OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: RPM Packaging of the latest Snapshot
From: Wietse Venema (wietseporcupine.org)
Date: Sun Jun 04 2000 - 18:16:27 CDT


Bennett Todd:
> As the first step of working with the new content filtering
> features, I wanted (naturally) to rpm the latest postfix.
>
> I may turn up some more stuff that needs tweaking in further
> testing, but I think I've got as simple and straightforward a
> packaging of the latest snapshot as I can manage. It's not really as
> simple as I'd ideally like. A few changes would account for most of
> the ick.
>
> It would be _way_ cleaner if we could avoid the here doc feeding the
> interactive "INSTALL.sh" script; if that script could accept cmdline
> args, or envars, or a config file with var=value defines, or
> whatever to override a couple of defaults while still accepting the
> others, that would definitely be nicer.

You are welcome to provide a target system specific version. I
won't stop you.

However, consider my position. I provide a script that has to run
on most every odd-ball system. Since it is potentially going to
blow away system files, I am going to require confirmation from
the luser for every step.

> I had to dike out the calls to chown and chgrp in INSTALL.sh so the
> resulting RPM would build as non-root, but that was only one line.

I consider this a minor problem - you can build the tree as root
and that is good enough.

> Then I had to do some manual frobbing to get spawn built, to make
> and install the man page for it, and to get a symlink to sendmail
> into /usr/lib/sendmail. But there's still not too much excess cruft
> in this one; it's as clean as I can make it.

Auch, you're going to ship the immature variant of content filtering
as an RPM to the unwashed and unsuspecting public? Is that wise?

> There are still some rough spots; if a /usr/lib/sendmail exists when
> the rpm is built, the INSTALL.sh will decide to install sendmail
> there rather than into /usr/sbin, and so the symlink will fail. And
> I used the simplest useradd invocation to ensure that a postfix
> userid is available in %pre, and made no effort to clean up in
> %postun.

Nope. INSTALL.sh will *SUGGEST* to install in /usr/lib/sendmail
but give the luser to opportunity to correct. This is why the
script insists on manual confirmation.

> But if you get this note, this packaging is basically sound.
>
> Unlike the earlier packaging I worked on, which is ... well, you
> could call it "evolved", if you wanted to be kind:-) ... this one
> is as close as I can manage to a direct simple straight install,
> and mostly avoids non-default options. I did include LDAP and PCRE,
> since they're so easy to do.
>
> As always, when doing any non-trivial upgrade, save the non-default
> options you've configured with "postconf -n >save-file", carefully
> upgrade the software (I did an "rpm -e --nodeps postfix", then I
> went "rm -rf /etc/postfix /var/spool/postfix", and finished by
> making sure the "postfix" user and group were removed); then edit
> those customizations you actually need back into main.cf, and try
> starting; make sure to check maillog, and test carefully.

You can actually use "postconf -n >save-file" output to patch
the new main.cf file.

I am still using main.cf files from the pre-vmailer days.

        Wietse