Не мог Вытянуть Метаданные репозитория EPEL

Хорошо, начиная с изменения ENV TZ для date действительно кажется призыву корректным текущим временем в Ubuntu, это - по крайней мере, обходное решение (тот, на который я пытался не полагаться):

SHELL=/bin/bash

0 14 * * 1-5  [ $[10#$(date +\%H) - 10#$(TZ=":US/Eastern" date +\%H)] == 5 ] || sleep 3600; w;df

Таким образом, это имеет целью работать w;df в 9:00 ET с понедельника по пятницу. Вместо часа 15 я вставил 14 с возможностью сна одного часа (3 600 секунд) прежде, чем выполнить дальнейшие команды.

20
03.08.2014, 18:47
5 ответов

Если следующее не удается:

yum check-update

, но:

yum --disablerepo="epel"  check-update

работает, запустите:

URLGRABBER_DEBUG=1 yum check-update 2> debug.log

и проверьте debug.log на наличие:

PYCURL ERROR 77 - "Problem with the SSL CA cert (path? access rights?)"

Если это сообщение найдено, попробуйте:

yum --disablerepo="epel" reinstall ca-certificates

Если это не помогло решить проблему, вам может потребоваться обновить ваши CA-сертификаты:

yum --disablerepo="epel" update ca-certificates

Если это не помогло решить проблему, сделайте резервную копию вашего текущего сертификата CA:

cp /etc/pki/tls/certs/ca-bundle.crt /root/

и запустите:

curl http://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt

Explanation

Журнал показывает ошибку с сертификатами SSL вашей системы.

Пакет сертификатов CA в вашей системе мог быть каким-то образом поврежден, и приведенная выше команда yum -disablerepo = "epel" переустановите ca-сертификаты просто заменит ваш сертификат новой версией. Это вряд ли будет ответом, поскольку все другие репозитории работают - если бы были серьезные проблемы с SSL, все репозитории не работали бы.

Приведенная выше команда curl ... заменяет комплект сертификатов CA вашей системы более новой версией. Пакет сертификатов CA содержит все корневые сертификаты CA, которым доверяет ваша система.

В этом случае в репозитории EPEL есть новые сертификаты SSL (подписанные новым корневым центром сертификации), которым ваша система не доверяет. Репозитории CentOS продолжают работать со своими немного более старыми сертификатами.

20
27.01.2020, 19:43

Исходные пакеты, использующие autotools - ./configure; изготовить; make install - обычно имеется цель make uninstall . Однако этот целевой объект не существует до запуска ./configure (потому что на самом деле нет makefile), поэтому если вы получите ошибку:

make: *** No rule to make target 'uninstall'. Stop.

Это, вероятно, проблема. Это может быть подтверждено попыткой сделать ; если вы получаете make: * * * Цели не указаны и makefile не найден. Стоп. , то makefile отсутствует, поскольку ./configure не был успешно запущен.

При использовании нового извлечения исходного пакета для удаления, вероятно, не очень важно, чтобы параметры ./configure не совпадали с исходным построением (за исключением целевых каталогов, которые, очевидно, должны быть одинаковыми) но было бы хорошо попытаться сблизиться, если вы можете вспомнить их.

Я также думаю, что установка программы с помощью checkinstall, а затем удаление ее с помощью синаптики или apt-get или любого менеджера пакетов будет подходящим, верно?

Я не использовал checkinstall сам, но это, безусловно, выглядит хорошей идеей и кажется явно полезным в удалении вещей, если вы использовали его в первую очередь. Насколько я могу судить, это актуально только для derived distros debian (таких как ubuntu).

Библиотека imgdisplay -121--230403-

w3m может отображать изображения напрямую. Он работает только на некоторых терминальных эмуляторах, таких как Xterm и URxvt.

ranger - это браузер файлов, который использует библиотеку для отображения предварительного просмотра. Добавьте его в файл конфигурации рейнджера, чтобы включить функцию:

set preview_images true
-121--634-

Проблема в том, что пакет nss слишком старый. Эта старая версия не может взаимодействовать с сайтом Fedora через завитки , который использует более старую версию библиотеки nss.

Просто обновите свою версию nss до последней, она решает проблему с обновлением репо EPEL:

$ sudo yum clean all 
$ sudo yum --disablerepo="epel" update nss

ПРИМЕЧАНИЕ: эта версия nss-3.14.3-4.el6 _ 4 .x86 _ 64 прекрасно работает с репозиторием EPEL.

33
27.01.2020, 19:43

Я использую fdisk.

Если вы знаете, какие подсказки он дает, вы можете поместить ответы в файл и использовать их для ввода в fdisk.

-121--210026-

Проблема заключается в том, что cron не знает о вашем сеансе входа в систему.

Если сценарий не работает с системной консоли ( ctrl-alt-f1 ), он определенно работает с cron.

Если вы хотите автоматизировать GUI, то, вероятно, вместо cron следует использовать dscheduler на основе GUI.

-121--230081-

У меня была та же проблема и я исправил ее, изменив https на простой http .

Это не идеальное решение, но может быть достойным решением в зависимости от ваших потребностей в безопасности.

2
27.01.2020, 19:43

У меня была такая же проблема, попробовала все вышеперечисленные шаги. Выяснил, насколько глупый я был, потому что я пытался установить, без вошении в корне. Даже ты мой счет имел доступ Sudo.

sudo yum remove epel-release

su root

sudo yum install epel-release

Исправлены мои вопросы на CentOS 7

0
27.01.2020, 19:43

У меня была такая же ошибка при работе за корпоративным прокси. Обновление сертификатов или использование http не помогало. Чтобы исправить это, мне пришлось добавить настройку прокси в каждый из репо epel:

for x in /etc/yum.repos.d/epel*; do sed -i '/^\[/ a proxy=http://YOUR.PROXY.HERE:8080' $x; done

Вставьте, конечно, свои собственные данные о прокси.

Теперь мои файлы репо выглядят так:

[epel]
proxy=http://YOUR.PROXY.HERE:8080
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

[epel-debuginfo]
proxy=http://YOUR.PROXY.HERE:8080
...
4
27.01.2020, 19:43

Теги

Похожие вопросы