How to access outside the chrooted directory

Symbolic links do not work when pointing outside the default root (chrooted location) directory. To get around this limitation, it is possible to remount directories into chrooted location. One can
also remount a single file (on a single file).

as of the 2.4.0 kernel:
# mount --bind olddir newdir

also putting this line into /etc/fstab makes it permanent.
/my/old/dir /my/new/dir none bind 0 0

Recursively copy

Recursively copy a directory into another place with preserving mode, ownership and timestamps and redirect the names of erroneous ones into a file(copy_error.txt).

# cp -R --preserve /old_dir/* /new_dir/ >& copy_error.txt

passwordless ssh

on the first and second server:

test ~# mkdir ~/.ssh
test ~# chmod 755 ~/.ssh
test ~# /usr/bin/ssh-keygen -t rsa
test ~# /usr/bin/ssh-keygen -t dsa
test ~# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
test ~# cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

on the first server:

test ~# ssh test@server2 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
test ~# ssh test@server2 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
test ~# chmod 644 ~/.ssh/authorized_keys

on the second server:

test ~# ssh test@server1 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
test ~# ssh test@server1 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
test ~# chmod 644 ~/.ssh/authorized_keys

verification:

on the first server:
test ~# ssh test@server2 ls -al

on the second server:
test ~# ssh test@server1 ls -al

Installing rpm packages with "yum localinstall"

If rpm packages are installed via "yum localinstall", then dependent packages are also installed automatically. For instance:

# yum localinstall truecrypt-5.1-1.i386.rpm -y

This command tries to install truecrypt, but this rpm needs some others. Then, yum will find and install these dependent rpm's for you silently.

Converting a .p7b signed cert to .pem

openssl pkcs7 -inform DER -in server-cert.p7b
 -print_certs -text -out /etc/apache2/ssl.crt/server.crt

Getting all installed rpm packages sorted by size

rpm -qa --queryformat '%{SIZE} %{NAME}\n'| sort -r -n

Logging commands executed by ssh

If you're using bash you can add these lines to your .bashrc file.

if [ -n "$SSH_CONNECTION" ]; then
       LOG=$HOME/log
       date >> $LOG
       echo $SSH_CONNECTION >> $LOG
       echo $BASH_EXECUTION_STRING >> $LOG
fi

X11 connection rejected because of wrong authentication

ssh says "X11 connection uses different authentication protocol". Check you have TCP enabled (i.e. no -nolisten tcp option) for your X server and try using a tunnel. E.g.

yourhost$ xhost + localhost
yourhost$ ssh -R 6007:localhost:6000 strangehost
strangehost$ env DISPLAY=localhost:7.0 xclock

Using x2x with ssh

To use host1 mouse and keyboard on host2 type:

host1:~> ssh host2 'x2x -from $DISPLAY -to :0 -east'

You can use -west instead of -east, or swap -from with -to parameters to use host2 mouse and keyboard.

File Tips and Tricks

Truncate the contents of a file:

> file/to/truncate

Eliminate "reserve space" from non-root (/) partitions, freeing for other uses:

> tune2fs -r 0 /dev/sda4

Email Tips and Tricks

Send an email:

/usr/bin/echo "message here" | /usr/bin/mailx -s "Subject Here" recipient-email@example.com

Send a file by email:

/usr/bin/echo "see attachment" | /usr/bin/mailx -s "I'm sending a file" -a /file/to/send recipient-email@example.com

CD Burning Tips and Tricks

Create an ISO:

/usr/bin/mkisofs -r -x -o file.iso /files/to/image

Create an ISO Preserving Ownership and ACL and Excluding a directory:

/usr/bin/mkisofs -R -x /files/to/image/dir/to/exclude -o file.iso /files/to/image

Burn an ISO to CD:

/usr/bin/cdrecord dev=0,0,0 speed=4 -data file.iso

Burn an ISO to DVD:

/usr/bin/dvdrecord dev=0,1,0 -dao file.iso

or

growisofs -speed=4 -Z /dev/dvd=/home/nfs/backups/root.iso

Erase a CD-RW:

/usr/bin/cdrecord dev=0,0,0 speed=4 blank=all

Rip a CD as an ISO:

/bin/dd if=/dev/cdrom of=file.iso

IO Redirection

UNIX had the concept of IO redirection long before DOS copied and bastardised the concept. The UNIX IO redirection concept is fundamental to many of the things that you can do with UNIX, and it is quite a well-developed idea, so we will explore this concept here.

Why do I mention UNIX at all? Well, Linux is a UNIX operating system!

Under UNIX, all programs that run are given three open files when they are started by a shell:

0.	Standard in, or STDIN. This is where input comes from, and it normally points at your terminal device. To find out what device is your terminal, use the tty(1) command. Note, the (1) after command names in UNIX refers to the section of the man pages that the documentation for the command exists in. You can arrange to run any command and pass it input from a file in the following way: $ some-command < /path/to/some/file Note, the '$' is your prompt. Note also, you can always specify a complete path name for a file. For example: $ grep -i Fred < /etc/passwd Would search for the string 'fred' in /etc/passwd, regardless of the case of the characters. But wait a minute, you object, I always use: $ grep -i Fred /etc/passwd This is true, but you can also pass the file in on STDIN, and you will get different results if you do. Can you see what the difference is?
1.	Standard out, or STDOUT. This is where the normal output from a program goes. It normally points at your terminal as well, but you can redirect it. You can redirect output in the following way: $ some-program > /path/to/some/file For example: $ grep -i Fred /etc/passwd > /tmp/results
2.	Standard error, or STDERR. This is where error output from your program goes. This normally points at your terminal as well, but you can redirect it. Why have different output places for standard out and standard error? Well, as you will see when you come to writing shell scripts, you often do not want error messages cluttering up the normal output from a program.

You will forgive me for starting the above list at 0, I am sure, when you learn that each of these IO 'channels' are represented by small numbers, called file descripters (FDs), that have exactly those numbers. That is, STDIN is FD 0, while STDOUT is FD 1, and STDERR is FD 2.

When the shell runs a program for you, it opens STDIN as FD 0, STDOUT as FD 1, and STDERR as FD 2, and then runs the program (technically, it almost always does a fork(2) and then an exec(3) or one of the exec?? calls). If you have redirected one of STDIN, STDOUT or STDERR, your shell opens that file as the appropriate FD before running the program.

Now, what does this all have to do with you, I hear you ask?

Well, there are lots of neat things you can do, but some things to watch out for as well.

A lot of inexperienced UNIX users assume that they can redirect a file into a program and use the same name for redirecting the output:

$ some-program <> mega-important-data-file

They become very upset after doing the above, especially if that mega-important data file has never been backed up anywhere. Why is this?

The shell opens the mega-important-data-file for reading and associates it with FD 0 (or STDIN), and then opens it for writing, but truncates it to zero length, and associates it with FD 1 (or STDOUT) as well.

So, if you want to do something like the above, use a different file name for the output file. Oh, you should also back up files as well :-).

Now, there are lots of redirection symbols that you can use, and here are some of them:

< file	means open a file for reading and associate with STDIN.
<< token	Means use the current input stream as STDIN for the program until token is seen. We will ignore this one until we get to scripting.
> file	means open a file for writing and truncate it and associate it with STDOUT.
>> file	means open a file for writing and seek to the end and associate it with STDOUT. This is how you append to a file using a redirect.
n>&m	means redirect FD n to the same places as FD m. Eg, 2>&1 means send STDERR to the same place that STDOUT is going to.

OK, here are some tricks that you might want to use in various places.

If you are gathering evidence for a bug report, you might want to redirect the output from a series of programs to a text file (never mind that you can use the script command to do the same :-). So you might do the following:

$ some-buggy-program > important-evidence.txt
$ echo '---------MARKER-------' >> important-evidence.txt
$ some-buggy-program some-params >> important-evidence.txt

The second and subsequent lines append the output from the commands issues to the evidence file rather than overwriting them. Try the following:

$ echo This is a line of text > /tmp/file.txt
$ echo This is another line   > /tmp/file.txt

What do you get?

Now try:

$ echo This is a line of text > /tmp/file.txt
$ echo This is another line   >> /tmp/file.txt

What do you get this time?

OK, for the last few tricks here. Sometimes you want to append STDOUT and STDERR to a file. How do you do it?

$ some-command >> /tmp/log.log 2>&1

The 2>&1 says make STDERR point to the same places as STDOUT. Since STDOUT is open already, and the shell has done a seek to the end, STDERR will also be appended to STDOUT.

If you want to append a line to a file, you can echo the line you want with a redirect, rather than firing up an editor:

$ echo Some text >> /path/to/some/file

It turns out that you can cause the shell to redirect to other file descriptors as well, and if you look in the configure scripts that come with many UNIX software packages, you will see examples of this.

Why is redirecting so important? Well, it is used in many shell scripts, it is a simple and conventient mechanism to sending output to any file without the programmer having to add code for handling command line instructions, and it is the UNIX way of doing things :-).

It is also the same as piping, where you redirect output to, or input from, a pipe device. The pipe device has a process living on the other side, but we will look at this later.

