Re: [systemd-devel] Use of namespaced cgroups (aka Docker in systemd-nspawn containers)

2016-07-01 Thread Lennart Poettering 
On Mon, 27.06.16 16:58, Lee Hambley (lee.hamb...@gmail.com) wrote:

> Hi List,
> 
> My company is currently conducting research into the most viable container
> technology that fits our stack (CentOS based) and given our already
> widespread reliance on systemd, I have a personal stake in preferring not
> to introduce other tooling (LXD, the 2nd place leader) into our stack.
> 
> I'd like to know what is required to fulfil our use-case (Docker in
> LXD/systemd-nspawn)
> 
> Here's what I (think I) know:
> 
>- Docker can't run in systemd-nspawn because cgroup fs is mounted ro,
>and the systemd-nspwan container sees the entire system's cgroupfs (no
>namespacing)

There's a patch waiting in github, to add cgroup namespace support to
nspawn:

https://github.com/systemd/systemd/pull/3589

I am not a Docker guy, but do note that nspawn payloads have write
access to the name=systemd hierarchy below their subtree, and can
delegate that further, hence Docker could work, if it wanted to, as
long as it turns on delegation in its service or asks for a scope with
delegation turned on.

nspawn itself is actually fine with running inside of nspawn (or at
least used to, haven't tested this in a while).

Note that delegation of resource controllers is not safe on cgroupsv1
however, and nspawn hence makes all resource controllers (meaning: all
of "cpu", "memory", "blkio", …) read-only. This will become safe with
cgroupv2. Effectively this means that you can set resource limits on
the outermost container, but not on anything inside of it.

>- cgroups filesystem normally mounted ro in containers, to protect the
>host (or, something related to privileged containers)

well, it's not that easy. Today, systemd makes all cgroup controller
hierarchies read-only, except for the name=systemd named hierarchy,
where everything above the container's cgroup subtree is read-only,
but the subtree itself writable.

>   - When mounted rw it can break the host (not the worst problem in the
>   world, we're not defending against malice here, but apparently
> it's trivial
>   to brick the host by having systemd fight over ttys, etc)

well, if we'd mount all cgroup hierarchies writable, inclduing the
various resource controller hiearchies, and everything above the
container's subtree in the name=systemd hierarchy, then this would be
a major security problem. First of all, controller delegation is not
safe on cgroupv1 (as mentioned above), and secondly this would enable
the container to interfere with the host's cgroup tree, which is
highly problematic.

That said, containers on Linux are not a security concept really
anyway, there are more holes in the entire model than in swiss
cheese. But we should at least close the holes we are aware of.

>   - it might be fair to say that privilidged containers
>- namespaces cgroups are relatively new in linux
>   - available 4.6 [1]
>   - backported to 4.4+ on Ubuntu kernels
>- We think LXD does something around setns() [2] to make sure that the
>container has a correct view of the cgroup "subtree".

yes, cgroup namespaces are very new. Also, they only make full sense
on cgroupsv2 as delegation isn't safe on cgroupsv1 anyway.

> I suspect something can be done in .nspawn files to grant certain
> privileges to work around issues related to ro/rw cgroups trees, etc but I
> think systemd-nspawn has to know about creating the correct cgroup
> hierarchy before passing control to the

As mentioned, if Docker wants to it could work just fine inside of an
nspawn container, it won't have access to any controllers, but it gets
enough write access to delegate things further.

Lennart

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

[systemd-devel] vconsole-setup updates & fixes

2016-07-01 Thread Michal Soltys 
Hi,

This patch fixes issues I mentioned in
http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/36874

And on top of that adds few simple features:

- new vc_max tunable, so user can set how many consoles should be adjusted
- iutf8 is also being [un]set (per-console)

I tried to keep coding style as close as possible to the original.


Michal Soltys (1):
  vconsole-setup: updates & fixes

 src/vconsole/vconsole-setup.c | 260 --
 1 file changed, 125 insertions(+), 135 deletions(-)

-- 
2.9.0

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

[systemd-devel] [PATCH] vconsole-setup: updates & fixes

2016-07-01 Thread Michal Soltys 
This patch updates vconsole helper to:

- correctly handle fonts of heights different than 16
- avoid issues with setfont's -m option

And adds:

- new vc_max tunable, so user can set how many consoles should be adjusted
- iutf8 flag is now set/reset as necessary

Short revised code flow overview:

- determine whether we're setting one console or range
- open tty0 or supplied device, do sanity checks
- parse config and command line (if applicable)
- sanitize vc_max
- do per-console tests (allocated, openable, kbd mode) and if they all pass -
  per-console changes (font, utf8, iutf8, kbd mode)
- if at least one console was modified, do global changes: sysfs utf8 flag,
  loadkeys
---
 src/vconsole/vconsole-setup.c | 260 --
 1 file changed, 125 insertions(+), 135 deletions(-)

diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index 1118118..223235a 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "alloc-util.h"
@@ -35,6 +36,7 @@
 #include "io-util.h"
 #include "locale-util.h"
 #include "log.h"
+#include "parse-util.h"
 #include "process-util.h"
 #include "signal-util.h"
 #include "stdio-util.h"
@@ -43,6 +45,8 @@
 #include "util.h"
 #include "virt.h"
 
+#define MAX_CONSOLES 63
+
 static bool is_vconsole(int fd) {
 unsigned char data[1];
 
@@ -50,57 +54,76 @@ static bool is_vconsole(int fd) {
 return ioctl(fd, TIOCLINUX, data) >= 0;
 }
 
-static int disable_utf8(int fd) {
-int r = 0, k;
-
-if (ioctl(fd, KDSKBMODE, K_XLATE) < 0)
-r = -errno;
+static bool is_settable(int n, int *fd) {
+char vcname[strlen("/dev/vcs") + DECIMAL_STR_MAX(int)];
+int fdt, r, curr_mode;
+
+/* skip non-allocated ttys */
+xsprintf(vcname, "/dev/vcs%i", n);
+if (access(vcname, F_OK) < 0)
+return false;
+
+/* try to open terminal */
+xsprintf(vcname, "/dev/tty%i", n);
+fdt = open_terminal(vcname, O_RDWR|O_CLOEXEC);
+if (fdt < 0)
+return false;
+
+r = ioctl(fdt, KDGKBMODE, _mode);
+/*
+ * Make sure we only adjust consoles in K_XLATE or K_UNICODE mode.
+ * Oterwise we would (likely) interfere with X11's processing of the
+ * key events.
+ *
+ * 
http://lists.freedesktop.org/archives/systemd-devel/2013-February/008573.html
+ */
+if (r || (curr_mode != K_XLATE && curr_mode != K_UNICODE)) {
+close(fdt);
+return false;
+}
 
-k = loop_write(fd, "\033%@", 3, false);
-if (k < 0)
-r = k;
+*fd = fdt;
+return true;
+}
 
-k = write_string_file("/sys/module/vt/parameters/default_utf8", "0", 
0);
-if (k < 0)
-r = k;
+static int toggle_utf8_default(bool utf8) {
+int r;
 
+r = write_string_file("/sys/module/vt/parameters/default_utf8", utf8 ? 
"1" : "0", 0);
 if (r < 0)
-log_warning_errno(r, "Failed to disable UTF-8: %m");
-
-return r;
+log_warning_errno(r, "Failed to %s sysfs UTF-8 flag: %m", utf8 
? "enable" : "disable");
+return r == 0;
 }
 
-static int enable_utf8(int fd) {
-int r = 0, k;
-long current = 0;
-
-if (ioctl(fd, KDGKBMODE, ) < 0 || current == K_XLATE) {
-/*
- * Change the current keyboard to unicode, unless it
- * is currently in raw or off mode anyway. We
- * shouldn't interfere with X11's processing of the
- * key events.
- *
- * 
http://lists.freedesktop.org/archives/systemd-devel/2013-February/008573.html
- *
- */
-
-if (ioctl(fd, KDSKBMODE, K_UNICODE) < 0)
-r = -errno;
-}
+static int toggle_utf8(int fd, bool utf8) {
+struct termios tc;
+int r;
 
-k = loop_write(fd, "\033%G", 3, false);
-if (k < 0)
-r = k;
+r = ioctl(fd, KDSKBMODE, utf8 ? K_UNICODE : K_XLATE);
+if (r < 0) {
+r = -errno;
+log_warning_errno(r, "Failed to %s UTF-8 kbdmode: %m", utf8 ? 
"enable" : "disable");
+return r;
+}
 
-k = write_string_file("/sys/module/vt/parameters/default_utf8", "1", 
0);
-if (k < 0)
-r = k;
+r = loop_write(fd, utf8 ? "\033%G" : "\033%@", 3, false);
+if (r < 0) {
+log_warning_errno(r, "Failed to %s UTF-8 term processing: %m", 
utf8 ? "enable" : "disable");
+return r;
+}
 
+r = tcgetattr(fd, );
+if (r == 0) {
+if (utf8)
+tc.c_iflag |= IUTF8;
+else
+

Re: [systemd-devel] [PATCH] vconsole-setup: updates & fixes

2016-07-01 Thread systemd github import bot 
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


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

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Lennart Poettering 
On Fri, 01.07.16 17:59, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> This is fixed in testing (stretch); a backport of the version from
> stretch, or introducing native systemd services locally, would probably
> help. See  for
> more on this general topic. rpcbind's Debian maintainer does not appear
> to be working on it any more, so I suspect it might be in danger of not
> releasing with Debian 9; if NFS is important to you, you might want to
> look into taking over its maintenance.
> 
> I think vmware-tools might be in a similar situation: relatively early
> boot, but only a LSB init script, not a native systemd service.

Note that systemd upstream does not support early-boot SysV services,
because it's necessarily problematic.

Lennart

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

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Lennart Poettering 
On Fri, 01.07.16 14:44, wolfgang.wag...@riwa-gis.de 
(wolfgang.wag...@riwa-gis.de) wrote:

> My postgresql.service is this:  (unmodified file)
> [Unit]
> Description=PostgreSQL RDBMS
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/true
> ExecReload=/bin/true
> RemainAfterExit=on
> 
> [Install]
> WantedBy=multi-user.target

Hmm, not sure how postgresql is setup on your distro, but the above
unit file is pretty much a nop. How does your postgresql@.service
template unit file look like though?

Normally, if you want a service to run only after all NFS mounts are
in place, add an ordering dependency towards remote-fs.target to
it. Specifically: add a drop-in file
/etc/systemd/system/postgresql@.service.d/50-nfs.conf and write into
it:


[Unit]
After=remote-fs.target


> Maybe it is caused by this  (ssome lines before in journalctl-log):
> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit 
> display-manager.service, ignoring: Unit display-manager.service f
> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on 
> basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on sysinit.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on 
> network-online.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on 
> vmware-tools.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting job 
> rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted to 
> break ordering cycle starting with basic.target/start

So, there's an ordering cycle: basic.target → sysinit.target →
rpcbind.service → network-line.target → vmware-tools.service →
basic.target. Reach each arror in this as "After=" ordering.

This suggests some borkage probably either in vmware-tools.service or
in rpcbind.service. Not sure why the latter wants to be ordered until
after the network is fully up, and not sure why the former wants to be
ordered before that... The key of the issue though is that
vmware-tools is declared a late-boot service (since it wants to be
ordered after basic.target) while rpcbind.service is declared an early
boot service (since it wants to be ordered before basic.target), but
of course that cannot be fulfilled, given both their request for
ordering towards network-online.target.

Consider asking your distro for help, or vmware. This is really
borkage in those unit files. Most likely rpcbind is most broken
service in this regard.

Lennart

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

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Simon McVittie 
On 01/07/16 15:44, wolfgang.wag...@riwa-gis.de wrote:
> Maybe it is caused by this  (ssome lines before in journalctl-log):

I don't know whether it's causal, but dependency loops are never good news.

> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service f
> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on
> basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> sysinit.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> network-online.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> vmware-tools.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting
> job rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted
> to break ordering cycle starting with basic.target/start

I think I recognize this from when Debian switched default init system
to systemd.

Part of the problem is that rpcbind is an early-boot service (rcS,
sysinit.target) but the version in Debian 8 doesn't have a native
systemd service, only an LSB init script in /etc/init.d. systemd has a
generator that can fake a service from that script, but because it
doesn't have all the necessary information and has to make some
assumptions, it's easy for it to create a dependency loop that could
have been avoided when using native services.

This is fixed in testing (stretch); a backport of the version from
stretch, or introducing native systemd services locally, would probably
help. See  for
more on this general topic. rpcbind's Debian maintainer does not appear
to be working on it any more, so I suspect it might be in danger of not
releasing with Debian 9; if NFS is important to you, you might want to
look into taking over its maintenance.

I think vmware-tools might be in a similar situation: relatively early
boot, but only a LSB init script, not a native systemd service.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Reindl Harald 

please strip your quotes

Am 01.07.2016 um 17:44 schrieb killermoehre:

just drop a
---
[Unit]
ReuqiresMountsFor=/mnt/daten/postgis/9.4/main
---
into
»/etc/systemd/system/postgresql@9.4-main.service.d/wait-for-mountpoint.conf«
(create directory and file if necessary) end everything should be fine.
In your fstab also add »_netfs« and remove »noauto« for your mount
point. See »man systemd.unit« for more informations on RequireMountsFor=.


Oh, and obviously write RequiresMountsFor= in the right way and not with
reversed »q« and »u« or missing »s«.
well, after "systemctl daemon-reload" this should become obvious when 
someone takes a look at the systemlogs - sadly even distro-packagers 
don't look proper for errors like typos in their packages







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

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread killermoehre 
Am 01.07.2016 um 17:29 schrieb killermoehre:
> Am 01.07.2016 um 16:44 schrieb wolfgang.wag...@riwa-gis.de:
>> Hello list,
>>
>>  
>>
>> after days of reading man-pages and searching the web i have no solution
>> to my problem, and I am lost in the documentation.
>>
>> My system is Debian Jessie 8.5, upgraded from wheezy 7.11. With Debian
>> wheezy all works fine, after the upgrade to jessie my postgresql-service
>> does not start on boot automatically.
>>
>> Starting manually after booting works fine, but this is not a option for
>> a database-server.
>>
>> I want do some simple thing, which worked with SysV-Init without any
>> problems:
>>
>>  
>>
>> Starting postgresql from a NFS-mount.
>>
>>  
>>
>> I am not able to achieve this. The error is always the same:
>>
>>  
>>
>> Jul 01 16:11:27 postgis1 postgresql@9.4-main[536]: Error:
>> /mnt/daten/postgis/9.4/main is not accessible or does not exist
>>
>> Jul 01 16:11:27 postgis1 systemd[1]: postgresql@9.4-main.service:
>> control process exited, code=exited status=1
>>
>> Jul 01 16:11:27 postgis1 systemd[1]: Failed to start PostgreSQL Cluster
>> 9.4-main.
>>
>> Jul 01 16:11:27 postgis1 systemd[1]: Unit postgresql@9.4-main.service
>> entered failed state.
>>
>>  
>>
>> A few lines after these log-lines i  find this:
>>
>>  
>>
>> Jul 01 16:11:28 postgis1 rpcbind[818]: Starting rpcbind daemon
>>
>> Jul 01 16:11:28 postgis1 rpc.statd[861]: Version 1.2.8 starting
>>
>> Jul 01 16:11:28 postgis1 rpc.statd[861]: Flags: TI-RPC
>>
>> Jul 01 16:11:28 postgis1 kernel: FS-Cache: Loaded
>>
>> Jul 01 16:11:28 postgis1 kernel: RPC: Registered named UNIX socket
>> transport module.
>>
>> Jul 01 16:11:28 postgis1 kernel: RPC: Registered udp transport module.
>>
>> Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp transport module.
>>
>> Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp NFSv4.1 backchannel
>> transport module.
>>
>> Jul 01 16:11:28 postgis1 kernel: FS-Cache: Netfs 'nfs' registered for
>> caching
>>
>>  
>>
>> It seems to me, that NFS-mounts were done after trying to start postgresql.
>>
>>  
>>
>> My postgresql.service is this:  (unmodified file)
>>
>> [Unit]
>>
>> Description=PostgreSQL RDBMS
>>
>>  
>>
>> [Service]
>>
>> Type=oneshot
>>
>> ExecStart=/bin/true
>>
>> ExecReload=/bin/true
>>
>> RemainAfterExit=on
>>
>>  
>>
>> [Install]
>>
>> WantedBy=multi-user.target
>>
>> ---
>>
>> Modifications in section [Unit] like :
>>
>> ConditionPathExists=/mnt/daten/postgis
>>
>>  
>>
>> Requires=mnt-daten-postgis.mount
>>
>> Before=mnt-daten-postgis.mount
>>
>> (and creating a Unit-file for the mount-point, enabling etc. instead of
>> /etc/fstab) don’t change the problem.
>>
>>  
>>
>> After booting is complete, the mount is available, but not at the time,
>> when postgresql should  be startet.
>>
>>  
>>
>> Maybe it is caused by this  (ssome lines before in journalctl-log):
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit
>> display-manager.service, ignoring: Unit display-manager.service f
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on
>> basic.target/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
>> sysinit.target/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
>> rpcbind.service/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
>> network-online.target/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
>> vmware-tools.service/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting
>> job rpcbind.service/start
>>
>> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted
>> to break ordering cycle starting with basic.target/start
>>
>>  
>>
>>  
>>
>> Where is my error?
>>
>>  
>>
>>  
>>
>> mit freundlichen Grüssen
>>
>>  
>>
>> Wolfgang Wagner
>>
>> Systemadministration
>>
>>  
>>
>> RIWA GmbH
>>
>> Gesellschaft für Geoinformationen
>>
>> Zwingerstr. 2, 87435 Kempten
>>
>> E-Mail: wolfgang.wag...@riwa-gis.de
>>
>> http://www.riwa-gis.de
>>
>>  
>>
>> --
>> RIWA GmbH, Zwingerstrasse 2, 87435 Kempten
>> Sitz der Gesellschaft: Kempten (Allgaeu)
>> Registergericht: Amtsgericht Kempten, HRB 6480
>> Geschaeftsfuehrer: Dipl.-Ing. Guenter Kraus
>> --
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> 
> Hi,
> 
> just drop a
> ---
> [Unit]
> ReuqiresMountsFor=/mnt/daten/postgis/9.4/main
> ---
> into
> »/etc/systemd/system/postgresql@9.4-main.service.d/wait-for-mountpoint.conf«
> (create directory and file if necessary) end everything should be fine.
> In your fstab

Re: [systemd-devel] Use of namespaced cgroups (aka Docker in systemd-nspawn containers)

2016-07-01 Thread Chris Kühl 
On Mon, Jun 27, 2016 at 4:58 PM, Lee Hambley  wrote:
> Hi List,
>
> My company is currently conducting research into the most viable container
> technology that fits our stack (CentOS based) and given our already
> widespread reliance on systemd, I have a personal stake in preferring not to
> introduce other tooling (LXD, the 2nd place leader) into our stack.
>
> I'd like to know what is required to fulfil our use-case (Docker in
> LXD/systemd-nspawn)
>

Hi Lee,

You may want to look into rkt[1] if you're on CentOS 7. By default it
uses systemd-nspawn to set up the containerized environment and it's
designed to work and integrate well with systemd.

If you want to talk more about it, it'd probably be best to take the
conversation to the rkt-dev list[2] or the #rkt-dev freennode channel.

Cheers,
Chris

disclaimer: My company contributes to rkt.

[1] https://github.com/coreos/rkt
[2] https://groups.google.com/forum/#!forum/rkt-dev

> Here's what I (think I) know:
>
> Docker can't run in systemd-nspawn because cgroup fs is mounted ro, and the
> systemd-nspwan container sees the entire system's cgroupfs (no namespacing)
> cgroups filesystem normally mounted ro in containers, to protect the host
> (or, something related to privileged containers)
>
> When mounted rw it can break the host (not the worst problem in the world,
> we're not defending against malice here, but apparently it's trivial to
> brick the host by having systemd fight over ttys, etc)
> it might be fair to say that privilidged containers
>
> namespaces cgroups are relatively new in linux
>
> available 4.6 [1]
> backported to 4.4+ on Ubuntu kernels
>
> We think LXD does something around setns() [2] to make sure that the
> container has a correct view of the cgroup "subtree".
>
>
> I suspect something can be done in .nspawn files to grant certain privileges
> to work around issues related to ro/rw cgroups trees, etc but I think
> systemd-nspawn has to know about creating the correct cgroup hierarchy
> before passing control to the
>
> Please excuse the "idiot knows what he's talking about tone" I'm very deep
> into this stuff today, and not in a good way.
>
> Thanks sincerely,
>
> ---
>
> [1]:
> https://www.phoronix.com/scan.php?page=news_item=CGroup-Namespaces-Linux-4.6
> [2]:
> https://github.com/lxc/lxd/blob/c8a2956fae6d5d2092e17a3229e4640b53c8a854/lxd/nsexec.go#L107-L126
>
> Lee Hambley
> http://lee.hambley.name/
> +49 (0) 170 298 5667
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread killermoehre 
Am 01.07.2016 um 16:44 schrieb wolfgang.wag...@riwa-gis.de:
> Hello list,
> 
>  
> 
> after days of reading man-pages and searching the web i have no solution
> to my problem, and I am lost in the documentation.
> 
> My system is Debian Jessie 8.5, upgraded from wheezy 7.11. With Debian
> wheezy all works fine, after the upgrade to jessie my postgresql-service
> does not start on boot automatically.
> 
> Starting manually after booting works fine, but this is not a option for
> a database-server.
> 
> I want do some simple thing, which worked with SysV-Init without any
> problems:
> 
>  
> 
> Starting postgresql from a NFS-mount.
> 
>  
> 
> I am not able to achieve this. The error is always the same:
> 
>  
> 
> Jul 01 16:11:27 postgis1 postgresql@9.4-main[536]: Error:
> /mnt/daten/postgis/9.4/main is not accessible or does not exist
> 
> Jul 01 16:11:27 postgis1 systemd[1]: postgresql@9.4-main.service:
> control process exited, code=exited status=1
> 
> Jul 01 16:11:27 postgis1 systemd[1]: Failed to start PostgreSQL Cluster
> 9.4-main.
> 
> Jul 01 16:11:27 postgis1 systemd[1]: Unit postgresql@9.4-main.service
> entered failed state.
> 
>  
> 
> A few lines after these log-lines i  find this:
> 
>  
> 
> Jul 01 16:11:28 postgis1 rpcbind[818]: Starting rpcbind daemon
> 
> Jul 01 16:11:28 postgis1 rpc.statd[861]: Version 1.2.8 starting
> 
> Jul 01 16:11:28 postgis1 rpc.statd[861]: Flags: TI-RPC
> 
> Jul 01 16:11:28 postgis1 kernel: FS-Cache: Loaded
> 
> Jul 01 16:11:28 postgis1 kernel: RPC: Registered named UNIX socket
> transport module.
> 
> Jul 01 16:11:28 postgis1 kernel: RPC: Registered udp transport module.
> 
> Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp transport module.
> 
> Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp NFSv4.1 backchannel
> transport module.
> 
> Jul 01 16:11:28 postgis1 kernel: FS-Cache: Netfs 'nfs' registered for
> caching
> 
>  
> 
> It seems to me, that NFS-mounts were done after trying to start postgresql.
> 
>  
> 
> My postgresql.service is this:  (unmodified file)
> 
> [Unit]
> 
> Description=PostgreSQL RDBMS
> 
>  
> 
> [Service]
> 
> Type=oneshot
> 
> ExecStart=/bin/true
> 
> ExecReload=/bin/true
> 
> RemainAfterExit=on
> 
>  
> 
> [Install]
> 
> WantedBy=multi-user.target
> 
> ---
> 
> Modifications in section [Unit] like :
> 
> ConditionPathExists=/mnt/daten/postgis
> 
>  
> 
> Requires=mnt-daten-postgis.mount
> 
> Before=mnt-daten-postgis.mount
> 
> (and creating a Unit-file for the mount-point, enabling etc. instead of
> /etc/fstab) don’t change the problem.
> 
>  
> 
> After booting is complete, the mount is available, but not at the time,
> when postgresql should  be startet.
> 
>  
> 
> Maybe it is caused by this  (ssome lines before in journalctl-log):
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service f
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on
> basic.target/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> sysinit.target/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> rpcbind.service/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> network-online.target/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> vmware-tools.service/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting
> job rpcbind.service/start
> 
> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted
> to break ordering cycle starting with basic.target/start
> 
>  
> 
>  
> 
> Where is my error?
> 
>  
> 
>  
> 
> mit freundlichen Grüssen
> 
>  
> 
> Wolfgang Wagner
> 
> Systemadministration
> 
>  
> 
> RIWA GmbH
> 
> Gesellschaft für Geoinformationen
> 
> Zwingerstr. 2, 87435 Kempten
> 
> E-Mail: wolfgang.wag...@riwa-gis.de
> 
> http://www.riwa-gis.de
> 
>  
> 
> --
> RIWA GmbH, Zwingerstrasse 2, 87435 Kempten
> Sitz der Gesellschaft: Kempten (Allgaeu)
> Registergericht: Amtsgericht Kempten, HRB 6480
> Geschaeftsfuehrer: Dipl.-Ing. Guenter Kraus
> --
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

Hi,

just drop a
---
[Unit]
ReuqiresMountsFor=/mnt/daten/postgis/9.4/main
---
into
»/etc/systemd/system/postgresql@9.4-main.service.d/wait-for-mountpoint.conf«
(create directory and file if necessary) end everything should be fine.
In your fstab also add »_netfs« and remove »noauto« for your mount
point. See »man systemd.unit« for more informations on RequireMountsFor=.

Regards




signature.asc
Description: OpenPGP digital

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Reindl Harald 



Am 01.07.2016 um 16:44 schrieb wolfgang.wag...@riwa-gis.de:

Modifications in section [Unit] like :

ConditionPathExists=/mnt/daten/postgis
Requires=mnt-daten-postgis.mount
Before=mnt-daten-postgis.mount


nonsense - you explicitly state that it should be startet *before* the 
mountpoint - when you want something to be started after some other 
thing, well then you say After=whatever-should-be-started-before


Requires and Before with the same value is not solveable at all



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

[systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread wolfgang.wagner 
Hello list,

after days of reading man-pages and searching the web i have no solution to my 
problem, and I am lost in the documentation.
My system is Debian Jessie 8.5, upgraded from wheezy 7.11. With Debian wheezy 
all works fine, after the upgrade to jessie my postgresql-service does not 
start on boot automatically.
Starting manually after booting works fine, but this is not a option for a 
database-server.
I want do some simple thing, which worked with SysV-Init without any problems:

Starting postgresql from a NFS-mount.

I am not able to achieve this. The error is always the same:

Jul 01 16:11:27 postgis1 postgresql@9.4-main[536]: Error: 
/mnt/daten/postgis/9.4/main is not accessible or does not exist
Jul 01 16:11:27 postgis1 systemd[1]: postgresql@9.4-main.service: control 
process exited, code=exited status=1
Jul 01 16:11:27 postgis1 systemd[1]: Failed to start PostgreSQL Cluster 
9.4-main.
Jul 01 16:11:27 postgis1 systemd[1]: Unit postgresql@9.4-main.service entered 
failed state.

A few lines after these log-lines i  find this:

Jul 01 16:11:28 postgis1 rpcbind[818]: Starting rpcbind daemon
Jul 01 16:11:28 postgis1 rpc.statd[861]: Version 1.2.8 starting
Jul 01 16:11:28 postgis1 rpc.statd[861]: Flags: TI-RPC
Jul 01 16:11:28 postgis1 kernel: FS-Cache: Loaded
Jul 01 16:11:28 postgis1 kernel: RPC: Registered named UNIX socket transport 
module.
Jul 01 16:11:28 postgis1 kernel: RPC: Registered udp transport module.
Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp transport module.
Jul 01 16:11:28 postgis1 kernel: RPC: Registered tcp NFSv4.1 backchannel 
transport module.
Jul 01 16:11:28 postgis1 kernel: FS-Cache: Netfs 'nfs' registered for caching

It seems to me, that NFS-mounts were done after trying to start postgresql.

My postgresql.service is this:  (unmodified file)
[Unit]
Description=PostgreSQL RDBMS

[Service]
Type=oneshot
ExecStart=/bin/true
ExecReload=/bin/true
RemainAfterExit=on

[Install]
WantedBy=multi-user.target
---
Modifications in section [Unit] like :
ConditionPathExists=/mnt/daten/postgis

Requires=mnt-daten-postgis.mount
Before=mnt-daten-postgis.mount
(and creating a Unit-file for the mount-point, enabling etc. instead of 
/etc/fstab) don't change the problem.

After booting is complete, the mount is available, but not at the time, when 
postgresql should  be startet.

Maybe it is caused by this  (ssome lines before in journalctl-log):
Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service f
Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on basic.target/start
Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on sysinit.target/start
Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on rpcbind.service/start
Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on 
network-online.target/start
Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on 
vmware-tools.service/start
Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on basic.target/start
Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting job 
rpcbind.service/start
Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted to break 
ordering cycle starting with basic.target/start


Where is my error?


mit freundlichen Grüssen

Wolfgang Wagner
Systemadministration

RIWA GmbH
Gesellschaft für Geoinformationen
Zwingerstr. 2, 87435 Kempten
E-Mail: wolfgang.wag...@riwa-gis.de
http://www.riwa-gis.de



--
RIWA GmbH, Zwingerstrasse 2, 87435 Kempten
Sitz der Gesellschaft: Kempten (Allgaeu)
Registergericht: Amtsgericht Kempten, HRB 6480
Geschaeftsfuehrer: Dipl.-Ing. Guenter Kraus
--

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