> >>> The evidence of such trouble is evident already in a much simpler area: > >>> recognizing operating system versions and releases. HP-UX 11 had this > >>> problem, and the numerous various Linux distributions render this almost > >>> impossible to keep up with. Does cfengine recognize White Box Linux? > >>> TinySofa? Enguarde? Vine? Miracle? Red Flag? And most importantly, can > >>> it be made to recognize these variants without recompiling?
> >> Agreed, 100% with you on that one. The magic string file method would > >> probably be a workable solution there, then folks would only have to > >> download the latest magic string file to be updated. They could even > >> distribute that through cfengine as well via update.conf. I still think > >> there'd have to be some level of detection in code to at least determine > >> the OS type (Linux, HP-UX, Solaris), since those are reliably obtainable > >> with uname(), but once that was known, a magic string check could > >> probably be applied to find specifically what you are dealing with. I think you're confusing the detection of OSs (names and kernel revs via uname) with Linux distributions here. Cfengine already has OS detection via "uname", "uname -r" and the like. Kernel info (uname) doesn't work for detecting Linux distros: different distros can have the same kernel names and versions (eg Scientific Linux and RHEL.) > > Perhaps the module previously put up for Scientific Linux would work in a > > more general fashion? Of course. > I'd be in favour, but I don't know how others would feel about > perl :). Keep in mind that the classes my module defines won't work in all places. For example, it doesn't work in the "files:" section. I haven't really investigated this peculiarity; I assume files: gets evaluated before modules do. steve - - - systems & network manager high energy physics university of wisconsin _______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
