miércoles, 9 de octubre de 2019

Conectarse como root a instancia Linux en AWS



Cómo conectarse directamente como root a una instancia EC2 Linux en AWS.



Al crear una instancia Linux en AWS, Amazon nos obliga a iniciar una conexión por SSH a una instancia EC2 Linux en AWS usando un usuario no privilegiado predefinido por ellos, como ec2-user o ubuntu. Si tratamos de iniciar una sesión SSH como root, nos encontraremos con el siguiente mensaje:

Using username "root". Authenticating with public key "imported-openssh-key" Please login as the user "ec2-user" rather than the user "root".

Para permitir el login del usuario root vía SSH, debemos situarnos en la home de root:

HOST# cd /root/.ssh

Y buscar el fichero authorized_keys, el cual contendrá algo parecido a:

HOST# cat authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAAB3NzaC1yc2EAAAADA+K4WkbVwemgociUzbzVtBb5SJZHbV1uqKNBH8mS82o6ffjhUGljbUjTj5EStJVMqnxFZpi7+RukgH55lwtKeIASZxjyiHEKq+0xg3iyRno2masFCgiwZD18znPnUFtX0Js8vM0+QOOsb7EE+w8nLuk+m4Jxze+eTjjErRSrTkpQejeJ3OkfGce3GLJLCwA2KsUMMLEsAvyTL6qn9ppk+VaO1fNeQtrr0OYSBKo3 KEY_NAME

Para permitir el login de root por SSH, tenemos que borrar el "command" con algún editor tipo vi:

command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10"

A continuación, debemos editar el fichero de configuración de SSH (/etc/ssh/sshd_config) y modificar la política PermitRootLogin, la cual viene desactivada por defecto en AWS (PermitRootLogin No).

Si queremos acceder con clave pública/privada:

PermitRootLogin wihtout-password

Si queremos acceder con password:

PermitRootLogin Yes

Una vez modificada la política, recargamos la configuración del servicio SSH para que lea los cambios:

HOST# systemctl reload sshd

Hecho esto, ya podremos conectarnos a la instancia EC2 Linux por SSH con el usuario root.
0

miércoles, 2 de octubre de 2019

Linux: espacio ocupado no concuerda con archivos



Cómo liberar espacio bloqueado en disco en un sistema Linux.



El sistema de monitorización que uso para ver si las máquinas virtuales tienen el disco lleno, la CPU al 100%, etc. me envió un correo diciendo que el directorio raíz de un sistema Linux estaba prácticamente lleno. Me conecté a la máquina afectada y lo comprobé:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G    30G    5,9G    84%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

Al ejecutar el comando df vi que había 30 GB usados de un total de 38 GB aprovisionados en /dev/sda1. En cambio, al mirar qué carpeta estaba ocupando más espacio en disco mediante du, no vi ningún directorio donde se concentrara esa ocupación. Tampoco el total de GB ocupados cuadraban con los mostrados por df. Como vemos, no había más de 3 GB usados en total:

root@host:/# du -hs * | sort -h 0      dead.letter 0      initrd.img 0      proc 0      sys 0      vmlinuz 4,0K   lib64 4,0K   mnt 4,0K   opt 4,0K   selinux 8,0K   backup 8,0K   srv 12K    media 16K    lost+found 52K    tmp 100K   dev 3,6M   lib32 4,5M   sbin 5,8M   bin 6,6M   etc 16M    boot 22M    root 49M    home 115M   lib 1,0G   usr 1,8G   var

Lo que podía estar ocurriendo es que algún proceso estuviese usando un archivo que hubiese sido eliminado y como el buffer no se podía vaciar porque no existía el archivo hacia el que el proceso quería escribir, se mantuviera esa información en el limbo hasta que ese proceso mueriera, aumentando así el tamaño del buffer hasta ocupar esos 30 GB mencionados anteriormente.

Podemos ver qué procesos usan archivos que han sido borrados mediante:

