Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Tom Gundersen 
Hi Zbyszek,

On 27 May 2014 04:38, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
wrote:

 On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
  When enabled in [Network] it will set up a dhcp server on the
interface, listening
  on one of its statically configured IPv4 addresses and with a fixed
size pool of
  leases determined from it.
 Hi Tom,
 before looking at the code, a couple of general questions:
 - does the DHCP server have to be part of networkd? Isn't the job
   of acquiring addresses and giving out addresses separate and shouldn't
   two different processes be responsible?

As the dhcp library will need (eventually) a lot of state from networkd and
to hook into various events, I think having it integrated will make our
lives much easier. However, as all the logic lives in the library,
splitting it out later (when we know exactly how it will all look) should
not be a problem if that ends up making more sense.

 - why the fixed limit of 32 addresses? Shouldn't the default be to give
   out all possible addresses except for the server one.

This should be configurable, but until we have figure out the syntax I just
hard coded this to make it easy to test.

  [Match]
  Name=ve-arch-tree
 
  [Network]
  Address=192.168.12.5/24
  DHCPServer=yes
 
  [Route]
  Gateway=192.168.12.5
  Destination=192.168.12.0/24
 
  In this case we will configure ve-arch-tree with the address
192.168.12.5 and
  hand out addresses in the range 192.168.12.6 - 192.168.12.38.
 
  In the future, we should (as suggested by Lennart) introduce a syntax
to pick the
  server address automatically.
  ---
   src/network/networkd-link.c  | 101
++-
   src/network/networkd-network-gperf.gperf |   1 +
   src/network/networkd.h   |   5 ++
   3 files changed, 93 insertions(+), 14 deletions(-)
 
  diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
  index 6677b94..b80a002 100644
  --- a/src/network/networkd-link.c
  +++ b/src/network/networkd-link.c
  @@ -174,19 +174,6 @@ void link_drop(Link *link) {
   return;
   }
 
  -static int link_enter_configured(Link *link) {
  -assert(link);
  -assert(link-state == LINK_STATE_SETTING_ROUTES);
  -
  -log_info_link(link, link configured);
  -
  -link-state = LINK_STATE_CONFIGURED;
  -
  -link_save(link);
  -
  -return 0;
  -}
  -
   static void link_enter_unmanaged(Link *link) {
   assert(link);
 
  @@ -227,6 +214,16 @@ static int link_stop_clients(Link *link) {
   }
   }
 
  +if (link-network-dhcp_server) {
  +assert(link-dhcp_server);
  +
  +k = sd_dhcp_server_stop(link-dhcp_server);
  +if (k  0) {
  +log_warning_link(link, Could not stop DHCPv4
server: %s, strerror(-r));
  +r = k;
  +}
  +}
  +
   return r;
   }
 
  @@ -245,6 +242,37 @@ static void link_enter_failed(Link *link) {
   link_save(link);
   }
 
  +static int link_enter_configured(Link *link) {
  +int r;
  +
  +assert(link);
  +assert(link-network);
  +assert(link-state == LINK_STATE_SETTING_ROUTES);
  +
  +
  +if (link-network-dhcp_server) {
  +log_debug_link(link, offering DHCPv4 leases);
  +
  +r = sd_dhcp_server_start(link-dhcp_server);
  +if (r  0) {
  +log_warning_link(link, could not start DHCPv4
server 
  + instance: %s, strerror(-r));
  +
  +link_enter_failed(link);
  +
  +return 0;
  +}
  +}
  +
  +log_info_link(link, link configured);
  +
  +link-state = LINK_STATE_CONFIGURED;
  +
  +link_save(link);
  +
  +return 0;
  +}
  +
   static int route_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
   Link *link = userdata;
   int r;
  @@ -1663,7 +1691,52 @@ static int link_configure(Link *link) {
   }
   }
 
  -if (link_has_carrier(link-flags, link-kernel_operstate)) {
  +if (link-network-dhcp_server) {
  +Address *address;
  +
  +r = sd_dhcp_server_new(link-dhcp_server,
link-ifindex);
  +if (r  0)
  +return r;
  +
  +r = sd_dhcp_server_attach_event(link-dhcp_server,
NULL, 0);
  +if (r  0)
  +return r;
  +
  +LIST_FOREACH(addresses, address,
  + link-network-static_addresses) {
  +struct in_addr pool_start;
  +
  +if (address-family != AF_INET)
  +continue;
  +
  +/* currently this is picked essentially at
random */
  +

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Michael Biebl 
2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
 When enabled in [Network] it will set up a dhcp server on the interface, 
 listening
 on one of its statically configured IPv4 addresses and with a fixed size 
 pool of
 leases determined from it.
 Hi Tom,
 before looking at the code, a couple of general questions:
 - does the DHCP server have to be part of networkd? Isn't the job
   of acquiring addresses and giving out addresses separate and shouldn't
   two different processes be responsible?

I have to agree with Zbigniew here. This looks like feature creep.

Also, IIRC, the scope of networkd was to establish network connections
in a minimal environment, like an initramfs.
I'm pretty sure we don't need a DHCP server in a initramfs...

Cheers,
Michael


-- 
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
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Tom Gundersen 
On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote:
 2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
 When enabled in [Network] it will set up a dhcp server on the interface, 
 listening
 on one of its statically configured IPv4 addresses and with a fixed size 
 pool of
 leases determined from it.
 Hi Tom,
 before looking at the code, a couple of general questions:
 - does the DHCP server have to be part of networkd? Isn't the job
   of acquiring addresses and giving out addresses separate and shouldn't
   two different processes be responsible?

 I have to agree with Zbigniew here. This looks like feature creep.

As I already stated, if it turns out that things will be simpler with
this separate, we could easily make that change later. I do agree with
Marcel that that is unlikely though.

 Also, IIRC, the scope of networkd was to establish network connections
 in a minimal environment, like an initramfs.
 I'm pretty sure we don't need a DHCP server in a initramfs...

networkd should be usable in a minimal environment, like an initramfs.
However, we also target other simple setups like
virtualization/containers (inside and outside, which is what this
feature is mainly meant for).

Cheers,

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread David Herrmann 
Hi

On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote:
 2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 before looking at the code, a couple of general questions:
 - does the DHCP server have to be part of networkd? Isn't the job
   of acquiring addresses and giving out addresses separate and shouldn't
   two different processes be responsible?

 I have to agree with Zbigniew here. This looks like feature creep.

I strongly disagree. One major example is Wifi-P2P which requires a
DHCP-Server for ad-hoc P2P connections. A network-daemon manages the
local address-space, so it should also be responsible of assigning
those ranges to an ad-hoc DHCP server.

In most current network-solutions it is awfully hard to integrate
ad-hoc DHCP networks. Yes, everyone can configure a static
pre-assigned DHCP range, but that's not going to work with dynamically
created networks. This includes p2p-connections like Wifi-P2P, but
also stuff like tethering, virtual devices and containers.

Besides, the DHCP-server implementation isn't that much more complex
than the client-side. I mean ConnMan requires ~1000 lines for that, I
haven't looked at Toms patches so far, though. I'd really like to hear
why exactly you guys think this is feature-creep?

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Lennart Poettering 
On Tue, 27.05.14 13:39, David Herrmann (dh.herrm...@gmail.com) wrote:

 Hi
 
 On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote:
  2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
  before looking at the code, a couple of general questions:
  - does the DHCP server have to be part of networkd? Isn't the job
of acquiring addresses and giving out addresses separate and shouldn't
two different processes be responsible?
 
  I have to agree with Zbigniew here. This looks like feature creep.
 
 I strongly disagree. One major example is Wifi-P2P which requires a
 DHCP-Server for ad-hoc P2P connections. A network-daemon manages the
 local address-space, so it should also be responsible of assigning
 those ranges to an ad-hoc DHCP server.
 
 In most current network-solutions it is awfully hard to integrate
 ad-hoc DHCP networks. Yes, everyone can configure a static
 pre-assigned DHCP range, but that's not going to work with dynamically
 created networks. This includes p2p-connections like Wifi-P2P, but
 also stuff like tethering, virtual devices and containers.
 
 Besides, the DHCP-server implementation isn't that much more complex

 than the client-side. I mean ConnMan requires ~1000 lines for that, I
 haven't looked at Toms patches so far, though. I'd really like to hear
 why exactly you guys think this is feature-creep?

Fully agree.

In many ways, if people complain about a dhcp server in networkd, then
it's like complaining about the fact that pppd also can assign addresses
to the other side...

Michael, Cristian, I don't see you complaining about the IP assigning
bits in pppd either!  ;-)

If we set up links (and especially, create them like
we do for veth), then hel, yeah we should be prepared to make sure
everybody gets an address on it. 

Lennart

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

[systemd-devel] [PATCH] units: use KillMode=process for systemd-nspawn@.service

2014-05-27 Thread Jonathan Liu 
This causes the container to shut down cleanly when the service is
stopped.
---
 units/systemd-nsp...@.service.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/units/systemd-nsp...@.service.in b/units/systemd-nsp...@.service.in
index ff36e90..6228345 100644
--- a/units/systemd-nsp...@.service.in
+++ b/units/systemd-nsp...@.service.in
@@ -11,6 +11,7 @@ Documentation=man:systemd-nspawn(1)
 
 [Service]
 ExecStart=@bindir@/systemd-nspawn --quiet --keep-unit --boot 
--link-journal=guest --directory=/var/lib/container/%i
+KillMode=process
 Type=notify
 
 [Install]
-- 
1.9.3

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Michael Biebl 
2014-05-27 14:00 GMT+02:00 Lennart Poettering lenn...@poettering.net:

 In many ways, if people complain about a dhcp server in networkd, then
 it's like complaining about the fact that pppd also can assign addresses
 to the other side...

I don't see pppd implementing a DHCP server.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts.

2014-05-27 Thread Harald Hoyer 
On 21.05.2014 10:03, Lennart Poettering wrote:
 On Sun, 18.05.14 19:36, Przemek Rudy (pru...@o2.pl) wrote:
 
 diff --git a/src/core/automount.c b/src/core/automount.c
 index 65e6d6f..d4359b9 100644
 --- a/src/core/automount.c
 +++ b/src/core/automount.c
 @@ -124,7 +124,7 @@ static int automount_add_mount_links(Automount *a) {
  if (r  0)
  return r;
  
 -return unit_require_mounts_for(UNIT(a), parent);
 +return unit_needs_mounts_for(UNIT(a), parent, true);
  }
  
 
 Please make the the last parameter one of type UnitDependency, so that
 one can either pass UNIT_WANTS or UNIT_REQUIRES there. THat makes the
 calls much more descriptive, as well as more generic.
 
 Otherwise looks pretty good!
 
 Lennart
 

Hmm, I might see a problem in the initramfs, where devices show up bit by bit.
The user might then be confronted with the password dialog, although the device
with the key file will show up a little bit later.

But I might be wrong. Time will tell.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Tollef Fog Heen 
]] Lennart Poettering 

 If we set up links (and especially, create them like
 we do for veth), then hel, yeah we should be prepared to make sure
 everybody gets an address on it. 

Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to
make sure it's possible to push routes?  I take DHCPv6 and IPv6 RA are a
given that'll be implemented.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Running a systemd service in capability-only environment as non-root user

2014-05-27 Thread Michal Witanowski 

Hi,

first of all I'd like to mark that I'm not sure if I'm writing in the 
right place.


I have a problem with running a systemd service in capability-only 
environment: I want to run a process with some caps (cap_sys_admin 
cap_dac_override cap_mac_override) as a regular user (UID != 0).

My service config file looks something like this:

   User=test
   CapabilityBoundingSet=cap_sys_admin cap_dac_override cap_mac_override
   Capabilities=cap_sys_admin,cap_dac_override,cap_mac_override=eip
   SecureBits=keep-caps

Unfortunately, the process does not gain any permissive capabilities:

   CapInh: 00010022
   CapPrm: 
   CapEff: 
   CapBnd: 00010022

However, when I run the service as root (by removing User=test) the 
process does own required caps:


   CapInh: 00010022
   CapPrm: 00010022
   CapEff: 00010022
   CapBnd: 00010022

It looks like the SecureBits=keep-caps option, which should preserve 
permissive caps after root drop according to [1], does not work. Am I 
doing something wrong?


Any response would be very helpful.

Best Regards,
Michal Witanowski

[1] http://linux.die.net/man/7/capabilities
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Eelco Dolstra 
Hi,

On 27/05/14 13:50, Lennart Poettering wrote:

 On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
 When enabled in [Network] it will set up a dhcp server on the interface, 
 listening
 on one of its statically configured IPv4 addresses and with a fixed size 
 pool of
 leases determined from it.
 Hi Tom,
 before looking at the code, a couple of general questions:
 - does the DHCP server have to be part of networkd? Isn't the job
   of acquiring addresses and giving out addresses separate and
   shouldn't
   two different processes be responsible?
 
 I am very sure this should be in networkd. 
[snip]

That sounds reasonable. However, to be honest, I've never really understood why
networkd needs to be part of systemd in the first place. It seems to me that it
would work just as well as a separate package with its own releases. To me as a
downstream that would be preferable, since such a package can be upgraded
(mostly) independently from systemd. For instance, in NixOS we can upgrade
dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system;
but getting the latest networkd would require getting the latest systemd, which
is typically a much bigger step since it potentially impacts much more of the
system.

You often point out (correctly) that systemd is not monolithic as it consists of
dozens of separate programs. But it *is* a monolithic package: those dozens of
programs can only be upgraded as a set.

 Remember that the goal here is not to write another ldap enabled
 monstrosity. 

A package becomes a monstrosity one small feature at a time. (And one person's
bloat is another person's essential feature.) For instance, networkd currently
lacks a WPA supplicant, which you surely need in a modern system. So should
systemd accrete a WPA supplicant? How about Bluetooth support? Etc. etc. I mean,
is there any concrete criterion about what should or shouldn't go into systemd?

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] handling mount failure in initramfs context

2014-05-27 Thread Vivek Goyal 
On Mon, May 26, 2014 at 04:12:56PM +0800, WANG Chao wrote:
 Hi, all
 
 In a pure initramfs enviroment, I want to mount a filesystem and I put
 an mount entry in /etc/fstab, so that fstab-generator could generate a
 mount unit and systemd will mount it at some time.
 
 I have a question about mount failure in such case:
 
 How can I make sure that upon a mount failure, systemd would stop
 booting and switch to emergency handling?

I will give little more context to the problem at hand.

So kdump uses --mount option of dracut to mount file systems in initramfs
context. dracut puts right values in /etc/fstab of initramfs which in
turn are parsed by systemd and mount units are generated.

Now question is what will happen if one of the mount failed? I think
currently systemd does not drop us to emergency shell and instead
continues to boot.

We are trying to figure out how to change this behavior where we can
tell systemd to drop into an emergency shell instead.

I think Chao used x-initrd.mount option as mount option and that changes
the behavior. With this option the mount unit becomes required by
initrd-root-fs.target rather than it used to be local-fs.target. And
the way these targets are configured, we drop into emergency shell with
other untis isolated.

Point being that usage of x-initrd.mount to achieve the desired behavior
sounded hackish to me. Nowhere systemd guarantees that usage of this 
option will ensure certain dependencies. I think this option just means
that file system will be mounted in initramfs.

So is there a better way to achieve what we are looking for.

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Cristian Rodríguez 

El 27/05/14 10:04, Eelco Dolstra escribió:
¿

That sounds reasonable. However, to be honest, I've never really understood why
networkd needs to be part of systemd in the first place.



For the start, to share a large amount code..

It seems to me that it

would work just as well as a separate package with its own releases.


That's a bad idea.. it will only cause it to grow in size, increase 
complexity etc.etc.



You often point out (correctly) that systemd is not monolithic as it consists of
dozens of separate programs. But it *is* a monolithic package: those dozens of
programs can only be upgraded as a set.


That's not true. I am running timesyncd with systemd 210.. of course 
that requires to know what you are doing.


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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Cristian Rodríguez 
El 27/05/14 07:39, David Herrmann escribió:

 I strongly disagree. One major example is Wifi-P2P which requires a
 DHCP-Server for ad-hoc P2P connections. 

OOk. that convinced me, thanks..


-- 
Cristian
I don't know the key to success, but the key to failure is trying to
please everybody.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Tom Gundersen 
On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heen tfh...@err.no wrote:
 ]] Lennart Poettering

 If we set up links (and especially, create them like
 we do for veth), then hel, yeah we should be prepared to make sure
 everybody gets an address on it.

 Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to
 make sure it's possible to push routes?

The sarcasm is not lost on me, but just for the record, I'd say those
are out-of-scope.

 I take DHCPv6 and IPv6 RA are a
 given that'll be implemented.

The client side is mostly done (by Patrik). If you are interested in
working on the server-side, do get in touch so we can coordinate the
efforts.

Cheers,

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

Re: [systemd-devel] [PATCH 08/17] sd-dhcp-server: add support for setting the server address

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, May 26, 2014 at 09:39:37PM +0200, Tom Gundersen wrote:
 ---
  src/libsystemd-network/dhcp-server-internal.h |  1 +
  src/libsystemd-network/sd-dhcp-server.c   | 13 +
  src/libsystemd-network/test-dhcp-server.c | 17 +
  src/systemd/sd-dhcp-server.h  |  1 +
  4 files changed, 32 insertions(+)
 
 diff --git a/src/libsystemd-network/dhcp-server-internal.h 
 b/src/libsystemd-network/dhcp-server-internal.h
 index 6c2f2b4..58a9877 100644
 --- a/src/libsystemd-network/dhcp-server-internal.h
 +++ b/src/libsystemd-network/dhcp-server-internal.h
 @@ -39,6 +39,7 @@ struct sd_dhcp_server {
  int fd_raw;
  
  int index;
 +be32_t address;
  };
  
  typedef struct DHCPClientId {
 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index ecdc15d..7d6170c 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -27,6 +27,17 @@
  #include dhcp-server-internal.h
  #include dhcp-internal.h
  
 +int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address) {
 +assert_return(server, -EINVAL);
 +assert_return(address, -EINVAL);
 +assert_return(address-s_addr, -EINVAL);
 +assert_return(server-address == htobe32(INADDR_ANY), -EBUSY);
 +
 +server-address = address-s_addr;
 +
 +return 0;
 +}
 +
  sd_dhcp_server *sd_dhcp_server_ref(sd_dhcp_server *server) {
  if (server)
  assert_se(REFCNT_INC(server-n_ref) = 2);
 @@ -60,6 +71,7 @@ int sd_dhcp_server_new(sd_dhcp_server **ret, int ifindex) {
  server-n_ref = REFCNT_INIT;
  server-fd_raw = -1;
  server-fd = -1;
 +server-address = htobe32(INADDR_ANY);
  server-index = ifindex;
  
  *ret = server;
 @@ -281,6 +293,7 @@ int sd_dhcp_server_start(sd_dhcp_server *server) {
  assert_return(!server-receive_message, -EBUSY);
  assert_return(server-fd_raw == -1, -EBUSY);
  assert_return(server-fd == -1, -EBUSY);
 +assert_return(server-address != htobe32(INADDR_ANY), -EBUSY);

EBUSY seems rather confusing here, since actually the opposite is
true, for this newly added check as well for the preexisting ones:
the structure has not been initialized to be usable yet. Maybe a
different error code like EUNATCH or EBADRQC, ENODATA, EDESTADDRREQ or
EUCLEAN ?
  
  r = socket(AF_PACKET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
  if (r  0) {
 diff --git a/src/libsystemd-network/test-dhcp-server.c 
 b/src/libsystemd-network/test-dhcp-server.c
 index dd0f29a..0cbb4df 100644
 --- a/src/libsystemd-network/test-dhcp-server.c
 +++ b/src/libsystemd-network/test-dhcp-server.c
 @@ -32,6 +32,12 @@
  
  static void test_basic(sd_event *event) {
  _cleanup_dhcp_server_unref_ sd_dhcp_server *server = NULL;
 +struct in_addr address_lo = {
 +.s_addr = htonl(INADDR_LOOPBACK),
 +};
 +struct in_addr address_any = {
 +.s_addr = htonl(INADDR_ANY),
 +};
  
  /* attach to loopback interface */
  assert_se(sd_dhcp_server_new(server, 1) = 0);
 @@ -48,6 +54,11 @@ static void test_basic(sd_event *event) {
  assert_se(sd_dhcp_server_ref(server) == server);
  assert_se(!sd_dhcp_server_unref(server));
  
 +assert_se(sd_dhcp_server_start(server) == -EBUSY);
 +assert_se(sd_dhcp_server_set_address(server, address_any) == 
 -EINVAL);
 +assert_se(sd_dhcp_server_set_address(server, address_lo) = 0);
 +assert_se(sd_dhcp_server_set_address(server, address_lo) == -EBUSY);
 +
  assert_se(sd_dhcp_server_start(server) = 0);
  assert_se(sd_dhcp_server_start(server) == -EBUSY);
  assert_se(sd_dhcp_server_stop(server) = 0);
 @@ -74,8 +85,14 @@ static void test_message_handler(void) {
  .option_type.type = DHCP_DISCOVER,
  .end = DHCP_OPTION_END,
  };
 +struct in_addr address_lo = {
 +.s_addr = htonl(INADDR_LOOPBACK),
 +};
  
  assert_se(sd_dhcp_server_new(server, 1) = 0);
 +assert_se(sd_dhcp_server_set_address(server, address_lo) = 0);
 +assert_se(sd_dhcp_server_attach_event(server, NULL, 0) = 0);
 +assert_se(sd_dhcp_server_start(server) = 0);
  
  assert_se(dhcp_server_handle_message(server, (DHCPMessage*)test, 
 sizeof(test)) == 1);
  
 diff --git a/src/systemd/sd-dhcp-server.h b/src/systemd/sd-dhcp-server.h
 index ab63294..5edeffc 100644
 --- a/src/systemd/sd-dhcp-server.h
 +++ b/src/systemd/sd-dhcp-server.h
 @@ -41,4 +41,5 @@ sd_event *sd_dhcp_server_get_event(sd_dhcp_server *client);
  int sd_dhcp_server_start(sd_dhcp_server *server);
  int sd_dhcp_server_stop(sd_dhcp_server *server);
  
 +int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address);
  #endif

Zbyszek

[systemd-devel] [PATCH] unit: make unit can start without instance

2014-05-27 Thread WaLyong Cho 
I'm not sure this could be patch for below TODO.

* enabling an instance unit creates a pointless link, and
  the unit will be started with getty@getty.service:
$ systemctl enable getty@.service
ln -s '/usr/lib/systemd/system/getty@.service' 
'/etc/systemd/system/getty.target.wants/getty@.service'

If can be, when this can be used?
And I couldn't avoid one of strdup in manager_load_unit_prepare(). And
I wasn't able to make a suit name better than instanceless.

WaLyong Cho (1):
  unit: make unit can start without instance

 src/core/manager.c | 10 ++
 src/shared/unit-name.c | 12 
 src/shared/unit-name.h |  1 +
 3 files changed, 19 insertions(+), 4 deletions(-)

-- 
1.9.3

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

[systemd-devel] [PATCH] unit: make unit can start without instance

2014-05-27 Thread WaLyong Cho 
---
 src/core/manager.c | 10 ++
 src/shared/unit-name.c | 12 
 src/shared/unit-name.h |  1 +
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/core/manager.c b/src/core/manager.c
index 0cb2044..089df43 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1163,6 +1163,7 @@ int manager_load_unit_prepare(
 Unit *ret;
 UnitType t;
 int r;
+_cleanup_free_ char *n = NULL;
 
 assert(m);
 assert(name || path);
@@ -1177,11 +1178,12 @@ int manager_load_unit_prepare(
 name = basename(path);
 
 t = unit_name_to_type(name);
+n = unit_name_from_instanceless(name);
 
-if (t == _UNIT_TYPE_INVALID || !unit_name_is_valid(name, 
TEMPLATE_INVALID))
-return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, Unit 
name %s is not valid., name);
+if (t == _UNIT_TYPE_INVALID || !unit_name_is_valid(n, 
TEMPLATE_INVALID))
+return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, Unit 
name %s is not valid., n);
 
-ret = manager_get_unit(m, name);
+ret = manager_get_unit(m, n);
 if (ret) {
 *_ret = ret;
 return 1;
@@ -1199,7 +1201,7 @@ int manager_load_unit_prepare(
 }
 }
 
-r = unit_add_name(ret, name);
+r = unit_add_name(ret, n);
 if (r  0) {
 unit_free(ret);
 return r;
diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
index 6c167b4..c5584b5 100644
--- a/src/shared/unit-name.c
+++ b/src/shared/unit-name.c
@@ -431,6 +431,18 @@ char *unit_name_from_path_instance(const char *prefix, 
const char *path, const c
 return strjoin(prefix, @, p, suffix, NULL);
 }
 
+char *unit_name_from_instanceless(const char *name) {
+_cleanup_free_ char *i = NULL;
+
+assert(name);
+
+if (unit_name_is_template(name)) {
+i = unit_name_to_prefix(name);
+return unit_name_replace_instance(name, i);
+} else
+return strdup(name);
+}
+
 char *unit_name_to_path(const char *name) {
 _cleanup_free_ char *w = NULL;
 
diff --git a/src/shared/unit-name.h b/src/shared/unit-name.h
index d06d2b2..1251b18 100644
--- a/src/shared/unit-name.h
+++ b/src/shared/unit-name.h
@@ -98,6 +98,7 @@ char *unit_name_template(const char *f);
 
 char *unit_name_from_path(const char *path, const char *suffix);
 char *unit_name_from_path_instance(const char *prefix, const char *path, const 
char *suffix);
+char *unit_name_from_instanceless(const char *name);
 char *unit_name_to_path(const char *name);
 
 char *unit_dbus_path_from_name(const char *name);
-- 
1.9.3

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Tollef Fog Heen 
]] Tom Gundersen 

 On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heen tfh...@err.no wrote:
  ]] Lennart Poettering
 
  If we set up links (and especially, create them like
  we do for veth), then hel, yeah we should be prepared to make sure
  everybody gets an address on it.
 
  Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to
  make sure it's possible to push routes?
 
 The sarcasm is not lost on me, but just for the record, I'd say those
 are out-of-scope.

I'm actually both sarcastic and serious.  Almost all the machines I
manage have full BGP tables and run routing daemons.

  I take DHCPv6 and IPv6 RA are a
  given that'll be implemented.
 
 The client side is mostly done (by Patrik). If you are interested in
 working on the server-side, do get in touch so we can coordinate the
 efforts.

I currently don't have time for this, I'm afraid.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 10/17] sd-dhcp-server: add basic DISCOVER/OFFER support

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, May 26, 2014 at 09:39:39PM +0200, Tom Gundersen wrote:
 ---
  src/libsystemd-network/sd-dhcp-server.c   | 81 
 ++-
  src/libsystemd-network/test-dhcp-server.c | 14 +++---
  2 files changed, 86 insertions(+), 9 deletions(-)
 
 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index cea7390..be6938b 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -27,6 +27,8 @@
  #include dhcp-server-internal.h
  #include dhcp-internal.h
  
 +#define DHCP_DEFAULT_LEASE_TIME 60
 +
  int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address) {
  assert_return(server, -EINVAL);
  assert_return(address, -EINVAL);
 @@ -277,6 +279,64 @@ int dhcp_server_send_packet(sd_dhcp_server *server,
  sizeof(DHCPPacket) + 
 optoffset);
  }
  
 +static int server_message_init(sd_dhcp_server *server, DHCPPacket **ret,
 +   uint8_t type, size_t *_optoffset, DHCPRequest 
 *req) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t optoffset;
 +int r;
 +
 +assert(server);
 +assert(ret);
 +assert(_optoffset);
 +assert(type == DHCP_OFFER);
 +
 +packet = malloc0(sizeof(DHCPPacket) + req-max_optlen);
 +if (!packet)
 +return -ENOMEM;
 +
 +r = dhcp_message_init(packet-dhcp, BOOTREPLY, 
 be32toh(req-message-xid),
 +  type, req-max_optlen, optoffset);
 +if (r  0)
 +return r;
 +
 +packet-dhcp.flags = req-message-flags;
 +packet-dhcp.giaddr = req-message-giaddr;
 +memcpy(packet-dhcp.chaddr, req-message-chaddr, ETH_ALEN);
 +
 +*_optoffset = optoffset;
 +*ret = packet;
 +packet = NULL;
 +
 +return 0;
 +}
 +
 +static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t offset;
 +be32_t lease_time;
 +int r;
 +
 +r = server_message_init(server, packet, DHCP_OFFER, offset, req);
 +if (r  0)
 +return r;
 +
 +/* for now offer a random IP */
 +packet-dhcp.yiaddr = random_u32();
 +
 +/* for ten seconds */
The comment appears to be out of date already, it's 60 :)

 +lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 +r = dhcp_option_append(packet-dhcp, req-max_optlen, offset, 0,
 +   DHCP_OPTION_IP_ADDRESS_LEASE_TIME, 4, 
 lease_time);
 +if (r  0)
 +return r;
 +
 +r = dhcp_server_send_packet(server, req, packet, DHCP_OFFER, offset);
 +if (r  0)
 +return r;
 +
 +return 0;
 +}
 +
  static int parse_request(uint8_t code, uint8_t len, const uint8_t *option,
   void *user_data) {
  DHCPRequest *req = user_data;
 @@ -377,9 +437,26 @@ int dhcp_server_handle_message(sd_dhcp_server *server, 
 DHCPMessage *message,
  /* this only fails on critical errors */
  return r;
  
 -log_dhcp_server(server, received message of type %d, type);
 +switch(type) {
 +case DHCP_DISCOVER:
 +log_dhcp_server(server, DISCOVER (0x%x),
 +be32toh(req-message-xid));
 +
 +r = server_send_offer(server, req);
 +if (r  0) {
 +log_dhcp_server(server, could not send offer: %s,
 +strerror(-r));
The error is logged at debug level, but otherwise ignored. Is this enough? It 
seems that if
server_send_offer() fails, things are significantly off.

 +return 0;
 +} else {
 +log_dhcp_server(server, OFFER (0x%x),
 +be32toh(req-message-xid));
 +return DHCP_OFFER;
 +}
 +
 +break;
 +}
  
 -return 1;
 +return 0;
  }
  
  static int server_receive_message(sd_event_source *s, int fd,
 diff --git a/src/libsystemd-network/test-dhcp-server.c 
 b/src/libsystemd-network/test-dhcp-server.c
 index 0cbb4df..ed3aaf9 100644
 --- a/src/libsystemd-network/test-dhcp-server.c
 +++ b/src/libsystemd-network/test-dhcp-server.c
 @@ -94,13 +94,13 @@ static void test_message_handler(void) {
  assert_se(sd_dhcp_server_attach_event(server, NULL, 0) = 0);
  assert_se(sd_dhcp_server_start(server) = 0);
  
 -assert_se(dhcp_server_handle_message(server, (DHCPMessage*)test, 
 sizeof(test)) == 1);
 +assert_se(dhcp_server_handle_message(server, (DHCPMessage*)test, 
 sizeof(test)) == DHCP_OFFER);
  
  test.end = 0;
  /* TODO, shouldn't this fail? */
 -

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Jóhann B. Guðmundsson 


On 05/27/2014 03:20 PM, Tom Gundersen wrote:

On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heentfh...@err.no  wrote:

]] Lennart Poettering


If we set up links (and especially, create them like
we do for veth), then hel, yeah we should be prepared to make sure
everybody gets an address on it.


Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to
make sure it's possible to push routes?

The sarcasm is not lost on me, but just for the record, I'd say those
are out-of-scope.



I would beg the differ you will need this to be able to properly support 
containers, isolating them to their own vlans etc.


I would have gone the route of implementing this into a separated 
systemd network server ( optionally being hidden from the network itself 
for security reasons which is required ) and have networkd tightly 
integrated and communicate with that server but you seem to be wanting 
to integrate all of this into networkd which does not lessen the 
requirements just complicates configuring them a bit more.


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

Re: [systemd-devel] [PATCH 11/17] sd-dhcp-server: add basic REQUEST/ACK support

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, May 26, 2014 at 09:39:40PM +0200, Tom Gundersen wrote:
 ---
  src/libsystemd-network/dhcp-server-internal.h |   3 +
  src/libsystemd-network/sd-dhcp-server.c   | 135 
 +-
  src/libsystemd-network/test-dhcp-server.c |  37 +++
  src/systemd/sd-dhcp-server.h  |   1 +
  4 files changed, 171 insertions(+), 5 deletions(-)
 
 diff --git a/src/libsystemd-network/dhcp-server-internal.h 
 b/src/libsystemd-network/dhcp-server-internal.h
 index 381304e..cd480e7 100644
 --- a/src/libsystemd-network/dhcp-server-internal.h
 +++ b/src/libsystemd-network/dhcp-server-internal.h
 @@ -40,6 +40,8 @@ struct sd_dhcp_server {
  
  int index;
  be32_t address;
 +be32_t pool_start;
 +size_t pool_size;
  };
  
  typedef struct DHCPClientId {
 @@ -55,6 +57,7 @@ typedef struct DHCPRequest {
  DHCPClientId client_id;
  size_t max_optlen;
  be32_t server_id;
 +be32_t requested_ip;
  } DHCPRequest;
  
  DEFINE_TRIVIAL_CLEANUP_FUNC(sd_dhcp_server*, sd_dhcp_server_unref);
 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index be6938b..01cd8be 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -29,6 +29,21 @@
  
  #define DHCP_DEFAULT_LEASE_TIME 60
  
 +int sd_dhcp_server_set_lease_pool(sd_dhcp_server *server, struct in_addr 
 *address,
 +  size_t size) {
 +assert_return(server, -EINVAL);
 +assert_return(address, -EINVAL);
 +assert_return(address-s_addr, -EINVAL);
 +assert_return(size, -EINVAL);
 +assert_return(server-pool_start == htobe32(INADDR_ANY), -EBUSY);
 +assert_return(!server-pool_size, -EBUSY);
 +
 +server-pool_start = address-s_addr;
 +server-pool_size = size;
 +
 +return 0;
 +}
 +
  int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address) {
  assert_return(server, -EINVAL);
  assert_return(address, -EINVAL);
 @@ -288,7 +303,7 @@ static int server_message_init(sd_dhcp_server *server, 
 DHCPPacket **ret,
  assert(server);
  assert(ret);
  assert(_optoffset);
 -assert(type == DHCP_OFFER);
 +assert(IN_SET(type, DHCP_OFFER, DHCP_ACK));
  
  packet = malloc0(sizeof(DHCPPacket) + req-max_optlen);
  if (!packet)
 @@ -310,7 +325,7 @@ static int server_message_init(sd_dhcp_server *server, 
 DHCPPacket **ret,
  return 0;
  }
  
 -static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req) {
 +static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req, 
 be32_t address) {
  _cleanup_free_ DHCPPacket *packet = NULL;
  size_t offset;
  be32_t lease_time;
 @@ -320,8 +335,7 @@ static int server_send_offer(sd_dhcp_server *server, 
 DHCPRequest *req) {
  if (r  0)
  return r;
  
 -/* for now offer a random IP */
 -packet-dhcp.yiaddr = random_u32();
 +packet-dhcp.yiaddr = address;
  
  /* for ten seconds */
  lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 @@ -337,6 +351,32 @@ static int server_send_offer(sd_dhcp_server *server, 
 DHCPRequest *req) {
  return 0;
  }
  
 +static int server_send_ack(sd_dhcp_server *server, DHCPRequest *req, be32_t 
 address) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t offset;
 +be32_t lease_time;
 +int r;
 +
 +r = server_message_init(server, packet, DHCP_ACK, offset, req);
 +if (r  0)
 +return r;
 +
 +packet-dhcp.yiaddr = address;
 +
 +/* for ten seconds */
 +lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 +r = dhcp_option_append(packet-dhcp, req-max_optlen, offset, 0,
 +   DHCP_OPTION_IP_ADDRESS_LEASE_TIME, 4, 
 lease_time);
 +if (r  0)
 +return r;
 +
 +r = dhcp_server_send_packet(server, req, packet, DHCP_ACK, offset);
 +if (r  0)
 +return r;
 +
 +return 0;
 +}
 +
  static int parse_request(uint8_t code, uint8_t len, const uint8_t *option,
   void *user_data) {
  DHCPRequest *req = user_data;
 @@ -344,6 +384,11 @@ static int parse_request(uint8_t code, uint8_t len, 
 const uint8_t *option,
  assert(req);
  
  switch(code) {
 +case DHCP_OPTION_REQUESTED_IP_ADDRESS:
 +if (len == 4)
 +req-requested_ip = *(be32_t*)option;
 +
 +break;
  case DHCP_OPTION_SERVER_IDENTIFIER:
  if (len == 4)
  req-server_id = *(be32_t*)option;
 @@ -439,10 +484,21 @@ int dhcp_server_handle_message(sd_dhcp_server *server, 
 DHCPMessage *message,
  
  switch(type) {
  case DHCP_DISCOVER:
 +{
 +

Re: [systemd-devel] [PATCH 11/17] sd-dhcp-server: add basic REQUEST/ACK support

2014-05-27 Thread Tom Gundersen 
On Tue, May 27, 2014 at 5:48 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, May 26, 2014 at 09:39:40PM +0200, Tom Gundersen wrote:
 ---
  src/libsystemd-network/dhcp-server-internal.h |   3 +
  src/libsystemd-network/sd-dhcp-server.c   | 135 
 +-
  src/libsystemd-network/test-dhcp-server.c |  37 +++
  src/systemd/sd-dhcp-server.h  |   1 +
  4 files changed, 171 insertions(+), 5 deletions(-)

 diff --git a/src/libsystemd-network/dhcp-server-internal.h 
 b/src/libsystemd-network/dhcp-server-internal.h
 index 381304e..cd480e7 100644
 --- a/src/libsystemd-network/dhcp-server-internal.h
 +++ b/src/libsystemd-network/dhcp-server-internal.h
 @@ -40,6 +40,8 @@ struct sd_dhcp_server {

  int index;
  be32_t address;
 +be32_t pool_start;
 +size_t pool_size;
  };

  typedef struct DHCPClientId {
 @@ -55,6 +57,7 @@ typedef struct DHCPRequest {
  DHCPClientId client_id;
  size_t max_optlen;
  be32_t server_id;
 +be32_t requested_ip;
  } DHCPRequest;

  DEFINE_TRIVIAL_CLEANUP_FUNC(sd_dhcp_server*, sd_dhcp_server_unref);
 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index be6938b..01cd8be 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -29,6 +29,21 @@

  #define DHCP_DEFAULT_LEASE_TIME 60

 +int sd_dhcp_server_set_lease_pool(sd_dhcp_server *server, struct in_addr 
 *address,
 +  size_t size) {
 +assert_return(server, -EINVAL);
 +assert_return(address, -EINVAL);
 +assert_return(address-s_addr, -EINVAL);
 +assert_return(size, -EINVAL);
 +assert_return(server-pool_start == htobe32(INADDR_ANY), -EBUSY);
 +assert_return(!server-pool_size, -EBUSY);
 +
 +server-pool_start = address-s_addr;
 +server-pool_size = size;
 +
 +return 0;
 +}
 +
  int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address) {
  assert_return(server, -EINVAL);
  assert_return(address, -EINVAL);
 @@ -288,7 +303,7 @@ static int server_message_init(sd_dhcp_server *server, 
 DHCPPacket **ret,
  assert(server);
  assert(ret);
  assert(_optoffset);
 -assert(type == DHCP_OFFER);
 +assert(IN_SET(type, DHCP_OFFER, DHCP_ACK));

  packet = malloc0(sizeof(DHCPPacket) + req-max_optlen);
  if (!packet)
 @@ -310,7 +325,7 @@ static int server_message_init(sd_dhcp_server *server, 
 DHCPPacket **ret,
  return 0;
  }

 -static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req) {
 +static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req, 
 be32_t address) {
  _cleanup_free_ DHCPPacket *packet = NULL;
  size_t offset;
  be32_t lease_time;
 @@ -320,8 +335,7 @@ static int server_send_offer(sd_dhcp_server *server, 
 DHCPRequest *req) {
  if (r  0)
  return r;

 -/* for now offer a random IP */
 -packet-dhcp.yiaddr = random_u32();
 +packet-dhcp.yiaddr = address;

  /* for ten seconds */
  lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 @@ -337,6 +351,32 @@ static int server_send_offer(sd_dhcp_server *server, 
 DHCPRequest *req) {
  return 0;
  }

 +static int server_send_ack(sd_dhcp_server *server, DHCPRequest *req, be32_t 
 address) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t offset;
 +be32_t lease_time;
 +int r;
 +
 +r = server_message_init(server, packet, DHCP_ACK, offset, req);
 +if (r  0)
 +return r;
 +
 +packet-dhcp.yiaddr = address;
 +
 +/* for ten seconds */
 +lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 +r = dhcp_option_append(packet-dhcp, req-max_optlen, offset, 0,
 +   DHCP_OPTION_IP_ADDRESS_LEASE_TIME, 4, 
 lease_time);
 +if (r  0)
 +return r;
 +
 +r = dhcp_server_send_packet(server, req, packet, DHCP_ACK, offset);
 +if (r  0)
 +return r;
 +
 +return 0;
 +}
 +
  static int parse_request(uint8_t code, uint8_t len, const uint8_t *option,
   void *user_data) {
  DHCPRequest *req = user_data;
 @@ -344,6 +384,11 @@ static int parse_request(uint8_t code, uint8_t len, 
 const uint8_t *option,
  assert(req);

  switch(code) {
 +case DHCP_OPTION_REQUESTED_IP_ADDRESS:
 +if (len == 4)
 +req-requested_ip = *(be32_t*)option;
 +
 +break;
  case DHCP_OPTION_SERVER_IDENTIFIER:
  if (len == 4)
  req-server_id = *(be32_t*)option;
 @@ -439,10 +484,21 @@ int dhcp_server_handle_message(sd_dhcp_server *server, 
 DHCPMessage *message,

  switch(type) {

Re: [systemd-devel] [PATCH 10/17] sd-dhcp-server: add basic DISCOVER/OFFER support

2014-05-27 Thread Tom Gundersen 
On Tue, May 27, 2014 at 5:41 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Mon, May 26, 2014 at 09:39:39PM +0200, Tom Gundersen wrote:
 ---
  src/libsystemd-network/sd-dhcp-server.c   | 81 
 ++-
  src/libsystemd-network/test-dhcp-server.c | 14 +++---
  2 files changed, 86 insertions(+), 9 deletions(-)

 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index cea7390..be6938b 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -27,6 +27,8 @@
  #include dhcp-server-internal.h
  #include dhcp-internal.h

 +#define DHCP_DEFAULT_LEASE_TIME 60
 +
  int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
 *address) {
  assert_return(server, -EINVAL);
  assert_return(address, -EINVAL);
 @@ -277,6 +279,64 @@ int dhcp_server_send_packet(sd_dhcp_server *server,
  sizeof(DHCPPacket) + 
 optoffset);
  }

 +static int server_message_init(sd_dhcp_server *server, DHCPPacket **ret,
 +   uint8_t type, size_t *_optoffset, 
 DHCPRequest *req) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t optoffset;
 +int r;
 +
 +assert(server);
 +assert(ret);
 +assert(_optoffset);
 +assert(type == DHCP_OFFER);
 +
 +packet = malloc0(sizeof(DHCPPacket) + req-max_optlen);
 +if (!packet)
 +return -ENOMEM;
 +
 +r = dhcp_message_init(packet-dhcp, BOOTREPLY, 
 be32toh(req-message-xid),
 +  type, req-max_optlen, optoffset);
 +if (r  0)
 +return r;
 +
 +packet-dhcp.flags = req-message-flags;
 +packet-dhcp.giaddr = req-message-giaddr;
 +memcpy(packet-dhcp.chaddr, req-message-chaddr, ETH_ALEN);
 +
 +*_optoffset = optoffset;
 +*ret = packet;
 +packet = NULL;
 +
 +return 0;
 +}
 +
 +static int server_send_offer(sd_dhcp_server *server, DHCPRequest *req) {
 +_cleanup_free_ DHCPPacket *packet = NULL;
 +size_t offset;
 +be32_t lease_time;
 +int r;
 +
 +r = server_message_init(server, packet, DHCP_OFFER, offset, req);
 +if (r  0)
 +return r;
 +
 +/* for now offer a random IP */
 +packet-dhcp.yiaddr = random_u32();
 +
 +/* for ten seconds */
 The comment appears to be out of date already, it's 60 :)

Ha, indeed. I started out with 10 seconds, but watching wireshark was
not possible at that speed :)

 +lease_time = htobe32(DHCP_DEFAULT_LEASE_TIME);
 +r = dhcp_option_append(packet-dhcp, req-max_optlen, offset, 0,
 +   DHCP_OPTION_IP_ADDRESS_LEASE_TIME, 4, 
 lease_time);
 +if (r  0)
 +return r;
 +
 +r = dhcp_server_send_packet(server, req, packet, DHCP_OFFER, 
 offset);
 +if (r  0)
 +return r;
 +
 +return 0;
 +}
 +
  static int parse_request(uint8_t code, uint8_t len, const uint8_t *option,
   void *user_data) {
  DHCPRequest *req = user_data;
 @@ -377,9 +437,26 @@ int dhcp_server_handle_message(sd_dhcp_server *server, 
 DHCPMessage *message,
  /* this only fails on critical errors */
  return r;

 -log_dhcp_server(server, received message of type %d, type);
 +switch(type) {
 +case DHCP_DISCOVER:
 +log_dhcp_server(server, DISCOVER (0x%x),
 +be32toh(req-message-xid));
 +
 +r = server_send_offer(server, req);
 +if (r  0) {
 +log_dhcp_server(server, could not send offer: %s,
 +strerror(-r));
 The error is logged at debug level, but otherwise ignored. Is this enough? It 
 seems that if
 server_send_offer() fails, things are significantly off.

Hm, yes, you are right. We should just make sure that
server_send_offer can only fail with critical errors and then return r
here (same goes for the other server_send_*() methods later in the
patches.

 +return 0;
 +} else {
 +log_dhcp_server(server, OFFER (0x%x),
 +be32toh(req-message-xid));
 +return DHCP_OFFER;
 +}
 +
 +break;
 +}

 -return 1;
 +return 0;
  }

  static int server_receive_message(sd_event_source *s, int fd,
 diff --git a/src/libsystemd-network/test-dhcp-server.c 
 b/src/libsystemd-network/test-dhcp-server.c
 index 0cbb4df..ed3aaf9 100644
 --- a/src/libsystemd-network/test-dhcp-server.c
 +++ b/src/libsystemd-network/test-dhcp-server.c
 @@ -94,13 +94,13 @@ static void test_message_handler(void) {

Re: [systemd-devel] [PATCH] build: Fix compile failure, KMOD_CFLAGS missing..again..

2014-05-27 Thread Tom Gundersen 
On Tue, May 20, 2014 at 5:07 AM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 ---
  Makefile.am | 4 
  1 file changed, 4 insertions(+)

 diff --git a/Makefile.am b/Makefile.am
 index f2a3bbd..bea3876 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4195,6 +4195,8 @@ endif

  # 
 --
  if ENABLE_RESOLVED
 +systemd_resolved_CFLAGS = $(AM_CFLAGS) $(KMOD_CFLAGS)
 +
  systemd_resolved_SOURCES = \
 src/resolve/resolved.h \
 src/resolve/resolved.c \
 @@ -4298,6 +4300,8 @@ systemd_networkd_wait_online_LDADD = \
 libsystemd-shared.la \
 libsystemd-network.la

 +test_network_CFLAGS = $(AM_CFLAGS) $(KMOD_CFLAGS)
 +
  test_network_SOURCES = \
 src/network/test-network.c

 --
 1.8.4.5

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

This appears to have been fixed by a similar patch.

Thanks.

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

Re: [systemd-devel] [PATCH 14/17] sd-dhcp-server: track bound leases

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, May 26, 2014 at 09:39:43PM +0200, Tom Gundersen wrote:
 Make sure we don't hand out the same IP twice. We still don't
 handle lease expiry.
 ---
  src/libsystemd-network/dhcp-server-internal.h |  25 -
  src/libsystemd-network/sd-dhcp-server.c   | 136 
 --
  src/libsystemd-network/test-dhcp-server.c |  59 +++
  3 files changed, 206 insertions(+), 14 deletions(-)
 
 diff --git a/src/libsystemd-network/dhcp-server-internal.h 
 b/src/libsystemd-network/dhcp-server-internal.h
 index ce2e260..7fe7253 100644
 --- a/src/libsystemd-network/dhcp-server-internal.h
 +++ b/src/libsystemd-network/dhcp-server-internal.h
 @@ -23,12 +23,25 @@
  #include sd-event.h
  #include sd-dhcp-server.h
  
 +#include hashmap.h
  #include refcnt.h
  #include util.h
  #include log.h
  
  #include dhcp-internal.h
  
 +typedef struct DHCPClientId {
 +size_t length;
 +uint8_t *data;
 +} DHCPClientId;
 +
 +typedef struct DHCPLease {
 +DHCPClientId client_id;
 +
 +be32_t address;
 +usec_t expiration;
 +} DHCPLease;
 +
  struct sd_dhcp_server {
  RefCount n_ref;
  
 @@ -42,12 +55,11 @@ struct sd_dhcp_server {
  be32_t address;
  be32_t pool_start;
  size_t pool_size;
 -};
 +size_t next_offer;
  
 -typedef struct DHCPClientId {
 -size_t length;
 -uint8_t *data;
 -} DHCPClientId;
 +Hashmap *leases_by_client_id;
 +DHCPLease **bound_leases;
 +};
  
  typedef struct DHCPRequest {
  /* received message */
 @@ -71,3 +83,6 @@ int dhcp_server_handle_message(sd_dhcp_server *server, 
 DHCPMessage *message,
  int dhcp_server_send_packet(sd_dhcp_server *server,
  DHCPRequest *req, DHCPPacket *packet,
  int type, size_t optoffset);
 +
 +unsigned long client_id_hash_func(const void *p, const uint8_t 
 hash_key[HASH_KEY_SIZE]);
 +int client_id_compare_func(const void *_a, const void *_b);
 diff --git a/src/libsystemd-network/sd-dhcp-server.c 
 b/src/libsystemd-network/sd-dhcp-server.c
 index 3de61f7..44ca645 100644
 --- a/src/libsystemd-network/sd-dhcp-server.c
 +++ b/src/libsystemd-network/sd-dhcp-server.c
 @@ -23,6 +23,8 @@
  #include sys/ioctl.h
  #include netinet/if_ether.h
  
 +#include siphash24.h
 +
  #include sd-dhcp-server.h
  #include dhcp-server-internal.h
  #include dhcp-internal.h
 @@ -37,6 +39,11 @@ int sd_dhcp_server_set_lease_pool(sd_dhcp_server *server, 
 struct in_addr *addres
  assert_return(size, -EINVAL);
  assert_return(server-pool_start == htobe32(INADDR_ANY), -EBUSY);
  assert_return(!server-pool_size, -EBUSY);
 +assert_return(!server-bound_leases, -EBUSY);
 +
 +server-bound_leases = new0(DHCPLease*, size);
 +if (!server-bound_leases)
 +return -ENOMEM;
  
  server-pool_start = address-s_addr;
  server-pool_size = size;
 @@ -62,13 +69,63 @@ sd_dhcp_server *sd_dhcp_server_ref(sd_dhcp_server 
 *server) {
  return server;
  }
  
 +unsigned long client_id_hash_func(const void *p, const uint8_t 
 hash_key[HASH_KEY_SIZE]) {
 +uint64_t u;
 +const DHCPClientId *id = p;
 +
 +assert(id);
 +assert(id-length);
 +assert(id-data);
 +
 +siphash24((uint8_t*) u, id-data, id-length, hash_key);
 +
 +return (unsigned long) u;
 +}
 +
 +int client_id_compare_func(const void *_a, const void *_b) {
 +const DHCPClientId *a, *b;
 +
 +a = _a;
 +b = _b;
 +
 +assert(!a-length || a-data);
 +assert(!b-length || b-data);
 +
 +if (a-length != b-length)
 +return a-length  b-length ? -1 : 1;
 +
 +return memcmp(a-data, b-data, a-length);
 +}
 +
 +static void dhcp_lease_free(DHCPLease *lease) {
 +if (!lease)
 +return;
 +
 +free(lease-client_id.data);
 +free(lease);
 +}
 +
 +DEFINE_TRIVIAL_CLEANUP_FUNC(DHCPLease*, dhcp_lease_free);
 +#define _cleanup_dhcp_lease_free_ _cleanup_(dhcp_lease_freep)
 +
  sd_dhcp_server *sd_dhcp_server_unref(sd_dhcp_server *server) {
  if (server  REFCNT_DEC(server-n_ref) = 0) {
 +DHCPLease *lease;
 +Iterator i;
 +
  log_dhcp_server(server, UNREF);
  
  sd_dhcp_server_stop(server);
  
  sd_event_unref(server-event);
 +
 +HASHMAP_FOREACH(lease, server-leases_by_client_id, i) {
 +hashmap_remove(server-leases_by_client_id, lease);
 +dhcp_lease_free(lease);
 +}
 +
 +hashmap_free(server-leases_by_client_id);
 +free(server-bound_leases);
  free(server);
  }
  
 @@ -90,6 +147,7 @@ int sd_dhcp_server_new(sd_dhcp_server **ret, int ifindex) {
  server-fd = -1;
  server-address = htobe32(INADDR_ANY);
  server-index = ifindex;
 +

Re: [systemd-devel] [PATCH 08/17] sd-dhcp-server: add support for setting the server address

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, May 27, 2014 at 05:33:34PM +0200, Tom Gundersen wrote:
 On Tue, May 27, 2014 at 5:29 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Mon, May 26, 2014 at 09:39:37PM +0200, Tom Gundersen wrote:
  ---
   src/libsystemd-network/dhcp-server-internal.h |  1 +
   src/libsystemd-network/sd-dhcp-server.c   | 13 +
   src/libsystemd-network/test-dhcp-server.c | 17 +
   src/systemd/sd-dhcp-server.h  |  1 +
   4 files changed, 32 insertions(+)
 
  diff --git a/src/libsystemd-network/dhcp-server-internal.h 
  b/src/libsystemd-network/dhcp-server-internal.h
  index 6c2f2b4..58a9877 100644
  --- a/src/libsystemd-network/dhcp-server-internal.h
  +++ b/src/libsystemd-network/dhcp-server-internal.h
  @@ -39,6 +39,7 @@ struct sd_dhcp_server {
   int fd_raw;
 
   int index;
  +be32_t address;
   };
 
   typedef struct DHCPClientId {
  diff --git a/src/libsystemd-network/sd-dhcp-server.c 
  b/src/libsystemd-network/sd-dhcp-server.c
  index ecdc15d..7d6170c 100644
  --- a/src/libsystemd-network/sd-dhcp-server.c
  +++ b/src/libsystemd-network/sd-dhcp-server.c
  @@ -27,6 +27,17 @@
   #include dhcp-server-internal.h
   #include dhcp-internal.h
 
  +int sd_dhcp_server_set_address(sd_dhcp_server *server, struct in_addr 
  *address) {
  +assert_return(server, -EINVAL);
  +assert_return(address, -EINVAL);
  +assert_return(address-s_addr, -EINVAL);
  +assert_return(server-address == htobe32(INADDR_ANY), -EBUSY);
  +
  +server-address = address-s_addr;
  +
  +return 0;
  +}
  +
   sd_dhcp_server *sd_dhcp_server_ref(sd_dhcp_server *server) {
   if (server)
   assert_se(REFCNT_INC(server-n_ref) = 2);
  @@ -60,6 +71,7 @@ int sd_dhcp_server_new(sd_dhcp_server **ret, int 
  ifindex) {
   server-n_ref = REFCNT_INIT;
   server-fd_raw = -1;
   server-fd = -1;
  +server-address = htobe32(INADDR_ANY);
   server-index = ifindex;
 
   *ret = server;
  @@ -281,6 +293,7 @@ int sd_dhcp_server_start(sd_dhcp_server *server) {
   assert_return(!server-receive_message, -EBUSY);
   assert_return(server-fd_raw == -1, -EBUSY);
   assert_return(server-fd == -1, -EBUSY);
  +assert_return(server-address != htobe32(INADDR_ANY), -EBUSY);
 
  EBUSY seems rather confusing here, since actually the opposite is
  true, for this newly added check as well for the preexisting ones:
  the structure has not been initialized to be usable yet. Maybe a
  different error code like EUNATCH or EBADRQC, ENODATA, EDESTADDRREQ or
  EUCLEAN ?
 
 Ah, that's a fair point. I expect this issue to appear throughout the
 patches, I'll fix them all up.
I'm rooting for EUCLEAN of course ;)

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

Re: [systemd-devel] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts.

2014-05-27 Thread Przemek Rudy 
On 05/27/2014 01:37 PM, Harald Hoyer wrote:
 On 21.05.2014 10:03, Lennart Poettering wrote:
 On Sun, 18.05.14 19:36, Przemek Rudy (pru...@o2.pl) wrote:

 diff --git a/src/core/automount.c b/src/core/automount.c
 index 65e6d6f..d4359b9 100644
 --- a/src/core/automount.c
 +++ b/src/core/automount.c
 @@ -124,7 +124,7 @@ static int automount_add_mount_links(Automount *a) {
  if (r  0)
  return r;
  
 -return unit_require_mounts_for(UNIT(a), parent);
 +return unit_needs_mounts_for(UNIT(a), parent, true);
  }
  

 Please make the the last parameter one of type UnitDependency, so that
 one can either pass UNIT_WANTS or UNIT_REQUIRES there. THat makes the
 calls much more descriptive, as well as more generic.

 Otherwise looks pretty good!

 Lennart

 
 Hmm, I might see a problem in the initramfs, where devices show up bit by bit.
 The user might then be confronted with the password dialog, although the 
 device
 with the key file will show up a little bit later.
 
 But I might be wrong. Time will tell.
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
Hello Harald,
After years, same thing different place, was in dracut now in systemd. :)

Please note that the key device has its own mounting timeout that goes into 
fstab:
x-systemd.device-timeout=10,auto,nofail

this ensures we have x-systemd.device-timeout seconds to wait for the key 
device before give up.

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Kirill Elagin 

 The container usecase alone is already the reason why I am so very sure
 I want this stuff, and that it needs to be in networkd, and just work. I
 want this fully automatic, so that we can create a hundred of veth
 tunnels, and trivially easy (simply by setting DHCPServer=yes for their
 .network file) make them automatically configured, passing the relevant
 configuration bits on.


I'm sorry to intervene, but there are other ways to configure containers
and similar stuff. I mean, systemd is great because it pioneered so
many cool things. Why can't we do something new? For example, prohibit
IPv4 for containers and VMs and require them to use IPv6 with link-local
addresses which will eliminate the need for any kind of configuration.
Pushing IPv6 forward is a good idea. But, well, if you find this
unacceptable, what's wrong with IPv4LL?

DHCP is complex (well, not _that_ complex, but still) and it's not
always required. E.g. IPv6 networks can live without DHCP by using
link-local addresses and, say, some basic NDP. It seems to me that
IPv4LL should suffice for all the “container use-cases”.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running a systemd service in capability-only environment as non-root user

2014-05-27 Thread Mantas Mikulėnas 
On Tue, May 27, 2014 at 4:31 PM, Michal Witanowski
m.witanow...@samsung.com wrote:
 Hi,

 first of all I'd like to mark that I'm not sure if I'm writing in the right
 place.

 I have a problem with running a systemd service in capability-only
 environment: I want to run a process with some caps (cap_sys_admin
 cap_dac_override cap_mac_override) as a regular user (UID != 0).
 My service config file looks something like this:

 User=test
 CapabilityBoundingSet=cap_sys_admin cap_dac_override cap_mac_override
 Capabilities=cap_sys_admin,cap_dac_override,cap_mac_override=eip
 SecureBits=keep-caps

 Unfortunately, the process does not gain any permissive capabilities:

 CapInh: 00010022
 CapPrm: 
 CapEff: 
 CapBnd: 00010022

 However, when I run the service as root (by removing User=test) the
 process does own required caps:

 CapInh: 00010022
 CapPrm: 00010022
 CapEff: 00010022
 CapBnd: 00010022

Does the executable file itself have these capabilities set as =ei?

According to the same manual page, each capability must be set as
inheritable for both the process and the file, to receive them _at
all_...

P'(permitted) = (P(inheritable)  F(inheritable)) | (F(permitted)  cap_bset)

...and as effective on the file, otherwise the new process has to
manually 'enable' them:

P'(effective) = F(effective) ? P'(permitted) : 0

...or at least that seems to be how it works. Damn thing is confusing.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator

2014-05-27 Thread Thomas H.P. Andersen 
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com

Reuses logic from service.c and the rc-local generator.

Note that this drops reading of chkconfig entirely. It also drops reading
runlevels from the LSB headers. The runlevels were only used to check for
runlevels outside of the normal 1-5 range and then add special dependencies
and settings. Special runlevels were dropped in the past so it seemed to be
unused code.

Also note that this code behaves differently to the old if an initcsript
and native unit exist with the same name. Before the initscript would be
ignored but now a .service file is created in /run which will override
the native unit.

The old code dealing with initscripts are left in for now as the generator
will run first and the old code will then ignore the initscripts since
unit files exist for them. I will add another patch to rip the old code out
later.

The patch is WIP and only tested lightly. I am mostly looking for comments
if this is a good idea at all.
---
 .gitignore  |   1 +
 Makefile.am |  10 +
 src/sysv-generator/Makefile |   1 +
 src/sysv-generator/sysv-generator.c | 896 
 4 files changed, 908 insertions(+)
 create mode 100644 src/sysv-generator/Makefile
 create mode 100644 src/sysv-generator/sysv-generator.c

diff --git a/.gitignore b/.gitignore
index 908c563..061b4af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -101,6 +101,7 @@
 /systemd-socket-proxyd
 /systemd-sysctl
 /systemd-system-update-generator
+/systemd-sysv-generator
 /systemd-timedated
 /systemd-timesyncd
 /systemd-tmpfiles
diff --git a/Makefile.am b/Makefile.am
index 5b26bc3..a395969 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -549,6 +549,7 @@ nodist_systemunit_DATA += \
units/halt-local.service
 
 systemgenerator_PROGRAMS += \
+   systemd-sysv-generator \
systemd-rc-local-generator
 endif
 
@@ -1918,6 +1919,15 @@ UNINSTALL_EXEC_HOOKS += dbus1-generator-uninstall-hook
 endif
 
 # 
--
+systemd_sysv_generator_SOURCES = \
+   src/sysv-generator/sysv-generator.c
+
+systemd_sysv_generator_LDADD = \
+   libsystemd-core.la \
+   libsystemd-label.la \
+   libsystemd-shared.la
+
+# 
--
 systemd_rc_local_generator_SOURCES = \
src/rc-local-generator/rc-local-generator.c
 
diff --git a/src/sysv-generator/Makefile b/src/sysv-generator/Makefile
new file mode 100644
index 000..530e5e9
--- /dev/null
+++ b/src/sysv-generator/Makefile
@@ -0,0 +1 @@
+../Makefile
diff --git a/src/sysv-generator/sysv-generator.c 
b/src/sysv-generator/sysv-generator.c
new file mode 100644
index 000..7d153a6
--- /dev/null
+++ b/src/sysv-generator/sysv-generator.c
@@ -0,0 +1,896 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Thomas H.P. Andersen
+  Copyright 2010 Lennart Poettering
+  Copyright 2011 Michal Schmidt
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include errno.h
+#include stdio.h
+#include unistd.h
+
+#include util.h
+#include mkdir.h
+#include strv.h
+#include path-util.h
+#include path-lookup.h
+#include log.h
+#include strv.h
+#include unit.h
+#include unit-name.h
+#include special.h
+#include exit-status.h
+#include def.h
+#include env-util.h
+#include fileio.h
+#include hashmap.h
+
+typedef enum RunlevelType {
+RUNLEVEL_UP,
+RUNLEVEL_DOWN
+} RunlevelType;
+
+static const struct {
+const char *path;
+const char *target;
+const RunlevelType type;
+} rcnd_table[] = {
+/* Standard SysV runlevels for start-up */
+{ rc1.d,  SPECIAL_RESCUE_TARGET,RUNLEVEL_UP },
+{ rc2.d,  SPECIAL_RUNLEVEL2_TARGET, RUNLEVEL_UP },
+{ rc3.d,  SPECIAL_RUNLEVEL3_TARGET, RUNLEVEL_UP },
+{ rc4.d,  SPECIAL_RUNLEVEL4_TARGET, RUNLEVEL_UP },
+{ rc5.d,  SPECIAL_RUNLEVEL5_TARGET, RUNLEVEL_UP },
+
+/* Standard SysV runlevels for shutdown */
+{ rc0.d,  SPECIAL_POWEROFF_TARGET,  RUNLEVEL_DOWN },
+{ rc6.d,  SPECIAL_REBOOT_TARGET,RUNLEVEL_DOWN }
+
+/* Note that the order here matters, as we read the
+   directories in this order, and we want to make sure that
+

Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator

2014-05-27 Thread Peeters Simon 
2014-05-28 1:12 GMT+02:00 Thomas H.P. Andersen pho...@gmail.com:
 From: Thomas Hindoe Paaboel Andersen pho...@gmail.com

 Reuses logic from service.c and the rc-local generator.

 Note that this drops reading of chkconfig entirely. It also drops reading
 runlevels from the LSB headers. The runlevels were only used to check for
 runlevels outside of the normal 1-5 range and then add special dependencies
 and settings. Special runlevels were dropped in the past so it seemed to be
 unused code.

 Also note that this code behaves differently to the old if an initcsript
 and native unit exist with the same name. Before the initscript would be
 ignored but now a .service file is created in /run which will override
 the native unit.

this feels wrong, the native unit should override the sysv one.
Is there any reason why you want to change this?
Couldn't you just use arg_dest = argv[3]; instead?

 The old code dealing with initscripts are left in for now as the generator
 will run first and the old code will then ignore the initscripts since
 unit files exist for them. I will add another patch to rip the old code out
 later.

 The patch is WIP and only tested lightly. I am mostly looking for comments
 if this is a good idea at all.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Reindl Harald 

Am 27.05.2014 20:14, schrieb Kirill Elagin:
 The container usecase alone is already the reason why I am so very sure
 I want this stuff, and that it needs to be in networkd, and just work. I
 want this fully automatic, so that we can create a hundred of veth
 tunnels, and trivially easy (simply by setting DHCPServer=yes for their
 .network file) make them automatically configured, passing the relevant
 configuration bits on.
 
 I'm sorry to intervene, but there are other ways to configure containers
 and similar stuff. I mean, systemd is great because it pioneered so
 many cool things. Why can't we do something new? For example, prohibit
 IPv4 for containers and VMs and require them to use IPv6 with link-local
 addresses which will eliminate the need for any kind of configuration.
 Pushing IPv6 forward is a good idea. But, well, if you find this
 unacceptable, what's wrong with IPv4LL?

because people are using containers to reflect the real life out there?
that means IPv4 for a very very long time
that means *dual stack* for a very very long time

how do you imagine building up a comlex network structure within
containers for simulations and after figure out things take
them for production and only replace the network segments?

if someone starts with something new followed by prohibit
things which are just in use and working he only can be wrong



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2

2014-05-27 Thread Aaron Lewis 
Hi,

I'm running Arch and recently upgraded system, now every time I boot I
see a dead service: rfkill1

  systemd-rfkill@rfkill0.service   loaded active
exitedLoad/Save RF Kill Switch Status of rfkill0
● systemd-rfkill@rfkill1.service   loaded failed
failedLoad/Save RF Kill Switch Status of rfkill1
  systemd-rfkill@rfkill2.service   loaded active
exitedLoad/Save RF Kill Switch Status of rfkill2

I tried to run `systemctl disable systemd-rfkill@rfkill1`, but there's
no output after that and it wasn't disabled at all

Any ideas?

PS. rfkill list output

0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no


-- 
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print:   9F67 391B B770 8FF6 99DC  D92D 87F6 2602 1371 4D33
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator

2014-05-27 Thread Cristian Rodríguez 
El 27/05/14 20:14, Peeters Simon escribió:

 this feels wrong, the native unit should override the sysv one.
 Is there any reason why you want to change this?
 Couldn't you just use arg_dest = argv[3]; instead?
 

This behaviour is probably my only objection to the idea in question,
the generated unit should not override the native one.



-- 
Cristian
I don't know the key to success, but the key to failure is trying to
please everybody.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2

2014-05-27 Thread Leonid Isaev 
Hi,

On Wed, 28 May 2014 08:25:52 +0800
Aaron Lewis the.warl0ck.1...@gmail.com wrote:

 Hi,
 
 I'm running Arch and recently upgraded system, now every time I boot I
 see a dead service: rfkill1
 
   systemd-rfkill@rfkill0.service   loaded active
 exitedLoad/Save RF Kill Switch Status of rfkill0
 ● systemd-rfkill@rfkill1.service   loaded failed
 failedLoad/Save RF Kill Switch Status of rfkill1
   systemd-rfkill@rfkill2.service   loaded active
 exitedLoad/Save RF Kill Switch Status of rfkill2
 
 I tried to run `systemctl disable systemd-rfkill@rfkill1`, but there's
 no output after that and it wasn't disabled at all
 
 Any ideas?

Yes: systemctl mask systemd-rfkill@rfkill1.service. Or better yet, append
systemd.restore_state=0 to your kernel cmdline.

Cheers,
L.
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


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

Re: [systemd-devel] [PATCH] hostnamed: Fix the way that static and transient host names interact

2014-05-27 Thread Lennart Poettering 
On Wed, 12.02.14 09:46, Stef Walter (s...@thewalter.net) wrote:

heya!

I finally merged this patch. Sorry for the delay!

I wasn't sure about the rationale, but this appears to be the right
thing to do after all, so I merged it!

Thank you!

Lennart

 It is almost always incorrect to allow DHCP or other sources of
 transient host names to override an explicitly configured static host
 name.
 
 This commit changes things so that if a static host name is set, this
 will override the transient host name (eg: provided via DHCP). Transient
 host names can still be used to provide host names for machines that have
 not been explicitly configured with a static host name.
 
 The exception to this rule is if the static host name is set to
 localhost or matches localhost.*. In those cases we act as if no
 static host name has been explicitly set.
 
 As discussed elsewhere, systemd may want to have an fd based ownership
 of the transient name. That part is not included in this commit.
 ---
  man/hostnamectl.xml  |  8 +++-
  src/hostname/hostnamed.c | 36 +++-
  2 files changed, 34 insertions(+), 10 deletions(-)
 
 diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
 index 4bc05f5..80e8cde 100644
 --- a/man/hostnamectl.xml
 +++ b/man/hostnamectl.xml
 @@ -68,11 +68,9 @@
  (e.g. Lennart's Laptop), the static hostname which
  is used to initialize the kernel hostname at boot
  (e.g. lennarts-laptop), and the transient hostname
 -which might be assigned temporarily due to network
 -configuration and might revert back to the static
 -hostname if network connectivity is lost and is only
 -temporarily written to the kernel hostname
 -(e.g. dhcp-47-11)./para
 +which is a default received from network configuration.
 +If a static hostname is set, and is valid (something other
 +than localhost) then the transient hostname is not 
 used./para
  
  paraNote that the pretty hostname has little
  restrictions on the characters used, while the static
 diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
 index e57891b..5174fa8 100644
 --- a/src/hostname/hostnamed.c
 +++ b/src/hostname/hostnamed.c
 @@ -228,16 +228,36 @@ static char* context_fallback_icon_name(Context *c) {
  return strdup(computer);
  }
  
 -static int context_write_data_hostname(Context *c) {
 +static bool hostname_is_useful(const char *hn) {
 +return !isempty(hn)  !streq(hn, localhost) 
 +   !startswith(hn, localhost.);
 +}
 +
 +static int context_update_kernel_hostname(Context *c) {
 +const char *static_hn;
  const char *hn;
  
  assert(c);
  
 -if (isempty(c-data[PROP_HOSTNAME]))
 -hn = localhost;
 -else
 +static_hn = c-data[PROP_STATIC_HOSTNAME];
 +
 +/* /etc/hostname with something other than localhost
 + * has the highest preference ... */
 +if (hostname_is_useful(static_hn))
 +hn = static_hn;
 +
 +/* ... the transient host name, (ie: DHCP) comes next ...*/
 +else if (!isempty(c-data[PROP_HOSTNAME]))
  hn = c-data[PROP_HOSTNAME];
  
 +/* ... fallback to static localhost.* ignored above ... */
 +else if (!isempty(static_hn))
 +hn = static_hn;
 +
 +/* ... and the ultimate fallback */
 +else
 +hn = localhost;
 +
  if (sethostname(hn, strlen(hn))  0)
  return -errno;
  
 @@ -389,7 +409,7 @@ static int method_set_hostname(sd_bus *bus, 
 sd_bus_message *m, void *userdata, s
  free(c-data[PROP_HOSTNAME]);
  c-data[PROP_HOSTNAME] = h;
  
 -r = context_write_data_hostname(c);
 +r = context_update_kernel_hostname(c);
  if (r  0) {
  log_error(Failed to set host name: %s, strerror(-r));
  return sd_bus_error_set_errnof(error, r, Failed to set 
 hostname: %s, strerror(-r));
 @@ -441,6 +461,12 @@ static int method_set_static_hostname(sd_bus *bus, 
 sd_bus_message *m, void *user
  c-data[PROP_STATIC_HOSTNAME] = h;
  }
  
 +r = context_update_kernel_hostname(c);
 +if (r  0) {
 +log_error(Failed to set host name: %s, strerror(-r));
 +return sd_bus_error_set_errnof(error, r, Failed to set 
 hostname: %s, strerror(-r));
 +}
 +
  r = context_write_data_static_hostname(c);
  if (r  0) {
  log_error(Failed to write static host name: %s, 
 strerror(-r));


Lennart

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

Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator

2014-05-27 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote:
 From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
 
 Reuses logic from service.c and the rc-local generator.
 
 Note that this drops reading of chkconfig entirely. 
How likely is this to cause regressions in existing distributions?

 It also drops reading
 runlevels from the LSB headers. The runlevels were only used to check for
 runlevels outside of the normal 1-5 range and then add special dependencies
 and settings. Special runlevels were dropped in the past so it seemed to be
 unused code.
 
 Also note that this code behaves differently to the old if an initcsript
 and native unit exist with the same name. Before the initscript would be
 ignored but now a .service file is created in /run which will override
 the native unit.
This is a total no-no. This would immediately break existing setups,
becuase since forever this has been documented and advertised as a
compatibility mechanism.

 The old code dealing with initscripts are left in for now as the generator
 will run first and the old code will then ignore the initscripts since
 unit files exist for them. I will add another patch to rip the old code out
 later.
It would be nice to have this counterpart too, since then it would be easier
to tell how much complexity and existing code we are removing. I think that
there's general agreement to the idea of moving sysv support to a generator,
the question is only if we can do it without significant breakage.

 The patch is WIP and only tested lightly. I am mostly looking for comments
 if this is a good idea at all.
The code look OK.

 ---
  .gitignore  |   1 +
  Makefile.am |  10 +
  src/sysv-generator/Makefile |   1 +
  src/sysv-generator/sysv-generator.c | 896 
 
  4 files changed, 908 insertions(+)
  create mode 100644 src/sysv-generator/Makefile
  create mode 100644 src/sysv-generator/sysv-generator.c
 
 diff --git a/.gitignore b/.gitignore
 index 908c563..061b4af 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -101,6 +101,7 @@
  /systemd-socket-proxyd
  /systemd-sysctl
  /systemd-system-update-generator
 +/systemd-sysv-generator
  /systemd-timedated
  /systemd-timesyncd
  /systemd-tmpfiles
 diff --git a/Makefile.am b/Makefile.am
 index 5b26bc3..a395969 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -549,6 +549,7 @@ nodist_systemunit_DATA += \
   units/halt-local.service
  
  systemgenerator_PROGRAMS += \
 + systemd-sysv-generator \
   systemd-rc-local-generator
  endif
  
 @@ -1918,6 +1919,15 @@ UNINSTALL_EXEC_HOOKS += dbus1-generator-uninstall-hook
  endif
  
  # 
 --
 +systemd_sysv_generator_SOURCES = \
 + src/sysv-generator/sysv-generator.c
 +
 +systemd_sysv_generator_LDADD = \
 + libsystemd-core.la \
 + libsystemd-label.la \
 + libsystemd-shared.la
 +
 +# 
 --
  systemd_rc_local_generator_SOURCES = \
   src/rc-local-generator/rc-local-generator.c
  
 diff --git a/src/sysv-generator/Makefile b/src/sysv-generator/Makefile
 new file mode 100644
 index 000..530e5e9
 --- /dev/null
 +++ b/src/sysv-generator/Makefile
 @@ -0,0 +1 @@
 +../Makefile
 diff --git a/src/sysv-generator/sysv-generator.c 
 b/src/sysv-generator/sysv-generator.c
 new file mode 100644
 index 000..7d153a6
 --- /dev/null
 +++ b/src/sysv-generator/sysv-generator.c
 @@ -0,0 +1,896 @@
 +/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
 +
 +/***
 +  This file is part of systemd.
 +
 +  Copyright 2014 Thomas H.P. Andersen
 +  Copyright 2010 Lennart Poettering
 +  Copyright 2011 Michal Schmidt
 +
 +  systemd is free software; you can redistribute it and/or modify it
 +  under the terms of the GNU Lesser General Public License as published by
 +  the Free Software Foundation; either version 2.1 of the License, or
 +  (at your option) any later version.
 +
 +  systemd is distributed in the hope that it will be useful, but
 +  WITHOUT ANY WARRANTY; without even the implied warranty of
 +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 +  Lesser General Public License for more details.
 +
 +  You should have received a copy of the GNU Lesser General Public License
 +  along with systemd; If not, see http://www.gnu.org/licenses/.
 +***/
 +
 +#include errno.h
 +#include stdio.h
 +#include unistd.h
 +
 +#include util.h
 +#include mkdir.h
 +#include strv.h
 +#include path-util.h
 +#include path-lookup.h
 +#include log.h
 +#include strv.h
 +#include unit.h
 +#include unit-name.h
 +#include special.h
 +#include exit-status.h
 +#include def.h
 +#include env-util.h
 +#include fileio.h
 +#include hashmap.h
 +
 +typedef enum RunlevelType {
 +RUNLEVEL_UP,
 +RUNLEVEL_DOWN
 +} RunlevelType;
 +
 +static const struct {
 +const char *path;
 +

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Lennart Poettering 
On Tue, 27.05.14 14:28, Michael Biebl (mbi...@gmail.com) wrote:

 
 2014-05-27 14:00 GMT+02:00 Lennart Poettering lenn...@poettering.net:
 
  In many ways, if people complain about a dhcp server in networkd, then
  it's like complaining about the fact that pppd also can assign addresses
  to the other side...
 
 I don't see pppd implementing a DHCP server.

Of course, that's what they do. They call it differently though
ipcp-accept-remote and stuff. Pretty much the same stuff: it
configures pppd to not use static IP address configuration, but dynamic
one, assigned by the peer, much like dhcp works.

Lennart

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

Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support

2014-05-27 Thread Lennart Poettering 
On Tue, 27.05.14 16:04, Eelco Dolstra (eelco.dols...@logicblox.com) wrote:

  I am very sure this should be in networkd. 
 [snip]
 
 That sounds reasonable. However, to be honest, I've never really understood 
 why
 networkd needs to be part of systemd in the first place. It seems to
 me that it

Well, it shares a lot of code with the rest of systemd, and the rest of
systemd inetgrate with it in many ways. For example, timsyncd is able to
follow network state changes and only do NTP when  there's actually an
IP address up. Or it can recieve NTP servers via DHCP, and so on. 

or you have all that integration for the initrd and the early boot environment.

 would work just as well as a separate package with its own
 releases. To me as a

No, it wouldn't, we couldn't share much of our code, we couldn't simply
rely on the various interfaces between the components, we'd enter
dependency hell. 

The reason why something like networkd so quickly became useful and at
its minimal footprint is precisely that we can share so much code and
systemd's trove of utility functions makes it so easy to write code.

 downstream that would be preferable, since such a package can be upgraded
 (mostly) independently from systemd. For instance, in NixOS we can upgrade
 dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system;
 but getting the latest networkd would require getting the latest systemd, 
 which
 is typically a much bigger step since it potentially impacts much more of the
 system.

Well, philosophically, I think the major weakness of the current Linux
system is the fact that everything can be upgraded completely
independently. That makes it incredibly hard to test anything it
explodes the test matrix, annd it makes it equally hard for developers
to target the OS, since they never know what they will be runnin on.

You are welcome to split systemd up into multiple packages when you
package it, but it's an absolute requirement that you always update them
in sync. 

 You often point out (correctly) that systemd is not monolithic as it consists 
 of
 dozens of separate programs. But it *is* a monolithic package: those dozens of
 programs can only be upgraded as a set.

Well, that's a weird definition of monolithic. But yeah, we
*absolutely* require that systemd and its components is updated in
sync. That's a core design principle of what we do.

  Remember that the goal here is not to write another ldap enabled
  monstrosity. 
 
 A package becomes a monstrosity one small feature at a time. (And one 
 person's
 bloat is another person's essential feature.) For instance, networkd currently
 lacks a WPA supplicant, which you surely need in a modern system. So should
 systemd accrete a WPA supplicant? How about Bluetooth support? Etc. etc. I 
 mean,
 is there any concrete criterion about what should or shouldn't go into 
 systemd?

That is always a good question, and a hard one to answer. But it's
usually a question of specific vs. generic. IP configuration and stuff
is generic, inherently so. Hardware like Bluetooth is specific in my
eyes, so it's beyond the line.

But yeah, systemd is a *platform*, and we will cover the bits sooner or
later, than the ajority of systems will obviously need. And for me DHCP
is one of those things...

Lennart

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

Re: [systemd-devel] How to escape from systemd slice

2014-05-27 Thread David Timothy Strauss 
One of the cleanest ways to do what you want is to create a
D-Bus-activated systemd service (or socket-activated, if that's more
appropriate). That allows activation completely outside the user's
session without elevated privileges. Of course, it requires
considerable work for each service to do it right.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] units: use KillMode=process for systemd-nspawn@.service

2014-05-27 Thread David Timothy Strauss 
Is there a downside to using KillMode=mixed instead?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] units: use KillMode=process for systemd-nspawn@.service

2014-05-27 Thread Jonathan Liu 
On 28 May 2014 13:36, David Timothy Strauss da...@davidstrauss.net wrote:
 Is there a downside to using KillMode=mixed instead?

I suspect one downside is that if the container takes longer than the
timeout to shutdown then it will go on a SIGKILL-ing spree... which
could be a problem if a container process was in the middle of saving
to disk while shutting down.

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

Re: [systemd-devel] How do I disable rfkill1 service? I only have slot 0 and 2

2014-05-27 Thread Mantas Mikulėnas 
On May 28, 2014 3:25 AM, Aaron Lewis the.warl0ck.1...@gmail.com wrote:

 Hi,

 I'm running Arch and recently upgraded system, now every time I boot I
 see a dead service: rfkill1

   systemd-rfkill@rfkill0.service   loaded active
 exitedLoad/Save RF Kill Switch Status of rfkill0
 ● systemd-rfkill@rfkill1.service   loaded failed
 failedLoad/Save RF Kill Switch Status of rfkill1
   systemd-rfkill@rfkill2.service   loaded active
 exitedLoad/Save RF Kill Switch Status of rfkill2

 I tried to run `systemctl disable systemd-rfkill@rfkill1`, but there's
 no output after that and it wasn't disabled at all

 Any ideas?

 PS. rfkill list output

 0: tpacpi_bluetooth_sw: Bluetooth
 Soft blocked: yes
 Hard blocked: no
 2: phy0: Wireless LAN
 Soft blocked: no
 Hard blocked: no

It is a bit strange. The systemd-rfkill@ units are invoked by udev rules
with the exact name from kernel, so a rfkill1 must have been there at some
point, and disappeared very quickly afterwards? (There wouldn't be a hole
in the numbering otherwise, too.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel