Re: [Web-cyradm] LDAP ... any preferences?

Ron Wheeler Mon, 16 May 2005 20:18:35 -0700

I was thinking that a Web Service might be a good way to "Create a new User', "Update a user" or "Delete a user" These should not be to hard to write and could be called from all kinds of user uinterfaces (local or client-side). I would like to eventually access these functions from a Flash RIA but in the short term a simple HTML page would do or web-cyradm. If web-cyradm became the client side to a series of calls to Web Services, it would be a lot simpler and much more robust. The Web Services would be pretty simple since web-cyradm does not really make a lot of changes to the database and the Web Services should be pretty small. LDAP should be able to replace the SQL batabase since it is not transactional in any significant sense and all of the virtual domain stuff is already easy to describe in LDAP. The e-mail quota and vacation stuff would have to be added through a custom schema. At least, I do no recall seeing it in the standard schemas taht come with OpenLDAP although I am sure that some of the bigger LDAP aaplications would have schema elements that would handle this info.

I am also looking at the Eclipse plug-in route since the LDAP side is already done - another story altogether.

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

Re: [Web-cyradm] LDAP ... any preferences?

Reply via email to