| ../irclogs/#mantishelp.2009-12-20.log | ||
| --- scribe started --- | 00:00 | |
| paul__ | dhx_m / nuclear_eclipse : *SIGH* | 00:15 |
|---|---|---|
| paul__ | dhx_m: up still? | 09:35 |
| * paul__ wonders how one gets 1.2master branch | 10:01 | |
| dhx_m | paul__: hey | 10:36 |
| dhx_m | paul__: git checkout master-1.2.x | 10:37 |
| paul__ | $ git checkout master-1.2.x | 11:15 |
| paul__ | error: pathspec 'master-1.2.x' did not match any file(s) known to git. | 11:15 |
| dhx_m | oh | 11:25 |
| dhx_m | you need to add a new remote | 11:25 |
| dhx_m | hmmm actually no you don't... | 11:25 |
| dhx_m | does master-1.2.x show in git branch -a | 11:26 |
| dhx_m | git branch --help | 11:26 |
| dhx_m | oops | 11:26 |
| paul__ | yea | 11:26 |
| paul__ | remotes/orogin/master | 11:27 |
| dhx_m | try git checkout origin/master-1.2.x | 11:28 |
| dhx_m | ? | 11:28 |
| paul__ | gives a warning about it's not a local branch | 11:28 |
| paul__ | but I guess it changes? | 11:28 |
| dhx_m | oops | 11:29 |
| dhx_m | try: | 11:29 |
| paul__ | it's changed | 11:29 |
| dhx_m | git checkout --track -b master-1.2.x origin/master-1.2.x | 11:29 |
| paul__ | so I guess I can work on it? | 11:29 |
| dhx_m | that will create a local tracking branch with the same name | 11:29 |
| dhx_m | normally you'd want to stage commits in a local branch | 11:30 |
| paul__ | now do we want 1.2 to be 5.09 or 5.10? | 11:30 |
| dhx_m | and then check them, and "git push origin master master-1.2.x" to make the changes go live | 11:30 |
| dhx_m | same as 1.3.x I'd argue | 11:30 |
| paul__ | master master? | 11:30 |
| dhx_m | our dependencies should always be the latest stable version so we're up to date with security fixes, etc | 11:31 |
| dhx_m | nah... git push origin {branch1} {branch2} ... {branchX} | 11:31 |
| paul__ | why would I want to push to master? | 11:31 |
| dhx_m | you can push multiple branches at once to the remote (in this case 'origin') | 11:31 |
| dhx_m | if you make changes to your local master (1.3.x) branch | 11:32 |
| paul__ | then i'd just push to master | 11:32 |
| paul__ | $ git cherry-pick 69aa96a3a347e80e3ddf3b2f5692c178bbdf6e31 | 11:33 |
| paul__ | Automatic cherry-pick failed. After resolving the conflicts, | 11:33 |
| paul__ | mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result. | 11:33 |
| paul__ | When commiting, use the option '-c 69aa96a' to retain authorship and message. | 11:33 |
| paul__ | mmmmmm | 11:33 |
| dhx_m | what are you cherry-picking? | 11:33 |
| dhx_m | oh | 11:33 |
| dhx_m | it's better to revert my commit | 11:33 |
| dhx_m | delete the entire library/ directory | 11:34 |
| paul__ | I did | 11:34 |
| dhx_m | then copy the one from 1.3.x | 11:34 |
| paul__ | hmm | 11:34 |
| dhx_m | and just make an overall "sync" commit | 11:34 |
| dhx_m | ezC is also behind times in the 1.2.x branch | 11:34 |
| paul__ | yea I know | 11:34 |
| paul__ | i've updated it locally | 11:34 |
| paul__ | I think we should put jquery into library dir too at some point | 11:34 |
| paul__ | and start using it | 11:34 |
| dhx_m | I think it'd just be better if 1.2.x and 1.3.x library/ directories were 1:1 copies | 11:35 |
| dhx_m | unless of course we add more dependencies in 1.3.x or later versions | 11:35 |
| dhx_m | or we use a development version of a library in 1.3.x but not 1.2.x | 11:35 |
| paul__ | what i'm not happy with atm | 11:36 |
| paul__ | is we've added shit since rc1/rc2 to 1.2 | 11:36 |
| paul__ | that I think we should pull out | 11:36 |
| paul__ | in trunk | 11:36 |
| dhx_m | examples? | 11:36 |
| paul__ | obvious example: | 11:36 |
| paul__ | ldap api now stores md5 hash of password in mantis table | 11:37 |
| paul__ | I've asked 3 friends from elsewhere so far | 11:37 |
| dhx_m | what's the point in storing md5 hashes? they can be cracked in no time at all | 11:37 |
| paul__ | who have all gone 'wtf' | 11:37 |
| paul__ | Personally | 11:37 |
| paul__ | i'll be pulling that code out from my work version of ldap api | 11:37 |
| dhx_m | why are there hashes of passwords stored in Mantis at all? | 11:38 |
| paul__ | er? | 11:38 |
| paul__ | so you can log in ? :P | 11:38 |
| dhx_m | isn't the whole idea of LDAP that you authenticate users via LDAP (hence passwords aren't stored in the Mantis DB)? | 11:38 |
| paul__ | one friends comment: | 11:38 |
| paul__ | 'well, personally i'd try to avoid any redundancy, if someone wants ldap, let them use it and if ldap is important enough they'll make sure it's redundant anyway | 11:39 |
| paul__ | in a windows world | 11:39 |
| paul__ | (where I expect most people would probably find ldap these days ? (aka AD) | 11:39 |
| dhx_m | you've confused me so much now... what has redundancy got to do with password hashing? | 11:39 |
| paul__ | i.e. storing ldap password is redundancy you'd want to avoid | 11:39 |
| dhx_m | is the idea in Mantis that if LDAP goes offline, you can use locally cached passwords in the DB for authentication? | 11:39 |
| paul__ | I think so ;p | 11:40 |
| dhx_m | if that's the case then *ugh* | 11:40 |
| dhx_m | I just don't see why we should be storing duplicate information of data that is normally pulled from LDAP | 11:41 |
| paul__ | the simulation stuff that's been added to 'simulate ldap from a text file' is making it more difficult for me to merge in my work changes | 11:41 |
| paul__ | so for work | 11:41 |
| paul__ | i'm gonna code a new ldap api I think | 11:41 |
| dhx_m | unless LDAP queries are many times more expensive than SQL queries? | 11:41 |
| paul__ | as i cba fixing my changes into our current ldap api | 11:41 |
| dhx_m | it requires a lot of planning though | 11:42 |
| dhx_m | basically a new authentication API | 11:42 |
| dhx_m | that can allow for plugins to provide external data | 11:42 |
| paul__ | well | 11:44 |
| paul__ | the new ldap stuff we now have kicks off more quieries then the old stuff | 11:44 |
| paul__ | it's a mess ;/ | 11:44 |
| paul__ | the password duplication stuff was added in july 2009 | 11:45 |
| paul__ | no sorry | 11:45 |
| paul__ | October 2009 | 11:45 |
| paul__ | Tue, 6 Oct 2009 - Updated release notes for RC2 | 11:46 |
| paul__ | 2009-10-26 | 11:46 |
| paul__ | it's a POST-RC2 change | 11:46 |
| * paul__ checks whether it has been ported to master-1.2 | 11:46 | |
| paul__ | it's a post rc2 change | 11:47 |
| paul__ | that has been ported to master 1.2 | 11:47 |
| paul__ | that I want to get rid of in 1.3/trunk asap | 11:47 |
| dhx_m | check with whoever committed it though | 11:48 |
| dhx_m | it might have been part of a larger plan | 11:48 |
| dhx_m | paul__: http://git.mantisbt.org/?p=mantisbt.git;a=commit;h=a8f9af9c39ec5603cfd7787ff324f65a6c5466e0 | 11:49 |
| dhx_m | paul__: did you read the commit message? it seems like a fairly compelling need to me, short of moving LDAP out into a separate plugin | 11:50 |
| dhx_m | paul__: and then adding new events like user_get_realname, etc that the new LDAP plugin hooks | 11:50 |
| paul__ | the idea of ldap is it's redundant... | 11:54 |
| dhx_m | yes, but the commit isn't about providing redundancy | 11:54 |
| paul__ | 1. Locations that require retrieval of user realname don't have to know about LDAP. | 11:54 |
| dhx_m | it's about decoupling LDAP from the rest of the code (so user_api.php doesn't need to know about LDAP) | 11:54 |
| paul__ | that's wrong though | 11:55 |
| paul__ | the realname display function should check against ldap | 11:55 |
| paul__ | so that changes are immediately picked up | 11:55 |
| dhx_m | agreed | 11:55 |
| paul__ | so therefore | 11:55 |
| dhx_m | but it should really be done via a plugin hook IMO | 11:55 |
| paul__ | there's no point to store it in db | 11:55 |
| dhx_m | that way you can authenticate via whatever means you want | 11:55 |
| paul__ | 2. Database information will be kept up to date and hence we can fallback to the database. | 11:55 |
| dhx_m | PAM, LDAP, etc | 11:56 |
| paul__ | you'd normally have >1 ldap server | 11:56 |
| paul__ | by the time you try a connect to multiple servers | 11:56 |
| paul__ | the fallback is gonna be slow | 11:56 |
| paul__ | so it might be better to alert user if all servers are down | 11:56 |
| dhx_m | I agree on (2) | 11:56 |
| paul__ | i.e. 3 servers | 11:56 |
| paul__ | 10 seconds to make a ldap query + allow to timeout | 11:56 |
| paul__ | = 30 seconds | 11:56 |
| paul__ | after 30 seconds if ldap hasn't responded, sure you could fallback to db | 11:57 |
| dhx_m | what about (3) though... are there performance considerations? I'd argue there wouldn't be in a well designed LDAP plugin (it caches values it pulls from the directory)? | 11:57 |
| dhx_m | I'd argue fallbacks are bad design | 11:57 |
| dhx_m | the purpose of LDAP is to have a central store for authentication/account info | 11:57 |
| dhx_m | if it's down, then you can't be sure you've got the latest account information (which is updated by third parties external from Mantis) | 11:58 |
| dhx_m | therefore it's safer to assume that all accounts have been disabled (ie. lockout Mantis until LDAP comes back online) | 11:58 |
| paul__ | performance: well, I'm not sure we've had users report issues? | 11:59 |
| paul__ | and I suspect that with AD (probably biggest ldap server?) there's enough queries being generated by logons/exchange etc | 12:00 |
| paul__ | 4. Less possibility for LDAP specific bugs. | 12:00 |
| paul__ | and i'd say is invalid | 12:00 |
| paul__ | if you've got one realname in ldap | 12:00 |
| paul__ | + a different one in mantis | 12:00 |
| dhx_m | agreed on (4) | 12:00 |
| paul__ | the idea is sensible | 12:01 |
| paul__ | however like... | 12:01 |
| paul__ | to access mantis @ work | 12:01 |
| paul__ | from home | 12:01 |
| paul__ | i'd need to log in via isa server | 12:01 |
| dhx_m | and with (3) I think we still need caching (don't hit LDAP every time we need the real name... only the first time for each PHP process) | 12:01 |
| paul__ | which requires my user/pass to be sent to LDAP server | 12:01 |
| paul__ | before I see mantis | 12:01 |
| dhx_m | however you're right that storing that information in an SQL database is not a good caching method | 12:02 |
| paul__ | to an extent we hide realname | 12:02 |
| dhx_m | as you said, we now have two points of failure instead of one, and the sources can desync, etc | 12:02 |
| paul__ | there's two bits of data: | 12:02 |
| paul__ | a) username | 12:02 |
| paul__ | b) userid | 12:02 |
| paul__ | c) realname | 12:02 |
| paul__ | d) email | 12:02 |
| paul__ | for the most part email gets used in two places: | 12:02 |
| paul__ | a) view user page | 12:02 |
| paul__ | b) manage/* | 12:02 |
| dhx_m | can't you store any data with LDAP? | 12:02 |
| paul__ | c) email api for events | 12:02 |
| dhx_m | ie. you can create your own fields? | 12:03 |
| paul__ | yea | 12:03 |
| paul__ | i'm talking about what mantis does atm | 12:03 |
| paul__ | now ifyour sending an email to a user | 12:03 |
| paul__ | you'd probably want to check ldap for latest email address | 12:03 |
| paul__ | the *problem* one is probably | 12:03 |
| paul__ | realname | 12:03 |
| dhx_m | is it easy for LDAP admins to add extra fields? | 12:03 |
| paul__ | fairly i believe | 12:03 |
| paul__ | i.e. if you display realname not user names | 12:03 |
| paul__ | so it might be sensible to cache realname | 12:04 |
| dhx_m | ah, does LDAP suck for lookups (ie. find all users with an email address matching %something.com and who are part of the 'reporters' group)? | 12:04 |
| paul__ | however, i'd do it in a seperate table (i.e. as part of plugin) | 12:04 |
| paul__ | we dont do those type's of queries | 12:04 |
| dhx_m | I imagine we do... for instance, generating an email list for notifying users of changes to a bug | 12:05 |
| paul__ | we'd always go from the username | 12:05 |
| dhx_m | we don't want to send off 500 queries to an LDAP server with each one asking for the email address of a single user | 12:05 |
| dhx_m | paul__: ldap_search() in PHP handles these lookups anyway :) | 12:07 |
| paul__ | ? | 12:07 |
| dhx_m | paul__: http://php.net/manual/en/function.ldap-search.php | 12:07 |
| dhx_m | paul__: pulling information on multiple users at once from the LDAP tree | 12:07 |
| paul__ | yea up to 1000 | 12:08 |
| paul__ | at a time | 12:08 |
| paul__ | iirc | 12:08 |
| paul__ | dhx_m: ? | 22:53 |
Generated by irclog2html.py