All perguntas(server)

Tenho duas conexões WAN alimentando meu roteador Linux homebrew. Ambas são apresentadas como conexões ethernet. Uma usa dhcp, a outra é PPPoE. Configurei ambas usando nmcli.

O próximo passo é usar o roteamento de políticas para sistemas selecionados. Como teste, adicionei uma tabela de roteamento para cada conexão WAN, criei dois novos IPs no lado LAN do roteador e adicionei uma regra de IP para cada um desses IPs para usar uma das tabelas de roteamento. Isso também funciona bem quando configurado manualmente usando comandos iproute2.

O problema surge quando tento configurar esse cenário com nmcli. Chego perto com:

nmcli con mod pppoe ipv4.routes "0.0.0.0/0 onlink=1 table=200"
nmcli con mod pppoe ipv4.routing-rules "priority 999 from 10.87.3.204 lookup 200"
nmcli con up pppoe

nmcli con mod eth2 ipv4.routes "0.0.0.0/0 onlink=1 table=201"
nmcli con mod eth2 ipv4.routing-rules "priority 999 from 10.87.3.59 lookup 201"
nmcli con up eth2

Fiquei agradavelmente surpreso ao descobrir que a conexão PPPoE realmente funcionou, já que deixar a opção nexthop fora da regra faz com que o padrão seja usar o dispositivo para roteamento, que é exatamente o que eu fiz manualmente.

Entretanto, fazer o mesmo para a conexão dhcp não funciona, pois usar 'dev eth2' para a rota está errado... Ele precisa do endereço do próximo salto/gateway, que é dinâmico e o que eu fiz manualmente.

Obviamente, criar um script para atualizar a tabela de roteamento é simples, mas seria melhor fazer o gerenciador de rede fazer isso quando a conexão for criada. Ele obviamente terá essas informações, como a interface ppp é conhecida pela conexão PPPoE.

Existe algum mecanismo para incorporar ip4.gateway na sequência de roteamento? Ou existe outro método para atingir o mesmo objetivo?

Não sou especialista em nmcli, pois nos anos passados ​​sempre o evitei. Estou gostando do desafio de lidar com ele agora, então espero que haja algo muito básico que eu tenha perdido e que não tenha aprendido na minha jornada até agora.

Qualquer ajuda seria apreciada

Tenho um arquivo robots.txt que se parece com isto:

    User-agent: *
    Disallow: /account/
    Disallow: /captcha/
    Disallow: /checkout/
    
    User-agent: DataForSeoBot
    Disallow: /p-

    User-agent: UptimeRobot
    Disallow: /p-

Tenho dezenas de arquivos e pastas na minha regra de proibição de curinga. Então, quero bloquear adicionalmente o acesso a URLs que começam com /p- para rastreadores específicos como o DataForSeoBot. Antes de adicionar a regra específica para o DataForSeo, ele estava vendo a longa lista de URLs na minha regra de curinga. Depois que adicionei essa regra específica adicional pelo nome do bot, a ÚNICA regra de proibição que o DataForSeoBot agora vê é a /p-. Eles estão lendo o arquivo robots.txt incorretamente ou eu não o escrevi incorretamente? Espero não ter que repetir a primeira regra inteira para cada rastreador que também quero proibir /p-, pois há cerca de uma dúzia deles. Também tentei mover a regra específica por nome para o topo antes da regra de curinga, mas não fez diferença.

Estou testando usando o recurso no site deles para ver como eles estão lendo o arquivo robots.txt.

Eu estava tentando criar um cluster mongodb com replica set usando 3 pc. Sou muito novo no mongodb. Os 3 pc têm almalinux9.5 e mongodb v6 instalados. Até agora, eu dei esses comandos como root.

 yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
 percona-release enable psmdb-60 release
 yum list percona-server-mongodb --showduplicates
 yum install percona-server-mongodb
 systemctl start mongod
 systemctl status mongod
 systemctl stop mongod
 mongosh
 sudo firewall-cmd --add-port=27017/tcp --permanent
 firewall-cmd --reload
 systemctl restart mongod
 rm /tmp/mongodb-27017.sock
 systemctl restart mongod
 systemctl status mongod
 mongosh --port 27017  --authenticationDatabase "admin" -u "admin" -p
 nano /etc/mongod.conf 
 systemctl stop mongod

o arquivo conf é este:

dbPath: /var/lib/mongo
  journal:
    enabled: true
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongo/mongod.log
processManagement:
  fork: true
  pidFilePath: /var/run/mongod.pid
net:
  port: 27017
  bindIp: 0.0.0.0
security:
  authorization: enabled
replication:
  replSetName: "rs0"
security:
    keyFile: /etc/mongodb/keyfile

quando tento iniciar o mongod, e faço isso como root, recebo este log de erro:

{"t":{"$date":"2025-01-16T12:01:48.622+01:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"-","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2025-01-16T12:01:48.629+01:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"-","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":17},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":17},"outgoing":{"minWireVersion":6,"maxWireVersion":17},"isInternalClient":true}}}
{"t":{"$date":"2025-01-16T12:01:48.630+01:00"},"s":"I",  "c":"NETWORK",  "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."}
{"t":{"$date":"2025-01-16T12:01:48.632+01:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"permissions on /etc/mongodb/keyfile are too open"}}}
{"t":{"$date":"2025-01-16T12:01:48.633+01:00"},"s":"I",  "c":"SHARDING", "id":5847201, "ctx":"main","msg":"Balancer command scheduler stop requested"}
{"t":{"$date":"2025-01-16T12:01:48.633+01:00"},"s":"I",  "c":"ASIO",     "id":22582,   "ctx":"main","msg":"Killing all outstanding egress activity."}
{"t":{"$date":"2025-01-16T12:01:48.633+01:00"},"s":"F",  "c":"CONTROL",  "id":20575,   "ctx":"main","msg":"Error creating service context","attr":{"error":"Location5579201: Unable to acquire security key[s]"}}

Para explicar melhor minha tentativa, criei um arquivo-chave chamado keyfile e usei o scp para copiá-lo no 3º PC no caminho: /etc/mongodb/keyfile, o arquivo-chave agora tem permissão 644. Como faço para corrigir esse erro Não foi possível adquirir a chave de segurança e o que isso significa?

Na minha máquina recentemente configurada, eu uso ZFS no Linux Mint (LMDE 6) para criar pools de armazenamento e usar o sistema de arquivos ZFS. A configuração de armazenamento específica é quatro HDDs de 1 TB organizados em topologia RAID-Z2. O próprio sistema operacional foi instalado em uma partição ext4 em uma unidade SSD separada, enquanto o particionamento foi feito pelo instalador. Eu movi o diretório \home para o pool ZFS por

• copiando seu conteúdo para um conjunto de dados chamado zpool\home
• removendo o diretório \home original no sistema de arquivos raiz
• criando um ponto de montagem para o conjunto de dados no sistema de arquivos raiz porzfs set mountpoint="\home" zpool\home

Mover o diretório \home para o zpool funcionou sem problemas.

Agora estou estruturando os sistemas de arquivos, por exemplo, criando conjuntos de dados, configurando a compactação, instantâneos etc. Quando se trata de pontos de montagem, está claro para mim que qualquer conjunto de dados e seus filhos podem ser montados em qualquer lugar no sistema de arquivos Linux. Minha pergunta é se pode surgir algum problema ao tentar montar conjuntos de dados em locais no novo diretório \home. Por exemplo, como com: zfs create zpool\very-important-documents zfs set mountpoint="\home\user\very-important-documents" zpool\very-important-documents

É considerado uma prática ruim definir pontos de montagem de conjuntos de dados para locais em diretórios que estão localizados dentro de conjuntos de dados? Se sim, quais são os problemas específicos que podem surgir? Seria melhor definir os pontos de montagem no sistema de arquivos raiz diretamente?

Usando o Synology DSM 7.2.2-72806 Update 2, Docker Container Manager 20.10.23, com a imagem oficial do Nginx instalada e em execução, acessando o servidor via SSH, descobri que nano/apt/git não estão presentes.

É possível construir uma nova imagem de servidor nginx que inclua nano, git e apt? Se sim, como?

Nginx versão 1.27.3 com bookworm

Acho que um sistema docker com nginx + ssl + nodered + grafana + mosquitto + influxdb é bastante comum. Espero que isso ajude outros.

Tenho o nginx e o ssl (certbot) funcionando perfeitamente, e se eu for para http://example.com:1880 ou http://example.com:1880/ui ou http://example.com:3000 consigo acessar perfeitamente os fluxos nodered, ui e grafana.

Mas eu preciso de "mais".

Quero ter "subpastas" como esta:

1. grafana irá para example.com/grafana
2. A edição do fluxo nodered deve ir para example.com/nodered
3. a interface do usuário nodered (painel ou flowfuse, tanto faz) deve ir para example.com

Tentei centenas de configurações editando docker-compose.yml, nginx.conf, settings.js e grafana.ini, mas... sem sorte.

Espero que alguém possa ter algo semelhante e compartilhar conosco seus arquivos de configuração.

Estas são as minhas neste momento (eu apaguei minhas "tentativas de configuração erradas")

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    location /.well-known/acme-challenge {
        allow all;
        root /var/www/certbot;
    }
    location / {
#        rewrite ^ https://$host$request_uri? permanent;
        return 301 https://$server_name$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    #STATIC index index.php index.html index.htm;
    #STATIC root /var/www/html;

    server_tokens off; #Disable the Nginx version in headers for security       

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

#linuxserver.io
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
    ssl_session_tickets off;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    # Logs for Nginx access and errors
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location ~ /\.ht { deny all; }

    location = /favicon.ico { log_not_found off; access_log off; }
    location = /robots.txt { log_not_found off; access_log off; allow all; }
    location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ { expires max; log_not_found off; }    
}

Docker-compose.yml

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    ports:
      - "1883:1883"
      #- "8883:8883"
      #- "9001:9001" # Websocket opcional
    volumes:
      - ./mosquitto-data:/mosquitto
    restart: unless-stopped
    #environment:
    #  - 'TZ='Europe/Brussels'

  influxdb:
    image: influxdb:2.7
    container_name: influxdb
    ports:
      - "8086:8086"
    volumes:
      - ./influxdb-data:/var/lib/influxdb2
      - ./influxdb-config:/etc/influxdb2
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=user
      - DOCKER_INFLUXDB_INIT_PASSWORD=password
      - DOCKER_INFLUXDB_INIT_ORG=org
      - DOCKER_INFLUXDB_INIT_BUCKET=buck
      - DOCKER_INFLUXDB_INIT_RETENTION=0
    restart: unless-stopped

  grafana:
    image: grafana/grafana:11.4.0
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - ./grafana-data:/var/lib/grafana
      - ./grafana-config:/etc/grafana
    #user: "0"
    environment:
      - GF_SECURITY_ADMIN_USER=user
      - GF_SECURITY_ADMIN_PASSWORD=password
      #- GF_SERVER_ROOT_URL=https://example.com/grafana
      #- GF_SERVER_DOMAIN=https://example.com/
      #- GF_INSTALL_PLUGINS 
    restart: unless-stopped

  nodered:
    image: nodered/node-red:4.0
    container_name: nodered
    ports:
      - "1880:1880"
    volumes:
      - ./nodered-data:/data
    restart: unless-stopped

  nginx:
    image: nginx:1.27.3-bookworm
    container_name: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx-data:/etc/nginx/conf.d
      - ./nginx-logs:/var/log/nginx
      - ./letsencrypt-data:/etc/letsencrypt
      - ./certbot-data:/var/www/certbot
    depends_on:
      - nodered
      - grafana
      - influxdb
    restart: unless-stopped

  certbot:
    image: certbot/certbot
    container_name: certbot
    depends_on:
      - nginx
    volumes:
      - ./letsencrypt-data:/etc/letsencrypt
      - ./certbot-data:/var/www/certbot
    #restart: unless-stopped
#    command: certonly --webroot --webroot-path=/var/www/certbot/ --email [email protected] --agree-tos --no-eff-email --staging -d example.com
    #command: certonly --webroot --webroot-path=/var/www/certbot/ --email [email protected] --agree-tos --no-eff-email --force-renewal -d example.com

volumes:
  mosquitto-data:
  influxdb-data:
  influxdb-config:
  grafana-data:
  grafana-config:
  nodered-data:
  letsencrypt-data:
  nginx-data:
  certbot-data:

O que preciso alterar/adicionar a esses arquivos?:

1. nodered: docker-compose, nginx e settings.js
2. grafana: docker-compose, nginx e grafana.ini

Muito obrigado.

2025/01/15 19:00 (UTC): Comecei com o grafana para ir passo a passo (acho que é mais fácil) Mudei o docker-compose para:

  grafana:
    image: grafana/grafana:11.4.0
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - ./grafana-data:/var/lib/grafana
      - ./grafana-config:/etc/grafana
    #user: "0"
    environment:
      - GF_SECURITY_ADMIN_USER=user
      - GF_SECURITY_ADMIN_PASSWORD=password
      - GF_SERVER_ROOT_URL=https://example.com/grafana/
      - GF_SERVER_DOMAIN=https://example.com/
      - GF_SERVER_SERVER_FORM_SUB_PATH=true
    restart: unless-stopped

E nginx.conf:

    # Grafana Dashboard
    location /grafana/ {
        proxy_set_header Host $host;
        proxy_pass http://grafana:3000/;
    }

    # Proxy Grafana Live WebSocket connections.
    location /grafana/api/live/ {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_pass http://grafana:3000/;
    }

Não alterei o grafana.ini porque encontrei uma maneira melhor de usar variáveis ​​de ambiente no docker-compose.

Estou entendendo "alguma coisa", pelo menos, "grafana" está respondendo:

If you're seeing this Grafana has failed to load its application files
This could be caused by your reverse proxy settings.
If you host grafana under a subpath make sure your grafana.ini root_url setting includes subpath. If not using a reverse proxy make sure to set serve_from_sub_path to true.
If you have a local dev build make sure you build frontend using: yarn start, or yarn build.
Sometimes restarting grafana-server can help.
Check if you are using a non-supported browser. For more information, refer to the list of supported browsers .

Então ainda não consigo fazê-lo funcionar.

2025/01/15 20:30 (UTC): Aqui estou testando o nodered, a configuração de "proxy" mais simples.

Adicionei isso em nginx.conf

    location / {
        proxy_pass http://nodered:1880/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
#        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#        proxy_set_header X-Forwarded-Proto $scheme;

#        # WebSocket support
        proxy_http_version 1.1;
#        proxy_cache_bypass  $http_upgrade;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        rewrite ^/(.*) /$1 break;
    }

Eu tentei várias tentativas comentando e descomentando cada linha (cada tentativa === uma linha comentada ou descomentada)

Novamente resultado parcial. Posso ver que o nodered está respondendo, mas com uma página em branco, pois várias páginas estáticas não estão carregando.

Estes são alguns dos erros que posso ver no console:

Failed to load resource: the server responded with a status of 404 ()Understand this errorAI
example.com/:1 Refused to execute script from 'https://example.com/vendor/vendor.js?v=3305aad6c0c6' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.Understand this errorAI
monaco-bootstrap.js:1 
        
Failed to load resource: the server responded with a status of 404 ()Understand this errorAI
red.min.js:1 
Failed to load resource: the server responded with a status of 404 ()Understand this errorAI
main.min.js:1 

Então, novamente, estou me sentindo estúpido sobre isso. Provavelmente isso também é fácil de resolver, eu tentei todas as coisas que encontrei pesquisando no Google e usando chatgpt (por exemplo)

Mais uma vez obrigado pela sua ajuda.

2025/01/18 9:00 (UTC):

Continuo tentando coisas diferentes. Desta vez a configuração mais simples do grafana apenas para testar as configurações docker-compose e nginx. Sem sorte de novo.

    # Grafana Dashboard
    location / {
        proxy_set_header Host $host;
        proxy_pass http://grafana:3000/;
    }

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - ./grafana-data:/var/lib/grafana
      - ./grafana-config:/etc/grafana
    #user: "0"
    environment:
      - GF_SECURITY_ADMIN_USER=user
      - GF_SECURITY_ADMIN_PASSWORD=password

E grafana.ini NÃO foi modificado do arquivo padrão.

Consigo ver a página web do Grafana com erro e, no console, na aba de rede, consigo ver que o Chrome não carrega arquivos CSS e JS.

https://example.com/public/build/grafana.dark.722d809dba5a31f57d49.css

Verifiquei que dentro do contêiner grafana esse arquivo existe, então não sei por que o nginx não está redirecionando ou encontrando esse arquivo.

Mas, este arquivo foi encontrado: https://example.com/public/img/grafana_icon.svg

Então há algum problema no arquivo de configuração do nginx com arquivos js, css, ..., não é?

Se eu for (testar) em http://example.com:3000 os arquivos são carregados corretamente: http://example.com:3000/public/build/grafana.dark.722d809dba5a31f57d49.css

Então...alguma solução?

(só por precaução, o arquivo nginx.conf que estou usando para este teste "simples":)

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    location /.well-known/acme-challenge {
        allow all;
        root /var/www/certbot;
    }
    location / {
        rewrite ^ https://$host$request_uri? permanent;
#        return 301 https://$server_name$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    server_tokens off; #Disable the Nginx version in headers for security       

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
    ssl_session_tickets off;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    # Grafana Dashboard
    location / {
        proxy_set_header Host $host;
        proxy_pass http://grafana:3000/;
    }

    # Logs for Nginx access and errors
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location ~ /\.ht { deny all; }

    location = /favicon.ico { log_not_found off; access_log off; }
    location = /robots.txt { log_not_found off; access_log off; allow all; }
    location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ { expires max; log_not_found off; }    
}

Não tenho iotop, atop ou qualquer ferramenta que não seja Redhat no Redhat 7.9.

Existe uma maneira de investigar qual processo está consumindo todo o acesso ao disco rígido?

Não tenho o gnome instalado, então não tenho acesso à ferramenta monitor disponível com o gnome. Estou usando apenas o ssh e a ferramenta de linha de comando.

Usando o SAR, detectei que o SDA do disco rígido está 99% ocupado, mas não sei o porquê.

Estou tentando configurar a replicação entre dois servidores mysql 5.7. Consigo conectar à fonte a partir da réplica, mas quando tento iniciar a replicação, a réplica falha ao conectar à fonte. O que pode causar isso

Isso abre com sucesso um cliente mysql conectado à fonte:

# On replica
$ mysql -u [my_user] -p -h [source_host] \
    --ssl-mode=REQUIRED \
    --ssl-ca=/etc/[source_host].cabundle

Status da fonte:

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.002513 | 45687316 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Na réplica:

mysql> CHANGE MASTER TO
    -> MASTER_HOST='[source_host]',
    -> MASTER_USER='[my_user]',
    -> MASTER_PASSWORD='[my_password]',
    -> MASTER_LOG_FILE='mysql-bin.002495',
    -> MASTER_LOG_POS=154,
    -> MASTER_SSL=1,
    -> MASTER_SSL_VERIFY_SERVER_CERT=0,
    -> MASTER_SSL_CA='/etc/ssl/[source_host].cabundle'
    -> ;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

Status da réplica:

mysql> show slave stauts \G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Master_Host: [source_host]
                  Master_User: [my_user]
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.002495
          Read_Master_Log_Pos: 154
               Relay_Log_File: [hostname]-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.002495
             Slave_IO_Running: Connecting
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: /etc/ssl/[source_host].cabundle
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 2026
                Last_IO_Error: error connecting to master '[my_user]@[source_host]:3306' - retry-time: 60  retries: 
4
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
                  Master_UUID: 
             Master_Info_File: [mysql_dir]/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 250115 03:03:38
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:

mysql error.log na réplica:

[Note] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='[source_host]', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='[source_host]', master_port= 3306, master_log_file='mysql-bin.002495', master_log_pos= 154, master_bind=''.
[Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
[Note] Slave SQL thread for channel '' initialized, starting replication in log 'mysql-bin.002495' at position 154, relay log './analysis-relay-bin.000001' position: 4
[ERROR] Slave I/O for channel '': error connecting to master '[my_user]@[source_host]:3306' - retry-time: 60  retries: 1, Error_code: 2026

mysql error.log na fonte:

[Note] Bad handshake

Peço desculpas se esta pergunta fugir do assunto; estou tentando solucionar algo que foge da minha área de especialização.

Recentemente, migrei um aplicativo da web interno para o IIS. Também habilitei a Autenticação do Windows (IWA), que eu não estava usando antes. O problema que estou vendo é que minha conta de usuário (e, evidentemente, apenas minha conta de usuário) às vezes (não em todos os lugares) é identificada incorretamente pelo processo de autenticação.

Aqui estão os detalhes da configuração de autenticação do IIS para meu site:

• Tenho a Autenticação do Windows habilitada e todo o resto (incluindo a Autenticação Anônima) desabilitado.
• A autenticação do Windows está usando a autenticação no modo Kernel e o Negotiateprovedor.

Em relação à identificação errônea a que aludi:

• Tenho duas contas de usuário no mesmo domínio do AD. Chamo-as ​​de acct1e acct2. Normalmente, entro como acct1, alternando para acct2quando preciso de privilégios elevados.
• Fiz login na VM que está executando o IIS acct2para configurar o site.
• Quando volto ao meu PC local para acessar o site, o site me identifica como acct2, mesmo que eu esteja conectado ao meu PC como acct1.
• Todos os outros que acessaram o site foram devidamente identificados, mesmo aqueles que têm mais de uma conta, como eu.
• Se eu acessar o site de um PC diferente enquanto estiver conectado como acct1, serei identificado corretamente pelo site como acct1.
• Perversamente, se eu acessar o site da própria máquina do servidor, onde estou logado como acct2, ele me identifica como acct1.
• Pelo que vale, acct2ele tem privilégios de administrador no meu PC local, mas não no outro PC de onde acessei o site.
• Isso vem acontecendo há mais de uma semana e persiste mesmo depois de reiniciar meu PC local. Também acontece em diferentes navegadores.

Se eu mudar o provedor IWA de Negotiatepara NTLM, aqui está o que vejo:

• Sou devidamente identificado acct1quando acesso o site do meu PC local.
• Sou solicitado a inserir credenciais quando acesso o site da máquina do servidor web. No entanto, ele não aceita credenciais para acct1ou acct2.

Não estou muito preocupado em acessar o site do servidor, mas preciso ser identificado corretamente ao acessá-lo do meu PC. Gostaria de usar Negotiateem vez de NTLM.

Sou um desenvolvedor e não um administrador de sistema, mas estou tentando encontrar pistas que possam me ajudar a restringir o que está acontecendo e potencialmente apontar nossa equipe de infraestrutura na direção certa. Isso parece um problema de configuração do Active Directory ou do Kerberos?

O site é um aplicativo Python Flask rodando como um aplicativo FastCGI no IIS por meio da wfastcgibiblioteca Python. O site lê o valor da REMOTE_USERvariável request para obter o resultado do processo de autenticação IWA.

Eu instalei o Samba 4 como um controlador de domínio + servidor de arquivos. Eu forneci acesso às pastas via Samba. Agora, quando tento alterar permissões em pastas e arquivos do Windows Explorer, preciso encontrar um usuário para adicionar à lista. Mas o sistema não consegue encontrar o usuário por um motivo desconhecido para mim. Eu tentei "EXAMPLE\user1", "EXAMPLE.COM\user1", " [email protected] " - ele ainda não pesquisa. Se eu clicar no botão Avançado na janela de seleção de objetos (para definir permissões na guia Segurança nas propriedades do arquivo), o Windows informará "O servidor está inativo". No entanto, a lista de usuários e suas permissões (anteriormente definidas diretamente no servidor) é exibida perfeitamente, indicando o domínio e os nomes. O que fazer?