[systemd-devel] [ANNOUNCE] systemd v220

[Lennart Poettering]

Heya,

Many many bugfixes, and a good number of new features:

http://www.freedesktop.org/software/systemd/systemd-220.tar.xz

CHANGES WITH 220:

* The gudev library has been extracted into a separate repository
  available at: https://git.gnome.org/browse/libgudev/
  It is now managed as part of the Gnome project. Distributions
  are recommended to pass --disable-gudev to systemd and use
  gudev from the Gnome project instead. gudev is still included
  in systemd, for now. It will be removed soon, though. Please
  also see the announcement-thread on systemd-devel:
  
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032070.html

* systemd now exposes a CPUUsageNSec= property for each
  service unit on the bus, that contains the overall consumed
  CPU time of a service (the sum of what each process of the
  service consumed). This value is only available if
  CPUAccounting= is turned on for a service, and is then shown
  in the "systemctl status" output.

* Support for configuring alternative mappings of the old SysV
  runlevels to systemd targets has been removed. They are now
  hardcoded in a way that runlevels 2, 3, 4 all map to
  multi-user.target and 5 to graphical.target (which
  previously was already the default behaviour).

* The auto-mounter logic gained support for mount point
  expiry, using a new TimeoutIdleSec= setting in .automount
  units. (Also available as x-systemd.idle-timeout= in /etc/fstab).

* The EFI System Partition (ESP) as mounted to /boot by
  systemd-efi-boot-generator will now be unmounted
  automatically after 2 minutes of not being used. This should
  minimize the risk of ESP corruptions.

* New /etc/fstab options x-systemd.requires= and
  x-systemd.requires-mounts-for= are now supported to express
  additional dependencies for mounts. This is useful for
  journalling file systems that support external journal
  devices or overlay file systems that require underlying file
  systems to be mounted.

* systemd does not support direct live-upgrades (via systemctl
  daemon-reexec) from versions older than v44 anymore. As no
  distribution we are aware of shipped such old versions in a
  stable release this should not be problematic.

* When systemd forks off a new per-connection service instance
  it will now set the $REMOTE_ADDR environment variable to the
  remote IP address, and $REMOTE_PORT environment variable to
  the remote IP port. This behaviour is similar to the
  corresponding environment variables defined by CGI.

* systemd-networkd gained support for uplink failure
  detection. The BindCarrier= option allows binding interface
  configuration dynamically to the link sense of other
  interfaces. This is useful to achieve behaviour like in
  network switches.

* systemd-networkd gained support for configuring the DHCP
  client identifier to use when requesting leases.

* systemd-networkd now has a per-network UseNTP= option to
  configure whether NTP server information acquired via DHCP
  is passed on to services like systemd-timesyncd.

* systemd-networkd gained support for vti6 tunnels.

* Note that systemd-networkd manages the sysctl variable
  /proc/sys/net/ipv[46]/conf/*/forwarding for each interface
  it is configured for since v219. The variable controls IP
  forwarding, and is a per-interface alternative to the global
  /proc/sys/net/ipv[46]/ip_forward. This setting is
  configurable in the IPForward= option, which defaults to
  "no". This means if networkd is used for an interface it is
  no longer sufficient to set the global sysctl option to turn
  on IP forwarding! Instead, the .network file option
  IPForward= needs to be turned on! Note that the
  implementation of this behaviour was broken in v219 and has
  been fixed in v220.

* Many bonding and vxlan options are now configurable in
  systemd-networkd.

* systemd-nspawn gained a new --property= setting to set unit
  properties for the container scope. This is useful for
  setting resource parameters (e.g "CPUShares=500") on
  containers started from the command line.

* systemd-nspawn gained a new --private-users= switch to make
  use of user namespacing available on recent Linux kernels.

* systemd-nspawn may now be called as part of a shell pipeline
  in which case the pipes used for stdin and stdout are passed
  directly to the process invoked in the container, without
  indirection via a pseud

Re: [systemd-devel] Problem when m->finish_timestamp is set before running manager_loop

[Lennart Poettering]

On Wed, 20.05.15 11:16, cee1 (fykc...@gmail.com) wrote:

> 2015-05-20 1:27 GMT+08:00 Lennart Poettering :
> > Hmm, can you provide a backtrace of the call chain when this happens,
> > please?
> 
> The call chain is:
> 0xb6df1acc : 0xe1a07000
> 0xb6e9f744 : 0xe3a0
> 0xb6df4bb0 : 0xe59a0004
> 0xb6ded8e8 : 0xe2509000
> 0xb6de6080 : 0xe371
> 

Should be fixed in git. Please verify!

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] buildsys: remove always true autoconf checks

[Cristian Rodríguez]

On Thu, May 21, 2015 at 11:39 AM, Lennart Poettering
 wrote:
> On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
>
>> All this checks are always true in any modernish linux system.
>> ---
>>  configure.ac | 11 ---
>>  1 file changed, 11 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 3efee22..cd6375b 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
>> valgrind/valgrind.h])
>>  have_myhostname=no
>>  AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
>> nss-myhostname support]))
>>  if test "x$enable_myhostname" != "xno"; then
>> -AC_HEADER_STDC
>> -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h
>> netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h
>> nss.h sys/ioctl.h sys/auxv.h])
>
> sys/auxv.h at least is a relatively recent addition to glibc, hence
> simply removing this all appears too broad...

Right.. that's an oversight..

>
> Not sure however why this is in the enable_myhostname part however, it
> should just be moved up. Could you prep a patch that does that?

Sure.. stay tuned ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] swap: use swapon -o

[Lennart Poettering]

On Thu, 21.05.15 18:02, Karel Zak (k...@redhat.com) wrote:

> On Thu, May 21, 2015 at 04:45:44PM +0200, Lennart Poettering wrote:
> > I think it might be a good idea to log a warning if the priority is
> > specified both in s->parameters_frament.priority and in
> > s->parameters_fragment.options.
> 
> This (priority specified by both fields) is standard fstab-generator 
> behaviour.
> Maybe the generator should be also updated to stop generate "Priority:".

Yeah, I agree. It should pass the option string as is, given that we
can do so now, and not parse it in any way and generate secondary
fields from it.

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] swap: use swapon -o

[Karel Zak]

On Thu, May 21, 2015 at 04:45:44PM +0200, Lennart Poettering wrote:
> I think it might be a good idea to log a warning if the priority is
> specified both in s->parameters_frament.priority and in
> s->parameters_fragment.options.

This (priority specified by both fields) is standard fstab-generator behaviour.
Maybe the generator should be also updated to stop generate "Priority:".

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot

[Jóhann B. Guðmundsson]

On 05/21/2015 03:19 PM, Colin Walters wrote:

On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote:

IMHO subvolumes, like hard disk partitions, are something that the
administrator of a host should create deliberately only. Automatically
created ones just create confusion about "why the heck can't I remove
that directory".. It's roughly equivalent of some random package
messing with your partitions and/or fstab.

So if we could somehow make this conditional on "running on real
iron", that would be a good compromise IMHO.

I also agree with this.


Real or not makes no difference

systemd should not be creating subvolumes et all or atleast there should 
be a system wide option to disable it altogether and that option should 
be disabled by default upstream.


This breaks btrfs setup/administrations on host, breaks tools etc. so 
perhaps just best to get a second opinion with upstream btrfs community 
and get their opinion of having core/base component creating subvolumes 
on their own is the *smart* thing to do and see if their words are 
enough to change Lennart's mind about this.


JBG



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

Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]

[Serge Hallyn]

Quoting Lennart Poettering (lenn...@poettering.net):
> On Wed, 20.05.15 22:40, Martin Pitt (martin.p...@ubuntu.com) wrote:
> 
> > Hey Lennart,
> > 
> > Lennart Poettering [2015-05-20 17:49 +0200]:
> > > Nope, ConditionSecurity=audit is only a simple boolean check that
> > > holds when audit is enabled at all. It doesn't tell you anything about
> > > the precise audit feature set of the kernel.
> > 
> > Ah, thanks for the clarification.
> > 
> > > I have now conditionalized the unit on CAP_ADMIN_READ, which is the
> > > cap that you need to read the audit multicast stuff. You container
> > > manager hence should simply drop that cap fro, the cap set it passes
> > > and all should be good.

I want to clarify this point.  Dropping CAP_ADMIN_READ from the bounding
set means dropping it from the capabilities targeted at your own user
namespace.  The only check in the kernel for CAP_ADMIN_READ currently is
against the initial user namespace.  One day of course (maybe soon) this
may change so that you only need CAP_ADMIN_READ against your own
user_ns.  Following the above, container managers could then again keep
CAP_ADMIN_READ in the bounding set.

But I'm claiming that checking for CAP_ADMIN_READ in your bounding set
is the wrong check here.  It simply has nothing to do with what you
actually want to be able to do.  One could argue that the right answer
is a new kernel facility to check for caps against init_user_ns, but no
that will have the same problem after audit ns becomes possible.  I
think the right check for systemd to perform to check whether this is
allowed is to actuallly try the bind().  That will return the right
answer both now and when namespaced audit is possible, without taking a
probably-wrong unrelated cue from the container manager.

It's not earth-shatteringly important and what you've got is workable,
but I think it may set a better precedent to do it the other way.

-serge

(One might almost think that we should have a new kernel facility to
answer questions such questions.  CAP_MAC_ADMIN is similar.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot

[Colin Walters]

On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote:
>
> IMHO subvolumes, like hard disk partitions, are something that the
> administrator of a host should create deliberately only. Automatically
> created ones just create confusion about "why the heck can't I remove
> that directory".. It's roughly equivalent of some random package
> messing with your partitions and/or fstab.
> 
> So if we could somehow make this conditional on "running on real
> iron", that would be a good compromise IMHO.

I also agree with this.

Having a special `btrfs rm -rf` (as is implemented now by 
systemd/src/shared/btrfs-util.c)
copied into various projects is painful.  There are a *lot* of tools that
do packages in chroots that would all need to be taught this.

I'll look at the seccomp approach, but the amount of pain versus gain
here seems quite disproportionate right now.

(OTOH, I want to use seccomp for RPM things in general, of which
 this is just one)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] swap: use swapon -o

[Lennart Poettering]

On Wed, 20.05.15 17:54, Karel Zak (k...@redhat.com) wrote:

> This patch simplify swapon usage in systemd. The command swapon(8)
> since util-linux v2.26 supports "-o ". The idea is exactly the
> same like for mount(8). The -o specifies options in fstab-compatible
> way. For systemd it means that it does not have to care about things
> like "discard" or another swapon specific options.

I figure the README should be updated as part of the patch to require
util-linux 2.26 then.

>  static void swap_enter_activating(Swap *s) {
> -_cleanup_free_ char *discard = NULL;
> -int r, priority = -1;
> +_cleanup_free_ char *opts = NULL;
> +int r;
>  
>  assert(s);
>  
> @@ -726,13 +726,19 @@ static void swap_enter_activating(Swap *s) {
>  s->control_command = s->exec_command + SWAP_EXEC_ACTIVATE;
>  
>  if (s->from_fragment) {
> -fstab_filter_options(s->parameters_fragment.options, 
> "discard\0", NULL, &discard, NULL);
> +int priority = -1;
> +
> +r = fstab_find_pri(s->parameters_fragment.options, 
> &priority);
> +if (r < 0)
> +log_notice_errno(r, "Failed to parse swap
> priority \"%s\", ignoring: %m", s->parameters_fragment.options);

So far we logged such non-fatal errors as LOG_WARNING. Could you
upgrade this from log_notice_errno() to log_warning_errno() please?

(I am aware the the previous code used LOG_NOTICE, but this should be
fixed I think)

>  
> -priority = s->parameters_fragment.priority;
> -if (priority < 0) {
> -r = fstab_find_pri(s->parameters_fragment.options, 
> &priority);
> +if (r <= 0 && s->parameters_fragment.priority >= 0) {
> +if (s->parameters_fragment.options)
> +r = asprintf(&opts, "%s,pri=%i", 
> s->parameters_fragment.options, s->parameters_fragment.priority);
> +else
> +r = asprintf(&opts, "pri=%i", 
> s->parameters_fragment.priority);
>  if (r < 0)
> -log_notice_errno(r, "Failed to
> -parse swap priority \"%s\", ignoring: %m",
> -s->parameters_fragment.options);
> +goto fail;
>  }

I think it might be a good idea to log a warning if the priority is
specified both in s->parameters_frament.priority and in
s->parameters_fragment.options.

Otherwise looks good!

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] buildsys: remove always true autoconf checks

[Lennart Poettering]

On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

> All this checks are always true in any modernish linux system.
> ---
>  configure.ac | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 3efee22..cd6375b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
> valgrind/valgrind.h])
>  have_myhostname=no
>  AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
> nss-myhostname support]))
>  if test "x$enable_myhostname" != "xno"; then
> -AC_HEADER_STDC
> -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h
> netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h
> nss.h sys/ioctl.h sys/auxv.h])

sys/auxv.h at least is a relatively recent addition to glibc, hence
simply removing this all appears too broad...

Not sure however why this is in the enable_myhostname part however, it
should just be moved up. Could you prep a patch that does that?

> -
> -AC_C_CONST
> -AC_TYPE_SIZE_T
> -AC_HEADER_TIME
> -
> -AC_FUNC_MALLOC
> -AC_FUNC_SELECT_ARGTYPES
> -AC_CHECK_FUNCS([gethostbyaddr gethostbyname gettimeofday inet_ntoa 
> memset select socket strcspn strdup strerror strncasecmp strcasecmp strspn])
> -
>  have_myhostname=yes
>  fi
>  AM_CONDITIONAL(HAVE_MYHOSTNAME, [test "$have_myhostname" = "yes"])
> -- 
> 2.4.1
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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] networkd: do not change kernel forwarding parameters when IPForwarding is unset

[Tom Gundersen]

On Mon, May 18, 2015 at 6:55 PM, Lennart Poettering
 wrote:
> On Fri, 15.05.15 22:49, Tom Gundersen (t...@jklm.no) wrote:
>
>> On Fri, May 15, 2015 at 10:02 PM, Lennart Poettering
>>  wrote:
>> > On Fri, 15.05.15 12:56, Michael Marineau (michael.marin...@coreos.com) 
>> > wrote:
>> >
>> >> (build time option to ./configure that is)
>> >
>> > I guess I'd be OK with that...
>>
>> It would be a shame if we started diverging on the defaults I think.
>> Would be nice if we could come up with some scheme that would work for
>> everyone. Would an option be to use a script to append
>> IPForward='kernel' to your network files on upgrades? Pretty dirty,
>> but I don't know how you usually deal with config changes...
>
> Well, I think it is fine if downstream departs from our defaults...

Ok, I guess. As there appears to be no better way.

> Another idea would be to add DefaultIPForward= to
> /etc/systemd/networkd.conf that alters defaults for networks, the same
> way as we have DefaultXYZ= in /etc/systemd/system.conf that affects
> unit defaults?

In principle it sounds like a feature we could add, but I think we
should have a better usecase than just backwards compatibility, then
I'd rather go with the compile-time switch I guess.

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

Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time

[Rauta, Alin]

Yes. It makes sence.
Thanks,
Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no] 
Sent: Thursday, May 21, 2015 3:20 PM
To: Rauta, Alin
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Belkind, Nadav
Subject: Re: networkd: dbus API for networkd reconfiguration at run-time

On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin  wrote:
> Hi Lennart,
>
> Thanks for the answers.
>
> One more questions. Just a curiosity of mine.
>
> Currently, a user has to write scripts if he wants to save the run-time 
> configuration in networkd format or to use a configuration management tool 
> like chef for example.
> Even with the latter, the user still needs to write scripts.
>
> What about saving the run-time configuration in networkd format with 
> "networkctl" maybe ?
> Something like "networkctl save" or "networkctl save config" with extensions 
> to provide per port configuration saving, output directory for saved 
> configuration and so on ... ?

Not entirely sure I understand the question, but this is what I have in mind: 
we support three config sources at the moment: stuff in /lib which is shipped 
by packages, stuff in /etc that is provided by the admin and is persistent 
between reboots and stuff in /run which is lost on reboot. Our future API 
should have a switch allowing the config we apply to either be persistent 
(written out to /etc) or ephemeral (written out to /run), so that any config in 
networkd is backed by a config file somewhere. Does that make sense? Does it 
answer your question, or is there some other type of config you would like to 
write out?

Cheers,

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

Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time

[Tom Gundersen]

On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin  wrote:
> Hi Lennart,
>
> Thanks for the answers.
>
> One more questions. Just a curiosity of mine.
>
> Currently, a user has to write scripts if he wants to save the run-time 
> configuration in networkd format or to use a configuration management tool 
> like chef for example.
> Even with the latter, the user still needs to write scripts.
>
> What about saving the run-time configuration in networkd format with 
> "networkctl" maybe ?
> Something like "networkctl save" or "networkctl save config" with extensions 
> to provide per port configuration saving, output directory for saved 
> configuration and so on ... ?

Not entirely sure I understand the question, but this is what I have
in mind: we support three config sources at the moment: stuff in /lib
which is shipped by packages, stuff in /etc that is provided by the
admin and is persistent between reboots and stuff in /run which is
lost on reboot. Our future API should have a switch allowing the
config we apply to either be persistent (written out to /etc) or
ephemeral (written out to /run), so that any config in networkd is
backed by a config file somewhere. Does that make sense? Does it
answer your question, or is there some other type of config you would
like to write out?

Cheers,

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

Re: [systemd-devel] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs

[Tom Gundersen]

On Wed, May 20, 2015 at 8:05 PM, Michael Marineau
 wrote:
> I haven't retested HEAD yet but up through 219 it would report 'no-carrier
> configuring' which seems bogus since it shouldn't be configuring an
> interface in such a state

"no-carrier configuring" could easily happen as we would enslave a
device and add routes/addresses even before the device gains a
carrier.

> and there is no .network config to apply to the
> interface either.

Now this is strange. A link should never be in "configuring" state
unless we actually have a .network file to apply to it.

> We have seen similar looking networkctl output for
> physical interfaces too but since several different states get squashed into
> 'configuring' I'm not sure if it is the same situation, it was just easier
> to demo with a .netdev and bridge. Interestingly no other mechanism for
> creating a bridge (ip or brctl) got it into the same state but I'm not sure
> why.

Not sure to be honest, I'll try to keep an eye on this, but as I said
I have not been able to reproduce.

Cheers,

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

Re: [systemd-devel] [PATCH] Fixed incorrect type for MTU

[Tom Gundersen]

On Thu, May 21, 2015 at 12:54 PM, dmoneil2  wrote:
> The parser uses size_t for MTU however the structure is defined with unsigned 
> int
> as the target type resulting in a value corruption for the next field of the 
> structure.
>
> dmoneil2 (1):
>   Fixed issue with corruption of speed value when setting on x64
> systems.
>
>  src/udev/net/link-config.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for the patch!  I now pushed a similar fix, please verify that
it works for you.

Cheers,

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

Re: [systemd-devel] [PATCH] Fixed incorrect type for MTU

[systemd github import bot]

Patchset imported to github.
Pull request:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Fixed incorrect type for MTU

[dmoneil2]

---
 src/udev/net/link-config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/udev/net/link-config.h b/src/udev/net/link-config.h
index 34facde..8bb5b79 100644
--- a/src/udev/net/link-config.h
+++ b/src/udev/net/link-config.h
@@ -66,7 +66,7 @@ struct link_config {
 NamePolicy *name_policy;
 char *name;
 char *alias;
-unsigned int mtu;
+size_t mtu;
 unsigned int speed;
 Duplex duplex;
 WakeOnLan wol;
-- 
1.8.2

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

[systemd-devel] [PATCH] Fixed incorrect type for MTU

[dmoneil2]

The parser uses size_t for MTU however the structure is defined with unsigned 
int 
as the target type resulting in a value corruption for the next field of the 
structure.

dmoneil2 (1):
  Fixed issue with corruption of speed value when setting on x64
systems.

 src/udev/net/link-config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.2

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

Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]

[Lennart Poettering]

On Wed, 20.05.15 22:40, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hey Lennart,
> 
> Lennart Poettering [2015-05-20 17:49 +0200]:
> > Nope, ConditionSecurity=audit is only a simple boolean check that
> > holds when audit is enabled at all. It doesn't tell you anything about
> > the precise audit feature set of the kernel.
> 
> Ah, thanks for the clarification.
> 
> > I have now conditionalized the unit on CAP_ADMIN_READ, which is the
> > cap that you need to read the audit multicast stuff. You container
> > manager hence should simply drop that cap fro, the cap set it passes
> > and all should be good.
> 
> Wonderful! Now it works perfectly in nspawn. (This needs to be fixed
> in unprivileged LXC containers, but that's not a systemd problem; I'll
> talk to LXC upstream about that).
> 
> With these two fixes, should we now remove the scary warning in
> README? AFAICS there is no need to turn auditing off on the host any
> more.

As mentioned before: unless you turn auditing off in the kernel,
you cannot even log into any Fedora system running in a container
(unless you have the seccomp trick on and are on x86-64). The message
hence really should stay.

Note that Debian/Ubuntu are not as restrictive regarding audit as
Fedora is. In Fedora due to government craziness failing audit will
result in refused logins, and that's the issue here.

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] Timers and Service Conditions

[Merten Sach]

Hi,

I was also able to reproduce the problem using a clean Fedora 22 Beta with
systemd 219.

Merten

On 19/05/15 16:57, Lennart Poettering wrote:
> On Thu, 02.04.15 12:01, Merten Sach (mer...@tabinin.eu) wrote:
> 
>> Hi,
>>
>> I have a problem with a timer that trigges a service that has a condition 
>> set.
>> The timer defines the following properties:
>>
>>   [Timer]
>>   OnBootSec=1h
>>   OnUnitInactiveSec=1h
>>   Unit=autobackup@%i.service
>>
>> The service unit set the following condition:
>>
>>   ConditionACPower=true
>>
>> When I'm now on AC power the service is never active and, therefor, the 
>> inactive
>> timestamp is never set. This causes the timer to be triggered repeatedly 
>> which
>> causes a very high system load.
>>
>> I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ?
> 
> Hmm, so I tried to reproduce this issue here, bu I couldn't. I used
> the same unit files as you propose, but this works cleanly, as the
> code already contains checks that if the triggered unit doesn't have
> an initialized inactive timestamp we'll fall back to the last trigger
> time of the unit. And if that's not set, we'll simply not set any
> timer...
> 
> Hence, which version of systemd did you run this into with?
> 
> Any chance you can check if you can reproduce this with current git or
> at least 219?
> 
> Lennart
> 

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

Re: [systemd-devel] How to set primary slave in active-backup mode (bonding)

[Mikhail Morfikov]

On Tue, 19 May 2015 18:12:15 +0200
Tom Gundersen  wrote:

> On Thu, Apr 9, 2015 at 4:29 PM, Mikhail Morfikov
>  wrote:
> > I usually have two network interfaces on my laptops (one eth and one
> > wlan), and when I was using sysvinit I also was configuring the bond
> > interface via the /etc/network/interfaces file so the two interfaces
> > could work in the active-backup mode. But now, they work in
> > balance-rr mode which is set via the .netdev file. The problem with
> > this mode is that when you have, let's say wifi 30mbit/s and wired
> > 100mbit/s, you can get 60mbit/s max, and that's why I wanted to use
> > the active-backup mode which switches from wire to wifi and vice
> > versa depending on whether the ethernet cable is plugged in.
> > Generally speaking, I have to set some additional parameters so
> > this could work well, and that would be:
> 
> We don't yet fully support all the bonding options.
> 
> > bond-primary eth1
> 
> This is not currently supported, I suppose we should add the
> possibility of marking a slave as 'primary' to the .network file
> (rather than listing the slave in the .netdev file).
> 
> > bond-primary-reselect always
> 
> This is PrimaryReselectPolicy=always in the .netdev file.
> 
> > bond-slaves eth1 wlan0
> 
> This is achieved by setting Bond= in the .network files applied to
> eth1 and wlan0.
> 
> > bond-fail-over-mac none
> 
> This is FailOverMACPolicy=none in the .netdev file, which is also the
> default, so is redundant.
> 
> > I'm not sure if all of them are necessary, and the question is how
> > to pass these parameters in systemd? I'm asking because in the
> > systemd.netdev manual, in the bond section, these options weren't
> > specified.
> 
> I hope the above helps, but I suspect you really need the feature to
> specify the primary slave for this to work as you intended. Happy to
> take a patch!
> 
> Cheers,
> 
> Tom

Thank you for the information.



pgpa9lyjdGv2A.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel