Algo de Linux: 2015

martes, 22 de diciembre de 2015

Supercontrato Tic extremeño e innovación educativa

Parece que los administradores informáticos no somos los únicos descontentos con el Supercontrato Tic extremeño como se refleja en el siguiente post del blog TICtirití: http://iessanjose.blogspot.com.es/2015/12/supercontrato-tic-extremeno-e.html?m=1 
Recomiendo su lectura porque no tiene desperdicio.
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 12 de diciembre de 2015

Script download_pkg_and_deps: Descargar un paquete y todas sus dependencias

El script download_pkg_and_deps permite descargar el paquete que pasemos como parámetro y todas sus dependencias en una carpeta con el nombre del paquete.

Ésto nos servirá para descargar paquetes que luego podremos instalar offline.
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 8 de diciembre de 2015

Extremadura se vende a Microsoft no sólo en Educación, también en Sanidad

Extremadura, una de las regiones pioneras en la implantación de software libre da marcha atrás y se vende a Microsoft no sólo en Educación (http://enavas.blogspot.com.es/2015/12/salvemos-gnulinex-con-windows-llega-el.html), también en Sanidad. 

Por si os queda alguna duda sobre la compra de licencias a Microsoft por parte de Sanidad, no tenéis más que echar un vistazo a la web de contratación pública de la Junta de Extremadura:

Un cambio de rumbo que los profesionales que trabajamos con sofware libre no entendemos, y no entendemos por muchas razones. Algunas de ellas:

Hoy por hoy las aplicaciones que se desarrollan son multiplataforma, lo que nos da la posibilidad de utilizar cualquier sistema operativo.

La mayor parte de las aplicaciones utilizadas en un equipo hoy en día se encuentran en la nube. 

El software libre nos ofrece la posibilidad de realizar cualquier modificación que necesitemos tanto en el sistema operativo como en el software. Ésto es algo imposible de realizar en un sistema operativo cerrado como Microsoft Windows.

El software de Microsoft es malware. En la siguiente página podéis leer por qué se considera dañiño: http://www.gnu.org/proprietary/malware-microsoft.es.html

Cuando se decide comprar un sistema operativo Windows, la administración se está obligando a adquirir nuevas versiones porque Microsoft no te permite seguir con tu sistema indefinidamente. Llega un momento en que decide dejar de darle soporte y  tienes que volver a comprarle nuevas versiones.

Cambiar de versión de Windows, supone ampliar o cambiar también los equipos porque cada vez que Microsoft saca una nueva versión, ésta necesita más recursos. Esto implica que la administración, pasado un tiempo, no sólo tendrá que comprar una nueva versión del sistema operativo, sino que deberá renovar sus equipos para que soporten las necesidades del sistema operativo.

Tener muchas máquinas Windows significa disponer de un software de gestión que Microsoft no regala. Y si no se dispone de un software de gestión, el mantenimiento de los equipos uno a uno resulta imposible. Sin un sofware de gestión,Windows devora el ancho de banda de la red, sobre todo con sus actualizaciones. Lo hemos visto en Educación. En la época de Windows XP, dos aulas de 25 ordenadores consumían el 90% del ancho de banda de internet, cuando 20 aulas de 15 ordenadores LinEx, donde sí teníamos software de gestión, tan sólo consumían el 10%.

Los sistemas operativos libres nos permiten adaptar el sistema operativo al hardware de la máquina, de tal manera que no se necesita renovar el hardware con tanta frecuencia como con sistemas operativos privativos.

Y como decía un compañero, no está mal recordar algún que otro artículo, de alguna que otra ley que se vulnera y que ahora no debe tener importancia:

Estatuto de Autonomía
Ley Orgánica 1/2011, de 28 de enero, de reforma del Estatuto de Autonomía de la Comunidad Autónoma de Extremadura.
http://www.boe.es/boe/dias/2011/01/29/pdfs/BOE-A-2011-1638.pdf
Artículo 7.10:
Los poderes públicos regionales:
[...]
Consideran un objetivo irrenunciable la masiva difusión de la cultura en su sentido más amplio y un acceso igualitario de los extremeños a la información y a los bienes y servicios culturales. Para ello, Extremadura considera instrumentos particularmente útiles el dominio de otras lenguas, el manejo de las tecnologías de la información y la comunicación, la extensión de los sistemas operativos de código abierto y el uso de las licencias de libre copia y distribución.
[...]

Ley 4/2013, de 21 de mayo, de Gobierno Abierto de Extremadura:
http://www.gobex.es/filescms/ig/uploaded_files/interlex_normas/Ley_4_2013_de_21_de_mayo_de_Gobierno_Abierto_de_Extremadura.pdf

Artículo 4, letra o:
"Principio de neutralidad tecnológica: la Administración pública ha de apostar por la utilización  y promoción de software de código abierto en su funcionamiento, así como por el uso de estándares abiertos y neutrales en materia tecnológica e informática, y favorecer dichas soluciones abiertas, compatibles y reutilizables en la contratación administrativa de aplicaciones o desarrollos informáticos."

Agenda Digital, está llena de menciones al uso del software libre, pero por destacar alguna:
http://www.extremaduradigital.org/sites/extremaduradigital.org/files/Agenda_Digital_Extremadura.pdf

-Independencia Tecnológica: el software libre es la única tecnología que te permite ser autónomo tecnológicamente hablando.
5. Uso de Software Libre.
Liberación de aplicaciones y puestas a disposición de ciudadanía, empresas y otras administraciones (reutilización de aplicaciones ya creadas y liberadas por parte de la Administración). Extremadura cuenta con una larga tradición en la implantación de Software de Fuentes Abiertas en su Administración. De hecho, el sistema educativo es referencia internacional en la migración a entornos libres y en el aprovechamiento de los recursos educativos abiertos. Se tomará como referencia el Decreto de Reutilización de Software Público13 recientemente aprobado por el Gobierno Vasco e integrado en la Agenda Digital Europea.

Si Extremadura es una de las regiones más pobres de España, ¿por qué se tira dinero comprando licencias de software privativo cuando trabaja desde hace más de 10 años con software libre y el modelo funciona tanto en Educación como en Sanidad? ¿Alguien puede darnos una explicación razonable?
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 4 de diciembre de 2015

Salvemos gnuLinex, con Windows llega el fin, el caos a las TIC.

No puedo estar más de acuerdo con mi compañero Jaime,  y le he pedido permiso para publicar este documento protesta que refleja el sentir de la mayor parte de los administradores que trabajamos en ésto, y con el que me siento completamente identificado:
 
 No he podido resistir más y escribo estas palabras porque veo que el trabajo, sobre todo el realizado en estos últimos años (CPR), se va al traste, me duele que se diga gnuLinex que es una mierda, reinventar la rueda, ...  no es ponerla con la medida y la presión y del tipo que mejor se adapta a nuestras necesidades. Distribuciones adaptadas a las máquinas, DVD y USB de instalación, NET-install, nfs, ldap, ...

 Ha faltado compromiso y apoyo por parte de la comunidad educativa (esto se va consiguiendo, con esfuerzo y trabajo), que no quería los ordenadores sin entrar en que software traía, eso vino después.

 Los CPR tampoco han sido adalides del SL, más bien todo lo contrario, son las contradicciones del ser humano, los partidarios de lo público (la escuela y demás, "concertado/privado demonio"), defendiendo el software cerrado de una multinacional estadounidense "tuiteándolo" desde su Iphone.

 Es verdad que  a veces están (los SO) muy encorsetados, pero la gente confunde ordenador de trabajo, enseñanza, con ordenador personal, y la verdad que cuando ves alguno de estos últimos da "asco" de como están.

 Para quién no me conozca, o para los que no sepan que labor a parte de los 50 centros a los que intento dar el mejor servicio y son el "leitmotiv" de todo lo siguiente:

 El primer DVD de instalación de Linexcolegios2010 (SysRescueCd + PartImage)  repartido por todos los colegios de Extremadura, que sustituyo al uso de debian installer (lentísimo).
 DVD LinexColegios2011 (SysRescueCd+tar)
 Live de Linex Concertados + Instalador (python) iba con unos netbook que se repartieron por algunos centros concertados
 Instalación remota de servidores (SystemRescue + rsync + tar) totalmente automatizada, cambio de distribución sin presencia detrás del equipo.
 Instalación red de Linex Colegios desde la version 2011 en adelante, centralización en los servidores de los Colegios para instalar por red y siempre lo más reciente, con PXE + tinyCore + split-tar.
 Live LinexColegios y portable (Vbox+iso live) para pendrive.
 ISOS de todas estas versiones autoconstruibles desde la instalación.
 Mint Debian Secretaria,  Mint 16 Secretaria, instalables tanto por red como desde ISO.

 Empaquetado y correcciones de seguridad del software PDI Interwrite.
 Reempaquetado del software PDI iqboard.
 Empaquetado de la galería y las toolkit de la PDI SmartBoard.

 Sistema de resolución de incidencias frecuentes para LinexColegios, donde desde un simple formulario php cualquier persona puede seleccionar de una lista  añadir y subsanar funcionalidades a su ordenador, programas de editoriales, forzar actualizaciones, ... como muestra se han realizado sobre 500 instalaciones del AulaVirtual en toda la región y casi 4500 de todo tipo el menos de año y medio, más de 3000 instalación es por red desde 2013 en todos los colegios de Extremadura.


Extrapolar a guindos lo que hacemos en gnuLinex.
 Actualmente la asistencia/asesoramiento/resolución/diagnosis/instalación de programas se realiza desde cualquier equipo linux contra el ordenador afectado por ssh y por vnc (transparente o no, display del usuario u otro), se le notifica en pantalla si se quiere libnotify/notify-send , ¿esto como se va a hacer con guindos? ¿coste 0? o que quieren que para instalar un programa tengamos que ponerlos delante de la máquina. Y reinstalar 36 Gb comprimido la instalación "básica" del sistema, frente a 4Gb  de gnuLinex (donde sobra la mitad), donde los archivos de instalación están en una partición y al reinstalar solo se descarga lo nuevo.


Lo que nos espera.
 Ahora viene el rodillo, la rueda de la cuadriga con pinchos que destroza todo lo que le rodea, ¿de verdad piensa alguien que pueden coexistir ambos sistemas a la vez?, un sistema dominante que no respeta a su vecino, que a la mínima lo destruye, sistema operativo "terrorista", que aniquila todo lo demás, que no quiere competidores y aprovecha su posición dominante para imponer a los fabricantes de hardware reglas que impidan el uso de SL.


Estos señores lo han conseguido, se avecina el fin del software libre, pero no solo eso, se avecina un caos (troyano,malware,virus, software pirata), la oscuridad se cierne sobre las TIC de los centros educativos, su objetivo lo han cumplido que el software libre desaparezca de la educación, que ya no tengamos el control sobre las máquinas y sus programas, que las reglas las impongan las multinacionales, llámese microsoft, telefónica, HP, ... que haya que pagar por todo, con el dinero de todos.

No lo querían (el SL) y no han demostrado el mínimo rubor. Venían preparándolo, primero la puntita, con los equipos TTL sobremesa / portátiles con win7 y netbook táctiles 10.1" con win 8 (64Gb sdd para linex/win 8.1, no se puede ni actualizar los sistemas porque se queda sin espacio)

Al menos los sistemas instalados de una manera "aceptable" particionado a nuestro gusto, no UEFI+secure boot, no GPT, windows sin activar, pero ya con la pegatina de la muerte y el rum-rum entre la gente. El cambio no fue gratis,  de la hornada anterior de TTL pasamos de monitores de 23" a unos modestos 19"+windows.


Pero lo mejor estaba por llegar, unos fondos Europeos (38M€) que había que gastar antes de final de año. Hacemos una macroencuesta para ver las necesidades de los centros, pero preguntamos a quién nos interesa, no a los profesionales, y de hay nos quedamos con lo que queremos (win-win). Todo esto a espalda de los que llevamos, en mi caso 12 años, repartidos 50%-50% entre institutos y CPR (colegios), que conocemos mejor que nadie la realidad y la mejor alternativa tecnológica de los centros.

¿Donde están los datos de la encuesta en que se basan los pliegos posteriores ?, ¿alguno ha tenido acceso a ella?, en los centros dicen que no les están dando lo que pidieron, eso si se van a "jartar" de imprimir.

¿Quién va a pagar la renovación de las licencias? ¿ Antivirus ?

Algunos esperábamos que está locura se parase con el cambio de gobierno y con la intervención de algunos compañeros, se ha visto a la postre que es irreversible.

Como muestra, de lo que yo he podido ver de momento:

Equipos laboratorio con windows 10 marca HP (hp "gran multinacional que cuida bien a sus empleados") con EUFI+secure boot, GPT, xubuntu (deberás era la opción más atractiva para un equipo i5 con 8/16Gb de RAM) de un día para otro sin ninguna personalización/adaptación, particionado desastroso, para más inri no funciona linux, lo han clonado mal.

Todo el sistema linux en 1 partición+ swap.

Desde hace varios año (4 o 5 creo recordar), trabajamos con 6 o 9 (linex+win) particiones que nos permiten cambiar el sistema operativo y/o  reinstalarlo  sin la intervención del usuario y sin necesidad de dejar de usar el equipo y sin perdida de datos.

No he tenido oportunidad de ver el resto de equipos aún, pero no espero gran cosa, si vienen de serie con win10.

Los equipos de las pdi's cuando los monten en los colegios, creo con menú de arranque, quién impide que usen windows, si además antes el valor añadido que teníamos era que linexcolegios lo tenía todo de serie configurado Jclic, editorales, software de pdi, usuarios a un clic, ....  de eso que yo sepa no hay nada, y no tenemos info sobre que trabajar.

Sin ver los resultados de la encuesta, no se si son públicos, si se que la mayoría el software favorito de PDI era Notebook, ¿ habéis visto el software de las pdi Galneo, Pandectas ?, verde no lo siguiente, además adolece del problema de siempre versión de linux siempre por detrás del resto de sistemas, con lo cual lo de dar a la gente lo que quiere si, si es lo que yo quiero también.

"EscudoWeb", tenemos algún pitoniso por la consejería, se estaba usando antes de resolverse el concurso y adjudicarse, se ve que era el favorito de la casa, hasta aquí en este tema, que cada uno saque conclusiones.

Estos son los mismo que pidieron que los alumnos de centros Scholarium,  trajeran la tablet de casa, que le pagaban los libros digitales, WTF!!!, todo el mundo sabe que las tablet son como la PS4, que solo hay una de un tipo y con un sistema operativo igual para todos, la risa que le tendría que entrar a los profesores cuando quisieran dar una clase con un parque de tablet desde 50€ hasta 1000€.

Los que dan la gestión de nuestros switches a teléfonica y luego no van a arreglar los problemas que hay de red, que duplican ip's porque no preguntan, hacen ping y sino responde usan esa ip, ¿amigo y si el equipo de red está apagado? ah! se siente.
Luego los muy profesionales cuando "crean el mapa de la red física", en vez de marcar en el panel de parcheo las conexiones entre armarios, ponen etiquetas en los latiguillos que unen las bocas con los switches, ¿de donde han salido estos pro's?

No puede ser que haya un sección administraciónSI que la dejen fuera de cualquier decisión, no les dejen participar activamente en reuniones, como es eso que está ahora tan de moda de profesionalizar la toma de decisiones y sacar la política y los cargos, pues eso es lo que se debería hacer. Ellos tendrían que estar desarrollando, depurando, evolucionando los sistemas que se usan tanto en coles, como en IES, no de adorno y haciendo el trabajo de los informáticos de algunos centros que con una simple buscada en la lista de correo o google hallarían la solución. Para dudas está la lista con el resto de los compañeros, internet y cuando es un problema global, un bug, entonces si administraciónSI.
AdministraciónSI no debe ser un call center ni asistencia técnica.

Esto correo va dirigido a los que amamos el SL  y no entendemos ni compartimos lo que se esta haciendo y a los responsables de este atropello para que sepan que no vamos a dar por perdida la batalla.

Tengo la conciencia bien tranquila por el trabajo bien hecho, y el que se ofenda con mis palabras, que reflexione, y si sigue ofendido, que se ...

Fdo.: Jaime Gómez Calero
Administrador informático CPR de Mérida.

Luego está el tema de las redes inalámbricas, en el que insistido mucho y al que dediqué un post. Reinventan la rueda creando una solución inalámbrica de aficionados, por no llamarlo de otro modo, difícil de gestionar, que utiliza al menos el doble de "puntos de acceso" de los que son necesarios y que encima se va a saturar por la cercanía de los mismos. Y en lugar de comprar puntos de acceso adecuados a las necesidades, vas y compras routers wifi y los flasheas con un firmware no sabemos para qué... ¿Por qué hay que buscar soluciones chapuceras cuando tenemos suficiente software libre para implantar soluciones profesionales más seguras y eficientes? ¿Tiene ésto algún sentido?

Fdo.: Esteban M. Navas Martín 
Administrador informátio IES Valle del Jerte.
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 2 de diciembre de 2015

Configurar switch TP-LINK TL-SG2424 por primera vez

Este switch tiene por defecto los siguientes datos de configuración:
  • IP: 192.168.0.1
  • Máscara de red: 255.255.255.0
  • Username: admin
  • Password: admin
Es muy sencillo configurar el switch por primera vez, si lo conectamos a la red y asignamos a nuestra máquina una IP del rango en el que se encuentra configurado por defecto.

Para no cambiar la ip de la interfaz de red de nuestro equipo, podemos asignarle una segunda dirección IP. Por ejemplo, suponiendo que mi equipo tiene una interfaz de red llamada vmbr0, puedo asignarle una segunda dirección IP de la siguiente manera:
# ip addr add 192.168.0.100/24 dev vmbr0
Una vez asignada, abrimos el navegador e introducimos la IP del dispositivo:

A continuación, introducimos nombre de usuario (admin) y password (admin):


Y con ésto, tendremos acceso a la configuración del switch:


Cuando terminemos de configurarlo, eliminamos la segunda dirección IP que habíamos asignado a la interfaz de red de nuestro equipo, y listo:
# ip addr del 192.168.0.100/24 dev vmbr0
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 30 de noviembre de 2015

Forzar apt-get para que sobreescriba ficheros de configuración instalados por otro paquete

En ocasiones, cuando instalamos un paquete, obtenemos un error porque trata de sobreescribir archivos instalados por otro paquete. Si ésto sucede, podemos hacer que apt-get los sobreescriba utilizando la opción --force-overwrite.

Veámoslo con un ejemplo:
# apt-get -o Dpkg::Options::="--force-overwrite" install libldap-2.4-2:i386
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 25 de noviembre de 2015

Instalar las páginas de ayuda de linux en español

Como todos sabéis, las páginas de ayuda de linux son un bien muy preciado que nos permiten consultar en cualquier momento la ayuda de cualquier comando, con tan sólo utilizar el comando man.

Cuando queremos disponer de las páginas de ayuda, instalamos el paquete manpages, que se encuentra en los repositorios de Debian.
# apt-get install manpages

Ahora bien, como muchas de las páginas de ayuda se encuentran traducidas a varios idiomas, si queremos disponer de ellas en español, deberemos instalar también el paquete manpages-es:
# apt-get install manpages-es
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar el historial del shell completamente

Una de las cosas más utilizadas por un administrador en la línea de comandos es el historial.

Cuando queremos consultar el historial de comandos de cualquier usuario ejecutamos el comando:
# history
De este modo, podemos ver todos los comandos que un usuario ha ejecutado en el shell. 

Ahora bien, el historial puede borrarse fácilmente de la siguiente manera:
# history -c && history -w 
Ésto limpia el historial actual del shell (history -c) y fuerza a que el historial (vacío tras ejecutar history -c) sobreescriba el fichero ~/.bash_history
Publicado por primera vez en http://enavas.blogspot.com.es

Configurar OpenMediaVault para que nos envíe notificaciones por correo usando el smtp de gmail

A continuación podéis ver un pantallazo en el que muestro cuál es la configuración que hay que realizar para que OpenMediaVault nos envíe notificaciones por correo electrónico usando el SMTP de gmail:

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

martes, 24 de noviembre de 2015

pkgsync 1.25-2: Añadidas nuevas mejoras y funcionalidades

He visto que el sistema que nos han proporcionado en el nuevo servidor HP es un Debian Jessie de 32 bits sin LVM. Como desconozco el motivo, y ya tenía en mente otros cambios, lo primero que pensé fue transformarlo en un sistema de 64 bits con volúmenes LVM.

Así que, aprovechando que la plataforma de virtualización Proxmox VE 4.0 está basada en Debian Jessie y quería disponer una plataforma de virtualización,  decidí matar dos pájaros de un tiro.

El problema estaba en que, examinando el sistema que nos han proporcionado, ví que la lista de paquetes de pkgsync incluía expresamente paquetes de 32 bits. Un verdadero problema, sobre todo, teniendo en cuenta que necesitamos seguir manteniendo la "compatibilidad". Y con compatibilidad me refiero a que el servidor siga respondiendo al puppetmaster de Mérida y nuestros compañeros de la sección de administración de sistemas puedan seguir gestionándolo mediante puppet como cualquier otro servidor. Pero sobre todo, cumplir mi objetivo de aprovechar mejor los recursos del servidor, y ya que dispongo de una máquina de 64 bits, lo más óptimo es que el sistema operativo también lo sea.

En diciembre de 2013, ya hice una mejora en pkgsync, modificándolo para compartir la gestión de paquetes. Así que pensé que lo más conveniente sería volver a revisar pkgsync, añadiéndole una serie de mejoras y funcionalidades, entre ellas, una que me permitiera ignorar el fichero musthave que mi servidor reciba vía puppet, manteniendo sólo los paquetes que yo indique en mis ficheros musthave locales.

Éstos son los cambios que he realizado en pkgsync:

Primero.- Además de permitir fusionar los archivos musthave, maynothave y mayhave gestionados por la sección de administración de sistemas con los archivos musthave.ies, maynothave.ies y mayhave.ies gestionados por el administrador informático del centro, es posible crear ficheros en los siguientes directorios:
  • /etc/pkgsync/musthave.d
  • /etc/pkgsync/mayhave.d
  • /etc/pkgsync/maynothave.d
Ésto permite al administrador mantener organizadas sus listas de paquetes.

De este modo pkgsync fusionará por un lado todos los musthave, por otro los mayhave y por otro los maynothave, eliminando repeticiones y limpiando los ficheros de espacios en blanco y tabulaciones.

Segundo.- A veces, por circunstancias, resulta imposible realizar una gestión compartida, como en este caso: Estoy tratando de instalar un sistema de 64 bits y en los ficheros musthave figuran expresamente paquetes de 32 bits que me rompen el sistema. Esta modificación es la que me llevó a introducir las diferentes mejoras que he introducido en pkgsync. 
De este modo, podemos ignorar los ficheros musthave, mayhave y maynothave, con tan sólo cambiar el valor de las siguientes variables en el fichero /etc/default/pkgsync:

IGNORE_MUSTHAVE="no"
IGNORE_MAYHAVE="no"
IGNORE_MAYNOTHAVE="no"


por:

IGNORE_MUSTHAVE="yes"
IGNORE_MAYHAVE="no"
IGNORE_MAYNOTHAVE="no"

Para ello he introducido un fichero de configuración: /etc/default/pkgsync.

En el ejemplo anterior, como podéis comprobar estoy ignorando el fichero /etc/pkgsync/musthave, de tal manera que pkgsync para crear la lista de paquetes sólo utilizará el fichero /etc/pkgsync/musthave.ies junto con los ficheros ubicados en /etc/pkgsync/musthave.d/ y todos los ficheros mayhave y maynothave.

Tercero.- Como el script pkgsync nos lo colocan vía puppet en el directorio /usr/sbin y necesito que se ejecute mi versión de pkgsync, el paquete lo instala en /usr/local/sbin que tiene prioridad sobre /usr/sbin.

Cuarto.- En esta versión de pkgsync he añadido una funcionalidad interesante que permite comprobar si alguno de los ficheros de pkgsync contiene paquetes que no se encuentran disponibles en los repositorios utilizando el parámetro -t,--test-files.
Al ejecutar pkgsync -t o pkgsync --test-files se muestra por pantalla la lista de paquetes especificados en los ficheros de pkgsync que no se encuentran en los repositorios y, además, lo almacena en el siguiente fichero de log:
/var/log/pkgsync/removefromlist.log

Quinto.- Por último, también he añadido una mejora que considero muy importante: En esta versión de pksync se da prioridad a los ficheros maynothave, de tal manera que, cuando el administrador especifique un nombre de paquete en un fichero maynothave, si el nombre del fichero se encuentra añadido a cualquiera de los ficheros musthave, pkgsync lo ignorará para que aptitude no trate de instalarlo. Ésto me resuelve el problema de instalar un paquete que es incompatible con los que se han instalado por defecto en el sistema y el que se ha instalado por defecto en el sistema no se usa y me estorba.

Por si alguien quiere echarle un vistazo, he subido el proyecto a mi github:
https://github.com/algodelinux/pkgsync

Aquí podéis ver el código completo de pkgsync:
Y si queréis descargar el paquete que instala esta versión de pkgsync, aquí lo tenéis:
https://copy.com/d2n3dZ2izAlvj6fH
Publicado por primera vez en http://enavas.blogspot.com.es

Modificado el script musthave-build para Debian Jessie

Como ya comenté anteriormente, en Debian Squeeze creábamos una lista de paquetes en /etc/pkgsync/musthave con los nombres de los paquetes instalados intencionadamente en el sistema para mantener una uniformidad en el software instalado en un conjunto de máquinas. Para generar la lista de paquetes en Debian Wheezy, que es multiarch, tuve que hacer una pequeña modificación que incluya, además del nombre del paquete instalado, su arquitectura.

Así que preparé un script al que llamé musthave-build que detecta el codename del sistema operativo (squeeze o wheezy) realiza la generación del fichero musthave en función del mismo. Pues bien, recientemente lo he modificado para que permita crear la lista de paquetes también en Debian Jessie.

Aquí podéis ver el código:
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 21 de noviembre de 2015

sed: Eliminar espacios en blanco y tabuladores en ficheros de configuración

Cuando trabajamos con shell scripts en los que necesitamos hacer comparaciones, muchas veces nos surgen problemas porque el usuario ha introducido espacios en blanco y/o tabuladores. 

Supongamos que tenemos un fichero mayhave en el que el usuario ha introducido los nombres de los paquetes que el sistema puede tener con espacios y tabuladores. Por ejemplo:
        acpi     
     man


              cinnamon-desktop-environment
         
zip





    mtools

Podemos quitar todos los espacios y tabuladores de una forma muy sencilla, con tan sólo ejecutar el comando sed:
# sed -i -e 's/^[ \t]*//; s/[ \t]*$//; /^$/d' fichero
Y el fichero quedaría así:
acpi
man
cinnamon-desktop-environment
zip

Si dividimos las expresión aplicada con sed en partes, veremos que es muy sencillo:
  • Eliminamos los espacios en blanco y tabuladores al comienzo de cada línea:
    s/^[ \t]*//
  • Eliminamos los espacios en blanco y tabuladores al final de cada línea:
    s/[ \t]*$//
  • Eliminamos las líneas en blanco con líneas en blanco formadas por espacios y/o tabuladores:
    /^$/d
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 12 de noviembre de 2015

Error "Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0" al abrir gnome-terminal en Debian Jessie

Si tratáis de abrir gnome-terminal en Debian Jessie y obtenéis un error como el siguiente: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0 , lo más probable es que sea porque hay un bug que no permite iniciarlo cuando se usan locales sin UTF-8. Si es así, reconfigurad vuestros locales y elegid uno que sea UFT-8:
# dpkg-reconfigure locales
Una vez configurados, ejecutad el comando locale para comprobarlo:
# locale
LANG=es_ES.UTF-8
LANGUAGE=
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 11 de noviembre de 2015

Instalar Google Chrome desde los repositorios de Google en Debian Jessie

Instalar Google Chrome desde los repositorios de Google es muy sencillo.
Vamos a verlo paso a paso para que quede muy claro:

Primero.- Añadimos la dirección del repositorio a los archivos de fuentes:
# echo "deb http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list
Segundo.- Descargamos la clave pública del repositorio y la añadimos directamente al anillo de claves:
wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | sudo apt-key add - 
El anillo de claves se guarda en el archivo /etc/apt/trusted.gpg
Tercero.- Actualizamos los índices de los repositorios:
# apt-get update
Cuarto.- Instalamos Google Chrome:
# apt-get install google-chrome-stable
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar la última versión de Iceweasel desde los repositorios de Mozilla en Debian Jessie

Mantener actualizado iceweasel en Debian Jessie es muy sencillo si utilizamos los repositorios de Mozilla y los de Debian-Backports.

Primero.- Añadimos los repositorios necesarios a un archivo de fuentes. Para mantener un poco organizadas las fuentes de mis repositorios, lo haré de la siguiente manera:
# echo "# Repositorio del Mozilla Debian Team\n\ndeb http://mozilla.debian.net/ jessie-backports iceweasel-release" > /etc/apt/sources.list.d/mozilla.list

# echo "# Repositorio jessie-backports\n\ndeb http://ftp.es.debian.org/debian jessie-backports main contrib non-free" > /etc/apt/sources.list.d/jessie-backports.list
Segundo.- Actualizamos los índices de los repositorios:
# apt-get update
Tercero.- Instalamos el paquete que contiene la firma del repositorio de mozilla:
# apt-get install  pkg-mozilla-archive-keyring
Cuarto.- Por último, instalamos iceweasel en español:
# apt-get -t jessie-backports install iceweasel iceweasel-l10n-es-es
Publicado por primera vez en http://enavas.blogspot.com.es

domingo, 8 de noviembre de 2015

Resetear punto de acceso UniFi a sus valores por defecto conociendo su IP

Si conocemos la IP del punto de acceso Ubiquiti, es muy sencillo resetearlo:
  1. Nos conectamos al punto de acceso mediante ssh. Nos pedirá que introduzcamos la contraseña. Así que introducimos la contraseña del controlador.
  2. Una vez conectados al punto de acceso, ejecutamos el comando "set-default" y esperamos algo más de un minuto a que termine de reiniciar.
  3. Cuando haya terminado, ya podemos volver a conectarnos por ssh con los datos de acceso por defecto:
    • Usuario: ubnt
    • Password: ubnt
Publicado por primera vez en http://enavas.blogspot.com.es

¿Qué significa el color del LED en los puntos de acceso Ubiquiti UAP?

El color del led de estado de nuestros dispositivos UAP de Ubiquiti va a variar dependiendo del estado del mismo.


Si nuestro dispositivo es un UAP-Normal, un UAP Long Range o un UAP Outdoor, éste es el significado de los colores del LED de estado:
  • Orange Blinking (second interval) - initializing
  • Orange Steady - factory defaults; awaiting adoption
  • Orange Flashes (every 10 seconds) - reset device & readopt
  • Green Steady - adopted
  • Green Flashing (every 3-4 seconds) - isolated AP; looking for uplink
  • Green Flashing (intervals < 1 second) - AP being located in controller
  • No Light Steady - Check power/cable/POE
Y si nuestro dispositivo es un UAP-Pro, éste es el significado de los colores del LED de estado:
  • White Flashing - initializing
  • White Steady - factory defaults; awaiting adoption
  • White/Blue Flashing - busy with process (i.e. firmware); do not disconnect!
  • Blue Steady - device is successfully integrated in UAP network
  • Blue Steady Flashing (every 3-4 seconds) - isolated AP; looking for uplink
  • Blue Flashing (intervals < 1 second) - AP being located by controller
  • Blue/White Flashing - busy with process (i.e. firmware); do not disconnect!
Fuente: http://www.getclearwave.com/knowledge-base/what-do-the-led-color-patterns-represent-for-uaps/
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 5 de noviembre de 2015

Error al actualizar VirtualBox 5.0.6 a VirtualBox 5.0.8 en Debian Jessie

Al actualizar VirtualBox 5.0.6 a VirtualBox 5.0.8 en Debian Jessie he observado que no se me abría ninguna de las máquinas virtuales que tenía instaladas y me aparecía un cuadro de diálogo diciendo que ejecutara /sbin/vboxconfig para instalar los módulos de VirtualBox.

Al ejecutar el comando /sbin/vboxconfig siempre obtengo los mismos errores:
Failed to get D-Bus connection: Error desconocido -1
Failed to get D-Bus connection: Error desconocido -1
Failed to get D-Bus connection: Error desconocido -1
Failed to get D-Bus connection: Error desconocido -1
La solución para eliminar los viejos módulos de VirtualBox e instalar los nuevos es ejecutar:
# rcvboxdrv setup
Stopping VirtualBox kernel modules ...done.
Uninstalling old VirtualBox DKMS kernel modules ...done.
Removing old VirtualBox pci kernel module ...done.
Removing old VirtualBox netadp kernel module ...done.
Removing old VirtualBox netflt kernel module ...done.
Removing old VirtualBox kernel module ...done.
Trying to register the VirtualBox kernel modules using DKMS ...done.
Starting VirtualBox kernel modules ...done.
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar certificados en el cliente puppet

Si tenemos problemas con los certificados en algún cliente, puppet nos muestra un mensaje informándonos de que debemos borrar el certificado tanto en el cliente como en el servidor:

Cuando tengo que borrar el certificado en el servidor, lo hago con la herramienta puppet cert:
# puppet cert clean nombrehost.nombredominio

Y cuando tengo que borrar el certificado en el cliente utilizo el siguiente script que coloqué en el directorio /usr/local/sbin de todos los clientes puppet:
#!/bin/bash
#
# Esteban M. Navas Martín 
#

test -f /var/run/puppet/agent.pid && puppet resource service puppet ensure=stopped
rm -r $(puppet agent --configprint ssldir)/* && puppet agent --test
grep "START=yes" /etc/default/puppet && puppet resource service puppet ensure=running
Fijáos en el script:
  • Si puppet está corriendo en el cliente, lo paro utilizando el propio recurso service de puppet.
  • A continuación borro el directorio de almacenamiento de las claves ssl y hago un puppet agent --test para volver a regenerarlo.
  • Y, por último, utilizando de nuevo el recurso service de puppet, me aseguro de que se vuelva a iniciar, si el servicio está configurado para iniciarse.
 
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 4 de noviembre de 2015

Limpiar y regenerar certificados en el servidor puppet

En ocasiones, es posible que necesitemos regenerar los certificados, así como las credenciales de seguridad (claves públicas y claves privadas) creadas por la autoridad de certificación de nuestro servidor Puppet. Para ello seguiremos los siguientes pasos:

Primero.- como nuestro servidor puppet es cliente y servidor a la vez, nos aseguraremos de cuál es el directorio ssldir del puppetmaster:
root@servidor ~ # puppet master --configprint ssldir
/var/lib/puppet/ssl
Segundo.- Haremos un backup del directorio /var/lib/puppet/ssl del servidor Puppet. De este modo, si algo no fuera bien, podríamos restaurar la configuración:
root@servidor ~ # cp -r $(puppet master --configprint ssldir) $(puppet master --configprint ssldir).old
Tercero.- Paramos el servicio puppet agent:
root@servidor ~ # puppet resource service puppet ensure=stopped
Si os dáis cuenta, lo estamos parando usando los recursos de puppet.
Cuarto.- Paramos el servicio puppet master. Una observación importante: Como nuestro servidor puppet está montado con apache2 mediante passenger, lo que tenemos que parar es el servicio apache2:
root@servidor ~ # puppet resource service apache2 ensure=stopped
Quinto.- Una vez parados los servicios, borramos  el contenido del directorio ssldir:
root@servidor ~ # rm -r $(puppet master --configprint ssldir)/*
Sexto.- Regeneramos los certificados de la autoridad de certificación:
root@servidor ~ # puppet cert list -a
Veremos un mensaje como el siguiente:
Notice: Signed certificate request for ca
Lo que significa que la autoridad de certificación de puppet se habrá autofirmado su certificado.
Séptimo.- A continuación, generamos los nuevos certificados del puppet master:
root@servidor ~ # puppet master --no-daemonize --verbose
Ésto ejecutará puppet master en primer plano. Cuando veamos el siguiente mensaje en pantalla, pulsamos Ctrl+C:
Notice: Starting Puppet master 
Octavo.- Una vez regenerados los certificados,  arrancamos el puppet master de nuevo levantando apache2:
root@servidor ~ # puppet resource service apache2 ensure=running
Noveno.- Y por último, arrancamos el puppet agent de nuevo:
root@servidor ~ # puppet resource service puppet ensure=running
Con todo ésto, habremos creado dos cosas:
  • Un nuevo certificado y una nueva clave para la autoridad de certificación de puppet (CA).
  • Un nuevo certificado para el puppet master firmado por la autoridad de certificación.
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 3 de noviembre de 2015

Crear una lista blanca de hosts en denyhosts

Podemos crear una lista blanca de hosts en el fichero /var/lib/denyhosts/allowed-hosts, de tal manera que denyhosts no monitorice los accesos desde las IP's que especifiquemos dentro del mismo. Este fichero contendrá una IP por línea. Por ejemplo:
127.0.0.1
172.19.25.10
172.19.25.11
172.19.25.12
Publicado por primera vez en http://enavas.blogspot.com.es

Script para listar las direcciones IP baneadas por denyhosts

Aunque tan sólo hay que echar un vistazo al fichero /etc/hosts.deny para ver qué direcciones IP se encuentran baneadas en un momento determinado, utilizo un script muy simple: listbannedhosts:
#!/bin/bash

sed -nr "/([0-9]{1,3}\.){3}[0-9]{1,3}/ p" /etc/hosts.deny | cut -f2 -d" "
Así, si lo necesito, puedo utilizar este script desde otro.
https://copy.com/0knRokFHTV1q31nF
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar una dirección IP baneada por denyhosts

Si utilizáis denyhosts para prevenir ataques de fuerza bruta contra ssh a vuestros servidores, probablemente más de una vez os habréis equivocado al realizar la conexión y habéis bloqueado accidentalmente el acceso a la IP desde la que habéis accedido.

Para volver a permitir el acceso a una IP denegada por denyhosts, es necesario borrarla de los siguientes archivos:
  • /etc/hosts.deny
  • /var/lib/denyhosts/hosts 
  • /var/lib/denyhosts/hosts-restricted
  • /var/lib/denyhosts/hosts-root
  • /var/lib/denyhosts/hosts-valid
  • /var/lib/denyhosts/users-hosts
Para poder hacerlo de una forma más cómoda, he creado un script al que he llamado unbanhost que "des-banea" la IP que le indiquemos como parámetro:
#!/bin/bash

if [ -z "$1" ]; then
    echo -e "Error:\tDebe indicar la IP del host"
    echo -e "  Uso: $0 "
    exit 1
fi

/etc/init.d/denyhosts stop
sed -i "/$1/d" /var/lib/denyhosts/hosts
sed -i "/$1/d" /var/lib/denyhosts/hosts-restricted
sed -i "/$1/d" /var/lib/denyhosts/hosts-root
sed -i "/$1/d" /var/lib/denyhosts/hosts-valid
sed -i "/$1/d" /var/lib/denyhosts/users-hosts
sed -i "/$1/d" /etc/hosts.deny
/etc/init.d/denyhosts start
https://copy.com/kpOTUNhSXas3hvuX
Publicado por primera vez en http://enavas.blogspot.com.es

Utilizar expresiones regulares extendidas en el comando sed

Podemos emplear expresiones regulares extendidas en el comando sed, utilizando el parámetro -r (--regexp-extended). Las expresiones regulares extendidas son aquellas aceptadas por el comando egrep.

Por ejemplo, si queremos buscar las líneas que contienen una IP en un fichero, podríamos usar la siguiente expresión regular: ([0-9]{1,3}\.){3}[0-9]{1,3}
# sed -nr "/([0-9]{1,3}\.){3}[0-9]{1,3}/ p" /etc/hosts.deny
Publicado por primera vez en http://enavas.blogspot.com.es

Tecla de acceso al BIOS en portátiles TTL de TeknoService

La tecla de acceso a la configuración BIOS en portátiles TTL de TeknoService es F2.

Si tenéis Windows instalado y no podéis entrar en ella, probablemente sea porque se encuentra activado el Fast Startup en el sistema operativo.
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 30 de octubre de 2015

Ventajas de utilizar puntos de acceso Ubiquiti coordinados por un controlador frente al uso de un router DLINK Dir- 860L aislado por aula

Como ya he comentado en otras ocasiones, y aprovechando que me han preguntado sobre el tema, vuelvo a insistir en que sería mucho mejor utilizar puntos de acceso Ubiquiti en nuestras instalaciones, gestionados desde un único lugar (el controlador unifi) y trabajando de forma coordinada, que utilizar un router DLINK Dir- 860L aislado por aula.

¿Razones? 
  • Funcionamiento óptimo del sistema inalámbrico, puesto que  los puntos de acceso balancearán la carga.
  • Garantía en la itinerancia cuando un usuario se mueve entre las zonas de cobertura de los diferentes puntos de acceso.
  • Posibilidad de limitar el consumo de ancho de banda de subida y bajada.
  • Mayor control y sencillez en la tarea de administración de puntos de acceso: Desde un único lugar y mediante una interfaz web podemos ver todos los puntos de acceso que tenemos instalados en nuestra red, además de poder verificar de un vistazo si todos ellos se encuentran funcionando.

  • Control de todos los puntos de acceso desde la interfaz, pudiendo reiniciarlos, actualizar su firmware, etc... El sistema permite activar la actualización automática del firmware de todos los puntos de acceso.

  • Control de todos los dispositivos conectados en un momento determinado a la red inalámbrica, obteniendo sus datos, consumo de ancho de banda, además de poder bloquearles y desbloquearles el acceso.

  • Visualización de estadísticas de uso, pudiendo seleccionar días concretos.

  • Gestión de un histórico de conexiones en el que se puede consultar qué equipos se conectaron en un momento determinado, tiempo de conexión, consumo de ancho de banda y posibilidad de bloquear el acceso a equipos del histórico.

Si a ésto le añadimos el servidor PfSense que nos permite controlar el acceso mediante usuario/password a través de un portal cautivo o tickets y un par de servidores freeradius que realizan el control de usuarios de ldap, las posiblidades de control pueden ser infinitas.
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar el mensaje "No Valid Subscription" en versiones Proxmox 3+

Para los que utilizáis Proxmox como yo, os recomiendo leer el siguiente post acerca de cómo eliminar el popup con el mensaje "No Valid Subscription" que aparece al hacer login en versiones de Proxmox a partir de la 3, no tan sólo por eliminar el molesto mensaje sino por la interesante reflexión del autor:
https://smyl.es/how-to-remove-proxmox-no-valid-subscription-pop-up-message-from-proxmox-3/
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 28 de octubre de 2015

Compilar Squid3 para realizar filtrado HTTPS y SSL Bumping

Como ya sucede con otros paquetes en Debian, Squid3 no viene compilado con soporte SSL. Así que, si queremos utilizarlo para realizar filtrado https, tendremos que compilarlo nosotros mismos.

Para poner en práctica lo explicado en este post, voy a utilizar Debian Jessie, que es lo que tengo en casa. La compilación en Debian Wheezy se haría exactamente del mismo modo.

Lo primero que debemos hacer es instalar las herramientas de desarrollo, si no las tenemos instaladas ya:
# apt-get install build-essential fakeroot dpkg-dev
Además instalamos curl para descargar archivos:
# apt-get install curl
Una vez instalado todo lo necesario, nos aseguramos de que tenemos el repositorio de código fuente de Debian en nuestra lista de repositorios, y si no, lo añadimos a nuestro /etc/apt/sources.list:
deb-src http://ftp.es.debian.org/debian jessie main
La diferencia entre el repositorio de código fuente y el de binarios es que el primero comienza con deb-src y el segundo con deb.
A continuación hacemos un:
# apt-get update
Después instalamos las dependencias necesarias para construir el paquete squid3:
# apt-get build-dep squid3
Y a continuación descargamos el código fuente de squid3 con nuestro usuario no privilegiado:
$ apt-get source squid3
Una vez hecho ésto, descargamos el script para compilar el código fuente:
$ curl -o squid-compile.sh https://copy.com/nLo0EbtLO3IocN4o
Y le damos permisos de ejecución:
$ chmod 755 squid-compile.sh
A continuación descargamos el parche para realizar la compilación con soporte ssl:
$ curl -o rules.patch https://copy.com/Xk1hq8nahtlmGfFJ
Y por último, ejecutamos el script para que construya los paquetes con soporte ssl:
$ ./squid-compile.sh
El proceso tardará un rato más o menos largo dependiendo de la potencia de vuestro ordenador. Cuando termine, encontraréis los siguientes paquetes creados:
  • squid3_3.4.8-6_amd64.deb
  • squid-cgi_3.4.8-6_amd64.deb
  • squid3-common_3.4.8-6_all.deb
  • squidclient_3.4.8-6_amd64.deb
  • squid3-dbg_3.4.8-6_amd64.deb
  • squid-purge_3.4.8-6_amd64.deb
Publicado por primera vez en http://enavas.blogspot.com.es

Descargar un archivo desde copy.com con el comando curl

Descargar un archivo desde Copy.com es una tarea sencilla si utilizamos el comando curl.

La sintaxis para descargarlo es la siguiente:
curl -o nombreficherodestino URL
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar wiithon en Debian Jessie

En un post de 2009 os hablé de WBFS, y un tiempo después vimos como instalar wiithon en Debian Squeeze

Wiithon es una herramienta GPL que sirve para trabajar con backups de juegos Wii, permitiendo añadirlos a un disco duro, extraerlos, etc. 

Esta herramienta ha evolucionado y mejorado aún más con el tiempo. La última versión que podemos encontrar en launchpad es la 1.32, publicada en noviembre de 2014.


Disponer de wiithon en Debian Jessie es muy sencillo puesto que tan sólo hay que instalar el paquete Debian correspondiente a nuestra arquitectura:
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 26 de octubre de 2015

Actualizar Debian Wheezy automáticamente mediante unattended-upgrades

En un post de mayo de 2012 os mostré cómo actualizar los paquetes de Debian Squeeze automáticamente utilizando unattended-upgrades, una aplicación para realizar instalaciones automáticas de actualizaciones de seguridad, ideal para mantener actualizado el software de nuestro equipo de forma desatendida.

Como desde la versión que teníamos instalada en Debian Squeeze han cambiado algunas cosillas (por ejemplo: ya no corre como demonio), vamos a dar un repaso de nuevo a esta herramienta.

Instalar unattended-upgrades en Debian Wheezy sigue siendo igual de sencillo, puesto que el paquete se encuentra en los repositorios:
# apt-get install unattended-upgrades
Una vez instalado, echaremos un vistazo al principal fichero de configuración: /etc/apt/apt.conf.d/50unattended-upgrades:
// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
        "origin=Debian,archive=stable,label=Debian-Security";
        "origin=Debian,archive=oldstable,label=Debian-Security";
};

// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
//      "vim";
//      "libc6";
//      "libc6-dev";
//      "libc6-i686";
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION* if a
// the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";
Este fichero es muy fácil de entender, sobre todo teniendo en cuenta los comentarios que explican los parámetros. Como podéis comprobar, viene configurado para realizar tan sólo las actualizaciones de Debian-Security, pero podemos modificarlo para que se actualicen de forma desatendida los paquetes de todos nuestros repositorios.

El siguiente bloque del fichero de configuración permite definir los repositorios desde los que queremos actualizar automáticamente los paquetes:
// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
        "origin=Debian,archive=stable,label=Debian-Security";
        "origin=Debian,archive=oldstable,label=Debian-Security";
};
En este bloque podemos añadir nuevos patrones que permitan realizar instalaciones desatendidas desde otros repositorios. Para especificar repositorios utilizaremos los siguientes campos:
  • origin (formato corto: o).
  • label (formato corto: l).
  • archive (formato corto: a).
  • suite.
  • component (formato corto: c).
  • site.
Podemos encontrar los valores de cada uno de los campos de nuestros repositorios en los ficheros _Release alojados en /var/lib/apt/lists/.

Por ejemplo, supongamos que deseamos actualizar los paquetes del repositorio de Mozilla. Como ya tenemos configurado este repositorio en nuestra máquina, obtenemos las primeras líneas del siguiente archivo, donde veremos los datos que vamos a necesitar:
# head /var/lib/apt/lists/ldap_mozilla-backports_dists_wheezy-backports_Release
Origin: Debian Mozilla Team
Label: Debian Mozilla Team
Suite: wheezy-backports
Codename: wheezy-backports
Date: Fri, 16 Oct 2015 05:45:52 UTC
Architectures: i386 amd64
Components: iceweasel-release iceweasel-esr
Description: Debian Mozilla team APT archive for wheezy-backports
MD5Sum:
 8fe44fc8853db9b7df27b21016257761 86467 iceweasel-release/binary-i386/Packages
Viendo la salida del comando anterior, podríamos construir un patrón de origen como el siguiente:
        "o=Debian Mozilla Team,suite=wheezy-backports";
Y añadirlo al fichero /etc/apt/apt.conf.d/50unattended-upgrades, para que se actualicen también los paquetes del repositorio de Mozilla de forma desatendida:
// Automatically upgrade packages from these origin patterns
Unattended-Upgrade::Origins-Pattern {
        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
//      "o=Debian,a=stable";
//      "o=Debian,a=stable-updates";
//      "o=Debian,a=proposed-updates";
        "origin=Debian,archive=stable,label=Debian-Security";
        "origin=Debian,archive=oldstable,label=Debian-Security";
        "o=Debian Mozilla Team,suite=wheezy-backports";
};
Por otra parte, "descomentaremos" las líneas de las opciones que nos interese aplicar.
Por ejemplo, sería interesante aplicar esta opción para solucionar el problema de que en una ejecución anterior de dpkg se hubiera interrumpido el proceso:
Unattended-Upgrade::AutoFixInterruptedDpkg "true";

Una vez hecho ésto, creamos el fichero /etc/apt/apt.conf.d/02periodic con el siguiente contenido:
// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable "1";

// Do "apt-get update" automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists "1";

// Do "apt-get upgrade --download-only" every n-days (0=disable)
APT::Periodic::Download-Upgradeable-Packages "1";

// Run the "unattended-upgrade" security upgrade script
// every n-days (0=disabled)
// Requires the package "unattended-upgrades" and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";

// Do "apt-get autoclean" every n-days (0=disable)
APT::Periodic::AutocleanInterval "7";
Este fichero nos servirá para configurar las actualizaciones periódicas. Veamos lo que significa cada opción con un ejemplo: 
  • APT::Periodic::Enable "1";  Activamos las actualizaciones automáticas poniendo el valor a 1 o las desactivamos poniendo el valor a 0.
  • APT::Periodic::Update-Package-Lists "1"; Hacemos un apt-get update. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::Download-Upgradeable-Packages "1"; Descargamos los paquetes actualizables. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::AutocleanInterval "7"; Hacemos un apt-get autoclean cada 7 días. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::Unattended-Upgrade "1"; Ejecutar el script"unattended-upgrade" cada día. Si ponemos el valor a 0 lo desactivamos.    
unattended-upgrades se ejecuta mediante cron (/etc/cron.daily/apt). No obstante, si queremos, podemos forzar la ejecución manualmente mediante el script unattended-upgrade:
# unattended-upgrade
Además, podemos ejecutar unattended-upgrade en modo debug:
# unattended-upgrade -d
O simular la ejecución de unattended-upgrade sin llegar a actualizar:
# unattended-upgrade -d --dry-run
Publicado por primera vez en http://enavas.blogspot.com.es

Cómo hacer que ssh utilice una determinada interfaz de red

Algunas veces tenemos máquinas con varias interfaces de red y en ocasiones puede que coincida el rango de direcciones de algunas de ellas. 

En ese caso, si queremos realizar una conexión con ssh a una máquina de uno de los rangos de red que coinciden, podemos especificar la dirección IP de la interfaz de red por la que estamos conectados a su red utilizando el parámetro --bind (-b) de ssh:
# ssh --bind 192.168.1.16 root@192.168.1.35
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 23 de octubre de 2015

Resetear punto de acceso UniFi a sus valores por defecto

En la parte trasera del punto de acceso, junto al conector de red ethernet, hay un pequeño agujero con un botón de reset.  

Para resetear el punto de acceso:
  1. Pulsamos y mantenemos pulsado con un clip el botón de reset durante 10 segundos.
  2. A continuación soltamos el botón. El led de color del punto de acceso se apagará. y comenzará el proceso de reinicio.
Una vez hecho ésto, no debemos desconectar el punto de acceso del alimentador POE y el punto de acceso se restaurará a sus valores por defecto.
 
Una vez que el led vuelva a encenderse de color naranja y permanezca fijo sin parpadear, podremos comenzar el proceso de adopción por parte del controlador.

Este procedimiento sirve para los siguientes puntos de acceso:
  • UAP
  • UAP-Pro
  • UAP-LR
  • UAP-AC
  • UAP-Outdoor
  • UAP-Outdoor+
Publicado por primera vez en http://enavas.blogspot.com.es

Configurar SMTP en controlador UniFi para recibir notificaciones

En un post anterior, os mostré como  instalar el controlador UniFi en Debian Jessie para controlar todos nuestros puntos de acceso y gestionar nuestra red wifi desde un único lugar. No he publicado como realizar la instalación en Debian Wheezy porque el procedimiento es exactamente el mismo.

Es muy recomendable configurar SMTP en el controlador UniFi para recibir notificaciones del controlador. Y qué mejor manera de hacerlo que usando el SMTP de gmail, si no tenéis un servidor SMTP en vuestra red.

En la siguiente captura de pantalla podéis ver los valores que es necesario configurar para que nuestro controlador UniFi pueda enviarnos notificaciones mediante el SMTP de Gmail:


Básicamente se trata de acceder a la sección Controller, que he marcado con un (1) en la imagen e introducir los valores como se muestran en la imagen:
  • Activamos la casilla "Enable mail server".
  • En host escribimos el nombre del servidor SMTP de Gmail: smtp.gmail.com
  • En puerto especificamos el puerto 587.
  • Marcamos la casilla "Enable SSL"
  • Marcamos la casilla "Enable Authentication".
  • Escribimos el nombre del usuario que se va a utilizar para enviar el e-mail. En mi caso podéis ver que he introducido la dirección de correo completa. Pues bien, eso es porque he utilizado una cuenta de mi dominio de Google Apps.
  • Escribimos el password del usuario que se va a utilizar para enviar el e-mail.
  • Si marcamos la casilla "Specify sender address" podemos especificar la dirección de correo que queramos se muestre en la dirección de envío.
 Por último, tan sólo me queda decir que podéis testear si el envío funciona introduciendo una dirección en la casilla " Send test email to"
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 22 de octubre de 2015

Encender y apagar la wifi de nuestro router A4001N utilizando el botón de reset/wps

Si echáis un vistazo al siguiente howto, veréis que es muy sencillo asignar funciones a los botones de nuestro router wifi con OpenWRT:
http://wiki.openwrt.org/doc/howto/hardware.button

Para este post, he utilizado un A4001N, pero es perfectamente aplicable a otros routers con OpenWRT.
La idea es que podamos apagar el wifi si mantenemos presionado el botón de reset/wps durante un intervalo de tiempo y volver a encenderlo de nuevo del mismo modo.

Vamos a hacer todo ésto desde la línea de comandos, así que nos conectamos al router mediante ssh.

Una vez conectados, lo primero que tenemos que hacer es identificar los botones.  Para ello, creamos una carpeta en el directorio /etc/hotplug.d a la que llamaremos button:
# mkdir /etc/hotplug.d/button
Dentro de esa carpeta creamos un script al que podemos llamar buttons, por ejemplo, con el siguiente contenido:
/etc/hotplug.d/button/buttons
#!/bin/sh
logger the button was $BUTTON and the action was $ACTION
El script lo que hará será crear una entrada en el registro de logs con un mensaje que nos informa del botón que pulsó y la acción que se realizó.

Una vez lo hayamos guardado, pulsamos un botón (en nuestro caso hemos dicho que el botón de reset/wps, que por cierto, es el único que tiene nuestro router además del botón de apagado) y lo soltamos.

A continuación leemos los logs utilizando el comando logread:
# logread
Y entre los muchos mensajes de log, veremos algunos como los siguientes:
Thu Oct 22 20:30:37 2015 user.notice root: the button was wps and the action was pressed
Thu Oct 22 20:30:38 2015 user.notice root: the button was wps and the action was released
Que nos informa de dos cosas:
  • El botón llamando "wps" fué pulsado "presed".
  • El botón llamando "wps" fué soltado "released".
Pues bien. Con ésto ya hemos identificado el nombre del botón (wps) y sus dos acciones: "pressed" y "released".

El siguiente paso que daremos, una vez identificado el botón, será descargarnos un script que va a gestionar las acciones que se deben realizar cuando el botón se haya pulsado durante un intervalo de tiempo. Y lo vamos a descargar directamente en el router usando wget, así que si no tenéis instalado wget, lo instaláis:
# opkg update && opkg install wget
Una vez instalado wget, lo ejecutamos para que descargue el script 00-button y lo coloque en el directorio /etc/hotplug.d/button/ directamente:
# wget --no-check-certificate -O /etc/hotplug.d/button/00-button https://dev.openwrt.org/export/36332/trunk/target/linux/atheros/base-files/etc/hotplug.d/button/00-button
Y le damos permisos de ejecución:
# chmod 755 /etc/hotplug.d/button/00-button
Este script contiene el siguiente código:
. /lib/functions.sh
do_button () {
        local button
        local action
        local handler
        local min
        local max

        config_get button $1 button
        config_get action $1 action
        config_get handler $1 handler
        config_get min $1 min
        config_get max $1 max

        [ "$ACTION" = "$action" -a "$BUTTON" = "$button" -a -n "$handler" ] && {
                [ -z "$min" -o -z "$max" ] && eval $handler
                [ -n "$min" -a -n "$max" ] && {
                        [ $min -le $SEEN -a $max -ge $SEEN ] && eval $handler
                }
        }
}

config_load system
config_foreach do_button button
Ahora que ya tenemos el script en su sitio, podemos crear configuraciones para ejecutar diferentes acciones en función del tiempo que el usuario deje pulsado el botón. 
Las configuraciones de los botones se almacenan en el mismo fichero que las configuraciones de los leds, es decir, en el archivo /etc/config/system. Así que editamos este fichero y le añadimos lo siguiente:
config button
        option button   wps
        option action   released
        option handler  "/usr/bin/wifionoff"
        option min      0
        option max      3
La configuración que estamos realizando se entiende por sí sola: Estamos definiendo un botón cuyo nombre es wps y la acción que se debe realizar (ejecutar el script /usr/bin/wifionoff) al soltar el botón cuando se haya pulsado durante un tiempo entre 0 y 3 segundos.

Por último, no nos queda más que crear el script /usr/bin/wifionoff, que se encargará de conmutar entre los estados de encendido y apagado del router:
#!/bin/sh
SW=$(uci -q get wireless.@wifi-device[0].disabled)
[ "$SW" == "1" ] && uci set wireless.@wifi-device[0].disabled=0
[ "$SW" == "1" ] || uci set wireless.@wifi-device[0].disabled=1
wifi
Si ahora quisiéramos hacer que el router se resetease a los valores por defecto al pulsar el mismo botón durante un tiempo de entre 20 y 25 segundos, añadiríamos la siguiente configuración al fichero /etc/config/system:
config button
        option button   wps
        option action   released
        option handler  "firstboot && reboot"
        option min      20
        option max      25
De este modo, podríamos configurar diferentes acciones dependiendo del intervalo de tiempo que se esté pulsando el botón.
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 21 de octubre de 2015

Conectar un HUB USB a nuestro router OpenWRT para disponer de varios puertos USB

Podemos conectar un HUB USB con alimentación externa a nuestro router OpenWRT para disponer de varios puertos USB a los que conectar diferentes dispositivos. Eso sí, es importante que el HUB disponga de alimentación externa porque si no, no va a funcionar. 


Una vez conectado, instalamos los siguientes paquetes:


Si  nos conectamos al router mediante ssh y ejecutamos:
# dmesg | grep -i hub
Comprobaremos que el hub ha sido detectado por el sistema.

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

Error en Luci "/usr/lib/lua/luci/dispatcher.lua:433: Failed to execute cbi dispatcher target for entry '/admin/system/fstab'."

Si instaláis el soporte para montar dispositivos usb en OpenWRT, puede que al tratar de mostrar los puntos de montaje en Luci,



obtengáis un error como el siguiente: 

 "/usr/lib/lua/luci/dispatcher.lua:433: Failed to execute cbi dispatcher target for entry '/admin/system/fstab'."


Para solucionarlo, no tenéis más que conectaros mediante ssh al router, y crear el archivo /etc/config/fstab:
 

Y el error desaparecerá:



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

Configurar OpenWRT desde Luci para que muestre un led de actividad wifi

OpenWRT por defecto muestra todos los LEDS del router apagados, salvo el de Power. Si utilizáis vuestro router con OpenWRT como cliente wifi de otro, sería interesante usar alguno de los LEDS para mostrar que hay conexión.
En este ejemplo, en un router A4001N he configurado el LED A4001:green:dsl desde el interfaz Luci para que muestre actividad cuando:
  • El enlace esté activado (link).
  • ita (tx).
  • O reciba (rx). 

Una vez seleccionadas las opciones, pulsamos el botón "Guardar y aplicar" y los cambios se aplicarán.

Si echáis un vistazo al archivo /etc/config/system de vuestro router, veréis que las opciones seleccionadas en el interfaz Luci se han traducido en el siguiente bloque de configuración:

config led
        option name 'wifi'
        option sysfs 'A4001N:green:dsl'
        option default '1'
        option trigger 'netdev'
        option dev 'wlan1'
        option mode 'link tx rx'
En este router tengo instalado OpenWRT Chaos Calmer. 
Una cosa que me ha llamado la atención que al especificar que se encienda el LED dsl, lo que se enciende es el LED inet. Supongo que será un bug.
Y otra cosa que también he observado es que no se encuentran definidos todos los LEDS.
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 20 de octubre de 2015

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

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