On Sun, 27 Dec 2015 11:22:56 +0000 (UTC) Juuso Lapinlampi <w...@partyvan.eu> wrote: > I'm having a bit of hard time installing Mailman from ports to an > alternative `DESTDIR` chroot on OpenBSD 5.8 -stable, GENERIC.MP amd64. I > have a working Mailman setup in a non-chroot environment and I'm trying > to move it to a chroot. I've partially succeeded in doing so, but it > seems `DESTDIR` is not working on this port. > > For those not yet aware, Mailman is a mailing list software written in > Python that interacts with CGI to provide a web interface for mail > archives and control panel. > > By default, Mailman packages will install to `/usr/local/lib/mailman/`. > For this to work with Mailman's web interface, both OpenBSD httpd(8) and > slowcgi(8) must be chrooted to `/` to be able to access Mailman's needed > files. For obvious reasons, running slowcgi with `-p /` is not > recommended from security perspective and is actively discouraged by > OpenBSD developers. > > Ideally, Mailman should be installed to a chroot at `/var/www` > (`/var/www/usr/local/lib/mailman/`). This is what I'm looking for. > Because the packages for Mailman don't do this by default, I am trying > to use the ports to customize the DESTDIR. > > It seems this port doesn't play very well with `DESTDIR` however. I've > tried at least > > cd /usr/ports/mail/mailman/ > make > DESTDIR="/var/www" make install > > among other similar things (e.g. using `env DESTDIR="/var/www"`), but it > seems Mailman will be installed to `DESTDIR=/` (that is, > `/usr/local/lib/mailman/`). > > The Makefile itself has this comment: > > # gnu still breaks the pathes as prefix is actually mailman's home > CONFIGURE_STYLE= simple > > This might be the blocker, but I am not sure what to do with it. Maybe > any of porters have a better idea. > > Right now I also tried creating a package and installing it with > `pkg_add(1)` to work around the issue: > > cd /usr/ports/mail/mailman/ > make > make uninstall package clean > pkg_add -B /var/www /usr/ports/packages/amd64/all/mailman-2.1.20.tgz
if i am reading you right, you probably only need that last pkg_add. i regularly use chroot for a number of packages (and their complex dependencies), and the packages are the normally compiled versions. the line from my scripts which is pretty much identical, is: $ env PKG_DBDIR=$_dbdir pkg_add -B $_jaildir $_pkg except i use PKG_DBDIR for an alternative to /var/db/pkg. but your pkg_add should install to '/var/www/usr/local/lib/mailman/'. and within the the chroot it will see it as /usr/local/lib/mailman so there shouldn't be a problem unless mailman doesn't play nice in a chroot (there are a number of packages that don't). my notes on using chroot here may be useful: https://marc.info/?l=openbsd-misc&m=142676615612510&w=2 > > and this seems to be a success, assuming the dependencies are okay and > also in the chroot (they're not, yet). Now my problem is getting > `DESTDIR` for the dependencies. I'm not also sure if using `pkg_add(1)` > like this is a great idea. i think you are looking in the wrong direction with DESTDIR. i have never found modifying ports/packages necessary. > > The closest advice I found for installing Mailman to an OpenBSD chroot > was a `mailman-users` mailing list post from 2008.[1] However, this > advice is quite dated and relies too much on copying Mailman manually > and building Mailman from source instead of ports. Not what I'm looking > for. > > It seems `/ports/mail/mailman/` hasn't changed in `-current` tree or in > the past 8 months, so I could probably reproduce my issue there but I've > not yet tested so. > > I could move or copy Mailman and all of its dependencies manually under > `/var/www` chroot, but this doesn't seem to be a good idea from > maintenance perspective. > > Can I do something to build Mailman and its dependencies with > `DESTDIR=/var/www` for easier maintenance? > > [1]: https://mail.python.org/pipermail/mailman-users/2008-April/061331.html > for maintainance, just do the reverse, and 'pkg_delete -B /var/www ...' or if you use PKG_DBDIR=/var/www/pkgdb (or something similar) you can just delete the packages and the pkg database manually, and install the new versions.
