FreeVSD FAQ by Ben Kennish

This FAQ is being hosted on Fubra Ltd's server @ freevsd.fubra.com

INDEX



INSTALLING / GENERAL

Back to top

(Q) Where do I get FreeVSD from?

(A) Read everything at www.freevsd.org then go to ftp://ftp.freevsd.org/freevsd/ and go to the RPMs folder or the SOURCES folder for whichever you want.


(Q) How do I install FreeVSD?

(A) RTFM! - that's F for "Fine" BTW ;-) But seriously, check out /usr/share/freevsd/docs (/usr/local/share/freevsd/docs if you installed from source) before you do anything else. Note that it's recommended that you install FreeVSD into a fresh install of RedHat with the "Server" option selected. Also, you should allocate loads of space to the partition that will contain /home as this is (by default) where you skel and virtual servers will be stored. Finally, make sure that you install the freevsd-pkgs RPM after you install the standard freevsd RPM (or you build it from source.) This will ensure that the

$add_ons = "/usr/share/freevsd/pkgs"

line is at the bottom of your freevsd.conf (paranoid types (like me) will want to check anyway.) NB: If your installing from source, you might want the above to be /usr/local/share/freevsd/pkgs - just check where your packages are (rpm -q -l freevsd-pkgs.)


(Q) Where's all the documentation?

(A) Try /usr/doc/freevsd-xxxx (or /usr/local/docs/freevsd-xxx if installed from source)


(Q) Is FreeVSD supported on XXX distribution as well as RedHat

(A) Quick Answer: No. However, work is currently in progress in porting it over to other popular distributions (e.g. Debian, Mandrake) and even in creating compact distributions especially for FreeVSD. Keep your eyes peeled!


(Q) Which versions of RedHat are supported?

(A) Redhat 6.2 is officially supported. Also, I have managed to get version 1.4.10 (from CVS) running on RH7.2 successfully.


(Q) Can I get my source install to install to the same place as the RPM install?

(A) Yes you can. Follow the instructions for installing from source as usual but when you do the ./configure bit, do the following ...

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-siteconf=./site/linux-redhat --enable-addons=./freevsd-pkgs

Now carry on with "make" and "make install" and it should've worked. Oh and don't forget to install the pkgs RPM (making sure that the '$add_ons = "/usr/share/freevsd/pkgs"' line is in freevsd.conf!


(Q) What is freevsd-pkgs all about?

(A) This is an RPM of RPMs. Literally! :)

It contains RPM files for core components such as glibc, sh-utils, util-linux etc that do not work correctly or at all with freeVSD unless they are patched.

For example, certain system binaries need to run suexec root to give the 'admin' user psuedo root priviledges. Other packages try to retrieve the hostname from the kernel and of course, this will contain the hosting server's hostname and not that of the VS. So these are patched to take the hostname from the /etc/FQDN file instead.

Generally, you will know if an RPM has been patched to work for FreeVSD as it should end with 'vsd'.


(Q) What are all these RPMs installed by the freevsd-pkgs RPM? Do I need to install them?

(A) They are installed into the skel by the vsd-genskel.pl script when you create a script. Do you need to install them? No..no..no..no. And no. Yes I made this mistake. And doing so will probably mean you need to reinstall Linux as these RPMs have been specifically patched to work only on a FreeVSD VS. So no then! ;-) Additional: Actually, you can install the openssl* ones on to the host (as recommended in the "Installing with OpenSSL" part of user-guide.txt.)


(Q) I have a freevsd-pkgs RPM but will the RPMs it contains work under RH7.X?

(A) The general rule of thumb is to make sure that the version numbers for each vsd RPM is greater than or equal to the version numbers for those RPMs installed on the host server.

So for example, I'm running RH7.2 with glibc 2.2.4-13. So I need to make sure that the vsd version of the glibc RPM is 2.2.4-13 or higher.

If you want freeVSD patched RPMs for RH7.2, check out this page - Big thanks to Simon Garner for the files.


(Q) How do I use anonymous CVS to retrieve the latest FreeVSD source?

(A) First go into /usr/src. Now run...

cvs -d:pserver:anonymous@cvs.freevsd.org:/usr/local/cvsroot login
(type anonymous as password)
cvs -d:pserver:anonymous@cvs.freevsd.org:/usr/local/cvsroot checkout freevsd
cvs -d:pserver:anonymous@cvs.freevsd.org:/usr/local/cvsroot update -Pd

Note that as is with most CVS versions of any software, its probably not a good idea to use in live environments without considerable testing first (work is continuously in development and there's no guarantees that when you get the source that some features might be broken as Idaya work on others.) Instead you should use the latest stable release from standard FTP.


SKELS

Back to top

(Q) So what's all this skel stuff then?

(A) Well if you read the documentation at www.freevsd.org fully then you'd know wouldn't you?! ;-) Skels are templates for virtual servers. As of version 1.4.8 (I think), FreeVSD handles having multiple skels and being able to choose which you use on a per-VS basis. The skels are typically stored in /home/vsd/skel/x where x is the name of the skel. Each VS starts its life as an identical copy of the skel on which it is based. The only difference is that when a VS is created the config files in the skel are scanned for #HOSTNAME#, #BINDADDR# and this is replaced with the FQDN and IP address of the VS respectively (see /home/vsd/skel/default/etc/httpd/conf/httpd.conf for an example.) Also, some files are hard-linked into the skel (ie the skel file and the VS files are one and the same part of the hard disk) whereas other files (like those in /etc/) are just copied from the skel to the VS at VS-creation time.


(Q) Should I use a prebuilt skel or build my own?

(A) It depends. If you want to incorporate a daemon that's not included with one of the prebuilt skels then its probably better to create your own. The alternative is to use a prebuilt one and then copy the extra files to get the daemon working into the skel. If all your requirements are met by a prebuilt skel then its gonna be a lot easier to use one of those (see the documentation for details on how to do this.)


(Q) What exactly happens when I build a skel?

(A) At each step, files that are already present in the skel are overwritten.


(Q) How do I know what files on a VS are in the skel and what files aren't?

(A) To do this, you need to scan for files (not directories) with an inode count greater than 1. This can be achieved using the following command....

find /home/vsd/ -links +1 ! -type d ! -type l -printf "%i\t%n\t%p\n" | sort

Replace /home/vsd/ with wherever you would like to start searching from. This will display each hard link file with its inode number first, then the inode count and finally the filename. The "| sort" bit sorts the output so that files with the same inode number are displayed next to each other (files with the same inode number are pointing to the same data on the disk.)


(Q) How do I upgrade / install new software into a skel?

(A)


DAEMONS

Back to top

APACHE

Back to top

(Q) Can I get Apache running on the host server as well as the VSs?

(A) Yes you can. But you'll need to make sure that /etc/httpd/conf/http.conf contains...

"Listen (host-servers-ip):80"

To re-enable it at startup (FreeVSD disables it by default) do...

/sbin/chkconfig --add httpd
/sbin/chkconfig --level 345 httpd on


(Q) How do I enable Apache's suexec wrapper?

(A) By default Apache is installed with the suexec wrapper disabled. It is left as an exercise for the administrator to enable it by setting the appropriate permissions.

Prior to creating the skel, fix the permissions with:
chmod 4711 /usr/sbin/suexec

If you have already created the skel, use:
chmod 4711 /path/to/skel/usr/sbin/suexec


(Q) Apache listens on port 8080. How can I get it to listen on port 80?

(A) It is set to listen on 8080 because of the issue described in security.txt. Unless you really need it to listen on port 80, don't worry (vsdredirect should redirect all requests to 80 to 8080.) To get it to start on port 80, you need to modify `rc' and `rc.vsd', located in /usr/share/freevsd/skel-repo/etc.

Add the following lines to rc, just before the `exit 0'.

# Start Apache web server (as root)
httpd_enable="YES"
if [ "${httpd_enable}" = "YES" ]; then
      echo -n 'starting web server: '
      if [ -x "/bin/httpd" ]; then httpd_path="/bin/httpd"; fi
      if [ -x "/usr/sbin/httpd" ]; then httpd_path="/usr/sbin/httpd"; fi
      if [ -x "/usr/libexec/httpd" ]; then httpd_path="/usr/libexec/httpd"; fi
      ${httpd_path} -D SSL &
      echo 'httpd'
fi


Then comment out the following lines in rc.vsd:

# Start Apache web server
if [ "${httpd_enable}" = "YES" ]; then
      echo -n 'starting web server: '
      if [ -x "/bin/httpd" ]; then httpd_path="/bin/httpd"; fi
      if [ -x "/usr/sbin/httpd" ]; then httpd_path="/usr/sbin/httpd"; fi
      if [ -x "/usr/libexec/httpd" ]; then httpd_path="/usr/libexec/httpd"; fi
      su - web -c "${httpd_path} -D SSL" &
      echo 'httpd'
fi


Once you have done that, delete your virtual servers, re-create the skel (using vsd-genskel.pl) and re-create your virtual servers

NB: Please read the next question for more info on port 80 and 8080...


(Q) I don't mind Apache listening on Port 8080 and using some form of redirection mechanism from port 80 to 8080 but when I goto http://myvirtualserver/folder on the web site, the address bar changes to http://myvirtualserver:8080/folder/. Is there a way to stop this?

(A) Yes there is and, thanks to Bill Brigden, here is how you do it....

You need to put "Port 80" in each <VirtualHost> directive. Apache will continue to listen on port 8080 but when you dont type the '/' on the end of directories, you dont see the ":8080". It will look something like this...

<Virtualhost example.com>
Servername example.com
Documentroot /home/example
Port 80
</Virtualhost>


(Q) Hey! How come my web logs always show the IP address of the person requesting a document to be that of the local machine?

(A) Quote from Tim Sellar:

-------------------------

"With regard to vsdredirect, here is some background:

Running the Apache processes as root raises security issues in that it makes certain root exploits possible. However, if the process does not run as root, it is unable to allocate ports < 1024. Instead we make it allocate the ports 8080 and 8443 and use vsdredirect to carry out simple port redirection. Unfortunately, this means that some of the original ip-packet information is lost. This can be seen in the problems with HTTPS and the fact that Apache logs will show the connection ip address as being the local machine rather than the actual connecting client. In order to resolve this problem you need to be carrying out a much more sophisticated ip masquerading rather then simple port redirection and this requires serious programming at a very low (kernel) level. I don't believe this is practical. We have investigated the problem that logging is affected and there is no simple solution. Defaulting to an ipchains solution for port redirection simply does not work on 2.2.x kernels. It results in all HTTP requests being redirected to the first configured virtual server, which is no use at all.

I see the following options:

i) Allow Apache to start-up with root privilege and allocate ports 80 and 443 - Not good.

ii) Make do with limitations imposed under the current kernel and use vsdredirect - (only practical if you do not need HTTPS or accurate Apache logs)

iii) Upgrade your kernel to 2.4 and utilise iptables to carry out the redirection - (incidentally upgrading to kernel 2.4 potentially removes the problem anyway because process capabilities would allow Apache to be started with only sufficient privilege to allocate port < 1024, without being given all the other root privileges)

We default to using vsdredirect because it is presently the most reliable method of providing the necessary port redirection and works on both 2.2.x kernels (RH6.x) and 2.4.x kernels.

A possible workaround, recently discovered by Jimmy Koerting, is to redirect to a different port on every virtual server. ie. 8080 on vsone, 8081 on vstwo, 8082 on vsthree, etc.. I believe this has the problem that the Apache configuration within each vs must be ammended accordingly and could get complicated when virtual servers are created/deleted/migrated. I think this will provide a better, if less elegant solution, than vsdredirect and may become the default method. Given that workarounds exist, this has not been made a priority. If there are sufficient calls for it to be done, we could probably prioritise the work."

-------------------------

As Tim mentions, you can allocate a different port to each VS if using ipchains. Damion Parry sent me the following:

-------------------------

"If you are using the Linux 2.2 kernel an alternative arrangement using ipchains involves establishing a rule for each virtual server, so that both TCP and UDP packets are forwarded to a unique port number for each virtual server. For example, your first virtual server on IP address 1.2.3.4 would require the following commands:

    # ipchains -A input --dst 1.2.3.4 --dport 80 -p tcp -j REDIRECT 8081
    # ipchains -A input --dst 1.2.3.4 --dport 80 -p udp -j REDIRECT 8081

The default httpd configuation file /etc/httpd/conf/httpd.conf within the virtual server must then be modified to set the Port and Listening directives as follows:

Port 8081
Listen 8081

Please note the lack of an IP address in the 'Listen' directive. Finally, the relevant entries for vsdredirect should be removed from /etc/rc (on the virtual server.)

This process must be repeated for each virtual server although the chosen HTTP port (8081 in this case) must be unique for each VS

For example, the second virtual server, with IP address 1.2.3.5 would require the following commands (if you chose 8082 as its HTTP port) :

# ipchains -A input --dst 1.2.3.5 --dport 80 -p tcp -j REDIRECT 8082
# ipchains -A input --dst 1.2.3.5 --dport 80 -p udp -j REDIRECT 8082

And the following entries then need to be set in /etc/httpd/conf/httpd.conf (on the VS)

Port 8082
Listen 8082

Again, the relevant entries for vsdredirect should be removed from /etc/rc."

-------------------------

So there you have it! Another possible option is to run Apache as an inetd (xinetd on RH7 +) daemon. Thanks to Simon Garner for the following...

-------------------------

"There are pros and cons to this; it makes things more secure in some ways -- users cannot change the IP/port their Apache runs on, Apache runs totally non-root (so in a VSD you wouldn't need any port redirection). But it makes HTTP requests slower (your server has to spawn a brand new httpd process for every connection) and less scalable (each httpd process does not know about the existence of any others -- there's no pool size regulation, so you have to rely on your [x]inetd configuration to limit connections.

For hosting low traffic sites inetd mode may be a good option, although in newer versions of Apache it is deprecated (which suggests to me it is probably not tested well -- so beware of security issues etc.)."

-------------------------

Finally, here is the basic lines required to get it working if you have iptables up and running.....

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p udp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
iptables -t nat -A PREROUTING -p udp --dport 443 -j REDIRECT --to-port 8443

NB: This will also cause port 80 requests to the host server to be redirected to port 8080 so it will be necessary to ensure that the host server's Apache is listening on port 8080 instead.


MySQL

Back to top

(Q) How do I use MySQL within the virtual server (building my own skel.)

(A) Carry out the following steps...

Now edit /etc/freevsd.conf so that the @usr_sbin_progs array contains 'mysqld' (to make sure it copies the MySQL daemon across)...

Then edit /usr/share/freevsd/skel-repo/etc/rc.vsd and add the following lines:

# Start MySQL server
if [ "${mysql_enable}" = "YES" ]; then
      if [ ! -d "/var/lib/mysql" ]; then
            echo 'Initilializing MySQL Database'
            /usr/sbin/useradd -d /var/lib/mysql mysql
            su - mysql -c "/usr/bin/mysql_install_db"
            echo 'Database Initialised'
      fi
      if [ -d "/var/lib/mysql" ]; then
            echo -n 'Starting MySQL Server: '
            su - mysql -c "/usr/bin/safe_mysqld --bind-address=`hostname -i`">/dev/null 2>&1 &
            echo 'mysqld'
      fi
fi


Thanks go to Bill Brigden for the additional 'Initializing MySQL Database' bit.

Then add the following lines to the following file:
/usr/share/freevsd/skel-repo/etc/rc.conf.

# Set to YES to enable MySQL
mysql_enable="YES"


Now create your skel, and your virtual servers.




(Q) Why isn't MySQL working with this pre-built skel?

(A) Probably because you need to run mysql_install_db on the VS (it is in the skel.) Some of the log files that MySQL uses are named after the server it is running and so obviously, these files cant be put in the skel. Run mysql_install_db after bevs -r <vs>. Also, look out for Nigel (Father Christmas) Marett's autoconfigure skel (coming soon!)


PHP

Back to top

(Q) So how do I get PHP working?

