[apache] vhosts werken opeens niet meer

[_Thanatos_]

Zojuist m'n server geupgrade naar Ubuntu 14.04, en ik dacht dat het wel goed gegaan was, maar ik kom er nu achter dat al m'n vhosts naar de maan zijn. Er is geen configuratie gewijzigd... En ja, hiervoor werkte alles.

Als ik een vhost in de browser open, dan krijg ik gewoon een indexpagina van /var/www. De accesslogs voor de vhosts komt doodleuk in other_vhosts_access.log terecht, en niet in de logs in in de vhost configs gedefinieerd staan.

Hoe instrueer ik apache om de vhosts gewoon te gebruiken?

Alles lijkt gewoon goed te zijn. En zoals ik al zei, er is geen config veranderd, de modtimes zijn gelijk gebleven zelfs. Ik kan ook niets raars ontdekken.

Hoe nu verder?

[Thc_Nbl]

kijk even of de "default" in je vhost-enabled config niet terug gezet is.

[GrandPuba]

Lijkt er meer op of je de default krijgt die naar eigenlijk alles wel luistert.
Zijn de vhosts wel nog enabled? staan deze in /etc/apache2/sites-enabled ?

Wellicht kan het zijn, dat deze niet meer enabled zijn, ivm overgang apache 2.4.

enable doe je met:
a2ensite VIRTUALHOSTNAME als root of met sudo

[ Voor 12% gewijzigd door GrandPuba op 21-03-2014 13:13 ]

[init6]

Mijn meeste kennis is redhat based, maar misschien helpt het je de goede kant op.
Onder redhat worden bij upgrades ook de httpd packages voorzien van nieuwe versie. Bij Redhat is er dan sprake van nieuwe opties in config files die dan geplaatst worden in configfile.conf.rpmnew zodat je op eigen gelegenheid configs kan aanpassen en bij de huidige werkende status blijft. Bij Fedora heb ik eens gezien dat je de keuze hebt bij upgraden om files te overschrijven, wie weet wat Ubuntu doet (ben wel nieuwsgierig)? Ik zou eens kijken in je httpd.conf of de sites-enabled of conf.d toegestaan is.

[ Voor 8% gewijzigd door init6 op 21-03-2014 13:16 ]

[GrandPuba]

@init6
Hier hetzelfde, echter denk ik dat vhosts uitgeschakelt kunnen zijn door apache 2.4 ( veel andere opties, niet altijd backwards compaitble, veel wel, en hierom dus weer handmatig inschakelen )
Idd, fedora en RHEL based doen dat ivm nieuwe opties of annotatie, je zou verwachten dat andere distro's dit ook doen alleen al om zeker te zijn dat zaken werken of blijven werken, of iig je het controleert / mogelijkheid hebt om te controleren.
Ik heb op debian iets vergelijkbaars gehad met een upgrade van de php versie en een module waardoor apache niet meer wilde starten.
Door logs te checken kwam ik erachter dat een module optie qua notatie niet meer hetzelfde was en ipv 128 nu 128M werd verwacht, ik kwam toen geen vergelijkbare bestanden als .rpmnew tegen ( logisch debian, maar iets vergelijkbaar dus )! wellicht was het hiervoor te specifiek...

[_Thanatos_]

Thc_Nbl schreef op vrijdag 21 maart 2014 @ 13:04:
kijk even of de "default" in je vhost-enabled config niet terug gezet is.

Die was teruggezet, en heb ik weer weggehaald. En apache gerestart.

GrandPuba schreef op vrijdag 21 maart 2014 @ 13:11:
Lijkt er meer op of je de default krijgt die naar eigenlijk alles wel luistert.
Zijn de vhosts wel nog enabled? staan deze in /etc/apache2/sites-enabled ?

Ze staan er nog vrolijk...
Wat wel is, als ik een syntaxfout in een van de vhost configs maak, kan apache gewoon vrolijk opstarten... net alsof hij ze gewoon niet oppikt.

En dat terwijl dit in de apache2.conf gewoon staat:

code:

