[systemd-devel] [systemd.link] How to use NamePolicy=mac?
Reading rules file: /usr/lib/udev/rules.d/10-dm.rules Reading rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules Reading rules file: /usr/lib/udev/rules.d/13-dm-disk.rules Reading rules file: /usr/lib/udev/rules.d/42-usb-hid-pm.rules Reading rules file: /usr/lib/udev/rules.d/50-firmware.rules Reading rules file: /usr/lib/udev/rules.d/50-udev-default.rules Reading rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules Reading rules file: /usr/lib/udev/rules.d/60-drm.rules Reading rules file: /usr/lib/udev/rules.d/60-keyboard.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-input.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-serial.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules Reading rules file: /usr/lib/udev/rules.d/61-accelerometer.rules Reading rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules Reading rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules Reading rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules Reading rules file: /usr/lib/udev/rules.d/70-power-switch.rules Reading rules file: /usr/lib/udev/rules.d/70-uaccess.rules Reading rules file: /usr/lib/udev/rules.d/71-seat.rules Reading rules file: /usr/lib/udev/rules.d/73-seat-late.rules Reading rules file: /usr/lib/udev/rules.d/75-net-description.rules Reading rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules Reading rules file: /usr/lib/udev/rules.d/75-tty-description.rules Reading rules file: /usr/lib/udev/rules.d/78-sound-card.rules Reading rules file: /usr/lib/udev/rules.d/80-drivers.rules Reading rules file: /usr/lib/udev/rules.d/80-net-setup-link.rules Reading rules file: /usr/lib/udev/rules.d/95-dm-notify.rules Reading rules file: /usr/lib/udev/rules.d/95-udev-late.rules Reading rules file: /usr/lib/udev/rules.d/99-systemd.rules Reading rules file: /etc/udev/rules.d/raspberrypi.rules rules contain 24576 bytes tokens (2048 * 12 bytes), 11452 bytes strings 1734 strings (21255 bytes), 1151 de-duplicated (10387 bytes), 584 trie nodes used set children_max to 10 ^Cvalidate module index Check if link configuration needs reloading. unload module index Unloaded link configuration context. So question: how can I use the given ID_NET_NAME and get rid at vitam eternam of 'eth0'? This would be useful for services that require an interface name (e.g. Wpa_supplicant). The behavior is the same on my laptop (eth0 instead of enxmac; wlan0 instead of wlxmac); however, I don't have the output of the last commands to share. Best regards, -- Moviuro @ PsychoticDelirium Our life is the immortals' death. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore
On Friday 29 August 2014 15:00:06 you wrote: On Thu, Aug 28, 2014 at 5:27 PM, Moviuro movi...@gmail.com wrote: I'm using systemd 216 on Archlinux (uptodate). Everything worked fine at last boot (systemd 215, kernel 3.14.1) Here is my tap0.network: [Match] Name=tap0 [Network] DHCP=yes [Route] Gateway=10.3.16.1 Destination=10.3.14.0/24 [Route] Gateway=10.3.16.1 Destination=10.3.15.0/24 And the routes: % ip route show default via 192.168.1.1 dev wlan0 proto dhcp metric 1024 10.3.16.0/24 dev tap0 proto kernel scope link src 10.3.16.201 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.128 192.168.1.1 dev wlan0 proto dhcp scope link metric 1024 And relevant journal snippet: Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address 10.3.16.201/24 Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured **At this point I do have all my routes** **Shutdown begins** Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost -- Reboot -- Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address 192.168.1.128/24 via 192.168.1.1 Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address 10.3.16.201/24 Note that tap0 never becomes 'configured'. The man does not tell any changes in networkd configuration and my setup is 2 months old. What's happening (in case that was not obvious) is that your statically configured routes depend on the address received over DHCP to be configured before they are set up. The current code assumes that there are no such dependencies so does the static and dynamic setup independently (in parallel). I guess we should either support this explicitly, or verify the config up-front and fail with a clearer error message. Out of interest, is there some way you could get these routes out of your DHCP server (if the server sends routes we should set them up)? I mean, your current config would fail if your DHCP server configuration was changed, which does not sound ideal... Cheers, Tom So, actually, the VPN server should push the routes to me (just noticed indeed this strange workaroud I used). However, when the openvpn server pushes its routes, ip route add fails: openvpn@profile[6649]: /usr/bin/ip route add 10.3.14.0/24 via 10.3.16.1 openvpn@profile[6649]: ERROR: Linux route add command failed: external program exited with error status: 2 I'm looking into this issue. Cheers, -- Moviuro @ Schizophrenia Our life is the immortals' death signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-networkd doesn't add static routes anymore
Hi all, I'm using systemd 216 on Archlinux (uptodate). Everything worked fine at last boot (systemd 215, kernel 3.14.1) Here is my tap0.network: [Match] Name=tap0 [Network] DHCP=yes [Route] Gateway=10.3.16.1 Destination=10.3.14.0/24 [Route] Gateway=10.3.16.1 Destination=10.3.15.0/24 And the routes: % ip route show default via 192.168.1.1 dev wlan0 proto dhcp metric 1024 10.3.16.0/24 dev tap0 proto kernel scope link src 10.3.16.201 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.128 192.168.1.1 dev wlan0 proto dhcp scope link metric 1024 And relevant journal snippet: Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address 10.3.16.201/24 Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured **At this point I do have all my routes** **Shutdown begins** Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost -- Reboot -- Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address 192.168.1.128/24 via 192.168.1.1 Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address 10.3.16.201/24 Note that tap0 never becomes 'configured'. The man does not tell any changes in networkd configuration and my setup is 2 months old. Regards, -- Moviuro @ PsychoticDelirium Our life is the immortals' death. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore
After git bisect-ing (following dreisner's instructions on #systemd), I get the following info: 38de08a does not add static routes ccf1c02 systemd-networkd is broken (does not run) (crash) 54cba0b systemd-networkd is broken (does not run) (crash) 3c9b886 systemd-networkd is broken (does not run) (crash) 68ba387 systemd-networkd works as expected I can't help review the code as I know no C, but I hope that helps Cheers, On Thursday 28 August 2014 18:57:15 you wrote: So I downgraded to systemd 215-4 with the same kernel (3.16.1) and now I get my routes on tap0 as well as the 'tap0: link configured' message. Cheers, On Thursday 28 August 2014 17:27:12 you wrote: Hi all, I'm using systemd 216 on Archlinux (uptodate). Everything worked fine at last boot (systemd 215, kernel 3.14.1) Here is my tap0.network: [Match] Name=tap0 [Network] DHCP=yes [Route] Gateway=10.3.16.1 Destination=10.3.14.0/24 [Route] Gateway=10.3.16.1 Destination=10.3.15.0/24 And the routes: % ip route show default via 192.168.1.1 dev wlan0 proto dhcp metric 1024 10.3.16.0/24 dev tap0 proto kernel scope link src 10.3.16.201 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.128 192.168.1.1 dev wlan0 proto dhcp scope link metric 1024 And relevant journal snippet: Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network is unreachable Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address 10.3.16.201/24 Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured **At this point I do have all my routes** **Shutdown begins** Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost -- Reboot -- Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address 192.168.1.128/24 via 192.168.1.1 Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a nonexistent link, ignoring Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network is unreachable Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address 10.3.16.201/24 Note that tap0 never becomes 'configured'. The man does not tell any changes in networkd configuration and my setup is 2 months old. Regards, -- Moviuro @ PsychoticDelirium Our life is the immortals' death. -- Moviuro @ Schizophrenia Our life is the immortals' death signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unit to test if a domain is reachable
Hi all! Since (from my understanding) systemd devel team did not want to interpret nor force its interpretation of network availability on systemd consumers, we have to use some other services and cross fingers (network.target, systemd- networkd-wait-online.service and so on). However, everything I tried proved an utter failure: target says reached even though it doesn't even have an IP on any link; wait-online obviously didn't even check if I had a DNS whatsoever. In the end, I had to write my own (ugly) service to test if a domain is reachable: /etc/systemd/system/reachable-retry@.service [Unit] Description=Test if %i is reachable # I'm not even sure it's useful, because it doesn't do its job After=systemd-networkd-wait-online.service [Service] Type=forking ExecStart=/usr/bin/ping -c1 %i Restart=on-failure # Needed, else the unit just goes crazy # if there are no links and systemd stops it RestartSec=2 # I don't know if the [Install] part is needed [Install] WantedBy=multi-user.target This works but using the Type=forking is an ugly hack: the result I'm waiting for would be: o Call reachable-retry@ in a unit (Requires and After); o If it fails, try again (seems OK with the Restart directive); o If it succeeds, the unit that needs to reach %i gets launched and my reachable-retry@ *does not* enter SUCCESS or whatever good state you can think of: it just stays asleep until someone else wants to recheck later if the domain is still reachable (e.g. domain goes down, my ISP goes crazy, I suspend my computer...). An other unit I could use would be reachable@ that would simply test whether or not a domain is reachable and: o In case it isn't, prevent a unit from being launched, period. o In case it is, launch the unit and don't enter any SUCCESS or good state. o If an other unit needs to test afterwards, launch the test again. Would Type=oneshot do that? Any input would be greatly appreciated. The issue was also a bit discussed here: https://bbs.archlinux.org/viewtopic.php?id=182717 And here too (in French): https://forums.archlinux.fr/topic15485.html Cheers, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit to test if a domain is reachable
On Thursday 17 July 2014 12:12:22 you wrote: Why not just use network-online.target? http://www.freedesktop.org/software/systemd/man/systemd.special.html#network -online.target o If it succeeds, the unit that needs to reach %i gets launched and my reachable-retry@ *does not* enter SUCCESS or whatever good state you can think of: it just stays asleep until someone else wants to recheck later if the domain is still reachable (e.g. domain goes down, my ISP goes crazy, I suspend my computer...). network-online.target does not fulfill these requirements. It stays in SUCCESS across suspend/resume cycles. Therefore, it is *not* a correct indicator. -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tun/tap device
On Monday 30 June 2014 22:23:30 Susant Sahani wrote: This patch introduces TUN/TAP device creation support to networkd. Example conf to create a tap device: file: tap.netdev -- [NetDev] Name=tap-test Kind=tap [Tap] OneQueue=true MultiQueue=true PacketInfo=true -- The man page at : http://www.freedesktop.org/software/systemd/man/systemd.netdev.html Does not mention tun and tap as netdev kinds: 'The netdev kind. Currently, bridge, bond, vlan, macvlan, vxlan, ipip, gre, sit, vti, veth, and dummy are supported. This option is compulsory.' -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tun/tap device
On Thursday 03 July 2014 23:59:03 you wrote: On Monday 30 June 2014 22:23:30 Susant Sahani wrote: This patch introduces TUN/TAP device creation support to networkd. Example conf to create a tap device: file: tap.netdev -- [NetDev] Name=tap-test Kind=tap [Tap] OneQueue=true MultiQueue=true PacketInfo=true -- The man page at : http://www.freedesktop.org/software/systemd/man/systemd.netdev.html Does not mention tun and tap as netdev kinds: 'The netdev kind. Currently, bridge, bond, vlan, macvlan, vxlan, ipip, gre, sit, vti, veth, and dummy are supported. This option is compulsory.' The according patch would be (correct me if I'm wrong, first time asking to patch on a ML) (git clone-d systemd, did the little modification, asked for git diff): diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index c90bd8f..4755262 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -162,7 +162,8 @@ literalbond/literal, literalvlan/literal, literalmacvlan/literal, literalvxlan/literal, literalipip/literal, literalgre/literal, -literalsit/literal, literalvti/literal, +literalsit/literal, literaltap/literal, +literaltun/literal, literalvti/literal, literalveth/literal, and literaldummy/literal are supported. This option is compulsory./para /listitem Regards, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Multiple template parameters for one service
Hi all, I am at the moment trying to clean up my units to write some simple ones that I just have to link without hardcoding anything in them but am stuck at this issue: what to do if my unit requires multiple parameters? E.g. Using unison to sync files, the different variables I have to use are: local user and profile file (an optional variable would be the server). It is at the moment not possible to write a unit file that would understand so many things with just a simple '@'. I could use an extra configuration file in /etc/systemd/system every time I want to use unison, but it's not really nice and clean (one file per unison profile...). Some people would object that I can have a bash script do the job of translating what is behind the '@' into my many arguments: not really nice either. An idea would be to use units with many '@' or have systemd interpret the string between '@' and '.service' as '@'-separated values (e.g. unison@local_user@profile.service). The feature could also help by including some optional arguments (e.g. the server information in unison is not necessary for it to work but could help if I use a service to check if the server is online beforehand: unison@local_user@profile@server.service). Cheers, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple template parameters for one service
On Sunday 29 June 2014 00:21:33 you wrote: You could just use /etc/systemd/system/unison@instance.service.d/ directory to provide service environment variables, this seems to be much more convenient way to configure service. I can't do that because different users may have the same profile name (and thus the same configuration folder). (I wanted to avoid it but, here is the unit) [Unit] Description=Unison sync for profile PROFILE Requires=reachable-retry@SERVER.service After=reachable-retry@SERVER.service [Service] User=LOCAL_USER ExecStart=/usr/bin/unison -auto -silent PROFILE I can't put the full path to the PROFILE as unison@/path/to/profile.service because I can't put '/' in a file name. Cheers, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
