On Wed, Feb 16, 2005 at 07:34:44PM -0800, Robert Menschel wrote: >Hello George, > >Wednesday, February 16, 2005, 7:06:16 PM, you wrote: > >>>GG> Rather than squelching custom site rules, I think it more >>>GG> appropriate to verbosely report why rules become obsoleted (not >>>GG> necessarily in the new ruleset). Maybe a changes file for each cf >>>GG> file is appropriate? You cannot guarantee what or how anything is >>>GG> done in a local config, let the admin who created it address the >>>GG> changes too. >>> >>>The question then becomes, where to verbosely report these. Putting >>>into the config file probably doesn't help, since if RDJ sees the >>>--lint failure, it wipes out the config file that has the change >>>report, and if RDJ doesn't see a --lint failure, then there's no >>>reason for an admin to go looking for it. >>> >>>I'm open to suggestions. > >GG> I ended up looking but not finding a change log at: >GG> http://www.rulesemporium.com/rules.htm > >You'll find them inside the file(s) changed. In this specific case, >you'll find them inside 70_sare_header0.cf. > >However, compare the previous file's change history to the current >one. You'll see that I removed a whole bunch of detail, because the >change history was simply getting too long. I'm open to disagreement, >but for these types of files, I don't think it's appropriate to have a >change history longer than some of the files themselves.
No, I was only suggesting a single change log _entry_ be in each file, and a link to the the historical change logs. cf "this release" Per next paragraph. >GG> Maybe the way RDJ does the roll back needs be addressed? I know version >GG> 2 is nearing release, and this wouldn't be difficult to add: It could >GG> check the cf file for a grep-able, commented, "this release" changes >GG> entry, which may include a rules.htm#ChangesVerX url. > >GG> Then if some change broke your site, you get a likely indicator why, >GG> right there beside the roll back commands, near the lint output. And if >GG> your update is multiple revisions behind, you have a url to get started >GG> on finding changes at the relevant revision. > >But that's assuming the reason --lint fails is explained in the change >history. Past experience suggests that need not be the case -- --lint >fails more often because of typo errors rather than because of >intentional changes. In this case lint failed because of a change. Though I looked I couldn't find record of the change that made my configuration broken. That is the reason for my suggestion, I'm not looking for a better lint, that is what debug is for. If I break a config, there is a very good chance I know I did it. If the published ruleset changes, I'd like a change log entry presented or at least readily available. >GG> Actually, I like this proposed way of reporting changes a lot. I've >GG> always wondered the point of email notifications, "ruleset x has >GG> changed.." They kinda suggest I should do a diff and figure out if >GG> everything is really okay. I'd just assume see a change log as part of >GG> the notification that new rules have been loaded (or that lint prevented >GG> those changes from happening). > >Not everyone uses RDJ. I personally prefer to do my rule changes by >hand, after I've validated themselves against my own corpus. The email >notifications are more for people like me than the people who use RDJ >and want rule updates to be completely automatic. Even if someone doesn't use RDJ, isn't a 2-10 line commented change log in the cf file worthwhile? RDJ is not just for people who want to submit full trust. It can also be used to help automate distribution of fully validated enterprise rulesets, which happens to be the way I use it to distribute rulesets to my clients and is why I've been working with Chris Thielen to develop RDJ2, for better enterprise support and features that will help RDJ scale to support enterprise, and more clients and ruleset servers. #@@# A note specifying the recent changes made, with a comment designed #@@# for grep-ing would be useful for the casual RDJ user to monitor #@@# what automatic updates are doing, as well as function to notify the #@@# enterprise admin of the changes he needs to validate, and integrate #@@# with his private rules. If you are going through the trouble of publishing your rulesets for the ease of others to use, I don't see the point of forcing them to submit trust or manually discover changes when you publish them. Regards, // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
