Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

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. 

News The tar pit of Red Hat overcomplexity RHEL7 documentation Recommended Links Systemd Systemd Cheatsheet Differences between RHEL 6 and RHEL 7 Migrating systems from RHN to RHNSM
Registering a server using Red Hat Subscription Manager (RHSM) Configuring network in RHEL7 Bonding Ethernet Interfaces in RHEL 7 Log rotation in RHEL/Centos/Oracle linux Installation and configuration of NFS in RHEL7     Disabling the avahi daemon
Installation Kickstart Modifying ISO image to include kickstart file Recover the Root Password in RHEL 7       Xinetd
Networking Linux ip command Network Manager overwrites resolv.conf Linux route command RHEL handling of DST change Infiniband Subnet Manager Infiniband Installing Mellanox Infiniband Driver on RHEL 6.5
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      
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 Sysadmin Horror Stories Systemd Tips 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". May be there is advanced option, I do not know. In windonized/bastardized 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. That means that Webserver is a better deal as infrastructure server option. You can shut down the HTTP server later if you do not need it. 

At the beginning when you still do not know the 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 and select package within the group like version  of Anaconda used in RHEL6. You now operate on a very primitive level of groups of packages. Only some 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. 

It looks like in RHEL7 version of anaconda you no longer can select a specific set of packages and select RPMs within the group as  version  of Anaconda used in RHEL6.

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.

Changes in existing semantic

  We're an empire now, and when we act, we create our own reality.

And while you're studying that reality—judiciously, as you will—we'll act again, creating other new realities, which you can study too, and that's how things will sort out.

We're history's actors … and you, all of you, will be left to just study what we do."

Karl Rove - Wikiquote

In previous version of RHEL (and all other Linux and Unix  flavors) if you exit from your terminal session (or it was kiiled) all processes which were started within this terminal session will be killed too, even if you are running them in the background

In case of systemd putting the process into background is somewhat similar  to putting the process into background plus prefixing it  with the nohup command in "old" Linuxes. nohup detaches the process (daemonizes it), preventing the shell from killing child processes on exit.

nohup behaviour is now default for the background processes in systems with  systemd like RHEL7 in case you disconnect the terminal. Your background process will survive the terminal disconnect but in some kind of "managed zombie stage":  they are not like screen sessions which you can re-attach to any new terminal you wish. You can't reattach them to a different terminal and a new session for the same user does not list them in output of the jobs command.

On the other hand systemd introduces a plethora of settings which affects program like tmux and by default system can display  "excessive zeal" killing tmux  session after disconnect from of the terminal.  that also man that depending on setting systemd behaviour in this important areacan vary from one system to another creating Alice in Wonderland situation

How to run tmux/screen with systemd > 230?

Aug 02, 2018  | askubuntu.com

MvanGeest ,May 10, 2017 at 20:59

I run 16.04 and systemd now kills tmux when the user disconnects ( summary of the change ).

Is there a way to run tmux or screen (or any similar program) with systemd 230? I read all the heated disussion about pros and cons of the behaviors but no solution was suggested.

(I see the behaviour in 229 as well)

WoJ ,Aug 2, 2016 at 20:30

RemainAfterExit=

Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no.

jpath, Feb 13 at 12:29

The proper solution is to disable the offending systemd behavior system-wide.

Edit /etc/systemd/logind.conf ( you must sudo , of course) and set

KillUserProcesses=no

You can also put this setting in a separate file, e.g. /etc/systemd/logind.conf.d/99-dont-kill-user-processes.conf .

Then restart systemd-logind.service .

sudo systemctl restart systemd-logind

sarnold, Dec 9, 2016 at 11:59

Based on @Rinzwind's answer and inspired by a unit description the best I could find is to use TaaS (Tmux as a Service) - a generic detached instance of tmux one reattaches to. 
# cat /etc/systemd/system/[email protected]

[Unit]
Description=tmux default session (detached)
Documentation=man:tmux(1)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/tmux new-session -d -s %I
ExecStop=/usr/bin/tmux kill-server
KillMode=none

[Install]
WantedBy=multiplexer.target

# systemctl start [email protected]
# systemctl start [email protected]
# tmux list-sessions

instanceone: 1 windows (created Sun Jul 24 00:52:15 2016) [193x49]
instancetwo: 1 windows (created Sun Jul 24 00:52:19 2016) [193x49]

# tmux attach-session -t instanceone

(instanceone)#

Robin Hartmann ,Aug 2, 2018 at 20:23

You need to set the Type of the service to forking , as explained here .

Let's assume the service you want to run in screen is called minecraft . Then you would open minecraft.service in a text editor and add or edit the entry Type=forking under the section [Service] .

According to https://unix.stackexchange.com/a/287282/117599 invoking tmux using 
systemd-run --user --scope tmux

should also do the trick.

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, respectively

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, which is logical and reminds me the arrangement for TPC privileged ports.

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 ;-)

[Mar 28, 2021] How to Disable SELinux on RHEL 8 by Josphat Mutai

Jan 26, 2019 | computingforgeeks.com

... ... ...

Before disabling SELinux, check first its mode of operation using the command sestatus.

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

The default mode in RHEL 8 is Enforcing . In this mode, SELinux policy is enforced and it denies access based on SELinux policy rules.

The other available mode for running SELinux in enabled state is Permissive. In this mode, SELinux policy is not enforced and access is not denied but denials are logged for actions that would have been denied if running in enforcing mode.

To permanently disable SELinux. edit its main configuration file /etc/selinux/config and set:

SELINUX=disabled

it will take effect affter the reboot. To work in disabled mode and postpone reboot, just set the current mode to Permissive in runtime.

sudo setenforce 0

[Dec 10, 2020] Disable Boot Splash screen in Centos - smtsang

Dec 10, 2020 | smtsang.wordpress.com

To try CentOS 6 display the details about what its doing while it boots, first we need to make a backup of the file at /etc/grub.conf in case there is something goes wrong. Then open /etc/grub.conf in the editor, and look for the line(s) that begin with 'kernel'.

At the end of line is shown 'rhgb' and 'quiet'. Remove both of those words from grub.conf. After saving the changes, reboot the server and it will see everything its doing when it starts up.

[Nov 08, 2019] Manage NTP with Chrony by David Both

Dec 03, 2018 | opensource.com

Chronyd is a better choice for most networks than ntpd for keeping computers synchronized with the Network Time Protocol.

"Does anybody really know what time it is? Does anybody really care?"
– Chicago , 1969

Perhaps that rock group didn't care what time it was, but our computers do need to know the exact time. Timekeeping is very important to computer networks. In banking, stock markets, and other financial businesses, transactions must be maintained in the proper order, and exact time sequences are critical for that. For sysadmins and DevOps professionals, it's easier to follow the trail of email through a series of servers or to determine the exact sequence of events using log files on geographically dispersed hosts when exact times are kept on the computers in question.

I used to work at an organization that received over 20 million emails per day and had four servers just to accept and do a basic filter on the incoming flood of email. From there, emails were sent to one of four other servers to perform more complex anti-spam assessments, then they were delivered to one of several additional servers where the emails were placed in the correct inboxes. At each layer, the emails would be sent to one of the next-level servers, selected only by the randomness of round-robin DNS. Sometimes we had to trace a new message through the system until we could determine where it "got lost," according to the pointy-haired bosses. We had to do this with frightening regularity.

Most of that email turned out to be spam. Some people actually complained that their [joke, cat pic, recipe, inspirational saying, or other-strange-email]-of-the-day was missing and asked us to find it. We did reject those opportunities.

Our email and other transactional searches were aided by log entries with timestamps that -- today -- can resolve down to the nanosecond in even the slowest of modern Linux computers. In very high-volume transaction environments, even a few microseconds of difference in the system clocks can mean sorting thousands of transactions to find the correct one(s).

The NTP server hierarchy

Computers worldwide use the Network Time Protocol (NTP) to synchronize their times with internet standard reference clocks via a hierarchy of NTP servers. The primary servers are at stratum 1, and they are connected directly to various national time services at stratum 0 via satellite, radio, or even modems over phone lines. The time service at stratum 0 may be an atomic clock, a radio receiver tuned to the signals broadcast by an atomic clock, or a GPS receiver using the highly accurate clock signals broadcast by GPS satellites.

To prevent time requests from time servers lower in the hierarchy (i.e., with a higher stratum number) from overwhelming the primary reference servers, there are several thousand public NTP stratum 2 servers that are open and available for anyone to use. Many organizations with large numbers of hosts that need an NTP server will set up their own time servers so that only one local host accesses the stratum 2 time servers, then they configure the remaining network hosts to use the local time server which, in my case, is a stratum 3 server.

NTP choices

The original NTP daemon, ntpd , has been joined by a newer one, chronyd . Both keep the local host's time synchronized with the time server. Both services are available, and I have seen nothing to indicate that this will change anytime soon.

Chrony has features that make it the better choice for most environments for the following reasons:

The NTP and Chrony RPM packages are available from standard Fedora repositories. You can install both and switch between them, but modern Fedora, CentOS, and RHEL releases have moved from NTP to Chrony as their default time-keeping implementation. I have found that Chrony works well, provides a better interface for the sysadmin, presents much more information, and increases control.

Just to make it clear, NTP is a protocol that is implemented with either NTP or Chrony. If you'd like to know more, read this comparison between NTP and Chrony as implementations of the NTP protocol.

This article explains how to configure Chrony clients and servers on a Fedora host, but the configuration for CentOS and RHEL current releases works the same.

Chrony structure

The Chrony daemon, chronyd , runs in the background and monitors the time and status of the time server specified in the chrony.conf file. If the local time needs to be adjusted, chronyd does it smoothly without the programmatic trauma that would occur if the clock were instantly reset to a new time.

Chrony's chronyc tool allows someone to monitor the current status of Chrony and make changes if necessary. The chronyc utility can be used as a command that accepts subcommands, or it can be used as an interactive text-mode program. This article will explain both uses.

Client configuration

The NTP client configuration is simple and requires little or no intervention. The NTP server can be defined during the Linux installation or provided by the DHCP server at boot time. The default /etc/chrony.conf file (shown below in its entirety) requires no intervention to work properly as a client. For Fedora, Chrony uses the Fedora NTP pool, and CentOS and RHEL have their own NTP server pools. Like many Red Hat-based distributions, the configuration file is well commented.

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking

Let's look at the current status of NTP on a virtual machine I use for testing. The chronyc command, when used with the tracking subcommand, provides statistics that report how far off the local system is from the reference server.

[root@studentvm1 ~]# chronyc tracking
Reference ID : 23ABED4D (ec2-35-171-237-77.compute-1.amazonaws.com)
Stratum : 3
Ref time (UTC) : Fri Nov 16 16:21:30 2018
System time : 0.000645622 seconds slow of NTP time
Last offset : -0.000308577 seconds
RMS offset : 0.000786140 seconds
Frequency : 0.147 ppm slow
Residual freq : -0.073 ppm
Skew : 0.062 ppm
Root delay : 0.041452706 seconds
Root dispersion : 0.022665167 seconds
Update interval : 1044.2 seconds
Leap status : Normal
[root@studentvm1 ~]#

The Reference ID in the first line of the result is the server the host is synchronized to -- in this case, a stratum 3 reference server that was last contacted by the host at 16:21:30 2018. The other lines are described in the chronyc(1) man page .

The sources subcommand is also useful because it provides information about the time source configured in chrony.conf .

[root@studentvm1 ~]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 6 377 0 -2613us[-2613us] +/- 63ms
^+ dev.smatwebdesign.com 3 10 377 28m -2961us[-3534us] +/- 113ms
^+ propjet.latt.net 2 10 377 465 -1097us[-1085us] +/- 77ms
^* ec2-35-171-237-77.comput> 2 10 377 83 +2388us[+2395us] +/- 95ms
^+ PBX.cytranet.net 3 10 377 507 -1602us[-1589us] +/- 96ms
[root@studentvm1 ~]#

The first source in the list is the time server I set up for my personal network. The others were provided by the pool. Even though my NTP server doesn't appear in the Chrony configuration file above, my DHCP server provides its IP address for the NTP server. The "S" column -- Source State -- indicates with an asterisk ( * ) the server our host is synced to. This is consistent with the data from the tracking subcommand.

The -v option provides a nice description of the fields in this output.

[root@studentvm1 ~]# chronyc sources -v
210 Number of sources = 5

.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 7 377 28 -2156us[-2156us] +/- 63ms
^+ triton.ellipse.net 2 10 377 24 +5716us[+5716us] +/- 62ms
^+ lithium.constant.com 2 10 377 351 -820us[ -820us] +/- 64ms
^* t2.time.bf1.yahoo.com 2 10 377 453 -992us[ -965us] +/- 46ms
^- ntp.idealab.com 2 10 377 799 +3653us[+3674us] +/- 87ms
[root@studentvm1 ~]#

If I wanted my server to be the preferred reference time source for this host, I would add the line below to the /etc/chrony.conf file.

server 192.168.0.51 iburst prefer

I usually place this line just above the first pool server statement near the top of the file. There is no special reason for this, except I like to keep the server statements together. It would work just as well at the bottom of the file, and I have done that on several hosts. This configuration file is not sequence-sensitive.

The prefer option marks this as the preferred reference source. As such, this host will always be synchronized with this reference source (as long as it is available). We can also use the fully qualified hostname for a remote reference server or the hostname only (without the domain name) for a local reference time source as long as the search statement is set in the /etc/resolv.conf file. I prefer the IP address to ensure that the time source is accessible even if DNS is not working. In most environments, the server name is probably the better option, because NTP will continue to work even if the server's IP address changes.

If you don't have a specific reference source you want to synchronize to, it is fine to use the defaults.

Configuring an NTP server with Chrony

The nice thing about the Chrony configuration file is that this single file configures the host as both a client and a server. To add a server function to our host -- it will always be a client, obtaining its time from a reference server -- we just need to make a couple of changes to the Chrony configuration, then configure the host's firewall to accept NTP requests.

Open the /etc/chrony.conf file in your favorite text editor and uncomment the local stratum 10 line. This enables the Chrony NTP server to continue to act as if it were connected to a remote reference server if the internet connection fails; this enables the host to continue to be an NTP server to other hosts on the local network.

Let's restart chronyd and track how the service is working for a few minutes. Before we enable our host as an NTP server, we want to test a bit.

[root@studentvm1 ~]# systemctl restart chronyd ; watch chronyc tracking

The results should look like this. The watch command runs the chronyc tracking command every two seconds so we can watch changes occur over time.

Every 2.0s: chronyc tracking studentvm1: Fri Nov 16 20:59:31 2018

Reference ID : C0A80033 (192.168.0.51)
Stratum : 4
Ref time (UTC) : Sat Nov 17 01:58:51 2018
System time : 0.001598277 seconds fast of NTP time
Last offset : +0.001791533 seconds
RMS offset : 0.001791533 seconds
Frequency : 0.546 ppm slow
Residual freq : -0.175 ppm
Skew : 0.168 ppm
Root delay : 0.094823152 seconds
Root dispersion : 0.021242738 seconds
Update interval : 65.0 seconds
Leap status : Normal

Notice that my NTP server, the studentvm1 host, synchronizes to the host at 192.168.0.51, which is my internal network NTP server, at stratum 4. Synchronizing directly to the Fedora pool machines would result in synchronization at stratum 3. Notice also that the amount of error decreases over time. Eventually, it should stabilize with a tiny variation around a fairly small range of error. The size of the error depends upon the stratum and other network factors. After a few minutes, use Ctrl+C to break out of the watch loop.

To turn our host into an NTP server, we need to allow it to listen on the local network. Uncomment the following line to allow hosts on the local network to access our NTP server.

# Allow NTP client access from local network.
allow 192.168.0.0/16

Note that the server can listen for requests on any local network it's attached to. The IP address in the "allow" line is just intended for illustrative purposes. Be sure to change the IP network and subnet mask in that line to match your local network's.

Restart chronyd .

[root@studentvm1 ~]# systemctl restart chronyd

To allow other hosts on your network to access this server, configure the firewall to allow inbound UDP packets on port 123. Check your firewall's documentation to find out how to do that.

Testing

Your host is now an NTP server. You can test it with another host or a VM that has access to the network on which the NTP server is listening. Configure the client to use the new NTP server as the preferred server in the /etc/chrony.conf file, then monitor that client using the chronyc tools we used above.

Chronyc as an interactive tool

As I mentioned earlier, chronyc can be used as an interactive command tool. Simply run the command without a subcommand and you get a chronyc command prompt.

[root@studentvm1 ~]# chronyc
chrony version 3.4
Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the
GNU General Public License version 2 for details.

chronyc>

You can enter just the subcommands at this prompt. Try using the tracking , ntpdata , and sources commands. The chronyc command line allows command recall and editing for chronyc subcommands. You can use the help subcommand to get a list of possible commands and their syntax.

Conclusion

Chrony is a powerful tool for synchronizing the times of client hosts, whether they are all on the local network or scattered around the globe. It's easy to configure because, despite the large number of options available, only a few configurations are required for most circumstances.

After my client computers have synchronized with the NTP server, I like to set the system hardware clock from the system (OS) time by using the following command:

/sbin/hwclock --systohc

This command can be added as a cron job or a script in cron.daily to keep the hardware clock synced with the system time.

Chrony and NTP (the service) both use the same configuration, and the files' contents are interchangeable. The man pages for chronyd , chronyc , and chrony.conf contain an amazing amount of information that can help you get started or learn about esoteric configuration options.

Do you run your own NTP server? Let us know in the comments and be sure to tell us which implementation you are using, NTP or Chrony.

[Mar 10, 2019] Common Administrative Commands for RHEL 7, 6, 5

Mar 10, 2019 | www.pawanbahuguna.com

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.

Download Chart

[Mar 01, 2019] Creating symlinks instead of /bin /sbin /lib and /lib64 directories in RHEL7

That change essentially means that /usr should be on the root partition, not on a separate partition which with the current sizes of harddrive is a resobale requirement.
Notable quotes:
"... On Linux /bin and /usr/bin are still separate because it is common to have /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 only have / mounted. ..."
Mar 01, 2019 | unix.stackexchange.com

balki ,May 2, 2015 at 6:17

What? no /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, /bin and /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).

/bin

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

/usr/bin/

This is the primary directory of executable commands on the system.

essentially, /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 16:12

/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 level.

/usr/bin - Application/distribution binaries meant to be accessed by locally logged in users

/usr/sbin - Application/distribution binaries that support or configure stuff in /sbin.

/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 /usr/local/bin and /usr/local/share/bin .

JonnyJD ,Jan 3, 2013 at 0:17

Some kind of "update" on this issue:

Recently some Linux distributions are merging /bin into /usr/bin and relatedly /lib into /usr/lib . Sometimes also (/usr)/sbin to /usr/bin (Arch Linux). So /usr is 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 obsolete.

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 16:23

On Linux /bin and /usr/bin are still separate because it is common to have /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 only have / mounted.

On Solaris and Arch Linux (and probably others) /bin is a symlink to /usr/bin . Arch also has /sbin and /usr/sbin symlinked to /usr/bin .

Of particular note, the statement that /bin is for "system administrator" commands and /usr/bin is for user commands is not true (unless you think that bash and ls are for admins only, in which case you have a lot to learn). Administrator commands are in /sbin and /usr/sbin .

[Jan 31, 2019] How to Disable Bluetooth in CentOS-RHEL 5,6,7

Jan 31, 2019 | www.thegeekdiary.com

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

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

[Oct 18, 2018] Fedora switching from NetworkManager to explicit ifcfg networking Linux

Nov 23, 2015 | lxer.com

penguinist. Nov 23, 2015

Now that I've spent uncounted hours reaching a solution on this one I wanted to document it somewhere for other LXers who might be faced with a similar problem in the future.

In a fresh installation of Fedora23 the default configuration came up with NetworkManager running the show. This workstation however has a more complex configuration than average with two network interfaces, one running with dhcp and the other serving as a static gateway to an internal lan. Since this configuration is set up once and never changes, the right way seemed to be an explicit configuration, one with custom crafted /etc/sysconfig/network-scripts/ifcfg-ethx config files. After setting up those files, the next part went fairly easily:

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
systemctl enable network.service
systemctl start network.service

Checking the result however showed errors which indicated that dhclient had been invoked on the eth1 interface even though its ifcfg-eth1 configuration was clearly marked:

BOOTPROTO=none

After a long investigation it turned out that NetworkManager had saved an eth1 lease file under /var/lib/dhclient/ and network.service dutifully attempted to restore that lease even though the interface was explicitly marked for no dhcp service (should file a bugzilla report on this one).

Manually removing the extraneous lease file fixed the problem and we now start network cleanly with NetworkManager disabled.

JaseP

Nov 23, 2015
8:48 PM EDT Nice catch & fix!

[Oct 16, 2018] How to Enable or Disable Services on Boot in Linux Using chkconfig and systemctl Command by Prakash Subramanian

Oct 15, 2018 | www.2daygeek.com
It's a important topic for Linux admin (such a wonderful topic) so, everyone must be aware of this and practice how to use this in the efficient way.

In Linux, whenever we install any packages which has services or daemons. By default all the services "init & systemd" scripts will be added into it but it wont enabled.

Hence, we need to enable or disable the service manually if it's required. There are three major init systems are available in Linux which are very famous and still in use.

What is init System?

In Linux/Unix based operating systems, init (short for initialization) is the first process that started during the system boot up by the kernel.

It's holding a process id (PID) of 1. It will be running in the background continuously until the system is shut down.

Init looks at the /etc/inittab file to decide the Linux run level then it starts all other processes & applications in the background as per the run level.

BIOS, MBR, GRUB and Kernel processes were kicked up before hitting init process as part of Linux booting process.

Below are the available run levels for Linux (There are seven runlevels exist, from zero to six).

Below three init systems are widely used in Linux.

What is System V (Sys V)?

System V (Sys V) is one of the first and traditional init system for Unix like operating system. init is the first process that started during the system boot up by the kernel and it's a parent process for everything.

Most of the Linux distributions started using traditional init system called System V (Sys V) first. Over the years, several replacement init systems were released to address design limitations in the standard versions such as launchd, the Service Management Facility, systemd and Upstart.

But systemd has been adopted by several major Linux distributions over the traditional SysV init systems.

What is Upstart?

Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.

It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init.

It was used in Ubuntu from 9.10 to Ubuntu 14.10 & RHEL 6 based systems after that they are replaced with systemd.

What is systemd?

Systemd is a new init system and system manager which was implemented/adapted into all the major Linux distributions over the traditional SysV init systems.

systemd is compatible with SysV and LSB init scripts. It can work as a drop-in replacement for sysvinit system. systemd is the first process get started by kernel and holding PID 1.

It's a parant process for everything and Fedora 15 is the first distribution which was adapted systemd instead of upstart. systemctl is command line utility and primary tool to manage the systemd daemons/services such as (start, restart, stop, enable, disable, reload & status).

systemd uses .service files Instead of bash scripts (SysVinit uses). systemd sorts all daemons into their own Linux cgroups and you can see the system hierarchy by exploring /cgroup/systemd file.

How to Enable or Disable Services on Boot Using chkconfig Commmand?

The chkconfig utility is a command-line tool that allows you to specify in which
runlevel to start a selected service, as well as to list all available services along with their current setting.

Also, it will allows us to enable or disable a services from the boot. Make sure you must have superuser privileges (either root or sudo) to use this command.

All the services script are located on /etc/rd.d/init.d .

How to list All Services in run-level

The -–list parameter displays all the services along with their current status (What run-level the services are enabled or disabled).

# chkconfig --list
NetworkManager     0:off    1:off    2:on    3:on    4:on    5:on    6:off
abrt-ccpp          0:off    1:off    2:off    3:on    4:off    5:on    6:off
abrtd              0:off    1:off    2:off    3:on    4:off    5:on    6:off
acpid              0:off    1:off    2:on    3:on    4:on    5:on    6:off
atd                0:off    1:off    2:off    3:on    4:on    5:on    6:off
auditd             0:off    1:off    2:on    3:on    4:on    5:on    6:off
.
.
How to check the Status of Specific Service

If you would like to see a particular service status in run-level then use the following format and grep the required service.

In this case, we are going to check the auditd service status in run-level

[Oct 14, 2018] I m curious if Redhat are regretting their decision on the early hard switch to systemd in RHEL7

RHEL7 looks like a fiasco to me...
Notable quotes:
"... I have friends in the industry still on RHEL6 as the upgrade to version 7 is a logistical nightmare and one who works at a reasonably large enterprise considering ditching Redhat entirely to go to a systemd-less alternative. ..."
"... That faster boot time sure helps with servers that are only restarted once a year ... ..."
"... The best part is how they want to use systemd to save 12 seconds of boot time on my servers that take 5-10 minutes to boot, once every few years. Anyone who thinks that complexity is worth that negligible difference is insane. Of course there are other arguments for systemd, but don't tell me I need it on my servers so they "boot faster". ..."
Oct 14, 2018 | linux.slashdot.org

Zarjazz ( 36278 ) , Monday December 11, 2017 @08:42AM ( #55715117 )

Enterprise Headache ( Score: 4 , Informative)

I'm curious if Redhat are regretting their decision on the early hard switch to systemd in RHEL7. I know for a fact their support system was flooded with issues from early adopters.

I have friends in the industry still on RHEL6 as the upgrade to version 7 is a logistical nightmare and one who works at a reasonably large enterprise considering ditching Redhat entirely to go to a systemd-less alternative.

That faster boot time sure helps with servers that are only restarted once a year ...

jon3k ( 691256 ) , Monday December 11, 2017 @10:44AM ( #55715759 )
Re:Enterprise Headache ( Score: 4 , Informative)

The best part is how they want to use systemd to save 12 seconds of boot time on my servers that take 5-10 minutes to boot, once every few years. Anyone who thinks that complexity is worth that negligible difference is insane. Of course there are other arguments for systemd, but don't tell me I need it on my servers so they "boot faster".

[Oct 12, 2018] RHEL 7 Root Password Recovery - Red Hat Customer Portal

Notable quotes:
"... That should be "touch /.autorelabel" (forward-slash dot instead of dot forward-slash). ..."
Oct 12, 2018 | access.redhat.com

Robert Krátký

Adding rd.break to the end of the line with kernel parameters in Grub stops the start up process before the regular root filesystem is mounted (hence the necessity to chroot into sysroot ). Emergency mode, on the other hand, does mount the regular root filesystem, but it only mounts it in a read-only mode. Note that you can even change to emergency mode using the systemctl command on a running system ( systemctl emergency ).

I updated the linked solution ( Resetting the Root Password of RHEL-7 / systemd ) to make the instructions easier to follow.

Guru 6827 points 11 November 2014 1:44 AM R. Hinton Community Leader

I've found recently that sometimes on a virtual system you have to add "console=tty0" at the end on a virtual system else the output goes to a non-available serial console.

IO Loreal.Linux 9 November 2017 2:40 PMRHEL 7 root Password Reset.

Step 1: Break the Consloe while Linux boot. Step 2: Press "e" to edit the kernel. Step 3: append the entry at the end of linux line as below rd.break console=tty1

Step 4: Press CTRL+X

Step 5: mount -o remount,rw /sysroot

Step 6: chroot /sysroot; change root password

Step 7: touch /.autorelabel

Step 8: Type exit two times

Thanks & Regards Namasivayam

Siggy Sigwald 22 February 2018 3:55 PM

1 - on grub menu, select the kernel to boot from and press "e". 2 - append the following to the end of the line that starts with "linux16" rd.break console=tty1 3 - use ctrl+x to bootup - mount -o remount,rw /sysroot 4 - chroot /sysroot 5 - passwd (enter new password). 6 - touch /.autorelabel 7 - ctrl+d twice to resume normal boot process.

William Schmidt, 18 April 2018 11:14 AM

If you use the syntax above (touch ./autorelabel (dot forward-slash)), the result is to create a file called autorelabel in the current directory. The result will NOT be a relabel function and a system you may not be able to log in to.

That should be "touch /.autorelabel" (forward-slash dot instead of dot forward-slash). Notice the position of the period in front of the autorelabel filename. The result is to create a file called .autorelabel in the root directory. The result will be a relabel function and a system you can log in to.

I have made that mistake!

// Bill //

[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) <[email protected] 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

Google matched content

Softpanorama Recommended

Top articles

Sites

Etc

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard 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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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 to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: December, 13, 2020