(A) Like most things, the first thing to try is installing it on the host server and checking it works there before you build your skel. However, you'll need to manually copy /etc/php.ini to /usr/share/freevsd/skel-repo/etc and edit /usr/share/freevsd/skel-repo/etc/httpd/conf so it's got the relevant PHP directives (look through your host's httpd.conf to see what needs to be added.) Now when you build a skel, all should be OK.


PostgreSQL

Back to top

(Q) How do I use PostgreSQL within the virtual server.

(A) First, install PostgreSQL onto the hosting server.

Edit the /usr/share/freevsd/skel-repo/etc/rc.vsd by adding the following lines:

# Start PostgreSQL server
if [ "${postgresql_enable}" = "YES" ]; then
      if [ -d "/var/lib/postgres" ]; then
            echo -n 'starting postgresql server: '
            (postmaster -D /var/lib/postgres -p ${postgresql_port} -B 256 2>&1 | logger -p local5.notice) &
            echo 'postgres'
      fi
fi


Add the following to /usr/share/freevsd/skel-repo/etc/rc.conf:

# Set to YES to enable PostgreSQL
postgresql_enable="NO"
postgresql_port=NONE


Finally, rebuild your skel, and re-create your virtual servers.

Each VS that wants a PostgreSQL database must be given a unique port number, by editing /etc/rc.conf in the VS *after* it has been created.

Postgres generates shared memory mappings based on it's port number. Two Postgres databases cannot run on the same server on the same port because their shared memory key ids will clash.


ERROR MESSAGES

Back to top

(Q) Apparently, I don't have permission to xxx with a VS. How do I stop this?

(A) The various permissions (named things like login, mail, telnet ...) and who has them are in the text file /etc/vsd/priv on each VS (normally administered with "listrights" and "setrights".) By default the admin starts with all permissions except login. The login permission allows that user to give / take away the telnet permission to/from other users and also to login with SSH. To change it so that you only need telnet permission to use SSH (personally, I can't see why SSH is any different to telnet apart from increased security!), edit (as root on virtual server (bevs -r <vs>)) /etc/pam.d/sshd so that the priv=login is changed to priv=telnet so it ends up like ...

auth     required     /lib/security/pam_vsd.so priv=telnet


(Q) When doing (s)vsdadm vs_create localhost ... I get -ERR Virtual Server does not exist!

(A) That's because you're using v1.4.8+ of FreeVSD which now needs the hostname of your host server rather than localhost. To check what one to use, check out /home/vsd/ with ls -l and find the one that's a symbolic link to the root directory. Oh and do 'hostname' and make sure that this returns the same as that link and that this is the first entry after your IP in /etc/hosts. It's recommended that you use the FQDN of your machine in both places. To set the hostname returned by 'hostname' you simply type 'hostname (hostname)'. NB: To set this permenantly, change the HOSTNAME entry in /etc/sysconfig/network.


(Q) I try to create a virtual server using (s)vsdadm vs_create xxx ... and I get the error: "connection to xxx could not be established: Connection refused".

(A) This means that more than likely the freeVSD daemon is not running. Type...

netstat -lt | egrep "*:s?vsd"

and if you don't get an entry, freeVSD isn't running properly. Ensure that you have run vsd-install as this should setup (x)inetd properly for you.

If you get an 'svsd' entry with the above command, you are currently running the SSL enabled version of FreeVSD and need to use "svsdadm", whereas if you get a 'vsd' entry, you are running the plaintext version and need to use "vsdadm".

NOTE: If you are running the plaintext version, you must ensure that connections to port 1725 are only permitted by "localhost" (and any other machine authorised to administer your host server.) You can either do this through your firewall or, if you are using xinetd, you can add a line like this to xinetd.conf...

only_from = 127.0.0.1/32

Put the above line in the "service vsd { }" section of the file. Yet more thanks to Bill Brigden for this hint.


(Q) When I run vsboot --start, I get the error: "SIOCSIFFLAGS: Cannot assign requested address".

(A) You are trying to start a virtual server that is already running. vsboot is trying to set an IP alias on the interface, but the alias already exists. Either ensure your VS is stopped prior to starting it, or use `vsboot --restart' instead.


(Q) Whats all this "bind() : Address already in use" stuff?

(A) This is a known issue and is caused when you reboot a VS without pausing to wait for bind to let go of the IP address (e.g. vsboot --restart.) Bind doesn't let go of the IP quick enough and you try to get it to attach to the same IP when the VS starts again - its already being held by bind.

Solution: Use rebootvs on a VS to reboot instead or do "vsboot --stop" wait for around 30 seconds before "vsboot --start"


(Q) I run vsboot --start and get errors like: "/etc/rc: rm: command not found" and "/etc/rc: su: command not found" or "no such file or directory." What gives?

(A) You haven't installed the freevsd-pkgs RPM (or you installed it before the freevsd RPM and not after. This RPM contains a number of patched vital files (such as the rm and su binaries and glibc) that will override the ones installed on the host server. Without these RPMs, vsd-genskel.pl will just use the standard ones installed on your host server that have not been patched to work in a VS and hence will not work. To sort all this out, download and install the pkgs RPM, ensure that the line $add_ons='/usr/share/freevsd/pkgs'; is in your freevsd.conf, delete all virtual servers and re-generate the skel.


(Q) When I try to use XXX service on a VS, it appears I'm actually using the one on the host server. What's going on?

(A) Well, the relevant daemon on the host is listening on the default IP address' (i.e. all) port and so is interrupting it before it can be taken by FreeVSD (specifically virtuald) into the VS. You can check this by typing netstat --numeric-hosts -lt on the host server (0.0.0.0 means all IP addresses) and looking out for the right port. You'll need to either stop the daemon on the host server (if it's not necessary) or ensure that it's configured to only listen on the IP address of your host server.


QUOTAS

Back to top

(Q) Running vsd-vsbatch.pl returns the following error: "error: -ERR Could not set quota stats".

(A) You have tried to create a virtual server with a disk quota limit however you haven't set up your filesystem for user/group quota support. Read the Quotas section in the INSTALL document to find out how to do this. NB: You might not get this message but if quotas don't seem to work, following the INSTALL should be your first point of call.

I know HOWTOquotas.txt talks of recompiling your kernel but it wasn't necessary for me. If you still can't get quotas working, you'd better follow HOWTOquotas.txt properly.


(Q) Total quota allocated to all users on a VS seems to exceed the total for the VS itself!

(A) By default, FreeVSD gives the following user quotas out whenever quotas are enabled for a VS...

ftp - 4k
web - 4096k
mail - 4k
admin - 10,240k

So if you allocate a VS less than 14344k (a little over 14MB), then you'll need to set quota for each user manually using "(s)vsdadm quota_userset ...".


TOOLS AND EXTRAS

Back to top

(Q) Is there a 'prettier', easier way for my clients to Administrate their VSs?

(A) You could try the VSDWebAdmin scripts. They can be found here. To use them, you'll need to install them to a server (even a VS if you want - thanks Paul) with Apache, PHP, MySQL and mod_auth_mysql (click here for an RPM for mod_auth_mysql) all up and running. If you're installing to the host server, make sure the daemons are set up not to break your VSs (read section above on DAEMONS.)


(Q) But I don't wanna install mod_auth_mysql - I've got mod_php for Apache and mysql.so for PHP so why should I?

(A) OK then. Try the vsdadmauth.phtml file posted by Ross McKillop to the mailing list. Click here to view the source inc. instructions for how to get it up and running. Please post any queries on this to him and not me as I've never used it!


(Q) I've got problems with these VSDWebAdmin scripts. What am I doing wrong?

(A) Try these...


(Q) What about a Windows program?

(A) Get VSD Client. Where can you get it? Erm, not too sure actually. It's on the Idaya CD if you fancy buying it but Im not sure where else you can download it. :S Note however that by default, the program attempts to connect with SSL. If you haven't installed FreeVSD with SSL support, you'll need to start the client like this...

vsdclient.exe -NOSSL

A bit disturbed that any old person could administrate all your VSs from anywhere? You should be! Read security.txt (why haven't you already ;-) ) in /usr/share/freevsd/docs and follow the instructions in there.


(Q) Is there any rebrandable documentation that I can modify to provide our clients with?

(A) There sure is! And although I have a copy of the Word doc, I am not sure whether Idaya would like me giving it out? Idaya?


OTHER

Back to top

(Q) Where the hell is the /etc/rc.d directory on my VS?

(A) It isn't there. FreeVSD runs the /etc/rc script as root on the startup/reboot of a VS and /etc/rc.vsd script as admin. Generally, you'll want to edit /etc/rc.vsd on a VS if you want to change something on startup. Those variables that you see mentionned (e.g. $httpd_startup) are set in /etc/rc.conf and you can make your own to allow your client easy ability to enable/disable features.

Note from Bill Brigden:

"It's a good idea to make the /etc/rc.conf file owned by root to stop users from enabling services if they arent allowed (same goes for /etc/rc.vsd and /etc/rc obviously)"




(Q) Do I need a valid IP address for each VS?

(A) Short answer: Yes. This is the way that FreeVSD works and will probably always be the way that FreeVSD will work. Live with it! ;-)


(Q) HELP! vsd-refreshskel.pl just wrecked my skel!

(A) Quote from Tim Sellar:

--------------------

"vsd-refreshskel.pl should be used with extreme caution. Expect to have to do some tinkering for it to match your installation situation. It basically 'syncs' the contents of the skel with the software installed on the hosting server and then does the necessary re-linking into all the virtual servers (which must have been stopped). It does the same as deleting your skel and then executing vsd-genskel.pl but, crucially, it doesn't require you to then recreate all your virtual servers. The problems arise because of the difference between some packages on the hosting server and within the skel. If the vsd-specific skel versions are over-written (the code attempts to ensure this doesn't happen) it will break all your virtual servers and you will have fix things manually. "

--------------------

You have been warned... ;-)


(Q) What is the maximum number of virtual servers that can run on a Linux box?

(A) Approximately 250. Linux imposes a limit of 255 mounted partitions. For each running virtual server, the pseudo-filesystem /proc must be mounted, which counts as one partition per-VS. The final five partitions are likely to be used by your system disk, and the mounting of hard disks for hosting the VSes.


(Q) How do I change what the VS users see when they log on?

(A) This is a Linux thing not a FreeVSD thing! But as you asked...

/etc/issue.net on the VS is outputted to the screen before a successful login.
/etc/motd on the VS is outputted to the screen after a successful login.


(Q) So just how do I monitor bandwidth on these VSs? BWLimit and BWBurst in vsd.conf don't work!

(A) They're not intended to 'work'. They're there for use by any external scripts you care to write. One way to monitor bandwidth is using "ipchains" or "iptables" on the host server. This is how todo it using "ipchains"...

/sbin/ipchains -N [vsname]
/sbin/ipchains -I input -j [vsname]
/sbin/ipchains -I output -j [vsname]
/sbin/ipchains -A [vsname] -s [vsip]/255.255.255.255 -p all
/sbin/ipchains -A [vsname] -d [vsip]/255.255.255.255 -p all


Replacing [vsname] with the name of a VS and [vsip] with its IP address.

"/sbin/ipchains -L [vsname] -v" will now give you info on bytes in/out since the chain was created (you can output this to a script or whatever.)
"/sbin/ipchains -Z [vsname]" will reset the counter to zero.

Everytime ipchains is shutdown (e.g. rebooting host server) the info will be lost so you better make sure your scripts account for this! Alternatively, check this out.



Author: Ben Kennish - Fubra Ltd
Author's Homepage: Ben Kennish's Web Site
Last Updated: 15th July 2002

If you've got any further questions (after reading the WHOLE of the FreeVSD documentation and this FAQ, try searching the FreeVSD mailing list archives by clicking here. If you still can't solve it, why not join the mailing list here? If you've got something that you think should be added to the FAQ, please feel free to mail me it and I'll put it in!

Thanks to Idaya for making FreeVSD.

Thanks to whoever wrote the original faq.txt (from which most of this file was written!)

Thanks to everyone who helped me on the freevsd-support@freevsd.org mailing list (esp. Damion, Nick, Nigel, Tim, Kevin and Zen and anyone else I've forgotten.)

Oh and a big thanks to my boss (Brendan) for letting me play LAN HalfLife / Counter-Strike at lunch times. :-)



Back to top




This document is copyright Ben Kennish (c) 2002.