[Cerowrt-devel] procd support for core daemons?

[Cerowrt-devel] procd support for core daemons?

[Dave Taht]

this is not a list of "must haves" but a "would likes".

Earlier this year, openwrt started working on a replacement for the first
process in the system, the "init" process. Most distros have migrated
away from init towards things like systemd (which provide kitchen sink services)

Openwrt went in another direction for something simpler and lighter weight,
called "procd".

http://wiki.openwrt.org/doc/techref/procd

Documentation on it is pretty sparse, the best way to learn how to use
it is to grep USE_PROCD /etc/init.d/* and read those files.

 A huge disadvantage
of old init system is once a daemon dies, it stays dead until a human
restarts it. If that daemon is critical you are hosed.

The principal advantages of procd are that it can restart a process
after it crashes, and that it integrates with other messages sent
along the ubus so that multiple restarts can be suppressed as
various network things get configured.

There are a ton of daemons in cero that while pretty reliable, can be made
more so, if wrapped by procd. Converting an existing init script in /etc/init.d
is pretty easy if you look at the code already done there, and how dependencies
work in /etc/config/ucitrack .

And: that ton of daemons in cero has not been converted to procd yet.
Doing a couple of these would be a good project(s) for someone(s) as
the conversion can be done directly on the router, and tested, no need
for a toolchain. Getting  grip on how uci works
is very helpful for scripting tests and the like, and getting a working package
is only a bit more work. (and the work can quickly go upstream to openwrt)

the core non-procd daemons in cero currently are

dbus: I don't even know if this needed anymore (?)

babeld: of all these, when babeld crashes it's most bad, the router
drops off the mesh. Right now the yurtlab is down... However converting
it to procd looks kind of involved, so I pinged the babel list if they
were interested

xinetd: if xinetd crashes it's very bad, things like ssh stop working. However
in practice xinetd has been very mature code and has never crashed. I kind
of like it existing independently of procd. That said, I'd like closer ties
with things like dhcpv6-pd so that ipv6 permissions get added and deleted.

someday procd will gain xinetd-like functionality.

lighthttpd: cero runs two instances of the lighttpd web server. One is outward
facing, drops root permissions, and the other is for configuration,
and keeps root.

If it were up to me, these would be disabled after installation, and the only
path into the router would be by ssh secure key. Since it isn't, it would
be nice to keep them running no matter what. Getting two separate instances
started would be a matter of some uci syntax in /etc/config/lighttpd, but
doing the full lighthttpd.conf file format in uci an exercise in pain.

I'd like it if there was some way to to have it start from xinetd (and die when
unneeded). would like to run one daemon with non-root privs talking to fcgi
with root privs, too. can't have everything.

polipo: if nobody but me is using polipo, we can disable it by default, but it
too would be nice to be more network aware and use procd.

ahcpd: this has been a pita generally. I don't know what to do about
it. Of all these, this needs the most love to work right in our
dynamic ipv6 universe.

rngd: the random number daemon. It used to be that if this crashed,
ssh connections and wpa wifi came to a near halt. It's unknown if it's
still needed after all the random number
fixes that went into the kernel...

I just moved rngd to procd. (I'd like it if folk running wpa and heavy
crypto stopped rngd for a day to see what happened)

pimd - this too, I just moved to procd. not that we think it's working.

snmpd: looks easy

minissdpd: looks easy but we have other problems with it
miniupnpd: looks easy
avahi: looks easy

There are several other optional daemons like ipsec, samba, & openvpn
that could use
a procd treatment.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] procd support for core daemons?

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

It sounds like a good project, I'll look into it this weekend.

-- 
David P.



On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht <dave.taht@gmail.com> wrote:

> this is not a list of "must haves" but a "would likes".
>
> Earlier this year, openwrt started working on a replacement for the first
> process in the system, the "init" process. Most distros have migrated
> away from init towards things like systemd (which provide kitchen sink
> services)
>
> Openwrt went in another direction for something simpler and lighter weight,
> called "procd".
>
> http://wiki.openwrt.org/doc/techref/procd
>
> Documentation on it is pretty sparse, the best way to learn how to use
> it is to grep USE_PROCD /etc/init.d/* and read those files.
>
>  A huge disadvantage
> of old init system is once a daemon dies, it stays dead until a human
> restarts it. If that daemon is critical you are hosed.
>
> The principal advantages of procd are that it can restart a process
> after it crashes, and that it integrates with other messages sent
> along the ubus so that multiple restarts can be suppressed as
> various network things get configured.
>
> There are a ton of daemons in cero that while pretty reliable, can be made
> more so, if wrapped by procd. Converting an existing init script in
> /etc/init.d
> is pretty easy if you look at the code already done there, and how
> dependencies
> work in /etc/config/ucitrack .
>
> And: that ton of daemons in cero has not been converted to procd yet.
> Doing a couple of these would be a good project(s) for someone(s) as
> the conversion can be done directly on the router, and tested, no need
> for a toolchain. Getting  grip on how uci works
> is very helpful for scripting tests and the like, and getting a working
> package
> is only a bit more work. (and the work can quickly go upstream to openwrt)
>
> the core non-procd daemons in cero currently are
>
> dbus: I don't even know if this needed anymore (?)
>
> babeld: of all these, when babeld crashes it's most bad, the router
> drops off the mesh. Right now the yurtlab is down... However converting
> it to procd looks kind of involved, so I pinged the babel list if they
> were interested
>
> xinetd: if xinetd crashes it's very bad, things like ssh stop working.
> However
> in practice xinetd has been very mature code and has never crashed. I kind
> of like it existing independently of procd. That said, I'd like closer ties
> with things like dhcpv6-pd so that ipv6 permissions get added and deleted.
>
> someday procd will gain xinetd-like functionality.
>
> lighthttpd: cero runs two instances of the lighttpd web server. One is
> outward
> facing, drops root permissions, and the other is for configuration,
> and keeps root.
>
> If it were up to me, these would be disabled after installation, and the
> only
> path into the router would be by ssh secure key. Since it isn't, it would
> be nice to keep them running no matter what. Getting two separate instances
> started would be a matter of some uci syntax in /etc/config/lighttpd, but
> doing the full lighthttpd.conf file format in uci an exercise in pain.
>
> I'd like it if there was some way to to have it start from xinetd (and die
> when
> unneeded). would like to run one daemon with non-root privs talking to fcgi
> with root privs, too. can't have everything.
>
> polipo: if nobody but me is using polipo, we can disable it by default,
> but it
> too would be nice to be more network aware and use procd.
>
> ahcpd: this has been a pita generally. I don't know what to do about
> it. Of all these, this needs the most love to work right in our
> dynamic ipv6 universe.
>
> rngd: the random number daemon. It used to be that if this crashed,
> ssh connections and wpa wifi came to a near halt. It's unknown if it's
> still needed after all the random number
> fixes that went into the kernel...
>
> I just moved rngd to procd. (I'd like it if folk running wpa and heavy
> crypto stopped rngd for a day to see what happened)
>
> pimd - this too, I just moved to procd. not that we think it's working.
>
> snmpd: looks easy
>
> minissdpd: looks easy but we have other problems with it
> miniupnpd: looks easy
> avahi: looks easy
>
> There are several other optional daemons like ipsec, samba, & openvpn
> that could use
> a procd treatment.
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 5689 bytes --]

Re: [Cerowrt-devel] procd support for core daemons?

[Dave Taht]

I moved pimd, ahcpd, polipo, avahi-daemon, rngd, and the cerowrt and
luci configuration web servers into being managed by procd. (The
lighttpd/cerowrt fix actually fixed a longstanding bug in restarting
those competing webservers.)

Left to convert are babeld (which was the only one of the above I
really cared about, sadly. I am bogged down on understanding the
uci_validate routine).

The trival changes required to those init scripts (not warranted to be
correct at this point) are at:
http://snapon.lab.bufferbloat.net/~cero2/procd/

could use eyeballs on all that(?).

The WIP on converting babel is there also. (I found it necessary to
patch babel to run without a pid file, not that I'm right...)

I didn't touch minissd or upnp 'cause I don't know enough about them
to be able to test. (and I understand that they are busted
for some people, and that I/we need to fix that first. and I just
nabbed a playstation to observe)

I don't plan to convert xinetd.

Didn't get around to converting snmpd.

That's it for "core daemons". (a fingering change is generally you
want to do a /etc/init.d/whatever reload rather than
restart)

of the other commonly installed ones, there are samba, openwrt,
strongswan and ipsec, that I know of. All these are packages that
haven't been installed or tested for a while (by me, anyway)...

I am travelling back to california tomorrow and don't plan an actual
build until next weekend.



On Wed, Jan 22, 2014 at 1:45 PM, David Personette <dperson@gmail.com> wrote:
> It sounds like a good project, I'll look into it this weekend.

I left you the hard bits. :( - nearly all the above are checked into
ceropackages-3.3 and cerofiles-next.

>
> --
> David P.
>
>
>
> On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> this is not a list of "must haves" but a "would likes".
>>
>> Earlier this year, openwrt started working on a replacement for the first
>> process in the system, the "init" process. Most distros have migrated
>> away from init towards things like systemd (which provide kitchen sink
>> services)
>>
>> Openwrt went in another direction for something simpler and lighter
>> weight,
>> called "procd".
>>
>> http://wiki.openwrt.org/doc/techref/procd
>>
>> Documentation on it is pretty sparse, the best way to learn how to use
>> it is to grep USE_PROCD /etc/init.d/* and read those files.
>>
>>  A huge disadvantage
>> of old init system is once a daemon dies, it stays dead until a human
>> restarts it. If that daemon is critical you are hosed.
>>
>> The principal advantages of procd are that it can restart a process
>> after it crashes, and that it integrates with other messages sent
>> along the ubus so that multiple restarts can be suppressed as
>> various network things get configured.
>>
>> There are a ton of daemons in cero that while pretty reliable, can be made
>> more so, if wrapped by procd. Converting an existing init script in
>> /etc/init.d
>> is pretty easy if you look at the code already done there, and how
>> dependencies
>> work in /etc/config/ucitrack .
>>
>> And: that ton of daemons in cero has not been converted to procd yet.
>> Doing a couple of these would be a good project(s) for someone(s) as
>> the conversion can be done directly on the router, and tested, no need
>> for a toolchain. Getting  grip on how uci works
>> is very helpful for scripting tests and the like, and getting a working
>> package
>> is only a bit more work. (and the work can quickly go upstream to openwrt)
>>
>> the core non-procd daemons in cero currently are
>>
>> dbus: I don't even know if this needed anymore (?)
>>
>> babeld: of all these, when babeld crashes it's most bad, the router
>> drops off the mesh. Right now the yurtlab is down... However converting
>> it to procd looks kind of involved, so I pinged the babel list if they
>> were interested
>>
>> xinetd: if xinetd crashes it's very bad, things like ssh stop working.
>> However
>> in practice xinetd has been very mature code and has never crashed. I kind
>> of like it existing independently of procd. That said, I'd like closer
>> ties
>> with things like dhcpv6-pd so that ipv6 permissions get added and deleted.
>>
>> someday procd will gain xinetd-like functionality.
>>
>> lighthttpd: cero runs two instances of the lighttpd web server. One is
>> outward
>> facing, drops root permissions, and the other is for configuration,
>> and keeps root.
>>
>> If it were up to me, these would be disabled after installation, and the
>> only
>> path into the router would be by ssh secure key. Since it isn't, it would
>> be nice to keep them running no matter what. Getting two separate
>> instances
>> started would be a matter of some uci syntax in /etc/config/lighttpd, but
>> doing the full lighthttpd.conf file format in uci an exercise in pain.
>>
>> I'd like it if there was some way to to have it start from xinetd (and die
>> when
>> unneeded). would like to run one daemon with non-root privs talking to
>> fcgi
>> with root privs, too. can't have everything.
>>
>> polipo: if nobody but me is using polipo, we can disable it by default,
>> but it
>> too would be nice to be more network aware and use procd.
>>
>> ahcpd: this has been a pita generally. I don't know what to do about
>> it. Of all these, this needs the most love to work right in our
>> dynamic ipv6 universe.
>>
>> rngd: the random number daemon. It used to be that if this crashed,
>> ssh connections and wpa wifi came to a near halt. It's unknown if it's
>> still needed after all the random number
>> fixes that went into the kernel...
>>
>> I just moved rngd to procd. (I'd like it if folk running wpa and heavy
>> crypto stopped rngd for a day to see what happened)
>>
>> pimd - this too, I just moved to procd. not that we think it's working.
>>
>> snmpd: looks easy
>>
>> minissdpd: looks easy but we have other problems with it
>> miniupnpd: looks easy
>> avahi: looks easy
>>
>> There are several other optional daemons like ipsec, samba, & openvpn
>> that could use
>> a procd treatment.
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] procd support for core daemons?

[Toke Høiland-Jørgensen]

> Left to convert are babeld (which was the only one of the above I
> really cared about, sadly. I am bogged down on understanding the
> uci_validate routine).

I mostly care about babeld and tincd. Will look into those when I get a chance, unless you beat me to it...

> >> http://wiki.openwrt.org/doc/techref/procd

That page is useless...

-Toke

Re: [Cerowrt-devel] procd support for core daemons?

[Dave Taht]

On Sat, Jan 25, 2014 at 11:43 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Left to convert are babeld (which was the only one of the above I
>> really cared about, sadly. I am bogged down on understanding the
>> uci_validate routine).
>
> I mostly care about babeld and tincd. Will look into those when I get a chance, unless you beat me to it...

Well, when I get back to california I have ipv6 capability again so
I'll add tincd to my testlist of the
vpn technologies that may be problematic with source/dst routing...

but I'm done through monday at least. gotta pack.

>> >> http://wiki.openwrt.org/doc/techref/procd
>
> That page is useless...

like all wikis it can be improved.

I left a bunch of documentation behind in the babeld attempt on how
the validator theoretically works.

>
> -Toke
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] procd support for core daemons?

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> Well, when I get back to california I have ipv6 capability again so
> I'll add tincd to my testlist of the vpn technologies that may be
> problematic with source/dst routing...

Right. Pretty sure it doesn't work if you use the built-in routing
stuff. I just run it in layer2 switch mode, though, and run babeld on
top of that. Haven't gotten around to upgrading to the source routing
version yet, though...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] procd support for core daemons?

[Dave Taht]

On Sat, Jan 25, 2014 at 12:06 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> Well, when I get back to california I have ipv6 capability again so
>> I'll add tincd to my testlist of the vpn technologies that may be
>> problematic with source/dst routing...
>
> Right. Pretty sure it doesn't work if you use the built-in routing
> stuff. I just run it in layer2 switch mode, though, and run babeld on
> top of that. Haven't gotten around to upgrading to the source routing
> version yet, though...

I note that this is the babels branch of babel, not the babel-rtt branch,
which has implications for your routing metrics.

>
> -Toke



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] procd support for core daemons?

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

>
> of the other commonly installed ones, there are samba, openwrt,
> strongswan and ipsec, that I know of. All these are packages that
> haven't been installed or tested for a while (by me, anyway)...
>

I have strongswan running on my 3800 with v3.10.24-8.  I've found some
interesting results comparing it against another platform I have.  I may
(or may not) have found some bufferbloat-ish behavior in IPSec (where it
forms a bottleneck doing the encryption/decryption).  More on that when I
get clearer results.

-Aaron

[-- Attachment #2: Type: text/html, Size: 788 bytes --]