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

[Ron Wheeler]

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: web-cyradm@web-cyradm.org
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
Web-cyradm@web-cyradm.org
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
Web-cyradm@web-cyradm.org
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
Web-cyradm@web-cyradm.org
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
Web-cyradm@web-cyradm.org
http://www.web-cyradm.org/mailman/listinfo/web-cyradm