CentOS convert hda to vda for virtualisation / grub problems & root panic

When virtualising a server, it sometimes become necessary to convert an old centos version from using hda as it’s root device, to be referenced by vda for virtio.  Here’s a howto for people who already know what they’re kinda doing:

First thing is to make sure you’re running on the latest kernel for your OS before doing anything to make sure you’ve got the appropriate drivers:
yum update kernel

Step to is to edit some files on there. If you’ve already got it booted then great, otherwise you can boot it using ide virtualisation options in your virtualisation software, or you can use a boot/live cd (lots of options here! If you’re stuck, just use a centos LIVE CD)

Once in there, you’ll need to mount your image’s partitions in order to get into your image’s /boot/grub (or equivalent thereof – if your lost here then this howto really isn’t for you sorry!)

edit device.map and change
(hd0)     /dev/hda
to
(hd0)     /dev/vda

Next step is to edit your /etc/modprobe.conf and add/update the corresponding virtio modules:

alias eth0 virtio_net
alias scsi_hostadapter1 virtio_blk

(Remember if you’re using a boot cd, make sure you’re editing your image’s files – not your live cd’s temp files!)

Then you need to recreate the initrd file to have the virtio drivers (no redhat won’t put them in by default if they weren’t already there)

mkinitrd -f –with=virtio_blk –with=virtio_pci –builtin=xenblk /boot/initrd-2.6.18-custom.img 2.6.18-308.16.1.el5

Where 2.6.18-308.16.1.el5 is your kernel version (you can get it by looking at your files in /boot
Now you have the choice of altering your /boot/grub/menu.lst to use this new initrd-2.6.18-custom.img file (or you can just reboot, hit a key at grub boot time, use the e key to edit the initrd line – you can use tab to auto-complete to make it easy).

You might also need to update the root= part to be your /dev/vda3 (or whatever your root drive is). Mine was using labels so it didnt need to be changed.

Once booted, you now want to reinstall the stock centos initrd / kernel (it’s always scary to run on your own customisations!)…..so you’ll want to run:
rpm –erase –nodeps kernel-2.6.18-308.16.1.el5
(Or whatever your kernel version is)
yum install kernel

then reboot and if everything went according to plan, you should be sitting in a stock standard centos kernel, with your drives running on virtio / /dev/vda. Woo!

.ssh authorized_keys and centos / redhat / selinux enabled Linux solution

Just a quick note that if you ever create /home or /home/user or /home/user/.ssh or /home/user/.ssh/authorized_keys that you’ll need to reset the selinux contexts for the coresponding files/directories or else sshd won’t be allowed to access your authorized_keys file!

If your /home isn’t very large (and /home was what you created), the easiest way of fixing things is to run this:

restorecon -R -v /home

Otherwise if you added /home via useradd AND the user home dir then you can probably get away with just:

restorecon -R -v /home/user

This will reset the contexts placed on /home/user/.ssh/*

We have moved!

As you may or may not be aware, we have recently (recent being 6 months ago!) moved our office. After 9 years of residing on other end of Sydney CBD, we are now streets away from Sydney landmarks, Harbour Bridge & Opera House.

The project planning room

For more happy snaps check out our Facebook album

In other news, the team is currently busy working on revamping our Rackcorp website! More details to come, watch this space.

MySQL Replication with SSL Error_code: 2026 – Resolved

We keep returning to an issue with MySQL Replication whereby we keep seeing error code 2026 when trying to set it up with SSL:
[ERROR] Slave I/O: error connecting to master ‘———@———-:—-‘ – retry-time: 60 retries: 86400, Error_code: 2026

The simplest answer is – DONT USE OPENSSL. Mysql comes bundled with yassl, just specify –with-ssl on the configure line rather than adding your openssl path, and mysql will compile with the internal yassl. Same config works just fine with yassl, and doesnt with openssl.

Are there security implications with doing this? Possibly as yassl has had issues in the past. But if you’re opening up your MySQL servers to the public then you’re probably already weighing up risk vs functionality anyway.

Just for the record, some key points from the my.cnf files:
[client]
timezone = UTC
ssl-ca=/etc/certs/ca-cert.pem
ssl-cert=/etc/certs/server-cert.pem
ssl-key=/etc/certs/server-key.pem

[server]
ssl
ssl-ca=/etc/certs/ca-cert.pem
ssl-cert=/etc/certs/server-cert.pem
ssl-key=/etc/certs/server-key.pem

And the MASTER config:
| Slave_IO_State | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File | Read_Master_Log_Pos | Relay_Log_File | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master | Master_SSL_Verify_Server_Cert | Last_IO_Errno | Last_IO_Error | Last_SQL_Errno | Last_SQL_Error |
| Waiting for master to send event | IPADDRESSS | mysqlrepl | PORT | 60 | mysql_bin_log.000539 | 1652774 | relay-bin.000006 | 1652923 | mysql_bin_log.000539 | Yes | Yes | | | | | | | 0 | | 0 | 1652774 | 1750495 | None | | 0 | Yes | /etc/certs/ca-cert.pem | /etc/certs/ | /etc/certs/client-cert.pem | | /etc/certs/client-key.pem | 0 | No | 0 | | 0 | |

Hopefully that helps someone else get things set up….

Shared Hosting Support for PHP 5.3

Just letting everybody know that as of tonight, we now have servers running in most of our POPs that are capable of running PHP 5.3. If it’s possible on your server, you will see the option in the RackCorp portal to select:

PHP 5.3.6 (SSL,FTP,ZLIB,IMAP,IMAPSSL,GD,MySQL,Sockets,Kerberos,ICONV,MBSTRING,MBREGEX,GetText,MimeMagic)

It takes about 1-2 minutes for your site to do a changeover between versions. If it doesn’t come up, select 5.2 to put things back to how they were, and drop a ticket in to see if we can debug it for you.

We’ve also taken this upgrade to try and get our servers all running the same version of our web manager. By doing so, a lot of you should now find that you can control several more php.ini options for your accounts, and that you also have access to PHP 4.4.9. If you’re unusure of any options, just run with the defaults as they’re pretty safe.

Overall, just remember that PHP 5.3 is not entirely compatible with PHP 5.2. Check out this link for sure:

http://www.php.net/manual/en/migration53.deprecated.php

Some things we came across just in the RackCorp portal:
Depreciated functions:

# ereg() (use preg_match() instead)
# ereg_replace() (use preg_replace() instead)
# eregi() (use preg_match() with the ‘i’ modifier instead)
# eregi_replace() (use preg_replace() with the ‘i’ modifier instead)
# split() (use preg_split() instead)
# spliti() (use preg_split() with the ‘i’ modifier instead)
# session_register() (use the $_SESSION superglobal instead)
# session_unregister() (use the $_SESSION superglobal instead)
# session_is_registered() (use the $_SESSION superglobal instead)
# set_socket_blocking() (use stream_set_blocking() instead)
# mysql_db_query() (use mysql_select_db() and mysql_query() instead)
# mysql_escape_string() (use mysql_real_escape_string() instead)

Also, for the few of you out there that use it (like us!) Ming has been moved out to PECL.

Otherwise, we’ll let you know how we go with our migration over the next few months. We’re particularly interested in any SOAP changes as things seem to silently have crept in during PHP 5.2.X revisions that although minor changes left us with big headaches (timezones in datetime fields – ARGH!)… To be continued…. 🙂