Menu
▾
▴
mailadmin-devel
|
From: James A. P. <ja...@pc...> - 2004-03-16 15:49:34
|
-----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----- -- 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. |
|
From: Chris B. <ch...@hu...> - 2004-03-16 17:08:27
|
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 |
|
From: James A. P. <ja...@pc...> - 2004-03-16 19:40:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Do you want to just go with option 1 or create the /etc/mailadmin and move the config.inc into 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. | | 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 iD8DBQFAV1gjtUXjwPIRLVERAqiHAKC1Buxy8L7/uwxpGZAyUIiXPLLm9gCgrhsf as0YuegKp8gPkJ7IhdgmEvA= =2+oc -----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. |
|
From: Chris B. <ch...@hu...> - 2004-03-24 16:31:49
|
Hi James, Sorry for the delay, I've only just now gotten back from England... On Tue, 2004-03-16 at 15:40, James A. Pattie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > 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 > > iD8DBQFAV1gjtUXjwPIRLVERAqiHAKC1Buxy8L7/uwxpGZAyUIiXPLLm9gCgrhsf > as0YuegKp8gPkJ7IhdgmEvA= > =2+oc > -----END PGP SIGNATURE----- -- Chris Bowlby <ch...@hu...> Hub.Org Networking Services |
|
From: James A. P. <ja...@pc...> - 2004-03-25 05:10:49
|
-----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----- -- 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. |
|
From: Chris B. <ch...@hu...> - 2004-03-25 13:36:04
|
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 |
|
From: Chris B. <ch...@hu...> - 2004-03-25 14:21:02
|
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 |
|
From: James A. P. <ja...@pc...> - 2004-03-25 16:17:45
|
-----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. |
|
From: Chris B. <ch...@hu...> - 2004-03-25 16:33:23
|
I'll see if I can do it by tomorrow.. On Thu, 2004-03-25 at 12:17, James A. Pattie wrote: > -----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----- -- Chris Bowlby <ch...@hu...> Hub.Org Networking Services |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X