summaryrefslogtreecommitdiffstats
path: root/debian/README.Debian
diff options
context:
space:
mode:
authorDavid Lamparter <equinox@diac24.net>2018-12-10 22:34:49 +0100
committerDavid Lamparter <equinox@diac24.net>2019-02-19 21:30:54 +0100
commitb3c4c164b5a6652deeddec41502f098846eb63d3 (patch)
treeff89587c87bee78f9d9281d4148905e678e78fb6 /debian/README.Debian
parentdebian: move changelog out of the way (diff)
downloadfrr-b3c4c164b5a6652deeddec41502f098846eb63d3.tar.xz
frr-b3c4c164b5a6652deeddec41502f098846eb63d3.zip
debian: make package "official"
Move us into place in debian/ Signed-off-by: David Lamparter <equinox@diac24.net>
Diffstat (limited to 'debian/README.Debian')
-rw-r--r--debian/README.Debian135
1 files changed, 135 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000000000..47a353310
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,135 @@
+* SAFETY MEASURES:
+==================
+
+Please consider setting this package "on hold" by typing
+ echo "frr hold" | dpkg --set-selections
+and verifying this using
+ dpkg --get-selections | grep 'hold$'
+
+Setting a package "on hold" means that it will not automatically be upgraded.
+Instead apt-get only displays a warning saying that a new version would be
+available forcing you to explicitly type "apt-get install frr" to upgrade it.
+
+
+* What is frr?
+=================
+
+http://www.frrouting.org/
+FRR is a routing software suite, providing implementations of OSPFv2,
+OSPFv3, RIP v1 and v2, RIPng, ISIS, PIM, BGP and LDP for Unix platforms, particularly
+FreeBSD and Linux and also NetBSD, to mention a few. FRR is a fork of Quagga
+which itself is a fork of Zebra.
+Zebra was developed by Kunihiro Ishiguro.
+
+
+* Build Profiles used in the upstream debian/
+=============================================
+
+The following Build Profiles have been added:
+
+- pkg.frr.nortrlib (pkg.frr.rtrlib)
+ controls whether the RPKI module is built.
+ Will be enabled by default at some point, adds some extra dependencies.
+
+- pkg.frr.nosnmp (pkg.frr.snmp)
+ controls whether the SNMP module is built, see below for license issues.
+ Will remain default-off as long as the license issue persists.
+
+- pkg.frr.nosystemd
+ Disables both systemd unit file installation as well as watchfrr sd_notify
+ support at startup. Removes libsystemd dependency.
+
+Note that all options have a "no" form; if you want to have your decision
+be sticky regardless of changes to what it defaults to, then always use one
+of the two. For example, all occurrences of <pkg.frr.rtrlib> will at some
+point be replaced with <!pkg.frr.nortrlib>.
+
+The main frr package has the exact same contents regardless of rtrlib or snmp
+choices. The options only control frr-snmp and frr-rpki-rtrlib packages.
+
+The main frr package does NOT have the same contents if pkg.frr.nosystemd is
+used. This option should only be used for systems that do not have systemd,
+e.g. Ubuntu 14.04.
+
+
+* Why has SNMP support been disabled?
+=====================================
+FRR used to link against the NetSNMP libraries to provide SNMP
+support. Those libraries sadly link against the OpenSSL libraries
+to provide crypto support for SNMPv3 among others.
+OpenSSL now is not compatible with the GNU GENERAL PUBLIC LICENSE (GPL)
+licence that FRR is distributed under. For more explanation read:
+ http://www.gnome.org/~markmc/openssl-and-the-gpl.html
+ http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
+Updating the licence to explecitly allow linking against OpenSSL
+would requite the affirmation of all people that ever contributed
+a significant part to Zebra / Quagga or FRR and thus are the collective
+"copyright holder". That's too much work. Using a shrinked down
+version of NetSNMP without OpenSSL or convincing the NetSNMP people
+to change to GnuTLS are maybe good solutions but not reachable
+during the last days before the Sarge release :-(
+
+ *BUT*
+
+It is allowed by the used licence mix that you fetch the sources and
+build FRR yourself with SNMP with
+ # apt-get -b source -Ppkg.frr.snmp frr
+Just distributing it in binary form, linked against OpenSSL, is forbidden.
+
+
+* Debian Policy compliance notes
+================================
+
+- 4.15 Reproducibility
+ FRR build is reproducible as outlined in version 4.2.1 of the Policy, but
+ won't be reproducible when the build directory is varied. This is because
+ configure parameters are burned into the executables which includes CFLAGS
+ like -fdebug-prefix-map=/build/directory/...
+
+
+* Daemon selection:
+===================
+
+The Debian package uses /etc/frr/daemons to tell the
+initscript which daemons to start. It's in the format
+<daemon>=<yes|no|priority>
+with no spaces (it's simply source-d into the initscript).
+Default is not to start anything, since it can hose your
+system's routing table if not set up properly.
+
+Priorities were suggested by Dancer <dancer@zeor.simegen.com>.
+They're used to start the FRR daemons in more than one step
+(for example start one or two at network initialization and the
+rest later). The number of FRR daemons being small, priorities
+must be between 1 and 9, inclusive (or the initscript has to be
+changed). /etc/init.d/frr then can be started as
+
+/etc/init.d/frr <start|stop|restart|<priority>>
+
+where priority 0 is the same as 'stop', priority 10 or 'start'
+means 'start all'
+
+
+* Error message "privs_init: initial cap_set_proc failed":
+==========================================================
+
+This error message means that "capability support" has to be built
+into the kernel.
+
+
+* Error message "netlink-listen: overrun: No buffer space available":
+=====================================================================
+
+If this message occurs the receive buffer should be increased by adding the
+following to /etc/sysctl.conf and "--nl-bufsize" to /etc/frr/daemons.
+> net.core.rmem_default = 262144
+> net.core.rmem_max = 262144
+See message #4525 from 2005-05-09 in the quagga-users mailing list.
+
+
+* vtysh immediately exists:
+===========================
+
+Check /etc/pam.d/frr, it probably denies access to your user. The passwords
+configured in /etc/frr/frr.conf are only for telnet access.
+