[CentOS] Thanks, good bye, and an observation from a newbie.
lowen at pari.edu
Mon Oct 17 17:40:37 UTC 2005
On Monday 17 October 2005 12:49, Les Mikesell wrote:
> On Mon, 2005-10-17 at 09:43, Lamar Owen wrote:
> > ... showing their ignorance to the fact that the initscript can get
> > blown away in an RPM update at whim, but that the config file wasn't ever
> > overwritten...
> Isn't it always up to the whim of the RPM builder what gets blown
> away and what is preserved? Did you just mean that the config file
> hasn't been changed recently?
No, sorry, I didn't fully explain the postgresql.conf situation. The
postgresql.conf is generated from a template during initdb, and is thus
created along with your database when you initdb. It is not managed directly
by the spec's %files list. Likewise with pg_hba.conf, and any other
configuration found in $PGDATA (/var/lib/pgsql/data by default).
Thus, unless the packager (at the time me) does something drastic (like, rm
-f /var/lig/pgsql/data/postgresql.conf ; cp
some-new-template-for-conf /var/lib/pgsql/data/postgresql.conf or adds
specific files to %files for the -server subpackage) then the
$PGDATA/postgresql.conf is pretty much guaranteed safe from overwrite by the
RPM installation. There are whims, and then there are stupid tricks.
> > No, Linux isn't for newbies, and ninety percent of the time it's not the
> > distribution's fault.
> What is it that could be explained that couldn't be scripted?
More than you might realize given the constraints of the RPM system.
Otherwise, very little, but you do have to write and debug the scripts. And
the script interpreter, regardless of language, takes things far more
literally than even the rankest newbie following an explanation.
But to directly answer the question you posed, in the context of the
PostgreSQL upgrade procedure, there are external limitations that cannot be
scripted for various reasons, most of which are outside the control of the
scripts that run during %pre, %post, %preun, and %postun. The biggest
problem is that PostgreSQL databases contain a vast amount of
version-specific metadata, specifically they can contain compiled C functions
that are version-dependent, and they contain the default type handler
functions for the whole database (PostgreSQL is extraordinarily customizable
and extensible, and in fact the default types, operators, and functions are
implemented just exactly as if they were user customizations, inside the
database itself. This is what initdb does, in fact: it loads a default set
of customizations using a standalone backend and template files).
The second biggest problem is that these scripts (%pre and kin) cannot tell if
they are running in an anaconda chroot or from yum or from a manual rpm
commandline. If they are running in an anaconda chroot, 'Danger Will
Robinson!' : they had better not try to start a backend process, because the
anaconda chroot with busybox is NOT a suitable place to start a backend (to
dump the database in preparation for upgrade, something that would have to be
done in a %pre, and of course you run into serious disk space calculation
Third, RPM scriplets are forbidden (especially inside anaconda, or during a
yum update or similar) from sending to stdout or gathering data from stdin,
preventing the scriptlet from asking questions and receiving answers. And
the user may never see the output your carefully thought out initscript wrote
I know what the short-term solution is, but have not had the time or the need
to implement it. And that is the capability of having multiple versions of
the backend available at any given time. Debian's maintainers are working on
a system along those lines, but they have run into snags too.
It is far easier to explain "dump, upgrade, initdb, restore" than to write a
script to do some really hairy data manipulation that can:
1.) Understand the binary data format;
2.) Has knowledge of all possible old versions with binary mappings from old
version default type handlers and new version handlers, with the appropriate
OID's necessary for mapping;
3.) Knows how to take an object code function and translate to the new version
object code function for all possible versions, keeping the same OID;
4.) Can do all of the above without overflowing disk, or at least handles disk
space exhausted in a sane manner;
5.) Oh, and has no possibility of database corruption.
That's just the overview.
Now, explain to a newbie why they can't just stick the disk in and upgrade;
you'll likely get a blank stare. This is, IMO, one reason why Red Hat no
longer officially supports upgrades, and only allows 'upgradeany' at your own
Or to put it very bluntly: being newbie-friendly is hard work for a developer,
but even harder work for support staff or mailing list participants. There
are no easy answers for ease of use. Although my initial impressions of
Ubuntu are pretty positive.
Personally, I have nearly a decade of experience with Red Hat-like systems;
too much intellectual equity to jump ship. One might say I'm somewhat vested
in RPM-based setups at this point.
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
More information about the CentOS