Brian Candler skrev: > On Sun, Jul 02, 2006 at 11:17:36AM +0200, Tony Earnshaw wrote: >> I call a failover server a physical server in sync with a master that >> will automatically take over from the master if the master should fail >> in any sense, physically or programmatically. Clustered servers would be >> an example. > > OK - so presumably it also takes over the master's IP address. In that case > it's completely transparent to the client. Right?
Yes. Whereas "fallback" is up > to the client to contact explicitly if it fails to talk to the master? Yes. That's how I got the two terms "nailed to my mind" after discussing "failover" (a while ago) with a colleague with respect to his ISC DHCP so-called failover servers. Although they're not clustered, the one can take over the DHCP duties of the other, should he fail. Bit like DNS round robin or smtp MX RRs. However, that's not failover (to my mind). IMO "failover" is a complete physical replacement of one's counterpart, should it fail for any reason whatsoever. Here we never planned for failover servers, because 1: the school's budget and 2: we use IBM eServers with hot-swap redundant power supplies, cooler systems and SCSI RAID 5 arrays. On a couple of the servers we've had to replace hard disks (yellow LED on the panel, disk out, new disk in, wait with reduced I/O for rebuild), no downtime. On my mail/master LDAP *nix* after two years' 24x7 (apart from a pretty comprehensive RHAS4 to RHAS4 system update last February). >>> According to the courier-authlib docs, with LDAP_URI this should still >>> work, >>> except you have to separate the URIs with commas. Does it not? Perhaps you >>> could detail what behaviour you have observed, and how this differs from >>> the >>> behaviour you would like to see? >> I didn't know this, I can't find it in the authlib LDAP-relevant docs; >> I'm at home today with only one test server, so I can't try it in >> practice. But adding a second LDAP listener wit a comma delimiter in >> authldaprc doesn't at least cause it to barf (LDAP_URI >> ldapi://%2fvar%2frun%2fslapd%2fldapi/, ldap://tru.leerlingen). I'll try >> it out in practice on the Courier server when I'm at work again. > > By "docs" I actually meant just the comments and example in authldaprc: > > ##NAME: LOCATION:1 > # > # Location of your LDAP server(s). If you have multiple LDAP servers, > # you can list them separated by commas and spaces, and they will be tried in > # turn. > # > > LDAP_URI ldaps://ldap.example.com, ldaps://backup.example.com I found it in my RHAS4 rpm-installed 0.58 authldaprc.distro file, installed with Courier authlib 0,58 in Feb. last. In Norwegian that's: "Kven som søkjer finn att/den som søker finner", Dutch something like "die, die zoekt, vindt". In English: "Like looking for a needle in a haystack". Sorry, but. > It's worth a try. AsI said nothing barfs and I'l try it out in practice Tuesday. [...] >> ((uid=%u)(&(accountstatus=active)(objectClass=inetMailRecipient))) That should be inetLocalMailRecipient, apart from the rest of the trash. Excuses. > OK. I believe what you've written there is not syntactically correct LDAP > filter, Actually, the syntax is worthless. Call a shovel a shovel! ;) Apart from anything else (lousy), it should be inetLocalMailRecipient. > but > (&(uid=%u)(accountstatus=active)(objectClass=inetMailRecipient)) > would be valid (if %u is substituted with the username, of course), as would > (&(uid=%u)(&(accountstatus=active)(objectClass=inetMailRecipient))) Indeed, this works with ldapsearch. > The first is an AND with three operands; the second is an AND with two > operands, the second of which is an AND with two operands. > >>> A filter is a filter. If you want to filter on multiple conditions, you can >>> use '|(..)(..)'. Are you saying you want to search with filter 1, and if >>> that search returns zero entries, try again with filter 2? >> I want to AND, not OR. authldap barfs if I try >> &(accountstatus=active)(objectClass=inetMailRecipient). By "barfs" I >> mean I get the dreaded "OPERATION NOT PERMITTED" response. > > Hmm. Well let's be more precise. I am guessing what you mean is you are > setting > > LDAP_FILTER &(accountstatus=active)(objectClass=inetMailRecipient) > > Is that correct? Now, I believe the filter constructed by Courier will be > > (&LDAP_FILTER(mail=%u)) > giving > (&&(accountstatus=active)(objectClass=inetMailRecipient)(mail=%u)) > > which is invalid. However if you add an extra level of parentheses, i.e. > > LDAP_FILTER (&(accountstatus=active)(objectClass=inetMailRecipient)) > > then it should work, as you should get > > (&(&(accountstatus=active)(objectClass=inetMailRecipient))(mail=%u)) Indeed, the former (above plus one) suggestion works (bearing in mind it should be inetLocalMailRecipient). > Now, IIRC, the filter specification sent over the LDAP protocol is actually > ASN.1 encoded; this means it's up to the *client* library to fully parse the > filter string and turn it into ASN.1. In turn, this means that if you > provide an invalid filter string, the client will barf and not even send > anything to the server. > > I'm guessing this is what the 'operation not permitted' error is reporting. This seems to be a generic translation of whatever authldap doesn't like, at any time and for whichever reason. For example, I recently posted a question as to why authldap compiled on a given RHAS4 test machine wouldn't work on any RHAS4 machine whatsoever, whereas the same code compiled on another machine worked on all of them. There was no fallible answer, the generic failure response was 'operation not permitted' and stracing and gdbing didn't give any indication at any stage of the failure whatsoever (I only discovered the answer by chance after a week's sweating over my production and test servers) . Postfix has a similar generic failure response whenever it doesn't like some particular thing: '4.5.x queue file write error'. This is done (by Wietse Venema in person, he said so) to mollify the client, while at the same time giving the local mailadmin a poke in the eye (those aren't his exact words, but that's the gist of it). > (However, does authldap log the filter string it has built, before trying to > send it to the server? If not, it would be a good thing for it to do) No. Nothing in Courier authlib nor imap logs anything useful for any debugging whatsoever, apart from your own authlib authentication code. Contrast with OpenLDAP 2.3, which gives literally hundreds of user-definable debug combinations. > If the last LDAP_FILTER above doesn't work for you, then we'll need to debug > further. No need to debug further, it seems to have been a bolean logic dysfunction in my brain (aka bracket whackit). > If this does work: well perhaps it would be easier if courier-authlib added > the extra parentheses for you, or the documentation should make it clearer > that your own subexpression needs to be enclosed in parentheses, but the > code is fine. It was me; your taking the time out to help structurally made the difference. >>> "Multiple lookup fields (not just two)" doesn't mean anything to me either. >> s/field/attribute'. In which objectClass is also counted as an attribute. > > OK, so you just mean that you want to be able to construct a filter which > matches on multiple attributes. Hopefully the above will work for you. It worked, many thanks again (maybe the LDAP docs could be improved; at the moment I'm not the right one to attempt this). --Tonni -- tonni at barlaeus.nl Tony Earnshaw Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
