Mostrando entradas con la etiqueta ies. Mostrar todas las entradas
Mostrando entradas con la etiqueta ies. Mostrar todas las entradas

martes, 20 de octubre de 2015

¿Por qué no me gusta la solución inalámbrica que se ha decidido implantar en los centros?

0 comentarios
Por lo que nos comentaron en junio, el servicio TIC había instalado en un centro un aula de pruebas con un router wifi D-Link DIR-860L para dar servicio inalámbrico a 40 portátiles y posteriormente lo extendieron al resto del centro montando un total de 22 puntos de acceso, uno por aula.

El montaje consiste más o menos en lo siguiente: En cada aula habrá un router wifi conectado al equipo del profesor mediante cable. El equipo de profesor actuará como servidor dhcp y por defecto, la wifi del aula se encontrará desactivada.  Para que los usuarios puedan conectarse a la wifi del aula, el profesor deberá generar una contraseña y activar la wifi. Y cuando el profesor cierre la sesión gráfica, se desconectará automáticamente la wifi del punto de acceso.

La idea es extender este modelo a todos los centros educativos.

En principio me parece una solución de aficionados que está bien para montar en casa o para un grupo de usuarios, pero creo que no es óptima para dar cobertura a un centro con muchos usuarios y donde se pretende implantar el sistema BYOD (Bring Your Own Device) sin que se produzcan problemas y el sistema ideado termine fallando, como ya ha sucedido en otras ocasiones.

He tratado de explicar por qué no me convence este sistema y los problemas que le veo, además de contarles la solución que actualmente tengo implantada en mi centro, pero creo que no acaban de entenderla (quizás porque sea demasiado técnica...) y no me responden a las dudas que me surgen sobre el funcionamiento del sistema, probablemente porque ni tan siquiera se lo hayan planteado.
Para empezar creo que no es necesario instalar un router wifi por aula y, es más, creo que eso va a dar problemas porque se solaparán los canales al disponer de tantos puntos de acceso cercanos y no poder garantizar cuándo se encenderá cada uno de ellos. Lo ideal es que se mida y se realice tan sólo la instalación de los puntos de acceso necesarios en ubicaciones concretas y probablemente  con la mitad sea más que suficiente, aunque como ya digo, eso requiere un estudio porque cada edificio es diferente.

Por otra parte, el plantear un modelo basado en un punto de acceso por aula conectado al ordenador del profesor implica una dificultad para administrar los dispositivos y diagnosticar problemas al encontrarse dentro de la clase y mayor probabilidad de que fallen por encontrarse al alcance de la mano.

En lugar de los routers wifi D-Link que nos proponen, personalmente creo que es más conveniente utilizar puntos de acceso Unifi de Ubiquiti:
  • Con tan sólo instalar un controlador Unifi en una de las máquinas del centro, es posible gestionar todos los puntos de acceso desde un único lugar, algo que simplifica enormemente la gestión de los puntos de acceso.
  • Por otra parte, con Ubiquiti se dispone de un control más directo de los dispositivos conectados desde una interfaz web, pudiendo controlar el consumo de ancho de banda por dispositivo. 
  • Además, con el modelo que nos plantean, es necesario disponer de una toma de corriente para enchufar los router wifi D-Link. En cambio los puntos de acceso Unifi de Ubiquiti disponen de alimentación Poe, que alimenta los dispositivos mediante el mismo cable ethernet, lo que no requiere una toma de corriente adicional.
Me parece también un inconveniente que tenga que haber un control software para que el profesor genere una contraseña, active el punto de acceso y luego tenga que proporcionársela a los alumnos para que puedan contectarse a la red.

Otro de los inconveientes que le veo es que este modelo obliga a plantear otras soluciones a parte para otras dependencias del centro como la sala de profesores, el salón de actos, los departamentos, etc... cuando es mucho más sencillo y práctico disponer de un único modelo. Y si el modelo deja fuera a estas otras dependencias, ¿no se propone un modelo para ellas? Sí es así y se van a suministrar equipos a profesores, ¿dónde se van a conectar a la red? ¿sólo dentro del aula? ¿no se está haciendo un trabajo a medias?

Si la idea es lograr el uso más eficaz posible de un recurso limitado como el ancho de banda, como nos han dicho:
  • El modelo que se ha decidido poner en marcha, ¿va a funcionar cuando se implante BYOD y los alumnos traigan sus equipos con sistemas operativos que puedan tener virus? ¿permite realizar un filtrado?
  • ¿El modelo propuesto incorpora alguna forma de control de consumo de ancho de banda? Nos han dicho que las pruebas se han realizado con equipos Debian. ¿Qué va a suceder cuando los usuarios traigan equipos Windows y tengan activado Windows Update?
¿Garantizar la seguridad consiste solamente en que los puntos de acceso solamente sean visibles durante el tiempo de uso?

¿Por qué dicen que este modelo garantiza mejor la conectividad? Si ni siquiera se estudia dónde es necesario colocar un punto de acceso. La conectividad puede lograrse colocando sólo los puntos de acceso necesarios en las ubicaciones adecuadas.
¿Por qué piensan que este modelo es más fácil de mantener? ¿En qué sentido? Como he explicado, con Unifi es posible gestionar todos los puntos de acceso desde un único lugar mediante una interfaz web, cosa que con el modelo propuesto no es así. 

¿Por qué piensan que otras soluciones se basan en añadir mac de equipos nuevos? Mediante un firewall como PfSense y puntos de acceso Unifi se pueden hacer muchas cosas y sobre todo, realizar una instalación más profesional.

Sinceramente, me da la impresión de que ésto es otro nuevo invento, que, esperemos me equivoque, no va a funcionar o al menos no como debería si se hiciera bien.
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 25 de mayo de 2015

Control de acceso wifi en el IES utilizando PfSense

0 comentarios
Aprovechando que algún compañero de otro centro me ha vuelto a preguntar qué control de acceso inalámbrico tengo implantado en mi centro, y que muchos otros compañeros me siguen, voy a explicarlo aquí para que a todo el mundo le sirva de orientación: 
 
Para controlar el acceso inalámbrico a la Intranet del centro sigo utilizando freeradius directamente. Esto quiere decir que para poder conectarse en esta red, habrá que configurar un acceso WPA2 Enterprise con EAP/TTLS + PAP en lo clientes. En el blog hay un post de febrero de 2012 con un documento en el que explicaba cómo instalar y configurar freeradius para lograrlo.

Ahora bien, como en un futuro se pretende implantar el sistema BYOD (Bring Your Own Device), que en castellano quiere decir "Trae tu propio dispositivo", y aún no nos han contando cómo se va a implantar, decidí adelantarme y montar mi propio sistema de control de acceso, en lugar de esperar a que se implante en algún momento, pero, sobre todo, motivado por dos razones:
  • Porque en el centro ya me habían pedido poder conectar dispositivos personales ajenos al mismo vía wifi, algo que no podía realizar por disponer del tiempo suficiente para llevar a cabo un proyecto como éste que requiere bastante trabajo y pruebas.
  • Y porque en estos momentos cuento con la ayuda de dos alumnas en prácticas, Raquel y Jennifer, que me están ayudando muchísimo a ponerlo en marcha y probarlo.
La idea se basa en utilizar PfSense, un firewall basado en FreeBSD, para crear un portal cautivo que permita a los usuarios acceder a una red privada que les proporcione un acceso a internet.


De este modo, los usuarios se podrán conectar a la red mediante diferentes puntos de acceso abiertos y tendrán que iniciar sesión para poder navegar, como puede verse en la siguiente imagen:


Se podrá acceder de dos modos:
  • Mediante el usuario y la contraseña con que está dado de alta en el servidor ldap del centro.
  • Mediante un ticket que se podrá generar para dar un acceso limitado en tiempo a usuarios ajenos al centro.
El servidor pfSense tendrá dos interfaces:
  • Una interfaz LAN para dar servicio a clientes inalámbricos en la red 192.168.0.0
  • Una interfaz WAN que servirá para dar acceso a internet a los equipos que se conecten a través de la LAN.


El servidor pfSense, al que hemos llamado firewall, contactará con el servidor freeradius para autorizar a los usuarios que intenten conectar vía wifi. A su vez, el servidor freeradius contactará con el servidor ldap del centro para validar dichos usuarios. Ésto quiere decir que dispondremos de un sistema de control de acceso freeradius+pfsense combinado, pudiendo establecer reglas de control en freeradius y en pfsense.

Por ejemplo, podríamos hacer que los usuarios de un determinado grupo tuvieran acceso durante el horario de mañana y los de otro grupo durante el horario de tarde mediante controles en freeradius y limitar el tiempo que pueden estar conectados mediante el portal cautivo de pfsense.

El firewall pfSense tiene configurado un servidor DHCP que proporciona IP's a los clientes conectados en la LAN 192.168.0.0

Y os preguntaréis: ¿Cómo hago para que los puntos de acceso presten servicio en la red 192.168.0.0 si en el centro tan sólo tengo una red 172.x.x.x? Muy sencillo: Aprovechando que los switches disponen de soporte de VLAN, crearemos una VLAN a través de los switches de nuestro centro a la que se encontrará conectado el firewall en la interfaz LAN.
 Ésto es algo que requerirá un cierto trabajo por vuestra parte, puesto que probablemente no tendréis un mapa de red de vuestro centro en el que se identifiquen al menos los puertos que interconectan los switches, pero tampoco es difícil de identificar si examináis las tablas de enrutamiento de vuestros switches y disponéis de un tester de red. En mi caso hice un mapa de red cuando estuve configurando la telefonía IP con nuestro compañero Javi, de telecomunicaciones.

