Re: service jails and precmd make ntpd (and nfsd) sad
- In reply to: Lexi Winter : "Re: service jails and precmd make ntpd (and nfsd) sad"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 22 Mar 2025 18:12:50 UTC
Am 2025-03-21 15:52, schrieb Lexi Winter: > Alexander Leidinger: >> > i would propose 'setup' as the thing which is run outside the jail, and >> > 'precmd' as the thing which is run inside the jail. > >> Modifying the service jails to run the precmd (or whatever) inside >> instead >> of of outside requires more than an one line change. Be careful if you >> want >> to go that way. > > i think this is going to break things either way. i'd be fine with > doing it the other way around, i.e., 'setup' runs inside the jail and > 'precmd' runs outside the jail, but both nfsd and ntpd will need > changing either way. I did not want to suggest which name to use for inside or outside (the name matters, but right here, right now, for my point, it doesn't). I simply wanted to suggest that it may be more easy to check if there is a way without a change. For those scripts which I had to modify to make the work better with service jails, I didn't need to run a setup command in the jail, or I was able to integrate it into a start function. >> There is another option. Load the kernel module outside of the ntpd >> service >> rc script. Either as a documented requirement when enabling service >> jails >> (and an error message from the rc script in the svcj case if the >> module is >> not loaded), or by adding another rc script which also listens on >> ntpd_enable and the ntpd rc scripts depends on. > > some rc.d scripts (nfsd, for example) also attempt to set sysctls in > their precmd, and this won't be allowed in a jail either. would you > suggest that all such services should have a second service > (ntpd_setup, > nfsd_setup, etc.) to perform these tasks? > > i'm not opposed to that approach, and i can see how it's cleaner, but > before i put any effort into implementing it i'd appreciate some sort > of consensus that this is the right approach. In general: There are benefits both ways. Which one is cleaner... depends. Here I would not use xxx_setup, I would use xxx_kld. A setup you may want to run multiple times, or only once in total, or after every reboot (depending on what is setup and how). Something which loads klds needs to run before the securelevel is raised to >=1, whereas not everything which needs a kld needs to be started before the securelevel is raised (it might be started before, but not because of the securelevel). I can also imagine a generic kld loader for services which checks for a particular meta-comment in the rc scripts and loads all klds specified in one go. That way we wouldn't need to load klds in each service. That could be realized as a rc script itself. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF