Необычно невозможно подключиться к домену с сервера.
Я нашел, что похоже на ответ, который решил мою проблему, но это скорее метод кувалды, который в конце концов не помогает. Удаление целого каталога, вероятно, не самый изящный способ:
sudo rm -rf /usr/local/lib/python3.5/dist-packages
После этого пип не был установлен, поэтому я переустановил его с помощью
sudo apt-get update
sudo apt-get install python3-pip
pip вернулся и работал и проблема с Software Updater была также решена как ожидалось. Это «решение» работает, хотя оно удаляет многие библиотеки, такие как matplotlib, которые впоследствии необходимо переустановить. Но когда я переустановил matplotlib 2.1.2, была вызвана ошибка pip. Я действительно не могу рекомендовать этот подход.
tl; dr: Не делайте этого.
Итак, вернемся к квадрату. Решена проблема переустановки pip и каждой следующей библиотеки с sudo -H, например
sudo -H apt install --reinstall python3-pip
Без флага -H установка matplotlib вызвала ту же проблему pip , Но все же я получил сообщение об ошибке. Решение похоже на ответ, который решил мою проблему , исходящую здесь:
Я отредактировал строку # 2121 ~ 2122 этого файла: /usr/local/lib/python3.5/ dist-packages / pip / _vendor / pkg_resources / __ init__.py#orig_path.sort(key=position_in_sys_path)
#module.__path__[:] = [_normalize_cached(p) for p in orig_path]
orig_path_t = list(orig_path)
orig_path_t.sort(key=position_in_sys_path)
module.__path__[:] = [_normalize_cached(p) for p in orig_path_t]
Этот восстановленный pip / pip3 и я смогли установить модули. Пока все работает. Будем надеяться, это будет последним.
Редактирование: через неделю проблема не возникла, поэтому я отмечаю это как принятый ответ.
Редактировать 2: обновление pip возродило проблему. По-видимому, обновление переписало модификацию. Не было никаких проблем повторно вводить его снова и избавиться от аберрантного поведения.
3 ответа
Я подозревал, что это как-то связано с тем, что я использовал подсеть 192.168.0.0/16 в своей локальной сети, и, действительно, это оказалось так. Чтобы понять, в чем проблема и в конечном итоге ее решить, я начал с запроса маршрутизации сервера, в котором была обнаружена странная сетевая маска:
# ip route show
default via 192.168.0.1 dev enp5s0 onlink
192.0.0.0/8 dev enp5s0 proto kernel scope link src 192.168.0.2
Глядя в /etc/network/interfaces, выяснилось, что виновник:
Я больше не помню, если при настройке сервера установка Ubuntu Server запрашивала меня для получения подробной информации о сети или молчаливо делала эти предположения. Я действительно полагаю, что он настроен из коробки, чтобы ожидать подсеть 10.0.0.0/8, и я, должно быть, по ошибке поменял его на 192.168.*.*, но забыл о сетевой маске.
В любом случае, я исправил сетевую маску выше до 255.255.0.0 и выполнено systemctl restart networking. Запуск ip route show показал новую сетевую маску, но также и старую, как ни странно. Мне пришлось явно удалить старый маршрут с помощью ip route delete 192.0.0.0/8 dev enp5s0, а затем все это сработало.
EDIT: ответ на первую часть моего вопроса (как диагностировать) был посмотрите на маршрутизацию машины, которая, если у вас возникли проблемы с подключением к сети, может оказаться хорошим местом для поиска.
Я подозревал, что это как-то связано с тем, что я использовал подсеть 192.168.0.0/16 в своей локальной сети, и, действительно, это оказалось так. Чтобы понять, в чем проблема и в конечном итоге ее решить, я начал с запроса маршрутизации сервера, в котором была обнаружена странная сетевая маска:
# ip route show
default via 192.168.0.1 dev enp5s0 onlink
192.0.0.0/8 dev enp5s0 proto kernel scope link src 192.168.0.2
Глядя в /etc/network/interfaces, выяснилось, что виновник:
iface enp5s0 inet static
address 192.168.0.2
netmask 255.0.0.0
gateway 192.168.0.1
Я больше не помню, если при настройке сервера установка Ubuntu Server запрашивала меня для получения подробной информации о сети или молчаливо делала эти предположения. Я действительно полагаю, что он настроен из коробки, чтобы ожидать подсеть 10.0.0.0/8, и я, должно быть, по ошибке поменял его на 192.168.*.*, но забыл о сетевой маске.
В любом случае, я исправил сетевую маску выше до 255.255.0.0 и выполнено systemctl restart networking. Запуск ip route show показал новую сетевую маску, но также и старую, как ни странно. Мне пришлось явно удалить старый маршрут с помощью ip route delete 192.0.0.0/8 dev enp5s0, а затем все это сработало.
EDIT: ответ на первую часть моего вопроса (как диагностировать) был посмотрите на маршрутизацию машины, которая, если у вас возникли проблемы с подключением к сети, может оказаться хорошим местом для поиска.
Я подозревал, что это как-то связано с тем, что я использовал подсеть 192.168.0.0/16 в своей локальной сети, и, действительно, это оказалось так. Чтобы понять, в чем проблема и в конечном итоге ее решить, я начал с запроса маршрутизации сервера, в котором была обнаружена странная сетевая маска:
# ip route show
default via 192.168.0.1 dev enp5s0 onlink
192.0.0.0/8 dev enp5s0 proto kernel scope link src 192.168.0.2
Глядя в /etc/network/interfaces, выяснилось, что виновник:
iface enp5s0 inet static
address 192.168.0.2
netmask 255.0.0.0
gateway 192.168.0.1
Я больше не помню, если при настройке сервера установка Ubuntu Server запрашивала меня для получения подробной информации о сети или молчаливо делала эти предположения. Я действительно полагаю, что он настроен из коробки, чтобы ожидать подсеть 10.0.0.0/8, и я, должно быть, по ошибке поменял его на 192.168.*.*, но забыл о сетевой маске.
В любом случае, я исправил сетевую маску выше до 255.255.0.0 и выполнено systemctl restart networking. Запуск ip route show показал новую сетевую маску, но также и старую, как ни странно. Мне пришлось явно удалить старый маршрут с помощью ip route delete 192.0.0.0/8 dev enp5s0, а затем все это сработало.
EDIT: ответ на первую часть моего вопроса (как диагностировать) был посмотрите на маршрутизацию машины, которая, если у вас возникли проблемы с подключением к сети, может оказаться хорошим местом для поиска.