Por otra parte, he aprovechado que la mayoría de los puntos de acceso de que dispongo tienen soporte de VLAN para hacer que un mismo punto de acceso preste servicio en la VLAN por defecto del centro, por un lado y en la VLAN para dispositivos ajenos por el otro.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 23 de octubre de 2014

Script para borrar las credenciales de usuario cacheadas en portátiles

0 comentarios
Para hacer algo más de limpieza desde el script /root/S99primer-arranque, es interesante borrar las credenciales de usuarios cacheadas en portátiles.

Para realizar dicha limpieza, tengo un script /usr/local/sbin/removecachedcredentials al que llamo desde el script S99primer-arranque.  De este modo, puedo limpiar también las credenciales en cualquier momento, no sólo en el inicio:
#!/bin/bash

# Instalamos libpam-ccreds si no estaba instalado
dpkg -l | grep ^"ii libpam-ccreds" > /dev/null || apt-get -y install libpam-ccreds

for usuario in `cc_dump |awk '{print $3}' | sed '1,2d'`; do
cc_test -update any $usuario -
done

Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 26 de septiembre de 2014

Configurar el servidor nfs del centro para poder establecer quotas de disco

0 comentarios
Aprovechando que tuve que cambiar el viejo servidor NFS del centro por el Primergy TX100 S3 que me enviaron, pensé que, ya que tenía una máquina de 64 bits, lo ideal sería montarle una Debian de 64 bits, en lugar de clonarlo con la imagen de 32 bits del antiguo servidor.

Al hacer una nueva instalación, tenía que configurarlo para poder establecer quotas de disco para los usuarios. Así que he aprovechado que mi amigo Chema me ha preguntado acerca del tema para hacer una pequeña chuleta que le sirva a otros compañeros:

Lo primero que tenemos que hacer es  instalar los paquetes quota y quotatool:
# apt-get install quota quotatool

A continuación instalamos el paquete que añade el script setgroupquota para establecer quotas por grupos:
# dpkg -i setgroupquota_0.2_all.deb

Editamos el archivo /etc/fstab del servidor y modificamos la línea que monta la partición home para que admita quotas de disco:
/dev/mapper/servidor-home   /home   ext4    defaults    0    2
De tal manera que quede así:
/dev/mapper/servidor-home   /home   ext4    defaults,usrquota,grpquota    0    2
Una vez modificado el /etc/fstab, "re-montamos" la partición home para no tener que reiniciar:
# mount -o remount /home
A continuación, ejecutamos el comando quotacheck para que se creen los ficheros de quotas:
# quotacheck -ugm /home 
Por último, activamos las quotas de disco:
# quotaon -ugv /home
Y listo. A partir de ahora ya podéis usar los scripts para asignar quotas de disco como el setgroupquota.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 15 de mayo de 2014

Configurar el servidor nfs del centro como puerta de enlace + squid

0 comentarios
En un post anterior os mostraba cómo he configurando los dos servidores de mi centro para tener una alta disponibilidad de servicios. Además, he instalado Monit en todos los servidores para monitorizar servicios y las temperaturas de la placa base, cpu y disco duro de cada uno de ellos. 

Pues bien, el otro día, monitorizando el servidor ldap he observado que los dos discos duros instalados en él tienen una temperatura demasiado alta (uno de ellos está cerca de los 45ºC), sobre todo si los comparamos con las temperaturas de los discos duros de los servidores LTSP (en torno a los 30-35ºC). Creo que el servidor de ldap tiene un problema fundamental y es que la caja es demasiado pequeña y no ventila bien. Además los ventiladores también son pequeños y los discos duros están justo uno encima del otro, por lo que se dan calorcito mutuamente.

Como tengo un ordenador que me trajo un compañero con una caja tipo torre más grande con varios ventiladores de 80x80mm, pensé: Voy a intercambiar  las cajas entre ambos ordenadores para reducir la temperatura de los componentes: Discos duros, placa base y procesador. Pero hay un problema. ¿Cuándo lo hago sin detener los servicios? Si el servidor ldap está funcionando siempre y además es la puerta de enlace... Así que revisé mi esquema y pensé: Si configuro el servidor nfs como puerta de enlace y le monto squid, tan sólo tengo que modificar un objeto en la configuración de dhcp de la base de datos ldap  para que se asigne como puerta de enlace  el servidor nfs. De este modo, podré parar el servidor ldap sin dejar de dar servicio. Así que me puse manos a la obra y ésta es la configuración que tengo actualmente:
Faltaría repasarlo detenidamente y hacer la prueba. ¿Cuándo? Ya veremos.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 10 de abril de 2014

Controlar el acceso a páginas https desde Squid

0 comentarios
Ya os conté cómo es posible filtrar por usuario y/o por grupos en un post anteriorhttp://enavas.blogspot.com.es/2013/11/filtrar-por-usuario-mediante-squid-ldap.html, utilizando squid en modo no transparente, algo que os recomiendo porque, aunque es cierto que puede darnos un poco más de trabajo a la hora de implementarlo, debido a que requiere configurar el uso explícito del proxy en el navegador, nos va a aportar un mayor nivel de control sobre las reglas de filtrado.

