Re: [systemd-devel] Creating containers from local .raw or tar images

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 15:45, Erik Johnson (e...@saltstack.com) wrote:

 The machinectl pull-* commands allow you to download container images,
 but no such option (yet) exists for deploying from an image or tar file
 on your local filesystem.
 
 Are there plans to expand the machinectl pull-* commands to support
 either absolute file paths or file:/// URLs?
 
 My current dirty hack is to run an nginx instance that listens only on
 localhost, and pull from http://localhost/path/to/container.tar.gz, but
 this is far from ideal.

You can simply place your raw or tar images in /var/lib/machines/
directly.

But yeah, pretty high on my list is to add machinectl import-raw,
machinectl import-tar, machinectl export-raw, machinectl
export-tar, for doing this in a nice way.

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] Unable to remove images using machinectl

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 14:10, Erik Johnson (e...@saltstack.com) wrote:

 On Mon, Mar 02, 2015 at 07:51:35PM +0100, Lennart Poettering wrote:
 On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote:
 
 I'm getting a similar error to the one described in the following post
 from a couple weeks ago:
 
 https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html
 
 I get an access denied error when running machinectl remove, even as
 root.
 
 This was a bug in the dbus policy. It should be fixed with this commit:
 
 http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat
 
 
 Thanks. I applied the patch, restarted dbus, and now I get the
 following after a 20-30 second pause:
 
 Could not remove image: Activation of org.freedesktop.machine1 timed out

dbus is not a service that cannot be restarted during normal
operation. This is a well-known limitation of dbus. Reloading
configuration should be sufficient.

You probably need to reboot now to get back to a working system...

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] Creating containers from local .raw or tar images

2015-03-02 Thread Daurnimator
AFAIK, all the pull-* commands do is download into /var/lib/machines.
You could easily enough just copy things into there yourself.

Or even less work: don't copy them in there at all, and pass your image
directly to systemd-nspawn (which is what machinectl uses)
See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

On 2 March 2015 at 17:45, Erik Johnson e...@saltstack.com wrote:

 The machinectl pull-* commands allow you to download container images,
 but no such option (yet) exists for deploying from an image or tar file
 on your local filesystem.

 Are there plans to expand the machinectl pull-* commands to support
 either absolute file paths or file:/// URLs?

 My current dirty hack is to run an nginx instance that listens only on
 localhost, and pull from http://localhost/path/to/container.tar.gz, but
 this is far from ideal.

 --

 Erik Johnson | Senior Engineer

 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
 e...@saltstack.com | http://saltstack.com

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


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


Re: [systemd-devel] Unable to remove images using machinectl

2015-03-02 Thread Erik Johnson

On Mon, Mar 02, 2015 at 07:51:35PM +0100, Lennart Poettering wrote:

On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote:


I'm getting a similar error to the one described in the following post
from a couple weeks ago:

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html

I get an access denied error when running machinectl remove, even as
root.


This was a bug in the dbus policy. It should be fixed with this commit:

http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b

Lennart

--
Lennart Poettering, Red Hat



Thanks. I applied the patch, restarted dbus, and now I get the
following after a 20-30 second pause:

Could not remove image: Activation of org.freedesktop.machine1 timed out

--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


[systemd-devel] Creating containers from local .raw or tar images

2015-03-02 Thread Erik Johnson

The machinectl pull-* commands allow you to download container images,
but no such option (yet) exists for deploying from an image or tar file
on your local filesystem.

Are there plans to expand the machinectl pull-* commands to support
either absolute file paths or file:/// URLs?

My current dirty hack is to run an nginx instance that listens only on
localhost, and pull from http://localhost/path/to/container.tar.gz, but
this is far from ideal.

--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


[systemd-devel] How to disable the log of services' status?

2015-03-02 Thread Wang Sen
Hi all,

I'm trying to reduce the log output when OS starts. The messages reporting the
services' status like:

[  OK  ] Started Console Getty.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started Login Service.
[  OK  ] Reached target Multi-User System.
...

are useless to me. Anyone who knows how to close these messages?

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


[systemd-devel] [PATCH] tmpfiles: Fail verbosely if acls can't be read

2015-03-02 Thread Hans-Peter Deifel
If the acls of a file couldn't be retrieved (probably due to missing acl
support in the filesytem), systemd-tmpfiles just silently failed.

Now it logs an error, just as it already does if the acls cannot be set.
---
 src/tmpfiles/tmpfiles.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 2642934..de8aa76 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -703,7 +703,9 @@ static int path_set_acl(const char *path, acl_type_t type, 
acl_t acl, bool modif
 if (modify) {
 r = acls_for_file(path, type, acl, dup);
 if (r  0)
-return r;
+return log_error_errno(r, Getting %s ACL on %s 
failed: %m,
+   type == ACL_TYPE_ACCESS ? 
access : default,
+   path);
 
 r = calc_acl_mask_if_needed(dup);
 if (r  0)
-- 
2.3.1

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


Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities

2015-03-02 Thread Jay Faulkner
Hey,

Lennart reviewed this in IRC and suggested I refactor the change in this 
manner. Now, we have an array of capability:sys call pairs, and iterate through 
that and then only add the seccomp filter if the capability doesn’t exist.

The new patch is attached, and available here: 
https://github.com/jayofdoom/systemd/pull/5.patch.


nspawn-seccomp-capabilities.patch
Description: nspawn-seccomp-capabilities.patch
Thanks all,Jay FaulknerOn Feb 27, 2015, at 12:15 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,My apologies if this is frowned upon, but this has been posted for a week and I haven’t gotten any feedback on it. I’d appreciate if this could get reviewed and if adequate, merged. I’m waiting on this change in order to be able to continue using systemd-nspawn containers, properly configured, to perform system tasks (such as firmware and bios flashing).Thanks,Jay FaulknerOn Feb 20, 2015, at 6:59 PM, Jay Faulkner j...@jvf.cc wrote:After some additional testing, I found a bug in this patch where it would not compile with seccomp disabled. I’ve updated the patch athttps://github.com/jayofdoom/systemd/pull/4.patch— also I’ve attached the fixed patch.-Jayrefactor-nspawn-map-seccomp-to-capabilities.patchOn Feb 20, 2015, at 4:18 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found herehttps://github.com/jayofdoom/systemd/pull/4.patch— thanks!refactor-nspawn-map-seccomp-to-capabilities.patchThanks,Jay FaulknerOn Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved.I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :)The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch.Thanks,Jay Faulknernspawn-map-seccomp-to-capabilities.patch___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://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 to disable the log of services' status?

2015-03-02 Thread Andrei Borzenkov
В Tue, 3 Mar 2015 11:12:20 +0800
Wang Sen wang...@linux.vnet.ibm.com пишет:

 Hi all,
 
 I'm trying to reduce the log output when OS starts. The messages reporting the
 services' status like:
 
 [  OK  ] Started Console Getty.
 [  OK  ] Reached target Login Prompts.
 [  OK  ] Started Login Service.
 [  OK  ] Reached target Multi-User System.
 ...
 
 are useless to me. Anyone who knows how to close these messages?

a) add quiet to kernel command line
b) See show_status and ShowStatus in man systemd and man
systemd-system.conf 

 
 ___
 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] Creating containers from local .raw or tar images

2015-03-02 Thread Erik Johnson

On Mon, Mar 02, 2015 at 06:03:42PM -0500, Daurnimator wrote:

AFAIK, all the pull-* commands do is download into /var/lib/machines.
You could easily enough just copy things into there yourself.

Or even less work: don't copy them in there at all, and pass your image
directly to systemd-nspawn (which is what machinectl uses)
See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html



I've done that before, but I am writing nspawn support for SaltStack
(http://saltstack.com) and I need to start and stop them unattended.

--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


Re: [systemd-devel] Creating containers from local .raw or tar images

2015-03-02 Thread Erik Johnson

On Tue, Mar 03, 2015 at 12:24:10AM +0100, Lennart Poettering wrote:

On Mon, 02.03.15 15:45, Erik Johnson (e...@saltstack.com) wrote:


The machinectl pull-* commands allow you to download container images,
but no such option (yet) exists for deploying from an image or tar file
on your local filesystem.

Are there plans to expand the machinectl pull-* commands to support
either absolute file paths or file:/// URLs?

My current dirty hack is to run an nginx instance that listens only on
localhost, and pull from http://localhost/path/to/container.tar.gz, but
this is far from ideal.


You can simply place your raw or tar images in /var/lib/machines/
directly.

But yeah, pretty high on my list is to add machinectl import-raw,
machinectl import-tar, machinectl export-raw, machinectl
export-tar, for doing this in a nice way.

Lennart

--
Lennart Poettering, Red Hat


Nice, I figured this would be the logical next step. Right now I am
writing support for managing nspawn images in SaltStack, so I was just
considering possibilities for functions to add.

--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


Re: [systemd-devel] Unable to remove images using machinectl

2015-03-02 Thread Peter Paule
Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700:
 Thanks. I applied the patch, restarted dbus, and now I get the
 following after a 20-30 second pause:

@Erik
Did you use the aur package or did you compile systemd and install it
using make? Do you have experience rolling back to the normal package
provided by arch?

I'm just asking because I thought about installing systemd on my arch,
but as it is my machine which I use very frequently I don't want to
crash it. :-)

@Lennart
Is is difficult to get rid of a systemd package installed from git?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to disable the log of services' status?

2015-03-02 Thread Wang Sen
Thanks a lot. I added the kernel argument systemd.show_status=0 and it works.

On Tue, Mar 03, 2015 at 07:02:31AM +0300, Andrei Borzenkov wrote:
 В Tue, 3 Mar 2015 11:12:20 +0800
 Wang Sen wang...@linux.vnet.ibm.com пишет:
 
  Hi all,
  
  I'm trying to reduce the log output when OS starts. The messages reporting 
  the
  services' status like:
  
  [  OK  ] Started Console Getty.
  [  OK  ] Reached target Login Prompts.
  [  OK  ] Started Login Service.
  [  OK  ] Reached target Multi-User System.
  ...
  
  are useless to me. Anyone who knows how to close these messages?
 
 a) add quiet to kernel command line
 b) See show_status and ShowStatus in man systemd and man
 systemd-system.conf 
 
  
  ___
  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] Unable to remove images using machinectl

2015-03-02 Thread Erik Johnson

On Tue, Mar 03, 2015 at 07:11:18AM +0100, Peter Paule wrote:

Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700:

Thanks. I applied the patch, restarted dbus, and now I get the
following after a 20-30 second pause:


@Erik
Did you use the aur package or did you compile systemd and install it
using make? Do you have experience rolling back to the normal package
provided by arch?

I'm just asking because I thought about installing systemd on my arch,
but as it is my machine which I use very frequently I don't want to
crash it. :-)



The patch was to the dbus policy, it did not require a recompile.

You can always boot to an Arch snapshot ISO, mount your partitions under
/mnt, and do an arch-chroot /mnt, then install a previous systemd from
/var/cache/pacman/pkg.


@Lennart
Is is difficult to get rid of a systemd package installed from git?


--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


Re: [systemd-devel] Service watchdog feature in state ACTIVATING ?

2015-03-02 Thread Hoyer, Marko (ADITG/SW2)
Hi Umut,

thx for answering

 -Original Message-
 From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com]
 Sent: Monday, March 02, 2015 8:51 PM
 To: Hoyer, Marko (ADITG/SW2)
 Cc: systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] Service watchdog feature in state
 ACTIVATING ?
 
 Hi Marko,
 
 On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) mho...@de.adit-
 jv.com wrote:
 
 
   Hi,
 
   I ran into a use case where the activation phase of a service
 takes significantly longer than the desired watchdog period
 (Activating: 10-20secs, Watchdog: 1-5secs).
 
   I found out that the watchdog features starts not before the
 service is in state START_POST. This means for my use case that the
 system is blind for 10-20secs (whatever I set as startup timeout here).
 
   Is there any way to activate the watchdog feature already in
 phase ACTIVATING?
 
 
 Why would you need this? Watchdog is to prevent system being stuck
 somewhere. If activation fails within TimeoutStartSec=, systemd will
 put the service in failed to activate state anyways.
 
 Is waiting 20 seconds to detect the freeze is too much for your case?
 Is it not possible to lower the activation time?

Yes it is too long. The process is a kind of application starter and observer 
processing a startup phase. It is responsible for:
- observing the application internal states of upcoming applications
- it kicks off the startup of applications depending on the internal state of 
other once
- it delays the startup of late services started the normal way by systemd once 
the startup phase is done

And yes, one could say that we are implementing a kind of second systemd 
started by systemd. The difference is that our starter knows about some more 
states than just ACTIVATING and RUNING which is not really realizable with 
systemd especially when more than one application is contained in one process.

So the idea was to bring up a set of applications with our starter application 
and stay with our starter in state ACTIVATING until it is done with bringing up 
the set of applications.

Depending on the product, bringing up our set of applications can take 
10-20secs. Since the starter is a kind of sensible application, it needs to be 
supervised by a watchdog with a timeout far less than 20secs.

Hope this gives a rough picture of our use case.

 
 Umut
 
 
   I guess there should be a second watchdog configuration parameter
 to allow services to use different values for the states ACTIVATING and
 RUNING. Otherwise, people who are not interested in having a watchdog
 observation during startup will run into troubles ...
 
   Any opinions on that?
 
 
   Best regards
 
   Marko Hoyer
 
   Advanced Driver Information Technology GmbH
   Software Group II (ADITG/SW2)
   Robert-Bosch-Str. 200
   31139 Hildesheim
   Germany
 
   Tel. +49 5121 49 6948
   Fax +49 5121 49 6999
   mho...@de.adit-jv.com javascript:;
 
   ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch
 Car Multimedia GmbH and DENSO Corporation
   Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB
 3438
   Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda
   ___
   systemd-devel mailing list
   systemd-devel@lists.freedesktop.org javascript:;
   http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 
Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH/RFC] FuseMAC: user space MAC in systemd

2015-03-02 Thread Topi Miettinen
Intercept and filter filesystem operations of processes launched
by systemd with FUSE.

Implement learning, enforcing and auto enforcing/learning modes,
enabled with new exec directive FuseMAC.

FS operations can be filtered by access type (e.g. getattr/read,
cf. AppArmor or TOMOYO Linux) or for more fine grained control,
which area of the file is being accessed.

Due to limitations of FUSE, API file systems can't be intercepted.

Also the patch seems to trigger bugs in kernel (hang CPU).
---
 Makefile.am   |9 +-
 configure.ac  |   13 +
 src/core/dbus-execute.c   |3 +
 src/core/execute.c|   22 +
 src/core/execute.h|   16 +
 src/core/fusemac.c| 1118 +
 src/core/load-fragment-gperf.gperf.m4 |5 +-
 src/core/load-fragment.c  |   31 +
 src/core/load-fragment.h  |1 +
 src/shared/build.h|9 +-
 src/shared/exit-status.c  |3 +
 src/shared/exit-status.h  |1 +
 src/shared/util.c |2 +-
 src/shared/util.h |2 +
 14 files changed, 1231 insertions(+), 4 deletions(-)
 create mode 100644 src/core/fusemac.c

diff --git a/Makefile.am b/Makefile.am
index 9d41a2c..61598bf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1186,6 +1186,11 @@ libsystemd_core_la_SOURCES = \
src/core/failure-action.c \
src/core/failure-action.h
 
+if HAVE_FUSE
+libsystemd_core_la_SOURCES += \
+   src/core/fusemac.c
+endif
+
 nodist_libsystemd_core_la_SOURCES = \
src/core/load-fragment-gperf.c \
src/core/load-fragment-gperf-nulstr.c
@@ -1198,6 +1203,7 @@ libsystemd_core_la_CFLAGS = \
$(APPARMOR_CFLAGS) \
$(SECCOMP_CFLAGS) \
$(MOUNT_CFLAGS) \
+   $(FUSE_CFLAGS) \
-pthread
 
 libsystemd_core_la_LIBADD = \
@@ -1211,7 +1217,8 @@ libsystemd_core_la_LIBADD = \
$(KMOD_LIBS) \
$(APPARMOR_LIBS) \
$(SECCOMP_LIBS) \
-   $(MOUNT_LIBS)
+   $(MOUNT_LIBS) \
+   $(FUSE_LIBS)
 
 if HAVE_SECCOMP
 libsystemd_core_la_LIBADD += \
diff --git a/configure.ac b/configure.ac
index 419b5d4..12d7937 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1332,6 +1332,19 @@ AC_ARG_ENABLE(ldconfig,
 AM_CONDITIONAL(ENABLE_LDCONFIG, [test x$enable_ldconfig = xyes])
 
 # 
--
+have_fuse=no
+AC_ARG_ENABLE(fuse, AS_HELP_STRING([--disable-fuse], [Disable optional FUSE 
support]))
+if test x$enable_fuse != xno; then
+PKG_CHECK_MODULES(FUSE, [ fuse ],
+[AC_DEFINE(HAVE_FUSE, 1, [Define if FUSE is available]) 
have_fuse=yes], have_fuse=no)
+if test x$have_fuse = xno -a x$enable_fuse = xyes; then
+AC_MSG_ERROR([*** FUSE support requested but libraries not 
found])
+fi
+M4_DEFINES=$M4_DEFINES -DHAVE_FUSE
+fi
+AM_CONDITIONAL(HAVE_FUSE, [test $have_fuse = yes])
+
+# 
--
 # Location of the init scripts as mandated by LSB
 SYSTEM_SYSVINIT_PATH=/etc/init.d
 SYSTEM_SYSVRCND_PATH=/etc/rc.d
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index a9f7971..9611f29 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -49,6 +49,8 @@ static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_exec_input, 
exec_input, ExecInp
 static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_protect_home, 
protect_home, ProtectHome);
 static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_protect_system, 
protect_system, ProtectSystem);
 
+static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_fusemac_mode, 
fusemac_mode, FuseMAC);
+
 static int property_get_environment_files(
 sd_bus *bus,
 const char *path,
@@ -665,6 +667,7 @@ const sd_bus_vtable bus_exec_vtable[] = {
 SD_BUS_PROPERTY(RestrictAddressFamilies, (bas), 
property_get_address_families, 0, SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY(RuntimeDirectoryMode, u, bus_property_get_mode, 
offsetof(ExecContext, runtime_directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_PROPERTY(RuntimeDirectory, as, NULL, offsetof(ExecContext, 
runtime_directory), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FuseMAC, s, bus_property_get_fusemac_mode, 
offsetof(ExecContext, fusemac_mode), SD_BUS_VTABLE_PROPERTY_CONST),
 SD_BUS_VTABLE_END
 };
 
diff --git a/src/core/execute.c b/src/core/execute.c
index 39ec5ad..08686bd 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1600,9 +1600,19 @@ static int exec_child(
 log_close();
 } else if (r  0) {
 *exit_status = EXIT_NAMESPACE;
+
+}
+}
+
+#ifdef HAVE_FUSE
+if (context-fusemac_mode != FUSEMAC_NO) {
+r = 

Re: [systemd-devel] [PATCH] po: update Russian translation

2015-03-02 Thread Dimitri John Ledkov
On 2 March 2015 at 13:04, Sergey Ptashnick 0comff...@inbox.ru wrote:
 On 02.03.2015 02:26, Ivan Shapovalov wrote:
 Hmm... Here (and in similar cases below) the comma should not be used,
 because для is just a preposition and hence для управления does not
 introduce neither a subordinate clause; it's a word in genitive case.

 Such form used also in other statements. If you think that removing this
 comma will improve readability, please prepare patch for all of them.
 (I don't think so, and leave this to your discretion.)

If it was up to me, I'd switch the sentence around:

Необходимо пройти аутентификацию для управления виртуальными машинами
и контейнерами.

I also wouldn't want to see foreign bored terms like менеджер and
юнит used in translation and instead use e.g. управляющий and
единица. But I'm not a sysadmin in a Russian speaking environment,
so I cannot judge whether the foreign terms are actually already
wide-spread in IT context and became de-facto terms.

-- 
Regards,

Dimitri.

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] po: update Russian translation

2015-03-02 Thread Sergey Ptashnick
On 02.03.2015 02:26, Ivan Shapovalov wrote:
 Hmm... Here (and in similar cases below) the comma should not be used,
 because для is just a preposition and hence для управления does not
 introduce neither a subordinate clause; it's a word in genitive case.

Such form used also in other statements. If you think that removing this 
comma will improve readability, please prepare patch for all of them.
(I don't think so, and leave this to your discretion.)

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


Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 06:56, Peter Paule (systemd-de...@fedux.org) wrote:

 Hi,
 
 is it ok for you to have a configuration file for machined? It would be
 wonderful if one could add the dkr index url to that file because for me
 it's always the same.

You can specify it at build time as a configure parameter.

 And maybe you could also support multiple values for the url to support
 private and public registries at the same time:
 
 1. Lookup the name of the dkr image at the first registry
 2. Return if found
 3. Go on with info message if not found
 4. Lookup the name of the dkr image at the second registry
 5. Return if found
 6. Fail with error message if not found
 
 Does this makes sense to you?

I am not really sure, it sounds slightly problematic regarding
security since it would not be clear anymore what you get if you ask
for a specific name.

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] Errors using machinectl pull-tar and machinectl pull-dkr

2015-03-02 Thread Peter Paule


Quoting Lennart Poettering lenn...@poettering.net:

Thanks for clarifying this. :-) Any ETA for this? I'm looking for better
integrated solution into systemd than docker and I really like the
idea of having a systemd-daemon managing the containers.


This is actually in place now in git. The first time you invoke one of
the machinectl pull-xyz commands we create /var/lib/machines.raw as
loop back file with btrfs inside which is then mounted to
/var/lib/machines. With the machinectl set-limit command you can
then set the size of this file dynamically, which resizes the btrfs
and the loopback file, as well as the btrfs quota settings
inside. It's really nice to use.

Next step: make the file grow automatically during pull, if a certain
fill level of the file system is reached.


Great. Thanks for that. Do you always create that loop back file or  
only if on non-btrfs-filesystems?


Do you have a solution for the trustdb-stuff already? I only found  
this in the manual for gnupg2:


--trustdb-name file
  Use file instead of the default trustdb. If file begins with a  
tilde and a slash, these are replaced by the $HOME directory. If the  
filename does not contain
  a slash, it is assumed to be in the GnuPG home directory  
(‘~/.gnupg’ if --homedir or $GNUPGHOME is not used).


Maybe you should just create your own trustdb-file and ship it as well  
or create it on the first run of machined. There was no other obvious  
option for that I found. But I'm not really a gpg-pro. Maybe some  
other guy has a better idea about solving this thing.


BTW:
Even RHEL 6.6 ships with gpg2 already. Do you really need to support gpg1? :-)

Be aware:
I think I send one of my mails in this thread directly to you (by  
accident) and forgot to add the mailinglist. Fixed that with this mail.


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


Re: [systemd-devel] heads-up: chasing journal(?) related regression in 219 causing boot hang/fail

2015-03-02 Thread Martin Pitt
Hey Lennart,

Lennart Poettering [2015-02-28 13:05 +0100]:
 Any idea about the details of this?

For the record, I'm still working on this on-and-off (I got some other
urgent things to work on, though). It took me a while to install
Fedora, as the rawhide images and upgrade are both broken ATM, but I
now have F21 with rawhide's dbus and systemd in a VM. That's fairly
close to Debian sid plus systemd from experimental. We did get reports
about that hang under Debian, so it's at least likely that Fedora is
affected too. But so far my simple reproducer doesn't trigger it under
either, so I need to keep digging and experimenting, and probably go
with the full reboot test iterations.  Of course I'll follow up here
once I find out more.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 11:00, Peter Paule (systemd-de...@fedux.org) wrote:

 
 Quoting Lennart Poettering lenn...@poettering.net:
 Thanks for clarifying this. :-) Any ETA for this? I'm looking for better
 integrated solution into systemd than docker and I really like the
 idea of having a systemd-daemon managing the containers.
 
 This is actually in place now in git. The first time you invoke one of
 the machinectl pull-xyz commands we create /var/lib/machines.raw as
 loop back file with btrfs inside which is then mounted to
 /var/lib/machines. With the machinectl set-limit command you can
 then set the size of this file dynamically, which resizes the btrfs
 and the loopback file, as well as the btrfs quota settings
 inside. It's really nice to use.
 
 Next step: make the file grow automatically during pull, if a certain
 fill level of the file system is reached.
 
 Great. Thanks for that. Do you always create that loop back file or only if
 on non-btrfs-filesystems?

Only on non-btrfs.

 Do you have a solution for the trustdb-stuff already? I only found this in
 the manual for gnupg2:
 
 --trustdb-name file
   Use file instead of the default trustdb. If file begins with a tilde and a
 slash, these are replaced by the $HOME directory. If the filename does not
 contain
   a slash, it is assumed to be in the GnuPG home directory (‘~/.gnupg’ if
 --homedir or $GNUPGHOME is not used).

I wonder if we can use --trustdb-name /dev/null

 Maybe you should just create your own trustdb-file and ship it as well or
 create it on the first run of machined. There was no other obvious option
 for that I found. But I'm not really a gpg-pro. Maybe some other guy has a
 better idea about solving this thing.
 
 BTW:
 Even RHEL 6.6 ships with gpg2 already. Do you really need to support
 gpg1? :-)

Well, gpg1 is kinda the default on FEdora at least since it is
installed as /usr/bin/gpg... We can of course switch to gpg2 instead,
but that's a package that is not as frequently installed I
think. Hence maybe a scheme where we use /usr/bin/gpg with a fallback
to /usr/bin/gpg2 might work.

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] Errors using machinectl pull-tar and machinectl pull-dkr

2015-03-02 Thread Peter Paule

Quoting Lennart Poettering lenn...@poettering.net:

I wonder if we can use --trustdb-name /dev/null


I think, no. I got a weird error using /dev/null

% strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring  
--no-auto-key-locate --no-auto-check-trustdb --batch  
--trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg  
--verify ~/data/halde/signature.sig --trustdb-name /dev/null  
trusty-server-cloudimg-amd64-root.tar.gz

gpg: Note: '--trustdb-name' is not considered an option
gpg: can't open signed data '--trustdb-name'
gpg: can't hash datafile: No such file or directory

% strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring  
--no-auto-key-locate --no-auto-check-trustdb --batch  
--trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg  
--verify ~/data/halde/signature.sig  
trusty-server-cloudimg-amd64-root.tar.gz

gpg: Signature made Sat 28 Feb 2015 02:07:02 CET using RSA key ID 7DB87C81
gpg: BAD signature from UEC Image Automatic Signing Key  
cdim...@ubuntu.com [unknown]


/pp

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


Re: [systemd-devel] [PATCH] journal: fix Inappropriate ioctl for device on ext4

2015-03-02 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Mar 02, 2015 at 03:58:48AM +0300, Ivan Shapovalov wrote:
 On 2015-03-01 at 21:13 -0300, Cristian Rodríguez wrote:
  Logs constantly show
  
  systemd-journald[395]: Failed to set file attributes: Inappropriate
  ioctl for device
  
  This is because ext4 does not support FS_NOCOW_FL.
  ---
   src/journal/journal-file.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
  index 9c9a548..ecabfd3 100644
  --- a/src/journal/journal-file.c
  +++ b/src/journal/journal-file.c
  @@ -2610,7 +2610,8 @@ int journal_file_open(
* checksumming). */
   r = chattr_fd(f-fd, true, FS_NOCOW_FL);
   if (r  0)
  -log_warning_errno(errno, Failed to set file 
  attributes: %m);
  +if(r != -ENOTTY)
 
 Maybe it's better to just say if (r  0  r != -ENOTTY) here?
 
 Just nitpicking,
Yeah, it is.

Applied, with the suggested change.

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


Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 09:45, Jordan Hargrave (jhar...@gmail.com) wrote:

 There are currently two competing naming mechanisms for network cards,
 biosdevname and systemd.  Systemd currently has some limitations on naming
 cards that use network partitioning or support SR-IOV.  Proposal is to add
 support for biosdevname-like names as part of systemd.  The names would be
 created as a new environment variable ID_NET_NAME_BIOSDEVNAME.  This could
 then be used in the udev rules scripts to replace the external biosdevname
 handler.

No.

We didn't adopt the biosdevname names in udev since they didn't actually
deliver what they claimed to deliver, and resorted to naming things
after probing order in the end.

Use biosdevname if you want biosdevname names, it still works.

Sorry, but this has no place in systemd/udev. We didn't adopt the
names for a reason.

 At least on Dell systems, systemd generates unusable names (PCI B:D:F vs
 Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method,
 but they do have a SMBIOS slot number.

unusable? Can you elaborate what you mean by that?

Lennart

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


[systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Jordan Hargrave
It would be nice if systemd could discover and display enclosure/bay slot
mappings for drives in the system.  The /dev/disk/by-path method doesn't
quite work, for SAS drives the ID can change on hotplug.  The slot mapping
also doesn't handle PCIe SSD devices as they are bare block devices and
don't use SCSI midlayer.  Proposing to add support for something like
/dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Proposal: Add biosdevname naming scheme to systemd

2015-03-02 Thread Jordan Hargrave
There are currently two competing naming mechanisms for network cards,
biosdevname and systemd.  Systemd currently has some limitations on naming
cards that use network partitioning or support SR-IOV.  Proposal is to add
support for biosdevname-like names as part of systemd.  The names would be
created as a new environment variable ID_NET_NAME_BIOSDEVNAME.  This could
then be used in the udev rules scripts to replace the external biosdevname
handler.

At least on Dell systems, systemd generates unusable names (PCI B:D:F vs
Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method,
but they do have a SMBIOS slot number.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Andrei Borzenkov
В Mon, 2 Mar 2015 09:48:51 -0600
Jordan Hargrave jhar...@gmail.com пишет:

 It would be nice if systemd could discover and display enclosure/bay slot
 mappings for drives in the system.  The /dev/disk/by-path method doesn't
 quite work, for SAS drives the ID can change on hotplug.  The slot mapping
 also doesn't handle PCIe SSD devices as they are bare block devices and
 don't use SCSI midlayer.  Proposing to add support for something like
 /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

How it should be discovered? Is there universal method that can be used
on majority of systems?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Jordan Hargrave
On Mon, Mar 2, 2015 at 10:24 AM, Andrei Borzenkov arvidj...@gmail.com
wrote:

 В Mon, 2 Mar 2015 09:48:51 -0600
 Jordan Hargrave jhar...@gmail.com пишет:

  It would be nice if systemd could discover and display enclosure/bay slot
  mappings for drives in the system.  The /dev/disk/by-path method doesn't
  quite work, for SAS drives the ID can change on hotplug.  The slot
 mapping
  also doesn't handle PCIe SSD devices as they are bare block devices and
  don't use SCSI midlayer.  Proposing to add support for something like
  /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

 How it should be discovered? Is there universal method that can be used
 on majority of systems?


For Dell system PCIE SSD it requires using ipmitool OEM command to get the
correct Bus:Device:Function to Enclosure:Slot mapping.  For devices using
SAS controllers it's a bit more tricky.  There is a sysfs variable for
enclosure/slot in sysfs for SAS devices with 8 drives on our servers.  The
driver for some reason doesn't export this info for Dell systems with  8
drives.

Ideally there should be an enclosure.c device defined for every device
type.  Currently only ses.c seems to use this, but SCSI enclosure services
aren't available on SSDs.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Cristian Rodríguez
On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave jhar...@gmail.com wrote:
 It would be nice if systemd could discover and display enclosure/bay slot
 mappings for drives in the system.  The /dev/disk/by-path method doesn't
 quite work, for SAS drives the ID can change on hotplug.  The slot mapping
 also doesn't handle PCIe SSD devices as they are bare block devices and
 don't use SCSI midlayer.  Proposing to add support for something like
 /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

As far as I am aware, no new things dealing with storage naming rules
will be added to udev/systemd, it has to go to whatever other
project..(sg3_utils last time I checked)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Unable to remove images using machinectl

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote:

 I'm getting a similar error to the one described in the following post
 from a couple weeks ago:
 
 https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html
 
 I get an access denied error when running machinectl remove, even as
 root.

This was a bug in the dbus policy. It should be fixed with this commit:

http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b

Lennart

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


[systemd-devel] Unable to remove images using machinectl

2015-03-02 Thread Erik Johnson

I'm getting a similar error to the one described in the following post
from a couple weeks ago:

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html

I get an access denied error when running machinectl remove, even as
root.

For reference, /var/lib/machines is on a btrfs partition and I am
running systemd 219 on an Arch Linux host. I am, however, unexperienced
with btrfs and may have done something wrong. I did not manually create
any subvolumes.

I tried stopping systemd-machined and running it under strace to check
for permission errors as mentioned by Lennart in the reply to the thread
I referenced above. But to my surprise, when I attempted to remove the
container I did not get the same permission error and the container was
successfully removed. So, it occurs to me that the issue might have to
do with the options in the unit file. Below are the contents of the unit
file, with the commented lines at the beginning removed for brevity. Any
insight that can be offered would be appreciated.


[Unit]
Description=Virtual Machine and Container Registration Service
Documentation=man:systemd-machined.service(8)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/machined
Wants=machine.slice
After=machine.slice

[Service]
ExecStart=/usr/lib/systemd/systemd-machined
BusName=org.freedesktop.machine1
CapabilityBoundingSet=CAP_KILL CAP_SYS_PTRACE CAP_SYS_ADMIN CAP_SETGID 
CAP_SYS_CHROOT CAP_DAC_READ_SEARCH
WatchdogSec=1min
PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=full
ProtectHome=yes


--

Erik Johnson | Senior Engineer

3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043
e...@saltstack.com | http://saltstack.com


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


Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd

2015-03-02 Thread Tom Gundersen
Hi Jordan,

On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave jhar...@gmail.com wrote:
 There are currently two competing naming mechanisms for network cards,
 biosdevname and systemd.  Systemd currently has some limitations on naming
 cards that use network partitioning or support SR-IOV.

Could you point to an example so we can fix it? I thought all bug
reports had been handled, but maybe I lost track of something.

 Proposal is to add
 support for biosdevname-like names as part of systemd.  The names would be
 created as a new environment variable ID_NET_NAME_BIOSDEVNAME.  This could
 then be used in the udev rules scripts to replace the external biosdevname
 handler.

I don't think this makes much sense. If biosdevname had been
acceptable, the udev naming scheme would not have been introduced in
the first place.

 At least on Dell systems, systemd generates unusable names (PCI B:D:F vs
 Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method,
 but they do have a SMBIOS slot number.

Wouldn't the better approach be to simply add SMBIOS support to udev
then? I must admit I don't know what challenges that entails, but
seems like a natural first step.

Cheers,

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


Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files

2015-03-02 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Feb 18, 2015 at 06:17:17PM -0300, Cristian Rodríguez wrote:
 El 18/02/15 a las 07:10, Lennart Poettering escribió:
 On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
 
 Please fix this for all arguments, not just symlinks.
 
 diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
 index c948d4d..1b35b8e 100644
 --- a/src/tmpfiles/tmpfiles.c
 +++ b/src/tmpfiles/tmpfiles.c
 @@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned 
 line, const char *buffer) {
   i.argument = strappend(/usr/share/factory/, 
  i.path);
   if (!i.argument)
   return log_oom();
 +} else {
 +r = specifier_printf(i.argument,
 specifier_table, NULL, i.argument);
 
 Here's a memory leak, you need to free the old i.argument.
 
 Indentation! Please have a look at CODING_STYLE. You need to indent by
 8ch. 4ch indenting is not acceptable.
 
 +if (r  0) {
 +log_error([%s:%u] Failed to replace specifiers: 
 %s, fname, line, path);
 +return r;
 +}
 
 
 HI again:
 
 Is the attached version cool for you ?
Hi,

sorry for the delay. We seem to have trouble getting all patches
reviewed recently.  Hopefully this is just
conferences/vacations/fedora-alpha-releases, and things will
return to normal.

 From ee8e4f440def745b6f0655b897e65d48321e46c5 Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
 Date: Wed, 18 Feb 2015 18:09:16 -0300
 Subject: [PATCH] tmpfiles: implement specifier substitution for file
  argument
 
 Only for L and C types where it makes sense.
 ---
  src/tmpfiles/tmpfiles.c | 12 
  1 file changed, 12 insertions(+)
 
 diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
 index 88ba7e4..6de477b 100644
 --- a/src/tmpfiles/tmpfiles.c
 +++ b/src/tmpfiles/tmpfiles.c
 @@ -1568,6 +1568,18 @@ static int parse_line(const char *fname, unsigned 
 line, const char *buffer) {
  }
  }
  
 +if(IN_SET(i.type, CREATE_SYMLINK, COPY_FILES)) {
Please add a space after if and for...

 +if(i.argument) {
 +_cleanup_free_ char *resolved_iarg = NULL;
...and empty line after variable declarations.

 +r = specifier_printf(i.argument, specifier_table, 
 NULL, resolved_iarg);
 +if(r  0)
 +return log_error_errno(r, [%s:%u] Failed to 
 replace specifiers: %s, fname, line, path);
 +r = free_and_strdup(i.argument, resolved_iarg);
There's no need to to use free_and_strdup here. resolved_arg was just
newly allocated, so it can be used without any strdup.

 +if(r  0)
 +return log_oom();
 +}
 +}
 +
  switch (i.type) {

Otherwise looks OK.

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


Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 15:33, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

 On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave jhar...@gmail.com wrote:
  It would be nice if systemd could discover and display enclosure/bay slot
  mappings for drives in the system.  The /dev/disk/by-path method doesn't
  quite work, for SAS drives the ID can change on hotplug.  The slot mapping
  also doesn't handle PCIe SSD devices as they are bare block devices and
  don't use SCSI midlayer.  Proposing to add support for something like
  /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.
 
 As far as I am aware, no new things dealing with storage naming rules
 will be added to udev/systemd, it has to go to whatever other
 project..(sg3_utils last time I checked)

Well, that's not precisely true. Yes, more exotic stuff like SCSI/SAS
should be maintained elsewhere, like in sg3_utils, but if something is
common enough, so that it used on a large percentage of systems (like
SATA), then we of course will support this in systemd/udev natively.

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] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Tom Gundersen
On Mon, Mar 2, 2015 at 5:42 PM, Jordan Hargrave jhar...@gmail.com wrote:


 On Mon, Mar 2, 2015 at 10:24 AM, Andrei Borzenkov arvidj...@gmail.com
 wrote:

 В Mon, 2 Mar 2015 09:48:51 -0600
 Jordan Hargrave jhar...@gmail.com пишет:

  It would be nice if systemd could discover and display enclosure/bay
  slot
  mappings for drives in the system.  The /dev/disk/by-path method doesn't
  quite work, for SAS drives the ID can change on hotplug.  The slot
  mapping
  also doesn't handle PCIe SSD devices as they are bare block devices and
  don't use SCSI midlayer.  Proposing to add support for something like
  /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

 How it should be discovered? Is there universal method that can be used
 on majority of systems?


 For Dell system PCIE SSD it requires using ipmitool OEM command to get the
 correct Bus:Device:Function to Enclosure:Slot mapping.  For devices using
 SAS controllers it's a bit more tricky.  There is a sysfs variable for
 enclosure/slot in sysfs for SAS devices with 8 drives on our servers.  The
 driver for some reason doesn't export this info for Dell systems with  8
 drives.

 Ideally there should be an enclosure.c device defined for every device type.
 Currently only ses.c seems to use this, but SCSI enclosure services aren't
 available on SSDs.

Sounds like something the kernel could/should expose in some uniform way, no?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr

2015-03-02 Thread Lennart Poettering
On Mon, 02.03.15 12:28, Peter Paule (systemd-de...@fedux.org) wrote:

 Quoting Lennart Poettering lenn...@poettering.net:
 I wonder if we can use --trustdb-name /dev/null
 
 I think, no. I got a weird error using /dev/null
 
 % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring
 --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always
 --keyring=/usr/lib/systemd/import-pubring.gpg --verify
 ~/data/halde/signature.sig --trustdb-name /dev/null
 trusty-server-cloudimg-amd64-root.tar.gz
 gpg: Note: '--trustdb-name' is not considered an option
 gpg: can't open signed data '--trustdb-name'
 gpg: can't hash datafile: No such file or directory
 
 % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring
 --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always
 --keyring=/usr/lib/systemd/import-pubring.gpg --verify
 ~/data/halde/signature.sig trusty-server-cloudimg-amd64-root.tar.gz
 gpg: Signature made Sat 28 Feb 2015 02:07:02 CET using RSA key ID 7DB87C81
 gpg: BAD signature from UEC Image Automatic Signing Key
 cdim...@ubuntu.com [unknown]

I have now added some code to git that should make the logic work with
both gpg 1 and gpg 2.

I now create a throw-away home directory in /tmp to use with gpg's
--homedir= parameter, and remove it right after gpg ran. gpg can then
create whatever it wants there, and I'll remove it right after.

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] Service watchdog feature in state ACTIVATING ?

2015-03-02 Thread Umut Tezduyar Lindskog
Hi Marko,

On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com
wrote:

 Hi,

 I ran into a use case where the activation phase of a service takes
 significantly longer than the desired watchdog period (Activating:
 10-20secs, Watchdog: 1-5secs).

 I found out that the watchdog features starts not before the service is in
 state START_POST. This means for my use case that the system is blind for
 10-20secs (whatever I set as startup timeout here).

 Is there any way to activate the watchdog feature already in phase
 ACTIVATING?


Why would you need this? Watchdog is to prevent system being stuck
somewhere. If activation fails within TimeoutStartSec=, systemd will put
the service in failed to activate state anyways.

Is waiting 20 seconds to detect the freeze is too much for your case? Is it
not possible to lower the activation time?

Umut


 I guess there should be a second watchdog configuration parameter to allow
 services to use different values for the states ACTIVATING and RUNING.
 Otherwise, people who are not interested in having a watchdog observation
 during startup will run into troubles ...

 Any opinions on that?


 Best regards

 Marko Hoyer

 Advanced Driver Information Technology GmbH
 Software Group II (ADITG/SW2)
 Robert-Bosch-Str. 200
 31139 Hildesheim
 Germany

 Tel. +49 5121 49 6948
 Fax +49 5121 49 6999
 mho...@de.adit-jv.com javascript:;

 ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car
 Multimedia GmbH and DENSO Corporation
 Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
 Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org javascript:;
 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] Plans to fix or provide alternative for lz4?

2015-03-02 Thread Shawn Landden
On Sun, Mar 1, 2015 at 3:04 AM, Lennart Poettering lenn...@poettering.net
wrote:

 On Thu, 26.02.15 05:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
 wrote:

  On Thu, Feb 26, 2015 at 04:41:48AM +, Laszlo Papp wrote:
   Hi,
  
   it seems that the lz4 headers are broken when getting coredumps
   generated. They cannot even be extracted by the lz4 tool itself, let
   alone using them via the coredump controller util.
  
   My system, which is Archlinux, is using lz4 127 and systemd 219.
  
   My current workaround was to disable compression altogether for
   coredumps in the corresponding config file, but it is suboptimal,
   especially on embedded systems.
  The headers are different because when lz4 support was added, lz4 did
  not provide a library to write the headers so I added custom headers.
  You should be able to use coredumpctl to unpack the file.
 
  Proper lz4 support has been written, but lz4 upstream has trouble
  with keeping .so compatibility:
 https://code.google.com/p/lz4/issues/detail?id=147.
  So the question is whether to replace lz4 with something more stable
  or to ignore the issue and hope it doesn't happen again.

 Maybe gzip might be a good compromise? Due to the importd logic we now
 check for libz anyway in configure.ac, we might as well use it for the
 journal. To my knowledge gzip is still a good compromise between
 compression ratio on one hand and memory use/time on the other...

except xz beats gzip at its lower compression settings even on memory
use/time. See man 1 xz.


 Lennart

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




-- 

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


[systemd-devel] Systemd-219: Failed to start Create Volatile...

2015-03-02 Thread RicΛrdo Bastos™
Hi all,

I'm using this tip to solve problem in systemd-TMPFILES-setup.service:
http://forums.gentoo.org/viewtopic-t-1011254-view-previous.html?sid=4a7ba76e913f996abfa6e09aee95
http://www.google.com/url?q=http%3A%2F%2Fforums.gentoo.org%2Fviewtopic-t-1011254-view-previous.html%3Fsid%3D4a7ba76e913f996abfa6e09aee95sa=Dsntz=1usg=AFQjCNEAeFsiM_50wA7SSsdJej8T6aPpQA

So I commented the following lines in systemd.conf file:

# a+ /var/log/journal/%m - - - - d:group:adm:r-x,d:group:wheel:r-x
# A+ /var/log/journal/%m - - - - group:adm:r-x,group:wheel:r-x

Now the service is starting correctly :)
*# **Active: active (exited) since Seg 2015-03-02 13:37:04 BRT; 3h 1min ago*

I do not understand the failure, nor why it occurs, not even because this
solution solved .. :(
Anyway, what is the relationship between TMPFILES and journal?


Atenciosamente

* RICARDO BASTOS CAMPOS *
 Análise e Desenvolvimento de Sistemas

​
MS Researcher at INF in
​

​
​P
arallel and
​D
istributed
​P
rocessing Systems (UFRGS)​
 Porto Alegre, RS - Brasil
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel