зеркало репозитория

[repoman]

Добрый день!

Планирую сделать локальное зеркало debian для собственных нужд, планируется зеркалировать только amd64.
Гугл выдаёт уйму возможных сценариев решения.
Самые распространённые - это apt-mirror и debmirror.

После более углублённого изучения результатов поисковой выдачи Google привёл меня на страницу на debian.org, где весьма поверхностно рассматривается использование утилиты ftpsync, которой по каким-то причинам нету в репозитории, а лишь приведена ссылка на непонятный архив со скриптами.

Мне непонятно, каким образом отслеживать измения в этих скриптах. Неужели нужно писать shell скрипт, который будет постоянно скачивать архив по ссылке и проверять его на изменения, и указывать его в cron?

По той же черным по белому написано, что настоятельно не рекомендуется использовать wget для зеркалирования (именно его используют apt-mirror и debmirror).

Почему такой мощный и огромный проект, как Debian, так несерьёзно относится к таким важным вещам, как зеркалирование репозитория?

Чем Вы пользуетесь для создания и поддержания в актуальном состоянии зеркала репозиториев GNU/Debian Linux?

Заранее благодарствую за советы.

[watashiwa_daredeska]

Мне непонятно, каким образом отслеживать измения в этих скриптах. Неужели нужно писать shell скрипт, который будет постоянно скачивать архив по ссылке и проверять его на изменения, и указывать его в cron?

Там помимо архива есть еще и git-репозиторий.

не рекомендуется использовать wget для зеркалирования (именно его используют apt-mirror и debmirror).

apt-mirror и debmirror зеркалируют совершенно по другому принципу, поэтому им можно. apt-mirror и debmirror зеркалируют репозитории, а ftpsync — Debian archive целиком.

[drBatty]

После более углублённого изучения результатов поисковой выдачи Google привёл меня на страницу на debian.org, где весьма поверхностно рассматривается использование утилиты ftpsync, которой по каким-то причинам нету в репозитории, а лишь приведена ссылка на непонятный архив со скриптами.

рискну предположить, что речь идёт о скриптах для rsync.
Эта утилита умеет не только качать новое с FTP, но и даже выкачивать новые/повреждённые части файлов.

По той же черным по белому написано, что настоятельно не рекомендуется использовать wget для зеркалирования (именно его используют apt-mirror и debmirror).

а вот wget этого не умеет.
потому и не рекомендуют - большая нагрузка на канал связи.

Почему такой мощный и огромный проект, как Debian, так несерьёзно относится к таким важным вещам, как зеркалирование репозитория?

http://www.debian.org/CD/mirroring/rsync-mirrors.ru.html

[repoman]

Там помимо архива есть еще и git-репозиторий.

Так это немногое меняет. Я имел в виду, что очень неудобно, что нету собранного deb-пакета в репозитории.
Все равно все конфигурационные будут затираться.

apt-mirror и debmirror зеркалируют совершенно по другому принципу, поэтому им можно. apt-mirror и debmirror зеркалируют репозитории, а ftpsync — Debian archive целиком.

Вы хотите сказать, что ftpsync для создания локальной копии репозитория подходит меньше, нежели apt-mirror, и при задаче создания зеркала репозиория пользоваться лучше именно последним?

рискну предположить, что речь идёт о скриптах для rsync.

Да. Именно о них.

http://www.debian.org/CD/mirroring/rsync-mirrors.ru.html

Спасибо. До этой ссылки я ещё не добрался.

[repoman]

И если можно, ещё один вопрос, касательно зеркал:
При релиза debian, получается, что ветки съезжают. И при обновлении зеркала получается, что чуть ли не половина оного скачивается заново?
Ведь сейчас у большинства пакетов из ленни в имени пакетов присутствует '~lenny'. ПОлучается, что и когда squeeze станет oldstable, то многие из его пакетов переименуют. Правильно?

[SLEDopit]

Ведь сейчас у большинства пакетов из ленни в имени пакетов присутствует '~lenny'.

Я бы не стал так паниковать. Чуть больше 2500 deb файлов имеют такую приставку в своём имени. У squeeze эта цифра около 1700. Так что перекачивать Вам ничего не придется. Тем более, что структура репозитория такова, что все файлы, относящиеся к разным версиям (oldstable -> sid) находятся в одной директории (например pool/main/n/nautilus/ ) и ничего страшного не произойдет.

[watashiwa_daredeska]

При релиза debian, получается, что ветки съезжают. И при обновлении зеркала получается, что чуть ли не половина оного скачивается заново?

Не совсем. Нужно будет скачать репозиторий нового stable.

Ведь сейчас у большинства пакетов из ленни в имени пакетов присутствует '~lenny'. ПОлучается, что и когда squeeze станет oldstable, то многие из его пакетов переименуют. Правильно?

Нет. В squeeze свои пакеты, старые остались в lenny и никуда не делись. Точно также, при выходе wheezy, пакеты squeeze останутся в squeeze и никуда не денутся. Это всё три разных репозитория: lenny, squeeze, wheezy.
При выходе нового stable меняются лишь симлинки oldstable, stable, testing.

Так что перекачивать Вам ничего не придется.

Если захочется новоиспеченный stable, то придется скачать его репозиторий почти весь, за исключением пакетов, которые не изменились с прошлой версии.

Вы хотите сказать, что ftpsync для создания локальной копии репозитория подходит меньше, нежели apt-mirror, и при задаче создания зеркала репозиория пользоваться лучше именно последним?

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

[SLEDopit]

Если захочется новоиспеченный stable, то придется скачать его репозиторий почти весь, за исключением пакетов, которые не изменились с прошлой версии.

Почему придется перекачать? И что именно перекачать?
Структура репозитория такова, что для каждого пакета в репозитории есть своя директория, в которой хранятся пакеты для всех веток (oldstable, stable и т.д.), а так же исходники и прочая полезная информация. При объявлении стейблом testing'a из этой директории будут удалены все файлы, относящиеся к oldstable, однако все остальные файлы останутся такими же. К тому же, в момент релиза версии пакетов в stable и testing совпадают. Таким образом ничего нового в директорию не добавится. Просто пропадут oldstable версии. А уже со временем версии в testing будут меняться и будут добавляться новые файлы. Поэтому сильно больше трафика в момент релиза не предвидется.

Просто стоит иметь в виду, что при подходе зеркалирования с rsync нет возможности исключать пакеты по секциям (games, например, как в debmirror) и по веткам (качаются сразу все ветки для выбранной архитектуры). Таким образом минимальный вес будет порядка 110Гб для amd64. В то время, как вес amd64 только для тестинг не превышает 40Гб. Но зато rsync гарантирует качество зеркала и отсутствие битых файлов, чего нам совсем не гарантирует wget, который используют apt-mirror и debmirror. Так что, если Вам превыше всего стабильность и уверенность в качестве репозитория, то лучше ftpsync'a ничего не найти. Ежели превыше дисковое пространство, то wellcome to apt/deb mirror. Ну или и вовсе настроить apt-cacher.

[repoman]

Однако, судя по описанию, я бы предположил, что да — apt-mirror предпочтительнее.

Меня очень интересует вопрос целостности зеркала. Высока ли вероятность получить поломанные пакеты при использовании утилит apt-mirror и debmirror?

Так что перекачивать Вам ничего не придется.

Нужно будет скачать репозиторий нового stable.

И кого мне слушать?

[watashiwa_daredeska]

И кого мне слушать?

Вопрос лишь в том, чего Вы хотите.
1. Если нужна одна ветка дистрибутива, например, squeeze, то выход нового stable на нее никак не повлияет и перекачивать не придется.
2. Если нужен stable, каким бы он ни был в данный момент, то при выходе нового stable, нужно будет качать пакеты нового stable почти все, ибо меняются они почти все.

Высока ли вероятность получить поломанные пакеты при использовании утилит apt-mirror и debmirror?

Не знаю, промышленно не использовал.

[SLEDopit]

И кого мне слушать?

Я имел в виду, что если зеркалировать с помощью ftpsync'a то ничего перекачивать не придется. В случае с apt-mirror - придется полностью перекачивать ветку, как описал watashiwa_daredeska.

Высока ли вероятность получить поломанные пакеты при использовании утилит apt-mirror и debmirror?

Очевидно, зависит, от Вашего канала. Если для собственных нужд - вполне сгодится apt-mirror. Для продакшна я бы использовал rsync.

[watashiwa_daredeska]

Почему придется перекачать? И что именно перекачать?

Потому, что в wheezy другие пакеты, чем в squeeze. Если хочется wheezy, а есть только squeeze, то придется скачивать пакеты для wheezy.

К тому же, в момент релиза версии пакетов в stable и testing совпадают. Таким образом ничего нового в директорию не добавится.

Это если testing зеркалить. Если testing не зеркалить, то в момент релиза появляется куча неотзеркаленых пакетов.

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

Ну, об этом я и говорил, что rsync больше подходит для зеркалирования целиком :) В этом случае, конечно, докачивать ничего не надо, там и так уже куча лишнего, если требовался только stable.

rsync гарантирует качество зеркала и отсутствие битых файлов, чего нам совсем не гарантирует wget, который используют apt-mirror и debmirror.

Теоретически, apt-mirror знает об устройстве репозитория и может проверять хеш-суммы и перекачивать неправильно скачанное. Кроме того, apt-mirror, опять же теоретически, может выкладывать файлы Release и Packages только тогда, когда все пакеты, указанные в них, корректно скачаны. Т.е. даже с wget у apt-mirror достаточно средств для того, чтобы поддерживать репозиторий в 100% корректном состоянии. Только вот я не знаю, всё ли правильно делает для этого apt-mirror.

[SLEDopit]

watashiwa_daredeska
Ну да. Мы просто немного о разных вещах говорили: о зеркалировании через rsync и о зеркалировании по http.

Только вот я не знаю, всё ли правильно делает для этого apt-mirror.

Я глянул исходник apt-mirror. Что-то ничего о проверке я там не нашел. Видимо нужно допиливать.

[repoman]

Более менее всё встало на свои места.
Спасибо большое за разъяснения!