Re: ldap search filter with OID matching rule not working
On Wed, Sep 20, 2023 at 12:01:13PM +, Andreas Menge wrote: > Hello, > > I???m trying to get some attributes from our AD ldap. Most stuff works fine, > but it seams that OID matching rules are not handled correctly. > > eg. this works: > > ldap search -D ???myuser" -W -H my_host_up -b "OU=User,DC=example,DC=de" > "(&(proxyaddresses=*)(useraccountcontrol=512))??? > > but using the match rule does not work: > > ldap search -D "myuser" -W -H my_host_up -b "OU=User,DC=example,DC=de" > "(&(proxyaddresses=*)(useraccountcontrol:1.2.840.113556.1.4.803:=2))??? > > I also tried to only get all deactivated accounts with this filter: > ???(useraccountcontrol:1.2.840.113556.1.4.803:=2)???. No results. No error > message. But running this filter on our LDAP server works as expected. > > Has anyone an idea what might be wrong? > > Could it be a bug in how ldap(1) handles these matching rules? ldap(1) doesn't support OIDs in filters.
Re: undocumented command switches -OR- fix documentation fully
In 5 years, the one true {,g,m}AWK is forked (again) as OpenAWK.. from
GNU awk(1). Undocumented switches are kept for BSD consistency (at
looks). We self-cope with BSD awk(1) in a number of miss-parsed
struggled diffs and give up. Nobody cares. GNU userland is
sup-positioning the BSD. We are one with the new kids. Old men are
no more.. reality check, awk(1) is not Xorg's XTerm, it can be upkept.
Why the undocumented switches are perceived as a failure in this
upkeep work reimport trim beginning, you tell.
On 9/20/23, Theo de Raadt wrote:
> I really don't give a shit.
awk-local(1)
> Eponymous Pseudonym wrote:
>> There is one (old man) in each of you, but "we" see the youth (in you)
>> forever.
Re: undocumented command switches -OR- fix documentation fully
I really don't give a shit. Eponymous Pseudonym wrote: > There is one (old man) in each of you, but "we" see the youth (in you) > forever. > > You know what this is addressing, it's not clouds, but system > conversion principles. Since it is your project, but NOT your system, > surprise me with a solution that I or a broader consensus would > propose, on the domain of: > > * Discrepancies between BSD and GNU and undocumented parts in the BSD > system from imported bulk of "non-OpenBSD" author-ware * > > A call like "get off the list" is fine too, but it's not solving the > problem that pokes your eyes too. Now, let me propose a goal that is > "admitting failure of upkeep in-house of important language utilities > integral to the core of UNIX". Separate it in ports and strip its > core to the system. Documentation is part of that, the split would be > worth it on parts of the system that are exercised a lot, this one is > considered moot? AWK as in the tool that compiler parsers peruse? > > You're _exactly_ interested in this, but it might be too late for this > kind of effort.. in OpenBSD in 2025. Is it too late and too thin of > an edge to walk on? > > awk-local(1) when? > > On 9/20/23, Theo de Raadt wrote: > > Old man yells at cloud. > > Yes.
Re: undocumented command switches -OR- fix documentation fully
There is one (old man) in each of you, but "we" see the youth (in you) forever. You know what this is addressing, it's not clouds, but system conversion principles. Since it is your project, but NOT your system, surprise me with a solution that I or a broader consensus would propose, on the domain of: * Discrepancies between BSD and GNU and undocumented parts in the BSD system from imported bulk of "non-OpenBSD" author-ware * A call like "get off the list" is fine too, but it's not solving the problem that pokes your eyes too. Now, let me propose a goal that is "admitting failure of upkeep in-house of important language utilities integral to the core of UNIX". Separate it in ports and strip its core to the system. Documentation is part of that, the split would be worth it on parts of the system that are exercised a lot, this one is considered moot? AWK as in the tool that compiler parsers peruse? You're _exactly_ interested in this, but it might be too late for this kind of effort.. in OpenBSD in 2025. Is it too late and too thin of an edge to walk on? awk-local(1) when? On 9/20/23, Theo de Raadt wrote: > Old man yells at cloud. Yes.
Re: undocumented command switches -OR- fix documentation fully
Old man yells at cloud.
Re: undocumented command switches -OR- fix documentation fully
> I'm aware that i'm replying to an obvious troll. You mean undocumented switches are abuse to the system operators. So, stop trolling and fix the documentation or remove undocumented switches. The sooner the better, man/doc support is your skill. Not smearing, work accordingly! > Just clarifying what's going on here for bystanders who might feel confused. You're not aware yourself, Ingo, as usual for you. Save yourself the postage fare of your volumEnous strives. Fix manual the page of awk(1) or remove long options for BSD and let it persist in ports and GNU utilities. You're thus mixing and mismatching and covering it up in docs. > CVSROOT:/cvs > Module name:src > Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12 > > Modified files: > usr.bin/awk: main.c > > Log message: > Support --version option like upstream awk but don't document it. > > Upstream awk has supported --version for a long time but does not > support -V like our awk does. Both options are supported by gawk. > This is perfectly in line with OpenBSD project goals. How do you know what this is, if you're speaking your own opinion. Coordinate somewhat? > Usually, we do not support long options at all because their "YOU" again > very existence violates POSIX and because, if a programs needs > more options than there are letters in the alphabet, that usually > means the program was seriously misdesigned. Overly opinionated, rejected. Long options is part of some reimplementation utilities like openrsync(1) etc, and POSIX is derived after BSD, which is dishonoured in GNU utilities and extended long options are brought with them which are UNDOCUMENTED HERE. WTF IS THIS! > In some cases, some long options that are synonymous with short > options are so widely used that supporting them *for compatibility > purposes only* makes the life easier for some people, for example > for our porting team. NO. Long options are used in scripts for declarative programming where your GNU info(1) documentation is inconveniencing you. > In those cases, supporting them without > cluttering up the documentation is a perfectly sane approach, in NO. Not EVER. Either in the program and documented or foregone. > particular when the option is as useless as -V in the first place. > Note that most OpenBSD programs, for good reasons, do not provide > an option to print any version number in the first place. It's not about versions, do not skew the topic of fixing undocumented switches. > In some rare cases, practical considerations make it seem worthwhile > to make an exception and provide a long option - usually popularized by > GNU in open defiance of POSIX - that does not have a short equivalent. > In such cases, we do usually document the long option. But that's not > the case here. TLDR; > None of these are hard rules, common sense and good judgement is > always needed, but i certainly agree with what Todd did in this case. Yes, you agree, I do not, and many would NOT. Now, this is MY $opinion. Your blind vote is always amazingly clueless at first draft. What are undocumented switches today? Tomorrow? In 25 years of back-porting monsters? > So everybody, please refrain from insulting Todd who is just doing > some good work here, for free, and for everybody's benefit. That's not the point, Ingo. Write me an autobiographic bug report on fixing the discrepancy, NO? 3-line diff or bust.
Re: undocumented command switches -OR- fix documentation fully
I'm aware that i'm replying to an obvious troll. Just clarifying what's going on here for bystanders who might feel confused. > CVSROOT:/cvs > Module name:src > Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12 > > Modified files: > usr.bin/awk: main.c > > Log message: > Support --version option like upstream awk but don't document it. > > Upstream awk has supported --version for a long time but does not > support -V like our awk does. Both options are supported by gawk. This is perfectly in line with OpenBSD project goals. Usually, we do not support long options at all because their very existence violates POSIX and because, if a programs needs more options than there are letters in the alphabet, that usually means the program was seriously misdesigned. In some cases, some long options that are synonymous with short options are so widely used that supporting them *for compatibility purposes only* makes the life easier for some people, for example for our porting team. In those cases, supporting them without cluttering up the documentation is a perfectly sane approach, in particular when the option is as useless as -V in the first place. Note that most OpenBSD programs, for good reasons, do not provide an option to print any version number in the first place. In some rare cases, practical considerations make it seem worthwhile to make an exception and provide a long option - usually popularized by GNU in open defiance of POSIX - that does not have a short equivalent. In such cases, we do usually document the long option. But that's not the case here. None of these are hard rules, common sense and good judgement is always needed, but i certainly agree with what Todd did in this case. So everybody, please refrain from insulting Todd who is just doing some good work here, for free, and for everybody's benefit. Now, let's please stop this thread and discuss something relevant. Yours, Ingo
undocumented command switches -OR- fix documentation fully
I don't know how you can tolerate this after all these years. >From one of the most important contributors to the project. In one of the most important system utilities and languages. IT IS DISGUSTING. FIX IT. ALL. Outcome like this: CVSROOT:/cvs Module name:src Changes by: mill...@cvs.openbsd.org 2023/09/20 10:57:12 Modified files: usr.bin/awk: main.c Log message: Support --version option like upstream awk but don't document it. Upstream awk has supported --version for a long time but does not support -V like our awk does. Both options are supported by gawk. (k)NOW! What are you doing here? Saving work or saving discrepancies with GNU? Why is this even a question? Do you NOT KNOW what to do here? FIX IT IMMEDIATELY.
ldap search filter with OID matching rule not working
Hello, I’m trying to get some attributes from our AD ldap. Most stuff works fine, but it seams that OID matching rules are not handled correctly. eg. this works: ldap search -D “myuser" -W -H my_host_up -b "OU=User,DC=example,DC=de" "(&(proxyaddresses=*)(useraccountcontrol=512))” but using the match rule does not work: ldap search -D "myuser" -W -H my_host_up -b "OU=User,DC=example,DC=de" "(&(proxyaddresses=*)(useraccountcontrol:1.2.840.113556.1.4.803:=2))” I also tried to only get all deactivated accounts with this filter: “(useraccountcontrol:1.2.840.113556.1.4.803:=2)”. No results. No error message. But running this filter on our LDAP server works as expected. Has anyone an idea what might be wrong? Could it be a bug in how ldap(1) handles these matching rules? -Andreas smime.p7s Description: S/MIME cryptographic signature
