Tag: Debian

Openssl in Debian en afgeleiden voorspelbaar

Aangezien recent gebleken is dat de Debian ontwikkelaars een bug ingevoegd blijken te hebben in openssl zijn de aangemaakte keys niet betrouwbaar.

Wat ik ervan begreep gebruikt openssl een variabele op een ongebruikelijke manier. De Debian ontwikkelaars hebben dat dus aangepast zonder te weten dat dit de basis is voor het aanmaken van random gegevens die een key onvoorspelbaar maken. Dat ze dit gedaan hebben komt mede doordat de code op dit punt niet gedocumenteerd was en er blijkbaar geen reactie geweest is na het submitten van deze patch naar de ontwikkelaars van openssl.

Nu gebruikt onder andere openssh deze aangemaakte keys en aangezien ik inlog met behulp van deze methode zal ik de oude keys moeten weggooien en opnieuw aanmaken. Het bijwerken van de pakketten op zowel de Debian als de Kubuntu systemen heb ik al gedaan.

Als eerste maar eens zorgen de oude keys niet meer gebruikt worden. Per machine log ik in met behulp van de key en hernoem het bestand authorized_keys. In een extra terminalvenster kan ik vervolgens op mijn machine een nieuwe key aanmaken op de vertrouwde methode. En het testen hiervan. Als dat lukt dan kan ik de hernoemde authorized_keys file gaan verwijderen.

Gelukkig heb ik slechts 4 machines waarbij ik op deze manier inlog en gebruik ik nog geen certificaten dus het blijft binnen de perken. Het schrijven van dit bericht heeft me in elk geval meer tijd gekost.

Lighttpd staakt (2)

Zowel gisteren als vandaag begon de webserver weer kuren te vertonen. Na het updaten van een aantal posts op dit blog kreeg ik geen reactie meer terug. Dus toch maar weer eens de logbestanden nageplozen. Vreemd genoeg is er niets te vinden wat een probleem zou kunnen geven.

Als laatste redmiddel dan toch maar een mailtje gewaagd aan Henk van de Kamer, ik heb tenslotte van hem afgekeken hoe ik de server opzetten kan.

Gelukkig tref ik het want ik heb dezelfde avond nog een mailtje terug ontvangen. Henk was dus beschikbaar en hij had een oplossing voor me. Hij heeft hetzelfde probleem namelijk al eens eerder ondervonden. En aangezien ik zijn configuratie bestanden overgenomen en dus ook zijn achteraf gezien wat ongelukkig instelling:

http://www.hetlab.tk/asterix/tunen-webserver

Wat hier dus gebeurt is dat bij sommige handelingen er door php teveel tijd besteed wordt. Doordat er maar maximaal 1 proces mag zijn volgens de configuratie kom je in de problemen als dit proces ermee ophoud door geheugenproblemen. Door dus het maximale aantal processen te verhogen voorkom je dat de server in  staking gaat.

Na het aanpassen van het php configuratiebestand en het herstarten van lighttpd draait de webserver deze keer hoogstwaarschijnlijk een stuk langer.

Bedankt Henk!

Tijd

Vandaag kwam ik erachter dat ik om 10 uur ’s avonds al voor de volgende dag aan het posten was. Ergens klopt er iets niet. Toch maar even de tijd goed zetten.

Je kan de tijd van de server natuurlijk handmatig instellen. Maar uiteindelijk zal de tijd gaan verlopen. Het automatiseren hiervan is dus handiger. Hiervoor installeer ik de pakketten ntp en ntpdate

Arkon:~# aptitude install ntp ntpdate

Als alles goed gaat dan wordt de NTP service na de installatie automatisch gestart. We kunnen dit controleren met het volgende commande:

Arkon:~# ntpq -p

Dit commando draait een NTP query en de optie -p zorgt ervoor dat er een lijst van de servers geprint wordt die in /etc/ntp.conf genoemd worden. Ook laat het van deze servers de status zien.

Voor de zekerheid nog even de tijdzone controleren en/of goedzetten met:

Arkon:~# tzconfig
Your current time zone is set to Europe/Amsterdam
Do you want to change that? [n]: n
Your time zone will not be changed

En zoals je ziet staat mijn tijdzone prima aangezien ik in Nederland woon en daar ook mijn server heb staan.

Als laatste met date nog even kijken of de aanpassingen succesvol waren:

Arkon:~# date
Sat Feb 23 23:02:26 CET 2008

En ook dat klopt, CET oftewel Central European Time en de juiste tijd ook nog eens.

Vanaf nu zal het tijdstip wat er bij mijn blogposts staat dus ook werkelijk kloppen.

Fail2ban

Naar aanleiding van de Problemen Arkon (4) heb ik vandaag een volautomatisch blockprogramma geinstalleerd. De keuze is gevallen op fail2ban. Waarom zul je denken? Ik had het namelijk de vorige keer over snort en snortblock. Snort is inderdaad een intrusion detection systeem wat al een behoorlijke tijd aan de weg timmert. Blokkeer mogelijkheden zitten er niet in en snortblock was een shell script wat iemand van het Freesco support forum in elkaar geknutseld heeft. In hoevere dit bijgehouden wordt weet ik niet, dus vandaar dat ik op zoek ben gegaan naar een vervanger. Uiteindelijk kwam ik uit op fail2ban als enkel pakket wat zowel het detecteren als het blokkeren voor zijn rekening neemt. Continue reading “Fail2ban”

Debian Etch 4.0r3 (2)

Vandaag de upgrade naar Etch 4.0r3 maar eens doorvoeren:

Arkon:~# aptitude upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
Building tag database... Done
The following packages will be upgraded:
cpio libc6 libc6-i686 linux-image-2.6.18-6-486 locales
5 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 26.2MB of archives. After unpacking 311kB will be used.
Do you want to continue? [Y/n/?] y

Grub wordt geupdate tijdens dit proces:

Running postinst hook script /sbin/update-grub.
You shouldn't call /sbin/update-grub. Please call /usr/sbin/update-grub instead!

Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file … found: /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found kernel: /vmlinuz-2.6.18-6-486
Updating /boot/grub/menu.lst … done

Zo maar eens een reboot doen om te kijken wat het opleverd.

Problemen Arkon

Ik probeerde eerder vanavond een post toe te voegen aan dit blog en het wou maar niet lukken. Ook het inloggen via ssh faalde.

tecumseh@Athlan:~$ ssh -l root 192.168.0.10
Read from socket failed: Connection reset by peer

Toch maar eens een beeldscherm en toetsenbord aansluiten. Hierna zie ik de volgende melding zeer vaak langskomen:

end_request: I/O error, dev hda, sector 4994570

En daar tussendoor de volgende meldingen:

INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" respawning too fast: disabled for 5 minutes

Er gaat iets behoorlijk mis. Iemand een idee wat dit veroorzaken kan?

Debian Etch 4.0r3

Ik zag op het blog van Henk van de Kamer dat er een upgrade van Debian Etch is uitgekomen. Ik ga nog even afwachten wat zijn methode van upgraden is en of hij wellicht nog wat tips voor me heeft.

Voornaamste probleem wat ik aan zie komen is de upgrade van de kernel en daarbij het weer correct instellen van grub.

Binnenkort ook maar zijn mailscript in orde maken op mijn server. Krijg ik ook eens mail van mijn systeempje.

Debian geinstalleerd (2)

Zo, ik heb het kale systeem ondertussen weer terug kunnen halen.

Tijdens de 1e installatie was ik nog al voorzichtig met de selectie van de pakketten (dpkg –set-selections). Ik ben er daarmee achtergekomen dat de minimale installatie die Henk van de Kamer gebruikt met slechts een paar pakketten uitgebreid moet worden voor mijn installatie. Het gaat dan om de dhcp3-client en dhcp3-common en locales. Op de een of andere manier krijg ik namelijk gigantisch veel perl waarschuwingen over het niet ingesteld hebben van de locales. Deze keer kon ik dus gewoon de selectie accepteren om vervolgens die 3 pakketten handmatig te installeren samen met de kernel. Ik kwam er hierbij ook achter dat dit in de juiste volgorde gebeuren moet. De volgende keer dus als eerste de locales installeren en daarna de kernel, grub en dhcp3-client (plus de dhcp3-common die daar automagisch bij meekomt).

Hierna de rest afronden en dan heb je een systeem wat weer werkt. Of toch niet…?

Alles afgerond, en een reboot. Wil toch helemaal het netwerk niet meer opkomen… Na veel zoeken heb ik /etc/network/interfaces maar aangepast. eth0 stond inderdaad netjes ingesteld op dhcp maar auto was ‘vergeten’. Na dit veranderd te hebben boot ie weer netjes.

Debian etch installatie (again…)

Helaas…

Ben ik gedurende het weekend regelmatig druk geweest met Arkon (dat is de hostname die ik de microclient gegeven heb). Dan krijg ik het uiteraard voor elkaar om het geheel zondagavond nog te slopen…

Ik was nog druk bezig met het installeren van een ftp-server. Aangezien deze standaard op inetd leunt kreeg ik het niet voor elkaar om ‘m te starten. Dus maar eens terugzoeken hoe ik Debian Etch geinstalleerd gekregen heb. Dat betekend het teruglezen van de pagina’s op Het Lab. Ik kwam in elk geval tegen dat ik vergeten was om voor de 2e keer de initrd te vernieuwen nadat een aantal modules nog expliciet uitgesloten werden. Jammer dat ik dus het volgende stukje niet uitgeschakeld heb:

## de volgende is waarschijnlijk nodig voor niet SATA (bijvoorbeeld cd-rom)
#install ide_core /bin/true

De harde schijf die ik gebruik is namelijk een ide-schijf. En zonder harde schijf is er geen mogelijkheid dat er een besturingssysteem geladen wordt.

Na het opnieuw booten van de usb-stick met de netboot installatiebestanden heb ik nog getracht om van daar uit de initrd opnieuw op te bouwen. Helaas is me dat niet gelukt. Na een tijdje hiermee geprutst te hebben heb ik de knuppel maar in het hoenderhok gegooid en ben verdergegaan met het opnieuw installeren.

De verloren tijd moeten we dan maar onder de noemer leerervaring zetten.