All perguntas(server)

Lembro que posso ver RX‌e TXvia ifconfig.
Por exemplo:

root@debian:~# ifconfig enp0s31f6
enp0s31f6: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.1.106  netmask 255.255.255.255  broadcast 192.168.1.106
        ether 54:e1:ad:62:7f:b6  txqueuelen 1000  (Ethernet)
        RX packets 87  bytes 11064 (10.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 103  bytes 12049 (11.7 KiB)
        TX errors 0  dropped 525 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xec200000-ec220000  

Como posso fazer isso via iproute?

Tenho um problema com meu registro PTR.

Configurei minhas configurações de DNS PTR, mas o MXToolbox não as reconhece. O que há de errado?

Caixa de ferramentas MXSupter

Configurações de DNS

Todas as outras configurações de DNS funcionam

Se, na minha configuração de DNS, eu tiver um registro como este:

sub.example.com NS ns1.nameserverexample.com

As solicitações de pesquisa para subdomínios de sub.example.com(por exemplo, a.sub.example.com) também serão direcionadas para ns1.nameserverexample.com? Ou eu precisaria criar um registro NS adicional para a.sub.example.compara enviar essas solicitações para ns1.nameserverexample.com?

Se possível, eu apreciaria ter uma fonte confiável para quaisquer respostas dadas. Passei algum tempo procurando a resposta, e até agora o Gemini do Google parece dizer que a resposta é "não" (mas não consigo encontrar isso claramente declarado em nenhuma das referências às quais ele faz link) e um comentário do Reddit sem fonte sugere que a resposta é "sim".

Tenho alguns problemas com uma configuração específica que desejo alcançar:

Resumo:

• O Nginx atua como um proxy reverso
• Backend em execução em http://localhost:8080/
• O Nginx pode retornar HTTP 403 ( $block_access = true), nesse caso quero mostrar uma página de erro personalizada ( /errors/403.html)
• O backend pode retornar HTTP 404, nesse caso também quero mostrar uma página de erro personalizada ( /errors/404.html)

Problemas:

• A página HTTP 403 personalizada não funciona, a página Nginx 403 padrão é exibida em seu lugar
• Página HTTP 404 personalizada para o backend funciona
• Se eu remover proxy_intercept_errorsdo bloco de localização, a página 403 personalizada funciona para o Nginx, mas a página 404 personalizada para o proxy obviamente não funciona mais

Configuração:

server {
    listen 443 ssl http2;
    server_name mydomain.com;

    # Reverse proxy configuration
    location / {
        # Let Nginx handle basic blocking behavior
        if ($block_access) {
            return 403;
        }

        # Proxy request to backend
        proxy_pass http://localhost:8080/;
        proxy_buffering off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Connection $http_connection;

        # Only intercept 404 errors from the backend
        proxy_intercept_errors on;
        error_page 404 /errors/404.html;

        # Serve custom 404 error page
        location = /errors/404.html {
            root /var/www/html;
            internal;
        }
    }

    # Serve custom 403 error page for blocked access ($block_access = true)
    error_page 403 /errors/403.html;
    location = /errors/403.html {
        root /var/www/html;
        internal;
    }

    location /errors/ {
        root /var/www/html;
        try_files $uri $uri/ =404;
    }
}

Estou mais ou menos completamente perdido na busca por uma solução...

Então, um dos nossos administradores se sentiu estranho e começou a brincar com os esquemas de cores do Jira e do Confluence recentemente. O resultado não é muito amigável ao usuário, nem em termos de usabilidade (contraste etc.) nem esteticamente.

Quero redefinir tudo relacionado às configurações do esquema de cores de volta aos padrões de fábrica. O problema é que não tenho ideia de quais são/eram os padrões de fábrica.

(Eu provavelmente conseguiria descobrir quais são os padrões de fábrica restaurando um backup mais antigo, mas tenho certeza de que a comunidade do SO fornecerá essas informações muito mais rápido.)

Versões usadas: Jira 10.x, Confluence 9.x. Ambas estão no local, mas eu imagino que os esquemas de cores funcionam da mesma forma em instâncias de nuvem. Também imagino que diferentes versões principais tenham esquemas de cores padrão bem semelhantes.

Atalhos para as páginas de administração que possuem essas informações:

<Jira base URL>/admin/LookAndFeel!default.jspa
<Confluence base URL>/admin/lookandfeel.action

O que preciso é do conteúdo completo das seções Colors, Gadget Colors, Global Color Scheme, especialmente os códigos de cores hexadecimais, como #FFFFFF. Se houver um código de cor separado para temas claros e escuros, informe ambos na sua resposta.

Se alguém puder me indicar páginas de recursos oficiais da Atlassian com essas informações exatas, seria uma ótima resposta também.

systemdpermite combinar uma .pathunidade e uma .serviceunidade de modo que escrever um arquivo ativará o serviço. Agora considere que o serviço deve ser iniciado após cada modificação de arquivo. Não há problema em unir várias modificações em um único início, mas a unidade de serviço deve ser iniciada após cada modificação. Não é assim que o systemd normalmente opera. Se o serviço estiver em execução no momento da modificação, ele será considerado ativo e não ativado, mas deverá ser ativado imediatamente após terminar nessa situação. Essas semânticas podem ser alcançadas de alguma outra forma?

Tenho o seguinte sistema Linux antigo e uso uma ferramenta de software proprietária que tenta copiar arquivos (com sftp ou curl) para um sistema Linux mais novo, mas falha. Os sistemas são:

Cheirando a troca vemos:

• O pacote de resposta de troca do Grupo Diffie-Hellman do servidor confirma os seguintes parâmetros negociados:
  • Algoritmo de troca de chaves (KEX): diffie-hellman-group-exchange-sha256 (corresponde ao suporte do cliente ✅)
  • Algoritmo de criptografia: aes128-ctr (corresponde ao suporte do cliente ✅)
  • Algoritmo MAC: hmac-sha2-256 (corresponde ao suporte do cliente ✅)
  • Compressão: nenhuma (corresponde ao suporte do cliente ✅)
  • Tipo de chave do host: ssh-rsa (corresponde ao suporte do cliente ✅, mas veja abaixo)
  • Tipo de assinatura do host: rsa-sha2-256 (problema potencial ⚠️)

O tipo de chave de host na resposta KEX do servidor é ssh-rsa, que o cliente suporta. No entanto, o tipo de assinatura usado pelo servidor é rsa-sha2-256, que o cliente não anunciou suporte em sua mensagem SSH_MSG_KEXINIT.

Tenho olhado o arquivo /etc/ssh/ssh_configand /etc/ssh/sshd_configpara uma modificação de configuração que eu poderia fazer no sistema Rocky Linux 9.5 para suportar a troca, mas não encontrei nenhuma. Também tentei adicionar o seguinte a /etc/ssh/sshd_config (conforme proposto por este outro caso ), mas isso também falhou:

# Allow mildly-outdated cipher selection                                                                                                                                                                                                                                                                                                                              
Ciphers +aes128-cbc                                                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                                                                        
# Allow negotiating cipher key using weak DH                                                                                                                                                                                                                                                                                                                          
# (only add group1 if you *really* need it)                                                                                                                                                                                                                                                                                                                           
KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                                                                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                                                                                                        
# Offer SHA1 signatures for host pubkey                                                                                                                                                                                                                                                                                                                               
HostKeyAlgorithms +ssh-rsa                                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                        
# Accept SHA1 signatures for client pubkey                                                                                                                                                                                                                                                                                                                            
PubkeyAcceptedAlgorithms +ssh-rsa    

A solução real será atualizar esse antigo derivado do CentOS 7, mas antes de fazer isso preciso fazer a cópia do arquivo funcionar para concluir vários testes.

Estou, portanto, procurando uma solução temporária onde eu modificaria a configuração do sistema Rocky Linux 9.5 para permitir a transferência de arquivos. Alguém sabe qual alteração/adição de configuração deve ser feita?

Tenho lido sobre redes esta semana, mas ainda tenho uma lacuna aparentemente significativa no meu entendimento, relacionada a quais endereços IP são acessíveis a partir da minha máquina host e como.

Especificamente, ip -br addrmostra:

lo               UNKNOWN        127.0.0.1/8 ::1/128
tunl0@NONE       DOWN
sit0@NONE        DOWN
ip6tnl0@NONE     DOWN
eth0@if15        UP             198.19.249.109/24 metric 1024 fd07:b51a:cc66:0:439:fcff:fe3f:27d6/64 fe80::439:fcff:fe3f:27d6/64
docker0          DOWN           172.17.0.1/16 fe80::acc7:7cff:fe73:5421/64
br-140e1fbca70a  UP             172.18.0.1/16 fe80::34c3:10ff:fe55:2464/64
vethbf1bfcc@if5  UP             fe80::38fd:c6ff:fe37:f54/64
veth7e8fb76@if5  UP             fe80::689e:8bff:fe81:d8c3/64

E ip routemostra:

default via 198.19.249.1 dev eth0 proto dhcp src 198.19.249.109 metric 1024
0.250.250.200 via 198.19.249.1 dev eth0 proto dhcp src 198.19.249.109 metric 1024
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-140e1fbca70a proto kernel scope link src 172.18.0.1
198.19.249.0/24 dev eth0 proto kernel scope link src 198.19.249.109 metric 1024
198.19.249.1 dev eth0 proto dhcp scope link src 198.19.249.109 metric 1024

E ip neighmostra:

198.19.249.1 dev eth0 lladdr da:9b:d0:54:e0:02 STALE
172.18.0.3 dev br-140e1fbca70a lladdr fe:50:d0:de:5a:ce STALE
fe80::d84c:3aff:fef1:e382 dev eth0 lladdr da:9b:d0:54:e0:02 router STALE

Além disso, docker network inspect ..._..._defaultdiz que a rede possui Gateway 172.18.0.1, com dois contêineres conectados a ela, incluindo 172.18.0.3.

iptablescontém apenas as regras padrão do Docker .

Pergunta :

Corri ip route del 172.18.0.0/16e excluí essa entrada da tabela de roteamento.

Por que não consigo mais acessar o contêiner do Docker agora?

O 172.18.0.3contêiner roda localmente na minha máquina, então eu esperava poder acessá-lo, se eu ajustasse as iptableregras de alguma forma. Não é isso?

Tenho uma política de rede global que se parece com isso (registrar qualquer pacote que não esteja na porta 30000 e permitir apenas o tráfego para a porta 30000 na interface ens4):

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: internal-rules
spec:
  selector: interface == 'ens4'
  applyOnForward: true
  types:
  - Ingress
  - Egress
  ingress:
  - action: Log
    protocol: TCP
    destination:
      notPorts:
      - 30000:32767
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 30000:32767
  egress:
  - action: Allow

então aplico isso a uma interface com um hostendpoint como este.

apiVersion: projectcalico.org/v3
kind: HostEndpoint
metadata:
  name: node1-internal-if
  labels:
    interface: ens4
spec:
  interfaceName: ens4
  node: testmdm2503nic-node1

Tenho regras diferentes para as 3 interfaces diferentes que tenho na minha configuração. Em geral, funciona para filtrar meu tráfego, mas vejo pacotes sendo descartados de forma inesperada. Por exemplo, o seguinte pacote é descartado. Observe que a interface IN está em branco; eu teria pensado que ela não deveria ser filtrada por uma das minhas regras de hostendpoint. A porta 30000 é uma das portas que listei como aberta no ens4, mas não tenho certeza de qual interface esse tráfego está chegando.

Ter 11 Mar 18:02:39 2025 : INFO | kickRegressionSuite: 11 Mar 16:43:04 testmdm2503nic-k8sc-node1-2 kernel: calico-packet: IN= OUT=cali6f00f63eeec SRC=1.2.3.4 DST=1.2.8.4 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=9941 DF PROTO=TCP SPT=58082 DPT=30000 WINDOW=64240 RES=0x00 SYN URGP=0 MARK=0x69a04000

Quando um pacote é descartado conforme o esperado, normalmente o log teria o nome da interface listado no campo IN:

20 de fevereiro 10:30:50 loriek8s-k8sc-node2-3 kernel: calico-packet: IN=ens3 OUT= MAC=fa:: SRC=1.1.7.9 DST=1.1.7.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=53798 DF PROTO=TCP SPT=33728 DPT=10250 WINDOW=29200 RES=0x00 SYN URGP=0

alguma ideia do que posso estar fazendo errado ou talvez o registro de pacotes descartados não esteja como eu esperava.

como estou com dificuldades para encaminhar o IP real para os aplicativos docker, agora estou executando o docker traefik no modo de rede host.

traefik e serviços funcionam. Aqui está minha configuração

docker-compose.yaml:

---
services:
  traefik:
    image: traefik:latest
    container_name: traefik
    network_mode: host
    volumes:
      - ./traefik.yaml:/traefik.yaml
      - ./letsencrypt/:/letsencrypt/
      - /run/docker.sock:/var/run/docker.sock:ro
    labels:
      - traefik.enable=true
      - traefik.http.routers.traefik.rule=Host(`frontal.cestpasla.norhere.net`)
      - traefik.http.routers.traefik.entrypoints=websecure
      - traefik.http.routers.traefik.service=api@internal
      - traefik.http.services.traefik-0000traefik.loadbalancer.server.port=8080
      - traefik.http.routers.traefik.tls.certresolver=myresolver
      - traefik.http.routers.traefik.middlewares=traefik-auth
      - traefik.http.middlewares.traefik-auth.basicauth.users=me:encryptedpassword

O arquivo yaml estático do traefik:

---
api:
  dashboard:
providers:
  docker:
    exposedByDefault: false
entrypoints:
  web:
    address: 10.20.0.2:80
  websecure:
    address: 10.20.0.2:443
certificatesresolvers:
  myresolver:
    acme:
      tlschallenge: true
      email: [email protected]
      storage: /letsencrypt/acme.json
#log:
#  level: DEBUG

A linha problemática é:

      - traefik.http.services.traefik-0000traefik.loadbalancer.server.port=8080

O nome do serviço do painel é traefik-0000traefik, provavelmente porque o arquivo docker-compose está em uma pasta chamada 0000.traefik. Não me lembro em que ponto dos meus testes eu tive que adicionar essa linha de repente, mas a partir de agora, no modo host de rede, se eu não usar essa linha, posso ver esse erro nos logs do docker:

2025-03-12T11:25:38Z ERR error="service \"traefik-0000traefik\" error: port is missing" container=traefik-0000traefik-09ccfe569180f81f22b135fd75082ed017ce95a7dc0ade1ab5a7e2bfbd960886 providerName=docker

A questão:
Se eu precisar usar uma linha de configuração para o serviço do painel, posso pelo menos escolher o nome do serviço, digamos traefik_dashboard, ou algo parecido? E como?