Apache2 op Debian Squeeze upgraden naar 2.2.20 of 2.2.21

[Cyphax]

Dag allen,

Ik zou graag Apache2 op onze server upgraden van 2.2.16 naar 2.2.20 of 2.2.21. Uiteraard is dat vanwege die vulnerability die daarin is opgelost.

De server draait op Debian 6 (Squeeze) en ik heb in sources.list dit staan:

code:

deb http://mirrors.nl.kernel.org/debian/ squeeze main
deb-src http://mirrors.nl.kernel.org/debian/ squeeze main

deb ftp://debian.oregonstate.edu/debian/ squeeze main contrib
deb-src ftp://debian.oregonstate.edu/debian/ squeeze main contrib

deb http://backports.debian.org/debian-backports squeeze-backports main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

# squeeze-updates, previously known as 'volatile'
deb http://mirrors.nl.kernel.org/debian/ squeeze-updates main
deb-src http://mirrors.nl.kernel.org/debian/ squeeze-updates main

#deb ftp://ftp.vuurmuur.org/debian/ squeeze main

#deb http://ftp.de.debian.org/debian sid main non-free

Ik heb als laatste deb http://backports.debian.org/debian-backports squeeze-backports main toegevoegd (gevolgd door apt-get update).

Ik heb geprobeerd 'm te updaten met:

apt-get install apache2
en
apt-get -t squeeze-backports install apache2

Maar ik krijg de melding dat de nieuwste versie al geinstalleerd is, in beide gevallen. Dat is 2.2.16, dus daar ben ik niet mee geholpen.

Op deze pagina heb ik de 2e poging met apt-get die hierboven staat gevonden. De andere suggestie die daar staat is /etc/apt/preferences wijzigen maar dat bestand bestaat helemaal niet.

Ik wil eigenlijk, omdat het een productieserver is, alleen simpelweg apache2 upgraden naar 2.2.20/21, zonder allerhande andere packages te upgraden (behalve als het echt niet anders kan). Maar ik word een beetje moe van dat gestoei met apt-get en ik wil voorkomen dat ik de installatie vervuil. Vandaar dat ik nu het zelf uitzoeken en proberen opgeef en de vraag hier neerleg: hoe krijg ik apache2 2.2.20/21 geïnstalleerd? Wat is de gangbare manier die een serveradmin hiervoor zou gebruiken? Ik ben ook niet zo bekend met de manier waarop je dat in Debian zou moeten doen, packages upgraden voor dit soort zaken, dus als iemand dat uit zou kunnen leggen zou dat wel fijn zijn.

