Raskas’ blog

In my Reverse proxy of virtual hosts with apache 2 blog entry I showed how you can configure a reverse proxy. The only limitation is that the internal webserver must be http.

This limitation can be solved with 1 easy configuration line: SSLProxyEngine on.
All configuration lines needed to enable reverse proxy to an internal https servers are:

ProxyRequests off
SSLProxyEngine on
ProxyPass / https://blue.internal.x-tend.be/
ProxyPassReverse / https://blue.internal.x-tend.be/


If you want encryption between the clients on the internet and your proxy you have to configure you vhosts on the proxy to work with https. This doesn’t change anything about the reverse proxy configuration. You can still use both http and https on your internal connection.

Last week I updated my CentOS base image document.
One important change was in the yum line.

Previously it would do a groupinstall of Base, which results in a total of 300 packages. This is the same amount of packages when it is installed from cd and minimal install is checked.
But this minimal install includes way to much and useless packages like pcmcia, irda, isdn, …
The groupinstall of Core gives a better result. Now only a bit more than 100 packages are installed. Even yum or openssh aren’t installed. So you will have to add some extra packages but at least you’re not stuck with all those unused packages and running services.

The same happens when you kickstart. By default it will install the base and core groups. But again this results in 300 packages. Just mentioning core or not mentioning base in the packages section doesn’t solve the problem.
Luckily there is an, undocumented, option for the packages section. You can pass –nobase if you don’t want to install the complete Base group. But now you will have to mention the Core group or it will install not enough packages.
This is how your packages section in the kickstart file can look like:

% packages --nobase
@ Core
yum
openssh-clients
openssh-server


Everybody knows and uses output redirection to get the output of a command to a file.

With > you redirect STDOUT, with 2> you redirect STDERR and with &> you redirect both at the same time.

ls > output.txt
ls 2> error.txt
ls &> output_and_error.txt


But how do you get the output written to the screen AND to a file?

“tee” answers this question. This little program will accept text from STDIN and put in on STDOUT and write it to a file.
This is how you use it:

ls | tee output.txt


Kris explained in a previous blog post how you can create multiple bridges.

While testing the multiple bridges in a situation where every bridge is connected to a physical interface and that every virtual interface must be connected to the correct bridge (peth0->xenbr0->vifX.0; peth1->xenbr1->vifX.1; …) I noticed something strange.

The vif interface was not always connected to the correct bridge. When the bridgename is provided in the configuration file (with or without the mac address) the first entry is not always mapped to vifX.0.

A wrapper script brought again a solution. The vif-wrapper-bridge script will chech the name of the vif interface and use the last number (interface number) to define the bridge. That bridgename is stored in the xenstore and used by the vif-bridge script.


[root@GW-Y ~]$ grep wrapper xend-config.sxp
(network-script network-wrapper-bridge)
(vif-script vif-wrapper-bridge)


vif-wrapper-bridge
#!/bin/sh
 
if [ $1 = "online" ]
then
  # load some general functions
  dir=$(dirname "$0")
  . "$dir/vif-common.sh"
  # find the bridge number out of the vif interface name
  brnum=$(echo $vif | sed 's/vif.*\.//')
  bridge=xenbr$brnum
  # store the bridgename in xenstore
  bridge=$(xenstore_write "$XENBUS_PATH/bridge" "$bridge")
fi
 
# load the real vif-bridge script
/etc/xen/scripts/vif-bridge $1


During testing of heartbeat 1 on a xen dom0, some strange errors appeared. One of the error messages was:
ERROR: No local heartbeat. Forcing shutdown

This error message was explained in the heartbeat FAQ but the explained causes didn’t make any sense.
An update from Xen 3 to Xen 3.0.4 didn’t solve the problem.
Updating heartbeat from v1 to v2 made the error disappear and heartbeat was now working without any problems.
Heartbeat v2 has a complete new config file. The main config file (ha.cf) is now an xml file. But don’t worry, if you don’t want to upgrade the config file, you can keep working with a v1 config file. You can’t take advantage of the new features of heartbeat v2 but at least you’re taking advantage of the bugfixes

I repeadetly tried to install xen. The installation of the rpms, downloaded from the xen site, succeeded but when I rebooted into the xen kernel a kernel panic occured.
A message like no version for “struct_module” found: kernel tainted scrolled over the screen during the loading of the modules. A deeper look into that message showed me that it was not fatal and the kernel panic was caused by something else.

A lot of kernel panics are caused because they can’t find the harddisk. This happens because the correct module isn’t build into the kernel or available in the initrd. The same problem occured here. The xen kernel has not as many build in modules as a normal centos kernel and the needed modules aren’t automatically added in the initrd.

The solution is easy: include the needed modules in the initrd.
But which module is the correct one? That depends on the hardware in your system. You can start finding the correct modules by reading the dmesg when you boot that system with a working kernel.

Following command worked on my home machine:

[root@xen ~]# mkinitrd -v -f --with=ide-generic /boot/initrd-2.6.16.33-xen_3.0.4.1.img 2.6.16.33-xen_3.0.4.1


By default xen will bind it’s console on ttyS0 and following message is visible in /var/log/message
kernel: Xen virtual console successfully installed as ttyS0

At this moment you can’t send messages over a serial cable connected to your system because the device is already in use by xen.

Adding following parameter in the grub config file, the default ttyS0 will be changed to whatever you provide or removed if you enter xencons=off.
module /boot/vmlinuz-2.6-xen ro root=/dev/sda1 xencons=ttyS9

ttyS0 will be unused after a reboot and the module providing the serial devices can be loaded, the module is called 8250.
Normally the serial modules are compiled in the kernel and nothing is implemented to load them during boot. But we want to load when the system is booted. Therefore I added that module in /etc/modprobe.conf:
# loading the module for serial devices. We want this at boot time therefore it is aliased to snd-card.
alias snd-card-0 8250
alias snd-card-0 8250_pci
alias snd-card-0 8250_pnp


This is how you can test the serial connection between 2 machine:
* On machine 1 open the serial device: cat /dev/ttyS0
* On machine 2 send a message over the link: echo “Hello World” > /dev/ttyS0
The message should appear on machine 1.

When you initiate a kickstart installation from a bootcd you have to enter something like: linux ks=hd:sda1:/ks.cfg.
This and whatever you enter on the same line can be accessed during the installation. This line is stored in /proc/cmdline.
It is not specific to a kickstart installation, but on every linux system you can find the information entered at the boot prompt in /proc/cmdline.

In a previous post I mentioned how you can mount your usb-drive. As you can see sda1 is hard-coded which isn’t very flexible. This can be done on a different way:

%pre
if grep -iqE "ks=hd:[a-z]{2,3}[0-9]:" /proc/cmdline
then
  DISK=`cat /proc/cmdline | sed 's/.*ks=hd:\(.*\):.*/\1/'`
fi
mkdir -p /tmp/usb-disk-mount/
mount /dev/$DISK /tmp/usb-disk-mount/


There are many things you can do with the line stored in /proc/cmdline.
You can enter a keyword, and with that keyword you can select which files are needed for the installation.
That keyword can also be used to specify a specific option.

The bad thing is that the %pre section is executed in a seperate run. If you set some variables during the %pre section (like $DISK in the above example) they won’t be available for the rest of the script.
The include path of the file must be hard-coded but you can change existing content or generate the complete file during the %pre section.

Everybody know iptables. But do you know arptables?

From the man pages of iptables and arptables:

Iptables  is used to set up, maintain, and inspect the tables of IP  packet filter rules in the Linux kernel.
Arptables is used to set up, maintain, and inspect the tables of ARP packet filter rules in the Linux kernel.


The only difference between these 2 tools is that iptables will filter IP packets and arptables will filter ARP packets. The usage is very simple, if you can work with iptables you can work with arptables, and vice-versa. All commands (Append, Insert, List, …) can be used for both iptables and arptables. The arguments are, off course, different but are very similar in usage.

The package containing arptables is called arptables_jf. I guess the jf stands for Jay Fenlason, which is the name of the writer of arptables.

Last week I started playing with kickstart. You can read more about it in the howto section of my blog.

Today I was testing the %include command but every file and every path I tried gave me a file not found error.
It appears that just the specific kickstart config file is copied to /tmp and the other content of my usb-disk is nowhere to find. This explains why my included files can’t be found.

The solution is to make your included files available during the %pre-section. This is possible because anaconda will parse the ks.cfg file 2 times. The first time it won’t complain about included files that can’t be found and only the %pre section is executed. The second time it will complain if an include file is missing.

This is how I made my includes work:
* mount the usb-drive during the %pre section

%pre
mkdir -p /tmp/usb-disk-mount/
mount /dev/sda1 /tmp/usb-disk-mount/

* include the files

%include /tmp/usb-disk-mount/partition/base
%include /tmp/usb-disk-mount/network/dummy