Inestabilidad en el sistema, reinicios inesperados… pueden deberse a problemas de software y también de hardware. Para estar al tanto de estos últimos tenemos dos utilidades que no serán de utilidad: mcelog y rasdaemon.
Protege tus logs: logrotate + cifrado GPG
Logrotate necesita pocas presentaciones ya que es una herramienta clásica para el rotado de logs en nuestro sistema. Podemos configurarla conjuntamente con GPG de una manera sencilla para cifrar y proteger los logs rotados y que sólo puedan ser accesibles por personal autorizado en posesión de la clave de descifrado correspondiente.
Supervisión del sistema con psacct/acct y audit
Las herramientas audit y psacct/acct son de gran utilidad para tener controlado qué ocurre en nuestro sistema: qué usuarios han entrado a la máquina, acciones realizadas, procesos lanzados, etc… Aunque por el nombre puedan parecer lo mismo no lo son:
- Audit mediante un componente integrado como subsistema del Kernel Linux se encarga de capturar las llamadas a sistema de las aplicaciones para posteriormente mandar la información de dichas llamadas al demonio auditd. Éste se encarga de procesar dicha información y generar los logs de auditoría que podemos consultar con comandos como aureport, ausearch, aulast…
- La segunda herramienta tiene un nombre distinto según la distribución: psacct (Process Accounting) en RHEL/derivadas y acct (Accounting) en Debian/derivadas. Con esta herramienta podemos ver fácilmente qué usuarios entran a la máquina, qué comandos lanzan, etc… pudiendo detectar acciones u operaciones que comprometan la integridad del sistema.
Qué comandos instala un determinado paquete en nuestro sistema
Entradilla de domingo. Echando la vista tres años atrás acabé dando con un post sobre cómo dar con el paquete al que pertenece un determinado comando. Pues hoy toca artículo al revés: vamos a ver qué comandos se incorporan a nuestro sistema cuando instalamos un paquete.
Clúster JGroups independiente para cada Server Group en Jboss EAP 6.x+ modo dominio
Si utilizamos Jboss en modo dominio seguramente tengamos aplicaciones agrupadas en distintos Server Groups. Éstos a su vez estarán asociados a un Profile en concreto. En caso de ser HA podría ser:
<server-groups>
<server-group name="server-group-1" profile="ha">
<jvm name="default">
<heap size="1000m" max-size="1000m"/>
</jvm>
<socket-binding-group ref="ha-sockets"/>
</server-group>
<server-group name="server-group-2" profile="full-ha">
<jvm name="default">
<heap size="1000m" max-size="1000m"/>
</jvm>
<socket-binding-group ref="full-ha-sockets"/>
</server-group>
</server-groups>
Certification Authority Authorization (CAA) para nuestro dominio
Cuando intentamos emitir un certificado SSL para un dominio, suele existir un mecanismo por el cual tenemos que demostrar que somos propietarios de dicho de dominio. Resulta obvio ya que de lo contrario cualquiera podría emitir certificados para dominios ajenos.
Para reforzar este mecanismo de garantías ya presente en las principales Autoridades Certificadoras, la IETF elaboró el RFC 6844. En él se establece cómo implementar un nuevo tipo de registro DNS llamado Certification Authority Authorization (CAA). Este registro especifica qué Autoridades Certificadores están autorizadas a emitir certificados para un dominio en particular. El resumen del RFC es bastante claro: