Typical sysadmin in enterprise environment connect to the server from windows environment using terminal emulator such as Putty and
Teraterm.
On the exam you will work with the server directly. But s multiple servers are used you need to connect to them via ssh.
To speed up the work you need to work with multiple windows and on other methods to increase you productivity in command line environment.
One of such methods is to use screen -- terminal multiplexor which is included in RHEL ISO. It allow open multiple terminal
windows (one for each directory you are using on the remote server) and this save time on switching between various, sometimes deeply
nested directories.
The other more complex, time consuming and risky method (for the exam) is to try to install GUI and use GUI environment, if it was
not provided by default. During training you preferably should use GUI environment as it more convenient. If you connect from Windows
laptop you can also use multiple terminals.
In a non=graphical environment, you just have a set of six virtual consoles -- six terminal windows. To switch use Alt+F1
through Alt+F6.
Tip: A convenient alternative to using the Alt+F1 Alt-F6 in non-graphical environment when you access the console directly
(if and only if you access the console directly, ssh session does not qualify) is offered by the chat command
which is installed by default of RHEL7. For example, type chvt 3. This brings you to a login prompt on virtual terminal
3. Switch back to the graphical environment using the chvt 1 command.
The first virtual terminal is so called the default console. the first corresponds to the device /dev/tty1. The other virtual
consoles to devices /dev/tty2 through /dev/tty6.
The graphical environment is the most convenient environment to work as it allow open any number of terminal sessions (aka virtual
consoles) on the screen. And if you have large display you can position 4 terminal sessions on the screen which make working with
multiple sessions very convenient.
Gnome also has multiple virtual screen, which is another big advantage as you can have several sets of terminal session on different
virtual screens.
If you connect from windows you can open multiple session via your terminal emulator and also potion then side byside on the screen.
Window does not have multiple virtual screens though.
NOTE:
You can also use screen to get multiple consoles (terminal
sessions). It has no limit on the number of opened terminal sessions.
But you can also switch to linux console: use Ctrl+Alt+F1 key to switch to the first console (Works on real console;
does not work if you are connected via ssh to pseudo terminal )
When you connect via ssh you connect to so called pseudo terminals. These pseudo terminals are corresponds to devices /dev/pts
directory. The first is /dev/pts/1, the second is /dev/pts/2, and so on. You can see then
if you type the command last
[0]test01@ROOT:/mnt/Packages # last
bezroun pts/0 ool-44c79867.dyn Mon Oct 15 22:41 still logged in
reboot system boot 3.10.0-862.14.4. Mon Oct 15 22:37 - 05:35 (06:57)
bezroun pts/1 ool-44c79867.dyn Sun Oct 14 08:45 - 06:04 (21:18)
bezroun pts/0 ool-44c79867.dyn Sun Oct 14 08:32 - 06:04 (21:31)
reboot system boot 3.10.0-862.14.4. Sun Oct 14 08:23 - 06:04 (21:40)
bezroun pts/0 ool-44c79867.dyn Sat Oct 13 22:30 - 05:03 (06:32)
reboot system boot 3.10.0-862.14.4. Sat Oct 13 22:29 - 05:04 (06:35)
bezroun pts/0 ool-44c79867.dyn Fri Oct 12 22:27 - 05:02 (06:35)
bezroun pts/0 ool-44c79867.dyn Fri Oct 12 17:43 - 21:02 (03:18)
reboot system boot 3.10.0-862.14.4. Fri Oct 12 17:43 - 05:02 (11:19)
alterego pts/1 ool-44c79867.dyn Fri Oct 12 04:16 - 05:03 (00:47)
bezroun pts/0 ool-44c79867.dyn Fri Oct 12 02:33 - 05:03 (02:30)
In this exercise, you learn how to work with pseudo terminals. You also learn how to get more information on user activity on specific
pseudo interfaces.
1. Login via ssh to your test server. Switch to root.
2. From the terminal window, type w. This will give an overview of all users who are currently logged in.
[0]test01@ROOT:/mnt/Packages # w
05:37:28 up 6:59, 1 user, load average: 0.00, 0.01, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
bezroun pts/0 dsk-44 22:41 0.00s 0.32s 0.20s sshd: bezroun [priv]
In RHEL7 to issue a proper reboot you need to use the systemd. The "addition" to RHEL7 make
administration of RHEL7 drastically different from administration of RHEL6 and this is not a good thing. So now you need use:
The systemctl poweroff command should shut off power on the machine. While systemctl halt should shutdown
and then hang the server without switching the power off.
When other users are login issuing systemd reboot and similar commands is dangerous as those you might not be able
to save their work. You need to warn them first.
Note: systemd is very complex and thus notoriously unreliable (and problems with it significantly slowed down adoption of
RHEL7 in enterprise environment) and might not work if the server is malfunctioning. In such cases you need to try to force a
machine to reset, you can try to type echo b > /proc/sysrq-trigger. This command immediately resets the machine without saving
anything. Of course, this command should be used only if there are no other options!
Those days sysadmins typically connect to servers from corporate Windows laptop in his/her office or cubical. And often servers are
in remote locations, that if are not physically accessible. To manage these servers, Secure Shell (SSH) is normally used. In this section,
you learn how to work with SSH.
In RHEL7 ssh service (sshd daemon) is running by default and offering services at port 22, and it not blocked by the firewall.
You use iether terminal emulator like PuTTY or if you are on other linux server command like ssh command to reach the
other server. The ssh command by default uses port 22. If you ssh server was reconfigured to run on other port
(which happen in some Web hosting companies), use ssh -p followed by the port number you want to connect to.
to connect to other Linux server from a Linux session just type ssh followed by the name of the other Linux machine.
For example
ssh test02
ssh will try to connect you as the same user ID under which you are logged on the first machine (for example root). If you need other
user you need specify the name. For example
ssh alterego@test02
If, for example, you are logged as regular use on you current server and want to connect as root to the other server you need
to use the command ssh root@remoteserver.
An alternative way of specifying the user account is by using the option -l userID. So, ssh remoteserver -l roottest02 will try to establish a root session to the remote server test02
NOTE: On Windows there is reach choice of terminal emulators including Teraterm and MobaXterm. The latter is so
called "rich" terminal emulator and also offers major Unix command in windows environment as well as the ability to transfer files.
1. From the root shell on server1 type systemctl status sshd. This command in RHEL7 replaces server command
of RHEL6 and allows to determine the status of this service.
2. To avoid any firewall-related problems, type systemctl stop firewalld. (this product of systemd team replaced
iptables and you you learn how to configure this firewall to limit traffic).
3. Type ip a | grep 'inet '. (Notice the space between inet and the closing quote. Command
ip is also a "new brave world", although unlike farewald it has some advantages over ifconfig command ( unlike
firewalld it also was available in RHEL6 )
[0]test01@ROOT:/mnt/Packages # ip a | grep 'inet '
inet 127.0.0.1/8 scope host lo
inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0
That is a new way to determine the IPv4 address on RHEL7 server tha tyou now is supposed to know. But old good command ifconfig -a
is still availbe too:
4. Now type cat /etc/hosts and determine ip of your second server. Let's assume that it is 10.0.0.5
5. On server1, type ssh -l root 10.0.0.5 This connects to the sshd process on test02
server and opens a root shell.
6. Before being prompted for a password, you see a message indicating that the authenticity of host 10.0.0.5
cannot be established. This message is shown because the host you are connecting to is not yet known on your current host, which might
involve a security risk. that also is normal message if the remote server has never been contacted before and therefore there is no
way to verify the identity of the remote server. After connecting to the remote server, a public key fingerprint is stored in the file
~/.ssh/known_hosts. Type yes to continue. You should not be prompted if you connect the second time.
7. When prompted, enter the root password. After entering it, you now are logged in to test02 and can investigate
it. To terminate this session type exit
NOTES:
In some cases, for example if you reinstalled OS on the second server of changed its IP address the remote host key fingerprint
does not match the key fingerprint that is stored locally. This situation also arise if you ssh session is decoded in the middle
(attack in the middle) which is a potentially dangerous attack. If you made changes mention before then you can remove
the key fingerprint from the ~/.ssh/known_hosts file. Otherwise you need to investigate why this situation arose.
If you connect to other computer form terminal window in GUI environment you might wish to see X11 screen of the terget computer
too. It is possible if X server is running of target computer too. If this is the case you can add option -X
to the ssh command. for example ssh -X alterego@test02
you can also create a systemwide configuration that allows you to use “X forwarding,” which is starting graphical applications through
an SSH session. As root, open the configuration file /etc/ssh/ssh_config and make sure it includes the following line:
ForwardX11 yes
The next time you use the ssh command, X forwarding will be available by default.
Instead of using password for authentication ssh provide more secure method based on you a public/private key pair. The private key
needs to be kept private and will never be distributed outside server on which it was generated. The public key is stored in the home
directory of the target user on each og the servers you want to communicate with
When authenticating using key pairs, the ssh client generates a hash derived from the private key. This hash is sent to the server,
then the server sends something bask to complete authentication. This is called ssh handshake.
To create a key pair, use the ssh-keygen command. The ssh-copy-id command is used to copy the public
key to the target server.
When creating a public/private key pair, you are prompted for a passphrase. If you want maximal security, you should enter a passphrase.
If not you can skip this step and get so called passwordless public/private paie which is still more secure then any password based
authentication and is enough for most purposes outside financial and military applications. You should never transfer your private
key using unencrypted channel, or send it by email, though.
Creating Public/Private Keys and distribution private key to the target server
On the server test01, open a root shell.
Switch to ~/.ssh directory and type ssh-keygen. When asked for the filename in which to store the (private)
key, accept the default filename ~/.ssh/id_rsa. When asked whether you want to use a passphrase, press Enter
twice to creates passwordless public/private pair
Check if the private key will now be written to the ~/.ssh/id_rsa file and the public key is written to the ~/.ssh/id_rsa.pub
file.
If yes execute the utility ssh-copy-id test02 to copy the public key you have just created over to test02.
it will be added to the file ~/.ssh/authorized_keys file on the remote host. You are then asked for the password on the
remote server. After that you can enjoy passwordless login.
To check the setup, type ssh test02. You should now authenticate without having to enter the password for the remote
server test02.
NOTE: if multiple users are using keys to log in with that specific account, the authorized_keys file may contain several
public keys. If you accidentally overwrite this file, you will destroy ability of other users to login on the server using ssh
private key authentication
scp command allow to transmit files form computer to another using secure encrypted channel. For example, to transfere the /etc/hosts
file to the /tmp directory on test02 server using your current user account, use the following command:
scp /etc/hosts test02:/tmp
You can also use scp to copy an entire subdirectory structure. To do so, use the -r command, as in
the following command:
scp -r /etc test02:/tmp
that creates a backup copy of /etc of server test01 on server test01. which is useful for transfering common files to another server.
It also allow you to restore files if you did something wrong in your /etc/directory on server test01.
This command transfer you modified files .bash_profile and .bashrc (with added aliases) to server test02. That makes
working as root on server test02 more convenient. Old files are overwritten so we make backup of them first.
NOTES:
The scp command can work with non standard port as well. Unlike ssh the option -P (uppercase) instead of
-p (lowercase) for the ssh
As an alternative to using scp for copying files between servers is the rsync command. The basic
use of rsync is similar to the use of scp, but you should use it only if you use of often in your daily work as there are
some gotchas here. It is mainly useful for volume transfer of changes to pre-existing site like overnight update of the website.
Rsync also allow you synchronize files and directories deleting all file on the tqrget that do not exist on the source. If also often
used for the backup as poor man backup tool.
If you connect to Linux server from Windows laptop and need to transfer files for it the best is to install Winscp program
(which is free). It provides very convenient graphical interface and contain windows style editor which can be used to edit
small files directly on the remote host (well not completly directly; it first copied it to windows in the background and then copies
back). For people who got used to Windows editors it is the most convenient and safe editing option for configuration
files and small scripts
The screen command allows you to multiplex single session. It does not just allow you to run multiple terminals, but
also allows you to share a session with other users, or to detach to remote terminal sessions and later resume it getting exactly the
same environment as when you left.
Screen is not installed by default but is available from Red Hat RPM. To install it use the yum install -y screen
command. Then, type screen to open a screen session. After installation the most important file to know about is screen
configuration file which is located in etc directory:
After that screen is workable condition and you can start screen session by simply typing screen on the command line. You will
get terminal window with the last line reserved for screen information. and can type any command it in it. If you close session,
screen autodetach its session and it will be preserved so if you connect letter you can connect to is by typing screen -r and get the
same environment which you left. Which in most cases is a big productivity booster.
NOTE: line mc (Midnight commander screen can initially intimidating if you want to use its full capabilities. In this case
you need to know around a dozen of command which start with prefix Ctrl-A (see below). Custom screenrc can help (see
.screenrc examples).
Those who find it difficult can find the package byobu available from EPEL repository which originated in Ubuntu
and provide more user friendly screen interface and ton of bells and whistles. After installation of the package just type byobu-screen
and perform configuration by pressing F9. I did not find this package useful because it is way too complex. But it is
written in bash and as such can be a useful example of extending screen capabilities. That's probably the main value of
the package.
The screen command is particularly useful on remote server (in our setup this test02 server). In this case
when you connect to this server after disconnecting you are able to return in the same environment that you had left previous time,
includes current working directory and value of env variables.
As this is command line utility it has a set of commands. Every screen command is started with the Ctrl+A key
sequence. To get help type Ctrl+A, ?. This shows a list of all commands that are available. An important command to remember
is Ctrl+A, /, which will close the screen session. Make sure to remove screen sessions that you do not need anymore, otherwise
they will stay active until the next time you reboot your server!
All you need to know to work with screen is 12 command listed below:
Help Ctrl-a ? (you need to press Shift key to get ? on the US keyboard)
Create a new windows Ctrl+a c
List windows Ctrl-a w
Go to a window numbered 0 9 Ctrl+a 0-9
Switch to the next screen Ctrl-a space
Detach Screen: Ctrl-a d
Re-attach Screen: screen -x or screen -x PID
Split window horizontally: Ctrl-a S Split window vertically: Ctrl-a |
Move Between Windows: Ctrl-a Tab
Name Session: Ctrl-a A
Detach from screen but keep shell window open Ctrl+a d. Detach and disconnect Ctrl-a D
Quit screen Ctrl-a Ctrl-\
To learn how to use screen please do the following exercise:
Open an SSH session to test02 server,
Install screen on the test02 server, if it was not installed before.
Type screen to open a screen session on server test02
Type command tail -f /var/log/messages
Type the Ctrl+A,D key sequence to detach from the screen session and log out from the SSH session.
When you are ready to reconnect, start the SSH session again. It is essential that you are using the same user account that you
used before.
Attach to the screen session again using screen -r. You can see that you get into the same environment running the same
command as before
If while trying to attach to a screen session you get a message that multiple screen sessions are currently running, you need to
be more specific. To find out which screen sessions currently are running, use the screen -ls command. In this
case you need to adding the number of the screen session to the screen -r command to reconnect to the particular session.
NOTE: You can also use screen to work together with other users in the same session. So they are able to see what
you are doing in your teminal session. The second user can just connect to your pre-existing screen session using screen -x command.
If multiple screen instances are running you need to provide the name of the the instance from screen -ls command.
When screen is started it reads its configuration parameters from /etc/screenrc and ~/.screenrc if the
file is present. We can modify the default Screen settings according to our own preferences using the .screenrc file.
Here is a sample ~/.screenrc configuration with customized status line and few additional options:
~/.screenrc
# Turn off the welcome message
startup_message off
# Disable visual bell
vbell off
# Set scrollback buffer to 10000
defscrollback 10000
# Customize the status line
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
