Algo de Linux: junio 2017

viernes, 30 de junio de 2017

Error "invalid byte sequence in US-ASCII" en Puppet

En nuestros centros utilizamos puppetmaster con passenger y apache.

Probablemente alguno de vosotros haya visto el siguiente error en alguna ocasión: "invalid byte sequence in US-ASCII". Pues bien, una manera de evitarlo, es forzar que el puppetmaster utilice UTF-8.

Para ello, editamos el archivo /usr/share/puppet/rack/puppetmasterd/config.ru y le añadimos la siguiente línea:

Encoding.default_external = Encoding::UTF_8

A continuación podéis ver el fichero /usr/share/puppet/rack/puppetmasterd/config.ru de mi puppetmaster:
# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.

# if puppet is not in your RUBYLIB:
# $LOAD_PATH.unshift('/opt/puppet/lib')

$0 = "master"

# if you want debugging:
# ARGV << "--debug"

ARGV << "--rack"

# Rack applications typically don't start as root.  Set --confdir and --vardir
# to prevent reading configuration from ~puppet/.puppet/puppet.conf and writing
# to ~puppet/.puppet
ARGV << "--confdir" << "/etc/puppet"
ARGV << "--vardir"  << "/var/lib/puppet"

# NOTE: it's unfortunate that we have to use the "CommandLine" class
#  here to launch the app, but it contains some initialization logic
#  (such as triggering the parsing of the config file) that is very
#  important.  We should do something less nasty here when we've
#  gotten our API and settings initialization logic cleaned up.
#
# Also note that the "$0 = master" line up near the top here is
#  the magic that allows the CommandLine class to know that it's
#  supposed to be running master.
#
# --cprice 2012-05-22

require 'puppet/util/command_line'
# we're usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Util::CommandLine.new.execute

Encoding.default_external = Encoding::UTF_8
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar perfiles de usuario en el sistema operativo Windows de los equipos de Infolab

Como los equipos de Infolab disponen de arranque dual, además de eliminar los directorios HOME locales de usuario, para completar el proceso de limpieza, es conveniente eliminar los perfiles de usuario en Windows. Para hacerlo de una forma sencilla, suministro la herramienta Delprof2 a todos los clientes Windows usando una directiva de grupo.

Delprof2 elimina perfiles de usuario inactivos. No obstante, si queremos hacer limpieza para recuperar el espacio en disco ocupado por perfiles de usuario que ya no se van a utilizar, no tenemos más que ejecutarlo como administrador sin parámetros y eliminará todos los perfiles excepto el que estemos usando y algunos perfiles especiales necesarios para el sistema operativo (como el perfil "Predeterminado").

Delprof2 dispone de opciones de filtrado adicionales de manera que:
  • Es posible eliminar copias localmente en caché de perfiles móviles.
  • O eliminar sólo aquellos perfiles que no se hayan utilizado en un número de días especificado.
Además, es posible utilizarlo tanto de forma local como remota.

En la página de la herramienta encontraréis toda la información, incluida la sintaxis del comando y una serie de ejemplos de uso.
Publicado por primera vez en http://enavas.blogspot.com.es

Eliminar directorios HOME locales en Ubuntu de equipos Infolab y portátiles

Mis equipos de Infolab y portátiles se autentican contra el servidor ldap y se crea un directorio HOME local para cada usuario que inicia sesión en la máquina. Como ya comenté en el post anterior, ahora que hemos llegado a final de curso, es conveniente realizar limpieza borrando los directorios HOME locales de estas máquinas.

Para borrar dichos directorios suministro a los equipos mediante puppet el siguiente script que en su día escribí para portátiles:
#!/bin/bash
#
# /usr/local/sbin/borrahomes
# Esteban M. Navas Martin
# algodelinux@gmail.com
# Fecha creacion: 17/06/2015

# Requiere tener instalado el paquete facter para identificar el tipo de máquina
tipo=$(facter tipo)

if [ $tipo = "infolab" ] || [[ $tipo =~ notebook.* ]]; then

   # Borramos los directorios HOME
   rm -fr /home/profesor/* 2>/dev/null
   rm -fr /home/alumnos/* 2>/dev/null

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

   # Creamos un fichero testigo para borrar homes solamente cuando no exista el fichero
   touch /etc/homecleaned
fi
Como podéis comprobar, hace uso del facter tipo definido en el fichero /etc/escuela2.0 para asegurar que solamente se ejecute en equipos de infolab y portátiles.
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 28 de junio de 2017

Eliminar directorios HOME de usuario en equipos de Infolab

Como ya he comentado en más de una ocasión, mis equipos de Infolab tienen habilitado el arranque dual (Ubuntu+Windows) de manera que:
  • En Ubuntu se inicia sesión contra el servidor LDAP y se crea un home local para cada usuario.
  • En Windows se inicia sesión con el  servidor Active Directory implementado mediante samba con Zentyal y se crea un perfil local parar cada usuario.
Con el tiempo, lo más práctico será iniciar sesión tanto en Windows como en Ubuntu contra el mismo servidor y lo más probable es que lo haga utilizando el servidor Zentyal.

Ahora que hemos llegado a fin de curso, es conveniente realizar limpieza tanto en Ubuntu como en Windows eliminando los perfiles locales de los usuarios. Para ello:
  • En Ubuntu utilizo un script al que llamé borrahomes.
  • En Windows utilizo la herramienta delprof2.
Publicado por primera vez en http://enavas.blogspot.com.es

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