Algo de Linux: 2017

lunes, 26 de junio de 2017

Utilizar autofs para automontar directorios compartidos vía NFS en Infolab

Antes de nada, tengo que decir que mis equipos de Infolab no montan el home remoto del servidor. En lugar de ésto, inician sesión contra el servidor LDAP y se crea un home local para cada usuario.

Tomé esta decisión teniendo en cuenta que los equipos tienen una gran capacidad de almacenamiento en los discos duros locales y el espacio en el servidor siempre va a ser más limitado (Un equipo de Infolab tiene dos discos duros de 2Tb y el servidor tiene un sólo disco duro de 2Tb).

No obstante, también me interesa montar directorios compartidos del servidor y del nas vía nfs , algo que podemos hacer fácilmente utilizando autofs y añadirlos a los bookmarks de los usuarios. 

Autofs nos permite montar sistemas de archivos locales y remotos bajo demanda y desmontarlos automáticamente cuando no se usen. Esto quiere decir que los sistemas de archivos se van a montar cuando el usuario acceda a ellos y se desmontarán después de un tiempo de inactividad.

Mi NAS comparte el almacenamiento con los equipos de Infolab en una de sus interfaces de red a la que he asignado el nombre de nasinfolab y exporta varios directorios mediante nfs, entre ellos: "instituto" y "multimedia"  y queremos que ambos directorios se encuentren disponibles para las máquinas de la VLAN de Infolab, junto con el directorio "aulas" que se encuentra almacenado en servidor. Lo que tendríamos que hacer sería configurar autofs en cada máquina para que acceda a dicho directorio.

Ésto es algo que podemos configurar de una manera muy sencilla mediante puppet, pero veamos cómo hacerlo manualmente:

Primero, instalamos autofs en el cliente, si no lo tenemos instalado ya:
# apt-get install autofs

Una vez instalado, editamos el archivo /etc/auto.master y le añadimos las siguientes líneas:
/servidor /etc/auto.instituto --ghost
/nas /etc/auto.nas --ghost
Si no hemos configurado nada aún en autofs, el fichero os quedará más o menos así:
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#
#/misc  /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
#       "nosuid" and "nodev" options unless the "suid" and "dev"
#       options are explicitly given.
#
#/net   -hosts
#
# Include /etc/auto.master.d/*.autofs
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master
/servidor /etc/auto.instituto --ghost
/nas /etc/auto.nas --ghost
Con ésto, estamos especificando:
  • Un punto de montaje en /servidor, que configuraremos en el archivo /etc/auto.instituto. Por cierto, el directorio de montaje no es necesario crearlo. Lo crea autofs de forma automática.
  • Un punto de montaje en /nas, que configuraremos en el archivo /etc/auto.nas. Al igual que en el caso anterior, el directorio de montaje no es necesario crearlo. Lo crea autofs de forma automática.
A continuación creamos el archivo /etc/auto.instituto con el siguiente contenido:

aulas -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 servidor:/home/aulas
Donde:
  • aulas son los punto de montaje dentro de /instituto.
  • -fstype=nfs,vers=3,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 son las opciones de montaje.
  • servidor:/home/aulas es el directorio nfs de la máquina remota que queremos montar.
De este modo, cuando el usuario acceda a /servidor/aulas, se realizará automáticamente el montaje.

A continuación creamos el archivo /etc/auto.nas con el siguiente contenido:

instituto -fstype=nfs,vers=4,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 nasinfolab:/instituto


multimedia -fstype=nfs,vers=4,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 nasinfolab:/multimedia
Donde:
  • instituto y multimedia son los punto de montaje dentro de /nas.
  • -fstype=nfs,vers=4,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 son las opciones de montaje.
  • nasinfolab:/instituto y nasinfolab:/multimedia son los directorios nfs de la máquina remota que queremos montar.
De este modo, cuando el usuario acceda a /nas/instituto o a /nas/multimedia, se realizará automáticamente el montaje.

Para facilitar la tarea de montaje, he creado marcadores en /etc/skel/.config/gtk-3.0/bookmarks, para que cada home de usuario que se cree localmente tenga dicha configuración y que el usuario pueda acceder directamente a los recursos compartidos simplemente haciendo clic directamente sobre ellos.

El contenido del fichero /etc/skel/.config/gtk-3.0/bookmarks es el siguiente:
file:///servidor/aulas
file:///nas/multimedia
file:///nas/instituto
De este modo, cada usuario tendrá dicha configuración en $HOME/.config/gtk-3.0/bookmarks
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 24 de junio de 2017

Administrar extensiones de Gnome Shell en portablet Vexia con gnome-tweak-tool

En un post de mayo, vimos cómo administrar extensiones de Gnome Shell desde Firefox o Google Chrome. Para los que no lo sepan, también podemos administrarlas mediante gnome-tweak-tool:


Por cierto, las extensiones que instalemos como usuario, se guardarán en el directorio:
$HOME/.local/share/gnome-shell/extensions/

Ya comentaré en otro post qué extensiones de gnome-shell utilizo en mi portablet Vexia.
Publicado por primera vez en http://enavas.blogspot.com.es

Controlar el aspecto y la configuración de gnome-shell con gnome-tweak-tool

Nuestros portablets Vexia llevan montado Ubuntu Xenial con entorno de escritorio GNOME SHELL, motivado porque estos últimos dispositivos tienen pantalla táctil.

Los usuarios a los que se ha asignado un portablet son responsables de su configuración y mantenimiento principalmente porque se les dió permisos de administración, algo que puede parecer muy interesante a algunos, pero que a otros les complica un poco más la vida sin necesidad.

Para configurar el aspecto del entorno gráfico como usuario, mi recomendación en estos dispositivos es utilizar gnome-tweak-tool, que es sencillo de instalar desde un terminal porque se encuentra en los repositorios:
# apt-get install gnome-tweak-tool
Una vez instalado el paquete, si desplazáis el puntero del ratón a la esquina superior izquierda de la pantalla, os aparecerá el buscador de aplicaciones. Si escribís "gnome-tweak-tool":


Y pulsáis Enter, podréis abrir rápidamente la herramienta para configurar diferentes aspectos del entorno gráfico:

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

miércoles, 21 de junio de 2017

Utilizar la herramienta PsPasswd para cambiar la password de un usuario local en máquinas remotas

PsPasswd es una herramienta de la suite PsTools que nos va a permitir cambiar la password de un usuario local en una máquina remota, algo que nos viene como anillo al dedo para cambiar la contraseña del administrador local.

Veamos un ejemplo:
C:\PSTools> pspasswd.exe \\infolab-prueba -u AdminEdu -p password_actual AdminEdu nueva_password
En el ejemplo anterior estamos usando el propio administrador local para cambiar su clave de forma remota.
C:\PSTools> pspasswd.exe \\infolab-prueba -u instituto\gestor -p password_usuario_gestor AdminEdu nueva_password
Por otra parte, en lugar de indicar el nombre del equipo, podemos especificar un nombre de fichero que contenga un listado de las máquinas a las que hay que cambiar la password:
C:\PSTools> pspasswd.exe @fichero -u instituto\gestor -p password_usuario_gestor AdminEdu nueva_password
Publicado por primera vez en http://enavas.blogspot.com.es

GPO: Agregar un grupo del dominio al grupo local de Administradores

Para que un usuario pueda instalar aplicaciones en el sistema, debe tener permisos de Administrador. 

Si queremos que un grupo de usuarios del dominio no administradores puedan instalar aplicaciones, podemos añadir su grupo del dominio al grupo local de Administradores. O incluso podemos crear un grupo específico (por ejemplo Setup) que agreguemos al grupo local de Administradores y añadir y quitar usuarios cuando queramos concederles/denegarles permisos de administrador.

Para agregar un grupo del dominio como administrador local, crearemos una directiva de grupo en:
"Configuración del equipo" -> "Configuración de Windows" -> "Configuración de seguridad" -> "Grupos restringidos":

