Solucionar error: “Failed to download metadata for repo ‘appstream’: Cannot prepare internal mirrorlist: No URLs in mirrorlist” en centos 8.

por

Seguimos con los errores recurrentes, puede que nos haya pasado que al instalar algún paquete con yum en centos 8 nos haya salido el siguiente error: “Failed to download metadata for repo ‘appstream’: Cannot prepare internal mirrorlist: No URLs in mirrorlist”

Este error es debido a que centos ha cambiado las urls de descarga de los paquetes de los repositorios.

Pues con estos dos pequeños comandos te explico como solucionarlo.

Con el primer comando modificaremos la linea que contiene la variable mirrorlist de todos los ficheros de la carpeta /etc/yum.repos.d que empiecen por CentOS–, y la dejaremos comentada #mirrorlist.

sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-*

Y con el segundo comando descomentaremos la variable comentada #baseurl y añadiremos la nueva url de los repositorios de centos, baseurl=http://vault.centos.org/$contentdir/$releasever/AppStream/$basearch/os/

sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-*

Como paso final actualizamos con “yum clean all” los cambios y ya podremos instalar paquetes por repositorio con yum.

yum clean all

Como convertir certificado Let’s encrypt en keystore java para tomcat (jks)

por

Todos conocemos Let’s encrypt, en un servicio muy comido que nos permite instalar certificados SSL seguros de manera cómoda y gratuita.

Pero desgraciadamente no los crea en formato jks y no podemos utilizarlos en servidores de aplicaciones tomcat.

Pero esto lo podemos solucionar de una manera muy fácil utilizando las herramientas openssl y keytool que nos permiten convertirlo en formato jks.

Lo primero que haremos es con openssl exportar la clave privada (privkey1.pem) y el certificado (fullchain1.pem) y guardarlo en un fichero p12 (fichero.p12) con el siguiente comando:

openssl pkcs12 -export -out fichero.p12 -inkey privkey1.pem -in fullchain1.pem -name "tomcat-cert"

A continuación con keytool generaremos el llavero jks (llavero.jks) con el siguiente comando:

keytool -importkeystore -srckeystore fichero.p12 -srcstoretype pkcs12 -destkeystore llavero.jks

Y ya tendríamos el certificado keystore creado.

Lo ultimo que tendríamos que haces es configurar el server.xml de tomcat para que utiliza el llavero creado, añadiendo la password que usamos para su creación (en el ejemplo “secreta”).

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true" URIEncoding="UTF-8"
        keystoreFile="llavero.jks"
keystorePass="secreta" keyAlias="tomcat-cert"
clientAuth="false" sslProtocol="TLS" />

Poner certificado https en nginx con Let’s encrypt y Docker

por

Poner certificados https muchas veces nos da verdaderos dolores de cabeza, pero para solucionarnos este problema se crearon los certificados Let’s encrypt que de una manera sencilla nos permite utilizar certificados gratuitos y renovarlos periódicamente.

En esta entrada voy a explicar a poner el certificado en entornos con docker y lo primero que vamos a hacer es crear el docker-compose.yml donde crearemos el contenedor para el nginx.

version: '3'

services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
      - 443:443
    restart: always
    volumes:
      - ./nginx/conf.d/:/etc/nginx/conf.d/:ro

A continuación creamos el fichero de configuración del nginx ( ./nginx/conf.d/default.conf ) cambiando example.org pro nuestro dominio.

server {
    listen 80;
    listen [::]:80;

    server_name example.org www.example.org;
    server_tokens off;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://example.org$request_uri;
    }
}

Ahora arrancamos el contenedor y vemos como el nginx es accesible.

docker-compose up -d

El siguiente paso es crear el servicio certbot que se encargara de crear nuestro certificado editando el fichero docker-compose.yml.

version: '3'

services:

  webserver:
    image: nginx:latest
    ports:
      - 80:80
      - 443:443
    restart: always
    volumes:
      - ./nginx/conf.d/:/etc/nginx/conf.d/:ro
      - ./certbot/www/:/var/www/certbot/:ro
      - ./certbot/conf.d/:/etc/nginx/ssl/:ro

  certbot:
    image: certbot/certbot:latest
    volumes:
      - ./certbot/www/:/var/www/certbot/:rw
      - ./certbot/conf.d/:/etc/letsencrypt/:rw

Volvemos a lanzar el docker-compose para crear los directorios que utilizara certbot

docker-compose up -d

Una vez cambiado el docker-compose.yml lanzamos el comando para crear los certificados, cambiando el dominio example.org por el nuestro.

docker-compose run --rm  certbot certonly --webroot --webroot-path /var/www/certbot/ -d example.org

Una vez que ya tengamos los certificados creados editamos el fichero de configuración del nginx (./nginx/conf.d/default.conf) cambiando el dominio example.org por el nuestro.

En el ejemplo uso el nginx como proxy para servir un tomcat.

server {
    listen 80;
    listen [::]:80;

    server_name example.org www.example.org;
    server_tokens off;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://example.org$request_uri;
    }
}

server {
    listen 443 default_server ssl http2;
    listen [::]:443 ssl http2;

    server_name example.org;

    ssl_certificate /etc/nginx/ssl/live/example.org/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/live/example.org/privkey.pem;
    
    location / {
      proxy_pass      http://127.0.0.1:8080;
    }
}

Ya por ultimo paramos el contenedor del nginx y recreamos los contenedores.

docker stop nginx

docker-compose up -d

Y ya tendriamos nuestra web accesible con https y certificado seguro.

Como ultimo paso añado el comando que tenemos que utilizar cuando queramos renovar el certificado.

docker-compose run --rm certbot renew

Saltar error “rsync warning: some files vanished before they could be transferred”

por

Es muy común cuando sincronizamos ficheros con rsync encontrarnos este error (mas bien warning) rsync warning: some files vanished before they could be transferred

rsync warning: some files vanished before they could be transferred

Esto suele deberse a que rsync indexa los ficheros a sincronizar y cuando lo hace han desaparecido y suele ocurrir con ficheros temporales, los cuales son innecesarios pero nos da este error molesto.

Pues con este pequeño script os doy la solución para omitir estos errores, lo único que tenemos que hacer es usarlo cuando queramos sincronizar omitiendo ese warning.

cat rsync-vanished.sh

#!/bin/bash
(rsync "$@"; if [ $? == 24 ]; then exit 0; else exit $?; fi) 2>&1 | grep -v 'vanished'

Instalar certificado gratuito ssl con Let’s Encrypt en tomcat

por

Es comun utilizar Let’s Encrypt par poner certificados gratuitos seguros en nuestros dominios, ponerlos en apache o nginx es una tarea sencilla, pero todos hemos sufrido la tarea de poner un certificado seguro en un llavero (Java KeyStore) de tomcat.

Con esta pequeña entrada voy a explicar paso a paso como poner un certificado gratuito Let’s Encrypt en tomcat.

Para realizar los pasos necesitaremos tener instalado en el sistema keytool (viene con el jdk) y certboot (https://certbot.eff.org/).

Creamos un llavero JKS (letsencrypt.jks) con una clave RSA 2048, con la entrada de dominio (midominio.es)

keytool -genkeypair -alias simple-cert -keyalg RSA -keysize 2048 -keystore letsencrypt.jks -dname "CN=midominio.es" -storepass password12345

Agregamos una segunda clave RSA 4096 – (san-cert)

keytool -genkeypair -alias san-cert -keyalg RSA -keysize 4096 -keystore letsencrypt.jks -dname "CN=midominio.es" -storepass password12345

Creamos un CSR para simple-cert y un CSR para san-cert

keytool -certreq -alias simple-cert -keystore letsencrypt.jks -file midominio.csr -storepass password12345 -ext san=dns:midominio.es

Creamos el full certificate chain con certboot (certificado Let’s Encrypt).

certbot certonly --manual --csr midominio.csr --preferred-challenges "dns"

Nos creara una serie de certificados y debemos de quedarnos con el full certificate chain.

Successfully received certificate.

Certificate is saved at:            C:\Program Files (x86)\Certbot\bin\0000_cert.pem
Intermediate CA chain is saved at:  C:\Program Files (x86)\Certbot\bin\0000_chain.pem
Full certificate chain is saved at: C:\Program Files (x86)\Certbot\bin\0001_chain.pem
This certificate expires on 2023-03-07.

Añadimos el certificado al keystore (clic YES cuando pregunte).

keytool -importcert -alias simple-cert -keystore letsencrypt.jks -storepass password12345 -file 0001_chain.pem

Y ya tendriamos el certifiado creado y solo necesitariamos añadirlo en el fichero de configuración del tomcat (server.xml).

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true" URIEncoding="UTF-8"
keystoreFile="conf\ssl\letsencrypt.jks"
keystorePass="password12345" keyAlias="simple-cert"
clientAuth="false" sslProtocol="TLS" />

—- RENOVAR CERTIFICADO —-

Los certificados Let’s Encrypt , caducan a los tres meses, con lo que es posible que al intentar reniovarlo nos de problemas, lo unico que tendremos es que realizar los mismos pasos y cuando lancemoz el comando certbot, crear la entrada dns que nos pidan por consola.

Please deploy a DNS TXT record under the name:

_acme-challenge.midominio.es.

with the following value:

t8TpRgmScIuzwwrXgsCEhqt1VaV4s7EkxEziWoOCJ2h

Iniciar sesión en centos 7 sin contraseña con gnome

por

Nos habra pasado alguna vez que cuando usamos un entorno grafico nos da pereza andar metiendo la contraseña nmada mas iniciar sesión.

Con esta pequeña entrada voy a explicar como iniciar sesión en centos 7 con entorno grafico gnome.

Editaremos el fichero de configuración de gnome:

vi /etc/gdm/custom.conf

Y añadiremos lo siguiente debajo de default cambiando la variable nombre_usuario pro el usuario que queramos que inicie sesión sin contraseña:

AutomaticLoginEnable=true
AutomaticLogin=nombre_usuario

Guardamos el fichero y reiniciamos

Y ya podemos ver como iniciamos sesión sin introducir contraseña.

Como solucionar error The program can’t start because api-ms-win-core-path-l1-1-0.dll is missing from your computer

por

El otro dia estuve intentado instalar un certificado de let’s encrypt con certbot y me aparecido el siguiente error “The program can’t start because api-ms-win-core-path-l1-1-0.dll is missing from your computer” y buscando por internet observe que se trata de un error bastante comun y voy a explicar como solucionarlo con la siguiente entrada.

The program can’t start because api-ms-win-core-path-l1-1-0.dll is missing from your computer

Este error es debido a que la libreria api-ms-win-core-path-l1-1-0.dll no se encuentra en el sistema y no solo sucede al intenter ejectuar certbot sino que tambien falla con la suite adobe, blender, EAdesktop y un sin fin de aplicaciones.

Yo lo resolvi descagando la libreria del siguiente repositorio de github https://github.com/nalexandru/api-ms-win-core-path-HACK/releases/download/0.3.1/api-ms-win-core-path-blender-0.3.1.zip dejandola en el directorio de instalación de certbot C:\Program Files (x86)\Certbot\bin permitiendo ejecutar la aplicación sin problemas.

Si queremos que forme parte de las librerias del sistema solo tendriamos que dejarla en los directorios C:\Windows\System32 y C:\Windows\SysWOW64

Por ultimo dejo la libreria descargable desde la web, para tenerla mas a mano:

api-ms-win-core-path-blender-0.3.1Descarga

Insertar caracteres UTF8 en Oracle con SQLPLUS desde windows.

por

Por todos son conocidos los quebraderos de cabeza que nos das los caracteres especiales en el dia a dia a los informáticos.

La logica la conocemos, se invento UTF8 como standard para corregir esos problemas, pero aun asi siguen apareciendo.

O voy a intentar explicar como corregir un error recurrente, cuando insertamos en una bbdd Oracle la cual ya se encuentra en UTF8 y aun asi los caraceres se ven de manera incorrecta.

Esto no es debido a la bbdd Oracle si no al propio cliente desde donde si inserta y en este caso el problema viene causado por windows y su uso de propias codificaciones de caracteres.

Lo unico que tenemos que hacer para corregir esto consiste en setear la variable NLS_LANG con la codificacion UTF8 antes de arrancar el SQLPLUS.

Abrimos una consola cmd de windows y seteamos la variable NLS_LANG

set NLS_LANG=.AL32UTF8

Y ya podemos conectar a Oracle y hacer inserciones en SQLPLUS.

SQLPLUS

Opción 2.

Si queremos dejar la configuración de manera persistente , siempre podemos añadirla como variable del sistema.

Variable de entorno

Aumentar el tamaño máximo en la carga de ficheros en IIS

por

El IIS recién instalado tiene configurado por defecto con un tamaño máximo de subida de 30.000.000 bytes, o lo que es lo mismo 28,61MB.

Dicho valor se puede modificar, ya que no es un limite real y lo podemos configurar con el tamaño que queramos.

Para cambiar el valor debemos seguir los siguientes pasos:

Desde la interfaz gráfica del IIS, hacemos clic en el sitio web y doble clic en “Request filtering“

Dentro del menú “Request Filtering” hacemos clic con el botón derecho y seleccionamos “Edit Feature Settings…”

En el siguiente menú se nos mostrará una ventana donde podemos configurar varios valores, entre ellos “Maximun allowed content length (Bytes)“, con el valor por defecto establecido (30000000), donde cambiaremos el valor por el que mas se adapte a nuestras necesidades.

Una vez cambiado el valor, solo tendremos que reiniciar el servicio web IIS y ya habremos aumentando el tamaño máximo de subida para los ficheros.

Reconstruir y optimizar indices fragmentados en SQL Server

por

Es muy común en SQL server que si una tabla tiene muchos cambios de estado, inserciones, borrados, etc, los indices queden fragmentados y las consultas a base de datos sean cada vez mas pesadas.

Pues con esta pequeña entrada voy a explicar como consultar el porcentaje de fragmentación de las tablas y como reconstruirlas y optimizarlas.

Lo primero que haremos es lanzar esta query que nos dirá el porcentaje de fragmentacion de las tablas.

SELECT 
dbtables.[name] as 'Table',
indexstats.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID() 
ORDER BY indexstats.avg_fragmentation_in_percent desc
Porcentaje de fragmentación de cada tabla

Una vez visto que los porcentajes de fragmentación son altisimos, lanzamos esta query que reconstruye todos los indices de las tablas.

DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE @fillfactor INT
SET @fillfactor = 80 
DECLARE TableCursor CURSOR FOR
SELECT QUOTENAME(OBJECT_SCHEMA_NAME([object_id]))+'.' + QUOTENAME(name) AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3),@fillfactor) + ')'
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO
Porcentajes de fragmentación con indices de las tablas reconstruidas

Lanzamos estas querys periódicamente conseguiremos mantener las bases de datos en un estado optimo.