Переменная окружения `no_proxy` неэффективна при загрузке`setup.py`

Я пытаюсь загрузить артефакт Python в пользовательский репозиторий Nexus, расположенный в сети моей компании, и он не работает:

$ python2 setup.py bdist_wheel --universal upload -r nexus
running bdist_wheel
running build
running build_py
running build_scripts
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64/wheel
. . .
. . .
. . .
running upload
Submitting /home/<user>/dist/processing_catalog-0.1.1-py2.py3-none-any.whl to http://nexus3.mycompany.net/repository/pip/
Upload failed (503): Service Unavailable
error: Upload failed (503): Service Unavailable

Я за корпоративный HTTP прокси (10.200.1.1:3128). Тем не менее, хранилище Nexus находится в той же сети, поэтому я "не проксировал" локальный домен компании. Вот мои переменные окружения прокси:

$ env | grep -Fi proxy
NO_PROXY=localhost,127.0.0.0/8,::1,.mycompany.net
http_proxy=http://10.200.1.1:3128
https_proxy=http://10.200.1.1:3128
HTTPS_PROXY=http://http://10.200.1.1:3128/
no_proxy=localhost,127.0.0.1,.mycompany.net
HTTP_PROXY=http://http://10.200.1.1:3128/

Tcpdump при выполнении команды загрузки показывает, что поток выходит на прокси:

$ sudo tcpdump -Q out -i eth0 -nn dst host 10.200.1.1 and dst port 3128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:36:58.537988 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [S], seq 3601157597, win 29200, options [mss 1460,sackOK,TS val 1913260691 ecr 0,nop,wscale 7], length 0
11:36:58.539684 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [.], ack 3499932568, win 229, options [nop,nop,TS val 1913260692 ecr 2310337451], length 0
11:36:58.539746 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [.], seq 0:7240, ack 1, win 229, options [nop,nop,TS val 1913260692 ecr 2310337451], length 7240
11:36:58.539753 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [.], seq 7240:14480, ack 1, win 229, options [nop,nop,TS val 1913260692 ecr 2310337451], length 7240
11:36:58.542743 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [P.], seq 14480:16847, ack 1, win 229, options [nop,nop,TS val 1913260695 ecr 2310337454], length 2367
11:36:58.567501 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [.], ack 4009, win 291, options [nop,nop,TS val 1913260720 ecr 2310337476], length 0
11:36:58.567866 IP 10.100.59.19.38048 > 10.200.1.1.3128: Flags [F.], seq 16847, ack 4010, win 291, options [nop,nop,TS val 1913260721 ecr 2310337476], length 0
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

Это хорошо согласуется с тем фактом, что журналы не принимаются на стороне сервера Nexus при выполнении загрузки.

Моя конфигурация загрузки:

$ cat ~/.pypirc
[distutils]
index-servers =
    nexus

[nexus]
repository: http://nexus3.mycompany.net/repository/pip/
username:
password:

$ sudo cat /etc/pip.conf
[global]
timeout = 60
trusted-host = pypi.python.org
               nexus3.mycompany.net
index-url = https://pypi.python.org/simple
extra-index-url = http://nexus3.mycompany.net/repository/pip/simple

С другой стороны, загрузка пипсов работает просто отлично:

$ pip download processing-catalog
Collecting processing-catalog
  Downloading http://nexus3.mycompany.net/repository/pip/packages/processing-catalog/0.1.2/processing_catalog-0.1.2-py2.py3-none-any.whl
. . .
. . .
. . .
Successfully downloaded processing-catalog . . .

То же самое касается простого завитка:

$ curl -sv -u <username>:<password> http://nexus3.mycompany.net/repository/pip/packages/processing-catalog/0.1.1/processing_catalog-0.1.1-py2.py3-none-any.whl -o processing_catalog-0.1.1-py2.py3-none-any.whl
*   Trying 10.100.58.110...
* Connected to nexus3.mycompany.net (10.100.58.110) port 80 (#0)
* Server auth using Basic with user '<username>'
> GET /repository/pip/packages/processing-catalog/0.1.1/processing_catalog-0.1.1-py2.py3-none-any.whl HTTP/1.1
> Host: nexus3.mycompany.net
> Authorization: Basic <token>
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 27 Feb 2018 10:51:47 GMT
< Server: Nexus/3.6.2-01 (OSS)
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Last-Modified: Tue, 27 Feb 2018 10:11:01 GMT
< Content-Type: application/zip
< Content-Length: 14229
< 
{ [4096 bytes data]
* Connection #0 to host nexus3.mycompany.net left intact

Итак, почему setup.py upload выходить на прокси?

Источник

1 ответ

Отвечая на мой вопрос

Я думаю, что в отличие от curl или же pip, setup.py upload не могу читать, в no_proxy переменная среды, формат домена с . в начале. Увидеть:

нет . в начале домена в no_proxy переменная: это работает

$ no_proxy=mycompany.net python2 setup.py bdist_wheel --universal upload -r nexus
running bdist_wheel
running build
running build_py
running build_scripts
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64/wheel
creating build/bdist.linux-x86_64/wheel/processing_catalog
. . .
. . .
. . .
running upload
Submitting /home/<user>/dist/processing_catalog-0.1.1-py2.py3-none-any.whl to http://nexus3.mycompany.net/repository/pip/
Server response (200): OK

. в начале домена в no_proxy переменная: это не работает

$ no_proxy=.mycompany.net python2 setup.py bdist_wheel --universal upload -r nexus
running bdist_wheel
running build
running build_py
running build_scripts
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64/wheel
creating build/bdist.linux-x86_64/wheel/processing_catalog
. . .
. . .
. . .
running upload
Submitting /home/<user>/dist/processing_catalog-0.1.1-py2.py3-none-any.whl to http://nexus3.mycompany.net/repository/pip/
Upload failed (503): Service Unavailable
error: Upload failed (503): Service Unavailable
Источник
Другие вопросы по тегам