[I generally use Debian. These notes cover Red Hat-flavored things.]
[Updated March 2018]
Red Hat Enterprise Linux (RHEL) appeals to businesses and vendors because its long release cycle keeps costs low by providing a stable target platform, with predictable support costs. RHEL fits servers where the OS may never see a major upgrade until the box gets replaced or rebuilt. Balanced against that stability is the lack of feature updates, since software packages only see major version upgrades every few years.
Red Hat releases a new major version irregularly — historically every two to five years. Red Hat fully supports each release for at least five years, followed by another five years of fixes for critical bugs and important security patches.
Red Hat provides excellent commercial support for RHEL. As a company, Red Hat derives the bulk of its revenue from training and support.
For those willing to forgo commercial support, CentOS provides a free trademark-stripped clone of RHEL (with Red Hat’s blessing). CentOS generally releases updates within three days of the corresponding RHEL updates (often in less than a day, rarely after a few weeks). Apart from the lack of commercial support and slight update lag, CentOS is functionally identical to RHEL.
Fedora is a community-driven Linux project that fills the role of de facto experimental branch for RHEL. Fedora is Red Hat-flavored, but moves much faster than RHEL. Where RHEL releases a new version every few years, Fedora releases a new version every six months. While it doesn’t have RHEL stability, frequent software updates make Fedora appealing for some roles (i.e., the same places where you’d run Debian Testing, like many workstations).
$ cat /etc/redhat-release
Unlike Debian, Red Hat recommends a fresh install between major version rather than attempting an upgrade (though this may change in RHEL 8).
The stability of RHEL may not be the best fit for customers deploying virtual machines, where a system can easily move to new hardware without a rebuild. This mis-match may be one of the reasons Red Hat is aggressively pursuing Project Atomic and Docker.
Differences in RHEL vs Debian:
yumpackage manager instead of Debian’s
apt. (Fedora has replaced
# yum install tmux vim-enhanced
yum is the current Red Hat package manager.
Fedora is testing a new package manager called (unfortunately)
dnf has a more efficient dependency solver than
yum, and better support for online repositories.
dnf doesn’t depend on Python.
For a user,
dnf works very much like
yum, using most of the same commands and arguments.
See yum(8) and yum.conf(5).
Check for updates:
# yum check-update
# yum update
Update a single package:
# yum update foo
Search for a package:
# yum search foo
Show package info:
# yum info foo
Install a package:
# yum install foo
Remove a package
# yum remove foo
List files in a package:
# repoquery --list foo
Find which package provided a file:
# yum provides "*bin/foo"
List installed packages:
# yum list installed
List enabled repositories:
# yum repolist
Show yum history:
# yum history list # yum history list all # yum history list 4
Undo/redo a history transaction (!):
# yum history undo 3 # yum history redo 3
Is NetworkManager running?
# chkconfig --list NetworkManager
# service NetworkManager status
# systemctl status network
# service NetworkManager start
# systemctl start network
Enable NetworManager at boot:
# chkconfig NetworkManager on
Disable NetworkManager (and enable the standard network service):
# service NetworManager stop
# systemctl stop network # chkconfig NetworkManager off # $EDITOR /etc/sysconfig/network-scripts/ethN NM_CONTROLLED=no ONBOOT=yes # service network start # chckconfig network on
Start NetworkManager applet if not already started (in X):
$ nm-applet &
Edit connection (in X):
$ nm-connection-editor &
Edit connection (curses) (does not support all connection types, e.g. VPN’s, WPA Enterprise):
# yum install NetworkManager-tui $ nmtui
Find config files in
/etc/sysconfig/, except for VPN, mobile broadband, and PPPoE which are stored in
/etc/sysconfig/network holds global settings.
Set a static IP by editing
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes PREFIX=24 IPADDR=10.0.1.91 DNS1=188.8.131.52 DNS1=184.108.40.206
Set the default route in
NETWORKING=yes HOSTNAME=foo.example.org GATEWAY=10.0.1.1
If we edit an ifcfg file by hand, NetworkManager is not automatically aware of changes. Tell it to notice the changes:
# nmcli connection reload
After changing an interface with
nmcli, the interface must be brought down and up for the changes to take effect:
# nmcli dev disconnect ethN # nmcli con up ethN
$ nmcli help $ nmcli general|connection|device help
$ nmcli general status
$ nmcli connection show
Check device statuses:
$ nmcli dev status
Show device details:
$ nmcli dev show
Start the interactive connection editor:
# nmcli con edit
Add a dhcp connection (not with the interactive editor) example:
# nmcli con add type ethernet con-name myconnection ifname eth0
Modify it to use a static address:
# nmcli con modify myconnection myconnection ip4 10.0.0.99/24 gw 10.0.0.1 ipv4.dns "220.127.116.11 18.104.22.168"
Set DNS search domain for a connection:
$ nmcli con show # nmcli con mod "Wired connection 1" +ipv4.dns-search example.com $ nmcli con show "Wired connection 1" | grep dns-search # nmcli con down "Wired connection 1" # nmcli con up "Wired connection 1"
firewalld, a wrapper around iptables.
It provides dynamically swapable sets of rules, with each rule set organizes rules into trust “zones”.
I speculate that Red Hat introduced firewalld for two reasons:
Unfortunately, as of 2017, the capabilities of firewalld are limited. It works OK for very simple rule sets, but is not suited for firewalls, routers, or servers with complex rule needs.
Here’s how to remove firewalld and add iptables:
# systemctl mask firewalld # yum install -y iptables-services # systemctl enable iptables # systemctl enable ip6tables # systemctl stop firewalld # systemctl start iptables # systemctl start ip6tables
The iptables rules for
iptables-services persist in
RHEL7 ships with chronyd, an NTP daemon.
Chrony aims to provide timekeeping superior to ntpd in adverse environments, including those with intermittent or congested network connections, systems that do not run continually, and on virtual machines.
Customize it with the
By default, chronyd runs as only a client.
allow entry to
/etc/chrony.conf serve time to a particular subnet.