I’ve been having a look at the new SCM site procedures and would like to pass on a couple of initial thoughts.
I like the idea of being able to set parameters from within the fixlet but how can I have different parameters for the same check? i.e. Default System Accounts and Cron (GEN003060). We allow some system accounts (sys and adm) to run cron jobs but ONLY on some servers, not all.
If I change a parameter for a check, this doesn’t appear to be propagated immediately. I’m guessing that it will only change when the Deploy and Run task is actioned again. This may only happen every 24 hours (or more) but I would like to see the effect of my parameter change immediately on my endpoints. (see feature request (1) below)
I’m presuming the ‘Create Custom Checklist’ wizard does more than simply copy all the fixlets/tasks/analysis from an external site to a custom site. If that is correct, how can I add a new fixlet or a group of fixlets to an existing custom site? I’m working on the premise that I will probably start with a selected set of fixlets and then add to those over time. Will I have to re-copy ALL the fixlets and remove the ones I don’t want again?
Following on from 3) - the wizard won’t allow you to overwrite an existing custom site which would mean that, if my assumptions in 3) are correct or you released updated fixlets (not that I would be able to tell - see my previous post on version control) because of functionality changes or bug fixes, then I would have to delete my existing custom site then recreate it. The obvious flaw with that is that I would have to re-enter all of my customized parameters again!
I’ve just noticed that the GENxxxxxx scripts fail after I have modified the parameters. The contents of the GENxxxxxx.detect.log file contains “./SunOS/5.10/GEN000600a.detect: test: unknown operator ‘-ge’”. I’ve run the script manually (using runme.sh -t -f GEN000600a) and have attached the detect.log file.
Some feature requests to start with…
How about a task that would allow an operator to run a single GEN script that you specify as a parameter on an ad hoc basis? This would allow us to modify a fixlets parameters and see it’s effect across all our end points without having to wait for the daily ‘Deploy and Run’ task to execute.
In the ‘Create Custom Checklist’ wizard, allow the operator to specify which fixlets/tasks/analysis should be copied. This list could be, perhaps, sourced from various places - a flat file, point-and-click selection, manually typed in, etc - and, ideally, should be preserved between executions of the wizard for each external site. This would a) get over the problem of managing updated content (the wizard could check to see if the fixlet has been updated or not) and b) allow us to add content as we expand the custom site checks and c) prevent the need to copy ALL fixlets and then delete the ones we don’t want. Standard fixlets/tasks such as the ‘Deploy and Run’ task should be automatically added by default.
My name is Craig and I’m a developer on the SCM team here at BigFix. First off, thanks for your feedback and suggestions - this is great stuff! Thoughts/comments are as follows:
Unfortunately, there currently isn’t a particularly clean way to set different parameter values for the same check (i.e. for different computers). The currently recommended work-around for this is simply to copy the fixlet in question (usually added to a different custom site), set a different value, and target it to a different set of endpoints. Of course, this introduces some possible issues with consistency and maintenance, but I’m afraid it’s the best option available with our current framework.
For Unix content, you must execute the “Deploy and Run” task in order for a parameterization to take effect.
In its current incarnation, the wizard simply does exactly what you describe - it just copies all fixlets, analyses, and tasks from the selected external sites and sticks them in a new custom site. We are currently working on implementing a number of improvements that will allow for greater granularity in this process (i.e. selecting individual fixlets via manual selection or filters, detecting modifications to the source content, synchronizing/merging of these changes, etc.), but as of now, it just dumps everything in the new site. As a work around for this, you may navigate to the new site after creating it via the wizard, and choose to remove individual fixlets (via right-click menu), or add additional fixlets to it (by right-clicking the source fixlet(s) you would like to add).
Yes, you are correct - under the current model, you would have to delete and re-create (and therefore re-customize) all the fixlets in your custom site if/when you want to pull in the latest updates from the original source external site. We know this is a big inconvenience, and solving this problem is a very high priority for myself and the rest of the SCM development team right now.
This is a known bug in our content, and a fix is currently scheduled to be released in the very near future.
Regarding your requests:
This is possible by modifying the “Deploy and Run” task. The runme.sh script takes a -f argument so you can do something like: runme.sh -f GEN001234 and it will only run that one script. You can also run runme.sh -F
where is a plain text file containing something like the following:
GEN1234
GEN2345
…
Many of these requests are already in development. Currently, we are planning to allow for selecting individual fixlets from any subscribed external sites, and most likely from any existing SCM custom sites as well. We aren’t currently planning on providing for pulling from a a flat file, but it’s a good suggestion, and we’ll certainly consider it as we continue to toss these ideas around. Preserving the state of an “In Progress” custom site prior to “publishing” it to an actual custom site is something we’ve talked about before, and are seriously considering as well. The same goes for detecting changes in the source external sites (as I mentioned above).
Thanks again for your feedback. Knowing that real customers like you are actively requesting a particular feature will certainly strengthen the case for including it in the project roadmap for upcoming releases, so please don’t hesitate to continue speaking up!