LINUX.ORG.RU

Экономное зеркалирование репозитариев Linux


0

1

Когда на предприятии требуется обновлять множество Linux машин, как правило, создают полные зеркала репозитариев, что требует загрузки большого объема данных. Однако в большинстве случаев все пакеты из репозитария не нужны, т.е. при классическом зеркалировании происходит загрузка ненужных пакетов, что "ударяет" по кошельку предприятия.

Для создания "экономных" зеркал репозитариев предлагается использовать сетевую виртуальную файловую систему с кешированием - LftpFS. Она основана на FUSE и всем известном консольном клиенте LFTP, который поддерживает необходимые протоколы FTP, HTTP и работает через различные виды прокси-серверов.

Технология следующая: монтируем каталог репозитария посредством LftpFS (см. документацию), настраиваем доступ по FTP в этот каталог для Linux машин, ну и настраиваем обновление машин с этого ресурса.

В итоге: все машины видят листинг репозитария и загружают только необходимые пакеты, при этом загрузка пакетов происходит один раз с учетом кэширования. Экономия на лицо!

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

Ну как я понял господин r хочет донести до всех следующий трабл:

Условия - канал медленный и падучий.

Мы зеркалируем список файлов. Дальше 1-й клиент лезет за обновлением. Зеркало начинает тянуть копию файла себе в кэш. В этот момент залезет клиент 2 и тоже попытается скачать тот-же файл. Зеркало (ежели оно тупое) увидит, что в кэше такого файла нет и поднимит 2-ю сессию скачивания файла... И т.д. короче когда законнектятся все клиентымы получим количество скачанных файлов равным количеству клиентов.

Если это так - то очень простой выход из положения. Расписание обновлений - сначала последовательно 1 машина потом еще одна и так далее после 10- вероятно все уже будет в кеше.

На быстром но дорогом канале файлы качаюбтся быстро и мы можем ну в 2-3 раза по стоимости попасть но не во столько раз сколько машин в сети (если зеркала нет).

Я не знаю как в этом случае ведет себя apt-proxy. Опять-же непонятно что сделает это зеркало в случае пропадения файлов в родительском репозитории. Не понятно как оно поймет если пакет не сменил имени, но обновился (apt-proxy видит это из packages.gz)...

Вобщем если откинуть агрессивные наезды что если не можешь спалит 100$ просто так то ты неудачнег, смысл в его словах есть.

Однако даже при 2-х машинах и анлиме apt-proxy имеет смысл. Смысл такой, что 1) канал утилизируется 1 раз. 2) у меня всегда остаются локальные копии пакетов, которые я могу и на болванку записать и это уже не раз помогало.

demmsnt
()
Ответ на: комментарий от AVL2

>Заказывать, мучаться с оплатой, отслеживать доставку, ждать курьера или бегать на почту. Зачем, когда есть инет?

Он же у тебя супердорогой, на острове и спутник постоянно топится в океяне так?

Вы уже решите наконец - или у вас с инетом проблемы или нет.

>Народ хочет данные on-demand, но без повторной загрузки.

Где в зеркале повторная загрузка?

r ★★★★★
()

наверное про дебиановский apt-proxy или approx уже говорили? повторять тогда не буду :)

alt0v14 ★★★
()
Ответ на: комментарий от demmsnt

>Ну как я понял господин r хочет донести до всех следующий трабл:

Не совсем. Я просто возражаю против этого как против замены зеркала. ЗЕркало создается локальным с быстрым доступом. Если обновлятся с удаленных источников то в случае упомянутого голимого канала во время обновления софта машина грубо говоря работать не будет. То есть человек на ней работающий ничего не делает - простаивает. Альтернативный вариант - админ делает это в нерабочее время. Сверхурочные админу. + Набор всяких побочных критериев - дерьмовый канал отваливается посредине апдейта - что дальше? Всему вообще пипец, а админа шеф отимеет. Или начинает плужить, спутник нырнул.

Локальное зеркало делается именно для организации _доступного_ (во всех смыслах) источника. Данное решение - делает источником _удаленный сервак_. Следовательно это не решение о замене зеркала, которое как раз и организуется при проблемном доступе. Это может быть решение для небольшого количества машинок и очень стабильном быстром канале. Иначе сэкономив на трафике мы теряем в рабочем времени всей компании и вообещ переходим на более рискованный вариант работы.

r ★★★★★
()
Ответ на: комментарий от r

>Зеркало не нужно.

да они сами решат, надо оно им или нет.

Предложеное решение интересно и тем, у кого хороший, быстрый канал и тем, у кого он плохой. Кому-то оно экономит трафик, кому-то - время, а многим и то и другое со всеми производными.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>Предложеное решение интересно и тем, у кого хороший, быстрый канал и тем, у кого он плохой. Кому-то оно экономит трафик, кому-то - время, а многим и то и другое со всеми производными.

С этим никто и не спорил. Эта штука хороша как альтернатива _прямому апдейту с удаленного репозитария_. А не как замена зеркалу. О чем я и говорю.

r ★★★★★
()
Ответ на: комментарий от r

>Он же у тебя супердорогой, на острове и спутник постоянно топится в океяне так?

нет. я уже писал, что у меня балансировка на два быстрых анлим канала.

>Где в зеркале повторная загрузка?

в зеркале очень много лишнего трафика. при этом зеркало все равно отстает от основного репозитария.

AVL2 ★★★★★
()
Ответ на: комментарий от r

зеркало, это тоже альтернатива прямому апдейту с удаленного репозитария.

то есть это две альтернативы, где то дополняющие, а где то заменяющие друг-друга.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>то есть это две альтернативы, где то дополняющие, а где то заменяющие друг-друга.

Только никто у кого было зеркало не заменит его на эту штуку. Будешь спорить с этим утверждением в статистическом смысле?

r ★★★★★
()
Ответ на: комментарий от r

>во время обновления софта машина грубо говоря работать не будет.

4.2

прекрасно работает. или ты про однозадачную винду?

>То есть человек на ней работающий ничего не делает - простаивает

даже если принять на веру первый пункт, все равно 4.2.

может быть и другой компьютер, работа не ограничивается компьютером и т.д.

>админ делает это в нерабочее время. Сверхурочные админу.

man at,cron?

>дерьмовый канал отваливается посредине апдейта - что дальше? Всему вообще пипец, а админа шеф отимеет. Или начинает плужить, спутник нырнул.

man bash, man rpm

от того, что апдейт пройдет сутками позже все накроется? ядреная станция на дежурстве? ;)

AVL2 ★★★★★
()
Ответ на: комментарий от r

> Ага - на локальных линкс-десктопах. Им очень важны эти проблемы безопасности в апаче и пыхе.

Проблемы краша прикладных утилит важны. Или добавления функционала.

Поставим вопрос по-другому. Нужно оперативно обновлять/устанавливать софт на некотором кол-ве типовых машин. Как это сделать?

Можно не обновлять или бегать на почту за дисками. Можно качать пакеты для каждой машины N раз. Можно сделать зеркало и обновлять даже то, что не используешь. Можно сделать `срез` зеркала и обновлять только реально используемые пакеты.

Мне симпатичны последние 2 варианта. Четвертый более всех. И subj позволяет в той или иной степени это реализовать. Если есть идея как это сделать альтернативным способом (а ведь есть, и неплохие), то пожалуйста. Ежели дальше бредить, то более с вами на эту тему спорить не собираюсь.

skwish ★★
()
Ответ на: комментарий от r

>Только никто у кого было зеркало не заменит его на эту штуку. Будешь спорить с этим утверждением в статистическом смысле?

я очень долгое время держал зеркало целого ряда дистров. И прекрасно знаю, что это такое.

Основные проблемы зеркала:

1) отставание от источника. Из за этого никаким зеркалом нельзя пользоваться вслепую.

2) невалидность зеркала из за ошибок синхронизации или синхронизации с временно невылидным источником. Из за этого зеркало гораздо дольше находится в нерабочем состоянии, чем источник.

3) большой объем трафика, причем невостребованного трафика.

4) сложность оптимизации. Например, мне не нужен kde. Я не зеркалирую все kd*, но кто сказал, что мне это вообще никогда не понадобится? Недавно я подключил девелоперски репозитарий fc9 ради rsync3 и gnome-do. мне теперь зеркалировать еще 5 гигов этого репозитария или отказаться от оптимизации этого трафика?

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

Теперь берем lftpfs и организуем тоже самое зеркало.

