Комментарии 26
НЛО прилетело и опубликовало эту надпись здесь
И устанавливать обновления по крону — это не лучший выход, ибо машинка может быть вырублена. Есть тьма путей, как это обойти, самый простой — устанавливать обновления при загрузке системы.
Apt-mirror, на мой вкус, попроще будет.
Хорошая статья, автору спасибо!
Полезно, полезно… Надо будет на будущее поместить в закладки…
apt-mirror
Расскажите вкратце, чем это лучше прозрачного кеширующего прокси на восьмидесятом порту? Вашим пользователям действительно необходим весь репозиторий?
Меня пугает перспектива выкачивать изначально 100 Гб пакетов, а потом ещё и постоянно обновлять их все. Ведь большинство из этих пакетов вообще никем будут не востребованы. Тогда зачем их все качать и постоянно обновлять?
Более приемлемой мне кажется идея с кэширующим прокси-сервером. Первая обновляющаяся машина в сети тянет обновления из инета через прокси, а уже все остальные скачивают эти файлы по локалке из кэша прокси. Итого качаются только те пакеты, которые хоть кому-то в локалке нужны, и из инета каждый качается единожды (по первому запросу).
Для реализации этой идеи предлагаю рассмотреть AptProxy.
Более приемлемой мне кажется идея с кэширующим прокси-сервером. Первая обновляющаяся машина в сети тянет обновления из инета через прокси, а уже все остальные скачивают эти файлы по локалке из кэша прокси. Итого качаются только те пакеты, которые хоть кому-то в локалке нужны, и из инета каждый качается единожды (по первому запросу).
Для реализации этой идеи предлагаю рассмотреть AptProxy.
Идея хороша, если список пакетов у всех одинаковый, а как же быть если различные группы юзеров работают с определенным набором ПО? Да, можно все суммировать и выкачивать через главную машинку. Но это не спасает от периодической необходимости что-то быстро развернуть. А быстрота может влететь в копеечку, ибо монополизации арендодателей помещений в сфере услуг связи никто не отменял. Это выливается в использовании услуг двух провайдеров. Местный — быстро, но дорого и безлимитный Yota, нормальная скорость работы которого достигается при достаточной разгрузке БС, т.е ночью. Следовательно в рабочее время выкачать нечто более менее увесистое может обернуться проблемой.
А что до 100 гигабайт, они получились в моем случае ( сырцы, две архитектуры, и все секции). Гораздо меньше места оно займет, если убрать все лишнее. Старался как можно подробнее расписать скрипт, дабы каждый смог отредактировать его под свои нужды. И да, это всего лишь один из вариантов, на его «православность» не претендую.
А что до 100 гигабайт, они получились в моем случае ( сырцы, две архитектуры, и все секции). Гораздо меньше места оно займет, если убрать все лишнее. Старался как можно подробнее расписать скрипт, дабы каждый смог отредактировать его под свои нужды. И да, это всего лишь один из вариантов, на его «православность» не претендую.
Идея хороша, если список пакетов у всех одинаковый, а как же быть если различные группы юзеров работают с определенным набором ПО?Не понял, какое тут имеет значение одинаковость ПО. Все пакеты, которые нужны хотя бы одному компьютеру, будут выкачиваться через прокси единожды. И всё равно это будет получаться гораздо меньше, чем качать и постоянно обновлять полный репозиторий.
вот вы бы написали, сколько весит ваш репазиторий.
и что еще, кроме ру.архива и секьюрити хорошо было бы отзеркалить.
Маленький хинт: первичное зеркало репы кошерно делать с внутреннего сервера какого-нибудь крупного частного провайдера. И скорость сто мегабит, и трафик халаявен.
Например для обитателей билайна — это ftp.corbina.net (/pub/Linux/ubuntu)
и что еще, кроме ру.архива и секьюрити хорошо было бы отзеркалить.
Маленький хинт: первичное зеркало репы кошерно делать с внутреннего сервера какого-нибудь крупного частного провайдера. И скорость сто мегабит, и трафик халаявен.
Например для обитателей билайна — это ftp.corbina.net (/pub/Linux/ubuntu)
В данном контексте есть ещё и задача кастомизации конфигурации установки (в инсталяторе убунты вроде называется «профилями», типа там десктоп, разработка, итп)
Есть ли у «памятка» для этого?
Есть ли у «памятка» для этого?
терминологическая придирка:
«гибче» всётаки rsync, поскольку он обеспечивает более базовые операции, с большей степенью свободы конфигурации.
а «debmirror» заточен на конкретную задачу, и в данном случае он «проще» или «удобнее», рад чего всегда жертвуется гибкость.
«гибче» всётаки rsync, поскольку он обеспечивает более базовые операции, с большей степенью свободы конфигурации.
а «debmirror» заточен на конкретную задачу, и в данном случае он «проще» или «удобнее», рад чего всегда жертвуется гибкость.
По пунктам:
2. Важно учитывать не только место, но и количество свободных inodes на целевом разделе.
3. Запускаем скрипт и консоль на десятки часов занята. Поэтому первоначально скрипт repo_update.sh надо запускать по крону или в screen.
5. Браво. Вместо целевого конфига мы рисуем костыль. Если вы рисуете костыль на клиентах, значит их не так много. Тогда какой смысл для десятка-другого компьютеров выкачивать 100ГБ пакетов и потом их ибновлять? Мсье мазохист или прямо на точке обмена трафиком М9 сидит?
P.S. Чтобы вылезти из песочницы уже достаточно перевести/скопипастить стандартный howto? Не знал.
2. Важно учитывать не только место, но и количество свободных inodes на целевом разделе.
3. Запускаем скрипт и консоль на десятки часов занята. Поэтому первоначально скрипт repo_update.sh надо запускать по крону или в screen.
5. Браво. Вместо целевого конфига мы рисуем костыль. Если вы рисуете костыль на клиентах, значит их не так много. Тогда какой смысл для десятка-другого компьютеров выкачивать 100ГБ пакетов и потом их ибновлять? Мсье мазохист или прямо на точке обмена трафиком М9 сидит?
P.S. Чтобы вылезти из песочницы уже достаточно перевести/скопипастить стандартный howto? Не знал.
По пунктам:
3. В примечании указано примерный размер скачиваемого. Время — индивидуальный параметр. А масло маслянистым и масленным ежеминутно называть я считаю не слишком удачным ходом. Тем не менее подправил, спасибо.
5. Никто не мешает Вам поправить sources.list, об этом варианте я намекнул. Моей целью был упор на изменение записей в DNS, дабы клиентов не трогать вовсе, но в предверии отказа от контроллера домена на AD, с DNS приходится повременить. И да, выкачать порядка 30гб репозитория на одну архитектуру и еженочно обновлять ради десятка-другого компьютеров стоит. По крайней мере если у вас подключена Yota.
p.s: Вам помог стандартный howto? Мне нет. Вышеописанное — последовательность действий, которая привела к положительному результату и я буду рад, если описанная последовательность поможет кому-либо еще.
3. В примечании указано примерный размер скачиваемого. Время — индивидуальный параметр. А масло маслянистым и масленным ежеминутно называть я считаю не слишком удачным ходом. Тем не менее подправил, спасибо.
5. Никто не мешает Вам поправить sources.list, об этом варианте я намекнул. Моей целью был упор на изменение записей в DNS, дабы клиентов не трогать вовсе, но в предверии отказа от контроллера домена на AD, с DNS приходится повременить. И да, выкачать порядка 30гб репозитория на одну архитектуру и еженочно обновлять ради десятка-другого компьютеров стоит. По крайней мере если у вас подключена Yota.
p.s: Вам помог стандартный howto? Мне нет. Вышеописанное — последовательность действий, которая привела к положительному результату и я буду рад, если описанная последовательность поможет кому-либо еще.
> Моей целью был упор на изменение записей в DNS
Правка файла hosts и измнение в DNS — это костыли.
И вообще в своём DNS вы предлагаете создавать свою зону ubuntu.com всего с парой записей в ней для локального сервера репозиториев? Вы понимаете, что тогда любые хосты из зоны ubuntu.com ваши клиенты будут пытаться разрешить через ваш DNS (раз там есть такая зона), но они этого сделать не смогут. Т.е. какой-нить www.ubuntu.com, help.ubuntu.com, shop.ubuntu.com и т.д. они уже разрешить через DNS не смогут.
Что же теперь для корректной работы вручную поддерживать все записи в DNS-зоне ubuntu.com на своих DNS?
Правка файла hosts и измнение в DNS — это костыли.
И вообще в своём DNS вы предлагаете создавать свою зону ubuntu.com всего с парой записей в ней для локального сервера репозиториев? Вы понимаете, что тогда любые хосты из зоны ubuntu.com ваши клиенты будут пытаться разрешить через ваш DNS (раз там есть такая зона), но они этого сделать не смогут. Т.е. какой-нить www.ubuntu.com, help.ubuntu.com, shop.ubuntu.com и т.д. они уже разрешить через DNS не смогут.
Что же теперь для корректной работы вручную поддерживать все записи в DNS-зоне ubuntu.com на своих DNS?
Простите, но причем здесь весь домен www.ubuntu.com? Речь идет о доменах третьего уровня, которые являются серверами репозиториев и в DNS на каждый из оных имеются свои записи.
Ну тогда напишите точнее, какие именно записи вы собираетесь создавать в DNS и где именно (в каких зонах).
Например: «на внутренних DNS-серверах компании создаётся зона прямого просмотра с именем bbbbb.aaa, в этой зоне создаётся запись типа A с именем сссссс и значением xxx.xxx.xxx.xxx».
Например: «на внутренних DNS-серверах компании создаётся зона прямого просмотра с именем bbbbb.aaa, в этой зоне создаётся запись типа A с именем сссссс и значением xxx.xxx.xxx.xxx».
www.ubuntu.com это и есть домен третьего уровня!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание локального репозитория Ubuntu 10.04