One place for hosting & domains

      Cómo funcionan los enlaces de ciclo de vida de Vue.js


      Introducción

      Los enlaces de ciclo de vida son una ventana para ver cómo la biblioteca que está usando funciona en segundo plano. Los enlaces de ciclo de vida le permiten saber cuándo se crea su componente, se añade al DOM, se actualiza o se destruye.

      Este diagrama de la documentación oficial de Vue.js captura el ciclo de vida de la instancia Vue.js:

      Diagrama del ciclo de vida de la instancia Vue.js

      Este artículo le explicará los enlaces de creación, montaje, actualización y destrucción.

      Cómo funcionan los enlaces de creación (inicialización)

      Los enlaces de creación son los primeros enlaces que se ejecutan en su componente. Le permiten realizar acciones antes de que su componente haya sido añadido al DOM. A diferencia de cualquier otro enlace, los enlaces de creación también se ejecutan durante la renderización del lado del servidor.

      Utilice los enlaces de creación si necesita configurar cosas en su componente, durante la renderización del cliente y la renderización del servidor.

      No tendrá acceso al DOM o al elemento de montaje objetivo (this.$el) dentro de los enlaces de creación.

      beforeCreate

      El enlace beforeCreate se ejecuta en el momento de inicializar su componente. Los datos no se han hecho reactivos y los eventos no se han configurado aún:

      ExampleComponent.vue

      <script>
      export default {
        beforeCreate() {
          console.log('At this point, events and lifecycle have been initialized.')
        }
      }
      </script>
      

      En este ejemplo, cuando el enlace beforeCreate se ejecuta, este fragmento de código registrará el mensaje: en este momento, los eventos y el ciclo de vida se han inicializado.

      created

      Puede acceder a los datos reactivos y a los eventos que están activos con el enlace created. Las plantilla y Virtual DOM no han sido montados aún o renderizados:

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{ propertyComputed }}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            property: 'Example property.'
          }
        },
      
        computed: {
          propertyComputed() {
            return this.property
          }
        },
      
        created() {
          console.log('At this point, this.property is now reactive and propertyComputed will update.')
          this.property = 'Example property updated.'
        }
      }
      </script>
      

      En este ejemplo, el fragmento de código almacenará property como Example property. Cuando se ejecuta el enlace created, se registrará un mensaje de At this point, this.property is now reactive and propertyComputed will update. y, luego, property se cambia a Example property updated.

      Más adelante en el ciclo de vida, {{ propertyComputed }} aparecerá como Example property updated, en vez de como Example property.

      En este paso, ha revisado algunos ejemplos de enlaces de creación y está listo para pasar a la siguiente parte del ciclo de vida, los enlaces de montaje.

      Cómo funcionan los enlaces de montaje (inserción DOM)

      Los enlaces de montaje a menudo son los enlaces más usados. Le permiten acceder a su componente inmediatamente antes y después de la primera renderización. Sin embargo, no se ejecutan durante la renderización del lado del servidor.

      Utilice enlaces de montaje si necesita acceder o modificar el DOM de su componente inmediatamente antes o después de la renderización inicial.

      No utilice los enlaces de montaje si necesita obtener algunos datos para su componente durante la inicialización.

      Nota: Utilice created (o created y activated para los componentes de keep-alive) para esto. Especialmente si necesita esos datos durante la renderización del lado del servidor.

      beforeMount

      El enlace beforeMount se ejecuta justo antes de que se produzca la renderización inicial y tras compilarse las funciones de plantilla o renderización:

      ExampleComponent.vue

      <script>
      export default {
        beforeMount() {
          console.log(`At this point, vm.$el has not been created yet.`)
        }
      }
      </script>
      

      En este ejemplo, cuando se ejecuta el enlace beforeMount, este fragmento de código registrará el mensaje: At this point, vm.$el has not been created yet..

      mounted

      En el enlace mounted, tendrá acceso completo al componente reactivo, las plantillas y DOM renderizado (a través de this.$el).

      Utilice mounted para modificar el DOM, sobre todo cuando integra bibliotecas no Vue:

      ExampleComponent.vue

      <template>
        <div ref="example-element">Example component.</div>
      </template>
      
      <script>
      export default {
        mounted() {
          console.log(`At this point, vm.$el has been created and el has been replaced.`);
          console.log(this.$el.textContent) // Example component.
        }
      }
      </script>
      

      En este ejemplo, cuando se ejecuta el enlace mounted, este fragmento de código registrará el mensaje At this point, vm.$el has been created and el has been replaced.. Además, se registrará un mensaje de Contenido de ejemplo (this.$el.textContent).

      En esta sección, exploró casos de uso para los enlaces de montaje. En el siguiente paso, revisó algunos ejemplos que usan los enlaces de actualización.

      Comprender los enlaces de actualización (Diff y Re-render)

      Los enlaces de actualización se invocan siempre que una propiedad reactiva usada por su componente cambie u otra cosa haga que se vuelva a renderizar. Le permiten engancharse al ciclo watch-compute-render para su componente.

      Utilice los enlaces de actualización si necesita saber cuándo se vuelve a renderizar su componente, quizá para depurar o perfilar.

      No utilice ganchos de actualización si necesita saber cuándo cambia una propiedad reactiva en su componente. Utilice propiedades computadas o vigilantes para eso.

      beforeUpdate

      El enlace beforeUpdate se ejecuta cuando los datos cambian en su componente, y el ciclo de actualización se inicia, justo antes de que el DOM se corrija y vuelva a renderizar.

      Utilice beforeUpdate si necesita obtener el nuevo estado de cualquier dato reactivo en su componente antes de que se renderice realmente.

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        beforeUpdate() {
          console.log(`At this point, Virtual DOM has not re-rendered or patched yet.`)
          // Logs the counter value every second, before the DOM updates.
          console.log(this.counter)
        }
      }
      </script>
      

      Primero, este fragmento de código guardará counter como 0. Cuando se ejecute el enlace created, aumentará counter cada 1000 ms. Cuando el enlace beforeUpdate se ejecuta, este fragmento de código registrará el mensaje: En este momento, Virtual DOM no se ha vuelto a renderizar ni se ha parcheado y se registra un número para counter,

      updated

      El enlace updated se ejecuta cuando cambian los datos en su componente y el DOM se vuelve a renderizar.

      Use updated si necesita acceder al DOM tras cambiar una propiedad:

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        updated() {
          console.log(`At this point, Virtual DOM has re-rendered and patched.`)
          // Fired every second, should always be true
          console.log(+this.$refs['example-element'].textContent === this.counter)
        }
      }
      </script>
      

      Primero, este fragmento de código guardará counter como 0. Cuando el enlace created se ejecute, incrementará counter cada 1000 ms. Cuando se ejecuta el enlace updated, este fragmento de código registrará el mensaje: En este momento, Virtual DOM se ha vuelto a renderizar y parcheado y se registra un valor booleano de true porque el valor renderizado y el valor actual con iguales.

      Ahora que ha explorado el uso de los enlaces de actualización, está listo para aprender sobre los enlaces de destrucción.

      Comprender los enlaces de destrucción (Desmontaje)

      Los enlaces de destrucción le permiten realizar acciones cuando se destruye su componente, como la limpieza o el envío de análisis. Se activan cuando su componente se desmonta y elimina del DOM.

      beforeDestroy

      beforeDestroy se activa justo antes del desmontaje. Su componente seguirá estando completamente presente y funcional.

      Utilice beforeDestroy si necesita limpiar eventos o suscripciones reactivas:

      ExampleComponent.vue

      <script>
      export default {
        data() {
          return {
            exampleLeakyProperty: 'This represents a property that will leak memory if not cleaned up.'
          }
        },
      
        beforeDestroy() {
          console.log(`At this point, watchers, child components, and event listeners have not been teared down yet.`)
          // Perform the teardown procedure for exampleLeakyProperty.
          // (In this case, effectively nothing)
          this.exampleLeakyProperty = null
          delete this.exampleLeakyProperty
        }
      }
      </script>
      

      Este fragmento de código primero almacenará exampleLeakyProperty. Cuando el enlace beforeDestroy se ejecuta, este fragmento de código registrará el mensaje En este momento, los vigilantes, componentes secundarios y oyentes de eventos no hay sido desmontados aún y luego se elimina exampleLeakyProperty.

      destroyed

      Cuando llegue al enlace destroyed, su componente estará prácticamente vacío. Todo lo que estaba unido a él se ha destruido.

      Utilice destroyed si necesita realizar cualquier limpieza de último minuto o informar a un servidor remoto que el componente se ha destruido.

      ExampleComponent.vue

      <script>
      import ExampleAnalyticsService from './example-analytics-service'
      
      export default {
        destroyed() {
          console.log(`At this point, watchers, child components, and event listeners have been torn down.`)
          console.log(this)
          ExampleAnalyticsService.informService('Component destroyed.')
        }
      }
      </script>
      

      Primero, este fragmento de código importará ExampleAnalyticsService. Cuando se ejecute el enlace beforeDestroy, este fragmento de código registrará el mensaje At this point, watchers, child components, and event listeners have been torn down.. Lo que queda del componente se registrará en la consola y a ExampleAnalyticsService se pasará el mensaje Componente destruido.

      Con eso, completó su revisión general de los enlaces de ciclo de vida de Vue.js.

      Otros enlaces

      Hay otros dos enlaces, activated y deactivated. Estos son para los componentes keep-alive, un tema que está fuera del alcance de este artículo.

      Es suficiente decir que le permiten detectar cuando un componente que está envuelto en una etiqueta <keep-alive><keep-alive> se activa o desactiva. Es posible que los use para buscar datos para su componente o administrar los cambios de estado, comportándose de forma efectiva como created y beforeDestroy sin la necesidad de realizar una reconstrucción completa del componente.

      Conclusión

      En este artículo, hemos explicado los diferentes enlaces de ciclo de vida disponibles en el ciclo de vida de la instancia Vue.js. Ha explorado los diferentes casos de uso para los enlaces de creación, los enlaces de montaje, los enlaces de actualización y los enlaces de destrucción.

      Si desea saber más sobre Vue.js, consulte nuestra página del tema Vue.js para consultar ejercicios y proyectos de programación.



      Source link

      Cómo usar los parámetros de consulta en Angular


      Introducción

      Los parámetros de consulta en Angular permiten pasar los parámetros opcionales a través de cualquier ruta en la aplicación. Los parámetros de consulta son diferentes a los parámetros de ruta regulares, que solo están disponibles en una ruta y no son opcionales (por ejemplo, /product/:id).

      En este artículo, nos referiremos a un ejemplo de una aplicación que muestra una lista de productos. Proporcionaremos valores de order opcional y price-range en los que el componente receptor puede leer y actuar. Los valores proporcionados afectarán el orden y filtrado de la lista de productos.

      Uso de parámetros de consulta con Router.navigate

      Si navega a la ruta de forma imperativa usando Router.navigate, pasará los parámetros de consulta con queryParams.

      En nuestro ejemplo, si queremos enrutar visitantes a los productos con la lista ordenada por popularidad, se verá así:

      goProducts() {
        this.router.navigate(["https://www.digitalocean.com/products"], { queryParams: { order: 'popular' } });
      }
      

      Esto dará como resultado una URL con el siguiente aspecto:

      http://localhost:4200/products?order=popular
      

      También puede proporcionar múltiples parámetros de consulta. En nuestro ejemplo, si queremos enrutar visitantes a los productos con la lista ordenada por popularidad y filtrada con un alto rango de precios, se verá así:

      goProducts() {
        this.router.navigate(["https://www.digitalocean.com/products"], { queryParams: { order: 'popular', 'price-range': 'not-cheap' } });
      }
      

      Esto dará como resultado una URL con el siguiente aspecto:

      http://localhost:4200/products?order=popular&price-range=not-cheap
      

      Ahora ya sabe cómo puede usar queryParams para configurar los parámetros de consulta.

      Conservar o combinar parámetros de consulta con queryParamsHandling

      De forma predeterminada, los parámetros de consulta se pierden en cualquier acción de navegación posterior. Para evitar esto, puede configurar queryParamsHandling, ya sea para 'preserve' o 'merge'.

      En nuestro ejemplo, si queremos enrutar visitantes desde una página con el parámetro de consulta { order: 'popular' } a la página /users, manteniendo los parámetros de consulta, usaremos 'preserve':

      goUsers() {
        this.router.navigate(['/users'], { queryParamsHandling: 'preserve' });
      }
      

      Esto dará como resultado una URL con el siguiente aspecto:

      http://localhost:4200/users?order=popular
      

      En nuestro ejemplo, si queremos enrutar visitantes desde una página con el parámetro de consulta { order: 'popular' } a la página /users, pasando el parámetro de consulta { filter: 'new' }, usaremos 'merge':

      goUsers() {
        this.router.navigate(['/users'], { queryParams: { filter: 'new' }, queryParamsHandling: 'merge' });
      }
      

      Esto dará como resultado una URL con el siguiente aspecto:

      http://localhost:4200/users?order=popular&filter=new
      

      Nota: Conservar los parámetros de consulta utilizados para hacerse con preserveQueryParams configurado en true, pero esto ahora es obsoleto en Angular 4+ a favor de queryParamsHandling.

      Ahora ya sabe cómo puede usar queryParamsHandling para conservar y combinar los parámetros de consulta.

      En nuestro ejemplo, si en vez de eso está usando la directiva RouterLink para navegar a la ruta, tendría que usar queryParams de esta forma:

      <a [routerLink]="["https://www.digitalocean.com/products"]" [queryParams]="{ order: 'popular'}">
        Products
      </a>
      

      Y en nuestro ejemplo, si desea 'preserve' o 'merge' parámetros de consulta en la posterior navegación, tendría que usar queryParamsHandling de esta forma:

      <a [routerLink]="['/users']"
         [queryParams]="{ filter: 'new' }"
         queryParamsHandling="merge">
        Users
      </a>
      

      Ahora ya sabe cómo puede usar queryParams y queryParamsHandling con RouterLink.

      Acceso a los valores del parámetro de consulta

      Ahora que sabemos pasar los parámetros de consulta opcionales a una ruta, veamos cómo acceder a estos valores en las rutas resultantes. La clase ActivatedRoute tiene una propiedad queryParams que devuelve un observable de los parámetros de consulta que están disponibles en la URL actual.

      Dada la siguiente ruta URL:

      http://localhost:4200/products?order=popular
      

      Podemos acceder al parámetro de consulta order de esta forma:

      // ...
      import { ActivatedRoute } from '@angular/router';
      import 'rxjs/add/operator/filter';
      
      @Component({ ... })
      export class ProductComponent implements OnInit {
        order: string;
        constructor(private route: ActivatedRoute) { }
      
        ngOnInit() {
          this.route.queryParams
            .filter(params => params.order)
            .subscribe(params => {
              console.log(params); // { order: "popular" }
      
              this.order = params.order;
              console.log(this.order); // popular
            }
          );
        }
      }
      

      En el registro de la consola, veremos el objeto params:

      Output

      { order: "popular" }

      Y el valor params.order

      Output

      popular

      También existe queryParamMap, que devuelve un observable con un objeto paramMap

      Dada la siguiente ruta URL:

      http://localhost:4200/products?order=popular&filter=new
      

      Podemos acceder al parámetro de consulta order de esta forma:

      this.route.queryParamMap
        .subscribe((params) => {
          this.orderObj = { ...params.keys, ...params };
        }
      );
      

      Aquí hemos utilizado el operador de propagación del objeto y así es como se verán los datos en orderObj:

      {
        "0": "order",
        "1": "filter",
        "params": {
          "order": "popular",
          "filter": "new"
        }
      }
      

      Ahora ya sabe cómo puede usar queryParams y queryParamMap para acceder a los valores en las rutas resultantes.

      Conclusión

      En este artículo, utilizamos diferentes ejemplos para configurar y obtener parámetros de consulta en Angular. Presentamos queryParams y queryParamsHandling con Router.navigate y RouterLink. También presentamos queryParams y queryParamMap con ActivatedRoute.

      Si desea obtener más información sobre Angular, consulte nuestra página sobre el tema Angular para ver ejercicios y proyectos de programación.



      Source link

      Cómo centralizar los registros con Journald en Ubuntu 20.04


      El autor seleccionó la Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas y cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envía sus registros en tiempo real a un servidor de administración de registros específico.

      Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

      • Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
      • Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
      • Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que puede estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que, quizá, no puedan acceder directamente por razones de seguridad.

      En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • Dos servidores Ubuntu 20.04.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Ubuntu 20.04 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
      • Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

      Esta guía utilizará los dos nombres de host siguientes:

      • client.your_domain: el sistema de cliente que genera los registros.
      • server.your_domain: el servidor de compilación de registro.

      Inicie sesión en el cliente y en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

      Nota: A lo largo del tutorial, se etiquetan los bloques de comandos con el nombre de servidor (cliente o servidor) en el que debería ejecutarse el comando.

      Paso 1: Instalar systemd-journal-remote

      En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

      Primero, en el cliente y en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      A continuación, instale el paquete systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

      En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      En el cliente, solo deberá abrir el puerto 80 con este comando:

      Client

      Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

      Paso 2: Instalar certificados de registro y Certbot

      Let’s Encrypt es una autoridad de certificación que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

      En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

      Primero, habilite el repositorio universe de Ubuntu, ya que la utilidad certbot reside en el repositorio universe. Si ya tiene el repositorio universe habilitado, la ejecución de estos comandos es segura y no le hará a su sistema:

      Client and Server

      • sudo apt install software-properties-common
      • sudo add-apt-repository universe
      • sudo apt update

      A continuación, instale certbot en ambos hosts:

      Client and Server

      Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Las opciones de este comando significan lo siguiente:

      • certonly: registra el certificado y no realiza otros cambios en el sistema.
      • --standalone: utiliza el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: acepta de forma automática los Términos de uso de Let’s Encrypt.
      • --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
      • -d your_domain: el nombre de host para el que se registrará el certificado. Debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le solicitará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional, si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

      Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

      Por último, deberá descargar una copia de los certificados intermedios y de la autoridad de certificación Let’s Encrypt y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen entre ellos.

      El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

      Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

      Paso 3: Configuración del servidor

      En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

      systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

      • sudo nano /etc/systemd/journal-remote.conf

      A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aquí están las opciones que ha utilizado:

      • Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
      • SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
      • ServerKeyFile: el archivo de clave privada del servidor.
      • ServerCertificateFile: el archivo de certificado del servidor.
      • TrustedCertificateFile: el archivo que contiene los certificados de la autoridad de certificación Let’s Encrypt.

      Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

      Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ahora puede iniciar systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

      Paso 4: Configurar el cliente

      En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

      La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

      Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Estas opciones al comando son:

      • --system: crea el nuevo usuario como un usuario de sistema. Le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
      • --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
      • --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
      • --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
      • --group: crea un grupo con el mismo nombre que el usuario.

      A continuación, establezca los permisos y la propiedad de los archivos del certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este archivo de forma que se parezca a lo siguiente:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

      • sudo systemctl restart systemd-journal-upload.service

      Ahora su cliente está configurado y ejecutándose, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que se están enviando los registros de forma correcta.

      Paso 5: Probar el cliente y el servidor

      En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

      El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo será llamará como el nombre de host que utilizó para el certificado TLS.

      Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

      Server

      • sudo ls -la /var/log/journal/remote/

      Esto imprimirá el contenido del directorio que muestra el archivo de registro:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

      En el cliente ejecute el siguiente comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

      A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario, de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      El mensaje de registro aparecerá como se muestra:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

      Conclusión

      En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.



      Source link