[CentOS] Upgrading from CentOS 5.6 to 6.0

Red Hat does not support upgrades between major versions (doesn't
necessarily mean it's not possible)
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-upgrade-x86.html
http://linsec.ca/blog/2011/02/23/my-adventure-upgrading-rhel5-to-rhel6/

Microsoft Windows and Red Hat Linux have a very different release strategies
and version numbers. You can read more about the support lifecycle here:
https://access.redhat.com/support/policy/updates/errata/

_____

From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
Of Giovanni Tirloni
Sent: Saturday, July 23, 2011 6:54 PM
To: CentOS mailing list
Subject: Re: [CentOS] Upgrading from CentOS 5.6 to 6.0


On Sat, Jul 23, 2011 at 7:41 PM, Thomas Dukes wrote:


Help!

Just ran the installation DVD but there is no option to 'upgrade'. Looked at
the RHEL docs,
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati
<http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installat
i%0Aon_Guide/ch-guimode-x86.html#id4594292>
on_Guide/ch-guimode-x86.html#id4594292 referenced off the CentOS Release
notes but the CentOS installation doesn't offer the 'upgrade'.

I use to be able to upgrade by doing a 'yum update'. That doesn't work
either.

Guess I'm stuck with 5.6 as I an not about to install a new version and have
to rebuild all non-rpm packages from scratch. This is worse than Microsoft!!



Red Hat does not support upgrades between major versions (doesn't
necessarily mean it's not possible)
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati
on_Guide/ch-upgrade-x86.html
http://linsec.ca/blog/2011/02/23/my-adventure-upgrading-rhel5-to-rhel6/

Since when?? I started with slackware 1.0 on a pentinum 1 system from
VaResearch back in the mid 90's, change to Redat 2.0, then Fedora, then to
Whitebox, then CentOS.. Never had a problem upgrading on an rpm based
system.

Microsoft Windows and Red Hat Linux have a very different release strategies
and version numbers. You can read more about the support lifecycle here:
https://access.redhat.com/support/policy/updates/errata/

That's a good question. It seems that since RHEL 4 (2005), Red Hat has
been telling us that upgrading from earlier major versions is not a
good idea.

- RHEL 3 docs say it's possible to upgrade from 2.1 to 3.x (http://goo.gl/8Gwrs)
- RHEL 4 docs don't bother showing the steps and provide a lot of
warnings for 2.x/3.x to 4.x (http://goo.gl/yiRGK)
- RHEL 5 docs explicitly say Red Hat does not support upgrading from
earlier major versions (http://goo.gl/RQABB)
- RHEL 6 docs explicitly say Red Hat does not support upgrading from
earlier major versions (http://goo.gl/H9zBU)

I don't think RPM is the one allowing/disallowing the upgrade between
major versions. The kernel architecture and other major components
changes are more likely to be the culprit. I'd be surprised how you
moved from Slackware 1.0 all the way to CentOS without a reinstall
(because that's what is being discussed here).

Just as reference, starting with Solaris 11, it'll not be possible to
upgrade from earlier major versions either (although binary
compatibility will still be there). Oracle is asking customers to
treat earlier versions as legacy and put them in containers and/or
virtual machines. Solaris 11 will change so much how things work that
Oracle says it's better not to bother upgrading path from Solaris 10.

My point is that big changes happen in Linux much frequently than in
Solaris and even Solaris sometimes doesn't support these kinds of
upgrades.

It is the inevitable and time-consuming upheaval which many will
probably find daunting. Installing Centos then configuring it for a
specific manner of operation can take several hours.

When I recently re-installed C 5.6 as a server/desktop, the
configuration took 4 to 5 hours to complete. I didn't use kickstart.

People love and appreciate Centos. They sometimes shudder at the
implication of effectively a re-installation, re-configuration and a
translation of perfectly good reliable working applications into
unfamiliar compulsory alternatives. Get something wrong and the time and
effort increases and competes with the daily priorities of running a
smooth computer operation and responding to all the things that do
occur.

The challenge is how to do an easily transition from one major version
to its successor version with the least physical, emotional,
intellectual and time-consuming effort.

Paul,

as much as I understand your point of view, I must disagree taking
upstream's and CentOS's position. Your description reflects a home user
or an administrator with just less than a handful of systems.

CentOS and RHEL aims for the enterprise use. Of course that does not
imply people can not rely on this stable platform in very small
environments, but that's not the focus of the OS design. And speaking
about the enterprise scenario, no serious administrator will risk the
proper function of his install base by going risky paths. Typically the
OS is just the base for the middleware and application level. Switching
to a new major level of OS with lots of important changes means, the
administrator will have to test and adjust his setup of OS and
application use in multiple aspects. This even applies to applications
the base OS ships with.

In enterprise environments, where the CentOS systems are more than a
simple shell box or a trivial webserver, it is more time consuming to
find all the possible places to adjust the obsolete configurations being
transferred by an upgrade and to find the tripping points than to run a
clean and fresh installation with a defined state. In less trivial
setups the applications even get wrecked because of library changes and
such.

Regards

Alexander

Alexander,

I have 11 servers all running C 5.6 and will stay on 5.x while
everything works satisfactorily. For development and experimentation I
use 2 desktops, laptop and notebook running C 5.6 as a server/client
(server/normal user). The 6.x kernel offers me new development
possibilities.
The operating system comprises several parts. The kernel, Red Hat's
versions of various semi-system/application software, the extras like
clustering and kvm. The focus of the design is to provide a very stable
base upon which many different additions will successfully operate and
co-exist.

Red Hat provide one basic version of their RHEL which can be used both
as a server and as a client (meaning 'normal user' environment). You may
have noticed RH's endorsement of Gnome. RHEL is an enterprise operating
system but enterprise, in the commercial understanding of the word,
means more than a server farm or racks in a data centre. It means the
entire corporation - servers and end-users. From the payroll system to
the chief executive officer's desk. RHEL does all these different tasks
admirably well.
The large? jump from 5.x to 6.x and the resulting pressure on people to
find the problems and solve them is, obviously, time consuming and for
some demanding.

If some (certainly not 'all') of the 'new' 6.x
systems/changes/improvements were available in 5.x, people could
gradually learn about them including any changes. This pre-knowledge
spread over a year, would make major version transitions easier and
quicker. I acknowledge this is not a Centos issue but a Red Hat policy.
A solution is to experiment with the relevant Fedora versions.
Hopefully each application has just one configuration file in one known
location. Keeping a set-up simple and ensuring up-to-date documentation
should avoid 'obsolete configurations' existing and 'tripping points'
occurring.

I am a sysadmin for an enterprise running both RHEL and AIX...both of them
being enterprise level OSes.

IBM has managed to support in place upgrading of their OSes from one major
version to another for several versions, now...in fact, each release is,
according to IBM, a separate release, with technical levels or maintenance
levels and service packs being in-level patches.

So, going from 5.3 TL6 SP6 to 5.3 TL12 is as considered patching and is as
simple as running "smitty update_all" from within an appropriately
configured repository directory (or directories), much like running "yum
update".

On the other hand, going from 5.1 anything to 5.2 anything, 5.2 to 5.3,
5.3 to 6.1 is considered a major release...and upgrading those, in place,
is fully supported by IBM, and is as simple as either booting from an
appropriate boot disk, or using the appropriately configured NIM boot and
install/up process.

If IBM can make this happen for their OS, and Red Hat certainly supports
such a process in the Fedora line of releases (including the ability to
list additional repositories for remote installation as part of the
process), they could certainly make it a supportable option for the RHEL
line.

The upstream supports nothing as to Fedora, and indeed,
members of that project regularly (and seem to gleefully)
break forward compatability

But you are missing the point -- WHY spend the engineering
effort on trying to support such Major 'upgradeany's? A new
deployment takes mere minutes for a commercial shop, and by
NOT supporting such explicitly, the upstream avoids much
support and engineering load.

[I say this having done an 'upgradeany' and run into a later
'nss' in C5 than the C6 initial media provides, that required
some head scratching, and a nasty workaround, to solve over
the weekend]

-- Russ herrold

I can not believe that the upstream does not guide/provide direction with
regard to the Fedora project, given that the Fedora project is still the
test bed for what eventually goes into the upstream's commercially
supported product.
Quite simply, because the customer base, which is paying the upstream for
support, is requesting that such a process be supported.

Quite simply, as well, because the upstream is selling the customer on the
idea that their product is an enterprise level product. Other enterprise
level *NIX providers support this process...the customer may reasonably
expect that this provider do the same.

Sure...it may take only a few minutes for a commercial shop to deploy an
OS, it takes that shop much more time to have to reinstall and reconfigure
the applications that run on those OS instances, test, cut over, etc.

Additionally, not every shop is running their entire Linux infrastructure
in a VM based environment. For those running physical systems, the
hardware may still be within their viable hardware lifecycle, but be in
need of a newer version of the OS. Should the customer have to purchase
an additional physical system for each instance of their OS that must be
upgraded from one major release to the next? Where would that leave the
customer, as far as having been sold on the cost effectiveness of their
Linux installs vs other commercial *NIX offerings?

How about those virtualized environments? Spinning up a new VM environment
to eventually replace the existing VM with a new OS instance may also
require the purchase of additional hardware, in an effort to support the
temporary resources needed to spin up, configure and test the new
instances prior to putting them into live use.

The cost of testing and then supporting live upgrade scenarios, born by
the upstream, would likely be less than the cost to the customer base in
potential hardware and manpower cycles, and would undoubtedly build the
upstream more good will from the customer base.

Consider, again, that the feature to perform an upgrade (and not via a
hidden upgradeany command line option) is available in the version of
Anaconda (the installation tool used by the upstream) that is in use for
Fedora intallations and upgrades, and that particular compilation of
Anaconda does include the ability to specify those third party
repositories from which one may have installed packages. It may be
compiled out of the binary that is in use by the upstream, but any of us
who have also used their test environment know that it's there, and are
more than aware that the upstream has and continues to disable certain
features of various included tools when shipping those tools in their
commercially supported distribution.

If there's sufficient customer demand _and_ if RH decide it's worth it
then they might support it. However I can tell you that the 20,000+ RH
machines at my place will not be major-version upgraded in-place; they'll
be rebuilt (possibly onto new hardware; maybe onto a split-mirror).
That's how we do Linux; that's how we do Solaris; heck, that's even how
we do AIX.

Our support dollars are pushing RedHat in a different direction. We don't
care about in-place major-version upgrades.

And this would be a sensible argument, were it not being made on the
CentOS list. Folks here aren't paying anyone anything.

This is more like an extension of the Fedora community, in a way -- free
testers and freeloaders. Big deal. Red Hat doesn't *need* to do anything
for us, come to think of it they're already doing quite a bit, so I see
no point in complaining.

-Iwao

Several points (all for "enterprises I've worked at")
1) Folks tend to hold onto hardware WAY past the expiration date. We
still have SunFire v1xx boxes alive and some x86 boxes that aren't 64
bit capable. If they want the latest OS, buy new hardware.
2) I've never seen an OS upgraded across major releases under an
existing app (other than a web server). Generally it is the other way.
The app guys want to run the new version, which requires the new OS, which
requires new hardware, which requires a full recert.
3) Just because IBM can do it on mainframes and Power/AIX boxes, doesn't
mean you can do it on x86 hardware. Or should even try.
4) As others have noted, comparing RHEL to Fedora is not valid.
----------------------------------------------------------------------
Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.net
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine

RPH is definitely right about "gleefully breaking forward compatibility".

It is easier to control compatibility backward and forward when you're
deploying a closed (or at least tightly controlled) system as opposed to
one that boils with change the way the Fedora upstream does.

Example: systemd

Find a way to make a transition from 6x to 7.0 seamless by way of a
simple "yum update" once SysV init goes away and all system services
must grow configuration files and drop init scripts. That's just one
subsystem, there are other huge changes as well (Gnome3...).

IBM and the tightly controlled (and decades long) OS/360 -> z/OS process
or their linear passes through AIX Ver.n -> Ver.n+i do not compare to
Red Hat's situation. Anyway, compatibility is often complex enough for
IBM to address by quietly including emulators for their previous systems
instead of shooting for base compatibility.

The key to Red Hat's success has been its hands-off approach to the
Fedora Project. If Red Hat ever desires to implement something they must
first present working implementations for acceptance by FESCo -- which
implies promising, working implementations. This forces a lot of unique
situations, but the primary effects are:
* Advances occur at a rate difficult to compare to other projects
* Entire subsystems can be marked "obsolete" if a working
implementation demonstrates superior function (systemd ousting the
venerated SysV init is an example of this "nothing sacred" attitude)
* Technical debate about anything/everything crosses company, private
and personal lines in ways difficult to interpret from a traditional
development perspective
* The chaos level is high (marked by the inability for any one person
to be an expert on everything at a given time -- by the time one thing
is thoroughly understood something else has changed)
* Absolute forward and backward compatibility requires too much
effort, so the concept of "compatibility" moves up two levels to the
data layer[1]

IBM, on the other hand, has a long-term compatibility program they
consider to be at the core of their business model (System/360 history
is interesting here). They plan their changes around a few subsystems
they consider to be sacred. If you want to change something sacred you
have to plan it out through the high priest in charge of that subsystem
-- and it is acceptable for major system changes to take several years.

The whole thought process is entirely different -- as are their target
markets. Red Hat is a good value for large- to huge-sized businesses,
and IBM is a better value (sometimes with a mix of Red Hat in some
areas/departments) for titanic- to ZOMG-sized businesses.

I apologize for the long message. I didn't have time to write a short one.

-Iwao

[1] I've been thinking about this a bit and I've come to think that
there are roughly three layers to compatibility -- so I'll define them
here since I referenced my own definition:

1- Absolute forward and backward compatibility. Code builds and runs in
exactly the same way on any system in the series.

This is the level IBM shoots for. System upgrades and downgrades are
clean, reliable and easy to recommend and support.

In Linux terms this would mean you could load, say, RHEL 3 and "yum
upgrade" to RHEL 6.1 -- whether that is through a yum-initiated upgrade
chain or a one-step upgrade is of no concern to the user.

2- Configuration compatibility. Implementations change in radical ways,
but the interpretation, format and semantics of configuration files is
absolutely respected between versions and often between competing
implementations of a single standard. OpenLDAP's move to cn=config while
retaining the ability for slapd.conf to be read and converted to a
cn=config loadable set of LDIFs is an example of this.

This is roughly what Microsoft used to aim for (somewhere on the road
between XP and 8 they seem to have totally quit the idea, though).

In Linux terms this would mean you can copy things like /etc, /var and
/home/~/.* and add the contents to whatever new is in the upgrade and
not endure any major shocks.

3- User data compatibility. Config files might change, because entire
subsystems might evaporate or be replaced. Converting between radically
different concepts (Gnome 2 to 3 with gconf to dconf, for example) means
that finding enough logical parallels to define a user/upgrade friendly
automatic conversion tool is at least as difficult as developing the
replacement system was in the first place -- and therefore an
unrewarding level of effort. User data, on the other hand -- being the
actual media, business files, whatever, are considered sacred, however,
and the system must be able to support loading the old media onto the
new system. Universal support for ODF, import support of database dumps
between PostgreSQL versions or MySQL to MariaDB, universal image
formats, JwCAD .jww export to .dxf and import to LibreCAD, mbox, etc.
are examples of this level.

This seems to be what Red Hat considers acceptable.

In Linux terms this means that you should be able to copy /home without
the dotfiles and a lot of /var (or /var-type things, depending on how
you're set up) and not be surprised by the result.

As a slightly off-topic aside, there is a youtube video out there about doing just that; the video shows an upgrade chain that goes from Windows 1.0 (no, that's not a typo) up through Windows 7, all as upgrades, along with all the things that have to be changed along the way.... some of the text the guy enters in textboxes is NSFW, however. So you'll have to google for it yourselves; it made Slashdot a few weeks back, so it shouldn't be hard to find.

I'm sure that some of these major upgrades *can* be done, but in a land where the package is the unit of OS granularity, and package maintenance practices vary from package to package as to 'upgradeableness,' it really becomes a task, and this is before even considering the upgrade-hostile attitudes of some software projects that upstream ships packaged in upstream EL.

While package groups give an illusion of a unit larger than a package, it's just an illusion, really. The collective set of dependencies defines the full distribution, and nothing in the dependency chain requires rigorous, tested, upgrade path implementation.

In the case of other commercial vendors doing this, well, those vendors typically have strict and tight control over all the developers working on it, and have enforcement mechanisms in place to ensure that migration paths are implemented. It's called an employment contract, and it's enforced through the ordinary commercial developer chain of command.

While open source developers and packagers are technically capable of doing this, some seem to take great delight in making it difficult to be compatible (partly to prevent closed-source programs from continuing to work). And if just one development group becomes the proverbial fly in the ointment, then all the users of that package that need upgrades to 'just work' suffer. And sometimes the developers care, and sometimes they don't.

But consider: upstream doesn't employ a 'critical mass' of developers in all of its shipped packages to reliably enforce upgrade provisions, even if it wanted to do so.

Beyond that, there are packages supported by upstream that have serious difficulties with major version upgrades, simply because supporting data in place upgrades is not a priority for that development group. I can think of more than one project that seems 'upgrade hostile' but in reality it's just something that's not front burner; they'd rather develop newer features and fix bugs than 'waste' time on a rarely used procedure that is, in some cases, extremely complex and in other cases simply won't work anyway. That is, there are data sets associated with some upstream packages that are impossible to migrate in place to a newer version in a seamless, nondisruptive, fashion.

In a nutshell, it becomes a tradeoff of open source freedom versus the upgrade needs of the users. If the needs of the users trump the freedom of the developers, then developer freedom (the freedom to 'scratch ones own itch'), the very essence of open source, goes out the window.

To the OP, if your itch is to have seamless in-place upgrades, then scratch that itch (or pay someone what scratching that itch is really worth... but be prepared to come up with six or seven figures). That's going to be a mighty big itch, though..... especially with over 2,500 upstream packages from nearly as many heterogeneous development groups with many more agendas of their own.

Keep in mind that the Linux kernel itself makes no concessions to
backwards compatibility and demands that all related modules be
recompiled to match changes. Enterprise distributions have their hands
full just trying to keep things working within the life of a major rev
and are generally restricted in how much new development can be added
without major breakage.

Other OS kernels have more reason to maintain backwards binary
compatibly (i.e. paying customers that demand it...).

One of my paragraphs originally included a fairly lengthy passage on kernel ABI compatibility, but I trimmed it out, and I 'genericized' to more than just the one project, and put in parentheses the statement 'partly to prevent closed-source programs from continuing to work' as a more generic thing, more than just binary kernel modules.

It's most assuredly not just the kernel.

Yes, its only a slight over-generalization to say that free projects
have no obligation to existing customers and they usually prefer 'new
and different' development to boring backward compatible support work.

Even though RHEL isn't a free project, there's only so much they can do
to reconcile the wild changes in the code they include.

A low skill user was never able to go from 2.1 to 3, nor 3 to
4, nor 4 to 5, and an a minimally skilled will not be able
to go from 5 to 6. This is the policy of the upstream, and
a sensible one, because of invasive changes each major
release represents. Functionally, each major is a new
product.

That said, the CentOS wiki has an UNSUPPORTED method for media
based 'upgradeany' transitions of the type you mention. It IS
UNSUPPORTED, because it can break systems. For that reason, I
specifically added warnings to that article, to take and test
backups before trying that path
Much worse -- you could not steal binaries and license keys
from CentOS because we give them away for free

CentOS ships no non-RPM packaged packages -- look to whoever
put those packages on your box without using the packaging
system if you feel the need to blame someone

-- Russ herrold

When I say non-rpm, I mean source packages I compiled such as zoneminder.

And even *if* you would be able to upgrade from CentOS 5.x to 6 -
technically and by personal skills - what makes you think that your self
compiled software would not completely fail, just because libraries change?

If you would have gone the proper way by using rpms, or where not
available by building your own rpms, things would be no drama for you
when doing a fresh install of CentOS 6, because you could again install
additional software from 3rd party repositories or you could just
rebuild and install your own rpms.

You are barking up the wrong tree.

Alexander

The specific example of zoneminder is particularly insidious. On our zoneminder systems, even point updates to certain libraries has created problems. A good, modern, package of zoneminder in a repo somewhere would save a lot of grief in that particular case.

And even having maintained packages before, I'm not sure I would want to touch rolling my own zoneminder package(s).

I've a full set for C5 on ZM 1.23 -- the SElinux blissful
unawareness of that code is startling, as it is doing 'unsafe'
operations all over the place. Running it on a dedicated
appliance box and treating it as a vulnerable client to a
SELinux enabled network using network sockets, is about the
only way to run it safely

1.24 looks 'doable', although perhaps not without some C6
libraries -- I see it in rawhide, and in F, after F13, as I
recall

-- Russ herrold

I managed to get 1.24.x (VM is shut down right now due to VMware update 'things' going on, so can't check specific version) running, but it wasn't pleasant, and required very specific versions of things to get it working on CentOS 5. It does work, but it is touchy if any of its dependencies gets updated. And now there is a newer version than the one I have running.....

And the SELinux business is still there (or rather, not there) and that complicates things. This seems to be more true with network cameras than with native v4l devices.

With the library version in C6 being more close to what ZM wants, it should be easier to make it work with C6. Haven't tried out C6 on our VMware setup yet; it's ESX 3.5U5, and AFAIK EL6 isn't supported on ESX3.5. But I'm still digging into that, and seeing if vSphere 4 vmware-tools from packages.vmware.com will work on ESX3.5.

If ZM just wasn't the most useful CCTV webcam software out there, bar none, I'd probably not even bother. I haven't found anything even close to ZM in terms of functionality in the open-source realm.

[clean up the trimming and leave the top post as it was]

and so the person you are angry at for not taking the time to
do the packaging, to have a SRPM that may be rebuilt, is ...

If that person just happens to be oneself then I suggest that you
use "checkinstall" in the future so avoid the pain of dealing with
custom installed software outside the rpm/yum package manager

@Thomas: I'm a "newbie" home user, with CentOS on our Desktops, and
Red Hat Linux, before that.

I do not believe you understand the philosophy behind CentOS (an
Enterprise OS) or RHEL (the upstream distro). This is a distro with a
*LONG* life, and without the "latest and greatest", for security and
stability reasons.

It has always been recommended to do a "Clean Install" when moving
from one major version (ie: 5.x) to a newer version (ie: 6.x) and then
to Restore your data, from your backup.

If you do it in some other fashion, there are apt to be problems,
which will probably not be supported on this list. If you break it,
you will fix it.

There is a lot of information available, on CentOS.org in the Wiki.
HowTos, FAQs, etc. If you look there, you will find many things
explained clearly.

Also, if you search the archives of the mailing list, you will find a
ton of information, from a large group of highly knowledgeable users.
People who work with CentOS in the Enterprise, all day, every day.

Installing non RPM software on an RPM Distro like CentOS is frowned
upon. That is the worst way to do it. There are 3rd party Yum
repositories, with lots of things that have been packaged for CentOS
and you can install them with Yum, once you have the Repository data
ready for yum. You probably won't need to rebuild many packages, if
any, if you use the 3rd party repositories. GL

I have never had a problem upgrading a CentOS release since I started with
3.x. Seems now, I can't even upgrade from 5.6 to 5.7. I have never had to do
a complete re-install since moving from Slackware 1.x to Redhat 2.x except
once when I had a hard drive failure.

I'll be moving to Ubunto. They have a 3 year window for support on a
distribution unlike CentOS/RHEL. They seem to be more user friendly for a
home networking environment.

The software package I use which takes hours of trial and error to compile
and install is as simple apt-get install under Ubunto. There are no rpms for
zoneminder 1.24.x. The compliation of ffmpeg/zoneminder seems to be an issue
with CentOS with the outdated php/mysql and other various libs.

I can see the direction RHEL is taking and its more and more like Microsoft.
The enduser is having to be more and more dependent on the provider. CentOS
has its hands tied.

I thank all for the help I have recievied over the years, its just not
beneficial to stay this current direction.

TE Dukes

I know of at least one packaged zoneminder and its required deps; I'm
not sure if it's public but if it is the person that did the packaging will
likely speak up as he is on this list. So it's indeed possible.
Good luck with future endeavors.




John

PHP and MySQL work fine for me. My systems depend on both these being
reliable, efficient, dependable and robust - they are on Centos 5.6.
While Centos (and SL) exist, we are never going to be like M$. RH needs,
commercially, to prevent/reduce business losses to copy-cat companies
like Oracle etc.
Yes all Centos users are dependent on RH if they want to run a 100%
binary compatible system. However there is flexibility to add
non-standard software and, as you have proved, one's own non-standard
applications successfully.

Good Luck. We will be here if you pop back sometime in the future.

----
update from CentOS 5.6 to 5.7 (when 5.7 becomes available) is
automatic... just run 'yum update' - no extra efforts or thought need to
be given.

update from CentOS 5.x to CentOS 6.x is at best a crapshoot. Skilled
admins should be able to fix whatever needs fixing. Less than skilled
admins will find it takes less time to backup and re-install.

As for switching to Ubuntu...

I have switched my latest installs from RHEL/CentOS to Ubuntu. Primarily
because I felt I couldn't rely upon timely releases/updates.

Let me assure you though that nothing is perfect with any distribution
and while some packages might be newer/more readily available on one
distribution than the other, there are certainly other packages that are
newer/better vice versa.

ffmpeg on CentOS/RHEL 5.x is a bit behind (CentOS/RHEL 5 is way behind).
zoneminder is just perl scripts so it doesn't make that much of a
difference if it is RPM packaged or just tarball install

CentOS/RHEL has a much larger window of support for a specific version
than Ubuntu so claiming that Ubuntu has a 3 year window as an advantage
suggests that you don't understand the RHEL/CentOS support windows at
all.

Craig

RHEL is supported for 10 years on each major release.

Huh??

From: http://mirrors.kernel.org/centos/3/readme.txt

CentOS Errata and Security Advisory CESA-2010:0817

End Of Life security update for CentOS 3:
https://rhn.redhat.com/errata/RHSA-2010-0817.html

As per the upstream vendors errata support policy, updates for CentOS-3
has ended on October 31th 2010.

It is recommended that any system still running CentOS 3 should be
upgraded to a more recent version of CentOS before this date to ensure
continued security and bug fix support.

see also http://wiki.centos.org/HowTos/EOLC3

Thank you to everyone who helped make this project possible.

Tru

RHEL/CentOS are supported 7 years from date of release to EOL date.
RHEL has an optional extended support plan that you can purchase if you
are a RHEL subscriber; CentOS does not offer this extended support as
upstream does not make the update source RPMs available for download
unless you are a paying customer.





John

No, they're not. Been there, done that.

----
why?

you made a vacuous argument.

Craig

Hunh. You are ** still ** trolling here [arguing against
package management] and on this thread [C 6 matters], Craig?

I thot back on June 13 you said here:
-- Russ herrold

----
still running some CentOS 5 servers... what's your point?

Craig

@Craig: I retract that. Probably something that is discouraged,
rather than frowned upon Lanny

In the RHEL environments where I have worked, installing non RPM
software was more than frowned upon. It was strictly forbidden and cause
for immediate public flogging. If someone could not (or did not want to)
understand why installing non RPM software was a bad idea then that
person would have been removed from his duties.

It's like using imperial units or US customary units (so non-metric) in
Satellite design. It's just not an option. And if you insist then you
can use it but it will be in your own basement and not at a vendor
creating a Satellite.

Regards,
Patrick

In production environments where you treat hardware as disposable
commodity chunks it makes sense to demand the extra effort to make the
software components reproducible across repeated installs. In other
scenarios, it is just extra effort without much purpose unless someone
else has already done it. That is, building an RPM is always more work
than doing a source install and often imposes inconvenient restraints
like only permitting a single version to be running at once, and doesn't
give you any guarantee that you won't have to repeat that extra work
when the distribution changes. If you aren't planning to repeat that
install on other machines, where's the payback for the extra work and
constraints?

The rant at the start of this thread was about a migration
into C6, so of course, your predicate condition: 'you aren't
planning to repeat that install' does not apply

The disciplne and benefit of identifying and solving
dependencies in a packaged system, rather than splatting as
root over system libraries upon which other packages depend
[also, the same isue using CPAN shell to 'solve' a problem,
rather than packaging, as ZM has many such [1]] is obvious,
and needs no further advocacy, even for a single install; the
'straw man' about setting different private library paths
assumes that the person building such even comprehends that
there is an issue in play. Not likely

-- Russ herrold

[1] [herrold at centos-5 zoneminder]$ ls -1 | grep ^per | wc
37 37 1354

My condition in that case was that you couldn't count on the RPM to work
anyway once the distribution changes. So you'll likely be repeating
that extra effort anyway. And of course your next install may be on a
non-RPM based system, making any rpm-packaging effort moot.
Now you are talking about very different things. Installing your own
stuff in /usr/local (as most source installs would do unless you go out
of your way to subvert it) bypasses the issue of overwriting
disto-supplied files. You are right, of course, that outdated and
missing libraries in the base disto are a complex problem particularly
for languages/apps that have their own update/install concepts, no
matter how you try to solve it. But a simple 'build an rpm' isn't going
to fix those complications.

On 07/25/2011 07:26 PM, Les Mikesell wrote:
[snip]
Not sure what you mean with "once the distribution changes" but within a
major CentOS/RHEL version (e.g. 5 or 6) there is a stable ABI so an
update to the distro should not introduce issues. In my experience apps
deployed on RHEL 5.1 work equally on 5.7. If they work crappy, hire
better developers :)
So do people in the Windows world decide to *not* build msi packages
because their PHB might decide to replace all Windows with RHEL/CentOS?
I have never seen that (the not building msi packages that is). And
neither the reverse. I build versioned packages so (amongst other
things) I can create a controlled and predictable environment. Are you
going to install from source on thousands of servers or do you push
*one* tested rpm? I know what I will be doing. Anything else just does
not make sense to me.

Regards,
Patrick

The context for the issue was someone moving from 5.x to 6.x.
But wouldn't it be better if they actually did that instead of locking
themselves into a single vendors system?
How do you deal with java apps in cross platform environments?

Still normal procedures apply: port to the new platform and/or rebuild
for the new platform, test on the new platform, rinse & repeat, verify,
give seal of approval, package and finally deploy the RPM(s).
Really? No. I wish you good luck with the DLL hell caused by your
non-versioned, non-packaged, non-controllable, non-manageable source
install on a few thousand servers. You don't get freedom or
not-being-locked-in from not using best practices like versioned
packaging. The choice for a certain platform was made. Deal with it.
RHEL5 life cycle ends on 31/03/2017 so for now I don't.

Regards,
Patrick

<snip>
Another thing: most places I've worked, the large majority of projects
will be running in production, eventually. Having specialized packages
that you have to build, other than the project itself, means you'll
eventually have to do it for the entire time the project's in production,
and frequently means that the project itself is fragile, and perhaps
poorly implemented, and likely to break.

mark