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

[Ron Wheeler]

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: web-cyradm@web-cyradm.org
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: 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
   


 

_______________________________________________
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