Hacemos clic con el botón derecho sobre "Grupos restringidos" y se nos mostrará un menú de contexto. De las diferentes opciones que nos aparecen, hacemos clic en "Agregar grupo" y se abrirá un cuadro de diálogo que nos permitirá agregar el grupo:


Hacemos clic en el botón "Examinar" y se nos abrirá un nuevo cuadro de diálogo en el que escribiremos el nombre del grupo de usuarios del dominio. A continuación hacemos clic en el botón "Comprobar nombres" para que busque el nombre de grupo en el dominio. Veremos que el nombre del grupo se subraya.


Pulsamos el botón "Aceptar" y nos mostrará el grupo del dominio añadido:


Pulsamos el botón "Aceptar" y se nos abrirá el cuadro de Propiedades. En el cuadro que dice "Este grupo es un miembro de:" pulsamos el botón "Agregar". Se abrirá un cuadro donde introducimos el nombre del grupo de administradores locales: Administradores. Y, a continuación, pulsamos el botón "Aceptar".


Es importante destacar que en la ventana anterior, no pulsamos el botón "Examinar" porque queremos agregar el grupo del dominio al grupo de administradores local y esta opción nos serviría para buscar un grupo del dominio.

Una vez hecho lo anterior, así nos quedaría configurada la pertenencia:


Pulsamos el botón "Aceptar" y volveremos de nuevo al editor de directivas de grupo, donde podremos añadir más grupos restringidos:

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

Instalación silenciosa de NetBeans en Windows

Al igual que en Linux, podemos realizar una instalación desatendida de NetBeans en Windows iniciando el instalador con el parámetro --silent:

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

martes, 20 de junio de 2017

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

Parece que en versiones más recientes de Proxmox, ya no funciona el viejo método de eliminar el popup con el mensaje "No Valid Subscription" que aparece al hacer login. No obstante, tal y como apuntaba el usuario Marcel G en el siguiente post, podemos seguir eliminándolo de la siguiente manera:
# sed -i.bak 's/NotFound/Active/g' /usr/share/perl5/PVE/API2/Subscription.pm && systemctl restart pveproxy.service
Si os dáis cuenta, estamos reemplazando "NotFound" por "Active" en el fichero "/usr/share/perl5/PVE/API2/Subscription.pm" y haciendo una copia de seguridad del mismo antes de reemplazar.
Publicado por primera vez en http://enavas.blogspot.com.es

Utilizar YUMI en Linux mediante Wine

YUMI (Your Universal Multiboot Integrator) es una interesante herramienta para crear dispositivos USB Multiboot que contengan diferentes distribuciones y herramientas en Windows.

Si queréis utilizar esta herramienta en Linux, tendréis que instalar dos cosas:
  • wine.
  • el runtime de mono.
Instalar wine desde los repositorios de Linux es sencillo:
# apt-get install wine
Del mismo modo, también es sencillo instalar el runtime de mono:
# apt-get install mono-runtime
Una vez hecho ésto, podéis ejecutar YUMI mediante WINE:
# wine YUMI-2.0.4.9.exe


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

sábado, 10 de junio de 2017

Instalar un disco duro USB en un thinclient HP5730

En un post de febrero de 2016, vimos cómo aprovechar un thinclient HP5730 como firewall pfSense. 


Hace poco tiempo pensé darle un uso adicional como servidor de clonación DRBL, pero sin perder la funcionalidad de firewall. Como este thinclient cuenta con un IDE flash memory 44 PIN de 2GB, pero tiene dos conectores USB dentro de la carcasa, opté por conectar un disco duro vía USB aprovechando esos dos conectores USB internos:  


Puesto que mi thinclient tiene  instalado el módulo de expansión GZ286AA, es sencillo atornillarlo a la carcasa del thinclient para que quede alojado en el interior:


Para conectarlo por USB he usado la placa SATA-mini USB de la carcasa de un disco duro externo que en su día murió y que conservaba en un cajón:


