Re: [Mailadmin-devel] packaging mailadmin and apache include files, etc.

[Chris B. <ch...@hu...>]

Ok, these all work, for the record, I'm going to be in the UK for the
week and may not be accessable until I get back... As for the changes
below, all of them sound like good ideas, but we also need to keep a
bare bones tar ball available for those not using debian..

On Tue, 2004-03-16 at 11:49, James A. Pattie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm thinking about debianizing the mailadmin package to make it easier to deploy
> on the mail servers we build and have already deployed, etc.
> 
> I'm proposing we suggest that mailadmin is installed into /usr/share/mailadmin/
> and we create an apache include file which sets up the alias and directory for
> that.  We can then also add the mailadmin/includes directory and say that it is
> off limits to web requests.  This will protect the config.inc file.
> 
> Alternatively, we can also create an /etc/mailadmin and put the config.inc file
> there plus the apache include file and update the code to source the config.inc
> file from /etc/mailadmin.  This means we don't have to explicitly protect the
> includes directory and is more inline with the way debian likes packages layed
> out (config files in /etc/<package name> and web content in /usr/share/<package
> name>).
> 
> If we don't do the /etc/mailadmin, I was thinking of putting the apache config
> file in /usr/share/mailadmin/includes/.
> 
> I also think the config.inc.dist file should have better defaults than just
> saying your.server.here, etc. but use 127.0.0.1 for the mail servers.  The
> cookie domain is trickier.  I think I'll probably do a post-install step that
> does a hostname and substitutes that in.
> 
> The reason I think we should put 127.0.0.1 is that right now, you can't have
> mailadmin installed on a remote server if you want to change sasl passwords.  We
> might want to add a flag that indicates you are remote and thus removes the
> ability to add/delete users and/or change passwords until we add the ldap
> backend support, etc.  This way people can use it to set quotas and acls and not
> complain that the password code doesn't work.
> 
> Thoughts?
> - --
> James A. Pattie
> ja...@pc...
> 
> Linux -- SysAdmin / Programmer
> Xperience, Inc.
> http://www.pcxperience.com/
> http://www.xperienceinc.com/
> http://www.pcxperience.org/
> 
> GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFAVyICtUXjwPIRLVERAjt2AJ90Ia2JCosyMsnro5O4QSf8JMpwPgCfSJQX
> c+Nf9iAvtwUi2aWpS4Xbht8=
> =DTn6
> -----END PGP SIGNATURE-----
-- 
Chris Bowlby <ch...@hu...>
Hub.Org Networking Services