openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8639) Remove support for LANMAN
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

Hi, Is this just the support for LANMAN hashes of passwords in slapd? There seems to also be some stand alone support for samba LANMAN passwords = in the smbk5pwd module. Cheers, Andy

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

@Alex The difference in behaviour is because it constructs a uri from the h= ostname and port. If there is no port you end up with an invalid uri. I am = not sure if this is necessarily a good thing. Cheers, Andy

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by arekkusu＠r42.ch 03 Mar '18

03 Mar '18

I was referring to best practice/RFC regarding what is a valid hostname. My example was intentionally provocative. I think rejecting hostname containing the '://' construct is actually a good idea. Those would be problematic for parsing and such broken hostname are unlikely to ever be use. Been reading a bit more (1) and I think internationalized domain are also not an issue as they have a ASCII representation. So the only real concern I can think of at this point is underscore. But I could be missing something... I am still not convinced about having addition verification beside: - What the DNS standard says (RFC2181) - Prohibiting hostname that would cause cause an issue with parsing ('://') Why do the 'host' and 'dig' command does not seem to place any restriction when querying for A records ? (would be interested to see how other software handle this) Andew: Did you manage to find out why the behavior with '-h' option and both ' --h' and '-p' option was different ? Best, Alex (1) https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have- an-underscore-in-it PS: Andrew: In my client (evolution) your previous plain text email did show up as base64 encoded. (had to use 'base64 -d' to read them). I did not remember outlook making it so hard to send plain text email (!) On Sat, 2018-03-03 at 10:29 +0000, michael(a)stroeder.com wrote: > Alexandre Rosenberg wrote: > > Micheal, you are *right* about the man page saying _hostname_. Indeed > > OpenLDAP > > only accepting hostname as per best practice/RFC might be the most correct > > behavior. > > There is no relevant RFC or best practice, only the man-page. And the -h > and -p arguments come from the old UMich LDAP times. > > > However we can not change this behavior without breakable. consider: > > AFAICS backward compability has only be provided to those ancient Umich > or Netscape Directory tools. So IMO LDAP URI does not have to be accepted. > > > - Underscore are not that uncommon with Active Directory > > - What about > > - ... (probably more) > > If you want to fix something for 2.4.x to match what the man-page says > you could effectively reject LDAP URI by simply rejecting colons and > slashes. Those chars are never in even seriously broken hostnames. If > they were they would cause more interop issues anyway. > > > Therefore I believe such change could only be done in a major release. And > > at > > that point we might just remove the depreciated '-h' option altogether. > > Agreed. 2.5 release chould IMO simply remove options -h and -p. > > Ciao, Michael. > > >

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

I am using Outlook and in addition to sending messages with HTML by default= it also uses some kind of encoding if you select plain text. I have spent = most of the afternoon trying to turn this off and hopefully I have now been= successful. I followed the instructions to upload the patch (andrew-lawrence-180303.pa= tch) to ftp://openldap.org/incoming/. I am not sure if it was successful a= s I cannot see the contents of the folder. The attached file is derived from OpenLDAP Software. All of the modificatio= ns to OpenLDAP Software represented in the following patch(es) were develop= ed by Siemens Rail Automation Holdings Limited. Siemens Rail Automation Hol= dings Limited has not assigned rights and/or interest in this work to any p= arty. I, Andrew Lawrence am authorized by Siemens Rail Automation Holdings = Limited, my employer, to release this work under the following terms. Siemens Rail Automation Holdings Limited hereby place the following modific= ations to OpenLDAP Software (and only these modifications) into the public = domain. Hence, these modifications may be freely used and/or redistributed = for any purpose with or without attribution and/or other notice. Cheers, Andy -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 02 March 2018 22:53 To: Lawrence, Andy (MO MM R&D UK IXL); openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with andrew.lawrence(a)siemens.com wrote: > --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: multipart/alternative; > boundary=3D"_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5M= SXww9_" > > --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: text/plain; charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > I believe the following patch addresses this problem. I am still a bit > conf=3D used about what constitutes a DNS name. Alex has suggested they > should cont=3D ain an underscore. My colleague who reviewed the code had > a different opini=3D on. > > > > I am also not sure what to do about copyright headers and whether it > is acc=3D eptable or not for me to add them into the files. Please read the Contributing guidelines. Please do not use HTML email. Please demonstrate a basic ability to read and follow directions, otherwise= your patch will be discarded. It's not like the information is hard to fin= d, everything is linked from the front page of the web site. http://www.openldap.org/devel/contributing.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by michael＠stroeder.com 03 Mar '18

