| Request | LDAP User Folder -- question -- by Mark Hammond |
| Posted on | May 1, 2005 7:41 pm |
| Subscribe |
| Resolve by Jens Vagelpohl on Jun 8, 2005 5:49 am | |
|
I think this one can be closed - all the work needed to make replacing the LDAPDelegate seems complete at this point. If that's not the case please let me know. |
|
|
|
| Comment by Jens Vagelpohl on May 16, 2005 7:14 am | |
|
I believe these networking issues were caused by a iptables IP block I put in for a specific Australian IP that connected to the CVS pserver port several hundred times a day, which looked extremely bogus. I have unblocked it now and if there's any more issues it is probably on your end. P.S.: What kind of messed-up CVS client would connect to the server several hundred times a day? |
|
|
|
| Comment by Mark Hammond on May 15, 2005 8:54 pm | |
| Just FYI, I am a little stuck with some bizarre networking issue talking to dataflake - my CVS can't make a connection. Other machines I test can, as can other CVS servers from this machine. I'll try and get this sorted out, and I haven't forgotten... |
|
|
|
| Comment by Jens Vagelpohl on May 6, 2005 1:23 pm | |
|
So today I spent the whole day refactoring and changing things around and this is what's been done: - Move almost all LDAP-related items that were module-level functions or attributes into the LDAPDelegate instance - Hooked the delegate creation and created a simple registration mechanism (see utils) for delegate implementations so they become available during LDAPUserFolder instantiation - Replaced all logging with a shim implementation that feeds back into zLOG I'd say the ball is in your court to put your ideas into code. If you want to send patches I can attach them to the tracker issue. |
|
|
|
| Comment by Jens Vagelpohl on May 6, 2005 8:38 am | |
|
That intermediate logger class makes sense and it solves one other problem that occurred to me: When using zLOG directly, you would want to make sure that each log entry's "subsystem" member contains information about the specific user folder instance in question, like its path. This can be put right into the logger instance's "name" attribute that you're using in your Logger class and thus save constant calls to "absolute_url" and friends. I'll spend some time on this stuff today. I also thought about a fantastic use case for pluggable delegates: I can create and use a "testing" delegate for unit tests etc. that uses the FakeLDAP module instead of having to go through weird contortions in the unit tests to make sure that the imported name "ldap" is replaced with the FakeLDAP module. |
|
|
|
| Comment by Mark Hammond on May 4, 2005 7:57 pm | |
|
I just use a class like: import zLOG class Logger: def __init__(self, name = "ADSIDelegate"): self.name = name def log(self, level, msg, *args, **kw): exc_info = kw.get("exc_info") if exc_info == 1: exc_info = sys.exc_info() if exc_info == (None, None, None): exc_info = None zLOG.LOG(self.name, level, msg % args, error=exc_info) def debug(self, msg, *args, **kw): self.log(zLOG.DEBUG, msg, *args, **kw) ... logger = Logger() The intention is that the code looks more Pythonic, and IIUC, is better suited to a Z3 environment. Also IIUC, 2.8 allows you to use the builtin logging module to target zLOG, meaning the class isn't necessary there either. I'm still getting my head around this stuff :) |
|
|
|
| Comment by Jens Vagelpohl on May 4, 2005 6:58 pm | |
|
> However, looking even further forward, I am using zLOG via a pep282 > style interface - just a trivial wrapper class. That may be worth > considering. Just to clarify this, you created a logger that uses the logging module conventions and a handler that calls zLOG? What's the advantage over calling zLOG directly and plug various handlers into its own backend? |
|
|
|
| Comment by Mark Hammond on May 4, 2005 6:45 pm | |
|
I think the move to zLOG would be a great idea. Just yesterday I abandonded all attempts to reuse the log for the delegate, and just switched to zLOG. However, looking even further forward, I am using zLOG via a pep282 style interface - just a trivial wrapper class. That may be worth considering. |
|
|
|
| Comment by Jens Vagelpohl on May 4, 2005 10:02 am | |
|
Hi Mark, > * A method such as "self._createDelegate()" could replace the existing > hard-coded instantiation of the delegate. Yeah, that's a benign change > * explode_dn, and ADD, DELETE, REPLACE and BASE could be replaced with > instance attributes on the delegate. Good idea, too. Right now they are on the module itself, but it doesn't really change anything moving them to the instance. > * The ability for the delegate to use the _log() object for > diagnostic/debugging purposes <snip> > As this last point is the ugliest and also independent of additional > delegates, it seems the best one to tackle first. How would you > approach > the problem of adding logging to the LDAPDelegate object? Should > it use the > same log as the containing folder, or maybe the delegate should > simply use > zLOG (meaning messages go somewhere else than LDUF itself) Right, that's a problem. You will notice how I have used the passing of simple strings from the delegate back to the user folder to achieve some kind of logging, the user folder would use them for logging in some cases. I do not want to use the _log() object directly because I do not want any dependencies in the LDAPDelegate that point back to the user folder instance. At the same time it doesn't make sense to have the delegate log via zLOG. One compromise, at the expense of comfortable TTW lookup, could be to use zLOG throughout. This has the added benefit of removing one unique wart from the product, the wart being the fact that the logging is handled outside the normal framework. It would simplify the product a little bit as well. Another advantage is the simple fact that the logging call zLOG.LOG allows you to pass along way more interesting data, too. What do you think about the wholesale switch to zLOG to replace the current logging completely and sidestep all these niggles elegantly? jens |
|
|
|
| Comment by Mark Hammond on May 2, 2005 8:05 am | |
|
Hi Jens, Thanks for getting back to me. I've replied via email as "login" on your site isn't working for me (just appears to refresh the current page) I think I can come up with some fairly reasonable patches for this, and should not place any burden on you in the longer term. The issues I have come across so far: * A method such as "self._createDelegate()" could replace the existing hard-coded instantiation of the delegate. * explode_dn, and ADD, DELETE, REPLACE and BASE could be replaced with instance attributes on the delegate. * The ability for the delegate to use the _log() object for diagnostic/debugging purposes These seem to be the only changes necessary for us to re-use the buld of your LDUF code. The first 2 items have fairly reasonable implementations (assuming you would find them acceptable) - but the last remains a little hacky (currently I arrange for the delegate to store the _hash() and verbosity of the parent, so it can fetch the log). As this last point is the ugliest and also independent of additional delegates, it seems the best one to tackle first. How would you approach the problem of adding logging to the LDAPDelegate object? Should it use the same log as the containing folder, or maybe the delegate should simply use zLOG (meaning messages go somewhere else than LDUF itself) Thanks, Mark. |
|
|
|
| Comment by Jens Vagelpohl on May 2, 2005 3:35 am | |
|
Hi Mark, I wouldn't mind help on the AD end of things, but my main problem is the fact that I cannot test any of it myself. I don't run Windows and don't have any access to a AD instance that I can configure/use for testing. If there's any code in there which I cannot test myself there's a big danger of it turning into an orphan... jens |
|
|
|
| Initial Request by Mark Hammond on May 1, 2005 7:42 pm | |
|
There may be some value in an LDAPDelegate that uses Windows specific ActiveDirectory APIs instead of connecting via LDAP (main advantages: integrated with Windows security and far less configuration options necessary to get running) If we provided such a replacement open-source module, would there be interest in making changes to LDAPUF such that the delegate class can be plugged in at runtime - ie, so that a configuration option would allow the AD delegate to be used in place of the LDAP one? We (Enfold) intend working on such a scheme, but we are still trying to determine how best to structure it. LDAPDelegate looks like the correct place - any comments you have would be appreciated. Thanks |
