All perguntas(server)

Configuramos as configurações do BBR em todas as nossas máquinas RHEL 8.6 da seguinte forma: (de acordo com a documentação da Red Hat [https://access.redhat.com/solutions/3713681]). O objetivo é avaliar se a configuração do BBR proporciona alguma melhoria na rede. Caso contrário, planejamos reverter para as configurações padrão do Cubic.

sysctl -w net.ipv4.tcp_congestion_control=bbr
echo "net.ipv4.tcp_congestion_control = bbr" >> /etc/sysctl.conf
modprobe tcp_bbr

para reverter as alterações escrevi os seguintes passos

sysctl -w net.ipv4.tcp_congestion_control=cubic
delete from /etc/sysctl.conf the line with net.ipv4.tcp_congestion_control = bbr

mas não tenho certeza de como reverter as alterações sobremodprobe tcp_bbr

precisamos apenas fazer:

modprobe tcp_cubic

ou

rmmod tcp_bbr
rmmod: ERROR: Module tcp_bbr is in use

ou então?

Estou executando dois serviços (backend e API) na mesma porta dentro do Docker. No entanto, sempre que envio solicitações, o NGINX encaminha todas as solicitações para o serviço de backend, e não consigo acessar o serviço de API corretamente.

Suspeito que seja um problema com minha configuração do NGINX.

Aqui estão meus arquivos:

docker-compose.yml

version: '3.8'

services:
  backend:
    build:
      context: .
      dockerfile: ./backend/Dockerfile.dev
    volumes:
      - ./backend:/var/www/html/backend
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  api:
    build:
      context: .
      dockerfile: ./api/Dockerfile.dev
    volumes:
      - ./api:/var/www/html/api
    environment:
      - APP_ENV=development
    networks:
      - bysooq-network
    expose:
      - 9000
    env_file:
      - .env

  postgres:
    image: postgres:13
    restart: always
    volumes:
      - ~/bysooq-data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: xxx
      POSTGRES_USER: xx
      POSTGRES_PASSWORD: xxx
    networks:
      - bysooq-network

  redis:
    image: redis:latest
    ports:
      - "6380:6379"
    restart: always
    networks:
      - bysooq-network

  nginx:
    image: nginx:latest
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
      - ./api:/var/www/html/api
      - ./backend:/var/www/html/backend
    ports:
      - 80:80
    depends_on:
      - backend
      - api
    networks:
      - bysooq-network

networks:
  bysooq-network:
    driver: bridge

nginx default.conf

nginx

server {
    listen 80;
    server_name localhost;
    client_max_body_size 100M;
    index index.php;

    # API Service - Must come first with strict matching
    location ~ ^/api(/.*)?$ {
        root /var/www/html/api/web;
        try_files $1 $1/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass api:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root/index.php;
            fastcgi_param REQUEST_URI $1$is_args$args;
        }
    }

    # Backend Service
    location / {
        root /var/www/html/backend/web;
        try_files $uri $uri/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_pass backend:9000;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }
}

O que eu espero:

Solicitações para /api/* devem ir para o serviço de API.

Outras solicitações devem ser encaminhadas para o serviço de backend.

O que acontece:

Todas as solicitações (mesmo /api/...) são tratadas pelo backend.

Pergunta: Como posso configurar corretamente o NGINX para rotear solicitações /api/* para o serviço de API e outras solicitações para o serviço de backend?

Desde já, obrigado!

Pesquisei em vários lugares online e todas as fontes parecem sugerir que se trata de um problema de resolução de DNS. No entanto, o DNS resolve bem na minha máquina, e consultas whois para outros TLDs (por exemplo, .com) não apresentam esse problema.

Também tentei em várias máquinas diferentes, obtendo o mesmo resultado.

Mon 04-28 03:49 OVH root ~
> whois google.com | head
   Domain Name: GOOGLE.COM
   Registry Domain ID: 2138514_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2019-09-09T15:39:04Z
   Creation Date: 1997-09-15T04:00:00Z
   Registry Expiry Date: 2028-09-14T04:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: [email protected]

Mon 04-28 03:49 OVH root ~
> whois icann.org | head
This domain is protected by the Registry Lock service. If you are the registrant and wish to take action on this lock, please contact your registrar.

Domain Name: icann.org
Registry Domain ID: 628dbbcb4edc464b9401cbadea0a08b2-LROR
Registrar WHOIS Server: http://whois.cscglobal.com
Registrar URL: http://www.cscglobal.com/global/web/csc/digital-brand
Updated Date: 2025-01-31T20:19:44Z
Creation Date: 1998-09-14T04:00:00Z
Registry Expiry Date: 2028-12-07T17:04:26Z
Registrar: CSC Corporate Domains, Inc.

Mon 04-28 03:49 OVH root ~
> whois nic.app | head
getaddrinfo(whois.nic.app): Name or service not known

Minha configuração do Wireguard parou de funcionar repentinamente ontem, sem nenhuma alteração de configuração ou chave. Para solucionar o problema, reduzi-a à configuração mais simples. Um cliente na minha rede deve se conectar a um servidor rodando em um VPS.

Configuração do servidor ("posto avançado"):

outpost:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <outpost-privkey>
Address = 10.5.0.1/16
MTU = 1440
ListenPort = 51820

[Peer]
PublicKey = <rp-pubkey>
AllowedIPs = 10.5.0.2/32
PersistentKeepAlive = 13

Configuração do cliente ("rp"):

rp:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <rp-privkey>
Address = 10.5.0.2/16
MTU = 1440

[Peer]
PublicKey = <outpost-pubkey>
Endpoint = <outpost-ip>:51820
AllowedIPs = 10.5.0.1/32
PersistentKeepAlive = 23

Usando dmesge tcpdumpposso observar repetidas tentativas de iniciação de handshake enviadas pelo cliente:

rp:~# dmesg -wT
...
[Fri Apr 25 23:45:18 2025] wireguard: wg0: Sending handshake initiation to peer 1 (<outpost-ip>:51820)

rp:~# tcpdump -n -vvv -i ens18 udp port 51820
...
23:45:19.115710 IP (tos 0x88, ttl 64, id 34886, offset 0, flags [none], proto UDP (17), length 176)
    <rp-ip>.48825 > <outpost-ip>.51820: [bad udp cksum 0x825d -> 0x3db4!] UDP, length 148

O servidor recebe o pacote:

outpost:~# tcpdump -n -vvv -i enp0s6 udp port 51820
...
23:45:19.129033 IP (tos 0x8, ttl 55, id 34886, offset 0, flags [none], proto UDP (17), length 176)
    <rp-ip>.46567 > <outpost-rp>.51820: [udp sum ok] UDP, length 148

Mas o Wireguard no servidor não mostra nenhuma indicação de que recebeu algo.

outpost:~# wg
interface: wg0
  public key: <outpost-pubkey>
  private key: (hidden)
  listening port: 51820

peer: <rp-pubkey>
  allowed ips: 10.5.0.2/32
  persistent keepalive: every 13 seconds

O servidor tenta regularmente enviar sua própria iniciação de handshake:

outpost:~# dmesg -wT
[Fri Apr 25 23:46:45 2025] wireguard: wg0: Sending handshake initiation to peer 1 ((einval))

Mas como o servidor não tem conhecimento do IP público (dinâmico) do cliente, essa iniciação de handshake não aparece nem no servidor nem no cliente que o utiliza tcpdump.

Ambas as máquinas usam o mesmo servidor NTP ( ntp.ubuntu.com) e estão sincronizadas corretamente. Minha MTU de 1440 está otimizada para minha configuração, e o comportamento não muda sem esta linha. Também regenerei as chaves do servidor/cliente várias vezes sem alterações no comportamento.

iptables estão definidos corretamente no servidor/cliente:

# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
...

O UFW não está instalado.

Qualquer sugestão é bem-vinda.

Estou instalando o Solr 9.6.1 no Unix seguindo este link e consigo iniciar o serviço por meio do comando abaixo

service solr start

Mas não consigo iniciar o serviço através de systemctl. Ao executar systemctl start solraparece a mensagem abaixo

Job for solr.service failed because the control process exited with error code.
See "systemctl status solr.service" and "journalctl -xeu solr.service" for details.

A execução systemctl status solrfornece a mensagem abaixo

× solr.service - Apache SOLR
     Loaded: loaded (/etc/systemd/system/solr.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Fri 2025-04-25 02:54:41 EDT; 1min 19s ago
    Process: 5298 ExecStart=/opt/solr/bin/solr start -noprompt (code=exited, status=1/FAILURE)
        CPU: 89ms
 
systemd[1]: solr.service: Scheduled restart job, restart counter is at 5.
systemd[1]: Stopped Apache SOLR.
systemd[1]: solr.service: Start request repeated too quickly.
systemd[1]: solr.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Apache SOLR.

Abaixo está o conteúdo de/etc/systemd/system/solr.service

[Unit]
Description=Apache SOLR
After=syslog.target network.target remote-fs.target nss-lookup.target
 
[Service]
Type=forking
PIDFile=/var/solr/solr-8983.pid
Environment=SOLR_INCLUDE=/etc/sysconfig/solr
ExecStart=/opt/solr/bin/solr start -noprompt
ExecStop=/opt/solr/bin/solr stop -noprompt
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
User=solr
PrivateTmp=true
TimeoutSec=180s
LimitNOFILE=65000
LimitNPROC=65000
 
[Install]
WantedBy=multi-user.target

Resumo da questão

Estou enfrentando um atraso muito longo (~20–40 segundos) ao abrir uma nova sessão SSH ou ao usar sudopela primeira vez um terminal no meu sistema Debian 11. sudoComandos subsequentes no mesmo terminal são instantâneos, mas o atraso retorna em um novo terminal. Para sua informação, isso acontece tanto com SSH remoto quanto com SSH local ( ssh admin@localhost).

O que eu tentei

• UseDNS noe GSSAPIAuthentication nosão definidas em sshd_config.
• Nenhum módulo PAM personalizado ou relacionado à rede (sem pam_ldap, pam_krb5, pam_sss, etc.).
• Comentado pam_systemd.soem sessão comum sem efeito.
• nsswitch.conf é padrão: somente filese dnspara hosts, sem LDAP/NIS para usuários/grupos.
• hosts está correto e inclui ambos 127.0.1.1e o IP real com o nome do host.
• Nenhum /etc/nologinarquivo.
• As permissões tmp estão corretas ( drwxrwxrwt).
• Nenhuma regra access.conf.
• profile, bash.bashrc, environment e dotfiles do usuário estão limpos ou foram movidos temporariamente.
• Sem cotas ou problemas de espaço em disco.
• o correio existe e é acessível.
• passwd e group são normais.
• Nenhuma entrada incomum em sudoers ou sudoers.d.
• Nenhum /etc/motd.d/script MOTD ou scripts personalizados.
• Nenhum problema com limits.conf ou limits.d.
• Não /etc/ldap.confou /etc/sssd/sssd.confpresente.
• systemd-logind, dbus, e polkitestão em execução e foram reiniciados.
• Nenhum erro em dmesg, auth.log ou syslog.
• Sem alta carga de CPU, memória ou E/S durante o atraso.
• Nenhuma montagem de rede ou autofs.
• As permissões pts estão corretas.
• Os diretórios pessoais existem, têm permissões corretas e são locais.
• O shell é bash e funciona.
• Testado com o mínimo de usuários e sh como shell
• straceligado sudoe sshdmostra que o atraso ocorre antes que os scripts do shell ou do perfil do usuário sejam executados.
• straceon sshde seus filhos mostram longas esperas em select()ou read()em descritores de arquivo internos (não soquetes de rede).
• O atraso ocorre depois que a autenticação da senha é bem-sucedida, mas antes que o prompt do shell apareça.
• ssh -vvva saída mostra o atraso antes debug2: we sent a password packet, wait for replye depois debug1: Authentication succeeded (password).

Atualizar

• Entropia disponível: 256
• O hardware é Armv7 Cortex A7 dual-core 1GHz, 2GB DDR3L, o armazenamento é eMMC

Estou completamente sem ideias... O que inicialmente parecia um simples problema de DNS me deixou sem a mínima ideia do que realmente está acontecendo.

Obrigado por qualquer ajuda ou informação!

Após uma queda de energia e uma falha no UPS, o pool ZFS está em um estado que não consigo entender:

$ zpool status -c serial
  pool: storage
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
  scan: scrub repaired 0B in 1 days 10:40:40 with 0 errors on Wed Apr  2 10:40:42 2025
config:

        NAME                                                  STATE     READ WRITE CKSUM                serial
        storage                                               DEGRADED     0     0     0
          raidz2-0                                            DEGRADED     0     0     0
            8844532865098720143                               FAULTED      0     0     0  was /dev/sda1  ZL2AJ3S10000C1111G0H
            scsi-35000c500cafcbb67                            ONLINE       0     0     0  ZL2AJ3S10000C1111G0H
            scsi-35000c500cafc9a63                            ONLINE       0     0     0  ZL2AKR3F0000C1128SV6
            scsi-35000c500cafcb303                            ONLINE       0     0     0  ZL2AKQVX0000C1143G62
            scsi-35000c500cafcff33                            ONLINE       0     0     0  ZL2AKAG10000C11445AW
            scsi-35000c500cafc392b                            ONLINE       0     0     0  ZL2AKCWB0000C1143ARJ
            wwn-0x5000c500cafa8287                            ONLINE       0     0     0  ZL2AHSSL0000C107BQWN
            scsi-35000c500cafbec03                            ONLINE       0     0     0  ZL2AGE6X0000C1122SME
            7647119559265938125                               FAULTED      0     0     0  was /dev/sdi1  ZL2AGE6X0000C1122SME
            scsi-35000c500cafca18b                            ONLINE       0     0     0  ZL2AKR0B0000C1128RNJ
            scsi-35000c500cafc29c3                            ONLINE       0     0     0  ZL2AGDN30000C1140NTP
            scsi-35000c500cafbe293                            ONLINE       0     0     0  ZL2AKDSM0000C11278YB
          raidz2-1                                            DEGRADED     0     0     0
            scsi-SSEAGATE_ST16000NM002G_ZL2AKBXB0000C1126C6X  ONLINE       0     0     0  ZL2AKBXB0000C1126C6X
            1470086598115969130                               UNAVAIL      0     0     0  was /dev/sdy1          20342A6158FC
            wwn-0x5000c500cae0af8b                            ONLINE       0     0     0  ZL29T97Q0000C107188W
            12722321230162544658                              FAULTED      0     0     0  was /dev/sdl1  ZL2AKDSM0000C11278YB
            scsi-35000c500cafc3be7                            ONLINE       0     0     0  ZL2AJJZF0000C1143AH2
            scsi-35000c500cafc611f                            ONLINE       0     0     0  ZL2AKC6Z0000C11438R8
            scsi-35000c500cafcfb97                            ONLINE       0     0     0  ZL2AHY5R0000C11441Z5
            scsi-35000c500cafc8663                            ONLINE       0     0     0  ZL2AKBNX0000C1128RLR
            scsi-35000c500cafc9fa3                            ONLINE       0     0     0  ZL2AKR0Y0000C1128RN1
            scsi-35000c500cafc96b3                            ONLINE       0     0     0  ZL2AKR6T0000C1128SQP
            scsi-35000c500cafc2f23                            ONLINE       0     0     0  ZL2AK1NP0000C1143FXB
            scsi-35000c500cafc4ccf                            ONLINE       0     0     0  ZL2AKCKG0000C1143ETM
        logs
          nvme-INTEL_SSDPED1K375GA_PHKS01530050375AGN         ONLINE       0     0     0    PHKS01530050375AGN
        cache
          sdu                                                 FAULTED      0     0     0  corrupted data  ZL2AKR6T0000C1128SQP
          sdw                                                 FAULTED      0     0     0  corrupted data  ZL2AK1NP0000C1143FXB

Há muita coisa que não entendo no status acima:

1. Todos os discos COM DEFEITO têm o mesmo número de série de um dos discos ONLINE
2. O número de série do disco UNAVAIL é de um dos dois SSDs que uso para cache, não de um dos HDDs usados ​​para o pool
3. As séries dos dois discos de cache com FALHA são as de dois HDDs de armazenamento

O que poderia ter acontecido para reduzir o pool nesse estado? É recuperável? Pensei em tentar o procedimento descrito aqui, mas não consigo nem entender quais são os discos com defeito. O procedimento simples descrito nesta postagem funcionaria no meu caso? Preciso muito de ajuda com isso, agradeço antecipadamente.

Usando o Rocky 9.4 e o OpenSSH 8.7p1, tenho um par de chaves RSA que não é aceito, a menos que o sshd esteja em modo de depuração. (Felizmente, tenho um par antigo que funciona).

Desativei o SSH_AUTH_SOCK e verifiquei que nenhum agente está envolvido. Movi o ~/.ssh/config para evitar essa complicação. Verifiquei que o ~/.ssh/ está no modo 0700, id_rsa e authorized_keys estão em 0400 e known_hosts está em 0600. Confirmei que a chave pública correta está em authorized_keys e verifiquei usando 'ssh-keygen -l'.

Quando o sshd está sendo executado como um serviço e eu executo 'ssh -avv -i ~/.ssh/id_rsa localhost', vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Authentications that can continue:  publickey, ...
we did not send a packet, disable method
Next authentication method: keyboard-interactive

... e sou solicitada minha senha normal.

/var/log/secure mostra:

Connection from 127.0.0.1 ...
Failed publickey for (user) and shows the same correct SHA256 code.

Encontrei o conselho de que eu deveria interromper o serviço sshd e executá-lo manualmente em modo de depuração. Abri uma segunda sessão como root e executei:

systemctl stop sshd
/usr/sbin/sshd -D -ddd -e

Quando repito o comando 'ssh -avv -i ~/.ssh/id_rsa localhost' na janela do usuário original, vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Server accepts key:   (with the correct filename and SHA256 fingerprint)
Enter passphrase for key '(filename)':  (I type passphrase)
Authenticated to 127.0.0.1 (via proxy) using "publickey".

... e consegui fazer login usando a mesma chave.

Eu esperava que sshd -D -ddd me ajudasse a descobrir o problema, mas ele aceita minha chave com prazer.

Atualização 2024-04-30

Seguindo a sugestão de @mircea-vutcovici , a configuração LogLevel: DEBUGgerou sshdsequências diferentes de mensagens ao tentar chaves diferentes: a tentativa com falha incluiu uma mensagem que authorized_keysnão era legível, apesar de todas as chaves estarem no mesmo arquivo e na mesma sshdinstância!

Meu diretório home é um compartilhamento NFS e o SELinux está sendo aplicado, então pesquisei mais usando a sugestão do @grawity : ls -LZproduziu system_u:object_r:nfs_t:s0um rótulo genérico do SELinux. Aparentemente, isso é um problema se a montagem NFS preceder o patchwork de carregamento da política SELinux: selinux: faça o NFS rotulado funcionar quando montado antes do carregamento da política . Esse problema foi corrigido em 2023 e deveria ter sido incluído no Rocky 9.4 (meados de 2024). Dito isso, /homeé montado com NFS, vers=3a propósito.

Finalmente, encontrei um encantamento útil serverfault: Rótulos SELinux errados em casas NFS? : setsebool -P use_nfs_home_dirs on. Agora posso usar ambas as chaves, mas ainda não consigo entender por que elas foram tratadas de forma diferente, já que ambas as chaves públicas estão no mesmo arquivo e ambas as chaves privadas têm as mesmas permissões na mesma pasta.

Acabei de me deparar com uma pergunta semelhante de 13 anos atrás: a autenticação de chave pública falha SOMENTE quando sshd é daemon . Aparentemente, o SELinux é sempre o problema :-) Vou dar os créditos ao @grawity por uma resposta que me fez cair em uma grande enrascada.

Em nossa rede, todas as VMs e servidores têm /tmp montado como noexec por motivos de segurança. Tentar instalar o Jira resulta em falha ao tentar executar o Java a partir dessa pasta. Como posso resolver esse problema?

Carreguei arquivos na minha conta do Azure e atingi minha cota (100):

Os arquivos foram enviados com:

from openai import AzureOpenAI
from config import AZURE_OPENAI_CONFIG

client = AzureOpenAI(
    azure_endpoint=AZURE_OPENAI_CONFIG["azure_endpoint"],
    api_key=AZURE_OPENAI_CONFIG["api_key"],
    api_version=AZURE_OPENAI_CONFIG["api_version"],
)

with open('training_set.jsonl', 'rb') as tf:  
    training_resp = client.files.create(file=tf, purpose="fine-tune")  

Como posso remover todos os meus arquivos de uma vez?