|
|
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 | |||||||
Release of RHEL 8 gives opportunity for those who still are using RHEL 6 to skip RHEL 7 completely for new server installations. RHEL 7 has five years before EOL (June 30, 2024) while many severs last more then five years now.
RHEL 8 theoretically will be able to withstand more heavy loads due to optimized TCP/IP stack and improvements in memory handling. Among notable changes
On command line level you do not feel much change. Systemd is omnipresent like in RHEL 7.
Compatible changes
Installation did not changed much from RHEL 7. RHEL 8 still pushes LVM for root filesystem in
default installation. Without subscription you can still install packages from ISO, iether directly or making it a repo. The default filesystem remains XFS, RedHat EnterpriseLinux 8 supports installing from a repository on a local hard drive. you only need to specify the
directory instead of the ISO image. For example: inst.repo=hd:<device>:<path to the repository>.
Kickstart changed but not much ( auth or authconfig are
depreciated you need to use authselect instead See
Chapter5.Installer and image creation Red Hat Enterprise Linux 8 Red Hat Customer Portal
RPM command is also upgraded. The rpmbuild command can now do
all build steps from a source package directly. the new --reinstall option allows to
reinstall a previously installed package. there is a new rpm2archive utility for converting rpm
payload to tar archives. See
New RPM features in RHEL 8.
TCP networking stack is Improved. Red Hat claims that version 4.18 provides higher performances, better scalability, and more stability
RHEL 8 natively supports the Open SSL 1.1.1 and TLS 1.3 cryptographic standard
BIND version 9.11 is installed by default. This version of the DNS server introduces new features and feature changes compared to version 9.10.
Apache HTTP Server, has been updated from version 2.4.6 to version 2.4.37 between RHEL 7 and RHEL 8. This updated version includes several new features, but maintains backwards compatibility with the RHEL 7 version
OpenSSH was upgraded to version 7.8p1, and the Digital Signature Algorithm (DSA) is considered deprecated..
Authentication mechanisms that depend on DSA keys do not work in the default configuration. Note that OpenSSH
clients do not accept DSA host keys even in the LEGACY system-wide cryptographic policy level.
GCC toolchain is based on the GCC 8.2
Perl 5.26, distributed with RHEL 8. The current directory . has been removed from the
@INC module search path for security reasons.
Vim runs default.vim script, if no ~/.vimrc file is available.
The 'nobody' & 'nfsnobody' user and groups are merged into 'nobody' ID (65534).
Incompatible changes
In RHEL 8, for some daemons like cups, the logs are no longer stored in specific files within the /var/log directory, which was
used in RHEL 7. Instead, thet are stored only in systemd-journald. The configuration files in the rsyslog packages
now use the non-legacy format by default. The default logging environment setup might consume 4 GB of memory or even more when
systemd-journald is running with rsyslog. See the
Negative effects of the RHEL default logging setup on performance and their
mitigations
Now you are forced to switch to Chronyd. The old NTP implementation is not supported in RHEL8. See Achieving some settings previously supported by ntp in chrony. The default chrony configuration file is /etc/chrony.conf. For information on how to configure NTP using the chrony suite, see Configuring basic system settings.
NFS over UDP (NFS3) is no longer supported. The NFS configuration file moved to "/etc/nfs.conf". when upgrading from RHEL7 the file is moved automatically.
Iptables were replaced by the nftables as a default network filtering framework. This update adds the
iptables-translate and ip6tables-translate tools to convert the existing iptables or
ip6tables rules into the equivalent ones for nftables.
Python version installed by default is 3.6, which introduced incompatibilities with scripts written for
Python 2.x Python 2.7 is available in the python2 package. See
Using Python in Red Hat Enterprise Linux 8.
Repo channels names changed, but content of them is mostly the same. CodeReady Linux Builder repository was added. It is similar to EPEL and supplies additional packages, which are not supported for production use.
Docker is not included in RHEL 8. For working with containers, Red hat expects you to use the podman, buildah, skopeo, and runc tools. The podman tool manages pods, container images, and containers on a single node. It is built on the libpod library, which enables management of containers and groups of containers, called pods.
The network scripts are not available by default in RHEL 8. The basic installation provides a new version of the ifup
and ifdown scripts which call NetworkManager through the nmcli tool. The
NetworkManager-config-server package is only installed by default if you select either the Server or
Server with GUI base environment during the setup. If you selected a different environment, use the yum install
NetworkManager-config-server command to install the package.
Git 2.18, a distributed revision control system with a decentralized architecture. Mercurial 4.8, a lightweight distributed version control system, designed for efficient handling of large
projects. Subversion 1.10, a centralized version control system. New tools and capabilities
Node.js, a software development platform in the JavaScript programming language, is provided for the first
time in RHEL. It was previously available only as a Software Collection. RHEL 8 provides Node.js 10.
RHEL 8 supports installing from a repository on a local hard drive. you only need to specify the
directory instead of the ISO image. For example: inst.repo=hd:<device>:<path to the repository>.
Kickstart changed but not much ( auth or authconfig are
depreciated you need to use authselect instead See
Chapter5.Installer and image creation Red Hat Enterprise Linux 8 Red Hat Customer Portal
DNF modules improve package management.
New tool called Image Builder enables users to create customized RHEL images. Image Builder is available in AppStream in the lorax-composer package. Among other things, it allows created live ISO disk image and images for Azure, VMWare and AWS, See Composing a customized RHEL system image.
New tools for working with containers were introduced
Some new storage management capabilities were introduced. Stratis is a new local storage manager. It provides managed file systems on top of pools of storage with additional features to the user. See : Managing layered local storage with Stratis.
Upgrade
Upgrade from RHEL 7.6 and higher is possible. https://www.tecmint.com/upgrade-from-rhel-7-to-rhel-8/
Theoretically upgrade from RHEL 6 to RHEL 8 is possible via upgrade to RHEL 7 first, but is too risky.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
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 shutdown2. Reboot system
RHEL 5 & 6: # reboot or # init 6
RHEL 7: # systemctl reboot3. Configure default run level/target
RHEL 5 & 6: # /etc/inittab
RHEL 7: # systemctl set-default4. Configure GRUB bootloader
RHEL 5 & 6: # /boot/grub/grub.conf
RHEL 7: # /etc/default/grub, grub2-mkconfig, grub-set-default5. List running services
RHEL 5 & 6: # service –status-all
RHEL 7: # systemctl -t service –state=active6. Check if service is enabled
RHEL 5 & 6: # chkconfig name
RHEL 7: # systemctl is-enabled name7. View run level/target
RHEL 5 & 6: # runlevel or who -r
RHEL 7: # systemctl get-default or who -r8. Enable/disable service
RHEL 5 & 6: # chkconfig name on and # chkconfig name off
RHEL 7: # systemctl enable name.service and # systemctl disable name.service9. View service status
RHEL 5 & 6: # service name status
RHEL 7: # systemctl status name.serviceNote: 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.
|
|
|
Mar 01, 2019 | unix.stackexchange.com
- Anyone interested in the historicity of this configuration should read this: lists.busybox.net/pipermail/busybox/2010-December/074114.html – JDS Nov 30 '16 at 19:02
balki ,May 2, 2015 at 6:17
What? no/bin/is not a symlink to/usr/binon any FHS compliant system. Note that there are still popular Unixes and Linuxes that ignore this - for example,/binand/sbinare symlinked to/usr/binon Arch Linux (the reasoning being that you don't need/binfor rescue/single-user-mode, since you'd just boot a live CD).contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scriptsThis is the primary directory of executable commands on the system.essentially,
/bincontains executables which are required by the system for emergency repairs, booting, and single user mode./usr/bincontains any binaries that aren't required.I will note, that they can be on separate disks/partitions,
/binmust be on the same disk as/./usr/bincan 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/binbut always a/usr/local/binand/usr/local/share/bin.JonnyJD ,Jan 3, 2013 at 0:17
Some kind of "update" on this issue:Recently some Linux distributions are merging
/bininto/usr/binand relatedly/libinto/usr/lib. Sometimes also(/usr)/sbinto/usr/bin(Arch Linux). So/usris 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
/binavailable 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/binand/usr/binare still separate because it is common to have/usron a separate partition (although this configuration breaks in subtle ways, sometimes). In/binis all the commands that you will need if you only have/mounted.On Solaris and Arch Linux (and probably others)
/binis a symlink to/usr/bin. Arch also has/sbinand/usr/sbinsymlinked to/usr/bin.Of particular note, the statement that
/binis for "system administrator" commands and/usr/binis for user commands is not true (unless you think thatbashandlsare for admins only, in which case you have a lot to learn). Administrator commands are in/sbinand/usr/sbin.
|
|
|
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.serviceOn CentOS/RHEL 5 and 6 , execute the following commands as root:
# chkconfig bluetooth off # service bluetooth stopUloading Bluetooth ModulesIf 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 btusbOn CentOS/RHEL 5 :
# rmmod bnep # rmmod bluetooth # rmmod hci_usb
|
|
|
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)Re:Systemd has been the most divisive force in the Linux community lately, and perhaps ever. It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.
Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.
Amen. It's sad, but a single person has managed to kill the momentum of GNU/Linux as an operating system. Microsoft should give the guy a medal.People are loath to publish new projects because keeping them running with systemd and all its dependencies in all possible permutations is a full time job. The whole "do one thing only and do it well" concept has been flushed down the 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)Re:Why does John shut down all systemd talk? (Score:5, Insightful)I was reading through the article's comments and saw this thread of discussion [complete.org]. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away.
The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today. I don't use Debian, but I do use another distro that switched to systemd, and it is in fact the problem here. My workstation doesn't work anywhere as well as it did a couple of years ago, before systemd got installed. So when somebody blames systemd for these kinds of problems, that person is totally correct. I don't get why John would censor the discussion like that. I also don't get why he'd label somebody who points out the real problem as being a 'troll'.
John needs to admit that the real problem here is not the people who are against systemd. These people are actually the ones who are right, and who have the solution to John's problems!
The comment I linked to says 'Systemd needs to be removed from Debian immediately.', and that's totally right. But I think we need to expand it to 'Systemd needs to be removed from all Linux distros immediately.'
If we want Linux to be usable again, systemd does need to go. It's just as simple as that. Censoring any and all discussion of the real problem here, systemd, sure isn't going to get these problems resolved any quicker!
|
|
|
Aug 27, 2014
There's a lot to like in the next Red Hat Enterprise Linux, but some fundamental changes may prove problematic By Paul Venezia,
Open Source, Linux, Red Hat Enterprise LinuxOne 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.
- Linux containers get a front-row seat in the form of Docker. RHEL can now perform cross-domain trusts with Microsoft Active Directory, so users can authenticate to Linux resources with Active Directory accounts without the need for synchronization.
- RHEL 7 also includes new monitoring and performance tools. For instance, the Performance Co-Pilot (PCP) provides a new API for importing, exporting, and processing performance data, while the Tuned daemon provides dynamic system performance tuning.
- On the inside, RHEL 7 incorporates enhanced NUMA affinity features that optimize performance on a per-process level by aligning processor affinity to RAM location, reducing cross-node communication and improving process performance.
- RHEL 7 offers tighter integration with the VMware vSphere hypervisor via 3D graphics drivers for hardware acceleration with OpenGL and X11, and Open Virtual Machine Tools, an open source implementation of VMware Tools that is now a maintained package.
- Open Linux Management Infrastructure (OpenLMI) is now supported. OpenLMI is a framework that allows for common configuration, management, and monitoring of hardware and software through a remote connection. It provides a standard API that can be used by any compliant controller to make changes to the server configuration or to monitor the system.
- Other changes include the use of Chrony versus the historical Network Time Protocol daemon for time synchronization, support for 40GB interfaces, structured logging, and low-latency sockets. A new firewall management interface, Firewalld, now permits firewall configuration changes without restarting.
- None of these changes or additions will come as much of a surprise to anyone who's been working with Red Hat's Fedora distribution. But those who working exclusively within the RHEL 5 and RHEL 6 ecosystems are in for a jolt.
Brace for impact Of the myriad changes found in RHEL 7, a few are certain to cause consternation. First and foremost of those is the move to the Systemd system and process manager. This represents a major departure from Red Hat's -- and Linux's -- history and from the tried-and-true Unix philosophy of using simple, modular tools for critical infrastructure components. Systemd replaces the simplicity of Init scripts with a major management system that offers new features and capabilities but adds significant 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.
Google matched content |
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, 22, 2020
