Mostrando entradas de marzo, 2015

Puppet custom fact easy as 1, 2, 3.

After taking a careful reading at creating a custom fact. The solution was as follows to get the net uuid from /etc/sysconfig/network-scripts/ifcfg-eth0:

My custom fact stored on <modulepath>/<module>/lib/facter/netuuid.rb: Facter.add('netuuid') do         setcode do                 Facter::Core::Execution.exec("echo `grep UUID /etc/sysconfig/network-scripts/ifcfg-eth0 | cut -c 7-42`")         end end
I have created the <modulepath>/<module>/templates/netuuid.erb with this content: <%= netuuid %>
And then call my custom netuuid facter variable on a template inside a manifest: class netuuid {         file { '/tmp/netuuid':                         path    => '/tmp/netuuid',                         ensure  => file,                         content => template("module1/netuuid.erb"),                 } }
# cat /tmp/netuuid e9ca61ca-7fee-4ce6-9728-f9eacd343b08


Pending: create a custom fact to retrieve the network UUID

Maintain known_hosts file with a puppet class

Each time an ssh client gets connected to another ssh remote host, a known_hosts file is generated or updated based on the remote host public key.

The purpose of this file is well explaines on the following link: http://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fknown_hosts
Let's say that we have a network with 100 servers and each time we add another server to this network all the machines need to update the known_hosts file with the new public key. 
First step: ask the new machine for it's public key with ssh-keyscan:
# ssh-keyscan localhost/remotehost # localhost SSH-2.0-OpenSSH_5.3 localhost ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAygRKDjzHw1a1L79f5rNaGlqPUDndZv9KhtZPG2MYrUrU/9NiBOiVDWwllUwWXQkLY3fhdTVncjGfzn4oc09876J3uXZJaNWr0PZpD8S7Y6+50iZWYVA0fTM0j32WdD3MMfJjCtrXo+/gDx9+XiQPXlWqkuy5L5PRIvjIzVeZwL6BDDalmQXx3Jw5QcfQn9Bc7m+Bw7ZO80mxnFnKH5zZa8jdjd6XPSLXN0Q+5UlvZ5o5hxaFA+4ywtvKbF6avlQj5rm9+6kGUkVLIZRVw+lkkGqSixsTMGC3mZURH2s38UB1OjHXQSW8DP/mImcAAQWB3V5JDHbs…

Puppet: estructura de un módulo y como invocar a sus clases

Dicen que es de sabios cambiar de opinión, pero también es de idiotas permanecer aferrados. Como sea, ahora que he estado aprendiendo algo de puppet, he tenido que generarme algunos módulos para hacer algunas tareas básicas de configuración en mis nodos. Para lo que es bueno recordar las siguientes referencias; basado en mi siguiente estructura de directorios:

# tree
└── base
    ├── files
    │   ├── hosts
    │   ├── motd
    │   └── vimrc
    ├── manifests
    │   ├── hosts.pp
    │   ├── init.pp
    │   ├── motd.pp
    │   └── vimrc.pp
    └── tests
        └── init.pp

4 directories, 8 files

Tendría que llamar a las clases de la siguiente manera:
# cat ../manifests/site.pp node 'foo-host' {         include base::hosts }
node 'default' {         include base::motd         include base::vimrc         include base::hosts }

Remember how to nat your network

Is a good idea to remember how to nat a network, so the lessons learned are always good lessons. This is for most linux distributions and not permanent changes (let's say a reboot will destroy this change).

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Also make sure we have a default gateway on the internal network:

# route add default gw aaa.bbb.ccc.ddd

And that's it.

More details on: http://www.revsys.com/writings/quicktips/nat.html