Raskas’ blog

Your passwords are stored encrypted in the /etc/shadow file. This encryption is normally done by the passwd command, but for some cases you want to produce your own encrypted password for manually placing it in the shadow file.

With following perl oneliner you can produce encrypt your password:
# echo "EnterHereYourNonEncryptedPassword" | perl -nle 'print crypt($_, "\$1\$".join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64]);'
This will print an ecrypted string on the screen:
$1$UckA8UmW$Ck0rISvkyk2rDutFT4nU20

Let’s split the oneliner in different pieces so it is easier to understand. The most important perl function, which does the actual encrypting, used in the oneliner is:
crypt("password", "salt");
The “salt” is a random string starting with $1$. Following join will produce such 8 charachters long random string:
join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64];

More information about the crypt function can be found here: http://perldoc.perl.org/functions/crypt.html.
As you can notice the join is also listed on that page

If you try to manage users and there passwords with puppet on CentOs you will receive the error explained by “Known issues” on following page: Puppet on RedHat/CentOS. That page also describes the solution: install the libshadow package on the client.
It is not that easy because there is not yet an rpm of the ruby shadow libraries for CentOs.

“Not yet” because there IS a ruby-shadow rpm available in fedora (see: https://bugzilla.redhat.com/show_bug.cgi?id=240008).

So we only need to download and rebuild it:
wget http://download.fedora.redhat.com/pub/fedora/linux/extras/6/SRPMS/ruby-shadow-1.4.1-6.fc6.src.rpm
rpmbuild --rebuild ruby-shadow-1.4.1-6.fc6.src.rpm


Once we have that rebuilded rpm we can install it on all our puppet-clients. Off course we are not going to do this manually but use puppet for it .
If you have a local repository you can just add the package, but this is not yet the case for my setup so we need some extra rules.
Here is a snippet of puppet manifest:

class ruby-shadow {
   package {
      "ruby-shadow":
         ensure   => installed,
         provider => rpm,
         source   => "/tmp/ruby-shadow-1.4.1-6.i386.rpm",
         require  => file["/tmp/ruby-shadow-1.4.1-6.i386.rpm"],
   }

   file {
      "/tmp/ruby-shadow-1.4.1-6.i386.rpm":
         source => "puppet://puppetmaster/files/ALL/tmp/ruby-shadow-1.4.1-6.i386.rpm"
   }
}

class users {
   include ruby-shadow
   user {
      "root":
         ensure   => present,
         name     => "root",
         password => "SomeAlreadyEncryptedPassword";
   }
}

With this code it will require 2 runs of the puppet client. Even if you add a require in the user section for the ruby-shadow package 2 runs are necessary. Don’t know if this is a bug or a feature…

This week I updated the full backup page. We jumped from version 0.4 to 0.8.
Thanks to my colleagues: Raf, Fred and Jos the script is updated to meet our requirements.

Here are some of the major features added to the newest version:

• You can choose if you want to keep a history (= full weekly backups and daily incrementals) or only 1 backup.
• All information will be written to a logfile which can be mailed to some addresses when the script is done (previously this was done by an extra command in the cron).
• After the backup we will check the size of the local data and the size of the backup, printed to the logfile.
• We will check the free space on the backupdisk and print it to the logfile.

The behavior of the script can be configured with the variables at the top of the script.

Today I tested a heartbeat setup. Everything went fine until…

I performed a reboot of one of the hosts. The host came back and started to communicate with the other heartbeat. At that moment heartbeat started to generate ERROR messages. The load of heartbeat and the load of syslog increased because of the amount of error messages and my /var/log/messages file grew quite a bit.

When the problem started heartbeat was printing lots of information in the log files, but after some time only this messages appeared in the logs.


Jul 17 16:27:33 heartbeat: [2893]: ERROR: Cannot write to media pipe 0: Resource temporarily unavailable
Jul 17 16:27:33 heartbeat: [2893]: ERROR: Shutting down.
Jul 17 16:27:33 heartbeat: [2893]: ERROR: Message hist queue is filling up (200 messages in queue)


20 minutes after the first occurrence of this message the master heartbeat process killed itself. During this time it generated over 30000 times the above error.

The guys of #linux-ha helped me with this error and explained that it is caused by the serial link. The messages sent over the cable didn’t arrive in time.
The fix for it is easy, increase the baud in your ha config file.

My baud was first configured at 9600 and increasing it to 19200 fixed this error.

While using Beryl as my default window manager, I noticed that some java applications didn’t work correctly, for example the XenServer Client.
The application started correctly but I only saw a gray screen.
Whenever my Metacity window manager (that’s the one of gnome) was active, instead of Beryl, the application works as it was meant to be.

This problem is explained in the beryl wiki.
The solution is also mentioned there.

Because I’m using java 5 (1.5.0u11 from Sun) the fix is very simple.
I added following line at the end of /etc/bashrc.

export AWT_TOOLKIT=MToolkit

After restarting the X server the java applications works without any problems.

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