Por lo me­no­s, eso hi­zo en mi no­te­book y tar­dé un mes en arre­glar­lo.

Por aho­ra só­lo en es­pa­ño­l, pe­ro eso cam­bia en una se­ma­na, más o me­no­s.

Fue un tra­ba­jo in­te­re­san­te, por­que es­ta­mos usan­do tres apli­ca­cio­nes web en tres len­gua­ges (ph­p/­p­y­tho­n/­per­l) y que­ría dar­le a los usua­rios un úni­co lo­gin pa­ra las tres.

Fue un es­fuer­zo, pe­ro fué edu­ca­ti­vo :-D

En otras no­ti­cia­s, hay un li­nk "Ti­pi­t" en ca­da pos del blo­g. ¿Pa­ra qué sir­ve? Pa­ra dar­me di­ne­ro. Y sa­len lis­ta­dos co­mo "gen­te que le dió di­ne­ro a Ro­ber­to" (a­pe­nas ha­ya al­guien ;-)

Es­te post es pa­ra reír­se un ra­ti­to. Es­te no de­be­ría ser su ser­ve­r. Es una so­lu­ción tem­po­ral de­bi­do a mul­ti­ples fa­llas si­mul­ta­neas de har­dwa­re. Es­ta es una em­pre­sa gran­de y bien ad­mi­nis­tra­da, y es­ta si­tua­ción irre­gu­lar se va a re­sol­ver pron­to. Y de to­das for­mas fun­cio­na.

Co­mo sa­be­n, Li­nux pue­de ha­cer es­te ti­po de tra­ba­jo sin gran­des re­que­ri­mien­tos de har­dwa­re. Des­pués de to­do, só­lo ne­ce­si­ta ma­ne­jar unos 3 Mbps de da­to­s, y es­te equi­po tie­ne 2GB de RA­M, así que hay mu­cho lu­gar pa­ra un ca­ché rá­pi­do.

Así que ten­ga­mos un po­co de bue­na­s/­ma­las no­ti­cia­s.

Bue­nas no­ti­cia­s: Es un ver­da­de­ro ser­vi­dor IBM! Ma­las no­ti­cia­s: Es un IBM Ne­tfi­ni­ty 5000 (mo­de­lo 3Ry)!

Aquí hay un po­co de in­for­ma­ción téc­ni­ca de IBM.

Bue­nas no­ti­cia­s: Tie­ne 2 CPUs! Ma­las no­ti­cia­s: Son dos Pen­tium II de 450­Mh­z.

Bue­nas no­ti­cia­s: so­por­ta dis­cos SCSI ho­t-swa­p! Ma­las no­ti­cia­s: no hay dis­cos pa­ra esa con­tro­la­do­ra, así que va­mos a usar es­te dis­co IDE PA­TA de 8GB!

Y lo va­mos a de­jar ahí sen­ta­do jun­to a la lec­to­ra de CD, jun­to al agu­je­ro adon­de irían los dis­cos SCSI.

Ma­las no­ti­cia­s: tien­de a re­ca­len­tar­se! Bue­nas no­ti­cia­s! te­ne­mos có­mo man­te­ner el ca­fé ti­bio!

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.

But then you start seeing how your "not pre­pro­ce­ss­e­d" queue star­ts gro­win­g, and gro­win­g...

This can al­so mean things like cla­mav or spa­ma­ssas­si­n, whi­ch need to che­ck the mail be­fo­re it ge­ts queued are not kee­ping up wi­th the mail flo­w, or ma­y­be so­me IO per­for­ma­ce is­sue.

But what can you do ri­gh now to fix it?

We­ll, you can di­sa­ble spa­ma­ssas­si­n, or, in ex­tre­me ca­ses, shu­tdo­wn SM­TP so the sys­tem has a chan­ce to ca­tch its brea­th so to speak.

Of cour­se, clo­sing SM­TP means your own users can't send email ei­the­r, whi­ch su­cks.

Now the­re is a li­gh­ter al­ter­na­ti­ve: shu­tdo­wn SM­TP for tho­se who are not your user­s.

He­re's the tri­vial co­de, im­ple­men­ted as a SPP plu­gi­n:

#!/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 da­ring and want to make your sys­tem se­l­f-­co­rrec­tin­g, ma­y­be you should cron so­me­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 wi­ll pro­ba­bly co­de it again in C and make it part of ra/­plu­gin­s.