1) отставания нет. Если файлы в источнике обновились, зеркало отдаст их, пусть на первый раз и с меньшей скоростью.

2) время неработоспособности зеркала не превышает время неработоспособности источника. Как только источник починили - файлы изменились - зеркало их взяло.

3) трафик только востребованый.

4) Оптимизация проста как валенок.

а)Включаем все, что хотим зеркалировать.

б) ту часть, которую мы считаем необходимым иметь всегда под рукой, синхронизируем по расписанию. Расписание может быть сколь угодно редким, потому что все равно в случае обновления источника клиент получит свежак.

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

AVL2 ★★★★★
()
Ответ на: комментарий от r

> 3. Надо апдейтить OOo + FF + TB - ~200MB. > 4. На машине бухгалтерии есть этот OOo, ему говорят update и оно качается 5 часов. В это время бухгалтер бьет баклуши.

Да вроде вы раньше были адекватней. Пока апдейтится OO бухгалтер работает в старом. Даже когда проапдейтится бухгалтер это заметит после перезапуска приложения.

Это как же люди ядра апдейтят по вашей логике? При выключеном компе что ли?

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

skwish ★★
()
Ответ на: комментарий от AVL2

>прекрасно работает. или ты про однозадачную винду?

Серьезно? В то время как загрузилась половонина пакетов OOo а вторая не загрузилась? Какой у тебя дистр? Я тоже хочу дистр который временно может сэмулировать отсутствующие зависимости пока они не загрузятся.

>даже если принять на веру первый пункт, все равно 4.2.

Ага - давай - давай расскажи как клево будет работать софт который зависит от библиотек окторые сейчас альтерятся.

>может быть и другой компьютер, работа не ограничивается компьютером и т.д.

Ахрененно на инете сэкономили да?

>man at,cron?

Сурьезно? Обновление офисных рабочих машин для юзеров типа "неквалифицированный ITщник" по крону непроверенными пакетами с удаленного репозитария? Это 5!

Ты не путаешь обновление на машинке квалифицированного айтишника (типа сисадмин, программист) который если дообновляется до полной неработоспособности ситемы - плакать не пойдет, а все разрулит сам, и бухгалтера у которого "internet незапускаицца"?

>man bash, man rpm

Ты или никогда не обновлялся или хрен его знает. В репозитории все есть, dependency check проходит - начинаем качать и инсталить download (apply xdelta?) install, download (apply xdelta?) install, download (apply xdelta?) install, download... could not connect.

Или у тебя RPM уже рекаверить проблемы с сетью научился?

>от того, что апдейт пройдет сутками позже все накроется? ядреная станция на дежурстве? ;)

Нет - накроется например опеноффис - если его выползти успела всего половина, а полз он не одним мегапакетом.

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

r ★★★★★
()
Ответ на: комментарий от r

> С этим никто и не спорил. Эта штука хороша как альтернатива _прямому апдейту с удаленного репозитария_. А не как замена зеркалу. О чем я и говорю.

Это не замена зеркалу. Речь изначально шла про обновления (читать новость). И рассматривалось, что как один из вариантов - зеркало, как другой - хранить только срез зеркала.

skwish ★★
()
Ответ на: комментарий от r

r Вы либо пользуетесь чем-то жудко старым или врете. Я лично обновлял Ubuntu начиная с 5.10 до 7.10 И ни разу, в процессе обновления мне не пришлось сидеть бить баклуши. Очень забавно наблюдать как мигнул гном и все иконки сменились. или как фаерфокс заявил что он был (не фаерфокс, а APT) обновлен и не соизволю-ли я выйти и зати снова.

Когда я говорю apt-get install APT сначал выкачает ВСЕ необходимые пакеты и только потом их начнет ставить... Тоесть если зеркало затормозится - так, как пакет далеко, пользователь это не заметит нифига

demmsnt
()
Ответ на: комментарий от AVL2

>Основные проблемы зеркала:

1) нерелевантно - это твое зеркало и обновляешь ты тоже себя.

2) аналогично.

3) значит тебе зеркало нек нужно.

>1) отставания нет. Если файлы в источнике обновились, зеркало отдаст их, пусть на первый раз и с меньшей скоростью.

Это один иж важнейших факторов почему зеркала вообще делаются. Ты об этом не думал?

>2) время неработоспособности зеркала не превышает время неработоспособности источника.

Переформулирую по другому - неработоспособность твоего зеркала полностью совпадает с неработоспособностью / загруженностью источника.

Та же самая причина почему зеркала вообще делают. На nvidia зепозитария для драйверов для новеловских дситров перманентно уходил в даун - обновляться вообще был страшный гемор. С зеркалом таких проблем нет. Далее украинское зеркало openSUSE 10.3 в прошлом месяце вдруг исчезло - вот и ппц твоему истонику. Перманентный. А так бы у тебя было свое зеркало - и все бы работало.

Еще одна причина держать свое зеркало - _независимость_ от стабильности источника.

>3) трафик только востребованый.

Более нестабильное обновление. Надо организовывать политики обновления всего офиса с удаленного репозитария, вместо того чтобы проводить полностью подконтрольные обновления с подконтрольного репозитария.

r ★★★★★
()
Ответ на: комментарий от r

> Серьезно? В то время как загрузилась половонина пакетов OOo а вторая не загрузилась? Какой у тебя дистр? Я тоже хочу дистр который временно может сэмулировать отсутствующие зависимости пока они не загрузятся.

А вот это лишнее. Пока весь требуемый пакет с зависимостями не загрузится и поставится транзакция не пройдет. В это время все сидят за старым офисом и работают.

skwish ★★
()
Ответ на: комментарий от r

>Серьезно? В то время как загрузилась половонина пакетов OOo а вторая не загрузилась? Какой у тебя дистр? Я тоже хочу дистр который временно может сэмулировать отсутствующие зависимости пока они не загрузятся.

федора, дебиан и другие, использующие апт или yum.

сначала грузятся все пакеты в /var/cache/[yum;apt], затем все ставятся.

>Ага - давай - давай расскажи как клево будет работать софт который зависит от библиотек окторые сейчас альтерятся.

см выше.

Во вторых, почитай, как удаляются/обновляются файлы в линуксе. Пока приложение использует библиотеку, она не будет физически удалена, пока приложение ее не освободит. Так что пока не перезапустишь опенофис - будет работать старый вариант, пусть половина уже переписана.

>Ахрененно на инете сэкономили да?

ну это все равно заметно быстрее, чем по почте, а других альтернатив может и не быть...

>Сурьезно? Обновление офисных рабочих машин для юзеров типа "неквалифицированный ITщник" по крону непроверенными пакетами с удаленного репозитария? Это 5!

Во первых, зачем сразу обновление? man apt на предмет опций download-only. Для yum придется взять список, чего он там запросил и поставить в очередь самому.

во вторых, от того, что ты отзеркалировал "по крону непроверенными пакетами с удаленного репозитария", они сразу стали проверенными? в чем разница с полным локальным зеркалом, кроме того, что зеркало может быть еще и перекошенным?

AVL2 ★★★★★
()
Ответ на: комментарий от skwish

>Да вроде вы раньше были адекватней. Пока апдейтится OO бухгалтер работает в старом. Даже когда проапдейтится бухгалтер это заметит после перезапуска приложения.

У вас наверное какой-то /dev/mystic присутствует в системе. Если у вас не загружены _все библиотеки_ у память (например открыт и writer и base) и в это время произошло обновление - получите неописуемый фан несовместимых бинарников при догрузке запуска например base когда врайтер уже запущен. Только не говорити что не видели как рушатся во время апдейта уже запущенные многопакетные приложения типа ooo, seamonkey и t.d.

>Это как же люди ядра апдейтят по вашей логике? При выключеном компе что ли?

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

r ★★★★★
()
Ответ на: комментарий от demmsnt

>Вы либо пользуетесь чем-то жудко старым или врете. Я лично обновлял Ubuntu начиная с 5.10 до 7.10 И ни разу, в процессе обновления мне не пришлось сидеть бить баклуши.

И не надо - вы работаете в системе которая находится в unstable состоянии. Не раз и не два улетал например Seamonkey который апдейтится тучей пакетов если апдейт происходит во время его работы. Я тоже не уходил покурить - я перезапускал обезьяну. А еще замечательно происходит когда обновляется например dbus или ядерные кедовские либы. Происходит все что угодно вплоть до отказа приложений запускаться через klauncher. Так что это либо вы беспробудно врете либо одно из двух.

>не соизволю-ли я выйти и зати снова.

ЗАбавно - а зачем это делать вам в голову не приходила мысль подумать? Вот подумайте.

r ★★★★★
()
Ответ на: комментарий от r

>Переформулирую по другому - неработоспособность твоего зеркала полностью совпадает с неработоспособностью / загруженностью источника.

не так.

Зеркало работает независимо. Источник нужен только в моменты обновления на нем файлов.Собственно, как и в обычном зеркале.

>Это один иж важнейших факторов почему зеркала вообще делаются. Ты об этом не думал?

Если зеркало файлы отдает в лучшем случае только один раз - оно не нужно.

>Еще одна причина держать свое зеркало - _независимость_ от стабильности источника.

Зависимость все равно остается. Новых файлов не получишь.

AVL2 ★★★★★
()
Ответ на: комментарий от skwish

>А вот это лишнее. Пока весь требуемый пакет с зависимостями не загрузится и поставится транзакция не пройдет. В это время все сидят за старым офисом и работают.

Ты что - вообще не понимаешь как работает загрузка приложения с разделяемыми библиотеками? При чему тут транзакция обновления? У тебя уже половина в мамяти, а вторая только что сменилась. Ты за стабильность уже запущенного приложения отвечаешь? С ума сойти какую фантастику вы сейчас рассказываете.

r ★★★★★
()
Ответ на: комментарий от AcidumIrae

>если предприятие, не может себе позволить потрать $500-$1000 в месяц на инет - это не предприятие, а что-то иное

При цене по рублю за метр это 500-1000 мб. У нас с одного компа больше в меняц улетает. А компов штук 30 на этаже. А этажей 5*4 корпуса. Так кого ты назвал мелким предприятием?

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от AVL2

>о вторых, почитай, как удаляются/обновляются файлы в линуксе. Пока приложение использует библиотеку, она не будет физически удалена, пока приложение ее не освободит. Так что пока не перезапустишь опенофис - будет работать старый вариант, пусть половина уже переписана.

Это _если_ он уже открыл файл. А если нет? Ты когда статруешь большое приложение типа симанки или ооо оно сразу все в память грузится? Ты уверен?

>ну это все равно заметно быстрее, чем по почте, а других альтернатив может и не быть...

Обновление должно происходит без остановки производства. Это одна из причин почему большие конторы вообще держат зеркала, а не обновляются с норвежского рыболовецкого судна в течении 2х суток.

>во вторых, от того, что ты отзеркалировал "по крону непроверенными пакетами с удаленного репозитария", они сразу стали проверенными?

Нет. Когда зеркало обновилось - он все еще закрыто для локальных обновлений. Админ обновился проверил, что все пашет, iptables allow, и все обновились на гарантировано стабилные версии. А не пришли утром и обнаружили что у них по крону кеды4 стоят и админ бегает с безумными глазами пытаясь все вернуть в работоспособное состояние.

r ★★★★★
()
Ответ на: комментарий от r

ну мы уже разобрались, что пока все файлы не скачаются, обновление не начнется?

То есть речь идет о тех считанных минутах, пока ставятся локальные пакеты и сеть вообще не нужна?

AVL2 ★★★★★
()
Ответ на: комментарий от r

Понятно, что нестабильное. Но зеркало или нет это роли не играет. Обновляются пакеты и он обновится только когда ВСЕ зависимости выкачает. Это раз. Два это, то, что при ПОЛНОМ апгрейде дистрибутива я получил только одну просьбу. Я считаю это великолепно. А вот при апгрейде какихнибудь man или unzip я вообще этого не замечу. А желать апгрейд такой надо. Вобщем в 99% бух ничего и не узнает.

demmsnt
()
Ответ на: комментарий от r

> Нет. Когда зеркало обновилось - он все еще закрыто для локальных обновлений. Админ обновился проверил, что все пашет, iptables allow, и все обновились на гарантировано стабилные версии. А не пришли утром и обнаружили что у них по крону кеды4 стоят и админ бегает с безумными глазами пытаясь все вернуть в работоспособное состояние.

Ну это уже другой уровень. Ежели на предприятии сидит админ, который в состоянии проверить весь репозитарий на работоспособность, то такому предприятию лишняя пара сотен гиг в месяц трафика - не помеха... ;)

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>Зеркало работает независимо. Источник нужен только в моменты обновления на нем файлов.Собственно, как и в обычном зеркале.

Нет. В зеркале все есть всегда - на то оно и зеркало. А в кеше только то что закешировано. Все что не закешировано - зависит от стабилности внешнего зеркала.

>Если зеркало файлы отдает в лучшем случае только один раз - оно не нужно.

Если оин раз - даже кеш не нужен:) ? А если сотня машин - подумай 2 раза.

>Зависимость все равно остается. Новых файлов не получишь.

ЗАвисимость обновления _зеркала_ а не офиса. Офис останется на необновленной системе пока не обновится зеркало. А так будут просто ругаться и материться юзерские тачки на тему cannot connect, could not update.

r ★★★★★
()
Ответ на: комментарий от r

> Ты что - вообще не понимаешь как работает загрузка приложения с разделяемыми библиотеками? При чему тут транзакция обновления? У тебя уже половина в мамяти, а вторая только что сменилась. Ты за стабильность уже запущенного приложения отвечаешь? С ума сойти какую фантастику вы сейчас рассказываете.

Под дурачка косишь? У нас в обоих случаях есть работающий офис. Мы обновили в нем все пакеты с зависимостями. И что? То что мы использовали зеркало нам чем то поможет? Да та же самая ситуация.

skwish ★★
()
Ответ на: комментарий от r

>Если оин раз - даже кеш не нужен:) ? А если сотня машин - подумай 2 раза.

а тогда как раз и полезно зеркалить on-demand. Хрен их знает, чего им понадобится завтра, но 99 машин будет работать с кешом, а одна подождет...

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

>То есть речь идет о тех считанных минутах, пока ставятся локальные пакеты и сеть вообще не нужна?

Обновление в yast происходит последовательно, а не атомарно :(.

Во вторых ты пока изложил противоречивый сценарий - с одной стороны у тебя apt download-only - ты потом будешь бегать по тачкам и все ставить?

r ★★★★★
()
Ответ на: комментарий от r

гы интересно - эта штука - это FS. как ообще сеяб поведет mount этого дела если источник недоступен? ;))

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

r ★★★★★
()
Ответ на: комментарий от r

Короче разговор слепого с глухим... Дело в том, что у пакета есть мантэйнер. Этот могучий человек и пишет скрипты обновления пакета. Так вот этот матерый человечище почемуто на лету ниразу не подменял ядро. Конечно есть важные либы и прочее, что походу фиг обновишь. Но еще раз даже при 100% обновлении системы я только 1 сообщение увидел. Ну какого черта на машине появится 4-й KDE вместо 3.5? это разные пакеты.

И вообще какое это все имеет отношение к зеркалу или кеширующему прокси. Зеркало всегда доступно? Да по вашей логике я щас стек обновлю, выкачаю половину пакетов начну ставить сетевая подсистема ляжет, а вотрую часть мне пушкин по телепатическому сенасу передавать будет???

Во огороде бузина, в Киеве дядька

demmsnt
()
Ответ на: комментарий от demmsnt

>И вообще какое это все имеет отношение к зеркалу или кеширующему прокси. Зеркало всегда доступно?

Упомянутое? Оно локально.

r ★★★★★
()
Ответ на: комментарий от anonymous

>Да хватит уже этого тролля кормить, уже не смешно и не итренесно читать его бред.

Ты уже поставил этот fs вместо зеркала? Нет? Теоретик хренов.

r ★★★★★
()
Ответ на: комментарий от anonymous

> Да хватит уже этого тролля кормить, уже не смешно и не итренесно читать его бред.

В том то и дело, что раньше он зачастую говорил вполне адекватные вещи. Может пароль на аккаунт украли?

skwish ★★
()
Ответ на: комментарий от AcidumIrae

Товарища AcidumIrae надо сослать^W отправить в Сибирь и устроить на работу в среднестатистическую контору. Тогда он запоёт совсем по-другому :)

anonymous
()
Ответ на: комментарий от r

>ы интересно - эта штука - это FS. как ообще сеяб поведет mount этого дела если источник недоступен? ;))

посмотрел исходники - не смонтируется. То есть зависимость локальной файловой системы от связи с источником - полная. Что вполне логично для FTPFS. И совсем нехорошо для зеркала.

r ★★★★★
()
Ответ на: комментарий от r

> посмотрел исходники - не смонтируется. То есть зависимость локальной файловой системы от связи с источником - полная. Что вполне логично для FTPFS. И совсем нехорошо для зеркала.

Вот притензия к реализации вролне обоснована. С этим соглаен. FTPFS далеко не лучшее решение, даже при дорогом трафике.

skwish ★★
()
Ответ на: комментарий от r

Убейтесь. Какие разговоры про наполовину обновленный офис. Пока все пакеты не скачаются оно не начнет ставицо. А если все уже скачаецо то офис обновиццо разом (ну скока там пакеты будут ставицо по времени?).

goletsa
()
Ответ на: комментарий от skwish

>FTPFS далеко не лучшее решение, даже при дорогом трафике.

Вот - так к этому же и была одна единственная и основная претензия. Что данное решение не подходит как замена зеркала. Все остальное от врагов:)

Судя по исходникам он все операции делает ремотно кроме чтения - на открытие файла оно его кеширует и потом читает с диска. К стати неуверен что это хорошая мысль - для больштх файлов операция типа fopen будет занимать фантастическое время. Никакого хендлинга открытия одного и того же файла двумя процессами одновременно не нашел. Как 2 процесса смогут открыть файл который не в кеше? Они конкурентно будут писать его в кеш? Один дописал 99 мегабайт из 100, второй тут же затрет и начнет заново и они намусоряд друг другу и вообще выпадут с ашипками? Плюс по коду - очень фиговая практика вот так писать:

my $size = (lftp_getattr($file))[7] || 0; my $mdtm = (lftp_getattr($file))[9] || 0;

каждый lftp_getattr - это ползанье по FTP. Мало того что операция неатомарна (а вдруг файл там как раз меняется) так еще и одни и те же данные получение которых очень дорого получаются много раз. У этой файловой системы будет "скорость ах%@вающая" (C) Лесь Подеревьянский. И стабильность. Короче до "предприятий" проекту еще развиваться и развиваться.

r ★★★★★
()
Ответ на: комментарий от f3ex

> непрощели сделать debmirror на серваке каком-нибудь, с указанием нужных каталогов, и потом просто настроить sourse.list на локальных машинах?

Проще... просто не у всех дебиан %)

Arceny ★★
()
Ответ на: комментарий от r

>4. На машине бухгалтерии есть этот OOo, ему говорят update и оно качается 5 часов. В это время бухгалтер бьет баклуши. Сей процесс происходит на всех машинах предприятия. Оное простаивает. С экономил?

>4a. Админ приходит ночью чтобы после работы посидеть 5 часов разруливая апдейты. И Так регулярно. Получает оплату за сверхурочные. Ты уже обосновал где трафик будет дешевле зарплаты админа который будет там ночевать, и на поиск новых админов которые не захотят жить на работе ради наблюдения за критичными обновлениями которые надо делать постоянно?

4б.В конце рабочего дня одмин ставит качаться на своей тачке апдейты и идёт домой бухать. На следующее утро тестирует апдейты и обновляет все тачки на которых стоит аналогичный софт со своей.

Arceny ★★
()
Ответ на: комментарий от r

>> FTPFS далеко не лучшее решение, даже при дорогом трафике. > Вот - так к этому же и была одна единственная и основная претензия.

Твоя притензия была вообще к подходу создать `срез` зеркала вместо полного копирования всего и вся. Если не веришь - посты перечитай.

skwish ★★
()
Ответ на: комментарий от skwish

>Твоя притензия была вообще к подходу создать `срез` зеркала вместо полного копирования всего и вся. Если не веришь - посты перечитай.

Не знаю, что вы там придумали, но моя претензия была к созданию среза для обновлений методом кеша давнлоадов с бухгалтерских тачек, как industrial схемы. А не к срезам вообще.

r ★★★★★
()
Ответ на: комментарий от r

>Или у тебя RPM уже рекаверить проблемы с сетью научился?

Чой то у тебя с головой. Не знаю какой говнодистр ты юзаешь, но yum начинает update только после того как пакеты выкачались, поэтому ты бред несешь.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.