03 Mar '18

Alexandre Rosenberg wrote: > Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP > only accepting hostname as per best practice/RFC might be the most correct > behavior. There is no relevant RFC or best practice, only the man-page. And the -h and -p arguments come from the old UMich LDAP times. > However we can not change this behavior without breakable. consider: AFAICS backward compability has only be provided to those ancient Umich or Netscape Directory tools. So IMO LDAP URI does not have to be accepted. > - Underscore are not that uncommon with Active Directory > - What about internationalized DNS name > - ... (probably more) If you want to fix something for 2.4.x to match what the man-page says you could effectively reject LDAP URI by simply rejecting colons and slashes. Those chars are never in even seriously broken hostnames. If they were they would cause more interop issues anyway. > Therefore I believe such change could only be done in a major release. And at > that point we might just remove the depreciated '-h' option altogether. Agreed. 2.5 release chould IMO simply remove options -h and -p. Ciao, Michael.

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 03 Mar '18

03 Mar '18

SSBmb2xsb3dlZCB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHVwbG9hZCB0aGUgcGF0Y2ggIChhbmRyZXct bGF3cmVuY2UtMTgwMzAzLnBhdGNoKSAgdG8gZnRwOi8vb3BlbmxkYXAub3JnL2luY29taW5nLy4g SSBhbSBub3Qgc3VyZSBpZiBpdCB3YXMgc3VjY2Vzc2Z1bCBhcyBJIGNhbm5vdCBzZWUgdGhlIGNv bnRlbnRzIG9mIHRoZSBmb2xkZXIuDQoNClRoZSBhdHRhY2hlZCBmaWxlIGlzIGRlcml2ZWQgZnJv bSBPcGVuTERBUCBTb2Z0d2FyZS4gQWxsIG9mIHRoZSBtb2RpZmljYXRpb25zIHRvIE9wZW5MREFQ IFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlcmUgZGV2 ZWxvcGVkIGJ5IFNpZW1lbnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdzIExpbWl0ZWQuIFNpZW1l bnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdzIExpbWl0ZWQgaGFzIG5vdCBhc3NpZ25lZCByaWdo dHMgYW5kL29yIGludGVyZXN0IGluIHRoaXMgd29yayB0byBhbnkgcGFydHkuIEksIEFuZHJldyBM YXdyZW5jZSBhbSBhdXRob3JpemVkIGJ5IFNpZW1lbnMgUmFpbCBBdXRvbWF0aW9uIEhvbGRpbmdz IExpbWl0ZWQsIG15IGVtcGxveWVyLCB0byByZWxlYXNlIHRoaXMgd29yayB1bmRlciB0aGUgZm9s bG93aW5nIHRlcm1zLg0KDQpTaWVtZW5zIFJhaWwgQXV0b21hdGlvbiBIb2xkaW5ncyBMaW1pdGVk IGhlcmVieSBwbGFjZSB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbnMgdG8gT3BlbkxEQVAgU29m dHdhcmUgKGFuZCBvbmx5IHRoZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21h aW4uIEhlbmNlLCB0aGVzZSBtb2RpZmljYXRpb25zIG1heSBiZSBmcmVlbHkgdXNlZCBhbmQvb3Ig cmVkaXN0cmlidXRlZCBmb3IgYW55IHB1cnBvc2Ugd2l0aCBvciB3aXRob3V0IGF0dHJpYnV0aW9u IGFuZC9vciBvdGhlciBub3RpY2UuDQoNCkNoZWVycywNCkFuZHkNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEhvd2FyZCBDaHUgW21haWx0bzpoeWNAc3ltYXMuY29tXSANClNl bnQ6IDAyIE1hcmNoIDIwMTggMjI6NTMNClRvOiBMYXdyZW5jZSwgQW5keSAoTU8gTU0gUiZEIFVL IElYTCk7IG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmcNClN1YmplY3Q6IFJlOiAoSVRTIzg2MTgp IGxkYXBzZWFyY2ggLSB1bmV4cGVjdGVkIGJlaGF2aW9yIHdpdGgNCg0KYW5kcmV3Lmxhd3JlbmNl QHNpZW1lbnMuY29tIHdyb3RlOg0KPiAtLV8wMDRfNENGNzEwMjI5Nzg3QTA0MTlCRjkyQzkzMDRE QzY0NDZFNzkyN0FERUZUSFc5OUVJNU1TWHd3OV8NCj4gQ29udGVudC1UeXBlOiBtdWx0aXBhcnQv YWx0ZXJuYXRpdmU7DQo+IAlib3VuZGFyeT0iXzAwMF80Q0Y3MTAyMjk3ODdBMDQxOUJGOTJDOTMw NERDNjQ0NkU3OTI3QURFRlRIVzk5RUk1TVNYd3c5XyINCj4gDQo+IC0tXzAwMF80Q0Y3MTAyMjk3 ODdBMDQxOUJGOTJDOTMwNERDNjQ0NkU3OTI3QURFRlRIVzk5RUk1TVNYd3c5Xw0KPiBDb250ZW50 LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9Imlzby04ODU5LTEiDQo+IENvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCj4gDQo+IEkgYmVsaWV2ZSB0aGUgZm9sbG93 aW5nIHBhdGNoIGFkZHJlc3NlcyB0aGlzIHByb2JsZW0uIEkgYW0gc3RpbGwgYSBiaXQgDQo+IGNv bmY9IHVzZWQgYWJvdXQgd2hhdCBjb25zdGl0dXRlcyBhIEROUyBuYW1lLiBBbGV4IGhhcyBzdWdn ZXN0ZWQgdGhleSANCj4gc2hvdWxkIGNvbnQ9IGFpbiBhbiB1bmRlcnNjb3JlLiBNeSBjb2xsZWFn dWUgd2hvIHJldmlld2VkIHRoZSBjb2RlIGhhZCANCj4gYSBkaWZmZXJlbnQgb3Bpbmk9IG9uLg0K PiANCj4gDQo+IA0KPiBJIGFtIGFsc28gbm90IHN1cmUgd2hhdCB0byBkbyBhYm91dCBjb3B5cmln aHQgaGVhZGVycyBhbmQgd2hldGhlciBpdCANCj4gaXMgYWNjPSBlcHRhYmxlIG9yIG5vdCBmb3Ig bWUgdG8gYWRkIHRoZW0gaW50byB0aGUgZmlsZXMuDQoNClBsZWFzZSByZWFkIHRoZSBDb250cmli dXRpbmcgZ3VpZGVsaW5lcy4NClBsZWFzZSBkbyBub3QgdXNlIEhUTUwgZW1haWwuDQoNClBsZWFz ZSBkZW1vbnN0cmF0ZSBhIGJhc2ljIGFiaWxpdHkgdG8gcmVhZCBhbmQgZm9sbG93IGRpcmVjdGlv bnMsIG90aGVyd2lzZSB5b3VyIHBhdGNoIHdpbGwgYmUgZGlzY2FyZGVkLiBJdCdzIG5vdCBsaWtl IHRoZSBpbmZvcm1hdGlvbiBpcyBoYXJkIHRvIGZpbmQsIGV2ZXJ5dGhpbmcgaXMgbGlua2VkIGZy b20gdGhlIGZyb250IHBhZ2Ugb2YgdGhlIHdlYiBzaXRlLg0KDQpodHRwOi8vd3d3Lm9wZW5sZGFw Lm9yZy9kZXZlbC9jb250cmlidXRpbmcuaHRtbA0KDQotLSANCiAgIC0tIEhvd2FyZCBDaHUNCiAg IENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICBEaXJl Y3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8NCiAgIENo aWVmIEFyY2hpdGVjdCwgT3BlbkxEQVAgIGh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3Qv DQo=

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by arekkusu＠r42.ch 02 Mar '18

02 Mar '18

I am also not a C programmer. I've not even looked at patch at this point. I agree best practice says hostname are limited to specific ASCII characters. And underscore are indeed not included. However DNS name in general only have very few restriction (RFC2181) (2). I did some tests using the 'host' and 'dig' command and they do not perform additional validation. For example (2): $ host 'ldap://.test.com' ldap://.test.com has address 69.172.200.109 I would expect C library for resolving DNS names to already enforce those basic constrain. I believe we should be careful about performing additional validation/restriction. Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP only accepting hostname as per best practice/RFC might be the most correct behavior. However we can not change this behavior without breakable. consider: - Underscore are not that uncommon with Active Directory - What about internationalized DNS name - ... (probably more) Therefore I believe such change could only be done in a major release. And at that point we might just remove the depreciated '-h' option altogether. I don't know how OpenLDAP code work. I have a suspicion it might transform hostname + port into a URI. The ITC shows that (for some cases) hostname are handled differently when: 1. Using only '-h' without '-p' 2. Using both '-h' and '-p' And this is clearly not a correct behavior. Best, Alex (1) See RFC for reference but essentially: - A full domain name is limited to 255 octets (including the separators) - Each part of the domain (label) can be between 1 and 63 octets (2) test.com DNS seems to simply return the same A record for any subdomain (wildcard). It highlights that wierd name like works at the DNS level. PS: I exchanged a few email regarding DNS/hostname with Lawrence off the list. I believe this email summarizes the main points from my perspective. On Fri, 2018-03-02 at 18:48 +0000, michael(a)stroeder.com wrote: > andrew.lawrence(a)siemens.com wrote: > > I believe the following patch addresses this problem. I am still a > > bit conf used about what constitutes a DNS name. Alex has suggested > > they should contain an underscore. My colleague who reviewed the code > > had a different opinion. > > Disclaimer: Since I'm not a C programmer I did not really review your > patch in detail but just want to add some general notes. > > 1. Reviewing this ticket my is that the only problem is that > -h also accepts a LDAP URI because -H should be used instead. > IIRC -h was only meant to take an IP address or hostname. > Therefore I'd strongly recommend to simply reject an LDAP URI for -h. > Is that your goal? > > 2. The term "DNS name" is a bit too blurry. In case of option -h it > should be an IP address or . And according to best practices > hostnames SHOULD NOT contain underscores. > Whether you _allow_ underscores to accommodate some strange setups is > your decision. > > Ciao, . > > >

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by hyc＠symas.com 02 Mar '18

02 Mar '18

andrew.lawrence(a)siemens.com wrote: > --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: multipart/alternative; > boundary="_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_" > > --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > I believe the following patch addresses this problem. I am still a bit conf= > used about what constitutes a DNS name. Alex has suggested they should cont= > ain an underscore. My colleague who reviewed the code had a different opini= > on. > > > > I am also not sure what to do about copyright headers and whether it is acc= > eptable or not for me to add them into the files. Please read the Contributing guidelines. Please do not use HTML email. Please demonstrate a basic ability to read and follow directions, otherwise your patch will be discarded. It's not like the information is hard to find, everything is linked from the front page of the web site. http://www.openldap.org/devel/contributing.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 02 Mar '18

02 Mar '18

SGkgTWljaGFlbCwNCg0KTXkgZ29hbCB3YXMgdG8gb25seSBhbGxvdyB2YWxpZCBob3N0bmFtZXMg d2hlbiB1c2luZyB0aGUgLWggb3B0aW9uLiBBICBiaXByb2R1Y3Qgb2YgdGhpcyBpcyB0aGF0IGxk YXAgdXJpcyBhcmUgYWxzbyByZWplY3RlZC4NCg0KVGhlIHBhdGNoIHJlamVjdHMgaG9zdG5hbWVz IHdpdGggdW5kZXJzY29yZXMgYXMgYmVpbmcgaW52YWxpZC4gSSBoYWQgaGVhcmQgc2V2ZXJhbCBv cGluaW9ucyB3aGVuIHdyaXRpbmcgdGhlIHBhdGNoIGFuZCBvbmUgb2YgdGhlbSB3YXMgdGhhdCBB Y3RpdmUgRGlyZWN0b3J5IGFsbG93cyB1bmRlcnNjb3JlcyBpbiBob3N0bmFtZXMuDQoNCkFuZHkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgU3Ryw7ZkZXIgW21h aWx0bzptaWNoYWVsQHN0cm9lZGVyLmNvbV0NClNlbnQ6IDAyIE1hcmNoIDIwMTggMTg6NDgNClRv OiBMYXdyZW5jZSwgQW5keSAoTU8gTU0gUiZEIFVLIElYTCk7IG9wZW5sZGFwLWl0c0BPcGVuTERB UC5vcmcNClN1YmplY3Q6IFJlOiAoSVRTIzg2MTgpIGxkYXBzZWFyY2ggLSB1bmV4cGVjdGVkIGJl aGF2aW9yIHdpdGgNCg0KYW5kcmV3Lmxhd3JlbmNlQHNpZW1lbnMuY29tIHdyb3RlOg0KPiBJIGJl bGlldmUgdGhlIGZvbGxvd2luZyBwYXRjaCBhZGRyZXNzZXMgdGhpcyBwcm9ibGVtLiBJIGFtIHN0 aWxsIGEgYml0DQo+IGNvbmYgdXNlZCBhYm91dCB3aGF0IGNvbnN0aXR1dGVzIGEgRE5TIG5hbWUu IEFsZXggaGFzIHN1Z2dlc3RlZCB0aGV5DQo+IHNob3VsZCBjb250YWluIGFuIHVuZGVyc2NvcmUu IE15IGNvbGxlYWd1ZSB3aG8gcmV2aWV3ZWQgdGhlIGNvZGUgaGFkIGENCj4gZGlmZmVyZW50IG9w aW5pb24uDQpEaXNjbGFpbWVyOiBTaW5jZSBJJ20gbm90IGEgQyBwcm9ncmFtbWVyIEkgZGlkIG5v dCByZWFsbHkgcmV2aWV3IHlvdXIgcGF0Y2ggaW4gZGV0YWlsIGJ1dCBqdXN0IHdhbnQgdG8gYWRk IHNvbWUgZ2VuZXJhbCBub3Rlcy4NCg0KMS4gUmV2aWV3aW5nIHRoaXMgdGlja2V0IG15IGltcHJl c3Npb24gaXMgdGhhdCB0aGUgb25seSBwcm9ibGVtIGlzIHRoYXQgLWggYWxzbyBhY2NlcHRzIGEg TERBUCBVUkkgYmVjYXVzZSAtSCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkLg0KSUlSQyAtaCB3YXMg b25seSBtZWFudCB0byB0YWtlIGFuIElQIGFkZHJlc3Mgb3IgaG9zdG5hbWUuDQpUaGVyZWZvcmUg SSdkIHN0cm9uZ2x5IHJlY29tbWVuZCB0byBzaW1wbHkgcmVqZWN0IGFuIExEQVAgVVJJIGZvciAt aC4NCklzIHRoYXQgeW91ciBnb2FsPw0KDQoyLiBUaGUgdGVybSAiRE5TIG5hbWUiIGlzIGEgYml0 IHRvbyBibHVycnkuIEluIGNhc2Ugb2Ygb3B0aW9uIC1oIGl0IHNob3VsZCBiZSBhbiBJUCBhZGRy ZXNzIG9yIF9ob3N0bmFtZV8uIEFuZCBhY2NvcmRpbmcgdG8gYmVzdCBwcmFjdGljZXMgaG9zdG5h bWVzIFNIT1VMRCBOT1QgY29udGFpbiB1bmRlcnNjb3Jlcy4NCldoZXRoZXIgeW91IF9hbGxvd18g dW5kZXJzY29yZXMgdG8gYWNjb21tb2RhdGUgc29tZSBzdHJhbmdlIHNldHVwcyBpcyB5b3VyIGRl Y2lzaW9uLg0KDQpDaWFvLCBNaWNoYWVsLg0K

1 0

Re: (ITS#8618) ldapsearch - unexpected behavior with
by michael＠stroeder.com 02 Mar '18

02 Mar '18

andrew.lawrence(a)siemens.com wrote: > I believe the following patch addresses this problem. I am still a > bit conf used about what constitutes a DNS name. Alex has suggested > they should contain an underscore. My colleague who reviewed the code > had a different opinion. Disclaimer: Since I'm not a C programmer I did not really review your patch in detail but just want to add some general notes. 1. Reviewing this ticket my impression is that the only problem is that -h also accepts a LDAP URI because -H should be used instead. IIRC -h was only meant to take an IP address or hostname. Therefore I'd strongly recommend to simply reject an LDAP URI for -h. Is that your goal? 2. The term "DNS name" is a bit too blurry. In case of option -h it should be an IP address or _hostname_. And according to best practices hostnames SHOULD NOT contain underscores. Whether you _allow_ underscores to accommodate some strange setups is your decision. Ciao, Michael.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs