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

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

Actually, never mind, we'll work on that for v2.0, go for a release of
1.5.2 tomorrow..

On Thu, 2004-03-25 at 09:36, Chris Bowlby wrote:
> k, I just thought of a few sample configurations that I'd like to add as
> well, I will do that today and let you know once they are done.
> 
> On Thu, 2004-03-25 at 01:10, James A. Pattie wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Chris Bowlby wrote:
> > | Hi James,
> > |
> > |  Sorry for the delay, I've only just now gotten back from England...
> > 
> > That's ok.  I haven't had that much free time to hack on mailadmin anyway. :)
> > 
> > |
> > | On Tue, 2004-03-16 at 15:40, James A. Pattie wrote:
> > |
> > | Chris Bowlby wrote:
> > | | 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..
> > |
> > | The debianized tarball is just a debian subdirectory with the control files,
> > | etc. in it to be able to build a .deb from the tarball.  It doesn't hurt to
> > | include it, just like it doesn't hurt to include an rpm .spec file, though that
> > | really means we should move the current web content into a sub-folder in the
> > | released tarball.
> > |
> > |
> > |
> > |>  K, as long as we can create a Debianized and non-debianized package we
> > |> should be fine.
> > 
> > I'm thinking of keeping the debianized version seperate for now since it will
> > require some hacking to make things work in the approved Debian ways.
> > 
> > I think we are about as ready as we are going to be for a release at this time.
> > 
> > |
> > |
> > | Do you want to just go with option 1 or create the /etc/mailadmin and move the
> > | config.inc into it?
> > |
> > |
> > |
> > |>  I'd leave it in the main path, but we should change the config.inc to
> > |> config.inc.php so that someone can not get at the variables that are
> > |> defined within it.
> > |
> > |
> > | If we go with the second option, then we really need to create an install script
> > | that the user runs to install and do all the setup, so we can use the current
> > | layout and just move files around, etc.
> > |
> > |
> > |
> > |>  Agreed.
> > |
> > |
> > | |
> > | | On Tue, 2004-03-16 at 11:49, James A. Pattie wrote:
> > | |
> > | | 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
> > 
> > iD8DBQFAYmnLtUXjwPIRLVERAuLaAJ972oovW9pOY47D3DANEZt6svji+gCfeoJb
> > LtoXN6IZOP3Avz1KX/rNgfc=
> > =uVlb
> > -----END PGP SIGNATURE-----
-- 
Chris Bowlby <ch...@hu...>
Hub.Org Networking Services