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
1

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

miércoles, 4 de septiembre de 2019

Averiguar versión de GPFS instalada en Linux



Cómo averiguar qué versión de GPFS está instalada en un sistema operativo Linux, averiguar versión instalada de General Parallel File System, ver versión de IBM Spectrum Scale.



Hay aplicaciones, como SAP, que se suelen instalar sobre un sistema de archivos GPFS (General Parallel File System) por su velocidad de acceso a disco y su escalabilidad.

GPFS, como la mayoría de productos, evoluciona con cada versión, es decir, recibe cambios que pueden provocar un comportamiento inesperado en las aplicaciones que interactúan con él. Esto significa que scripts o programas que interactúan con un clúster GPFS puede que dejen de funcionar o funcionen erróneamente después de actualizar el programa o la versión de GPFS.

Para prevenir problemas, un buen comienzo es averiguar qué versión de GPFS está instalada en una máquina. Para ello, IBM no ha creado un comando específico, pero sí existen un par de métodos que nos ayudarán a encontrar la susodicha versión.


rpm



Para averiguar la versión de GPFS instalada en un sistema Linux podemos usar el comando siguiente:

HOST# rpm -qa | grep gpfs gpfs.gpl-4.2.3-13.noarch gpfs.gskit-8.0.50-86.x86_64 gpfs.license.std-4.2.3-13.x86_64 gpfs.docs-4.2.3-13.noarch gpfs.ext-4.2.3-13.x86_64 gpfs.msg.en_US-4.2.3-13.noarch gpfs.base-4.2.3-13.x86_64

Las opciones "qa" del comando rpm equivalen a "query all", es decir, busca todos los paquetes instalados en el sistema operativo. Con grep, filtramos los paquetes que contienen "gpfs" en su nombre, para ver solo aquellos que tienen relación con GPFS.

Con todo esto, llegamos al paquete "gpfs.base", el cual nos dice que tenemos instalada la versión 4.2.3 del General Parallel File System en este sistema.


mmfsadm



IBM Spectrum Scale incluye una utilidad llamada mmfsadm, la cual nos muestra en pantalla la versión del daemon de GPFS instalado en la máquina, así como otros datos de la instalación:

HOST# mmfsadm dump version Dump level: verbose Build branch "4.2.3.13 ". Built on Aug 7 2019 at 13:50:36 by . Current daemon version 1717, minimum compatible version 1301 ...


mmlsconfig



A nivel de cluster, mmlsconfig nos muestra la versión mínima de GPFS del cluster:

HOST# /usr/lpp/mmfs/bin/mmlsconfig Configuration data for cluster HANAcluster.gpfsnode01: ------------------------------------------------------ clusterName HANAcluster.gpfsnode01 clusterId 774744069380081798 dmapiFileHandleSize 32 dataStructureDump /tmp/GPFSdump pagepool 4G maxMBpS 2048 maxFilesToCache 4000 skipDioWriteLogWrites yes nsdInlineWriteMax 1M prefetchAggressivenessWrite 2 readReplicaPolicy local nsdThreadsPerDisk 24 enableLinuxReplicatedAio no restripeOnDiskFailure yes ignorePrefetchLUNCount yes minReleaseLevel 4.2.3.9 ccrEnabled yes autoload yes adminMode central File systems in cluster HANAcluster.gpfsnode01: ----------------------------------------------- /dev/sapmntdata

La línea que empieza por minReleaseLevel nos indica la versión más baja de GPFS instalada en el cluster.


Conclusión



Sabiendo la versión de GPFS instalada en un sistema, ya podemos indagar si el software que queremos instalar o actualizar soporta dicha versión, para proceder o no con su instalación.


Fuentes:

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000...
https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.0/com.ibm.itsm.hsmul.doc...
1