-1

Assume you have a third party program running on a server.

To configure it, you log in, apply some CLI commands and leave again.

Every time you do this, you also copy and paste the commands to some file in your git, so that in the future, you can figure out what was configured and you are also able to configure the server again if you ever need to.

This is prone to error.

I know that people invented things like Puppet to avoid this problem, but AFAIK Puppet relies on modules with which you can define state and then does idempotent operations. This means that you do not have a Puppet module for everything and that the modules you have might not be able to do all the configuration you want.

So after this long story:

Is there a proper way to "record" the commands you ran, so that you can run them and also document the run at the same time?

J Fabian Meier
  • 101
  • 4
  • 1
    That's what configuration management (like puppet) is for. If puppet is not suitable for you, try the alternatives. – Gerald Schneider Feb 08 '22 at 08:40
  • @GeraldSchneider But doesn't that require that the vendor or at least the community provides a module for this program? Furthermore, it probably also means that you cannot just run the commands from the manual, but need to find out how the configuration works in the Puppet, Ansible, Chef, whatever module... – J Fabian Meier Feb 08 '22 at 09:11
  • 2
    `But doesn't that require that the vendor or at least the community provides a module for this program?` - Not really. They all provide a method to run arbitrary commands. You only need to build your recipe, playbook, whatever they call it. You may even realize that some modules make tasks easier than piping 5 tools until you get a result. – Gerald Schneider Feb 08 '22 at 09:17
  • @GeraldSchneider But, AFAIK, don't these playbooks rely on the idea that everything is idempotent and can be run again every time? This is generally hard to achieve. – J Fabian Meier Feb 08 '22 at 10:14
  • The world of server management has moved on. If you are configuring a server, use the configuration management tools available, you know it makes sense. – user9517 Feb 08 '22 at 11:40
  • @user9517 Actually, many server based programs still use the GUI as standard tool to configure them. I am already happy to be able to do everything on command line. So while I think you are right regarding common platforms like e.g. JBoss server, it is different for other tools. – J Fabian Meier Feb 08 '22 at 12:07
  • And those 'gui' tools will store their configuration in a file somewhere that can be managed by a configuration management tool. I don't think you do any real server management either. – user9517 Feb 08 '22 at 14:10

2 Answers2

3

If you want to do it the old way, you can use script(1) to record your session.

AlexD
  • 8,179
  • 2
  • 28
  • 38
  • Now that is old-school. Just out of curiosity, what happens when you use `sudo -i` or `sudo su -`, is what happens with elevated privileges also recorded? – Bob Feb 08 '22 at 12:48
  • @Bob, yes, it will record everything, including privileged sub-shells with `sudo`/`su` and even interactive programs like `vi`. But with interactive programs, the script output will be mostly unreadable so you'll need to use `scriptreplay` (which requires timing being recorded by `script`). – AlexD Feb 08 '22 at 13:03
0

The problem that you describe is exactly why people at some point decide that they no longer want to rely on manual commands and administrators using interactive (GUI) tools.

You want to be able to repeat what you did in an more structured way than following a checklist that may not have been updated after the latest release/change/crisis.

And although that appears a simple problem and the first approach of a long list of all the commands that were issued to achieve the current state seems a good idea you probably realize after giving it some thought, that such a list not the best solution either. That list probably also contains also steps like, try, error, fail, revert and try something else, typo, repeat again etc. that you don’t necessarily want or need to repeat..

Wikipedia provides a nice summary of several tools people created to solve that: https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software

Those all have a learning curve and seem more complicated than what you think you need, but trust me, invest some time and effort and you see why many of those are widely used to solve the kind of problem you’re now facing.

Bob
  • 5,335
  • 5
  • 24
  • I actually just want the long list of commands. These are the things documented in the manual. Writing a playbook, recipe whatever means that I add an extra layer of complexity: I probably cannot just run commands from the manual because they may not be idempotent, instead I have to either rely on community playbooks (which I may or may not trust to do the right thing) or write some stuff myself. – J Fabian Meier Feb 08 '22 at 10:18