From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0B3E4201B02 for ; Wed, 22 Jan 2014 10:45:52 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i7so923712oag.36 for ; Wed, 22 Jan 2014 10:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QRB+uiYNOJHolriwya8F2hISoC6OgY79TYqTtLSRf7k=; b=j/AQCv5aMvhrJrC1tMZetJjq2wsK9qmc+GoLanj4qfwEPNtXW713kydr0aS6XTsJ2+ HnCZ62HfQoaWXckp98CSfMEhVgguukqfdU6SnaULTSs2JwWvTkyFArV7TZjX9q7FhBQm ucEruPkqux5H64nD20MsrQ6s1StSYgN7JB1ImGm3gn1VsCmXbqN//gUE8+as6jO8qF84 cMU8bYKCEzKHANILlOhGyMRv99SI6UF/r/Ss14kMSctLZDKKUksgHiLYvLgU3UQNHVEa Av2aT41JrO0/kNU2QuLQnV6/MoCilQkkAb1AlnfgghEVkL7rBv2Ukn6sdB8ix0Ps4sfV D7QQ== X-Received: by 10.182.29.66 with SMTP id i2mr2689185obh.23.1390416351894; Wed, 22 Jan 2014 10:45:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.194 with HTTP; Wed, 22 Jan 2014 10:45:30 -0800 (PST) In-Reply-To: References: From: David Personette Date: Wed, 22 Jan 2014 13:45:30 -0500 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a11c2bbdcbea52104f093889b Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] procd support for core daemons? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 18:45:53 -0000 --001a11c2bbdcbea52104f093889b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It sounds like a good project, I'll look into it this weekend. --=20 David P. On Wed, Jan 22, 2014 at 1:08 AM, Dave Taht 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 weigh= t, > 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 mad= e > 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 kin= d > of like it existing independently of procd. That said, I'd like closer ti= es > 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 instanc= es > 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 di= e > when > unneeded). would like to run one daemon with non-root privs talking to fc= gi > 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=C3=A4ht > > 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 > --001a11c2bbdcbea52104f093889b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds like a good project, I'll look into it this = weekend.

-- =
David P.



On Wed, Jan 22, 2014 at 1:08 AM, Dav= e 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 migr= ated
away from init towards things like systemd (which provide kitchen sink serv= ices)

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

htt= p://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.

=C2=A0A 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<= br> more so, if wrapped by procd. Converting an existing init script in /etc/in= it.d
is pretty easy if you look at the code already done there, and how dependen= cies
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 =C2=A0grip on how uci works
is very helpful for scripting tests and the like, and getting a working pac= kage
is only a bit more work. (and the work can quickly go upstream to openwrt)<= br>
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<= br> 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.<= br>
someday procd will gain xinetd-like functionality.

lighthttpd: cero runs two instances of the lighttpd web server. One is outw= ard
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 on= ly
path into the router would be by ssh secure key. Since it isn't, it wou= ld
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= 9;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<= br> 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=C3=A4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--001a11c2bbdcbea52104f093889b--