miércoles, 26 de diciembre de 2018

Instalar Service Pack en SUSE Linux Enterprise



Cómo instalar un Service Pack en un SUSE Linux Enterprise Server 12.



Hace unos días, SUSE lanzó el Service Pack 4 para SUSE Linux Enterprise 12. Este Service Pack dota a SLES 12 de soporte para nuevo hardware, instala una nueva versión del kernel, ofrece mejoras de virtualización, etc. además de ser un compendio de todos los parches aparecidos en el lapso de tiempo comprendido entre el SP3 y el SP4.

Para actualizar a este Service Pack, debemos tener, primero de todo, una suscripción activa a SUSE.

Para actualizar a SP4, podemos actualizar desde cualquier versión de SLES 12, desde la versión base hasta la versión SP3. En este artículo, mostraré como actualizar desde SLES 12 versión base a SLES 12 SP4 vía línea de comandos. Hay que decir que es posible actualizar también desde otras vías, como son la ISO del DVD y el entorno gráfico (mediante YasT2).

Primero de todo, sería recomendable ver qué versión de SUSE Linux Enterprise Server tenemos instalada. Lo podemos averiguar de varias formas. Yo he elegido la siguiente:

HOST# cat /etc/os-release NAME="SLES" VERSION="12" VERSION_ID="12" PRETTY_NAME="SUSE Linux Enterprise Server 12" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12"

Vemos que el sistema es un SLES 12 base (base = sin ningún Service Pack instalado).

En este punto, lo ideal es realizar una actualización estándar de paquetes del sistema. Así, si las herramientas de conexión a los repositorios de SUSE hubieran sido actualizadas, podríamos descargar sus últimas versiones y usarlas en la actualización de Service Pack:

HOST# zypper up Building repository 'SLES12-Pool' cache ...............................[done] Retrieving repository 'SLES12-Updates' metadata .......................[done] Building repository 'SLES12-Updates' cache ............................[done] Loading repository data... Reading installed packages... ...

Una vez actualizados los paquetes correspondientes del sistema, ya podemos lanzar la migración hacia el último Service Pack. Como partimos de un SLES 12 base, deberemos instalar primero el Service Pack 3 antes de poder instalar el Service Pack 4:

HOST# zypper migration Executing 'zypper refresh' Repository 'SLES12-Pool' is up to date. Repository 'SLES12-Updates' is up to date. All repositories have been refreshed. Executing 'zypper --no-refresh patch-check --updatestack-only' Loading repository data... Reading installed packages... 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server 12 SP3 x86_64 2 | SUSE Linux Enterprise Server 12 SP2 x86_64 3 | SUSE Linux Enterprise Server 12 SP1 x86_64 [num/q]:

Elegimos la opción 1 (actualizar a Service Pack 3), aceptamos el acuerdo de licencia y esperamos pacientemente a que se instalen las más de 1.000 actualizaciones.

Cuando el proceso haya terminado, verificamos que se haya instalado el servce Pack 3:

HOST# cat /etc/os-release NAME="SLES" VERSION="12-SP3" VERSION_ID="12.3" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp3"

Reiniciamos la máquina. Cuando levante, ya podemos actualizar a Service Pack 4:

HOST# zypper migration Executing 'zypper refresh' Repository 'SLES12-SP3-Pool' is up to date. Repository 'SLES12-SP3-Updates' is up to date. All repositories have been refreshed. Executing 'zypper --no-refresh patch-check --updatestack-only' Loading repository data... Reading installed packages... Considering 0 out of 0 applicable patches: 0 patches needed (0 security patches) Available migrations: 1 | SUSE Linux Enterprise Server 12 SP4 x86_64 [num/q]:

Para acabar, verificamos que el Service Pack 4 haya quedado instalado:

HOST# cat /etc/os-release NAME="SLES" VERSION="12-SP4" VERSION_ID="12.4" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp4"

Y ya tenemos el SUSE Linux Enterprise Server actualizado a Service Pack 4.
0

miércoles, 19 de diciembre de 2018

SSL: cómo generar un archivo .p12



Cómo generar un archivo .p12 para realizar firmas electrónicas en ficheros PDF.



Hace un tiempo hablé de cómo generar un certificado SSL. Hoy hablaré de como usar la clave pública y la clave privada de un certificado para unirlas en un solo archivo de extensión .p12, el cual podremos usar como certificado para firmar documentos PDF.

Para empezar, necesitamos la parte pública del certificado SSL (archivo .cer o .crt) y la parte privada del certificado (archivo .key) así como los certificados intermedios de la entidad (archivos .cer).

Unimos todas las partes del certificado mediante la utilidad openssl:

C:\temp>openssl pkcs12 -export -inkey clave_privada.key -in CERT364.cer -out fichero.p12 -certfile multi.pem Enter Export Password: Verifying - Enter Export Password:

IMPORTANTE: el password que se nos pide es el que asignamos en su momento al CSR.

Echemos un vistazo a los diferentes archivos usados para generar el .p12:

- clave_privada.key: la clave privada del certificado.
- CERT364.cer: la clave pública del certificado. Podría ser un archivo .crt.
- fichero.p12: el fichero resultante de unir ambas claves.
- multi.pem: este archivo está compuesto por el contenido de los archivos .cer "extra" que nos envían desde la entidad certificadora; se trata de certificados propios de la entidad que validan que el certificado que vamos a usar ha sido emitido por ellos.

Para obtener el archivo .pem, creamos un archivo vacío y copiamos dentro los bloques de texto que hay dentro de los archivos .cer de la entidad certificadora:

-----BEGIN CERTIFICATE-----
<contenido>
-----END CERTIFICATE-----

Los copiamos uno debajo del otro, sin líneas en blanco entre ellos, y manteniendo el begin y el end.

Con el .p12 ya generado, ya lo podemos usar para realizar firmas electrónicas.
0

miércoles, 12 de diciembre de 2018

Tipos de red en VirtualBox



¿Alguna vez te has preguntado cuál es la diferencia entre los distintos tipos de red que puedes elegir en el adaptador de red de una máquina virtual en VirtualBox? veamos sus diferencias.



En esta entrada, veremos los tipos de conexiones de red de los que dispone el programa VirtualBox.



Con VirtualBox instalado, creamos o importamos una máquina Virtual y clicamos el botón Configuración. En Configuración, nos vamos al apartado Red. Allí, veremos distintas opciones a seleccionar para el adaptador de red de la máquina. Veamos en qué consiste cada una.

No conectado
Adaptador sólo-anfitrión (Host-Only)
Modo puente (bridge)
NAT
Red interna



No conectado



Con esta opción, la máquina virtual tiene una tarjeta de red instalada, pero no tiene conectividad con el host anfitrión ni con ninguna otra máquina virtual. Al entrar en la máquina virtual y mirar su IP, veremos que tiene una IP estática, no visible fuera de la máquina en sí.



Adaptador sólo-anfitrión (Host-Only)



Una máquina con el adaptador de red fijado en host-only solo tiene conectividad con el equipo anfitrión. Está totalmente aislada de las demás máquinas de la red de área local donde está conctado el anfitrión.




Modo puente (bridge)



En modo bridge, la máquina virtual pasa a ser un equipo más dentro de la red local. De este modo, la máquina virtual podrá conectarse a cualquier otra máquina/dispositivo presente en la red y cualquier otra máquina de la red podrá usar los recursos compartidos de la máquina virtual. De esta forma, si el equipo anfitrión está configurado para recibir una dirección IP por DHCP, la máquina virtual recibirá una IP del mismo rango, del mismo servidor DHCP.




NAT



Con el adaptador fijado en NAT, la máquina virtual recibe una dirección IP de un pool DHCP privado de VirtualBox. La máquina virtual, entonces, se conecta hacia el exterior mediante el firewall de VirtualBox, el cual le permite salir a internet medante el adaptador de red de la máquina anfitrión.




Red interna



Red interna es una forma de conectar varias máquinas virtuales entre ellas creando una red privada. De esta forma, las máquinas virtuales no podrán ver al PC anfitrión, ni viceversa, pero tendrán conectividad entre ellas. Con esta opción, podemos crear más de una red interna, separadas unas de otras.



Fuentes:

http://www.ticarte.com/contenido/tipos-de-conexiones-de-red-en-virtualbox-y-vmware
0

miércoles, 5 de diciembre de 2018

Quitar contraseña de un certificado SSL



Cómo quitar la contraseña de un certificado SSL, para que el servidor no la pida al reiniciarse.



Si tenemos un servidor web que sirva contenido HTTPS, necesitamos un certificado SSL que asegure las conexiones HTTPS hacia él. Los certificados SSL se suelen crear con un contraseña incrustada cuya utilidad principal es evitar que si el servidor web se ve comprometido, el intruso pueda robar el certificado y usarlo en otra máquina para realizar ataques de phishing, o similares.

Por otro lado, nos encontramos con que al proteger un certificado SSL con contraseña, cada vez que reiniciemos Apache o reiniciemos la máquina, el sistema nos pedirá que introduzcamos la contraseña:

Server dominio.com:443 (RSA) Enter pass phrase:

Esto puede llegar a ser un engorro y puede llegar a provocar downtime del sitio web. Si, por ejemplo, varias personas tienen acceso al servidor (desarrolladores, administradores, operadores, etc.) y una de ellas lo reinicia por una u otra causa, es posible que se olvide de que hay que intoducir el password del certificado durante el arranque de la máquina y el servicio web quede caído hasta que alguien se de cuenta. Si el certificado no tiene contraseña, se puede reiniciar la máquina sin mayor preocupación.

Para evitar que Apache nos pida la contraseña del certificado SSL cada vez que lo reiniciemos (o que reiniciemos la máquina), podemos usar este comando para quitar la contraseña a la clave privada:

HOST# openssl rsa -in /ssl/dominio.key -out /ssl/dominio_sin_password.key

La máquina nos preguntará entonces por la contraseña del certificado. Después de introducirla por última vez, se generará un archivo .key sin contraseña.

Lo último que queda por hacer es configurar Apache para que use el archivo .key que contiene la clave privada sin contraseña. A partir de este momento, al reiniciar Apache (o la máquina), este ya no pedirá la contraseña del certificado, pero seamos conscientes de que cualquiera que consiga hackear el servidor podrá extraer y usar el certificado SSL del dominio a su antojo.
0

miércoles, 28 de noviembre de 2018

Configurar HTTPS en Apache



Cómo configurar Apache para que sirva una página web por HTTPS con un certificado SSL.

HTTP es un protocolo inseguro y está sujeto a ataques man-in-the-middle y eavesdropping que pueden permitir a un atacante obtener acceso a información confidencial enviada de un cliente (PC de un usuario) a un servidor (página web) o viceversa.

HTTPS, por su parte, combina HTTP con el protocolo de seguridad SSL/TLS, creando un canal cifrado que hace que la información que se pueda conseguir si se intercepta una petición sea indescifrable, y por lo tanto, inusable por un atacante.

Si servimos páginas web, lo ideal es servirlas por HTTPS, sea cual sea el software de servidor web que usemos. Si estamos usando Apache, deberemos configurarlo para que sirva contenido por el puerto 443 (HTTPS), ya que por defecto, Apache solo escucha por el puerto 80 (HTTP).

Para que Apache escuche por el puerto 443, primero deberemos editar el siguiente archivo:

/etc/apache2/listen.conf

Añadimos el puerto 443:

Listen 80 Listen 443

Recordar que deberemos dejar pasar el puerto 443 en el firewall de la máquina. A continuación, creamos un Virtual Host nuevo que escuche por ese puerto. Para crear un Virtual Host, nos dirigimos a:

/etc/apache2/vhosts.d/

Y creamos un archivo con extensión .conf y el siguiente contenido:

<VirtualHost _default_:443> DocumentRoot "/srv/www/htdocs" ServerName web.com SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/archivo.crt SSLCertificateKeyFile /etc/apache2/ssl.key/archivo.key SSLCertificateChainFile /etc/apache2/ssl.crt/gd_bundle-g2-g1.crt </VirtualHost>

Veamos qué significa cada parámetro:

- <VirtualHost _default_:443>: el dominio por defecto responde por el puerto 443 (HTTPS).
- DocumentRoot "/srv/www/htdocs": ruta donde están los archivos que conforman la página web.
- ServerName web.com: dirección de la web.
- SSLEngine on: activamos SSL.
- SSLCertificateFile /etc/apache2/ssl.crt/certificado.crt: clave pública del certificado.
- SSLCertificateKeyFile /etc/apache2/ssl.key/archivo.key: clave privada del certificado.
- SSLCertificateChainFile /etc/apache2/ssl.crt/gd_bundle-g2-g1.crt: certificado intermedio (certificado de la autoridad certificadora).

Los archivos .crt y .key son los que conforman el certificado SSL de la página web y los debemos tener de antemano. Podemos obtener un certificado SSL de esta forma.

Para aplicar la nueva configuración, debemos reiniciar Apache. Antes de hacerlo, podemos verificar que la sintaxis del archivo .conf que acabamos de crear sea correcta con el comando:

HOST# apachectl configtest Syntax OK

Si la sintaxis está OK, podemos reiniciar Apache para aplicar los cambios:

HOST# apachectl restart

A partir de este momento, Apache ya sirve contenido por HTTPS. Podemos verificarlo accediendo a nuestra web por https://. El navegador debería indicarnos que el sitio es seguro.
0

miércoles, 21 de noviembre de 2018

Cómo generar CSR para obtener certificado SSL



Cómo generar un archivo .csr para obtener un archivo .crt (certificado SSL).



Hoy en día es básico que una página web sea accesible por HTTPS de forma segura con un certificado válido. Para que eso sea posible, debemos disponer de un certificado SSL válido y vigente para el dominio de la página web en cuestión.

Para obtener un certificado SSL para un dominio, primero debemos crear un archivo que contenga una "solicitud de firma de certificado". A continuación, debemos enviar este archivo a una empresa que se dedique a expedir certificados SSL para que lo valide y lo devuelva firmado por ellos, en forma de certificado SSL público. A partir de este momento, ya tendremos un certificado SSL válido, firmado por una entidad certificadora, listo para ser usado en nuestro servidor web.

La solicitud de firma de certificado, en inglés Certificate Signing Request, es un código que se guarda en un archivo de extensión .csr. Este archivo, se envía a una entidad certificadora y esta lo usa para generar un archivo .crt, el cual será la parte pública del certificado SSL. En el interior de un CSR quedan registrados datos tales como la empresa que lo pide, la localidad desde donde se pide y el dominio para el que se genera el certificado, entre otros.

Para generar un CSR, la opción más común es usar la utilidad openssl. Las distribuciones Linux lo suelen traer instalado por defecto, mientras que en Windows habrá que instalarlo explícitamente. Podemos obtener la última versión de OpenSSL para Windows desde aquí.

Una vez instalado OpenSSL, nos situamos en un directorio y generamos el CSR:

C:\temp>openssl req -nodes -keyout clave_privada.key -out pedido_certificado.csr -newkey rsa:2048 Generating a 2048 bit RSA private key ..........................................+++ ..........................................+++ writing new private key to 'clave_privada.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Barcelona Locality Name (eg, city) []:Barcelona Organization Name (eg, company) [Internet Widgits Pty Ltd]:Empresa Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:dominio.com Email Address []:hola@email.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

Vemos que al generar un CSR se crean dos archivos:

- archivo.csr: el Certificate Signing Request del que ya hemos hablado.
- archivo.key: la clave privada del certificado -> es importante guardarlo bien.

Una vez generados estos dos ficheros, mandamos nuestro archivo CSR a una entidad certificadora (p.e. GoDaddy.com) y pagamos el precio que nos pidan por el certificado SSL. Recordemos que este certificado tiene una vigencia determinada, siendo esta 1 año, 2 años, 3 años o los que queramos pagar.

Una vez realizado el pago, la entidad nos devolverá un archivo con extensión .cer o .crt que ya podremos usar en nuestro servidor web para asegurar las comunicaciones vía HTTPS.
1

miércoles, 14 de noviembre de 2018

Sudo o no sudo, esa es la cuestión



Qué diferencias hay entre ejecutar comandos en Linux como root, ejecutar comandos como usuario común, ejecutar comandos como usuario con sudo o ejecutar comandos con su.



Sudo. Soy humano y los humanos tenemos glándulas sudoríparas en el cuerpo que nos hacen sudar. Esta podría ser una respuesta válida al título de esta entrada, pero no van por ahí los tiros (lo siento, no he podido resistirme a hacer la broma xD).

Con el título de la entrada me refería a la pregunta que todo sysadmin que maneje Linux se ha planteado en algún momento: si es aceptable acceder a un servidor vía SSH como root y trabajar bajo ese usuario o si es mejor acceder con un usuario "limitado" y usar sudo cada vez que queramos ejecutar un comando que requiera permisos de superusuario. Y es que cada vez son más las distribuciones de Linux que, por defecto, no nos permiten conectarnos a una máquina como root.

Veamos algnos ejemplos:

Debian: en Debian, el acceso por SSH al sistema con el usuario root viene deshabilitado por defecto (PermitRootLogin no). Si queremos trabajar como root, tenemos que configurar el acceso de root vía SSH previamente o configurar sudo.

Ubuntu: en Ubuntu, durante la instalación, no se nos pregunta en ningún momento por el password de root, por lo que, directamente, no es posible conectarse a la máquina como root por SSH (es posible si lo configuramos nosotros posteriormente, obviamente).


¿Por qué no es aconsejable usar la cuenta root?



La respuesta a esta pregunta no es otra que el principio de mínimo privilegio, por el cuál cada usuario debería poder acceder solamente a los recursos que necesite. No más.

Me explico.

Si una persona no tiene que reiniciar servicios de un sistema, no tiene por qué acceder a ese sistema con la cuenta root. Si una persona no tiene que instalar paquetes en el sistema, no necesita poder acceder como root. Si una persona sólo va a subir imágenes por SFTP a una carpeta, no necesita la cuenta root, basta con que tenga acceso a la carpeta en cuestión.

¿Y si un usuario necesita poder reiniciar un servicio, por ejemplo nginx, por si el servicio cae?

La respuesta es sencilla: usar sudo.


Beneficios e inconvenientes de sudo



Para empezar, con el uso de sudo podemos especificar qué comandos puede ejecutar un usuario determinado usando privilegios de root, así como impedirle el uso de otros comandos como root. Así, si no queremos que un usuario pueda parar Apache, por poner un ejemplo, podemos impedirle explícitamente que ejecute el comando "sudo service apache2 stop". Y sin privilegios de root, no podrá parar el servicio. Por si esto fuera poco, podemos logear todos los comandos que un usuario realiza como root para ver quién y cuándo, ha hecho qué cambios.

Además, sudo nos puede salvar de catástrofes. Imaginemos que accedemos a un sistema como root y ejecutamos algo como "rm -rf /tmp/*" y por error ponemos un espacio entre / y * o entre / y tmp; el resultado será desastroso. Si ejecutamos la instrucción como usuario normal (no root o sin usar sudo), un mensaje nos dirá que no tenemos permisos para borrarlo todo.

Por otro lado, usar sudo es algo incómodo. Para empezar, debemos escribir "sudo comando" cada vez que queramos ejecutar un comando con privilegios de root, cuando normalmente sólo escribiríamos "comando". Muchas veces nos olvidaremos de escribir sudo y debremos recurrir a "sudo !!" para ejecutar el comando anterior con sudo o deberemos volver a escribir los comandos que queramos ejecutar. Algunas veces no hay problema, repetimos el comando y listo. Otras veces, veremos cosas "raras" en pantalla cuando no usemos sudo.

Con "cosas raras" me refiero a, por ejemplo, el caso siguiente. Queremos ver el estado de Apache:

HOST# service httpd status httpd dead but subsys locked

Ahora bien, si lo ejecutamos con sudo:

HOST# sudo service httpd status httpd (pid 4703) is running...

Esto ocurre porque un usuario sin privilegios no puede monitorizar ciertos servicios, mientras que usando sudo vemos el mismo output que vería root en la terminal.


¿Qué diferencias hay entre sudo y su?



Desde un usuario limitado, podemos usar dos formas para ejecutar comandos con privilegios de root:

sudo comando
su - root -c comando

La diferencia entre ambos es la siguiente:

- sudo nos pedirá el password de la cuenta que estemos usando para ejecutar un comando como root (podemos especificar que no nos pida password, aunque no es aconsejable desde el punto de vista de la seguridad).

- su nos pide el password del usuario "destino" con el que queremos ejecutar el comando. Eso significa que si no conocemos el password de root, no podremos usar "su - root".

Por lo tanto, si acceden varios usuarios a una misma máquina y queremos que usen su, deberemos comunicarles a todos el password de root para que accedan a una shell de root, mientras que usando sudo, los usuarios sólo deben conocer su propio password. Usando sudo, el password de root queda más protegido ante posibles robos de credenciales.


Conclusión



Por todo lo mencionado anteriormente, es desaconsejable usar la cuenta root en un servidor, y entre sudo y su, es claramente más recomendable usar sudo para ejecutar comandos con privilegios de root.


Fuentes:

https://www.howtoforge.com/tutorial/sudo-vs-su/
https://askubuntu.com/questions/16178/why-is-it-bad-to-log-in-as-root
https://security.stackexchange.com/questions/119410/why-should-one-use-sudo
0

miércoles, 31 de octubre de 2018

Instalar PHP 7.2 en SUSE Linux Enterprise 12



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
0

Permitir administración de Sonicwall por internet



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.
0

miércoles, 17 de octubre de 2018

Primeros pasos con nginx



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.
0

miércoles, 10 de octubre de 2018

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



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
0

martes, 2 de octubre de 2018

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



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.
0

miércoles, 26 de septiembre de 2018

Cómo instalar el kernel más reciente en CentOS 7



Cómo instalar la última versión del kernel - ya pre-compilada - en un sistema operativo Linux distribución CentOS versión 7, paso a paso, desde un repositorio third-party.



Cuando instalamos CentOS 7 desde una imagen oficial, el sistema se instala con el Kernel 3.10, el cual está algo anticuado a día de hoy (el Kernel de Linux ya va por la rama 4), por lo que es recomendable instalar una versión superior del mismo en el sistema. Idealmente, se debería instalar la última versión liberada del Kernel, la cual podemos conocer accediendo a https://www.kernel.org.

Como decía, una opción para instalar un nuevo kernel es descargar su código fuente desde kernel.org y compilarlo, pero es una tarea larga y compleja. Para simplificar las cosas, podemos instalar un kernel pre-compilado desde un repositorio third-party como por ejemplo "ELRepo".

Para activar el repositorio "ELRepo" en CentOS 7:

[root@host ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org [root@host ~]# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

Una vez instalado el repositorio, podemos buscar todos los kernels disponibles en él con:

[root@host ~]# yum --disablerepo="*" --enablerepo="elrepo-kernel" list available Complementos cargados:fastestmirror Loading mirror speeds from cached hostfile * elrepo-kernel: www.jules.fm Paquetes disponibles kernel-lt.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-devel.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-doc.noarch 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-headers.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-tools.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-tools-libs.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-lt-tools-libs-devel.x86_64 4.4.158-1.el7.elrepo elrepo-kernel kernel-ml-devel.x86_64 4.18.10-1.el7.elrepo elrepo-kernel kernel-ml-doc.noarch 4.18.10-1.el7.elrepo elrepo-kernel kernel-ml-headers.x86_64 4.18.10-1.el7.elrepo elrepo-kernel kernel-ml-tools.x86_64 4.18.10-1.el7.elrepo elrepo-kernel kernel-ml-tools-libs.x86_64 4.18.10-1.el7.elrepo elrepo-kernel kernel-ml-tools-libs-devel.x86_64 4.18.10-1.el7.elrepo elrepo-kernel perf.x86_64 4.18.10-1.el7.elrepo elrepo-kernel python-perf.x86_64

Ahora toca instalar la última versión estable:

[root@host ~]# yum --enablerepo=elrepo-kernel install kernel-ml

Cuando acabe la instalación, reiniciamos la máquina. Durante el inicio, en el menú de GRUB, deberíamos ver el nuevo kernel instalado. Lo seleccionamos y arrancamos el sistema:



Una vez en la consola, podemos configurar GRUB para que arranque el sistema con el nuevo kernel por defecto. Para hacer esto, editamos el archivo /etc/default/grub y configuramos el parámetro GRUB_DEFAULT cambiando el valor 1 por 0:

[root@host ~]# vi /etc/default/grub

GRUB_DEFAULT=0

Esto hará que el primer kernel de la lista de GRUB sea el kernel con el que el sistema arranque por defecto. Guardamos los cambios de configuración de arranque con el comando grub2-mkconfig:

[root@host ~]# grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.18.10-1.el7.elrepo.x86_64 Found initrd image: /boot/initramfs-4.18.10-1.el7.elrepo.x86_64.img Found linux image: /boot/vmlinuz-3.10.0-862.14.4.el7.x86_64 Found initrd image: /boot/initramfs-3.10.0-862.14.4.el7.x86_64.img Found linux image: /boot/vmlinuz-3.10.0-862.11.6.el7.x86_64 Found initrd image: /boot/initramfs-3.10.0-862.11.6.el7.x86_64.img Found linux image: /boot/vmlinuz-3.10.0-862.el7.x86_64 Found initrd image: /boot/initramfs-3.10.0-862.el7.x86_64.img Found linux image: /boot/vmlinuz-0-rescue-d114c821418141b4989f03970795ddeb Found initrd image: /boot/initramfs-0-rescue-d114c821418141b4989f03970795ddeb.img done

Reiniciamos la máquina y verificamos que el sistema arranque con el nuevo kernel por defecto. Lo podemos comprobar con el comando uname una vez lleguemos a la consola:

[root@host ~]# uname -a Linux host 4.18.10-1.el7.elrepo.x86_64 #1 SMP Wed Sep 26 16:20:39 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

Si detectamos que algo no funciona como debería, siempre podemos arrancar el sistema con el antiguo kernel eligiéndolo en la lista de GRUB.
0

miércoles, 19 de septiembre de 2018

La directiva de equipo no se puede actualizar



Cómo solucionar el problema "La directiva de equipo no se puede actualizar" al ejecutar gpupdate /force desde una línea de comandos o cmd de un PC Windows de una organización.



En una empresa u organización, los PCs suelen estar enrolados en un dominio, con directivas de grupo (GPO) que se despliegan en estos PCs para restringir funciones o aplicar configuraciones diversas. Hay veces que estas directivas tardan bastante en propagarse por la red, por lo que el administrador decide forzar su aplicación a un PC en concreto. Para forzar la aplicación de una directiva, se suele usar:

gpupdate /force

El problema que me he encontrado recientemente, es que al ejecutar este comando desde mi propio PC, el sistema (Windows 10) me devuelve el siguiente error:

C:\Users\usuario>gpupdate /force Actualizando directiva... La directiva de equipo no se puede actualizar correctamente debido a los siguientes errores: Error al procesar la directiva de grupo. Windows no pudo aplicar la configuración de directiva basada en el Registro para el objeto de directiva de grupo LocalGPO. La configuración de directiva de grupo no se podrá aplicar hasta que este evento se solucione. Consulte los detalles del evento para obtener más información acerca del nombre y la ruta de acceso del archivo que provocó el error. Se completó correctamente la Actualización de directiva de usuario. Para diagnosticar el error, revise el registro de eventos o ejecute GPRESULT /H GPReport.html para obtener acceso a la información sobre los resultados de la directiva de grupo.

Para solucionar este problema y volver a aplicar directivas, deberemos dirigirnos a estas dos rutas:

C:\Windows\System32\GroupPolicy\Machine
C:\Windows\System32\GroupPolicy\User


Y buscar en cada directorio un archivo llamado:

Registry.pol

Renombramos este archivo a, por ejemplo, Registry.old y volvemos a ejecutar gpupdate:

C:\Users\usuario>gpupdate /force Actualizando directiva... La actualización de la directiva de equipo se completó correctamente. Se completó correctamente la Actualización de directiva de usuario.

Ahora sí, al ejecutar gpupdate, las directivas se actualizan correctamente en el equipo y crean un nuevo archivo Registry.pol para almacenarse.
2

martes, 11 de septiembre de 2018

Cómo actualizar Ubuntu



Cómo actualizar el software instalado en un sistema operativo Ubuntu (o cualquiera de sus derivados) para aplicar parches a los programas y manetener el sistema al día.



Mantener el software de un sistema operativo al día - incluyendo sus componentes base - es una tarea básica de cualqueir administrador de sistemas. En el caso de Ubuntu (o Debian, Linux Mint, etc.) el gestor de paquetes que nos permite actualizar las versiones de los mismos es apt.

Para iniciar el proceso de actualización, usaremos el comando apt update (recordar que si usamos Ubuntu, debemos poner el comando sudo delante de cada comando para ejecutarlo como root):

usuario@host:~$ sudo apt update [sudo] password for usuario: Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [83.2 kB] Hit:2 http://es.archive.ubuntu.com/ubuntu bionic InRelease Get:3 http://es.archive.ubuntu.com/ubuntu bionic-updates InRelease [83.2 kB] Get:4 http://es.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] ... Fetched 1,005 kB in 1s (937 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 5 packages can be upgraded. Run 'apt list --upgradable' to see them.

La opción update compara las versiones del software instaladas en local con las versiones del mismo software disponibles en los distintos repositorios del sistema operativo.

Para ver las nuevas versiones de cada programa que podemos instalar deberemos ejecutar apt list --upgradable (deberemos ejecutar esta opción solo después de haber ejecutado apt update). Este comando listará cada paquete y su nuevo número de versión disponible.

usuario@host:~$ apt list --upgradable Listing... Done libssl1.0.0/bionic-updates,bionic-security 1.0.2n-1ubuntu5.1 amd64 [upgradable from: 1.0.2n-1ubuntu5] libssl1.1/bionic-updates,bionic-security 1.1.0g-2ubuntu4.1 amd64 [upgradable from: 1.1.0g-2ubuntu4] networkd-dispatcher/bionic-updates,bionic-updates 1.7-0ubuntu3.2 all [upgradable from: 1.7-0ubuntu3] openssl/bionic-updates,bionic-security 1.1.0g-2ubuntu4.1 amd64 [upgradable from: 1.1.0g-2ubuntu4] update-notifier-common/bionic-updates,bionic-updates 3.192.1.1 all [upgradable from: 3.192.1]

Si quisieramos actualizar un solo paquete, por ejemplo openssl, usaremos sudo apt upgrade openssl:

usuario@host:~$ sudo apt upgrade openssl Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-image-3.16.0-77-generic linux-image-extra-3.16.0-77-generic Use 'sudo apt autoremove' to remove them. The following packages will be upgraded: openssl 1 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade. Need to get 1,21 kB of archives. After this operation, 0,24 B of additional disk space will be used. Do you want to continue? [Y/n] y

Para actualizar todos los paquetes, usaremos sudo apt upgrade:

usuario@host:~$ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-image-3.16.0-77-generic linux-image-extra-3.16.0-77-generic Use 'sudo apt autoremove' to remove them. The following packages will be upgraded: libssl1.0.0 libssl1.1 networkd-dispatcher openssl update-notifier-common 5 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade. Need to get 2,921 kB of archives. After this operation, 1,024 B of additional disk space will be used. Do you want to continue? [Y/n] y

Si disponemos de suficiente espacio en el disco, aceptamos la actualización:

Get:1 http://es.archive.ubuntu.com/ubuntu bionic-updates/main amd64 update-notifier-common all 3.192.1.1 [161 kB] Get:2 http://es.archive.ubuntu.com/ubuntu bionic-updates/main amd64 libssl1.1 amd64 1.1.0g-2ubuntu4.1 [1,128 kB] Get:3 http://es.archive.ubuntu.com/ubuntu bionic-updates/main amd64 networkd-dispatcher all 1.7-0ubuntu3.2 [12.8 kB] Get:4 http://es.archive.ubuntu.com/ubuntu bionic-updates/main amd64 openssl amd64 1.1.0g-2ubuntu4.1 [532 kB] Get:5 http://es.archive.ubuntu.com/ubuntu bionic-updates/main amd64 libssl1.0.0 amd64 1.0.2n-1ubuntu5.1 [1,087 kB] Fetched 2,921 kB in 1s (3,439 kB/s) Preconfiguring packages ... (Reading database ... 82066 files and directories currently installed.) Preparing to unpack .../update-notifier-common_3.192.1.1_all.deb ... Unpacking update-notifier-common (3.192.1.1) over (3.192.1) ... Preparing to unpack .../libssl1.1_1.1.0g-2ubuntu4.1_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.0g-2ubuntu4.1) over (1.1.0g-2ubuntu4) ... Preparing to unpack .../networkd-dispatcher_1.7-0ubuntu3.2_all.deb ... Unpacking networkd-dispatcher (1.7-0ubuntu3.2) over (1.7-0ubuntu3) ... Preparing to unpack .../openssl_1.1.0g-2ubuntu4.1_amd64.deb ... Unpacking openssl (1.1.0g-2ubuntu4.1) over (1.1.0g-2ubuntu4) ... Preparing to unpack .../libssl1.0.0_1.0.2n-1ubuntu5.1_amd64.deb ... Unpacking libssl1.0.0:amd64 (1.0.2n-1ubuntu5.1) over (1.0.2n-1ubuntu5) ... Setting up libssl1.0.0:amd64 (1.0.2n-1ubuntu5.1) ... Setting up update-notifier-common (3.192.1.1) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... Setting up libssl1.1:amd64 (1.1.0g-2ubuntu4.1) ... Setting up openssl (1.1.0g-2ubuntu4.1) ... Processing triggers for man-db (2.8.3-2) ... Setting up networkd-dispatcher (1.7-0ubuntu3.2) ... Installing new version of config file /etc/default/networkd-dispatcher ... Processing triggers for libc-bin (2.27-3ubuntu1) ... usuario@host:~$

Una vez finalizado el proceso de upgrade, ya tendremos el sistema al día.
0

miércoles, 5 de septiembre de 2018

Cómo instalar PHP 7.2 en IIS



Cómo instalar PHP 7.2 en un servidor web IIS de un Windows Server.



Hoy en día, son muchas las aplicaciones web que requieren PHP 7.2 para funcionar correctamente. IIS, por defecto, no tiene PHP configurado y este debe ser instalado a parte.

Para instalar PHP 7.2 en un servidor Windows que use IIS, primero debemos descargarnos una herramienta oficial de Microsoft llamada Microsoft Web Platform Installer la cual nos permite añadir componentes como PHP o SQL a los IIS de forma sencilla.

Descargamos Microsoft Web Platform Installer, lo ejecutamos y nos vamos a la pestaña "Products". Nos dirigimos a "Frameworks" y bajamos hasta la opción "php 7.2.2 (x64)".



Clicamos "Add" y a continuación "Install". El programa seleccionará automáicamente otras utilidades (además de PHP 7.2) que deben instalarse obligatoriamente para poder usar PHP 7 en IIS.



Cuando haya terminado la instalación, creamos un archivo .php en la carpeta donde tengamos alojada nuestra página web con el siguiente código:

<?php phpinfo(); ?>

Reiniciamos IIS. Ahora, al acceder con el navegador a este archivo .php, comprobaremos cómo PHP 7.2 ha quedado instalado y está en ejecución:



Es recomendable eliminar este archivo una vez realizada esta comprobación, ya que este archivo revela información sobre el servidor que podría ser utilizada por un atacante para comprometer la máquina.
0