Undefined subroutine &virtual_server::set_provision_features called at /usr/share/webmin/virtual-server/domain_setup.cgi line 39

URGENT:

Since this morning's upgrade via aptitude, when creating a sub-domain, we get:

Error - Perl execution failed

Undefined subroutine &virtual_server::set_provision_features called at /usr/share/webmin/virtual-server/domain_setup.cgi line 391.

Note:

During the upgrade we had 2 errors due to a customer deleting a domains/subdomain.com folder ! :

Error: Failed to copy /etc/php5/cgi/php.ini to /home/xxxxx/domains/yyyyyy.com/etc/php5/php.ini : cp: cannot create regular file `/home/xxxxx/domains/yyyyyy.com/etc/php5/php.ini': No such file or directory

Also in that case, Apache cannot restart:

/etc/init.d/apache2 reloadWarning: DocumentRoot [/home/xxxxx/domains/yyyyyy.com/public_html] does not exist
Syntax error on line 19 of /etc/apache2/sites-enabled/yyyyyy.com.conf:
can't get fastcgi file info: /home/xxxxx/domains/vossfjellandsby-skiskule.no/fcgi-bin/php5.fcgi(/home/xxxxx/domains/yyyyyy.com/fcgi-bin/php5.fcgi), errno: 2
   ...fail!

So that would be a second bug... Users should not be able to delete the folders created by Virtualmin, specially in domains and public_html itself too. And if they delete, it should not preemt Apache from (re)starting...

Status: 
Active

Comments

Actually, after fixing the renamed (he didn't delete it) folder, then downgrading to 3.82-2 and upgrading again to 3.83 in aptitude, then restarting webmin, the problem got solved by itself.

So may have been related to the renamed folder.

Second bug that user should not be allowed to tamper their folders hierarchy, as it breaks entire server, remains.

Howdy -- as far as your first issue goes, when you received "Undefined subroutine" -- we've seen some cases where that comes up when there's a "stuck" Webmin process.

That is, if the miniserv.pl process isn't killed off properly during the upgrade, that can cause that sort of trouble.

In that case, the fix would be to first stop Webmin (with /etc/init.d/webmin stop), look for any of Webmin's miniserv.pl processes, and kill them with the kill command. Then launch Webmin using "/etc/init.d/webmin start", and see if that does the trick.

As far as users changing their hierarchy -- the files and directories that are required for Apache already setup to not allow users to delete them. Unfortunately, due to the way Linux permissions work, users can continue to rename them, there's not much we could do there.

To actually prevent the user from renaming those, you'd have to make it so that they didn't own their own home directory.

You could always set it up so that the Virtual Server owner can't FTP into the server (by changing their shell to something like /dev/null), and instead requiring that they create website access FTP accounts that are locked in the public_html folder.

One thing I'll talk to Jamie about though is adding an Apache config test to Virtualmin's "Re-check Configuration" section, so that it could detect any trouble there. In addition to being able to run that from the GUI, you could also run that from cron at night, and have it email you if there's any sort of problem.