Ubuntu. Solucionar apt-get update “the following signatures couldn’t be verified because the public key is not available”

Introducción

Para solucionar el problema he recurrido a Chris Jean 

Quiero utilizar el programa Sikulix para probar software, y para utilizar la parte de OCR para buscar texto, se necesita innstalar el OCR Tesseract 4.0.1 mínimo, y resulta que la clave pública no está en mi sistema y por tanto no se pueden instalar estos paquetes.

He hecho lo siguiente:

1. Cargar el repositorio

sudo add-apt-repository ppa:alex-p/tesseract-ocr

con lo que me sale una ratahila de mensajes y en concreto uno de ello me dice:

Las firmas siguientes no se han podido verificar porque la clave pública no está disponible: NO_PUBKEY F7E06F06199EF2F2

2. Actualizar el software

sudo apt-get update

y constesta entre otras cosas.

Las firmas siguientes no se han podido verificar porque la clave pública no está disponible: NO_PUBKEY F7E06F06199EF2F2

N: No se puede actualizar de un repositorio como este de forma segura y por tanto est desactivado per omisión.

N: Mire la página de manual apt-secure(8) para ver los detalles sobre la creación de repositorios y la configuración de usuarios.

3. Para añadir las claves públicas, Chris propone:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F7E06F06199EF2F2

Vamos a probar a ver si ya se puede instalar el software.

Sikulixpara ello hacemos:(Sikulix-RaiMan)

sudo add-apt-repository ppa:alex-p/tesseract-ocr
sudo apt-get update
sudo apt install tesseract-ocr
sudo apt install libtesseract-dev
sudo ldconfig

y para ver la version

tesseract -v

Que nos devuelve:

tesseract 4.1.1

 leptonica-1.78.0

  libgif 5.1.4 : libjpeg 8d (libjpeg-turbo 1.5.2) : libpng 1.6.34 : libtiff 4.0.9 : zlib 1.2.11 : libwebp 0.6.1 : libopenjp2 2.3.0

 Found AVX2

 Found AVX

 Found FMA

 Found SSE

 Found libarchive 3.2.2 zlib/1.2.11 liblzma/5.2.2 bz2lib/1.0.6 liblz4/1.7.1

Con lo que ya lo tenemos instalado

Certificados en Java (3). Configurar JBoss Server con https. autentificacion del cliente con certificado.

 1. Introducción

En el fichero server.xml se indica donde localizar los certificados

para encontralo, si se sabe que cuelga de "/opt" se puede probar con este comando

find /opt -name server.xml -print

Y nos salen

/opt/jboss-X.X.X.ZZ/server/all/deploy/jboss-web.deployer/server.xml
/opt/jboss-X.X.X.ZZ/server/default/deploy/jboss-web.deployer/server.xml

Parece ser que el segundo fichero es el correcto.

Miramos el contenido del fichero, y solamente la parte que nos interesa es:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
               keystoreFile="${jboss.server.home.dir}/conf/myjbosscert.p12" keystorePass="mypassword" keystoreType="PKCS12"
               truststoreFile="${jboss.server.home.dir}/conf/server.truststore" truststorePass="otherpassword" truststoreType="JKS" />

Ahora hay que cambiar myjbosscert.p12 por el nuevo certificado y tener en cuenta la nueva contraseña e indicarlo en el fichero server.xml

OJO: solo se puede activar para que vea los certificados como jks o como PKCS12. Por tanto hay que tener cuidado y leerse la documentación para no terner problemas, y ver que está activado el APR para utilizar certificados ".p12" (PKCS12) 

2. Pero y si tenemos un certificado en formato crt?

Para ello tenemos que convertirlo a p12 y para ello hacemos

openssl pkcs12 -export -in myjbosscert.crt -inkey myjboss.key -out myjbosscert.p12 -name myjboss -CAfile myCA.pem -caname root -chain

Donde myjboss.key es la clave que hemos creado para el servidor

y myCA.pem es el certificado X509 de la entidad certificadora.

Lo que hacemos es que añadimos la cadena de certificados al almacén PKCS12

NO ES OBLIGADO e incluso puede ser recomendable en ciertos casos no utilizar las opciones 

   -name myjboss    ni tampoco

   -caname root 

Y nos pedirá una contraseña.

NOTA: Al convertir un certificado de X509 v3 (con datos adicionales como los diversos SAN o "nombre-maquina+dominio" alternativos), parece que se pierde parte de esta información adicional. Si queremos ver el certificado resultante y sabiendo la contraseña que nos pide anteriormente podemos hacer:

openssl pkcs12 -nokeys -info -in ximodante.p12 -passin pass:mypassword

OJO: este comando no muestra las SAN o DNS alternativos!!, pero si instalamos este certificado en un Tomcat y accedemos a este servidor desde Firefox y le decimos que muestre el certrificado de servidor, SI QUE NOS MUESTRA LOS SAN!!!!!

3. Apuntes de José María del Ayuntamiento de Mula

 1. En el servidor de la SEDE tenéis que modificar el nombre del certificado y pass en el server.xml de 

/opt/jboss-4.2.3.GA/server/default/deploy/jboss-web.deployer/server.xml

2. En Backoffice para el SELLO es en keystore.properties de la ruta 

/opt/jboss-4.2.3.GA/server/default/conf/keystore.properties

 

ECLIPSE muy lento, ¿Cómo espabilarlo?

En máquinas obsoletas, las nuevas versiones de eclipse van muy lentas, para agilizar un poco se puede hacer:

1. Quitar la opción de               Project   -> Build Automatically
2. Quitar la validación de JPA: Window-> Preferences -> Validation -> Buscar el JPA de la tabla y desmarcarlo.

Ahora cuando queramos ejecutar en el servidor:

La primera vez al abrir el workspace:

1. Botón derecho sobre el proyecto: Run As --> Maven Clean
2. Botón derecho sobre el proyecto: Maven  --> Update project
3. Apretar el icono de Build

Cuando no se hagan cambios muy significativos, solo se apretara el iocono del Build.

ERROR: no encuentra void com.sun.mail.util.TraceInputStream.(java.io.InputStream, com.sun.mail.util.MailLogger)

 Si se ejecuta en modo aplicación no da ningún problema pero en modo web con Tomcat si los da.

Parece ser segun stackoverflow que hay que añadir la dependencia de maven smtp, a pesar de que hay dependencia a javax.mail y simple-java-mail

<dependency>
  <groupId>com.sun.mail</groupId>
  <artifactId>smtp</artifactId>
  <version>${smtp.version}</version>
</dependency>
        
<dependency>
  <groupId>com.sun.mail</groupId>
  <artifactId>javax.mail</artifactId>
  <version>${javax.mail.version}/version>
</dependency>

<dependency>
  <groupId>org.simplejavamail</groupId>
  <artifactId>simple-java-mail</artifactId>
  <version>${simple-java-mail.version}></version>
</dependency>

STAX2-API: Error en Eclipse + Tomcat: Caused by: java.lang.NoSuchMethodError: 'org.codehaus.stax2.ri.SingletonIterator org.codehaus.stax2.ri.SingletonIterator.create(java.lang.Object)'

Problema

 El Tomcat no arranca, y es consecuencia de que se han declarado mas de una version de "stax2-api".

Por tanto hay que entrar en el "pom.xml" y comentar las declaraciones duplicadas de dependencias de stax2-api de diferentes versiones.

Esta duplicidad se produce debido a que los test de clases básicas que contienen Hibernate Envers necesitan estas declaraciones en <scope>runtime</scope> para funcionar, mientras en modo web no funcionan. Ver stackoverflow. Y ver también post anterior.

Por tanto cuando se ejecuten los test en modo java application (y no en modo web) hay que descomentarlo

Solución 1

20/01/2022. Se puede solucionar lo de Hibernate Envers utilizando la nueva implementación de jakarta que no utiliza el stax2-api

implementation 'org.hibernate:hibernate-core-jakarta:5.6.3.Final'
implementation 'org.hibernate:hibernate-envers-jakarta:5.6.3.Final'
//implementation "org.hibernate:hibernate-testing-jakarta:5.6.3.Final'
implementation "org.hibernate:hibernate-validator:7.0.2.Final" 

Solución 2

Utilizar Maven shadow plugin o Gradle shadow plugin

MULTIPLE CONTEXTS: Error en Eclipse + Tomcat: Could not publish server configuration for Tomcat. Multiple Contexts have a path of..

 Según StackOverflow, hay que entrar en la carpeta "Servers" y buscar un duplicado de "<Context ....></Context> y borrarlo

Conflicto de librerias de Hibernate Envers: java.lang.NoSuchMethodError: org.codehaus.stax2.ri.EmptyIterator.getInstance()

Problema (ir al apartado de solución)

El problema viene que hay un conflicto de dependencias de la stax2-api pues se uilizan distintas versiones.

El sistema de compilación de Maven parece ser que elimina las versiones mas viejas, por tanto cualquier referencia a métodos que se encuentren excluisivamente en versiones viejas, dan error de "runtime" que en este caso indica que no encuentra el método.

Para solucionarlo hacemos uso de <scope>runtime</scope> en cada una de las dependencias antigua que queremos.

Su suso está bien explicado en Baeldung y en mi caso tenía que suministrar las versiones 4.2.1 y la 3.1.4

Quedando en el pom.xml este fragmento

<dependency>
  <groupId>org.codehaus.woodstox</groupId>
  <artifactId>stax2-api</artifactId>
  <version>4.2.1</version>
  <scope>runtime</scope>
</dependency>
		 
<dependency>
  <groupId>org.codehaus.woodstox</groupId>
  <artifactId>stax2-api</artifactId>
  <version>3.1.4</version>
  <scope>runtime</scope>
</dependency>

Con esta adición de dependencias parece ser que se ha solucionado si se ejecuta como Java applicaion pero no en modo web

Por tanto para ejecutar una clase que abra una sesion de JPA Hibernate que haga uso de Hibernate Envers con la anotiación @Audited en una Entidad como la clase FirstControlLoad, hay que añadir este código al pom-xml, pero hay que quitarlo para generar el war!!!

Solución buena

20/01/2022. Se puede solucionar lo de Hibernate Envers utilizando la nueva implementación de jakarta que no utiliza el stax2-api

implementation 'org.hibernate:hibernate-core-jakarta:5.6.3.Final'
implementation 'org.hibernate:hibernate-envers-jakarta:5.6.3.Final'
//implementation "org.hibernate:hibernate-testing-jakarta:5.6.3.Final'
implementation "org.hibernate:hibernate-validator:7.0.2.Final"