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