Date: Sun, 9 Apr 2006 01:19:19 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: thierry@freebsd.org, fbsdq <freebsd-questions@freebsd.org> Subject: RE: BEWARE upgrading Horde System Message-ID: <LOBBIFDAGNMAMLGJJCKNEEJIFDAA.tedm@toybox.placo.com> In-Reply-To: <20060409044505.N1096@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I know what your getting at but I would suggest that doing an
in-place upgrade of a production server is immensely stupid -
no offense intended.
What we do with our production servers is once they are built
they go into a golden can and are not touched.
In the event a security notice comes out that is not very simple
to patch, or when the software on the server is getting a bit long
in the tooth, we build a complete new server, new software, new
applications, then when we are positive it's solid, in the dead of
night we swap IP addresses between new and old servers and quickly
move the user data from the old to the new server.
This of course requires that we fully understand what all areas of
the server are used for storing transient user-data, this requires
a through understanding of how the app works, as well as careful
note-taking when the server is built. We have to do this anyway
in order to have a good backup/restore strategy.
I have never understood the demand for being able to do an inplace
upgrade of applications or of the operating system, and I've seen
enormous trouble with servers that people do this with, under Windows
as well as FreeBSD.
Furthermore, by the time the software on the server is old, the hardware
is ready to be retired in favor of shiny new hardware that is a lot
faster. This is also very true of Windows servers too.
This gets back to what I was saying with professional-vs-amateur
approach. A professional approach to a server is to plan for it
to live a certain life then you scrap it, or at the least nuke and
repave it for something less demanding. The car-rental companies
have been doing this with cars for years, and all the used car buyers
can never understand why a car rental companies sell perfectly
good cars with a lot of years of life left in them.
The amateur approach is to build the server then wring every last
day of life out of it. Patch and patch it over and over and over
and upgrade it over and over and over, until it just won't work anymore.
Hell, people were complaining that FreeBSD 6.0 wouldn't run on a
80386!!!! That's a total amateur approach.
Horde is built for a professional approach not an amateur approach,
but as a nod to the amateurs it does the .dist thing, but that is
useless for the professional adminstrator. And it's kind of silly
because only someone who is really willing to get in and get their
fingers dirty, like a professional, should be running Horde. As I
said there's plenty of easier apps out for the "install binary rpm
and cross your fingers and hope it works" crowd.
Note that I'm not saying there's never a legitimate reason to do
an inplace upgrade, just that in what _I_ and I think most professional
adminstrators think is proper operating procedure, what your
talking about as a problem would almost never happen.
Ted
>-----Original Message-----
>From: Marc G. Fournier [mailto:scrappy@hub.org]
>Sent: Sunday, April 09, 2006 1:00 AM
>To: Ted Mittelstaedt
>Cc: dick hoogendijk; fbsdq; thierry@freebsd.org
>Subject: RE: BEWARE upgrading Horde System
>
>
>
>As much as I agree with your sentiments, the issue that is at
>question is
>the replacement of existing config files with default ones ...
>at least in
>my instance, had those config files *not* been replaced, 'make install'
>(to upgrade an existing, configured installation), would have
>left me with
>a system that would have still worked as originally configured ...
>
>Horde is/was designed to make upgrading it fairly simple, as it
>*explicitly* does not overwrite any config files, because it doesn't
>install any ... it installs .dist files, and the admin then has to move
>those into place ...
>
>All the port needs to do beyond what it is doing ... and, quite
>frankly,
>it requires only one change to do so ... is to not do the:
>
>mv <config file> <config file>.previous
>
>The weird thing is that looking at the Makefile, I can't see where its
>doing the move to previous in the first place .. and, in fact, the
>following code should prevent it overwriting my existing config file:
>
>.for FILE in ${CONFFILE}
> @if [ ! -f ${CONFDIR}/${FILE} ]; then \
> ${CP} ${CONFDIR}/${FILE}.dist ${CONFDIR}/${FILE} ; \
> fi
>.endfor
>
>Wow, okay ... Makefile says "don't overwrite existing config
>file", while
>files/pkg-install.in is the one that forces the issue:
>
>Personally, the following patch would make doing an install safe:
>
>diff -c files/pkg-install.in.orig files/pkg-install.in
>*** files/pkg-install.in.orig Sun Apr 9 07:56:56 2006
>--- files/pkg-install.in Sun Apr 9 07:57:24 2006
>***************
>*** 101,117 ****
> chown -R $hordeusr:$hordegrp $hordedir || exit 1
> fi
>
>- if [ -z "${PACKAGE_BUILDING}" ]; then
>- # Don't reset the config to default (PR ports/88621)
>-
>- for cf in `ls %%HORDEDIR%%/config/*php`; do
>- if [ -f $cf.previous ]; then
>- mv $cf $cf.new
>- echo "---> $cf not installed ***"
>- echo "---> please copy from
>$cf.previous ***"
>- echo "---> or from $cf.new
> ***"
>- fi
>- done
>- fi
> ;;
> esac
>--- 101,105 ----
>
>If its an initial install, the Makefile copies in the initial
>config files
>as it is ... if its an upgrade, Makefile is smart enough to
>note overwrite
>existing files ... pkg-install.in shouldn't either ...
>
>That is the *only* complaint that I have with the Horde ports ...
>
>
>On Sat, 8 Apr 2006, Ted Mittelstaedt wrote:
>
>>
>> Horde is too complex and too configurable a program to
>> easily fit in the FreeBSD Ports tree. All you can do is
>> what I think has been done - which is set the port up to
>> do 90% of the heavy lifting, and depend on the person
>> doing the installation to finish off the configuration.
>> I think the horde port met this goal just fine.
>>
>> It may not be politically correct to say this, but being
>> able to install and get Horde and IMP and the modules running
>> either with or without the assistance of the ports directories,
>> is the mark of a real system administrator. It is, I think,
>> a given that this port can never meet what I feel is an
>> unrealistic goal of being able to do a "make install", go away
>> and come back and have full-blown Horde/IMP server up and
>> running, ready to use. There's plenty of simpler programs
>> that the amateurs can do that with and have fine results.
>>
>> I would point out that even the FreeBSD Release process doesn't
>> meet this goal. For all the vaunted hype about being able to
>> type "make release" and build the entire installation CD images,
>> it is really a bunch of bullshit. "make release" is just the
>> last command in a very long process of getting the environment
>> setup, and figuring out what options your going to set and
>> what they do.
>>
>> Ted
>>
>>> -----Original Message-----
>>> From: owner-freebsd-questions@freebsd.org
>>> [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of
>dick hoogendijk
>>> Sent: Saturday, April 08, 2006 1:19 AM
>>> To: fbsdq
>>> Subject: Re: BEWARE upgrading Horde System
>>>
>>>
>>> On Sat, 8 Apr 2006 09:53:05 +0200
>>> Thierry Thomas <thierry@FreeBSD.org> wrote:
>>>
>>>> Le Ven 7 avr 06 à 16:18:31 +0200, Jeremy Chadwick
>>>> <freebsd@jdc.parodius.com> écrivait :
>>>>> On Fri, Apr 07, 2006 at 10:40:01AM +0100, Spadge wrote:
>>>>>> Why not overwrite the .dist and leave the .conf as it was? OK, so
>>>>>> it may
>>>>>
>>>>> Many ports work this way (re: keeping the .conf). The port
>>>>> maintainer should address this, as many others have done.
>>>>
>>>> OK, I must admit that I don't know how to handle properly
>>>> installation / configuration / deinstallation /
>reinstallation of the
>>>> Horde's ports.
>>>>
>>>> Since the very first version of these ports, I have tried several
>>>> solutions and accepted many patches, but I have never found a
>>>> widespread agreement. Maintainership is now available.
>>>
>>> It won't be me (sadly enough I lack the experience and/or knowledge)
>>>
>>> I *DO* hope however that the horde port will be supported in
>the future.
>>> Personally I *never* had any trouble upgrading horde. I *DID* have to
>>> read the documentation though! It is always needed with horde. But,
>>> hey, given good docs, that's not too bad, is it?
>>> Even the latest changes (from 3.0x to 3.1.x) went very very
>smoothly. I
>>> just followed the upgrade path (/usr/ports/UPGRADING plus
>the upgrading
>>> info from the horde package itself.
>>> Putting back *.previous files also is not that bad. I can
>live with it.
>>> So, I'd like to thank you for all the good work and hope you'd
>>> reconsider maintainership.
>>>
>>> --
>>> dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE
>>> ++ Running FreeBSD 6.1 ++ The Power to Serve
>>> _______________________________________________
>>> freebsd-questions@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to
>>> "freebsd-questions-unsubscribe@freebsd.org"
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.385 / Virus Database: 268.4.0/304 - Release
>Date: 4/7/2006
>>>
>>
>> _______________________________________________
>> freebsd-questions@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to
>"freebsd-questions-unsubscribe@freebsd.org"
>>
>>
>
>----
>Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ:
7615664
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/304 - Release Date: 4/7/2006
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNEEJIFDAA.tedm>