2020-04-29
The problem of Ubuntu 20.04, Snaps, and where your home directory is
Due to Chromium becoming a Snap in Ubuntu 20.04 and our user home directories not being under /home, it looks like our users will have to live without Chromium. Thanks, Ubuntu.
This may sound a little bit hard to believe, so let me show you the
stages of trying to use chromium-browser on 20.04 (installed by
doing 'apt-get install chromium-browser'):
; chromium-browser 2020/04/30 00:44:29.065359 cmd_run.go:560: WARNING: XAUTHORITY environment value is not a clean path: "/h/281/cks/.Xauthority" cannot open path of the current working directory: Permission denied ; cp -a $HOME/.Xauthority /tmp/cks-xauth; export XAUTHORITY=/tmp/cks-xauth ; chromium-browser cannot open path of the current working directory: Permission denied ; cd /tmp; chromium-browser Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.
On Ubuntu 20.04, Canonical delivers 'chromium-browser' (the open source version of Chrome) as a Snap, which is the jargon name for a 'Snappy', well, thing. The installed and visible /usr/bin/chromium-browser is just a shell script that flails around and eventually runs /snap/bin/chromium, which is a symlink to /usr/bin/snap, which magically winds up running Chromium as a sandboxed and oddly set up program. Or trying, at any rate; it fails, as you can see, because our long standing system configuration is incompatible with how Canonical requires you to operate your Ubuntu systems now.
(It would be nice if the whole system told you the core problem right away and saved you the initial attempts to make things work.)
Although the messages do not say this, the Snap system ignores any
$HOME environment variable that you might have set; what it cares
about is where /etc/passwd says your home directory is (after any
symlinks are resolved). The official documentation says 'a workaround is to bind
mount the home directory outside /home into /home'.
We currently have roughly 2600 user home directories that are not
under /home; instead they are under an assortment of filesystems
that are NFS mounted from our Linux ZFS fileservers. Bind mounting all of their filesystems
into /home or changing all of them to be NFS mounted there is
what we can politely call not feasible, and certainly massively
disruptive even if it was feasible.
Given this, I have to say that Canonical's Snappy system does not appear to be designed for anything except small environments, such as desktops and laptops used by one or a few people. It's certainly not viable in our larger (but still small scale) multi-user Unix environment. At the moment, we can probably live without Chromium in 20.04, although some of our users are going to be upset. If Canonical packages more important things as Snaps instead of actual packages, we will probably be forced to do something much more drastic.
(One quite likely option is migrating from Ubuntu LTS to Debian, who will probably never be this narrowly focused on small desktops or so willing to throw away compatibility with different environments.)
Dealing with my worries about Django and HTTP Basic Authentication
Last year, I attempted to upgrade our Django web app from Django 1.10 to 1.11, but ran into rather mysterious CSRF validation failures that caused me to revert back to 1.10. We have stayed there since, and the potential for this issue resurfacing has been a major blocker for moving to more recent Django versions or porting it to Python 3. I was lucky that moving from Django 1.10 to 1.11 required neither significant code changes nor a database migration, and so could be rolled back; a more major update would have left us basically marooned and having to debug Django itself, in production.
Ever since then, one of the growing focuses of my suspicions has been an interaction between our use of Apache HTTP Basic Authentication and Django's idea of a 'session' in the face of that (which apparently interacts with its CSRF protection). I rather suspect that not very many people use HTTP Basic Authentication with Django, which would allow bugs to linger here undetected for some time, and certainly Django having to magically materialize fake sessions for users authenticated this way seems like a potential source of fun problems.
Even reproducing the problem is, well, a problem, because it only manifests in a full production setup; setting up an entire duplicate of our app that runs under Django 1.11 is more than a bit tricky and I haven't done it so far. While thinking about this recently, though, it belatedly struck me that I probably don't need to go as far as a copy of our web app. If there really is a general CSRF validation issue when you're running under HTTP Basic Authentication, it should reproduce with a very basic Django app that just displays a form for you to update. I should be able to put that together fairly easily and it's easy to run it beside our web app since they have nothing to do with each other (unlike two copies of the real app, which if left alone would be trying to interact with the same things).
If I can reproduce our problems with a test app under Django 1.11, this gives me a path forward to Python 3 and a current version of Django because I can finally have confidence that we won't run into this issue in a big upgrade. Or I can find out in advance that we will run into the issue, which is much better than doing a lot of work, rolling forward, and then having it blow up badly.
(I have more thoughts about the future of our web app, but they don't fit in the margins of this entry. The short version is that we'd like to not have to do anything to our web app, but that doesn't seem very viable, cf.)