tracker
tracker copied to clipboard
turnkeylinux
Bad Password for Database during initial Setup
My Turnkey Nextcloud instance suddenly started having odd issues that prompted me to download a copy of my data for a Backup and recreating the entire LXC.
I noticed there are some newer versions of the Turnkey appliances so I decided to try the latest (debian-11-turnkey-nextcloud-17.2-1). This one, even in a Privileged container, fails to properly initialize due to issues creating the /dev/random and /dev/urandom nodes within the container:
So I decided to try the previous template (debian-11-turnkey-nextcloud-17.1-1) and it does hang on this postfix step for several minutes during initial boot. I'm not sure why it is running an "unprivileged" hook when this is a Privileged container.
It does eventually complete without any visible errors and allows me to login. While walking through the first-run wizard, I create the Adminer password and then the Admin user password. After specifying that Admin password, I get the error below, indicating that there is an issue connecting to the Database.
Anybody else having issues like this in Proxmox containers? This is with Proxmox 7.7-3.
FYI, the debian-10-turnkey-nextcloud_16.1-1 template does not hang on that postfix step and I can get through the initial configuration and to the Install Security Updates stage.
While installing those updates, I noticed an error related to the Apache service:
But it eventually finishes and reaches the Configuration Console:
Unfortunately, it seems Apache is not running because I cannot access the web interface at the URLs shown. (The Webmin and Web Shell URLs do not work either)
If I go into the Advanced menu and Reboot the appliance, I still do not have access to any of the URLs and Apache2 still is not running:
I had this Debian 10-based install running for a couple months with no issues until today when it broke. I'm guessing something updated in Proxmox that is causing these troubles. As it stands now, I am unable to get any of these three Turnkey Nextcloud appliances up and running.
Ok, after some digging I was able to resolve the Apache2 issues in the debian-10-turnkey-nextcloud_16.1-1 version by enabling Nesting in the Privileged LXC container.
Now I am going to try again with the newer turnkey appliances and see if I have better luck.
Ok, debian-11-turnkey-nextcloud_17.1-1 is working now that I have enabled Nesting in the LXC container. Might be worth noting in the Docs that you must set the LXC to allow Nesting.
As for debian-11-turnkey-nextcloud_17.2-1, it does still hang here on first boot, and this seems to be the only version that has this permission denied error.
This is a Privileged container with Nesting enabled.
Update After being hung there for about 5min, it did eventually continue booting and allowed me to complete setup. So it seems that enabling Nesting was the key to get these working. I don't recall if I had done that previously when I originally setup the older appliance.
I'm still not sure what impacts those Permission Denied errors may have, but I will continue configuration and report anything I find.
@tokenwizard - apologies on such a ridiculously slow response...
fails to properly initialize due to issues creating the /dev/random and /dev/urandom nodes within the container
The error you are noting is a workaround we implemented some time ago to allow TurnKey containers to run unprivileged (hence the name - although it is applied to all of our containers - so you don't need to use a different template depending on your usage scenario). The issue is that postfix runs inside a chroot, which if LDAP authentication is required/desired then it needs to create those "special" files (/dev/random & /dev/urandom). It appears that the command to make them immutable is failing, although other than the error message, it shouldn't be a problem.
enabling Nesting in the Privileged LXC container
Please DO NOT do that unless you really, really need to and ideally please ensure that your container is not publicly available. Enabling nesting has security implications - it passes additional host system access to the container. In an unprivileged container, the risk is mitigated because the root user within the container is mapped to a non root user on the host. So even if a malicious actor were to get root in your container and escape the container, the damage will be limited because they will only be a limited user on the host. But on a privileged container, the root user is mapped directly to the root user on the host. That means that if a malicious actor was to gain root on your container, getting root on the host becomes a distinct possibility.
So long story short, avoid privileged containers whenever possible. Enabling nesting is ok, but only on unprivileged containers.
Services failing on privileged containers is pretty common these days. That is because many of the newer system (systemd) hardening tweaks (direct from Debian) are incompatible within a privileged container. The cause of the error you note when trying to set the adminer user password in your first post is because MySQL is failing to start (in a privileged container).
The reason why the earlier version "works" is because it has a older version of systemd and doesn't have the same MySQL security hardening applied to the service. TBH, I'm not 100% sure about the later Apache issue you note, although looking at the output, I see issues relating to "namespace" - in context of LXC, that is almost always because it requires a system capability that it is not being allowed by the host.
The Nextcloud appliance requires nesting because the Redis service has some special requirements. (That may also be a factor for older images, default inclusion of redis is somewhat new).
As for debian-11-turnkey-nextcloud_17.2-1, it does still hang here on first boot, and this seems to be the only version that has this permission denied error.
As noted above, the error message is not actually a problem. For the record, that bit of code has been around for ~4 years so is in both v16.x & v17.x so my guess is that you set then up slightly differently?
After being hung there for about 5min, it did eventually continue booting and allowed me to complete setup.
I'm not sure, but I suspect that the "hang" you are reporting is postfix restarting (i.e. the service postfix restart line). It certainly shouldn't take anything like 5 minutes though! TBH I don't really know why it took that long!?
So it seems that enabling Nesting was the key to get these working.
Yep, but as I say, only do that for an unprivileged container.
Final summary:
The errors you note are somewhat expected. The "workaround" is to use an unprivileged container, with nesting enabled.
I think it might be useful for us to check the container config on firstboot and check for privileged/unprivileged and whether nesting is enabled - and advise the user.
Thanks for taking the time to share your feedback and apologies again on my slow response. Hopefully some of what I've posted is of value...
