Moving sub-server to top-level server does not change the session save path tmp directory in local etc/php.ini

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

Thanks for pointing this out - it will be fixed in the next Virtualmin release (3.74)

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.

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.

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

Joe's picture
Submitted by Joe on Tue, 10/13/2009 - 17:28 Pro Licensee

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.

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.

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 ?

The next Virtualmin release (3.75) will copy the files from /etc/skel when converting a sub-server into a top-level server..

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

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 )

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.

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:

reload | force-reload) if ! $APACHE2CTL configtest > /dev/null 2>&1; then $APACHE2CTL configtest || true log_end_msg 1 exit 1 fi log_daemon_msg "Reloading web server config" "apache2" if pidof_apache > /dev/null ; then if $APACHE2CTL graceful $2 ; then log_end_msg 0 else log_end_msg 1 fi fi

;;

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.

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.