All perguntas(server)

Estou tentando configurar meu servidor dovecot para acessar a solicitação curl pela LAN seguindo https://doc.dovecot.org/2.3/admin_manual/doveadm_http_api/#admin-doveadm-http-api

Meu sistema operacional é: Rocky 9 Linux e a versão do Dovecot é: 2.3.16

em /etc/dovecot/conf.d/ meu mail-location definido como:

mail_location = maildir:/home/vmail/%d/%n/Maildir

e

inbox = yes

/etc/dovecot/dovecot.conf, adicionei

doveadm_password = admpass
service doveadm {
     unix_listener doveadm-server {
             user = vmail
     }
     inet_listener {
             port = 2425
     }
     inet_listener http {
             port = 8080
             #ssl = yes # uncomment to enable https
     }
}

quando eu corro

doveadm fetch -u [email protected] "text" MAILBOX INBOX UNSEEN

Consigo receber os novos e-mails corretamente.

Mas quando tento buscar e-mails usando curl.

curl -u doveadm:admpass -X POST -H "Content-Type: application/json" -d '[[ "fetch", { "mailbox": "INBOX", "user": "[email protected]"}, "tag1" ]]' http://localhost:8080/doveadm/v1

Recebo este erro:

[["error",{"type":"invalidRequest", "exitCode":0},"tag1"]]

Como posso consultar os novos e-mails dos meus usuários usando o curl a partir do host da LAN? E obter a resposta em formato JSON?

Verifiquei os logs do MySQL no Google Cloud e encontrei os seguintes logs. Isso acontece a cada 15 minutos. O que é isso? Posso ignorar? O MySQL é 8.0.31.

[Nota] [MY-000000] [Servidor] O comprimento é 0 e a política é 1

Tentei pesquisar, mas não consegui encontrar nenhuma documentação.

Estou trabalhando com o software "Wonderguard Filmora", que alguns de nossos usuários precisam, e estou encontrando um erro ao iniciar. O problema decorre da tentativa do software de executar uma detecção de atualização ao iniciar, que é executada por meio de um arquivo .tmp em USERS\User*\APPDATA\LOCAL\TEMP\IS-4CRPP.TMP\WONDERSHARE FILMORA UPDATE(X64).TMP. Esta é uma execução não assinada e, portanto, está sendo bloqueada pelo AppLocker. Agora, vejo que criar uma exceção do AppLocker para este caso é um risco à segurança, já que permitir que qualquer arquivo temporário seja executado a partir de um local é a única maneira de habilitar isso, já que o nome é diferente a cada vez.

Estou procurando uma solução de melhores práticas para resolver esse problema sem comprometer a segurança.

Estou tentando entender o processo exe no meu servidor Ubuntu

sudo ls -l /proc/6293/exe 
lrwxrwxrwx 1 jenkins 65533 0 апр  4 09:03 /proc/6293/exe -> /usr/local/bin/node

Quando procuro no lixo

/usr/local/bin# ls node
ls: cannot access 'node': No such file or directory

Para onde esse elo simbólico realmente aponta?

Eu realmente preciso de ajuda para descobrir como expandir com segurança a partição raiz na minha VM de servidor Linux. Adicionei 50 GB de espaço extra ao disco virtual da VM e consigo visualizar usando o fdisk, mas não tenho certeza de como alocá-lo sem danificar o sistema.

Aqui está meu layout de partição atual:

home-srv-01:~ #  lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0  100G  0 disk 
├─sda1   8:1    0    8M  0 part 
├─sda2   8:2    0 30.8G  0 part /var
│                               /usr/local
│                               /tmp
│                               /boot/grub2/i386-pc
│                               /boot/grub2/x86_64-efi
│                               /opt
│                               /srv
│                               /.snapshots
│                               /root
│                               /
├─sda3   8:3    0 17.2G  0 part /home
└─sda4   8:4    0    2G  0 part [SWAP]
sr0     11:0    1 15.3G  0 rom  
home-srv-01:~ #

home-srv-01:~ # fdisk -l
GPT PMBR size mismatch (104857599 != 209715199) will be corrected by write.
Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: VMware Virtual S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A1C8759F-D45C-4FB4-A365-1402AD4516B3

Device         Start       End  Sectors  Size Type
/dev/sda1       2048     18431    16384    8M BIOS boot
/dev/sda2      18432  64600063 64581632 30.8G Linux filesystem
/dev/sda3   64600064 100661247 36061184 17.2G Linux filesystem
/dev/sda4  100661248 104857566  4196319    2G Linux swap
home-srv-01:~ # 

O objetivo é expandir a partição raiz do Btrfs (sda2) para o novo espaço livre sem perder os dados em /home (sda3 XFS) ou fazer com que o sistema fique ininicializável. Infelizmente, minhas tentativas anteriores resultaram em problemas de inicialização, então estou sendo extremamente cauteloso agora.

Recapitulação das etapas:

1. Fez backup de todos os dados de /home( /dev/sda3).
2. Inicializado em um ambiente live CD/USB.
3. Dados movidos de /homepara um disco externo.
4. Executei swapoff /dev/sda4e deletei /dev/sda4.
5. Excluído /dev/sda3(isso cria espaço livre ao lado de /dev/sda2).
6. Redimensionou o sistema de arquivos Btrfs ao /dev/sda2usar btrfs filesystem resize max /.
7. Recriou /dev/sda3e restaurou os /homedados do backup.
8. Recriado /dev/sda4e executado swapon /dev/sda4.
9. Uma vez concluído, o sistema não inicializa mais.

Agradeço desde já qualquer conselho ou sugestão passo a passo. Eu realmente apreciaria sua orientação.

LX

No Ubuntu 22.04.1 (AMD 3970x, 64 GB de RAM (passou no memtest86), vários TB livres no sistema de arquivos raiz, sem erros SMART), instalei o Community MongoDB seguindo as instruções padrão aqui . Ao iniciar o MongoDB no systemd, ele falhou com as journalctl -xemensagens:

Apr 01 22:55:52 ganymede systemd[1]: Started MongoDB Database Server.
░░ Subject: A start job for unit mongod.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit mongod.service has finished successfully.
░░ 
░░ The job identifier is 9623.
Apr 01 22:55:52 ganymede sudo[427395]: pam_unix(sudo:session): session closed for user root
Apr 01 22:55:52 ganymede mongod[427399]: {"t":{"$date":"2025-04-02T05:55:52.613Z"},"s":"I",  "c":"CONTROL",  "id":7484500, "ctx":"main","msg":"Environment variable MONGODB_CONFIG_OVERRIDE_NOFORK == 1, overriding \"processManagem>
Apr 01 22:55:52 ganymede systemd[1]: mongod.service: Main process exited, code=exited, status=14/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ An ExecStart= process belonging to unit mongod.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 14.
Apr 01 22:55:52 ganymede systemd[1]: mongod.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ The unit mongod.service has entered the 'failed' state with result 'exit-code'.

Mensagens de erro mais específicas da mesma tentativa de inicialização apareceram em /var/log/mongodb/mongod.log-

{"t":{"$date":"2025-04-01T22:55:52.617-07:00"},"s":"I",  "c":"CONTROL",  "id":20698,   "ctx":"main","msg":"***** SERVER RESTARTED *****"}
{"t":{"$date":"2025-04-01T22:55:52.620-07:00"},"s":"I",  "c":"CONTROL",  "id":23285,   "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"}
{"t":{"$date":"2025-04-01T22:55:52.620-07:00"},"s":"I",  "c":"CONTROL",  "id":5945603, "ctx":"main","msg":"Multi threading initialized"}
{"t":{"$date":"2025-04-01T22:55:52.621-07:00"},"s":"I",  "c":"NETWORK",  "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set at least one of the related parameters","attr":{"relatedParameters":["tcpFastOpenServer","tcpFastOpenClient","tcpFastOpenQueueSize"]}}
{"t":{"$date":"2025-04-01T22:55:52.621-07:00"},"s":"I",  "c":"NETWORK",  "id":4915701, "ctx":"main","msg":"Initialized wire specification","attr":{"spec":{"incomingExternalClient":{"minWireVersion":0,"maxWireVersion":25},"incomingInternalClient":{"minWireVersion":0,"maxWireVersion":25},"outgoing":{"minWireVersion":6,"maxWireVersion":25},"isInternalClient":true}}}
{"t":{"$date":"2025-04-01T22:55:52.632-07:00"},"s":"F",  "c":"ASSERT",   "id":23095,   "ctx":"main","msg":"Fatal assertion","attr":{"msgid":40475,"error":"FailedToParse: failed to parse time zone file for time zone identifier \"Asia/Riyadh87\": The version used in this timezone identifier is unsupported","file":"src/mongo/db/query/datetime/date_time_support.cpp","line":219}}
{"t":{"$date":"2025-04-01T22:55:52.632-07:00"},"s":"F",  "c":"ASSERT",   "id":23096,   "ctx":"main","msg":"\n\n***aborting after fassert() failure\n\n"}

Isso parece indicar um problema com o pacote tzdata, então verifiquei de algumas maneiras:

• dpkg --verify tzdata # sem erros ou saída
• Verificando os aptlogs zgrep -i tzdata /var/log/apt/*.gz, houve uma atualização ontem (31 de março de 2025)
• Ao verificar os arquivos tzdata de Riyadh, find /usr/share/zoneinfo|grep "Riyadh"|xargs -n 1 zdump -vnão havia mensagens de erro, embora alguns registros tivessem "NULL", mas não está claro se isso indica um problema.

Então, eu desinstalei essa versão ( apt remove mongodb-org-server mongodb-org-shell mongodb-org-tools mongodb-org-mongos mongodb-org-database mongodb-org-database-tools-extra mongodb-mongosh mongodb-database-tools)

Em seguida, instalei versões anteriores a partir da página de arquivo da edição comunitária , baixando arquivos .deb e iterando pelas versões 8.0.5, 8.0.4, 8.0.3, 8.0.1 e 8.0.0. Instalei cada uma delas, iniciei e verifiquei se falhavam – todas falhavam –, todas com a mesma mensagem "FailedToParse: falha ao analisar o arquivo de fuso horário para o identificador de fuso horário "Asia/Riyadh87"" em /var/log/mongodb/mongod.log.

Isso pode ser um "problema meu", mas parece improvável que um arquivo de fuso horário no tzdata com um formato não suportado consiga entrar no repositório do Ubuntu sem afetar outros serviços e sem ser corrigido imediatamente. No entanto, já tive problemas com o tzdata no Ubuntu 22.04 e consegui resolvê-los com um apt reinstall.

Prefiro executar serviços em bare metal, daí meus esforços, então, se alguém tiver alguma contribuição, agradeço. Por enquanto, vou abrir o MongoDB no Docker e cerrar os dentes.

Atualização - A instalação do mongodb-server-org adiciona um /etc/mongod.conf padrão, que contém:

processManagement:
  timeZoneInfo: /usr/local/share/tzdb

Tentei começar com e sem essas linhas, sem diferença, o mongod ainda verifica o tzdb integrado do Ubuntu e falha na asserção.

Então baixei o tzdb e o descompactei em /usr/local/share/mytzdb, apontei o mongod.conf para esse local e iniciei o mongod - sem sucesso, falhou da mesma forma.

Talvez haja uma variável de ambiente que substitua? Por enquanto, estou usando o Docker, sem problemas.

Ah, hoje de manhã uma atualização do Ubuntu teve uma atualização do tzdb, rs. Mas não corrigiu o mongod.

Primeiro, não estou usando IPv6 no meu servidor, e o IPv6 está sendo desabilitado.

Entretanto, se eu executar firewall-cmd --list-all-policies, posso ver que há uma política padrão chamada allow-host-ipv6.

O que ele realmente faz? Também não tenho ideia de onde vem essa política. Tenho quase certeza de que o /etc/firewalld/policies/diretório está vazio. Como posso me livrar dele?

# firewall-cmd --list-all-policies
allow-host-ipv6 (active)
  priority: -15000
  target: CONTINUE
  ingress-zones: ANY
  egress-zones: HOST
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
        rule family="ipv6" icmp-type name="neighbour-advertisement" accept
        rule family="ipv6" icmp-type name="neighbour-solicitation" accept
        rule family="ipv6" icmp-type name="router-advertisement" accept
        rule family="ipv6" icmp-type name="redirect" accept

A situação: host Debian12, apache2 httpd servindo git CGI (localizado em /repos/git) para clonagem de repositórios. Repos são armazenados no /reposdiretório e são de propriedade do gitusuário para habilitar acesso ssh a eles (por exemplo, para poder escrever no console).git push [email protected]:repos/repo.git

O problema é que, ao executar git clone https://example.com/repos.gitquando tudo é propriedade do usuário git, o git CGI imprime isso em stderr:

(13)Permission denied: [client <ip>:<port>] AH00035: access to /repos.git/info/refs denied (filesystem path '/repos/git') because search permissions are missing on a component of the path

e os comandos clone funcionam bem se eu executar chown -R www-data:www-data /repos. Mas dessa forma, não consigo acessar o repositório via ssh ( fatal: detected dubious ownership in repository at /repos/repo.gitno cliente, mesmo quando gito usuário está dentro www-datado grupo)

Tentei fazer o diretório ser de propriedade de use gite group www-datae habilitar sharedRepository=0640na configuração (eu também tentei valores diferentes), mas então o script CGI falha com esse dubious ownershiperro. Tentei configurar a configuração global, tentei fazer diretório 2777e 0666permissões, mas nada funciona.

Para esclarecer, eu realmente não gosto de fazer login como www-datausuário para acesso ssh a repositórios git. E eu sinto que deve haver algo sharedRepositoryque eu possa executar, mas não consigo entender o que deveria ser.

PS: Não preciso, gitwebpois estou executando o cgit, e apache2a configuração deveria (pelo menos em teoria) ser irrelevante aqui.

Estou tentando desabilitar o Jenins neste servidor, porque não precisamos mais dele

ps -feww | grep jenkins

mostra

jenkins     6646    6089  0 08:53 ?        00:00:00 npm start
jenkins     9180    6646 29 08:53 ?        01:19:15 next-server (v14.2.5)
jenkins    15769   12444  0 08:53 ?        00:00:02 /shared/argocd-dex rundex
jumicha      587438  544583  0 13:18 pts/0    00:00:00 grep --color=auto jenkins

Qual deve ser o próximo passo? Como descobrir o que iniciou o Jenkins?

ps -p 9180 -o pid,vsz=MEMORY -o user,group=GROUP -o comm,args=ARGS
    PID MEMORY USER     GROUP    COMMAND         ARGS
   9180 21735356 jenkins 65533   next-server (v1 next-server (v14.2.5)

O que foi que deu início ao next-server?

pstree -pn 9180
next-server (v1(9180)─┬─{next-server (v1}(9189)
                      ├─{next-server (v1}(9190)
                      ├─{next-server (v1}(9191)
                      ├─{next-server (v1}(9192)
                      ├─{next-server (v1}(9193)
                      ├─{next-server (v1}(9214)
                      ├─{next-server (v1}(12061)
                      ├─{next-server (v1}(12062)
                      ├─{next-server (v1}(12063)
                      └─{next-server (v1}(12064)

Estou tentando configurar a seguinte rede:

Host1 ---(VPN1)--- Host2 ---(VPN2)--- Host3

Onde

• Host1tem IP 10.0.0.1/16na interface tun-vpn1;
• Host2tem IPs 10.0.0.2/16na interface tun-vpn1, e 10.1.0.1/16na interface tun-vpn2;
• Host3tem IP 10.1.0.2/16na interface tun-vpn2.

Especificamente, Host1é um servidor OpenVPN com rede 10.0.0.0/16com Host2como seu cliente. Portanto, eles são conectados de 10.0.0.1 --- 10.0.0.2.

Similarmente, Host2é um servidor OpenVPN com rede 10.1.0.0/16com Host3como seu cliente. Portanto, eles são conectados de 10.1.0.1 --- 10.1.0.2.

Agora, estou tentando fazer Host1ping Host3. A primeira coisa que tentei foi Host1fazer ping Host2na interface dele tun-vpn2. Então, de Host1eu faço

ping 10.1.0.1

O que não funciona.

Então tentei configurar uma rota Host1como

ip route add 10.1.0.0/16 via 10.0.0.2 dev tun-vpn1

E novamente não tive sucesso. E o tcpdump não mostra nenhum pacote chegando em Host2, mesmo que eles saiam Host1na interface tun-vpn1.

Como posso configurar esse roteamento?

Obrigado.