All perguntas(server)

Depois de muitas tentativas, consegui reiniciar um banco de dados muito corrompido adicionando innodb_force_recovery = 6 ao meu.ini

No entanto, agora, não consigo iniciar o servidor de forma alguma, a menos que essa linha esteja permanentemente no arquivo ini. Isso não parece certo.

Há algo que eu deva fazer depois de recuperar um banco de dados dessa maneira, além de fazer backup e restaurar em um novo?

Meu objetivo é obter login SSH 2FA (senha + OTP) quando conectado de fora da minha rede local, enquanto uso login SSH "somente senha" da rede local (192.168.1.0/24).

Atualmente tenho o primeiro bit (senha + OTP) funcionando com a seguinte configuração:

Meu /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes

Meu /etc/pam.d/sshd:

#@include common-auth
auth    required     pam_unix.so nullok_secure
auth    required     pam_oath.so usersfile=/etc/users.oath window=30 digits=6

Como obter o segundo bit (somente senha, sem OTP) da rede local?

Desde já, obrigado!

Temos um volume XFS montado no RHEL9.5 (5.14.0-503.22.1.el9_5.x86_64) com apenas 88K arquivos:

$ find /mnt -type f | wc -l
87739

O sistema de arquivos relata ~200 GB de espaço livre. No entanto, o total - real usado dá ~4 TB.

$ df /mnt
Filesystem        1K-blocks         Used Available Use% Mounted on
/dev/sda1      558602657792 558397210232 205447560 100% /mnt

$ du -s /mnt
554502450484    /mnt

A diferença entre o tamanho total do sistema de arquivos e a soma dos tamanhos dos arquivos

558602657792 - 554502450484
4100207308

Onde está o espaço perdido e como podemos recuperá-lo? Conforme sugerido por outras respostas, tentamos xfs_fsr e xfs_repair , mas nada mudou.

Tenho um Docker Swarm com vários serviços em execução. Adicionei um serviço OSE syslog-ng usando https://github.com/linuxserver/docker-syslog-ng . A pilha syslog-ng tem o seguinte docker-compose.yml:

---
services:
  syslog:
    image: registry.local.net/syslog-ng:latest
    ports:
      - 514:514
    volumes:
      - /path/on/host/syslog-ng/config:/config
      - /path/on/host/log:/log
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - LOG_TO_STDOUT=1
#    healthcheck:
#      test: ["CMD-SHELL", "/usr/sbin/syslog-ng-ctl healthcheck -c /config/syslog-ng.ctl || exit 1"]
#      interval: 10s
#      timeout: 2s
#      retries: 3
    deploy:
      mode: replicated
      replicas: 1
      restart_policy:
        condition: on-failure
      update_config:
        parallelism: 1
        delay: 10s
    networks:
      syslog:

networks:
  syslog:
    external: true

e meu arquivo syslog-ng.conf é este:

@version: 4.2
@include "scl.conf"

options {
     chain_hostnames(no);
     flush_lines(0);
     use_dns(no);
     time_reopen(1);
};

source net {
    tcp(ip(0.0.0.0) port(514));
};

template my_log_format {
    template("$MSG\n");
};

filter f_access_log { program("httpd.access") };

destination d_logs {
    file(
        "/log/TEST"
        owner("1000")
        group("1000")
        perm(0664)
        template(my_log_format)
        );
};

log {
    source(net); filter(f_access_log); destination(d_logs);
};

Configurei um serviço Apache no Docker Swarm para enviar seus logs para o serviço syslog-ng usando logger -T -t httpd.accept -n syslog -P 514 --rfc3164.

O Syslog-ng cria o arquivo de log configurado, recebe as linhas de log do Apache e as anexa ao arquivo de log configurado regularmente. Tudo parece estar funcionando do jeito que eu quero. O único problema é que o contêiner Docker syslog-ng continua saindo e reiniciando a cada 70-80 segundos. Tentei adicionar uma verificação de integridade (comentada acima), mas não mudou nada. A inspeção dos contêineres encerrados mostra que todas as verificações de integridade passam até o contêiner sair com o código de saída 137, e o log do Docker dos contêineres encerrados não exibe nada obviamente errado.

O arquivo de log atual do syslog-ng mostra o seguinte (menos os registros de data e hora no início de cada linha):

Accepting connections; addr='AF_INET(0.0.0.0:514)'
syslog-ng starting up; version='4.8.1'
Syslog connection accepted; fd='14', client='AF_INET(10.0.6.244:37126)', local='AF_INET(0.0.0.0:514)'

Segundos antes de um dos contêineres sair, topdentro do contêiner estava escrito o seguinte:

top - 08:31:26 up 169 days, 17:44,  0 user,  load average: 1.13, 1.05, 1.05
Tasks:  15 total,   1 running,  14 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.8 us,  1.8 sy,  0.0 ni, 73.9 id,  0.0 wa,  0.2 hi,  0.2 si,  0.0 st 
MiB Mem :   7652.9 total,    405.8 free,   2924.0 used,   4968.6 buff/cache     
MiB Swap:   8192.0 total,   7883.4 free,    308.6 used.   4728.9 avail Mem 

EDIT: Achei que tinha encontrado uma solução adicionando

    time-reap(30);
    mark-freq(10);

para as opções globais do syslog-ng. O contêiner Docker ficou ativo por quase 5 minutos depois que eu fiz essa alteração inicialmente, mas agora ele voltou a sair e reiniciar a cada minuto ou mais, mesmo com essas opções.

Temos um banco de dados de modelo com esquemas, tabelas, sequências etc. Criamos um novo banco de dados a partir dele e fornecemos a propriedade do novo banco de dados a um usuário (um novo usuário criado como parte deste fluxo de trabalho). O novo usuário ainda não tem os privilégios para selecionar dados de tabelas existentes. Qual é a melhor maneira de lidar com isso? A versão PG é 16.3. O novo usuário não precisa obter nenhum privilégio em nenhum banco de dados além do novo criado, mas deve ter os privilégios para fazer praticamente qualquer coisa no novo banco de dados.

Mysql 8.0.41 no Windows (mas isso se aplica também a versões anteriores, pelo menos todas as versões 8.x)

Posso parar e reiniciar o serviço do gerenciador de tarefas/serviços quantas vezes eu quiser, sem problemas.

Entretanto, assim que faço uma alteração no my.ini, o mysqld começa a parar com:

2025-02-05T09:01:07.459474Z 0 [System] [MY-010116] [Server] C:\db\mysql\bin\mysqld.exe (mysqld 8.0.41) starting as process 4628
2025-02-05T09:01:07.462226Z 0 [Warning] [MY-010091] [Server] Can't create test file C:\db\mysql\data\mysqld_tmp_file_case_insensitive_test.lower-test
2025-02-05T09:01:07.462284Z 0 [Warning] [MY-010091] [Server] Can't create test file C:\db\mysql\data\mysqld_tmp_file_case_insensitive_test.lower-test
2025-02-05T09:01:07.474391Z 0 [ERROR] [MY-013276] [Server] Failed to set datadir to 'C:\db\mysql\data\' (OS errno: 2 - No such file or directory)
2025-02-05T09:01:07.521215Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-02-05T09:01:07.521381Z 0 [System] [MY-010910] [Server] C:\db\mysql\bin\mysqld.exe: Shutdown complete (mysqld 8.0.41)  MySQL Community Server - GPL.

Observe que:

1. Eu não toquei no datadir de forma alguma. Nem no arquivo ini, nem no próprio datadir
2. Eu só alterei o sqlmode no meu.ini
3. Apaguei a alteração e restaurei meu.ini como estava antes de editá-lo

No entanto, não importa o que aconteça, o mysqld continua não iniciando, com o(s) erro(s) acima. Somente desinstalar e reinstalar do zero resolve o problema.

Alguém já passou por esse problema e conhece uma solução alternativa?

Tenho um servidor Windows (2022) com dois SSDs Samsung 990 Pro de 2 TB. Tive alguns problemas estranhos com um deles desaparecendo de vez em quando. O que acontece é que a cada 2 meses ou mais, o disco em questão não existe mais: diskpartou Get-PhysicalDisk(no PS) simplesmente não lista mais o disco. A única coisa a fazer naquele momento é um desligamento completo e reinicialização, uma simples reinicialização no SO não é suficiente.

No começo, pensei que fosse um problema com a placa-mãe, então entrei em contato com o fabricante e -surpresa!- eles me disseram para ter certeza de que não era um problema com o disco. Depois de algumas idas e vindas, decidi explorar um possível problema com os discos, simplesmente para evitar o incômodo de substituir a placa-mãe e ainda ter o problema.

Examinar a situação dos discos não foi tão fácil, porque esta é uma instalação Server Core, então sem GUI, mas eu consegui fazer algumas análises, que revelaram um choque: rodar o diskspd da MS mostrou um desempenho completamente abismal para ambos os discos . Tanto a leitura quanto a gravação estão um pouco abaixo de 50 MiB/s, o que é bem menor do que as especificações do 990 Pro.

Então agora tenho algumas perguntas:

• Os dois problemas (disco desaparecendo de tempos em tempos) estão relacionados?
• O problema de velocidade pode ser causado pela placa-mãe (é uma ASRock X570S PG Riptide)?
• Poderia ser que os SSDs sejam falsificados? E como posso verificar isso?
• Alguma sugestão para analisar isso melhor?

Esclarecimento:

• Logs do servidor: nada aparece no visualizador de eventos
• Idade das unidades: elas têm um ano e não foram usadas intensivamente
• Leituras inteligentes: Esta é a saída que obtive do Samsung DC Toolkit:

Número do disco: 1:c | Nome do modelo: Samsung SSD 990 PRO com dissipador de calor de 2 TB | Versão do firmware: 0B2QJXG7

Estou entrando em contato para pedir ajuda em relação a um problema de estabilidade que encontramos após atualizar nosso cluster Ceph da versão Pacific 16.2.3 para Quincy 17.2.8.

Após a atualização, observamos que vários dos nossos Object Storage Daemons (OSDs) estão apresentando comportamento errático. Esses OSDs frequentemente exibem uma condição de "oscilação", onde eles inesperadamente caem e depois voltam a subir. Esse problema afetou predominantemente os OSDs recentemente atualizados dentro do cluster.

Ao revisar os logs dos OSDs afetados, encontramos as seguintes mensagens:

2025-02-03T08:34:09.769+0000 7f0f11390780 -1 bluestore::NCB::__restore_allocator::Failed open_for_read with error-code -2
2025-02-03T08:38:22.920+0000 7feb9dd44780 -1 bluestore::NCB::__restore_allocator::No Valid allocation info on disk (empty file)

Em uma tentativa de resolver o problema, executamos os comandos ceph-bluestore-tool fsck e repair. Embora esses comandos tenham sido executados com sucesso, eles não corrigiram o problema em questão.

Além disso, capturamos as seguintes informações de falha dos logs do ceph:

ceph crash info 2025-02-03T09:19:08.749233Z_9e2800fb-77f6-46cb-8087-203ea15a2039
{
   "assert_condition": "log.t.seq == log.seq_live",
   "assert_file": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos9/DIST/centos9/MACHINE_SIZE/gigantic/release/17.2.8/rpm/el9/BUILD/c
eph-17.2.8/src/os/bluestore/BlueFS.cc",
   "assert_func": "uint64_t BlueFS::_log_advance_seq()",
   "assert_line": 3029,
   "assert_msg": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos9/DIST/centos9/MACHINE_SIZE/gigantic/release/17.2.8/rpm/el9/BUILD/ce
ph-17.2.8/src/os/bluestore/BlueFS.cc: In function 'uint64_t BlueFS::_log_advance_seq()' thread 7ff983564640 time 2025-02-03T09:19:08.738781+0000\n/home/jenkins-build/build/workspace/ceph-bu
ild/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos9/DIST/centos9/MACHINE_SIZE/gigantic/release/17.2.8/rpm/el9/BUILD/ceph-17.2.8/src/os/bluestore/BlueFS.cc: 3029: FAILED ceph_assert
(log.t.seq == log.seq_live)\n",
   "assert_thread_name": "bstore_kv_sync",
   "backtrace": [
       "/lib64/libc.so.6(+0x3e730) [0x7ff9930f5730]",
       "/lib64/libc.so.6(+0x8bbdc) [0x7ff993142bdc]",
       "raise()",
       "abort()",
       "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x179) [0x55882dfb7fdd]",
       "/usr/bin/ceph-osd(+0x36b13e) [0x55882dfb813e]",
       "/usr/bin/ceph-osd(+0x9cff3b) [0x55882e61cf3b]",
       "(BlueFS::_flush_and_sync_log_jump_D(unsigned long)+0x4e) [0x55882e6291ee]",
       "(BlueFS::_compact_log_async_LD_LNF_D()+0x59b) [0x55882e62e8fb]",
       "/usr/bin/ceph-osd(+0x9f2b15) [0x55882e63fb15]",
       "(BlueFS::fsync(BlueFS::FileWriter*)+0x1b9) [0x55882e631989]",
       "/usr/bin/ceph-osd(+0x9f4889) [0x55882e641889]",
       "/usr/bin/ceph-osd(+0xd74cd5) [0x55882e9c1cd5]",
       "(rocksdb::WritableFileWriter::SyncInternal(bool)+0x483) [0x55882eade393]",
       "(rocksdb::WritableFileWriter::Sync(bool)+0x120) [0x55882eae0b60]",
       "(rocksdb::DBImpl::WriteToWAL(rocksdb::WriteThread::WriteGroup const&, rocksdb::log::Writer*, unsigned long*, bool, bool, unsigned long)+0x337) [0x55882ea00ab7]",
       "(rocksdb::DBImpl::WriteImpl(rocksdb::WriteOptions const&, rocksdb::WriteBatch*, rocksdb::WriteCallback*, unsigned long*, unsigned long, bool, unsigned long*, unsigned long, rocksdb
::PreReleaseCallback*)+0x1935) [0x55882ea07675]",
       "(rocksdb::DBImpl::Write(rocksdb::WriteOptions const&, rocksdb::WriteBatch*)+0x35) [0x55882ea077c5]",
       "(RocksDBStore::submit_common(rocksdb::WriteOptions&, std::shared_ptr<KeyValueDB::TransactionImpl>)+0x83) [0x55882e992593]",
       "(RocksDBStore::submit_transaction_sync(std::shared_ptr<KeyValueDB::TransactionImpl>)+0x99) [0x55882e992ee9]",
       "(BlueStore::_kv_sync_thread()+0xf64) [0x55882e578e24]",
       "/usr/bin/ceph-osd(+0x8afb81) [0x55882e4fcb81]",
       "/lib64/libc.so.6(+0x89e92) [0x7ff993140e92]",
       "/lib64/libc.so.6(+0x10ef20) [0x7ff9931c5f20]"
   ],
   "ceph_version": "17.2.8",
   "crash_id": "2025-02-03T09:19:08.749233Z_9e2800fb-77f6-46cb-8087-203ea15a2039",
   "entity_name": "osd.211",
   "os_id": "centos",
   "os_name": "CentOS Stream",
   "os_version": "9",
   "os_version_id": "9",
   "process_name": "ceph-osd",
   "stack_sig": "ba90de24e2beba9c6a75249a4cce7c533987ca5127cfba5b835a3456174d6080",
   "timestamp": "2025-02-03T09:19:08.749233Z",
   "utsname_hostname": "afra-osd18",
   "utsname_machine": "x86_64",
   "utsname_release": "5.15.0-119-generic",
   "utsname_sysname": "Linux",
   "utsname_version": "#129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024"
}

Os logs de travamento acima destacam uma falha de asserção no componente BlueFS, especificamente dentro da função BlueFS::_log_advance_seq(). Apesar de nossos esforços para analisar e resolver o problema, chegamos a um impasse.

Para completar, verificamos a integridade dos nossos discos usando smartctl, e todos eles foram considerados saudáveis.

Solicitamos gentilmente orientação da comunidade sobre como abordar esse problema ou quaisquer etapas recomendadas para diagnósticos mais profundos. Agradecemos seu suporte e experiência durante esse processo de solução de problemas.

Obrigado pela sua atenção e assistência.

arquivo de log osd: https://paste.mozilla.org/6STm6eum

Tenho um proxy reverso baseado em caminho traefik bastante simples e queria saber se é possível redirecionar o usuário para um caminho diferente, em vez de middlewares influenciarem a solicitação do proxy .

Sei que posso simplesmente especificar o caminho raiz para rotear para o serviço desejado, mas isso atrapalha o tratamento desse serviço de estar por trás do proxy (não é possível carregar nenhuma imagem de página/recurso).

Olhando os documentos, não há nada óbvio que não seja uma ferramenta de middleware para alterar a url de um usuário. Existe uma maneira de redirecionar um usuário para um caminho diferente com base em outro?

Minha configuração atual:

tls:
  stores:
    default:
      defaultCertificate:
        certFile: /etc/traefik/certs/publicCert.crt
        keyFile: /etc/traefik/certs/privateKey.pem
  certificates:
    - certFile: /etc/traefik/certs/publicCert.crt
      keyFile: /etc/traefik/certs/privateKey.pem
      stores:
        - default
http:
  # https://doc.traefik.io/traefik/routing/services/
  services:
    core-depot:
      loadBalancer:
        serversTransport: oqmInternalTransport
        servers:
          - url: https://oqm-core-depot:443
            preservePath: true
    core-api:
      loadBalancer:
        serversTransport: oqmInternalTransport
        servers:
          - url: https://oqm-core-api:443
            preservePath: true
    infra-keycloak:
      loadBalancer:
        serversTransport: oqmInternalTransport
        servers:
          - url: https://oqm-infra-keycloak:443
    core-base-station:
      loadBalancer:
        serversTransport: oqmInternalTransport
        servers:
          - url: http://oqm-core-base_station:80
            preservePath: true
  # https://doc.traefik.io/traefik/routing/services/#serverstransport_1
  serversTransports:
    oqmInternalTransport:
      rootCAs:
        - /etc/traefik/certs/rootCert.crt
  # https://doc.traefik.io/traefik/routing/routers/
  routers:
    defaultRoute:
      service: core-depot
      rule: "Path(`/`)"
    core-depot-router:
      rule: "PathPrefix(`/core/depot`)"
      service: core-depot
      middlewares:
        - strip-oqm-prefixes
    core-api-router:
      rule: "PathPrefix(`/core/api`)"
      service: core-api
      middlewares:
        - strip-oqm-prefixes
    infra-keycloak-router:
      rule: "PathPrefix(`/infra/keycloak`)"
      service: infra-keycloak
      middlewares:
    core-base-station-router:
      rule: "PathPrefix(`/core/base-station`)"
      service: core-base-station
      middlewares:
        - strip-oqm-prefixes
  middlewares:
    strip-oqm-prefixes:
      stripprefix:
        prefixes:
          - /core/depot
          - /core/api
          - /core/base-station

Estou usando o Windows Server na AWS e preciso abrir várias portas para o servidor REST, depurador remoto e assim por diante. Eu os configurei nos três lugares que conheço:

• Firewall do Windows
• Grupo de Segurança AWS
• Regras de entrada do AWS Lightsail

Eu configurei as portas em todos os três, mas elas ainda não estão abertas. O que eu posso ter esquecido ou feito errado?

Ainda não tenho certeza se preciso do Security Group e do Lightsail Inbound Rules. Espero que eles não estejam interagindo entre si.

DESCANSAR

Eu consegui fazer o REST Server funcionar. Tolamente, pensei que definir a regra de entrada no Windows, vinculada a um aplicativo, seria mais seguro. Mas não funciona.

DEPURADOR

Não consigo fazer o depurador remoto Delphi (PAServer) funcionar. Ele precisa da porta 64211. O que eu errei ou esqueci.

Regra de entrada do Lightsail (vinculada ao meu endereço IP)

Grupo de segurança (vinculado ao meu endereço IP)

Firewall do Windows

Erro no cliente no Delphi IDE, configurando o Connection Profile Manager

A conexão com 'host-name' na porta 64211 falhou. Certifique-se de que 'Platform AssistantServer' esteja em execução na máquina host e esteja configurado para usar a porta 64211

Eu tentei tanto 'static-ip' quanto 'host-name'. O hostname funciona para o servidor REST e o site. O servidor está em execução e usando esta porta. Eu testei sem senha em ambas as pontas, e com uma senha em ambas as pontas.

Para mostrar que o lado do servidor está em execução

Servidor do Platform Assistant Versão 14.2.14.0
Copyright (c) 2009-2024 Embarcadero Technologies, Inc.

Senha do perfil de conexão:

Iniciando o servidor do Platform Assistant na porta 64211