De este modo, tan sólo tengo que conectar la placa al disco duro SATA:


Y, por último, conectar la placa a los conectores USB que quedan dentro de la carcasa con un cable como el siguiente:

Una vez hecho el montaje, cerramos la carcasa y el disco duro quedará oculto dentro.


Así tengo la posibilidad de arrancar el firewall desde la IDE flash memory de 2GB o cualquier distro/s que instale en el disco duro conectado vía USB, como por ejemplo, DRBL.

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

miércoles, 7 de junio de 2017

Instalación silenciosa de Scratch 2.0 en Windows

Para instalar Adobe Air en Windows de forma silenciosa, no tenemos más que iniciar el instalador con los siguientes parámetros:


Es importante decir que Scratch es una aplicación Adobe AIR. Lo que significa que debéis instalar Adobe AIR para que funcione.
Publicado por primera vez en http://enavas.blogspot.com.es

Instalación silenciosa de Adobe Air en Windows

Para un administrador es importante que una aplicación ofrezca la posibilidad de realizar una instalación silenciosa, porque nos va a permitir automatizar la distribución de la aplicación a un conjunto de máquinas.

Para instalar Adobe Air en Windows de forma silenciosa, no tenemos más que iniciar el instalador con el parámetro -silent:

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

martes, 6 de junio de 2017

Puppet: Asegurar que un servicio esté detenido y deshabilitado

En ocasiones nos interesa garantizar que un servicio se encuentre detenido y que no vuelva a iniciarse. Para indicar a puppet el estado del servicio utilizamos el atributo ensure y para deshabilitarlo, usamos el atributo enable.
Por ejemplo:
   service { "checkLdapDaemon":
          ensure => stopped,
          enable => false
   }
De este modo, estamos garantizando que el servicio se encuentre detenido y deshabilitado.
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 5 de junio de 2017

Testear la configuración de hora de un cliente Windows

Una vez configurado el servicio de hora en clientes Windows, deberíamos echar un vistazo a un cliente y comprobar si se está realizando la sincronización.

Lo primero que deberíamos comprobar es si se ha aplicado la directiva en el cliente. Ésto es fácil de ver con rsop.msc (Resultant Set Of Policy):


Una vez comprobado, podemos consultar el estado de sincronización:


En este caso, veo que se ha realizado la sincronización con mi servidor de hora primario.

Por otra parte, con w32tm también podemos ver la configuración del cliente en un terminal:


Si todo es correcto, podéis tratar de realizar una re-sincronización para aseguraros:


Y consultar el estado del servicio tras realizar dicha sincronización:


Por útlimo, podemos usar el comando time con el parámetro /T para comprobar si la hora está bien actualizada:

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

GPO: Configurar el servicio de hora en los clientes de nuestro dominio

Es importante tener bien configurado el servicio de hora en todos los dispositivos de nuestra organización para lograr un buen funcionamiento de servicios y evitar problemas. Por tanto, me ha parecido interesante modificar las directivas de proveedores de hora para que los clientes Windows de mi dominio sincronicen su hora con los servidores NTP del centro. Para ello, vamos a tocar dos directivas:
  • Configurar el cliente NTP de Windows.
  • Habilitar el cliente NTP de Windows.

Ambas directivas se encuentran en:
Configuración del Equipo -> Directivas -> Plantillas administrativas -> Sistema -> Servicio Hora de Windows -> Proveedores de hora -> Configurar el cliente NTP de Windows


Abrimos la directiva "Configurar el cliente NTP de Windows" para habilitarla y configurarla:


Como se puede ver en la imagen anterior, he especificado que el cliente debe utilizar dos servidores NTP de mi red registrados en DNS con los siguientes nombres:
  • ntp (servidor primario)
  • ldap (servidor secundario)
Podemos indicar que el cliente use varios servidores, separándolos mediante un espacio.

