Trouble with ASP.Net and SignalR websockets

snapcraft
1

I am needing package an ASP.Net core webapp into a snap so I can run it on an ubuntu core device (A task I have learned to dread because its always a painful process). This application works well outside of snaps, I can even stop the snap sudo su into the path and run the binary and everything works but when it runs as a snap all the network communications get blocked and I get 404 errors. I have included the yaml below I have added all the obvious network plugs but to no avail.

Additional info: The webapp is a vue3 front end Communications are handled through signalR and largely is websocket based but the intial serve that is blocked is just a simple HTTP GET

name: cmc-hmi
version: '0.2.0'
summary: EClass HMI
description: |
  HMI for EClass
confinement: strict
grade: stable
base: core22
type: app

apps:
  cmc-hmi:
    command: cmc-hmi
    plugs: 
      - home
      - content
      - browser-support
      - network
      - network-status
      - network-bind
      - network-observe
      - network-control
    daemon: simple
    restart-condition: always
    environment:
      LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP
      DOTNET_SYSTEM_GLOBALIZATION_INVARIANT: 'true'
    passthrough: 
      restart-delay: 10s

parts:
  main-app:
    plugin: dump
    source: ./publish/${SNAPCRAFT_TARGET_ARCH}

plugs:
  datalayer:
    interface: content
    content: datalayer
    target: $SNAP_DATA/.datalayer
slots:
  # This slot is for sidebar integration
  package-assets:
    interface: content
    content: package-assets
    source:
      read:
        - $SNAP/package-assets/${SNAPCRAFT_PROJECT_NAME}
2

Have you tried to run snappy-debug alongside this app snap to see if your issues are actually caused by confinement at all?

3

it is having several confinement issues, sorry not including those originally.

requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0 File: /sys/devices/system/node/possible (read)

requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0 File: /sys/fs/cgroup/system.slice/snap.cmc-hmi.cmc-hmi.service/cpu.max (read)

capname=“sys_nice” Capability: sys_nice

I have no idea what exactly is causing those reads though, and they dont seem network related at face value.

4

Well, the log would have been helpful, but you can read it yourself i guess, underneath the denials it should make suggestions about what interface plugs might be needed to solve the denial…

5

Ok I have found the main cause to the issue to be the webapp was trying to load the from the var/… directory instead of its own container. Since there is only user data in this directory but not the app parts themselves this fails now why the system is pulling from the wrong directory I am not sure. This is fixable in my case by directly telling it where its own directory is but I am not sure why

System.Directory.GetCurrentDirectory()

returns the var path when historically it has always returned the snap path.

@ogra I appreciate you hoping in to help. Is the above behavior expected? if so I can consider this issue solved.

6

Daemon snaps have exactly two dirs they can write to, you should make sure your app uses these … both are exposed in the runtime environment via env variables …

SNAP_DATA → points to /var/snap/<snapname>/current, data in there will be bound to the currently running snap version and gets copied forward on refreshes (i.e. configuration and such should land there, the version binding makes sure rolling back your snap will get the user the exact config for this version (i.e., if config options or syntax change between to revisions, it will not break) …

SNAP_COMMON → points to /var/snap/<snapname>/common and should be used for bigger amounts of data that does not need to be versioned… i.e. caches, databases etc

I’d recommend to make your code use these two variables for your app so any writable bits can actually be written at runtime …

7

Yes currently that is how handle writable data, but the wwwroot file and binary are in the path provided by $SNAP env var. The ASP.NET webapplication builder uses by default the path returned by:

Directory.GetCurrentDirectory();

typically this path is the same as returned by $SNAP as this where the binary is running. In this case it it returns the path of $SNAP_DATA. there for the binary could run and knew where to write values and read configs ect. but it could not find the wwwroot file which for whatever reason does seem to throw an exception. This is at least my working theory