Puppet users - Apr 2010 - Default Gateway facter problems

I was slightly surprised to see that there is no "gateway" fact. I
poked around and it seems easy enough to add but I''m running into a
problem... My gateway.rb looks like:

# gateway.rb

Facter.add("gateway") do
    setcode do
        begin
            Facter.lsbdistid
        rescue
            Facter.loadfacts()
        end
        distid = Facter.value(''lsbdistid'')
        if distid.match(/RedHatEnterprise|CentOS|Fedora/)
            gateway = %x{grep GATEWAY= /etc/sysconfig/network|sed -e
''s/GATEWAY=//''}.chomp
        elsif distid.match(/Ubuntu|Debian/)
            gateway = %x{/bin/grep -E ''^[     ]*gateway''
/etc/network/
interfaces|/bin/sed -e ''s/^[         ]*gateway[     
]//''}.chomp
        else
            gateway = "undefined"
        end
        gateway
    end
end

# end gateway.rb

I can see the fact on the client node (but only if I add "--puppet"):
# facter --puppet|grep gateway
gateway => 10.2.0.3
# facter|grep gateway
#

I can''t seem to see the gateway fact for the client on the
puppetmasterd node though...

# grep gateway /var/lib/puppet/yaml/node/test.example.org.yaml
#

And when I run puppetd I get the following:
# puppetd -o -t
info: Retrieving plugin
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed to parse template syslog/syslog.conf.erb: Could not
find value for ''gateway'' at
/etc/puppet/modules/syslog/manifests/
init.pp:17 on node test.example.org
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
#

I should note that syslog/syslog.conf.erb is a template that
references "<%= gateway %>".

Any ideas? I have "pluginsync = true" and I''m using 0.25.4 on
both
nodes.

Scott

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

Scott Beardsley <sc0ttbeardsley@gmail.com> writes:
> I was slightly surprised to see that there is no "gateway" fact.
Er, this fact is mostly unhelpful: there is no "gateway" — there are
zero-or-more gateways, depending on the route on the server, which may or may
not get used to communicate to any given destination.

A number of our machines have two or more gateways, since they have multiple
paths to other networks, differentiated by route priority and/or manipulated
by a routing protocol.

So, a simple "gateway" fact is essentially meaningless for our
network; this
is probably true of at-least-some machines on at-least-some large networks.


(So, while your fact is meaningful, it isn''t a generic
"gateway" fact :)
> I poked around and it seems easy enough to add but I''m running
into a
> problem... My gateway.rb looks like:
[...]
>         elsif distid.match(/Ubuntu|Debian/)
>             gateway = %x{/bin/grep -E ''^[     ]*gateway''
/etc/network/
> interfaces|/bin/sed -e ''s/^[         ]*gateway[     
]//''}.chomp
This can return multiple results, trivially, even on a simple network where
you have multiple definitions in /etc/network/interfaces; it breaks in the
face of network mapping, or of having two NICs with gateway statements.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>         distid = Facter.value(''lsbdistid'')
>         if distid.match(/RedHatEnterprise|CentOS|Fedora/)
sidenote: you can use confine for such things.

[...]
> I can see the fact on the client node (but only if I add
"--puppet"):
> # facter --puppet|grep gateway
> gateway => 10.2.0.3
> # facter|grep gateway
> #
right, that might be related to a known bug. but that shouldn''t affect
puppet.

[...]
> And when I run puppetd I get the following:
> # puppetd -o -t
btw: -t implies onetime
> info: Retrieving plugin
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Failed to parse template syslog/syslog.conf.erb: Could not
> find value for ''gateway'' at
/etc/puppet/modules/syslog/manifests/
> init.pp:17 on node test.example.org
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> #
> 
> I should note that syslog/syslog.conf.erb is a template that
> references "<%= gateway %>".
> 
> Any ideas? I have "pluginsync = true" and I''m using
0.25.4 on both
> nodes.
so if you remove your fact from the client you see that it is downloaded
by the master?

I assume you distribute your new fact in a module? Can you run it a bit
more in debug mode?

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvNTBMACgkQbwltcAfKi3/TwwCfR9l+WediGah8tuL+Y/NLTo6K
JfgAn24q7Nsg2VjhxCVa3hCN4AFtKWta
=2lPO
-----END PGP SIGNATURE-----

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

On Apr 19, 10:09 pm, Daniel Pittman <dan...@rimspace.net>
wrote:
> So, a simple "gateway" fact is essentially meaningless for our
network; this
> is probably true of at-least-some machines on at-least-some large networks.
>
> (So, while your fact is meaningful, it isn''t a generic
"gateway" fact :)
<snip>
> This can return multiple results, trivially, even on a simple network where
> you have multiple definitions in /etc/network/interfaces; it breaks in the
> face of network mapping, or of having two NICs with gateway statements.
When I made up my sites broadcast fact I solved it in a manner like
interfaces.rb. Essentially there are multiple "broadcast_$interface"
facts, and while creating these the interface associated with
"ipaddress" also sets the "broadcast" fact as primary.

Moving on to the gateway fact; I think a trivial solution is to use
your array of gateways to create a series of "gateway_$n"[1] facts. If
you can detect a default then that can be "gateway". Given I
haven''t
looked at this exact problem yet, so I could be overlooking the hard
bits.

[1] I could have *sworn* Facter::Util had a method for exactly this,
but now I don''t see it of course.

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

donavan <donavan@desinc.net> writes:
> On Apr 19, 10:09 pm, Daniel Pittman <dan...@rimspace.net> wrote:
>> So, a simple "gateway" fact is essentially meaningless for
our network; this
>> is probably true of at-least-some machines on at-least-some large
networks.
>>
>> (So, while your fact is meaningful, it isn''t a generic
"gateway" fact :)
> <snip>
>> This can return multiple results, trivially, even on a simple network
where
>> you have multiple definitions in /etc/network/interfaces; it breaks in
the
>> face of network mapping, or of having two NICs with gateway statements.
>
> When I made up my sites broadcast fact I solved it in a manner like
> interfaces.rb. Essentially there are multiple
"broadcast_$interface"
> facts, and while creating these the interface associated with
> "ipaddress" also sets the "broadcast" fact as primary.
What do you do about an interface like this:

2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
  link/ether 00:30:48:97:59:ae brd ff:ff:ff:ff:ff:ff
  inet 192.168.10.11/24 brd 192.168.10.255 scope global eth0
  inet 192.168.10.130/24 brd 192.168.10.255 scope global secondary eth0:0
  inet 192.168.10.131/24 brd 192.168.10.255 scope global secondary eth0:1
  inet 192.168.10.132/24 brd 192.168.10.255 scope global secondary eth0:2

(Actually, that one is easy as all the extra addresses are in the same
 segment.  We have other machines where they are not...)
> Moving on to the gateway fact; I think a trivial solution is to use
> your array of gateways to create a series of "gateway_$n"[1]
facts.
...by "gateway" do you mean "default route", or just
"gateway" — we have hosts
that have a dozen different routes, and sometimes no default route at all,
that act inside the network.

So, there would be a different "gateway" for the 0/0, 192.168/8, and
10/8
networks, as a trivial example.
> If you can detect a default then that can be "gateway". Given I
haven''t
> looked at this exact problem yet, so I could be overlooking the hard bits.
I think the problem is that there is a mismatch between the simple
"gateway"
model of networking, and the reality of IP networking.

For many people today, they only deal with simple machines: one local route,
to their connected Ethernet segment, and one default route to the rest of the
world.

Once you start getting multiple sites, and a need for network availability,
this starts to fall off: you will have at least some systems that have
multiple routes to other parts of the network, and then the wheels fall off.


In my opinion building assumptions that fall apart in the face of complexity
into puppet is a bad strategy — and this is just as true if you do that in the
manifests you write yourself as if the upstream developers do it.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

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

> >         if distid.match(/RedHatEnterprise|CentOS|Fedora/)
>
> sidenote: you can use confine for such things.
I''ll look into confine. Incidentally this is my first fact and I stole
most of it from the puppet docs.
> right, that might be related to a known bug. but that shouldn''t
affect puppet.
ok. I did see a post elsewhere that made me suspect this was a bug. It
sounded like it was minor and didn''t affect any real functionality
though.
> btw: -t implies onetime
Ahh, didn''t know that. Thanks.
> so if you remove your fact from the client you see that it is downloaded
> by the master?
Yes.
> I assume you distribute your new fact in a module?
Yes. Is there a different, preferred way to distribute it?
> Can you run it a bit more in debug mode?
The debug output isn''t very helpful...

puppetd -tvd
debug: Failed to load library ''selinux'' for feature
''selinux''
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Failed to load library ''ldap'' for feature
''ldap''
debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
dscl does not exist
debug: /File[/var/lib/puppet/ssl/certs/test.example.org.pem]:
Autorequiring File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/
puppet/ssl]
debug: /File[/var/lib/puppet/ssl/public_keys/test.example.org.pem]:
Autorequiring File[/var/lib/puppet/ssl/public_keys]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
lib/puppet]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/
lib/puppet/ssl]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
puppet]
debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
debug: /File[/var/run/puppet/puppetd.pid]: Autorequiring File[/var/run/
puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/
puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/
var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/private_keys/test.example.org.pem]:
Autorequiring File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/
puppet/ssl]
debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/
var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/
var/lib/puppet/state]
debug: Finishing transaction 23724655480440 with 0 changes
debug: Using cached certificate for ca, good until Mon Apr 06 20:53:28
UTC 2015
debug: Using cached certificate for test.example.org, good until Sat
Apr 11 23:40:54 UTC 2015
debug: Loaded state in 0.00 seconds
info: Retrieving plugin
debug: Using cached certificate for ca, good until Mon Apr 06 20:53:28
UTC 2015
debug: Using cached certificate for test.example.org, good until Sat
Apr 11 23:40:54 UTC 2015
debug: Using cached certificate_revocation_list for ca, good until
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw
yaml; using pson
debug: Finishing transaction 23724655053440 with 0 changes
debug: catalog supports formats: b64_zlib_yaml marshal pson raw yaml;
using pson
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed to parse template syslog/syslog.conf.erb: Could not
find value for ''gateway'' at
/etc/puppet/modules/syslog/manifests/
init.pp:17 on node test.example.org
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

One question, do templates get parsed on the master or the client? If
the former it could be that the master itself doesn''t have a valid
entry for "gateway" (it doesn''t because it gets the default
gw from
dhcp not a config file).

Thanks Pete,
Scott

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

Hi all:

El Miércoles, 21 de Abril de 2010 06:55:29, Daniel Pittman
escribió:
> donavan <donavan@desinc.net> writes:
[...]
> > When I made up my sites broadcast fact I solved it in a manner like
> > interfaces.rb. Essentially there are multiple
"broadcast_$interface"
> > facts, and while creating these the interface associated with
> > "ipaddress" also sets the "broadcast" fact as
primary.
>
> What do you do about an interface like this:
>
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
qlen 1000
>   link/ether 00:30:48:97:59:ae brd ff:ff:ff:ff:ff:ff
>   inet 192.168.10.11/24 brd 192.168.10.255 scope global eth0
>   inet 192.168.10.130/24 brd 192.168.10.255 scope global secondary eth0:0
>   inet 192.168.10.131/24 brd 192.168.10.255 scope global secondary eth0:1
>   inet 192.168.10.132/24 brd 192.168.10.255 scope global secondary eth0:2
>
> (Actually, that one is easy as all the extra addresses are in the same
>  segment.  We have other machines where they are not...)
>
> > Moving on to the gateway fact; I think a trivial solution is to use
> > your array of gateways to create a series of "gateway_$n"[1]
facts.
>
> ...by "gateway" do you mean "default route", or just
"gateway" — we have
> hosts that have a dozen different routes, and sometimes no default route at
> all, that act inside the network.
*Or* even multiple default gateways since a "default gateway" is
nothing but
one that allows routing to 0/0.  When more that one is defined, provided they 
have the same metric, the first one is always used unless fail is detected in 
which case the second one is tried in turn, etc.

Cheers.

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

I''ve filed an issue[1] for this. I don''t think it is a bug in
facter
since it is returning the fact correctly.

As for the gateway fact discussion... Most of my puppetized systems
are pretty simple (HPC clusters) so they typically have a single
default gateway. Does facter only support string data types? Maybe it
could support more complex data types?

Scott
------------
[1] http://projects.puppetlabs.com/issues/3653

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