Развертывание локального репозитария

[ogri]

Требуется развернуть локальный репозитарий для нескольких дистрибутивов linux - Ubuntu, Fedora, CentOS. Объясните плиз, как это работает? Вэб сервер с rsync на официальный реп? можно ли развернуть дебьяновский apt-proxy на CentOS, для сокращения трафика, или лучше наоборот установить ubuntu server, а на нем развернуть createrepo rpm? поделитесь опытом, я смотрю на http://mirror.space.kz/ хостятся куча операционок, через вэб, а вот как mirror синхронизирует свои папки с оригинальными источниками?

[Vicpo]

я смотрю на http://mirror.space.kz/ хостятся куча операционок, через вэб, а вот как mirror синхронизирует свои папки с оригинальными источниками?

Все настроено

rsync на официальный реп

а отдается через веб и ftp сервера

[ValeryK]

и где будет экономия трафика при этом? поставь сквид на сервак, диск поболе для кеша, указать правила хранения rpm deb exe pdf и т.п. разрешить рамеры метров под 300 для них вот и будет экономия. получаем обновления, или делаем установку в любом дистре, пакеты кешируются сквидом, на другой комп тажже установка обновлений или просто установка идет уже из кеша, за секунды. а так нужны не нужны пакеты в репах, а рсинк все обновления гонит.

[ogri]

и где будет экономия трафика при этом? поставь сквид на сервак, диск поболе для кеша, указать правила хранения rpm deb exe pdf и т.п. разрешить рамеры метров под 300 для

и разрешить squid кэшировать файлы по 20Mb? это мощно...

экономия трафика будет в том, что тянется все один раз на одну машину (далее синхронизируются только различия в репах через rsync). Остальные 30 серверов датацентра обновляются уже не с инета, а с локального репа, а если учесть еще сотню-другую пользователей на бубунте и каждый ежедневно тянет одно и тоже... Вот тебе и "мегаэкономия" трафика. squid тут не спасет.

[B@F]

и разрешить squid кэшировать файлы по 20Mb? это мощно...

экономия трафика будет в том, что тянется все один раз на одну машину (далее синхронизируются только различия в репах через rsync). Остальные 30 серверов датацентра обновляются уже не с инета, а с локального репа, а если учесть еще сотню-другую пользователей на бубунте и каждый ежедневно тянет одно и тоже... Вот тебе и "мегаэкономия" трафика. squid тут не спасет.

Не скажу, что я очень хорошо разбираюсь, но недавно поднял дома squid3 и там спокойно можно указать файл и больше чем 20Мб. Так что думаю это реально. Тут дело в другом. В нете точно читал много статей по этому поводу (создание локального репозитория) просто огромная куча статей. Сам же я использую apt-proxy . На убунте довольно легко и просто настраивается и по умолчанию на сервере все работает, тока на клеенте sours.list правишь и все. А вот на счет rpm тут не скажу, но подразумеваю, что на шапочку будет не менее мощные штуки для этого дела. squid более универсален мне кажется, хотя я не уверен точнее не знаю, как работает его кеш, но думаю создали позаботились об этом.

[ValeryK]

и разрешить squid кэшировать файлы по 20Mb? это мощно...

экономия трафика будет в том, что тянется все один раз на одну машину (далее синхронизируются только различия в репах через rsync). Остальные 30 серверов датацентра обновляются уже не с инета, а с локального репа, а если учесть еще сотню-другую пользователей на бубунте и каждый ежедневно тянет одно и тоже... Вот тебе и "мегаэкономия" трафика. squid тут не спасет.

у меня на сквиде  стоит кешировать до 350 метров, иначе сауербратен и нексуиз не влазят. одна первая машина обновляется , остальные получают из кеша. Когда делается новая установка на комп, все проги стягиваются в секунды, тот же нексуиз. под кеш выделено 300 гигов, хватает за глаза.
а целый репозитарий выкачивать бессмысленно было-бы в данном случае.

[ValeryK]

кстати rpm тоже кешаться, частенько нужны установки rhel и к нему потом теже webmin и много чего. Так их тянем через wget , и получаем из кеша сквидовского. Сквид же чем замечателен в этом плане, что он отдает файл из кеша только в случае совпадения его с источником, если у источника будет более новый файл, то и сквид заменит его у себя.

[ogri]

под кеш выделено 300 гигов, хватает за глаза.
а целый репозитарий выкачивать бессмысленно было-бы в данном случае.

http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/blink.gif\' class=\'bbc_emoticon\' alt=\':blink:\' /> шайтанама... 300GB расточительно и дорого.
репозитарий CentOS занимает 7GB, так что полюбому лучше зеркало, чем такой дикий кэш - это раз!, два - зачем все серваки выпускать в инет? не секьюрно это как-то, особенно если они в каких-нибудь management сетях, дырку в фаерволе проковырял до своего зеркала и все.
вообщем ответа vicpo мне достаточно, у rpm-дистров нет инструмента наподобии apt-proxy, так что для зоопарка deb и rpm систем только зеркало с rsync, дальнейшую полемику считаю непродуктивной.

[ValeryK]

http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/blink.gif\' class=\'bbc_emoticon\' alt=\':blink:\' /> шайтанама... 300GB расточительно и дорого.
репозитарий CentOS занимает 7GB, так что полюбому лучше зеркало, чем такой дикий кэш - это раз!, два - зачем все серваки выпускать в инет? не секьюрно это как-то, особенно если они в каких-нибудь management сетях, дырку в фаерволе проковырял до своего зеркала и все.
вообщем ответа vicpo мне достаточно, у rpm-дистров нет инструмента наподобии apt-proxy, так что для зоопарка deb и rpm систем только зеркало с rsync, дальнейшую полемику считаю непродуктивной.

300G дискового пространства стоят на сегодня 3600 тенге, это раз (можно ограничится и 80-ю, я привел собственный пример), трафик по сравнению с полным зеркалом ниже в десятки раз, это два, какие серваки при этом выпускаем в инет, о чем вы? Сквид стоит за файерволом в локалке, кеширует http трафик по той самой "дырке" которая нужна для вэб-контента, так-что насчет секъюрности вы сказали ерунду.  И кеширует не только программные пакеты, но и всякую белиберду, и этой билеберды при этом оказывается около 10% из кеша ежемесячно по моей статистике. Я не навязываю вам мое мнение, просто форум просматривает много людей, которым мой опыт может и пригодится.

[B@F]

http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/blink.gif\' class=\'bbc_emoticon\' alt=\':blink:\' /> шайтанама... 300GB расточительно и дорого.
репозитарий CentOS занимает 7GB, так что полюбому лучше зеркало, чем такой дикий кэш - это раз!, два - зачем все серваки выпускать в инет? не секьюрно это как-то, особенно если они в каких-нибудь management сетях, дырку в фаерволе проковырял до своего зеркала и все.
вообщем ответа vicpo мне достаточно, у rpm-дистров нет инструмента наподобии apt-proxy, так что для зоопарка deb и rpm систем только зеркало с rsync, дальнейшую полемику считаю непродуктивной.

А зачем тебе 300 гигов или зачем 7 гигов, будут храниться только файлы, которые были скачены каким-то одним компом. Тебе же не нужно все зеркало, т.к. большая часть пакетов тебе не нужна. Твои 30 серверов работая на одной ОС и качающие одно и тоже будут вальготно себя чувствовать и при 50 гигах а может и меньше. Допустим ежедневные обновления той же убунту у меня не превышали 100М, это учитывая ядро и графические пакеты(оперу, дрова, твикеры) а на серваках графики обычно нет и обьем обновлений будет меньше. Ну а если решишь что-то установить большое все равно не будет больше 100М, мне так кажется. Вот и смотри какой кешь тебе нужен 300 гигов или 300 метров. Тебе же нужна экономия, а не полный репозиторий, зачем тебе качать ненужные пакеты. А apt-proxy делает то же самое, но только для deb, если только для этого то тоже пойдет, но не универсально получается как-то.


ValeryK скажи пожалуйста сколько кеша в мегабайтах у тебя используется реально при обновлении машин? Ну явно же не 300Г.

[ogri]

300G дискового пространства стоят на сегодня 3600 тенге, это раз (можно ограничится и 80-ю, я привел собственный пример), трафик по

Один 146GB SAS disk стоит 900$. я так понимаю, мы говорим о разных "гигабайтах", мне никто не разрешит запихнуть в датацентр писюк.
Насчет squid убедили, тоже вариант, возникает следующий вопрос, каким образом отделить "прокси для обновления" от "корпоративного прокси" у юзеров? так как у юзеров есть определенные пакеты ограничения доступа в инет, но возможности "неограниченного" обновления их лишать вроде бы тоже не желательно.

[ValeryK]

А зачем тебе 300 гигов или зачем 7 гигов, будут храниться только файлы, которые были скачены каким-то одним компом. Тебе же не нужно все зеркало, т.к. большая часть пакетов тебе не нужна. Твои 30 серверов работая на одной ОС и качающие одно и тоже будут вальготно себя чувствовать и при 50 гигах а может и меньше. Допустим ежедневные обновления той же убунту у меня не превышали 100М, это учитывая ядро и графические пакеты(оперу, дрова, твикеры) а на серваках графики обычно нет и обьем обновлений будет меньше. Ну а если решишь что-то установить большое все равно не будет больше 100М, мне так кажется. Вот и смотри какой кешь тебе нужен 300 гигов или 300 метров. Тебе же нужна экономия, а не полный репозиторий, зачем тебе качать ненужные пакеты. А apt-proxy делает то же самое, но только для deb, если только для этого то тоже пойдет, но не универсально получается как-то.


ValeryK скажи пожалуйста сколько кеша в мегабайтах у тебя используется реально при обновлении машин? Ну явно же не 300Г.

конечно не испульзуются 300 гигов, и для единичного файла в установках максимальный размер 350 мегабайт лишь потому, что в игре Nexuiz (и Sauerbraten) deb пакет с data весит где то 320 мегабайт  http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/rolleyes.gif\' class=\'bbc_emoticon\' alt=\':rolleyes:\' />  Можно и 80-ю гигами обойтись (на данный момент у нас 20гб кеша, накопленного за 2 месяца после переноса сквида на новый комп)), наверняка хватит, ведь после заполнения кеша (в настройках по дефолту) под 90% (по моей памяти) начнут удаляться наиболее старые пакеты, "вытесняемые" более свежим контентом.
А мой выбор в 300 гигов был прост, собрали новый комп для прокси сервера на асусовской мамке с процом на атоме интегрированном в майкроатх формфакторе, к ней малюсенький корпус наподобие кейс, диск на 500 гигов (ниже бессмысленно покупать, т.к. цена практически на падает) и дополнительную сетевую к имеющейся интегрированной. Установили опенсусе, на ней файервол, webmin, SQUID, lightSQUID (учет трафика по пользователям) апач нужный для lightSQUID, DNSmasq для кеширования днс запросов и резолвинга локальных адресов. Ну и куда было девать 500 гб диск в данном случае? вот и выделили 300 сквиду. Все удовольствие обошлось примерно тыс в 60 тенге.

[ValeryK]

Один 146GB SAS disk стоит 900$. я так понимаю, мы говорим о разных "гигабайтах", мне никто не разрешит запихнуть в датацентр писюк.
Насчет squid убедили, тоже вариант, возникает следующий вопрос, каким образом отделить "прокси для обновления" от "корпоративного прокси" у юзеров? так как у юзеров есть определенные пакеты ограничения доступа в инет, но возможности "неограниченного" обновления их лишать вроде бы тоже не желательно.

конечно в данном случае у нас разные гигабайты  http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/rolleyes.gif\' class=\'bbc_emoticon\' alt=\':rolleyes:\' /> . Тем более кэш будет "кошернее", и, мне кажется, вам чисто для обновлений для 2-3 дистров за глаза хватит и 20 гб (это будет меньше чем для зеркал, согласитесь). Ограничение пользователей как по контенту, так и по трафику замечательно умеет делать тот-же сквид, но не суть: отделить "прокси для обновления" от "корпоративного прокси" можно наверно несколькими способами, например завернув пакеты к серверам обновлений в файерволе на прокси со сквидом или пропускать весь трафик через сквид, а ему задать правила кешировать только то что пойдет на сервера обновлений , или весь трафик через сквид, кешируем только обновления (если надо только) и отправляем этот трафик на ваш gateway наружу, а остальной трафик на proxy который был корпоративный, это сквид умеет. Наверно еще много путей можно найти.

[B@F]

Один 146GB SAS disk стоит 900$. я так понимаю, мы говорим о разных "гигабайтах", мне никто не разрешит запихнуть в датацентр писюк.
Насчет squid убедили, тоже вариант, возникает следующий вопрос, каким образом отделить "прокси для обновления" от "корпоративного прокси" у юзеров? так как у юзеров есть определенные пакеты ограничения доступа в инет, но возможности "неограниченного" обновления их лишать вроде бы тоже не желательно.

Я говорю о гигабайтах на сервере на котором установлен прокси и который будет их кешировать и раздавать остальным по запросу. Я вообще не понял что в теме фигурируют разные гигабайты. В любом случаи из темы я понял, что если бы делал я, то я бы для кеша выделил 50 гигов, а может и меньше те же 20, ктр возможно потом и не заполнятся вовсе. Со временем конечно будет.

А зачем их отделять, пусть пользуются одним кешем, я думаю так даже лучше. Я бы настроил авторизацию по IP для серверов или по MAC и для серверов убрать ограничения на объем трафика оставив ограничение на скорость скачивания, хотя то же не обязательно, т.к. работа с ПО сервера наверняка производится ночью, по крайней мере я делаю так на серваках у себя, а ночью нормальные люди спят и серваки со своим обновлением им не помешают.

[ValeryK]

Я говорю о гигабайтах на сервере на котором установлен прокси и который будет их кешировать и раздавать остальным по запросу. Я вообще не понял что в теме фигурируют разные гигабайты.

B@F  http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/unsure.gif\' class=\'bbc_emoticon\' alt=\':unsure:\' /> тут получилось несколько юморно конечно, про гигабайты мы говорили все про одни и те-же "на сервере на котором установлен прокси" разность была в стоимости дискового пространства, У меня используется обычный sata HDD 500 Gb Seagate Barracuda стоимостью в 17тыс тенге, у ogri диск SAS (Serial attached SCSI) наверно в дисковом массиве и стоимостью 900$ за 146 Gb(вообщето на альфе они по 210 доларей, но все равно разница в стоимости гигабайта велика)

[B@F]

А Вы про деньги разговор ведете, это да разница хорошая, но это же не из своего кармана и если фирма хочет экономить то пусть экономит. А то у нас вроде бы все экономисты с высшим образованием, а экономику вообще не знаю. Почему-то они считают, что экономика это когда тратишь меньше, а на сомом деле экономика должна быть экономной. Но в любом случаи найти для кеша 20Гигов думаю должно быть реально. Тут главное идея, а её реализация может быть как угодно, все равно зеркало это будет и apt-proxy. Все это будет занимать место, а тут уже готовый прокси, практически ничего делать не надо, тока кеша больше дать и все.