Re: [systemd-devel] [PATCH] networkd: do not change kernel forwarding parameters when IPForwarding is unset

2015-05-01 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, May 01, 2015 at 02:05:11PM -0700, Nick Owens wrote:
 From: Nick Owens misch...@offblast.org
 
 ---
  man/systemd.network.xml|  6 +++---
  src/network/networkd-link.c| 24 
  src/network/networkd-network.c |  2 ++
  src/network/networkd.h |  1 +
  4 files changed, 18 insertions(+), 15 deletions(-)
 
 the following patch should address 
 https://bugs.freedesktop.org/show_bug.cgi?id=89509
 let me know if there is a problem with it.
 
 sorry for the dup email tom et al., i had tried to send this email before 
 subscribing to the list.

Based on the discussion on the bug tracker, Lennart is OK with this
change. I think it makes sense too.

Please add some commit message though, explaining the rationale for the change
and the link 'https://bugs.freedesktop.org/show_bug.cgi?id=89509'.

 
 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index 4be9d13..c5958e3 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -356,7 +356,7 @@
listitemparaConfigures IP forwarding for the network
interface. If enabled incoming packets on the network
interface will be forwarded to other interfaces according to
 -  the routing table. Takes either a boolean argument, or the
 +  the routing table. The argument can be unset, a boolean, or the
Generally we don't specify that settings can be left unset. There are no
obligatory settings at all afaik. So there's no need to change this part.

values literalipv4/literal or literalipv6/literal,
which only enables IP forwarding for the specified address
family. This controls the
 @@ -365,8 +365,8 @@
filenamenet.ipv6.conf.lt;interfacegt;.forwarding/filename
sysctl options of the network interface (see ulink

 url=https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt;ip-sysctl.txt/ulink
 -  for details about sysctl options). Defaults to
 -  literalno/literal./para
 +  for details about sysctl options). By default, if unset, the IP
 +  forwarding parameters of the interface will not be changed.
And you can simplify this last sentence: If unset, IP forwarding
parameters of the interface will not be changed.

  
paraNote: unless this option is turned on, no IP
forwarding is done on this interface, even if this is
 diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
 index 0f9a1cd..6e7bade 100644
 --- a/src/network/networkd-link.c
 +++ b/src/network/networkd-link.c
 @@ -1488,16 +1488,14 @@ static int link_set_ipv4_forward(Link *link) {
  bool b;
  int r;
  
 -b = link_ipv4_forward_enabled(link);
 -
 -p = strjoina(/proc/sys/net/ipv4/conf/, link-ifname, 
 /forwarding);
 -r = write_string_file_no_create(p, one_zero(b));
 -if (r  0)
 -log_link_warning_errno(link, r, Cannot configure IPv4 
 forwarding for interface %s: %m, link-ifname);
 -
 -if (b) {
 +if (link-network-ip_forward != ADDRESS_FAMILY_UNSET) {
  _cleanup_free_ char *buf = NULL;
  
 +p = strjoina(/proc/sys/net/ipv4/conf/, link-ifname, 
 /forwarding);
 +r = write_string_file_no_create(p, 
 one_zero(link_ipv4_forward_enabled));
 +if (r  0)
 +log_link_warning_errno(link, r, Cannot configure 
 IPv4 forwarding for interface %s: %m, link-ifname);
 +
  /* If IP forwarding is turned on for this interface,
   * then propagate this to the global setting. Given
   * that turning this on has side-effects on other
 @@ -1525,10 +1523,12 @@ static int link_set_ipv6_forward(Link *link) {
  const char *p = NULL;
  int r;
  
 -p = strjoina(/proc/sys/net/ipv6/conf/, link-ifname, 
 /forwarding);
 -r = write_string_file_no_create(p, 
 one_zero(link_ipv6_forward_enabled(link)));
 -if (r  0)
 -log_link_warning_errno(link, r, Cannot configure IPv6 
 forwarding for interface: %m);
 +if (link-network-ip_forwarding != ADDRESS_FAMILY_UNSET) {
 +p = strjoina(/proc/sys/net/ipv6/conf/, link-ifname, 
 /forwarding);
 +r = write_string_file_no_create(p, 
 one_zero(link_ipv6_forward_enabled(link)));
 +if (r  0)
 +log_link_warning_errno(link, r, Cannot configure 
 IPv6 forwarding for interface: %m);
 +}
  
  return 0;
  }
 diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
 index 4d4972e..db36332 100644
 --- a/src/network/networkd-network.c
 +++ b/src/network/networkd-network.c
 @@ -109,6 +109,8 @@ static int network_load_one(Manager *manager, const char 
 *filename) {
  
  network-link_local = ADDRESS_FAMILY_IPV6;
  
 +network-ip_forward = ADDRESS_FAMILY_UNSET;
I think it would

Re: [systemd-devel] [PATCH v3] journalctl: Improve boot ID lookup

2015-05-01 Thread systemd github import bot 
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1430486116-18262-1-git-send-email-medhefgo%40web.de

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-nspawn --template: should it delete /etc/hostname?

2015-05-01 Thread Kai Krakow 
Hello!

If I create a new machine by cloning using systemd-nspawn --template, should 
it remove etc/hostname? It already creates a new machine-id etc, and the 
hostname should probably not be set for a new container in this case, 
regardless of whether the template is a real template or a cloned machine.

Thoughts?

I suppose something similar should be possible for statically configured IP 
addresses as an option, tho I wouldn't know how to implement that because 
systemd-networkd doesn't expect that information at well defined location.

-- 
Replies to list only preferred.

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

[systemd-devel] systemd-nspawn: cannot join existing macvlan

2015-05-01 Thread Kai Krakow 
Hello!

I'm not sure about this but I suspect that I cannot start a second nspawn 
container with --network-macvlan when another nspawn instance has created it 
before:

# systemd-nspawn -b --network-macvlan=enp4s0
Spawning container gentoo-mysql-base on /var/lib/machines/gentoo-mysql-base.
Press ^] three times within 1s to kill container.
Failed to add new macvlan interfaces: File exists

To my surprise it works when adding machines to machines.target. While you 
cannot start them through means of systemd because of the same error, it 
works during boot of the whole system: All containers boot up properly - but 
stop one and you cannot restart it.

So it looks like there's an unintentional race condition during boot which 
allows to create this interface but when the system is up, it no longer 
works because the race condition is no longer present.

systemd-nspawn should probably just allow joining existing macvlan bridges. 
I would fix it in the code but I don't know the implications why this check 
is in there in the first place.

A second fix should maybe do something about such race conditions if it is 
such one. I suspect there are cases where the interface presence check makes 
actually sense.

-- 
Replies to list only preferred.

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

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction

2015-05-01 Thread Uoti Urpala 
On Mon, 2015-04-27 at 18:07 +0200, Lennart Poettering wrote:
 On Wed, 04.02.15 23:48, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
  If you mean something like systemctl restart --no-block
  mydaemon-convert-config.service; systemctl reload mydaemon.service, I
  don't see why you'd ever /expect/ this to work with any reload semantics
  - isn't this clear user error, and will be racy with current systemd
  code just as much as the proposed fix? 
 
 Yupp, this is what I mean. (though I'd actually specify the --no-block
 in the second command too, though this doesn't make much of a
 difference...)


  And in any case I'd consider the semantics of reload to be switch
  to configuration equal or newer than what existed *when the reload
  was requested*, without any guarantees that changes from operations
  queued but not finished before calling reload would be taken into
  account.
 
 The queue is really a work queue, and the After= and Before= deps
 dictate how the work can be parallelized or needs to be serialized. As
 such if i have 5 jobs enqueued that depend on each other, i need to
 make sure they are executed in the order specified and can operateon
 the results of the previous job.
 
 I hope this makes sense...

After those clarifications I believe I now understand what kind of
example case you meant, and it does now seem a meaningful case to
consider; however, I still think that you're wrong, as your example case
turns out to work fine and is not actually a counterexample to the kind
of changes I was talking about.

If I understood correctly, you're talking about a case where service B
has After=A.service, both A and B have queued jobs where the B job is
a reload, and the queued job for A might change the configuration for B
(so the reload needs to happen after that); and you're worried that
immediately returning success for the reload could create a violation of
the after job A requirement. Is this reload property of After
documented anywhere? The code does seem to apply it to reloads, but
systemd.unit documentation only starts about start/stop. Anyway, when
you consider what actually happens with my suggested change, it turns
out that even these After semantics for reload still work.

The situation where my changes would result in different behavior is
when B has a start job queued, but no code for B is running yet, and you
request a reload for B; current code waits for the start of B before the
reload is considered complete, whereas my change makes the reload return
immediate success. This does not actually change the semantics above:
the only difference is when the reload operation is CONSIDERED COMPLETE,
there is NO difference in what operations are actually run or in which
order! [1] Current code merges RELOAD to existing START and returns
success for reload after START has completed, whereas my change returns
success immediately; but both run exactly the same START operation with
the same ordering constraints, which already ensure that it happens
after A.service (START already has the ordering constraints from
After=; merging the RELOAD to START does not add any additional
ordering that START would not already have had).

[1] So this difference only really matters when something blocks to wait
until the reload completes.


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

Re: [systemd-devel] pam_systemd.so indirectly calling pam_acct_mgmt

2015-05-01 Thread Colin Guthrie 
Stephen Gallagher wrote on 30/04/15 14:04:
 On Thu, 2015-04-30 at 15:01 +0200, Lennart Poettering wrote:
 On Thu, 30.04.15 08:54, Stephen Gallagher (sgall...@redhat.com) 
 wrote:

 Does set-linger persist across reboots? 

 Yes it does. When a systemd is booted up with a user that has
 lingering on this means that his user@.service instance is invoked at
 boot, without waiting for any login.

 
 One last question, Lennart: what is the primary use-case for the
 linger feature? When is it expected that users would want to use it?

There are lots of potential uses.

e.g. a user may want to run their irssi IRC client at all times
(connecting into it via screen or via proxy etc).

Or maybe they want to run Rygel to export their media collection over
the network. Various other daemons make sense to be run in a per-user
context (i.e. not system services) and the lingering feature allows this
in a clean way.

Hope this gives you some use cases. I'm sure other people an give others.

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] mount crypto_LUKS device in conatiner

2015-05-01 Thread arnaud gaboury 
My container will need access to a Luks encrypted device (/dev/sdd4) for its DB.

Here is the setup on the host :

-
# cryptsetup --key-file /etc/keys/poppy.luks luksOpen /dev/bcache0 sdd4_crypt
$  lsblk -o NAME,KNAME,MAJ:MIN,FSTYPE,LABEL
..
└─sdd4   sdd4  8:52  bcache
  └─bcache0  bcache0 254:0   crypto_LUKS
└─sdd4_crypt dm-7253:7   btrfs   poppy-encrypt


I am little lost for now how the container manage /dev and  devices
mapper. So I am wondering where to write this device entry in
/etc/fstab  and /etc/crypttab. In host or container?

It seems to me it is more easy to manage anything in the host. Am I right?

Thank you for hints.
-- 

google.com/+arnaudgabourygabx
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam_systemd.so indirectly calling pam_acct_mgmt

2015-05-01 Thread Tomasz Torcz 
On Fri, May 01, 2015 at 09:46:26AM +0100, Colin Guthrie wrote:
 Stephen Gallagher wrote on 30/04/15 14:04:
  On Thu, 2015-04-30 at 15:01 +0200, Lennart Poettering wrote:
  On Thu, 30.04.15 08:54, Stephen Gallagher (sgall...@redhat.com) 
  wrote:
 
  Does set-linger persist across reboots? 
 
  Yes it does. When a systemd is booted up with a user that has
  lingering on this means that his user@.service instance is invoked at
  boot, without waiting for any login.
 
  
  One last question, Lennart: what is the primary use-case for the
  linger feature? When is it expected that users would want to use it?
 
 There are lots of potential uses.
 
 e.g. a user may want to run their irssi IRC client at all times
 (connecting into it via screen or via proxy etc).

  I'm using it primarly for two things:
1) having user services (like dropbox) run even when I'm not logged in
2) do some periodic tasks as user; systemd timers are more flexible than
   cron 

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia

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

Re: [systemd-devel] sd-bus vs gdbus on dbus-daemon

2015-05-01 Thread Umut Tezduyar Lindskog 
On Thu, Apr 30, 2015 at 11:13 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
 Hi Simon,

 On Wed, Apr 29, 2015 at 5:34 PM, Simon McVittie
 simon.mcvit...@collabora.co.uk wrote:
 On 29/04/15 15:08, Umut Tezduyar Lindskog wrote:
 We [1] have noticed that there could be up to %50 performance gain on
 using sd-bus over gdbus on dbus-daemon.
 ...
 gdbus.c
   - g_dbus_proxy_new_for_bus_sync()
   - 50 x g_dbus_proxy_call_sync()

 sdbus.c
   - sd_bus_open_system()
   - 50 x sd_bus_get_property()

 If you want to compare apples with apples, I suggest using the
 lower-level g_bus_get() and g_dbus_connection_call[_sync]() instead of
 GDBusProxy. The design and priorities of sd-bus and GDBus are not really
 very similar, but GDBusProxy is certainly not the closest equivalent you
 can get.

 Thanks for the tip. I will re-run the measurements with
 g_dbus_connection_call_sync(g_bus_get_sync(),...). Just considering
 the traffic in the dbus, I do believe we have compared apple to apple.
 But if you believe we might get even more performance with raw API
 calls, then that is fantastic news!

Unfortunately I didn't get any better result with
g_dbus_connection_call_sync. I have updated the link
(https://drive.google.com/open?id=1O3FEnpdZ2auisYalKT6qJTiNV9cfDxya_qisbpGj3MQauthuser=0)
with the source code if you would like to double check my work.

Umut



 Also, if your application profile is such that (a) D-Bus is a
 significant factor in performance, and (b) sending 50 synchronous D-Bus
 messages per connection is anywhere near realistic, then you are
 probably not using D-Bus the way it is designed to be used.

 Measurement we have done was not about if dbus is the ipc we want or
 not. It was about comparing the performances of two libraries. It
 wouldn't have been fair to compare sending only 1 message on the dbus
 due to the performance penalty of creating a worker thread with gdbus.
 But it really didn't matter. 1, 2, 10, 50, in all cases gdbus
 (GDBusProxy) couldn't performed as good as sd-bus.


 See also http://permalink.gmane.org/gmane.comp.freedesktop.dbus/13663.

 --
 Simon McVittie
 Collabora Ltd. http://www.collabora.com/

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

Re: [systemd-devel] udev interface naming for SR-IOV VFs

2015-05-01 Thread Dan Kenigsberg 
On Mon, Apr 20, 2015 at 08:43:21PM +0200, Lennart Poettering wrote:
 On Fri, 17.04.15 14:19, Nir Soffer (nir...@gmail.com) wrote:
 
  - You may wait for unrelated events that happen to trigger in the same
time, waiting after the new interfaces are ready.
  
  I think you need something like:
  
  while True:
  try:
  udevadm.settle(1)
  except udevadm.Timeout:
  pass
  else:
  if all devices are ready:
  break
  time.sleep(1)
 
 Please never use udevadm settle in new code.

Could you explain why? Is it because we are not sure if our events
have not been queued when settle is called, or something more dramatic
that should be documented in udevadm(1)?

 
 Please instead subscribe to libudev events about network interfaces
 and don't take rtnl messages into account until the device has been
 reported via udev, too.
 
 THis is for example what networkd does to make sure it doesn't start
 making use of network interfaces that didn't get fully set up yet by
 the udev rules.
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] networkd: do not change kernel forwarding parameters when IPForwarding is unset

2015-05-01 Thread Nick Owens 
From: Nick Owens misch...@offblast.org

---
 man/systemd.network.xml|  6 +++---
 src/network/networkd-link.c| 24 
 src/network/networkd-network.c |  2 ++
 src/network/networkd.h |  1 +
 4 files changed, 18 insertions(+), 15 deletions(-)

the following patch should address 
https://bugs.freedesktop.org/show_bug.cgi?id=89509
let me know if there is a problem with it.

sorry for the dup email tom et al., i had tried to send this email before 
subscribing to the list.

diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 4be9d13..c5958e3 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -356,7 +356,7 @@
   listitemparaConfigures IP forwarding for the network
   interface. If enabled incoming packets on the network
   interface will be forwarded to other interfaces according to
-  the routing table. Takes either a boolean argument, or the
+  the routing table. The argument can be unset, a boolean, or the
   values literalipv4/literal or literalipv6/literal,
   which only enables IP forwarding for the specified address
   family. This controls the
@@ -365,8 +365,8 @@
   filenamenet.ipv6.conf.lt;interfacegt;.forwarding/filename
   sysctl options of the network interface (see ulink
   
url=https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt;ip-sysctl.txt/ulink
-  for details about sysctl options). Defaults to
-  literalno/literal./para
+  for details about sysctl options). By default, if unset, the IP
+  forwarding parameters of the interface will not be changed.
 
   paraNote: unless this option is turned on, no IP
   forwarding is done on this interface, even if this is
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 0f9a1cd..6e7bade 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -1488,16 +1488,14 @@ static int link_set_ipv4_forward(Link *link) {
 bool b;
 int r;
 
-b = link_ipv4_forward_enabled(link);
-
-p = strjoina(/proc/sys/net/ipv4/conf/, link-ifname, /forwarding);
-r = write_string_file_no_create(p, one_zero(b));
-if (r  0)
-log_link_warning_errno(link, r, Cannot configure IPv4 
forwarding for interface %s: %m, link-ifname);
-
-if (b) {
+if (link-network-ip_forward != ADDRESS_FAMILY_UNSET) {
 _cleanup_free_ char *buf = NULL;
 
+p = strjoina(/proc/sys/net/ipv4/conf/, link-ifname, 
/forwarding);
+r = write_string_file_no_create(p, 
one_zero(link_ipv4_forward_enabled));
+if (r  0)
+log_link_warning_errno(link, r, Cannot configure IPv4 
forwarding for interface %s: %m, link-ifname);
+
 /* If IP forwarding is turned on for this interface,
  * then propagate this to the global setting. Given
  * that turning this on has side-effects on other
@@ -1525,10 +1523,12 @@ static int link_set_ipv6_forward(Link *link) {
 const char *p = NULL;
 int r;
 
-p = strjoina(/proc/sys/net/ipv6/conf/, link-ifname, /forwarding);
-r = write_string_file_no_create(p, 
one_zero(link_ipv6_forward_enabled(link)));
-if (r  0)
-log_link_warning_errno(link, r, Cannot configure IPv6 
forwarding for interface: %m);
+if (link-network-ip_forwarding != ADDRESS_FAMILY_UNSET) {
+p = strjoina(/proc/sys/net/ipv6/conf/, link-ifname, 
/forwarding);
+r = write_string_file_no_create(p, 
one_zero(link_ipv6_forward_enabled(link)));
+if (r  0)
+log_link_warning_errno(link, r, Cannot configure IPv6 
forwarding for interface: %m);
+}
 
 return 0;
 }
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 4d4972e..db36332 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -109,6 +109,8 @@ static int network_load_one(Manager *manager, const char 
*filename) {
 
 network-link_local = ADDRESS_FAMILY_IPV6;
 
+network-ip_forward = ADDRESS_FAMILY_UNSET;
+
 r = config_parse(NULL, filename, file,
  Match\0
  Link\0
diff --git a/src/network/networkd.h b/src/network/networkd.h
index 4b13d4a..f4aefc1 100644
--- a/src/network/networkd.h
+++ b/src/network/networkd.h
@@ -60,6 +60,7 @@ typedef enum AddressFamilyBoolean {
 ADDRESS_FAMILY_IPV4 = 1,
 ADDRESS_FAMILY_IPV6 = 2,
 ADDRESS_FAMILY_YES = 3,
+ADDRESS_FAMILY_UNSET = 4,
 _ADDRESS_FAMILY_BOOLEAN_MAX,
 _ADDRESS_FAMILY_BOOLEAN_INVALID = -1,
 } AddressFamilyBoolean;
-- 
2.3.6

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

Re: [systemd-devel] [PATCH] networkd: do not change kernel forwarding parameters when IPForwarding is unset

2015-05-01 Thread systemd github import bot 
Patchset imported to github.
Pull request:
https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1430514311-3787-1-git-send-email-nick.owens%40coreos.com

--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] pam_systemd.so indirectly calling pam_acct_mgmt

2015-05-01 Thread Stephen Gallagher 
On Fri, 2015-05-01 at 11:46 +0200, Tomasz Torcz wrote:
 On Fri, May 01, 2015 at 09:46:26AM +0100, Colin Guthrie wrote:
  Stephen Gallagher wrote on 30/04/15 14:04:
   On Thu, 2015-04-30 at 15:01 +0200, Lennart Poettering wrote:
On Thu, 30.04.15 08:54, Stephen Gallagher (sgall...@redhat.com) 

wrote:

 Does set-linger persist across reboots? 

Yes it does. When a systemd is booted up with a user that has
lingering on this means that his user@.service instance is 
invoked at
boot, without waiting for any login.

   
   One last question, Lennart: what is the primary use-case for the
   linger feature? When is it expected that users would want to use 
   it?
  
  There are lots of potential uses.
  
  e.g. a user may want to run their irssi IRC client at all times
  (connecting into it via screen or via proxy etc).
 
   I'm using it primarly for two things:
 1) having user services (like dropbox) run even when I'm not logged 
 in
 2) do some periodic tasks as user; systemd timers are more flexible 
 than
cron 
 



Right, so based on this information, it seems to me that in SSSD we
need to be treating the 'systemd-user' PAM service the same way we do
the 'cron' service. The idea being that this is meant to handle
actions performed *as* a user but not *by* a user (for lack of a
better distinction).

In the terms of how Microsoft Active Directory would treat it (and
when we're using AD as the identity and authorization store), it
should be handled as the [Allow|Deny]BatchLogonRight permission which
is described by MS as:

This security setting allows a user to be logged on by means of a
batch-queue facility.

For example, when a user submits a job by means of the task scheduler,
the task scheduler logs that user on as a batch user rather than as an
interactive user.

Does that seem to match everyone's expectation here?

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add VARIANT as a standard value for /etc/os-release

2015-05-01 Thread Stephen Gallagher 
On Wed, 2015-04-29 at 08:19 -0400, Stephen Gallagher wrote:
 Some distributions (such as Fedora) are using the VARIANT field to
 indicate to select packages which of several default configurations
 they should be using. For example, VARIANT=Server provides a
 different default firewall configuration (blocking basically
 everything but SSH and the management console) whereas
 VARIANT=Workstation opens many other ports for application
 compatibility.
 
 By adding this patch to the manual pages, we can standardize on a
 cross-distribution mechanism for accomplishing this.
 
 Fedora implementation details are available at
 https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration



Lennart, I believe I addressed your concerns here. Would you mind re
-reviewing?


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v3] journalctl: Improve boot ID lookup

2015-05-01 Thread Jan Janssen 
This method should greatly improve offset based lookup, by simply jumping
from one boot to the next boot. It starts at the journal head to get the
a boot ID, makes a _BOOT_ID match and then comes from the opposite
journal direction (tail) to get to the end that boot. After flushing the matches
and advancing the journal from that exact position, we arrive at the start
of next boot. Rinse and repeat.

This is faster than the old method of aggregating the full boot listing just
so we can jump to a specific boot, which can be a real pain on big journals
just for a mere -b -1 case.

As an additional benefit --list-boots should improve slightly too, because
it does less seeking.

Note that there can be a change in boot order with this lookup method
because it will use the order of boots in the journal, not the realtime stamp
stored in them. That's arguably better, though.
Another deficiency is that it will get confused with boots interleaving in the
journal, therefore, it will refuse operation in --merge, --file and --directory 
mode.

https://bugs.freedesktop.org/show_bug.cgi?id=72601
---
 src/journal/journalctl.c | 275 ++-
 1 file changed, 174 insertions(+), 101 deletions(-)

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 666aa20..c059b77 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -129,6 +129,7 @@ typedef struct boot_id_t {
 sd_id128_t id;
 uint64_t first;
 uint64_t last;
+LIST_FIELDS(struct boot_id_t, boot_list);
 } boot_id_t;
 
 static void pager_open_if_enabled(void) {
@@ -733,6 +734,11 @@ static int parse_argv(int argc, char *argv[]) {
 return -EINVAL;
 }
 
+if ((arg_boot || arg_action == ACTION_LIST_BOOTS)  (arg_file || 
arg_directory || arg_merge)) {
+log_error(Using --boot or --list-boots with --file, 
--directory or --merge is not supported.);
+return -EINVAL;
+}
+
 return 1;
 }
 
@@ -852,111 +858,203 @@ static int add_matches(sd_journal *j, char **args) {
 return 0;
 }
 
-static int boot_id_cmp(const void *a, const void *b) {
-uint64_t _a, _b;
+static int discover_next_boot(sd_journal *j,
+  boot_id_t **boot,
+  bool advance_older,
+  bool read_realtime) {
+int r;
+char match[9+32+1] = _BOOT_ID=;
+_cleanup_free_ boot_id_t *next_boot = NULL;
 
-_a = ((const boot_id_t *)a)-first;
-_b = ((const boot_id_t *)b)-first;
+assert(j);
+assert(boot);
 
-return _a  _b ? -1 : (_a  _b ? 1 : 0);
-}
+/* We expect the journal to be on the last position of a boot
+ * (in relation to the direction we are going), so that the next
+ * invocation of sd_journal_next/previous will be from a different
+ * boot. We then collect any information we desire and then jump
+ * to the last location of the new boot by using a _BOOT_ID match
+ * coming from the other journal direction. */
 
-static int get_boots(sd_journal *j,
- boot_id_t **boots,
- unsigned int *count,
- boot_id_t *query_ref_boot) {
-int r;
-const void *data;
-size_t length, allocated = 0;
+/* Make sure we aren't restricted by any _BOOT_ID matches, so that
+ * we can actually advance to a *different* boot. */
+sd_journal_flush_matches(j);
 
-assert(j);
-assert(boots);
-assert(count);
+if (advance_older)
+r = sd_journal_previous(j);
+else
+r = sd_journal_next(j);
+if (r  0)
+return r;
+else if (r == 0)
+return 0; /* End of journal, yay. */
+
+next_boot = new0(boot_id_t, 1);
+if (!next_boot)
+return log_oom();
 
-r = sd_journal_query_unique(j, _BOOT_ID);
+r = sd_journal_get_monotonic_usec(j, NULL, next_boot-id);
 if (r  0)
 return r;
 
-*count = 0;
-SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
-boot_id_t *id;
+if (read_realtime) {
+r = sd_journal_get_realtime_usec(j, next_boot-first);
+if (r  0)
+return r;
+}
 
-assert(startswith(data, _BOOT_ID=));
+/* Now seek to the last occurrence of this boot ID. */
+sd_id128_to_string(next_boot-id, match + 9);
+r = sd_journal_add_match(j, match, sizeof(match) - 1);
+if (r  0)
+return r;
 
-if (!GREEDY_REALLOC(*boots, allocated, *count + 1))
-return log_oom();
+if (advance_older)
+r = sd_journal_seek_head(j);
+else
+r = sd_journal_seek_tail(j);
+if (r  0)
+