And this is my first tip – use these guides and follow all of objectives. For example if there`s a task about iSCSI initiator then learn and make some exercises. You have to follow all of these objectives. It`s especially important to people like me who didn`t take any course before, because it`s harder to make yourself some excercises. I was using two virtual machines for this purpose – one of them was a server with some services (nfs, ldap, iscsi target, etc..) and one was a client.

Second thing – don`t forget about SELinux. All of services must be SELinux enabled. Do not turn this off during your study. If you`re not familiar with SELinux then read this documentation – it`s really good and helpful. I recommend reading it at least twice and check all of described commands/tools.

Documentation. I think that Red Hat guys did a really good job creating a bunch of nice docs available on their site.  I recommend reading all of them as they describe most of exam objectives with nice examples. Unfortunately it`s not available during the exam and you must also know how to use manual pages (e.g. man httpd_selinux – describes options on selinux configuration of httpd service) and use it. Also config examples in /usr/shared/doc/* are pretty useful. That`s a very nice thing in Red Hat exams – when you forgot some detail you can always use built-in documentation. They don`t require you to remember all of options although you must know how particular services work. So my tip is this – learn how to find info on something using documentation available in you system rather than just ask google like you (probably) always do

And last but not least tip – get yourself a good sleep night before exam. I didn`t take any notes nor my laptop – try to relax and think positive. If you learn  and practice then everything will go smoothly.

Of course I have passed both exams and got both RHCSA and RHCE certificates In my personal opinion I consider RHCSA to be more challenging than RHCE – just look at exam objectives. RHCE adds SElinux and some basic configuration of network services while RHCSA covers a lot of other things. I recommend taking two exams on one day – it`s not that scary as you think.

Good luck to all of you preparing and studying! I`m starting preparation for RHCA exams. I`ll try to write some tips on them too. Stay tuned.

I created self-signed certificate:

openssl req -new -x509 -nodes -out /etc/pki/tls/certs/slapd.crt -keyout /etc/pki/tls/certs/slapd.key -days 365

and added following lines to /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif

olcTLSCACertificateFile: /etc/pki/tls/certs/slapd.crt
olcTLSCertificateKeyFile: /etc/pki/tls/certs/slapd.key

Everything seemed to work fine, but I couldn`t query ldap using ldaps uri – I got the following error message:

ldapsearch -x  -H ldaps://localhost -b 'dc=example,dc=com'
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

After short and intensive investigation, reading dozens of howto pages I founded the cause – it turned out that in RHEL6 you can`t use self-signed certificates. Well, maybe it`s not that they forbid you to do this, but it`s not as simple as it was in previous versions. Now you have to explicitly add your certificate so that is no longer unknown. There`s even more – you have to configure your Common Name field of the certificate so it matches exactly your server`s name.

So eventually to solve this issue I had to confgure ldap tools/clients and add path to server`s certificate to /etc/openldap/ldap.conf:

TLS_CACERT /etc/pki/tls/certs/slapd.crt

So nothing is the same now – RHEL6 brings new features, new tools and new problems It`s time to learn and adapt.

root (hd0,0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... no

then I have a solution for you. If you checked dozens of pages (like I did) that say there`s a problem with your grub files and you checked them hundred times that everything is fine (files were there, you can still install grub on the source system using exactly the same set of files) then do not loose hope You might want to check if your grub is able to read your filesystem. Maybe you created fs using newer tools. I was moving Fedora Core 3 using sysrescuecd. I created partition and filesystem using tools available on that system. It seems that probably there were minor changes between ext3 fs created on FC3 and sysrecurecd and therefore after chrooting to FC3 environment I couldn`t install grub.

The solution is quite simple – do it outside chroot environment!

Once you have mounted your root partition with /boot install mbr using grub from your livecd environment. In my case I had it mounted on /mnt/custom so I had to enter the following command to install grub on /dev/sda:

grub-install --root-directory=/mnt/custom /dev/sda

I didn`t find a way to do this using grub command line, but using grub-install I was able to boot my system and that was what I needed.

dpkg-query -W -f='${Installed-Size} ${Package}\n'

And here`s a rpm version:

rpm -qa --queryformat '%{SIZE} %{NAME}\n'


mount: xxx:/yyy failed, reason given by server: Permission denied


I checked the configuration dozens of times – it was good, and the nfs server granted access to the share. The following info appeared in logs:


.. authenticated mount request from 1.1.1.1 for /yyy


So everything looked ok, but it didn`t work. The problem was a pseudo filesystem nfsd which should be mounted in /proc/fs/nfsd, but for some reason it wasn`t. I`ve added the following entry to /etc/fstab


none /proc/fs/nfsd nfsd defaults 0 0


and mounted it:


mount /proc/fs/nfsd


After that I was able to mount the nfs share. It took me some time to figure it out and I think that there should be more specific error messages, because the one with permission denied is quite confusing.

In order to configure virtual hosting based on above assumptions I used apache http server as a proxy to tomcat.
First you need to add wildcard records to your domain (example.com) so that records of all its subdomains can be resolved to IP address of your server. Following record should be added to your bind server zone config:

*   IN   A   1.2.3.4

where 1.2.3.4 is IP address of your server.

Next you need to configure httpd server. Please make sure that you have ajp proxy module installed on your server, as connections to tomcat are based on AJP protocol. On CentOS/RHEL 5 this module is included in standard httpd package (see /etc/httpd/conf.d/proxy_ajp.conf).
Now you need to create configuration for your virual hosts. I created a new file /etc/httpd/conf.d/tomcat-vhosting.conf:

UseCanonicalName Off
RewriteEngine On

# vhost map using perl script
RewriteMap vhost prg:/usr/local/bin/apache-getvhost.pl

# do no rewrite restricted names
RewriteCond %{SERVER_NAME} !^docs\.
RewriteCond %{SERVER_NAME} !^examples\.
RewriteCond %{SERVER_NAME} !^host-manager\.
RewriteCond %{SERVER_NAME} !^ROOT\.

# rewrite it
RewriteRule ^/(.*)$ ajp://localhost:8009/${vhost:%{SERVER_NAME}}/$1 [P]

Quite simple and cool, isn`t it? I`m sure that you probably expected VirtualHost directives, but all you need is a powerfull rewriting feature of apache. This configuration allows to access myapp application located in tomcat`s webapps directory via http://myapp.example.com.
I used custom rewrite map which is a simple perl script. All it does is extract subdomain from server name based on URL.

Put the following in /usr/local/bin/apache-getvhost.pl

#!/usr/bin/perl

$| = 1;

while (<STDIN>) {
  if (/(.*?)\.example\.com/)      {
      print $1."\n";
  } else {
      print $_."\n";
  }
}

and make it executable

chmod +x /usr/local/bin/apache-getvhost.pl

Now all you need to do is provide some applications to tomcat.

Recently I had to rename volume group in one of my virtual machines. It is based on CentOS (both dom0 and domU) and it was paravirtualized. I couldn`t do it on running system because root partition was on logical volume. I had to boot the machine in rescue mode. I had no idea how to boot from CD/DVD iso image – AFAIK it is impossible on pv guests. I had to boot vm directly from kernel and initrd used in installation (both are xen aware). So I copied  them to /tmp/xen from /images/xen/ on CD/DVD installation disc.

Then I had to comment out the following line from vm`s config file to bypass pygrub bootloader:

#bootloader = "/usr/bin/pygrub"


Now I needed to tell my vm to use kernel and initrd I had previously copied so I added the following lines:

kernel = "/tmp/xen/vmlinuz"
ramdisk = "/tmp/xen/initrd.img"
extra = "rescue method=http://192.168.0.2/install/centos/"


The last line passes extra arguments to kernel. There is a rescue keyword and a method which tells anaconda installer to get install files from my http server.

After that I was able to boot vm in rescue and rename my LVM virtual group.

Xen posiada również możliwość migracji maszyn. Funkcja ta znana jako live migration jest odpowiednikiem vmotion dla produktów VMware. Można ją wykorzystać jedynie w przypadku, gdy wszystkie serwery dom0 mają dostęp do współdzielonego storage`u. Najłatwiej jest wykorzystać zasób NFS podmontowany na wszystkich serwerach, a maszyny wirtualne instalować na plikach (obrazy dysków) tam umieszczonych. Oczywiście tracimy na wydajności, a poza tym NFS nie wydaje się dobrym pomysłem dla większych instalacji.
I tu z pomocą przychodzi klastrowa odmiana LVM (CLVM). W RHEL/CentOS demon zarządzający klastrową częścią LVM (clvmd) komunikuje się z menadżerem klastra RHCS (Red Hat Cluster Suite). Mi osobiście to niezbyt pasuje. Nie tylko chyba ja uważam, że twór RHCS nie jest jeszcze stabilny ani też łatwy w konfiguracji i zarządzaniu/utrzymaniu. Ale to już chyba temat na odrębny wpis. Ku czemu innemu zmierzam. Mianowicie bardzo zainteresował mnie ten wpis. Okazuje się, że jest możliwe zmuszenie CLVM do działania bez skonfigurowanego RHCS! Należy zamiast tego użyć openais, który i tak wchodzi w skład RHCS. Jako odrębna część jest jednak o wiele przyjemniejsza w zarządzaniu i konfiguracji. Zachęcony wspomnianym wpisem przystąpiłem do pracy. Udało mi się przerobić paczkę lvm2-cluster, tak aby linkowała się z openais. Wpis ten byłby chyba pierwszym howto w sieci opisującym ten proces dla systemów RHEL/CentOS. Niestety w trakcie działania pojawiają się wycieki w pamięci w demonie aisexec. Przy każdorazowym wysłaniu wiadomości do aisexec przez demon clvmd ten pierwszy rezerwuje około 6MB pamięci i nie zwalnia jej poprawnie. Kilkunastogodzinne próby nie przyniosły rozwiązania. Wielka szkoda. Byłaby to świetna wiadomość i dalsze pole do eksperymentowania. Liczę, że uda mi się jeszcze powrócić do tematu, a o rezultatach postaram się niezwłocznie poinformować.

Całość procesu jest dość prosta i opisywana już w wielu artykułach w sieci ( m.in. tutaj ). Wszędzie niemalże wspomina się o ustawianiu typu partycji na fd, czyli Linux raid autodetect. Nazwa sugeruje, że ma to coś wspólnego z autowykrywaniem raidu. Otóż okazuje się, że miało w przeszłości. Parametry konfiguracyjny CONFIG_MD_AUTODETECT zniknął już jakiś czas temu z kernela i tym samym zniknęła też autodetekcja. Opisuje to ten artykuł. Jest tam geneza usunięcia autodetekcji i rozwiązanie problemu bootowania z raidu 1. Wiąże się to z odpowiednio wygenerowanym plikiem initramfs. Ja się złapałem na tym, że system nie wstawał poprawnie, gdyż liczyłem że odpowiednio poustawiane typy partycji zrobią swoje i podczas startu wszystkie macierze samoczynnie wystartują. Krótka analiza struktury initramfs i kilka minut na googlach przyniosły rozwiązanie. Musiałem powiadomić mdadm o istnieniu macierzy, a zatem po ich utworzeniu wywołać polecenie

mdadm --examine --scan >> /etc/mdadm.conf

Następnie należy wygenerować plik initramfs uwzględniający te zmiany – załączy on ten plik do swojego drzewa i podczas startu odpowiednio wywołany mdadm z poziomu initramfs wystartuje podane tam macierze.
W Ubuntu generujemy nowy initramfs dla obecnego kernela poleceniem

update-initramfs -u

Teraz już możemy cieszyć się mirrorowaną partycją /boot.