Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
You are right. Apologies. I was stuck on my own work due to this issue and was eager to get it solved too soon. I'll spend some more time tonight digging about how other DHCP clients deal with detecting if the interface supports link level unicast or not. — Sent from Mailbox On Wed, May 28, 2014 at 7:31 PM, Michael Marineau wrote: > On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar > wrote: >> Oh, never mind, there is no rush since we are already custom patching in >> CoreOS for now. > Hey, don't get ahead of yourself. I haven't merged your patch into > CoreOS just yet ;-) > I'm fine with the patch being a temporary fix as long as we can sort > out the final version soon. >> >> >> On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar >> wrote: >>> >>> It makes total sense. I can provide that patch in addition if you like, >>> But, can we merge this change for now so we can fix >>> https://github.com/coreos/bugs/issues/12 and create a new issue to make it >>> more robust? >>> >>> >>> On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen wrote: On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar wrote: > In systems running on hypervisors this flag needs to be set ON, so > offers can reach > the virtual machines. > > For more information please refer to this thread in CoreOS: > https://github.com/coreos/bugs/issues/12 > > Signed-off-by: Camilo Aguilar > --- > src/libsystemd-network/sd-dhcp-client.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/src/libsystemd-network/sd-dhcp-client.c > b/src/libsystemd-network/sd-dhcp-client.c > index 0300a6b..8f54906 100644 > --- a/src/libsystemd-network/sd-dhcp-client.c > +++ b/src/libsystemd-network/sd-dhcp-client.c > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client > *client, DHCPPacket **ret, > refuse to issue an DHCP lease if 'secs' is set to zero */ > packet->dhcp.secs = htobe16(client->secs); > > +/* RFC2132 section 4.1 > + A client that cannot receive unicast IP datagrams until its > protocol > + software has been configured with an IP address SHOULD set > the > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER > or > + DHCPREQUEST messages that client sends. The BROADCAST bit > will > + provide a hint to the DHCP server and BOOTP relay agent to > broadcast > + any messages to the client on the client's subnet. */ > +packet->dhcp.flags = htobe16(0x8000); Hm, most clients can and should use unicast, so we should definitely not request broadcast unconditionally. If there really is a situation where we need broadcast, we should detect that and only request broadcast in this case. > Do you have any ideas on how to detect the issue documented here with > VMware virtual machines? I haven't dug into this bug yet myself so I'm > not sure what other DHCP implementations are doing off the top of my > head. > https://github.com/coreos/bugs/issues/12___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Wed, May 28, 2014 at 4:13 PM, Camilo Aguilar wrote: > Oh, never mind, there is no rush since we are already custom patching in > CoreOS for now. Hey, don't get ahead of yourself. I haven't merged your patch into CoreOS just yet ;-) I'm fine with the patch being a temporary fix as long as we can sort out the final version soon. > > > On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar > wrote: >> >> It makes total sense. I can provide that patch in addition if you like, >> But, can we merge this change for now so we can fix >> https://github.com/coreos/bugs/issues/12 and create a new issue to make it >> more robust? >> >> >> On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen wrote: >>> >>> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar >>> wrote: >>> > In systems running on hypervisors this flag needs to be set ON, so >>> > offers can reach >>> > the virtual machines. >>> > >>> > For more information please refer to this thread in CoreOS: >>> > https://github.com/coreos/bugs/issues/12 >>> > >>> > Signed-off-by: Camilo Aguilar >>> > --- >>> > src/libsystemd-network/sd-dhcp-client.c | 9 + >>> > 1 file changed, 9 insertions(+) >>> > >>> > diff --git a/src/libsystemd-network/sd-dhcp-client.c >>> > b/src/libsystemd-network/sd-dhcp-client.c >>> > index 0300a6b..8f54906 100644 >>> > --- a/src/libsystemd-network/sd-dhcp-client.c >>> > +++ b/src/libsystemd-network/sd-dhcp-client.c >>> > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client >>> > *client, DHCPPacket **ret, >>> > refuse to issue an DHCP lease if 'secs' is set to zero */ >>> > packet->dhcp.secs = htobe16(client->secs); >>> > >>> > +/* RFC2132 section 4.1 >>> > + A client that cannot receive unicast IP datagrams until its >>> > protocol >>> > + software has been configured with an IP address SHOULD set >>> > the >>> > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER >>> > or >>> > + DHCPREQUEST messages that client sends. The BROADCAST bit >>> > will >>> > + provide a hint to the DHCP server and BOOTP relay agent to >>> > broadcast >>> > + any messages to the client on the client's subnet. */ >>> > +packet->dhcp.flags = htobe16(0x8000); >>> >>> Hm, most clients can and should use unicast, so we should definitely >>> not request broadcast unconditionally. If there really is a situation >>> where we need broadcast, we should detect that and only request >>> broadcast in this case. Do you have any ideas on how to detect the issue documented here with VMware virtual machines? I haven't dug into this bug yet myself so I'm not sure what other DHCP implementations are doing off the top of my head. https://github.com/coreos/bugs/issues/12 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
Oh, never mind, there is no rush since we are already custom patching in CoreOS for now. On Wed, May 28, 2014 at 7:10 PM, Camilo Aguilar wrote: > It makes total sense. I can provide that patch in addition if you like, > But, can we merge this change for now so we can fix > https://github.com/coreos/bugs/issues/12 and create a new issue to make > it more robust? > > > On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen wrote: > >> On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar >> wrote: >> > In systems running on hypervisors this flag needs to be set ON, so >> offers can reach >> > the virtual machines. >> > >> > For more information please refer to this thread in CoreOS: >> https://github.com/coreos/bugs/issues/12 >> > >> > Signed-off-by: Camilo Aguilar >> > --- >> > src/libsystemd-network/sd-dhcp-client.c | 9 + >> > 1 file changed, 9 insertions(+) >> > >> > diff --git a/src/libsystemd-network/sd-dhcp-client.c >> b/src/libsystemd-network/sd-dhcp-client.c >> > index 0300a6b..8f54906 100644 >> > --- a/src/libsystemd-network/sd-dhcp-client.c >> > +++ b/src/libsystemd-network/sd-dhcp-client.c >> > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client >> *client, DHCPPacket **ret, >> > refuse to issue an DHCP lease if 'secs' is set to zero */ >> > packet->dhcp.secs = htobe16(client->secs); >> > >> > +/* RFC2132 section 4.1 >> > + A client that cannot receive unicast IP datagrams until its >> protocol >> > + software has been configured with an IP address SHOULD set >> the >> > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER >> or >> > + DHCPREQUEST messages that client sends. The BROADCAST bit >> will >> > + provide a hint to the DHCP server and BOOTP relay agent to >> broadcast >> > + any messages to the client on the client's subnet. */ >> > +packet->dhcp.flags = htobe16(0x8000); >> >> Hm, most clients can and should use unicast, so we should definitely >> not request broadcast unconditionally. If there really is a situation >> where we need broadcast, we should detect that and only request >> broadcast in this case. >> >> Does that make sense? >> >> Cheers, >> >> Tom >> >> > /* RFC2132 section 4.1.1: >> > The client MUST include its hardware address in the >> ’chaddr’ field, if >> > necessary for delivery of DHCP reply messages. >> > -- >> > 1.8.5.2 (Apple Git-48) >> > >> > >> > ___ >> > systemd-devel mailing list >> > systemd-devel@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > >> > > > > -- > *Camilo Aguilar* > Software Engineer > http://github.com/c4milo > > > -- *Camilo Aguilar* Software Engineer http://github.com/c4milo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
It makes total sense. I can provide that patch in addition if you like, But, can we merge this change for now so we can fix https://github.com/coreos/bugs/issues/12 and create a new issue to make it more robust? On Wed, May 28, 2014 at 7:03 PM, Tom Gundersen wrote: > On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar > wrote: > > In systems running on hypervisors this flag needs to be set ON, so > offers can reach > > the virtual machines. > > > > For more information please refer to this thread in CoreOS: > https://github.com/coreos/bugs/issues/12 > > > > Signed-off-by: Camilo Aguilar > > --- > > src/libsystemd-network/sd-dhcp-client.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/src/libsystemd-network/sd-dhcp-client.c > b/src/libsystemd-network/sd-dhcp-client.c > > index 0300a6b..8f54906 100644 > > --- a/src/libsystemd-network/sd-dhcp-client.c > > +++ b/src/libsystemd-network/sd-dhcp-client.c > > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client > *client, DHCPPacket **ret, > > refuse to issue an DHCP lease if 'secs' is set to zero */ > > packet->dhcp.secs = htobe16(client->secs); > > > > +/* RFC2132 section 4.1 > > + A client that cannot receive unicast IP datagrams until its > protocol > > + software has been configured with an IP address SHOULD set > the > > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER > or > > + DHCPREQUEST messages that client sends. The BROADCAST bit > will > > + provide a hint to the DHCP server and BOOTP relay agent to > broadcast > > + any messages to the client on the client's subnet. */ > > +packet->dhcp.flags = htobe16(0x8000); > > Hm, most clients can and should use unicast, so we should definitely > not request broadcast unconditionally. If there really is a situation > where we need broadcast, we should detect that and only request > broadcast in this case. > > Does that make sense? > > Cheers, > > Tom > > > /* RFC2132 section 4.1.1: > > The client MUST include its hardware address in the ’chaddr’ > field, if > > necessary for delivery of DHCP reply messages. > > -- > > 1.8.5.2 (Apple Git-48) > > > > > > ___ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > -- *Camilo Aguilar* Software Engineer http://github.com/c4milo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
On Wed, May 28, 2014 at 7:43 PM, Camilo Aguilar wrote: > In systems running on hypervisors this flag needs to be set ON, so offers can > reach > the virtual machines. > > For more information please refer to this thread in CoreOS: > https://github.com/coreos/bugs/issues/12 > > Signed-off-by: Camilo Aguilar > --- > src/libsystemd-network/sd-dhcp-client.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/src/libsystemd-network/sd-dhcp-client.c > b/src/libsystemd-network/sd-dhcp-client.c > index 0300a6b..8f54906 100644 > --- a/src/libsystemd-network/sd-dhcp-client.c > +++ b/src/libsystemd-network/sd-dhcp-client.c > @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client *client, > DHCPPacket **ret, > refuse to issue an DHCP lease if 'secs' is set to zero */ > packet->dhcp.secs = htobe16(client->secs); > > +/* RFC2132 section 4.1 > + A client that cannot receive unicast IP datagrams until its > protocol > + software has been configured with an IP address SHOULD set the > + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or > + DHCPREQUEST messages that client sends. The BROADCAST bit will > + provide a hint to the DHCP server and BOOTP relay agent to > broadcast > + any messages to the client on the client's subnet. */ > +packet->dhcp.flags = htobe16(0x8000); Hm, most clients can and should use unicast, so we should definitely not request broadcast unconditionally. If there really is a situation where we need broadcast, we should detect that and only request broadcast in this case. Does that make sense? Cheers, Tom > /* RFC2132 section 4.1.1: > The client MUST include its hardware address in the ’chaddr’ > field, if > necessary for delivery of DHCP reply messages. > -- > 1.8.5.2 (Apple Git-48) > > > ___ > 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] joystick doesn't respect seat rule
Hi On Wed, May 28, 2014 at 11:07 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 28, 2014 at 09:22:23PM +0200, Floris wrote: >> Op Wed, 28 May 2014 20:38:17 +0200 schreef Mantas Mikulėnas >> : >> >> > >> >So the seat assignment works fine – gdm is added to the ACL. >> > >> >The problem is that the devnode is *world-readable*. >> >> and how can we fix this? > > It has "always" been like this: > > commit d638611c44672dea8d8a498dbe84c7d650ef2194 > Author: Kay Sievers > Date: Fri Aug 10 12:36:59 2007 +0200 > > rules: add default rules > > I guess that the assumption is that this is relatively safe to allow > public reading of joystick and mouse input. Kay, please correct me > if necessary. Correct. joydev devices are always world-readable as games (SDL, steam, ...) rely on the device-nodes. There are some things to note about joydevs: 1) They are deprecated! No features are added, any new application is advised to use evdev exclusively (event devices). Same is true for mousedev and others. Rule of thumb is: evdev is the only node you should use. 2) Input handling other than mouse (which includes trackpads and touchscreens) and keyboard has never been figured out properly. There is XInput, XInput2 and more, but games still use joydev directly. They ignore seat assignments, they ignore permissions, they ignore evdev. It's a mess and there is currently no solution. No, there isn't even anyone working on it. It's a complex task. So unless someone wants to tackle it, we have to deal with the consequences. This includes: applications will ignore seat-assignments for joysticks, gamepads and more. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] joystick doesn't respect seat rule
On Wed, May 28, 2014 at 09:22:23PM +0200, Floris wrote: > Op Wed, 28 May 2014 20:38:17 +0200 schreef Mantas Mikulėnas > : > > > > >So the seat assignment works fine – gdm is added to the ACL. > > > >The problem is that the devnode is *world-readable*. > > and how can we fix this? It has "always" been like this: commit d638611c44672dea8d8a498dbe84c7d650ef2194 Author: Kay Sievers Date: Fri Aug 10 12:36:59 2007 +0200 rules: add default rules I guess that the assumption is that this is relatively safe to allow public reading of joystick and mouse input. Kay, please correct me if necessary. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] journald: Add UDP syslog listener
This is fairly simple, yet useful with netconsole. Remote socket address is not
used to obtain hostname, it would be easy to fake it via UDP anyway, which is
probably not desirable. If clients wish, they should identify themselves via
identifier field in syslog packets.
Disabled by default.
---
man/systemd-journald.service.xml | 6 ++
src/journal/journald-server.c| 16 +---
src/journal/journald-server.h| 1 +
src/journal/journald-syslog.c| 10 ++
units/systemd-journald.socket| 1 +
5 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml
index 715..7c0d277 100644
--- a/man/systemd-journald.service.xml
+++ b/man/systemd-journald.service.xml
@@ -97,6 +97,12 @@
obtains the the handles from systemd via activation
socket-passing
interface, or opens them itself.
+Additionally, journal might be passed an open
+SOCK_DGRAM inet socket, which will be
used for
+an UDP syslog protocol listener. Note that you should not
normally
+need this and it would allow remote machines to inject logs
into
+journal without any authentication.
+
systemd-journald will
forward all received log messages to the
AF_UNIX
SOCK_DGRAM socket
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 381d80a..7f7bf6e 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1108,7 +1108,7 @@ int process_datagram(sd_event_source *es, int fd,
uint32_t revents, void *userda
Server *s = userdata;
assert(s);
-assert(fd == s->native_fd || fd == s->syslog_fd);
+assert(fd == s->native_fd || fd == s->syslog_fd || fd ==
s->syslog_udp_fd);
if (revents != EPOLLIN) {
log_error("Got invalid event from epoll for datagram fd:
%"PRIx32, revents);
@@ -1191,7 +1191,7 @@ int process_datagram(sd_event_source *es, int fd,
uint32_t revents, void *userda
}
}
-if (fd == s->syslog_fd) {
+if (fd == s->syslog_fd || fd == s->syslog_udp_fd) {
if (n > 0 && n_fds == 0) {
s->buffer[n] = 0;
server_process_syslog_message(s,
strstrip(s->buffer), ucred, tv, label, label_len);
@@ -1460,7 +1460,7 @@ int server_init(Server *s) {
assert(s);
zero(*s);
-s->syslog_fd = s->native_fd = s->stdout_fd = s->dev_kmsg_fd =
s->hostname_fd = -1;
+s->syslog_fd = s->syslog_udp_fd = s->native_fd = s->stdout_fd =
s->dev_kmsg_fd = s->hostname_fd = -1;
s->compress = true;
s->seal = true;
@@ -1544,6 +1544,15 @@ int server_init(Server *s) {
s->syslog_fd = fd;
+} else if (sd_is_socket_inet(fd, AF_UNSPEC, SOCK_DGRAM, -1,
514) > 0) {
+
+if (s->syslog_udp_fd >= 0) {
+log_error("Too many syslog UDP sockets
passed.");
+return -EINVAL;
+}
+
+s->syslog_udp_fd = fd;
+
} else {
log_error("Unknown socket passed.");
return -EINVAL;
@@ -1648,6 +1657,7 @@ void server_done(Server *s) {
sd_event_unref(s->event);
safe_close(s->syslog_fd);
+safe_close(s->syslog_udp_fd);
safe_close(s->native_fd);
safe_close(s->stdout_fd);
safe_close(s->dev_kmsg_fd);
diff --git a/src/journal/journald-server.h b/src/journal/journald-server.h
index e468b82..c757704 100644
--- a/src/journal/journald-server.h
+++ b/src/journal/journald-server.h
@@ -56,6 +56,7 @@ typedef struct StdoutStream StdoutStream;
typedef struct Server {
int syslog_fd;
+int syslog_udp_fd;
int native_fd;
int stdout_fd;
int dev_kmsg_fd;
diff --git a/src/journal/journald-syslog.c b/src/journal/journald-syslog.c
index 434eac4..8fe2eae 100644
--- a/src/journal/journald-syslog.c
+++ b/src/journal/journald-syslog.c
@@ -478,6 +478,16 @@ int server_open_syslog_socket(Server *s) {
return r;
}
+if (s->syslog_udp_fd > 0) {
+fd_nonblock(s->syslog_udp_fd, 1);
+
+r = sd_event_add_io(s->event, &s->syslog_event_source,
s->syslog_udp_fd, EPOLLIN, process_datagram, s);
+if (r < 0) {
+log_error("Failed to add syslog server fd to event
loop: %s", strerror(-r));
+return r;
+}
+}
+
return 0;
}
diff --git a/units/systemd-journald.socket b/units/systemd-journald.socket
index fbeb10b..add6785 100644
--- a/units/systemd-journald.socket
+++ b/units/systemd-journ
[systemd-devel] [PATCH 1/2] man: Document server sockets in use by journald
--- man/systemd-journald.service.xml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml index f0ce7aa..715 100644 --- a/man/systemd-journald.service.xml +++ b/man/systemd-journald.service.xml @@ -86,6 +86,17 @@ systemd-journald will then store the data. +Journal listens on +/run/systemd/journal/stdout socket of +SOCK_STREAM type, and +/run/systemd/journal/socket and +/dev/log sockets of +SOCK_DGRAM type in AF_UNIX +family that handle traffic from systemd-cat, +native clients and syslog local clients respectively. It either +obtains the the handles from systemd via activation socket-passing +interface, or opens them itself. + systemd-journald will forward all received log messages to the AF_UNIX SOCK_DGRAM socket -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] joystick doesn't respect seat rule
Op Wed, 28 May 2014 20:38:17 +0200 schreef Mantas Mikulėnas : So the seat assignment works fine – gdm is added to the ACL. The problem is that the devnode is *world-readable*. and how can we fix this? tia, floris___ 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
On Wed, May 28, 2014 at 2:14 AM, Peeters Simon wrote: > 2014-05-28 1:12 GMT+02:00 Thomas H.P. Andersen : >> From: Thomas Hindoe Paaboel Andersen >> >> 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? Thanks. I have changed it to use this 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
[systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1
In systems running on hypervisors this flag needs to be set ON, so offers can reach the virtual machines. For more information please refer to this thread in CoreOS: https://github.com/coreos/bugs/issues/12 Signed-off-by: Camilo Aguilar --- src/libsystemd-network/sd-dhcp-client.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/libsystemd-network/sd-dhcp-client.c b/src/libsystemd-network/sd-dhcp-client.c index 0300a6b..8f54906 100644 --- a/src/libsystemd-network/sd-dhcp-client.c +++ b/src/libsystemd-network/sd-dhcp-client.c @@ -286,6 +286,15 @@ static int client_message_init(sd_dhcp_client *client, DHCPPacket **ret, refuse to issue an DHCP lease if 'secs' is set to zero */ packet->dhcp.secs = htobe16(client->secs); +/* RFC2132 section 4.1 + A client that cannot receive unicast IP datagrams until its protocol + software has been configured with an IP address SHOULD set the + BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or + DHCPREQUEST messages that client sends. The BROADCAST bit will + provide a hint to the DHCP server and BOOTP relay agent to broadcast + any messages to the client on the client's subnet. */ +packet->dhcp.flags = htobe16(0x8000); + /* RFC2132 section 4.1.1: The client MUST include its hardware address in the ???chaddr??? field, if necessary for delivery of DHCP reply messages. -- 1.8.5.2 (Apple Git-48) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] joystick doesn't respect seat rule
So the seat assignment works fine – gdm is added to the ACL. The problem is that the devnode is *world-readable*. -- Mantas Mikulėnas On May 28, 2014 8:57 PM, "Floris" wrote: > Op Wed, 28 May 2014 19:06:22 +0200 schreef Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl>: > > On Wed, May 28, 2014 at 05:45:01PM +0200, Floris wrote: >> >>> >Are you logged in as the same user on both seats? >>> > >>> >>> Nobody is logged in on seat1 >>> >>> >I think the difference is that with `jstest`, the device doesn't >>> >interact with your seat, but *you* are interacting directly with its >>> >device node, so the only thing that's checked is devnode >>> >permissions... >>> > >>> >>> When I start a game on seat0 I can use the joystick attached to seat1 >>> >> What does 'getfacl /dev/input/js0' say? And 'loginctl seat-status seat1'? >> >> Zbyszek >> >> $ getfacl /dev/input/js0 > getfacl: Removing leading '/' from absolute path names > # file: dev/input/js0 > # owner: root > # group: root > user::rw- > user:Debian-gdm:rw- > group::r-- > mask::rw- > other::r-- > > $ loginctl seat-status seat1 > seat1 > Sessions: *c1 > Devices: > ├─/sys/devices/pci:00/:00:05.0/:02:00.0 > │ [MASTER] pci::02:00.0 > ├─/sys/devices/pci:00/:00:05.0/:02:00.1/ > sound/card1 > │ sound:card1 "NVidia" > │ ├─/sys/devices/pci:00/:00:05.0/:02:00.1/ > sound/card1/input14 > │ │ input:input14 "HDA NVidia HDMI/DP,pcm=7" > │ └─/sys/devices/pci:00/:00:05.0/:02:00.1/ > sound/card1/input5 > │ input:input5 "HDA NVidia HDMI/DP,pcm=3" > ├─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4 > │ usb:1-1.4 > │ ├─/sys/devices/pci...000: > 00:1a.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/0003:05FE:0011. > 0005/input/input19 > │ │ input:input19 "Cypress Sem PS2/USB Browser Combo > Mouse" > │ ├─/sys/devices/pci...000: > 00:1a.0/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.0/0003:046D:C312. > 0006/input/input20 > │ │ input:input20 "BTC USB Multimedia Keyboard" > │ ├─/sys/devices/pci...000: > 00:1a.0/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.1/0003:046D:C312. > 0007/input/input21 > │ │ input:input21 "BTC USB Multimedia Keyboard" > │ ├─/sys/devices/pci...000: > 00:1a.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006. > 0008/input/input22 > │ │ input:input22 "DragonRise Inc. Generic USB > Joystick " > │ │ ├─/sys/devices/pci...0/ > usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/ > input/input22/event19 > │ │ │ input:event19 > │ │ └─/sys/devices/pci...:1a. > 0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22/js0 > │ │ input:js0 > │ └─/sys/devices/pci...000: > 00:1a.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006. > 0009/input/input23 > │ input:input23 "DragonRise Inc. Generic USB > Joystick " > │ ├─/sys/devices/pci...0/ > usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006.0009/ > input/input23/event20 > │ │ input:event20 > │ └─/sys/devices/pci...:1a. > 0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006.0009/input/input23/js1 > │ input:js1 > └─/sys/devices/pci:00/:00:1e.0/:08:02.0/ > sound/card2 > sound:card2 "Live" > ___ > 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] joystick doesn't respect seat rule
Op Wed, 28 May 2014 19:06:22 +0200 schreef Zbigniew Jędrzejewski-Szmek : On Wed, May 28, 2014 at 05:45:01PM +0200, Floris wrote: >Are you logged in as the same user on both seats? > Nobody is logged in on seat1 >I think the difference is that with `jstest`, the device doesn't >interact with your seat, but *you* are interacting directly with its >device node, so the only thing that's checked is devnode >permissions... > When I start a game on seat0 I can use the joystick attached to seat1 What does 'getfacl /dev/input/js0' say? And 'loginctl seat-status seat1'? Zbyszek $ getfacl /dev/input/js0 getfacl: Removing leading '/' from absolute path names # file: dev/input/js0 # owner: root # group: root user::rw- user:Debian-gdm:rw- group::r-- mask::rw- other::r-- $ loginctl seat-status seat1 seat1 Sessions: *c1 Devices: ├─/sys/devices/pci:00/:00:05.0/:02:00.0 │ [MASTER] pci::02:00.0 ├─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card1 │ sound:card1 "NVidia" │ ├─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card1/input14 │ │ input:input14 "HDA NVidia HDMI/DP,pcm=7" │ └─/sys/devices/pci:00/:00:05.0/:02:00.1/sound/card1/input5 │ input:input5 "HDA NVidia HDMI/DP,pcm=3" ├─/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4 │ usb:1-1.4 │ ├─/sys/devices/pci...000:00:1a.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.0/0003:05FE:0011.0005/input/input19 │ │ input:input19 "Cypress Sem PS2/USB Browser Combo Mouse" │ ├─/sys/devices/pci...000:00:1a.0/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.0/0003:046D:C312.0006/input/input20 │ │ input:input20 "BTC USB Multimedia Keyboard" │ ├─/sys/devices/pci...000:00:1a.0/usb1/1-1/1-1.4/1-1.4.2/1-1.4.2:1.1/0003:046D:C312.0007/input/input21 │ │ input:input21 "BTC USB Multimedia Keyboard" │ ├─/sys/devices/pci...000:00:1a.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22 │ │ input:input22 "DragonRise Inc. Generic USB Joystick " │ │ ├─/sys/devices/pci...0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22/event19 │ │ │ input:event19 │ │ └─/sys/devices/pci...:1a.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22/js0 │ │ input:js0 │ └─/sys/devices/pci...000:00:1a.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006.0009/input/input23 │ input:input23 "DragonRise Inc. Generic USB Joystick " │ ├─/sys/devices/pci...0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006.0009/input/input23/event20 │ │ input:event20 │ └─/sys/devices/pci...:1a.0/usb1/1-1/1-1.4/1-1.4.4/1-1.4.4:1.0/0003:0079:0006.0009/input/input23/js1 │ input:js1 └─/sys/devices/pci:00/:00:1e.0/:08:02.0/sound/card2 sound:card2 "Live" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] joystick doesn't respect seat rule
On Wed, May 28, 2014 at 05:45:01PM +0200, Floris wrote: > >Are you logged in as the same user on both seats? > > > > Nobody is logged in on seat1 > > >I think the difference is that with `jstest`, the device doesn't > >interact with your seat, but *you* are interacting directly with its > >device node, so the only thing that's checked is devnode > >permissions... > > > > When I start a game on seat0 I can use the joystick attached to seat1 What does 'getfacl /dev/input/js0' say? And 'loginctl seat-status seat1'? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] joystick doesn't respect seat rule
Are you logged in as the same user on both seats? Nobody is logged in on seat1 I think the difference is that with `jstest`, the device doesn't interact with your seat, but *you* are interacting directly with its device node, so the only thing that's checked is devnode permissions... When I start a game on seat0 I can use the joystick attached to seat1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] units: use KillMode=mixed for systemd-nspawn@.service
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..e373628 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=mixed 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] units: use KillMode=process for systemd-nspawn@.service
On 28/05/2014 10:32 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, May 28, 2014 at 05:42:31PM +1000, Jonathan Liu wrote: On 28 May 2014 14:06, David Timothy Strauss wrote: On Tue, May 27, 2014 at 10:55 PM, Jonathan Liu wrote: 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. Is it reasonable to have no timeout, though? The weight (in terms of state and shutdown time) of what runs in most containers isn't more substantial than what runs in most services. It's not hard to override the instance if it's necessary to have a longer timeout or no timeout. There is still a timeout with KillMode=process. It's not a question of timeouts, but of what is killed. With "process", only the main process itself is killed. Normally this should be enough, because the init in the container will kill eveything else. But if it malfunctions, other processes from the container could be left around. So we don't want that. But the default is "control-group", which does not seem right either in case of containers. IIUC, host's systemd will send SIGTERM to all processes in the container. We should probably be using "mixed" instead. Killing systemd-nspawn kills the container processes as well. I am just following the wiki at http://fedoraproject.org/wiki/Features/SystemdLightweightContainers "mixed" was added in 209, much later than this page was written. Zbyszek Okay, I will resubmit patch using KillMode=mixed. 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
On Wed, 28 May 2014 11:55:08 +0400 Kirill Elagin wrote: > Might be that rfkill1 disappears after rfkill0 is switched off, if they are > related. Right. Additionally, on my system one rfkill? controls multiple devices. This is why I suggested disabling systemd state-storing at all: it works OK in simple cases, but is meaningless and breaks things on tricky hardware. > > > -- > Кирилл Елагин > Cheers, -- 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] joystick doesn't respect seat rule
On Wed, May 28, 2014 at 5:28 PM, Floris wrote:
> Hey,
>
> I have created an udev rule for an usb hub with "loginctl attach" so every
> device I plug-in will go to seat1
> $cat /etc/udev/rules.d/72-seat-usb-pci-_00_1a_0-usb-0_1_4.rules
> TAG=="seat", ENV{ID_FOR_SEAT}=="usb-pci-_00_1a_0-usb-0_1_4",
> ENV{ID_SEAT}="seat1"
>
> Nevertheless, when I plug-in a joystick on seat1, it is also working on
> seat0
>
> I would expect the same behavior as a keyboard or a mouse. A device on seat1
> does not interact with seat0
>
> $ jstest /dev/input/js0 #run on seat0
> Driver version is 2.1.0.
> Joystick (DragonRise Inc. Generic USB Joystick ) has 7 axes (X, Y, Z,
> Rx, Rz, Hat0X, Hat0Y)
> and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn,
> BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
> Testing ... (interrupt to exit)
Are you logged in as the same user on both seats?
I think the difference is that with `jstest`, the device doesn't
interact with your seat, but *you* are interacting directly with its
device node, so the only thing that's checked is devnode
permissions...
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] joystick doesn't respect seat rule
Hey,
I have created an udev rule for an usb hub with "loginctl attach" so every
device I plug-in will go to seat1
$cat /etc/udev/rules.d/72-seat-usb-pci-_00_1a_0-usb-0_1_4.rules
TAG=="seat", ENV{ID_FOR_SEAT}=="usb-pci-_00_1a_0-usb-0_1_4",
ENV{ID_SEAT}="seat1"
Nevertheless, when I plug-in a joystick on seat1, it is also working on
seat0
I would expect the same behavior as a keyboard or a mouse. A device on
seat1 does not interact with seat0
$ jstest /dev/input/js0 #run on seat0
Driver version is 2.1.0.
Joystick (DragonRise Inc. Generic USB Joystick ) has 7 axes (X, Y,
Z, Rx, Rz, Hat0X, Hat0Y)
and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn,
BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
Testing ... (interrupt to exit)
...
$ udevadm info --query=all --name=input/js0
P:
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22/js0
N: input/js0
S: input/by-id/usb-DragonRise_Inc._Generic_USB_Joystick-joystick
S: input/by-path/pci-:00:1a.0-usb-0:1.4.3:1.0-joystick
E:
DEVLINKS=/dev/input/by-id/usb-DragonRise_Inc._Generic_USB_Joystick-joystick
/dev/input/by-path/pci-:00:1a.0-usb-0:1.4.3:1.0-joystick
E: DEVNAME=/dev/input/js0
E:
DEVPATH=/devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4.3/1-1.4.3:1.0/0003:0079:0006.0008/input/input22/js0
E: ID_BUS=usb
E: ID_FOR_SEAT=input-pci-_00_1a_0-usb-0_1_4_3_1_0
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_MODEL=Generic_USB_Joystick
E: ID_MODEL_ENC=Generic\x20\x20\x20USB\x20\x20Joystick\x20\x20
E: ID_MODEL_ID=0006
E: ID_PATH=pci-:00:1a.0-usb-0:1.4.3:1.0
E: ID_PATH_TAG=pci-_00_1a_0-usb-0_1_4_3_1_0
E: ID_REVISION=0107
E: ID_SEAT=seat1
E: ID_SERIAL=DragonRise_Inc._Generic_USB_Joystick
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:03:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=DragonRise_Inc.
E: ID_VENDOR_ENC=DragonRise\x20Inc.\x20\x20
E: ID_VENDOR_ID=0079
E: MAJOR=13
E: MINOR=0
E: SUBSYSTEM=input
E: TAGS=:seat:seat1:uaccess:
E: USEC_INITIALIZED=776894
___
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
On 05/28/2014 01:52 PM, Mantas Mikulėnas wrote: Not sure what security hole you see here. If the executable owns cap_foo=ei (*not* cap_foo=eip), then running it will not grant any capabilities unless its process (or the parent process) explicitly adds them to the inheritable set... And that's the solution - using "ei" instead of "eip". Why I haven't thought about it earlier... Thank you very much! BRs, Michal ___ 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
On Wed, May 28, 2014 at 05:42:31PM +1000, Jonathan Liu wrote: > On 28 May 2014 14:06, David Timothy Strauss wrote: > > On Tue, May 27, 2014 at 10:55 PM, Jonathan Liu wrote: > >> 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. > > > > Is it reasonable to have no timeout, though? The weight (in terms of > > state and shutdown time) of what runs in most containers isn't more > > substantial than what runs in most services. It's not hard to override > > the instance if it's necessary to have a longer timeout or no timeout. > > There is still a timeout with KillMode=process. It's not a question of timeouts, but of what is killed. With "process", only the main process itself is killed. Normally this should be enough, because the init in the container will kill eveything else. But if it malfunctions, other processes from the container could be left around. So we don't want that. But the default is "control-group", which does not seem right either in case of containers. IIUC, host's systemd will send SIGTERM to all processes in the container. We should probably be using "mixed" instead. > Killing systemd-nspawn kills the container processes as well. > I am just following the wiki at > http://fedoraproject.org/wiki/Features/SystemdLightweightContainers "mixed" was added in 209, much later than this page was written. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to bring up bonding interface (dracut+system)
2014-05-28 15:57 GMT+04:00 Harald Hoyer : > > ?? something in your real root system assigning MAC adresses to the > interfaces? > > which distribution? I'm using exherbo (gentoo like system) with latest systemd release. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to bring up bonding interface (dracut+system)
2014-05-28 15:57 GMT+04:00 Harald Hoyer : > ?? something in your real root system assigning MAC adresses to the > interfaces? > > which distribution? > I'm using exherbo (gentoo like system) with latest systemd release. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ 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
On Wed, May 28, 2014 at 1:59 PM, Michael Biebl wrote: > 2014-05-28 11:58 GMT+02:00 Thomas H.P. Andersen : >> On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek >> wrote: >>> On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: From: Thomas Hindoe Paaboel Andersen 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? >> The start priority in chkconfig was already removed in 213 so the only >> thing was the runlevels. The runlevels were only used to determine if >> the runlevel was special (not 1-5). Since special runlevels was >> dropped way back I don't see any reason to read the chkconfig at all. > > Wasn't there also the # pidfile: parsing as part of the chkconfig header? Pidfile is still parsed. I only dropped the line with start priority and runlevels. > -- > 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] [RFC] Move handling of sysv initscripts to a generator
2014-05-28 11:58 GMT+02:00 Thomas H.P. Andersen : > On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: >>> From: Thomas Hindoe Paaboel Andersen >>> >>> 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? > The start priority in chkconfig was already removed in 213 so the only > thing was the runlevels. The runlevels were only used to determine if > the runlevel was special (not 1-5). Since special runlevels was > dropped way back I don't see any reason to read the chkconfig at all. Wasn't there also the # pidfile: parsing as part of the chkconfig header? -- 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] failed to bring up bonding interface (dracut+system)
On 24.05.2014 09:02, Vasiliy Tolstov wrote: > Hello. > I'm using dracut to create initramfs and systemd. > Dracut configures bond and all works fine, but then it shutdowns and > switch rooti, mac address of slave interfaces (eth0 and eth1) changed, > but bonding mac saves the same. After that bond interface not works. > How to prevent this fail? > If i rmmod igb driver and load it mac addresses change to normal and > all works fine. > dracut from current master, system - 212. > > my /proc/cmdline > bond=bond0:eth0,eth1:mode=balance-xor,miimon=100,updelay=200,downdelay=200 > net.ifnames=0 ip=bond0:auto6:9000 rd.bootif=0 rd.md=0 rd.dm=0 rd.lvm=0 > rd.luks=0 console=tty0 console=ttyS1,115200 rw > root=live:http://[2001:db8:0:f101:92e2:baff:fe31:44c]/image/mh-vm/image.squashfs > rd.live.size=1G > chef=http://[2001:db8:0:f101:92e2:baff:fe31:44c]/chef/vm09 rd.shell > raid=noautodetect rdshell rd.debug rdnetdebug > > Invalid mac addresses is > ba:ee:69:7c:ed:4e > 4a:0f:e8:44:93:35 > Valid mac addreses is > 00:25:90:d5:bf:bc > 00:25:90:d5:bf:bd > > ?? something in your real root system assigning MAC adresses to the interfaces? which distribution? ___ 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
On Wed, May 28, 2014 at 1:37 PM, Michal Witanowski wrote: > > On 05/28/2014 12:07 AM, Serge Hallyn wrote: >> >> Quoting Mantas Mikulėnas (graw...@gmail.com): >>> >>> On Tue, May 27, 2014 at 4:31 PM, Michal Witanowski >>> 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. >> >> Correct. keep_caps is about not dropping the capabilities when dropping >> all 0 uids, i.e. when systemd does setuid(test). But systemd is going >> to proceed to exec(), causing the capabilities to be re-execed from >> there. >> >> So as Mantas wrote, I think what you want is to set >> cap_sys_admin,cap_dac_override,cap_mac_override=ie to the file you are >> executing. So long as you don't also set it to 'p', this should be ok >> as only processes with cap_sys_admin,cap_dac_override,cap_mac_override=i >> will inherit it from the file. >> >> Kinda neat, I especially like the ability to also lock the >> service into no-setuid and noroot secbits. >> >> -serge >> > The executable does not own any capabilities, since setting them in RPM > scripts would be a security hole. Of course, enabling them manually fixes Not sure what security hole you see here. If the executable owns cap_foo=ei (*not* cap_foo=eip), then running it will not grant any capabilities unless its process (or the parent process) explicitly adds them to the inheritable set... > the problem, but it does not explain the difference in caps set when > launching an app as root vs. non-root, ie. when UID==0, the formula: > > > P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & > cap_bset) > > doesn't work. Does it mean that when launching an app as root, exec() is not > called at all and the process gains full capabilities set (except > restrictions introduced by bounding set)? Is the only solution to this > problem setting the file caps before service starting? When launching the app as root, exec() *is* called of course, but the difference is that uid 0 always has all capabilities after an exec (unless the "noroot" securebit was set): "Capabilities and execution of programs by root In order to provide an all-powerful root using capability sets, during an execve(2): 1. If a set-user-ID-root program is being executed, or the real user ID of the process is 0 (root) then the file inheritable and permitted sets are defined to be all ones (i.e., all capabilities enabled)." -- Mantas Mikulėnas ___ 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
On 05/28/2014 12:07 AM, Serge Hallyn wrote: Quoting Mantas Mikulėnas (graw...@gmail.com): On Tue, May 27, 2014 at 4:31 PM, Michal Witanowski 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. Correct. keep_caps is about not dropping the capabilities when dropping all 0 uids, i.e. when systemd does setuid(test). But systemd is going to proceed to exec(), causing the capabilities to be re-execed from there. So as Mantas wrote, I think what you want is to set cap_sys_admin,cap_dac_override,cap_mac_override=ie to the file you are executing. So long as you don't also set it to 'p', this should be ok as only processes with cap_sys_admin,cap_dac_override,cap_mac_override=i will inherit it from the file. Kinda neat, I especially like the ability to also lock the service into no-setuid and noroot secbits. -serge The executable does not own any capabilities, since setting them in RPM scripts would be a security hole. Of course, enabling them manually fixes the problem, but it does not explain the difference in caps set when launching an app as root vs. non-root, ie. when UID==0, the formula: P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset) doesn't work. Does it mean that when launching an app as root, exec() is not called at all and the process gains full capabilities set (except restrictions introduced by bounding set)? Is the only solution to this problem setting the file caps before service starting? BRs, Michal ___ 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
On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: >> From: Thomas Hindoe Paaboel Andersen >> >> 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? The start priority in chkconfig was already removed in 213 so the only thing was the runlevels. The runlevels were only used to determine if the runlevel was special (not 1-5). Since special runlevels was dropped way back I don't see any reason to read the chkconfig at all. >> 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. Definitely something to address before the patch is ready. I only meant to highlight the issue in case anybody wanted to test it. >> 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. Thanks Zbyszek. I will resend the patch tonight with fixes for your comments. >> --- >> .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.
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 22:14, Kirill Elagin (kirela...@gmail.com) wrote: > > > > 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 we don't really ever "prohibit" anything. People can do whatever they want to do... That said, I think IPv4 connectivity is kinda important if we ever want to minimize the differences between container-based virtualization and normal systems. I want containers to be as close to a real OS as possible and that includes being able to communicate with the usual internet. I mean, we will have a strong focus on making things work with IPv6 nicely, and I have the suspicion we can make a number of things nicer with Ipv6 than with IPv4 (since we could automatically assign an externally routable IPv6 address for each container, which is not really doable for IPv4). > 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? Ipv4LL is inherently not routable. We want something here though that can talk to the internet if it wants to. > 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”. DHCP is actually one of the simplest protocols I am aware of... 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
On Tue, 27.05.14 14:48, 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? I don't see that these are really that common on most Linux machines, except on "border" systems. I mean, they are uncommon enough that I never in my life touched a system with these in place, I must admit... > I take DHCPv6 and IPv6 RA are a > given that'll be implemented. Yes. 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] shorten_uuid: use proper table size
16.05.2014 at 16:41 Lennart Poettering wrote:
On Fri, 16.05.14 11:00, Maciej Wereski (m.were...@partner.samsung.com)
wrote:
---
src/core/machine-id-setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
index 2a58e48..0544117 100644
--- a/src/core/machine-id-setup.c
+++ b/src/core/machine-id-setup.c
@@ -38,7 +38,7 @@
#include "fileio.h"
#include "path-util.h"
-static int shorten_uuid(char destination[36], const char *source) {
+static int shorten_uuid(char destination[34], const char *source) {
unsigned i, j;
for (i = 0, j = 0; i < 36 && j < 32; i++) {
Hmm? This patch doesn't look right.
When the function is called the buffer is filled with 36 chars, and we
then strip the non-hex-chars, so that 34 chars result. But the function
signature should still indicate that we need 36 chars initially..
Lennart
Well, i (< 36) is used for source and j (< 32) is used for destination.
After the loop destination[32] and destination[33] is set. Also
shorten_uuid() is used in two places, where id[34] is passed as
destination. So it looked for me like destination should be 34.
regards,
--
Maciej Wereski
Samsung R&D Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 213
Heya! http://www.freedesktop.org/software/systemd/systemd-213.tar.xz Some new features, lots of bugfixes. CHANGES WITH 213: * A new "systemd-timesyncd" daemon has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd. * The queue "seqnum" interface of libudev has been disabled, as it was generally incompatible with device namespacing as sequence numbers of devices go "missing" if the devices are part of a different namespace. * "systemctl list-timers" and "systemctl list-sockets" gained a --recursive switch for showing units of these types also for all local containers, similar in style to the already supported --recursive switch for "systemctl list-units". * A new RebootArgument= setting has been added for service units, which may be used to specify a kernel reboot argument to use when triggering reboots with StartLimitAction=. * A new FailureAction= setting has been added for service units which may be used to specify an operation to trigger when a service fails. This works similarly to StartLimitAction=, but unlike it controls what is done immediately rather than only after several attempts to restart the service in question. * hostnamed got updated to also expose the kernel name, release, and version on the bus. This is useful for executing commands like hostnamectl with the -H switch. systemd-analyze makes use of this to properly display details when running non-locally. * The bootchart tool can now show cgroup information in the graphs it generates. * The CFS CPU quota cgroup attribute is now exposed for services. The new CPUQuota= switch has been added for this which takes a percentage value. Setting this will have the result that a service may never get more CPU time than the specified percentage, even if the machine is otherwise idle. * systemd-networkd learned IPIP and SIT tunnel support. * LSB init scripts exposing a dependency on $network will now get a dependency on network-online.target rather than simply network.target. This should bring LSB handling closer to what it was on SysV systems. * A new fsck.repair= kernel option has been added to control how fsck shall deal with unclean file systems at boot. * The (.ini) configuration file parser will now silently ignore sections whose name begins with "X-". This may be used to maintain application-specific extension sections in unit files. * machined gained a new API to query the IP addresses of registered containers. "machinectl status" has been updated to show these addresses in its output. * A new call sd_uid_get_display() has been added to the sd-login APIs for querying the "primary" session of a user. The "primary" session of the user is elected from the user's sessions and generally a graphical session is preferred over a text one. * A minimal systemd-resolved daemon has been added. It currently simply acts as a companion to systemd-networkd and manages resolv.conf based on per-interface DNS configuration, possibly supplied via DHCP. In the long run we hope to extend this into a local DNSSEC enabled DNS and mDNS cache. * The systemd-networkd-wait-online tool is now enabled by default. It will delay network-online.target until a net
Re: [systemd-devel] handling mount failure in initramfs context
On 05/28/14 at 09:57am, Przemyslaw Rudy wrote: > I use 'auto,fail' in fstab line options, however I have rootfs > dependency to it so fail means all will fail. How do you do that? Are you saying that you create a explicit dependency on sysroot.mount to your xxx.mount from /etc/fstab? Thanks WANG Chao > > On 05/26/2014 09:12 AM, 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? > > > > Thanks in advance! > > > > WANG Chao > > ___ > > 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] handling mount failure in initramfs context
I use 'auto,fail' in fstab line options, however I have rootfs dependency to it so fail means all will fail. On 05/26/2014 09:12 AM, 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? > > Thanks in advance! > > WANG Chao > ___ > 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] How do I disable rfkill1 service? I only have slot 0 and 2
Might be that rfkill1 disappears after rfkill0 is switched off, if they are related. -- Кирилл Елагин On Wed, May 28, 2014 at 8:43 AM, Mantas Mikulėnas wrote: > On May 28, 2014 3:25 AM, "Aaron Lewis" 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 > > ___ > 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] [PATCH] units: use KillMode=process for systemd-nspawn@.service
On 28 May 2014 14:06, David Timothy Strauss wrote: > On Tue, May 27, 2014 at 10:55 PM, Jonathan Liu wrote: >> 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. > > Is it reasonable to have no timeout, though? The weight (in terms of > state and shutdown time) of what runs in most containers isn't more > substantial than what runs in most services. It's not hard to override > the instance if it's necessary to have a longer timeout or no timeout. There is still a timeout with KillMode=process. Killing systemd-nspawn kills the container processes as well. I am just following the wiki at http://fedoraproject.org/wiki/Features/SystemdLightweightContainers Regards, Jonathan ___ 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
On Tue, 2014-05-27 at 13:39 +0200, David Herrmann wrote: > 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. I strongly agree with David here. Any form of tethering or WiFi P2P in addition to uplink network setup involving DHCPv4 clients just becomes impossible to maintain in a consistent way if the client and server parts are loosely coupled. With the wild west of IPv4 private addressing there needs to be a consistent and quick way of reacting to the newly acquired IPv4 subnet should it conflict with the existing one(s) handed out locally by the DHCPv4 server. This of course applies towards the client end usage as a virtual server/container setup is a more strictly controlled environment. Cheers, Patrik ___ 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
On Tue, 2014-05-27 at 22:31 -0500, David Timothy Strauss wrote: > 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. Hi David, Thanks for reply. However I found the culprit - I misconfigured pam by accident so that pam_systemd was never called. Once I fixed it mosh/tmux worked OOTB without need of adding PAM support. Matthew 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
