Re: [systemd-devel] Getting rid of the /run/credentials mount

2022-08-31 Thread Marc Haber
On Fri, Aug 26, 2022 at 07:28:37AM +0200, Marc Haber wrote:
> On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote:
> > On 25.8.2022 22.42, Marc Haber wrote:
> > > on the system and sends an alert if things change on the system. In the
> > > Debian package, this is done from cron. I would like to move that to a
> > > systemd timer and in passing use some of systemd's security features.
> > > Here is my service:
> > > 
> > > What do I do to disable the credentials mechanism in my service?
> > 
> > You could use TemporaryFileSystem=/run together with a few BindPaths= for
> > the required directories. For example, on my setup the user doesn't see all
> > cruft in global /run:
> > $ ls /run
> > dbus/  firejail/  systemd/  udev/  user/
> > 
> > See also
> > https://github.com/systemd/systemd/pull/21748
> > for some thoughts on tentative new directive PrivateRun= or something
> > similar.
> 
> My intention is the opposite. I want (and need!) my process to see what
> is actually in /run. Nothing should be hidden away. The process itself
> doesn't use anything in /run, but I want it to be able to detect changes.

I filed an enhancement issue,
https://github.com/systemd/systemd/issues/24508

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


Re: [systemd-devel] Getting rid of the /run/credentials mount

2022-08-25 Thread Marc Haber
On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote:
> On 25.8.2022 22.42, Marc Haber wrote:
> > on the system and sends an alert if things change on the system. In the
> > Debian package, this is done from cron. I would like to move that to a
> > systemd timer and in passing use some of systemd's security features.
> > Here is my service:
> > 
> > What do I do to disable the credentials mechanism in my service?
> 
> You could use TemporaryFileSystem=/run together with a few BindPaths= for
> the required directories. For example, on my setup the user doesn't see all
> cruft in global /run:
> $ ls /run
> dbus/  firejail/  systemd/  udev/  user/
> 
> See also
> https://github.com/systemd/systemd/pull/21748
> for some thoughts on tentative new directive PrivateRun= or something
> similar.

My intention is the opposite. I want (and need!) my process to see what
is actually in /run. Nothing should be hidden away. The process itself
doesn't use anything in /run, but I want it to be able to detect changes.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


[systemd-devel] Getting rid of the /run/credentials mount

2022-08-25 Thread Marc Haber
Hi,

the aide (https://github.com/aide/aide) tool builds checksums of files
on the system and sends an alert if things change on the system. In the
Debian package, this is done from cron. I would like to move that to a
systemd timer and in passing use some of systemd's security features.
Here is my service:

[Unit]
Description=dailyaide check
StartLimitIntervalSec=7200
StartLimitBurst=1

[Service]
Type=oneshot
User=root
Group=root
Environment="CREDENTIALS_DIRECTORY=/nonexistent"
ProtectSystem=strict
ProtectClock=yes
ProtectKernelModules=no
ProtectKernelLogs=yes
ProtectControlGroups=yes
PrivateDevices=no
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectHome=read-only
ReadWritePaths=/run/aide /var/lib/aide /var/log/aide /var/spool/exim4 
/var/log/exim4 /var/tmp /tmp
RestrictRealtime=yes
RestrictSUIDSGID=yes
PrivateTmp=no
ExecStartPre-=/bin/umount /run/credentials
ExecStart=/usr/local/sbin/dailyaidecheck --systemdservice

You might see that I have tried some things to get rid of the mount of
/run/credentials which allows an attacker to hide something in
/run/credentials without aide being able to see it because it gets some
temporary filesystem mounted over that path.

Unfortunately, neither of those tricks have worked, and my
/run/credentials/foo that I created before starting my service remains
undetected.

What do I do to disable the credentials mechanism in my service?

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


Re: [systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?

2021-06-14 Thread Marc Haber
On Mon, Jun 14, 2021 at 09:59:24AM +0200, Lennart Poettering wrote:
> It's the boot ID, i.e. /proc/sys/kernel/random/boot_id. We include it
> in the name so that we can distinguish such dirs of the current boot
> from those of earlier boots (which can be retained because of abnormal
> shutdown or so). In the latter case we can safely remove them to avoid
> collecting left-over directories.

Thanks for the explanation, I appreciate that.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?

2021-06-13 Thread Marc Haber
Hi,

I am wondering where the 32 xdigit number in pathnames like

systemd-private-27aa635a15cf4da0a7ebda10f25c3950-chrony.service-9DShFi/

comes from. I always had the impression that it's the systemd/dbus
machine id, but that does not seem to be the case. Is that just an
arbitrary random number, or can it be predicted in a way?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Networkd - how to augment an already configured interface

2020-03-21 Thread Marc Haber
On Thu, Mar 12, 2020 at 06:24:48PM +, Susant Sahani wrote:
> https://www.freedesktop.org/software/systemd/man/systemd.network.html#KeepConfiguration=

Stupid me, I forgot that I already had this issue back last year. And I
still don't have a later systemd. Please forget that I asked.

Greetings
Ma "this is now documented" rc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Networkd - how to augment an already configured interface

2020-03-12 Thread Marc Haber
Hi,

for a rather complex tunneling setup on a system that uses
systemd-networkd and OpenVPN, I am trying to use networkd to augment the
Interface that has been configured by OpenVPN.

In OpenVPN, a daemon is started with a service unit, which connects to a
remote side and creates a tunX interface and configures it according to
what the other side says. The other side can push basic configuration
like IP address and routes that go into the main routing table, but I
need a RoutingPolicyRule and addiitonal Routes pushed into the
configuration.

I tried writing the following tunX.network unit:

[Match]
Name=tun1

[Network]
Description=tun1 tunnel to old torres
DHCP=no
IPForward=yes
IPv6AcceptRA=no

[Route]
Destination=0::/0
Gateway=2a01:238:4071:3202::1
Table=202

[RoutingPolicyRule]
Priority=32100
From=2a01:238:4071:3280::/59
Table=202

[RoutingPolicyRule]
Priority=32101
From=2a01:238:4071:32b0::/62
Table=202

but it looks like networkd wants full control over the network interface
and flushes the IP addresses from the working interface, leaving it in a
non-functional state.

Is there any way to

(a) tell networkd to just add the configuration from the unit to the
already interface without cleaning up first, or
(b) to have part of systemd just execute a single .network unit,
probably as a sidekick unit that I can use to add configuration to my
OpenVPN configuration?

Or am I better off by just taking things away from systemd-networkd
completely and use an "up" script from the OpenVPN configuration?

Hoping for your opinions and a good discussion,
cheers, Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] disable EDNS in systemd-resolved

2019-12-27 Thread Marc Haber
On Fri, Dec 27, 2019 at 11:25:20AM +0200, Mantas Mikulėnas wrote:
> On Fri, Dec 27, 2019 at 10:52 AM Marc Haber 
> wrote:
> > how would I disable EDNS in systemd-resolved? Some recursive DNS servers
> > (for example in public hotspots) choke on queries with EDNS options.
> >
> 
> I don't think there is a configuration option, but resolved *should*
> automatically detect lack of EDNS support (grep the system log for
> "feature"). Do the queries simply time out, or do they get rejected?
> 
> Make sure you don't have DNSSEC support set to "yes", since it depends on
> EDNS.

The DNS recursor of the Hotsplots network that I will use in the next
three days just returns an authoritative NXDOMAIN. Yes, that's broken. I
still need my system to handle the situation.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] disable EDNS in systemd-resolved

2019-12-27 Thread Marc Haber
Hi,

how would I disable EDNS in systemd-resolved? Some recursive DNS servers
(for example in public hotspots) choke on queries with EDNS options.

I didn't find anything about this in the systemd-resolved or resolvectl
manual pages for systemd 244.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Unit dependencies for socket activated services

2019-10-13 Thread Marc Haber
Hallo,

when I want a normal service to be started only after the networks is
ready, I put

|[Unit]
|After=network-online.target
|Wants=network-online.target

into the service unit.

Now I have a socket activated service which I know won't properly start
(but claim readiness) if started before the network is ready.

Would I put those two lines into foo.service or foo.socket?

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?

2019-09-26 Thread Marc Haber
On Thu, Sep 26, 2019 at 09:16:53AM +, Susant Sahani wrote:
> On 26/09/19, 11:49 AM, "Marc Haber"  wrote:
> > 
> > Did you tried with KeepConfiguration=?
> 
> That is not yet in the Man Page on my system. Is it alreay there in
> systemd 242?
> 
> This is in 243.

I'll have to wait then. Thanks.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?

2019-09-26 Thread Marc Haber
Hi Susant,

On Wed, Sep 25, 2019 at 05:56:23PM +, Susant Sahani wrote:
> On 22/09/19, 5:35 PM, "systemd-devel on behalf of Marc Haber" 
>  mh+systemd-de...@zugschlus.de> wrote:
> On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote:
> > when I run an OpenVPN interface, OpenVPN manages the interface itself:
> > It handles creation, destruction and assignment of the IP address. The
> > IP address can be controlled by the remote site, so the OpenVPN daemon
> > is kind of the only thing that can configured the Interface.
> > 
> > I would, however, like systemd-resolved to ask DNS servers that are
> > reachable over the VPN for certain domains, such as ka51.zugschlus.de.
> > 
> > Dumping a tun0.network containing:
> > [Match]
> > Name=tun0
> > 
> > [Network]
> > Domains=~ka51.zugschlus.de
> > DNS=2a01:238:4071:3281::35:100
> > DNS=2a01:238:4071:328e::35:100
> > DHCP=no
> > IPv6AcceptRA=no
> > 
> > into /e/s/n doesn't work since that clears up the IP addresses that
> > OpenVPN has correctly assigned.
> 
> No hints? Is this behavior - maybe - a bug?
> 
> Did you tried with KeepConfiguration=?

That is not yet in the Man Page on my system. Is it alreay there in
systemd 242?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?

2019-09-22 Thread Marc Haber
Hi,

On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote:
> when I run an OpenVPN interface, OpenVPN manages the interface itself:
> It handles creation, destruction and assignment of the IP address. The
> IP address can be controlled by the remote site, so the OpenVPN daemon
> is kind of the only thing that can configured the Interface.
> 
> I would, however, like systemd-resolved to ask DNS servers that are
> reachable over the VPN for certain domains, such as ka51.zugschlus.de.
> 
> Dumping a tun0.network containing:
> [Match]
> Name=tun0
> 
> [Network]
> Domains=~ka51.zugschlus.de
> DNS=2a01:238:4071:3281::35:100
> DNS=2a01:238:4071:328e::35:100
> DHCP=no
> IPv6AcceptRA=no
> 
> into /e/s/n doesn't work since that clears up the IP addresses that
> OpenVPN has correctly assigned.

No hints? Is this behavior - maybe - a bug?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?

2019-09-16 Thread Marc Haber
Hi,

when I run an OpenVPN interface, OpenVPN manages the interface itself:
It handles creation, destruction and assignment of the IP address. The
IP address can be controlled by the remote site, so the OpenVPN daemon
is kind of the only thing that can configured the Interface.

I would, however, like systemd-resolved to ask DNS servers that are
reachable over the VPN for certain domains, such as ka51.zugschlus.de.

Dumping a tun0.network containing:
[Match]
Name=tun0

[Network]
Domains=~ka51.zugschlus.de
DNS=2a01:238:4071:3281::35:100
DNS=2a01:238:4071:328e::35:100
DHCP=no
IPv6AcceptRA=no

into /e/s/n doesn't work since that clears up the IP addresses that
OpenVPN has correctly assigned.

Can I have the advantages of systemd-resolved on an Interface that is
not fully managed by systemd-networkd?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?

2019-04-02 Thread Marc Haber
On Tue, Apr 02, 2019 at 12:32:58PM +0200, Lennart Poettering wrote:
> I thought people have noticed by now that systemd is really about
> removing unnecessary shell scripts from all clean system boot
> codepaths.

The problem is that millions of professional systems administrators do
violently disagree.

I have seen unit files full of bash -c and quoting hell. Your work. Be
proud of it.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?

2019-04-02 Thread Marc Haber
On Tue, Apr 02, 2019 at 10:17:26AM +0200, Lennart Poettering wrote:
> Well packaged NTP servers should have a separate .service unit that
> waits until an NTP sync is reached. For example, systemd's own
> systemd-timesyncd.service comes with a companion
> systemd-time-wait-sync.service that does this.

systemd-time-wait-sync.service invokes
/lib/systemd/systemd-time-wait-sync do to the actual wait, which is an
ELF binary. While this is a valid approach to do this, an interested
used will now need to download the systemd souces, unpack them, search
for the source for the binary just to find out what this service
actually does.

To adapt it to wait for something else, one needs to whack out a
compiler.

IMO, this is a classic case of "doing this scripted is way easier and
more flexible". Please consider for the future.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

2017-03-10 Thread Marc Haber
Hi,

On Mon, Feb 20, 2017 at 05:42:19PM +0100, Lennart Poettering wrote:
> On Mon, 20.02.17 17:38, Lennart Poettering (lenn...@poettering.net) wrote:
> > Consider naming the file 50-lanc0.link or so, so that it takes
> > precedence over 99-default.link if that's shipped by your distro. If
> > it isn't, please contact your downstream distro for help (see above).
> 
> BTW, all of the above is documented in systemd.link(5). My
> recommendation is always to check the documentation first.

Just to put and end to this, with proper numbering things are just
fine now. Having this part ot systemd working in lexical order was
just a surprise, I didn't expect that.

Btw, the word "link" is multiply used in IT, so one can expect people
to think of the wrong meaning of the word if one uses it without more
explanation.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

2017-02-19 Thread Marc Haber
On Mon, Feb 06, 2017 at 09:56:30PM +0100, Lennart Poettering wrote:
> On Sat, 21.01.17 21:20, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote:
> > > I've learned about the kernel parameter and symlink ways to disable
> > > predictable network interface names.
> > 
> > What would be the "symlink way"?
> 
> Linking the relevant .link file to /dev/null in /etc.

What if there is no .link file and the Interfaces just come up as
enp8s0 and wlp2s0

> However, if you pick your own names outside of the kernel's
> namespaces, then all is good, and that's actually what we
> recommend. (Though I'd do it by dropping in some .link files with the
> right [Match] sections to make this happen, not bother with udev
> rules, but either works)

[2/5147]mh@swivel:~ $ cat /etc/systemd/network/lanc0.link
[Match]
MACAddress=f0:de:f1:b0:03:20

[Link]
Name=lanc0
[3/5148]mh@swivel:~ $ ip --oneline link show | grep f0:de:f1:b0:03:20
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state 
DOWN mode DEFAULT group default qlen 1000\link/ether f0:de:f1:b0:03:20 brd 
ff:ff:ff:ff:ff:ff
[4/5149]mh@swivel:~ $

My ethernet is still enp0s25, what am I doing wrong?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

2017-02-06 Thread Marc Haber
On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote:
> I've learned about the kernel parameter and symlink ways to disable
> predictable network interface names.

What would be the "symlink way"?

Will predictable network names still play nice with the old udev way?
I cannot make my brain remember that my notebook has enp0s25 and
wlp3s0, and would like to have eth0 and wlan0 again (or net0 and net1,
or wired0 and wless0, if it is a bad idea to move the interfaces back
to the kernel namespaces), while keeping the advantage of having
predictable network names for USB network interfaces that I regularly
plug in as well.

Will placing a /etc/udev/rules.d/70-persistent-network.rules
that renames enp0s25 to wired0 and wlp3s0 to wless0 play nice, it is
that asking for trouble?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-10 Thread Marc Haber
On Sun, Nov 06, 2016 at 09:28:59AM +0300, Andrei Borzenkov wrote:
> 1. The behavior that if filesystem from /etc/fstab fails to mount, boot
> is stopped and administrator intervention is required existed long
> before systemd.

I have never seen this.

> 2. Password is requested not by systemd, but by command that it starts
> to present shell. Default is sulogin. You are free to override it with
> anything you want, including /bin/sh. Again, sulogin was often default
> in this case before systemd as well.

Yes, that right. Before the systemd era, systems usually continued to
boot in case (1) until they hit something hard and unmoving. systemd
systems stop voluntarily.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-10-31 Thread Marc Haber
On Sun, Sep 25, 2016 at 08:09:20PM -0400, Dave Reisner wrote:
> Making bootup potentially interactive in this manner is strictly worse
> than dumping you into emergency mode. At least with emergency mode, you
> might be able to add dependencies to emergency.target such that, for
> example, an sshd comes up and an admin can login to the remote box.

Is there an example around for doing so? This looks way interesting.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-10-31 Thread Marc Haber
On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> The emergency mode assumes console access, which requires physical access,
> which is quiet difficult if the machine is remote.

It does also assume knowledge of the root password, which is in
enterprise environments not often the case. Enterprises usually have
root passwords stowed away in a safe, behind a three-headed guard dog,
requiring management approval, and > 2 eyes mechanisms, and usually
have password-changing processes attached that touch other machines
sharign the same root password as well (for example because the root
password hash is stamped into the golden image).

Many enterprise environments that I know have their processes geared
in a way that the root password is not needed in daily operation.
Login via ssh key, privilege escalation via sudo.

systemd requiring the root password because some tertiary file system
doesn't mount is a nuisance for those environments.

Some sites have resorted to adding "nofail" to all fstab lines just to
find themselves with the next issue since the initramfs of some
distributions doesn't know this option yet. 

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-21 Thread Marc Haber
On Mon, Dec 21, 2015 at 11:14:43PM +0100, Kai Krakow wrote:
> I cannot see anything here in the thread which would disallow continue
> using non-systemd installations.

The problem is that many concepts of systemd are really nice. Once
wants to have things like that.

The problem is that a minoriy of concepts and the attitude of the
makers make working with systemd a constant source of increased blood
pressure and a strong urge to break something expensive just to get
rid of the aggression.


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-21 Thread Marc Haber
On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> Thus: Please maintainers and developers, remove it. Do not let Lennart
> remove this useful option to force others into removing your shitty
> cruft.

This is exactly why systemd is the top one most hated piece of open
source software. We are not here to be educated about the one and only
right way of doing things.

Unix used to be about choice.

Too bad that we allowed this to be no longer the case. Linux is no
longer about choice. Linux nowadays is about what the systemd people
want.

Too bad that we gave the systemd people the power of forcing us to run
our systems their way.

Man kann manchmal echt nicht genug essen wie man in dieser Welt kotzen
möchte.

Merry Christmas.

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-20 Thread Marc Haber
On Sun, Dec 20, 2015 at 02:34:15PM +0100, Tomasz Torcz wrote:
> On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote:
> > On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> > > and then tell admin to use systemctl edit
> > > [Unit]
> > > Environment=OPTS=-baz
> > 
> > How would I do the equivalent of systemctl edit with a declarative
> > configuration management tool like puppet?
> 
>   You have to make sure directory /etc/systemd/system/nfs-ganesha.service.d/
> exists, then inside you create something.conf file with above content.

Is that the documented interface equivalent to systemctl edit? Does
the stability promise apply?

>   Afterwards you need to issue "systemctl daemon-reload" (or send signal
> to PID1) to have the changes read.

That's a regression over the old-fashioned way, but doable.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-20 Thread Marc Haber
On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> and then tell admin to use systemctl edit
> [Unit]
> Environment=OPTS=-baz

How would I do the equivalent of systemctl edit with a declarative
configuration management tool like puppet?

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Policy Routing on a machine using systemd-networkd

2015-12-20 Thread Marc Haber
*nudge*

Is there really no option about this rather common issue?

Greetings
Marc


On Tue, Dec 15, 2015 at 01:20:34PM +0100, Marc Haber wrote:
> I would like to do policy routing on a router with ~ 10 interfaces
> running Debian Linux and systemd. Networking is managed with ferm and
> systemd-networkd.
> 
> I now need Policy Routing. What is the recommended way to handle the
> usual knot of iptables, ip rule and ip route statement in a clear and
> beautiful way in a systemd environment?
> 
> As far as I know, systemd-network has not yet implemented policy
> routing, so the canonical way (for me, as a systemd newbie) to
> implement this would be a sysv init script containing the needed
> commands.
> 
> What would be the "correct" way to do this in a systemd setup?
> 
> Actually, I need something that does the following:
> 
> o prevent a default route from being present in the main table (either
>   by preventing it from being set in the first place or removing it
>   idempotently)
> o Establish a number of iptables rules to set fwmarks
> o Establish a number of extra routing tables with a set of rules
> o Establish a number of ip rule rules regarding source IP ranges or
>   fwmarks.
> 
> How would I do that in systemd? Am I doing ok with a Type=oneshot
> service unit with a bunch of ExecStart Options? Or is there another
> recommended way?

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-20 Thread Marc Haber
On Tue, Dec 15, 2015 at 05:59:11PM +, Simon Peeters wrote:
> Why not do like normal people and use configmanagement to put the
> right apache config on the right host?
> This whole "-D testserver" and ""  looks like an
> ugly workaround for a lacking configmanagment system.

And what is your business in deliberately breaking those ugly setups?
If you want to educate people, be a teacher. If you want to bully
people into doing things your way, be a team leader.

Greetings
Marc

-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-20 Thread Marc Haber
On Fri, Dec 11, 2015 at 03:59:54PM +0100, Reindl Harald wrote:
> EnvironmentFile is a great way to make units flexible with sane
> defaults and i am *not* talking about upstream or distributions here
> 
> so taking away that option gains you nothing but breaks things for
> no valid reason - it would only confirm people which hesitate to
> adopt systemd because the fear that they can't rely on capabilities
> it brings now because they may flippantly disappear

Amen.

Greetings
Marc


-- 
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Policy Routing on a machine using systemd-networkd

2015-12-15 Thread Marc Haber
Hi,

I would like to do policy routing on a router with ~ 10 interfaces
running Debian Linux and systemd. Networking is managed with ferm and
systemd-networkd.

I now need Policy Routing. What is the recommended way to handle the
usual knot of iptables, ip rule and ip route statement in a clear and
beautiful way in a systemd environment?

As far as I know, systemd-network has not yet implemented policy
routing, so the canonical way (for me, as a systemd newbie) to
implement this would be a sysv init script containing the needed
commands.

What would be the "correct" way to do this in a systemd setup?

Actually, I need something that does the following:

o prevent a default route from being present in the main table (either
  by preventing it from being set in the first place or removing it
  idempotently)
o Establish a number of iptables rules to set fwmarks
o Establish a number of extra routing tables with a set of rules
o Establish a number of ip rule rules regarding source IP ranges or
  fwmarks.

How would I do that in systemd? Am I doing ok with a Type=oneshot
service unit with a bunch of ExecStart Options? Or is there another
recommended way?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-22 Thread Marc Haber
On Tue, Jul 21, 2015 at 09:42:38PM +0200, Michael Biebl wrote:
 Have a look at the openvpn package in Debian. It implements something
 like you have in mind.
 There are multiple openvpn@.service instances and a single
 openvpn.service which can be used by the admin to start/stop/restart
 them.

That uses a generator, which is somewhat oversized for the question at
hand. And it's a service with ExecStart=/bin/true which is a hackish
workaround.  But if that's the way to go, I'm fine with it.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-21 Thread Marc Haber
On Tue, Jul 21, 2015 at 02:20:39PM +0100, Dimitri John Ledkov wrote:
 And then people can do e.g.:
 systemctl enable nifty@4.service nifty@6.service
 systemctl start nifty@*.service
 systemctl stop nifty@*.service

As I mentioned in my original mail, this is explictly not wanted, as
most users will have to start and stop both instances together.

We cannot make our lives simpler at the cost of our users. And yes,
this is true for both systemd upstream and software packagers, a
transitive relationship.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How to properly write an umbrella unit

2015-07-21 Thread Marc Haber
Hi,

I am trying to systemd'ize a daemon which is useful to be run in two
instances. It is usually the case that both instances need to be
started and stopped simultaneously, and the local admin would want a
_single_ command to start and stop both instances. Therefore, an
umbrella is needed.

As a beginner, I have written:

nifty.target:
[Unit]
Description=nifty Server (all protocols)
After=network.target

[Install]
WantedBy=multi-user.target


nifty-v4.service:
[Unit]
Description=nifty Server for IPv4 (niftyd4.conf)
After=network.target
PartOf=nifty.target

[Service]
ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf

[Install]
WantedBy=nifty.target



nifty-v6.service:
[Unit]
Description=nifty Server for IPv6
After=network.target
PartOf=nifty.target

[Service]
ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf

[Install]
WantedBy=nifty.target


This works as designed. Unfortunately, my Distribution's build tools
don't handle package-provided targets too well, and I feel that using
a target here is kind of wrong anyway.

Can I write my nifty.target as a service? I have seen in this case
nifty.service files with Exec=/bin/true to basically create a no-op
service, but that's ugly.

If I move my service to a nifty@.service, how would I start two
instances from a single shell command?

How would one handle this situation in the clear, recommended way?

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-21 Thread Marc Haber
On Tue, Jul 21, 2015 at 01:40:31PM +0100, Colin Guthrie wrote:
 In this case, I'd perhaps recommend NOT including [Install] sections fir
 your two .service files and instead make your make install action
 write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus
 the user could never disable the individual components of your daemon
 themselves and thus not need to rely on distro scripts to create them at
 install time.

No, I'd like to give the local admin an option to disable parts of
course. My work is about choice and robustness.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-21 Thread Marc Haber
Hi Alexandre,

thanks for your fast answer and correctly guessing my Distribution ,-)

On Tue, Jul 21, 2015 at 02:13:12PM +0200, Alexandre Detiste wrote:
 Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit :
  This works as designed. Unfortunately, my Distribution's build tools
  don't handle package-provided targets too well, and I feel that using
  a target here is kind of wrong anyway.
 
 Hi,
 
 Package-provided targets works well,
 but by default debhelper will try to enable everything.

In my case, dh_systemd_enable doesn't install the file:
dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target
echo # Automatically added by dh_systemd_enable 
debian/isc-dhcp-server.postinst.debhelper
sed s/#UNITFILE#/isc-dhcp-server-v6.service/ 
/usr/share/debhelper/autoscripts/postinst-systemd-enable  
debian/isc-dhcp-server.postinst.debhelper
echo '# End automatically added section'  
debian/isc-dhcp-server.postinst.debhelper
echo # Automatically added by dh_systemd_enable 
debian/isc-dhcp-server.postinst.debhelper
sed s/#UNITFILE#/isc-dhcp-server-v4.service/ 
/usr/share/debhelper/autoscripts/postinst-systemd-enable  
debian/isc-dhcp-server.postinst.debhelper
echo '# End automatically added section'  
debian/isc-dhcp-server.postinst.debhelper
echo # Automatically added by dh_systemd_enable 
debian/isc-dhcp-server.postinst.debhelper
sed s/#UNITFILE#/isc-dhcp-server-v4-old.service/ 
/usr/share/debhelper/autoscripts/postinst-systemd-enable  
debian/isc-dhcp-server.postinst.debhelper
echo '# End automatically added section'  
debian/isc-dhcp-server.postinst.debhelper
echo # Automatically added by dh_systemd_enable 
debian/isc-dhcp-server.postrm.debhelper.new
sed s/#UNITFILES#/isc-dhcp-server-v6.service 
isc-dhcp-server-v4.service isc-dhcp-server-v4-old.service/ 
/usr/share/debhelper/autoscripts/postrm-systemd  
debian/isc-dhcp-server.postrm.debhelper.new
echo '# End automatically added section'  
debian/isc-dhcp-server.postrm.debhelper.new
cat debian/isc-dhcp-server.postrm.debhelper  
debian/isc-dhcp-server.postrm.debhelper.new
mv debian/isc-dhcp-server.postrm.debhelper.new 
debian/isc-dhcp-server.postrm.debhelper
(grep -s -v misc:Depends debian/isc-dhcp-server.substvars; echo 
misc:Depends=debconf (= 0.5) | debconf-2.0, init-system-helpers (= 1.18~)) 
 debian/isc-dhcp-server.substvars.new
mv debian/isc-dhcp-server.substvars.new debian/isc-dhcp-server.substvars
dh_installinit -Nisc-dhcp-server
install -d debian/isc-dhcp-relay/etc/init.d
install -p -m755 debian/isc-dhcp-relay.init.d 
debian/isc-dhcp-relay/etc/init.d/isc-dhcp-relay
echo # Automatically added by dh_installinit 
debian/isc-dhcp-relay.postinst.debhelper
sed 
s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit 
\$?/ /usr/share/debhelper/autoscripts/postinst-init  
debian/isc-dhcp-relay.postinst.debhelper
echo '# End automatically added section'  
debian/isc-dhcp-relay.postinst.debhelper
echo # Automatically added by dh_installinit 
debian/isc-dhcp-relay.prerm.debhelper
sed 
s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit 
\$?/ /usr/share/debhelper/autoscripts/prerm-init  
debian/isc-dhcp-relay.prerm.debhelper
echo '# End automatically added section'  
debian/isc-dhcp-relay.prerm.debhelper
echo # Automatically added by dh_installinit 
debian/isc-dhcp-relay.postrm.debhelper.new
sed 
s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit 
\$?/ /usr/share/debhelper/autoscripts/postrm-init  
debian/isc-dhcp-relay.postrm.debhelper.new
echo '# End automatically added section'  
debian/isc-dhcp-relay.postrm.debhelper.new
cat debian/isc-dhcp-relay.postrm.debhelper  
debian/isc-dhcp-relay.postrm.debhelper.new
mv debian/isc-dhcp-relay.postrm.debhelper.new 
debian/isc-dhcp-relay.postrm.debhelper
dh_installinit -pisc-dhcp-server --error-handler=true
#dh_systemd_start isc-dhcp-server.target

and dh_systemd_enable's code specialcasing service, socket, and
tmpfile, but not target, gave me the impression that target files are
unsupported.

My debian/rules is:
override_dh_installinit:
dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4
dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4-old
dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v6
dh_systemd_enable --verbose -pisc-dhcp-server 
--name=isc-dhcp-server.target
dh_installinit -Nisc-dhcp-server
dh_installinit -pisc-dhcp-server --error-handler=true

what is wrong here?

(if this is off-topic in systemd-devel, which I suspect, please feel
free to reply in private mail instead).

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

2015-07-18 Thread Marc Haber
On Tue, Jun 09, 2015 at 01:02:43PM +0200, Lennart Poettering wrote:
 On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote:
 
  2015-06-01 20:12 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
   Hi
  
   As of today we've disabled git-push to fd.o. The official development
   git repository is now at github [1].
  
  What about the bug tracker? Will it remain at fdo's bugzilla. I have
  to admit I'm not a huge fan of github's bug tracker.
 
 I am not a fan of bz either...
 
 I think for now we prefer github, but will leave bz open, and we will
 not migrate bugs.

As it looks at the moment, freedesktop.org doesnt want new bugs to be
filed in their Bugzilla. At least it is no longer possible to open new
bugzilla requests for systemd there.

Would you prefer bugzilla requests to be moved over to github issues
by people interested in those requests/issues being addressed, or do
old bugzilla requests have the same chance of being looked at by
somebody able to address them as github issues?

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd and openvswitch?

2015-05-28 Thread Marc Haber
Hi Richard,

thanks for your insights. In the mean time, I was successful in
bridging an VLAN trunk to a VM with the native linux bridge, and thus
do not need Openvswich in my project any more.

Your mail will be helpful to others in the future.

ftr, one needs to define the VLANs on the hosts as well, and the VLAN
definition needs to be on the _bridge_, not the ethernet. I guess that
the Linux bridge code uses the VLANs defined on the bridge as kind of
VLAN filter for the poor.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-networkd and openvswitch?

2015-05-16 Thread Marc Haber
Hi,

is there any possibility to nicely integrate openvswitch to a system
that runs systemd-networkd? While I understand that there does not
currrently seem to be native openvswitch support in systemd-networkd,
maybe somebody has written unit files to bring up the openvswitch
before systemd-networkd kicks in?

The reason I am trying to do this is that openvswitch is advertised as
being capable to switch an entire dot1q VLAN trunk through to a VM,
something that a standard Linux bridge doesn't seem to do.

Any comments about this?

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-15 Thread Marc Haber
On Thu, Aug 14, 2014 at 08:18:10PM +0200, Lennart Poettering wrote:
 On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
   Not aware of an C++ code. There's a vala one, and of course the one we
   ship in systemd itself in C, but c++ i cannot help you with, sorry.
  
  Is it possible to write a PasswordAgent in shell? Example code please
  ;)
 
 Probably possible, after all bash allows you to talk to unix sockets and
 stuff. And you could probably put the protocol together with carefully
 crafted echo lines, but I know of nobody who has done that so far...

There is also the daemonizing and inotify part...

   I fear I don#t have an easy suggestion. What kind of device do you
   actually want to make work here? some smartcard or so?
  
  That's the vision, yes. At the moment, my keyscript unlocks a small
  LUKS partition on the disk and takes the key for the root fs from
  there. That's just a placeholder for a future more complicated setup.
 
 Not following. You place a key for a LUKS partition on another LUKS
 partition? What's the benefit of that? Inception? ;-)

It's actually part of a two-factor-authentification for the poor. The
part to know is the key to the LUKS parition, the part to have is an
USB key.

The key script hashes part of the key found on the USB key and part of
the key found on the LUKS partition on the hard disk together to build
the actual key to unlock the root fs. I use this scheme for so long
that I don't even remember why I implemented it this way, but I guess
it was because the logic to unlock a LUKS fs from initramfs was
already in place and could be used as-is to unlock the
key-part-holding LUKS partition instead of the actual root fs that it
was intended for.

But I also know of people who use a keyscript to unlock LUKS file
systems with the key stored in the system's TPM or on a crypto card. I
have never looked into the details of those implementations (having
that saved for a long winter night), but I guess that those people
will also be pretty hosed on a systemd-based Debian.

  First step to do that would be to implement support for the keyscript=
  option in /etc/crypttab as this is the canonical place to hook into on
  non-system systems. At least it's the case on Debian, I don't know
  about Red Hat, Fedora and other distributions.
 
 Well, I am really not convinced that this is a well-defined
 interface. Even in your case you have to wait for two devices at least,
 right? a synchronous shell callout won't solve that for you since
 there's no guarantee that the second LUKS device has already shown up,
 or am I missing something?

It may be possible that /etc/crypttab is processed sequentially which
would obviously not be the case with systemd. So you have a point here.

 As mentioned we really should redesign the whole thing around the kernel
 keyring anyway, I am really conservative in adding support for Debian's
 keyscript thingy upstream now. (That of course shouldn't stop Debian
 from adding this downstream)

It didn't occur to me that /etc/crypttab's keyscript= option was a
Debianism. I educated myself in the mean time. I'm going to yell at
the Debian systemd team now ;-)

  The PasswordAgent stuff is really neat, but complicated due to the
  socket communication, and it's far from being a drop-in replacement.
 
 Well, it's really easy in C I figure, but admittedly not in shell...

It would be significantly easier if there were boilerplate code to
derive from. To a non-adept programmer, adapting the boilerplate would
probably lead to enough buffer overflow vulnerabilities anyway ;-)

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-15 Thread Marc Haber
On Fri, Aug 15, 2014 at 01:30:32PM +0200, Lennart Poettering wrote:
 On Fri, 15.08.14 12:56, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
Is it possible to write a PasswordAgent in shell? Example code please
;)
   
   Probably possible, after all bash allows you to talk to unix sockets and
   stuff. And you could probably put the protocol together with carefully
   crafted echo lines, but I know of nobody who has done that so far...
  
  There is also the daemonizing and inotify part...
  
 I fear I don#t have an easy suggestion. What kind of device do you
 actually want to make work here? some smartcard or so?

That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.
   
   Not following. You place a key for a LUKS partition on another LUKS
   partition? What's the benefit of that? Inception? ;-)
  
  It's actually part of a two-factor-authentification for the poor. The
  part to know is the key to the LUKS parition, the part to have is an
  USB key.
 
 The part to have is trivially easy to copy, so why do the excercise
 at all? Sounds more like theatre to me...

Because I still hope to have that in a more secure way in the near
future.

  But I also know of people who use a keyscript to unlock LUKS file
  systems with the key stored in the system's TPM or on a crypto card. I
  have never looked into the details of those implementations (having
  that saved for a long winter night), but I guess that those people
  will also be pretty hosed on a systemd-based Debian.
 
 I think supporting TPM or smartcards out of the box is very desirable to
 have upstream.

Yes, and that should be done in a modular way so that even exotic (or
broken) schemes can be plugged in.

  I am not convinced though that Debian's keyscript= logic is really
  that well designed that I want to update it upstream.

You don't need to. I falsely thought that this was general
functionality and not a Debianism.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-14 Thread Marc Haber
On Wed, Aug 13, 2014 at 06:42:13PM +0200, Lennart Poettering wrote:
 On Wed, 13.08.14 16:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
  did I reach the wrong mailing list? Is there better forum to get
  systemd working with something resembling my current setup?
 
 No, this is the right place. But I just have a huge backlog of threads
 to reply to on the ML. I am slowly working on catching up now, in
 preparation for a new release.

Ok, I'll sit back quietly ;-)  Maybe somebody else cares to comment?

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-14 Thread Marc Haber
Hi Lennart,

thanks for your thoughts.

On Thu, Aug 14, 2014 at 07:44:59PM +0200, Lennart Poettering wrote:
 On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
  (4)
  My PasswordAgent indicates taking responsibility by unlinking the
  ask.xxx file from /run/systemd/ask-password. The interactive password
 
 Well, so far it is the querier that removes the file, not the agent...

I see. What would happen if I remove the file myself?

  To use this to unlock the root fs, an entire python installation would
  need to go in my initramfs, right? And if I want to keep things
  simple, the best idea would be to write my PasswordAgent in a compiled
  language which would only need the binary and its libs in the
  initramfs, right?
 
 Yes. Correct. If you want to stick something into the initrd, I'd always
 do things in C (or shell if you must), but nothing else.
 
  Is there code for an example PasswordAgent in C++ which I can use as a
  template? I am quite reluctant to write a program which needs to to
  complex string processing and is bound to run as root in C because my
  C experience is somewhat lacking.
 
 Not aware of an C++ code. There's a vala one, and of course the one we
 ship in systemd itself in C, but c++ i cannot help you with, sorry.

Is it possible to write a PasswordAgent in shell? Example code please ;)

  Can you please recommend a way to allow me to migrate to systemd?
  Without keyscript= being supported in /etc/crypttab, I need to replace
  my 50 line key script written in POSIX shell and would like to keep
  things simple.
  
  Thank you very much for your consideration.
 
 I fear I don#t have an easy suggestion. What kind of device do you
 actually want to make work here? some smartcard or so?

That's the vision, yes. At the moment, my keyscript unlocks a small
LUKS partition on the disk and takes the key for the root fs from
there. That's just a placeholder for a future more complicated setup.

With Debian's initramfs, unlocking the small LUKS partition works
transparently even with plymouth. This is real functionality being
lost in the systemd migration.

 I think in the long run we should somehow work towards the direction to
 make things like that just work, for common devices like smartcards and
 other auth tokens...

First step to do that would be to implement support for the keyscript=
option in /etc/crypttab as this is the canonical place to hook into on
non-system systems. At least it's the case on Debian, I don't know
about Red Hat, Fedora and other distributions.

The PasswordAgent stuff is really neat, but complicated due to the
socket communication, and it's far from being a drop-in replacement.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-14 Thread Marc Haber
Hi,

On Thu, Aug 14, 2014 at 08:09:05PM +0200, David Herrmann wrote:
 That is, to solve your problem, I'd recommend to make systemd allow
 external scripts like keyscript= before placing *.ask files (or some
 other hookup or configuration, if scripts are not suitable for that).

If systemd would support keyscript=, migration would be painless. I am
absolutely in favor of that ;-)

Greetings
Marc, unfortunately too bad a C programmer to write a patch

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-08-13 Thread Marc Haber
Hi,

did I reach the wrong mailing list? Is there better forum to get
systemd working with something resembling my current setup?

Greetings
Marc


On Mon, Jul 21, 2014 at 10:46:21AM +0200, Marc Haber wrote:
 From: Marc Haber mh+systemd-de...@zugschlus.de
 Subject: Thoughts about /etc/crypttab keyscript options
 To: systemd-devel@lists.freedesktop.org
 Date: Mon, 21 Jul 2014 10:46:21 +0200
 User-Agent: Mutt/1.5.21 (2010-09-15)
 
 Hi,
 
 I was recently bitten by the issue that systemd does not support the
 keyscript= option in /etc/crypttab. I don't know whether keyscript= is
 a Debian extension, but the migration to systemd (which was pulled in
 by some new version of - I think - Network Manager) broke my system's
 boot process, leaving me with all my filesystems locked since already
 the root fs used to be unlocked by a keyscript.
 
 I have read the thread (from 2012?) where those things were discussed
 here and I understand that I should replace my keyscript with a
 passwort agent. Things would then work like this:
 
 (1)
 systemd would try to unlock the root file system and place a ask.xxx
 file in /run/systemd/ask-password
 
 (2)
 All running PasswordAgents (including my, non-interactive one and
 all interactive ones) would act on that ask.xxx file.
 
 (3)
 The interactive password agents would present an interactive password
 request.
 
 (4)
 My PasswordAgent indicates taking responsibility by unlinking the
 ask.xxx file from /run/systemd/ask-password. The interactive password
 agents will remove their interactive requests then. The user will
 therefore see the password request popping up for a very short period
 of time, if at all.
 
 (5)
 Should my PasswordAgent need a password to act itself (like a PIN for
 a hardware device, for example), it would place its own ask.xxx file
 in /run/systemd/ask-password. The interactive PasswordAgents would
 act on that, obtain the password/PIN interactively from the user and
 return it to my PasswordAgent.
 
 (6)
 My PasswordAgent would then obtain the password for the file system
 itself and return it to systemd which can now proceed to unlock the
 file system.
 
 
 Am I understanding things correctly so far?
 
 
 If so, this leaves the task to write my PasswordAgent. I have found
 some example code in python for a password agent.
 
 To use this to unlock the root fs, an entire python installation would
 need to go in my initramfs, right? And if I want to keep things
 simple, the best idea would be to write my PasswordAgent in a compiled
 language which would only need the binary and its libs in the
 initramfs, right?
 
 Is there code for an example PasswordAgent in C++ which I can use as a
 template? I am quite reluctant to write a program which needs to to
 complex string processing and is bound to run as root in C because my
 C experience is somewhat lacking.
 
 Can you please recommend a way to allow me to migrate to systemd?
 Without keyscript= being supported in /etc/crypttab, I need to replace
 my 50 line key script written in POSIX shell and would like to keep
 things simple.
 
 Thank you very much for your consideration.
 
 Greetings
 Marc
 
 -- 
 -
 Marc Haber | I don't trust Computers. They | Mailadresse im Header
 Leimen, Germany|  lose things.Winona Ryder | Fon: *49 621 31958061
 Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600420
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Thoughts about /etc/crypttab keyscript options

2014-07-21 Thread Marc Haber
Hi,

I was recently bitten by the issue that systemd does not support the
keyscript= option in /etc/crypttab. I don't know whether keyscript= is
a Debian extension, but the migration to systemd (which was pulled in
by some new version of - I think - Network Manager) broke my system's
boot process, leaving me with all my filesystems locked since already
the root fs used to be unlocked by a keyscript.

I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
passwort agent. Things would then work like this:

(1)
systemd would try to unlock the root file system and place a ask.xxx
file in /run/systemd/ask-password

(2)
All running PasswordAgents (including my, non-interactive one and
all interactive ones) would act on that ask.xxx file.

(3)
The interactive password agents would present an interactive password
request.

(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
agents will remove their interactive requests then. The user will
therefore see the password request popping up for a very short period
of time, if at all.

(5)
Should my PasswordAgent need a password to act itself (like a PIN for
a hardware device, for example), it would place its own ask.xxx file
in /run/systemd/ask-password. The interactive PasswordAgents would
act on that, obtain the password/PIN interactively from the user and
return it to my PasswordAgent.

(6)
My PasswordAgent would then obtain the password for the file system
itself and return it to systemd which can now proceed to unlock the
file system.


Am I understanding things correctly so far?


If so, this leaves the task to write my PasswordAgent. I have found
some example code in python for a password agent.

To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?

Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.

Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.

Thank you very much for your consideration.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel