Cobbler #7496 ke

[keichwa]

see https://github.com/SUSE/spacewalk/issues/7496

[keichwa]

@SchoolGuy I'd appreciate if you would have the time to check this PR. Then it would be great if you'd read the complete modules/client-configuration/pages/cobbler.adoc file and edit/remove everything that's not supported on SUMA.

Thanks for your help!

[mcalmer]

Multi-site installation server configuration using the [command]``cobbler replicate`` command

This is not supported with SUSE Manager. We have tftpsync which is different.

[mcalmer]

[IMPORTANT]

Cobbler is not currently supported within {smr} environments. If you intend to use your installation with {smr} formulas, do not configure Cobbler.

I do not understand this. Cobbler is always automatically configured and you cannot run SUSE Manager without it. What does it has to do with "formulas"? Can we find out what we want to say with this note?

[mcalmer]

This section explains the Cobbler features most commonly used with {productname}:

If we explain some commands and functionality we should add cobbler sync. This command is triggered from SUSE Manager Server and generate the tftp boot environment on the server.

This is the main functionality of cobbler in combination with SUSE Manager.

[mcalmer]

Kickstart Templates

This explains variables and snippets with Kickstart Profiles. This is ok, but we should say somewhere prominent, that variables and snippets can also be used in "Autoyast Profiles".

[mcalmer]

Note: Building ISOs with Cobbler is not supported on {ibmz}.

I think also not on ppc64le ? But I am not sure if this can work or not.

[mcalmer]

Enable Bare Metal Systems Management ... The process can take a few minutes, and the system will automatically shut down once it is complete. After the reboot, the system will appear in the Systems list.

There is no "reboot". I would say:

The process can take a few minutes, and the system will automatically shut down once it is complete. The system should now be visible in the Systems List.

[SchoolGuy]

Also I would finally remove the commented out parts of the document. There are no plans or efforts to my knowledge to support them in the future. @keichwa

[keichwa]

@mcalmer and @SchoolGuy , thanks for all your feedback. I'll work on this now.

[keichwa]

Multi-site installation server configuration using the [command]cobbler replicatecommand

This is not supported with SUSE Manager. We have tftpsync which is different. I'll remove this item (later on, it was not explained, though ;)

[keichwa]

[IMPORTANT]
Cobbler is not currently supported within {smr} environments.
If you intend to use your installation with {smr} formulas, do not configure Cobbler.

I do not understand this. Cobbler is always automatically configured and you cannot run SUSE Manager without it. What does it has to do with "formulas"? Can we find out what we want to say with this note?

@aaannz , do you know why we have this admonition here? Maybe, we must re-phrase it somehow.

[aaannz]

Sure, this is to make sure that user will not run/enable cobbler managed tftp server. This limitation is currently only for branch proxy, but work is ongoing to enable terminal bootstrap directly from SUMA. Possibly in the 4.1 there will be this limitation even for SUMA for Retail or we'll need to figure out how can SMR and Cobbler run together - including other services like cobbler dhcp, etc.

EDIT: Ok, so the cobbler and dhcp is not an issue. So only tftp for pxe boot environment is.

[keichwa]

EDIT: Ok, so the cobbler and dhcp is not an issue. So only tftp for pxe boot environment is.

@aaannz Does this mean that we can delete the admonition about cobbler and SMR here completely and better a different warning about SMR and tftp for pxe boot somewhere else? Or shall we rephrase the existing warning here?

(BTW, @mcalmer asked initially.)

[keichwa]

Note: Building ISOs with Cobbler is not supported on {ibmz}.

I think also not on ppc64le ? But I am not sure if this can work or not.

@paususe I need your help please. Do we have to mention such a limitation here (assuming that it exists). Or is this something to add to the feature matrix?

[mcalmer]

Sure, this is to make sure that user will not run/enable cobbler managed tftp server. This limitation is currently only for branch proxy, but work is ongoing to enable terminal bootstrap directly from SUMA. Possibly in the 4.1 there will be this limitation even for SUMA for Retail or we'll need to figure out how can SMR and Cobbler run together ~- including other services like cobbler dhcp, etc~.

EDIT: Ok, so the cobbler and dhcp is not an issue. So only tftp for pxe boot environment is.

Currently it affect only Branch Server == Proxy. On a proxy we do not have cobbler, but you could do tftpsync. I think this is the part which would break things. (in 4.0). So we may write that you should not enable tftpsync to a Retail Branch Server.

@aaannz when you introduce limits on the server in 4.1 it will become a bit difficult. Cobbler is used via API and you cannot just disable it. It will crash the UI at places you never thought about. So cobbler will run and will create /srv/tftpboot/ . Reserve enough time to do the research how to make it work.

[keichwa]

I think a addressed all concerns. I just want to add more details on cobbler sync.

[SchoolGuy]

@keichwa How detailed do you need the docs? I will accordingly create upstream docs and then you can take from there what you need!

[keichwa]

"Enno G." notifications@github.com writes:

@keichwa How detailed do you need the docs?

What we now have is probably detailed enough. I'm sure Lana will help with faceliftig when we stop adding fixes.

The only thing that's missing is a description what exactly happens when the user runs "cobbler sync" on a SUMA default installation. If you could provide this it would help a lot.

Some weeks ago, you provided this listing:

A sync is basically a rebuild of every file cobbler touched.

1. Run Pre-Sync-Triggers (this can be any number of shell scripts to my knowledge)
2. Delete all files and directories which are not allowed in /var/www/cobbler
3. Create all needed folders
4. Delete all elements inside the folders.
5. Generate the tftpd directory
6. Write the DHCP files (if management is enabled)
7. Do the same with DNS
8. Clean the Cache
9. If rsync management is enabled do that
10. Run Post-Sync-Triggers (this can also be any number of shell scripts to my knowledge)

I'm especially wondering whether all these steps are valid in our context?

-- Karl Eichwalder SUSE Software Solutions Germany GmbH PES / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany Geschäftsführer: Felix Imendörffer (HRB 36809, AG Nürnberg)

[SchoolGuy]

@keichwa Yes they are. SUMA does just nothing more then triggering a cobbler sync.

Just to mention it: There is also a lite sync. This sync works similar but only touches files and directories which are related to the change which triggered it. SUMA also adds/removes and edits systems which are in cobbler and thus triggers such lite-syncs.

[keichwa]

Now I please want some final approvals. Then I'll push it to the uyuni-docs repo (assuming that that's the thing to do).

[keichwa]

closing here. we now have the same PR (squashed) in uyuni-project.