axiscommunications / docker-compose-acap Goto Github PK

Regarding the compatibility instructions in README.md, perhaps we should consider adding information that you need to enable SSH (with link to existing instructions, or have the instructions here in the repo) on the device before attempting to run the command.

One might otherwise, falsely, assume that the camera hasn't support for Docker, while it in fact doesn't allow SSH connections.

Hi there, I have an issue where if a camera unexpectedly reboots (power or memory) then on reboot I get the following errors:

2022-08-05T10:39:30.172+10:00 axis-b8a44f3be4f1 [ ERR     ] dockerdwrapperwithcompose[1353]: Couldn't identify the file system of the SD card at /var/spool/storage/SD_DISK
2022-08-05T10:39:30.179+10:00 axis-b8a44f3be4f1 [ ERR     ] dockerdwrapperwithcompose[1353]: Starting dockerd failed

I am using Docker Daemon with Compose version 1.2.3, the camera is P3265-LV, Axis OS version 10.9.4. After reboot if I stop the app and start it again, it works perfectly fine. I have a 126gb sd card installed and formatted as per below:

Describe the feature

I am advocating to add an AXParameter to enable access to the host loopback through toggling the presence of '--disable-host-loopback' in the rootless startup call here

My use case is consuming the cameras RTSP stream through a rootless dockerised application which may not be aware/detect underlying changes in the interface/IP configuration and should only need to know the relative path to the stream via 'host.docker.internal'.

I realise that RTSP also runs on a privileged port (554) but this can easily be remedied by enabling a custom port above 1024. If there are other services which cannot be moved to custom ports there might be consideration to allow for this but I do not feel that this issue scopes towards the implications of extendng to privileged ports.

Added value

There are a number of ACAP applications which will consume/forward data from the host for the purposes of recording/backup, telemetry and brokering communication via MQTT which is. natively configured and exposed on the host. Adding a method to explicitly allow loopback access to applications lets users make in an informed decision about whether they would like to implement a less secure (but not root privileged) feature in order to realise many of these applications.

There are many options/ways in which the problem can be solved outlined here but other solutions would require intermediary containers and combining sandboxes/functionality which feels brittle and difficult to implement for most initial users.

Im Happy to collaborate on the PR if the feature is welcome

Describe the feature

Since we now release the Docker Compose ACAP as a signed eap file here on GitHub we should no longer release an image on Docker Hub.

Describe the feature

Less a feature and more a requisite for production usage. Should anyone use the contianer-example pattern they will encounter an issue whereby if their camera is either gracefully restarted or externally rebooted the containers do not respawn.

The root cause of the issue is that the paths which are recreated in the parent namespace are not removed prior to dockerd starting, resulting in the inability to create containers under /run/container in the user namespace.

You can see the dockerd-rootless.sh solves this by deleting the necessary paths so dockerd/rootlesskit can administrate these appropriately https://github.com/moby/moby/blob/4318ab0b33888d155abea0366d9c066dad46cf6c/contrib/dockerd-rootless.sh#L144

Added value

Any body availing of containerised applications which are managed by the runtime itself and not restarted externally will need this in order to have stable fault tolerant workloads.

Additional context

N/A