Works for me. :) One last question regarding the os release vs kernel release. I've noticed ( at least on RH and AIX ) that these numbers are usually whole numbers. Technically, AIX 5.3 is a completely new OS than from AIX 5.2 ( think RHEL 5 vs RHEL 4 ) and they use maintenance levels as their versioning of release, so you end up with AIX 5.3 ML 4 ( equivalent to RHEL 5, Update 1 ).
Can the operatingsystemrelease be a string ( 5.3 ) or does it require it to be a whole number ( 5 ) for some other internal reason? I don't have access to anything besides RHEL ( which only returns 5 and not 5.1 or 5.0 ), so I thought I'd ask. -- steve On May 29, 3:55 pm, Luke Kanies <[EMAIL PROTECTED]> wrote: > On May 29, 2008, at 5:03 PM, [EMAIL PROTECTED] wrote: > > > > > > > Finally took the time to compile git for AIX so I could access the > > facter git repo and start working on the facter improvements - > > however, I wanted to sound off first on this and get a few opinions. > > > In essence, I'm trying to update some of facter's default facts to be > > more appropriate for AIX. However, because ( thanks IBM! ) AIX is so > > different, I'm unsure of what some of these should really be defined > > as. > > > First off - > > kernelrelease vs. operatingsystemrelease > > > Facter, on an AIX 5.3 system, returns '3' for both of these, which > > isn't technically correct - one of these needs to display '5', I'm > > just not sure which. I'm leaning towards operatingsystemrelease > > should display as 5 and kernel release should be 3. While AIX 5 is > > much different than 4, 5.2 isn't too much different than 5.3. > > This is largely arbitrary -- choose what you, as someone with AIX > experience, think makes more sense. > > > > > > > Secondly - hardwaremodel > > > By default, facter display this as the result of a 'uname -n' and on > > AIX this returns something like 00C4EC9C4C00, which according to AIX's > > man page: > > > "Displays the name of the node. This may be a name the system is known > > by to a UUCP communications network." > > > So obviously that's wrong. The real answer can be obtained with an > > 'lsattr -El sys0 -a modelname', but in order to get *just* the > > hardware model, you'd have to pipe this to a tail or awk. Is it > > 'kosher' to use pipes in the setcode in facter or would it be > > preferred to get the result and then do the string processing in Ruby > > to get the real model number? > > It's preferred to use Ruby to do the string processing -- it's not > nearly as difficult as you might think. :) > > > > > And thirdly - should these AIX improvements for the default facter > > facts even be included in the facter module or should I just implement > > these as my own personal custom facts? The only reason I thought they > > should belong in the facter release itself is because this would fix > > and add support for many of the default facts that facter has to begin > > with - rather than adding random custom facts. > > Yeah, I think they belong in the core, so they provide base support > for a new platform. > > -- > I don't deserve this award, but I have arthritis and I don't deserve > that either. -- Jack Benny > --------------------------------------------------------------------- > Luke Kanies |http://reductivelabs.com|http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
