We updated one of our test servers today to 3.16. It's a Debian server and the question to update Apache configuration for 2.4 appeared, yes is preselected. But the update will break the Apache configuration if you don't have 2.4 or later, because of the changes to permissions (I think). Just wanted to put this out here, as there might be more people experiencing this. It would be great if the script could check for the Apache version and only display the question when a new version is detected.
Off the top of my head, I don't think it will break on apache 2.2.
According to my coworder it did, he had to repeat the process with 'no'. I think because of the change in the permissions.
Well, I am not sure what it was, but he said it was broken :)
Some of the first comments on bug 11404 say we should add the .conf suffix even if you have Apache 2.2, so you won't get surprised when you eventually upgrade to 2.4.
Did someone test it with an older Apache?
I did a test, and found the issue. It's nothing to do with permissions, it's that if you do: a2ensite foo apache 2.2 will look for /etc/apache2/sites-available/foo and apache 2.4 will look for ..../foo.conf. Our script does a2ensite foo, when it should do a2ensite foo || a2ensite foo.conf to cover both cases. I'll make a patch up for this and role out a new package with it once it's been checked out.
Oh, we can't do the renaming dependent on the apache version, as we wouldn't get the chance to fix the files until the next Koha upgrade. They need to be fixed before an upgrade to 2.4
Created attachment 28474 [details] [review] Bug 12312 - correctly upgrade under apache 2.2 As the way we need to reference apache instance names has now changed between 2.2 and 2.4, we need to try it out both ways to make sure we get it right. This also allows koha-create/koha-disable to try the .conf version of the name if the first one doesn't work. To test: * Create an instance on an apache 2.2 system with koha < 3.16 * Upgrade to 3.16 with this patch, saying 'yes' to the renaming question ** Make sure you don't see the warning: Warning: problem enabling $site in Apache * Do a 'service apache2 restart' * Make sure you can still access the instance * Make sure that /etc/apache2/sites-enabled/instance.conf exists as a link to /etc/apache2/sites-available/instance.conf * Check that koha-create and koha-remove behave like you'd expect. Note: * If you need to make debconf forget that it asked you the question about renaming so that it'll do it again, then run: echo "unregister koha-common/rename-apache-vhost-files" | sudo debconf-communicate koha-common * 'debconf-show koha-common' will show you the current debconf configuration.
When this has been double-checked by someone, I'll do a rebuild of the 3.16.0 and master packages with it included.
BTW a workaround if you hit this issue: Just run: sudo service a2ensite instancename.conf
Pushed to master and 3.16.x. Thanks, Robin!
Robin: I have created a special tag called v3.16.00-pkg for you to use when creating a replacement 3.16.0 package.
Thx Galen and Robin!
If I understand this correctly, including the ".conf" suffix will only cause problems with the koha-enable and koha-disable scripts? I ran the upgrade with "yes" and it worked fine on my Debian system, but I didn't/haven't done any enabling/disabling. I would be surprised if including the suffix broke anything else in regards to Apache 2.2, as other systems (like OpenSuse and Fedora) use ".conf" suffixes by default.
According to my coworker he didn't run any koha- commands - not sure where the problem was, but it seems to be all fixed now with the patch :)
It was because the postint script says "a2ensite foo" when it needs to say "a2ensite foo.conf" on 2.2, so the site never got reenabled after the update. Now if just the name fails, it tries with .conf, which hopefully works.