Quick Notes on ASL3 in Docker

AllStarLink
1

So over the weekend I decided to undertake the task of seeing if I could get ASL3 working in Docker. There's a lot of conflicting information from everyone...which is common in the ham world and is going to be the thing that brings this to a broken smashed circle. This is not going to be a HOWTO, it's not going to be in-depth. It's mostly a dump of my thoughts and notes I made while attempting to deploy this that might help someone else in the future should they decide. Host is a LibreComputer LePotato running the vendor built Debian 12 image. This is basically a Pi3B+ class device.

The Docker build in the ASL3 repository works. Mostly. Currently the Dockerfile isn't going to pull an base image as $ARCH/debian:13-slim is no longer the proper way of doing it. This is fixed by not passing $ARCH at all...and is probably something I can submit as a PR. I built it using a 13-slim container on a Debian 12 host with no problems.

  • The snd-pcm-oss snd-mixer-oss kernel modules need to be loaded on the host. My vendor didn't load them by default. That was a fun 2 hours.
  • There are reasons to not run privileged mode; but I didn't get far enough to determine if it was really needed here. That being said it'll avoid a lot of permissions issues with /dev/dsp and isn't much worse than running it baremetal.
  • asl-menu, naturally, is built around systemd - so can't restart asterisk but you restart the container. That's the only complaint it has.

So...I was expecting far more notes and issues; but those were the only things I had related to actually getting ASL3 running. I had a lot of fun getting an Allscan container built....however since I never got the node functional I have no clue if it did anything but load config.

Ultimately I was trying to use AIOC cables...they're not going to work. People say they do...but I've got six radios here and I get the same failure every time; and it's one that everyone points to the solutions that haven't worked for me and even has Fable confused. I can manually buzz the audio with my finger and VCOS works fine. The minute I plug it in to a radio VCOS quits working. Oh..it detects audio...it just doesn't hold VCOS on. But you pull it out of the radio and it functions fine. I'm just done with 'em.

2

3.10.x release will no longer need OSS to connect to the audio. That maybe helpful.
The container will still need to connect to the USB device to access the GPIO...

3

Any PRs to improve the Docker situation would be welcome. There's low use of ASL in Docker or Podman, but there is some small instances of it. It just doesn't get a lot of attention.

4

Yes, I've read that will be coming soon; which will be good. None of the OSS stuff will matter. I have a dmr hotspot already containerized using GPIO. As well as one for an OpenGD radio on USB.

I might have to convert my primary node over to docker then since the hardware I had for the planned one isn't going to work out. I'm not exactly a docker fan...but I got this far with it. Plus it did make tunneling it over my particular VPN setup much less tedious.

5

So I started writing this about 4 hours ago when I needed a break...and then I just really wanted to get the last piece of a "working" setup finished. But you're gonna get what I already typed...and then what my sleep-deprived brain feels like saying.

So I went through both the existing dockerfile, the docker-compose, and all of the shell scripts involved to bring it up to typical "docker standards". The image creation is now solely done in one single Dockerfile. This also cuts out a lot of stuff that's no longer needed...like kernel headers. The original entrypoint script was also...not necessary. We don't have modprobe in a container to load modules...let alone have the modules to load. The initial set of configs will come from the repository...and the perl substitutions don't seem necessary anymore. One of them doesn't seem to exist and the other doesn't seem like it does anything meaningful.

Yes...the initial default set of scripts should ship in the repository with the docker-compose.yaml and not installed from apt. That is fine for bare-metal land; but it's not a fit in docker world. We're already mounting ./asterisk_conf to /etc/asterisk in the container. Put them in the repo and then it's done.

The systemctl shim is real and probably here to stay...at least for part of the process. Apt and dpkg seem to really love starting and stopping things with systemctl; and that's fine. There are actually numerous images out there that have this same shim for the same reasons.

The other dependencies on systemd appear to be related to starting/stopping/restarting Asterisk, and the astdb update service. The first one is easy...we just tell the user they need to start/stop/restart their container. I mean technically...we can make the container do this if it's set to always-restart. Asterisk runs as PID 1; if we send it a shutdown command then the container will exit and auto-restart will boot it back up. I don't think it's a great idea to encourage the container to influence it's own lifecycle outside of overflowing the stack and heaping all over the place. I'll probably just shim/stub anything about rebooting asterisk to a message about restarting the container....and I might just remove any mention/option of shutting asterisk down.

So...the whole privileged container thing....I cracked it. That was probably a large chunk of my evening; but I did manage to figure out what was needed to get HID enumerated and not have chan_usbwhteveraradio to refuse to load...and it was a combination of the old libusb-0.1; the fact debian doesn't just ship a shim for libusb-0.1 and ships the real deal; and docker's modern security policies not allowing me to link in /proc/asound.

    security_opt:
      - systempaths=unconfined
    device_cgroup_rules:
      - 'c 189:* rmw'

I feel better about that than a privileged container. It's still giving it access to a lot of stuff; but it's not tearing the wall off the front of the house.

I had originally ended by saying "after I get my node back online I'll take a look at allmon3 docker". The reality is I personally use Allscan...and had already started trying to docker it up. Yeah...this was not fun. You're probably wondering "it's just a php app running on a server...how hard could that be?" Well...there's dependencies. Yeah...they list some; but they're incomplete and it's a game of "what doesn't load". Then there's the fact it really assumes...and really insists that it runs on the same machine as your Asterisk. I mean...I guess I did see where it didn't have to...and clearly it does; but I also did some things it wanted...like giving it read-only access to /var/log/asterisk and the conf files from asterisk it wanted. Then I found my VPN policy routing was biting me in the butt. So I fixed that and spent 2 hours debugging what was ultimately a setting in lighttpd.

Work is gonna have questions about my token usage and I'm not going to have good answers for them....so I hope they at least wait a week. :winking_face_with_tongue:

So...if I can get allscan running in a docker container; I should be able to get allmon3 running in one too.