Документ взят из кэша поисковой машины. Адрес оригинального документа : http://theory.sinp.msu.ru/pipermail/ru-ngi/2011q2/000193.html
Дата изменения: Mon Jun 20 18:40:33 2011
Дата индексирования: Tue Oct 2 03:03:23 2012
Кодировка:
[RU-NGI] Updates from epel repository

[RU-NGI] Updates from epel repository

Valery Mitsyn vvm at mammoth.jinr.ru
Sat Jun 18 20:03:58 MSD 2011


On Sat, 18 Jun 2011, Vladimir Tikhomirov wrote:

>   Добрый день еще раз.
>
> 18 июня 2011 г. 17:11 пользователь Valery Mitsyn <vvm at mammoth.jinr.ru>написал:
>
>> On Sat, 18 Jun 2011, Vladimir Tikhomirov wrote:
>>
>>   Добрый день.
>>> Произошло что-то непонятное: 10 июня в 11:53 МСК на всех Гридовских SLC5
>>> компьютерах обновились файлы в директории /etc/yum.repos.d, в том числе
>>> появился файл epel.repo, которого там быть не должно. И вот сегодня ночью
>>> произошел update (у меня настроен автоматический апдейт) пакетов из этого
>>> epel репозитория, который все порушил, по крайней мере, на WNs. Теперь
>>> там стоят какие-то неправильные пакеты из epel репозитория, которые
>>> замещают нужные пакеты из gLite.
>>> Вопросы:
>>> 1. Никто еще с этим не столкнулся?
>>> 2. Откуда могли взяться новые .repo файлы в /etc/yum.repos.d ? - я не вижу
>>> никаких объявлений об этом ни на SLC странице, ни в logwatch, ни в логах
>>> на самих компьютерах. И что нужно сделать, чтобы это безобразие больше не
>>> повторялось?
>>>
>>
>> epel.repo видимо появился из обновления yum-conf-5X-8.slc5,
>> где он с "enabled=1', хотя это весьма странно.
>> Чтобы не повторялось - надо запретить автоматический апдейт.
>>
>>
> Да, теперь понял: epel.repo и другие новые .repo файлы действительно
> принадлежат пакету yum-conf-5X-8.slc5.noarch.rpm, который заменил
> yum-conf-5X-6.slc5.cern.noarch.rpm только вчера, это просто сами .repo файлы
> внутри пакета от 10 июня.

  Это rpm сперва отлежался в testing положенное время, но похоже
никто его так и не проверил.

> Насчет запретить автоматический апдейт - не знаю, насколько это удобнее.
> Апдейты-то все равно проводить придется, по крайней мере - для gLite
> пакетов. Ну, запущу я yum update руками - результат все равно будет тот же.
>

  "yum upgrade", или даже "yum -y --tsflags=test upgrade" полезно
запустить сперва хотя бы на одной "типичной" конфигурации, посмотреть
на результат, потом уже делать на всех.
  В документации по установке glite специально указано, что
автоматический update надо запрещать.
  В EMI написано тоже самое про авто update. EPEL видимо попал
в SLC5.6 с учетом установки EMI, в котором EPEL надо разрешать,
а DAG запрещать. Хотя EPEL по моему мнению и опыту - большая
"свалка", как и всякая fedora, постоянно что-то обновляется и
перестает работать, или перестает работать что-то другое,
которое зависило от этого обновленного.

>
>
>>  3. Что делать собственно с проблемой? Напрашивается - снести все пакеты из
>>> репозитория epel, а потом - yum update. Можно ли одной командой снести все
>>> пакеты из данного репозитория? - я не умею. Или придется руками удалять
>>> каждый пакет?
>>>
>>
>> В /var/log есть файлы rpmpkgs, rpmpkgs.1 ..., каждый содержит
>> полный список rpm'ом в системе на дату создания этого файла.
>> Там же есть yum.log, можно достать информацию об обновлениях оттуда.
>> Потом надо делать "yum downgrade" со списком нужных rpm'ом и их
>> версий. Предварительно конечно поставьте "enabled=0" в epel.repo.
>>
>>
> Да, список апдейтнутых пакетов я получить могу. Просто думал, что можно
> как-то не перечислять все пакеты, а указать на репозиторий, типа : удалить
> все пакеты из epel.
> Кстати, downgrade не получается - некуда, ведь их раньше просто не было,
> напр.:
> yum downgrade dcap-libs-2.47.5-1.el5.x86_64
> ......
> Only Upgrade available on package: dcap-libs-2.47.5-1.el5.x86_64
> Nothing to do

  Конечно указывать надо не версию, которая сейчас стоит, а ту,
на которую надо делать downgrade.
  yum list all dcap-libs\*
покажет все доступные версии.

>
> Так что, видимо, нужно делать  yum remove. Но там еще зависимости
> цепляются... В общем, мрак.

  Ко всему прчему, наверное придется и yaim запускать после
всех downgrade'ов.

>  Всего наилучшего,
>  Владимир.
>
> P.S. В SLC часто встречались и продолжают встечаться подобные
>> ляпы, поэтому я уже давно перешел на SL, только некоторые
>> пакеты разрешено устанавливать из SLC и соответсвующем .repo.
>>
>>
>>   Заранее спасибо,
>>>  Владимир.
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> RU-NGI mailing list
>>> RU-NGI at theory.sinp.msu.ru
>>> http://theory.sinp.msu.ru/**mailman/listinfo/ru-ngi<http://theory.sinp.msu.ru/mailman/listinfo/ru-ngi>
>>>
>>>
>> --
>> Best regards,
>>  Valery Mitsyn

-- 
Best regards,
  Valery Mitsyn


More information about the RU-NGI mailing list