Is it within the scope of this bug to consider renaming the Apache site config files upon package upgrade?  It would have to happen anyway, and since Apache 2.2 is perfectly happy if the files have a .conf extension, it would be possible for koha-create to not have to check the Apache version.

I can't see Apache 2.4 in wheezy, however that's not an excuse to not get this patch in sooner rather than later.

I don't think checking the apache version is necessary, I think, as Galen suggests, we should transition to this by renaming all the existing apache files (as shown by koha-list) to have a .conf suffix. This can be done in a postinst type thing. Note that it should ask the admin if they want to do this on the upgrade, so they a) can opt out, and b) know what's going on.

koha-create should use .conf for all new ones though

All the scripts should check for a .conf version, and if that doesn't exist, a version without the .conf. It might be a good excuse to start building a shared library for the scripts so you can go 'get_apache_config_for($site)' and it does the right thing.

Anyway, opinions on this welcome.

Apache 2.4 breaks more than just the .conf stuff.

It also changes the way you define access (like Tomás noted) this bit me on my Ubuntu Saucy test machine.

So it might be good to do all the work fixing the config file for 2.4 on this?

(In reply to Chris Cormack from comment #4)
> So it might be good to do all the work fixing the config file for 2.4 on
> this?

I agree, so I've changed the title of the bug accordingly.

Hi,
(In reply to Galen Charlton from comment #5)
> (In reply to Chris Cormack from comment #4)
> > So it might be good to do all the work fixing the config file for 2.4 on
> > this?
> 
> I agree, so I've changed the title of the bug accordingly.

Chris Cormack is right, starting from a clean Ubuntu Saucy install, using Apache 2.4.6, I got problems with the mpm_event module and AssignUserId:

http://mpm-itk.sesse.net/

Seems there is a problem from 2.2.2 until 2.4.7
http://debian.2.n7.nabble.com/mpm-itk-and-mod-fcgid-td3014876.html

my quick fix was to swap the mpm_event and mpm_itk :

sudo a2dismod mpm_event
sudo a2enmod mpm_itk

As for the .conf issue in Apache 2.4.6+, perhaps it is better to change to .conf altogether, if it won't break previous versions?

Regards
Benjamin Rokseth
Oslo Public Library

(In reply to Benjamin Rokseth from comment #6)
> As for the .conf issue in Apache 2.4.6+, perhaps it is better to change to
> .conf altogether, if it won't break previous versions?

There are some scripts that assume the Apache config files are named witt just the instance name, without a .conf extension, so those will have to be updated too. But I agree, we might as well do this sooner rather than later.

(In reply to Benjamin Rokseth from comment #6)
> Hi,
> (In reply to Galen Charlton from comment #5)
> > (In reply to Chris Cormack from comment #4)
> > > So it might be good to do all the work fixing the config file for 2.4 on
> > > this?
> > 
> > I agree, so I've changed the title of the bug accordingly.
> 
> Chris Cormack is right, starting from a clean Ubuntu Saucy install, using
> Apache 2.4.6, I got problems with the mpm_event module and AssignUserId:
> 
> http://mpm-itk.sesse.net/
> 
> Seems there is a problem from 2.2.2 until 2.4.7
> http://debian.2.n7.nabble.com/mpm-itk-and-mod-fcgid-td3014876.html

Benjamin, I'm about to start working on a fix for this. Could you please email me evidence or steps to reproduce the AssignUserId problem? I'm building a 13.10 VPS to try to reproduce it.

Dear Tomás,
Sorry for the late reply!

all I can say is there seems still to be dependency issues and mpm_event gives the following errors:

vagrant@vagrant-saucy64:~$ sudo a2enmod mpm_event
Considering conflict mpm_worker for mpm_event:
Considering conflict mpm_prefork for mpm_event:
Considering conflict mpm_itk for mpm_event:
Enabling module mpm_event.

which disables the 'AssignUserID' variable and fails apache:
AH00526: Syntax error on line 13 of /etc/apache2/sites-enabled/knakk.conf:
Invalid command 'AssignUserID', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.

swapping the mpm_event module with mpm_itk makes everything work:
http://mpm-itk.sesse.net/

Hope you find a more robust solution!

A note from the debian testing changelog:

  MPM ITK users should be advised, that ITK is not a MPM anymore. Instead, it
  is a simple Apache module, expanding functionality of the prefork MPM. Thus,
  users should switch to the prefork MPM and enable ITK as a module. The
  upgrade scripts ensure this for the upgrade from Debian Wheezy.

(In reply to Robin Sheat from comment #10)
> A note from the debian testing changelog:
> 
>   MPM ITK users should be advised, that ITK is not a MPM anymore. Instead, it
>   is a simple Apache module, expanding functionality of the prefork MPM.
> Thus,
>   users should switch to the prefork MPM and enable ITK as a module. The
>   upgrade scripts ensure this for the upgrade from Debian Wheezy.

Yep, unfortunately that breaks horribly with our config

I was just bitten by the new "Access control" things described here:
https://httpd.apache.org/docs/2.4/upgrading.html#access
(On Ubuntu, recently upgraded to 14.04.)

Even if we provide a workaround in the packages scripts there will be problems for users until this is fixed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734865

Note that this is a candidate for 3.16 RC

Hi, I need feedback on both the approach and testing the effective results of this patches.

Contact me on IRC or email for whatever doubt or comment you might have.

Tested and signed off on these, also added a patch that will improve the behaviour:

* Only ask the questions if there is a Koha apache file without .conf (this'll also stop it asking on new installs, and so on.)
* Account for the fact that a2dissite will fail with an old configuration form on apache 2.4.

Note that the ITK thing isn't something we can fix readily. However, we might be able to detect it and throw out warnings with instructions. The easy way is simply:

sudo a2dismod mpm_event

This will be added to the documentation on the wiki, and whereever else we can.

I've grabbed this for inclusion in 3.16.0.  Thanks, Tomás!

Created attachment 28370 [details] [review]
[PASSED QA] Bug 11404: Apache 2.4 expects the sites definition files use the sufix '.conf'

To reproduce:
- Install the 'koha-common' package on Debian 7 or Ubuntu 13.10+
  (both known to include Apache 2.4).
- Create an instance (for example testlibrary) using the supplied commands:
 $ koha-create --create-db testlibrary
> FAIL: apache reports an error like this:
"ERROR: Site testlibrary does not exist!"

This patch adds a test on the Apache version and appends the needed ".conf" sufix
if needed.

To test:

1st step: koha-create gets fixed:

-- The hard way --
- Apply the patch, and build the koha-common package on top of this commit.
- Install the built package on an Apache 2.4 Debian-based distro (Debian 7 or Ubuntu 13.10 will work)
- Create a test instance:
 $ koha-create --create-db testlibrary
> SUCCESS: no more apache sites related error.

-- The easy way --
- Apply the patch, and copy the koha-create into an Apache 2.4 Debian-based distro
- Create a test instance using the koha-create script you just copied:
 $ ./koha-create --create-db testlibrary
> SUCCESS: no more apache sites related error.

2nd step: the rest of the touched scripts keep working as usual

koha-disable
koha-dump
koha-enable
koha-list
koha-remove
koha-restart-zebra
koha-stop-zebra
koha-start-zebra

They should all keep working. Can be tested "the easy way" too.

Then sign on the patch.

Note: there might be another issues regarding Apache 2.4 deployments like the need for

 $ a2enmod access_compat

and perhaps some directory permissions tweak, which I think should be properly
documented on the install instructions.

Regards
To+

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 28371 [details] [review]
[PASSED QA] Bug 11404: koha-functions.sh introduced for reuse

As asked by Robin, a bash lib of functions is introduced with the common
functions to be reused. Most of the scripts are modified (reduced) to include
this file and the repeated functions cleaned.

No noticeable change in behaviour should be noticed.

As I've been said in #debian-mentors, it is used that files for inclusion
should be installed at the apps directory (i.e. /usr/share/koha/) so this
patch makes the install script put the file in the bin/ directory.

All koha-* scripts assume the file is there already (and fail otherwise).

Regards
To+

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 28372 [details] [review]
[PASSED QA] Bug 11404: Make the install process aware of the changes

This patch makes the install scripts take care of the new file
and prompt for user confirmation on the apache file renaming step.

Both prompt and the renaming actions depend on the fact that there
are instances with their files missing the .conf appendix.

Regards
To+

Sponsored-by: Universidad Nacional de Cordoba
Signed-off-by: Robin Sheat <robin@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 28373 [details] [review]
[PASSED QA] Bug 11404: only ask user if there are instances needing upgrading

There's no point asking the user if they want their Apache Koha
configuration updated if there's no configuration needing updated.

This also fixes a case where the updating would have failed when running
on Apache 2.4.

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
I agree with adding that checks, and the conditions rewrite seems cleaner
than my first approach. So, I sign it.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Looks like you actually just beat me to this one Galen, apologies.

Well, It's been doubly tested at least ;).. I built packages and tested it every way I could think of, and it works nicely.

Patch already included in 3.16.x branch