Copyin and pasting since it's quickest [regarding wanting dev-pythn/python-ldap on toucan/roadrunner] <@lcars> ferringb: and why's that? what do you need that's missing in perl_ldap < ferringb> lcars: try using it for more then a single modification < ferringb> it's good for command line < ferringb> but fex, generating an xml tree? you're doing it by hand. has some snafu's that I can cover up, but I'd rather hand off to another framework for handling (various char encodings) < ferringb> can't loop over N objects, inspecting/modifying; if I were to go through and reset Retired to retired fex, I'd have to do some massive script foo, rather then just load the db, iterate over it modifying and pushing the change < ferringb> reuse for stuff beyond simple command line mods; checking/verification of inputs automatically, etc. <@lcars> ok..looks like you need to code your own scrip then ;) < ferringb> lcars: basically, yes. < ferringb> lcars: case in point- I just had to insert 70 users into ldap < ferringb> I wrote a wrapper around perl_ldap, feeding the chunks of the xml into ldap, but it's not pretty (nor particularly reusable). If I build a reusable api, any crap like this down the line is a helluva lot easier. :) < ferringb> lcars: don't get me wrong... normally, it's fine. just thinking about crazy crap like above. :) < ferringb> hence my request for python-ldap (which will be bugged shortly) * lcars nods Further reason for merging this? My intention is to write a module wrapping our ldap db (including accessing it), so that common code can use it beyond trying to parse perl_ldap's output. Via said module, can do usual high level scans/mods/mass inserts (the devrel userinfo -> ldap should be the last of the sort), *plus* do verification on all inserts. Ensuring date's are in xyz format, etc. Chunks of that can probably be shoved into the ldap backend, but other parts, not so much so imo. I'd like to get it to the point where I can easily scan the wrapped db, feeding the data into xml framework for generating userinfo on the fly (rather then hand crafted outputting of it). Stuff like that. Easier programmatic access to the data. So... issues? ;)
I'm fine with installing this on toucan and ldap1 (roadrunner). Keep in mind that I won't ever provide support/help for it since my python-fu is very low ;). If no one has objections I'll just emerge it. (no deps)
As long as you don't see any problem with it security-wies, I don't see an issue.
done
Kind of need python-ldap merged with sasl/ssl capabilities to actually access our ldap servers...
the package was originally emerged with ssl USE flag (sasl flag is useless for us) , so if you are having issues the problems must be somewhere else.
