Created attachment 244040 [details] Extend /etc/periodic/weekly/340.noid to support /etc/jail.conf.d The current /etc/periodic/weekly/340.noid script excludes jail paths it finds in /etc/jail.conf, but does not check jail configs in /etc/jail.conf.d/, so I added that in this patch. I thought about enumerating ${jail_list} but that only includes enabled jails, and in the case of /etc/jail.conf you may parse it multiple times, so you'd have to check for that, too. Just searching /etc/jail.conf and /etc/jail.conf.d/*.conf seemed simpler.
Created attachment 246578 [details] Consider /etc/jail.conf.d/*.conf and /etc/jail.*.conf Parse all documented sources for jail configurations (i.e. /etc/jail.conf, /etc/jail.conf.d/*.conf and /etc/jail.*.conf)
I don't know why this request has not received any feedback, but I also think that this script should consider the same sources as /etc/rc.d/jail. Everything else is counterintuitive and should probably be considered unexpected behavior. Therefore I've added a second attachment which also fixes another issue with the original script. The "-e" option separates the parameters by the separator provided. However, each jails parameters will be on a separate line (i.e. a new line character is inserted after the last parameter of a jail). In case the "path" parameter is the last parameter of a jail, the script will consider the line break and the first parameter of the next jail as part of the value. Example: $ cat /etc/jail.conf issue { path = '/some/path'; } cause { path = '/another/path'; } $ jail -f /etc/jail.conf -e : name=issue:path=/some/path name=cause:path=/another/path In the above case, the script would try to hand "-path /some/path$'\n'name=cause -prune" to find, leading it to fail to parse its arguments (resulting in a noop for this script). Therefore I changed the separator to the newline character. Another option to fix the bug would be to just add the newline character to IFS. However, using newline as a separator allowed to simplify and optimize the main loop.