Full_Name: Alexandre Rosenberg Version: 2.4.44 OS: Linux - CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.6.137) I found some unexpected behavior when using both '-h' and '-p' option with ldapserach. == Reproduce: - Use the '-h' option with an invalid hostname such as a URI - Also set a (valid) port using the '-p' option == Result: If those condition are met, ldapearch seem to always connect to localhost on port 389 $ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 == Expected behavior: Failure due to invalid hostname == Note: This *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine: $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine == Additional example: Bellow are some more example - note adding "/" to the hostname is enough to trigger the issue. 1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected) 2. $ ldapsearch -x -d 255 -h /example.org -p 10636 -> Connects to localhost on port 389 (!) - note the added "/" 3. $ ldapsearch -x -d 255 -h /example.org Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44.
moved from Incoming to Software Bugs
I believe the following patch addresses this problem. I am still a bit confused about what constitutes a DNS name. Alex has suggested they should contain an underscore. My colleague who reviewed the code had a different opinion. I am also not sure what to do about copyright headers and whether it is acceptable or not for me to add them into the files. From b3d02c8478edaa877b39f3d8824b54dc7b70146d Mon Sep 17 00:00:00 2001 From: Andrew Lawrence <andrew.lawrence@siemens.com> Date: Thu, 25 Jan 2018 22:15:14 +0000 Subject: [PATCH] Added host name validation Removed spurious include Fixed review comments Fixed additional review comments regarding errorcode and underscore --- clients/tools/common.c | 14 ++++++++++++-- include/ldap_pvt.h | 4 ++++ libraries/libldap/url.c | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/clients/tools/common.c b/clients/tools/common.c index 5eb41aa..821b006 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -5,6 +5,7 @@ * Copyright 1998-2017 The OpenLDAP Foundation. * Portions Copyright 2003 Kurt D. Zeilenga. * Portions Copyright 2003 IBM Corporation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -1242,7 +1243,16 @@ tool_conn_setup( int dont, void (*private_setup)( LDAP * ) ) int rc; if( ( ldaphost != NULL || ldapport ) && ( ldapuri == NULL ) ) { - /* construct URL */ + + rc = ldap_validate_hostname(ldaphost); + if (rc != LDAP_URL_SUCCESS) { + fprintf( stderr, + "Invalid host name %s\n", + ldaphost); + exit( EXIT_FAILURE ); + } + + /* construct URL */ LDAPURLDesc url; memset( &url, 0, sizeof(url)); @@ -1394,7 +1404,7 @@ dnssrv_free:; fprintf( stderr, "Could not create LDAP session handle for URI=%s (%d): %s\n", ldapuri, rc, ldap_err2string(rc) ); - exit( EXIT_FAILURE ); + exit( EXIT_FAILURE ); } if( private_setup ) private_setup( ld ); diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h index f1d93ac..6d1a6cb 100644 --- a/include/ldap_pvt.h +++ b/include/ldap_pvt.h @@ -2,6 +2,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -68,6 +69,9 @@ LDAP_F (int) ldap_url_parselist_ext LDAP_P(( const char *sep, unsigned flags )); +LDAP_F (int) ldap_validate_hostname LDAP_P(( + const char *hostname )); + LDAP_F (char *) ldap_url_list2urls LDAP_P(( struct ldap_url_desc *ludlist )); diff --git a/libraries/libldap/url.c b/libraries/libldap/url.c index b65e2b9..2702fec 100644 --- a/libraries/libldap/url.c +++ b/libraries/libldap/url.c @@ -3,6 +3,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,7 @@ #include <stdio.h> + #include <ac/stdlib.h> #include <ac/ctype.h> @@ -1325,6 +1327,36 @@ ldap_url_parselist_ext (LDAPURLDesc **ludlist, const char *url, const char *sep, } int +ldap_validate_hostname (const char *url) +{ + assert( url != NULL ); + + // Empty host names are invalid + if (strlen(url) == 0) { + return LDAP_URL_ERR_BADHOST; + } + + int prevalnum = 0; + int labelcount = 0; + int i; + + for (i=0; url[i] != '\0'; i++) { + if (!(isalnum(url[i]) || url[i] == '.' || url[i] == '-') || + (labelcount == 0 && url[i] == '.'&& !(i == 0 && url[i+1] == '\0')) || + i == 255 || labelcount == 63) { + // We have an invalid hostname. Fail. + return LDAP_URL_ERR_BADHOST; + } else if (url[i] == '.') { + labelcount = 0; + } else { + labelcount++; + } + } + + return LDAP_URL_SUCCESS; +} + +int ldap_url_parsehosts( LDAPURLDesc **ludlist, const char *hosts, -- libgit2 0.26.0 With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, Großbritannien und Nordirland mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00016033
andrew.lawrence@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.
Hi Michael, My goal was to only allow valid hostnames when using the -h option. A biproduct of this is that ldap uris are also rejected. The patch rejects hostnames with underscores as being invalid. I had heard several opinions when writing the patch and one of them was that Active Directory allows underscores in hostnames. Andy -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: 02 March 2018 18:48 To: Lawrence, Andy (MO MM R&D UK IXL); openldap-its@OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with andrew.lawrence@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.
andrew.lawrence@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/
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@stroeder.com wrote: > andrew.lawrence@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, . > > >
I followed the instructions to upload the patch (andrew-lawrence-180303.patch) to ftp://openldap.org/incoming/. I am not sure if it was successful as I cannot see the contents of the folder. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Siemens Rail Automation Holdings Limited. Siemens Rail Automation Holdings Limited has not assigned rights and/or interest in this work to any party. 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 modifications 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@OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with andrew.lawrence@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/
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.
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.patch) to ftp://openldap.org/incoming/. I am not sure if it was successful as I cannot see the contents of the folder. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Siemens Rail Automation Holdings Limited. Siemens Rail Automation Holdings Limited has not assigned rights and/or interest in this work to any party. 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 modifications 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@OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with andrew.lawrence@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/
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@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. > > >
@Alex The difference in behaviour is because it constructs a uri from the hostname 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
Andry, I am sorry but I still don't understand... - You are saying ldapsearch internally converts '-h' and '-p' parameters into a URI, correct ? - The '-p' option in ldapsearch is optional, if it's not set it should use the default LDAP port (TCP/389). In the example bellow, when I am calling ldapsearch without specifying the port (1), it does not say anything about the ldap URI being invalid. It simply tries to connect to '/example.org:389' and fails. (which is expected). On the other hand the same example with the option '-p 389' added, result in the query going to localhost (2). I don't understand why. The default LDAP port is TCP/389, therefore I would expect ldapsearch to behave in the same way regardless if the '-p 389' argument is provided or not. (1) $ ldapsearch -x -d 255 -h /example.org ldap_create ldap_url_parse_ext(ldap://% 2Fexample.org) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ld ap_int_open_connection ldap_connect_to_host: TCP /example.org:389 ldap_connect_to_ host: getaddrinfo failed: Name or service not known ldap_err2string ldap_sasl_bind (SIMPLE): Can't contact LDAP server (-1) (2) $ ldapsearch -x -d 255 -h /example.org -p 389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Best, Alex On Sat, 2018-03-03 at 16:24 +0000, andrew.lawrence@siemens.com wrote: > @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 > > >
Hi Alex, I was wrong. It is not the lack of port that causes it to fail. On the third line of the output below you can see the ldapsearch request without the port has tried to construct a uri by appending "ldap://" to another ldap uri. $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine If you also specify the port it does not try to append "ldap://" to the front of the hostname/uri. From an external point of view the behaviour is correct in that the command fails but the internal behaviour of the code is not as intended. Andy -----Original Message----- From: Alexandre Rosenberg [mailto:arekkusu@r42.ch] Sent: 04 March 2018 12:30 To: Lawrence, Andy (MO MM R&D UK IXL); openldap-its@OpenLDAP.org Subject: Re: (ITS#8618) ldapsearch - unexpected behavior with
Created attachment 657 [details] andrew-lawrence-2018-03-03.patch
For 2.5, remove -h and -p options finally?
https://git.openldap.org/openldap/openldap/-/merge_requests/175
Commits: • 66af4cfd by Quanah Gibson-Mount at 2020-10-01T21:27:59+00:00 ITS#8618 - Remove deprecated -h and -p options to client tools
A lot of admin people will now be forces to rewrite, test and debug their hard-worked and stable management/startup/monitoring scripts. Multiply this by N, because unforeseen corner cases always arise with time. Some times such changes must be conducted via external auditing/certification authority, that is a way costlier. And last, but not least, ... [-h] and [-p] are de-facto standard for ldap-tools. E.g., at the moment I use identical ldapsearch command line parameters on Linux and on Solaris, but since then I should learn, train and use two different ways, with unavoidable confusing from time to time. I think you might be mistaken with removing -h/-p. Why not to leave it as-is? It just works.
(In reply to Konstantin Andreev from comment #18) > A lot of admin people will now be forces to rewrite, test and debug their > hard-worked and stable management/startup/monitoring scripts. Multiply this > by N, because unforeseen corner cases always arise with time. > > Some times such changes must be conducted via external > auditing/certification authority, that is a way costlier. > > And last, but not least, ... [-h] and [-p] are de-facto standard for > ldap-tools. > > E.g., at the moment I use identical ldapsearch command line parameters on > Linux and on Solaris, but since then I should learn, train and use two > different ways, with unavoidable confusing from time to time. > > I think you might be mistaken with removing -h/-p. Why not to leave it > as-is? It just works. These options have been deprecated since 2000, so you've had literally 20 years to migrate away from them. "It just works" is incorrect, these options are inadequate for most modern use cases. E.g., they're insufficient for specifying ldaps or ldapi connections, while using -H with a URI handles all use cases.
(In reply to Howard Chu from comment #19) > > > > I think you might be mistaken with removing -h/-p. Why not to leave it > > as-is? It just works. > > These options have been deprecated since 2000, so you've had literally 20 > years to migrate away from them. "It just works" is incorrect, these options > are inadequate for most modern use cases. E.g., they're insufficient for > specifying ldaps or ldapi connections, while using -H with a URI handles all > use cases. You should ask instead: how many people do use them? It costs negligible to zero for you to just leave these features well enough alone, but it always costs money and efforts to migrate away. > These options have been deprecated since 2000, so you've had literally 20 > years to migrate away from them. If you are locked in OpenLDAP. But people use them because they are "lowest common denominator", supported by virtually any ldaptools suite. If you discard these options, you become (very?) special. The most balanced approach is to remove *being used* features only when they come into conflict with new features or enhancements. Not just because "there is another way". What is the advantage in removing -h/-p?
(In reply to Konstantin Andreev from comment #20) > The most balanced approach is to remove *being used* features only when they > come into conflict with new features or enhancements. Not just because > "there is another way". What is the advantage in removing -h/-p? It's quite poor etiquette to respond to a thread without reading it from the beginning. This ticket already makes the advantage clear.
(In reply to Howard Chu from comment #21) > > It's quite poor etiquette to respond to a thread without reading it from the > beginning. This ticket already makes the advantage clear. I certainly read the thread before responding. But I admit I should make this clear to facilitate the discussion. The only advantage I could assume from 2018-year thread is the ability to "Not to fix" the bug originally called [ldapsearch - unexpected behavior with "-h URI -p PORT"]. If this is what you mean as "advantage" then I could say that even simple WONTFIX would be better, because it, at least, does not harm current ldaptools users.
Just upgraded a server from Ubuntu 20.04 to 22.04, which contains 2.5.x and found out, that the options -p and -h got dropped - and requires me to adjust quite a bit of scripts because of this non-sense. This is such a poor software management and versioning, hard to believe, that anyone who allowed it to go through, has any experience in enterprise ready software. 1) If one decides to drop an option, it should be a) communicated clearly. b) documented and alternatives shown 2) If a software gets released, which has an incompatible change wrt. previous major.minor.tiny version, it should rise the major number of the software version, so that OS/Distro vendors are warned and may decide to stick with the old version. There are several options to allow -H and -h,-p side by side - openldap has chosen the worst option. This might be a hint, how poor its maintenance actually is/how bad the support by sysmas probably is. This is also a good example, that for OS/Distro vendors it is sometimes a really good thing to stick with the older version instead of switching to the "latest" stuff. Anyway, thanx for the work. =8-(
A reminder that the OpenLDAP Project is worked solely by volunteers. Symas does not direct the operation of the Project. They merely provide support for what the Project releases. Your criticism of Symas is wholly out of place. Meanwhile, criticizing work that was given to you for free, without you ever lifting a finger to contribute, just makes you a selfish, entitled, ungrateful ass. If you think you can run things better, then actively contribute. That is the only way that open source projects advance.
Also: the time to raise objections to a change is before the release. The 2.5 call for testing went out in April 2021. https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/thread/RO2W7RVTJOSABO2VNGWZPTGACEFZVAOM/ You're about 3 years late complaining about the removal of a feature deprecated 24 years ago. Demanding that volunteers work on what you want the way you want won't fly. Only people who are actively involved will have their concerns listened to.
(In reply to jel+git from comment #23) > 1) If one decides to drop an option, it should be > a) communicated clearly. > b) documented and alternatives shown Hello, The options were *clearly* marked as deprecated for the last 24 years in the man pages for the ldap client utilities. It appears whomever wrote the scripts in question chose to ignore this clearly documented deprecation of the options and used them anyway. Additionally, this was clearly documented in the UPGRADE section of the Admin guide. In other words, this change has been clearly communicated for years, and well documented. Perhaps in the future it would be wise to read the supplied upgrade documentation prior to performing an upgrade of software and to pay attention to deprecation notices in the software documentation instead of attacking a volunteer powered open source software project. Regards, Quanah
(In reply to Quanah Gibson-Mount from comment #26) > Additionally, this was clearly documented in the UPGRADE section of the Admin guide. Specifically, in the OpenLDAP 2.5 admin guide section on upgrading from OpenLDAP 2.4 or prior releases.
(In reply to Quanah Gibson-Mount from comment #27) > (In reply to Quanah Gibson-Mount from comment #26) > > Additionally, this was clearly documented in the UPGRADE section of the Admin guide. > > Specifically, in the OpenLDAP 2.5 admin guide section on upgrading from > OpenLDAP 2.4 or prior releases. https://www.openldap.org/doc/admin25/appendix-upgrading.html#Client%20utility%20changes