Busindre

User Tools

Site Tools

Trace:
guia_rapida_de_docker_swarm

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
guia_rapida_de_docker_swarm [2021/06/05 02:19] – busindreguia_rapida_de_docker_swarm [2021/06/06 02:14] (current) – busindre
Line 12: Line 12:
 Los servicios pueden usar réplicas o definirse como globales. Un servicio que usa réplicas permite configurar su número mientras que en el global, todos los nodos tendrán una tarea asignada. De agregarse nuevos nodos, estos recibirán la tarea automáticamente. Los servicios pueden usar réplicas o definirse como globales. Un servicio que usa réplicas permite configurar su número mientras que en el global, todos los nodos tendrán una tarea asignada. De agregarse nuevos nodos, estos recibirán la tarea automáticamente.
  
-**Task** / **Tarea** es lo que el planificador llena generando un contenedor. Es decir, el contenedor es la instancia de la tarea. Si una tarea falla (health check) o termina, por ejemplo escuchando peticiones HTTP, el orquestador crea una nueva tarea de réplica que engendra un nuevo contenedor.Una tarea es un mecanismo unidireccional. Progresa monotónicamente a través de una serie de estados: asignado, preparado, en ejecución, etc. Si la tarea falla, el orquestador elimina la tarea y su contenedor y luego crea una nueva tarea para sustituirla según el estado deseado especificado por el servicio. +**Task** / **Tarea** es lo que el planificador llena generando un contenedor. Es decir, el contenedor es la instancia de la tarea. Si una tarea falla (health check) o termina, por ejemplo escuchando peticiones HTTP, el orquestador crea una nueva tarea de réplica que engendra un nuevo contenedor.Una tarea es un mecanismo unidireccional. Progresa a través de una serie de estados: asignado, preparado, en ejecución, etc. Si la tarea falla, el orquestador elimina la tarea y su contenedor y luego crea una nueva tarea para sustituirla según el estado deseado especificado por el servicio. 
  
 **Stacks** en Docker Swarm son definiciones de servicios, volúmenes, redes, secretos, etc en un archivo de texto en formato YAML. Permite iniciar por tanto múltiples contenedores y elementos necesarios para su correcto funcionamiento. Viene a ser el docker compose de los entornos swarm, teniendo un formato casi idéntico. Los ficheros compose se deben desplegar en enjambres siempre mediante el comando docker "stack" **Stacks** en Docker Swarm son definiciones de servicios, volúmenes, redes, secretos, etc en un archivo de texto en formato YAML. Permite iniciar por tanto múltiples contenedores y elementos necesarios para su correcto funcionamiento. Viene a ser el docker compose de los entornos swarm, teniendo un formato casi idéntico. Los ficheros compose se deben desplegar en enjambres siempre mediante el comando docker "stack"
 +
 ===== Características de un entorno Docker swarm ===== ===== Características de un entorno Docker swarm =====
  
Line 44: Line 45:
   * UDP Puerto 4789: Tráfico de red.   * UDP Puerto 4789: Tráfico de red.
  
-**Número de nodos manager recomendado en Docker Swarm (Ralf/Quorum)**+**Número de nodos manager recomendado en Docker Swarm (Raft/Quorum)**
  
 Los nodos gestores de un enjambre utilizan el algoritmo de consenso de "Raft" para gestionar el estado del enjambre. Raft requiere una mayoría de gestores, también llamada "quórum", para acordar las propuestas de actualización del enjambre, como la adición o eliminación de nodos. Los nodos gestores de un enjambre utilizan el algoritmo de consenso de "Raft" para gestionar el estado del enjambre. Raft requiere una mayoría de gestores, también llamada "quórum", para acordar las propuestas de actualización del enjambre, como la adición o eliminación de nodos.
Line 52: Line 53:
 Si no se mantiene el quórum, perdiendo un nodo más del que nuestro clúster necesita, por ejemplo perder 3 nodos gestores de 5, el clúster no podrá ser administrado. las tareas del enjambre en los nodos trabajadores existentes siguen ejecutándose. Sin embargo, los nodos del enjambre no pueden añadirse, actualizarse o eliminarse, y las tareas nuevas o existentes no pueden iniciarse, detenerse, moverse o actualizarse. Si no se mantiene el quórum, perdiendo un nodo más del que nuestro clúster necesita, por ejemplo perder 3 nodos gestores de 5, el clúster no podrá ser administrado. las tareas del enjambre en los nodos trabajadores existentes siguen ejecutándose. Sin embargo, los nodos del enjambre no pueden añadirse, actualizarse o eliminarse, y las tareas nuevas o existentes no pueden iniciarse, detenerse, moverse o actualizarse.
  
-En entornos grandes donde haya varias zonas de red y desde todas ellas deba estar el cluster operativo, se recomienda dividir el número de nodos entre el nodo de zonas de manera equitativa. Si se dispone de 9 Nodos gestores y tres zonas, pues 3-3-3. Si fueron 5 gestores y tres zonas, 2-2-1, etc.+En entornos grandes donde haya varias zonas de red y desde todas ellas deba estar el clúster operativo, se recomienda dividir el número de nodos entre el nodo de zonas de manera equitativa. Si se dispone de 9 Nodos gestores y tres zonas, pues 3-3-3. Si fueron 5 gestores y tres zonas, 2-2-1, etc.  
 + 
 +Utilizando una implementación de Raft, los gestores mantienen un estado interno coherente de todo el enjambre y de todos los servicios que se ejecutan en él. Además del quórum, Raft permite también la "replicación de registros", permitiendo que todos los nodos tengan los mismos datos. Estos datos, llamados registros Raft, se usan para guardar información relevante, como los secretos usados en los contenedores, la llave privada raiz de la CA del clúster, información sobre la configuración de las redes, y cualquier cosa necesaria para garantizar el correcto funcionamiento del enjambre.
  
 ====== Crear un entorno swarm ====== ====== Crear un entorno swarm ======
Line 68: Line 71:
 </code> </code>
  
-Cuando se crea un enjambre ejecutando "docker swarm init", Docker se designa a sí mismo como nodo gestor. Por defecto, el nodo gestor genera una nueva Autoridad de Certificación (CA) raíz, un certificado del propio nodo y una llave privada. Todo esto se utiliza para asegurar las comunicaciones con otros nodos que se unen al enjambre. Si se prefiere, se puede especificar una propia CA raíz generada por el usuario, utilizando la bandera %%--%%external-ca del comando "docker swarm init".+**Entendiendo el proceso de inicializado de un entorno Docker swarm** 
 + 
 +Cuando se crea un enjambre ejecutando "docker swarm init", el nodo se designa a sí mismo como nodo gestor. En ese momento el nodo gestor genera una nueva Autoridad de Certificación (CA) raíz (llave privada y certificado autofirmado), esta CA firmará los certificados de cada nodo pero no se almacena nunca en disco, se encuentra en los registros raft y por tanto está disponible en todos los nodos manager. Además de la CA, se genera un fichero "/var/lib/docker/swarm/certificates/swarm-node.key" con dos llaves privadas (una llave Raft DEK para cifrar los secretos y otra llave TLS para cifrar y autenticar a los nodos mediante TLS). Con la llave TLS se genera un certificado el cual es firmado por la CA.  
 + 
 +Todo esto se utiliza para asegurar las comunicaciones con otros nodos que se unen al enjambre. Si se prefiere, se puede especificar una propia CA raíz generada por el usuario, utilizando la bandera %%--%%external-ca del comando "docker swarm init".
  
-El nodo gestor también genera dos tokens para utilizar cuando se unen nodos adicionales al enjambre: un token de trabajador y un token de gestor. Cada token incluye el compendio del certificado de la CA raíz y un secreto generado aleatoriamente. Cuando un nodo se une al enjambre, el nodo que se une utiliza el compendio para validar el certificado de la CA raíz del gestor remoto. El gestor remoto utiliza el secreto para asegurarse de que el nodo que se une es un nodo aprobado.+El nodo gestor también genera dos tokens para utilizar cuando se unen nodos adicionales al enjambre: un token de trabajador y un token de gestor. Cada token incluye el compendio del certificado de la CA raíz y un secreto generado aleatoriamente. Cuando un nodo se une al enjambre, el nodo que se une utiliza el compendio para validar el certificado de la CA raíz del gestor remoto. El gestor remoto utiliza el secreto para asegurarse de que el nodo que se une es un nodo legítimo.
  
-Cada vez que un nuevo nodo se une al enjambre, el gestor emite un certificado para el nodo, el cual firma. El certificado contiene un ID de nodo generado aleatoriamente para identificar el nodo bajo el nombre común (CN) del certificado y el rol bajo la unidad organizativa (OU). El ID de nodo sirve como identidad de nodo criptográficamente segura durante la vida del nodo en el enjambre actual. Por defecto, cada nodo del enjambre renueva su certificado cada tres meses. Puede configurar este intervalo ejecutando el siguiente comando.+Cada vez que un nuevo nodo se une al enjambre, el nodo el gestor firma el certificado, el certificado contiene un ID de nodo generado aleatoriamente para identificar el nodo bajo el nombre común (CN) del certificado y el rol bajo la unidad organizativa (OU). El ID de nodo sirve como identidad de nodo criptográficamente segura durante la vida del nodo en el enjambre actual. Por defecto, cada nodo del enjambre renueva su certificado cada tres meses. Puede configurar este intervalo ejecutando el siguiente comando.
  
 <code bash># La fecha de caducidad de los certificados será de 9 días (216 horas) <code bash># La fecha de caducidad de los certificados será de 9 días (216 horas)
Line 81: Line 88:
 Certificados y llave privada en Docker Swarm. Certificados y llave privada en Docker Swarm.
  
-  * /var/lib/docker/swarm/certificates/swarm-node.crt    Certificado del nodo. +  * /var/lib/docker/swarm/certificates/swarm-node.crt    Certificado del nodo (Rota cada 3 meses). 
-  * /var/lib/docker/swarm/certificates/swarm-node.key    Llave privada del nodo. +  * /var/lib/docker/swarm/certificates/swarm-node.key    Llaves privadas DEK y TLS del nodo (Cifra y autentica Nodos (TLS) / Cifra los secretos (DEK)). 
-  * /var/lib/docker/swarm/certificates/swarm-root-ca.crt Certificado de la CA del clúster.+  * /var/lib/docker/swarm/certificates/swarm-root-ca.crt Certificado de la CA del clúster (No rota). 
 +  * Llave privada rait de la CA del clúster se encuentra en el registro Raft.
  
-El certificado CA es el mismo en todos los nodos, mientras que los certificados individuales de cada nodo tienen la misma firma que el raíz. Es decir, swarm-root-ca.crt y swarm-node.crt tienen la misma firma ya que han sido firmados por el nodo manager elegido en el momento de inicialización del swarm. Cuando se usa el bloqueo de un enjambre Docker, lo que se hace es cifrar la llave privada y obliga por tanto a usar un arranque manual donde se introduzca la "llave" en cada inicio del clúster para desbloquearlo y que pueda funcionar.+El certificado CA es el mismo en todos los nodos, mientras que los certificados individuales de cada nodo tienen la misma firma de la CA. Es decir, swarm-root-ca.crt y swarm-node.crt tienen la misma firma ya que han sido firmados por el nodo manager elegido en el momento de inicialización del swarm. Cuando se usa el bloqueo de un enjambre Docker, lo que se hace es cifrar el fichero swarm-node.key (Llave TLS y llave DEK), obligando por tanto a usar un arranque manual donde se introduzca la "llave/passphrase" en cada inicio del clúster para desbloquearlo y que pueda funcionar. Es una medida de seguridad orientada a impedir males mayores si alguien indeseable accede al sistema de ficheros de algún nodo ([[#bloquear_el_entorno_swarm_autolockcifrado_de_llaves_privada|leer]]).
  
 **Desplegar un servicio (Replicas / Global)** **Desplegar un servicio (Replicas / Global)**
Line 448: Line 456:
 Un secreto es un bloque de datos, como una contraseña, una clave privada SSH, GPG, certificado SSL u otra pieza de datos que no debe transmitirse a través de una red o almacenarse sin cifrar en un archivo Docker o en el código fuente de su aplicación. Puedes utilizar los secretos de Docker para gestionar de forma centralizada estos datos y transmitirlos de forma segura sólo a aquellos contenedores que necesiten acceder a ellos. Un secreto dado sólo es accesible para aquellos servicios a los que se les ha concedido acceso explícito a él, y sólo mientras esas tareas de servicio se están ejecutando.  Es decir, no se almacenan y solo están presentes en tiempo de ejecución (en forma de solo lectura. Un secreto es un bloque de datos, como una contraseña, una clave privada SSH, GPG, certificado SSL u otra pieza de datos que no debe transmitirse a través de una red o almacenarse sin cifrar en un archivo Docker o en el código fuente de su aplicación. Puedes utilizar los secretos de Docker para gestionar de forma centralizada estos datos y transmitirlos de forma segura sólo a aquellos contenedores que necesiten acceder a ellos. Un secreto dado sólo es accesible para aquellos servicios a los que se les ha concedido acceso explícito a él, y sólo mientras esas tareas de servicio se están ejecutando.  Es decir, no se almacenan y solo están presentes en tiempo de ejecución (en forma de solo lectura.
  
-Cuando se añada un secreto al enjambre, Docker envía el secreto al administrador del enjambre a través de una conexión TLS mutua. El secreto se almacena en el registro de Raft, que está cifrado. Todo el registro de Raft se replica en los demás nodos gestores, asegurando así la alta disponibilidad para los secretos.+Cuando se añada un secreto al enjambre, Docker envía el secreto al administrador del enjambre a través de una conexión TLS mutua. El secreto se almacena en el registro de Raft, que está siempre cifrado en disco (solo nodos gestores). Todo el registro de Raft se replica en los demás nodos gestores, asegurando así la alta disponibilidad para los secretos.
  
 NOTA: Los secretos siempre están accesibles en texto claro en el mismo nodo donde fueron montados mediante tmpfs. Cuando el contenedor no está activo, ese directorio desaparece. NOTA: Los secretos siempre están accesibles en texto claro en el mismo nodo donde fueron montados mediante tmpfs. Cuando el contenedor no está activo, ese directorio desaparece.
Line 509: Line 517:
 Las configuraciones de servicio permiten almacenar información no sensible, normalmente archivos de configuración, fuera de la imagen de un servicio o de los contenedores en ejecución. Esto permite mantener imágenes genérica, sin la necesidad de bind-mount o el uso de variables de entorno. Estos ficheros de configuración pueden usarse como plantillas para que una vez arranque el contenedor de un servicio, la configuración se genere con los valores deseados mediante variables. Las configuraciones de servicio permiten almacenar información no sensible, normalmente archivos de configuración, fuera de la imagen de un servicio o de los contenedores en ejecución. Esto permite mantener imágenes genérica, sin la necesidad de bind-mount o el uso de variables de entorno. Estos ficheros de configuración pueden usarse como plantillas para que una vez arranque el contenedor de un servicio, la configuración se genere con los valores deseados mediante variables.
  
-Las configuraciones operan de manera similar a los secretos, excepto que no están encriptadas cuando están en reposo y se montan directamente en el sistema de archivos del contenedor sin el uso de discos RAM. Las configuraciones pueden ser añadidas o eliminadas de un servicio en cualquier momento, y los servicios pueden compartir una configuración. Incluso se pueden usar "configs" con variables de entorno o etiquetas, para crear plantillas que ofrezcan más flexibilidad. Los valores de configuración pueden ser cadenas genéricas o contenido binario (de hasta 500 kb de tamaño).+Las configuraciones operan de manera similar a los secretos, excepto que no están cifradas cuando están en reposo y se montan directamente en el sistema de archivos del contenedor sin el uso de discos RAM. Las configuraciones pueden ser añadidas o eliminadas de un servicio en cualquier momento, y los servicios pueden compartir una configuración. Incluso se pueden usar "configs" con variables de entorno o etiquetas, para crear plantillas que ofrezcan más flexibilidad. Los valores de configuración pueden ser cadenas genéricas o contenido binario (de hasta 500 kb de tamaño).
  
 **Cómo gestiona Docker Swarm las configuraciones**. **Cómo gestiona Docker Swarm las configuraciones**.
Line 962: Line 970:
 ===== Bloquear el entorno Swarm (autolock: cifrado de llaves privada) ===== ===== Bloquear el entorno Swarm (autolock: cifrado de llaves privada) =====
  
-Los registros de Raft utilizados por los gestores de enjambres están encriptados en el disco por defecto. Este cifrado en reposo protege la configuración y los datos de su servicio de los atacantes que acceden a los registros cifrados de Raft. Una de las razones por las que se introdujo esta función fue para apoyar la función de secretos de Docker.+Si no se tiene claro qué es lo que pasa al inicializar un enjambre docker se recomienda leer la sección "[[#crear_un_entorno_swarm|Entendiendo qué pasa internamente al iniciallizar un enjambre Docker]]"
  
-Cuando Docker se reinicia, tanto la clave TLS utilizada para cifrar la comunicación entre los nodos del enjambre, como la clave utilizada para cifrar y descifrar los registros de Raft en el disco, se cargan en la memoria de cada nodo gestor. Docker tiene la capacidad de proteger mediante cifrado la clave de cifrado TLS mutua y la clave utilizada para cifrar y descifrar los registros de Raft en reposo, es lo que sería el bloqueo. El descrifrado de esas llaves se llama autolock y es necesario ya que si están cifradas, el enjambre no puede operar.+El almacén completo de raft como sabemos es el mismo en todos los nodos gestores, se propaga a todos los gestores cifrado únicamente a través de mTLS. Cada nodo gestor debe tener una copia idéntica de los registros, que se encuentra en la siguiente ruta /var/lib/docker/swarm/raft/. Estos registros están cifrados, ya que almacenan datos sensibles como los secretos de Docker utilizados por los servicios que se ejecutan en el clúster de Swarm.  
 + 
 +Las llaves TLS/DEK están en la ruta /var/lib/docker/swarm/certificates/swarm-node.key. 
 + 
 +Como ya se comentó, este fichero swarm-node.key tiene dos llaves privadas, la llave DEK en forma de cabecera en formato PEM y la llave TLS. 
 + 
 +**Raft DEK (Data Encrypting Key)** 
 +  * Uso: Cifra el registro Raft. 
 +  * Única por nodo gestor. 
 +  * Se almacena como una cabecera PEM en la clave TLS que se almacena en /var/lib/docker/swarm/certificates/swarm-node.key. 
 +  * Se genera cuando el gestor se inicializa por primera vez, o en la rotación. 
 +  * Cifrado: No está cifrada por defecto pero se cifra al usar el bloqueo del enjambre. 
 +  * Rotación: Esta lave siempre rota cuando el clúster pasa de no autobloqueado a autobloqueado. 
 +  * Eliminación: Cuando un gestor es degradado o abandona el clúster 
 + 
 +**Llave TLS** 
 +  * Uso: Cifra y autentica la comunicación a través de mTLS. 
 +  * Única por nodo gestor. 
 +  * Se almacena en /var/lib/docker/swarm/certificates/swarm-node.key y actualmente tiene le formato pkcs8. 
 +  * Se genera cuando el nodo se une al enjambre por primera vez, o al renovar el certificado. 
 +  * Cifrado: No está cifrada por defecto pero se cifra al usar el bloqueo del enjambre. 
 + 
 +Estas dos llaves son cifradas si se usa el bloqueo del clúster, esto se realiza mediante otra llave, la denominada "Manager unlock key" 
 + 
 +**Manager unlock key** 
 + 
 +  * Uso: Cifra las llaves DEK y TLS (actúa como una KEK, o clave de cifrado). 
 +  * No es única por nodo gestor: la comparten todos los gestores del clúster. 
 +  * Se almacena en el resgitro Raft (así se propaga a todos los gestores). 
 +  * Se genera cuando el clúster se pone en autolock, o cuando la llave de desbloqueo se rota. 
 +  * Cifrado: Como el resto del registro Raft, al enviarse se usa TLS para cifrar la comunicación y vía DEK cuando está en reposo sobre el sistema de ficheros. 
 +  * Se puede rotar a través de la API. 
 +  * Se elimina cuando se desactiva el bloqueo automático. 
 + 
 +Fichero swarm-node.key sin autolock. 
 +<code swarm-node.key NO cifrado> 
 +-----BEGIN PRIVATE KEY----- 
 +kek-version: 300855 
 +raft-dek: EiC9cFBOPxkZDl8VqRI/QsJ1ydTtUkcyeO/1loOZD+Ty6w== 
 + 
 +MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgBuGLymWVcAdlsVR0 
 +q8n+urqIPnFu+jscKNXoY7lkhhKhRANCAAT63Va7/TnEMZv4d2EPMnQsG61DKl1e 
 +Heo+CCIobsR6srfxMGyzFTxA5kbxgD24dJL+1pS/c8iZxmPbPAuLdr6e 
 +-----END PRIVATE KEY-----</code> 
 + 
 +Fichero swarm-node.key con autolock. 
 +<code swarm-node.key cifrado> 
 +-----BEGIN ENCRYPTED PRIVATE KEY----- 
 +kek-version: 250979 
 +raft-dek: CAESMHie2K4PvoYXxTHVO2nvduabxZg9cSEKQAn/pr8kGXe8pYKwM0RlVlBmjSRzLzYm4hoYEdkND+C+RbqXfoO5Nlqja80xyw6vNtDq 
 + 
 +MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAiLTl7MCLK0CAICCAAw 
 +HQYJYIZIAWUDBAEqBBC3SVE2J6Hp/E5cUp31Q6Z8BIGQejzdNjlB6kGLWfeO+YOW 
 +U4fOaEuwGyBbihnsG4qkbDAJmp5qLJa8VhPhBzlPsmtswVTFpSmV9zD0TOuPPXAG 
 +DavgVl+k5y0nCCHUW/dokackUB2QNH+V/SbDrQEB8XA+uG7dxVzdI6M4x6Nz6X/s 
 +pwX17y2X6+/BYw0ERv7AfsfEwrMus6LmHHxmi3pvDAAg 
 +-----END ENCRYPTED PRIVATE KEY-----</code> 
 + 
 +Los registros de Raft utilizados por los gestores de enjambres están cifrados en el disco por defecto. Si la llave está accesible desde el sistema de ficheros, se puede acceder a los datos del registro Raft. El bloqueo lo que hace es cifrar dicha llave y por lo tanto exige descifrarla en cada inicio del enjambre o al reiniciar nodos manager. Esto significa que si uno de los nodos gestores ha sido comprometido a nivel de sistema de fichero y no uso autoblock, es decir, no tiene su fichero swarm-node.key cifrado. Entonces es posible descifrar y leer los registros de Raft para obtener los secretos de Docker, entre otra información sensible.  
 + 
 +Si el atacante tiene acceso a root, lógicamente siempre podrá consultar lo que quiera, desde los secretos a las llaves privadas, independientemente de la configuración autoblock. El bloqueo tiene como finalidad defenderse de accesos al sistema de ficheros, por ejemplo mediante a un acceso a backups/snapshots del disco.
  
 <code bash> <code bash>
-# Incializar un entorno swarm bloqueando el entorno. (cifrando las llaves privadas). +# Incializar un entorno swarm bloqueando el entorno. (cifrando las llaves privadas TLS y DEK de swarm-node.key). 
 docker swarm init --autolock docker swarm init --autolock
  
Line 973: Line 1041:
 docker swarm update --autolock=true docker swarm update --autolock=true
  
-Mostrar la key (lógicamente solo funciona cuando esté el bloqueo activado pero el entorno está desactivado).+Mostrar la Manager unlock key (lógicamente solo funciona cuando esté el bloqueo activado pero el entorno está desactivado).
 # docker swarm unlock-key # docker swarm unlock-key
  
Line 987: Line 1055:
 # Rota las llaves de bloqueo. # Rota las llaves de bloqueo.
 docker swarm unlock-key --rotate docker swarm unlock-key --rotate
-# Rota la llave CA del clúster. Todo eso conlleva cambiar los certificados, llaves de los nodos y por supuesto nuevos tokens.+# Rota la llave CA del clúster. No está directamente relacionado con el tema de unlock, pero obliga a cambiar los certificados, llaves de los nodos y por supuesto se generan nuevos tokens.
 docker swarm ca --rotate docker swarm ca --rotate
  
 # Desactiva el bloqueo. # Desactiva el bloqueo.
 docker swarm update --autolock=false</code> docker swarm update --autolock=false</code>
 +
 +Si se quiere realizar un volcado del registro Raft puede usarse swarm-rafttool (swamkit): https://github.com/docker/swarmkit 
guia_rapida_de_docker_swarm.1622852369.txt.gz · Last modified: 2021/06/05 02:19 by busindre