Re: [systemd-devel] [RFT] DHCPv4 support in networkd

2014-01-06 Thread Holger Winkelmann [TP]
just a small off topic question here. How far is IPv6 support in
networks incl. DHCPv6?

Many thanks and a happy new year!

Holger


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


Re: [systemd-devel] [RFT] DHCPv4 support in networkd

2014-01-06 Thread Tom Gundersen
On Mon, Jan 6, 2014 at 10:43 AM, Holger Winkelmann [TP]
h...@travelping.com wrote:
 just a small off topic question here. How far is IPv6 support in
 networks incl. DHCPv6?

So far we only support static IPv6.

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


[systemd-devel] Starting in a network name?

2014-01-06 Thread Holger Schurig
Hi, I used ip netns commands to setup several network namespaces.
Now I want to run a user-space (non-root) in one of those netspaces.
ip netns exec NAME COMMAND seems to only work for root, not normal
users.

Is there a way to configure a systemd unit to run in a *specific*
network namespace?  I mean similar to, but more general than,
PrivateNetwork=true and JoinsNamespaceOf= ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/2] Add switch_apparmor_profile helper, to switch the profile of the next command to run. This can be used to load a custom apparmor profile for a unit.

2014-01-06 Thread Michael Scherer
Le lundi 06 janvier 2014 à 03:20 +0100, Zbigniew Jędrzejewski-Szmek a
écrit :
 On Fri, Jan 03, 2014 at 05:22:42PM +0100, m...@zarb.org wrote:
  From: Michael Scherer m...@zarb.org
  
  ---
   src/shared/apparmor-util.c | 15 +++
   src/shared/apparmor-util.h |  1 +
   2 files changed, 16 insertions(+)
  
  diff --git a/src/shared/apparmor-util.c b/src/shared/apparmor-util.c
  index 2b85da1..a75bec4 100644
  --- a/src/shared/apparmor-util.c
  +++ b/src/shared/apparmor-util.c
  @@ -39,3 +39,18 @@ bool use_apparmor(void) {
   
   return use_apparmor_cached;
   }
  +
  +int switch_apparmor_profile(const char * profile) {
  +_cleanup_free_ char *filename = NULL;
  +_cleanup_fclose_ FILE *proc = NULL;
  +
  +if (asprintf (filename, /proc/%d/attr/exec, getpid()) 0)
  +return -ENOMEM;
  +
  +proc = fopen (filename, w);
  +if (! proc)
  +return -errno;
  +
  +fprintf (proc, exec %s\n, profile);
  +return 0;
  +}
 This should be something like
 
 int apparmor_switch_profile(const char *profile) {
 char *p, *t;
 
 p = procfs_file_alloca(0, attr/exec);
   t = strappenda(exec , profile);
 
   return write_string_file(p, t);
 }
 
 Totally untested, but there's no unnecessary malloc, and there's
 a meaningful error returned if the thing most likely to fail, i.e. the
 write, actually fails.
   
I rewrote this part using libapparmor, so the new patch is simpler
( didn't send yet, I am adding the support of ignoring with '-' and
doing a few more tests ), so please do not merge this one :).

I will also look at adding a test, but this requires kernel support to
work ( but I can test this is a no-op ).
-- 
Michael Scherer

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


Re: [systemd-devel] [WIP][RFC][PATCH] networkd: generate resolv.conf

2014-01-06 Thread Djalal Harouni
On Mon, Jan 06, 2014 at 12:50:23AM +0100, Tom Gundersen wrote:
 Hi Djalal,
 
 On Mon, Jan 6, 2014 at 12:17 AM, Djalal Harouni tix...@opendz.org wrote:
   1) nameservers receieved over DHCP
   2) nameservers statically configured in a currently active .network file
   3) nameservers statically configured in the global networkd configuration 
  file
 
 [...]
 
  So first question: do you agree with adding this functionality?
 
  Second question: do you agree with the order of precedence I listed above?
  I'll comment on this:
 
  IMO by default try to not be so intrusive
 
 What in particular do you find intrusive?
