From owner-freebsd-arch@freebsd.org Fri Nov 8 06:37:48 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AFB4D1A8B4F for ; Fri, 8 Nov 2019 06:37:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 478VvH50Hwz3x8d for ; Fri, 8 Nov 2019 06:37:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf29.google.com with SMTP id n12so1806804qvt.1 for ; Thu, 07 Nov 2019 22:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2dfCk60t6E37E14fvB35W/pj/npMsNoxCKlqoALNy5E=; b=F/yuKipeEidF2tMYnG4dvTa6RWCkP8nY7OBFAPD8tRNJvpnUGdDKVJ8lOeOKet217q za8sUEDWxYFjJmyWLkKQSXOXWDL9NYBLuwh9Rsq7MoZzvkGWm10Somj8KIrL2kbFZ9Tc gcGroRZsQUCZtLLq04oOOr0AG9QbIlDr86cYTNQWNSBJlkUvPwu/wQfqQbi2dFedoihH YhGNuyWhbQGSIuw7G1DahANYRIYnNNvLEyjm5R47sA19tZpf0k46Jj2Rjezt7gnKYI5v sebrd4eoJZ/nThU1q1dUsaE34y9W2clRGZGpKzjMplcbeqVgoxPrbU3aajvQ9PfD/PiL ZlkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2dfCk60t6E37E14fvB35W/pj/npMsNoxCKlqoALNy5E=; b=F+TzZB503U1cj5IJ0YPJga1XdFoSsYPzIH5x5lyK8MXR3tMtC+ZyBz617Mo+NKUc3R Xlo8YCvMTGd4IgYbqfrKA7EKgmp+CG+cGovFWwDVG1TLqXd6cLQsRPrXTLCHXGYyyWL6 SC+TQDutwZWJGkCB0q1IaxKi2WXWLTpYxagq16uVur+tWba5Wy2ohLMLeoU2ZHgy8bkP JeRlJtRGfV+oiNguchZfuwLg3jk9S6f3kTmbzlryZPv2EPPNHC00e3KumcMnYoQcbnGY POQdR2UkN8vx9M79wH2pGqVgR4DGjBlSGJ2GjTQEnd7K7YrgdrV+3PYkwntAz4O99+bJ 9+uw== X-Gm-Message-State: APjAAAUnpiB035aE2uaDms5KiVfXO2Mo+iL+rKFZaK6jUfolV1ISuFxt rYmZ9v0nVqdCSwTMlY79OHezPF3sNjcP0zYw4sLO0x4Nzms= X-Google-Smtp-Source: APXvYqzfoRixeMCk4MoHjYJJXJoC7DENHVLx59PSLLtAWt+Tk8zeiE7thbZE1lW2/X2dZ9098CJ2h8AXmMy3ycFBdmA= X-Received: by 2002:a0c:f8d1:: with SMTP id h17mr8057022qvo.125.1573195060813; Thu, 07 Nov 2019 22:37:40 -0800 (PST) MIME-Version: 1.0 References: <201911080623.xA86NCcO070007@slippy.cwsent.com> In-Reply-To: <201911080623.xA86NCcO070007@slippy.cwsent.com> From: Warner Losh Date: Thu, 7 Nov 2019 23:37:29 -0700 Message-ID: Subject: Re: Creating /etc/os-release To: Cy Schubert Cc: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 478VvH50Hwz3x8d X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=F/yuKipe; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.88)[ipnet: 2607:f8b0::/32(-2.34), asn: 15169(-2.01), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 06:37:48 -0000 On Thu, Nov 7, 2019, 11:23 PM Cy Schubert wrote: > In message > 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. It seems like pkg info would need some careful thought to know what to report to maximize the benefits of the automation you want. It seems to me you'd want more exact version info than what's customary for os-release. It isn't clear to me the needs of this file from a compatibility with other systems standpoint match well with what rpm -aq reports that you'd like pkg to report. It's a good idea, but I'm having trouble connecting the dots with the problem I'm trying to solve here. Warner -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > >