[ jalogisch]

ich hatte das problem einer vollgelaufenen /var partition. über nacht gab es wohl einen massiven run auf den mailserver wodurch dieser mal eben über 5gb logfiles erzeugte und somit die partition gesprengt hat …

zum glück handelte es sich um eine über xen virtualisierte kiste, sodas eine lösung schnell gefunden war.

also erstes das device (sprich das lvm) für die partition vergrössern, nach einem reboot war mittels fdisk -l zu sehen, die virtuelle festplatte war grösser geworden, jedoch fehlte doch die partitionstabelle für den voll virtualisierten kernel.

also ein fdisk /dev/xvdf¹ und jetzt als erstes d zum löschen der partition, danach ein n zum neu anlegen der partition² und schliesslich w um das ganze auch zu schreiben und fdisk zu verlassen. durch einen erneuten reboot wusste der kernel dann auch von seinem mehr an platz auf der partition und ein xfs_growfs /dev/xvdf sorgte dafür das es auch ein grösseres dateisystem gegeben hat.

der sicherlich richtigere weg, wäre über ein rettungssystem gegangen, da ich so ein root dateisystem nicht vergrössern würde³ aber bei einer logpartition war mir das risiko schnuppe. ausserdem wäre dies umständlicher gewesen.

so kann ich dann jetzt auch die gesetzlich vorgeschriebenen vorhaltezeiten für logfiles einhalten ohne diese quer durchs netzwerk zu schieben …. virtualisierung kann auch stellenweise das leben erleichtern habe ich da gemerkt.

1. es handelte sich zum glück um die einzige Partition auf dem device [↩]
2. hier sieht man schon die mehr vorhandenen blocks [↩]
3. einfach aus dem risiko heraus daten zu verlieren [↩]

ich hasse es kernel-maintainer zu sein … das bedeutet ich muss auf der arbeit den linux kernel neu bauen, bei sicherheitslücken und wenn neue features benötigt werden. leider habe ich arge probleme damit einen aktuellen kernel zu bauen der auf sämtlicher dell hardware läuft.

das bedeutet zwar läuft meine konfiguration auf allen gängigen systemen, für alle benötigten aufgaben, aber auf dieser verflixten 860 mit perc controller will der einfach nicht laufen. ziemlich ätzend, da wir die kiste oft eingesetzt haben.

hat jemand einen tip für mich wie ich nen kernel (unter debian) bekommen kann, der sowohl auf der 2950, der 1950, der 2900 und der 860 läuft … modelle wie eine 750 und 850 sollten auch noch damit laufen …

ich hasse es!

ich bin ja ein freund der weiterentwicklung, des schaffens neuer möglichkeiten, neuer blickwinkel und neuer optionen … also jetzt mal so auf die arbeit bezogen, oder besser gesagt aus dem herzen des nerds … der neuste kernel sollte am besten schon eine stunden nach erscheinen auf kernel.org auf allen systemen produktiv laufen … das php ohne nachzudenken einfach mal in der neuen version drübergebügelt werden … und die ganzen netten features die mir in den fingern jucken am besten über nacht einbauen …

aber wenn ich immer gleich losbasteln würde, was würde dabei rauskommen? schweinegeile systeme für die kunden, massenweise features, alles geht, nichts ist unmöglich … aber dann, ein ausfall, wie war das nochmal genau … und genau deswegen, die ungeliebte dokumentation … hat mir heute mal wieder den arsch gerettet … ein hoch auf das dokuwiki.

… die zahl der hosts die ich heute selber geupdatet habe … neuer kernel.

grundsätzlich nichts wildes … fast täglich turne ich auf den systemen rum … der kernel lief ja auch … aber die kleinen zipperlein der älteren systeme … die unterschiedliche firmware version in raidcontrollern und schon wollten 60 server einmal gestreichelt werden und eine bestätigung mit rootpassword das sie jetzt rebooten sollen … natürlich auf der konsole .. auch drac nicht …

… dann noch der spruch, keine gute laune ? … in so einem moment halte ich lieber meinen mund es könnte sonst nicht so nett sein …

… also an alle kunden die hier lesen, ja es gab heute auf allen systemen eine downtime bedingt durch ein kernelupdate … und ja es gab stellenweise kleine hänger … dafür sind die systeme wieder sicher verpackt mit neuem kernel … nachwehen jetzt in der spätschicht … natürlich nach der normalen tagschicht …