gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] packaging GNUnet for OpenWrt


From: Daniel Golle
Subject: Re: [GNUnet-developers] packaging GNUnet for OpenWrt
Date: Sun, 31 May 2015 16:51:07 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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

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). 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.


> 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)

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?


> > 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...

Maybe we'll have libcurl-{openssl,polarssl,cyassl,gnutls}-{mini,full},
but though I'm hoping for that, it's definitely not in the upper range
of my personal priories.

> Do you have a list of which dependencies are how costly (in terms of
> size)? That might provide a useful way of determining how to cut it down.

I'm about to figure that out, together with your hints below it should
be possible to come up with a sane packaging in relatively short time.


> > It'd be great if some of you can confirm that this is basically
> > working. I still had some trouble starting gnunet-arm as user
> > 'gnunet' which is what the init-script currently does.
> > When manually starting gnunet-arm -s as root, things seem to work
> > from what I can tell -- however, I don't know what I should
> > expect and you probably know better how well things should work
> > and general and how to operate the beast.
> 
> 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?

> 
> > 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.

> > - 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.

> > - 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.

> > - 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.

> 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).


> > - 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

> 
> > - 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...

> 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.


Cheers


Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]