Differences between RHEL 6 and RHEL 7

With systemd RHEL 7 introduced a lot of unnecessary and harmful complexity.
 It also broke compatibility with RHEL 6 sysadmin wise.  Try to postpone  mass deployment till 2020

News The tar pit of Red Hat overcomplexity Recommended Books Recommended Links Installation of Red Hat from a USB drive Installation Differences between RHEL 6 and RHEL 7 Migrating systems from RHN to RHNSM
LVM Modifying ISO image to include kickstart file Kickstart Log rotation in RHEL/Centos/Oracle linux Disabling useless daemons in RHEL 6 servers Disabling useless daemons in RHEL 5 linux servers Disabling RHEL 6 Network Manager Disabling the avahi daemon
Systemd Networking Network Manager overwrites resolv.conf RHEL 6 NTP configuration RHEL handling of DST change RHEL6 registration on proxy protected network RHEL5 registration on proxy protected network Xinetd
Disabling useless daemons in RHEL/Centos/Oracle 6 servers Disabling useless daemons in RHEL/Centos/Oracle 5 servers Certification Program Oracle Linux Changing runlevel when booting with grub Infiniband Subnet Manager Infiniband Installing Mellanox Infiniband Driver on RHEL 6.5
RPM YUM Anaconda VNC-based Installation in Anaconda Cron Wheel Group PAM RHEL handling of DST change
RHEL subscription management RHEL Runlevels RHEL4 registration RHEL5 registration on proxy protected network SELinux Security Disk Management IP address change
Apache NTP SSH rsync  NFS Samba Red Hat Startup Scripts Fedora
 serial console Screen vim Log rotation bash Sendmail VNC/VINO Midnight Commander
Oracle Linux Administration Notes Virtualization Xen Red Hat vs. Solaris Sysadmin Horror Stories Tips Humor Etc

Introduction

 

Without that discipline, too often, software teams get lost in what are known in the field as "boil-the-ocean" projects -- vast schemes to improve everything at once. That can be inspiring, but in the end we might prefer that they hunker down and make incremental improvements to rescue us from bugs and viruses and make our computers easier to use.

Idealistic software developers love to dream about world-changing innovations; meanwhile, we wait and wait for all the potholes to be fixed.

The Mythical Man-Month

Most large organization are not pure RHEL or Suse shop and sysadmin often need to maintain at least two different flavors of linux. So Microsoft Windows 7 - Windows 8 style games that Red Hat decided to play with RHEL 7 was big and unpleasant hit for most system administrators.  Looks like some Red Hat honchos are really envious about Apple success on desktop ;-)

When Red Hat released RHEL 7 in June, 2014 it was a big change. Differences between RHEL 6 and RHEL 7 are as almost as big as differences between RHEL and Suse. That did not come as a shock, as beta  was available since Dec 2013, but still it was big and unpleasant surprise. In organizations who need to maintain both RHEL 7 and RHEL 6 load on sysadmins  effectively doubles.  People need retraining to adapt to those changes and now most companies are extremely scroogy on training (with the exception of banks).   That means that deployment of RHEL 7 should be very slow and reserved for cases where you can do without it. Maintaining both RHEL 6 and RHEL 7 is really painful so it makes sense to try to wait till 2020 when you are forced to switch.

I waited till RHEL 7.3 was released to try it (which is actually a good strategy for any new RHEL version for anybody who is  not beta-addict).  It is always better to wait till other people iron out most bugs inherent in new version ;-)  Usually around third or fifth  release things more or less stabilize. They can destabilize again as happened with Windows X in RHEL 6.6 but this is another story. Level of testing of Redhat releases now is definitely lower, probably because the system now is so complex.

In any case the key message is that RHEL 7 is very different from RHEL 6. I've been feeling like I'm re-learning a totally new flavor of Linux like is the case with Red Hat and Suse.

To a certain extent RHEL 7 can be viewed as example of ego-driven vandalism, when the desire to scratch your own itch degenerate in desire to make changes based on the attitude "I am right and f*ck you all". This type of behaviour was actually observed multiple time in linux ecosphere, but  never on such tremendous scale.

Red Hat enterprise and Red Hat for HPC are supposed to be a serious, stable, useful operating system. A step up in comparison with CentOS. I do not see that happening.  Red Hat 7.3 (I did nor check earlier version) is still a poor choice for Enterprise IT because of excessive complexity. Which by-and-large was introduced via systemd.  Attempt to emulate Solaris zones is nice, but this is a little bit "too little too late." Still makes perfect sense for web server farms, etc. 

