Date: Thu, 07 Nov 2019 22:23:12 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Creating /etc/os-release Message-ID: <201911080623.xA86NCcO070007@slippy.cwsent.com> In-Reply-To: <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@mail.gmail.com> References: <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CANCZdfre=jOatW-A1Ke3X10Tt1hPq3ePmR0KpWfFX9z7w9cK3Q@mail.gmail.c om> , Warner Losh writes: > Greetings, > > A standard has evolved in other communities to communicate certain key > aspects of the system to interested parties. The /etc/os-release file. The > standard is defined here http://0pointer.de/blog/projects/os-release and > here https://www.freedesktop.org/software/systemd/man/os-release.html . It > has become a de-facto standard for the graphical systems. > > FreeBSD currently tries to address this with a port > sysutils/etc_os-release, but there's a number of issues with it, see for > example https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238953. The > biggest issue being that we can't install a static file: it has to change > as the system is updated. > > To that end, I propose the following: First, we create a /etc/os-release > symlink to /var/run/os-release. This will place the file in the standard > place, but allow its generation on each boot in a friendly to > read-only-root manner. Second, we create a /etc/rc.d/os-release script that > will populate /var/run/os-release. Since this is a standard rc script, we > can allow people to opt-out of generating this file in a standardized way > (although it contains information that's available to anybody on the > system, some reduced configurations may not have all the scripts / programs > used to generate it). If the file isn't generated, then opening it will > return the same not found error as before. Since this is a symlink, it's > friendly to etcupdate / mergemaster updating schemes. Finally, we'd > obsolete the port since it is flawed anyway. > > I opted for every boot rather than a file in /etc that gets generated as > part of mergemaster / etcupdate because it's more robust (the change > happens right away, and works in all environments, even if /etc isn't > updated). The amount of work here is tiny as well, so all but the most > demanding of users won't notice it at all. While this does come from the > Linux community, it has become a de-facto standard. DragonflyBSD has it, > for example, since 9c172c37, but their implementation is flawed for us to > use directly since it creates it at installworld time and we don't touch > /etc as part of installworld. We also have a port, but there's enough flaws > in the port approach that we should just make this be part of the base > system to place nicely with software that expects it today. It also means > we don't need hacks for freebsd-update. Finally, since this change is > additive, we can also MFC it to 12. > > I've created a change that I think covers all these aspects. Please see > https://reviews.freebsd.org/D22271 for the specifics. Comments about the > code should go there, while comments about the plan should go here. And, with pkgbase, assign it the actual release of the O/S so that we can do pkg info -aI | grep ... similar to rpm -aq | grep ... Why? Automation such as HP SA, Tower, cfengine, and others could be used to query package names in a mysql or Oracle database of packages. One could write an sql query to display all servers in a network with, for examle, package freebsd-12.1 (or whatever we choose to call it) installed. Of course this wouldn't work with -current or -stable unless installworld generates the appropriate package registrations at the time. Users of binary releases based on -RELEASE might see immediate benefit though. This might help integration into large shops -- making FreeBSD more visible to shops at the enterprise level -- which use that sort of automation. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201911080623.xA86NCcO070007>