Algo de Linux: 2017

viernes, 19 de mayo de 2017

Instalar paquetes mediante Chocolatey a través de un proxy de nuestra red

Como ya vimos en posts anteriores es muy sencillo instalar y mantener actualizada una gran cantidad de software en Windows mediante Chocolatey.


Para instalar un paquete en concreto, tan sólo tenemos que utilizar el comando choco install al que pasaremos el nombre del paquete:
C:\> choco install mls-software-openssh
Chocolatey detectará el proxy de nuestra red y lo usará para instalar los paquetes que le pidamos. Ahora bien, en un momento determinado, es posible que nos interese especificar otro proxy diferente del proxy por defecto. Por ejemplo:
C:\> choco install mls-software-openssh --proxy=recursos:3128
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 18 de mayo de 2017

WSUS Offline Update: Solucionar problema de timeout en script DoUpdate.cmd

En mi centro utilizo WSUS Offline Update para descargar las actualizaciones de Windows y Office e instalarlas de forma local, lo que reduce el tiempo de actualización  y el consumo de ancho de banda.

Para descargar las actualizaciones, se utiliza un script que se ejecuta una vez a la semana en el servidor de almacenamiento mediante cron.

Para actualizar los clientes se utiliza un script Doupdate.cmd que se encuentra en el directorio wsusoffline/client/cmd/.

Pues bien, actualizando clientes, observé que tanto al detener el servicio wuauserv, como al iniciarlo o esperar a que estuviera iniciado, siempre se alcanzaba el timeout, lo que retardaba la ejecución un tiempo extra de 180s + 60s.

Esta mañana me puse a ver el código y descubrí dónde estaba el problema: El script está pensado para obtener el estado del servicio filtrando por la palabra "STAT".  Ahora bien, como nuestro sistema se encuentra en español, esa condición no se produce y estaremos esperando hasta que se agote el tiempo definido en el script.
La forma más sencilla de solucionar el problema es cambiar la palabra "STAT" por "ESTADO".

Aquí tenéis la parte del script donde hay que realizar las modificaciones:
:WaitService
echo Waiting for service '%1' to reach state '%2' (timeout: %3s)...
echo %DATE% %TIME% - Info: Waiting for service '%1' to reach state '%2' (timeout: %3s)>>%UPDATE_LOGFILE%
echo WScript.Sleep(2000)>"%TEMP%\Sleep2Seconds.vbs"
for /L %%i in (2,2,%3) do (
  for /F "tokens=4" %%j in ('%SystemRoot%\System32\sc.exe query %1 2^>nul ^| %SystemRoot%\System32\find.exe /I "STAT"') do (
    if /i "%%j"=="%2" (
      echo %DATE% %TIME% - Info: Service '%1' reached state '%2'>>%UPDATE_LOGFILE%
      del "%TEMP%\Sleep2Seconds.vbs"
      goto :eof
    )
  )
  %CSCRIPT_PATH% //Nologo //B //E:vbs "%TEMP%\Sleep2Seconds.vbs"
) 
echo Warning: Service '%1' did not reach state '%2' (timeout occured)
echo %DATE% %TIME% - Warning: Service '%1' did not reach state '%2' (timeout occured)>>%UPDATE_LOGFILE%
del "%TEMP%\Sleep2Seconds.vbs"
verify other 2>nul
goto :eof


:StopWUSvc
for /F "tokens=4" %%i in ('%SystemRoot%\System32\sc.exe query wuauserv 2^>nul ^| %SystemRoot%\System32\find.exe /I "STAT"') do (
  if /i "%%i"=="STOPPED" goto :eof
)
echo Stopping service 'Windows Update' (wuauserv)...
echo %DATE% %TIME% - Info: Stopping service 'Windows Update' (wuauserv)>>%UPDATE_LOGFILE%
%SC_PATH% stop wuauserv >nul 2>&1
if errorlevel 1 (
  echo Warning: Stopping of service 'Windows Update' ^(wuauserv^) failed.
  echo %DATE% %TIME% - Warning: Stopping of service 'Windows Update' ^(wuauserv^) failed>>%UPDATE_LOGFILE%
) else (
  call :WaitService wuauserv STOPPED 30
  if not errorlevel 1 echo %DATE% %TIME% - Info: Stopped service 'Windows Update' ^(wuauserv^)>>%UPDATE_LOGFILE%
)
goto :eof


:StartWUSvc
for /F "tokens=4" %%i in ('%SystemRoot%\System32\sc.exe query wuauserv 2^>nul ^| %SystemRoot%\System32\find.exe /I "STAT"') do (
  if /i "%%i"=="RUNNING" goto :eof
)
echo Starting service 'Windows Update' (wuauserv)...
echo %DATE% %TIME% - Info: Starting service 'Windows Update' (wuauserv)>>%UPDATE_LOGFILE%
%SC_PATH% start wuauserv >nul 2>&1
if errorlevel 1 (
  echo Warning: Starting of service 'Windows Update' ^(wuauserv^) failed.
  echo %DATE% %TIME% - Warning: Starting of service 'Windows Update' ^(wuauserv^) failed>>%UPDATE_LOGFILE%
) else (
  call :WaitService wuauserv RUNNING 30
  if not errorlevel 1 echo %DATE% %TIME% - Info: Started service 'Windows Update' ^(wuauserv^)>>%UPDATE_LOGFILE%
)
goto :eof
Y aquí tenéis esa parte del script en la que he cambiado la palabra "STAT" por "ESTADO":

:WaitService
echo Waiting for service '%1' to reach state '%2' (timeout: %3s)...
echo %DATE% %TIME% - Info: Waiting for service '%1' to reach state '%2' (timeout: %3s)>>%UPDATE_LOGFILE%
echo WScript.Sleep(2000)>"%TEMP%\Sleep2Seconds.vbs"
for /L %%i in (2,2,%3) do (
  for /F "tokens=4" %%j in ('%SystemRoot%\System32\sc.exe query %1 2^>nul ^| %SystemRoot%\System32\find.exe /I "ESTADO"') do (
    if /i "%%j"=="%2" (
      echo %DATE% %TIME% - Info: Service '%1' reached state '%2'>>%UPDATE_LOGFILE%
      del "%TEMP%\Sleep2Seconds.vbs"
      goto :eof
    )
  )
  %CSCRIPT_PATH% //Nologo //B //E:vbs "%TEMP%\Sleep2Seconds.vbs"
) 
echo Warning: Service '%1' did not reach state '%2' (timeout occured)
echo %DATE% %TIME% - Warning: Service '%1' did not reach state '%2' (timeout occured)>>%UPDATE_LOGFILE%
del "%TEMP%\Sleep2Seconds.vbs"
verify other 2>nul
goto :eof


:StopWUSvc
for /F "tokens=4" %%i in ('%SystemRoot%\System32\sc.exe query wuauserv 2^>nul ^| %SystemRoot%\System32\find.exe /I "ESTADO"') do (
  if /i "%%i"=="STOPPED" goto :eof
)
echo Stopping service 'Windows Update' (wuauserv)...
echo %DATE% %TIME% - Info: Stopping service 'Windows Update' (wuauserv)>>%UPDATE_LOGFILE%
%SC_PATH% stop wuauserv >nul 2>&1
if errorlevel 1 (
  echo Warning: Stopping of service 'Windows Update' ^(wuauserv^) failed.
  echo %DATE% %TIME% - Warning: Stopping of service 'Windows Update' ^(wuauserv^) failed>>%UPDATE_LOGFILE%
) else (
  call :WaitService wuauserv STOPPED 30
  if not errorlevel 1 echo %DATE% %TIME% - Info: Stopped service 'Windows Update' ^(wuauserv^)>>%UPDATE_LOGFILE%
)
goto :eof


:StartWUSvc
for /F "tokens=4" %%i in ('%SystemRoot%\System32\sc.exe query wuauserv 2^>nul ^| %SystemRoot%\System32\find.exe /I "ESTADO"') do (
  if /i "%%i"=="RUNNING" goto :eof
)
echo Starting service 'Windows Update' (wuauserv)...
echo %DATE% %TIME% - Info: Starting service 'Windows Update' (wuauserv)>>%UPDATE_LOGFILE%
%SC_PATH% start wuauserv >nul 2>&1
if errorlevel 1 (
  echo Warning: Starting of service 'Windows Update' ^(wuauserv^) failed.
  echo %DATE% %TIME% - Warning: Starting of service 'Windows Update' ^(wuauserv^) failed>>%UPDATE_LOGFILE%
) else (
  call :WaitService wuauserv RUNNING 30
  if not errorlevel 1 echo %DATE% %TIME% - Info: Started service 'Windows Update' ^(wuauserv^)>>%UPDATE_LOGFILE%
)
goto :eof
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 5 de mayo de 2017

Reparación de particiones NTFS en Linux

Algunos usuarios tienen las particiones de sus discos duros externos en formato NTFS  y, si una partición se ha desmontado mal en algún momento, es posible que se necesite ser reparada.

Para reparar particiones NTFS desde linux podemos utilizar en primera instancia la herramienta ntfsfix que vienen en el paquete ntfs-3g. Por ejemplo: Supongamos que estamos tratando de conectar un disco duro que nos está mostrando error al montarse y que tiene una única partición /dev/sdb1. Podríamos chequearlo mediante ntfsfix de la siguiente manera:
# ntfsfix /dev/sdb1
Publicado por primera vez en http://enavas.blogspot.com.es

