Re: [systemd-devel] [PATCH] fstab-generator: do not check btrfs and xfs
On Mon, 30.06.14 00:10, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote: This sounds really unnecessary, no? We already have fsck_exists() in place that since a very recent commit of mine even detects a per-fstype fsck implementation being linked to /bin/true... I also downgraded all warnings for cases like that to LOG_DEBUG, hence the xfs/btrfs case should already be covered nicely, and fully generic... Why do we need another explicit blacklist on top of that? True. But this requires additional effort from the initramfs generator and from the distribution to remember to install the symlink. Well, whether they install a symlink or whether they ship nothing at all, both is fine. They just shouldn't install a tool that prints a warning. We already have a list of network filesystems, this just another one which is actually much easier to manager since new local filesystems with automatic repair don't come that often. Just because we had to add an awful hack to deal with the networking mess (where I really don't know a better alternative), doesn't mean we have to add one more here. The nicer option appears to me is to talk to xfs and btrfs upstream and ask them to either change their fsck to a symlink to /bin/true or to remove it altogether. Because otherwise we cannot detect whether fscking is actually necessary. I'd just reassign all bug reports popping up to their respective utilities asking them to fix this, and giving us a sane API to detct wether fsck is necessary or not. And that sane API should be to to install that symlink or nothing at all. IMHO both xfs and btrfs should just not ship a fsck helper at all, not even as a symlink. This workaround made sense at some point, but now I believe both systemd _and_ fsck itself can deal gracefully with a missing fsck helper. IMHO, this shows that using fstab-generator to shortcuit the whole discussion who is right and what is the proper way to say that the fs should not be checked seems like a good idea ;) Wel, out of a matter of principle, I'd always try to fix things upstream and properly where the problems lie, instead of taping over them. In particular since btrfs upstream so far has always been nice to us... 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] [PATCH 0/3] move timeout handling out of the core
On Sat, 28.06.14 06:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Heya, this patch series continues the trend of moving stuff out of the core into generators. As a prerequisite for 3/3, it was necessary to move some code from core to shared. If comments are not counted, series is line-count-wise neutral, but I think it makes things cleaner and easier to introspect. I think I agree with this. The only reason I could think of why this might not be the right thing to do is to be nice to folks who wrote native mount units who want to use the mount option. Because this way the mount option becomes specific to fstab and cannot be used otherwise... (Which actually is exactly what we do for x-systemd.automount, which makes this all feel quite OK) I never liked the patching of the device unit's timeout the way we so far did. I feel quite a bit more comfortable with the way you propose as we never patch, we always have readable files in the fs... Anyway, looks good to me. We need to document though that both x-sytemd.automount and x-systemd.device-timeout= strictly only work in fstab and not otherwise. Zbigniew Jędrzejewski-Szmek (3): 1/3 Move x-systemd-device.timeout handling from core to fstab-generator 2/3 fstab-generator: allow x-systemd.device-timeout for swap units 3/3 cryptsetup: allow x-systemd.device-timeout Makefile.am | 8 ++- src/core/mount.c | 55 -- src/core/unit.c | 70 ++- src/cryptsetup/cryptsetup-generator.c | 25 - src/fstab-generator/fstab-generator.c | 17 +- src/shared/dropin.c | 102 ++ src/shared/dropin.h | 31 +++ src/shared/generator.c| 66 ++ src/shared/generator.h| 3 + src/shared/path-lookup.h | 2 + 10 files changed, 264 insertions(+), 115 deletions(-) create mode 100644 src/shared/dropin.c create mode 100644 src/shared/dropin.h 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] Multiple template parameters for one service
On Sat, 28.06.14 18:15, Moviuro (movi...@gmail.com) wrote: 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). Hummm... So far the instancing was strictly one-dimensional from systemd's PoV. And I think I would prefer it like that, since it makes so many things easier. I mean, as you notice, one can always parse this from shell or so, if you want, so we can actually get away with not supporting anything more complex with systemd. (Note that specifically using this for running things as unpriviliged normal users: I'd encourage you not to do this with system-level services, but instead run this as user services, from the systemd user instance. Of course, the work on thta isn't complete yet, but it definitely sounds like the more correct option for the long run). Sorry, 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] [PATCH] tests: add missing XDG_RUNTIME_DIR env variable
On Wed, 11.06.14 21:20, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
Otherwise the test fails because specifier_runtime() returns -ENOTSUP
when XDG_RUNTIME_DIR is not set.
Thanks! Applied!
---
src/test/test-unit-name.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/test/test-unit-name.c b/src/test/test-unit-name.c
index fff3e16..bff4319 100644
--- a/src/test/test-unit-name.c
+++ b/src/test/test-unit-name.c
@@ -145,6 +145,7 @@ static int test_unit_printf(void) {
assert_se(setenv(USER, root, 1) == 0);
assert_se(setenv(HOME, /root, 1) == 0);
+assert_se(setenv(XDG_RUNTIME_DIR, /run/user/1/, 1) == 0);
assert_se(u = unit_new(m, sizeof(Service)));
assert_se(unit_add_name(u, blah.service) == 0);
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] systemd-networkd-wait-online and network.target
On Sun, 29.06.14 23:58, Tom Gundersen (t...@jklm.no) wrote: On Wed, Jun 25, 2014 at 12:12 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: Commit 58e027023b47b32e42cf93dd4a629b869ee1ef25 'units: order network-online.target after network.target' added Before=network.target dependency to systemd-networkd-wait-online.service. Is that correct? If I understand the documentation correctly, then network.target should not be delayed. Maybe this was supposed to be Afternetwork.target? Looks like a bug to me. Reverted that hunk. You forgot to push? 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] Multiple template parameters for one service
On Mon, Jun 30, 2014 at 1:38 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 28.06.14 18:15, Moviuro (movi...@gmail.com) wrote: 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). Hummm... So far the instancing was strictly one-dimensional from systemd's PoV. And I think I would prefer it like that, since it makes so many things easier. I mean, as you notice, one can always parse this from shell or so, if you want, so we can actually get away with not supporting anything more complex with systemd. (Note that specifically using this for running things as unpriviliged normal users: I'd encourage you not to do this with system-level services, but instead run this as user services, from the systemd user instance. Of course, the work on thta isn't complete yet, but it definitely sounds like the more correct option for the long run). User services work quite well for such things already, only the X11 and DBus session-bus access is still problematic. Should be fine for Unison. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd-wait-online and network.target
On Mon, Jun 30, 2014 at 1:04 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 29.06.14 23:58, Tom Gundersen (t...@jklm.no) wrote: On Wed, Jun 25, 2014 at 12:12 PM, Michael Olbrich m.olbr...@pengutronix.de wrote: Commit 58e027023b47b32e42cf93dd4a629b869ee1ef25 'units: order network-online.target after network.target' added Before=network.target dependency to systemd-networkd-wait-online.service. Is that correct? If I understand the documentation correctly, then network.target should not be delayed. Maybe this was supposed to be Afternetwork.target? Looks like a bug to me. Reverted that hunk. You forgot to push? Indeed. Done. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regression in a4a878d0 (units: introduce network-pre.target...)
On Sun, 29.06.14 16:25, Tom Gundersen (t...@jklm.no) wrote: On Sat, Jun 28, 2014 at 6:36 AM, Gerardo Exequiel Pozzi vmlinuz...@gmail.com wrote: Looks like this commit also changes a unrelated file (units/local-fs.target) reverting the commit 40f862e3 (filesystem targets: disable default dependencies) The side effect, at least in my case is that the nofail option in both crypttab and fstab has partial effect does the default timeout instead of continue normal boot without timeout. Looks like a bug, so I reverted that hunk. Lennart, care to double check? Humm, not following here. Quite frankly I don't even understand 40f862e3... It soudns like a hack to disable defaultdeps on the targets, just so that we can leave them set for mount units. I mean, why would mount units be pulled in by local-fs.target, without being ordered before them? And if that's OK, then why aren't they the ones that get defaultdependencies=no? Can somebody who made the commit 40f862e3 tell me what that was about? I'd like to revert this, looks really wrong to me. 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] regression in a4a878d0 (units: introduce network-pre.target...)
On Sat, 28.06.14 01:36, Gerardo Exequiel Pozzi (vmlinuz...@gmail.com) wrote: Hello Looks like this commit also changes a unrelated file (units/local-fs.target) reverting the commit 40f862e3 (filesystem targets: disable default dependencies) The side effect, at least in my case is that the nofail option in both crypttab and fstab has partial effect does the default timeout instead of continue normal boot without timeout. Not following here. Any idea why that commit should have resulted in this? (And before we revert these things, can we please try to figure out what really is happening here? Don't grok this at all...) 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] [PATCH] fstab-generator: do not check btrfs and xfs
On Mon, Jun 30, 2014 at 12:23:39PM +0200, Lennart Poettering wrote: [snip] The nicer option appears to me is to talk to xfs and btrfs upstream and ask them to either change their fsck to a symlink to /bin/true or to remove it altogether. Because otherwise we cannot detect whether fscking is actually necessary. I'd just reassign all bug reports popping up to their respective utilities asking them to fix this, and giving us a sane API to detct wether fsck is necessary or not. And that sane API should be to to install that symlink or nothing at all. Installing nothing at at all or a symlink to /bin/true increases the burder on the fs developers, because now they have to make an additional effort to educate people what it means. I just don't see that happening. But seems I'm the only one who likes the patch, let's forget about it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] move timeout handling out of the core
On Mon, Jun 30, 2014 at 12:33:18PM +0200, Lennart Poettering wrote: On Sat, 28.06.14 06:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Heya, this patch series continues the trend of moving stuff out of the core into generators. As a prerequisite for 3/3, it was necessary to move some code from core to shared. If comments are not counted, series is line-count-wise neutral, but I think it makes things cleaner and easier to introspect. I think I agree with this. The only reason I could think of why this might not be the right thing to do is to be nice to folks who wrote native mount units who want to use the mount option. Because this way the mount option becomes specific to fstab and cannot be used otherwise... (Which actually is exactly what we do for x-systemd.automount, which makes this all feel quite OK) Good catch. I didn't think about that. Maybe a middle ground of issuing a warning? I'll add some code which complains when the option is seen in a unit file. I never liked the patching of the device unit's timeout the way we so far did. I feel quite a bit more comfortable with the way you propose as we never patch, we always have readable files in the fs... Anyway, looks good to me. We need to document though that both x-sytemd.automount and x-systemd.device-timeout= strictly only work in fstab and not otherwise. OK. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] move timeout handling out of the core
On Mon, 30.06.14 14:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I think I agree with this. The only reason I could think of why this might not be the right thing to do is to be nice to folks who wrote native mount units who want to use the mount option. Because this way the mount option becomes specific to fstab and cannot be used otherwise... (Which actually is exactly what we do for x-systemd.automount, which makes this all feel quite OK) Good catch. I didn't think about that. Maybe a middle ground of issuing a warning? I'll add some code which complains when the option is seen in a unit file. I'd just document it. I mean, part of the reason for your patch is to remove this from the core, so it sounds wrong readding this this way. I'd just document it, and retain no further code for this in PID 1. Maybe if a thousand bugs get reported about this we can add a warning, but otherwise I'd really keep this clean. 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] [PATCH] localed: search locale settings on kernel cmdline first
On Mon, 02.06.14 18:03, Michal Sekletar (msekl...@redhat.com) wrote: Heya! Sorry for the late response! systemd spawns services with locale settings taken from kernel cmdline. If it doesn't find anything there, then it proceeds with parsing settings from /etc/locale.conf. localed should do the same and look at kernel cmdline first. Hmm, this would create the weird situation where changing the settings with localectl would have no effect on the settings it displays, right? It's a weird thing: on one hand we want the rule that kernel cmdline args override configuration in /etc. On the other we want that localectl to be both getter and setter for the settings, and connect them directly. Of course localectl cannot change the kernel cmdline. We could make localed refuse changing the settings if there's something on the kernel cmdline, but I think I'd hate that, since the admin should always be able to change the settings. Maybe another option is to improve localectl on the client side to simply warn the user if there's something on the kernel cmdline specified? (this check should probably test this directly, bypassing localed, and thus get skipped if localectl is used on a remote host). i.e. just a simple warning if you type localectl that says: Warning: Locale configuration has been specified on the kernel command line, overriding the system settings below. or so... Opinions? 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] [PATCH v2 3/3] nspawn: log a warning on failure from wait_for_terminate()
On Sun, 29.06.14 20:18, Luke Shumaker (luke...@sbcglobal.net) wrote:
This is at the suggestion of Djalal Harouni on the mailing list, and
reflects the behavior of shared/util.c:wait_for_terminate_and_warn().
Commited all three, and made a minor simplification afterwards.
Thanks!
---
src/nspawn/nspawn.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index be0e6b5..8fb72d6 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2666,8 +2666,10 @@ static int wait_for_container(pid_t pid,
ContainerStatus *container) {
siginfo_t status;
r = wait_for_terminate(pid, status);
-if (r 0)
+if (r 0) {
+log_warning(Failed to wait for container: %s,
strerror(-r));
return r;
+}
switch (status.si_code) {
case CLD_EXITED:
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] regression in a4a878d0 (units: introduce network-pre.target...)
On Mon, Jun 30, 2014 at 1:15 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 28.06.14 01:36, Gerardo Exequiel Pozzi (vmlinuz...@gmail.com) wrote: Hello Looks like this commit also changes a unrelated file (units/local-fs.target) reverting the commit 40f862e3 (filesystem targets: disable default dependencies) The side effect, at least in my case is that the nofail option in both crypttab and fstab has partial effect does the default timeout instead of continue normal boot without timeout. Not following here. Any idea why that commit should have resulted in this? (And before we revert these things, can we please try to figure out what really is happening here? Don't grok this at all...) Hm, I see why you don't like this. To take it from the beginning: nofail translates to not Before= and noauto translates to not Wants=. If we use default dependencies on both the target and the mount, then auto implies fail, which is no good as they should be independent. The reason we didn't just disable default depedencies for the affected mount units is that we would really like all the other default dependencies to apply, and we would not like to repeat this logic in all the generators (but rather rely on core sorting this all out). The hack that we ended up with is to disable the default deps on the mount targets. On further consideration, perhaps the better solution would have been to simply not make the Wants implies Before be a default depenedency for mount units? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd -- net.ipv4.ip_dynaddr requirement?
I noticed commit 68ceb9df6a39a7 says: sd-dhcp-client/networkd: set lifetimes for IPv4 addresses Note that /proc/sys/net/ipv4/ip_dynaddr needs to be non-zero. If I understand it correctly, the commit makes it so that IPv4 address lifetimes from DHCP show up as valid_lft X preferred_lft Y in `ip addr`. If that's the case, why the sysctl requirement, if the same information already shows up in `ip -4 addr` when set by NetworkManager, even though the sysctl has always been zero on my system? Also: I tried searching ~/src/linux/Documentation for ip_dynaddr, and it seems to be talking about IP address rewriting or masquerading, *not* lifetimes/expiry? Confused. -- Mantas Mikulėnas graw...@gmail.com ___ 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 Mon, 2014-06-30 at 12:38 +0200, Lennart Poettering wrote: On Sat, 28.06.14 18:15, Moviuro (movi...@gmail.com) wrote: 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). Hummm... So far the instancing was strictly one-dimensional from systemd's PoV. And I think I would prefer it like that, since it makes so many things easier. I mean, as you notice, one can always parse this from shell or so, if you want, so we can actually get away with not supporting anything more complex with systemd. Shouldn't just another '%x' format specifier or two for unit files be enough to get most of the benefit, without changing any of the underlying architecture? As in something like %?5? meaning interpret the instance name as a whatever-delimited list, and place the 5th element of the list here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: Introduce tun/tap device
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
--
Modifications:
Added:
1. file networkd-tuntap.c
3. netdev kind NETDEV_KIND_TUN and NETDEV_KIND_TAP
2. Tun and Tap Sections and config params to parse
conf and gperf conf parameters
TODO:
1. Add user(uid) group(gid) parameters
---
Makefile.am | 1 +
src/network/networkd-netdev-gperf.gperf | 6 ++
src/network/networkd-netdev.c | 34 ---
src/network/networkd-tuntap.c | 101
src/network/networkd.h | 7 +++
5 files changed, 142 insertions(+), 7 deletions(-)
create mode 100644 src/network/networkd-tuntap.c
diff --git a/Makefile.am b/Makefile.am
index bb85b2c..c947731 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4514,6 +4514,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-tunnel.c \
src/network/networkd-veth.c \
src/network/networkd-vxlan.c \
+ src/network/networkd-tuntap.c \
src/network/networkd-network.c \
src/network/networkd-address.c \
src/network/networkd-route.c \
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 9125e1d..38133c8 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -38,3 +38,9 @@ VXLAN.Group, config_parse_tunnel_address,
0,
VXLAN.TOS, config_parse_unsigned, 0,
offsetof(NetDev, tos)
VXLAN.TTL, config_parse_unsigned, 0,
offsetof(NetDev, ttl)
VXLAN.MacLearning, config_parse_bool, 0,
offsetof(NetDev, learning)
+Tun.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tun.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tun.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
+Tap.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tap.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tap.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
diff --git a/src/network/networkd-netdev.c b/src/network/networkd-netdev.c
index dcf7596..a25cb84 100644
--- a/src/network/networkd-netdev.c
+++ b/src/network/networkd-netdev.c
@@ -41,7 +41,9 @@ static const char* const netdev_kind_table[_NETDEV_KIND_MAX]
= {
[NETDEV_KIND_GRE] = gre,
[NETDEV_KIND_SIT] = sit,
[NETDEV_KIND_VETH] = veth,
-[NETDEV_KIND_VTI] = vti
+[NETDEV_KIND_VTI] = vti,
+[NETDEV_KIND_TUN] = tun,
+[NETDEV_KIND_TAP] = tap,
};
DEFINE_STRING_TABLE_LOOKUP(netdev_kind, NetDevKind);
@@ -221,6 +223,7 @@ static int netdev_enter_ready(NetDev *netdev) {
return 0;
}
+
static int netdev_create_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
NetDev *netdev = userdata;
int r;
@@ -521,11 +524,19 @@ int netdev_set_ifindex(NetDev *netdev, sd_rtnl_message
*message) {
return -EINVAL;
}
-if (!streq(kind, received_kind)) {
-log_error_netdev(netdev, Received newlink with wrong KIND %s,
- expected %s, received_kind, kind);
-netdev_enter_failed(netdev);
-return r;
+switch(netdev-kind) {
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+break;
+default:
+if (!streq(kind, received_kind)) {
+log_error_netdev(netdev,
+ Received newlink with wrong KIND %s,
+ expected %s, received_kind, kind);
+netdev_enter_failed(netdev);
+return r;
+}
+break;
}
netdev-ifindex = ifindex;
@@ -617,9 +628,10 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
netdev-vxlanid = VXLAN_VID_MAX + 1;
netdev-tunnel_pmtudisc = true;
netdev-learning = true;
+netdev-packet_info = true;
r = config_parse(NULL, filename, file,
- Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0,
+
Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0Tun\0Tap\0,
Re: [systemd-devel] networkd -- net.ipv4.ip_dynaddr requirement?
On Mon, Jun 30, 2014 at 6:14 PM, Mantas Mikulėnas graw...@gmail.com wrote: I noticed commit 68ceb9df6a39a7 says: sd-dhcp-client/networkd: set lifetimes for IPv4 addresses Note that /proc/sys/net/ipv4/ip_dynaddr needs to be non-zero. If I understand it correctly, the commit makes it so that IPv4 address lifetimes from DHCP show up as valid_lft X preferred_lft Y in `ip addr`. Correct. If that's the case, why the sysctl requirement, if the same information already shows up in `ip -4 addr` when set by NetworkManager, even though the sysctl has always been zero on my system? Also: I tried searching ~/src/linux/Documentation for ip_dynaddr, and it seems to be talking about IP address rewriting or masquerading, *not* lifetimes/expiry? Confused. Indeed, the commit message seems wrong. Patrik, care to comment? (he is on holiday, so don't expect an answer for another month or so :) ). Cheers, Tom ___ 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 06/25/2014 07:12 PM, Zbigniew Jędrzejewski-Szmek wrote:
-[NETDEV_KIND_VTI] = vti
+[NETDEV_KIND_VTI] = vti,
+[NETDEV_KIND_TUN] = tun,
+[NETDEV_KIND_TAP] = tap - Maybe add a comma here, to makes future
patches simpler
};
DEFINE_STRING_TABLE_LOOKUP(netdev_kind, NetDevKind);
@@ -221,6 +223,7 @@ static int netdev_enter_ready(NetDev *netdev) {
return 0;
}
+
static int netdev_create_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
NetDev *netdev = userdata;
int r;
@@ -521,11 +524,19 @@ int netdev_set_ifindex(NetDev *netdev, sd_rtnl_message
*message) {
return -EINVAL;
}
-if (!streq(kind, received_kind)) {
-log_error_netdev(netdev, Received newlink with wrong KIND %s,
- expected %s, received_kind, kind);
-netdev_enter_failed(netdev);
-return r;
+switch(netdev-kind) {
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+break;
+default:
+if (!streq(kind, received_kind)) {
+log_error_netdev(netdev,
+ Received newlink with wrong KIND %s,
+ expected %s, received_kind, kind);
+netdev_enter_failed(netdev);
+return r;
+}
+break;
}
netdev-ifindex = ifindex;
@@ -617,9 +628,10 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
netdev-vxlanid = VXLAN_VID_MAX + 1;
netdev-tunnel_pmtudisc = true;
netdev-learning = true;
+netdev-packet_info = true;
r = config_parse(NULL, filename, file,
- Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0,
+
Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0Tun\0Tap\0,
config_item_perf_lookup, (void*)
network_netdev_gperf_lookup,
false, false, netdev);
if (r 0) {
@@ -719,6 +731,14 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
if (r 0)
return r;
break;
+
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+r = netdev_create_tuntap(netdev);
+if (r 0)
+return r;
+break;
+
default:
break;
}
diff --git a/src/network/networkd-tuntap.c b/src/network/networkd-tuntap.c
new file mode 100644
index 000..7c1840c
--- /dev/null
+++ b/src/network/networkd-tuntap.c
@@ -0,0 +1,101 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+This file is part of systemd.
+
+Copyright 2014 Susant Sahani sus...@redhat.com
+
+systemd is free software; you can redistribute it and/or modify it
+under the terms of the GNU Lesser General Public License as published by
+the Free Software Foundation; either version 2.1 of the License, or
+(at your option) any later version.
+
+systemd is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public License
+along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include sys/ioctl.h
+#include net/if.h
+#include linux/if_tun.h
+
+#include networkd.h
+
+#define TUN_DEV /dev/net/tun
+
+
+static int netdev_fill_tuntap_message(NetDev *netdev, struct ifreq *ifr) {
+
+assert(netdev);
+assert(ifr);
+
+memset(ifr, 0, sizeof(*ifr));
+if(netdev-kind != NETDEV_KIND_TAP)
+ifr-ifr_flags |= IFF_TUN;
+else
+ifr-ifr_flags |= IFF_TAP;
+
+if(!netdev-packet_info)
+ifr-ifr_flags = ~IFF_NO_PI;
+else
+ifr-ifr_flags |= IFF_NO_PI;
Can the conditions in two if's above be reverted? It is easier to read
true conditions than !false.
Also add space between if and (.
/* gperf */
const struct ConfigPerfItem* network_netdev_gperf_lookup(const char *key,
unsigned length);
Look good.
Zbyszek
Addressed all the comments thanks .
--
Susant
___
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 Mon, 30.06.14 19:52, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Mon, 2014-06-30 at 12:38 +0200, Lennart Poettering wrote: On Sat, 28.06.14 18:15, Moviuro (movi...@gmail.com) wrote: 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). Hummm... So far the instancing was strictly one-dimensional from systemd's PoV. And I think I would prefer it like that, since it makes so many things easier. I mean, as you notice, one can always parse this from shell or so, if you want, so we can actually get away with not supporting anything more complex with systemd. Shouldn't just another '%x' format specifier or two for unit files be enough to get most of the benefit, without changing any of the underlying architecture? As in something like %?5? meaning interpret the instance name as a whatever-delimited list, and place the 5th element of the list here. Well, I am not thrilled by that idea, but I'd probably accept a patch that does this if it uses a very convincing syntax and doesn't try to be too generic. For example, it should enforce one clear separator syntax, and clearly map to %i and %I. 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] [PATCH] networkd: Introduce tun/tap device
On Mon, 30.06.14 22:23, Susant Sahani (sus...@redhat.com) wrote:
This patch introduces TUN/TAP device creation support
to networkd.
Please always also include the updates to the respective man pages that
document these settings in these patches! THanks!
Example conf to create a tap device:
file: tap.netdev
--
[NetDev]
Name=tap-test
Kind=tap
[Tap]
OneQueue=true
MultiQueue=true
PacketInfo=true
--
Modifications:
Added:
1. file networkd-tuntap.c
3. netdev kind NETDEV_KIND_TUN and NETDEV_KIND_TAP
2. Tun and Tap Sections and config params to parse
conf and gperf conf parameters
TODO:
1. Add user(uid) group(gid) parameters
---
Makefile.am | 1 +
src/network/networkd-netdev-gperf.gperf | 6 ++
src/network/networkd-netdev.c | 34 ---
src/network/networkd-tuntap.c | 101
src/network/networkd.h | 7 +++
5 files changed, 142 insertions(+), 7 deletions(-)
create mode 100644 src/network/networkd-tuntap.c
diff --git a/Makefile.am b/Makefile.am
index bb85b2c..c947731 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4514,6 +4514,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-tunnel.c \
src/network/networkd-veth.c \
src/network/networkd-vxlan.c \
+ src/network/networkd-tuntap.c \
src/network/networkd-network.c \
src/network/networkd-address.c \
src/network/networkd-route.c \
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 9125e1d..38133c8 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -38,3 +38,9 @@ VXLAN.Group, config_parse_tunnel_address,
0,
VXLAN.TOS, config_parse_unsigned, 0,
offsetof(NetDev, tos)
VXLAN.TTL, config_parse_unsigned, 0,
offsetof(NetDev, ttl)
VXLAN.MacLearning, config_parse_bool, 0,
offsetof(NetDev, learning)
+Tun.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tun.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tun.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
+Tap.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tap.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tap.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
diff --git a/src/network/networkd-netdev.c b/src/network/networkd-netdev.c
index dcf7596..a25cb84 100644
--- a/src/network/networkd-netdev.c
+++ b/src/network/networkd-netdev.c
@@ -41,7 +41,9 @@ static const char* const
netdev_kind_table[_NETDEV_KIND_MAX] = {
[NETDEV_KIND_GRE] = gre,
[NETDEV_KIND_SIT] = sit,
[NETDEV_KIND_VETH] = veth,
-[NETDEV_KIND_VTI] = vti
+[NETDEV_KIND_VTI] = vti,
+[NETDEV_KIND_TUN] = tun,
+[NETDEV_KIND_TAP] = tap,
};
DEFINE_STRING_TABLE_LOOKUP(netdev_kind, NetDevKind);
@@ -221,6 +223,7 @@ static int netdev_enter_ready(NetDev *netdev) {
return 0;
}
+
static int netdev_create_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
NetDev *netdev = userdata;
int r;
@@ -521,11 +524,19 @@ int netdev_set_ifindex(NetDev *netdev, sd_rtnl_message
*message) {
return -EINVAL;
}
-if (!streq(kind, received_kind)) {
-log_error_netdev(netdev, Received newlink with wrong KIND
%s,
- expected %s, received_kind, kind);
-netdev_enter_failed(netdev);
-return r;
+switch(netdev-kind) {
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+break;
+default:
+if (!streq(kind, received_kind)) {
+log_error_netdev(netdev,
+ Received newlink with wrong KIND
%s,
+ expected %s, received_kind, kind);
+netdev_enter_failed(netdev);
+return r;
+}
+break;
}
netdev-ifindex = ifindex;
@@ -617,9 +628,10 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
netdev-vxlanid = VXLAN_VID_MAX + 1;
netdev-tunnel_pmtudisc = true;
Re: [systemd-devel] [PATCH] networkd: Introduce tun/tap device
On 06/30/2014 11:03 PM, Lennart Poettering wrote: On Mon, 30.06.14 22:23, Susant Sahani (sus...@redhat.com) wrote: This patch introduces TUN/TAP device creation support to networkd. Please always also include the updates to the respective man pages that document these settings in these patches! THanks! Sure thanks . Lennart -- Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: +varlistentry +termfilename/usr/lib/filename/term +listitemparaSystem libraries and +package-specific +data./para/listitem +/varlistentry + +varlistentry +termfilename/usr/lib64/filename/term +listitemparaSecondary library +directory for placing 64bit versions +of system libraries in, if the primary +architecture of the system is +32bit. This directory should not be +used for package-specific data, unless +this data requires 64bit-specific +versions, too./para/listitem +/varlistentry So far systemd was agnostic to the details of this split. This makes this official, and conflicts with the Debian/Ubuntu camp. The multiarch layout is more flexible, so this seems backwards. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 8:38 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: +varlistentry +termfilename/usr/lib/filename/term +listitemparaSystem libraries and +package-specific +data./para/listitem +/varlistentry + +varlistentry +termfilename/usr/lib64/filename/term +listitemparaSecondary library +directory for placing 64bit versions +of system libraries in, if the primary +architecture of the system is +32bit. This directory should not be +used for package-specific data, unless +this data requires 64bit-specific +versions, too./para/listitem +/varlistentry So far systemd was agnostic to the details of this split. This makes this official, and conflicts with the Debian/Ubuntu camp. The multiarch layout is more flexible, so this seems backwards. It sounds like, yes. We should not specify the content of the lib64 directory. All we would need to run an ABI compliant x86_64 system is /lib64 - usr/lib/x86_64-linux-gnu/. What a mess, Fedora should just sort out its backwards and outdated lib64/ and libexec/ rules and everybody would benefit. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 20:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: +varlistentry +termfilename/usr/lib/filename/term +listitemparaSystem libraries and +package-specific +data./para/listitem +/varlistentry + +varlistentry + termfilename/usr/lib64/filename/term +listitemparaSecondary library +directory for placing 64bit versions +of system libraries in, if the primary +architecture of the system is +32bit. This directory should not be +used for package-specific data, unless +this data requires 64bit-specific +versions, too./para/listitem +/varlistentry So far systemd was agnostic to the details of this split. This makes this official, and conflicts with the Debian/Ubuntu camp. The multiarch layout is more flexible, so this seems backwards. I do agree that the Debian/Ubuntu design here sounds like the better design there than Fedora's lib64. But then again lib64 is encoded in the ELF ABI since the dynamic loader is located there. There's no way we can get rid of it. Note that the concept of lib64 is actually encoded in systemd now, since nspawn and PID 1 when switching roots will actually create /lib64 as symlink to /usr/lib64 should the latter exist. That scheme should be compatible with both Fedora's and Debin's multilib design. I tried to weasel myself out of the situation by clarifying that the the dir should only exist in case of the ABI requiring that. Not sure how we could improve the situation... Suggestions? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] mount units and symlinks
Hi, we were trying to update systemd to git master in gnome-continuous, and hit an issue with mount points that are symlinks. It's pretty easy to reproduce: mkdir /mnt/a ln -s a /mnt/b cat /etc/systemd/system/mnt-b.mount EOF [Mount] What=tmpfs Where=/mnt/b Type=tmpfs Options=mode=1777,strictatime EOF systemctl daemon-reload systemctl start mnt-b.mount # Notice that we can see this mount via *both* units: systemctl status mnt-a.mount systemctl status mnt-b.mount # Now let's do an unrelated mount: mkdir /mnt/unrelated mount --bind /mnt/unrelated /mnt/unrelated systemctl status mnt-a.mount systemctl status mnt-b.mount # Notice mnt-b died This happens because on any mountpoint change, we mark all mounts as dead, and only reload the ones we see. But the kernel resolved the b - a symlink at mount time, so it doesn't exist from the kernel's perspective. In gnome-continuous this breaks the /tmp - /sysroot/tmp link; which I could work around in a different way perhaps, but it would be nice if systemd had better semantics for mount points that are symlinks. What would the right thing here be? Should e.g. systemd follow the links and create two units from mount points that contain symlinks, explicitly having the source reflect destination? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 9:22 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 30.06.14 20:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Jun 30, 2014 at 11:10:15AM -0700, Lennart Poettering wrote: +varlistentry +termfilename/usr/lib/filename/term +listitemparaSystem libraries and +package-specific +data./para/listitem +/varlistentry + +varlistentry + termfilename/usr/lib64/filename/term +listitemparaSecondary library +directory for placing 64bit versions +of system libraries in, if the primary +architecture of the system is +32bit. This directory should not be +used for package-specific data, unless +this data requires 64bit-specific +versions, too./para/listitem +/varlistentry So far systemd was agnostic to the details of this split. This makes this official, and conflicts with the Debian/Ubuntu camp. The multiarch layout is more flexible, so this seems backwards. I do agree that the Debian/Ubuntu design here sounds like the better design there than Fedora's lib64. But then again lib64 is encoded in the ELF ABI since the dynamic loader is located there. There's no way we can get rid of it. Right, we will have /lib64, but we do not need /usr/lib64/ Note that the concept of lib64 is actually encoded in systemd now, since nspawn and PID 1 when switching roots will actually create /lib64 as symlink to /usr/lib64 should the latter exist. That scheme should be compatible with both Fedora's and Debin's multilib design. There is only the tuple-dir in /usr, seems, our current factory-setup will not work on Debian. We probably should change the logic to $libdir instead of looking for /usr/lib64. I tried to weasel myself out of the situation by clarifying that the the dir should only exist in case of the ABI requiring that. Not sure how we could improve the situation... Suggestions? I guess we should just not define /usr/lib64, it is just not strictly needed vor the ABI or compat. We should find out when we need to create /lib64 -- $libdir, grr ... :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Mon, 30.06.14 12:23, Colin Walters (walt...@verbum.org) wrote: Hi, we were trying to update systemd to git master in gnome-continuous, and hit an issue with mount points that are symlinks. It's pretty easy to reproduce: mkdir /mnt/a ln -s a /mnt/b cat /etc/systemd/system/mnt-b.mount EOF [Mount] What=tmpfs Where=/mnt/b Type=tmpfs Options=mode=1777,strictatime EOF systemctl daemon-reload systemctl start mnt-b.mount # Notice that we can see this mount via *both* units: systemctl status mnt-a.mount systemctl status mnt-b.mount # Now let's do an unrelated mount: mkdir /mnt/unrelated mount --bind /mnt/unrelated /mnt/unrelated systemctl status mnt-a.mount systemctl status mnt-b.mount # Notice mnt-b died This happens because on any mountpoint change, we mark all mounts as dead, and only reload the ones we see. But the kernel resolved the b - a symlink at mount time, so it doesn't exist from the kernel's perspective. In gnome-continuous this breaks the /tmp - /sysroot/tmp link; which I could work around in a different way perhaps, but it would be nice if systemd had better semantics for mount points that are symlinks. Why would you create such a symlink? This sounds wrong. /tmp should generally be a tmpfs these days, why would you link that? BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html What would the right thing here be? Should e.g. systemd follow the links and create two units from mount points that contain symlinks, explicitly having the source reflect destination? I am pretty sure we should simply prohibit mounts on existing symlinks. Sounds unnecessary and pretty dangerous to me. Not entirely sure though how we can effectively prohibit this, given that there is no lmount(), i.e. a mount() that refuses following mount points. We could implement this in a racy way by stat()ing first, which might be good enough (after all this requires priv), but of course not pretty... 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] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 21:28, Kay Sievers (k...@vrfy.org) wrote: Note that the concept of lib64 is actually encoded in systemd now, since nspawn and PID 1 when switching roots will actually create /lib64 as symlink to /usr/lib64 should the latter exist. That scheme should be compatible with both Fedora's and Debin's multilib design. There is only the tuple-dir in /usr, seems, our current factory-setup will not work on Debian. We probably should change the logic to $libdir instead of looking for /usr/lib64. Not following? I mean, the x86-64 ABI practically requires /lib64 to exist (does any other ABI?), how would you decide when to create it? #idef __x86_64__? And then always link it to $libdir? I tried to weasel myself out of the situation by clarifying that the the dir should only exist in case of the ABI requiring that. Not sure how we could improve the situation... Suggestions? I guess we should just not define /usr/lib64, it is just not strictly needed vor the ABI or compat. THis is so fucking broken. I mean, how should we ever be able to tell people where to place their stuff if the distros can't even agree on the ABI... meh. 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] mount units and symlinks
On Mon, Jun 30, 2014, at 12:29 PM, Lennart Poettering wrote: Why would you create such a symlink? This sounds wrong. /tmp should generally be a tmpfs these days, why would you link that? I need to support cases where /tmp is not tmpfs (e.g. current Fedora cloud images). The rationale is the way OSTree implements atomic upgrades and parallel OS installation involves having separate os roots, so by having /tmp - /sysroot/tmp they're shared rather than separate per root. I am pretty sure we should simply prohibit mounts on existing symlinks. That would be one way to do it. I could figure something out on the ostree side to adapt, probably having custom units around /tmp. There's likely other people in the field though with mount points that are symlinks, and while they're clearly buggy it'd be rather unfriendly to just have them entirely break after upgrading systemd. Maybe a loud warning? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 9:35 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 30.06.14 21:28, Kay Sievers (k...@vrfy.org) wrote: Note that the concept of lib64 is actually encoded in systemd now, since nspawn and PID 1 when switching roots will actually create /lib64 as symlink to /usr/lib64 should the latter exist. That scheme should be compatible with both Fedora's and Debin's multilib design. There is only the tuple-dir in /usr, seems, our current factory-setup will not work on Debian. We probably should change the logic to $libdir instead of looking for /usr/lib64. Not following? I mean, the x86-64 ABI practically requires /lib64 to exist (does any other ABI?) The ABI defines and requires: /lib64/ld-linux-x86-64.so.2 so /lib64 needs to be a symlink to /usr/lib(something), or a directory containing nothing but the dynloader. how would you decide when to create it? #idef __x86_64__? And then always link it to $libdir? I don't know exactly, something along that line. We would probably have configure to find out libdir and tuple-name in some way and try to make sense out of it. I tried to weasel myself out of the situation by clarifying that the the dir should only exist in case of the ABI requiring that. Not sure how we could improve the situation... Suggestions? I guess we should just not define /usr/lib64, it is just not strictly needed vor the ABI or compat. THis is so fucking broken. I mean, how should we ever be able to tell people where to place their stuff if the distros can't even agree on the ABI... meh. Yeah, it is all completely broken, as broken as the idea to spread the system over many directories and splitting the so-called root from /usr. None of that stuff makes the slightest sense today. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] console font
On 25.06.2014 20:49, poma wrote: On 25.06.2014 20:10, Felix Miata wrote: On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed: So...these are three different machines? 3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) NVidia for video. I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter? Most of my test machines get used most of the time with a '21' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default. My second most used test machine display is a 19 LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT. I also have 2 15 1024x768, 17 19 1280x1024 and 20 1600x1200 LCD puter displays, 2 31.5 TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary. # yum install terminus-fonts-console - permanent system wide /etc/vconsole.conf FONT=Big mama font e.g. 'latarcyrheb-sun32' or 'ter-v32b' - runtime local $ setfont latarcyrheb-sun32 $ setfont ter-v32b systemd-214-5.fc21.x86_64 kernel-3.16.0-0.rc3.git0.1.fc21.x86_64 It seems this kernel? bug is still present[2]. rd.vconsole.font=ter-v32b also fails to subsist due to fb: switching to nouveaufb from VESA VGA. - journal systemd-vconsole-setup systemd[1]: Starting Setup Virtual Console... systemd-vconsole-setup[347]: putfont: KDFONTOP: Invalid argument systemd-vconsole-setup[347]: /usr/bin/setfont failed with error code 71. systemd[1]: Started Setup Virtual Console. I've found so far that this can only be overcome with these two almost identical solutions; When I thought of 'actual-vconsole-setup-start' I did not know that Yegor already done it. Saṃsāra. Yegor's solution[1]: # cp /usr/lib/systemd/system/systemd-vconsole-setup.service /etc/systemd/system/ # diff /etc/systemd/system/systemd-vconsole-setup.service \ /usr/lib/systemd/system/systemd-vconsole-setup.service 13,14c13,14 After=sysinit.target Before=shutdown.target --- After=systemd-readahead-collect.service systemd-readahead-replay.service Before=sysinit.target shutdown.target or even simpler - leave 'systemd-vconsole-setup.service' as is, and make this one /etc/systemd/system/actual-vconsole-setup-start.service: # Actual Virtual Console Setup Start [Unit] Description=Actual Virtual Console Setup Start [Service] Type=forking ExecStart=/usr/lib/systemd/systemd-vconsole-setup [Install] WantedBy=rescue.target multi-user.target # systemctl enable actual-vconsole-setup-start.service and now you have appropriate font size for 1920x1080, no need to lower resolution via video=xresxyres. Perhaps '32' is too large, so choose = '28', e.g. ter-v28b or ter-v24b. /usr/share/doc/terminus-fonts-console/README[.fedora] poma [1] systemd-vconsole-setup: /usr/bin/setfont failed with error code 71 http://lists.freedesktop.org/archives/systemd-devel/2011-June/002562.html [2] Can not change console font via /etc/vconsole.conf https://bugzilla.redhat.com/show_bug.cgi?id=1074113 The keyboard layout for the virtual console cannot be changed using “localectl set-keymap map; dracut -f; reboot;” https://bugzilla.redhat.com/show_bug.cgi?id=1033250 font settings are lost when kernel fb drivers are changed https://bugzilla.redhat.com/show_bug.cgi?id=892340 Kernel drivers lose console font settings https://bugzilla.redhat.com/show_bug.cgi?id=1074624 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Mon, 30.06.14 12:41, Colin Walters (walt...@verbum.org) wrote: Why would you create such a symlink? This sounds wrong. /tmp should generally be a tmpfs these days, why would you link that? I need to support cases where /tmp is not tmpfs (e.g. current Fedora cloud images). This sounds confused. Why would the cloud images not use a tmpfs for /tmp? The rationale is the way OSTree implements atomic upgrades and parallel OS installation involves having separate os roots, so by having /tmp - /sysroot/tmp they're shared rather than separate per root. Not following here. You should really declare that /tmp has to be a tmpfs. Anyway, to allow to avoid the discussion I have now added ConditionPathIsSymbolicLink=!/tmp to tmp.mount. This will skip mounting of the tmpfs if /tmp is already a symlink. This should fix your issue? 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] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On 30/06/14 20:56, Filipe Brandenburger wrote: On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers k...@vrfy.org wrote: We should find out when we need to create /lib64 -- $libdir, grr ... :) Consider the case where you're running Fedora but use debootstrap to create a Debian tree and systemd-nspawn to run a process in it. $libdir will make sense in Fedora, not in Debian... In practice, a debootstrap'd 64-bit Debian tree will have to contain its own /lib64 basically forever, because the generic x86-64 Linux ABI says it must (even though Debian does not otherwise use lib64 any more); libc6_*_amd64.deb contains the directory and the ld-linux-x86-64.so symlink. As long as you don't actively break an existing /lib64 in the container, everything should be OK? On current Debian unstable, the only thing in /lib64 is: lrwxrwxrwx 1 root root 32 Jun 23 22:30 ld-linux-x86-64.so.2 - /lib/x86_64-linux-gnu/ld-2.19.so S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 09:02:07PM +0100, Simon McVittie wrote: On 30/06/14 20:56, Filipe Brandenburger wrote: On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers k...@vrfy.org wrote: We should find out when we need to create /lib64 -- $libdir, grr ... :) Consider the case where you're running Fedora but use debootstrap to create a Debian tree and systemd-nspawn to run a process in it. $libdir will make sense in Fedora, not in Debian... In practice, a debootstrap'd 64-bit Debian tree will have to contain its own /lib64 basically forever, because the generic x86-64 Linux ABI says it must (even though Debian does not otherwise use lib64 any more); libc6_*_amd64.deb contains the directory and the ld-linux-x86-64.so symlink. As long as you don't actively break an existing /lib64 in the container, everything should be OK? On current Debian unstable, the only thing in /lib64 is: lrwxrwxrwx 1 root root 32 Jun 23 22:30 ld-linux-x86-64.so.2 - /lib/x86_64-linux-gnu/ld-2.19.so This is about the case when only /usr is present in the container, and systemd-nspawn creates the rest of dirs and symlinks in container's /. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Use dev_port for the ID of a network device.
For network devices on the same PCI function, dev_id should not be used,
since its purpose is for IPv6 support on interfaces with the same MAC
address.
The new dev_port sysfs attribute should be used when it is found. When
it is not, using dev_id might work.
Signed-off-by: Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com
---
src/udev/udev-builtin-net_id.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index c80c30a..6de9c98 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -186,9 +186,14 @@ static int dev_pci_slot(struct udev_device *dev, struct
netnames *names) {
return -ENOENT;
/* kernel provided multi-device index */
-attr = udev_device_get_sysattr_value(dev, dev_id);
-if (attr)
+attr = udev_device_get_sysattr_value(dev, dev_port);
+if (attr) {
dev_id = strtol(attr, NULL, 16);
+} else {
+attr = udev_device_get_sysattr_value(dev, dev_id);
+if (attr)
+dev_id = strtol(attr, NULL, 16);
+}
/* compose a name based on the raw kernel's PCI bus, slot numbers */
s = names-pci_path;
--
1.7.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Mon, 30.06.14 13:27, Colin Walters (walt...@verbum.org) wrote: On Mon, Jun 30, 2014, at 12:49 PM, Lennart Poettering wrote: This sounds confused. Why would the cloud images not use a tmpfs for /tmp? https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n181 Oh, man. This is just stupid. Anyway, to allow to avoid the discussion I have now added ConditionPathIsSymbolicLink=!/tmp to tmp.mount. This will skip mounting of the tmpfs if /tmp is already a symlink. This should fix your issue? Hmm, that would effectively force tmp to *not* be a tmpfs with the current tree. We just pushed a different fix for continuous to just make /tmp a regular directory, since there I'm comfortable assuming /tmp-on-tmpfs. Not following? This makes physical /tmp be more broken for ostree systems, but maybe I can just ship some logic to bind mount it to /sysroot/tmp if it's not already a mount point, or so. I'll figure something out. Hmm, I already commited the fix I mentioned. Shall I revert it? It kinda makes sense to me to leave the condition in, after all with a symlink you revert redirect things to something else, and systemd cannot make sense of that. Hence: if you redirect things then drop in a .mount file for the new location, and don't do any mounts on /tmp itself. 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] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 21:35, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 30.06.14 21:28, Kay Sievers (k...@vrfy.org) wrote: Note that the concept of lib64 is actually encoded in systemd now, since nspawn and PID 1 when switching roots will actually create /lib64 as symlink to /usr/lib64 should the latter exist. That scheme should be compatible with both Fedora's and Debin's multilib design. I have not updated the man page so that it only mentions $libdir, and doesn't codify lib64 in anything. It's really disappointing that the Linux distributions can't even agree on where to place libraries. FHS is such a joke... But anyway, the man page should now not be too far from what the various distribution's ABIs. 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] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, 30.06.14 12:56, Filipe Brandenburger (filbran...@google.com) wrote: Hi, On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers k...@vrfy.org wrote: We should find out when we need to create /lib64 -- $libdir, grr ... :) Problem is that $libdir is relevant for the host distribution but might not be for the one running inside the nspawn'd namespace. Consider the case where you're running Fedora but use debootstrap to create a Debian tree and systemd-nspawn to run a process in it. $libdir will make sense in Fedora, not in Debian... Maybe it should try both and figure out which one of them exists? Or default to $libdir and allow an override for the cross-distro cases. Hmm, I am tempted to say that we should add a logic to this that just checks the few debian-style arch tuples we know of, plus fedora-style lib64, and if any of them exist, we create a lib64 symlink to them. The table should be relatively short I think. Ugly that we need this, but maintainable. With that in place we should allow cross-distro nspawn I figure. 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] networkd config for dummy0 interface
On 06/24/2014 12:25 PM, Tom Gundersen wrote:
On Tue, Jun 24, 2014 at 12:14 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote:
Hi. I have very strange task:
Not tested, but I would start with trying:
1) Nedd modprobe dummy
Use modules-load.d
2) Assign specific mac address to it
Possibly use .link files, or check if it is possible to spcify this as
module options (didn't check).
3) Bring up it
4) Assign specific address to it
Use a regular .network file... Should wokr.
HTH,
Tom
I'm not sure if this has changed recently, but I think it is not
possible to use .link files to configure virtual network devices as
there is _nothing_ to match on.
As I mentioned in another discussion (regarding bridge MAC addresses),
I've added the following udev rule as a workaround, which allows
matching for virtual device names using the Path= match (I need this for
a batman-adv device, I guess there are tons of other device types which
are similar):
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
I think we really need a name match for virtual devices which have
neither a persistent MAC address nor a device path to match on in .link
units. It might be called VirtualName= and only work for devices that
don't have a path so people don't try to use it when a Path= match would
be more appropriate...
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile-man.am man/daemon.xml man/file-hierarchy.xml tmpfiles.d/systemd.conf
On Mon, Jun 30, 2014 at 2:38 PM, Lennart Poettering lenn...@poettering.net wrote: Maybe it should try both and figure out which one of them exists? Or default to $libdir and allow an override for the cross-distro cases. Hmm, I am tempted to say that we should add a logic to this that just checks the few debian-style arch tuples we know of, plus fedora-style lib64, and if any of them exist, we create a lib64 symlink to them. The table should be relatively short I think. Ugly that we need this, but maintainable. With that in place we should allow cross-distro nspawn I figure. Sounds good to me. Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Jun 30, Lennart Poettering lenn...@poettering.net wrote: BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html Another difference is that Debian, Ubuntu and other derivatives support (closer to a MUST than a SHOULD) $TMPDIR instead of $TMP. This is the normative reference: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 -- ciao, Marco signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Jun 30, Lennart Poettering lenn...@poettering.net wrote: BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html The other major issue that I can see is that in Debian we have already tried to make /tmp a tmpfs and this caused enough problems that we had to revert the default. So if you feel really strongly about /tmp being only for small files then we will have to patch the man page in some way to make it reflect the actual usage. -- ciao, Marco signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mount units and symlinks
On Tue, 01.07.14 00:27, Marco d'Itri (m...@linux.it) wrote: On Jun 30, Lennart Poettering lenn...@poettering.net wrote: BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html The other major issue that I can see is that in Debian we have already tried to make /tmp a tmpfs and this caused enough problems that we had to revert the default. So if you feel really strongly about /tmp being only for small files then we will have to patch the man page in some way to make it reflect the actual usage. Well, Fedora has been using tmpfs of /tmp for quite a while now, by default. There have been problems, but they got fixed. The intention of the document is to describe what assumptions people should make about the specific directories, not what they actually are going to be like. /tmp may be on physical disk, but tmpfs is common, and hence the assumption should be that large files should not be placed there, since tmpfs in this regard is the more limiting backing store. 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] [PATCH 0/3] move timeout handling out of the core
On Mon, Jun 30, 2014 at 02:57:21PM +0200, Lennart Poettering wrote: On Mon, 30.06.14 14:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I think I agree with this. The only reason I could think of why this might not be the right thing to do is to be nice to folks who wrote native mount units who want to use the mount option. Because this way the mount option becomes specific to fstab and cannot be used otherwise... (Which actually is exactly what we do for x-systemd.automount, which makes this all feel quite OK) Good catch. I didn't think about that. Maybe a middle ground of issuing a warning? I'll add some code which complains when the option is seen in a unit file. I'd just document it. I mean, part of the reason for your patch is to remove this from the core, so it sounds wrong readding this this way. I'd just document it, and retain no further code for this in PID 1. Maybe if a thousand bugs get reported about this we can add a warning, but otherwise I'd really keep this clean. OK, pushed. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: send hostname to dhcp server
Send hostname (option 12) in DISCOVER and REQUEST messages so the
DHCP server could use it to register with dynamic DNS and such.
---
src/libsystemd-network/sd-dhcp-client.c | 35 +
src/network/networkd-link.c | 26
src/systemd/sd-dhcp-client.h| 1 +
3 files changed, 62 insertions(+)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 1603c41..44a5e8a 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -56,6 +56,7 @@ struct sd_dhcp_client {
uint8_t type;
struct ether_addr mac_addr;
} _packed_ client_id;
+char *hostname;
uint32_t xid;
usec_t start_time;
uint16_t secs;
@@ -178,6 +179,20 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client,
return 0;
}
+int sd_dhcp_client_set_hostname(sd_dhcp_client *client,
+const char *hostname) {
+
+assert_return(client, -EINVAL);
+assert_return(hostname, -EINVAL);
+
+if (client-hostname streq(client-hostname, hostname) )
+return 0;
+
+client-hostname = strdup(hostname);
+
+return 0;
+}
+
int sd_dhcp_client_get_lease(sd_dhcp_client *client, sd_dhcp_lease **ret) {
assert_return(client, -EINVAL);
assert_return(ret, -EINVAL);
@@ -386,6 +401,17 @@ static int client_send_discover(sd_dhcp_client *client) {
return r;
}
+/* it is unclear from RFC 2131 if client should send hostname in
+ DHCPDISCOVER but dhclient does and so we do as well
+*/
+if (client-hostname) {
+r = dhcp_option_append(discover-dhcp, optlen, optoffset, 0,
+ DHCP_OPTION_HOST_NAME,
+ strlen(client-hostname),
client-hostname);
+if (r 0)
+return r;
+}
+
r = dhcp_option_append(discover-dhcp, optlen, optoffset, 0,
DHCP_OPTION_END, 0, NULL);
if (r 0)
@@ -477,6 +503,14 @@ static int client_send_request(sd_dhcp_client *client) {
return -EINVAL;
}
+if (client-hostname) {
+r = dhcp_option_append(request-dhcp, optlen, optoffset, 0,
+ DHCP_OPTION_HOST_NAME,
+ strlen(client-hostname),
client-hostname);
+if (r 0)
+return r;
+}
+
r = dhcp_option_append(request-dhcp, optlen, optoffset, 0,
DHCP_OPTION_END, 0, NULL);
if (r 0)
@@ -1363,6 +1397,7 @@ sd_dhcp_client *sd_dhcp_client_unref(sd_dhcp_client
*client) {
sd_dhcp_lease_unref(client-lease);
free(client-req_opts);
+free(client-hostname);
free(client);
}
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 9296a59..9d849a0 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -21,6 +21,7 @@
#include netinet/ether.h
#include linux/if.h
+#include unistd.h
#include networkd.h
#include libudev-private.h
@@ -1846,6 +1847,19 @@ static int link_enter_enslave(Link *link) {
return 0;
}
+/* make sure the hostname is not localhost */
+static bool is_localhost(const char *hostname) {
+char *hostend;
+
+assert(hostname);
+
+hostend = strchr(hostname, '.');
+if (hostend)
+return strneq(hostname, localhost, (hostend - hostname));
+else
+return streq(hostname, localhost);
+}
+
static int link_configure(Link *link) {
int r;
@@ -1886,6 +1900,8 @@ static int link_configure(Link *link) {
}
if (link-network-dhcp) {
+char hostname[HOST_NAME_MAX];
+
r = sd_dhcp_client_new(link-dhcp_client);
if (r 0)
return r;
@@ -1911,6 +1927,16 @@ static int link_configure(Link *link) {
if (r 0)
return r;
}
+
+r = gethostname(hostname, sizeof(hostname));
+if (r 0)
+return r;
+
+if (!is_localhost(hostname)) {
+r = sd_dhcp_client_set_hostname(link-dhcp_client,
hostname);
+if (r 0)
+return r;
+}
}
if (link-network-dhcp_server) {
diff --git a/src/systemd/sd-dhcp-client.h b/src/systemd/sd-dhcp-client.h
index 5818ec4..7b5b938 100644
--- a/src/systemd/sd-dhcp-client.h
+++ b/src/systemd/sd-dhcp-client.h
@@ -50,6 +50,7 @@ int sd_dhcp_client_set_request_address(sd_dhcp_client *client,
int
Re: [systemd-devel] [PATCH] networkd: send hostname to dhcp server
On Mon, Jun 30, 2014 at 04:52:21PM -0700, Eugene Yakubovich wrote:
Send hostname (option 12) in DISCOVER and REQUEST messages so the
DHCP server could use it to register with dynamic DNS and such.
---
src/libsystemd-network/sd-dhcp-client.c | 35
+
src/network/networkd-link.c | 26
src/systemd/sd-dhcp-client.h| 1 +
3 files changed, 62 insertions(+)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 1603c41..44a5e8a 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -56,6 +56,7 @@ struct sd_dhcp_client {
uint8_t type;
struct ether_addr mac_addr;
} _packed_ client_id;
+char *hostname;
uint32_t xid;
usec_t start_time;
uint16_t secs;
@@ -178,6 +179,20 @@ int sd_dhcp_client_set_mac(sd_dhcp_client *client,
return 0;
}
+int sd_dhcp_client_set_hostname(sd_dhcp_client *client,
+const char *hostname) {
+
+assert_return(client, -EINVAL);
+assert_return(hostname, -EINVAL);
+
+if (client-hostname streq(client-hostname, hostname) )
+return 0;
+
+client-hostname = strdup(hostname);
+
+return 0;
+}
+
int sd_dhcp_client_get_lease(sd_dhcp_client *client, sd_dhcp_lease **ret) {
assert_return(client, -EINVAL);
assert_return(ret, -EINVAL);
@@ -386,6 +401,17 @@ static int client_send_discover(sd_dhcp_client *client) {
return r;
}
+/* it is unclear from RFC 2131 if client should send hostname in
+ DHCPDISCOVER but dhclient does and so we do as well
+*/
+if (client-hostname) {
+r = dhcp_option_append(discover-dhcp, optlen, optoffset,
0,
+ DHCP_OPTION_HOST_NAME,
+ strlen(client-hostname),
client-hostname);
+if (r 0)
+return r;
+}
+
r = dhcp_option_append(discover-dhcp, optlen, optoffset, 0,
DHCP_OPTION_END, 0, NULL);
if (r 0)
@@ -477,6 +503,14 @@ static int client_send_request(sd_dhcp_client *client) {
return -EINVAL;
}
+if (client-hostname) {
+r = dhcp_option_append(request-dhcp, optlen, optoffset, 0,
+ DHCP_OPTION_HOST_NAME,
+ strlen(client-hostname),
client-hostname);
+if (r 0)
+return r;
+}
+
r = dhcp_option_append(request-dhcp, optlen, optoffset, 0,
DHCP_OPTION_END, 0, NULL);
if (r 0)
@@ -1363,6 +1397,7 @@ sd_dhcp_client *sd_dhcp_client_unref(sd_dhcp_client
*client) {
sd_dhcp_lease_unref(client-lease);
free(client-req_opts);
+free(client-hostname);
free(client);
}
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 9296a59..9d849a0 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -21,6 +21,7 @@
#include netinet/ether.h
#include linux/if.h
+#include unistd.h
#include networkd.h
#include libudev-private.h
@@ -1846,6 +1847,19 @@ static int link_enter_enslave(Link *link) {
return 0;
}
+/* make sure the hostname is not localhost */
+static bool is_localhost(const char *hostname) {
+char *hostend;
+
+assert(hostname);
You only call this in one place, with an array on the stack, so it can
never be NULL. So why check this at all?
Other than that minor nit, this looks good, thanks for adding it.
greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Use dev_port for the ID of a network device.
On Mon, Jun 30, 2014 at 10:36 PM, Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com wrote: For network devices on the same PCI function, dev_id should not be used, since its purpose is for IPv6 support on interfaces with the same MAC address. The new dev_port sysfs attribute should be used when it is found. When it is not, using dev_id might work. I don't see a problem switching this over, but why would we keep using dev_id if it is not the right thing to use? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd config for dummy0 interface
Matthias Schiffer mschif...@universe-factory.net on Mon, 2014/06/30 23:47:
On 06/24/2014 12:25 PM, Tom Gundersen wrote:
On Tue, Jun 24, 2014 at 12:14 PM, Vasiliy Tolstov v.tols...@selfip.ru
wrote:
Hi. I have very strange task:
Not tested, but I would start with trying:
1) Nedd modprobe dummy
Use modules-load.d
2) Assign specific mac address to it
Possibly use .link files, or check if it is possible to spcify this as
module options (didn't check).
3) Bring up it
4) Assign specific address to it
Use a regular .network file... Should wokr.
HTH,
Tom
I'm not sure if this has changed recently, but I think it is not
possible to use .link files to configure virtual network devices as
there is _nothing_ to match on.
Sure. You have a name. That is what I tried first and it works perfectly.
[Match]
Name=dummy0
Or did I miss anything?
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd config for dummy0 interface
On 07/01/2014 05:56 AM, Christian Hesse wrote: Matthias Schiffer mschif...@universe-factory.net on Mon, 2014/06/30 23:47: On 06/24/2014 12:25 PM, Tom Gundersen wrote: On Tue, Jun 24, 2014 at 12:14 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: Hi. I have very strange task: Not tested, but I would start with trying: 1) Nedd modprobe dummy Use modules-load.d 2) Assign specific mac address to it Possibly use .link files, or check if it is possible to spcify this as module options (didn't check). 3) Bring up it 4) Assign specific address to it Use a regular .network file... Should wokr. HTH, Tom I'm not sure if this has changed recently, but I think it is not possible to use .link files to configure virtual network devices as there is _nothing_ to match on. Sure. You have a name. That is what I tried first and it works perfectly. [Match] Name=dummy0 Or did I miss anything? No, Name= matches only work in .network units, not in .link units. A link unit without any valid match option matches any interface though; so if you have a .link unit with Name=dummy0 in its [Match] section, it will actually be applied to dummy0... but also to all other interfaces, which can be very confusing. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd config for dummy0 interface
Matthias Schiffer mschif...@universe-factory.net on Tue, 2014/07/01 07:08:
On 07/01/2014 05:56 AM, Christian Hesse wrote:
Matthias Schiffer mschif...@universe-factory.net on Mon, 2014/06/30
23:47:
On 06/24/2014 12:25 PM, Tom Gundersen wrote:
On Tue, Jun 24, 2014 at 12:14 PM, Vasiliy Tolstov v.tols...@selfip.ru
wrote:
Hi. I have very strange task:
Not tested, but I would start with trying:
1) Nedd modprobe dummy
Use modules-load.d
2) Assign specific mac address to it
Possibly use .link files, or check if it is possible to spcify this as
module options (didn't check).
3) Bring up it
4) Assign specific address to it
Use a regular .network file... Should wokr.
HTH,
Tom
I'm not sure if this has changed recently, but I think it is not
possible to use .link files to configure virtual network devices as
there is _nothing_ to match on.
Sure. You have a name. That is what I tried first and it works perfectly.
[Match]
Name=dummy0
Or did I miss anything?
No, Name= matches only work in .network units, not in .link units. A
link unit without any valid match option matches any interface though;
so if you have a .link unit with Name=dummy0 in its [Match] section, it
will actually be applied to dummy0... but also to all other interfaces,
which can be very confusing.
Of course you are right. I do have a dummy0.network unit.
Sorry for the noise.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
