Perguntas[debian](server)

Tenho um servidor Debian rodando com um SSD e dois HDDs (SDA e SDB). O SDA é EXT4 e o SDB é XFS. Ambos são Toshiba MG07ACA14TE (512e), 14 TB.

A situação é a seguinte:

Os HDs ficam em modo de espera, na maior parte do tempo, e só despertam quando necessário. Todas as noites, executo um script Snapraid e alguns outros scripts para backup. A cada duas semanas, aproximadamente, os HDs apresentam um comportamento estranho. Assim que o SDA desperta, ele permanece ativo por cerca de 2 dias e depois volta ao modo de espera. Ele fica apenas girando e, até onde pude verificar, nada é escrito ou lido. Eu fiz isso:

• ps -ef: nenhum processo vinculado a esse comportamento.
• iotop -a: nada para SDA
• fatrace -c: nada para SDA
• dstat --nocolor -dD sda: nada para SDA

Normalmente, se eu verificar hdparm -C /dev/sda, o estado da unidade é standby, idle ou active. Mas agora ele mostra active/idle. Quando verifico novamente após dois dias, ele mostra standy, idle ou active novamente.

Outra coisa interessante que notei é que, antes de formatar o SDB para XFS, ele também era EXT4 e apresentava o mesmo comportamento do SDA. A única diferença foi que o despertar ocorreu um dia depois, porque em determinado momento desconectei o disco do servidor por um dia para testes. No entanto, toda vez que o SDA começava a rodar por 2 dias, um dia depois o SDB também.

Em um tópico em outro fórum, obtive informações de que esse comportamento pode ser causado pelo Ext4-rsv-conver. Verifiquei no PS e vi esse processo, mas agora duvido que seja ele quem esteja causando o problema, pois ele aparece depois que o disco já está girando e, enquanto o disco normalmente está em espera, também vejo esse processo em execução de vez em quando.

Alguém tem alguma ideia do que está fazendo com que os HDs fiquem girando por 2 dias e voltem ao modo normal? Ou me dê alguma dica sobre o que mais eu posso tentar para solucionar o problema?

Primeiro, um pouco de história:

Atualmente, tenho meu site pessoal (sei que o Server Fault é para ambientes corporativos, mas pareceu o melhor lugar para fazer essa pergunta) hospedado em um servidor Amazon Lightsail executando a imagem Node.js da Bitnami (o servidor Bitnami). O site usa NextJS. Recentemente, decidi movê-lo para outro servidor Lightsail executando a imagem Debian 12 (o servidor Debian), já que a Bitnami não tem uma boa maneira de manter o Apache e o Node atualizados. Depois de iniciar o servidor Debian, instalei o Apache (mas ainda não o configurei), o FNM (para gerenciar o Node e o NPM) e o PM2 nele e me certifiquei de que tudo estava atualizado. Em seguida, adicionei git pullmeu site ao novo servidor para poder criá-lo lá. ( git pullEra como eu estava implantando o site no servidor Bitnami.)

O problema:

Sempre que executo npm run buildo Debian no servidor, ele trava ou trava com "código de saída: nulo e sinal: SIGKILL". Descobri como ler os logs do sistema e descobri que ele estava sendo eliminado pelo eliminador de memória insuficiente, e sempre que travava era quando, de alguma forma, isso não o eliminava. (Não faço ideia do porquê.) O problema é que funciona perfeitamente no servidor Bitnami, embora eu tenha que usar sudo, ou recebo um erro de "permissão negada" sobre a desvinculação de algum arquivo. (Acho que terei que lidar com isso depois que o problema de memória insuficiente for corrigido, mas estou lidando com um problema de cada vez agora.)

Ambos os servidores têm 512 MB de RAM e um SSD de 20 GB. Ambos os servidores foram criados com as configurações padrão/mais baratas para suas imagens, eu acho. (Ambos usam a configuração que paga US$ 5/mês.)

Executei topem ambos os servidores para ver se isso me ajudaria a descobrir o problema e notei que o servidor Bitnami tem bastante memória swap que o servidor Debian não tem. Não sei por quê. O servidor Bitnami também tinha muito menos memória livre do que o servidor Debian (sem npm run buildexecução), o que faz sentido, visto que o servidor Bitnami tem alguns programas extras em execução e está hospedando ativamente o site. Além disso, o servidor Bitnami tinha muito mais memória "buff/cache" do que o servidor Debian.

O que posso fazer para corrigir o problema de falta de memória ou descobrir o que está causando isso?

Determinado a transformar um computador antigo em um servidor (NAS, Home Assistant, ...), decidi aprender sobre Virtualização com o Projeto Xen no Debian. O servidor deve ser usado somente em LAN e tem o endereço IP estático 10.56.0.191. Estou tentando criar um convidado em 10.56.0.192 com Xen. Para isso, segui as informações fornecidas no guia para iniciantes do projeto Xen e consegui criar um convidado VP executando Debian também.

Infelizmente, o convidado não tem conexão nenhuma. Ainda seguindo o guia para iniciantes, junto com a rede Xen , tentei configurar a interface do host, encaminhamento de IP, proxy ARP e mascaramento de IP. Infelizmente, o wiki faz referência a iptable que parece ter sido substituído por nftables . Portanto, estou tentando usar nftables .

O convidado parece não conseguir se comunicar (conexão testada por ping em vários hosts na LAN), enquanto o host consegue se comunicar corretamente.

Parece que estou esquecendo de algo importante, mas não consigo descobrir. Você poderia me ajudar com esse problema?

Configurei o host e o convidado da seguinte maneira.

Agradeço sua ajuda :-)

No host

Criei uma ponte, xenbr0, da /etc/network/interfacesseguinte forma:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Static IP on ethernet
iface enp2s0 inet manual

# Bridge for Xen hypervisor
auto xenbr0
iface xenbr0 inet static
    address 10.56.0.191
    netmask 255.255.0.0
    gateway 10.56.0.1
    dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8
    bridge_ports enp2s0
    bridge_stp off
    bridge_maxwait 0
    bridge_fd 0

O encaminhamento IPv4 e o proxy ARP estão habilitados em /etc/sysctl.conf.

net.ipv4.ip_forward=1
net.ipv4.conf.enp2s0.proxy_arp=1

Com nftables , criei uma tabela nat e uma cadeia postrouting . Depois adicionei uma regra para o mascaramento de IP.

nft add table nat
nft add chain ip nat postrouting { type nat hook postrouting priority 0 \; }
nft add rule nat postrouting ip saddr 10.56.0.0/16 oif enp2s0 masquerade

A chamada nft list rulesetretorna o seguinte:

table ip nat {
    chain postrouting {
        type nat hook postrouting priority filter; policy accept;
        ip saddr 10.56.0.0/16 oif "enp2s0" masquerade
    }
}

No convidado

No arquivo de configuração do convidado, a interface virtual é definida comovif = [ 'ip=10.56.0.192 ,mac=00:16:3E:FA:9C:76, bridge=xenbr0' ]

Também estou tentando configurar sua interface de rede definindo um IP estático em /etc/network/interfaces:

auto lo
iface lo inet loopback

auto enX0
iface enX0 inet static
    address 10.56.0.192
    gateway 10.56.0.1
    netmask 255.255.0.0
    dns-nameservers 1.1.1.1 4.4.4.4 8.8.8.8

Tenho um problema ao atualizar o Linux. Recebi um 404 não encontrado para o IP do servidor de destino, o que foi estranho o suficiente. Mais tarde, descobri que o traceroute passa por um nó backbone.rt.ru do núcleo.

Isso é um possível sequestro de BGP?

Os domínios ru hoje em dia parecem muito suspeitos, especialmente na Europa Central.

root@XXXXXXX:~# apt-get update
Hit:1 http://ftp.pl.debian.org/debian buster InRelease
Hit:2 http://ftp.pl.debian.org/debian buster-updates InRelease
Hit:3 http://security.debian.org buster/updates InRelease
Hit:4 https://deb.nodesource.com/node_12.x buster InRelease
Ign:5 http://apt.postgresql.org/pub/repos/apt buster-pgdg InRelease
Err:6 http://apt.postgresql.org/pub/repos/apt buster-pgdg Release
 ** 404  Not Found [IP: 217.196.149.55 80]**
Reading package lists... Done
E: The repository 'http://apt.postgresql.org/pub/repos/apt buster-pgdg Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@XXXXXXX:~# ^C
root@XXXXXXX:~#

Aqui está o traceroute:

root@XXXXXXX:~# traceroute 217.196.149.55
traceroute to 217.196.149.55 (217.196.149.55), 30 hops max, 60 byte packets
 1  * * *
 2  XXXXXXXXXXXXXX  0.465 ms  0.438 ms
 3  164.next4.zicom.pl (185.175.107.164)  6.748 ms  7.108 ms  7.089 ms
 4  et-0-0-18-590.edge5.Warsaw1.Level3.net (213.249.126.109)  7.345 ms  7.777 ms  7.271 ms
 5  ae2.3601.edge5.ber1.neo.colt.net (171.75.8.27)  15.454 ms  15.421 ms  15.572 ms
 6  195.122.181.74 (195.122.181.74)  16.261 ms  16.202 ms  16.138 ms
 7  ae6-2082.ams10.core-backbone.com (80.255.14.33)  27.831 ms  27.767 ms  27.473 ms
 8  core-backbone.rt.ru (81.95.2.150)  26.598 ms  26.359 ms  26.919 ms
 9  * * *
10  185.69.160.214 (185.69.160.214)  37.410 ms  37.011 ms 195.192.211.124 (195.192.211.124)  37.004 ms
11  fabrina.postgresql.org (217.196.149.55)  44.516 ms  44.481 ms *

O problema é semelhante a este , mas há duas nuances.

1. Se eu alternar para o usuário e sudo -u testuser -ientão carregar a CPU usando o utilitário de estresse, o CPUQuota não terá efeito.

2. Se eu fizer login via SSH como um testuser, executar alguma tarefa intensiva e então funcionará como esperado.

Minha configuração de CPUQuota

/etc/systemd/system.control/user-1003.slice.d/50-CPUQuota.conf

[Slice]
CPUQuota=33%

systemctl show -p DefaultCPUAccounting

DefaultCPUAccounting=yes

Distribuição: Debian 12 mais recente. Ubuntu 22.04 também afetado por isso.

Como posso depurar esse problema para obter alguma pista?

Problema de PS postado no repositório GitHub do systemd

Infelizmente, não tenho muita experiência com administração de sistemas e configuração de sistemas Linux, então, por favor, não seja tão duro comigo; ainda estou aprendendo ;)

Configuração de rede:

172.21.0.1 - o servidor com modelagem de tráfego.

172.21.0.2 - o segundo servidor que armazena arquivos solicitados pelos clientes via HTTP.

172.21.0.6 e 172.21.0.7 - dois dispositivos clientes.

Estou tentando configurar a modelagem de tráfego para clientes WireGuard:

tc qdisc add dev wg0 parent root handle 1:0 hfsc default 10

# Root class
tc class add dev wg0 parent 1: classid 1:1 hfsc sc rate 1gbit ul rate 1gbit

# Reserved traffic
# Guaranteed bandwidth of 500 Mbit/s and a maximum of 1 Gbit/s
tc class add dev wg0 parent 1:1 classid 1:10 hfsc sc rate 500mbit ul rate 1gbit

# Client traffic
# Guaranteed bandwidth of 500 Mbit/s and a maximum of 1 Gbit/s
tc class add dev wg0 parent 1:1 classid 1:20 hfsc sc rate 500mbit ul rate 1gbit

# Shaping for individual client 6
tc class add dev wg0 parent 1:20 classid 1:3006 hfsc sc rate 100kbit ul rate 100kbit
tc filter add dev wg0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.21.0.6/32 flowid 1:3006

# Shaping for individual client 7
tc class add dev wg0 parent 1:20 classid 1:3007 hfsc sc rate 100kbit ul rate 100kbit
tc filter add dev wg0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.21.0.7/32 flowid 1:3007

tc -pretty filtro mostra dev wg0

filter parent 1: protocol ip pref 2 u32 chain 0
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800: ht divisor 1
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800::801 order 2049 key ht 800 bkt 0 *flowid 1:3006 not_in_hw
  match IP dst 172.21.0.6/32
filter parent 1: protocol ip pref 2 u32 chain 0 fh 800::802 order 2050 key ht 800 bkt 0 *flowid 1:3007 not_in_hw
  match IP dst 172.21.0.7/32

tc -graph classe mostra dev wg0

+---(1:) hfsc
     +---(1:1) hfsc sc m1 0bit d 0us m2 1Gbit ul m1 0bit d 0us m2 1Gbit
          +---(1:10) hfsc sc m1 0bit d 0us m2 500Mbit ul m1 0bit d 0us m2 1Gbit
          +---(1:20) hfsc sc m1 0bit d 0us m2 500Mbit ul m1 0bit d 0us m2 1Gbit
               +---(1:3007) hfsc sc m1 0bit d 0us m2 100Kbit ul m1 0bit d 0us m2 100Kbit
               +---(1:3006) hfsc sc m1 0bit d 0us m2 100Kbit ul m1 0bit d 0us m2 100Kbit
          |
     |    |

Ao tentar baixar um arquivo de ambos os clientes ao mesmo tempo, apenas um obtém 100 kbit, enquanto o outro obtém 0 kbit :(

O que estou fazendo errado? Servidor: Debian 12 rodando em KVM.

PS: O limite de 100 kbit/s é apenas para testar a funcionalidade do modelador de tráfego.

Eu também apreciaria sugestões sobre como reescrever a configuração. Talvez eu esteja fazendo isso completamente errado, e pode haver uma maneira mais otimizada (como configurar uma única classe para toda a sub-rede, para que todos os clientes WireGuard tenham um limite individual de 100 kbit).

Estou enfrentando um problema com o NFS nos últimos dias e realmente preciso de ajuda.

Minha configuração:

Armazenamento NAS: Synology, Exportação NFS /volume1/data

Nextcloud App Server: Debian, cliente NFS montado em /mnt/storage_cloud

Montar a exportação NFS 4.1 funciona bem, e eu posso acessar todos os dados com permissões de leitura/gravação como usuário root. No entanto, o usuário www-data (que executa o aplicativo Nextcloud) não consegue acessar o diretório de forma alguma.

O que tentei até agora:

• chown : -> alterando a propriedade de 'storage_cloud': Operação não permitida

• chmod 777 (sei que não é o ideal, mas vale a pena tentar): -> alterando permissões de 'storage_cloud': Operação não permitida

• setfacl: -> Operação não suportada

Depois de uma extensa pesquisa, descobri que usar Kerberos em vez de sys_auth pode ser uma solução, mas encontrei muito pouca documentação ou tutoriais sobre esse tópico.

Dado que minha configuração não parece particularmente complexa, parece que deveria haver uma solução mais simples para permitir acesso adequado ao compartilhamento NFS para www-data. Posso estar complicando demais as coisas.

Eu realmente apreciaria qualquer informação ou sugestão!

Obrigado antecipadamente, PP

Tenho um servidor que roda o Proxmox VE 8.2 (baseado no Debian 12), totalmente atualizado, que usa SAN multipath. Lá temos um espaço alocado, dez dispositivos de 2T cada, que são vistos 16 vezes cada (o número de caminhos) e que são mapeados em 10 dispositivos virtuais multipathed e coletados em um único grupo LVM, onde um volume lógico é esculpido. Sem problemas nesta parte.

Ele foi inicializado "on the fly" e estava funcionando bem, até que o host foi reiniciado. Depois disso, notei que sempre que alguém executa qualquer comando relacionado ao LVM ( lvs, etc.) no shell do sistema, ele emite o aviso no formato:

WARNING: Device mismatch detected for <LV> which is accessing <list of devices like
 /dev/sdak, /dev/sdaz, /dev/sdbn, ...> instead of <list of the devices
 like /dev/mapper/oamdwhdg-01, /dev/mapper/oamdwhdg-02, ...>

Na realidade, estes /dev/mapper/oamdwhdg-XXsão os dispositivos multipercurso, eles foram nomeados dessa forma por razões operacionais em /etc/multipath.conf:

multipaths {
...
    multipath {
        wwid 36...
        alias oamdwhdg-04
    }
...
}

Ou seja, por qualquer motivo, o LV é mapeado usando dispositivos de backend, em vez de usar dispositivos virtuais multicaminho.

Então atualizei o filtro em /etc/lvm/lvm.conf, que agora se parece com isto:

global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|.*|" ]

(Eu atualizei , não adicionei, estava global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]antes com o comentário added by pve-manager to avoid scanning ZFS zvols and Ceph rbds. Acredito que meu filtro seja muito mais rigoroso que esse.)

/dev/sda3é o disco local onde o PVE está instalado e contém o VG pveque não depende do SAN, então é o único /dev/sd...que não usa multipath e foi incluído na lista de permissões.

Testei esse filtro usando vgscane ele mostra que ambos os grupos podem ser encontrados.

Então eu executei update-initramfse reiniciei. Durante a inicialização, o servidor falhou no shell de emergência . Quando eu cheguei Ctrl+Dlá, ele, no entanto, inicializou quase normalmente: o VG multipathed é visto, mas não ativado (como se vgchange -an oamdwhdgainda não tivesse sido executado). Mas então eu o ativei manualmente perfeitamente normalmente com o comando dito e ele funcionou perfeitamente.

Suspeito que isso seja porque o multipath não foi inicializado corretamente antes do LVM no initramfs, então ele tentou configurar mapeamentos usando dispositivos /dev/sdXX. Mas por que ele falhou no shell de emergência quando adicionei o filtro, eu não entendo.

Duas perguntas (muito relacionadas) aqui: por que o shell de emergência, também conhecido como o que está errado, e como fazê-lo funcionar conforme o esperado?

Estou tentando impedir que o servidor HTTP básico 80 fique na raiz do meu DNS dinâmico e, em vez disso, usar um subdiretório.

então em vez de blabla.dynamicdns.org não será servido mas blabla.dynamicdns.org/serviceseria.

Esta tentativa de configuração não funcionou. Diz que as raízes do documento não são permitidas em tags Directory.

Eu sei o quanto o SE adora seus exemplos, então vou colocar essa configuração padrão aqui de qualquer forma.

Eu literalmente não sei nada e preciso literalmente ser alimentado com colher aqui, e é difícil pesquisar no Google sobre isso.

<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.
    #ServerName www.example.com

    ServerAdmin webmaster@localhost


    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn
    <Directory /var/www/html/ampache/>
    DocumentRoot /var/www/html/ampache
    DocumentRoot /var/www/html/ampache/public
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

Uma configuração mais correta, que ainda não produz o resultado desejado:

<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.
    #ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html/ampache
    DocumentRoot /var/www/html/ampache/public

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

Desculpe por esse spam de fato, mas meu histórico com SE e meu desejo por "exemplos práticos" sobre tópicos que nem sei como funcionam me forçaram a agir.

Instalei o MariaDB usando apt no Debian 12 junto com o Nginx. Estou executando o Wordpress no servidor.

MariaDB trava a cada poucos dias. Preciso examinar os logs de erros para determinar a causa da falha.

Não há diretório mariadb em/var/log

Ao executar o seguinte comando, show global variables like 'log_error';obtenho os resultados abaixo

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error     |       |
+---------------+-------+
1 row in set (0.001 sec)

Saída degrep 'log_error' /etc/mysql/mariadb.conf.d/50-server.cnf

#log_error = /var/log/mysql/error.log

Alguma coisa precisa ser feita para ativar o log do MaridaDB no Debian 12? Se sim, o que precisa ser feito?