Release of RHEL 8 gives opportunity for those who still are using RHEL 6 to skip RHEL 7 completely for new server
7 has five years before EOL ( June 30, 2024) while many severs last more then five years now.
RHEL 8 theoretically will be able to withstand more heavy loads due to optimized TCP/IP stack and improvements
in memory handling.
On command line level you do not feel much change. Systemd is omnipresent like in RHEL 7.
Must know Command Difference in RHEL 7, 6 and 5
1. Shutdown system
RHEL 5 & 6: # shutdown
RHEL 7: # systemctl shutdown
2. Reboot system
RHEL 5 & 6: # reboot or # init 6
RHEL 7: # systemctl reboot
3. Configure default run level/target
RHEL 5 & 6: # /etc/inittab
RHEL 7: # systemctl set-default
4. Configure GRUB bootloader
RHEL 5 & 6: # /boot/grub/grub.conf
RHEL 7: # /etc/default/grub, grub2-mkconfig, grub-set-default
5. List running services
RHEL 5 & 6: # service –status-all
RHEL 7: # systemctl -t service –state=active
6. Check if service is enabled
RHEL 5 & 6: # chkconfig name
RHEL 7: # systemctl is-enabled name
7. View run level/target
RHEL 5 & 6: # runlevel or who -r
RHEL 7: # systemctl get-default or who -r
8. Enable/disable service
RHEL 5 & 6: # chkconfig name on and # chkconfig name off
RHEL 7: # systemctl enable name.service and # systemctl disable name.service
9. View service status
RHEL 5 & 6: # service name status
RHEL 7: # systemctl status name.service
Note: I have tried few RHEL6 command and they are working perfectly fine in RHEL7 also.
This chart is freely available at Red Hat website , you can just Google it or click below
download link to download. Go and try these commands on your test environment.
,May 2, 2015 at 6:17
/bin/ is not a symlink to
/usr/bin on any FHS compliant
system. Note that there are still popular Unixes and Linuxes that ignore this - for example,
/sbin are symlinked to
/usr/bin on Arch Linux
(the reasoning being that you don't need
/bin for rescue/single-user-mode, since
you'd just boot a live CD).
contains commands that may be used by both the system administrator and by users, but which
are required when no other filesystems are mounted (e.g. in single user mode). It may also
contain commands which are used indirectly by scripts
This is the primary directory of executable commands on the system.
/bin contains executables which are required by the system for
emergency repairs, booting, and single user mode.
/usr/bin contains any binaries
that aren't required.
I will note, that they can be on separate disks/partitions,
/bin must be on
the same disk as
/usr/bin can be on another disk - although
note that this configuration has been kind of broken for a while (this is why e.g. systemd
warns about this configuration on boot).
For full correctness, some unices may ignore FHS, as I believe it is only a Linux
Standard, I'm not aware that it has yet been included in SUS, Posix or any other UNIX
standard, though it should be IMHO. It is a part of the
LSB standard though.
LawrenceC ,Jan 13, 2015 at
/sbin - Binaries needed for booting, low-level system repair, or maintenance
(run level 1 or S)
/bin - Binaries needed for normal/standard system functioning at any run
/usr/bin - Application/distribution binaries meant to be accessed by locally
logged in users
/usr/sbin - Application/distribution binaries that support or configure stuff
/usr/share/bin - Application/distribution binaries or scripts meant to be
accessed via the web, i.e. Apache web applications
*local* - Binaries not part of a distribution; locally compiled or manually
installed. There's usually never a
/local/bin but always a
JonnyJD ,Jan 3, 2013 at 0:17
Some kind of "update" on this issue:
Recently some Linux distributions are merging
/usr/lib . Sometimes also
/usr/bin (Arch Linux). So
expected to be available at the same time as
The distinction between the two hierarchies is taken to be unnecessary complexity now. The
idea was once having only
/bin available at boot, but having an initial ramdisk makes this
I know of Fedora Linux (2011) and Arch Linux (2012) going this way and Solaris is doing
this for a long time (> 15 years).
xenoterracide ,Jan 17, 2011 at
/usr/bin are still separate because it is common
/usr on a separate partition (although this configuration breaks in
subtle ways, sometimes). In
/bin is all the commands that you will need if you
On Solaris and Arch Linux (and probably others)
/bin is a symlink to
/usr/bin . Arch also has
Of particular note, the statement that
/bin is for "system administrator"
/usr/bin is for user commands is not true (unless you think
ls are for admins only, in which case you have a lot
to learn). Administrator commands are in
Disabling Bluetooth service at startup
Additionally, once the kernel modules are disabled, if you have the bluez (Bluetooth
utilities) package installed you will want to have the Bluetooth service disabled at
On CentOS/RHEL 7 execute the following commands as root:
# systemctl disable bluetooth.service
# systemctl mask bluetooth.service
# systemctl stop bluetooth.service
On CentOS/RHEL 5 and 6 , execute the following commands as root:
# chkconfig bluetooth off
# service bluetooth stop
Uloading Bluetooth Modules
If the above kernel modules are already loaded, you can manually unload them with the rmmod
command. Depending on what Bluetooth hardware is discovered on the system, there is expected to
be slight variations on which Bluetooth modules are loaded. The rmmod command will display
information about additional Bluetooth modules loaded when attempting to use it. You will want
to rmmod any additional Bluetooth modules it notifies you are also loaded. Execute the
following as root to unload these modules from the running kernel:
On CentOS/RHEL 6 and 7 :
# rmmod bnep
# rmmod bluetooth
# rmmod btusb
On CentOS/RHEL 5 :
# rmmod bnep
# rmmod bluetooth
# rmmod hci_usb
An anonymous reader writes: Debian developer John Goerzen asks
Linux has become so complex that it has lost some of its defining characteristics. "I used to be able to say Linux was clean,
logical, well put-together, and organized. I can't really say this anymore. Users and groups are not really determinitive for permissions,
now that we have things like polkit running around. (Yes, by the way, I am a member of plugdev.) Error messages are unhelpful (WHY
was I not authorized?) and logs are nowhere to be found. Traditionally, one could twiddle who could mount devices via /etc/fstab
lines and perhaps some sudo rules. Granted, you had to know where to look, but when you did, it was simple; only two pieces to fit
together. I've even spent time figuring out where to look and STILL have no idea what to do."
Lodragandraoidh (639696) on Wednesday February 11, 2015 @11:21AM (#49029667)
Re:So roll your own. (Score:5, Insightful)
I think you're missing the point. Linux is the kernel - and it is very stable, and while it has modern extensions, it still
keeps the POSIX interfaces consistent to allow inter-operation as desired. The issue here is not that forks and new versions of
Linux distros are an aberration, but how the major distributions have changed and the article is a symptom of those changes towards
The Linux kernel is by definition identically complex on any distro using a given version of the kernel (the variances created
by compilation switches notwithstanding). The real variance is in the distros - and I don't think variety is a bad thing, particularly
in this day and age when we are having to focus more and more on security, and small applications on different types of devices
- from small ARM processor systems, to virtual cluster systems in data centers.
Variety creates a strong ecosystem that is more resilient to security exploitation as a whole; variety is needed now more than
ever given the security threats we are seeing. If you look at the history of Linux distributions over time - you'll see that from
the very beginning it was a vibrant field with many distros - some that bombed out - some that were forked and then died, and
forks and forks of forks that continued on - keeping the parts that seemed to work for those users.
Today - I think people perceive what is happening with the major distros as a reduction in choice (if Redhat is essentially
identical to Debian, Ubuntu, et al - why bother having different distros?) - a bottleneck in variability; from a security perspective,
I think people are worried that a monoculture is emerging that will present a very large and crystallized attack surface after
the honeymoon period is over.
If people don't like what is available, if they are concerned about the security implications, then they or their friends need
to do something about it. Fork an existing distro, roll your own distro, or if you are really clever - build your own operating
system from scratch to provide an answer, and hopefully something better/different in the long run. Progress isn't a bad thing;
sitting around doing nothing and complaining about it is.
NotDrWho (3543773) on Wednesday February 11, 2015 @11:28AM (#49029739)
Re: So roll your own. (Score:5, Funny)
One man's variety is another man's hopelessly confusing goddamn mess.
Anonymous Coward on Wednesday February 11, 2015 @09:31AM (#49028605)
Re: Yes (Score:4,
Systemd has been the most divisive force in the Linux community lately, and perhaps ever. It has been foisted
upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just
so they can get systems that boot properly.
Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed
of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.
Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should
give the guy a medal.
People are loath to publish new projects because keeping them running with systemd and all its dependencies
in all possible permutations is a full time job. The whole "do one thing only and do it well" concept has been flushed down the
I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7, but install new systems with RHE
<email@example.comCOLAet minus caffeine> on Wednesday February 11, 2015
Who modded this up?
SystemD has put in jeopardy the entire presence of Linux in the server room:1: AFIAK, as there have been zero mention
of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted
on people in RHEL 7 and downstreams with no ability to transition to it.
Formal code testing is pretty much what Redhat brings to the table.
2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications
can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1.
Similar with Solaris.
At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions.
It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing...
and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes
a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has
multiple daemons to separate privs, unlike SystemD.
Do you really understand the architecture of either SystemD or sendmail?
Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs
but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD,
Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on
top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly,
since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on
the systemd web site so I really don't get how you didn't know this.
4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything
including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this
isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.
Unlikely, it is a minority of malcontents
who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done
will not even notice the transition.
5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic
userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.
Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite
all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean
up the horrific mess that was the previous init.
6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we
say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to
Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing
being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.
Solaris has already transitioned
to it's own equivalent daemon that does roughly what SystemD does.
As for SystemD: It allows booting on more complicated hardware. Debian switched because they were losing market share on larger
systems that the current init system only handles under extreme protest. As a side affect of the primary problem it was meant
to solve, it happens to be faster which is great for desktops and uses a lot less memory which is good for embedded systems.
So, all and all, SystemD is the worst thing that has happened with Linux, its reputation, and potentially, its future in 10 years,
since the ACTA treaty was put to rest. SystemD is not production ready, and potentially can put every single box in jeopardy of
a remote root hole.
Riight.. Meanwhile in the real world, none of my desktops or servers have any SystemD related network services
running so no root hole here.
(991472) on Wednesday February 11, 2015 @12:26PM (#49030407)
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It
does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing...
and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes
a solid program.
Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons
to separate privs, unlike SystemD.
Because of course it's been years since anyone found any security holes in well-tested software like Bash or OpenSSL.
Anonymous Coward on Wednesday February 11, 2015 @08:24AM (#49028117)
Re:Why does John shut down all systemd
I was reading through the article's comments and saw
this thread of discussion [complete.org]. Well, it's hard to call it a thread of discussion because John apparently put an
end to it right away.
The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems
with Linux today. I don't use Debian, but I do use another distro that switched to systemd, and it is in fact the problem here.
My workstation doesn't work anywhere as well as it did a couple of years ago, before systemd got installed. So when somebody blames
systemd for these kinds of problems, that person is totally correct. I don't get why John would censor the discussion like that.
I also don't get why he'd label somebody who points out the real problem as being a 'troll'.
John needs to admit that the real problem here is not the people who are against systemd. These people are actually the ones
who are right, and who have the solution to John's problems!
The comment I linked to says 'Systemd needs to be removed from Debian immediately.', and that's totally right. But I think
we need to expand it to 'Systemd needs to be removed from all Linux distros immediately.'
If we want Linux to be usable again, systemd does need to go. It's just as simple as that. Censoring any and all discussion
of the real problem here, systemd, sure isn't going to get these problems resolved any quicker!
Aug 27, 2014
There's a lot to like in the next Red Hat Enterprise Linux, but some fundamental changes may prove problematic By Paul Venezia,
Open Source, Linux,
Red Hat Enterprise Linux
One of the hallmarks of Red Hat Enterprise Linux is that it overwhelmingly favors stability
over currency. As such, RHEL generally ships with packages and frameworks that are years behind the current releases. This is by
design, to ensure that the RHEL distribution is as solid as possible. As an example, Red Hat's slow and steady approach saved RHEL
6.4 users from the
OpenSSL Heartbleed vulnerability because all RHEL versions up to and including that version shipped with a two-year-old version
of OpenSSL that was not affected.
If you follow the Fedora distribution, which serves as the icebreaker for the more stable RHEL distribution, you've seen many
changes coming down the pike for RHEL 7. Many of these changes are the most fundamental we've seen in quite some time. Several are
to be heralded, but others -- notably the replacement of Init and Upstart with Systemd -- are likely to chafe longtime RHEL users
and potentially curb adoption.
Harbinger of the Linux apocalypse | Prove your expertise with the free OS in InfoWorld's
Linux admin IQ test round 1 and
round 2 | Download InfoWorld's
guide to Docker to get started on this red-hot technology. ]
What's new in RHEL 7There is a long list of changes in RHEL 7, but only a few are fundamental. RHEL 7 now uses
Systemd rather than Init scripts for service startup and management -- more on that later. The new default file system is XFS rather
than Ext4, with support of XFS file systems up to 500TB in size. To that end, RHEL 7 now supports Ext4 file systems as large as 50TB.
- Linux containers get a front-row seat in the form of
RHEL can now perform cross-domain trusts with Microsoft Active Directory, so users can authenticate to Linux resources with Active
Directory accounts without the need for synchronization.
- RHEL 7 also includes new monitoring and performance tools. For instance, the Performance Co-Pilot (PCP) provides a new API
for importing, exporting, and processing performance data, while the Tuned daemon provides dynamic system performance tuning.
- On the inside, RHEL 7 incorporates enhanced NUMA affinity features that optimize performance on a per-process level by aligning
processor affinity to RAM location, reducing cross-node communication and improving process performance.
- RHEL 7 offers tighter integration with the VMware vSphere hypervisor via 3D graphics drivers for hardware acceleration with
OpenGL and X11, and Open Virtual Machine Tools, an open source implementation
of VMware Tools that is now a maintained package.
- Open Linux Management Infrastructure (OpenLMI) is now supported. OpenLMI is a framework that allows for common configuration,
management, and monitoring of hardware and software through a remote connection. It provides a standard API that can be used by
any compliant controller to make changes to the server configuration or to monitor the system.
- Other changes include the use of Chrony versus the historical Network Time Protocol daemon for time synchronization, support
for 40GB interfaces, structured logging, and low-latency sockets. A new firewall management interface, Firewalld, now permits
firewall configuration changes without restarting.
- None of these changes or additions will come as much of a surprise to anyone who's been working with Red Hat's Fedora distribution.
But those who working exclusively within the RHEL 5 and RHEL 6 ecosystems are in for a jolt.
Brace for impact Of the myriad changes found in RHEL 7, a few are certain to cause consternation. First and foremost
of those is the move to the Systemd system and process manager. This represents a major departure from Red Hat's -- and Linux's --
history and from the tried-and-true Unix philosophy of using simple, modular tools for critical infrastructure components. Systemd
replaces the simplicity of Init scripts with a major management system that offers new features and capabilities but adds significant
Some of the benefits to Systemd are the parallelized service startup at boot and centralized service management -- and it certainly
shortens boot times.
However, there are decades of admin reflexes to overcome by introducing Systemd, and those tasked with maintaining servers running
RHEL 6 and RHEL 7 releases will quickly tire of the significant administrative differences between them. Red Hat has replicated many
original commands to Systemd commands to address this issue (see the Fedora project's
SysVinit to Systemd Cheatsheet). But at the heart of
the matter, an extremely fundamental part of RHEL server administration is now wildly altered.
To take one example, for 20 years we've been able to issue the chkconfig -list command to show what services are set to start
and at what run level. That command is now systemctl list-unit-files --type=service. For the moment, chkconfig -list still works,
but chides you for not using the systemctl call. In /etc/init.d you'll find only a few scripts and a README.
Both sides of the Systemd
divide have their adherents, but in RHEL 7, the Systemd argument has clearly won. I believe, however, that this will ultimately
rankle many veteran Linux admins, and we may be on the road to a real schism in the RHEL community and in the Linux world at large.
Smoother sailing RHEL7 will integrate
Linux containers solution. Docker is built around the Linux kernel-based virtualization method that permits multiple, isolated virtual
systems, or containers, to run on a single host system. Docker makes it easy to deploy applications and services inside containers
and move them between host systems without requiring specific dependencies or package installations on the target host.
For example, you could create a container on an Ubuntu server that's running a Memcached service and copy that container to an
RHEL server where it would run without alteration. Linux containers and Docker can also run on physical, virtual, or cloud infrastructures,
generally without requiring anything more than the Docker binary installed on the host.
Docker-managed containerization is a big deal for computing in general, and the quick adoption in RHEL 7 shows that Red Hat is
interested in getting on the forefront of this change, rather than backing into it in a later release.
Direct support for Active Directory authentication is another significant update, one that may cause more than a few environments
to finally ditch NIS and existing LDAP authentication mechanisms. RHEL 7 can now function with cross-domain trusts to Microsoft Active
Directory. This means that a user existing only in Active Directory can authenticate to an RHEL 7 server without requiring any synchronization
of user data between the realms.
Thus, environments that have been maintaining multiple authentication mechanisms for their Windows and Linux infrastructures can
now combine them without jumping through too many hoops. There are many shops that still run NIS on Linux, either maintaining a completely
separate authentication realm, or using one of several rather funky methods of combining the two (such as identity synchronization
or using a Windows server as the NIS master).
The addition of Performance Co-Pilot (PCP) should also find many supporters. PCP can collect all kinds of performance metrics
on a server and make them available to any local or remote viewer, even running on other platforms. PCP can also be used to provide
detailed information on application performance. Thorough use of PCP will make troubleshooting intractable server-side problems easier
and offer heightened visibility into the operating state of a server.
Finally, the graphical installation tool Anaconda has received a face-lift. It's much flatter, allowing all pertinent configuration
elements to be set within one screen, rather than through a series of screens separated by Next buttons. Within a few clicks you
can configure the system as you require, then click Install and walk away while that work is done.
On the downside, the package selection is somewhat restricting, separating certain packages by base server selection. For instance,
you can't easily select MariaDB server and client in the Web server grouping, so selecting the elements of a LAMP server will need
to be done after install.
That said, the new installer is clean and slick, and let's face it -- we're not likely to use the installer much these days. We'll
create some templates or images and use those.
RHEL 7 is a fairly significant departure from the expected full-revision release from Red Hat. This is not merely a reskinning
of the previous release with updated packages, a more modern kernel, and some new toolkits and widgets. This is a very different
release than RHEL 6 in any form, mostly due to the move to Systemd.
Though this change has been visible for some time, it will still cause integration problems in a large number of sites with a
significant RHEL installed base. You can expect the adoption of RHEL 7 to be slowed quite a bit in these places, which may push out
the lifecycle of RHEL 5 and RHEL 6 longer than Red Hat may like.
This article, "Review:
RHEL 7 lands with a jolt," was originally published at InfoWorld.com.
Follow the latest developments in Linux,
open source at InfoWorld.com. For the latest
business technology news, follow InfoWorld.com on Twitter.
Read more about data center in InfoWorld's Data