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

[James A. P. <ja...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Do you want to make the release or me?

Right now, I won't have time till maybe Friday night and even then I'm not 100%
sure I have the time. :(

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

iD8DBQFAYwYftUXjwPIRLVERAqDCAKCWWYA6nWe/DUjf8DdJhDHw/fK9xwCg0nNu
f55BSu7RrB8CChizqwBpgP8=
=DcPC
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.