Por otra parte, debemos mencionar que junto al nombre del servidor, separado por una coma, debemos especificar un valor de flag que puede tener uno de los siguientes valores o una combinación de los mismos (para más información ver el siguiente artículo):
  • 0x01 SpecialInterval 
  • 0x02 UseAsFallbackOnly 
  • 0x04 SymmatricActive 
  • 0x08 Client
Para el servidor primario, he definido un valor de flag de 0x9 (Client 0x08 + SpecialInterval 0x01).
Para el servidor secundario, he definido un valor de flag de 0xa (Client 0x08 + UseAsFallbackOnly 0x02).

En cuanto al tipo de servidor, seleccionamos NTP.

Por otra parte, abrimos la directiva "Habilitar el cliente NTP de Windows" para habilitar el cliente NTP de Windows:


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

GPO: Evitar problema "La relación de confianza entre esta estación de trabajo y el dominio principal falló"

Si gestionáis un dominio de Windows, seguro que en más de una ocasión, a algún usuario se le ha mostrado el siguiente mensaje al tratar de iniciar sesión en el dominio:
"La relación de confianza entre esta estación de trabajo y el dominio principal falló"

Después de este mensaje ningún usuario del dominio puede iniciar sesión y la única solución es iniciar sesión con un administrador local de la máquina, añadir la máquina a un grupo de trabajo para sacarla del dominio (lo que nos obligará a reiniciar), para posteriormente volver a iniciar sesión con el administrador local y añadir la máquina al dominio (lo que nos volverá a obligar a reiniciar de nuevo).

Este problema puede deberse a que:
  • La password del equipo almacenada en el controlador de dominio no coincide con la password almacenada en el equipo porque se ha renovado.
  • La password del equipo ha expirado porque ha alcanzado su duración máxima (por defecto el tiempo máximo es de 30 días).
Como la renovación de las passwords de los equipos es un proceso que se realiza automáticamente y de forma transparente para el usuario, es probable que algún problema con la fecha y la hora del equipo haya motivado el error y habría que investigarlo.

Lo ideal es detectar cuál es exactamente el problema para resolverlo, pero, mientras tanto, podemos evitar que suceda este problema bajando la seguridad mediante la modificación de las siguientes directivas:
  • Miembro de dominio: deshabilitar los cambios de contraseña de cuentas de equipo.
  • Miembro de dominio: duración máxima de contraseña de cuenta de equipo. En esta directiva podemos establecer un valor entre 0 y 999 días. El valor por defecto es 30. Establecer un valor de 0, signfica que los equipos no cambien sus contraseñas. 
Ambas directivas se encuentran en:
Configuración del equipo -> Directivas -> Configuración de Windows -> Configuración de seguridad -> Directivas locales -> Opciones de seguridad


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

viernes, 2 de junio de 2017

Script de PowerShell para instalar actualizaciones de Windows Update mediante el módulo de PowerShell PSWindowsUpdate

El script del post anterior installwindowsupdate.ps1 instala el módulo de PowerShell PSWindowsUpdate y, una vez instalado, descarga e instala actualizaciones de Windows. Como una vez instalado lo único que vamos a necesitar va a ser realizar las actualizaciones, podríamos crear un nuevo script windowsupdate.ps1 a partir del anterior en el que tan sólo dejáramos la parte que obtiene e instala actualizaciones:

windowsupdate.ps1
Import-Module -Name PSWindowsUpdate
Get-WUInstall -WindowsUpdate -IgnoreUserInput -AcceptAll -IgnoreReboot -Verbose | Out-File C:\Windows\Temp\PSWindowsUpdate.log
Publicado por primera vez en http://enavas.blogspot.com.es

Script de PowerShell que instala el módulo de PowerShell PSWindowsUpdate

En el post anterior, vimos como instalar el módulo de PowerShell PSWindowsUpdate. Si tenemos que instalarlo en varias máquinas, sería interesante conventirlo en un script que podamos ejecutar directamente, y, de paso, que realice la instalación de actualizaciones de Windows Update:

