Topics: Hardware, Red Hat

Common items to install under Red Hat on Dell hardware

There are a few items that can be very useful to install within Red Hat, if used on Dell hardware. These are the OpenManage System Administrator tools that will provide you more information on the Dell hardware, Dell System Updater or DSU, that can be used to update firmware and BIOS on Dell hardware, and the Dell iDRAC Service Module that allows the iDRAC to exchange information with the Operating System.

First, set up the Dell Linux repository:

# curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash
Next, install OpenManage System Administrator, or OMSA, and make sure to start it, and enable it at boot time:
# yum -y install srvadmin-all
# /opt/dell/srvadmin/sbin/srvadmin-services.sh start
# /opt/dell/srvadmin/sbin/srvadmin-services.sh enable
With OMSA installed, you can, for example, now retrieve information about the physical disks in the system, and also the virtual disks (or RAID arrays) configured on these physical disks. Here's how you can use the command line interface tools to look up this information:

List the controllers available in the system:
# /opt/dell/srvadmin/bin/omreport storage controller
Now, list the physical disks (or pdisks) for each controller, for example for the controller with ID 0:
# /opt/dell/srvadmin/bin/omreport storage pdisk controller=0
And you can list the virtual disks (or pdisks) for each controller, for example for the controller with ID 0:
# /opt/dell/srvadmin/bin/omreport storage vdisk controller=X
A lot more is possible with OMSA, but that's outside the scope of this article. Instead, let's move on with the items to install.

Install Dell System Update (or DSU):
# yum install dell-system-update
To update firmware, you can now run:
# dsu
Usually it's just fine to select all firmware items to update (by pressing "a") and have it updated (by pressing "c"). This may take a while, and may require a reboot of the system. Upon reboot, the system may also take a while to complete the firmware and/or BIOS updates.

Finally, the Dell iDRAC service module. The latest version (at time of writing this article) can be found here: https://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=HNX9K. Copy the download link on this page of the GNU ZIP file.

The Dell Service Module requires the usbutils package to be installed:
# yum -y install usbutils
Now you can download and install the Dell iDRAC Service Module:
# mkdir /tmp/dsm
# cd /tmp/dsm
# wget https://downloads.dell.com/FOLDER05038145M/1/OM-iSM-Dell-Web-LX-310-1233_A00.tar.gz
# gzip -d *z
# tar xf *tar
# ./setup.sh
Here it's best to select all features (by typing "6") and hit "i" to install. Keep everything at default settings and answer "yes" to any other questions. After installation is completed, you can log in to the iDRAC of the system, and view Operating System information there. This information has been communicated from the OS to the iDRAC by the Dell iDRAC Service Module.

Topics: Networking

Using tcpdump to monitor DHCP network traffic

The tcpdump command can be used to monitor DHCP related network traffic. This is very useful in cases where DHCP issues may have to be investigated. Basically, the tcpdump command can be used to do some packet sniffing on the network.

The method to capture DHCP traffic is to define a filter so that tcpdump dumps only DHCP related traffic. In DHCP, UDP port number 67 is used by a DHCP server, and UDP port number 68 is used by DHCP clients. Thus, you want to capture traffic with port number 67 or 68 as follows, assuming that eth0 is the network interface that will be used to monitor:

# tcpdump -i eth0 port 67 or port 68 -e -n -vv
By using the -vv option (for very verbose) you may see a lengthy output from the tcpdump command displaying a lot of information. In it you can see which DHCP server is responding, and what IP address is assigned. For example:
Client-ID Option 61, length 7: ether ec:9b:f3:6b:97:4b
Requested-IP Option 50, length 4: 192.168.0.3
Server-ID Option 54, length 4: 192.168.0.1
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 16: "android-dhcp-7.0"
Hostname Option 12, length 16: "SAMSUNG-SM-G890A"
In the example above, you can see that a Samsung SM-G890A phone, running Android, gets IP address 192.168.0.3 assigned from DHCP server 192.168.0.1. You can also see the MAC (or "hardware") address of the phone: ec:9b:f3:6b:97:4a.

One you're finished sniffing the network for DHCP related traffic, you can simply CTRL-C out of the tcpdump command.

Topics: Networking, Red Hat

Using tcpdump to discover network information

For most switches it is impossible to see which switch and switch port you are when you are connected to an 'access' port.

