[Facter]: The use of ENV objects in Facter

[William Van Hevelingen]

Hello All,

I have a facter question, is the use of ruby environmental variables encouraged or discouraged? I noticed that path.rb uses the ruby ENV object, but id.rb does not use it. However, if id.rb did use it then it could be reduced to 5 lines like so:

Facter.add(:id) do

    setcode do

        ENV['USER']

    end

end

Is there any particular reason that 'whoami' (Linux) and 'id' (Solaris) are used instead?

Here is some custom facts i made for windows. What do you think?

  1 # Windows specific facts

  2 

  3 Facter.add(:homeshare) do

  4     confine :kernel => %w{Windows}

  5     setcode do

  6         ENV['HOMESHARE']

  7     end

  8 end

  9 

 10 # Doesn't notice if its a roaming profile

 11 Facter.add(:userprofile) do

 12     confine :kernel => %w{Windows}

 13     setcode do

 14         ENV['USERPROFILE']

 15     end

 16 end

 17 

 18 Facter.add(:appdata) do

 19     confine :kernel => %w{Windows}

 20     setcode do

 21         ENV['APPDATA']

 22     end

 23 end

 24

 25 Facter.add(:deploydate) do

 26     confine :kernel => %w{Windows}

 27     setcode do

 28         ENV['DEPLOY_DATE']

 29     end

 30 end

--
William Van Hevelingen
Portland State University
wv...@cs.pdx.edu

[Marc Fournier]

Hello,

> I have a facter question, is the use of ruby environmental variables
> encouraged or discouraged? I noticed that path.rb uses the ruby ENV
> object, but id.rb does not use it. However, if id.rb did use it then
> it could be reduced to 5 lines like so:
>
> Facter.add(:id) do
> setcode do
> ENV['USER']
> end
> end

Not really answering your question, but when I just want to have
environment variables appear as facts, I use the (little known) ability
of facter to transform every variable prepended with "FACTER_" to a
fact:

$ FACTER_foo="bar" facter foo
bar
$ FACTER_now=$(date) facter now
Sun May 30 14:07:19 CEST 2010

Cheers,
Marc

[Luke Kanies]

Seems pretty reasonable, although it almost seems worth adding a special hook:

Facter.envfact(:deploydate) { confine :kernel => %w{Windows} }

Which just does the above, but skips most of the duplication.

In general, the reason I've always avoided relying on ENV is that it's so easy for the data to not be right at different times, at least I think I've experienced that.  It's always tough to track whether a given ENV variable is overwriteable, guaranteed, always set, etc.

-- 

The people who are regarded as moral luminaries are those who forego
ordinary pleasures themselves and find compensation in interfering
with the pleasures of others. -- Bertrand Russell

---------------------------------------------------------------------

Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199

[William Van Hevelingen]

Facter.envfact(:deploydate) { confine :kernel => %w{Windows} }

 

Thanks that looks great.

In general, the reason I've always avoided relying on ENV is that it's so easy for the data to not be right at different times, at least I think I've experienced that.  It's always tough to track whether a given ENV variable is overwriteable, guaranteed, always set, etc.

 Yea I noticed that the documentation is very hard to find concerning the ENV object and whether any ENV variables are guaranteed.

Thanks Luke

Cheers
--
William Van Hevelingen
Computer Science Major
Portland State University
wv...@cs.pdx.edu

[Luke Kanies]

On May 31, 2010, at 2:36 PM, William Van Hevelingen wrote:

Facter.envfact(:deploydate) { confine :kernel => %w{Windows} }

 

Thanks that looks great.

In general, the reason I've always avoided relying on ENV is that it's so easy for the data to not be right at different times, at least I think I've experienced that.  It's always tough to track whether a given ENV variable is overwriteable, guaranteed, always set, etc.

 Yea I noticed that the documentation is very hard to find concerning the ENV object and whether any ENV variables are guaranteed.

It's not about the ENV hash itself, it's about what the shell/environment actually provides.  And trusting, say, HP-UX vs. Debian vs. Red Hat to provide similar information just seemed crazy.  And I wrote most of the first versions of Facter specifically because I was so distrustful if everything the OS thought I wanted to know.

-- 

If it jams, force it. If it breaks, it probably needed replacing
anyway. -- Lowrey's Law

[Michael DeHaan]

If your process is execed directly from custom /bin/init is their an ENV at all?  Not that  it should be likely or sane ... but it is legal :).  +1 to not relying on that whenever possible.

-- Michael

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

[Luke Kanies]

I think essentially everyone on *nix guarantees some level of environment - e.g., USER, PATH, probably UID and GID, and likely a few others.

Not sure, but hey, that's why I didn't rely on it. :)

-- 

Today at work an ethernet switch decided to take the 'N' out of NVRAM
    -- Richard Letts