Category: Linux

Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.

And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.

Murphy’s Law is still at work

Murphy’s Law is still at work:

If anything can go wrong, it will.

Just when I thought I was finishing with integrating main LDAP parts (that includes installation, configuration and testing of LDAP server, deployment of LDAP cluster, development of all needed web interfaces, documenting everything, training other people to use the system, etc) into our network infrastructure at work, I get these news:

“Red Hat Announces Directory Server”

Trying to keep myself positive, I was thinking that Red Hat will make it into a commercial product available for its Enterprise Linux product series. The second I thought that, I get these news:

“Fedora Directory Server Now Available to the Open Source Community”

Oh, well. The only thing I’m happy with is that I already have a tested and developed system, while all those people who are planning to use Red Hat Directory Server will just start their journey. And, of course, LDAP being an open standard, I am at easy with the possibilities of further migrations.

P.S.: More informationa about the Directory Server is here.

Static Subversion for Red Hat 6.2

I’ve heard a few harsh words about Subversion before. Mostly these came from sysadmins who complained about all bits and pieces Subversion requires to work properly. Some mentioned that it is not trivial to compile with the set of options that is different from the default.

Today I spent about three hours together with The Master of Strace trying to make Subversion command line client svn work on one of our old machines that runs Red Hat Linux 6.2. The only way to success, it seems, was to compile the static version of svn. Since we needed support for https:// URLs, we had to build with OpenSSL. OpenSSL is not trivial to compile statically too, because of it enourmous love of Kerberos5. While trying to make it work we also jumped through a number of versions of Subversion and other components.

Finally, we managed to build everything. In case you’ll ever need a statically compiled version of svn (from Subversion version 0.17.1 (r4503)), you can get it here (the binary is about 7 MB):

/usr/local/bin/svn

As far as I am concerned it works just fine. It runs on Red Hat Linux 6.2 and can work (import, checkout, commit, etc) with repository running on one of the recent versions (1.1.4 if I recall correctly).

Needless to say that today I’ve heard a few more not-for-kids-ears words and phrases towards Subversion developers.

Reminder about NTP

NTP – Network Time Protocol allows for automatic and precise time synchronization over the network. There are many problems that can be caused by incorrect time – starting from logs confusions and going to software locks due to file timestamps. Configuring NTP is very easy. Just install the ntp RPM that comes with Red Hat or Fedora Linux (or a number of other Linux distributions) and use one of the two modes described below.

  1. Full blown NTP server. In this mode, you’ll have to edit /etc/ntp.conf to specify a number of NTP servers to synchronize time from, as well as a lit of machines that can synchronize time with your server. Usually you’d want to have only one full blown NTP servers per network.
  2. Simple NTP client. This is even easier to configure than the previous mode. All you have to do is add these two commands to your scheduler (cron or similar) to execute hourly. 
    /usr/sbin/ntpdate -s ntp_server_ip_or_hostname
/sbin/hwclock -w

While modern computers are very smart and fast, they don’t have any special skills at keeping the time precisely correct. Internal timers get offset by power cuts, CPU usage bursts, and things like that. The daily changes are small, but when left unattended for a longer period of times, clocks can run ahead or stay back for as long as days!

Here is a log record from one of the servers in our office:

21:01:01 ... ntpdate[...]:  ... offset 0.250427 sec
22:01:00 ... ntpdate[...]:  ... offset 0.251682 sec
23:01:01 ... ntpdate[...]:  ... offset 0.251269 sec
00:01:01 ... ntpdate[...]:  ... offset 0.251013 sec
01:01:01 ... ntpdate[...]:  ... offset 0.250451 sec
02:01:01 ... ntpdate[...]:  ... offset 0.250061 sec
03:01:01 ... ntpdate[...]:  ... offset 0.250239 sec
04:01:01 ... ntpdate[...]:  ... offset 0.250313 sec
05:01:00 ... ntpdate[...]:  ... offset 0.250112 sec
06:01:01 ... ntpdate[...]:  ... offset 0.250554 sec
07:01:01 ... ntpdate[...]:  ... offset 0.250691 sec
08:01:01 ... ntpdate[...]:  ... offset 0.249850 sec
09:01:01 ... ntpdate[...]:  ... offset 0.250418 sec
10:01:01 ... ntpdate[...]:  ... offset 0.250070 sec
11:01:01 ... ntpdate[...]:  ... offset 0.250488 sec

As you can see, this machine’s time inconsistencies are as large as quarter of a second per hour, which can result in 6 seconds per day (24 hours). This alone can cause noticable slowdowns in software that counts on time being always correct.

P.S.: There are NTP implementations for other operating systems as well. Google is your friend.

Uptime records

It’s been a while since I checked uptime on few servers that I manage at work. And by “a while” I mean “a while“. Here are five records for you to be impressed.

  1. ldap-master – this server has a pretty easy life. It is a master node of our internal LDAP cluster. All it has to do is answer the queries of about 20 other servers and a couple of web applications. 
    [leonid@ldap-master leonid]$ uptime
2:39pm  up 462 days,  9:19,  3 users,  
load average: 0.00, 0.00, 0.00
  2. news – this server is under bigger load constantly. It runs as a slave of our internal LDAP cluster. It hosts one of the havier used web applications with database backend. It also runs a news-mail-news gateway, which allows employees to read and post to several heavy mailing lists via a single subscription. 
    [leonid@news leonid]$ uptime
2:40pm  up 455 days, 10:59,  1 user,  
load average: 0.11, 0.03, 0.01
  3. devzone – this is our main development server. About 20 people are constantly using it. It also hosts one of our RT ticketing systems, as well as a few other web applications. There are also a few processes running in test mode. 
    [leonid@devzone leonid]$ uptime
2:44pm  up 404 days, 13:12, 11 users,  
load average: 0.07, 0.06, 0.00
  4. gorilla – our main file server. It hosts homes for more than a hundred users. It also has a bunch of file areas accessible via FTP, NFS, and Windows file sharing (SMB). It also hosts mirrors some mirrors of apt repositories and even Tucows. Some of it is also used for network backups. 
    [leonid@gorilla leonid]$ uptime
2:46pm  up 394 days, 10:36,  2 users,  
load average: 0.00, 0.01, 0.15
  5. backupsrv – this is our backup server. It is one of the most heavier used servers on our whole network. It is responsible for backup and restore of about a hundred hosts and devices. Most of these are done on the daily basis. This server gets most of its reboots from the SCSI equipment errors. 
    [leonid@backupsrv leonid]$ uptime
2:51pm  up 284 days,  6:55,  2 users,  
load average: 0.00, 0.00, 0.00

I checked uptime on several other hosts and all of them are either approaching one year, or passed it already. All of these hosts are running some version of Red Hat distribution. Versions vary from Red Hat Linux 6.2, through Fedora Linux Core 3, to Red Hat Enterprise Linux ES 4.