IMHO and from a user point of view:
*If there are* static nameservers they should take precedence and avoid
probing DHCP nameservers.

   unless *told* so, some configs
  need their prefered/trusted nameservers.
 
 With the current patch the admin (or packager) needs to add the
 /etc/resolv.conf - /run/systemd/network/resolv.conf symlink to get
 any of this at all. If we assume this symlink is in place, I intend to
 still make sure the admin has the full power by having the option of
 statically configuring global and per-NIC nameservers (though these
 will still apply globally due to how resolv.conf works). I'll also add
 an option to opt-out of using the DNS servers received over DHCP.
 
 Does that sound ok to you?
Hmm, you say to opt-out of using the DHCP nameservers?

IMHO that would be nice to opt-in for DHCP nameservers if there are no
static nameservers or if the networkd config tells this.

For the first part of the /etc/resolv.con symlink that sounds good.

(per-NIC nameservers will be really nice! :-)

Thanks Tom

 Cheers,
 
 Tom

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


Re: [systemd-devel] [PATCH] core: support Distribute=n to distribute to n workers

2014-01-06 Thread David Timothy Strauss
On Sun, Jan 5, 2014 at 1:44 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 3. The strategy of dup()ing the socket doesn't work. I wrote
a simple server in python which logs the connections [2], and hooked
it up into systemd [3-4] (*). If REUSEPORT was working correctly,
each connection would be handled by just one instance, either created
previously, or newly created by systemd for this connection. But
I see the same connection being accept()ed by one of the instances
and systemd itself spawning a new instance. I'm pretty sure that what
Lennart wrote before, that you need to create a new socket bound to
the same port for REUSEPORT to take effect, is true.

I've also seen pretty even (but not perfect, especially with
event-based designs) distribution with multiple processes simply
running accept() on the same inherited socket.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] initial sd-dns commit

2014-01-06 Thread Daniel Buch
Hi again,

Im hopeing we can continue in-tree since its easier from here, and im unable to 
get the time i want at the moment.
But i will ofcourse continue to help where i can when time permits.

I think the file nameing and locations are right?

Anyway heres what i got so far

---
 Makefile.am   |   29 +
 src/libsystemd-dns/asyncns-util.h |8 +
 src/libsystemd-dns/asyncns.c  | 1158 +
 src/libsystemd-dns/test-asyncns.c |  164 ++
 src/systemd/sd-dns.h  |  156 +
 5 files changed, 1515 insertions(+)
 create mode 100644 src/libsystemd-dns/asyncns-util.h
 create mode 100644 src/libsystemd-dns/asyncns.c
 create mode 100644 src/libsystemd-dns/test-asyncns.c
 create mode 100644 src/systemd/sd-dns.h

diff --git a/Makefile.am b/Makefile.am
index 069583c..9ae123a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -662,6 +662,35 @@ tests += \
 
 # 
--
 noinst_LTLIBRARIES += \
+   libsystemd-dns.la
+
+libsystemd_dns_la_SOURCES = \
+   src/systemd/sd-asyncns.h \
+   src/libsystemd-dns/asyncns.c \
+   src/libsystemd-dns/asyncns-util.h
+
+libsystemd_dns_la_LIBADD = \
+   libsystemd-shared.la
+
+libsystemd_dns_la_CFLAGS = \
+   -pthread
+
+test_dns_SOURCES = \
+   src/libsystemd-dns/test-asyncns.c \
+   src/systemd/sd-dns.h
+
+test_dns_LDADD = \
+   libsystemd-dns.la
+
+test_dns_LDFLAGS = \
+   -lresolv \
+   -pthread
+
+tests += \
+test-dns
+
+# 
--
+noinst_LTLIBRARIES += \
libsystemd-shared.la
 
 libsystemd_shared_la_SOURCES = \
diff --git a/src/libsystemd-dns/asyncns-util.h 
b/src/libsystemd-dns/asyncns-util.h
new file mode 100644
index 000..31d19bd
--- /dev/null
+++ b/src/libsystemd-dns/asyncns-util.h
@@ -0,0 +1,8 @@
+#pragma once
+
+DEFINE_TRIVIAL_CLEANUP_FUNC(asyncns_t*, asyncns_free);
+DEFINE_TRIVIAL_CLEANUP_FUNC(unsigned char *, asyncns_freeanswer);
+DEFINE_TRIVIAL_CLEANUP_FUNC(struct addrinfo*, asyncns_freeaddrinfo);
+#define _cleanup_asyncns_free_ _cleanup_(asyncns_freep)
+#define _cleanup_asyncns_answer_free_ _cleanup_(asyncns_freeanswerp)
+#define _cleanup_asyncns_addrinfo_free_ _cleanup_(asyncns_freeaddrinfop)
diff --git a/src/libsystemd-dns/asyncns.c b/src/libsystemd-dns/asyncns.c
new file mode 100644
index 000..508f6b0
--- /dev/null
+++ b/src/libsystemd-dns/asyncns.c
@@ -0,0 +1,1158 @@
+/***
+  This file is part of libasyncns.
+
+  Copyright 2005-2008 Lennart Poettering
+
+  libasyncns 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.
+
+  libasyncns 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 libasyncns. If not, see
+  http://www.gnu.org/licenses/.
+ ***/
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include assert.h
+#include fcntl.h
+#include signal.h
+#include unistd.h
+#include sys/select.h
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include errno.h
+#include sys/wait.h
+#include sys/types.h
+#include pwd.h
+#include netinet/in.h
+#include arpa/nameser.h
+#include resolv.h
+#include dirent.h
+#include sys/time.h
+#include sys/resource.h
+#include stdint.h
+#include pthread.h
+
+#ifdef HAVE_SYS_PRCTL_H
+#include sys/prctl.h
+#endif
+
+#include sd-dns.h
+#include util.h
+
+#define MAX_WORKERS 16
+#define MAX_QUERIES 256
+#define BUFSIZE (10240)
+
+typedef enum {
+REQUEST_ADDRINFO,
+RESPONSE_ADDRINFO,
+REQUEST_NAMEINFO,
+RESPONSE_NAMEINFO,
+REQUEST_RES_QUERY,
+REQUEST_RES_SEARCH,
+RESPONSE_RES,
+REQUEST_TERMINATE,
+RESPONSE_DIED
+} query_type_t;
+
+enum {
+REQUEST_RECV_FD = 0,
+REQUEST_SEND_FD = 1,
+RESPONSE_RECV_FD = 2,
+RESPONSE_SEND_FD = 3,
+MESSAGE_FD_MAX = 4
+};
+
+struct asyncns {
+int fds[MESSAGE_FD_MAX];
+
+pthread_t workers[MAX_WORKERS];
+unsigned valid_workers;
+
+unsigned current_id, current_index;
+asyncns_query_t* queries[MAX_QUERIES];
+
+asyncns_query_t *done_head, *done_tail;
+
+int n_queries;
+int dead;
+};
+
+struct asyncns_query {
+asyncns_t *asyncns;
+int done;
+unsigned id;
+query_type_t type;
+asyncns_query_t *done_next, *done_prev;
+int ret;
+int _errno;
+int _h_errno;
+struct addrinfo *addrinfo;
+char *serv, *host;
+void *userdata;
+};
+

Re: [systemd-devel] [PATCH] core: support Distribute=n to distribute to n workers

2014-01-06 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jan 06, 2014 at 04:14:40AM -0800, David Timothy Strauss wrote:
 On Sun, Jan 5, 2014 at 1:44 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  3. The strategy of dup()ing the socket doesn't work. I wrote
 a simple server in python which logs the connections [2], and hooked
 it up into systemd [3-4] (*). If REUSEPORT was working correctly,
 each connection would be handled by just one instance, either created
 previously, or newly created by systemd for this connection. But
 I see the same connection being accept()ed by one of the instances
 and systemd itself spawning a new instance. I'm pretty sure that what
 Lennart wrote before, that you need to create a new socket bound to
 the same port for REUSEPORT to take effect, is true.
 
 I've also seen pretty even (but not perfect, especially with
 event-based designs) distribution with multiple processes simply
 running accept() on the same inherited socket.
It'll work fine with multiple daemons all waiting in accept (e.g. in a threaded
server), because only one will be woken. But if they are using poll, they will
all get notified and race. But this second option is what we're working towards
here.

Zbyszek

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


Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item

2014-01-06 Thread Daniel J Walsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/2014 12:35 PM, Michael Scherer wrote:
 Le vendredi 03 janvier 2014 à 11:48 -0500, Daniel J Walsh a écrit :
 On 01/03/2014 09:16 AM, Michael Scherer wrote:
 
 Well thinking about this again, I think still to the single label.  Lets
 not break the field up into multiple labels.
 
 And not make it SELinux specific.  Maybe the field could be
 SecurityLabel:
 
 That would allow smack to also use the field and any other LSM that used
 a labeling system.
 
 I fail to follow you. The current code use setexecon, and this is quite 
 selinux specific. What would be the equivalent for apparmor, for smack and
 others ?
 
 
No idea, I only do SELinux...

But as Kay Pointed out, there is some similar code in udev for this.

 
 Udev uses: SECLABEL{selinux}=foo SECLABEL{smack}=bar
 
 I think we should be able to distinguish the LSM-module-specific label type
 somehow in the key or value.
 
 Kay



-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLKsRYACgkQrlYvE4MpobOZaACfZTo4JI3dYFhZ9bXKTVkQrQy0
nB4AoLS6FYmmiasReuREK+oedjWn/jI5
=K5oJ
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [WIP][RFC][PATCH] networkd: generate resolv.conf

2014-01-06 Thread Kay Sievers
On Mon, Jan 6, 2014 at 6:49 AM, Tom Gundersen t...@jklm.no wrote:
 This adds support to generate a basic resolv.conf in /run/systemd/network.
 This file will not take any effect unless the admin makes a symlink from
 /etc/resolv.conf.

 The precedence of nameservers is:

  1) nameservers receieved over DHCP
  2) nameservers statically configured in a currently active .network file
  3) nameservers statically configured in the global networkd configuration 
 file

 Note: /etc/resolv.conf is severely limited, so in the future we will likely
 rather provide a much more powerfull nss plugin (or something to that effect),
 but this should allow current users to function without any loss of
 functionality.
 ---

 Hi guys,

 This patch is not finished yet (currently only hooked up to DHCP, not to 
 statically
 configured addresses), but I thought I'd ask for some input early on.

 It seems pretty clear that resolv.conf sucks, and we want somethig better (and
 that pretty soon). However, it seems simple to provide the legacy resolv.conf
 functionality at least until we have something better in place. Without it, I
 guess it will be a bit of a hassle to test networkd.

 So first question: do you agree with adding this functionality?

Sounds fine as long as we make sure it's a private file in the systemd
directory. PPP does something similar.

We should make sure that people understand resolv.conf a rescue for
rather broken tools that rely on it, not something we will carry
forward as a primary interface like fstab.

So, writing one out in a private directory sounds fine, but it should
have a few magic as it can have.

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


[systemd-devel] systemd-bus-proxyd causes hang in connman

2014-01-06 Thread Peeters Simon
hej,

recently I tried to switch my system to kdbus and systemd-bus-proxy.
But the only dbus based daemon (except for systemd) which I care about
(connman) seems to hang on startup, and connmanctl aborts with an
error in libdbus-1 (dbus message iterator is NULL)

the journal does not contain anything releveant other than
Jan 06 16:14:51 troll systemd[1]: Starting Legacy D-Bus Protocol
Compatibility Daemon (PID 2326/UID 0)...
Jan 06 16:14:51 troll systemd[1]: Started Legacy D-Bus Protocol
Compatibility Daemon (PID 2326/UID 0).

this is with both systemd and kdbus both pulled from git today.

can anybody help me further debugging this?


thanks

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


Re: [systemd-devel] How to control socket activation when it run respawn infinitely.

2014-01-06 Thread Tony Seo
Yeah, I got the process what you explain, thanks.
But, I suspect that systemd has room not to get ACK from the server process
executed by service unit.
I concentrated on 3-way handshaking when I studied to analyze this problem.

Isn't it right when we consider the systemd?


2014/1/1 David Timothy Strauss da...@davidstrauss.net

 On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo tonys...@gmail.com wrote:
  But What I really want to know is why the server process always waited in
  the accept stage, when I executed client process for the first after
 system
  boot.

 It may hang in accept() if the service is Accept=true and the daemon
 still tries to accept(). It may also hang on accept() if it's simply
 blocking until the next connection.

  As you know that socket activation makes a service related with socket
 unit
  executed with connection of client process.
  If the procedure for socket activation would run like that, the server
  process executed for the first may not prepare the passive connection
 which
  should be set beforehand because of client connection.
  In my view, this waiting problem will be continue as far as the server
  process is simultaneously executed with the client process.
 
  what do you think about it?

 There is no race condition, if that's what you mean. systemd waits
 using epoll for the appropriate event for starting a child daemon (for
 Accept=false) or child processes (for Accept=true). For Accept=false,
 it's the same effect as if a daemon used epoll on the listener socket
 and only ran accept() in a callback, just possibly with a bit more
 delay.

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


[systemd-devel] journal: how to query journal to see ALL output of given unit?

2014-01-06 Thread Warpme

Hi *

I have question regarding logging with help of systemd journal.
I have mysql daemon unit which so some housekeeping after daemon start 
(see below).
My question is: what is best method to query journal to see _ALL_ 
execution output of mysqld.service unit?
Kicking 'journalctl --unit mysqld.service' gives output of 
'/usr/bin/mysqld' but not '/usr/local/bin/mysqld-check.sh'

Thx in advance!



--
mysqld.service

[Unit]
Description=MySQL Server
After=syslog.target network.target asd.service
BindTo=asd.service

[Service]
WorkingDirectory=/usr
ExecStartPre=/bin/mkdir -p /var/run/mysqld
ExecStartPre=/bin/mkdir -p /var/state/mysqld
ExecStartPre=/bin/chown mysql:mysql /var/run/mysqld

ExecStart=/bin/su mysql -c /usr/bin/mysqld 
--defaults-file=/etc/mysql/my.cnf --datadir=/var/lib/mysql 
--socket=/var/run/mysqld/mysqld.sock


ExecStartPost=/usr/bin/sleep 8
ExecStartPost=/usr/local/bin/mysqld-check.sh
ExecStartPost=/usr/bin/touch /var/state/mysqld/mysqld.dirty

ExecStopPost=/bin/rm -rf /var/state/mysqld/mysqld.dirty

[Install]
WantedBy=multi-user.target

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


Re: [systemd-devel] journal: how to query journal to see ALL output of given unit?

2014-01-06 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Jan 06, 2014 at 09:09:56PM +0100, Warpme wrote:
 Kicking 'journalctl --unit mysqld.service' gives output of
 '/usr/bin/mysqld' but not '/usr/local/bin/mysqld-check.sh'
Can you show a record from journalctl -o verbose for mysqld-check.sh
(one of those not shown, just one is enough)?

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


Re: [systemd-devel] How to control socket activation when it run respawn infinitely.

2014-01-06 Thread David Timothy Strauss
On Mon, Jan 6, 2014 at 8:56 AM, Tony Seo tonys...@gmail.com wrote:
 But, I suspect that systemd has room not to get ACK from the server process
 executed by service unit.
 I concentrated on 3-way handshaking when I studied to analyze this problem.

 Isn't it right when we consider the systemd?

I'm not sure what you mean by room here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel