Filesystem access to app data

[teracloud]

Hi,

We currently have an application installed as a snap on our Bosch development hardware. This application reads and writes a few files on the filesystem in the snap's data directory (e.g. /var/snap/name/ver; unsure of what the exact path is on the Bosch HW).

My question is if there is some way to access these files on the PLC through the web interface or an application, etc? I know that SSH access has been disabled for security reasons. Is it necessary for the application to expose functionality to read or write these files e.g. through some sort of REST API? We need to be able to read or write these files in production.

And what is the recommended approach? To be clear, we're only talking about reading and writing data specifically for this app, and nothing else.

Thank you.

[CodeShepherd · Accepted solution]

The standard way of exchanging data between different apps is putting them into the active configuration (app data) that is a shared file system and is used for storing/restoring configuration data.

See this post how to use from your own app.

See this post how to access to these data from outside of the control (via WebDAV).

As addition:

PLC file system is also part of the app data. See this post.

You could also use SD-card or USB storage. See this post.

Use SD-card storage from PLC. See this post.

[teracloud]

Lots of interesting information to look at.

Thank you for the information!

[teracloud]

According to your first link, it should be possible to manage the snap application's data via the web interface by writing the data to the $SNAP_COMMON/solutions folder.

We tried to update our snapcraft.yaml file with the suggested solution, but we can't get it to work. What are we missing? Is there some kind of special requirement to get this active-solution plug working?

Please keep in mind that this is a work in progress, but there is out current snapcraft.yaml file:

name: teracloud # you probably want to 'snapcraft register <name>'
base: core20 # the base snap is the execution environment for this snap
version: '1.0' # just for humans, typically '1.2+git' or '1.3.2'
summary: ControlMachines Logic # 79 char long summary
description: ControlMachinesLogic

grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
type: app

plugs:
  active-solution:
  interface: personal-files
  write:
    - $HOME/.config/foo

passthrough:
  hooks:
    install:
      environment:
        CONFIG_NAME: Config.xml
        CONFIG_PACKED: ${SNAP}/bin/${CONFIG_NAME} #config location in the package (source)
        CONFIG_PATH: ${SNAP_USER_DATA}/${CONFIG_NAME} #config destination

parts:
  src:
    plugin: dump
    source: ./src #dump files to root of the snap

apps:
  copyconfig:
    command: bin/conf_upd.sh
    daemon: oneshot
    restart-condition: never

  # configtest:
  #   command: bin/script.sh $CONFIG_PATH
  #   daemon: oneshot
  #   restart-condition: never
  #   environment:
  #     CONFIG_NAME: Config.xml
  #     CONFIG_PACKED: ${SNAP}/bin/${CONFIG_NAME} #config location in the package (source)
  #     CONFIG_PATH: ${SNAP_USER_COMMON}/${CONFIG_NAME} #config destination

  GenAddrCacheEMA:
    command: bin/ControlMachinesLogic $CACHE_NAME
    daemon: oneshot
    plugs:
      - mount-observe
      - network
      - network-status
      - network-bind
      - active-solution:
          interface: content
          content: solutions
          target: $SNAP_COMMON/solutions

    restart-condition: never
    environment:
      DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: 'true'
      CACHE_NAME: -GenMonitorAddrCache:EMA -Environment:Bosch
  
  viewconfig:
    command: bin/printconfig.sh
    daemon: oneshot
    restart-condition: never


  app:
    command: bin/ControlMachinesLogic $RUNTIME
    daemon: simple
    plugs:
    - mount-observe
    - network
    - network-status
    - network-bind
    - active-solution:
        interface: content
        content: solutions
        target: $SNAP_COMMON/solutions


    restart-condition: on-failure
    passthrough:
      restart-delay: 10s
    environment:
      DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: 'true'
      RUNTIME: -Logic:EMA -Environment:Bosch
# SNAP_USER_COMMON unversioned user specific storage
# SNAP_USER_DATA versioned user specific storage
# SNAP_DATA/SNAP_COMMON system-wide data storage to share between snaps

We are running snapcraft via github. When we do, we get the following error:

Starting Snapcraft 7.1.3
Logging execution to '/home/user/.cache/snapcraft/log/snapcraft-20220906-145237.288545.log'
Issues while validating snapcraft.yaml: The 'apps/GenAddrCacheEMA/plugs[4]' property does not match the required schema: OrderedDict([('active-solution', OrderedDict([('interface', 'content'), ('content', 'solutions'), ('target', '$SNAP_COMMON/solutions')]))]) is not of type 'string'

 What could be the problem?

[CodeShepherd · Accepted solution]

There is no special requirement for this. But the plug needs to be added to your third code block not under the app. I created a small test example here.

#...
grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
type: app

plugs:
  active-solution:
    interface: content
    content: solutions
    target: $SNAP_COMMON/solutions
  interface: personal-files
  write:
    - $HOME/.config/foo

passthrough:
#...