Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment

[Nathan Williams]

Fwiw, if you're using Chef, the impending release of v3 of the systemd
cookbook has a machine_image and a machine resource, which use importd and
nspawn under the hood.

On Wed, Oct 19, 2016, 3:45 PM Lennart Poettering 
wrote:

> On Thu, 13.10.16 01:09, Brian Kroth (bpkr...@gmail.com) wrote:
>
> > Seems really dependent upon the container layout as to what's the most
> > appropriate way of doing that. For instance, if the underlying fs of the
> > source container is something like btrfs or zfs you could imagine doing a
> > send/recv of a golden snapshot. Possibly also for an lvm volume/snapshot.
> > For others rsync might be best. For others maybe it's just a deployment
> > script or tar or git repo.
>
> Yeah, to make this clear: I doubt we should really be in the
> deployment business too much. That's for other people to solve, for
> example rkt.
>
> However, I do think the most basic bits should probably be available,
> simply to get developers off the ground for the most basic testing. I
> figure that means "machinectl migrate" (as suggested in the other
> mail) is really as good as it might get, and anything fancier should
> really be left to other projects.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> 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 deploy systemd-nspawn containers and use for deployment

[Lennart Poettering]

On Thu, 13.10.16 10:22, Samuel Williams (space.ship.travel...@gmail.com) wrote:

> I'm not sure if this belongs in machinectl, but it would be interesting to
> explore some kind of deployment mechanism. e.g. machinectl deploy
> local-container-name ssh://remote-server:container-name because I'm sure
> this is going to be a really common use case, and there are enough details
> (e.g. stopping and starting the remote machine) that it would be nice to
> keep it easy for new users.

There's a TODO list item somewhere, to add "machinectl migrate
$CONTAINER $HOST" which would basically be a combination of
"export-tar"  locally, then an ssh link, and an "import-tar"
remotely or so.

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 deploy systemd-nspawn containers and use for deployment

[Lennart Poettering]

On Wed, 12.10.16 15:29, Samuel Williams (space.ship.travel...@gmail.com) wrote:

> Hello.
> 
> I've been thinking about how I could use systemd-nspawn containers.
> 
> Ideally, we have a local container which can then be pushed to one or more
> VPS instances.
> 
> An example workflow might look like this:
> 
> - Step 1: On development box, update some software in a container and test.
> It's okay.
> - Step 2: Push the container to several VPSs, some procedure to minimise
> downtime while updating.



> - Step 3: ...
> - Step 4: Profit.
> 
> For step 2, what would be the best practice. Rsync the local container to
> the remote container?

That's one option. Another one is to do "machinectl export-tar foo |
ssh someothermachine machinectl import-tar foo"...

You can also upload a tarball generated like that to some web server and then 
issue
"machinectl pull-tar" with the URL to download it on the host you want
to run it on.

Another way to generate images for deployment is to use the new
"mkiso" tool, which spits out signatures and shasums too, which make
it easy to place the stuff on a http server that machinectl pull-tar
can make use of...

-- 
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 deploy systemd-nspawn containers and use for deployment

[Lennart Poettering]

On Thu, 13.10.16 01:09, Brian Kroth (bpkr...@gmail.com) wrote:

> Seems really dependent upon the container layout as to what's the most
> appropriate way of doing that. For instance, if the underlying fs of the
> source container is something like btrfs or zfs you could imagine doing a
> send/recv of a golden snapshot. Possibly also for an lvm volume/snapshot.
> For others rsync might be best. For others maybe it's just a deployment
> script or tar or git repo.

Yeah, to make this clear: I doubt we should really be in the
deployment business too much. That's for other people to solve, for
example rkt.

However, I do think the most basic bits should probably be available,
simply to get developers off the ground for the most basic testing. I
figure that means "machinectl migrate" (as suggested in the other
mail) is really as good as it might get, and anything fancier should
really be left to other projects.

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] keyscript support in systemd-cryptsetup

[Lennart Poettering]

On Wed, 19.10.16 16:10, Ryan Castellucci 
(ryan.castellucci+systemd-de...@gmail.com) wrote:

> It looks like my use case could be supported with a "Password Agent", and
> it seems that it would be possible to wrap the existing keyscript stuff
> (though the interface is much more complicated).
> 
> How should a password agent be started? Is there a way to disable
> particular password agents?

Well, you could start them as services. And services can be
enabled/disabled/masked, of course.

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] keyscript support in systemd-cryptsetup

[Ryan Castellucci]

It looks like my use case could be supported with a "Password Agent", and
it seems that it would be possible to wrap the existing keyscript stuff
(though the interface is much more complicated).

How should a password agent be started? Is there a way to disable
particular password agents?

On Wed, Oct 19, 2016 at 3:35 PM, Lennart Poettering 
wrote:

> On Wed, 19.10.16 15:28, Ryan Castellucci (ryan.castellucci+systemd-deve
> l...@gmail.com) wrote:
>
> > Systemd broke a use case that people were actively using, and cryptsetup
> > comes with scripts to support.
>
> Humm, the keyscript thing was a Debian-specific extension. It was
> never supported on systemd or any non-Debian distro. I wouldn't really
> call that breaking... But yeah, we don't support this scheme natively.
>
> > If you won't merge the patch that addresses this, can you explain what
> > needs to be done to support the "use some administrator defined program
> to
> > supply the password" use case that you will merge? Depending on the
> scope,
> > I may be able to write the code. Is there any way this can be done with a
> > wrapper so that people don't have to maintain two versions of their
> > programs?
>
> I don't think the keyscript= concept fits into systemd, sorry. I can
> understand you want this, but all I can suggest is to write a bit of
> glue to make it possible to run keyscript= scripts via the ask
> password logic. It's not too hard, an the API to use is documented here:
>
> https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/
>
> 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] systemd 210 - mount/umount/remount

[Lennart Poettering]

On Fri, 14.10.16 12:06, Michael Hirmke (camp...@mike.franken.de) wrote:

> 1. How can I prevent systemd from mounting a manually unmounted
>partition? The partiton should be mounted automatically during system
>start, though.

There were some changes related to this in more recent versions of
systemd. Consider upgrading, 210 is pretty ancient.

That said, if you don't want systemd to mount the thing, consider
removing it from /etc/fstab (or setting "noauto" on the entry there)
and issuing "systemctl daemon-reload".

In never systemd versions you can also take BSD file lock on the
top-level device node in order to block udev from refreshing the
device and generating events for it.

> 2. If I would switch from mount/umount to pure systemd behaviour for
>mounting and unmounting partitons in my script, would a command like
>"systemctl stop|start /var/backup" be sufficient?
>And how would a remount command (for read only or read write) look
>like?

"systemctl stop /var/backup" is probably not going to suffice. If you
modify your partition table/disk image during runtime this means the
device will vanish from and return to systemd's view as the accesses
are serialized. Whenever the device pops up again systemd might
requeue the jobs declared in /etc/fstab via the "auto" mount option.

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] BUG: Huge Problem: systemd does not mount all filesystems on Boot

[Lennart Poettering]

On Fri, 14.10.16 11:11, Juergen Sauer (juergen.sa...@automatix.de) wrote:

> Moin,
> 
> Systemd 231, Archlinux current
> 
> The concept is /home is to be mounted from nfs server. Works.
> For performance reasons (email thunderbird, kde/plasma 5.8.x i.e odr
> gnome are unusable if home is pure nfs) the user sub dirs .local,
> .cache, .config, .thunderbird etc. are mounts from local fs (btrfs
> subvolume).
> 
> Network is without NetWorkmanager (masked), fixed configured via
> systemd-networkd.
> 
> The Problem is, after boot /home is mounted or not, random
> result. WTF?!?

