Re: [GNUnet-developers] packaging GNUnet for OpenWrt

[Christian Grothoff]

On 05/31/2015 04:51 PM, Daniel Golle wrote:
> Hi Christian!
> 
> On Sun, May 31, 2015 at 03:31:52PM +0200, Christian Grothoff wrote:
>> On 05/31/2015 02:57 PM, Daniel Golle wrote:
>>> I also wonder whether using gnunet-arm is really what I want, given
>>> that we got procd to pretty much do the same job.
>>
>> In theory you can replace 'gnunet-arm' with anything else that provides
>> systemd-like functionality, at the expense of having to document a
>> system-specific way to configure things (as the PORT/UNIXPATH
>> configurations from the GNUnet-configuration would have to be mapped 1:1
>> to the procd syntax, maybe with some conversion script?).
>>
>> Still, while ARM is really tiny, for an embedded system where a few KB
>> of RAM/ROM can matter, this might be worth the effort.
> 
> Yes, that's not a top-priority, I just want to make sure I got things
> right..
> By now the main difficulty I got is that I'd want a way to start
> gnunet-arm in foreground, so it can be monitored by procd (or other
> init system) and most important: it would also allow to kill and
> restart stuff reliably. See
> https://gnunet.org/bugs/view.php?id=3804

Oh, but then just start 'gnunet-service-arm' directly.  gnunet-arm -s
just starts gnunet-service-arm in the background, so if you want it in
the foreground, it is totally fine to just directly run the service (you
can still use gnunet-arm -e to stop it).

> Another issue is that most services started by gnunet-arm should be
> run as uid:gid set to gnunet:gnunet or gnunet:gnunetdns. Some will
> require root proviledges at least at some point (e.g. gnunet-vpn, see
> below).

gnunet-service-arm should be started as user 'gnunet:gnunet'. Those
parts that require root should be installed SUID (like the helpers),
and gnunet-service-dns should be SGID (and group 'gnunetdns').

> As that's a quite common problem for many network services,
> OpenWrt recently started to implement seccomp to allow certain
> processes to be run as root but only enjoy some-but-not-all
> priviledges.

Sure, but even that is too much for GNUnet. We can do with less, as long
as the helpers can be SUID.

>> libgnurl is our attempt to remove the crud from libcurl, did you
>> actually 'configure' it with the right options? (So only using GnuTLS
>> and not any protocols other than http/https?)
> 
> I also had to move the headers from /usr/include/curl to
> /usr/include/gnurl so existing files left there by actual curl won't
> get overwritten (and even if they are identical, that would definitely
> offend people)

Sure.

> See
> https://github.com/openwrt/packages/blob/master/net/gnurl/Makefile#L51
> 
> Anything more to add there?
> Seems like many protocols (e.g. SMTP) can't really be disabled or maybe
> I just didn't figure out how that works. Any hints?

Yes, you don't have all the flags.  The Gnurl README says to use:

./configure --enable-ipv6 --with-gnutls --without-libssh2
--without-libmetalink
--without-winidn --without-librtmp --without-nghttp2 --without-nss
--without-cyassl
--without-polarssl --without-ssl --without-winssl --without-darwinssl
--disable-sspi --disable-ntlm-wb --disable-ldap --disable-rtsp
--disable-dict
--disable-telnet --disable-tftp --disable-pop3 --disable-imap
--disable-smtp
--disable-gopher --disable-file --disable-ftp --disable-smb

>>> However, to have a clean
>>> state to start-off from, I also packaged gnurl (but would like to get
>>> rid of it, the sooner the better). We also don't have a good solution
>>> to build curl and libcurl in several variants with different SSL
>>> implementations -- this was easy to do for other packages, but seems
>>> to be harder for curl. So gnurl it is for now.
>>
>> If one of your curl packages is guaranteed to use libgnutls and you're
>> short on space, you *can* re-use that package safely.  On an embedded
>> system that has libcurl already, this would make sense to me.
> 
> Hopefully, we'll one day have libcurl-{openssl,polarssl,cyassl,gnutls}
> packages. Unfortunately, the problem is multi-dimensional because of
> all the protocols which could be supported or not, which makes you
> end up with t * 2^n different packages.
> (t:=number of TLS implementations, n:=number of optional protocols)
> This is hard to imagine and I couldn't even come up with a sane
> naming scheme for that...

Well, my frustration with this was the birth of gnurl, so I feel your pain.

>> Well, running as 'root' generally works, but of course given that we do
>> not need root, is really a bad idea from a security perspective. Also,
>> in that case the DNS interception for GNS will *not* work for the user
>> 'root' himself, which may be problematic. If you run as user 'gnunet',
>> DNS interception will not be effective for the user 'gnunet', which is
>> typically what you want/need (so that gnunet-service-dns can forward DNS
>> queries to DNS and GNS queries to GNS).
> 
> What about VPN when starting gnunet-arm as user 'gnunet'. Doesn't that
> require root priviledges at least to setup the TUN device?

Yes, but if you run GNUnet configure '--with-sudo' or as root, it should
install certain gnunet-helper binaries SUID (or SGID), so that they can
get those privs just for as long as they need them.  That's the
recommended method, way better than running 'everything' as root.

>>
>>> The next high-priority item is to split up the package into a bunch
>>> of small packages, e.g.:
>>> - libgnunet
>>
>> Not sure there is utility in just having the libs.
> Sure, nobody would select only libgnunet. But probably most/all other
> packages will depend on it, including third-party-supplied stuff.

I'm not sure why they should not directly depend on 'gnunet-core' --
having the libs without the ability to run the peer is at best odd.

>>> - gnunet-core
> I thought of /usr/share/* as well as stuff like gnunet-arm in here.
> But right, the common libraries can go there as well.

And foundational services (transport, core, ats, dht, cadet, statistics,
nse, set, block plugins, hostlist, identity, topology,
peerinfo/peerstore, nat -- that'd be the list of the top of my head).

>>> - gnunet-utils
>> Not sure what 'utils' would naturally include.
> e.g. gnunet-config or other things which may be needed for on-target
> administration but not during everyday run-time.

Ok, makes sense to put certain 'rarely used' command-line binaries
there. Sure.

>>> - gnunet-testing
>>
>> Plenty here, makes definitively sense to keep apart.
> 
> 
>>
>>> - gnunet-app-gns
>>> - gnunet-app-filesharing
>>
>> For filesharing, you might have two versions:
>> - gnunet-app-filesharing
>> - gnunet-app-filesharing-extractor-plugins
> 
> I thought that (similar to other complex packages) we might want quite
> atomic packages and then have empty meta-packages depending on sets of
> these small atomic packages commonly needed for a certain use-case.
> gnunet-app-filesharing and gnunet-app-gns by themselves would not
> contain any files, but depend on e.g. gnunet-mod-namestore, ... and
> maybe gnunet-app-filesharing would also depend on a subset of the
> libextractor plugins.

Well, if you want to truly atomize the system, look at doc/structure.dot
to find a good approximation of the dependency graph.  But you'll end up
with 50+ packages, not sure how wise that is.

>> The 2nd one would drag in the LE plugins (and their dependencies!),
>> while the first one would just ship with an empty
>> PREFIX/lib/libextractor/* directory.  As users are unlikely to run
>> 'gnunet-publish' on the OpenWRT to publish files locally anyway, that
>> would remove a lot of unnecessary crud.
> 
> OpenWrt (despite it's history) is a general purpose embedded distribution.
> I run it on NAS-boxes, Web-Server-VMs, my mpd-based jukebox, ...
> So think of everything ranging from routers to large servers. I guess
> what most of these things got in common is that lack of classic human
> input (keyboard, mouse) and output (video).

Ok, well, still makes sense to make the LE plugins a separate package.

>>> - gnunet-app-conversation
>>
>> Here a split between the service and the user-tools might make sense.
>> If the OpenWRT doesn't have a speaker and a microphone, it doesn't make
>> sense to drag in opus and pulseaudio.  So you could run the conversation
>> service and allow the user to connect to it from a TCP port, running the
>> command-line/GUI on the desktop.  That'd remove Opus and PA dependencies
>> from the OpenWRT.
> 
> OpenWrt does support quite a lot of audio stuff, either via PCM/I2S or 
> built-in
> codecs like on several Allwinner sunxi targets, or by attaching Audio I/O
> via USB.
> Think: NAS + USB-Audio = Juke-Box
> Router + Audio = Phone

Ok, I stand corrected -- again maybe some separate package for the
Phone-WRTs would then make sense ;-).

>>
>>> - gnunet-app-vpn
>>
>> There's also what you might consider the 'experimental' group:
> 
> A petty. I was hoping to use the VPN feature, which sounds very
> promissing for OpenWrt...

Yes, that made total sense to me, my comment about 'experimental' was
not about the 'vpn' package.

>> psyc, multicast, social, ATS plugins (especially the one needing glpk),
>> scalarproduct, rps, sensor* rest, env, dv, consensus: none of these are
>> useful for end-user applications today, so there is really no point in
>> installing them today on an embeded system, for anything but
>> development.  In the future, some might become part of 'core' or a new
>> package ("social"), but for now it's safe to just leave those separate
>> and generally not install them.
> 
> Ok, that makes things easier, at least :)
> 
>> I've put comments on those that are more or less useless for
>> OpenWRT/embedded systems inline.
> 
> Thanks you! I'll go through that and explore linking and run-time
> behaviour to complete the picture.

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature