10 command line tricks you didn't know about. Honestly.

1. A simple way to catch output and errors

Want to send stdout and stderr to one file?

command &> file

Maybe you understand a certain program with strace, and would like to see system calls along with program errors?

strace badapp &> errors_and_output

Pros : easy to remember, and easier than "Send errors to the output, and then all this to a file."
Compatibility : any Linux.

2. Parallelizing loops

Almost any administrator knows the power of cycles — how to do something for one, hundreds or thousands of users, files, machines, processes, or whatever. Most build loops sequentially, so that each task is completed before the next one starts. But you can send each task to the background, and not wait for its completion:

for HOST in $ (<ListOfHosts); do ssh $ HOST 'sudo apt-get update' & done

')
Maybe you need a bunch of ssh tunnels at the same time:

for HOST in $ (<ListOfHosts); do ssh -C -N -R 80: localhost: 80 $ HOST & done

Sometimes you do not want to see the output right away - in this case, save the log file on each machine, and then use another cycle to collect it.

Pros : saves metric tuyu hucha (⅔ imperial tuyev hucha) waiting time to complete.
Compatibility : any Linux.
Minuses : the bash should have restrictions on the number of simultaneous tasks, but so far the author ( and the translator ) has not rested against them.

3. Catching memory leaks through CZK

Memory leaks in Linux are infrequent, but they happen, especially with beta distributions or homemade software. It is often not so easy to identify a program with a leak. In Linux, there is an Out-Of-Memory program that allows you to find and kill such processes, but until it works, the system can already start to slow down a lot - so much so that you lose patience and reboot.

The usual way to know the memory consumption of a program is to run top (or its graphical equivalent, like System Monitor), and check the Resident Part Size (Res or RSS) of the processes of interest (you don’t need the memory allocated by the program — leaks come from use and not from assignments, and the program can allocate (allocate) a bunch of memory without harm to the system). Most citizens do not know that top can be run in batches, which means that you can use cron and top to create a simple report on the use of memory by the program:

run top
use the <and> buttons to sort the processes by RSS (size of the resident part)
press W to write the configuration to the file
add cron task:

crontab - <<< '* / 15 * * * * top -n 1 -b'

And every 15 minutes you will receive a letter with the withdrawal of the top.

Pros : how much easier it is to install software like SAR.
Compatibility : any Linux.
Cons : some restrictions on the number of simultaneous tasks.

4. stdin directly from the command line

Did not understand what was this garbage (<<<)? Bash allows you to send processes standard input directly from the command line.

Pros : allows you to write commands from the command line, even for alternatively friendly programs that require EVERYTHING from standard input. [Fists MySQL].
Compatibility : bash 3 and newer.
Cons : there are still a lot of systems with bash 2.

5. Set the primary password that needs to be changed.

Many organizations have good and strong password policies. Passwords are stored on Windows machines. Linux is either not covered by the policy, or the policy is not respected - people are not aware of authorization under Linux (most citizens do not understand PAM, and Linux administrators often do not realize that Linux can wonderfully authorize through Active Directory), and there was a time that the developers of OpenSSH did not like PAM (this has changed since then).

Set a password that should be changed at the first login:

umask u = rw, go =
openssl rand -base64 6 | tee -a PasswordFile | passwd –stdin joe
chage -d 0 joe

The password is saved in the PasswordFile file, which is available for even only under your account. After that, tell the initial password to the user via a secure channel, such as a phone or an encrypted letter (Translator had to encounter a system in which the initial password was sent via a regular email. The piquancy was that it was not Facebook or classmates. It was an online bank. )

Pros : users will not be with the initial password indefinitely.
Compatibility : any Linux with updated OpenSSH (if your users log in for the first time over SSH). RedHat claims that it still does not work in RHEL 3/4, but after applying their updates, everything is fine.
Cons : no.

6. Simple addition of a public key to a remote host.

For a login but a new host by key, you must first write the public part of the key to this host. Of course, this can be done manually, but soon it will bother you (and why ssh does not have authorized_keys.d ...), but there is a special utility for this:

ssh-copy-id -i .ssh / id_rsa.pub hostname

Enter the password one last time, ssh will say:

Now try logging into the machine, with “ssh 'hostname'”, and check in:

.ssh / authorized_keys

to make sure we haven't been expecting extra keys.

Try it. Goodbye passwords!

7. Unpacking RPM without additional software

On debian-like distributions, this is not a problem, because .deb files are simply .ar archives. Each RedHat tutorial mentions rpm2cpio (goes by default with rpm), but to be honest, I am not able to remember the cpio syntax, an antique format, now used only, mm, perhaps only rpm.

This command puts the package in a temporary directory, but does not change the RPM database (only in the temporary directory, which you will delete later). Since there is nothing else in it, we prohibit dependencies and scripts.

mkdir / tmp / deleteme

rpm -ivh –root / tmp / deleteme –nodeps –noscripts package.rpm

8. Has the file changed since delivery?

This is an easy way to find out if a file has changed from a package. First determine the package that includes the file:

dpkg -S /etc/foo/foo.conf

rpm -qf /etc/foo/foo.conf

Then, expand the original package with tar (DPKg) or the rpm trick above (RPM) and run:

diff /etc/foo/foo.conf /tmp/deleteme/etc/foo/foo.conf

And find the difference.

Pros : finding bad config files quickly (strace can be useful here too)
Compatibility : any Linux.
Cons : you have more time at work to read Digg.

9. - First of all, disconnect the connection ... Alo? Alo? idiots!

Poking around in the firewall remotely? Nervously somehow, right? Not that clicked, and the connection is lost.

Why not roll back the error? Charge the rollback of what you are going to change.

at now + 5 minutes <<< 'cp /etc/ssh/sshd_config.old / etc / ssh / sshd_config; service sshd restart '

If you make a mistake, the process will execute and restore the settings. And if you don’t make a mistake, run atq, and atrm <task number> to delete.

Pros : covers ass in case of error.
Compatibility : any Linux in which at is allowed, but it is usually yes.
Cons : remember that this must be done before risky action.

10. Is the port open

Want to check if the network service is running? Netcat with the -w option (how long to wait) will be useful:

nc -w 3 server ssh <<< ''

Connect to the ssh port on the host named server, wait 3 seconds before sending, mm, nothing, and close the connection. Whether the port has been opened will be reflected in the nc status.

if nc -w 3 localhost 22 <<< '' &> / dev / null
then
echo 'Port is open'
else
echo 'Port is closed'
fi

And here are some more bonus tricks ... (The translation will follow with good reviews on this part.)