Something like /etc/rc.conf.d, but for periodic?

rwv37

rwv37

I make extensive use of the /etc/rc.conf.d directory instead of the /etc/rc.conf file; by creating individual files like /etc/rc.conf.d/apache24 and /etc/rc.conf.d/mysql instead of adding lines about both Apache and MySQL to /etc/rc.conf, I find that configuration management is greatly simplified.

I do not use the "periodic" system (except whatever default stuff it may do, I guess), but I now have something I intend to use it for. Investigating it, I was surprised to be unable to find anything akin to /etc/rc.conf.d - i.e. a directory intended for the user to place their own periodic-related individual files in. I know about /etc/periodic.conf and /etc/periodic.conf.local, but it seems to me that since these are files and not directories, directly using either of them would introduce the kind of configuration management complications I'm trying to avoid.

Obviously I can just accept the fact of the issue and use those files anyway, but before I do that, I want to make sure:

1. Did I just miss the existence of some standard, built-in thing like /etc/periodic.conf.d?

2. Assuming I didn't miss anything like that: It seems to me that these things (e.g. /etc/periodic.conf) are intended to just be shell scripts. Is that correct?

3. If that is correct, then it furthermore seems to me that I could just "roll my own" by setting up some secure directory with my "real" periodic scripts in it, and changing /etc/periodic.conf to be a simple little script that just sources in whatever it happens to find in that directory. That way I could have (e.g.) one file for periodic Apache-related stuff and another for periodic MySQL-related stuff, which is what I'm hoping for. But these sorts of systems (e.g. periodic, rc) are often, in my experience, more complicated than they may seem at first glance, so I want to make sure: Is there anything problematic about this approach?

Thanks in advance.
 
rwv37 said:
1. Did I just miss the existence of some standard, built-in thing like /etc/periodic.conf.d?
2. Assuming I didn't miss anything like that: It seems to me that these things (e.g. /etc/periodic.conf) are intended to just be shell scripts. Is that correct?
Click to expand...
You didn't miss anything, and you're correct. See also periodic(8) which emphasizes this.

Why not simply use cron instead?

Periodic is a rather specific system which is intended to run scripts at specific intervals also with specific settings. This is also the reason why there isn't some kind of global 'collection' directory.

So if your intend is merely to run certain scripts then you may want to look into crontab(5).
 
Thanks.

I do use cron, but I am looking to modify a setting that is used by a periodic script installed by a port, with the specifically suggested means of modification being to add a line to /etc/periodic.conf.
 
periodic(8)
Code: 
directory  An arbitrary directory containing a set of executables to be run.
Wouldn't it be better to run periodic directory
using cron?
Am I misunderstanding something?
 
Charlie_ said:
periodic(8)
Code: 
directory  An arbitrary directory containing a set of executables to be run.
Wouldn't it be better to run periodic directory
using cron?
Am I misunderstanding something?
Click to expand...
I could be misunderstanding what you're suggesting, but there's an existing periodic script which uses a specific variable, and I want to set the value of that variable in preparation for that script. I don't want it to be set at some other time; I want it to be set as that existing periodic script is about to be run. The specifically suggested way of doing this, according to the script itself, is to modify /etc/periodic.conf.
 
What you want is to run periodic scripts from ports, there's /usr/local/etc/periodic/ just for it.

For example:
Code: 
% pkg which -o /usr/local/etc/periodic/daily/411.pkg-backup
/usr/local/etc/periodic/daily/411.pkg-backup was installed by package ports-mgmt/pkg

Not sure (as not read /etc/defaults/periodic.conf thoroughly) it's supported or not, but possibly /usr/local/etc/periodic.conf can override (nonexistent by default) /etc/periodic.conf and /etc/defaults/periodic.conf.

Note that manually editing anything in /etc/defaults/ is STRONGLY DISCOURAGED. IT CAN HARM UPGRADES.
 
rwv37 said:
I do use cron, but I am looking to modify a setting that is used by a periodic script installed by a port, with the specifically suggested means of modification being to add a line to /etc/periodic.conf.
Click to expand...
Then... first I don't understand why you wouldn't just put the entries in /usr/local/etc/periodic.conf and get it over with? Using "dump directories" isn't exactly a commonly used practice for user customizations because it can easily turn into an administrative nightmare.

I mean... if you need to change something then checking 1 config file is easier than having to check, say, 8 or 10. Sure, this isn't a problem if you still know what each of those 8 config files are supposed to do, but does that also apply after 6 months of not having used any of those?

Then the periodic stuff... When a service uses the periodic system then you normally define 3 parts: whether it's enabled, when it's supposed to run and finally the flags. But flags can also be used on the commandline.

Take security/rkhunter for example, this is from /etc/periodic.conf I meant: /usr/local/etc/periodic.conf:
Code: 
# Run daily check
security_rkhunter_check_enable="YES"
security_rkhunter_check_period="daily"
security_rkhunter_check_flags="--checkall --nocolors --skip-keypress"
The thing not to forget here is that /usr/local/etc/periodic/security/415.rkhunter is still a "simple" shell script which can be easily bypassed if you want to. One quick look at that file shows me:

Code: 
if check_yesno_period security_rkhunter_check_enable
then
        echo ""
        echo "Running rkhunter..."
        /usr/local/bin/rkhunter ${security_rkhunter_check_flags}
fi
So if I don't want to rely on Periodic then all I have to do is dump /usr/local/bin/rkhunter --checkall --nocolors --skip-keypress in a crontab somewhere and I'm done.
 
Well, what can I say; it's good for me. As I said in the initial post, I've found the similar case of the rc system (and other systems too) to be greatly reduced in configuration complexity when using the directory rather than the file, and I see no reason to doubt the same in the case of the periodic system. As for your concerns such as needing to check one config file or ten, and remembering what config file is supposed to do what, perhaps I should be a little more explicit about how I deal with configuration management, because honestly I actually see those issues as more problematic under your suggestion than under my system:

I rarely if ever directly modify configuration files. Instead, more or less all of my nondefault (i.e. modified) configuration related to, say, Tiny Tiny RSS is stored in /usr/local/bobconfig/stowfiles/ttrss. In there, I have essentially mirrored the parts of the / directory tree that relate to where Tiny Tiny RSS-related configuration would "normally" be found:

Code: 
# find ttrss -type f | rg -v "/\.svn/?" | sort
ttrss/etc/rc.conf.d/ttrssd
ttrss/usr/local/etc/caddy/config/imports/ttrss.vestertopia.net
ttrss/usr/local/etc/php-fpm.d/ttrss.conf
ttrss/usr/local/etc/rc.d/rcorder-ttrssd-after-mysql
ttrss/usr/local/www/tt-rss/BOB-SENSITIVE.php
ttrss/usr/local/www/tt-rss/config.php
ttrss/usr/local/www/tt-rss/config.php.sample
ttrss/usr/local/www/tt-rss/plugins.local/youtube_subscribe/init.php

I then use GNU Stow to make the "real" files, e.g. /usr/local/www/tt-rss/config.php, be symlinks to these files (in one fell swoop, i.e. simply a single stow ttrss to deal with all of them at once):

Code: 
# ls -l /usr/local/www/tt-rss/config.php
lrwxr-xr-x  1 root wheel 79 Oct 17  2024 /usr/local/www/tt-rss/config.php@ -> ../../../../usr/local/bobconfig/stowfiles/ttrss/usr/local/www/tt-rss/config.php

In this way of doing things, using (e.g.) /etc/rc.conf.d instead of /etc/rc.conf means that I can keep all of my TTRSS configuration in one place, unadultered by other, unrelated configuration. I find that this makes it much easier to deal with configuration management. For example, regarding your concern about needing to remember what all of these configuration files do:

If I want to look at TTRSS configuration, I simply go to /usr/local/bobconfig/stowfiles/ttrss, and there it all is. If I want to modify it, I just modify it. If I want to uninstall it, I just unstow ttrss. If I want to reinstall it, I just stow ttrss.

But if I had instead just directly modified /etc/rc.conf and other standard files to contain my TTRSS-related configuration:

"If I want to look at it": I have to remember that TTRSS-related config may be in TTRSS's config file, or Caddy's config file, or the rc configuration, or PHP-FPM's configuration, or blah blah blah. Moreover if I think it's in (say) the rc configuration, I have to look through the entire rc.conf file, which is pretty big, contains a lot of stuff completely unrelated to TTRSS, and will only contain a small amount of TTRSS-related stuff, if any at all.

"If I want to modify it": Yeah, fine, after figuring that all out, I modify, say, /etc/rc.conf. And I store my change in source control. OK so far, but....

"If I want to uninstall it": I have to hunt through all of these files (and keep in mind I may not even remember some of them; for example it may have been years since I've made a change to my TTRSS configuration and I might not even remember that such a thing as "PHP-FPM" exists, let alone that TTRSS uses it) and their source control histories to find what TTRSS-related stuff is in there and that should be removed. I then have to edit them all, because the vast majority of their contents -- i.e. the parts unrelated to TTRSS -- need to remain unchanged.

"If I want to reinstall it": Same problem as in the uninstall case, and probably even worse.

The main problem I've found with my system (having used it for a long time) is that once in a while some piece of software will not like the fact that its config file is a symlink. This is annoying, but I just deal with it in the pretty rare case of encountering it. Meanwhile, having used your system for decades prior to that, I can state without hesitation that my system has since saved me a great amount of time, effort, confusion, and misconfiguration.

I'm not claiming that my system is wonderful, or that it would suit everyone. All I'm saying is that it works for me, and in my experience it works much better, much more efficiently, and much more simply for me than the system you seem to be suggesting.
 
Interesting system.

For complex things, that affect lots of configuration files, it is a nice idea; and your argument is exactly correct: all the configuration settings and files relating to the complex thing are in one place, on directory hierarchy.

But for simple things, it seems overkill. A lot of my services require only a single line in /etc/rc.conf to turn them on, simply "foo_enable=YES". Having to create /usr/local/bobconfig/stowfiles/foo/usr/local/etc/rc.conf.d/foo.conf, and from there create /usr/local/etc/rc.conf.d/foo.conf means I have 7 extra directory, one extra file, one extra symlink, where a single line in /etc/rc.conf would have been sufficient.
 
OK. From my personal perspective, the extra file and such are essentially irrelevant, especially given the simplicity with which GNU Stow reduces them all to a single actionable object, whereas the "single line in /etc/rc.conf" is... yes, "sufficient", but a quick-and-dirty solution for the immediate situation, which frequently leads to complications which will absolutely dwarf "seven extra directories" and whatnot down the road. I'd rather spend the two extra minutes it takes to set things up in a way that I think (and, through experience, know) will save me significant hassles in the future.

But anyway, let me ask you this: Does your system work for you? Are you happy with it? I hope you are. If so, great!

Mine works for me, and I am happy with it.
 
It does work for me. One of the reasons is that I'm quite careful about commenting and recording everything. For example, my rc.conf has divider lines, section headings, it is split into kernel, file systems, network devices and host identity, stock FreeBSD daemons, daemons from ports, local daemons, and so on. In addition, whenever I change something, I record it in my log files, usually cutting and pasting the lines. So if I need to reconstruct it, or debug it, I usually start with my log files.
 
I also use a parallel system. Mine is at /box. There I have a shell subdir, with subdirs "s" (scripts) "env", for setting variables, plus "aux" and "data" - the last one only got one file, for the time being, a local extract of relevant timezonedata that I use to generate the /usr/share/zoneinfo structure. At "box/sys" I have an "etc" & "var", where the var-dir has some 'imports' from the system environment, like a maildir, the pkg-database and also the ports build database. The overall idea is this annoying practice called "update" that makes it necessary to prepare for configuring what you already have configured.. or something like that. The "box" directory is also the place for the build script - THE buildscript. A never-ending project
 
You must log in or register to reply here.
Back
Top