AFTERBOOT(8) BSD System Manager's Manual AFTERBOOT(8)
afterboot - things to check after the first complete boot
This document attempts to list items for the system administrator to check and set up after the installation and first complete boot of the system. The idea is to create a list of items that can be checked off so that you have a warm fuzzy feeling that something obvious has not been missed. A basic knowledge of UNIX is assumed, otherwise type # help Complete instructions for correcting and fixing items is not provided. There are manual pages and other methodologies available for doing that. For example, to view the man page for the ls(1) command, type: # man 1 ls Administrators will rapidly become more familiar with MirOS BSD if they get used to using the high quality manual pages. In order to browse a file, for example /usr/share/doc/legal/1stREAD, which you should really read, type: # less /usr/share/doc/legal/1stREAD Within less(1), type ? for help and q to quit. Other important files to read include /usr/share/doc/legal/LICENCE, which refers to most other files within the same directory. You are obliged to read, understand and acknowledge the licences outlined in these files to use this product.
By the time that you have installed your system, it is quite likely that bugs in the release have been found. Most significant and easily fixed problems will be reported at the errata webpage at http://mirbsd.de/ or its subpages. The web page will mention if a problem is security related. It is recommended that you check this page regularly.
Basic use of the lynx(1) command required. To see current online manual pages, go to this page: http://www.mirbsd.org/cman/ For interactive help, see our mailing lists: http://www.mirbsd.org/?mail There are several IRC channels to connect to: http://www.mirbsd.org/?irc Please note there is no longer an IRC client in the default installation; use net/sirc, net/bitchx, or net/irssi.
During installation, a user with which you can login has been created. Use sudo(8) to perform administrative tasks. Logging in as "root" is no longer possible; this also affects single user mode (which only works after you manually set a root password). You can do so on the console, or over the network using ssh(1). If you wish to log in as root over the network, edit the /etc/ssh/sshd_config file and set PermitRootLogin to "yes" first (see sshd_config(5)), but this is totally insecure. If you want to use RSA Version 1 or DSA Version 2 keys with sshd(8), you must edit the /etc/ssh/sshd_config file first and generate the keys using # /usr/bin/ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -N '' for RSA Version 1 (old), and # /usr/bin/ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -N '' for DSA Version 2 (extremely slow). These are however both totally in- secure. Upon successful login on the console, you may see the message "Don't login as root, use su". For security reasons, it is bad practice to log in as root during regular use and maintenance of the system. Instead, ad- ministrators are encouraged to add a "regular" user, add said user to the "wheel" group, then use the su(1) and sudo(8) commands when root privileges are required. This process is described in more detail later.
Change the password for the root user. (Note that throughout the documen- tation, the term "superuser" is a synonym for the root user.) Choose a password that has numbers, digits, and special characters (not space) as well as from the upper and lower case alphabet. Do not choose any word in any language. It is common for an intruder to use dictionary attacks. Type the command /usr/bin/passwd to change it. It is a good idea to always specify the full path name for both the passwd(1) and su(1) commands as this inhibits the possibility of files placed in your execution PATH for most shells. Furthermore, the superuser's PATH should never contain the current directory (".").
Check the system date with the date(1) command. If needed, change the date, and/or change the symbolic link of /etc/localtime to the correct time zone in the /usr/share/zoneinfo directory. It is highly recommended to use ntpd(8), or at least rdate(8), to set the system clock against a NTP or time server. In the default crontab, there is even an entry which does that automatically after installation, using the adjtime(2) system call, which is not suitable for setting the clock, only adjusting it by a few milliseconds, but can be used in a runlevel greater than 0 as well. Examples: Set the current date to January 27th, 1999 3:04pm: # date 199901271504 Set the time zone to Atlantic Standard Time: # ln -fs /usr/share/zoneinfo/Canada/Atlantic /etc/localtime
Use the hostname command to verify that the name of your machine is correct. See the man page for hostname(1) if it needs to be changed. You will also need to edit the /etc/myname file to have it stick around for the next reboot.
The first thing to do is an ifconfig -a to see if the network interfaces are properly configured. Correct by editing /etc/hostname.interface (where interface is the interface name, e.g., "le0") and then using ifconfig(8) to manually configure it if you do not wish to reboot. Read the hostname.if(5) man page for more information on the format of /etc/hostname.interface files. The default routes are also set in these files; if you come from OpenBSD you will have to merge your /etc/mygate into a /etc/hostname.interface file - preferably with interface being the one on which the route is set. The loopback interface will look something like: lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 32972 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 an Ethernet interface something like: le0: flags=9863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> inet 192.168.4.52 netmask 0xffffff00 broadcast 192.168.4.255 inet6 fe80::5ef0:f0f0%le0 prefixlen 64 scopeid 0x1 and a PPP interface something like: ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> inet 18.104.22.168 --> 22.214.171.124 netmask 0xffff0000 See netstart(8) for instructions on configuring multicast routing. See dhcp(8) for instructions on configuring interfaces with DHCP.
Issue a netstat -rn command. The output will look something like: Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 192.168.4.254 UGS 0 11098028 - le0 127 127.0.0.1 UGRS 0 0 - lo0 127.0.0.1 127.0.0.1 UH 3 24 - lo0 192.168.4 link#1 UC 0 0 - le0 192.168.4.52 8:0:20:73:b8:4a UHL 1 6707 - le0 192.168.4.254 0:60:3e:99:67:ea UHL 1 0 - le0 Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/96 ::1 UGRS 0 0 32972 lo0 => ::1 ::1 UH 4 0 32972 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 32972 lo0 fc80::/10 ::1 UGRS 0 0 32972 lo0 fe80::/10 ::1 UGRS 0 0 32972 lo0 fe80::%le0/64 link#1 UC 0 0 1500 le0 fe80::%lo0/64 fe80::1%lo0 U 0 0 32972 lo0 ff01::/32 ::1 U 0 0 32972 lo0 ff02::%le0/32 link#1 UC 0 0 1500 le0 ff02::%lo0/32 fe80::1%lo0 UC 0 0 32972 lo0 The default gateway address is stored in the hostname.if(5) file. If you need to edit this file, a painless way to reconfigure the network after- wards is route flush followed by a sh -x /etc/netstart command. You may manually configure using a series of route add and route delete commands (see route(8)). If you run dhclient(8) you will have to kill it by run- ning kill $(</var/run/dhclient.pid) after you flush the routes. If you wish to route packets between interfaces, add one or both of the following directives (depending on whether IPv4 or IPv6 routing is re- quired) to /etc/sysctl.conf: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Packets are not forwarded by default, due to RFC requirements.
Check that the disks are mounted correctly by comparing the /etc/fstab file against the output of the mount(8) and df(1) commands. Example: # cat /etc/fstab /dev/sd0a / ffs rw 1 1 /dev/sd0d /usr ffs rw,nodev 1 2 /dev/sd0e /var ffs rw,nodev,nosuid 1 3 /dev/sd0g /tmp ffs rw,nodev,nosuid 1 4 /dev/sd0h /home ffs rw,nodev,nosuid 1 5 # mount /dev/sd0a on / type ffs (local) /dev/sd0d on /usr type ffs (local, nodev) /dev/sd0e on /var type ffs (local, nodev, nosuid) /dev/sd0g on /tmp type ffs (local, nodev, nosuid) /dev/sd0h on /home type ffs (local, nodev, nosuid) # df Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 22311 14589 6606 69% / /dev/sd0d 203399 150221 43008 78% /usr /dev/sd0e 10447 682 9242 7% /var /dev/sd0g 18823 2 17879 0% /tmp /dev/sd0h 7519 5255 1888 74% /home # pstat -s Device 512-blocks Used Avail Capacity Priority swap_device 131072 84656 46416 65% 0 Edit /etc/fstab and use the mount(8) and umount(8) commands as appropri- ate. Refer to the above example and fstab(5) for information on the for- mat of this file. You may wish to do NFS partitions now too, or you can do them later.
You can use ps(1), netstat(1), and fstat(1) to check on running processes, network connections, and opened files, respectively. CHANGING /etc FILES The system should be usable now, but you may wish to do more customizing, such as adding users, etc. Many of the following sections may be skipped if you are not using that package (for example, skip the Sendmail section if you won't be using Sendmail (not recommended)). We suggest that you cd /etc and edit most of the files in that directory. Note that the /etc/motd file is modified by /etc/rc whenever the system is booted. To keep any custom message intact, ensure that you leave two blank lines at the top, or your message will be overwritten.
Add users. There is no adduser(8) script. You may use vipw(8) to add users to the /etc/passwd file and edit /etc/group by hand to add new groups. You may also wish to edit /etc/login.conf and tune some of the limits documented in login.conf(5). The manual page for su(1) tells you to make sure to put people in the 'wheel' group if they need root access. For example: wheel:*:0:root,myself
The /etc/rc.* scripts are invoked at boot time, after single user mode has exited, and at shutdown. The whole process is controlled, more or less, by the master script /etc/rc. This script should not be changed by administrators. /etc/rc is in turn influenced by the configuration variables present in /etc/rc.conf. Again this script should not be changed by administrators: site-specific changes should be made to (freshly created if necessary) /etc/rc.conf.local. Any commands which should be run before the system sets its secure level should be made to /etc/rc.securelevel, and commands to be run after the system sets its secure level should be made to /etc/rc.local. Commands to be run before system shutdown should be set in /etc/rc.shutdown. For more information about system startup/shutdown files, see rc(8), rc.conf(8), securelevel(7), and rc.shutdown(8). If you've installed X, you may want to turn on xdm(1), the X Display Manager. To do this, change the value of xdm_flags in /etc/rc.conf.local.
Some architectures permit keyboard type control. Use the kbd(8) command to change the keyboard encoding. kbd -l will list all available encod- ings. kbd xxx will select the xxx encoding. Store the encoding in /etc/kbdtype to make sure it is set automatically at boot time.
Edit /etc/printcap and /etc/hosts.lpd to get any printers set up. Consult lpd(8) and printcap(5) if needed.
Edit /etc/mail/aliases and set the three standard aliases to go to either a mailing list, or the system administrator. # Well-known aliases -- these should be filled in! root: sysadm manager: root dumper: root Run newaliases(8) after changes.
MirOS ships with a default /etc/mail/localhost.cf file that will work for simple installations; it was generated from openbsd-localhost.mc in /usr/share/sendmail/cf. Please see /usr/share/sendmail/README and /usr/share/doc/smm/08.sendmailop/op.me for information on generating your own sendmail configuration files. For the default installation, sendmail is configured to only accept connections from the local host and to not accept connections on any external interfaces. This makes it possible to send mail locally, but not receive mail from remote servers, which is ideal if you have one central incoming mail machine and several clients. To cause sendmail to accept external network connections, modify the sendmail_flags variable in /etc/rc.conf.local to use the /etc/mail/sendmail.cf file in accordance with the comments therein. This file was generated from openbsd-proto.mc. Note that sendmail now also listens on port 587 by default. This is to implement the RFC 2476 message submission protocol. You may disable this via the no_default_msa option in your sendmail .mc file. See /usr/share/sendmail/README for more information. The /etc/mail/localhost.cf file already has this disabled.
If you are using a name server from MirPorts (djbdns or BIND 9), check the /etc/resolv.conf file. It may look something like: domain nts.umn.edu nameserver 126.96.36.199 nameserver 188.8.131.52 search nts.umn.edu. umn.edu. lookup file bind If using a caching name server, add the line "nameserver 127.0.0.1" first. To get a local BIND instance to run, you will need to set named_flags in /etc/rc.conf.local. In this case, make sure that named(8) is running (otherwise there are long waits for resolver timeouts).
If this is a BOOTP server, edit /etc/dhcpd.conf as needed. dhcpd(8) will have to be turned on in rc.conf.local(8).
In order to make sure the system clock is synchronised to that of a pub- licly accessible NTP server, make sure that /etc/rc.conf.local contains the following: ntpd_flags="" See ntpd(8), rdate(8), and timed(8) for more information on setting the system's date.
If you are using ccd(4) concatenated disks, edit /etc/ccd.conf. Use the ccdconfig -U command to unload and the ccdconfig -C command to create tables internal to the kernel for the concatenated disks. You then mount(8), umount(8), and edit /etc/fstab as needed.
If this is a DHCP server, edit /etc/dhcpd.conf and /etc/dhcpd.interfaces as needed. You will have to make sure /etc/rc.conf.local has: dhcpd_flags="" or run dhcpd(8) manually.
Edit /etc/rbootd.conf if needed for remote booting. If you do not have HP computers doing remote booting, do not enable this.
If you are going to use kerberos(8) for authentication, and you already have a Kerberos master, change directory to /etc/kerberosV and configure. Remember to get a srvtab from the master so that the remote commands work.
If this is an NFS server make sure /etc/rc.conf.local has: nfs_server=YES Edit /etc/exports and get it correct. It is probably easier to reboot than to get the daemons running manually, but you can get the order correct by looking at /etc/rc.
Several services depend on the RPC portmapper, portmap(8), being running for proper operation. This includes NFS exports, among other services. To get the RPC portmapper to start automatically on boot, you will need to have this line in /etc/rc.conf.local: portmap=YES
Look at and possibly edit the /etc/daily, /etc/weekly, and /etc/monthly scripts. Your site specific things should go into /etc/daily.local, /etc/weekly.local, and /etc/monthly.local. These scripts have been limited so as to keep the system running without filling up disk space from normal running processes and database updates. (You probably do not need to understand them.) The /altroot filesystem can optionally be used to provide a backup of the root filesystem on a daily basis. To take advantage of this, you must have an entry in /etc/fstab with "xx" for the mount option: /dev/wd0j /altroot ffs xx 0 0 and you must add a line to root's crontab(5): ROOTBACKUP=1 so that the /etc/daily script will make a daily backup of the root filesystem.
You might wish to tighten up security more by editing /etc/fbtab as when installing X. In /etc/inetd.conf comment out any extra entries you do not need, and only add things that are really needed.
Look at the other files in /etc and edit them as needed. (Do not edit files ending in .db - like pwd.db, spwd.db, nor localtime, nor rmt, nor any directories.) Many files - for example, /etc/mk.conf, /etc/profile, /etc/rc.conf, /etc/changelist, and others - provide the ability to have them unchanged and place the changes into the file with .local added. Example: # echo 'rdate_flags="-n ntp0.nl.net"' >>/etc/rc.conf.local It is recommended to use rcs(1) for versioning files in /etc, especially those not in any changelist.
Check what is running by typing crontab -l as root and see if anything unexpected is present. Do you need anything else? Do you wish to change things? For example, if you do not like root getting standard output of the daily scripts, and want only the security scripts that are mailed internally, you can type crontab -e and change some of the lines to read: 30 1 * * * /bin/mksh /etc/daily >/var/log/daily.out 2>&1 30 3 * * 6 /bin/mksh /etc/weekly >/var/log/weekly.out 2>&1 30 5 1 * * /bin/mksh /etc/monthly >/var/log/monthly.out 2>&1 See crontab(5).
After the first night's security run, change ownerships and permissions on files, directories, and devices; root should have received mail with subject: "<hostname> daily insecurity output.". This mail contains a set of security recommendations, presented as a list looking like this: var/mail: permissions (0755, 0775) etc/daily: user (0, 3) The best bet is to follow the advice in that list. The recommended set- ting is the first item in parentheses, while the current setting is the second one. This list is generated by mtree(8) using /etc/mtree/special. Use chmod(1), chgrp(1), and chown(8) as needed.
Install your own packages. See ports(7) and packages(7) for more details. Copy vendor binaries and install them. You will need to install any shared libraries, etc. (Hint: man -k compat to find out how to install and use compatibility mode.) There is also other third-party software that is available in source form only, either because it has not been ported to MirOS yet, or because licensing restrictions make binary redistribution impossible. Sometimes checking the mailing lists for past problems that people have encountered will result in a fix posted.
Note: The standard MirOS kernel configuration (GENERIC) is suitable for most purposes. Use of an alternative kernel configuration is not recom- mended. First, review the system message buffer using the dmesg(8) command to find out information on your system's devices as probed by the kernel at boot. In particular, note which devices were not configured. This infor- mation will prove useful when editing kernel configuration files. To compile a kernel inside a writable source tree, do the following: # cd /usr/src/sys/arch/somearch/conf # vi SOMEFILE (to make any changes) # config SOMEFILE # cd ../compile/SOMEFILE # make where somearch is the architecture (e.g. i386), and SOMEFILE should be a name indicative of a particular configuration (often that of the host- name). You can also do a make depend so that you will have dependencies there the next time you do a compile. If you are building your kernel again, before you do a make you should do a make depend after making changes (including updates or patches) to your kernel source, or a make clean after making changes to your kernel op- tions. After either of these two methods, you can place the new kernel (called bsd) in / (i.e. /bsd) and the system will boot it next time. Most people save their backup kernels as /bsd.1, /bsd.2, etc. It is not always necessary to recompile the kernel if only configuration changes are required. With config(8), you can change the device confi- guration in the kernel file directly: # config -e -o bsd.new /bsd OpenBSD 2.7-beta (GENERIC.rz0) #0: Mon Oct 4 03:57:22 MEST 1999 root@winona:/usr/src/sys/arch/pmax/compile/GENERIC.rz0 Enter 'help' for information ukc> Additionally, you can permanently save the changes made with UKC during boot time in the kernel image.
aliases(5), bootpd(8), bootptab(5), ccd(4), ccdconfig(8), chgrp(1), chmod(1), chown(8), config(8), crontab(1), crontab(5), date(1), df(1), dhclient(8), dhcp(8), dhcpd(8), dmesg(8), fstat(1), hostname(1), ls(1), make(1), man(1), netstat(1), passwd(1), pkg_add(1), ps(1), ssh(1), su(1), xdm(1), ccd(4), aliases(5), crontab(5), dhcpd.conf(5), exports(5), fbtab(5), fstab(5), ftpd(8), group(5), hostname(1), hostname(7), hostname.if(5), login.conf(5), passwd(5), printcap(5), resolv.conf(5), ssh_config(5), sysctl.conf(5), hier(7), hostname(7), packages(7), ports(7), ccdconfig(8), chown(8), config(8), dhclient(8), dhcp(8), dhcpd(8), dmesg(8), ftpd(8), ifconfig(8), inetd(8), kbd(8), lpd(8), ls(1), make(1), man(1), mount(8), mtree(8), netstart(8), netstat(1), newaliases(8), ntpd(8), portmap(8), ports(7), printcap(5), rbootd(8), rc(8), rdate(8), rmt(8), route(8), sendmail(8), sudo(8), sysctl(8), timed(8), umount(8), vipw(8), xdm(1)
This document first appeared in OpenBSD 2.2.
This document is totally out of date. MirOS BSD #10-current April 19, 2006 8
Generated on 2013-04-27 00:20:00 by $MirOS: src/scripts/roff2htm,v 1.77 2013/01/01 20:49:09 tg Exp $
These manual pages and other documentation are copyrighted by their respective writers;
their source is available at our CVSweb,
AnonCVS, and other mirrors. The rest is Copyright © 2002‒2013 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.
This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.