En este post os voy a explicar cómo controlar el acceso a páginas https como facebook, twitter, etc.. vía https y para corroborar lo que os digo, os mostraré cómo podemos hacer un control selectivo dependiendo del grupo al que pertenezca un usuario, basándome en la configuración realizada en el post mencionado anteriormente.

Supongamos que tengo configurado mi servidor con un filtrado selectivo mediante squid y ldap y en el fichero de configuración /etc/squid/squid.conf tengo dos ACL:
# ACL para establecer reglas de filtrado para el grupo teachers
acl profesores external group_auth teachers

# ACL para establecer reglas de filtrado para el grupo students
acl alumnos external group_auth students

Supongamos que quiero controlar el acceso vía https a páginas como facebook, twitter y youtube. Para ello podría crear una acl por cada dominio:
# ACL para gestionar facebook
acl facebook dstdomain .facebook.com

# ACL para gestionar twitter
acl twitter dstdomain .twitter.com

# ACL para gestionar youtube
acl youtube dstdomain .youtube.com

Y crear reglas de filtrado para permitir el acceso del grupo profesores a estos tres dominios y denegárselo al grupo alumnos:
# Permitir facebook a profesores y denegárselo a alumnos
http_access allow CONNECT facebook profesores
http_access deny CONNECT facebook alumnos

# Permitir twitter a profesores y denegárselo a alumnos
http_access allow CONNECT twitter profesores
http_access deny CONNECT twitter alumnos

# Denegar youtube a profesores y denegárselo a alumnos
http_access allow CONNECT youtube profesores
http_access deny CONNECT youtube alumnos

Una vez añadidas las reglas al fichero de configuración, haríamos que squid lo re-lea:

# service squid reload

Así de fácil. Ahora bien, en lugar de crear una acl y una regla de filtrado para cada web con acceso https que necesite filtrar, podríamos almacenar los dominios a restringir en un fichero y cambiar las reglas de filtrado anteriores por las siguientes:

# Lista de dominios https restringidos
acl deny_https url_regex "/etc/squid/acl/deny_https"

# Controlar el acceso a webs https específicas
http_access allow CONNECT deny_https profesores
http_access deny CONNECT deny_https alumnos

De este modo, cuando queramos filtrar el acceso a una nueva web vía https, tan sólo tendremos que añadir el dominio al archivo /etc/squid/acl/deny_https.

Publicado por primera vez en http://enavas.blogspot.com.es

martes, 8 de abril de 2014

LTSP: Configurar DNS para los thinclients

0 comentarios
Si queremos, podemos configurar las DNS de los thinclients LTSP modificando el fichero /opt/ltsp/i386/etc/resolv.conf a mano. Aunque también podemos utilizar otro método: Definirlos en el fichero de configuración /opt/ltsp/i386/etc/lts.conf, algo sencillo de hacer porque sólo hay que configurar dos parámetros:
  • DNS_SERVER: Nos permite indicar los servidores DNS.
  • SEARCH_DOMAIN: Nos permite indicar el dominio de búsqueda.

Por ejemplo: Si en mi centro tengo dos servidores de DNS: 172.19.144.2 y 172.19.144.3, mi dominio es valledeljerte3 y quiero configurar los DNS para los thinclients utilizando este método, añadiré los dos parámetros al fichero de configuración /opt/ltsp/i386/etc/lts.conf:

DNS_SERVER="172.19.144.3 172.19.144.2"
SEARCH_DOMAIN="valledeljerte3"

Una vez hecho ésto, como en nuestro sistema utilizamos NBD, tendremos que volver a regenerar la imagen de los terminales.

Publicado por primera vez en http://enavas.blogspot.com.es

Alta disponibilidad con ldap+réplica ldap+dhcp failover+dns duplicado

0 comentarios
En el siguiente post: http://enavas.blogspot.com.es/2014/04/alta-disponibilidad-con-ldapreplica.html, os mostré los cambios que he realizado en los servidores y clientes de mi centro para tener una mayor disponibilidad de servicios y que el sistema no deje de funcionar por la caída de alguno de ellos. Con estos cambios conseguí:
  • Disponer de dos servidores de autenticación activos usando ldap y una réplica de ldap.
  • Disponer de un dhcp failover que proporcione direcciones IP a los clientes mediante dos servidores.
El siguiente cambio que me propuse fue replicar también el servicio DNS, de manera que ahora tengo dos servidores DNS: Uno en el servidor "ldap" y otro en el servidor nfs "servidor".



Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 28 de marzo de 2014

Módulo puppet para configurar nfs en clientes

0 comentarios
He subido a mi GitHub un módulo (puppet-nfsv4) para gestionar el servicio nfs. Pensaba haber añadido la gestión de servidor nfs, pero, como no lo necesito, en principio, tan sólo administra el servicio cliente de nfs.

Su función es garantizar que el paquete nfs-common se encuentra instalado y el servicio está corriendo. Además configura idmap para mapear id's de usuario y grupos, lo que mejora notablemente el montaje de unidades nfs. 

Este módulo podría implementarse de una forma más sencilla. Lo implementé de una forma más compleja para que fuera funcional y, al mismo tiempo, poder utilizarlo con fines formativos en un nuevo curso de puppet avanzado o de ampliación que propusiéramos para ampliar los conocimientos para aquellos compañeros que pudieron realizar el de "Sistema de automatización de tareas Puppet" y que he tenido el placer de impartir en la Escuela de Adminstración Pública durante dos años, pero viendo que la EAP no ha tenido a bien mantener el curso anterior ni ninguno de los cursos a los que los administradores informáticos podíamos optar, está claro que no merece la pena hacer ninguna nueva propuesta.

Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 26 de febrero de 2014

Definir un alias para una máquina en el servidor ldap

0 comentarios
Como suelo utilizarlo poco, se me suele olvidar en qué rama del servidor ldap se puede definir un alias para un nombre de máquina. Así que voy a ponerlo aquí y de paso le sirve a aquellos compañeros que no lo sabían y me lo han preguntado.

Si queréis añadir un alias para una máquina debéis hacerlo en la siguiente rama:

dc=NOMBREDOMINIO,ou=hosts,dc=instituto,dc=extremadura,dc=es

Lógicamente, deberéis sustituir: NOMBREDOMINIO por vuestro dominio concreto. Ejemplo:

dc=valledeljerte3,ou=hosts,dc=instituto,dc=extremadura,dc=es

Publicado por primera vez en http://enavas.blogspot.com.es

martes, 11 de febrero de 2014

Paquetes de firefox 27.0 para instalar en las máquinas de los IES

0 comentarios
Aquí tenéis los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 27.0 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.

Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 7 de febrero de 2014

Script para crear mirror de Debian Wheezy y Squeeze en los IES

0 comentarios
Aprovechando que voy a testear la imagen de Debian Wheezy que nuestros compañeros de la Sección de Administración de Sistemas han preparado, he pensado que me sería de gran utilidad tener ya un mirror interno de Debian Wheezy en el centro. Y como el script que crea el mirror  en el servidor ldap (mkdebmirror-lenny-squeeze.select) necesitaba unos retoques, he decidido matar dos pájaros de un tiro.

Como el script anterior ya no crea el mirror de Lenny y no quería quitarlo mientras hacía pruebas, lo he llamado mkdebmirror-squeeze-wheezy.select. Por si alguien quiere probarlo en su centro, aquí lo tenéis:

Éstas son las modificaciones que he realizado:

  • Para ahorrar espacio y consumo de ancho de banda innecesario, he excluido del mirror los paquetes dbg. Son paquetes de depuración que habitualmente no usamos para nada.
  • Después de hacer algunos testeos, he modificado la lista de mirrors y he bajado el tiempo de chequeo por mirror a 10 segundos.
  • He añadido algunas líneas que crean los directorios de destino de los mirrors tan sólo si no existen, para evitar mensajes de que no se puede crear los directorios porque ya están creados.
  • Como los ficheros de project/trace requieren descargarse por rsync y esto no funciona, he modificado el script para que se bajen mediante wget vía ftp.

Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 20 de diciembre de 2013

Configurar Link Aggregation en switch TP-LINK TL SG3210

0 comentarios
Si queréis hacer bonding en vuestro servidor nfs, no es suficiente con realizar la configuración en el servidor. También tenéis que configurar los puertos del switch al que están conectadas las tarjetas de red para formar una agrupación de puertos (Link Aggregation) para que el switch sepa cómo debe actuar con esos puertos. Evidentemente, para hacer ésto, debéis tener un switch gestionable.

A continuación os muestro cómo configurar la agrupación de puertos en el switch TP-LINK TL SG3210:


Es muy sencillo. Basicamente se trata de dar un nombre al grupo de puertos, marcar los puertos que pertenecen a dicho grupo y guardar la configuración.

Ojo, como podéis ver en la imagen anterior, no es recomendable mezclar puertos de 100Mb y 1000Mb en una agrupación de puertos.


Como podéis deducir de la imagen, mi servidor tiene dos tarjetas de red conectadas a los puertos 2 y 3 del swich funcionando con bonding.

Publicado por primera vez en http://enavas.blogspot.com.es

martes, 17 de diciembre de 2013

Borrar copias de seguridad antiguas