I can't think of a single reason why any sysadmin who know RHEL 6 well should waste time with this distro.  But in reality you have no choice. Still my recommendation is to prolong life of RHEL 6 till 2020 by all means that you have in your disposal. Unless you heavily deled  on light-weight VMs for critical business tasks, IMHO RHEL 7 does not add anything really new and interesting  to the enterprise mix and it is substantially different to cause a lot of headaches during regular administration.  Your mileage may vary.

NOTES:

Installation

Anaconda was completely redesigned. And it was not improved, it  was just changes in cosmetics and cutting the number of screen you need to view  to get OS installed. There  are also some positive changes -- better detecting of network cards.   The whole install process was simplified it, at the same time was "windownized" and dumbed down. may be there is advanced option, I do not know. In dumped down version there are dramatically less screens during installation but also less capabilities to tune  the OS configuration to your liking. 

BTW "server with GUI" as an installation option is now understood by Red Hat as something like desktop and you are asked stupid questions like connecting to Google or Facebook after installation finishes and the box reboots. Webserver is a better deal. You can shut down the server later if you do not need it.  At the beginning when you still do not know the4 ropes you might wish to disable security policy during the installation as SElinux sometimes interferes with certain types of ssh login (typically passwordless login. 

It looks like you no longer can select a specific set of packages with the groups of packages you need. Only groups are selectable (http server etc).  This is a minor issue as additional packages can always be installed after the installation, but still that means that you need to do more work with your kickstart file to make it do what you want on other servers in a group after you manually installed the first one. 

New Anaconda remains reasonably flexible. For example, if you are on VPN, then during the installation you can boot from small "boot image" and then change the location of the repository to full ISO located on your local HTTP server. For example, if you select 'Server with GUI" installation option anaconda blindly installs pulseaudio even, if there is no sound card on the server (is it so difficult to check ?).  Selecting Web server is a better deal in this respect.  

Manual installation of OS of multiple, slightly different variants of OS remains very boring, and uninspiring. A better deal is to get kickstart for basic system and then install the necessary packages (after you registered the system) using your custom scripts. There is no any capability of macro recoding of your keystrokes to ftp , NFS or similar  remote filesystem. Only kickstart  file that (only partially) reflects your choices (and which actually changes your intent somewhat in case you want to install another similar  box, not to re-install the same server).

You can select some minimal number of settings and hope for best (if you do not know their results beforehand). Then you wait for packages installed with with fast local connection takes 5-10 minutes and reboot the box.

Around 1200 packages are installed in Web server with GUI case. Which is way too much.  Of them probably 20% are redundant for the server, so you should never select this option.  "Webserver" in most cases is a better deal if you want GUI to be present. The slideshow Red Hat provides during the GUI-based  installation is shameless advertizing and should be called the slimeshow.

Gnome is meant to be light, right? Wrong!  Of cause consumption of CPU on 28 core box with 256GB of memory is not that noticeable but in no way this is a alight application.

This behaviour of Anaconda also means that you need to copy ISO immediately after the reboot and install missing packages ( and probably try to remove redundant) from RPM using your own scripts. 

But all-in-all troubles with Anaconda are a minor nuisance.

On a positive side it looks like Anaconda recognizes the network cards better and is capable to tell which interface is wired.  That's an important plus.

Systemd introduces a lot of unnecessary complexity and is a huge headache
as large part of your skills of managing daemons and runlevels is now obsolete

The list of systemd entries brings us 383 unit files which is far too excessive.

The main problem with systems from purely syntax perspective is that it creates mental conflict with your RHEL6 skills and typical commands like chkconfig --list Thanks  god service network restart  are still emulated because those commands are etched in your brain.

Still differences in system files clocation and content are enough to create the situation that if you manage both RHEL 7 and  RHEL 6 servers, then in order to preserve sanity you might wish to write a wrapper, name for those utilities that differ drastically.

For example to emulate chkconfig --list you need to write a screp, say,  sysconfig.pl amd put in /root/bin Then you need to define "version sensitive" shell wrapper and put it in your . bashrc.  Something like:

function chkconfig
if egrep ' [4-6]\.[0-9]+ ' /etc/redhat-release ; then 
    /sbin/chkconfig $@
else 
   /root/bin/sysconfig.pl $@
fi

A very simple wrapper that I wrote in Perl can be found here.

Differences in system files are considerable and make many scripts written for RHEL 6 and earlier versions  obsolete

If your "smart provisioning" of servers was based on kickstart you need iether to revise your scripts or provide symlink to old locations for commonly used in scripts utilities

Location of most utilities including bash changed from /bin and /sbin to /usr/bin and /usr/sbin, respectivly

Typically location of utilities in Unix scripts is abstracted with "indirection layer" by introducing for each utility a variable with full path to particular utility, for example

DF=`/bin/df`
or even
DF=`which df`
so you can write a script to modify all your scripts to RHEL 7 conventions.  But if your scripts are inconsistent in this respect (my where) they need to be manually revized and that should be done  one by one.

There are substantial differences in most common daemons. Iptables and ntpd were replaced

Differences in authentication

Password authentication files (/etc/passwd, /etc/group, /etc/shadow, /etc/gshadow) format and location did not  change. Within /etc/passwd system user UID range was extended from 0-499 to 0-999

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. This is a plus.

Default file system now is XFS

Default file system now is XFS and that is definitely a positive change.

XFS was available as an option in RHEL6 (default in RHEL6 is Ext4) so for those sysadmins who know what they are doing this  is not a news. XFS is superior to EXT line of filesystems in most areas, Only for very small partitions like /boot ext2 have an edge.

What is important is that this filesystem has usable dump and restore utilities. So "by partition" backup can  be done using utilities supplied with the system. 

runlevels are called as "targets" as shown below:

runlevel0.target -> poweroff.target
runlevel1.target -> rescue.target
runlevel2.target -> multi-user.target
runlevel3.target -> multi-user.target
runlevel4.target -> multi-user.target
runlevel5.target -> graphical.target
runlevel6.target -> reboot.target

Summary of changes
(adapted from SysAdminView)

Features RHEL 7 RHEL 6
Kernel Version/Code Name 3.10.x-x kernel / Maipo 2.6.x-x Kernel / Santiago
Default File System XFS EXT4
Process ID systemd (process ID 1) init (process ID 1)
Runlevel runlevel0.target -> poweroff.target
runlevel1.target -> rescue.target
runlevel2.target -> multi-user.target
runlevel3.target -> multi-user.target
runlevel4.target -> multi-user.target
runlevel5.target -> graphical.target
runlevel6.target -> reboot.target/etc/systemd/system/default.target(this by default is linked to the multi-user target)
runlevel 0
runlevel 1
runlevel 2
runlevel 3
runlevel 4
runlevel 5
runlevel 6and the default runlevel would be defined in /etc/inittab file.
Boot Loader GRUB 2
Supports GPT, additional firmware types, including BIOS, EFI and OpenFirmwar. Ability to boot on various file systems(xfs, ext4, ntfs, hfs+, raid, etc)
GRUB 0.97
System & Service Manager Systemd Upstart
Enable/Start Service Enable Services: “systemctl enable httpd.service

Start Services: “systemctl start httpd.service

Enable Services: “chkconfig httpd on

Start Services: “service start httpd
or “/etc/init.d/httpd start

Maximum File Size Supported XFS is the  default filesyste
  • Individual File Size = 500 TB(Maximum)
  • Filesystem Size = 500 TB (Maximum)

RHEL 7 Supports only 64-bit machines

Ext4 is the default filasystem, XFS is availble as option.

EXT4 Individual File Size = 16 TB (Maximum)
Filesystem Size (64-bit machine) = 16 TB (Maximum)Filesystem Size (32-bit machine)  = 8 TB (Maximum)
RHEL 6 Supports both 32 and 64-bit machines

File System Structure /sbin, /bin, /lib and /lib64 are under /usr. /sbin, /bin, /lib and /lib64 are under /
File System Check xfs_repair

XFS does not check file system while boot time

e2fsck

File System check would executed while boot time

Differences Between xfs_repair & e2fsck “xfs_repair”
– Inode and inode blockmap (addressing) checks.
– Inode allocation map checks.
– Inode size checks.
– Directory checks.
– Pathname checks.
– Link count checks.
– Freemap checks.
– Super block checks.
“e2fsck”
– Inode, block, and size checks.
– Directory structure checks.
– Directory connectivity checks.
– Reference count checks.
– Group summary info checks.
Difference Between xfs_growfs & resize2fs “xfs_growfs”
xfs_growfs takes mount point as arguments.
“resize2fs”
resize2fs takes logical volume name as arguments.
Desktop/GUI Interface GNOME3 and KDE 4.10 GNOME2
Host Name Change Hostname Variable is defined in /etc/hostname configuration file Hostname Variable is defined in /etc/sysconfig/network.
UID Allocation By default UID 1000 assigned to any new user. This could be changed in /etc/login.defs if required. By default UID 500 assigned to any new user. This could be changed in /etc/login.defs if required.
Firewall Firewalld / IP tables IP tables
Network Bonding “Team Driver”

/etc/sysconfig/network-scripts/ifcfg-team0
DEVICE=”team0”
DEVICETYPE=”Team”

“Bonding”

-/etc/sysconfig/network-scripts/ifcfg-bond0
– DEVICE=”bond0”

NFS NFSv3, NFSv4.0, and NVSv4.1 clients.                                                        NFSv2 is no longer supported NFS4
Time Synchronization Using Chrony suite (Faster sync when compare with ntpd) ntpd
Cluster Resource Manager Pacemaker Rgmanager
Load Balancer Technology Keepalived and HAProxy Piranha
Default Database MariaDB is the default implementation of MySQL MySQL
Managing Temporary Files systemd-tmpfiles tmpwatch

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Aug 14, 2017] Are 32-bit applications supported in RHEL 7?

Aug 14, 2017 | access.redhat.com
Solution Verified - Updated June 1 2017 at 1:22 PM -

Environment

Issue Resolution

Red Hat Enterprise Linux 7 does not support installation on i686, 32 bit hardware. ISO installation media is only provided for 64-bit hardware. Refer to Red Hat Enterprise Linux technology capabilities and limits for additional details.

However, 32-bit applications are supported in a 64-bit RHEL 7 environment in the following scenarios:

While RHEL 7 will not natively support 32-bit hardware, certified hardware can be searched for in the certified hardware database .

[Aug 14, 2017] CentOS-RHEL - WineHQ Wiki

Aug 14, 2017 | wiki.winehq.org

Notes on EPEL 7

At the time of this writing, EPEL 7 still has no 32-bit packages (including wine and its dependencies). There is a 64-bit version of wine, but without the 32-bit libraries needed for WoW64 capabilities, it cannot support any 32-bit Windows apps (the vast majority) and even many 64-bit ones (that still include 32-bit components).

This is primarily because with release 7, Red Hat didn't have enough customer demand to justify an i386 build. While Red Hat itself still comes with lean multilib and 32-bit support for legacy needs, this is part of Red Hat's release process, not the packages themselves. Therefore CentOS 7 had to develop its own workflow for building an i386 release, a process that was completed in Oct 2015 .

With its i386 release, CentOS has cleared a major hurdle on the way to an EPEL with 32-bit libraries, and now the ball is in the Fedora project's court (as the maintainers of the EPEL). Once a i386 version of the EPEL becomes available, you should be able to follow the same instructions above to install a fully functional wine package for CentOS 7 and its siblings.

Thankfully, this also means that EPEL 8 shouldn't suffer from this same problem. In the meantime though, you can keep reading for some hints on getting a recent version of wine from the source code.

Special Considerations for Red Hat

Those with a Red Hat subscription should have access to enhanced help and support, but we wanted to provide some very quick notes on enabling the EPEL for your system. Before installing the epel-release package, you'll first need to activate some additional repositories.

On release 6 and older, which used the Red Hat Network Classic system for package subscriptions, you need to activate the optional repo with rhn-channel

rhn-channel -a -c rhel-6-server-optional-rpms -u <your-RHN-username> -p <your-RHN-password>

Starting with release 7 and the Subscription Manager system, you'll need to activate both the optional and extras repos with subscription-manager

subscription-manager repos --enable=rhel-7-server-optional-rpms
subscription-manager repos --enable=rhel-7-server-extras-rpms

As for source RPMs signed by Red Hat, there doesn't seem to be much public-facing documentation. With a subscription, you should be able to login and browse the repos ; this post on LWN also has some background.

[Aug 14, 2017] CentOS 6 or CentOS 7

Aug 14, 2017 | www.lowendtalk.com

[Aug 13, 2017] Differences Between RHEL 7 and RHEL 6 - SysAdminView

Features RHEL 7 RHEL 6
Kernel Version/Code Name 3.10.x-x kernel / Maipo 2.6.x-x Kernel / Santiago
Default File System XFS EXT4
Process ID systemd (process ID 1) init (process ID 1)
Runlevel runlevel0.target -> poweroff.target
runlevel1.target -> rescue.target
runlevel2.target -> multi-user.target
runlevel3.target -> multi-user.target
runlevel4.target -> multi-user.target
runlevel5.target -> graphical.target
runlevel6.target -> reboot.target/etc/systemd/system/default.target(this by default is linked to the multi-user target)
runlevel 0
runlevel 1
runlevel 2
runlevel 3
runlevel 4
runlevel 5
runlevel 6and the default runlevel would be defined in /etc/inittab file.
Boot Loader GRUB 2
Supports GPT, additional firmware types, including BIOS, EFI and OpenFirmwar. Ability to boot on various file systems(xfs, ext4, ntfs, hfs+, raid, etc)
GRUB 0.97
System & Service Manager Systemd Upstart
Enable/Start Service Enable Services: “systemctl enable httpd.service

Start Services: “systemctl start httpd.service

Enable Services: “chkconfig httpd on

Start Services: “service start httpd
or “/etc/init.d/httpd start

Maximum File Size Supported XFS is the default filesyste
  • Individual File Size = 500 TB(Maximum)
  • Filesystem Size = 500 TB (Maximum)

RHEL 7 Supports only 64-bit machines

Ext4 is the default filasystem, XFS is availble as option.

EXT4 Individual File Size = 16 TB (Maximum)
Filesystem Size (64-bit machine) = 16 TB (Maximum)Filesystem Size (32-bit machine) = 8 TB (Maximum)
RHEL 6 Supports both 32 and 64-bit machines

File System Structure /sbin, /bin, /lib and /lib64 are under /usr. /sbin, /bin, /lib and /lib64 are under /
File System Check xfs_repair

XFS does not check file system while boot time

e2fsck

File System check would executed while boot time

Differences Between xfs_repair & e2fsck “xfs_repair”
– Inode and inode blockmap (addressing) checks.
– Inode allocation map checks.
– Inode size checks.
– Directory checks.
– Pathname checks.
– Link count checks.
– Freemap checks.
– Super block checks.
“e2fsck”
– Inode, block, and size checks.
– Directory structure checks.
– Directory connectivity checks.
– Reference count checks.
– Group summary info checks.
Difference Between xfs_growfs & resize2fs “xfs_growfs”
xfs_growfs takes mount point as arguments.
“resize2fs”
resize2fs takes logical volume name as arguments.
Desktop/GUI Interface GNOME3 and KDE 4.10 GNOME2
Host Name Change Hostname Variable is defined in /etc/hostname configuration file Hostname Variable is defined in /etc/sysconfig/network.
UID Allocation By default UID 1000 assigned to any new user. This could be changed in /etc/login.defs if required. By default UID 500 assigned to any new user. This could be changed in /etc/login.defs if required.
Firewall Firewalld / IP tables IP tables
Network Bonding “Team Driver”

/etc/sysconfig/network-scripts/ifcfg-team0
DEVICE=”team0”
DEVICETYPE=”Team”

“Bonding”

-/etc/sysconfig/network-scripts/ifcfg-bond0
– DEVICE=”bond0”

NFS NFSv3, NFSv4.0, and NVSv4.1 clients. NFSv2 is no longer supported NFS4
Time Synchronization Using Chrony suite (Faster sync when compare with ntpd) ntpd
Cluster Resource Manager Pacemaker Rgmanager
Load Balancer Technology Keepalived and HAProxy Piranha
Default Database MariaDB is the default implementation of MySQL MySQL
Managing Temporary Files systemd-tmpfiles tmpwatch

[Jul 24, 2017] RHEL 6 vs RHEL 7 Difference Between Previous and Newer Version by ARK

Red Hat Enterprise Linux 7 is an major / drastic change to enterprise. To serve / meet today’s business critical application performance RHEL 7 is the best Operating system to use, very light weight and container based. In this article we are going to see RHEL 6 vs RHEL 7 Difference Between Previous and Newer Version. RHEL 7 vs RHEL 6.

What’s Changed in RHEL 7 Administration side

RHEL 6 vs RHEL 7 Difference

Feature Name RHEL 6 RHEL 7
Default File System Ext4 XFS
Kernel Version 2.6.xx 3.10.xx
Release Name Santiago Maipo
Gnome Version GNOME 2 GNOME 3.8
KDE Version KDE 4.1 KDE 4.6
Release Date Wednesday, November 10, 2010 Tuesday, June 10, 2014
NFS Version NFS 4 NFS 4.1. NFS V2 is deprecated in RHEL 7
Samba Version SMB 3.6 SMB 4.4
Default Database MySQL MariaDB
Cluster Resource Manager Rgmanager Pacemaker
Network Interface Grouping Bonding can be done as Active-Backup, XOR, IEEE and Load Balancing Team Driver will support multiple types of Teaming methods called Active-Backup, Load-balancing and Broadcast
KDUMP Kdump does’t support with large RAM Size RHEL 7 can be supported up to 3TB
Boot Loader Grub 2
/boot/grub2/grub.cfg
Grub 0.97
/boot/grub/grub.conf
File System Check e2fsck
-Inode check. Block and size check
–Directory Structure check
-Directory Link Check
-reference count check
-Group Summary Check
xfs_replair
– Inode blockmap checks
-Inode allocation map checks
-Inode size check
-Directory check
-Path Name check
-Link count check
-Freemap check
-Super block check
Process ID Initd Process ID 1 Systemd Process ID 1
Port Security Iptables by default service port is enabled when service is switched on. Firewalld instead of iptables. Iptables can also support with RHEL 7, but we can’t use both of them at the same time. Firewall will not allow any port until and unless you enabled it.
Boot Time 40 Sec 20 Sec
File System Size EXT4 16TB with XFS 100TB XFS 500TB with EXT4 16TB
Processor Architecture 32Bit and 64Bit Only 64Bit.
Network Configuration Tool setup nmtui
Host name Config File /etc/sysconfig/network /etc/hostname No need to edit hostname file to write permanent hostname simply use hostnamectl command
Interface Name eth0 ens33xxx
Managing Services service sshd start
service sshd restart
chkconfig sshd on
systemctl start sshd.service
systemctl restart sshd.service
systemctl enable sshd.service
System Logs /var/log/ /var/log
journalctl
Run Levels runlevel 0 – Power Off
runlevel 1 – Single User Mode
runlevel 2 – Multi User without Networking
runlevel 3 – Multi User CLI
runlevel 4 – Not USed
runlevel 5 – GUI Mode
runlevel 6 – Restart
There is no run levels in RHEL 7. Run levels are called as targets
Poweroff.target
rescue.target
multi-user.target
graphical.target
reboot.target
UID Information Normal User UID will start from 500 to 65534
System Users UID will start from 1 to 499
Normal User UID start from 1000 – 65534
System Users UID will start from 1 to 999Because Services are increased compare to RHEL 6
By Pass Root Password Prompt append 1 or s or init=/bin/bash to Kernel command line Append rd.break or init=/bin/bash to kernel command line
Rebooting and Poweroff poweroff – init 0
reboot – init 6
systemctl poweroff
systemctl reboot
YUM Commands yum groupinstall
yum groupinfo
yum group install
yum group info
Newly Introduced Features in RHEL 7
  1. No More 32-bit installation packages
  2. Docker is an Open Source Project, it helps to deploy applications inside Linux containers.

Thanks for the Read, Please Provide your valuable feedback on the same. RHEL 6 vs RHEL 7

Conclusion: There are lot many changes out of all few are listed above. For complete and detailed information please read Red Hat enterprise Linux 7 release notes. Download this Complete Changes list

[Apr 15, 2015] Is Modern Linux Becoming Too Complex

One man's variety is another man's hopelessly confusing goddamn mess.

Feb 11, 2015 | Slashdot

An anonymous reader writes: Debian developer John Goerzen asks whether 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 homogeneity.

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, Insightful)

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.

Re:
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 drain.

I know that I am not the only sysadmin who refuses to install Red Hat Enterprise Linux 7, but install new systems with RHE

gmack (197796) <gmack@innerfire.nCOLAet minus caffeine> on Wednesday February 11, 2015 @11:55AM (#49030073) Homepage Journal

Score:4, Informative)

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.

Dragonslicer (991472) on Wednesday February 11, 2015 @12:26PM (#49030407)

Score:5, Insightful)

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)

Score:5, Interesting)

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!

Re:Why does John shut down all systemd talk? (Score:5, Insightful)

[Aug 27, 2014] Review RHEL 7 lands with a jolt

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.

[ Systemd: 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 beginner'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.

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 complexity.

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 Docker, the 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, data center, virtualization, and 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 Center Channel.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: August, 16, 2017