Showstopper bug - HIGH PRIORITY

On Dec 22, 2020 I submitted this bug report: https://www.virtualmin.com/comment/831622#comment-831622

re: JamieCameron said this would be fixed in the next virtualmin release. I have yet to see this fix on Ubuntu apt-get update / apt-get install

Now when I add a new virtual server, I have to manually hack and copy files from: /etc/init.d/php-fcgi-domain

...and also

/lib/systemd/system/php-fcgi-domain.service

From existing domain files.

After that, I have to run systemctl daemon-reload and systemctl start (service name)

This is on Ubuntu 18.04.5 LTS

This is a CRITICAL / showstopper bug. Please try it yourself on an Ubuntu 18.04.5 installation. Webmin and Virtualmin is severely corrupted. After waiting a month for a fix -- this has now become a high priority item.

I appreciate the webmin/virtualmin solution - but it has become unbearable to deal with because of this issue. Who knows how many silent users have dealt with this issue and simply given up on webmin/virtualmin as a result?

Status: 
Closed (fixed)
Virtualmin version: 
6.14
Webmin version: 
1.970

Comments

Which Webmin version are you running there? The latest release (1.971) should already contain a fix for this.

Ilia's picture
Submitted by Ilia on Wed, 02/03/2021 - 05:08

Wait, is this Nginx? If so, what is Virtualmin Nginx module do you have installed? (can be checked on System Settings > Features and Plugins page.)

Yes, I'm running NGINX -- It handles port scans and small DoS a lot better than bloated Apache. -- A lot of people are using NGINX more and more these days.

We run both non-ssl and SSL websites.

NGINX website plugin v2.18
NGINX SSL website plugin 1.14

The error that creates this seems to be in this file: /usr/share/webmin/virtualmin-nginx/virtualmin-nginx-lib.pl

Check around line 1708

Current:

              "Starts Nginx PHP FastCGI server for $d->{'dom'} (Virtualmin)",
              &command_as_user($d->{'user'}, 0,
                "$envs $cmd >>$log 2>&1 </dev/null")." & echo \$! >$pidfile && chmod +r $pidfile",
              &command_as_user($d->{'user'}, 0,
                "kill `cat $pidfile`")." ; sleep 1",

I think the second line is missing something to give a full path to the kill command (and the cat command) -- systemd runs first and doesn't have access to a user environment path if I remember correctly.

I'm really wondering why the first command which ends up as an ExecStart for systemctl says: $envs $cmd ...but the second command that ends up in ExecStop doesn't have the $envs

It seems to be one of the most confusing things that gets a lot of people I'm on Ubuntu (debian).. Here's someone talking about it on Centos that could help https://unix.stackexchange.com/questions/347873/set-path-for-a-systemd-unit

I can come close to fixing this problem EXCEPT for one single escaped \ backslash character that needs to be removed manually.

/usr/share/webmin/virtualmin-nginx/virtualmin-nginx-lib.pl Line 1708

OLD: "kill `cat $pidfile`")." ; sleep 1",
NEW: "'"."kill `".'cat'." $pidfile`")." ; sleep 1'",

This will create this type of entry in /libs/systemd/system/php-fcgi-domain.service

ExecStop=/bin/su username -c \'kill\ \`cat\ \/var\/php\-nginx\/16124277622318\.php\.pid\` ; sleep 1'

...and systemd will still complain about an Exec Format error. But all I have to do now is manually remove the backlash infront of the kill command:

ExecStop=/bin/su username -c 'kill\ \`cat\ \/var\/php\-nginx\/16124277622318\.php\.pid\` ; sleep 1'

...and now I can do:

# systemctl daemon-reload
# systemctl start php-fcgi-domain.service

...and things work. fcgi-php gets started for the user just fine, like it should. ** Removing the first backslash \ before the kill command is important.** It's obvious that this function is going thorough a regex and all single quotes are being escaped somewhere. Hope this helps a programmer that knows how to fix it.

Ilia's picture
Submitted by Ilia on Thu, 02/04/2021 - 05:28

Okay, thanks for your ideas. The real source of the issue was that commands didn't have absolute paths. It's going to be fixed in Nginx module 2.19.

You are welcome to try the patch.

Thanks for reporting.

I can confirm this patch works!! Thank you so much for fixing it.