You are here
Adnan R. - Wed, 2023/07/12 - 21:31
Hi there,
Answering 55107, I didn't put the logs in a file because there isn't much to
root@dc1 ~# systemctl status stunnel4@webmin --no-pager -l
* stunnel4@webmin.service - Universal SSL tunnel for network daemons (webmin)
Loaded: loaded (/lib/systemd/system/stunnel4@.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2023-07-11 23:28:24 UTC; 18h ago
Process: 19394 ExecStart=/usr/bin/stunnel4 /etc/stunnel/webmin.conf (code=exited, status=226/NAMESPACE)
CPU: 575us
Jul 11 23:28:23 dc1 systemd[1]: stunnel4@webmin.service: Control process exited, code=exited, status=226/NAMESPACE
Jul 11 23:28:23 dc1 systemd[1]: stunnel4@webmin.service: Failed with result 'exit-code'.
Jul 11 23:28:23 dc1 systemd[1]: Failed to start Universal SSL tunnel for network daemons (webmin).
Jul 11 23:28:24 dc1 systemd[1]: stunnel4@webmin.service: Scheduled restart job, restart counter is at 5.
Jul 11 23:28:24 dc1 systemd[1]: Stopped Universal SSL tunnel for network daemons (webmin).
Jul 11 23:28:24 dc1 systemd[1]: stunnel4@webmin.service: Start request repeated too quickly.
Jul 11 23:28:24 dc1 systemd[1]: stunnel4@webmin.service: Failed with result 'exit-code'.
Jul 11 23:28:24 dc1 systemd[1]: Failed to start Universal SSL tunnel for network daemons (webmin).
root@dc1 ~# systemctl status stunnel4@shellinabox --no-pager -l
* stunnel4@shellinabox.service - Universal SSL tunnel for network daemons (shellinabox)
Loaded: loaded (/lib/systemd/system/stunnel4@.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2023-07-08 21:43:41 UTC; 3 days ago
CPU: 646us
Jul 08 21:43:40 dc1 systemd[1]: stunnel4@shellinabox.service: Control process exited, code=exited, status=226/NAMESPACE
Jul 08 21:43:40 dc1 systemd[1]: stunnel4@shellinabox.service: Failed with result 'exit-code'.
Jul 08 21:43:40 dc1 systemd[1]: Failed to start Universal SSL tunnel for network daemons (shellinabox).
Jul 08 21:43:41 dc1 systemd[1]: stunnel4@shellinabox.service: Scheduled restart job, restart counter is at 9.
Jul 08 21:43:41 dc1 systemd[1]: Stopped Universal SSL tunnel for network daemons (shellinabox).
Jul 08 21:43:41 dc1 systemd[1]: stunnel4@shellinabox.service: Start request repeated too quickly.
Jul 08 21:43:41 dc1 systemd[1]: stunnel4@shellinabox.service: Failed with result 'exit-code'.
Jul 08 21:43:41 dc1 systemd[1]: Failed to start Universal SSL tunnel for network daemons (shellinabox).
root@dc1 ~# systemctl start webmin
A dependency job for webmin.service failed. See 'journalctl -xe' for details.
root@dc1 ~# systemctl status webmin --no-pager -l
* webmin.service - Webmin server daemon
Loaded: loaded (/lib/systemd/system/webmin.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/webmin.service.d
`-override.conf
Active: inactive (dead)
Jul 12 18:24:46 dc1 systemd[1]: Dependency failed for Webmin server daemon.
Jul 12 18:24:46 dc1 systemd[1]: webmin.service: Job webmin.service/start failed with result 'dependency'.
Also, /var/log/webmin.log shows logs from march, I installed the container in July, so nothing related to my issue I suppose. And /var/log/stunnel4/stunnel.log is empty.
Forum:
Is this a priveledged container?
Is this a privileged container? If so I suggest retrying with an unprivileged one. If it's already an unprivileged container, try enabling nesting.
FWIW it was this line that makes me think that:
Systemd namespace errors are almost always caused by the container not having access to some resource that it needs.
Hey !
Hey !
Thanks for the tip, it was indeed privileged but not nested. It didn't prevent me to use the DC part anyway.
I'm enjoying the extra now :)
I actually meant "unprivileged"
I actually meant "unprivileged" (I've edited my previous post), but TBH I'm not completely sure now and I may be confused? I recall that a privileged container was required, but I'm fairly sure that with "nesting" enabled it should work in an unprivileged container.
Please be aware that with nesting enabled on a privileged container, if a malicious actor were able to get root in your container, breaking out of it and getting access to the host (Proxmox) root account is a significant risk! Enabling nesting for an unprivileged container is nowhere near as much risk (some host resources are available, but the container root user does not map directly to the host root user).
Unless you explicitly trust all the users on your network, I would personally recommend at least trying to get it working in a unprivileged container, or probably better still, run it in a "proper" VM (ISO download links are available from the relevant appliance pages; i.e. Domain Controller and Fileserver).
Add new comment