RedHat sucks
So a customer of mine needs to use RedHat. It's not their choice, the choice was forced upon them by the people who wrote the tools they need to use.
The new version of this particular tool which they wanted to use requires RHEL5, and they're currently running RHEL4. So I had to upgrade their systems from RHEL4 to RHEL5. No sweat, right?
Yeah, right.
RedHat has this nice 'Red Hat Network', where you can manage your servers, and remotely mark packages for upgrade. You can also, by way of a command line tool, say that you want it to upgrade from one release to another. This can't be done remotely, which sortof makes sense; upgrading from one release to another might cause problems that you really really don't want if you don't have an immediate shell. So you should use 'up2date --upgrade-to-release=5' to upgrade from RHEL4 to RHEL5.
Except that that doesn't work. For some reason, RedHat chose not to support in-place upgrades from RedHat 4 to RedHat 5. Instead, you have to download installation media, boot from them (thereby inducing downtime) and select 'upgrade' in the installer. Which part of this distribution is "Enterprise", again?
Oh well. So I download the first ISO, and start the upgrade process. Surely that'll work, right?
Hah. No, I really need all six images. So I download them, and start again.
Some minutes into the installation, the HP iLO session that I'm using times out, and takes my Virtual CD device with it. As such, the installer-in-upgrade-mode obviously can't find the CD-ROM anymore, and produces a read error. This is totally normal. The system provides me with a 'retry' button. That button doesn't work.
That is to say, it works, but after two or so files, the installation goes to a grinding halt. I had to reboot, and start over.
So after rebooting, changing my iLO session settings so the timeout is at 120 minutes (the maximum) rather than 30 minutes (what appears to be the default), and I restart the upgrade process, making sure to click in the iLO interface every once in a while to keep it active. When it's somewhere at 80% and 3 hours into the upgrade process (god, why does that have to take so long?), it suddenly finds itself out of disk space.
Well, shit happens, of course; guess there's nothing to blame RedHat with that one. But the way this situation is handled, is beyond my comprehension:
The only 'recover' option is 'reboot'. There's no 'retry'. I don't mind diving to a second console, mucking about a bit on the mounted partition, and doing 'retry', but the installer doesn't even offer me that option. Instead, I have to choose 'reboot'. Never mind that the system is halfway through an installation process and might be totally and utterly broken, and not even bootable. Well, that's what rescue modes on installation media are for, I guess, but still.
After cleaning out some old files that aren't needed anymore and going back to the installer, you'd suppose that the system could figure out what it'd already done, and continue from there, right?
Well, no, it can't. It starts over from scratch, thereby forcing me to sit and wait for another three hours.
Times like these make me remember why I'm a Debian developer, and not a RedHat one. Why I chose not to finish that Linux From Scratch project that I'd started after using RedHat for three years and about six months before becoming a Debian Developer. Why I stopped hitting my computer screen around that time.
Stupid piece of shit.
disclaimer: this is all IMAO, and you don't
have to agree with me. But what's a blog for, if not to rant?
A few years ago, I had to setup a custom install CD using redhat and it was a nightmare. This might have changed since then but at that point anaconda was almost completely undocumented. What should have taken maybe a day or so to whittle down which packages I wanted took about a week of searching the web for bits and pieces of information.
About linux from scratch, I did that a long time ago and found that it was mostly worth my time. I wouldn't actually run an LFS system, but learning exactly which packages are required for a basic linux install and what they do is still worth something I think.
I guess you missed this: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-steps-network-installs-x86.html
Normally you only need a one CD-ROM (or usb stick) with the installer on, chose 'linux askmethod' on the prompt and chose netinstall. Enter http or nfs location and you're done.
Couldn't agree more about Red Hat installs and the lack of upgrades. Everyone I've talked to that runs Red Hat or Fedora just reinstalls rather than trying to upgrade. RHEL contains too few packages to be useful to developers and coders
All this IMHO
I too had a similar situation. The poor customers didn't even know which version they'd bought nor was RHN of any help. It kept borking on every attempt to even install a simple package like MySQL. After trying for a couple of days, we simply switched the repository to CentOS and upgraded the whole distro and installed the required packages. Though yum still lags apt, it's still much better than the RHN.
Are you smoking crack ?
You can install or update RHEL (or RHL or Fedora) with a network connexion since at least RHL 6 ! And with PXE if there is no CD/USB/floppy drive.
@Chris Butler
This is not so simple : http://www.fr.debian.org/releases/lenny/amd64/release-notes/ch-upgrading.en.html
@mank
$ cat /etc/redhat-release It's also printed by loggin and ... at boot time. Stupid customer.
In RHEL 5, yum use RHN. It seems that nobody here knows Red Hat and really don't want.
btw, RHEL can also use VNC since many years. RTFM.
Oh well, surely dist-upgrading isn't simple, but it is far simpler than doing a similar thing to a RedHat installation. And regarding Yum/RHN: I have stopped counting the times where yum just told me that the repository metadata was corrupt (non-matching hashes or whatever). Usually, it worked again a second later, but it really is unnerving. Additionally, I regularly have problems with registered systems suddenly not being able to access RHN anymore (and no, the subscription did not expire). Apart from the problems I regularly have with anaconda installs and x86_64 systems that also include i386 packages. Works fine as long as you make sure to exclude certain i386 packages early in the process, but you never know which ones to exclude until you hit them,.... Sure, Debian doesn't really have bi/multi-arch support (yet), so the last one can't be helt against RHEL, but given that RedHat ships bi-arch for some years now, I had expected them to fix this kind of issues by now.
You complained that this is a failure for an enterprise product, but this is not how you want to do things in the 'enterprise'. If your upgrade procedure is to upgrade the one machine running some service, with no fallover plan, nor scheduled downtime maintenance, then you're not big enough for Red Hat.
A bit of theory: You upgrade from RHEL4 -> RHEL5 which includes installing a new apache version. In order to restart the apache server to the new version, you will have to endure a minimum amount of downtime. Supporting live upgrades is such a hard to hit goal, that it's not cost effective for a large enterprise.
In the enterprise though, you'll have a whole pool of apache servers, including backups and other servers poised to take over. Furthermore, each machine is being provisioned through some automatic service, such as RHN, cobbler, or another PXE booting service. Finally, the configuration is automatically managed by a configuration tool like CFengine or puppet. In order to upgrade your pool, you schedule a time for reduced service, switch the profile of half the servers over to the new RHEL version, and reboot. In 15 minutes, your servers will be upgraded and online. Then you upgrade the other half. Zero uptime, and if you tested adequately, there should be zero worries.
Yeah,
Back in the day (RH 6.0 IIRC) I gave up trying to install RH in a laptop I had . Not becuase it was impossible but each stage present a new, but, silly challenge.
Debian -for which I had reliably informed was only for hardcore users installed much easier. I've always used debian since.
Of course I probably have always been a hardcore user - the 2nd computer I ever used I helped my father build the motherboard from a kit of parts.
and 10 years later you still cant upgrade redhat in-place. rhel 8 also provides a broken/inferior python 27 and python3.6... neither installed by default. (note: redhate does have a half-baked in place upgrade that always fails with BIOS/CSM and really 100% always fails on EFI or iscsi root systems).
now its wayland by force and kde for some reason was banished.
iptables is gone and so is a ton of compatibility with rules from before - people cant just re-use old commands - no - they must replace them and make them incompatible. nice.
now ntp is gone and chrony is forced...
a few more good ones - dsa in ssh is forced deprecated - any cowboys trying to hack up a remote upgrade
ifup and ifdown are now scripts that rely on network manager aka networkmangler. of source the systemd-ness has spread like cancer. you want scripts that suddenly stopped working after 20 years try yum install network-scripts... (they had the good sense to make yum and dnf work the same and yum symlinks to dnf).
everyone uses virt-manager in a pinch... no more! redhate has determined virt-manager should be gone. good stuff.
also redhat has a jihad for butrfs - they nuke it out for no reason. gone. because they want their barely beta fs to go in its stead..
network mangler forced, init is forced into sh1tstemd (they dont have the ability to not have systemd) and virt-manager gone.
they also farted around with nfs and nobody - making a new nobody called nfsnobody. this is really smart when dealing with mixed systems... not.
the spineless cretins at redhate also dont have (even with python2/python3 installed side by side) a /usr/bin/python - not there... so whip out a symlink, or use the horrible "alternatives" framework to supply a python to the system.
its gotten comical at this point. its easier to rebase a development environment in os x with brew than to deal with the diarhea poop mess than redhate has become. and all the abstractions and love that sh1tstemd was supposed to give us failed utterly. that systemd package gets updated / fixed / patched constantly and massive issues from version to version of crapstemd prevents easily being able to upgrade from rhel7 to rhel8.
i know ubuntu, debian, redhat, fedora, solaris, freebsd, netbsd, aix, various cloud linuxes and micro-platforms based on linuxes - jeos style linuxes, , os x , windows - from the old days, netware 3.x, 4.x+, os/2, and all sorts of obscure 1980s/1990s stuff - its a job and a hobby. most of the time its "build new" and "move to" rather than lift and shifts or keeping old cruft around - but never - and i mean never - have i seen a company like redhat do so much to make compatibility with itself and the rest of the linuxes as hard as possible. i went from being a bigtime whitebox linux/caos/caosity/centos supporter to really disliking it immensely - why ? because people think centos is rhel for free and because rhel is brutally expensive it must be great right!? wrong. wrong. the perceived value is the only value as it is now one of the worst and most cumbersome linux ecosystems to work with.
redhat is sad.
I just tried getting set up with RHEL 8. The first installer I downloaded from their site was actually ubuntu with a file title of RHEL(something).iso Feel free to call bullsh1t on that, it happened. I couldn't register because I need an org. I copy/pasted entered my developer org. It didn't work because error something was unsubscriptable. Looked up the error. Resolution is to fix a file that doesn't exist. then another said, update. I tried to update but can't until I register. But it seems I can't register until I update. So I tried adding a new activation key to my account and when I clicked new it 404'd me. Then I tried to look at my activation key and it 404'd me again. Then I called the customer support number and it didn't even ring. Now I'm going to try an reinstall. This is nuts. If it wasn't for Openshift being a job requirement for me now I would go directly back to Debian.