4.0.19 - Server Config and Symbolic Links

A

Atticus

Active Member
#1
#1
Hello!

With 4.0.18 you included the ability to omit an entry for the server name variable in httpd_config.xml. LSWS uses the environment $HOSTNAME variable to set it when this happens.

With this change I moved the location of the central httpd_config.xml file from /usr/lsws/conf to /home/lsws (NFS mount) using a symbolic link. Every Litespeed server was configured in this method and everything has worked great. There is, however, one exception.

While Litespeed operates fine with this file as a symbolic link, updating the config file from the Litespeed interface causes a problem. Litespeed appears to copy the contents of httpd_config.xml, deletes the symbolic link, and then recreates the httpd_config.xml as a static file.

Before Updating in LSWS GUI:
[root@www2 lsws]# stat /usr/lsws/conf/httpd_config.xml
File: `/usr/lsws/conf/httpd_config.xml' -> `/home/lsws/httpd_config.xml'
Size: 27 Blocks: 0 IO Block: 4096 symbolic link
Device: 802h/2050d Inode: 197593802 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 151/ lsadm) Gid: ( 503/ lsadm)
Access: 2011-01-31 10:30:33.000000000 -0800
Modify: 2011-01-28 12:07:36.000000000 -0800
Change: 2011-01-31 10:30:30.000000000 -0800

After Updating in LSWS GUI:
[root@www2 lsws]# stat /usr/lsws/conf/httpd_config.xml
File: `/usr/lsws/conf/httpd_config.xml'
Size: 100735 Blocks: 208 IO Block: 4096 regular file
Device: 802h/2050d Inode: 197593797 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 151/ lsadm) Gid: ( 503/ lsadm)
Access: 2011-01-31 10:32:02.000000000 -0800
Modify: 2011-01-31 10:32:02.000000000 -0800
Change: 2011-01-31 10:32:02.000000000 -0800

This is happening on a cluster of servers running CentOS 5.5 x86_64 w/ the latest Litespeed release installed. This issue does not affect Litespeed in any negative way other than being a minor inconvenience to have to recreate the link repeatedly.
 
M

mistwang

LiteSpeed Staff
#2
#2
If you use symbolic link, you have to link the "conf" directory.
LiteSpeed always create new configuration file, then rename, it is to prevent corrupting current configuration when out of disk space.
 
A

Atticus

Active Member
#4
#4
One issue this appears to present is the presence of the server license key being in the conf folder. Obviously this can't be shared across multiple servers. Any solution for that?
 
N

NiteWave

Administrator
#5
#5
a question, even if all servers of a cluster share one http_config.xml, once it updates, still need restart each server individually?
not sure if the procedure is:
1.update the http_config.xml through admin console on one server.
2.cp /usr/lsws/conf/httpd_config.xml /home/lsws/httpd_config.xml
3.restart each server in the cluster
 
A

Atticus

Active Member
#6
#6
Restarting the whole cluster is actually quite simple. We have a collection of CLI tools written in PHP which can help issues commands over the whole cluster. I can trigger a staggered restart across all of our Litespeed servers with one command.

For the most part I don't use the GUI to manage the configs. If I had, I'd have noticed this issue a lot sooner. I was just getting tired of rearranging a bunch of different vhosts to a new service tier via pico.

Ideally, if we made any updated via the GUI it would update the config, keep the symbolic link, and all of our servers are content. No copying of files necessary.

Am I making sense?
 
N

NiteWave

Administrator
#7
#7
much clear now. no experience with cluster, so those questions.

it looks you only need copy one file one time after you update anything through GUI?

assume there are 100 servers in a cluster. Through server 001's admin console, you updated server 001's http_config.xml. then you copy server 001's http_config.xml back to common area /home/lsws/httpd_config.xml. server 002-100 needn't change anything. since their lsws/conf/http_config.xml still symbol linked to /home/lsws/httpd_config.xml

so the overhead is only 1 copy, not 100.
 
A

Atticus

Active Member
#8
#8
I am aware of this, but you assume that I would only ever use one server to make changes. If I'm looking for a particular server's status I would login to the GUI on that server. Changes might be made from that location. I would know enough to correct the issue that this creates, but someone else might not. Even then, quick fixes and changes made from [for example] a mobile phone or a friend's computer would become a problem due to firewall restrictions relating to the required SSH access.

You are completely correct in your assertion, however. I like making things work with as few steps as are possible. In this case, I'm ultimately trying to make it fool proof. It would be a real pain if one of my junior techs logged into www4, made some changes, and then completely forgets that this bombs the symbolic link on the config. A mistake like that could be so minuscule and isolated that it might go unnoticed for days by everyone and everything except our viewers. In an HA environment, that is unacceptable.

I had noticed over the past week or so that the config file was being deleted first rather than overwritten. But this was only happening on my www2 server (the server I normally access the GUI from when necessary). Today it finally dawned on me what was happening as I managed to fubar my rearranging of config files while trying to fix the symbolic link again. I went back into the GUI to make the changes quickly and it happened again.

To support a symbolic link on /conf/ rather than /conf/httpd_config.xml the naming scheme of the license file would need to be changed or the license file structure itself changed to an array to support multiple keys tied to server hostname, for example. The alternative is for Litespeed to recognize the symbolic link on httpd_conf.xml and follow that to the correct file it should be working with. As it stands, I imagine that any of those would be a far stretch for a new feature.
 
Last edited:
You must log in or register to reply here.
Top