| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> I've got dual opteron 270's, it shouldn't take too long ;-)
<0> actually, the build hosts are in VMs are are only single processor
<0> but it ought to still be quick
<1> dajt: everything before OpenLDAP 2.3.25 has a serious security hole
<1> and there are many critical patches since 2.3.19
<1> so if you think that there's nothing really that important past 2.3.19 OpenLDAP wise
<1> you are nuts
<2> JoBbZ: send details to secalert@redhat.com
<1> dajt: Don't you read the change logs?
<1> dajt: read the ITS data about what was fixed?
<2> In the ideal world where I only worked on OpenLDAP and had infinite time I could do all that.
<1> well, if you are the openldap maintainer for redhat, you should be on top of why things are changing
<1> it is nice to know redhat has gotten a new one ;)
<2> ...Because the previous maintainer was even more overworked than I am.
<1> i'm overworked all the time :P
<3> join the club.
<3> oh wait...
<1> tsk, hyc overworks me! ha. ;P
<3> heh heh
<2> Anyway, security holes need to go to secalert, so I can get time allocated to deal with them. Sigh.
<1> dajt: you can read it here:
<1> http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4587;selectid=4587
<2> Heh. That one. Backporting the fix to 2.0.x was a pain.
<1> why would you do anything with 2.0?
<1> 2.0 is dead
<1> and full of all sorts of problems
<2> Yeah. Unfortunatly, we still support it, so I have to backport security fixes to it.
<1> i hope redhat is re-evaluating that support...
<1> yuck
<2> Life would be so much easier if we could simply break all of our users' running setups by forcing them to upgrade to new versions.
<3> amazing. why would anyone stay with it?
<1> you are breaking your users by supporting it...
<1> given all the known issues and problems with 2.0, and its ldbm backend
<3> but by definition, their setups are already broken.
<2> The usual reasons are "It works in our setup" and "We can't afford the downtime /expense /whatever to upgrade"
<2> But I'm not a user, so I don't know what's really going through their alleged minds.
<3> sad... they only *think* it works. there are countless reports of ldbm not returning entries that existed, etc.
<3> and it doesn't do any consistency checks, can't indicate that things are corrupt after an unclean shutdown...
<3> anyone who thinks "it works for us" is just burying their head in the sand.
<4> I have a large set of computers of the major OS varieties. RedHat, Suse, Windows 2000, Windows 2003, AIX (5.1, 5.2, and 5.3), Solaris (8,9, and 10), and HPUX. Currently I keep a very large spreadsheet with usernames and p***words for each one. I wanted to move to a single sign on, but was curious what people suggest using as an authentication method.
<4> Can anyone clarify my options for creating a single sign on solution?
<5> krb5 + ldap
<4> Novell: Thanks, Do you know of any other solutions out there?
<5> I don't think there is any other one..
<1> we use krb5+ldap too
<6> blizzow, TAM SSO
<4> I could use pGINA, no?
<6> blizzow,Tivoli Accss Manger OS
<4> Sorry for the loaded questions, If I went with an LDAP + krb5 implementation, who makes the "best" ldap server implementation, I know M$ and Sun Directory are out there, should I roll my own?
<3> yeah go ahead, write your own LDAP server.
<3> of the UMich-derived LDAP servers, OpenLDAP 2.3 is the fastest out there today.
<3> MS AD is not real LDAP, but it is real slow.
<1> sun DS is pretty slow too, don't leave MS AD out in the cold...
<3> I was lumping that among the UMich-derived.
<3> which it is...
<1> ah ;)
<3> and I think MS AD has little competition in the race to the bottom.
<7> hyc: we'll see... the java ones will probably compete quite well for slowest
<3> oh, forgot about them...
<8> i need to fuzzy search the memberof field but it would appear that doing so is not possible
<8> can someone either direct me to an alternative method or show me that it is possible?
<6> how you gonna roll your own ldap
<6> i'd like to know.
<1> with rollos
<1> !
<9> hello ... I'm trying to use a telephoneNumber=+832554175108 in the dn using a modrdn operation ... but getting the error "34 invalid new RDN" ... any hint?
<9> ah, forgot .. I'm using openldap 2.3
<10> rbc: have you tried without +?
<9> Gagatan: yes .. sorry, my mistake :) the escaping was kind of wricked up...
<9> out of curiosity ... anybody here used fedora-ds ? openldap ? others ? which one would you suggest?
<9> (used -> used in production environments)
<10> openldap, oracle and sun are those my company have in production
<9> Gagatan: have you had reliability problems with openldap? can I ask you something about volumes?
<10> 28k users.
<9> Gagatan: so, it's only for authentication? or mail routing?
<11> rbc, I have 1.5 million entries in OpenLDAP
<10> authentication
<10> and addressbook
<9> _ranger_: authentication? mail routing?
<9> Gagatan: ok ...
<12> Good day, gentlemen.
<11> mail (routing, imap auth, pop3 auth, delivery etc.) of ~ 1.1 mil, radius of ~ 0.4 mil
<9> _ranger_: ever had reliability problems? which version of openldap are you running? on linux?
<9> _ranger_: all the DB_CONFIG stuff is scaring me :)
<11> rbc, 2.3.27 (because I need the latest updates for sync-repl, which we switched to about 1 month ago) on linux
<11> rbc, we had some reliability problems on ldbm on 2.1.x, no problems so far on bdb on 2.3.x
<11> rbc, all we really need in our DB_CONFIG is cache_size ... but we also have some transaction log size config
<9> _ranger_: we had quite some troubles with 2.2, berkeley db and the hdb backend ...
<11> hmm, 2.2 on bdb was ok ...
<11> what troubles?
<3> hdb had some growing pains, yes
<11> did you configure 1)db cache size in DB_CONFIG, 2)checkpointing in slapd.conf, 3)run a checkpoint cron job, 4)ensure database recover was run at start ?
<9> _ranger_: hard lockups, log transactions file not being closed ...
<9> _ranger_: index corruption...
<9> _ranger_: 1) yes ... accordingly to the faq and an email in the openldap mailing list, but still, was worried about the growth of the system, would outnumber 'the right' values calculated based on leaves/...
<9> 2) yes ... 3) no 4) yes
<9> db4.2_recover, sometimes, would succesfully recover the database...
<9> but some entries were visible with slapcat, but ldapsearch would return 'entry not found'
<11> the email you're referring to covers the minimum cache size IIRC
<11> not necessarily the best size
<9> in those cases, we would have to rerun slapindex, and even sometimes, we had to rebuild the db from scratch...
<11> rbc, BTW, what version of 2.2.x ?
<11> re-import is probably faster than reindex anyway ...
<9> _ranger_: we tryed a wide range of them :) probably, starting from 2.2.5 to 2.2.25 ...
<9> things actually got improved... but I didn't find 'production quality' code in the first 'official stable releases'
<9> so, was wondering about the 2.3 situation...
<9> _ranger_: at that time, having a cache size too low would completely hang the server under heavy load ...
<11> hmm, if you used hdb on 2.2.5, that would probably have been pretty ugly
<11> rbc, yes, having cache size too low *will* do that, especially under write load
<9> _ranger_: it was considered _stable_ ...
<9> (hdb) on 2.2.5
<3> yes, stable as long as you used your brain and tuned it.
<3> besides, the hang back in the 2.2.5 days was a BDB library bug.
<9> hyc uhm .. a client modrdn dc=test,dc=entry,dc=org on dc=test,dc=entry,dc=org would hang the server :|
<11> rbc, well, IIRC 2.3.7 was considered "stable", but I didn't switch to 2.3.x in production until about 2.3.12
<11> it is worthwhile testing everything yo uwill use
<9> hyc a slapcat |slapadd, would report errors about entry not being insertable...
<3> and "stable" just means no known issues. we get it out in the world, real users pound on it, and we get things to fix...
<9> _ranger_: yes, I know ... but, still, it is not always easy to reproduce the exact load that we will encounter... at that time, we did perform testing, and most of them were succesfull...
<11> rbc, well, 2.3.27 is doing quite well here
<11> on bdb with sync-repl
<11> I still need to test modrdn replication though ...
<11> the sync-repl delete propagation issue seems to be fixed
<3> yeah, finally. took a long time track down all of the failure cases.
<3> a few times I was tempted to say "screw it" and force a full refresh.
<3> after all, the syncrepl protocol design only promises *eventual* convergence, not immediate, and not constant...
<11> yeah, but if it's going to be the only replication method available ... it has to be better than slurpd ...
<3> true.
<11> and, forcing a full refresh on a 1 million entry database isn't exactly quick ..
<3> heh, no.
<9> how is slurpd replication with 2.3? at that time, it was probably one of the things we never had problems with...
<3> it should work the same.
<11> rbc, it's just as bad on 2.3 as on 2.2 ....
<3> but it may be going away soon.
<9> _ranger_: which kind of problems does it have?
<3> we haven't committed to deleting it from 2.4 yet, but it's on my list.
<11> rbc, it works, but there are some issues you have to workaround with replication of multiple databases to multiple slaves
<11> and, then you may be confused by false rejects
<9> _ranger_: uhm ... ok :)
<9> here do you all use heartbeat stuff to achieve master reliability? back some time ago I was reading on the openldap mailing list about an overlay to allow something similar to multi-master...
<11> rbc, I used to use red hat cluster suite ... but at present we're running on one master
<3> 2.4 has mirror-mode.
<11> I still need to rebuild the new cluster
<11> hyc, you trying to get more people to beta-test 2.4 ?
<3> multi-master is profanity around here ;)
<3> _ranger_: actually mirror-mode has been in production in Symas CDS for about a year.
<3> a couple different customers are using it, happily.
<9> lol :) did anybody take a look to fedora-ds?
<11> I think RH calls says their "multi-master" code ensures "loose synchronisation" ...
<11> which isn't really something I need
<3> uh huh.
Return to
#ldap
or
Go to some related
logs:
#perl
how to delete mails from mqueue sendmail
#css
#linux
#perl
get documentroot windows php
#mysql
apt fsck.ufs
#suse
jetx witch
|
|