afterboot man page on OpenBSD

Man page or keyword search:  
man Server   11362 pages
apropos Keyword Search (all sections)
Output format
OpenBSD logo
[printable version]

AFTERBOOT(8)		OpenBSD System Manager's Manual		  AFTERBOOT(8)

NAME
     afterboot - things to check after the first complete boot

DESCRIPTION
   Starting out
     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 OpenBSD if they get
     used to using the high quality manual pages.

   Errata
     By the time that you have installed your system, it is quite likely that
     bugs in the release have been found.  Any security or reliability fixes
     can be found at http://www.openbsd.org/errata.html.  It is recommended to
     check this page regularly.

   Login
     Log in on the console, or over the network using ssh(1).  For security
     reasons, it is bad practice to log in as root during regular use and
     maintenance of the system.	 Instead, administrators 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.

     The installation process provides an option to set up a user account.  By
     default, accounts created via this method are automatically added to the
     ``wheel'' group.  If that option was not used, see the paragraph Add new
     users below.

     To deny root logins over the network, edit the /etc/ssh/sshd_config file
     and set PermitRootLogin to ``no'' (see sshd_config(5)).

   Root password
     Change the password for the root user.  (Note that throughout the
     documentation, the term ``superuser'' is a synonym for the root user.)
     Choose a password that has 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/sudo /usr/bin/passwd root

     to change it.

     It is a good idea to always specify the full path name for the passwd(1),
     su(1) and sudo(8) commands as this inhibits the possibility of rogue
     files placed in your PATH being executed for most shells.	Furthermore,
     the superuser's PATH should never contain the current directory (``.'').

   System date
     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.

     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

   Check hostname
     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.

   Verify network interface configuration
     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 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 203.3.131.108 --> 198.181.0.253 netmask 0xffff0000

     See netstart(8) for instructions on configuring multicast routing.

     See dhcp(8) for instructions on configuring interfaces with DHCP.

   Check routing tables
     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 /etc/mygate file.  If you
     need to edit this file, a painless way to reconfigure the network
     afterwards is route flush followed by a sh -x /etc/netstart command.  Or,
     you may prefer to 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 running pkill dhclient 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
     required) 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 DNS
     Use host(1) or dig(1) to check that domain name resolution is working
     properly.

     Most likely, the IP address of at least one domain name server was added
     to resolv.conf(5) while installing the system.  If DHCP is in use, it
     will overwrite /etc/resolv.conf every time dhclient-script(8) is run but
     /etc/resolv.conf.tail can be used to add options and extra name servers
     to those received dynamically.

     A hosts(5) file can be used if there is a need for system specific name
     resolution entries.

   Check disk mounts
     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
     appropriate.  Refer to the above example and fstab(5) for information on
     the format of this file.

     You may wish to do NFS partitions now too, or you can do them later.

   Check the running system
     You can use ps(1), netstat(1), and fstat(1) to check on running
     processes, network connections, and opened files, respectively.

FURTHER CHANGES
     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.	 We suggest that you cd /etc and edit
     any files in that directory as necessary.

     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 new users
     Add users.	 There is an 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
     (non-Kerberos).  For example:

	   wheel:*:0:root,myself

     Follow instructions for login_krb5(8) if using Kerberos for
     authentication.

   System command scripts
     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.

   Set keyboard type
     Some architectures permit keyboard type control.  Use the kbd(8) command
     to change the keyboard encoding.  kbd -l will list all available
     encodings.	 kbd xxx will select the xxx encoding.	Store the encoding in
     /etc/kbdtype to make sure it is set automatically at boot time.

   Printers
     Edit /etc/printcap and /etc/hosts.lpd to get any printers set up.
     Consult lpd(8) and printcap(5) if needed.

   Mail aliases
     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.

   Sendmail
     The default mail agent on OpenBSD is sendmail(8).	Details on how to
     configure an alternative mailer are documented in mailer.conf(5).

     OpenBSD 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 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.

   Daily, weekly, monthly scripts
     Review daily(8) to understand what the periodic system maintenance
     scripts do and how to customize them: For example, to enable ROOTBACKUP
     or to disable VERBOSESTATUS, or to add local maintenance code to
     /etc/daily.local, /etc/weekly.local, or /etc/monthly.local.

   Tighten up security
     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.

   Other files in /etc
     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.)

   Crontab (background running processes)
     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?  See crontab(5).

   Next day cleanup
     After the first night's security(8) run, change ownerships and
     permissions on files, directories, and devices; root may have received
     mail with subject: "<hostname> daily insecurity output".  This mail
     contains a set of security recommendations, presented as a list looking
     something 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
     setting 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.

   Daemons
     Enable/disable any daemon processes as necessary.	intro(8) contains a
     comprehensive guide to the various daemons available on the OpenBSD
     system.

   Packages
     Install your own packages.	 The OpenBSD ports collection includes a large
     set of third-party software.  A lot of it is available as binary packages
     that you can download from ftp://ftp.openbsd.org or a mirror, and install
     using pkg_add(1).	See ports(7) and packages(7) for more details.

     Copy vendor binaries and install them.  You will need to install any
     shared libraries, etc.  Read the compat_* man pages 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 OpenBSD 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.

   Compiling a kernel
     Information on building and modifying kernels is contained within
     config(8).

SEE ALSO
     ksh(1), man(1), pkg_add(1), ps(1), vi(1), hier(7), config(8), dmesg(8),
     ifconfig(8), intro(8), sudo(8), sysctl(8)

HISTORY
     This document first appeared in OpenBSD 2.2.

OpenBSD 4.9		       February 16, 2011		   OpenBSD 4.9
[top]

List of man pages available for OpenBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net