Re: weekly periodic security status
On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen j...@freebsd.org wrote: On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Sounds like a good idea. However I don't know how to implement this because, in the current state of the periodic security scripts, there is no way to know whether a script had been called from daily or weekly periodic scripts, so no way to know which variable to check. The easy way to work around this would be to declare an environment variable from 450.status-security, but it sounds like a hackish way because you create an additional dependency for the periodic security scripts. I've modified periodic(8) to set the $PERIODIC environment variable in r254829. The attached patch does more or less what you requested, but slightly differently. We now have the following variables to control daily/weekly security runs: daily_status_security_enable=YES daily_status_security_inline=NO daily_status_security_output=root weekly_status_security_enable=YES weekly_status_security_inline=NO weekly_status_security_output=root 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): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily The periodic.conf(5) manpage and default/periodic.conf have been updated accordingly, but I plan to further rework them after the patch is committed (especially, grouping security related variable into their own section). That way the modification done by the patch remain clear. Patch available here: http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff This approach creates the granularity that I was looking for, and represents a non-trivial amount of work; thanks for taking this on! I haven't looked closely at the patch, but I do have a couple of style comments. If someone uses an unrecognized value the config, the phrase this is incorrect, while strictly accurate, is a little harsh (and less FreeBSD-ish, I think). I would expect something more along the lines of Valid values are now (daily|weekly|NO). See periodic.conf(5) for more details. This gives the user the minimum information, leaves breadcrumbs ... and is a little less potentially pejorative. :-) Also, while I see the utility in toggling daily/weekly in the *_enable variables, how much precedent is there for overloading *_enable in this way? It's the first time that I've seen it, and may be a mild POLA violation. Most scripts seem to use *_enable solely as a binary YES/NO toggle, and then modify script behavior with other variables (perhaps _period in this case?) That would double the config size, though, so I definitely see why you went this route. Both of the above are closely related. If the period was stored in a different variable, and the default _period was daily, then the vast majority of the user base would still be correct and Just Keep Working ... and only those interested in weekly updates would need to modify anything. Just my $0.04. Royce ___ 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 Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: Thank you for this, but if I may make one suggestion: don't combine all the security report settings--keep both daily_* and weekly_*. This makes possible running some security tasks on a daily basis and others on a weekly basis. For example, daily pkg/portaudit checks, but weekly filesystem scans. Agreed. I welcome and would use the weekly option at this level of granularity, but would like to retain daily for many checks, and so would not use weekly if was an all-or-nothing option. Royce ___ 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: FreeBSD Kernel Internals, lecture video
On Sun, Aug 26, 2012 at 6:09 AM, Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Aug 26, 2012 at 9:25 AM, Chris Rees utis...@gmail.com wrote: On 26 Aug 2012 13:15, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: very expensive.. Training and education generally are. It's still very expensive. $100 I can understand, but $1000 for individuals? Take a look at the courses available on coursera.org, all for free. Take a look at the prices for video/audio courses on thegreatcourses.com. Combined with the fact that these videos were recorded from lectures given to an in-person audience, rather than produced specifically for home viewing, IMHO the price is quite unreasonable. These videos are the equivalent of learning about the Constitution from its framers. While some Coursera courses can say the same, they appear to be relatively few. This is also probably a significant portion of Kirk's income. Unlike the universities represented in Coursera, he has no regular day job that I'm aware of. He has no university infrastructure and funding model that is already paying him to create these courses (and just capturing them on the side for online use). Finally, he offers discounts: Please note that I offer a 25% discount to people that can make a plausible hardship case and a 50% discount to full-time students. Please contact me at mckus...@mckusick.com to verify that you qualify and to get instructions on how to order at the discounted price. I think that this all adds up to the pricing being quite fair. Royce ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 2, 2012 at 5:14 PM, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer jul...@freebsd.org wrote: On 8/2/12 9:53 AM, Doug Barton wrote: On 08/02/2012 09:44, Garrett Cooper wrote: The Watson/Losh connection worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for the right people, even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. Doug First, too many of these posts assume way too much. I don't think anyone should be thinking of any sort of what is commonly called teleconferencing. That would be nice, but is far more complex and expensive, both in bandwidth and equipment, then should be considered as a starting point. I suggest the starting point is a webpage with a link to the slides being presented and a simple audio stream. This is trivially possible with a FreeBSD system and open-source software. A bandwidth of only about 70kbps would be needed. Less with reasonable codec choice. Several streams could be broadcast via a single, unicast stream to a well connected server which woild then stream to end users It might be augmented with jabber other open IM technology with someone at the meeting if procedures for this could be agreed to. (Some vetting is desirable, but will result in calls of censorship.) For small rooms, microphones are fairly easy to handle and one-way streams don't require echo cancellation. As costs for video come down, that might be something to think about some day, but is not required to allow remote attendance. Of course, unless this is publicized, no one will come (which eliminates any technical issues). :-) Nail - head. Everything that Kevin just said. With so much collective technical experience and intelligence available, we can work out the minor kinks in a solved problem (one-to-many audio and slide sharing). Getting the word out is also a solved problem. Both are very high-leverage -- and very good for the project. If we think about live BSDCan streaming as a fun project with classic hack value, instead of an amorphous cloud of undoability, things will just come together naturally. The next action I see is calling for boots-on-the-ground volunteers to coordinate the local setup, and maybe a wiki page to capture the state of the project. Royce ___ 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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
Resending to list, forgot to hit reply-all. On Wed, Jun 13, 2012 at 10:06 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. [snip] Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). [my wishlist snipped] No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . Catch-22. This honestly reads as we can't stop for gas, we're already late. :-) I should have been more clear that I understand that this would require someone to step away from the firehose of work that not having such tools perpetuates. I certainly understand that it requires an effort of will to raise one's head high enough out of the lists/PRs/email swamp long enough, shake off some learned helplessness, and be inspired to tackle one of them. I struggle with that daily myself. There's a Not Invented Here comic strip that is quite applicable: http://notinventedhe.re/on/2010-3-8 [good Garrett summary of the resource problem snipped] So, rather than do things this way by posting wishlist projects that won't happen in the immediate future, why not make developers' lives easier by spreading the load, increasing the domain knowledge in one or more areas, and improving the community in the meantime? Affected companies/the Foundation should have more than enough funds to devote towards a handful of staff to make this a reality, even if the position is part-time. Remember: low hanging fruit - more likely to succeed - quicker/better RoI results. Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) The objections you're raising to my wish list could have been used, in the past, to justify anything from not writing send-pr (which was somewhat low-hanging fruit) to not writing freebsd-update (decidedly less trivial). Not all of my wishlist items require Herculean effort to make progress on. They just require someone who can both code, and see the light at the end of the tunnel that such a project would reveal. It's the never-ending chronic pain and whack-a-mole game of troubleshooting that makes us frame these things as wishes. If we take as an assumption that they're within reach, they might be. It calls to mind the last lines of Say Anything (if I may indulge my John Cusack fanboyhood): Diane Court: Nobody thinks it will work, do they? Lloyd Dobler: No. You just described every great success story. Royce ___ 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: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. Royce [1]. http://lists.freebsd.org/pipermail/freebsd-doc/2011-September/018865.html [2]. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037310.html ___ 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: iso2flash img
On Thu, Mar 22, 2012 at 3:15 AM, Luigi Rizzo ri...@iet.unipi.it wrote: On Wed, Mar 21, 2012 at 10:52:53AM -0500, Mark Felder wrote: As an alternative I recently purchased a Zalman ZM-VE200 device (there's also a USB3.0 flavor) that lets you copy ISOs to it and it will emulate a CDROM/DVDROM/BDROM for you so you never have to deal with this mess again. It works amazingly well. I was tired of fighting this problem and this is an amazing solution -- I can keep every ISO I ever need on a single drive. http://www.zalman.com/eng/product/Product_Read.asp?idx=431 http://www.zalman.com/eng/product/Product_Read.asp?idx=459 http://www.rmprepusb.com/tutorials/ve200 really nice, thanks for the link. Now if they had something that supported a USB key it would be even nicer... I *love* mine - it almost always Just Works. Since all you do is buy the enclosure (around $30), you can put in whatever size 2.5 drive you'd like. I threw in a 750G, so I have ~98G of CD and DVD images. There is a physical rocker switch for navigating the list of ISOs and mounting/unmounting them. You can also toggle ISO-only, drive-only, or hybrid/both mode, so I've got lots of other stuff on there that's handy once you've booted. It also has a physical read-only switch - great feature. The only hangup I've seen so far is if the BIOS doesn't support USB-attached optical drives. There are probably some workarounds for that out there (boot from a USB and then chainload-ish the optical drive), but I have not yet pursued them. There is undocumented support for floppy images as well. I haven't tested it, but there are success stories. *Highly* recommended. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
John's trying to manage risk. Switching from RELEASE to CURRENT adds a lot of risk and churn, when most folks in this class of use case just need a few very specific drivers and bugfixes (what some OSes call hotfixes.) John sounds willing to trade a little bit of local risk (and testing time) in exchange for a way to self-serve a hotfix without abandoning RELEASE. How can we enable that? There are simple cases -- the ones that just need a few files and a kernel module -- that seem within easy reach. For example, the eRacks guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and 8.2: http://blog.eracks.com/2011/08/lsi-logic-6gbps-mps-driver-for-freebsd-8-2-release/ For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE, and using freebsd-update) and eat it too (support for specific newer hardware). If security updates break my mps(4), I'm on my own -- but it's still a much better balance of risk for me than switching to CURRENT. I know that some fixes are harder than just adding a kernel module. I know that the standards for releasing errata are high, and they should be. But I wish there was a way to optionally lower that threshold and say: Yes, I know this might eat my data. Let me judge and test that for myself without otherwise abandoning RELEASE. If there was a way to mark hotfixes as worked for me (to let the better ones bubble up to the top), we non-coders could even help manage the list. I can't do it myself, but I would happily help brainstorm, test -- and commit $100 or more, Kickstarter-style, to fund someone else's work. Royce ___ 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
