Back to Newsletters KEYWORDS= Davrom Consulting Newsletter - Issue # 47 - Dated: 1 Oct 2010 From the desk of David Clark My thanks to the prompters once again asking when the next newsletter will be coming out (you know who you are). Newsletters can be a little one-sided so it is good that when they are absent, people miss them. Some major projects of late ranging from more work with PDF files, server clustering and working with various e-mail technologies. I would like to thank the reader for their time in reading this newsletter. David.M.Clark UNIX Quote Real web site creators program with vi (or vim). DRBD - server to server filesystem sharing As always I tend to write articles based on our latest projects and over the last two months I have been involved in getting some file sharing going between RedHat servers for customers. DRBD is a filesystem technology developed by LINBIT and is designed primarily to allow you to share the same data between multiple servers, (termed a cluster), or as a primary/secondary fail-over solution where the data on one filesystem is "mirrored/synced" to another server at the same time. When running in a primary/primary role the filesystems are writable by all primary servers in the cluster so your updates are seen on all servers. DRBD is the underlying technology which then allows you to use products like GFS2 (Global Filesystems from RedHat) or OCFS2 (Oracle Cluster Filesystems) to manage the actual filesystems between the servers. These are free products that come with a wide range of options. If you just use normal filesystems such as ext3, you can only run the solution in a primary/secondary, or master/backup scenario. It is only the GFS2 and OCFS2 solutions that provide the simultaneous update of files on all servers in a cluster. GlusterFS and Coda are also other filesystem clustering products available so there seems to be no shortage to solutions for organisations requiring mirroring and fail-over solutions. Having worked on the older SCO ReliantHA technology quite some years ago, it was refreshing to see how a set of installed server packages coupled with some uniform modifications to the configuration files on all the cluster servers made all of this happen. Ideally DRBD when coupled with GFS2/Cman or OCFS2 running with two servers side-by-side connected over a private network, provides a very powerful fail-over solution. Although OCFS2 seems to handle the remote connectivity between servers over a WAN, remote clusting over a WAN is not a good solution unless there is extremely high bandwidth between the two sites and the filesystem is hosted on something like a shared SAN technology. The latency in the communications over a WAN often lead to slow response times for local users at each end of the cluster. The filesystems can reside on independent devices such as SANs (ideal) but you can also run DRBD on LVM volumes or if you are only after a primary/secondary setup, you can use local filesystems setup to be GFS2 or OCFS2 or just use DRBD by itself. There is a growing range of proprietary hardware that suits this technology of sharing disks between multiple servers and the clustering solutions fit perfectly into these models. There are many options as to how you fail-over in the event of one server having an issue or the network link going down, but all-in-all the recovery process is quite robust. Excellent products and can be quite simple to implement depending on your configuration requirements. Roundcube You have heard me talk about Squirrelmail as an excellent web based e-mail system for Linux servers, but one other product that is worth looking at is Roundcube. I have normally stayed away from anything that relies on other packages to be installed and running and Roundcube does require a fully running MySQL system, but given MySQL's low overhead for computer resources, Roundcube is certainly a nice web based e-mail client worth considering. Roundcube is a simple to use and easy on the eye e-mail client solution that allows Linux server based users to access their e-mail via web browser either on the local LAN or externally from the Internet. One customer who has switched from Squirrelmail to Roundcube has reported better user base acceptance of Roundcube based on it's more web friendly e-mail composing and smoother use interface. From an admisitrator point of view, you must be able to setup the MySQL database (basically follow the supplied instructions) and then add/include any of the extra plugins such as a global address book. It has integration with existing Linux based technologies such as LDAP (Lightweight Directory Access Protocol) and there is a myriad of plugins available as you would expect from a seasoned e-mail client. If you want best of both worlds, you can run Roundcube and Squirrelmail on the same server. So many choices for webmail.... From the Trenches Some comic or not so comic relief from the support days gone by. The growing concern... A customer some years ago reported that their root filesystem was filling up slowly but surely and was nearing the 98-99% full mark. After much checked of the disk they asked if I could have a look around. As part of our service whilst on-site I listed back their previous nights backup tape only to find it was empty. Puzzles I checked the cron (scheduled task organiser) and sure enough the tape backup was executing each night and its log files showed successful backups were being performed. I subsequently went through the 10 or so tapes they had religiously been feeding into the tape drive each night, all of which were empty. It was after further checking the hard disk that I found a file called /dev/rcto which was about 1.5GB - it was a tar or cpio archive file. When I checked the backup command I found they were using the device name of /dev/rcto instead of /dev/rct0 which mean a valid backup was being performed, but to a regular file in /dev instead of to the device file rct0. So removing the /dev/rcto file fixed the disk space issue and changing the tape device to /dev/rct0 in their script got the backup running to the tapes once again. This explained why the customer was getting backup reports as successful, and why the tapes were empty. UNIX was doing what it was told to do - create an archive backup to /dev/rcto. I guess the lesson is, beware of the typos in your scripts. (It is always good practice to get UNIX/Linux to 'test' the type of file being used for the tape device name and return an error if it is not a special device file). Tech Tip For those familiar with the cat command in UNIX/Linux, it is simply a way to output the contents of a text file to the screen (like the type command for DOS): cat /etc/passwd But have you ever wanted to see the files in reverse? The solution is to use tac, for example: tac /etc/passwd will show you the contents of the /etc/passwd file in reverse order. Back to Newsletters 
Website design by Davrom Consulting Pty Ltd This site is fully tested with Google Chrome and Firefox web bowsers Home Page | Support | Misc | David's Pages | Podcasts | Contact Us | Blog |
