The exact description of what this does is

It is very useful to use the option “-t” in screen as it allows you to mark your instances. If you run a new screen sheel with the command;

Then when you run Ctrl-a “ to list the windows, you will recognize your tailing window with the title “/var/log/local6″

This is a very short article about screen. I hope on the way I use this tool, I may improve this it.

For example if you want to set ethernet options into your ifcfg-eth0 file below is the quote from this file;

I hope that you have taken the backup of partition table previously with the command;

Or if you also want to backup the whole MBR to a file do this;

From now on, I assume that you have booted the system in rescue mode with networking support.

1) The first thing is to paste this partition table back into its original space. Presumably, you have copied the partition table from network and put it under /tmp/sda_partition_table.out

This will fix your partition table. Now time to fix MBR

2) As the MBR has gone, we have to write MBR again. Do the followings;

The root (hd0,0) command assumes that your boot partition is in /dev/sda1

After these commands, you should be able to boot your system as before.

Lets start:

Sample NIS domain: penguen.com
NIS Server: rh54srv1.penguen.com
NIS Server IP:  192.168.200.1
NIS Client IP: 192.168.200.81

**Don’t forget that this hostname to IP mapping must exist in /etc/hosts file.

[SERVER SIDE CONFIGURATION]

Install the packages required for NIS server

Add the following line  into cat /etc/sysconfig/network

Start the following daemons

Generate the NIS database by the following command. Command should detect your hostname and you should only press Control D.
Once you Press and confirm the output, database will be generated.

Now start two more services

Make sure that deamons are running not to beat the air

Now our NIS server is ready, it is time to configure NIS clients.

NIS client configuration is easy, espacially with the handy tool “authconfig” in redhat. It is sufficent to type “man authconfig” to learn how you can use this tool to configure your nis client. Run the following command to activate authentication via your NIS server.

Everything is completed now. Lets test the setup. Login to the server and run the following;

You should see a similar output. If you don’t check your setup. Now lets add another username “nisuser100″ ,  update the database
and test this username in the client.

Now try to login with this username into the client that we previously configured as NIS client.

Just ignore the error message now. We haven’t configured autofs mounter yet, but we can see that our NIS setup
works properly. Now configure NFS server for home exports.

Add the following line into our NFS server (rh54srv1) /etc/exportfs file.

Now reexport all directories in NFS server and check the configuration;

Server side NFS configuration is completed. Now login to NIS client and configure automounter.

Add the following line into /etc/auto.master file

Create the file /etc/auto.home and add the following line into it, so that when users login their home directories will be mapped.

Restart autofs deamon

To test automounting works properly, login into the client via ssh once again.

As you can see we haven’t received any error message about “home directory not found” but instead /home/nisuser100 is automatically mounted on the NFS server.

I hope everything went right on your side too. Let me know if you see any issues on this short article.

We have two partitions of the size 512MB in two different disks:

First Partition: /dev/sdb2
Second Partition: /dev/sdc1
Partition Types: fd (Linux raid auto detect)

As we are creating a raid paritition, using fdisk set both partition types to the code “fd” . Your output from fdisk will be something like below;

Lets create our RAID1 array;

Now check the raid array building;

As you can see from the output of cat command, md1 raid device has been created with two active partitions (sdc1 and sdb2)

Now you can create the filesystem on /dev/md1 device and mount.

Finally mount the partition into a directory.

In order to see the status of the array you can run the command for which you will see a similar output like below;

DISK FAILURE

Now your array is working. Imagine that one of the disks (e.g /dev/sdc1) in the array has failed and we need
replace the failed disk with another one (e.g /dev/sdd1) . Here is the process: First fail the disk (but this may not
be necessary if it is in already failed state, you can try) , remove it and add /dev/sde1 device.

After this command, rebuilding the array starts automatically.

The new situation is;

SPARE DISK

What if you want to have a spare disk into this array. Normally spare disk can be added during initilization step with the switch “-x” , however
in our configuration (raid1 with 2 disks) if you try to add a third disk, mdadm will automatically add it as a spare disk.

You can also try failing /dev/sdd1 and you will see that /dev/sde1 will be automatically attached into the raid1 array and /dev/sdd1 will be marked as faulty.

STOPPING THE ARRAY

