Puppet » Facter

i think you should check @/etc/mtab@ first, as it sometimes consists better information (ie. what is exactly /dev/root under RHEL). it could be also nice to have full information about filesystems, not only mount point in facts (ie. @fs@ as a key).

this is how we do it (excuse my ruby, i don’t know how to eval);

# mounts.rb
 
fs_source = nil
if FileTest.exists?("/etc/mtab")
    fs_source = "/etc/mtab"
elsif FileTest.exists?("/proc/mounts")
    fs_source = "/proc/mounts"
end
 
if fs_source
    r = IO.popen("/bin/cat " + fs_source)
    r.each do |line|
        fs_spec, fs_file, fs_vfstype, fs_mntops, fs_freq, fs_passno = line.split(" ")
        if fs_spec == "rootfs"
            next
        end
        label = fs_file
        if label == "/"
            label = "_rootfs"
        else
            label = label.gsub(/\//, '_')
        end
        Facter.add("fs_spec" + label) do
            setcode do
                fs_spec
            end
        end
        Facter.add("fs_file" + label) do
            setcode do
                fs_file
            end
        end
        Facter.add("fs_vfstype" + label) do
            setcode do
                fs_vfstype
            end
        end
        Facter.add("fs_mntops" + label) do
            setcode do
                fs_mntops
            end
        end
        Facter.add("fs_freq" + label) do
            setcode do
                fs_freq
            end
        end
        Facter.add("fs_passno" + label) do
            setcode do
                fs_passno
            end
        end
    end
    r.close
end

Can you please send to the dev list as described in http://projects.puppetlabs.com/projects/puppet/wiki/Development_Development_Lifecycle – thanks

https://groups.google.com/group/puppet-dev/browse_thread/thread/e592fae2b322cd25/f81bd32c5bb360eb re different fact resolutions

It would be useful to dynamically control the ignorefs list somehow, not sure how this could be achieved though.

I’d like to use it determine if CD/DVD images (so iso9660) are mounted, and if so not attempt to manage the mountpoint.

Below is my take on the problem. I needed something similar that is distribution-agnostic.

Code for comments / reviews here: https://github.com/kwilczynski/facter-facts/blob/master/mounts.rb

I can add support for /etc/facts.d/mounts/exclude.list for Michael Knox if needed.

Hope that helps.

KW

Michael Kincaid wrote:

Thanks, Krzysztof. Ready for merge at https://github.com/mkincaid/facter/tree/ticket/2847

No problem! Thank you so much for writing tests! I struggle with spare time at the moment :–(

KW

Ken Barber wrote:

So after discussion with KW I think its going to be too difficult/inefficient to split the fact into two pieces and move the code into setcode.

Depends on the approach. We could have utility class with static methods there that ease parsing. On that note… Are we more pro enumerating “/sys” entries, or we are fine with processing /proc data as it is? Technically, “/sys” is the new “/proc”, but for what is worth “/proc” is here to stay.

There are still pending issues:

• The need for mutex troubles me – I’m curious to understand if this is a bug in the latest version of facter that this fact will be committed to. If it is indeed a bug we should get it raised somewhere – and then accept this workaround.

I put mutex in every fact I did, not only this particular one. I would recommend not spending too much time on pursuing this, and I will simply remove mutexes from my code. On this note, the following use Thread::exclusive for some reason too: processor.rb and util/memory.rb; I guess it is also not needed?

• There is a new version of mount.rb in KW’s repo: https://github.com/kwilczynski/facter-facts/blob/master/mounts.rb – when I do copy this in it throws unexpected invocation using the existing moch arrangement and needs to be fixed before merging.

Is this related to tests?

• The code breaks in ruby 1.9.2 & 1.9.3 due to the use of each. You can see this easily enough if you switch to ruby 1.9.2 with rvm.

I am not using 1.9.x anywhere yet. Perhaps later I will set myself up with up-to-date RVM and test it.

Also in regards to naming of the facts … ‘mounts’ is probably okay but ‘devices’ doesn’t make it obvious they are related and is ambiguous. Perhaps they should be something like:

• mounts_paths
• mounts_devices

Or something like that … since the idea is that they are arrays related by order having the prefix be the same makes it obvious. What does everyone think? Doing this kind of thing without proper structured data can be so ugly at the best of times :–).

What about “mount_points” instead of “mounts_paths”?

KW

• The need for mutex troubles me – I’m curious to understand if this is a bug in the latest version of facter that this fact will be committed to. If it is indeed a bug we should get it raised somewhere – and then accept this workaround.

I put mutex in every fact I did, not only this particular one. I would recommend not spending too much time on pursuing this, and I will simply remove mutexes from my code. On this note, the following use Thread::exclusive for some reason too: processor.rb and util/memory.rb; I guess it is also not needed?

Yeah I noticed that last night while I was digging around. I’ve asked the dev list. If its a bug its a bug and we should work around it. If you’ve seen bad side-effects in later facter then we should definitely work around it … but perhaps a mention of the bug in question in comments is needed.

The closest bug I can find on this is #4246.

I raised a message on the dev forum about it to see if anyone else has seen it for themselves:

http://groups.google.com/group/puppet-dev/browse_frm/thread/ccd4a7d762651aa5

• There is a new version of mount.rb in KW’s repo: https://github.com/kwilczynski/facter-facts/blob/master/mounts.rb – when I do copy this in it throws unexpected invocation using the existing moch arrangement and needs to be fixed before merging.

Is this related to tests?

Yes totally. And yes – if Michael is doing the tests for you this is probably more aimed at him.

• The code breaks in ruby 1.9.2 & 1.9.3 due to the use of each. You can see this easily enough if you switch to ruby 1.9.2 with rvm.

I am not using 1.9.x anywhere yet. Perhaps later I will set myself up with up-to-date RVM and test it.

We aim for future ruby support so we try to test on it. I think its a trivial fix tbh – just a deprecated use of each.

Also in regards to naming of the facts … ‘mounts’ is probably okay but ‘devices’ doesn’t make it obvious they are related and is ambiguous. Perhaps they should be something like:

• mounts_paths
• mounts_devices

Or something like that … since the idea is that they are arrays related by order having the prefix be the same makes it obvious. What does everyone think? Doing this kind of thing without proper structured data can be so ugly at the best of times :–).

What about “mount_points” instead of “mounts_paths”?

mount_points and mount_devices is fine … probably to match the current convention the file should be mount.rb then?

Ken Barber wrote:

Hey Michael – you wanna submit a pull request on this?

I have added a comment to his pull that recommends pulling newer version from me. It has a fix for parsing certain paths containing spaces in them, etc. I am not sure whether he read it :)

KW

Thanks for the added fix KW — pull request #42 is reopened and updated.

Krzysztof Wilczynski wrote:

I can add support for /etc/facts.d/mounts/exclude.list for Michael Knox if needed.

Hope that helps.

KW

Sorry for taking so long. Sounds like that is probably the way to go. Currently I use this fact as a module with the iso9660 exclusion removed but when it becomes core that won’t be so easy.

I’ve added Solaris support (tested on Solaris 10) to my github branch, https://github.com/mikeknox/facter/commit/f4886f13a7d47e485fa40a7a4ec260dc20560039

I’ve added the ability to modify the exclude list (https://github.com/mikeknox/facter/commit/4a3c3247de75943ec340fde879e148f3a08fdb48) if required.

If /etc/facts.d/mounts/exclude.list is present, it provides the values for exclude. exclude.list is just a whitespace delimited text file of filesystem types to exclude.

Michael Knox wrote:

I’ve added the ability to modify the exclude list (https://github.com/mikeknox/facter/commit/4a3c3247de75943ec340fde879e148f3a08fdb48) if required.

If /etc/facts.d/mounts/exclude.list is present, it provides the values for exclude. exclude.list is just a whitespace delimited text file of filesystem types to exclude.

So I like the idea of an exclusion list configuration file, but we would want to be wary of introducing configuration files without a good generic design. Configuration files for facter have been raised off and on and we’re always looking for use-cases to build up. We’ve raised this generic ticket to aid with the discussion: #11449.

As far as Solaris support – that is very awesome, thanks very much. Hold on to that thought – lets at least get the Linux one in since there are still design discussions going on. Perhaps we can raise a second ticket and link it to this one for housekeeping purposes – (unless mkincaid wants to incorporate it into his patchset now of course).

Anyway onto the point of exclusion lists … (and this I’m looking for your points as well KW). Is there any reason why we shouldn’t just allow the user of the fact to do the exclusion at runtime instead? ie. pass through all mount device types and let people filter in puppet code (ie. with a function or something). I think this is the main topic of contention at the moment that is blocking this ticket so I’d be interested in some objective views and points on this so we can push past this, as this ticket seems to be going on forever :–).

Hi Ken,

So I like the idea of an exclusion list configuration file, but we would want to be wary of introducing configuration files without a good generic design. Configuration files for facter have been raised off and on and we’re always looking for use-cases to build up. We’ve raised this generic ticket to aid with the discussion: #11449.

I do want to see the idea of facts having per-fact configuration file too, especially with new facts caching framework. I believe it would then make Facter more complete. Said that, there is nothing I can do at this point in time since such functionality is simply not present in Facter, therefore having a hard-coded (which is always bad, yes) list of things whether they are: file systems, devices types, etc … you name it; was the only feasible way to go.

As far as Solaris support – that is very awesome, thanks very much. Hold on to that thought – lets at least get the Linux one in since there are still design discussions going on. Perhaps we can raise a second ticket and link it to this one for housekeeping purposes – (unless mkincaid wants to incorporate it into his patchset now of course).

People over process, Ken :–) Please, I am begging you! :)

Anyway onto the point of exclusion lists … (and this I’m looking for your points as well KW). Is there any reason why we shouldn’t just allow the user of the fact to do the exclusion at runtime instead? ie. pass through all mount device types and let people filter in puppet code (ie. with a function or something). I think this is the main topic of contention at the moment that is blocking this ticket so I’d be interested in some objective views and points on this so we can push past this, as this ticket seems to be going on forever :–).

I believe that there is nothing wrong with this fact per se. There are already a numerous people using it whom have taken it straight from my github. Therefore, the very reason why this ticket is going forever lies somewhere else (yes, I am guilty of not having the time in most cases; my day job stands in the way somewhat, but that is not the main reason for it) :–(

About allowing people to filter for themselves. Look at my comment here. There is also this old problem of limited number of facts and data they expose that Facter can use (send over) as the length of parameters for GET request is not infinite unless this was solved already (citation needed), therefore sending everything may not be feasible and/or a good idea at all.

KW

As far as Solaris support – that is very awesome, thanks very much. Hold on to that thought – lets at least get the Linux one in since there are still design discussions going on. Perhaps we can raise a second ticket and link it to this one for housekeeping purposes – (unless mkincaid wants to incorporate it into his patchset now of course).

People over process, Ken :–) Please, I am begging you! :)

This has got nothing to do with process, its trying to not muddy the water with too many logical changes at once, and getting some sort of an accepted design now as apposed to later. Like I said – if mkincaid wants to integrate it into the patchset thats fine, but its going to take longer and obviously hacking facter isn’t his only day job :–).

There is no harm in having a separate change for this, I just don’t want to lose track of it. Anyway process is all about people isn’t it?

Anyway onto the point of exclusion lists … (and this I’m looking for your points as well KW). Is there any reason why we shouldn’t just allow the user of the fact to do the exclusion at runtime instead? ie. pass through all mount device types and let people filter in puppet code (ie. with a function or something). I think this is the main topic of contention at the moment that is blocking this ticket so I’d be interested in some objective views and points on this so we can push past this, as this ticket seems to be going on forever :–).

I believe that there is nothing wrong with this fact per se. There are already a numerous people using it whom have taken it straight from my github. Therefore, the very reason why this ticket is going forever lies somewhere else (yes, I am guilty of not having the time in most cases; my day job stands in the way somewhat, but that is not the main reason for it) :–(

So my question was – is there any reason why the user of the fact can’t do the exclusion at runtime instead? What I want to know is if there is a technical restriction on this, or an issue that would cause it to be a bad idea. If there is not, then I can’t see any harm in removing the exclusion list so we can cover the edge use-cases.

Also – going back to the Solaris example, this concept of exclusion list would be harder to maintain once you start covering other operating systems as well. I guess conceptually you would have different exclusion lists for every OS.

And – what if a new device type pops up that we didn’t anticipate? In that case – shouldn’t we just have a white-list instead? Where is the line drawn … what belongs in the exclusion list anyway?

My point primarily is that its going to always be user choice and we don’t have a configuration file mechanism today that we are happy with. Users will eventually want to change that exclusion list themselves, so can we just do away with it and not feel a side-effect?

About allowing people to filter for themselves. Look at my comment here. There is also this old problem of limited number of facts and data they expose that Facter can use (send over) as the length of parameters for GET request is not infinite unless this was solved already (citation needed), therefore sending everything may not be feasible and/or a good idea at all.

In 2.7.x it’s now a POST request. See #6117.

I guess adding extra mount types adds the question of what should we put in the mount_devices part. Where does one get the mount type info anyway?

If I was to be very honest about this fact anyway, I would say that its fairly unhelpful for a lot of cases until we have structured data support. Maybe we should just stuff JSON into the fact and fake it :–).

Okay – I think doing a mount point fact before structured data is implemented is going to be sub-par – at least having it in core. We really want to represent all fs types, however having this is going to look terrible in mount_devices and traversing the data in a flattened form is less-then-useful. The data really needs a hash I think, if we want to represent it properly and we just don’t do that now.

For this reason I’m going to shelve the current suggested branch/pull request until we get structured facts implemented. Sorry – feel free to convince me otherwise.

I’ll put a dependency on #4561 to reflect this. We are hopefully planning to implement #4561 for Telly (2.8) now anyway, so hopefully we won’t have long to wait.

Users who want to use KW’s implementation can find it here:

https://github.com/kwilczynski/facter-facts/blob/master/mounts.rb

Could you provide some information about what is insufficient with the code?

micah – wrote:

Could you provide some information about what is insufficient with the code?

My bet is on the design behind the fact versus Facter and its current inability to return complex structured data, which is what Ken Barber has envisioned will be the best for it.

KW