Использование cl-update через прокси

citycat · June 3, 2019, 6:14am

Итак, господа, 2019 год на дворе - а воз и ныне там? Ну не работает cl-update через прокси, хоть ты тресни - а все рекомендации относятся к году лохматому, при том, что calculate-utils регулярно переделывается нафиг.
Вот, форму мне предложил тему от 2016 года - я ее уже читал, но как так ни делай - работать не будет. Icerider, ау!
В итоге плюнул я на это дело и решил разобраться. Да, cl-core сотоварищи написана на питоне, а я питона совсем не знаю, но пофиг - я знаю Perl и общие принципы, есть гугл, прорвемся!
Прорываемся… и охреневаем.

--- binhosts.py.old     2019-02-15 17:00:33.000000000 +0700
+++ binhosts.py 2019-06-03 13:09:19.609969164 +0700
@@ -43,8 +43,9 @@
     """
     Получить URL, без прокси
     """
-    proxy_handler = urllib2.ProxyHandler({})
-    opener = urllib2.build_opener(proxy_handler)
+#    proxy_handler = urllib2.ProxyHandler({})
+#    opener = urllib2.build_opener(proxy_handler)
+    opener = urllib2.build_opener()
     if timeout is not None:
         f = opener.open(fn, timeout=timeout)
     else:

Вот ЭТО, простите, как назвать??? (Патч имени меня, в оригинале - старая версия, собственно файл - как наверное уже догадались - /usr/lib/python2.7/site-packages/calculate/lib/utils/binhosts.py
Вот скажите мне, ей-Богу интересно очень - ПОЧЕМУ? Сервак может быть за корпоративным прокси, доступ через который не получить никак. Накуа ему требовать прямой выход в тырнет?

icerider · June 3, 2019, 7:21am

Прокси был отключен в связи с жалобами на невозможное обновление с системным прокси.

К тому же были сложности при скачивании последнего среза git с использованием proxy.

citycat · June 4, 2019, 3:05am

А разобраться? Вообще-то это напоминает лечение зубной боли методом “врежу-в-харю”.
Не, я понимаю, что с бесплатного дистриба всегда взятки гладки - вроде как не нравится - не кушай, либо разбирайся сам. Мозилла во времена оные была ровно же с таким подходом… Ладно, разберусь, заодно модный нынче питон мало-мало знать буду.

У меня есть возможность дать прямой выход хоть кому. Но это глупо.

JFYI:Проблема, судя по гуглу - тянется с лохматых годов и до сих пор не найдено никакого способа решения? Ну, значит так надо…

Типо корпоративный дистриб, блин…

C2H5OH · June 5, 2019, 7:00am

У меня такая же проблема. Корпоративный прокси и никак пока не получается запустить cl-update. До этого был ubuntu server и там как-то всё совсем сразу и просто решилось. Но по разным причинам от ubuntu ушли и вот упёрся в непонятное. Все рекомендации, что нашлись, не помогли. Сам вряд ли что-то придумаю, опыта мало совсем пока.
Огромная просьба, если вдруг будет решение - напишите тут )

citycat · June 6, 2019, 6:00am

Решение уже есть - я упрямый

Правда, icerider-у сотоварищи оно не понравится Поглядел я на общую структуру cl-core и прочего комплекса - и подумал “Да, вот классический пример бестолковости и ненужности - налабать преогромнейший программный комплекс, а зачем он? Нешто в линухе нет утиля, который мог бы сделать то же самое, но стандартными средствами?”

В общем, cl-update встает в позу ротного пулемета в двух местах. Сначала, когда пытается протестить сервер бинарных обновлений - там патч выше приведен, который возвращает поддержку прокси в этом месте (про настройку прокси напишу ниже). И второй раз, когда пытается проверить доступность сервера обновлений из переменной update.cl_update_rep_url, причем, если в первом случае использовались хоть питоновские стандартные функции, то во втором - все свое, от самого socket(). Спасибо, что стек TCP/IP не переписали

Поскольку дорабатывать функцию проверки так, чтобы она и прокси могла использовать, да еще на питоне было бы для меня сложновато - я проверил, что данная функция вызывается только один раз - и тупо закомментил ее - пусть checkUrl() всегда возвращает True
— lib/utils/git.py.old 2019-02-15 17:00:33.000000000 +0700
+++ lib/utils/git.py 2019-06-04 12:22:29.346346839 +0700
@@ -542,8 +542,8 @@
:return:
“”"
git_port, target = Git.parse_url(url)

   if git_port != self.GitProtocol.Unknown:

       return check_port(target, git_port, timeout=20)

+# if git_port != self.GitProtocol.Unknown:
+# return check_port(target, git_port, timeout=20)
return True

 def isNeedUnpack(self, rpath, fns=(".gitignore",

После этого cl-update начинает работу через прокси - если все правильно настроено (об этом в следующем посту)

citycat · June 6, 2019, 6:11am

А теперь про необходимые настройки

Нужно настроить использование прокси в layman - /etc/layman/layman.cfg
Нужно настроить использование прокси в wget - /etc/wgetrc
Нужно настроить использование прокси в git - .gitconfig в домашке рута
Нужно настроить использование прокси в системе вообще /etc/env.d/99proxy (он топорно прост:
HTTP_PROXY=http://10.1.1.1:8080
HTTPS_PROXY=http://10.1.1.1:8080
FTP_PROXY=http://10.1.1.1:8080
RSYNC_PROXY=http://10.1.1.1:8080
FTP_PASSIVE_MODE=yes
(естественно поставить свой IP прокси или имя, потом запустить env-update)
Нужно в файлах /etc/portage/repos.conf/layman.conf и /etc/portage/repos.conf/gentoo.conf заменить префикс протокола git:// на https:// в параметре sync-uri
Нужно добавить в файл /etc/calculate/calculate.env (если такого нет - создать) параметр update.cl_update_rep_url, значение взять из /var/lib/layman/distros/profiles/calculate.env, потом в этом значении все префиксы протоколов git:// заменить на https://

Возможно из всего этого надо не все. Я просто все это делал в процесс разбирательств, а выяснять что к чему и выводить Минимально Необходимое Воздействие было неохота…