| Summary: | automatic update of userinfo from ldap | ||
|---|---|---|---|
| Product: | Community Relations | Reporter: | Torsten Veller (RETIRED) <tove> |
| Component: | Developer Relations | Assignee: | Gentoo Community Relations Team <comrel> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | beu, dberkholz, lcars, robbat2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 189430, 196558 | ||
| Bug Blocks: | 175411 | ||
|
Description
Torsten Veller (RETIRED)
2006-04-09 08:42:47 UTC
(In reply to comment #0) > Some time ago i've heard that ferringb was working on an automatic way to > update userinfo from ldap. I've also heard that there were problems with > encoding. > > What's the status of this? What was done? What are the problems? > Last I heard it was stuck on some UTF-8 issues. perl UTF8 issues; came down to the perl bindings mangling UTF8, which I wasn't able to solve. Banged my head against the wall long enough on that one I finally said "screw it" and decided to write it using python ldap bindings; intention was to build up a module that handled perl_ldap actions (adding/removing/searching) in a bit saner/encapsulated manner, and had built in checks. Basically, library for the backend gentoo ldap crap. Problem being? Ssl cert in use technically isn't valid due to the hostname's not matching; perl-ldap shouldn't be working from what I know, and python-ldap is *strict* aboutit so it's a no go there. So... that's where it's at. Have fun with it. :) The following patch fixes UTF-8 writing for userinfo.xml. http://dev.gentoo.org/~robbat2/perl_ldap-utf8-userinfo-fix.patch And also one bug with gpgKey being not always being defined. I see there are some entries in the existing userinfo.xml that are not in LDAP - this should be resolved before perl_ldap is used for automating userinfo.xml. *** Bug 132459 has been marked as a duplicate of this bug. *** (In reply to comment #3) [snip] > I see there are some entries in the existing userinfo.xml that are not in LDAP > - this should be resolved before perl_ldap is used for automating userinfo.xml. what fields are you refering to? Also, is there any reason for this bug to be restricted to devrel? (In reply to comment #5) > (In reply to comment #3) > > I see there are some entries in the existing userinfo.xml that are not in LDAP And vice versa: There is gbittorent in `perl_ldap -U` output while it should only contain devs. > Also, is there any reason for this bug to be restricted to devrel? I am not and never was able to change it. It shouldn't be restricted at all i think. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > I see there are some entries in the existing userinfo.xml that are not in LDAP > > And vice versa: > There is gbittorent in `perl_ldap -U` output while it should only contain devs. > > > Also, is there any reason for this bug to be restricted to devrel? > > I am not and never was able to change it. It shouldn't be restricted at all i > think. > You asked for it; you got it. Restricted to Developers because I don't imagine anyone else cares. Changed my mind. My reasoning made no sense to me, and I don't see what's secret about this. Unrestricted, as Torsten requested. is anybody going to use the patch? *bump* status? A diff of ldap and cvs data is on my devspace ~me/userinfo.diff We need a place in ldap to store email adresses of retired devs. Those have come in handy a number of times and we have quite a few of them in roll-call currently (<email role="primary">). Besides doing a final sync between ldap and roll-call I believe that's the only outstanding issue. The attribute "mail" can be added to any entry, check mine for instance. I was talking to kloeri about this, and we've come to the conclusion that CVS to LDAP is actually better to store most (not all) of the data in, for a few reasons (there were some others, but these are the big ones) - The type attribute on mail isn't preserved in data. - We don't need to block developers from editing userinfo.xml in general (eg Lisa joins my herd and I add it to her description when she asks me to). - handles developers that retired pre-LDAP gracefully - keeps comments in the userinfo.xml - CVS keeps history - most importantly: for most of the attributes, they are NOT consumed out of LDAP, but rather only by the web frontend from the CVS tree anyway. - some of the stuff in LDAP is over-locked compared to CVS - devs cannot their own location or roles presently. These are presently only in LDAP, are related to access control, and have never been needed for the userinfo.xml: gentooAccess (infra write only) sshPublicKey (self write access) gentooStatus - this one is special, we need it in CVS for generating the correct page, MUST be kept locked down. in both CVS/LDAP, only needed in CVS presently: gentooRoles gentooGPGKey gentooJoin birthday old, no longer needed, replaced by gentooRoles: gentooHerd other special cases: gentooGPGFingerprint - present on 59 users only - need to add to XML DTD gentooLatitude - not used at all yet, add to DTD? gentooLongitude - not used at all yet, add to DTD? gentooForumsUID - only exists on lcars and mariez - do we need actually need it at all? one other comment, there seem to be a lot of active developers without sshPublicKey entries presently. (In reply to comment #14) > I was talking to kloeri about this, and we've come to the conclusion that CVS > to LDAP is actually better to store most (not all) of the data in, for a few > reasons (there were some others, but these are the big ones) > - The type attribute on mail isn't preserved in data. > - We don't need to block developers from editing userinfo.xml in general (eg > Lisa joins my herd and I add it to her description when she asks me to). Users should be modifying only their own data; recruiters/devrel/infra are exempted of course since they're effectively custodial, meaning they need full access to all others. > - handles developers that retired pre-LDAP gracefully Majority of those devs ought to be in ldap already; I went through and sync'd userinfo and ldap about 10 months back, that *should* have taken care of the vast bulk, leaving just kloeri's updates (which should be updating both anyways as is). > - keeps comments in the userinfo.xml > - CVS keeps history so do cronjob'd dumps. > - most importantly: for most of the attributes, they are NOT consumed out of > LDAP, but rather only by the web frontend from the CVS tree anyway. The web frontend was to use perl_ldap to get the data out of ldap, instead of having to maintain both CVS and ldap; this is a non-issue in other words. > - some of the stuff in LDAP is over-locked compared to CVS - devs cannot their > own location or roles presently. Then reduce the anal locking infra stuck in... > in both CVS/LDAP, only needed in CVS presently: > gentooRoles > gentooGPGKey > gentooJoin > birthday Birthday isn't needed (again, nobody actually tracks it for web crap). > gentooForumsUID - only exists on lcars and mariez - do we need actually need it > at all? Yes, the reason for it to be added was to be able to make retiring simpler; cronjob'd pushes, but have their forums status automatically slaved to what ldap says about 'em; even if that automation is dropped, still need to track their Forums ID since their is no gurantee their gentoo nick matches their forums nick, making it harder to retire 'em if they've gone MIA and rarely used forums. Wouldn't mind hearing the full logic behind this one also, since userinfo (cvs) was sync'd upto ldap at one point, meaning their shouldn't be a huge delta between the two unless folks stopped maintaining one/other. (In reply to comment #16) >> - The type attribute on mail isn't preserved in data. You missed this one. >> - We don't need to block developers from editing userinfo.xml in general (eg >> Lisa joins my herd and I add it to her description when she asks me to). >Users should be modifying only their own data; recruiters/devrel/infra are >exempted of course since they're effectively custodial, meaning they need full >access to all others. The gentoo policy in the past has always been to trust developers with the tree, and I don't see this as a change. >> - handles developers that retired pre-LDAP gracefully >Majority of those devs ought to be in ldap already; I went through and sync'd >userinfo and ldap about 10 months back, that *should* have taken care of the >vast bulk, leaving just kloeri's updates (which should be updating both anyways >as is). I could 540 in LDAP, and 575 in CVS. There's also a few I've run into in the ancient -core archives that have never been in either, but I have found mention of them in the bowels of the CVS tree. >> - keeps comments in the userinfo.xml >> - CVS keeps history > >so do cronjob'd dumps. commiting LDAP->CVS keeps the history anyway, but comments would still be lost. See for example the present comment at the top about date format that is there to remind people. There will probably be a few more comments about data types later on. >> - most importantly: for most of the attributes, they are NOT consumed out of >> LDAP, but rather only by the web frontend from the CVS tree anyway. >The web frontend was to use perl_ldap to get the data out of ldap, instead of >having to maintain both CVS and ldap; this is a non-issue in other words. If it's going to consume strictly LDAP, then there is no need for userinfo.xml on the web nodes. Conversely, the existing stuff uses userinfo.xml and isn't broken in any way - don't fix it ;-). >> - some of the stuff in LDAP is over-locked compared to CVS - devs cannot their >> own location or roles presently. >Then reduce the anal locking infra stuck in... I only discovered it today, appears to be the schema and ACLs not being kept in sync. >> birthday >Birthday isn't needed (again, nobody actually tracks it for web crap). I'm NOT reopening that argument that was had re birthday on anoncvs. If devs put it in, we keep it, if not, no issue. >> gentooForumsUID - only exists on lcars and mariez - do we need actually need it >> at all? >Yes, the reason for it to be added was to be able to make retiring simpler; >cronjob'd pushes, but have their forums status automatically slaved to what >ldap says about 'em; even if that automation is dropped, still need to track >their Forums ID since their is no gurantee their gentoo nick matches their >forums nick, making it harder to retire 'em if they've gone MIA and rarely used >forums. Ok, so it just seems that it got designed, but never used beyond lcars/marienz. I'm not opposed to it given the above explaination, that that it wasn't documented anywhere ;-). >Wouldn't mind hearing the full logic behind this one also, since userinfo (cvs) >was sync'd upto ldap at one point, meaning their shouldn't be a huge delta >between the two unless folks stopped maintaining one/other. I think it's been a side effect of users not being able to change their own data - or knowning that that they should change both at least - esp. amongst some of the developers that have been around a long time. I'm not against automation, I'm just saying that CVS->LDAP seems to make a lot more sense. Descripitive medium -> Less Descriptive medium. (In reply to comment #17) > (In reply to comment #16) > >> - The type attribute on mail isn't preserved in data. > You missed this one. Pardon; clarify it however please since I wasn't around for that specific complaint... > >> - We don't need to block developers from editing userinfo.xml in general (eg > >> Lisa joins my herd and I add it to her description when she asks me to). > >Users should be modifying only their own data; recruiters/devrel/infra are > >exempted of course since they're effectively custodial, meaning they need full > >access to all others. > The gentoo policy in the past has always been to trust developers with the > tree, and I don't see this as a change. Tree is one thing, with what y'all are suggesting, gpg, cvs, all would now be controlled via cvs; stated that "would need to limit peoples ability to modify ssh key" which... how? Best I can figure y'all are suggesting there is that devs still have to go to ldap to make the change, which makes one wonder why they are modifying bits xyz in cvs, and bit A in ldap, instead of doing 'em all in ldap :) > >> - handles developers that retired pre-LDAP gracefully > >Majority of those devs ought to be in ldap already; I went through and sync'd > >userinfo and ldap about 10 months back, that *should* have taken care of the > >vast bulk, leaving just kloeri's updates (which should be updating both anyways > >as is). > I count 540 in LDAP, and 575 in CVS. There's also a few I've run into in the > ancient -core archives that have never been in either, but I have found mention > of them in the bowels of the CVS tree. 35 isn't much to sync into ldap; pretty easy to do at this point also, just generate a new userinfo.xml via perl_ldap, use diff to track down the differences. > >> - keeps comments in the userinfo.xml > >> - CVS keeps history > > > >so do cronjob'd dumps. > commiting LDAP->CVS keeps the history anyway, but comments would still be lost. > See for example the present comment at the top about date format that is there > to remind people. There will probably be a few more comments about data types > later on. Comments about data types however are daft; people can still commit crap breaking it. Use perl_ldap for the mods, you can at least force data validation. Any comments that aren't related to "you have to do it this way" ? They go away with ldap since the frontend can just do the verification... > >> - most importantly: for most of the attributes, they are NOT consumed out of > >> LDAP, but rather only by the web frontend from the CVS tree anyway. > >The web frontend was to use perl_ldap to get the data out of ldap, instead of > >having to maintain both CVS and ldap; this is a non-issue in other words. > If it's going to consume strictly LDAP, then there is no need for userinfo.xml > on the web nodes. Conversely, the existing stuff uses userinfo.xml and isn't > broken in any way - don't fix it ;-). Reason for it consuming from a generated userinfo.xml was an infra decree; worried about web cruft bringing down ldap. Regarding "don't fix it", theres a reason I nudged you to fix the utf8 issues with userinfo generation for perl_ldap; with that fixed, ldap could become the master repository of that data, and it could be exported out for consumers expecting the old format. So... it's not forcing any changes on web stuff; could just push the ldap dump into cvs, or cronjob updates on the web nodes, whatever folk wanted. > >> birthday > >Birthday isn't needed (again, nobody actually tracks it for web crap). > I'm NOT reopening that argument that was had re birthday on anoncvs. > If devs put it in, we keep it, if not, no issue. Just saying, birthday isn't the best thing to bring up ;) > >> gentooForumsUID - only exists on lcars and mariez - do we need actually need it > >> at all? > >Yes, the reason for it to be added was to be able to make retiring simpler; > >cronjob'd pushes, but have their forums status automatically slaved to what > >ldap says about 'em; even if that automation is dropped, still need to track > >their Forums ID since their is no gurantee their gentoo nick matches their > >forums nick, making it harder to retire 'em if they've gone MIA and rarely used > >forums. > Ok, so it just seems that it got designed, but never used beyond lcars/marienz. > I'm not opposed to it given the above explaination, that that it wasn't > documented anywhere ;-). Blame me for retiring; there is a bug open re: it, tomk should know some of the details also- was working on pairing up forums nick -> dev to build a table to push into ldap... Bit of manual work, but that list is required either way since the current way of handling it (no offense to those handling it either) has a fair potential for misses. > >Wouldn't mind hearing the full logic behind this one also, since userinfo (cvs) > >was sync'd upto ldap at one point, meaning their shouldn't be a huge delta > >between the two unless folks stopped maintaining one/other. > I think it's been a side effect of users not being able to change their own > data - or knowning that that they should change both at least - esp. amongst > some of the developers that have been around a long time. > > I'm not against automation, I'm just saying that CVS->LDAP seems to make a lot > more sense. Descripitive medium -> Less Descriptive medium. Well... with ldap, the "descriptive" bit is just a matter of the frontend used for modifying that stuff. In other words, it can be made god awfully informative if folks find that an issue ;) The real underlying reason for centralizing it into ldap, and trying to go the route of having folks modify the ldap records directly instead of current methods was that of data validation, and centraliziation. Upshot, would get ACL on dev specific data (keys mainly), which was (and likely still is) haphazardly tracked. Sidenote, would kill for a freaking preview button; bugzilla blows for discussion of this sort... >(In reply to comment #17) >> (In reply to comment #16) >> >> - The type attribute on mail isn't preserved in data. >> You missed this one. >Pardon; clarify it however please since I wasn't around for that specific >complaint... In userinfo.xml presently, here's a few examples of email entries: <email role="primary">a.sleep@asleep.net</email> <email role="gentoo">a.sleep@gentoo.org</email> <email role="secondary">bangert@fizzelpark.com</email> <email role="gentoo">bangert@gentoo.org</email> <email role="primary">broeman@k64.dk</email> <email role="secondary">jesper.brodersen@sourcebook.dk</email> <email role="primary">micke@imendio.com</email> <email role="secondary">micke@hallendal.net</email> <email role="gentoo">hallski@gentoo.org</email> There's a distinct lack of pattern here. We could catch @gentoo.org as the role=gentoo entry, but handling the order of the others is not available in LDAP. It's multiple instances of the mail attribute, unordered. yeah it can be solved by adding new attributes mailPrimary, mailSecondary, etc, *me looks at perl_ldap hackers* >Tree is one thing, with what y'all are suggesting, gpg, cvs, all would now be >controlled via cvs; stated that "would need to limit peoples ability to modify >ssh key" which... how? Best I can figure y'all are suggesting there is that >devs still have to go to ldap to make the change, which makes one wonder why >they are modifying bits xyz in cvs, and bit A in ldap, instead of doing 'em all >in ldap :) I definetly did NOT say that everything would be modified via CVS. I should have implied that the data in that first block, with the exeception of status, was specialized data that should NOT exist in userinfo.xml. Nobody except the dev and infra/recruiters should be able to see it. The following things are the only ones that the devs would change themselves in LDAP: userPassword, sshPublicKey. infra/kloeri/kingtaco handle gentooAccess/gentooStatus. >35 isn't much to sync into ldap; pretty easy to do at this point also, just >generate a new userinfo.xml via perl_ldap, use diff to track down the >differences. Ok, also going the other way implies that we lock down the userinfo.xml in CVS, and direct people to LDAP. >Comments about data types however are daft; people can still commit crap >breaking it. Use perl_ldap for the mods, you can at least force data >validation. There's no enforcement to use perl_ldap. I came across a case that broken it yesterday myself. I added a secondary sshPublicKey for myself, and then wanted to delete the extra entry, but perl_ldap craped out, and I just used ldapmodify manually (since this is perl_ldap just sends the same statements to LDAP...) > Any comments that aren't related to "you have to do it this way" ? They go > away with ldap since the frontend can just do the verification... No objections there, just fix perl_ldap, k thx. > Reason for it consuming from a generated userinfo.xml was an infra decree; > worried about web cruft bringing down ldap. I don't see how web cruft could bring down LDAP in this case. > Regarding "don't fix it", theres a reason I nudged you to fix the utf8 issues > with userinfo generation for perl_ldap; with that fixed, ldap could become the > master repository of that data, and it could be exported out for consumers > expecting the old format. kloeri said the utf8 stuff was fixed (I assume somebody used by patch), and I took his word for it. In what repo is perl_ldap stored, so that I can check this properly? >> >> gentooForumsUID - only exists on lcars and mariez - do we need actually >Blame me for retiring; there is a bug open re: it, tomk should know some of the >details also- was working on pairing up forums nick -> dev to build a table to >push into ldap... > >Bit of manual work, but that list is required either way since the current way >of handling it (no offense to those handling it either) has a fair potential >for misses. fine by me, devrel just needs to remember to input said data on creation of developer account - tomk runs that script more often ;-). >Well... with ldap, the "descriptive" bit is just a matter of the frontend used >for modifying that stuff. In other words, it can be made god awfully >informative if folks find that an issue ;) Actually I was talking about the more room for data stuff in userinfo.xml. Constructed example - While on a Gentoo specific trip to Europe, I use the DTD and actually enter a phonenumber for myself (our DTD allows it already), and put a comment that it's only a temporary phone number above that. The comment isn't part of the phone number, but it is a markup comment above the phone number. >The real underlying reason for centralizing it into ldap, and trying to go the >route of having folks modify the ldap records directly instead of current >methods was that of data validation, and centraliziation. Upshot, would get >ACL on dev specific data (keys mainly), which was (and likely still is) >haphazardly tracked. Validation comes from the frontend, not LDAP itself, so could just as easily have a frontend for editing the XML ;-). What about CVS isn't centralized? GPG key/FP data is the only publically readable item that IMO should be locked to the dev editing it, but that isn't a huge concern anyway - when the keyring stuff happens later (per the tree-signing GLEPs), we need to track it better regardless. >Sidenote, would kill for a freaking preview button; bugzilla blows for >discussion of this sort... yeah. (In reply to comment #19) > >(In reply to comment #17) > >> (In reply to comment #16) > >> >> - The type attribute on mail isn't preserved in data. > >> You missed this one. > >Pardon; clarify it however please since I wasn't around for that specific > >complaint... > In userinfo.xml presently, here's a few examples of email entries: > <email role="primary">a.sleep@asleep.net</email> > <email role="gentoo">a.sleep@gentoo.org</email> > > <email role="secondary">bangert@fizzelpark.com</email> > <email role="gentoo">bangert@gentoo.org</email> > > <email role="primary">broeman@k64.dk</email> > <email role="secondary">jesper.brodersen@sourcebook.dk</email> > > <email role="primary">micke@imendio.com</email> > <email role="secondary">micke@hallendal.net</email> > <email role="gentoo">hallski@gentoo.org</email> > There's a distinct lack of pattern here. We could catch @gentoo.org as the > role=gentoo entry, but handling the order of the others is not available in > LDAP. It's multiple instances of the mail attribute, unordered. > yeah it can be solved by adding new attributes mailPrimary, mailSecondary, etc, > *me looks at perl_ldap hackers* Seperate bug bound to this one /me thinks... > I definetly did NOT say that everything would be modified via CVS. I should > have implied that the data in that first block, with the exeception of status, > was specialized data that should NOT exist in userinfo.xml. Nobody except the > dev and infra/recruiters should be able to see it. > > The following things are the only ones that the devs would change themselves in > LDAP: userPassword, sshPublicKey. location... gpg id (keys expire, folks stupidly lose them), roles offhand, surname (amazing enough, but as you've proved geeks sometimes do manage to get married ;), ForumsID comes to mind also for cases where the dev *lacks* a forums account, and gets one... Would need to see the schema to pick off the others offhand; been 8+ months. > >Comments about data types however are daft; people can still commit crap > >breaking it. Use perl_ldap for the mods, you can at least force data > >validation. > There's no enforcement to use perl_ldap. I came across a case that broken it > yesterday myself. I added a secondary sshPublicKey for myself, and then wanted > to delete the extra entry, but perl_ldap craped out, and I just used ldapmodify > manually (since this is perl_ldap just sends the same statements to LDAP...) > > > Any comments that aren't related to "you have to do it this way" ? They go > > away with ldap since the frontend can just do the verification... > No objections there, just fix perl_ldap, k thx. Bug #? I personally can't do a damn thing these days to fix it since I can't actually *test* any fixes, so you'll have to sweet talk lcars... > > Reason for it consuming from a generated userinfo.xml was an infra decree; > > worried about web cruft bringing down ldap. > I don't see how web cruft could bring down LDAP in this case. Suspect they were worried about folks hitting the rollcall page repeatedly to generate a shiteload of pulls from ldap, thus an indirect DoS attempt. Would have to ask them either way; my main intention was unifying the data in one place, doing so without too much screaming ;) > > Regarding "don't fix it", theres a reason I nudged you to fix the utf8 issues > > with userinfo generation for perl_ldap; with that fixed, ldap could become the > > master repository of that data, and it could be exported out for consumers > > expecting the old format. > kloeri said the utf8 stuff was fixed (I assume somebody used by patch), and I > took his word for it. In what repo is perl_ldap stored, so that I can check > this properly? Just log into d.g.o, and run perl_ldap -U (iirc); it'll create a userinfo.xml in your directory (again, iirc). Yes, that needs to be configured, but my perl fu is just strong enough to prevent me from puking at lcars script ('nother way of saying, I hate perl) :) Need to make that commandline configurable obviously, but I was waiting on the utf8 being fixed prior; fix came after I no longer had access... > >Well... with ldap, the "descriptive" bit is just a matter of the frontend used > >for modifying that stuff. In other words, it can be made god awfully > >informative if folks find that an issue ;) > Actually I was talking about the more room for data stuff in userinfo.xml. > Constructed example - While on a Gentoo specific trip to Europe, I use the DTD > and actually enter a phonenumber for myself (our DTD allows it already), and > put a comment that it's only a temporary phone number above that. The comment > isn't part of the phone number, but it is a markup comment above the phone > number. Don't have a good answer for that one, although introducing a comments field might suffice (although if that were heavily abused that would be indicative the schema needs an overhaul). > >The real underlying reason for centralizing it into ldap, and trying to go the > >route of having folks modify the ldap records directly instead of current > >methods was that of data validation, and centraliziation. Upshot, would get > >ACL on dev specific data (keys mainly), which was (and likely still is) > >haphazardly tracked. > Validation comes from the frontend, not LDAP itself, so could just as easily > have a frontend for editing the XML ;-). Shush, don't poke holes in my rhetoric ;) My original intention for this was to create a python module (perl if enough bitching occured) to handle validation, and simple queries; leads into next bit... > What about CVS isn't centralized? It's centralized, but getting access to it is a bit of a manual affair. You have service X that needs access to this data; ldap, you just setup the connection, for cvs, cronjob to checkout the file every N hours, dumping to a location, then have a script able to parse the full dumped xml pulling what it needs. More of an api thing there; can pull from ldap with less BS required for it, and if that common lib was written, could just use that directly for any service that needed access- this would also ensure that any writes they did into ldap would pass through validation also. Specific example that comes to mind is pushing last commit date into ldap on a cvs commit. >> *me looks at perl_ldap hackers* >Seperate bug bound to this one /me thinks... will do. >> The following things are the only ones that the devs would change themselves in >> LDAP: userPassword, sshPublicKey. >location... gpg id (keys expire, folks stupidly lose them), roles offhand, >surname (amazing enough, but as you've proved geeks sometimes do manage to get >married ;), ForumsID comes to mind also for cases where the dev *lacks* a >forums account, and gets one... argh, I need sleep. I meant to say that userPassword and sshPublicKey are the only ones that devs would change themselves that are NOT public to other developers. All of the rest (as you mentioned here - except surname), were going to be modifiable. ForumsID should probably be handled by that script you mentioned, and not manually - if you're going to be paranoid about it. BTW - it seems Christel is probably the first Gentoo dev ever to change her name in the DB ;-). >> No objections there, just fix perl_ldap, k thx. >Bug #? I personally can't do a damn thing these days to fix it since I can't >actually *test* any fixes, so you'll have to sweet talk lcars... That's why I asked where the repo was, to fix it myself. >> > Reason for it consuming from a generated userinfo.xml was an infra decree; >> > worried about web cruft bringing down ldap. >> I don't see how web cruft could bring down LDAP in this case. >Suspect they were worried about folks hitting the rollcall page repeatedly to >generate a shiteload of pulls from ldap, thus an indirect DoS attempt. Dear god no. Not ever will we do per hit stuff like that. >Just log into d.g.o, and run perl_ldap -U (iirc); it'll create a userinfo.xml >in your directory (again, iirc). Ok, my patch I prepared was never applied. There's also a case that it might be wrong (but it's possible the data in ldap is weird for that person). Please answer where the repo that has the revision controlled copy of perl_ldap is. I applied my utf8 patch to a local copy, as well as a much-needer modification so that it sorted the usernames instead of random order, and thereafter found 59 new users, and beyond those, some ~400 additions of data (where the field was blank before), along with 75 changes of data - so yes, it really has drifted quite a long way (I know i'm responsible for about 100 additions of <joined> in there, but that's it). >Don't have a good answer for that one, although introducing a comments field >might suffice (although if that were heavily abused that would be indicative >the schema needs an overhaul). Phone number is going away for the moment, I'll make do with a general comments field per developer at the moment then. >> What about CVS isn't centralized? >It's centralized, but getting access to it is a bit of a manual affair. You >have service X that needs access to this data; ldap, you just setup the >connection, for cvs, cronjob to checkout the file every N hours, dumping to a >location, then have a script able to parse the full dumped xml pulling what it >needs. Vs. a cronjob that runs an ldap script that you still need to write ;-). And I'd take XPath queries over ldap search queries any day, the later are a PITA compared to XPath. >More of an api thing there; can pull from ldap with less BS required for it, >and if that common lib was written, could just use that directly for any >service that needed access- this would also ensure that any writes they did >into ldap would pass through validation also. And this is not something that Infra would _ever_ pass onto the webservers. Generate userinfo.xml centrally if you're going to do it at all, and then push to webs. Don't generate in all 3 places seperately. Your stuff here is more orthogonal to the actual problem at hand ;-). >Specific example that comes to mind is pushing last commit date into ldap on a >cvs commit. Pushing the combined data for CVS+SVN commits might be more useful, since while CVS does currently track it nicely, SVN doesn't. Still not complex tho ;-); oneliner to do that: echo -e "dn: uid=$USER,ou=dev,dc=gentoo,dc=org\nchangetype: modify\nmodify: vcsCommitTimeStamp\nvcsCommitTimeStamp: $(date +%s)" | ldapmodify (bind param stuff here, probably have a special LDAP binddn that has write to that attribute only, without a password). (In reply to comment #21) > >> No objections there, just fix perl_ldap, k thx. > >Bug #? I personally can't do a damn thing these days to fix it since I can't > >actually *test* any fixes, so you'll have to sweet talk lcars... > That's why I asked where the repo was, to fix it myself. Probably hiding in the infra repository - at least I can't find it anywhere in public repositories. Have to ask lcars for details I guess. Restricting the bug, this info doesn't need to be public at all. why does it need to be private ? i dont see anything that can really be used to compromise us Ok, this bug is getting some loving again. devrel and myself have been talking about how to handle it. The following are rough counts of the role usage: 621 total devs 572 role=gentoo 139 role=primary 9 role=secondary That's with a minor cleanup so that there are no users with (gentoo,secondary). The only valid combinations are: (gentoo),(gentoo,primary),(gentoo,primary,secondary). With so few role=secondary people, how about we just ditch the primary/secondary seperation entirely? <email role="gentoo">$USER@gentoo.org</email> <email >$MAIL1</email> <email >$MAIL2</email> ... with NO ordering on the other emails. This is immediately doable in LDAP. Here are the other fields that LDAP/perl_ldap need to be aware of: ircalias (will default to their nick, but still be in LDAP, multiple-value allowed) webpage (defaults to dev.g.o/~username, but still in LDAP, multiple-value allowed) (In reply to comment #25) > Here are the other fields that LDAP/perl_ldap need to be aware of: > ircalias (will default to their nick, but still be in LDAP, multiple-value > allowed) > webpage (defaults to dev.g.o/~username, but still in LDAP, multiple-value > allowed) Don't forget about retireDate ;) And don't forget to drop the address field (its in ldap and the xsl). This is making progress, perl_ldap is ready to roll, and data cleanup is in progress. userinfo.xml is now updated every hour, on the :15's from LDAP. The group is locked down so that only CVS admins can commit directly to the file. |
