Cosas a tener en cuenta en el momento de la implementacion

Requerimientos minimos de hardware para montar un servidor.

• Inicialmente para montar un servidor usamos un array de discos en raid 1, para lo que necesitamos dos discos de igual tamaño preferentemente.

• Las caracteristicas del CPU y la RAM serán consideradas en función de la carga de trabajo, los equipos actuales de media gama cumplen con los requisitos mínimos: CPU +2000 Mhz RAM +2Gb

Nombres de hosts que deben resolver despues de la instalacion.

• autoserver (para el instalador, por ahora usamos autoserver.redcta.org.ar)

• puppet (para los clientes puppet)

• debproxy-ubuntu (para el proxy de paquetes en local)

• ldap (para los clientes ldap)

• Debemos asegurarnos de que el nombre del servidor (hostname) es el mismo que el quedara finalmente. Tenemos una receta en puppet para tal fin. ​https://trac.redcta.org.ar/redcta/browser/trunk/puppet/modules/puppet-network Cómo se asigna este valor varia, segun el entorno*.

Un ejemplo de nodo

Los nodos y sus caracteristicas, es decir, lo que puppet hace con ellos, se definen en el servidor puppet.

Creamos un archivo de nodo en en el servidor puppet.

#touch /etc/puppet/nodes/ejemplo.pp

Lo editamos con el siguiente contenido:

##Definimos el nombre del nodo
node ejemplo {
###
# Agregamos el modulo constructor del menu para booteo por pxe. 
# screenshot del cliente netboot: https://trac.redcta.org.ar/redcta/attachment/wiki/ServidorRedLocalMultiServiciosCapturasDePantalla/netboot-menu-pxe.png
#
#	The objective is the facilitate the download of debian-installer
#	and build a menu for the pxe clients.
#	
#	To use this module, you need to have a tftpd server running and
#	configure your dhcp server correctly.
#	
# source: https://trac.redcta.org.ar/redcta/browser/trunk/puppet/modules/di_netboot_assistant
           include di_netboot_assistant
### Aca usamos la clase debproxy::activateclient, definimos que el nodo sera cliente del proxy de paquetes, le asignamos a la variable "debproxyhost" el valor "debproxy-ubuntu"        
          debproxy::activateclient { dist:
              debproxyhost => "debproxy-ubuntu",
         }
### Incluimos la clase debproxy::server que se encarga de instalar apt-cacher y verificar la configuracion del paquete.
# source: https://trac.redcta.org.ar/redcta/browser/trunk/puppet/manifests/classes/debproxy.pp
         include debproxy::server
### Usamos el modulo dnsmasq y le pasamos los valores adecuados segun la red en la que estemos trabajando.
# source:  https://trac.redcta.org.ar/redcta/browser/trunk/puppet/modules/puppet-dnsmasq
	     dnsmasq::config { 'oficina':
             dhcp_authoritative => 'yes',
             dhcp_range         => '10.0.12.150,10.0.12.200,255.255.0.0,2h',
             dhcp_gw            => '10.0.12.1',
             dhcp_nameservers   => '10.0.12.1',
             dhcp_script        => '/usr/local/sbin/dnsmasq-genhostname.sh',
             dhcp_hostsfile     => '/etc/dnsmasq.hostsfile',

             addn_hosts         => '/etc/hosts.dnsmasq',
             domain             => 'ejemplo.org.ar',
             dhcp_boot          => '/pxelinux.0,ejemplo,10.0.12.2',
             tftp_root          => '/',
             log_queries        => 'yes',
             log_dhcp           => 'yes'
         }
# Aca estamos usando el modulo network, nuevamente le asigamos los valores a definir en el nodo.    
         network::interface { "eth0" :
             address => "10.0.12.2",
             broadcast => "10.0.12.255",
             netmask => "255.255.0.0",
             parameters => "gateway 10.0.12.1\n        dns-search ejemplo.org.ar\n        dns-nameservers 10.0.12.1",
         }
# Incluimos las modificacines de los archivos para usar el proxy de paquetes.
         include ubuntu_sources_list
# Le decimos a puppet que añada a archivo /etc/apt/sources.list los repositorios para poder instalar virtualbox con apt-get..desde puppet.
         include ubuntu_sources_list::virtualbox

     }

Algunos comandos que utilizamos para las pruebas

Cuando tocamos el archivo de nodo, modificando su contenido, podemos probar si el cliente toma los cambios. Para eso ejecutamos en el cliente:

puppet -d -t 

Lo que nos permiter ver el debug y verificar si los cambios se efectuan o ver los errores para corregirlos.

Para reiniciar el servicio:

/etc/init.d/puppetmaster/ restart

o para recargar la configuracion hacemos:

/etc/init.d/puppetmaster/ reload

Como definimos:

• ltsp en server y cliente
• ldap, nfs
• cups
• otros