If you want to stop/disassemble the array, use the following;

Now you have a fully functional raid1 array. Congratulations!!

In this example, here are the client and server data. Green color  is used for the text/command you should type.

Client hostname: rh54-win-1
Client username: sshtest
Remote system IP: 192.168.200.1
Remote system hostname: rh54srv1
Remote username: root

1) Authenticating yourself by public key instead of password into remote systems

a) First create private and public keys. When the passphrase is asked leave it empty.

[sshtest@rh54-win-1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sshtest/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sshtest/.ssh/id_rsa.
Your public key has been saved in /home/sshtest/.ssh/id_rsa.pub.
The key fingerprint is:
a3:6f:be:7f:0c:c5:32:61:dc:d6:e1:2c:57:df:9a:a2 sshtest@rh54-win-1.penguen.com

Now our keys are saved under /home/sshtest/.ssh folder in the client we work.

b) It is time to copy our public key into the remote system
[sshtest@rh54-win-1 ~]$ ssh-copy-id -i /home/sshtest/.ssh/id_rsa.pub root@192.168.200.1
29
root@192.168.200.1’s password:
Now try logging into the machine, with “ssh ‘root@192.168.200.1′”, and check in:

.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.

We have copied our key successfully.

c) Now try to login to the system again

[sshtest@rh54-win-1 ~]$ ssh root@192.168.200.1
Last login: Tue Dec 29 20:37:59 2009 from 192.168.200.50
[root@rh54srv1 ~]#

It is nice right:)

2) Using passphrase in authentication

If you had provided a passphrase during the key creation in the step 1.a, then you would have had to enter the passphrase in each connection setup but what is the point if we have to enter a passphrase each time we initiate the connection.  If we put the security point of view aside, I will try to explain how we can avoid entering passphrase everytime but once for the session. For instance once at the beginning of the day and you won’t have to type it again and again. Here it is;

1) Create public and private key but this time type a passphrase.

[sshtest@rh54-win-1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sshtest/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):  testphrase
Enter same passphrase again: testphrase
Your identification has been saved in /home/sshtest/.ssh/id_rsa.
Your public key has been saved in /home/sshtest/.ssh/id_rsa.pub.
The key fingerprint is:
b1:b1:68:45:8e:31:fb:98:7f:b9:21:c7:2c:73:ce:9b sshtest@rh54-win-1.penguen.com

2)Copy the key into the remote system
[sshtest@rh54-win-1 ~]$ ssh-copy-id -i /home/sshtest/.ssh/id_rsa.pub root@192.168.200.1
29
root@192.168.200.1’s password:
Now try logging into the machine, with “ssh ‘root@192.168.200.1′”, and check in:

.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.

From now on if you try to login to the root account on the remote system 192.168.200.1 you will be presented by a passphrase. To avoid this, continue reading.

3) Run the ssh-agent program which will respond on behalf of us.

[sshtest@rh54-win-1 ~]$ ssh-agent /bin/bash
[sshtest@rh54-win-1 ~]$ env | grep SSH
SSH_AGENT_PID=3381
SSH_AUTH_SOCK=/tmp/ssh-Bixnyz3380/agent.3380
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

We can see from the output of the second command such that ssh-agent sets some environmental variables. That is good:)

4) Now let’s use ssh-add to provide ssh-agent with your key.

[sshtest@rh54-win-1 ~]$ ssh-add
Enter passphrase for /home/sshtest/.ssh/id_rsa:  testphrase
Identity added: /home/sshtest/.ssh/id_rsa (/home/sshtest/.ssh/id_rsa)

5) Now try to login again

[sshtest@rh54-win-1 ~]$ ssh root@192.168.200.1
Last login: Tue Dec 29 21:13:55 2009 from 192.168.200.50
[root@rh54srv1 ~]#

As you can see, nothing has been asked. However, if you leave the current shell in which you have executed ssh-agent, ssh-agent will die and you will have to enter passphrase again. SSH-AGENT is very handy for administrators who have terminals active during the day  and connect into various servers.

I hope this article was useful for a quick intro authentication in SSH. If you want to have more info on the subject not a tutorial style but mainly about concepts you can have a look at http://unixwiz.net/techtips/ssh-agent-forwarding.html