As others already pointed out: mounting local device-based file
systems inside of remote network-based ones isn't particularly well
supported. We generally mount network-based mounts pretty late (since
NM and friends are late-boot services usually, and we need to be
compatible with that), but local file systems pretty early during
the earliest boot phases. If you now nest local file systems into
remote ones, then this creates a cyclic ordering dependency: the local
mounts are mounted first, the network mounts second, but want to be
mounted before the local mounts. Which of course can't be fulfilled
fully.

If systemd runs into a cyclic dep like this it's usually approach is
to remove jobs from the cyclce until the cycle is gone. Which one is
removed is not deterministic, and that's what you are seeing.

My general recommendation would be not to do such setups of nesting
local mounts within remote mounts. But if you really want to do that,
you should probably be able to mark your nested mounts as remote and
thus remove the ordering problem. Specifically, adding "_netdev" as
mount option to the relevant mounts should suffice.

Hope this makes sense,

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] keyscript support in systemd-cryptsetup

[Lennart Poettering]

On Wed, 19.10.16 15:28, Ryan Castellucci 
(ryan.castellucci+systemd-de...@gmail.com) wrote:

> Systemd broke a use case that people were actively using, and cryptsetup
> comes with scripts to support.

Humm, the keyscript thing was a Debian-specific extension. It was
never supported on systemd or any non-Debian distro. I wouldn't really
call that breaking... But yeah, we don't support this scheme natively.

> If you won't merge the patch that addresses this, can you explain what
> needs to be done to support the "use some administrator defined program to
> supply the password" use case that you will merge? Depending on the scope,
> I may be able to write the code. Is there any way this can be done with a
> wrapper so that people don't have to maintain two versions of their
> programs?

I don't think the keyscript= concept fits into systemd, sorry. I can
understand you want this, but all I can suggest is to write a bit of
glue to make it possible to run keyscript= scripts via the ask
password logic. It's not too hard, an the API to use is documented here:

https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/

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] keyscript support in systemd-cryptsetup

[Ryan Castellucci]

Systemd broke a use case that people were actively using, and cryptsetup
comes with scripts to support.

There were complaints about this four years ago, you rejected a patch that
would have resolved it, and it still has not been addressed.

If you won't merge the patch that addresses this, can you explain what
needs to be done to support the "use some administrator defined program to
supply the password" use case that you will merge? Depending on the scope,
I may be able to write the code. Is there any way this can be done with a
wrapper so that people don't have to maintain two versions of their
programs?

On Wed, Oct 19, 2016 at 2:27 PM, Lennart Poettering 
wrote:

> On Wed, 19.10.16 11:20, Ryan Castellucci (ryan.castellucci+systemd-
> de...@gmail.com) wrote:
>
> > What will it take to get keyscript support in systemd-cryptsetup fixed?
> >
> > This is a nasty regression for people who were using that functionality,
> > and it necessitating some pretty ugly workarounds. I understand from
> > previous threads that there's an aversion to restoring this without some
> > more generic key handling functionality. I disagree with this stance,
> it's
> > a case of "perfect is the enemy of good" - keyscripts work well enough,
> are
> > easy to work with, and seem as though they should be easy to implement (I
> > think I even saw a patch).
> >
> > Under older initscripts, I was able to write a very small shell script or
> > trivial statically compiled C program that does whatever custom
> > functionality I need to get a password for LUKS and dump it on STDOUT. I
> > don't want to have to rewrite my existing scripts or deal with anything
> > more complicated than this.
> >
> > I mainly use non-interactive keyscripts, so I've been able to
> re-implement
> > the automapping of my encrypted volumes by some ugly udev hackery, but I
> > have other stuff I've used in the past (for example, requiring a quorum
> of
> > admins to enter passwords) for which this doesn't work.
>
> It should be possibly to write a password agent that does what
> keyscripts do, without adding direct keyscript support to
> systemd-crpytsetup itself.
>
> systemd is not supposed to be this conglomerate of pieces glued
> together with scripts here and scripts there. That makes me very
> conservative in adding a concept such as "keyscripts" to our tools,
> natively. Sorry.
>
> It's not that we didn't have an API for that, there's just some glue
> missing to make it work for your use case, but it shouldn't be too
> hard to write.
>
> Sorry,
>
> 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] systemd - how to run system service by user target

[Lennart Poettering]

On Wed, 19.10.16 12:46, Kamil Jońca (kjo...@o2.pl) wrote:

> 
> Assume we have openvpn.service.
> This service neccessary only when I want to connect to my work from
> home.
> 
> Is it possible to make user target which will be automatically run this
> service?

Whenever a user logs in it will get a per-user slice unit
started. When the user logs out, the slice unit is removed. You could
make sure that your service is pulled in by this slice when the slice
is started (and hence at login) and stopped whenever the slice is
stopped (i.e. at last logout). There's no particularly nice scheme for
that in place, but if you have well-established UIDs, it would be as
easy as dropping in a symlink
/etc/systemd/system/user-1000.slice.wants/
pointing to your main service file. Then, inside that file, add
dependencies back to the slice, i.e. something like
BindsTo=user-1000.slice

I hope you get the idea of what I am suggesting here...

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] keyscript support in systemd-cryptsetup

[Lennart Poettering]

On Wed, 19.10.16 11:20, Ryan Castellucci 
(ryan.castellucci+systemd-de...@gmail.com) wrote:

> What will it take to get keyscript support in systemd-cryptsetup fixed?
> 
> This is a nasty regression for people who were using that functionality,
> and it necessitating some pretty ugly workarounds. I understand from
> previous threads that there's an aversion to restoring this without some
> more generic key handling functionality. I disagree with this stance, it's
> a case of "perfect is the enemy of good" - keyscripts work well enough, are
> easy to work with, and seem as though they should be easy to implement (I
> think I even saw a patch).
> 
> Under older initscripts, I was able to write a very small shell script or
> trivial statically compiled C program that does whatever custom
> functionality I need to get a password for LUKS and dump it on STDOUT. I
> don't want to have to rewrite my existing scripts or deal with anything
> more complicated than this.
> 
> I mainly use non-interactive keyscripts, so I've been able to re-implement
> the automapping of my encrypted volumes by some ugly udev hackery, but I
> have other stuff I've used in the past (for example, requiring a quorum of
> admins to enter passwords) for which this doesn't work.

It should be possibly to write a password agent that does what
keyscripts do, without adding direct keyscript support to
systemd-crpytsetup itself.

systemd is not supposed to be this conglomerate of pieces glued
together with scripts here and scripts there. That makes me very
conservative in adding a concept such as "keyscripts" to our tools,
natively. Sorry.

It's not that we didn't have an API for that, there's just some glue
missing to make it work for your use case, but it shouldn't be too
hard to write.

Sorry,

Lennart

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

[systemd-devel] keyscript support in systemd-cryptsetup

[Ryan Castellucci]

What will it take to get keyscript support in systemd-cryptsetup fixed?

This is a nasty regression for people who were using that functionality,
and it necessitating some pretty ugly workarounds. I understand from
previous threads that there's an aversion to restoring this without some
more generic key handling functionality. I disagree with this stance, it's
a case of "perfect is the enemy of good" - keyscripts work well enough, are
easy to work with, and seem as though they should be easy to implement (I
think I even saw a patch).

Under older initscripts, I was able to write a very small shell script or
trivial statically compiled C program that does whatever custom
functionality I need to get a password for LUKS and dump it on STDOUT. I
don't want to have to rewrite my existing scripts or deal with anything
more complicated than this.

I mainly use non-interactive keyscripts, so I've been able to re-implement
the automapping of my encrypted volumes by some ugly udev hackery, but I
have other stuff I've used in the past (for example, requiring a quorum of
admins to enter passwords) for which this doesn't work.

bug references:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451032
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd - how to run system service by user target

[Kamil Jońca]

Assume we have openvpn.service.
This service neccessary only when I want to connect to my work from
home.

Is it possible to make user target which will be automatically run this
service?
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/
Alas, I am dying beyond my means.
-- Oscar Wilde [as he sipped champagne on his deathbed]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel