We have a system with CentOS 5.2 that is up and running
and is supposed to remain up and running continuously.
As the subject says: I'd like to know whether it is safe to
run yum update to upgrade the system while it is running.
It's actually two machines running CentOS 5.2; one of
them is running PostgreSQL, version 8.3.x installed from
source; the other machine is running a piece of custom
software, written in C++ and using libpqxx 3.0 to connect
to the PG backend --- pqxx also installed from source on
the CentOS 5.2 machine.
I notice that among the available upgrades is the compiler
and related libraries (glibc, libgcc, libstdc++, etc.), so it
worries me a little. Maybe I should expect the newer
libraries to install without removing the previous ones,
so that the programs that are already compiled (linked)
to those older-version libraries remain running properly?
Anything that I may be missing?
Thanks for any info / advice / tips !
Carlos
--
In general, it's painless. The jump from RHEL 5 all the way up to RHEL
5.3 is suppsed to put you in the same place as if you'd been doing all
the incremental upgrades of the intervening period, when they came
out. This is why CentOS managers feel safe pointing the older 5.1
repository to the contents of 5.3. Your update settings in /etc/
yum.repos.d/CentOS0Base.repo point to "/5/" in the directory tree for
updates, not "/5.2/"
The rebundling simply gives you a new starting place that already
includes the last few hundred updates, and a kernel with six months or
so of patches and backports to run on more hardware.
> It's actually two machines running CentOS 5.2; one of
> them is running PostgreSQL, version 8.3.x installed from
> source; the other machine is running a piece of custom
> software, written in C++ and using libpqxx 3.0 to connect
> to the PG backend --- pqxx also installed from source on
> the CentOS 5.2 machine.
Back up your systems, first, especially with PostgreSQL, and I hope
your software installers haven't been over-writing the RPM material
in /usr/lib and /usr/bin.
> I notice that among the available upgrades is the compiler
> and related libraries (glibc, libgcc, libstdc++, etc.), so it
> worries me a little. Maybe I should expect the newer
> libraries to install without removing the previous ones,
> so that the programs that are already compiled (linked)
> to those older-version libraries remain running properly?
Sort of. Any programs that have the old files already linked in will
stay linked to them, even if they're deleted, because they're linked
to the *inodes* of the old files. The "rm" command merely removes the
connection between a file name and the contents of the file, the
contents are still there. This is how logrotate can move aside logs,
still get logs after they've been moved, and do a 'kill -HUP' on
processes like syslogd to have them start new files. And in general,
that's how RPM works.
> Anything that I may be missing?
Perl modules. If your programmers have been slapping things into /usr/
lib/perl5/ from CPAN, you may wind up with modules rewritten. Same
with using pear to install PHP modules.
For the big updates, I am glad I have a FiOS Internet connection. When I was
on dial-up, these could take several days.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 05:40:01 up 10 days, 16:29, 3 users, load average: 4.33, 4.17, 4.06
Hey Carlos,
Is there anything "broken" with the current setup?
Are there any security "holes" you are trying to patch?
If not then why "fix" something that is not broken?
Just a thought!
Ciao
I guess the operating principle is "just because we do
not know *how exactly* it is broken does not mean it
is not broken" :-)
What I mean is that there must be potential security
holes or potential bugs leading to data loss, etc. The
fact that there are updates available is an indication
of a certain likelihood --- I think the PostgreSQL guys
(the developers) put it more or less like this: "the risk
of upgrading is lower than the risk of running a non-
up-to-date system".
Yes, in terms of functionality I don't think there's anything
that needs fixing or improvement, but in terms of security,
well, I think the potential for trouble is always there, and
it is presumably *reduced* (as opposed to eliminated, of
course) by upgrading to the latest available packages.
Thanks --- and thanks Nico and Jean-David for your
messages!
Carlos
--
Chances are that something _is_ broken with the current setup. Recall that
Red Hat do not put enhancements into their releases, only security fixes and
bug fixes. All enhancements are put in the next release (RHEL 6 would be the
next release.)
>
> Are there any security "holes" you are trying to patch?
You may not know what the security holes are in the release you are running
now. But you can be sure they are there or Red Hat would not be issuing fixes.
>
> If not then why "fix" something that is not broken?
>
> Just a thought!
>
> Ciao
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:50:01 up 10 days, 20:39, 3 users, load average: 4.46, 4.42, 4.32
> We have a system with CentOS 5.2 that is up and running
> and is supposed to remain up and running continuously.
>
> As the subject says: I'd like to know whether it is safe to
> run yum update to upgrade the system while it is running.
I actually tried this on several non-critical systems to see what would
happen after doing the update without rebooting. Everything went smoothly,
and there was no fallout. There is a kernel update, which of course won't
take effect until a reboot (but I did that too, several days later, with
no ill effects). From the release notes, you may need to upgrade glibc
first; the procedure that I actually used was:
yum clean all
yum update glibc\*
yum update yum\* rpm\* python\*
yum clean all
yum update kernel\*
yum update
Steve