Re: s6, listen(8), etc.

[Daniel Kahn Gillmor]

On Mon 2016-09-05 02:48:54 -0400, Jonathan de Boyne Pollard wrote:
> Daniel Kahn Gillmor:
>
>>  #!/bin/sh
>>  mkdir -p /run/kresd/workdir && \
>>  setfacl -m u:kresd:rwx /run/kresd/workdir && \
>>  cd /run/kresd/workdir && \
>>  exec listen -udp::53 \
>>  -tcp::53 \
>>  -tcp:label=tls:853 \
>>  -unix:label=control,mode=0600:/run/kresd/control \
>>  chpst -u kresd -p 1 \
>>  /usr/sbin/kresd
>
> start:
>
>  #!/bin/sh -e
>  install -d -m 0755 -o kresd /run/kresd/workdir
>
> stop:
>
>  #!/bin/sh -e
>  rm -r /run/kresd/
>
> run:
>
>  #!/bin/nosh
>  udp-socket-listen --systemd-compatibility --combine4and6 :: domain
>  tcp-socket-listen --systemd-compatibility --combine4and6 --backlog 2 
> :: domain
>  local-datagram-socket-listen --systemd-compatibility --mode 0666 
> /run/kresd/query.socket
>  local-stream-socket-listen --systemd-compatibility --mode 0600 
> /run/kresd/control
>   ./service
>
> service:
>
>  #!/bin/nosh
>  chdir /run/kresd/workdir
>  softlimit -p 1
>  setuidgid kresd
>  kresd

Thanks, this looks pretty cool.

a couple caveats:

 * i don't see where the label for the sockets is passed in.  how is the
   daemon supposed to know whether to listen on the tcp socket using TLS
   or not?  How is it supposed to know whether the unix domain socket is
   for control or for recursive DNS queries?

 * it looks like this will result in a chain of proceses: nosh → nosh →
   kresd, rather than a single process due to the lack of exec.  or am i
   misunderstanding nosh?


I see you've got debian packages available for nosh, but they aren't in
debian proper.  have you considered putting them into debian?

   --dkg


signature.asc
Description: PGP signature

Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Steve Litt]

On Sun, 4 Sep 2016 17:30:43 +0100
Jonathan de Boyne Pollard 
wrote:

> Simon McVittie:
> 
> > This can already work. If you put XDG_RUNTIME_DIR in user programs' 
> > environment, and arrange for your favourite service manager to make
> > a dbus-daemon (or something else that speaks the same protocol)
> > listen on $XDG_RUNTIME_DIR/bus before any user process would try to
> > connect to it, then modern versions of at least libdbus, GDBus and
> > sd-bus will connect to it by default with no additional effort on
> > your part. This client-side code path does not depend on systemd,
> > does not depend on libsystemd (except obviously sd-bus which is
> > part of libsystemd), and is compiled in for all supported Unix
> > platforms. 
> That's the problem.  No the whole unix:runtime=yes mechanism is not.
> As I said, this is something that you and Joe Marcus Clarke and
> whomever else have to sort out with each other.  I'm unfortunately
> stuck in the middle, here.  Please do whatever it is that you need to
> do with each other to make your program understand address=systemd:
> and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD.  It does not
> do so.
> 
> Simon McVittie:
> 
> > Meanwhile, if you want the relevant integration files (your
> > favourite service manager's equivalent of systemd units) to be part
> > of dbus (the reference implementation of D-Bus), please propose
> > tested patches; if they follow the "user session" model[1], they
> > could eventually go in dbus-user-session.deb, with its dependencies
> > changed from the current systemd-sysv to "systemd-sysv |
> > your-service-manager". 
> Kudos for being the first project to offer integration, ever. (-:

Danger Will Robinson.

"Integration" in cases of systemd and its venus fly trap, dbus, is more
Embrace, Extend, Extinguish than integration. The Rube Goldbergesque
system described in the preceding quoted context exquisitely highlights
that fact.

Do not cooperate with systemd. The systemd proponents don't cooperate
with anyone else.


> Yes, down the road it would be marvellous if people included service
> bundles in their own projects.  

What would be marvellous is if people would simply ignore systemd,
opting for a real init system (not a conglomeration of welded krap
trying to supercede what we've had for years).

> Yes, I'd like to see the day when the
> number of service bundles in the nosh-bundles package actually starts
> going down, because people are taking on shipping their own service
> bundles for their own services, instead of going up.  So yes,
> eventually you'll be taken up on that offer I hope. But one step at a
> time.

Ooo, "service bundles." My runit run scripts average about 6 lines
long. Any fool can make them. Behold the power of a real init: An init
that knows it's an init, and does only what inits are designed to do. I
highlight runit out of familiarity, but my use of s6 and Epoch indicate
that both are equally as simple, when defining service startup, runit.

> 
> Simon McVittie:
> 
> >> As for what I would like, I'd like you (where that's plural, 
> >> including Joe Marcus Clarke or whomever else) to please make
> >> either address=systemd: or address=unix:runtime=yes work in your
> >> program on FreeBSD/PC-BSD/OpenBSD.
> >>  
> > To the best of my knowledge, the listenable address
> > "unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes")
> > does work on generic Unix, and should interoperate fine with the
> > XDG_RUNTIME_DIR/bus fallback used by clients with no
> > DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever
> > DBUS_UNIX is defined (i.e. everything except Windows), and I
> > haven't seen bug reports about that test failing. 


> There you go, then.  New knowledge.  (-:  It doesn't work with your 
> program as ported to FreeBSD/TrueOS/OpenBSD.  Joe Marcus Clarke is
> the porter for FreeBSD, according to the port information, and
> Antoine Jacoutot the porter for OpenBSD.  

To the *BSD communities: Please do not let the systemd camel get his
nose in your tent. Systemd is a repudiation of everything Unix, created
by a guy who makes no bones of his hate for Posix.


> This is why I am saying
> that it's something that you (plural, remember) need to sort out
> amongst yourselves.  We users stuck in the middle cannot use
> address=systemd: and address=unix:runtime=yes with your program on
> these systems.  As I said, it's something that I had to fix in
> November 2015, to stop trying to use address=systemd: on
> FreeBSD/TrueOS because it turned out that it didn't actually work.  I
> thought that address=unix:runtime=yes might, but that did not either.
> 
[snip]
> 
> Simon McVittie:
> 
> > To be brutally honest, there is a fairly low limit to how much
> > benefit I can create by giving new things to PC-BSD users, [...]
> >  
> That's not the right way to look at it.  

This is precisely the right way to look at it, when it pertains to
systemd.

> 

Re: s6, listen(8), etc.

[Jonathan de Boyne Pollard]

Laurent Bercot:


how does the daemon know what fd corresponds to what use?

In the wild, it's generally a for() loop over the passed-in descriptors 
that checks each socket type.  In the wild, only one of any type is 
often the case.


"If AF_INET4 and SOCK_DGRAM, this must be my UDP4 socket."

That's how I patched dnscache and tinydns to work, too.  A simple set of 
socket_is() functions in the Bernstein socket library, and it is off and 
away.

Re: s6, listen(8), etc.

[Jonathan de Boyne Pollard]

Daniel Kahn Gillmor wrote:

So i'm hoping that it'll find a taker in one of these more 
toolkit-style supervisor suites.



http://jdebp.eu./Softwares/nosh/#Features

socket services section