(Ik ben geen serveradmin maar omdat we helemaal geen serveradmin hebben, en ik als soort van nevenactiviteit meehelp onze servers in de lucht te houden, ben ik wel de aangewezen persoon hiervoor op 't moment)

[pennywiser]

Eerst apt-get update gedaan?

Kan zijn dat je de backports keyring nog moet installeren..

En ik denk dat Apache2 nog helemaal geen backport heeft:

ii apache2 2.2.16-6+squeeze3

[ Voor 104% gewijzigd door pennywiser op 30-09-2011 14:26 ]

[liledevil]

volgens http://packages.qa.debian.org/a/apache2.html is 2.2.20 in de testing en 2.2.21 in de unstable repository at the moment.
Je zou dus testing of unstable kunnen kiezen als distribution (ipv squeeze) om deze versies via aptitude te krijgen.

[Cyphax]

Ik zie het hier maar is dat de gangbare gang van zaken dan? Uit een nieuwere distributie de package halen? Waarom zouden ze niet gewoon een backport maken?

[pennywiser]

Debian lost zelf vulnerabilities op in huidige repo versies, die heb je als het goed is al lang binnen gehad. Als je gaat stoeien met teasting/unstable packages maak je systeem alleen maar meer vulnerable.

Zelf weten, maar regelmatig apt-get update && apt-get (dist-)upgrade is voldoende.

Probeer ook niet, zoals je suggereert, allerlei dependencies tegen te houden, je komt er alleen maar mee in de problemen.

[liledevil]

Zoals Vinzz zegt, Debian fixed ook de vulnerabilities in huidige versies.
Ik was nog op zoek naar een link waarin dit werd uitgelegd, maar kreeg dit helaas niet zo snel gevonden.

[deadinspace]

Cyphax schreef op vrijdag 30 september 2011 @ 14:18:
Ik zou graag Apache2 op onze server upgraden van 2.2.16 naar 2.2.20 of 2.2.21.

Niet doen.

Uiteraard is dat vanwege die vulnerability die daarin is opgelost.

Welke? CVE-2011-3192? Die is al lang gefixt in 2.2.16-6+squeeze2/3 (DST, DSA, Changelog).

Ik heb als laatste deb http://backports.debian.org/debian-backports squeeze-backports main toegevoegd (gevolgd door apt-get update).

Ik raad af backports te gebruiken, tenzij je daar een specifieke reden voor hebt. Voor stabiliteit en veiligheid ben je beter af met vanilla stable.

Wat is de gangbare manier die een serveradmin hiervoor zou gebruiken?

Debians security updates volgen, daar zijn ze voor. Debian backport security fixes naar de versies in Debian stable, waar nodig.

Verder:

• Lees de Debian security FAQ
• Abbonneer je op de debian-security-announce mailinglist.
• Leer de security tracker gebruiken.

[ Voor 0% gewijzigd door deadinspace op 30-09-2011 15:33 . Reden: Naam v.d. mailinglist gefixt (link was wel goed) ]

[pennywiser]

Om mijn Squeeze bak schoon te houden doe ik dit:

code:

apt-get update && apt-get dist-upgrade

apt-get clean && apt-get autoclean && apt-get autoremove

deborphan | xargs apt-get --purge remove -y

Deborphan is een repo package

Deze kan ook nog:

code:

dpkg --purge $(COLUMNS=132 dpkg -l | grep ^rc | awk '{ print $2; }')

[ Voor 21% gewijzigd door pennywiser op 30-09-2011 15:13 ]

[Cyphax]

pennywiser schreef op vrijdag 30 september 2011 @ 14:49:
Debian lost zelf vulnerabilities op in huidige repo versies, die heb je als het goed is al lang binnen gehad.

Ah, dus ze zouden die vulnerability hebben opgelost terwijl de versie van Apache gewoon op 2.2.16 blijft staan? Is dat het? Want dan ben ik dus klaar als 't goed is.

Als je gaat stoeien met teasting/unstable packages maak je systeem alleen maar meer vulnerable.

Dat wil ik dus echt voorkomen, vandaar dit topic. Ik heb dat ook niet gedaan verder trouwens.

Probeer ook niet, zoals je suggereert, allerlei dependencies tegen te houden, je komt er alleen maar mee in de problemen.

Nouja, dependencies tegenhouden hoeft ook niet, maargoed. Ik heb namelijk op gegeven moment apt-get install apache2 gedraaid, waarna een versie geïnstalleerd werd. Daarmee werden ook nieuwe versies van een aantal PHP-gerelateerde zaken geïnstalleerd, maar dat is dus geen punt.
Na die installatie veranderde het versienummer alleen niet. WEL de build-datum:

code:

Server version: Apache/2.2.16 (Debian)
Server built:   Sep  4 2011 20:27:43

Dat verklaart het een en ander dus.

liledevil schreef op vrijdag 30 september 2011 @ 14:59:
Zoals Vinzz zegt, Debian fixed ook de vulnerabilities in huidige versies.
Ik was nog op zoek naar een link waarin dit werd uitgelegd, maar kreeg dit helaas niet zo snel gevonden.

Nouja, als dat het geval is ben ik dus al lang blij. Ik weet (intussen meer "wist" dan "weet") alleen dus niet precies hoe dat werkt bij Debian. Ben meer een Slackwaregebruiker.

deadinspace schreef op vrijdag 30 september 2011 @ 15:03:
[...]

Niet doen.

Okee.

[...]

Welke?

Deze

Die is al lang gefixt in 2.2.16-6+squeeze2/3 (DST, DSA, Changelog).

Okee da's dus duidelijk intussen, prima dat ze dat zo doen verder, het is alleen voor mij even anders dan ik had verwacht en daarmee wat onduidelijk.

[...]
Ik raad af backports te gebruiken, tenzij je daar een specifieke reden voor hebt. Voor stabiliteit en veiligheid ben je beter af met vanilla stable.

Dat wil ik ook graag (om die redenen) dus ik ga die tip vooral volgen.

[...]
Verder:

• Lees de Debian security FAQ
• Abbonneer je op de debian-security mailinglist.
• Leer de security tracker gebruiken.

Ik zal er eens doorheen lezen. Hopelijk is het niet teveel, 'k kan er niet vele uren in steken helaas.
'k Heb me ook ingeschreven voor die mailinglist.

Dank je voor de linkjes.
Dank jullie allen, trouwens, voor de hulp en nuttige info.
Ik moet zeggen dat ik de manier waarop Debian dit regelt kan waarderen.

[pennywiser]

Cyphax schreef op vrijdag 30 september 2011 @ 15:27:
[...]

Ah, dus ze zouden die vulnerability hebben opgelost terwijl de versie van Apache gewoon op 2.2.16 blijft staan? Is dat het? Want dan ben ik dus klaar als 't goed is.

[...]

Dat wil ik dus echt voorkomen, vandaar dit topic. Ik heb dat ook niet gedaan verder trouwens.

[...]

Nouja, dependencies tegenhouden hoeft ook niet, maargoed. Ik heb namelijk op gegeven moment apt-get install apache2 gedraaid, waarna een versie geïnstalleerd werd. Daarmee werden ook nieuwe versies van een aantal PHP-gerelateerde zaken geïnstalleerd, maar dat is dus geen punt.
Na die installatie veranderde het versienummer alleen niet. WEL de build-datum:

code:

Server version: Apache/2.2.16 (Debian)
Server built:   Sep  4 2011 20:27:43

Dat verklaart het een en ander dus.

[...]

Nouja, als dat het geval is ben ik dus al lang blij. Ik weet (intussen meer "wist" dan "weet") alleen dus niet precies hoe dat werkt bij Debian. Ben meer een Slackwaregebruiker.

[...]

Okee.

[...]

Deze

[...]

Okee da's dus duidelijk intussen, prima dat ze dat zo doen verder, het is alleen voor mij even anders dan ik had verwacht en daarmee wat onduidelijk.

[...]

Dat wil ik ook graag (om die redenen) dus ik ga die tip vooral volgen.

[...]

Ik zal er eens doorheen lezen. Hopelijk is het niet teveel, 'k kan er niet vele uren in steken helaas.
'k Heb me ook ingeschreven voor die mailinglist.

Dank je voor de linkjes.
Dank jullie allen, trouwens, voor de hulp en nuttige info.
Ik moet zeggen dat ik de manier waarop Debian dit regelt kan waarderen.

Klopt, mooi, ja en goed zo.

Versienummer is wel veranderd, check maar met

code:

dpkg -l | grep apache

[deadinspace]

pennywiser schreef op vrijdag 30 september 2011 @ 15:08:
Om mijn Squeeze bak schoon te houden doe ik dit:

code:

apt-get update && apt-get dist-upgrade

apt-get clean && apt-get autoclean && apt-get autoremove

Ik doe alles met aptitude, die is een stuk krachtiger (zeker met de interactieve mode erbij).

Upgraden doe ik eigenlijk ook bijna altijd interactief, dus: aptitude starten en dan u, U, g, g (gevolgd door q, y ).

code:

deborphan | xargs apt-get --purge remove -y

Daar gebruikte ik vroeger ook deborphan voor, maar tegenwoordig raad ik aan om de automark functionaliteit van aptitude te gebruiken. Aptitude maakt onderscheid tussen packages die handmatig zijn geinstalleerd en packages die automatisch zijn mee-geinstalleerd om dependencies te voldoen. Automatisch geinstalleerde packages waar niks meer op depend worden verwijderd. In de interactieve mode van apt markeer je een package als auto-installed met M, en manually installed met m.

Opschonen kun je dan bijvoorbeeld doen door in aptitude je view te limiten naar handmatig geinstalleerde packages met l~i!~M, en de resulterende lijst door te lopen. Vervolgens kun je packages als auto-installed markeren (M), of verwijderen (- of _).

Cyphax schreef op vrijdag 30 september 2011 @ 15:27:
Deze

Jep, da's degene waar ik het over had (en die dus gefixt is). Volg de link "awaited fix" maar, en dan "announced a..." dan zie je dat ze het over CVE-2011-3192 hebben.

Als je de Debian security tracker en dergelijke niet kent, dan kun je een heel eind komen door te googlen op Debian CVE-2011-3192.

Okee da's dus duidelijk intussen, prima dat ze dat zo doen verder, het is alleen voor mij even anders dan ik had verwacht en daarmee wat onduidelijk.

En dat is natuurlijk het gevaar van het onderhouden van servers "als soort van nevenactiviteit"

Ik zal er eens doorheen lezen. Hopelijk is het niet teveel, 'k kan er niet vele uren in steken helaas.

De FAQ is niet superlang, en niet alle vragen zijn op jou van toepassing (sommigen zijn bedoeld voor Debian developers bv). Ik raad je aan iig alle vragen te lezen, en de antwoorden waar relevant.

Ik bedoelde overigens de debian-security-announce mailinglist, niet de debian-security mailinglist (die is meer voor discussie). De link in mijn vorige post was wel goed, maar de zichtbare naam niet.

Dank jullie allen, trouwens, voor de hulp en nuttige info.

Graag gedaan, we hopen dat je er wat aan hebt

Ik moet zeggen dat ik de manier waarop Debian dit regelt kan waarderen.

Het is een manier je veel werk bespaart, en gelukkig neemt Debian security serieus. Je moet wel opletten als je zelf software installeert buiten de stable repositories om (backports heeft wel security updates voorzover ik weet trouwens).

Ook doet Debian dit voor een release maar tot ongeveer een jaar na de release van een nieuwe versie. Zo zal de security support op 5.0 (Lenny) rond februari 2012 aflopen.