installwindowsupdate.ps1
Set-ExecutionPolicy RemoteSigned -Force
Install-PackageProvider NuGet -Force
Import-PackageProvider NuGet
Set-PsRepository -Name PSGallery -InstallationPolicy Trusted
Save-Module -Name PSWindowsUpdate -Path C:\Windows\System32\WindowsPowerShell\v1.0\Modules
Install-Module -Name PSWindowsUpdate
Import-Module -Name PSWindowsUpdate
Get-WUInstall -WindowsUpdate -IgnoreUserInput -AcceptAll -IgnoreReboot -Verbose | Out-File C:\Windows\Temp\PSWindowsUpdate.log
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar módulo de PowerShell PSWindowsUpdate

PSWindowsUpdate es un módulo de PowerShell que nos va a permitir gestionar las actualizaciones de Windows Update de nuestros clientes mediante PowerShell. 

Para instalarlo, no tenemos más que abrir PowerShell y ejecutar la siguiente secuencia de comandos que, por otro lado, podemos incluir en un script:
Set-ExecutionPolicy RemoteSigned -Force
Set-PsRepository -Name PSGallery -InstallationPolicy Trusted
Save-Module -Name PSWindowsUpdate -Path C:\Windows\System32\WindowsPowerShell\v1.0\Modules
Install-Module -Name PSWindowsUpdate
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 1 de junio de 2017

Prestar servicio DNS en la interfaz WAN del Firewall PfSense

Como ya expliqué en un post de septiembre de 2016, tengo dividida la red del centro en varias VLAN, de manera que los equipos que se conectan vía wifi se encuentran en la VLAN 3, los equipos de infolab se encuentran en la VLAN 4 y ambos acceden a los servicios del centro en la interfaz WAN del firewall PfSense.

Para facilitar la gestión de recursos, habilité DNS Resolver en PfSense con la intención de prestar servicio de nombres en ambas VLAN. 

A raíz de un problema surgido con el servicio LDAP del servidor del centro, me ha parecido que sería interesante contar con otro servidor DNS que pudiera utilizar adicionalmente cuando lo necesite. Como ya tengo funcionando DNS Resolver en PfSense, he pensado que sería más que suficiente con hacer que DNS Resolver preste servicio DNS en la interfaz WAN también. Veamos cómo hacerlo:

Primero.- En el apartado "Network Interfaces", además de las interfaces WIFI e INFOLAB, seleccionamos la interfaz WAN para que DNS Resolver atienda peticiones DNS en dicha interfaz:


Segundo.- Creamos una regla en el firewall que permita recibir el tráfico DNS (puerto 53) en la interfaz WAN:


Tercero.- En el aparatado "Access list" de DNS Resolver creamos una regla que permita realizar consultas a los hosts de la red del centro donde está conectada la interfaz WAN:


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

Instalar libarchive-zip-perl para disponer de la herramienta crc32 en Debian Jessie

Llevamos ya un tiempo utilizando el servidor ldap con configuración OLC.

Se supone que con OLC no debemos modificar manualmente los archivos de configuración, pero, en ocasiones, puede que por alguna razón necesitemos hacerlo. En ese caso, cuando realicemos una operación con ldap, nos encontraremos con un error similar al siguiente:
54f983e8 ldif_read_file: checksum error on "/etc/ldap/slapd.d/cn\=config.ldif"
(...)
Donde vemos que hay un error de CRC en el archivo que hemos editado manualmente. Para solucionar el problema, necesitaremos la herramienta crc32 que se encuentra disponible en el paquete libarchive-zip-perl. Así que lo instalaremos:
# apt-get -y install libarchive-zip-perl
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 31 de mayo de 2017

Ejecutar script de Powershell desde la consola de Windows

Podemos ejecutar un script de PowerShell directamente desde la consola de windows (cmd) de la siguiente manera:
C:\WINDOWS\system32> powershell -File windowsupdate.ps1
Donde windowsupdate.ps1 es el script de powershell que queremos ejecutar.

