RFC : Host Registration Extension

MSinghal · February 17, 2022, 2:17pm

Hello,

Host registration page already works great but it can be extended with following ideas to make it more user friendly.

Saving the host registration parameters without tokens to re-use:

Useful when one has multiple hosts to register with same configuration
Multiple users in an organization wants to register hosts with same configuration

Minimize the options selection by auto-filling them from hostgroup like, OS, Activation key etc.
Adding an option to also select the http-proxy.

lstejska · February 21, 2022, 2:40pm

Hi,
I like the ideas, just have some comments and questions.

Saving the host registration parameters without tokens to re-use

Do you want to save every generated command automatically or only if user specifically say that they want to save it?
Will this be shareable between users or it will be tied to user that created it?
Do we want to have it as special page where users can list all generated commands or it will be under the registration form?
How about cleanup of old data? Would it be automatically or have to be done manually by user?

Minimize the options selection by auto-filling them from hostgroup like, OS, Activation key etc.

This is already (partially) happening. Following fields are inherited from the host group (with Katello): Operating System, Setup Rex, Setup Insights, Install packages, Activation keys and Life Cycle Environments.

Fields that are not inherited, but should be, are: Update packages, REX interface. Probably also the repository fields but I’m not sure about those two.

Adding an option to also select the http-proxy.

I don’t have much experience with HTTP(S) proxies in Foreman, but from the documentation [0] it looks like they are for the Compute Resources mainly, I don’t see the use case here for the registration. But feel free to correct me, I might be wrong here.

[0] Foreman :: Manual

MSinghal · February 25, 2022, 8:51am

1.   Saving the host registration parameters without tokens to re-use.

We generate command per hostgroup and shareable within the organization by adding a save button next to generate button. Which means users in same organization can view, edit, delete the command. And it should be possible to re-write it by all users and when they want to use the command, they simply view/edit it, generate the token, make edits if they want to and generate the command.

2. Minimize the options selection by auto-filling them from hostgroup like, OS, Activation key etc.

Yeah, the main fields were OS, activation keys, rex setup, LCE so this should be fine.

3. Adding an option to also select the http-proxy.

Some hosts are not directly reachable by Foreman and therefore, they need http-proxy to connect. Having an option to select http-proxy will solve the issue where such hosts needs to be registered.

lstejska · March 21, 2022, 1:52pm

Sorry for late response, have some other comments:

We generate command per hostgroup and shareable within the organization by adding a save button next to generate button.

I don’t understand the We generate command per host group. Could you please explain how it will work?

Which means users in same organization can view, edit, delete the command.

The edit part will be done how? Is it going to be same form as the one for creating the command or is it going to be new form?
Where do you want to list the created commands, is it going to be a new page?

Some hosts are not directly reachable by Foreman and therefore, they need http-proxy to connect. Having an option to select http-proxy will solve the issue where such hosts needs to be registered.

How this will work with the current smart proxy field? Do we want to list Smart Proxies and HTTP proxies together or is it going to be two different fields?
I think it’s a good idea, but we need to check that only smart proxy OR http proxy can be selected, not both

MSinghal · March 22, 2022, 6:02am

There should be a page which lists all the generated commands and these commands are for each hostgroup, So one hostgroup can have only one generated command saved for it and visible on that list. It should be very similar to hosts/content hosts page but instead of hosts list it will have 2+ columns, one column for hostgroup (unique) and other should have generated command.

For the edit part, it should be same form as create one but autofill the values similar to what we have with other components where you simply edit the existing form and has values filled.

The created commands should be in new page where we can list them, on top right we can have option to create new command, and on each row have an option to edit or delete those saved commands.

We can have two fields and if one is selected then other should be disabled with warning/notice that other field is filled. Or we can have radio button to select Smart proxy or HTTP proxy and based on the selection have a drop down menu.

lstejska · March 22, 2022, 12:58pm

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!

MSinghal · March 23, 2022, 6:09am

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.

lstejska · March 23, 2022, 9:30am

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.

quba42 · March 23, 2022, 9:34am

What does “RCs” refer to?

MSinghal · March 23, 2022, 10:23am

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?

MSinghal · March 23, 2022, 10:24am

Registration commands that can be stored to re-use later.

lstejska · March 28, 2022, 6:29am

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.

MSinghal · April 11, 2022, 5:12am

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.

Bernhard_Suttner · October 21, 2022, 1:21pm

Please have a look at these 2 screenshots. This is, how I would simply improve the register host functionality:

its possible to store the registration parameters in a extra db table called “register_host_templates”.
on the new tab “templates”, templates are shown
if you scroll over the template, it will show its configuration like “Organization: ÄTIX, Host Group: …”
you can select a template, and then generate the register host curl again which will create a new token.
its possible to delete an entry

Your thoughts?

Bernhard_Suttner · October 27, 2022, 10:20am

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

not possible to view which token/entries exists
not possible to delete old torken/entries

Am I right?

I guess, a UI would be helpful to list/delete the tokens.

Bernhard_Suttner · October 28, 2022, 4:59pm

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?

lstejska · October 31, 2022, 12:50pm

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:

Naming it templates might not be the best idea, it can confuse users with (provisioning) templates that we used for the registration and host initial configuration. Something like registration parameters would be more suitable IMHO.
Saved entries would be saved per user or the whole organization?

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.

Bernhard_Suttner · October 31, 2022, 3:54pm

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.

lstejska · November 2, 2022, 11:13am

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.

Bernhard_Suttner · November 8, 2022, 4:15pm

Sounds interesting. What concerns did you have that it isn’t finished / merged to foreman? What is missing ?