ntfs-3g: Gestionar particiones NTFS desde Linux

ntfs-3g es una implementación open source del sistema de ficheros NTFS de Microsoft. Para poder trabajar con particiones ntfs en nuestro sistema Ubuntu/Debian, no tenemos más que instalar este paquete:
apt-get install ntfs-3g

Al instalar el paquete, tendremos a nuestra disposición, junto con el driver, una amplia colección de utilidades que nos permiten trabajar con particiones NTFS.

Veamos algunas de las utilidades que nos proporciona este paquete:
  • ntfsfix tal y como dice la ayuda, ntfsfix es una utilidad que arregla algunos problemas comunes en volumenes NTFS.
  • mkntfs nos permite formatear una partición con el sistema de archivos NTFS.
  • ntfsinfo nos permite ver informacion detallada de volumenes NTFS.
  • ntfslabel nos permite ver y cambiar la etiqueta de volumen de una particion NTFS.
  • ntfsresize nos permite redimensionar un volumen NTFS de forma no destructiva, moviendo de forma segura cualquier dato si es necesario.
  • ntfsundelete nos permite recuperar archivos eliminados de una particion NTFS.
  • ntfscluster identifica ficheros en una región específica de un volumen NTFS.
  • ntfscat muestra en pantalla ficheros de volumenes NTFS sin montar la particion.
  • ntfsls lista el contenido de directorios sin montar la particion.
  • ntfscp nos permite copiar ficheros en un volumen NTFS.
  • ntfsclone nos permite clonar volumenes NTFS o una parte de ellos.
Publicado por primera vez en http://enavas.blogspot.com.es

Controlar los clientes Ubuntu de Infolab con Epoptes

Para los que no lo conocen, Epoptes es una herramienta de control de aula GPL bastante sencilla de utilizar que funciona mediante un sistema cliente/servidor y que nos va a permitir:
  • Mostrar la pantalla en los clientes.
  • Supervisarlos.
  • Ejecutar comandos de forma remota.
  • Enviarles mensajes.
  • Aplicar restricciones como por ejemplo el bloqueo del terminal.
  • etc...
Es fácil de implantar. Tan sólo requiere instalar y configurar:
  • El paquete epoptes en el equipo del profesor.
  • El paquete epoptes-client en los equipos de alumnos.
Además, es sencillo de desplegar con un simple módulo puppet que instale y configure tanto el cliente como el servidor.

Para que el profesor pueda controlar el aula, tiene que estar en el grupo por defecto epoptes. No obstante, es posible cambiarlo en el fichero /etc/default/epoptes:
# The port where the server will be listening on, and where the client will try
# to connect to. For security reasons it defaults to a system port, 789.
#PORT=789

# Epoptes server will use the following group for the communications socket.
# That means that any user in that group will be able to launch the epoptes UI
# and control the clients.
#SOCKET_GROUP=epoptes
SOCKET_GROUP=teachers
En el directorio /etc/epoptes del equipo del profesor, donde hemos instalado el paquete epoptes, encontraréis dos ficheros que contienen la clave pública y la clave privada:
# ls -l /etc/epoptes/
total 8
-rw-r--r-- 1 root root 1919 abr 21 13:44 server.crt
-rw------- 1 root root 3272 abr 21 13:44 server.key
Podemos distribuir la clave pública del equipo del profesor (server.crt) a los clientes mediante el módulo puppet que creemos para configurarlo.

Por último, podemos crear un grupo de hosts para cada infolab y copiar la información de grupos a los profesores: $HOME/.config/epoptes/groups.json 

Una vez configurarlo, podremos, encender, apagar y controlar los equipos de alumnos:


Como podéis ver en la siguiente imagen, podemos controlar el equipo de alumno incluso antes de que inicie sesión:


Y veremos qué equipos están encendidos, cuáles se encuentran apagados y quién ha iniciado sesión en un determinado equipo:


Además, podemos conectarnos de forma remota mediante ssh exportando el display y controlaremos el aula desde nuestro equipo de administrador.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 4 de mayo de 2017

Eliminar rutas por defecto cuando tenemos varias interfaces de red

Supongamos que tenemos un equipo con al menos dos interfaces de red... Por ejemplo:
# cat /etc/network/intefaces
auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet dhcp

iface eth1 inet dhcp

Si queremos garantizar que la ruta por defecto sea la de la interfaz eth0, podemos eliminar la ruta por defecto de la interfaz eth1 simplemente añadiendo la línea que he resaltado en color amarillo y que se encarga de eliminarla:
auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet dhcp

iface eth1 inet dhcp
      post-up route del default dev $IFACE
Publicado por primera vez en http://enavas.blogspot.com.es

CUPS Cloud Print: Nueva versión del paquete

Como ya vimos en un post de septiembre de 2015, el paquete cupscloudprint nos permite utilizar impresoras de Google Cloud Print como impresoras locales en nuestro equipo.
El paquete que instalábamos en ese post no funcionaba en versiones más actuales del sistema operativo, por lo que el autor del paquete publicó una nueva versión corrigiendo los problemas. Si queréis, podéis descargarlo con wget:
# wget http://ppa.launchpad.net/simon-cadman/niftyrepo/ubuntu/pool/main/c/cupscloudprint/cupscloudprint_20160502-1_all.deb
E instalarlo directamente:
# dpkg -i cupscloudprint_20160502-1_all.deb
Publicado por primera vez en http://enavas.blogspot.com.es

Warnings "W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169" en Debian

Si tenéis mensajes de warning del tipo: "W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169", lo más probable es que sea porque no tenéis instalado el firmware propietario de Realtek. Podéis instalar este firmware simplemente instalando el paquete firmware-realtek:
# apt-get install firmware-realtek
Publicado por primera vez en http://enavas.blogspot.com.es

Actualizar el kernel a la versión 4 en Debian Jessie

Para actualizar el kernel a la versión 4 en Debian Jessie, debemos utilizar los repositorios de Debian Backports:
# echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" > /etc/apt/sources.list.d/jessie-backports.list
Una vez que tenemos el repositorio, actualizamos índices:
# apt-get update
Una vez actualizado, instalamos el kernel que nos interese. Por ejemplo: Suponiendo que tengo una máquina con un sistema de 32 bits en la que quiero instalar un kernel pae:
# apt-get -t jessie-backports install linux-image-686-pae linux-headers-686-pae
Publicado por primera vez en http://enavas.blogspot.com.es

Drivers de OpenPrinting para Epson WorkForce Pro WF-8590

Epson proporciona un driver GPL para la impresora A3 Epson WorkForce Pro WF-8590 que tenemos en los centros y que funciona perfectamente. Podéis ver más información en la página de OpenPrinting: http://www.openprinting.org/printer/Epson/Epson-WF-8590_Series
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 3 de mayo de 2017

Script desbloquearimpresoras

Para evitar el bloqueo permanente de impresoras, utilizo un script que se ejecuta de forma periódica mediante una tarea cron. Este script evita el bloqueo que se produce en determinadas situaciones.
# cat /usr/local/bin/desbloquearimpresoras
#!/bin/bash
# ------------------------------------------------------------
# script:  /usr/local/bin/desbloquearimpresoras
# Author:  Esteban M. Navas Martín
# Date:    27-04-2014
# Ver:     03-05-2017
#
# Purpose: Unlock printers and jobs

# Copyright (c) 2012-2017 Esteban M. Navas Martín . All rights reserved.
#
#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.

#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#   You should have received a copy of the GNU General Public License
#   along with this program. If not, see .

idioma=$LC_ALL
export LC_ALL=en_US.UTF-8

# Definimos una antiguedad maxima de trabajos de 10 minutos
antiguedad=10

# Obtenemos la lista de impresoras
lpstat -s > /tmp/impresoras

#  Identificar impresoras locales y asegurar que esten operativas
while read linea; do
  impresora=`echo $linea | grep 'device' | awk '{print$3}' | cut -f1 -d":"`
  impresoradesconectada=`lpstat -o -p $impresora | grep Unplugged`
  impresorapausada=`lpstat -o -p $impresora | grep Paused`
  impresorarechazandojobs=`lpstat -o -p $impresora | grep Rejecting`

  if [ "$impresorarechazandojobs" ]; then
     cupsaccept $impresora
  fi

  if [ "$impresorapausada" ]; then
     cupsenable $impresora
  fi

done < /tmp/impresoras

# Obtenemos el estado de los trabajos de las impresoras
lpstat -o | awk '{print$1,$5,$6,$7,$8}'>/tmp/trabajosimpresora

# Procesamos cada trabajo
while read trabajo; do
  impresora=`echo ${trabajo%-*}`
  numtrabajo=`echo ${trabajo##*-} | cut -f1 -d" "`
  fechatrabajo=$(date -d "`echo $trabajo | awk '{print$6,$7,$8}'`" "+%s")
  fechaactual=`date +%s`
  diferencia=$(((fechaactual-fechatrabajo) / 60))
  impresoradesconectada=`lpstat -o -p $impresora | grep Unplugged`

  if [ ! $impresoradesconectada ]; then
     if [ $diferencia -gt $antiguedad ]; then
        cancel $numtrabajo
     fi
  fi

done < /tmp/trabajosimpresora

export LC_ALL=$idioma
Publicado por primera vez en http://enavas.blogspot.com.es

Script limpiarspoolimpresora

Para limpiar el spool de las impresoras, tengo puesto un script muy simple en los clientes que para el servicio, borra el directorio de spool de cups y vuelve a iniciar el servicio:
# cat /usr/local/sbin/limpiarspoolimpresora
#!/bin/bash
service cups stop
rm -r /var/spool/cups/*
service cups start
De este modo, puedo limpiar el spool cuando sea necesario. Publicado por primera vez en http://enavas.blogspot.com.es

Ejecutar un comando en bash con unos locales específicos

En ocasiones nos interesa ejecutar un comando con unos locales específicos. Ésto es algo sencillo de lograr:
LC_ALL=en_US.utf8 lpstat -p
En el ejemplo anterior estamos haciendo que el comando lpstat -p nos muestre la salida del comando en inglés. Publicado por primera vez en http://enavas.blogspot.com.es

martes, 2 de mayo de 2017

systemctl: Gestión de servicios systemd

Systemd es el sistema de inicio que incorpora Debian Jessie, y que, por tanto, tenemos en nuestros servidores. Destaco que es el sistema de nuestros servidores porque nuestros clientes tienen montado Ubuntu Trusty, que utiliza Upstart; si bien es cierto, que cuando pasemos los clientes a Xenial, se homogeinizará un poco el tema puesto que Ubuntu Xenial usa también Systemd. Mientras tanto, debemos tener en cuenta este detalle.

En este post vamos a ver cómo gestionamos servicios en systemd mediante la herramienta systemctl, algo que he notado que muchos compañeros no tiene claro.

En systemd, los servicios se nombran siempre con el sufijo .service

La sintaxis de systemctl a la hora de trabajar con servicios es muy sencilla:
# systemctl acción servicio.service

Donde:
  • acción será la operación a realizar con el servicio.
    • start
    • stop
    • restart
    • reload
    • reload-or-restart
    • status
    • enable
    • disable
    • is-active
    • is-enabled
    • is-failed
  • servicio será el nombre del servicio.
De acuerdo con lo anterior, vamos a ver qué operaciones podemos realizar con un servicio, utilizando a modo de ejemplo, el servicio slapd:

Para iniciar por ejemplo el servicio slapd, ejecutaremos:
# systemctl start slapd.service
Si queréis, podéis omitir el sufijo service a la hora de ejecutar el comando:
# systemctl start slapd
Para parar el servicio slapd, ejecutaremos:
# systemctl stop slapd.service
Para reiniciar el servicio slapd, ejecutaremos:
# systemctl restart slapd.service
Si el servicio dispone de la opción reload, ejecutaremos:
# systemctl reload slapd.service
Si no sabemos si el servicio tiene la función reload, podemos usar la acción reload-or-restart que tratará de recargar la configuración, y, si no es posible, reiniciará el servicio para que la nueva configuración sea aplicada:
# systemctl reload-or-restart slapd.service
Para comprobar el estado del servicio slapd, ejecutaremos:
# systemctl status slapd.service
Notaréis que las líneas largas se cortan. Si queréis mostrar la información completa, tan sólo tenéis que utilizar el parámetro -l:
# systemctl status -l slapd.service
Otro ejemplo: Supongamos que queremos comprobar el estado del servicio pdns.service:
# systemctl status -l pdns.service 
● pdns.service - PowerDNS Authoritative Server
   Loaded: loaded (/lib/systemd/system/pdns.service; enabled)
   Active: active (running) since mar 2017-05-02 18:48:13 CEST; 9s ago
  Process: 21937 ExecStop=/usr/bin/pdns_control quit (code=exited, status=0/SUCCESS)
 Main PID: 21943 (pdns_server)
   CGroup: /system.slice/pdns.service
           ├─21943 /usr/sbin/pdns_server --daemon=no
           └─21947 /usr/sbin/pdns_server-instance --daemon=no

may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 Polled security status of version 3.4.1-4+deb8u7.Debian at startup, no known issues reported: OK
may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 Set effective group id to 119
may 02 18:48:17 servidor pdns[21947]: Set effective user id to 111
may 02 18:48:17 servidor pdns[21947]: DNS Proxy launched, local port 32566, remote 127.0.0.1:1553
may 02 18:48:17 servidor pdns[21947]: Creating backend connection for TCP
may 02 18:48:17 servidor pdns[21947]: [LdapBackend] LDAP servers = ldap://127.0.0.1 ldap://172.19.144.3
may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 Set effective user id to 111
may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 DNS Proxy launched, local port 32566, remote 127.0.0.1:1553
may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 Creating backend connection for TCP
may 02 18:48:17 servidor pdns_server[21943]: May 02 18:48:17 [LdapBackend] LDAP servers = ldap://127.0.0.1 ldap://172.19.144.3
Para activar un servicio que se encuentra desactivado, utilizamos la acción enable:
# systemctl enable slapd.service
Para desactivar un servicio, utilizamos la acción disable:
# systemctl disable slapd.service
Para comprobar si un servicio se encuentra activo:
# systemctl is-active slapd.service
Ahora bien, si lo que queremos es comprobar si un servicio se encuentra activado:
# systemctl is-enabled slapd.service
Del mismo modo, podemos comprobar si un servicio está fallando:
# systemctl is-failed slapd.service
Esta comprobación nos devolverá "active" si el servicio está corriendo perfectamente y "failed" si ocurrió algún error. Publicado por primera vez en http://enavas.blogspot.com.es

domingo, 30 de abril de 2017

Sincronizar clientes puppet de forma periódica mediante cron en los IES

En nuestros centros decidieron que era conveniente ejecutar puppet solamente una vez en cada arranque del cliente, siempre y cuando  haya transcurrido un tiempo mínimo entre sincronizaciones definido por la variable INTERVAL en el fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default

Esta configuración me parece adecuada para máquinas que no se encuentran conectadas permanentemente a la red, como por ejemplo, portátiles cuyo acceso es vía wifi. Ahora bien, en mi opinión, en máquinas conectadas a la red mediante cable, debería ejecutarse puppet de forma periódica. Ésto es algo muy sencillo de realizar con tan sólo definir un recurso cron que programe una tarea cron en dichas máquinas:
cron { 'puppet-cron':
    ensure => present,
    command => 'if [ $(pgrep -c "^puppet$") -eq 0 ]; then /usr/sbin/sinc_puppet -f;fi',
    user => 'root',
    hour => "*/$puppet_interval",
    minute => '0',
}
Como podéis ver, defino una tarea cron que se ejecuta como root e inicia el script /usr/sbin/sinc_puppet si no está corriendo puppet en el intervalo definido por la variable INTERVAL en el fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default

Es importante destacar que puppet es capaz de obtener el valor de la variable INTERVAL almacenado en el fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default del fact puppet_inteval creado por el fichero ruby readsincpuppetconfig.rb que convierte en facts los valores definidos en este fichero de configuración. Lo que significa que es necesario haber distribuido previamente el fichero readsincpuppetconfig.rb a vuestros clientes (ver el siguiente post: https://enavas.blogspot.com.es/2017/04/convertir-en-facts-los-valores.html).  

Podríamos establecer el intervalo horario de forma fija en el recurso cron, pero al hacerlo de este modo, siempre que cambiemos el valor INTERVAL, en el fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default se modificará automáticamente en el recurso para el valor de periodicidad coincida.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 27 de abril de 2017

Convertir en facts los valores definidos en fichero de configuración /etc/default/pkgsync

He creado un nuevo fichero ruby (readpkgsyncconfig.rb) que convierte las variables definidas en el fichero de configuración /etc/default/pkgsync en variables facter con tan sólo colocarlo en el directorio /usr/lib/ruby/vendor_ruby/facter/ de los clientes.

Podéis descargarlo directamente en vuestro servidor:
# wget --no-check-certificate -O readpkgsyncconfig.rb https://github.com/algodelinux/facter/raw/master/readpkgsyncconfig.rb
Y distribuirlo a vuestros clientes mediante puppet.

Aquí podéis ver el código completo: Una vez distribuido el fichero readpkgsyncconfig.rb a los clientes, podéis consultar las variables facter generadas a partir del fichero de configuración:
# facter |grep "pkgsync_"

pkgsync_clean => no
pkgsync_enable => yes
pkgsync_ignore_mayhave => no
pkgsync_ignore_maynothave => no
pkgsync_ignore_musthave => yes
pkgsync_launch_sinc_puppet => yes
pkgsync_launchpad_getkeys => no
pkgsync_purge_old_kernels => no
pkgsync_remove_orphan_libs => no
pkgsync_timeout_for_dpkg_or_apt => 3m
Publicado por primera vez en http://enavas.blogspot.com.es

Convertir en facts los valores definidos en fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default

He creado un nuevo fichero ruby (readsincpuppetconfig.rb) que convierte las variables definidas en el fichero de configuración /usr/share/linex-ubuntu-puppet/sincpuppet.default en variables facter con tan sólo colocarlo en el directorio /usr/lib/ruby/vendor_ruby/facter/ de los clientes.

Podéis descargarlo directamente en vuestro servidor:
# wget --no-check-certificate -O readsincpuppetconfig.rb https://github.com/algodelinux/facter/raw/master/readsincpuppetconfig.rb
Y distribuirlo a vuestros clientes mediante puppet.

Aquí podéis ver el código completo: Una vez distribuido el fichero readsincpuppetconfig.rb a los clientes, podéis consultar las variables facter generadas a partir del fichero de configuración:
# facter |grep "puppet_"

puppet_enable => yes
puppet_interval => 2
puppet_locales => es_ES.UTF-8
puppet_ping_interval => 30
puppet_ping_server => puppetinstituto
puppet_ping_tries => 3
puppet_splaylimit => 3m
puppet_waitforcert => 30
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 26 de abril de 2017

sed: Extraer el valor de una variable com la forma variable="valor" de un fichero de configuración

Supongamos que tenemos un fichero de configuración como /etc/default/sincpuppet en el que existen definiciones de variables como las siguientes:
# grep -v -e "#" -e "^$" /etc/default/sincpuppet
 
LOCALES="es_ES.UTF-8"
ENABLE="yes"
PING_SERVER="puppetinstituto"
PING_TRIES="3"
SPLAYLIMIT="3m"
WAITFORCERT="30"
Podemos extraer el valor de cada variable utilizando el comando sed como en el siguiente ejemplo, donde extraemos el valor de la variable INTERVAL:
# sed -n 's|^INTERVAL="\(.*\)".*|\1|p' /etc/default/sincpuppet
Publicado por primera vez en http://enavas.blogspot.com.es

Puppet: Asegurar que un fichero existe y se encuentre vacío

Podemos asegurar que un fichero existe utilizando la propiedad:
ensure => present
Ahora bien, si además queremos asegurar que el fichero se encuentra vacío, podemos utilizar la propiedad :
content =>""
file { "/etc/resolvconf/resolv.conf.d/base":
  ensure => present,
  content => "",
}
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 20 de abril de 2017

Establecer la impresora por defecto mediante comandos

Si queremos ver qué impresoras tenemos configuradas en un equipo desde la línea de comandos, no tenemos más que ejecutar:
# lpstat -p
Ahora bien, si lo que nos interesa es saber cuál es la impresora predeterminada, lo que tenemos que usar es el parámetro -d:
# lpstat -d
Y si lo que queremos es establecer una impresora como predeterminada haremos uso de lpadmin:
# lpadmin -d "nombre-impresora"
Sabiendo ésto, podemos configurar fácilmente una impresora como pretederminada mediante puppet. Por ejemplo:
exec { "lpadmin -d Copiadora_BN":
       unless => "lpstat -d | grep Copiadora_BN"
}
Publicado por primera vez en http://enavas.blogspot.com.es

Configuración para que Arduino IDE contacte con la placa Arduino

En febrero preparé un paquete que nos permite instalar Arduino IDE en nuestros equipos. Si tenéis problemas para que el entorno de desarrollo se comunique con la placa Arduino, probablemente sea porque no habéis añadido vuestro usuario al grupo dialout. La forma más sencilla de que todos nuestros usuarios tengan dicho grupo es añadirlo al archivo /etc/security/group.conf:
*;*;*;Al0000-2400;audio,cdrom,floppy,plugdev,video,lp,lpadmin,netdev,games,fuse,dialout
Publicado por primera vez en http://enavas.blogspot.com.es

Utilizar dig para testear resolución de nombres

dig es una herramienta muy útil para testear resolución de nombres.

Esta herramienta se encuentra disponible en el paquete dnsutils. Si lo no tenéis instalado, podéis hacerlo fácilmente desde los repositorios:
# apt-get install dnsutils
Una vez instalado, podéis hacer una consulta sobre un nombre de host:
# dig a25-pro.valledeljerte3
O sobre una dirección IP:
# dig -x 172.19.144.106
Si tenéis varios servidores DNS y queréis consultar a uno en concreto:
# dig @ip-servidor-dns a25-pro.valledeljerte3
Por ejemplo:
# dig @172.19.144.4 a25-pro.valledeljerte3
Publicado por primera vez en http://enavas.blogspot.com.es

Optimización de resolución de nombres en clientes

Como ya he comentado en varias ocasiones, en mi centro tengo configurados dos servidores de nombres en la vlan por defecto:
search valledeljerte3
nameserver 172.x.y.3
nameserver 172.x.y.2
Si configuro los clientes para que utilicen solamente mis dos servidores de nombres, sería interesante añadir la opción "options rotate" al fichero /etc/resolv.conf de los clientes para repartir la carga de las consultas entre los diferentes servidores DNS.

Por otra parte, también al tener dos servidores, sería interesante reducir el timeout de las consultas DNS, de manera que si un servidor de nombres no responde, se tarde menos en consultar al siguiente. Para ello, utilizaremos la opción timeout, reduciendo por ejemplo el tiempo de espera a 1 segundo: "options timeout:1"

Por último, también sería útil reducir el número de intentos por servidor. Por ejemplo: "options attempts:1".

Nuestros clientes Ubuntu tienen instalado el paquete resolvconf. Así que podemos aplicar dichas opciones simplemente añadiendo la línea siguiente al fichero de configuración /etc/resolvconf/resolv.conf.d/base:
options timeout:1 attempts:1 rotate
Y ejecutar el siguiente comando para actualizar el fichero /etc/resolv.conf:
# resolvconf -u
Una vez hecho ésto, podemos comprobar que la línea se ha añadido al fichero /etc/resolv.conf.

Realizar estos cambios en los clientes mediante puppet, no tiene ninguna dificultad:
   file { '/etc/resolvconf/resolv.conf.d/base':
      content => 'options timeout:1 attempts:1 rotate',
      notify => Exec ['update-resolvconf']
   }

   exec { 'update-resolvconf':
      command => 'resolvconf -u',
      refreshonly => true
   }
Publicado por primera vez en http://enavas.blogspot.com.es

Orden de los servidores de nombres en /etc/resolv.conf

Supongamos que tenemos un /etc/resolv.conf como el siguiente en nuestros clientes:
search valledeljerte3
nameserver 172.x.y.3
nameserver 172.x.y.2
Las entradas nameserver nos permiten especificar diferentes direcciones de servidores de nombres que podrían ser consultados por el resolver.

De acuerdo con la ayuda (man resolv.conf), se listan hasta un máximo de MAXNS (actualmente 3) servidores de nombre, uno por palabra clave. 

Si en el fichero de configuración incluimos múltiples servidores de nombres, como en el ejemplo inicial, la biblioteca resolver los consultará en el orden listado. No obstante, es posible modificar ese comportamiento haciendo que se consulten mediante un mecanismo round-robin incluyendo la siguiente opción en el fichero de configuración:
options rotate
Lo que nos aporta esta opción es repartir la carga de las consultas entre los diferentes servidores DNS.
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar manpages 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.

Si hacéis un dpkg -l | grep manpages, comprobaréis que al menos se encuentra instalado en el sistema el paquete manpages, que contiene las páginas de ayuda en inglés.

Si queréis disponer de las páginas de ayuda en español tanto en Ubuntu como en Debian, tan sólo tenéis que instalar dos paquetes:
  • manpages-es
  • manpages-es-extra
# apt-get install manpages-es manpages-es-extra
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 19 de abril de 2017

Limpiar la cache de squid3 de nuestro servidor Debian Jessie

Podemos limpiar fácilmente la caché de squid3 de la siguiente manera:

Primero.- Paramos el servicio squid3:
# systemctl stop squid3.service
Segundo.- Borramos el contenido de la caché:
rm -Rf /var/spool/squid3/*
Tercero.- Regeneramos la estructura de directorios de la caché:
# squid3 -z
Cuarto.- Iniciamos el servicio squid3:
# systemctl start squid3.service
Podemos convertir estos cuatro pasos en un script para simplificar nuestra tarea: Podéis instal este script fácilmente en vuestro servidor con tan sólo ejecutar los siguientes comandos:
# wget --no-check-certificate -O /usr/local/sbin/clean-squid3-cache https://github.com/algodelinux/clean-squid3-cache/raw/master/clean-squid3-cache
# chmod 755 /usr/local/sbin/clean-squid3-cache
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 18 de abril de 2017

Instalar Master PDF Editor en Debian Jessie

Master PDF Editor es una excelente herramienta para editar ficheros PDF en Linux, Windows o Mac OS X que se encuentra disponible tanto en versión comercial como free.

Como ya comentamos en el post donde explicábamos como instalarlo en Ubuntu, la versión free tan sólo puede utilizarse con fines no comerciales, como por ejemplo, para propósitos educativos o uso en casa y tiene algunas funciones bloqueadas:
  • "Paste to Multiple Pages"
  • "Save Optimized As..."
  • "Document Actions"
  • "Document JavaScript"
  • "Page Properties"
  • "Signing PDF with digital signature"
Si queréis disponer de estas funciones, tendréis que adquirir una licencia. 

Instalarlo en Debian Jessie es sencillo:

Primero.- Descargamos el paquete, que se encuentra disponible tanto para 32 como 64 bits, desde el sitio web. Por ejemplo:
# wget http://get.code-industry.net/public/master-pdf-editor-4.1.30_qt5.amd64.deb
La 4.1.30 es la última versión disponible a día de hoy.

Segundo.- Instalamos el paquete:
# dpkg -i master-pdf-editor-4.1.30_qt5.amd64.deb
Tercero.- Y por último, instalamos sus dependencias:
# apt-get -f install
Publicado por primera vez en http://enavas.blogspot.com.es

clean-homes: Script para hacer limpieza en homes de alumnos y/o profesores mediante Bleachbit

En un post del 6 de abril, hablamos de BleachBit, una interesante herramienta que nos permite hacer limpieza y liberar espacio en disco.

Para liberar espacio en el servidor nfs del centro, escribí un script (clean-homes) con el que liberar espacio en los directorios HOME de profesores y/o alumnos haciendo uso de BleachBit.

Podéis instalarlo fácilmente en vuestro servidor con tan sólo ejecutar los siguientes comandos:
# wget --no-check-certificate -O /usr/local/sbin/clean-homes https://github.com/algodelinux/clean-homes/raw/master/clean-homes
# chmod 755 /usr/local/sbin/clean-homes
Aquí podéis ver el código completo: El script es muy sencillo de utilizar. Tan sólo tendremos que indicar si deseamos limpiar homes de alumnos, profesores o todos:
# clean-homes -c profesor
# clean-homes --clean profesor
# clean-homes -c alumnos
# clean-homes --clean alumnos
# clean-homes -c all
# clean-homes --clean all
No olvidéis que debéis instalar el paquete bleachbit en el servidor. Publicado por primera vez en http://enavas.blogspot.com.es

Puppet: Asegurar que un servicio está corriendo

Si administráis un entorno de clientes Ubuntu Trusty y Xenial o incluso Debian mediante Puppet, habréis notado que en algún caso, al aplicar algún módulo que gestiona un servicio, Puppet no encuentra el servicio. 

En ese caso, lo más probable es que debamos cambiar el proveedor del servicio por defecto. Ésto es algo muy sencillo de lograr, puesto que el recurso puppet "service" nos proporciona una propiedad "provider" con la que podemos indicar al servicio qué proveedor debe utilizar.

Teniendo en cuenta lo anterior, en nuestros módulos podemos distinguir tipos de máquinas en función del facter $lsbdistcodename para asegurar que el servicio esté corriendo con un proveedor diferente para cada tipo de máquina. Por ejemplo:

   case $lsbdistcodename {
      'trusty': {
         service { "ntp":
            provider => 'upstart',
            ensure => running
         }
      }
      default: {
         service { "ntp":
            provider => 'systemd',
            ensure => running
         }
      }
   }
Ésto me permitiría usar "systemd" como proveedor de servicio por defecto (algo necesario para máquinas con Debian Jessie o Ubuntu Xenial, que utilizan systemd) y "upstart" como proveedor de servicio para "trusty".
Publicado por primera vez en http://enavas.blogspot.com.es

Reempaquetar un paquete instalado en el sistema

Alguien me preguntaba cómo podía obtener un paquete que ya no encontraba en los repositorios pero que tenía instalado en su máquina. La solución es sencilla: Haciendo uso de dpkg-repack.

Éste es un post que publiqué en 2013 y que quizás alguien haya descartado por ser antiguo. Lo vuelvo a publicar tal cual porque sigue funcionando.

A veces hemos instalado algún software en nuestro sistema y, a pesar de que sigue instalado, ya no disponemos del paquete con el que lo hemos instalado, sea porque ya no se encuentra en los repositorios, no tenemos actualmente configurados los repositorios desde los que lo instalamos, es un paquete que creamos nosotros mismos y lo hemos perdido, etc... En este caso, podemos volver a crear el paquete haciendo uso de una herramienta muy útil para estos casos: dpkg-repack.

Veamos cómo usarla con un ejemplo:

Supongamos que hace tiempo instalamos en nuestro sistema el paquete gpdftk, queremos instalarlo en otra máquina y no sabemos de dónde sacarlo.

Primero instalamos los paquetes fakeroot y dpkg-repack:
# apt-get -y install fakeroot dpkg-repack

Una vez instalados, no tenemos más que usarlos:
$ fakeroot -u dpkg-repack  gpdftk

Y de este modo tan sencillo, obtendremos el paquete gdftk.
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 14 de abril de 2017

El comando ls: Listar ficheros ordenados por fecha de modificación

Podemos listar ficheros ordenando la salida por fecha de modificación y mostrando los más nuevos primero mediante el parámetro -t del comando ls:
# ls -lt
Y si queremos mostrar una ordenación inversa (los más antiguos primero), tan sólo tenemos que añadir el parámetro -r al comando anterior:
# ls -ltr
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 6 de abril de 2017

Bleachbit: Una herramienta Opensource muy útil para liberar espacio en disco

BleachBit es una interesante herramienta que nos va a permitir hacer limpieza y liberar espacio en disco. Tres de sus principales ventajas frente a otras herramientas de propósito similar son:
  • Es OpenSource.
  • Se encuentra disponible tanto para Linux como para Windows. 
  • Podemos utilizarlo mediante su interfaz gráfica o desde la línea de comandos.
Con BleachBit podemos: Liberar espacio de caché, eliminar cookies, borrar el historial de los navegadores, triturar archivos para evitar su recuperación una vez borrados, etc...

Instalarlo tanto en Debian como en Ubuntu es realmente trivial puesto que se encuentra en los repositorios: 
# apt-get update && apt-get -y install bleachbit
Un ejemplo de limpieza de la caché del sistema, los paquetes de idioma, la papelera y archivos temporales:
# bleachbit --clean system.cache system.localizations system.trash system.tmp
Publicado por primera vez en http://enavas.blogspot.com.es

El comando find: Buscar archivos modificados en las últimas 24 horas

Podemos buscar los archivos modificados en las últimas 24 horas simplemente utilizando el comando find:
# find directorio-de-busqueda -mtime -1 -type f 
Ejemplo:
# find /usr/local/sbin/ -mtime -1 -type f 
Es importante decir que el símbolo "-" significa que el archivo cambió en un día o menos.
Si utilizamos el símbolo "+" estaremos buscando archivos que hayan cambiado en un día o mas.
Y si no utilizamos ningún símbolo, estaremos indicando que queremos buscar archivos que hayan cambiado exactamente en un día.

martes, 4 de abril de 2017

Lyx: "Package babel Error: You haven't specified a language option" al generar documento PDF

Al tratar de generar un documento PDF escrito en otra máquina con Lyx me aparecía el siguiente error:
Package babel Error: You haven't specified a language option
La solución ha sido instalar el paquete texlive-lang-spanish:
# apt-get install texlive-lang-spanish
Publicado por primera vez en http://enavas.blogspot.com.es

Pulseaudio: Configurar salida de audio combinada

Todos hemos tenido problemas con usuarios a los que, por alguna razón que desconozco, se les cambia la salida de audio de analógica a hdmi y deja de escucharse el sonido. 

Una de las soluciones para resolver el problema consiste en deshabilitar el perfil de audio HDMI. Otra, sería habilitar la salida de audio combinada a todos los dispositivos. Esta segunda posibilidad es la que yo he decidido aplicar. Para ello, no tenemos más que añadir la siguiente línea al final del fichero de configuración /etc/pulse/default.pa:
load-module module-combine-sink sink_name=combined
Una vez añadida, reiniciamos pulseaudio:
# killall pulseaudio
Convertir ésto en un módulo puppet es muy sencillo. Os muestro a continuación cómo habría que crear la clase:
# cat /etc/puppet/modules/pulseaudio/manifests/init.pp 
class pulseaudio {

   file { '/etc/pulse/default.pa':
      source => "puppet:///modules/pulseaudio/default.pa",
      owner => root, group => root, mode => 644,
      notify => Exec ['restart_pulseaudio']
   }

   exec { 'restart_pulseaudio':
      command => '/usr/bin/killall pulseaudio',
      refreshonly => true
   }
}
No olvidéis colocar el fichero default.pa modificado en el directorio files del módulo puppet.
Publicado por primera vez en http://enavas.blogspot.com.es

domingo, 2 de abril de 2017

Detectar y matar procesos zombie en nuestro sistema

Un proceso zombie es un proceso que ha terminado pero sigue apareciendo en la tabla de procesos. Para detectar si en nuestro sistema hay procesos zombie, podemos ejecutar la siguiente combinación de comandos:
# ps -A -ostat,ppid | awk '/[zZ]/{print $2}')
Un proceso zombie ya es un proceso muerto, y, por tanto, no se le puede matar. Así que, si matamos al proceso padre conseguiremos eliminar el hijo. Para eliminar los procesos zombie, añadiremos un kill a la secuencia de comandos anterior:
# kill $(ps -A -ostat,ppid | awk '/[zZ]/{print $2}')
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 29 de marzo de 2017

Controlar el acceso de usuarios al equipo vía lightdm

pam_access es el módulo pam que nos permite realizar un control de acceso al equipo. 

En este post nos vamos a centrar tan sólo en ver la configuración que debemos aplicar para controlar qué usuarios pueden hacer login vía lightdm. Para lograrlo, tan sólo vamos a tocar dos ficheros:
  • /etc/pam.d/lightdm (donde habilitaremos el uso del módulo pam_access desde lightdm)
  • /etc/security/access.conf (donde definiremos las reglas de acceso)
Como podéis comprobar, en el fichero /etc/pam.d/lightdm de nuestros clientes Ubuntu no se está utilizando el módulo pam_access:
# nano /etc/pam.d/lightdm
#%PAM-1.0
auth    requisite       pam_nologin.so
auth    sufficient      pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
auth    optional        pam_gnome_keyring.so
auth    optional        pam_kwallet.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
#session required        pam_loginuid.so
session required        pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional        pam_gnome_keyring.so auto_start
session optional        pam_kwallet.so auto_start
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-password
Para habilitarlo, añadimos la siguiente línea al fichero de configuración /etc/pam.d/lighdm:
account  required       pam_access.so
Es importante destacar que debemos añadirla en el lugar que se muestra en el siguiente fichero:
# nano /etc/pam.d/lightdm
#%PAM-1.0
auth    requisite       pam_nologin.so
auth    sufficient      pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
auth    optional        pam_gnome_keyring.so
auth    optional        pam_kwallet.so
account  required       pam_access.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
#session required        pam_loginuid.so
session required        pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional        pam_gnome_keyring.so auto_start
session optional        pam_kwallet.so auto_start
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-password
Una vez añadida, no tenemos más que editar el fichero /etc/security/access.conf para insertar las reglas de acceso que queramos.
No vamos a entrar en muchos detalles sobre cómo deben añadirse las reglas de accceso a este fichero, puesto que está bastante claro en los comentarios que vienen dentro del mismo, pero sí vamos a destacar lo más importante:
  • Cualquier línea que comience por el símbolo "#" se considera un comentario.
  • El orden en que definamos reglas de acceso es importante, puesto que se examinarán de arriba a abajo.
  • Cada regla se compone de tres campos separados por el símbolo ":"
    • permisos : usuarios : orígenes
  • El primer campo debería ser:
    • Un símbolo "+" para conceder acceso.
    • Un símbolo "-" para denegar acceso.
  • El segundo campo debe ser una lista de uno o más nombres de usuarios, de grupos o la palabra reservada ALL que representa a todos. Es posible indicar un patrón del tipo usuario@host para controlar el acceso de un usuario en concreto desde un determinado host.
  • El tercer campo debe ser una lista de uno o más nombres de terminal que indican un acceso local, nombres de hosts, nombres de dominio (comenzando por ".") direcciones de hosts, la palabra reservada ALL que representa a todos, la palabra reservada NONE que representa que no se está usando un terminal o el login no es de red o la palabra reservada LOCAL que representa cualuquier cadena que con contenga un carácter "."
  • Además podemos utilizar el operador EXCEPT para especificar excepciones en las reglas
Veamos unos ejemplos sencillos:

Supongamos que queremos denegar el acceso a todos los usuarios excepto a aquellos cuyo nombre sea teachers o pertenezcan al grupo teachers:
- : ALL EXCEPT teachers : ALL
Ahora bien, si lo que nos interesa es denegar el acceso a todos los usuarios excepto a aquellos que pertenezcan al grupo teachers, eliminando la posiblidad de que pueda hacer login un usuario con el nombre teachers, colocaremos el nombre entre paréntesis:
- : ALL EXCEPT (teachers) : ALL
Si queremos añadir  más usuarios y/o grupos a la regla, no tenemos más que separarlos por espacios. Por ejemplo, supongamos que nos interesa que el usuario root también pueda acceder al equipo:
- : ALL EXCEPT (teachers) root : ALL
Como ya comenté en el post anterior, utilizo un módulo puppet al que he llamado (linex-config-ldapclient) para gestionar los ficheros de configuración que establece el paquete linex-config-ldapclient. Podríamos usarlo también para gestionar los ficheros /etc/pam.d/lightdm y /etc/security/access.conf
Publicado por primera vez en http://enavas.blogspot.com.es

Configuración de ldap en clientes del IES

Para configurar los equipos de los centros como clientes ldap,  se utiliza el paquete linex-config-ldapclient:
# dpkg -l|grep linex-config-ldapclient
ii  linex-config-ldapclient                     0.5                                     all          linex ldap autentication and mount system.
Tan sólo tenéis que examinar el paquete para ver qué ficheros se modifican y cómo se realiza la configuración. 
# tree /usr/share/linex-config-ldapclient/
/usr/share/linex-config-ldapclient/
├── actualiza_cache_passwd
├── autofs-restart
├── group.conf
├── ldap.conf
├── nslcd.conf
├── nsswitch.conf
├── nsswitch.conf.dpkg-dist
├── nsswitch.conf.lwidentity.bak
├── nsswitch.conf.lwidentity.orig
├── pam.d
│   ├── common-account
│   ├── common-auth
│   ├── common-password
│   ├── common-session
│   ├── common-session-noninteractive
│   └── gdm3-autologin
└── update_cache_passwd
Una cosa que debéis tener en cuenta es que los ficheros de configuración se colocan en /usr/share/linex-config-ldapclient/ y en el directorio donde debería ir el fichero, lo que se hace es un enlace al fichero ubicado en el directorio anterior. Por ejemplo:
# ls -l /etc/nsswitch.conf
lrwxrwxrwx 1 root root 48 jul 19  2016 /etc/nsswitch.conf -> /usr/share/linex-config-ldapclient/nsswitch.conf

# ls -l /etc/ldap/ldap.conf
lrwxrwxrwx 1 root root 44 mar 28 13:22 /etc/ldap/ldap.conf -> /usr/share/linex-config-ldapclient/ldap.conf

# ls -l /etc/nslcd.conf
lrwxrwxrwx 1 root root 45 mar 28 13:21 /etc/nslcd.conf -> /usr/share/linex-config-ldapclient/nslcd.conf
Ésta es una cuestión importante que debéis tener en cuenta. Evitaréis problemas colocando los ficheros de configuración en la ubicación correcta.

Por si os sirve la idea, yo utilizo un módulo puppet al que he llamado del mismo modo (linex-config-ldapclient) para gestionar estos ficheros de configuración. De momento, tan sólo controla tres ficheros (ldap.conf, nslcd.conf y group.conf), básicamente porque en los clientes defino como servidores ldap a los que consultar, el principal y una de las réplicas de ldap que tengo montadas en el centro; y porque necesitaba asignar el grupo dialout a los clientes para que pudieran utilizar arduino.
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 28 de marzo de 2017

Expulsar a un usuario del sistema

Hay varias formas de "expulsar" a un usuario del sistema. Una de las más sencillas consiste en usar el comando pkill, que sirve para matar procesos.

Primero.- Nos conectamos mediante ssh a la máquina donde queremos cerrar la sesión de usuario.

Segundo.- Comprobamos qué usuarios y en qué terminal han iniciado sesión:
root@a22-pro:~# who
ponente  :0           2017-03-28 12:27 (:0)
root     pts/0        2017-03-28 12:25 (recursos.valledeljerte3)
Como podéis ver en el ejemplo anterior, hay dos usuarios:
  • El usuario ponente, que ha iniciado sesión en el terminal gráfico.
  • El usuario root, conectado de forma remota desde la máquina recursos.valledeljerte3. Este usuario es el que he usado para conectarme remotamente y cerrar la sesión del usuario ponente.
Tercero.- Matamos todos los procesos del usuario ponente haciendo uso del parámetro -u, y con eso habremos cerrado su sesión:
root@a22-pro:~# pkill -u ponente
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 27 de marzo de 2017

CUPS: Reconfigurar para que muestre el nombre de usuario que imprime cada trabajo

Si accedemos al interfaz de administración de CUPS, podemos obtener información acerca de los trabajos enviados a la impresora:
  • El usuario que realizó la impresión.
  • El nombre del trabajo.
  • Fecha y hora de impresión.
  • Cantidad de páginas impresas.
Ahora bien, en la configuración por defecto de CUPS no se muestra el nombre de usuario que realizó la impresión, y, en su lugar, se muestra un mensaje como el siguiente:
{job_originating_user_name}
Para modificar este comportamiento, tan sólo tenemos que cambiar el valor del parámetro JobPrivateValues en el fichero de configuración /etc/cups/cupsd.conf
JobPrivateValues default
Por:
JobPrivateValues none
Publicado por primera vez en http://enavas.blogspot.com.es

CUPS: Cambiar la interfaz de escucha

Si os fijáis en el fichero de configuración /etc/cups/cupsd.conf, por defecto, CUPS escucha solamente conexiones desde la máquina local:
# Only listen for connections from the local machine.
Listen localhost:631
Podemos cambiar este valor para hacer que escuche en una determinada interfaz. Por ejemplo:
Listen 192.168.0.10:631
O incluso, que escuche en todas las interfaces. Algo interesante cuando tenemos varias redes y queremos que nuestro servidor de impresión preste servicio en varias de ellas:
Listen *:631
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 17 de marzo de 2017

tr: Concatenar las líneas de un archivo en una sola

A veces, un comando no tiene un parámetro que permita tomar los datos desde un fichero y necesitamos obtener los datos del fichero en una sola línea. 
La forma más sencilla de hacerlo es usar el comando tr para transformar cada carácter de nueva línea en un espacio: tr '\n' ' ' 

Un ejemplo:
# cat /etc/dsh/machines.list | tr '\n' ' '
Publicado por primera vez en http://enavas.blogspot.com.es

nmap: Excluir del escaneo una serie de máquinas mediante un fichero

Es posible excluir del escaneo una serie de máquinas mediante un fichero si utilizamos el parámetro:
 --excludefile.

Un ejemplo:
# nmap -e eth1 -p 135 192.168.100.0/22 --excludefile=/tmp/noscan
Publicado por primera vez en http://enavas.blogspot.com.es

nmap: Detectar el sistema operativo instalado en una máquina

En versiones recientes de nmap, podemos utilizar el parámetro -A para tratar de detectar el sistema operativo instalado en una máquina. Por ejemplo:
# nmap -v -A 192.168.101.16

Starting Nmap 6.47 ( http://nmap.org ) at 2017-03-17 10:53 CET
NSE: Loaded 118 scripts for scanning.
NSE: Script Pre-scanning.
Initiating ARP Ping Scan at 10:53
Scanning 192.168.101.16 [1 port]
Completed ARP Ping Scan at 10:53, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 10:53
Completed Parallel DNS resolution of 1 host. at 10:53, 5.50s elapsed
Initiating SYN Stealth Scan at 10:53
Scanning 192.168.101.16 [1000 ports]
Discovered open port 22/tcp on 192.168.101.16
Discovered open port 135/tcp on 192.168.101.16
Completed SYN Stealth Scan at 10:53, 19.44s elapsed (1000 total ports)
Initiating Service scan at 10:53
Scanning 2 services on 192.168.101.16
Completed Service scan at 10:53, 6.01s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against 192.168.101.16
Retrying OS detection (try #2) against 192.168.101.16
NSE: Script scanning 192.168.101.16.
Initiating NSE at 10:54
Completed NSE at 10:54, 4.05s elapsed
Nmap scan report for 192.168.101.16
Host is up (0.00052s latency).
Not shown: 998 filtered ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 7.4 (protocol 2.0)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
135/tcp open  msrpc   Microsoft Windows RPC
MAC Address: 50:65:F3:2D:38:BB (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|router|firewall
Running (JUST GUESSING): FreeBSD 6.X (93%), Juniper JUNOS 9.X|10.X|12.X (87%), m0n0wall FreeBSD (87%), Netasq embedded (87%)
OS CPE: cpe:/o:freebsd:freebsd:6.2 cpe:/o:juniper:junos:9 cpe:/o:m0n0wall:freebsd cpe:/o:juniper:junos:10 cpe:/o:juniper:junos:12 cpe:/h:netasq:u70
Aggressive OS guesses: FreeBSD 6.2-RELEASE (93%), Juniper Networks JUNOS 9.0R2.10 (87%), m0n0wall 1.3b11 - 1.3b15 FreeBSD-based firewall (87%), Juniper SRX100-series or SRX200-series firewall (JUNOS 10.4 - 12.1) (87%), Netasq U70 firewall (87%), FreeBSD 6.3-RELEASE (86%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 1.977 days (since Wed Mar 15 11:26:54 2017)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

TRACEROUTE
HOP RTT     ADDRESS
1   0.52 ms 192.168.101.16

NSE: Script Post-scanning.
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 40.27 seconds
           Raw packets sent: 3108 (141.968KB) | Rcvd: 42 (2.128KB)
En este caso, como podemos comprobar, el sistema operativo de la máquina detectada es Windows: Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 16 de marzo de 2017

Añadir el módulo zentyal-radius con mschap a zentyal 4.2

Por alguna razón, los desarrolladores de Zentyal decidieron quitar el soporte de radius a partir de la versión 4.0 de Zentyal Community Edition, que por cierto, en versiones posteriores pasaron a llamar Zentyal Development Edition.

Si queréis añadir el soporte para radius en versiones 4.0, 4.2 o 5.0, podéis recurrir al foro de Zentyal, donde el usuario julio tiene publicadas las instrucciones para descargar el código del módulo zentyal-radius_3.5.1, aplicarle un parche que lo adapta a las siguientes versiones y volver a construir el paquete.

Siguiendo sus instrucciones, he generado el paquete que instala el módulo en la versión 4.2 y funciona perfectamente:
# sudo apt-get install zbuildtools build-essential fakeroot dpkg-dev -y
# mkdir ~/tmp
# cd ~/tmp
# wget 'http://archive.zentyal.org/zentyal/pool/main/z/zentyal-radius/zentyal-radius_3.5.1.tar.gz' -O zentyal-radius_3.5.1.tar.gz
# tar -xf zentyal-radius_3.5.1.tar.gz
# mv zentyal-radius-3.5.1 zentyal-radius-4.2
# wget 'https://drive.google.com/uc?export=download&id=0B4_d-7xL0AS_MWRMOS10Y2c1S2s' -O zentyal-radius-4.2.patch
# patch -t -p1 -i zentyal-radius-4.2.patch
# cd zentyal-radius-4.2
# dpkg-buildpackage -rfakeroot -b -tc
# cd ..
# sudo dpkg -i zentyal-radius_4.2_all.deb
# sudo apt-get install -f -y
De este modo, podreḿos controlar qué grupo de usuarios del servidor Zentyal pueden acceder a la red vía freeradius, algo muy interesante porque vamos a poder configurar nuestro portal cautivo en pfSense para que utilice el servicio radius de Zentyal.
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 15 de marzo de 2017

Realizar consulta para obtener usuarios, grupos y máquinas en la B.D. LDAP de Zentyal 4.2

Tengo implementado el controlador de dominio Windows mediante Zentyal 4.2. Para obtener información de usuarios en la B.D. LDAP, podemos realizar la siguiente consulta desde un terminal:
# ldapsearch -xLLL -H ldap://127.0.0.1 -D "adminies@instituto.extremadura.es" -b "cn=Users,dc=instituto,dc=extremadura,dc=es" -W
Para obtener información de grupos en la B.D. LDAP, podemos realizar la siguiente consulta desde un terminal:
# ldapsearch -xLLL -H ldap://127.0.0.1 -D "adminies@instituto.extremadura.es" -b "cn=Groups,dc=instituto,dc=extremadura,dc=es" -W
Para obtener información de máquinas en la B.D. LDAP, podemos realizar la siguiente consulta desde un terminal:
# ldapsearch -xLLL -H ldap://127.0.0.1 -D "adminies@instituto.extremadura.es" -b "cn=Computers,dc=instituto,dc=extremadura,dc=es" -W
Siendo adminies@instituto.extremadura.es un usuario administrador del dominio. Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 10 de marzo de 2017

Error: VM is locked (backup) en Proxmox

Si en algún momento tratáis de hacer un backup de una máquina virtual en Proxmox y os aparece el siguiente error cuando no se está realizando ningún backup:
Error: VM is locked (backup)
Es posible que se haya producido algún error y se mantenga el bloqueo de la máquina virtual. Para eliminar dicho bloqueno no tenemos más que utilizar
# qm unlock <vmid>
Donde será el identificador de la máquina virtual a desbloquear. Por ejemplo:
# qm unlock 102
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 8 de marzo de 2017

Instalación de OMV-Extras en OpenMediaVault 3.0

OMV-Extras.org es un plugin que nos permite, entre otras cosas:
  • Instalar otros plugins en OpenMediaVault.
  • Instalar un kernel de backports.
  • Añadir repositorios personalizados.
En este post, vamos a ver cómo instalar este plugin en OMV 3.0 desde la línea de comandos:

Primero.- Instalamos el paquete apt-transport-https, si no lo teníamos instalado aún:
# apt-get install apt-transport-https
Segundo.- Descargamos el paquete que contiene el plugin:
# wget http://omv-extras.org/openmediavault-omvextrasorg_latest_all3.deb
Tercero.- Una vez descargado, lo instalamos:
# dpkg -i openmediavault-omvextrasorg_latest_all3.deb
Cuarto.- Por último actualizamos los índices de los repositorios:
# apt-get update
Una vez hecho ésto, ya podemos buscar plugins de openmediavault:
# apt-cache search openmediavault
Publicado por primera vez en http://enavas.blogspot.com.es

Cambiar/establecer etiqueta en una partición/volumen LVM

Es muy fácil cambiar o establecer una etiqueta para una partición o volúmen LVM con tan sólo utilizar el comando e2label. Un par de ejemplos:
# e2label /dev/openmediavault-vg/backup backup
# e2label /dev/openmediavault-vg/publico publico
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 3 de marzo de 2017

Restaurar objetos de directiva de grupo

Es conveniente tener un backup de nuestros objetos de directiva de grupo, para poder restaurarlos en caso de que haya algún problema.

Primero.- Seleccionamos "Objetos de directiva de grupo":


Segundo.- Hacemos clic con el botón derecho del ratón sobre "Objetos de directiva de grupo". Se nos desplegará un menú de contexto. Haremos clic sobre la opción "Administrar copias de seguridad...":



Tercero.- Se nos mostrará un cuadro de diálogo donde seleccionaremos la ubicación de la copia de seguridad y el/los objeto/s de directiva de grupo que queramos restaurar. Una vez seleccionados, pulsaremos el botón "Restaurar":


Cuarto.- Se nos abrirá un cuadro de diálogo que nos pedirá confirmación antes de restaurar. Pulsamos en "Aceptar":


Y comenzará el proceso de restauración. Cuando termine, pulsamos el botón "Aceptar" y habremos restaurado los objetos de política de grupo seleccionados.


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

Realizar un Backup de todos los objetos de directiva de grupo

Veamos cómo hacer un backup de los objetos de directiva de grupo de nuestro dominio:

Primero.- Abrimos la herramienta de administración de directivas de grupo gpmc.msc en el equipo que tiene instalado RSAT y seleccionamos "Objetos de directiva de grupo".


Segundo.- Hacemos clic con el botón derecho del ratón sobre "Objetos de directiva de grupo". En el menú de contexto hacemos clic sobre "Hacer copia de seguridad de todos..." para realizar una copia de seguridad de todos los objetos de directiva de grupo:


Tercero.- Seleccionamos la ruta donde guardar la copia de seguridad, escribimos un comentario en la "Descripción" y hacemos clic sobre el botón "Hacer copia de seguridad".


Cuando termine, pulsamos el botón "Aceptar" y listo:


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

Modificación del script update.cmd para actualizar Windows en equipos Infolab sólo en un intervalo horario

En un post del viernes pasado, os mostré un script al que llamé update.cmd que me permite dos cosas:
  • Actualizar el software instalado mediante chocolatey.
  • Aplicar las actualizaciones de Windows Update descargadas mediante WSUS Offline Update en mi NAS.
Esta semana he realizado una actualización del script que tan sólo realizará la actualización del equipo si se encuentra en un determinado intervalo horario, renombrando la versión anterior como "pkgsyncwin.cmd".

La idea es dejar el script pkgsyncwin.cmd para poder lanzarlo de forma manual en cualquier momento y utilizar el script update.cmd mediante una tarea que se ejecute en el inicio de Windows. De este modo, las actualizaciones sólo se realizarán fuera del horario de "actividad".
update.cmd
@echo off

set olddir=%CD%
set hour=%TIME:~0,2%

if %hour% LSS 8 if %hour% GTR 15) (
   bcdedit /set {bootmgr} path \efi\microsoft\boot\bootmgfw.efi
   choco upgrade -y all --except=puppet

   net use t: \\nas\wsus /persistent:no
   t:
   cd client\cmd
   call DoUpdate.cmd /verify /updatecpp /updatetsc /instdotnet4
   cd /d %olddir%
   shutdown -r -t 10   
)
El script hace exactamente lo mismo que la versión anterior, sólo dentro de un horario.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 2 de marzo de 2017

El interfaz web de Zentyal no carga después de actualizar desde la versión 4.2 a la 5.0

Por lo que he podido comprobar, parece un poco pronto para actualizar desde zentyal development edition 4.2 a 5.0, si nuestro sistema se encuentra en producción.
Uno de los errores que se han producido: El interfaz webadmin no cargaba después de actualizar de una versión a otra.
Al conectarme vía ssh al servidor Zentyal comprobé que el servicio webadmin estaba caído. ¿Cómo lo comprobamos?
# zs webadmin status
Una vez comprobado, podemos iniciarlo de la siguiente manera:
# zs webadmin start

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

Eliminar un usuario local de Windows mediante Puppet

Es muy sencillo eliminar un usuario local de Windows mediante Puppet. Tan sólo tenemos que utilizar el recurso puppet "user" del mismo modo que lo hacemos con clientes Linux. Vamos a verlo con un ejemplo aplicado:

El sistema Windows de mis Infolab tiene un usuario local llamado "Usuario". Puesto que tengo un controlador de dominio para estos equipos, y, cada usuario inicia sesión con su propio login y password, no me interesa que puedan iniciar sesión con este usuario local, que, por otra parte, no tiene contraseña. Para eliminarlo, podemos utilizar el recurso user de la siguiente manera:
   user { 'Usuario':
      ensure => absent,
      managehome => true
   }
Para eliminarlo, es suficiente con definir el atributo ensure => absent.

Sin embargo, me gustaría comentar un detalle importante: Podemos utilizar el atributo managehome (y esto es aplicable tanto a clientes Linux como clientes Windows) para eliminar su home local (si estamos usando ensure => absent) o crearlo (si estamos usando ensure => present).

Una vez definido el recurso y aplicado a los clientes, podemos comprobar que el usuario se elimina:
# puppet agent -tv
Info: Caching catalog for infolab-prueba.instituto.extremadura.es Info: Applying configuration version '1488442521' Notice: /Stage[main]/Windows_users/User[Usuario]/ensure: removed Notice: Finished catalog run in 54.99 seconds
Publicado por primera vez en http://enavas.blogspot.com.es

Recuperar el gestor de arranque del DEP-Profe

Los adjudicatarios de un DEP-Profe deben solucionar los problemas de sus dispositivos. En ocasiones, se pierde el arranque dual tras las actualizaciones de Windows. En este caso, es sencillo repararlo siguiendo las instrucciones del manual creado por el CPR de Mérida:

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

miércoles, 1 de marzo de 2017

Uso de barras invertidas en manifests Puppet para Windows

Cuando escribimos un fichero manifests para clientes Windows, debemos tener en cuenta lo siguiente:
  • En la mayoría de los atributos, Puppet admite tanto las barras (/) como las barras invertidas (\), si bien es cierto que algunos atributos sólo admiten las barras y otros, solamente las barras invertidas.
  • Cuando las barras invertidas se encuentran entre comillas dobles, deben ser "escapadas".
  • Cuando las barras invertidas se encuentran entre comillas simples, podemos elegir "escaparlas" o no.
Ejemplos:
file { "C:\\Windows\\System32\\pkgsyncwin.cmd": }
file { 'C:\Windows\System32\pkgsyncwin.cmd': }
file { 'C:\\Windows\\System32\\pkgsyncwin.cmd': }
Publicado por primera vez en http://enavas.blogspot.com.es

Actualizar pfSense desde la línea de comandos


Normalmente actualizamos pfSense desde el interfaz web, aunque también es posible actualizarlo desde la línea de comandos, algo realmente útil, como por ejemplo, cuando no tenemos un acceso a dicho interfaz pero sí podemos conectarnos remotamente al servidor vía ssh.

Lo primero será conectarnos vía ssh al firewall. Si necesitáis acceder a él desde las interfaces LAN, no hay problema. Pero si lo que queréis es acceder desde la WAN, tendréis que crear una regla que lo permita.

Una vez conectados, ejecutamos el comando: 
# pfSense-upgrade -d
Y comenzará el proceso de actualización. Cuando termine, se reiniciará el sistema automáticamente para aplicar los cambios.
Publicado por primera vez en http://enavas.blogspot.com.es

Copiar scripts a múltiples equipos Windows vía GPO

Aprovechando que necesitaba distribuir el script update.cmd (una especie de pkgsync para windows que me va a permitir mantener actualizados los equipos), he creado un script de inicio copyfiles.cmd con el que distribuir cualquier nuevo script a los clientes:


De este modo, cada vez que necesite distribuir un nuevo script a los clientes Windows, tan sólo tengo que colocarlo en el directorio Netlogon del controlador de dominio.
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 24 de febrero de 2017

Script update.cmd para actualizar Windows en equipos Infolab

He creado un script update.cmd que me permite dos cosas:
  • Actualizar el software instalado mediante chocolatey.
  • Aplicar las actualizaciones de Windows Update descargadas mediante WSUS Offline Update en mi NAS.
update.cmd
@echo off
bcdedit /set {bootmgr} path \efi\microsoft\boot\bootmgfw.efi
choco upgrade -y all --except=puppet
net use z: \\nas\wsus
z:
cd client\cmd
call DoUpdate.cmd /verify /updatecpp /updatetsc /instdotnet4
shutdown -r -t 10
El script realiza las actualizaciones y reinicia el equipo para que se apliquen aquellas que puedan requerir un reinicio.

La idea es poder usarlo, al menos de momento, de forma manual y, posteriormente encajarlo en el sistema que permita actualizar Ubuntu y Window de forma desatendida.

La línea que contiene el comando bcdedit cambia el arranque por defecto a Windows. Utilizo este mecanismo para forzar un inicio en Windows después de la actualización. En el siguiente reinicio volverá a iniciarse mi cargador de arranque por defecto (rEFInd) porque tengo mecanismos que lo establecen como gestor de arranque por defecto tanto en Windows como en Ubuntu.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 23 de febrero de 2017

Hacer un debug de un cliente ldap

Para diagnosticar un problema de conexión a un servidor LDAP desde un cliente, podemos realizar una búsqueda en modo debug.

Por ejemplo, supongamos que queremos ver qué sucede al realizar una consulta con el usuario administrador mediante ldap seguro:
# ldapsearch -v -H ldaps://servidor -D cn=admin,ou=People,dc=instituto,dc=extremadura,dc=es -W -x -b dc=instituto,dc=extremadura,dc=es -d1
Ahora bien, supongamos que queremos comprobar qué sucede cuando hacemos una consulta con el usuario replica mediante ldap no seguro:
# ldapsearch -v -H ldap://servidor -D cn=replica,dc=instituto,dc=extremadura,dc=es -W -x -b dc=instituto,dc=extremadura,dc=es -d1
Como podéis imaginar, con "-d num" estamos indicando el nivel de debug.
Publicado por primera vez en http://enavas.blogspot.com.es