Re: security/clamav: /ar/run on TMPFS renders the port broken by design
Date: Sun, 28 Aug 2022 10:21:24 UTC
In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>, Michael Gmelin w rites: > > > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote: > >=20 > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST): > >> As stated before in this thread, replacing /var/run with tmpfs is not a > >> supported configuration. > >=20 > > Not supported? What is the purpose of /etc/rc.d/var then? That creates a t= > mpfs backed /var, populates it through mtree, and makes a proper /var/run av= > ailable. > >=20 > > However it doesn't (yet) create /var/run/clamav of course. > >=20 > > It would be fairly easy to extend /etc/rc.d/var by a logic that walks thro= > ugh /usr/local/etc/mtree/* and runs mtree on each of the files found as need= > ed. All that the security/clamav port would need to do then is to drop an ap= > propriate small mtree file as /usr/local/etc/mtree/clamav. =46rom a port's p= > erspective that is the same logic as dropping service scripts as /usr/local/= > etc/rc.d/clamav-*. > > =46rom a user's perspective, it would be preferable to have this happen at s= > ervice start though, as (unlike in the setup described) reboots don't happen= > that frequently, but files in /var/run might get deleted manually. Maybe so= > me rc framework based solution would make sense, e.g., a variable `mtree_fil= > es`, which, if set, is applied in the default start_precmd. Besides being mo= > re resilient, this would also have the advantage that all required file syst= > ems should be available at that point and the separation between system and p > = > orts would be more clear. Another advantage would be that directories are on= > ly created for services that are actually enabled/started. Unfortunately this requires all ports to include an mtree file. Relying on port maintainers who are human to ensure that these files are created and updated when ports are created and maintained will result in more human error. I've learned over my long career to rely more on automation than human beings. Automation [should] never fail and when it does it does temporarily until the bug is found and fixed. Human beings inconsistently fail. If it were an auto-discovery script that created an mtree file as part of the packaging process, it would be another matter. But this optional solution path should be discussed on ports@, not here. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0