From owner-freebsd-arch@freebsd.org Thu Nov 7 18:10:52 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 C85671BBCAB for ; Thu, 7 Nov 2019 18:10:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 478BKR2md2z44C4 for ; Thu, 7 Nov 2019 18:10:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id m16so2804457qki.11 for ; Thu, 07 Nov 2019 10:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QIJbdfCKcQcfiRGqypqKTKTKDFLh73/MCdpRQLtvRmY=; b=XqnQGHwQU3MabOE7dUB7vHLTmVPXRd6hrSTlsq+B1Qg+ShscjFj+ks/w1rifs3IDDL cpcuRqwlB+qyzf1WeJmJUpLIk/Emg2nJ6CpUsYTpDKFAZSgh7TV+OnBrk2B7fY0+UbdB 64N3RYNrIb6K8Yg3KbjSTN/3S/OR+DzSSrjB4LCMdlpJKjpz1UDKz1E8jL2W4fA6kcJu JGjWguXfRMM8thLomKLZxoA0GXInD/nyuu1ZLh7pv/6FIuiN8Q1p7tKcb3WS9eJp1fz5 nSTQrZLE3QCzxZUc65ba3xcxZ7TuielyJ9tlPW/DVDMLqqGdihnGb7aAiepZ1ih3Wlre HIpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QIJbdfCKcQcfiRGqypqKTKTKDFLh73/MCdpRQLtvRmY=; b=I9zkRKFFnOdSzHPJ5WmN6DXVGFBQ/IZjcI22HXe7B3P4myNJQfJtwvRTKL1l4z4H6K 9viu3i+8Dz8wBCIScNusnKvKyLUUeWFCOiE8xh6HIBCJWom+WTYWbqBrdxpPgBBCokMB +ySmbv/BcUSDkHHUIa4Tr9wokU5V9ggVPO5bKwewSmB95VxseWwLqoDns3+JqsnfmHbf hzhQru7zmj11lUMSD56KEX92kSAf/Ho2jUYqVbMBLmlne2T9u/y94ABOJJRjKzCUtpaq POBatLLrpxcTMGPqjkkYnRqTYTP2xWGRlKl3WSNDlSr+0a/blQ2ERIIlD+ouGGSp8MYT 2vqA== X-Gm-Message-State: APjAAAXKmNZgypZzh28ZksOw8qJvtH5ySukIhULC7sGA0xsnG+NCPA1X AEGXEhlO7QoE55KKeo00zJxar8kOExiHUwTDnE7tvW3Jrphr0w== X-Google-Smtp-Source: APXvYqw5sdo4olF0I6AjlsQIDgPTOpV1Cln0S2YUBhtF9PVU/ZkzCcWMFc/dwlO6OqPN8T7OCqksz8Pf+gFjkWMoqNg= X-Received: by 2002:a37:b0c5:: with SMTP id z188mr4299530qke.215.1573150249618; Thu, 07 Nov 2019 10:10:49 -0800 (PST) MIME-Version: 1.0 From: Warner Losh Date: Thu, 7 Nov 2019 11:10:38 -0700 Message-ID: Subject: Creating /etc/os-release To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 478BKR2md2z44C4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=XqnQGHwQ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::729) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(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]; URI_COUNT_ODD(1.00)[13]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[9.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.73)[ip: (-9.24), ipnet: 2607:f8b0::/32(-2.35), 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: Thu, 07 Nov 2019 18:10:52 -0000 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. Warner From owner-freebsd-arch@freebsd.org Fri Nov 8 05:14:20 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 946721A75CD for ; Fri, 8 Nov 2019 05:14:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 478T2z3b8Vz3P5X for ; Fri, 8 Nov 2019 05:14:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x741.google.com with SMTP id q70so4176049qke.12 for ; Thu, 07 Nov 2019 21:14:19 -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=QvIgJSg4SnpRqc84x14HsRzbwrIHEQ0GUWDg9WB2pgo=; b=Tm2XNkguyqAJBcE4HSrCrNrf/9YQZ6Do+jZ5wLdJaDsQtc6b5AfQEqBWfnJKMF9yGG 9ugEh7w6dx04CLYBe5wM+vib4mYZR/BSNVCt3GqHYjmKwqrRh2CVHrcM/vu3EOOBEsLh yfKwr/gj+6sk86DcYw+tKL7/tkbIf/H0rhVUDU3vRq61r0NuCYlt/hsRZmAuUJL4/LcR 2mYudqYs/XN6eUJVu3MVHvB4tUe5THghA5v07vkQ/GnOEb16AMu4T9yG5opFSnL8/yq5 pGXmnM7gSjc4Ps7L4WTLQ2K+cCYH0qfln/DBwJyTb9890XskjlD/R1uM7taOmB3YFrNi rSPw== 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=QvIgJSg4SnpRqc84x14HsRzbwrIHEQ0GUWDg9WB2pgo=; b=czFpZVvwufc6wLVjkC+0vLqEjBvBDkttZ6lGBo9p9Bvu21hN6kfgjzIkOk6L7ugHAk OIG4j/LWcxAnb6P9bLrwXDneuGeb4Vi6VY/B4bn7YtAgxxX6dLTyAUbycQnxSBgeXnnU pSc81+AFtfjt2tzQpz6AXnrwM+lQPO3BnoeyaCRMwQn2Y/Xba/KYdz7doFWyySTYrxJg 9iDxznvF02txn8fIBq/612Xosc4/pH44jaRJ+EbdyZXho7KeXUKrXSdub37SI4CibrGj C7k41oofDUcc9k5g8diDMfvLlVdp8EfZWSH9hBZ6iGkUaNOnUh/G+3Bpwrma7DsNlaZ3 SfhQ== X-Gm-Message-State: APjAAAUvK9QRi/Y8UQkTZ41dsT+kK9K2ZGNebxcYSUsQzRBdVfOFUbR6 u0y8hZE9qxM/vVJnSJs1WEQ1aWdpP+2/JKQNt5pWOvkTJuY= X-Google-Smtp-Source: APXvYqxHwOuSY0cDXvXuTfkCDBCf8WJtR2wmXuVa/00CdphDoLZbr8Wj6c0nxMUVPwJAlSGhRdol2uwmfBrGY8cI/9M= X-Received: by 2002:a37:b07:: with SMTP id 7mr6435513qkl.240.1573190058004; Thu, 07 Nov 2019 21:14:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 7 Nov 2019 22:14:06 -0700 Message-ID: Subject: Re: Creating /etc/os-release To: MJ Cc: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 478T2z3b8Vz3P5X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Tm2XNkgu; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::741) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.39 / 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]; RCVD_IN_DNSWL_NONE(0.00)[1.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.39)[ip: (2.45), 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 05:14:20 -0000 On Thu, Nov 7, 2019, 3:39 PM MJ wrote: > > On 8/11/2019 5:10 am, Warner Losh wrote: > > 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. > > First off, I'm not attempting to be antagonistic about this, I have no > horse in this race. However, I am genuinely curious about why this is > needed and to that end why it adds more clutter to the system. > > So, forgive me, but why is this needed? Ok, it's a "standard" but for what > reason is there to add it specifically to FreeBSD? > FreeBSD implements industry standards. This is a new standard that creates friction for our users because they have to do extra things that users of other systems get without doing anything. > > 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. > > I see one issue. The issue is with the port itself, not FreeBSD. Does > FreeBSD fail to operate with this file missing? What ports are failing with > this missing? > Lots of desktop programs have issues. In my own use cases, our servers run fine without it. My desktop runs fine > without it. I'm not seeing the compelling reason. Sorry. > You can ignore it. I'm sure there are at least 2 extra firewalls you are ignoring or doing something to disable... > 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. > > So, the file is not needed, it will be nice to have, but I still can't see > a compelling reason to have it. > You are free to set osrelease_enable=NO in /etc/rc.conf if you don't want it. Just because it's a "standard" in Linux doesn't offer up to me a compelling > reason for its integration into the system. > It is standard on other systems. It causes friction to our users because we don't have it. It fits best into the base due to the location and the need to update when we update the system. Warner I am keen to hear those reasons; genuinely. > > Regards > > Mark > > > From owner-freebsd-arch@freebsd.org Fri Nov 8 05:24: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 92A661A7B17 for ; Fri, 8 Nov 2019 05:24:48 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 478TH35S55z3Pg7 for ; Fri, 8 Nov 2019 05:24:47 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pl1-x62f.google.com with SMTP id y24so3260197plr.12 for ; Thu, 07 Nov 2019 21:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=cJcrqiYcwFR/gSODP7cAVfxXX2kNdFGpb+DHCVRV1mk=; b=MVPQbamnVAApOCcmiManJe7Kdmw5uC2jtkgXn1bWZmgqinmhwBknOIL68C8LiThHwj suFNGYJyzWMhjvBBTyoVpD5Ol6z9mZy+M6w31dnsDVfz+nyYDnyBUWnfy3ZlYkkG+Fuj qeF3nHrjDwPl4ZNaZJfwLZCqlI+dZMV100hvNh3WRvaBnZ7AfgxHAS3RpP+9dMceNdfE +ZCbTnqb1ks5YuOrzEiqMwUUFHBLrkYQiokjaZ9OKYT8Z37ffrIjFF6oD87jLn83BptY Z7FtsX1UqWwPqg64wqE5Vwpmdr7OPy7cyw9wpDxaN5fIr+XAtsGR8vtHP6HAGKeoyuC9 k0og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=cJcrqiYcwFR/gSODP7cAVfxXX2kNdFGpb+DHCVRV1mk=; b=MQvzhF55LAb9ci5FE1iCuzdwl/2uNiO0ALvaOEss0HYyH9K5IvUuRfKIowL7lBo/bv ioPzSr8VQoPE0GA0VYfcGtrnr+5mOhlm3ujpjjPfzkpQBguOf3qnfICHe2aEX3jK17KS YC8uV8Qa6hSwjBSJ9zl/Je3pa592qmvvZlORMHPj5ttHtuqjvDpbfMl58ICW9jwmHNau Smy7P9azsunWDfmL+j1kRbtF8kIkbSCtTfkon2Xsr79gaM70Cuy3pS8pz7mHC8uTgaBz mN+audXOt3WA82HsbayiBheqb6m4DAoktUHechVlX5Y6LYFyyIS/T7BvCq8uCMxIOWEW NFew== X-Gm-Message-State: APjAAAV+xnQc5y4cnLNOdlPZlfpyVnOg53Wqet18j6+dnpbAKmaRcAKC 2T5xGW7MjVqFDGr25UMLLUYcgRqo X-Google-Smtp-Source: APXvYqwgeqWAJeWAuVe4fLYrWMm5rFyyY/qiiPVGZaXslldq5jYpXcljLX/BgZJOt0+1mC0nmzqj9Q== X-Received: by 2002:a17:902:d895:: with SMTP id b21mr8112372plz.337.1573190685636; Thu, 07 Nov 2019 21:24:45 -0800 (PST) Received: from [192.168.1.10] (C-59-101-167-38.mel.connect.net.au. [59.101.167.38]) by smtp.gmail.com with ESMTPSA id i126sm4866689pfc.29.2019.11.07.21.24.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 21:24:45 -0800 (PST) Subject: Re: Creating /etc/os-release To: Warner Losh Cc: freebsd-arch@freebsd.org References: From: MJ Message-ID: <360ef4fc-235e-26ba-07d0-3983cbd7f1cf@gmail.com> Date: Fri, 8 Nov 2019 16:24:22 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-AU X-Rspamd-Queue-Id: 478TH35S55z3Pg7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=MVPQbamn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::62f as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[38.167.101.59.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(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]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.32), ipnet: 2607:f8b0::/32(-2.34), asn: 15169(-2.01), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 05:24:48 -0000 On 8/11/2019 4:14 pm, Warner Losh wrote: > > > On Thu, Nov 7, 2019, 3:39 PM MJ > wrote: > > > On 8/11/2019 5:10 am, Warner Losh wrote: > > 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. > > First off, I'm not attempting to be antagonistic about this, I have no horse in this race. However, I am genuinely curious about why this is needed and to that end why it adds more clutter to the system. > > So, forgive me, but why is this needed? Ok, it's a "standard" but for what reason is there to add it specifically to FreeBSD? > > > FreeBSD implements industry standards. This is a new standard that creates friction for our users because they have to do extra things that users of other systems get without doing anything. > That seems a rather vague substantiation. Anyway, it seems this is such an issue that FreeBSD will imminently fail without it. > > > > 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. > > I see one issue. The issue is with the port itself, not FreeBSD. Does FreeBSD fail to operate with this file missing? What ports are failing with this missing? > > > Lots of desktop programs have issues. > As in? > In my own use cases, our servers run fine without it. My desktop runs fine without it. I'm not seeing the compelling reason. Sorry. > > > You can ignore it. I'm sure there are at least 2 extra firewalls you are ignoring or doing something to disable... I am only asking a question or two. I fail to see the need to be so hostile about simple questions. If this is indeed a good idea, I would expect some substantive, imperial proof of its need. Just asking. But, then again, don't bother, you've set the tone of this "discussion". Regards, Mark From owner-freebsd-arch@freebsd.org Fri Nov 8 06:19:27 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 915BE1A85D5 for ; Fri, 8 Nov 2019 06:19:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 478VV648Jzz3RCC for ; Fri, 8 Nov 2019 06:19:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x733.google.com with SMTP id 205so4330821qkk.1 for ; Thu, 07 Nov 2019 22:19:26 -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=jm/WmbitC4v9vdgoc7ZDDa1OLDcG4z6rR/6SYEZiVr8=; b=NTK7Zw18zIORuqDIoANOjJjqYg9gFRTtjTdq9F1DAyjhKDN2Z/F6IlCYqpPxWFCVfn 1OuamdRIR8IZPzKXEbe+9tbQLZWCtnRXjhe8NmYxG0g7g1k8nKe4I1D8yVAHhCypw9bd PXn+DGNTpiKkT1JBcBTu54UwQrhi/F8RwMRZ/r5g/PVj8DxtI3FgqSz65AecZIMki4oC O89OgpAB70ZfCa+ckL2GufWfynZ1Exi4aEV7VA8jVTMTs55HuMTmx5MOInkVExxvWb3p Vy1rWNGBNqKbqY1ptczEdfadrG5rf151HtAtXUliZqcga5FEWPwoKFaFitHfibf/Funq t+UA== 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=jm/WmbitC4v9vdgoc7ZDDa1OLDcG4z6rR/6SYEZiVr8=; b=pcwUXc3ZjK68eHhXO5YMuIWfBoVardQ7WLBOATx2L2XaoGn55skFPW6taPp07bN4rY ZPgtxBQwKBI2KG30syX7NDis3ABzZgWpMD0Lecrsuonp94Z5cjOw4uQLLczr6yGAUQ8l fElW546st4tFIW1yqwrrGR0P8ti1lNXKVeWxzb3O0Rik0Ptp9l8u6S5HRi2fc65eLIfS nbpf5ToYboWtlCfWOISzvx+7ik6pw2umYdeoIiIqcd9mhQkylZJqQBvtLzGHX7Ii+w5z GjvaYDBEC0xtQB44dWJ2emLMETJunBGM7lH1yzjEMMc1YJEvprb3uR0BiQKQMfru+yw1 vXkg== X-Gm-Message-State: APjAAAUpkwWVW7yemsLSUMGG3JzQLWRtQlFjHXXcbiiDinFs4u4BQGQ0 dH+7tYeO0wHol7/pbKqst7pyd3vMbyzKpDf6essE6Q== X-Google-Smtp-Source: APXvYqyig0CLhME8CXe273kuY/PZDeKsBefMiPUwY5n0ILb6nVZdqjvP4Hk8JVWnjy7CvfGtkhWyupxh0/10sJtcaCA= X-Received: by 2002:a37:b07:: with SMTP id 7mr6637540qkl.240.1573193965011; Thu, 07 Nov 2019 22:19:25 -0800 (PST) MIME-Version: 1.0 References: <360ef4fc-235e-26ba-07d0-3983cbd7f1cf@gmail.com> In-Reply-To: <360ef4fc-235e-26ba-07d0-3983cbd7f1cf@gmail.com> From: Warner Losh Date: Thu, 7 Nov 2019 23:19:13 -0700 Message-ID: Subject: Re: Creating /etc/os-release To: MJ Cc: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 478VV648Jzz3RCC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=NTK7Zw18; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::733) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.73 / 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]; URI_COUNT_ODD(1.00)[13]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[3.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.73)[ip: (-9.26), 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:19:27 -0000 On Thu, Nov 7, 2019, 10:24 PM MJ wrote: > > On 8/11/2019 4:14 pm, Warner Losh wrote: > > > > On Thu, Nov 7, 2019, 3:39 PM MJ wrote: > >> >> On 8/11/2019 5:10 am, Warner Losh wrote: >> > 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. >> >> First off, I'm not attempting to be antagonistic about this, I have no >> horse in this race. However, I am genuinely curious about why this is >> needed and to that end why it adds more clutter to the system. >> >> So, forgive me, but why is this needed? Ok, it's a "standard" but for >> what reason is there to add it specifically to FreeBSD? >> > > FreeBSD implements industry standards. This is a new standard that creates > friction for our users because they have to do extra things that users of > other systems get without doing anything. > > That seems a rather vague substantiation. Anyway, it seems this is such an > issue that FreeBSD will imminently fail without it. > > > > >> > 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. >> >> I see one issue. The issue is with the port itself, not FreeBSD. Does >> FreeBSD fail to operate with this file missing? What ports are failing with >> this missing? >> > > Lots of desktop programs have issues. > > As in? > > > In my own use cases, our servers run fine without it. My desktop runs fine >> without it. I'm not seeing the compelling reason. Sorry. >> > > You can ignore it. I'm sure there are at least 2 extra firewalls you are > ignoring or doing something to disable... > > > I am only asking a question or two. I fail to see the need to be so > hostile about simple questions. If this is indeed a good idea, I would > expect some substantive, imperial proof of its need. > > Just asking. > > But, then again, don't bother, you've set the tone of this "discussion". > I'm sorry, but have you seen this https://knowyourmeme.com/memes/sea-lioning yet? I'm only asking because I'd like you to know about all the benefits of being well versed in meme culture. Serious response: sea lioning is such a toxic interaction style that it has no place on our lists. Warner Regards, > > Mark > From owner-freebsd-arch@freebsd.org Fri Nov 8 06:23:41 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 0BF821A879F for ; Fri, 8 Nov 2019 06:23:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 478Vb00wxMz3wj8 for ; Fri, 8 Nov 2019 06:23:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id SxgDiwf9w17ZDSxgEi4rhF; Thu, 07 Nov 2019 23:23:37 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=MeAgGD-zjQ4A:10 a=9qa3YWOjAAAA:8 a=e5mUnYsNAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=jTdHeBC3IP_Sng2e4SAA:9 a=lc6Hvb3KbnopHPgo:21 a=7SpNMSnedhXlLx3j:21 a=CjuIK1q_8ugA:10 a=N6PBoGjP6LMA:10 a=2_lZy0vNFpoA:10 a=2Su-2_OBkbdmYqucsK2F:22 a=Vxmtnl_E_bksehYqCbjh:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 4CF9F1621; Thu, 7 Nov 2019 22:23:32 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id xA86NCob070011; Thu, 7 Nov 2019 22:23:12 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id xA86NCcO070007; Thu, 7 Nov 2019 22:23:12 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201911080623.xA86NCcO070007@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: "freebsd-arch@freebsd.org" Subject: Re: Creating /etc/os-release In-reply-to: References: Comments: In-reply-to Warner Losh message dated "Thu, 07 Nov 2019 11:10:38 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 2019 22:23:12 -0800 X-CMAE-Envelope: MS4wfM5VaKhtkAVT6NvM9tXav1170ZBba1543Hj3AFaMYorN7y4/TEHItXg+J2IETctQdwSNHLtqXIire4rJl04ucokbmgKhnpFDOcNH0IURng3+70MhedXc hnJgLMQ4bWavTWc1TWQ3VCFCzdbacze+gcPwtdUr66KvW4nJnPXCAZ+S03WmIU/+e7nWrxWNqTlx+hpSB7DH/epf4NsmfJ6SUUo= X-Rspamd-Queue-Id: 478Vb00wxMz3wj8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.24)[ip: (-5.78), ipnet: 64.59.128.0/20(-3.02), asn: 6327(-2.33), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] 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:23:41 -0000 In message , 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 FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. 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. > > > From owner-freebsd-arch@freebsd.org Fri Nov 8 07:07:20 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 8DC6F1A93EC for ; Fri, 8 Nov 2019 07:07:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 478WYM4hLkz3yLV for ; Fri, 8 Nov 2019 07:07:19 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id SyMWiwqMK17ZDSyMXi4wRR; Fri, 08 Nov 2019 00:07:18 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=MeAgGD-zjQ4A:10 a=YxBL1-UpAAAA:8 a=9qa3YWOjAAAA:8 a=e5mUnYsNAAAA:8 a=6I5d2MoRAAAA:8 a=FRhivEZ415G1AZWOgI0A:9 a=72nkV6eZp--yWH3R:21 a=ii-7F7qYFb89p7Ku:21 a=CjuIK1q_8ugA:10 a=N6PBoGjP6LMA:10 a=2_lZy0vNFpoA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=2Su-2_OBkbdmYqucsK2F:22 a=Vxmtnl_E_bksehYqCbjh:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 8CCE21682; Thu, 7 Nov 2019 23:07:15 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id xA876tgs045066; Thu, 7 Nov 2019 23:06:55 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id xA876tSG045063; Thu, 7 Nov 2019 23:06:55 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201911080706.xA876tSG045063@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: Creating /etc/os-release In-reply-to: References: <201911080623.xA86NCcO070007@slippy.cwsent.com> Comments: In-reply-to Warner Losh message dated "Thu, 07 Nov 2019 23:37:29 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 2019 23:06:55 -0800 X-CMAE-Envelope: MS4wfIKIlXxsA7WLL4NARIpZDTwcdGimzS39ioSHry4ZUseyeRXBCnD/09l9WcSTWhR2VDpyAUcoQUv7VsqzhwSTU+lUacMnbdP4ckbgAMn9574sOi2ed/RG U6ShRweLnngTagns9QW92sCm0ln5d6iCqpR2r8GYsolaZC44Cr9Wfw4gUpACjyVb1x8w53/hhJR3EmJapbx8qYjkTgqEiraQ9w0= X-Rspamd-Queue-Id: 478WYM4hLkz3yLV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.137) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[137.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.24)[ip: (-5.76), ipnet: 64.59.128.0/20(-3.02), asn: 6327(-2.33), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] 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 07:07:20 -0000 In message , Warner Losh writes: > --000000000000c332a50596d00425 > Content-Type: text/plain; charset="UTF-8" > > 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. Using Red Hat as an example, IIRC they put the version.release numbers in the package name, or in the case of CentOS, a build number, followed by the repo name (el7 -- which I think is redundant), followed by the arch. We could have something like FreeBSD-12.1-r353000.amd64. If we want to maintain repositories for 12-stable and 12.1-release then something like FreeBSD-12.1.12S-r353000 for the -stable repo v.s. FreeBSD-12.1p3.12R for the same package within the 12-release repo. We don't need to decide the composition of the package name here and now but the folks working on pkgbase might want to have some input into this. Personally, I'm not set on one package name v.s. another, as long as we consider how we derive the file's package name in our installworld and release process. Contrary to how we'd normally consider what to do, in this case how it's done is probably more important than what the name is, as whatever decisions are made now in how we implement this, we will have to live with those decisions in the future. At this point how we do it is more important than the composition of the package name itself. I'd invite the pkgbase team for their thoughts. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Fri Nov 8 16:41:38 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 16DBB1B745E for ; Fri, 8 Nov 2019 16:41:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 478mJ10fwdz4b7K for ; Fri, 8 Nov 2019 16:41:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id t8so7168485qtc.6 for ; Fri, 08 Nov 2019 08:41:36 -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=1HHDibkGOAx8aaBL2Zpv5GckqbVZjoujYteD2t900Yk=; b=BafP5JWxFkGJrnURlzPYAMkublp8vHt5dX1yD6bmR5R+5Fc9EFeZQMorV+9EbgNjrM snMqFtkq8Q9MqbxUCyPZyY3A2j5Mdv26c/63Fk1BUAHsjeV1xZ5Kgm689rUK+ON5IjEH S0o2Gmiv/KtKiiFBidSbrHeiJJnEu9Oi7j4lpmefzb4LwBiUqWxd15t07tJFpKp+TEfx ZRgLG0cC1GFI6yS4w7yRZ7ZDXxR60+5xsUpBsOuhtipBkDjvmbbzUnuEW7O64se7wmDT 2InTxvbss7U6rt2+qnQqct4yTLKmLfMzNlPsJgY1teYNcQNXQfwoT09xtLIFn3/Qc+TW /I2A== 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=1HHDibkGOAx8aaBL2Zpv5GckqbVZjoujYteD2t900Yk=; b=kibRm6f2Rs0CrSBA7emMu5RV5FS8KVrGCAZSYBIptICBOhcFaGbRl3DbW1PYgSOB2h mXMI3cROR5/4HbFOYvT6sPz00L57KIHO9rqSLJvyjVfZ83QAqqlo+fAtt0bn0fZtODzj yVEAOj+PCCxkanBAc83Mp+ELr4vSif8k4FbodBFDAcGRCLPbIp1cte/vZ8AvKz316Ols BPhf7f15ef4dKqCwloG6jJAZ+LWryTSrVC+ZT8GeY3QmxEuchrst3TBGP21uSFQr530M ogWDOzdh4iYJwxw9v6A4/MM9mBUgKA27QiHnJ0bnCfKWgoDcCfqeE/BMl9P9FVMlLP7E Etng== X-Gm-Message-State: APjAAAXfkXXHMEI/2onDs+hykFqKuMtRwXS6rNQizTIDrSTyBCC1Vxf7 PKZZAJBSv9sCnvExl93JZWO4aaKKXk6PNK4mwvhcvsu7Y/M= X-Google-Smtp-Source: APXvYqxxeBA6XgSbGTRt3I96/+bA4CgDvmXOp9WfzOj0b/YOoXo2UZL9gMJI3mvkEcakq852u1o+ok5QZVqXYgeyFH4= X-Received: by 2002:ac8:7216:: with SMTP id a22mr11414293qtp.187.1573231295188; Fri, 08 Nov 2019 08:41:35 -0800 (PST) MIME-Version: 1.0 References: <201911080623.xA86NCcO070007@slippy.cwsent.com> <201911080706.xA876tSG045063@slippy.cwsent.com> In-Reply-To: <201911080706.xA876tSG045063@slippy.cwsent.com> From: Warner Losh Date: Fri, 8 Nov 2019 09:41:24 -0700 Message-ID: Subject: Re: Creating /etc/os-release To: Cy Schubert Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 478mJ10fwdz4b7K X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=BafP5JWx; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.73 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; 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]; URI_COUNT_ODD(1.00)[13]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[e.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.73)[ip: (-9.27), 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 16:41:38 -0000 On Fri, Nov 8, 2019 at 12:07 AM Cy Schubert wrote: > In message > om> > , Warner Losh writes: > > --000000000000c332a50596d00425 > > Content-Type: text/plain; charset="UTF-8" > > > > 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. > > Using Red Hat as an example, IIRC they put the version.release numbers in > the package name, or in the case of CentOS, a build number, followed by > the > repo name (el7 -- which I think is redundant), followed by the arch. We > could have something like FreeBSD-12.1-r353000.amd64. If we want to > maintain repositories for 12-stable and 12.1-release then something like > FreeBSD-12.1.12S-r353000 for the -stable repo v.s. FreeBSD-12.1p3.12R for > the same package within the 12-release repo. > Yes. That makes sense. How much resolution do you want on the version. 12, 12.1, 12.1p3, 12.1-stable-r35300 are all refinements of that answer. What you need depends a lot on the question you are asking. "Is this 12 vs 13?" vs "Is my entire fleet running the latest 12.1.p3.netflix47 yet?" Both are legit questions, but have very different actions depending on the answers. This file is more for the former than the latter, but that doesn't invalidate the desire to ask the latter question. > We don't need to decide the composition of the package name here and now > but the folks working on pkgbase might want to have some input into this. > Personally, I'm not set on one package name v.s. another, as long as we > consider how we derive the file's package name in our installworld and > release process. Contrary to how we'd normally consider what to do, in > this > case how it's done is probably more important than what the name is, as > whatever decisions are made now in how we implement this, we will have to > live with those decisions in the future. At this point how we do it is > more > important than the composition of the package name itself. > > I'd invite the pkgbase team for their thoughts. > I would too. This is a very interesting area to both follow industry practice, and break from it when there's a compelling reason (like a well known problem to fix). Warner From owner-freebsd-arch@freebsd.org Fri Nov 8 17:11:50 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 AB9921B7EE9 for ; Fri, 8 Nov 2019 17:11:50 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from muon.bsdio.com (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 478mys6lhYz4csh for ; Fri, 8 Nov 2019 17:11:49 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from muon.bsdio.com (localhost [127.0.0.1]) by muon.bsdio.com (Postfix) with ESMTP id 826A6A94D; Fri, 8 Nov 2019 10:14:28 -0700 (MST) Received: from muon.bsdio.com ([127.0.0.1]) by muon.bsdio.com (muon.bsdio.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s2Ew8-JNDN3H; Fri, 8 Nov 2019 10:14:28 -0700 (MST) Received: from [10.0.10.115] (unknown [10.0.10.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by muon.bsdio.com (Postfix) with ESMTPSA; Fri, 8 Nov 2019 10:14:28 -0700 (MST) Subject: Re: Creating /etc/os-release To: Warner Losh , "freebsd-arch@freebsd.org" References: From: Rebecca Cran Message-ID: <6f296606-9a9b-6a0d-a0be-3cb6261280f4@bsdio.com> Date: Fri, 8 Nov 2019 10:11:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 478mys6lhYz4csh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of rebecca@bsdio.com has no SPF policy when checking 65.103.231.193) smtp.mailfrom=rebecca@bsdio.com X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdio.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:65.103.224.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.88)[ip: (-8.73), ipnet: 65.103.224.0/19(-0.59), asn: 209(-0.01), country: US(-0.05)] 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 17:11:50 -0000 On 11/7/19 11:10 AM, Warner Losh wrote: > 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. Also, it's enough of a standard that it's supported in Solaris 11.4 - https://docs.oracle.com/cd/E88353_01/html/E37852/os-release-5.html . -- Rebecca Cran From owner-freebsd-arch@freebsd.org Fri Nov 8 17:36:26 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 8645D158CC5 for ; Fri, 8 Nov 2019 17:36:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 478nWF52NWz4fld for ; Fri, 8 Nov 2019 17:36:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id y39so7396792qty.0 for ; Fri, 08 Nov 2019 09:36:25 -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:cc; bh=Pv8s2Ck8QGqvNdKLk5KKq24SDy4p1MA7QxkS+paz5RI=; b=Skdswfp0Hal7fxjKXx7LlHLhmoBK16Ule4cTbiWHcUtLqxnuLu4fV1vvHfC0D/Wyyv 2Q4QFb1b0ACF0eiZWReK7VkhCQox5R7lqDLlCv4nnkvVEwbSnfqzM23z/7cQitGcck7m ttlgjZdznmZi/fEReIcbwUwjLBmb1v/j8x4IKfyC6T3xHr0JdX+vAJB/L6FvJtFmv4iy 6Klt18FoowV8OCngctS+bdI3ZBLX16i2QdjKM+I6FO0cYCH5MZpFz/UE62btJW3FZAG2 9bK2plNUEogSw8CRlXuk/TWm2HPbNXfE2R/TazpLJ3qd/kpsQmc/s/Y+WYs1lq63VPLq Yshg== 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:cc; bh=Pv8s2Ck8QGqvNdKLk5KKq24SDy4p1MA7QxkS+paz5RI=; b=ZSXx7RB3Wb1z4Smn10wdoLjrNZOu5k5XJ/3SDiQ5XbyhWPEk5TpxP/W+wFLe6Tn9dl EJzdxtgnJfQBVRFuRibfxZ//6nNoqSrk6hhwX9HHirLBRrYM5wuOJ043w2PREcezWXx6 8bAAdjzoiufGZkys0fW0xnB51gJEec0gbUThUSVMKnQ/YPeLR3wNr9gH2pVbnRtvJ+N1 IKFCCf+7ilkZJb+n3WkXb3iLGJ9DW+II29+tb2b/ualvnbS2xKWnL9wwaYUvuytApOh0 Ik8WKovgQndWG2PNzsWQ3RHptcTKj1RDko2QAsFHxpMK7D3EcrPFigWRRdSMYmQgkuGA wdZw== X-Gm-Message-State: APjAAAUyp4xdDwTCxBSLiyKCK5JoNzI8fh16iAiQaMQOc9Y+pmR8kM8C pHgrp+wzlb9vhakT6EK5LOt1jzBfgElmt5iNSILfX/9FIGy/4Q== X-Google-Smtp-Source: APXvYqxJ46gF4CUrJ7WzRfxZsfQFxWhCsAlh1C3F3H0Tq2pLl1wzfISuMbhjHrdsiVCm0AlnpMpahEz/n6VIJehgbQk= X-Received: by 2002:ac8:3a64:: with SMTP id w91mr11937093qte.242.1573234583495; Fri, 08 Nov 2019 09:36:23 -0800 (PST) MIME-Version: 1.0 References: <360ef4fc-235e-26ba-07d0-3983cbd7f1cf@gmail.com> In-Reply-To: <360ef4fc-235e-26ba-07d0-3983cbd7f1cf@gmail.com> From: Warner Losh Date: Fri, 8 Nov 2019 10:36:11 -0700 Message-ID: Subject: Re: Creating /etc/os-release Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 478nWF52NWz4fld X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Skdswfp0; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.24 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.61)[-0.608,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_MEDIUM(0.13)[0.129,0]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MISSING_TO(2.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.76)[ip: (-9.38), 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 17:36:26 -0000 On Thu, Nov 7, 2019 at 10:24 PM MJ wrote: > Lots of desktop programs have issues. > > As in? > There's a more complete list of the affected programs, and the problems with the current solution of just having it be a port in https://reviews.freebsd.org/D22271 as well as the consequences for its absence and/or a lack of proper due diligence in importing new ports that look for it. Warner