[systemd-devel] systemd prerelease 245-rc2

2020-03-02 Thread systemd tag bot 
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
tarball here:

https://github.com/systemd/systemd/archive/v245-rc2.tar.gz

NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Changes since the previous release:

* A new tool "systemd-repart" has been added, that operates as an
  idempotent declarative repartitioner for GPT partition tables.
  Specifically, a set of partitions that must or may exist can be
  configured via drop-in files, and during every boot the partition
  table on disk is compared with these files, creating missing
  partitions or growing existing ones based on configurable relative
  and absolute size constraints. The tool is strictly incremental,
  i.e. does not delete, shrink or move partitions, but only adds and
  grows them. The primary use-case is OS images that ship in minimized
  form, that on first boot are grown to the size of the underlying
  block device or augmented with additional partitions. For example,
  the root partition could be extended to cover the whole disk, or a
  swap or /home partitions could be added on first boot. It can also be
  used for systems that use an A/B update scheme but ship images with
  just the A partition, with B added on first boot. The tool is
  primarily intended to be run in the initrd, shortly before
  transitioning into the host OS, but can also be run after the
  transition took place. It automatically discovers the disk backing
  the root file system, and should hence not require any additional
  configuration besides the partition definition drop-ins. If no
  configuration drop-ins are present, no action is taken.

* A new component "userdb" has been added, along with a small daemon
  "systemd-userdb.service" and a client tool "userdbctl". The framework
  allows defining rich user and group records in a JSON format,
  extending on the classic "struct passwd" and "struct group"
  structures. Various components in systemd have been updated to
  process records in this format, including systemd-logind and
  pam-systemd. The user records are intended to be extensible, and
  allow setting various resource management, security and runtime
  parameters that shall be applied to processes and sessions of the
  user as they log in. This facility is intended to allow associating
  such metadata directly with user/group records so that they can be
  produced, extended and consumed in unified form. We hope that
  eventually frameworks such as sssd will generate records this way, so
  that for the first time resource management and various other
  per-user settings can be configured in LDAP directories and then
  provided to systemd (specifically to systemd-logind and pam-system)
  to apply on login. For further details see:

  https://systemd.io/USER_RECORD
  https://systemd.io/GROUP_RECORD
  https://systemd.io/USER_GROUP_API

* A small new service systemd-homed.service has been added, that may be
  used to securely manage home directories with built-in encryption.
  The complete user record data is unified with the home directory,
  thus making home directories naturally migratable. Its primary
  back-end is based on LUKS volumes, but fscrypt, plain directories,
  and other storage schemes are also supported. This solves a couple of
  problems we saw with traditional ways to manage home directories, in
  particular when it comes to encryption. For further discussion of
  this, see the video of Lennart's talk at AllSystemsGo! 2019:

  https://media.ccc.de/v/ASG2019-164-reinventing-home-directories

  For further details about the format and expectations on home
  directories this new daemon makes, see:

  https://systemd.io/HOME_DIRECTORY

* systemd-journald is now multi-instantiable. In addition to the main
  instance systemd-journald.service there's now a template unit
  systemd-journald@.service, with each instance defining a new named
  log 'namespace' (whose name is specified via the instance part of the
  unit name). A new unit file setting LogNamespace= has been added,
  taking such a namespace name, that assigns services to the specified
  log namespaces. As each log namespace is serviced by its own
  independent journal daemon, this functionality may be used to improve
  performance and increase isolation of applications, at the price of

[systemd-devel] "[Match]" section in systemd.link file doesn't match interface

2020-03-02 Thread Felix 
Hello everybody,

I'm failing to set an alias for a link using systemd-networkd. Am I
doing something wrong? Is this a bug?


I'm on this systemd version:
systemd 244 (244.3-1~bpo10+1)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

This runs on a Debian Buster inside a virtual machine hosted on a
proxmox 6.1 server, if that matters.

I'm trying to set an alias for a link using systemd-networkd, following
this documentation:
https://www.freedesktop.org/software/systemd/man/systemd.link.html#Alias= .
I put my file in /etc/systemd/network/, as
-rw-r--r-- 1 root root  56 Mär  2 14:06 ens19.link
with this content:

```
[Match]
Path=/sys/class/net/ens19

[Link]
Alias=myalias
```

I also tried to replace `Path=/sys/class/net/ens19` with
`MACAddress=be:19:32:ed:c0:61` and `OriginalName=ens19`.


After `systemctl restart systemd-networkd` or even rebooting the alias
is still not set:
```
3: ens19:  mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether be:19:32:ed:c0:61 brd ff:ff:ff:ff:ff:ff
```

I expected/want to see this:
```
3: ens19:  mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT group default qlen 1000
link/ether be:19:32:ed:c0:61 brd ff:ff:ff:ff:ff:ff
alias myalias
```

`networkctl status ens19` doesn't show my .link file: `Link File:
/usr/lib/systemd/network/99-default.link`.

`udevadm test-builtin net_setup_link /sys/class/net/ens19` prints this:
```
Load module index
Parsed configuration file /etc/systemd/network/ens19.link
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
Config file /usr/lib/systemd/network/99-default.link applies to device ens19
link_config: autonegotiation is unset or enabled, the speed and duplex
are not writable.
Using default interface naming scheme 'v240'.
ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
Unload module index
Unloaded link configuration context.
```

How can I set the link alias using systemd-networkd?

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

Re: [systemd-devel] Unsubscribe from this list

2020-03-02 Thread Reindl Harald 


Am 02.03.20 um 13:35 schrieb Lubor Kolář:
> Hi,I am trying to unsubscribe for a couple of week using the unsubscribe
> link from mail header but it is always rejected:
> 
> Address not found
> 
> Your message wasn't delivered to
> systemd-devel-requ...@lists.freedesktop.org
>  because the address
> couldn't be found, or is unable to receive mail.
> The response from the remote server was:
> 
> 550 5.1.1  >: Recipient address
> rejected: User unknown in local recipient table
> 
> 
> I suppose there is something wrong with the list configuration (either
> local recipient table is wrong or mail header instructions are outdated).
> 
> Thanks for fixing that issue

while there is something wrong you should be able to use

https://lists.freedesktop.org/mailman/listinfo/systemd-devel



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

Re: [systemd-devel] sd-daemon documentation clarification

2020-03-02 Thread Łukasz Niemier 
> AFAIK both stdout and stderr even get attached to the same journal pipe by 
> default, so they should also be interpreted in the same way.
> 
> The description of SyslogLevelPrefix= in systemd.exec(5) also says: "This 
> only applies to log messages written to stdout or stderr.”

THX, I must have missed that. This mean that the `sd-daemon` documentation page 
should be updated to contain that information as well.

--

Łukasz Niemier
luk...@niemier.pl

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

[systemd-devel] Unsubscribe from this list

2020-03-02 Thread Lubor Kolář 
Hi,I am trying to unsubscribe for a couple of week using the unsubscribe
link from mail header but it is always rejected:

Address not found

Your message wasn't delivered to systemd-devel-requ...@lists.freedesktop.org
because the address couldn't be found, or is unable to receive mail.
The response from the remote server was:

550 5.1.1 : Recipient address
rejected: User unknown in local recipient table


I suppose there is something wrong with the list configuration (either
local recipient table is wrong or mail header instructions are outdated).

Thanks for fixing that issue.

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

Re: [systemd-devel] sd-daemon documentation clarification

2020-03-02 Thread Mantas Mikulėnas 
On Mon, Mar 2, 2020 at 1:38 PM Łukasz Niemier  wrote:

> `man 3 sd-daemon` states that `SD_*` prefixes works with `stderr` logging:
>
> These prefixes are intended to be used in conjunction with stderr-based
> logging as implemented by systemd.
>
>
> But only if `StandardError=` is set to one of `journal`, `syslog`, or
> `kmsg`. Does that mean that these prefixes do not work with
> `StandardOutput=journal`?
>
> I am writing Erlang logger integration and I am just curious if I should
> force user to use `stdandard_error` output or it could work with
> `standard_output` as well.
>

AFAIK both stdout and stderr even get attached to the same journal pipe by
default, so they should also be interpreted in the same way.

The description of SyslogLevelPrefix= in systemd.exec(5) also says: "This
only applies to log messages written to stdout or stderr."

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

[systemd-devel] sd-daemon documentation clarification

2020-03-02 Thread Łukasz Niemier 
`man 3 sd-daemon` states that `SD_*` prefixes works with `stderr` logging:

> These prefixes are intended to be used in conjunction with stderr-based 
> logging as implemented by systemd.

But only if `StandardError=` is set to one of `journal`, `syslog`, or `kmsg`. 
Does that mean that these prefixes do not work with `StandardOutput=journal`?

I am writing Erlang logger integration and I am just curious if I should force 
user to use `stdandard_error` output or it could work with `standard_output` as 
well.

--

Łukasz Niemier
luk...@niemier.pl

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

Re: [systemd-devel] Ask some questions about overlay+/dev/mtdblock?

2020-03-02 Thread www 


If after uninstalling block4 and block5, I don't want overlay to have direct 
access to block4 or block5, what should I do?


thanks，
Byron







At 2020-03-02 16:21:17, "www"  wrote:

Dear all,


Systemd is used in the embedded system. and some mounting information is as 
follows:


dev on /dev type devtmpfs (rw,relatime,size=221372k,nr_inodes=55343,mode=755)
sys on /sys type sysfs (rw,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/mtdblock4 on /run/initramfs/ro type squashfs (ro,relatime)
/dev/mtdblock5 on /run/initramfs/rw type jffs2 (rw,relatime)
cow on / type overlay 
(rw,relatime,lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)


I have a question, why can overlayfs directly save the information in block4 
and block5 (such as the running information of SYSTEMd) after I uninstall 
block4 and block5 with umount command？
Who knows why, or gives some advice?


thanks,
Byron






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

Re: [systemd-devel] Ask some questions about overlay+/dev/mtdblock?

2020-03-02 Thread www 


If after uninstalling block4 and block5, I don't want overlay to have direct 
access to block4 or block5, what should I do?


thanks，
Byron







At 2020-03-02 16:21:17, "www"  wrote:

Dear all,


Systemd is used in the embedded system. and some mounting information is as 
follows:


dev on /dev type devtmpfs (rw,relatime,size=221372k,nr_inodes=55343,mode=755)
sys on /sys type sysfs (rw,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/mtdblock4 on /run/initramfs/ro type squashfs (ro,relatime)
/dev/mtdblock5 on /run/initramfs/rw type jffs2 (rw,relatime)
cow on / type overlay 
(rw,relatime,lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)


I have a question, why can overlayfs directly save the information in block4 
and block5 (such as the running information of SYSTEMd) after I uninstall 
block4 and block5 with umount command？
Who knows why, or gives some advice?


thanks,
Byron






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

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

2020-03-02 Thread Andreas Kempe 
On Thu, Feb 27, 2020 at 05:39:27PM +0200, Mantas Mikulėnas wrote:
> On Wed, Feb 26, 2020 at 11:59 AM Andreas Kempe 
> wrote:
> 
> > Hello everyone,
> >
> > I'm working in a project with an embedded Linux system based on
> > Openembedded using Systemd version 241 as our init process. We're
> > using a read-only /etc. To facilitate development, we want to use a
> > writeable overlay on /etc, but we ran into an issue.
> >
> > When we start, Systemd detects that there is no machine-id file
> > present in /etc so it generates and mounts a /etc/machine-id. When our
> > mount unit then applies the overlay on /etc, it hides the mounted
> > file. Journald later fails to start because /etc/machine-id isn't
> > visible through the overlay.
> >
> > At this point we're considering a number of workarounds, but I thought
> > it worthwhile asking the experts before we go patching Systemd or
> > similar.
> >
> > My gut feeling is that using overlays on /etc can't be that uncommon
> > and it is likely PEBKAC on our end. Is there some canonical way of
> > doing overlays with Systemd and we're screwing things up?
> >
> 
> If you have an initramfs, consider setting up the /etc overlay there
> instead.
> 

For the development assisting part of it, that is unfortunately not an
option for various reasons. We will have some overlays in the final
released product as well, but there we will mount them in the
initramfs so hopefully it won't be a problem then.

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

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

2020-03-02 Thread Andreas Kempe 
On Thu, Feb 27, 2020 at 11:53:45PM +0100, Jérémy ROSEN wrote:
> Le jeu. 27 févr. 2020 à 16:30, Andreas Kempe  a
> écrit :
> > I was contemplating whether it could be acceptable having the same
> > static machine-id file pre-generated for all systems. I'm not 100% sure
> > what it's used for, TBH; would it be a really bad idea?
> >
> 
> As long as two machines with the same machine-id are never in contact you
> should be fine...
> 
> Theoretically the machine-id should never cross the network, but you never
> know what individual apps might do
> 
> The only place where that could be problematic is the journal : if you mix
> the logs of multiple machines with the
> same machine-id, you won't be able to tell them appart and that might have
> other side-effects I wouldn't know about...
> 

AFAIK, we don't use the ID for anything in our own software and mixing
logs up shouldn't really be an issue, I think. I'll keep it in mind as
a potential workaround if nothing else.

Thank you for the help!
Cordially,
Andreas Kempe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Ask some questions about overlay+/dev/mtdblock?

2020-03-02 Thread www 
Dear all,


Systemd is used in the embedded system. and some mounting information is as 
follows:


dev on /dev type devtmpfs (rw,relatime,size=221372k,nr_inodes=55343,mode=755)
sys on /sys type sysfs (rw,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/mtdblock4 on /run/initramfs/ro type squashfs (ro,relatime)
/dev/mtdblock5 on /run/initramfs/rw type jffs2 (rw,relatime)
cow on / type overlay 
(rw,relatime,lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)


I have a question, why can overlayfs directly save the information in block4 
and block5 (such as the running information of SYSTEMd) after I uninstall 
block4 and block5 with umount command？
Who knows why, or gives some advice?


thanks,
Byron

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