If you delete the emp­ty di­rec­to­ry /var/lib/xk­b, then en­able the KDE key­board lay­out switcher, the up­-ar­row key works like print­-screen.

At least on my box it does. It took me a month to fig­ure it out.

And you can see it at http://www.net­man­ager­s.­com.ar.

It's span­ish on­ly right now, but that will change in a week or so.

It was an in­ter­est­ing job, be­cause we are us­ing three web apps writ­ten in three dif­fer­ent lan­guages (ph­p/python/per­l) and I want­ed to pro­vide our cus­tomers with a sin­gle lo­gin for all three.

It was a bit of ef­fort, but ed­u­ca­tion­al :-D

On oth­er news, there is now a "Tip­it" link on each post. What's that for? Well, you can use it to give me mon­ey. You get to be list­ed as "guy that gave Rober­to mon­ey", too (as soon as there is one ;-).

I was in one of my cus­tomer's dat­a­cen­ters the oth­er day, and while I do most work re­mote­ly, I had to take this op­por­tu­ni­ty to take some snap­shots of their proxy serv­er.

This post is just a bit of fun. This is not sup­posed to be their server, it was just a stop­gap mea­sure be­cause of mul­ti­ple hard­ware fail­ures. This is a large, well man­aged com­pa­ny, and this ir­reg­u­lar sit­u­a­tion will be fixed soon. And any­way, it is work­ing just fine.

As you know, Lin­ux can do that kind of job easy with­out much hard­ware re­quire­ments. Af­ter al­l, it has to han­dle at most about 3Mbps of data, and this box has 2GB of ram, so there's plen­ty of room for a speedy cache.

So, let's go for some good news/bad news.

Good news: It's a true-blue IBM Server! Bad news: It's a IBM Netfin­i­ty 5000 (mod­el 3Ry)!

Here is some tech in­fo from IBM about it.

Good news: It has 2 CPUs! Bad news: They are two 450Mhz Pen­tium II CPUs.

Good News: it has hot-swap­pable SC­SI disc­s! Bad news: you have no discs for that con­troller, so we will use this 8GB IDE (PATA) disk!

And will leave it just sit­ting there by the CD unit, be­sides the huge gap­ing hole in the front where the SC­SI discs would be.

Bad News: it has a ten­dence to over­heat­ing! Good News: You have a place to keep your coffe war­m!

The guys at http://github.­com have been nice enough to add me to their be­ta pro­gram, so I am do­ing a lit­tle project there, to fig­ure out if I like git or not.

Since ev­ery­one raves about it, I sup­pose I will, and then will have to turn my nu­mer­ous google­code SVN re­pos in­to git mir­rors or what­ev­er the cor­rect ter­mi­nol­o­gy is.

It should not hap­pen but it does: Your qmail serv­er is over­load­ed. Maybe you are un­der a DOS at­tack, or there is a rea­son why you are get­ting 10x your usu­al amount of mail.

But then you start see­ing how your "not pre­pro­cessed" queue starts grow­ing, and grow­ing...

This can al­so mean things like cla­mav or spa­mas­sas­s­in, which need to check the mail be­fore it gets queued are not keep­ing up with the mail flow, or maybe some IO per­for­ma­ce is­sue.

But what can you do righ now to fix it?

Well, you can dis­able spa­mas­sas­s­in, or, in ex­treme cas­es, shut­down SMTP so the sys­tem has a chance to catch its breath so to speak.

Of course, clos­ing SMTP means your own users can't send email ei­ther, which suck­s.

Now there is a lighter al­ter­na­tive: shut­down SMTP for those who are not your user­s.

Here's the triv­ial code, im­ple­ment­ed as a SPP plug­in, fit to be used in the [mail] sec­tion:

#!/bin/dash

if [ -f /var/qmail/control/overloaded ]
then
      if [ -z "$SMTPAUTHUSER" ]
      then
              echo R451 Temporary Failure: Server overload
              echo overload: $PPID Temporary Failure: Server overload >&2
      fi
fi

And if you are dar­ing and want to make your sys­tem self­-­cor­rect­ing, maybe you should cron some­thing like this:

* * * * * if [ `qmail-qstat  | tail -1 | cut -d: -f2` -gt 100 ];\
then touch /var/qmail/control/overloaded ;\
else rm -f /var/qmail/control/overloaded; fi

I will prob­a­bly code it again in C and make it part of ra/­plu­g­in­s.