Closed (fixed)
Project:
Provision
Version:
6.x-2.x-dev
Component:
Debian package
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
21 Nov 2011 at 18:42 UTC
Updated:
28 Feb 2013 at 21:50 UTC
Right now the debian package installs Apache, and supports only apache. We should support nginx.
This should be minor changes, in debian/control:
-Depends: ${misc:Depends}, drush (>= 4.3), drush-make, php5-mysql, apache2, libapache2-mod-php5, aegir-provision (>= ${source:Version}), git-core, unzip
+Depends: ${misc:Depends}, drush (>= 4.3), drush-make, php5-mysql, apache2 | nginx, libapache2-mod-php5 | php5-fpm, aegir-provision (>= ${source:Version}), git-core, unzip
In debian/*postinst, something like this, but for aegir/webserver:
db_get "aegir/makefile"
if [ ! -z "$RET" ]; then
FLAGS="$FLAGS --makefile='$RET'"
fi
Also needs to be added to *templates and *config. From there, we need to figure out if special configuration is required for php5-fpm.
Comments
Comment #1
cweagansAny movement on this? I'd love to use Aegir with Nginx, but every time I've tried to set it up, it doesn't work very well. A standardized setup would be awesome.
Maybe it'd be worth it to do two separate packages: aegir-apache and aegir-nginx, with the default aegir package just being a metapackage that installs aegir-apache.
Comment #2
anarcat commentedomega8cc has talked about doing this in the last scrum.
i don't think it's worth having two packages. what I think is that we should have both webservers as dependencies and then decide in the postinst which one to configured (and maybe even the two!) based on which binaries are installed.
contrarly to what I stated in the original post above, I don't think we should prompt anymore. just install the damn thing and "do the right thing". :)
Comment #3
lelutin commentedhello.
just a suggestion: to make support broader:
here's how the "nagios3" package implements it's recommends list:
since the nginx provides 'httpd', it is possible to have nginx installed, and then install this package without it bringing in apache:
doing the same would open up support for nginx, and also lighttpd, and possibly others that provide 'httpd'.
Comment #4
anarcat commentedWell, the thing here is that Aegir *only* supports apache or nginx, it doesn't support lighttpd and "others" right now. So in effect, apache2|httpd would be wrong - we need to force the platforms we support!
But thanks for the tip!
Comment #5
anarcat commentedAlso, I think we should wait for the debian branch merge before going ahead with this, so we can test with 2.x for example: #1435144: get rid of the debian branch, make a native package...
Comment #6
omega8cc commentedWe have finally fully up to date Nginx config in 6.x-1.x and 6.x-2.x, so we can start working on this.
Comment #7
cweagansThe more I look at this, the more I think we ought to do separate pacakges, like aegir-apache and aegir-nginx, with "aegir" defaulting to install aegir-apache.
Seems like it will be a LOT more maintainable and will greatly simplify initial installations and upgrades.
Comment #8
anarcat commentedWould you care to expand on that? Why would it be more maintainable and simplify upgrades?
What happens if you uninstall aegir-apache and install aegir-nginx? In fact, what would those packages *do* if anything?
The usual way of doing this (see the phpmyadmin package for an example), is to have one package that can configure many web servers. It depends on either server and the operator basically chooses, at install time, which dependent package to install.
Comment #9
cweagansSo, aegir would be a metapackage that depends on either aegir-nginx or aegir-apache being installed. If you uninstall aegir-nginx, aegir would also get installed (same thing that would happen now if you ran apt-get remove aegir).
aegir-apache and aegir-nginx would each have the installation scripts for those respective servers, and would allow us to do things like, for instance, setting up certain caching mechanisms on certain servers. Right now, we don't have a need for this, but in the future, maybe it will be a need (for instance, running Aegir on Cherokee or Lighty). The reason that this split would simplify things is that in each of them, we just have to assume that the one server is being installed. Each package would be very straightforward. Likely, it would probably boil down to having common functionality in the aegir package, and server specific stuff in aegir-*.
Personally, I don't like the .deb packages that prompt me for input during installation. I want them to just install and tell me the postconfig tasks that need to happen when apt-get is finished.
Comment #10
anarcat commentedThe "aegir" package is currently totally empty, it is just a metapackage that provides dependency. I am puzzled as how you think changing that will make things easier.
I do not think that having everything in one package will make supporting extra servers harder. In fact I think it's the exact opposite, exactly because we *won't* have to create a special new package for this, just this one script (debian/postinst) and template file (debian/templates).
We do not need to prompt the user: we can check what packages are installed during those scripts and do clever guesses, while at the same time allowing user overrides with low-priority prompts that will not get showed by default.
The install instructions would change from:
to:
(ie. no change, no prompt by default) or:
if you want to install with nginx.
Comment #11
anarcat commentedI got bold and pushed a first draft of this to the 2.x branch. Hopefully the debian package won't explode under the load, but anyways as things stand the jenkins tests for the debian package are dead anyways.
So I am marking this as needs review, the patch is http://drupalcode.org/project/provision.git/commit/350f929
Comment #12
anarcat commented