Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is there a way to record the Linux commands I use and reuse them on another machine or in case I want to reinstall the machine?

In example record how I set up NginX, PHP and permissions in my lab environment and then repeat the exact commands on my deploy machine?

share|improve this question
add comment

6 Answers 6

up vote 15 down vote accepted

Seems to me like you want script(1).

It allows you to record and replay terminal sessions.

On the other hand, if you are trying to automate setups, consider configuration management, like puppet.

share|improve this answer
    
Thanks for Puppet, it looks good. I will read more about it. –  Jonas Mar 6 '10 at 17:24
1  
+1 for Puppet. This is a much better way to go than simply recording shell commands. –  EEAA Mar 6 '10 at 18:22
    
+1. cfengine is a competitor to Puppet, also –  gWaldo Sep 7 '10 at 16:49
add comment

Two ways I can think of off the top of my head:

  • Use the builtin command history

  • Do everything in a screen session and enable logging

share|improve this answer
add comment

Bash records commands in a file called ~/.bash_history. This works if you do everything via a command line, and in one command window.

Be warned though, it limits the size of that file to the most recent 1000(by default) commands.

share|improve this answer
add comment

try this out

script /tmp/it356658-$(uname -n).out

# date

share|improve this answer
    
He is directing script's output to a particular file. The naming is unusual, but likely extracted from a larger shell script perhaps. –  mctylr Mar 6 '10 at 19:01
1  
The $(uname -n) is interpreted by the command line to run the uname command with the -n flag to print out the system's hostname. –  mctylr Mar 6 '10 at 19:02
    
Thanks for a good explanation. I seems useful. –  Jonas Mar 6 '10 at 19:29
add comment

I think you could also use autoexpect for this task.

share|improve this answer
    
I got "command not found" in Ubuntu when I tried it. –  Jonas Mar 6 '10 at 18:29
1  
I think it would be part of the Expect package which may not installed by default. Ref: linuxjournal.com/article/3065 –  mctylr Mar 6 '10 at 18:59
    
Thanks again for a good link. –  Jonas Mar 6 '10 at 19:30
add comment

Normally I use a command like history > ~/tmp/hh to save a history file. Then I use vi, jump to the bottom with the G command and then search upwards until I find the part that would be near a useful entry point into a script. From there I collapse out extraneous ls commands, combine series of incremental cd into directories, add comments, and start figuring out which parts need to be arguments, which things might have to be environment settings and which things have to be hard-coded. I add lots of comments. Sometimes I "punt" on parts of automating it and just give the user some instructions (go find this setting, ssh to foo and ..., uncomment blah from this file and move it to blarg) or echo a URL ... and a prompt string like: 'Configured Foo and exit >'

(When you punt on an automated file edit ... I suggest appending the instructive code to the file, as a comment, and use something like the vi + command line switch to put the editor's cursor near the bottom of the file, at the top of your instructions. For example with 5 lines of instructive text (a here doc for example) you'd add '+$-5' to the vi command line, before the filename. ($-5 is an old ex incantation to address the last line of the file, minus five lines; the relatively obscure + switch to vi accepts any ex ... : command ... as an argument).

Another trick ... assuming you do most of your work from a X Windowing System terminal (xterm, konsole, gnome-terminal, etc) then keep a browser open on some wiki pages as you go. Cut and past commands, output, snippets of text files and jot down notes as you go. (This mostly assumes you're mostly working on your servers over ssh from your workstation, desktop, laptop, or whatever).

Save early and often.

Create new wiki pages for different processes or stages. Then link them together and link out to any references out on the 'net. (You know, all those Google pages you used every time you got stuck at any point).

Some of my best HOWTO documents have been created this way.

If you do it right then you might be able to get the job off your plate the old-fashioned way, by delegating to the junior team member ... or the eager intern. :)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.