Como reiniciar el gnome-shell sin cerrar la sesion

A veces el gnome-shell no responde correctamente, por ejemplo no funciona llevar el ratón a la esquina superior izquierda, pero las aplicaciones esta funcionando correctamente.

¿Se puede arreglar el gnome-shell sin cerrar nada? Si

El camino más fácil es pretando ALT + F2, sale un dialogo que pide un comando, escribir “r” y pulsar ENTER.

Si no tambien se podria desde un terminal ejecutar el siguiente comando:

killall -3 gnome-shell Hay otros métodos pero cierran las aplicaciones.

Probar una nueva versión de un servicio en un nuevo servidor plug/unplug

Algo muy común  cuando administramos servidores es redireccionar tráfico.

Supongamos que tenemos un servidor con determinados servicios funcionando. Y queremos migrar o probar en producción una nueva versión que va en un nuevo servidor (por ejemplo porque estamos migrando de tecnologia o de versión de servidor, etc…) , pero que sea muy facil volvera la versión vieja ante cualquier problema no detectado en periodo de test.

Lo normal y más frecuente sería simplemente cambiar la IP en el registro DNS, no obstante si alguien estaba usando la IP en vez del subdominio se verá afectado.

 ¿Qué se puede hacer? Simple, redireccionar el tráfico que reciba ese servidor por ese puerto hacia otro servidor con el mismo puerto.

¿Cómo empezamos?

Lo primero será que debemos tener habilitado el forwarding en el servidor, para ello pondremos lo siguiente:

echo "1" > /proc/sys/net/ipv4/ip_forward

CentOS:
sysctl net.ipv4.ip_forward=1
Luego reiniciaremos la red:

service networking restart

CentOS sería:

service nertwork restart

Ahora ya se puede redireccionar:

iptables -t nat -A PREROUTING -p tcp --dport <puerto receptor> -j DNAT --to-destination <ip final>:<puerto de ip final>

Supongamos que deseamos redireccionar todo el tráfico que recibe nuestro servidor por el puerto 8080 hacia otro servidor (ej: 10.2.3.3), que igual recibirá ese tráfico por el 8080 (pues se trata del mismo servicio):

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.2.3.3:8080

El servidor 10.2.3.3 verá que todos los paquetes o peticiones vienen desde la IP del cliente, en caso de que quieran natear las peticiones, o sea, que el 2º servidor vea que las peticiones llegan con la IP del 1er servidor, sería poner además esta segunda línea:

iptables -t nat -A POSTROUTING -j MASQUERADE

 

Otras opciones

Redireccionar el tráfico que viene de una IP específica:

iptables -t nat -A PREROUTING -s 10.2.3.85 -p tcp --dport 8080 -j DNAT --to-destination 10.2.3.3:8080

Redireccionar el tráfico de un segmento de red:

iptables -t nat -A PREROUTING -s 10.2.3.0/24 -p tcp --dport 8080 -j DNAT --to-destination 10.2.3.3:8080

Redireccionar el tráfico que llegue por una interfaz específica:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.2.3.3:8080

Gnome: Abrir un aventana con terminales ya creados

Con este comando abrimos una ventana nueva de terminales:

gnome-terminal -e “$var_path/gnome_terminals_prod.sh”

Y con este creamos las pestañas que queremos en esa ventana:

gnome-terminal –title=”Entorno de test” –tab –command “bash -c ‘ssh -t cli1.neodoo.test  –tab –command “bash -c ‘ssh -t cli2.neodoo.test” –tab –command “bash -c ‘ssh -t services1.neodoo.test ” –tab –command “bash -c ‘ssh -t lb1.neodoo.test ” –tab –command “bash -c ‘ssh -t ws1.neodoo.test” –tab –command “bash -c ‘ssh -t rest1.neodoo.test ‘”

Esto combinado con la autentificación por clave privada, hace que tengamos en un segundo acesso a todos los servidores.

NGREP: Poder ver todas las peticiones http y sus respuestas en linux

Se puede descargar de aqui:

http://ngrep.sourceforge.net/usage.html

Con esta linea podemos mandar a un log todas las peticiones y las respuestas en texto claro:

ngrep -W byline port 8080 > request_http.log

Esto se puede usar por ejemplo para ver que los XML que se envian en las llamadas SOAP a un servicio y despues poder reproducirlos usando SoapUI.

Crear enlace simbólico que si se monta en otro servidor no resuelva el enlace en local

El caso es tener un enlace simbólico en una maquina:

ln -s /usr/java/wildfly-10.0.0.Final wildfly

Y montar por ejemplo por sshfs ese maquina.

Al intentar acceder a ese enlace simbólico, este se resuelve en local en la máquina 2 y no se accede al que realmente se quiere que es el de la máquina 1.

Para que esto no pase, hay que crear el enlace simbólico con la opción “-r”:

ln -sr /usr/java/wildfly-10.0.0.Final wildfly

Wildfly: Habilitar el HTTP2

HTTP/2 es el nuevo protocolo  para mejorar la experiecia de navegación de la web.

Tendrá menos latencia y más velocidad siendo más eficiente.

Se pubicó oficialmente en 2015 y los principales navegadores como Mozilla Firefox, Google Chrome y Microsoft Edge ya lo soportan.

Desde Wildfly 9.0.0.Beta1 se libero el soporte para HTTP2.

Se requiere una extensión que se llama ALPN (application layer protocol negotiation).

El soporte para ALPN vendrá en Java 9, y no esta presente en JDK7 y JDK8.

Asi que para poder usarlo hay que proveer su soporte en el classpath de arranque de la JVM.

Toda la información sobre el APLN y donde descargar el soporte en :

http://www.eclipse.org/jetty/documentation/current/alpn-chapter.html

Y descargar en :

http://central.maven.org/maven2/org/mortbay/jetty/alpn/alpn-boot/

Aunque no se obliga en la RFC, los navegadores obligan a que el HTTP2 sea por TLS, asi que necesitaremos un certificado. Para hacer pruebas podemos generarnos uno autofirmado:

$ keytool -genkeypair -alias server -storetype jks -keyalg RSA -keysize 2048 -keypass cambiame -keystore wfly.jks -storepass cambiame -dname "CN=server.neodoo.es,OU=inf,L=Zaragoza,ST=Zaragoza,C=ES" -validity 9999 -v

$ cp wfly.jks $JBOSS_HOME/standalone/configuration/

Nota: Y para producción podemos conseguir uno gratuito en “letsencrypt.org” (es una autoridad certificadora libre, abierta, gratis y reconocida por los principales navegadores)

Hay que añadir el certificado en un almacen de certificados de confianza de Java:

Exportarlo del almacen:

$ keytool -exportcert -keystore wfly.jks -alias server -storepass cambiame -file server.cer

Importalo en el almacen de confianza:

$ keytool -importcert -keystore v.truststore -alias server -storepass cambiame -file server.cer -noprompt

 

Configurar el Wildfly

Crear un realm para el SSL que use el certificado que hemos creado:

<security-realm name=”UndertowRealm”>
<server-identities>
<ssl>
<keystore path=”wfly.jks” relative-to=”jboss.server.config.dir” keystore-password=”cambiame” alias=”comet” key-password=”cambiame”/>
</ssl>
</server-identities>
<authentication>
<truststore path=”wfly.truststore ” relative-to=”jboss.server.config.dir” keystore-password=”cambiame”/>
</authentication>
</security-realm>

Añadir un conector al Undertow para HTTPS que use ese realm:

<https-listener name=”default-https” enable-http2=”true” security-realm=”UndertowRealm” socket-binding=”https”/>

Ahora sólo falta poder en soporte de APLN en el arranque del Wildfly:-Xbootclasspath/p:$JBOSS_HOME/bin/alpn-boot-8.1.7.v20160121.jarY quedará asi:
JAVA_OPTS=”-Xms1024m -Xmx1024m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=512m -Djava.net.preferIPv4Stack=true -Xbootclasspath/p:$JBOSS_HOME/bin/alpn-boot-8.1.7.v20160121.jar”

Nota: La versión del APLN depende de la version del JDK y de su update.

 

Nota extra: A mi con la JDK 1.8.0_74 y el APLN alpn-boot-8.1.7.v20160121.jar me falla, he tenido que poner la 1.8.0_72.

 

Ahora si tenemos algún balanceador o proxy HTTP esto tiene otras restricciones:

HAPROXY: Será soportado por la versión 1.7 que a dia de hoy aun esta en Beta

NGINX: Es soportado por la versión 1.9.5

UNDERTOW: Ya lo soporta

APACHE: Esta soportado a partir de la versión 2.4.17 usando los modulos del mod_ssl y mod_http2

 

Como saber si una página esta ofrecida en HTTP2. Pues se puede hacer con un plugin. Yo en Firefox uso este:

https://github.com/chengsun/moz-spdy-indicator