Re: weekly periodic security status
On 8/26/2013 5:09 PM, Jeremie Le Hen wrote: On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote: The new framework would let me rely on the environment instead of $0, which, IMO, is more reliable. I'd need to be able to tell periodic to run that script with the daily, weekly and monthly security runs, though. If I understand what you say correctly, this should continue to work. As I understand the framework, I can only set the enable to "NO", "daily", "weekly" or "monthly". Periodic will only run it one of the periods. How would I set it to run in all three? How would I set to run in only two of the three periods? It seems like you could add this functionality by adding stars to each end of the case patterns in check_yesno_period. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: weekly periodic security status
Darren On Mon, Aug 26, 2013 at 12:29:30PM -0400, Darren Pilgrim wrote: > >> On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: > >>> And the following variables to control whether you want each check to > >>> run "daily", "weekly" or directly from "crontab" (the default, backward > >>> compatible values are shown): > >> > >> What do we do if we want to run a check both daily and weekly? > > > > I really don't see the point of running some checks weekly when you do > > daily. Do you have a particular example in mind? > > On one set of systems, I have a log analyser run as a periodic script. > On a daily run, it grabs and filters logs into a database. On weekly > runs, it does some statistical analysis of the filtered logs in the > database. On monthly runs, it does a larger set of stats and a bit of > housekeeping. The script lives in /usr/local/libexec and is hardlinked > into the /usr/local/etc/periodic/ subtree and cases out the value of $0. > > The new framework would let me rely on the environment instead of $0, > which, IMO, is more reliable. I'd need to be able to tell periodic to > run that script with the daily, weekly and monthly security runs, though. If I understand what you say correctly, this should continue to work. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: weekly periodic security status
On 8/25/2013 1:37 PM, Jeremie Le Hen wrote: Hi Darren, On Sun, Aug 25, 2013 at 12:45:22PM -0400, Darren Pilgrim wrote: On 8/25/2013 7:05 AM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run "daily", "weekly" or directly from "crontab" (the default, backward compatible values are shown): What do we do if we want to run a check both daily and weekly? I really don't see the point of running some checks weekly when you do daily. Do you have a particular example in mind? On one set of systems, I have a log analyser run as a periodic script. On a daily run, it grabs and filters logs into a database. On weekly runs, it does some statistical analysis of the filtered logs in the database. On monthly runs, it does a larger set of stats and a bit of housekeeping. The script lives in /usr/local/libexec and is hardlinked into the /usr/local/etc/periodic/ subtree and cases out the value of $0. The new framework would let me rely on the environment instead of $0, which, IMO, is more reliable. I'd need to be able to tell periodic to run that script with the daily, weekly and monthly security runs, though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: weekly periodic security status
On Mon, Aug 26, 2013 at 05:03:32PM +0100, RW wrote: > On Sun, 25 Aug 2013 22:03:58 +0200 > Jeremie Le Hen wrote: > > > I've implemented it here: > > http://people.freebsd.org/~jlh/security_status_period.diff > > > > Doesn't this mean that if you want to run "periodic security" from > crontab or manually etc, you have to override every single entry to > "crontab" in period.conf. > > IMO when "periodic security" is run directly every test should run > unless it's explicitly set to NO. You are right, I've updated the patch accordingly. Thanks for your review. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: weekly periodic security status
On Sun, 25 Aug 2013 22:03:58 +0200 Jeremie Le Hen wrote: > I've implemented it here: > http://people.freebsd.org/~jlh/security_status_period.diff > Doesn't this mean that if you want to run "periodic security" from crontab or manually etc, you have to override every single entry to "crontab" in period.conf. IMO when "periodic security" is run directly every test should run unless it's explicitly set to NO. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: About CPU cores numbering an processor affinity
On 23/08/2013 15:23, Dmitry Sivachenko wrote: > Hello! > > I am using FreeBSD-9-STABLE on the following hardware: > > FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs > FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads > > So I have 2 physical CPUs with 6 core each. > > # cpuset -g > pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, > 18, 19, 20, 21, 22, 23 > > > So each of 24 cores are numbered 0..23. > > 1) In what particular order are these cores numbered? Can I assume that > 0..11 correspond to 1st physical CPU and 12..23 to second? How SMT threads > are numbered within each core? You could look at the kern.sched.topology_spec sysctl, which outputs like this: 0, 1, 2, 3, 4, 5, 6, 7 0, 1, 2, 3 4, 5, 6, 7 Note that this output is created from the kernel's own interpretation of the pysical CPUs, not necessarily from what the physical topology actually is (but if there is a mismatch, it's a bug). signature.asc Description: OpenPGP digital signature
