4 ms·

I'm still on the platform side, out of K8s and the like - but this is so painfully true. They try to tailor a lot of these things to the OS/distribution, but f

I'm still on the platform side, out of K8s and the like - but this is so painfully true. They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways. A recent example: they're aware of RHEL. They're also aware of 'firewalld'. However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backend; iptables Meanwhile, using incredibly inefficient and 'portable' command lines. ie: using find in such a way that an LDAP query happens for every file Refusing to use the arguments available to the operating system they 'tailor' for. Ultimately timing out once you hold a certain number of files.

eddd-ddde 3y ago
I find interesting the last example with find and ldap queries. I'm not too familiar with ldap, but i do use find frequently. Could you expand on the example and what happens and why it's bad?
- bravetraveler 3y ago
  Certainly! In this case, they were interested in files that were too permissive. I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored. They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result to resolve UIDs and GIDs to names. They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls' Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out
  - eddd-ddde 3y ago
    Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!
    - bravetraveler 3y ago
      Best of luck to you! I've been around them for over a decade now, and still can't commit the various services to memory. I like to call what I do "taking the coward's way out" -- using FreeIPA My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments. I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)
  - res0nat0r 3y ago
    I think correctly configuring nscd should prevent this, ie it should cache some of these name lookups for a period of time. As long as it is properly setup for LDAP to hook into it. https://linux.die.net/man/8/nscd https://linux.die.net/man/8/nscd
    - bravetraveler 3y ago
      I suspect you're right, I'm not as familiar with our configuration (or the service) as I'd like to be The 'ls' output is honestly superfluous, though - 'find' will report the paths. I won't even get into how these are batched/time limited. If not this, it'd be something else eventually
  - TheNewsIsHere 3y ago
    Sounds like a spectacular self-DDoS on your LDAP infrastructure if that thing ever got deployed too widely and ran at the same time everywhere.
deleted 3y ago
[deleted]

eddd-ddde 3y ago

I find interesting the last example with find and ldap queries. I'm not too familiar with ldap, but i do use find frequently. Could you expand on the example and what happens and why it's bad?

bravetraveler 3y ago
Certainly! In this case, they were interested in files that were too permissive. I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored. They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result to resolve UIDs and GIDs to names. They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls' Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out
- eddd-ddde 3y ago
  Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!
  - bravetraveler 3y ago
    Best of luck to you! I've been around them for over a decade now, and still can't commit the various services to memory. I like to call what I do "taking the coward's way out" -- using FreeIPA My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments. I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)
- res0nat0r 3y ago
  I think correctly configuring nscd should prevent this, ie it should cache some of these name lookups for a period of time. As long as it is properly setup for LDAP to hook into it. https://linux.die.net/man/8/nscd https://linux.die.net/man/8/nscd
  - bravetraveler 3y ago
    I suspect you're right, I'm not as familiar with our configuration (or the service) as I'd like to be The 'ls' output is honestly superfluous, though - 'find' will report the paths. I won't even get into how these are batched/time limited. If not this, it'd be something else eventually
- TheNewsIsHere 3y ago
  Sounds like a spectacular self-DDoS on your LDAP infrastructure if that thing ever got deployed too widely and ran at the same time everywhere.

deleted 3y ago

[deleted]