Puppet, cron cada 5 minutos

Ya hacía que no hablaba de Puppet en el blog, así que ya tocaba. No se si os acordáis, ya hace bastante tiempo, escribí un post donde explicaba cómo emplear valores aleatorios en puppet, lo que resultaba especialmente útil para un manifiesto que use cron, ya que evitábamos que todas las máquinas tirasen del recurso programado al mismo tiempo.

Pues hoy vamos a ver algo más sobre cron aplicado desde Puppet. Este es el manifiesto de partida,

cron { "update mirror":
   command   => "/usr/local/sbin/update_mirror",
   user      => root,
   hour      => 18,
   minute    => 30,
   subscribe => File["/usr/local/sbin/update_mirror"],
   ensure    => present;
}

Como se puede observar vemos que a las 18:30 se ejecuta el tarea programada. Ahora imaginémonos por un momento que nos interesa que el trabajo se ejecute cada 10 minutos. Pues bien, para hacer eso, podíamos suprimir la línea de la hora y quedarnos con una línea de minutos tal que así,

cron{
   ...
   minute    => [2,15,25,35,45,55],
   ...
}

Realmente esta opción es perfectamente viable, pero el resultado que produce no es muy bonito que digamos, a nivel de cron,

shell> crontab -e
5,15,25,35,45,55 * * * *   /usr/local/sbin/update_mirror

Aunque esta solución es perfectamente válida, quizás no sea la más óptima, ya que si tenemos que ejecutarlo cada minuto, nos quedaría una línea "un poco grande". Así que para optimizarlo, podemos hacer algo tal que así:

cron{
   ...
   minute    => "*/10"
   ...
}

Lo que produciría el siguiente resultado,

shell> crontab -e
*/5 * * * *   /usr/local/sbin/update_mirror

Leer más

puppet manifest for ntp

Clase ntp:

class ntp {
   package { "ntp":
      ensure     => installed;
   }

   group { "ntp":
      ensure     => present;
   }

   define ntpconf ($ntpserver = [ "0.debian.pool.ntp.org" ]) {
      file { "/etc/ntp.conf":
         owner   => root,
         group   => root,
         mode    => 644,
         content => template("ntp.conf.erb"),
         require => Package[ "ntp" ],
         notify  => Service[ "ntp" ];
      }
   }

   service { "ntp":
      name       => $operatingsystem ?{
         debian  => "ntp",
         ubuntu  => "ntp",
         default => "ntpd",
      },
      ensure     => running,
      enable     => true,
      provider   => debian,
      subscribe  => File[ "/etc/ntp.conf" ];
   }
}

Y la forma de usarlo,

include ntp
ntp::ntpconf { "ntp":
   ntpserver => [ "0.debian.pool.ntp.org", "127.0.0.1" ]
}

Leer más

puppet: decisiones usando facter

puppet usa por defecto una serie de variables que son dadas por facter, un software que comprueba diversos parámetros del sistema cliente y se los envía al máster para poder usarlos y tomar decisiones.
Las principales variables de facter se verán en otro post, pero entre ellas se encuentra la versión del sistema operativo, el sistema operativo, la IP, el dominio, etc.



Un ejemplo de éste uso sería:

file { "localtime":
   path  => $operatingsystem ?{
      debian  => "/etc/localtime",
      ubuntu  => "/etc/localtime",
      redhat  => "/etc/sysconfig/clock",
      centos  => "/etc/sysconfig/clock",
      suse    => "/etc/sysconfig/clock",
      default => "/etc/localtime", 
   },
   owner => root,
   group => root,
   mode  => 0644;
}

O también, esta otra forma,

...
case $fqdn {
   server1.domain.com: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "miguel@company.com" ];
      }
   }

   server3.company.es: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "javier@company.com" ];
      }
   }

   default: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "logs@company.com" ];
      }
   }
}
...

Leer más

puppet: usando parámetros para mejorar legibilidad

puppet permite realizar configuraciones complejas basadas en parámetros, lo cual permite la posterior exportación de las configuraciones a otros sistemas y arquitecturas de una forma mucho más simple.

Escenificándolo, se podría crear una clase, params, sobre la cual se definirán los diversos valores que podrán coger las variable, en función de determinados parámetros, por ejemplo $operatingsystem.

class basico::params {
   $provider = $operatingsystem ? {
      /(ubuntu|debian)/ => "debian",
      default           => "init",
   }
   $atoppack = $operatingsystem ? {
      default           => "atop",
   }
}

Y luego sólo habría que incluir dicha subclase donde se desee usar y llamar a sus variables, que siempre tendrán un valor.

class basico::atop {
   require bascio::params

   package { "atop":
      name     => "${basico::params::atoppack}",
      ensure   => installed;
   }
}

En este ejemplo, el paquete atop está únicamente disponible para sistemas debian/ubuntu, en caso de que ahora aparezca un nuevo sistema redhat, en el que el paquete atop tiene otro nombre, atop.noarch, éste no se podría instalar desde puppet sin modificar la clase basico::atop con un case. Al tener la clase de params definida, únicamente habría que añadir un nuevo valor redhat para la variable $atoppack, tal como sigue,

class basico::params {
   $atoppack = $operatingsystem ? {
      redhat  => "atop.noarch",
      default => "atop",
   }
}

Aunque su utilidad pueda no parecer muy grande, realmente sí lo es, por que la toma de decisiones en función de casos está en un único fichero y no dentro del propio manifiesto, lo que asegura que no se altere el funcionamiento. Aunque en el caso presentado su utilidad puede no ser excesiva, el uso de una subclase para los parámetros es altamente recomendable.

Leer más

puppet manifest for zabbix-agent

A continuación, el manifiesto necesario para instalar el agente zabbix en todos los sistemas cliente que deseemos sin esfuerzo alguno desde puppet.

Primero, creamos la subclase de parámetros, por si es necesario alguna modificación, sólo tocar este fichero.

class zabbix::params {
   $agent_packagename = $operatingsystem ? {
      debian=> "zabbix-agent",
      ubuntu=> "zabbix-agent",
      default=> "zabbix",
   }

   $server_packagename = $operatingsystem ? {
      debian=> "zabbix-server-mysql",
      ubuntu=> "zabbix-server-mysql",
      default=> "zabbix-server",
   }

   $provider = $operatingsystem ? {
      debian=> "debian",
      ubuntu=> "debian",
      default=> "init",
   }

   $agent_servicename = $operatingsystem ? {
      debian=> "zabbix-agent",
      ubuntu=> "zabbix-agent",
      default=> "zabbix",
   }

   $server_servicename = $operatingsystem ? {
      debian=> "zabbix-server",
      ubuntu=> "zabbix-server",
      default=> "zabbix-server-mysql",
   }

   $agent_configfiled = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_agentd.conf",
   }

   $agent_configfile = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_agent.conf",
   }

   $server_configfiled = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_server.conf",
   }

   $agent_dir = $operatingsystem ? {
      default=> "/etc/zabbix",
   }
}

La clase zabbix.

Leer más

puppet manifest for git

Como se comentó en el último post sobre git, antes de comenzar a usarlo y crear repositorios, se muestra la clase que permite la configuración automática de git cuando un usuario se crea desde puppet.

class usuarios {
   define add_user($username, $git=false) {
      user { "$name":
         ensure        => present,
         membership    => inclusive,
         comment       => $username,
         home          => "/home/$name",
         provider      => useradd,
         shell         => "/bin/bash",
      }

      file { "/home/$name/":
         owner         => $name,
         group         => $operatingsystem ? {
            suse       => "users",
            default    => "$name",
         },
         mode          => 750,
         ensure        => directory;
      }
      if $key {
         file { "/home/$name/.gitconfig":
            owner      => $name,
            group      => $operatingsystem ? {
               suse    => "users",
               default => "$name",
            },
            mode       => 0600,
            require    => File["/home/$name"],
            content    => template("templates/gitconfig.erb");
         }
      }
   }
}

Leer más