Welkom in deze online versie van mijn maandelijkse rubriek Het Lab in PC-Active. Sinds april 1998 vul ik elke maand drie pagina's over alles wat ik meemaak met computers. Gelukkig is dat laatste zeer rekbaar, hetgeen u zelf kunt controleren via de oude afleveringen en via het onderstaande labjournaal. Veel leesplezier!
Labjournaal
Voor alle experimenten gebruik ik een hele serie computers in het domein armorica.tk. De computers zijn genoemd naar karakters uit de strip Asterix & Obelix. Omdat deze namen u mogelijk minder zeggen, heb ik een overzicht gemaakt met de belangrijkste details.
Geheugenverbruik
Tot op heden heb ik de minimale Etch templates geüpgrade via de hardware-node. Zojuist probeerde ik met mijn bat_small instellingen binnen zo'n virtuele server het pakket Lighttpd te installeren en dat ging hopeloos mis: te weinig geheugen. Nu is bekend dat nieuwere versies van besturingssystemen meer resources vragen en Debian zal daarop geen uitzondering zijn. Ik heb daarom even een debian-3.1-min-amd64 — nummer 44 — met een debian-etch-min-amd64 — nummer 45 — vergeleken. Als eerste heb ik de machines gestart, gestopt en vervolgens weer gestart. Dit omdat de eerste keer starten een hele serie extra acties uitvoert. het resultaat:
44: kmemsize 474679 759384 3775000 4194304 0
privvmpages 1162 2295 32768 33792 0
physpages 588 904 0 (2^63-1) 0
45: kmemsize 503036 792987 3775000 4194304 0
privvmpages 835 1338 32768 33792 0
physpages 646 1115 0 (2^63-1) 0
U ziet dat het verbruik van privvmpages in Debian Etch minder is geworden, maar dat gaat wel ten koste van meer physpages en die bepalen hoeveel geheugen op dit moment wordt vastgelegd. Beide resultaten zijn bepaald vanuit de hardware-node. Vervolgens doen we een enter, wat een paar extra processen binnen de virtuele server opstart:
44: kmemsize 825668 848146 3775000 4194304 0
privvmpages 2409 2494 32768 33792 0
physpages 1132 1132 0 (2^63-1) 0
45: kmemsize 855228 890177 3775000 4194304 0
privvmpages 1627 1639 32768 33792 0
physpages 1215 1215 0 (2^63-1) 0
Ook hier zien we hetzelfde resultaat. Ofwel het ligt niet aan de standaardprocessen, maar aan wat aptitude allemaal uitspookt. Nu is bekend dat het bijwerken of installeren een enorme hoeveelheid geheugen vergt. Ook Windows heeft hier last van. Ofwel ik heb in beide het pakket lighttpd geselecteerd, op de g gedrukt, waarna 45 afbreekt met een geheugenprobleem. In beide gevallen heb ik aptitude verlaten en het staatje opgevraagd. U moet nu naar de tweede kolom kijken, dat is de piek die bereikt is tijdens dit proces:
44: kmemsize 896331 1432550 3775000 4194304 0
privvmpages 2759 22586 32768 33792 0
physpages 1303 15087 0 (2^63-1) 0
45: kmemsize 806953 1180180 3775000 4194304 0
privvmpages 1545 33149 32768 33792 457
physpages 1150 22206 0 (2^63-1) 0
Ofwel onder Sarge is het geheel opgelopen tot 22.586 aangevraagde blokken, waarvan 15.087 daadwerkelijk in gebruik waren. Onder Etch is het maximum bereikt — dat het getal groter is dan de barrrier kan in dit geval, zie het getal daarna — en wel 457 keer. We moeten nu dus uitzoeken hoeveel extra geheugen er nodig is om aptitude te laten slagen. Want sommige mensen krijgen root-toegang en ook dan willen we dat ze in ieder geval aptitude kunnen gebruiken.
Toevoeging 09-04-2008 om 11:42
Het uitzoeken is ondertussen gebeurd...
Geheugenverbruik is op 19-03-2008 om 11:04 bewaard onder Virtueel — Er zijn geen reacties —
Tunen mailserver (3)
Het is een tijdje goed gegaan, maar zojuist is wederom een grens overschreden. De melding was om 08:05 en betrof numothersock die ik al eerder verhoogd had naar 384. Nu zijn de virtuele servers op Hoefnix II vergelijkbaar met de Strato V-PowerServer C en die configuratie heb ik een tijdje geleden al eens opgezocht. Zij gaan uit van veel hogere waarden dan ik momenteel heb staan. Nu ben ik bewust met alles laag begonnen, omdat ik de indruk had dat sommige waardes die providers hanteren compleet waanzinnig waren 
. Hoe dan ook, ik ga het geheel nog maar een keer verhogen:
hoefnix2:/etc/vz/conf# vzctl set 180 --numothersock 512:512 --save hoefnix2:/etc/vz/conf# vzctl set 180 --othersockbuf 786432:2097152 --save
Voor het nageslacht even de waardes die op dit moment (10:47) zijn breikt voor de vier aangepaste:
numflock 4 59 100 120 0
othersockbuf 176736 689344 786432 1769472 0
numothersock 103 384 384 384 138
numfile 362 2260 3072 3072 0
Tunen mailserver (3) is op 11-01-2008 om 15:01 bewaard onder Virtueel — Er zijn geen reacties —
Tunen mailserver (2)
Zojuist ontdekte ik dat wederom twee waardes van mijn spam-mailserver zijn overschreden. Helaas zijn deze gemaskeerd doordat een andere virtuele server op Hoefnix II ook een probleem had. Kortom ik weet dus niet het exact moment, maar op 4 januari om 10:10 zette ik het systeem weer op scherp en in het toen bewaarde ubc_154 zijn de verhoogde waarden nog niet als regel aanwezig, ofwel ze stonden toen nog op 0. Op 4 janauri om 21:45 kwam de genoemde andere server in nood en in die uitdraai zijn eveneens nog geen verhoogde waarden te vinden. Vanochtend om 09:50 zag ik de melding en zette ik het systeem weer op scherp. In ubc_155 die toen werd aangemaakt zijn wel de verhoogde waardes te vinden:
numflock 13
numothersock 19
numfile 25
Ofwel ergens tussen gisteravond 21:45 en vanochtend 09:50 is de spam-mailserver in de problemen gekomen met zo te zien het aantal geopende bestanden. Nu heb ik beide al eens eerder zien gebeuren, alleen heb ik de verhoogde waardes nooit doorgevoerd. Voor ve145 heb ik dit zojuist dus alsnog gedaan:
hoefnix2:~/scripts# vzctl set 145 --numflock 100:120 --save hoefnix2:~/scripts# vzctl set 145 --numfile 3072:3072 --save
De numflock is op Asterix ooit eens opgelopen tot 85, ofwel dit zou voorlopig afdoende moeten zijn. Op alle andere servers is de grens van 50:60 nog nooit bereikt! De numfile is op Asterix ooit op 3.026 terecht gekomen en slechts één andere machine heeft de grens van 2048 bereikt. De komende tijd gewoon in de gaten houden en volgens mij kan ik het rustig doorvoeren op alle zware machines als blijkt dat dit afdoende is.
Toevoeging 05-01-2008 om 16:03
Waarschijnlijk gaat het om de spamrun van 762 mailtjes tussen 22:15:39 en 22:17:43. Waarschijnlijk is dit te snel na elkaar, zodat het systeem nog bezig is om de oudere te verwerken en er filedescriptors voor de nieuw ontvangen nodig zijn.
Tunen mailserver (2) is op 05-01-2008 om 15:50 bewaard onder Virtueel — Er zijn geen reacties —
Tunen mailserver (1)
Gistermiddag plaatste ik een gloednieuwe mailserver online om zo te kunnen experimenteren met het ontvangen van spamruns. Vanochtend om 08:15 ontving ik van Hoefnix II een melding dat tussen 08:10 en 08:15 het aantal numothersock de limiet van 256 had bereikt. Volgens mij zijn dit de pipes die programma' s gebruiken om dingen aan elkaar door te geven? De teller stond in één klap op 18 en tussen 08:15 en nu (10:35) is er nog één bijgekomen. Als eerste heb ik de numothersock verhoogd — waarbij indirect ook othersockbuf moet worden aangepast — als volgt:
hoefnix2:/etc/vz/conf# vzctl set 145 --numothersock 384:384 --save hoefnix2:/etc/vz/conf# vzctl set 145 --othersockbuf 786432:1769472 --save
Uiteraard ook even de logs bekeken en ik kan geen enorme aantallen zien die rond dit tijdstip werden afgeleverd. Vreemd dus...
Tunen mailserver (1) is op 28-12-2007 om 10:48 bewaard onder Virtueel — Er zijn geen reacties —
Templates updates
Half november maakte ik up-to-date versies van mijn minimale Debian Etch template. Nu wil ik op basis hiervan een nieuwe virtuele server gaan maken om mijn spam-experiment van Asterix te verwijderen. Deze is namelijk wat uit de hand gelopen en zorgt er nu voor dat Asterix regelmatig plat gaat. Het is ook niet niets om tigduizend spamberichten in een paar minuten te moeten verwerken...
Ter controle heb ik even ve56 gestart om te kijken of deze up-to-date is. Dat is niet het geval 
. Om onduidelijke reden zit in dit template de e2fsprogs die een tijdje terug op alle fysieke servers moest worden geüpgrade. Ter controle e2fsprogs verwijderd en dan moet ik het volgende intikken: Yes, I'am aware this is a very bad idea. Nu ben ik mij van geen kwaad bewust . Tenslotte is e2fs alleen nodig als je fysieke partities wilt maken, maar dat is op virtuele servers nergens voor nodig. Helaas blijkt dat mount en util-linux afhankelijk zijn van libuuid1 en mount ook nog eens van libblkid1. Verder wil initscripts absoluut e2fsprogs hebben en die wil weer de andere pakketten 
. Ik moet dus maar eens gaan uitzoeken waarom deze drie pakketten absoluut deze ellende willen...
Voorlopig heb ik dus maar even een up-to-date template gemaakt, omdat ik absoluut verder wil met bovenstaande. Het uitzoeken kan gebeuren voordat ik echt massaal Etch virtuele servers ga inzetten:
hoefnix2:~/templates# vzctl start 56 hoefnix2:~/templates# vzctl enter 56 ve56:/# aptitude ve56:/# exit hoefnix2:~/templates# vzctl stop 56 hoefnix2:~/templates# ./cleanlog 56 hoefnix2:~/templates# cd /var/lib/vz/private/56/ hoefnix2:/var/lib/vz/private/56# tar --numeric-owner -czf ../../template/cache/debian-etch-min-i386.tar.gz . hoefnix2:/var/lib/vz/private/56# cp -a ../../template/cache/debian-etch-min-i386.tar.gz ../../root/135/var/www/armorica.tk/files/debian/.
Hetzelfde heb ik voor ve57 gedaan, want op Hoefnix II gebruiken we tenslotte de amd64 variant.
Toevoeging 25-12-2007 om 22:31
. Ik schaam mij diep. Na de aanpassing eind mei heb ik nooit gecontroleerd of ik het back-up script juist had aangepast. En zojuist bleek dat de dagelijkse full back-up van de database weliswaar netjes op Asterix wordt gemaakt, maar deze dus nooit op de andere harddisk — deze wordt door de back-up server gebruikt — van Hoefnix II terechtkomt. Dat heb ik zojuist dus opgelost. En is weer eens duidelijk dat u regelmatig moet controleren of u met de back-ups wel alles weer in de lucht kunt krijgen...
Toevoeging 27-12-2007 om 18:46
Ook de Etch templates hebben waarschijnlijk de upgrade naar versie 4.0r2 nodig. Dat dus zojuist maar even doorgevoerd. En meteen een fraai script geschreven dat één en ander automatiseert .
Templates updates is op 25-12-2007 om 21:19 bewaard onder Virtueel — Er zijn geen reacties —
Templates
Op dit moment is het een beetje chaos met alle templates die ik heb. Daarom maar eens even één en ander uitzoeken:
Hoefnix I
-rw-r--r-- 1 root root 32510502 Oct 3 2006 debian-3.1-i386-miniserver.tar.gz -rw-r--r-- 1 root root 49727180 Apr 11 2007 debian-3.1-i386-webhosting.tar.gz -rw-r--r-- 1 root root 48327295 Oct 25 2006 x1.debian-3.1-i386-webhosting.tar.gz -rw-r--r-- 1 root root 50155085 Nov 21 2006 x2.debian-3.1-i386-webhosting.tar.gz
Hoefnix II
-rw-r--r-- 1 root root 31279507 Oct 3 2006 debian-3.1-amd64-miniserver.tar.gz -rw-r--r-- 1 root root 48327295 Oct 25 2006 debian-3.1-i386-webhosting.tar.gz -rw-r--r-- 1 root root 37755511 Apr 29 2007 debian-etch-min-amd64.tar.gz -rw-r--r-- 1 root root 39562730 Apr 29 2007 debian-etch-min-i386.tar.gz
Strato
-rw-r--r-- 1 root root 31279507 Oct 3 2006 debian-3.1-amd64-miniserver.tar.gz -rw-r--r-- 1 root root 49507447 Nov 30 2006 debian-3.1-amd64-webhosting.tar.gz -rw-r--r-- 1 root root 46716262 Sep 11 2006 debian-3.1-amd64-webhosting_old1.tar.gz -rw-r--r-- 1 root root 32510502 Oct 3 2006 debian-3.1-i386-miniserver.tar.gz -rw-r--r-- 1 root root 63227727 Oct 31 2006 debian-3.1-i386-web_mysqld.tar.gz
Tot slot heb ik nog een serie templates die zijn afgeleid van het standaard Strato template. Deze wil ik eigenlijk niet gebruiken voor mijn eigen servers. Op Hoefnix I gebruik ik voorlopig nog even de i386-webhosting, totdat ik klaar ben om alle machines te gaan upgraden. De andere drie gaan voorlopig in het archief. Na hernoemen en alles synchroniseren heb ik nu:
-rw-r--r-- 1 root root 49727180 Apr 11 2007 debian-3.1-web-i386.tar.gz -rw-r--r-- 1 root root 37755511 Apr 29 2007 debian-etch-min-amd64.tar.gz -rw-r--r-- 1 root root 39562730 Apr 29 2007 debian-etch-min-i386.tar.gz
De eerste is zoals gezegd tijdelijk en moet de komende maanden vervangen worden door een etch variant. Die moet ik weer baseren op de laatste twee. De eerste stap is die twee updaten tot de nieuwste stand.
Toevoeging 15-11-2007 om 19:11
Het updaten gaat om onduidelijke reden behoorlijk mis:
hoefnix2:~# vzctl create 57 --ostemplate debian-etch-min-amd64 --config bat_large hoefnix2:~# vzctl set 57 --hostname ve57.armorica.tk --save hoefnix2:~# vzctl set 57 --ipadd 192.168.13.57 --save hoefnix2:~# vzctl start 57 hoefnix2:~# vzctl enter 57 ve57:/# aptitude debconf: delaying package configuration, since apt-utils is not installed dpkg: failed to open package info file `/var/lib/dpkg/available' for reading: No such file or directory E: Sub-process /usr/bin/dpkg returned an error code (2) A package failed to install. Trying to recover: dpkg: failed to open package info file `/var/lib/dpkg/available' for reading: No such file or directory Press return to continue.
Na een tiental minuten zoeken ontdek ik dat om onduidelijk reden een mount point is verdwenen, waardoor de backports niet meer online zijn. Dat is gelukkig snel op te lossen:
hoefnix2:~# mount --bind /mnt/dists/ /var/lib/vz/root/135/var/www/armorica.tk/backports/dists/
Vervolgens krijgen we een foutmelding dat de publieke sleutel van mijn backports niet aanwezig is. Eveneens gemakkelijk op te lossen:
ve57:/# wget http://backports.armorica.tk/backports.gpg ve57:/# apt-key add backports.gpg ve57:/# rm backports.gpg
Daarna gaat het updaten goed en is het een kwestie van inpakken:
ve57:/# exit hoefnix2:~# vzctl stop 57 hoefnix2:~# cd templates/ hoefnix2:~/templates# ./cleanlog 57 hoefnix2:~/templates# cd /var/lib/vz/private/57/ hoefnix2:/var/lib/vz/private/57# tar --numeric-owner -czf ../../template/cache/debian-etch-min-amd64.tar.gz .
Toevoeging 15-11-2007 om 19:36
Voor het maken van de webhosting templates moet ik eerst een nieuwe Lighttpd en PHP gaan compileren. Ik lop behoorlijk achter met het bijhouden van patches . Maar dat ga ik de komende weken inlopen...
Templates is op 15-11-2007 om 17:03 bewaard onder Virtueel — Er zijn 4 reacties —
Submission
Zoals u gisteren heeft kunnen lezen, heb ik wat problemen met KPN die zo nodig poort 25 wenst af te sluiten. De oplossing is simpel, gewoon een mailserver installeren die naast poort 25 ook luistert op een andere poort. Bekende zijn 465 (secure SMTP) en 587 (message submission). Die laatste is wel heel erg gemakkelijk in Postfix. Gewoon even master.cf openen en de regel met submission ontdoen van zijn hekje:
submission inet n - - - - smtpd
Na een postfix reload zien we opeens dat naast poort 25 ook poort 587 staat te luisteren. Om te testen of dit werkt, doen we vervolgens vanaf Obelix het volgende:
hvdkamer@obelix:~$ telnet vpsa.armorica.tk 587 Trying 85.214.42.196... Connected to h1171527.serverkompetenz.net. Escape character is '^]'. 220 vpsa.armorica.tk ESMTP Postfix (Debian/GNU) helo obelix.armorica.tk 250 vpsa.armorica.tk mail from: <henk@vandekamer.nscom> 250 2.1.0 Ok rcpt to: <h.van.de.kamer@hccnet.nsnl> 554 5.7.1 <h.van.de.kamer@hccnet.nsnl>: Relay access denied
U ziet dat het geheel nog steeds veilig is en ook dat poort 587 niet automatisch versleuteling hoeft te betekenen. Kortom ik kan zonder al te veel problemen bovenstaande in ieder geval doorvoeren op ve42. Daar mag ik dan wel mail verzenden omdat mijn vaste IP-adres van KPN in mynetworks staat. Daarmee heb ik in ieder geval de onzin van KPN omzeilt. Wanneer leren dit soort bedrijven nu eens dat filteren of blokkeren geen enkel nut heeft?
Toevoeging 08-11-2007 om 17:37
Moet ik natuurlijk wel in de firewall van Hoefnix I zorgen dat voortaan poort 587 ook op ve42 wordt afgeleverd...
Submission is op 08-11-2007 om 18:20 bewaard onder Virtueel — Er zijn geen reacties —
MySQL probleem
Voor een klant wil ik één van mijn Strato images op de gloednieuwe V-PowerServer A installeren. Dat gaat mis op MySQL met de volgende melding in syslog:
Oct 23 21:13:39 h1337041 mysqld_safe[9596]: started Oct 23 21:13:39 h1337041 mysqld[9599]: ^G/usr/sbin/mysqld: File '/var/log/mysql/mysql-bin.index' not found (Errcode: 13) Oct 23 21:13:39 h1337041 mysqld[9599]: 071023 21:13:39 [ERROR] Aborting Oct 23 21:13:39 h1337041 mysqld[9599]: Oct 23 21:13:39 h1337041 mysqld[9599]: 071023 21:13:39 [Note] /usr/sbin/mysqld: Shutdown complete Oct 23 21:13:39 h1337041 mysqld[9599]: Oct 23 21:13:39 h1337041 mysqld_safe[9601]: ended
Zojuist dus maar eens uitgezocht wat hier aan de hand is. Al snel blijkt dat de directory als eigenaar 71 heeft en dat het genoemde bestand inderdaad niet bestaat. Al snel bedacht ik mij dat dit wel eens kan liggen aan de manier waarop ik de images opruim voordat ik ze verspreid. En jawel, het gaat dus mis omdat op Asterix de nummers van gebruikers en groepen anders zijn dan op de ontwikkelmachine:
drwxr-s--- 2 sshd adm 4096 Oct 22 10:51 mysql
dat moet echter zijn:
drwxr-s--- 2 mysql adm 4096 Oct 24 06:09 mysql
Waarom dat vervolgens na uitpakken leidt tot een 71 kan ik nog niet helemaal volgen. Maar bij het inpakken (uitpakken gebruikt de nummers in het archief) van het archief moet ik voortaan in dit soort gevallen de optie --numeric-owner gebruiken. Als ik dat doe, bevat het gemaakte archief in ieder geval de juiste nummers die overeenkomen met de etc/passwd en etc/group in hetzelfde archief . Daarmee staan ook de rechten voor MySQL goed en zou het opstarten geen probleem mogen zijn.
Toevoeging 24-10-2007 om 16:36
De genoemde 71 is nu ook verklaard en komt door het rescue-systeem van Strato. Daarin staat:
sshd:x:71:65:SSH daemon:/var/lib/sshd:/bin/false
MySQL probleem is op 24-10-2007 om 15:53 bewaard onder Virtueel — Er zijn geen reacties —
Stupide HCCnet
Ik ben blij dat ik al mijn mail bij het HCCnet heb weggehaald. Want wat ik zojuist ontdekte, slaat wederom alles. Het HCCnet doet er namelijk alles aan om te zorgen dat mail niet — ik herhaal *NIET* — bezorgd kan worden. Zo was ik aan het uitzoeken hoe ik voor mijn Strato serie tijdelijk alle mail via sSMTP kan versturen. Omdat de meeste lezers niet zoals ik een eigen mailserver hebben, moet het dus via de provider. Ofwel in ssmtp.conf heb ik nu staan:
root=h.van.de.kamer@hccnet.nsnl mailhub=hcc1.schonemail.nl
Daarmee zou alle mail van en naar de lokale gebruiker root via de mailserver van HCCnet verstuurd moeten worden. Ofwel:
h1171527:~# mail -s "Test" root Blaat . Cc:
Vervolgens is het even stil en volgt de ellende:
send-mail: RCPT TO:<h.van.de.kamer@hccnet.nsnl> (450 4.7.1 <h.van.de.kamer@hccnet.nsnl>... from <root@h1171527.serverkompetenz.net> via [85.214.42.196] to <h.van.de.kamer@hccnet.nsnl> denied for 120 seconds) Can't send mail: sendmail process failed with error code 1
Inderdaad, in hun strijd tegen de spam wordt gewoon alle mail botweg geweigerd. Een mailserver zal de code 450 opvatten als tijdelijk probleem, maar sSMTP heeft geen mailqueue. Het is tenslotte bedoeld om mail van het systeem naar een echte mailserver te krijgen. Maar als die dit soort onzin uitvreten...
Stupide HCCnet is op 04-08-2007 om 17:32 bewaard onder Virtueel — Er zijn 2 reacties —
Debian uitkleden
Op het PC-Active forum ontstond de vraag in hoeverre distributies zijn uit te kleden. Nu heb ik Debian al behoorlijk gestript voor mijn virtuele servers en dan blijft er een footprint over van circa 167 MiB. Nu zit hierin de nodige overbodige zaken, zoals alle vertalingen (45 MiB) en de enorme lijsten met te installeren packages (25 MiB). Als ik die zou kunnen strippen komt het geheel onder de 100 MiB uit voor een verse installatie.
De volgende stap is het verwijderen van Perl. Deze kost 2,5 MiB en is volgens aptitiude alleen nodig voor adduser. En aangezien we die nauwelijks gebruiken, is dat dus zonde. Waarschijnlijk zijn er nog meer van dit soort maffe afhankelijkheden. Ik moet dus mijn strip experimenten weer eens oppakken en de boel verder gaan uitkleden. Want op zich is dit wel een leuke bezigheid en leer ik veel van hoe één en ander in elkaar steekt.
Debian uitkleden is op 04-08-2007 om 12:00 bewaard onder Virtueel — Er zijn geen reacties —
© 1998-2016 by Henk van de Kamer