IncludeOptional sites-enabled/*.conf

/edit
Ohw awesome. Er is toch wel iets sneaky gebeurd, want de vhost configs hebben niet de .conf extensie (nooit gehad) en de IncludeOptional directive verwacht dat wel (maar is echt altijd zo geweest). En waarempel, als ik die in een gewone Include directive verander, krijg ik een fout bij het restarten dat hij geen confs kan vinden. Oh dear. Er zijn dus files gewijzigd en de installer heeft stiekem de modtimes teruggezet

/edit2
Yup dat was hem. Sorry voor de stomme fout. Maar op een gegeven moment ga je blindstaren en zie je het niet meer. Toch bedankt voor de duwtjes in de juiste richting

[ Voor 27% gewijzigd door _Thanatos_ op 21-03-2014 14:01 ]

[GrandPuba]

En als je een a2dissite VIRTUALHOSTNAME doet, dan service apache2 reload of restart en daar weer a2ensite VIRTUALHOSTNAME om hem aan te zetten en weer service apache2 reload /restart doet hij het dan wellicht wel?
Kun jij verifieren dat het apache 2.4 is?
Wellicht kun je alle vhosts echt disablen en dan proberen met één vhost om werkend te krijgen?

Is er echt niets te zien in logs?

Misschien vind je hier wat zaken welke de problemen veroorzaken: https://httpd.apache.org/docs/trunk/upgrading.html

[GrandPuba]

Ik heb hier een debian 7.4 met apache2.2

Wat jij zegt is denk ik dus ook veranderd want in die debian staat het volgende met apache2.2

Include sites-enabled/

Het is overigens best normaal om de vhostnaam.conf te noemen.
Je kunt er denk ik wel vanuit gaan, dat dit is gewijzigd in de nieuwe config, dat dit vervangen wordt zonder te melden etc. is erg tricky.

[_Thanatos_]

Ik mag er verdorie vanuit gaan dat de installatie van een nieuwe versie (minor of major) met z'n tengels van mijn config afblijft. Ik heb er bloed zweet en tranen in gestoken (figuurlijk dan heh) en dan zal hij het wel even gaan vernaggelen.

Helaas weet ik niet precies wat er in deze gebeurd is, maar hoe dan ook moet een installer niet aan config komen. Zeker niet als de boel daarmee vernaggeld raakt. Simple as that.

[8088]

Debian (en naar ik aanneem Ubuntu) heeft als policy dat bij een upgrade configuratiebestanden alleen overschreven worden als deze niet aangepast zijn. Als ze wel aangepast zijn, dan zal er tijdens het upgraden eerst om toestemming gevraagd worden.

Om herhaling te voorkomen, kun je apache2.conf ongemoeid laten en een nieuw bestand in conf.d/ met de regel Include sites-enabled/ (of IncludeOptional sites-enabled/) plaatsen.
Ehm..dat zal niet alle problemen voorkomen, zoals RobertMe hieronder aangeeft. En Debian-gebruikers zullen er bij een dist-upgrade ook aan moeten geloven:

code:

#   Yet we strongly suggest that all configuration files either end with a
#   .conf or .load suffix in the file name. The next Debian release will
#   ignore files not ending with .conf (or .load for mods-enabled).

_{uit apache2.conf van Debian 7.4}

[ Voor 31% gewijzigd door 8088 op 23-03-2014 19:08 ]

[RobertMe]

Buiten dat Include nu met *.conf is, werkt a2ensite ook alleen maar met .conf files. Het beste zou het dus zijn om de files te hernoemen, zodat ze in sites-available .conf heten, en dan ook in sites-enabled (let op dat de bestanden in sites-enabled symlinks naar sites-available zijn, en je de symlinks dus ook aanpast).

[Hero of Time]

_Thanatos_ schreef op zondag 23 maart 2014 @ 18:11:
Ik mag er verdorie vanuit gaan dat de installatie van een nieuwe versie (minor of major) met z'n tengels van mijn config afblijft. Ik heb er bloed zweet en tranen in gestoken (figuurlijk dan heh) en dan zal hij het wel even gaan vernaggelen.

Helaas weet ik niet precies wat er in deze gebeurd is, maar hoe dan ook moet een installer niet aan config komen. Zeker niet als de boel daarmee vernaggeld raakt. Simple as that.

Assumptions is the mother of all fuckups! Ga nooit, maar dan ook nooit ergens vanuit. zeker als je configs aanpast en je updates unattended laat plaatsvinden. Dan kan je er vergif op innemen dat je je config verliest. Helemaal als je apache2.conf verandert, want die wordt dan gewoon vervangen door de distro meegeleverde versie. Zoals hierboven al is aangegeven zou je een melding over moeten krijgen, maar als je overal maar "ja" of "yes" op antwoord, ben je niet zo handig bezig. Dan lijk je meer op de doorsnee Windows gebruiker "next, next, ja op alle bende, next, finish, mot ut nu hebbuh".

Ook het niet hebben van backups, zeker als je updates en upgrades gaat uitvoeren is geen handige zet. Als je config aangepast wordt door een update kan je die altijd terugdraaien hierdoor. Nu heeft Debian gelukkig dat ze je config hernoemen als deze overschreven wordt, of als je de nieuwe versie niet accepteert wordt de meegeleverde config met de naam .dpkg-new neergezet.

Evenals, je hebt een upgrade naar 14.04 gedaan. Die release is nog niet eens final. Van welke release kwam je? Ben je niet van apache 2.2 naar 2.4 gegaan, zoals die in 14.04 zit? 12.04, de vorige LTS, zat nog op 2.2.

Zomaar gaan vloeken en tieren zonder te weten wat je doet is het slechtste wat je kan doen. Je hebt doelbewust de upgrade naar een non-final release uitgevoerd. Je hoort te weten dat de boel dan stuk kan gaan. En dus backups moet hebben voordat je die stap onderneemt.

[robkorv]

In 2.4 hebben ze rigoureuze config veranderingen doorgevoerd, zover dat de meeste vhosts breken.
Zie hier een voorbeeld http://robkorv.com/posts/...-virtual-host-for-apache/

Meer info -> http://httpd.apache.org/docs/2.4/upgrading.html