root@host:/# lsof | grep deleted

En el resultado, vi que el programa apache2 estaba tratando de escribir en los archivos /var/log/apache2/error.log y /var/log/apache2/other_vhosts_access.log, los cuales habían sido eliminados:

apache2 ... /var/log/apache2/error.log (deleted) apache2 ... /var/log/apache2/other_vhosts_access.log (deleted)

Como el causante era Apache, tras reiniciar Apache se liberó el espacio ocupado en /dev/sda1:

root@host:/# df -h S.ficheros      Size   Used   Avail   Use%   Montado en /dev/sda1        38G   4,7G    32G     14%   / tmpfs           7,9G      0    7,9G     0%   /lib/init/rw udev            7,9G   100K    7,9G     1%   /dev tmpfs           7,9G      0    7,9G     0%   /dev/shm

¡Misterio resuelto!


Fuentes:

https://serverfault.com/questions/315181/df-says-disk-is-full-but-it-is-not
0

miércoles, 25 de septiembre de 2019

Migrar colas de impresión entre Windows Servers



Cómo migrar colas de impresión o impresoras de un Windows Server a otro Windows Server.



Si tenemos colas de impresión funcionando en un Windows Server antiguo - por ejemplo en un Windows Server 2008 - en algún momento tendremos que migrarlas a un Windows Server más reciente.

En este artículo, muestro como migrar todas las colas de impresión de un Windows Server 2008 (ya fuera de soporte por parte de Microsoft) a un Windows Server 2019 recién instalado.


Servidor origen



Lo primero que tendremos que hacer para migrar las colas de impresión es asegurarnos de que el Windows Server origen tenga instalado el rol de "Print and Document Services". Este rol añade al componente "Print Management" al servidor, necesario para exportar la lista de impresoras, sus drivers, IPs, etc. a un archivo. Este archivo será el que luego importemos en el servidor destino.



Clicamos con el botón derecho sobre "Print Management" y elegimos la opción "Migrate Printers...":



Elegimos la opción "Export" y exportamos todos los datos de las impresoras presentes en el sistema.



Este proceso nos generará un "Printer Migration File", el cual contiene los nombres de todas las impresoras presentes en el sistema, así como sus IPs, marca y modelo y el driver asociado.


Servidor Destino



Nos aseguramos de que el rol "Print Services" esté instalado en el servidor destino:



Dentro del Server Manager, nos dirigimos a Tools > Print Management:



En Print Management, botón derecho y elegimos la opción "Migrate Printers...":



Seleccionamos la opción "Import...", abrimos el archivo generado en el apartado anterior y clicamos siguiente hasta que el import finalice:



En este caso, el proceso de import ha terminado con advertencias; algunas impresoras de la lista ya no existen, y por lo tanto, su IP ya no responde. Es un buen momento para eliminarlas.

Llegados a este punto, solo nos queda configurar el FQDN al que apuntan los servicios de impresión para que apunte al nuevo servidor. Con esto, ya habremos migrado satisfactoriamente el servicio de impresión a una versión actual de Windows Server.
0

miércoles, 18 de septiembre de 2019

Re-registrar SUSE Linux Enterprise Server 'cloud'



Registrar SLES en AWS, Error Unexpected exception. Receive: script died unexpectedly Please file a bug report about this en un sistema SUSE Linux Enterprise Server en Amazon Web Services.



Actualizando un sistema SUSE Linux Enterprise Server (SLES) alojado en Amazon Web Services (AWS), me encontré con un mensaje de error un tanto curioso que no había visto nunca antes:

ec2-user@ip-10-250-3-73:~> sudo zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Unexpected exception. Receive: script died unexpectedly Please file a bug report about this. See http://en.opensuse.org/Zypper/Troubleshooting for instructions.

No recuerdo haber visto ningún otro error en SLES que dijera al usuario explícitamente que informara de un bug. Sea como sea, la situación era que el sistema no me permitía instalar paquetes, ni realizar actualizaciones ni migraciones hacia Service Packs, por lo que suponía un riesgo de seguridad.

Después de eliminar y añadir repositorios al S.O. y de jugar con SUSEConnect sin éxito, encontré un comando que debe ser exclusivo de las instancias cloud de SLES y que me fue la mar de bien:

ec2-user@ip-10-250-3-73:~> sudo /usr/sbin/registercloudguest --force-new

Después de forzar el re-registro de la instancia con este comando llamado "registercloudguest", ya pude actualizar el sistema operativo sin mayor problema:

ec2-user@ip-10-250-3-73:~> sudo zypper up Refreshing service 'Basesystem_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'Desktop_Applications_Module_x86_64'. Refreshing service 'Development_Tools_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'SUSE_Cloud_Application_Platform_Tools_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Refreshing service 'Server_Applications_Module_x86_64'. Refreshing service 'Web_and_Scripting_Module_x86_64'. ...

Comentar que los registros generados por este comando pueden consultarse en:

/var/log/cloudregister

No hay ninguna entrada en las páginas man del sistema operativo para el comando registercloudguest, ni hay más documentación por parte de SUSE al respecto, así que solo debe poderse ejecutar con las opciones mencionadas y solamente en instancias cloud.


Fuentes:

https://forums.suse.com/showthread.php?14030-SLES12SP4-fails-cloud-registration
https://www.suse.com/support/kb/doc/?id=7022311
0

miércoles, 11 de septiembre de 2019

Redirigir HTTP a HTTPS en NGINX



Cómo redireccionar las peticiones HTTP a HTTPS en NGINX.



Cuando un usuario quiere acceder a una página web, normalmente accede a dominio.com en vez de acceder a https://dominio.com. De esta forma, su sesión en la página web se desempeña por HTTP, con todos los riesgos de seguridad que ello conlleva.

Desde NGINX podemos configurar que se redirija automáticamente a un usuario desde [http://] dominio.com hacia https://dominio.com de forma automática, para así asegurar su sesión. En determinados casos, como en el e-commerce, este requisito es indispensable para poder operar con TPVs, por ejemplo, donde la pasarela de pago debe estar asegurada mediante HTTPS obligatoriamente.


Redirección 301



Para automatizar la redirección de HTTP a HTTPS en todos los dominios que apunten al NGINX, lo más habitual es usar una redirección 301 en las solicitudes HTTP. Una redirección 301 devuelve el mensaje "Moved Permanently" (Movido permanentemente), el cual indica al navegador que efectue una redirección desde una determinada URL hacia un nuevo destino URL. Para los usuarios, una redirección 301 implica que cambie la URL de la barra de direcciones del navegador.


Configurando NGINX



Para que NGINX realice una redirección 301 de HTTP a HTTPS en la URL que el usuario está visitando, podemos usar este código dentro de la directiva http en nuestro archivo de configuración .conf:

http {     server {         listen 80;         return 301 https://$host$request_uri;     } ... }

Si quisiéramos realizar la redirección en un solo dominio en vez de aplicar esta redirección a todos los dominios configurados en NGINX, deberíamos incorporar el server_name a la directiva server tal que así:

http {     server {         server_name dominio.com;         listen 80;         return 301 https://$host$request_uri;     } ... }

Si queremos hacer la redirección en varios dominios, los pondremos uno detrás de otro en la opción server_name, separados por espacios.


Certificado SSL



Por último, recordar que para evitar que el navegador muestre a los visitantes un aviso del tipo "Detectado riesgo de seguridad" al acceder al dominio por HTTPS, deberemos configurar un certificado SSL en el NGINX para el dominio en cuestión.


Fuentes:

https://miposicionamientoweb.es/redireccion-301/
https://www.sistrix.es/preguntale-a-sistrix/optimizacion-onpage/codigo-de-estado-http/3xx-redirect...
0