0 comentarios
Para hacer copias de seguridad uso rsync (http://enavas.blogspot.com.es/2008/01/copias-de-seguridad-incrementales-con.html). Es cómodo, sencillo y me facilita las búsquedas a la hora de recuperar archivos.

Con este sistema de copias de seguridad, por cada máquina de la que hacemos copia, se guarda:
  • Un directorio main con las copias actualizadas del sistema.
  • Y un directorio nombrado mediante fecha con las modificaciones por cada día en que hubo cambios.
Para borrar copias de seguridad antiguas, podemos usar el comando find desde un script lanzado desde cron. Como es más fácil verlo con un ejemplo, os muestro mi script de borrado de copias de seguridad:

#!/bin/bash

# Primero borra copias de mas de 60 días del servidor nfs
find /var/ies_backups/servidor/ -maxdepth 1 -mtime +60 -not -iname main -exec rm -rf {} +;
# Para ver las copias que se van a eliminar: find /var/ies_backup/servidor/ -maxdepth 1 -mtime +60 -not -iname main -exec echo {} +;

# Luego borra copias de mas de 60 días del servidor ldap
find /var/ies_backups/ldap/ -maxdepth 1 -mtime +60 -not -iname main -exec rm -rf {} +;
# Para ver las copias que se van a eliminar: find /var/ies_backup/ldap/ -maxdepth 1 -mtime +60 -not -iname main -exec echo {} +;

# Luego borra copias de mas de 60 días del servidor recursos
find /var/ies_backups/recursos/ -maxdepth 1 -mtime +60 -not -iname main -exec rm -rf {} +;
# Para ver las copias que se van a eliminar: find /var/ies_backup/recursos/ -maxdepth 1 -mtime +60 -not -iname main -exec echo {} +;

# Luego borra copias de mas de 60 días del servidor freeradius
find /var/ies_backups/a22-pro/ -maxdepth 1 -mtime +60 -not -iname main -exec rm -rf {} +;

# Para ver las copias que se van a eliminar: find /var/ies_backups/a22-pro/ -maxdepth 1 -mtime +60 -not -iname main -exec echo {} +;

Analicemos uno de los comandos de borrado paso a paso:

# find /var/ies_backups/servidor/ -maxdepth 1 -mtime +60 -not -iname main -exec rm -rf {} +;

En este ejemplo estamos buscando con una profundidad de subdirectorio de 1 (-maxdepth 1), aquellos archivos/directorios que tengan más de 60 días de antiguedad (-mtime +60), excluyendo el archivo/directorio main (-not -iname main) y los borramos (-exec rm -rf {})

Fijaos lo útil que pueden ser los parámetros -iname y -not.
  • Con -iname "patrón" puedo indicar un patrón de búsqueda. Por ejemplo, si indico como patrón -iname 2013-11*, buscaré los archivos que tengan como nombre 2013-11 seguido de cualquier cadena de caracteres, lo que, en este caso, se traducirá en encontrar los directorios de copias de seguridad de noviembre de 2013.
  • Con -not simplemente voy a indicar una negación para que la búsqueda me devuelva lo contrario del patrón indicado en -iname.
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 16 de diciembre de 2013

Paquetes de firefox 26.0 para instalar en las máquinas de los IES

0 comentarios
Aquí tenéis los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 26.0 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.

Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 16 de noviembre de 2013

Filtrar por usuario mediante squid + ldap

0 comentarios
Lo más habitual es que utilicemos Squid en modo transparente para filtrar tráfico en nuestra organización y  supongo que se debe a que es la opción que menos trabajo da porque no nos obliga a configurar cada navegador de cada equipo para usar nuestro proxy. No obstante, en ocasiones puede ser muy interesante filtrar en modo no transparente o, si no tenemos posibilidad de cambiarlo todo, usar ambos mecanismos.

Así que, si pensáis en que queréis o necesitáis filtrar por usuario, es imprescindible que éste acceda a internet en modo no transparente. De otro modo, el filtrado por usuario no va a funcionar. ¿Y qué implica ésto? Que el usuario deberá introducir su login y su password cada vez que abra el navegador. Y os dirán que es muy incómodo tener que teclearlo una y otra vez. Bueno, pues les decís que dejen que el navegador guarde los datos de acceso.

Autenticación externa.- 
Para lograr que squid filtre por usuario vamos a utilizar un programa de autenticación externo. Si queréis, podéis escribir vuestro propio programa/script de autenticación externo, pero no os preocupéis porque squid ya nos proporciona unos cuantos.

En Debian, encontraréis los programas de autenticación externos que squid nos proporciona en el directorio /usr/lib/squid/. Como nuestra autenticación está basada en ldap, de todos los programas que hay, usaremos dos:
  • ldap_auth: Para validar usuarios.
  • squid_ldap_group: Para validar grupos.

Validación de usuarios.-
Antes de configurar squid, lo mejor que podemos hacer es utilizar el programa de autenticación externa desde un terminal para comprobar que funcionan las consultas que el programa va a realizar al servidor ldap. Veamos cómo:

Suponiendo que el nombre de nuestro servidor es "ldap", la base del árbol ldap donde se encuentran los usuarios es "ou=People,dc=instituto,dc=extremadura,dc=es" y utilizamos la versión 3 del protocolo LDAP, abrimos un terminal y ejecutamos el programa:


# /usr/lib/squid/ldap_auth -h ldap -b "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3


Al ejecutarlo, el programa quedará esperando a que introduzcamos un usuario y su contraseña, separados por un espacio en blanco.

Si introducimos un usuario y un password válidos en ldap, nos devolverá OK:

root@ldap:~# /usr/lib/squid/ldap_auth -h ldap -b "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3

profesor claveprofesor

OK

Si introducimos un usuario que no existe o el password introducido no es válido en ldap, nos devolverá ERR Success:

root@ldap:~# /usr/lib/squid/ldap_auth -h ldap -b "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3

profesor claveerronea

ERR Success

Cuando terminemos de hacer comprobaciones, pulsamos Ctrl+C y saldremos del programa.

Validación de grupos.-
Además de establecer un control por usuario, puede que nos interese realizar también un control por grupos,  para establecer reglas en squid que controlen el acceso a los contenidos en función del grupo al que pertenece el usuario.
Al igual que en el caso anterior, lo mejor que podemos hacer es utilizar el programa de autenticación externa desde un terminal para comprobar que funcionan las consultas que el programa va a realizar al servidor ldap. Veamos cómo:

Suponiendo que el nombre de nuestro servidor es "ldap", la base del árbol ldap donde se encuentran los grupos es "ou=Group,dc=instituto,dc=extremadura,dc=es" y utilizamos la versión 3 del protocolo LDAP, abrimos un terminal y ejecutamos el programa:


# /usr/lib/squid/squid_ldap_group -h ldap -b "ou=Group,dc=instituto,dc=extremadura,dc=es" -f "(&(objectClass=posixGroup)(cn=%a)(memberuid=%v))" -B "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3 -s sub


Como podéis ver, con el parámetro -f, indicamos el filtro para comprobar que un usuario es miembro de un grupo. Al ejecutarlo, el programa quedará esperando a que introduzcamos un usuario y un grupo, separados por un espacio en blanco.

Si introducimos un usuario y un grupo al que pertenece el usuario, nos devolverá OK:

# /usr/lib/squid/squid_ldap_group -h ldap -b "ou=Group,dc=instituto,dc=extremadura,dc=es" -f "(&(objectClass=posixGroup)(cn=%a)(memberuid=%v))" -B "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3 -s sub

ponente teachers
OK

Si introducimos un usuario que no existe o existe pero no pertenece al grupo introducido, nos devolverá ERR:

# /usr/lib/squid/squid_ldap_group -h ldap -b "ou=Group,dc=instituto,dc=extremadura,dc=es" -f "(&(objectClass=posixGroup)(cn=%a)(memberuid=%v))" -B "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3 -s sub

ponente students

ERR

Cuando terminemos de hacer comprobaciones, pulsamos Ctrl+C y saldremos del programa.

Configurar squid para autenticar usuarios.-
Bien, pues una vez que hemos visto cuáles son los programas de autenticación de usuarios y grupos mediante ldap que squid nos proporciona, ahora vamos a ver cómo configurar squid para autenticar usuarios.

Lo primero que haremos será editar el fichero /etc/squid/squid.conf:

# nano /etc/squid/squid.conf

Una vez abierto, buscamos el TAG: auth_param. Si no lo tenéis porque habéis quitado los comentarios de este fichero, buscadlo en el archivo squid.conf original, que viene completamente comentado, para saber en qué parte del squid.conf debéis insertar las siguientes líneas y las insertamos al final de la sección TAG: auth_param:

auth_param basic program /usr/lib/squid/ldap_auth -h ldap -b "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3
auth_param basic children 5

Como podéis ver, básicamente estamos definiendo el programa que vamos a usar como autenticador y es el mismo que habíamos comprobado que funcionaba desde la línea de comandos.

A continuación nos vamos a la sección del documento donde se definen las ACL. Para ello buscamos el TAG: acl, nos desplazamos al final de esta sección e insertamos la siguiente línea:

# acl ldapauth proxy_auth REQUIRED

Por último, buscamos el TAG: http_access e insertamos una línea como la siguiente:

# http_access allow ldapauth

Esta vez no insertamos la línea al final de la sección. Tendremos que insertarla en el lugar que corresponda de acuerdo con las otras reglas que tengamos establecidas.

Una vez hecho ésto, reiniciamos squid para aplicar los cambios y listo:

# service squid restart

Configurar squid para restringir algunos usuarios.-
Por otra parte, en la sección donde se definen las ACL podríamos definir una nueva como la siguiente:

# acl usuariosrestringidos proxy_auth "/etc/squid/acl/deny_users"

Y en la sección de reglas definir reglas de filtrado para los usuarios que especifiquemos en el archivo /etc/squid/acl/deny_users

Configurar squid para autenticar grupos.-
Con lo expuesto anteriormente, todos aquellos usuarios registrados en el servidor ldap podrán navegar por internet. Eso sí, al abrir el navegador se les solicitará que introduzcan su usuario y contraseña.

Si ahora queremos ir un paso más allá y permitir o denegar que los usuarios de un cierto grupo naveguen o que lo hagan de forma limitada,  vamos a volver a modificar el fichero squid.conf.

# nano /etc/squid/squid.conf

Una vez abierto el fichero, buscamos la regla:

http_access allow ldapauth

Y la comentamos:

# http_access allow ldapauth

A continuación, buscamos el TAG: external_acl_type y al final de esta sección insertarmos lo siguiente:

external_acl_type group_auth %LOGIN /usr/lib/squid/squid_ldap_group -b "ou=Group,dc=instituto,dc=extremadura,dc=es" -f "(&(objectclass=posixGroup)(cn=%a)(memberuid=%v))" -h ldap -B "ou=People,dc=instituto,dc=extremadura,dc=es" -v 3 -s sub

Esta acl externa a la que hemos llamado group_auth, nos va a permitir lograr que squid compruebe si un usuario es miembro de un grupo.

A continuación nos vamos a la sección del documento donde se definen las ACL. Para ello buscamos el TAG: acl, nos desplazamos al final de esta sección e insertamos las acl que queramos. Por ejemplo, podemos especificar una acl para profesores:

# acl profesores external group_auth teachers

Donde, teachers es uno de los grupos registrados en nuestro servidor ldap.

También podríamos crear una acl para usar en reglas de filtrado para alumnos:

# acl alumnos external group_auth students

Por último, buscamos el TAG: http_access e insertamos reglas de filtrado:

http_access allow profesores

Esta vez no insertamos la línea al final de la sección. Tendremos que insertarla en el lugar que corresponda de acuerdo con las otras reglas que tengamos establecidas y dependiendo de cómo queráis filtrar.

Una vez hecho ésto, reiniciamos squid para aplicar los cambios y listo:

# service squid restart

Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 4 de octubre de 2013

Relacionar alumnos/portátiles en el servidor ldap

0 comentarios
Cada uno realizamos la asignación de alumnos/portátiles de un modo más o menos particular y son igual de válidos, sobre todo porque nos solucionan el problema. Os voy a contar cómo lo hago yo, por si a alguien más le sirve la idea.

Para empezar, asigno un nombre a cada portátil de manera similar a como lo hacemos con los equipos de las aulas de terminales. Por ejemplo: a01-o01 sería el portátil 01 del aula 01, a01-o02 sería el portátil 02 del aula 01, y así sucesivamente.

En el servidor ldap, utilizo un esquema (ldapns.schema) que me permite definir, para cada usuario, los hosts desde los que va a tener acceso. Ahora mismo, no utilizo este esquema para controlar el acceso desde determinados hosts; tan sólo lo uso para asignar un determinado portátil a un alumno concreto.

Para hacer uso del esquema ldapns.schema, hacemos lo siguiente:

Primero.- Copiamos /usr/share/doc/nss_ldap-253/ldapns.schema /etc/ldap/schema/ldapns.schema

# cp /usr/share/doc/nss_ldap-253/ldapns.schema /etc/ldap/schema/ldapns.schema

Segundo.- Editamos el archivo de configuración del servidor ldap:

# nano /etc/ldap/slapd.conf

Y añadimos al fichero el include para usar el esquema:

include         /etc/ldap/schema/ldapns.schema

Tercero.- El siguiente paso será añadir a cada entrada de usuario el objectClass: hostObject y el atributo host con el nombre del portátil

Para realizar este último paso, retoqué el script que uso para añadir el objectClass y los atributos de radius a los usuarios para que, al mismo tiempo, también añadiera el objectClass hostObject y el atributo host.
Por otra parte, creé un script perl (asignaportatiles) al que le indico el nombre del aula y el fichero que contiene la lista de alumnos de ese aula ordenado por apellidos y va asignando de forma correlativa los portátiles por orden de lista.

Y, por último, tomando como modelo el script anterior, creé otro (desasignaportatiles) que desasigna los portátiles a todos los alumnos de un aula, poniéndoles el atributo host = none.

Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 4 de julio de 2013

Paquetes de firefox 22.0 para instalar en las máquinas de los IES

0 comentarios
A continuación dejo dos enlaces para descargar los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 22.0 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.

martes, 18 de junio de 2013

Obtener una lista de los paquetes instalados en nuestro sistema

0 comentarios
Cuando configuramos pkgsync, creamos tres ficheros:

  • musthave: Contiene una lista de los paquetes que debe tener instalado la máquina.  
  • mayhave: Contiene una lista de los paquetes que puede tener instalado la máquina.
  • maynothave: Contiene una lista de de los paquetes que no debe tener instalado. 
Una forma sencilla de obtener la lista de paquetes instalados en un sistema para rellenar el fichero musthave, es hacer uso de dpkg --get-selections:

# dpkg --get-selections | cut -f1 > /etc/pkgsync/musthave

miércoles, 15 de mayo de 2013

Paquetes de firefox 21.0 para instalar en las máquinas de los IES

0 comentarios

A continuación dejo dos enlaces para descargar los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 21.0 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.

wibiya widget