[systemd-devel] CODENAME field in /etc/os-release
Hello, I have tried to search the archives of this mailing list for "CODENAME" but that searched the entire freedesktop.org site... Anyway, at the danger that this has been discussed before, I'd like to make this Proposal: Add CODENAME as an officially described field to /etc/os-release. Its value would be the release code name, for human consumption. It would be optional. If not specified, it would have no default. Justification: The benefit of adding this field is that this is the only information from other release files that is still missing from /etc/os-release (compared to the output of the lsb_release command, ignoring LSB compliance information for the moment, and compared to the older one-line distro release files). Therefore, this helps with the migration from these other file formats to /etc/os-release. Alternatives considered: According to the description of extension fields in http://www.freedesktop.org/software/systemd/man/os-release.html, a field with this name should not be added by OS vendors as an extension field, because the highly recommended convention for extension field names is to prefix them with an OS specific name. So the alternative of a distro specific extension field is not good for this purpose, and the only reasonable option is to have a standard field. Comments? Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "labeling for /sys/fs/cgroup mount point"
Hi Fi, https://bugzilla.redhat.com/show_bug.cgi?id=1274958#c5 Is it expected that this will be resolved here/upstream, or is it specificum for Fedora/downstream? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CODENAME field in /etc/os-release
Use the existing fields as in NAME= VERSION= ID= VERSION_ID= PRETTY_NAME= VARIANT= VARIANT_ID= Adding additional codename field serves no purpose or value which the previous fields do not already cover. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CODENAME field in /etc/os-release
Unknown [2016-01-13 14:23 +0100]: > You shouldn't ask yourself where can i find the codename, but rather > what do I want to do with it? > - display it to the user or otherwise describe it in human readable > text? use PRETTY_NAME if the distribution isn't obvious, or VERSION if > it is. > - anything else? are you sure the codename is fit for the job? On deb-based distributions the code name is used for specifying the package sources. For example, deb http://archive.ubuntu.com/ubuntu/ xenial main where "xenial" is the code name of the distribution. For Debian those are "wheezy", "jessie", "unstable", and so on. The request to add a code name to os-release has come up several times on our side too, and right now we add it as "UBUNTU_CODENAME=", as per os-release(5). Standardizing to "CODENAME" would be preferrable, obviously. > and what would you do on systems not using a codename? for example > archlinux? Nothing at all would change for them, as the field wouldn't be mandatory. Other fields like "VARIANT" don't make sense in a lot of use cases either, after all. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] CODENAME field in /etc/os-release
Johann, The description for /etc/os-release makes only this (quite informal) statement about the release code name: VERSION: A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This does not even recommend what the syntax should be. VERSION_ID, VARIANT_ID are definitely out of question for putting it there, and IMO also NAME and VARIANT. The statement about having it in PRETTY_NAME is even more informal than the one for VERSION. Bottom line is for someone deciding to add a release code name, there is room for doing that. However, I'm on the parsing side of this. From that perspective, this is not a question about having a possibility for putting the release code name somewhere, but where to expect it. A standard field named CODENAME is obviously superior compared to putting the release code name somewhere, even if there is a recommendation on the syntax (that people can and will choose not to follow, e.g. for compatibility reasons). Also, adding a new field is a backwards compatible change for distributions, whereas changing the value of an existing field may not be (depending on the existing parsing code). Even lsb_release, as little as it provides, has a code name field described. See http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html For distributions that have /etc/os-release and do not have lsb_release (there seem to be many of them), this missing field is a reason still to parse the one-line distro files. Andy On 01/13/2016 12:04 PM, Jóhann B. Guðmundsson wrote: Use the existing fields as in NAME= VERSION= ID= VERSION_ID= PRETTY_NAME= VARIANT= VARIANT_ID= Adding additional codename field serves no purpose or value which the previous fields do not already cover. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CODENAME field in /etc/os-release
On wo, 2016-01-13 at 13:04 +0100, Andreas Maier wrote: > Johann, > The description for /etc/os-release makes only this (quite informal) > statement about the release code name: > > VERSION: A string identifying the operating system version, > excluding any OS name information, possibly including a release code > name, and suitable for presentation to the user. > > This does not even recommend what the syntax should be. Because there is no syntax for it, similar to "This specification assigns no meaning to the value of the string, the contents are at the discretion of the distribution provider." even though it's mostly seen in the form of "$versionnumber ($codename)", but relying on that would be a bad idea. > VERSION_ID, VARIANT_ID are definitely out of question for putting it > there, and IMO also NAME and VARIANT. > > The statement about having it in PRETTY_NAME is even more informal > than the one for VERSION. > > Bottom line is for someone deciding to add a release code name, there > is room for doing that. > > However, I'm on the parsing side of this. From that perspective, this > is not a question about having a possibility for putting the release > code name somewhere, but where to expect it. A standard field named > CODENAME is obviously superior compared to putting the release code > name somewhere, even if there is a recommendation on the syntax (that > people can and will choose not to follow, e.g. for compatibility > reasons). You shouldn't ask yourself where can i find the codename, but rather what do I want to do with it? - display it to the user or otherwise describe it in human readable text? use PRETTY_NAME if the distribution isn't obvious, or VERSION if it is. - anything else? are you sure the codename is fit for the job? codenames can be pretty much anything. and what would you do on systems not using a codename? for example archlinux? below the os-release of systems I (co)maintain: -- NAME="Arch Linux" ID=arch PRETTY_NAME="Arch Linux" ANSI_COLOR="0;36" HOME_URL="https://www.archlinux.org/; SUPPORT_URL="https://bbs.archlinux.org/; BUG_REPORT_URL="https://bugs.archlinux.org/; -- NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/; BUG_REPORT_URL="https://bugs.centos.org/; CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" -- PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=debian HOME_URL="http://www.debian.org/; SUPPORT_URL="http://www.debian.org/support/; BUG_REPORT_URL="https://bugs.debian.org/; -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Variables in the [Unit] section of a server
Hello, Is is possible to set a variable in the [Unit] section of a service? For example in rpc-gssd.service there is ConditionPathExists=/etc/krb5.keytab but for some installation the krb5.keytab is in a different place. The rpc.gssd daemon can be told this by setting a command line argument from the EnvironmentFile. So people have to edit both the EnvironmentFile and the rpc-gssd.service to make this change. So it would be nice if only the EnvironmentFile need to be edit and the change would happen in both places. Possible? steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Variables in the [Unit] section of a server
Am 13.01.2016 um 16:51 schrieb Steve Dickson: Is is possible to set a variable in the [Unit] section of a service? For example in rpc-gssd.service there is ConditionPathExists=/etc/krb5.keytab but for some installation the krb5.keytab is in a different place. The rpc.gssd daemon can be told this by setting a command line argument from the EnvironmentFile. So people have to edit both the EnvironmentFile and the rpc-gssd.service to make this change. So it would be nice if only the EnvironmentFile need to be edit and the change would happen in both places. Possible? sadly no, i would even have usescases to start ExecStart with var from an EnvironmentFile but see the latest discussion about EnvironmentFile and you can guess how much support you can expect... http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/35157 https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg34887.html 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] CODENAME field in /etc/os-release
On Wed, 13.01.16 11:53, Andreas Maier (andreas.r.ma...@gmx.de) wrote: > Hello, > I have tried to search the archives of this mailing list for "CODENAME" but > that searched the entire freedesktop.org site... > > Anyway, at the danger that this has been discussed before, I'd like to make > this > > Proposal: > > Add CODENAME as an officially described field to /etc/os-release. > > Its value would be the release code name, for human consumption. > It would be optional. If not specified, it would have no default. We have one string already that is explicitly for human consumption, and where distros can put whatever they desire to place in there, and that's PRETTY_NAME. I am not sure what the case could be for defining another field for human consumption. Or in other words, if your distro does code names, then place it in the PRETTY_NAME. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] known but not-listed units
hi all, i'm having following situation on a centos 7.2 system (systemd-219-19.el7) there is a sysvinit service called netconsole that is not listed as a unit or unitfile, but the unitfile was generated and systemctl seems to be able to handle the unit. the only odd issue is that this service is not enabled (chkconfig shows all levels as off). this system has otehr sysvinit services that do show up as units (but for those, at least one level is on) is this "normal"? and what sort of units exits that are not listed as units or unitfiles in general? i pasted some output below, hope this helps many thanks, stijn > [root@test2200 ~]# chkconfig --list netconsole > > Note: This output shows SysV services only and does not include native > systemd services. SysV configuration data might be overridden by native > systemd configuration. > > If you want to list systemd services use 'systemctl list-unit-files'. > To see services enabled on particular target use > 'systemctl list-dependencies [target]'. > > netconsole0:off 1:off 2:off 3:off 4:off 5:off 6:off > [root@test2200 ~]# systemctl list-units --all |grep netconsole > [root@test2200 ~]# systemctl list-unit-files --all |grep netconsole > [root@test2200 ~]# systemctl show netconsole.service |grep generator > Documentation=man:systemd-sysv-generator(8) > FragmentPath=/run/systemd/generator.late/netconsole.service > [root@test2200 ~]# systemctl status netconsole.service > ● netconsole.service - SYSV: Initializes network console logging >Loaded: loaded (/etc/rc.d/init.d/netconsole) >Active: inactive (dead) > Docs: man:systemd-sysv-generator(8) > [root@test2200 ~]# ls -l /run/systemd/generator.late/netconsole.service > -rw-r--r-- 1 root root 453 Jan 13 14:49 > /run/systemd/generator.late/netconsole.service > [root@test2200 ~]# cat /run/systemd/generator.late/netconsole.service > # Automatically generated by systemd-sysv-generator > > [Unit] > Documentation=man:systemd-sysv-generator(8) > SourcePath=/etc/rc.d/init.d/netconsole > Description=SYSV: Initializes network console logging > Before=shutdown.target > Conflicts=shutdown.target > > [Service] > Type=forking > Restart=no > TimeoutSec=5min > IgnoreSIGPIPE=no > KillMode=process > GuessMainPID=no > RemainAfterExit=yes > ExecStart=/etc/rc.d/init.d/netconsole start > ExecStop=/etc/rc.d/init.d/netconsole stop ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] known but not-listed units
Am 13.01.2016 um 17:26 schrieb Stijn De Weirdt: i'm having following situation on a centos 7.2 system (systemd-219-19.el7) there is a sysvinit service called netconsole that is not listed as a unit or unitfile, but the unitfile was generated and systemctl seems to be able to handle the unit becaus enobody created a systemd-unit and there is still "/etc/init.d/netconsole" 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] known but not-listed units
13.01.2016 19:26, Stijn De Weirdt пишет: > hi all, > > i'm having following situation on a centos 7.2 system (systemd-219-19.el7) > > there is a sysvinit service called netconsole that is not listed as a > unit or unitfile, but the unitfile was generated and systemctl seems to > be able to handle the unit. > > the only odd issue is that this service is not enabled (chkconfig shows > all levels as off). > this system has otehr sysvinit services that do show up as units (but > for those, at least one level is on) > > is this "normal"? and what sort of units exits that are not listed as > units or unitfiles in general? > Unit is generated from initscript, that is correct. It seems that list-unit-files explicitly skips generated units. I do not know if this is intentional. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] known but not-listed units
>> i'm having following situation on a centos 7.2 system >> (systemd-219-19.el7) >> >> there is a sysvinit service called netconsole that is not listed as a >> unit or unitfile, but the unitfile was generated and systemctl seems to >> be able to handle the unit > > becaus enobody created a systemd-unit and there is still > "/etc/init.d/netconsole" but it is properly generated like all other sysvinit services (/run/systemd/generator.late/netconsole.service exists and is non-empty) stijn > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
