| |
| |
| |
|
Page: 1 2 3 4 5
<podzap> RHEL will be the new system platform...
<podzap> the new DS software is not 100% decided as of yet
<hyc> I suppose in your case it would make sense to go with RHDS
<hyc> your NDS experience would translate over directly
<podzap> yep
<podzap> and our management code
<hyc> and you just have to talk to one company (RedHat) for everything
<podzap> but in some other systems, we might use OL
<hyc> HP is bundling OpenLDAP with their Linux distros, and offering Symas CDS as an upgrade option.
<podzap> i guess we will be done with HP fairly soon...
<podzap> but running Symas CDS on RHEL, in some situations, could be a possibility.
<hyc> Sounds fine ;) we've got RPMs for RHEL on the web site.
<podzap> the thing about recommending OL is that the bigger architects will reject it for HA architectures...
<podzap> the single-master replication is a _major_ point of contention and concern which can not be easily overcome
<JoBbZ> dunno, i had a 100% uptime last year :P
<podzap> JoBbZ: we once had a customer who told us that their systems kept crashing every day at the same time
<JoBbZ> heh
<podzap> come to find out, the cleaning lady was unplugging a server so that she could plug her vacuum cleaner in.
<JoBbZ> rofl
<podzap> point being, we have to be resilient towards that type of disaster.
<JoBbZ> yeah, i understand the point ;)
<JoBbZ> hyc has a multi-master scheme worked out
<JoBbZ> :P
<JoBbZ> for $, I bet it'd show up quickly too :P
<podzap> i don't control any money
<podzap> i'm just an architect
<JoBbZ> nods
<hyc> podzap: people who think they need multimaster just haven't analyzed their situation in enough depth.
<hyc> there are very few cases where two agents really need to modify the same piece of data.
<hyc> in most cases floating master is sufficient.
<pfn> the need for multimaster arises from the need to do heavy writes
<podzap> at the end of the day, the bigger architects simply won't buy it.
<pfn> but I think that's more applicable in transactional systems
<hyc> the bigger architects you speak of are fools.
<pfn> ldap doesn't need multi-masters as much, imo
<pfn> hyc but what if you needed to support 1000 updates a minute and a single server can't handle it?
<podzap> hyc: heh, they might be :-) they don't always listen to me :-)
<pfn> (random number)
<pfn> aside from just throwing bigger hardware at the problem
<hyc> pfn: walk through the logic, show how multimaster alleviates the capacity problem.
<klippo> there we go, got a working ldap system with mail and samba
<pfn> hyc multiple writable masters that could then replicate at a more "leisurely" rate
<JoBbZ> you have rate throttling on the replica's?
<JoBbZ> how will they ever catch up?
<hyc> it's nonsense. what if your data rate is sustained?
<pfn> indeed, that would be a problem
<pfn> but that still doesn't resolve bursts
<podzap> placing HA requirements on any architecture complicates it by a factor of 10, from my experience.
<podzap> that **** really drives me nuts.
<pfn> systems generally aren't hammered 24/7, but maybe 4-8 hours out of the day
<JoBbZ> I generally think OL should support multi-master simply so that those who think it buys them something will be happy :P
<podzap> and there are people who demand systems to be HA, when the system doesn't really need to be HA.
<SimonRaven> i've seen that just from running a home network
<hyc> pfn: the only solution that makes sense is to use a master that can handle the burst rate.
<SimonRaven> (hammered a few hours a day)
<JoBbZ> multi-master was on Stanford's initial list of requirements, but practical usage showed it wasn't necessary
<hyc> when you run a master with no indexing, big cache, and fast disks, your only limit is network bandwidth.
<SimonRaven> hyc: floating master: 2 servers that sync to each other, and clients configured to use either one depending on availability?
<SimonRaven> (well, 2 or more)
<hyc> SimonRaven: something like that. use a load balancer frontend to allocate the writes based on availability, yes.
<SimonRaven> ok, thanks
<pfn> I've seen a few emails fly across openldap-software about linux-ha with openldap
<pfn> sounds reasonable
<hyc> yes, it's being done.
<podzap> if you have two servers which sync to each other, then isn't that multi-master?
<SimonRaven> i was noticing that that's what i'd need to do, but wasn't sure how i would implement it. thanks for the advice
<hyc> yes.... but by controlling the flow of writes, you guarantee that simultaneous conflicting writes can't occur.
<pfn> hyc so, the reason why I haven't tested syncprov again... what happens in the case that I have a subordinate glued from back-ldap ?
<pfn> hyc and of course, the back-ldap doesn't know anything about syncprov or contextCSN or whatever
<pfn> how does syncprov perform?
<pfn> that never got answered in my comment to its4027 (I think it was)
<podzap> hyc: so OL can be set up where two servers accept writes, and they sync to each other?
<hyc> podzap: not by default, you need to #define a few things.
<hyc> there is no configure switch to enable it.
<pfn> oops, 3996
<pfn> 4027 was the back-meta stuff
<podzap> so in the above case, one of the servers would actually need to be restarted to change it to accept writes
<podzap> thus disconnecting all clients if you were not behind a load balancer
<hyc> restarted, no.
<hyc> just a tweak in back-config.
<podzap> or can you send something over the wire to cn=config
<podzap> OK
<pfn> are all changes in back-config reflected dynamically? which changes in back-config would require a server restart?
<hyc> pfn: just about all are dynamic. there are a few delete operations that require a restart.
<pfn> so you can define new backends dynamically? neat
<hyc> yes
<podzap> what happens if you have one server set to master, syncrepl to slave, and you send an over-the-wire to slave to be a "master" ?
<pfn> any docs on which delete ops in particular would require a restart?
<podzap> you have two masters and mayhem?
<hyc> pfn: not yet
<hyc> podzap: actually it works fine, though not documented.
<podzap> pfn: this is handled e.g. in NDS by listing those attributes in cn=config as nsslapd-requires-restart
<podzap> which is multi-valued
<podzap> could be a good idea also for OL
<pfn> hyc so, any ideas on the performance of syncprov if it descends into a large (300k records) subordinate back-meta? I don't think I ever got an answer to that
<pfn> podzap that'd be interesting if OL would do that as well
<hyc> pfn: there is no answer to that. it depends entirely on what meta is talking to.
<pfn> hyc meta is talking to a 3rd party ldap directory
<hyc> looking at the code, there are 4 attrs that require a restart: deleting a SLAPI plugin, deleting a dynamically loaded module
<pfn> not openldap, doesn't have entryCSN or know anything about syncprov
<pfn> that's two :p
<hyc> deleting authzregexp rule, deleting rewrite rule
<pfn> oh, ok, there they go ;-)
<podzap> would be simple to code that list statically into cn=config
<JoBbZ> hm, now to just make slapd self-restarting..
<podzap> then people could write data-driven management applications
<hyc> currently the return code from the operation includes that message "change requires slapd restart"
<podzap> self-restarting? are you mad? :-)
<JoBbZ> nah, just self-restarting in the case of changes requiring restarts :P
<JoBbZ> could be optional of coruse
<JoBbZ> ;)
<pfn> but I'm happy with my slurpd now that I use ssl certs
<pfn> don't have to worry about silly krb5 tickets
<podzap> JoBbZ: not too nice when you have some thousand connected clients :-)
<JoBbZ> my clients don't talk to the master
<JoBbZ> :P
<hyc> podzap: I've outlined on -devel how to do restarts without losing connections.
<JoBbZ> more of a problem I suppose if I had to makea change to a replica's cn=config
<JoBbZ> pfn: I prefer gssapi replication to SSL replication cause OpenSSL is leaky
<JoBbZ> plus it works just fine for me :P
<podzap> i gotta subscribe to -devel
<JoBbZ> just a few simple ticket management tools, and boom, it is all good
<pfn> dunno how leaky openssl is, haven't tested enough to be sure
<pfn> but I don't like having so many extraneous services running
<JoBbZ> well, since my entire infrastructure is based on kerberos, it isn't paritcularly extraneous :P
<pfn> and ssl is generally accepted practice
<pfn> well, I do a lot of simple binds against ldap
<pfn> so it's all gotta be protected anyway
<JoBbZ> yeah, i have those disabled :P
<podzap> hmm, what about a patch to OL to use NSS instead of OpenSSL?
<JoBbZ> it is either anonymous or GSSAPI
<JoBbZ> or go debian's route with GnuTLS
<JoBbZ> :P
<pfn> db2, apache, system logins, etc.
<hyc> podzap: I've thought of it. not sure yet if there's a net win.
<JoBbZ> our apache does GSSAPI binds
<hyc> I'll be merging GNUtls support in a few weeks.
<JoBbZ> system logins use anonymous binds for user information (other than p***word, which goes throught he KDC)
<hyc> s/merging/writing/ sigh...
<podzap> hyc: well the most obvious win is that NSS is maintained by the people who invented SSL :-)
<hyc> yes...
<hyc> but mozilla.org is not what it used to be.
<pfn> gnutls any good?
<hyc> I have two patches against the nss code base that have sat in their bugzilla, approved, waiting to be checked in, since .. March? April? whatever...
<podzap> that stinks!
<hyc> yes
<hyc> it stinks.
<hyc> pfn: re: GNUtls, I have doubts.
<hyc> won't know until I'm in the middle of it....
Return to ldap
or
Go to some related
logs:
trondheim
java
poker
|
|