All perguntas(server)

Tenho um domínio principal com modelos de administração específicos da Microsoft. Quando vou fazer alterações no meu domínio filho, esses modelos não aparecem no controlador de domínio do domínio filho. Por que eles não passam esses modelos como parte da replicação e onde coloco os modelos de administração no domínio filho para que eu possa editar essas configurações?

Eu tentei adicionar uma pasta chamada PolicyDefinitions a C:\Windows\SYSVOL\SYSVOL\DOMAIN no DC do domínio filho, mas quando eu carrego o GPO, os únicos modelos de administração que ele vê com essa pasta são os novos modelos de administração e nenhum dos padrões. Eles estão escondidos em algum lugar ou se referem ao topo?

Fundo

Estou planejando configurar um servidor PostgreSQL/PostGIS no RHEL 9.4 como parte do trabalho de migração de uma versão mais antiga do RHEL e estou comparando caminhos de atualização de uma perspectiva de estabilidade.

Se entendi corretamente, há duas maneiras de instalar o PostgreSQL e o PostGIS no RHEL9:

Opção 1: Use o repositório PostgreSQL

Instale o PostgreSQL ( postgresqlNN-server) e o PostGIS ( postgisNN_MM) do repositório oficial do PostgreSQL ( pgdgNN).

Esta opção segue o ciclo de manutenção do PostgreSQL e PostGIS .

Opção 2: Use os repositórios RHEL9 e EPEL

Instale o PostgreSQL ( postgresql) do Red Hat Application Streams e o PostGIS ( postgis) do EPEL.

A Red Hat fornece diversas versões do PostgreSQL:

• PostgreSQL 13: Entregue por meio do canal RHEL 9 Full Life Application Streams e com suporte até o EOL do RHEL9 (2032-05).
• PostgreSQL 15, 16: Entregue via RHEL 9 Application Streams com vida útil mais curta, atingindo o EOL em 2028-05 e 2029-05, respectivamente.

Para o PostGIS, as atualizações são fornecidas pela EPEL com base no melhor esforço devido à natureza do projeto orientada pela comunidade. Dito isso, os mantenedores da EPEL se esforçam para manter os pacotes até o EOL do RHEL.

Das Perguntas Frequentes da EPEL :

Por quanto tempo os pacotes EPEL são atualizados?

Idealmente, os pacotes EPEL são mantidos enquanto a versão RHEL correspondente for suportada. No entanto, o EPEL é um esforço voluntário, e um mantenedor de pacote pode aposentar sua ramificação EPEL a qualquer momento.

Pergunta

Estou pensando em usar o EPEL PostGIS porque ele complementa o PostgreSQL fornecido pela Red Hat, que oferece um longo ciclo de vida (PostgreSQL 13 suportado até 2032). No entanto, estou preocupado com a compatibilidade de longo prazo dos pacotes EPEL com o software fornecido pela Red Hat, especialmente depois que as versões upstream (por exemplo, PostgreSQL ou PostGIS) atingirem o EOL.

No meu caso, o PostgreSQL upstream atingirá o fim da vida útil em 2025-11 e, olhando para o gráfico de compatibilidade PostgreSQL-PostGIS e extrapolando a tendência, espero que o PostGIS deixe de oferecer suporte ao PostgreSQL 13 nas próximas versões.

Como os pacotes EPEL, como o PostGIS, normalmente são mantidos em tais cenários, especialmente quando vinculados ao software fornecido pela Red Hat com um ciclo de vida mais longo?

Especificamente:

• A versão EPEL do PostGIS continuará recebendo atualizações para permanecer compatível com o PostgreSQL 13 até o fim da vida útil do RHEL9?
• Existe precedente ou prática padrão para pacotes EPEL fazerem backport de alterações de versões upstream em casos como esse?

Tenho um servidor (com um único endereço IP) alvo de vários registros DNS – por exemplo ftp1.adomain.com, ftp69.filetime.com, e ftp420.sendthefiles.com. Estou curioso para saber se é possível registrar o nome do host (não o endereço IP) que o usuário alvou em sua conexão.

Efetivamente, quero identificar se um usuário se conectou usando ftp1.adomain.comou usando ftp420.sendthefiles.com.

Dei uma olhada na documentação do ProFTPD e acho que não encontrei o que queria, mas pensei em ver se alguém tem alguma informação adicional.

Recentemente, tentei configurar vários SSLs para vários domínios usando o postfix SNI. (Dovecot permanece inalterado). Agora, estou recebendo erros de TLS (var/etc/mail.log):

Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: connect from unknown[46.39.58.24]
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: warning: table hash:/etc/postfix/vmail_ssl.map.db: key history.tor: malformed BASE64 value: /FakeSSL/history.tor/history.t
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: warning: tls_server_sni_maps: history.tor map lookup problem
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: SSL_accept error from unknown[46.39.58.24]: -1
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: warning: TLS library problem: error:0A0000EA:SSL routines::callback failed:../ssl/statem/extensions.c:1000:
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: lost connection after STARTTLS from unknown[46.39.58.24]
Jan 22 22:06:17 2099047-cg00264 postfix/smtpd[138223]: disconnect from unknown[46.39.58.24] ehlo=1 starttls=0/1 commands=1/2

Meu postfix main.conf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 3.6 on
# fresh installs.
compatibility_level = 3.6


smtpd_use_tls = yes
# TLS parameters
smtpd_tls_cert_file=/OtherSSL/mishkin.ml/mishkin.ml.chain.pem
smtpd_tls_key_file=/OtherSSL/mishkin.ml/mishkin.ml.priv.key
smtpd_tls_security_level=may

#smtp_tls_CApath=/OtherSSL/CA
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_tls_auth_only = yes
smtpd_tls_wrappermode = no
smtpd_tls_mandatory_ciphers = high

tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mishkin.ml
mydomain = mishkin.ml
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, mishkin.ml, 2099047-cg00264.twc1.net, localhost.twc1.net, localhost, history.tor
virtual_alias_domains = mishkin.ml, history.tor
virtual_alias_maps = hash:/etc/postfix/virtual
relayhost = 
mynetworks = 90.156.226.142/32
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

vmail_ssl.map:

mishkin.ml /OtherSSL/mishkin.ml/mishkin.ml.chain.pem /OtherSSL/mishkin.ml/mishkin.ml.priv.key
history.tor /FakeSSL/history.tor/history.tor.chain.pem /FakeSSL/history.tor/history.tor.priv.key

Os SSLs foram criados usando https://github.com/Vinalti/Self-Signed-Certificates-Generator

1. Tentou substituir ambos os arquivos smtpd_tls em um parâmetro smtpd_tls_chain_files
2. Postfix movido para uma porta 25 (sim, movido DE 587 para 25)
3. Seguiu outras instruções de configuração do SNI
4. Tentei obter o certificado via openssl, não esse script

Estou executando um servidor apache2 com vários hosts virtuais. Eu o executo em um raspberry pi 4 com recursos bastante limitados. Em particular, a RAM é muito apertada (4 GB). Não há muito tráfego, eu o uso principalmente para hospedar o nextcloud, um site de streaming personalizado e alguns arquivos estáticos.

O problema são os arquivos estáticos. Sempre que eu, ou qualquer outra pessoa, baixa um arquivo, parece que o arquivo inteiro é carregado na RAM. Isso não é um problema para arquivos pequenos, mas qualquer coisa > 500 MB causa problemas sérios, frequentemente enchendo o SWAP e eventualmente causando uma morte OOM do apache.

Não consigo descobrir como fazer para simplesmente transmitir os arquivos do disco, em vez de armazená-los em cache na memória antes de enviá-los. Isso pode ser uma coisa viável a se fazer se você tiver 128 GB de RAM em um servidor adequado, mas está me matando no meu pobre pi.

Então, como faço para que o apache apenas transmita o arquivo do disco? E por que ele carrega o arquivo para a ram de qualquer maneira? O disco i/o é muito mais rápido do que a rede, então não há sentido em armazenar o arquivo do disco para a memória.

Eu tentei:

• alternando de mpm_prefetch para mpm_event.
• EnableSendfile On, o que parece não fazer nada.
• mod_xsendfile comXSendFile On
• Procurando outras soluções, incluindo
  • este , não aplicável porque um único trabalhador está usando toda a RAM para carregar um único arquivo enorme na RAM
  • este , não aplicável porque mesmo que eu rode PHP, o problema é com solicitações get para arquivos estáticos no disco, não PHP. Também não consigo instalar mais RAM.
  • este aqui , onde eu nem sei do que diabos eles estão falando com aquele arquivo de configuração. Também, novamente, não é um problema de PHP.
  • Muitos outros falam sobre grandes uploads para PHP e solicitações PUT, e outras coisas do PHP.

Gostaria de evitar fazer um proxy reverso para arquivos hospedados no nginx, se possível, pois isso só aumentaria a complexidade de tudo.

Um dos meus hosts virtuais, para o qual o problema existe:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        ServerName host.tld
        ServerAdmin [email protected]

        DocumentRoot /var/www/web
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # Generate more pleasing and modern looking listing
        IndexOptions FancyIndexing IconsAreLinks FoldersFirst

        EnableSendfile On
        EnableMMAP     Off
        <IfModule mod_xsendfile.c>
            <Directory "/var/www/web">
                XSendFile On
                XSendFilePath /var/www/web
            </Directory>
        </IfModule>

        <IfModule mod_rewrite.c>
            RewriteEngine on
            RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
            RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
            RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
            RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]

            RewriteRule ^/ocm-provider/?$ index.php [QSA,L]
        </IfModule>

        <IfModule mod_headers.c>
            # disallow embedding of non https
            Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
            # Prevents browsers from interpreting text files as javascript
            Header onsuccess unset X-Content-Type-Options
            Header always set X-Content-Type-Options "nosniff"
            # enable browser side cross site script filter
            Header onsuccess unset X-XSS-Protection
            Header always set X-XSS-Protection "1; mode=block"
            # prevent search engines from indexing the site
            Header onsuccess unset X-Robots-Tag
            Header always set X-Robots-Tag "noindex, nofollow"
            # prevent embedding in other sites
            Header onsuccess unset X-Frame-Options
            Header always set X-Frame-Options "SAMEORIGIN"
            Header onsuccess unset X-Permitted-Cross-Domain-Policies
            Header always set X-Permitted-Cross-Domain-Policies "none"
            # prevent browser from sending referrer data when clicking links
            Header onsuccess unset Referrer-Policy
            # Header always set Referrer-Policy "no-referrer"
            Header always set Referrer-Policy "same-origin"
        </IfModule>

        # Private, password protected directory
        <Location "/private">
            # authentication
            AuthType                basic
            AuthName                "My Server"

            # Cache credentials with socache
            AuthBasicProvider       socache dbd

            # also needed for caching: tell cache to cache dbd lookups
            AuthnCacheProvideFor    dbd

            AuthDBDUserPWQuery      "SELECT password FROM authn WHERE user = %s"

            # block all non users.
            Require                 valid-user
        </Location>

        <Location /nextcloud/>
            Require all granted
            AllowOverride All
            Options FollowSymLinks MultiViews

            <IfModule mod_dav.c>
                Dav off
            </IfModule>

            # Disable Basic auth for this
            Satisfy Any
        </Location>

        # SSL settings
        SSLEngine on
        SSLCertificateFile      /etc/letsencrypt/live/host.tld/cert.pem
        SSLCertificateChainFile /etc/letsencrypt/live/host.tld/fullchain.pem
        SSLCertificateKeyFile   /etc/letsencrypt/live/host.tld/privkey.pem
        #Include /etc/letsencrypt/options-ssl-apache.conf

        # Add vhost name to log entries:
        LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
        LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
    </VirtualHost>
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr et

Meus módulos habilitados:

access_compat.load  authn_core.load authz_core.load  autoindex.load  dir.conf     headers.load    mpm_event.load    proxy.load      reqtimeout.conf  security3.load     socache_shmcb.load  status.load
alias.conf     authn_dbd.load   authz_host.load  dbd.load   dir.load     mime.conf       negotiation.conf   proxy_fcgi.load      reqtimeout.load  setenvif.conf     ssl.conf        unique_id.load
alias.load     authn_file.load  authz_user.load  deflate.conf   env.load     mime.load       negotiation.load   proxy_http.load      rewrite.load     setenvif.load     ssl.load        xsendfile.load
auth_basic.load     authn_socache.load  autoindex.conf  deflate.load    filter.load  mpm_event.conf  proxy.conf proxy_wstunnel.load  security3.conf   socache_memcache.load  status.conf

mpm_event.conf:

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxRequestWorkers     150
    MaxConnectionsPerChild   0
</IfModule>

apachectl -V:

Server built:   2024-07-17T18:57:26
Server's Module Magic Number: 20120211:126
Server loaded:  APR 1.7.0, APR-UTIL 1.6.1
Compiled using: APR 1.7.0, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

/proc/meminfo ao baixar um arquivo estático de 2 GB com curl. O texto é quando a conexão ssh morreu aproximadamente 10 segundos após o início do download. Até então, nem um único byte foi recebido pelo curl ainda.

MemTotal:        3880848 kB
MemFree:          190000 kB
MemAvailable:     479864 kB
Buffers:           52840 kB
Cached:           458780 kB
SwapCached:        63000 kB
Active:           502232 kB
Inactive:        2665432 kB
Active(anon):     318696 kB
Inactive(anon):  2479580 kB
Active(file):     183536 kB
Inactive(file):   185852 kB
Unevictable:       26756 kB
Mlocked:           26756 kB
SwapTotal:       4095996 kB
SwapFree:        2418916 kB
Dirty:                52 kB
Writeback:           192 kB
AnonPages:       2626292 kB
Mapped:           172496 kB
Shmem:            134752 kB
KReclaimable:     292096 kB
Slab:             411324 kB
SReclaimable:     292096 kB
SUnreclaim:       119228 kB
KernelStack:        8768 kB
PageTables:        22876 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6036420 kB
Committed_AS:    8174592 kB
VmallocTotal:   133143592960 kB
VmallocUsed:       27632 kB
VmallocChunk:          0 kB
Percpu:             3216 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:          65536 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB

Estou configurando o haproxy para atuar como intermediário entre a internet e vários serviços executados em um cluster k8s isolado.

Já testei com sucesso a conexão com o backend via http simples, mas agora estou tentando manipular o componente SSL lá também e, por algum motivo, não importa o que eu tente, estou recebendo o seguinte nos logs:

Jan 22 11:10:22 jake haproxy[170526]: 95.214.55.185:34832 [22/Jan/2025:11:10:21.968] xanadu-ingress-front/3: SSL handshake failure (error:0A000076:SSL routines::no suitable signature algorithm)

Tentar solucionar problemas via openssl s_clientme dá o seguinte (endereços IP e nomes DNS alterados para proteger o culpado):

shadur@luminosity:~$ openssl s_client --connect teapot.example.com:443 
Connecting to 1.2.3.4 CONNECTED(00000003)
40E7B2BBBA7F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:../ssl/record/rec_layer_s3.c:907:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 335 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

arquivo de configuração do haproxy abaixo:

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private


        # generated 2025-01-22, Mozilla Guideline v5.7, HAProxy 3.1.2, OpenSSL 3.4.0, intermediate config
        # https://ssl-config.mozilla.org/#server=haproxy&version=3.1.2&config=intermediate&openssl=3.4.0&guideline=5.7
        # intermediate configuration
        ssl-default-bind-curves X25519:prime256v1:secp384r1
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options prefer-client-ciphers ssl-min-ver TLSv1.2 no-tls-tickets

        ssl-default-server-curves X25519:prime256v1:secp384r1
        ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
        ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-server-options ssl-min-ver TLSv1.2 no-tls-tickets

        # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
        ssl-dh-param-file /etc/ssl/private/dhparam


defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

crt-store company
  crt-base /etc/ssl/certs/
  key-base /etc/ssl/private/
  load crt "company.com-full.pem" key "company.nl.key" alias "company"
  load crt "company.net-full.pem" key "company.net.key" alias "company.net"

frontend xanadu-ingress-front
  bind 1.2.3.4:80
  bind 1:2:3:4:5:6:7:8:80 transparent
  bind 1.2.3.4:443 ssl crt-list /etc/ssl/crt-lists/company.list alpn h2,http/1.1
  http-request redirect scheme https unless { ssl_fc }
  default_backend xanadu-ingress-back
  option httplog

backend xanadu-ingress-back
  mode http
  server xanadu 172.16.41.80:80 check

Tenho quase certeza de que estou esquecendo de algo muito simples e óbvio, mas não consigo descobrir o que é. Qualquer ajuda seria apreciada.

Temos um cluster k3s local para nosso ambiente de preparação para reproduzir algo parecido com nosso ambiente de produção. Hoje, nosso nó único atingiu seu limite, então decidimos adicionar um novo nó.

Comprei um novo servidor físico e acabei de instalar o Ubuntu Server 24.04.1 LTS. O próximo passo foi instalar o agente k3s para fazê-lo se juntar ao cluster existente. Segui a documentação online :

curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.1:6443 K3S_TOKEN=<my master token> sh -

Depois, verifiquei se tudo estava pronto com kubectl get nodes:

NAME    STATUS   ROLES                  AGE    VERSION
serv1   Ready    control-plane,master   382d   v1.28.5+k3s1
serv2   Ready    <none>                 117s   v1.31.4+k3s1

Mas quando o primeiro pod foi atribuído a este novo nó, ele obtém o status CreateContainerConfigError. Descrevendo o pod com kubectl describe pod, posso ver este erro:

Warning  Failed     12s (x2 over 13s)  kubelet            Error: services have not yet been read at least once, cannot construct envvars

Encontrei algumas coisas online sobre esse erro. Parece que há um problema entre nossos dois servidores e que, por algum motivo, eles não conseguem se comunicar corretamente. Mas como o novo nó está marcado Ready, não entendo onde está o problema...

Também encontrei exatamente o mesmo caso aqui , mas parece que nenhuma solução real foi compartilhada.

Alguém tem alguma ideia sobre a causa desse problema?

Tenho dois servidores DHCP (Domínio 2019) na minha rede.

Então dei uma olhada no ADSI Edit para ver as entradas listadas lá e foi isso que encontrei:

CN=server01.mydomain.net
CN=server01.mydomain.netCNF:ba47eb2c-3c6e-479b-a2d3-837a2a78d437

CN=server02.mydomain.net
CN=server02.mydomain.netCNF:ca47eb2c-3c6e-479b-a2e5-897a2a78d437

CN=server03.mydomain.net

há failover de DHCP entre server01 e server03. não há função DHCP no server02. Então por que há registros como abaixo?

CN=server01.mydomain.netCNF:ba47eb2c-3c6e-479b-a2d3-837a2a78d437
CN=server02.mydomain.netCNF:ca47eb2c-3c6e-479b-a2e5-897a2a78d437

Excluir a entrada manualmente no ADSI Edit causará algum problema com AD, DHCP Failover etc.?

Problema: Estou executando o WikiJS no Kubernetes (GKE) e estou encontrando problemas de permissão. O aplicativo não consegue criar o diretório de cache, gerando: "EACCES: permissão negada, mkdir '/wiki/data/cache'"

Ambiente:

• Kubernetes: GKE
• Versão do WikiJS: 2.5
• Volume: PVC

Configuração atual:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-wikijs
  namespace: test
  labels:
    app: test-wikijs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-wikijs
  template:
    metadata:
      labels:
        app: test-wikijs
    spec:
      containers:
      - name: test-wikijs
        image: requarks/wiki:2.5
        ports:
        - containerPort: 3000
        env:
          - name: DB_TYPE
            valueFrom:
              configMapKeyRef:
                name: test-wikjs-config
                key: DB_TYPE
          - name: DB_HOST
            valueFrom:
              configMapKeyRef:
                name: test-wikjs-config
                key: DB_HOST
          - name: DB_PORT
            valueFrom:
              configMapKeyRef:
                name: test-wikjs-config
                key: DB_PORT
          - name: DB_NAME
            valueFrom:
              secretKeyRef:
                name: sql-secret
                key: POSTGRES_DB
          - name: DB_USER
            valueFrom:
              secretKeyRef:
                name: sql-secret
                key: POSTGRES_USER
          - name: DB_PASS
            valueFrom:
              secretKeyRef:
                name: sql-secret
                key: POSTGRES_PASSWORD
        volumeMounts:
        - name: wikijs-data
          mountPath: /wiki/data
      volumes:
      - name: wikijs-data
        persistentVolumeClaim:
          claimName: wikijs-data-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wikijs-data-pvc
  namespace: test
  labels:
    app: test-wikijs
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 50Gi

Retorno do console

# PVC detail list
kubectl get pvc -n $env:NAMESPACE -o wide

# PVC description
kubectl describe pvc wikijs-data-pvc -n $env:NAMESPACE
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE     VOLUMEMODE
postgres-data-pvc   Bound    pvc-9906e095-5341-451f-a2ff-ffbd8d8991e3   20Gi       RWO            standard       <unset>                 3h29m   Filesystem
wikijs-data-pvc     Bound    pvc-30553c23-75aa-429e-9464-7a567103b320   50Gi       RWO            standard       <unset>                 3h29m   Filesystem
Name:          wikijs-data-pvc
Namespace:     test
StorageClass:  standard
Status:        Bound
Volume:        pvc-30553c23-75aa-429e-9464-7a567103b320
Labels:        app=test-wikijs
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
               volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      50Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Used By:       test-wikijs-5458d966c9-h97w8
Events:        <none>

# detail PV list
kubectl get pv -o wide

# Description d'un PV spécifique
kubectl describe pv wikijs-data-pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                                      STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE     VOLUMEMODE
pvc-30553c23-75aa-429e-9464-7a567103b320   50Gi       RWO            Delete           Bound      test/wikijs-data-pvc              standard       <unset>                          3h32m   Filesystem
pvc-9906e095-5341-451f-a2ff-ffbd8d8991e3   20Gi       RWO            Delete           Bound      test/postgres-data-pvc            standard       <unset>                          3h32m   Filesystem

kubectl describe pv pvc-30553c23-75aa-429e-9464-7a567103b320
Name:              pvc-30553c23-75aa-429e-9464-7a567103b320
Labels:            topology.kubernetes.io/region=europe-west1
                   topology.kubernetes.io/zone=europe-west1-b
Annotations:       pv.kubernetes.io/migrated-to: pd.csi.storage.gke.io
                   pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd
                   volume.kubernetes.io/provisioner-deletion-secret-name:
                   volume.kubernetes.io/provisioner-deletion-secret-namespace:
Finalizers:        [kubernetes.io/pv-protection external-attacher/pd-csi-storage-gke-io]
StorageClass:      standard
Status:            Bound
Claim:             test/wikijs-data-pvc
Reclaim Policy:    Delete
Access Modes:      RWO
VolumeMode:        Filesystem
Capacity:          50Gi
Node Affinity:
  Required Terms:
    Term 0:        topology.kubernetes.io/zone in [europe-west1-b]
                   topology.kubernetes.io/region in [europe-west1]
Message:
Source:
    Type:       GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
    PDName:     pvc-30553c23-75aa-429e-9464-7a567103b320
    FSType:     ext4
    Partition:  0
    ReadOnly:   false
Events:         <none>

kubectl exec -it $env:POD_NAME -n $env:NAMESPACE -- ls -la /wiki/data
total 28
drwxr-xr-x    4 root     root          4096 Jan 20 13:19 .
drwxr-xr-x    1 node     node          4096 Oct 12 09:00 ..
drwxr-xr-x    2 node     node          4096 Oct 12 08:55 content
drwx------    2 root     root         16384 Jan 20 13:05 lost+found

Pergunta : Como posso configurar corretamente as permissões para o pod WikiJS gravar em seu diretório de dados? O volume está montado, mas o aplicativo não consegue criar os diretórios necessários.

Eu executo o MySQL em um contêiner docker:

sudo docker run --rm --name mysql5 --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7
mysql -u root -h 172.20.0.2 -p$MROOTPASS

e criou um banco de dados experimental com o seguinte comando:

CREATE DATABASE testdb;

e comprometeu o contêiner:

sudo docker commit mysql5 mysql:5.7-test

Quando iniciei o contêiner comprometido:

sudo docker stop mysql5;
sudo docker run --rm --name mysql5 --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7-test

meu banco de dados de teste desapareceu.

É um comportamento normal ou fiz algo errado?

Meu entendimento era que o Docker armazena seus dados em algum lugar em seu armazenamento interno que é copiado para a nova imagem quando eu faço isso docker commit. O que eu entendi errado?

EDITAR1

sudo docker inspect mysql5 | grep -i volume

        "VolumeDriver": "",
        "VolumesFrom": null,
            "Type": "volume",
            "Source": "/var/lib/docker/volumes/1f04f07e91a16e6e9aeb393af2954dd7e32e2a2b93615fb4b6924de3568951af/_data",
        "Volumes": {

sudo docker inspect mysql:5.7

        "Volumes": {
            "/var/lib/mysql": {}
        },

EDITAR2

O Docker cria o volume com seu mysqlusuário que tem id=999:

sudo docker run --rm --name mysql5 -v /home/dmitriano/work/mysql:/var/lib/mysql --net legacy_net --net-alias mysql5 --ip 172.20.0.2 -e MYSQL_ROOT_PASSWORD=$MROOTPASS -d mysql:5.7

ll
drwxr-xr-x 5       999 root      4096 Jan 20 19:31 mysql/

sudo docker exec -it mysql5 bash -c "id 999"
uid=999(mysql) gid=999(mysql) groups=999(mysql)

O que devo fazer com este 999 na máquina host?