Submitted by beat on Thu, 10/08/2009 - 08:22
Moving sub-server to top-level server does not change the session save path tmp directory in local etc/php.ini :
- changed sub-domain to subserver
- then moved sub-server to top-level server
- then website settings -> changed php to fastcgi
Result:
session write permissions error: the session was tried to be saved in the previous parent-server tmp directory !
Status:
Active
Comments
Submitted by JamieCameron on Thu, 10/08/2009 - 11:39 Comment #1
Thanks for pointing this out - it will be fixed in the next Virtualmin release (3.74)
Submitted by beat on Tue, 10/13/2009 - 11:30 Comment #2
Another small bug when doing this operation:
missing a shell initialization file:
.shrc or .bashrc file is missing in /home/newtoplevelserverthatwasdomainalias/
This got pointed out as a possible security issue during a security audit of the site, so we copied .bashrc from another account.
Submitted by JamieCameron on Tue, 10/13/2009 - 16:37 Comment #3
If you create a new top-level virtual server, do those files get copied into it's home directory?
Virtualmin normally copies in everything from the /etc/skel directory.
Submitted by beat on Tue, 10/13/2009 - 17:19 Comment #4
These files got created on a new site I created just before the migration.
I can't try right now on exactly that server, as i'm avoiding like hell creating a new site in virtualminPro, as virtualminPro unfortunately restarts" the apache server, instead of just *reloading its settings (which is safer, as in most error cases, the previous config continues working with reload). And this causes a downtime of 2-3 minutes in our case, due to some long-runing crons, not ending quickly, and making virtualminPro's restart fail...
EDIT:
Precision:
My /etc/skel/ has .bash_logout, .bash_profile, .bashrc
Actually, Virtualmin reloads under most circumstances. The only occasions where it restarts Apache (unless you've configured it to always do so) would be for adding SSL sites or adding new IPs, which requires a restart because Apache has to re-bind to port 80, which requires root privileges.
If you're seeing it restart when just creating a new virtual server, rather than reload, and you didn't configure it that way, I guess it would be a bug.
Submitted by beat on Tue, 10/13/2009 - 18:08 Comment #6
I cycled through all of the "Configuration For module Virtualmin Virtual Servers" configuration panes, and didn't see such a switch. Don't recall to have seen such a setting, so i guess it's in default state. Where is it so I can check it ?
Submitted by JamieCameron on Tue, 10/13/2009 - 18:17 Comment #7
The next Virtualmin release (3.75) will copy the files from /etc/skel when converting a sub-server into a top-level server..
Submitted by JamieCameron on Tue, 10/13/2009 - 19:45 Comment #8
Regarding the Apache update, go to Webmin -> Servers -> Apache Webserver -> Module Config -> System configuration, and make sure the "Command to apply configuration" is set to something like
/etc/rc.d/init.d/httpd graceful
Submitted by beat on Wed, 10/14/2009 - 09:31 Comment #9
it is currently:
/usr/sbin/apache2ctl graceful
And that takes lots of time, since it still restarts all processes.
But shouldn't it (/ can it ? ) be on debian/ubuntu systems:
/etc/init.d/apache2 reload
???
reload is instant and TESTS the config before applying, leaving the old one if there is an error.
(start and stop are already of the forms /etc/init.d/apache2 start , and, /etc/init.d/apache2 stop )
Submitted by JamieCameron on Wed, 10/14/2009 - 12:43 Comment #10
A graceful update shouldn't restart any processes, just tell Apache to re-read its config.
If you run
/usr/sbin/apache2ctl graceful
manually, does it take a long time?You can switch this to
/etc/init.d/apache2 reload
if you like though.Submitted by beat on Wed, 10/14/2009 - 16:40 Comment #11
No, graceful is fast, like reload.
I checked ubuntu code for reload, and it calls graceful, after having checked the config, thus looks better, avoiding restart failures on configuration errors:
;;
Submitted by beat on Fri, 10/23/2009 - 15:48 Comment #12
Another bug here when moving a sub-server to top-level:
In the existing directory, the ownerships are not changed. In particular, the 2 symbolic links:
awstats-icon -> /usr/share/awstats/icon icon -> /usr/share/awstats/icon
do keep their previous owner, which makes them not deletable by the new owner, or by an install script.
Submitted by JamieCameron on Sat, 10/24/2009 - 00:27 Comment #13
I'll fix the link ownership in the next release .. although it doesn't actually matter, as link permissions are never actually used. In my tests without this fix the new owner could still delete the links.