Ron, I think we're both targetting the same issue.
> If you want to get rid of the mysql portion of web-cyradm, you need to > carry all of that information in LDAP. No problem, in theory. > As you pointed out, the account stuff can probably be found among the > "standard" schemas. The ObjectClasses that you mentioned are all part of > the standard distribution. Yes. But are all attributes that are in the MySQL tables covered by these objects? This is what I never really checked, but I doubt. Well, I *know* this is not the case when it comes to simpleSecurityObject or posixUser at least. At least the stuff such as - max number of accounts for a domain - default mailbox quota - individual mailbox quota cannot be put into any of the standard LDAP objects AFAIK. It would therefore probably make sense to have something like a mailDomain or an imapMailbox object in LDAP that takes this information. And this is where I thought there should be a standard LDAP schema for that. Standard in the sense of that it is described in a RFC or IETF draft, pretty much as inetOrgPerson is for example. I think this should neither be web-cyradm specific nor Cyrus IMAPd specific as the kind of information would apply to any other other IMAP implementation as well. > A Web Services maintenance interface would make it easier to integrate > e-mail management into applications rather than have to do some of the > work of adding a new user in the application and then finishing the job > in web-cyradm. Shifting Web-Cyradm to a client/server architecture might > also make it more robust and easier to mantain. Well, this is right, but to me this in an entirely different story. I would agree that having cyradm implemented as a SOAP web service would make a lot of sense, but I am not sure if I would implement this in PHP. I would like to see this as a stable and reliable daemon, written either in Java or C++. If such a think would exist, it would make sense that web-cyradm called this instead of doing what it does today: Open a socket on the IMAP server and talk cyradm commands over the wire. > I would be interested in working on this What exactly? Implementing such a web service or changing web-cyradm in a way that it will support a pure LDAP backend? There is lots of value in both but I personally wouldn't target two different things at a time. Regards, Torsten > --- Urspr�ngliche Nachricht --- > Von: Ron Wheeler <[EMAIL PROTECTED]> > An: unknown > Kopie: [email protected] > Betreff: Re: [Web-cyradm] LDAP ... any preferences? > Datum: Tue, 17 May 2005 08:51:19 -0400 > > I guess that I could have been more specific. > OpenLDAP ships with a number of "standard" schemas, some more standard > than others. > If you want to get rid of the mysql portion of web-cyradm, you need to > carry all of that information in LDAP. No problem, in theory. > As you pointed out, the account stuff can probably be found among the > "standard" schemas. The ObjectClasses that you mentioned are all part of > the standard distribution. > I would be interested in working on this since I think that the long > term benefit of an LDAP based solution that can integrate into an > overall virtual domain architecture would be a lot better than a system > with some of the data in MySQL and some in LDAP. > A Web Services maintenance interface would make it easier to integrate > e-mail management into applications rather than have to do some of the > work of adding a new user in the application and then finishing the job > in web-cyradm. Shifting Web-Cyradm to a client/server architecture might > also make it more robust and easier to mantain. > > Ron > > Torsten Schlabach wrote: > > >Ron, > > > > > > > >>What is the proposed LDAP Schema? > >> > >> > > > >For what excactly? > > > >To represent the user's account, you can use simpleSecurityObject, > posixUser > >or inetOrgPerson. But they all don't have the IMAP specific attributes > such > >as mailbox quota and the like. > > > >I wonder if I have overlooked anything. There should be some RFC for > that. > >If not, it might be worth writing one. > > > >Regards, > >Torsten > > > > > > > >>--- Urspr�ngliche Nachricht --- > >>Von: Ron Wheeler <[EMAIL PROTECTED]> > >>An: [email protected] > >>Betreff: Re: [Web-cyradm] LDAP ... any preferences? > >>Datum: Mon, 16 May 2005 22:06:13 -0400 > >> > >>What is the proposed LDAP Schema? > >>I am right in the middle of this and trying to get it right. I have not > >>done a custom schema. I do not have enough LDAP experience to be sure > >>that I have everything that I need in LDAP to handle Postfix(not really > >>an issue) and Cyrus. > >> > >>What is the minimum set ofObjectClasses and the minimum set of > >>Attributes required? > >> > >>Ron > >> > >> > >> > >> > >>Torsten Schlabach wrote: > >> > >> > >> > >>>Hi again, > >>> > >>>I finally found the time and got my arms around the idea of drivers as > in > >>>Horde. So I did some very limited prototyping with the current CVS > >>> > >>> > >>version > >> > >> > >>>of web-cyradm to try to demonstrate the concept. I will attach a little > >>> > >>> > >>tar > >> > >> > >>>archive that is to be extracted to the web-cyram directory. > >>> > >>>The only thing that works for now is the _static driver which will > always > >>>reply "true" to the _check method. The _ldap driver is just a skeleton > >>> > >>> > >>for > >> > >> > >>>now. > >>> > >>>In case we like the concept and want to go further down that road, then > I > >>>would probably have to move anything which is the crypto.php file into > a > >>>_sql driver, right? > >>> > >>>If the final goal was to eliminate the need for an SQL database at all, > >>>there will be more changes necessary. Right now for example when > browsing > >>>accounts the code to query an SQL database for all existing accounts is > >>>built right into the user interface code. > >>> > >>>I think in the longer run we will also need a sort of driver concept > here > >>>where we have drivers that will either query > >>> > >>>- an SQL database (today's code) > >>>- the LDAP server > >>>- the mail server itself > >>> > >>>Regarding the latest two, I wonder anyway what the best approach would > >>> > >>> > >>be. > >> > >> > >>>This isn't really a web-cyradm question but more an issue of general > >>>interest: How can we make sure that the mailbox names and the LDAP / > SQL > >>>user entries are kept in sync. > >>> > >>>For example, if you login to the cyrus imapd from the command line and > >>>delete a mailbox, web-cyradm will still think it's there, won't it? > >>> > >>>As a near term goal, what I will have a look at (given there are no > major > >>>comments on the approach taken) will be: > >>> > >>>- finish the auth stuff > >>>- triggering LDAP operations in parallel to the SQL operations > >>> > >>>What I mean is: > >>> > >>>If a new mailbox is created in web-cyradm, the existing code will (I > >>> > >>> > >>assume) > >> > >> > >>>- create a mailbox in cyrus imapd (cm ...) > >>>- create an entry in the SQL database for the user > >>> > >>>So it should not be that difficult to add a line of code that calls a > >>>mechanism that will also make / alter a corresponding LDAP entry. > >>> > >>>This makes me think of implementing a PAM concept where any providers > can > >>>register and web-cyradm will just cycle through the list and call each > of > >>>them. > >>> > >>>Any thoughts? Anyone has any experience with this? > >>> > >>>Reagards, > >>>Torsten > >>> > >>> > >>> > >>> > >>> > >>>>--- Urspr�ngliche Nachricht --- > >>>>Von: "Torsten Schlabach" <[EMAIL PROTECTED]> > >>>>An: [email protected] > >>>>Betreff: Re: [Web-cyradm] LDAP ... any preferences? > >>>>Datum: Tue, 12 Apr 2005 16:30:35 +0200 (MEST) > >>>> > >>>>Luc, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>>>Hmm... I wonder what is the best idea. It is needed to abstract the > >>>>>>>whole authentication and authorization stuff. So maybe something > >>>>>>>horde-like with drivers can be a solution? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>Can you give any pointers to that concept? I was unable to access > >>>>>>http://www.horde.org/ today (HTTP 500 - Internal Server error). > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>You can choose different datasources for different purposes. Best > place > >>>>>to look at it is in /horde/config. BTW: horde.org went back online... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I found some good reading here: > >>>> > >>>>http://www.horde.org/papers/oscon2002hordeconf.pdf > >>>> > >>>>(Also for the benefit of everyone else on the list.) > >>>> > >>>>My understanding than would be that we'd have to gradually introduce > >>>> > >>>> > >>some > >> > >> > >>>>more OO concepts into web-cyradm. If I get the concept of drivers in > >>>> > >>>> > >>Horde > >> > >> > >>>>right, then I would compare a driver to an Interface in Java, right? > >>>> > >>>>I mean the plan is to define a number of methods that any object which > >>>>connects to a back-end needs to understand. The driver basically > decides > >>>>which implementation of the interface (which class) is to be used, > >>>> > >>>> > >>right? > >> > >> > >>>>To take complexity to the next level, I am not sure if we would need > to > >>>>choose different data stores for different items or at least offer a > >>>>choice > >>>>here. I think it will heavily depend on a particular setup, but > >>>> > >>>> > >>depending > >> > >> > >>>>on > >>>>a specific environment, you can either store any information that > >>>>web-cyradm > >>>>needs into the same backend or you cannot. > >>>> > >>>>If you cannot, you will need an auxilliary storage. > >>>> > >>>>This topic is getting more and more complex ... but also interesting. > >>>> > >>>>I will see how far I can get with prototyping some stuff for the > >>>> > >>>> > >>password > >> > >> > >>>>auth in the first place. I think this will show what questions arise > for > >>>>the > >>>>rest. > >>>> > >>>>Regards, > >>>>Torsten > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Torsten Schlabach wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Luc, > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>1. Should we use the PHP LDAP functions > >>>>>>>>(http://www.php.net/manual/en/ref.ldap.php) or rather > PEAR::Net:LDAP > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>or > >>>> > >>>> > >>>> > >>>> > >>>>>>>>PEAR::ldap or PEAR::ldap2? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>I have no preferences, what is your opinion? Pros? Contras? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>This makes a difference especially for people who don't have full > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>control of > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>their environment. If you want to use the PHP LDAP functions (i.e. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>ldap_...) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>they needs to be enabled in the PHP binary that web-cyradm is > supposed > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>run on. If it isn't, this means you have to re-compile your PHP to > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>make > >>>> > >>>> > >>>> > >>>> > >>>>>it > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>run. If this is an option at all. (I am thinking of hosted > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>environments, > >>>> > >>>> > >>>> > >>>> > >>>>>>though I am not sure if ISPs will allow you to install custom PEAR > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>modules. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Never had that problem.) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>If the PEAR::ldap classes does not need ldap support compiled in PHP > >>>>>then we should definitely go for PEAR. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I also think that there should be a consistent direction used > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>throughout > >>>> > >>>> > >>>> > >>>> > >>>>>>web-cyradm. For example, when it comes to database access, you've > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>choosen > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>the PEAR:DB stuff, not the PHP built-in MySQL functions. You also > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>don't > >>>> > >>>> > >>>> > >>>> > >>>>>rely > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>on the built-in functions to interface the Cyrus IMAPd, though there > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>would > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>be even two different sets of functions to choose from. So I think > it > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>would > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>make most sense in this context to go for the PEAR stuff also for > LDAP > >>>>>>access. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>There have been several good reasons for it. PEAR::DB provides DB > >>>>>abstraction, so web-cyradm is supporting MySQL and POstgreSQL (only > >>>>>limited by pam_you-name-it-database and availability of patches for > >>>>>postfix. > >>>>> > >>>>>In 2001 the cyrus stuff of PHP was simply not working. > >>>>> > >>>>>I agree with the PEAR ldap access (see above) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I have seen there are LDAP drivers for PEAR:DB. But I doubt they > will > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>do > >>>> > >>>> > >>>> > >>>> > >>>>>the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>trick in a way that the code does not need any major modifications > in > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>oder > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>to support LDAP but just by replacing the driver, unfortunately. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>Though > >>>> > >>>> > >>>> > >>>> > >>>>>it > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>might be worth looking at. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>This would simplify the work much, I'll having a look at it. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hmm... I wonder what is the best idea. It is needed to abstract the > >>>>>>>whole authentication and authorization stuff. So maybe something > >>>>>>>horde-like with drivers can be a solution? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>Can you give any pointers to that concept? I was unable to access > >>>>>>http://www.horde.org/ today (HTTP 500 - Internal Server error). > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>You can choose different datasources for different purposes. Best > place > >>>>>to look at it is in /horde/config. BTW: horde.org went back online... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>It's question how far you intend to take OO in web-cyradm. If you > plan > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>make a strong move towards OO concepts I'd agree with you that > neither > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>of my > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>suggestions would be a perfect solution. > >>>>>> > >>>>>>Then again, PHP has changed a lot when it comes to OO with the 5.x > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>releases. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Should web-cyradm depend on 5.x so it will be safe to use these > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>features > >>>> > >>>> > >>>> > >>>> > >>>>>or > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>will there be a need to stay backwards-compatible with earlier PHP > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>releases. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>If yes, how far? Is there any official statement somewhere regarding > >>>>>>web-cyradm's requirements to PHP? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>The official Statement is: Web-cyradm should work with PHP 4.3.x and > >>>>>above (inluding 5.0.x) > >>>>> > >>>>>This limits the OO code to be realized, but for the next two years I > >>>>>think it is important to also support PHP 4.3 because a lot of people > >>>>>are and will be stuck at PHP 4 for the next time (i.e all with are > >>>>> > >>>>> > >>using > >> > >> > >>>>>typo3 with older extensions) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>P.S.: You might want to update the web-cyradm website to reflect the > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>fact > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>that the mailing list is back online! > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Thanks for the reminder, its done :-) > >>>>> > >>>>>rgds > >>>>> > >>>>>Luc > >>>>>_______________________________________________ > >>>>>This mailing list is hosted and supported > >>>>>by bit-heads GmbH | http://www.bit-heads.ch > >>>>> > >>>>>_______________________________________________ > >>>>>Web-cyradm mailing list > >>>>>[email protected] > >>>>>http://www.web-cyradm.org/mailman/listinfo/web-cyradm > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>This mailing list is hosted and supported > >>>>by bit-heads GmbH | http://www.bit-heads.ch > >>>> > >>>>_______________________________________________ > >>>>Web-cyradm mailing list > >>>>[email protected] > >>>>http://www.web-cyradm.org/mailman/listinfo/web-cyradm > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>This mailing list is hosted and supported > >>>by bit-heads GmbH | http://www.bit-heads.ch > >>> > >>>_______________________________________________ > >>>Web-cyradm mailing list > >>>[email protected] > >>>http://www.web-cyradm.org/mailman/listinfo/web-cyradm > >>> > >>> > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>This mailing list is hosted and supported > >>by bit-heads GmbH | http://www.bit-heads.ch > >> > >>_______________________________________________ > >>Web-cyradm mailing list > >>[email protected] > >>http://www.web-cyradm.org/mailman/listinfo/web-cyradm > >> > >> > >> > > > > > > > > > > _______________________________________________ > This mailing list is hosted and supported > by bit-heads GmbH | http://www.bit-heads.ch > > _______________________________________________ > Web-cyradm mailing list > [email protected] > http://www.web-cyradm.org/mailman/listinfo/web-cyradm > _______________________________________________ This mailing list is hosted and supported by bit-heads GmbH | http://www.bit-heads.ch _______________________________________________ Web-cyradm mailing list [email protected] http://www.web-cyradm.org/mailman/listinfo/web-cyradm
