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

cweagans’s picture

Any 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.

anarcat’s picture

omega8cc 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". :)

lelutin’s picture

hello.

just a suggestion: to make support broader:

here's how the "nagios3" package implements it's recommends list:

Package: nagios3-cgi
[...]
Recommends: apache2 | httpd, [...]

since the nginx provides 'httpd', it is possible to have nginx installed, and then install this package without it bringing in apache:

Package: nginx
[...]
Provides: httpd

doing the same would open up support for nginx, and also lighttpd, and possibly others that provide 'httpd'.

anarcat’s picture

Well, 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!

anarcat’s picture

Also, 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...

omega8cc’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev

We 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.

cweagans’s picture

The 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.

anarcat’s picture

Would 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.

cweagans’s picture

So, 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.

anarcat’s picture

The "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:

apt-get install aegir

to:

apt-get install aegir

(ie. no change, no prompt by default) or:

apt-get install nginx aegir

if you want to install with nginx.

anarcat’s picture

Status: Active » Needs review

I 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

anarcat’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.