domingo, 3 de mayo de 2015

Catársis de un bloqueo kilométrico

Si hay algo que me cuesta trabajos superar, es el hecho de ver como otras personas se brincan filas o no respetan a los demás cuando rebasan por acotamientos, siendo que cientos de personas mas están esperando con la misma paciencia en una fila kilométrica.
Esto nos sucedió ahora que a los amigos del gobierno se les ocurrió bloquear muchos de los accesos del estado de Jalisco fueron bloqueados. Observé muchos comportamientos que probablemente han sido estudiados por alguien, y es como cuando nos encontramos en grupo, cuando una persona como las que rebasan a los demás por el acotamiento pone el mal ejemplo, muchos otros imitan esa conducta en automático. Es mas fácil imita una conducta negativa que una positiva? Tendré que investigar un poquito al respecto para conocer el fenómeno.



Otro comportamiento curioso es el que vi cuando un automóvil que pasaba a un lado de nosotros traía el noticiero, al parecer un informe oficial sobre los hechos. Dado que en nuestro radio no llegaba la señal intentamos escuchar el auto vecino, se escucharon algunas declaraciones que no entendí muy bien, y un segundo después los que iban en ese auto comenzaron a proferir frases como "que mentiroso!", "quién va a creele!", Estoy de acuerdo con las frases que lanzaban, aunque me parece un poco infructuosa la manera de hacerlo. Si nos subimos a todos los rings de pelea que encontramos y la pasamos luchando unilateralmente, dia a dia, hora tras hora, año tras año, no sé, en mi opnión me parece la fórmula perfecta para desgastarnos interna y prematuramente.

Fuera de la temática violenta de la jornada y dado que hubo la oportunidad de desviarnos hacia la libre Guadalajara-Tepic por un paso que capufe abrió de entre sus túneles pasadizos, tuve las memorias de esta carretera que durante mi infancia viajé con mis padres en muchas ocasiones. Plan de barrancas es de esas carreteras libres que me imagino se asemejan a la famosa ruta 66, en su momento fué una carretera llena de actividad, pero ahora es una carretera vacía, hasta se aprecian limpios los acotamientos y orillas de la misma, señal de que desgraciadamente no circula mucha gente por ahí, o la gente que circula es gente muy limpia y educada. Me inclino mas por la primer opción.


viernes, 3 de abril de 2015

La misión

Comienzo a creer que mi misión ha terminado, ya vi lo que tenía que ver, ya hice lo que tenía que hacer, el resto es papalotear, consumir, y repetir en un ciclo hasta que se vaya la última gota de vida.


lunes, 30 de marzo de 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

jueves, 19 de marzo de 2015

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/mImcAAQWB3V5JDHbswee99C8CU6ekcw==

And manually append the output to your ssh_known_hosts/known_hosts file in the proper format (man ssh-keyscan):

     Output format for rsa1 keys:

     host-or-namelist bits exponent modulus

     Output format for rsa and dsa keys:

     host-or-namelist keytype base64-encoded-key

     Where keytype is either “ssh-rsa” or “ssh-dss”.


Distribute this file with a puppet class on your nodes and you won't be prompted again to add this new key into your known_hosts/ssh_known_hosts file at the first login attempt. 

For sure this is far from perfect, but solves the problem in a short time. 

martes, 10 de marzo de 2015

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
}

jueves, 5 de marzo de 2015

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