Using Proc

In /proc, there are subdirectories for each process running on the system, named based on the PID number of the process. In each of these directories, there is a fd/ subdirectory that contains files that represent the file descriptors the process currently has open. These files are actually symlinks that point to the actual device, socket, or other file the process currently has open and mapped to that file descriptor.

If you have a program that can read input from a file but not from standard input, or that can write to a file but not to standard output, you may be able to cheat by taking advantage of these special files:

/proc/self/fd/0 is standard input of the current process
/proc/self/fd/1 is standard output of the current process
/proc/self/fd/2 is standard error of the current process

For example if 'myfilter' can only read from a file, which it takes as its first argument, you can make it read from standard input instead with:

'myfilter /proc/self/fd/0'

Another example: 'cat filename > /proc/self/fd/2' sends the contents of filename out standard
error instead of standard output. Whether these tricks will behave in a sane manner will depend on how the process actually handles the file it opens.

USB when the Drivers Aren't Available

As a way to save a few valuable pennies on newer PCs, manufacturers are increasingly getting rid of the good old PS/2 keyboard and mouse interfaces. As a result, some recent systems only ship with USB ports to which we need to connect a USB keyboard and mouse.

USB is all well and good, but what if the driver for your USB controller is not loaded? In practice, this is not a problem, as Red Hat loads the ehci- hcd and uhci-hcd drivers automatically at boot time. There are situations, namely in emergency mode, where the USB drivers won't be available. So you won't even be able to enter a command. This is due to the fact that in emergency mode all drivers need to be provided in the initrd file under /boot, and USB is not there by default. The trick is to add those drivers, so that they will be available earlier. The 'mkinitrd' command can do precisely that with the '--with' argument (this only works under RHEL4):

mkinitrd --with=ehci-hcd --with=uhci-hcd /boot/newinitrd-`uname -r`.img `uname -r`

Add a new entry in your grub.conf file (always do backups!) that points to this new initrd image, and you're done! Your USB keyboard now works in emergency mode.

How To Determine the Manufacturer of a Laptop Battery

With all the recent news about laptop batteries suddenly exploding, it might be a good idea to determine the manufacturer and model number of the battery that’s currently connected to your laptop. A simple file, included with the 2.6 kernel that runs on Red Hat Enterprise Linux 4, can easily show this information on any laptop running with ACPI enabled:

cat /proc/acpi/battery/BAT0/info

Look for the “model number” and “OEM info” fields.

Wiping a Hard Drive

Have you ever needed to completely wipe out critical data from a hard drive? As we all know, mkfs doesn’t erase a lot. (You already knew this, right?) mkfs and its variants (e.g., mkfs.ext3 and mke2fs) only get rid of a few important data structures on the filesystem, but the data is still there! For a SCSI disk connected as /dev/sdb, a quick

dd if=/dev/sdb | strings

will let anyone recover text data from a supposedly erased hard drive. Binary data is more complicated to retrieve, but the same basic principle applies: the data was not completely erased. To make things harder for the bad guys, an old trick was to use the ‘dd’ command as a way to erase a drive.
Note: This command will erase your disk!

dd if=/dev/zero of=/dev/sdb

There’s one problem with this: newer, more advanced, techniques make it possible to retrieve data that were replaced with a bunch of 0s. To make it more difficult, if not impossible, for the bad guys to read data that was previously stored on a disk, Red Hat ships the “shred” utility as part of the coreutils RPM package. Launching “shred” on a disk or a partition will write repeatedly (25 times by default) to all locations on the disk.
Note: Be careful with this one too!

shred /dev/sdb

This is currently known to be a very safe way to delete data from a hard drive before, let’s say, you ship it back to the manufacturer for repair or before you sell it on eBay!

Frozen Xwindow

If your Xwindow freezes sometimes, here are two ways that you may try to kill your server. The first is the simple simple way of killing your X server the key combination: Ctrl+Alt+Backspace

The second way is a little more complicated, but it works most of the time. Hit Ctrl+Alt+F2 to startup a virtual console, then log in with your user name and password and run:

# ps -ax | grep startx

This will give you the PID of your Xserver. Then just kill it with:

# kill -9 PID_Number

To go back to your first console, just hit Alt-F1

Customizing your directory colors

I know a lot of you know the command ls --color. Which displays your directory with colors. But, a lot of people may not know that those colors are customizable. All you need to do is add the following line to your /etc/bashrc file.

eval `dircolors /etc/DIR_COLORS`

And then all of the color configuration can be found in the file /etc/DIR_COLORS