Allow native distribution packages to run with their default user
and group names by no longer forcing "-u root -g root" on any of
the Quagga daemons' command lines.
This should continue to allow hand-compiled and/or "side-loaded"
Quagga software to run as root, if configured to do so at build
time.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
Since all Quagga daemons are configured from a consolidated
location (the 'zebra' service), there is nothing left to do
for a dedicated service such as 'vtysh'. This patch removes
the service, along with all references to it from the rest
of the source tree (sample *.imn files, examples, etc.)
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
Currently, all Quagga daemons are started concurrently by their
respective CORE services, using "quaggaboot.sh" generated by the
'zebra' service. However, all routing services depend on 'zebra'
already running, and 'vtysh' depends on ALL other Quagga services
before it can push configuration from the common "Quagga.conf" to
all running daemons (see "waitforvtyfiles()" in "quaggaboot.sh").
The spinwait+timeout based implementation of "waitforvtyfiles()"
may, depending on load, give up too early and fail to configure
all Quagga daemons.
This patch streamlines the way Quagga daemons are started, by
launching them all from the 'zebra' service. The correct sequence
is to first launch the 'zebra' daemon itself, then proceed with
all routing daemons, and finish with a call to "vtysh -b" which
configures all running daemons.
The list of all applicable daemons to launch is obtained using
'grep' from Quagga.conf, in the same way "waitforvtyfiles()" used
to discover which *.vty files to look for in /var/run/quagga/.
The startup command for all services other than 'zebra' becomes
empty, and "quaggaboot.sh" issues a warning on attempts to have
it launch any other daemon.
Signed-off-by: Gabriel Somlo <glsomlo@cert.org>
When enabled, the startup service ensures that other node services
start in order (according to the service _startindex value) and that
the prior service completes before the next service starts. It also
captures any output from startup commands in a file named
'startup.log'.
