Postagens

Mostrando postagens com o rótulo networkmanager

Acesso a convidado do Hyper-V via nome de máquina não funciona

O Hyper-V tem um recurso interessante no comutador "Default Switch" que automaticamente adiciona um registro DNS no hospedeiro com o nome de máquina do convidado quando este obtém IPv4 via DHCP. É salvo em %SystemRoot%\System32\drivers\etc\hosts.ics e usa o domínio mshome.net . Meu convidado Fedora 40 não estava aparecendo lá. NetworkManager envia o nome de máquina na requisição DHCP: $ nmcli connection show eth0 | grep hostname ipv4.dhcp-send-hostname: sim [...] Descrição da propriedade no manual nm-settings : If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent. Depois de quebrar um pouco a cabeça, lembrei que a instalação do Fedora por padrão não configura um nome ...

Timeout ao desmontar compartilhamento SMB durante o desligamento

Imagem
Pontos de montagem autofs são úteis para compartilhamentos de rede. Com o systemd, basta adicionar, em /etc/fstab , x-systemd.automount nas opções. Exemplo: //192.168.0.10/Arquivos /mnt/Arquivos cifs credentials=/etc/senha-servidor,uid=marcos,gid=marcos,file_mode=0600,dir_mode=0700,x-systemd.automount 0 0 Isso evita que precisemos habilitar um serviço que implemente network-online.target , como NetworkManager-wait-online.service ou systemd-networkd-wait-online.service . Assim, não há atraso durante a inicialização. Apenas quando o ponto de montagem for acessado será montado. Porém, durante o desligamento, a desmontagem sempre dava timeout e causava atraso com o NetworkManager ao usar conexões sem fio. Analisando a cadeia de dependências, nada achei de errado. Estava em outro lugar o problema. O nm-applet , aquele programinha que fica no tray, salva conexões sem fio [1] , pelo menos ao usar o plugin nativo keyfile , com o parâmetro connection.permissions configurado para o us...

Autoconfiguração de proxy com NetworkManager + PACRunner

No NetworkManager 1.6, temos novidades na forma de lidar com configuração automática de proxies. Agora, o NM pode obter a configuração via WPAD (DHCP) e enviá-la ao PACRunner , outro daemon, ativado via D-Bus, que trata de processar o JavaScript recebido e responder às requisições dos clientes. Os proxies podem ser configurados de acordo com a interface, caso mais de uma exista. Os clientes falam diretamente com o PACRunner usando sua interface via D-Bus, ou, para os que linkam a libproxy, uma biblioteca de compatibilidade provida pelo daemon faz o mesmo. Essa biblioteca substitui a libproxy original, sendo mais simples e eficiente. Trabalha apenas consultando-o via D-Bus. O design está aqui: https://wiki.gnome.org/Projects/NetworkManager/Proxies +----------------+ | NetworkManager | +----------------+ | | D-Bus (org.pacrunner.Manager.CreateProxyConfiguration) v +----------------+ +----------...

Squid 4 + systemd: combinação que funciona

Até o Squid 3.5, o comportamento do daemon é incompatível com inits modernos e exige gambiarras ou funcionalidade limitada ( -N ). Recapitulando como é até a versão 3.5: PID1 \_ MASTER/PARENT \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ FILHO 1 \_ FILHO 2 ... No Squid 4, beta enquanto escrevo, é assim: PID1 \_ MASTER/PARENT <--- PROCESSO PAI DE FATO (ARQUIVO PID) \_ WORKER \_ FILHO 1 \_ FILHO 2 ... Ou seja, o processo a ser monitorado (e sinalizado) passou a ser filho direto do init, que agora pode fazê-lo via SIGCHLD. Portanto, usando Type=forking e rodando o daemon sem a opção -N , temos uma configuração funcional. Continua não bloqueando ao receber SIGTERM; o systemd, mesmo assim, aguarda o processo principal terminar, sendo finalizado corretamente. E, sem -N , o modo de múltiplos processos funciona. Desde a versão 3.5.11, o daemon não morre mais se receber SIGHUP antes de completar a...

Arquivos de configuração do NetworkManager

Em /etc/NetworkManager/NetworkManager.conf , seção [main] , a opção plugins define onde o NM armazenará as configurações das interfaces de rede. Podem ser listados múltiplos plugin separados por vírgulas (dentre os habilitados durante a compilação): ele escreverá a configuração no local do primeiro plugin e interpretará a configuração dos demais, caso exista alguma. O Fedora, desde a versão 17 , usa o NM por padrão em todas as instalações, inclusive em modo texto. O único plugin configurado é o ifcfg-rh , que entende os velhos arquivos /etc/sysconfig/network-scripts/ifcfg-* . A configuração é por interface, sendo que cada arquivo é amarrado a um endereço MAC. Você pode sem problema remover todos os arquivos ifcfg se quiser. A interface loopback é configurada pelo systemd e o arquivo ifcfg-lo é desnecessário . No próximo boot, se, em /etc/NetworkManager/NetworkManager.conf , não existir uma linha no-auto-default=<MAC> , o NM automaticamente criará uma nova configuração tem...