Relocating an Apache DocumentRoot under Selinux

Selinux works pretty well straight out of the box, but I have learnt that when application reconfigurations mysteriously result in failures to startup – then Selinux is generally the culprit. In particular, if any file locations are customised from what’s installed, Selinux will lock it down, and for the uninitiated, the debugging process can be quite confusing. Apache webserver (HTTPD) provides a good example of what happens in this scenario, and I’ll demonstrate how to make it work with the Document Root in a different location.

Selinux can be distinctly daunting for Linux sysadmins, and often seems to be more trouble than it’s worth. However it is an extremely powerful tool which increases security and encourages rigour in configuration. Essentially, Selinux augments the usual Unix file permissions and ownership by adding more granular application-specific contexts as well. I won’t go into the details here, as it’s well documented elsewhere.

What I’ll aim to show here is two ways for relocating the Apache DocumentRoot directory – the proper way, and a quicker dirtier way.

Say, you decide to situate the Apache webserver root under /home/apache/www instead of the default /var/www/html. You edit the /etc/httpd/conf/httpd.conf and change the DocumentRoot line to:

DocumentRoot /home/apache/www

Copy your HTML files into place, change the directory and file onwerships, and permissions:

# chown -R apache. /home/apache/www
# chmod 755 /home/apache/www
# chmod 644 /home/apache/www/*

(NB: That’s not a typo – you can type “apache.”, with the dot at the end, in chown rather than “apache:apache” and save yourself a few keystrokes).

Restart httpd to make sure, and browse to your web page. You’ll get something like this in your browser:

You don't have permission to access / on this server.

And in /var/log/httpd/error_log:

[client] (13)Permission denied: access to /index.html denied

This is because the Apache back-end process, running as user “apache”, can’t access the file /home/apache/www/index.html – even though we granted all the correct permissions. What gives? Turns out, with Selinux, having regular old permissions and ownership isn’t enough.

Here’s how you can fix this, nice and quickly.

First things first, check that you’ve got Selinux running, and that this is in fact the source of your problem:

  # getenforce

Yep. Next, check the Selinux context of the original HTTPD DocumentRoot directory. The ls command has the “-Z” switch which displays this:

# ls -ldZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Take note of the colon-delimited string “system_u:object_r:httpd_sys_content_t:s0″. Take note of this string; you’ll need it later. Each field is:

  • User: system_u
  • Role: object_r
  • Type: httpd_sys_content_t
  • Level: s0

Checking the Selinux context on our new erroneously configured folder, we see this:

# ls -Z file1
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /home/apache/www

So this explains why Apache can’t read the index.html file – it’s got the wrong Selinux context for Apache to read it. You can see how this enhances security. Apache can never server up a page unless it has explicitly got a context set that matches Apache privilege.

To reset the directory and file contexts, you need to ensure that the semanage software is installed (it may not be, depending on what package groups you have):

  # yum whatprovides */semanage
  # yum -y install policycoreutils-python

A very full discussion of how to change Selinux policies and file contexts is given here, but briefly, the steps are:

  # semanage fcontext -a -t httpd_sys_content_t "/home/apache/(/.*)?"
  # restorecon -Rv /home/apache
restorecon reset /home/apache context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /home/apache/www context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /home/apache/www/index.html context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0

The semanage argument “/home/apache/(/.*)?” is a regular expression indicating the context should apply to the directory “/home/apache” and everything under it. Yes you need to do this for the home directory as that stays in user_sys_content. Unless you change that the https will still complain.

Quick and Dirty Fix
If, however you don’t have access to the semanage program or if you just need to make a small ad hoc change to a file context, you can simply set this manually. Remember that string coloured red earlier? Grab the relevant text from it.

  # chcon -R -u system_u -t httpd_sys_content_t /home/apache/

This command uses the “-R” switch so will apply recursively to all files under the directory. Note that the difference between this command and the semanage command is that chcon will not update the Selinux policy.

So the proof of the pudding will be in the reloading. Ctrl-R your browser and BOOM! Your page is back and being happily server up.


How To Set Up GitLab As Your Very Own Private GitHub Clone


Git and GitHub are awesome tools that make managing and administering lots of Git repositories and their associated permissions a breeze. This is wonderful if you’re writing open source software, but when writing closed source software you may not want to trust your code to a third party server. So how can you get the control, flexibility and ease of use of something like Github or BitBucket without hosting your git repositories on servers outside of your control?

Enter GitLab. GitLab provides a simple but powerful web based interface to your Git repositories a la GitHub, only you can host it on your own cloud server, control access as you see fit, and repo size is limited only by how much storage space your server has. This tutorial will walk you through setting up a DigitalOcean VPS as a GitLab server.

It assumes you’re using a brand new Ubuntu 12.04 VPS. We’ll be installing all the necessary software needed to make GitLab work. If you are using an existing VPS (droplet) or a different Linux distro you may have issues, especially with incompatible Python and Ruby versions. Make sure you have Ruby 2.0 and Python 2.7 installed before beginning.

The first step is to install some required packages:

sudo apt-get update
sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl git-core openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev

Make sure you don’t have Ruby 1.8 installed (on a default Ubuntu 12.04 VPS it won’t be).

Install Ruby 2.0 (this will take a while):

mkdir /tmp/ruby && cd /tmp/ruby
curl --progress | tar xz
cd ruby-2.0.0-p247
sudo make install

When it’s finished you can check to make sure that you have Ruby 2 (not 1.8) installed by doing a:

ruby --version

If the output looks like the below then you’re good:

ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Now we need to install the Bundler gem:

sudo gem install bundler --no-ri --no-rdoc

And create a git user for GitLab to use:

sudo adduser --disabled-login --gecos 'GitLab' git

Installing the GitLab Shell

Download the GitLab shell with the following commands:

cd /home/git
sudo -u git -H git clone
cd gitlab-shell
sudo -u git -H git checkout v1.7.0
sudo -u git -H cp config.yml.example config.yml

You now have a copy of GitLab Shell 1.7.0, and the example config.yml is ready to go.

If you have a domain name pointed at this VPS, then you should take the time to editconfig.yml to use this domain.

nano config.yml

Near the top there will be a line that looks like:

gitlab_url: "http://localhost/"

Change the http://localhost/ portion to match your domain name. So if your domain is the line should look like this:

gitlab_url: ""

Now you can run the GitLab shell installer:

sudo -u git -H ./bin/install

Database Setup

We’ll set up GitLab to use a MySQL backend. The first step is to install MySQL with the below command. During the install process it will ask you to set a MySQL root password. Set it to whatever you like, but note it down as you will need it for the next steps.

sudo apt-get install -y mysql-server mysql-client libmysqlclient-dev

MySQL is now installed and the root password is set to the value you chose in the last step. We now need to create a MySQL user for GitLab to use. To do this we’ll first save the necessary SQL queries to a temporary file. Type:

nano tempfile


Paste in the following, changing the $password on the first line to a real password. Keep track of this password as this will be your GitLab’s database password.

CREATE USER 'gitlab'@'localhost' IDENTIFIED BY '$password';
CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'gitlab'@'localhost';

Now save the file and execute the following command (entering your MySQL root password from the first step at the prompt) to have MySQL execute your queries:

cat tempfile | mysql -u root -p

To make sure your new MySQL user was created successfully let’s log in to mysql using thegitlab user:

mysql -u gitlab -p

If you see some text followed by a:


line then everything worked successfully. Go ahead and type:



at the mysql> prompt to exit MySQL, and delete the tempfile file since it contains a password:

rm tempfile


At this point we have everything configured to install GitLab successfully, so let’s proceed with the installation:

cd /home/git
sudo -u git -H git clone gitlab
cd /home/git/gitlab
sudo -u git -H git checkout 6-0-stable
sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml


Just like we did with the GitLab shell set up, if you have a domain configured for your VPS we need to edit the config.yml to use that domain.

sudo -u git -H nano config/gitlab.yml


Near the top of the file you should a text block that looks like the following:

## Web server settings
host: localhost
port: 80
https: false


Change the host: entry to match your domain name. If your domain is, then it should look like this:

## Web server settings
port: 80
https: false


Let’s also set some linux file permissions, configure the git user’s Git config, and set up some GitLab config and directories for the git user:

cd /home/git/gitlab
sudo chown -R git log/
sudo chown -R git tmp/
sudo chmod -R u+rwX  log/
sudo chmod -R u+rwX  tmp/
sudo -u git -H mkdir /home/git/gitlab-satellites
sudo -u git -H mkdir tmp/pids/
sudo -u git -H mkdir tmp/sockets/
sudo chmod -R u+rwX  tmp/pids/
sudo chmod -R u+rwX  tmp/sockets/
sudo -u git -H mkdir public/uploads
sudo chmod -R u+rwX  public/uploads
sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb
sudo -u git -H git config --global "GitLab"
sudo -u git -H git config --global "gitlab@localhost"
sudo -u git -H git config --global core.autocrlf input
sudo -u git cp config/database.yml.mysql config/database.yml


Now we need to tell GitLab to use the gitlab MySQL user we set up earlier. To do this, edit the config/database.yml file:

sudo -u git -H nano config/database.yml


Near the top there will be a section called production: which will contain username andpassword entries. By default it looks like this:

  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_production
  pool: 10
  username: root
  password: "secure password"


Change the username and password entries to match the GitLab database user we set up earlier. So if the password you used for your GitLab MySQL user was $password the edited file should look like this:

  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_production
  pool: 10
  username: gitlab
  password: "$password"


Save the file, and we’ll secure it so that other users of the server can’t see the password:

sudo -u git -H chmod o-rwx config/database.yml


Let’s install a few more needed gems (this step may take awhile):

cd /home/git/gitlab
sudo gem install charlock_holmes --version ''
sudo -u git -H bundle install --deployment --without development test postgres aws


And run some final setup (type yes when it asks if you want to continue):

sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production


After this finishes it will print a lot of information onscreen and at the end will showAdministrator account created and give you your administrator credentials. It should look something like the below:

Administrator account created:


Now let’s set GitLab to start up whenever your server boots:

sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
sudo chmod +x /etc/init.d/gitlab
sudo update-rc.d gitlab defaults 21


Run the following to make sure everything is working:

sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production


If there are no error messages and the data outputted by that command looks right then your GitLab install is working. Almost finished! Start up GitLab with this command:

sudo service gitlab start

Setting Up NGINX

GitLab works with the nginx web server by default. If you already have your own web server such as Apache set up then these steps don’t apply. Check out these recipes for info on how to configure GitLab with other web servers. Otherwise follow these directions to install and configure nginx to work with GitLab:

sudo apt-get -y install nginx
cd /home/git/gitlab
sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab


Edit /etc/nginx/sites-available/gitlab to use your domain name:

sudo nano /etc/nginx/sites-available/gitlab


A little ways from the top of the file you will see an entry server_name which is set toYOUR_SERVER_FQDN. As in the previous steps, replace the YOUR_SERVER_FQDN with your domain name. The original file looks like this:

server {
  listen *:80 default_server;     # e.g., listen; In most cases *:80 is a good idea
  server_name YOUR_SERVER_FQDN;       #


If your domain is then you should change it to look like this:

server {
  listen *:80 default_server;         # e.g., listen; In most cases *:80 is a good idea
  server_name;     #


And restart nginx:

sudo service nginx restart


Voila! You’re done. Connect to GitLab via your web browser using the Admin login and password from above (default user:, pass: 5iveL!fe) and enjoy GitLab.

If you are using a 512MB VPS then due to GitLab’s memory requirements it’s quite likely you will run into a 502 Bad Gateway error. If that’s the case, read on…


502 Bad Gateway Error

In a perfect world GitLab would now be running perfectly. Unfortunately, GitLab has surprisingly high memory requirements, so on 512MB VPSs it often chokes on the first sign in. This is because GitLab uses a lot of memory on the very first login. Since the Ubuntu 12.04 VPS has no swap space when the memory is exceeded parts of GitLab get terminated. Needless to say GitLab does not run well when parts of it are being unexpectedly terminated.

The easiest solution is just to allocate more memory to your VPS, at least for the first sign in. If you don’t want to do that, another option is to increase swap space. DigitalOcean already has a full tutorial on how to do this available here (although I would recommend adding more than just 512MB of swap). The quick fix is to run the following:

sudo dd if=/dev/zero of=/swapfile bs=1024 count=1024k
sudo mkswap /swapfile
sudo swapon /swapfile


Your swapfile is now running and active, but to set it so that it’s activated on each boot we need to edit /etc/fstab:

sudo nano /etc/fstab


Paste the following onto the bottom of the file:

/swapfile       none    swap    sw      0       0 


Now restart your VPS:

sudo restart


Wait a minute or two for your VPS to reboot, and then try GitLab again. If it doesn’t work the first time, refresh the Bad Gateway page a couple of times, and you should soon see the GitLab login page.

Install BackupPC on CentOS 6.3

  1. You need to have a running CentOS 6.3. I installed it with minimal components on a VM via Hyper-V 2; “lean but mean” so to say. 
  2. Using Putty, connect to your CentOS box and install these useful tools:
    • wget – an easy-to-use CLI download tool.
    • nano – a file editor for humans.
    • screen – I like this tool because it allows you to have different screens for every task you to do; very useful, it enhances your Putty experience 
    • man – your dependable CLI technical support.

    Use this command yum -y install man nano screen wget

  3. You need to add two special repositories, EPEL and REMI. A number of the packages we need for this endeavor is not part of the Red Hat / CentOS package manifest.
    wget -c
    wget -c
    rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm
  4. Enable the REMI repository.
    nano /etc/yum.repos.d/remi.repo 

    Edit and save the above file to reflect this:

    name=Les RPM de remi pour Enterprise Linux $releasever – $basearch

  5. Install the BackupPC pre-requisites.
    yum -y install perl-Compress-Zlib perl-Archive-Zip perl-File-RsyncP perl-suidperl openssh-clients expect 
  6. Do an update, then upgrade, to make sure everything is up-to-date.
    yum -y update
    yum -y upgrade 
  7. We need to create the user account that BackupPC will use and assign a password for it.
    adduser backuppc
    passwd backuppc 

    You will be prompted to key-in your desired password. Remember this password ’cause you will need it later.

  8. And now folks, the moment you’ve all been waiting for, the BackupPC installation!  
    yum -y install BackupPC 

    I wish the command was longer or better yet, extremely complex but that’s just it… 

  9. After the package installation, two biggies are now in place, Apache and BackupPC. Verify that these services are listed in the startup script.
    chkconfig –list backuppc
    chkconfig –list httpd 

    Notice that both are turned off.

  10. We need to make these two services start at startup. Do this:
    chkconfig backuppc on
    chkconfig httpd on 
  11. You’re probably guessing what’s Apache got to do with BackupPC; well, it runs the web interface but we need to do some tasks before we can use it. We first need to create the access file.
    htpasswd -c /etc/BackupPC/apache.users backuppc 

    You will be prompted for a password; just key-in the password you assigned the backuppc user awhile back.

  12. Edit and save the BackupPC configuration file for Apache.
    nano /etc/httpd/conf.d/BackupPC.conf 

    Your changes should reflect something like this:
    order deny,allow
    deny from all
    #allow from
    #allow from ::1
    allow from all
    AuthType Basic
    AuthUserFile /etc/BackupPC/apache.users
    AuthName “backuppc”

  13. As a safety precaution, make a duplicate of the BackupPC main configuration file.
    cp /etc/BackupPC/ /etc/BackupPC/ 
  14. We’ll use screen to help us accomplish this next task.
    nano /etc/BackupPC/ 

    In nano, press CTRL + W; this will invoke the search facility. Search for this parameter $Conf\{ServerMesgSecret\}.

    Now, press CTRL + A + C; this will open another screen. Run this command:
    mkpasswd -l 32 -d 16

    Highlight the output then press CTRL + A + P; this will bring you back to the previous screen. Right-click your mouse to paste the output between the single quotes of the aforementioned configuration parameter. You should have something like this:
    $Conf{ServerMesgSecret} = ’7687nR848l39etpm7812w1f-pj3iEpb7′;

    Next, search for this parameter $Conf{CgiAdminUsers} and add backuppc. You should have something like this:
    $Conf{CgiAdminUsers} = ‘backuppc’;

  15. This time, edit the Apache configuration file.
    nano /etc/httpd/conf/httpd.conf 

    Changes should reflect these changes:
    User backuppc
    Group apache
    ServerName actual_server_hostname_or_IP_Address:80
    (e.g. ServerName

  16. Now, the secret that made the BackupPC web interface work:
    iptables -I INPUT -p tcp –dport 80 -j ACCEPT
    /sbin/service iptables save 

    Just to make sure the firewall entry was saved, we verify.
    cat /etc/sysconfig/iptables. Result below:

    # Generated by iptables-save v1.4.7 on Mon Oct 15 15:57:49 2012
    :INPUT ACCEPT [0:0]
    :OUTPUT ACCEPT [4:464]
    -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT
    -A INPUT -j REJECT –reject-with icmp-host-prohibited
    -A FORWARD -j REJECT –reject-with icmp-host-prohibited
    # Completed on Mon Oct 17 15:57:49 2012

  17. We now are nearing completion, let’s start the services.
    service httpd start
    service backuppc start 
  18. The finale, access the BackupPC web interface. 


Allowing FTP with IPTables

Here’s the document I refer people to so that they can following the FTP protocol:

  • To do active-mode FTP, you need to allow incoming connections to TCP port 21 and outgoing connections from port 20.
  • To do passive-mode FTP, you need to allow incoming connections to TCP port 21 and incoming connections to a randomly-generated port on the server computer (necessitating using a conntrack module in netfilter)

You don’t have anything re: your OUTPUT chain in your post, so I’ll include that here, too. If your OUTPUT chain is default-drop then this matters.

Add these rules to your iptables configuration:

iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 20 -j ACCEPT

To support passive mode FTP, then, you need to load the ip_conntrack_ftp module on boot. Uncomment and modify the IPTABLES_MODULES line in the /etc/sysconfig/iptables-config file to read:


Save the iptables config and restart iptables.

service iptables save
service iptables restart

To completely rule out VSFTPD as being a problem, stop VSFTPD, verify that it’s not listening on port 21 with a “netstat -a” and then run a :

nc -l 21

This will start netcat listening on port 21 and will echo input to your shell. From another host, TELNET to port 21 of your server and verify that you get a TCP connection and that you see output in the shell when you type in the TELNET connection.

Finally, bring VSFTPD back up, verify that it is listening on port 21, and try to connect again. If the connection to netcat worked then your iptables rules are fine. If the connection to VSFTPD doesn’t work after netcat does then something is wrong w/ your VSFTPD configuration.

Moving to from is very good VPS service which offer good value for money if you are comfortable with command line. In my two years experience with them i had occasional outage. Over all very satisfactory.

Now i m planning to move over to and buy their EX service root server. I hope to utilize my VPS experience to install a Xen Server 5.6 Sp2 on it. Then may be install couple of bunch of VMs to do testing and Dev machines for the consultants,

Automated Install Xenserver Hetzner for EX4S Guest Networking Enabled

Skip to end of metadata

  • Hetzner’s gateway setup requires special network settings (all XenServer releases)
  • the XenServer 5.6 unattended installation has a bug so the installed system will not boot
  • XenServer 5.6 FP1 has a problem with the RealTek 8169 NIC which are used in Hetzner’s servers

This article explains how to circumvent these problems. Some workarounds are needed even when installing from a physical CD (by using Hetzner’s LARA console).

This How-To also works for XenServer 5.61 SP2

Copy contents of the installation CD to a directory on a webserver

Copy the contents of the Citrix XenServer installation CD to a directory on a web server. This directory must be accessible by ip address (in this example it ishttp://, so you might need to set up a default virtual host.

# mount -o loop XenServer-5.6.1-fp1-install-cd.iso /mnt
# cp -a /mnt xenserver

Create answerfile

In the xenserver directory, create a new file xenserver.xml containing the following XML code. Make sure to enter your own hostname, root password, ip address, subnet mask, gateway and name server ip addresses. The source URL is of course the URL to the installation directory you have just created. It must contain the ip address, not the domain name.

<installation mode="fresh" srtype="lvm">
 <primary-disk gueststorage="yes">sda</primary-disk>
 <source type ="url"></source>
 <!-- No Post install scripts configured -->
 <admin-interface name="eth0" proto="static">

Configure new server for unattended installation

The new XenServer host must be initialized with an arbitrary Linux system. Its only purpose is to boot a special XenServer kernel, which in turn will start the actual installation process by downloading the answerfile and the installation packages from the web server.

When installing the Linux system, do not use a software raid. There seems to be a bug in the XenServer 5.6 installer: if the Linux system used to boot the XenServer installer had software raid turned on, the installed XenServer system was corrupt. Files were missing or had binary data in them.

To install the initial Linux system, do the following for a Hetzner root server:

  1. boot the server in the rescue console 

  2. wipe all disks so that they do not have partitions of type 0xfd (Linux raid autodetect):
    # dd if=/dev/zero of=/dev/sda count=256
    # dd if=/dev/zero of=/dev/sdb count=256

    Note that this will destroy all data on your disks. 

  3. install Linux using the installimage command. I was using CentOS 5.5 32bit with good success. Remember to turn off the software raid option, this is done by editing the configuration to SW RAID = 0

  4. After installing Linux, mount the boot partition:
    # mount /dev/sda3 /mnt
    # mount /dev/sda2 /mnt/boot
  5. Replace the file /mnt/boot/grub/menu.lst with the following content:
    timeout 5
    default 0
    title Install Xenserver
    root (hd0,1)
    kernel /boot/xen.gz dom0_mem=752M acpi=off nosmp noapic noirqbalance
    module /boot/vmlinuz answerfile= install
    module /boot/install.img

    Note that the file references the answerfile created earlier. The URL must contain the ip address, a domain name will not work. 

  6. if there is a file grub.conf, copy menu.lst to it 

  7. some files must be copied from the XenServer installation directory into the /boot directory. On the server containing the XenServer installation files (the web server), do the following:
    scp xenserver/install.img xenserver/boot/vmlinuz xenserver/boot/xen.gz newserver.mydomain:/mnt/boot
    root@newserver.mydomain's password: ********
    install.img     100%   26MB  12.9MB/s   00:02
    vmlinuz         100% 2058KB   2.0MB/s   00:00
    xen.gz          100%  585KB 585.2KB/s   00:00
  8. to see whether the XenServer installer actually retrieves the files from the web server, run the tail command:
    # tail -f access_log.2011-04-16-00_00_00  | grep xenserver - - [16/Apr/2011:11:36:11 +0200] "GET /download/xenserver/xenserver.xml HTTP/1.1" 200 871 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-REPOSITORY-LIST HTTP/1.1" 200 21 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-REPOSITORY HTTP/1.1" 404 230 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/XS-PACKAGES HTTP/1.1" 404 228 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages/XS-REPOSITORY HTTP/1.1" 404 239 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages/XS-PACKAGES HTTP/1.1" 404 237 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages.main/XS-REPOSITORY HTTP/1.1" 200 145 "-" "Python-urllib/2.4" - - [16/Apr/2011:11:36:23 +0200] "GET /download/xenserver/packages.main/XS-PACKAGES HTTP/1.1" 200 3720 "-" "Python-urllib/2.4"
  9. if you want to install XenServer 5.5, you can now restart the server. You should see the XenServer installer accessing the installation files a couple of minutes later. After the automatic reboot you should be able to connect to the new server via XenCenter 

  10. if you are installing XenServer 5.6, the configuration must be modified before the reboot. Otherwise XenServer will hang during reboot and there is no chance to log in and fix the settings. therefore the Hetzner rescue system must be set up before the XenServer installation finishes. The easiest way to do this is: log into the Hetzner server administration, restart the server, and right after you see the installer accessing the packages from the web server, turn on the rescue system for this server. This way, when the freshly installed XenServer reboots after the installation has finished, it will boot into the rescue mode. 

  11. in the rescue console, mount the disks again. In the file /etc/rc.sysinit, find the following line and comment it out:
    # [ -x /sbin/nash ] && echo "raidautorun /dev/md0" | nash --quiet
  12. After that, edit /etc/modprobe.conf and add the line
    options r8169 use_dac=1
  13. Finally, reboot. The new XenServer 5.6 FP1 system should now be accessible from XenCenter


7. Makse sure your /etc/sysctl.conf has this :

# Kernel sysctl configuration file for Red Hat Linux


# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and

# sysctl.conf(5) for more details.

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

# Controls proxy arp

net.ipv4.conf.default.proxy_arp = 1

# Turn off redirects

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.lo.send_redirects = 0

net.ipv4.conf.xenbr0.send_redirects = 0

and validated with ’systcl -p’

# sysctl -p

net.ipv4.ip_forward = 1

net.ipv4.conf.default.proxy_arp = 1

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.lo.send_redirects = 0

net.ipv4.conf.xenbr0.send_redirects = 0

net.ipv4.conf.default.rp_filter = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.conf.default.accept_source_route = 0

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

kernel.sysrq = 1

kernel.core_uses_pid = 1

net.ipv4.tcp_syncookies = 1

kernel.msgmnb = 65536

kernel.msgmax = 65536

kernel.shmmax = 4294967295

kernel.shmall = 268435456

vm.dirty_ratio = 5

kernel.printk = 4 4 1 4

8. Disable SeLinux with

# system-config-securitylevel-tui

9. add your additional subnetwork to your xenserver

# ip addr add dev xenbr0

10. shutdown the iptables

# service iptables stop

11. Create Dummy interface as we would use this as gateway for all Guest machine (Linux or Windows)

let say you have this Ip subnet from Hetzner until



HostMin: (this one we would use as gatway for our guesthost)


# nano /etc/sysconfig/network-scripts/ifcfg-xenbr0:1







12. bring our xenguest gateway ip up

#ifup xenbr0:1

13. now you can use this range until