Instalar PHP 7.2 en SUSE Linux Enterprise 12

Escrito por Blai el 31.10.18

Cómo actualizar la versión de PHP 7 a PHP 7.2 en SUSE Linux Enterprise Server 12.



Los repositorios de SUSE Linux Enterprise Server 12 contienen los binarios de la versión 7.0.7 de PHP 7, tal como se puede ver si instalamos PHP 7 en un SUSE Lnux Enterprise Server 12:

HOST# php -v PHP 7.0.7 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

La versión más actual de PHP 7 en el momento de escribir estas líneas es la 7.2, soportada por aplicaciones web varias como Drupal, Joomla, Moodle, etc. PHP 7.2 incluye varias mejoras respecto a la versión 7.0 inicial y es aconsejable usarla en los servidores web en los que tengamos PHP corriendo.

El problema viene en el momento de ir a actualizar PHP 7.0 a PHP 7.2: los repositorios oficiales de SUSE no contienen la versión 7.2 de PHP, y compilarla desde código fuente puede ser un infierno... pero estamos de suerte, la comunidad viene al rescate. Y es que en https://software.opensuse.org/ podemos encontrar repositorios comunitarios y añadirlos a nuestros SLES para instalar componentes no portados a SLES de forma oficial (siempre bajo nuestra responsabilidad y asumiendo los riesgos que conlleva).

Buscando, he encontrado un repositorio que contiene los binarios de PHP 7.2 para SLES 12 SP3 y he decidido instalarlo en una máquina con SLES 12 SP3 con "zypper addrepo https://(URL del repo)":

HOST# zypper addrepo https://download.opensuse.org/repositories/home:/Miuku:/php72/SLE_12_SP3/home:Miuku:php72.repo Adding repository 'PHP 7.2.x (SLE_12_SP3)' .........................[done] Repository 'PHP 7.2.x (SLE_12_SP3)' successfully added URI : http://download.opensuse.org/repositories/home:/Miuku:/php72/SLE_12_SP3/ Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities are without effect. All enabled repositories share the same priority.

Una vez instalado el repositorio, hay que refrescar la lista de repositorios del sistema e indicarle al SLES que confíe siempre en él a la hora de buscar nuevos paquetes y actualizaciones:

HOST# zypper refresh Repository 'SLES12-SP3-Pool' is up to date. Repository 'SLES12-SP3-Updates' is up to date. Repository 'SLE-SDK12-SP3-Pool' is up to date. Repository 'SLE-SDK12-SP3-Source-Pool' is up to date. Repository 'SLE-SDK12-SP3-Updates' is up to date. Repository 'SUSE-PackageHub-12-SP3' is up to date. Repository 'SUSE-PackageHub-12-SP3-Pool' is up to date. Repository 'SLE-Module-Web-Scripting12-Pool' is up to date. Repository 'SLE-Module-Web-Scripting12-Updates' is up to date. Retrieving repository 'PHP 7.2.x (SLE_12_SP3)' metadata -------------------------------------------------------------------------[\] New repository or package signing key received: Repository: PHP 7.2.x (SLE_12_SP3) Key Name: home:Miuku OBS Project Key Fingerprint: BC53D00F B6D3ED76 A85D8684 F6DA4F79 E9E45FB5 Key Created: Sat Sep 10 18:00:04 2016 Key Expires: Mon Nov 19 17:00:04 2018 Rpm Name: gpg-pubkey-e9e45fb5-57d42e04 Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a Retrieving repository 'PHP 7.2.x (SLE_12_SP3)' metadata .............[done] Building repository 'PHP 7.2.x (SLE_12_SP3)' cache ..................[done] All repositories have been refreshed.

Finalmente, con el repositorio comunitario ya validado en el sistema, podemos lanzar una actualización masiva de componentes desde todos los repositorios del sistema mediante "zypper dup", para que el SLES vea que hay una nueva versión de PHP 7 disponible. Y la instalamos:

HOST# zypper dup Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Refreshing service 'SUSE_Linux_Enterprise_Server_12_SP3_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Software_Development_Kit_12_SP3_x86_64'. Refreshing service 'SUSE_Package_Hub_12_SP3_x86_64'. Refreshing service 'Web_and_Scripting_Module_12_x86_64'. Loading repository data... Reading installed packages... Computing distribution upgrade... The following 13 packages are going to be upgraded: php7 php7-ctype php7-dom php7-iconv php7-json php7-mbstring php7-openssl php7-pdo php7-phar php7-sqlite php7-tokenizer php7-xmlreader php7-xmlwriter The following 13 packages have no support information from their vendor: php7 php7-ctype php7-dom php7-iconv php7-json php7-mbstring php7-openssl php7-pdo php7-phar php7-sqlite php7-tokenizer php7-xmlreader php7-xmlwriter 13 packages to upgrade. Overall download size: 2.5 MiB. Already cached: 0 B. After the operation, additional 5.4 MiB will be used. Continue? [y/n/...? shows all options] (y):

Una vez actualizados los paquetes de PHP 7, nos aseguramos de que PHP 7.2 haya quedado instalado. Comprobamos ahora la versión de PHP instalada en la máquina usando el mismo comando que hemos usado al principio del artículo:

HOST# php -v PHP 7.2.9 (cli) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

Leer más »

Permitir administración de Sonicwall por internet

Escrito por Blai el 31.10.18

Cómo acceder a la consola de administración de un Sonicwall vía web a través de internet.



Permitir la administración de un Sonicwall a través de internet es un riesgo de seguridad, pero puede sernos útil en momentos puntuales. Si tememos que podamos llegar a quedarnos sin acceso al dispositivo después de realizar alguna tarea de mantenimiento, esto nos puede salvar.

Por ejemplo, instalar un nuevo firmware en el dispositivo o editar reglas de routing, podrían dejar el Sonicwall inaccesible, por lo que garantizarnos un acceso extra por WAN, nos puede venir bien.

Para permitir el acceso al panel de administración de un Sonicwall a través de internet, debemos dirigirnos al apartado Network > Interfaces y clicar en el botón de configuración de la interfaz WAN.

Una vez estemos en la nueva ventana, activamos el management vía HTTPS:



Cuando cliquemos en el checkbox de HTTPS, el Sonicwall nos avisará de que estamos poniendo en riesgo la seguridad del dispositivo. Si tiene una contraseña débil, puede que alguien la crackee:



Clicamos en OK y el acceso al panel de administración vía internet (WAN) queda concedido.

En este momento, ya podemos realizar la tarea de mantenimiento en cuestión.

Cuando hayamos terminado y verifiquemos que el Sonicwall funciona correctamente, volvemos a desactivar el acceso vía WAN y volveremos a estar seguros.

Leer más »

Primeros pasos con nginx

Escrito por Blai el 17.10.18

Cómo instalar nginx, configurarlo y empezar a usarlo en una máquina Linux.



NGINX es un software de código abierto apto para usarse como servidor web, reverse proxy, almacenamiento en caché, balanceo de carga, transmisión TCP, etc. Comenzó como un servidor web diseñado para ofrecer el máximo rendimiento y estabilidad y progresó hasta ser uno de los mejores productos del mercado en varias áreas.

Personalmente, nginx me gusta mucho por su facilidad de configuración y por su gran potencial como reverse proxy, siendo un producto Open Source (con opción a licencia Enterprise) mejor que la mayoría de productos de pago destinados a la gran empresa (véase F5 Big-IP).

Instalación

Para instalar nginx, deberemos desplegar primero un sistema Linux. Nnginx se puede instalar sobre las principales distribuciones Linux: CentOS, RHEL, SUSE, Debian, Ubuntu... Según la distribución Linux que hayamos elegido, deberemos instalar un repositorio u otro de entre los repositorios oficiales de nginx.

Una vez añadido al sistema el repositorio correspondiente de nginx, ya podemos instalar el software de acuerdo al gestor de paquetes de nuestra distribución:

HOST# yum install nginx

HOST# zypper install nginx

HOST# apt install nginx

Después de instalar nginx, hay que iniciarlo:

HOST# systemctl start nginx.service

Y una vez iniciado, habilitamos que se inicie automáticamente cada vez que se reinicie la máquina:

HOST# systemctl enable nginx.service

Configuración

Con nignx instalado y corriendo, ya podemos empezar a configurarlo. Para configurar nginx y personalizar sus parámetros, solo hace falta modificar un archivo:

/etc/nginx/nginx.conf

A diferencia de Apache, que tiene varios archivos a modificar según lo que se quiera configurar, nginx lo junta todo en un solo archivo, lo cual facilita su análisis y modificación.

Otra diferencia entre Apache y nginx es que nginx no se basa en procesos, sino en eventos. Las peticiones hacia el servidor se clasifican como eventos (nginx) y no como nuevos procesos de trabajo (Apache). Estos eventos se distribuyen entre los procesos existentes, que son mantenidos en memoria por el proceso principal.

La cantidad de procesos existentes y la manera en la que se dividen las solicitudes del servidor (eventos) se definen en el archivo nginx.conf, y se pueden aumentar o disminuir según la capacidad de computo y la RAM de la máquina donde se ejecuta nginx:

worker_processes 1; events {     worker_connections 1024; }

Ejemplo de configuración de procesos y eventos en nginx.conf

Señales

Los procesos de nginx se controlan con el parámetro –s y una señal (signal) de la siguiente manera:

HOST# sudo nginx -s signal

Signal puede ser cualquiera de estas opciones:

- stop: finaliza nginx (cierra el programa).
- quit: nginx finaliza después de que todas las solicitudes activas hayan sido contestadas.
- reload: el archivo de configuración se vuelve a cargar.
- reopen: se reinician los archivos de registro.

La opción que más vamos a usar es reload. Cada vez que hagamos un cambio en nginx.conf, deberemos usar la señal reload para recargar la configuración y que nginx use los nuevos parámetros.

Cuando se hace un reload, lo primero que hace nginx es verificar la sintaxis del archivo nginx.conf. Si hay un error en la configuración, nginx muestra el error en la terminal y mantiene la configuración previa, de modo que el servicio no se ve afectado. Si no hay errores o si ya se ha corregido el error y se hace un reload, la nueva configuración entra en uso en cuanto las sesiones activas terminan.

Si queremos comprobar si hay errores en nginx.conf antes de efectuar un reload, podemos hacer:

# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

Si nginx.conf está correctamente formado, se nos devolverá el mensaje "test is successful". De otro modo, nginx nos dirá en que línea hay un error y cuál es ese error, para que podamos corregirlo antes de hacer un reload de la configuración.

Hasta aquí llega este artículo sobre como instalar nginx, como iniciarlo y como modificar sus parámetros. En sucesivas entradas, iré mostrando cómo configurar nginx para usarlo como reverse proxy o cómo usarlo para servir contenido vía HTTP, entre otras cosas.

Leer más »

Cómo registrar un SLES desde línea de comandos

Escrito por Blai el 10.10.18

Cómo registrar un SUSE Linux Enterprise Server desde línea de comandos, consola. shell, terminal.



SUSE permite la descarga de las ISOs de SUSE Linux Enterprise Server así como su libre uso, pero cobra una suscripción anual por el acceso de un sistema a los repositorios oficiales de la compañía. Es decir, SUSE Linux Enterprise Server se puede usar libremente pero no se pueden actualizar sus paquetes ni instalar nuevos componentes hasta que se registre el sistema con un código de registro. Y dicho código de registro solo se obtiene tras el pago de una suscripción.

El registro de un SUSE Linux Enterprise Server se puede realizar desde el entorno gráfico con el programa yast2 o vía línea de comandos con la utilidad SUSEConnect.

Registro

Para registrar un sistema vía línea de comandos, podemos usar la siguiente sintaxis:

HOST# SUSEConnect -r <CódigoDeActivación> -e <DirecciónEmail> Registered SLES_SAP 12 x86_64 To server: https://scc.suse.com Using E-Mail: user@mail.com

Si todo va bien, SUSEConnect nos devolverá el mensaje "Registered" seguido de la versión del sistema operativo que acabamos de registrar.

Debug

Si nos encontramos algún error, podemos usar la opción --debug para ver un log en tiempo real de qué está sucediendo durante el registro y ver así posibles problemas:

HOST# SUSEConnect -r XXXXXXXXXXXXX -e user@mail.com --debug cmd options: '{:token=>"XXXXXXXXXXXXX", :email=>"user@mail.com", :debug=>true, :language=>"POSIX"}' Merged options: #<SUSE::Connect::Config url="https://scc.suse.com", insecure=false, token="XXXXXXXXXXXXX", email="user@mail.com", debug=true, language="POSIX"> Reading credentials from /etc/zypp/credentials.d/SCCcredentials Read credentials: SCC_AAAAAAAAAAAA : YYYYYYYYYY Reading credentials from /etc/zypp/credentials.d/SCCcredentials Read credentials: SCC_AAAAAAAAAAAA : YYYYYYYYYY Executing: 'uname -i' Quiet: false Output: 'x86_64' Executing: 'lscpu' Quiet: false ... Registered SLES_SAP 12 x86_64 To server: https://scc.suse.com Using E-Mail: user@mail.com

Cuando el registro se haya realizado con éxito, se generará en el sistema el archivo /etc/SUSEConnect:

HOST# cat /etc/SUSEConnect --- url: https://scc.suse.com insecure: false

A partir de este momento, ya podemos realizar actualizaciones del sistema, migrar a nuevos Service Pack o instalar programas desde los repositorios oficiales de SUSE.

Recuperar código de registro

Si en algún momento queremos ver el código de registro usado para registrar un sistema determinado, podemos usar la opción -s de SUSEConnect, la cual nos devolverá el código de registro del sistema (regcode) así como la fecha de registro y la fecha de expiración del código de registro usado:

HOST# SUSEConnect -s [{"identifier":"SLES_SAP","version":"12","arch":"x86_64", "status":"Registered","regcode":"XXXXXXXXXXXXXX", "starts_at":"2018-04-09 07:59:29 UTC", "expires_at":"2020-04-08 07:59:29 UTC", "subscription_status":"ACTIVE","type":"oem"}]

Fuentes:

https://www.suse.com/support/kb/doc/?id=7016626

Leer más »

Cómo conectar por RDP a un EC2 Windows en AWS

Escrito por Blai el 2.10.18

Pasos a seguir para conectar por escritorio remoto a una instancia EC2 Windows Server en Amazon Web Services (AWS). Obtener password para conectar por RDP a Windows Server en AWS.



Cuando desplegamos un Windows Server en Amazon Web Services, debemos generar un par de claves pública/privada y a continuación, debemos descargarnos la clave privada (fichero.pem).

Una vez hecho esto y con la máquina ya desplegada, nos vamos al apartado EC2:



Vamos a las instancias en ejecución:



Cuando haya cargado la lista con las instancias en funcionamiento, hacemos click derecho encima de la instancia que nos interesa y elegimos "Connect":



En la ventana que se nos abre, clicamos "Get password":



En la siguiente ventana, cargamos la clave privada (el fichero.pem que nos descargamos al desplegar la máquina) en el apartado "Key Pair Path" y luego clicamos "Decrypt Password":



El password aparecerá entonces en texto plano:



Como último paso, nos queda habilitar el protocolo RDP para esta máquina. Para ello, dentro del apartado EC2, en el menú de la izquierda, nos vamos a Networking y accedemos a Security Groups:



Seleccionamos el grupo donde está incluida la instancia (recordar que asociamos cada instancia a un grupo en el apartado Network Interfaces) y creamos una regla Inbound para RDP:



Recordar que también debemos configurar RDP en las reglas de salida (Outbound).

Conociendo el usuario, el password y la IP privada de la instancia y con el servicio RDP habilitado, ya nos podremos conectar al Windows Server de turno vía escritorio remoto.

Leer más »