I like the idea to have commands and host groups connected, we can even show on the host group detail page table with all generated commands tied to the host group. But I don’t understand why every host group should have only one saved command. Why this limit?
Otherwise I agree with the proposed changes and ideas, good job!
The idea is the command generated by one user can be re-used by other users in same organization. If we have multiple commands saved for one hostgroup then how will a user differentiate between them? And how will other users know which command they should use if they want same configured registered host(s) like other users in that organization. Thus, by limiting the command count to one per hostgroup, it can be used by other users and if they think that the command should have different configuration then it should be modifiable by them which should be reflected to all users in that organization.
Well I thought that in the table we list all the parameters from the command
Thus, by limiting the command count to one per hostgroup, it can be used by other users and if they think that the command should have different configuration then it should be modifiable by them which should be reflected to all users in that organization.
Then I propose to have “Register host” button on the host group detail that would redirect user to the registration form with pre-filled fields from the host group.
Being honest here I found the idea of association between host group and RCs really confusing, I just don’t see any benefits or additional values there.
Instead of this users could easily go to the RCs index page and pick /filter the RCs there, no need to add more logic for the host groups.
What does “RCs” refer to?
We are not associating hostgroups and registration commands but only having hostgroup as index/primary-key to filter those commands. Something like:
New Registration
Hostgroup | Registration command
|
Centos | <generated command> Edit|Delete
Ubuntu | <generated command> Edit|Delete
Otherwise, how would a user pick/filter the commands? And how would they identify which command is for which configuration? A user themselves might identify but how other users in same organization who wants to use same configuration to register hosts would identify which configurations should be used?
Registration commands that can be stored to re-use later.
I would expect to have page Registration Commands where would be a search field and the table with commands and their parameters, something like this:
|RC|Host Group|OS|Param 2|param 3| param 4|Actions|
|generated rc ...|rc's HG|rc's OS|...|...|...|Edit/delete/copy
|generated rc ...|rc's HG|rc's OS|...|...|...|Edit/delete/copy
|generated rc ...|rc's HG|rc's OS|...|...|...|Edit/delete/copy
Basically same as every other index page with search bar in the Foreman.
I’m really strongly against the idea of one command per host group, I really don’t see the benefits there.
My suggestion is for now to focus on the other ideas we discussed before and leave this for later, maybe we can find another solution more suitable for this use
case.
Another idea to save the registration commands:
| Name | Description | Command | Actions |
| command name | give description about command | saved command| edit/delete/copy|
| command name | give description about command | saved command| edit/delete/copy|
We can have Save command button next to Generate Command button and when its clicked, have a pop up window to save it’s name and description about it like which settings, usage etc.
Please have a look at these 2 screenshots. This is, how I would simply improve the register host functionality:
Your thoughts?
Question to @lstejska (btw, did you see RFC : Host Registration Extension - #14 by Bernhard_Suttner)
If you set the “token expiry” to unlimited, the token is valid forever but its
Am I right?
I guess, a UI would be helpful to list/delete the tokens.
Analyzed the token generation today and found out, that there is no DB which stores the tokens as its using JWT and the Users.Secrect.
So, if you delete the jwt_secret from user, the tokens are invalid.
Idea: would it be better to generate the tokens from the foreman anonymous account and add a option, to reset the secret so that all tokens are invalid?
Hi @Bernhard_Suttner,
sorry for the late response, I’ve been busy with 3.5 stuff.
I like the idea of saving the “templates”, you are not the first one who came up with this idea, and seems to me that a lot of users would benefit from such a feature. So my thoughts about this are definitively positive, question is who’s going to do this, it’s not going to be a small feature to implement, but I’d be glad to help and give my insights
Just a few points from my side:
If you set the “token expiry” to unlimited, the token is valid forever but its
- not possible to view which token/entries exists
- not possible to delete old token/entries
Am I right?
Yes, you are right. It is a security issue however it’s not enabled by default, users have to select the unlimited option manually, therefore taking responsibility for the security.
Plus the scope of the token is limited to registration only, you can’t use it in other API endpoints.
Idea: would it be better to generate the tokens from the foreman anonymous account and add an option, to reset the secret so that all tokens are invalid?
Or we can new feature Invalidate JWT tokens where you can invalidate tokens for the specific user or all of them.
If you want we can schedule a meeting and discuss all the stuff and ideas, there is a lot of space for improvement and we could plan some organized effort to improve the registration feature.
For the whole organizations, so that they can be re-used by other users, too.
To invalidate a JWT token, it would be necessary to store the tokens itself - which would be somehow against the JWT idea.
Better would be to reset the JWT secret. Therefore, it should be another user, otherwise the user’s secret would be gone which is maybe used for other purposes, too.
Another possiblity would be, to add JWT secrets to a organization and the registration token are generated by the organization’s JWT token - currently not possible because only a user has a secret.
Yeah, sorry, by token I meant secret, you are right.
I found that in past I made some POC PR for the managing user’s JWT, maybe that could be useful.
Sounds interesting. What concerns did you have that it isn’t finished / merged to foreman? What is missing ?
Well it’s been a while since I pushed the PRs [0][1], but after quick look:
[0] [WIP] User JSON web tokens by stejskalleos · Pull Request #8525 · theforeman/foreman · GitHub
[1] [WIP] Fixes #32278 - Invalidate user's JWT by stejskalleos · Pull Request #8452 · theforeman/foreman · GitHub
[2] [WIP] User JSON web tokens by stejskalleos · Pull Request #8525 · theforeman/foreman · GitHub
Currently, the best way is to do User.find_by_login('admin').jwt_secret.destroy in a console, I guess it would be easy to add a button to the user edit page to do this. The new secret is generated in case it’s missing.
Sure, this would be possible but then other tokens which are used by the user are invalid, too.
Better would be:
Your thoughts?
I’m not sure if you mean one secret per org or the secret would be a combination of user’s and org’s secret. That way one could reset entire org or a specific user.
If this would be org level only, I’d say that could be quite open. I think it’s not an exception people use single org, while they have multiple AKs in it, each accessing a different content, which is potentially maintained by a different sysadmin. But I may be wrong.
I thought about storing a secret only on organization. Then, if sysadmin 1 leaves the company or is in vacation or sick, sysadmin 2 could reset the secret for the organization easily. Otherwise, there are maybe tokens available, which would allow to access the system.
