Re: [systemd-devel] negative trust anchors not working with non TLD domain names

2017-04-20 Thread Sean Dague 
On 04/20/2017 07:05 AM, Lennart Poettering wrote:
> On Wed, 19.04.17 07:12, Sean Dague (s...@dague.net) wrote:
> 
>> I just upgraded to Ubuntu 17.04 (systemd 232) where systemd-resolved is
>> turned on by default, which means DNSSEC validation on by default.
> 
> The DNSSEC code got substantially updated in 233. Any chance you can
> retest with something more current?
> 
> Lennart

I rebuilt systemd 233 out of debian experimental on a VM, and after
installing that in a fresh 17.04 environment, the local lookup case
seems to be working fine. I'll go report that to the distro. Are there
specific patches that they should be looking at here to fix this
behavior, or is it extensive enough that the answer is just that it's
going to need a full version bump?

-Sean

-- 
Sean Dague
http://dague.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

2017-04-20 Thread David Herrmann 
Hey

On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
> Hi,
>
> I'm implementing a server which creates an ObjectManager using the
> sd-bus API and there seems to be some differences between how gdbus and
> sd-bus implements the API.
>
> I implemented a simple ObjectManager at /org/gnome/TestManager which
> exports objects /org/gnome/TestManager/fooX with interface
> org.gnome.TestManager.Device.
>
> Under sd-bus, if an object is removed, the following signal is
> generated:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.freedesktop.DBus.Peer"
>   string "org.freedesktop.DBus.Introspectable"
>   string "org.freedesktop.DBus.Properties"
>   string "org.freedesktop.DBus.ObjectManager"
>   string "org.gnome.TestManager.Device"
>]
>
> If I implement the same simple server in gdbus, the signal is instead:
>
> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
> serial=90 path=/org/gnome/TestManager;
> interface=org.freedesktop.DBus.ObjectManager;
> member=InterfacesRemoved
>object path "/org/gnome/TestManager/foo0"
>array [
>   string "org.gnome.TestManager.Device"
>]
>
> The corresponding signals are also generated when an object is added.
>
> Beside simply being different, this difference seems to confuse gdbus.
> If I create a test client, it will report that any object which is
> already existing when I start the client has 1 interface and any object
> which is added/removed subsequently is reported as having 5 interfaces,
> 4 of which are nameless (this would appear to be one or more gdbus
> bug(s)).
>
> This bug in gdbus also means that it doesn't correctly catch the removal
> of an object which existed at the time the client was started (because
> of the interface count mismatch).
>
> Anyway, gdbus bugs aside, it seems that the interfaces reported by
> sd-bus should match what gdbus does? (assuming, of course, that gdbus
> can be considered the "reference" implementation).

Does the appended patch fix your issue?
(line-breaks might be screwed, sorry)

Thanks
David


diff --git a/src/libsystemd/sd-bus/bus-objects.c
b/src/libsystemd/sd-bus/bus-objects.c
index 9bd07ffca..b6f5afe1b 100644
--- a/src/libsystemd/sd-bus/bus-objects.c
+++ b/src/libsystemd/sd-bus/bus-objects.c
@@ -1057,6 +1057,22 @@ static int object_manager_serialize_path(
 if (r < 0)
 return r;

+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Peer", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Introspectable", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.Properties", 0);
+if (r < 0)
+return r;
+
+r = sd_bus_message_append(reply, "{sa{sv}}",
"org.freedesktop.DBus.ObjectManager", 0);
+if (r < 0)
+return r;
+
 found_something = true;
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] nspawn: devpts not mounted with PrivateUsers

2017-04-20 Thread Michael Biebl 
2017-04-20 13:09 GMT+02:00 Michael Biebl :

> nspawn/machined are in the systemd-container package in Debian, which
> in turn recommends libnss-mymachines.
> Recommends are installed by default, unless the user explicitly disables that.

And libnss-mymachines depends on systemd-container, as it would be
pretty useless withouth.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] nspawn: devpts not mounted with PrivateUsers

2017-04-20 Thread Michael Biebl 
2017-04-20 12:32 GMT+02:00 Lennart Poettering :
> On Thu, 20.04.17 00:14, Olaf the Lost Viking (olaf.the.lost.vik...@gmail.com) 
> wrote:
>
>> > Don't do this. If you register the group like this, nspawn will
>> > normally abstain from using this group. Use "nss-mymachines" instead
>> > (consider lobbying your distro to turn it on automatically when
>> > nspawn/machined are installed) which will make all private UIDs used
>> > by nspawn (or any other machined registered containers) appear in the
>> > user database (as shown by getent passwd) without any modification of
>> > /etc/passwd or any other file therein.
>>
>> I'm glad that I don't have to do that! It was one of the experiments to get
>> things to to work. Letting systemd do that automatically is much, much 
>> better!
>>
>> The nss-mymachines/myhostname/resolve/systemd aren't installed in a Debian
>> minbase - you are right! I figured that out, too, and installed them 
>> manually.
>> But I guess this is fair as I explicitly asked for a _minimal_
>> installation.
>
> nss-mymachines really should be part of the same package as
> nspawn/machined, not the one of resolved. Please ask your distro to
> fix that...

nspawn/machined are in the systemd-container package in Debian, which
in turn recommends libnss-mymachines.
Recommends are installed by default, unless the user explicitly disables that.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] negative trust anchors not working with non TLD domain names

2017-04-20 Thread Lennart Poettering 
On Wed, 19.04.17 07:12, Sean Dague (s...@dague.net) wrote:

> I just upgraded to Ubuntu 17.04 (systemd 232) where systemd-resolved is
> turned on by default, which means DNSSEC validation on by default.

The DNSSEC code got substantially updated in 233. Any chance you can
retest with something more current?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] nspawn: devpts not mounted with PrivateUsers

2017-04-20 Thread Lennart Poettering 
On Thu, 20.04.17 00:14, Olaf the Lost Viking (olaf.the.lost.vik...@gmail.com) 
wrote:

> > Don't do this. If you register the group like this, nspawn will
> > normally abstain from using this group. Use "nss-mymachines" instead
> > (consider lobbying your distro to turn it on automatically when
> > nspawn/machined are installed) which will make all private UIDs used
> > by nspawn (or any other machined registered containers) appear in the
> > user database (as shown by getent passwd) without any modification of
> > /etc/passwd or any other file therein.
> 
> I'm glad that I don't have to do that! It was one of the experiments to get 
> things to to work. Letting systemd do that automatically is much, much better!
> 
> The nss-mymachines/myhostname/resolve/systemd aren't installed in a Debian 
> minbase - you are right! I figured that out, too, and installed them 
> manually. 
> But I guess this is fair as I explicitly asked for a _minimal_
> installation.

nss-mymachines really should be part of the same package as
nspawn/machined, not the one of resolved. Please ask your distro to
fix that...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] sd-bus: ObjectManager difference with gdbus

2017-04-20 Thread David Härdeman 
Hi,

I'm implementing a server which creates an ObjectManager using the
sd-bus API and there seems to be some differences between how gdbus and
sd-bus implements the API.

I implemented a simple ObjectManager at /org/gnome/TestManager which
exports objects /org/gnome/TestManager/fooX with interface
org.gnome.TestManager.Device.

Under sd-bus, if an object is removed, the following signal is
generated:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
   object path "/org/gnome/TestManager/foo0"
   array [
  string "org.freedesktop.DBus.Peer"
  string "org.freedesktop.DBus.Introspectable"
  string "org.freedesktop.DBus.Properties"
  string "org.freedesktop.DBus.ObjectManager"
  string "org.gnome.TestManager.Device"
   ]

If I implement the same simple server in gdbus, the signal is instead:

signal time=1492642227.714223 sender=:1.104 -> destination=(null destination) 
serial=90 path=/org/gnome/TestManager;
interface=org.freedesktop.DBus.ObjectManager;
member=InterfacesRemoved
   object path "/org/gnome/TestManager/foo0"
   array [
  string "org.gnome.TestManager.Device"
   ]

The corresponding signals are also generated when an object is added.

Beside simply being different, this difference seems to confuse gdbus.
If I create a test client, it will report that any object which is
already existing when I start the client has 1 interface and any object
which is added/removed subsequently is reported as having 5 interfaces,
4 of which are nameless (this would appear to be one or more gdbus
bug(s)).

This bug in gdbus also means that it doesn't correctly catch the removal
of an object which existed at the time the client was started (because
of the interface count mismatch).

Anyway, gdbus bugs aside, it seems that the interfaces reported by
sd-bus should match what gdbus does? (assuming, of course, that gdbus
can be considered the "reference" implementation).

Regards,
David

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service Type for Tomcat

2017-04-20 Thread Lennart Poettering 
On Wed, 19.04.17 20:32, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 18.04.2017 21:35, Jonathan de Boyne Pollard пишет:
> > "Igal @ Lucee.org" :
> >> Examples I see online use forking [...]
> > 
> > ... because they are bad examples.  Read
> > http://jdebp.eu./FGA/systemd-house-of-horror/tomcat.html .
> 
> Service type simple is the worst possible type as it does not provide
> for any synchronization between started process and dependent services.
> So examples that recommend forking are correct (as long as forking is
> implemented correctly). If you have choice between working forking and
> simple, forking is definitely preferred.

I can only second that. The various types in order of preference:

1) Type=notify — if the daemon supports that this is almost always the
   best option, as no forking and no messy PID files are involved, and
   proper ready synchronization is supported. Of course, the daemons
   need to support this method explicitly. Supporting this is easy
   though: you can either use libsystemd's sd_notify() function or any
   similar library for your language of choice. In fact, the
   underlying protocol is so simple and generic, that it is trivial to
   reimplement without involving any external library altogether:
   simply send a single AF_UNIX/SOCK_DGRAM datagram to the socket set
   in $NOTIFY_SOCKET containing a newline-separated text string and
   you are done. (There's one trick though: if $NOTIFY_SOCKET starts
   with an '@' character, it refers to a socket in the Linux AF_UNIX
   'abstract' namespace, which essentially means you need to replace
   it with a NUL char when binding).

2) Type=forking — this is the traditional UNIX way. It requires
   double-fork()ing in order to daemonize. If your daemon consists of
   multiple processes your daemon also needs to write out a PID file
   (and you need to tell systemd about it via PIDFile=), otherwise
   systemd can't know which the 'main' process of your daemon
   is. Double-fork()ing correctly is hard, and traditionally people
   haven't been very good at implementing this correctly. Well-known
   mistakes are: people only fork() once, not twice, which means the
   process won't be reparented to PID 1 correctly — systemd is very
   forgiving on this one though. More problematic is if daemons exit
   in the parent process before the grandchild properly completed
   initialization and established all listening sockets and
   suchlike. For broken daemons like that startup synchronization won't
   work, as systemd will continue starting the next daemons at a time
   where these daemons haven't finished start-up yet. Note that not
   implementing this correctly not only is broken on systemd but also
   on all other init systems, including traditional SysV. Note that
   Type=forking is hard to use in programming environments where
   fork() is not available. Specifically, Go, Java, and many other
   higher-level programming languages don't really support fork()
   without execve(), i.e. they don't permit the language runtime being
   duplicated without all associated threads.

3) Type=simple — in this mode, systemd won't do any synchronization,
   and just fork off your daemon and immediately proceed with the
   next. This is a great option for daemons which are unlikely to fail
   or where failure shall not be propagated to any depending
   services. This is a particularly good option for socket activated
   services, as for them all communication channels are already
   established before the service starts, and synchronization is hence
   redundant. Type=simple is not a useful option however, if your
   daemon has a startup phase where it establishes communication
   channels or if it can likely fail during its startup phase and that
   fact should propagated to depending services.

Under the assumption that Tomcat does have communication channels
(most non-trivial software has) and there are depending services that
need to wait for them to be established, and given that Tomcat appears
to be written in Java, I am pretty sure Type=notify is the best
option, but it does require sending out that notification message with
sd_notify() or something equivalent.

Given that systemd is pretty universally adopted in bigger
distributions, in particular commercial ones these days, it should not
be impossible to convince the Tomcat developers to add native support
for the sd_notify() message. In particular as support for it is
entirely transparent: if $NOTIFY_SOCKET is set, send that one ready
message to it, otherwise don't. This will make things work nicely with
systemd, and won't affect systems not using it.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd mucking with partition tables ( was: bug#25756: Problems using "parted ... print" on nvme devices )

2017-04-20 Thread Lennart Poettering 
On Wed, 19.04.17 13:59, Phil Susi (ps...@ubuntu.com) wrote:

> On 4/19/2017 12:17 PM, Lennart Poettering wrote:
> > This isn't precisely new functionality, it has been doing that since
> > years. It will synthesize "change" udev events when a process closes a block
> > device after writing, so that the changed superblock/partition
> > information is properly propagated to clients.
> > 
> > Also note that parted never was in the business of retriggering block
> > devices through sysfs/udev (i.e. echoing "change" into a "uevents"
> > file in sysfs), only udev ever did that so far, and I am pretty sure
> > that should stay that way.
> 
> What?  The kernel must generate the event as otherwise systemd has no
> idea that a process on the system closed its handle to the device, and
> so would not know when it should trigger them.  Or do you mean that the
> kernel only triggers on the main device, and udev now synthesizes events
> on the partitions?

The kernel generates inotify IN_CLOSED_WRITE events, and udev then
retriggers the device.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logging API

2017-04-20 Thread Jérémy Rosen 
The logging API provided by journald is already very rich, have a look 
at man:sd_journal_send


if you just want log levels, do note that journald will parse lines 
starting with "<1>" and related prefix  as syslog levels and correctly 
treat them... even if those messages arrive through the stdout of your 
daemon


man:sd-daemon has the details of that particular feature. it's 
particularly easy to use.


On 20/04/2017 09:41, Łukasz Stelmach wrote:

Hello.

I am writing a new piece of code. After several dozens of fprintf(3)
calls here and there I decided to clean that mess. I really like the
internal logging API (log_error(), log_debug(), log_info_errno() etc.)
used by systemd parts.

Is it possible to make it part of the public libsystemd API? Where to
start the work?



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
Logo 

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr    
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr 
Tel : +33141402967

Facebook  Google%2B 
 LinkedIn 
 Twitter 




bandeaux_mail 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] logging API

2017-04-20 Thread Łukasz Stelmach 
Hello.

I am writing a new piece of code. After several dozens of fprintf(3)
calls here and there I decided to clean that mess. I really like the
internal logging API (log_error(), log_debug(), log_info_errno() etc.)
used by systemd parts.

Is it possible to make it part of the public libsystemd API? Where to
start the work?

-- 
Łukasz Stelmach
Samsung R Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel