Re: Patch Installation

[Mailing Lists <lists@coredump.com.ar>]

>> by myself, that sucks realy.... even I do it because the security 
>> but I'm sometimes just angry that there's no solution wich is part
>>  of OpenBSD because that wastes just my time...
>> 
>> And I read somewhere OpenBSD wanna be a platform for developers 
>> too. I think also developers wanna develop anything and not 
>> patching a system (yes I include also the packages when I say 
>> "patching") or the software about 93 minutes.
> 

generic solutions are indeed not included in OpenBSD but
I don't think it is that hard to create yours.

get a fast machine and install the release you are working with
to do your very own builds, write a script to do the boring and
repetitive parts, vg. man release, cut & paste and test until
it works w/o manual intervention.

I cvs up and build the whole tree (except X) everytime there's
anything new on errata.html as a way to know the tree is in a
sane state and to include also all -stable changes. I don't
mind to manually select the appropiate files to compile and
install once every, say, 8 or 9 years if a remote root
vulnerability appears. other remote problems may or may not
grab my attention.

also the build server can be used to build the ports and allow
http OS and/or ports installs to the local network with minimal
changes:

for the ports:

# ln -sf /usr/ports/packages/`uname -m`/all /var/www/htdocs/all
# apachectl stop ; httpd -u

and on clients: pkg_add http://build-server/all/package-x.y.z.tgz

exporting the base OS is equally simple, just link your $RELEASEDIR
somewhere in the documentroot and manually enter it at install time.

once your builds server works decide upon you need (or preffer)
a push or pull patching method for the clients.

1) push

I couldn't find a way to make rdist work from other dir than / to a
remote / so I droped it.

while it takes some time to build releases, once they are created
you can simply untar them with -p on some directory in the build
server and, basically, run:

BASE="/bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata"
BASE="$BASE /usr/share"

for s in $servers
do
   for d in $BASE
   do
      rsync --delete -avz ./new-release/$d/ root@$s:/$d/
   done
done

ssh root@server "echo -n 'saving remote /bsd as /obsd ';/bin/cp -f /bsd
/obsd; echo ok"
rsync -avz ./path-to-kernel-builds/bsd root@server:/bsd

add -n to rsync first to check how it will behave, add --delete-after
to have some extra safety and add --progress to make it funnier.

I had to include the following opts to rsync be nice to my
machines:

--exclude=whatis.db --exclude=libphp4.so --exclude=Config.pm

you may need others, do extensive use of -n when running with --delete.

check -p and -n options with pkg_add and install to a local dir
and rsync that dir to root@server:/usr/local/ (do not include --delete
in this rsync or other packages will be removed, ie everything that
isn't part of the package you are working on).

let ssh keys enter to make it comfortable (and even cronable) and spend
some more time writing a script that lets you know when errata.html had
changed.

you can use ssh-agent to have your keys password protected in order to
not to blindly allow passwordless root logins from the build server.

2) pull

just put releases somewere in the documentroot of the build server,
start apache and let your servers:

for p in base man ...
do
  lynx -source http://build-server/releases/${p}XX.tgz | tar -C / -zxpf -
done

or tar -C ./local-new/ and then

for d in bin sbin usr/bin usr/sbin ...
do
  rsync -avz ./local-new/$d/ /$d/
done

Untar packages somewhere in the build server and tar'em again without
the +* files (maybe there's a tar option to skip that), download and
untar them on the fly with -C /usr/local/ and -p; or, once again,
download to a local dir and rsync from it. or download all of
them at once and include --delete to remove extrange things, this
in case you do not tent to manually put things on /usr/local/ or
run packages that do it.

2a) setup an rsync mirror on the build server and let the clients
rsync -avz /bin /sbin and others to it. I never had done this.

a script that checks pkg-stable.html and notifies you also helps.

lastly reboot every server to let changed kernels, daemons or apps
start working. you need to reboot after such a change anyway or time
will pass, other changes will happend and if something breaks you
may not know for sure what and/or why it was.

this method is limited to one release for build server but, in
my case, the convenience of having all and every machine running
the same release (comfortable binary patching at least)
largelly justifies the pain of the first upgrade on networks
running different releases.

base build and update scripts suffered only a 3.2 to 3.4 upgrade
(ie a new build server) but I am not sure they needed any changes.
I haven't finished a packages updater script as until now the
machines I worked on did run very few apps. I can send you my
build and push-update scripts in case you want to see them, those
are the only two I'm currently using.

I jump to the lastest -stable every two releases, according with
the two-releases support policy of the team. that way I install a
new build server every year and N machines that are really simply
to maintain updated. The quantity of N in your situation may or may
not justify spending time on this.


Juan