Date: Mon, 29 Aug 2022 10:31:28 +0200 From: Franco Fichtner <franco@lastsummer.de> To: FreeBSD User <freebsd@walstatt-de.de> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Michael Gmelin <grembo@freebsd.org>, freebsd@oldach.net, otis@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, yasu@freebsd.org, "freebsd-pkg@freebsd.org" <freebsd-pkg@FreeBSD.org> Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by design Message-ID: <25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de> In-Reply-To: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de> References: <202208280842.27S8gDXn055868@nuc.oldach.net> <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org> <20220828131120.C3781317@slippy.cwsent.com> <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On 29. Aug 2022, at 8:24 AM, FreeBSD User <freebsd@walstatt-de.de> = wrote: >=20 > Checking today NanoBSD based projects, i.e. XigmaNAS, which also let = /var reside on a memory > disk and the way NanoBSD handles /var, contradicts some claims that is = is 'unsupported' to put > /var on a volatile memory infrastructure. I fully agree with the situation that at least NanoBSD has always been a = valid use case for this and don't see the need to "recycle" contents in = /var/run and let alone assume software that state inside /var/run is not volatile. Milage varies for other /var related subdirectories of course, but = people using a /var MFS type setup have managed the situation for many years anyway = with all of its ups and downs. The situation is a bit sloppy on the ClamAV end and has been for a = couple of releases assuming this and that and failing on tmpfs nodes, not = bootstrapping required things in the first place, but let's just assume that is the = case for other software as well now or in the future. > what (fatal?) implications does it have to create some folders by = port's rc-script in /var/run > or whatever folder is needed to be on a volatile memory device for = FreeBSD base system's mtree > infrastructure? So the obvious "separation of concerns" solution isn't something that = was being discussed here seeing that this is a ports/packages related issue: The fix in all cases is to upgrade/reinstall the package in question, so the knowledge of these required directories is buried inside the = +POST_INSTALL script but you cannot easily re-run these scripts since there is no = command option for it. Obviously this beats having a copy of the package lying = around just to reinstall it on a reboot... In the past you were able to extract them from "pkg info --raw = $packagename", and run them in the shell but that workaround is no longer feasible for = LUA scripting was added since pkg uses internal definitions in the ports = tree provided scripts. Whether or not someone will have to script something to rerun the = +POST_INSTALL on reboot shouldn't stop from adding a pkg script run option to enable = the former. Solutions not involving the actual ports scripts seem to be = over-engineering when trying to record "unknown state" for a "reproducible outcome". ;) Cheers, Franco=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25A758F5-784E-45EC-8F9A-278E0D3AB8DE>