Привет всем.Кратко: нужен http-proxy понимающий yum-специфику.
Подробно:
Есть около десятка систем (в т.ч. виртуальных) на CentOS 5, когда выходит очередная порция обновлений (особенно типа обновления на 5.4) выкачиваение rpm-пакетов неслабо загружает канал. Если делать кажду систему по очереди, то это растягивается на полдня и тоже загружает канал все это время, хоть и не так сильно. Попытка проксировать через squid дала слабые результаты, т.к. при малейшей проблеме в сети yum переключается на другое зеркало, с другим адресом файла, что полностью ... делает непригодной идею кэширования. Видел, что для apt-get есть спец. прокси, который понимает что к чему и экономит трафик и полосу, хотелось бы найти такое же, только для yum.Примечания:
a) Сам прокси для apt-get не нашел, но вроде помню что он yum не поддерживал.
b) Spacewalk смотрел, но там слишком все монстроидально + Oracle нужен -- не для моего кол-ва машин.
c) Заводить локальный репозиторий не хочется, т.к. придется качать очень много ненужных пакетов (опять грузить канал).Ну вот, собственно, может кто что вспомнит? В гугле ничего найти не удалось...
>[оверквотинг удален]
>Примечания:
>a) Сам прокси для apt-get не нашел, но вроде помню что он
>yum не поддерживал.
>b) Spacewalk смотрел, но там слишком все монстроидально + Oracle нужен
>-- не для моего кол-ва машин.
>c) Заводить локальный репозиторий не хочется, т.к. придется качать очень много ненужных
>пакетов (опять грузить канал).
>
>Ну вот, собственно, может кто что вспомнит? В гугле ничего найти не
>удалось...
а локальный репозитарий замутить не судьба? тем более столько серваков.
Я, при наличии 3-4, уже делаю локальный репозитарий на одном из них, он синхронизируется раз в сутки, ночью. Все остальное уже тянеться с него.
Читайте внимательно, в начальном же посте указана достаточно веская причина почему автор не хочет делать локальный репозитарий. Ну и не стоит думать что все остальные тоже работают в офисах, где ночью никого нет и как следствие никакой нагрузки. Есть ведь и серьезное администрирование ;)
>b) Spacewalk смотрел, но там слишком все монстроидально + Oracle нужен
>-- не для моего кол-ва машин.Я бы все-таки поставила Spacewalk. В нем как раз очень удобный менеджмент безопасности, всегда можно знать, какой пакет на какой системе уязвим.
Они сейчас мигрируют на постгресс, какое-то время можно на бесплатном Оракле перекантоваться.
Что меня (лично) в нем напрягает, так это то, что он не UNIX-way, и немного душит жаба за оперативку: просто жалко на менеджмент отдавать 3-4 Гб.На полутора гигабайтах на тестовой инсталяции он работает, но так как на гигабайте он постоянно падает с out of memory, стоит прислушаться к рекомендацим разработчиков, что автоматически означает очень существенную часть ресурсов физического сервера под одну виртуалку с менеджментом.
Для очень больших сетей это must have, для Вашего маштаба, конечно, "монструозность" большой минус.
>
>>b) Spacewalk смотрел, но там слишком все монстроидально + Oracle нужен
>>-- не для моего кол-ва машин.
>
>Я бы все-таки поставила Spacewalk. В нем как раз очень удобный менеджмент
>безопасности, всегда можно знать, какой пакет на какой системе уязвим.
>Они сейчас мигрируют на постгресс, какое-то время можно на бесплатном Оракле перекантоваться.Судя из ответа на их сайте
Why do you use Oracle? Any plans for supporting other databases? ¶
Originally the Spacewalk code base was used as a hosted application and Oracle was a good choice for a hosted application in 2001. Over the years open source databases such as PostgreSQL and MySQL have improved tremendously in terms of stability, speed, and scalability. We have not had the resources allocated in the past to add support for an open source database but want to do so soon.
неизвестно вообще перейдут они или нет :)
>[оверквотинг удален]
>
>Originally the Spacewalk code base was used as a hosted application and
>Oracle was a good choice for a hosted application in 2001.
>Over the years open source databases such as PostgreSQL and MySQL
>have improved tremendously in terms of stability, speed, and scalability. We
>have not had the resources allocated in the past to add
>support for an open source database but want to do so
>soon.
>
>неизвестно вообще перейдут они или нет :)Перейдут, в рассылке активно обсуждается, + смотрите роадмап.
+ вспомните новость про то, что RHT стал инвестором EnterpriseDB, в интересах RH, что бы Sattelite был и на Postgre
Слiпий казав - Побачим :)Вообще интересная вещь, но вот наличие 4 Гб памяти и необходимость в Oracle отталкивает
>Слiпий казав - Побачим :)
>
>Вообще интересная вещь, но вот наличие 4 Гб памяти и необходимость в
>Oracle отталкиваетМеня тоже, как и не-UNIX-way специфика организации решения. Но я больше не знаю каких-либо OSS альтернатив для мониторинга и установки пакетов для _большого_ числа хостов.
Тот же puppet может ставить rpm-ки из локального или внешнего репозитория, но вот специальной БД, где бы хранились rpm-ки, установленные на каждом хосте, там нет.
Можно ставить только то, что знаешь, что нужно установить.Spacewalk/Sattelite дает возможность развести некое количество нестандарта на нодах проекта, и не позволит забыть, где что стоит :))
На сайте федоры есть ссылка на проект IntelligentMirror (https://fedorahosted.org/intelligentmirror/) судя по описанию вроде близко к тому что вам нужно.
>На сайте федоры есть ссылка на проект IntelligentMirror (https://fedorahosted.org/intelligentmirror/) судя по описанию
>вроде близко к тому что вам нужно.Да, спасибо, я уже вышел на него по предыдущей ссылке (в комментариях было), сейчас разбираюсь что это, но если будут еще варианты -- не откажусь ;)