Score:-1

Server

"Remember" the CLI commands you ran for a server

J Fabian Meier

6/8/23, 8:37 AM

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?

0 + 0

command-line-interface

documentation

Gerald Schneider

6/8/23, 8:40 AM

That's what configuration management (like puppet) is for. If puppet is not suitable for you, try the alternatives.

J Fabian Meier

6/8/23, 9:11 AM

@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...

Gerald Schneider

6/8/23, 9:17 AM

`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.

J Fabian Meier

6/8/23, 10:14 AM

@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.

user9517

6/8/23, 11:40 AM

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.

J Fabian Meier

6/8/23, 12:07 PM

@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.

user9517

6/8/23, 2:10 PM

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.

Score:3

Server

AlexD

6/8/23, 11:19 AM

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

0 + 0

Bob

6/8/23, 12:48 PM

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?

AlexD

6/8/23, 1:03 PM

@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`).

Score:0

Server

Bob

6/8/23, 9:14 AM

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.

0 + 0

J Fabian Meier

6/8/23, 10:18 AM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: "Remember" the CLI commands you ran for a server

TH: "จดจำ" คำสั่ง CLI ที่คุณเรียกใช้สำหรับเซิร์ฟเวอร์

RO: „Amintiți-vă” comenzile CLI pe care le-ați executat pentru un server

RU: «Запомните» команды CLI, которые вы запускали для сервера

VI: "Ghi nhớ" các lệnh CLI bạn đã chạy cho máy chủ

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.