this page should be splitted in subpages so that it becomes well arranged
GSOC project logs
Date : 28.04. - 05.05.
get familiar with MoinDev/MercurialGuide -> sent ssh pub-key to Thomas (http://fly.srk.fer.hr/~gizmo/ssh_pub_key.txt)
get familiar with py.test http://codespeak.net/py/dist/test.html
read MoinDev/UnitTests
- installed py.test and played with it
- get familiar with moin code
- get familiar with OpenLDAP -
started writing short help on getting familiar with LDAP http://fly.srk.fer.hr/~gizmo/ldap_help.txt
writing a document about LDAP groups matching with moin groups http://fly.srk.fer.hr/~gizmo/ldap_groups.txt
- comment to Reimar: please take look at the "replace or delete values in a multivalued attribute" process (in first article)
- please give an example which kind of data/atr. will be used regular multivalued.
- comment to Reimar: please take look at the "replace or delete values in a multivalued attribute" process (in first article)
http://www.openldap.org/, http://www.ibm.com/developerworks/linux/library/l-openldap/
- learn about LDAP groups and how to configure LDAP
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-LDIF-example1.html
- set a LDAP server and write a documentation about it
installed and set up slapd - (http://fly.srk.fer.hr/~gizmo/slapd_help.txt)
- get familiar with python-ldap
- MM groups concept doesn't currently distinguish usergroups from other groups.Groups are currently defined by the page_group_regex only
- think about advantages and disadvantages for separating user groups from common groups
- think about if it does make sense to split group definitions in e.g. user_group to have only users and page_group for the other stuff
- take a look at ldap_wikiconfig_snippet and auth_session_wikiconfig_snippet (the solution for the groups should be similar to the auth - so that the default is moin_groups and one can replace or add other group definitions )
- read FeatureRequests/UseGroupsOfAWiki
- think about advantages and disadvantages for separating user groups from common groups
Date : 05.05. - 12.05
- work woth moin code and ldap server
- written some OpenLDAP help
- write unitTest for ldap_login.py - test with the set up OpenLDAP environment
2008-05-20 01:13:56
- got moin working with ldap (with Thomas help)
- example of not found user:
2008-05-20 02:52:05,930 DEBUG MoinMoin.auth.ldap_login:120 uso 2008-05-20 02:52:05,930 DEBUG MoinMoin.auth.ldap_login:125 Setting misc. ldap options... 2008-05-20 02:52:05,936 DEBUG MoinMoin.auth.ldap_login:144 Trying to initialize 'ldap://localhost'. 2008-05-20 02:52:06,126 DEBUG MoinMoin.auth.ldap_login:146 Connected to LDAP server 'ldap://localhost'. 2008-05-20 02:52:06,128 DEBUG MoinMoin.auth.ldap_login:161 Bound with binddn 'cn=admin,dc=nodomain' 2008-05-20 02:52:06,128 DEBUG MoinMoin.auth.ldap_login:165 Searching u'(uid=foo)' 2008-05-20 02:52:06,129 DEBUG MoinMoin.auth.ldap_login:184 Search found no matches for u'(uid=foo)'.
- will test logging on some more examples and a bigger .ldif file.
Date : 24.05- 30.5
- play with different ldap groups
- done all pre-coding stuff
- do some moin to ldap adding groups code
- exams at college:
- 29.05, 30.05, 01.06 ,11.06, 07.07, 09.07
- Date
- 06.06.2008.
- Short description
- - set ldap test framework (all 5 tests passed)
- Date
- 07.06.2008.
- Short description
- - written tests for reading groups from LDAP and matching groups and users
- Date
- 08.06.2008 - 16.06.2008
- Short description
- exams passing
- Date
- 17.06.2008.
- Short description
- - test for searching groups that currently logged user is member of and adding groups to set
- Date
- 18.06.2008.
- Short description
-
- test for storing groups from LDAP to caching module, ldap_login.py: reading groups from LDAP that currently loged user is member of and storing groups to caching module
- changed test_ldapgroups.py - added search filter which looks at objectClass of defult LDAP Group types (groupOfNames, groupOfUniqueNames, posixGroup)
- deal with 'is X member of group G'
- Date
- 19.06.2008. - add member is_group to LDAP_groups lower level code
- Date
- 20.06.2008.-27.06.2008.
- Short description
-
- worked on wikidicts design requirements
- Date
- 28.06.2008.
- Short description
-
- finished wikidicts design requirements and started implementation of the config backend and high level code
To do
- reading groups from LDAP
- create test groups with small, medium and large amount of members
- cache results
- check how to get informed if an ldap server admin does changes in the group definition
- e.g. always if a new user is added on the ldap server and this user does access the first time the wiki we know that there was a change.
- so we know we have to update all group data related caches
- what other information can we use and how much time does it costs to use them?
Topics
1. Caching and updating new things from LDAP
- - if it is possible to change LDAP data only from moin after pre LDAP configuration then everything what is changed should go to "cache" before adding to ldap
2. Who should change groups (add groups, add users to groups)
I am not sure that this is going into the right direction. IMHO, moin should not editing/modifying LDAP data, but just use what's already there (LDAP admins usually have other tools to modify it). I suggest you also discuss this with people having LDAP experience, like the people on the openldap mailing list (or python-ldap for specific stuff). -- ThomasWaldmann 2008-06-11 10:19:48
It is currently more important to get part 1 in a productive state. part 2 is an extension similiar to the wiki openid server JohannesBerg has implemented. On this part work could be done after part 1 is done and we have time left. It is about to use a wiki to setup ldap users, groups and user preferences. So you can control entries in a ldap from one wiki. At least you would like to control your userpreferences and part2 could be started to solve how you can change your user password from within the wiki on the ldap server. -- ReimarBauer 2008-06-11 16:49:40
3. I was reading /MoinMoinIdeas/WikiApplicationServerPage and was thinking to implement checking for LDAP changes every time when user logs into, but after I'm not sure. Could someon explain me that caching strategy (dynamic vs static) please?
But the decision if an item is static or dynamic depends on the caching strategy. Neither the parser nor the formatter nor the macros should have to know much about this strategy. By now it is hard coded in at least one of these three objects
We don't have currently different caching flags. You have to set the global var Dependency = [] in the definition of the parser, macro, formatter if it should not cache. This is needed for all kind of addons on a page which can change dynamicly. e.g. it does not make sense for Hits to cache the result and to show the cached result on every page request. Because that is the wrong value. This macro returns a value for every click on the page where it is used. RecentChanges isn't cached too because it's content is changed on every page edit etc action. So it can't become static. static can only be used for data which does not change. sometimes it is used also for data which costs lot of time to get. FullSearch can cost lots of time so if that is not wanted you can use FullSearchCached. the data cache will be rebuilded after cache is purged. pagelinks for example would only change if the pagename is changed but it does not need to be changed after any other request (static).