Re: Looking for an advice on file location in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/20/19 2:06 PM, Neal Gompa wrote:
On Wed, Mar 20, 2019 at 9:00 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
On Wed, Mar 20, 2019 at 10:44:53AM +0100, Michal Ruprich wrote:
Hi,

I am preparing FRR so that it could be added to Fedora and since there
are a lot of experienced packagers here, I would like to ask for an
advice. FRR is a fork of quagga and it provides a couple of routing
daemons(bgp, isis, odpf, rip, eigrp etc.). Originally in quagga, each
daemon had its own binary in /usr/sbin and each daemon could be started
via systemctl(including the zebra daemon which is needed to run other
routing daemons). In FRR the developers have chosen a different
approach. They provide a script that takes care of the start-up of all
requested daemons - that means that all daemons are started via a single
systemctl command.
That doesn't sound like a good idea. It seems that they reimplement
daemon management internally, which usually doesn't go well.

I've experienced this from a number of other projects. This is a
seriously bad idea. Have you asked the FRR developers why they feel
they can't use the service management facilities of systemd
effectively?

Yes I have, this is their answer:

  • We see it as “one package”, not as a collection of multiple packages.
    Ie. Postgresql runs multiple processes, but has 1 startup service/script
    Similar, we wanted one master init/systemd script to start all daemons.

  • Systemd is kind of braindead on monitoring and restarting daemons.
    Things we need, but could not get done with systemd:
    1) Our desire is to move to one config file (frr.conf) instead of
    one per daemon in the near future and in such a config, the startup
    script needs to reload the configs with vtysh after the daemons are
    started. This is (not yet) the default for the main distro, but
    the agreed on future.
    2) watchfrr (or on Quagga: watchquagga) is much better in monitoring
    the daemons than systemd. It has hooks into the daemons to check
    if they are actually responding (and not just “running”) and trigger
    restarts as needed. Watchfrr also does watchdog timers back to systemd
    3) The order of the startup matters in some cases (i.e. with integrated
    config where we load config at the end)
    4) There is a reload command which can do a non-intrusive reload without
    restarting any daemons and do a differential config apply.
    5) Many distro’s don’t like systemd and we figured that maintaining one
    (complex) init script is easier than multiple scripts. (I’m still
    tasked to somehow combine the debian and red hat init scripts into
    one single one if somehow possible, but didn’t get around it.


      
There are a couple of other scripts that are used for
reloading the daemons etc. I am now wondering about where to place all
relevant binary files and all the scripts.
Do the daemons have names that are unique enough to not cause conflicts
with other packages? If yes, then it should be OK to put them all in
/usr/bin/. (There's no reason to care about "sbin" vs "bin", since nowadays
both are included in $PATH.)

The upstream idea about the location is to put all binary files and all
the scripts to /usr/lib/frr/ which does not make much sense to me.
It is actually a pretty good choice, except that you say that those
executables are supposed to be called by the users directly. If they
weren't, or if were only rarely, this upstream decision would be
appropriate. In particular, there's no effective difference between
/usr/libexec and /usr/lib/ffr, so using /usr/lib/ffr would be correct.

If you're going to stuff binaries in a non-PATH place,
/usr/libexec/frr (I assume FRR is the project name, and not FFR) is
where it should go, full stop.

My
first idea was to keep the main script in /usr/sbin and put the rest to
/usr/libexec, but that would only make sense if the binaries and scripts
were not meant to be run by the user, which is not the case. It is very
well possible to start each daemon directly without interfering with
systemd or any of the scripts. Same applies for each of the script.

So the question is whether it is acceptable to keep the scripts in the
/usr/sbin directory together with the binaries or whether I should put
them somewhere else?

I would be grateful for any ideas about this. Thanks.

      
In general, this project seems like it needs some help understanding
how services should work.




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
-- 
Michal Ruprich
Software Engineer

Email: mruprich@xxxxxxxxxx
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux