Menu
▾
▴
mailadmin-devel — General Developers List
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(21) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: <ben...@id...> - 2004-05-25 09:21:56
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: James A. P. <ja...@pc...> - 2004-03-31 19:32:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Bowlby wrote: | Hadn't started it yet :> ok. When you do, please post to this list so any other developers are aware. PS. Do we maybe want to post announcements on this list when new releases are done, since I'm not subscribed to any other lists? :) | | On Wed, 2004-03-31 at 14:04, James A. Pattie wrote: | | Chris Bowlby wrote: | | I'd like to start a totally new branch for 2.0, and re-write alot of the | | stuff that was in 1.x so that it's more fluid and better manageable in | | 2.0... | | | | Be it a new branch, or start a new trunk or what ever.. | | agreed. I just wanted to know if you had started the "branch" and what it is | called so when I start hacking I'm in the right place. :) | | | | | On Wed, 2004-03-31 at 12:30, James A. Pattie wrote: | | | | Are we still developing on the 1.5.2 branch or are we moving back to the trunk? | | | - -- 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 iD8DBQFAaxzRtUXjwPIRLVERAhMdAJ98tYH92HE0B002GyuonrvI6HXakgCfXkzl bQ1c6AZtFOQxw+Qph/EFcO8= =ClyY -----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-31 18:43:33
|
Hadn't started it yet :> On Wed, 2004-03-31 at 14:04, James A. Pattie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Bowlby wrote: > | I'd like to start a totally new branch for 2.0, and re-write alot of the > | stuff that was in 1.x so that it's more fluid and better manageable in > | 2.0... > | > | Be it a new branch, or start a new trunk or what ever.. > > agreed. I just wanted to know if you had started the "branch" and what it is > called so when I start hacking I'm in the right place. :) > > | > | On Wed, 2004-03-31 at 12:30, James A. Pattie wrote: > | > | Are we still developing on the 1.5.2 branch or are we moving back to the trunk? > | > > - -- > 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 > > iD8DBQFAawgetUXjwPIRLVERArnfAJ9bEr+2iZT3oP3Gvh645lDwRg68fgCgiLcc > 963SdYIDBbcI7jP9xavc7XM= > =LIZH > -----END PGP SIGNATURE----- -- Chris Bowlby <ch...@hu...> Hub.Org Networking Services |
|
From: James A. P. <ja...@pc...> - 2004-03-31 18:04:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Bowlby wrote: | I'd like to start a totally new branch for 2.0, and re-write alot of the | stuff that was in 1.x so that it's more fluid and better manageable in | 2.0... | | Be it a new branch, or start a new trunk or what ever.. agreed. I just wanted to know if you had started the "branch" and what it is called so when I start hacking I'm in the right place. :) | | On Wed, 2004-03-31 at 12:30, James A. Pattie wrote: | | Are we still developing on the 1.5.2 branch or are we moving back to the trunk? | - -- 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 iD8DBQFAawgetUXjwPIRLVERArnfAJ9bEr+2iZT3oP3Gvh645lDwRg68fgCgiLcc 963SdYIDBbcI7jP9xavc7XM= =LIZH -----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-31 16:50:36
|
I'd like to start a totally new branch for 2.0, and re-write alot of the stuff that was in 1.x so that it's more fluid and better manageable in 2.0... Be it a new branch, or start a new trunk or what ever.. On Wed, 2004-03-31 at 12:30, James A. Pattie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Are we still developing on the 1.5.2 branch or are we moving back to the trunk? > > - -- > 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 > > iD8DBQFAavIXtUXjwPIRLVERAhJtAJ48c+8cErS6z8zUYkJM6tw65W8y3QCffkSj > Vjh8gtGEpKgMPg4pAbDbcvY= > =o+WM > -----END PGP SIGNATURE----- -- Chris Bowlby <ch...@hu...> Hub.Org Networking Services |
|
From: James A. P. <ja...@pc...> - 2004-03-31 16:30:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are we still developing on the 1.5.2 branch or are we moving back to the trunk? - -- 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 iD8DBQFAavIXtUXjwPIRLVERAhJtAJ48c+8cErS6z8zUYkJM6tw65W8y3QCffkSj Vjh8gtGEpKgMPg4pAbDbcvY= =o+WM -----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-31 11:45:25
|
At 12:17 AM 3/31/04, James A. Pattie wrote:
>Adding support for ldap or other authentication backends where we would create
>users in them and not the sasl interface, but the rest of the functionality is
>still imap based (quotas, acl's).
k, we just need to make sure we have various options enabled to be able to
do that...
>This should be customizable. By default we stick with the sasl/sasl2
>interface
>and have a config option to let the user say we want to use ldap, mysql,
>whatever.
>
>I guess I'm thinking of:
>
>userBackend = 'sasl2'; // sasl, sasl2, ldap
This would help manage it :>
>We should probably install /etc/mailadmin/settings.{php,pl} config files that
>get included by the config.inc file or the perl scripts (assuming we still
>need
>them) and thus let the perl scripts be able to get the backend to use (sasl,
>sasl2, etc.), the admin username and password, and imap seperator without us
>having to pass them in on the command line.
That works, sounds cool..
>By having a global /etc/mailadmin/settings.{php,pl} file, we can have an
>install
>script that asks the user what the database name is, user to use, etc.,
>populate
>the config file snippet and create the database and have our
>/usr/share/mailadmin/includes/config.inc file just source that file. All the
>critical user changes would be in /etc/mailadmin/settings.{php,pl} which will
>get around some of the limitations that different distros have in having a
>config file in /usr. (Debian comes to mind)
>
>That should help upgrading to be much easier.
agreed.
|
|
From: James A. P. <ja...@pc...> - 2004-03-31 04:17:25
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Bowlby wrote:
| At 06:38 PM 3/29/04, Chris Bowlby wrote:
|
|> Hi All,
|>
|> Ok, now that 1.5.2 is out the door, I'd like to retire that package
|> so we can work on a newer version that is much more flexible, and can
|> be configured fairly easily. 1.5.x I'd like to leave as a bug fix only
|> version with new versions going into a 2.x version. This is what I'd
|> like to have as part of my wish list:
|>
|> - Change to a session based platform, rather then cookie based. Cookie
|> usage is outdated when dealing with PHP and sessions are much easier
|> to maintain.
|> - A flow based means to manage ACL controls on folders, for both
|> cyrus+sasl and cyrus2+sasl2 based systems. James started some work on
|> this area based on older work that I had in place, but we both felt
|> 1.5.x based ACL controls were going to be somewhat limited anyway.
|> - fully PHP based, remove as much of the perl code as possible. I
|> don't yet know if this will be possible, but I'd like to remove some
|> of the issues we've been having with SUID based scripts.
|> - I new interface, allowing administrators to move around the system a
|> little easier.
|> - Give the user (non-admin accounts) more control over their own
|> mailboxes....
|> - Change in the file structure framework, so that we can simplify some
|> screens a little more.
|>
|> This is a small wish list, but it's also a set of ideas I've been
|> thinking about for the last year or so, anyone have any additional
|> items to add?
Adding support for ldap or other authentication backends where we would create
users in them and not the sasl interface, but the rest of the functionality is
still imap based (quotas, acl's).
This should be customizable. By default we stick with the sasl/sasl2 interface
and have a config option to let the user say we want to use ldap, mysql, whatever.
I guess I'm thinking of:
userBackend = 'sasl2'; // sasl, sasl2, ldap
- ---
We should probably install /etc/mailadmin/settings.{php,pl} config files that
get included by the config.inc file or the perl scripts (assuming we still need
them) and thus let the perl scripts be able to get the backend to use (sasl,
sasl2, etc.), the admin username and password, and imap seperator without us
having to pass them in on the command line.
By having a global /etc/mailadmin/settings.{php,pl} file, we can have an install
script that asks the user what the database name is, user to use, etc., populate
the config file snippet and create the database and have our
/usr/share/mailadmin/includes/config.inc file just source that file. All the
critical user changes would be in /etc/mailadmin/settings.{php,pl} which will
get around some of the limitations that different distros have in having a
config file in /usr. (Debian comes to mind)
That should help upgrading to be much easier.
- --
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
iD8DBQFAakY8tUXjwPIRLVERAqyMAJwLuUBkxDmxxT7hnO/iB2e6Zpc4TwCgmnye
XHSl7SSs+S7fL6L5V8AwY58=
=4brK
-----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-31 00:37:34
|
Hi All, Ok, now that 1.5.2 is out the door, I'd like to retire that package so we can work on a newer version that is much more flexible, and can be configured fairly easily. 1.5.x I'd like to leave as a bug fix only version with new versions going into a 2.x version. This is what I'd like to have as part of my wish list: - Change to a session based platform, rather then cookie based. Cookie usage is outdated when dealing with PHP and sessions are much easier to maintain. - A flow based means to manage ACL controls on folders, for both cyrus+sasl and cyrus2+sasl2 based systems. James started some work on this area based on older work that I had in place, but we both felt 1.5.x based ACL controls were going to be somewhat limited anyway. - fully PHP based, remove as much of the perl code as possible. I don't yet know if this will be possible, but I'd like to remove some of the issues we've been having with SUID based scripts. - I new interface, allowing administrators to move around the system a little easier. - Give the user (non-admin accounts) more control over their own mailboxes.... - Change in the file structure framework, so that we can simplify some screens a little more. This is a small wish list, but it's also a set of ideas I've been thinking about for the last year or so, anyone have any additional items to add? Woops, resending due to snipage.. |
|
From: Chris B. <ch...@hu...> - 2004-03-31 00:32:00
|
At 06:38 PM 3/29/04, Chris Bowlby wrote: >Hi All, > > Ok, now that 1.5.2 is out the door, I'd like to retire that package so > we can work on a newer version that is much more flexible, and can be > configured fairly easily. 1.5.x I'd like to leave as a bug fix only > version with new versions going into a 2.x version. This is what I'd like > to have as part of my wish list: > >- Change to a session based platform, rather then cookie based. Cookie >usage is outdated when dealing with PHP and sessions are much easier to >maintain. >- A flow based means to manage ACL controls on folders, for both >cyrus+sasl and cyrus2+sasl2 based systems. James started some work on this >area based on older work that I had in place, but we both felt 1.5.x based >ACL controls were going to be somewhat limited anyway. >- fully PHP based, remove as much of the perl code as possible. I don't >yet know if this will be possible, but I'd like to remove some of the >issues we've been having with SUID based scripts. >- I new interface, allowing administrators to move around the system a >little easier. >- Give the user (non-admin accounts) more control over their own mailboxes.... >- Change in the file structure framework, so that we can simplify some >screens a little more. > > This is a small wish list, but it's also a set of ideas I've been > thinking about for the last year or so, anyone have any additional items > to add? Making sure this got to the list. |
|
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 |
|
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 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: 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: 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-24 16:43:49
|
k, sounds cool.. On Wed, 2004-03-17 at 01:35, James A. Pattie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I just created an apache include file to support putting mailadmin into > /usr/share/mailadmin and which denies access to the includes directory. The > apache.include file is in the includes directory. > > I also updated the config.inc.dist file to have 127.0.0.1 as defaults for the > servers to connect to and tried to improve the cookie related variables so that > the user has an example of what the domain needs to be like and shouldn't even > have to mess with the path. > > The acl screen now honors the use buttons option and I tweaked the table layout > code so that we go wide and hopefully not vertical, thus trying to save realty. > > I also made the select boxes for users and folders to be size 10 since 3 was > just way too small when you have a lot of folders to scroll through. > > I think I'll put off the enhancement to select the folders to edit until the > next major code cycle, though it will be painfull to use personally. > > The setrights.pl script has not got the right permissions on it, so when > packaging we need to make sure it has 755 before we tar it up and release > otherwise people won't be able to change acl's. :) (This bit me for awhile, > especially since the exec command didn't give me any clue either!) > > I'll try to get around to Debianizing it tomorrow. > > - -- > 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 > > iD8DBQFAV+OStUXjwPIRLVERAthhAKCYKdZqdj2m1EP6vdvOeY8E8QiuCACffncx > nWqx+9CeRWQHhF4Z8UzStN4= > =L3Wj > -----END PGP SIGNATURE----- -- Chris Bowlby <ch...@hu...> Hub.Org Networking Services |
|
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-17 22:26:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just letting everyone know that if they use the latest IMAP::Admin from CPAN or use the deb I just built and is in my unstable repository at http://www.pcxperience.org/, spaces in folder names works, and apparently has been fixed since the 1.4.x version. I was testing with 1.3.7, which is pretty old for debian! The version in the docs/IMAP directory should only be used if people want to stay at 1.3.7. Debianizing will have to wait till tomorrow. - -- 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 iD8DBQFAWNCetUXjwPIRLVERAqOQAJoCyo8MFdQQadCdOdoSN76IL4StYgCgk5do aPfLcg16aogQLZyqMVVvj14= =1d+K -----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: James A. P. <ja...@pc...> - 2004-03-17 05:35:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just created an apache include file to support putting mailadmin into /usr/share/mailadmin and which denies access to the includes directory. The apache.include file is in the includes directory. I also updated the config.inc.dist file to have 127.0.0.1 as defaults for the servers to connect to and tried to improve the cookie related variables so that the user has an example of what the domain needs to be like and shouldn't even have to mess with the path. The acl screen now honors the use buttons option and I tweaked the table layout code so that we go wide and hopefully not vertical, thus trying to save realty. I also made the select boxes for users and folders to be size 10 since 3 was just way too small when you have a lot of folders to scroll through. I think I'll put off the enhancement to select the folders to edit until the next major code cycle, though it will be painfull to use personally. The setrights.pl script has not got the right permissions on it, so when packaging we need to make sure it has 755 before we tar it up and release otherwise people won't be able to change acl's. :) (This bit me for awhile, especially since the exec command didn't give me any clue either!) I'll try to get around to Debianizing it tomorrow. - -- 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 iD8DBQFAV+OStUXjwPIRLVERAthhAKCYKdZqdj2m1EP6vdvOeY8E8QiuCACffncx nWqx+9CeRWQHhF4Z8UzStN4= =L3Wj -----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: 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-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 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. |