Archive for June, 2007

Network Bridge

Wednesday, June 27th, 2007

Unlike the expected header, this is not about silently routing packets between interfaces, or bridging multiple networks. This is all about how ants, which find the summer the best time to start investigating our place, can show innovativeness, and can prove that even ants can use network bridges, when required.

The cable was in-air, not connected to wall along the line.

You can see a close-up of how ants actually use Cat5e cables for their own benefit

Resting on the ‘5’

Painful upgrade from Edgy x86_64 to Feisty x86_64

Sunday, June 24th, 2007

If it works, don’t touch it. This is one of my mottoes. I have broken this rule just yesterday when I decided that I was too lazy to install Pidgin from source, and decided I wanted it to be installed directly from deb. Unfortunately, there was no pidgin deb for Edgy. None that I was able to find.

My computer has been suggesting to be upgraded for a while now – ever since Feisty was available. I was cautious and avoided upgrading up until now. I have already installed Feisty on my laptop, on one of my servers (installed Edgy and then upgraded to Feisty with no special events), so I was somehow more at ease. This was, of course, a complete disaster.

Upgrading Edgy to Feisty went OK. Nothing really special, no external sources, nothing. After upgrade, the system failed to reboot – just hung there. It appears (and I have yet to post a bug) that my IT8212 IDE controller (which is connected to my CDROM) hangs the computer.

Not only that, but even when disabled, it appears that Feisty’s kernel has an issue with sata_iix. The issue was solved using post #59 from this bug report. Do not follow, though, this recommendation (all_generic_ide) as you will experience a noticeable performance hit.

I was able to boot my system. No CDROM, but working. I have installed NVidia drivers manually, as the restricted modules were too old. I was required to remove the nvidia entries in /etc/modprobe.d/lrm-video (probably because I’ve installed restricted modules and later on removed it). Had X running, but didn’t have Beryl working. Past experience taught me that AIGLX or direct NVidia DRI are slower than XGL. Attempting to use XGL, I get the white-screen-of-death. Following this guide, I was able to setup XGL correctly, as it seems. It did not solve my white-screen-of-death, however, using –use-copy flag things worked, and seemed to be responding fast enough.

Still have to open a bug about the IT8212 device. Hope for the best.

Misconfigured Amavisd and its impact

Tuesday, June 19th, 2007

As an administrator, I am responsible for many setups and configurations, sometimes hand tailored to supply an answer to a set of given demands.

As a human, I err, and the common method of verifying that you have avoided error is by answering this simple rule: “Does it work after these changes?”

In the world of computers there is hardly ever simple true or false. We would have expected it to be boolean world – either it works or it doesn’t, but we are not there. The world of computers is filled with “works better” and “works worse”, and sometimes we forget that.

This long prologue was meant to bring up the subject of monitoring and evaluating your actions. While the simplest method of evaluation remains “Does it work?”, there are some additional, more subtle methods of verifying that things work according to your specifications.

One of the tools which helps me see, in the mirror of time, the effect of changes I have done is a graphical tool called Cacti. This tool graphs a set of predefined parameters which were chosen by me. It has no special AI, it cannot guess anything, and I am quite happy with it, as I can understand for myself the course of events better.

This post is about a mis configured Amavisd daemon. Amavis is a wrapper which scans using both Spamassassin and a selected Antivirus (ClamAV, in my case, as it has proven itself to me as a good AV) mail supplied by the local MTA.

I had a directive looking like this in it:

[‘ClamAV-clamscan’, ‘clamscan’,
“–stdout –disable-summary -r –tempdir=$TEMPBASE {}”, [0], [1],
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],

It worked, however, this server, as it appears, was heavily loaded for a while now. Since it’s a rather strong server, it was not really visible unless you take a look at the server’s Cacti. On about 80%+ of the time the CPUs were on 100% with the process ‘clamscan‘. I have decided yesterday to solve the heavy load, and for that modified the file ‘/etc/amavisd.conf‘ to include the primary ClamAV section as follows:

[‘ClamAV-clamd’,
&ask_daemon, [“CONTSCAN {}n”, “/tmp/clamd”],
qr/bOK$/, qr/bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],

This uses clamd instead of clamscan. The results were a drastic decrease on the CPU consumption and system average load, as can be seen in the Cacti graph (around 4 AM):

Cacti load average graph

The point is that while both configuration worked, I had the tools to understand that the earlier configuration was not good enough. Through tracking parameters on the system for a while, I could monitor my configuration modifications using a wider perspective, and reach better conclusions.

The first biological portable computer

Tuesday, June 19th, 2007

This is not exactly a technical post, but I had to bring it online.

I am proud to be one of the first persons, if not actually the first one to own a biological portable computer (BPC). You will find no other such thing, I think. I have searched Google, after all.

Although the docking station, or Biologic Electronic Interface (BEI) looks quite similar to the IBM X40’s docking station

The docking station, or Biological Electronic Interface (BEI)

You can see the difference. Unfortunately, in this picture you cannot clearly see the micro conductors which are used in the BEI plug, which is, actually, the method of connecting a simple and regular USB mouse to the BPC.

The BPC has the ability to self support. It is self propelled, and will walk(!!!) back to the BEI whenever the need arises. It has the computational power of hundreds of normal PCs, and although it runs its own unique OS, it has a simple interface which accepts commands. In the picture below, you can see the BPC in its docking station, charging.

The BPC inside its docking

As said, accepts commands, but only seldom performs them. It’s a prototype, and yet has a way to go. It has to fit the docking better (this prototype BEI has been developed as a case study), and should go through more modifications until it can be sold commercially. Yet, very impressive.

RHEL3 Kickstart on Itanium (IA64)

Saturday, June 16th, 2007

Recently I have installed several Redhat systems on IA64 platforms. Since it required only slight adjustments, and since there were two sets of systems, RHEL3 Update2 and RHEL4 Update3, I have decided to use Kickstart for both, each with his own ks.cfg file.

For lack of any other explanation at the moment, I can only say I feel I have encountered a bug with RHEL3 on IA64 platform and ks handling.

Steps:

1. Bring up a dedicated installation server. Install on it DHCP Server, Name Server, TFTP Service (activated from xinetd), NFS Service.

2. Setup DHCP for a dedicated network card. Address pool 192.168.0.x. Server IP: 192.168.0.1

3. Verify it’s working.

4. Extract RH images to the NFS root directory, under the distro name. Example – /install/rhel3.2-ia64

5. Add elilo PXE image for IA64 in /tftpboot. Add a file elilo.conf (elilo.conf)

6. Install both servers – RHEL3 and RHEL4

7. Take anaconda-ks.cfg and use it (with slight modifications) to fit my needs. Really minor changes.

8. Boot the next nodes based on these ks files. (RHEL3 ks file: ks.cfg)

While RHEL4 works fine and uses my ks.cfg, RHEL3 does not. It seems to start using it, and then go on to asking me all these annoying questions (Welcome to RedHat 3 installation!)

I have even tried building ks.cfg using redhat-config-kickstart tool, but same results.

Since installation is done using serial console, I cannot access other virtual consoles and debug the problem on-the-fly.

***UPDATE***

Per a suggestion in a forum, I have looked again into the elilo.conf file, and noticed that the ks path was different. Matter of paying attention. This is probably the problem, and I will verify it soon.