From 253e67c8b3a72b3a4757fdbc5845297628db0a4a Mon Sep 17 00:00:00 2001 From: Jacob McDonnell Date: Sat, 25 Apr 2026 19:55:15 -0400 Subject: docs: Added All NetBSD Manuals --- static/netbsd/man5/RELEASE_NOTES-2.5 | 376 + static/netbsd/man5/RELEASE_NOTES-3.5 | 157 + static/netbsd/man5/access.5 | 486 + static/netbsd/man5/aliases.5 | 249 + static/netbsd/man5/altq.conf.5 | 1344 +++ static/netbsd/man5/amd.conf.5 | 788 ++ static/netbsd/man5/atf-formats.5 | 231 + static/netbsd/man5/auto_master.5 | 401 + static/netbsd/man5/bad.include-toplevel.5 | 8 + static/netbsd/man5/blocklistd.conf.5 | 237 + static/netbsd/man5/body_checks.5 | 3 + static/netbsd/man5/bootparams.5 | 100 + static/netbsd/man5/bootptab.5 | 408 + static/netbsd/man5/bounce.5 | 237 + static/netbsd/man5/canonical.5 | 304 + static/netbsd/man5/ccd.conf.5 | 109 + static/netbsd/man5/cdb.5 | 104 + static/netbsd/man5/cidr_table.5 | 202 + static/netbsd/man5/config.5 | 987 ++ static/netbsd/man5/config.samples.5 | 266 + static/netbsd/man5/cpio.5 | 389 + static/netbsd/man5/crontab.5 | 421 + static/netbsd/man5/ctf.5 | 1243 +++ static/netbsd/man5/cvs.5 | 330 + static/netbsd/man5/dhclient.conf.5 | 788 ++ static/netbsd/man5/dhclient.leases.5 | 52 + static/netbsd/man5/dhcp-eval.5 | 484 + static/netbsd/man5/dhcp-options.5 | 1576 +++ static/netbsd/man5/dhcpcd.conf.5 | 1091 ++ static/netbsd/man5/dhcpd.conf.5 | 3672 +++++++ static/netbsd/man5/dhcpd.leases.5 | 399 + static/netbsd/man5/disklabel.5 | 439 + static/netbsd/man5/dm.conf.5 | 114 + static/netbsd/man5/editrc.5 | 326 + static/netbsd/man5/envsys.conf.5 | 459 + static/netbsd/man5/example.5 | 26 + static/netbsd/man5/exports.5 | 488 + static/netbsd/man5/fips_config.5 | 247 + static/netbsd/man5/ftpd.conf.5 | 738 ++ static/netbsd/man5/ftpusers.5 | 179 + static/netbsd/man5/gdbinit.5 | 222 + static/netbsd/man5/generic.5 | 276 + static/netbsd/man5/gettytab.5 | 447 + static/netbsd/man5/header_checks.5 | 524 + static/netbsd/man5/hostapd.conf.5 | 213 + static/netbsd/man5/hosts_access.5 | 424 + static/netbsd/man5/hosts_options.5 | 189 + static/netbsd/man5/info.5 | 64 + static/netbsd/man5/ipf.5 | 1697 +++ static/netbsd/man5/ipfilter.5 | 12 + static/netbsd/man5/ipmon.5 | 226 + static/netbsd/man5/ipnat.5 | 730 ++ static/netbsd/man5/ippool.5 | 390 + static/netbsd/man5/ipscan.5 | 52 + static/netbsd/man5/ipsend.5 | 403 + static/netbsd/man5/ipv6.5 | 14 + static/netbsd/man5/irs.conf.5 | 171 + static/netbsd/man5/krb5.conf.5 | 840 ++ static/netbsd/man5/kyua-tester-list.5 | 103 + static/netbsd/man5/kyua-tester-result.5 | 66 + static/netbsd/man5/ldap.conf.5 | 532 + static/netbsd/man5/ldap_table.5 | 757 ++ static/netbsd/man5/ldif.5 | 277 + static/netbsd/man5/ldpd.conf.5 | 127 + static/netbsd/man5/libarchive-formats.5 | 478 + static/netbsd/man5/lloadd.conf.5 | 1001 ++ static/netbsd/man5/lmdb_table.5 | 144 + static/netbsd/man5/login.access.5 | 61 + static/netbsd/man5/lvm.conf.5 | 397 + static/netbsd/man5/magic.5 | 832 ++ static/netbsd/man5/mailer.conf.5 | 141 + static/netbsd/man5/man.conf.5 | 132 + static/netbsd/man5/mandoc.db.5 | 228 + static/netbsd/man5/master.5 | 292 + static/netbsd/man5/mech.5 | 96 + static/netbsd/man5/memcache_table.5 | 261 + static/netbsd/man5/moduli.5 | 166 + static/netbsd/man5/mongodb_table.5 | 261 + static/netbsd/man5/mtree.5 | 323 + static/netbsd/man5/mysql_table.5 | 471 + static/netbsd/man5/netid.5 | 74 + static/netbsd/man5/nicknames.5 | 90 + static/netbsd/man5/nisplus_table.5 | 108 + static/netbsd/man5/npf.conf.5 | 846 ++ static/netbsd/man5/openssl-config.5 | 654 ++ static/netbsd/man5/openssl.cnf.5 | 536 + static/netbsd/man5/openssl_config.5 | 606 ++ static/netbsd/man5/p.5 | 3 + static/netbsd/man5/pam.conf.5 | 229 + static/netbsd/man5/pcre_table.5 | 303 + static/netbsd/man5/pf.boot.conf.5 | 72 + static/netbsd/man5/pf.conf.5 | 2988 ++++++ static/netbsd/man5/pf.os.5 | 228 + static/netbsd/man5/pgsql_table.5 | 397 + static/netbsd/man5/pkg_summary.5 | 138 + static/netbsd/man5/postconf.5 | 15905 ++++++++++++++++++++++++++++ static/netbsd/man5/postfix-wrapper.5 | 319 + static/netbsd/man5/racoon.conf.5 | 1587 +++ static/netbsd/man5/radius.conf.5 | 185 + static/netbsd/man5/rcsfile.5 | 428 + static/netbsd/man5/regexp_table.5 | 266 + static/netbsd/man5/relocated.5 | 197 + static/netbsd/man5/resolver.5 | 239 + static/netbsd/man5/rtadvd.conf.5 | 495 + static/netbsd/man5/slapd-asyncmeta.5 | 522 + static/netbsd/man5/slapd-bdb.5 | 293 + static/netbsd/man5/slapd-config.5 | 2317 ++++ static/netbsd/man5/slapd-dnssrv.5 | 49 + static/netbsd/man5/slapd-ldap.5 | 713 ++ static/netbsd/man5/slapd-ldbm.5 | 27 + static/netbsd/man5/slapd-ldif.5 | 54 + static/netbsd/man5/slapd-mdb.5 | 241 + static/netbsd/man5/slapd-meta.5 | 1378 +++ static/netbsd/man5/slapd-monitor.5 | 126 + static/netbsd/man5/slapd-ndb.5 | 127 + static/netbsd/man5/slapd-null.5 | 72 + static/netbsd/man5/slapd-passwd.5 | 56 + static/netbsd/man5/slapd-perl.5 | 199 + static/netbsd/man5/slapd-pw-pbkdf2.5 | 112 + static/netbsd/man5/slapd-pw-radius.5 | 110 + static/netbsd/man5/slapd-pw-sha2.5 | 118 + static/netbsd/man5/slapd-relay.5 | 207 + static/netbsd/man5/slapd-shell.5 | 238 + static/netbsd/man5/slapd-sock.5 | 344 + static/netbsd/man5/slapd-sql.5 | 699 ++ static/netbsd/man5/slapd-wt.5 | 97 + static/netbsd/man5/slapd.access.5 | 1212 +++ static/netbsd/man5/slapd.backends.5 | 133 + static/netbsd/man5/slapd.conf.5 | 2168 ++++ static/netbsd/man5/slapd.overlays.5 | 204 + static/netbsd/man5/slapd.plugin.5 | 124 + static/netbsd/man5/slapm-ppm.5 | 353 + static/netbsd/man5/slapo-accesslog.5 | 514 + static/netbsd/man5/slapo-adremap.5 | 104 + static/netbsd/man5/slapo-alias.5 | 121 + static/netbsd/man5/slapo-allop.5 | 63 + static/netbsd/man5/slapo-auditlog.5 | 98 + static/netbsd/man5/slapo-autoca.5 | 120 + static/netbsd/man5/slapo-autogroup.5 | 119 + static/netbsd/man5/slapo-chain.5 | 152 + static/netbsd/man5/slapo-ciboolean.5 | 75 + static/netbsd/man5/slapo-cloak.5 | 82 + static/netbsd/man5/slapo-collect.5 | 52 + static/netbsd/man5/slapo-constraint.5 | 155 + static/netbsd/man5/slapo-datamorph.5 | 338 + static/netbsd/man5/slapo-dds.5 | 271 + static/netbsd/man5/slapo-deref.5 | 80 + static/netbsd/man5/slapo-dyngroup.5 | 58 + static/netbsd/man5/slapo-dynlist.5 | 323 + static/netbsd/man5/slapo-emptyds.5 | 68 + static/netbsd/man5/slapo-homedir.5 | 157 + static/netbsd/man5/slapo-lastbind.5 | 118 + static/netbsd/man5/slapo-lastmod.5 | 185 + static/netbsd/man5/slapo-memberof.5 | 159 + static/netbsd/man5/slapo-nestgroup.5 | 92 + static/netbsd/man5/slapo-nops.5 | 32 + static/netbsd/man5/slapo-nssov.5 | 316 + static/netbsd/man5/slapo-otp.5 | 138 + static/netbsd/man5/slapo-pbind.5 | 61 + static/netbsd/man5/slapo-pcache.5 | 330 + static/netbsd/man5/slapo-ppolicy.5 | 1093 ++ static/netbsd/man5/slapo-rbac.5 | 157 + static/netbsd/man5/slapo-refint.5 | 78 + static/netbsd/man5/slapo-remoteauth.5 | 160 + static/netbsd/man5/slapo-retcode.5 | 257 + static/netbsd/man5/slapo-rwm.5 | 708 ++ static/netbsd/man5/slapo-smbk5pwd.5 | 177 + static/netbsd/man5/slapo-sssvlv.5 | 57 + static/netbsd/man5/slapo-syncprov.5 | 81 + static/netbsd/man5/slapo-totp.5 | 109 + static/netbsd/man5/slapo-translucent.5 | 133 + static/netbsd/man5/slapo-unique.5 | 188 + static/netbsd/man5/slapo-valsort.5 | 97 + static/netbsd/man5/slapo-variant.5 | 472 + static/netbsd/man5/slappw-argon2.5 | 131 + static/netbsd/man5/smp.5 | 23 + static/netbsd/man5/socketmap_table.5 | 151 + static/netbsd/man5/sqlite_table.5 | 286 + static/netbsd/man5/ssh_config.5 | 2487 +++++ static/netbsd/man5/sshd_config.5 | 2347 ++++ static/netbsd/man5/syslog.conf.5 | 707 ++ static/netbsd/man5/tar.5 | 947 ++ static/netbsd/man5/targets.5 | 179 + static/netbsd/man5/tcp_table.5 | 135 + static/netbsd/man5/test_ldnsrr.5 | 178 + static/netbsd/man5/test_packets.5 | 70 + static/netbsd/man5/test_signatures.5 | 48 + static/netbsd/man5/texinfo.5 | 53 + static/netbsd/man5/traffic.expect.5 | 9 + static/netbsd/man5/transport.5 | 337 + static/netbsd/man5/ttys.5 | 246 + static/netbsd/man5/tzfile.5 | 552 + static/netbsd/man5/usermgmt.conf.5 | 171 + static/netbsd/man5/uuencode.5 | 145 + static/netbsd/man5/vgrindefs.5 | 158 + static/netbsd/man5/virtual.5 | 346 + static/netbsd/man5/wpa_supplicant.conf.5 | 225 + static/netbsd/man5/wsmoused.conf.5 | 201 + static/netbsd/man5/x509v3_config.5 | 698 ++ 199 files changed, 92662 insertions(+) create mode 100644 static/netbsd/man5/RELEASE_NOTES-2.5 create mode 100644 static/netbsd/man5/RELEASE_NOTES-3.5 create mode 100644 static/netbsd/man5/access.5 create mode 100644 static/netbsd/man5/aliases.5 create mode 100644 static/netbsd/man5/altq.conf.5 create mode 100644 static/netbsd/man5/amd.conf.5 create mode 100644 static/netbsd/man5/atf-formats.5 create mode 100644 static/netbsd/man5/auto_master.5 create mode 100644 static/netbsd/man5/bad.include-toplevel.5 create mode 100644 static/netbsd/man5/blocklistd.conf.5 create mode 100644 static/netbsd/man5/body_checks.5 create mode 100644 static/netbsd/man5/bootparams.5 create mode 100644 static/netbsd/man5/bootptab.5 create mode 100644 static/netbsd/man5/bounce.5 create mode 100644 static/netbsd/man5/canonical.5 create mode 100644 static/netbsd/man5/ccd.conf.5 create mode 100644 static/netbsd/man5/cdb.5 create mode 100644 static/netbsd/man5/cidr_table.5 create mode 100644 static/netbsd/man5/config.5 create mode 100644 static/netbsd/man5/config.samples.5 create mode 100644 static/netbsd/man5/cpio.5 create mode 100644 static/netbsd/man5/crontab.5 create mode 100644 static/netbsd/man5/ctf.5 create mode 100644 static/netbsd/man5/cvs.5 create mode 100644 static/netbsd/man5/dhclient.conf.5 create mode 100644 static/netbsd/man5/dhclient.leases.5 create mode 100644 static/netbsd/man5/dhcp-eval.5 create mode 100644 static/netbsd/man5/dhcp-options.5 create mode 100644 static/netbsd/man5/dhcpcd.conf.5 create mode 100644 static/netbsd/man5/dhcpd.conf.5 create mode 100644 static/netbsd/man5/dhcpd.leases.5 create mode 100644 static/netbsd/man5/disklabel.5 create mode 100644 static/netbsd/man5/dm.conf.5 create mode 100644 static/netbsd/man5/editrc.5 create mode 100644 static/netbsd/man5/envsys.conf.5 create mode 100644 static/netbsd/man5/example.5 create mode 100644 static/netbsd/man5/exports.5 create mode 100644 static/netbsd/man5/fips_config.5 create mode 100644 static/netbsd/man5/ftpd.conf.5 create mode 100644 static/netbsd/man5/ftpusers.5 create mode 100644 static/netbsd/man5/gdbinit.5 create mode 100644 static/netbsd/man5/generic.5 create mode 100644 static/netbsd/man5/gettytab.5 create mode 100644 static/netbsd/man5/header_checks.5 create mode 100644 static/netbsd/man5/hostapd.conf.5 create mode 100644 static/netbsd/man5/hosts_access.5 create mode 100644 static/netbsd/man5/hosts_options.5 create mode 100644 static/netbsd/man5/info.5 create mode 100644 static/netbsd/man5/ipf.5 create mode 100644 static/netbsd/man5/ipfilter.5 create mode 100644 static/netbsd/man5/ipmon.5 create mode 100644 static/netbsd/man5/ipnat.5 create mode 100644 static/netbsd/man5/ippool.5 create mode 100644 static/netbsd/man5/ipscan.5 create mode 100644 static/netbsd/man5/ipsend.5 create mode 100644 static/netbsd/man5/ipv6.5 create mode 100644 static/netbsd/man5/irs.conf.5 create mode 100644 static/netbsd/man5/krb5.conf.5 create mode 100644 static/netbsd/man5/kyua-tester-list.5 create mode 100644 static/netbsd/man5/kyua-tester-result.5 create mode 100644 static/netbsd/man5/ldap.conf.5 create mode 100644 static/netbsd/man5/ldap_table.5 create mode 100644 static/netbsd/man5/ldif.5 create mode 100644 static/netbsd/man5/ldpd.conf.5 create mode 100644 static/netbsd/man5/libarchive-formats.5 create mode 100644 static/netbsd/man5/lloadd.conf.5 create mode 100644 static/netbsd/man5/lmdb_table.5 create mode 100644 static/netbsd/man5/login.access.5 create mode 100644 static/netbsd/man5/lvm.conf.5 create mode 100644 static/netbsd/man5/magic.5 create mode 100644 static/netbsd/man5/mailer.conf.5 create mode 100644 static/netbsd/man5/man.conf.5 create mode 100644 static/netbsd/man5/mandoc.db.5 create mode 100644 static/netbsd/man5/master.5 create mode 100644 static/netbsd/man5/mech.5 create mode 100644 static/netbsd/man5/memcache_table.5 create mode 100644 static/netbsd/man5/moduli.5 create mode 100644 static/netbsd/man5/mongodb_table.5 create mode 100644 static/netbsd/man5/mtree.5 create mode 100644 static/netbsd/man5/mysql_table.5 create mode 100644 static/netbsd/man5/netid.5 create mode 100644 static/netbsd/man5/nicknames.5 create mode 100644 static/netbsd/man5/nisplus_table.5 create mode 100644 static/netbsd/man5/npf.conf.5 create mode 100644 static/netbsd/man5/openssl-config.5 create mode 100644 static/netbsd/man5/openssl.cnf.5 create mode 100644 static/netbsd/man5/openssl_config.5 create mode 100644 static/netbsd/man5/p.5 create mode 100644 static/netbsd/man5/pam.conf.5 create mode 100644 static/netbsd/man5/pcre_table.5 create mode 100644 static/netbsd/man5/pf.boot.conf.5 create mode 100644 static/netbsd/man5/pf.conf.5 create mode 100644 static/netbsd/man5/pf.os.5 create mode 100644 static/netbsd/man5/pgsql_table.5 create mode 100644 static/netbsd/man5/pkg_summary.5 create mode 100644 static/netbsd/man5/postconf.5 create mode 100644 static/netbsd/man5/postfix-wrapper.5 create mode 100644 static/netbsd/man5/racoon.conf.5 create mode 100644 static/netbsd/man5/radius.conf.5 create mode 100644 static/netbsd/man5/rcsfile.5 create mode 100644 static/netbsd/man5/regexp_table.5 create mode 100644 static/netbsd/man5/relocated.5 create mode 100644 static/netbsd/man5/resolver.5 create mode 100644 static/netbsd/man5/rtadvd.conf.5 create mode 100644 static/netbsd/man5/slapd-asyncmeta.5 create mode 100644 static/netbsd/man5/slapd-bdb.5 create mode 100644 static/netbsd/man5/slapd-config.5 create mode 100644 static/netbsd/man5/slapd-dnssrv.5 create mode 100644 static/netbsd/man5/slapd-ldap.5 create mode 100644 static/netbsd/man5/slapd-ldbm.5 create mode 100644 static/netbsd/man5/slapd-ldif.5 create mode 100644 static/netbsd/man5/slapd-mdb.5 create mode 100644 static/netbsd/man5/slapd-meta.5 create mode 100644 static/netbsd/man5/slapd-monitor.5 create mode 100644 static/netbsd/man5/slapd-ndb.5 create mode 100644 static/netbsd/man5/slapd-null.5 create mode 100644 static/netbsd/man5/slapd-passwd.5 create mode 100644 static/netbsd/man5/slapd-perl.5 create mode 100644 static/netbsd/man5/slapd-pw-pbkdf2.5 create mode 100644 static/netbsd/man5/slapd-pw-radius.5 create mode 100644 static/netbsd/man5/slapd-pw-sha2.5 create mode 100644 static/netbsd/man5/slapd-relay.5 create mode 100644 static/netbsd/man5/slapd-shell.5 create mode 100644 static/netbsd/man5/slapd-sock.5 create mode 100644 static/netbsd/man5/slapd-sql.5 create mode 100644 static/netbsd/man5/slapd-wt.5 create mode 100644 static/netbsd/man5/slapd.access.5 create mode 100644 static/netbsd/man5/slapd.backends.5 create mode 100644 static/netbsd/man5/slapd.conf.5 create mode 100644 static/netbsd/man5/slapd.overlays.5 create mode 100644 static/netbsd/man5/slapd.plugin.5 create mode 100644 static/netbsd/man5/slapm-ppm.5 create mode 100644 static/netbsd/man5/slapo-accesslog.5 create mode 100644 static/netbsd/man5/slapo-adremap.5 create mode 100644 static/netbsd/man5/slapo-alias.5 create mode 100644 static/netbsd/man5/slapo-allop.5 create mode 100644 static/netbsd/man5/slapo-auditlog.5 create mode 100644 static/netbsd/man5/slapo-autoca.5 create mode 100644 static/netbsd/man5/slapo-autogroup.5 create mode 100644 static/netbsd/man5/slapo-chain.5 create mode 100644 static/netbsd/man5/slapo-ciboolean.5 create mode 100644 static/netbsd/man5/slapo-cloak.5 create mode 100644 static/netbsd/man5/slapo-collect.5 create mode 100644 static/netbsd/man5/slapo-constraint.5 create mode 100644 static/netbsd/man5/slapo-datamorph.5 create mode 100644 static/netbsd/man5/slapo-dds.5 create mode 100644 static/netbsd/man5/slapo-deref.5 create mode 100644 static/netbsd/man5/slapo-dyngroup.5 create mode 100644 static/netbsd/man5/slapo-dynlist.5 create mode 100644 static/netbsd/man5/slapo-emptyds.5 create mode 100644 static/netbsd/man5/slapo-homedir.5 create mode 100644 static/netbsd/man5/slapo-lastbind.5 create mode 100644 static/netbsd/man5/slapo-lastmod.5 create mode 100644 static/netbsd/man5/slapo-memberof.5 create mode 100644 static/netbsd/man5/slapo-nestgroup.5 create mode 100644 static/netbsd/man5/slapo-nops.5 create mode 100644 static/netbsd/man5/slapo-nssov.5 create mode 100644 static/netbsd/man5/slapo-otp.5 create mode 100644 static/netbsd/man5/slapo-pbind.5 create mode 100644 static/netbsd/man5/slapo-pcache.5 create mode 100644 static/netbsd/man5/slapo-ppolicy.5 create mode 100644 static/netbsd/man5/slapo-rbac.5 create mode 100644 static/netbsd/man5/slapo-refint.5 create mode 100644 static/netbsd/man5/slapo-remoteauth.5 create mode 100644 static/netbsd/man5/slapo-retcode.5 create mode 100644 static/netbsd/man5/slapo-rwm.5 create mode 100644 static/netbsd/man5/slapo-smbk5pwd.5 create mode 100644 static/netbsd/man5/slapo-sssvlv.5 create mode 100644 static/netbsd/man5/slapo-syncprov.5 create mode 100644 static/netbsd/man5/slapo-totp.5 create mode 100644 static/netbsd/man5/slapo-translucent.5 create mode 100644 static/netbsd/man5/slapo-unique.5 create mode 100644 static/netbsd/man5/slapo-valsort.5 create mode 100644 static/netbsd/man5/slapo-variant.5 create mode 100644 static/netbsd/man5/slappw-argon2.5 create mode 100644 static/netbsd/man5/smp.5 create mode 100644 static/netbsd/man5/socketmap_table.5 create mode 100644 static/netbsd/man5/sqlite_table.5 create mode 100644 static/netbsd/man5/ssh_config.5 create mode 100644 static/netbsd/man5/sshd_config.5 create mode 100644 static/netbsd/man5/syslog.conf.5 create mode 100644 static/netbsd/man5/tar.5 create mode 100644 static/netbsd/man5/targets.5 create mode 100644 static/netbsd/man5/tcp_table.5 create mode 100644 static/netbsd/man5/test_ldnsrr.5 create mode 100644 static/netbsd/man5/test_packets.5 create mode 100644 static/netbsd/man5/test_signatures.5 create mode 100644 static/netbsd/man5/texinfo.5 create mode 100644 static/netbsd/man5/traffic.expect.5 create mode 100644 static/netbsd/man5/transport.5 create mode 100644 static/netbsd/man5/ttys.5 create mode 100644 static/netbsd/man5/tzfile.5 create mode 100644 static/netbsd/man5/usermgmt.conf.5 create mode 100644 static/netbsd/man5/uuencode.5 create mode 100644 static/netbsd/man5/vgrindefs.5 create mode 100644 static/netbsd/man5/virtual.5 create mode 100644 static/netbsd/man5/wpa_supplicant.conf.5 create mode 100644 static/netbsd/man5/wsmoused.conf.5 create mode 100644 static/netbsd/man5/x509v3_config.5 (limited to 'static/netbsd/man5') diff --git a/static/netbsd/man5/RELEASE_NOTES-2.5 b/static/netbsd/man5/RELEASE_NOTES-2.5 new file mode 100644 index 00000000..f560d3b5 --- /dev/null +++ b/static/netbsd/man5/RELEASE_NOTES-2.5 @@ -0,0 +1,376 @@ +The stable Postfix release is called postfix-2.5.x where 2=major +release number, 5=minor release number, x=patchlevel. The stable +release never changes except for patches that address bugs or +emergencies. Patches change the patchlevel and the release date. + +New features are developed in snapshot releases. These are called +postfix-2.6-yyyymmdd where yyyymmdd is the release date (yyyy=year, +mm=month, dd=day). Patches are never issued for snapshot releases; +instead, a new snapshot is released. + +The mail_release_date configuration parameter (format: yyyymmdd) +specifies the release date of a stable release or snapshot release. + +Incompatibility with Postfix 2.3 and earlier +-------------------------------------------- + +If you upgrade from Postfix 2.3 or earlier, read RELEASE_NOTES-2.4 +before proceeding. + +Major changes - critical +------------------------ + +[Incompat 20071224] The protocol to send Milter information from +smtpd(8) to cleanup(8) processes was cleaned up. If you use the +Milter feature, and upgrade a live Postfix system, you may see an +"unexpected record type" warning from a cleanup(8) server process. +To prevent this, execute the command "postfix reload". The +incompatibility affects only systems that use the Milter feature. +It does not cause loss of mail, just a minor delay until the remote +SMTP client retries. + +[Incompat 20071212] The allow_min_user feature now applies to both +sender and recipient addresses in SMTP commands. With earlier Postfix +versions, only recipients were subject to the allow_min_user feature, +and the restriction took effect at mail delivery time, causing mail +to be bounced later instead of being rejected immediately. + +[Incompat 20071206] The "make install" and "make upgrade" procedures +now create a Postfix-owned directory for Postfix-writable data files +such as caches and random numbers. The location is specified with +the "data_directory" parameter (default: "/var/lib/postfix"), and +the ownership is specified with the "mail_owner" parameter. + +[Incompat 20071206] The tlsmgr(8) and verify(8) servers no longer +use root privileges when opening the address_verify_map, +*_tls_session_cache_database, and tls_random_exchange_name cache +files. This avoids a potential security loophole where the ownership +of a file (or directory) does not match the trust level of the +content of that file (or directory). + +[Incompat 20071206] The tlsmgr(8) and verify(8) cache files should +now be stored as Postfix-owned files under the Postfix-owned +data_directory. As a migration aid, attempts to open these files +under a non-Postfix directory are redirected to the Postfix-owned +data_directory, and a warning is logged. + +This is an example of the warning messages: + + Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: request + to update file /etc/postfix/prng_exch in non-postfix directory + /etc/postfix + + Dec 6 12:56:22 bristle postfix/tlsmgr[7899]: warning: redirecting + the request to postfix-owned data_directory /var/lib/postfix + +If you wish to continue using a pre-existing tls_random_exchange_name +or address_verify_map file, move it to the Postfix-owned data_directory +and change ownership from root to Postfix (that is, change ownership +to the account specified with the mail_owner configuration parameter). + +[Feature 20071205] The "make install" and "make upgrade" procedures +now create a Postfix-owned directory for Postfix-writable data files +such as caches and random numbers. The location is specified with +the "data_directory" parameter (default: "/var/lib/postfix"), and +the ownership is specified with the "mail_owner" parameter. + +[Incompat 20071203] The "make upgrade" procedure adds a new service +"proxywrite" to the master.cf file, for read/write lookup table +access. If you copy your old configuration file over the updated +one, you may see warnings in the maillog file like this: + + connect #xx to subsystem private/proxywrite: No such file or directory + +To recover, run "postfix upgrade-configuration" again. + +[Incompat 20070613] The pipe(8) delivery agent no longer allows +delivery with the same group ID as the main.cf postdrop group. + +Major changes - malware defense +------------------------------- + +[Feature 20080107] New "pass" service type in master.cf. Written +years ago, this allows future front-end daemons to accept all +connections from the network, and to hand over connections from +well-behaved clients to Postfix. Since this feature uses file +descriptor passing, it imposes no overhead once a connection is +handed over to Postfix. See master(5) for a few details. + +[Feature 20070911] Stress-adaptive behavior. When a "public" network +service runs into an "all processes are busy" condition, the master(8) +daemon logs a warning, restarts the service, and runs it with "-o +stress=yes" on the command line (under normal conditions it runs +the service with "-o stress=" on the command line). This can be +used to make main.cf parameter settings stress dependent, for +example: + +/etc/postfix/main.cf: + smtpd_timeout = ${stress?10}${stress:300} + smtpd_hard_error_limit = ${stress?1}${stress:20} + +Translation: under conditions of stress, use an smtpd_timeout value +of 10 seconds instead of 300, and use smtpd_hard_error_limit of 1 +instead of 20. The syntax is explained in the postconf(5) manpage. + +The STRESS_README file gives examples of how to mitigate flooding +problems. + +Major changes - tls support +--------------------------- + +[Incompat 20080109] TLS logging output has changed to make it more +useful. Existing logfile parser regular expressions may need +adjustment. + +- More log entries include the "hostnamename[ipaddress]" of the + remote SMTP peer. + +- Certificate trust chain error reports show only the first + error certificate (closest to the trust chain root), and the + reporting is more human-readable for the most likely errors. + +- After the completion of the TLS handshake, the session is logged + with TLS loglevel >= 1 as either "Untrusted", "Trusted" or + "Verified" (SMTP client only). + - "Untrusted" means that the certificate trust chain is invalid, + or that the root CA is not trusted. + - "Trusted" means that the certificate trust chain is valid, and + that the root CA is trusted. + - "Verified" means that the certificate meets the SMTP client's + matching criteria for the destination: + - In the case of a destination name match, "Verified" also + implies "Trusted". + - In the case of a fingerprint match, CA trust is not applicable. + +- The logging of protocol states with TLS loglevel >= 2 no longer + reports bogus error conditions when OpenSSL asks Postfix to refill + (or flush) network I/O buffers. This loglevel is for debugging + only; use 0 or 1 in production configurations. + +[Feature 20080109] The Postfix SMTP client has a new "fingerprint" +security level. This avoids dependencies on CAs, and relies entirely +on bi-lateral exchange of public keys (really self-signed or private +CA signed X.509 public key certificates). Scalability is clearly +limited. For details, see the fingerprint discussion in TLS_README. + +[Feature 20080109] The Postfix SMTP server can now use SHA1 instead +of MD5 to compute remote SMTP client certificate fingerprints. For +backwards compatibility, the default algorithm is MD5. For details, +see the "smtpd_tls_fingerprint_digest" parameter in the postconf(5) +manual. + +[Feature 20080109] The maximum certificate trust chain depth +(verifydepth) is finally implemented in the Postfix TLS library. +Previously, the parameter had no effect. The default depth was +changed to 9 (the OpenSSL default) for backwards compatibility. + +If you have explicity limited the verification depth in main.cf, +check that the configured limit meets your needs. See the +"lmtp_tls_scert_verifydepth", "smtp_tls_scert_verifydepth" and +"smtpd_tls_ccert_verifydepth" parameters in the postconf(5) manual. + +[Feature 20080109] The selection of SSL/TLS protocols for mandatory +TLS can now use exclusion rather than inclusion. Either form is +acceptable; see the "lmtp_tls_mandatory_protocols", +"smtp_tls_mandatory_protocols" and "smtpd_tls_mandatory_protocols" +parameters in the postconf(5) manual. + +Major changes - scheduler +------------------------- + +[Feature 20071130] Revised queue manager with separate mechanisms +for per-destination concurrency control and for dead destination +detection. The concurrency control supports less-than-1 feedback +to allow for more gradual concurrency adjustments, and uses hysteresis +to avoid rapid oscillations. A destination is declared "dead" after +a configurable number of pseudo-cohorts(*) reports connection or +handshake failure. + +(*) A pseudo-cohort is a number of delivery requests equal to a + destination's delivery concurrency. + +The drawbacks of the old +/-1 feedback scheduler are a) overshoot +due to exponential delivery concurrency growth with each pseudo-cohort(*) +(5-10-20...); b) throttling down to zero concurrency after a single +pseudo-cohort(*) failure. The latter was especially an issue with +low-concurrency channels where a single failure could be sufficient +to mark a destination as "dead", and suspend further deliveries. + +New configuration parameters: destination_concurrency_feedback_debug, +default_destination_concurrency_positive_feedback, +default_destination_concurrency_negative_feedback, +default_destination_concurrency_failed_cohort_limit, as well as +transport-specific versions of the same. + +The default parameter settings are backwards compatible with older +Postfix versions. This may change after better defaults are field +tested. + +The updated SCHEDULER_README document describes the theory behind +the new concurrency scheduler, as well as Patrik Rak's preemptive +job scheduler. See postconf(5) for more extensive descriptions of +the configuration parameters. + +Major changes - small/home office +--------------------------------- + +[Feature 20080115] Preliminary SOHO_README document that combines +bits and pieces from other document in one place, so that it is +easier to find. This document describes the "mail sending" side +only. + +[Feature 20071202] Output rate control in the queue manager. For +example, specify "smtp_destination_rate_delay = 5m", to pause five +minutes between message deliveries. More information in the postconf(5) +manual under "default_destination_rate_delay". + +Major changes - smtp client +--------------------------- + +[Incompat 20080114] The Postfix SMTP client now by default defers +mail after a remote SMTP server rejects a SASL authentication +attempt. Specify "smtp_sasl_auth_soft_bounce = no" for the old +behavior. + +[Feature 20080114] The Postfix SMTP client can now avoid making +repeated SASL login failures with the same server, username and +password. To enable this safety feature, specify for example +"smtp_sasl_auth_cache_name = proxy:btree:/var/lib/postfix/sasl_auth_cache" +(access through the proxy service is required). Instead of trying +to SASL authenticate, the Postfix SMTP client defers or bounces +mail as controlled with the new smtp_sasl_auth_soft_bounce configuration +parameter. + +[Feature 20071111] Header/body checks are now available in the SMTP +client, after the implementation was moved from the cleanup server +to a library module. The SMTP client provides only actions that +don't change the message delivery time or destination: warn, replace, +prepend, ignore, dunno, ok. + +[Incompat 20070614] By default, the Postfix Cyrus SASL client no +longer sends a SASL authoriZation ID (authzid); it sends only the +SASL authentiCation ID (authcid) plus the authcid's password. Specify +"send_cyrus_sasl_authzid = yes" to get the old behavior. + +Major changes - smtp server +--------------------------- + +[Feature 20070724] Not really major. New support for RFC 3848 +(Received: headers with ESMTPS, ESMTPA, or ESMTPSA); updated SASL +support according to RFC 4954, resulting in small changes to SMTP +reply codes and (DSN) enhanced status codes. + +Major changes - milter +---------------------- + +[Incompat 20071224] The protocol to send Milter information from +smtpd(8) to cleanup(8) processes was cleaned up. If you use the +Milter feature, and upgrade a live Postfix system, you may see an +"unexpected record type" warning from a cleanup(8) server process. +To prevent this, execute the command "postfix reload". The +incompatibility affects only systems that use the Milter feature. +It does not cause loss of mail, just a minor delay until the remote +SMTP client retries. + +[Feature 20071221] Support for most of the Sendmail 8.14 Milter +protocol features. + +To enable the new features specify "milter_protocol = 6" and link +the filter application with a libmilter library from Sendmail 8.14 +or later. + +Sendmail 8.14 Milter features supported at this time: + +- NR_CONN, NR_HELO, NR_MAIL, NR_RCPT, NR_DATA, NR_UNKN, NR_HDR, + NR_EOH, NR_BODY: The filter can tell Postfix that it won't reply + to some of the SMTP events that Postfix sends. This makes the + protocol less chatty and improves performance. + +- SKIP: The filter can tell Postfix to skip sending the rest of + the message body, which also improves performance. + +- HDR_LEADSPC: The filter can request that Postfix does not delete + the first space character between header name and header value + when sending a header to the filter, and that Postfix does not + insert a space character between header name and header value + when receiving a header from the filter. This fixes a limitation + in the old Milter protocol that can break DKIM and DK signatures. + +- SETSYMLIST: The filter can override one or more of the main.cf + milter_xxx_macros parameter settings. + +Sendmail 8.14 Milter features not supported at this time: + +- RCPT_REJ: report rejected recipients to the mail filter. + +- CHGFROM: replace sender, with optional ESMTP command parameters. + +- ADDRCPT_PAR: add recipient, with optional ESMTP command parameters. + +It is unclear when (if ever) the missing features will be implemented. +SMFIP_RCPT_REJ requires invasive changes in the SMTP server recipient +processing and error handling. SMFIR_CHGFROM and SMFIR_ADDRCPT_PAR +require ESMTP command-line parsing in the cleanup server. Unfortunately, +Sendmail's documentation does not specify what ESMTP options are +supported, but only discusses examples of things that don't work. + +Major changes - address verification +------------------------------------ + +[Incompat 20070514] The default sender address for address verification +probes was changed from "postmaster" to "double-bounce", so that +the Postfix SMTP server no longer causes surprising behavior by +excluding "postmaster" from SMTP server access controls. + +Major changes - ldap +-------------------- + +[Incompat 20071216] Due to an incompatible API change between +OpenLDAP 2.0.11 and 2.0.12, an LDAP client compiled for OpenLDAP +version <= 2.0.11 will refuse to work with an OpenLDAP library +version >= 2.0.12 and vice versa. + +Major changes - logging +----------------------- + +[Incompat 20080109] TLS logging output has changed to make it more +useful. Existing logfile parser regular expressions may need +adjustment. + +- More log entries include the "hostnamename[ipaddress]" of the + remote SMTP peer. + +- Certificate trust chain error reports show only the first + error certificate (closest to the trust chain root), and the + reporting is more human-readable for the most likely errors. + +- After the completion of the TLS handshake, the session is logged + with TLS loglevel >= 1 as either "Untrusted", "Trusted" or + "Verified" (SMTP client only). + - "Untrusted" means that the certificate trust chain is invalid, + or that the root CA is not trusted. + - "Trusted" means that the certificate trust chain is valid, and + that the root CA is trusted. + - "Verified" means that the certificate meets the SMTP client's + matching criteria for the destination: + - In the case of a destination name match, "Verified" also + implies "Trusted". + - In the case of a fingerprint match, CA trust is not applicable. + +- The logging of protocol states with TLS loglevel >= 2 no longer + reports bogus error conditions when OpenSSL asks Postfix to refill + (or flush) network I/O buffers. This loglevel is for debugging + only; use 0 or 1 in production configurations. + +[Incompat 20071216] The SMTP "transcript of session" email now +includes the remote SMTP server TCP port number. + +Major changes - loop detection +------------------------------ + +[Incompat 20070422] [Incompat 20070422] When the pipe(8) delivery +agent is configured to create the optional Delivered-To: header, +it now first checks if that same header is already present in the +message. If so, the message is returned as undeliverable. This test +should have been included with Postfix 2.0 when Delivered-To: support +was added to the pipe(8) delivery agent. diff --git a/static/netbsd/man5/RELEASE_NOTES-3.5 b/static/netbsd/man5/RELEASE_NOTES-3.5 new file mode 100644 index 00000000..d3c41b83 --- /dev/null +++ b/static/netbsd/man5/RELEASE_NOTES-3.5 @@ -0,0 +1,157 @@ +This is the Postfix 3.5 (stable) release. + +The stable Postfix release is called postfix-3.5.x where 3=major +release number, 5=minor release number, x=patchlevel. The stable +release never changes except for patches that address bugs or +emergencies. Patches change the patchlevel and the release date. + +New features are developed in snapshot releases. These are called +postfix-3.6-yyyymmdd where yyyymmdd is the release date (yyyy=year, +mm=month, dd=day). Patches are never issued for snapshot releases; +instead, a new snapshot is released. + +The mail_release_date configuration parameter (format: yyyymmdd) +specifies the release date of a stable release or snapshot release. + +If you upgrade from Postfix 3.3 or earlier, read RELEASE_NOTES-3.4 +before proceeding. + +License change +--------------- + +This software is distributed with a dual license: in addition to the +historical IBM Public License 1.0, it is now also distributed with the +more recent Eclipse Public License 2.0. Recipients can choose to take +the software under the license of their choice. Those who are more +comfortable with the IPL can continue with that license. + +Major changes - multiple relayhost in SMTP +------------------------------------------ + +[Feature 20200111] the Postfix SMTP and LMTP client support a list +of nexthop destinations separated by comma or whitespace. These +destinations will be tried in the specified order. + +The list form can be specified in relayhost, transport_maps, +default_transport, and sender_dependent_default_transport_maps. + +Examples: +/etc/postfix/main.cf: + relayhost = foo.example, bar.example + default_transport = smtp:foo.example, bar.example. + +NOTE: this is an SMTP and LMTP client feature. It does not work for +other Postfix delivery agents. + +Major changes - certificate access +---------------------------------- + +[Feature 20190517] Search order support for check_ccert_access. +Search order support for other tables is in design (canonical_maps, +virtual_alias_maps, transport_maps, etc.). + +The following check_ccert_access setting uses the built-in search +order: it first looks up the client certificate fingerprint, then +the client certificate public-key fingerprint, and it stops when a +decision is made. + +/etc/postfix/main.cf: + smtpd_mumble_restrictions = + ... + check_ccert_access hash:/etc/postfix/ccert-access + ... + +The following setting, with explicit search order, produces the +exact same result: + +/etc/postfix/main.cf: + smtpd_mumble_restrictions = + ... + check_ccert_access { + hash:/etc/postfix/ccert-access { + search_order = cert_fingerprint, pubkey_fingerprint } } + ... + +Support is planned for other certificate features. + +Major changes - dovecot usability +--------------------------------- + +[Feature 20190615] The SMTP+LMTP delivery agent can now prepend +Delivered-To, X-Original-To and Return-Path headers, just like the +pipe(8) and local(8) delivery agents. + +This uses the "flags=DORX" command-line flags in master.cf. See the +smtp(8) manpage for details. + +This obsoletes the "lmtp_assume_final = yes" setting, and replaces +it with "flags=...X...", for consistency with the pipe(8) delivery +agent. + +Major changes - forced expiration +--------------------------------- + +[Feature 20200202] Support to force-expire email messages. This +introduces new postsuper(1) command-line options to request expiration, +and additional information in mailq(1) or postqueue(1) output. + +The forced-to-expire status is stored in a queue file attribute. +An expired message is returned to the sender when the queue manager +attempts to deliver that message (note that Postfix will never +deliver messages in the hold queue). + +The postsuper(1) -e and -f options both set the forced-to-expire +queue file attribute. The difference is that -f will also release +a message if it is in the hold queue. With -e, such a message would +not be returned to the sender until it is released with -f or -H. + +In the mailq(1) or postqueue(1) -p output, a forced-to-expire message +is indicated with # after the queue file name. In postqueue(1) JSON +output, there is a new per-message field "forced_expire" (with value +true or false) that shows the forced-to-expire status. + +Major changes - haproxy2 protocol +--------------------------------- + +[Feature 20200112] Support for the haproxy v2 protocol. The Postfix +implementation supports TCP over IPv4 and IPv6, as well as non-proxied +connections; the latter are typically used for heartbeat tests. + +The haproxy v2 protocol introduces no additional Postfix configuration. +The Postfix smtpd(8) and postscreen(8) daemons accept both v1 and +v2 protocol versions. + +Major changes - logging +----------------------- + +[Incompat 20191109] Postfix daemon processes now log the from= and +to= addresses in external (quoted) form in non-debug logging (info, +warning, etc.). This means that when an address localpart contains +spaces or other special characters, the localpart will be quoted, +for example: + + from=<"name with spaces"@example.com> + +Older Postfix versions would log the internal (unquoted) form: + + from= + +The external and internal forms are identical for the vast majority +of email addresses that contain no spaces or other special characters +in the localpart. + +Specify "info_log_address_format = internal" for backwards +compatibility. + +The logging in external form is consistent with the address form +that Postfix 3.2 and later prefer for table lookups. It is therefore +the more useful form for non-debug logging. + +Major changes - IP address normalization +---------------------------------------- + +[Incompat 20190427] Postfix now normalizes IP addresses received +with XCLIENT, XFORWARD, or with the HaProxy protocol, for consistency +with direct connections to Postfix. This may change the appearance +of logging, and the way that check_client_access will match subnets +of an IPv6 address. diff --git a/static/netbsd/man5/access.5 b/static/netbsd/man5/access.5 new file mode 100644 index 00000000..c3d40bbe --- /dev/null +++ b/static/netbsd/man5/access.5 @@ -0,0 +1,486 @@ +.\" $NetBSD: access.5,v 1.5 2025/02/25 19:15:42 christos Exp $ +.\" +.TH ACCESS 5 +.ad +.fi +.SH NAME +access +\- +Postfix SMTP server access table +.SH "SYNOPSIS" +.na +.nf +\fBpostmap /etc/postfix/access\fR + +\fBpostmap \-q "\fIstring\fB" /etc/postfix/access\fR + +\fBpostmap \-q \- /etc/postfix/access <\fIinputfile\fR +.SH DESCRIPTION +.ad +.fi +This document describes access control on remote SMTP client +information: host names, network addresses, and envelope +sender or recipient addresses; it is implemented by the +Postfix SMTP server. See \fBheader_checks\fR(5) or +\fBbody_checks\fR(5) for access control on the content of +email messages. + +Normally, the \fBaccess\fR(5) table is specified as a text file +that serves as input to the \fBpostmap\fR(1) command. +The result, an indexed file in \fBdbm\fR or \fBdb\fR format, +is used for fast searching by the mail system. Execute the +command "\fBpostmap /etc/postfix/access\fR" to rebuild an +indexed file after changing the corresponding text file. + +When the table is provided via other means such as NIS, LDAP +or SQL, the same lookups are done as for ordinary indexed files. + +Alternatively, the table can be provided as a regular\-expression +map where patterns are given as regular expressions, or lookups +can be directed to a TCP\-based server. In those cases, the lookups +are done in a slightly different way as described below under +"REGULAR EXPRESSION TABLES" or "TCP\-BASED TABLES". +.SH "CASE FOLDING" +.na +.nf +.ad +.fi +The search string is folded to lowercase before database +lookup. As of Postfix 2.3, the search string is not case +folded with database types such as regexp: or pcre: whose +lookup fields can match both upper and lower case. +.SH "TABLE FORMAT" +.na +.nf +.ad +.fi +The input format for the \fBpostmap\fR(1) command is as follows: +.IP "\fIpattern action\fR" +When \fIpattern\fR matches a mail address, domain or host address, +perform the corresponding \fIaction\fR. +.IP "blank lines and comments" +Empty lines and whitespace\-only lines are ignored, as +are lines whose first non\-whitespace character is a `#'. +.IP "multi\-line text" +A logical line starts with non\-whitespace text. A line that +starts with whitespace continues a logical line. +.SH "EMAIL ADDRESS PATTERNS IN INDEXED TABLES" +.na +.nf +.ad +.fi +With lookups from indexed files such as DB or DBM, or from networked +tables such as NIS, LDAP or SQL, patterns are tried in the order as +listed below: +.IP \fIuser\fR@\fIdomain\fR +Matches the specified mail address. +.IP \fIdomain.tld\fR +Matches \fIdomain.tld\fR as the domain part of an email address. +.sp +The pattern \fIdomain.tld\fR also matches subdomains, but only +when the string \fBsmtpd_access_maps\fR is listed in the Postfix +\fBparent_domain_matches_subdomains\fR configuration setting. +.IP \fI.domain.tld\fR +Matches subdomains of \fIdomain.tld\fR, but only when the +string \fBsmtpd_access_maps\fR is not listed in the Postfix +\fBparent_domain_matches_subdomains\fR configuration setting. +.IP \fIuser\fR@ +Matches all mail addresses with the specified user part. +.PP +Note: lookup of the null sender address is not possible with +some types of lookup table. By default, Postfix uses \fB<>\fR +as the lookup key for such addresses. The value is specified with +the \fBsmtpd_null_access_lookup_key\fR parameter in the Postfix +\fBmain.cf\fR file. +.SH "EMAIL ADDRESS EXTENSION" +.na +.nf +.fi +.ad +When a mail address localpart contains the optional recipient delimiter +(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes: +\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIdomain\fR, +\fIuser+foo\fR@, and \fIuser\fR@. +.SH "HOST NAME/ADDRESS PATTERNS IN INDEXED TABLES" +.na +.nf +.ad +.fi +With lookups from indexed files such as DB or DBM, or from networked +tables such as NIS, LDAP or SQL, the following lookup patterns are +examined in the order as listed: +.IP \fIdomain.tld\fR +Matches \fIdomain.tld\fR. +.sp +The pattern \fIdomain.tld\fR also matches subdomains, but only +when the string \fBsmtpd_access_maps\fR is listed in the Postfix +\fBparent_domain_matches_subdomains\fR configuration setting. +.IP \fI.domain.tld\fR +Matches subdomains of \fIdomain.tld\fR, but only when the +string \fBsmtpd_access_maps\fR is not listed in the Postfix +\fBparent_domain_matches_subdomains\fR configuration setting. +.IP \fInet.work.addr.ess\fR +.IP \fInet.work.addr\fR +.IP \fInet.work\fR +.IP \fInet\fR +Matches a remote IPv4 host address or network address range. +Specify one to four decimal octets separated by ".". Do not +specify "[]" , "/", leading zeros, or hexadecimal forms. + +Network ranges are matched by repeatedly truncating the last +".octet" from a remote IPv4 host address string, until a +match is found in the access table, or until further +truncation is not possible. + +NOTE: use the \fBcidr\fR lookup table type to specify +network/netmask patterns. See \fBcidr_table\fR(5) for details. +.IP \fInet:work:addr:ess\fR +.IP \fInet:work:addr\fR +.IP \fInet:work\fR +.IP \fInet\fR +Matches a remote IPv6 host address or network address range. +Specify three to eight hexadecimal octet pairs separated +by ":", using the compressed form "::" for a sequence of +zero\-valued octet pairs. Do not specify "[]", "/", leading +zeros, or non\-compressed forms. + +A network range is matched by repeatedly truncating the +last ":octetpair" from the compressed\-form remote IPv6 host +address string, until a match is found in the access table, +or until further truncation is not possible. + +NOTE: use the \fBcidr\fR lookup table type to specify +network/netmask patterns. See \fBcidr_table\fR(5) for details. + +IPv6 support is available in Postfix 2.2 and later. +.SH "ACCEPT ACTIONS" +.na +.nf +.ad +.fi +.IP \fBOK\fR +Accept the address etc. that matches the pattern. +.IP \fIall\-numerical\fR +An all\-numerical result is treated as OK. This format is +generated by address\-based relay authorization schemes +such as pop\-before\-smtp. +.PP +For other accept actions, see "OTHER ACTIONS" below. +.SH "REJECT ACTIONS" +.na +.nf +.ad +.fi +Postfix version 2.3 and later support enhanced status codes +as defined in RFC 3463. +When no code is specified at the beginning of the \fItext\fR +below, Postfix inserts a default enhanced status code of "5.7.1" +in the case of reject actions, and "4.7.1" in the case of +defer actions. See "ENHANCED STATUS CODES" below. +.IP "\fB4\fINN text\fR" +.IP "\fB5\fINN text\fR" +Reject the address etc. that matches the pattern, and respond with +the numerical three\-digit code and text. \fB4\fINN\fR means "try +again later", while \fB5\fINN\fR means "do not try again". + +The following responses have special meaning for the Postfix +SMTP server: +.RS +.IP "\fB421 \fItext\fR (Postfix 2.3 and later)" +.IP "\fB521 \fItext\fR (Postfix 2.6 and later)" +After responding with the numerical three\-digit code and +text, disconnect immediately from the SMTP client. This +frees up SMTP server resources so that they can be made +available to another SMTP client. +.IP +Note: The "521" response should be used only with botnets +and other malware where interoperability is of no concern. +The "send 521 and disconnect" behavior is NOT defined in +the SMTP standard. +.RE +.IP "\fBREJECT \fIoptional text...\fR +Reject the address etc. that matches the pattern. Reply with +"\fB$access_map_reject_code \fIoptional text...\fR" when the +optional text is +specified, otherwise reply with a generic error response message. +.IP "\fBDEFER \fIoptional text...\fR +Reject the address etc. that matches the pattern. Reply with +"\fB$access_map_defer_code \fIoptional text...\fR" when the +optional text is +specified, otherwise reply with a generic error response message. +.sp +This feature is available in Postfix 2.6 and later. +.IP "\fBDEFER_IF_REJECT \fIoptional text...\fR +Defer the request if some later restriction would result in a +REJECT action. Reply with "\fB$access_map_defer_code 4.7.1 +\fIoptional text...\fR" when the +optional text is specified, otherwise reply with a generic error +response message. +.sp +Prior to Postfix 2.6, the SMTP reply code is 450. +.sp +This feature is available in Postfix 2.1 and later. +.IP "\fBDEFER_IF_PERMIT \fIoptional text...\fR +Defer the request if some later restriction would result in +an explicit or implicit PERMIT action. +Reply with "\fB$access_map_defer_code 4.7.1 \fI optional +text...\fR" when the +optional text is specified, otherwise reply with a generic error +response message. +.sp +Prior to Postfix 2.6, the SMTP reply code is 450. +.sp +This feature is available in Postfix 2.1 and later. +.PP +For other reject actions, see "OTHER ACTIONS" below. +.SH "OTHER ACTIONS" +.na +.nf +.ad +.fi +.IP \fIrestriction...\fR +Apply the named UCE restriction(s) (\fBpermit\fR, \fBreject\fR, +\fBreject_unauth_destination\fR, and so on). +.IP "\fBBCC \fIuser@domain\fR" +Send one copy of the message to the specified recipient. +.sp +If multiple BCC actions are specified within the same SMTP +MAIL transaction, with Postfix 3.0 only the last action +will be used. +.sp +This feature is available in Postfix 3.0 and later. +.IP "\fBDISCARD \fIoptional text...\fR +Claim successful delivery and silently discard the message. +Log the optional text if specified, otherwise log a generic +message. +.sp +Note: this action currently affects all recipients of the message. +To discard only one recipient without discarding the entire message, +use the transport(5) table to direct mail to the discard(8) service. +.sp +This feature is available in Postfix 2.0 and later. +.IP \fBDUNNO\fR +Pretend that the lookup key was not found. This +prevents Postfix from trying substrings of the lookup key +(such as a subdomain name, or a network address subnetwork). +.sp +This feature is available in Postfix 2.0 and later. +.IP "\fBFILTER \fItransport:destination\fR" +After the message is queued, send the entire message through +the specified external content filter. The \fItransport\fR +name specifies the first field of a mail delivery agent +definition in master.cf; the syntax of the next\-hop +\fIdestination\fR is described in the manual page of the +corresponding delivery agent. More information about +external content filters is in the Postfix FILTER_README +file. +.sp +Note 1: do not use $\fInumber\fR regular expression +substitutions for \fItransport\fR or \fIdestination\fR +unless you know that the information has a trusted origin. +.sp +Note 2: this action overrides the main.cf \fBcontent_filter\fR +setting, and affects all recipients of the message. In the +case that multiple \fBFILTER\fR actions fire, only the last +one is executed. +.sp +Note 3: the purpose of the FILTER command is to override +message routing. To override the recipient's \fItransport\fR +but not the next\-hop \fIdestination\fR, specify an empty +filter \fIdestination\fR (Postfix 2.7 and later), or specify +a \fItransport:destination\fR that delivers through a +different Postfix instance (Postfix 2.6 and earlier). Other +options are using the recipient\-dependent \fBtrans\%port\%_maps\fR +or the sen\%der\-dependent +\fBsender\%_de\%pen\%dent\%_de\%fault\%_trans\%port\%_maps\fR +features. +.sp +This feature is available in Postfix 2.0 and later. +.IP "\fBHOLD \fIoptional text...\fR" +Place the message on the \fBhold\fR queue, where it will +sit until someone either deletes it or releases it for +delivery. +Log the optional text if specified, otherwise log a generic +message. + +Mail that is placed on hold can be examined with the +\fBpostcat\fR(1) command, and can be destroyed or released with +the \fBpostsuper\fR(1) command. +.sp +Note: use "\fBpostsuper \-r\fR" to release mail that was kept on +hold for a significant fraction of \fB$maximal_queue_lifetime\fR +or \fB$bounce_queue_lifetime\fR, or longer. Use "\fBpostsuper \-H\fR" +only for mail that will not expire within a few delivery attempts. +.sp +Note: this action currently affects all recipients of the message. +.sp +This feature is available in Postfix 2.0 and later. +.IP "\fBPREPEND \fIheadername: headervalue\fR" +Prepend the specified message header to the message. +When more than one PREPEND action executes, the first +prepended header appears before the second etc. prepended +header. +.sp +Note: this action must execute before the message content +is received; it cannot execute in the context of +\fBsmtpd_end_of_data_restrictions\fR. +.sp +This feature is available in Postfix 2.1 and later. +.IP "\fBREDIRECT \fIuser@domain\fR" +After the message is queued, send the message to the specified +address instead of the intended recipient(s). When multiple +\fBREDIRECT\fR actions fire, only the last one takes effect. +.sp +Note 1: this action overrides the FILTER action, and currently +overrides all recipients of the message. +.sp +Note 2: a REDIRECT address is subject to canonicalization +(add missing domain) but NOT subject to canonical, masquerade, +bcc, or virtual alias mapping. +.sp +This feature is available in Postfix 2.1 and later. +.IP "\fBINFO \fIoptional text...\fR +Log an informational record with the optional text, together +with client information and if available, with helo, sender, +recipient and protocol information. +.sp +This feature is available in Postfix 3.0 and later. +.IP "\fBWARN \fIoptional text...\fR +Log a warning with the optional text, together with client information +and if available, with helo, sender, recipient and protocol information. +.sp +This feature is available in Postfix 2.1 and later. +.SH "ENHANCED STATUS CODES" +.na +.nf +.ad +.fi +Postfix version 2.3 and later support enhanced status codes +as defined in RFC 3463. +When an enhanced status code is specified in an access +table, it is subject to modification. The following +transformations are needed when the same access table is +used for client, helo, sender, or recipient access restrictions; +they happen regardless of whether Postfix replies to a MAIL +FROM, RCPT TO or other SMTP command. +.IP \(bu +When a sender address matches a REJECT action, the Postfix +SMTP server will transform a recipient DSN status (e.g., +4.1.1\-4.1.6) into the corresponding sender DSN status, and +vice versa. +.IP \(bu +When non\-address information matches a REJECT action (such +as the HELO command argument or the client hostname/address), +the Postfix SMTP server will transform a sender or recipient +DSN status into a generic non\-address DSN status (e.g., +4.0.0). +.SH "REGULAR EXPRESSION TABLES" +.na +.nf +.ad +.fi +This section describes how the table lookups change when the table +is given in the form of regular expressions. For a description of +regular expression lookup table syntax, see \fBregexp_table\fR(5) +or \fBpcre_table\fR(5). + +Each pattern is a regular expression that is applied to the entire +string being looked up. Depending on the application, that string +is an entire client hostname, an entire client IP address, or an +entire mail address. Thus, no parent domain or parent network search +is done, \fIuser@domain\fR mail addresses are not broken up into +their \fIuser@\fR and \fIdomain\fR constituent parts, nor is +\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. + +Patterns are applied in the order as specified in the table, until a +pattern is found that matches the search string. + +Actions are the same as with indexed file lookups, with +the additional feature that parenthesized substrings from the +pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on. +.SH "TCP-BASED TABLES" +.na +.nf +.ad +.fi +This section describes how the table lookups change when lookups +are directed to a TCP\-based server. For a description of the TCP +client/server lookup protocol, see \fBtcp_table\fR(5). +This feature is not available up to and including Postfix version 2.4. + +Each lookup operation uses the entire query string once. +Depending on the application, that string is an entire client +hostname, an entire client IP address, or an entire mail address. +Thus, no parent domain or parent network search is done, +\fIuser@domain\fR mail addresses are not broken up into +their \fIuser@\fR and \fIdomain\fR constituent parts, nor is +\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. + +Actions are the same as with indexed file lookups. +.SH "EXAMPLE" +.na +.nf +.ad +.fi +The following example uses an indexed file, so that the +order of table entries does not matter. The example permits +access by the client at address 1.2.3.4 but rejects all +other clients in 1.2.3.0/24. Instead of \fBhash\fR lookup +tables, some systems use \fBdbm\fR. Use the command +"\fBpostconf \-m\fR" to find out what lookup tables Postfix +supports on your system. + +.nf +.na +/etc/postfix/main.cf: + smtpd_client_restrictions = + check_client_access hash:/etc/postfix/access + +/etc/postfix/access: + 1.2.3 REJECT + 1.2.3.4 OK +.fi +.ad + +Execute the command "\fBpostmap /etc/postfix/access\fR" after +editing the file. +.SH BUGS +.ad +.fi +The table format does not understand quoting conventions. +.SH "SEE ALSO" +.na +.nf +postmap(1), Postfix lookup table manager +smtpd(8), SMTP server +postconf(5), configuration parameters +transport(5), transport:nexthop syntax +.SH "README FILES" +.na +.nf +.ad +.fi +Use "\fBpostconf readme_directory\fR" or +"\fBpostconf html_directory\fR" to locate this information. +.na +.nf +SMTPD_ACCESS_README, built\-in SMTP server access control +DATABASE_README, Postfix lookup table overview +.SH "LICENSE" +.na +.nf +.ad +.fi +The Secure Mailer license must be distributed with this software. +.SH "AUTHOR(S)" +.na +.nf +Wietse Venema +IBM T.J. Watson Research +P.O. Box 704 +Yorktown Heights, NY 10598, USA + +Wietse Venema +Google, Inc. +111 8th Avenue +New York, NY 10011, USA diff --git a/static/netbsd/man5/aliases.5 b/static/netbsd/man5/aliases.5 new file mode 100644 index 00000000..f015b4b3 --- /dev/null +++ b/static/netbsd/man5/aliases.5 @@ -0,0 +1,249 @@ +.\" $NetBSD: aliases.5,v 1.6 2025/02/25 19:15:42 christos Exp $ +.\" +.TH ALIASES 5 +.ad +.fi +.SH NAME +aliases +\- +Postfix local alias database format +.SH "SYNOPSIS" +.na +.nf +.fi +\fBnewaliases\fR + +\fBpostalias \-q \fIname\fB [\fIfile\-type\fB]:[\fIfile\-name\fB]\fR +.SH DESCRIPTION +.ad +.fi +The optional \fBaliases\fR(5) table (alias_maps) redirects +mail for local recipients. The redirections are processed +by the Postfix \fBlocal\fR(8) delivery agent. This table +is always searched with an email address localpart (no +domain portion). + +This is unlike \fBvirtual\fR(5) aliasing (virtual_alias_maps) +which applies to all recipients: local(8), virtual, and remote, +and which is implemented by the \fBcleanup\fR(8) daemon. That +table is often searched with a full email address (including +domain). + +Normally, the \fBaliases\fR(5) table is specified as a text file +that serves as input to the \fBpostalias\fR(1) command. The +result, an indexed file in \fBdbm\fR or \fBdb\fR format, is +used for fast lookup by the mail system. Execute the command +\fBnewaliases\fR in order to rebuild the indexed file after +changing the Postfix alias database. + +When the table is provided via other means such as NIS, LDAP +or SQL, the same lookups are done as for ordinary indexed files. + +Alternatively, the table can be provided as a regular\-expression +map where patterns are given as regular expressions. In +this case, the lookups are done in a slightly different way +as described below under "REGULAR EXPRESSION TABLES". + +Users can control delivery of their own mail by setting +up \fB.forward\fR files in their home directory. +Lines in per\-user \fB.forward\fR files have the same syntax +as the right\-hand side of \fBaliases\fR(5) entries. + +The format of the alias database input file is as follows: +.IP \(bu +An alias definition has the form +.sp +.nf + \fIname\fR: \fIvalue1\fR, \fIvalue2\fR, \fI...\fR +.fi +.IP \(bu +Empty lines and whitespace\-only lines are ignored, as +are lines whose first non\-whitespace character is a `#'. +.IP \(bu +A logical line starts with non\-whitespace text. A line that +starts with whitespace continues a logical line. +.PP +The \fIname\fR is a local address (no domain part). +Use double quotes when the name contains any special characters +such as whitespace, `#', `:', or `@'. The \fIname\fR is folded to +lowercase, in order to make database lookups case insensitive. +.PP +In addition, when an alias exists for \fBowner\-\fIname\fR, +this will override the envelope sender address, so that +delivery diagnostics are directed to \fBowner\-\fIname\fR, +instead of the originator of the message (for details, see +\fBowner_request_special\fR, \fBexpand_owner_alias\fR and +\fBreset_owner_alias\fR). +This is typically used to direct delivery errors to the maintainer of +a mailing list, who is in a better position to deal with mailing +list delivery problems than the originator of the undelivered mail. +.PP +The \fIvalue\fR contains one or more of the following: +.IP \fIaddress\fR +Mail is forwarded to \fIaddress\fR, which is compatible +with the RFC 822 standard. +.IP \fI/file/name\fR +Mail is appended to \fI/file/name\fR. For details on how a +file is written see the sections "EXTERNAL FILE DELIVERY" +and "DELIVERY RIGHTS" in the \fBlocal\fR(8) documentation. +Delivery is not limited to regular files. For example, to dispose +of unwanted mail, deflect it to \fB/dev/null\fR. +.IP "|\fIcommand\fR" +Mail is piped into \fIcommand\fR. Commands that contain +special characters, such as whitespace, should be enclosed +between double quotes. For details on how a command is +executed see "EXTERNAL COMMAND DELIVERY" and "DELIVERY +RIGHTS" in the \fBlocal\fR(8) documentation. +.sp +When the command fails, a limited amount of command output is +mailed back to the sender. The file \fB/usr/include/sysexits.h\fR +defines the expected exit status codes. For example, use +\fB"|exit 67"\fR to simulate a "user unknown" error, and +\fB"|exit 0"\fR to implement an expensive black hole. +.IP \fB:include:\fI/file/name\fR +Mail is sent to the destinations listed in the named file. +Lines in \fB:include:\fR files have the same syntax +as the right\-hand side of \fBaliases\fR(5) entries. +.sp +A destination can be any destination that is described in this +manual page. However, delivery to "|\fIcommand\fR" and +\fI/file/name\fR is disallowed by default. To enable, edit the +\fBallow_mail_to_commands\fR and \fBallow_mail_to_files\fR +configuration parameters. +.SH "ADDRESS EXTENSION" +.na +.nf +.ad +.fi +When alias database search fails, and the recipient localpart +contains the optional recipient delimiter (e.g., \fIuser+foo\fR), +the search is repeated for the unextended address (e.g., \fIuser\fR). + +The \fBpropagate_unmatched_extensions\fR parameter controls +whether an unmatched address extension (\fI+foo\fR) is +propagated to the result of table lookup. +.SH "CASE FOLDING" +.na +.nf +.ad +.fi +The local(8) delivery agent always folds the search string +to lowercase before database lookup. +.SH "REGULAR EXPRESSION TABLES" +.na +.nf +.ad +.fi +This section describes how the table lookups change when the table +is given in the form of regular expressions. For a description of +regular expression lookup table syntax, see \fBregexp_table\fR(5) +or \fBpcre_table\fR(5). NOTE: these formats do not use ":" at the +end of a pattern. + +Each regular expression is applied to the entire search +string. Thus, a search string \fIuser+foo\fR is not broken +up into \fIuser\fR and \fIfoo\fR. + +Regular expressions are applied in the order as specified +in the table, until a regular expression is found that +matches the search string. + +Lookup results are the same as with indexed file lookups. +For security reasons there is no support for \fB$1\fR, +\fB$2\fR etc. substring interpolation. +.SH "SECURITY" +.na +.nf +.ad +.fi +The \fBlocal\fR(8) delivery agent disallows regular expression +substitution of $1 etc. in \fBalias_maps\fR, because that +would open a security hole. + +The \fBlocal\fR(8) delivery agent will silently ignore +requests to use the \fBproxymap\fR(8) server within +\fBalias_maps\fR. Instead it will open the table directly. +Before Postfix version 2.2, the \fBlocal\fR(8) delivery +agent will terminate with a fatal error. +.SH "CONFIGURATION PARAMETERS" +.na +.nf +.ad +.fi +The following \fBmain.cf\fR parameters are especially relevant. +The text below provides only a parameter summary. See +\fBpostconf\fR(5) for more details including examples. +.IP "\fBalias_database (see 'postconf -d' output)\fR" +The alias databases for \fBlocal\fR(8) delivery that are updated with +"\fBnewaliases\fR" or with "\fBsendmail \-bi\fR". +.IP "\fBalias_maps (see 'postconf -d' output)\fR" +Optional lookup tables that are searched only with an email address +localpart (no domain) and that apply only to \fBlocal\fR(8) recipients; +this is unlike virtual_alias_maps that are often searched with a +full email address (including domain) and that apply to all recipients: +\fBlocal\fR(8), virtual, and remote. +.IP "\fBallow_mail_to_commands (alias, forward)\fR" +Restrict \fBlocal\fR(8) mail delivery to external commands. +.IP "\fBallow_mail_to_files (alias, forward)\fR" +Restrict \fBlocal\fR(8) mail delivery to external files. +.IP "\fBexpand_owner_alias (no)\fR" +When delivering to an alias "\fIaliasname\fR" that has an +"owner\-\fIaliasname\fR" companion alias, set the envelope sender +address to the expansion of the "owner\-\fIaliasname\fR" alias. +.IP "\fBpropagate_unmatched_extensions (canonical, virtual)\fR" +What address lookup tables copy an address extension from the lookup +key to the lookup result. +.IP "\fBowner_request_special (yes)\fR" +Enable special treatment for owner\-\fIlistname\fR entries in the +\fBaliases\fR(5) file, and don't split owner\-\fIlistname\fR and +\fIlistname\fR\-request address localparts when the recipient_delimiter +is set to "\-". +.IP "\fBrecipient_delimiter (empty)\fR" +The set of characters that can separate an email address +localpart, user name, or a .forward file name from its extension. +.PP +Available in Postfix version 2.3 and later: +.IP "\fBfrozen_delivered_to (yes)\fR" +Update the \fBlocal\fR(8) delivery agent's idea of the Delivered\-To: +address (see prepend_delivered_header) only once, at the start of +a delivery attempt; do not update the Delivered\-To: address while +expanding aliases or .forward files. +.SH "STANDARDS" +.na +.nf +RFC 822 (ARPA Internet Text Messages) +.SH "SEE ALSO" +.na +.nf +local(8), local delivery agent +newaliases(1), create/update alias database +postalias(1), create/update alias database +postconf(5), configuration parameters +.SH "README FILES" +.na +.nf +.ad +.fi +Use "\fBpostconf readme_directory\fR" or +"\fBpostconf html_directory\fR" to locate this information. +.na +.nf +DATABASE_README, Postfix lookup table overview +.SH "LICENSE" +.na +.nf +.ad +.fi +The Secure Mailer license must be distributed with this software. +.SH "AUTHOR(S)" +.na +.nf +Wietse Venema +IBM T.J. Watson Research +P.O. Box 704 +Yorktown Heights, NY 10598, USA + +Wietse Venema +Google, Inc. +111 8th Avenue +New York, NY 10011, USA diff --git a/static/netbsd/man5/altq.conf.5 b/static/netbsd/man5/altq.conf.5 new file mode 100644 index 00000000..1e65e5a4 --- /dev/null +++ b/static/netbsd/man5/altq.conf.5 @@ -0,0 +1,1344 @@ +.\" $NetBSD: altq.conf.5,v 1.20 2025/03/15 20:29:05 gutteridge Exp $ +.\" $KAME: altq.conf.5,v 1.15 2002/11/17 02:51:49 kjc Exp $ +.\" +.\" Copyright (C) 2000 +.\" Sony Computer Science Laboratories Inc. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY SONY CSL AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL SONY CSL OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.Dd July 14, 2021 +.Dt ALTQ.CONF 5 +.Os +.\" +.Sh NAME +.Nm altq.conf +.Nd ALTQ configuration file +.\" +.Sh DESCRIPTION +The +.Nm +file contains a number of lines specifying the behavior of queueing +disciplines. +Comments start with a # and extend to the end of the line. +.Pp +The +.Xr altqd 8 +program reads +.Pa /etc/altq.conf +at startup and sets up queueing disciplines. +BLUE, CBQ (Class-Based Queueing), FIFOQ (First-In First-Out Queue), +HFSC (Hierarchical Fair Service Curve), PRIQ (Priority Queueing), +RED (Random Early Detection), RIO (RED with IN/OUT), +WFQ (Weighted Fair Queueing), JoBS (Joint Buffer Management and +Scheduling) +and CDNR (Diffserv Traffic Conditioner) can be configured in this file. +.Ss Interface Commands +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Ar discipline-specific-options +.El +.Pp +The +.Cm interface +command specifies a network interface to be under control of ALTQ. +One interface specification is provided for each network interface +under control of ALTQ. +A system configured as a router may have multiple interface +specifications. +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +This is the maximum rate that the queueing discipline will allow on this +interface. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +When +.Cm tbrsize +is omitted, the system automatically sets the bucket size +using heuristics. +The token rate is set to the interface bandwidth specified by the +.Cm interface +command. +.It Ar sched_type +Type of a queueing discipline. +It must be either +.Cm blue , +.Cm cbq , +.Cm fifoq , +.Cm hfsc , +.Cm jobs , +.Cm priq , +.Cm red , +.Cm rio , +or +.Cm wfq . +If the interface has only traffic conditioners and no queueing +discipline, +.Ar sched_type +can be omitted. +.El +.Ss Class Command +.Bl -tag -width class -offset indent +.It Cm class +.Ar sched_type +.Ar if_name +.Ar class_name +.Ar parent_name +.Op Cm red|rio +.Op Cm ecn +.Op Cm cleardscp +.Op Ar discipline-specific-options +.El +.Pp +The +.Cm class +command specifies a packet scheduling class for CBQ, HFSC, JoBS or PRIQ. +A class specifier must be provided for each packet scheduling class. +.Bl -tag -width 8n -offset indent +.It Ar sched_type +Type of queueing discipline. +Must correspond to the discipline name in interface specification. +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar class_name +Arbitrary name for this class. +Must be unique for this interface. +.It Ar parent_name +The name of the parent class for this class (for CBQ or HFSC). +Parent class must have been previously defined. +PRIQ and JoBS do not have class hierarchy and parent_name must be +.Dv NULL +for PRIQ and JoBS classes. +.It Cm red +Use RED (Random Early Detection) on this class queue. +RED drops packets with the probability proportional to the average +queue length. +.It Cm rio +Use RIO (RED with In/Out bit) on this class queue. +RIO runs triple RED algorithms at the same time. +.It Cm ecn +Use RED/ECN (Explicit Congestion Notification) on this +class queue (experimental implementation). +ECN implies RED. +.It Cm cleardscp +Clear diffserv codepoint in the IP header. +.El +.Ss Filter Commands +.Bl -tag -width filter -offset indent +.It Cm filter +.Ar if_name +.Ar class_name +.Op Cm name Ar fltr_name +.Op Cm ruleno Ar num +.Ar filter_values +.El +.Pp +The +.Cm filter +command specifies a filter to classify packets into +a scheduling class. +A filter specifier determines any statically-defined packet +classification rules. +.Bl -tag -width 10n -offset indent +.It Ar if_name +Name of a network interface (e.g., fxp0). +.It Ar class_name +Name of a class or a conditioner to which matching packets are directed. +.It Cm name +Add an arbitrary name to the filter for a future reference. +.It Cm ruleno +Specifies explicit order of filter matching. +Filter matching is performed from a filter with a larger ruleno. +Default is 0. +.El +.Pp +.Ar filter_values +should be in the following format: +.Bl -tag -width filter -offset indent +.It Ar filter_values : +.Ad dst_addr Op Cm netmask Ar mask +.Ar dport +.Ad src_addr Op Cm netmask Ar mask +.Ar sport +.Ar proto +.Oo +.Cm tos +.Ar value +.Op Cm tosmask Ar value +.Oc +.Op Cm gpi Ar value +.El +.Pp +Here +.Ad dst_addr +and +.Ad src_addr +are dotted-decimal addresses of +the destination and the source respectively. +An address may be followed by +.Cm netmask +keyword. +.Ar dport +and +.Ar sport +are port numbers of the destination and the source respectively. +.Ar proto +is a protocol number defined for IP packets (e.g., 6 for TCP). +.Cm tos +keyword can be used to specify the type of service field value. +.Cm gpi +keyword can be used to specify the Security Parameter Index value for +IPsec. +.Pp +When filter value 0 is used, it is taken as a wildcard. +.Bl -tag -width filter6 -offset indent +.It Cm filter6 +.Ar if_name +.Ar class_name +.Op Cm name Ar fltr_name +.Op Cm ruleno Ar num +.Ar filter6_values +.El +.Pp +The +.Cm filter6 +command is for IPv6. +.Ar filter6_value +should be in the following format: +.Bl -tag -width filter6 -offset indent +.It filter6_values : +.Ad dst_addr Ns Op /prefix_len +.Ar dport +.Ad src_addr Ns Op /prefix_len +.Ar sport +.Ar proto +.Op Cm flowlabel Ar value +.Oo +.Cm tclass +.Ar value +.Op Cm tclassmask Ar value +.Oc +.Op Cm gpi Ar value +.El +.Pp +Here +.Ad dst_addr +and +.Ad src_addr +are IPv6 addresses of the destination and the source respectively. +An address may be followed by an optional address prefix length. +.Ar dport +and +.Ar sport +are port numbers of the destination and the source respectively. +.Ar proto +is a protocol number defined for IPv6 packets (e.g., 6 for TCP). +.Cm flowlabel +keyword can be used to specify the flowlabel field value. +.Cm tclass +keyword can be used to specify the traffic class field value. +.Cm gpi +keyword can be used to specify the Security Parameter Index value for +IPsec. +.Pp +When filter value 0 is used, it is taken as a wildcard. +.Ss CBQ Commands +CBQ (Class Based Queueing) achieves both partitioning and sharing of +link bandwidth by hierarchically structured classes. +Each class has its own queue and is assigned its share of bandwidth. +A child class can borrow bandwidth from its parent class as long as +excess bandwidth is available. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm efficient +.Op Cm no-control +.Op Cm no-tbr +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be either +.Cm cbq , +.Cm cbq-wrr +(weighted-round robin) or +.Cm cbq-prr +(packet-by-packet round robin). +.Cm cbq +is equivalent to +.Cm cbq-wrr . +.It Cm efficient +Enables CBQ's link efficiency mode. +This means that the scheduler will send a packet from the first +overlimit class it encounters of all classes of the link-sharing +structure when all classes are overlimit. +This will also cause the scheduler to use greater than its assigned +bandwidth, if the link is capable of more than the assigned bandwidth. +By default, this mode is turned off. +By adding the keyword +.Cm efficient +to the interface specification line, enables this mode. +.It Cm no-control +By default, the control class is automatically created when default class is +created and one doesn't exist yet. +This option suppresses the behavior on the interface. +.It Cm no-tbr +By default, a token bucket regulator is automatically created on each interface. +This option suppresses the behavior on the interface. +.El +.Bl -tag -width class -offset indent +.It Cm class +.Ar sched_type +.Ar if_name +.Ar class_name +.Ar parent_name +.Op Cm admission cntlload|none +.Op Cm priority Ar pri +.Op Cm pbandwidth Ar percent +.Op Cm exactbandwidth Ar bps +.Op Cm borrow +.Op Cm default +.Op Cm control +.Op Cm maxburst Ar count +.Op Cm minburst Ar count +.Bk -words +.Op Cm maxdelay Ar msec +.Ek +.Op Cm packetsize Ar bytes +.Op Cm maxpacketsize Ar bytes +.Op Cm red|rio +.Op Cm ecn +.Op Cm flowvalve +.Op Cm cleardscp +.El +.Pp +The +.Cm class +command specifies a CBQ class. +The classes are organized as a hierarchy, and every class, except +for the root class, has a parent. +.Bl -tag -width 8n -offset indent +.It Ar sched_type +must be +.Cm cbq +for a CBQ class. +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar class_name +Arbitrary name for this class. +Must be unique within the class +hierarchy for this interface. +The name +.Cm ctl_class +is a reserved class name. +.It Cm parent_name +The name of the parent class for this class or +.Dv NULL +if this is the root class. +Parent class must have been previously defined. +.It Cm admission +The type of admission control and QoS type. +.Cm cntlload +is controlled load service for RSVP, otherwise, it should be +.Cm none . +The default is +.Cm none . +.It Cm priority +High numbers are higher priority. +Max value is 7 and Min value is 0. +Default is 1. +.It Cm pbandwidth +The percentage of the interface bandwidth allocated to this class. +Generally should add up to 100 percent at each level of the class +hierarchy, although other amounts can be specified for purposes of +experimentation. +.It Cm exactbandwidth +Specify the bandwidth in bits-per-second instead of +.Cm pbandwidth . +Note that the bandwidth allocation of CBQ is not so precise but this +is just a way to pass a parameter to CBQ; the user is supposed to know +the detailed internals of CBQ. +.Cm pbandwidth +is a preferred way to specify the bandwidth of a class. +.It Cm borrow +The class can borrow bandwidth from its parent class when this class +is overlimit. +If this keyword is not present, then no borrowing is done, and the +packet is delayed or dropped when the class is overlimit. +.It Cm default +Specify the default class. +When this keyword is present, all packets that do not match some +classification criteria are assigned to this class. +Must be exactly one class on each interface defined as the default +class. +.It Cm control +Specify the control class. +When this keyword is present, the predefined control class packets +(RSVP, IGMP, and ICMP) are assigned to this class. +Note that when the control class is not specified by the time the +default class is created, one is automatically created with default +parameters. +Thus, if the control class is specified, it must be listed before the +default class. +Must be exactly one class on each interface defined as the control +class. +.It Cm maxburst +The maximum burst of back-to-back packets allowed in this class. +Default is 16 but the default value is automatically reduced to 4 when +the class bandwidth is small (about less than 1Mbps). +.It Cm minburst +The minimum burst is used to obtain the steady state burst size. +It's the parameter to help compute offtime for the class. +Offtime is the amount of time a class is to wait between packets. +Default is 2. +.It Cm maxdelay +The maxdelay is specified in milliseconds and used to obtain the max +queue size of the class. +If not specified, the default max queue size (30 packets) is used. +.It Cm packetsize +The average packet size in bytes to be used in CBQ over-/under-limit +computations. +Default value is MTU of the interface. +.It Cm maxpacketsize +The maximum packet size in bytes for the class. +Default value is MTU of the interface. +.It Cm red +enables RED on this class queue. +.It Cm rio +enables RIO on this class queue. +.It Cm ecn +enables RED/ECN on this class queue. +.It Cm flowvalve +enables RED/flow-valve (a.k.a. red-penalty-box) on this class queue. +.It Cm cleardscp +clears diffserv codepoint in the IP header. +.El +.Ss HFSC Commands +HFSC (Hierarchical Fair Service Curve) supports both link-sharing and +guaranteed real-time services. +H-FSC employs a service curve based QoS model, and its unique feature +is an ability to decouple delay and bandwidth allocation. +HFSC has 2 independent scheduling mechanisms. +Real-time scheduling is used to guarantee the delay and the +bandwidth allocation at the same time. +Hierarchical link-sharing is used to distribute the excess +bandwidth. +When dequeueing a packet, HFSC always tries real-time scheduling +first. +If no packet is eligible for real-time scheduling, link-sharing +scheduling is performed. +HFSC does not use class hierarchy for real-time scheduling. +Additionally, an upper-limit service curve can be specified for +link-sharing to set the upper limit allowed for the class. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm hfsc +for HFSC. +.El +.Bl -tag -width class -offset indent +.It Cm class +.Ar sched_type +.Ar if_name +.Ar class_name +.Ar parent_name +.Op Cm admission cntlload|none +.Op Bq Cm sc Ar m1 d m2 +.Op Bq Cm rt Ar m1 d m2 +.Op Bq Cm ls Ar m1 d m2 +.Op Bq Cm ul Ar m1 d m2 +.Op Cm pshare Ar percent +.Op Cm grate Ar bps +.Op Cm bandwidth Ar bps +.Op Cm ulimit Ar bps +.Op Cm default +.Op Cm qlimit Ar count +.Op Cm red|rio +.Op Cm ecn +.Op Cm cleardscp +.El +.Pp +The +.Cm class +command specifies a HFSC class. +The classes are organized as a hierarchy, and every class, except +for the root class, has a parent. +.Pp +Each HFSC class has 2 service curves, the real-time service curve and +the link-sharing service curve. +Service curves are specified by +.Bq Ar type Ar m1 d m2 . +.Ar type +should be either +.Cm sc , rt , ls , +or +.Cm ul . +.Cm sc +(service curve) is used to set the same values to both real-time and +link-sharing service curves. +.Cm rt +(real-time) is used to specify the real-time service curve. +.Cm ls +(link-sharing) is used to specify the link-sharing service curve. +.Cm ul +(upper-limit) is used to specify the upper-limit service curve for +link-sharing. +.Ar m1 +is the slope of the first segment specified in bits-per-second. +.Ar d +is the x-projection of the intersection point of the 2 segments +specified in milliseconds. +.Ar m2 +is the slope of the second segment specified in bits-per-second. +.Bl -tag -width 8n -offset indent +.It Ar sched_type +must be +.Cm hfsc +for a HFSC class. +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar class_name +Arbitrary name for this class. +Must be unique within the class hierarchy for this interface. +The name +.Cm root +is a reserved class name for the root class. +The root class for the interface is automatically created by the +.Cm interface +command. +.It Ar parent_name +The name of the parent class for this class. +Keyword +.Cm root +is used when the parent is the root class. +Parent class must have been previously defined. +.It Cm admission +The type of admission control and QoS type. +.Cm cntlload +is controlled load service for RSVP, otherwise, it should be +.Cm none . +The default is +.Cm none . +.It Cm pshare +Percent of the link share. +This specifies a linear link-sharing service curve as a fraction of +the link bandwidth. +It is a short hand of +.Li [ls 0 0 (link-bandwidth * percent / 100)] . +.It Cm grate +Guaranteed rate. +This specifies a linear real-time service curve. +It is a short hand of +.Li [rt 0 0 bps] . +.It Cm bandwidth +This is a short hand of +.Li [sc 0 0 bps] . +.It Cm ulimit +Upper limit rate. +This specifies a upper-limit service curve. +It is a short hand of +.Li [ul 0 0 bps] . +.It Cm default +Specify the default class. +When this keyword is present, all packets that do not match some +classification criteria are assigned to this class. +Must be exactly one class on each interface defined as the default +class. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 50. +.It Cm red +enables RED on this class queue. +.It Cm rio +enables RIO on this class queue. +.It Cm ecn +enables RED/ECN on this class queue. +.It Cm cleardscp +clears diffserv codepoint in the IP header. +.El +.Ss PRIQ Commands +PRIQ (Priority Queueing) implements simple priority-based queueing. +A higher priority class is always served first. +Up to 16 priorities can be used with PRIQ. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm priq +for PRIQ. +.El +.Bl -tag -width class -offset indent +.It Cm class +.Ar sched_type +.Ar if_name +.Ar class_name +.Ar parent_name +.Op Cm priority Ar pri +.Op Cm default +.Op Cm qlimit Ar count +.Op Cm red|rio +.Op Cm ecn +.Op Cm cleardscp +.El +.Bl -tag -width 8n -offset indent +.It Ar sched_type +must be +.Cm priq +for a PRIQ class. +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar class_name +Arbitrary name for this class. +Must be unique for this interface. +.It Ar parent_name +Parent class must be +.Dv NULL +for PRIQ. +.It Cm priority +High numbers are higher priority. +Max value is 15 and Min value is 0. +Default is 0. +A higher priority class is always served first in PRIQ. +Priority must be unique for the interface. +.It Cm default +Specify the default class. +When this keyword is present, all packets that do not match some +classification criteria are assigned to this class. +Must be exactly one class on each interface defined as the default +class. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 50. +.It Cm red +enables RED on this class queue. +.It Cm rio +enables RIO on this class queue. +.It Cm ecn +enables RED/ECN on this class queue. +.It Cm cleardscp +clears diffserv codepoint in the IP header. +.El +.Ss WFQ Commands +WFQ (Weighted Fair Queueing) implements a weighted-round robin +scheduler for a set of queue. +A weight can be assigned to each queue to give a +different proportion of the link capacity. +A hash function is used to map a flow to one of a set of queues, and +thus, it is possible for two different flows to be mapped into the same +queue. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm nqueues Ar count +.Op Cm qsize Ar bytes +.Op Cm hash Ar policy +.El +.Bl -tag -width 8n -offset indent +.It Cm if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm wfq +for WFQ. +.It Cm nqueues +The number of queues in WFQ. +Default value is 256. +.It Cm qsize +The size of each queue in number of bytes. +Default value is 64K bytes. +.It Cm hash +Type of hash policy to select a queue. +.Cm dstaddr +specifies a hashing policy by IP destination address. +.Cm full +specifies a hashing policy by IP addresses and ports. +.Cm srcport +specifies a hashing policy by IP source port number. +.Cm srcaddr +specifies a hashing policy by IP source address. +Default is +.Cm dstaddr +.El +.Ss FIFOQ Commands +FIFOQ (First-In First-Out Queueing) is a simple tail-drop FIFO queue. +FIFOQ is the simplest possible implementation of a queueing discipline +in ALTQ, and can be used to compare with other queueing disciplines. +FIFOQ can be also used as a template for those who want to write their +own queueing disciplines. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm qlimit Ar count +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm fifoq +for FIFOQ. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 50. +.El +.Ss RED Commands +RED (Random Early Detection) is an implicit congestion notification +mechanism that exercises packet dropping or packet marking +stochastically according to the average queue length. +RED can be viewed as a buffer management mechanism +and can be integrated into other packet scheduling schemes. +.Bl -tag -width red -offset indent +.It Cm red +.Ar min_th +.Ar max_th +.Ar inv_pmax +.El +.Pp +The +.Cm red +command sets the default RED parameters. +.Ar min_th +and +.Ar max_th +are the minimum and the maximum threshold values. +.Ar inv_pmax +is the inverse (reciprocal) of the maximum drop probability. +For example, 10 means the maximum drop probability of 1/10. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm qlimit Ar count +.Op Cm packetsize Ar bytes +.Op Cm weight Ar n +.Op Cm thmin Ar n +.Op Cm thmax Ar n +.Op Cm invpmax Ar n +.Op Cm ecn +.Op Cm flowvalve +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm red +for RED. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 60. +.It Cm packetsize +The average packet size in number of bytes. +This parameter is used to calibrate the idle period. +Default value is 1000. +.It Cm weight +The inverse of the weight of EWMA (exponentially weighted moving average). +.It Cm thmin +The minimum threshold. +.It Cm thmax +The maximum threshold. +.It Cm invpmax +The inverse of the maximum drop probability. +.It Cm ecn +enables ECN. +.It Cm flowvalve +enables flowvalve. +.El +.Ss RIO Commands +ALTQ/RIO has 3 drop precedence levels defined for the Assured +Forwarding of DiffServ (RFC2597). +Since adaptive flows are likely to stay under the medium drop +precedence level under congestion, the medium drop precedence would +protect adaptive flows from unadaptive flows. +.Pp +The original RIO has 2 sets of RED parameters; one for in-profile +packets and the other for out-of-profile packets. +At the ingress of the network, profile meters tag packets as IN +or OUT based on contracted profiles for customers. +Inside the network, IN packets receive preferential treatment by +the RIO dropper. +It is possible to provision the network not to drop IN packets +at all by providing enough capacity for the total volume of IN +packets. +Thus, RIO can be used to provide a service that statistically assures +capacity allocated for users. +This mechanism can be extended to support an arbitrary number of drop +precedence levels. +ALTQ supports 3 drop precedence levels. +.Bl -tag -width rio -offset indent +.It Cm rio +.Ar low_min_th +.Ar low_max_th +.Ar low_inv_pmax +.Ar medium_min_th +.Ar medium_max_th +.Ar medium_inv_pmax +.Ar high_min_th +.Ar high_max_th +.Ar high_inv_pmax +.El +.Pp +The +.Cm rio +command sets the default RIO parameters. +The parameters are RED parameters for 3 (low, medium, high) drop +precedence. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm qlimit Ar count +.Op Cm packetsize Ar bytes +.Op Cm weight Ar n +.Op Cm lo_thmin Ar n +.Op Cm lo_thmax Ar n +.Op Cm lo_invpmax Ar n +.Op Cm med_thmin Ar n +.Op Cm med_thmax Ar n +.Op Cm med_invpmax Ar n +.Op Cm hi_thmin Ar n +.Op Cm hi_thmax Ar n +.Op Cm hi_invpmax Ar n +.Op Cm ecn +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm rio +for RIO. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 60. +.It Cm packetsize +The average packet size in number of bytes. +This parameter is used to calibrate the idle period. +Default value is 1000. +.It Cm weight +The inverse of the weight of EWMA (exponentially weighted moving average). +.It Cm lo_thmin +The minimum threshold for low drop precedence. +.It Cm lo_thmax +The maximum threshold for low drop precedence. +.It Cm lo_invpmax +The inverse of the maximum drop probability for low drop precedence. +.It Cm med_thmin +The minimum threshold for medium drop precedence. +.It Cm med_thmax +The maximum threshold for medium drop precedence. +.It Cm med_invpmax +The inverse of the maximum drop probability for medium drop precedence. +.It Cm hi_thmin +The minimum threshold for high drop precedence. +.It Cm hi_thmax +The maximum threshold for high drop precedence. +.It Cm hi_invpmax +The inverse of the maximum drop probability for high drop precedence. +.It Cm ecn +enables ECN. +.El +.Ss BLUE Commands +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.Op Cm qlimit Ar count +.Op Cm packetsize Ar bytes +.Op Cm maxpmark Ar n +.Op Cm holdtime Ar usec +.Op Cm ecn +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm blue +for BLUE. +.It Cm qlimit +The maximum queue size in number of packets. +Default value is 60. +.It Cm packetsize +The average packet size in number of bytes. +Default value is 1000. +.It Cm maxpmark +specifies the precision of marking probability. +.It Cm holdtime +specifies the hold time in usec. +.It Cm ecn +enables ECN. +.El +.Ss CDNR Commands +The +.Cm conditioner +command specifies a diffserv traffic conditioner. +A traffic conditioner is not a queueing discipline but a component to +meter, mark or drop incoming packets according to some rules. +.Pp +As opposed to a queueing discipline, a traffic conditioner handles +incoming packets at an input interface. +If no queueing discipline (e.g., CBQ) is used for the interface, +a null interface command should be used to specify an input network +interface. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm tbrsize Ar bytes +.El +.Pp +The +.Cm conditioner +command has the following syntax. +.Bl -tag -width conditioner -offset indent +.It Cm conditioner +.Ar if_name +.Ar cdnr_name +.Aq action +.El +.Bl -tag -width 10n -offset indent +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar cdnr_name +Arbitrary name for this conditioner. +Must be unique for this interface. +.It Ar action +Action of the conditioner. +.El +.Pp +An action can be a recursively defined action. +The following actions are defined. +.Bl -tag -width pass -offset indent +.It Cm pass +.Bl -inset -offset indent +.It Cm pass +allows the packet to go through without any modification to the packet. +.El +.El +.Bl -tag -width drop -offset indent +.It Cm drop +.Bl -inset -offset indent +.It Cm drop +rejects the packet. +The packet is immediately discarded. +.El +.El +.Bl -tag -width mark -offset indent +.It Cm mark +.Ar value +.Bl -inset -offset indent +.It Cm mark +sets the specified value to the ds field in the IP header. +Then, the packet is allowed to go through. +.El +.El +.Bl -tag -width tbmeter -offset indent +.It Cm tbmeter +.Ar rate depth +.Aq in_action +.Aq out_action +.Bl -inset -offset indent +.It Cm tbmeter +is a token bucket meter configured with rate and depth parameters. +Rate is token rate in bits-per-second. +Depth is bucket depth in KB. +When an incoming packet is in profile (available token is more than +the packet size), tbmeter takes in_action. +Otherwise, tbmeter takes out_action. +.El +.El +.Bl -tag -width trtcm -offset indent +.It Cm trtcm +.Ar cmtd_rate cmtd_depth peak_rate peak_depth +.Aq green_action +.Aq yellow_action +.Aq red_action +.Op Cm coloraware|colorblind +.Bl -inset -offset indent +.It Cm trtcm +is a 2-rate 3 color marker for Assured Forwarding. +A trtcm consists of 2 token buckets, one for a committed rate and the +other for a peak rate. +When an incoming packet is in the committed profile, trtcm takes +green_action. +When the packet is out of the committed profile but in the peak +profile, trtcm takes yellow_action. +Otherwise, tbtcm takes red_action. +A trtcm is either color-aware or color-blind. +A color-aware trtcm do not raise the color (ds field value), that is, +a yellow packet can be yellow or red but can not be blue. +Default is color-blind. +.El +.El +.Bl -tag -width tswtcm -offset indent +.It Cm tswtcm +.Ar cmtd_rate peak_rate avg_interval +.Aq green_action +.Aq yellow_action +.Aq red_action +.Bl -inset -offset indent +.It Cm tswtcm +is a time sliding window 3 color marker for Assured Forwarding. +A tswtcm differs from trtcm in that a tswtcm probabilistically marks +packets. +A tswtcm consists of 2 rates, one for a committed rate and the +other for a peak rate. +When an incoming packet is in the committed profile, tswtcm takes +green_action. +When the packet is out of the committed profile but in the peak +profile, tswtcm takes yellow_action. +Otherwise, tswtcm takes red_action. +cmtd_rate and peak_rate are specified in bits per second. +avg_interval provides the size of time window for averaging incoming +rate, and is specified in milliseconds. +500 msec is ok for normal settings. +.El +.El +.Ss JoBS Commands +JoBS (Joint Buffer Management and Scheduling) is a queuing discipline +that can enforce any feasible mix of absolute and proportional guarantees +on packet losses, packet delays, and throughput, for classes of traffic, +on a per-hop basis. +No admission control is performed, thus if the set of service +guarantees becomes infeasible, some service guarantees may be +relaxed. +.Bl -tag -width interface -offset indent +.It Cm interface +.Ar if_name +.Op Cm bandwidth Ar bps +.Op Cm qlimit Ar count +.Op Cm separate +.Op Cm tbrsize Ar bytes +.Op Ar sched_type +.El +.Bl -tag -width 8n -offset indent +.It Ar if_name +specifies the name of a network interface (e.g., fxp0). +.It Cm bandwidth +specifies the interface bandwidth in bits per second. +.It Cm qlimit +specifies the maximum queue size in number of packets. +.It Cm separate +specifies that classes have independent buffers. +The default is to have a shared buffer for all classes. +If this option is specified, qlimit applies to each independent +buffer. +.It Cm tbrsize +specifies the bucket size of a token bucket regulator in bytes. +.It Ar sched_type +must be +.Cm jobs +for JoBS. +.El +.Bl -tag -width class -offset indent +.It Cm class +.Ar sched_type +.Ar if_name +.Ar class_name +.Ar parent_name +.Op Cm priority Ar pri +.Op Cm default +.Op Cm adc Ar microsecs +.Op Cm alc Ar fraction +.Op Cm arc Ar bps +.Op Cm rdc Ar prop +.Op Cm rlc Ar prop +.El +.Bl -tag -width 8n -offset indent +.It Ar sched_type +must be +.Cm jobs +for a JoBS class. +.It Ar if_name +Interface name. +Must correspond to name in interface specification. +.It Ar class_name +Arbitrary name for this class. +Must be unique for this interface. +.It Ar parent_name +Parent class must be +.Dv NULL +for JoBS. +.It Cm priority +Priority index used for proportional differentiation. +Max value is 15 and Min value is 0. +Default is 0. +Priority must be unique for the interface. +.It Cm default +Specify the default class. +When this keyword is present, all packets that do not match some +classification criteria are assigned to this class. +Must be exactly one class on each interface defined as the +default class. +.It Cm adc +Specifies an upper bound on delays for that class (in microseconds). +A value of \-1 will indicate the absence of delay bound. +By default, no delay bound is offered. +.It Cm alc +Specifies a upper bound on loss rate for that class (in fraction of 1, +for instance a 1% loss rate bound will be expressed as 0.01). +A value of \-1 will indicate the absence of loss rate bound. +By default, no loss rate bound is offered. +.It Cm arc +Specifies a lower bound +on the throughput received by that class (in bits per second). +A value of +\-1 will indicate the absence of throughput bound. +By default, no throughput bound is offered. +.It Cm rdc +Specifies a proportional delay differentiation factor between that class +and the class with the successive priority index. +For instance, for priority 1, an rdc of 2 specifies that the delays of +packets marked as class 2 will roughly be twice the delays of packets +marked as class 1. +A value of +\-1 indicates the absence of proportional differentiation on that class. +Note that class N if N is the maximum priority should have a dummy +coefficient different from \-1 if proportional delay differentiation is desired +on Class N. +By default, no proportional delay differentiation is offered. +.It Cm rlc +Specifies a proportional loss differentiation factor between that class +and the class with the successive priority index. +For instance, for priority 1, an rlc of 2 specifies that the loss rate of +packets marked as class 2 will roughly be twice the loss rate of packets +marked as class 1. +A value of +\-1 indicates the absence of proportional differentiation on that class. +Note that class N if N is the maximum priority should have a dummy +coefficient different from \-1 if proportional loss differentiation is desired +on Class N. +By default, no proportional loss differentiation is offered. +.El +.Sh EXAMPLES +.Ss CBQ Example +.Bd -literal +# +# cbq configuration for vx0 (10Mbps ether) +# give at least 40% to TCP +# limit HTTP from network 133.138.1.0 up to 10%, use RED. +# other traffic goes into default class +# +interface vx0 bandwidth 10M cbq +# +class cbq vx0 root_class NULL priority 0 pbandwidth 100 +class cbq vx0 def_class root_class borrow pbandwidth 95 default +class cbq vx0 tcp_class def_class borrow pbandwidth 40 + filter vx0 tcp_class 0 0 0 0 6 +class cbq vx0 csl_class tcp_class pbandwidth 10 red + filter vx0 csl_class 0 0 133.138.1.0 netmask 0xffffff00 80 6 + filter vx0 csl_class 133.138.1.0 netmask 0xffffff00 0 0 80 6 +# +# sample filter6 command +# + filter6 vx0 csl_class ::0 0 2001:db8:0:123::/64 80 6 +.Ed +.Ss HFSC Example +.Bd -literal +# +# hfsc configuration for hierarchical sharing +# +interface pvc0 bandwidth 45M hfsc +# +# (10% of the bandwidth share goes to the default class) +class hfsc pvc0 def_class root pshare 10 default +# +# bandwidth share guaranteed rate +# CMU: 45% 15Mbps +# PITT: 45% 15Mbps +# +class hfsc pvc0 cmu root pshare 45 grate 15M +class hfsc pvc0 pitt root pshare 45 grate 15M +# +# CMU bandwidth share guaranteed rate +# CS: 20% 10Mbps +# other: 20% 5Mbps +# +class hfsc pvc0 cmu_other cmu pshare 20 grate 10M + filter pvc0 cmu_other 0 0 128.2.0.0 netmask 0xffff0000 0 0 +class hfsc pvc0 cmu_cs cmu pshare 20 grate 5M + filter pvc0 cmu_cs 0 0 128.2.242.0 netmask 0xffffff00 0 0 +# +# PITT bandwidth share guaranteed rate +# CS: 20% 10Mbps +# other: 20% 5Mbps +# +class hfsc pvc0 pitt_other pitt pshare 20 grate 10M + filter pvc0 pitt_other 0 0 136.142.0.0 netmask 0xffff0000 0 0 +class hfsc pvc0 pitt_cs pitt pshare 20 grate 5M + filter pvc0 pitt_cs 0 0 136.142.79.0 netmask 0xffffff00 0 0 +.Ed +.Ss HFSC Example (simpler one with ulimit) +.Bd -literal +# +interface fxp0 bandwidth 90M hfsc +# reserve 20% for default class +class hfsc fxp0 def_class root pshare 20 default +# shared class for TCP and UDP +class hfsc fxp0 shared_class root bandwidth 72M +# shared class for all TCP +class hfsc fxp0 tcp_shared shared_class bandwidth 40M ulimit 60M +# generic tcp +class hfsc fxp0 tcp_class tcp_shared bandwidth 15M ulimit 50M + filter fxp0 tcp_class 0 0 0 0 6 +# http +class hfsc fxp0 http_class tcp_shared bandwidth 25M ulimit 40M + filter fxp0 http_class 0 80 0 0 6 + filter fxp0 http_class 0 0 0 80 6 +# udp +class hfsc fxp0 udp_class shared_class bandwidth 15M ulimit 20M + filter fxp0 udp_class 0 0 0 0 17 +.Ed +.Ss PRIQ Example +.Bd -literal +# +# priq configuration for fxp0 (100Mbps ether) +# icmp: high priority +# tcp: medium priority +# others: low priority +# +interface fxp0 bandwidth 100M priq +# +class priq fxp0 high_class NULL priority 2 + filter fxp0 high_class 0 0 0 0 1 +class priq fxp0 med_class NULL priority 1 + filter fxp0 med_class 0 0 0 0 6 +class priq fxp0 low_class NULL priority 0 default +.Ed +.Ss WFQ Example +.Bd -literal +interface pvc0 bandwidth 134000000 wfq +.Ed +.Ss FIFOQ Example +.Bd -literal +interface rl0 bandwidth 10M fifoq +.Ed +.Ss Conditioner Example +.Bd -literal +# +interface fxp0 +# +# a simple dropper +# discard all packets from 192.168.0.83 +# +conditioner fxp0 dropper + filter fxp0 dropper 0 0 192.168.0.83 0 0 + +# +# EF conditioner +# mark EF to all packets from 192.168.0.117 +# +conditioner pvc1 ef_cdnr > + filter fxp0 ef_cdnr 0 0 192.168.0.117 0 0 + +# +# AF1x conditioner +# mark AF1x to packets from 192.168.0.178 +# AF11 (low drop precedence): less than 3Mbps +# AF12 (medium drop precedence): more than 3Mbps and less than 10Mbps +# AF13 (high drop precedence): more than 10Mbps +# +conditioner fxp0 af1x_cdnr > + filter fxp0 af1x_cdnr 0 0 192.168.0.178 0 0 +.Ed +.Sh SEE ALSO +.Xr altqd 8 +.Sh BUGS +This man page is incomplete. +For more information read the source. diff --git a/static/netbsd/man5/amd.conf.5 b/static/netbsd/man5/amd.conf.5 new file mode 100644 index 00000000..cf3d4923 --- /dev/null +++ b/static/netbsd/man5/amd.conf.5 @@ -0,0 +1,788 @@ +.\" $NetBSD: amd.conf.5,v 1.1.1.3 2015/01/17 16:34:18 christos Exp $ +.\" +.\" +.\" Copyright (c) 1997-2014 Erez Zadok +.\" Copyright (c) 1990 Jan-Simon Pendry +.\" Copyright (c) 1990 Imperial College of Science, Technology & Medicine +.\" Copyright (c) 1990 The Regents of the University of California. +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to Berkeley by +.\" Jan-Simon Pendry at Imperial College, London. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" +.\" File: am-utils/scripts/amd.conf.5 +.\" +.TH AMD.CONF 5 "7 August 1997" +.SH NAME +amd.conf \- Amd configuration file +.SH SYNOPSIS +.B amd.conf +.SH DESCRIPTION +The +.B amd.conf +file is the configuration file for Amd, as part of the am-utils suite. +.P +.B amd.conf +contains runtime configuration information for the +.B Amd +automounter program. +.\" ************************************************************************** +.SH FILE FORMAT +.P +The file consists of sections and parameters. A section begins with the +name of the section in square brackets and continues until the next section +begins or the end the file is reached. Sections contain parameters of the +form 'name = value'. +.P +The file is line-based - that is, each newline-terminated line represents +either a comment, a section name or a parameter. No line-continuation +syntax is available. +.P +Section, parameter names and their values are case sensitive. +.P +Only the first equals sign in a parameter is significant. Whitespace before +or after the first equals sign is discarded. Leading, trailing and +internal whitespace in section and parameter names is irrelevant. Leading +and trailing whitespace in a parameter value is discarded. Internal +whitespace within a parameter value is not allowed, unless the whole +parameter value is quoted with double quotes as in 'name = "some value"'. +.P +Any line beginning with a pound sign (#) is ignored, as are lines containing +only whitespace. +.P +The values following the equals sign in parameters are all either a string +(no quotes needed if string does not include spaces) or a boolean, which may +be given as yes/no. Case is significant in all values. Some items such as +cache timeouts are numeric. +.\" ************************************************************************** +.SH SECTIONS +.SS The [global] section +Parameters in this section either apply to Amd as a whole, or to all other +regular map sections which follow. There should be only one global section +defined in one configuration file. +.P +It is highly recommended that this section be specified first in the +configuration file. If it is not, then regular map sections which precede +it will not use global values defined later. + +.SS Regular [/map] sections +Parameters in regular (non-global) sections apply to a single map entry. +For example, if the map section +.B [/homes] +is defined, then all parameters following it will be applied to the +.I /homes +Amd-managed mount point. +.\" ************************************************************************** +.SH PARAMETERS +.SS Parameters common to all sections +These parameters can be specified either in the global or a map specific +section. Entries specified in a map-specific section override the default +value or one defined in the global section. If such a common parameter is +specified only in the global section, it is applicable to all regular map +sections that follow. +.\" ************************************************************************** +.TP +.BR browsable_dirs " (string, default=no)" +If "yes," then Amd's top-level mount points will be browsable to +.BR readdir (3) +calls. This means you could run for example +.BR ls (1) +and see what keys are available to mount in that directory. Not all entries +are made visible to readdir(3): the "/default" entry, wildcard +entries, and those with a "/" in them are not included. If you specify +"full" to this option, all but "/default" will be visible. +Note that if you run a command which will attempt to +.BR stat (2) +the entries, such as often done by "ls -l" or "ls -F," Amd will attempt to +mount +.I every +entry in that map. This is often called a ``mount storm.'' + +.TP +.BR map_defaults " (string, default to empty)" +This option sets a string to be used as the map's /defaults entry, +overriding any /defaults specified in the map. This allows local users to +override map defaults without modifying maps globally. + +.TP +.BR map_options " (string, default no options)" +This option is the same as specifying map options on the command line to +Amd, such as "cache:=all". + +.TP +.BR map_type " (string, default search all map types)" +If specified, Amd will initialize the map only for the type given. This is +useful to avoid the default map search type used by Amd which takes longer +and can have undesired side-effects such as initializing NIS even if not +used. Possible values are + +.nf +\fBexec\fR executable maps +\fBfile\fR plain files +\fBhesiod\fR Hesiod name service from MIT +\fBldap\fR Lightweight Directory Access Protocol +\fBndbm\fR (New) dbm style hash files +\fBnis\fR Network Information Services (version 2) +\fBnisplus\fR Network Information Services Plus (version 3) +\fBpasswd\fR local password files +\fBunion\fR union maps +.fi + +.TP +.BR mount_type " (string, default=nfs)" +All Amd mount types default to NFS. That is, Amd is an NFS server on the +map mount points, for the local host it is running on. If "autofs" is +specified, Amd will be an autofs server for those mount points. + +.TP +.BR autofs_use_lofs " (string, default=yes)" +When set to "yes" and using Autofs, Amd will use lofs-type (loopback) mounts +for type:=link mounts. This has the advantage of mounting in place, and +users get to the see the same pathname that they chdir'ed into. If this +option is set to "no," then Amd will use symlinks instead: that code is more +tested, but negates autofs's big advantage of in-place mounts. + +.TP +.BR search_path " (string, default no search path)" +This provides a (colon-delimited) search path for file maps. Using a search +path, sites can allow for local map customizations and overrides, and can +distributed maps in several locations as needed. + +.TP +.BR selectors_in_defaults " (boolean, default=no)" +If "yes," then the /defaults entry of maps will search for and process any +selectors before setting defaults for all other keys in that map. Useful +when you want to set different options for a complete map based on some +parameters. For example, you may want to better the NFS performance over +slow slip-based networks as follows: + +.nf +/defaults \\ + wire==slip-net;opts:=intr,rsize=1024,wsize=1024 \\ + wire!=slip-net;opts:=intr,rsize=8192,wsize=8192 +.fi + +Deprecated form: selectors_on_default + +.TP +.BR sun_map_syntax " (boolean, default=no)" +If "yes," then Amd will parse the map according to the Sun Automount syntax. + +.\" ************************************************************************** +.SS Parameters applicable to the global section only + +.TP +.BR arch " (string, default to compiled in value)" +Same as the +.B \-A +option to Amd. Allows you to override the value of the +.I arch +Amd variable. + +.TP +.BR auto_attrcache " (numeric, default=0)" +Specify in seconds (or units of 0.1 seconds, depending on the OS), what is +the (kernel-side) NFS attribute cache timeout for @i{Amd}'s own automount +points. A value of 0 is supposed to turn off attribute caching, meaning +that @i{Amd} will be consulted via a kernel-RPC each time someone stat()'s +the mount point (which could be abused as a denial-of-service attack). +Warning: some OSs are incapable of turning off the NFS attribute cache +reliably. On such systems, Amd may not work reliably under heavy load. See +the README.attrcache document in the Am-utils distribution for more details. + +.TP +.BR auto_dir " (string, default=/a)" +Same as the +.B \-a +option to Amd. This sets the private directory where Amd will create +sub-directories for its real mount points. + +.TP +.BR cache_duration " (numeric, default=300)" +Same as the +.B \-c +option to Amd. Sets the duration in seconds that looked-up or mounted map +entries remain in the cache. + +.TP +.BR cluster " (string, default no cluster)" +Same as the +.B \-C +option to Amd. Specifies the alternate HP-UX cluster to use. + +.TP +.BR debug_mtab_file " (string, default=/tmp/mnttab)" +Path to mtab file that is used by Amd to store a list of mounted +file systems during debug-mtab mode. This option only applies +to systems that store mtab information on disk. +.TP + +.TP +.BR debug_options " (string, default no debug options)" +Same as the +.B \-D +option to Amd. Specify any debugging options for Amd. Works only if +am-utils was configured for debugging using the --enable-debug option. The +"mem" option, as well as all other options, can be turned on via +--enable-debug=mem. Otherwise debugging options are ignored. Options are +comma delimited, and can be preceded by the string "no" to negate their +meaning. You can get the list of supported debugging options by running Amd +\-H. Possible values are: + +.nf +\fBall\fR all options (excludes hrtime and mtab) +\fBdefaults\fR "sensible" default options (all--excluding hrtime, mtab, and xdrtrace) +\fBtest\fR full debug options plus mtab,nodaemon,nofork,noamq +\fBamq\fR register for amq +\fBdaemon\fR enter daemon mode +\fBfork\fR fork server +\fBfull\fR program trace +\fBhrtime\fR print high resolution time stamps (only if syslog(3) is not used) +\fBinfo\fR info service specific debugging (hesiod, nis, etc.) +\fBmem\fR trace memory allocations +\fBmtab\fR use local "/tmp/mtab" file +\fBreaddir\fR show browsable_dirs progress +\fBstr\fR debug string munging +\fBtrace\fR trace protocol and NFS mount arguments +\fBxdrtrace\fR trace XDR routines +.fi + +.TP +.BR dismount_interval " (numeric, default=120)" +Same as the +.B \-w +option to Amd. Specify in seconds, the time between attempts to dismount +file systems that have exceeded their cached times. + +.TP +.BR domain_strip " (boolean, default=yes)" +If "yes," then the domain +name part referred to by ${rhost} is stripped off. This is +useful to keep logs and smaller. If "no," then the domain name +part is left changed. This is useful when using multiple domains with +the same maps (as you may have hosts whose domain-stripped name is +identical). + +.TP +.BR exec_map_timeout " (numeric, default=10)" +The timeout in seconds that +.I Amd +will wait for an executable map program before an answer is returned from +that program (or script). This value should be set to as small as possible +while still allowing normal replies to be returned before the timer expires, +because during the time that the executable map program is queried, +.I Amd +is essentially waiting and is thus not responding to any other queries. + +.TP +.BR forced_unmounts " (boolean, default=no)" +If set to "yes," and the client OS supports forced or lazy unmounts, then +.I Amd +will attempt to use them if it gets any of three serious error conditions +when trying to unmount an existing mount point or mount on top of one: EIO, +ESTALE, or EBUSY. + +This could be useful to recover from serious conditions such as hardware +failure of mounted disks, or NFS servers which are down permanently, were +migrated, or changed their IP address. Only "type:=toplvl" mounts hung with +EBUSY are forcibly unmounted using this option, which is useful to recover +from a hung +.IR Amd ). + +.TP +.BR full_os " (string, default to compiled in value)" +The full name of the operating system, along with its version. Allows you +to override the compiled-in full name and version of the operating system. +Useful when the compiled-in name is not desired. For example, the full +operating system name on linux comes up as ``linux'', but you can override +it to ``linux-2.2.5.'' + +.TP +.BR fully_qualified_hosts " (string, default=no)" +If "yes," +.I Amd +will perform RPC authentication using fully-qualified host names. This is +necessary for some systems, and especially when performing cross-domain +mounting. For this function to work, the +.I Amd +variable ${hostd} is used, requiring that ${domain} not be null. + +.TP +.BR hesiod_base " (string, default=automount)" +Specify the base name for hesiod maps. + +.TP +.BR karch " (string, default to karch of the system)" +Same as the +.B \-k +option to Amd. Allows you to override the kernel-architecture of your +system. Useful for example on Sun (Sparc) machines, where you can build one +Amd binary, and run it on multiple machines, yet you want each one to get +the correct +.I karch +variable set (for example, sun4c, sun4m, sun4u, etc.) Note that if not +specified, Amd will use uname(3) to figure out the kernel architecture of +the machine. + +.TP +.BR ldap_base " (string, default not set)" +Specify the base name for LDAP. This often includes LDAP-specific +values such as country and organization. + +.TP +.BR ldap_cache_maxmem " (numeric, default=131072)" +Specify the maximum memory Amd should use to cache LDAP entries. + +.TP +.BR ldap_cache_seconds " (numeric, default=0)" +Specify the number of seconds to keep entries in the cache. + +.TP +.BR ldap_hostports " (string, default not set)" +Specify the LDAP host and port values. + +.TP +.BR ldap_proto_version " (numeric, default=2)" +Specify the version of the LDAP protocol to use. + +.TP +.BR local_domain " (string, default no sub-domain)" +Same as the +.B \-d +option to Amd. Specify the local domain name. If this option is not given +the domain name is determined from the hostname, by removing the first +component of the fully-qualified host name. + +.TP +.BR localhost_address " (string, default to localhost or 127.0.0.1)" +Specify the name or IP address for Amd to use when connecting the sockets +for the local NFS server and the RPC server. This defaults to 127.0.0.1 or +whatever the host reports as its local address. This parameter is useful on +hosts with multiple addresses where you want to force Amd to connect to a +specific address. + +.TP +.BR log_file " (string, default=/dev/stderr)" +Same as the +.B \-l +option to Amd. Specify a file name to log Amd events to. +If the string +.B /dev/stderr +is specified, Amd will send its events to the standard error file descriptor. +If the string +.B syslog +is given, Amd will record its events with the system logger +.BR syslogd (8). +The default syslog facility used is LOG_DAEMON. If you +wish to change it, append its name to the log file name, delimited by a +single colon. For example, if +.I logfile +is the string +.B syslog:local7 +then Amd will log messages via +.IR syslog (3) +using the LOG_LOCAL7 facility (if it exists on the system). + +.TP +.BR log_options " (string, default=defaults)" +Same as the +.B \-x +option to Amd. Specify any logging options for Amd. Options are comma +delimited, and can be preceded by the string "no" to negate their meaning. +The "debug" logging option is only available if am-utils was configured with +--enable-debug. You can get the list of supported debugging and logging +options by running +.B amd +.BR \-H . +Possible values are: + +.nf +\fBall\fR all messages +\fBdefaults\fR default messages (fatal,error,user,warning,info) +\fBdebug\fR debug messages +\fBerror\fR non-fatal system errors (cannot be turned off) +\fBfatal\fR fatal errors (cannot be turned off) +\fBinfo\fR information +\fBmap\fR map errors +\fBstats\fR additional statistical information +\fBuser\fR non-fatal user errors +\fBwarn\fR warnings +\fBwarning\fR warnings +.fi + +.TP +.BR map_reload_interval " (numeric, default=3600)" +The number of seconds that Amd will wait before it checks to see if any maps +have changed at their source (NIS servers, LDAP servers, files, etc.). Amd +will reload only those maps that have changed. + +.TP +.BR nfs_allow_any_interface " (string, default=no)" +Normally Amd accepts local NFS packets only from 127.0.0.1. If this +parameter is set to "yes" then Amd will accept local NFS packets from any +local interface; this is useful on hosts that may have multiple interfaces +where the system is forced to send all outgoing packets (even those bound to +the same host) via an address other than 127.0.0.1. + +.TP +.BR nfs_allow_insecure_port " (string, default=no)" +Normally Amd will refuse requests coming from unprivileged ports (i.e. +ports >= 1024 on Unix systems), so that only privileged users and the kernel +can send NFS requests to it. However, some kernels (certain versions of +Darwin, MacOS X, and Linux) have bugs that cause them to use unprivileged +ports in certain situations, which causes Amd to stop dead in its tracks. +This parameter allows Amd to operate normally even on such systems, at the +expense of a slight decrease in the security of its operations. If you see +messages like "ignoring request from foo:1234, port not reserved" in your +Amd log, try enabling this parameter and give it another go. + +.TP +.BR nfs_proto " (string, default to trying version tcp then udp)" +By default, Amd tries TCP and then UDP. This option forces the overall NFS +protocol used to TCP or UDP. It overrides what is in the Amd maps, and is +useful when Amd is compiled with NFSv3 support that may not be stable. With +this option you can turn off the complete usage of NFSv3 dynamically +(without having to recompile Amd) until such time as NFSv3 support is +desired again. + +.TP +.BR nfs_retransmit_counter " (numeric, default=11)" +Same as the +.I retransmit +part of the +.BI \-t " timeout.retransmit" +option to Amd. +Specifies the number of NFS retransmissions that the kernel will use to +communicate with Amd. + +.TP +.BR nfs_retransmit_counter_udp " (numeric, default=11)" +Same as the +.B nfs_retransmit_counter +option, but for all UDP mounts only. + +.TP +.BR nfs_retransmit_counter_tcp " (numeric, default=11)" +Same as the +.B nfs_retransmit_counter +option, but for all TCP mounts only. + +.TP +.BR nfs_retransmit_counter_toplvl " (numeric, default=11)" +Same as the +.B nfs_retransmit_counter +option, but only for Amd's top-level UDP mounts. + +.TP +.BR nfs_retry_interval " (numeric, default=8)" +Same as the +.I timeout +part of the +.BI \-t " timeout.retransmit" +option to Amd. Specifies the NFS timeout interval, in +.I tenths +of seconds, between NFS/RPC retries (for UDP and TCP). +This is the value that the kernel will use to +communicate with Amd. + +Amd relies on the kernel RPC retransmit mechanism to trigger mount retries. +The values of the +.B nfs_retransmit_counter +and the +.B nfs_retry_interval +parameters change the overall retry interval. Too long an interval gives +poor interactive response; too short an interval causes excessive retries. + +.TP +.BR nfs_retry_interval_udp " (numeric, default=8)" +Same as the +.B nfs_retry_interval +option, but for all UDP mounts only. + +.TP +.BR nfs_retry_interval_tcp " (numeric, default=8)" +Same as the +.B nfs_retry_interval +option, but for all TCP mounts only. + +.TP +.BR nfs_retry_interval_toplvl " (numeric, default=8)" +Same as the +.B nfs_retry_interval +option, but only for Amd's top-level UDP mounts. + +.TP +.BR nfs_vers " (numeric, default to trying version 3 then 2)" +By default, Amd tries version 3 and then version 2. This option forces the +overall NFS protocol used to version 3 or 2. It overrides what is in the +Amd maps, and is useful when Amd is compiled with NFSv3 support that may not +be stable. With this option you can turn off the complete usage of NFSv3 +dynamically (without having to recompile Amd) until such time as NFSv3 +support is desired again. + +.TP +.BR nis_domain " (string, default to local NIS domain name)" +Same as the +.B \-y +option to Amd. Specify an alternative NIS domain from which to fetch the +NIS maps. The default is the system domain name. This option is ignored if +NIS support is not available. + +.TP +.BR normalize_hostnames " (boolean, default=no)" +Same as the +.B \-n +option to Amd. If "yes," then the name refereed to by ${rhost} is +normalized relative to the host database before being used. The effect is +to translate aliases into ``official'' names. + +.TP +.BR normalize_slashes " (boolean, default=yes)" + +If "yes," then Amd will condense all multiple ``/'' (slash) characters into +one and remove all trailing slashes. If "no," then Amd will not touch +strings that may contain repeated or trailing slashes. The latter is +sometimes useful with SMB mounts, which often require multiple slash +characters in pathnames. + +.TP +.BR os " (string, default to compiled in value)" +Same as the +.B \-O +option to Amd. Allows you to override the compiled-in name of the operating +system. Useful when the built-in name is not desired for backward +compatibility reasons. For example, if the build in name is ``sunos5'', you +can override it to ``sos5'', and use older maps which were written with the +latter in mind. + +.TP +.BR osver " (string, default to compiled in value)" +Same as the +.B \-o +option to Amd. Overrides the compiled-in version number of the operating +system. Useful when the built in version is not desired for backward +compatibility reasons. For example, if the build in version is ``2.5.1'', +you can override it to ``5.5.1'', and use older maps that were written with +the latter in mind. + +.TP +.BR pid_file " (string, default=/dev/stdout)" +Specify a file to store the process ID of the running daemon into. If not +specified, Amd will print its process id onto the standard output. Useful +for killing Amd after it had run. Note that the PID of a running Amd can +also be retrieved via +.B amq +.BR \-p . +This file is used only if the print_pid option is on. + +.TP +.BR plock " (boolean, default=yes)" +Same as the +.B \-S +option to Amd. +If "yes," lock the running executable pages of Amd into memory. To improve +Amd's performance, systems that support the +.BR plock (3) +or +.BR mlockall (2) +call can lock the Amd process into memory. This way there is less chance it +the operating system will schedule, page out, and swap the Amd process as +needed. This improves Amd's performance, at the cost of reserving the +memory used by the Amd process (making it unavailable for other processes). + +.TP +.BR portmap_program " (numeric, default=300019)" +Specify an alternate Port-mapper RPC program number, other than the official +number. This is useful when running multiple Amd processes. For example, +you can run another Amd in "test" mode, without affecting the primary Amd +process in any way. For safety reasons, the alternate program numbers that +can be specified must be in the range 300019-300029, inclusive. +Amq +has an option +.B -P +which can be used to specify an alternate program number of an Amd to +contact. In this way, amq can fully control any number of Amd processes +running on the same host. + +.TP +.BR preferred_amq_port " (numeric, default=0)" +Specify an alternate Port-mapper RPC port number for Amd's +Amq +service. This is used for both UDP and TCP. Setting this value to 0 (or +not defining it) will cause +Amd +to select an arbitrary port number. Setting the +Amq +RPC service port to a specific number is useful in firewalled or NAT'ed +environments, where you need to know which port +Amd +will listen on. + +.TP +.BR print_pid " (boolean, default=no)" +Same as the +.B \-p +option to Amd. If "yes," Amd will print its process ID upon starting. + +.TP +.BR print_version " (boolean, default=no)" +Same as the +.B \-v +option to Amd, but the version prints and Amd continues to run. If "yes," +Amd will print its version information string, which includes some +configuration and compilation values. + +.TP +.BR restart_mounts " (boolean, default=no)" +Same as the +.B \-r +option to Amd. If "yes" +Amd +will scan the mount table to determine which file systems are currently +mounted. Whenever one of these would have been auto-mounted, +Amd +inherits it. + +.TP +.BR show_statfs_entries " (boolean), default=no)" +If "yes," then all maps which are browsable will also show the number of +entries (keys) they have when "df" runs. (This is accomplished by returning +non-zero values to the statfs(2) system call). + +.TP +.BR truncate_log " (boolean), default=no)" +If "yes," then the log file (if it is a regular file), will be truncated +upon startup. + +.TP +.BR unmount_on_exit " (boolean), default=no)" +If "yes," then Amd will attempt to unmount all file systems which it knows +about. Normally Amd leaves all (esp. NFS) mounted file systems intact. +Note that Amd does not know about file systems mounted before it starts up, +unless the restart_mounts option or +.B \-r +flag are used. + +.TP +.BR use_tcpwrappers " (boolean), default=yes)" +If "yes," then Amd will use the tcpd/librwap tcpwrappers library +(if available) to control +access to Amd via the /etc/hosts.allow and /etc/hosts.deny files. + +.TP +.BR vendor " (string, default to compiled in value)" +The name of the vendor of the operating system. Overrides the compiled-in +vendor name. Useful when the compiled-in name is not desired. For example, +most Intel based systems set the vendor name to ``unknown'', but you can set +it to ``redhat.'' + +.\" ************************************************************************** +.SS Parameters applicable to regular map sections + +.TP +.BR map_name " (string, must be specified)" +Name of the map where the keys are located. + +.TP +.BR tag " (string, default no tag)" +Each map entry in the configuration file can be tagged. If no tag is +specified, that map section will always be processed by Amd. If it is +specified, then Amd will process the map if the +.B -T +option was given to Amd, and the value given to that command-line option +matches that in the map section. + +.\" ************************************************************************** +.SH EXAMPLES +Here is a real Amd configuration file I use daily. +.P +.nf +# GLOBAL OPTIONS SECTION +[ global ] +normalize_hostnames = no +print_pid = no +restart_mounts = yes +auto_dir = /n +log_file = /var/log/amd +log_options = all +#debug_options = all +plock = no +selectors_in_defaults = yes +# config.guess picks up "sunos5" and I don't want to edit my maps yet +os = sos5 +# if you print_version after setting up "os," it will show it. +print_version = no +map_type = file +search_path = /etc/amdmaps:/usr/lib/amd:/usr/local/AMD/lib +browsable_dirs = yes + +# DEFINE AN AMD MOUNT POINT +[ /u ] +map_name = amd.u + +[ /proj ] +map_name = amd.proj + +[ /src ] +map_name = amd.src + +[ /misc ] +map_name = amd.misc + +[ /import ] +map_name = amd.import + +[ /tftpboot/.amd ] +tag = tftpboot +map_name = amd.tftpboot +.fi +.\" ************************************************************************** +.SH "SEE ALSO" +.BR amd (8), +.BR amq (8), +.BR ctl-amd (8), +.BR automount (8), +.BR hosts_access (5). +.LP +``am-utils'' +.BR info (1) +entry. +.LP +.I "Linux NFS and Automounter Administration" +by Erez Zadok, ISBN 0-7821-2739-8, (Sybex, 2001). +.LP +.I http://www.am-utils.org +.LP +.I "Amd \- The 4.4 BSD Automounter" +.SH AUTHORS +Erez Zadok , Computer Science Department, Stony Brook +University, Stony Brook, New York, USA. +.P +Other authors and contributors to am-utils are listed in the +.B AUTHORS +file distributed with am-utils. diff --git a/static/netbsd/man5/atf-formats.5 b/static/netbsd/man5/atf-formats.5 new file mode 100644 index 00000000..bb919f48 --- /dev/null +++ b/static/netbsd/man5/atf-formats.5 @@ -0,0 +1,231 @@ +.\" +.\" Automated Testing Framework (atf) +.\" +.\" Copyright (c) 2007 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND +.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, +.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY +.\" DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE +.\" GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER +.\" IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR +.\" OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN +.\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd December 20, 2011 +.Dt ATF-FORMATS 5 +.Os +.Sh NAME +.Nm atf-formats +.Nd machine-parseable data formats used by ATF +.Sh DESCRIPTION +This manual page describes the multiple data formats used in ATF. +These formats affect configuration files, control files and any data that +is externalized or internalized by the tools. +.Pp +Data files are always organized as follows: +.Bd -literal -offset indent +Header1: Value1 \\ + ... | head +HeaderN: ValueN / + mandatory blank line +Free-form text contents \\ + ... | body + ... / +.Ed +.Pp +A file must always contain a +.Sq Content-Type +header and must always separate that header from the body with a blank +line, even if the body is empty. +.Pp +The +.Sq Content-Type +is always of the form: +.Bd -literal -offset indent +Content-Type: application/X-atf-; version="" +.Ed +.Pp +where +.Sq subtype +indicates the specific file format and +.Sq version +its format version. +This header must be the first one of the file. +.Pp +The main purpose of the +.Sq Content-Type +header, aside from determining the format used in the file, is to allow +future changes to a given format. +Whenever an incompatible change is made, the version is bumped by one. +By keeping the header in the first line, future versions may even remove +the need for such a header -- e.g. if some format was replaced by XML +files, which have their own mandatory header. +.Pp +The rest of this document details the different format types. +.Ss Format: application/X-atf-atffile, version: 1 +Atffiles are logically divided into three sections: +.Bl -bullet +.It +Test programs: the list of test programs that define the test suite +described by the Atffile. +.It +Meta-data properties: these define some constant values applicable to +all the test programs defined in the file. +In some sense they define the properties that describe the test suite. +.It +Configuration variables: defaults for configuration variables that +can be overridden through configuration files or the command line. +.El +.Pp +The grammar for Atffiles is the following: +.Bd -literal -offset indent +DATA ::= ( ( CONF | PROP | TP )? COMMENT? NEWLINE )* EOF +CONF ::= 'conf:' WORD EQUAL STRING +PROP ::= 'prop:' WORD EQUAL STRING +TP ::= TPFILE | TPGLOB +TPFILE ::= 'tp: ' STRING +TPGLOB ::= 'tp-glob: ' STRING +STRING ::= WORD | '"' WORD* '"' +.Ed +.Pp +The meaning of the constructions above is: +.Bl -tag -width TPGLOBXX +.It CONF +Definition of a configuration variable. +.It PROP +Definition of a meta-data property. +.It TPFILE +Addition of a test program into the test suite. +The string is taken literally as the program's name, and this program +must exist. +.It TPGLOB +Addition of multiple test programs into the test suite. +The string is taken as a glob pattern, which may have or not have any +matches in the current directory. +.El +.Pp +An example: +.Bd -literal -offset indent +prop: test-suite = utilities + +conf: unprivileged-user = nobody + +tp: t_cp +tp: t_mv +tp: t_df +tp-glob: t_dir_* +.Ed +.Ss Format: application/X-atf-config, version: 1 +Configuration files are very simple: they only contain a list of variable +name/variable value pairs. +Their grammar is: +.Bd -literal -offset indent +DATA ::= ( VAR? COMMENT? NEWLINE )* EOF +VAR ::= WORD EQUAL STRING +COMMENT ::= HASH WORD* +STRING ::= WORD | '"' WORD* '"' +.Ed +.Pp +An example: +.Bd -literal -offset indent +# This is the system-wide configuration file for ATF. +# The above and this line are comments placed on their own line. + +var1 = this is a variable value +var2 = this is another one # Optional comment at the end. +.Ed +.Ss Format: application/X-atf-tps, version: 3 +The +.Sq application/X-atf-tps +format multiplexes the standard output, standard error and results output +streams from multiple test programs into a single data file. +This format is used by +.Xr atf-run 1 +to report the execution of several test programs and is later parsed by +.Xr atf-report 1 +to inform the user of this process. +It has the following grammar: +.Bd -literal -offset indent +DATA ::= INFO* TPS-COUNT TP-STANZA* INFO* EOF +INFO ::= 'info' COLON STRING COMMA STRING NEWLINE +TPS-COUNT ::= 'tps-count' COLON POSITIVE-NUMBER NEWLINE +TP-STANZA ::= TP-START TC-STANZA* TC-END +TP-START ::= 'tp-start' COLON TIMESTAMP COMMA STRING COMMA + POSITIVE-NUMBER NEWLINE +TP-END ::= 'tc-end' COLON TIMESTAMP COMMA STRING (COMMA STRING)? +TC-STANZA ::= TC-START (TC-SO | TC-SE)* TC-END +TC-START ::= 'tc-start' COLON TIMESTAMP COMMA STRING NEWLINE +TC-SO ::= 'tc-so' COLON STRING NEWLINE +TC-SE ::= 'tc-se' COLON STRING NEWLINE +TC-END ::= 'tc-end' COLON TIMESTAMP COMMA STRING COMMA TCR NEWLINE +TCR ::= 'passed' | ('failed' | 'skipped') COMMA STRING +TIMESTAMP ::= [0-9]+.[0-9]+ +.Ed +.Pp +The meaning of the constructions above is: +.Bl -tag -width TPSXCOUNTXX +.It TPS-COUNT +Indicates the number of test programs that will be executed. +There will be this exact amount of +.Sq TP-STANZA +constructions following it. +.It TP-START +Indicates the beginning of a test program. +This includes the program's name and the amount of test cases that +will follow. +.It TP-END +Indicates the completion of a test program. +This is followed by the program's name and, if the program ended +prematurely, an error message indicating the reason of its failure. +A successful execution of a test program (regardless of the status of its +test cases) must not be accompanied by any reason. +.It TC-START +Indicates the beginning of a test case. +This is accompanied by the test case's name. +.It TC-SO +Contains a text line sent to the standard output stream during the +execution of the test case. +Leading and trailing space is preserved. +.It TC-SE +Contains a text line sent to the standard error stream during the +execution of the test case. +Leading and trailing space is preserved. +.It TC-END +Indicates the completion of a test case. +This is accompanied by the test case's name, its result and the reason +associated with this result (if applicable). +.El +.Pp +An example: +.Bd -literal -offset indent +tps-count: 2 +tp-start: calculator, 1324318951.838923, 2 +tc-start: add, 1324318951.839101 +tc-end: add, 1324318951.839500, passed +tc-start: subtract, 1324318951.840001 +tc-so: 3-2 expected to return 1 but got 0 +tc-end: subtract, 1324318952.000123, failed, Calculated an unexpected value +tp-end: calculator, 1324318952.002301 +tp-start: files, 1, 1324318952.502348 +tc-start: copy, 1324318952.508291 +tc-se: could not find the cp(1) utility +tc-end: copy, 1324318953.203145, skipped +tp-end: files, 1324318953.203800 +.Ed +.Sh SEE ALSO +.Xr atf 7 diff --git a/static/netbsd/man5/auto_master.5 b/static/netbsd/man5/auto_master.5 new file mode 100644 index 00000000..bdcf6d10 --- /dev/null +++ b/static/netbsd/man5/auto_master.5 @@ -0,0 +1,401 @@ +.\" $NetBSD: auto_master.5,v 1.8 2019/11/21 15:24:17 tkusumi Exp $ +.\" Copyright (c) 2017 The NetBSD Foundation, Inc. +.\" Copyright (c) 2016 The DragonFly Project +.\" Copyright (c) 2014 The FreeBSD Foundation +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to The NetBSD Foundation +.\" by Tomohiro Kusumi. +.\" +.\" This software was developed by Edward Tomasz Napierala under sponsorship +.\" from the FreeBSD Foundation. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" $FreeBSD$ +.\" +.Dd November 16, 2019 +.Dt AUTO_MASTER 5 +.Os +.Sh NAME +.Nm auto_master +.Nd auto_master and map file format +.Sh DESCRIPTION +The automounter configuration consists of the +.Nm +configuration file, which assigns file system paths to map names, +and maps, which contain actual mount information. +The +.Nm +configuration file is used by the +.Xr automount 8 +command. +Map files are read by the +.Xr automountd 8 +daemon. +.Sh AUTO_MASTER SYNTAX +The +.Nm +file consists of lines with two or three entries separated by whitespace +and terminated by a newline character: +.Bd -literal -offset indent +.Ar mountpoint Ar map_name Op Fl Ar options +.Ed +.Pp +.Ar mountpoint +is either a fully specified path, or +.Pa /- . +When +.Ar mountpoint +is a full path, +.Ar map_name +must reference an indirect map. +Otherwise, +.Ar map_name +must reference a direct map. +See +.Sx "MAP SYNTAX" +below. +.Pp +.Ar map_name +specifies map to use. +If +.Ar map_name +begins with +.Li - , +it specifies a special map. +See +.Sx "MAP SYNTAX" +below. +If +.Ar map_name +is not a fully specified path +.Pq it does not start with Li / , +.Xr automountd 8 +will search for that name in +.Pa /etc . +Otherwise it will use the path as given. +If the file indicated by +.Ar map_name +is executable, +.Xr automountd 8 +will assume it is an executable map. +See +.Sx "MAP SYNTAX" +below. +Otherwise, the file is opened and the contents parsed. +.Pp +.Op Fl Ar options +is an optional field that starts with +.Fl +and can contain generic file system mount options. +.Pp +The following example specifies that the +.Pa /etc/auto_example +indirect map will be mounted on +.Pa /example . +.Bd -literal -offset indent +/example auto_example +.Ed +.Sh MAP SYNTAX +Map files consist of lines with a number of entries separated by whitespace +and terminated by newline character: +.Bd -literal -offset indent +.Ar key Oo Fl Ar options Oc Oo Ar mountpoint Oo Fl Ar options Oc Oc Ar location Op ... +.Ed +.Pp +In most cases, it can be simplified to: +.Bd -literal -offset indent +.Ar key Oo Fl Ar options Oc Ar location +.Ed +.Pp +.Ar key +is the path component used by +.Xr automountd 8 +to find the right map entry to use. +It is also used to form the final mountpoint. +A wildcard +.Pq Ql * +can be used for the key. +It matches every directory that does not match other keys. +Those directories will not be visible to the user until accessed. +.Pp +The +.Ar options +field, if present, must begin with +.Fl . +When mounting the file system, options supplied to +.Nm +and options specified in the map entry are concatenated together. +The special option +.Ic fstype +is used to specify file system type. +It is not passed to the mount program as an option. +Instead, it is passed as an argument to +.Cm "mount -t". +The default +.Ic fstype +is +.Ql nfs . +The special option +.Ic nobrowse +is used to disable creation of top-level directories for special +and executable maps. +.Pp +The optional +.Ar mountpoint +field is used to specify multiple mount points for a single key. +.Pp +The +.Ar location +field specifies the file system to be mounted. +Ampersands +.Pq Ql & +in the +.Ar location +field are replaced with the value of +.Ar key . +This is typically used with wildcards, like: +.Bd -literal -offset indent +* 192.168.1.1:/share/& +.Ed +.Pp +The +.Ar location +field may contain references to variables, like: +.Bd -literal -offset indent +sys 192.168.1.1:/sys/${OSNAME} +.Ed +.Pp +Defined variables are: +.Pp +.Bl -tag -width "Dv OSNAME" -compact +.It Dv ARCH +Expands to the output of +.Li "uname -p" . +.It Dv CPU +Same as +.Dv ARCH . +.It Dv DOLLAR +A literal $ sign. +.It Dv HOST +Expands to the output of +.Li "uname -n" . +.It Dv OSNAME +Expands to the output of +.Li "uname -s" . +.It Dv OSREL +Expands to the output of +.Li "uname -r" . +.It Dv OSVERS +Expands to the output of +.Li "uname -v" . +.El +.Pp +Additional variables can be defined with the +.Fl D +option of +.Xr automount 8 +and +.Xr automountd 8 . +.Pp +To pass a location that begins with +.Pa / , +prefix it with a colon. +For example, +.Li :/dev/cd0 . +.Pp +This example, when put into +.Pa /etc/auto_example , +and with +.Nm +referring to the map as described above, specifies that the NFS share +.Li 192.168.1.1:/share/example/x +will be mounted on +.Pa /example/x/ +when any process attempts to access that mountpoint, with +.Ic intr +and +.Ic nfsv4 +mount options, described in +.Xr mount_nfs 8 : +.Bd -literal -offset indent +x -intr,nfsv4 192.168.1.1:/share/example/x +.Ed +.Pp +Automatically mount an SMB share on access, as a guest user, +without prompting for a password: +.Bd -literal -offset indent +share -fstype=smbfs,-N ://@server/share +.Ed +.Pp +Automatically mount the CD drive on access: +.Bd -literal -offset indent +cd -fstype=cd9660 :/dev/cd0 +.Ed +.Sh SPECIAL MAPS +Special maps have names beginning with +.Li - . +Supported special maps are: +.Pp +.Bl -tag -width ".Ic -noauto" -compact +.It Ic -hosts +Query the remote NFS server and map exported shares. +This map is traditionally mounted on +.Pa /net . +Access to files on a remote NFS server is provided through the +.Pa /net/ Ns Ar nfs-server-ip Ns / Ns Ar share-name Ns / +directory without any additional configuration. +Directories for individual NFS servers are not present until the first access, +when they are automatically created. +.It Ic -media +Query devices that are not yet mounted, but contain valid file systems. +Generally used to access files on removable media. +.It Ic -noauto +Mount file systems configured in +.Xr fstab 5 +as "noauto". +This needs to be set up as a direct map. +.It Ic -null +Prevent +.Xr automountd 8 +from mounting anything on the mountpoint. +.El +.Pp +It is possible to add custom special maps by adding them, as executable +maps named +.Pa special_foo , +to the +.Pa /etc/autofs/ +directory. +.Sh EXECUTABLE MAPS +If the map file specified in +.Nm +has the execute bit set, +.Xr automountd 8 +will execute it and parse the standard output instead of parsing +the file contents. +When called without command line arguments, the executable is +expected to output a list of available map keys separated by +newline characters. +Otherwise, the executable will be called with a key name as +a command line argument. +Output from the executable is expected to be the entry for that key, +not including the key itself. +.Sh INDIRECT VERSUS DIRECT MAPS +Indirect maps are referred to in +.Nm +by entries with a fully qualified path as a mount point, and must contain only +relative paths as keys. +Direct maps are referred to in +.Nm +by entries with +.Li /- +as the mountpoint, and must contain only fully qualified paths as keys. +For indirect maps, the final mount point is determined by concatenating the +.Nm +mountpoint with the map entry key and optional map entry mountpoint. +For direct maps, the final mount point is determined by concatenating +the map entry key with the optional map entry mountpoint. +.Pp +The example above could be rewritten using direct map, by placing this in +.Nm : +.Bd -literal -offset indent +/- auto_example +.Ed +.Pp +and this in the +.Pa /etc/auto_example +map file: +.Bd -literal -offset indent +/example/x -intr,nfsv4 192.168.1.1:/share/example/x +/example/share -fstype=smbfs,-N ://@server/share +/example/cd -fstype=cd9660 :/dev/cd0 +.Ed +.Sh DIRECTORY SERVICES +Both +.Nm +and maps may contain entries consisting of a plus sign and map name: +.Bd -literal -offset indent ++auto_master +.Ed +.Pp +Those entries cause +.Xr automountd 8 +daemon to retrieve the named map from directory services (like LDAP) +and include it where the entry was. +.Pp +If the file containing the map referenced in +.Nm +is not found, the map will be retrieved from directory services instead. +.Pp +To retrieve entries from directory services, +.Xr automountd 8 +daemon runs +.Pa /etc/autofs/include , +which is usually a shell script, with map name as the only command line +parameter. +The script should output entries formatted according to +.Nm +or automounter map syntax to standard output. +An example script to use LDAP is included in +.Pa /etc/autofs/include_ldap . +It can be symlinked to +.Pa /etc/autofs/include . +.Sh FILES +.Bl -tag -width ".Pa /etc/auto_master" -compact +.It Pa /etc/auto_master +The default location of the +.Nm +file. +.It Pa /etc/autofs/ +Directory containing shell scripts to implement special maps and directory +services. +.El +.Sh SEE ALSO +.Xr autofs 5 , +.Xr automount 8 , +.Xr automountd 8 , +.Xr autounmountd 8 +.Sh AUTHORS +.An -nosplit +The +.Nm +configuration file functionality was developed by +.An Edward Tomasz Napierala Aq Mt trasz@FreeBSD.org +under sponsorship from the +.Fx +Foundation. +.Pp +The +.Nm +configuration file functionality was ported to +.Dx +and +.Nx +by +.An Tomohiro Kusumi Aq Mt tkusumi@netbsd.org . +.Sh BUGS +The +.Li -media +special map is currently unsupported on +.Nx . diff --git a/static/netbsd/man5/bad.include-toplevel.5 b/static/netbsd/man5/bad.include-toplevel.5 new file mode 100644 index 00000000..b2c0eae8 --- /dev/null +++ b/static/netbsd/man5/bad.include-toplevel.5 @@ -0,0 +1,8 @@ +include-toplevel: include.withclauses.* +server: + identity: "top 1" + include: include.withoutclauses.* + include-toplevel: include.withsomeclauses.* +include: include.withclauses.* +include-toplevel: include.withclauses.* +server: identity: "top 2" diff --git a/static/netbsd/man5/blocklistd.conf.5 b/static/netbsd/man5/blocklistd.conf.5 new file mode 100644 index 00000000..cff8b333 --- /dev/null +++ b/static/netbsd/man5/blocklistd.conf.5 @@ -0,0 +1,237 @@ +.\" $NetBSD: blocklistd.conf.5,v 1.9 2026/01/13 21:38:18 christos Exp $ +.\" +.\" Copyright (c) 2015, 2025 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to The NetBSD Foundation +.\" by Christos Zoulas. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd January 13, 2026 +.Dt BLOCKLISTD.CONF 5 +.Os +.Sh NAME +.Nm blocklistd.conf +.Nd configuration file format for blocklistd +.Sh DESCRIPTION +The +.Nm +file contains configuration entries for +.Xr blocklistd 8 +in a fashion similar to +.Xr inetd.conf 5 . +Only one entry per line is permitted. +Every entry must have all fields populated. +Each field can be separated by a tab or a space. +Comments are denoted by a +.Dq # +at the beginning of a line. +.Pp +There are two kinds of configuration lines, +.Va [local] +and +.Va [remote] . +By default, configuration lines are +.Va [local] , +i.e. the address specified refers to the addresses on the local machine. +To switch to between +.Va [local] +and +.Va [remote] +configuration lines you can specify the stanzas: +.Dq [local] +and +.Dq [remote] . +.Pp +On +.Va [local] +and +.Va [remote] +lines +.Dq * +means use the default, or wildcard match. +In addition, for +.Va [remote] +lines +.Dq = +means use the values from the matched +.Va [local] +configuration line. +.Pp +The first four fields, +.Va location , +.Va type , +.Va proto , +and +.Va owner +are used to match the +.Va [local] +or +.Va [remote] +addresses, whereas the last 3 fields +.Va name , +.Va nfail , +and +.Va disable +are used to modify the filtering action. +.Pp +The first field denotes the +.Va location +as an address, mask, and port. +The syntax for the +.Va location +is: +.Bd -literal -offset indent + [
|[/]:] +.Ed +.Pp +The +.Dv address +can be an IPv4 address in numeric format, an IPv6 address +in numeric format and enclosed by square brackets, or an interface name. +Mask modifiers are not allowed on interfaces because interfaces +can have multiple addresses in different protocols where the mask has a +different size. +.Pp +The +.Dv mask +is always numeric, but the +.Dv port +can be either numeric or symbolic. +.Pp +The second field is the socket +.Va type : +.Dv stream , +.Dv dgram , +or numeric. +The third field is the +.Va protocol : +.Dv tcp , +.Dv udp , +.Dv tcp6 , +.Dv udp6 , +or numeric. +The fourth field is the effective user +.Va ( owner ) +of the daemon process reporting the event, +either as a username or a userid. +.Pp +The rest of the fields control the behavior of the filter. +.Pp +The +.Va name +field, is the name of the packet filter rule to be used. +If the +.Va name +starts with a hyphen +.Pq Dq - , +then the default rulename is prepended to the given name. +If the +.Dv name +contains a +.Dq / , +the remaining portion of the name is interpreted as the mask to be +applied to the address specified in the rule, causing a single rule violation to +block the entire subnet for the configured prefix. +.Pp +The +.Va nfail +field contains the number of failed attempts before access is blocked, +defaulting to +.Dq * +meaning never, and the last field +.Va duration +specifies the amount of time since the last access that the blocking +rule should be active, defaulting to +.Dq * +meaning forever. +The default unit for +.Va duration +is seconds, but one can specify suffixes for different units, such as +.Dq m +for minutes +.Dq h +for hours and +.Dq d +for days. +.Pp +Matching is done first by checking the +.Va [local] +rules individually, in the order of the most specific to the least specific. +If a match is found, then the matching +.Va [remote] +rules are applied. +The +.Va name , +.Va nfail , +and +.Va duration +fields can be altered by the +.Va [remote] +rule that matched. +.Pp +The +.Va [remote] +rules can be used for allowing specific addresses, changing the mask +size (via +.Va name ) , +the rule that the packet filter uses (also via +.Va name ) , +the number of failed attempts (via +.Va nfail ) , +or the duration to block (via +.Va duration ) . +.Sh FILES +.Bl -tag -width /etc/blocklistd.conf -compact +.It Pa /etc/blocklistd.conf +Configuration file. +.El +.Sh EXAMPLES +.Bd -literal -offset 8n +# Block ssh, after 3 attempts for 6 hours on the bnx0 interface +[local] +# location type proto owner name nfail duration +bnx0:ssh * * * * 3 6h +[remote] +# Never block 1.2.3.4 +1.2.3.4:ssh * * * * * * +# Never block the example IPv6 subnet either +[2001:db8::]/32:ssh * * * * * * +# For addresses coming from 8.8.0.0/16 block whole /24 networks instead +# individual hosts, but keep the rest of the blocking parameters the same. +8.8.0.0/16:ssh * * * /24 = = +.Ed +.Sh SEE ALSO +.Xr blocklistctl 8 , +.Xr blocklistd 8 +.Sh HISTORY +.Nm +first appeared in +.Nx 7 . +.Fx +support for +.Nm +was implemented in +.Fx 11 . +.Sh AUTHORS +.An Christos Zoulas diff --git a/static/netbsd/man5/body_checks.5 b/static/netbsd/man5/body_checks.5 new file mode 100644 index 00000000..39b1179f --- /dev/null +++ b/static/netbsd/man5/body_checks.5 @@ -0,0 +1,3 @@ +.\" $NetBSD: body_checks.5,v 1.1.1.1 2009/06/23 10:08:33 tron Exp $ +.\" +.so man5/header_checks.5 diff --git a/static/netbsd/man5/bootparams.5 b/static/netbsd/man5/bootparams.5 new file mode 100644 index 00000000..02aca27c --- /dev/null +++ b/static/netbsd/man5/bootparams.5 @@ -0,0 +1,100 @@ +.\" $NetBSD: bootparams.5,v 1.11 2002/02/28 01:19:48 lukem Exp $ +.\" +.\" Copyright (c) 1994 Gordon W. Ross +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. The name of the author may not be used to endorse or promote products +.\" derived from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd February 28, 2002 +.Dt BOOTPARAMS 5 +.Os +.Sh NAME +.Nm bootparams +.Nd boot parameter database +.Sh SYNOPSIS +.Nm /etc/bootparams +.Sh DESCRIPTION +The +.Nm +file specifies the boot parameters that +.Xr diskless 8 +clients may request when booting over the network. +Each client supported by this server must have an entry in the +.Nm +file containing the servers and pathnames for its +.Pa root , +area. It may optionally contain +.Pa swap , +.Pa dump , +and other entry types. +.Pp +Each line in the file +(other than comment lines that begin with a #) +specifies the client name followed by the pathnames that +the client may request by their logical names. Names +are matched in a case-insensitive fashion, and may also +be wildcarded using shell-style globbing characters. +.Pp +The components of the line are delimited with blank or tab, +and may be continued onto multiple lines with a backslash. +.Pp +For example: +.Bd -literal -offset indent +dummy root=server:/export/dummy/root \\ + swap=server:/export/dummy/swap \\ + dump=server:/export/dummy/swap \\ + gateway=router:255.255.255.0 +.Ed +.Pp +When the client named "dummy" requests the pathname for +its logical "root" it will be given server +.Dq Pa "server" +and pathname +.Dq Pa "/export/dummy/root" +as the response to its +.Tn RPC +request. +.Pp +.Bd -literal -offset indent +netra[1-5]www* root=server:/export/jumpstart/netra_www +.Ed +.Pp +When any client with a name matching the pattern "netra[1-5]www*" +requests the pathname for its logical "root" it will be given server +.Dq Pa "server" +and pathname +.Dq Pa "/export/jumpstart/netra_www" +as the response to its +.Tn RPC +request. As this example implies, this is useful for setting up +Jumpstart servers for Sun clients. +.Sh NOTES +The server does not default to the localhost, and must be filled in. +.Sh FILES +.Bl -tag -width /etc/bootparams -compact +.It Pa /etc/bootparams +default configuration file +.El +.Sh SEE ALSO +.Xr diskless 8 , +.Xr rpc.bootparamd 8 diff --git a/static/netbsd/man5/bootptab.5 b/static/netbsd/man5/bootptab.5 new file mode 100644 index 00000000..a1f99caa --- /dev/null +++ b/static/netbsd/man5/bootptab.5 @@ -0,0 +1,408 @@ +.\" Copyright (c) 1988, 1989, 1991 Carnegie Mellon University +.\" +.\" $NetBSD: bootptab.5,v 1.7 2012/04/21 12:27:30 roy Exp $ +.\" +.TH BOOTPTAB 5 "October 31, 1991" "Carnegie Mellon University" +.UC 6 + +.SH NAME +bootptab \- Internet Bootstrap Protocol server database +.SH DESCRIPTION +The +.I bootptab +file is the configuration database file for +.IR bootpd , +the Internet Bootstrap Protocol server. +Its format is similar to that of +.IR capfile (5) +in which two-character case-sensitive tag symbols are used to +represent host parameters. These parameter declarations are separated by +colons (:), with a general format of: +.PP +.I " hostname:tg=value:tg=value:tg=value:" +.PP +where +.I hostname +is the actual name of a bootp client (or a "dummy entry"), and +.I tg +is a two-character tag symbol. Replies are returned to clients +only if an entry with the client's Ethernet or IP address exists +in the +.I booptab +file. Dummy entries have an invalid hostname +(one with a "." as the first character) and are used to provide +default values used by other entries via the +.B tc=.dummy-entry +mechanism. Most tags must be followed by an equal sign +and a value as above. Some may also appear in a boolean form with no +value (i.e. +.RI : tg :). +The currently recognized tags are: +.PP +.br + bf Bootfile +.br + bs Bootfile size in 512-octet blocks +.br + cs Cookie server address list +.br + df Merit dump file +.br + dn Domain name +.br + ds Domain name server address list +.br + ef Extension file +.br + gw Gateway address list +.br + ha Host hardware address +.br + hd Bootfile home directory +.br + hn Send client's hostname to client +.br + ht Host hardware type (see Assigned Numbers RFC) +.br + im Impress server address list +.br + ip Host IP address +.br + lg Log server address list +.br + lp LPR server address list +.br + ns IEN-116 name server address list +.br + nt NTP (time) Server (RFC 1129) +.br + ra Reply address override +.br + rl Resource location protocol server address list +.br + rp Root path to mount as root +.br + sa TFTP server address client should use +.br + sm Host subnet mask +.br + sw Swap server address +.br + tc Table continuation (points to similar "template" host entry) +.br + td TFTP root directory used by "secure" TFTP servers +.br + to Time offset in seconds from UTC +.br + ts Time server address list +.br + vm Vendor magic cookie selector +.br + yd YP (NIS) domain name +.br + ys YP (NIS) server address + +.PP +There is also a generic tag, +.RI T n , +where +.I n +is an RFC1084 vendor field tag number. Thus it is possible to immediately +take advantage of future extensions to RFC1084 without being forced to modify +.I bootpd +first. Generic data may be represented as either a stream of hexadecimal +numbers or as a quoted string of ASCII characters. The length of the generic +data is automatically determined and inserted into the proper field(s) of the +RFC1084-style bootp reply. +.PP +The following tags take a whitespace-separated list of IP addresses: +.BR cs , +.BR ds , +.BR gw , +.BR im , +.BR lg , +.BR lp , +.BR ns , +.BR nt , +.BR ra , +.BR rl , +and +.BR ts . +The +.BR ip , +.BR sa , +.BR sw , +.BR sm , +and +.B ys +tags each take a single IP address. +All IP addresses are specified in standard Internet "dot" notation +and may use decimal, octal, or hexadecimal numbers +(octal numbers begin with 0, hexadecimal numbers begin with '0x' or '0X'). +Any IP addresses may alternatively be specified as a hostname, causing +.I bootpd +to lookup the IP address for that host name using gethostbyname(3). +If the +.B ip +tag is not specified, +.I bootpd +will determine the IP address using the entry name as the host name. +(Dummy entries use an invalid host name to avoid automatic IP lookup.) +.PP +The +.B ht +tag specifies the hardware type code as either an unsigned decimal, octal, or +hexadecimal integer or one of the following symbolic names: +.B ethernet +or +.B ether +for 10Mb Ethernet, +.B ethernet3 +or +.B ether3 +for 3Mb experimental Ethernet, +.BR ieee802 , +.BR tr , +or +.B token-ring +for IEEE 802 networks, +.B pronet +for Proteon ProNET Token Ring, or +.BR chaos , +.BR arcnet , +or +.B ax.25 +for Chaos, ARCNET, and AX.25 Amateur Radio networks, respectively. +The +.B ha +tag takes a hardware address which may be specified as a host name +or in numeric form. Note that the numeric form +.I must +be specified in hexadecimal; optional periods and/or a leading '0x' may be +included for readability. The +.B ha +tag must be preceded by the +.B ht +tag (either explicitly or implicitly; see +.B tc +below). +If the hardware address is not specified and the type is specified +as either "ethernet" or "ieee802", then +.I bootpd +will try to determine the hardware address using ether_hostton(3). +.PP +The hostname, home directory, and bootfile are ASCII strings which may be +optionally surrounded by double quotes ("). The client's request and the +values of the +.B hd +and +.B bf +symbols determine how the server fills in the bootfile field of the bootp +reply packet. +.PP +If the +.B bf +option is specified, its value is copied into the reply packet. +Otherwise, the name supplied in the client request is used. +If the +.B hd +option is specified, its value is prepended to the +boot file in the reply packet, otherwise the path +supplied in the client request is used. +The existence of the boot file is NOT verified by +.I bootpd +because the boot file may be on some other machine. +.PP +The +.B bs +option specified the size of the boot file. +It can be written as +.BR bs =auto +which causes +.I bootpd +to determine the boot file size automatically. +.PP +Some newer versions of +.I tftpd +provide a security feature to change their root directory using +the +.IR chroot (2) +system call. +The +.B td +tag may be used to inform +.I bootpd +of this special root directory used by +.IR tftpd . +(One may alternatively use the +.I bootpd +"-c chdir" option.) +The +.B hd +tag is actually relative to the root directory specified by the +.B td +tag. +For example, if the real absolute path to your BOOTP client bootfile is +/tftpboot/bootfiles/bootimage, and +.IR tftpd +uses /tftpboot as its "secure" directory, then specify the following in +.IR bootptab : +.PP +.br + :td=/tftpboot:hd=/bootfiles:bf=bootimage: +.PP +If your bootfiles are located directly in /tftpboot, use: +.PP +.br + :td=/tftpboot:hd=/:bf=bootimage: +.PP +The +.B sa +tag may be used to specify the IP address of the particular TFTP server +you wish the client to use. In the absence of this tag, +.I bootpd +will tell the client to perform TFTP to the same machine +.I bootpd +is running on. +.PP +The time offset +.B to +may be either a signed decimal integer specifying the client's +time zone offset in seconds from UTC, or the keyword +.B auto +which uses the server's time zone offset. Specifying the +.B to +symbol as a boolean has the same effect as specifying +.B auto +as its value. +.PP +The bootfile size +.B bs +may be either a decimal, octal, or hexadecimal integer specifying the size of +the bootfile in 512-octet blocks, or the keyword +.B auto +which causes the server to automatically calculate the bootfile size at each +request. As with the time offset, specifying the +.B bs +symbol as a boolean has the same effect as specifying +.B auto +as its value. +.PP +The vendor magic cookie selector (the +.B vm +tag) may take one of the following keywords: +.B auto +(indicating that vendor information is determined by the client's request), +.B rfc1048 +or +.B rfc1084 +(which always forces an RFC1084-style reply), or +.B cmu +(which always forces a CMU-style reply). +.PP +The +.B hn +tag is strictly a boolean tag; it does not take the usual equals-sign and +value. It's presence indicates that the hostname should be sent to RFC1084 +clients. +.I Bootpd +attempts to send the entire hostname as it is specified in the configuration +file; if this will not fit into the reply packet, the name is shortened to +just the host field (up to the first period, if present) and then tried. +In no case is an arbitrarily-truncated hostname sent (if nothing reasonable +will fit, nothing is sent). +.PP +Often, many host entries share common values for certain tags (such as name +servers, etc.). Rather than repeatedly specifying these tags, a full +specification can be listed for one host entry and shared by others via the +.B tc +(table continuation) mechanism. +Often, the template entry is a dummy host which doesn't actually exist and +never sends bootp requests. This feature is similar to the +.B tc +feature of +.IR capfile (5) . +Note that +.I bootpd +allows the +.B tc +tag symbol to appear anywhere in the host entry, unlike +.I capfile +which requires it to be the last tag. Information explicitly specified for a +host always overrides information implied by a +.B tc +tag symbol, regardless of its location within the entry. The +value of the +.B tc +tag may be the hostname or IP address of any host entry +previously listed in the configuration file. +.PP +Sometimes it is necessary to delete a specific tag after it has been inferred +via +.BR tc . +This can be done using the construction +.IB tag @ +which removes the effect of +.I tag +as in +.IR capfile (5). +For example, to completely undo an IEN-116 name server specification, use +":ns@:" at an appropriate place in the configuration entry. After removal +with +.BR @ , +a tag is eligible to be set again through the +.B tc +mechanism. +.PP +Blank lines and lines beginning with "#" are ignored in the configuration +file. Host entries are separated from one another by newlines; a single host +entry may be extended over multiple lines if the lines end with a backslash +(\\). It is also acceptable for lines to be longer than 80 characters. Tags +may appear in any order, with the following exceptions: the hostname must be +the very first field in an entry, and the hardware type must precede the +hardware address. +.PP +An example +.I /etc/bootptab +file follows: +.PP +.nf + # Sample bootptab file (domain=andrew.cmu.edu) + + .default:\\ + :hd=/usr/boot:bf=null:\\ + :ds=netserver, lancaster:\\ + :ns=pcs2, pcs1:\\ + :ts=pcs2, pcs1:\\ + :sm=255.255.255.0:\\ + :gw=gw.cs.cmu.edu:\\ + :hn:to=-18000: + + carnegie:ht=6:ha=7FF8100000AF:tc=.default: + baldwin:ht=1:ha=0800200159C3:tc=.default: + wylie:ht=1:ha=00DD00CADF00:tc=.default: + arnold:ht=1:ha=0800200102AD:tc=.default: + bairdford:ht=1:ha=08002B02A2F9:tc=.default: + bakerstown:ht=1:ha=08002B0287C8:tc=.default: + + # Special domain name server and option tags for next host + butlerjct:ha=08002001560D:ds=128.2.13.42:\\ + :T37=0x12345927AD3BCF:\\ + :T99="Special ASCII string":\\ + :tc=.default: + + gastonville:ht=6:ha=7FFF81000A47:tc=.default: + hahntown:ht=6:ha=7FFF81000434:tc=.default: + hickman:ht=6:ha=7FFF810001BA:tc=.default: + lowber:ht=1:ha=00DD00CAF000:tc=.default: + mtoliver:ht=1:ha=00DD00FE1600:tc=.default: + +.fi +.SH FILES +/etc/bootptab + +.SH "SEE ALSO" +.br +bootpd(8), tftpd(8), +.br +DARPA Internet Request For Comments RFC951, RFC1048, RFC1084, Assigned Numbers diff --git a/static/netbsd/man5/bounce.5 b/static/netbsd/man5/bounce.5 new file mode 100644 index 00000000..64fd5153 --- /dev/null +++ b/static/netbsd/man5/bounce.5 @@ -0,0 +1,237 @@ +.\" $NetBSD: bounce.5,v 1.2 2017/02/14 01:16:44 christos Exp $ +.\" +.TH BOUNCE 5 +.ad +.fi +.SH NAME +bounce +\- +Postfix bounce message template format +.SH "SYNOPSIS" +.na +.nf +\fBbounce_template_file = /etc/postfix/bounce.cf\fR + +\fBpostconf \-b\fR [\fItemplate_file\fR] +.SH DESCRIPTION +.ad +.fi +The Postfix \fBbounce\fR(8) server produces delivery status +notification (DSN) messages for undeliverable mail, delayed +mail, successful delivery or address verification requests. + +By default, these notifications are generated from built\-in +templates with message headers and message text. Sites can +override the built\-in information by specifying a bounce +template file with the \fBbounce_template_file\fR configuration +parameter. + +This document describes the general procedure to create a +bounce template file, followed by the specific details of +bounce template formats. +.SH "GENERAL PROCEDURE" +.na +.nf +.ad +.fi +To create a customized bounce template file, create a +temporary +copy of the file \fB/etc/postfix/bounce.cf.default\fR and +edit the temporary file. + +To preview the results of $\fIname\fR expansions in the +template text, use the command + +.nf + \fBpostconf \-b\fR \fItemporary_file\fR +.fi + +Errors in the template will be reported to the standard +error stream and to the syslog daemon. + +While previewing the text, be sure to pay particular attention +to the expansion of time value parameters that appear in +the delayed mail notification text. + +Once the result is satisfactory, copy the template to the +Postfix configuration directory and specify in main.cf +something like: + +.nf +/etc/postfix/main.cf: + bounce_template_file = /etc/postfix/bounce.cf +.fi +.SH "TEMPLATE FILE FORMAT" +.na +.nf +.ad +.fi +The template file can specify templates for failed mail, +delayed mail, successful delivery or for address verification. +These templates are named \fBfailure_template\fR, +\fBdelay_template\fR, \fBsuccess_template\fR and +\fBverify_template\fR, respectively. You can but do not +have to specify all four templates in a bounce template +file. + +Each template starts with "\fItemplate_name\fB = <XXX" -compact +.It Pa /etc/crontab +System crontab. +.It Pa /var/cron/tabs/ Ns Aq Ar user +User crontab. +.El +.Sh EXAMPLES +.Bd -literal +# use /bin/sh to run commands, no matter what /etc/passwd says +SHELL=/bin/sh +# mail any output to `paul', no matter whose crontab this is +MAILTO=paul +# +# run five minutes after midnight, every day +5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1 +# run at 2:15pm on the first of every month -- output mailed to paul +15 14 1 * * $HOME/bin/monthly +# run at 10 pm on weekdays, annoy Joe +0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?% +23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday" +5 4 * * sun echo "run at 5 after 4 every sunday" +.Ed +.Sh SEE ALSO +.Xr crontab 1 , +.Xr cron 8 +.Sh STANDARDS +The +.Nm +file format is compliant with the +.St -p1003.1-2008 +specification. +The behaviours described below are all extensions to that standard: +.Bl -dash +.It +The +.Ar day-of-week +field may use 7 to represent Sunday. +.It +Ranges may include +.Dq steps . +.It +Months or days of the week can be specified by name. +.It +Mailing after a successful run can be suppressed with +.Fl n . +.It +Logging can be suppressed with +.Fl q . +.It +Environment variables can be set in a crontab. +.It +Command output can be mailed to a person other than the crontab +owner, or the feature can be turned off and no mail will be sent +at all. +.It +All of the +.Ql @ +commands that can appear in place of the first five fields. +.El +.Sh AUTHORS +.Nm +was written by +.An Paul Vixie Aq Mt vixie@isc.org . diff --git a/static/netbsd/man5/ctf.5 b/static/netbsd/man5/ctf.5 new file mode 100644 index 00000000..6849a0f0 --- /dev/null +++ b/static/netbsd/man5/ctf.5 @@ -0,0 +1,1243 @@ +.\" +.\" This file and its contents are supplied under the terms of the +.\" Common Development and Distribution License ("CDDL"), version 1.0. +.\" You may only use this file in accordance with the terms of version +.\" 1.0 of the CDDL. +.\" +.\" A full copy of the text of the CDDL should have accompanied this +.\" source. A copy of the CDDL is also available via the Internet at +.\" http://www.illumos.org/license/CDDL. +.\" +.\" +.\" Copyright (c) 2014 Joyent, Inc. +.\" +.Dd February 28, 2022 +.Dt CTF 5 +.Os +.Sh NAME +.Nm ctf +.Nd Compact C Type Format +.Sh SYNOPSIS +.In sys/ctf.h +.Sh DESCRIPTION +.Nm +is designed to be a compact representation of the C programming +language's type information focused on serving the needs of dynamic +tracing, debuggers, and other in-situ and post-mortem introspection +tools. +.Nm +data is generally included in +.Sy ELF +objects and is tagged as +.Sy SHT_PROGBITS +to ensure that the data is accessible in a running process and in subsequent +core dumps, if generated. +.Lp +The +.Nm +data contained in each file has information about the layout and +sizes of C types, including intrinsic types, enumerations, structures, +typedefs, and unions, that are used by the corresponding +.Sy ELF +object. +The +.Nm +data may also include information about the types of global objects and +the return type and arguments of functions in the symbol table. +.Lp +Because a +.Nm +file is often embedded inside a file, rather than being a standalone +file itself, it may also be referred to as a +.Nm +.Sy container . +.Lp +On +.Nx +systems, +.Nm +data is consumed by +.Xr dtrace 1 . +Programmatic access to +.Nm +data can be obtained through libctf. +.Lp +The +.Nm +file format is broken down into seven different sections. +The first two sections are the +.Sy preamble +and +.Sy header , +which describe the version of the +.Nm +file, the links it has to other +.Nm +files, and the sizes of the other sections. +The next section is the +.Sy label +section, +which provides a way of identifying similar groups of +.Nm +data across multiple files. +This is followed by the +.Sy object +information section, which describes the types of global +symbols. +The subsequent section is the +.Sy function +information section, which describes the return +types and arguments of functions. +The next section is the +.Sy type +information section, which describes +the format and layout of the C types themselves, and finally the last +section is the +.Sy string +section, which contains the names of types, enumerations, members, and +labels. +.Lp +While strictly speaking, only the +.Sy preamble +and +.Sy header +are required, to be actually useful, both the type and string +sections are necessary. +.Lp +A +.Nm +file may contain all of the type information that it requires, or it +may optionally refer to another +.Nm +file which holds the remaining types. +When a +.Nm +file refers to another file, it is called the +.Sy child +and the file it refers to is called the +.Sy parent . +A given file may only refer to one parent. +This process is called +.Em uniquification +because it ensures each child only has type information that is +unique to it. +A common example of this is that most kernel modules in illumos are uniquified +against the kernel module +.Sy genunix +and the type information that comes from the +.Sy IP +module. +This means that a module only has types that are unique to itself and the most +common types in the kernel are not duplicated. +Uniquification is not used when building kernel modules on +.Nx . +.Sh FILE FORMAT +This documents version +.Em three +of the +.Nm +file format. +The +.Xr ctfconvert 1 +and +.Xr ctfmerge 1 +utilities emit +.Nm +version 3, and all other applications and libraries can operate on +versions 2 and 3. +.Lp +The file format can be summarized with the following image, the +following sections will cover this in more detail. +.Bd -literal + + +-------------+ 0t0 ++--------| Preamble | +| +-------------+ 0t4 +|+-------| Header | +|| +-------------+ 0t36 + cth_lbloff +||+------| Labels | +||| +-------------+ 0t36 + cth_objtoff +|||+-----| Objects | +|||| +-------------+ 0t36 + cth_funcoff +||||+----| Functions | +||||| +-------------+ 0t36 + cth_typeoff +|||||+---| Types | +|||||| +-------------+ 0t36 + cth_stroff +||||||+--| Strings | +||||||| +-------------+ 0t36 + cth_stroff + cth_strlen +||||||| +||||||| +||||||| +||||||| +-- magic - vers flags +||||||| | | | | +||||||| +------+------+------+------+ ++---------| 0xcf | 0xf1 | 0x03 | 0x00 | + |||||| +------+------+------+------+ + |||||| 0 1 2 3 4 + |||||| + |||||| + parent label + objects + |||||| | + parent name | + functions + strings + |||||| | | + label | | + types | + strlen + |||||| | | | | | | | | + |||||| +------+------+------+------+------+-------+-------+-------+ + +--------| 0x00 | 0x00 | 0x00 | 0x08 | 0x36 | 0x110 | 0x5f4 | 0x611 | + ||||| +------+------+------+------+------+-------+-------+-------+ + ||||| 0x04 0x08 0x0c 0x10 0x14 0x18 0x1c 0x20 0x24 + ||||| + ||||| + Label name + ||||| | + Label type + ||||| | | + Next label + ||||| | | | + ||||| +-------+------+-----+ + +-----------| 0x01 | 0x42 | ... | + |||| +-------+------+-----+ + |||| cth_lbloff +0x4 +0x8 cth_objtoff + |||| + |||| + |||| Symidx 0t15 0t43 0t44 + |||| +------+------+------+-----+ + +----------| 0x00 | 0x42 | 0x36 | ... | + ||| +------+------+------+-----+ + ||| cth_objtoff +0x4 +0x8 +0xc cth_funcoff + ||| + ||| + CTF_TYPE_INFO + CTF_TYPE_INFO + ||| | + Return type | + ||| | | + arg0 | + ||| +--------+------+------+-----+ + +---------| 0x2c10 | 0x08 | 0x0c | ... | + || +--------+------+------+-----+ + || cth_funcff +0x4 +0x8 +0xc cth_typeoff + || + || + ctf_stype_t for type 1 + || | integer + integer encoding + || | | + ctf_stype_t for type 2 + || | | | + || +--------------------+-----------+-----+ + +--------| 0x19 * 0xc01 * 0x0 | 0x1000000 | ... | + | +--------------------+-----------+-----+ + | cth_typeoff +0x0c +0x10 cth_stroff + | + | +--- str 0 + | | +--- str 1 + str 2 + | | | | + | v v v + | +----+---+---+---+----+---+---+---+---+---+----+ + +---| \\0 | i | n | t | \\0 | f | o | o | _ | t | \\0 | + +----+---+---+---+----+---+---+---+---+---+----+ + 0 1 2 3 4 5 6 7 8 9 10 11 +.Ed +.Lp +Every +.Nm +file begins with a +.Sy preamble , +followed by a +.Sy header . +The +.Sy preamble +is defined as follows: +.Bd -literal +typedef struct ctf_preamble { + uint16_t ctp_magic; /* magic number (CTF_MAGIC) */ + uint8_t ctp_version; /* data format version number (CTF_VERSION) */ + uint8_t ctp_flags; /* flags (see below) */ +} ctf_preamble_t; +.Ed +.Pp +The +.Sy preamble +is four bytes long and must be four byte aligned. +This +.Sy preamble +defines the version of the +.Nm +file which defines the format of the rest of the header. +While the header may change in subsequent versions, the preamble will not change +across versions, though the interpretation of its flags may change from +version to version. +The +.Em ctp_magic +member defines the magic number for the +.Nm +file format. +This must always be +.Li 0xcff1 . +If another value is encountered, then the file should not be treated as +a +.Nm +file. +The +.Em ctp_version +member defines the version of the +.Nm +file. +The current version is +.Li 3 . +It is possible to encounter an unsupported version. +In that case, software should not try to parse the format, as it may have +changed. +Finally, the +.Em ctp_flags +member describes aspects of the file which modify its interpretation. +The following flags are currently defined: +.Bd -literal +#define CTF_F_COMPRESS 0x01 +.Ed +.Pp +The flag +.Sy CTF_F_COMPRESS +indicates that the body of the +.Nm +file, all the data following the +.Sy header , +has been compressed through the +.Sy zlib +library and its +.Sy deflate +algorithm. +If this flag is not present, then the body has not been compressed and no +special action is needed to interpret it. +All offsets into the data as described by +.Sy header , +always refer to the +.Sy uncompressed +data. +.Lp +In versions two and three of the +.Nm +file format, the +.Sy header +denotes whether or not this +.Nm +file is the child of another +.Nm +file and also indicates the size of the remaining sections. +The structure for the +.Sy header +logically contains a copy of the +.Sy preamble +and the two have a combined size of 36 bytes. +.Bd -literal +typedef struct ctf_header { + ctf_preamble_t cth_preamble; + uint32_t cth_parlabel; /* ref to name of parent lbl uniq'd against */ + uint32_t cth_parname; /* ref to basename of parent */ + uint32_t cth_lbloff; /* offset of label section */ + uint32_t cth_objtoff; /* offset of object section */ + uint32_t cth_funcoff; /* offset of function section */ + uint32_t cth_typeoff; /* offset of type section */ + uint32_t cth_stroff; /* offset of string section */ + uint32_t cth_strlen; /* length of string section in bytes */ +} ctf_header_t; +.Ed +.Pp +After the +.Sy preamble , +the next two members +.Em cth_parlabel +and +.Em cth_parname , +are used to identify the parent. +The value of both members are offsets into the +.Sy string +section which point to the start of a null-terminated string. +For more information on the encoding of strings, see the subsection on +.Sx String Identifiers . +If the value of either is zero, then there is no entry for that +member. +If the member +.Em cth_parlabel +is set, then the +.Em ctf_parname +member must be set, otherwise it will not be possible to find the +parent. +If +.Em ctf_parname +is set, it is not necessary to define +.Em cth_parlabel , +as the parent may not have a label. +For more information on labels and their interpretation, see +.Sx The Label Section . +.Lp +The remaining members (excepting +.Em cth_strlen ) +describe the beginning of the corresponding sections. +These offsets are relative to the end of the +.Sy header . +Therefore, something with an offset of 0 is at an offset of thirty-six +bytes relative to the start of the +.Nm +file. +The difference between members indicates the size of the section itself. +Different offsets have different alignment requirements. +The start of the +.Em cth_objtoff +and +.Em cth_funcoff +must be two byte aligned, while the sections +.Em cth_lbloff +and +.Em cth_typeoff +must be four-byte aligned. +The section +.Em cth_stroff +has no alignment requirements. +To calculate the size of a given section, excepting the +.Sy string +section, one should subtract the offset of the section from the following one. +For example, the size of the +.Sy types +section can be calculated by subtracting +.Em cth_typeoff +from +.Em cth_stroff . +.Lp +Finally, the member +.Em cth_strlen +describes the length of the string section itself. +From it, you can also calculate the size of the entire +.Nm +file by adding together the size of the +.Sy ctf_header_t , +the offset of the string section in +.Em cth_stroff , +and the size of the string section in +.Em cth_srlen . +.Ss Type Identifiers +Through the +.Nm ctf +data, types are referred to by identifiers. +A given +.Nm +file supports up to 2147483646 (0x7ffffffe) types. +.Nm +version 2 had a much smaller limit of 32767 types. +The first valid type identifier is 0x1. +When a given +.Nm +file is a child, indicated by a non-zero entry for the +.Sy header Ns 's +.Em cth_parname , +then the first valid type identifier is 0x80000000 and the last is 0xfffffffe. +In this case, type identifiers 0x1 through 0x7ffffffe are references to the +parent. +0x7fffffff and 0xffffffff are not treated as valid type identifiers so as to +enable the use of -1 as an error value. +.Lp +The type identifier zero is a sentinel value used to indicate that there +is no type information available or it is an unknown type. +.Lp +Throughout the file format, the identifier is stored in different sized +values; however, the minimum size to represent a given identifier is a +.Sy uint16_t . +Other consumers of +.Nm +information may use larger or opaque identifiers. +.Ss String Identifiers +String identifiers are always encoded as four byte unsigned integers +which are an offset into a string table. +The +.Nm +format supports two different string tables which have an identifier of +zero or one. +This identifier is stored in the high-order bit of the unsigned four byte +offset. +Therefore, the maximum supported offset into one of these tables is 0x7ffffffff. +.Lp +Table identifier zero, always refers to the +.Sy string +section in the CTF file itself. +String table identifier one refers to an external string table which is the ELF +string table for the ELF symbol table associated with the +.Nm +container. +.Ss Type Encoding +Every +.Nm +type begins with metadata encoded into a +.Sy uint32_t . +This encoded information tells us three different pieces of information: +.Bl -bullet -offset indent -compact +.It +The kind of the type +.It +Whether this type is a root type or not +.It +The length of the variable data +.El +.Lp +The 32 bits that make up the encoding are broken down into six bits +for the kind (bits 26 to 31), one bit for the root type flag (bit 25), +and 25 bits for the length of the variable data. +.Lp +The current version of the file format defines 14 different kinds. +The interpretation of these different kinds will be discussed in the section +.Sx The Type Section . +If a kind is encountered that is not listed below, then it is not a valid +.Nm +file. +The kinds are defined as follows: +.Bd -literal -offset indent +#define CTF_K_UNKNOWN 0 +#define CTF_K_INTEGER 1 +#define CTF_K_FLOAT 2 +#define CTF_K_POINTER 3 +#define CTF_K_ARRAY 4 +#define CTF_K_FUNCTION 5 +#define CTF_K_STRUCT 6 +#define CTF_K_UNION 7 +#define CTF_K_ENUM 8 +#define CTF_K_FORWARD 9 +#define CTF_K_TYPEDEF 10 +#define CTF_K_VOLATILE 11 +#define CTF_K_CONST 12 +#define CTF_K_RESTRICT 13 +.Ed +.Lp +Programs directly reference many types; however, other types are referenced +indirectly because they are part of some other structure. +These types that are referenced directly and used are called +.Sy root +types. +Other types may be used indirectly, for example, a program may reference +a structure directly, but not one of its members which has a type. +That type is not considered a +.Sy root +type. +If a type is a +.Sy root +type, then it will have bit 25 set. +.Lp +The variable length section is specific to each kind and is discussed in the +section +.Sx The Type Section . +.Lp +The following macros are useful for constructing and deconstructing the encoded +type information: +.Bd -literal -offset indent + +#define CTF_V3_MAX_VLEN 0x00ffffff +#define CTF_V3_INFO_KIND(info) (((info) & 0xfc000000) >> 26) +#define CTF_V3_INFO_ISROOT(info) (((info) & 0x02000000) >> 25) +#define CTF_V3_INFO_VLEN(info) (((info) & CTF_V3_MAX_VLEN)) + +#define CTF_V3_TYPE_INFO(kind, isroot, vlen) \\ + (((kind) << 26) | (((isroot) ? 1 : 0) << 25) | ((vlen) & CTF_V3_MAX_VLEN)) +.Ed +.Ss The Label Section +When consuming +.Nm +data, it is often useful to know whether two different +.Nm +containers come from the same source base and version. +For example, when building illumos, there are many kernel modules that are built +against a single collection of source code. +A label is encoded into the +.Nm +files that corresponds with the particular build. +This ensures that if files on the system were to become mixed up from multiple +releases, that they are not used together by tools, particularly when a child +needs to refer to a type in the parent. +Because they are linked using the type identifiers, if the wrong parent is used +then the wrong type will be encountered. +Note that this mechanism is not currently used on +.Nx . +In particular, kernel modules built on +.Nx +each contain a complete type graph. +.Lp +Each label is encoded in the file format using the following eight byte +structure: +.Bd -literal +typedef struct ctf_lblent { + uint32_t ctl_label; /* ref to name of label */ + uint32_t ctl_typeidx; /* last type associated with this label */ +} ctf_lblent_t; +.Ed +.Lp +Each label has two different components, a name and a type identifier. +The name is encoded in the +.Em ctl_label +member which is in the format defined in the section +.Sx String Identifiers . +Generally, the names of all labels are found in the internal string +section. +.Lp +The type identifier encoded in the member +.Em ctl_typeidx +refers to the last type identifier that a label refers to in the current +file. +Labels only refer to types in the current file, if the +.Nm +file is a child, then it will have the same label as its parent; +however, its label will only refer to its types, not its parent's. +.Lp +It is also possible, though rather uncommon, for a +.Nm +file to have multiple labels. +Labels are placed one after another, every eight bytes. +When multiple labels are present, types may only belong to a single label. +.Ss The Object Section +The object section provides a mapping from ELF symbols of type +.Sy STT_OBJECT +in the symbol table to a type identifier. +Every entry in this section is a +.Sy uint32_t +which contains a type identifier as described in the section +.Sx Type Identifiers . +If there is no information for an object, then the type identifier 0x0 +is stored for that entry. +.Lp +To walk the object section, you need to have a corresponding +.Sy symbol table +in the ELF object that contains the +.Nm +data. +Not every object is included in this section. +Specifically, when walking the symbol table, an entry is skipped if it matches +any of the following conditions: +.Lp +.Bl -bullet -offset indent -compact +.It +The symbol type is not +.Sy STT_OBJECT +.It +The symbol's section index is +.Sy SHN_UNDEF +.It +The symbol's name offset is zero +.It +The symbol's section index is +.Sy SHN_ABS +and the value of the symbol is zero. +.It +The symbol's name is +.Li _START_ +or +.Li _END_ . +These are skipped because they are used for scoping local symbols in +ELF. +.El +.Lp +The following sample code shows an example of iterating the object +section and skipping the correct symbols: +.Bd -literal +#include +#include + +/* + * Given the start of the object section in a CTFv3 file, the number of symbols, + * and the ELF Data sections for the symbol table and the string table, this + * prints the type identifiers that correspond to objects. Note, a more robust + * implementation should ensure that they don't walk beyond the end of the CTF + * object section. + * + * An implementation that handles CTFv2 must take into account the fact that + * type identifiers are 16 bits wide rather than 32 bits wide. + */ +static int +walk_symbols(uint32_t *objtoff, Elf_Data *symdata, Elf_Data *strdata, + long nsyms) +{ + long i; + uintptr_t strbase = strdata->d_buf; + + for (i = 1; i < nsyms; i++, objftoff++) { + const char *name; + GElf_Sym sym; + + if (gelf_getsym(symdata, i, &sym) == NULL) + return (1); + + if (GELF_ST_TYPE(sym.st_info) != STT_OBJECT) + continue; + if (sym.st_shndx == SHN_UNDEF || sym.st_name == 0) + continue; + if (sym.st_shndx == SHN_ABS && sym.st_value == 0) + continue; + name = (const char *)(strbase + sym.st_name); + if (strcmp(name, "_START_") == 0 || strcmp(name, "_END_") == 0) + continue; + + (void) printf("Symbol %d has type %d\n", i, *objtoff); + } + + return (0); +} +.Ed +.Ss The Function Section +The function section of the +.Nm +file encodes the types of both the function's arguments and the function's +return value. +Similar to +.Sx The Object Section , +the function section encodes information for all symbols of type +.Sy STT_FUNCTION , +excepting those that fit specific criteria. +Unlike with objects, because functions have a variable number of arguments, they +start with a type encoding as defined in +.Sx Type Encoding , +which is the size of a +.Sy uint32_t . +For functions which have no type information available, they are encoded as +.Li CTF_V3_TYPE_INFO(CTF_K_UNKNOWN, 0, 0) . +Functions with arguments are encoded differently. +Here, the variable length is turned into the number of arguments in the +function. +If a function is a +.Sy varargs +type function, then the number of arguments is increased by one. +Functions with type information are encoded as: +.Li CTF_V3_TYPE_INFO(CTF_K_FUNCTION, 0, nargs) . +.Lp +For functions that have no type information, nothing else is encoded, and the +next function is encoded. +For functions with type information, the next +.Sy uint32_t +is encoded with the type identifier of the return type of the function. +It is followed by each of the type identifiers of the arguments, if any exist, +in the order that they appear in the function. +Therefore, argument 0 is the first type identifier and so on. +When a function has a final varargs argument, that is encoded with the type +identifier of zero. +.Lp +Like +.Sx The Object Section , +the function section is encoded in the order of the symbol table. +It has similar, but slightly different considerations from objects. +While iterating the symbol table, if any of the following conditions are true, +then the entry is skipped and no corresponding entry is written: +.Lp +.Bl -bullet -offset indent -compact +.It +The symbol type is not +.Sy STT_FUNCTION +.It +The symbol's section index is +.Sy SHN_UNDEF +.It +The symbol's name offset is zero +.It +The symbol's name is +.Li _START_ +or +.Li _END_ . +These are skipped because they are used for scoping local symbols in +ELF. +.El +.Ss The Type Section +The type section is the heart of the +.Nm +data. +It encodes all of the information about the types themselves. +The base of the type information comes in two forms, a short form and a long +form, each of which may be followed by a variable number of arguments. +The following definitions describe the short and long forms: +.Bd -literal +#define CTF_V3_MAX_SIZE 0xfffffffe /* max size of a type in bytes */ +#define CTF_V3_LSIZE_SENT 0xffffffff /* sentinel for ctt_size */ +#define CTF_V3_MAX_LSIZE UINT64_MAX + +struct ctf_stype_v3 { + uint32_t ctt_name; /* reference to name in string table */ + uint32_t ctt_info; /* encoded kind, variant length */ + union { + uint32_t _size; /* size of entire type in bytes */ + uint32_t _type; /* reference to another type */ + } _u; +}; + +struct ctf_type_v3 { + uint32_t ctt_name; /* reference to name in string table */ + uint32_t ctt_info; /* encoded kind, variant length */ + union { + uint32_t _size; /* always CTF_LSIZE_SENT */ + uint32_t _type; /* do not use */ + } _u; + uint32_t ctt_lsizehi; /* high 32 bits of type size in bytes */ + uint32_t ctt_lsizelo; /* low 32 bits of type size in bytes */ +}; + +#define ctt_size _u._size /* for fundamental types that have a size */ +#define ctt_type _u._type /* for types that reference another type */ +.Ed +.Pp +Type sizes are stored in +.Sy bytes . +The basic small form uses a +.Sy uint32_t +to store the number of bytes. +If the number of bytes in a structure would exceed 0xfffffffe, then the +alternate form, the +.Sy struct ctf_type_v3 , +is used instead. +To indicate that the larger form is being used, the member +.Em ctt_size +is set to value of +.Sy CTF_V3_LSIZE_SENT +(0xffffffff). +In general, when going through the type section, consumers use the +.Sy struct ctf_type_v3 +structure, but pay attention to the value of the member +.Em ctt_size +to determine whether they should increment their scan by the size of +.Sy struct ctf_stype_v3 +or +.Sy struct ctf_type_v3 . +Not all kinds of types use +.Sy ctt_size . +Those which do not, will always use the +.Sy struct ctf_stype_v3 +structure. +The individual sections for each kind have more information. +.Lp +Types are written out in order. +Therefore the first entry encountered has a type id of 0x1, or 0x8000 if a +child. +The member +.Em ctt_name +is encoded as described in the section +.Sx String Identifiers . +The string that it points to is the name of the type. +If the identifier points to an empty string (one that consists solely of a null +terminator) then the type does not have a name, this is common with anonymous +structures and unions that only have a typedef to name them, as well as +pointers and qualifiers. +.Lp +The next member, the +.Em ctt_info , +is encoded as described in the section +.Sx Type Encoding . +The type's kind tells us how to interpret the remaining data in the +.Sy struct ctf_type_v3 +and any variable length data that may exist. +The rest of this section will be broken down into the interpretation of the +various kinds. +.Ss Encoding of Integers +Integers, which are of type +.Sy CTF_K_INTEGER , +have no variable length arguments. +Instead, they are followed by a +.Sy uint32_t +which describes their encoding. +All integers must be encoded with a variable length of zero. +The +.Em ctt_size +member describes the length of the integer in bytes. +In general, integer sizes will be rounded up to the closest power of two. +.Lp +The integer encoding contains three different pieces of information: +.Bl -bullet -offset indent -compact +.It +The encoding of the integer +.It +The offset in +.Sy bits +of the type +.It +The size in +.Sy bits +of the type +.El +.Pp +This encoding can be expressed through the following macros: +.Bd -literal -offset indent +#define CTF_INT_ENCODING(data) (((data) & 0xff000000) >> 24) +#define CTF_INT_OFFSET(data) (((data) & 0x00ff0000) >> 16) +#define CTF_INT_BITS(data) (((data) & 0x0000ffff)) + +#define CTF_INT_DATA(encoding, offset, bits) \\ + (((encoding) << 24) | ((offset) << 16) | (bits)) +.Ed +.Pp +The following flags are defined for the encoding at this time: +.Bd -literal -offset indent +#define CTF_INT_SIGNED 0x01 +#define CTF_INT_CHAR 0x02 +#define CTF_INT_BOOL 0x04 +#define CTF_INT_VARARGS 0x08 +.Ed +.Lp +By default, an integer is considered to be unsigned, unless it has the +.Sy CTF_INT_SIGNED +flag set. +If the flag +.Sy CTF_INT_CHAR +is set, that indicates that the integer is of a type that stores character +data, for example the intrinsic C type +.Sy char +would have the +.Sy CTF_INT_CHAR +flag set. +If the flag +.Sy CTF_INT_BOOL +is set, that indicates that the integer represents a boolean type. +For example, the intrinsic C type +.Sy _Bool +would have the +.Sy CTF_INT_BOOL +flag set. +Finally, the flag +.Sy CTF_INT_VARARGS +indicates that the integer is used as part of a variable number of arguments. +This encoding is rather uncommon. +.Ss Encoding of Floats +Floats, which are of type +.Sy CTF_K_FLOAT , +are similar to their integer counterparts. +They have no variable length arguments and are followed by a four byte encoding +which describes the kind of float that exists. +The +.Em ctt_size +member is the size, in bytes, of the float. +The float encoding has three different pieces of information inside of it: +.Lp +.Bl -bullet -offset indent -compact +.It +The specific kind of float that exists +.It +The offset in +.Sy bits +of the float +.It +The size in +.Sy bits +of the float +.El +.Lp +This encoding can be expressed through the following macros: +.Bd -literal -offset indent +#define CTF_FP_ENCODING(data) (((data) & 0xff000000) >> 24) +#define CTF_FP_OFFSET(data) (((data) & 0x00ff0000) >> 16) +#define CTF_FP_BITS(data) (((data) & 0x0000ffff)) + +#define CTF_FP_DATA(encoding, offset, bits) \\ + (((encoding) << 24) | ((offset) << 16) | (bits)) +.Ed +.Lp +Where as the encoding for integers is a series of flags, the encoding for +floats maps to a specific kind of float. +It is not a flag-based value. +The kinds of floats correspond to both their size, and the encoding. +This covers all of the basic C intrinsic floating point types. +The following are the different kinds of floats represented in the encoding: +.Bd -literal -offset indent +#define CTF_FP_SINGLE 1 /* IEEE 32-bit float encoding */ +#define CTF_FP_DOUBLE 2 /* IEEE 64-bit float encoding */ +#define CTF_FP_CPLX 3 /* Complex encoding */ +#define CTF_FP_DCPLX 4 /* Double complex encoding */ +#define CTF_FP_LDCPLX 5 /* Long double complex encoding */ +#define CTF_FP_LDOUBLE 6 /* Long double encoding */ +#define CTF_FP_INTRVL 7 /* Interval (2x32-bit) encoding */ +#define CTF_FP_DINTRVL 8 /* Double interval (2x64-bit) encoding */ +#define CTF_FP_LDINTRVL 9 /* Long double interval (2x128-bit) encoding */ +#define CTF_FP_IMAGRY 10 /* Imaginary (32-bit) encoding */ +#define CTF_FP_DIMAGRY 11 /* Long imaginary (64-bit) encoding */ +#define CTF_FP_LDIMAGRY 12 /* Long double imaginary (128-bit) encoding */ +.Ed +.Ss Encoding of Arrays +Arrays, which are of type +.Sy CTF_K_ARRAY , +have no variable length arguments. +They are followed by a structure which describes the number of elements in the +array, the type identifier of the elements in the array, and the type identifier +of the index of the array. +With arrays, the +.Em ctt_size +member is set to zero. +The structure that follows an array is defined as: +.Bd -literal +struct ctf_array_v3 { + uint32_t cta_contents; /* reference to type of array contents */ + uint32_t cta_index; /* reference to type of array index */ + uint32_t cta_nelems; /* number of elements */ +}; +.Ed +.Lp +The +.Em cta_contents +and +.Em cta_index +members of the +.Sy struct ctf_array_v3 +are type identifiers which are encoded as per the section +.Sx Type Identifiers . +The member +.Em cta_nelems +is a simple four byte unsigned count of the number of elements. +This count may be zero when encountering C99's flexible array members. +.Ss Encoding of Functions +Function types, which are of type +.Sy CTF_K_FUNCTION , +use the variable length list to be the number of arguments in the function. +When the function has a final member which is a varargs, then the argument count +is incremented by one to account for the variable argument. +Here, the +.Em ctt_type +member is encoded with the type identifier of the return type of the function. +Note that the +.Em ctt_size +member is not used here. +.Lp +The variable argument list contains the type identifiers for the arguments of +the function, if any. +Each one is represented by a +.Sy uint32_t +and encoded according to the +.Sx Type Identifiers +section. +If the function's last argument is of type varargs, then it is also written out, +but the type identifier is zero. +This is included in the count of the function's arguments. +In +.Nm +version 2, an extra type identifier may follow the argument and return type +identifiers in order to maintain four-byte alignment for the following type +definition. +Such a type identifier is not included in the argument count and has a value +of zero. +In +.Nm +version 3, four-byte alignment occurs naturally and no padding is used. +.Ss Encoding of Structures and Unions +Structures and Unions, which are encoded with +.Sy CTF_K_STRUCT +and +.Sy CTF_K_UNION +respectively, are very similar constructs in C. +The main difference between them is the fact that members of a structure +follow one another, where as in a union, all members share the same memory. +They are also very similar in terms of their encoding in +.Nm . +The variable length argument for structures and unions represents the number of +members that they have. +The value of the member +.Em ctt_size +is the size of the structure and union. +There are two different structures which are used to encode members in the +variable list. +When the size of a structure or union is greater than or equal to the large +member threshold, 536870912, then a different structure is used to encode the +member; all members are encoded using the same structure. +The structure for members is as follows: +.Bd -literal +struct ctf_member_v3 { + uint32_t ctm_name; /* reference to name in string table */ + uint32_t ctm_type; /* reference to type of member */ + uint32_t ctm_offset; /* offset of this member in bits */ +}; + +struct ctf_lmember_v3 { + uint32_t ctlm_name; /* reference to name in string table */ + uint32_t ctlm_type; /* reference to type of member */ + uint32_t ctlm_offsethi; /* high 32 bits of member offset in bits */ + uint32_t ctlm_offsetlo; /* low 32 bits of member offset in bits */ +}; +.Ed +.Lp +Both the +.Em ctm_name +and +.Em ctlm_name +refer to the name of the member. +The name is encoded as an offset into the string table as described by the +section +.Sx String Identifiers . +The members +.Sy ctm_type +and +.Sy ctlm_type +both refer to the type of the member. +They are encoded as per the section +.Sx Type Identifiers . +.Lp +The last piece of information that is present is the offset which describes the +offset in memory at which the member begins. +For unions, this value will always be zero because each member of a union has +an offset of zero. +For structures, this is the offset in +.Sy bits +at which the member begins. +Note that a compiler may lay out a type with padding. +This means that the difference in offset between two consecutive members may be +larger than the size of the member. +When the size of the overall structure is strictly less than 536870912 bytes, +the normal structure, +.Sy struct ctf_member_v3 , +is used and the offset in bits is stored in the member +.Em ctm_offset . +However, when the size of the structure is greater than or equal to 536870912 +bytes, then the number of bits is split into two 32-bit quantities. +One member, +.Em ctlm_offsethi , +represents the upper 32 bits of the offset, while the other member, +.Em ctlm_offsetlo , +represents the lower 32 bits of the offset. +These can be joined together to get a 64-bit sized offset in bits by shifting +the member +.Em ctlm_offsethi +to the left by thirty two and then doing a binary or of +.Em ctlm_offsetlo . +.Ss Encoding of Enumerations +Enumerations, noted by the type +.Sy CTF_K_ENUM , +are similar to structures. +Enumerations use the variable list to note the number of values that the +enumeration contains, which we'll term enumerators. +In C, an enumeration is always equivalent to the intrinsic type +.Sy int , +thus the value of the member +.Em ctt_size +is always the size of an integer which is determined based on the current model. +For +.Nx +systems, this will always be 4, as an integer is always defined to +be 4 bytes large in both +.Sy ILP32 +and +.Sy LP64 , +regardless of the architecture. +For further details, see +.Xr arch 7 . +.Lp +The enumerators encoded in an enumeration have the following structure in the +variable list: +.Bd -literal +typedef struct ctf_enum { + uint32_t cte_name; /* reference to name in string table */ + int32_t cte_value; /* value associated with this name */ +} ctf_enum_t; +.Ed +.Pp +The member +.Em cte_name +refers to the name of the enumerator's value, it is encoded according to the +rules in the section +.Sx String Identifiers . +The member +.Em cte_value +contains the integer value of this enumerator. +.Ss Encoding of Forward References +Forward references, types of kind +.Sy CTF_K_FORWARD , +in a +.Nm +file refer to types which may not have a definition at all, only a name. +If the +.Nm +file is a child, then it may be that the forward is resolved to an +actual type in the parent, otherwise the definition may be in another +.Nm +container or may not be known at all. +The only member of the +.Sy struct ctf_type_v3 +that matters for a forward declaration is the +.Em ctt_name +which points to the name of the forward reference in the string table as +described earlier. +There is no other information recorded for forward references. +.Ss Encoding of Pointers, Typedefs, Volatile, Const, and Restrict +Pointers, typedefs, volatile, const, and restrict are all similar in +.Nm . +They all refer to another type. +In the case of typedefs, they provide an alternate name, while volatile, const, +and restrict change how the type is interpreted in the C programming language. +This covers the +.Nm +kinds +.Sy CTF_K_POINTER , +.Sy CTF_K_TYPEDEF , +.Sy CTF_K_VOLATILE , +.Sy CTF_K_RESTRICT , +and +.Sy CTF_K_CONST . +.Lp +These types have no variable list entries and use the member +.Em ctt_type +to refer to the base type that they modify. +.Ss Encoding of Unknown Types +Types with the kind +.Sy CTF_K_UNKNOWN +are used to indicate gaps in the type identifier space. +These entries consume an identifier, but do not define anything. +Nothing should refer to these gap identifiers. +.Ss Dependencies Between Types +C types can be imagined as a directed, cyclic, graph. +Structures and unions may refer to each other in a way that creates a cyclic +dependency. +In cases such as these, the entire type section must be read in and processed. +Consumers must not assume that every type can be laid out in dependency order; +they cannot. +.Ss The String Section +The last section of the +.Nm +file is the +.Sy string +section. +This section encodes all of the strings that appear throughout the other +sections. +It is laid out as a series of characters followed by a null terminator. +Generally, all names are written out in ASCII, as most C compilers do not allow +any characters to appear in identifiers outside of a subset of ASCII. +However, any extended characters sets should be written out as a series of UTF-8 +bytes. +.Lp +The first entry in the section, at offset zero, is a single null +terminator to reference the empty string. +Following that, each C string should be written out, including the null +terminator. +Offsets that refer to something in this section should refer to the first byte +which begins a string. +Beyond the first byte in the section being the null terminator, the order of +strings is unimportant. +.Ss Data Encoding and ELF Considerations +.Nm +data is generally included in ELF objects which specify information to +identify the architecture and endianness of the file. +A +.Nm +container inside such an object must match the endianness of the ELF object. +Aside from the question of the endian encoding of data, there should be no other +differences between architectures. +While many of the types in this document refer to non-fixed size C integral +types, they are equivalent in the models +.Sy ILP32 +and +.Sy LP64 . +If any other model is being used with +.Nm +data that has different sizes, then it must not use the model's sizes for +those integral types and instead use the fixed size equivalents based on an +.Sy ILP32 +environment. +.Lp +When placing a +.Nm +container inside of an ELF object, there are certain conventions that are +expected for the purposes of tooling being able to find the +.Nm +data. +In particular, a given ELF object should only contain a single +.Nm +section. +Multiple containers should be merged together into a single one. +.Lp +The +.Nm +file should be included in its own ELF section. +The section's name must be +.Ql .SUNW_ctf . +The type of the section must be +.Sy SHT_PROGBITS . +The section should have a link set to the symbol table and its address +alignment must be 4. +.Sh SEE ALSO +.Xr ctfconvert 1 , +.Xr ctfdump 1 , +.Xr ctfmerge 1 , +.Xr dtrace 1 , +.Xr elf 3 , +.Xr gelf 3 , +.Xr a.out 5 , +.Xr elf 5 diff --git a/static/netbsd/man5/cvs.5 b/static/netbsd/man5/cvs.5 new file mode 100644 index 00000000..589f0678 --- /dev/null +++ b/static/netbsd/man5/cvs.5 @@ -0,0 +1,330 @@ +.TH cvs 5 "12 February 1992" +.\" Full space in nroff; half space in troff +.de SP +.if n .sp +.if t .sp .5 +.. +.SH NAME +cvs \- Concurrent Versions System support files +.SH NOTE +This documentation may no longer be up to date. Please consult the Cederqvist +(CVS Manual) as specified in +.BR cvs ( 1 ). + +.SH SYNOPSIS +.hy 0 +.na +.TP +.B $CVSROOT/CVSROOT/commitinfo,v +.TP +.B $CVSROOT/CVSROOT/cvsignore,v +.TP +.B $CVSROOT/CVSROOT/cvswrappers,v +.TP +.B $CVSROOT/CVSROOT/editinfo,v +.TP +.B $CVSROOT/CVSROOT/history +.TP +.B $CVSROOT/CVSROOT/loginfo,v +.TP +.B $CVSROOT/CVSROOT/modules,v +.TP +.B $CVSROOT/CVSROOT/rcsinfo,v +.TP +.B $CVSROOT/CVSROOT/taginfo,v +.ad b +.hy 1 +.SH DESCRIPTION +.B cvs +is a system for providing source control to hierarchical collections +of source directories. Commands and procedures for using \fBcvs\fP +are described in +.BR cvs ( 1 ). +.SP +.B cvs +manages \fIsource repositories\fP, the directories containing master +copies of the revision-controlled files, by copying particular +revisions of the files to (and modifications back from) developers' +private \fIworking directories\fP. In terms of file structure, each +individual source repository is an immediate subdirectory of +\fB$CVSROOT\fP. +.SP +The files described here are supporting files; they do not have to +exist for \fBcvs\fP to operate, but they allow you to make \fBcvs\fP +operation more flexible. +.SP +You can use the `\|modules\|' file to define symbolic names for +collections of source maintained with \fBcvs\fP. If there is no +`\|modules\|' file, developers must specify complete path names +(absolute, or relative to \fB$CVSROOT\fP) for the files they wish to +manage with \fBcvs\fP commands. +.SP +You can use the `\|commitinfo\|' file to define programs to execute +whenever `\|\fBcvs commit\fP\|' is about to execute. +These programs are used for ``pre-commit'' checking to verify that the +modified, added, and removed files are really ready to be committed. +Some uses for this check might be to turn off a portion (or all) of the +source repository from a particular person or group. +Or, perhaps, to verify that the changed files conform to the site's +standards for coding practice. +.SP +You can use the `\|cvswrappers\|' file to record +.B cvs +wrapper commands to be used when checking files into and out of the +repository. Wrappers allow the file or directory to be processed +on the way in and out of CVS. The intended uses are many, one +possible use would be to reformat a C file before the file is checked +in, so all of the code in the repository looks the same. +.SP +You can use the `\|loginfo\|' file to define programs to execute after +any +.BR commit , +which writes a log entry for changes in the repository. +These logging programs might be used to append the log message to a file. +Or send the log message through electronic mail to a group of developers. +Or, perhaps, post the log message to a particular newsgroup. +.SP +You can use the `\|taginfo\|' file to define programs to execute after +any +.BR tag or rtag +operation. These programs might be used to append a message to a file +listing the new tag name and the programmer who created it, or send mail +to a group of developers, or, perhaps, post a message to a particular +newsgroup. +.SP +You can use the `\|rcsinfo\|' file to define forms for log messages. +.SP +You can use the `\|editinfo\|' file to define a program to execute for +editing/validating `\|\fBcvs commit\fP\|' log entries. +This is most useful when used with a `\|rcsinfo\|' forms specification, as +it can verify that the proper fields of the form have been filled in by the +user committing the change. +.SP +You can use the `\|cvsignore\|' file to specify the default list of +files to ignore during \fBupdate\fP. +.SP +You can use the `\|history\|' file to record the \fBcvs\fP commands +that affect the repository. +The creation of this file enables history logging. +.SH FILES +.TP +.B modules +The `\|modules\|' file records your definitions of names for +collections of source code. \fBcvs\fP will use these definitions if +you use \fBcvs\fP to check in a file with the right format to +`\|\fB$CVSROOT/CVSROOT/modules,v\fP\|'. +.SP +The `\|modules\|' file may contain blank lines and comments (lines +beginning with `\|\fB#\fP\|') as well as module definitions. +Long lines can be continued on the next line by specifying a backslash +(``\e'') as the last character on the line. +.SP +A \fImodule definition\fP is a single line of the `\|modules\|' file, +in either of two formats. In both cases, \fImname\fP represents the +symbolic module name, and the remainder of the line is its definition. +.SP +\fImname\fP \fB\-a\fP \fIaliases\fP\|.\|.\|. +.br +This represents the simplest way of defining a module \fImname\fP. +The `\|\fB\-a\fP\|' flags the definition as a simple alias: \fBcvs\fP +will treat any use of \fImname\fP (as a command argument) as if the list +of names \fIaliases\fP had been specified instead. \fIaliases\fP may +contain either other module names or paths. When you use paths in +\fIaliases\fP, `\|\fBcvs checkout\fP\|' creates all intermediate +directories in the working directory, just as if the path had been +specified explicitly in the \fBcvs\fP arguments. +.SP +.nf +\fImname\fP [ \fIoptions\fP ] \fIdir\fP [ \fIfiles\fP\|.\|.\|. ] [ \fB&\fP\fImodule\fP\|.\|.\|. ] +.fi +.SP +In the simplest case, this form of module definition reduces to +`\|\fImname dir\fP\|'. This defines all the files in directory +\fIdir\fP as module \fImname\fP. \fIdir\fP is a relative path (from +\fB$CVSROOT\fP) to a directory of source in one of the source +repositories. In this case, on \fBcheckout\fP, a single directory +called \fImname\fP is created as a working directory; no intermediate +directory levels are used by default, even if \fIdir\fP was a path +involving several directory levels. +.SP +By explicitly specifying \fIfiles\fP in the module definition after +\fIdir\fP, you can select particular files from directory +\fIdir\fP. The sample definition for \fBmodules\fP is an example of +a module defined with a single file from a particular directory. Here +is another example: +.SP +.nf +.ft B +m4test unsupported/gnu/m4 foreach.m4 forloop.m4 +.ft P +.fi +.SP +With this definition, executing `\|\fBcvs checkout m4test\fP\|' +will create a single working directory `\|m4test\|' containing the two +files listed, which both come from a common directory several levels +deep in the \fBcvs\fP source repository. +.SP +A module definition can refer to other modules by including +`\|\fB&\fP\fImodule\fP\|' in its definition. \fBcheckout\fP creates +a subdirectory for each such \fImodule\fP, in your working directory. +.br +.I +New in \fBcvs\fP 1.3; +avoid this feature if sharing module definitions with older versions +of \fBcvs\fP. +.SP +Finally, you can use one or more of the following \fIoptions\fP in +module definitions: +.SP +\&`\|\fB\-d\fP \fIname\fP\|', to name the working directory something +other than the module name. +.br +.I +New in \fBcvs\fP 1.3; +avoid this feature if sharing module definitions with older versions +of \fBcvs\fP. +.SP +\&`\|\fB\-i\fP \fIprog\fP\|' allows you to specify a program \fIprog\fP +to run whenever files in a module are committed. \fIprog\fP runs with a +single argument, the full pathname of the affected directory in a +source repository. The `\|commitinfo\|', `\|loginfo\|', and +`\|editinfo\|' files provide other ways to call a program on \fBcommit\fP. +.SP +`\|\fB\-o\fP \fIprog\fP\|' allows you to specify a program \fIprog\fP +to run whenever files in a module are checked out. \fIprog\fP runs +with a single argument, the module name. +.SP +`\|\fB\-e\fP \fIprog\fP\|' allows you to specify a program \fIprog\fP +to run whenever files in a module are exported. \fIprog\fP runs +with a single argument, the module name. +.SP +`\|\fB\-t\fP \fIprog\fP\|' allows you to specify a program \fIprog\fP +to run whenever files in a module are tagged. \fIprog\fP runs with two +arguments: the module name and the symbolic tag specified to \fBrtag\fP. +.SP +`\|\fB\-u\fP \fIprog\fP\|' allows you to specify a program \fIprog\fP +to run whenever `\|\fBcvs update\fP\|' is executed from the top-level +directory of the checked-out module. \fIprog\fP runs with a +single argument, the full path to the source repository for this module. +.TP +\&\fBcommitinfo\fP, \fBloginfo\fP, \fBrcsinfo\fP, \fBeditinfo\fP +These files all specify programs to call at different points in the +`\|\fBcvs commit\fP\|' process. They have a common structure. +Each line is a pair of fields: a regular expression, separated by +whitespace from a filename or command-line template. +Whenever one of the regular expression matches a directory name in the +repository, the rest of the line is used. +If the line begins with a \fB#\fP character, the entire line is considered +a comment and is ignored. +Whitespace between the fields is also ignored. +.SP +For `\|loginfo\|', the rest of the +line is a command-line template to execute. +The templates can include not only +a program name, but whatever list of arguments you wish. If you write +`\|\fB%s\fP\|' somewhere on the argument list, \fBcvs\fP supplies, at +that point, the list of files affected by the \fBcommit\fP. +The first entry in the list is the relative path within the source +repository where the change is being made. +The remaining arguments list the files that are being modified, added, or +removed by this \fBcommit\fP invocation. +.SP +For `\|taginfo\|', the rest of the +line is a command-line template to execute. +The arguments passed to the command are, in order, the +.I tagname , +.I operation +(i.e. +.B add +for `tag', +.B mov +for `tag -F', and +.B del +for `tag -d`), +.I repository , +and any remaining are pairs of +.B "filename revision" . +A non-zero exit of the filter program will cause the tag to be aborted. +.SP +For `\|commitinfo\|', the rest of the line is a command-line template to +execute. +The template can include not only a program name, but whatever +list of arguments you wish. +The full path to the current source repository is appended to the template, +followed by the file names of any files involved in the commit (added, +removed, and modified files). +.SP +For `\|rcsinfo\|', the rest of the line is the full path to a file that +should be loaded into the log message template. +.SP +For `\|editinfo\|', the rest of the line is a command-line template to +execute. +The template can include not only a program name, but whatever +list of arguments you wish. +The full path to the current log message template file is appended to the +template. +.SP +You can use one of two special strings instead of a regular +expression: `\|\fBALL\fP\|' specifies a command line template that +must always be executed, and `\|\fBDEFAULT\fP\|' specifies a command +line template to use if no regular expression is a match. +.SP +The `\|commitinfo\|' file contains commands to execute \fIbefore\fP any +other \fBcommit\fP activity, to allow you to check any conditions that +must be satisfied before \fBcommit\fP can proceed. The rest of the +\fBcommit\fP will execute only if all selected commands from this file +exit with exit status \fB0\fP. +.SP +The `\|rcsinfo\|' file allows you to specify \fIlog templates\fP for +the \fBcommit\fP logging session; you can use this to provide a form +to edit when filling out the \fBcommit\fP log. The field after the +regular expression, in this file, contains filenames (of files +containing the logging forms) rather than command templates. +.SP +The `\|editinfo\|' file allows you to execute a script \fIbefore the +commit starts\fP, but after the log information is recorded. These +"edit" scripts can verify information recorded in the log file. If +the edit script exits with a non-zero exit status, the commit is aborted. +.SP +The `\|loginfo\|' file contains commands to execute \fIat the end\fP +of a commit. The text specified as a commit log message is piped +through the command; typical uses include sending mail, filing an +article in a newsgroup, or appending to a central file. +.TP +\&\fBcvsignore\fP, \fB.cvsignore\fP +The default list of files (or +.BR sh ( 1 ) +file name patterns) to ignore during `\|\fBcvs update\fP\|'. +At startup time, \fBcvs\fP loads the compiled in default list of file name +patterns (see +.BR cvs ( 1 )). +Then the per-repository list included in \fB$CVSROOT/CVSROOT/cvsignore\fP +is loaded, if it exists. +Then the per-user list is loaded from `\|$HOME/.cvsignore\|'. +Finally, as \fBcvs\fP traverses through your directories, it will load any +per-directory `\|.cvsignore\|' files whenever it finds one. +These per-directory files are only valid for exactly the directory that +contains them, not for any sub-directories. +.TP +.B history +Create this file in \fB$CVSROOT/CVSROOT\fP to enable history logging +(see the description of `\|\fBcvs history\fP\|'). +.SH "SEE ALSO" +.BR cvs ( 1 ), +.SH COPYING +Copyright \(co 1992 Cygnus Support, Brian Berliner, and Jeff Polk +.PP +Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. +.PP +Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided that the +entire resulting derived work is distributed under the terms of a +permission notice identical to this one. +.PP +Permission is granted to copy and distribute translations of this +manual into another language, under the above conditions for modified +versions, except that this permission notice may be included in +translations approved by the Free Software Foundation instead of in +the original English. diff --git a/static/netbsd/man5/dhclient.conf.5 b/static/netbsd/man5/dhclient.conf.5 new file mode 100644 index 00000000..fbd649ab --- /dev/null +++ b/static/netbsd/man5/dhclient.conf.5 @@ -0,0 +1,788 @@ +.\" $NetBSD: dhclient.conf.5,v 1.3 2022/04/03 01:10:57 christos Exp $ +.\" +.\" Id: dhclient.conf.5,v 1.34 2012/01/24 22:23:39 sar Exp +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" This Source Code Form is subject to the terms of the Mozilla Public +.\" License, v. 2.0. If a copy of the MPL was not distributed with this +.\" file, You can obtain one at http://mozilla.org/MPL/2.0/. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" Support and other services are available for ISC products - see +.\" https://www.isc.org for more information or to learn more about ISC. +.\" +.TH dhclient.conf 5 +.SH NAME +dhclient.conf - DHCP client configuration file +.SH DESCRIPTION +The dhclient.conf file contains configuration information for +.IR dhclient, +the Internet Systems Consortium DHCP Client. +.PP +The dhclient.conf file is a free-form ASCII text file. It is parsed by +the recursive-descent parser built into dhclient. The file may contain +extra tabs and newlines for formatting purposes. Keywords in the file +are case-insensitive. Comments may be placed anywhere within the +file (except within quotes). Comments begin with the # character and +end at the end of the line. +.PP +The dhclient.conf file can be used to configure the behaviour of the +client in a wide variety of ways: protocol timing, information +requested from the server, information required of the server, +defaults to use if the server does not provide certain information, +values with which to override information provided by the server, or +values to prepend or append to information provided by the server. +The configuration file can also be preinitialized with addresses to +use on networks that don't have DHCP servers. +.SH PROTOCOL TIMING +The timing behaviour of the client need not be configured by the user. +If no timing configuration is provided by the user, a fairly +reasonable timing behaviour will be used by default - one which +results in fairly timely updates without placing an inordinate load on +the server. +.PP +If required the following statements can be used to adjust the timing +behaviour of the DHCPv4 client. The DHCPv6 protocol provides values +to use and they are not currently configurable. +.PP +.I The +.B timeout +.I statement +.PP + \fBtimeout \fItime\fR\fB;\fR +.PP +The +.I timeout +statement determines the amount of time that must pass between the +time that the client begins to try to determine its address and the +time that it decides that it's not going to be able to contact a +server. By default, this timeout is sixty seconds. After the +timeout has passed, if there are any static leases defined in the +configuration file, or any leases remaining in the lease database that +have not yet expired, the client will loop through these leases +attempting to validate them, and if it finds one that appears to be +valid, it will use that lease's address. If there are no valid +static leases or unexpired leases in the lease database, the client +will restart the protocol after the defined retry interval. +.PP +.I The +.B retry +.I statement +.PP + \fBretry \fItime\fR\fB;\fR +.PP +The +.I retry +statement determines the time that must pass after the client has +determined that there is no DHCP server present before it tries again +to contact a DHCP server. By default, this is five minutes. +.PP +.I The +.B select-timeout +.I statement +.PP + \fBselect-timeout \fItime\fR\fB;\fR +.PP +It is possible (some might say desirable) for there to be more than +one DHCP server serving any given network. In this case, it is +possible that a client may be sent more than one offer in response to +its initial lease discovery message. It may be that one of these +offers is preferable to the other (e.g., one offer may have the +address the client previously used, and the other may not). +.PP +The +.I select-timeout +is the time after the client sends its first lease discovery request +at which it stops waiting for offers from servers, assuming that it +has received at least one such offer. If no offers have been +received by the time the +.I select-timeout +has expired, the client will accept the first offer that arrives. +.PP +By default, the select-timeout is zero seconds - that is, the client +will take the first offer it sees. +.PP +.I The +.B reboot +.I statement +.PP + \fBreboot \fItime\fR\fB;\fR +.PP +When the client is restarted, it first tries to reacquire the last +address it had. This is called the INIT-REBOOT state. If it is +still attached to the same network it was attached to when it last +ran, this is the quickest way to get started. The +.I reboot +statement sets the time that must elapse after the client first tries +to reacquire its old address before it gives up and tries to discover +a new address. By default, the reboot timeout is ten seconds. +.PP +.I The +.B backoff-cutoff +.I statement +.PP + \fBbackoff-cutoff \fItime\fR\fB;\fR +.PP +The client uses an exponential backoff algorithm with some randomness, +so that if many clients try to configure themselves at the same time, +they will not make their requests in lockstep. The +.I backoff-cutoff +statement determines the maximum amount of time that the client is +allowed to back off, the actual value will be evaluated randomly between +1/2 to 1 1/2 times the \fItime\fR specified. It defaults to fifteen +seconds. +.PP +.I The +.B initial-interval +.I statement +.PP + \fBinitial-interval \fItime\fR\fB;\fR +.PP +The +.I initial-interval +statement sets the amount of time between the first attempt to reach a +server and the second attempt to reach a server. Each time a message +is sent, the interval between messages is incremented by twice the +current interval multiplied by a random number between zero and one. +If it is greater than the backoff-cutoff amount, it is set to that +amount. It defaults to ten seconds. +.PP +.I The initial-delay +.I statement +.PP + \fBinitial-delay \fItime\fR\fB;\fR +.PP +.I initial-delay +parameter sets the maximum time client can wait after start before +commencing first transmission. +According to RFC2131 Section 4.4.1, client should wait a random time between +startup and the actual first transmission. Previous versions of ISC DHCP +client used to wait random time up to 5 seconds, but that was unwanted +due to impact on startup time. As such, new versions have the default +initial delay set to 0. To restore old behavior, please set initial-delay +to 5. +.SH DHCPv6 LEASE SELECTION +In the DHCPv6 protocol the client will wait a small amount of time to +allow ADVERTISE messages from multiple servers to arrive. It will then +need to choose from all of the messages that may have arrived before +proceeding to making a request of the selected server. + +The first selection criteria is the set of options and addresses +in the message. Messages that don't include an option specified +as required will be given a score of 0 and not used. If the +\fI-R\fR option is given on the command line then messages that +don't include the correct number of bindings (IA-NA, IA-TA or +IA-PD) will be discarded. + +The next criteria is the preference value from the message. With +the highest preference value being used even if leases with better +addresses or options are available. + +Finally the lease is scored and the lease with the highest score +is selected. A lease's score is based on the number of bindings, +number of addresses and number of options it contains: +.nf + bindings * X + addresses * Y + options +.fi +By default X = 10000 and Y = 100, this will cause the client to +select a lease with more bindings over a lease with less bindings +but more addresses. The weightings were changed as part of +implementing RFC 7550. Previously they were X = 50 and Y = 100 +meaning more addresses were preferred over more bindings. If +you wish to continue using the old style you may do so by editing +the file includes/site.h and uncommenting the define for +USE_ORIGINAL_CLIENT_LEASE_WEIGHTS. +.SH LEASE REQUIREMENTS AND REQUESTS +The DHCP protocol allows the client to request that the server send it +specific information, and not send it other information that it is not +prepared to accept. The protocol also allows the client to reject +offers from servers if they don't contain information the client +needs, or if the information provided is not satisfactory. +.PP +There is a variety of data contained in offers that DHCP servers send +to DHCP clients. The data that can be specifically requested is what +are called \fIDHCP Options\fR. DHCP Options are defined in + \fBdhcp-options(5)\fR. +.PP +.I The +.B request +.I statement +.PP + \fB[ also ] request [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR +.PP +The request statement causes the client to request that any server +responding to the client send the client its values for the specified +options. Only the option names should be specified in the request +statement - not option parameters. By default, the DHCPv4 client +requests the subnet-mask, broadcast-address, time-offset, routers, +domain-name, domain-name-servers and host-name options while the DHCPv6 +client requests the dhcp6 name-servers and domain-search options. Note +that if you enter a \'request\' statement, you over-ride these defaults +and these options will not be requested. +.PP +In some cases, it may be desirable to send no parameter request list +at all. To do this, simply write the request statement but specify +no parameters: +.PP +.nf + request; +.fi +.PP +In most cases, it is desirable to simply add one option to the request +list which is of interest to the client in question. In this case, it +is best to \'also request\' the additional options: +.PP +.nf + also request domain-search, dhcp6.sip-servers-addresses; +.fi +.PP +.I The +.B require +.I statement +.PP + \fB[ also ] require [ [ \fIoption-space\fR . ] \fIoption\fR ] [\fB,\fI ... ]\fB;\fR +.PP +The require statement lists options that must be sent in order for an +offer to be accepted. Offers that do not contain all the listed +options will be ignored. There is no default require list. +.PP +.nf + require name-servers; + + interface eth0 { + also require domain-search; + } +.fi +.PP +.I The +.B send +.I statement +.PP + \fBsend [ \fIoption declaration\fR ] \fB;\fR +.PP +The send statement causes the client to send the specified option to +the server with the specified value. This is a full option +declaration as described in \fBdhcp-options(5)\fR. Options that are +always sent in the DHCP protocol should not be specified here, except +that the client can specify a requested \fBdhcp-lease-time\fR option other +than the default requested lease time, which is two hours. The other +obvious use for this statement is to send information to the server +that will allow it to differentiate between this client and other +clients or kinds of clients. +.SH DYNAMIC DNS +The client now has some very limited support for doing DNS updates +when a lease is acquired. This is prototypical, and probably doesn't +do what you want. It also only works if you happen to have control +over your DNS server, which isn't very likely. +.PP +Note that everything in this section is true whether you are using DHCPv4 +or DHCPv6. The exact same syntax is used for both. +.PP +To make it work, you have to declare a key and zone as in the DHCP +server (see \fBdhcpd.conf\fR(5) for details). You also need to +configure the \fIfqdn\fR option on the client, as follows: +.PP +.nf + send fqdn.fqdn "grosse.example.com."; + send fqdn.encoded on; + send fqdn.server-update off; + also request fqdn, dhcp6.fqdn; +.fi +.PP +The \fIfqdn.fqdn\fR option \fBMUST\fR be a fully-qualified domain +name. You \fBMUST\fR define a zone statement for the zone to be +updated. The \fIfqdn.encoded\fR option may need to be set to +\fIon\fR or \fIoff\fR, depending on the DHCP server you are using. +.PP +.I The +.B do-forward-updates +.I statement +.PP + \fBdo-forward-updates [ \fIflag\fR ] \fB;\fR +.PP +If you want to do DNS updates in the DHCP client +script (see \fBdhclient-script(8)\fR) rather than having the +DHCP client do the update directly (for example, if you want to +use SIG(0) authentication, which is not supported directly by the +DHCP client, you can instruct the client not to do the update using +the \fBdo-forward-updates\fR statement. \fIFlag\fR should be \fBtrue\fR +if you want the DHCP client to do the update, and \fBfalse\fR if +you don't want the DHCP client to do the update. By default, the DHCP +client will do the DNS update. +.SH OPTION MODIFIERS +In some cases, a client may receive option data from the server which +is not really appropriate for that client, or may not receive +information that it needs, and for which a useful default value +exists. It may also receive information which is useful, but which +needs to be supplemented with local information. To handle these +needs, several option modifiers are available. +.PP +.I The +.B default +.I statement +.PP + \fBdefault [ \fIoption declaration\fR ] \fB;\fR +.PP +If for some option the client should use the value supplied by +the server, but needs to use some default value if no value was supplied +by the server, these values can be defined in the +.B default +statement. +.PP +.I The +.B supersede +.I statement +.PP + \fBsupersede [ \fIoption declaration\fR ] \fB;\fR +.PP +If for some option the client should always use a locally-configured +value or values rather than whatever is supplied by the server, these +values can be defined in the +.B supersede +statement. +.PP +.I The +.B prepend +.I statement +.PP + \fBprepend [ \fIoption declaration\fR ] \fB;\fR +.PP +If for some set of options the client should use a value you +supply, and then use the values supplied by +the server, if any, these values can be defined in the +.B prepend +statement. The +.B prepend +statement can only be used for options which +allow more than one value to be given. This restriction is not +enforced - if you ignore it, the behaviour will be unpredictable. +.PP +.I The +.B append +.I statement +.PP + \fBappend [ \fIoption declaration\fR ] \fB;\fR +.PP +If for some set of options the client should first use the values +supplied by the server, if any, and then use values you supply, these +values can be defined in the +.B append +statement. The +.B append +statement can only be used for options which +allow more than one value to be given. This restriction is not +enforced - if you ignore it, the behaviour will be unpredictable. +.SH LEASE DECLARATIONS +.PP +.I The +.B lease +.I declaration +.PP + \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR +.PP +The DHCP client may decide after some period of time (see \fBPROTOCOL +TIMING\fR) that it is not going to succeed in contacting a +server. At that time, it consults its own database of old leases and +tests each one that has not yet timed out by pinging the listed router +for that lease to see if that lease could work. It is possible to +define one or more \fIfixed\fR leases in the client configuration file +for networks where there is no DHCP or BOOTP service, so that the +client can still automatically configure its address. This is done +with the +.B lease +statement. +.PP +NOTE: the lease statement is also used in the dhclient.leases file in +order to record leases that have been received from DHCP servers. +Some of the syntax for leases as described below is only needed in the +dhclient.leases file. Such syntax is documented here for +completeness. +.PP +A lease statement consists of the lease keyword, followed by a left +curly brace, followed by one or more lease declaration statements, +followed by a right curly brace. The following lease declarations +are possible: +.PP + \fBbootp;\fR +.PP +The +.B bootp +statement is used to indicate that the lease was acquired using the +BOOTP protocol rather than the DHCP protocol. It is never necessary +to specify this in the client configuration file. The client uses +this syntax in its lease database file. +.PP + \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR +.PP +The +.B interface +lease statement is used to indicate the interface on which the lease +is valid. If set, this lease will only be tried on a particular +interface. When the client receives a lease from a server, it always +records the interface number on which it received that lease. +If predefined leases are specified in the dhclient.conf file, the +interface should also be specified, although this is not required. +.PP + \fBfixed-address\fR \fIip-address\fR\fB;\fR +.PP +The +.B fixed-address +statement is used to set the ip address of a particular lease. This +is required for all lease statements. The IP address must be +specified as a dotted quad (e.g., 12.34.56.78). +.PP + \fBfilename "\fR\fIstring\fR\fB";\fR +.PP +The +.B filename +statement specifies the name of the boot filename to use. This is +not used by the standard client configuration script, but is included +for completeness. +.PP + \fBserver-name "\fR\fIstring\fR\fB";\fR +.PP +The +.B server-name +statement specifies the name of the boot server name to use. This is +also not used by the standard client configuration script. +.PP + \fBoption\fR \fIoption-declaration\fR\fB;\fR +.PP +The +.B option +statement is used to specify the value of an option supplied by the +server, or, in the case of predefined leases declared in +dhclient.conf, the value that the user wishes the client configuration +script to use if the predefined lease is used. +.PP + \fBscript "\fIscript-name\fB";\fR +.PP +The +.B script +statement is used to specify the pathname of the dhcp client +configuration script. This script is used by the dhcp client to set +each interface's initial configuration prior to requesting an address, +to test the address once it has been offered, and to set the +interface's final configuration once a lease has been acquired. If +no lease is acquired, the script is used to test predefined leases, if +any, and also called once if no valid lease can be identified. For +more information, see +.B dhclient-script(8). +.PP + \fBvendor option space "\fIname\fB";\fR +.PP +The +.B vendor option space +statement is used to specify which option space should be used for +decoding the vendor-encapsulate-options option if one is received. +The \fIdhcp-vendor-identifier\fR can be used to request a specific +class of vendor options from the server. See +.B dhcp-options(5) +for details. +.PP + \fBmedium "\fImedia setup\fB";\fR +.PP +The +.B medium +statement can be used on systems where network interfaces cannot +automatically determine the type of network to which they are +connected. The media setup string is a system-dependent parameter +which is passed to the dhcp client configuration script when +initializing the interface. On Unix and Unix-like systems, the +argument is passed on the ifconfig command line when configuring the +interface. +.PP +The dhcp client automatically declares this parameter if it uses a +media type (see the +.B media +statement) when configuring the interface in order to obtain a lease. +This statement should be used in predefined leases only if the network +interface requires media type configuration. +.PP + \fBrenew\fR \fIdate\fB;\fR +.PP + \fBrebind\fR \fIdate\fB;\fR +.PP + \fBexpire\fR \fIdate\fB;\fR +.PP +The \fBrenew\fR statement defines the time at which the dhcp client +should begin trying to contact its server to renew a lease that it is +using. The \fBrebind\fR statement defines the time at which the dhcp +client should begin to try to contact \fIany\fR dhcp server in order +to renew its lease. The \fBexpire\fR statement defines the time at +which the dhcp client must stop using a lease if it has not been able +to contact a server in order to renew it. +.PP +These declarations are automatically set in leases acquired by the +DHCP client, but must also be configured in predefined leases - a +predefined lease whose expiry time has passed will not be used by the +DHCP client. +.PP +Dates are specified in one of two ways. The software will output times in +these two formats depending on if the \fBdb-time-format\fR configuration +parameter has been set to \fIdefault\fR or \fIlocal\fR. +.PP +If it is set to \fIdefault\fR, then \fIdate\fR values appear as follows: +.PP + \fI \fB/\fI\fB/\fI +\fB:\fI\fB:\fI\fR +.PP +The weekday is present to make it easy for a human to tell when a +lease expires - it's specified as a number from zero to six, with zero +being Sunday. When declaring a predefined lease, it can always be +specified as zero. The year is specified with the century, so it +should generally be four digits except for really long leases. The +month is specified as a number starting with 1 for January. The day +of the month is likewise specified starting with 1. The hour is a +number between 0 and 23, the minute a number between 0 and 59, and the +second also a number between 0 and 59. +.PP +If the \fBdb-time-format\fR configuration was set to \fIlocal\fR, then +the \fIdate\fR values appear as follows: +.PP + \fBepoch\fR \fI\fR\fB; #\fR \fI + \fR\fB:\fR\fI\fR\fB:\fR\fI \fR +.PP +The \fIseconds-since-epoch\fR is as according to the system's local clock (often +referred to as "unix time"). The \fB#\fR symbol supplies a comment that +describes what actual time this is as according to the system's configured +timezone, at the time the value was written. It is provided only for human +inspection, the epoch time is the only recommended value for machine +inspection. +.PP +Note that when defining a static lease, one may use either time format one +wishes, and need not include the comment or values after it. +.PP +If the time is infinite in duration, then the \fIdate\fR is \fBnever\fR +instead of an actual date. +.SH ALIAS DECLARATIONS + \fBalias { \fI declarations ... \fB}\fR +.PP +Some DHCP clients running TCP/IP roaming protocols may require that in +addition to the lease they may acquire via DHCP, their interface also +be configured with a predefined IP alias so that they can have a +permanent IP address even while roaming. The Internet Systems +Consortium DHCP client doesn't support roaming with fixed addresses +directly, but in order to facilitate such experimentation, the dhcp +client can be set up to configure an IP alias using the +.B alias +declaration. +.PP +The alias declaration resembles a lease declaration, except that +options other than the subnet-mask option are ignored by the standard +client configuration script, and expiry times are ignored. A typical +alias declaration includes an interface declaration, a fixed-address +declaration for the IP alias address, and a subnet-mask option +declaration. A medium statement should never be included in an alias +declaration. +.SH OTHER DECLARATIONS + \fBdb-time-format\fR [ \fIdefault\fR | \fIlocal\fR ] \fB;\fR +.PP +The \fBdb-time-format\fR option determines which of two output methods are +used for printing times in leases files. The \fIdefault\fR format provides +day-and-time in UTC, whereas \fIlocal\fR uses a seconds-since-epoch to store +the time value, and helpfully places a local timezone time in a comment on +the same line. The formats are described in detail in this manpage, within +the LEASE DECLARATIONS section. +.PP +The +.I lease-id-format +parameter +.RS 0.25i +.PP +.B lease-id-format \fIformat\fB;\fR +.PP +The \fIformat\fR parameter must be either \fBoctal\fR or \fBhex\fR. +This parameter governs the format used to write certain values to lease +files. With the default format, octal, values are written as quoted strings in +which non-printable characters are represented as octal escapes - +a backslash character followed by three octal digits. When the hex format +is specified, values are written as an unquoted series of hexadecimal digit +pairs, separated by colons. + +Currently, the values written out based on lease-id-format are the default-duid +and the IAID value (DHCPv6 only). The client automatically reads the values +in either format. Note that when the format is octal, rather than as an octal +string, IAID is output as hex if it contains no printable characters or as a +string if contains only printable characters. This is done to maintain backward +compatibility. +.PP + \fBreject \fIcidr-ip-address\fR [\fB,\fR \fI...\fB \fIcidr-ip-address\fR ] \fB;\fR +.PP +The +.B reject +statement causes the DHCP client to reject offers from +servers whose server identifier matches any of the specified hosts or +subnets. This can be used to avoid being configured by rogue or +misconfigured dhcp servers, although it should be a last resort - +better to track down the bad DHCP server and fix it. +.PP +The \fIcidr-ip-address\fR configuration type is of the +form \fIip-address\fR[\fB/\fIprefixlen\fR], where \fIip-address\fR is a +dotted quad IP address, and \fRprefixlen\fR is the CIDR prefix length of +the subnet, counting the number of significant bits in the netmask starting +from the leftmost end. Example configuration syntax: +.PP +.I \fIreject\fR 192.168.0.0\fB/\fR16\fB,\fR 10.0.0.5\fB;\fR +.PP +The above example would cause offers from any server identifier in the +entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific +single address 10.0.0.5, to be rejected. +.PP + \fBinterface "\fIname\fB" { \fIdeclarations ... \fB } +.PP +A client with more than one network interface may require different +behaviour depending on which interface is being configured. All +timing parameters and declarations other than lease and alias +declarations can be enclosed in an interface declaration, and those +parameters will then be used only for the interface that matches the +specified name. Interfaces for which there is no interface +declaration will use the parameters declared outside of any interface +declaration, or the default settings. +.PP +.B Note well: +ISC dhclient only maintains one list of interfaces, which is either +determined at startup from command line arguments, or otherwise is +autodetected. If you supplied the list of interfaces on the command +line, this configuration clause will add the named interface to the +list in such a way that will cause it to be configured by DHCP. Which +may not be the result you had intended. This is an undesirable side +effect that will be addressed in a future release. +.PP + \fBpseudo "\fIname\fR" "\fIreal-name\fB" { \fIdeclarations ... \fB } +.PP +Under some circumstances it can be useful to declare a pseudo-interface +and have the DHCP client acquire a configuration for that interface. +Each interface that the DHCP client is supporting normally has a DHCP +client state machine running on it to acquire and maintain its lease. +A pseudo-interface is just another state machine running on the +interface named \fIreal-name\fR, with its own lease and its own +state. If you use this feature, you must provide a client identifier +for both the pseudo-interface and the actual interface, and the two +identifiers must be different. You must also provide a separate +client script for the pseudo-interface to do what you want with the IP +address. For example: +.PP +.nf + interface "ep0" { + send dhcp-client-identifier "my-client-ep0"; + } + pseudo "secondary" "ep0" { + send dhcp-client-identifier "my-client-ep0-secondary"; + script "/etc/dhclient-secondary"; + } +.fi +.PP +The client script for the pseudo-interface should not configure the +interface up or down - essentially, all it needs to handle are the +states where a lease has been acquired or renewed, and the states +where a lease has expired. See \fBdhclient-script(8)\fR for more +information. +.PP + \fBmedia "\fImedia setup\fB"\fI [ \fB, "\fImedia setup\fB", \fI... ]\fB;\fR +.PP +The +.B media +statement defines one or more media configuration parameters which may +be tried while attempting to acquire an IP address. The dhcp client +will cycle through each media setup string on the list, configuring +the interface using that setup and attempting to boot, and then trying +the next one. This can be used for network interfaces which aren't +capable of sensing the media type unaided - whichever media type +succeeds in getting a request to the server and hearing the reply is +probably right (no guarantees). +.PP +The media setup is only used for the initial phase of address +acquisition (the DHCPDISCOVER and DHCPOFFER packets). Once an +address has been acquired, the dhcp client will record it in its lease +database and will record the media type used to acquire the address. +Whenever the client tries to renew the lease, it will use that same +media type. The lease must expire before the client will go back to +cycling through media types. +.PP + \fBhardware\fR \fIlink-type mac-address\fR\fB;\fR +.PP +The +.B hardware +statement defines the hardware MAC address to use for this interface, +for DHCP servers or relays to direct their replies. dhclient will determine +the interface's MAC address automatically, so use of this parameter +is not recommended. The \fIlink-type\fR corresponds to the interface's +link layer type (example: \'ethernet\'), while the \fImac-address\fR is +a string of colon-separated hexadecimal values for octets. +.PP + \fBanycast-mac\fR \fIlink-type mac-address\fR\fB;\fR +.PP +The +.B anycast-mac +statement over-rides the all-ones broadcast MAC address dhclient will use +when it is transmitting packets to the all-ones limited broadcast IPv4 +address. This configuration parameter is useful to reduce the number of +broadcast packets transmitted by DHCP clients, but is only useful if you +know the DHCP service(s) anycast MAC address prior to configuring your +client. The \fIlink-type\fR and \fImac-address\fR parameters are configured +in a similar manner to the \fBhardware\fR statement. +.PP +.SH SAMPLE +The following configuration file was used on a laptop running NetBSD +1.3, though the domains have been modified. +The laptop has an IP alias of 192.5.5.213, and has one +interface, ep0 (a 3com 3C589C). Booting intervals have been +shortened somewhat from the default, because the client is known to +spend most of its time on networks with little DHCP activity. The +laptop does roam to multiple networks. + +.nf + +timeout 60; +retry 60; +reboot 10; +select-timeout 5; +initial-interval 2; +reject 192.33.137.209; + +interface "ep0" { + send host-name "andare.example.com"; + hardware ethernet 00:a0:24:ab:fb:9c; + send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; + send dhcp-lease-time 3600; + supersede domain-search "example.com", "rc.isc.org", "home.isc.org"; + prepend domain-name-servers 127.0.0.1; + request subnet-mask, broadcast-address, time-offset, routers, + domain-name, domain-name-servers, host-name; + require subnet-mask, domain-name-servers; + script "CLIENTBINDIR/dhclient-script"; + media "media 10baseT/UTP", "media 10base2/BNC"; +} + +alias { + interface "ep0"; + fixed-address 192.5.5.213; + option subnet-mask 255.255.255.255; +} +.fi +This is a very complicated dhclient.conf file - in general, yours +should be much simpler. In many cases, it's sufficient to just +create an empty dhclient.conf file - the defaults are usually fine. +.SH SEE ALSO +dhcp-options(5), dhcp-eval(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5), +RFC2132, RFC2131. +.SH AUTHOR +.B dhclient(8) +Information about Internet Systems Consortium can be found at +.B https://www.isc.org. diff --git a/static/netbsd/man5/dhclient.leases.5 b/static/netbsd/man5/dhclient.leases.5 new file mode 100644 index 00000000..dd38bc43 --- /dev/null +++ b/static/netbsd/man5/dhclient.leases.5 @@ -0,0 +1,52 @@ +.\" $NetBSD: dhclient.leases.5,v 1.3 2022/04/03 01:10:57 christos Exp $ +.\" +.\" Id: dhclient.leases.5,v 1.8 2011/02/23 23:50:55 sar Exp +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1997-2003 by Internet Software Consortium +.\" +.\" This Source Code Form is subject to the terms of the Mozilla Public +.\" License, v. 2.0. If a copy of the MPL was not distributed with this +.\" file, You can obtain one at http://mozilla.org/MPL/2.0/. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" Support and other services are available for ISC products - see +.\" https://www.isc.org for more information or to learn more about ISC. +.\" +.\" Id: dhclient.leases.5,v 1.8 2011/02/23 23:50:55 sar Exp +.\" +.TH dhclient.leases 5 +.SH NAME +dhclient.leases - DHCP client lease database +.SH DESCRIPTION +The Internet Systems Consortium DHCP client keeps a persistent +database of leases that it has acquired that are still valid. The +database is a free-form ASCII file containing one valid declaration +per lease. If more than one declaration appears for a given lease, +the last one in the file is used. The file is written as a log, so +this is not an unusual occurrence. +.PP +The format of the lease declarations is described in +.B dhclient.conf(5). +.SH FILES +.B DBDIR/dhclient.leases +.SH SEE ALSO +dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), +dhcpd.conf(5), RFC2132, RFC2131. +.SH AUTHOR +.B dhclient(8) +Information about Internet Systems Consortium can be found at +.B https://www.isc.org. diff --git a/static/netbsd/man5/dhcp-eval.5 b/static/netbsd/man5/dhcp-eval.5 new file mode 100644 index 00000000..d2e88662 --- /dev/null +++ b/static/netbsd/man5/dhcp-eval.5 @@ -0,0 +1,484 @@ +.\" $NetBSD: dhcp-eval.5,v 1.3 2022/04/03 01:10:58 christos Exp $ +.\" +.\" Id: dhcp-eval.5,v 1.5 2009/11/24 02:06:56 sar Exp +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhcp-eval.5,v 1.2 2002/05/23 04:17:13 horikawa Exp $ +.TH dhcp-eval 5 +.SH ̾�� +dhcp-eval - ISC DHCP �ˤ��������դ�ɾ�� +.SH ���� +Internet Systems Consortium �� DHCP ���饤����Ȥȥ����Фϡ��ɤ���� +��������ѥ��åȤ˰�¸��������դ�ư���Ԥ�ǽ�Ϥ�����ޤ��� +����դ�ư���ʸˡ�򤳤��˼����ޤ��� +.SH ����: ����դ�ư�� +����դ�ư��ϡ�if, else, elsif ʸ����Ѥ��ƻ��ꤷ�ޤ��� +���ʸ�ϡ��̾�ʸ (option ʸ) ���о��ǽ�ʾ��Ϥɤ��ˤǤ��о��ǽ�Ǥ��ꡢ +�ޤ����Τ褦��ʸ���뤳�Ȥ��ǽ�Ǥ��� +�����Фˤ�������ʸ�ϼ��Τ褦�ˤʤ뤳�Ȥ�¿���Ǥ��礦: +.PP +.nf +if option dhcp-user-class = "accounting" { + max-lease-time 17600; + option domain-name "accounting.example.org"; + option domain-name-servers ns1.accounting.example.org, + ns2.accounting.example.org; +} elsif option dhcp-user-class = "sales" { + max-lease-time 17600; + option domain-name "sales.example.org"; + option domain-name-servers ns1.sales.example.org, + ns2.sales.example.org; +} elsif option dhcp-user-class = "engineering" { + max-lease-time 17600; + option domain-name "engineering.example.org"; + option domain-name-servers ns1.engineering.example.org, + ns2.engineering.example.org; +} else { + max-lease-time 600; + option domain-name "misc.example.org"; + option domain-name-servers ns1.misc.example.org, + ns2.misc.example.org; +} +.fi +.PP +���饤�����¦�Ǥϡ�����դ�ɾ������ϼ��Τ褦�ˤʤ�Ǥ��礦: +.PP +.nf +# example.org �ϥե����䥦������� DNS ��ե��륿����Τǡ� +# example.org �ͥåȥ���˷Ҥ���Ȥ��Τߡ����� DNS �����Ф���Ѥ��ޤ��� +# example.org �˷Ҥ���ΤǤϤʤ���硢���ʤ� DNS �����Ф�ͥ����Ѥ��ޤ��� +if not option domain-name = "example.org" { + prepend domain-name-servers 127.0.0.1; +} +.fi +.PP +.B if +ʸ�� +.B elsif +��³ʸ�ϡ������Ȥ��ƥ֡��뼰����ޤ��� +�Ĥޤꡢ������ʸ�ϡ�ɾ�������ȥ֡����ͤη�̤��������뼰����ޤ��� +����ɾ����̤����ˤʤ�ȡ� +.B if +ʸ��ľ��Υ֥졼���dz��줿ʸ���¹Ԥ��졢��³���� +.B elsif +�� +.B else +����ϥ����åפ���ޤ��� +�����Ǥʤ���硢ɾ����̤����ˤʤ� elsif ��˽в񤦤ޤǡ���³����� +.B elsif +��μ��������å�����ޤ��� +���Τ褦���᤬���դ���ȡ�ľ��Υ֥졼�����ʸ���¹Ԥ��졢��³���� +.B elsif +�� +.B else +����ϥ����åפ���ޤ��� +���٤Ƥ� +.B if +����� +.B elsif +���᤬�����å����줿��ΤΤɤμ��⿿�ˤʤ�ʤ����ǡ� +.B else +�᤬¸�ߤ����硢 +.B else +��ľ��Υ֥졼�����ʸ��ɾ������ޤ��� +���ˤ����Ƥϡ�ɾ����̤����ˤʤ�֡��뼰�ϵ��Ȥ��ư����ޤ��� +.SH �֡��뼰 +�ʲ��ϡ�DHCP ����ʪ�Ǹ��ߥ��ݡ��Ȥ���Ƥ���֡��뼰�ΰ����Ǥ��� +.PP +.I data-expression-1 \fB=\fI data-expression-2\fR +.RS 0.25i +.PP +\fB=\fR ���ڥ졼���ϡ�2 �ĤΥǡ���������Ӥ���ξ�Ԥ�Ʊ�����Ͽ����֤��� +Ʊ��Ǥʤ����ϵ����֤��ޤ��� +���դ⤷���ϱ��դΤ����줫�����ξ�硢��̤϶��ˤʤ�ޤ��� +.RE +.PP +.I boolean-expression-1 \fBand\fI boolean-expression-2\fR +.PP +.RS 0.25i +\fBand\fR ���ڥ졼���ϡ����դΥ֡��뼰�ȱ��դΥ֡��뼰��ξ����ɾ����̤� +���ξ�硢����ɾ������ޤ��� +�����Ǥʤ���硢����ɾ������ޤ��� +���դ⤷���ϱ��դΤ����줫�����ξ�硢��̤϶��ˤʤ�ޤ��� +.RE +.PP +.I boolean-expression-1 \fBor\fI boolean-expression-2\fR +.PP +.RS 0.25i +\fBor\fR ���ڥ졼���ϡ����դΥ֡��뼰�ȱ��դΥ֡��뼰�Τ����줫��ɾ����̤� +���ξ�硢����ɾ������ޤ��� +�����Ǥʤ���硢����ɾ������ޤ��� +���դ⤷���ϱ��դΤ����줫�����ξ�硢��̤϶��ˤʤ�ޤ��� +.RE +.PP +.B not \fIboolean-expression +.PP +.RS 0.25i +\fBnot\fR ���ڥ졼���ϡ�\fIboolean-expression\fR ��ɾ����̤����ξ�硢 +����ɾ������ޤ��� +�ޤ���\fIboolean-expression\fR ��ɾ����̤����ξ�硢����ɾ������ޤ��� +\fIboolean-expression\fR ��ɾ����̤����ξ�硢��̤�ޤ����ˤʤ�ޤ��� +.RE +.PP +.B exists \fIoption-name\fR +.PP +.RS 0.25i +\fBexists\fR ���ϡ������оݤ����� DCHP �ѥ��å���ˡ� +���ꤵ�줿���ץ����¸�ߤ����硢�����֤��ޤ��� +.RE +.B known +.PP +.RS 0.25i +\fBknown\fR ���ϡ��׵��б���Υ��饤����Ȥ����Τξ�硢 +���ʤ���ۥ�������������硢�����֤��ޤ��� +.RE +.B static +.PP +.RS 0.25i +\fBstatic\fR ���ϡ��׵��б���Υ��饤����ȤؤΥ꡼��������Ƥ��� +��Ū���ɥ쥹������Ƥˤ���ΤǤ��ä���硢�����֤��ޤ��� +.RE +.SH �ǡ����� +���ҤΥ֡��뼰�ϡ��ǡ�������ɾ����̤˰�¸���ޤ��� +�ǡ������򤳤��˼����ޤ��� +.PP +.B substring (\fIdata-expr\fB, \fIoffset\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBsubstring\fR ���ڥ졼���ϡ��ǡ�������ɾ������ +ɾ�������� \fIoffset\fR �Х��Ȥ��鳫�Ϥ��� \fIlength\fR �Х��ȷ�³���� +���֥��ȥ�󥰤��֤��ޤ��� +\fIoffset\fR �� \fIlength\fR �϶��˿��ͼ��Ǥ��� +\fIdata-expr\fR, \fIoffset\fR, \fIlength\fR �Τ����줫������ɾ��������硢 +��̤�ޤ����ˤʤ�ޤ��� +\fIoffset\fR ����ɾ�����줿�ǡ�����Ĺ���ʾ�Ǥ����硢 +Ĺ�� 0 �Υǡ���ʸ�����֤���ޤ��� +\fIlength\fI ����ɾ�����줿�ǡ����� \fIoffset\fR �����Ĺ������礭����硢 +ɾ�����줿�ǡ����� \fIoffset\fR ���齪ü�ޤǤ����ǡ�����ޤ� +�ǡ���ʸ�����֤���ޤ��� +.RE +.PP +.B suffix (\fIdata-expr\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBsuffix\fR ���ڥ졼���ϡ�\fIdata-expr\fR ��ɾ������ +ɾ����̤κǸ�� \fIlength\fR �Х��Ȥ��֤��ޤ��� +\fIlength\fR �Ͽ��ͼ��Ǥ��� +\fIdata-expr\fR �ޤ��� \fIlength\fR ��ɾ����̤����ξ�硢 +��̤�ޤ����ˤʤ�ޤ��� +\fIsuffix\fR +(����: \fIlength\fR ���������Ȼפ��ޤ�) +��ɾ����̤�ɾ�����줿�ǡ�����Ĺ������礭����硢 +ɾ�����줿�ǡ������֤���ޤ��� +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.RE +.PP +.B option \fIoption-name\fR +.PP +.RS 0.25i +\fBoption\fR ���ڥ졼���ϡ������Ф�����������Υѥ��åȤ���Ρ� +���ꤷ�����ץ��������Ƥ��֤��ޤ��� +.RE +.PP +.B config-option \fIoption-name\fR +.PP +.RS 0.25i +\fBconfig-option\fR ���ڥ졼���ϡ����ꤷ�����ץ������Ф��� +DHCP ���饤����Ȥޤ��ϥ����Ф����Ф���褦���ꤵ�줿�ͤ��֤��ޤ��� +.RE +.PP +.B hardware +.PP +.RS 0.25i +\fBhardware\fR ���ڥ졼���ϡ��ǡ������ȥ�󥰤��֤��ޤ��� +�ǡ������ȥ�󥰤κǽ�����Ǥϡ� +�оݥѥ��åȤ������ͥåȥ�����󥿥ե������Υ����פǤ��ꡢ +��³�������Ǥϡ����饤����ȤΥ���إ��ɥ쥹�Ǥ��� +�ѥ��åȤ�¸�ߤ��ʤ����⤷���� RFC2131 \fIhlen\fR �ե�����ɤ�̵���ʾ�硢 +��̤϶��ˤʤ�ޤ��� +�ϡ��ɥ����������פˤϡ��������ͥå� (1)���ȡ������� (6)�� +FDDI (8) ���ޤޤ�ޤ��� +�ϡ��ɥ����������פ� IETF �ˤ�äƵ��ꤵ�졢 +�ɤΤ褦�˥����פο��ͤ��������뤫�ξܺ٤� RFC2131 +(ISC DHCP ����ʪ�Ǥϡ�doc/ ���֥ǥ��쥯�ȥ�ˤ���ޤ�) �򻲾Ȥ��Ƥ��������� +.RE +.PP +.B packet (\fIoffset\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBpacket\fR ���ڥ졼���ϡ��оݥѥ��åȤλ�����ʬ���֤����� +�оݥѥ��åȤ�̵��ʸ̮�Ǥ϶����֤��ޤ��� +\fIoffset\fR �� \fIlength\fR �ϡ� +\fBsubstring\fR ���ڥ졼����Ʊ�ͤˡ��ѥ��åȤ����Ƥ�Ŭ�Ѥ���ޤ��� +.RE +.PP +.I string +.PP +.RS 0.25i +�������Ȥdz��줿���ȥ�󥰤ϥǡ������Ȥ��ƻ����ǽ�Ǥ��ꡢ +�������Ȥδ֤� ASCII ���󥳡��ɤ����Υƥ����Ȥ��֤��ޤ��� +�Хå�����å��� ('\\') ʸ���� C �ץ������Τ褦�����̰�������ޤ�: +���ʤ�� '\\t' �ϥ��֤�'\\r' ��������'\\n' �ϲ��Ԥ�'\\b' �ϥ٥�� +��̣���ޤ��� +8 �ʿ��ͤ� '\\nnn' �ǻ����ǽ�Ǥ��ꡢnnn �� 0 �ʾ� 0377 �ʲ��� 8 �ʿ��ͤǤ��� +16 �ʿ��ͤ� '\\xnn' �ǻ����ǽ�Ǥ��ꡢnn �� 0 �ʾ� 0xff �ʲ��� 16 �ʿ��ͤǤ��� +.\" �ͤ��ϰϤθ���ˤĤ��Ƥϡ�Murray ��ͳ�ǥ�ݡ��Ⱥ� +.\" horikawa@jp.FreeBSD.org 2002/05/01 +.RE +.PP +.I colon-separated hexadecimal list +.PP +.RS 0.25i +������Ƕ��ڤ�줿 16 �ʿ��Υ����ƥå��ͤΥꥹ�Ȥ� +�ǡ������Ȥ��ƻ����ǽ�Ǥ��� +.RE +.PP +.B concat (\fIdata-expr1\fB, ..., \fIdata-exprN\fB)\fR +.RS 0.25i +����ɾ�����졢��ɾ����̤����ּ��ν��֤�Ϣ�뤵��ޤ��� +���ּ��Τ����줫��ɾ����̤����ˤʤ��硢Ϣ��η�̤϶��ˤʤ�ޤ��� +.RE +.PP +.B reverse (\fInumeric-expr1\fB, \fIdata-expr2\fB)\fR +.RS 0.25i +2 �Ĥμ���ɾ�����졢�ǡ�������ɾ����̤����ξ��ȿž����ޤ��� +ȿž�ϡ����ͼ��ǻ��ꤵ����礭����ñ�̤ǹԤ��ޤ��� +�㤨�С����ͼ���ɾ����̤� 4 �ξ��ǡ� +�ǡ�������ɾ����̤� 12 �Х��Ȥˤʤ��硢 +reverse ����ɾ����̤ϡ����Τ褦�� 12 �Х��ȤΥǡ����ˤʤ�ޤ��� +���ʤ�������ϤκǸ�� 4 �Х��ȡ������ 4�Х��ȡ��ǽ�� 4 �Х��Ȥ� +��ˤʤ�ޤ��� +.RE +.PP +.B leased-address +.RS 0.25i +�����ʤ�ʸ̮�ˤ����Ƥ⡢ +�׵�����оݤȤʤäƤ��륯�饤����Ȥ� IP ���ɥ쥹��������ƺѤξ�硢 +���� IP ���ɥ쥹���֤���ޤ��� +.RE +.PP +.B binary-to-ascii (\fInumeric-expr1\fB, \fInumeric-expr2\fB, +.B \fIdata-expr1\fB,\fR \fIdata-expr2\fB)\fR +.RS 0.25i +data-expr2 ��ɾ����̤�ƥ����ȥ��ȥ�󥰤��Ѵ����ޤ��� +���Υƥ����ȥ��ȥ����Ǥϡ� +data-expr2 ��ɾ����̤γ����Ǥ���1 �Ĥο��ͤˤʤ�ޤ��� +�ƿ��ͤϡ����줾�졢data-expr1 ��ɾ����̤ˤ�äƶ��ڤ��ޤ��� +numeric-expr1 ��ɾ����̤ϡ���� (2 ���� 16) �Ǥ��ꡢ +���δ���˿��ͤ��Ѵ�����ޤ��� +numeric-expr2 ��ɾ����̤ϡ��ƿ��ͤΥӥå����Ǥ��ꡢ +8, 16, 32 �Τ����줫�Ǥ��� +.PP +�ǽ�� 3 �ĤΥ����פμ�����Ȥ��ơ� +���饤����Ȥ˳�����Ƥ�줿 IP ���ɥ쥹�Ѥ� +PTR �쥳���ɤ�̾�����������뤿��˻��Ѳ�ǽ�ʼ��򼨤��ޤ� +.RE +.PP +.nf + concat (binary-to-ascii (10, 8, ".", + reverse (1, leased-address)), + ".in-addr.arpa."); + +.fi +.PP +.B encode-int (\fInumeric-expr\fB, \fIwidth\fB)\fR +.RS 0.25i +���ͼ���ɾ�����졢���ꤵ�줿���Υǡ������ȥ�󥰤� +�ͥåȥ���Х��Ƚ� (�Ǿ�̥Х��Ȥ��ǽ�) �ǥ��󥳡��ɤ���ޤ��� +���ͼ���ɾ����̤������ͤˤʤ��硢��̤�ޤ����Ǥ��� +.RE +.\" ���� ".RE" ��̵���ȡ�����ǥ�Ȥ��������ʤ��Ǥ� +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.PP +.B pick-first-value (\fIdata-expr1\fR [ ... \fIexpr\fRn ] \fB)\fR +.RS 0.25i +pick-first-value �ؿ��ϡ�Ǥ�ոĤΥǡ������������ޤ��� +�ꥹ�Ȥ���Ƭ����Ƽ���ɾ�����졢 +ɾ����̤����ǤϤʤ��������դ���ޤǤ��줬³���ޤ��� +���μ����֤��졢���μ��˸�³���뼰��ɾ������ޤ��� +���٤Ƥμ���ɾ����̤����ξ�硢�����ͤ��֤���ޤ��� +.RE +.PP +.B host-decl-name +.RS 0.25i +host-decl-name �ؿ��ϡ������׵�����оݤȤʤäƤ��륯�饤����Ȥ˥ޥå����롢 +�ۥ��������̾�����֤��ޤ��� +�ɤΥۥ��������ޥå����ʤ���硢��̤϶��ˤʤ�ޤ��� +.RE +.SH ���ͼ� +���ͼ��ϡ�ɾ����̤������ˤʤ뼰�Ǥ��� +���̤ˡ������κ��祵������ 32 �ӥå�̤���Ǥ���Ȳ��ꤹ�٤��ǤϤ���ޤ��󤬡� +���������٤� 32 �ӥåȤ�ۤ��뤳�ȤϤ������ޤ��� +.PP +.B extract-int (\fIdata-expr\fB, \fIwidth\fB)\fR +.PP +.RS 0.25i +\fBextract-int\fR ���ڥ졼���ϡ��ͥåȥ���Х��Ƚ�������� +���ꤷ���ǡ�������ɾ����̤�����Ф��ޤ��� +���ϡ����Ф������Υӥå����Ǥ��� +���ߡ����ݡ��Ȥ���Ƥ������� 8, 16, 32 �Τ����줫�Ǥ��� +�ǡ�������ɾ����̤������ꤷ���礭���������ȼ��Ф��Τ� +��ʬ�ʥӥåȤ��󶡤��ʤ���硢�����ͤ��֤���ޤ��� +.RE +.PP +.B lease-time +.PP +.RS 0.25i +���ߤΥ꡼���δ��֤Ǥ��� +���ʤ�������ߤλ���ȥ꡼���δ��¤��ڤ�����Ȥκ��Ǥ��� +.RE +.PP +.I number +.PP +.RS 0.25i +0 ����ɽ����ǽ�ʺ��祵�������ϰϤ�Ǥ�դο��ͤ򡢿��ͼ��Ȥ��ƻ����ǽ�Ǥ��� +.RE +.PP +.B client-state +.PP +.RS 0.25i +�����оݤΥ��饤����Ȥθ��ߤξ��֤Ǥ��� +DHCP ���饤���������ե�����ˤ����ƤΤ�ͭ�ѤǤ��� +��������ͤϼ����̤�Ǥ�: +.TP 2 +.I \(bu +Booting - DHCP ���饤����Ȥ� INIT ���֤Ǥ��ꡢ +IP ���ɥ쥹��ޤ������ޤ��� +��������������å������� DHCPDISCOVER �Ǥ��ꡢ +����ϥ֥����ɥ��㥹�Ȥ���ޤ��� +.TP +.I \(bu +Reboot - DHCP ���饤����Ȥ� INIT-REBOOT ���֤Ǥ��� +IP ���ɥ쥹������ޤ����ޤ����Ѥ��Ƥ��ޤ��� +��������������å������� DHCPREQUEST �Ǥ��ꡢ +����ϥ֥����ɥ��㥹�Ȥ���ޤ��� +����������ʹ�����ʤ��ȡ����饤����ȤϤ��Υ��ɥ쥹�˥Х���ɤ��� +BOUND ���֤����ܤ��ޤ��� +.TP +.I \(bu +Select - DHCP ���饤����Ȥ� SELECTING ���֤Ǥ��� +���ʤ��Ȥ� 1 �Ĥ� DHCPOFFER ��å������ϼ������ޤ������� +¾�� DHCPOFFER ��å�������¾�Υ����Ф��������뤫�ɤ����ԤäƤ��ޤ��� +SELECTING ���֤Ǥϥ�å���������������ޤ��� +.TP +.I \(bu +Request - DHCP ���饤����Ȥ� REQUESTING ���֤Ǥ��� +���ʤ��Ȥ� 1 �Ĥ� DHCPOFFER ��å�������������� +���Τ����Τɤ���׵᤹�뤫���򤷤ޤ����� +��������������å������� DHCPREQUEST ��å������Ǥ��ꡢ +����ϥ֥����ɥ��㥹�Ȥ���ޤ��� +.TP +.I \(bu +Bound - DHCP ���饤����Ȥ� BOUND ���֤Ǥ��� +IP ���ɥ쥹���ͭ���Ƥ��ޤ��� +���ξ��֤Ǥϥ�å���������������ޤ��� +.TP +.I \(bu +Renew - DHCP ���饤����Ȥ� RENEWING ���֤Ǥ��� +IP ���ɥ쥹���ͭ���Ƥ��ꡢ����򹹿����뤿��˥����Ф���³���ߤƤ��ޤ��� +��������������å������� DHCPREQUEST ��å������Ǥ��ꡢ +����ϥ����Ф�ľ�ܥ�˥��㥹�Ȥ���ޤ��� +.TP +.I \(bu +Rebind - DHCP ���饤����Ȥ� REBINDING ���֤Ǥ��� +IP ���ɥ쥹���ͭ���Ƥ��ꡢ +����򹹿����뤿���Ǥ�դΥ����Ф���³���ߤƤ��ޤ��� +��������������å������� DHCPREQUEST ��å������Ǥ��ꡢ +����ϥ֥����ɥ��㥹�Ȥ���ޤ��� +.RE +.SH ����: ���� +����ʸ����Ѥ��ơ�ɸ���������ͥ�˾����������ǽ�Ǥ��� +����ʸ�ϡ���ά��ǽ�� priority +(\fBfatal\fR, \fBerror\fR, \fBinfo\fR, \fBdebug\fR �Τ����줫) �ȡ� +�ǡ���������ޤ��� +.PP +.B log (\fIpriority\fB, \fIdata-expr\fB)\fR +.\" "\FB" �� "\fB" �������� +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.PP +����ʸ�ϡ�ñ��Υǡ����������Τ߼��ޤ��� +ʣ���Υǡ����ͤ���Ϥ�������硢 +\fBconcat\fR ���ڥ졼������Ѥ��Ƥ�����Ϣ�뤹��ɬ�פ�����ޤ��� +.RE +.SH ����: ưŪ�� DNS ���� +.PP +DHCP ���饤����Ȥȥ����Фϡ� +ưŪ�˥ɥᥤ��͡��ॷ���ƥ�򹹿�����ǽ�Ϥ�����ޤ��� +����ե�������ˡ��ɤΤ褦�˥ɥᥤ��͡��ॷ���ƥ�򹹿������ߤ������� +�����ǽ�Ǥ��� +������ RFC 2136 �˽��äƤ��뤿�ᡢ +RFC 2136 �򥵥ݡ��Ȥ��� DNS �����Фϡ� +DHCP �����Ф���ι���������դ���ǽ�Ȼפ��ޤ��� +.SH �������ƥ� +TSIG ����� DNSSEC �Ϥޤ����ݡ��Ȥ���Ƥ��ޤ��� +DHCP �����Фޤ��ϥ��饤����Ȥ���ι���������դ���褦�� +DNS �����Ф����ꤹ���硢���¤�̵���������Ф��� +DNS �����Ф򻯤����Ȥˤʤ뤫�⤷��ޤ��� +������򤱤뤿��˺������Ǥ�����ɤ���ˡ�ϡ� +IP ���ɥ쥹�١����Υѥ��åȥե��륿����Ѥ��ơ� +���¤�̵���ۥ��Ȥ���ι����׵�ȯ�Ԥ��޻ߤ��뤳�ȤǤ��� +���餫�ˡ������Ǥϥ��饤����Ȥι������Ф��륻�����ƥ����󶡤�����ˡ�� +����ޤ��� +���Τ���ˤ� TSIG �� DNSSEC ��ɬ�פǤ����� +���� DHCP ����ʪ�ˤϤޤ��ޤޤ�Ƥ��ޤ��� +.PP +ưŪ DNS (DDNS) �����ϡ�\fBdns-update\fR ������Ѥ��뤳�ȤǼ¹Ԥ���ޤ��� +\fBdns-update\fR ���ϡ��֡��뼰�Ǥ��ꡢ4 �ĤΥѥ�᡼������ޤ��� +��������������ȡ���̤Ͽ��ˤʤ�ޤ��� +���Ԥ���ȡ���̤ϵ��ˤʤ�ޤ��� +4 �ĤΥѥ�᡼���ϡ��꥽�����쥳���ɥ����� (RR)�� +RR �κ��ա�RR �α��ա��쥳���ɤ�Ŭ�Ѥ����٤� ttl �Ǥ��� +���δؿ��κǤ��ñ�ʻ�����ϡ�dhcpd.conf �ե�����λ�����ˤ��ꡢ +�ʤˤ������뤫���Ҥ���Ƥ��ޤ��� +������Ǥϡ�ʣ���μ������Ѥ���ơ� +\fBdns-update\fR �Ѥΰ�������������Ƥ��ޤ��� +.PP +�����Ǥϡ��ǽ�� \fBdns-update\fR ���ؤ� 1 ���ܤΰ����ϡ� +A RR �����פ�ɾ�������ǡ������Ǥ��� +2 ���ܤΰ����ϡ�DHCP host-name ���ץ����� +��������ɥᥤ�󡢤��ξ�� "ssd.example.net"�� +��ޤ�ƥ����ȥ��ȥ�󥰤�Ϣ�뤹�뤳�Ȥǡ����ۤ���ޤ��� +3 ���ܤΰ����ϡ����饤����Ȥ˳�����Ƥ�줿���ɥ쥹�� +32 �ӥåȤο��ͤ���ƥХ��Ȥ� "." �Ƕ��ڤä� ASCII ʸ������Ѵ����뤳�Ȥǡ� +���ۤ���ޤ��� +4 ���ܤΰ��� TTL �ϡ��꡼���λĤ���֤Ǥ� +(���������������������ޤ��� +�ʤ��ʤ� DNS �����Фϡ��׵���Ф��Ƥ��Ĥ⤳�� TTL �ͤ���Ϥ��Ƥ��ޤ�����Ǥ��� +����ϡ��꡼�������ڤ�ο������Ǥ��äƤ�Ǥ�)�� +.PP +�ǽ�� \fBdns-update\fR ʸ����������ȡ� +����³���� 2 ���ܤι����ˤ�� PTR RR �����󥹥ȡ��뤵��ޤ��� +PTR �쥳���ɤΥ��󥹥ȡ���ϡ�A RR �Υ��󥹥ȡ����Ʊ�ͤǤ����� +�쥳���ɤκ��դϥ꡼�����줿���ɥ쥹��դˤ��� ".in-addr.arpa" �� +��礵�줿��ΤǤ��� +���դϡ����ɥ쥹�Υ꡼�����襯�饤����ȤΡ������ʷ��ǤΥɥᥤ��̾�Ǥ��� +.SH ��Ϣ���� +dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8), +dhclient(8), RFC2132, RFC2131 +.SH ��� +Internet Systems Consortium DHCP Distribution +�ϡ�Vixie Labs �Ȥη���Τ�Ȥǡ�Ted Lemon �����Ҥ��ޤ����� +�ܥץ��������Ȥλ��ϡ�Internet Systems Consortium ���󶡤��ޤ����� +Internet Systems Consortium �˴ؤ������ϡ� +.B https://www.isc.org +�ˤ���ޤ��� diff --git a/static/netbsd/man5/dhcp-options.5 b/static/netbsd/man5/dhcp-options.5 new file mode 100644 index 00000000..6e501193 --- /dev/null +++ b/static/netbsd/man5/dhcp-options.5 @@ -0,0 +1,1576 @@ +.\" $NetBSD: dhcp-options.5,v 1.3 2022/04/03 01:10:58 christos Exp $ +.\" +.\" Id: dhcp-options.5,v 1.5 2010/07/20 21:09:14 dhankins Exp +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" %FreeBSD: src/contrib/isc-dhcp/common/dhcp-options.5,v 1.2.2.1 2002/04/11 10:16:46 murray Exp % +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhcp-options.5,v 1.11 2002/05/21 03:51:52 horikawa Exp $ +.\" WORD: Dynamic Host Configuration Protocol ưŪ�ۥ��ȹ����ץ��ȥ��� +.\" WORD: Path MTU Discovery �ѥ� MTU õ�� +.\" WORD: Router Discovery �롼��õ�� +.\" WORD: Router Solicitation �롼������ +.\" WORD: Mask Discovery �ޥ���õ�� +.\" +.TH dhcp-options 5 +.SH ̾�� +dhcp-options - ưŪ�ۥ��ȹ����ץ��ȥ���Υ��ץ���� +.SH ���� +ưŪ�ۥ��ȹ����ץ��ȥ��� (DHCP: Dynamic Host Configuration Protocol) �� +���Ѥ��뤳�Ȥˤ�ꡢ���饤����Ȥ� DHCP �����Ф��顢�ͥåȥ������� +�ͥåȥ��������Ѳ�ǽ���͡��ʥ����ӥ��ˤĤ��Ƶ��Ҥ��Ƥ��� +.B ���ץ���� +�������뤳�Ȥ��Ǥ��ޤ��� +.B dhcpd(8) +�� +.B dhclient(8) +�����ꤹ��Ȥ��ˡ����Ф��Х��ץ������������ɬ�פ�����Ǥ��礦�� +�����Ǥϡ����ץ������������ʸˡ�� +�����������ǽ�ʥ��ץ�����̾���Ƚ񼰤�ʸ�񲽤��Ƥ��ޤ��� +.SH ��ե����: ���ץ����ʸ +.PP +DHCP \fIoption\fR ʸ�ϡ���˥������ \fIoption\fR �dz��Ϥ��� +ñ��Υ��ץ����̾��³�������ץ����ǡ�����³���ޤ��� +���ץ�����̾���ȥǡ����ν񼰤ϸ�Ҥ��ޤ��� +���٤Ƥ� DHCP ���ץ���������Ū�˻��ꤹ��ɬ�פϤʤ��� +���饤����Ȥ�ɬ�פʥ��ץ����Τߤ���ꤷ�ޤ��� +.PP +���ץ����ǡ����ˤϡ����Τ褦���͡��ʽ񼰤�����ޤ�: +.PP +.B ip-address +�ǡ��������פϡ�����Ū�� IP ���ɥ쥹 (�㤨�� 239.254.197.10) �ޤ��� +�ɥᥤ��̾ (�㤨�� haagen.isc.org) �Τɤ���Ǥ�����ǽ�Ǥ��� +�ɥᥤ��̾�ǻ��ꤹ���硢 +���Υɥᥤ��̾���褹���ñ��� IP ���ɥ쥹�ˤʤ�褦�ˤ��Ƥ��������� +.PP +.B int32 +�ǡ��������פ�����դ� 32 �ӥå���������ꤷ�ޤ��� +.B uint32 +�ǡ��������פ����̵�� 32 �ӥå���������ꤷ�ޤ��� +.B int16 +����� +.B uint16 +�Υǡ��������פϡ�����դ���������̵���� 16 �ӥå���������ꤷ�ޤ��� +.B int8 +����� +.B uint8 +�Υǡ��������פϡ�����դ���������̵���� 8 �ӥå���������ꤷ�ޤ��� +���̵�� 8 �ӥå������ϡ������ƥåȤȸƤФ�뤳�Ȥ⤢��ޤ��� +.PP +.B text +�ǡ��������פ� NVT ASCII ʸ�������ꤷ�ޤ��� +ʸ����ϥ��֥륯�����Ȥdz��ɬ�פ�����ޤ��� +�㤨�� root-path ���ץ�������ꤹ��ʸˡ�ϡ����Τ褦�ˤʤ�ޤ��� +.nf +.sp 1 +option root-path "10.0.1.4:/var/tmp/rootfs"; +.fi +.PP +.B domain-name +�ǡ��������פϥɥᥤ��̾����ꤷ�ޤ��� +ʸ�������֥륯�����Ȥdz�äƤ����ޤ��� +���Υǡ��������פϡ�¾�δ�¸�� DHCP ���ץ����ˤϻȤ��ޤ��� +�ɥᥤ��̾�ϡ�text ���ץ����Ǥ��뤫�Τ褦���ݻ�����ޤ��� +.\" text �ǡ��������פǤ��뤫�Τ褦��? +.\" metal +.PP +.B flag +�ǡ��������פϥ֡����ͤ���ꤷ�ޤ��� +�֡����ͤ� true �ޤ��� false �Τ����줫�Ǥ� +(�⤷���ϡ�on �ޤ��� off ������ʬ����䤹����С�������Ǥ⤫�ޤ��ޤ���)�� +.PP +.B string +�ǡ��������פϡ����֥륯�����Ȥdz���� NVT ASCII ʸ���󤫡� +��������ڤ�� 16 �ʿ��ǻ��ꤵ��륪���ƥåȤ�Ϣ³�Τ����줫����ꤷ�ޤ��� +�㤨�м��Τ褦�ˤʤ�ޤ�: +.nf +.sp 1 + option dhcp-client-identifier "CLIENT-FOO"; +�⤷���� + option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; +.fi +.SH �����Ѥ������ץ�����ͤ����� +.\" metal +���饤����Ȥ����Ф��뤤���Ĥ����ͤ�DHCP ���ץ������ͤ����ꤹ��Τ� +�Ȥ���������ʤ��Ȥ�����ޤ��� +����򤹤�ˤϼ���ɾ�������ѤǤ��ޤ��� +.B dhcp-eval(5) +�ޥ˥奢��ڡ����˼��ν������Ҥ٤��Ƥ��ޤ��� +ɾ���η�̤򥪥ץ�������������ˤϡ����ץ����򼡤Τ褦��������ޤ�: +.nf +.sp 1 + \fBoption \fImy-option \fB= \fIexpression \fB;\fR +.fi +.PP +�㤨�м��Τ褦�ˤ��ޤ�: +.nf +.sp 1 + option hostname = binary-to-ascii (16, 8, "-", + substring (hardware, 1, 6)); +.fi +.SH ɸ�� DHCP ���ץ���� +���˼����͡��ʥ��ץ����˴ؤ��뵭�Ҥϡ� +DHCP ���ץ����˴ؤ���ǿ��� IETF �ɥ�ե�ʸ�񤫤�Τ�ΤǤ��� +̾�����Ǻܤ���Ƥ��ʤ����ץ����ϡ��ޤ���������Ƥ��ʤ����⤷��ޤ��󤬡� +����ե������������뤳�Ȥǡ����Τ褦�ʥ��ץ�����Ȥ��뤫�⤷��ޤ��� +�ܤ����ϡ�������Ρֿ������ץ���������פ���³�����Ҥ򻲾Ȥ��Ƥ��������� +.PP +�����˵��Ҥ���Ƥ��륪�ץ����Τ����Τ����Ĥ��ϡ�DHCP �����Ф⤷���� +���饤����Ȥˤ�äƼ�ưŪ������������Τǡ��桼���ˤ�����Ǥ��ޤ��� +���Τ褦�ʥ��ץ������ͤϡ�����¦�� DHCP �ץ��ȥ��륨��������� +(�����Ф⤷���ϥ��饤�����) ������ե�������Ρ��㤨�о�Ｐ�ʤɤ� +�Ȥ��ޤ��� +���������Υ��ץ������ͤϡ�����¦�Υ���������Ȥ�����ե�������Ǥ� +�Ȥ��뤳�ȤϤ���ޤ��� +�Ȥ����Τ⡢�����ͤϡ�����ե����뤬�������줿��˷��ꤵ��뤫��Ǥ��� +�ʹߤε��Ҥˤ����ơ����Τ褦�ʥ��ץ����ˤ� +�֥桼�������ꤹ�뤳�ȤϤǤ��ޤ���פȵ�����ޤ��� +.PP +ɸ�४�ץ����򼨤��ޤ�: +.PP +.B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ���³����Ƥ��� IP �ͥåȥ���������֥ͥåȤ� +���Ѥ��� MTU �������饤����Ȥ�ľ����³����Ƥ��륵�֥ͥåȤ� MTU �� +Ʊ���Ǥ���ȡ����饤����Ȥ����ꤷ�Ƥ褤������ꤷ�ޤ��� +�� true �ϡ������֥ͥåȤ�Ʊ��� MTU �Ǥ��뤳�Ȥ��̣���ޤ��� +�� false �ϡ�ľ����³����Ƥ���ͥåȥ���Υ��֥ͥåȤˤϡ���꾮���� MTU �� +���Ĥ�Τ�����ȡ����饤����Ȥ����ꤹ�٤��Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�ARP ����å��奨��ȥ�Υ����ॢ���Ȥ��ÿ��ǻ��ꤷ�ޤ��� +.RE +.PP +.B option \fBbootfile-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ���ư�ե��������ꤹ�뤿��˻��Ѥ��ޤ��� +���饤����Ȥˤ�äƥ��ݡ��Ȥ���Ƥ����硢 +����� \fBfilename\fR �����Ʊ�����̤�����ޤ��� +BOOTP ���饤����Ȥǡ����Υ��ץ����򥵥ݡ��Ȥ��Ƥ����ΤϾ��ʤ��Ǥ��礦�� +DHCP ���饤����Ȥˤ�äƤϥ��ݡ��Ȥ����Τ����ꡢ +�º�ɬ�ܤȤ��Ƥ����Τ�����ޤ��� +.RE +.PP +.B option \fBboot-size\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤������ѤΥǥե���ȤΥ֡��ȥ��᡼����Ĺ���� +512 �����ƥåȥ֥��å����ǻ��ꤷ�ޤ��� +.RE +.PP +.B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����ȤΥ��֥ͥåȤǻ��Ѥ���Ƥ��� +�֥����ɥ��㥹�ȥ��ɥ쥹����ꤷ�ޤ��� +�����ʥ֥����ɥ��㥹�ȥ��ɥ쥹���ͤϡ�STD 3 (RFC1122) �� 3.2.1.3 ��� +���ꤵ��Ƥ��ޤ��� +.RE +.PP +.B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +���å��������Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� +RFC 865 ���å��������ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBdefault-ip-ttl\fR \fIuint8;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ��ǡ������������Ф���Ȥ��˻��Ѥ��٤��� +�ǥե���Ȥ���¸���� (TTL) ����ꤷ�ޤ��� +.RE +.PP +.B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ� TCP �������Ȥ����Ф���Ȥ��˻��Ѥ��٤��� +�ǥե���Ȥ� TTL ����ꤷ�ޤ��� +�Ǿ��ͤ� 1 �Ǥ��� +.RE +.PP +.B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ�����Ȥäơ��ۥ��������� DHCP ���饤����ȼ��̻Ҥ� +���ꤹ�뤳�Ȥ��Ǥ��ޤ��� +���Υ��饤����ȼ��̻ҤǾȹ��Ԥ����Ȥǡ� +dhcpd �Ϥ��Υۥ��ȤΥ쥳���ɤ�ȯ�����뤳�Ȥ��Ǥ��ޤ��� +.PP +.\" metal +DHCP ���饤����Ȥ���ˤϡ�ASCII �ƥ����Ȥˤ�äƥ��饤����ȼ��̻Ҥ� +���ꤵ�줿��硢���� ASCII �ƥ����Ȥ���Ƭ�� 0 ��Ĥ����Τ����뤳�Ȥ� +���դ��Ƥ��������� +���ξ�硢 +.nf + + option dhcp-client-identifier "foo"; + +�ǤϤʤ����ʲ��Τ褦�˵��Ҥ���ɬ�פ�����Ǥ��礦�� + + option dhcp-client-identifier "\\0foo"; +.fi +.RE +.PP +.B option \fBdhcp-lease-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤������׵� (DHCPDISCOVER �ޤ��� DHCPREQUEST) ����ǡ� +���饤����Ȥ� IP ���ɥ쥹�Υ꡼�����֤��׵᤹�뤿��˻��Ѥ���ޤ��� +�ޤ������б��� (DHCPOFFER) ����ǡ�DHCP �����Ф��󼨤������꡼�����֤� +���ꤹ��Τˤ⡢���Υ��ץ����ϻȤ��ޤ��� +.PP +�ܥ��ץ����ϡ������ФǤϥ桼����ľ�����ꤹ�뤳�ȤϤǤ��ޤ��� +.B dhcpd.conf(5) +�� \fImax-lease-time\fR �� \fidefault-lease-time\fR �����Х��ץ����� +���Ȥ��Ƥ��������� +.RE +.PP +.B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥ������Ф��줿��硢�����Ф����饤����Ȥ� +���Ф��뤹�٤Ƥα����κ��祵��������ꤷ�ޤ��� +�����Ф����ꤵ�줿��硢���饤����Ȥ� dhcp-max-message-size ���ץ����� +�������Ƥ��ʤ��ä��ݤˡ����Υ����Ф����ꤵ�줿�ͤ����Ѥ���ޤ��� +����ϡ�BOOTP �����Ǥ� DHCP ������Ʊ�ͤ�ư��ޤ��� +.RE +.PP +.B option \fBdhcp-message\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ��㳲�����������ˡ�DHCP �����Ф� DHCPNAK ��å�������� +DHCP ���饤����Ȥإ��顼��å��������󶡤���Τ˻��Ѥ��ޤ��� +�ޤ����饤����Ȥ����󼨤��줿�ѥ�᡼������ݤ�����ͳ�򼨤�����ˡ� +DHCPDECLINE ��å���������ܥ��ץ�����Ȥ����Ȥ⤢��ޤ��� +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.RE +.PP +.B option \fBdhcp-message-type\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥȥ����Ф�ξ�Ԥ������Ф��졢 +DHCP �ѥ��åȤ��ޤ�Ǥ��� DHCP ��å������Υ����פ���ꤷ�ޤ��� +�ܥ��ץ���󤬼�������ͤϡ��ʲ��ΤȤ���Ǥ� (RFC2132 ��ꤽ�Τޤ�ȴ��)�� +.PP +.nf + 1 DHCPDISCOVER + 2 DHCPOFFER + 3 DHCPREQUEST + 4 DHCPDECLINE + 5 DHCPACK + 6 DHCPNAK + 7 DHCPRELEASE + 8 DHCPINFORM +.fi +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.B option \fBdhcp-option-overload\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ�DHCP 'sname' �⤷���� 'file' �ե�����ɤ��� +DHCP ���ץ������ݻ����뤿��˵ͤ���߲᤮�ˤʤäƤ��뤳�Ȥ� +�����Τ˻Ȥ��ޤ��� +DHCP �����Фϡ��ֵѤ��줿�ѥ�᡼���������ץ������̾������Ƥ�줿 +���֤�Ķ�ᤷ����硢�ܥ��ץ������������ޤ��� +.PP +�ܥ��ץ����¸�ߤ�����硢���饤����Ȥϡ�ɸ��Υ��ץ����ե�����ɤ� +��᤬��λ�����塢���ꤵ�줿�ղåե�����ɤβ���Ԥ��ޤ��� +.PP +�ܥ��ץ������������ͤϡ��ʲ����̤�Ǥ�: +.PP +.nf + 1 'file' �ե�����ɤ������ץ�����ݻ��˻��Ѥ���Ƥޤ� + 2 'sname' �ե�����ɤ������ץ�����ݻ��˻��Ѥ���Ƥޤ� + 3 ξ���Υե�����ɤ������ץ�����ݻ��˻��Ѥ���Ƥޤ� +.fi +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.PP +.B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥ������Ф��줿��硢 +�����Ф��������˾���륪�ץ����򥯥饤����Ȥ����ꤷ�ޤ��� +�̾� ISC DHCP ���饤����ȤǤϡ�\fIrequest\fR ʸ���Ѥ��ƹԤ��ޤ��� +�ܥ��ץ���󤬥��饤����Ȥ�����ꤵ��ʤ��ä���硢�̾� DHCP �����Фϡ� +�����������ͭ�����ı����˼��ޤ뤹�٤ƤΥ��ץ������֤��ޤ��� +�ܥ��ץ���󤬥����о�ǻ��ꤵ�줿��硢�����ФϤ��λ��ꤵ�줿���ץ����� +�֤��ޤ��� +����ϡ����饤����Ȥ��׵ᤷ�ʤ��ä����ץ����򡢥��饤����Ȥ� +��������Τ˻��Ѥ���ޤ��� +�ޤ����̾掠���Ф��֤����ץ����Υ��åȤ򤵤�����¤���ɬ�פΤ��� +���饤����Ȥ��Ф��ơ�DHCP �����Фα�����Ĵ������Τˤ���Ѥ���ޤ��� +.RE +.PP +.B option \fBdhcp-rebinding-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥ����ɥ쥹��������Ƥ��� REBINDING ���֤� +�ܹԤ���ޤǤλ��֤��ÿ��ǻ��ꤷ�ޤ��� +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.PP +.B option \fBdhcp-renewal-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥ����ɥ쥹��������Ƥ��� RENEWING ���֤� +�ܹԤ���ޤǤλ��֤��ÿ��ǻ��ꤷ�ޤ��� +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.PP +.B option \fBdhcp-requested-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ����饤����Ȥ���DHCPDISCOVER �������� IP ���ɥ쥹�� +������Ƥ��뤳�Ȥ��׵᤹��Τ˻��Ѥ���ޤ��� +.PP +�ܥ��ץ����ϡ��桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.PP +.B option \fBdhcp-server-identifier\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ�DHCPOFFER �� DHCPREQUEST ��å�������ǻ��Ѥ��졢 +�ޤ� DHCPACK �� DHCPNAK ��å�������ˤ�ޤޤ�뤳�Ȥ�����ޤ��� +DHCP �����Фϡ����饤����Ȥ� (����: ʣ�������Ф����) �꡼�����󼨤� +���̤Ǥ���褦��DHCPOFFER ���ܥ��ץ�����ޤ�ޤ��� +DHCP ���饤����Ȥϡ�DHCP �����Фإ�˥��㥹�Ȥ��뤹�٤Ƥ� DHCP ��å������� +���襢�ɥ쥹�Ȥ��� 'server identifier' �ե�����ɤ����Ƥ���Ѥ��ޤ��� +�ޤ� DHCP ���饤����Ȥϡ�DHCPREQUEST ��å���������ܥ��ץ�����ޤᡢ +ʣ���Υ꡼�����󼨤Τɤ��������줿���򼨤��ޤ��� +.PP +�ܥ��ץ������ͤϡ������Ф� IP ���ɥ쥹�Ǥ��� +.PP +�ܥ��ץ����ϡ��桼����ľ�����ꤹ�뤳�ȤϤǤ��ޤ��� +.B \fIdhcpd.conf(5) +�� \fIserver-identifier\fR �����Х��ץ����򻲾Ȥ��Ƥ��������� +.PP +.RE +.PP +.B option \fBdomain-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ��ɥᥤ��͡��ॷ���ƥ����Ѥ��ƥۥ���̾���褹��Ȥ��� +���饤����Ȥ����Ѥ��٤��ɥᥤ��̾����ꤷ�ޤ��� +.RE +.PP +.B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +domain-name-servers ���ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� +�ɥᥤ��͡��ॷ���ƥ� (STD 13, RFC 1035) �Υ͡��ॵ���ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBextensions-path\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ��ɲå��ץ�����ޤ�ե�����Υե�����̾����ꤷ�ޤ��� +�����ɲå��ץ����ϡ�RFC2132 �ǵ��ꤵ��Ƥ��� DHCP ���ץ����ν񼰤˱�ä� +��ᤵ��ޤ��� +.RE +.PP +.B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +Finger �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� Finger �Υꥹ�Ȥ� +���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� X Window System �ե���ȥ����Ф� +���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBhost-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ�̾������ꤷ�ޤ��� +����̾���ϡ���������ɥᥤ��̾�˽�������Ƥ��Ƥ⡢���ʤ��Ƥ⤫�ޤ����� +(�ɥᥤ��̾����ꤹ��ˤϡ�domain-name ���ץ����λ��Ѥ򤪴��ᤷ�ޤ�)�� +ʸ�����������ˤĤ��Ƥ� RFC 1035 �򻲾Ȥ��Ƥ��������� +���饤����ȥޥ���Υۥ���̾�����ꤵ��Ƥ��ʤ���� (���ʤ�� +.B rc.conf(5) +�Ƕ�ʸ��������ꤵ��Ƥ�����) �Τߡ� +.B dhclient-script(8) +���ܥ��ץ�����º�Ť��ޤ��� +.RE +.PP +.B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����󥿥ե��������������ͥåȤǤ�����ˡ� +���饤����Ȥ��������ͥåȥС������ 2 (RFC 894) �� +IEEE 802.3 (RFC 1042) �Τɤ���Υ��ץ��벽����Ѥ��٤�������ꤷ�ޤ��� +�� false �ϡ����饤����Ȥ� RFC 894 �Υ��ץ��벽����Ѥ��٤��Ǥ��뤳�Ȥ� +��̣���ޤ��� +�� true �ϡ����饤����Ȥ� RFC 1042 �Υ��ץ��벽����Ѥ��٤��Ǥ��뤳�Ȥ� +��̣���ޤ��� +.RE +.PP +.B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]; +.RS 0.25i +.PP +ien116-name-servers ���ץ����ϡ� +���饤����Ȥ����Ѳ�ǽ�� IEN 116 �͡��ॵ���ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +impress-server ���ץ����ϡ� +���饤����Ȥ����Ѳ�ǽ�� Imagen Impress �����ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����Υ��󥿥ե��������Ф��ƻ��Ѥ��� MTU ����ꤷ�ޤ��� +MTU ���Ф���Ǿ��������ͤ� 68 �Ǥ��� +.RE +.PP +.B option \fBip-forwarding\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����ѥ��åȤ�ž������褦�� +��ʬ�� IP �ؤ����ꤹ�٤�������ꤷ�ޤ��� +�� false �� IP ž����̵���ˤ��뤳�Ȥ��̣���� +�� true �� IP ž����ͭ���ˤ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBirc-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +IRC �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� IRC �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +log-server ���ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� MIT-LCS UDP ���������Ф� +�ꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +LPR �����Х��ץ����ϡ� +���饤����Ȥ����Ѳ�ǽ�� RFC 1179 �饤��ץ�󥿥����ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBmask-supplier\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�ICMP ����Ѥ������֥ͥåȥޥ����׵���Ф��ơ� +���饤����Ȥ��������٤�������ꤷ�ޤ��� +�� false �ϡ����饤����Ȥ��������٤��Ǥʤ����Ȥ��̣���ޤ��� +�� true �ϡ����饤����Ȥ��������٤��Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ȥ�Ω�Ƥν����򤹤٤� +����ǡ�������ॵ��������ꤷ�ޤ��� +�Ǿ��������ͤ� 576 �Ǥ��� +.\" The minimum value legal value is 576. +.\" The minimum legal value is 576. ���� (horikawa@jp.freebsd.org 19990404) +.RE +.PP +.B option \fBmerit-dump\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ�����å��夹��Ȥ��� +���饤����ȤΥ������᡼��������פ����ե�����Υѥ�̾����ꤷ�ޤ��� +�ѥ��ν񼰤ϡ�NVT ASCII ʸ�������ʸ������ʤ�ʸ����Ǥ��� +.RE +.PP +.B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�ʥ�Х��� IP �ۡ��२��������Ȥ� +IP ���ɥ쥹�Υꥹ�Ȥ���ꤷ�ޤ��� +����������Ȥϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +���������̾泌��������Ȥ� 1 �ĤǤ��礦�� +.RE +.PP +.B option \fBnds-context\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-context ���ץ����ϡ�NDS ���饤����ȤΤ���κǽ�� +NetWare �ǥ��쥯�ȥꥵ���ӥ���̾������ꤷ�ޤ��� +.RE +.PP +.B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-servers ���ץ����ϡ�NDS �����Ф� IP ���ɥ쥹�Υꥹ�Ȥ���ꤷ�ޤ��� +.RE +.PP +.B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-tree-name ���ץ����ϡ�NDS ���饤����Ȥ����Ѥ��٤� NDS �ĥ꡼�� +̾������ꤷ�ޤ��� +.RE +.PP +.B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +NetBIOS �ǡ�����������ۥ����� (NBDD) ���ץ����ϡ� +RFC 1001/1002 �� NBDD �����ФΥꥹ�Ȥ�ͥ�褵����Τ����˻��ꤷ�ޤ��� +.RE +.PP +.B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR +.RS 0.25i +.PP +NetBIOS �͡��ॵ���� (NBNS) ���ץ����ϡ� RFC 1001/1002 �� +NBNS �͡��ॵ���ФΥꥹ�Ȥ�ͥ�褵����Τ����˻��ꤷ�ޤ��� +���ߤǤϡ�NetBIOS �͡��ॵ���ӥ��� WINS �ȸƤФ�뤳�Ȥ�����¿���Ǥ��� +netbios-name-servers ���ץ�������Ѥ��ơ�WINS �����Ф�����ǽ�Ǥ��� +.RE +.PP +.B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +NetBIOS �Ρ��ɥ����ץ��ץ����ϡ� +�����ǽ�� NetBIOS over TCP/IP ���饤����Ȥ� +RFC 1001/1002 �˵��Ҥ���Ƥ���褦�����ꤷ�ޤ��� +�ͤ�ñ��Υ����ƥåȤȤ��ƻ��ꤵ�졢���饤����ȥ����פ��̣���ޤ��� +.PP +���Ѳ�ǽ�ʥΡ��ɥ����פϼ����̤�Ǥ�: +.PP +.TP 5 +.I 1 +B �Ρ���: �֥����ɥ��㥹�� - WINS ̵�� +.TP +.I 2 +P �Ρ���: �ԥ� - WINS �Τ� +.TP +.I 4 +M �Ρ���: �ߥå��� - �֥����ɥ��㥹�ȸ�� WINS +.TP +.I 8 +H �Ρ���: �ϥ��֥�å� - WINS ��˥֥����ɥ��㥹�� +.RE +.PP +.B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +NetBIOS �������ץ��ץ����ϡ�RFC 1001/1002 �˵��ꤵ��Ƥ���褦�ˡ� +���饤����Ȥ� NetBIOS over TCP/IP �������ץѥ�᡼������ꤷ�ޤ��� +ʸ�����������ˤĤ��Ƥ� RFC1001, RFC1002, RFC1035 �򻲾Ȥ��Ƥ��������� +.RE +.PP +.B option \fBnis-domain\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ� NIS (Sun Network Information Services) +�ɥᥤ�����ꤷ�ޤ��� +�ɥᥤ��ν񼰤ϡ�NVT ASCII ʸ�������ʸ������ʤ�ʸ����Ǥ��� +.RE +.PP +.B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� NIS �����Ф򼨤� IP ���ɥ쥹�� +�ꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBnisplus-domain\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ� NIS+ �ɥᥤ���̾������ꤷ�ޤ��� +�ɥᥤ��ν񼰤ϡ�NVT ASCII ʸ�������ʸ������ʤ�ʸ����Ǥ��� +.RE +.PP +.B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� NIS+ �����Ф򼨤� IP ���ɥ쥹�� +�ꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +NNTP �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� NNTP �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����������ʻ����ϩ (non-local source route) ����� +�ǡ���������ž������褦�ˡ����饤����Ȥ���ʬ�� IP �ؤ����ꤹ�٤����� +���ꤷ�ޤ� (�ܹ��ܤˤĤ��Ƥ� [4] �� 3.3.5 ��򻲾Ȥ��Ƥ�������)�� +�� false �Ϥ��Τ褦�ʥǡ���������ž������Ĥ��ʤ����Ȥ��̣���� +�� true ��ž�����Ĥ��̣���ޤ��� +.RE +.PP +.B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� NTP (RFC 1035) �����Ф򼨤� +IP ���ɥ쥹����ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBnwip-domain\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +NetWare/IP ���饤����Ȥ����Ѥ��٤� NetWare/IP �ɥᥤ���̾���Ǥ��� +.RE +.PP +.B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +NetWare/IP ���饤������ѤΥ��֥��ץ����Υ������󥹤Ǥ��� +�ܤ����� RFC2242 �򻲾Ȥ��Ƥ��������� +�̾�ܥ��ץ���������� NetWare/IP ���֥��ץ�������ꤹ�뤳�Ȥ� +���ꤵ��ޤ��� +����ʤ����ϡ�NetWare/IP ���֥��ץ����פξϤ򻲾Ȥ��Ƥ��������� +.RE +.PP +.B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�RFC 1191 ���������뵡����ȯ�����줿�ѥ� MTU �ͤ� +�������󥰤˻��Ѥ��륿���ॢ���� (��ñ��) ����ꤷ�ޤ��� +.RE +.PP +.B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�RFC 1191 ����������ѥ� MTU õ�� (Path MTU Discovery) +�»ܻ��˻��Ѥ���� MTU �Υ�������ɽ����ꤷ�ޤ��� +ɽ�ν񼰤ϡ��Ǿ������˺���ޤǤΡ�16 �ӥå����̵�������Υꥹ�ȤǤ��� +�Ǿ� MTU �� 68 ��꾮�����ƤϤʤ�ޤ��� +.RE +.PP +.B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ� ICMP ����Ѥ��ƥ��֥ͥåȥޥ���õ���� +�»ܤ��٤�������ꤷ�ޤ��� +�� false �ϡ����饤����Ȥ��ޥ���õ����»ܤ��٤��Ǥʤ����Ȥ��̣���ޤ��� +�� true �ϡ����饤����Ȥ��ޥ���õ����»ܤ��٤��Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.nf +.B option \fBpolicy-filter\fR \fIip-address ip-address\fR + [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR +.RE +.fi +.RS 0.25i +.PP +�ܥ��ץ����ϡ����������ʻ����ϩ������Ф���ݥꥷ�ե��륿����ꤷ�ޤ��� +�ե��륿�ϡ�IP ���ɥ쥹�ȥޥ������ȤΥꥹ�Ȥ���ʤꡢ +���夹������ϩ���椵�줿�ǡ���������ѤΥե��륿�Ȥʤ� +����/�ޥ������Ȥ���ꤷ�ޤ��� +.PP +���ۥåץ��ɥ쥹���ե��륿�Τ�����ˤ�Ŭ�礷�ʤ������ϩ���椵�줿 +�ǡ��������ϡ����饤����Ȥ��˴����٤��Ǥ��� +.PP +����ʤ����� STD 3 (RFC1122) �򻲾Ȥ��Ƥ��������� +.RE +.PP +.B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +POP3 �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� POP3 �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBresource-location-servers\fR \fIip-address\fR + [\fB, \fR\fIip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� +RFC 887 �꥽��������������󥵡��ФΥꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBroot-path\fR \fItext\fB;\fR\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����ȤΥ롼�ȥǥ��������ޤޤ��ѥ�̾����ꤷ�ޤ��� +�ѥ��ν񼰤ϡ�NVT ASCII ʸ�������ʸ������ʤ�ʸ����Ǥ��� +.RE +.PP +.B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�RFC 1256 ����������롼��õ�� (Router Discovery) ������ +���Ѥ��ơ��롼�����������٤�������ꤷ�ޤ��� +�� false �ϡ����饤����Ȥ��롼��õ����»ܤ��٤��Ǥʤ����Ȥ��̣���ޤ��� +�� true �ϡ����饤����Ȥϥ롼��õ����»ܤ��٤��Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����ȤΥ롼�������������襢�ɥ쥹����ꤷ�ޤ��� +.RE +.PP +.B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +routers ���ץ����ϡ����饤����ȤΥ��֥ͥåȾ�ˤ���롼���� +IP ���ɥ쥹�Υꥹ�Ȥ���ꤷ�ޤ��� +�롼���ϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option slp-directory-agent \fIboolean ip-address +[\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ�2 �Ĥι��ܤ���ꤷ�ޤ�: +1 �İʾ�Υ����ӥ������������ץ��ȥ���ǥ��쥯�ȥꥨ��������� +(Service Location Protocol Directory Agent) �� IP ���ɥ쥹�ȡ� +�����Υ��ɥ쥹�λ��Ѥ�����Ū���ɤ����Ǥ��� +�ǽ�Υ֡����ͤ� true �Ǥ���С�SLP ����������Ȥϡ�����Ϳ����줿 +IP ���ɥ쥹�Τߤ���Ѥ��٤��Ǥ��� +�ͤ� false �Ǥ���С�SLP ����������Ȥϡ�SLP ����������Ȥ� +ǽưŪ�⤷���ϼ�ưŪ�ʥޥ�����㥹��õ�����ɲäǹԤäƤ⹽���ޤ��� +(�ܤ����� RFC2165 �򻲾Ȥ��Ƥ�������)�� +.PP +�ܥ��ץ����� slp-service-scope ���ץ����ˤ����ơ� +��SLP ����������ȡפȤϡ�DHCP �ץ��ȥ�����Ѥ������ꤵ�줿�ޥ����� +ư��Ƥ��륵���ӥ������������ץ��ȥ��륨��������Ȥ�ؤ��Ƥ��뤳�Ȥ� +���դ��Ƥ��������� +.PP +�ޤ��������Ĥ��δ�Ȥ� SLP �� NDS �ȸƤ�Ǥ��뤳�Ȥⵤ���դ��Ƥ��������� +�⤷ NDS �ǥ��쥯�ȥꥨ��������Ȥ����ꡢ���Υ��ɥ쥹�����ꤹ��ɬ�פ� +������ϡ� slp-directory-agent ���ץ�������ѤǤ���Ϥ��Ǥ��� +.RE +.PP +.B option slp-service-scope \fIboolean text\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�����ӥ������������ץ��ȥ���Υ����ӥ��������ץ��ץ����ϡ� +2 �Ĥι��ܤ���ꤷ�ޤ�: +SLP �ѤΥ����ӥ��������פΥꥹ�Ȥȡ����Υꥹ�Ȥλ��Ѥ�����Ū���ɤ����Ǥ��� +�ǽ�Υ֡����ͤ� true �Ǥ���С�SLP ����������Ȥϡ��ܥ��ץ����ˤ�� +�󶡤���륹�����פΥꥹ�ȤΤߤ���Ѥ��٤��Ǥ��� +�����Ǥʤ���С����Υ��ץ������󶡤����ꥹ�Ȥ�ͥ�褷�ơ� +���줾��θ�ͭŪ�������ȤäƤ⹽���ޤ��� +.PP +text ʸ����ϡ�SLP ����������Ȥ����Ѥ��٤��������פΡ�����޶��ڤ�� +�ꥹ�ȤȤ��Ƥ��������� +����Ͼ�ά��ǽ�ǡ����ξ�� SLP ����������Ȥϡ���ʬ���ΤäƤ��� +���٤ƤΥǥ��쥯�ȥꥨ��������ȤΥ������פΰ��ꥹ�Ȥ�Ȥ��ޤ��� +.RE +.PP +.B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +SMTP �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� SMTP �����ФΥꥹ�Ȥ� +���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.nf +.B option \fBstatic-routes\fR \fIip-address ip-address\fR + [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ���ϩ����å�����Ȥ߹���٤� +��Ū��ϩ�Υꥹ�Ȥ���ꤷ�ޤ��� +Ʊ��������Ф���ʣ���η�ϩ�����ꤵ��Ƥ�����ϡ� +ͥ���٤��㤯�ʤ����ǥꥹ�Ȥ���ޤ��� +.PP +��ϩ�� IP ���ɥ쥹���ȤΥꥹ�Ȥ���ʤ�ޤ��� +�ǽ�Υ��ɥ쥹�ϰ��襢�ɥ쥹�Ǥ��ꡢ +2 ���ܤΥ��ɥ쥹�Ϥ��ΰ�����Ф���롼���Υ��ɥ쥹�Ǥ��� +.PP +�ǥե���ȷ�ϩ (0.0.0.0) �ϡ���Ū��ϩ���Ф��Ƥ������ʰ���Ǥ��� +�ǥե���ȷ�ϩ����ꤹ��ˤϡ� +.B routers +���ץ�������Ѥ��Ƥ��������� +�ޤ����ܥ��ץ����ϡ����饹�쥹�� IP ��ϩ�����տޤ�����ΤǤ� +�ʤ����Ȥ����դ��Ʋ������� +����ϥ��֥ͥåȥޥ�����ޤ�Ǥ��ޤ��� +���ߡ����饹�쥹�� IP ��ϩ����ϡ���äȤ⹭��Ÿ������Ƥ��� +��ϩ����ɸ��ʤΤǡ��ܥ��ץ����ϼ¼�Ū��̵��̣�Ǥ��� +�����ơ��ޥ��������ե� DHCP ���饤����Ȥ�Ϥ���Ȥ���褯�Τ�줿 +DHCP ���饤����Ȥˤϼ�������Ƥ��ޤ��� +.RE +.PP +.nf +.B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR + [\fB,\fR \fIip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +StreetTalk Directory Assistance (STDA) �����Х��ץ����ϡ� +���饤����Ȥ����Ѳ�ǽ�� STDA �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +StreetTalk �����Х��ץ����ϡ� +���饤����Ȥ����Ѳ�ǽ�� StreetTalk �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option subnet-mask \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +���֥ͥåȥޥ������ץ����ϡ�RFC 950 �˽��äơ� +���饤����ȤΥ��֥ͥåȥޥ�������ꤷ�ޤ��� +����������Τɤ��ˤ⥵�֥ͥåȥޥ������ץ���󤬻��ꤵ��Ƥ��ʤ���硢 +�ǽ����ʤȤ��ơ�dhcpd �ϡ����ɥ쥹�������Ƥ褦�Ȥ��Ƥ��� +�ͥåȥ���Υ��֥ͥå�������顢���֥ͥåȥޥ�������Ѥ��ޤ��� +�����������ɥ쥹�������Ƥ褦�Ȥ��Ƥ���ͥåȥ���Υ���������� +.I �ɤΤ褦�� +���֥ͥåȥޥ������ץ��������Ǥ��äƤ⡢ +���֥ͥå�����ǻ��ꤵ�줿���֥ͥåȥޥ�����ͥ�褷�ޤ��� +.RE +.PP +.B option \fBsubnet-selection\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +(�׵᤬�Ф��줿���֥ͥåȤˤĤʤ��줿��졼�����ФΥ��ɥ쥹�˴�Ť���) +�̾����򤵤��Ǥ�������ΤǤϤʤ����֥ͥåȤΥ��ɥ쥹��ɬ�פʾ�硢 +���饤����Ȥ����Ф��ޤ��� +RFC3011 �򻲾Ȥ��Ƥ��������� +���Υ����Фˤ����ƻȤ��륪�ץ����ʥ�Ф� 118 �Ǥ��� +���Υʥ�Фϰ������餺�ä��������Ƥ����ʥ�ФǤϤʤ��� +�㤦�ͤ���Ѥ��륯�饤����Ȥ�¸�ߤ��뤳�Ȥ����դ��Ƥ��������� +���Υ��ץ����λ��ѤϾ����¸�Ū�Ǥ���ȹͤ���٤��Ǥ��礦! +.PP +�ܥ��ץ����ϡ������ФǤϥ桼�������ꤹ�뤳�ȤϤǤ��ޤ��� +.PP +.RE +.PP +.B option \fBswap-server\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����ȤΥ���åץ����Ф� IP ���ɥ쥹����ꤷ�ޤ��� +.RE +.PP +.B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ��Ť������Ȥθߴ����Τ���ˡ����ߤΥ����ƥåȤȰ��ˡ� +TCP �����ץ��饤�֥�å������򥯥饤����Ȥ�����٤�������ꤷ�ޤ��� +�� false �ϡ����ߤΥ����ƥåȤ�����٤��Ǥʤ����Ȥ��̣���ޤ��� +�� true �ϡ����ߤΥ����ƥåȤ�����٤��Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ� TCP �������ץ��饤�� (keepalive) +��å������� TCP ��³����������������ԤĤ٤��ֳ� (��ñ��) ����ꤷ�ޤ��� +���֤� 32 �ӥå����̵�������ǻ��ꤷ�ޤ��� +�� 0 �ϡ����ץꥱ�����������Ū���׵ᤷ�ʤ��¤ꡢ���饤����Ȥ� +��³��˥����ץ��饤�֥�å��������������٤��Ǥʤ����Ȥ��̣���ޤ��� +.RE +.PP +.B option \fBtftp-server-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����� TFTP �����Ф���ꤹ��Τ˻��Ѥ��졢���饤����Ȥ� +���ݡ��Ȥ��Ƥ�����ˤ� \fBserver-name\fR �����Ʊ�����̤�����ޤ��� +BOOTP ���饤����Ȥϡ��ܥ��ץ����򥵥ݡ��Ȥ��ʤ��Ǥ��礦�� +DHCP ���饤����Ȥˤ�äƤϥ��ݡ��Ȥ��Ƥ����Τ����ꡢ +�º�ɬ�ܤȤ��Ƥ����Τ�����ޤ��� +.RE +.PP +.B option time-offset \fIint32\fR\fB;\fR +.RS 0.25i +.PP +time-offset ���ץ����ϡ����������� (UTC) ������Ȥ��ơ� +���饤����ȤΥ��֥ͥåȤΥ��ե��åȤ��äǻ��ꤷ�ޤ��� +.RE +.PP +.B option time-servers \fIip-address\fR [, \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +time-server ���ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� RFC 868 ���掠���Ф� +�ꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ�ARP �ץ��ȥ�����ѻ��ˡ����饤����Ȥ��ȥ쥤����Ѥ� +�ͥ������������ (RFC 893 [14]) �򤹤٤�������ꤷ�ޤ��� +�� false �ϡ����饤����Ȥ��ȥ쥤����Ѥ��ߤ�٤��Ǥʤ��Ȱ�̣���ޤ��� +�� true �ϡ����饤����Ȥ��ȥ쥤����Ѥ��ߤ�٤��Ǥ���Ȱ�̣���ޤ��� +.RE +.PP +.B option \fBuap-servers\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ��桼��ǧ�ڥץ��ȥ��� (UAP) ����ޤ줿ǧ���׵�� +��������ǽ�ϤΤ���桼��ǧ�ڥ����ӥ��򤽤줾��ؤ��Ƥ��� +URL �Υꥹ�Ȥ���ꤷ�ޤ��� +UAP �����Ф� HTTP 1.1 ��³�� SSLv3 ��³�������뤳�Ȥ��Ǥ��ޤ��� +�ꥹ�Ȥ˴ޤޤ줿 URL �˥ݡ�����ʬ���ޤޤ�Ƥʤ����ϡ� +�̾�Υǥե���ȥݡ��Ȥ����ꤵ��ޤ� +(�Ĥޤ� http �ˤ� 80 �֡�https �ˤ� 443 ��)�� +�ꥹ�Ȥ˴ޤޤ줿 URL �˥ѥ�����ʬ���ޤޤ�Ƥʤ����ϡ� +�ѥ��� /uap �Ȳ��ꤵ��ޤ��� +2 �İʾ�� URL �����Υꥹ�Ȥ˻��ꤵ�줿��硢URL �϶���Ƕ��ڤ��ޤ��� +.RE +.PP +.B option \fBuser-class\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ��桼�������̾���򥯥饤����Ȥ˻��ꤹ����ʤȤ��ơ� +�����Ĥ��� DHCP ���饤����ȤǻȤ��ޤ��� +����� vendor-class-identifier ���ץ�����Ʊ�ͤ˻Ȥ��ޤ����� +�����ͤϡ��٥���ǤϤʤ����桼���ˤ�äƻ��ꤵ��ޤ��� +�Ƕ�ΤۤȤ�ɤ� DHCP ���饤����Ȥϡ����μ��̻Ҥ��ͤ���ꤹ�뤿��� +�桼�����󥿥ե������������Ƥ��ޤ��� +���μ��̻Ҥϡ��̾�ƥ�����ʸ����Ǥ��� +.RE +.PP +.B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +�ܥ��ץ����ϡ��٥�������פ䡢��ǽ�Ǥ���� DHCP ���饤����Ȥ������ +���̤��뤿��ˡ������Ĥ��� DHCP ���饤����ȤǻȤ��ޤ��� +���ξ�������Ƥϡ��٥����ͭ�ΥХ���ʸ����ǡ�ɸ��Ǥϵ��ꤵ��Ƥ��ޤ��� +���饤����Ȥ����Ф���٥�����饹���̻Ҥ��ǧ����ˤϡ� +�ʲ�������� DHCP ����������ե�����˲ä��Ƥ�������: +.nf +.PP +set vendor-class option vendor-class-identifier; +.fi +.PP +��������ϡ�DHCP �����ФΥ꡼���ǡ����١����ե�������Ρ� +�ʲ��Τ褦�� set ʸ����� vendor-class-identifier ���ץ����� +���äƤ��륯�饤����Ȥ��٤ƤΥ���ȥ�˺��Ѥ��ޤ��� +.nf +.PP +set vendor-class "SUNW.Ultra-5_10"; +.fi +.PP +vendor-class-identifier ���ץ����ϡ��̾� DHCP Server �ˤ�äơ� +.B vendor-encapsulated-options +���ץ��������֤���륪�ץ�������ꤹ��Τ˻Ȥ��ޤ��� +����ʤ����ϡ�dhcpd.conf �ޥ˥奢��ڡ����� VENDOR ENCAPSULATED OPTIONS �� +�Ϥ򻲾Ȥ��Ƥ��������� +.RE +.PP +.B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +\fBvendor-encapsulated-options\fR ���ץ����ϡ�1 �ĤΥ٥����ͭ�͡� +�⤷���� 1 �Ĥޤ��Ϥ���ʾ�Υ٥����ͭ���֥��ץ�����ޤߤޤ��� +�ܥ��ץ����ϡ��̾� DHCP �����Ф�����ե���������ꤵ����ΤǤ� +����ޤ��� +�̾�ϡ��٥�����饹���٥�����������졢 +�٥�����饹���֥��ץ����������졢���Υ��֥��ץ������ͤ� +������졢DHCP �����ФϤ������Ȥ˱������Ȥ߾夲�ޤ��� +.PP +�褯�Τ�줿 DHCP ���饤����ȥ٥�� (���ΤȤ��� Microsoft Windows +2000 DHCP ���饤�����) �����Τ����Ĥ��Υǥե���Ȥ�ư��Ǥϡ� +���Υ��ץ����ϼ�ưŪ�����ꤵ��ޤ���������¾�Τ�Τ˴ؤ��Ƥϡ� +��ư�����ꤷ�ʤ���Фʤ�ޤ��� +�ܺ٤� \fIdhcpd.conf\fI �� VENDOR ENCAPSULATED OPTIONS �ξϤ� +���Ȥ��Ƥ��������� +.RE +.PP +.B option \fBwww-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +WWW �����Х��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� WWW �Υꥹ�Ȥ���ꤷ�ޤ��� +�����Фϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.PP +.B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +�ܥ��ץ����ϡ����饤����Ȥ����Ѳ�ǽ�� X Window System +�ǥ����ץ쥤�ޥ͡������¹Ԥ��Ƥ��륷���ƥ�Υꥹ�Ȥ���ꤷ�ޤ��� +���ɥ쥹�ϡ�ͥ�褵����Τ����˥ꥹ�Ȥ��Ƥ��������� +.RE +.SH ��졼����������Ⱦ��󥪥ץ���� +.\" metal +IETF �ɥ�ե� draft-ietf-dhc-agent-options-11.txt �ˤϡ� +DHCP ��졼����������Ȥ� DHCP �ѥ��åȤ� DHCP �����Ф�ž������ݡ� +DHCP �ѥ��åȤ��ղä��뤳�ȤΤǤ����Ϣ�Υ��ץ��벽���줿���ץ���� +�������Ƥ��ޤ��� +�����Фϡ������Υ��ץ����˴�Ť������ɥ쥹�����η��� +(�䡢����¾��Ƚ��) ��Ԥ����Ȥ��Ǥ��ޤ��� +�ޤ������Фϡ���졼����������Ȥ��̤����֤����ɤΥѥ��åȤˤ� +�����Υ��ץ�����������֤��ޤ��� +����ˤ�äƥ�졼����������Ȥϡ������䥢������ƥ��󥰤ʤɤ� +�Ԥ�����ˡ������Υ��ץ����˴ޤޤ���������ѤǤ��ޤ��� +.PP +���ߤΥɥ�եȤˤ� 2 �ĤΥ��ץ�����������Ƥ��ޤ��� +DHCP �����ФǤ����Υ��ץ����򻲾Ȥ���ˤϡ����ץ�������̾ +"agent" �Τ��Ȥ˥ԥꥪ�ɤ�Ĥ������θ�˥��ץ����̾��³���Ƥ��������� +�����ФǤ����Υ��ץ������ͤ�������뤳�Ȥϡ� +�̾濫�ޤ�ͭ���ǤϤ���ޤ��󤬡����Ƥ���Ƥ��ޤ��� +�����Υ��ץ����ϡ����饤����ȤǤϥ��ݡ��Ȥ���Ƥ��ޤ��� +.PP +.B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +circuit-id ���֥��ץ����ϡ����饤����Ȥ��饵���Фؤ� DHCP �ѥ��åȤ� +������ä��������åȤ򼨤�������������ȥ�������ʥ������åȼ��̻Ҥ� +���󥳡��ɤ��Ƥ��ޤ��� +����ϡ�DHCP ������Ŭ�ڤʥ������åȤؤ������֤���褦�� +����������Ȥˤ�äƻȤ��뤳�Ȥ�տޤ��Ƥ��ޤ��� +���ߡ����Υ��ץ����ν񼰤�����ϥ٥����¸�ȤʤäƤ��ꡢ +¿ʬ���Τޤ޻Ĥ����Ǥ��礦�� +���������褳�ν񼰤�ɸ�ಽ������ǽ���⡢���ߤΥɥ�եȤˤϻĤ���Ƥ��ޤ��� +.RE +.PP +.B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +remote-id ���֥��ץ����ϡ��������åȤν�ü�Υ�⡼�ȥۥ��Ȥ� +����򥨥󥳡��ɤ��Ƥ��ޤ��� +����˴ޤޤ��Ǥ���������ϡ����Τ褦�ʤ�ΤǤ��� +�ƽи� ID ���󡢥桼��̾���󡢥�⡼�� ATM ���ɥ쥹�������֥��ǥ� ID�� +����¾��Ʊ�ͤʾ��� +��§Ū�ˤϡ����Υ��ץ����ΰ�̣�Ϥ������������Ƥ��ޤ��� +�������̾�������åȤ�����Υ�⡼�ȥ���ɤ��Ф��ư�դǤ���褦 +�������ݾڤ��줿���ʤ�餫�Υ��֥������Ȥȹͤ���٤���ΤǤ��� +.RE +.SH ���饤����� FQDN ���֥��ץ���� +.\" metal +���ߡ����󥿡��ͥåȥɥ�ե� draft-ietf-dhc-fqdn-option-00.txt �� +�������Ƥ��륯�饤����� FQDN ���ץ����ϡ��ޤ�ɸ��ȤʤäƤϤ��ޤ��� +���������Ǥ˽�ʬ�������Ѥ���Ƥ��ꡢ�桹�⤳���������Ƥ��ޤ��� +���ץ����ν񼰤�ʣ���ʤ��ᡢ�����Ǥϡ�ñ�ȤΥ��ץ����ǤϤʤ��� +���֥��ץ������֤˼������Ƥ��ޤ��� +����Ū�ˤϡ��ܥ��ץ����ϡ��桼���ˤ�ä����ꤵ����ΤǤϤʤ��� +��ư DNS ���������ƥ�ΰ����Ȥ��ƻȤ���٤���ΤǤ��� +.PP +.B option fqdn.no-client-update \fIflag\fB; +.RS 0.25i +.PP +�ܥ��ץ���󤬥��饤����Ȥ������Ф��줿��硢���줬 true �Ǥ���С� +���饤����Ȥϼ�ʬ�� A �쥳���ɤ򹹿����ʤ����Ȥ��̣���ޤ��� +�����Ф��饯�饤����Ȥ����Ф��줿���ϡ����饤����Ȥ� +��ʬ�� A �쥳���ɤ򹹿����� \fI�٤��ǤϤʤ�\fR ���Ȥ��̣���ޤ��� +.RE +.PP +.B option fqdn.server-update \fIflag\fB; +.RS 0.25i +.PP +�ܥ��ץ���󤬥��饤����Ȥ��饵���Ф����Ф��줿��硢 +�����Ф˥��饤����Ȥ� A �쥳���ɤι������׵ᤷ�Ƥ��ޤ��� +�����Ф������Ф��줿��硢�����Ф����饤����Ȥ� A �쥳���ɤ� +�������� (�⤷���Ϥ⤦������������Ȥ���) �Ǥ��뤳�Ȥ��̣���ޤ��� +.RE +.PP +.B option fqdn.encoded \fIflag\fB; +.RS 0.25i +.PP +true �Ǥ��ä��������ץ����˴ޤޤ��ɥᥤ��̾���� +������ ASCII �ƥ����ȤǤϤʤ���DNS �磻��ե����ޥåȤ� +���󥳡��ɤ���Ƥ��뤳�Ȥ򼨤��Ƥޤ��� +���饤����Ȥϡ���ʬ�� FQDN ���ץ����� DNS �磻��ե����ޥåȤ� +���ݡ��Ȥ��Ƥʤ���硢�̾盧�Υ��֥��ץ����� false �����ꤷ�ޤ��� +�����ФϾ�ˡ����饤����Ȥ����ꤷ���Τ�Ʊ���ͤ����ꤷ���֤��٤��Ǥ��� +�����ͤ�����ե���������ꤵ��Ƥ������ϡ�\fIfqdn.fqdn\fR ���֥��ץ����� +���󥳡��ɤ���ե����ޥåȤ����椷�ޤ��� +.RE +.PP +.B option fqdn.rcode1 \fIflag\fB; +.PP +.B option fqdn.rcode2 \fIflag\fB; +.RS 0.25i +.PP +�����Υ��ץ����Ϥ��줾�졢A �쥳���ɤ� PTR �쥳���ɤι�����̤򼨤��ޤ��� +�����ϡ�DHCP �����Ф��� DHCP ���饤����ȤؤΤ������ޤ��� +�����Υե�����ɤ��ͤϡ�DNS �ץ��ȥ��뵬�ʤˤ���������Ƥ��ޤ��� +.RE +.PP +.B option fqdn.fqdn \fItext\fB; +.RS 0.25i +.PP +���饤����Ȥ����Ѥ�˾��ɥᥤ��̾����ꤷ�ޤ��� +����ϴ����������줿�ɥᥤ��̾�Ǥ⡢ñ��Υ�٥�Ǥ⹽���ޤ��� +�⤷̾���� '.' ʸ�����ޤޤ�ʤ���С�����̾���ϴ�����������Ƥ��餺�� +�����Ф��̾���������������줿�ɥᥤ����Τ���̾���򹹿����ޤ��� +.RE +.PP +�⤷�����Υ��֥��ץ�������Ѥ��褦�ȻפäƤ���ΤǤ���С� +���饤����� FQDN ���ץ����Υɥ�ե� (�⤷���ϡ�ɸ��ˤʤä����Ϥ���ɸ��) +�򻲾Ȥ��뤳�Ȥ򶯤��侩���ޤ��� +����ʸ��ϡ����Υɥ�եȤ���٤��绨�Ĥ��Դ����Ǥ��ꡢ +���饤����� FQDN ���ץ���󵬳ʤ򤹤Ǥ����򤷤Ƥ���ͤ˻��Ȥ���뤳�Ȥ� +ñ�˰տޤ��Ƥ����ΤǤ��� +.SH NetWare/IP ���֥��ץ���� +.\" metal +RFC2242 �ϡ�Novell �� NetWare/IP ���饤������ѤΥ��ץ��벽���줿 +���ץ������Ȥ�������Ƥ��ޤ��� +DHCP �����Фˤ����Ƥ����Υ��ץ�������Ѥ���ˤϡ����ץ�������̾ +"nwip" �θ�˥ԥꥪ�ɤ�Ĥ������θ�˥��ץ����̾��³���Ƥ��������� +�ʲ��Υ��ץ���󤬻���Ǥ��ޤ�: +.PP +.B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +true �Ǥ��ä���硢���饤����Ȥϡ�NetWare/IP �����Фΰ��֤� +õ���Τ� NetWare Nearest Server Query ��Ȥ��٤��Ǥ��� +�ܥ��֥��ץ���� false �Ǥ��ä���硢�⤷���ϻ��ꤵ��ʤ��ä����� +Novell ���饤����Ȥ�ư��ϵ��ꤵ��Ƥ��ޤ��� +.PP +.RE +.B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��֥��ץ����ˤϡ�5 �ĤޤǤ� IP ���ɥ쥹�Υꥹ�Ȥ���ꤷ�ޤ��� +���줾��Υ��ɥ쥹�ϡ�NetWare �ɥᥤ�� SAP/RIP ������ (DSS) �� +IP ���ɥ쥹�Ǥ��� +.RE +.PP +.B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR + [\fB,\fR \fIip-address\fR...]\fR\fB;\fR +.RS 0.25i +.PP +�ܥ��֥��ץ����ˤϡ�5 �ĤޤǤ� IP ���ɥ쥹�Υꥹ�Ȥ���ꤷ�ޤ��� +���줾��Υ��ɥ쥹�ϡ����ܤ� NetWare IP ������ +(Nearest NetWare IP Server) �� IP ���ɥ쥹�Ǥ��� +.RE +.PP +.B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +��ư���ˡ�NetWare/IP ���饤����Ȥ���Ϳ����줿 DSS �����Ф� +�����̿����ߤ�٤�������ꤷ�ޤ��� +.RE +.PP +.B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +��ư���ˡ�NetWare/IP ���饤����Ȥ���Ϳ����줿 DSS �����Ф� +�̿����Ω������ˡ���ȥ饤�δֲ����ԤĤ٤�������ꤷ�ޤ��� +.RE +.PP +.B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +true �Ǥ��ä���硢NetWare/IP ���饤����Ȥ� NetWare/IP +�С������ 1.1 �򥵥ݡ��Ȥ��Ƥ���٤��Ǥ��� +����ϡ����饤����Ȥ� NetWare/IP �С������ 1.1 �Υ����Ф� +�̿�������Τ�ɬ�פǤ��� +.RE +.PP +.B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +NetWare/IP �ɥᥤ��Υץ饤�ޥ�ɥᥤ�� SAP/RIP �����ӥ������� +(DSS) �� IP ���ɥ쥹����ꤷ�ޤ��� +��������� DSS �����Ф�������ˡ�NetWare/IP �����桼�ƥ���ƥ��ϡ� +�����ͤ�ץ饤�ޥ� DSS �����ФȤ��ƻ��Ѥ��ޤ��� +.RE +.SH �������ץ�������� +.\" metal +Internet Systems Consortium DHCP ���饤����Ȥȥ����Фϡ� +�������ץ�����������뵡�����󶡤��Ƥ��ޤ��� +���줾��� DHCP ���ץ����ϡ�̾���ȥ����ɡ���¤����äƤ��ޤ��� +̾���ϡ����ѼԤ����ץ����򻲾Ȥ���Τ˻��Ѥ���ޤ��� +�����ɤϡ�DHCP �����Фȥ��饤����Ȥ����ץ����򻲾Ȥ���Τ� +���Ѥ����ֹ�Ǥ��� +��¤�ϡ����ץ��������Ƥ��ɤΤ褦�ʤ�Τ��򵭽Ҥ��Ƥ��ޤ��� +.PP +�������ץ������������ˤϡ�¾�Υ��ץ����ǤϻȤ��Ƥ��ʤ�̾���� +����ɬ�פ�����ޤ��� +�㤨�С�"host-name" �ȸ���̾���ϻ��ѤǤ��ޤ��� +�Ȥ����Τ⡢���Υޥ˥奢��ڡ����˽ФƤ����褦�ˡ� +DHCP �ץ��ȥ��뤬���� host-name ���ץ�����������Ƥ��뤫��Ǥ��� +���Υޥ˥奢��ڡ����˽ФƤ��Ƥ��ʤ����ץ����̾�ʤ�� +�ȤäƤ⹽���ޤ��󤬡�����ФƤ��륪�ץ����ȽŤʤ�ʤ��褦�ˡ� +���ץ����̾�κǽ���ȼ���ʸ�����Ĥ��뤳�Ȥϡ�¿ʬ�����ͤ��Ǥ��礦�� +�㤨�С������� DHCP ���ץ����ˤ� "local" �ǻϤޤ��Τ��ʤ��Τǡ� +"local-host-name" �ȸ���̾���ϡ������餫�¿���������Ǥ���Ǥ��礦�� +.PP +̾�������򤷤��顢���ϥ����ɤ����ФͤФʤ�ޤ��� +DHCP ���ץ����� 128 ���� 256 �ޤǤΥ����ɤϡ� +�����ȥ������륪�ץ�����ѤȤ���ͽ�󤵤�Ƥ���Τǡ� +������Υ����ɤʤ�ɤ�Ǥ����֤��Ȥ��Ǥ��ޤ��� +�ºݤˤϡ��ץ��ȥ���򾯡������ޤ��˲�ᤷ�Ƥ���٥�������ꡢ +128 ����礭���ͤΥ��ץ���󥳡��ɤ���Ѥ��Ƥ��ޤ��� +��������������˲��򤹤���ˡ�Ϥ���ޤ��󤬡� +�ºݤˤϤ����礭������������������ΤǤϤʤ��Ǥ��礦�� +.PP +���ץ����ι�¤�Ȥϡ�ñ�˥��ץ����Υǡ�����ɽ������Ƥ�������Ǥ��� +���� ISC DHCP �����Фϡ��������֡����͡�ʸ���󤽤��� IP ���ɥ쥹�Ȥ��ä��� +�����Ĥ���ñ��ʥǡ������򥵥ݡ��Ȥ��Ƥ��ꡢ +�ޤ�ñ��ǡ����������������Υǡ�������������������뤳�Ȥ�Ǥ��ޤ��� +.PP +�������ץ����ϡ��ʲ��Τ褦���������ޤ�: +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.I definition +.B ; +.PP +.I new-name +�� +.I new-code +���ͤϡ��������ץ�����Ѥˤ��ʤ����������ΤǤ��� +.I definition +�ϡ����ץ����ι�¤������Ǥ��� +.PP +�ʲ���ñ��ʥ��ץ����η���������ݡ��Ȥ���Ƥ��ޤ�: +.PP +.B �֡����� +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B boolean +.B ; +.PP +�֡��뷿�Υ��ץ����ϡ�on �ޤ��� off (�⤷���� true �� false) ���ͤ� +���ĥե饰�Ǥ��� +�֡��뷿�λ�����ϡ��ʲ��Τ褦�ˤʤ�ޤ�: +.nf + +option use-zephyr code 180 = boolean; +option use-zephyr on; + +.fi +.B ���� +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.I sign +.B integer +.I width +.B ; +.PP +\fIsign\fR �ȡ�����ϡ�����\fIunsigned\fR��\fIsigned\fR �Τ����줫�Ǥ��� +width �� 8, 16, 32 �Τ����줫�ǡ������� bit ���򼨤��ޤ��� +�㤨�С��ʲ��� 2 �Ԥϡ�sql-connection-max ���ץ���������� +����ˡ�򼨤��ޤ�: +.nf + +option sql-connection-max code 192 = unsigned integer 16; +option sql-connection-max 1536; + +.fi +.B IP ���ɥ쥹 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B ip-address +.B ; +.PP +IP ���ɥ쥹���ι�¤����ĥ��ץ����ϡ��ɥᥤ��̾�⤷���� +�ɥåȶ��ڤ�� 4 ������ɽ������ޤ��� +�ʲ��ϡ�IP ���ɥ쥹���λ�����Ǥ�: +.nf + +option sql-server-address code 193 = ip-address; +option sql-server-address sql.example.com; + +.fi +.PP +.B �ƥ����� +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B text +.B ; +.PP +�ƥ����ȷ��Υ��ץ����ϡ�ASCII �ƥ�����ʸ����򥨥󥳡��ɤ��ޤ��� +�㤨��: +.nf + +option sql-default-connection-name code 194 = text; +option sql-default-connection-name "PRODZA"; + +.fi +.PP +.B �ǡ���ʸ���� +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B string +.B ; +.PP +�ǡ���ʸ���󷿤Υ��ץ����ϡ��ܼ�Ū�ˤ�ñ�ʤ�Х��Ȥν����ΤǤ��� +�ƥ����ȷ��Τ褦�˥������Ȥ��줿�ƥ����Ȥǻ��ꤵ��뤫�� +�⤷���ϥ�������ڤ�� 16 �ʿ��Υꥹ�Ȥǻ��ꤵ��ޤ��� +���λ�������Ƕ��ڤ�줿��Ȥϡ�0 ���� FF �δ֤��ͤǤʤ���Фʤ�ޤ��� +�㤨��: +.nf + +option sql-identification-token code 195 = string; +option sql-identification-token 17:23:19:a6:42:ea:99:7c:22; + +.fi +.PP +.B ���ץ��벽 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B encapsulate +.I identifier +.B ; +.PP +���ץ��벽���Υ��ץ����ϡ�\fIidentifier\fR �ǻ��ꤵ�줿 +���ץ������֤���Ȥ򥫥ץ��벽���ޤ��� +���� DHCP �ץ��ȥ����¸�ߤ��륫�ץ��벽���ץ�������ϡ� +vendor-encapsulated-options ���ץ����netware-suboptions ���ץ���� +relay-agent-information ���ץ����ʤɤǤ��� +.nf + +option space local; +option local.demo code 1 = text; +option local-encapsulation code 197 = encapsulate local; +option local.demo "demo"; + +.fi +.PP +.B ���� +.PP +���ץ����ϡ��ƥ����ȷ��ȥǡ���ʸ���󷿰ʳ��ξ�ҤΤ����ʤ�ǡ������� +�����ޤळ�Ȥ��Ǥ��ޤ��� +�ƥ����ȷ��ȥǡ���ʸ���󷿤ϡ���������Ǥϥ��ݡ��Ȥ���Ƥ��ޤ��� +�����������ϰʲ����̤�Ǥ�: +.nf + +option kerberos-servers code 200 = array of ip-address; +option kerberos-servers 10.20.10.1, 10.20.11.1; + +.fi +.B �쥳���� +.PP +���ץ����ϡ��ǡ���������ǹ��������ǡ�����¤��ޤळ�Ȥ�Ǥ��ޤ��� +����Ϥ��Ф��Х쥳���ɷ��ȸƤФ�ޤ��� +�㤨��: +.nf + +option contrived-001 code 201 = { boolean, integer 32, text }; +option contrived-001 on 1772 "contrivance"; + +.fi +�ޤ��쥳���ɤ�����Υ��ץ�������Ĥ��Ȥ�Ǥ��ޤ��� +�㤨��: +.nf + +option new-static-routes code 201 = array of { + ip-address, ip-address, ip-address, integer 8 }; +option static-routes + 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, + 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, + 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3; + +.fi +.SH �٥�����ץ��벽���ץ���� +.\" metal +DHCP �ץ��ȥ���ˤϡ�\fB vendor-encapsulated-options\fR ���ץ���� +�������Ƥ��ޤ��� +�٥���ϡ����Υ��ץ����ˤ�äơ��٥����ͭ�Υ��ץ����� +ɸ�� DHCP ���ץ����˴ޤ�����Ф��뤳�Ȥ��Ǥ��ޤ��� +.B vendor-encapsulated-options +���ץ����ν񼰤ϡ��񼰤����ꤵ��Ƥ��ʤ���Ϣ�ΥХ����� +�⤷���ϰ�Ϣ�Υ��ץ������Ǥ��� +���ץ��������Τ��줾��Υ��ץ����ϡ�1 �Х��ȤΥ٥����ͭ�� +���ץ���󥳡��ɤθ�� 1 �Х��ȤΥǡ���Ĺ�� +�����Ƥ��Υǡ���Ĺ�ǻ��ꤵ�줿�礭���Υǡ�����³������Τǹ�������ޤ� +(�ǡ���Ĺ�ˤϡ��ǡ���Ĺ���Ȥ䥪�ץ���󥳡��ɤϴޤޤ�ޤ���)�� +.PP +�ܥ��ץ������ͤϡ�2 �Ĥ���ˡ�Τ����줫�����ꤵ��ޤ��� +1 ���ܤ���ˡ�ϡ�ñ�˥ǡ�����ľ�ܻ��ꤹ���ΤǤ��� +�ǡ����λ���ˤϡ��ƥ�����ʸ���󤫥�����Ƕ��ڤ�줿 16 �ʿ��ͤ��Ѥ��ޤ��� +�㤨��: +.PP +.nf +option vendor-encapsulated-options + 2:4:AC:11:41:1: + 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31: + 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63; +.fi +.PP +�ܥ��ץ��������ꤹ�� 2 ���ܤ���ˡ�ϡ�DHCP �����Ф� +�٥����ͭ���ץ����Хåե������������Ȥ�����ΤǤ��� +����򤹤�ˤϡ��ʲ��� 4 �ĤΤ��Ȥ򤹤�ɬ�פ�����ޤ�: +���ץ������֤�����������Υ��ץ���������˥��ץ������������ +�������ͤ��꿶�ꡢ�Ǹ�ˤ��Υ��ץ������֤� +.B vendor-encapsulated-options +���ץ����������˻��Ѥ���뤳�Ȥ���ꤷ�ޤ��� +.PP +�٥�����ץ���󤬳�Ǽ����륪�ץ������֤򿷵����������ˤϡ� +\fRoption space\fP ʸ����Ѥ��ޤ�: +.PP +.B option +.B space +.I name +.B ; +.PP +����ʸ��ˤ���ޤǽ񤫤�Ƥ���褦�ˡ� +���� name �ϡ����ץ��������ǻ��Ѥ��뤳�Ȥ��Ǥ��ޤ��� +�㤨��: +.nf + +option space SUNW; +option SUNW.server-address code 2 = ip-address; +option SUNW.server-name code 3 = text; +option SUNW.root-path code 4 = text; + +.fi +���١����ץ������֤ȥ��ץ����ν񼰤���������顢 +�����Υ��ץ������ͤ�������륹�����פ�����Ǥ��� +�����Υ��ץ����򤤤ĻȤ�������ꤹ�뤳�Ȥ��Ǥ��ޤ��� +�㤨�С�2 �Ĥΰۤʤ륯�饹�Υ��饤����Ȥ򰷤������Ȥ��ޤ��礦�� +���Ҥ���Ǽ��������ץ������֤������Ȥäơ��ʲ��Τ褦�ˡ� +���饤����Ȥ��������Ƥ��� vendor-class-identifier ���ץ����˴�Ť��ơ� +�ۤʤ륪�ץ������ͤ�ۤʤ륯�饤����Ȥ����Ф��뤳�Ȥ��Ǥ��ޤ��� +.PP +.nf +class "vendor-classes" { + match option vendor-class-identifier; +} + +option SUNW.server-address 172.17.65.1; +option SUNW.server-name "sundhcp-server17-1"; + +subclass "vendor-classes" "SUNW.Ultra-5_10" { + vendor-option-space SUNW; + option SUNW.root-path "/export/root/sparc"; +} + +subclass "vendor-classes" "SUNW.i86pc" { + vendor-option-space SUNW; + option SUNW.root-path "/export/root/i86pc"; +} +.fi +.PP +�����Ǹ����褦�ˡ��̾�Υ������ץ롼���Ŭ�Ѥ��뤳�Ȥǡ� +�������Х���ͤ򥰥����Х륹�������������Ǥ��� +����Υ��饹�˸�ͭ���ͤ�����������륹�����פ�����Ǥ��ޤ��� +\fBvendor-option-space\fR �����Ȥ����Ȥǡ� +.B vendor-encapsulated-options +���ץ�����������Τˡ�SUNW ���ץ���������Υ��ץ�����Ȥ��褦 +DHCP �����Ф˻ؼ����뤳�Ȥ��Ǥ��ޤ��� +.SH ��Ϣ���� +dhclient.conf(5), dhcp-eval(5), +dhclient(8), RFC2132, RFC2131 +.SH ��� +Internet Systems Consortium DHCP Distribution +�ϡ�Vixie Labs �Ȥη���Τ�Ȥǡ�Ted Lemon �����Ҥ��ޤ����� +�ܥץ��������Ȥλ��ϡ�Internet Systems Consortium ���󶡤��ޤ����� +Internet Systems Consortium �˴ؤ������ϡ� +.B https://www.isc.org +�ˤ���ޤ��� diff --git a/static/netbsd/man5/dhcpcd.conf.5 b/static/netbsd/man5/dhcpcd.conf.5 new file mode 100644 index 00000000..fee7e951 --- /dev/null +++ b/static/netbsd/man5/dhcpcd.conf.5 @@ -0,0 +1,1091 @@ +.\" SPDX-License-Identifier: BSD-2-Clause +.\" +.\" Copyright (c) 2006-2025 Roy Marples +.\" All rights reserved +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.Dd June 12, 2025 +.Dt DHCPCD.CONF 5 +.Os +.Sh NAME +.Nm dhcpcd.conf +.Nd dhcpcd configuration file +.Sh DESCRIPTION +Although +.Nm dhcpcd +can do everything from the command line, there are cases where it's just easier +to do it once in a configuration file. +Most of the options found in +.Xr dhcpcd 8 +can be used here. +The first word on the line is the option and the rest of the line is the value. +Leading and trailing whitespace for the option and value are trimmed. +You can escape characters in the value using the \\ character. +Comments can be prefixed with the # character. +String values should be quoted with the " character. +.Pp +Here's a list of available options: +.Bl -tag -width indent +.It Ic allowinterfaces Ar pattern +When discovering interfaces, the interface name must match +.Ar pattern +which is a space or comma separated list of patterns passed to +.Xr fnmatch 3 . +If the same interface is matched in +.Ic denyinterfaces +then it is still denied. +.It Ic denyinterfaces Ar pattern +When discovering interfaces, the interface name must not match +.Ar pattern +which is a space or comma separated list of patterns passed to +.Xr fnmatch 3 . +.It Ic anonymous +Enables Anonymity Profiles for DHCP, RFC 7844. +Any DUID is ignored and ClientID is set to LL only. +All non essential options are then masked at this point, +but they could be unmasked by explicitly requesting the option +.Sy after +the +.Ic anonymous +option is processed. +As such, the +.Ic anonymous +option +.Sy should +be the last option in the configuration unless you really want to +send something which could identify you. +.Nm dhcpcd +will not try and reboot an old lease, it will go straight into +DISCOVER/SOLICIT. +.It Ic randomise_hwaddr +Forces a hardware address randomisation when the interface is brought up +or when the carrier is lost. +This is generally used in tandem with the anonymous option. +.It Ic arping Ar address Op address +.Nm dhcpcd +will arping each address in order before attempting DHCP. +If an address is found, we will select the replying hardware address as the +profile, otherwise the IP address. +Example: +.Pp +.D1 interface bge0 +.D1 arping 192.168.0.1 +.Pp +.D1 # My specific 192.168.0.1 network +.D1 profile dd:ee:aa:dd:bb:ee +.D1 static ip_address=192.168.0.10/24 +.Pp +.D1 # A generic 192.168.0.1 network +.D1 profile 192.168.0.1 +.D1 static ip_address=192.168.0.98/24 +.It Ic authprotocol Ar protocol Op Ar algorithm Op Ar rdm +Authenticate DHCP messages. +See the Supported Authentication Protocols section. +If +.Ar protocol +is +.Ar token +then +.Ar algorithm is +snd_secretid/rcv_secretid so you can send and receive different tokens. +.It Ic authtoken Ar secretid Ar realm Ar expire Ar key +Define a shared key for use in authentication. +.Ar realm +can be "" to for use with the +.Ar delayed +protocol. +.Ar expire +is the date the token expires and should be formatted "yyy-mm-dd HH:MM". +You can use the keyword +.Ar forever +or +.Ar 0 +which means the token never expires. +For the token protocol, +.Ar secretid +needs to be 0 and +.Ar realm +needs to be "". +If +.Nm dhcpcd +has the error +.D1 dhcp_auth_encode: Invalid argument +then it means that +.Nm dhcpcd +could not find the correct authentication token in your configuration. +.It Ic background +Fork to the background immediately. +This is useful for startup scripts which don't disable link messages for +carrier status. +.It Ic blacklist Ar address Ns Op /cidr +Ignores all packets from +.Ar address Ns Op /cidr . +.It Ic whitelist Ar address Ns Op /cidr +Only accept packets from +.Ar address Ns Op /cidr . +.Ic blacklist +is ignored if +.Ic whitelist +is set. +.It Ic bootp +Be a BOOTP client. +Basically, this just doesn't send a DHCP Message Type option and will only +interact with a BOOTP server. +All other DHCP options still work. +.It Ic broadcast +Instructs the DHCP server to broadcast replies back to the client. +Normally this is only set for non-Ethernet interfaces, +such as FireWire and InfiniBand. +In most cases, +.Nm dhcpcd +will set this automatically. +.It Ic controlgroup Ar group +Sets the group ownership of +.Pa /var/run/dhcpcd/sock +so that users other than root can connect to +.Nm dhcpcd . +.It Ic debug +Echo debug messages to the stderr and syslog. +.It Ic dev Ar value +Load the +.Ar value +.Pa /dev +management module. +.Nm dhcpcd +will load the first one found to work, if any. +.It Ic env Ar value +Push +.Ar value +to the environment for use in +.Xr dhcpcd-run-hooks 8 . +For example, you can force the hostname hook to always set the hostname with +.Ic env +.Va force_hostname=YES . +Or set which driver +.Xr wpa_supplicant 8 +should use with +.Ic env +.Va wpa_supplicant_driver=nl80211 +.Pp +If the hostname is set, it will be will set to the FQDN if possible as per +RFC 4702, section 3.1. +If the FQDN option is missing, +.Nm dhcpcd +will still try and set a FQDN from the hostname and domain options for +consistency. +To override this, set +.Ic env +.Va hostname_fqdn=[YES|NO|SERVER] . +A value of +.Va SERVER +means just what the server says, don't manipulate it. +This could lead to an inconsistent hostname on a DHCPv4 and DHCPv6 network +where the DHCPv4 hostname is short and the DHCPv6 has an FQDN. +DHCPv6 has no hostname option. +.It Ic clientid Ar string +Send the +.Ar clientid . +If the string is of the format 01:02:03 then it is encoded as hex. +For interfaces whose hardware address is longer than 8 bytes, or if the +.Ar clientid +is an empty string then +.Nm dhcpcd +sends a default +.Ar clientid +of the hardware family and the hardware address. +.It Ic duid Op ll | lt | uuid | value +Use a DHCP Unique Identifier. +If persistent storage is available then a DUID-LLT +(link local address + time) is generated, +otherwise DUID-LL is generated (link local address). +The DUID type can be hinted as an optional parameter if the file +.Pa /var/db/dhcpcd/duid +does not exist. +If not +.Va ll , +.Va lt +or +.Va uuid +then +.Va value +will be converted from 00:11:22:33 format. +This, plus the IAID will be used as the +.Ic clientid . +The DUID generated will be held in +.Pa /var/db/dhcpcd/duid +and should not be copied to other hosts. +This file also takes precedence over the above rules except for setting a value. +.It Ic iaid Ar iaid +Set the Interface Association Identifier to +.Ar iaid . +This option must be used in an +.Ic interface +block. +This defaults to the VLANID (prefixed with 0xff) for the interface if set, +otherwise the last 4 bytes of the hardware address assigned to the +interface. +Each instance of this should be unique within the scope of the client and +.Nm dhcpcd +warns if a conflict is detected. +If there is a conflict, it is only a problem if the conflicted IAIDs are +used on the same network. +.It Ic dhcp +Enable DHCP on the interface, on by default. +.It Ic dhcp6 +Enable DHCPv6 on the interface, on by default. +.It Ic ipv4 +Enable IPv4 on the interface, on by default. +.It Ic ipv6 +Enable IPv6 on the interface, on by default. +.It Ic request Op Ar address +Request the +.Ar address +in the DHCP DISCOVER message. +There is no guarantee this is the address the DHCP server will actually give. +If no +.Ar address +is given then the first address currently assigned to the +.Ar interface +is used. +.It Ic inform Op Ar address Ns Op Ar /cidr Ns Op Ar /broadcast_address +Behaves like +.Ic request +as above, but sends a DHCP INFORM instead of DISCOVER/REQUEST. +This does not get a lease as such, just notifies the DHCP server of the +.Ar address +in use. +You should also include the optional +.Ar cidr +network number in case the address is not already configured on the interface. +.Nm dhcpcd +remains running and pretends it has an infinite lease. +.Nm dhcpcd +will not de-configure the interface when it exits. +If +.Nm dhcpcd +fails to contact a DHCP server then it returns a failure instead of falling +back on IPv4LL. +.It Ic inform6 +Performs a DHCPv6 Information Request. +No address is requested or specified, but all other DHCPv6 options are allowed. +This is normally performed automatically when an IPv6 Router Advertisement +indicates that the client should perform this operation. +This option is only needed when +.Nm dhcpcd +is not processing IPv6 RA messages and the need for a DHCPv6 Information Request +exists. +.It Ic persistent +.Nm dhcpcd +normally de-configures the interface and configuration when it exits. +Sometimes, this isn't desirable if, for example, you have root mounted over +NFS or SSH clients connect to this host and they need to be notified of +the host shutting down. +You can use this option to stop this from happening. +.It Ic fallback Ar profile +Fall back to using this profile if DHCP fails. +This allows you to configure a static profile instead of using ZeroConf. +.It Ic fallback_time Ar seconds +Start fallback after +.Ar seconds . +The default is 5 seconds. +.It Ic hostname Ar name +Sends the hostname +.Ar name +to the DHCP server so it can be registered in DNS. +If +.Ar name +is an empty string then the current system hostname is sent. +If +.Ar name +is a FQDN (i.e., contains a .) then it will be encoded as such. +.It Ic hostname_short +Sends the short hostname to the DHCP server instead of the FQDN. +This is useful because DHCP servers will not register the FQDN in their +DNS if the domain part does not match theirs. +.Pp +Also, see the +.Ic env +option above to control how the hostname is set on the host. +.It Ic ia_na Op Ar iaid Op / address +Request a DHCPv6 Normal Address for +.Ar iaid . +.Ar iaid +defaults to the +.Ic iaid +option as described above. +You can request more than one ia_na by specifying a unique +.Ar iaid +for each one. +.It Ic ia_ta Op Ar iaid +Request a DHCPv6 Temporary Address for +.Ar iaid . +You can request more than one ia_ta by specifying a unique +.Ar iaid +for each one. +.It Ic ia_pd Op Ar iaid Oo / Ar prefix / Ar prefix_len Oc Op Ar interface Op / Ar sla_id Op / Ar prefix_len Op / Ar suffix +Request a DHCPv6 Delegated Prefix for +.Ar iaid . +This option must be used in an +.Ic interface +block. +Unless a +.Ar sla_id +of 0 is assigned with the same resultant prefix length as the delegation, +a reject route is installed for the Delegated Prefix to +stop unallocated addresses being resolved upstream. +If no +.Ar interface +is given then we will assign a prefix to every other interface with a +.Ar sla_id +equivalent to the interface index assigned by the OS. +Otherwise addresses are only assigned for each +.Ar interface +and +.Ar sla_id . +To avoid delegating to any interface, use - as the invalid interface name. +Each assigned address will have a +.Ar suffix , +defaulting to 1. +If the +.Ar suffix +is 0 then a SLAAC address is assigned. +You cannot assign a prefix to the requesting interface unless the +DHCPv6 server supports the +.Li RFC 6603 +Prefix Exclude Option. +.Nm dhcpcd +has to be running for all the interfaces it is delegating to. +A default +.Ar prefix_len +of 64 is assumed, unless the maximum +.Ar sla_id +does not fit. +In this case +.Ar prefix_len +is increased to the highest multiple of 8 that can accommodate the +.Ar sla_id . +.Ar sla_id +is an integer which must be unique inside the +.Ar iaid +and is added to the prefix which must fit inside +.Ar prefix_len +less the length of the delegated prefix. +You can specify multiple +.Ar interface / +.Ar sla_id / +.Ar prefix_len +per +.Ic ia_pd , +space separated. +IPv6RS should be disabled globally when requesting a Prefix Delegation. +.Pp +In the following example eth0 is the externally facing interface to be +configured for both IPv4 and IPv6. +The DHCPv4 server will provide us with an IPv4 address and a default route. +The DHCPv6 server is going to provide us with an IPv6 address, a default +route and a /64 subnet to be delegated to the internal interface. +The eth1 interface will be automatically configured +for IPv6 using the first address (::1) from the delegated prefix. +A second prefix is requested and assigned to two other interfaces. +.Xr rtadvd 8 +can be used with an empty configuration file on eth1, eth2 and eth3, +to provide automatic +IPv6 address configuration for the internal network. +.Bd -literal +noipv6rs # disable routing solicitation +denyinterfaces eth2 # Don't touch eth2 at all +interface eth0 + ipv6rs # enable routing solicitation for eth0 + ia_na 1 # request an IPv6 address + ia_pd 2 eth1/0 # request a PD and assign it to eth1 + ia_pd 3 eth2/1 eth3/2 # req a PD and assign it to eth2 and eth3 + ia_pd 4 - # request a PD but don't assign it +.Ed +.It Ic ipv4only +Only configure IPv4. +.It Ic ipv6only +Only configure IPv6. +.It Ic fqdn Op disable | none | ptr | both +.Ar none +will not ask the DHCP server to update DNS. +.Ar ptr +just asks the DHCP server to update the PTR +record of the host in DNS, whereas +.Ar both +also updates the A record. +.Ar disable +will disable the FQDN option. +The default is +.Ar both . +.Nm dhcpcd +itself never does any DNS updates. +.Nm dhcpcd +encodes the FQDN hostname as specified in +.Li RFC 1035 . +.It Ic interface Ar interface +Subsequent options are only parsed for this +.Ar interface . +Pattern matching is allowed by +.Xr fnmatch 3 . +.It Ic ipv4ll_time Ar seconds +Wait for +.Ar seconds +before starting IPv4LL. +The default is 5 seconds. +.It Ic ipv6ra_autoconf +Generate SLAAC addresses for each Prefix advertised by an IPv6 +Router Advertisement message with the Auto flag set. +On by default. +.It Ic ipv6ra_noautoconf +Disables the above option. +.It Ic ipv6ra_fork +By default, when +.Nm dhcpcd +receives an IPv6 Router Advertisement, +.Nm dhcpcd +will only fork to the background if the RA contains at least one unexpired +RDNSS option and a valid prefix or no DHCPv6 instruction. +Set this option so to make +.Nm dhcpcd +always fork on a RA. +.It Ic ipv6rs +Enables IPv6 Router Advertisement solicitation. +This is on by default, but is documented here in the case where it is disabled +globally but needs to be enabled for one interface. +.It Ic lastlease +If +.Nm dhcpcd +cannot obtain a lease, then try to use the last lease acquired for the +interface. +.It Ic lastleaseextend +Same as the above, but the lease will be retained even if it expires. +.Nm dhcpcd +will give it up if any other host tries to claim it for their own via ARP. +This violates RFC 2131, section 3.7, which states the lease should be +dropped once it has expired. +.It Ic leasetime Ar seconds +Request DHCP a lease time of +.Ar seconds . +.Ar -1 +represents an infinite lease time. +By default +.Nm dhcpcd +does not request any lease time and leaves it in the hands of the +DHCP server. +It is not possible to request a DHCPv6 lease time as this is not RFC compliant. +See RFC 8415 21.4, 21.6, 21.21 and 21.22. +.It Ic link_rcvbuf Ar size +Override the size of the link receive buffer from the kernel default. +While +.Nm dhcpcd +will recover from link buffer overflows, +this may not be desirable on heavily loaded systems. +.It Ic logfile Ar logfile +Writes to the specified +.Ar logfile . +.Nm dhcpcd +still writes to +.Xr syslog 3 . +The +.Ar logfile +is reopened when +.Nm dhcpcd +receives the +.Dv SIGUSR2 +signal. +.It Ic metric Ar metric +Metrics are used to prefer an interface over another one, lowest wins. +.Nm dhcpcd +will supply a default metric of 1000 + +.Xr if_nametoindex 3 . +This will be offset by 2000 for wireless interfaces, with additional offsets +of 1000000 for IPv4LL and 2000000 for roaming interfaces. +.It Ic mudurl Ar url +Specifies the URL for a Manufacturer Usage Description (MUD). +The description is used by upstream network devices to instantiate any +desired access lists. +See draft-ietf-opsawg-mud for more information. +.It Ic noalias +Any pre-existing IPv4 addresses will be removed from the interface when +adding a new IPv4 address. +.It Ic noarp +Don't send any ARP requests. +This also disables IPv4LL. +.It Ic arp_persistdefence +Keep the IP address even if defence fails upon IP Address conflict. +.It Ic noauthrequired +Don't require authentication even though we requested it. +Also allows FORCERENEW and RECONFIGURE messages without authentication. +.It Ic nodelay +Don't delay for an initial randomised time when starting protocols. +.It Ic nodev +Don't load +.Pa /dev +management modules. +.It Ic nodhcp +Don't start DHCP or listen to DHCP messages. +This is only useful when allowing IPv4LL. +.It Ic nodhcp6 +Don't start DHCPv6 or listen to DHCPv6 messages. +Normally DHCPv6 is started by an IPv6 Router Advertisement instruction or +configuration. +.It Ic nogateway +Don't install any default routes. +.It Ic gateway +Install a default route if available (default). +.It Ic nohook Ar script +Don't run this hook script. +Matches full name, or prefixed with 2 numbers optionally ending with +.Pa .sh . +.Pp +So to stop +.Nm dhcpcd +from touching your DNS settings or starting wpa_supplicant you would do:- +.D1 nohook resolv.conf, wpa_supplicant +.It Ic noipv4 +Don't attempt to configure an IPv4 address. +.It Ic noipv4ll +Don't attempt to obtain an IPv4LL address if we failed to get one via DHCP. +See +.Rs +.%T "RFC 3927" +.Re +.It Ic noipv6 +Don't solicit or accept IPv6 Router Advertisements and DHCPv6. +.It Ic noipv6rs +Don't solicit or accept IPv6 Router Advertisements. +.It Ic nolink +Don't receive link messages about carrier status. +You should only set this for buggy interface drivers. +.It Ic nosyslog +Disable writing to syslog(3). +.It Ic noup +Don't bring the interface up when in manager mode. +.It Ic option Ar option +Requests the +.Ar option +from the server. +It can be a variable to be used in +.Xr dhcpcd-run-hooks 8 +or the numerical value. +You can specify more +.Ar option Ns s +separated by commas, spaces or more +.Ic option +lines. +Prepend dhcp6_ to +.Ar option +to request a DHCPv6 option. +If no DHCPv6 options are configured, +then DHCPv4 options are mapped to equivalent DHCPv6 options. +.Pp +Prepend nd_ to +.Ar option +to handle ND options, but this only works for the +.Ic nooption , +.Ic reject +and +.Ic require +options. +.Pp +To see a list of options you can use, call +.Nm dhcpcd +with the +.Fl V , Fl Fl variables +argument. +.It Ic nooption Ar option +Remove the option from the message before it's processed. +.It Ic require Ar option +Requires the +.Ar option +to be present in all messages, otherwise the message is ignored. +To enforce that +.Nm dhcpcd +only responds to DHCP servers and not BOOTP servers, you can +.Ic require +.Ar dhcp_message_type . +This isn't an exact science though because a BOOTP server can send DHCP-like +options. +.It Ic reject Ar option +Reject a message that contains the +.Ar option . +This is useful when you cannot use +.Ic require +to select / de-select BOOTP messages. +.It Ic destination Ar option +If +.Nm +detects an address added to a point to point interface (PPP, TUN, etc) then +it will set the listed DHCP options to the destination address of the +interface. +.It Ic profile Ar name +Subsequent options are only parsed for this profile +.Ar name . +.It Ic quiet +Suppress any dhcpcd output to the console, except for errors. +.It Ic reboot Ar seconds +Allow +.Ar reboot +seconds before moving to the DISCOVER phase if we have an old lease to use. +Allow +.Ar reboot +seconds before starting fallback states from the DISCOVER phase. +IPv4LL is started when the first +.Ar reboot +timeout is reached. +The default is 5 seconds. +A setting of 0 seconds causes +.Nm +to skip the reboot phase and go straight into DISCOVER. +This is desirable for mobile users because if you change from network A to +network B and they use the same subnet and the address from network A isn't +in use on network B, then the DHCP server will remain silent even if +authoritative which means +.Nm dhcpcd +will timeout before moving back to the DISCOVER phase. +This has no effect on DHCPv6 other than skipping the reboot phase. +.It Ic release +.Nm dhcpcd +will release the lease prior to stopping the interface. +.It Ic script Ar script +Use +.Ar script +instead of the default +.Pa /libexec/dhcpcd-run-hooks . +.It Ic request_time Ar seconds +Request the lease for +.Ar seconds +before going back to DISCOVER. +The default is 180 seconds. +.It Ic ssid Ar ssid +Subsequent options are only parsed for this wireless +.Ar ssid . +.It Ic slaac Ic hwaddr | Ic private | Ic token Ar token Op Ic temp | Ic temporary +Selects the interface identifier used for SLAAC generated IPv6 addresses. +If +.Ic private +is used, a RFC 7217 address is generated. +If +.Ic token Ar token +is used then the token is combined with the prefix to make the final address. +The +.Ic temporary +directive will create a temporary address for the prefix as well. +.It Ic static Ar value +Configures a static +.Ar value . +If you set +.Ic ip_address +then +.Nm dhcpcd +will not attempt to obtain a lease and will just use the value for the address +with an infinite lease time. +If you set an empty value this removes all prior static allocations to +the same value. +This is useful when using profiles and in the case of +.Ic ip_address +it will remove the static allocation. +Note that setting 0.0.0.0 keeps the static allocation but waits for a 3rdparty +to configure the address. +If you set +.Ic ip6_address , +.Nm dhcpcd +will continue auto-configuration as normal. +.Pp +Here is an example which configures two static address, overriding the default +IPv4 broadcast address, an IPv4 router, DNS and disables IPv6 auto-configuration. +You could also use the +.Ic inform6 +command here if you wished to obtain more information via DHCPv6. +For IPv4, you should use the +.Ic inform Ar ipaddress +option instead of setting a static address. +.D1 interface eth0 +.D1 noipv6rs +.D1 static ip_address=192.168.0.10/24 +.D1 static broadcast_address=192.168.0.63 +.D1 static ip6_address=fd51:42f8:caae:d92e::ff/64 +.D1 static routers=192.168.0.1 +.D1 static domain_name_servers=192.168.0.1 fd51:42f8:caae:d92e::1 +.Pp +Here is an example for PPP which gives the destination a default route. +It uses the special +.Ar destination +keyword to insert the destination address +into the value. +.D1 interface ppp0 +.D1 static ip_address=0.0.0.0 +.D1 destination routers +.It Ic timeout Ar seconds +Time out after +.Ar seconds , +instead of the default 30. +A setting of 0 +.Ar seconds +causes +.Nm dhcpcd +to wait forever to get a lease. +If +.Nm dhcpcd +is working on a single interface then +.Nm dhcpcd +will exit when a timeout occurs, otherwise +.Nm dhcpcd +will fork into the background. +If using IPv4LL then +.Nm dhcpcd +start the IPv4LL process after the timeout and then wait a little longer +before really timing out. +.It Ic userclass Ar string +Tag the DHCPv4 message with the userclass. +You can specify more than one. +.It Ic msuserclass Ar string +Tag the DHCPv4 mesasge with the Microsoft userclass. +Unlike the +.Ic userclass +option, this one can only be added once. +It should only be used for Microsoft DHCP servers and the +.Ic vendorclassid +should be set to "MSFT 98" or "MSFT 5.0". +This option is not RFC compliant. +.It Ic vendor Ar code , Ns Ar value +Add an encapsulated vendor-specific information option (DHCP Option 43). +.Ar code +should be between 1 and 254 inclusive. +To add a raw vendor string, omit +.Ar code +but keep the comma. +Examples. +.Pp +Set the vendor option 01 with an IP address. +.D1 vendor 01,192.168.0.2 +Set the vendor option 02 with a hex code. +.D1 vendor 02,01:02:03:04:05 +Set the vendor option 03 with an IP address as a string. +.D1 vendor 03,\e"192.168.0.2\e" +Set un-encapsulated vendor option to hello world. +.D1 vendor ,"hello world" +.It Ic vsio Ar en Ar code, Ns Ar value +Add an encapsulated vendor-specific information option (DHCP Option 125) with +IANA assigned Enterprise Number +.Ar en +proceeding with the +.Ar code +which should be between 1 and 255 inclusive, and the +.Ar value +after the comma. +Examples: +.Pp +Set the vsio for enterprise number 155 option 01 with an IPv4 address. +.D1 vsio 155 01,192.168.1.1 +Set the vsio for enterprise number 155 option 02 with a string. +.D1 vsio 155 02,"hello world" +Set the vsio for enterprise number 255 option 01 with a hex code. +.D1 vsio 255 01,01:02:03:04:05 +.It Ic vsio6 Ar en Ar code, Ns Ar value +Add an encapsulated vendor-specific information option (DHCPv6 Option 17) with +IANA assigned Enterprise Number +.Ar en +proceeding with the +.Ar code +which should be between 1 and 65535 inclusive, and the +.Ar value +after the comma. +Examples: +.Pp +Set the vsio for enterprise number 155 option 01 with an IPv6 address. +.D1 vsio6 155 01,2001:0db8:85a3:0000:0000:8a2e:0370:7334 +Set the vsio for enterprise number 155 option 02 with a string. +.D1 vsio6 155 02,"hello world" +Set the vsio for enterprise number 255 option 01 with a hex code. +.D1 vsio6 255 01,01:02:03:04:05 +.It Ic vendorclassid Ar string +Set the DHCP Vendor Class. +DHCPv6 has its own option as shown below. +The default is +dhcpcd-:::. +For example +.D1 dhcpcd-5.5.6:NetBSD-6.99.5:i386:i386 +If not set then none is sent. +Some badly configured DHCP servers reject unknown vendorclassids. +To work around it, try and impersonate Windows by using the MSFT vendorclassid. +.It Ic vendclass Ar en Ar data +Add the DHCPv6 Vendor Indetifying Vendor Class with the IANA assigned Enterprise +Number +.Ar en +with the +.Ar data . +This option can be set more than once to add more data, but the behaviour, +as per RFC 3925 is undefined if the Enterprise Number differs. +.It Ic waitip Op 4 | 6 +Wait for an address to be assigned before forking to the background. +4 means wait for an IPv4 address to be assigned. +6 means wait for an IPv6 address to be assigned. +If no argument is given, +.Nm +will wait for any address protocol to be assigned. +It is possible to wait for more than one address protocol and +.Nm +will only fork to the background when all waiting conditions are satisfied. +.It Ic xidhwaddr +Use the last four bytes of the hardware address as the DHCP xid instead +of a randomly generated number. +.El +.Ss Defining new options +DHCP, ND and DHCPv6 allow for the use of custom options, and RFC 3925 vendor +options for DHCP can also be supplied. +Each option needs to be started with the +.Ic define , +.Ic definend , +.Ic define6 +or +.Ic vendopt +directive. +This can optionally be followed by both +.Ic embed +or +.Ic encap +options. +Both can be specified more than once and +.Ic embed +must come before +.Ic encap . +.Bl -tag -width indent +.It Ic define Ar code Ar type Ar variable +Defines the DHCP option +.Ar code +of +.Ar type +with a name of +.Ar variable +exported to +.Xr dhcpcd-run-hooks 8 . +.It Ic definend Ar code Ar type Ar variable +Defines the ND option +.Ar code +of +.Ar type +with a name of +.Ar variable +exported to +.Xr dhcpcd-run-hooks 8 , +with a prefix of +.Va nd_ . +.It Ic define6 Ar code Ar type Ar variable +Defines the DHCPv6 option +.Ar code +of +.Ar type +with a name of +.Ar variable +exported to +.Xr dhcpcd-run-hooks 8 , +with a prefix of +.Va dhcp6_ . +.It Ic vendopt Ar code Ar type Ar variable +Defines the Vendor-Identifying Vendor Options. +The +.Ar code +is the IANA Enterprise Number which will uniquely describe the encapsulated +options. +.Ar type +is normally +.Ar encap . +.Ar variable +names the Vendor option to be exported. +.It Ic embed Ar type Ar variable +Defines an embedded variable within the defined option. +The length is determined by the +.Ar type . +If the +.Ar variable +is not the same as defined in the parent option, +it is prefixed with the parent +.Ar variable +first with an underscore. +If the +.Ar variable +has the name of +.Ar reserved +then it is not processed. +.It Ic encap Ar code Ar type Ar variable +Defines an encapsulated variable within the defined option. +The length is determined by the +.Ar type . +If the +.Ar variable +is not the same as defined in the parent option, +it is prefixed with the parent +.Ar variable +first with an underscore. +.El +.Ss Type prefix +These keywords come before the type itself, to describe it more fully. +You can use more than one, but they must appear in the order listed below. +.Bl -tag -width -indent +.It Ic request +Requests the option by default without having to be specified in user +configuration. +.It Ic norequest +This option cannot be requested, regardless of user configuration. +.It Ic optional +This option is optional. +Only makes sense for embedded options like the client FQDN option, where +the FQDN string itself is optional. +.It Ic index +The option can appear more than once and will be indexed. +.It Ic array +The option data is split into a space separated array, each element being +the same type. +.It Ic truncated +The option might truncated from its normal length. +The end of the normal size is zero padded on expansion. +Currently this is only supported for ip6address where it's a prefix. +.El +.Ss Types to define +The type directly affects the length of data consumed inside the option. +Any remaining data is normally discarded. +Lengths can be specified for string and binhex types, but this is generally +with other data embedded afterwards in the same option. +.Bl -tag -width indent +.It Ic ipaddress +An IPv4 address, 4 bytes. +.It Ic ip6address +An IPv6 address, 16 bytes. +.It Ic string Op : Ic length +A NVT ASCII string of printable characters. +.It Ic byte +A byte. +.It Ic bitflags : Ic flags +A byte represented as a string of flags, most significant bit first. +For example, using ABCDEFGH then A would equal 10000000, B 01000000, +C 00100000, etc. +If the bit is not set, the flag is not printed. +A flag of 0 is not printed even if the bit position is set. +This is to allow reservation of the first bits while assigning the last bits. +A flag of 1 prints the bit set or unset. +.It Ic int16 +A signed 16bit integer, 2 bytes. +.It Ic uint16 +An unsigned 16bit integer, 2 bytes. +.It Ic int32 +A signed 32bit integer, 4 bytes. +.It Ic uint32 +An unsigned 32bit integer, 4 bytes. +.It Ic flag +A fixed value (1) to indicate that the option is present, 0 bytes. +.It Ic domain +An RFC 3397 encoded string. +.It Ic dname +An RFC 1035 validated string. +.It Ic uri +If an array then the first two bytes are the URI length inside the option data. +Otherwise, the whole option data is the URI. +As a space is not allowed in the URI encoding, the URIs are space separated. +.It Ic binhex Op : Ic length +Binary data expressed as hexadecimal. +.It Ic embed +Contains embedded options (implies encap as well). +.It Ic encap +Contains encapsulated options (implies embed as well). +.It Ic option +References an option from the global definition. +.El +.Ss Example definition +.D1 # DHCP option 81, Fully Qualified Domain Name, RFC 4702 +.D1 define 81 embed fqdn +.D1 embed byte flags +.D1 embed byte rcode1 +.D1 embed byte rcode2 +.D1 embed domain fqdn +.Pp +.D1 # DHCP option 125, Vendor Specific Information Option, RFC 3925 +.D1 define 125 encap vsio +.D1 embed uint32 enterprise_number +.D1 # Options defined for the enterprise number +.D1 encap 1 ipaddress ipaddress +.Ss Supported Authentication Protocols +.Bl -tag -width -indent +.It Ic token +Sends a plain text token the server expects and matches a token sent by +the server. +The tokens do not have to be the same. +If unspecified, the token with a +.Ar secretid +of 0 will be used in sending messages +and validating received messages. +.It Ic delayedrealm +Delayed Authentication. +.Nm dhcpcd +will send an authentication option with no key or MAC. +The server will see this option, and select a key for +.Nm , writing the +.Ar realm +and +.Ar secretid +in it. +.Nm dhcpcd +will then look for an unexpired token with a matching +.Ar realm +and +.Ar secretid . +This token is used to authenticate all other messages. +.It Ic delayed +Same as above, but without a realm. +.El +.Ss Supported Authentication Algorithms +If none specified, +.Ic hmac-md5 +is the default. +.Bl -tag -width -indent +.It Ic hmac-md5 +.El +.Ss Supported Replay Detection Mechanisms +If none specified, +.Ic monotonic +is the default. +If this is changed from what was previously used, +or the means of calculating or storing it is broken, then the DHCP server +will probably have to have its notion of the client's Replay Detection Value +reset. +.Bl -tag -width -indent +.It Ic monocounter +Read the number in the file +.Pa /var/db/dhcpcd/dhcpcd-rdm.monotonic +and add one to it. +.It Ic monotime +Create an NTP timestamp from the system time. +.It Ic monotonic +Same as +.Ic monotime . +.El +.Sh SEE ALSO +.Xr fnmatch 3 , +.Xr if_nametoindex 3 , +.Xr dhcpcd 8 , +.Xr dhcpcd-run-hooks 8 +.Sh AUTHORS +.An Roy Marples Aq Mt roy@marples.name +.Sh BUGS +Please report them to +.Lk https://roy.marples.name/projects/dhcpcd diff --git a/static/netbsd/man5/dhcpd.conf.5 b/static/netbsd/man5/dhcpd.conf.5 new file mode 100644 index 00000000..ec57eb81 --- /dev/null +++ b/static/netbsd/man5/dhcpd.conf.5 @@ -0,0 +1,3672 @@ +.\" $NetBSD: dhcpd.conf.5,v 1.4 2022/04/03 01:10:59 christos Exp $ +.\" +.\" dhcpd.conf.5 +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" This Source Code Form is subject to the terms of the Mozilla Public +.\" License, v. 2.0. If a copy of the MPL was not distributed with this +.\" file, You can obtain one at http://mozilla.org/MPL/2.0/. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. +.\" +.\" Support and other services are available for ISC products - see +.\" https://www.isc.org for more information or to learn more about ISC. +.\" +.\" Id: dhcpd.conf.5,v 1.114 2012/04/02 22:47:35 sar Exp +.\" +.TH dhcpd.conf 5 +.SH NAME +dhcpd.conf - dhcpd configuration file +.SH DESCRIPTION +The dhcpd.conf file contains configuration information for +.IR dhcpd, +the Internet Systems Consortium DHCP Server. +.PP +The dhcpd.conf file is a free-form ASCII text file. It is parsed by +the recursive-descent parser built into dhcpd. The file may contain +extra tabs and newlines for formatting purposes. Keywords in the file +are case-insensitive. Comments may be placed anywhere within the +file (except within quotes). Comments begin with the # character and +end at the end of the line. +.PP +The file essentially consists of a list of statements. Statements +fall into two broad categories - parameters and declarations. +.PP +Parameter statements either say how to do something (e.g., how long a +lease to offer), whether to do something (e.g., should dhcpd provide +addresses to unknown clients), or what parameters to provide to the +client (e.g., use gateway 220.177.244.7). +.PP +Declarations are used to describe the topology of the +network, to describe clients on the network, to provide addresses that +can be assigned to clients, or to apply a group of parameters to a +group of declarations. In any group of parameters and declarations, +all parameters must be specified before any declarations which depend +on those parameters may be specified. +.PP +Declarations about network topology include the \fIshared-network\fR +and the \fIsubnet\fR declarations. If clients on a subnet are to be +assigned addresses +dynamically, a \fIrange\fR declaration must appear within the +\fIsubnet\fR declaration. For clients with statically assigned +addresses, or for installations where only known clients will be +served, each such client must have a \fIhost\fR declaration. If +parameters are to be applied to a group of declarations which are not +related strictly on a per-subnet basis, the \fIgroup\fR declaration +can be used. +.PP +For every subnet which will be served, and for every subnet +to which the dhcp server is connected, there must be one \fIsubnet\fR +declaration, which tells dhcpd how to recognize that an address is on +that subnet. A \fIsubnet\fR declaration is required for each subnet +even if no addresses will be dynamically allocated on that subnet. +.PP +Some installations have physical networks on which more than one IP +subnet operates. For example, if there is a site-wide requirement +that 8-bit subnet masks be used, but a department with a single +physical ethernet network expands to the point where it has more than +254 nodes, it may be necessary to run two 8-bit subnets on the same +ethernet until such time as a new physical network can be added. In +this case, the \fIsubnet\fR declarations for these two networks must be +enclosed in a \fIshared-network\fR declaration. +.PP +Note that even when the \fIshared-network\fR declaration is absent, an +empty one is created by the server to contain the \fIsubnet\fR (and any scoped +parameters included in the \fIsubnet\fR). For practical purposes, this means +that "stateless" DHCP clients, which are not tied to addresses (and therefore +subnets) will receive the same configuration as stateful ones. +.PP +Some sites may have departments which have clients on more than one +subnet, but it may be desirable to offer those clients a uniform set +of parameters which are different than what would be offered to +clients from other departments on the same subnet. For clients which +will be declared explicitly with \fIhost\fR declarations, these +declarations can be enclosed in a \fIgroup\fR declaration along with +the parameters which are common to that department. For clients +whose addresses will be dynamically assigned, class declarations and +conditional declarations may be used to group parameter assignments +based on information the client sends. +.PP +When a client is to be booted, its boot parameters are determined by +consulting that client's \fIhost\fR declaration (if any), and then +consulting any \fIclass\fR declarations matching the client, +followed by the \fIpool\fR, \fIsubnet\fR and \fIshared-network\fR +declarations for the IP address assigned to the client. Each of +these declarations itself appears within a lexical scope, and all +declarations at less specific lexical scopes are also consulted for +client option declarations. Scopes are never considered +twice, and if parameters are declared in more than one scope, the +parameter declared in the most specific scope is the one that is +used. +.PP +When dhcpd tries to find a \fIhost\fR declaration for a client, it +first looks for a \fIhost\fR declaration which has a +\fIfixed-address\fR declaration that lists an IP address that is valid +for the subnet or shared network on which the client is booting. If +it doesn't find any such entry, it tries to find an entry which has +no \fIfixed-address\fR declaration. +.SH EXAMPLES +.PP +A typical dhcpd.conf file will look something like this: +.nf + +.I global parameters... + +subnet 204.254.239.0 netmask 255.255.255.224 { + \fIsubnet-specific parameters...\fR + range 204.254.239.10 204.254.239.30; +} + +subnet 204.254.239.32 netmask 255.255.255.224 { + \fIsubnet-specific parameters...\fR + range 204.254.239.42 204.254.239.62; +} + +subnet 204.254.239.64 netmask 255.255.255.224 { + \fIsubnet-specific parameters...\fR + range 204.254.239.74 204.254.239.94; +} + +group { + \fIgroup-specific parameters...\fR + host zappo.test.isc.org { + \fIhost-specific parameters...\fR + } + host beppo.test.isc.org { + \fIhost-specific parameters...\fR + } + host harpo.test.isc.org { + \fIhost-specific parameters...\fR + } +} + +.ce 1 +Figure 1 + +.fi +.PP +Notice that at the beginning of the file, there's a place +for global parameters. These might be things like the organization's +domain name, the addresses of the name servers (if they are common to +the entire organization), and so on. So, for example: +.nf + + option domain-name "isc.org"; + option domain-name-servers ns1.isc.org, ns2.isc.org; + +.ce 1 +Figure 2 +.fi +.PP +As you can see in Figure 2, you can specify host addresses in +parameters using their domain names rather than their numeric IP +addresses. If a given hostname resolves to more than one IP address +(for example, if that host has two ethernet interfaces), then where +possible, both addresses are supplied to the client. +.PP +The most obvious reason for having subnet-specific parameters as +shown in Figure 1 is that each subnet, of necessity, has its own +router. So for the first subnet, for example, there should be +something like: +.nf + + option routers 204.254.239.1; +.fi +.PP +Note that the address here is specified numerically. This is not +required - if you have a different domain name for each interface on +your router, it's perfectly legitimate to use the domain name for that +interface instead of the numeric address. However, in many cases +there may be only one domain name for all of a router's IP addresses, and +it would not be appropriate to use that name here. +.PP +In Figure 1 there is also a \fIgroup\fR statement, which provides +common parameters for a set of three hosts - zappo, beppo and harpo. +As you can see, these hosts are all in the test.isc.org domain, so it +might make sense for a group-specific parameter to override the domain +name supplied to these hosts: +.nf + + option domain-name "test.isc.org"; +.fi +.PP +Also, given the domain they're in, these are probably test machines. +If we wanted to test the DHCP leasing mechanism, we might set the +lease timeout somewhat shorter than the default: + +.nf + max-lease-time 120; + default-lease-time 120; +.fi +.PP +You may have noticed that while some parameters start with the +\fIoption\fR keyword, some do not. Parameters starting with the +\fIoption\fR keyword correspond to actual DHCP options, while +parameters that do not start with the option keyword either control +the behavior of the DHCP server (e.g., how long a lease dhcpd will +give out), or specify client parameters that are not optional in the +DHCP protocol (for example, server-name and filename). +.PP +In Figure 1, each host had \fIhost-specific parameters\fR. These +could include such things as the \fIhostname\fR option, the name of a +file to upload (the \fIfilename\fR parameter) and the address of the +server from which to upload the file (the \fInext-server\fR +parameter). In general, any parameter can appear anywhere that +parameters are allowed, and will be applied according to the scope in +which the parameter appears. +.PP +Imagine that you have a site with a lot of NCD X-Terminals. These +terminals come in a variety of models, and you want to specify the +boot files for each model. One way to do this would be to have host +declarations for each server and group them by model: +.nf + +group { + filename "Xncd19r"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } + host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } + host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } +} + +group { + filename "Xncd19c"; + next-server ncd-booter; + + host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } + host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } +} + +group { + filename "XncdHMX"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } + host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } + host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } +} +.fi +.SH ADDRESS POOLS +.PP +The +\fBpool\fR and \fBpool6\fR +declarations can be used to specify a pool of addresses that will be +treated differently than another pool of addresses, even on the same +network segment or subnet. For example, you may want to provide a +large set of addresses that can be assigned to DHCP clients that are +registered to your DHCP server, while providing a smaller set of +addresses, possibly with short lease times, that are available for +unknown clients. If you have a firewall, you may be able to arrange +for addresses from one pool to be allowed access to the Internet, +while addresses in another pool are not, thus encouraging users to +register their DHCP clients. To do this, you would set up a pair of +pool declarations: +.PP +.nf +subnet 10.0.0.0 netmask 255.255.255.0 { + option routers 10.0.0.254; + + # Unknown clients get this pool. + pool { + option domain-name-servers bogus.example.com; + max-lease-time 300; + range 10.0.0.200 10.0.0.253; + allow unknown-clients; + } + + # Known clients get this pool. + pool { + option domain-name-servers ns1.example.com, ns2.example.com; + max-lease-time 28800; + range 10.0.0.5 10.0.0.199; + deny unknown-clients; + } +} +.fi +.PP +It is also possible to set up entirely different subnets for known and +unknown clients - address pools exist at the level of shared networks, +so address ranges within pool declarations can be on different +subnets. +.PP +As you can see in the preceding example, pools can have permit lists +that control which clients are allowed access to the pool and which +aren't. Each entry in a pool's permit list is introduced with the +.I allow +or \fIdeny\fR keyword. If a pool has a permit list, then only those +clients that match specific entries on the permit list will be +eligible to be assigned addresses from the pool. If a pool has a +deny list, then only those clients that do not match any entries on +the deny list will be eligible. If both permit and deny lists exist +for a pool, then only clients that match the permit list and do not +match the deny list will be allowed access. +.PP +The \fBpool6\fR declaration is similar to the \fBpool\fR declaration. +Currently it is only allowed within a \fBsubnet6\fR declaration, and +may not be included directly in a shared network declaration. +In addition to the \fBrange6\fR statement it allows the \fBprefix6\fR +statement to be included. You may include \fBrange6\fR statements +for both NA and TA and \fBprefix6\fR statements in a single +\fBpool6\fR statement. +.SH DYNAMIC ADDRESS ALLOCATION +Address allocation is actually only done when a client is in the INIT +state and has sent a DHCPDISCOVER message. If the client thinks it +has a valid lease and sends a DHCPREQUEST to initiate or renew that +lease, the server has only three choices - it can ignore the +DHCPREQUEST, send a DHCPNAK to tell the client it should stop using +the address, or send a DHCPACK, telling the client to go ahead and use +the address for a while. +.PP +If the server finds the address the client is requesting, and that +address is available to the client, the server will send a DHCPACK. +If the address is no longer available, or the client isn't permitted +to have it, the server will send a DHCPNAK. If the server knows +nothing about the address, it will remain silent, unless the address +is incorrect for the network segment to which the client has been +attached and the server is authoritative for that network segment, in +which case the server will send a DHCPNAK even though it doesn't know +about the address. +.PP +There may be a host declaration matching the client's identification. +If that host declaration contains a fixed-address declaration that +lists an IP address that is valid for the network segment to which the +client is connected, the DHCP server will never do dynamic address allocation. +In this case, the client is \fIrequired\fR to take the address specified +in the host declaration. If the client sends a DHCPREQUEST for some other +address, the server will respond with a DHCPNAK. +.PP +When the DHCP server allocates a new address for a client (remember, +this only happens if the client has sent a DHCPDISCOVER), it first +looks to see if the client already has a valid lease on an IP address, +or if there is an old IP address the client had before that hasn't yet +been reassigned. In that case, the server will take that address and +check it to see if the client is still permitted to use it. If the +client is no longer permitted to use it, the lease is freed if the +server thought it was still in use - the fact that the client has sent +a DHCPDISCOVER proves to the server that the client is no longer using +the lease. +.PP +If no existing lease is found, or if the client is forbidden to +receive the existing lease, then the server will look in the list of +address pools for the network segment to which the client is attached +for a lease that is not in use and that the client is permitted to +have. It looks through each pool declaration in sequence (all +.I range +declarations that appear outside of pool declarations are grouped into +a single pool with no permit list). If the permit list for the pool +allows the client to be allocated an address from that pool, the pool +is examined to see if there is an address available. If so, then the +client is tentatively assigned that address. Otherwise, the next +pool is tested. If no addresses are found that can be assigned to +the client, no response is sent to the client. +.PP +If an address is found that the client is permitted to have, and that +has never been assigned to any client before, the address is +immediately allocated to the client. If the address is available for +allocation but has been previously assigned to a different client, the +server will keep looking in hopes of finding an address that has never +before been assigned to a client. +.PP +The DHCP server generates the list of available IP addresses from a +hash table. This means that the addresses are not sorted in any +particular order, and so it is not possible to predict the order in +which the DHCP server will allocate IP addresses. Users of previous +versions of the ISC DHCP server may have become accustomed to the DHCP +server allocating IP addresses in ascending order, but this is no +longer possible, and there is no way to configure this behavior with +version 3 of the ISC DHCP server. +.SH IP ADDRESS CONFLICT PREVENTION +The DHCP server checks IP addresses to see if they are in use before +allocating them to clients. It does this by sending an ICMP Echo +request message to the IP address being allocated. If no ICMP Echo +reply is received within a second, the address is assumed to be free. +This is only done for leases that have been specified in range +statements, and only when the lease is thought by the DHCP server to +be free - i.e., the DHCP server or its failover peer has not listed +the lease as in use. +.PP +If a response is received to an ICMP Echo request, the DHCP server +assumes that there is a configuration error - the IP address is in use +by some host on the network that is not a DHCP client. It marks the +address as abandoned, and will not assign it to clients. The lease will +remain abandoned for a minimum of abandon-lease-time seconds. +.PP +If a DHCP client tries to get an IP address, but none are available, +but there are abandoned IP addresses, then the DHCP server will +attempt to reclaim an abandoned IP address. It marks one IP address +as free, and then does the same ICMP Echo request check described +previously. If there is no answer to the ICMP Echo request, the +address is assigned to the client. +.PP +The DHCP server does not cycle through abandoned IP addresses if the +first IP address it tries to reclaim is free. Rather, when the next +DHCPDISCOVER comes in from the client, it will attempt a new +allocation using the same method described here, and will typically +try a new IP address. +.SH DHCP FAILOVER +This version of the ISC DHCP server supports the DHCP failover +protocol as documented in draft-ietf-dhc-failover-12.txt. This is +not a final protocol document, and we have not done interoperability +testing with other vendors' implementations of this protocol, so you +must not assume that this implementation conforms to the standard. +If you wish to use the failover protocol, make sure that both failover +peers are running the same version of the ISC DHCP server. +.PP +The failover protocol allows two DHCP servers (and no more than two) +to share a common address pool. Each server will have about half of +the available IP addresses in the pool at any given time for +allocation. If one server fails, the other server will continue to +renew leases out of the pool, and will allocate new addresses out of +the roughly half of available addresses that it had when +communications with the other server were lost. +.PP +It is possible during a prolonged failure to tell the remaining server +that the other server is down, in which case the remaining server will +(over time) reclaim all the addresses the other server had available +for allocation, and begin to reuse them. This is called putting the +server into the PARTNER-DOWN state. +.PP +You can put the server into the PARTNER-DOWN state either by using the +.B omshell (1) +command or by stopping the server, editing the last failover state +declaration in the lease file, and restarting the server. If you use +this last method, change the "my state" line to: +.PP +.nf +.B failover peer "\fIname\fB" state { +.B my state partner-down;. +.B peer state \fIstate\fB at \fIdate\fB; +.B } +.fi +.PP +It is only required to change "my state" as shown above. +.PP +When the other server comes back online, it should automatically +detect that it has been offline and request a complete update from the +server that was running in the PARTNER-DOWN state, and then both +servers will resume processing together. +.PP +It is possible to get into a dangerous situation: if you put one +server into the PARTNER-DOWN state, and then *that* server goes down, +and the other server comes back up, the other server will not know +that the first server was in the PARTNER-DOWN state, and may issue +addresses previously issued by the other server to different clients, +resulting in IP address conflicts. Before putting a server into +PARTNER-DOWN state, therefore, make +.I sure +that the other server will not restart automatically. +.PP +The failover protocol defines a primary server role and a secondary +server role. There are some differences in how primaries and +secondaries act, but most of the differences simply have to do with +providing a way for each peer to behave in the opposite way from the +other. So one server must be configured as primary, and the other +must be configured as secondary, and it doesn't matter too much which +one is which. +.SH FAILOVER STARTUP +When a server starts that has not previously communicated with its +failover peer, it must establish communications with its failover peer +and synchronize with it before it can serve clients. This can happen +either because you have just configured your DHCP servers to perform +failover for the first time, or because one of your failover servers +has failed catastrophically and lost its database. +.PP +The initial recovery process is designed to ensure that when one +failover peer loses its database and then resynchronizes, any leases +that the failed server gave out before it failed will be honored. +When the failed server starts up, it notices that it has no saved +failover state, and attempts to contact its peer. +.PP +When it has established contact, it asks the peer for a complete copy +its peer's lease database. The peer then sends its complete database, +and sends a message indicating that it is done. The failed server +then waits until MCLT has passed, and once MCLT has passed both +servers make the transition back into normal operation. This waiting +period ensures that any leases the failed server may have given out +while out of contact with its partner will have expired. +.PP +While the failed server is recovering, its partner remains in the +partner-down state, which means that it is serving all clients. The +failed server provides no service at all to DHCP clients until it has +made the transition into normal operation. +.PP +In the case where both servers detect that they have never before +communicated with their partner, they both come up in this recovery +state and follow the procedure we have just described. In this case, +no service will be provided to DHCP clients until MCLT has expired. +.SH CONFIGURING FAILOVER +In order to configure failover, you need to write a peer declaration +that configures the failover protocol, and you need to write peer +references in each pool declaration for which you want to do +failover. You do not have to do failover for all pools on a given +network segment. You must not tell one server it's doing failover +on a particular address pool and tell the other it is not. You must +not have any common address pools on which you are not doing +failover. A pool declaration that utilizes failover would look like this: +.PP +.nf +pool { + failover peer "foo"; + \fIpool specific parameters\fR +}; +.fi +.PP +The server currently does very little sanity checking, so if you +configure it wrong, it will just fail in odd ways. I would recommend +therefore that you either do failover or don't do failover, but don't +do any mixed pools. Also, use the same master configuration file for +both servers, and have a separate file that contains the peer +declaration and includes the master file. This will help you to avoid +configuration mismatches. As our implementation evolves, this will +become less of a problem. A basic sample dhcpd.conf file for a +primary server might look like this: +.PP +.nf +failover peer "foo" { + primary; + address anthrax.rc.example.com; + port 519; + peer address trantor.rc.example.com; + peer port 520; + max-response-delay 60; + max-unacked-updates 10; + mclt 3600; + split 128; + load balance max seconds 3; +} + +include "/etc/dhcpd.master"; +.fi +.PP +The statements in the peer declaration are as follows: +.PP +The +.I primary +and +.I secondary +statements +.RS 0.25i +.PP +[ \fBprimary\fR | \fBsecondary\fR ]\fB;\fR +.PP +This determines whether the server is primary or secondary, as +described earlier under DHCP FAILOVER. +.RE +.PP +The +.I address +statement +.RS 0.25i +.PP +.B address \fIaddress\fR\fB;\fR +.PP +The \fBaddress\fR statement declares the IP address or DNS name on which the +server should listen for connections from its failover peer, and also the +value to use for the DHCP Failover Protocol server identifier. Because this +value is used as an identifier, it may not be omitted. +.RE +.PP +The +.I peer address +statement +.RS 0.25i +.PP +.B peer address \fIaddress\fR\fB;\fR +.PP +The \fBpeer address\fR statement declares the IP address or DNS name to +which the server should connect to reach its failover peer for failover +messages. +.RE +.PP +The +.I port +statement +.RS 0.25i +.PP +.B port \fIport-number\fR\fB;\fR +.PP +The \fBport\fR statement declares the TCP port on which the server +should listen for connections from its failover peer. This statement +may be omitted, in which case the IANA assigned port number 647 will be +used by default. +.RE +.PP +The +.I peer port +statement +.RS 0.25i +.PP +.B peer port \fIport-number\fR\fB;\fR +.PP +The \fBpeer port\fR statement declares the TCP port to which the +server should connect to reach its failover peer for failover +messages. This statement may be omitted, in which case the IANA +assigned port number 647 will be used by default. +.RE +.PP +The +.I max-response-delay +statement +.RS 0.25i +.PP +.B max-response-delay \fIseconds\fR\fB;\fR +.PP +The \fBmax-response-delay\fR statement tells the DHCP server how +many seconds may pass without receiving a message from its failover +peer before it assumes that connection has failed. This number +should be small enough that a transient network failure that breaks +the connection will not result in the servers being out of +communication for a long time, but large enough that the server isn't +constantly making and breaking connections. This parameter must be +specified. +.RE +.PP +The +.I max-unacked-updates +statement +.RS 0.25i +.PP +.B max-unacked-updates \fIcount\fR\fB;\fR +.PP +The \fBmax-unacked-updates\fR statement tells the remote DHCP server how +many BNDUPD messages it can send before it receives a BNDACK +from the local system. We don't have enough operational experience +to say what a good value for this is, but 10 seems to work. This +parameter must be specified. +.RE +.PP +The +.I mclt +statement +.RS 0.25i +.PP +.B mclt \fIseconds\fR\fB;\fR +.PP +The \fBmclt\fR statement defines the Maximum Client Lead Time. It +must be specified on the primary, and may not be specified on the +secondary. This is the length of time for which a lease may be +renewed by either failover peer without contacting the other. The +longer you set this, the longer it will take for the running server to +recover IP addresses after moving into PARTNER-DOWN state. The +shorter you set it, the more load your servers will experience when +they are not communicating. A value of something like 3600 is +probably reasonable, but again bear in mind that we have no real +operational experience with this. +.RE +.PP +The +.I split +statement +.RS 0.25i +.PP +.B split \fIbits\fR\fB;\fR +.PP +The split statement specifies the split between the primary and +secondary for the purposes of load balancing. Whenever a client +makes a DHCP request, the DHCP server runs a hash on the client +identification, resulting in value from 0 to 255. This is used as +an index into a 256 bit field. If the bit at that index is set, +the primary is responsible. If the bit at that index is not set, +the secondary is responsible. The \fBsplit\fR value determines +how many of the leading bits are set to one. So, in practice, higher +split values will cause the primary to serve more clients than the +secondary. Lower split values, the converse. Legal values are between +0 and 256 inclusive, of which the most reasonable is 128. Note that +a value of 0 makes the secondary responsible for all clients and a value +of 256 makes the primary responsible for all clients. +.RE +.PP +The +.I hba +statement +.RS 0.25i +.PP +.B hba \fIcolon-separated-hex-list\fB;\fR +.PP +The hba statement specifies the split between the primary and +secondary as a bitmap rather than a cutoff, which theoretically allows +for finer-grained control. In practice, there is probably no need +for such fine-grained control, however. An example hba statement: +.PP +.nf + hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: + 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00; +.fi +.PP +This is equivalent to a \fBsplit 128;\fR statement, and identical. The +following two examples are also equivalent to a \fBsplit\fR of 128, but +are not identical: +.PP +.nf + hba aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa: + aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa; + + hba 55:55:55:55:55:55:55:55:55:55:55:55:55:55:55:55: + 55:55:55:55:55:55:55:55:55:55:55:55:55:55:55:55; +.fi +.PP +They are equivalent, because half the bits are set to 0, half are set to +1 (0xa and 0x5 are 1010 and 0101 binary respectively) and consequently this +would roughly divide the clients equally between the servers. They are not +identical, because the actual peers this would load balance to each server +are different for each example. +.PP +You must only have \fBsplit\fR or \fBhba\fR defined, never both. For most +cases, the fine-grained control that \fBhba\fR offers isn't necessary, and +\fBsplit\fR should be used. +.RE +.PP +The +.I load balance max seconds +statement +.RS 0.25i +.PP +.B load balance max seconds \fIseconds\fR\fB;\fR +.PP +This statement allows you to configure a cutoff after which load +balancing is disabled. The cutoff is based on the number of seconds +since the client sent its first DHCPDISCOVER or DHCPREQUEST message, +and only works with clients that correctly implement the \fIsecs\fR +field - fortunately most clients do. We recommend setting this to +something like 3 or 5. The effect of this is that if one of the +failover peers gets into a state where it is responding to failover +messages but not responding to some client requests, the other +failover peer will take over its client load automatically as the +clients retry. +.PP +It is possible to disable load balancing between peers by setting this +value to 0 on both peers. Bear in mind that this means both peers will +respond to all DHCPDISCOVERs or DHCPREQUESTs. +.RE +.PP +The +.I auto-partner-down +statement +.RS 0.25i +.PP +.B auto-partner-down \fIseconds\fR\fB;\fR +.PP +This statement instructs the server to initiate a timed delay upon entering +the communications-interrupted state (any situation of being out-of-contact +with the remote failover peer). At the conclusion of the timer, the server +will automatically enter the partner-down state. This permits the server +to allocate leases from the partner's free lease pool after an STOS+MCLT +timer expires, which can be dangerous if the partner is in fact operating +at the time (the two servers will give conflicting bindings). +.PP +Think very carefully before enabling this feature. The partner-down and +communications-interrupted states are intentionally segregated because +there do exist situations where a failover server can fail to communicate +with its peer, but still has the ability to receive and reply to requests +from DHCP clients. In general, this feature should only be used in those +deployments where the failover servers are directly connected to one +another, such as by a dedicated hardwired link ("a heartbeat cable"). +.PP +A zero value disables the auto-partner-down feature (also the default), and +any positive value indicates the time in seconds to wait before automatically +entering partner-down. +.RE +.PP +The Failover pool balance statements. +.RS 0.25i +.PP + \fBmax-lease-misbalance \fIpercentage\fR\fB;\fR + \fBmax-lease-ownership \fIpercentage\fR\fB;\fR + \fBmin-balance \fIseconds\fR\fB;\fR + \fBmax-balance \fIseconds\fR\fB;\fR +.PP +This version of the DHCP Server evaluates pool balance on a schedule, +rather than on demand as leases are allocated. The latter approach +proved to be slightly klunky when pool misbalanced reach total +saturation \(em when any server ran out of leases to assign, it also lost +its ability to notice it had run dry. +.PP +In order to understand pool balance, some elements of its operation +first need to be defined. First, there are \'free\' and \'backup\' leases. +Both of these are referred to as \'free state leases\'. \'free\' and +\'backup\' +are \'the free states\' for the purpose of this document. The difference +is that only the primary may allocate from \'free\' leases unless under +special circumstances, and only the secondary may allocate \'backup\' leases. +.PP +When pool balance is performed, the only plausible expectation is to +provide a 50/50 split of the free state leases between the two servers. +This is because no one can predict which server will fail, regardless +of the relative load placed upon the two servers, so giving each server +half the leases gives both servers the same amount of \'failure endurance\'. +Therefore, there is no way to configure any different behaviour, outside of +some very small windows we will describe shortly. +.PP +The first thing calculated on any pool balance run is a value referred to +as \'lts\', or "Leases To Send". This, simply, is the difference in the +count of free and backup leases, divided by two. For the secondary, +it is the difference in the backup and free leases, divided by two. +The resulting value is signed: if it is positive, the local server is +expected to hand out leases to retain a 50/50 balance. If it is negative, +the remote server would need to send leases to balance the pool. Once +the lts value reaches zero, the pool is perfectly balanced (give or take +one lease in the case of an odd number of total free state leases). +.PP +The current approach is still something of a hybrid of the old approach, +marked by the presence of the \fBmax-lease-misbalance\fR statement. This +parameter configures what used to be a 10% fixed value in previous versions: +if lts is less than free+backup * \fBmax-lease-misbalance\fR percent, then +the server will skip balancing a given pool (it won't bother moving any +leases, even if some leases "should" be moved). The meaning of this value +is also somewhat overloaded, however, in that it also governs the estimation +of when to attempt to balance the pool (which may then also be skipped over). +The oldest leases in the free and backup states are examined. The time +they have resided in their respective queues is used as an estimate to +indicate how much time it is probable it would take before the leases at +the top of the list would be consumed (and thus, how long it would take +to use all leases in that state). This percentage is directly multiplied +by this time, and fit into the schedule if it falls within +the \fBmin-balance\fR and \fBmax-balance\fR configured values. The +scheduled pool check time is only moved in a downwards direction, it is +never increased. Lastly, if the lts is more than double this number in +the negative direction, the local server will \'panic\' and transmit a +Failover protocol POOLREQ message, in the hopes that the remote system +will be woken up into action. +.PP +Once the lts value exceeds the \fBmax-lease-misbalance\fR percentage of +total free state leases as described above, leases are moved to the remote +server. This is done in two passes. +.PP +In the first pass, only leases whose most recent bound client would have +been served by the remote server - according to the Load Balance Algorithm +(see above \fBsplit\fR and \fBhba\fR configuration statements) - are given +away to the peer. This first pass will happily continue to give away leases, +decrementing the lts value by one for each, until the lts value has reached +the negative of the total number of leases multiplied by +the \fBmax-lease-ownership\fR percentage. So it is through this value that +you can permit a small misbalance of the lease pools - for the purpose of +giving the peer more than a 50/50 share of leases in the hopes that their +clients might some day return and be allocated by the peer (operating +normally). This process is referred to as \'MAC Address Affinity\', but this +is somewhat misnamed: it applies equally to DHCP Client Identifier options. +Note also that affinity is applied to leases when they enter the state +\'free\' from \'expired\' or \'released\'. In this case also, leases will not +be moved from free to backup if the secondary already has more than its +share. +.PP +The second pass is only entered into if the first pass fails to reduce +the lts underneath the total number of free state leases multiplied by +the \fBmax-lease-ownership\fR percentage. In this pass, the oldest +leases are given over to the peer without second thought about the Load +Balance Algorithm, and this continues until the lts falls under this +value. In this way, the local server will also happily keep a small +percentage of the leases that would normally load balance to itself. +.PP +So, the \fBmax-lease-misbalance\fR value acts as a behavioural gate. +Smaller values will cause more leases to transition states to balance +the pools over time, higher values will decrease the amount of change +(but may lead to pool starvation if there's a run on leases). +.PP +The \fBmax-lease-ownership\fR value permits a small (percentage) skew +in the lease balance of a percentage of the total number of free state +leases. +.PP +Finally, the \fBmin-balance\fR and \fBmax-balance\fR make certain that a +scheduled rebalance event happens within a reasonable timeframe (not +to be thrown off by, for example, a 7 year old free lease). +.PP +Plausible values for the percentages lie between 0 and 100, inclusive, but +values over 50 are indistinguishable from one another (once lts exceeds +50% of the free state leases, one server must therefore have 100% of the +leases in its respective free state). It is recommended to select +a \fBmax-lease-ownership\fR value that is lower than the value selected +for the \fBmax-lease-misbalance\fR value. \fBmax-lease-ownership\fR +defaults to 10, and \fBmax-lease-misbalance\fR defaults to 15. +.PP +Plausible values for the \fBmin-balance\fR and \fBmax-balance\fR times also +range from 0 to (2^32)-1 (or the limit of your local time_t value), but +default to values 60 and 3600 respectively (to place balance events between +1 minute and 1 hour). +.RE +.SH CLIENT CLASSING +Clients can be separated into classes, and treated differently +depending on what class they are in. This separation can be done +either with a conditional statement, or with a match statement within +the class declaration. It is possible to specify a limit on the +total number of clients within a particular class or subclass that may +hold leases at one time, and it is possible to specify automatic +subclassing based on the contents of the client packet. +.PP +Classing support for DHCPv6 clients was added in 4.3.0. It follows +the same rules as for DHCPv4 except that support for billing classes +has not been added yet. +.PP +To add clients to classes based on conditional evaluation, you can +specify a matching expression in the class statement: +.PP +.nf +class "ras-clients" { + match if substring (option dhcp-client-identifier, 1, 3) = "RAS"; +} +.fi +.PP +Please note that the values used in match expressions may only come from +data or options that are part of the client packet. It is not possible to +use values constructed through one or more executable statements. This +stems from the fact that client classification occurs before any statements +are executed. Attempting to do so will yield indeterminate results. +.PP +Note that whether you use matching expressions or add statements (or +both) to classify clients, you must always write a class declaration +for any class that you use. If there will be no match statement and +no in-scope statements for a class, the declaration should look like +this: +.PP +.nf +class "ras-clients" { +} +.fi +.SH SUBCLASSES +.PP +In addition to classes, it is possible to declare subclasses. A +subclass is a class with the same name as a regular class, but with a +specific submatch expression which is hashed for quick matching. +This is essentially a speed hack - the main difference between five +classes with match expressions and one class with five subclasses is +that it will be quicker to find the subclasses. Subclasses work as +follows: +.PP +.nf +class "allocation-class-1" { + match pick-first-value (option dhcp-client-identifier, hardware); +} + +class "allocation-class-2" { + match pick-first-value (option dhcp-client-identifier, hardware); +} + +subclass "allocation-class-1" 1:8:0:2b:4c:39:ad; +subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3; +subclass "allocation-class-1" 1:0:0:c4:aa:29:44; + +subnet 10.0.0.0 netmask 255.255.255.0 { + pool { + allow members of "allocation-class-1"; + range 10.0.0.11 10.0.0.50; + } + pool { + allow members of "allocation-class-2"; + range 10.0.0.51 10.0.0.100; + } +} +.fi +.PP +The data following the class name in the subclass declaration is a +constant value to use in matching the match expression for the class. +When class matching is done, the server will evaluate the match +expression and then look the result up in the hash table. If it +finds a match, the client is considered a member of both the class and +the subclass. +.PP +Subclasses can be declared with or without scope. In the above +example, the sole purpose of the subclass is to allow some clients +access to one address pool, while other clients are given access to +the other pool, so these subclasses are declared without scopes. If +part of the purpose of the subclass were to define different parameter +values for some clients, you might want to declare some subclasses +with scopes. +.PP +In the above example, if you had a single client that needed some +configuration parameters, while most didn't, you might write the +following subclass declaration for that client: +.PP +.nf +subclass "allocation-class-2" 1:08:00:2b:a1:11:31 { + option root-path "samsara:/var/diskless/alphapc"; + filename "/tftpboot/netbsd.alphapc-diskless"; +} +.fi +.PP +In this example, we've used subclassing as a way to control address +allocation on a per-client basis. However, it's also possible to use +subclassing in ways that are not specific to clients - for example, to +use the value of the vendor-class-identifier option to determine what +values to send in the vendor-encapsulated-options option. An example +of this is shown under the VENDOR ENCAPSULATED OPTIONS head in the +.B dhcp-options(5) +manual page. +.SH PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION +.PP +You may specify a limit to the number of clients in a class that can +be assigned leases. The effect of this will be to make it difficult +for a new client in a class to get an address. Once a class with +such a limit has reached its limit, the only way a new client in that +class can get a lease is for an existing client to relinquish its +lease, either by letting it expire, or by sending a DHCPRELEASE +packet. Classes with lease limits are specified as follows: +.PP +.nf +class "limited-1" { + lease limit 4; +} +.fi +.PP +This will produce a class in which a maximum of four members may hold +a lease at one time. +.SH SPAWNING CLASSES +.PP +It is possible to declare a +.I spawning class\fR. +A spawning class is a class that automatically produces subclasses +based on what the client sends. The reason that spawning classes +were created was to make it possible to create lease-limited classes +on the fly. The envisioned application is a cable-modem environment +where the ISP wishes to provide clients at a particular site with more +than one IP address, but does not wish to provide such clients with +their own subnet, nor give them an unlimited number of IP addresses +from the network segment to which they are connected. +.PP +Many cable modem head-end systems can be configured to add a Relay +Agent Information option to DHCP packets when relaying them to the +DHCP server. These systems typically add a circuit ID or remote ID +option that uniquely identifies the customer site. To take advantage +of this, you can write a class declaration as follows: +.PP +.nf +class "customer" { + spawn with option agent.circuit-id; + lease limit 4; +} +.fi +.PP +Now whenever a request comes in from a customer site, the circuit ID +option will be checked against the class\'s hash table. If a subclass +is found that matches the circuit ID, the client will be classified in +that subclass and treated accordingly. If no subclass is found +matching the circuit ID, a new one will be created and logged in the +.B dhcpd.leases +file, and the client will be classified in this new class. Once the +client has been classified, it will be treated according to the rules +of the class, including, in this case, being subject to the per-site +limit of four leases. +.PP +The use of the subclass spawning mechanism is not restricted to relay +agent options - this particular example is given only because it is a +fairly straightforward one. +.SH COMBINING MATCH, MATCH IF AND SPAWN WITH +.PP +In some cases, it may be useful to use one expression to assign a +client to a particular class, and a second expression to put it into a +subclass of that class. This can be done by combining the \fBmatch +if\fR and \fBspawn with\fR statements, or the \fBmatch if\fR and +\fBmatch\fR statements. For example: +.PP +.nf +class "jr-cable-modems" { + match if option dhcp-vendor-identifier = "jrcm"; + spawn with option agent.circuit-id; + lease limit 4; +} + +class "dv-dsl-modems" { + match if option dhcp-vendor-identifier = "dvdsl"; + spawn with option agent.circuit-id; + lease limit 16; +} +.fi +.PP +This allows you to have two classes that both have the same \fBspawn +with\fR expression without getting the clients in the two classes +confused with each other. +.SH DYNAMIC DNS UPDATES +.PP +The DHCP server has the ability to dynamically update the Domain Name +System. Within the configuration files, you can define how you want +the Domain Name System to be updated. These updates are RFC 2136 +compliant so any DNS server supporting RFC 2136 should be able to +accept updates from the DHCP server. +.PP +There are two DNS schemes implemented. The interim option is +based on draft revisions of the DDNS documents while the standard +option is based on the RFCs for DHCP-DNS interaction and DHCIDs. +A third option, ad-hoc, was deprecated and has now been removed +from the code base. The DHCP server must be configured to use +one of the two currently-supported methods, or not to do DNS updates. +.PP +New installations should use the standard option. Older +installations may want to continue using the interim option for +backwards compatibility with the DNS database until the database +can be updated. This can be done with the +.I ddns-update-style +configuration parameter. +.SH THE DNS UPDATE SCHEME +the interim and standard DNS update schemes operate mostly according +to work from the IETF. The interim version was based on the drafts +in progress at the time while the standard is based on the completed +RFCs. The standard RFCs are: +.PP +.nf +.ce 3 +RFC 4701 (updated by RF5494) +RFC 4702 +RFC 4703 +.fi +.PP +And the corresponding drafts were: +.PP +.nf +.ce 3 +draft-ietf-dnsext-dhcid-rr-??.txt +draft-ietf-dhc-fqdn-option-??.txt +draft-ietf-dhc-ddns-resolution-??.txt +.fi +.PP +The basic framework for the two schemes is similar with the main +material difference being that a DHCID RR is used in the standard +version while the interim versions uses a TXT RR. The format +of the TXT record bears a resemblance to the DHCID RR but it is not +equivalent (MD5 vs SHA2, field length differences etc). +.PP +In these two schemes the DHCP server does not necessarily +always update both the A and the PTR records. The FQDN option +includes a flag which, when sent by the client, indicates that the +client wishes to update its own A record. In that case, the server +can be configured either to honor the client\'s intentions or ignore +them. This is done with the statement \fIallow client-updates;\fR or +the statement \fIignore client-updates;\fR. By default, client +updates are allowed. +.PP +If the server is configured to allow client updates, then if the +client sends a fully-qualified domain name in the FQDN option, the +server will use that name the client sent in the FQDN option to update +the PTR record. For example, let us say that the client is a visitor +from the "radish.org" domain, whose hostname is "jschmoe". The +server is for the "example.org" domain. The DHCP client indicates in +the FQDN option that its FQDN is "jschmoe.radish.org.". It also +indicates that it wants to update its own A record. The DHCP server +therefore does not attempt to set up an A record for the client, but +does set up a PTR record for the IP address that it assigns the +client, pointing at jschmoe.radish.org. Once the DHCP client has an +IP address, it can update its own A record, assuming that the +"radish.org" DNS server will allow it to do so. +.PP +If the server is configured not to allow client updates, or if the +client doesn\'t want to do its own update, the server will simply +choose a name for the client. By default, the server will choose +from the following three values: +.PP + 1. \fBfqdn\fR option (if present) + 2. hostname option (if present) + 3. Configured hostname option (if defined). +.PP +If these defaults for choosing the host name are not appropriate +you can write your own statement to set the ddns-hostname variable +as you wish. If none of the above are found the server will use +the host declaration name (if one) and use-host-decl-names is on. +.PP +It will use its own domain name for the client. It will then update +both the A and PTR record, using the name that it chose for the client. +If the client sends a fully-qualified domain name in the \fBfqdn\fR option, +the server uses only the leftmost part of the domain name - in the example +above, "jschmoe" instead of "jschmoe.radish.org". +.PP +Further, if the \fIignore client-updates;\fR directive is used, then +the server will in addition send a response in the DHCP packet, using +the FQDN Option, that implies to the client that it should perform its +own updates if it chooses to do so. With \fIdeny client-updates;\fR, a +response is sent which indicates the client may not perform updates. +.PP +Both the standard and interim options also include a method to +allow more than one DHCP server to update the DNS database without +accidentally deleting A records that shouldn\'t be deleted nor failing +to add A records that should be added. For the standard option the +method works as follows: +.PP +When the DHCP server issues a client a new lease, it creates a text +string that is an SHA hash over the DHCP client\'s identification (see +RFCs 4701 & 4702 for details). The update attempts to add an A +record with the name the server chose and a DHCID record containing the +hashed identifier string (hashid). If this update succeeds, the +server is done. +.PP +If the update fails because the A record already exists, then the DHCP +server attempts to add the A record with the prerequisite that there +must be a DHCID record in the same name as the new A record, and that +DHCID record\'s contents must be equal to hashid. If this update +succeeds, then the client has its A record and PTR record. If it +fails, then the name the client has been assigned (or requested) is in +use, and can\'t be used by the client. At this point the DHCP server +gives up trying to do a DNS update for the client until the client +chooses a new name. +.PP +The server also does not update very aggressively. Because each +DNS update involves a round trip to the DNS server, there is a cost +associated with doing updates even if they do not actually modify +the DNS database. So the DHCP server tracks whether or not it has +updated the record in the past (this information is stored on the +lease) and does not attempt to update records that it +thinks it has already updated. +.PP +This can lead to cases where the DHCP server adds a record, and then +the record is deleted through some other mechanism, but the server +never again updates the DNS because it thinks the data is already +there. In this case the data can be removed from the lease through +operator intervention, and once this has been done, the DNS will be +updated the next time the client renews. +.PP +The interim DNS update scheme was written before the RFCs were finalized +and does not quite follow them. The RFCs call for a new DHCID RRtype +while the interim DNS update scheme uses a TXT record. In addition +the ddns-resolution draft called for the DHCP server to put a DHCID RR +on the PTR record, but the \fIinterim\fR update method does not do this. +In the final RFC this requirement was relaxed such that a server may +add a DHCID RR to the PTR record. +.PP +.SH DDNS IN DUAL STACK ENVIRONMENTS +As described in RFC 4703, section 5.2, in order to perform DDNS in dual +stack environments, both IPv4 and IPv6 servers would need to be configured +to use the standard update style and participating IPv4 clients MUST +convey DUIDs as described in RFC 4361, section 6.1., in their +dhcp-client-identifiers. +.PP +In a nutshell, this mechanism is intended to use globally unique DUIDs +to idenfity both IPv4 and IPv6 clients, and where a device has both +IPv4 and IPv6 leases it is identified by the same DUID. This allows +a dual stack client to use the same FQDN for both mappings, while +being protected from updates for other clients by the rules of conflict +detection. +.PP +However, not all IPv4 clients implement this behavior which makes +supporting them dual stack environments problematic. In order to +address this issue ISC DHCP (as of 4.4.0) supports a new mode of +DDNS conflict resolution referred to as Dual Stack Mixed Mode (DSMM). +.PP +The concept behind DSMM is relatively simple. All dhcp servers of one +protocol (IPv4 or v6) use one ddns-update-style (interim or standard) +while all servers of the "other" protocol will use the "other" +ddns-udpate-style. In this way, all servers of a given protocol are +using the same record type (TXT or DHCID) for their DHCID RR entries. +This allows conflict detection to be enforced within each protocol +without interferring with the other's entries. +.PP +DSMM modifications now ensure that IPv4 DSMM servers only ever modify +A records, their associated PTR records and DHCID records, while DSMM +IPv6 severs only modify AAAA records, their associated PTR records, +and DHCID records. +.PP +Note that DSMM is not a perfect solution, it is a compromise that can +work well provided all participating DNS updaters play by DSMM rules. +As with anything else in life, it only works as well as those who +particpate behave. +.PP +While conflict detection is enabled by default, DSMM is not. To enable +DSMM, both update-conflict-detection and ddns-dual-stack-mixed-mode must +be true. +.PP +.SH PROTECTING DNS ENTRIES FOR STATIC CLIENTS +Built into conflict resolution is the protection of manually made entries +for static clients. Per the rules of conflict resolution, a DNS updater +may not alter forward DNS entries unless there is a DHCID RR which matches +for whom the update is being made. Therefore, any forward DNS entries +without a corresponding DHCID RR cannot be altered by such an updater. +.PP +In some environments, it may be desirable to use only this aspect of conflict +resolution and allow DNS updaters to overwrite entries for dynamic clients +regardless of what client owns them. In other words, the presence or lack +of a DHCID RR is used to determine whether entries may or may not be +overwritten. Whether or not the client matches the data value of the DHCID +RR is irrelevant. This behavior, off by default, can be configured through +the parameter, ddns-guard-id-must-match. As with DSMM, this behavior is +can only be enabled if conflict resolution is enabled. This behavior should +be considered carefully before electing to use it. +.PP +There is an additional parameter that can be used with DSMM +ddns-other-guard-is-dynamic. When enabled along with DSMM, a server will +regard the presence of a DHCID RR of the other style type as indicating that +the forward DNS entries for that FQDN should be dynamic and may be overwritten. +For example, such a server using interim style could overwrite the DNS entries +for an FQDN if there is only a DHDID type DHDID RR for the FQDN. Essentially, +if there are dynamic entries for one protocol, that is enough to overcome the +static protection of entries for the other protocol. This behavior warrants +careful consideration before electing to use it. +.PP +.SH DYNAMIC DNS UPDATE SECURITY +.PP +When you set your DNS server up to allow updates from the DHCP server, +you may be exposing it to unauthorized updates. To avoid this, you +should use TSIG signatures - a method of cryptographically signing +updates using a shared secret key. As long as you protect the +secrecy of this key, your updates should also be secure. Note, +however, that the DHCP protocol itself provides no security, and that +clients can therefore provide information to the DHCP server which the +DHCP server will then use in its updates, with the constraints +described previously. +.PP +The DNS server must be configured to allow updates for any zone that +the DHCP server will be updating. For example, let us say that +clients in the sneedville.edu domain will be assigned addresses on the +10.10.17.0/24 subnet. In that case, you will need a key declaration +for the TSIG key you will be using, and also two zone declarations - +one for the zone containing A records that will be updates and one for +the zone containing PTR records - for ISC BIND, something like this: +.PP +.nf +key DHCP_UPDATER { + algorithm HMAC-MD5.SIG-ALG.REG.INT; + secret pRP5FapFoJ95JEL06sv4PQ==; +}; + +zone "example.org" { + type master; + file "example.org.db"; + allow-update { key DHCP_UPDATER; }; +}; + +zone "17.10.10.in-addr.arpa" { + type master; + file "10.10.17.db"; + allow-update { key DHCP_UPDATER; }; +}; +.fi +.PP +You will also have to configure your DHCP server to do updates to +these zones. To do so, you need to add something like this to your +dhcpd.conf file: +.PP +.nf +key DHCP_UPDATER { + algorithm HMAC-MD5.SIG-ALG.REG.INT; + secret pRP5FapFoJ95JEL06sv4PQ==; +}; + +zone EXAMPLE.ORG. { + primary 127.0.0.1; + key DHCP_UPDATER; +} + +zone 17.127.10.in-addr.arpa. { + primary 127.0.0.1; + key DHCP_UPDATER; +} +.fi +.PP +The \fIprimary\fR statement specifies the IP address of the name +server whose zone information is to be updated. In addition to +the \fIprimary\fR statement there are also the \fIprimary6\fR , +\fIsecondary\fR and \fIsecondary6\fR statements. The \fIprimary6\fR +statement specifies an IPv6 address for the name server. The +secondaries provide for additional addresses for name servers +to be used if the primary does not respond. The number of name +servers the DDNS code will attempt to use before giving up +is limited and is currently set to three. +.PP +Note that the zone declarations have to correspond to authority +records in your name server - in the above example, there must be an +SOA record for "example.org." and for "17.10.10.in-addr.arpa.". For +example, if there were a subdomain "foo.example.org" with no separate +SOA, you could not write a zone declaration for "foo.example.org." +Also keep in mind that zone names in your DHCP configuration should end in a +"."; this is the preferred syntax. If you do not end your zone name in a +".", the DHCP server will figure it out. Also note that in the DHCP +configuration, zone names are not encapsulated in quotes where there are in +the DNS configuration. +.PP +You should choose your own secret key, of course. The ISC BIND 9 +distribution comes with a program for generating secret keys called +dnssec-keygen. If you are using BIND 9\'s +dnssec-keygen, the above key would be created as follows: +.PP +.nf + dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER +.fi +.PP +The key name, algorithm, and secret must match that being used by the DNS +server. The DHCP server currently supports the following algorithms: +.nf + + HMAC-MD5 + HMAC-SHA1 + HMAC-SHA224 + HMAC-SHA256 + HMAC-SHA384 + HMAC-SHA512 +.fi +.PP +You may wish to enable logging of DNS updates on your DNS server. +To do so, you might write a logging statement like the following: +.PP +.nf +logging { + channel update_debug { + file "/var/log/update-debug.log"; + severity debug 3; + print-category yes; + print-severity yes; + print-time yes; + }; + channel security_info { + file "/var/log/named-auth.info"; + severity info; + print-category yes; + print-severity yes; + print-time yes; + }; + + category update { update_debug; }; + category security { security_info; }; +}; +.fi +.PP +You must create the /var/log/named-auth.info and +/var/log/update-debug.log files before starting the name server. For +more information on configuring ISC BIND, consult the documentation +that accompanies it. +.SH REFERENCE: EVENTS +.PP +There are three kinds of events that can happen regarding a lease, and +it is possible to declare statements that occur when any of these +events happen. These events are the commit event, when the server +has made a commitment of a certain lease to a client, the release +event, when the client has released the server from its commitment, +and the expiry event, when the commitment expires. +.PP +To declare a set of statements to execute when an event happens, you +must use the \fBon\fR statement, followed by the name of the event, +followed by a series of statements to execute when the event happens, +enclosed in braces. +.SH REFERENCE: DECLARATIONS +.PP +.B The +.I include +.B statement +.PP +.nf + \fBinclude\fR \fI"filename"\fR\fB;\fR +.fi +.PP +The \fIinclude\fR statement is used to read in a named file, and process +the contents of that file as though it were entered in place of the +include statement. +.PP +.B The +.I shared-network +.B statement +.PP +.nf + \fBshared-network\fR \fIname\fR \fB{\fR + [ \fIparameters\fR ] + [ \fIdeclarations\fR ] + \fB}\fR +.fi +.PP +The \fIshared-network\fR statement is used to inform the DHCP server +that some IP subnets actually share the same physical network. Any +subnets in a shared network should be declared within a +\fIshared-network\fR statement. Parameters specified in the +\fIshared-network\fR statement will be used when booting clients on +those subnets unless parameters provided at the subnet or host level +override them. If any subnet in a shared network has addresses +available for dynamic allocation, those addresses are collected into a +common pool for that shared network and assigned to clients as needed. +There is no way to distinguish on which subnet of a shared network a +client should boot. +.PP +.I Name +should be the name of the shared network. This name is used when +printing debugging messages, so it should be descriptive for the +shared network. The name may have the syntax of a valid domain name +(although it will never be used as such), or it may be any arbitrary +name, enclosed in quotes. +.PP +.B The +.I subnet +.B statement +.PP +.nf + \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR + [ \fIparameters\fR ] + [ \fIdeclarations\fR ] + \fB}\fR +.fi +.PP +The \fIsubnet\fR statement is used to provide dhcpd with enough +information to tell whether or not an IP address is on that subnet. +It may also be used to provide subnet-specific parameters and to +specify what addresses may be dynamically allocated to clients booting +on that subnet. Such addresses are specified using the \fIrange\fR +declaration. +.PP +The +.I subnet-number +should be an IP address or domain name which resolves to the subnet +number of the subnet being described. The +.I netmask +should be an IP address or domain name which resolves to the subnet mask +of the subnet being described. The subnet number, together with the +netmask, are sufficient to determine whether any given IP address is +on the specified subnet. +.PP +Although a netmask must be given with every subnet declaration, it is +recommended that if there is any variance in subnet masks at a site, a +subnet-mask option statement be used in each subnet declaration to set +the desired subnet mask, since any subnet-mask option statement will +override the subnet mask declared in the subnet statement. +.PP +.B The +.I subnet6 +.B statement +.PP +.nf + \fBsubnet6\fR \fIsubnet6-number\fR \fB{\fR + [ \fIparameters\fR ] + [ \fIdeclarations\fR ] + \fB}\fR +.fi +.PP +The \fIsubnet6\fR statement is used to provide dhcpd with enough +information to tell whether or not an IPv6 address is on that subnet6. +It may also be used to provide subnet-specific parameters and to +specify what addresses may be dynamically allocated to clients booting +on that subnet. +.PP +The +.I subnet6-number +should be an IPv6 network identifier, specified as ip6-address/bits. +.PP +.B The +.I range +.B statement +.PP +.nf +.B range\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR +.fi +.PP +For any subnet on which addresses will be assigned dynamically, there +must be at least one \fIrange\fR statement. The range statement +gives the lowest and highest IP addresses in a range. All IP +addresses in the range should be in the subnet in which the +\fIrange\fR statement is declared. The \fIdynamic-bootp\fR flag may +be specified if addresses in the specified range may be dynamically +assigned to BOOTP clients as well as DHCP clients. When specifying a +single address, \fIhigh-address\fR can be omitted. +.PP +.B The +.I range6 +.B statement +.PP +.nf +.B range6\fR \fIlow-address\fR \fIhigh-address\fR\fB;\fR +.B range6\fR \fIsubnet6-number\fR\fB;\fR +.B range6\fR \fIsubnet6-number\fR \fBtemporary\fR\fB;\fR +.B range6\fR \fIaddress\fR \fBtemporary\fR\fB;\fR +.fi +.PP +For any IPv6 subnet6 on which addresses will be assigned dynamically, there +must be at least one \fIrange6\fR statement. The \fIrange6\fR statement +can either be the lowest and highest IPv6 addresses in a \fIrange6\fR, or +use CIDR notation, specified as ip6-address/bits. All IP addresses +in the \fIrange6\fR should be in the subnet6 in which the +\fIrange6\fR statement is declared. +.PP +The \fItemporary\fR variant makes the prefix (by default on 64 bits) available +for temporary (RFC 4941) addresses. A new address per prefix in the shared +network is computed at each request with an IA_TA option. Release and Confirm +ignores temporary addresses. +.PP +Any IPv6 addresses given to hosts with \fIfixed-address6\fR are excluded +from the \fIrange6\fR, as are IPv6 addresses on the server itself. +.PP +.PP +.B The +.I prefix6 +.B statement +.PP +.nf +.B prefix6\fR \fIlow-address\fR \fIhigh-address\fR \fB/\fR \fIbits\fR\fB;\fR +.fi +.PP +The \fIprefix6\fR is the \fIrange6\fR equivalent for Prefix Delegation +(RFC 3633). Prefixes of \fIbits\fR length are assigned between +\fIlow-address\fR and \fIhigh-address\fR. +.PP +Any IPv6 prefixes given to static entries (hosts) with \fIfixed-prefix6\fR +are excluded from the \fIprefix6\fR. +.PP +This statement is currently global but it should have a shared-network scope. +.PP +.B The +.I host +.B statement +.PP +.nf + \fBhost\fR \fIhostname\fR { + [ \fIparameters\fR ] + [ \fIdeclarations\fR ] + \fB}\fR +.fi +.PP +The +.B host +declaration provides a way for the DHCP server to identify a DHCP or +BOOTP client. This allows the server to provide configuration +information including fixed addresses or, in DHCPv6, fixed prefixes +for a specific client. +.PP +If it is desirable to be able to boot a DHCP or BOOTP client on more than one +subnet with fixed v4 addresses, more than one address may be specified in the +.I fixed-address +declaration, or more than one +.B host +statement may be specified matching the same client. +.PP +The +.I fixed-address6 +declaration is used for v6 addresses. At this time it only works with a single +address. For multiple addresses specify multiple +.B host +statements. +.PP +If client-specific boot parameters must change based on the network +to which the client is attached, then multiple +.B host +declarations should be used. The +.B host +declarations will only match a client if one of their +.I fixed-address +statements is viable on the subnet (or shared network) where the client is +attached. Conversely, for a +.B host +declaration to match a client being allocated a dynamic address, it must not +have any +.I fixed-address +statements. You may therefore need a mixture of +.B host +declarations for any given client...some having +.I fixed-address +statements, others without. +.PP +.I hostname +should be a name identifying the host. If a \fIhostname\fR option is +not specified for the host, \fIhostname\fR is used. +.PP +\fIHost\fR declarations are matched to actual DHCP or BOOTP clients +by matching the \fRdhcp-client-identifier\fR option specified in the +\fIhost\fR declaration to the one supplied by the client, or, if the +\fIhost\fR declaration or the client does not provide a +\fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR +parameter in the \fIhost\fR declaration to the network hardware +address supplied by the client. BOOTP clients do not normally +provide a \fIdhcp-client-identifier\fR, so the hardware address must +be used for all clients that may boot using the BOOTP protocol. +.PP +DHCPv6 servers can use the \fIhost-identifier option\fR parameter in +the \fIhost\fR declaration, and specify any option with a fixed value +to identify hosts. +.PP +Please be aware that +.B only +the \fIdhcp-client-identifier\fR option and the hardware address can be +used to match a host declaration, or the \fIhost-identifier option\fR +parameter for DHCPv6 servers. For example, it is not possible to +match a host declaration to a \fIhost-name\fR option. This is +because the host-name option cannot be guaranteed to be unique for any +given client, whereas both the hardware address and +\fIdhcp-client-identifier\fR option are at least theoretically +guaranteed to be unique to a given client. +.PP +.B The +.I group +.B statement +.PP +.nf + \fBgroup\fR { + [ \fIparameters\fR ] + [ \fIdeclarations\fR ] + \fB}\fR +.fi +.PP +The group statement is used simply to apply one or more parameters to +a group of declarations. It can be used to group hosts, shared +networks, subnets, or even other groups. +.SH REFERENCE: ALLOW AND DENY +The +.I allow +and +.I deny +statements can be used to control the response of the DHCP server to +various sorts of requests. The allow and deny keywords actually have +different meanings depending on the context. In a pool context, these +keywords can be used to set up access lists for address allocation +pools. In other contexts, the keywords simply control general server +behavior with respect to clients based on scope. In a non-pool +context, the +.I ignore +keyword can be used in place of the +.I deny +keyword to prevent logging of denied requests. +.PP +.SH ALLOW DENY AND IGNORE IN SCOPE +The following usages of allow and deny will work in any scope, +although it is not recommended that they be used in pool +declarations. +.PP +.B The +.I unknown-clients +.B keyword +.PP + \fBallow unknown-clients;\fR + \fBdeny unknown-clients;\fR + \fBignore unknown-clients;\fR +.PP +The \fBunknown-clients\fR flag is used to tell dhcpd whether +or not to dynamically assign addresses to unknown clients. Dynamic +address assignment to unknown clients is \fBallow\fRed by default. +An unknown client is simply a client that has no host declaration. +.PP +The use of this option is now \fIdeprecated\fR. If you are trying to +restrict access on your network to known clients, you should use \fBdeny +unknown-clients;\fR inside of your address pool, as described under the +heading ALLOW AND DENY WITHIN POOL DECLARATIONS. +.PP +.B The +.I bootp +.B keyword +.PP + \fBallow bootp;\fR + \fBdeny bootp;\fR + \fBignore bootp;\fR +.PP +The \fBbootp\fR flag is used to tell dhcpd whether +or not to respond to bootp queries. Bootp queries are \fBallow\fRed +by default. +.PP +.B The +.I booting +.B keyword +.PP + \fBallow booting;\fR + \fBdeny booting;\fR + \fBignore booting;\fR +.PP +The \fBbooting\fR flag is used to tell dhcpd whether or not to respond +to queries from a particular client. This keyword only has meaning +when it appears in a host declaration. By default, booting is +\fBallow\fRed, but if it is disabled for a particular client, then +that client will not be able to get an address from the DHCP server. +.PP +.B The +.I duplicates +.B keyword +.PP + \fBallow duplicates;\fR + \fBdeny duplicates;\fR +.PP +Host declarations can match client messages based on the DHCP Client +Identifier option or based on the client's network hardware type and +MAC address. If the MAC address is used, the host declaration will +match any client with that MAC address - even clients with different +client identifiers. This doesn't normally happen, but is possible +when one computer has more than one operating system installed on it - +for example, Microsoft Windows and NetBSD or Linux. +.PP +The \fBduplicates\fR flag tells the DHCP server that if a request is +received from a client that matches the MAC address of a host +declaration, any other leases matching that MAC address should be +discarded by the server, even if the UID is not the same. This is a +violation of the DHCP protocol, but can prevent clients whose client +identifiers change regularly from holding many leases at the same time. +By default, duplicates are \fBallow\fRed. +.PP +.B The +.I declines +.B keyword +.PP + \fBallow declines;\fR + \fBdeny declines;\fR + \fBignore declines;\fR +.PP +The DHCPDECLINE message is used by DHCP clients to indicate that the +lease the server has offered is not valid. When the server receives +a DHCPDECLINE for a particular address, it normally abandons that +address, assuming that some unauthorized system is using it. +Unfortunately, a malicious or buggy client can, using DHCPDECLINE +messages, completely exhaust the DHCP server's allocation pool. The +server will eventually reclaim these leases, but not while the client +is running through the pool. This may cause serious thrashing in the DNS, +and it will also cause the DHCP server to forget old DHCP client address +allocations. +.PP +The \fBdeclines\fR flag tells the DHCP server whether or not to honor +DHCPDECLINE messages. If it is set to \fBdeny\fR or \fBignore\fR in +a particular scope, the DHCP server will not respond to DHCPDECLINE +messages. +.PP +The \fBdeclines\fR flag is only supported by DHCPv4 servers. Given the large +IPv6 address space and the internal limits imposed by the server's +address generation mechanism we don't think it is necessary for DHCPv6 +servers at this time. +.PP +Currently, abandoned IPv6 addresses are reclaimed in one of two ways: + a) Client renews a specific address: + If a client using a given DUID submits a DHCP REQUEST containing + the last address abandoned by that DUID, the address will be + reassigned to that client. + + b) Upon the second restart following an address abandonment. When + an address is abandoned it is both recorded as such in the lease + file and retained as abandoned in server memory until the server + is restarted. Upon restart, the server will process the lease file + and all addresses whose last known state is abandoned will be + retained as such in memory but not rewritten to the lease file. + This means that a subsequent restart of the server will not see the + abandoned addresses in the lease file and therefore have no record + of them as abandoned in memory and as such perceive them as free + for assignment. +.PP +The total number addresses in a pool, available for a given DUID value, +is internally limited by the server's address generation mechanism. If +through mistaken configuration, multiple clients are using the same +DUID they will competing for the same addresses causing the server to reach +this internal limit rather quickly. The internal limit isolates this type +of activity such that address range is not exhausted for other DUID values. +The appearance of the following error log, can be an indication of this +condition: + + "Best match for DUID is an abandoned address, This may be a + result of multiple clients attempting to use this DUID" + + where is an actual DUID value depicted as colon separated + string of bytes in hexadecimal values. +.PP +.B The +.I client-updates +.B keyword +.PP + \fBallow client-updates;\fR + \fBdeny client-updates;\fR +.PP +The \fBclient-updates\fR flag tells the DHCP server whether or not to +honor the client's intention to do its own update of its A record. See +the documentation under the heading THE DNS UPDATE SCHEME for details. +.PP +.B The +.I leasequery +.B keyword +.PP + \fBallow leasequery;\fR + \fBdeny leasequery;\fR +.PP +The \fBleasequery\fR flag tells the DHCP server whether or not to +answer DHCPLEASEQUERY packets. The answer to a DHCPLEASEQUERY packet +includes information about a specific lease, such as when it was +issued and when it will expire. By default, the server will not +respond to these packets. +.SH ALLOW AND DENY WITHIN POOL DECLARATIONS +.PP +The uses of the allow and deny keywords shown in the previous section +work pretty much the same way whether the client is sending a +DHCPDISCOVER or a DHCPREQUEST message - an address will be allocated +to the client (either the old address it's requesting, or a new +address) and then that address will be tested to see if it's okay to +let the client have it. If the client requested it, and it's not +okay, the server will send a DHCPNAK message. Otherwise, the server +will simply not respond to the client. If it is okay to give the +address to the client, the server will send a DHCPACK message. +.PP +The primary motivation behind pool declarations is to have address +allocation pools whose allocation policies are different. A client +may be denied access to one pool, but allowed access to another pool +on the same network segment. In order for this to work, access +control has to be done during address allocation, not after address +allocation is done. +.PP +When a DHCPREQUEST message is processed, address allocation simply +consists of looking up the address the client is requesting and seeing +if it's still available for the client. If it is, then the DHCP +server checks both the address pool permit lists and the relevant +in-scope allow and deny statements to see if it's okay to give the +lease to the client. In the case of a DHCPDISCOVER message, the +allocation process is done as described previously in the ADDRESS +ALLOCATION section. +.PP +When declaring permit lists for address allocation pools, the +following syntaxes are recognized following the allow or deny keywords: +.PP + \fBknown-clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any client that has a host declaration (i.e., is known). +A client is known if it has a host declaration in \fIany\fR scope, not +just the current scope. +.PP + \fBunknown-clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any client that has no host declaration (i.e., is not +known). +.PP + \fBmembers of "\fRclass\fB";\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any client that is a member of the named class. +.PP + \fBdynamic bootp clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any bootp client. +.PP + \fBauthenticated clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any client that has been authenticated using the DHCP +authentication protocol. This is not yet supported. +.PP + \fBunauthenticated clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to any client that has not been authenticated using the DHCP +authentication protocol. This is not yet supported. +.PP + \fBall clients;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool to all clients. This can be used when you want to write a +pool declaration for some reason, but hold it in reserve, or when you +want to renumber your network quickly, and thus want the server to +force all clients that have been allocated addresses from this pool to +obtain new addresses immediately when they next renew. +.PP + \fBafter \fItime\fR\fB;\fR +.PP +If specified, this statement either allows or prevents allocation from +this pool after a given date. This can be used when you want to move +clients from one pool to another. The server adjusts the regular lease +time so that the latest expiry time is at the given time+min-lease-time. +A short min-lease-time enforces a step change, whereas a longer +min-lease-time allows for a gradual change. +\fItime\fR is either second since epoch, or a UTC time string e.g. +4 2007/08/24 09:14:32 or a string with time zone offset in seconds +e.g. 4 2007/08/24 11:14:32 -7200 +.SH REFERENCE: PARAMETERS +The +.I abandon-lease-time +statement +.RS 0.25i +.PP +.B abandon-lease-time \fItime\fR\fB;\fR +.PP +.I Time +should be the maximum amount of time (in seconds) that an abandoned IPv4 lease +remains unavailable for assignment to a client. Abandoned leases will only be +offered to clients if there are no free leases. If not defined, the default +abandon lease time is 86400 seconds (24 hours). Note the abandoned lease time +for a given lease is preserved across server restarts. The parameter may only +be set at the global scope and is evaluated only once during server startup. +.PP +Values less than sixty seconds are not recommended as this is below the ping +check threshold and can cause leases once abandoned but since returned to the +free state to not be pinged before being offered. If the requested time is +larger than 0x7FFFFFFF - 1 or the sum of the current time plus the abandoned time isgreater than 0x7FFFFFFF it is treated as infinite. +.RE +.PP +The +.I adaptive-lease-time-threshold +statement +.RS 0.25i +.PP +.B adaptive-lease-time-threshold \fIpercentage\fR\fB;\fR +.PP +When the number of allocated leases within a pool rises above +the \fIpercentage\fR given in this statement, the DHCP server decreases +the lease length for new clients within this pool to \fImin-lease-time\fR +seconds. Clients renewing an already valid (long) leases get at least the +remaining time from the current lease. Since the leases expire faster, +the server may either recover more quickly or avoid pool exhaustion +entirely. Once the number of allocated leases drop below the threshold, +the server reverts back to normal lease times. Valid percentages are +between 1 and 99. +.RE +.PP +The +.I always-broadcast +statement +.RS 0.25i +.PP +.B always-broadcast \fIflag\fR\fB;\fR +.PP +The DHCP and BOOTP protocols both require DHCP and BOOTP clients to +set the broadcast bit in the flags field of the BOOTP message header. +Unfortunately, some DHCP and BOOTP clients do not do this, and +therefore may not receive responses from the DHCP server. The DHCP +server can be made to always broadcast its responses to clients by +setting this flag to \'on\' for the relevant scope; relevant scopes would be +inside a conditional statement, as a parameter for a class, or as a parameter +for a host declaration. To avoid creating excess broadcast traffic on your +network, we recommend that you restrict the use of this option to as few +clients as possible. For example, the Microsoft DHCP client is known not +to have this problem, as are the OpenTransport and ISC DHCP clients. +.RE +.PP +The +.I always-reply-rfc1048 +statement +.RS 0.25i +.PP +.B always-reply-rfc1048 \fIflag\fR\fB;\fR +.PP +Some BOOTP clients expect RFC1048-style responses, but do not follow +RFC1048 when sending their requests. You can tell that a client is +having this problem if it is not getting the options you have +configured for it and if you see in the server log the message +"(non-rfc1048)" printed with each BOOTREQUEST that is logged. +.PP +If you want to send rfc1048 options to such a client, you can set the +.B always-reply-rfc1048 +option in that client's host declaration, and the DHCP server will +respond with an RFC-1048-style vendor options field. This flag can +be set in any scope, and will affect all clients covered by that +scope. +.RE +.PP +The +.I authoritative +statement +.RS 0.25i +.PP +.B authoritative; +.PP +.B not authoritative; +.PP +The DHCP server will normally assume that the configuration +information about a given network segment is not known to be correct +and is not authoritative. This is so that if a naive user installs a +DHCP server not fully understanding how to configure it, it does not +send spurious DHCPNAK messages to clients that have obtained addresses +from a legitimate DHCP server on the network. +.PP +Network administrators setting up authoritative DHCP servers for their +networks should always write \fBauthoritative;\fR at the top of their +configuration file to indicate that the DHCP server \fIshould\fR send +DHCPNAK messages to misconfigured clients. If this is not done, +clients will be unable to get a correct IP address after changing +subnets until their old lease has expired, which could take quite a +long time. +.PP +Usually, writing \fBauthoritative;\fR at the top level of the file +should be sufficient. However, if a DHCP server is to be set up so +that it is aware of some networks for which it is authoritative and +some networks for which it is not, it may be more appropriate to +declare authority on a per-network-segment basis. +.PP +Note that the most specific scope for which the concept of authority +makes any sense is the physical network segment - either a +shared-network statement or a subnet statement that is not contained +within a shared-network statement. It is not meaningful to specify +that the server is authoritative for some subnets within a shared +network, but not authoritative for others, nor is it meaningful to +specify that the server is authoritative for some host declarations +and not others. +.PP +In order for DHCPINFORMs to be responded to by the server, +they must match to subnets over which the server has authority; +otherwise they will be ignored and logged. To minimize the +impact on logging volume, only the first and every subsequent 100th +occurrence of an ignored DHCPINFORM is logged. +.RE +.PP +The \fIboot-unknown-clients\fR statement +.RS 0.25i +.PP +.B boot-unknown-clients \fIflag\fB;\fR +.PP +If the \fIboot-unknown-clients\fR statement is present and has a value +of \fIfalse\fR or \fIoff\fR, then clients for which there is no +.I host +declaration will not be allowed to obtain IP addresses. If this +statement is not present or has a value of \fItrue\fR or \fIon\fR, +then clients without host declarations will be allowed to obtain IP +addresses, as long as those addresses are not restricted by +.I allow +and \fIdeny\fR statements within their \fIpool\fR declarations. +.RE +.PP +The \fIcheck-secs-byte-order\fR statement +.RS 0.25i +.PP +.B check-secs-byte-order \fIflag\fB;\fR +.PP +When \fIcheck-secs-byte-order\fR is enabled, the server will check for DHCPv4 +clients that do the byte ordering on the secs field incorrectly. This field +should be in network byte order but some clients get it wrong. When this +parameter is enabled the server will examine the secs field and if it looks +wrong (high byte non zero and low byte zero) swap the bytes. The default +is disabled. This parameter is only useful when doing load balancing within +failover. (Formerly, this behavior had to be enabled during compilation +configuration via --enable-secs-byteorder). +.PP +The \fIdb-time-format\fR statement +.RS 0.25i +.PP +.B db-time-format \fR[ \fIdefault\fR | \fIlocal\fR ] \fB;\fR +.PP +The DHCP server software outputs several timestamps when writing leases to +persistent storage. This configuration parameter selects one of two output +formats. The \fIdefault\fR format prints the day, date, and time in UTC, +while the \fIlocal\fR format prints the system seconds-since-epoch, and +helpfully provides the day and time in the system timezone in a comment. +The time formats are described in detail in the dhcpd.leases(5) manpage. +.RE +.PP +The \fIddns-hostname\fR statement +.RS 0.25i +.PP +.B ddns-hostname \fIname\fB;\fR +.PP +The \fIname\fR parameter should be the hostname that will be used in +setting up the client's A and PTR records. If no \fIddns-hostname\fR is +specified in scope, then the server will derive the hostname +automatically, using an algorithm that varies for each of the +different update methods. +.RE +.PP +The \fIddns-domainname\fR statement +.RS 0.25i +.PP +.B ddns-domainname \fIname\fB;\fR +.PP +The \fIname\fR parameter should be the domain name that will be +appended to the client's hostname to form a fully-qualified +domain-name (FQDN). +.RE +.PP +The \fIddns-dual-stack-mixed-mode\fR statement +.RS 0.25i +.PP +.B ddns-dual-stack-mixed-mode \fIflag\fB;\fR +.PP +The \fIddns-dual-stack-mixed-mode\fR parameter controls whether or not the +server applies Dual Stack Mixed Mode rules during DDNS conflict resolution. +This parameter is off by default, has no effect unless +update-conflict-detection is enabled, and may only be specified at the +global scope. +.RE +.PP +The \fIddns-guard-id-must-match\fR statement +.RS 0.25i +.PP +.B ddns-guard-id-must-match \fIflag\fB;\fR +.PP +The \fIddns-guard-id-must-match\fR parameter controls whether or not a +the client id within a DHCID RR must match that of the DNS update's client +to permit DNS entries associated with that DHCID RR to be ovewritten. +Proper conflict resolution requires ID matching and should only be disabled +after careful consideration. When disabled, it is allows any DNS updater to +replace DNS entries that have an associated DHCID RR, regardless of client +identity. This parameter is on by default, has no effect unless +update-conflict-detection is enabled, and may only be specified at the global +scope. +.RE +.PP +The \fddns-local-address4\fR and \fddns-local-address6\fR statements +.RS 0.25i +.PP +.B ddns-local-address4 \fIaddress\fB;\fR +.PP +.B ddns-local-address6 \fIaddress\fB;\fR +.PP +The \fIaddress\fR parameter should be the local IPv4 or IPv6 address +the server should use as the from address when sending DDNS update +requests. +.RE +.PP +The \fIddns-other-guard-is-dynamic\fR statement +.RS 0.25i +.PP +.B ddns-other-guard-is-dynamic \fIflag\fB;\fR +.PP +The \fIddns-other-guard-is-dynamic\fR parameter controls whether or not a +a server running DSMM will consider the presence of the other update style +DHCID RR as an indcation that a DNS entries may be overwritten. It should +only be enabled after careful study as it allows DNS entries that would +otherwise be protected as static, to be overwritten in certain cases. This +paramater is off by default, has no effect unless ddns-dual-stack-mixed-mode +is enabled, and may only be specified at the global scope. +.RE +.PP +The \fIddns-rev-domainname\fR statement +.RS 0.25i +.PP +.B ddns-rev-domainname \fIname\fB;\fR +.PP +The \fIname\fR parameter should be the domain name that will be +appended to the client's reversed IP address to produce a name for use +in the client's PTR record. By default, this is "in-addr.arpa.", but +the default can be overridden here. +.PP +The reversed IP address to which this domain name is appended is +always the IP address of the client, in dotted quad notation, reversed +- for example, if the IP address assigned to the client is +10.17.92.74, then the reversed IP address is 74.92.17.10. So a +client with that IP address would, by default, be given a PTR record +of 10.17.92.74.in-addr.arpa. +.RE +.PP +The \fIddns-update-style\fR parameter +.RS 0.25i +.PP +.B ddns-update-style \fIstyle\fB;\fR +.PP +The +.I style +parameter must be one of \fBstandard\fR, \fBinterim\fR or \fBnone\fR. +The \fIddns-update-style\fR statement is only meaningful in the outer +scope - it is evaluated once after reading the dhcpd.conf file, rather +than each time a client is assigned an IP address, so there is no way +to use different DNS update styles for different clients. The default +is \fBnone\fR. +.RE +.PP +.B The +.I ddns-updates +.B statement +.RS 0.25i +.PP + \fBddns-updates \fIflag\fR\fB;\fR +.PP +The \fIddns-updates\fR parameter controls whether or not the server will +attempt to do a DNS update when a lease is confirmed. Set this to \fIoff\fR +if the server should not attempt to do updates within a certain scope. +The \fIddns-updates\fR parameter is on by default. To disable DNS +updates in all scopes, it is preferable to use the +\fIddns-update-style\fR statement, setting the style to \fInone\fR. +.RE +.PP +The +.I default-lease-time +statement +.RS 0.25i +.PP +.B default-lease-time \fItime\fR\fB;\fR +.PP +.I Time +should be the length in seconds that will be assigned to a lease if +the client requesting the lease does not ask for a specific expiration +time. This is used for both DHCPv4 and DHCPv6 leases (it is also known +as the "valid lifetime" in DHCPv6). +The default is 43200 seconds. +.RE +.PP +The +.I delayed-ack +and +.I max-ack-delay +statements +.RS 0.25i +.PP +.B delayed-ack \fIcount\fR\fB;\fR +.PP +.B max-ack-delay \fImicroseconds\fR\fB;\fR +.PP +.I Count +should be an integer value from zero to 2^16-1 and defaults to 0, which means +that the feature is disabled. Otherwise, 28 may be a sensible starting point +for many configurations (SO_SNDBUF size / 576 bytes.) The count represents how +many DHCPv4 replies maximum will be queued pending transmission until after a +database commit event. If this number is reached, a database commit event +(commonly resulting in fsync() and representing a performance penalty) will be +made, and the reply packets will be transmitted in a batch afterwards. This +preserves the RFC2131 direction that "stable storage" be updated prior to +replying to clients. Should the DHCPv4 sockets "go dry" (select() returns +immediately with no read sockets), the commit is made and any queued packets +are transmitted. +.PP +Similarly, \fImicroseconds\fR indicates how many microseconds are permitted +to pass inbetween queuing a packet pending an fsync, and performing the +fsync. Valid values range from 0 to 2^32-1, and defaults to 250,000 (1/4 of +a second). +.PP +The delayed-ack feature is compiled in by default, but can be disabled +at compile time with \'./configure --disable-delayed-ack\'. Please note +that the delayed-ack feature is not currently compatible with support for +DHPCv4-over-DHCPv6 so when a 4to6 port ommand line argument enables this +in the server the delayed-ack value is reset to 0. +.RE +.PP +The +.I dhcp-cache-threshold +statement +.RS 0.25i +.PP +.B dhcp-cache-threshold \fIpercentage\fB;\fR +.PP +The \fIdhcp-cache-threshold\fR statement takes one integer parameter +with allowed values between 0 and 100. The default value is 25 (25% of +the lease time). This parameter expresses the percentage of the total +lease time, measured from the beginning, during which a +client's attempt to renew its lease will result in getting +the already assigned lease, rather than an extended lease. This feature +is supported for both IPv4 and IPv6 and down to the pool level and for +IPv6 all three pool types: NA, TA and PD. +.PP +Clients that attempt renewal frequently can cause the server to +update and write the database frequently resulting in a performance +impact on the server. The \fIdhcp-cache-threshold\fR +statement instructs the DHCP server to avoid updating leases too +frequently thus avoiding this behavior. Instead the server replies with the +same lease (i.e. reuses it) with no modifications except for CLTT (Client Last +Transmission Time) and for IPv4: + + the lease time sent to the client is shortened by the age of + the lease + +while for IPv6: + + the preferred and valid lifetimes sent to the client are + shortened by the age of the lease. + +None of these changes require writing the lease to disk. + +.PP +When an existing lease is matched to a renewing client, it will be reused +if all of the following conditions are true: +.nf + 1. The dhcp-cache-threshold is larger than zero + 2. The current lease is active + 3. The percentage of the lease time that has elapsed is less than + dhcp-cache-threshold + 4. The client information provided in the renewal does not alter + any of the following: + a. DNS information and DNS updates are enabled + b. Billing class to which the lease is associated (IPv4 only) + c. The host declaration associated with the lease (IPv4 only) + d. The client id - this may happen if a client boots without + a client id and then starts using one in subsequent + requests. (IPv4 only) +.fi +.PP +While lease data is not written to disk when a lease is reused, the server +will still execute any on-commit statements. +.PP +Note that the lease can be reused if the options the client or relay agent +sends are changed. These changes will not be recorded in the in-memory or +on-disk databases until the client renews after the threshold time is reached. +.RE +.PP +The +.I do-forward-updates +statement +.RS 0.25i +.PP +.B do-forward-updates \fIflag\fB;\fR +.PP +The \fIdo-forward-updates\fR statement instructs the DHCP server as +to whether it should attempt to update a DHCP client\'s A record +when the client acquires or renews a lease. This statement has no +effect unless DNS updates are enabled. Forward updates are enabled +by default. If this statement is used to disable forward updates, +the DHCP server will never attempt to update the client\'s A record, +and will only ever attempt to update the client\'s PTR record if the +client supplies an FQDN that should be placed in the PTR record using +the \fBfqdn\fR option. If forward updates are enabled, the DHCP server +will still honor the setting of the \fBclient-updates\fR flag. +.RE +.PP +The +.I dont-use-fsync +statement +.RS 0.25i +.PP +.B dont-use-fsync \fIflag\fB;\fR +.PP +The \fIdont-use-fsync\fR statement instructs the DHCP server if +it should call fsync() when writing leases to the lease file. By +default and if the flag is set to false the server \fBwill\fR call +fsync(). Suppressing the call to fsync() may increase the performance +of the server but it also adds a risk that a lease will not be +properly written to the disk after it has been issued to a client +and before the server stops. This can lead to duplicate leases +being issued to different clients. Using this option is \fBnot +recommended\FR. +.RE +.PP +The +.I dynamic-bootp-lease-cutoff +statement +.RS 0.25i +.PP +.B dynamic-bootp-lease-cutoff \fIdate\fB;\fR +.PP +The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time +for all leases assigned dynamically to BOOTP clients. Because BOOTP +clients do not have any way of renewing leases, and don't know that +their leases could expire, by default dhcpd assigns infinite leases +to all BOOTP clients. However, it may make sense in some situations +to set a cutoff date for all BOOTP leases - for example, the end of a +school term, or the time at night when a facility is closed and all +machines are required to be powered off. +.PP +.I Date +should be the date on which all assigned BOOTP leases will end. The +date is specified in the form: +.PP +.ce 1 +W YYYY/MM/DD HH:MM:SS +.PP +W is the day of the week expressed as a number +from zero (Sunday) to six (Saturday). YYYY is the year, including the +century. MM is the month expressed as a number from 1 to 12. DD is +the day of the month, counting from 1. HH is the hour, from zero to +23. MM is the minute and SS is the second. The time is always in +Coordinated Universal Time (UTC), not local time. +.RE +.PP +The +.I dynamic-bootp-lease-length +statement +.RS 0.25i +.PP +.B dynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR +.PP +The \fIdynamic-bootp-lease-length\fR statement is used to set the +length of leases dynamically assigned to BOOTP clients. At some +sites, it may be possible to assume that a lease is no longer in +use if its holder has not used BOOTP or DHCP to get its address within +a certain time period. The period is specified in \fIlength\fR as a +number of seconds. If a client reboots using BOOTP during the +timeout period, the lease duration is reset to \fIlength\fR, so a +BOOTP client that boots frequently enough will never lose its lease. +Needless to say, this parameter should be adjusted with extreme +caution. +.RE +.PP +The +.I echo-client-id +statement +.RS 0.25i +.PP +.B echo-client-id\fR \fIflag\fR\fB;\fR +.PP +The \fIecho-client-id\fR statement is used to enable or disable RFC 6842 +compliant behavior. If the echo-client-id statement is present and has a +value of true or on, and a DHCP DISCOVER or REQUEST is received which contains +the client identifier option (Option code 61), the server will copy the option +into its response (DHCP ACK or NAK) per RFC 6842. In other words if the +client sends the option it will receive it back. By default, this flag is off +and client identifiers will not echoed back to the client. +.RE +.PP +The +.I filename +statement +.RS 0.25i +.PP +.B filename\fR \fB"\fR\fIfilename\fR\fB";\fR +.PP +The \fIfilename\fR statement can be used to specify the name of the +initial boot file which is to be loaded by a client. The +.I filename +should be a filename recognizable to whatever file transfer protocol +the client can be expected to use to load the file. +.RE +.PP +The +.I fixed-address +declaration +.RS 0.25i +.PP +.B fixed-address address\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR +.PP +The \fIfixed-address\fR declaration is used to assign one or more fixed +IP addresses to a client. It should only appear in a \fIhost\fR +declaration. If more than one address is supplied, then when the +client boots, it will be assigned the address that corresponds to the +network on which it is booting. If none of the addresses in the +\fIfixed-address\fR statement are valid for the network to which the client +is connected, that client will not match the \fIhost\fR declaration +containing that \fIfixed-address\fR declaration. Each \fIaddress\fR +in the \fIfixed-address\fR declaration should be either an IP address or +a domain name that resolves to one or more IP addresses. +.RE +.PP +The +.I fixed-address6 +declaration +.RS 0.25i +.PP +.B fixed-address6 ip6-address\fR ;\fR +.PP +The \fIfixed-address6\fR declaration is used to assign a fixed +IPv6 addresses to a client. It should only appear in a \fIhost\fR +declaration. +.RE +.PP +The +.I fixed-prefix6 +declaration +.RS 0.25i +.PP +.B fixed-prefix6\fR \fIlow-address\fR \fB/\fR \fIbits\fR\fB;\fR +.PP +The \fIfixed-prefix6\fR declaration is used to assign a fixed +IPv6 prefix to a client. It should only appear in a \fIhost\fR +declaration, but multiple \fIfixed-prefix6\fR statements may appear +in a single \fIhost\fR declaration. +.PP +The \fIlow-address\fR specifies the start of the prefix and the \fIbits\fR +specifies the size of the prefix in bits. +.PP +If there are multiple prefixes for a given host entry the server will +choose one that matches the requested prefix size or, if none match, +the first one. +.PP +If there are multiple \fIhost\fR declarations the server will try to +choose a declaration where the \fIfixed-address6\fR matches the client's +subnet. If none match it will choose one that doesn't have a \fIfixed-address6\fR +statement. +.PP +Note Well: Unlike the fixed address the fixed prefix does not need to match +a subnet in order to be served. This allows you to provide a prefix to +a client that is outside of the subnet on which the client makes the request +to the the server. +.RE +.PP +The +.I get-lease-hostnames +statement +.RS 0.25i +.PP +.B get-lease-hostnames\fR \fIflag\fR\fB;\fR +.PP +The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether +or not to look up the domain name corresponding to the IP address of +each address in the lease pool and use that address for the DHCP +\fIhostname\fR option. If \fIflag\fR is true, then this lookup is +done for all addresses in the current scope. By default, or if +\fIflag\fR is false, no lookups are done. +.RE +.PP +The +.I hardware +statement +.RS 0.25i +.PP +.B hardware \fIhardware-type hardware-address\fB;\fR +.PP +In order for a BOOTP client to be recognized, its network hardware +address must be declared using a \fIhardware\fR clause in the +.I host +statement. +.I hardware-type +must be the name of a physical hardware interface type. Currently, +only the +.B ethernet +and +.B token-ring +types are recognized, although support for a +.B fddi +hardware type (and others) would also be desirable. +The +.I hardware-address +should be a set of hexadecimal octets (numbers from 0 through ff) +separated by colons. The \fIhardware\fR statement may also be used +for DHCP clients. +.RE +.PP +The +.I host-identifier option +statement +.RS 0.25i +.PP +.B host-identifier option \fIoption-name option-data\fB;\fR +.PP +or +.PP +.B host-identifier v6relopt \fInumber option-name option-data\fB;\fR +.PP +This identifies a DHCPv6 client in a +.I host +statement. +.I option-name +is any option, and +.I option-data +is the value for the option that the client will send. The +.I option-data +must be a constant value. In the v6relopts case the additional number +is the relay to examine for the specified option name and value. The +values are the same as for the v6relay option. 0 is a no-op, 1 is the +relay closest to the client, 2 the next one in and so on. Values that +are larger than the maximum number of relays (currently 32) indicate the +relay closest to the server independent of number. +.RE +.PP +The +.I ignore-client-uids +statement +.RS 0.25i +.PP +.B ignore-client-uids \fIflag\fB;\fR +.PP +If the \fIignore-client-uids\fR statement is present and has a value of +\fItrue\fR or \fIon\fR, the UID for clients will not be recorded. +If this statement is not present or has a value of \fIfalse\fR or +\fIoff\fR, then client UIDs will be recorded. +.RE +.PP +The +.I infinite-is-reserved +statement +.RS 0.25i +.PP +.B infinite-is-reserved \fIflag\fB;\fR +.PP +ISC DHCP now supports \'reserved\' leases. See the section on RESERVED LEASES +below. If this \fIflag\fR is on, the server will automatically reserve leases +allocated to clients which requested an infinite (0xffffffff) lease-time. +.PP +The default is off. +.RE +.PP +The +.I lease-file-name +statement +.RS 0.25i +.PP +.B lease-file-name \fIname\fB;\fR +.PP +.I Name +Where \fIname\fR is the name of the DHCP server's lease file. By default, +this is DBDIR/dhcpd.leases. This statement \fBmust\fR appear in the outer +scope of the configuration file - if it appears in some other scope, it will +have no effect. The value must be the absolute path of the file to use. +The order of precedence the server uses for the lease file name +is: +.PP + 1. \fBlease-file-name\fR configuration file statement. + 2. \fB-lf\fR command line flag. + 3. \fBPATH_DHCPD_DB\fR environment variable. +.RE +.PP +The +.I dhcpv6-lease-file-name +statement +.RS 0.25i +.PP +.B dhcpv6-lease-file-name \fIname\fB;\fR +.PP +Where \fIname\fR is the name of the DHCP server's lease file when the server +is running DHCPv6. By default, this is DBDIR/dhcpd6.leases. This statement +\fBmust\fR appear in the outer scope of the configuration file - if it appears +in some other scope, it will have no effect. The value must be the absolute +path of the file to use. The order of precedence the server uses +for the lease file name is: +.PP + 1. \fBdhcpv6-lease-file-name\fR configuration file statement. + 2. \fB-lf\fR command line flag. + 3. \fBPATH_DHCPD6_DB\fR environment variable. +.RE +.PP +The +.I lease-id-format +parameter +.RS 0.25i +.PP +.B lease-id-format \fIformat\fB;\fR +.PP +The \fIformat\fR parameter must be either \fBoctal\fR or \fBhex\fR. +This parameter governs the format used to write certain values to lease +files. With the default format, octal, values are written as quoted strings in +which non-printable characters are represented as octal escapes - +a backslash character followed by three octal digits. When the hex format +is specified, values are written as an unquoted series of pairs of +hexadecimal digits, separated by colons. + +Currently, the values written out based on lease-id-format are the server-duid, +the uid (DHCPv4 leases), and the IAID_DUID (DHCPv6 leases). Note the server +automatically reads the values in either format. +.RE +.PP +The +.I limit-addrs-per-ia +statement +.RS 0.25i +.PP +.B limit-addrs-per-ia \fInumber\fB;\fR +.PP +By default, the DHCPv6 server will limit clients to one IAADDR per IA +option, meaning one address. If you wish to permit clients to hang onto +multiple addresses at a time, configure a larger \fInumber\fR here. +.PP +Note that there is no present method to configure the server to forcibly +configure the client with one IP address per each subnet on a shared network. +This is left to future work. +.RE +.PP +The +.I local-port +statement +.RS 0.25i +.PP +.B local-port \fIport\fB;\fR +.PP +This statement causes the DHCP server to listen for DHCP requests on +the UDP port specified in \fIport\fR, rather than on port 67. +.RE +.PP +The +.I local-address +statement +.RS 0.25i +.PP +.B local-address \fIaddress\fB;\fR +.PP +This statement causes the DHCP server to listen for DHCP requests sent +to the specified \fIaddress\fR, rather than requests sent to all addresses. +Since serving directly attached DHCP clients implies that the server must +respond to requests sent to the all-ones IP address, this option cannot be +used if clients are on directly attached networks; it is only realistically +useful for a server whose only clients are reached via unicasts, such as via +DHCP relay agents. +.PP +Note: This statement is only effective if the server was compiled using +the USE_SOCKETS #define statement, which is default on a small number of +operating systems, and must be explicitly chosen at compile-time for all +others. You can be sure if your server is compiled with USE_SOCKETS if +you see lines of this format at startup: +.PP + Listening on Socket/eth0 +.PP +Note also that since this bind()s all DHCP sockets to the specified +address, that only one address may be supported in a daemon at a given +time. +.RE +.PP +The +.I local-address6 +and +.I bind-local-address6 +statements +.RS 0.25i +.PP +.B local-address6 \fIaddress\fB;\fR +.PP +.B bind-local-address6 \fIflag\fB;\fR +.PP +The \fIlocal-address6\fR statement causes the DHCP server to send IPv6 +packets as originating from the specified IPv6 \fIaddress\fR, rather than +leaving the kernel to fill in the source address field. +.PP +When \fIbind-local-address6\fR is present and has a value of true or on, +service sockets are bound to \fIaddress\fR too. +.PP +By default \fIaddress\fR is the undefined address and the +\fIbind-local-address6\fR is disabled, both may only be set at the global +scope. +.RE +.PP +The +.I log-facility +statement +.RS 0.25i +.PP +.B log-facility \fIfacility\fB;\fR +.PP +This statement causes the DHCP server to do all of its logging on the +specified log facility once the dhcpd.conf file has been read. By +default the DHCP server logs to the daemon facility. Possible log +facilities include auth, authpriv, cron, daemon, ftp, kern, lpr, mail, +mark, news, ntp, security, syslog, user, uucp, and local0 through +local7. Not all of these facilities are available on all systems, +and there may be other facilities available on other systems. +.PP +In addition to setting this value, you may need to modify your +.I syslog.conf +file to configure logging of the DHCP server. For example, you might +add a line like this: +.PP +.nf + local7.debug /var/log/dhcpd.log +.fi +.PP +The syntax of the \fIsyslog.conf\fR file may be different on some +operating systems - consult the \fIsyslog.conf\fR manual page to be +sure. To get syslog to start logging to the new file, you must first +create the file with correct ownership and permissions (usually, the +same owner and permissions of your /var/log/messages or +/usr/adm/messages file should be fine) and send a SIGHUP to syslogd. +Some systems support log rollover using a shell script or program +called newsyslog or logrotate, and you may be able to configure this +as well so that your log file doesn't grow uncontrollably. +.PP +Because the \fIlog-facility\fR setting is controlled by the dhcpd.conf +file, log messages printed while parsing the dhcpd.conf file or before +parsing it are logged to the default log facility. To prevent this, +see the README file included with this distribution, which describes +BUG: where is that mentioned in README? +how to change the default log facility. When this parameter is used, +the DHCP server prints its startup message a second time after parsing +the configuration file, so that the log will be as complete as +possible. +.RE +.PP +The +.I log-threshold-high +and +.I log-threshold-low +statements +.RS 0.25i +.PP +.B log-threshold-high \fIpercentage\fB;\fR +.PP +.B log-threshold-low \fIpercentage\fB;\fR +.PP +The \fIlog-threshold-low\fR and \fIlog-threshold-high\fR statements +are used to control when a message is output about pool usage. The +value for both of them is the percentage of the pool in use. If the +high threshold is 0 or has not been specified, no messages will be +produced. If a high threshold is given, a message is output once the +pool usage passes that level. After that, no more messages will be +output until the pool usage falls below the low threshold. If the low +threshold is not given, it default to a value of zero. +.PP +A special case occurs when the low threshold is set to be higer than +the high threshold. In this case, a message will be generated each time +a lease is acknowledged when the pool usage is above the high threshold. +.PP +Note that threshold logging will be automatically disabled for shared +subnets whose total number of addresses is larger than (2^64)-1. The server +will emit a log statement at startup when threshold logging is disabled as +shown below: + + "Threshold logging disabled for shared subnet of ranges: " + +This is likely to have no practical runtime effect as CPUs are unlikely +to support a server actually reaching such a large number of leases. +.RE +.PP +The +.I max-lease-time +statement +.RS 0.25i +.PP +.B max-lease-time \fItime\fR\fB;\fR +.PP +.I Time +should be the maximum length in seconds that will be assigned to a +lease. +If not defined, the default maximum lease time is 86400. +The only exception to this is that Dynamic BOOTP lease +lengths, which are not specified by the client, are not limited by +this maximum. +.RE +.PP +The +.I min-lease-time +statement +.RS 0.25i +.PP +.B min-lease-time \fItime\fR\fB;\fR +.PP +.I Time +should be the minimum length in seconds that will be assigned to a +lease. +The default is the minimum of 300 seconds or +\fBmax-lease-time\fR. +.RE +.PP +The +.I min-secs +statement +.RS 0.25i +.PP +.B min-secs \fIseconds\fR\fB;\fR +.PP +.I Seconds +should be the minimum number of seconds since a client began trying to +acquire a new lease before the DHCP server will respond to its request. +The number of seconds is based on what the client reports, and the maximum +value that the client can report is 255 seconds. Generally, setting this +to one will result in the DHCP server not responding to the client's first +request, but always responding to its second request. +.PP +This can be used +to set up a secondary DHCP server which never offers an address to a client +until the primary server has been given a chance to do so. If the primary +server is down, the client will bind to the secondary server, but otherwise +clients should always bind to the primary. Note that this does not, by +itself, permit a primary server and a secondary server to share a pool of +dynamically-allocatable addresses. +.RE +.PP +The +.I next-server +statement +.RS 0.25i +.PP +.B next-server\fR \fIserver-name\fR\fB;\fR +.PP +The \fInext-server\fR statement is used to specify the host address of +the server from which the initial boot file (specified in the +\fIfilename\fR statement) is to be loaded. \fIServer-name\fR should +be a numeric IP address or a domain name. +.RE +.PP +The +.I omapi-port +statement +.RS 0.25i +.PP +.B omapi-port\fR \fIport\fR\fB;\fR +.PP +The \fIomapi-port\fR statement causes the DHCP server to listen for +OMAPI connections on the specified port. This statement is required +to enable the OMAPI protocol, which is used to examine and modify the +state of the DHCP server as it is running. +.RE +.PP +The +.I one-lease-per-client +statement +.RS 0.25i +.PP +.B one-lease-per-client \fIflag\fR\fB;\fR +.PP +If this flag is enabled, whenever a client sends a DHCPREQUEST for a +particular lease, the server will automatically free any other leases +the client holds. This presumes that when the client sends a +DHCPREQUEST, it has forgotten any lease not mentioned in the +DHCPREQUEST - i.e., the client has only a single network interface +.I and +it does not remember leases it's holding on networks to which it is +not currently attached. Neither of these assumptions are guaranteed +or provable, so we urge caution in the use of this statement. +.RE +.PP +The +.I persist-eui-64-leases +statement +.RS 0.25i +.PP +.B persist-eui-64-leases \fIflag\fR\fB;\fR +.PP +When this flag is enabled, the server will write EUI-64 based leases to the +leases file. Since such leases can only, ever be valid for a single DUID value +it can be argued that writing them to the leases file isn't essential and not +doing so may have perfomance advantages. See \fIuse-eui-64\fR statement for +more details on EUI-64 based address allocation. The flag is enabled by +default and may only be set at the global scope. +.RE +.PP +The +.I pid-file-name +statement +.RS 0.25i +.PP +.B pid-file-name +.I name\fR\fB;\fR +.PP +.I Name +should be the name of the DHCP server's process ID file. This is the +file in which the DHCP server's process ID is stored when the server +starts. By default, this is RUNDIR/dhcpd.pid. Like the \fIlease-file-name\fR +statement, this statement must appear in the outer scope of the configuration +file. The order of precedence used by the server is: +.PP + 1. \fBpid-file-name\fR configuration file statement. + 2. \fB-lf\fR command line flag. + 3. \fBPATH_DHCPD_PID\fR environment variable. +.PP +The +.I dhcpv6-pid-file-name +statement +.RS 0.25i +.PP +.B dhcpv6-pid-file-name \fIname\fB;\fR +.PP +.I Name +is the name of the pid file to use if and only if the server is running +in DHCPv6 mode. By default, this is DBDIR/dhcpd6.pid. This statement, +like \fIpid-file-name\fr, \fBmust\fR appear in the outer scope of the +configuration file. The order of precedence used by the server is: +.PP + 1. \fBdhcpv6-pid-file-name\fR configuration file statement. + 2. \fB-lf\fR command line flag. + 3. \fBPATH_DHCPD6_PID\fR environment variable. +.PP +.RE +.PP +The +.I ping-check +statement +.RS 0.25i +.PP +.B ping-check +.I flag\fR\fB;\fR +.PP +When the DHCP server is considering dynamically allocating an IP +address to a client, it first sends an ICMP Echo request (a \fIping\fR) +to the address being assigned. It waits for a second, and if no +ICMP Echo response has been heard, it assigns the address. If a +response \fIis\fR heard, the lease is abandoned, and the server does +not respond to the client. The lease will remain abandoned for a minimum +of abandon-lease-time seconds. +.PP +If a there are no free addressses but there are abandoned IP addresses, the +DHCP server will attempt to reclaim an abandoned IP address regardless of the +value of abandon-lease-time. +.PP +This \fIping check\fR introduces a default one-second delay in responding +to DHCPDISCOVER messages, which can be a problem for some clients. The +default delay of one second may be configured using the ping-timeout +parameter. The ping-check configuration parameter can be used to control +checking - if its value is false, no ping check is done. +.RE +.PP +The +.I ping-cltt-secs +statement +.RS 0.25i +.PP +.B ping-cltt-secs +.I seconds\fR\fB;\fR +.PP +The server will conduct a ping check if all the following conditions are true: +.PP +1. Ping checking is enabled. +.PP +2. The server is responding to a DISCOVER. +.PP +3. The lease to be offered is neither static nor active (i.e. still a valid +lease). +.PP +4. And any of the following are true: + a. This will be the first offer of this lease (CLTT is 0). + b. The lease is being offered to a client other than its previous owner + c. The lease is being offered to its previous owner and more than + \fBping-cltt-secs\fR have elapsed since CLTT of the original lease. + d. The lease was abandoned and the server is attempting to reclaim it. + +.PP +The \fBping-cltt-secs\fR statement allows the user to specify the amount of +time that must elaspe after CLTT before a ping check will be conducted. +The default value is sixty seconds. +.RE +.PP +The +.I ping-timeout +statement +.RS 0.25i +.PP +.B ping-timeout +.I seconds\fR\fB;\fR +.PP +If the DHCP server determined it should send an ICMP echo request (a +\fIping\fR) because the ping-check statement is true, ping-timeout allows +you to configure how many seconds the DHCP server should wait for an +ICMP Echo response to be heard, if no ICMP Echo response has been received +before the timeout expires, it assigns the address. If a response \fIis\fR +heard, the lease is abandoned, and the server does not respond to the client. +If no value is set, ping-timeout defaults to 1 second. (See also ping-timeout-ms +below) +.RE +.PP +The +.I ping-timeout-ms +statement +.RS 0.25i +.PP +.B ping-timeout-ms +.I milliseconds\fR\fB;\fR +.PP +Allows you to specify the ping timeout in milliseconds rather than +seconds. If this value is greater than zero, the server will use it +in place of ping-timeout. The default value is zero. +.RE +.PP +The +.I preferred-lifetime +statement +.RS 0.25i +.PP +.B preferred-lifetime +.I seconds\fR\fB;\fR +.PP +IPv6 addresses have \'valid\' and \'preferred\' lifetimes. The valid lifetime +determines at what point a lease might be said to have expired, and is no +longer useable. A preferred lifetime is an advisory condition to help +applications move off of the address and onto currently valid addresses +(should there still be any open TCP sockets or similar). +.PP +The preferred lifetime defaults to 5/8 the default lease time. +.RE +.PP +The +.I prefix-length-mode +statement +.RS 0.25i +.PP +.B prefix-length-mode +.I mode\fR\fB;\fR +.PP +According to RFC 3633, DHCPv6 clients may specify preferences when soliciting +prefixes by including an IA_PD Prefix option within the IA_PD option. Among +the preferences that may be conveyed is the "prefix-length". When non-zero it +indicates a client's desired length for offered prefixes. The RFC states that +servers "MAY choose to use the information...to select prefix(es)" but does +not specify any particular rules for doing so. The prefix-length-mode statement +can be used to set the prefix selection rules employed by the server, +when clients send a non-zero prefix-length value. The mode parameter must +be one of \fBignore\fR, \fBprefer\fR, \fBexact\fR, \fBminimum\fR, or +\fBmaximum\fR where: +.PP +1. ignore - The requested length is ignored. The server will offer the first +available prefix. +.PP +2. prefer - The server will offer the first available prefix with the same +length as the requested length. If none are found then it will offer the +first available prefix of any length. This is the default behavior. +.PP +3. exact - The server will offer the first available prefix with the same +length as the requested length. If none are found, it will return a status +indicating no prefixes available. +.PP +4. minimum - The server will offer the first available prefix with the same +length as the requested length. If none are found, it will return the first +available prefix whose length is greater than (e.g. longer than), the +requested value. If none of those are found, it will return a status +indicating no prefixes available. For example, if client requests a length +of /60, and the server has available prefixes of lengths /56 and /64, it will +offer prefix of length /64. +.PP +5. maximum - The server will offer the first available prefix with the same +length as the requested length. If none are found, it will return the first +available prefix whose length is less than (e.g. shorter than), the +requested value. If none of those are found, it will return a status +indicating no prefixes available. For example, if client requests a length +of /60, and the server has available prefixes of lengths /56 and /64, it will +offer a prefix of length /56. +.PP +In general "first available" is determined by the order in which pools are +defined in the server's configuration. For example, if a subnet is defined +with three prefix pools A,B, and C: +.PP +.nf +subnet 3000::/64 { + # pool A + pool6 { + : + } + # pool B + pool6 { + : + } + # pool C + pool6 { + : + } +} +.fi +.PP +then the pools will be checked in the order A, B, C. For modes \fBprefer\fR, +\fBminimum\fR, and \fBmaximum\fR this may mean checking the pools in that order +twice. A first pass through is made looking for an available prefix of exactly +the preferred length. If none are found, then a second pass is performed +starting with pool A but with appropriately adjusted length criteria. +.RE +.PP +The +.I release-on-roam +statement +.RS 0.25i +.PP +.B release-on-roam \fIflag\fB;\fR +.PP +When enabled and the dhcpd server detects that a DHCPv6 client (IAID+DUID) +has roamed to a new network, it will release the pre-existing leases on the +old network and emit a log statement similiar to the following: + + "Client: roamed to new network, releasing lease:
" + +The server will carry out all of the same steps that would normally occur +when a client explicitly releases a lease. When release-on-roam is disabled +(the default) the server makes such leases unavailable until they expire or +the server is restarted. Clients that need leases in multiple networks must +supply a unique IAID in each IA. This parameter may only be specified at +the global level. +.RE +.PP +The +.I remote-port +statement +.RS 0.25i +.PP +.B remote-port \fIport\fB;\fR +.PP +This statement causes the DHCP server to transmit DHCP responses to DHCP +clients upon the UDP port specified in \fIport\fR, rather than on port 68. +In the event that the UDP response is transmitted to a DHCP Relay, the +server generally uses the \fBlocal-port\fR configuration value. Should the +DHCP Relay happen to be addressed as 127.0.0.1, however, the DHCP Server +transmits its response to the \fBremote-port\fR configuration value. This +is generally only useful for testing purposes, and this configuration value +should generally not be used. +.RE +.PP +The +.I server-identifier +statement +.RS 0.25i +.PP +.B server-identifier \fIhostname\fR\fB;\fR +.PP +The server-identifier statement can be used to define the value that +is sent in the DHCP Server Identifier option for a given scope. The +value specified \fBmust\fR be an IP address for the DHCP server, and +must be reachable by all clients served by a particular scope. +.PP +The use of the server-identifier statement is not recommended - the only +reason to use it is to force a value other than the default value to be +sent on occasions where the default value would be incorrect. The default +value is the first IP address associated with the physical network interface +on which the request arrived. +.PP +The usual case where the +\fIserver-identifier\fR statement needs to be sent is when a physical +interface has more than one IP address, and the one being sent by default +isn't appropriate for some or all clients served by that interface. +Another common case is when an alias is defined for the purpose of +having a consistent IP address for the DHCP server, and it is desired +that the clients use this IP address when contacting the server. +.PP +Supplying a value for the dhcp-server-identifier option is equivalent +to using the server-identifier statement. +.RE +.PP +The +.I server-id-check +statement +.RS 0.25i +.PP +.B server-id-check \fIflag\fR\fB;\fR +.PP +The server-id-check statement is used to control whether or not a server, +participating in failover, verifies that the value of the +dhcp-server-identifier option in received DHCP REQUESTs match the server's +id before processing the request. Server id checking is disabled by default. +Setting this flag enables id checking and thereafter the server will only +process requests that match. Note the flag setting should be consistent +between failover partners. +.PP +Unless overridden by use of the server-identifier statement, the value the +server uses as its id will be the first IP address associated with the +physical network interface on which the request arrived. +.PP +In order to reduce runtime overhead the server only checks for a server id +option in the global and subnet scopes. Complicated configurations +may result in different server ids for this check and when the server id for +a reply packet is determined, which would prohibit the server from responding. +.PP +The primary use for this option is when a client broadcasts a request +but requires that the response come from a specific failover peer. +An example of this would be when a client reboots while its lease is still +active - in this case both servers will normally respond. Most of the +time the client won't check the server id and can use either of the responses. +However if the client does check the server id it may reject the response +if it came from the wrong peer. If the timing is such that the "wrong" +peer responds first most of the time the client may not get an address for +some time. +.PP +Care should be taken before enabling this option. +.PP +.RE +.PP +The +.I server-duid +statement +.RS 0.25i +.PP +.B server-duid \fILLT\fR [ \fIhardware-type\fR \fItimestamp\fR \fIhardware-address\fR ] \fB;\fR + +.B server-duid \fIEN\fR \fIenterprise-number\fR \fIenterprise-identifier\fR \fB;\fR + +.B server-duid \fILL\fR [ \fIhardware-type\fR \fIhardware-address\fR ] \fB;\fR +.PP +The server-duid statement configures the server DUID. You may pick either +LLT (link local address plus time), EN (enterprise), or LL (link local). +.PP +If you choose LLT or LL, you may specify the exact contents of the DUID. +Otherwise the server will generate a DUID of the specified type. +.PP +If you choose EN, you must include the enterprise number and the +enterprise-identifier. +.PP +If there is a server-duid statement in the lease file it will take precedence +over the server-duid statement from the config file and a +dhcp6.server-id option in the config file will override both. +.PP +The default server-duid type is LLT. +.RE +.PP +The +.I server-name +statement +.RS 0.25i +.PP +.B server-name "\fIname\fB";\fR +.PP +The \fIserver-name\fR statement can be used to inform the client of +the name of the server from which it is booting. \fIName\fR should +be the name that will be provided to the client. +.RE +.PP +The +.I dhcpv6-set-tee-times +statement +.RS 0.25i +.PP +.B dhcpv6-set-tee-times\fR \fIflag\fR\fB;\fR +.PP +The \fIdhcpv6-set-tee-times\fR statement enables setting T1 and T2 to the +values recommended in RFC 3315 (Section 22.4). When setting T1 and T2, the +server will use dhcp-renewal-time and dhcp-rebinding-time, respectively. +A value of zero tells the client it may choose its own value. + +When those options are not defined then values will be set to zero unless the +global \fIdhcpv6-set-tee-times\fR is enabled. When this option is enabled the +times are calculated as recommended by RFC 3315, Section 22.4: + + T1 will be set to 0.5 times the shortest preferred lifetime + in the reply. If the "shortest" preferred lifetime is + 0xFFFFFFFF, T1 will set to 0xFFFFFFFF. + + T2 will be set to 0.8 times the shortest preferred lifetime + in the reply. If the "shortest" preferred lifetime is + 0xFFFFFFFF, T2 will set to 0xFFFFFFFF. + +Keep in mind that given sufficiently small lease lifetimes, the above +calculations will result in the two values being equal. For example, a 9 second +lease lifetime would yield T1 = T2 = 4 seconds, which would cause clients to +issue rebinds only. In such a case it would likely be better to explicitly +define the values. + +Note that dhcpv6-set-tee-times is intended to be transitional and will likely +be removed in a future release. Once removed the behavior will be to use +the configured values when present or calculate them per the RFC. If you want +zeros, define them as zeros. +.RE +.PP +The +.I site-option-space +statement +.RS 0.25i +.PP +.B site-option-space "\fIname\fB";\fR +.PP +The \fIsite-option-space\fR statement can be used to determine from +what option space site-local options will be taken. This can be used +in much the same way as the \fIvendor-option-space\fR statement. +Site-local options in DHCP are those options whose numeric codes are +greater than 224. These options are intended for site-specific +uses, but are frequently used by vendors of embedded hardware that +contains DHCP clients. Because site-specific options are allocated +on an ad hoc basis, it is quite possible that one vendor's DHCP client +might use the same option code that another vendor's client uses, for +different purposes. The \fIsite-option-space\fR option can be used +to assign a different set of site-specific options for each such +vendor, using conditional evaluation (see \fBdhcp-eval (5)\fR for +details). +.RE +.PP +The +.I stash-agent-options +statement +.RS 0.25i +.PP +.B stash-agent-options \fIflag\fB;\fR +.PP +If the \fIstash-agent-options\fR parameter is true for a given client, +the server will record the relay agent information options sent during +the client's initial DHCPREQUEST message when the client was in the +SELECTING state and behave as if those options are included in all +subsequent DHCPREQUEST messages sent in the RENEWING state. This +works around a problem with relay agent information options, which is +that they usually not appear in DHCPREQUEST messages sent by the +client in the RENEWING state, because such messages are unicast +directly to the server and not sent through a relay agent. +.RE +.PP +The +.I update-conflict-detection +statement +.RS 0.25i +.PP +.B update-conflict-detection \fIflag\fB;\fR +.PP +If the \fIupdate-conflict-detection\fR parameter is true, the server will +perform standard DHCID multiple-client, one-name conflict detection. If +the parameter has been set false, the server will skip this check and +instead simply tear down any previous bindings to install the new +binding without question. The default is true and this parameter may only +be specified at the global scope. +.RE +.PP +The +.I update-optimization +statement +.RS 0.25i +.PP +.B update-optimization \fIflag\fB;\fR +.PP +If the \fIupdate-optimization\fR parameter is false for a given client, +the server will attempt a DNS update for that client each time the +client renews its lease, rather than only attempting an update when it +appears to be necessary. This will allow the DNS to heal from +database inconsistencies more easily, but the cost is that the DHCP +server must do many more DNS updates. We recommend leaving this option +enabled, which is the default. If this parameter is not specified, +or is true, the DHCP server +will only update when the client information changes, the client gets a +different lease, or the client's lease expires. +.RE +.PP +The +.I update-static-leases +statement +.RS 0.25i +.PP +.B update-static-leases \fIflag\fB;\fR +.PP +The \fIupdate-static-leases\fR flag, if enabled, causes the DHCP +server to do DNS updates for clients even if those clients are being +assigned their IP address using a \fIfixed-address\fR or +\fIfixed-address6\fR statement - that is, the client is being given a +static assignment. It is not recommended because the DHCP server has +no way to tell that the update has been done, and therefore will not +delete the record when it is not in use. Also, the server must attempt +the update each time the client renews its lease, which could have a +significant performance impact in environments that place heavy demands +on the DHCP server. This feature is supported for both DHCPv4 and DHCPv6, +and update modes standard or interim. It is disabled by default. +.RE +.PP +The +.I use-eui-64 +statement +.RS 0.25i +.PP +.B use-eui-64 \fIflag\fB;\fR +.PP + +(Support for this must be enabled at compile time, see EUI_64 in + includes/site.h) + +The \fIuse-eui-64\fR flag, if enabled, instructs the server to construct an +address using the client's EUI-64 DUID (Type 3, HW Type EUI-64), rather than +creating an address using the dynamic algorithm. This means that a given DUID +will always generate the same address for a given pool and further that the +address is guaranteed to be unique to that DUID. The IPv6 address will be +calculated from the EUI-64 link layer address, conforming to RFC 2373, unless +there is a host declaration for the client-id. + +The range6 statement for EUI-64 must define full /64 bit ranges. Invalid ranges +will be flagged during configuration parsing as errors. See the following +example: + + subnet6 fc00:e4::/64 { + use-eui-64 true; + range6 fc00:e4::/64; + } + +The statement may be specified down to the pool level, allowing a mixture of +dynamic and EUI-64 based pools. + +During lease file parsing, any leases which map to an EUI-64 pool, that have a +non-EUI-64 DUID or for which the lease address is not the EUI-64 address for +that DUID in that pool, will be discarded. + +If a host declaration exists for the DUID, the server grants the address +(fixed-prefix6, fixed-address6) according to the host declaration, regardless +of the DUID type of the client (even for EUI-64 DUIDs). + +If a client request's an EUI-64 lease for a given network, and the resultant +address conflicts with a fixed address reservation, the server will send the +client a "no addresses available" response. + +Any client with a non-conforming DUID (not type 3 or not hw type EUI-64) that +is not linked to a host declaration, which requests an address from an EUI-64 +enabled pool will be ignored and the event will be logged. + +Pools that are configured for EUI-64 will be skipped for dynamic allocation. +If there are no pools in the shared network from which to allocate, the client +will get back a no addresses available status. + +On an EUI-64 enabled pool, any client with a DUID 3, HW Type EUI-64, requesting +a solicit/renew and including IA_NA that do not match the EUI-64 policy, they +will be treated as though they are "outside" the subnet for a given client +message: + + Solicit - Server will advertise with EUI-64 ia suboption, but with rapid + commit off + Request - Server will send "an address not on link status", and no ia + suboption Renew/Rebind - Server will send the requested address ia + suboption with lifetimes of 0, plus an EUI-64 ia + +Whether or not EUI-64 based leases are written out to the lease database +may be controlled by \fIpersist-eui-64-leases\fR statement. +.RE +.PP +The +.I use-host-decl-names +statement +.RS 0.25i +.PP +.B use-host-decl-names \fIflag\fB;\fR +.PP +If the \fIuse-host-decl-names\fR parameter is true in a given scope, +then for every host declaration within that scope, the name provided +for the host declaration will be supplied to the client as its +hostname. So, for example, +.PP +.nf + group { + use-host-decl-names on; + + host joe { + hardware ethernet 08:00:2b:4c:29:32; + fixed-address joe.example.com; + } + } + +is equivalent to + + host joe { + hardware ethernet 08:00:2b:4c:29:32; + fixed-address joe.example.com; + option host-name "joe"; + } +.fi +.PP +Additionally, enabling use-host-decl-names instructs the server to use +the host declaration name in the the forward DNS name, if no other values +are available. This value selection process is discussed in more detail +under DNS updates. +.PP +An \fIoption host-name\fR statement within a host declaration will +override the use of the name in the host declaration. +.PP +It should be noted here that most DHCP clients completely ignore the +host-name option sent by the DHCP server, and there is no way to +configure them not to do this. So you generally have a choice of +either not having any hostname to client IP address mapping that the +client will recognize, or doing DNS updates. It is beyond +the scope of this document to describe how to make this +determination. +.RE +.PP +The +.I use-lease-addr-for-default-route +statement +.RS 0.25i +.PP +.B use-lease-addr-for-default-route \fIflag\fR\fB;\fR +.PP +If the \fIuse-lease-addr-for-default-route\fR parameter is true in a +given scope, then instead of sending the value specified in the +routers option (or sending no value at all), the IP address of the +lease being assigned is sent to the client. This supposedly causes +Win95 machines to ARP for all IP addresses, which can be helpful if +your router is configured for proxy ARP. The use of this feature is +not recommended, because it won't work for many DHCP clients. +.RE +.PP +The +.I vendor-option-space +statement +.RS 0.25i +.PP +.B vendor-option-space \fIstring\fR\fB;\fR +.PP +The \fIvendor-option-space\fR parameter determines from what option +space vendor options are taken. The use of this configuration +parameter is illustrated in the \fBdhcp-options(5)\fR manual page, in +the \fIVENDOR ENCAPSULATED OPTIONS\fR section. +.RE +.SH SETTING PARAMETER VALUES USING EXPRESSIONS +Sometimes it's helpful to be able to set the value of a DHCP server +parameter based on some value that the client has sent. To do this, +you can use expression evaluation. The +.B dhcp-eval(5) +manual page describes how to write expressions. To assign the result +of an evaluation to an option, define the option as follows: +.nf +.sp 1 + \fImy-parameter \fB= \fIexpression \fB;\fR +.fi +.PP +For example: +.nf +.sp 1 + ddns-hostname = binary-to-ascii (16, 8, "-", + substring (hardware, 1, 6)); +.fi +.RE +.SH RESERVED LEASES +It's often useful to allocate a single address to a single client, in +approximate perpetuity. Host statements with \fBfixed-address\fR clauses +exist to a certain extent to serve this purpose, but because host statements +are intended to approximate \'static configuration\', they suffer from not +being referenced in a littany of other Server Services, such as dynamic DNS, +failover, \'on events\' and so forth. +.PP +If a standard dynamic lease, as from any range statement, is marked +\'reserved\', then the server will only allocate this lease to the client it +is identified by (be that by client identifier or hardware address). +.PP +In practice, this means that the lease follows the normal state engine, enters +ACTIVE state when the client is bound to it, expires, or is released, and any +events or services that would normally be supplied during these events are +processed normally, as with any other dynamic lease. The only difference +is that failover servers treat reserved leases as special when they enter +the FREE or BACKUP states - each server applies the lease into the state it +may allocate from - and the leases are not placed on the queue for allocation +to other clients. Instead they may only be \'found\' by client identity. The +result is that the lease is only offered to the returning client. +.PP +Care should probably be taken to ensure that the client only has one lease +within a given subnet that it is identified by. +.PP +Leases may be set \'reserved\' either through OMAPI, or through the +\'infinite-is-reserved\' configuration option (if this is applicable to your +environment and mixture of clients). +.PP +It should also be noted that leases marked \'reserved\' are effectively treated +the same as leases marked \'bootp\'. +.RE +.SH REFERENCE: OPTION STATEMENTS +DHCP option statements are documented in the +.B dhcp-options(5) +manual page. +.SH REFERENCE: EXPRESSIONS +Expressions used in DHCP option statements and elsewhere are +documented in the +.B dhcp-eval(5) +manual page. +.SH SEE ALSO +dhcpd(8), dhcpd.leases(5), dhcp-options(5), dhcp-eval(5), RFC2132, RFC2131. +.SH AUTHOR +.B dhcpd.conf(5) +is maintained by ISC. +Information about Internet Systems Consortium can be found at +.B https://www.isc.org. diff --git a/static/netbsd/man5/dhcpd.leases.5 b/static/netbsd/man5/dhcpd.leases.5 new file mode 100644 index 00000000..c36709d5 --- /dev/null +++ b/static/netbsd/man5/dhcpd.leases.5 @@ -0,0 +1,399 @@ +.\" $NetBSD: dhcpd.leases.5,v 1.3 2022/04/03 01:10:59 christos Exp $ +.\" +.\" dhcpd.leases.5 +.\" +.\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" This Source Code Form is subject to the terms of the Mozilla Public +.\" License, v. 2.0. If a copy of the MPL was not distributed with this +.\" file, You can obtain one at http://mozilla.org/MPL/2.0/. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT +.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.\" Internet Systems Consortium, Inc. +.\" PO Box 360 +.\" Newmarket, NH 03857 USA +.\" +.\" https://www.isc.org/ +.\" +.\" Id: dhcpd.leases.5,v 1.17 2011/09/19 00:24:50 sar Exp +.\" +.TH dhcpd.leases 5 +.SH NAME +dhcpd.leases - DHCP client lease database +.SH DESCRIPTION +The Internet Systems Consortium DHCP Server keeps a persistent +database of leases that it has assigned. This database is a free-form +ASCII file containing a series of lease declarations. Every time a +lease is acquired, renewed or released, its new value is recorded at +the end of the lease file. So if more than one declaration appears +for a given lease, the last one in the file is the current one. +.PP +When dhcpd is first installed, there is no lease database. However, +dhcpd requires that a lease database be present before it will start. +To make the initial lease database, just create an empty file called +DBDIR/dhcpd.leases. You can do this with: +.PP +.nf + touch DBDIR/dhcpd.leases +.fi +.PP +In order to prevent the lease database from growing without bound, the +file is rewritten from time to time. First, a temporary lease +database is created and all known leases are dumped to it. Then, the +old lease database is renamed DBDIR/dhcpd.leases~. Finally, the +newly written lease database is moved into place. +.PP +In order to process both DHCPv4 and DHCPv6 messages you will need to +run two separate instances of the dhcpd process. Each of these +instances will need it's own lease file. You can use the \fI-lf\fR +option on the server's command line to specify a different lease file +name for one or both servers. +.SH FORMAT +Lease descriptions are stored in a format that is parsed by the same +recursive descent parser used to read the +.B dhcpd.conf(5) +and +.B dhclient.conf(5) +files. Lease files can contain lease declarations, and also group and +subgroup declarations, host declarations and failover state +declarations. Group, subgroup and host declarations are used to +record objects created using the OMAPI protocol. +.PP +The lease file is a log-structured file - whenever a lease changes, +the contents of that lease are written to the end of the file. This +means that it is entirely possible and quite reasonable for there to +be two or more declarations of the same lease in the lease file at the +same time. In that case, the instance of that particular lease that +appears last in the file is the one that is in effect. +.PP +Group, subgroup and host declarations in the lease file are handled in +the same manner, except that if any of these objects are deleted, a +\fIrubout\fR is written to the lease file. This is just the same +declaration, with \fB{ deleted; }\fR in the scope of the +declaration. When the lease file is rewritten, any such rubouts that +can be eliminated are eliminated. It is possible to delete a +declaration in the \fBdhcpd.conf\fR file; in this case, the rubout +can never be eliminated from the \fBdhcpd.leases\fR file. +.SH COMMON STATEMENTS FOR LEASE DECLARATIONS +While the lease file formats for DHCPv4 and DHCPv6 are different +they share many common statements and structures. This section +describes the common statements while the succeeding sections +describe the protocol specific statements. +.PP +.B Dates +.PP +A \fIdate\fR is specified in two ways, depending on the configuration +value for the \fBdb-time-format\fR parameter. If it was set to \fIdefault\fR, +then the \fIdate\fR fields appear as follows: +.PP +.I weekday year\fB/\fImonth\fB/\fIday hour\fB:\fIminute\fB:\fIsecond\fR +.PP +The weekday is present to make it easy for a human to tell when a +lease expires - it's specified as a number from zero to six, with zero +being Sunday. The day of week is ignored on input. The year is +specified with the century, so it should generally be four digits +except for really long leases. The month is specified as a number +starting with 1 for January. The day of the month is likewise +specified starting with 1. The hour is a number between 0 and 23, the +minute a number between 0 and 59, and the second also a number between +0 and 59. +.PP +Lease times are specified in Universal Coordinated Time (UTC), not in +the local time zone. There is probably nowhere in the world where the +times recorded on a lease are always the same as wall clock times. On +most unix machines, you can display the current time in UTC by typing +\fBdate -u\fR. +.PP +If the \fBdb-time-format\fR was configured to \fIlocal\fR, then +the \fIdate\fR fields appear as follows: +.PP + \fBepoch\fR \fI\fR\fB; #\fR \fI + \fR\fB:\fR\fI\fR\fB:\fR\fI \fR +.PP +The \fIseconds-since-epoch\fR is as according to the system's local clock (often +referred to as "unix time"). The \fB#\fR symbol supplies a comment that +describes what actual time this is as according to the system's configured +timezone, at the time the value was written. It is provided only for human +inspection. +.PP +If a lease will never expire, \fIdate\fR is \fBnever\fR instead of an +actual date. +.PP +.B General Variables +.PP +As part of the processing of a lease information may be attached to the +lease structure, for example the DDNS information or if you specify a +variable in your configuration file. Some of these, like the DDNS +information, have specific descriptions below. For others, such as +any you might define, a generic line of the following will be included. +.PP +.B set \fIvariable\fB = \fIvalue\fB; +.PP +The \fBset\fR statement sets the value of a variable on the lease. +For general information on variables, see the \fBdhcp-eval(5)\fR +manual page. +.PP +.B DDNS Variables +.PP +.nf +.B The \fIddns-text\fB and \fIddns-dhcid\fB variables +.PP +These variables are used to record the value of the client's identification +record when the server has updated DNS for a particular lease. The text +record is used with the interim DDNS update style while the dhcid record +is used for the standard DDNS update style. +.PP +.B The \fIddns-fwd-name\fB variable +.PP +This variable records the value of the name used in +updating the client's A record if a DDNS update has been successfully +done by the server. The server may also have used this name to +update the client's PTR record. +.PP +.B The \fIddns-client-fqdn\fB variable +.PP +If the server is configured both to use the interim or standard DDNS update +style, and to allow clients to update their own FQDNs, then if the +client did in fact update its own FQDN, the +\fIddns-client-fqdn\fR variable records the name that the client has +indicated it is using. This is the name that the server will have +used to update the client's PTR record in this case. +.PP +.B The \fIddns-rev-name\fB variable +.PP +If the server successfully updates the client's PTR record, this +variable will record the name that the DHCP server used for the PTR +record. The name to which the PTR record points will be either the +\fIddns-fwd-name\fR or the \fIddns-client-fqdn\fR. +.PP +.B Executable Statements +.PP +.B on \fIevents\fB { \fIstatements...\fB } +The \fBon\fR statement records a list of statements to execute if a +certain event occurs. The possible events that can occur for an +active lease are \fBrelease\fR and \fBexpiry\fR. More than one event +can be specified - if so, the events are separated by '|' characters. +.PP +The \fIauthoring-byte-order\fR statement +.RS 0.25i +.PP +.B authoring-byte-order \fR[ \fIbig-endian\fR | \fIlittle-endian\fR ] \fB;\fR +.PP +This statement is automatically added to the top of new lease files by +the server. It indicates the internal byte order of the server. This +permits lease files generated on a server with one form of byte order +to be read by a server with a different form. Lease files which do not +contain this entry are simply treated as having the same byte order as +the server reading them. If you are migrating lease files generated +by a server that predates this statement and is of a different byte +order than the your destination server, you can manually add this +statement. It must proceed any lease entries. Valid values for this +parameter are \fIlittle-endian\fR and \fIbig-endian\fR. +.RE +.PP +.SH THE DHCPv4 LEASE DECLARATION +.PP +.B lease \fIip-address\fB { \fIstatements...\fB } +.PP +Each lease declaration includes the single IP address that has been +leased to the client. The statements within the braces define the +duration of the lease and to whom it is assigned. +.PP +.nf +.B starts \fIdate\fB;\fR +.B ends \fIdate\fB;\fR +.B tstp \fIdate\fB;\fR +.B tsfp \fIdate\fB;\fR +.B atsfp \fIdate\fB;\fR +.B cltt \fIdate\fB;\fR +.fi +.PP +The start and end time of a lease are recorded using the \fBstarts\fR +and \fBends\fR statements. The \fBtstp\fR statement is present if +the failover protocol is being used, and indicates what time the peer +has been told the lease expires. The \fBtsfp\fR statement is +also present if the failover protocol is being used, and indicates +the lease expiry time that the peer has acknowledged. +The \fBatsfp\fR statement is the actual time sent from the failover +partner. +The \fBcltt\fR statement is the client's last transaction time. +.PP +See the description of dates in the section on common structures. +.PP +.B hardware \fIhardware-type mac-address\fB;\fR +.PP +The hardware statement records the MAC address of the network +interface on which the lease will be used. It is specified as a +series of hexadecimal octets, separated by colons. +.PP +.B uid \fIclient-identifier\fB;\fR +.PP +The \fBuid\fR statement records the client identifier used by the +client to acquire the lease. Clients are not required to send client +identifiers, and this statement only appears if the client did in fact +send one. Client identifiers are normally an ARP type (1 for +ethernet) followed by the MAC address, just like in the \fBhardware\fI +statement, but this is not required. +.PP +The client identifier is recorded as a colon-separated hexadecimal +list or as a quoted string. If it is recorded as a quoted string and +it contains one or more non-printable characters, those characters are +represented as octal escapes - a backslash character followed by three +octal digits. The format used is determined by the lease-id-format +parameter, which defaults to octal. +.PP +.B client-hostname "\fIhostname\fB";\fR +.PP +Most DHCP clients will send their hostname in the \fIhost-name\fR +option. If a client sends its hostname in this way, the hostname is +recorded on the lease with a \fBclient-hostname\fR statement. This +is not required by the protocol, however, so many specialized DHCP +clients do not send a host-name option. +.PP +.nf +.B binding state \fIstate\fB; +.B next binding state \fIstate\fB; +.fi +.PP +The \fBbinding state\fR statement declares the lease's binding state. +When the DHCP server is not configured to use the failover protocol, a +lease's binding state may be \fBactive\fR, \fBfree\fR or \fBabandoned\fR. +The failover protocol adds some additional transitional states, as well as +the \fBbackup\fR state, which indicates that the lease is available +for allocation by the failover secondary. Please see the \fBdhcpd.conf(5)\fR +manual page for more information about abandoned leases. +.PP +The \fBnext binding state\fR statement indicates what state the lease +will move to when the current state expires. The time when the +current state expires is specified in the \fIends\fR statement. +.PP +.B rewind binding state \fIstate\fB; +.PP +This statement is part of an optimization for +use with failover. This helps a server rewind a lease to the state most +recently transmitted to its peer. +.PP +.nf +.B option agent.circuit-id \fIstring\fR; +.B option agent.remote-id \fIstring\fR; +.fi +.PP +These statements are used to record the circuit ID and remote ID options +sent by the relay agent, if the relay agent uses the \fIrelay agent +information option\fR. This allows these options to be used +consistently in conditional evaluations even when the client is +contacting the server directly rather than through its relay agent. +.PP +.B The \fIvendor-class-identifier\fB variable +.PP +The server retains the client-supplied Vendor Class Identifier option +for informational purposes, and to render them in DHCPLEASEQUERY responses. +.PP +.nf +.B bootp; +.B reserved; +.fi +.PP +If present, they indicate that the BOOTP and RESERVED failover flags +(respectively) should be set. BOOTP +and RESERVED dynamic leases are treated differently than normal dynamic leases, +as they may only be used by the client to which they are currently allocated. +.PP +.B Other +Additional options or executable statements may be included, see the description +of them in the section on common structures. +.RE +.PP +.SH THE DHCPv6 LEASE (IA) DECLARATION +.PP +.nf +.B ia_ta \fI IAID_DUID\fB { \fIstatements...\fB } +.B ia_na \fI IAID_DUID\fB { \fIstatements...\fB } +.B ia_pd \fI IAID_DUID\fB { \fIstatements...\fB } +.fi +.PP +Each lease declaration starts with a tag indicating the type of the lease. +ia_ta is for temporary addresses, ia_na is for non-temporary addresses and +ia_pd is for prefix delegation. Following this tag is the combined IAID +and DUID from the client for this lease. +.PP +The IAID_DUID value is recorded as a colon-separated hexadecimal +list or as a quoted string. If it is recorded as a quoted string and +it contains one or more non-printable characters, those characters are +represented as octal escapes - a backslash character followed by three +octal digits. The format used is governed by the lease-id-format parameter, +which defaults to octal. +.PP +.B cltt \fIdate\fB;\fR +.PP +The \fBcltt\fR statement is the client's last transaction time. +.PP +See the description of dates in the section on common structures. +.PP +.nf +.B iaaddr \fIipv6-address\fB { \fIstatements...\fB } +.B iaprefix \fIipv6-address/prefix-length\fB { \fIstatements...\fB } +.PP +Within a given lease there can be multiple iaaddr and iaprefix statements. +Each will have either an IPv6 address or an IPv6 prefix (an address and +a prefix length indicating a CIDR style block of addresses). The following +statements may occur Within each iaaddr or iaprefix. +.PP +.B binding state \fIstate\fB; +.PP +The \fBbinding state\fR statement declares the lease's binding state. +In DHCPv6 you will normally see this as \fIactive\fR or \fIexpired\fR. +.PP +.B preferred-life \fIlifetime\fB; +.PP +The IPv6 preferred lifetime associated with this address, in seconds. +.PP +.B max-life \fIlifetime\fB; +.PP +The valid lifetime associated with this address, in seconds. +.PP +.B ends \fIdate\fB;\fR +.PP +The end time of the lease. See the description of dates in the section on +common structures. +.PP +Additional options or executable statements may be included. See the description +of them in the section on common structures. +.PP +.RE +.SH THE FAILOVER PEER STATE DECLARATION +The state of any failover peering arrangements is also recorded in the +lease file, using the \fBfailover peer\fR statement: +.PP +.nf +.B failover peer "\fIname\fB" state { +.B my state \fIstate\fB at \fIdate\fB; +.B peer state \fIstate\fB at \fIdate\fB; +.B } +.fi +.PP +The states of the peer named \fIname\fR is being recorded. Both the +state of the running server (\fBmy state\fR) and the other failover +partner (\fIpeer state\fR) are recorded. The following states are +possible: \fBunknown-state\fR, \fBpartner-down\fR, \fBnormal\fR, +\fBcommunications-interrupted\fR, \fBresolution-interrupted\fR, +\fBpotential-conflict\fR, \fBrecover\fR, \fBrecover-done\fR, +\fBshutdown\fR, \fBpaused\fR, and \fBstartup\fR. +.RE +.SH FILES +.B DBDIR/dhcpd.leases DBDIR/dhcpd.leases~ +.SH SEE ALSO +dhcpd(8), dhcp-options(5), dhcp-eval(5), dhcpd.conf(5), RFC2132, RFC2131. +.SH AUTHOR +.B dhcpd(8) +is maintained by ISC. +Information about Internet Systems Consortium can be found at: +.B https://www.isc.org/ diff --git a/static/netbsd/man5/disklabel.5 b/static/netbsd/man5/disklabel.5 new file mode 100644 index 00000000..f2165b53 --- /dev/null +++ b/static/netbsd/man5/disklabel.5 @@ -0,0 +1,439 @@ +.\" $NetBSD: disklabel.5,v 1.31 2022/08/28 10:48:16 hgutch Exp $ +.\" +.\" Copyright (c) 1987, 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" This code is derived from software contributed to Berkeley by +.\" Symmetric Computer Systems. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" @(#)disklabel.5.5 8.1 (Berkeley) 6/5/93 +.\" +.Dd September 11, 2016 +.Dt DISKLABEL 5 +.Os +.Sh NAME +.Nm disklabel +.Nd disk pack label +.Sh SYNOPSIS +.In sys/disklabel.h +.Sh DESCRIPTION +Each disk or disk pack on a system may contain a disk label +which provides detailed information +about the geometry of the disk and the partitions into which the disk +is divided. +It should be initialized when the disk is formatted, +and may be changed later with the +.Xr disklabel 8 +program. +This information is used by the system disk driver and by the bootstrap +program to determine how to program the drive +and where to find the file systems on the disk partitions. +Additional information is used by the file system in order +to use the disk most efficiently and to locate important file system information. +The description of each partition contains an identifier for the partition +type (standard file system, swap area, etc.). +The file system updates the in-core copy of the label if it contains +incomplete information about the file system. +.Pp +The label is located in the sector number returned by the +.Xr getlabelsector 3 +function, usually sector 0 where it may be found +without any information about the disk geometry. +It is at an offset (specified by the +.Xr getlabeloffset 3 +function) +from the beginning of the sector, to allow room for the initial bootstrap. +The disk sector containing the label is normally made read-only +so that it is not accidentally overwritten by pack-to-pack copies +or swap operations; +the +.Dv DIOCWLABEL +.Xr ioctl 2 , +which is done as needed by the +.Xr disklabel 8 +program. +.Pp +A copy of the in-core label for a disk can be obtained with the +.Dv DIOCGDINFO +.Xr ioctl 2 ; +this works with a file descriptor for a block or character (``raw'') device +for any partition of the disk. +The in-core copy of the label is set by the +.Dv DIOCSDINFO +.Xr ioctl 2 . +The offset of a partition cannot generally be changed while it is open, +nor can it be made smaller while it is open. +One exception is that any change is allowed if no label was found +on the disk, and the driver was able to construct only a skeletal label +without partition information. +Finally, the +.Dv DIOCWDINFO +.Xr ioctl 2 +operation sets the in-core label and then updates the on-disk label; +there must be an existing label on the disk for this operation to succeed. +Thus, the initial label for a disk or disk pack must be installed +by writing to the raw disk. +All of these operations are normally done using +.Xr disklabel 8 . +.Pp +The format of the disk label, as specified in +.Pa sys/disklabel.h , +is +.Bd -literal +/* + * Disk description table, see disktab(5) + */ +#define _PATH_DISKTAB "/etc/disktab" + +/* + * Each disk has a label which includes information about the hardware + * disk geometry, file system partitions, and drive specific information. + * The location of the label, as well as the number of partitions the + * label can describe and the number of the "whole disk" (raw) + * partition are machine dependent. + */ +#include + +/* + * The absolute maximum number of disk partitions allowed. + * This is the maximum value of MAXPARTITIONS for which 'struct disklabel' + * is <= DEV_BSIZE bytes long. If MAXPARTITIONS is greater than this, beware. + */ +#define MAXMAXPARTITIONS 22 +#if MAXPARTITIONS > MAXMAXPARTITIONS +#warning beware: MAXPARTITIONS bigger than MAXMAXPARTITIONS +#endif + + +#define DISKMAGIC ((u_int32_t)0x82564557) /* The disk magic number */ + +#ifndef _LOCORE +struct disklabel { + u_int32_t d_magic; /* the magic number */ + u_int16_t d_type; /* drive type */ + u_int16_t d_subtype; /* controller/d_type specific */ + char d_typename[16]; /* type name, e.g. "eagle" */ + + /* + * d_packname contains the pack identifier and is returned when + * the disklabel is read off the disk or in-core copy. + * d_boot0 and d_boot1 are the (optional) names of the + * primary (block 0) and secondary (block 1-15) bootstraps + * as found in /usr/mdec. These are returned when using + * getdiskbyname(3) to retrieve the values from /etc/disktab. + */ + union { + char un_d_packname[16]; /* pack identifier */ + struct { + char *un_d_boot0; /* primary bootstrap name */ + char *un_d_boot1; /* secondary bootstrap name */ + } un_b; + } d_un; +#define d_packname d_un.un_d_packname +#define d_boot0 d_un.un_b.un_d_boot0 +#define d_boot1 d_un.un_b.un_d_boot1 + + /* disk geometry: */ + u_int32_t d_secsize; /* # of bytes per sector */ + u_int32_t d_nsectors; /* # of data sectors per track */ + u_int32_t d_ntracks; /* # of tracks per cylinder */ + u_int32_t d_ncylinders; /* # of data cylinders per unit */ + u_int32_t d_secpercyl; /* # of data sectors per cylinder */ + u_int32_t d_secperunit; /* # of data sectors per unit */ + + /* + * Spares (bad sector replacements) below are not counted in + * d_nsectors or d_secpercyl. Spare sectors are assumed to + * be physical sectors which occupy space at the end of each + * track and/or cylinder. + */ + u_int16_t d_sparespertrack; /* # of spare sectors per track */ + u_int16_t d_sparespercyl; /* # of spare sectors per cylinder */ + /* + * Alternative cylinders include maintenance, replacement, + * configuration description areas, etc. + */ + u_int32_t d_acylinders; /* # of alt. cylinders per unit */ + + /* hardware characteristics: */ + /* + * d_interleave, d_trackskew and d_cylskew describe perturbations + * in the media format used to compensate for a slow controller. + * Interleave is physical sector interleave, set up by the + * formatter or controller when formatting. When interleaving is + * in use, logically adjacent sectors are not physically + * contiguous, but instead are separated by some number of + * sectors. It is specified as the ratio of physical sectors + * traversed per logical sector. Thus an interleave of 1:1 + * implies contiguous layout, while 2:1 implies that logical + * sector 0 is separated by one sector from logical sector 1. + * d_trackskew is the offset of sector 0 on track N relative to + * sector 0 on track N-1 on the same cylinder. Finally, d_cylskew + * is the offset of sector 0 on cylinder N relative to sector 0 + * on cylinder N-1. + */ + u_int16_t d_rpm; /* rotational speed */ + u_int16_t d_interleave; /* hardware sector interleave */ + u_int16_t d_trackskew; /* sector 0 skew, per track */ + u_int16_t d_cylskew; /* sector 0 skew, per cylinder */ + u_int32_t d_headswitch; /* head switch time, usec */ + u_int32_t d_trkseek; /* track-to-track seek, usec */ + u_int32_t d_flags; /* generic flags */ +#define NDDATA 5 + u_int32_t d_drivedata[NDDATA]; /* drive-type specific information */ +#define NSPARE 5 + u_int32_t d_spare[NSPARE]; /* reserved for future use */ + u_int32_t d_magic2; /* the magic number (again) */ + u_int16_t d_checksum; /* xor of data incl. partitions */ + + /* file system and partition information: */ + u_int16_t d_npartitions; /* number of partitions in following */ + u_int32_t d_bbsize; /* size of boot area at sn0, bytes */ + u_int32_t d_sbsize; /* max size of fs superblock, bytes */ + struct partition { /* the partition table */ + u_int32_t p_size; /* number of sectors in partition */ + u_int32_t p_offset; /* starting sector */ + u_int32_t p_fsize; /* file system basic fragment size */ + u_int8_t p_fstype; /* file system type, see below */ + u_int8_t p_frag; /* file system fragments per block */ + union { + u_int16_t cpg; /* UFS: FS cylinders per group */ + u_int16_t sgs; /* LFS: FS segment shift */ + } __partition_u1; +#define p_cpg __partition_u1.cpg +#define p_sgs __partition_u1.sgs + } d_partitions[MAXPARTITIONS]; /* actually may be more */ +}; +#else /* _LOCORE */ + /* + * offsets for asm boot files. + */ + .set d_secsize,40 + .set d_nsectors,44 + .set d_ntracks,48 + .set d_ncylinders,52 + .set d_secpercyl,56 + .set d_secperunit,60 + .set d_end_,276 /* size of disk label */ +#endif /* _LOCORE */ + +/* d_type values: */ +#define DTYPE_SMD 1 /* SMD, XSMD; VAX hp/up */ +#define DTYPE_MSCP 2 /* MSCP */ +#define DTYPE_DEC 3 /* other DEC (rk, rl) */ +#define DTYPE_SCSI 4 /* SCSI */ +#define DTYPE_ESDI 5 /* ESDI interface */ +#define DTYPE_ST506 6 /* ST506 etc. */ +#define DTYPE_HPIB 7 /* CS/80 on HP-IB */ +#define DTYPE_HPFL 8 /* HP Fiber-link */ +#define DTYPE_FLOPPY 10 /* floppy */ +#define DTYPE_CCD 11 /* concatenated disk device */ +#define DTYPE_VND 12 /* vnode pseudo-disk */ +#define DTYPE_ATAPI 13 /* ATAPI */ +#define DTYPE_RAID 14 /* RAIDframe */ +#define DTYPE_LD 15 /* logical disk */ +#define DTYPE_JFS2 16 /* IBM JFS2 */ +#define DTYPE_CGD 17 /* cryptographic pseudo-disk */ +#define DTYPE_VINUM 18 /* vinum volume obsolete */ +#define DTYPE_FLASH 19 /* flash memory device */ + +#ifdef DKTYPENAMES +static const char *const dktypenames[] = { + "unknown", + "SMD", + "MSCP", + "old DEC", + "SCSI", + "ESDI", + "ST506", + "HP-IB", + "HP-FL", + "type 9", + "floppy", + "ccd", + "vnd", + "ATAPI", + "RAID", + "ld", + "jfs", + "cgd", + "obsolete vinum", + "flash", + NULL +}; +#define DKMAXTYPES (sizeof(dktypenames) / sizeof(dktypenames[0]) - 1) +#endif + +/* + * Filesystem type and version. + * Used to interpret other file system-specific + * per-partition information. + */ +#define FS_UNUSED 0 /* unused */ +#define FS_SWAP 1 /* swap */ +#define FS_V6 2 /* Sixth Edition */ +#define FS_V7 3 /* Seventh Edition */ +#define FS_SYSV 4 /* System V */ +#define FS_V71K 5 /* V7 with 1K blocks (4.1, 2.9) */ +#define FS_V8 6 /* Eighth Edition, 4K blocks */ +#define FS_BSDFFS 7 /* 4.2BSD fast file system */ +#define FS_MSDOS 8 /* MSDOS file system */ +#define FS_BSDLFS 9 /* 4.4BSD log-structured file system */ +#define FS_OTHER 10 /* in use, but unknown/unsupported */ +#define FS_HPFS 11 /* OS/2 high-performance file system */ +#define FS_ISO9660 12 /* ISO 9660, normally CD-ROM */ +#define FS_BOOT 13 /* partition contains bootstrap */ +#define FS_ADOS 14 /* AmigaDOS fast file system */ +#define FS_HFS 15 /* Macintosh HFS */ +#define FS_FILECORE 16 /* Acorn Filecore Filing System */ +#define FS_EX2FS 17 /* Linux Extended 2 file system */ +#define FS_NTFS 18 /* Windows/NT file system */ +#define FS_RAID 19 /* RAIDframe component */ +#define FS_CCD 20 /* concatenated disk component */ +#define FS_JFS2 21 /* IBM JFS2 */ +#define FS_APPLEUFS 22 /* Apple UFS */ +#define FS_VINUM 23 /* Vinum */ + +#ifdef FSTYPENAMES +static const char *const fstypenames[] = { + "unused", + "swap", + "Version 6", + "Version 7", + "System V", + "4.1BSD", + "Eighth Edition", + "4.2BSD", + "MSDOS", + "4.4LFS", + "unknown", + "HPFS", + "ISO9660", + "boot", + "ADOS", + "HFS", + "FILECORE", + "Linux Ext2", + "NTFS", + "RAID", + "ccd", + "jfs", + "Apple UFS", + "obsolete vinum", + NULL +}; +#define FSMAXTYPES (sizeof(fstypenames) / sizeof(fstypenames[0]) - 1) +#endif + +/* + * flags shared by various drives: + */ +#define D_REMOVABLE 0x01 /* removable media */ +#define D_ECC 0x02 /* supports ECC */ +#define D_BADSECT 0x04 /* supports bad sector forw. */ +#define D_RAMDISK 0x08 /* disk emulator */ +#define D_CHAIN 0x10 /* can do back-back transfers */ + +/* + * Drive data for SMD. + */ + +#define d_smdflags d_drivedata[0] +#define D_SSE 0x1 /* supports skip sectoring */ +#define d_mindist d_drivedata[1] +#define d_maxdist d_drivedata[2] +#define d_sdist d_drivedata[3] + +/* + * Drive data for ST506. + */ +#define d_precompcyl d_drivedata[0] +#define d_gap3 d_drivedata[1] /* used only when formatting */ + +/* + * Drive data for SCSI. + */ +#define d_blind d_drivedata[0] + +#ifndef _LOCORE +/* + * Structure used to perform a format or other raw operation, + * returning data and/or register values. Register identification + * and format are device- and driver-dependent. + */ +struct format_op { + char *df_buf; + int df_count; /* value-result */ + daddr_t df_startblk; + int df_reg[8]; /* result */ +}; + +/* + * Structure used internally to retrieve information about a partition + * on a disk. + */ +struct partinfo { + struct disklabel *disklab; + struct partition *part; +}; +.Ed +.Pp +Disk specific ioctls are defined in +.Pa sys/dkio.h . +.Bd -literal +.Pp +/* + * Disk-specific ioctls. + */ + /* get and set disklabel; DIOCGPART used internally */ +#define DIOCGDINFO _IOR('d', 101, struct disklabel) /* get */ +#define DIOCSDINFO _IOW('d', 102, struct disklabel) /* set */ +#define DIOCWDINFO _IOW('d', 103, struct disklabel) /* set, update disk */ +#define DIOCGPART _IOW('d', 104, struct partinfo) /* get partition */ + + /* do format operation, read or write */ +#define DIOCRFORMAT _IOWR('d', 105, struct format_op) +#define DIOCWFORMAT _IOWR('d', 106, struct format_op) + +#define DIOCSSTEP _IOW('d', 107, int) /* set step rate */ +#define DIOCSRETRIES _IOW('d', 108, int) /* set # of retries */ +#define DIOCKLABEL _IOW('d', 119, int) /* keep/drop label on close? */ +#define DIOCWLABEL _IOW('d', 109, int) /* write en/disable label */ + +#define DIOCSBAD _IOW('d', 110, struct dkbad) /* set kernel dkbad */ +#define DIOCEJECT _IOW('d', 112, int) /* eject removable disk */ +#define DIOCLOCK _IOW('d', 113, int) /* lock/unlock pack */ + + /* get default label, clear label */ +#define DIOCGDEFLABEL _IOR('d', 114, struct disklabel) +#define DIOCCLRLABEL _IO('d', 115) +.Ed +.Sh SEE ALSO +.Xr disktab 5 , +.Xr disklabel 8 , +.Xr dkctl 8 +.\" .Sh HISTORY diff --git a/static/netbsd/man5/dm.conf.5 b/static/netbsd/man5/dm.conf.5 new file mode 100644 index 00000000..b7933cec --- /dev/null +++ b/static/netbsd/man5/dm.conf.5 @@ -0,0 +1,114 @@ +.\" $NetBSD: dm.conf.5,v 1.8 2003/08/07 09:37:11 agc Exp $ +.\" +.\" Copyright (c) 1988, 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" @(#)dm.conf.5 8.1 (Berkeley) 5/31/93 +.\" +.Dd May 31, 1993 +.Dt DM.CONF 5 +.Os +.Sh NAME +.Nm dm.conf +.Nd dungeon master configuration file +.Sh DESCRIPTION +The +.Nm +file is the configuration file for the +.Xr dm 8 +program. +It consists of lines beginning with one of three keywords, +.Em badtty , +.Em game , +and +.Em time . +All other lines are ignored. +.Pp +Any tty listed after the keyword +.Em badtty +may not have games played on it. +Entries consist of two white-space separated fields: the string +.Em badtty +and the ttyname as returned by +.Xr ttyname 3 . +For example, to keep the uucp dialout, +.Dq tty19 , +from being used for games, the entry would be: +.Bd -literal -offset indent +badtty /dev/tty19 +.Ed +.Pp +Any day/hour combination listed after the keyword +.Em time +will disallow games during those hours. +Entries consist of four white-space separated fields: the string +.Em time , +the unabbreviated day of the week and the beginning and ending time +of a period of the day when games may not be played. +The time fields are in a 0 based, 24-hour clock. +For example, the following entry allows games playing before 8AM +and after 5PM on Mondays: +.Bd -literal -offset indent +time Monday 8 17 +.Ed +.Pp +Any game listed after the keyword +.Em game +will set parameters for a specific game. +Entries consist of five white-space separated fields: the keyword +.Em game , +the name of a game, the highest system load average at which the +game may be played, the maximum users allowed if the game is to be +played, and the priority at which the game is to be run. +Any of these fields may start with a non-numeric character, resulting +in no game limitation or priority based on that field. +.Pp +The game +.Em default +controls the settings for any game not otherwise listed, and must be the last +.Em game +entry in the file. +Priorities may not be negative. +For example, the following entries limits the game +.Dq hack +to running only when the system has 10 or less users and a load average of 5 +or less; all other games may be run any time the system has 15 or less users. +.Bd -literal -offset indent +game hack 5 10 * +game default * 15 * +.Ed +.Sh FILES +.Bl -tag -width /etc/dm.conf -compact +.It Pa /etc/dm.conf +The +.Xr dm 8 +configuration file. +.El +.Sh SEE ALSO +.Xr setpriority 2 , +.Xr ttyname 3 , +.Xr dm 8 diff --git a/static/netbsd/man5/editrc.5 b/static/netbsd/man5/editrc.5 new file mode 100644 index 00000000..24966e71 --- /dev/null +++ b/static/netbsd/man5/editrc.5 @@ -0,0 +1,326 @@ +.\" $NetBSD: editrc.5,v 1.34 2022/12/06 00:59:20 uwe Exp $ +.\" +.\" Copyright (c) 1997-2000 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This file was contributed to The NetBSD Foundation by Luke Mewburn. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd May 22, 2016 +.Dt EDITRC 5 +.Os +.Sh NAME +.Nm editrc +.Nd configuration file for editline library +.Sh SYNOPSIS +.Nm +.Sh DESCRIPTION +The +.Nm +file defines various settings to be used by the +.Xr editline 3 +library. +.Pp +The format of each line is: +.Pp +.D1 Oo Ar prog Ns Ic \&: Oc Ns Ar command Oo Ar arg ... Oc +.Pp +.Ar command +is one of the +.Xr editline 3 +builtin commands. +Refer to +.Sx BUILTIN COMMANDS +for more information. +.Pp +.Ar prog +is the program name string that a program defines when it calls +.Xr el_init 3 +to set up +.Xr editline 3 , +which is usually +.Va argv Ns Li [0] . +.Ar command +will be executed for any program which matches +.Ar prog . +.Pp +.Ar prog +may also be a +.Xr regex 3 +style +regular expression, in which case +.Ar command +will be executed for any program that matches the regular expression. +.Pp +If +.Ar prog +is absent, +.Ar command +is executed for all programs. +.Sh BUILTIN COMMANDS +The +.Nm editline +library has some builtin commands, which affect the way +that the line editing and history functions operate. +These are based on similar named builtins present in the +.Xr tcsh 1 +shell. +.Pp +The following builtin commands are available: +.Bl -tag -width 4n +.It Ic bind Oo Fl aeklrsv Oc Op Ar key Op Ar command +Without options and arguments, list all bound keys and macros, and +the editor command or input string to which each one is bound. +If only +.Ar key +is supplied, show the binding for that key or macro. +If +.Ar key command +is supplied, bind the editor +.Ar command +to that key or macro. +.Pp +The options are as follows: +.Bl -tag -width 4n +.It Fl a +List or change key bindings in the +.Xr vi 1 +mode alternate (command mode) key map. +.It Fl e +Bind all keys to the standard +.Tn GNU +Emacs-like bindings. +.It Fl k +.Ar key +is interpreted as a symbolic arrow key name, which may be one of +.Ic up , +.Ic down , +.Ic left +or +.Ic right . +.It Fl l +List all editor commands and a short description of each. +.It Fl r +Remove the binding of the key or macro +.Ar key . +.It Fl s +Define a keyboard macro rather than a key binding or command macro: +.Ar command +is taken as a literal string and appended to the input queue whenever +.Ar key +is typed. +Bound keys and macros in +.Ar command +are themselves reinterpreted, and this continues for ten levels of +interpretation. +.It Fl v +Bind all keys to the standard +.Xr vi 1 Ns -like +bindings. +.El +.Pp +The +.Xr editline 7 +manual documents all editor commands and contains more information +about macros and the input queue. +.Pp +.Ar key +and +.Ar command +can contain control characters of the form +.Sq Ic ^ Ns Ar character +.Po +e.g.\& +.Ql ^A +.Pc , +and the following backslashed escape sequences: +.Pp +.Bl -tag -compact -offset indent -width Ic +.It Ic \ea +Bell +.It Ic \eb +Backspace +.It Ic \ee +Escape +.It Ic \ef +Formfeed +.It Ic \en +Newline +.It Ic \er +Carriage return +.It Ic \et +Horizontal tab +.It Ic \ev +Vertical tab +.Sm off +.It Ic \e Ar nnn +.Sm on +The +.Tn ASCII +character corresponding to the octal number +.Ar nnn . +.El +.Pp +.Ql \e +nullifies the special meaning of the following character, +if it has any, notably +.Ql \e +and +.Ql ^ . +.It Ic echotc Oo Fl sv Oc Ar arg Ar ... +Exercise terminal capabilities given in +.Ar arg . +If +.Ar arg +is +.Ql baud , +.Ql cols , +.Ql lines , +.Ql rows , +.Ql meta , +or +.Ql tabs , +the value of that capability is printed, with +.Dq yes +or +.Dq no +indicating that the terminal does or does not have that capability. +.Pp +.Fl s +returns an empty string for non-existent capabilities, rather than +causing an error. +.Fl v +causes messages to be verbose. +.It Ic edit Op Li on No | Li off +Enable or disable the +.Nm editline +functionality in a program. +.It Ic history Li list No | Li size Ar n No | Li unique Ar n +The +.Ql list +command lists all entries in the history. +The +.Ql size +command sets the history size to +.Ar n +entries. +The +.Ql unique +command controls if history should keep duplicate entries. +If +.Ar n +is non zero, only keep unique history entries. +If +.Ar n +is zero, then keep all entries (the default). +.It Ic settc Ar cap Ar val +Set the terminal capability +.Ar cap +to +.Ar val , +as defined in +.Xr termcap 5 . +No sanity checking is done. +.It Ic setty Oo Fl a Oc Oo Fl d Oc Oo Fl q Oc Oo Fl x Oc Oo Ic \&+ Ns Ar mode Oc \ +Oo Fl Ar mode Oc Oo Ar mode Oc Oo Ar char\| Ns Ic = Ns Ar c Oc +Control which tty modes that +.Nm +won't allow the user to change. +.Fl d , +.Fl q +or +.Fl x +tells +.Ic setty +to act on the +.Sq edit , +.Sq quote +or +.Sq execute +set of tty modes respectively; defaulting to +.Fl x . +.Pp +Without other arguments, +.Ic setty +lists the modes in the chosen set which are fixed on +.Po +.Ic + Ns Ar mode +.Pc +or off +.Po +.Fl Ns Ar mode +.Pc . +.Fl a +lists all tty modes in the chosen set regardless of the setting. +With +.Ic + Ns Ar mode , +.Fl Ns Ar mode +or +.Ar mode , +fixes +.Ar mode +on or off or removes control of +.Ar mode +in the chosen set. +.Pp +.Ic Setty +can also be used to set tty characters to particular values using +.Ar char\| Ns Ic = Ns Ar value . +If +.Ar value +is empty +then the character is set to +.Dv _POSIX_VDISABLE . +.It Ic telltc +List the values of all the terminal capabilities (see +.Xr termcap 5 ) . +.El +.Sh ENVIRONMENT +.Bl -tag -width Ev +.It Ev EDITRC +Names the default configuration file for the +.Xr editline 3 +library. +.El +.Sh FILES +.Bl -tag -width Pa +.It Pa ~/.editrc +Last resort user configuration file for the +.Xr editline 3 +library if no other file is specified. +.El +.Sh SEE ALSO +.Xr editline 3 , +.Xr regex 3 , +.Xr termcap 5 , +.Xr editline 7 +.Sh AUTHORS +.An -nosplit +The +.Nm editline +library was written by +.An Christos Zoulas , +and this manual was written by +.An Luke Mewburn , +with some sections inspired by +.Xr tcsh 1 . diff --git a/static/netbsd/man5/envsys.conf.5 b/static/netbsd/man5/envsys.conf.5 new file mode 100644 index 00000000..7073afc8 --- /dev/null +++ b/static/netbsd/man5/envsys.conf.5 @@ -0,0 +1,459 @@ +.\" $NetBSD: envsys.conf.5,v 1.15 2017/07/03 21:35:30 wiz Exp $ +.\" +.\" - +.\" Copyright (c) 2007, 2008 Juan Romero Pardines. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" +.\" +.Dd February 15, 2010 +.Dt ENVSYS.CONF 5 +.Os +.Sh NAME +.Nm envsys.conf +.Nd configuration file for the +.Xr envsys 4 +framework +.Sh SYNOPSIS +.Nm envstat +.Op Fl S +.Op Fl c Ar /etc/envsys.conf +.Sh DESCRIPTION +The +.Nm +file configures all the features provided by the +.Xr envsys 4 +framework. +It consists of a series of device and sensor blocks. +Each sensor block defines a group of +.Em properties . +The file format is free-form: new line markers and indentation are +ignored. +Comments start with a +.Sq # +sign and extend until the end of line. +.Pp +A +.Em property +is like a variable assignment. +It has a name, which goes to the left of the equal sign, and a value, +which goes to the right. +The assignment ends with a semicolon. +It looks like: +.Pp +.Dl name = value; +.Pp +There is no difference between string or integer values when defining them. +The value must be surrounded by double quotes if it contains whitespace. +.Pp +There can be multiple groups of devices and multiple groups of sensors +in the configuration file. +.Pp +A device block consists of one or more sensor blocks and one or more global +properties. +It has the following syntax: +.Bd -literal -offset indent + device_name { + prop = value; + ... + sensor0 { + prop = value; + ... + } + ... + sensorN { + prop = value; + ... + } + } + ... +.Ed +.Pp +Device names are those shown by the +.Ql envstat -D +command; sensor blocks are named by the index position in which they are shown. +.Pp +For example, if we have the following output from the +.Xr envstat 8 +command: +.Bd -literal -offset indent + CPU Temperature: 32.000 degC + MB Temperature: 37.000 degC + Vcore Voltage: 1.232 V + +3.3 Voltage: 3.248 V + +5 Voltage: 4.992 V + +12 Voltage: 11.985 V + CPU FAN Speed: 1250 RPM +.Ed +.Pp +.Ql sensor0 +corresponds to the +.Em CPU Temperature +sensor and +.Ql sensor6 +corresponds to the +.Em CPU FAN Speed +sensor. +.Pp +There is another way that will give you the correct index +sensor; the +.Ql envstat -x +command will print the raw XML property list. +You only have to find the +.Em index +object in the appropriate dictionary. +The object will be shown as: +.Bd -literal -offset indent + index + sensor2 +.Ed +.Pp +Invalid sensors and devices will be detected by the +.Xr envstat 8 +parser and will be reported as errors. +.Pp +The following properties are provided for sensor blocks (please note that +not all properties apply to all type of sensors): +.Bl -tag -width ident +.It critical-capacity = 10; +.Pp +Sets a critical capacity limit property of 10 +percent in a battery sensor. +Battery sensors are those that report a percentage from the +.Xr envstat 8 +output. +.Pp +It is possible to find out if the sensor accepts this property +by running +.Ql envstat -x +and looking if the +.Em want-percentage +object is defined as +.Em true +on its dictionary. +For example: +.Bd -literal -offset indent + want-percentage + +.Ed +.Pp +Only a value between 0 and 100 is allowed. +When the limit is reached in the sensor, a +.Em critical-capacity +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +.Pa /etc/powerd/scripts/sensor_battery . +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar CritMin . +.It warning-capacity = 20; +.Pp +Sets a warning capacity limit property of 20 +percent in a battery sensor. +Battery sensors are those that report a percentage from the +.Xr envstat 8 +output. +.Pp +It is possible to find out if the sensor accepts this property +by running +.Ql envstat -x +and looking if the +.Em want-percentage +object is defined as +.Em true +on its dictionary. +For example: +.Bd -literal -offset indent + want-percentage + +.Ed +.Pp +Only a value between 0 and 100 is allowed. +When the limit is reached in the sensor, a +.Em warning-capacity +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +.Pa /etc/powerd/scripts/sensor_battery . +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar WarnMin . +.It high-capacity = 90; +.Pp +Sets a high capacity limit property of 90 +percent in a battery sensor. +Battery sensors are those that report a percentage from the +.Xr envstat 8 +output. +.Pp +It is possible to find out if the sensor accepts this property +by running +.Ql envstat -x +and looking if the +.Em want-percentage +object is defined as +.Em true +on its dictionary. +For example: +.Bd -literal -offset indent + want-percentage + +.Ed +.Pp +Only a value between 0 and 100 is allowed. +When the limit is reached in the sensor, a +.Em high-capacity +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +.Pa /etc/powerd/scripts/sensor_battery . +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar WarnMax . +.It maximum-capacity = 99; +.Pp +Sets a warning capacity limit property of 99 +percent in a battery sensor. +Battery sensors are those that report a percentage from the +.Xr envstat 8 +output. +.Pp +It is possible to find out if the sensor accepts this property +by running +.Ql envstat -x +and looking if the +.Em want-percentage +object is defined as +.Em true +on its dictionary. +For example: +.Bd -literal -offset indent + want-percentage + +.Ed +.Pp +Only a value between 0 and 100 is allowed. +When the limit is reached in the sensor, a +.Em warning-capacity +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +.Pa /etc/powerd/scripts/sensor_battery . +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar WarnMin . +.It critical-max = 70C; +.Pp +Sets a critical maximum limit property in a sensor. +Note that in this example, we are specifying the +.Ql C +keyword at the end; that means that this will only be valid for +.Em temperature +sensors and that the value is specified as degrees +.Em Celsius . +If degrees Fahrenheit are wanted, just use the letter +.Em F , +as in: +.Bd -literal -offset indent +critical-max = 140F; +.Ed +.Pp +To know sensor type, you have to look at the +.Em type +object in the XML property list. +Remember: the XML property list has +all the information that the application uses to print the values! +.Pp +Other sensors that are not of +.Em temperature +type must not include the final character for the unit. +A dot is allowed in the value, if it corresponds to the +range that the sensor is reporting. +When the limit has been reached in the sensor, a +.Em critical-over +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +the appropriate +.Pa /etc/powerd/scripts/sensor_foo +script (depending on the sensor's type). +.Pp +Please note that this property cannot be set in battery capacity sensors +(those that have the +.Em want-percentage +object in their dictionary). +This rule applies for the +.Ql critical-min , +.Ql warning-max , +and +.Ql warning-min +properties too. +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar CritMax . +.It critical-min = 1.230; +.Pp +Sets a critical minimum limit property in a sensor. +The rules for +.Em critical-max , +.Em critical-min , +.Em warning-max , +and +.Em warning-min +are the same. +When the limit has been reached in the sensor, a +.Em critical-under +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +the appropriate +.Pa /etc/powerd/scripts/sensor_foo +script (depending on the sensor's type). +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar CritMin . +.It warning-max = 70C; +.Pp +Sets a warning maximum limit property in a sensor. +The rules for +.Em critical-max , +.Em critical-min , +.Em warning-max , +and +.Em warning-min +are the same. +When the limit has been reached in the sensor, a +.Em warning-over +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +the appropriate +.Pa /etc/powerd/scripts/sensor_foo +script (depending on the sensor's type). +.Pp +Please note that this property cannot be set in battery capacity sensors +(those that have the +.Em want-percentage +object in their dictionary). +This rule applies for the +.Ql warning-min +property too. +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar WarnMax . +.It warning-min = 1.230; +.Pp +Sets a critical minimum limit property in a sensor. +The rules for +.Em critical-max , +.Em critical-min , +.Em warning-max , +and +.Em warning-min +are the same. +When the limit has been reached in the sensor, a +.Em warning-under +event will be sent to the +.Xr powerd 8 +daemon (if running) and will execute the block for this event in +the appropriate +.Pa /etc/powerd/scripts/sensor_foo +script (depending on the sensor's type). +.Pp +If this property is set, its value will be shown in the +.Xr envstat 8 +display output with a column named +.Ar WarnMin . +.It description = string +.Pp +Sets a new description in a sensor. +You can set this property in +all sensors, except that you won't be able to set a description +that is currently used for the specified device. +.It rfact = 56000 +.Pp +Sets a new resistor factor property in a sensor. +This property is only allowed in +.Em Voltage +sensors and +.Em only +if the device has enabled the appropriate flag for the mentioned +sensor. +The resistor factor may be used to change the behavior +of the value returned by the device. +.Pp +If a sensor supports this, the +.Em allow-rfact +object appears enabled (true) in the dictionary. +.El +.Pp +The following properties are available for device blocks: +.Bl -tag -width ident +.It refresh-timeout = 10s +.Pp +This property sets the refresh timeout value in a device, and will be used +to refresh data and check for critical conditions any time the timeout +is met. +The value may be specified in seconds, minutes or hours. +To specify the value in seconds, the +.Em s +character must be appended last, if minutes is desired, a +.Em m +and a +.Em h +for hours. +For example +.Em 10s +for 10 seconds or +.Em 1h +for one hour. +.El +.Sh FILES +.Bl -tag -width /etc/envsys.conf -compact +.It Pa /etc/envsys.conf +Default configuration file. +.El +.Sh SEE ALSO +.Xr proplib 3 , +.Xr envsys 4 , +.Xr envstat 8 , +.Xr powerd 8 +.Sh HISTORY +The +.Nm +configuration file first appeared in +.Nx 5.0 . diff --git a/static/netbsd/man5/example.5 b/static/netbsd/man5/example.5 new file mode 100644 index 00000000..3d23ac5a --- /dev/null +++ b/static/netbsd/man5/example.5 @@ -0,0 +1,26 @@ +# $NetBSD: example.5,v 1.1.1.1 2012/03/23 21:20:15 christos Exp $ +# +# test ruleset +# +# allow packets coming from foo to bar through. +# +pass in from 10.1.1.2 to 10.2.1.1 +# +# allow any TCP packets from the same subnet as foo is on through to host +# 10.1.1.2 if they are destined for port 6667. +# +pass in proto tcp from 10.2.2.2/24 to 10.1.1.2/32 port = 6667 +# +# allow in UDP packets which are NOT from port 53 and are destined for +# localhost +# +pass in proto udp from 10.2.2.2 port != 53 to localhost +# +# block all ICMP unreachables. +# +block in proto icmp from any to any icmp-type unreach +# +# allow packets through which have a non-standard IP header length (ie there +# are IP options such as source-routing present). +# +pass in from any to any with ipopts diff --git a/static/netbsd/man5/exports.5 b/static/netbsd/man5/exports.5 new file mode 100644 index 00000000..0bb8183e --- /dev/null +++ b/static/netbsd/man5/exports.5 @@ -0,0 +1,488 @@ +.\" $NetBSD: exports.5,v 1.39 2024/03/29 22:50:27 uwe Exp $ +.\" +.\" Copyright (c) 1989, 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" @(#)exports.5 8.3 (Berkeley) 3/29/95 +.\" +.Dd March 27, 2024 +.Dt EXPORTS 5 +.Os +.Sh NAME +.Nm exports +.Nd exported filesystem mount points for +.Tn NFS +mount requests +.Sh DESCRIPTION +The +.Nm +file on an +.Tn NFS +server lists filesystems to be exported to +.Tn NFS +clients. +It is read and applied by +.Xr mountd 8 +on start and on +.Dv SIGHUP . +.Pp +Each entry in +.Nm +is a line with a list of directories followed by a list of hosts, +netgroups, and options, separated by spaces or tabs: +.Pp +.D1 Li / Ns Ar dir Li ... Oo Ar host | Ar netgroup | Fl Ar option Oc Li ... +.Pp +All directories in a single line must live in the same filesystem, +which is exported to the hosts and netgroups listed, according to the +options specified. +Exported directories must not have pathname components that are +symbolic links, +.Ql \&. , +or +.Ql \&.. . +.Pp +.Bf -symbolic +Warning: +Exporting a directory exposes the +.Em entire +contents of the filesystem that the directory lives in to +.Tn NFS +clients. +.Ef +This happens even if an exported directory is not the root directory of +a filesystem on the server. +.Tn NFS +clients are only prevented from access to files and directories on +filesystems that are +.Em not +exported at all. +.Pp +.Bf -symbolic +Warning: +Access control is only by network address. +.Ef +.Tn NFS +servers with any non-public data should be exposed only to restricted +or firewalled networks with ingress filtering. +There is no authentication or encryption to make it safe for +restricting access on the open internet. +.Pp +Blank lines are ignored. +Text beginning with +.Ql # +until the end of line is ignored as a comment. +Each line ending with +.Ql \e +has the next line appended, without the +.Ql \e , +as a continuation line. +Characters can be escaped with +.Ql \e . +.Pp +All directories, which begin with +.Ql / , +must come before any hosts, netgroups, or options on a line. +Options begin with +.Ql - . +All other items on an export line are interpreted either as netgroups +.Po see +.Xr netgroup 5 +.Pc +or as hosts, which can be either names, as in example.com, or numbers, +as in 192.0.2.123 or 2001:db8:1234:abcd::42. +Sets of hosts in a contiguous network range can be specified with the +.Fl network +option. +.Pp +The same filesystem may be exported on multiple lines with different +options to different sets of hosts, as long as it is exported at most +once to each host, netgroup, or network. +.Pp +Export lines with no hosts, netgroups, or +.Fl network +options are exported to +.Em any +hosts on the network, with no access control. +.Pp +Supported export options: +.Bl -tag -width Fl +.It Fl alldirs +Allow mount requests from clients at any point within the filesystem, +including regular files. +Only the root directory of the filesystem should be specified on the +line. +.Pp +Note that omitting the +.Fl alldirs +option should not be used as a security measure to make clients mount +only those subdirectories that they should have access to. +A client +can still access the whole filesystem via individual RPCs if it +wanted to, even if just one subdirectory has been mounted. +.Sm off +.It Fl maproot Li = Ar user +.Sm on +The credential of the specified user is used for remote access by root. +The credential includes all the groups to which the user is a member +on the local machine +.Po see +.Xr id 1 +.Pc . +The user may be specified by name or number. +.Sm off +.It Fl maproot Li = Ar user\^ Li \&: Op Ar group1\^ Li \&: group2\^ Li \&: Ar ... +.Sm on +The colon separated list is used to specify the precise credential +to be used for remote access by root. +The elements of the list may be either names or numbers. +Note that +.Sq Ar user\^ Ns Li \&: +(with the trailing colon) +should be used to distinguish a credential containing no groups from a +complete credential for that user. +.Sm off +.It Fl mapall Li = Ar user +.It Fl mapall Li = Ar user\^ Li \&: Op Ar group1\^ Li \&: Ar group2\^ Li \&: Ar ... +.Sm on +Mapping for all client uids (including root) +using the same semantics as +.Fl maproot . +.It Fl r Ar user +.It Fl r Ar user\^ Ns Li \&: Ns Op Ar group1\^ Ns Li \&: Ns Ar group2\^ Ns Li \&: Ns Ar ... +Synonym for +.Fl maproot , +for compatibility with older export file formats. +.Pp +.Em Note : +Not a synonym for the read-only option +.Fl ro . +.El +.Pp +In the absence of +.Fl maproot +and +.Fl mapall +options, remote accesses by root will result in using a credential of -2:-2. +All other users will be mapped to their remote credential. +If a +.Fl maproot +option is given, +remote access by root will be mapped to that credential instead of -2:-2. +If a +.Fl mapall +option is given, +all users (including root) will be mapped to that credential in +place of their own. +.Bl -tag -width Fl +.It Fl kerb +Specifies that the Kerberos authentication server should be +used to authenticate and map client credentials. +.Sy This option is currently not implemented. +.It Fl ro +Export filesystem read-only. +Clients will be forbidden to change or write to anything in the +filesystem +.Po +except for named pipes, sockets, and device nodes, where +write semantics is client-side anyway +.Pc . +.It Fl o +Synonym for +.Fl ro +for compatibility with older export file formats. +.It Fl noresvport +Allow NFS RPC calls for the filesystem to come from non-reserved +ports. +Normally, clients are required to use reserved ports for operations. +Using this option decreases the security of your system. +.\" XXX ^ Not really... +.It Fl noresvmnt +Allow mount RPC requests for the filesystem to come from non-reserved +ports. +Normally, clients are required to use reserved ports for mount requests. +Using this option decreases the security of your system. +.\" XXX ^ Not really... +.It Fl webnfs +(WebNFS) +Enables WebNFS export, equivalent to combining +.Fl public , +.Fl mapall=nobody , +and +.Fl ro . +.It Fl public +(WebNFS) +Enables WebNFS export strictly according to the spec, +RFC 2054 and RFC 2055. +This implies: +.Bl -bullet -compact +.It +read/write access to all files in the filesystem +.It +not requiring reserved ports +.Pq Fl noresvport , Fl noresvmnt +.It +not remapping uids +.El +.Pp +.Bf -symbolic +Warning: +.Fl public +is only provided to conform to the spec, and should normally +not be used. +.Ef +For a WebNFS export, +use the +.Fl webnfs +flag. +.It Fl index Ns Li = Ns Ar file +(WebNFS) +File whose handle will be returned if +a directory is looked up using the public filehandle. +This is to mimic the behavior of URLs. +If no +.Fl index +option is specified, a directory filehandle will be returned as usual. +.Pp +The +.Fl index +option only makes sense in combination with the +.Fl public +or +.Fl webnfs +flags. +.El +.Pp +.Bf -symbolic +Warning: exporting a filesystem both using WebNFS and read/write in +the normal way to other hosts should be avoided in an environment +that is vulnerable to IP spoofing. +.Ef +.\" XXX Isn't this an issue for _all_ read/write exports, not just +.\" WebNFS ones? +WebNFS enables any client to get filehandles to the exported filesystem. +Using IP spoofing, a client could then pretend to be a host to which +the same filesystem was exported read/write, and use the handle to +gain access to that filesystem. +.Bl -tag -width Fl +.Sm off +.It Fl network Li = Ar netname Op Li / Ar prefixlength +.Sm on +Export the filesystem to all hosts in the specified network. +.Pp +This approach to identifying hosts requires less overhead within the +kernel and is recommended for cases where the export line refers to a +large number of clients within an administrative subnet. +.Pp +The netmask may be specified either by +.Ar prefixlength , +or +.Pq for IPv4 networks only +by using a separate +.Fl mask +option. +If the mask is not specified, it will default to the mask for that network +class +.Po +A, B or C; see +.Xr inet 4 +.Pc . +.Pp +Scoped IPv6 address must carry a scope identifier as documented in +.Xr inet6 4 . +For example, +.Ql fe80::%ne2/10 +is used to specify +.Ql fe80::/10 +on +.Ql ne2 +interface. +.Sm off +.It Fl mask No = Ar netmask +.Sm on +(IPv4-only) +Netmask for +.Fl network +options with no +.Ar prefixlength . +.El +.Sh FILES +.Bl -tag -width Pa -compact +.It Pa /etc/exports +The default remote mount-point file. +.El +.Pp +If you have modified the +.Pa /etc/exports +file, send the mountd process a +.Dv SIGHUP +to make it re-read it: +.Pp +.Dl "kill -HUP $(cat /var/run/mountd.pid)" +.Sh EXAMPLES +.Bd -literal -offset indent +/usr /usr/local -maproot=0:10 friends +/usr -maproot=daemon grumpy.cis.uoguelph.ca 131.104.48.16 +/usr -ro -mapall=nobody +/u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 +/a -network 192.168.0/24 +/a -network 3ffe:1ce1:1:fe80::/64 +/u2 -maproot=root friends +/u2 -alldirs -kerb -network cis-net -mask cis-mask +.Ed +.Pp +Given that +.Pa /usr , +.Pa /u , +and +.Pa /u2 +are local filesystem mount points, the above example specifies the +following: +.Bl -tag -width ".Pa /usr" +.It Pa /usr +is exported to hosts +.Ql friends +where +.Ql friends +is specified in the +.Xr netgroup 5 +file with users mapped to their remote credentials and +root mapped to uid 0 and group 10. +It is exported read-write and the hosts in +.Ql friends +can mount either +.Pa /usr +or +.Pa /usr/local . +.Pp +It is also exported to +.Ql 131.104.48.16 +and +.Ql grumpy.cis.uoguelph.ca +with users mapped to their remote credentials and +root mapped to the user and groups associated with +.Ql daemon . +.Pp +It is also exported to the rest of the world as read-only with +all users mapped to the user and groups associated with +.Ql nobody . +.It Pa /u +is exported to all hosts on the subnetwork +.Ql 131.104.48 +with root mapped to the uid for +.Ql bin +and with no group access. +.It Pa /u2 +is exported to the hosts in +.Ql friends +with root mapped to uid and groups associated with +.Ql root ; +it is exported to all hosts on network +.Ql cis-net +allowing mounts at any +directory within +.Pa /u2 +and mapping all uids to credentials for the principal +that is authenticated by a Kerberos ticket. +.Pq Sy Kerberos not implemented. +.It Pa /a +is exported to the network +.Ql 192.168.0.0 , +with a netmask of +.Ql 255.255.255.0 . +However, the netmask in the entry for +.Pa /a +is not specified through a +.Fl mask +option, but through the +.Li / Ns Ar prefixlen +notation. +.It Pa /a +is also exported to the IPv6 network +.Ql 3ffe:1ce1:1:fe80:: +address, using the upper 64 bits as the prefix. +Note that, unlike with IPv4 network addresses, the specified network +address must be complete, and not just contain the upper bits. +With IPv6 addresses, the +.Fl mask +option must not be used. +.El +.Sh SEE ALSO +.Xr netgroup 5 , +.Xr mountd 8 , +.Xr nfsd 8 , +.Xr showmount 8 +.Rs +.%T NFS: Network File System Protocol Specification +.%R RFC 1094 +.%I IETF Network Working Group +.%O Appendix A +.%U https://datatracker.ietf.org/doc/html/rfc1094#appendix-A.1 +.Re +.Rs +.%A B. Callaghan +.%A B. Pawlowski +.%A P. Staubach +.%T NFS Version 3 Protocol Specification +.%R RFC 1813 +.%I IETF Network Working Group +.%O Appendix I +.%U https://datatracker.ietf.org/doc/html/rfc1813#section-5.0 +.Re +.Sh CAVEATS +Don't re-export NFS-mounted filesystems unless you are sure of the +implications. +NFS has some assumptions about the characteristics of the file +systems being exported, e.g. when timestamps are updated. +Re-exporting should work to some extent and can even be useful in +some cases, but don't expect it works as well as with local file +systems. +.Pp +Filesystems that provide a namespace for a subtree of another +filesystem such as nullfs +.Pq Xr mount_null 8 +and umapfs +.Pq Xr mount_umap 8 +.Em do not +restrict +.Tn NFS +clients to that namespace, so they cannot be used to securely limit +.Tn NFS +clients to a subtree of a filesystem. +If you want to export one subtree and prevent access to other subtrees, +the exported subtree must be on its own filesystem on the server. +.Sh BUGS +The export options are tied to the local mount points in the kernel and +must be non-contradictory for any exported subdirectory of the local +server mount point. +.\" XXX Explain what `contradictory' means here and give some positive +.\" and negative examples. +It is recommended that all exported directories within the same server +filesystem be specified on adjacent lines going down the tree. +You cannot specify a hostname that is also the name of a netgroup. +Specifying the full domain specification for a hostname can normally +circumvent the problem. diff --git a/static/netbsd/man5/fips_config.5 b/static/netbsd/man5/fips_config.5 new file mode 100644 index 00000000..e85086a5 --- /dev/null +++ b/static/netbsd/man5/fips_config.5 @@ -0,0 +1,247 @@ +.\" $NetBSD: fips_config.5,v 1.5 2026/04/08 17:06:50 christos Exp $ +.\" +.\" -*- mode: troff; coding: utf-8 -*- +.\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45) +.\" +.\" Standard preamble: +.\" ======================================================================== +.de Sp \" Vertical space (when we can't use .PP) +.if t .sp .5v +.if n .sp +.. +.de Vb \" Begin verbatim text +.ft CW +.nf +.ne \\$1 +.. +.de Ve \" End verbatim text +.ft R +.fi +.. +.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. +.ie n \{\ +. ds C` "" +. ds C' "" +'br\} +.el\{\ +. ds C` +. ds C' +'br\} +.\" +.\" Escape single quotes in literal strings from groff's Unicode transform. +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" +.\" If the F register is >0, we'll generate index entries on stderr for +.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index +.\" entries marked with X<> in POD. Of course, you'll have to process the +.\" output yourself in some meaningful fashion. +.\" +.\" Avoid warning from groff about undefined register 'F'. +.de IX +.. +.nr rF 0 +.if \n(.g .if rF .nr rF 1 +.if (\n(rF:(\n(.g==0)) \{\ +. if \nF \{\ +. de IX +. tm Index:\\$1\t\\n%\t"\\$2" +.. +. if !\nF==2 \{\ +. nr % 0 +. nr F 2 +. \} +. \} +.\} +.rr rF +.\" +.\" Required to disable full justification in groff 1.23.0. +.if n .ds AD l +.\" ======================================================================== +.\" +.IX Title "FIPS_CONFIG 5" +.TH FIPS_CONFIG 5 2026-04-07 3.5.6 OpenSSL +.\" For nroff, turn off justification. Always turn off hyphenation; it makes +.\" way too many mistakes in technical documents. +.if n .ad l +.nh +.SH NAME +fips_config \- OpenSSL FIPS configuration +.SH DESCRIPTION +.IX Header "DESCRIPTION" +A separate configuration file, using the OpenSSL \fBconfig\fR\|(5) syntax, +is used to hold information about the FIPS module. This includes a digest +of the shared library file, and status about the self\-testing. +This data is used automatically by the module itself for two +purposes: +.IP "\- Run the startup FIPS self\-test known answer tests (KATS)." 4 +.IX Item "- Run the startup FIPS self-test known answer tests (KATS)." +This is normally done once, at installation time, but may also be set up to +run each time the module is used. +.IP "\- Verify the module\*(Aqs checksum." 4 +.IX Item "- Verify the module's checksum." +This is done each time the module is used. +.PP +This file is generated by the \fBopenssl\-fipsinstall\fR\|(1) program, and +used internally by the FIPS module during its initialization. +.PP +The following options are supported. They should all appear in a section +whose name is identified by the \fBfips\fR option in the \fBproviders\fR +section, as described in "Provider Configuration Module" in \fBconfig\fR\|(5). +.IP \fBactivate\fR 4 +.IX Item "activate" +If present, the module is activated. The value assigned to this name is not +significant. +.IP \fBconditional\-errors\fR 4 +.IX Item "conditional-errors" +The FIPS module normally enters an internal error mode if any self test fails. +Once this error mode is active, no services or cryptographic algorithms are +accessible from this point on. +Continuous tests are a subset of the self tests (e.g., a key pair test during key +generation, or the CRNG output test). +Setting this value to \f(CW0\fR allows the error mode to not be triggered if any +continuous test fails. The default value of \f(CW1\fR will trigger the error mode. +Regardless of the value, the operation (e.g., key generation) that called the +continuous test will return an error code if its continuous test fails. The +operation may then be retried if the error mode has not been triggered. +.IP \fBmodule\-mac\fR 4 +.IX Item "module-mac" +The calculated MAC of the FIPS provider file. +.IP \fBinstall\-version\fR 4 +.IX Item "install-version" +A version number for the fips install process. Should be 1. +.IP \fBinstall\-status\fR 4 +.IX Item "install-status" +This field is deprecated and is no longer used. +.IP \fBinstall\-mac\fR 4 +.IX Item "install-mac" +This field is deprecated and is no longer used. +.SS "FIPS indicator options" +.IX Subsection "FIPS indicator options" +The following FIPS configuration options indicate if run\-time checks related to +enforcement of FIPS security parameters such as minimum security strength of +keys and approved curve names are used. +A value of \*(Aq1\*(Aq will perform the checks, otherwise if the value is \*(Aq0\*(Aq the checks +are not performed and FIPS compliance must be done by procedures documented in +the relevant Security Policy. +.PP +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) for further information related to these +options. +.IP \fBsecurity\-checks\fR 4 +.IX Item "security-checks" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-no_security_checks\fR +.IP \fBtls1\-prf\-ems\-check\fR 4 +.IX Item "tls1-prf-ems-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-ems_check\fR +.IP \fBno\-short\-mac\fR 4 +.IX Item "no-short-mac" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-no_short_mac\fR +.IP \fBdrbg\-no\-trunc\-md\fR 4 +.IX Item "drbg-no-trunc-md" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-no_drbg_truncated_digests\fR +.IP \fBsignature\-digest\-check\fR 4 +.IX Item "signature-digest-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-signature_digest_check\fR +.IP \fBhkdf\-digest\-check\fR 4 +.IX Item "hkdf-digest-check" +This option is deprecated. +.IP \fBtls13\-kdf\-digest\-check\fR 4 +.IX Item "tls13-kdf-digest-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-tls13_kdf_digest_check\fR +.IP \fBtls1\-prf\-digest\-check\fR 4 +.IX Item "tls1-prf-digest-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-tls1_prf_digest_check\fR +.IP \fBsshkdf\-digest\-check\fR 4 +.IX Item "sshkdf-digest-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-sshkdf_digest_check\fR +.IP \fBsskdf\-digest\-check\fR 4 +.IX Item "sskdf-digest-check" +This option is deprecated. +.IP \fBx963kdf\-digest\-check\fR 4 +.IX Item "x963kdf-digest-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-x963kdf_digest_check\fR +.IP \fBdsa\-sign\-disabled\fR 4 +.IX Item "dsa-sign-disabled" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-dsa_sign_disabled\fR +.IP \fBtdes\-encrypt\-disabled\fR 4 +.IX Item "tdes-encrypt-disabled" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-tdes_encrypt_disabled\fR +.IP \fBrsa\-pkcs15\-pad\-disabled\fR 4 +.IX Item "rsa-pkcs15-pad-disabled" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-rsa_pkcs15_pad_disabled\fR +.IP \fBrsa\-pss\-saltlen\-check\fR 4 +.IX Item "rsa-pss-saltlen-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-rsa_pss_saltlen_check\fR +.IP \fBrsa\-sign\-x931\-pad\-disabled\fR 4 +.IX Item "rsa-sign-x931-pad-disabled" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-rsa_sign_x931_disabled\fR +.IP \fBhkdf\-key\-check\fR 4 +.IX Item "hkdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-hkdf_key_check\fR +.IP \fBkbkdf\-key\-check\fR 4 +.IX Item "kbkdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-kbkdf_key_check\fR +.IP \fBtls13\-kdf\-key\-check\fR 4 +.IX Item "tls13-kdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-tls13_kdf_key_check\fR +.IP \fBtls1\-prf\-key\-check\fR 4 +.IX Item "tls1-prf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-tls1_prf_key_check\fR +.IP \fBsshkdf\-key\-check\fR 4 +.IX Item "sshkdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-sshkdf_key_check\fR +.IP \fBsskdf\-key\-check\fR 4 +.IX Item "sskdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-sskdf_key_check\fR +.IP \fBx963kdf\-key\-check\fR 4 +.IX Item "x963kdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-x963kdf_key_check\fR +.IP \fBx942kdf\-key\-check\fR 4 +.IX Item "x942kdf-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-x942kdf_key_check\fR +.IP \fBpbkdf2\-lower\-bound\-check\fR 4 +.IX Item "pbkdf2-lower-bound-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-no_pbkdf2_lower_bound_check\fR +.IP \fBecdh\-cofactor\-check\fR 4 +.IX Item "ecdh-cofactor-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-ecdh_cofactor_check\fR +.IP \fBhmac\-key\-check\fR 4 +.IX Item "hmac-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-hmac_key_check\fR +.IP \fBkmac\-key\-check\fR 4 +.IX Item "kmac-key-check" +See "OPTIONS" in \fBopenssl\-fipsinstall\fR\|(1) \fB\-kmac_key_check\fR +.PP +For example: +.PP +.Vb 8 +\& [fips_sect] +\& activate = 1 +\& install\-version = 1 +\& conditional\-errors = 1 +\& security\-checks = 1 +\& module\-mac = 41:D0:FA:C2:5D:41:75:CD:7D:C3:90:55:6F:A4:DC +\& install\-mac = FE:10:13:5A:D3:B4:C7:82:1B:1E:17:4C:AC:84:0C +\& install\-status = INSTALL_SELF_TEST_KATS_RUN +.Ve +.SH NOTES +.IX Header "NOTES" +When using the FIPS provider, it is recommended that the +\&\fBconfig_diagnostics\fR option is enabled to prevent accidental use of +non\-FIPS validated algorithms via broken or mistaken configuration. +See \fBconfig\fR\|(5). +.SH "SEE ALSO" +.IX Header "SEE ALSO" +\&\fBconfig\fR\|(5) +\&\fBopenssl\-fipsinstall\fR\|(1) +.SH HISTORY +.IX Header "HISTORY" +This functionality was added in OpenSSL 3.0. +.SH COPYRIGHT +.IX Header "COPYRIGHT" +Copyright 2019\-2025 The OpenSSL Project Authors. All Rights Reserved. +.PP +Licensed under the Apache License 2.0 (the "License"). You may not use +this file except in compliance with the License. You can obtain a copy +in the file LICENSE in the source distribution or at +. diff --git a/static/netbsd/man5/ftpd.conf.5 b/static/netbsd/man5/ftpd.conf.5 new file mode 100644 index 00000000..a5cf24d2 --- /dev/null +++ b/static/netbsd/man5/ftpd.conf.5 @@ -0,0 +1,738 @@ +.\" $NetBSD: ftpd.conf.5,v 1.38 2020/08/22 08:08:47 lukem Exp $ +.\" +.\" Copyright (c) 1997-2020 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to The NetBSD Foundation +.\" by Luke Mewburn. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd August 22, 2020 +.Dt FTPD.CONF 5 +.Os +.Sh NAME +.Nm ftpd.conf +.Nd +.Xr ftpd 8 +configuration file +.Sh DESCRIPTION +The +.Nm +file specifies various configuration options for +.Xr ftpd 8 +that apply once a user has authenticated their connection. +.Pp +.Nm +consists of a series of lines, each of which may contain a +configuration directive, a comment, or a blank line. +Directives that appear later in the file override settings by previous +directives. +This allows +.Sq wildcard +entries to define defaults, and then have class-specific overrides. +.Pp +A directive line has the format: +.Dl command class [arguments] +.Pp +A +.Dq \e +is the escape character; it can be used to escape the meaning of the +comment character, or if it is the last character on a line, extends +a configuration directive across multiple lines. +A +.Dq # +is the comment character, and all characters from it to the end of +line are ignored (unless it is escaped with the escape character). +.Pp +Each authenticated user is a member of a +.Em class , +which is determined by +.Xr ftpusers 5 . +.Em class +is used to determine which +.Nm +entries apply to the user. +The following special classes exist when parsing entries in +.Nm : +.Bl -tag -width "chroot" -compact -offset indent +.It Sy all +Matches any class. +.It Sy none +Matches no class. +.El +.Pp +Each class has a type, which may be one of: +.Bl -tag -width "CHROOT" -offset indent +.It Sy GUEST +Guests (as per the +.Dq anonymous +and +.Dq ftp +logins). +A +.Xr chroot 2 +is performed after login. +.It Sy CHROOT +.Xr chroot 2 Ns ed +users (as per +.Xr ftpchroot 5 ) . +A +.Xr chroot 2 +is performed after login. +.It Sy REAL +Normal users. +.El +.Pp +The +.Xr ftpd 8 +.Sy STAT +command will return the class settings for the current user as defined by +.Nm , +unless the +.Sy private +directive is set for the class. +.Pp +Each configuration line may be one of: +.Bl -tag -width 4n +.It Sy advertize Ar class Op Ar host +Set the address to advertise in the response to the +.Sy PASV +and +.Sy LPSV +commands to the address for +.Ar host +(which may be either a host name or IP address). +This may be useful in some firewall configurations, although many +ftp clients may not work if the address being advertised is different +to the address that they've connected to. +If +.Ar class +is +.Dq none +or +.Ar host +not is specified, disable this. +.It Sy checkportcmd Ar class Op Sy off +Check the +.Sy PORT +command for validity. +The +.Sy PORT +command will fail if the IP address specified does not match the +.Tn FTP +command connection, or if the remote TCP port number is less than +.Dv IPPORT_RESERVED . +It is +.Em strongly +encouraged that this option be used, especially for sites concerned +with potential security problems with +.Tn FTP +bounce attacks. +If +.Ar class +is +.Dq none +or +.Sy off +is specified, disable this feature, otherwise enable it. +.It Sy chroot Ar class Op Sy pathformat +If +.Ar pathformat +is not specified or +.Ar class +is +.Dq none , +use the default behavior (see below). +Otherwise, +.Ar pathformat +is parsed to create a directory to create as the root directory with +.Xr chroot 2 +into upon login. +.Pp +.Ar pathformat +can contain the following escape strings: +.Bl -tag -width "Escape" -offset indent -compact +.It Sy "Escape" +.Sy Description +.It "\&%c" +Class name. +.It "\&%d" +Home directory of user. +.It "\&%u" +User name. +.It "\&%\&%" +A +.Dq \&% +character. +.El +.Pp +The default root directory is: +.Bl -tag -width "CHROOT" -offset indent -compact +.It Sy CHROOT +The user's home directory. +.It Sy GUEST +If +.Fl a Ar anondir +is specified, use +.Ar anondir , +otherwise the home directory of the +.Sq ftp +user. +.It Sy REAL +By default no +.Xr chroot 2 +is performed. +.El +.It Sy classtype Ar class Ar type +Set the class type of +.Ar class +to +.Ar type +(see above). +.It Sy conversion Ar class Ar suffix Op Ar "type disable command" +Define an automatic in-line file conversion. +If a file to retrieve ends in +.Ar suffix , +and a real file (sans +.Ar suffix ) +exists, then the output of +.Ar command +is returned instead of the contents of the file. +.Pp +.Bl -tag -width "disable" -offset indent +.It Ar suffix +The suffix to initiate the conversion. +.It Ar type +A list of valid file types for the conversion. +Valid types are: +.Sq f +(file), and +.Sq d +(directory). +.It Ar disable +The name of file that will prevent conversion if it exists. +A file name of +.Dq Pa \&. +will prevent this disabling action +(i.e., the conversion is always permitted.) +.It Ar command +The command to run for the conversion. +The first word should be the full path name +of the command, as +.Xr execv 3 +is used to execute the command. +All instances of the word +.Dq %s +in +.Ar command +are replaced with the requested file (sans +.Ar suffix ) . +.El +.Pp +Conversion directives specified later in the file override earlier +conversions with the same suffix. +.It Sy denyquick Ar class Op Sy off +Enforce +.Xr ftpusers 5 +rules after the +.Sy USER +command is received, rather than after the +.Sy PASS +command is received. +Whilst enabling this feature may allow information leakage about +available accounts (for example, if you allow some users of a +.Sy REAL +or +.Sy CHROOT +class but not others), it is useful in preventing a denied user +(such as +.Sq root ) +from entering their password across an insecure connection. +This option is +.Em strongly +recommended for servers which run an anonymous-only service. +If +.Ar class +is +.Dq none +or +.Sy off +is specified, disable this feature, otherwise enable it. +.It Sy display Ar class Op Ar file +If +.Ar file +is not specified or +.Ar class +is +.Dq none , +disable this. +Otherwise, each time the user enters a new directory, check if +.Ar file +exists, and if so, display its contents to the user. +Escape sequences are supported; refer to +.Sx Display file escape sequences +in +.Xr ftpd 8 +for more information. +.It Sy hidesymlinks Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, disable this feature. +Otherwise, the +.Sy LIST +command lists symbolic links as the file or directory the link +references +.Pq Dq Li "ls -LlA" . +Servers which run an anonymous service may wish to enable this +feature for +.Sy GUEST +users, so that symbolic links do not leak names in +directories that are not searchable by +.Sy GUEST +users. +.It Sy homedir Ar class Op Sy pathformat +If +.Ar pathformat +is not specified or +.Ar class +is +.Dq none , +use the default behavior (see below). +Otherwise, +.Ar pathformat +is parsed to create a directory to change into upon login, and to use +as the +.Sq home +directory of the user for tilde expansion in pathnames, etc. +.Ar pathformat +is parsed as per the +.Sy chroot +directive. +.Pp +The default home directory is the home directory of the user for +.Sy REAL +users, and +.Pa / +for +.Sy GUEST +and +.Sy CHROOT +users. +.It Sy limit Ar class Op Ar count Op Ar file +Limit the maximum number of concurrent connections for +.Ar class +to +.Ar count , +with +.Sq \-1 +meaning unlimited connections. +If the limit is exceeded and +.Ar file +is specified, display its contents to the user. +If +.Ar class +is +.Dq none +or +.Ar count +is not specified, disable this. +If +.Ar file +is a relative path, it will be searched for in +.Pa /etc +(which can be overridden with +.Fl c Ar confdir ) . +.It Sy maxfilesize Ar class Op Ar size +Set the maximum size of an uploaded file to +.Ar size , +with +.Sq \-1 +meaning unlimited connections. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, disable this. +.It Sy maxtimeout Ar class Op Ar time +Set the maximum timeout period that a client may request, +defaulting to two hours. +This cannot be less than 30 seconds, or the value for +.Sy timeout . +If +.Ar class +is +.Dq none +or +.Ar time +is not specified, use the default. +.It Sy mmapsize Ar class Op Ar size +Set the size of the sliding window to map a file using +.Xr mmap 2 . +If zero, +.Xr ftpd 8 +will use +.Xr read 2 +instead. +The default is zero. +This option affects only binary transfers. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.It Sy modify Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, disable the following commands: +.Sy CHMOD , +.Sy DELE , +.Sy MKD , +.Sy RMD , +.Sy RNFR , +and +.Sy UMASK . +Otherwise, enable them. +.It Sy motd Ar class Op Ar file +If +.Ar file +is not specified or +.Ar class +is +.Dq none , +disable this. +Otherwise, use +.Ar file +as the message of the day file to display after login. +Escape sequences are supported; refer to +.Sx Display file escape sequences +in +.Xr ftpd 8 +for more information. +If +.Ar file +is a relative path, it will be searched for in +.Pa /etc +(which can be overridden with +.Fl c Ar confdir ) . +.It Sy notify Ar class Op Ar fileglob +If +.Ar fileglob +is not specified or +.Ar class +is +.Dq none , +disable this. +Otherwise, each time the user enters a new directory, +notify the user of any files matching +.Ar fileglob . +.It Sy passive Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, prevent passive +.Sy ( PASV , +.Sy LPSV , +and +.Sy EPSV ) +connections. +Otherwise, enable them. +.It Sy portrange Ar class Op Ar min Ar max +Set the range of port number which will be used for the passive data port. +.Ar max +must be greater than +.Ar min , +and both numbers must be between +.Dv IPPORT_RESERVED +(1024) and 65535. +If +.Ar class +is +.Dq none +or no arguments are specified, disable this. +.It Sy private Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, do not display class information in the output of the +.Sy STAT +command. +Otherwise, display the information. +.It Sy rateget Ar class Op Ar rate +Set the maximum get +.Pq Sy RETR +transfer rate throttle for +.Ar class +to +.Ar rate +bytes per second. +If +.Ar rate +is 0, the throttle is disabled. +If +.Ar class +is +.Dq none +or +.Ar rate +is not specified, disable this. +.It Sy rateput Ar class Op Ar rate +Set the maximum put +.Pq Sy STOR +transfer rate throttle for +.Ar class +to +.Ar rate +bytes per second. +If +.Ar rate +is 0, the throttle is disabled. +If +.Ar class +is +.Dq none +or +.Ar rate +is not specified, disable this. +.It Sy readsize Ar class Op Ar size +Set the size of the read buffer to +.Xr read 2 +a file. +The default is the file system block size. +This option affects only binary transfers. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.It Sy recvbufsize Ar class Op Ar size +Set the size of the socket receive buffer. +The default is zero and the system default value will be used. +This option affects only passive transfers. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.It Sy sanenames Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, allow uploaded file names to contain any characters valid for a +file name. +Otherwise, only permit file names which don't start with a +.Sq \&. +and only comprise of characters from the set +.Dq [-+,._A-Za-z0-9] . +.It Sy sendbufsize Ar class Op Ar size +Set the size of the socket send buffer. +The default is zero and the system default value will be used. +This option affects only binary transfers. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.It Sy sendlowat Ar class Op Ar size +Set the low water mark of socket send buffer. +The default is zero and system default value will be used. +This option affects only for binary transfer. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.It Sy template Ar class Op Ar refclass +Define +.Ar refclass +as the +.Sq template +for +.Ar class ; +any reference to +.Ar refclass +in following directives will also apply to members of +.Ar class . +This is useful to define a template class so that other classes which are +to share common attributes can be easily defined without unnecessary +duplication. +There can be only one template defined at a time. +If +.Ar refclass +is not specified, disable the template for +.Ar class . +.It Sy timeout Ar class Op Ar time +Set the inactivity timeout period. +(the default is fifteen minutes). +This cannot be less than 30 seconds, or greater than the value for +.Sy maxtimeout . +If +.Ar class +is +.Dq none +or +.Ar time +is not specified, use the default. +.It Sy umask Ar class Op Ar umaskval +Set the umask to +.Ar umaskval . +If +.Ar class +is +.Dq none +or +.Ar umaskval +is not specified, set to the default of +.Li 027 . +.It Sy upload Ar class Op Sy off +If +.Ar class +is +.Dq none +or +.Sy off +is specified, disable the following commands: +.Sy APPE , +.Sy STOR , +and +.Sy STOU , +as well as the modify commands: +.Sy CHMOD , +.Sy DELE , +.Sy MKD , +.Sy RMD , +.Sy RNFR , +and +.Sy UMASK . +Otherwise, enable them. +.It Sy writesize Ar class Op Ar size +Limit the number of bytes to +.Xr write 2 +at a time. +The default is zero, which means all the data available as a result of +.Xr mmap 2 +or +.Xr read 2 +will be written at a time. +This option affects only binary transfers. +If +.Ar class +is +.Dq none +or +.Ar size +is not specified, use the default. +.El +.Ss Numeric argument suffix parsing +Where command arguments are numeric, a decimal number is expected. +Two or more numbers may be separated by an +.Dq x +to indicate a product. +Each number may have one of the following optional suffixes: +.Bl -tag -width 3n -offset indent -compact +.It b +Block; multiply by 512 +.It k +Kibi; multiply by 1024 (1 KiB) +.It m +Mebi; multiply by 1048576 (1 MiB) +.It g +Gibi; multiply by 1073741824 (1 GiB) +.It t +Tebi; multiply by 1099511627776 (1 TiB) +.It w +Word; multiply by the number of bytes in an integer +.El +.Pp +See +.Xr strsuftoll 3 +for more information. +.Sh DEFAULTS +The following defaults are used: +.Pp +.Bd -literal -offset indent -compact +checkportcmd all +classtype chroot CHROOT +classtype guest GUEST +classtype real REAL +display none +limit all \-1 # unlimited connections +maxtimeout all 7200 # 2 hours +modify all +motd all motd +notify none +passive all +timeout all 900 # 15 minutes +umask all 027 +upload all +modify guest off +umask guest 0707 +.Ed +.Sh FILES +.Bl -tag -width /usr/share/examples/ftpd/ftpd.conf -compact +.It Pa /etc/ftpd.conf +This file. +.It Pa /usr/share/examples/ftpd/ftpd.conf +A sample +.Nm +file. +.El +.Sh SEE ALSO +.Xr strsuftoll 3 , +.Xr ftpchroot 5 , +.Xr ftpusers 5 , +.Xr ftpd 8 +.Sh HISTORY +The +.Nm +functionality was implemented in +.Nx 1.3 +and later releases by Luke Mewburn, based on work by Simon Burge. diff --git a/static/netbsd/man5/ftpusers.5 b/static/netbsd/man5/ftpusers.5 new file mode 100644 index 00000000..285f385f --- /dev/null +++ b/static/netbsd/man5/ftpusers.5 @@ -0,0 +1,179 @@ +.\" $NetBSD: ftpusers.5,v 1.17 2008/09/13 02:41:52 lukem Exp $ +.\" +.\" Copyright (c) 1997-2008 The NetBSD Foundation, Inc. +.\" All rights reserved. +.\" +.\" This code is derived from software contributed to The NetBSD Foundation +.\" by Luke Mewburn. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.Dd July 17, 2000 +.Dt FTPUSERS 5 +.Os +.Sh NAME +.Nm ftpusers , +.Nm ftpchroot +.Nd +.Xr ftpd 8 +access control file +.Sh DESCRIPTION +The +.Nm +file provides user access control for +.Xr ftpd 8 +by defining which users may login. +.Pp +If the +.Nm +file does not exist, all users are denied access. +.Pp +A +.Dq \e +is the escape character; it can be used to escape the meaning of the +comment character, or if it is the last character on a line, extends +a configuration directive across multiple lines. +A +.Dq # +is the comment character, and all characters from it to the end of +line are ignored (unless it is escaped with the escape character). +.Pp +The syntax of each line is: +.Dl userglob[:groupglob][@host] [directive [class]] +.Pp +These elements are: +.Bl -tag -width "groupglob" -offset indent +.It Sy userglob +matched against the user name, using +.Xr fnmatch 3 +glob matching +(e.g, +.Sq f* ) . +.It Sy groupglob +matched against all the groups that the user is a member of, using +.Xr fnmatch 3 +glob matching +(e.g, +.Sq *src ) . +.It Sy host +either a CIDR address (refer to +.Xr inet_net_pton 3 ) +to match against the remote address +(e.g, +.Sq 1.2.3.4/24 ) , +or an +.Xr fnmatch 3 +glob to match against the remote hostname +(e.g, +.Sq *.NetBSD.org ) . +.It Sy directive +If +.Dq allow +or +.Dq yes +the user is allowed access. +If +.Dq deny +or +.Dq no , +or +.Sy directive +is not given, the user is denied access. +.It Sy class +defines the class to use in +.Xr ftpd.conf 5 . +.El +.Pp +If +.Sy class +is not given, it defaults to one of the following: +.Bl -tag -width "chroot" -offset indent +.It Sy chroot +If there is a match in +.Sx /etc/ftpchroot +for the user. +.It Sy guest +If the user name is +.Dq anonymous +or +.Sq ftp . +.It Sy real +If neither of the above is true. +.El +.Pp +No further comparisons are attempted after the first successful match. +If no match is found, the user is granted access. +This syntax is backward-compatible with the old syntax. +.Pp +If a user requests a guest login, the +.Xr ftpd 8 +server checks to see that +both +.Dq anonymous +and +.Dq ftp +have access, so if you deny all users by default, you will need to add both +.Dq "anonymous allow" +and +.Dq "ftp allow" +to +.Pa /etc/ftpusers +in order to allow guest logins. +.Ss /etc/ftpchroot +The file +.Pa /etc/ftpchroot +is used to determine which users will have their session's root directory +changed (using +.Xr chroot 2 ) , +either to the directory specified in the +.Xr ftpd.conf 5 +.Sy chroot +directive (if set), +or to the home directory of the user. +If the file does not exist, the root directory change is not performed. +.Pp +The syntax is similar to +.Nm , +except that the +.Sy class +argument is ignored. +If there's a positive match, the session's root directory is changed. +No further comparisons are attempted after the first successful match. +This syntax is backward-compatible with the old syntax. +.Sh FILES +.Bl -tag -width /usr/share/examples/ftpd/ftpusers -compact +.It Pa /etc/ftpchroot +List of normal users who should have their ftp session's root directory +changed by using +.Xr chroot 2 . +.It Pa /etc/ftpusers +This file. +.It Pa /usr/share/examples/ftpd/ftpusers +A sample +.Nm +file. +.El +.Sh SEE ALSO +.Xr fnmatch 3 , +.Xr inet_net_pton 3 , +.Xr ftpd.conf 5 , +.Xr ftpd 8 diff --git a/static/netbsd/man5/gdbinit.5 b/static/netbsd/man5/gdbinit.5 new file mode 100644 index 00000000..a1faf825 --- /dev/null +++ b/static/netbsd/man5/gdbinit.5 @@ -0,0 +1,222 @@ +.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.42) +.\" +.\" Standard preamble: +.\" ======================================================================== +.de Sp \" Vertical space (when we can't use .PP) +.if t .sp .5v +.if n .sp +.. +.de Vb \" Begin verbatim text +.ft CW +.nf +.ne \\$1 +.. +.de Ve \" End verbatim text +.ft R +.fi +.. +.\" Set up some character translations and predefined strings. \*(-- will +.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left +.\" double quote, and \*(R" will give a right double quote. \*(C+ will +.\" give a nicer C++. Capital omega is used to do unbreakable dashes and +.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, +.\" nothing in troff, for use with C<>. +.tr \(*W- +.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' +.ie n \{\ +. ds -- \(*W- +. ds PI pi +. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch +. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch +. ds L" "" +. ds R" "" +. ds C` "" +. ds C' "" +'br\} +.el\{\ +. ds -- \|\(em\| +. ds PI \(*p +. ds L" `` +. ds R" '' +. ds C` +. ds C' +'br\} +.\" +.\" Escape single quotes in literal strings from groff's Unicode transform. +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" +.\" If the F register is >0, we'll generate index entries on stderr for +.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index +.\" entries marked with X<> in POD. Of course, you'll have to process the +.\" output yourself in some meaningful fashion. +.\" +.\" Avoid warning from groff about undefined register 'F'. +.de IX +.. +.nr rF 0 +.if \n(.g .if rF .nr rF 1 +.if (\n(rF:(\n(.g==0)) \{\ +. if \nF \{\ +. de IX +. tm Index:\\$1\t\\n%\t"\\$2" +.. +. if !\nF==2 \{\ +. nr % 0 +. nr F 2 +. \} +. \} +.\} +.rr rF +.\" +.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). +.\" Fear. Run. Save yourself. No user-serviceable parts. +. \" fudge factors for nroff and troff +.if n \{\ +. ds #H 0 +. ds #V .8m +. ds #F .3m +. ds #[ \f1 +. ds #] \fP +.\} +.if t \{\ +. ds #H ((1u-(\\\\n(.fu%2u))*.13m) +. ds #V .6m +. ds #F 0 +. ds #[ \& +. ds #] \& +.\} +. \" simple accents for nroff and troff +.if n \{\ +. ds ' \& +. ds ` \& +. ds ^ \& +. ds , \& +. ds ~ ~ +. ds / +.\} +.if t \{\ +. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" +. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' +. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' +. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' +. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' +. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' +.\} +. \" troff and (daisy-wheel) nroff accents +.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' +.ds 8 \h'\*(#H'\(*b\h'-\*(#H' +.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] +.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' +.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' +.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] +.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] +.ds ae a\h'-(\w'a'u*4/10)'e +.ds Ae A\h'-(\w'A'u*4/10)'E +. \" corrections for vroff +.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' +.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' +. \" for low resolution devices (crt and lpr) +.if \n(.H>23 .if \n(.V>19 \ +\{\ +. ds : e +. ds 8 ss +. ds o a +. ds d- d\h'-1'\(ga +. ds D- D\h'-1'\(hy +. ds th \o'bp' +. ds Th \o'LP' +. ds ae ae +. ds Ae AE +.\} +.rm #[ #] #H #V #F C +.\" ======================================================================== +.\" +.IX Title "GDBINIT 5" +.TH GDBINIT 5 "2025-12-20" "gdb-17.1" "GNU Development Tools" +.\" For nroff, turn off justification. Always turn off hyphenation; it makes +.\" way too many mistakes in technical documents. +.if n .ad l +.nh +.SH "NAME" +gdbinit \- GDB initialization scripts +.SH "SYNOPSIS" +.IX Header "SYNOPSIS" +~/.config/gdb/gdbinit +.PP +~/.gdbinit +.PP +\&./.gdbinit +.SH "DESCRIPTION" +.IX Header "DESCRIPTION" +These files contain \s-1GDB\s0 commands to automatically execute during +\&\s-1GDB\s0 startup. The lines of contents are canned sequences of commands, +described in +the \s-1GDB\s0 manual in node \f(CW\*(C`Sequences\*(C'\fR +\&\*(-- shell command \f(CW\*(C`info \-f gdb \-n Sequences\*(C'\fR. +.PP +Please read more in +the \s-1GDB\s0 manual in node \f(CW\*(C`Startup\*(C'\fR +\&\*(-- shell command \f(CW\*(C`info \-f gdb \-n Startup\*(C'\fR. +.ie n .IP "\fB(not enabled with \f(CB""\-\-with\-system\-gdbinit""\fB during compilation)\fR" 4 +.el .IP "\fB(not enabled with \f(CB\-\-with\-system\-gdbinit\fB during compilation)\fR" 4 +.IX Item "(not enabled with --with-system-gdbinit during compilation)" +System-wide initialization file. It is executed unless user specified +\&\s-1GDB\s0 option \f(CW\*(C`\-nx\*(C'\fR or \f(CW\*(C`\-n\*(C'\fR. +See more in +the \s-1GDB\s0 manual in node \f(CW\*(C`System\-wide configuration\*(C'\fR +\&\*(-- shell command \f(CW\*(C`info \-f gdb \-n \*(AqSystem\-wide configuration\*(Aq\*(C'\fR. +.ie n .IP "\fB(not enabled with \f(CB""\-\-with\-system\-gdbinit\-dir""\fB during compilation)\fR" 4 +.el .IP "\fB(not enabled with \f(CB\-\-with\-system\-gdbinit\-dir\fB during compilation)\fR" 4 +.IX Item "(not enabled with --with-system-gdbinit-dir during compilation)" +System-wide initialization directory. All files in this directory are +executed on startup unless user specified \s-1GDB\s0 option \f(CW\*(C`\-nx\*(C'\fR or +\&\f(CW\*(C`\-n\*(C'\fR, as long as they have a recognized file extension. +See more in +the \s-1GDB\s0 manual in node \f(CW\*(C`System\-wide configuration\*(C'\fR +\&\*(-- shell command \f(CW\*(C`info \-f gdb \-n \*(AqSystem\-wide configuration\*(Aq\*(C'\fR. +.IP "\fB\f(BI~/.config/gdb/gdbinit\fB or \f(BI~/.gdbinit\fB\fR" 4 +.IX Item "~/.config/gdb/gdbinit or ~/.gdbinit" +User initialization file. It is executed unless user specified +\&\s-1GDB\s0 options \f(CW\*(C`\-nx\*(C'\fR, \f(CW\*(C`\-n\*(C'\fR or \f(CW\*(C`\-nh\*(C'\fR. +.IP "\fB\f(BI.gdbinit\fB\fR" 4 +.IX Item ".gdbinit" +Initialization file for current directory. It may need to be enabled with +\&\s-1GDB\s0 security command \f(CW\*(C`set auto\-load local\-gdbinit\*(C'\fR. +See more in +the \s-1GDB\s0 manual in node \f(CW\*(C`Init File in the Current Directory\*(C'\fR +\&\*(-- shell command \f(CW\*(C`info \-f gdb \-n \*(AqInit File in the Current Directory\*(Aq\*(C'\fR. +.SH "OPTIONS" +.IX Header "OPTIONS" +.SH "ENVIRONMENT" +.IX Header "ENVIRONMENT" +.SH "SEE ALSO" +.IX Header "SEE ALSO" +\&\fBgdb\fR\|(1), \f(CW\*(C`info \-f gdb \-n Startup\*(C'\fR +.PP +The full documentation for \s-1GDB\s0 is maintained as a Texinfo manual. +If the \f(CW\*(C`info\*(C'\fR and \f(CW\*(C`gdb\*(C'\fR programs and \s-1GDB\s0's Texinfo +documentation are properly installed at your site, the command +.PP +.Vb 1 +\& info gdb +.Ve +.PP +should give you access to the complete manual. +.PP +\&\fIUsing \s-1GDB: A\s0 Guide to the \s-1GNU\s0 Source-Level Debugger\fR, +Richard M. Stallman and Roland H. Pesch, July 1991. +.SH "COPYRIGHT" +.IX Header "COPYRIGHT" +Copyright (c) 1988\-2025 Free Software Foundation, Inc. +.PP +Permission is granted to copy, distribute and/or modify this document +under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or +any later version published by the Free Software Foundation; with the +Invariant Sections being \*(L"Free Software\*(R" and \*(L"Free Software Needs +Free Documentation\*(R", with the Front-Cover Texts being \*(L"A \s-1GNU\s0 Manual,\*(R" +and with the Back-Cover Texts as in (a) below. +.PP +(a) The \s-1FSF\s0's Back-Cover Text is: \*(L"You are free to copy and modify +this \s-1GNU\s0 Manual. Buying copies from \s-1GNU\s0 Press supports the \s-1FSF\s0 in +developing \s-1GNU\s0 and promoting software freedom.\*(R" diff --git a/static/netbsd/man5/generic.5 b/static/netbsd/man5/generic.5 new file mode 100644 index 00000000..b0b47a6b --- /dev/null +++ b/static/netbsd/man5/generic.5 @@ -0,0 +1,276 @@ +.\" $NetBSD: generic.5,v 1.5 2025/02/25 19:15:42 christos Exp $ +.\" +.TH GENERIC 5 +.ad +.fi +.SH NAME +generic +\- +Postfix generic table format +.SH "SYNOPSIS" +.na +.nf +\fBpostmap /etc/postfix/generic\fR + +\fBpostmap \-q "\fIstring\fB" /etc/postfix/generic\fR + +\fBpostmap \-q \- /etc/postfix/generic <\fIinputfile\fR +.SH DESCRIPTION +.ad +.fi +The optional \fBgeneric\fR(5) table specifies an address +mapping that applies when mail is delivered. This is the +opposite of \fBcanonical\fR(5) mapping, which applies when +mail is received. + +Typically, one would use the \fBgeneric\fR(5) table on a +system that does not have a valid Internet domain name and +that uses something like \fIlocaldomain.local\fR instead. +The \fBgeneric\fR(5) table is then used by the \fBsmtp\fR(8) +client to transform local mail addresses into valid Internet +mail addresses when mail has to be sent across the Internet. +See the EXAMPLE section at the end of this document. + +The \fBgeneric\fR(5) mapping affects both message header +addresses (i.e. addresses that appear inside messages) and +message envelope addresses (for example, the addresses that +are used in SMTP protocol commands). + +Normally, the \fBgeneric\fR(5) table is specified as a +text file that serves as input to the \fBpostmap\fR(1) +command. The result, an indexed file in \fBdbm\fR or +\fBdb\fR format, is used for fast searching by the mail +system. Execute the command "\fBpostmap /etc/postfix/generic\fR" +to rebuild an indexed file after changing the corresponding +text file. + +When the table is provided via other means such as NIS, LDAP +or SQL, the same lookups are done as for ordinary indexed files. + +Alternatively, the table can be provided as a regular\-expression +map where patterns are given as regular expressions, or lookups +can be directed to a TCP\-based server. In those cases, the lookups +are done in a slightly different way as described below under +"REGULAR EXPRESSION TABLES" or "TCP\-BASED TABLES". +.SH "CASE FOLDING" +.na +.nf +.ad +.fi +The search string is folded to lowercase before database +lookup. As of Postfix 2.3, the search string is not case +folded with database types such as regexp: or pcre: whose +lookup fields can match both upper and lower case. +.SH "TABLE FORMAT" +.na +.nf +.ad +.fi +The input format for the \fBpostmap\fR(1) command is as follows: +.IP "\fIpattern result\fR" +When \fIpattern\fR matches a mail address, replace it by the +corresponding \fIresult\fR. +.IP "blank lines and comments" +Empty lines and whitespace\-only lines are ignored, as +are lines whose first non\-whitespace character is a `#'. +.IP "multi\-line text" +A logical line starts with non\-whitespace text. A line that +starts with whitespace continues a logical line. +.SH "TABLE SEARCH ORDER" +.na +.nf +.ad +.fi +With lookups from indexed files such as DB or DBM, or from networked +tables such as NIS, LDAP or SQL, each \fIuser\fR@\fIdomain\fR +query produces a sequence of query patterns as described below. + +Each query pattern is sent to each specified lookup table +before trying the next query pattern, until a match is +found. +.IP "\fIuser\fR@\fIdomain address\fR" +Replace \fIuser\fR@\fIdomain\fR by \fIaddress\fR. This form +has the highest precedence. +.IP "\fIuser address\fR" +Replace \fIuser\fR@\fIsite\fR by \fIaddress\fR when \fIsite\fR is +equal to $\fBmyorigin\fR, when \fIsite\fR is listed in +$\fBmydestination\fR, or when it is listed in $\fBinet_interfaces\fR +or $\fBproxy_interfaces\fR. +.IP "@\fIdomain address\fR" +Replace other addresses in \fIdomain\fR by \fIaddress\fR. +This form has the lowest precedence. +.SH "RESULT ADDRESS REWRITING" +.na +.nf +.ad +.fi +The lookup result is subject to address rewriting: +.IP \(bu +When the result has the form @\fIotherdomain\fR, the +result becomes the same \fIuser\fR in \fIotherdomain\fR. +.IP \(bu +When "\fBappend_at_myorigin=yes\fR", append "\fB@$myorigin\fR" +to addresses without "@domain". +.IP \(bu +When "\fBappend_dot_mydomain=yes\fR", append +"\fB.$mydomain\fR" to addresses without ".domain". +.SH "ADDRESS EXTENSION" +.na +.nf +.fi +.ad +When a mail address localpart contains the optional recipient delimiter +(e.g., \fIuser+foo\fR@\fIdomain\fR), the lookup order becomes: +\fIuser+foo\fR@\fIdomain\fR, \fIuser\fR@\fIdomain\fR, \fIuser+foo\fR, +\fIuser\fR, and @\fIdomain\fR. + +The \fBpropagate_unmatched_extensions\fR parameter controls whether +an unmatched address extension (\fI+foo\fR) is propagated to the +result of table lookup. +.SH "REGULAR EXPRESSION TABLES" +.na +.nf +.ad +.fi +This section describes how the table lookups change when the table +is given in the form of regular expressions. For a description of +regular expression lookup table syntax, see \fBregexp_table\fR(5) +or \fBpcre_table\fR(5). + +Each pattern is a regular expression that is applied to the entire +address being looked up. Thus, \fIuser@domain\fR mail addresses are not +broken up into their \fIuser\fR and \fI@domain\fR constituent parts, +nor is \fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. + +Patterns are applied in the order as specified in the table, until a +pattern is found that matches the search string. + +Results are the same as with indexed file lookups, with +the additional feature that parenthesized substrings from the +pattern can be interpolated as \fB$1\fR, \fB$2\fR and so on. +.SH "TCP-BASED TABLES" +.na +.nf +.ad +.fi +This section describes how the table lookups change when lookups +are directed to a TCP\-based server. For a description of the TCP +client/server lookup protocol, see \fBtcp_table\fR(5). +This feature is available in Postfix 2.5 and later. + +Each lookup operation uses the entire address once. Thus, +\fIuser@domain\fR mail addresses are not broken up into their +\fIuser\fR and \fI@domain\fR constituent parts, nor is +\fIuser+foo\fR broken up into \fIuser\fR and \fIfoo\fR. + +Results are the same as with indexed file lookups. +.SH "EXAMPLE" +.na +.nf +.ad +.fi +The following shows a generic mapping with an indexed file. +When mail is sent to a remote host via SMTP, this replaces +\fIhis@localdomain.local\fR by his ISP mail address, replaces +\fIher@localdomain.local\fR by her ISP mail address, and +replaces other local addresses by his ISP account, with +an address extension of \fI+local\fR (this example assumes +that the ISP supports "+" style address extensions). + +.na +.nf +/etc/postfix/main.cf: + smtp_generic_maps = hash:/etc/postfix/generic + +/etc/postfix/generic: + his@localdomain.local hisaccount@hisisp.example + her@localdomain.local heraccount@herisp.example + @localdomain.local hisaccount+local@hisisp.example + +.ad +.fi +Execute the command "\fBpostmap /etc/postfix/generic\fR" +whenever the table is changed. Instead of \fBhash\fR, some +systems use \fBdbm\fR database files. To find out what +tables your system supports use the command "\fBpostconf +\-m\fR". +.SH BUGS +.ad +.fi +The table format does not understand quoting conventions. +.SH "CONFIGURATION PARAMETERS" +.na +.nf +.ad +.fi +The following \fBmain.cf\fR parameters are especially relevant. +The text below provides only a parameter summary. See +\fBpostconf\fR(5) for more details including examples. +.IP "\fBsmtp_generic_maps (empty)\fR" +Optional lookup tables that perform address rewriting in the +Postfix SMTP client, typically to transform a locally valid address into +a globally valid address when sending mail across the Internet. +.IP "\fBpropagate_unmatched_extensions (canonical, virtual)\fR" +What address lookup tables copy an address extension from the lookup +key to the lookup result. +.PP +Other parameters of interest: +.IP "\fBinet_interfaces (all)\fR" +The local network interface addresses that this mail system +receives mail on. +.IP "\fBproxy_interfaces (empty)\fR" +The remote network interface addresses that this mail system receives mail +on by way of a proxy or network address translation unit. +.IP "\fBmydestination ($myhostname, localhost.$mydomain, localhost)\fR" +The list of domains that are delivered via the $local_transport +mail delivery transport. +.IP "\fBmyorigin ($myhostname)\fR" +The domain name that locally\-posted mail appears to come +from, and that locally posted mail is delivered to. +.IP "\fBowner_request_special (yes)\fR" +Enable special treatment for owner\-\fIlistname\fR entries in the +\fBaliases\fR(5) file, and don't split owner\-\fIlistname\fR and +\fIlistname\fR\-request address localparts when the recipient_delimiter +is set to "\-". +.SH "SEE ALSO" +.na +.nf +postmap(1), Postfix lookup table manager +postconf(5), configuration parameters +smtp(8), Postfix SMTP client +.SH "README FILES" +.na +.nf +.ad +.fi +Use "\fBpostconf readme_directory\fR" or +"\fBpostconf html_directory\fR" to locate this information. +.na +.nf +ADDRESS_REWRITING_README, address rewriting guide +DATABASE_README, Postfix lookup table overview +STANDARD_CONFIGURATION_README, configuration examples +.SH "LICENSE" +.na +.nf +.ad +.fi +The Secure Mailer license must be distributed with this software. +.SH HISTORY +.ad +.fi +A genericstable feature appears in the Sendmail MTA. + +This feature is available in Postfix 2.2 and later. +.SH "AUTHOR(S)" +.na +.nf +Wietse Venema +IBM T.J. Watson Research +P.O. Box 704 +Yorktown Heights, NY 10598, USA + +Wietse Venema +Google, Inc. +111 8th Avenue +New York, NY 10011, USA diff --git a/static/netbsd/man5/gettytab.5 b/static/netbsd/man5/gettytab.5 new file mode 100644 index 00000000..2c2ddd47 --- /dev/null +++ b/static/netbsd/man5/gettytab.5 @@ -0,0 +1,447 @@ +.\" $NetBSD: gettytab.5,v 1.40 2019/07/15 01:26:15 uwe Exp $ +.\" +.\" Copyright (c) 1983, 1991, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" from: @(#)gettytab.5 8.4 (Berkeley) 4/19/94 +.\" +.Dd April 5, 2012 +.Dt GETTYTAB 5 +.Os +.Sh NAME +.Nm gettytab +.Nd terminal configuration data base +.Sh SYNOPSIS +.Nm +.Sh DESCRIPTION +The +.Nm +file +is a simplified version of the +.Xr capfile 5 +data base +used to describe terminal lines. +The initial terminal login process +.Xr getty 8 +accesses the +.Nm +file each time it starts, allowing simpler +reconfiguration of terminal characteristics. +Each entry in the data base +is used to describe one class of terminals. +.Pp +Where to run +.Xr getty 8 +processes is normally defined by +.Xr ttys 5 . +.Pp +There is a default terminal class, +.Ic default , +that is used to set global defaults for all other classes. +(That is, the +.Ic default +entry is read, then the entry for the class required +is used to override particular settings.) +The +.Ic default +entry is also normally read by other programs that present login prompts +to the user, such as +.Xr telnetd 8 , +in order to retrieve the values of the +.Ic \&he , +.Ic \&hn , +.Ic \&im , +and +.Ic \&if +capabilities. +.Sh CAPABILITIES +Refer to +.Xr capfile 5 +for a description of the file layout. +The +.Sq Sy Default +column below lists defaults obtained if there is +no entry in the table obtained, nor one in the special +.Ic default +table. +.Bl -column ".Sy Name" ".Sy Type" "/usr/bin/login" +.It Sy Name Ta Sy Type Ta Sy Default Ta Sy Description +.It Ic \&ab Ta bool Ta false Ta Auto-baud speed select mechanism for the +Micom 600 portselector. Selection is done by looking at how the +character +.Ql \er +is garbled at 300, 1200, 4800, and 9600 baud. +.It Ic \&al Ta str Ta Dv NULL Ta user to auto-login instead of prompting +.It Ic \&ap Ta bool Ta false Ta terminal uses any parity +.It Ic \&bk Ta str Ta Li \e377 Ta alternative end of line character (input break) +.Pq Dv VEOL +.It Ic \&b2 Ta str Ta Li \e377 Ta alternative end of line character (input break) +.Pq Dv VEOL2 +.It Ic \&c0 Ta num Ta unused Ta tty control flags to write messages +.It Ic \&c1 Ta num Ta unused Ta tty control flags to read login name +.It Ic \&c2 Ta num Ta unused Ta tty control flags to leave terminal as +.It Ic \&ce Ta bool Ta false Ta use Tn CRT erase algorithm +.It Ic \&ck Ta bool Ta false Ta use Tn CRT kill algorithm +.It Ic \&cl Ta str Ta Dv NULL Ta screen clear sequence +.It Ic \&co Ta bool Ta false Ta console \(en add +.Ql \er\en +after login prompt +.It Ic \&cs Ta bool Ta false Ta clear screen based on terminal type in +.Pa /etc/ttys +.It Ic \&ds Ta str Ta So Li "^Y" Sc Ta delayed suspend character +.Pq Dv VDSUSP +.It Ic \&dx Ta bool Ta false Ta set Dv DECCTLQ +.It Ic \&ec Ta bool Ta false Ta leave echo +.Tn OFF +.It Ic \&ep Ta bool Ta false Ta terminal uses even parity +.It Ic \&er Ta str Ta So Li ^? Sc Ta erase character +.Pq Dv VERASE +.It Ic \&et Ta str Ta So Li ^D Sc Ta end of text +.Pq Dv VEOF +character +.It Ic \&ev Ta str Ta Dv NULL Ta initial environment +.It Ic \&f0 Ta num Ta unused Ta tty mode flags to write messages +.It Ic \&f1 Ta num Ta unused Ta tty mode flags to read login name +.It Ic \&f2 Ta num Ta unused Ta tty mode flags to leave terminal as +.It Ic \&fl Ta str Ta So Li ^O Sc Ta output flush character +.Pq Dv VDISCARD +.It Ic \&hc Ta bool Ta false Ta do +.Tn NOT +hangup line on last close +.It Ic \&he Ta str Ta Dv NULL Ta hostname editing string +.It Ic \&hn Ta str Ta hostname Ta hostname +.It Ic \&ht Ta bool Ta false Ta terminal has real tabs +.It Ic \&i0 Ta num Ta unused Ta tty input flags to write messages +.It Ic \&i1 Ta num Ta unused Ta tty input flags to read login name +.It Ic \&i2 Ta num Ta unused Ta tty input flags to leave terminal as +.It Ic \&if Ta str Ta Dv NULL Ta display named file before prompt, +like +.Pa /etc/issue +.It Ic \&ig Ta bool Ta false Ta ignore garbage characters in login name +.It Ic \&im Ta str Ta Dv NULL Ta initial (banner) message +.It Ic \&in Ta str Ta So Li ^C Sc Ta interrupt character +.Pq Dv VINTR +.It Ic \&is Ta num Ta unused Ta input speed +.It Ic \&kl Ta str Ta So Li ^U Sc Ta kill character +.Pq Dv VKILL +.It Ic \&l0 Ta num Ta unused Ta tty local flags to write messages +.It Ic \&l1 Ta num Ta unused Ta tty local flags to read login name +.It Ic \&l2 Ta num Ta unused Ta tty local flags to leave terminal as +.It Ic \&lc Ta bool Ta false Ta terminal has lower case +.It Ic \&lm Ta str Ta login: Ta login prompt +.It Ic \&ln Ta str Ta So Li ^V Sc Ta So literal next Sc character +.Pq Dv VLNEXT +.It Ic \&lo Ta str Ta /usr/bin/login Ta program to exec when name obtained +.It Ic \&mb Ta bool Ta false Ta do flow control based on carrier +.It Ic \&nl Ta bool Ta false Ta terminal has (or might have) a newline character +.It Ic \&nn Ta bool Ta false Ta do not prompt for a login name +.It Ic \&np Ta bool Ta false Ta terminal uses no parity (i.e. 8-bit characters) +.It Ic \&nx Ta str Ta default Ta next table (for auto speed selection) +.It Ic \&o0 Ta num Ta unused Ta tty output flags to write messages +.It Ic \&o1 Ta num Ta unused Ta tty output flags to read login name +.It Ic \&o2 Ta num Ta unused Ta tty output flags to leave terminal as +.It Ic \&op Ta bool Ta false Ta terminal uses odd parity +.It Ic \&os Ta num Ta unused Ta output speed +.It Ic \&pc Ta str Ta So Li \e0 Sc Ta pad character +.It Ic \&pe Ta bool Ta false Ta use printer (hard copy) erase algorithm +.It Ic \&pf Ta num Ta 0 Ta delay between first prompt and following +flush (seconds) +.It Ic \&pp Ta str Ta unused Ta Tn PPP authentication program +.It Ic \&ps Ta bool Ta false Ta line connected to a +.Tn MICOM +port selector +.It Ic \&qu Ta str Ta So Li \&^\e Sc Ta quit character +.Pq Dv VQUIT +.It Ic \&rp Ta str Ta So Li ^R Sc Ta line retype character +.Pq Dv VREPRINT +.It Ic \&rw Ta bool Ta false Ta do +.Tn NOT +use +.Dv RAW +for input, use +.Dv CBREAK +.It Ic \&sp Ta num Ta unused Ta line speed (input and output) +.It Ic \&st Ta str Ta So Li ^T Sc Ta status character +.Pq Dv VSTATUS +.It Ic \&su Ta str Ta So Li ^Z Sc Ta suspend character +.Pq Dv VSUSP +.It Ic \&tc Ta str Ta none Ta table continuation +.It Ic \&to Ta num Ta 0 Ta timeout (seconds) +.It Ic \&tt Ta str Ta Dv NULL Ta terminal type (for environment) +.It Ic \&ub Ta bool Ta false Ta do unbuffered output (of prompts etc) +.It Ic \&we Ta str Ta So Li ^W Sc Ta word erase character +.Pq Dv VWERASE +.It Ic \&xc Ta bool Ta false Ta do +.Tn NOT +echo control chars as +.Ql ^X +.It Ic \&xf Ta str Ta So Li ^S Sc Ta Tn XOFF +(stop output) character +.Pq Dv VSTOP +.It Ic \&xn Ta str Ta So Li ^Q Sc Ta Tn XON +(start output) character +.Pq Dv VSTART +.El +.Pp +The following capabilities are no longer supported by +.Xr getty 8 : +.Bl -column ".Sy Name" ".Sy Type" "/usr/bin/login" +.It Ic \&bd Ta num Ta 0 Ta backspace delay +.It Ic \&cb Ta bool Ta false Ta use Tn CRT backspace mode +.It Ic \&cd Ta num Ta 0 Ta carriage-return delay +.It Ic \&fd Ta num Ta 0 Ta form-feed (vertical motion) delay +.It Ic \&nd Ta num Ta 0 Ta newline (line-feed) delay +.It Ic \&uc Ta bool Ta false Ta terminal is known upper case only +.El +.Pp +If no line speed is specified, speed will not be altered +from that which prevails when getty is entered. +Specifying an input or output speed will override +line speed for stated direction only. +.Pp +Terminal modes to be used for the output of the message, +for input of the login name, +and to leave the terminal set as upon completion, +are derived from the boolean flags specified. +If the derivation should prove inadequate, +any (or all) of these three may be overridden +with one of the +.Ic \&c0 , +.Ic \&c1 , +.Ic \&c2 , +.Ic \&i0 , +.Ic \&i1 , +.Ic \&i2 , +.Ic \&l0 , +.Ic \&l1 , +.Ic \&l2 , +.Ic \&o0 , +.Ic \&o1 , +or +.Ic \&o2 +numeric specifications, which can be used to specify +(usually in octal, with a leading +.Ql 0 ) +the exact values of the flags. +These flags correspond to the termios +.Fa c_cflag , +.Fa c_iflag , +.Fa c_lflag , +and +.Fa c_oflag +fields, respectively. +Each these sets must be completely specified to be effective. +The +.Ic \&f0 , +.Ic \&f1 , +and +.Ic \&f2 +are excepted for backwards compatibility with a previous incarnation of +the TTY sub-system. +In these flags the bottom 16 bits of the (32 bits) value contain the +.Vt sgttyb +.Fa sg_flags +field, while the top 16 bits represent the local mode word. +.Pp +Should +.Xr getty 8 +receive a null character +(presumed to indicate a line break) +it will restart using the table indicated by the +.Ic nx +entry. +If there is none, it will re-use its original table. +.Pp +Delays are specified in milliseconds, the nearest possible +delay available in the tty driver will be used. +Should greater certainty be desired, delays +with values 0, 1, 2, and 3 are interpreted as +choosing that particular delay algorithm from the driver. +.Pp +The +.Ic \&cl +screen clear string may be preceded by a (decimal) number +of milliseconds of delay required (a la termcap). +This delay is simulated by repeated use of the pad character +.Ic \&pc . +.Pp +The initial message +.Ic \&im\^ , +and login message +.Ic \&lm +may include any of the following character sequences, which expand to +information about the environment in which +.Xr getty 8 +is running. +.Bl -tag -width ".Li XXXX" +.It Li \&%d +The current date. +.It Li \&%h +The hostname of the machine, which is normally obtained from the +system using +.Xr gethostname 3 , +but may also be overridden by the +.Ic \&hn +table entry. +In either case it may be edited with the +.Ic \&he +string. +A +.Ql @ +in the +.Ic \&he +string causes one character from the real hostname to +be copied to the final hostname. +A +.Ql # +in the +.Ic \&he +string causes the next character of the real hostname +to be skipped. +Each character that +is neither +.Ql @ +nor +.Ql # +is copied into the final hostname. +Surplus +.Ql @ +and +.Ql # +characters are ignored. +.It Li \&%t +The tty name. +.It Li \&%m , \&%r , \&%s , \&%v +The type of machine, release of the operating system, name of the +operating system, and version of the kernel, respectively, as +returned by +.Xr uname 3 . +.It Li \&%% +A +.Ql % +character. +.El +.Pp +When getty execs the login process, given +in the +.Ic \&lo +string (usually +.Dq Pa /usr/bin/login ) , +it will have set +the environment to include the terminal type, as indicated +by the +.Ic \&tt +string (if it exists). +The +.Ic \&ev +string, can be used to enter additional data into +the environment. +It is a list of comma separated strings, each of which +will presumably be of the form +.Ar name Ns Li \^= Ns Ar value . +.Pp +If a non-zero timeout is specified, with +.Ic \&to , +then getty will exit within the indicated +number of seconds, either having +received a login name and passed control +to +.Xr login 1 , +or having received an alarm signal, and exited. +This may be useful to hangup dial in lines. +.Pp +Output from +.Xr getty 8 +is even parity unless +.Ic \&op +or +.Ic \&np +is specified. +The +.Ic \&op +string +may be specified with +.Ic \&ap +to allow any parity on input, but generate odd parity output. +Note: this only applies while getty is being run, +terminal driver limitations prevent a more complete +implementation. +.Xr getty 8 +does not check parity of input characters in +.Dv RAW +mode. +.Pp +If +.Ic \&pp +string is specified and a Point to Point Protocol +.Pq Tn PPP +link bringup sequence is recognized, +.Xr getty 8 +will invoke the program referenced by the +.Ic \&pp +string, e.g.\& +.Xr pppd 8 . +This can be used to handle incoming +.Tn PPP +calls. +.Sh SEE ALSO +.Xr login 1 , +.Xr gethostname 3 , +.Xr uname 3 , +.Xr capfile 5 , +.Xr ttys 5 , +.Xr getty 8 , +.Xr pppd 8 , +.Xr telnetd 8 +.Sh HISTORY +The +.Nm +file format appeared in +.Bx 4.2 . +.Sh BUGS +The special characters (erase, kill, etc.) are reset to system defaults +by +.Xr login 1 . +In +.Em all +cases, +.Ql # +or +.Ql ^H +typed in a login name will be treated as +an erase character, and +.Ql @ +will be treated as a kill character. +.Pp +The delay stuff is a real crock. +Apart from its general lack of flexibility, some +of the delay algorithms are not implemented. +The terminal driver should support sane delay settings. +.Pp +The +.Ic \&he +capability is stupid. diff --git a/static/netbsd/man5/header_checks.5 b/static/netbsd/man5/header_checks.5 new file mode 100644 index 00000000..2156cc1f --- /dev/null +++ b/static/netbsd/man5/header_checks.5 @@ -0,0 +1,524 @@ +.\" $NetBSD: header_checks.5,v 1.4 2025/02/25 19:15:42 christos Exp $ +.\" +.TH HEADER_CHECKS 5 +.ad +.fi +.SH NAME +header_checks +\- +Postfix built\-in content inspection +.SH "SYNOPSIS" +.na +.nf +.nf +\fBheader_checks = pcre:/etc/postfix/header_checks\fR +\fBmime_header_checks = pcre:/etc/postfix/mime_header_checks\fR +\fBnested_header_checks = pcre:/etc/postfix/nested_header_checks\fR +\fBbody_checks = pcre:/etc/postfix/body_checks\fR +.sp +\fBmilter_header_checks = pcre:/etc/postfix/milter_header_checks\fR +.sp +\fBsmtp_header_checks = pcre:/etc/postfix/smtp_header_checks\fR +\fBsmtp_mime_header_checks = pcre:/etc/postfix/smtp_mime_header_checks\fR +\fBsmtp_nested_header_checks = pcre:/etc/postfix/smtp_nested_header_checks\fR +\fBsmtp_body_checks = pcre:/etc/postfix/smtp_body_checks\fR +.sp +\fBpostmap \-q "\fIstring\fB" pcre:/etc/postfix/\fIfilename\fR +\fBpostmap \-q \- pcre:/etc/postfix/\fIfilename\fR <\fIinputfile\fR +.fi +.SH DESCRIPTION +.ad +.fi +This document describes access control on the content of +message headers and message body lines; it is implemented +by the Postfix \fBcleanup\fR(8) server before mail is queued. +See \fBaccess\fR(5) for access control on remote SMTP client +information. + +Each message header or message body line is compared against +a list of patterns. +When a match is found the corresponding action is executed, and +the matching process is repeated for the next message header or +message body line. + +Note: message headers are examined one logical header at a time, +even when a message header spans multiple lines. Body lines are +always examined one line at a time. + +For examples, see the EXAMPLES section at the end of this +manual page. + +Postfix header or body_checks are designed to stop a flood of mail +from worms or viruses; they do not decode attachments, and they do +not unzip archives. See the documents referenced below in the README +FILES section if you need more sophisticated content analysis. +.SH "FILTERS WHILE RECEIVING MAIL" +.na +.nf +.ad +.fi +Postfix implements the following four built\-in content +inspection classes while receiving mail: +.IP "\fBheader_checks\fR (default: empty)" +These are applied to initial message headers (except for +the headers that are processed with \fBmime_header_checks\fR). +.IP "\fBmime_header_checks\fR (default: \fB$header_checks\fR)" +These are applied to MIME related message headers only. +.sp +This feature is available in Postfix 2.0 and later. +.IP "\fBnested_header_checks\fR (default: \fB$header_checks\fR)" +These are applied to message headers of attached email +messages (except for the headers that are processed with +\fBmime_header_checks\fR). +.sp +This feature is available in Postfix 2.0 and later. +.IP \fBbody_checks\fR +These are applied to all other content, including multi\-part +message boundaries. +.sp +With Postfix versions before 2.0, all content after the initial +message headers is treated as body content. +.SH "FILTERS AFTER RECEIVING MAIL" +.na +.nf +.ad +.fi +Postfix supports a subset of the built\-in content inspection +classes after the message is received: +.IP "\fBmilter_header_checks\fR (default: empty)" +These are applied to headers that are added with Milter +applications. +.sp +This feature is available in Postfix 2.7 and later. +.SH "FILTERS WHILE DELIVERING MAIL" +.na +.nf +.ad +.fi +Postfix supports all four content inspection classes while +delivering mail via SMTP. +.IP "\fBsmtp_header_checks\fR (default: empty)" +.IP "\fBsmtp_mime_header_checks\fR (default: empty)" +.IP "\fBsmtp_nested_header_checks\fR (default: empty)" +.IP "\fBsmtp_body_checks\fR (default: empty)" +These features are available in Postfix 2.5 and later. +.SH "COMPATIBILITY" +.na +.nf +.ad +.fi +With Postfix version 2.2 and earlier specify "\fBpostmap +\-fq\fR" to query a table that contains case sensitive +patterns. By default, regexp: and pcre: patterns are case +insensitive. +.SH "TABLE FORMAT" +.na +.nf +.ad +.fi +This document assumes that header and body_checks rules are specified +in the form of Postfix regular expression lookup tables. Usually the +best performance is obtained with \fBpcre\fR (Perl Compatible Regular +Expression) tables. The \fBregexp\fR (POSIX regular +expressions) tables are usually slower, but more widely +available. +Use the command "\fBpostconf \-m\fR" to find out what lookup table +types your Postfix system supports. + +The general format of Postfix regular expression tables is +given below. +For a discussion of specific pattern or flags syntax, +see \fBpcre_table\fR(5) or \fBregexp_table\fR(5), respectively. +.IP "\fB/\fIpattern\fB/\fIflags action\fR" +When /\fIpattern\fR/ matches the input string, execute +the corresponding \fIaction\fR. See below for a list +of possible actions. +.IP "\fB!/\fIpattern\fB/\fIflags action\fR" +When /\fIpattern\fR/ does \fBnot\fR match the input string, +execute the corresponding \fIaction\fR. +.IP "\fBif /\fIpattern\fB/\fIflags\fR" +.IP "\fBendif\fR" +If the input string matches /\fIpattern\fR/, then match that +input string against the patterns between \fBif\fR and +\fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +.sp +Note: do not prepend whitespace to patterns inside +\fBif\fR..\fBendif\fR. +.IP "\fBif !/\fIpattern\fB/\fIflags\fR" +.IP "\fBendif\fR" +If the input string does not match /\fIpattern\fR/, then +match that input string against the patterns between \fBif\fR +and \fBendif\fR. The \fBif\fR..\fBendif\fR can nest. +.IP "blank lines and comments" +Empty lines and whitespace\-only lines are ignored, as +are lines whose first non\-whitespace character is a `#'. +.IP "multi\-line text" +A pattern/action line starts with non\-whitespace text. A line that +starts with whitespace continues a logical line. +.SH "TABLE SEARCH ORDER" +.na +.nf +.ad +.fi +For each line of message input, the patterns are applied in the +order as specified in the table. When a pattern is found that matches +the input line, the corresponding action is executed and then the +next input line is inspected. +.SH "TEXT SUBSTITUTION" +.na +.nf +.ad +.fi +Substitution of substrings from the matched expression into the +\fIaction\fR +string is possible using the conventional Perl syntax +(\fB$1\fR, \fB$2\fR, etc.). +The macros in the result string may need to be written as \fB${n}\fR +or \fB$(n)\fR if they aren't followed by whitespace. + +Note: since negated patterns (those preceded by \fB!\fR) return a +result when the expression does not match, substitutions are not +available for negated patterns. +.SH "ACTIONS" +.na +.nf +.ad +.fi +Action names are case insensitive. They are shown in upper case +for consistency with other Postfix documentation. +.IP "\fBBCC \fIuser@domain\fR" +Add the specified address as a BCC recipient, and inspect +the next input line. The address +must have a local part and domain part. The number of BCC +addresses that can be added is limited only by the amount +of available storage space. + +Note 1: the BCC address is added as if it was specified with +NOTIFY=NONE. The sender will not be notified when the BCC +address is undeliverable, as long as all down\-stream software +implements RFC 3461. + +Note 2: this ignores duplicate addresses (with the same +delivery status notification options). +.sp +This feature is available in Postfix 3.0 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP "\fBDISCARD \fIoptional text...\fR" +Claim successful delivery and silently discard the message. +Do not inspect the remainder of the input message. +Log the optional text if specified, otherwise log a generic +message. +.sp +Note: this action disables further header or body_checks inspection +of the current message and affects all recipients. +To discard only one recipient without discarding the entire message, +use the transport(5) table to direct mail to the discard(8) service. +.sp +This feature is available in Postfix 2.0 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP \fBDUNNO\fR +Pretend that the input line did not match any pattern, and inspect the +next input line. This action can be used to shorten the table search. +.sp +For backwards compatibility reasons, Postfix also accepts +\fBOK\fR but it is (and always has been) treated as \fBDUNNO\fR. +.sp +This feature is available in Postfix 2.1 and later. +.IP "\fBFILTER \fItransport:destination\fR" +Override the content_filter parameter setting, and inspect +the next input line. +After the message is queued, send the entire message through +the specified external content filter. The \fItransport\fR +name specifies the first field of a mail delivery agent +definition in master.cf; the syntax of the next\-hop +\fIdestination\fR is described in the manual page of the +corresponding delivery agent. More information about +external content filters is in the Postfix FILTER_README +file. +.sp +Note 1: do not use $\fInumber\fR regular expression +substitutions for \fItransport\fR or \fIdestination\fR +unless you know that the information has a trusted origin. +.sp +Note 2: this action overrides the main.cf \fBcontent_filter\fR +setting, and affects all recipients of the message. In the +case that multiple \fBFILTER\fR actions fire, only the last +one is executed. +.sp +Note 3: the purpose of the FILTER command is to override +message routing. To override the recipient's \fItransport\fR +but not the next\-hop \fIdestination\fR, specify an empty +filter \fIdestination\fR (Postfix 2.7 and later), or specify +a \fItransport:destination\fR that delivers through a +different Postfix instance (Postfix 2.6 and earlier). Other +options are using the recipient\-dependent \fBtrans\%port\%_maps\fR +or the sen\%der\-dependent +\fBsender\%_de\%pen\%dent\%_de\%fault\%_trans\%port\%_maps\fR +features. +.sp +This feature is available in Postfix 2.0 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP "\fBHOLD \fIoptional text...\fR" +Arrange for the message to be placed on the \fBhold\fR queue, +and inspect the next input line. The message remains on \fBhold\fR +until someone either deletes it or releases it for delivery. +Log the optional text if specified, otherwise log a generic +message. + +Mail that is placed on hold can be examined with the +\fBpostcat\fR(1) command, and can be destroyed or released with +the \fBpostsuper\fR(1) command. +.sp +Note: use "\fBpostsuper \-r\fR" to release mail that was kept on +hold for a significant fraction of \fB$maximal_queue_lifetime\fR +or \fB$bounce_queue_lifetime\fR, or longer. Use "\fBpostsuper \-H\fR" +only for mail that will not expire within a few delivery attempts. +.sp +Note: this action affects all recipients of the message. +.sp +This feature is available in Postfix 2.0 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP \fBIGNORE\fR +Delete the current line from the input, and inspect +the next input line. See \fBSTRIP\fR for an alternative +that logs the action. +.IP "\fBINFO \fIoptional text...\fR +Log an "info:" record with the \fIoptional text...\fR (or +log a generic text), and inspect the next input line. This +action is useful for routine logging or for debugging. +.sp +This feature is available in Postfix 2.8 and later. +.IP "\fBPASS \fIoptional text...\fR" +Log a "pass:" record with the \fIoptional text...\fR (or +log a generic text), and turn off header, body, and Milter +inspection for the remainder of this message. +.sp +Note: this feature relies on trust in information that is +easy to forge. +.sp +This feature is available in Postfix 3.2 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP "\fBPREPEND \fItext...\fR" +Prepend one line with the specified text, and inspect the next +input line. +.sp +Notes: +.RS +.IP \(bu +The prepended text is output on a separate line, immediately +before the input that triggered the \fBPREPEND\fR action. +.IP \(bu +The prepended text is not considered part of the input +stream: it is not subject to header/body checks or address +rewriting, and it does not affect the way that Postfix adds +missing message headers. +.IP \(bu +When prepending text before a message header line, the prepended +text must begin with a valid message header label. +.IP \(bu +This action cannot be used to prepend multi\-line text. +.RE +.IP +This feature is available in Postfix 2.1 and later. +.sp +This feature is not supported with milter_header_checks. +.IP "\fBREDIRECT \fIuser@domain\fR" +Write a message redirection request to the queue file, and +inspect the next input line. After the message is queued, +it will be sent to the specified address instead of the +intended recipient(s). +.sp +Note 1: this action overrides the \fBFILTER\fR action, and affects +all recipients of the message. If multiple \fBREDIRECT\fR actions +fire, only the last one is executed. +.sp +Note 2: a REDIRECT address is subject to canonicalization +(add missing domain) but NOT subject to canonical, masquerade, +bcc, or virtual alias mapping. +.sp +This feature is available in Postfix 2.1 and later. +.sp +This feature is not supported with smtp header/body checks. +.IP "\fBREPLACE \fItext...\fR" +Replace the current line with the specified text, and inspect the next +input line. +.sp +This feature is available in Postfix 2.2 and later. The +description below applies to Postfix 2.2.2 and later. +.sp +Notes: +.RS +.IP \(bu +When replacing a message header line, the replacement text +must begin with a valid header label. +.IP \(bu +The replaced text remains part of the input stream. Unlike +the result from the \fBPREPEND\fR action, a replaced message +header may be subject to address rewriting and may affect +the way that Postfix adds missing message headers. +.RE +.IP "\fBREJECT \fIoptional text...\fR +Reject the entire message. Do not inspect the remainder of +the input message. Reply with \fIoptional text...\fR when +the optional text is specified, otherwise reply with a +generic error message. +.sp +Note: this action disables further header or body_checks inspection +of the current message and affects all recipients. +.sp +Postfix version 2.3 and later support enhanced status codes. +When no code is specified at the beginning of \fIoptional +text...\fR, Postfix inserts a default enhanced status code of +"5.7.1". +.sp +This feature is not supported with smtp header/body checks. +.IP "\fBSTRIP \fIoptional text...\fR" +Log a "strip:" record with the \fIoptional text...\fR (or +log a generic text), delete the input line from the input, +and inspect the next input line. See \fBIGNORE\fR for a +silent alternative. +.sp +This feature is available in Postfix 3.2 and later. +.IP "\fBWARN \fIoptional text...\fR +Log a "warning:" record with the \fIoptional text...\fR (or +log a generic text), and inspect the next input line. This +action is useful for debugging and for testing a pattern +before applying more drastic actions. +.SH BUGS +.ad +.fi +Empty lines never match, because some map types mis\-behave +when given a zero\-length search string. This limitation may +be removed for regular expression tables in a future release. + +Many people overlook the main limitations of header and body_checks +rules. +.IP \(bu +These rules operate on one logical message header or one body +line at a time. A decision made for one line is not carried over +to the next line. +.IP \(bu +If text in the message body is encoded +(RFC 2045) then the rules need to be specified for the encoded +form. +.IP \(bu +Likewise, when message headers are encoded (RFC +2047) then the rules need to be specified for the encoded +form. +.PP +Message headers added by the \fBcleanup\fR(8) daemon itself +are excluded from inspection. Examples of such message headers +are \fBFrom:\fR, \fBTo:\fR, \fBMessage\-ID:\fR, \fBDate:\fR. + +Message headers deleted by the \fBcleanup\fR(8) daemon will +be examined before they are deleted. Examples are: \fBBcc:\fR, +\fBContent\-Length:\fR, \fBReturn\-Path:\fR. +.SH "CONFIGURATION PARAMETERS" +.na +.nf +.ad +.fi +.IP "\fBbody_checks (empty)\fR" +Optional lookup tables for content inspection as specified in +the \fBbody_checks\fR(5) manual page. +.IP "\fBbody_checks_size_limit (51200)\fR" +How much text in a message body segment (or attachment, if you +prefer to use that term) is subjected to body_checks inspection. +.IP "\fBheader_checks (empty)\fR" +Optional lookup tables for content inspection of primary non\-MIME +message headers, as specified in the \fBheader_checks\fR(5) manual page. +.IP "\fBmime_header_checks ($header_checks)\fR" +Optional lookup tables for content inspection of MIME related +message headers, as described in the \fBheader_checks\fR(5) manual page. +.IP "\fBnested_header_checks ($header_checks)\fR" +Optional lookup tables for content inspection of non\-MIME message +headers in attached messages, as described in the \fBheader_checks\fR(5) +manual page. +.IP "\fBdisable_mime_input_processing (no)\fR" +Turn off MIME processing while receiving mail. +.SH "EXAMPLES" +.na +.nf +.ad +.fi +Header pattern to block attachments with bad file name +extensions. For convenience, the PCRE /x flag is specified, +so that there is no need to collapse the pattern into a +single line of text. The purpose of the [[:xdigit:]] +sub\-expressions is to recognize Windows CLSID strings. + +.na +.nf +/etc/postfix/main.cf: + header_checks = pcre:/etc/postfix/header_checks.pcre + +/etc/postfix/header_checks.pcre: + /^Content\-(Disposition|Type).*name\es*=\es*"?([^;]*(\e.|=2E)( + ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe| + hlp|ht[at]| + inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws| + \e{[[:xdigit:]]{8}(?:\-[[:xdigit:]]{4}){3}\-[[:xdigit:]]{12}\e}| + ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf| + vb[esx]?|vxd|ws[cfh]))(\e?=)?"?\es*(;|$)/x + REJECT Attachment name "$2" may not end with ".$4" +.ad +.fi + +Body pattern to stop a specific HTML browser vulnerability exploit. + +.na +.nf +/etc/postfix/main.cf: + body_checks = regexp:/etc/postfix/body_checks + +/etc/postfix/body_checks: + /^