Image a language in which both grammar and vocabulary is changing each three to five years.
And both are so huge that are beyond any normal human comprehension. You can learn some subset of
both vocabulary and grammar when you closely work with a particular subsystem for several months in a
row, only to forget it after a couple of months or quarters. The classic example here is RHEL
kickstart.
In a sense all talks about linux security is a joke as you can't secure the OS, which is far, far
beyond your ability to comprehend. So state-sponsored hackers will always have an edge in breaking
into linux.
Linux became two complex to master for a single person. Now this is yet another monstrous OS, that
nobody know well (as the level completely puts it far above mere mortal capabilities) And
that's the problem. Both Red Hat and Suse are now software development companies that can be called
"overcomplexity junks". And it shows in their recent products. Actually SLES is even worse then
RHEL in this respect, despite being (originally) a German distribution.
Generally in Linux administration (like previously in enterprise Unix administration) you get what
you paid for. Nothing can replace multi-year experience, and experience often is acquired by making expensive mistakes
(see Admin Horror Stories). Vendor training
is expensive and is more or less available only to sysadmin in few industries (financial industry is one).For Red Hat we have the situation that closely resembles the situation well know from Solaris: training
is rather good, but prices are exorbitant.
Due to the current complexity (or, more correctly, overcomplexity) of Linux environments most
sysadmins can master it well only for commonly used subsystems and for just one flavor of Linux. Better one might be able to support two (with
highly asymmetrical level of skills, being usually considerably more proficient in one flavor over the
other). In other words Unix wars are now replaced on Linux turf with vengeance.
The level of mental overload and frustration from the overcomplexity of two major enterprise Linux flavors
(RHEL and SLES) is such that people are ready for a change. Note that in OS ecosystem there is a
natural tendency toward monopoly -- nothing succeed like success and the
critical mass of installation that those two "monstrously complex" Linux distribution hold prevent any escape.
Especially
in enterprise environment. Red Hat can essentially dictate what linux should be -- as it did with
incorporating systemd in RHEL 7.
Still there is a large difference between RHEL and SLES popularity:
RHEL and its derivatives posses dominant share, probably over
60% in enterprise space (if we include Oracle Unbreakable Linux, Centos and Fedora).
Ubuntu -- a dumped-down Linux based on Debian, with some strange design decisions -- is now
getting some corporate sales, especially in cloud environment, the expense of Suse. It still mainly desktop
OS but it gradually acquires some enterprise share two. That makes the number of enterprise linux
distribution close to what we used to have in commercial Unix space (Solaris, AIX and HP-UX) and
Debian and Ubuntu playing the role of Solaris.
SLES until recently was slightly simpler then RHEL, as it did not include horribly complex security subsystem that RHEL uses --
SELinux. It takes a lot of efforts to learn even basics of SELinux and configure properly one facing Internet server. Most
sysadmin just use it blindly iether enabling it and disabling it without understanding any details of its functioning (or, more
correctly, understanding it on the level allowing them to use common protocols, much like is the case with firewalls)
Actually it has a better solution in Linux-space used in SLES (AppArmor). Which was
pretty elegant solution to a complex problem, if you ask me. But the critical mass of installation and m,arket share secured by Red
Hat, made it "king of the hill" and prevented AppArmor from becoming Linux standard. A the result SUSE was forced to incorporate
SELinux.
SELinux provides a Mandatory Access Control (MAC) system built into the Linux kernel (that is staff that
labels things as "super secret", "secret" and "confidential" that three letter agencies are using to guard information).
Historically Security Enhanced Linux (SELinux) was an open source project sponsored by the National Security Agency. Despite the
user-friendly GUI, SELinux is difficult to configure and hard to understand. The documentation does not help much either. Most
administrators are just turning SELinux subsystem off during the initial install but for Internet facing server you need to
configure and use it, or... And sometimes effects can be really subtle: for example you can login as root using password
authentication but can't using passwordless ssh certificate. That's why many complex applications, especially in HPC area
explicidly recommend disabling SElinux as a starting point of installation. You can find articles on the WEB devoted to this topic.
See for example
Thanks a million! I was dealing with a samba refusing to access the server shared folders. After about 2 hours of
scrolling forums I found out the issue may be this shitty thing samba_selinux.
I usually disable it when I install, but this time I had to use the Dell utilities (no choice at all) and they enabled the
thing. Disabled it your way, rebooted and it works as I wanted it. Thanks again!
SLES has one significant defect: by default it does not assign each user a unique group like RHEL does. But this can be fixed
with a special wrapper for useradd command. In simplest for it can be just:
#wrapper for useradd command
# accepts two arguments: UID and user name, for example
# uadd 3333 joedoers
function uadd
{
groupadd -g $1 $2
useradd -u $1 -g $1 -m $2
}
Working closely with commercial Linuxes and seeing all their warts and such, one instantly understand that the traditional Open
Source (GPL-based Open Source), is a very problematic business model. Historically (especially in case of Red Hat) is was used as a
smoke screen for the VCs to get software engineers to work for free, not even for minimum wage, but for free! And grab as much money
from suckers as they can, using all right words as an anesthetic. Essentially they take their hard work, pump $$$ in marketing and
either sell the resulting company to one of their other portfolio companies or take it public and dump the shares on the public.
Meanwhile the software engineers that worked to develop that software for free, aka slave labor, get $0.00 for their hard work while
the VCs top brass of the startup and investment bankers make a killing.
And of course then they get their buddies in mainstream media hype the GPL-based Open Source development as the best thing after
sliced bread.
RHEL licensing is a mess too. In addition two higher level licenses are expensive and make
Microsoft server license look very competitive. Recently they went "IBM way" and started to
change different prices for 4 socket servers: you can't just use two 2 socket licenses to license 4
socket server with their new registration-manager. The next step will be classic IBM per core
licensing; that's why so many people passionately hate IBM.
There are three different types of licensing (let's call them patch-only,
regular and with premium support). Each has several variations (for example HPC computational node is
a variant of "patches only" license but does not provide GUI and many packages in repository). The level of
tech support with the latter two (which are truly enterprise licenses) is very similar -- similarly
dismal -- especially for complex problems, unless you press them really hard.
In addition Red Hat people screwed their portal so much that you can't tell which server is assigned
to what license. that situation improved with registration manger but new problem arise.
Generally the level of screw up of RHEL user portal is such, that there doubts that they can do
anything useful in Linux space in the future, other then try to hold to their market share.
All is all while RHEL 6 is very complex but still a usable enterprise Linux distribution because
if did not radically changed from RHEL 4, and 5. But it is not fan to use it, anymore. It's a pain. It's a headache. The same is true for SLES.
It seems some of us are, in the year of our lord 2021, still reusing the same password for
multiple sites, plugging personal gear into work networks, and perhaps overly relying on
browser-managed passwords, judging from this poll.
ThycoticCentrify, formed from a merger between two computer access management firms, said it
surveyed about 8,000 people, and
reports just under a quarter admitted they reuse passwords across multiple websites –
a cybersecurity no-no because it opens you up to credential stuffing .
Meanwhile, about half of those working for large (5,000+ headcount) companies said they
hadn't received cybersecurity training in the past 12 months, even as the vast majority of all
those polled said they'd seen an increase in the volume of phishing messages their org had
received over the past year.
"More than a third of employees continue to save passwords within their internet browsers on
all of their personal and work devices," said Carson. "By cracking only one of those devices,
an attacker can easily access all the passwords stored within the user's browser. This makes it
so much easier for an attacker to elevate privileges without being detected and gain access to
the user's email, company cloud applications, or even sensitive data.
"If the employee has saved multiple passwords within the internet browser, an attacker can
readily see whether they are all the same or simple variations such as one character
difference."
Using a password manager, even one built into a browser, with complex, randomly generated
passwords is arguably better than asking people to memorize weak or guessable ones or reuse the
same credentials over and over for multiple services. That said, ThycoticCentrify's argument
appears to be that companies should move beyond relying just on passwords: they should consider
better ways to reliably and securely authenticate users when accessing resources, using things
like multi-factor authentication.
... ... ...
Finally, though most people responding to the survey acknowledged their business could be
targeted by cyber-criminals, a mere 16 per cent of respondents felt their business was at a
"very high risk" of catching the wrong end of a cybersecurity attack. The spray-and-pwn tactics
of ransomware gangs, such as the crews who targeted ageing Accellion
file-transfer appliances , hasn't quite sunk in for all. ®
Dmitry Antipov, a Linux developer at CloudLinux , AlmaLinux OS's parent
company, first spotted the problem in March 2021. Antipov found that
RPM would work with unauthorized
RPM packages . This meant that unsigned packages or packages signed with revoked keys could silently be patched or updated without
a word of warning that they might not be kosher.
Why? Because RPM had never properly checked revoked certificate key handling. Specifically, as Linux and lead RPM developer Panu
Matilainen explained: "
Revocation is one of
the many unimplemented things in rpm's OpenPGP support . In other words, you're not seeing a bug as such; it's just not implemented
at all, much like expiration is not."
Antipov, wearing his hat as a TuxCare (CloudLinux's KernelCare and Extended
Lifecycle Support) team member, has
submitted a patch
to fix this problem. As Antipov explained in an interview: "The problem is that both RPM and
DNF , [a popular software package manager that installs,
updates, and removes packages on RPM-based Linux distributions] do a check to see if the key is valid and genuine but not expired,
but not for revocation. As I understand it, all the distribution vendors have just been lucky enough to never have been hit by this."
They have indeed been lucky. Armed with an out-of-date key, it could be child's play to sneak malware into a Linux desktop or
server.
A seven-year-old privilege escalation vulnerability that's been lurking in several Linux
distributions was patched last week in a coordinated disclosure.
In a blog
post on Thursday, GitHub security researcher Kevin Backhouse recounted how he found the bug
( CVE-2021-3560 ) in a service called
polkit associated with systemd, a common Linux system and service manager component.
Introduced in commit
bfa5036 seven years ago and initially shipped in polkit version 0.113, the bug traveled
different paths in different Linux distributions. For example, it missed Debian 10 but it made
it to the unstable version of Debian ,
upon which other distros like Ubuntu are based.
Formerly known as PolicyKit, polkit is a service that evaluates whether specific Linux
activities require higher privileges than those currently available. It comes into play if, for
example, you try to create a new user account.
Backhouse says the flaw is surprisingly easy to exploit, requiring only a few commands using
standard terminal tools like bash, kill, and dbus-send.
"The vulnerability is triggered by starting a dbus-send command but killing it
while polkit is still in the middle of processing the request," explained Backhouse.
Killing dbus-send – an interprocess communication command – in the
midst of an authentication request causes an error that arises from polkit asking for the UID
of a connection that no longer exists (because the connection was killed).
"In fact, polkit mishandles the error in a particularly unfortunate way: rather than
rejecting the request, it treats the request as though it came from a process with UID 0,"
explains Backhouse. "In other words, it immediately authorizes the request because it thinks
the request has come from a root process."
This doesn't happen all the time, because polkit's UID query to the dbus-daemon
occurs multiple times over different code paths. Usually, those code paths handle the error
correctly, said Backhouse, but one code path is vulnerable – and if the disconnection
happens when that code path is active, that's when the privilege elevation occurs. It's all a
matter of timing, which varies in unpredictable ways because multiple processes are
involved.
The intermittent nature of the bug, Backhouse speculates, is why it remained undetected for
seven years.
"CVE-2021-3560 enables an unprivileged local attacker to gain root privileges," said
Backhouse. "It's very simple and quick to exploit, so it's important that you update your Linux
installations as soon as possible." ®
The polkit service is used by systemd. Linux systems that have polkit version 0.113 or later installed – like Debian (unstable),
RHEL 8, Fedora 21+, and Ubuntu 20.04 – are affected. "CVE-2021-3560 enables an unprivileged local attacker to gain root privileges,"
said Backhouse. "It's very simple and quick to exploit, so it's important that you update your Linux installations as soon as
possible."
Ancient Linux bugs provide root access to unprivileged users
Security researchers have discovered some 7-year-old vulnerabilities Linux
distribution
Can be used by unprivileged local users to bypass authentication and gain root access.
The bug patched last week exists in Polkit System Service, a toolkit used to assess whether a particular Linux activity requires
higher privileges than currently available. Polkit is installed by default on some Linux distributions, allowing unprivileged
processes to communicate with privileged processes.
Linux distributions that use systemd also use Polkit because the Polkit service is associated with systemd.
This vulnerability has been tracked as CVE-2021-3560 and has a CVSS score of 7.8. It was discovered by Kevin Backhouse, a
security researcher on GitHub. He states that this issue occurred in 2013 with code commit bfa5036.
Initially shipped with Polkit version 0.113, it has moved to various Linux distributions over the last seven years.
"If the requesting process disconnects from dbus-daemon just before the call to polkit_system_bus_name_get_creds_sync begins, the
process will not be able to get the unique uid and pid of the process and will not be able to verify the privileges of the
requesting process." And Red Hat
Advisory
..
"The biggest threats from this vulnerability are data confidentiality and integrity, and system availability."
so
Blog
post
According to Backhouse, exploiting this vulnerability is very easy and requires few commands using standard terminal
tools such as bash, kill and dbus-send.
This flaw affects Polkit versions between 0.113 and 0.118. Red Hat's Cedric Buissart said it will also affect Debian-based
distributions based on Polkit 0.105.
Among the popular Linux distributions affected are Debian "Bullseye", Fedora 21 (or later), Ubuntu 20.04, RHEL 8.
Polkit v.0.119, released on 3rd
rd
We
will address this issue in June. We recommend that you update your Linux installation as soon as possible to prevent threat
attackers from exploiting the bug.
CVE-2021-3560 is the latest in a series of years ago vulnerabilities affecting Linux distributions.
In 2017, Positive Technologies researcher Alexander Popov discovered a flaw in the Linux kernel introduced in the code in 2009.
Tracked as CVE-2017-2636, this flaw was finally patched in 2017.
Another old Linux security flaw indexed as CVE-2016-5195 was introduced in 2007 and patched in 2016. This bug, also known as the
"dirty COW" zero-day, was used in many attacks before the patch was applied.
Ancient Linux bugs provide root access to unprivileged users
Source link
Ancient Linux bugs provide root access to unprivileged users
We had a client that had an OLD fileserver box, a Thecus N4100PRO. It was completely dust-ridden and the power supply had burned
out.
Since these drives were in a RAID configuration, you could not hook any one of them up to a windows box, or a linux box to see
the data. You have to hook them all up to a box and reassemble the RAID.
We took out the drives (3 of them) and then used an external SATA to USB box to connect them to a Linux server running CentOS.
You can use parted to see what drives are now being seen by your linux system:
parted -l | grep 'raid\|sd'
Then using that output, we assembled the drives into a software array:
mdadm -A /dev/md0 /dev/sdb2 /dev/sdc2 /dev/sdd2
If we tried to only use two of those drives, it would give an error, since these were all in a linear RAID in the Thecus box.
If the last command went well, you can see the built array like so:
root% cat /proc/mdstat
Personalities : [linear]
md0 : active linear sdd2[0] sdb2[2] sdc2[1]
1459012480 blocks super 1.0 128k rounding
Note the personality shows the RAID type, in our case it was linear, which is probably the worst RAID since if any one drive fails,
your data is lost. So good thing these drives outlasted the power supply! Now we find the physical volume:
pvdisplay /dev/md0
Gives us:
-- Physical volume --
PV Name /dev/md0
VG Name vg0
PV Size 1.36 TB / not usable 704.00 KB
Allocatable yes
PE Size (KByte) 2048
Total PE 712408
Free PE 236760
Allocated PE 475648
PV UUID iqwRGX-zJ23-LX7q-hIZR-hO2y-oyZE-tD38A3
Then we find the logical volume:
lvdisplay /dev/vg0
Gives us:
-- Logical volume --
LV Name /dev/vg0/syslv
VG Name vg0
LV UUID UtrwkM-z0lw-6fb3-TlW4-IpkT-YcdN-NY1orZ
LV Write Access read/write
LV Status NOT available
LV Size 1.00 GB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors 16384
-- Logical volume --
LV Name /dev/vg0/lv0
VG Name vg0
LV UUID 0qsIdY-i2cA-SAHs-O1qt-FFSr-VuWO-xuh41q
LV Write Access read/write
LV Status NOT available
LV Size 928.00 GB
Current LE 475136
Segments 1
Allocation inherit
Read ahead sectors 16384
We want to focus on the lv0 volume. You cannot mount yet, until you are able to lvscan them.
ACTIVE '/dev/vg0/syslv' [1.00 GB] inherit
ACTIVE '/dev/vg0/lv0' [928.00 GB] inherit
Now we can mount with:
mount /dev/vg0/lv0 /mnt
And viola! We have our data up and accessable in /mnt to recover! Of course your setup is most likely going to look different
from what I have shown you above, but hopefully this gives some helpful information for you to recover your own data.
I've found a disturbing
trend in GNU/Linux, where largely unaccountable cliques of developers unilaterally decide to make fundamental changes to the way
it works, based on highly subjective and arrogant assumptions, then forge ahead with little regard to those who actually use the
software, much less the well-established principles upon which that OS was originally built. The long litany of examples includes
Ubuntu Unity ,
Gnome Shell ,
KDE 4 , the
/usr partition ,
SELinux ,
PolicyKit ,
Systemd ,
udev and
PulseAudio , to name a few.
The broken features, creeping bloat, and in particular the unhealthy tendency toward more monolithic, less modular code in certain
Free Software projects, is a very serious problem, and I have a very serous opposition to it. I abandoned Windows to get away from
that sort of nonsense, I didn't expect to have to deal with it in GNU/Linux.
Clearly this situation is untenable.
The motivation for these arbitrary changes mostly seems to be rooted in the misguided concept of "popularity", which makes no
sense at all for something that's purely academic and non-commercial in nature. More users does not equal more developers. Indeed
more developers does not even necessarily equal more or faster progress. What's needed is more of the right sort of developers,
or at least more of the existing developers to adopt the right methods.
This is the problem with distros like Ubuntu, as the most archetypal example. Shuttleworth pushed hard to attract more users,
with heavy marketing and by making Ubuntu easy at all costs, but in so doing all he did was amass a huge burden, in the form of a
large influx of users who were, by and large, purely consumers, not contributors.
As a result, many of those now using GNU/Linux are really just typical Microsoft or Apple consumers, with all the baggage that
entails. They're certainly not assets of any kind. They have expectations forged in a world of proprietary licensing and commercially-motivated,
consumer-oriented, Hollywood-style indoctrination, not academia. This is clearly evidenced by their
belligerently hostile attitudes toward the GPL, FSF,
GNU and Stallman himself, along with their utter contempt for security and other well-established UNIX paradigms, and their unhealthy
predilection for proprietary software, meaningless aesthetics and hype.
Reading the Ubuntu forums is an exercise in courting abject despair, as one witnesses an ignorant hoard demand GNU/Linux be mutated
into the bastard son of Windows and Mac OS X. And Shuttleworth, it seems, is
only too happy
to oblige , eagerly assisted by his counterparts on other distros and upstream projects, such as Lennart Poettering and Richard
Hughes, the former of whom has somehow convinced every distro to mutate the Linux startup process into a hideous
monolithic blob , and the latter of whom successfully managed
to undermine 40 years of UNIX security in a single stroke, by
obliterating the principle that unprivileged
users should not be allowed to install software system-wide.
GNU/Linux does not need such people, indeed it needs to get rid of them as a matter of extreme urgency. This is especially true
when those people are former (or even current) Windows programmers, because they not only bring with them their indoctrinated expectations,
misguided ideologies and flawed methods, but worse still they actually implement them , thus destroying GNU/Linux from within.
Perhaps the most startling example of this was the Mono and Moonlight projects, which not only burdened GNU/Linux with all sorts
of "IP" baggage, but instigated a sort of invasion of Microsoft "evangelists" and programmers, like a Trojan horse, who subsequently
set about stuffing GNU/Linux with as much bloated, patent
encumbered garbage as they could muster.
I was part of a group who campaigned relentlessly for years to oust these vermin and undermine support for Mono and Moonlight,
and we were largely successful. Some have even suggested that my
diatribes ,
articles and
debates (with Miguel
de Icaza and others) were instrumental in securing this victory, so clearly my efforts were not in vain.
Amassing a large user-base is a highly misguided aspiration for a purely academic field like Free Software. It really only makes
sense if you're a commercial enterprise trying to make as much money as possible. The concept of "market share" is meaningless for
something that's free (in the commercial sense).
Of course Canonical is also a commercial enterprise, but it has yet to break even, and all its income is derived through support
contracts and affiliate deals, none of which depends on having a large number of Ubuntu users (the Ubuntu One service is cross-platform,
for example).
Make each program do one thing well. To do a new job, build afresh rather than
complicate old programs by adding new features.
By now, and to be frank in the last 30 years too, this is complete and utter bollocks.
Feature creep is everywhere, typical shell tools are choke-full of spurious additions, from
formatting to "side" features, all half-assed and barely, if at all, consistent.
By now, and to be frank in the last 30 years too, this is complete and utter
bollocks.
There is not one single other idea in computing that is as unbastardised as the unix
philosophy - given that it's been around fifty years. Heck, Microsoft only just developed
PowerShell - and if that's not Microsoft's take on the Unix philosophy, I don't know what
is.
In that same time, we've vacillated between thick and thin computing (mainframes, thin
clients, PCs, cloud). We've rebelled against at least four major schools of program design
thought (structured, procedural, symbolic, dynamic). We've had three different database
revolutions (RDBMS, NoSQL, NewSQL). We've gone from grassroots movements to corporate
dominance on countless occasions (notably - the internet, IBM PCs/Wintel, Linux/FOSS, video
gaming). In public perception, we've run the gamut from clerks ('60s-'70s) to boffins
('80s) to hackers ('90s) to professionals ('00s post-dotcom) to entrepreneurs/hipsters/bros
('10s "startup culture").
It's a small miracle that iproute2only has formatting options and
grep only has --color . If they feature-crept anywhere near the same
pace as the rest of the computing world, they would probably be a RESTful SaaS microservice
with ML-powered autosuggestions.
This is because adding a new features is actually easier than trying to figure out how
to do it the Unix way - often you already have the data structures in memory and the
functions to manipulate them at hand, so adding a --frob parameter that does
something special with that feels trivial.
GNU and their stance to ignore the Unix philosophy (AFAIK Stallman said at some point he
didn't care about it) while becoming the most available set of tools for Unix systems
didn't help either.
No, it certainly isn't. There are tons of well-designed, single-purpose tools
available for all sorts of purposes. If you live in the world of heavy, bloated GUI apps,
well, that's your prerogative, and I don't begrudge you it, but just because you're not
aware of alternatives doesn't mean they don't exist.
typical shell tools are choke-full of spurious additions,
What does "feature creep" even mean with respect to shell tools? If they have lots of
features, but each function is well-defined and invoked separately, and still conforms to
conventional syntax, uses stdio in the expected way, etc., does that make it un-Unixy? Is
BusyBox bloatware because it has lots of discrete shell tools bundled into a single
binary? nirreskeya
3 years ago
I have succumbed to the temptation you offered in your preface: I do write you off
as envious malcontents and romantic keepers of memories. The systems you remember so
fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out
to pasture, they are fertilizing it from below.
Your judgments are not keen, they are intoxicated by metaphor. In the Preface you
suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag.
In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and
addled by puffiness of the genome.
Yet your prison without coherent design continues to imprison you. How can this
be, if it has no strong places? The rational prisoner exploits the weak places,
creates order from chaos: instead, collectives like the FSF vindicate their jailers
by building cells almost compatible with the existing ones, albeit with more
features. The journalist with three undergraduate degrees from MIT, the researcher at
Microsoft, and the senior scientist at Apple might volunteer a few words about the
regulations of the prisons to which they have been transferred.
Your sense of the possible is in no sense pure: sometimes you want the same thing
you have, but wish you had done it yourselves; other times you want something
different, but can't seem to get people to use it; sometimes one wonders why you just
don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice,
just a future whose intellectual tone and interaction style is set by Sonic the
Hedgehog. You claim to seek progress, but you succeed mainly in whining.
Here is my metaphor: your book is a pudding stuffed with apposite observations,
many well-conceived. Like excrement, it contains enough undigested nuggets of
nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of
contempt and of envy.
This file contains encrypted or ' shadowed ' passwords for group accounts and, for security
reasons, cannot be accessed by regular users. It's only readable by the root user and users
with sudo privileges.
$ sudo cat /etc/gshadow
tecmint:!::
From the far left, the file contains the following fields:
Jack Aboutboul, former Red Hat and Fedora engineer and architect, will be AlmaLinux's community
manager. Altogether, Aboutboul brings over 20 years of experience in open-source communities as
a participant, manager, and evangelist.
He'll be helped by the AlmaLinux governing board. Currently, this includes Jesse Asklund,
global head of customer experience for WebPros at cPanel ; Simon Phipps, open-source advocate and a former president of
the Open Source Initiative (OSI) ; Igor
Seletskiy, CloudLinux CEO; and Eugene Zamriy, CloudLinux director of release engineering at.
Two additional members of the governing board for the 501(c)(6) non-profit organization will be
selected by the AlmaLinux community.
"In an effort to fill the void soon to be left by the demise of CentOS as a stable
release, AlmaLinux has been developed in close collaboration with the Linux community," said
Aboutaboul in a statement. "These efforts resulted in a production-ready alternative to
CentOS that is supported by community members."
This first release of AlmaLinux is a one-to-one binary compatible fork of RHEL 8.3. Looking
ahead, AlmaLinux will seek to keep step-in-step with future RHEL releases. RHEL 8.x, CentOS
8.x, and Oracle Linux 8.x
migration instructions
are available today.
Installing the environment group "Server with GUI"
1. Check the available environment groups :
# yum grouplist
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
Available Environment Groups:
Minimal Install
Infrastructure Server
File and Print Server
Basic Web Server
Virtualization Host
Server with GUI
Available Groups:
Compatibility Libraries
Console Internet Tools
Development Tools
Graphical Administration Tools
Legacy UNIX Compatibility
Scientific Support
Security Tools
Smart Card Support
System Administration Tools
System Management
Done
2. Execute the following to install the environments for GUI.
# yum groupinstall "Server with GUI"
.......
Transaction Summary
====================================================
Install 199 Packages (+464 Dependent packages)
Upgrade ( 8 Dependent packages)
Total download size: 523 M
Is this ok [y/d/N]:
The above will install the GUI in RHEL 7, which by default get installed to text mode.
3. Enable GUI on system start up. In RHEL 7, systemd uses 'targets' instead of runlevels.
The file /etc/inittab is no more used to change run levels. Issue the following command to
enable the GUI on system start.
To set a default target :
# systemctl set-default graphical.target
To change the current target to graphical without reboot :
# systemctl start graphical.target
Verify the default target :
# systemctl get-default
graphical.target
4. Reboot the machine to verify that it boots into GUI directly.
# systemctl reboot
Installing core GNOME packages
"Server with GUI" installs the default GUI which is GNOME. In case if you want to install
only core GNOME packages use :
# yum groupinstall 'X Window System' 'GNOME'
....
Transaction Summary
===========================================================
Install 104 Packages (+427 Dependent packages)
Upgrade ( 8 Dependent packages)
Total download size: 318 M
Is this ok [y/d/N]:
GUI to CLI : Ctrl + Alt + F6 CLI to GUI : Ctrl + Alt + F1
Kapendra
http://kapendra.com Love to write technical stuff with personal experience as I am working
as a Sr. Linux Admin. and every day is a learning day and Trust me being tech geek is really
cool.
Monitoring failed login attempts on Linux
Failed logins can be legitimate human error or attempts to hack your Linux system, but either way they might flag something that
warrants attention.
Repeated failed login attempts on a Linux server can indicate that someone is trying to break into an account or might only
mean that someone forgot their password or is mistyping it. In this post, we look at how you can check for failed login
attempts and check your system's settings to see when accounts will be locked to deal with the problem.
One of the first things you need to know is how to check if logins are failing. The command below looks for indications of
failed logins in the
/var/log/auth.log
file used on Ubuntu and related systems.
When someone tries logging in with a wrong or misspelled password, failed logins will show up as in the lines below:
$ sudo grep "Failed password" /var/log/auth.log | head -3
Nov 17 15:08:39 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2
Nov 17 15:09:13 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2
You could summarize instances of failed logins by account with a command like this:
That command summarizes failed logins by username (ninth column in the grep output). It avoids looking at lines containing the
word "COMMAND" to skip over inquiries that contain the "Failed passwords" phrase (e.g., someone running the command that was
run above). The "times:" string suggests that there were more repeated attempts than the number reported. These come from
lines containing "message repeated 5 times:" that may be added to the log file when a password is entered incorrectly a
number of times in quick succession.
Another thing you might want to check is where the failed login attempts are coming from. For that, change the field that
you're focusing on from the ninth to the eleventh as in this example:
It might be especially suspicious, for example, if you're seeing failed logins for multiple users from a single system.
In RHEL, Centos and related systems, you'll find the messages related to failed logins in the
/var/log/secure
file.
You can use basically the same query as shown above to get a count. Just change the file name as shown here:
The retail environment has experienced far-reaching changes over the past year. With the pandemic fundamentally shifting
how customers interact with retailers, digital sales had to evolve at warp...
Checking faillog
You might check out the
faillog
command, but this command looks at the
/var/log/faillog
file
which does not seem to be used on many systems these days. If you use the
faillog -a
command
and get output like that shown below listing 12/31/69 as in the time columns, it's clear this file is
not
in
use.
$ faillog -a
Login Failures Maximum Latest On
root 0 0 12/31/69 19:00:00 -0500
daemon 0 0 12/31/69 19:00:00 -0500
bin 0 0 12/31/69 19:00:00 -0500
sys 0 0 12/31/69 19:00:00 -0500
The dates and times shown refer back to the beginning of Unix (01/01/70)--probably corrected for the local time zone. If you
run the commands shown below, you can verify that the file is not empty, but contains no real data:
If the
faillog
file is actually in use, you should see recent activity and no
references to 1969.
How to respond
Failed logins can happen for many reasons. It may be that one of your users tried to log in with their caps-lock key on and
didn't notice. Maybe they recently changed their password and forgot that they did so and were trying the old one. Maybe
they're trying the password they use on a different system. If one particular account frequently shows up when you run your
queries, you might look into it. However, an occasional failed login attempt is fairly common.
SponsoredPost
Sponsored by
Dell
Technologies and Intel®
AeroFarms takes vertical farming to new heights with edge and AI solutions that deliver data-driven insights.
Checking your settings
To see how your system is set up to deal with failed logins, check out the
/etc/pam.d/common-auth
file
. It's used on systems with the Linux Pluggable Authentication Modules (PAM). Two settings in this file control
how many failed login attempts will be tolerated before an account is temporarily locked and how long the account will be
locked.
A line like this one will have PAM locking an account after six failed login attempts. The lockout will last for five minutes
(300 seconds).
Occasional failed logins are to be expected, but it's still a good idea to be familiar with how your system is configured and
run a query from time to time to get a handle on how much of this kind of activity is taking place. One good way to do this is
to run the query as a
cron
job and email the output to yourself.
Linux users should immediately patch a serious vulnerability to the sudo
command that, if exploited, can allow unprivileged users gain root privileges on the host
machine.
Called Baron Samedit, the flaw has been "hiding in plain sight" for about 10 years, and was
discovered earlier this month by researchers at Qualys and reported to sudo developers, who
came up with patches Jan. 19, according to
a Qualys blog . (The blog includes a video of the flaw being exploited.)
A new version of sudo -- sudo v1.9.5p2 -- has been created to patch the
problem, and notifications have been posted for many Linux distros including Debian, Fedora,
Gentoo, Ubuntu, and SUSE, according to Qualys.
According to the common vulnerabilities and exposures (CVE) description of Baron Samedit (
CVE-2021-3156 ), the flaw can
be exploited "via 'sudoedit -s' and a command-line argument that ends with a single backslash
character."
According to Qualys, the flaw was introduced in July 2011 and affects legacy versions from
1.8.2 to 1.8.31p2 as well as default configurations of versions from 1.9.0 to 1.9.5p1.
The Unofficial Way To Migrate To AlmaLinux From CentOS 8
Written by
Sk
February
3, 2021
1053
Views
1 comment
3
AlmaLinux beta is already out! You can read the details in our
previous
post
. I hope you all are exploring the beta version. Some of you might be wondering when will the AlmaLinux
developers release a tool to migrate CentOS to AlamaLinux. While there is no news from the AlamaLinux team yet, I came
across an unofficial way to migrate to AlmaLinux from CentOS 8 on Reddit.
A Reddit user has provided a simple
workaround
for
the impatient users who wants to migrate to AlmaLinux. I followed the steps and It worked! I can able to successfully
convert CentOS 8 to AlmaLinux beta version using the steps provided below. The migration process was smooth and
straightforward!
Before migrating to AlmaLinux,
backup
all important data
from your CentOS system. I tested it on a freshly installed CentOS 8 virtual machine. My
CentOS VM has no data and it is a minimal installation. I would not recommend this method to migrate production systems. I
strongly suggest you to test this method in your testing machine and then decide whether you want proceed the migration.
If you're not sure what to do, it is really better to wait for the official script from AlmaLinux developers.
Migrate To AlmaLinux From CentOS 8
First, update your CentOS 8 system using command as
root
or
sudo
user:
$ sudo dnf update -y
Reboot your CentOS system after the update is completed.
$ sudo reboot
Next, remove all CentOS gpg keys, repositories and branding details such as backgrounds, logos etc.
If it is a CentOS desktop system, run the following command to remove all aforementioned details:
Finally, migrate to AlmaLinux from the CentOS 8 system using command:
$ sudo dnf distro-sync -y
Migrate To AlmaLinux From CentOS 8
This command will install some new packages, upgrade and downgrade some existing packages, reinstall a few packages and
delete some packages. This will take a while depending upon the Internet connection speed and the total number of installed
packages in your CentOS system. Please be patient. For me, It took around 20 minutes.
After the migration is completed, reboot your system:
$ sudo reboot
Now your system will boot to the newly migrated AlmaLinux system:
How that can beat Oracle offer is unclear. Also at least two additional alternatives to
CentOS are in the pipeline. AlmaLinux is due to be released in Q2 2021, is derived from
CloudLinux, which an existing commercial downstream RHEL distribution. Rocky Linux from CentOS
co-founder Gregory Kurtzer is also making progress and will be released this year.
One group that Red Hat already knows is deploying millions of CentOS installs are web
hosting companies, who are using CentOS because they have in-house RHEL expertise and therefore
don't require support. Their hosting plans typically default to CentOS, while including options
for other free Linux distributions, such as Ubuntu or Debian, for those who want them
Red Hat knowingly allowed tens of thousands (or more) of people to undergo upgrades from CentOS7 to CentOS8, while knowing
they were going to pull the plug on CentOS8. Its a huge breach of trust, borderline fraud... So it would be fair if the lose some licenses
to Oracle which still provides equivalent to CentOs free of charge.
Notable quotes:
"... I'll be damned if OEL isn't a stable equivalent of RHEL. In many cases, it feels like it's more stable. ..."
"... And they have a CentOS -> OEL migration script that you could run and then you could buy their service. RedHat did not support that for a long time, so they were just leaving money/customers on the table. That seems to have changed recently, but too little too late. ..."
...I'll be damned if OEL isn't a stable equivalent of RHEL. In many cases, it feels
like it's more stable. Download it and try it yourself:
https://yum.oracle.com/oracle-linux-isos.html
And they have a CentOS -> OEL migration script that you could run and then you could buy their service. RedHat did not support
that for a long time, so they were just leaving money/customers on the table. That seems to have changed recently, but too little
too late.
VirtualBox itself is GPLv2, so there's not a lot Oracle can do. The problem is the Extension Pack which is free only for personal/evaluation
use; for commercial use it must be purchased.
It is unclear whether it will be competitive with Oracle linux or not... The amount of funds
they have is much less then in case of Oracle. As they already market clone of ISM then have
substantial synergy, although not to the extent Oracle has as it need to tune it to the needs of
its database division and cell commercial version of the clone which helps to recoup the costs.
.
The Linux server operating system also now has a proper name: AlmaLinux. It was
originally dubbed "Lenix" as a placeholder. Alma is Latin for "hope."
While the exact number of servers running CentOS is an unknown, Seletskiy is in a unique
position to make an educated guess..."
"I cannot say the total number, but I'm sure that in enterprise use it's to the tune of
five to ten million CentOS servers."
..."I don't know how much it will cost, to be honest," Seletskiy told us. "I know that it
will definitely be at least to the tune of half a million or more."
The money will be spent in part to hire developers to maintain support for JBoss and other
software that is essential to enterprise workloads, he said, in addition to the cost of
creating a nonprofit organization that will hold the project's trademarks and assure members
that the project will be community controlled.
There was some hope last year that IBM was finally turning things around: after all, after 5
consecutive quarters of declining revenues, the company had just managed to grow its top-line
for the first time since Q2 2018 - when revenue grew by a paltry 0.1% - and only for the 4th
time in the past 8 years. Alas it was not meant to be, and moments ago IBM revealed that
revenue declined again in Q4, dropping for the third consecutive quarter, sliding a whopping
6.5%, the biggest decline since 2015 - and while Red Hat revenue rose by 19%, boosting cloud
revenue by 10% (including $738MM in internal revenue), total external cloud and cognitive
revenues of $6.8 billion once again missed expectations of $7.3BN, and more ominously, were a
decline of 4.5% from last year.
Then again "boosted" may be using the term loosely: at $20.4BN in total revenue, and once
again missing consensus expectations of a $20.6BN print, IBM's Q4 2020 was its worst fourth
quarter for sales this century.
Some more Q4 revenue details, which missed across all key categories, including cloud and
cognitive:
Cloud and cognitive software revenue $6.84 billion, estimate $7.26 billion
Global business services revenue $4.17 billion, estimate $4.17 billion
Global technology services revenue $6.57 billion, estimate $6.79 billion
Systems revenue $2.50 billion, estimate $2.48 billion
Adjusted gross margin 52.5%, estimate 51.2%
Total cloud revenue of $7.5 billion, up 10%
Red Hat revenue up 19%, normalized for historical comparability
And visually:
And while IBM's Q4 adjusted, non-GAAP EPS of $2.07 beat expectations of $1.79, if down a
whopping 56% Y/Y, as usual this was the product of lots of "artificial intelligence" and
aggressive accounting magic because the unadjusted EPS was $1.41, or 32% below the adjusted
number. Oh, and the only reason why EPS was this high: IBM reverted to its grotesque
"accounting trick" of slashing its effective tax rate, which in Q4 tumbled to just 1.9% down
from 8.1% a year ago.
But wait there's more, because the GAAP to non-GAAP bridge was, as usual, ridiculous and a
continuation of an "one-time, non-recurring" addback trend that started so many years ago we
can't even remember when, but one thing is certain: none of IBM's multiple-time, recurring
charges are either one-time, or non-recurring.
We have said it before, but we'll say it again: here is IBM's "one-time, non-recurring"
items In Q3...
... and in Q2 ...
.... and in Q1 ...
... and Q4 2019...
And here is the actual "beat" in context:
"We made progress in 2020 growing our hybrid cloud platform as the foundation for our
clients' digital transformations while dealing with the broader uncertainty of the macro
environment," said Arvind Krishna, IBM chairman and chief executive officer. "The actions we
are taking to focus on hybrid cloud and AI will take hold, giving us confidence we can achieve
revenue growth in 2021."
Maybe... and yet just like the past three quarters, IBM did not have enough "visibility"
into the future to give any guidance for 2021.
There was some good news: in Q4, when IBM's free cash flow was $6.1 billion, the company did
not return all of that to shareholders; instead it handed out just $1.5 billion in
dividends.
So where did the remaining cash go? "In 2020 we increased investment in our business across
R&D and CAPEX, and since October, announced the acquisition of seven companies focused on
hybrid cloud and AI," said James Kavanaugh, IBM senior vice president and chief financial
officer. "With solid cash generation, steadily expanding gross profit margins, disciplined
financial management and ample liquidity, we are well positioned for success as the leading
hybrid cloud platform company."
And speaking of cash flow, IBM ended the second quarter with $14.3 billion of cash on hand
which includes marketable securities, up $1.3 billion from Q2. Debt, including Global Financing
debt of $20.9 billion, totaled $65.4, up from $64.7 billion.
And some more good news: it appears that IBM is finally paying down its debt, which,
including Global Financing debt of $21.2 billion, totaled $61.5 billion, down $3.9 billion
since the end of the third quarter, and down $11.5 billion since closing the Red Hat
acquisition.
Bottom line: while IBM's core business remains a melting ice cube, the bigger concern was
the slowdown in Cloud growth, which led to another dismal quarter for revenue and (unadjusted
EPS). Worse, now that IBM is in cash paydown mode, it means little to no growth opportunities,
and after algos read through the boilerplate, was enough to send IBM stock tumbled over 3%,
erasing all gains for 2021.
Vampire squid does not take prisoner it its pursuit for money ;-) It seems fitting that IBM
brass hire a financial predator like Cohn in a bid to increase profitability at all cost. Red Hat
users should probably take a note.
Gary Cohn, the onetime No. 2 at Goldman Sachs who left the vampire squid (and cashed out
hundreds of millions in performance-based incentives, tax free) back in 2017 for what turned
out to be a brief, but tumultuous, stint in the Trump Administration, is returning to the
boardroom and the c-suite.
After launching a SPAC, Cohn is headed to IBM, where he will serve as vice chairman and a
member of the executive leadership team.
Cohn recently made headlines for refusing to return some $10MM in compensation paid out by
Goldman Sachs. Cohn was the lone executive among a group of current and former Goldman leaders
who stiffed the bank, which tried to claw back the bonus money as a kind of penance for
Goldman's involvement in
the 1MDB scandal.
Then again, hiring Cohn makes sense in at least one respect. As Big Blue scrambles to open
up new markets and business lines...
stockmarketpundit 32 minutes ago
In the timeless wisdom of George Carlin, "It's a big club and you ain't in it."
J J Pettigrew 29 minutes ago (Edited)
Its a small club...the rotating board member game..
You sit I my board, I'll sit on Jim's (any name) board, Jim sits on your board...and we
will all vote for heavy compensations and stock options...
see you in West Palm....
BlueLightning 10 minutes ago (Edited)
These parasites just go from one gravy train job to another. Just one big club!
Five_Black_Eyes_Intel_Agency 23 minutes ago
My all time favourite revolving door pathway is when execs jump from corporations to
regulatory bodies, and back to corporations again.
Wonders get achieved, like tax evasion, forcing Americans to pay the highest drug prices
in the OECD, and fantastic free lunches sponsored by US taxpayers.
convert2rhel is an RPM package which contains a Python2.x script written in completely
incomprehensible over-modulazed manner. Python obscurantism in action ;-)
Looks like a "backbox" tool unless you know Python well. As such it is dangerous to rely upon.
Ensure that you have an access to RHEL packages through custom repositories configured
in the /etc/yum.repos.d/ directory and pointing, for example, to RHEL ISO , FTP, or
HTTP. Note that the OS will be converted to the version of RHEL provided by these
repositories. Make sure that the RHEL minor version is the same or later than the original
OS minor version to prevent downgrading and potential conversion failures. See
instructions on how to configure a repository .
Recommended: Update packages from the original OS to the latest version that is
available in the repositories accessible from the system, and restart the
system:
Without performing this step, the rollback feature will not work
correctly, and exiting the conversion in any phase may result in a dysfunctional
system.
IMPORTANT:
Before starting the conversion process, back up your system.
NOTE: Packages that are available only in the original distribution and do not have
corresponding counterparts in RHEL repositories, or third-party packages, which
originate neither from the original Linux distribution nor from RHEL, are left
unchanged.
Before Convert2RHEL starts replacing packages from the original
distribution with RHEL packages, the following warning message is
displayed:
The tool allows rollback of any action until this point.
By continuing all further changes on the system will need to be reverted manually by the user, if necessary.
Changes made by Convert2RHEL up to this point can be automatically
reverted. Confirm that you wish to proceed with the conversion process.
Wait until Convert2RHEL installs the RHEL packages.
NOTE: After a successful conversion, the utility prints out the
convert2rhel command with all arguments necessary for running
non-interactively. You can copy the command and use it on systems with a similar
setup.
At this point, the system still runs with the original distribution kernel loaded in
RAM. Reboot the system to boot into the newly installed RHEL kernel.
Remove third-party packages from the original OS that remained unchanged (typically
packages that do not have a RHEL counterpart). To get a list of such packages,
use:
# yum list extras --disablerepo="*" --enablerepo=<RHEL_RepoID>
If necessary, reconfigure system services after the conversion.
TroubleshootingLogs
The Convert2RHEL utility stores the convert2rhel.log file in
the /var/log/convert2rhel/ directory. Its content is identical to what is
printed to the standard output.
The output of the rpm -Va command, which is run automatically unless the
--no-rpm-va option is used, is stored in the
/var/log/convert2rhel/rpm_va.log file for debugging purposes.
The Link to "instructions on how to configure a repository." is not working (404).
Also it would be great if the tool installs the repos that are needed for the conversion
itself.
Thanks, Stefan, for pointing that out. Before we fix that, you can use this link:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-yum#sec-Setting_repository_Options
Regarding the second point of yours - this article explains how to use convert2rhel
with custom repositories. Since Red Hat does not have the RHEL repositories public, we
leave it up to the user where they obtain the RHEL repositories. For example, when they
have a subscribed RHEL system in their company, they can create a mirror of the RHEL
repositories available on that system by following this guide:
https://access.redhat.com/solutions/23016.
However, convert2rhel is also able to connect to Red Hat Subscription Management
(RHSM), and for that you need to provide the subscription-manager package and pass the
subscription credentials to convert2rhel. Then the convert2rhel chooses the right
repository to use for the conversion. You can find the step by step guide for that in
https://www.redhat.com/en/blog/converting-centos-rhel-convert2rhel-and-satellite.
We are working on improving the user experience related to the use of RHSM.
It might surprise you to know that if you
forget to flip the network interface card (NIC) switch to the ON position (shown in the image below) during
installation, your Red Hat-based system will boot with the NIC disconnected:
Image
Setting the NIC to the ON position during installation.
More Linux resources
But, don't worry, in this article I'll
show you how to set the NIC to connect on every boot and I'll show you how to disable/enable your NIC on demand.
If your NIC isn't enabled at startup, you
have to edit the
/etc/sysconfig/network-scripts/ifcfg-NIC_name
file,
where NIC_name is your system's NIC device name. In my case, it's enp0s3. Yours might be eth0, eth1, em1, etc.
List your network devices and their IP addresses with the
ip
addr
command:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:81:d0:2d brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
Note that my primary NIC (enp0s3) has no
assigned IP address. I have virtual NICs because my Red Hat Enterprise Linux 8 system is a VirtualBox virtual
machine. After you've figured out what your physical NIC's name is, you can now edit its interface configuration
file:
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-enp0s3
and change the
ONBOOT="no"
entry
to
ONBOOT="yes"
as
shown below:
You don't need to reboot to start the NIC,
but after you make this change, the primary NIC will be on and connected upon all subsequent boots.
To enable the NIC, use the
ifup
command:
ifup enp0s3
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5)
Now the
ip
addr
command displays the enp0s3 device with an IP address:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:81:d0:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.64/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
valid_lft 86266sec preferred_lft 86266sec
inet6 2600:1702:a40:88b0:c30:ce7e:9319:9fe0/64 scope global dynamic noprefixroute
valid_lft 3467sec preferred_lft 3467sec
inet6 fe80::9b21:3498:b83c:f3d4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
To disable a NIC, use the
ifdown
command.
Please note that issuing this command from a remote system will terminate your session:
ifdown enp0s3
Connection 'enp0s3' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5)
That's a wrap
It's frustrating to encounter a Linux
system that has no network connection. It's more frustrating to have to connect to a virtual KVM or to walk up to
the console to fix it. It's easy to miss the switch during installation, I've missed it myself. Now you know how
to fix the problem and have your system network-connected on every boot, so before you drive yourself crazy with
troubleshooting steps, try the
ifup
command
to see if that's your easy fix.
When you press a machine's power button, the boot process starts with a hardware-dependent
mechanism that loads a bootloader . The bootloader software finds the kernel on the disk
and boots it. Next, the kernel mounts the root filesystem and executes an init
process.
This process sounds simple, and it might be what actually happens on some Linux systems.
However, modern Linux distributions have to support a vast set of use cases for which this
procedure is not adequate.
First, the root filesystem could be on a device that requires a specific driver. Before
trying to mount the filesystem, the right kernel module must be inserted into the running
kernel. In some cases, the root filesystem is on an encrypted partition and therefore needs a
userspace helper that asks the passphrase to the user and feeds it to the kernel. Or, the root
filesystem could be shared over the network via NFS or iSCSI, and mounting it may first require
configured IP addresses and routes on a network interface.
To overcome these issues, the bootloader can pass to the kernel a small filesystem image
(the initrd) that contains scripts and tools to find and mount the real root filesystem. Once
this is done, the initrd switches to the real root, and the boot continues as usual.
The
dracut infrastructure
On Fedora and RHEL, the initrd is built through dracut . From its home page , dracut is "an event-driven initramfs
infrastructure. dracut (the tool) is used to create an initramfs image by copying tools and
files from an installed system and combining it with the dracut framework, usually found in
/usr/lib/dracut/modules.d ."
A note on terminology: Sometimes, the names initrd and initramfs are used
interchangeably. They actually refer to different ways of building the image. An initrd is an
image containing a real filesystem (for example, ext2) that gets mounted by the kernel. An
initramfs is a cpio archive containing a directory tree that gets unpacked as a tmpfs.
Nowadays, the initrd images are deprecated in favor of the initramfs scheme. However, the
initrd name is still used to indicate the boot process involving a temporary
filesystem.
Kernel command-line
Let's revisit the NFS-root scenario that was mentioned before. One possible way to boot via
NFS is to use a kernel command-line containing the root=dhcp argument.
The kernel command-line is a list of options passed to the kernel from the bootloader,
accessible to the kernel and applications. If you use GRUB, it can be changed by pressing the e
key on a boot entry and editing the line starting with linux .
The dracut code inside the initramfs parses the kernel command-line and starts DHCP on all
interfaces if the command-line contains root=dhcp . After obtaining a DHCP lease,
dracut configures the interface with the parameters received (IP address and routes); it also
extracts the value of the root-path DHCP option from the lease. The option carries an NFS
server's address and path (which could be, for example, 192.168.50.1:/nfs/client
). Dracut then mounts the NFS share at this location and proceeds with the boot.
If there is no DHCP server providing the address and the NFS root path, the values can be
configured explicitly in the command line:
The first can be used for automatic configuration (DHCP or IPv6 SLAAC), and the second for
static configuration or a combination of automatic and static. Here some examples:
Note that if you pass an ip= option, but dracut doesn't need networking to
mount the root filesystem, the option is ignored. To force network configuration without a
network root, add rd.neednet=1 to the command line.
You probably noticed that among automatic configuration methods, there is also ibft .
iBFT stands for iSCSI Boot Firmware Table and is a mechanism to pass parameters about iSCSI
devices from the firmware to the operating system. iSCSI (Internet Small Computer Systems
Interface) is a protocol to access network storage devices. Describing iBFT and iSCSI is
outside the scope of this article. What is important is that by passing ip=ibft to
the kernel, the network configuration is retrieved from the firmware.
Dracut also supports adding custom routes, specifying the machine name and DNS servers,
creating bonds, bridges, VLANs, and much more. See the dracut.cmdline man page for more
details.
Network modules
The dracut framework included in the initramfs has a modular architecture. It comprises a
series of modules, each containing scripts and binaries to provide specific functionality. You
can see which modules are available to be included in the initramfs with the command
dracut --list-modules .
At the moment, there are two modules to configure the network: network-legacy
and network-manager . You might wonder why different modules provide the same
functionality.
network-legacy is older and uses shell scripts calling utilities like
iproute2 , dhclient , and arping to configure
interfaces. After the switch to the real root, a different network configuration service runs.
This service is not aware of what the network-legacy module intended to do and the
current state of each interface. This can lead to problems maintaining the state across the
root switch boundary.
A prominent example of a state to be kept is the DHCP lease. If an interface's address
changed during the boot, the connection to an NFS share would break, causing a boot
failure.
To ensure a seamless transition, there is a need for a mechanism to pass the state between
the two environments. However, passing the state between services having different
configuration models can be a problem.
The network-manager dracut module was created to improve this situation. The
module runs NetworkManager in the initrd to configure connection profiles generated from the
kernel command-line. Once done, NetworkManager serializes its state, which is later read by the
NetworkManager instance in the real root.
Fedora 31 was the first distribution to switch to network-manager in initrd by
default. On RHEL 8.2, network-legacy is still the default, but
network-manager is available. On RHEL 8.3, dracut will use
network-manager by default.
Enabling a different network module
While the two modules should be largely compatible, there are some differences in behavior.
Some of those are documented in the nm-initrd-generator man page. In general, it
is suggested to use the network-manager module when NetworkManager is enabled.
To rebuild the initrd using a specific network module, use one of the following
commands:
The --regenerate-all option also rebuilds all the initramfs images for the
kernel versions found on the system.
The network-manager dracut module
As with all dracut modules, the network-manager module is split into stages
that are called at different times during the boot (see the dracut.modules man page for more
details).
The first stage parses the kernel command-line by calling
/usr/libexec/nm-initrd-generator to produce a list of connection profiles in
/run/NetworkManager/system-connections . The second part of the module runs after
udev has settled, i.e., after userspace has finished handling the kernel events for devices
(including network interfaces) found in the system.
When NM is started in the real root environment, it registers on D-Bus, configures the
network, and remains active to react to events or D-Bus requests. In the initrd, NetworkManager
is run in the configure-and-quit=initrd mode, which doesn't register on D-Bus
(since it's not available in the initrd, at least for now) and exits after reaching the
startup-complete event.
The startup-complete event is triggered after all devices with a matching connection profile
have tried to activate, successfully or not. Once all interfaces are configured, NM exits and
calls dracut hooks to notify other modules that the network is available.
Note that the /run/NetworkManager directory containing generated connection
profiles and other runtime state is copied over to the real root so that the new NetworkManager
process running there knows exactly what to do.
Troubleshooting
If you have network issues in dracut, this section contains some suggestions for
investigating the problem.
The first thing to do is add rd.debug to the kernel command-line, enabling debug logging in
dracut. Logs are saved to /run/initramfs/rdsosreport.txt and are also available in
the journal.
If the system doesn't boot, it is useful to get a shell inside the initrd environment to
manually check why things aren't working. For this, there is an rd.break command-line argument.
Note that the argument spawns a shell when the initrd has finished its job and is about to give
control to the init process in the real root filesystem. To stop at a different stage of dracut
(for example, after command-line parsing), use the following argument:
The initrd image contains a minimal set of binaries; if you need a specific tool at the
dracut shell, you can rebuild the image, adding what is missing. For example, to add the ping
and tcpdump binaries (including all their dependent libraries), run:
# dracut -f --install "ping tcpdump"
and then optionally verify that they were included successfully:
If you are familiar with NetworkManager configuration, you might want to know how a given
kernel command-line is translated into NetworkManager connection profiles. This can be useful
to better understand the configuration mechanism and find syntax errors in the command-line
without having to boot the machine.
The generator is installed in /usr/libexec/nm-initrd-generator and must be
called with the list of kernel arguments after a double dash. The --stdout option
prints the generated connections on standard output. Let's try to call the generator with a
sample command line:
$ /usr/libexec/nm-initrd-generator --stdout -- \
ip=enp1s0:dhcp:00:99:88:77:66:55 rd.peerdns=0
802-3-ethernet.cloned-mac-address: '99:88:77:66:55' is not a valid MAC
address
In this example, the generator reports an error because there is a missing field for the MTU
after enp1s0 . Once the error is corrected, the parsing succeeds and the tool prints out the
connection profile generated:
Note how the rd.peerdns=0 argument translates into the ignore-auto-dns=true property, which
makes NetworkManager ignore DNS servers received via DHCP. An explanation of NetworkManager
properties can be found on the nm-settings man page.
The NetworkManager dracut module is enabled by default in Fedora and will also soon be
enabled on RHEL. It brings better integration between networking in the initrd and
NetworkManager running in the real root filesystem.
While the current implementation is working well, there are some ideas for possible
improvements. One is to abandon the configure-and-quit=initrd mode and run
NetworkManager as a daemon started by a systemd service. In this way, NetworkManager will be
run in the same way as when it's run in the real root, reducing the code to be maintained and
tested.
To completely drop the configure-and-quit=initrd mode, NetworkManager should
also be able to register on D-Bus in the initrd. Currently, dracut doesn't have any module
providing a D-Bus daemon because the image should be minimal. However, there are already
proposals to include it as it is needed to implement some new features.
With D-Bus running in the initrd, NetworkManager's powerful API will be available to other
tools to query and change the network state, unlocking a wide range of applications. One of
those is to run nm-cloud-setup in the initrd. The service, shipped in the
NetworkManager-cloud-setup Fedora package fetches metadata from cloud providers'
infrastructure (EC2, Azure, GCP) to automatically configure the network.
... DTrace gives the operational insights that have long been missing in the data center,
such as memory consumption, CPU time or what specific function calls are being made.
Designed for use on production systems to troubleshoot performance bottlenecks
Provides a single view of the software stack - from kernel to application - leading to
rapid identification of performance bottlenecks
Dynamically instruments kernel and applications with any number of probe points,
improving the ability to service software
Enables maximum resource utilization and application performance, as well as precise
quantification of resource requirements
Fast and easy to use, even on complex systems with multiple layers of software
Developers can learn about and experiment with DTrace on Oracle Linux by installing the
appropriate RPMs:
For Unbreakable Enterprise Kernel Release 5 (UEK5) on Oracle Linux 7
dtrace-utils and dtrace-utils-devel .
For Unbreakable Enterprise Kernel Release 6 (UEK6) on Oracle Linux 7 and Oracle Linux 8
dtrace and dtrace-devel .
Stability
It's well known that Red Hat Enterprise Linux is created from the most stable and tested
Fedora innovations, but since Oracle Linux was grown from the RHEL framework yet includes
additional, built-in integrations and optimizations specifically tailored for Oracle
products, our comparison showed that Oracle Linux is actually more stable for enterprises
running Oracle systems , including Oracle databases.
Flexibility
As an industry leader, RHEL provides a wide range of integrated applications and tools that
help tailor fit the Red Hat Enterprise Linux system to highly specific business needs.
However, once again Oracle Linux was found to excel over RHEL because OL offered the Red Hat
Compatible Kernel (RHCK), option, which enables any RHEL-certified app to run on Oracle Linux
. In addition, OL offers its own network of ISVs / third-party solutions, which can help
personalize your Linux setup even more while integrating seamlessly with your on-premises or
cloud-based Oracle systems.
If you are on CentOS-7 then you will probably be okay until RedHat pulls the plug on
2024-06-30 so do don't do anything rash. If you are on CentOS-8 then your days are numbered (to
~ 365) because this OS will shift from major-minor point updates to a streaming model at the
end of 2021. Let's look at two early founders: SUSE started in Germany in 1991 whilst RedHat
started in America a year later. SUSE sells support for SLE (Suse Linux Enterprise) which means
you need a license to install-run-update-upgrade it. Likewise RedHat sells support for RHEL
(Red Hat Enterprise Linux). SUSE also offers "openSUSE Leap" (released once a year as a
major-minor point release of SLE) and "openSUSE Tumbleweed" (which is a streaming thingy). A
couple of days ago I installed "OpenSUSE Leap" onto an old HP-Compaq 6000 desktop just to try
it out (the installer actually had a few features I liked better than the CentOS-7 installer).
When I get back to the office in two weeks, I'm going to try installing "OpenSUSE Leap" onto an
HP-DL385p_gen8. I'll work with this for a few months and I am comfortable, I will migrate my
employer's solution over to "OpenSUSE Leap".
Parting thoughts:
openSUSE is run out of Germany. IMHO switching over to a European distro is similar to
those database people who preferred MariaDB to MySQL when Oracle was still hoping that
MySQL would die from neglect.
Someone cracked off to me the other day that now that IBM is pulling strings at "Red
Hat", that the company should be renamed "Blue Hat"
I downloaded and tried it last week and was actually pretty impressed. I have only ever
tested SUSE in the past. Honestly, I'll stick with Red Hat/CentOS whatever, but I was still
impressed. I'd recommend people take a look.
I have been playing with OpenSUSE a bit, too. Very solid this time around. In the past I
never had any luck with it. But Leap 15.2 is doing fine for me. Just testing it virtually. TW
also is pretty sweet and if I were to use a rolling release, it would be among the top
contenders.
One thing I don't like with OpenSUSE is that you can't really, or are not supposed to I
guess, disable the root account. You can't do it at install, if you leave the root account
blank suse, will just assign the password for the user you created to it.
Of course afterwards you can disable it with the proper commands but it becomes a pain with
YAST, as it seems YAST insists on being opened by root.
One thing I don't like with OpenSUSE is that you can't really, or are not supposed to I
guess, disable the root account. You can't do it at install, if you leave the root account
blank suse, will just assign the password for the user you created to it.
I'm running Leap 15.2 on the laptops my kids run for school. During installation, I simply
deselected the option for the account used to be an administrator; this required me to set a
different password for administrative purposes.
I think you might.
My point is/was that if I select to choose my regular user to be admin, I don't expect for
the system to create and activate a root account anyways and then just assign it my
password.
I expect the root account to be disabled.
I was surprised, too. I was bit "shocked" when I realized, after the install, that I could
login as root with my user password.
At the very least, IMHO, it should then still have you set the root password, even if you
choose to make your user admin.
It for one lets you know that OpenSUSE is not disabling root and two gives you a chance to
give it a different password.
But other than that subjective issue I found OpenSUSE Leap a very solid distro.
The big academic labs (Fermilab, CERN and DESY to only name three of many used to run
something called Scientific Linux which was also maintained by Red Hat.see: https://scientificlinux.org/ and https://en.wikipedia.org/wiki/Scientific_Linux
Shortly after Red Hat acquired CentOS in 2014, Red Hat convinced the big academic labs to begin
migrating over to CentOS (no one at that time thought that Red Hat would become Blue Hat)
11 comments 67% Upvoted Log in or sign up to leave a comment
Log In Sign Up Sort by level 1
Scientific Linux is not and was not maintained by Red Hat. Like CentOS, when it was truly
a community distribution, Scientific Linux was an independent rebuild of the RHEL source code
published by Red Hat. It is maintained primarily by people at Fermilab. (It's slightly
different from CentOS in that CentOS aimed for binary compatibility with RHEL, while that is
not a goal of Scientific Linux. In practice, SL often achieves binary compatibility, but if
you have issues with that, it's more up to you to fix them than the SL maintainers.)
I fear you are correct. I just stumbled onto this article: https://www.linux.com/training-tutorials/scientific-linux-great-distro-wrong-name/
Even the wikipedia article states "This product is derived from the free and open-source
software made available by Red Hat, but is not produced, maintained or supported by them."
But it does seem that Scientific Linux was created as a replacement for Fermilab Linux.
I've also seen references to CC7 to mean "Cern Centos 7". CERN is keeping their Linux page
up to date because what I am seeing here ( https://linux.web.cern.ch/ ) today is not what I saw
2-weeks ago.
RedHat didn't convince them to stop using Scientific Linux, Fermilab no longer needed to
have their own rebuild of RHEL sources. They switched to CentOS and modified CentOS if they
needed to (though I don't really think they needed to)
SL has always been an independent rebuild. It has never been maintained, sponsored, or
owned by Red Hat. They decided on their own to not build 8 and instead collaborate on
CentOS. They even gained representation on the CentOS board (one from Fermi, one from
CERN).
I'm not affiliated with any of those organizations, but my guess is they will switch to
some combination of CentOS Stream and RHEL (under the upcoming no/low cost program).
Is anybody considering switching to RHEL's free non-production developer
subscription? As I understand it, it is free and receives updates.
The only downside as I understand it is that you have to renew your license every year (and
that you can't use it in commercial production).
In
view of the such effective and free promotion of Oracle Linux by IBM/Red Hat brass as the top replacement for
CentOS, the script can probably be slightly enhanced.
The script works well for simple systems, but still has some sharp edges. Checks for common bottlenecks should be added. For
exmple scale in /boot should be checked if this is a separate filesystem. It was not done. See my Also, in case
it was invoked the second time after the failure of the step "Installing base packages for Oracle
Linux..." it can remove hundreds of system RPM (including sshd, cron, and several other vital
packages ;-).
And failures on this step are probably the most common type of failures in conversion.
Inexperienced sysadmins or even experienced sysadmins in a hurry often make this blunder running
the script the second time.
It probably happens due to the presence of the line 'yum remove -y "${new_releases[@]}" ' in the
function remove_repos, because in their excessive zeal to restore the system after error the
programmers did not understand that in certain situations those packages that they want to delete via YUM have dependences and a lot
of them (line 65 in the current version of the script) Yum blindly deletes over 300 packages including such vital as sshd, cron, etc. Due to this execution of the script probably
should be blocked if Oracle repositories are already present. This check is absent.
After this "mass extinction of RPM packages," event you need to be pretty well versed in yum to recover. The names of
the deleted packages are in yum log, so you can reinstall them and something it helps. In other
cases system remain unbootable and the restore from the backup is the only option.
Due sudden surge of popularity of Oracle Linux due to Red Hat CentOS8 fiasco, the script definitely can benefit from better diagnostics.
The current diagnostic is very rudimentary. It might also make sense to make steps modular in the classic /etc/init.d fashion and
make initial steps shippable so that the script can be resumed after the error. Most of the steps have few dependencies, which
can be resolved by saving variables during the first run and sourcing them if the the first step is not step 1.
Also, it makes sense to check the amount of free space in /boot filesystem if /boot is a
separate filesystem. The script requires approx 100MB of free space in this filesystem. Failure
to write a new kernel to it due to the lack of free space leads to the situation of "half-baked"
installation, which is difficult to recover without senior sysadmin skills.
Oracle Linux is free to download, distribute and use (even in production) and has been
since its release over 14 years ago
Installation media, updates and source code are all publicly available on the Oracle
Linux yum server with no login or authentication requirements
Since its first release in 2006, Oracle Linux has been 100% application binary
compatible with the equivalent RHEL version. In that time, we have never had a
compatibility bug logged.
The script can switch CentOS Linux 6, 7 or 8 to the equivalent version of Oracle Linux.
Let's take a look at just how simple the process is.
Download the centos2ol.sh
script from GitHub
The simplest way to get the script is to use curl :
$ curl -O https://raw.githubusercontent.com/oracle/centos2ol/main/centos2ol.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10747 100 10747 0 0 31241 0 --:--:-- --:--:-- --:--:-- 31241
If you have git installed, you could clone the git repository from GitHub
instead.
Run the centos2ol.sh script to switch to Oracle Linux
To switch to Oracle Linux, just run the script as root using sudo
:
As part of the process, the default kernel is switched to the latest release of Oracle's
Unbreakable Enterprise Kernel (UEK) to enable extensive performance and scalability
improvements to the process scheduler, memory management, file systems, and the networking
stack. We also replace the existing CentOS kernel with the equivalent Red Hat Compatible
Kernel (RHCK) which may be required by any specific hardware or application that has
imposed strict kernel version restrictions.
Switching the default kernel (optional)
Once the switch is complete, but before rebooting, the default kernel can be changed
back to the RHCK. First, use grubby to list all installed kernels:
In the output above, the first entry (index 0) is UEK R6, based on the mainline kernel
version 5.4. The second kernel is the updated RHCK (Red Hat Compatible Kernel) installed by
the switch process while the third one is the kernel that were installed by CentOS and the
final entry is the rescue kernel.
Next, use grubby to verify that UEK is currently the default boot option:
To replace the default kernel, you need to specify either the path to its
vmlinuz file or its index. Use grubby to get that information for the
replacement:
Finally, use grubby to change the default kernel, either by providing the
vmlinuz path:
[demo@c8switch ~]$ sudo grubby --set-default /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
The default is /boot/loader/entries/0dbb9b2f3c2744779c72a28071755366-4.18.0-240.1.1.el8_3.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
Or its index:
[demo@c8switch ~]$ sudo grubby --set-default-index 1
The default is /boot/loader/entries/0dbb9b2f3c2744779c72a28071755366-4.18.0-240.1.1.el8_3.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
Changing the default kernel can be done at any time, so we encourage you to take UEK for
a spin before switching back.
The last of the RHEL downstreams up for discussion today is Hewlett-Packard Enterprise's
in-house distro, ClearOS .
Hewlett-Packard makes ClearOS available as a pre-installed option on its ProLiant server line,
and the company offers a free Community version to all comers.
ClearOS is an open source software platform that leverages the open source model to
deliver a simplified, low cost hybrid IT experience for SMBs. The value of ClearOS is the
integration of free open source technologies making it easier to use. By not charging for
open source, ClearOS focuses on the value SMBs gain from the integration so SMBs only pay for
the products and services they need and value.
ClearOS is mostly notable here for its association with industry giant HPE and its
availability as an OEM distro on ProLiant servers. It seems to be a bit behind the times -- the
most recent version is ClearOS 7.x, which is in turn based on RHEL 7. In addition to being a
bit outdated compared with other options, it also appears to be a rolling release itself --
more comparable to CentOS Stream itself, than to the CentOS Linux that came before it.
ClearOS is probably most interesting to small business types who might consider buying
ProLiant servers with RHEL-compatible OEM Linux pre-installed later.
I've seen a lot of folks mistakenly recommending the deceased Scientific Linux distro as a
CentOS replacement -- that won't work, because Scientific Linux itself was deprecated in favor
of CentOS. However, Springdale
Linux is very similar -- like Scientific Linux, it's a RHEL rebuild distro made by and for
the academic scientific community. Unlike Scientific Linux, it's still actively maintained!
Springdale Linux is maintained and made available by Princeton and Rutgers universities, who
use it for their HPC projects. It has been around for quite a long time. One Springdale Linux
user from Carnegie Mellon describes their own experience with Springdale (formerly PUIAS --
Princeton University Institute for Advanced Study) as a 10-year ride.
Theresa Arzadon-Labajo, one of Springdale Linux's maintainers, gave a pretty good
seat-of-the-pants overview in a recent mailing list discussion :
The School of Mathematics at the Institute for Advanced Study has been using Springdale
(formerly PUIAS, then PU_IAS) since its inception. All of our *nix servers and workstations
(yes, workstations) are running Springdale. On the server side, everything "just works", as
is expected from a RHEL clone. On the workstation side, most of the issues we run into have
to do with NVIDIA drivers, and glibc compatibility issues (e.g Chrome, Dropbox, Skype, etc),
but most issues have been resolved or have a workaround in place.
... Springdale is a community project, and [it] mostly comes down to the hours (mostly
Josko) that we can volunteer to the project. The way people utilize Springdale varies. Some
are like us and use the whole thing. Others use a different OS and use Springdale just for
its computational repositories.
Springdale Linux should be a natural fit for universities and scientists looking for a
CentOS replacement. It will likely work for most anyone who needs it -- but its
relatively small community and firm roots in academia will probably make it the most
comfortable for those with similar needs and environments.
64 • "best idea" ... (by Otis on 2020-12-25 19:38:01 GMT from United
States) @62
dang it BSD takes care of all that anxiety about systemd and the other bloaty-with-time worries
as far as I can tell. GhostBSD and a few others are spearheading a charge into the face of The
Enemy, making BSD palatable for those of us steeped in Linux as the only alternative to we know
who.
• Centos (by David on 2020-12-22
04:29:46 GMT from United States)
I was using Centos 8.2 on an older, desktop home computer. When Centos dropped long term
support on version 8, I was a little peeved, but not a whole lot, since it is free, anyway. Out
of curiosity I installed Scientific Linux 7.9 on the same computer, and it works better that
Centos 8. Then I tried installing SL 7.9 on my old laptop -- it even worked on that!
Previously, when I had tried to install Centos 8 on the laptop, an old Dell inspiron 1501,
the graphics were garbage --the screen displayed kind of a color mosaic --and the
keyboard/everthing else was locked up. I also tried Centos 7.9 on it and installation from
minimal dvd produced a bunch of errors and then froze part way through.
I will stick with Scientific Linux 7 for now. In 2024 I will worry about which distro to
migrate to. Note: Scientific Linux websites states that they are going to reconsider (in 1st
quarter of 2021) whether they will produce a clone of rhel version 8. Previously, they stated
that they would not.
"Personal opinion only. [...] After all the years of using Linux, and experiencing
first-hand the hobby mentality that has taken over [...], I prefer to use a distribution which
has all the earmarks of [...] being developed AND MAINTAINED by a professional
organization."
Yeah, your answer is exactly what I expected it to be.
The thing with Springdale is as following: it's maintained by the very professional team of
IT specialists at the Institute for Advanced Study (Princeton University) for the own needs.
That's why there's no fancy website, RHEL Wiki, live ISOs and such.
They also maintain several other repositories for add-on packages (computing, unsupported
[with audio/video codecs] ...).
With other words, if you're a professional who needs an RHEL clone, you'll be fine with it;
if you're a hobbyist who needs a how-to on everything and anything, you can still use the
knowledge base of RHEL/CentOS/Oracle ...
If you're 'small business' who needs a professional support, you'd get RHEL - unlike CentOS,
Springdale is not a commercial distribution selling you support and schooling. Springdale is
made by professional and for the professionals.
In 2010 I had the opportunity to put my hands in the shambles of Oracle Linux during an installation and training mission carried
out on behalf of ASF (Highways of the South of France) which is now called Vinci Autoroutes. I
had just published Linux on the
onions at Eyrolles, and since the CentOS 5.3 distribution on which it was based looked 99%
like Oracle Linux 5.3 under the hood, I had been chosen by the company ASF to train their
future Linux administrators.
All these years, I knew that Oracle Linux existed, as did another series of Red Hat clones
like CentOS, Scientific Linux, White Box Enterprise Linux, Princeton University's PUIAS
project, etc. I didn't care any more, since CentOS perfectly met all my server needs.
Following the disastrous announcement of the CentOS project, I had a discussion with my
compatriot Michael Kofler, a Linux guru who
has published a series of excellent books on our favorite operating system, and who has
migrated from CentOS to Oracle Linux for the Linux ad administration courses he teaches at the
University of Graz. We were not in our first discussion on this subject, as the CentOS project
was already accumulating a series of rather worrying delays for version 8 updates. In
comparison, Oracle Linux does not suffer from these structural problems, so I kept this option
in a corner of my head.
A problematic reputation
Oracle suffers from a problematic reputation within the free software community, for a
variety of reasons. It was the company that ruined OpenOffice and Java, put the hook on MySQL
and let Solaris sink. Oracle CEO Larry Ellison has been the center of his name because of his
unhinged support for Donald Trump. As for the company's commercial policy, it has been marked
by a notorious aggressiveness in the hunt for patents.
On the other hand, we have free and free apps like VirtualBox, which run perfectly on millions of developer
workstations all over the world. And then the very discreet Oracle Linux , which works perfectly and without making any noise
since 2006, and which is also a free and free operating system.
Install Oracle Linux
For a first test, I installed Oracle Linux 7.9 and 8.3 in two virtual machines on my
workstation. Since it is a Red Hat Enterprise Linux-compliant clone, the installation procedure
is identical to that of RHEL and CentOS, with a few small details.
Normally, I never care about banner ads that scroll through graphic
installers. This time, the slogan Free to use, free to download, free to update.
Always still caught my attention.
An indestructible kernel?
Oracle Linux provides its own Linux kernel newer than the one provided by Red Hat, and named
Unbreakable Enterprise Kernel (UEK). This kernel is installed by default and replaces
older kernels provided upstream for versions 7 and 8. Here's what it looks like oracle Linux
7.9.
$ uname -a
Linux oracle-el7 5.4.17-2036.100.6.1.el7uek.x86_64 #2 SMP Thu Oct 29 17:04:48
PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
Well-crafted packet deposits
At first glance, the organization of official and semi-official package filings seems much
clearer and better organized than under CentOS. For details, I refer you to the respective
explanatory pages for the 7.x and 8.x versions.
Like the organization of deposits, Oracle Linux's documentation is
worth mentioning here, because it is simply exemplary. The main index refers to the different
versions of Oracle Linux, and from there, you can access a whole series of documents in HTML
and PDF formats that explain in detail the peculiarities of the system and its day-to-day
management. As I go along with this documentation, I discover a multitude of pleasant little
details, such as the fact that Oracle packages display metadata for security updates, which is
not the case for CentOS packages.
Migrating from CentOS to Oracle Linux
The Switch your CentOS
systems to Oracle Linux web page identifies a number of reasons why Oracle Linux is a
better choice than CentOS when you want to have a company-grade free as in free beer
operating system, which provides low-risk updates for each version over a decade. This page
also features a script that transforms an existing CentOS system into a two-command Oracle
Linux system on the fly. centos2ol.sh
The script grinds about twenty minutes, we restart the machine and we end up with a clean
Oracle Linux system. To do some cleaning, just remove the deposits of saved packages.
# rm -f /etc/yum.repos.d/*.repo.deactivated
Migrating a CentOS 8.x server?
At first glance, the script only predicted the migration of CentOS 7.9 to Oracle Linux 7.9.
On a whim, I sent an email to the address at the bottom of the page, asking if support for
CentOS 8.x was expected in the near future. centos2ol.sh
A very nice exchange of emails ensued with a guy from Oracle, who patiently answered all the
questions I asked him. And just twenty-four hours later, he sent me a link to an Oracle Github repository with an
updated version of the script that supports the on-the-fly migration of CentOS 8.x to Oracle
Linux 8.x.
So I tested it with a cool installation of a CentOS 8 server at Online/Scaleway.
Again, it grinds a good twenty minutes, and at the end of the restart, we end up with a
public machine running oracle Linux 8.
Conclusion
I will probably have a lot more to say about that. For my part, I find this first experience
with Oracle Linux rather conclusive, and if I decided to share it here, it is that it will
probably solve a common problem to a lot of admins of production servers who do not support
their system becoming a moving target overnight.
Post Scriptum for the chilly purists
Finally, for all of you who want to use a free and free clone of Red Hat Enterprise Linux
without selling their soul to the devil, know that Springdale Linux is a solid alternative. It is maintained
by Princeton University in the United States according to the principle WYGIWYG (What You
Get Is What You Get ), it is provided raw de-cluttering and without any documentation, but
it works just as well.
Writing this documentation takes time and significant amounts of espresso coffee. Do you
like this blog? Give the editor a coffee by clicking on the cup.
" People are complaining because you are suddenly killing CentOS 8 which has been released last year with the promise of binary
compatibility to RHEL 8 and security updates until 2029."
One of immanent features of GPL is that it allow clones to exist. Which means the Oracle Linix, or Rocky Linux, or Lenin Linux will
simply take CentOS place and Red hat will be in disadvantage, now unable to control the clone to the extent they managed to co-opt and
control CentOS. "Embrace and extinguish" change i now will hand on Red Hat and probably will continue to hand for years from now. That
may not be what Redhat brass wanted: reputational damage with zero of narrative effect on the revenue stream. I suppose the majority
of CentOS community will finally migrate to emerging RHEL clones. If that was the Red Hat / IBM goal - well, they will reach it.
Notable quotes:
"... availability gap ..."
"... Another long-winded post that doesn't address the single, core issue that no one will speak to directly: why can't CentOS Stream and CentOS _both_ exist? Because in absence of any official response from Red Hat, the assumption is obvious: to drive RHEL sales. If that's the reason, then say it. Stop being cowards about it. ..."
"... We might be better off if Red Hat hadn't gotten involved in CentOS in the first place and left it an independent project. THEY choose to pursue this path and THEY chose to renege on assurances made around the non-stream distro. Now they're going to choose to deal with whatever consequences come from the loss of goodwill in the community. ..."
"... If the problem was in money, all RH needed to do was to ask the community. You would have been amazed at the output. ..."
"... You've alienated a few hunderd thousand sysadmins that started upgrading to 8 this year and you've thrown the scientific Linux community under a bus. You do realize Scientific Linux was discontinued because CERN and FermiLab decided to standardize on CentOS 8? This trickled down to a load of labs and research institutions. ..."
"... Nobody forced you to buy out CentOS or offer a gratis distribution. But everybody expected you to stick to the EOL dates you committed to. You boast about being the "Enterprise" Linux distributor. Then, don't act like a freaking start-up that announces stuff today and vanishes a year later. ..."
"... They should have announced this at the START of CentOS 8.0. Instead they started CentOS 8 with the belief it was going to be like CentOS7 have a long supported life cycle. ..."
"... IBM/RH/CentOS keeps replaying the same talking points over and over and ignoring the actual issues people have ..."
"... What a piece of stinking BS. What is this "gap" you're talking about? Nobody in the CentOS community cares about this pre-RHEL gap. You're trying to fix something that isn't broken. And doing that the most horrible and bizzarre way imaginable. ..."
"... As I understand it, Fedora - RHEL - CENTOS just becomes Fedora - Centos Stream - RHEL. Why just call them RH-Alpha, RH-Beta, RH? ..."
Let's go back to 2003 where Red Hat saw the opportunity to make a fundamental change to become an enterprise software company
with an open source development methodology.
To do so Red Hat made a hard decision and in 2003
split Red Hat Linux into Red Hat
Enterprise Linux (RHEL) and Fedora Linux. RHEL was the occasional snapshot of Fedora Linux that was a product -- slowed, stabilized,
and paced for production. Fedora Linux and the Project around it were the open source community for innovating -- speedier, prone
to change, and paced for exploration. This solved the problem of trying to hold to two, incompatible core values (fast/slow) in a
single project. After that, each distribution flourished within its intended audiences.
But that split left two important gaps. On the project/community side, people still wanted an OS that strived to be slower-moving,
stable-enough, and free of cost -- an availability gap . On the product/customer side, there was an openness gap
-- RHEL users (and consequently all rebuild users) couldn't contribute easily to RHEL. The rebuilds arose and addressed the availability
gap, but they were closed to contributions to the core Linux distro itself.
In 2012, Red Hat's move toward offering products beyond the operating system resulted in a need for an easy-to-access platform
for open source development of the upstream projects -- such as Gluster, oVirt, and RDO -- that these products are derived from.
At that time, the pace of innovation in Fedora made it not an easy platform to work with; for example, the pace of kernel updates
in Fedora led to breakage in these layered projects.
We formed a team I led at Red Hat to go about solving this problem, and, after approaching and discussing it with the CentOS Project
core team, Red Hat and the CentOS Project agreed to "
join forces ." We said
joining forces because there was no company to acquire, so we hired members of the core team and began expanding CentOS beyond being
just a rebuild project. That included investing in the infrastructure and protecting the brand. The goal was to evolve into a project
that also enabled things to be built on top of it, and a project that would be exponentially more open to contribution than ever
before -- a partial solution to the openness gap.
Bringing home the CentOS Linux users, folks who were stuck in that availability gap, closer into the Red Hat family was a wonderful
side effect of this plan. My experience going from participant to active open source contributor began in 2003, after the birth of
the Fedora Project. At that time, as a highly empathetic person I found it challenging to handle the ongoing emotional waves from
the Red Hat Linux split. Many of my long time community friends themselves were affected. As a company, we didn't know if RHEL or
Fedora Linux were going to work out. We had made a hard decision and were navigating the waters from the aftershock. Since then we've
all learned a lot, including the more difficult dynamics of an open source development methodology. So to me, bringing the CentOS
and other rebuild communities into an actual relationship with Red Hat again was wonderful to see, experience, and help bring about.
Over the past six years since finally joining forces, we made good progress on those goals. We started
Special Interest Groups (SIGs) to manage the
layered project experience, such as the Storage SIG, Virt Sig, and Cloud SIG. We created a
governance structure where there hadn't been one before. We brought
RHEL source code to be housed at git.centos.org . We designed and built out
a significant public build infrastructure and
CI/CD system in a project that had previously been sealed-boxes all the way
down.
"This brings us to today and the current chapter we are living in right now. The move to shift focus of the project to
CentOS Stream is about filling that openness gap in some key ways. Essentially, Red Hat is filling the development and contribution
gap that exists between Fedora and RHEL by shifting the place of CentOS from just downstream of RHEL to just upstream of RHEL."
Another long-winded post that doesn't address the single, core issue that no one will speak to directly: why can't CentOS
Stream and CentOS _both_ exist? Because in absence of any official response from Red Hat, the assumption is obvious: to drive RHEL sales. If that's the reason, then say it. Stop being cowards about it.
Redhat has no obligation to maintain both CentOS 8 and CentOS stream. Heck, they have no obligation to maintain CentOS
either. Maintaining both will only increase the workload of CentOS maintainers. I don't suppose you are volunteering to help them
do the work? Be thankful for a distribution that you have been using so far, and move on.
We might be better off if Red Hat hadn't gotten involved in CentOS in the first place and left it an independent project.
THEY choose to pursue this path and THEY chose to renege on assurances made around the non-stream distro. Now they're going to
choose to deal with whatever consequences come from the loss of goodwill in the community.
If they were going to pull this stunt they shouldn't have gone ahead with CentOS 8 at all and fulfilled any lifecycle
expectations for CentOS 7.
Sorry, but that's a BS. CentOS Stream and CentOS Linux are not mutually replaceable. You cannot sell that BS to any people
actually knowing the intrinsics of how CentOS Linux was being developed.
If the problem was in money, all RH needed to do was to ask the community. You would have been amazed at the output.
No, it is just a primitive, direct and lame way to either force "free users" to either pay, or become your free-to-use
beta testers (CentOS Stream *is* beta, whatever you say).
I predict you will be somewhat amazed at the actual results.
Not talking about the breach of trust. Now how much would cost all your (RH's) further promises and assurances?
you can spin this to the moon and back. The fact remains you just killed CentOS Linux and your users' trust by moving
the EOL of CentOS Linux 8 from 2029 to 2021.
You've alienated a few hunderd thousand sysadmins that started upgrading to 8 this year and you've thrown the scientific
Linux community under a bus. You do realize Scientific Linux was discontinued because CERN and FermiLab decided to standardize
on CentOS 8? This trickled down to a load of labs and research institutions.
Nobody forced you to buy out CentOS or offer a gratis distribution. But everybody expected you to stick to the EOL dates
you committed to. You boast about being the "Enterprise" Linux distributor. Then, don't act like a freaking start-up that announces
stuff today and vanishes a year later.
The correct way to handle this would have been to kill the future CentOS 9, giving everybody the time to cope with the
changes.
I've earned my RHCE in 2003 (yes that's seventeen years ago). Since then, many times, I've recommended RHEL or CentOS
to the clients I do free lance work for. Just a few weeks ago I was asked to give an opinion on six CentOS 7 boxes about to be
deployed into a research system to be upgraded to 8. I gave my go. Well, that didn't last long.
What do you expect me to recommend now? Buying RHEL licenses? That may or may be not have a certain cost per year and
may or may be not supported until a given date? Once you grant yourself the freedom to retract whatever published information,
how can I trust you? What added values do I get over any of the community supported distributions (given I can support myself)?
And no, CentOS Stream cannot "cover 95% (or so) of current user workloads". Stream was introduces as "a rolling preview
of what's next in RHEL".
I'm not interested at all in a "a rolling preview of what's next in RHEL". I'm interested in a stable distribution I
can trust to get updates until the given EOL date.
I guess my biggest issue is They should have announced this at the START of CentOS 8.0. Instead they started CentOS 8
with the belief it was going to be like CentOS7 have a long supported life cycle. What they did was basically bait and switch.
Not cool. Especially not cool for those running multiple nodes on high performance computing clusters.
I have over 300,000 Centos nodes that require Long term support as it's impossible to turn them over rapidly. I also
have 154,000 RHEL nodes. I now have to migrate 454,000 nodes over to Ubuntu because Redhat just made the dumbest decision short
of letting IBM acquire them I've seen. Whitehurst how could you let this happen? Nothing like millions in lost revenue from a single customer.
Just migrated to OpenSUSE. Rather than crying for dead os it's better to act yourself. Redhat is a sinking ship it probably
want last next decade.Legendary failure like ibm never have upper hand in Linux world. It's too competitive now. Customers have
more options to choose. I think person who have take this decision probably ignorant about the current market or a top grade fool.
IBM/RH/CentOS keeps replaying the same talking points over and over and ignoring the actual issues people have. You say
you are reading them, but choose to ignore it and that is even worse!
People still don't understand why CentOS stream and CentOS can't co-exist. If your goal was not to support CentOS 8, why did you put 2029 date or why did you even release CentOS 8 in the first
place?
Hell, you could have at least had the goodwill with the community to make CentOS 8 last until end of CentOS 7! But no,
you discontinued CentOS 8 giving people only 1 year to respond, and timed it right after EOL of CentOS6.
Why didn't you even bother asking the community first and come to a compromise or something?
Again, not a single person had a problem with CentOS stream, the problem was having the rug pulled under their feet!
So stop pretending and address it properly!
Even worse, you knew this was an issue, it's like literally #1 on your issue list "Shift Board to be more transparent
in support of becoming a contributor-focused open source project"
What a piece of stinking BS. What is this "gap" you're talking about? Nobody in the CentOS community cares about this
pre-RHEL gap. You're trying to fix something that isn't broken. And doing that the most horrible and bizzarre way imaginable.
I can only comment this as disappointment, if not betrayal, to whole CentOS user base.
This decision was clearly done, without considering impact to majority of CentOS community use cases.
If you need upstream contributions channel for RHEL, create it, do not destroy the stable downstream.
Clear and simple. All other 'explanations' are cover ups for real purpose of this action.
This stinks of politics within IBM/RH meddling with CentOS.
I hope, Rocky will bring the desired stability, that community was relying on with CentOS.
We've just agreed to cancel out RHEL subscriptions and will be moving them and our Centos boxes away as well. It was
a nice run but while it will be painful, it is a chance to move far far away from the terrible decisions made here.
The intellectually easy answer to what is happening is that IBM is putting pressure on Red
Hat to hit bigger numbers in the future. Red Hat sees a captive audience in its CentOS userbase
and is looking to covert a percentage to paying customers. Everyone else can go to Ubuntu or
elsewhere if they do not want to pay...
It seemed obvious (via Occam's Razor) that CentOS had cannibalized RHEL sales for the last
time and was being put out to die. Statements like:
If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options.
That line sure seemed like horrific marketing speak for "call our sales people and open your
wallet if you use CentOS in prod." ( cue evil mustache-stroking capitalist villain
).
... CentOS will no longer be downstream of RHEL as it was previously. CentOS will now
be upstream of the next RHEL minor release .
... ... ...
I'm watching Rocky Linux closely myself. While I plan to use CentOS for the vast majority of
my needs, Rocky Linux may have a place in my life as well, as an example powering my home
router. Generally speaking, I want my router to be as boring as absolute possible. That said
even that may not stay true forever, if for example CentOS gets good WireGuard support.
Lastly, but certainly not least, Red Hat has talked about upcoming low/no-cost RHEL options.
Keep an eye out for those! I have no idea the details, but if you currently use CentOS for
personal use, I am optimistic that there may be a way to get RHEL for free coming soon. Again,
this is just my speculation (I have zero knowledge of this beyond what has been shared
publicly), but I'm personally excited.
It seemed obvious (via Occam's Razor) that CentOS had cannibalized RHEL sales for the last
time and was being put out to die. Statements like:
If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options.
That line sure seemed like horrific marketing speak for "call our sales people and open your
wallet if you use CentOS in prod." ( cue evil mustache-stroking capitalist villain
).
... CentOS will no longer be downstream of RHEL as it was previously. CentOS will now
be upstream of the next RHEL minor release .
... ... ...
I'm watching Rocky Linux closely myself. While I plan to use CentOS for the vast majority of
my needs, Rocky Linux may have a place in my life as well, as an example powering my home
router. Generally speaking, I want my router to be as boring as absolute possible. That said
even that may not stay true forever, if for example CentOS gets good WireGuard support.
Lastly, but certainly not least, Red Hat has talked about upcoming low/no-cost RHEL options.
Keep an eye out for those! I have no idea the details, but if you currently use CentOS for
personal use, I am optimistic that there may be a way to get RHEL for free coming soon. Again,
this is just my speculation (I have zero knowledge of this beyond what has been shared
publicly), but I'm personally excited.
Red hat always has uneasy relationship with CentOS. Red hat brass always viwed it as something that streal Red hat licences. So
"Stop thesteal" mve might be not IBM inspired but it is firmly in IBM tradition. And like many similar IBM moves it will backfire.
This hiring of CentOS developers in 2014 gave them unprecedented control over the project. Why on Earth they now want independent
projects like Rocly Linux to re-emerge to fill the vacuum. They can't avoid the side affect of using GPL -- it allows clones. .Why it
is better to have a project that are hostile to Red Hat and that "in-house" domesticated project is unclear to me. As many large enterprises
deploy mix of Red Hat and CentOS the initial reaction might in the opposite direction the Red Hat brass expected: they will get less
licesses, not more by adopting "One IBM way"
On Hacker News , the leading comment was: "Imagine if you were running
a business, and deployed CentOS 8 based on the 10-year lifespan
promise . You're totally screwed now, and Red Hat knows it. Why on earth didn't they make this switch starting with CentOS 9????
Let's not sugar coat this. They've betrayed us."
A popular tweet from The Best Linux Blog In the Unixverse, nixcraft
, an account with over 200-thousand subscribers, went: Oracle buys Sun: Solaris Unix, Sun servers/workstation, and MySQL went to
/dev/null. IBM buys Red Hat: CentOS is going to
>/dev/null . Note to self: If a big vendor such as Oracle, IBM, MS, and others buys your fav software, start the migration procedure
ASAP."
Many others joined in this choir of annoyed CentOS users that it was IBM's fault that their favorite Linux was being taken away
from them. Still, others screamed Red Hat was betraying open-source itself.
... ... ...
Still another ex-Red Hat official said. If it wasn't for CentOS, Red Hat would have been a 10-billion dollar company before
Red Hat became
a billion-dollar business .
There are companies that sell appliances based on CentOS. Websense/Forcepoint is one of
them. The Websense appliance runs the base OS of CentOS, on top of which runs their
Web-filtering application. Same with RSA. Their NetWitness SIEM runs on top of CentOS.
Likewise, there are now countless Internet servers out there that run CentOS. There's now a
huge user base of CentOS out there.
This is why the Debian project is so important. I will be converting everything that is
currently CentOS to Debian. Those who want to use the Ubuntu fork of Debian, that is also
probably a good idea.
former Red Hat executive confided, "CentOS was gutting sales. The customer perception was
'it's from Red Hat and it's a clone of RHEL, so it's good to go!' It's not. It's a second-rate
copy." From where, this person sits, "This is 100% defensive to stave off more losses to
CentOS."
Still another ex-Red Hat official said. If it wasn't for CentOS, Red Hat would have been a
10-billion dollar company before Red
Hat became a billion-dollar business .
Yet another Red Hat staffer snapped, "Look at the CentOS FAQ . It says right there:
CentOS Linux is NOT Red Hat Linux, it is NOT Fedora Linux. It is NOT Red Hat Enterprise
Linux. It is NOT RHEL. CentOS Linux does NOT contain Red Hat® Linux, Fedora, or Red
Hat® Enterprise Linux.
CentOS Linux is NOT a clone of Red Hat® Enterprise Linux.
CentOS Linux is built from publicly available source code provided by Red Hat, Inc for Red
Hat Enterprise Linux in a completely different (CentOS Project maintained) build system.
CloudLinux OS is a RHEL rebuild distro designed for shared hosting providers. CloudLinux OS
itself probably isn't the free replacement for CentOS anyone is looking for -- it's more akin
to RHEL itself, with subscription fees necessary for production use.
However, the CloudLinux OS maintainers have announced that they'll be releasing a 1:1
replacement for CentOS in Q1 2021. The new fork will be a "separate, totally free OS that is
fully compatible with RHEL 8 and future versions."
There are a few upsides to this upcoming fork. CloudLinux OS has been around for a while,
and it has a pretty solid reputation. The new fork they're announcing won't be a big challenge
for Cloud -- they're already forking RHEL regularly and tracking changes to maintain the full
CloudLinux OS.
All they really need to do is make certain they separate out their own branding and
additional, license-only premium features.
This should also be a very easy upgrade for CentOS 8 users -- there's already a very easy
one-script migration path from CentOS to the full CloudLinux OS. Converting from CentOS to "the
new fork" should be just as simple and without the registration step necessary for the full
Cloud Linux.
Happy to report that we've invested exactly one day in CentOS 7 to CentOS 8
migration. Thanks, IBM. Now we can turn our full attention to Debian and never look back.
Here's a hot tip for the IBM geniuses that came up with this. Rebrand CentOS as New Coke, and
you've got yourself a real winner.
"... If you need official support, Oracle support is generally cheaper than RedHat. ..."
"... You can legally run OL free and have access to patches/repositories. ..."
"... Full binary compatibility with RedHat so if anything is certified to run on RedHat, it automatically certified for Oracle Linux as well. ..."
"... Premium OL subscription includes a few nice bonuses like DTrace and Ksplice. ..."
"... Forgot to mention that converting RedHat Linux to Oracle is very straightforward - just matter of updating yum/dnf config to point it to Oracle repositories. Not sure if you can do it with CentOS (maybe possible, just never needed to convert CentOS to Oracle). ..."
My office switched the bulk of our RHEL to OL years ago, and find it a great product, and
great support, and only needing to get support for systems we actually want support on.
Oracle provided scripts to convert EL5, EL6, and EL7 systems, and was able to convert some
EL4 systems I still have running. (Its a matter of going through the list of installed
packages, use 'rpm -e --justdb' to remove the package from the rpmdb, and re-installing the
package (without dependencies) from the OL ISO.)
We have been using Oracle Linux exclusively last 5-6 years for everything - thousands of
servers both for internal use and hundred or so customers.
Not a single time regretted, had any issues or were tempted to move to RedHat let alone
CentOS.
I found Oracle Linux has several advantages over RedHat/CentOS:
If you need
official support, Oracle support is generally cheaper than RedHat.You can legally
run OL free and have access to patches/repositories.Full binary compatibility with
RedHat so if anything is certified to run on RedHat, it automatically certified for Oracle
Linux as well. It is very easy to switch between supported and free setup (say, you have
proof-of-concept setup running free OL, but then it is being promoted to production status -
just matter of registering box with Oracle, no need to reinstall/reconfigure anything). You
can easily move licensed/support from one box to another so you always run the same OS and do
not have to think and decide (RedHat for production / CentOS for Dec/test). You have a choice
to run good old RedHat kernel or use newer Oracle kernel (which is pretty much vanilla kernel
with minimal modification - just newer). We generally run Oracle kernels on all boxes unless
we have to support particularly pedantic customer who insist on using old RedHat kernel.
Premium OL subscription includes a few nice bonuses like DTrace and Ksplice.
Overall, it is pleasure to work and support OL.
Negatives:
I found RedHat knowledge base / documentation is much better than Oracle's
Oracle does not offer extensive support for "advanced" products like JBoss, Directory Server,
etc. Obviously Oracle has its own equivalent commercial offerings (Weblogic, etc) and prefers
customers to use them. Some complain about quality of Oracle's support. Can't really comment
on that. Had no much exposure to RedHat support, maybe used it couple of times and it was
good. Oracle support can be slower, but in most cases it is good/sufficient. Actually over
the last few years support quality for Linux has improved noticeably - guess Oracle pushes
their cloud very aggressively and as a result invests in Linux support (as Oracle cloud aka
OCI runs on Oracle Linux).
Forgot to mention that converting RedHat Linux to Oracle is very straightforward -
just matter of updating yum/dnf config to point it to Oracle repositories. Not sure if you
can do it with CentOS (maybe possible, just never needed to convert CentOS to
Oracle).
At the end IBM/Red Hat might even lose money as powerful organizations, such as universities, might abandon Red Hat as the
platform. Or may be not. Red Hat managed to push systemd down the throat without any major hit to the revenue. Why not to
repeat the trick with CentOS? In any case IBM owns enterprise Linux and bitter complains and threats of retribution in this forum is
just a symptom that the development now is completely driven by corporate brass, and all key decisions belong to them.
Community wise, this is plain bad news for Open Source and all Open Source communities. IBM explained to them very clearly: you
does not matter. And organized minority always beat disorganized majority. Actually most large organizations will
probably stick with Red Hat compatible OS, probably moving to Oracle Linux or Rocky Linux, is it materialize, not to Debian.
What is interesting is that most people here believe that when security patches are stopped that's the end of the life for the
particular Linux version. It is an interesting superstition and it shows how conditioned by corporations Linux folk are and
how far from BSD folk they are actually are. Security is an architectural thing first and foremost. Patched are just band aid and
they can't change general security situation in Linux no matter how hard anyone tries. But they now serve as a powerful tool
of corporate mind control over the user population. Feat is a powerful instrument of mind control.
In reality security of most systems on internal network does no change one bit with patches. And on external network only
applications that have open ports that matter (that's why ssh should be restricted to the subnets used, not to be opened to the
whole world)
Notable quotes:
"... Bad idea. The whole point of using CentOS is it's an exact binary-compatible rebuild of RHEL. With this decision RH is killing CentOS and inviting to create a new *fork* or use another distribution ..."
"... We all knew from the moment IBM bought Redhat that we were on borrowed time. IBM will do everything they can to push people to RHEL even if that includes destroying a great community project like CentOS. ..."
"... First CoreOS, now CentOS. It's about time to switch to one of the *BSDs. ..."
"... I guess that means the tens of thousands of cores of research compute I manage at a large University will be migrating to Debian. ..."
"... IBM is declining, hence they need more profit from "useless" product line. So disgusting ..."
"... An entire team worked for months on a centos8 transition at the uni I work at. I assume a small portion can be salvaged but reading this it seems most of it will simply go out the window ..."
"... Unless the community can center on a new single proper fork of RHEL, it makes the most sense (to me) to seek refuge in Debian as it is quite close to CentOS in stability terms. ..."
"... Another one bites the dust due to corporate greed, which IBM exemplifies ..."
"... More likely to drive people entirely out of the RHEL ecosystem. ..."
"... Don't trust Red Hat. 1 year ago Red Hat's CTO Chris Wright agreed in an interview: 'Old school CentOS isn't going anywhere. Stream is available in parallel with the existing CentOS builds. In other words, "nothing changes for current users of CentOS."' https://www.zdnet.com/article/red-hat-introduces-rolling-release-centos-stream/ ..."
"... 'To be exact, CentOS Stream is an upstream development platform for ecosystem developers. It will be updated several times a day. This is not a production operating system. It's purely a developer's distro.' ..."
"... Read again: CentOS Stream is not a production operating system. 'Nuff said. ..."
"... This makes my decision to go with Ansible and CentOS 8 in our enterprise simple. Nope, time to got with Puppet or Chef. ..."
"... Ironic, and it puts those of us who have recently migrated many of our development serves to CentOS8 in a really bad spot. Luckily we haven't licensed RHEL8 production servers yet -- and now that's never going to happen. ..."
"... What IBM fails to understand is that many of us who use CentOS for personal projects also work for corporations that spend millions of dollars annually on products from companies like IBM and have great influence over what vendors are chosen. This is a pure betrayal of the community. Expect nothing less from IBM. ..."
"... IBM is cashing in on its Red Hat acquisition by attempting to squeeze extra licenses from its customers.. ..."
"... Hoping that stabbing Open Source community in the back, will make it switch to commercial licenses is absolutely preposterous. This shows how disconnected they're from reality and consumed by greed and it will simply backfire on them, when we switch to Debian or any other LTS alternative. ..."
"... Centos was handy for education and training purposes and production when you couldn't afford the fees for "support", now it will just be a shadow of Fedora. ..."
"... There was always a conflict of interest associated with Redhat managing the Centos project and this is the end result of this conflict of interest. ..."
"... The reality is that someone will repackage Redhat and make it just like Centos. The only difference is that Redhat now live in the same camp as Oracle. ..."
"... Everyone predicted this when redhat bought centos. And when IBM bought RedHat it cemented everyone's notion. ..."
"... I am senior system admin in my organization which spends millions dollar a year on RH&IBM products. From tomorrow, I will do my best to convince management to minimize our spending on RH & IBM ..."
"... IBM are seeing every CentOS install as a missed RHEL subscription... ..."
"... Some years ago IBM bought Informix. We switched to PostgreSQL, when Informix was IBMized. One year ago IBM bought Red Hat and CentOS. CentOS is now IBMized. Guess what will happen with our CentOS installations. What's wrong with IBM? ..."
"... Remember when RedHat, around RH-7.x, wanted to charge for the distro, the community revolted so much that RedHat saw their mistake and released Fedora. You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time. ..."
"... As I predicted, RHEL is destroying CentOS, and IBM is running Red Hat into the ground in the name of profit$. Why is anyone surprised? I give Red Hat 12-18 months of life, before they become another ordinary dept of IBM, producing IBM Linux. ..."
"... Happy to donate and be part of the revolution away the Corporate vampire Squid that is IBM ..."
"... Red Hat's word now means nothing to me. Disagreements over future plans and technical direction are one thing, but you *lied* to us about CentOS 8's support cycle, to the detriment of *everybody*. You cost us real money relying on a promise you made, we thought, in good faith. ..."
Bad idea. The whole point of using CentOS is it's an exact binary-compatible rebuild
of RHEL. With this decision RH is killing CentOS and inviting to create a new *fork* or use
another distribution. Do you realize how much market share you will be losing and how much
chaos you will be creating with this?
"If you are using CentOS Linux 8 in a production environment, and are concerned that
CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options".
So this is the way RH is telling us they don't want anyone to use CentOS anymore and switch
to RHEL?
That's exactly what they're saying. We all knew from the moment IBM bought Redhat
that we were on borrowed time. IBM will do everything they can to push people to RHEL even if
that includes destroying a great community project like CentOS.
Wow. Well, I guess that means the tens of thousands of cores of research compute I
manage at a large University will be migrating to Debian. I've just started preparing to
shift from Scientific Linux 7 to CentOS due to SL being discontinued by 2024. Glad I've only
just started - not much work to throw away.
An entire team worked for months on a centos8 transition at the uni I work at. I assume a small portion can be salvaged
but reading this it seems most of it will simply go out the window. Does anyone know if this decision of dumping centos8
is final?
Unless the community can center on a new single proper fork of RHEL, it makes the
most sense (to me) to seek refuge in Debian as it is quite close to CentOS in stability
terms.
Already existing functioning distribution ecosystem, can probably do good with influx
of resources to enhance the missing bits, such as further improving SELinux support and
expanding Debian security team.
I say this without any official or unofficial involvement with the Debian project,
other than being a user.
And we have just launched hundred of Centos 8 servers.
Another one bites the dust due to corporate greed, which IBM exemplifies. This is
why I shuddered when they bought RH. There is nothing that IBM touches that gets better,
other than the bottom line of their suits!
This is a big mistake. RedHat did this with RedHat Linux 9 the market leading Linux
and created Fedora, now an also-ran to Ubuntu. I spent a lot of time during Covid to convert
from earlier versions to 8, and now will have to review that work with my
customer.
I just finished building a CentOS 8 web server, worked out all the nooks and
crannies and was very satisfied with the result. Now I have to do everything from scratch?
The reason why I chose this release was that every website and its brother were giving a 2029
EOL. Changing that is the worst betrayal of trust possible for the CentOS community. It's
unbelievable.
What a colossal blunder: a pivot from the long-standing mission of an OS providing
stability, to an unstable development platform, in a manner that betrays its current users.
They should remove the "C" from CentOS because it no longer has any connection to a community
effort. I wonder if this is a move calculated to drive people from a free near clone of RHEL
to a paid RHEL subscription? More likely to drive people entirely out of the RHEL
ecosystem.
From a RHEL perspective I understand why they'd want it this way. CentOS was
probably cutting deep into potential RedHat license sales. Though why or how RedHat would
have a say in how CentOS is being run in the first place is.. troubling.
From a CentOS perspective you may as well just take the project out back and close it now. If
people wanted to run beta-test tier RHEL they'd run Fedora. "LATER SECURITY FIXES AND
UNTESTED 'FEATURES'?! SIGN ME UP!" -nobody
I'll probably run CentOS 7 until the end and then swap over to Debian when support starts
hurting me. What a pain.
Don't trust Red Hat. 1 year ago Red Hat's CTO Chris Wright agreed in an interview:
'Old school CentOS isn't going anywhere. Stream is available in parallel with the existing
CentOS builds. In other words, "nothing changes for current users of CentOS."' https://www.zdnet.com/article/red-hat-introduces-rolling-release-centos-stream/
I'm a current user of old school CentOS, so keep your promise, Mr CTO.
That was quick: "Old school CentOS isn't going anywhere. Stream is available in parallel with the existing CentOS builds.
In other words, "nothing changes for current users of CentOS."
From the same article: 'To be exact, CentOS Stream is an upstream development platform for
ecosystem developers. It will be updated several times a day. This is
not a production operating system. It's purely a developer's distro.'
Read again: CentOS Stream is not a production operating system. 'Nuff
said.
This makes my decision to go with Ansible and CentOS 8 in our enterprise simple.
Nope, time to got with Puppet or Chef. IBM did what I thought they would screw up Red Hat. My
company is dumping IBM software everywhere - this means we need to dump CentOS now
too.
Ironic, and it puts those of us who have recently migrated many of our development
serves to CentOS8 in a really bad spot. Luckily we haven't licensed RHEL8 production servers
yet -- and now that's never going to happen.
I can't believe what IBM is actually doing. This is a direct move against all that
open source means. They want to do exactly the same thing they're doing with awx (vs. ansible
tower). You're going against everything that stands for open source. And on top of that you
choose to stop offering support for Centos 8, all of a sudden! What a horrid move on your
part. This only reliable choice that remains is probably going to be Debian/Ubuntu. What a
waste...
What IBM fails to understand is that many of us who use CentOS for personal projects
also work for corporations that spend millions of dollars annually on products from companies
like IBM and have great influence over what vendors are chosen. This is a pure betrayal of the community. Expect nothing less from IBM.
This is exactly it. IBM is cashing in on its Red Hat acquisition by attempting to squeeze extra licenses
from its customers.. while not taking into account the fact that Red Hat's strong adoption
into the enterprise is a direct consequence of engineers using the nonproprietary version to
develop things at home in their spare time.
Having an open source, non support contract version of your OS is exactly what
drives adoption towards the supported version once the business decides to put something into
production.
They are choosing to kill the golden goose in order to get the next few eggs faster.
IBM doesn't care about anything but its large enterprise customers. Very stereotypically
IBM.
So sad.
Not only breaking the support promise but so quickly (2021!)
Business wise, a lot of business software is providing CentOS packages and support.
Like hosting panels, backup software, virtualization, Management. I mean A LOT of money
worldwide is in dark waters now with this announcement. It took years for CentOS to appear in
their supported and tested distros. It will disappear now much faster.
Community wise, this is plain bad news for Open Source and all Open Source
communities. This is sad. I wonder, are open source developers nowadays happy to spend so
many hours for something that will in the end benefit IBM "subscribers" only in the end? I
don't think they are.
I don't want to give up on CentOS but this is a strong life changing decision. My
background is linux engineering with over 15+ years of hardcore experience. CentOS has always
been my go to when an organization didn't have the appetite for RHEL and the $75 a year
license fee per instance. I fought off Ubuntu take overs at 2 of the last 3 organizations
I've been with successfully. I can't, won't fight off any more and start advocating for
Ubuntu or pure Debian moving forward.
RIP CentOS. Red Hat killed a great project. I wonder if Anisble will be next?
Hoping that stabbing Open Source community in the back, will make it switch to
commercial licenses is absolutely preposterous. This shows how disconnected they're from
reality and consumed by greed and it will simply backfire on them, when we switch to Debian
or any other LTS alternative. I can't think moving everything I so caressed and loved to a
mess like Ubuntu.
Assinine. This is completely ridiculous. I have migrated several servers from CentOS
7 to 8 recently with more to go. We also have a RHEL subscription for outward facing servers,
CentOS internal. This type of change should absolutely have been announced for CentOS 9. This
is garbage saying 1 year from now when it was supposed to be till 2029. A complete betrayal.
One year to move everything??? Stupid.
Now I'm going to be looking at a couple of other options but it won't be RHEL after
this type of move. This has destroyed my trust in RHEL as I'm sure IBM pushed for this. You
will be losing my RHEL money once I chose and migrate. I get companies exist to make money
and that's fine. This though is purely a naked money grab that betrays an established
timeline and is about to force massive work on lots of people in a tiny timeframe saying "f
you customers.". You will no longer get my money for doing that to me
In hind sight it's clear to see that the only reason RHEL took over CentOS was to
kill the competition.
This is also highly frustrating as I just completed new CentOS8 and RHEL8 builds for
Non-production and Production Servers and had already begun deployments. Now I'm left in
situation of finding a new Linux distribution for our enterprise while I sweat out the last
few years of RHEL7/CentOS7. Ubuntu is probably a no go there enterprise tooling is somewhat
lacking, and I am of the opinion that they will likely be gobbled up buy Microsoft in the
next few years.
Unfortunately, the short-sighted RH/IBMer that made this decision failed to realize
that a lot of Admins that used Centos at home and in the enterprise also advocated and drove
sales towards RedHat as well. Now with this announcement I'm afraid the damage is done and
even if you were to take back your announcement, trust has been broken and the blowback will
ultimately mean the death of CentOS and reduced sales of RHEL. There is however an
opportunity for another Corporations such as SUSE which is own buy Microfocus to capitalize
on this epic blunder simply by announcing an LTS version of OpenSues Leap. This would in turn
move people/corporations to the Suse platform which in turn would drive sale for
SLES.
So the inevitable has come to pass, what was once a useful Distro will disappear
like others have. Centos was handy for education and training purposes and production when
you couldn't afford the fees for "support", now it will just be a shadow of
Fedora.
This is disgusting. Bah. As a CTO I will now - today - assemble my teams and develop a plan to migrate all DataCenters back to Debian for good. I will also instantly instruct the termination of all
mirroring of your software.
For the software (CentOS) I hope for a quick death that will not drag on for
years.
This is a bit sad. There was always a conflict of interest associated with Redhat
managing the Centos project and this is the end result of this conflict of interest.
There is
a genuine benefit associated with the existence of Centos for Redhat however it would appear
that that benefit isn't great enough and some arse clown thought that by forcing users to
migrate it will increase Redhat's revenue.
The reality is that someone will repackage Redhat
and make it just like Centos. The only difference is that Redhat now live in the same camp as
Oracle.
Thankfully we just started our migration from CentOS 7 to 8 and this surely puts a
stop to that. Even if CentOS backtracks on this decision because of community backlash, the
reality is the trust is lost. You've just given a huge leg for Ubuntu/Debian in the
enterprise. Congratulations!
I am senior system admin in my organization which spends millions dollar a year on
RH&IBM products. From tomorrow, I will do my best to convince management to minimize our
spending on RH & IBM, and start looking for alternatives to replace existing RH & IBM
products under my watch.
Some years ago IBM bought Informix. We switched to PostgreSQL, when Informix was
IBMized. One year ago IBM bought Red Hat and CentOS. CentOS is now IBMized. Guess what will
happen with our CentOS installations. What's wrong with IBM?
Remember when RedHat, around RH-7.x, wanted to charge for the distro, the community
revolted so much that RedHat saw their mistake and released Fedora. You can fool all the people some of the time, and some of the people all the time,
but you cannot fool all the people all the time.
Even though RedHat/CentOS has a very large share of the Linux server market, it will
suffer the same fate as Novell (had 85% of the matket), disappearing into darkness
!
As I predicted, RHEL is destroying CentOS, and IBM is running Red Hat into the
ground in the name of profit$. Why is anyone surprised? I give Red Hat 12-18 months of life,
before they become another ordinary dept of IBM, producing IBM Linux.
CentOS is dead. Time to
either go back to Debian and its derivatives, or just pay for RHEL, or IBMEL, and suck it
up.
I am mid-migration from Rhel/Cent6 to 8. I now have to stop a major project for
several hundred systems. My group will have to go back to rebuild every CentOS 8 system we've
spent the last 6 months deploying.
Congrats fellas, you did it. You perfected the transition to Debian from
CentOS.
I find it kind of funny, I find it kind of sad.
The dreams in which I moving 1.5K+ machines to whatever distro I yet have to find fitting for
replacement to are the..
Wait. How could one with all the seriousness consider cutting down
already published EOL a good idea?
I literally had to convince people to move from Ubuntu and
Debian installations to CentOS for sake of stability and longer support, just for become
looking like a clown now, because with single move distro deprived from both of
this.
Red Hat's word now means nothing to me. Disagreements over future plans and technical direction are one thing, but you
*lied* to us about CentOS 8's support cycle, to the detriment of *everybody*. You cost us real money relying on a promise you
made, we thought, in good faith. It is now clear Red Hat no longer knows what "good faith" means, and acts only as a
Trumpian vacuum of wealth.
I have been using CentOS for over 10 years and one of the things I loved about it was how
stable it has been. Now, instead of being a stable release, it is changing to the beta
testing ground for RHEL 8.
And instead of 10 years of a support you need to update to the latest dot release. This
has me, very concerned.
well, 10 years - have you ever contributed with anything for the CentOS community, or paid
them a wage or at least donated some decent hardware for development or maybe just being
parasite all the time and now are you surprised that someone has to buy it's your own lunches
for a change?
If you think you might have done it even better why not take RH sources and make your own
FreeRHos whatever distro, then support, maintain and patch all the subsequent versions for
free?
That's ridiculous. RHEL has benefitted from the free testing and corner case usage of
CentOS users and made money hand-over-fist on RHEL. Shed no tears for using CentOS for free.
That is the benefit of opening the core of your product.
You are missing a very important point. Goal of CentOS project was to rebuild RHEL,
nothing else. If money was the problem, they could have asked for donations and it would be
clear is there can be financial support for rebuild or not.
Putting entire community in front of done deal is disheartening and no one will trust
Red Hat that they are pro-community, not to mention Red Hat employees that sit in CentOS
board, who can trust their integrity after this fiasco?
This is a breach of trust from the already published timeline of CentOS 8 where the EOL
was May 2029. One year's notice for such a massive change is unacceptable.
This! People already started deploying CentOS 8 with the expectation of 10 years of
updates. - Even a migration to RHEL 8 would imply completely reprovisioning the systems which
is a big ask for systems deployed in the field.
I am considering creating another rebuild of RHEL and may even be able to hire some
people for this effort. If you are interested in helping, please join the HPCng slack (link
on the website hpcng.org).
This sounds like a great idea and getting control away from corporate entities like IBM
would be helpful. Have you considered reviving the Scientific Linux project?
Feel free to contact me. I'm a long time RH user (since pre-RHEL when it was RHL) in both
server and desktop environments. I've built and maintained some RPMs for some private
projects that used CentOS as foundation. I can contribute compute and storage resources. I
can program in a few different languages.
Thank you for considering starting another RHEL rebuild. If and when you do, please
consider making your new website a Brave Verified Content Creator. I earn a little bit of
money every month using the Brave browser, and I end up donating it to Wikipedia every month
because there are so few Brave Verified websites.
The verification process is free, and takes about 15 to 30 minutes. I believe that the
Brave browser now has more than 8 million users.
Wikipedia. The so called organization that get tons of money from tech oligarchs and
yet the whine about we need money and support? (If you don't believe me just check their
biggest donors) also they keen to be insanely biased and allow to write on their web whoever
pays the most... Seriously, find other organisation to donate your money
Not sure what I could do but I will keep an eye out things I could help with. This change
to CentOS really pisses me off as I have stood up 2 CentOS servers for my works production
environment in the last year.
LOL... CentOS is RH from 2014 to date. What you expected? As long as CentOS is so good
and stable, that cuts some of RHEL sales... RH and now IBM just think of profit. It was
expected, search the net for comments back in 2014.
Amazon Linux 2 is the next generation of Amazon Linux, a Linux server operating system from
Amazon Web Services (AWS). It provides a secure, stable, and high performance execution
environment to develop and run cloud and enterprise applications. With Amazon Linux 2, you get
an application environment that offers long term support with access to the latest innovations
in the Linux ecosystem. Amazon Linux 2 is provided at no additional charge.
Amazon Linux 2 is available as an Amazon Machine Image (AMI) for use on Amazon Elastic
Compute Cloud (Amazon EC2). It is also available as a Docker container image and as a virtual
machine image for use on Kernel-based Virtual Machine (KVM), Oracle VM VirtualBox, Microsoft
Hyper-V, and VMware ESXi. The virtual machine images can be used for on-premises development
and testing. Amazon Linux 2 supports the latest Amazon EC2 features and includes packages that
enable easy integration with AWS. AWS provides ongoing security and maintenance updates for
Amazon Linux 2.
"... Redhat endorsed that moral contract when you brought official support to CentOS back in 2014. ..."
"... Now that you decided to turn your back on the community, even if another RHEL fork comes out, there will be an exodus of the community. ..."
"... Also, a lot of smaller developers won't support RHEL anymore because their target weren't big companies, making less and less products available without the need of self supporting RPM builds. ..."
"... Gregory Kurtzer's fork will take time to grow, but in the meantime, people will need a clear vision of the future. ..."
"... This means that we'll now have to turn to other linux flavors, like Debian, or OpenSUSE, of which at least some have hardware vendor support too, but with a lesser lifecycle. ..."
"... I think you destroyed a large part of the RHEL / CentOS community with this move today. ..."
"... Maybe you'll get more RHEL subscriptions in the next months yielding instant profits, but the long run growth is now far more uncertain. ..."
As a lot of us here, I've been in the CentOS / RHEL community for more than 10 years.
Reasons of that choice were stability, long term support and good hardware vendor support.
Like many others, I've built much of my skills upon this linux flavor for years, and have been implicated into the community
for numerous bug reports, bug fixes, and howto writeups.
Using CentOS was the good alternative to RHEL on a lot of non critical systems, and for smaller companies like the one I work
for.
The moral contract has always been a rock solid "Community Enterprise OS" in exchange of community support, bug reports & fixes,
and growing interest from developers.
Redhat endorsed that moral contract when you brought official support to CentOS back in 2014.
Now that you decided to turn your back on the community, even if another RHEL fork comes out, there will be an exodus of the
community.
Also, a lot of smaller developers won't support RHEL anymore because their target weren't big companies, making less and less
products available without the need of self supporting RPM builds.
This will make RHEL less and less widely used by startups, enthusiasts and others.
CentOS Stream being the upstream of RHEL, I highly doubt system architects and developers are willing to be beta testers for RHEL.
Providing a free RHEL subscription for Open Source projects just sounds like your next step to keep a bit of the exodus from happening,
but I'd bet that "free" subscription will get more and more restrictions later on, pushing to a full RHEL support contract.
As a lot of people here, I won't go the Oracle way, they already did a very good job destroying other company's legacy.
Gregory Kurtzer's fork will take time to grow, but in the meantime, people will need a clear vision of the future.
This means that we'll now have to turn to other linux flavors, like Debian, or OpenSUSE, of which at least some have hardware
vendor support too, but with a lesser lifecycle.
I think you destroyed a large part of the RHEL / CentOS community with this move today.
Maybe you'll get more RHEL subscriptions in the next months yielding instant profits, but the long run growth is now far more
uncertain.
IBM have a history of taking over companies and turning them into junk, so I am not that
surprised. I am surprised that it took IBM brass so long to kill CentOS after Red Hat
acquisition.
Notable quotes:
"... By W3Tech 's count, while Ubuntu is the most popular Linux server operating system with 47.5%, CentOS is number two with 18.8% and Debian is third, 17.5%. RHEL? It's a distant fourth with 1.8%. ..."
"... Red Hat will continue to support CentOS 7 and produce it through the remainder of the RHEL 7 life cycle . That means if you're using CentOS 7, you'll see support through June 30, 2024 ..."
I'm far from alone. By W3Tech 's count,
while Ubuntu is the most popular Linux server operating system with 47.5%, CentOS is number two
with 18.8% and Debian is third, 17.5%. RHEL? It's a distant fourth with 1.8%.
If you think you just realized why Red Hat might want to remove CentOS from the server
playing field, you're far from the first to think that.
Red Hat will continue to support CentOS 7 and produce it through the remainder of the
RHEL 7 life
cycle . That means if you're using CentOS 7, you'll see support through June 30, 2024
I wonder what Red Hat's plan is WRT companies like Blackmagic Design that ship CentOS as part of their studio equipment.
The cost of a RHEL license isn't the issue when the overall cost of the equipment is in the tens of thousands but unless I
missed a change in Red Hat's trademark policy, Blackmagic cannot distribute a modified version of RHEL and without removing all
trademarks first.
I don't think a rolling release distribution is what BMD wants.
My gut feeling is that something like Scientific Linux will make a return and current CentOS users will just use that.
We firmly believe that Oracle Linux is the best Linux distribution on the market today. It's reliable, it's affordable, it's 100%
compatible with your existing applications, and it gives you access to some of the most cutting-edge innovations in Linux like Ksplice
and DTrace.
But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your
systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or
can we?
We're putting Oracle Linux in your hands by doing two things:
We've made the Oracle Linux software available free of charge
We've created a simple script to switch your CentOS systems to Oracle Linux
We think you'll like what you find, and we'd love for you to give it a try.
FAQ
Wait, doesn't Oracle Linux cost money?
Oracle Linux support costs money. If you just want the software, it's 100% free. And it's all in our yum repo at
yum.oracle.com . Major releases, errata, the whole shebang. Free source
code, free binaries, free updates, freely redistributable, free for production use. Yes, we know that this is Oracle, but it's
actually free. Seriously.
Is this just another CentOS?
Inasmuch as they're both 100% binary-compatible with Red Hat Enterprise Linux, yes, this is just like CentOS. Your applications
will continue to work without any modification whatsoever. However, there are several important differences that make Oracle Linux
far superior to CentOS.
How is this better than CentOS?
Well, for one, you're getting the exact same bits our paying enterprise customers are getting . So that means a few
things. Importantly, it means virtually no delay between when Red Hat releases a kernel and when Oracle Linux does:
So if you don't want to risk another CentOS delay, Oracle Linux is a better alternative for you. It turns out that our enterprise
customers don't like to wait for updates -- and neither should you.
What about the code quality?
Again, you're running the exact same code that our enterprise customers are, so it has to be rock-solid. Unlike CentOS, we
have a large paid team of developers, QA, and support engineers that work to make sure this is reliable.
What if I want support?
If you're running Oracle Linux and want support, you can purchase a support contract from us (and it's significantly cheaper
than support from Red Hat). No reinstallation, no nothing -- remember, you're running the same code as our customers.
Contrast that with the CentOS/RHEL story. If you find yourself needing to buy support, have fun reinstalling your system with
RHEL before anyone will talk to you.
Why are you doing this?
This is not some gimmick to get you running Oracle Linux so that you buy support from us. If you're perfectly happy running
without a support contract, so are we. We're delighted that you're running Oracle Linux instead of something else.
At the end of the day, we're proud of the work we put into Oracle Linux. We think we have the most compelling Linux offering
out there, and we want more people to experience it.
centos2ol.sh can convert your CentOS 6 and 7 systems to Oracle Linux.
What does the script do?
The script has two main functions: it switches your yum configuration to use the Oracle Linux yum server to update some core
packages and installs the latest Oracle Unbreakable Enterprise Kernel. That's it! You won't even need to restart after switching,
but we recommend you do to take advantage of UEK.
Is it safe?
The centos2ol.sh script takes precautions to back up and restore any repository files it changes, so if it does not work on
your system it will leave it in working order. If you encounter any issues, please get in touch with us by emailing
[email protected] .
IBM is messing up RedHat after the take over last year. This is the most unfortunate news
to the Free Open-Source community. Companies have been using CentOS as a testing bed before
committing to purchase RHEL subscription licenses.
We need to rethink before rolling out RedHat/CentOS 8 training in our Centre.
You can use Oracle Linux in exactly the same way as you did CentOS except that you have
the option of buying support without reinstalling a "commercial" variant.
Everything's in the public repos except a few addons like ksplice. You don't even have to
go through the e-delivery to download the ISOs any more, they're all linked from
yum.oracle.com
Not likely. Oracle Linux has extensive use by paying Oracle customers as a host OS for
their database software and in general purposes for Oracle Cloud Infrastructure.
Oracle customers would be even less thrilled about Streams than CentOS users. I hate to
admit it, but Oracle has the opportunity to take a significant chunk of the CentOS user base
if they don't do anything Oracle-ish, myself included.
I'll be pretty surprised if they don't completely destroy their own windfall opportunity,
though.
IBM has discontinued CentOS. Oracle is producing a working replacement for CentOS. If, at
some point, Oracle attacks their product's users in the way IBM has here, then one can move
to Debian, but for now, it's a working solution, as CentOS no longer is.
You can use Oracle Linux exactly like CentOS, only better
Ang says: December 9, 2020 at 5:04 pm "I never thought we'd see the day Oracle is more
trustworthy than RedHat/IBM. But I guess such things do happen with time..."
Notable quotes:
"... The link says that you don't have to pay for Oracle Linux . So switching to it from CentOS 8 could be a very easy option. ..."
"... this quick n'dirty hack worked fine to convert centos 8 to oracle linux 8, ymmv: ..."
Oracle Linux is free. The only thing that costs money is support for it. I quote
"Yes, we know that this is Oracle, but it's actually free.
Seriously."
Is Oracle A Real Alternative To CentOS? Home "
CentOS " Is Oracle A Real Alternative To CentOS? December 8,
2020 Frank Cox CentOS 33 Comments
Is Oracle a real alternative to
CentOS ? I'm asking because genuinely don't know; I've never paid any attention to Oracle's Linux offering before now.
But today I've seen a couple of the folks here mention Oracle Linux and I see that Oracle even offers a script to convert
CentOS 7 to Oracle. Nothing about
CentOS 8 in that script, though.
That page seems to say that Oracle Linux is everything that
CentOS was prior to today's announcement.
But someone else here just said that the first thing Oracle Linux does is to sign you up for an Oracle account.
So, for people who know a lot more about these things than I do, what's the downside of using Oracle Linux versus CentOS? I assume
that things like epel/rpmfusion/etc will work just as they do under CentOS since it's supposed to be bit-for-bit compatible like
CentOS was. What does the "sign up with Oracle" stuff actually do, and can you cancel, avoid, or strip it out if you don't want it?
Based on my extremely limited knowledge around Oracle Linux, it sounds like that might be a go-to solution for CentOS refugees.
$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 (Maipo)
$ cat /etc/oracle-release Oracle Linux Server release 7.7
This is generally done so that sw pieces officially certified only on upstream enterprise vendor and that test contents of
the redhat-release file are satisfied. Using the lsb_release command on an Oracle Linux 7.6 machine:
# lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: OracleServer Description: Oracle Linux Server release 7.6
Release: 7.6
Codename: n/a
#
KVM is a subscription feature. They want you to run Oracle VM Server for x86 (which is based on Xen) so they can try to upsell
you to use the Oracle Cloud. There's other things, but that stood out immediately.
That's it. I know Oracle's history, but I think for Oracle Linux, they may be much better than their reputation. I'm currently
fiddling around with it, and I like it very much. Plus there's a nice script to turn an existing CentOS installation into an Oracle
Linux system.
Am Dienstag, den 15.12.2020, 10:14 +0100 schrieb Ruslanas Gžibovskis:
According to the Oracle license terms and official statements, it is "free to download, use and share. There is no license
cost, no need for a contract, and no usage audits."
Recommendation only: "For business-critical infrastructure, consider Oracle Linux Support." Only optional, not a mandatory
requirement. see: https://www.oracle.com/linux
No need for such a construct. Oracle Linux can be used on any production system without the legal requirement to obtain a extra
commercial license. Same as in CentOS.
So Oracle Linux can be used free as in "free-beer" currently for any system, even for commercial purposes. Nevertheless, Oracle
can change that license terms in the future, but this applies as well to all other company-backed linux distributions.
--
Peter Huebner
As I write this column, I'm in the middle of two summer projects; with luck, they'll both be finished by the time you read it.
One involves a forensic analysis of over 100,000 lines of old C and assembly code from about 1990, and I have to work on Windows
XP.
The other is a hack to translate code written in weird language L1 into weird language L2 with a program written in scripting
language L3, where none of the L's even existed in 1990; this one uses Linux. Thus it's perhaps a bit surprising that I find myself
relying on much the same toolset for these very different tasks.
... ... ...
Here has surely been much progress in tools over the 25 years that IEEE Software has been around, and I wouldn't want to go back
in time.
But the tools I use today are mostly the same old ones-grep, diff, sort, awk, and friends. This might well mean that I'm a dinosaur
stuck in the past.
On the other hand, when it comes to doing simple things quickly, I can often have the job done while experts are still waiting
for their IDE to start up. Sometimes the old ways are best, and they're certainly worth knowing well
Ok, so you need to quickly encrypt the contents of you pen drive. The easiest solution is to compress
them using the 7z archive file format, that is open source, cross-platform, and supports 256-bit
encryption using the AES algorithm.
Encrypt with Seahorse
The third option that I will show basically utilizes the popular GNU PG tool to encrypt anything
you want in your disk. What we need to install first are the following packages: gpg, seahorse, seahorse-nautilus,
seahorse-daemon, and seahorse-contracts which is needed if you're using ElementaryOS like I do. The
encryption will be based on a key that we need to create first by opening a terminal, and typing
the following command:
First of all this is kind of system error that is not easy to exploit. You need to locate
the vulnerable functions in core image and be able to overwrite them via call (length of which any
reasonable programmer will check). So whether this vulnerability is exploitable or not for applications
that we are running is an open question.
In any case most installed systems are theoretically vilnerable. Practically too if they are running
applications that do not check length for such system calls.
Only recently patched systems with glibc-2.11.3-17.74.13.x86_64 and above are not vulnerable.
Red Hat, which just reported a profit of $47.9 million (or 26 cents a share) on revenue of $456
million for its third quarter, has managed to pull off a tricky feat: It's been able to make money
off of free, well, open-source, software. (It's profit for the year-ago quarter was $52 million.)
In a blog post, Red Hat CEO Jim Whitehurst said the old days when IT pros risked their careers
by betting on open source rather than proprietary software are over. That old adage that you can't
be fired for buying IBM should be updated, I guess.
In what looks something like a victory lap, Whitehurst wrote that every company now runs some
sort of open source software. He wrote:
Many of us remember the now infamous "Halloween Documents," the classic quote from former Microsoft
CEO Steve Ballmer describing Linux as a "cancer," and comments made by former Microsoft CEO Bill
Gates, saying, "So certainly we think of [Linux] as a competitor in the student and hobbyist market.
But I really do not think in the commercial market, we'll see it [compete with Windows] in any significant
way."
He contrasted that to Ballmer successor's Satya Nadella's professed love of Linux. To be fair,
Azure was well down the road to embracing open source late in Ballmer's reign but Microsoft's transition
from open-source basher to open-source lover is still noteworthy - and indicative of open-source
software's wide spread adoption. If you can't beat 'em, join 'em.
Open source is great, but profitable?
So everyone agrees that open source is goodness. But not everyone is sure that many companies
will be able to replicate Red Hat's success profiting from it.
Sure, Microsoft wants people to run Linux and Java and whatever on Azure because that gives Azure
a critical mass of new-age users who are not necessarily enamored of .NET and Windows. And, Microsoft
has lots of revenue opportunities once those developers and companies are on Azure. (The fact that
Microsoft is open-sourcing .NET is icing on the open-source cake.)
But how does a company that is 100 percent focused on say, selling support and services and enhancements
to Apache Hadoop, make money? A couple of these companies are extremely well-funded and it's
unclear where the cash burn ends and the profits can begin.
[snip]
Docker - FreeBSD like container + API for L
Linux Containers (LXC) is a virtualization method for running multiple isolated Linux systems.
Docker extends LXC. It uses LXC, cgroups, Linux kernel and other parts to automate the deployment
of applications inside software containers.
It comes with API to runs processes in isolation. With docker I can pack WordPress (or any other
app written in Python/Ruby/Php & friends) and its dependencies in a lightweight, portable, self-sufficient
container. I can deploy and test such container on any Linux based server.
A patch dating back to 2005 was pushed for Xen to fix a vmalloc_fault() path that was similar
to what was reported by Dave. The patch had a comment that read "the line below does not always work.
Needs investigating!" But it looks like this issue was never properly investigated. Due to the nature
of the bug and its difficulty in tracking down, testers might be finding multiple but similar bugs
within the kernel. Linus even suggested
taking a look
in the watchdog code. He also concluded the Xen bug to be
a different
issue. The bug hunt continues in the Linux Kernel Mailing List."
Selected Skeptical Comments
binarylarry (1338699) on Saturday November 29, 2014 @01:04PM (#48485753)
Re: Have they checked systemd? (Score:5, Funny)
It's not systemd related, you can check by opening a termin
Anonymous Coward on Saturday November 29, 2014 @12:34PM (#48485599)
Re: What's happening to Linux? (Score:0)
The kernel with the above problems isn't in the 14.04 ubuntu repo, the latest kernel in 14.04
is 3.13 and is not having this problem. I'm sure it will be fixed soon.
Anonymous Coward on Saturday November 29, 2014 @01:15PM (#48485819)
Re:What's happening to Linux? (Score:1)
I love the assumption that this isn't happening in the corporate world.
It is. It just happens behind closed doors. Thus, patches.
raymorris (2726007) on Saturday November 29, 2014 @01:08PM (#48485775)
Try a stable distro like RH/CentOS. Or Mac (Score:3)
> First got into it ... because Linux was totally stable
If stable is your top priority, Fedora is approximately the worst possible choice. Fedora is
essentially Red Hat Beta. If you want stable, the devel / beta branch is not for you. You'll probably
be much happier with Red Hat or its twin, CentOS.
Also, you mentioned that you did an "upgrade" to Debian Unstable. You didn't mention any _reason_
for doing that. If stability is a top priority for you, don't upgrade just because you can, don't
fix it if it aint broke.
Mac OSX may indeed be a good choice for you also. It is certified Unix and if you use the commondand
line in Linux you'll find that day-to-day tasks are the same on a Mac. System internals are different
of course, but bash, sed, awk, grep, and vim work just like they do on Linux.
Anonymous Coward on Saturday November 29, 2014 @02:14PM (#48486131)
Re:But guys... (Score:0)
RHEL is an entire distribution. Does this magically make every package inside "enterprise"?
I was referring to single tools and programs. Before you hit me with that "Windows is not a single
tool" bat - it does not contain too much. Let's take usable entities instead of packages, software,
tools, etc.
And that "doubled Software thing", it was kind of "finger intelligence", i.e. if your fingers
type stupid things for themselves. I have another such example: Ever typed Touring complete instead
of Turing complete? How about reading holocaust instead of localhost? ;)
jones_supa (887896) on Saturday November 29, 2014 @02:08PM (#48486099)
Re: But guys... (Score:4, Informative)
Have you ever compared enterprise class software (I also count Windows 7 Enterprise)
with OSS Software? Windows does not even reliably support STR and resume. Using multiple monitors
is a PITA.
Suspend and multiple monitors have always worked great in Windows for me. Under Linux, they
have also worked fine in some machines, but I have also occasionally experienced serious problems
with those areas. During recent times I have found out that even laptop screen brightness adjustment
cannot be expected to work reliably out of the box under Linux.
SuricouRaven (1897204) on Saturday November 29, 2014 @03:26PM (#48486683)
Re: But guys... (Score:2)
There's an imbalance in development. Under windows, every hardware manufacturer does all they
can to ensure their hardware is good - investing a lot of money in developing and testing the
drivers. Under linux, the manufacturers usually don't care - aside from some server hardware,
there just aren't enough resources to justify it from a business perspective. So development falls
to three-man team on a side project, and sometimes it's down to community volunteers working from
reverse-engineered specifications.
jellomizer (103300) on Saturday November 29, 2014 @03:09PM (#48486527)
Re: Come on Slashdot, get your news current (Score:3)
A Microsoft bug, proof of the incompetence of closed source.
A Linux bug. Either point to some closed source factor, or claim its solving a victory in the
flexibility of open source.
Anonymous Coward on Saturday November 29, 2014 @01:36PM (#48485973)
Some actual information (Score:0)
So it may be a "bad" lockup bug in the sense that nobody knows exactly what causes it, but
it's not "bad" in the sense that people should worry overly.
Why?
Dave Jones sees it only under insane loads (CPU loads of 150+) running a stress tester that
is designed to do crazy things (trinity). And he can reproduce it on only one of his machines,
and even there it takes hours. And it happens on a debug kernel that has DEBUG_PAGEALLOC and other
explicit (and complex) debug code enabled. And even then the bug is a "Hmm. We made no progress
in the last 21 seconds", rather than anything stranger.
In other words, it's "bad" in the sense that any unknown behavior is bad, but it's unknown
mainly because it's so hard to trigger. Nobody else than core developers should really care. And
those developers do care, so it's not like it's worrisome there either. It just takes longer to
figure out because the usual "bisect it" approach isn't very easy when it can take a day to reproduce..
Scientific
Linux 6.3
is now based on Red Had
Enterprise
Linux 6.3,
powered by
Linux
kernel 2.6.32,
and features XOrg Server 1.7.7, IceWM 1.2.37, GNOME 2.28, Firefox 10.0.6, Thunderbird 10.0.6, LibreOffice
3.4.5.2 and KDE Software Compilation 4.3.4.
Moreover, the distro includes software from rpmforge, epel and elrepo in order to provide
support for NTFS and Reiserfs filesystems, secure network connection via OpenVPN, VPNC, PPTP,
better multimedia support, and various filesystem tools like dd_rescue, gparted, ddrescue, gdisk.
Scientific Linux 6.3 is distributed as Live CD and DVD ISO images, supporting both 32-bit and
64-bit architectures.
The complete list of changes with a comprehensive list of fixes, improvements, removed and updated
packages, can be found in the
official release announcement for Scientific Linux 6.3 Live CD/DVD.
Oracle Linux: A better alternative to CentOS We firmly believe that Oracle Linux is the best Linux
distribution on the market today. It's reliable, it's affordable, it's 100% compatible with your
existing applications, and it gives you access to some of the most cutting-edge innovations
in Linux like Ksplice and dtrace.
But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at
all, for at least some of your systems. So even if we made the best paid distribution in the world
(and we think we do), we can't actually get it to you... or can we?
We're putting Oracle Linux in your hands by doing two things:
◦We've made the Oracle Linux software available free of charge ◦We've created a simple script
to switch your CentOS systems to Oracle Linux We think you'll like what you find, and we'd love for
you to give it a try.
Switch your CentOS systems to Oracle Linux Run the following as root:
curl -O https://linux.oracle.com/switch/centos2ol.sh
sh centos2ol.sh
FAQ Q: Wait, doesn't Oracle Linux cost money? A: Oracle Linux support costs money. If you just
want the software, it's 100% free. And it's all in our yum repo at public-yum.oracle.com. Major releases,
errata, the whole shebang. Free source code, free binaries, free updates, freely redistributable,
free for production use. Yes, we know that this is Oracle, but it's actually free. Seriously.
During our conversation, Coekaerts touched on a range of additional topics - such as:
Oracle Linux vs. SUSE Linux: "SUSE is gone; we don't see them in the market anymore."
Whether PC server makers (Dell, HP, etc.) will pre-install Oracle Linux: "They aren't
shipping it, but they are supporting it."
On the Unbreakable Enterprise Kernel: "The kernel source is 100 percent open and every
line of code is public."
On Oracle Linux vs. Red Hat and CentOS: "We are as free and as open as CentOS."
On Oracle's own cloud/SaaS systems: "The majority runs on Linux."
On Oracle's Linux development strategy. "We spend 50 percent of our time making Linux
a better operating system, and 50 percent of our time making Oracle run really well on Linux."
On perceived competition with Red Hat. "We're not really worried about Red Hat, but
Red Hat does need a competitor. They are known to be arrogant. SUSE was a competitor with Red
Hat but they lost their way."
On Ubuntu and Mark Shuttleworth: "Ubuntu was not built to be a server product. They've tried
to position for cloud servers, but ISVs have written applications for a particular platform -
and it isn't Ubuntu. The ISV world isn't going to start testing on Ubuntu."
On software appliances. "ISVs can not bundle Red Hat or SUSE with their software appliances;
they would need support subscriptions [from Red Hat or SUSE] to do so. CentOS is one potential
alternative to bundle but that offers no support. Oracle Linux is the only truly free option;
ISVs can embed Oracle Linux [with their software appliances."
Oracle, by the way, calls the software appliances "templates." So far, Oracle has about
120+ templates but "we need to do an effort" to promote the template concept to ISVs, he added.
On multi-vendor vs. single-vendor solutions. "Around 2002 or 2003, companies wanted
one vendor to deal with. Then it went multi-vendor. Now we're getting back to customers wanting
just one vendor because it's all about cost savings. And we're low-cost."
On potential synergies and code sharing between Solaris and Oracle Linux. "They are
separate organizations but we have a great relationship. When I meet with customers I tell them
I'm here to talk about Linux. But Oracle supports and invests in both Linux and Solaris. We give
customers choice."
On Cisco's UCS (Unified Compute System) and server strategy. "It's pretty popular.
It's interesting. I'm surprised to see them have the amount of installs [reported]." But, he asserts,
UCS is proprietary because you can only plug Cisco's own blades into Cisco's blade centers.
On OpenStack, cloud computing and virtualization: "Everyone thinks the cloud is about
virtualization. But the cloud is an application delivery mechanism, not a virtualization story.
And now we hear about OpenStack, but OpenStack is about providing VMs. We're about delivering
an eBusiness suite."
Admittedly, this blog entry doesn't give equal time to many of the companies
Coekaerts mentioned. But that's the beauty of a blog like The VAR Guy - we'll be back with continuing
coverage of all the key players.
Final Thoughts
In the meantime, Coekaerts made an impression on The VAR Guy. Employees within big technology
companies often filter their words or use slick marketing presentations when sitting down with
the media. Coekaerts showed up to our meeting with no safety nets, no presentations - and no filters.
The support showdown started a couple of weeks ago, when
Red Hat extended the life cycle of Red Hat Enterprise
Linux (RHEL) versions 5 and 6 from the norm of seven years to a new standard of 10 years. A few days
later, Oracle
responded
by extending Oracle Linux life cycles to 10 years. Side note: It sounds like SUSE, now owned by Attachmate,
also offers extended Linux support of
up to 10 years.
The UNIX cult is widespread across the Galaxy now and the surprise discovery of some ancient
files in the archives of Intergalactic Brain Machines on Sol 3 triggered the dispatch of an inter-disciplinary
investigation team. The files are extremely extensive, occupying all of a small island off the
coast of Continent 3. It transpires that the island was taken over by Intergal in the aftermath
of the Corporate Wars which plagued Sol 3 some centuries after the birth of the cult.
The team were asked to find out the original meaning of some of the incantations used in UNIX
religious practice and also to shed some light on what it all meant at the start.
We should take this opportunity to use the ancient prayer:
UNIX is a trademark of AT&T in the USA and other countries.
Earlier versions of this prayer do seem to exist, it is unclear why the form of words altered.
`AT&T' was the Corporation where the Creators of the cult worshiped. The Corporation totally disappeared
in the wars and many of its original records were either destroyed or altered by the victor in
an attempt to `re-write' history. The placement of the country USA on the four continents has
been lost.
Why is UNIX successful?
The computer world seems to have gone `UNIX mad', and it is hard to understand why. One good
reason is the portability of the system but there must be more to it than that. Most people
who use the UNIX system seem to like it even though it is full of idiosyncrasies, is terse
to the point of unhelpfulness and consists of a very large number of totally forgettable commands.
I think that the success of the system is summed up by the following paragraph.
The UNIX system is successful because the minimum number of keystrokes achieve the maximum
effort. In addition, the system says very little to explain errors and relies on the intelligence
of the user to deduce reasons for failure.
The statement describes UNIX V6, which we all know is the parent of the UNIX systems running
today. History tells us that the guys who designed it did their own typing into the machine.
It seems to me that because of this, the main reason that UNIX enjoys/suffers from terse input
and output is not through any intellectual design decisions made at some early stage but because
the UNIX designers were just bad typists working on slow peripherals.
Please note that so called "hacker dictionary" is the jargon file spoiled by Eric Raymond :-)
-- earlier versions of jargon file are better than the latest hacker dictionary...
2. Tao_Of_Programming (originated in 1992). This is probably
No. 2 classic. There are several variants, but the link provided seems to be the original text (or at
least an early version close to the original).
Here is a classic quote:
"When you have learned to snatch the error code from the trap frame, it will be time for you to
leave."
... ...
If the Tao is great, then the operating system is great. If the operating system is great, then
the compiler is great. If the compiler is greater, then the applications is great. The user is pleased
and there is harmony in the world.
3. Know your Unix
System Administrator by Stephan Zielinski -- Probably the third most famous Unix humor
item. See also KNOW YOUR
UNIX SYSTEM ADMINISTRATOR also at
Field Guide to
System Administrators [rec.humor.funny]. I personally like the descriptions of idiots and fascists
and tend to believe that a lot of administrative fascists are ex-secretaries :-). At the same time
former programmers can became sadists also quite often -- there is something in sysadmin job that
seems cultivates the feeling of superiority and sadism ( "Users are Losers" mentality. IMHO other
members of classification are not that realistic :-) :
There are four major species of Unix sysad:
The
Technical Thug.
Usually a systems programmer who has been forced into system administration; writes scripts
in a polyglot of the Bourne shell, sed, C, awk, perl, and APL.
The Administrative Fascist.
Usually a retentive drone (or rarely, a harridan ex-secretary) who has been forced into
system administration.
The Maniac.
Usually an aging cracker who discovered that neither the Mossad nor Cuba are willing to
pay a living wage for computer espionage. Fell into system administration; occasionally
approaches major competitors with indesp schemes.
The Idiot.
Usually a cretin, morphodite, or old COBOL programmer selected to be the system administrator
by a committee of cretins, morphodites, and old COBOL programmers.
---------------- SITUATION: Root disk fails. ----------------
TECHNICAL THUG:
Repairs drive. Usually is able to repair filesystem from boot monitor. Failing that,
front-panel toggles microkernel in and starts script on neighboring machine to load binary
boot code into broken machine, reformat and reinstall OS. Lets it run over the weekend while
he goes mountain climbing.
ADMINISTRATIVE FASCIST:
Begins investigation to determine who broke the drive. Refuses to fix system until culprit
is identified and charged for the equipment.
MANIAC, LARGE SYSTEM:
Rips drive from system, uses sledgehammer to smash same to flinders. Calls manufacturer,
threatens pets. Abuses field engineer while they put in a new drive and reinstall the OS.
MANIAC, SMALL SYSTEM:
Rips drive from system, uses ball-peen hammer to smash same to flinders. Calls Requisitions,
threatens pets. Abuses bystanders while putting in new drive and reinstalling OS.
Writes scripts to monitor network, then rewires entire machine room, improving response
time by 2%. Shrugs shoulders, says, "I've done all I can do," and goes mountain climbing.
ADMINISTRATIVE FASCIST:
Puts network usage policy in motd. Calls up Berkeley and AT&T, badgers whoever answers
for network quotas. Tries to get xtrek freaks fired.
MANIAC:
Every two hours, pulls ethernet cable from wall and waits for connections to time out.
IDIOT:
# compress -f /dev/en0
---------------- SITUATION: User questions. ----------------
TECHNICAL THUG:
Hacks the code of emacs' doctor-mode to answer new users questions. Doesn't bother to
tell people how to start the new "guru-mode", or for that matter, emacs.
ADMINISTRATIVE FASCIST:
Puts user support policy in motd. Maintains queue of questions. Answers them when he
gets a chance, often within two weeks of receipt of the proper form.
MANIAC:
Screams at users until they go away. Sometimes barters knowledge for powerful drink
and/or sycophantic adulation.
IDIOT:
Answers all questions to best of his knowledge until the user realizes few UNIX systems
support punched cards or JCL.
4. RFC 1925 The Twelve Networking Truths by
R. Callon
It Has To Work.
No matter how hard you push and no matter what the priority, you can't increase the speed
of light. (2a) (corollary). No matter how hard you try, you can't make a baby in much less than
9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker.
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.
It is hard to be sure where they are going to land, and it could be dangerous sitting under them
as they fly overhead.
Some things in life can never be fully appreciated nor understood unless experienced firsthand.
Some things in networking can never be fully understood by someone who neither builds commercial
networking equipment nor runs an operational network.
It is always possible to aglutenate multiple separate problems into a single complex interdependent
solution. In most cases this is a bad idea.
It is easier to move a problem around (for example, by moving the problem to a different part
of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible
to add another level of indirection.
It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all
three).
It is more complicated than you think.
For all resources, whatever it is, you need more. (9a) (corollary) Every networking problem
always takes longer to solve than it seems like it should.
One size never fits all.
Every old idea will be proposed again with a different name and a different presentation,
regardless of whether it works. (11a) (corollary). See rule 6a.
In protocol design, perfection has been reached not when there is nothing left to add, but
when there is nothing left to take away.
5. Murphy's laws -- I especially
like "Experts arose from their own urgent need to exist." :-). See also
If there is a possibility of several things going wrong, the one that will cause the most
damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong,
it will happen then.
If anything simply cannot go wrong, it will anyway.
If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent
these, then a fifth way, unprepared for, will promptly develop.
Left to themselves, things tend to go from bad to worse.
If everything seems to be going well, you have obviously overlooked something.
Nature always sides with the hidden flaw.
Mother nature is a bitch.
It is impossible to make anything foolproof because fools are so ingenious.
Whenever you set out to do something, something else must be done first.
OO experienced a Road To Damascus situation the moment objects first crossed her mind. From that
moment on everything in her life became object oriented and the project never looked back. Or forwards.
Instead, it kept sending messages to itself asking it what direction it was facing in and would
it mind having a look around and send me a message telling me what was there...
OO thinks in Smalltalk and talks to you in Eiffel or Modula-3; unfortunately she's filled the
disk with the compilers for them and instead of getting any real work done she's busy writing papers
on holes in the type systems and, like all OOs, is designing her own perfect language.
The most dangerous OOs are OODB hackers; they inevitably demand a powerful workstation with local
disk onto which they'll put a couple of hundred megabytes of unstructured, incoherent pointers all
of which point to the number 42; any attempt to read or write it usually results in the network being
down for a week at least.
Real Programmers don't write specs -- users should consider themselves lucky to get any programs
at all, and take what they get.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write application programs, they program right down on the bare metal.
Application programming is for feebs who can't do system programming.
... ... ...
Real Programmers aren't scared of GOTOs... but they really prefer branches to absolute locations.
9. Real Programmers Don't
Use Pascal -- [ A letter to the editor of Datamation, volume 29 number 7, July 1983.
Ed Post Tektronix, Inc. P.O. Box 1000 m/s 63-205 Wilsonville, OR 97070 Copyright (c) 1982]
Back in the good old days-- the "Golden Era" of computers-- it was easy to separate the men from
the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature). During this period,
the Real Men were the ones who understood computer programming, and the Quiche Eaters were the ones
who didn't. A real computer programmer said things like "DO 10 I=1,10" and "ABEND" (they actually
talked in capital letters, you understand), and the rest of the world said things like "computers
are too complicated for me" and "I can't relate to computers-- they're so impersonal". (A previous
work [1] points out that Real Men don't "relate" to anything, and aren't afraid of being impersonal.)
But, as usual, times change. We are faced today with a world in which little old ladies can get
computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids
and Pac-Man, and anyone can buy and even understand their very own personal Computer. The Real Programmer
is in danger of becoming extinct, of being replaced by high school students with TRASH-80s.
There is a clear need to point out the differences between the typical high school junior Pac-Man
player and a Real Programmer. If this difference is made clear, it will give these kids something
to aspire to -- a role model, a Father Figure. It will also help explain to the employers of Real
Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year
old Pac-Man players (at a considerable salary savings).
Last week I walked into a local "home style cookin' restaurant/watering hole" to pick up a take
out order. I spoke briefly to the waitress behind the counter, who told me my order would be done
in a few minutes.
So, while I was busy gazing at the farm implements hanging on the walls, I was approached by two,
uh, um... well, let's call them "natives".
These guys might just be the original Texas rednecks -- complete with ten-gallon hats, snakeskin
boots and the pervasive odor of cheap beer and whiskey.
"Pardon us, ma'am. Mind of we ask you a question?"
Well, people keep telling me that Texans are real friendly, so I nodded.
And they showed me the way There were salesmen down the corridor I thought I heard them say Welcome
to Mountain View California Such a lovely place Such a lovely place (backgrounded) Such a lovely
trace(1) Plenty of jobs at Mountain View California Any time of year Any time of year (backgrounded)
You can find one here You can find one here
... ... ... ... ... ... ...
John Lennon's Yesterday -- variation for programmers.
Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.
Suddenly,
There's not half the files there used to be,
And there's a milestone hanging over me
The system crashed so suddenly.
I pushed something wrong
What it was I could not say.
Now all my data's gone
and I long for yesterday-ay-ay-ay.
Yesterday,
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.
Notes from some recent archeological findings on the birth of the UNIX cult on Sol 3 are presented.
Recently discovered electronic records have shed considerable light on the beginnings of the cult.
A sketchy history of the cult is attempted.
This article was written in 1984 and was published in various UNIX newsletters across the world.
I thought that it should be revived to mark the first 25 years of UNIX. If you like this, then you
might also like The UNIX Cult.
Peter Collinson
"VisTech is your one-stop source for Internet and Intranet open source development, as well as
open source software support and collaborative development" said Smuda, adjusting the toupee he has
worn since age 23. "We are a full-service company that can evaluate and integrate multi-platform
open source solutions, including Linux, Solaris, Aix and HP-UX"
"Remember, no job is too small for the professionals at VisTech," added the spouseless, childless
man, who is destined to die alone and unloved. "And no job is too big, either."
Nearly six years after publication of Dijkstra's now-famous letter, [1] the subject of GOTO-less
programming still stirs considerable controversy. Dijkstra and his supporters claim that the GOTO statement
leads to difficulty in debugging, modifying, understanding and proving programs. GOTO advocates argues
that this statement, used correctly, need not lead to problems, and that it provides a natural straightforward
solution to common programming procedures.
Numerous solutions have been advanced in an attempt to resolve this debate. Nevertheless, despite
the efforts of some of the foremost computer scientists, the battle continues to rage.
The author has developed a new language construct on which, he believes, both the pro- and the anti-GOTO
factions can agree. This construct is called the COME FROM statement. Although usage of the COME FROM
statement is independent of the linguistic environment, its use will be illustrated within the FORTRAN
language.
A. Optimism
B. Mild Wariness
C. Tried to overcome headache. I was really tied
D. Controlled Hostility
2. DESCRIBE YOUR WORKPLACE:
A. An enterprising, dynamic group of individuals laying the groundwork for tomorrow's economy.
B. A bunch of geeks with questionable social skills.
C. An anxiety-ridden, with long hours and a lot of stress because of backbiting bunch of finger-pointers.
D. Jerks and PHB
3. DESCRIBE YOUR HOME:
A. Small, but efficient.
B. Shared and dormlike.
C. Rubble-strewn and fetid.
D. I have a personal network at my home with three or more connected computers and permanent connection
to the Internet
NEW ELEMENT DISCOVERED!
The heaviest element known to science was recently discovered by university physicists. The new
element was tentatively named Administratium. It has no protons and no electrons, and thus has an
atomic number of 0. However, it does have one neutron, 15 assistant neutrons, 70 vice-neutrons, and
161 assistant vice-neutrons. This gives it an atomic mass of 247. These 247 particles are held together
by a force that involves constant exchange of a special class of particle called morons.
Since it does not have electrons, Administratium is inert. However, it can be detected chemically
as it impedes every reaction with which it comes into contact. According to the discoverers, a minute
amount of Administratium added to one reaction caused it to take over four days to complete. Without
Administratium, the reaction took less than one second.
Administratium has a half-life of approximately three years, after which it does not normally
decay but instead undergoes a complex nuclear process called "Reorganization". In this little-understood
process, assistant neutrons, vice-neutrons, and assistant vice-neutrons appear to exchange places.
Early results indicate that atomic mass actually increases after each "Reorganization".
Anytime you see a penguin, it makes you think of Linux
Your computer has more RAM than your car has horsepower.
When you hear the term "Evil Empire", you think, not of Ronald Reagan and the old USSR, but
of Microsoft.
Before you move into a new house or apartment, the most important thing to you is the type
and amount of wiring with which it is equipped.
You have a LAN in your room.
You like the sound of modems when they're handshaking.
Pornography is not the first thing you think of when you see the letter X.
You don't think wearing tennis shoes with a suit is strange.
You own more than 50 T-shirts, but can't remember the last time you had to actually pay for
one.
You understood the InterBase T-shirt.
You're the highest-paid but worst-dressed person in the office.
You get involved in heated conversations on newsgroups concerning things about which "normal"
people have never even heard.
You've spent more time in front of a computer screen than a television screen.
Your PC's monitor is bigger than your television screen.
When watching movies that show computers, you can not only tell which operating system is
being used, but you also know what development tool was likely used to create the custom applications
that are shown.
You know where Scott's Valley is.
You know that it wasn't named after Scott McNealy.
You know who Scott McNealy is.
You keep in touch with dozens of people on a regular basis, but have not sent a personal letter
via the post office in years.
"The first one's free!" vs "Download a free trial version..."
Have important South-East Asian connections.
Realize that there's tons of cash in the 14- to 25-year-old market.
Drug Dealers: unhealthy addictions. Software Developers: DOOM. Quake. SimCity. Duke Nukem. 'Nuff
said.
Jokes Magazine
Ten Commandments For Stress Free Programming December 23, 1999
Thou shalt not worry about bugs. Bugs in your software are actually special features.
Thou shalt not fix abort conditions. Your user has a better chance of winning state lottery
than getting the same abort again.
Thou shalt not handle errors. Error handing was meant for error prone people, neither you
or your users are error prone.
Thou shalt not restrict users. Don't do any editing, let the user input anything, anywhere,
anytime. That is being very user friendly.
Thou shalt not optimize. Your user are very thankful to get the information, they don't worry
about speed and efficiency.
Thou shalt not provide help. If your users can not figure out themselves how to use your software
than they are too dumb to deserve the benefits of your software any way.
Thou shalt not document. Documentation only comes in handy for making future modifications.
You made the software perfect the first time, it will never need mods.
Thou shalt not hurry. Only the cute and the mighty should get the program by deadline.
Thou shalt not revise. Your interpretation of specs was right, you know the users' requirements
better than them.
Thou shalt not share. If other programmers needed some of your code, they should have written
it themselves.
The Last but not LeastTechnology 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
FAIR USE NOTICEThis 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.
Created May 16, 1996; Last modified:
July 24, 2021
level 1
Normally, I never care about banner ads that scroll through graphic installers. This time, the slogan Free to use, free to download, free to update. Always still caught my attention.
