|
|
Notes for remote upgrades, in place, of OpenBSD from distribution Last updated
8 February 2008
The following notes use as example of remotely upgrading to
current versions from earlier versions on an i386 architecture. We started
these notes before comprehensive upgrade notes became part of the standard
OpenBSD documentation. You should review the official
"Upgrade Guide" which is hyperlinked on the left of the
OpenBSD FAQ Index which
now includes notes for "Upgrading without install media" which can be
referenced for remote upgrading. We considered discontinuing this
information, but for now we will keep in current for those who use and to
have notes not dependent on the main site being available.
This information is distributed in the hope that it will be
useful, with the understanding that the information presented is from various
sources and application experiences, but WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The experience of upgrading one or two revisions in place is
most of the time successful. An example of a good gotcha that caused an
remote upgrade to fail years back was that one of the remote machines had a network card that was recognized as a "de0" for version
3.0 and after reboot the new kernel identified it as "dc0" ... so after
the
reboot it was no longer available remote. We had to drive to the remote
location and use the console. After copying /etc/hostname.de0 to /etc/hostname.dc0 it still would not
work. We may have found the fix by fooling around with ifconfig and how it did
the media, but uptime was more important that being Sherlock Holmes so we
replaced the network card with a different model that happened to recognize as
dc0 and it worked. Lesson learned: remote upgrades are a risk.
- Use sudo where appropriate
- Read and familiarize yourself with the OpenBSD FAQ
http://www.openbsd.org/faq/index.html
- If feasible when doing remote administration it is really helpful to have
the test machine that has the exact same hardware and setup to practice
on. As mentioned above we got stung by the fact that the newer version
tried to use a newer driver for the network card and failed.
- If you have made any changes to the usr land, for example if you need a
custom kernel, recompiled sendmail to support smtp authentication, you enabled suexec with
"chmod u+s /usr/sbin/suexec" or the like better test the steps that may cause problems
and document on a local machine before trying remote!
- Recommend you 'man release' This man page discusses in
some detail several steps involved with upgrading a release that may or may
not apply.
- Recommend you review related documentation created by the author of the
OpenBSD Upgrade FAQ. Other Links:
http://www.openbsd.org/faq/upgrade-minifaq.html
http://pintday.org/hack/
http://pintday.org/hack/docs/remote-upgrade-howto.shtml
And another remote upgrade faq: http://a.area51.dk/openbsd/upgrade
- Recommend you use the latest version on CDROM,
rather than a snapshot. We recommend upgrading to stable, but don't recommend upgrading
to snapshot nor current unless you like to be on the
edge and you are good at researching answers for yourself. If you like being on the edge, don't
please do not ask questions of the mail lists till you have exhausted google.com, the faqs etc.
- Be prepared and have available the files you will need for target
distribution; source
tree (/usr/src), Mergemaster package, and the generic /bsd or
your custom kernel made on the test box ahead of time. It is
helpful to have them on a the hard drive of the computer before you start
and on cdrom in case the remote becomes an non-remote upgrade...
- Expect the typical issues to give you headaches like permissions and paths for wrappers changing, like smrsh for sendmail,
if you modified apachectl for the -u flag will have to do it again, for apache suexec will have to
enabled with "chmod u+s /usr/sbin/suexec", other headaches, and it helps to have
access to www.google.com/bsd,
www.undeadly.org and
other openbsd literature like searching
the past mail lists to hunt fixes with.
- Which version, rather update of src tree to use? It seems logical to
use the exact same src tree that matches the distribution tar files that are
used, that way mergemaster is proper configuration files from /usr/src/etc.
To do this would mean using the src.tar.gz and srssys.tar.gz not using
anoncvs to get the stable version till after upgrade to target version
number. However we have jumped this step for machines not excessively
remote and used anoncvs and updated /usr/src to stable prior to doing the
upgrade rather than using the exact matching src to the distribution files
and have not had significant issues arise.
- Familiarize yourself with the port mergemaster and it's man page.
- Do not forget that after using the distribution files, mergemaster and
rebooting you still need to update the src, rebuild or use new stable kernel
,
redo usr land (make obj && make build), and redo mergmaster just in
case configuration files changed significantly on the stable since the
distribution files were created.
- We are not sure that it is a good idea but on the drive back on night from
a remote location to make fixed from the console we
thought that maybe if the machine has only one network card what might
be useful is to have one /etc/hostname.anycard file and link all variations
of /etc/hostname.xxx to it. If anyone does this, send us know your
experience and maybe script or tar of the symbolic link files.
- Your procedure for handling migration of ports packages
should also be tested before you try it on a 'must be up' machine or a
remote machine.
- And oh by the way, this documentation does not address the issue of ports
packages nor the X4. You should consider removing all unnecessary
installed packages and perhaps all packages then reinstall necessary
packages after upgrade.
Attempt to anticipate probable problems that may
arise because of things like resource limitations and hardware compatibility.
Try to anticipate things that may cause problems and ways to
work around them. If appropriate we would like to add your work around notes
to these tips.
You may want to check hardware compatibility. Over all
we would expect hardware that works for past versions to continue to be
supported for new versions, but even so you may experience issues like the
driver designation changed.
Is you hard drive big enough? You may need to
clean all the cruft out you can find and verify you partition sizes are
adequate. Here is a link to some notes by a contributor for remote computers with small hard drives
to minimize space normally taken up by unpacking src.tar.gz and by mergemaster:
http://www.cocoavillagepublishing.com/development/tools/
openbsd/tips/upgrading/notes_minimize_space_on_etcvar.html
Open session(s) for remote administration.
You may want to create more than one ssh terminal session just
in case on a computer with battery backup and a dependable remote
connection. The following commands are examples run from the remote
computer.
Backup anything important just to be safe.
We recommend you consider doing a comprehensive backup, however if you want to just copy the
directories most likely to be edited by mergemaster then try backing up /etc, /var,
/usr/local if you have stuff their and perhaps /usr/share
(some sendmail stuff may reside there).
An example of backing up the folders with configuration
information from the remote server, for the paranoid:
### The following four examples use 'pax' with cpio format so you can backup
long path and file names.
### If you have SAMBA in
use, you may find really long file and path names created
by windows
### software and tar may not be able to handle them.
### You may also have to set up ssh keys
so that using ssh to run pax on the remote server
### does not require passphrases during the session, which is a security problem
that
### may be temporarily acceptable, else the pipe not work because of the
authentication request.
### no compression on remote, compress afterwards on this computer.
ssh root@remotecomputer "pax -w -x cpio -b 5120 /etc /root /var /home /usr/local /usr/share" | gzip >
/storage/remotecomputer.`date +%Y%m%d%H%M`.pax.gz
### no compression on remote, compress afterwards on this computer.
### with -s option to remove root /
ssh root@remotecomputer "pax -w -x cpio -b 5120 -s ',^//*,,' /root /var /home /usr/local /usr/share" | gzip >
/storage/remotecomputer.`date +%Y%m%d%H%M`.pax.gz
### compression on remote with output redirected to be saved on this computer
ssh root@remotecomputer "pax -wz -x cpio -b 5120 /etc /root /var /home /usr/local /usr/share" >
/storage/remotecomputer.`date +%Y%m%d%H%M`.pax.gz
### compression on remote with output redirected to be saved on this
computer,
### with -s option to remove leading /
ssh root@remotecomputer "pax -wz -x cpio -b 5120 -s ',^//*,,' /etc /root /var /home /usr/local /usr/share" >
/storage/remotecomputer.`date +%Y%m%d%H%M`.pax.gz
Prepare source on remote computer for upgrade.
To be safe it may be best to have the necessary distribution files, mergemaster package and kernel
available on the remote machine.. You could mount a cdrom on the remote
machine prior ( if you do put a bootable cdrom in the server, make sure the
bios does not boot from it on restarts) or copy them from the
cdrom or across the
network to a partitions with enough space to spare
(we will use /usr for our example).
### Example using 4.0
mkdir -p /usr/4.0/`arch -s`
### /usr/4.0/`arch -s` is the same as /usr/4.0/i386 for most all
computers
### with intel compatible processors.
mkdir /usr/4.0/packages
### mount the distribution cdrom of the local computer and scp to the remote
machine
### if you have it, or modify procedure appropriately.
ssh root@localcomputer mount -t cd9660 -r /dev/cd0a /mnt/cdrom
scp root@localcomputer:/mnt/cdrom/4.0/`arch -s`/* /usr/4.0/i386/
scp root@localcomputer:/mnt/cdrom/4.0/src.tar.gz /usr/4.0/
scp root@localcomputer:/mnt/cdrom/4.0/srcsys.tar.gz /usr/4.0/
scp root@localcomputer:/mnt/cdrom/4.0/ports.tgz /usr/4.0/
### or if you must be a gorilla, ftp
like below
### but try using a mirror to not load primary openbsd ftp server.
# ftp -n ftp://ftp.openbsd.org/pub/OpenBSD/4.0/`arch -s`/*
### just to be safe because we don't want to untar etc**.tgz
### we will rename it for now, mergemaster will use src so it doesn't need
this file.
mv /usr/4.0/i386/etc40.tgz /usr/4.0/i386/etc40.donotusenow
Prepare ports on remote computer for upgrade.
You may also want to get all the ports packages you will need to replace
available. Maybe checkout /usr/ports or have the precompiled binaries
copies somewhere locally.
Mergemaster
You'll need mergemaster unless you are doing it by hand and it is a port
package, if the machine your upgrading from is not to old you may can use
that mergemaster but it seems logical to use a mergemaster version that is
released with the distribution. Mergemaster is a Bourne shell script which is
designed to aid you in up- dating the various configuration and other files
associated with OpenBSD. It appears to have it's beginnings with FreeBSD
but no homepage on the Internet. The man page and a test run on an
unimportant machine should suffice for documentation and how-to for someone
familiar with Unix system administration.
### example for version 4.3 w/ i386
### if you do not already have the latest version of
mergemaster installed:
cd /usr/4.3/i386/packages/
ftp ftp://ftp.openbsd.org/pub/OpenBSD/4.3/packages/i386/mergemaster-*.tgz
pkg_add /usr/4.0/packages/mergemaster-*.tgz
You may want to also get other packages you think
you may need. You may want to use pkg_info to see what you are already
using and try to have the equivalent packages and dependent packages already on
hand for use after upgrading the operating system.
# scp root@localcomputer:/mnt/cdrom/4.3/packages/* /usr/4.3/packages/
Stop, kill, unnecessary processes that could get confused by usr land and
configuration files changing. Also un mount any unnecessary file systems.
Sendmail and named will most like be upset by in place upgrades.
Best to stop
any processes you don't need running.
### look at processes and identify some you can kill like sendmail and named
ps -ax | more
### killing sendmail and named using info they stored on file
kill `head -1 /var/run/sendmail.pid`
kill `head -1 /var/named/named.pid`
### stop apache
/usr/sbin/apachectl stop
### df -k
### umount any unnecessary file systems in case of crash.
### others?
Prepare the source tree to be used later
You should prepare the source tree under /usr/src.
You can extract the src
from the installation cdrom that has the src in two different files, src.tar.gz
and srcsys.tar.gz.
### get the old version stuff out of src if untaring new src
rm -rf /usr/src/*
cd /usr/src
### IF you want stable or say a certain date of current you could check
out
src from an anoncvs server.
### For example if you are crazy enough to use a current snapshot, know the
target date and
### need the source for that snapshot date you may could do something like
this:
### cvs checkout -D "2003-07-22 12:00"
src
###
### Getting the new src from
the installation cdrom by extracting src.tar.gz & srcsys.tar.gz
tar xvzpf /usr/4.3/src.tar.gz
tar xvzpf /usr/4.3/srcsys.tar.gz
You may or may not want to do these steps before replacing
kernel and untarring the new binaries. We have done it before and
after with out major issues arising, yet.
Upgrading from previous versions frequently requires additional users, groups,
permission changes, and
ownership changes that can cause mergemaster to fail or mysterious problems. Sometimes mergemaster can do it
automagically, but not always. This requires a human to figure out what is
going on and lean heavily on the information in the OpenBSD FAQs.
The following indented notes are are in series so if you are upgrading by a
jump of more than one release the notes may be used consecutively. If you
are jumping more than one or two releases for your remote upgrade it would be
safer to get another computer and do a fresh install then migrate the data
accordingly, but that is not always feasible :(. The following notes are a
guide and are not meant to be comprehensive. The notes may have missed something
so you should read the OpenBSD upgrade-minfaq
carefully in addition to using them.
The original 'MINI-FAQ: Upgrading OpenBSD'
by Kjell Wooding, was heavily referenced to
create the following notes, however it has been replaced with official
documentation as of version 3.5 as noted below. For following current see
http://www.openbsd.org/faq/current.html
Notes for changes from release 2.9 to 3.0 that
may still need doing after extracting binaries and before mergemaster
|
###################
### from 2.9. to 3.0 ###
###################
###
### a new user and group named proxy were added to the system.
### To support this addition,
### add the following user entry using vipw(8):
# proxy:*:71:71::0:0:Proxy
Services:/nonexistent:/sbin/nologin
### Also add the proxy group to /etc/group:
# proxy:*:71:
### Second, as part of the Sendmail 8.12 upgrade, sendmail no longer runs setuid root.
### Both a new user and a new group, named smmsp, have been added to the system.
### Add a line like the following to your /etc/group:
### smmsp:*:25:
### Then, run vipw(8) and add the following line for the smmsp user:
# smmsp:*:25:25::0:0:Sendmail Message Submission
Program:/nonexistent:/sbin/nologin
### Make sure this line appears before any yp(8) settings line.
### Finally, a new user and group were added for Solar Designer's popa3d server,
### now part of the core system. Add the following to /etc/group:
# popa3d:*:26:
### And using vipw(8), add
# popa3d:*:26:26::0:0:POP3 server:/var/empty:/sbin/nologin
|
Notes for changes from release 3.0 to 3.1 that
may still need doing after extracting binaries and before mergemaster
|
###################
### from 3.0 to 3.1 ###
###################
### ssh config files moved to /etc/ssh/
mkdir /etc/ssh
### Move your /etc/ssh*_* files
cd /etc
mv ssh*_* ssh/
#### If you don't plan on replacing
#### the rc files when doing mergemaster
#### you may need to make sure the paths
#### is correct like: HostKey /etc/ssh/ssh_host_key
|
Notes for changes from release 3.1 to 3.2 that
may still need doing after extracting binaries and before mergemaster
|
### Several new users/groups have been added.
### Add the following user entries using
vipw(8):
sshd:*:27:27::0:0:sshd privsep:/var/empty:/sbin/nologin
_portmap:*:28:28::0:0:portmap:/var/empty:/sbin/nologin
_identd:*:29:29::0:0:identd:/var/empty:/sbin/nologin
_rstatd:*:30:30::0:0:rpc.rstatd:/var/empty:/sbin/nologin
_rusersd:*:32:32::0:0:rpc.rusersd:/var/empty:/sbin/nologin
_fingerd:*:33:33::0:0:fingerd:/var/empty:/sbin/nologin
_x11:*:35:35::0:0:X server:/var/empty:/sbin/nologin
### Add the following to /etc/group:
sshd:*:27:
_portmap:*:28:
_identd:*:29:
_rstatd:*:30:
_rusersd:*:32:
_fingerd:*:33:
_sshagnt:*:34:
_x11:*:35:
authpf:*:72:
### New group for crontab(1) and at(1)
### The
crontab(1)
and at(1)
commands are no longer setuid root,
### they are now setgid crontab.
### Add a line like the following to your
/etc/group
file:
crontab:*:66:
### The
permissions may or may not get corrected,
### Here are some commands by hand just in case
### they are needed (/bin/csh shell)
chgrp crontab /var/at/at.{allow,deny} /var/cron/{allow,deny}
chmod 0640 /var/at/at.{allow,deny} /var/cron/{allow,deny}
foreach f ( /var/cron/tabs/* )
set u=`basename $f`
chown $u.crontab $f
end
### Note that you probably will not have all of the allow/deny
files;
### this is not expected to be a problem. |
Notes for changes from release 3.2 to 3.3 that
may still need doing after extracting binaries and before mergemaster
|
#################
#### from 3.2 to 3.3#
#################
### more users and groups needed for new features
groupadd -g 61 _lkm
groupadd -g 62 _spamd
groupadd -g 63 _radius
groupadd -g 64 _token
groupadd -g 65 _shadow
chgrp _lkm /dev/lkm
chgrp _radius /etc/raddb /etc/raddb/servers
chmod g+x /etc/raddb
chmod g+r /etc/raddb/servers
chgrp _token /etc/activ.db /etc/crypto.db /etc/snk.db
chmod 0640 /etc/activ.db /etc/crypto.db /etc/snk.db
chgrp _shadow /etc/spwd.db
chmod 0640 /etc/spwd.db
### as root add the user entry using vipw(8):
### _spamd:*:62:62::0:0:Spam daemon:/var/empty:/sbin/nologin
### may or may not need to remove unused libraries,
### libc_r and libnptherad replaced by libpthread
rm /usr/lib/libc_r* /usr/lib/libnpthread*
### may or may not need to do something about the fact that the
### contents of /var/at have been merged into /var/cron now
### that at has been integrated into cron
mv /var/at/* /var/cron
mv /var/cron/jobs /var/cron/atjobs
mv /var/cron/allow /var/cron/cron.allow
mv /var/cron/deny /var/cron/cron.deny
rm -rf /var/at
kill `cat /var/run/cron.pid`
/usr/sbin/cron
### Also be forewarned, that now OpenBSD uses
### version 9.x of BIND instead of
4.x and you the
### human may need to read up on BIND if unfamiliar.
|
Notes for changes from release 3.3 to 3.4 that
need to be done.
|
#################
#### from 3.3 to 3.4 - didn't work very well for us for those done
#### remotely because of the
change
to ELF,
#### in-place upgrades are not recommended.
#### Some enterprising admins have successfully worked around this
####
using
a 'installboot' that understands elf.
#### Todd Miller posted a message:
#### "You can copy:
ftp://ftp.courtesan.com/pub/millert/OpenBSD/3.4-a.out/bsd.rd
#### to your 3.3 machine's root filesystem and boot off it. It is an a.out 3.4 kernel
#### with the normal 3.4 ELF filesystem embedded in it. This is how I upgraded a
#### machine remotely via serial console..."
#### See also
http://undeadly.org/cgi?action=article&sid=20031028101040
####
BEST ADVICE: DON'T TRY IT, go to the machine, with a cdrom
#### and schedule downtime and do it by booting by cdrom!
############
### Following are commented out notes from the upgrade mini-faq,
### From 3.3 to 3.4 the following will need to be done, and might or
might not
### be caught by Mergemaster. ### New user and group _syslogd (2003/07/31)
### The syslogd(8) daemon now runs in privilege separated mode,
### and requires a new user and group _syslogd. Add the group by running
groupadd -g 73 _syslogd
### as root, and add the user entry using vipw(8):
_syslogd:*:73:73::0:0:Syslog Daemon:/var/empty:/sbin/nologin
### of note several files have been added that may not be yet
mentioned,
### like /etc/pf.os which is used for passive OS fingerprinting
### using mergemaster helps catch theses
|
Notes for changes from release 3.4 to 3.5 that
need to be done.
|
#################
### from 3.4 to 3.5
#################
#### new dev stuff
#### cp /usr/src/etc/etc.`machine`/MAKEDEV /dev
cd /dev
rm svnd* rsvnd*
./MAKEDEV vnd
### The pflogd(8) daemon now runs in privilege separated mode,
### and requires a new user and group _pflogd. Add the group by running
groupadd -g 74 _pflogd
### as root, and add the user entry using vipw(8):
### _pflogd:*:74:74::0:0:pflogd privsep:/var/empty:/sbin/nologin
### Several pseudo network drivers (like gif(4), lo(4), and tun(4)) have
been
### moved to support cloning. A snapshot will likely overwrite so they
don't
### have to be made, but if unsure, with new kernel can do theses steps:
# cd /usr/src && make includes
# cd sbin/ifconfig
# make obj depend
# make
# make install
# cp /usr/src/etc/netstart /etc
### The new bgpd(8) daemon runs in privilege separated mode,
### and requires a new user and group _bgpd.
#Add the group by running
groupadd -g 75 _bgpd
# and as root add this entry using vipw
### _bgpd:*:75:75::0:0:BGP Daemon:/var/empty:/sbin/nologin
### The join(1) command has been updated to follow the POSIX
### standard when writing non-matching lines. As a consequence
## /etc/security has to be updated. Runing mergemaster should
catch
## the change, but if you have the source you may want to:
# cp /usr/src/etc/security /etc
### The way the sudo(8) command is built has changed.
### A side-effect of this is that you may need to remove and old
### obj code if later doing a 'make build'
# rm -f /usr/obj/usr.bin/sudo/*
### new user noted during mergemasteruse....
groupadd -g 76 _tcpdump
### use vipw to add
### _tcpdump:*:76:76::0:0:tcpdump:/var/empty:/sbin/nologin
### ... this may not need to be done if replacing binaries rather than
### trying to rebuild, however it may need doing before rebuilding a kernel:
### machdep.c change (i386) (2004/02/01) A change to machdep.c requires that
### binutils be rebuilt before the kernel can be compiled. This only affects i386.
cd /usr/src/gnu/usr.bin/binutils
make -f Makefile.bsd-wrapper cleandir
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper depend
make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install
### Now you can rebuild the kernel and rest of the system
###### THIS IS ONLY FOR SPARC64 ############
### : Switch to gcc3 (sparc64) (2004/02/20)
### OpenBSD/sparc64 has converted to gcc3. To upgrade,
#
# cd /usr/src/share/mk
# make install
# rm -rf /usr/include/g++
### Now, build gcc3, (using the gcc3 directory)
### then build the kernel and system as usual.
################################
### Update bsd.own.mk (2004/02/20), suggested to update
### /usr/share/mk/bsd.own.mk to get the USE_GCC3 definition:
### (may not be necessary with binary install, may be...
cd /usr/src/share/mk
make install
########### not thought to be applicable for i386:
### Switch to gcc3 (sparc64) (2004/02/20)
###OpenBSD/sparc64 has converted to gcc3. To upgrade,
# rm -rf /usr/include/g++
###Now, build gcc3, (using the gcc3 directory) then build
###the kernel and system as usual.
|
Notes for changes from release 3.5 to 3.6 that
need to be done.
|
#############################
### from 3.5 to 3.6
#############################
#####################################
#### New user and group _dhcp (2004/04/12)
#### The various dhcp related daemons are being reworked
#### to drop privileges or to use privilege separation.
#### Thus a new user and group _dhcp are required.
### Add the user and group by running as root:
groupadd -g 77 _dhcp
useradd -u77 -g=uid -c"DHCP programs" -d/var/empty -s/sbin/nologin _dhcp
######################################
#### New user and group _mopd (2004/04/14)
#### The mopd(8) daemon now drops privileges after initialization,
#### and requires a new user and group _mopd.
### Add the user and group by running as root
groupadd -g 78 _mopd
useradd -u78 -g=uid -c"MOP Daemon" -d/var/empty -s/sbin/nologin _mopd
####################################
#### New user and group _tftpd (2004/04/17)
#### The tftpd(8) daemon now drops privileges after initialization
#### to a new user and group _tftpd instead of nobody.
### Add the guser and roup by running as root
groupadd -g 79 _tftpd
useradd -u79 -g=uid -c"TFTP Daemon" -d/var/empty -s/sbin/nologin _tftpd
### New user and group _rbootd (2004/04/30). The rbootd(8) daemon now drops
### privileges after initialization to a new user and group _rbootd.
### Add the user and group by running
groupadd -g 80 _rbootd
useradd -u80 -g=uid -c"rbootd Daemon" -d/var/empty -s/sbin/nologin _rbootd
### New user and group _afs (2004/05/06). The afsd(8) daemon is about to be
### privilege seperated. A new user and group _afs are required for this.
### Add the user and group by running
groupadd -g 81 _afs
useradd -u81 -g=uid -c"afs Daemon" -d/var/empty -s/sbin/nologin _afs
### New user and group _ppp (2004/05/06). The pppoe(8) program
### now drops privileges to a new user and group _ppp.
### Add the user and group by running
groupadd -g 82 _ppp
useradd -u82 -g=uid -c"PPP utilities" -d/var/empty -s/sbin/nologin _ppp
###New user and group _ntp (2004/05/30), The upcoming ntpd(8) program
###needs a new user and group _ntp. Add the user and group by running
groupadd -g 83 _ntp
useradd -u83 -g=uid -c"NTP Daemon" -d/var/empty -s/sbin/nologin _ntp
###########################################
#### pty device minor numbers changed (2004/04/11)
#### The device minor numbers of pty devices have changed
#### to increase the maximum number of pseudo-terminals
#### from 256 to 992, so you will need to run the updated
#### /dev/MAKEDEV before booting the new kernel:
###
### * Update your source code tree
### * Build and install a new kernel
### * Build the rest of the system (make build)
### * Copy the new MAKEDEV script to the /dev
### directory and create the new pty devices.
cp /usr/src/etc/etc.`machine`/MAKEDEV /dev
cd /dev && ./MAKEDEV pty0
### * Boot the new kernel
### * Remove the old pty devices no longer in use:
cd /dev && rm -f [pt]ty[rq]*
### * Or, for the vax platform:
### cd /dev && rm -f [pt]tyr*
### cksum moves (2004/05/02) The cksum(1) utility has moved from /usr/bin to /bin.
### After you have completed a make build or extracted the new chksum,
### run the following as root:
rm -f /usr/bin/cksum /usr/bin/sum
### Library bump flag day (2004/07/13)
#### This may cause you remote difficulties if you did not
reboot with new
#### generic kernel......
### Library and system interface changes have been made that require
### a bump of the major version number of every library.
### If you are extracting from you most likely will not have to do the
following.
#* update your source code tree, * Build a new kernel,
#* Install the new kernel and reboot,
* install new header files:
# cd /usr/src && make obj && make cleandir && make includes
#* build and install a new version of libc
## cd /usr/src/lib/libc && make depend && make && env NOMAN=1 make install
#* Build and install the system as usual
# cd /usr/src && make build
### Changes in pf anchors (2004/08/07)
### Users of authpf should change their anchor rule in the main ruleset from
# anchor authpf
# to
# anchor "authpf/*"
|
Notes for changes from release 3.6 to 3.7
|
###################
### from 3.6 to 3.7 ###
###################
New users and groups
The FTP daemon has been reworked to drop privileges, and an
OSPF daemon
has been added, so new users and groups are required.
As root, add
the following users and groups, using
useradd(8):
useradd -u84 -g=uid -c"FTP Daemon" \
-d/var/empty -s/sbin/nologin _ftp
useradd -u85 -g=uid -c"OSPF Daemon" \
-d/var/empty -s/sbin/nologin _ospfd
X.org replaces XFree86: Due the XFree86 project's change of
license,
OpenBSD has switched to the X.org
project's X Window System.
The X11 configuration files must be updated,
however.
If you have an /etc/X11/XF86Config file that works on
OpenBSD
3.6, renaming it to /etc/X11/xorg.conf will
probably give you a
fully functioning X Window system on
OpenBSD 3.7. You may also find that the
newer versions
of X are much more "self-configuring" than earlier versions,
and you may not need an /etc/X11/xorg.conf file at all
now,
depending on your hardware.
New directories also, which using mergemaster utility should
catch with mtree invoked.
|
Notes for changes from release 3.7 to 3.8
###################
### from 3.7 to 3.8 ###
###################Note that, with OpenBSD 3.8, the pkg tools now
support in-place
updating using pkg_add -r. This has been
checked to work with most
packages, in particular with the CD packages
available in 3.6 or 3.7.
Some important points apply:
pkg_add -r does not do global updates, but needs to be
told
which packages to update. A new option pkg_add -u can
be
used to find out the exact list of packages to pass to pkg_add
-r. pkg_add -r -F update -F updatedepends -q list_of_new_pkgs
should work in most cases. - mozilla packages in 3.7 can now safely be updated to a 3.8 version.
Install new /etc/firmware files: Due to the fact that some
uploaded
"firmware" blobs were relocated from the kernel to files in the
/etc/firmware
directory, there are a few drivers which will break if
there is no uploadable
firmware file available when the new kernel boots.
This will impact users of
only a few devices, though all users can use this
step without harm.
To extract the firmware files from base38.tgz,
use the following as root:
cd /
tar xzpf /path/base38.tgz "*etc/firmware/*"
New users and groups
An HostAP daemon has been added, so new users and groups are required.
As
root, add the following users and groups, using
useradd(8):
useradd -u86 -g=uid -c"HostAP Daemon" \
-d/var/empty -s/sbin/nologin _hostapd
This step will add both the new user and its corresponding group.
Your
environment may allow you to copy/paste those commands.
Userland Applications
/etc file changes (mergemaster package may be able to do
all this later)
You will want to extract the etc38.tgz files to a temporary
location:
cd /tmp
tar xzpf /path/etc38.tgz
Files that can probably be copied from etc38.tgz or from src "as
is":
hostapd.conf
netstart
pf.os
rc
services
mtree/*
Note that it IS possible to locally modify these files, if this has been
done,
manual merging will be needed. Here are copy/paste lines for copying
these
files, assuming you unpacked etc38.tgz in the above
recommended place:
cd /tmp/etc
cp hostapd.conf netstart pf.os rc services /etc
cp mtree/* /etc/mtree/
Files that must be manually merged, respecting any local changes
made to
them, if they were modified from the default, otherwise,
just copy them
over, too:
ftpusers
inetd.conf
login.conf
rc.conf
sysctl.conf
syslog.conf
mail/aliases
The changes to these files are in
this patch file.
NOTE mergemaster maybe able to handle all this...
You can attempt to use
this by executing the following as root:
cd /
patch -C -p0 <upgrade38.patch
This will test the patch to see how well it will apply to YOUR system,
to
actually apply it, leave off the "-C" option. Note that it is
likely that if
you have customized files or not kept them closely updated,
or are
upgrading from an snapshot of 3.7, they may not accept the patch
cleanly.
In those cases, you will need to manually apply the changes.
Please
test this process before relying on it for a machine
you can not easily get
to.
The following files have had changes which should be looked at,
but it is
unlikely they should be directly copied or merged
(i.e., if you are using pf.conf, look at the suggested change of
strategy, and decide if it is
appropriate for your use).
pf.conf
spamd.conf
/root/.profile
New directories also, which using mergemaster utility
should catch with mtree invoked.
Finally, use
mtree(8) to create any new directories:
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
|
Notes for changes from release 3.8 to 3.9
###################
### from 3.8 to 3.9 ###
#################### We repeat you may do better to follow the official notes
# on the OpenBSD website. The notes now include local
# local booting from media and remote upgrade notes.
# http://www.openbsd.org/faq/upgrade39.html
# We repeat similar information here.
# For the /etc you will need to get some files from the new
distribution,
# and it may be a good # idea to do so before doing the install because
# they may be needed by the kernel.
# Install new /etc/firmware files: Due to the fact that some
# uploaded
"firmware" blobs were relocated from the kernel to files in
# the
/etc/firmware directory, there are a few drivers which
# will break if
there is no uploadable firmware file available
# when the new kernel
boots. This will impact users of only a
# few devices, though all users
can use this step without harm.
# To extract the firmware files from
base39.tgz, use the following as root:
cd /
tar xzpf ${RELEASEPATH}/base39.tgz "*etc/firmware/*"
# Reboot on the new kernel before doing extracting
# the upgrade tars:
# This might be a tempting step to skip,
# but it should be done now, as usually,
# the new kernel will run old userland apps
# New users and groups * no new users or
# groups (that was unusual)
#### Operational changes
# * ftp-proxy ftp-proxy(8) was replaced by what was previously called
pftpx.
# The new ftp-proxy runs stand-alone and not from inetd.conf(5) as
it used to.
# You will have to update /etc/inetd.conf to no longer invoke
ftp-proxy(8),
# and update /etc/rc.conf and /etc/rc to run the new one.
# Edit rc.conf or rc.conf.local to invoke the new program,
for example:
echo 'ftpproxy_flags=""' >> /etc/rc.conf.local
# The new proxy uses anchors to allow data connections,
# which
means that your existing /etc/pf.conf must be adapted.
# In the NAT section you need:
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
# They are mandatory, even if you don't use NAT otherwise.
# The following rule, that is probably already there for the
# old ftp-proxy, must stay:
rdr pass on $int_if proto tcp from $lan to any port 21 -> \
127.0.0.1 port 8021
# In the rules section, this is needed:
anchor "ftp-proxy/*"
# Rules that allow the proxy to make FTP control connections
#(destination port 21/tcp) must stay. Rules that allow FTP data
#connections are no longer needed. Those rules may contain
#"user
proxy" or "to port > 49151". Care has been taken to keep the
#commandline switches similar, but some differ.
#See the ftp-proxy man
page.
# One case warrants special mention: if you have old clients that
rely
#on active mode data connections which use 20/tcp as a source
port,
#you need the '-r' switch
#(for this you had to run the old
proxy with "-u root").
# Run ftp-proxy with "-d -D7" if you run into trouble and
# want to
diagnose what's happening.
######## /etc file changes
######## If you use mergemaster
it should catch these changes, but it
######## would
not be a bad idea to do it manually afore.
# You will want to extract the etc39.tgz files to a temporary
location:
cd /tmp
tar xzpf ${RELEASEPATH}/etc39.tgz
# Files that can probably be copied from etc39.tgz "as is":
daily
ipsec.conf
magic
monthly
netstart
rc
security
services
weekly
mtree/*
# Note that it IS possible to locally modify these files, if this has
# been done, manual merging will be needed. Here are copy/paste
# lines for
copying these files, assuming you unpacked etc39.tgz
# in the above
recommended place:
cd /tmp/etc
cp daily ipsec.conf magic monthly netstart rc security services
weekly /etc
cp mtree/* /etc/mtree/
# Files that must be manually merged, respecting any local changes
# made to them, if they were modified from the default,
# otherwise, just
copy them over, too:
changelist
inetd.conf
lynx.cfg
rc.conf
ssh/ssh_config
ssh/sshd_config
sysctl.conf
# The changes to these files are in this patch file. You can attempt
to
# use this by executing the following as root:
cd /
patch -C -p0 < upgrade39.patch
# This will test the patch to see how well it will apply to YOUR
system,
# to actually apply it, leave off the "-C" # option. Note that it is likely
that
# if you have customized files or not kept them closely updated, or are
# upgrading from a snapshot of 3.8, they may not accept
the patch cleanly.
# In those cases, you will need to manually apply the
changes.
# Please test this process before relying on it for a machine you
# can not easily get to.
# The following files have had changes which should be looked at,
# but
it is unlikely they should be directly copied or merged (i.e., if
# you
are using pf.conf, look at the suggested change of strategy, and
# decide
if it is appropriate for your use).
hostapd.conf
pf.conf
spamd.conf
# Finally, use mtree(8) to create any new directories:
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
|
Notes for changes from release 3.9 to 4.0
#######################
### from 3.9 to 4.0 ###
######################## We repeat you may do better to follow the official
# notes at http://www.openbsd.org/faq/upgrade40.html
# the notes are referenced as follows
#2006/03/27 - New iwi(4) firmware
#iwi(4) now requires firmware version 3.0 to run.
#Due to license problems the
#firmware is not currently distributed with OpenBSD.
#The firmware can be installed via the pkg tools
#with the package at
http://damien.bergamini.free.fr/iwifw/\
OpenBSD/iwi-firmware-3.0.tgz.
#2006/05/18 - spppcontrol(8) removal
#In-kernel PPP configuration is now fully supported
#by ifconfig(8). The obsolete spppcontrol(8) utility
#has been removed from the tree.
#See the manual pages sppp(4) and pppoe(4)
#for configuration examples.
#Previously, the /etc/hostname.pppoe0 file
# looked like this:
#
#pppoedev ne0
#!/sbin/ifconfig ne0 up
#!/usr/sbin/spppcontrol \
# $if myauthproto=pap myauthname=testcaller \
# myauthkey=donttell
#!/sbin/ifconfig \$if inet 0.0.0.0 0.0.0.1 \
# netmask 0xffffffff
#!/sbin/route add default 0.0.0.1
#up
#
#This should be updated according to the following example:
#
#inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev ne0 \
#authproto pap authname testcaller authkey donttell up
#!/sbin/route add default 0.0.0.1
#
#And the physical interface must be marked UP:
#
## echo "up" > /etc/hostname.ne0
#2006/05/26 - ipsecadm(8) removal
#IPsec configuration is now fully supported by ipsecctl(8).
#The obsolete ipsecadm(8) utility has been removed
#from the tree. See the ipsec.conf(5) manual page for
#configuration examples.
#2006/06/21 - dvmrpd(8) added
#A mrouted(8) replacement has been started
# and imported, in order to use
# (note: not very useful yet)this new daemon
#the user _dvmrpd must be added:
useradd -u87 -g=uid -c"DVMRP Daemon" \
-d/var/empty -s/sbin/nologin _dvmrpd
#2006/06/25 - wicontrol(8) removal
#Wireless configuration for wi(4) is now fully supported
#by ifconfig(8). The obsolete wicontrol(8) utility has
#been removed from the tree.
#2006/07/27 - new compiler option
#The kernel on all platforms is now built with the
# recently introduced # -Wstack-larger-than compiler
# option.
# Before building a kernel, the compiler needs
# to be built and installed.
#Follow the instructions in FAQ 5 -
# How do I bootstrap a newer version
# of the compiler for details.
# http://www.openbsd.org/faq/faq5.html#NewCompiler
#
# --- this may not apply if you booted
# using a cdrom w/ snapshot
# and are doing an upgrade, but it does sound
# like trouble for a remote upgrade
|
Notes for changes from release 4.0 to 4.1
#######################
### from 4.0 to 4.1 ###
#######################QUOTED FROM
http://www.openbsd.org/faq/upgrade41.html
- Install new /etc/firmware files: Due to the fact
that some uploaded "firmware" files may have been updated, you may need
to update the files in the /etc/firmware directory. This will
impact users of only a few devices, though all users can use this step
without harm. To extract the firmware files from base41.tgz,
The firmware files hopefully will extract when extractng:
base41.tgz ./etc/firmware
- Note: the files in /etc may best be manually merged or with
mergemaster, so etc41.tgz and xetc41.tgz should NOT be
unpacked over existing.
Note: During this process,
sendmail(8) may produce some error messages like the following:
Nov 1 12:47:05 puffy sm-mta[16733]:
filesys_update failed: No such file or dire
ctory, fs=., avail=-1, blocksize=380204
These messages can be safely ignored, or you may wish to halt
sendmail(8) during the upgrade process.
New users and groups
Operational changes
This is not a complete list of the changes that took place between
4.0 and 4.1, but rather some of the important things that will impact a
large number of users in the upgrade process. For a more complete list of
changes, see plus41.html
and the CVS change logs.
- "flags S/SA keep state" implicit in pf.conf(5)
flags S/SA keep state is now the default for pass rules in
pf.conf(5), and new no state and flags any options
have been added to override these defaults. Current rulesets will
continue to load, but the behaviour may be slightly changed as these
defaults are more restrictive. Rulesets with stateless filtering (no
state) or a requirement to create states on intermediate packets (flags
any) should be updated to explicitly request the desired behaviour.
In particular care should be taken with the
enc0 interface, as floating states are a potential problem for
filtering IPsec traffic: states need to be interface bound, to avoid
permitting unencrypted traffic should
isakmpd(8) exit. Therefore all rules on the enc0 interface should
explicitly set keep state (if-bound)
- FreeBSD and NetBSD DOS MBR partitions are no longer used to store
disklabels, and are no longer searched for a disklabel
As a result, disks with only FreeBSD or NetBSD DOS MBR partitions will
no longer have an 'a' partition created in the spoofed disklabel. The
disklabel on such disks will be stored and loaded from sector 1, and
this could find an old accidental disklabel. Use fdisk(8) to change the
partition type to OpenBSD ('A6') to use the existing disklabel.
- amd64, i386, macppc, and mvmeppc no longer try to boot from the
first NetBSD partition when no OpenBSD partition is found.
Again, use
fdisk(8) to change the partition type to OpenBSD ('A6').
- New way to enable/disable process accounting on boot
In order to enable accounting on boot you need to set the new rc.conf
variable "accounting=YES". The presence of the /var/account/acct file
does not make it start automatically anymore.
- spamd(8) now runs in greylist mode by default
Whereas before greylisting had to be enabled via the -g flag,
it is now the default runtime mode. The -b flag (which used to
indicate which IP spamd(8) should listen on) can be used to run spamd in
blacklist-only mode. The new -l flag is used to indicate which
IP spamd should listen on.
- spamd.conf(5) now stored in /etc/mail
The spamd.conf(5) file which used to be stored in /etc has been
moved to /etc/mail. Move your spamd.conf file into
/etc/mail so that spamd(8) loads the proper configuration.
- Kernel sensors sysctl(3) MIB is now hierarchical
The sensors sysctl(3) MIB now contains the name of the sensor device as
well as the type and index of the actual sensor. So before when running
"sysctl hw.sensors" you might've seen "hw.sensors.12=it0, Temp 1,
25.00 degC" you will now see "hw.sensors.it0.temp0=25.00 degC".
Update your
sensorsd.conf(5) file to reflect the new names of your sensors.
Upgrading packages
If you installed any packages on your system, you should upgrade them after
completing the upgrade of the base system. Be aware, however, many packages
will require further setup before and/or after upgrading the package. Check
with the application's upgrade guide for details.
The following package is known to have significant upgrade issues that
will impact a large number of users. The fact that a package is not on this
list doesn't mean it will have a trivial upgrade. You must do some homework
on the applications YOU use.
- Postgresql: you must dump your database before upgrade and
restore it after
The package tools support in-place updating using pkg_add -u. For
instance, to update all your packages, make sure PKG_PATH is
pointing to the 4.1 packages directory on your CD or nearest FTP mirror, and
use something like
# pkg_add -ui -F update -F updatedepends
where the -u indicates update mode, and -i specifies
interactive mode, so pkg_add will prompt you for input when it encounters
some ambiguity. Read the
pkg_add(1) manual page and the
package management
chapter of the FAQ for more information.
|
Notes for changes from release 4.1 to 4.2
###################
### from 4.1 to 4.2 ###
###################Most of this information is quotedfrom
http://www.openbsd.org/faq/upgrade42.html
- Packages are now using libexpat shipped with X; xbase42.tgz is
your friend:
The libexpat port has been removed. Packages now use the libexpat which
is shipped with X instead. Many packages depend on libexpat through
other dependencies. For instance, many packages require gettext which
depends on libexpat. Therefore, these packages also depend on libexpat.
This means that many systems that weren't using X before will now
need to have xbase42.tgz installed. If you don't do this and
try to install a package that requires libexpat, pkg_add(1) will give an
error message.
Also note that building ports is only supported with a full
installation, including all X file sets.
Finally, after upgrading all your packages to the 4.2 versions, clean
up by removing the old expat package from your system:
# pkg_delete expat
This will impact a large number of users! This was an unfortunate
decision whose ramifications were not recognized earlier in the process.
For 4.3, libexpat will be part of base43.tgz, solving this
problem.
- Updated
ahci driver may change how disks are handled:
Systems using the ahci(4) driver may find SATA disks which had been
recognized and handled by the
wd(4) (i.e., wd0) to become
sd(4) (i.e., sd0) devices. Watch the dmesg output at boot.
A drive which turned up earlier as:
pciide1 at pci0 dev 31 function 2 "Intel 82801GBM AHCI
SATA" rev 0x02: DMA, channel 0 wired to native-PCI,
channel 1 wired to native-PCI
pciide1: using apic 2 int 11 (irq 11) for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <FUJITSU MHV2080BH>
wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
now instead turns up as:
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM
AHCI SATA" rev 0x02: AHCI 1.1: apic 2 int 16 (irq 11)
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, FUJITSU MHV2080B,
0084> SCSI2 0/direct fixed
sd0: 76319MB, 76319 cyl, 64 head, 32 sec, 512 bytes/sec,
156301488 sec total
This will cause problems for people doing remote upgrades of these
machines, as if the fstab file is not "correct", the system will not
complete booting. Unfortunately, how the driver handles the disk is
dependent upon a lot of things including BIOS configurations, so IF one
has an AHCI SATA interface, one will have to experiment with a similarly
configured local machine to see if the /etc/fstab file will
need to be re-worked.
It is believed very few people will be hit by this now, as ahci(4)
devices are moderately rare on existing hardware, though becoming much
more common now.
- bgpd filter language change:
bgpd filters using only prefixlen as filter parameter now need
to include an address family identifier like inet or inet6:
allow from any inet prefixlen 8 - 24
deny from any inet6 prefixlen > 64
As a reminder, bgplg and associated binaries are disabled at
install/upgrade time. If you use them, they must be re-enabled as
described in
bgplg(8).
SSH protocol 1 discouraged on new installs:
New OpenBSD installs will default to not accepting SSH v1 connections.
This upgrade process will not replace the /etc/ssh
configuration files, but you may wish to manually do this to gain the
new behavior. The following diff shows what has changed on new installs:
--- ./etc/ssh/sshd_config Sat Mar 10 20:31:32 2007
+++ ../42/etc/ssh/sshd_config Tue Aug 28 11:59:52 2007
@@ -11,3 +11,2 @@
#Port 22
-#Protocol 2,1
#AddressFamily any
@@ -15,2 +14,7 @@
#ListenAddress ::
+
+# Disable legacy (protocol version 1) support in the server for new
+# installations. In future the default will change to require explicit
+# activation of protocol 1
+Protocol 2
- Again, this change is NOT part of the standard upgrade process.
Changes in the way sudo(8) passes environment:
For
security reasons
sudo(8) will now reset the environment to a small default set with
only certain variables preserved from the previous environment.
In order for many things to continue to work as expected, the patch
file below will add a "Defaults env_keep"
line to your /etc/sudoers file and otherwise try to make the
file look like the one in etc42.tgz, but will possibly fail.
You will want to make sure your sudoers file contains a line
that looks something like:
%wheel ALL=(ALL) SETENV: ALL
-- or --
%wheel ALL=(ALL) NOPASSWD: SETENV: ALL
assuming you wish "wheel" group users to have full sudo rights. It would
probably be wise to test sudo(8) for proper operation before logging out
of the system after the patch file is applied.
- [alpha Only] Some de(4) NICs will become dc(4):
On the alpha platform,
some NICs which had been supported by the
de(4) driver will now be supported by
dc(4).
IF your NIC is one of these, you will need to alter at least your
/etc/hostname.deX (hint: hard link) and your pf.conf files as
appropriate.
Again, this is only on the alpha platform.
- [i386 Only] apm(4) takes precedence over acpi(4)
The device detection on i386 has been modified to make
apm(4) take precedence over
acpi(4). It means that if your hardware has both apm and acpi
devices, only apm will attach. If for some reason you prefer to use acpi,
disable apm on your acpi-enabled kernel using config(8)
or boot -c.
- rc.conf:
Unlike earlier versions of this process, since
4.1 it is
assumed that /etc/rc.conf is not a user-altered file. If you
have made changes to your /etc/rc.conf file, merge those
changes into /etc/rc.conf.local. If you have NO /etc/rc.conf.local,
simply copy your existing /etc/rc.conf file to /etc/rc.conf.local
and delete the last line of the script! Otherwise, pull your
existing rc.conf into the top of your existing
rc.conf.local file and remove the last line before doing the
rest of this process.
- Modified kernel:
Check whether you have made any modifications to your kernel. For
example, you might have modified your network device to use a
non-default setting using config(8). Note your changes, so you can
repeat them for the new 4.2 kernel.
Upgrading without install kernel
This is NOT the recommended process. Use the install kernel method if at
all possible!
Sometimes, one needs to do an upgrade of a machine when one can't easily
use the normal upgrade process. The most common case is when the machine is
in a remote location and you don't have easy access to the system console.
One can usually do this by carefully following this process:
During this process,
sendmail(8) may produce some error messages like the following:
Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed:
No such file or directory, fs=., avail=-1, blocksize=380204
These messages can be safely ignored for the moment, or you may wish to halt
sendmail(8) during the upgrade process. Note that sendmail is not working
properly at this point, and will need to be restarted (as part of the
reboot) before mail is expected to be handled properly.
Final steps
Whether you upgrade by using an install kernel and doing a formal "upgrade"
process, or do a "in-place" binary upgrade, there are certain manual steps
that have to be performed.
1. Upgrading /etc
You will want to extract the etc42.tgz files to a temporary
location:
tar -C /tmp -xzphf ${RELEASEPATH}/etc42.tgz
Files that can probably be copied from etc42.tgz "as is":
etc/magic
etc/man.conf
etc/netstart
etc/rc
etc/rc.conf
etc/rpc
etc/services
etc/mail/helpfile
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist
etc/mtree/BSD.local.dist
etc/mtree/special
Note that it IS possible to locally modify these files, if this has been
done, manual merging will be needed. Pay special attention to mail/*
if you are using something other than the default Sendmail(8) configuration.
Here are copy/paste lines for copying these files, assuming you unpacked
etc42.tgz in the above recommended place:
cd /tmp/etc
cp magic man.conf netstart rc rc.conf rpc services /etc
cp mtree/* /etc/mtree/
cp mail/helpfile mail/localhost.cf mail/submit.cf /etc/mail
cp mail/sendmail.cf /etc/mail # Careful on this one!!
Files that must be manually merged, respecting any local changes made to
them, if they were modified from the default, otherwise, just copy them
over, too:
etc/ntpd.conf
etc/sensorsd.conf
etc/ssh/ssh_config
etc/ssl/x509v3.cnf
etc/sudoers
etc/sysctl.conf
etc/wsconsctl.conf
var/www/conf/httpd.conf
The changes to these files are in
this patch file.
You can attempt to use this by executing the following as root:
cd /
patch -C -p0 < upgrade42.patch
This will test the patch to see how well it will apply to YOUR system, to
actually apply it, leave off the "-C" option. Note that it is
likely that if you have customized files or not kept them closely updated,
or are upgrading from a snapshot of 3.9, they may not accept the patch
cleanly. In those cases, you will need to manually apply the changes. Please
test this process before relying on it for a machine you can not easily get
to.
The following files have had changes which should be looked at, but it is
unlikely they should be directly copied or merged (i.e., if you are using
bgpd.conf, look at the suggested change of strategy, and decide if it is
appropriate for your use).
etc/bgpd.conf
etc/mail/spamd.conf
etc/ospfd.conf
etc/ssh/sshd_config
Finally, use
newaliases(8) to update the aliases database and
mtree(8) to create any new directories:
newaliases
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
2. Checking the kernel
Note: most people can skip this step!
If you followed the instructions for the upgrade process without install
kernel, you have already completed this step. However, if you used the
install kernel, and if you had a modified kernel in 4.1, it is likely you
will need to modify the stock kernel of 4.2. This can be as simple as
modifying a specific device using config(8), or it can involve a
recompilation if the option you need is not included in the GENERIC kernel.
Please consult FAQ 5 -
Building the system from source before considering to recompile your
kernel.
3. X configuration files
Due to the significant changes in X for this release, the easiest way to
upgrade your X for 4.2 may be to back up your existing X configuration
files, unpack xetc42.tgz, and manually merge back any changes you had made.
The files you are most likely to want to save a copy of are /etc/X11/xorg.conf
and /etc/X11/xinit/xinitrc. As X now often works with NO xorg.conf
file, you may wish to try it without one before you copy your file back.
Unpack xetc42.tgz as you would other file sets:
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf xetc42.tgz
4. Upgrading packages
If you installed any packages on your system, you should upgrade them after
completing the upgrade of the base system. Be aware, however, many packages
will require further setup before and/or after upgrading the package. Check
with the application's upgrade guide for details.
The following package is known to have significant upgrade issues that
will impact a large number of users. The fact that a package is not on this
list doesn't mean it will have a trivial upgrade. You must do some homework
on the applications YOU use.
- xfce: Configuration base directory and files have completely
changed. You will probably have to re-create your configuration from
scratch.
Before continuing, there are some major changes in the 4.2 release which
you should know about:
- The libexpat port has been removed, and packages are now using the
libexpat shipped with X11 instead. Many packages depend on libexpat
through other dependencies. For instance, all the packages which require
gettext also depend on libexpat. This means that before you can add or
upgrade packages, you most likely need to have xbase42.tgz
installed, even if the packages you are installing don't have a
graphical operation. Refer to the
FAQ about
adding xbase42.tgz to an installed system. If you don't do this
and try to install a package that requires libexpat, pkg_add(1) will
give an error message.
- If you are using pkg_add(1) in combination with sudo(8), you will
need to change your /etc/sudoers as the
patch file attempts to. See changes in sudo(8)
for more info.
The package tools support in-place updating using pkg_add -u. For
instance, to update all your packages, make sure PKG_PATH is
pointing to the 4.2 packages directory on your CD or nearest FTP mirror, and
use something like
# pkg_add -ui -F update -F updatedepends
where the -u indicates update mode, and -i specifies
interactive mode, so pkg_add will prompt you for input when it encounters
some ambiguity. Read the
pkg_add(1) manual page and the
package management
chapter of the FAQ for more information.
You will very possibly see something like this when running the above
command:
Looking for updates: complete
Cannot find updates for expat-2.0.0
Proceed? [y/N]
This is indicating you have run into the libexpat problem and must now
install xbase42.tgz as mentioned above. If you have not installed
xbase42.tgz, it is recommended that you stop the package update, install
xbase42.tgz and then re-run the package upgrade.
Finally, after upgrading all your packages, clean up by removing the old
expat package from your system:
# pkg_delete expat
|
Notes for changes from release 4.2 to 4.3
#######################
### from 4.2 to 4.3 beta ###
#######################2007/09/03 - _cxa_atexit support and sys/net
headers flag day
Support for _cxa_atexit has been added to csu. Using the new kernel
is imperiative and a new "csu" which hopefully will unfold from the tar
2007/10/20 - libexpat moved to base
libexpat has been moved from xenocara (xbase) to src (base); if you are
using binary snapshots and packages, things should just update during
extraction...
2007/10/08 - new user for ospf6d
A ospf6d daemon has been imported in order to use this daemon, a new
user and group are required. As root, add the following user and
group, using
useradd(8):
# useradd -u90 -g=uid -c"OSPF6 Daemon" -d/var/empty -s/sbin/nologin _ospf6d
This step will add both the new user and its corresponding group.
2007/11/28 - new AGP driver
The new agp(4)
driver requires an update to the X server after installing a new kernel if
your machine requires AGP support for X or XVideo. A new upgrade
of X hopefully will extract what you need, if not:
# cd /usr/src/include
# make includes
# cd /usr/src/xenocara/xserver
# make -f Makefile.bsd-wrapper build
# cd /usr/src/etc/etc.`uname -m`
# install -c MAKEDEV /dev
# cd /dev
# ./MAKEDEV agp0
2007/12/07 - _hoststated user gets renamed to _relayd
The hoststated(8) daemon has been renamed to
relayd(8), so the user and group need to be changed accordingly.
Use
vipw(8), edit the password files and your favorite editor to edit the
/etc/group file, changing "_hoststated" to "_relayd"
in both. Leave the rest of the line alone in each case.
|
Notes for changes from release 4.3 to 4.4
#######################
### from 4.3 to 4.4. beta ###
#######################not available as of this documentation.
|
PORTS: Before upgrading, some users choose to remove all
packages, and
installing new versions after upgrade. You may want to rename the old /usr/ports
to something like /usr/ports-old just in case you need it to roll back.
To quickly remove all packages from your system:
pkg_delete -q /var/db/pkg/*
After the upgrade, install the new versions of these applications.
Note that, with OpenBSD 3.8, the pkg tools now support
in-place updating using pkg_add -r.
This has been checked to work with most packages, in particular with the CD
packages available in 3.6 or 3.7. Some important points apply:
pkg_add -r does
not do global updates, but needs to be told which packages to update. A
new option pkg_add -u can be used to find out the exact
list of packages to pass to pkg_add -r. pkg_add -r -F update -F updatedepends -q
list_of_new_pkgs should work in most cases.
- mozilla packages in 3.7 can now safely be updated to
a 3.8 version.
OpenBSD 3.9
If you installed any packages on your system, you may want to update
them after completing the update of the base system. In OpenBSD 3.9, the pkg
tools now support in-place updating using pkg_add -u. This has been
checked to work with most packages, in particular with the CD packages
available in 3.8. For instance, to update all your packages, make sure
PKG_PATH is pointing to the 3.9 packages directory on your nearest CD
or FTP mirror, and use something like
# pkg_add -ui -F update -F updatedepends
where the -u indicates update mode, and -i specifies
interactive mode, so pkg_add will prompt you for input when it encounters
some ambiguity. Read the
pkg_add(1) manual page and the
package management
chapter of the FAQ for more information.
DEVICES: As a general rule, it is a good idea to copy and run the MAKEDEV script from your
source tree when performing an upgrade. Mergemaster might handle this okay, but
if unsure you may want to do yourself. Do note however when you remake the devices it is probable you won't be able to ssh back in again till reboot with matching usr land and kernel and /dev so it doesn't hurt to have an extra terminal open before doing this.
cd /dev
cp /usr/src/etc/etc.i386/MAKEDEV ./
./MAKEDEV all
DIRECTORIES: From time to time, files or directories are added to, or removed from the
file hierarchy. Also, ownership information for portions of the filesystem may
changes. Mergemaster might handle this okay, but if unsure you may want to do
yourself. An easy way to ensure that your file hierarchy is up-to-date is to use
the mtree(8) utility. First, fetch the latest source, then do the following:
cd /usr/src/etc/mtree
install -c -o root -g wheel -m 600 special /etc/mtree
### note, if users or groups like auth need added the next command will fail
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Hopefully now your file hierarchy should now be up to date.
Save existing kernel and copy the new replacement kernel into place. If
you have a custom kernel made on a similar machine already upgraded, change the
procedure accordingly. After this step, you will be committed if you are
remote. Also of note some unix administrators may do this much earlier before previous
steps, some will reboot after this point, others wait till later to reboot and
use the new kernel. This will be a decision to make by situation, because
sometimes the old user land does not like the new kernel and sometimes the new
userland being untarred does not like the old kernel. Rebooting to late or to
early may require a on site reboot and maybe a console upgrade from media.
No one promised you a rose garden! Of note, for 3.9 to 4.0 we rebooted
after untarring the new files in the next step.
cp -p /bsd /bsd.old
cp /usr/4.0/i386/bsd /bsd
chown root.wheel /bsd
Don't untar etc**.tgz!
You should at least untar the base**.tgz, comp**.tgz, and man**tgz. We
think it is wise, space permitting, to untar the xserver related files to avoid
potential issues when doing make build from source. (We have noticed that
sometimes if you don't install x related distribution you may get errors when
doing make build from soure).
Now to extract the binaries, you can use a for loop (but make sure etc does not have tgz extension!) or untar each
manually . Note this probably will not work jumping from 3.3 to 3.4 for
intel platforms.
ALSO NOTE that going from 3.5 to 3.6/3.7 probably because of the Library
bump part of the way through the untar lost control of computer and had to have
the remote machine unplugged and powered back up causing a messy fsck. So you
may want to try to reboot with generic kernel before untarring, but that to may
be an issue. Good luck...
cd /usr/4.0/i386/; for i in *.tgz; do tar xvzpf $i -C /; done
(Of note, for 3.9 to 4.0 we remotely rebooted, reboot, here after untarring
the new files)
Editing
the configuration files;
mergemaster
is your buddy
Hopefully now we can use mergemaster package to updage configuration files.
else we hand do the changes as mentioned in the "Long Answer" section
of the http://www.openbsd.org/faq/upgrade-minifaq.html#1.9 Probably can lean on
info in the upgrade minfaq to help decide on some of the merging. And we can use
pkg_info look at where
mergemaster was put because it's probably not in your path. Some of the
information in the Upgrading OpenBSD FAQ may be very helpful when having to decide on
what parts to merge, replace or leave alone. BE VERY CAREFUL - THINK
BEFORE YOU REPLACE, MERGE, OR NOT REPLACE. A mistake here can show
up when you reboot and a remote upgrade could turn into a local console upgrade
or even install if fubar.
Oh and if you are do some line editing with mergemaster you might want to
refresh your "ed"
editor skills.
By the way, before running mergemaster you may want to
replace some of the documents for apache so you don't have to answer a hundred
or requests if okay to replace or merge, example:
### Copying the whole manual also copies a lot of
unecessary pages with other languages.
### cp -Rp /usr/src/usr.sbin/httpd/htdocs/manual/* /var/www/htdocs/manual/*
### so we can do this
cp /var/www/conf/httpd.conf /var/www/conf/httpd.conf.backup
cd /usr/src/usr.sbin/httpd; make -f Makefile.bsd-wrapper distribution
### install and run mergemaster
pkg_info -L mergemaster-*
/usr/local/sbin/mergemaster
A few last things to consider before rebooting....
- If you are paranoid or very far away from the remoter server, you may want to
check /etc/rc.conf and /etc/rc.local one more time with an editor.
- If you must use httpd with the -u flag, you may want to edit /usr/sbin/apachectl,
because it got replaced.
# the path to your httpd binary, including options if necessary
HTTPD="/usr/sbin/httpd -u "
- If
you are using suexec, you'll want to enable it because it also got
replaced
chmod u+s /usr/sbin/suexec
- If you manually copied some libraries or other includes from within /usr/src,
you better check and do manually again if needed for remaking ports
perhaps. For example, if you are using the libmilter feature of
sendmail (can set in /etc/mk.conf) and an port
of clamav with milter flavor, the port will need mfapi.h and perhaps it
is not using the latest and greatest but an old copy mapi.h that was copied
into a folder like /usr/include/libmilter/mfapi.h
rm -rf /usr/include/libmilter
cp -pr /usr/src/gnu/usr.sbin/sendmail/include/libmilter /usr/include/
- What else have we/you forgot?
Now that you have it done, and hopefully it runs after a reboot. Note
that next time you use ssh or scp to the machine the keys may have changed!
reboot
If it does not finish rebooting remotely, maybe the problem is a simple
mistake on /etc/rc.conf, /etc/rc.local or the new kernel didn't recognize
hardware the same way. If the remote machine is very remote, that will be
very sad. Maybe you can have some one nearer put a monitor on it and tell you
want the console says or maybe turn of the power and restart. Good luck.
Assuming that everything is otay after the reboot, now you should upgrade yet
again to get changes since your distribution. If you are chasing the edge,
current, you better read and reread the most recent notes added to Upgrading OpenBSD FAQ.
For upgrading to stable read the OpenBSD literature associated.
We updated using source
by anoncvs to modify /usr/src and redid the make obj && make
build then used mergmaster to merge configuration changes yet again (may want to
delete any temp stuff from last use of mergemaster if haven't already). If you already have a src tree and need to change tags, or just to be
safe
declare Tag and environmental variables like below for bourne
shell. Also we may want to clean all the cruft out of the existing source tree.
A very important thing you can do is to clean out your obj directories. (Note
you could also tar a know good /usr/src that was updated or checkout recently
and use that, but if you do be sure to clean the 'cruft' out of it).
### -- example with anoncvs@anoncvs1.usa.openbsd.org as
server,
### you may want to change
/bin/sh
cd /usr/src
export CVSROOT= "anoncvs@anoncvs1.usa.openbsd.org:/cvs"
export CVS_RSH=/usr/bin/ssh
### NOTE: If you are updating a source tree that you initially fetched from a
### different server, or from a CD, you must add the -d $CVSROOT options to
cvs.
#cd /usr/src
#cvs -d $CVSROOT -q up -Pd
cd /usr/src
cvs -q up -rOPENBSD_3_5 -Pd
##### example using 4 aug2003 current update:
### cvs -q up -D "2003-08-04 12:00" -Pd
###### of note, if use -A will make current
### cvs up -Pd -A
find . -type l -name obj | xargs rm
make -k cleandir
rm -rf /usr/obj/*
### If you're having trouble with left over stuff in /usr/src, per suggestion of the
### Upgrading OpenBSD FAQ
you may want to
### try adding -I ! -I CVS -I obj
to your CVS updates.
And now to bring everything in usr land up to date for stable version.
You may want to modify the commands below to use nohup with make build since
it takes a long time to rebuild the usr land and you can watch it with a tail -f nohup.out
### note, may want to edit
/etc/mk.conf if want things like libmilter support made during build
cd /usr/src
make obj
make build
cd /dev
cp /usr/src/etc/etc.`machine`/MAKEDEV ./
./MAKEDEV all
cd /usr/src/etc/mtree
install -c -o root -g wheel -m 600 special /etc/mtree
install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
mergemaster
And it probably would not hurt to recompile your kernel with the latest and
replace the generic distribution kernel. Note if you are using samba
or doing a gateway you will want to research tuning the kernel parameters.
Another excellent source of information on OpenBSD is the site by nomoa, http://nomoa.com/bsd/kernel.htm
:
OpenBSD FAQ 5.0 - Kernel
configuration
http://www.openbsd.org/faq/faq5.html
And as afore mentioned, you may have
to reset some file permissions like suexec, and copy some includes out of source
that a port may need.
Reboot yet again and verify all is otay then document findings
reboot
It is a good idea to shutdown the computer completely and restart while you are available
to monitor so as to make darn sure some strange error doesn't show up
days, weeks later when an ups outage or forced reboot happens! Last thing
is make notes. And if you could be so kind please send us corrections or
improvements to our notes here, openbsd@webengr.com. - tia.
......PHEW........
More Concerns:
Some packages have security issues and may need upgrading.
Upgrading packages even if conveniently made in /usr/ports may become tricky
because of dependencies and changes in configuration files.
You may want to research and if appropriate upgrade X4
and your
packages and custom applications
Please note that the above
will not build and install X4, make and validate the XF4 release, nor make the third party
packages! If your machine is a server and not using X windows this may not be a
worry for you, but do worry about upgrading the packages and ports you use! Read the man
page on 'release' for more information. See
also a script created by FenderQ, that may or may not
work for you... release_building.sh
Excerpt from man release
"...
At this point you have most of an OpenBSD release. The only thing missing is
the X Window System (which is covered in the next section).
5. Build and install XF4 The XF4 tree is primarily imake(1)-based and
doesn't contain the ``obj'' directory mechanism that comes with Berkeley
make(1). While the tree can be built in place, it's better to refrain from
polluting the cvs sources. An alternate build location needs to be selected,
large enough to hold the X Window System object files, libraries, and
binaries. Call this location XF4BLD. XF4SRC is the path to your X Window
System source files. Once you've selected XF4BLD the build process is ...."
If you like this document make a
donation to OpenBSD,
and recommend our services ;-)
|
|
|
