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
Nem tudo são flores
E se o cliente não conversar com o PACRunner via D-Bus nem linkar a libproxy? Daí restam as variáveis de ambiente, que são terrivelmente problemáticas com autoconfiguração de proxy e não são suportadas pelo PACRunner.
Arch e openSUSE não empacotam o PACRunner. Já a versão que está no Fedora é velha demais e é compilada com
Bugs
NetworkManager 1.6.2 (última versão estável enquanto escrevo) não envia a configuração ao PACRunner (BGO#780558).
Ainda ruim
Autoconfiguração de proxy no GNU/Linux tem avançado a passos de tartaruga. O esqueleto de uma configuração funcional existe; os clientes, contudo, precisam parar de depender de variáveis de ambiente. Visto que a libproxy possui uma API simples, o ecosistema poderia padronizar nela a tarefa de lidar com proxies. Dos componentes básicos, a libcurl é usada por muitos códigos que acessam a internet. Precisaria ser a primeira a passar a usá-la (patch existe).
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 +----------------+ +-----------+ | PACRunner | <----> | v8, mozjs | +----------------+ +-----------+ ^ ^ | \ D-Bus (org.pacrunner.Client.FindProxyForURL) | +----------+ | \ | v | +----------------------+ | | | | | libproxy.so do | | | PACRunner | | | (API compatível) | | | | | +----------------------+ | ^ | | libproxy API (px_proxy_factory_get_proxies) | v | +-----------+ | | Cliente 2 | | +-----------+ | | D-Bus (org.pacrunner.Client.FindProxyForURL) v +-----------+ | Cliente 1 | +-----------+
Nem tudo são flores
E se o cliente não conversar com o PACRunner via D-Bus nem linkar a libproxy? Daí restam as variáveis de ambiente, que são terrivelmente problemáticas com autoconfiguração de proxy e não são suportadas pelo PACRunner.
Arch e openSUSE não empacotam o PACRunner. Já a versão que está no Fedora é velha demais e é compilada com
--disable-libproxy
.Bugs
NetworkManager 1.6.2 (última versão estável enquanto escrevo) não envia a configuração ao PACRunner (BGO#780558).
Ainda ruim
Autoconfiguração de proxy no GNU/Linux tem avançado a passos de tartaruga. O esqueleto de uma configuração funcional existe; os clientes, contudo, precisam parar de depender de variáveis de ambiente. Visto que a libproxy possui uma API simples, o ecosistema poderia padronizar nela a tarefa de lidar com proxies. Dos componentes básicos, a libcurl é usada por muitos códigos que acessam a internet. Precisaria ser a primeira a passar a usá-la (patch existe).
Comentários
Postar um comentário