Using the Cisco Discovery Protocol or CDP (Cisco) and Link Layer Discovery Protocol or LLDP (Juniper or Dell) you can find out quite a bit of information about the switch that a host is connected to.

Enabling CDP/LLDP on an access port is arguably a security risk (information exposure), so it might not be enabled on your network. You can use the tcpdump command to disassemble CDP/LLDP packets which will usually show information like the name of the switch, its IP address, the switch port connected to, and sometimes the VLAN in use.

For Cisco CDP, assuming the network interface you wish to check is called "eth0":

# tcpdump -nn -v -i eth0 -s 1500 -c 1 'ether[20:2] == 0x2000' 
For Juniper LLDP:
# tcpdump -nn -v -i eth0 -s 1500 -c 1 '(ether[12:2]=0x88cc or ether[20:2]=0x2000)'

Topics: Networking, Red Hat

How to add a new static route on RHEL 7

Any network we are trying to reach is accessed via the default gateway only, if it is not implicitly overwritten by another static route definition. Let's have a look at a routing table on a Red Hat 7 system:

# ip route show
default via 192.168.0.1 dev em1 proto static metric 100
192.168.0.0/24 dev em1 proto kernel scope link src 192.168.0.204 metric 100
192.168.1.0/24 dev em2 proto kernel scope link src 192.168.1.32
From the above we can see that any packets to reach a destination network IP 192.168.0.0/24 (meaning anything on the network 192.168.0.X with a subnet mask of 255.255.255.0) should travel via interface em1 with IP address 192.168.0.204, and any other destination network not implicitly defined should use default gateway 192.168.0.1.

Sometimes you'll require a static route. Static routes are for traffic that must not, or should not, go through the default gateway. Routing is often handled by devices on the network dedicated to routing (although any device can be configured to perform routing). Therefore, it is often not necessary to configure static routes on RHEL servers or clients. Exceptions include traffic that must pass through an encrypted VPN tunnel, or traffic that should take a specific route for reasons of cost or security or bandwidth. The default gateway is for any and all traffic which is not destined for the local network and for which no preferred route is specified in the routing table. The default gateway is traditionally a dedicated network router.

To add a new static route means to define yet another destination network as well as specify via which IP address and interface the packet should travel through in order to reach its destination. Usually this comes in handy when you have a second interface on the system that can be used to reach other networks (other than the networks that can be reached through the default gateway). In the example above that's interface em2.

For example, let's add a static route to destination network 192.168.2.0/24 via the 192.168.1.32 IP address and em2 network interface.

There are 2 ways of accomplishing this: By either using the "ip route add" command, which will define the route, but it will be lost upon reboot. Or by creating a route configuration file in the /etc/sysconfig/network-scripts/ directory.

First, the "ip route add" command:

To add a static route to a network, in other words, representing a range of IP addresses, issue this command as root:
# ip route add 192.168.2.0/24 via 192.168.1.32 dev em2
Where 192.168.2.0 is the IP address of the destination network in dotted decimal notation and /24 is the network prefix, which is equal to a subnet mask of 255.255.255.0. The network prefix is the number of enabled bits in the subnet mask. If you now rerun the "ip route show" command, you'll see that the route has been added.
192.168.2.0/24 via 192.168.1.32 dev em2 proto static metric 1
If you ever need to delete the route, you can use the same command, but just replace "add" with "delete".

Static route configuration can be stored per-interface in a /etc/syconfig/network-scripts/route-interface file. For example, fstatic routes for the em2 interface would be stored in the /etc/sysconfig/network-scripts/route-em2 file, for example:
# cat /etc/sysconfig/network-scripts/route-em2
192.168.2.0/24 via 192.168.1.32 dev em2
Once done, restart your network service (or restart the server):
# systemctl restart network

Topics: Red Hat

Install Python version 3 on Red Hat / CentOS

Red Hat / CentOS versions come, by default, with an older version of Python installed:

# python --version
Python 2.7.5
Python version 3 is available, however, it is not included with the Red Hat and/or CentOS distribution (at the time of writing this article).

If you do wish to use Python version 3, you can download this version from iuscommunity.org, which is an online community dedicated to delivering high quality packages of newer versions of popular software.

Here's how to do that:

First, install the ius-release.rpm:
# yum install https://centos7.iuscommunity.org/ius-release.rpm
Next, install Python 3.6:
# yum install python36u python36u-libs python36u-devel python36u-pip
Now you can write a python script. Be sure to replace the shebang at the beginning of the script from "python" to "python3.6", like this:
# /usr/bin/env python3.6
print('Hello')
If you were to just use just "python" in the shebang, then you get version 2 of Python. By specifiying "python3.6" in the shebang, you get version 3.6.:
# python --version
Python 3.6.5

Topics: Red Hat, System Admin

Linux Screen

The screen utility on Linux allows you to:

  • Use multiple shell windows from a single SSH session
  • Keep a shell active even through network disruptions
  • Disconnect and re-connect to a shell sessions from multiple locations
  • Run a long running process without maintaining an active shell session
First, let's install screen on a CentOS system:
# yum -y install screen
Once it's installed, screen can be easily started:
# screen
You are now inside of a window within screen. This functions just like a normal shell except for a special control command: "Ctrl-a".

Screen uses the command "Ctrl-a" (that's the control key and a lowercase "a") as a signal to send commands to screen instead of the shell.

For example, type "Ctrl-a", let go, and then type "?". You should now see the screen help page, showing you all the available key binding. Key bindings are the commands the screen accepts after you hit "Ctrl-a". You can reconfigure these keys to your liking using a .screenrc file, if you like.

To create a new window, you can use "Ctrl-a" and "c". This will create a new window for you with your default prompt. Your old window is still active.

For example, you can be running top and then open a new window to do other things. Top will remain running in the first window.

Screen allows you to switch between screens, by using "Ctrl-a" and "n". This command switches you to the next window. If you were to open more windows in screen, then "Ctrl-a" and "n" will allow you to cycle through all the windows, by repating the "Ctrl-a" and "n" commands. The windows work like a carousel and will loop back around to your first window. You can create several windows and toggle through them with "Ctrl-a" and "n" for the next window or "Ctrl-a" and "p" for the previous window. Each process in a window will keep running until you exit out of that window by typing "exit".

Anoter feature of screen is that you can detach from a screen, by typing "Ctrl-a" and "d". Screen allows you to detach from a window and reattach later. If your network connection fails, screen will automatically detach your session! If you detach from screen, you will drop back into your shell. All screen windows are still there and you can re-attach to them later.

If your connection drops or you have detached from a screen, you can re-attach by just running:
# screen -r
This will re-attach to your screen.

Screen will also allow you to create a log of the session, by typing "Ctrl-a" and "H". When you do that, you'll see in the Putty titlebar of your session the name of the log file being created, usually in the form of "screenlog.0". Screen will keep appending data to the file through multiple sessions. Using the log function is very useful for capturing what you have done, especially if you are making a lot of changes. If something goes awry, you can look back through your logs. Locking Your Screen Session

If you need to step away from your computer for a minute, you can lock your screen session using "Ctrl-a" and "x". This will require a password to access the session again.

When you are done with your work, you can stop screen by typing exit from your shell. This will close that screen window. You have to close all screen windows to terminate the session. You should get a message about screen being terminated once you close all windows. Alternatively, you can use "Ctrl-a" and "k". You should get a message if you want to kill the screen.

Topics: Red Hat, System Admin

Multi-user VNC setup on RHEL 7.5

Here's how to set up VNC on Red Hat 7.5, combined with the Gnome desktop, Firefox and TigerVNC.

The goal is to install a Linux desktop, Firefox and TigerVNC on a system with just a base (minimal) Red Hat 7.5 install (without a desktop), and to set up the VNC service for 2 users, in this case for user root, and for user oracle. The VNC port to use for user root will be 5901, and it will be 5092 for user oracle.

Note: This procedure will also work on older RHEL 7 versions, like RHEL 7.2 through RHEL 7.4, with a few minor changes as there are a few differences between these RHEL releases. Please see below.

Install the GUI first (based on: https://access.redhat.com/solutions/5238):

# yum -y groupinstall "Server with GUI"
# yum install xterm xorg-x11-xinit
Install TigerVNC:
# yum -y install tigervnc tigervnc-server
There is no need to specifically install Firefox - it is installed as part of the GUI installation.

If here, you are not using RHEL 7.5, but an older version of RHEL 7, then please make sure to (at least) update the following packages to the latest available versions. These latest package versions are needed to make this work:
# yum -y update xterm xorg-x1-xinit tigervnc tigervnc-server
Start the GUI:
# systemctl set-default graphical.target
# systemctl start graphical.target
Configure VNC (based on https://access.redhat.com/solutions/966063):

Configure the VNC password for both root and user oracle (repeat for both users - log in as each user, and run the following command):
# vncpasswd
You will be asked if you would like to enter a view-only password. You may answer "n" for no.

Set up the VNC service on the system:

For user root:
# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service
Edit the new file, and replace all entries in the files of "<USER>" with "root"; ensure the home directory of user root is also set to /root, not /home/root.

For user oracle:
# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:2.service
Edit the new file, and replace all entries of "<USER>" with "oracle".

Edit the xstartup user file in ~root/.vnc/xstartup and ~oracle/.vnc/xstartup. Replace the contents of the xstartup file with this:
#!/bin/sh

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
  [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
  vncconfig -iconic &
  dbus-launch --exit-with-session gnome-session &
If necessary, if the firewall is in use, add the ports in the firewall.

First check if the firewall daemon is running right now, and enabled at boot time:
# systemctl status firewalld
If so, then add the ports used by VNC to the firewall configuration:
# firewall-cmd --permanent --zone=public --add-port 5901/tcp
# firewall-cmd --permanent --zone=public --add-port 5902/tcp
# firewall-cmd --reload
Run the following command as changes were made to systemd files:
# systemctl daemon-reload
Enable and start the TigerVNC service:
# systemctl enable vncserver@:1.service
# systemctl enable vncserver@:2.service
# systemctl start vncserver@:1.service
# systemctl start vncserver@:2.service
If, at this point, when starting either VNC service, you get an error about not available resources, it may be that either VNC was already running, or that there are old VNC files in /tmp. In this case, first search for any running VNC processes:
# ps -ef | grep VNC
If any VNC processes are still running, then kill them, by using "kill -9". Then move over to the /tmp folder and clear out any old files used by VNC:
# cd /tmp
# rm -rf .X*
And then, try starting the VNC services again:
# systemctl start vncserver@:1.service
# systemctl start vncserver@:2.service
That should work. If so, then proceed with the next steps:

Check if the VNC services are listening on the ports 5901 and 5902:
# netstat -an | grep ::590
tcp        0      0 0.0.0.0:5901            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5902            0.0.0.0:*               LISTEN
tcp6       0      0 :::5901                 :::*                    LISTEN
tcp6       0      0 :::5902                 :::*                    LISTEN
Now, it's time to test the VNC connections. A good way to test, without having to install a VNC client (usually requiring admin privileges on your Windows desktop), use realVNC VNC viewer, from https://www.realvnc.com/en/connect/download/viewer/windows/. In the dropdown list on this website, make sure to select the "Standalone" version that applies to your operating system version. The regular EXE file on this site is a VNC viewer that requires admin privileges on Windows to install. This "standalone" VNC viewer can be used without having to install any software, and does not require admin-level access on Windows.

Open the screen for user root, by typing the following string, assuming the IP address of the server is 172.29.126.210:
172.29.126.210:5901
And for user oracle:
172.29.126.210:5902
And type the password provided earlier through the vncpasswd command.

That's it. You should be presented with desktop screens for both users root and oracle, and you should be able to run Firefox within those desktops.

Topics: Networking, Red Hat, Storage

How to install and configure Samba on CentOS 7 for file sharing on Windows

Here's how to set up a secure Samba share from a CentOS 7 (or RHEL 7) system, and share it with a Windows client.

First, install Samba:

# yum install samba samba-client samba-common
Add an exception to the firewall, if the firewall is active:
# firewall-cmd --permanent --zone=public --add-service=samba
# firewall-cmd --reload
Next, you'll need to know the workgroup the Windows system is configured in. By far, the easiest way to do this, is to open a command prompt on the Windows system, and run:
net config workstation
For the sake of this tutorial, we'll assume the workgroup is called WORKGROUP.

Make a copy of the Samba config file:
# cp /etc/samba/smb.conf /etc/samba/smb.conf.orig
Set up a secure file share. In the example below, the share will be located in /media/windows/share on the CentOS 7 system. Be sure to set the permissions in such a way that the user account used for the share (see below) indeed has access to this folder.
# mkdir -p /media/windows/share
# chmod -R 0755 /media/windows/share
# chown -R user:group /media/windows/share
Edit file /etc/samba/smb.conf and add:
[global]
        workgroup = WORKGROUP
        netbios name = centos

[Share]
        comment = Shared Folder
        path = /media/windows/share
        valid users = user
        browsable = yes
        writable = yes
        guest ok = no
        read only = no
Set the SMB passwd for the user (this will be the username and password used to access the share from Windows):
# smbpasswd -a user
New SMB password:
Retype new SMB password:
Make sure everything is okay:
# testparm
Now enable and start Samba:
# systemctl enable smb.service
# systemctl enable nmb.service
# systemctl start smb.service
# systemctl start nmb.service
On the Windows host, io File explore type the IP address of the CentOS system, for example:
\\192.168.0.206
You will be asked for the username and password used when you ran the smbpasswd command.

And that should do it; You should now have a secured Samba share available on a Windows system.

Windows may cache any credentials that are used for the Samba share(s). When configuring the Samba share(s), it may be needed to have Windows "forget" these credentials. This can be easily achieved by running from a Command Prompt:
net use * /del

Topics: Monitoring, Networking, Red Hat

Securely enabling SNMP on Red Hat

Monitoring tools often use SNMP to query another system's information and status. For that to work on a Red Hat Enterprise Linux system, that system will have to have SNMP configured. And to allow a remote (monitoring) system to query SNMP information of a Red Hat Enterprise Linux system, one has to complete the following 3 items:

  • Set up SNMP.
  • Configure SNMP to use a non-public community name.
  • Allow access through the firewall, if configured.
For the configuration of SNMP, you'll need to install the following 2 packages:
# yum -y install net-snmp net-snmp-utils
Next, start and enable (at boot time) the SNMP daemon to run on the system:
# systemctl enable snmpd
# systemctl start snmpd
Now you can test if you can query SNMP infomation -locally- on the system, by using the snmpwalk command:
# snmpwalk -v2c -c public localhost | head -5
The community string used above ("public") is a well-known SNMP community string, and this can be (and probably "is") utilized by hackers or other unfriendly people to obtain information about the system remotely, and as such, it's best practice to change the public community name into something a littlebit different, preferably something that can't be guessed very easily. For the sake of this tutorial, we'll change it to "kermit".

Basically, you'll have to update this line in /etc/snmp/snmpd.conf from "public" to "kermit":

Before:
com2sec notConfigUser  default       public
After:
com2sec notConfigUser  default       kermit
Then, restart the SNMP daemon, so it picks up the changes to configuration file /etc/snmp/snmpd.conf:
# systemctl restart snmpd
Now test again with the snmpwalk command but this time by using the "kermit" community name:
# snmpwalk -v2c -c kermit localhost
That should give you quite a bit of output. If it doesn't, you've made a mistake, and you'll have to re-trace your steps.

The final step is to allow remote access. That will be needed if a remote system is being used to monitor the server, for example by a tool like Solarwinds. By default, remote access will be blocked by the firewall daemon on the system. To allow remote access, open up UDP port 161 on the client:
# firewall-cmd --zone=public --add-port=161/udp --permanent
# firewall-cmd --reload
Now log in to a remote system and run a similar snmpwalk command, but this time, specify the hostname of the server that you're querying (instead of "localhost"). For example, if the name of the host is "myserver", run:
# snmpwalk -v2c -c kermit myserver
And that's it. You can now remotely monitor a Linux server using SNMP, and you've secured it by changing the community name.

Topics: Networking, Red Hat

Running tcpdump

From time to time, there may be a need to run a tcpdump, to analyze the TCP traffic on a Red Hat system.

Now, there's a perfectly good description on how to that on the Red Hat website at https://access.redhat.com/solutions/8787, so we won't be repeating that on this blog.

Just a few simple commands to get the tcpdump command going:

To start a tcpdump, for example on network interface em1, and dump the output to a file called /tmp/tcpdump.out, run:

# tcpdump -s 0 -i em1 -w /tmp/tcpdump.out -v
The "-v" option used in the example above, shows the number of packets that it captured, while the tcpdump command is running, and thus is very useful. Once you think you have gathered enough information, hit CTRL-C to stop the tcpudmp. Be careful, running tcpdump can create quite a bit of output, especially if there's a lot of network traffic going on. This may fill up the the file system where the tcpdump output file is located in, pretty quickly, so don't leave the tcpdump running for prolonged periods of time.

To review the contents of the tcpdump output, use the "-r" option:
# tcpdump -r /tmp/tcpdump.out
The "tcpdump -r" command will show you detailed information about the captured network packets.

Number of results found: 432.
Displaying results: 1 - 10.