Es importante destacar que, por seguridad, la ejecución de scripts se encuentra deshabilitada por defecto, para evitar ejecutar accidentalmente código malicioso en nuestro sistema. No obstante, Windows permite establecer tres posibles políticas de ejecución de scripts:
  • AllSigned.
  • RemoteSigned.
  • Unrestricted.
La directiva AllSigned requiere que todos los scripts y archivos de configuración estén firmados por un editor de confianza, incluidos los scripts que se escriban en el equipo local. 

La directiva RemoteSigned requiere que todos los scripts y archivos de configuración descargados de Internet estén firmados por un editor de confianza, pero no requiere firmas digitales en scripts ejecutados desde el equipo local.

En cuanto a la directiva Unrestricted, permite ejecutar todos los scripts sin necesidad de que hayan sido firmados por un editor de confianza. 
Para consultar qué política se encuentra establecida en nuestro equipo en un momento determinado, podemos ejecutar:
C:\WINDOWS\system32> powershell Get-ExecutionPolicy
AllSigned
Y para establecer una política, por ejemplo, RemoteSigned:
C:\WINDOWS\system32> powershell Set-ExecutionPolicy RemoteSigned
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 30 de mayo de 2017

GPO: Eliminar perfiles de usuario con una antigüedad superior al número de días especificado al reiniciar el sistema

Podemos utilizar la directiva "Eliminar perfiles de usuario con una antigüedad superior al número de días especificado al reiniciar el sistema" para hacer limpieza en Windows eliminando perfiles de usuario locales que no se hayan usado durante un número determinado de días. Esta directiva se encuentra accesible en:

Configuración del equipo -> Directivas -> Plantillas administrativas -> Sistema -> Perfiles de usuario -> Eliminar perfiles de usuario con una antigüedad superior al número de días especificado al reiniciar el sistema

Una vez seleccionada la directiva, la habilitamos y especificamos el número de días de antigüedad:

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

Instalar OpenSSH en Windows mediante Chocolatey

Para los que trabajamos habitualmente en Linux, es importante disponer del servicio ssh en Windows porque nos va a permitir conectarnos a nuestros clientes del mismo modo que nos conectamos a los clientes Linux. Ésto es algo muy sencillo de conseguir si utilizáis chocolatey:
C:\Windows\System32> choco install openssh -params '"/SSHServerFeature"'
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 24 de mayo de 2017

Administrar extensiones de Gnome Shell en portablet Vexia

Todos los nuevos equipos de nuestros centros llevan montado Ubuntu Trusty con entorno de escritorio XFCE4, excepto los portablets Vexia, en los que instalaron Ubuntu Xenial con entorno de escritorio GNOME SHELL, motivado porque estos últimos dispositivos tienen pantalla táctil.

Los portablets Vexia tienen instaladas una serie de extensiones de Gnome Shell que modifican el comportamiento y la funcionalidad del escritorio. Pues bien, para instalar y gestionar estas extensiones, podemos instalar una extensión en Firefox y/o Google Chrome que permite la integración de GNOME SHELL con el repositorio de extensiones https://extensions.gnome.org/


Aquí podéis ver una imagen de la extensión instalada en Google Chrome:


Y en Firefox:

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

martes, 23 de mayo de 2017

Obtener la clave de Windows OEM mediante Windows OEM Product Key Tool

Los nuevos equipos con Windows ya no traen una pegatina con la clave de instalación. En lugar de ésto, incorporan la clave en la BIOS o EFI. 

Para obtener la clave de instalación de un equipo Windows con licencia OEM, podemos utilizar la herramienta Windows OEM Product Key Tool.


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

Quitar mensaje: Modo de Prueba | Windows 10

Es posible que en alguna ocasión hayáis visto el siguiente mensaje en la esquina inferior derecha de vuestro escritorio Windows:


Para eliminarlo, abrimos como administrador la herramientas de símbolo de sistema de Windows cmd y ejecutamos el siguiente comando: bcdedit -set TESTSIGNING OFF




Una vez hecho ésto, reiniciamos el equipo y listo.
Publicado por primera vez en http://enavas.blogspot.com.es

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