Re: [systemd-devel] sibling DNS lookup of nspawn containers

[Johannes Ernst]

> On Jun 18, 2021, at 16:02, Silvio Knizek  wrote:
> 
> Am Freitag, dem 18.06.2021 um 14:52 -0700 schrieb Johannes Ernst:
>> 
>> Thanks, Silvio, but no luck:
>> 
>> I have host, container a and container b.
>> 
>> In both containers, .network for host0 has LLMNR=yes in the [Network]
>> section
>> 
>> The host has LLMNR=yes in the [Resolve] section of
>> /etc/systemd/resolved.conf
>> 
>> On the host: “resolvectl query a” and “…b” works.
>> 
>> In the containers “resolvectl query a” works only in container a, not
>> in b, and vice versa. So no sibling lookup.
>> 
>> iptables and ip6tables show default rules for all three.
>> 
>> What am I missing?
>> 
>> Thanks,
>> 
>> Johannes.
>> 
> 
> Are both machines in the same network zone or attached to the same
> bridge interface on the host machine? Else the default NAT rules won't
> allow for multicast traffic as it is done by LLMNR.
> sd-nspawn uses nftables, not iptables. You should see some rules with
> »nft list table ip io.systemd.nat«.
> So add »--network-zone=some-fancy-name« to your systemd-nspawn
> commands.

Almost! With —network-zone=foo, I get sibling IPv6 addresses, but I don’t get 
sibling IPv4 addresses.
iptables are empty, nftables seem to have nothing IP-version specific in them.

I know basically nothing about LLMNR. This is supposed to apply to both v4 and 
v6, right? 

On the other hand, I may not need IPv4 for my use case.

Thanks,



Johannes.

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

Re: [systemd-devel] sibling DNS lookup of nspawn containers

[Johannes Ernst]

> On Jun 18, 2021, at 2:02, Silvio Knizek  wrote:
> 
> Am Donnerstag, dem 17.06.2021 um 20:26 -0700 schrieb Johannes Ernst:
>> I’d like to be able to DNS lookup container b from within container a, if 
>> both were started with systemd-nspawn as siblings of each other, and shown 
>> as a and b in machinectl list.
>> 
>> man nss-mymachines specifically notes it won’t do that.
>> 
>> What’s the proper way of doing this?
>> 
>> Thanks,
> Hi Johannes,
> 
> you would enable LinkLocalMulticastNameResolution (LLMNR) in the
> containers systemd-networkd.
> See man:networkd.conf for further information.


Thanks, Silvio, but no luck:

I have host, container a and container b.

In both containers, .network for host0 has LLMNR=yes in the [Network] section

The host has LLMNR=yes in the [Resolve] section of /etc/systemd/resolved.conf

On the host: “resolvectl query a” and “…b” works.

In the containers “resolvectl query a” works only in container a, not in b, and 
vice versa. So no sibling lookup.

iptables and ip6tables show default rules for all three.

What am I missing?

Thanks,



Johannes.

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

[systemd-devel] sibling DNS lookup of nspawn containers

[Johannes Ernst]

I’d like to be able to DNS lookup container b from within container a, if both 
were started with systemd-nspawn as siblings of each other, and shown as a and 
b in machinectl list.

man nss-mymachines specifically notes it won’t do that.

What’s the proper way of doing this?

Thanks,




Johannes.

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

[systemd-devel] Running systemd unprivileged in Docker container

[Johannes Ernst]

I can run a full Arch system (with systemd as PID 1) in a Docker container in 
Docker privileged mode:
sudo docker run -i -t --privileged archlinux /usr/lib/systemd/systemd
but privileged mode is, well, a bit privileged. I believe used to be able to 
tone this down with something like:

sudo docker run -i -t --cap-add=ALL -v /sys/fs/cgroup:/sys/fs/cgroup:ro 
archlinux /usr/lib/systemd/systemd
or even less capabilities than "all". But now I'm getting:

systemd 248.3-2-arch running in system mode. (+PAM +AUDIT -SELINUX 
-APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL 
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 
-PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP 
-SYSVINIT default-hierarchy=unified)
Detected virtualization docker.
Detected architecture x86-64.
Detected first boot.

Welcome to Arch Linux!

Initializing machine ID from random generator.
Failed to create /init.scope control group: Read-only file system
Failed to allocate manager object: Read-only file system
[!!] Failed to allocate manager object.
Exiting PID 1...
I don't understand what that means. (Somebody likes exclamation marks.) What's 
the "manager object", and who is trying to allocate it?

Assuming that the "Read-only filesystem" in question is that /sys/fs/cgroup, 
when binding it into the container as read-write I get that instead:

Failed to create /init.scope control group: No such file or directory
Failed to allocate manager object: No such file or directory
This long Serverfault thread 

 may be related? Are they saying it's broken? Can it be done?

Posted this earlier  in the Arch 
forum, lots of views, no answers.

Thanks,



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

[systemd-devel] Dynamic .timer scheduling

[Johannes Ernst]

Is there a best practice for scheduling .timers based on what happened in a 
previous run?

Pseudocode:

while( true ) :
delta = runService();
sleep( delta );

I can think of …

1) run the job frequently, but skip the bulk of its execution most of the time 
(e.g. decrementing a counter saved somewhere)
2) have the job modify the .timer file at the end of each run (sounds … not so 
great)

There isn’t anything systemd “native” for that, right?

Thanks,




Johannes.

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

Re: [systemd-devel] host0 virtual link suddenly default down in systemd-nspawn container

[Johannes Ernst]

> On Sep 9, 2019, at 12:16, Ansgar Burchardt  wrote:
> 
> Johannes Ernst writes:
>> I've been running the same systemd-nspawn container for some time, always 
>> with the same options:
>> 
>>  systemd-nspawn -b -n -D dir -M name --bind /home -x
>> 
>> It would always bring up the virtual ethernet link immediately during
>> boot of the container. But since a recent Arch (host) upgrade (I
>> think), the virtual ethernet link host0 now stays "down" during boot
>> of the container:
> 
> Do you use systemd-networkd?  I noticed that systemd-networks no longer
> starts in nspawn containers (the condition for CAP_NET_ADMIN failed), so
> nothing configured the network interface after upgrading to systemd 243
> in Debian experimental.

Yes, I am running systemd-networkd and it is automatically started in the 
container. (So I don’t have the same condition failing.) But there is an error 
in the log which I had overlooked:

-- Reboot --
Sep 09 20:24:00 ubos-x8664-container systemd[1]: Starting Network Service...
Sep 09 20:24:01 ubos-x8664-container systemd-networkd[39]: Enumeration completed
Sep 09 20:24:01 ubos-x8664-container systemd[1]: Started Network Service.
Sep 09 20:24:01 ubos-x8664-container systemd-networkd[39]: host0: Could not 
bring up interface: Invalid argument

Hmmm … I do have interface host0@if18, and I can bring it up with “ip". Why 
would it think it’s an invalid argument?

Same thing happens if I stop and start systemd-networkd manually after the boot.

Cheers,


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

[systemd-devel] host0 virtual link suddenly default down in systemd-nspawn container

[Johannes Ernst]

I've been running the same systemd-nspawn container for some time, always with 
the same options:

systemd-nspawn -b -n -D dir -M name --bind /home -x

It would always bring up the virtual ethernet link immediately during boot of 
the container. But since a recent Arch (host) upgrade (I think), the virtual 
ethernet link host0 now stays "down" during boot of the container:

[container]# ip addr
...
2: host0@if16:  mtu 1500 qdisc noop state DOWN 
group default qlen 1000
link/ether c6:20:a3:f7:c4:3c brd ff:ff:ff:ff:ff:ff link-netnsid 0

I can manually bring it up, and then all is well:

[container]# ip link set host0 up
[container]# ip addr
...
2: host0@if16:  mtu 1500 qdisc noqueue 
state UP group default qlen 1000
link/ether c6:20:a3:f7:c4:3c brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.75.70/28 brd 192.168.75.79 scope global dynamic host0
   valid_lft 3598sec preferred_lft 3598sec
inet6 fe80::c420:a3ff:fef7:c43c/64 scope link 
   valid_lft forever preferred_lft forever

I’m using the default host0.network from 
https://github.com/systemd/systemd/blob/master/network/80-container-host0.network

How do I get it back to default-up? And what may have happened to cause this 
change in behavior, because the container itself did not change.

Thanks,



Johannes.

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

Re: [systemd-devel] "semaphore" for .timer-triggered run

[Johannes Ernst]

> On Aug 2, 2019, at 22:45, Andrei Borzenkov  wrote:
> 
> 02.08.2019 23:24, Johannes Ernst пишет:
>> I have a oneshot .service (certbot) that is run by its .timer with:
>> 
>> OnCalendar=daily
>> RandomizedDelaySec=1day
>> 
>> I also have a sometimes long-running script that may modify the same data. 
>> So the script and the oneshot service should never run at the same time.
>> 
> 
> If script itself runs as oneshot service, then putting After in your
> certbot.service should do it (it should wait for prerequisite service to
> complete).

No, the other script is a command-line tool invoked by the user.

> 
>> Is there a good systemd pattern for some kind of semaphore-like thing that 
>> will delay the execution of the oneshot service and try again when the 
>> script is done running?
>> 
>> I could skip execution, but then I miss an entire day until the service is 
>> run again -- I’d prefer it if it tried again a few minutes later. Or I could 
>> poll for some flag before running the main part of the service. Wondering 
>> whether there something more systemd-native.
>> 
>> Thanks,
>> 
>> 
>> 
>> Johannes.
>> 
>> ___
>> 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

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

[systemd-devel] "semaphore" for .timer-triggered run

[Johannes Ernst]

I have a oneshot .service (certbot) that is run by its .timer with:

OnCalendar=daily
RandomizedDelaySec=1day

I also have a sometimes long-running script that may modify the same data. So 
the script and the oneshot service should never run at the same time.

Is there a good systemd pattern for some kind of semaphore-like thing that will 
delay the execution of the oneshot service and try again when the script is 
done running?

I could skip execution, but then I miss an entire day until the service is run 
again -- I’d prefer it if it tried again a few minutes later. Or I could poll 
for some flag before running the main part of the service. Wondering whether 
there something more systemd-native.

Thanks,



Johannes.

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

Re: [systemd-devel] dependency-only .service

[Johannes Ernst]

> On Oct 15, 2018, at 16:17, Uoti Urpala  wrote:
> 
> On Mon, 2018-10-15 at 15:09 -0700, Johannes Ernst wrote:
>> I have several programs A, B and C that, while they are running, require 
>> memcached.service to be running.
>> When none of A, B, or C is running, I want memcached.service to not run 
>> either.
>> A, B and C should share the same memcached instance.
>> 
>> How do I best express this?
>> 
>> I was thinking I would have a foo@.service, which would be started by A, B 
>> and C as foo@A, foo@B, and foo@C right when they come up, and stopped before 
>> they quit. This foo@.service would have a dependency on memcached.service, 
>> but otherwise not do anything.
> 
> Why this indirection through "foo" instead of direct dependencies? Are
> A, B and C not systemd services, so you require "foo" as a placeholder
> that reflects their dependencies?

Yes, they are something else than a systemd service, in my example simply 
long-running batch programs.

>> 1. There isn’t a Type=Noop, so having an ExecStart=/bin/true might be my 
>> best option?
> 
> I think a service with Type=oneshot and RemainAfterExit=true should
> work with no ExecStart lines.

"Service lacks both ExecStart= and ExecStop= setting. Refusing.”

That presumably could be a .target but having a dummy exec is fine.

>> 2. How do I get memcached.service to stop automatically? A Requires= seems 
>> to keep it running even after all foo@.service have gone away.
> 
> Add StopWhenUnneeded=true to the configuration of the memcached
> service.

Ah. There’s always one more keyword somewhere :-)

Thank you,


Johannes.

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

[systemd-devel] getting dns-sd to work

[Johannes Ernst]

Here is what I do:

mkdir /etc/systemd/dnssd
cat > /etc/systemd/dnssd/http.dnssd

(the exact example file from "man systemd.dnssd”, minus leading white space)

systemctl restart systemd-resolved

Then

avahi-browse -a -r

or

systemd-resolve —-service myhost._http._tcp.local

as per man page should show me my service, right? Except that it does not. 
Everything else on my network is there. There is nothing remarkable in the 
journal, and strace confirms that systemd-resolved actually reads the file.

What am I doing wrong?

This is systemd-238.76 on Arch.

Thanks,



Johannes.

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

[systemd-devel] Run fuse in nspawn container?

[Johannes Ernst]

I’m running with

systemd-nspawn —capability=all

but now I also need /dev/fuse and I’m not permitted to create it.

man systemd-nspawn says that "Device nodes may not be created.” which sounds 
like game over and no Fuse in the container. Is it?

Thanks,



Johannes.

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

[systemd-devel] leftover machines

[Johannes Ernst]

After running a bunch of systemd-nspawn containers, I am left with a few that 
seem to be empty, running nothing, but refuse to die or be killed after they 
did their useful work (so they did run correctly, the problem seems to occur on 
poweroff).  What might be going on here?

This is:
* x86_64
* systemd 238.0-3 (from Arch)
* btrfs

% machinectl
MACHINECLASS SERVICEOS VERSION ADDRESSES
t-23-235311-webapptest container systemd-nspawn -  -   -
t-23-235806-webapptest container systemd-nspawn -  -   -
t-24-000300-webapptest container systemd-nspawn -  -   -
t-24-001033-webapptest container systemd-nspawn -  -   -
t-24-002455-webapptest container systemd-nspawn -  -   -

% machinectl status t-24-002455-webapptest
t-24-002455-webapptest(c844728734f243cfb99ffed0346bc9df)
   Since: Sat 2018-03-24 00:24:55 UTC; 20min ago
  Leader: 22947
 Service: systemd-nspawn; class container
Root: 
/build/x86_64/workarea/repository/dev/x86_64/uncompressed-images/.#machine.ubos_dev_x86_64-container_20180323-234823.tardir53dc09a3ef78c32c
   Iface: 13
Unit: machine-t\x2d24\x2d002455\x2dwebapptest.scope

Mar 24 00:24:55 ubos-pc systemd[1]: Started Container t-24-002455-webapptest.

The path to root does not exist (any more). All that’s left is the sibling lock 
file. btrfs does not list a relevant subvol.

Is Leader supposed to be a process ID? If so, such a process does not exist 
either.

% machinectl poweroff t-24-002455-webapptest
Could not kill machine: No such process

% machinectl terminate t-24-002455-webapptest
(says nothing, but does not do anything either)

% systemd-cgls
(does not show anything in the machine.slice, for none of the leftover machines)

Reboot makes them go away, but when I run the same scripts again, sooner or 
later I have leftover containers again.

There is nothing relevant in the journal I can see either.

This exact setup used to work just fine, I doubt I made any meaningful changes 
other than OS including systemd upgrades.

Life cycle:
1. systemd-nspawn --boot --ephemeral --network-veth --machine=t-xxx-webapptest 
--directory 
'/build/x86_64/workarea/repository/dev/x86_64/uncompressed-images/ubos_dev_x86_64-container_LATEST.tardir'
 --bind '/tmp/da6G8OYszu:/UBOS-STAFF' --system-call-filter=set_tls 
2. System boots, I ssh in, and do stuff, and when done:
3. machinectl poweroff ’t-xxx-webapptest'

Any ideas?

Thanks,



Johannes.



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

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 5, 2018, at 10:31, Zbigniew Jędrzejewski-Szmek  
> wrote:



>> systemd-sysusers
>> [[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
>> chown $(id -u foo):$(id -g foo) /var/lib/foo
> 
> # /usr/lib/tmpfiles.d/foo.conf
> d /var/lib/foo 0755 foo foo -
> 
> (BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).

Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to 
people like me to do it this way because it very clearly talks about 
“temporary” files.

Thanks,



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

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 4, 2018, at 21:56, Michael Chapman <m...@very.puzzling.org> wrote:
> 
> On Mon, 5 Feb 2018, Johannes Ernst wrote:
>> It appears systemd-sysusers does not create home directories. On the other 
>> hand, it picks (largely unpredictable) UIDs from a range.
>> 
>> So I have to run systemd-sysusers, and after that, find the UID of the user 
>> and chown the home directory? Or is there the equivalent of the “useradd -m” 
>> flag somewhere that I’m just not seeing?
> 
> systemd-sysusers is, as the name suggests, really for _system_ users, and 
> often those kinds of users don't have ordinary home directories -- that is, 
> ones the user can actually write to.

I agree with the “often” but not more :-)

> However, systemd-sysusers.service is ordered before 
> systemd-tmpfiles-setup.service at boot, so if you need to create a system 
> user's home directory and ensure its ownership is correct, you could use a 
> corresponding tmpfiles.d fragment to do so.

Hmm … tmpfiles.d, according to its man page, is for “the creation, cleaning and 
removal of volatile and temporary files and directories which usually reside in 
directories such as /run or /tmp.”. That doesn’t really seem to cover home 
directories that contain actual data.

Here’s my use case: Take a package for a daemon foo. The package contains a 
foo.service, and when foo runs, it is supposed to run in its own little place 
/var/lib/foo where it stores its data files. Because not everybody runs foo, it 
doesn’t make sense to pick a “fixed” UID like for more common daemons. 
Allocating a UID from a pool, like sysusers does, seems perfect. But how does 
the package ship /var/lib/foo? It can’t ship with owner foo because we don’t 
know what its UID is going to be. So the package, as part of its install 
script, needs to do something like:

systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo

I’d rather prefer a flag (if not the default) in the .conf file saying “create 
directory if it does not exist”. Perhaps worth adding?

But thanks for confirming that I didn’t miss anything, and I indeed need to 
jump through this hoop.

Cheers,



Johannes.



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

[systemd-devel] systemd-sysusers

[Johannes Ernst]

It appears systemd-sysusers does not create home directories. On the other 
hand, it picks (largely unpredictable) UIDs from a range.

So I have to run systemd-sysusers, and after that, find the UID of the user and 
chown the home directory? Or is there the equivalent of the “useradd -m” flag 
somewhere that I’m just not seeing?

Thanks,



Johannes.

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

Re: [systemd-devel] systemd-networkd-wait-online

[Johannes Ernst]

Thanks. I’m not surprised that work remains ...

Related question: systemd-networkd-wait-online.target seems to assume that once 
the network is online, it stays that way. I’d like to also take action when it 
goes down, and again when it comes back up. Any pointers how to best go about 
this? Is there an inverse of the systemd-networkd-wait-online executable?

Thanks,



Johannes.

> On Dec 6, 2017, at 3:30, Lennart Poettering <lenn...@poettering.net> wrote:
> 
> On Di, 05.12.17 12:21, Johannes Ernst (johannes.er...@gmail.com) wrote:
> 
> See the discussion on
> https://github.com/systemd/systemd/issues/7478#issuecomment-348508263
> regarding this kind of hardware.
> 
> Lennart
> 
> -- 
> Lennart Poettering, Red Hat

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

[systemd-devel] systemd-networkd-wait-online

[Johannes Ernst]

I’m running systemd 235.38 on an ARM64 device called the EspressoBin [1]. The 
EspressoBin board has an on-board Ethernet switch, which I configure with 
systemd-networkd (configuration is below). The device is intended as a home 
router that runs IPv4 masquerading, local DNS server etc.

I’m attempting to take action when the wan interface has a network connection 
to the upstream ISP. I discovered 
/usr/lib/systemd/systemd-networkd-wait-online, which behaves as follows:

% systemd-networkd-wait-online -i wan
Exactly what I would expect — once I connect upstream Ethernet, it prints 
"ignoring: lan0, lan1, eth0, lo” and returns true

% systemd-networkd-wait-online —ignore lan0 —ignore lan1
Same as first

% systemd-networkd-wait-online
“Hangs”

% systemd-networkd-wait-online -i lan0
“Hangs”

The way I read the man page [2] systemd-networkd-wait-online is supposed to 
return with true, even if only the wan interface is connected and the other two 
ports are configured (but not connected). Is my understanding correct? Or do 
all three ports need to be connected?

Thanks,



Johannes.



Configuration:

::
49-ubos-eth0.network
::
[Match]
Name=eth0

[Network]

::
50-ubos-lan0.network
::
[Match]
Name=lan0

[Network]
Address=192.168.140.1
DNS=192.168.140.1
IPForward=yes
BindCarrier=eth0

::
50-ubos-lan1.network
::
[Match]
Name=lan1

[Network]
Address=192.168.141.1
DNS=192.168.141.1
IPForward=yes
BindCarrier=eth0

::
50-ubos-wan.network
::
[Match]
Name=wan

[Network]
DHCP=yes
IPForward=yes
BindCarrier=eth0






[1] https://espressobin.net/
[2] 
https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html


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

Re: [systemd-devel] dhcp address change callback?

[Johannes Ernst]

> On Jan 25, 2016, at 4:43, Lennart Poettering <lenn...@poettering.net> wrote:
> 
> On Sat, 23.01.16 14:22, Johannes Ernst (johannes.er...@gmail.com) wrote:
> 
>> Is there a way to receive a callback when a dhcp client-side IP address 
>> changes?
>> 
>> Use case: dynamic DNS update.
> 
> On Linux changes regarding IP configuration are reported via rtnl (aka
> routing netlink). This works regardless how the IP address was
> required, and without any extra API from networkd.

So the way to do this would be to write a little daemon that listens to these 
events [1]

> RTM_NEWLINK (kernel→user)
> This message type is used in reply to a RTM_GETLINK request and carries the 
> configuration and statistics of a link. If multiple links need to be sent, 
> the messages will be sent in form of a multipart message.
> 
> The message type is also used for notifications sent by the kernel to the 
> multicast group RTNLGRP_LINK to inform about various link events. It is 
> therefore recommended to always use a separate link socket for link 
> notifications in order to separate between the two message types.
> 
and exec’s something in response? I agree it’s strange nobody has done that 
yet, apparently.

Cheers,



Johannes.


[1] https://www.infradead.org/~tgr/libnl/doc/route.html

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

[systemd-devel] dhcp address change callback?

[Johannes Ernst]

Is there a way to receive a callback when a dhcp client-side IP address changes?

Use case: dynamic DNS update.

Thanks,



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

[systemd-devel] container networking and iptables

[Johannes Ernst]

Setting IPMasquerade on a systemd-managed interface (e.g. for running an nspawn 
container) automatically sets up a “masquerade" netfilter entry. If an iptables 
ruleset exists already, it adds to it. (I think)

But what if I want to change other my firewall rules (unrelated to the 
container) without breaking the container’s networking? How would I add the 
systemd-generate rule to be added back in?

Example (in Arch):

1. System boots
2. systemd starts iptables.service, which reads its rules from 
/etc/iptables/iptables.rules
3. I start a container with nspawn -n, so networkd adds the equivalent of
-A POSTROUTING -s 10.0.0.0/28 -j MASQUERADE
to the ruleset. (At least I think it does.) Everything works fine.

4. I change my firewall rules by editing /etc/iptables/iptables.rules
5. system restart iptables

and voila, my container’s network is broken.

It’d be nice if there were some kind of saying:
cat /etc/iptables/iptables.rules /run/systemd/iptables/rules | 
iptables-restore
in iptables.service.

Or is there some other way of accomplishing this?

Thanks,



Johannes.

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

Re: [systemd-devel] ip forwarding

[Johannes Ernst]

> On Nov 6, 2015, at 1:09, Reindl Harald  wrote:
> 
> defaults should have security in mind, …

IMHO the current behavior is actually less secure:

If I set net.ipv4.ip_forward=1, I intentionally set forwarding on all 
interfaces, as documented in countless tutorials, so it’s very unlikely I 
didn’t mean to do that.

But if I set net.ipv4.ip_forward=1 in /etc/sysctl.d, and it only works 
sometimes and on some interfaces, I do have a security problem because it may 
come on when I least expect it. For example, when I execute systemctl restart 
systemd-sysctl.

(Because networkd doesn’t actually “manage” the interface, it only sets certain 
attributes at certain times, which can still be changed outside of networkd any 
time. If net.ipv4.ip_forward were turned into a read-only setting, for example, 
that would be different.)

Cheers,



Johannes.

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

[systemd-devel] ip forwarding

[Johannes Ernst]

TL;DR: I propose to have IPForward default to “no change”, rather than 0, as 0 
has unexpected consequences for non-expert users.

Details: A few months ago there where some threads about ip_forwarding needing 
a toggle from 1 to 0 and back to 1 before it would work. [1][2][3]

It appears I found the reason for this. With "net.ipv4.ip_forward = 1” in 
sysctl.d, after a fresh boot:

> for i in /proc/sys/net/ipv4/ip_forward 
/proc/sys/net/ipv4/conf/*/forwarding; do echo -n $i: ; cat $i; done
/proc/sys/net/ipv4/ip_forward:1
/proc/sys/net/ipv4/conf/all/forwarding:1
/proc/sys/net/ipv4/conf/default/forwarding:1
/proc/sys/net/ipv4/conf/enp0s3/forwarding:0<= Why?
/proc/sys/net/ipv4/conf/lo/forwarding:1

If I then do the toggle dance:

> sysctl net.ipv4.ip_forward=0
> sysctl net.ipv4.ip_forward=1

I get what I expected in the first place:

/proc/sys/net/ipv4/ip_forward:1
/proc/sys/net/ipv4/conf/all/forwarding:1
/proc/sys/net/ipv4/conf/default/forwarding:1
/proc/sys/net/ipv4/conf/enp0s3/forwarding:1
/proc/sys/net/ipv4/conf/lo/forwarding:1

Adding net.ipv4.conf.enp0s3.forwarding = 1 to sysctl.d does not have the 
desired effect.

Turns out my innocent-looking .network file is the culprit:

[Match]
Name=en*

[Network]
DHCP=ipv4

Without that file, after boot the enp0s3 flag remains 1 as expected.

The problem: I thought I created that file to say “get an IP address via DHCP” 
because that’s all it talks about. But due to the IPForward default, I also 
specified “and turn off ip forwarding”, which is non-obvious (e.g. I just found 
out, and I originally ran into this in June). So I suggest the default should 
be “don’t touch this setting” instead of 0.

Cheers,



Johannes.


[1] http://lists.freedesktop.org/archives/systemd-devel/2015-June/033239.html
[2] http://lists.freedesktop.org/archives/systemd-devel/2015-July/033738.html
[3] https://github.com/systemd/systemd/issues/468

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

Re: [systemd-devel] ip forwarding

[Johannes Ernst]

This makes my point. The default = 0 is counter intuitive and costs much time 
for the lucky ones among us who can figure it out. The rest will just give up...

Sent from my iPad.

> On Nov 5, 2015, at 22:32, Peter Paule  wrote:
> 
> Hi Johannes,
> 
> I had the same problem, I even wrote an article about that
> (https://www.fedux.org/articles/2015/09/09/having-no-fun-with-rubygems-systemd-docker-and-networking.html).
> 
> I think, you use `systemd-networkd`. Correct? The behaviour is documented
> in "systemd.network-manual".
> 
>  Note: unless this option is turned on, or set to “kernel”, no IP
>  forwarding is done on this interface, even if this is globally turned on
>  in the kernel, with the net.ipv4.ip_forward,
>  net.ipv4.conf.all.forwarding, and net.ipv6.conf.all.forwarding sysctl
>  options.
> 
> I took me by surprise, too. But a new tool needs some learning.
> Unfortunately. Though I would suggest to add some example to the manual
> `systemd.network` or at least add a comment like that.
> 
> ~~~
> Example 2. /etc/systemd/network/80-dhcp.network
> 
> [Match]
> Name=en*
> 
> [Network]
> DHCP=yes
> # enable ip forwarding for that interface, defaults to "no"
> # IPForward=yes
> ~~~
> 
> Cheers,
> Dennis
> 
> Excerpts from Johannes Ernst's message of 2015-11-05 16:08:26 -0800:
>> TL;DR: I propose to have IPForward default to “no change”, rather than 0, as 
>> 0 has unexpected consequences for non-expert users.
>> 
>> Details: A few months ago there where some threads about ip_forwarding 
>> needing a toggle from 1 to 0 and back to 1 before it would work. [1][2][3]
>> 
>> It appears I found the reason for this. With "net.ipv4.ip_forward = 1” in 
>> sysctl.d, after a fresh boot:
>> 
>>> for i in /proc/sys/net/ipv4/ip_forward 
>>> /proc/sys/net/ipv4/conf/*/forwarding; do echo -n $i: ; cat $i; done
>>/proc/sys/net/ipv4/ip_forward:1
>>/proc/sys/net/ipv4/conf/all/forwarding:1
>>/proc/sys/net/ipv4/conf/default/forwarding:1
>>/proc/sys/net/ipv4/conf/enp0s3/forwarding:0<= Why?
>>/proc/sys/net/ipv4/conf/lo/forwarding:1
>> 
>> If I then do the toggle dance:
>> 
>>> sysctl net.ipv4.ip_forward=0
>>> sysctl net.ipv4.ip_forward=1
>> 
>> I get what I expected in the first place:
>> 
>>/proc/sys/net/ipv4/ip_forward:1
>>/proc/sys/net/ipv4/conf/all/forwarding:1
>>/proc/sys/net/ipv4/conf/default/forwarding:1
>>/proc/sys/net/ipv4/conf/enp0s3/forwarding:1
>>/proc/sys/net/ipv4/conf/lo/forwarding:1
>> 
>> Adding net.ipv4.conf.enp0s3.forwarding = 1 to sysctl.d does not have the 
>> desired effect.
>> 
>> Turns out my innocent-looking .network file is the culprit:
>> 
>>[Match]
>>Name=en*
>> 
>>[Network]
>>DHCP=ipv4
>> 
>> Without that file, after boot the enp0s3 flag remains 1 as expected.
>> 
>> The problem: I thought I created that file to say “get an IP address via 
>> DHCP” because that’s all it talks about. But due to the IPForward default, I 
>> also specified “and turn off ip forwarding”, which is non-obvious (e.g. I 
>> just found out, and I originally ran into this in June). So I suggest the 
>> default should be “don’t touch this setting” instead of 0.
>> 
>> Cheers,
>> 
>> 
>> 
>> Johannes.
>> 
>> 
>> [1] http://lists.freedesktop.org/archives/systemd-devel/2015-June/033239.html
>> [2] http://lists.freedesktop.org/archives/systemd-devel/2015-July/033738.html
>> [3] https://github.com/systemd/systemd/issues/468
>> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] One-Command complex network reconfiguration, was: propagate reload from other events

[Johannes Ernst]

On Oct 12, 2015, at 1:20, Andrei Borzenkov <arvidj...@gmail.com> wrote:On Mon, Oct 12, 2015 at 1:40 AM, Johannes Ernst<johannes.er...@gmail.com> wrote:I guess I need to explain what I’m trying to do:I want a single command to reconfigure networking for different situationsthat a device running UBOS [2] might encounter. Example syntax:ubos-admin setnetconfig client# sets up DHCP client on all network interfaces, advertises http and httpssites on device via Avahi, runs firewallubos-admin setnetconfig static# allocates static IP addresses on all network interfaces, advertises httpand https sites via Avahi, runs firewallubos-admin setnetconfig gateway# sets up DHCP client on first Ethernet interface (WAN), allocates static IPaddresses to all other interfaces (LAN), advertises via Avahi but only onLAN, runs firewall and NATubos-admin setnetconfig cloud# sets up DHCP client on all network interfaces, no Avahi, runs firewall,also runs cloud-initThe idea is to take drudgery and needed competence out of networkconfiguration and make it “fool proof” by identifying the situation on ahigh level (“this is my home gateway”, “this is just some device on mynetwork” etc) and let software make it so.My implementation of ‘ubos-admin setnetconfig XXX’ basically goes like this:1. Generate/update configuration files for the configuration XXX2. systemctl start ubos-networking-XXX.service (where XXX=client, static,gateway, …), with all the ubos-networking-XXX.service files declaring aConflict with all others, so systemd will only run one of them at a time.To get back to the problem on the beginning of the thread, let’s take anexample:ubos-networking-client.service depends on systemd-networkd.service, with aconfig file like this:[Match]Name=*[Network]DHCP=ipv4ubos-networking-gateway.service depends on systemd-networkd.service, with aconfig file like this:[Match]Name=enp0s3[Network]DHCP=ipv4[Match]Name=*[Network]Address=0.0.0.0/16Now, if the current state is “client” and the user executes “ubos-adminsetnetconfig gateway”, after updating the config files, the following thingsneed to occur:1. ubos-networking-client.service needs to be stopped2. ubos-networking-gateway.service needs to be startedI still fail to see how ubos-networking-client.service orubos-networking-gateway.service come in play here. You changednetworkd configuration and need restart/reload networkd. That can bedone directly by ubos-admin. What is the purpose of other services?Just trying to make systemd do most of the work … the dependency management with Conflicts= and PropagateReload= does almost everything I need; was attempting to find out whether I overlooked something that would do the rest, but apparently not. That’s okay though :-)Thanks for your help.3. systemd-networkd.service needs to be reloaded, because its configurationhas changed.So I was wondering whether there is a mechanism to have systemd reloadsystemd-networkd, in response to an event such asubos-networking-client.service being stopped, orubos-networking-gateway.service being started.Does this make sense?Not really :)___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Two services allocated for the same bus name ...

[Johannes Ernst]

> On Oct 10, 2015, at 22:54, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 
> 11.10.2015 06:09, Johannes Ernst пишет:
>> I’m trying to set up two different Avahi configurations, using foo.service 
>> and bar.service.
>> 
>> Error message:
>> 
>> Two services allocated for the same bus name org.freedesktop.Avahi, refusing 
>> operation.
>> 
>> On the face of it, that seems to be correct: indeed foo.service and 
>> bar.service both declare
>> 
>> [Service]
>> Type=dbus
>> BusName=org.freedesktop.Avahi
>> 
>> However, I have in foo.service:
>> 
>> [Unit]
>> Conflicts=bar.service
>> 
>> and vice versa, so they will never be active at the same time. Is there some 
>> way to make this work? [I don’t know who might want to talk to Avahi via 
>> dbus, but it makes sense that they should find either foo or bar, depending 
>> on which configuration is currently up, so I don’t really want to rename 
>> this]
>> 
> 
> It sounds like you try to start both of them at the same time, is it correct?

No: Just doing a “systemctl status foo” or a “systemctl daemon-reload" produces 
foo.service: "Two services allocated for the same bus name 
org.freedesktop.Avahi, refusing operation.”

It seems the error checking is a bit too aggressive, as the Conflicts should 
make it impossible that a dbus conflict ever occurs? Or is there a workaround?

> 
>> Cheers,
>> 
>> 
>> 
>> Johannes.
>> 
>> 
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org 
>> <mailto:systemd-devel@lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel 
>> <http://lists.freedesktop.org/mailman/listinfo/systemd-devel>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] One-Command complex network reconfiguration, was: propagate reload from other events

[Johannes Ernst]

On Oct 10, 2015, at 23:16, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 
> 11.10.2015 07:14, Johannes Ernst пишет:
>> I understand that if foo.service specifies:
>> 
>> PropagatesReloadTo=bar.service
>> 
>> and I execute “systemctl reload foo”, this will trigger a reload of bar as 
>> well. Typically I might do that if I have changed some config file, and I 
>> want the daemon(s) to pick it up.
>> 
>> Is there a similar mechanism that triggers a reload in bar when foo stops, 
>> or when foo starts, or events like that?
>> 
>> I found a thread from 3 years ago on an OnStop= rule, but I don’t think that 
>> made it into the mainline? [1]
>> 
>> My use case is that if I switch from foo.service to foo2.service (both 
>> require bar, and are mutually exclusive to each other), I’d like bar to 
>> reload.
> 
> Usually if service A requires service B, service B need not be aware about 
> service A starting or stopping. In your case it actually sounds like "bar 
> requires either foo or foo2", otherwise why bar would need restart?

I guess I need to explain what I’m trying to do:

I want a single command to reconfigure networking for different situations that 
a device running UBOS [2] might encounter. Example syntax:

> ubos-admin setnetconfig client
# sets up DHCP client on all network interfaces, advertises http and https 
sites on device via Avahi, runs firewall
> ubos-admin setnetconfig static
# allocates static IP addresses on all network interfaces, advertises http and 
https sites via Avahi, runs firewall
> ubos-admin setnetconfig gateway
# sets up DHCP client on first Ethernet interface (WAN), allocates static IP 
addresses to all other interfaces (LAN), advertises via Avahi but only on LAN, 
runs firewall and NAT
> ubos-admin setnetconfig cloud
# sets up DHCP client on all network interfaces, no Avahi, runs firewall, also 
runs cloud-init

The idea is to take drudgery and needed competence out of network configuration 
and make it “fool proof” by identifying the situation on a high level (“this is 
my home gateway”, “this is just some device on my network” etc) and let 
software make it so.

My implementation of ‘ubos-admin setnetconfig XXX’ basically goes like this:

1. Generate/update configuration files for the configuration XXX
2. systemctl start ubos-networking-XXX.service (where XXX=client, static, 
gateway, …), with all the ubos-networking-XXX.service files declaring a 
Conflict with all others, so systemd will only run one of them at a time.

To get back to the problem on the beginning of the thread, let’s take an 
example:

ubos-networking-client.service depends on systemd-networkd.service, with a 
config file like this:

[Match]
Name=*
[Network]
DHCP=ipv4

ubos-networking-gateway.service depends on systemd-networkd.service, with a 
config file like this:

[Match]
Name=enp0s3
[Network]
DHCP=ipv4
[Match]
Name=*
[Network]
Address=0.0.0.0/16

Now, if the current state is “client” and the user executes “ubos-admin 
setnetconfig gateway”, after updating the config files, the following things 
need to occur:
1. ubos-networking-client.service needs to be stopped
2. ubos-networking-gateway.service needs to be started
3. systemd-networkd.service needs to be reloaded, because its configuration has 
changed.

So I was wondering whether there is a mechanism to have systemd reload 
systemd-networkd, in response to an event such as 
ubos-networking-client.service being stopped, or 
ubos-networking-gateway.service being started.

Does this make sense?


[2] http://ubos.net/

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

[systemd-devel] Two services allocated for the same bus name ...

[Johannes Ernst]

I’m trying to set up two different Avahi configurations, using foo.service and 
bar.service.

Error message:

Two services allocated for the same bus name org.freedesktop.Avahi, refusing 
operation.

On the face of it, that seems to be correct: indeed foo.service and bar.service 
both declare

[Service]
Type=dbus
BusName=org.freedesktop.Avahi

However, I have in foo.service:

[Unit]
Conflicts=bar.service

and vice versa, so they will never be active at the same time. Is there some 
way to make this work? [I don’t know who might want to talk to Avahi via dbus, 
but it makes sense that they should find either foo or bar, depending on which 
configuration is currently up, so I don’t really want to rename this]

Cheers,



Johannes.


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

[systemd-devel] propagate reload from other events

[Johannes Ernst]

I understand that if foo.service specifies:

PropagatesReloadTo=bar.service

and I execute “systemctl reload foo”, this will trigger a reload of bar as 
well. Typically I might do that if I have changed some config file, and I want 
the daemon(s) to pick it up.

Is there a similar mechanism that triggers a reload in bar when foo stops, or 
when foo starts, or events like that?

I found a thread from 3 years ago on an OnStop= rule, but I don’t think that 
made it into the mainline? [1]

My use case is that if I switch from foo.service to foo2.service (both require 
bar, and are mutually exclusive to each other), I’d like bar to reload.


[1] 
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007304.html

Thanks for the help, as always,



Johannes.

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

Re: [systemd-devel] container virtual Ethernet link naming

[Johannes Ernst]

> On Oct 9, 2015, at 13:00, Dan Williams <d...@redhat.com> wrote:
> 
> On Fri, 2015-10-09 at 12:53 -0700, Johannes Ernst wrote:
>> man systemd-nspawn, section on --network-veth
>>"The container side of the Ethernet link will be named 
>> host0."
>> 
>> container> ip link
>> ...
>> 2: host0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel 
>> state UP mode DEFAULT group default qlen 1000
>>link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
>> 
>> Where does the @if9 come from, and what’s the naming scheme here?
> 
> It comes from /sbin/ip.  What's after the @ is the interface index of
> the veth peer, so "if9" == interface index 9 and that tells you what the
> peer link will be outside the container/namespace.  The stuff after the
> @ isn't controlled by systemd/udev, the "if" prefix is hardcoded
> in /sbin/ip.

This is actually cool, and as far as I can find, entirely undocumented :-)

I put a paragraph on the Arch wiki: 
https://wiki.archlinux.org/index.php/Systemd-nspawn#Virtual_Ethernet_interfaces 
based on your information. Thank you!

Cheers,



Johannes.

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

[systemd-devel] container virtual Ethernet link naming

[Johannes Ernst]

man systemd-nspawn, section on --network-veth
"The container side of the Ethernet link will be named 
host0."

container> ip link
...
2: host0@if9:  mtu 1500 qdisc fq_codel state 
UP mode DEFAULT group default qlen 1000
link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0

Where does the @if9 come from, and what’s the naming scheme here?

Cheers,



Johannes.

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

Re: [systemd-devel] run no more than one of foo@.service at a time

[Johannes Ernst]

> On Oct 6, 2015, at 6:19, Lennart Poettering <lenn...@poettering.net> wrote:
> 
> On Mon, 05.10.15 09:04, Johannes Ernst (johannes.er...@gmail.com) wrote:
> 
>> I have a foo@.service. When started as
>>  systemctl start foo@abc
>> I’d like all other currently active foo@… services to stop, and vice versa. 
>> All of the foo@.services are supposed to be mutually exclusive with each 
>> other.
>> 
>> In foo@.service, I attempted:
>>  Conflicts: foo@.service
>> but that does not seem to do the trick (Starting foo@abc produces 
>> "Dependency Conflicts=foo@abc.service dropped”)
>> 
>> I’d like to avoid having to enumerate foo@abc, foo@def etc. in the Conflicts 
>> section.
> 
> Service templates are really about multi-instantiation, and explicitly
> not about enabling parameterization. That's why we only take a single
> instance identifier as parameter, and not a list of parameters, for
> example.

Good to know the principle here.

> Why wouldn't a nomral suervice suffice for your usecase, with maybe a
> few .d/ dropins to configure things differently?

That’s the kind of thing I will probably do.

Thanks,



Johannes.

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

Re: [systemd-devel] run no more than one of foo@.service at a time

[Johannes Ernst]

> On Oct 5, 2015, at 14:29, David Timothy Strauss <da...@davidstrauss.net> 
> wrote:
> 
> If you only want one instance running, why not just create one service and 
> reconfigure/restart it?
> 
Because the service dependencies are totally different.

> 
> On Mon, Oct 5, 2015, 09:04 Johannes Ernst <johannes.er...@gmail.com 
> <mailto:johannes.er...@gmail.com>> wrote:
> I have a foo@.service. When started as
> systemctl start foo@abc
> I’d like all other currently active foo@… services to stop, and vice versa. 
> All of the foo@.services are supposed to be mutually exclusive with each 
> other.
> 
> In foo@.service, I attempted:
> Conflicts: foo@.service
> but that does not seem to do the trick (Starting foo@abc produces "Dependency 
> Conflicts=foo@abc.service dropped”)
> 
> I’d like to avoid having to enumerate foo@abc, foo@def etc. in the Conflicts 
> section.
> 
> Ideas?
> 
> Thanks,
> 
> 
> 
> Johannes.
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> <mailto:systemd-devel@lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> <http://lists.freedesktop.org/mailman/listinfo/systemd-devel>

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

[systemd-devel] run no more than one of foo@.service at a time

[Johannes Ernst]

I have a foo@.service. When started as
systemctl start foo@abc
I’d like all other currently active foo@… services to stop, and vice versa. All 
of the foo@.services are supposed to be mutually exclusive with each other.

In foo@.service, I attempted:
Conflicts: foo@.service
but that does not seem to do the trick (Starting foo@abc produces "Dependency 
Conflicts=foo@abc.service dropped”)

I’d like to avoid having to enumerate foo@abc, foo@def etc. in the Conflicts 
section.

Ideas?

Thanks,



Johannes.

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

[systemd-devel] systemctl -M foo operates on host not container foo

[Johannes Ernst]

This sounds silly but I do think this used to work for me (current: v225 on 
Arch, perhaps something broke?)

> systemctl -M foo enable sshd.service

creates the symlink on the host, not in the container.
Other sub-commands also work on the host, not the container.

machine foo doesn’t actually exist. If it exists, the behavior is still the 
same.

The machine name argument is completely ignored.

What am I missing?

Actually just found an old v222. That produces a dbus error if machine foo does 
not exist. That sounds more reasonable.

Cheers,



Johannes.

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

[systemd-devel] directory for machine templates

[Johannes Ernst]

/var/lib/machines is intended to be, as I understand it, for (virtual) machines 
that are or could be started at every boot.

Would it make sense to have a similar convention for templates?

Use cases:
1. Testing. Pull base image once, run lots of containers from the same base 
image
2. Hosting. Pull common base image(s) once, let customers instantiate lots of 
containers from the same base image(s)

It could work like this, with -T (template) in analogy to -M (machine):

$ system-nspawn -T fedora-xyz -M fedora-test123

where /var/lib/machine-templates/fedora-xyz is the file downloaded with 
something like:

$ machinectl pull-raw-template http://../fedora-xyz http://../fedora-xyz

Just a thought.

Cheers,



Johannes.

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

[systemd-devel] ip_forward issue again

[Johannes Ernst]

The strange sysctl fails to setup IP forwarding #468”, closed after ordering 
systemd-sysctl and systemd-networkd, unfortunately still occurs for me.

https://github.com/systemd/systemd/issues/468#issuecomment-117904714

Cheers,



Johannes.

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

Re: [systemd-devel] Fedora 21 and systemd-nspawn

[Johannes Ernst]

 On Jun 15, 2015, at 18:15, Chris Morgan chmor...@gmail.com wrote:
 
 But yeah, was wondering if there were known users of nspawn containers that 
 discussed their use cases.

I’m starting to us it for testing of installation and upgrades of various web 
apps on UBOS [1] using webapptest [2]. This means spinning up, doing installing 
a few things, running curl from the host, and then shutting down lots of 
containers in a short amount of time.

So far, I have been using VirtualBox, which takes a looong time and only works 
on x86, but I’d also like to test on various little ARM devices.

Currently, the jury is still out whether nspawn is currently reliable enough to 
migrate most of our automated tests to it. Most of my posts to this list in the 
past month have come from trying to figure that out / make it work.

Cheers,



Johannes.

[1] http://ubos.net/ http://ubos.net/
[2] http://ubos.net/docs/developers/app-test.html#alternate-scaffolds 
http://ubos.net/docs/developers/app-test.html#alternate-scaffolds



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

Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

 On Jul 3, 2015, at 4:01, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 01.07.15 13:50, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 We should probably handle this case in a nicer way, and downgrade
 EROFS error for cases like this.

Should I file this as an issue, so it won’t get lost, or do you keep track of 
this kind of thing somewhere else? 

Cheers,


Johannes.


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

Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

 On Jul 3, 2015, at 4:01, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 01.07.15 13:50, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 Hey Martin,
 
 thanks, but:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 We should probably handle this case in a nicer way, and downgrade
 EROFS error for cases like this.
 
 Can you let me know which tmpfiles snippet actually adds this line,
 and what precisely it contains? i.e. look in /usr/lib/tmpfiles.d/ for
 the file that mentions /sys/devices/system/cpu/microcode/reload, and
 figure out the package name it is shipped with, and paste the contents
 of the file here.

/usr/lib/tmpfiles.d/linux-firmware.conf is owned by linux-firmware 
20150527.3161bfa-1

Content:

w /sys/devices/system/cpu/microcode/reload - - - - 1


 
 Thanks,
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

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

[systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

My container is degraded because systemd-tmpfiles-setup.service failed. My 
understanding is that it should not run in the container anyway. (Right?)

How do I find out why it was started?

This is probably a noob question.

Thanks,



Johannes.

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

Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

Hey Martin,

thanks, but:

 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.

Here is what fails:

# /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file 
system

This is systemd 221 on Arch in a container straight from the man page, just in 
case I screwed up my own, but the behavior is the same.

# pacstrap -c -d $(pwd)/arch-tree base
# systemd-nspawn -bD $(pwd)/arch-tree/

 How do I find out why it was started?
 
 $ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service
 systemd-tmpfiles-setup.service
 ● └─sysinit.target

This analyzes the static dependencies (and does indeed solve my problem here, 
thanks! I had missed the —reverse flag),
but I was wondering whether there was something more dynamic that could tell me 
something like:

a.service started, because b.service required it
b.service started because user foobar started it

 
 systemctl status systemd-tmpfiles-setup.service will say that it's
 statically enabled, and the list-dependencies says where. I. e. you
 should have a symlink
 /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service
 
 (could also be in /lib/systemd/, depending on your distro)
 
 Martin
 
 -- 
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

[systemd-devel] what does --ephemeral really do on btrfs?

[Johannes Ernst]

If I run systemd-nspawn with —ephemeral, it creates a new temporary btrfs 
subvolume, the documentation says.

Mine takes an awful long time — blocking IO on the device in the awful long 
meantime — and I’m puzzled why. Does it perhaps copy (deep? references only?) 
the entire drive? 

Should I put the original directory on a separate subvolume, or how can I speed 
this up? If I just copied the image / directory, this might be faster.

Thanks,



Johannes.

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

Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

 On Jul 1, 2015, at 14:59, Michael Biebl mbi...@gmail.com wrote:
 
 2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com:
 Hey Martin,
 
 thanks, but:
 
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)
 
 It should run in a container; its purpose is both necessary, and I
 don't see why a container would have any difficulty with it. It runs
 just fine in both system and even unprivileged user containers here.
 
 Here is what fails:
 
 # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
 Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only 
 file system
 
 Which packages ships that tmpfiles snippet? This is not coming from
 systemd itself.

https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in
 
https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in


 
 -- 
 Why is it that all of the instruments seeking intelligent life in the
 universe are pointed away from Earth?

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

[systemd-devel] getent hosts machine

[Johannes Ernst]

I was hoping that
getent hosts containername
would work, just like
getent hosts hostname
where hostname can be anything else in the hosts: field in nsswitch.conf. But 
no such luck.

The containername does get resolved correctly in other cases, e.g. when 
pinging it.

Not knowing how getent actually works, I don’t know why that is, but I figured 
I mention it.

Cheers,



Johannes.

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

Re: [systemd-devel] getent hosts machine

[Johannes Ernst]

 On Jun 29, 2015, at 10:32, Johannes Ernst johannes.er...@gmail.com wrote:
 
 I was hoping that
   getent hosts containername
 would work, just like
   getent hosts hostname
 where hostname can be anything else in the hosts: field in nsswitch.conf. 
 But no such luck.
 
 The containername does get resolved correctly in other cases, e.g. when 
 pinging it.
 
 Not knowing how getent actually works, I don’t know why that is, but I 
 figured I mention it.

I take it back. A reboot fixed it.

It appears I had a different problem: machinectl (suddenly) stopped showing any 
containers, but ps still showed several systemd-nspawn processes. These 
containers were originally shown with machinectl. The corresponding nics were 
also still there. Wildly speculating, I’d say it might be possible that getent 
stopped working at that time, and “ping” used a cached value.

This may be the same situation as I reported here: 
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033150.html 
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033150.html — 
perhaps the container was still there, it just didn’t show up with machinectl 
any more, which made me believe it was a leftover interface.

(No, I did not touch —register, and note the containers did show up with 
machinectl after they had been started)

I’ll see whether I can reproduce this, after reboot.

Cheers,



Johannes.

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

Re: [systemd-devel] howto handle one time shutdown programs

[Johannes Ernst]

Hallo Andreas,

 On Jun 25, 2015, at 7:57, Andreas Buschmann busch...@tech.net.de wrote:
 
 Hello,
 
 I am writing a systemd .service file to handle NVDIMMs.
 
 - start
 - stop
 - reload
 all work
 
 The problem child is restart.
 Restart is internally implemented as stop followed by start.
 
 The problem is, that stop calls a program which does something to the
 NVDIMM hardware.
 After that no further access to the NVDIMMs is possible before the next
 reboot of the server.
 
 How should I handle that sort of logic with systemd?

How is that different from the user executing:

systemctl start your.service
systemctl stop your.service
systemctl start your.service

without reboot?

 
 
   Mit freundlichen Gruessen
   Andreas Buschmann
 -- 
 
 Andreas Buschmann
 [Senior Systems Engineer]
 
 net.DE AG
 Büttnerstraße 57
 D-30165 Hannover 
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

Re: [systemd-devel] journalctl - Error was encountered while opening journal files: Invalid argument

[Johannes Ernst]

I realized later that this virtual machine had ended up with a borked btrfs 
filesystem. I blame it on a problem with the outer OSX filesystem, but 
regardless, it does not seem to be a systemd problem.

So disregard this error.

Cheers,



Johannes.

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

Re: [systemd-devel] How to provision a container after creation via a script

[Johannes Ernst]

 On Jun 23, 2015, at 7:45, Matthew Karas mkarasc...@gmail.com wrote:
 
 I am trying to configure a container after creation using machinectl
 but I'm coming up against problems in my implementation.  If this
 isn't the correct way to set up a container after creation please let
 me know the right way.
 
 -My Implementation--
 I'm running a bash loop installing modules via systemd-nspawn on the machine
 
 systemd-nspawn -m MACHINE dnf -y install PACKAGE
 
 The machine was created via this command
 
 sudo machinectl pull-raw --verify=no httppath to fed22 MACHINE
 
 -My Problem---
 
 The script installs a few packages then hangs saying the command for
 systemd-nspawn was killed.  Each attempt installs a few more packages.
 
 Once the script hangs - I have to reboot the system, as systemd-nspawn
 says the file system is busy.  There is no way to cancel the script
 unless you close the terminal.
 
 -My System
 
 I'm on a macbook pro running parallels 9 - the VM is a fedora 22 install.

I’m doing something rather similar on a macbook pro running VirtualBox and 
Arch. Have not run into problems.

Does your scenario work if you do the installation manually from the shell 
instead of from a script?

Just to state the obvious: the virtual machine has enough memory?


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

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

[systemd-devel] ip_forward

[Johannes Ernst]

(Morale: in doubt, lean hard on your booleans)

1. Reboot host. (Arch running in VirtualBox on Mac)

2. host sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

3. host sudo systemd-nspawn -M container -b -j -n --bind /home:/home
(Arch subset / UBOS)

4. container ping 8.8.8.8
7 packets transmitted, 0 received, 100% packet loss, time 6009ms

5. host sudo sysctl net.ipv4.ip_forward=0
net.ipv4.ip_forward = 0

6. host sudo sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

7. container # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=17.2 ms

This seems reproducible.



Settings:

host cat /etc/systemd/network/50-containers.network 
[Match]
Name=ve-*

[Network]
Address=0.0.0.0/28
IPMasquerade=yes
IPv4LL=yes
DHCPServer=yes
IPForward=yes
DNS=192.168.138.1


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

[systemd-devel] machinectl start vs. systemctl enable systemd-nspawn@...

[Johannes Ernst]

What’s the difference between
machinectl start foo
and
systemctl start systemd-nspawn@foo
? They look the same to me. 

Thanks,



Johannes.

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

[systemd-devel] machinectl clone -- access denied

[Johannes Ernst]

I can import-tar, list-images, image-status, start, rename, and remove, but 

 sudo machinectl clone depot depot2
Could not clone image: Access denied

Am I doing this wrong?

This is systemd 221-1 on Arch.


$ sudo machinectl list-images 
NAME  TYPE  RO  USAGE  CREATED MODIFIED
depot subvolume no  888.2M Mon 2015-06-22 23:02:38 UTC n/a 

1 images listed.

$ sudo machinectl show-image depot
Name=depot
Path=/var/lib/machines/depot
Type=subvolume
ReadOnly=no
CreationTimestamp=Mon 2015-06-22 23:02:38 UTC
Usage=937963520
Limit=18446744073709551615
UsageExclusive=937963520
LimitExclusive=18446744073709551615



[root@localhost]# strace machinectl clone depot depot2
execve(/usr/bin/machinectl, [machinectl, clone, depot, depot2], [/* 
19 vars */]) = 0
brk(0)  = 0x7f274af0
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=113959, ...}) = 0
mmap(NULL, 113959, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f274a264000
close(3)= 0
open(/usr/lib/librt.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\220!\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31672, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f274a263000
mmap(NULL, 2128856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f2749e57000
mprotect(0x7f2749e5e000, 2093056, PROT_NONE) = 0
mmap(0x7f274a05d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f274a05d000
close(3)= 0
open(/usr/lib/liblzma.so.5, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\2001\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=154288, ...}) = 0
mmap(NULL, 2249360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f2749c31000
mprotect(0x7f2749c56000, 2093056, PROT_NONE) = 0
mmap(0x7f2749e55000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f2749e55000
close(3)= 0
open(/usr/lib/liblz4.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300$\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=71968, ...}) = 0
mmap(NULL, 2167144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f2749a1f000
mprotect(0x7f2749a3, 2093056, PROT_NONE) = 0
mmap(0x7f2749c2f000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7f2749c2f000
close(3)= 0
open(/usr/lib/libgcrypt.so.20, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\221\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=919976, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f274a262000
mmap(NULL, 3016352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f274973e000
mprotect(0x7f2749815000, 2097152, PROT_NONE) = 0
mmap(0x7f2749a15000, 40960, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd7000) = 0x7f2749a15000
close(3)= 0
open(/usr/lib/libpthread.so.0, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320`\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142832, ...}) = 0
mmap(NULL, 2213040, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f2749521000
mprotect(0x7f2749539000, 2093056, PROT_NONE) = 0
mmap(0x7f2749738000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f2749738000
mmap(0x7f274973a000, 13488, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f274973a000
close(3)= 0
open(/usr/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\260\10\2\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1979984, ...}) = 0
mmap(NULL, 3807760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f274917f000
mprotect(0x7f2749318000, 2093056, PROT_NONE) = 0
mmap(0x7f2749517000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x198000) = 0x7f2749517000
mmap(0x7f274951d000, 14864, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f274951d000
close(3)= 0
open(/usr/lib/libgpg-error.so.0, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\20)\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=76320, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f274a261000
mmap(NULL, 2171480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f2748f6c000
mprotect(0x7f2748f7e000, 2093056, PROT_NONE) = 0
mmap(0x7f274917d000, 8192, 

[systemd-devel] Confusing error message

[Johannes Ernst]

$ systemctl restart systemd-networkd
Failed to restart systemd-networkd.service: The name org.freedesktop.PolicyKit1 
was not provided by any .service files

$ sudo systemctl restart systemd-networkd
Works.

Presumably this error message could be improved, in particular because that 
name is indeed not provided by any .service files :-)

Cheers,



Johannes.

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

Re: [systemd-devel] journalctl - Error was encountered while opening journal files: Invalid argument

[Johannes Ernst]

 On Jun 19, 2015, at 23:37, Daniel Mack dan...@zonque.org wrote:
 
 On 06/19/2015 09:31 PM, Johannes Ernst wrote:
 After a reboot, root gets this:
 
 # journalctl 
 Error was encountered while opening journal files: Invalid argument
 
 No other output.
 
 What does 'strace journalctl' say?

# strace journalctl
execve(/usr/bin/journalctl, [journalctl], [/* 18 vars */]) = 0
brk(0)  = 0x7f1c03a8d000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=204989, ...}) = 0
mmap(NULL, 204989, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1c036d
close(3)= 0
open(/usr/lib/librt.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\220!\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31672, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1c036cf000
mmap(NULL, 2128856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c032da000
mprotect(0x7f1c032e1000, 2093056, PROT_NONE) = 0
mmap(0x7f1c034e, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f1c034e
close(3)= 0
open(/usr/lib/liblzma.so.5, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\2001\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=154288, ...}) = 0
mmap(NULL, 2249360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c030b4000
mprotect(0x7f1c030d9000, 2093056, PROT_NONE) = 0
mmap(0x7f1c032d8000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f1c032d8000
close(3)= 0
open(/usr/lib/liblz4.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300$\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=71968, ...}) = 0
mmap(NULL, 2167144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c02ea2000
mprotect(0x7f1c02eb3000, 2093056, PROT_NONE) = 0
mmap(0x7f1c030b2000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7f1c030b2000
close(3)= 0
open(/usr/lib/libgcrypt.so.20, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\221\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=919976, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1c036ce000
mmap(NULL, 3016352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c02bc1000
mprotect(0x7f1c02c98000, 2097152, PROT_NONE) = 0
mmap(0x7f1c02e98000, 40960, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd7000) = 0x7f1c02e98000
close(3)= 0
open(/usr/lib/libacl.so.1, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300 \0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=35384, ...}) = 0
mmap(NULL, 2130592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c029b8000
mprotect(0x7f1c029c, 2093056, PROT_NONE) = 0
mmap(0x7f1c02bbf000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f1c02bbf000
close(3)= 0
open(/usr/lib/libpthread.so.0, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320`\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142832, ...}) = 0
mmap(NULL, 2213040, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c0279b000
mprotect(0x7f1c027b3000, 2093056, PROT_NONE) = 0
mmap(0x7f1c029b2000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f1c029b2000
mmap(0x7f1c029b4000, 13488, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1c029b4000
close(3)= 0
open(/usr/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\260\10\2\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1979984, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1c036cd000
mmap(NULL, 3807760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1c023f9000
mprotect(0x7f1c02592000, 2093056, PROT_NONE) = 0
mmap(0x7f1c02791000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x198000) = 0x7f1c02791000
mmap(0x7f1c02797000, 14864, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1c02797000
close(3)= 0
open(/usr/lib/libgpg-error.so.0, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\20)\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=76320, ...}) = 0
mmap(NULL, 2171480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0

[systemd-devel] journalctl - Error was encountered while opening journal files: Invalid argument

[Johannes Ernst]

After a reboot, root gets this:

# journalctl 
Error was encountered while opening journal files: Invalid argument

No other output.
Non-root gets user-specific output.

What might have happened here. and how do I fix it? I upgraded from 220 to 221: 
same behavior.

I briefly ran out of space on a root btrfs filesystem yesterday. Might this 
have anything to do with it?

Thanks,



Johannes.

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

[systemd-devel] leftover interface

[Johannes Ernst]

Not sure how I just managed to do that, but after an nspawn run with -n, I have 
a leftover ve-xxx interface on the host. The container/machine is gone, the 
(ephemeral) file system is gone, just the interface is still there.

Also sometimes it seems that the ephemeral subvolume stays around if the 
container has been shut down with ‘machinectl poweroff’.

This is not a bug report, as I don’t know what I did, but I wanted to mention 
it in case...

Cheers,



Johannes.

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

Re: [systemd-devel] machinectl status vs show

[Johannes Ernst]

In which case:

1. The man pages, to me, imply that I should be able to get everything that 
‘status' shows using ‘show' because it says:

This function is intended to generate human-readable output. If you are 
looking for computer-parsable output, use show instead.” (and vice versa)

This sentence may need a revision.

2. So how do I get at the IP address of the container in a way that is easily 
parseable?

Cheers,


Johannes.


 On Jun 17, 2015, at 1:42, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 17.06.15 10:13, David Herrmann (dh.herrm...@gmail.com 
 mailto:dh.herrm...@gmail.com) wrote:
 
 Hi
 
 On Wed, Jun 17, 2015 at 5:53 AM, Johannes Ernst
 johannes.er...@gmail.com wrote:
 Are those supposed to produce the same information, just formatted 
 differently (man vs machine per man page)?
 
 I’m failing to convince ‘show’ to give me the container’s IP address, while 
 ‘status’ has all of them.
 
 As with almost all *ctl tools in systemd, 'show' is used to print DBus
 properties of the object in question. 'status' on the other hand
 prints a human-readable, pre-selected set of attributes of an object.
 
 With machinectl, the 'show' command must be used with a parameter. So
 `machinectl --all show $machine` should contain the same information
 as `machinectl status $machine`, and even more. If that's not the
 case, please post an example.
 
 Well, machinectl status also shows the cgroup tree, which
 machinectl show currently does not.
 
 The IP addresses are not exposed as property, they are exposed
 as method, since acquiring them is relatively complex due to
 transitioning into the containers... That means they show up in
 machinectl status, because that code explicitly calls that method,
 but not in machinectl show which shows the plain props, and nothing
 else.
 
 Note that systemctl show and systemctl status have a similar
 relationship as machinectl show and machinectl status.
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

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

Re: [systemd-devel] /etc/resolv.conf link in container

[Johannes Ernst]

 On Jun 17, 2015, at 1:07, David Herrmann dh.herrm...@gmail.com wrote:
 
 Hi
 
 On Tue, Jun 16, 2015 at 11:39 PM, Johannes Ernst
 johannes.er...@gmail.com wrote:
 I have a root filesystem in directory foo/
 It has symlink
foo/etc/resolv.conf - /run/systemd/resolve/resolv.conf
 
 When I’m booting the container:
sudo systemd-nspawn --directory foo --boot
 
 I’m getting:
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many 
 levels of symbolic links
 
 This message makes very little sense to me. Why is a copy necessary? and is 
 that indeed /etc/resolv.conf or foo/etc/resolv.conf?
 
 If I boot with -n, I don’t seem to get the error.
 
 If you pass --private-network / -n, then we never touch resolv.conf.
 In all other cases, we copy resolv.conf from the host into the
 container. We usually assume that if your container runs in the same
 network as the host, then the container must also use the DNS features
 of the host.
 
 The error code of Too many levels of symbolic links is ELOOP. This
 is returned by open() in many cases. In this example, it is returned
 because we passed O_NOFOLLOW to open(), but the final part of the path
 is a symlink. In that case, the kernel returns ELOOP to tell us that
 we're dealing with a symlink.
 
 Maybe Lennart or Tom have some comments on that? Your example use-case
 (resolved in the container, even with shared network namespace) looks
 valid, though odd. I mean, what's the reason not to use -n”?

Well, if there isn’t a reason, why does the mode exist?

 Anyway,
 maybe we can deal with ELOOP in setup_resolv_conf() and just print a
 big fat warning?
 But lets people who know that stuff comment first..
 
 Thanks
 David

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

Re: [systemd-devel] machinectl status vs show

[Johannes Ernst]

 On Jun 17, 2015, at 14:09, Lennart Poettering lenn...@poettering.net wrote:
 
 On Wed, 17.06.15 13:34, Johannes Ernst (johannes.er...@gmail.com) wrote:
 
 2. So how do I get at the IP address of the container in a way that
 is easily parseable?
 
 make sure nss-mymachines is installed and enabled (see its man page
 for details). With that in place the container name is resolvable
 using normal libc calls, i.e. ping containername will work then,
 and all other commands too.
 
 Use getent hosts foobar to resolve hostnames from the command line,
 in a generic, parsable way. It will then work both for containers as
 well as for any other kind of host name.

Duh. In hindsight, that’s sort of obvious, sorry for missing it.

[[Meta-comment: I’m finding that systemd is a rather amazing set of 
technologies, doing much more than is generally known. It’s all very nicely 
integrated, too, BUT: for somebody like me who doesn’t live on the inside of 
the project, it's not obvious how things fit together or are intended to be 
used, so they ask silly questions on the mailing list like I have been doing.

I wonder whether one of the Linux magazines would be interested in doing a 
“following systemd” kind of regular piece in which they would go through one 
use case after another with full shell transcripts, depending on what’s new 
this month. Or does that exist already?]]

/musing out loud

Thanks for the help,


Johannes.

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

[systemd-devel] /etc/resolv.conf link in container

[Johannes Ernst]

I have a root filesystem in directory foo/
It has symlink
foo/etc/resolv.conf - /run/systemd/resolve/resolv.conf

When I’m booting the container:
sudo systemd-nspawn --directory foo --boot

I’m getting:
Failed to copy /etc/resolv.conf to /home/…./foo/etc/resolv.conf: Too many 
levels of symbolic links

This message makes very little sense to me. Why is a copy necessary? and is 
that indeed /etc/resolv.conf or foo/etc/resolv.conf?

If I boot with -n, I don’t seem to get the error.

Puzzled.



Johannes.


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

[systemd-devel] nspawn --ephemeral

[Johannes Ernst]

I have a root filesystem directory in foo/

I boot with nspawn, and immediately, in the container:
systemctl poweroff

This works fine if invoked as:
sudo systemd-nspawn --directory foo --boot -n

But if I add --ephemeral (and it is a btrfs filesystem)
sudo systemd-nspawn --directory foo --boot -n --ephemeral
I get:
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Powering off.
Container ... has been shut down.
Cannot remove subvolume '/home/.../.#foo...', ignoring: Directory not empty

btrfs subvolume list reports two new subvolumes:
…/.#foo...
…/.#foo.../var/lib/machines

Indeed I cannot remove subvol …/.#foo… unless I first remove subvol 
…/.#foo.../var/lib/machines

Further, foo/ does not actually contain /var/lib/machines
but in the booted container, it actually lists two subvolumes with that path:
# btrfs subvolume list /
ID 351 gen 250192 top level 5 path var/lib/machines
ID 371 gen 256382 top level 5 path home/…/.#foo
ID 372 gen 256382 top level 371 path var/lib/machines
On the host, we have the same, but the second one has the prefix i.e. 
home/…/.#foo/var/lib/machines

Hmm …?


Johannes.

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

Re: [systemd-devel] nspawn --ephemeral

[Johannes Ernst]

Aha! Works in 220. (It’s still in testing in Arch, so I had been on 219)

I’m still unclear why there’s an (empty) /var/lib/machines in the container.

 On Jun 16, 2015, at 15:22, Lennart Poettering lenn...@poettering.net wrote:
 
 On Tue, 16.06.15 14:53, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 I have a root filesystem directory in foo/
 
 I boot with nspawn, and immediately, in the container:
systemctl poweroff
 
 This works fine if invoked as:
sudo systemd-nspawn --directory foo --boot -n
 
 But if I add --ephemeral (and it is a btrfs filesystem)
sudo systemd-nspawn --directory foo --boot -n --ephemeral
 I get:
Sending SIGTERM to remaining processes...
Sending SIGKILL to remaining processes...
Powering off.
Container ... has been shut down.
Cannot remove subvolume '/home/.../.#foo...', ignoring: Directory not 
 empty
 
 btrfs subvolume list reports two new subvolumes:
…/.#foo...
…/.#foo.../var/lib/machines
 
 Indeed I cannot remove subvol …/.#foo… unless I first remove subvol 
 …/.#foo.../var/lib/machines
 
 Further, foo/ does not actually contain /var/lib/machines
 but in the booted container, it actually lists two subvolumes with that path:
# btrfs subvolume list /
ID 351 gen 250192 top level 5 path var/lib/machines
ID 371 gen 256382 top level 5 path home/…/.#foo
ID 372 gen 256382 top level 371 path var/lib/machines
 On the host, we have the same, but the second one has the prefix i.e. 
 home/…/.#foo/var/lib/machines
 
 Hmm …?
 
 Do you use systemd v220? only in v220 we support recursively removing
 subvolumes, and there's a tmpfiles snippet that creates
 /var/lib/machines as subvolume.
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

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

[systemd-devel] machinectl status vs show

[Johannes Ernst]

Are those supposed to produce the same information, just formatted differently 
(man vs machine per man page)?

I’m failing to convince ‘show’ to give me the container’s IP address, while 
‘status’ has all of them.

Cheers,


Johannes.


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

Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade

[Johannes Ernst]

 On Jun 15, 2015, at 11:32, Lennart Poettering lenn...@poettering.net wrote:
 
 On Mon, 15.06.15 10:39, Johannes Ernst (johannes.er...@gmail.com) wrote:
 
 
 On Jun 15, 2015, at 10:33, Lennart Poettering lenn...@poettering.net 
 wrote:
 
 On Mon, 15.06.15 10:32, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 
 On Jun 14, 2015, at 15:27, Lennart Poettering lenn...@poettering.net 
 wrote:
 
 On Fri, 12.06.15 17:32, Johannes Ernst (johannes.er...@gmail.com) wrote:
 
 * host and container can ping test (if test is the name of the
 * container machine per machinectl): FAILS, neither can
 
 Do you have nss-mymachines enabled in /etc/nsswitch.conf?
 
 Yes:
 
 Does pinging via the IP addresses work? 
 
 Yes. Both container-host and host-container.
 
 On host:
 machinectl
 MACHINE CLASS SERVICE
 foo container nspawn 
 
 1 machines listed.
 ping foo
 ping: unknown host foo
 cat /etc/nsswitch.conf 
 hosts: nss-mymachines files mdns_minimal [NOTFOUND=return] dns
 myhostname
 
 Ah, heh, try mymachines instead of nss-mymachines... Also see
 nss-mymachines(8) man page. That should fix your issue.

Magic! It’s working! Thank you.


 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

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

Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade

[Johannes Ernst]

 On Jun 14, 2015, at 15:27, Lennart Poettering lenn...@poettering.net wrote:
 
 On Fri, 12.06.15 17:32, Johannes Ernst (johannes.er...@gmail.com) wrote:
 
 * host and container can ping test (if test is the name of the
 * container machine per machinectl): FAILS, neither can
 
 Do you have nss-mymachines enabled in /etc/nsswitch.conf?

Yes:

 Does pinging via the IP addresses work? 

Yes. Both container-host and host-container.

On host:
 machinectl
MACHINE CLASS SERVICE
foo container nspawn 

1 machines listed.
 ping foo
ping: unknown host foo
 cat /etc/nsswitch.conf 
hosts: nss-mymachines files mdns_minimal [NOTFOUND=return] dns myhostname

(or with just nss-mymachines)

Thanks for your help,


Johannes.

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

Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade

[Johannes Ernst]

 On Jun 15, 2015, at 10:33, Lennart Poettering lenn...@poettering.net wrote:
 
 On Mon, 15.06.15 10:32, Johannes Ernst (johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com) wrote:
 
 
 On Jun 14, 2015, at 15:27, Lennart Poettering lenn...@poettering.net 
 wrote:
 
 On Fri, 12.06.15 17:32, Johannes Ernst (johannes.er...@gmail.com) wrote:
 
 * host and container can ping test (if test is the name of the
 * container machine per machinectl): FAILS, neither can
 
 Do you have nss-mymachines enabled in /etc/nsswitch.conf?
 
 Yes:
 
 Does pinging via the IP addresses work? 
 
 Yes. Both container-host and host-container.
 
 On host:
 machinectl
 MACHINE CLASS SERVICE
 foo container nspawn 
 
 1 machines listed.
 ping foo
 ping: unknown host foo
 cat /etc/nsswitch.conf 
 hosts: nss-mymachines files mdns_minimal [NOTFOUND=return] dns myhostname
 
 Does machinectl status show the IP addresses of the container in its
 output?

Yes:

 sudo machinectl status foo
   Since: Mon 2015-06-15 17:27:33 UTC; 9min ago
  Leader: 31137 (systemd)
 Service: nspawn; class container
Root: 
/home/buildmaster/git/github.com/uboslinux/ubos-buildconfig/repository/dev/x86_64/images/ubos_dev_container-pc_20150614-054626
   Iface: ve-foo
 Address: 10.0.0.2
  169.254.169.115
  OS: UBOS

(UBOS: for our purposes here: same as Arch)


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

[systemd-devel] Scripting a server test

[Johannes Ernst]

This is a best-practice question.

I’d like to automate testing of a web application (running in a container) by 
running curl from the host. The logical sequence should be:

* boot container using local tar file or existing directory
* wait until container is-system-running=true
* on the container, execute a few commands
* on the host, run curl against the container
* tear down the container

I need to boot the container, and the image I need to use for this test brings 
up a login prompt at the console.

I’m thinking of doing something like:
 machinectl import-tar foo.tar foo
 machinectl start foo
 ssh foo systemctl is-system-running
until satisfied
 ssh foo some other commands
 curl http://foo/ http://foo/…
 machinectl poweroff foo
 machinectl status foo
until off

But I don’t like the “container import and registration” part of this, because 
my container is very ephemeral and might only live for a few minutes if the 
test passes.

Alternatively I could create myself a “test@.service” which would be identical 
to systemd-nspawn@.service, except it would use the directory as the %I instead 
of the machine name, so I could start it like:
 systemctl start test@/my/container/directory

Or I could fork off the systemctl-nspawn command in my test script.

Opinions? I figure this is a common-enough scenario that there might be some 
opinions on this list ...

Cheers,



Johannes.

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

Re: [systemd-devel] Understanding DHCP, DNS and IPMasquerade

[Johannes Ernst]

 On Jun 13, 2015, at 2:33, joerg.syst...@higgsboson.tk 
 mailto:joerg.syst...@higgsboson.tk wrote:
 
 13. Juni 2015 02:32 Uhr, Johannes Ernst johannes.er...@gmail.com 
 mailto:johannes.er...@gmail.com schrieb:
 
 My host obtains an IP address and DNS server via DHCP from upstream via 
 Ethernet like this (systemd
 219, Arch Linux)
 
 [Match]
 Name=en*
 
 [Network]
 DHCP=ipv4
 
 It has the resolv.conf symlink to /run/systemd/resolve/resolv.conf, and the 
 DNS server from DHCP
 shows up there.
 
 It also has this test.network file:
 
 [Match]
 Name=ve-*
 
 [Network]
 Address=0.0.0.0/28
 IPMasquerade=yes
 IPv4LL=yes
 DHCPServer=yes
 IPForward=yes
 
 My host runs a container like this: (systemd 219, UBOS (just like Arch 
 Linux))
 
 systemd-nspawn -b -D test -n
 
 The container does not have any networkd configuration. It has the 
 resolv.conf symlink, and runs
 systemd-networkd
 
 I was expecting:
 * container gets an IP address from host in some new subnet: WORKS, e.g 
 10.0.0.2
 * container can route to upstream via IPMasquerade: WORKS, after manual 
 'modprobe iptable_nat'
 * container gets the DNS server from the host: FAILS: /etc/resolv.conf 
 points to Google name
 servers instead (8.8.8.8 etc)
 * host and container can ping test (if test is the name of the container 
 machine per machinectl):
 FAILS, neither can
 
 What am I misunderstanding or doing wrong? If somebody educates me, I’ll put 
 the insights on a wiki
 somewhere (e.g. Arch)
 
 Hi, you need to configure the networkd inside your container to issue 
 DHCP-Request on its own
 interface,
 like you did on the host:
 
 [Match]
 Type=ethernet
 
 [Network]
 DHCP=ipv4

I did. No change. I do receive the IP address (so DHCP IP assignment is 
working) but I do not receive the DNS server.


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

[systemd-devel] Understanding DHCP, DNS and IPMasquerade

[Johannes Ernst]

My host obtains an IP address and DNS server via DHCP from upstream via 
Ethernet like this (systemd 219, Arch Linux)

[Match]
Name=en*

[Network]
DHCP=ipv4

It has the resolv.conf symlink to /run/systemd/resolve/resolv.conf, and the DNS 
server from DHCP shows up there.

It also has this test.network file:

[Match]
Name=ve-*

[Network]
Address=0.0.0.0/28
IPMasquerade=yes
IPv4LL=yes
DHCPServer=yes
IPForward=yes

My host runs a container like this: (systemd 219, UBOS (just like Arch Linux))

systemd-nspawn -b -D test -n

The container does not have any networkd configuration. It has the resolv.conf 
symlink, and runs systemd-networkd

I was expecting:
 * container gets an IP address from host in some new subnet: WORKS, e.g 
10.0.0.2
 * container can route to upstream via IPMasquerade: WORKS, after manual 
'modprobe iptable_nat'
 * container gets the DNS server from the host: FAILS: /etc/resolv.conf points 
to Google name servers instead (8.8.8.8 etc)
 * host and container can ping test (if test is the name of the container 
machine per machinectl): FAILS, neither can

What am I misunderstanding or doing wrong? If somebody educates me, I’ll put 
the insights on a wiki somewhere (e.g. Arch)

Thanks,


Johannes.

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