Re: [systemd-devel] [ANNOUNCE] systemd 215
On Thu, Jul 3, 2014 at 10:59 PM, Lennart Poettering lenn...@poettering.net wrote: Heya! A lot of work to make factory reset, stateless systems and disconnected updates working. A lot of networkd love (dhcp4 server!) and coredumpctl is now finally really really useful. http://www.freedesktop.org/software/systemd/systemd-215.tar.xz Enjoy! CHANGES WITH 215: * A new tool systemd-sysusers has been added. This tool creates system users and groups in /etc/passwd and /etc/group, based on static declarative system user/group definitions in /usr/lib/sysusers.d/. This is useful to enable factory resets and volatile systems that boot up with an empty /etc directory, and thus need system users and groups created during early boot. systemd now also ships with two default sysusers.d/ files for the most basic users and groups systemd and the core operating system require. * A new tmpfiles snippet has been added that rebuilds the essential files in /etc on boot, should they be missing. * A directive for ensuring automatic clean-up of /var/cache/man/ has been removed from the default configuration. This line should now be shipped by the man implementation. The necessary change has been made to the man-db implementation. Note that you need to update your man implementation to one that ships this line, otherwise no automatic clean-up of /var/cache/man will take place. * A new condition ConditionNeedsUpdate= has been added that may conditionalize services to only run when /etc or /var are older than the vendor operating system resources in /usr. This is useful for reconstructing or updating /etc after an offline update of /usr or a factory reset, on the next reboot. Services that want to run once after such an update or reset should use this condition and order themselves before the new systemd-update-done.service, which will mark the two directories as fully updated. A number of service files have been added making use of this, to rebuild the udev hardware database, the journald message catalog and dynamic loader cache (ldconfig). The systemd-sysusers tool described above also makes use of this now. With this in place it is now possible to start up a minimal operating system with /etc empty cleanly. For more information on the concepts involved see this recent blog story: http://0pointer.de/blog/projects/stateless.html * A new system group input has been introduced, and all input device nodes get this group assigned. This is useful for system-level software to get access to input devices. It complements what is already done for audio and video. * systemd-networkd learnt minimal DHCPv4 server support in addition to the existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6 Router Solicitation client support. The DHCPv4 client gained support for static routes passed in from the server. Note that the [DHCPv4] section known in older systemd-networkd versions has been renamed to [DHCP] and is now also used by the DHCPv6 client. Existing .network files using settings of this section should be updated, though compatibility is maintained. Optionally, the client hostname may now be sent to the DHCP server. * networkd gained support for vxlan virtual networks as well as tun/tap and dummy devices. * networkd gained support for automatic allocation of address ranges for interfaces from a system-wide pool of addresses. This is useful for dynamically managing a large number of interfaces with a single network configuration file. In particular this is useful to easily assign appropriate IP addresses to the veth links of a large number of nspawn instances. * RPM macros for processing sysusers, sysctl and binfmt drop-in snippets at package installation time have been added. * The /etc/os-release file should now be placed in /usr/lib/os-release. The old location is automatically created as symlink. /usr/lib is the more appropriate location of this file, since it shall actually describe the vendor operating system shipped in /usr, and not the configuration stored in /etc. * .mount units gained a new boolean SloppyOptions= setting that maps to mount(8)'s -s option which enables permissive parsing of unknown mount options. * tmpfiles learnt a new L+
Re: [systemd-devel] [ANNOUNCE] systemd 215
2014-07-08 16:41 GMT+02:00 Umut Tezduyar Lindskog u...@tezduyar.com: Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. How would you transfer the coredumps if network is not up? And if the network is up, you might just mount a network share. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
On Tue, Jul 08, 2014 at 04:41:59PM +0200, Umut Tezduyar Lindskog wrote: * systemd-coredump may now optionally store coredumps directly on disk (in /var/lib/systemd/coredump, possibly compressed), instead of storing them unconditionally in the journal. This mode is the new default. A new configuration file /etc/systemd/coredump.conf has been added to configure this and other parameters of systemd-coredump. Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. Storing the coredumps in the journal and forwarding the logs to a different host, once that's available, might work. If that's too much overhead, than I think the option with mounting /var/lib/systemd/coredump over the network is the only option. Capacity of an embedded product might not be enough to store multiple dumps. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
On Tue, 08.07.14 16:41, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: * systemd-coredump may now optionally store coredumps directly on disk (in /var/lib/systemd/coredump, possibly compressed), instead of storing them unconditionally in the journal. This mode is the new default. A new configuration file /etc/systemd/coredump.conf has been added to configure this and other parameters of systemd-coredump. Are there any thoughts about natively sending coredumps over network? I guess it is possible now by mounting /var/lib/systemd/coredump to a network drive but dumps occuring before network is up need to be transferred too. Capacity of an embedded product might not be enough to store multiple dumps. I'd enjoy if we have some component that usees the journal remote stuff to POST all log messages of level LOG_CRIT and above to some server or so, and then coredumps would just be payload for that. This would of course then mean to store the coredumps in the journal itself. Which is not the default anymore. To make this scheme more useful we should probably extend the local logging protocol of the journal to allow sending over compressed blobs which are stored as is in the journal. THis way, it wouldn't be journald that potentially compresses huge blobs, but the coredump hook. 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] [ANNOUNCE] systemd 215
On Fri, 04.07.14 06:25, Andrey Borzenkov (arvidj...@gmail.com) wrote: В Thu, 3 Jul 2014 22:59:57 +0200 Lennart Poettering lenn...@poettering.net пишет: * A new command systemctl is-system-running has been added that allows checking the overall state of the system, for example whether it is fully up and running. Is it more reliable than simply waiting for idle? At which point systemd considers system fully up? This is precisely what it does, it waits until for the first time all jobs have been dispatched. Note that the command will output more than just a boolean: starting → the first time all jobs have been dispatched has not been reached yet stopping → a shutdown job has been queued running → fully up and running in normal operation, and nothing failed maintenance → up and running in rescue or emergency mode degraded → fully up and running in normal operation, but at least one unit failed 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] [ANNOUNCE] systemd 215
2014-07-04 0:59 GMT+04:00 Lennart Poettering lenn...@poettering.net: * systemd-networkd learnt minimal DHCPv4 server support in addition to the existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6 Router Solicitation client support. The DHCPv4 client gained support for static routes passed in from the server. Note that the [DHCPv4] section known in older systemd-networkd versions has been renamed to [DHCP] and is now also used by the DHCPv6 client. Existing .network files using settings of this section should be updated, though compatibility is maintained. Optionally, the client hostname may now be sent to the DHCP server. Nice! Does it possible now to use systemd-networkd with radv server and autogenerate address with advertised prefix? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
On Fri, 04.07.14 15:00, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: 2014-07-04 0:59 GMT+04:00 Lennart Poettering lenn...@poettering.net: * systemd-networkd learnt minimal DHCPv4 server support in addition to the existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6 Router Solicitation client support. The DHCPv4 client gained support for static routes passed in from the server. Note that the [DHCPv4] section known in older systemd-networkd versions has been renamed to [DHCP] and is now also used by the DHCPv6 client. Existing .network files using settings of this section should be updated, though compatibility is maintained. Optionally, the client hostname may now be sent to the DHCP server. Nice! Does it possible now to use systemd-networkd with radv server and autogenerate address with advertised prefix? networkd only contains a dhcp4 server, not a dhcp6 or router solicitation server. Hopefully we'll get that soon too. 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] [ANNOUNCE] systemd 215
2014-07-04 21:13 GMT+04:00 Lennart Poettering lenn...@poettering.net: networkd only contains a dhcp4 server, not a dhcp6 or router solicitation server. Hopefully we'll get that soon too. I need client support. I'm already have server (bird routing daemon, that advertise prefixes). -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
В Thu, 3 Jul 2014 22:59:57 +0200 Lennart Poettering lenn...@poettering.net пишет: * A new command systemctl is-system-running has been added that allows checking the overall state of the system, for example whether it is fully up and running. Is it more reliable than simply waiting for idle? At which point systemd considers system fully up? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
