Perguntas[debian](server)

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?

Eu tenho uma VPN Wireguard configurada para encaminhar pacotes (com iptables) recebidos em um VPS para um servidor, o que funciona muito bem. Porém, a configuração automática da eno2interface (do servidor) pelo Debian cria rotas IP, uma delas é a x:x:x:x::/64 dev eno2, que é a rede local em que o servidor está.

Isso cria um comportamento indesejado, pois quando eu (da rede local) envio pacotes para o servidor através do VPS (isso significa que o servidor receberá os pacotes na interface wg0), o servidor responde na rede local (interface eno2), pois o IPv6 de origem O endereço é o mesmo na Internet e na rede local e, portanto, corresponde à rota x:x:x:x::/64 dev eno2, mesmo que o tráfego IPv6 não local seja enviado wg0. E responde com um endereço IP que o computador de onde enviei os pacotes não conhece porque configurei o NAT com o Wireguard.

Conforme está escrito no título isso não ocorre com IPv4, pois ele usa NAT, então o endereço IP de origem não corresponde 192.168.1.0/24 dev eno2.

Sempre posso me conectar diretamente ao servidor sem passar pelo VPS, ou me conectar com os endereços link-local fe80::/10quando preciso e substituir a rota configurada automaticamente por uma que tenha métrica mais baixa e preferência mais alta (ex. x:x:x:x::/64 dev wg0 metric 200 pref high) para manter a configuração automática feita pelo Debian, exceto esta rota. Mas isso não leva em consideração que o prefixo da rede pode mudar. Também consegui fazê-lo funcionar adicionando uma regra SNAT iptablesdo VPS, mas isso interrompe os serviços que precisam do endereço IP de origem (por exemplo, SPF).

Existe uma solução melhor para o problema? Talvez adicionando uma rota que envie pacotes de volta wg0para wg0e fazendo com que essa rota tenha prioridade sobre a x:x:x:x::/64 dev eno2rota, para que eu ainda possa acessar o servidor na minha rede local com seu endereço IPv6 público?

Estou tentando instalar e configurar o servidor ISC DHCP no Debian 12 e . Mas continuo recebendo os seguintes erros no syslog.

Jul 26 13:42:38 3ecc1b69 dhcpd[774]: No subnet declaration for enp2s0 (no IPv4 addresses).
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: ** Ignoring requests on enp2s0.  If this is not what
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    you want, please write a subnet declaration
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    in your dhcpd.conf file for the network segment
Jul 26 13:42:38 3ecc1b69 dhcpd[774]:    to which interface enp2s0 is attached. **
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: 
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: 
Jul 26 13:42:38 3ecc1b69 dhcpd[774]: Not configured to listen on any interface

Abaixo estão os arquivos de configuração

dhcpd.conf

  subnet 192.168.1.0 netmask 255.255.255.0 {
        range 192.168.1.100 192.168.1.200;
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.1;
        option subnet-mask 255.255.255.0;
    }

interfaces

    source /etc/network/interfaces.d/*
    auto lo
    iface lo inet loopback
    
  


  allow-hotplug enp2s0
    iface enp2s0 static
        address 192.168.1.1
        netmask 255.255.255.0

servidor isc-dhcp

INTERFACESv4="enp2s0"
INTERFACESv6="enp2s0"

A tentativa de iniciar o servidor produz esta saída

    Job for isc-dhcp-server.service failed because the control process exited with error code.
    See "systemctl status isc-dhcp-server.service" and "journalctl -xeu isc-dhcp-server.service" for details.


systemctl status isc-dhcp-server.service provides this output

isc-dhcp-server.service - LSB: DHCP server
         Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
         Active: failed (Result: exit-code) since Fri 2024-07-26 16:11:23 EEST; 57s ago
           Docs: man:systemd-sysv-generator(8)
        Process: 1290 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
            CPU: 39ms
    
    Jul 26 16:11:21 3ecc1b69 systemd[1]: Starting isc-dhcp-server.service - LSB: DHCP server...
    Jul 26 16:11:21 3ecc1b69 isc-dhcp-server[1290]: Launching IPv4 server only.
    Jul 26 16:11:23 3ecc1b69 isc-dhcp-server[1290]: Starting ISC DHCPv4 server: dhcpdcheck syslog for diagnostics. ... failed!
    Jul 26 16:11:23 3ecc1b69 isc-dhcp-server[1290]:  failed!
    Jul 26 16:11:23 3ecc1b69 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
    Jul 26 16:11:23 3ecc1b69 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
    Jul 26 16:11:23 3ecc1b69 systemd[1]: Failed to start isc-dhcp-server.service - LSB: DHCP server.