On Tue, 2006-03-07 at 10:52, Andy Green wrote:
> Last week I was working on an RPM for a customer that configures their
> servers in one step. It has a bunch of dependent RPMs listed, like
> postfix, httpd, etc... if you install it with
>
> yum -y localinstall blah.rpm
>
> then yum brings in all those dependent packages the server needs for its
> role in one hit from the default-configured repos. But even so quite a
> large (unfortunately, proprietary) script was needed to run around
> configuring mail, aliases, mysql, etc, etc.
If you know how the configs should be done, they can be in separate
RPMs that require the base packages.
> Yum has a concept of a group, eg,
>
> yum grouplist
>
> but again I think the real way to attack these "box roles" is with
> packages, since RPM has everything that is needed.
OK, but you need to approach the problem knowing that one
version for each role isn't going to be right and you don't
want the end user to have to know the details of why or you
are back to dealing with individual packages.
> An example I can
> think of is a metapackage for mail with postfix+postgrey, just an RPM
> with the dependencies and a config script that runs post install, with
> all the good spamkilling options sed-ed into postfix config. So that
> would be a very thin package you might call postfix-spamhardened or
> whatever, but still it would install in one hit, force all its deps in
> and make a specific configuration action. RPM suits it well because it
> is happy to have complex scripts triggered by install and uninstall.
That should all be under the covers and selectable as
"Andy's mail server" while "Les's mail server" might install
sendmail and mimedefang instead. The user should be able
to select based on overall functionality and the reputation
of the person selecting the packages.
--
Les Mikesell
lesmikesell@xxxxxxxxx
