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 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
