MAAS fails clean install www-data user does not exist due to nginx requirement

[Craig Bender]

MAAS requires nginx, but nginx-related packages fail to install properly if user "www-data" has been removed.

This causes any MAAS component that relies on nginx to fail dpkg configuration.

Specifically, these packages will fail configuration/full installation:

Errors were encountered while processing:
 nginx-common
 libnginx-mod-http-xslt-filter
 libnginx-mod-http-geoip
 nginx-core
 libnginx-mod-mail
 maas-rack-controller
 libnginx-mod-http-image-filter
 libnginx-mod-stream
 maas

Happens on any version of MAAS where nginx is required (2.4+?)

Recreate: Remove www-data user prior to installing MAAS (sudo userdel -fr www-data)

While I know this is a bug with nginx, "apt install maas" should fail much earlier of pre-reqs fail to install. Discovered while installing on customer provided "hardened" Ubuntu Image

[Alberto Donato (ack)]

This is not a maas bug.

Since nginx fails to install and it's a maas dependency, install is interrupted and can't complete instaling maas.

[Thomas Ward (teward)]

We require more data to determine if this is actually an nginx *bug* or something else. We need to see the logs regarding the packages not installing, which are in apt console logs or syslog. Usually the issue isn't one of it not *installing* but more that it installed but couldn't complete configuration.

Without more details surrounding why nginx failed to install/run, it's impossible to diagnose this deeper.

[Thomas Ward (teward)]

This said, `www-data` is created by the *system* even if you don't have any web server installed - the removal of something in the predefined system users group is potentially 'non-standard' and could introduce some breakage of things, as seen here.

Digging deeper because I'm not entirely certain that this is something the nginx package should handle - user creation - but it needs more discussion among server team first.

[Robie Basak (racb)]

www-data has id 33, so belongs to the first class described at https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes

It's therefore reasonable for packaging to assume that it always exists, so this is not a bug in nginx packaging. In the general case it's not reasonable for packaging to accommodate arbitrary situations that cannot arise by policy, since that would make packaging complexity explode. I don't think this case warrants an exception.

I believe that the root cause of your problem is your hacked image. Removing the www-data user or group can be expected to have exactly these consequences.