Implement a simple helper to search registered peers of a given user.

[jonasbardino]

Implement a simple helper to search registered peers of a given user to help site operators quickly detect issues with peer acceptance and End date.

[albu-diku]

This doesn't sit comfortably with me.

First, we've generally tried to make CLI tools have a formal main() method. Second, I believe a CLI tool should be introduced in line with our new conventions which, to my understanding would suggest it be placed into the sbin directory.

[jonasbardino]

Thanks for the input 👍
The reason for this is that it's a ~99% copy/paste of the existing searchusers.py script in the same folder. I made it based on an explicit discussion with our support team colleagues about their (lack of) access to search registered peers of an employee.
Note that I intentionally left it as a draft because I wanted to record that it is something we want but didn't have time to finish it.

I see two paths ahead:
a) we fast-track the inclusion and merge (or manually install) something they can use as-is
b) we postpone it until we have a style-compliant version with unit tests in line with the FHSesque layout .

I can live with either, but agree that the long-term goal is definitely (b). I think we have the concrete use-case solved so not sure how urgently a generally available solution is.

[albu-diku]

Hey - thanks for the response, and a 👍 wrt it being a draft.

Appreciate it's meant to immediately satisfy a requirement - given it's a pressing need and knowing that we're aware we'll need to revisit it I think moving forward likely makes sense. In this case it might even be better what's here isn't "pretending" to be a solution into the future and that clarity at the outset is helpful.

[jonasbardino]

I've completely reworked this PR to use FHSesque layout and added unit tests as we discussed above.
Only leaving the existing unit test suite style alone until we have merged the mechanics-only part of #481 to avoid conflicts.

[jonasbardino]

Migrated the script to bin/ where it belongs with reformat using the new make format-python on the test suite and script.

NB: operator scripts like this belong in bin whereas daemons use sbin.

We do not have main() methods wrapping the entire opt parsing anywhere else in bin and sbin AFAICT, so I've left it to a very thin __main__ basically just calling the unit tested search_peers function after parsing the options.

[Martin-Rehr]

Approved

[Martin-Rehr]

Did we ever decide if we should use -I or -i for CERT-DN in these scripts?

NOTE: searchusers is using -I createuser is using -i

[jonasbardino]

I don't think we did, but at least one external user requested consistency :-)
Not sure if there is anything preventing a change (apart maybe from the time required to update our own routines and docs accordingly). Otherwise no protests from me .

[jonasbardino]

These are the mixed uses I could find in script usage help:

mig/server/checkcloud.py:   -I CERT_DN          Check only for user with ID (distinguished name)
mig/server/checkpwpolicy.py:   -I CERT_DN          Check only for user with ID (distinguished name)
mig/server/checktwofactor.py:   -I CERT_DN          Check only for user with ID (distinguished name)
mig/server/createuser.py:   -i CERT_DN          Use CERT_DN as user ID despite what other fields suggest
mig/server/deleteuser.py:   -i CERT_DN          Use CERT_DN as user ID no matter what other fields suggest
mig/server/editgdpuser.py:   -i CERT_DN          CERT_DN of user to edit
mig/server/edituser.py:   -i CERT_DN          CERT_DN of user to edit
mig/server/managecloud.py:   -I CERT_DN          Limit to instances for user with ID (distinguished name)
mig/server/matchpeerusers.py:   -I CERT_DN          Limit to users matching CERT_DN (distinguished name)
mig/server/missingusers.py:   -I CERT_DN          Search for user ID (distinguished name)
mig/server/notifyexpire.py:   -I CERT_DN          Send warning for user(s) with ID (distinguished name)
mig/server/notifymigoid.py:   -I CERT_DN          Send intro for user with ID (distinguished name)
mig/server/notifypassword.py:   -I CERT_DN          Send reminder for user with ID (distinguished name)
mig/server/refreshusers.py:   -I CERT_DN          Filter to user(s) with ID (distinguished name)
mig/server/rejectuser.py:   -i CERT_DN          Use CERT_DN as user ID despite what other fields suggest
mig/server/reqacceptpeer.py:   -I CERT_DN          Forward peer request to user(s) with ID (distinguished name)
mig/server/reset2fakey.py:   -i CERT_DN          CERT_DN of user to edit
mig/server/searchusers.py:   -I CERT_DN          Search for user ID (distinguished name)
mig/server/verifyarchives.py:   -I CERT_DN          Filter to Archives of user ID (distinguished name pattern)

AFAICT there are no conflicts preventing us from picking one or the other consistently.
I don't really like the capital -I much, but can live with either. Any preference?