|
2.5, LeNiN (ok), 15:17, 10/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Оно другое — apt-cacher-ng/apt-proxy не закачивают пакеты заранее, а кеширует то, что через них проходит. А apt-mirror, debmirror, ubumirror закачивают всё заранее. Им обычно нужно сотни гигабайт места. Хороши, когда у тебя много debian based систем.
| |
|
|
2.10, Аноним (-), 16:25, 10/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Действительно хорошего, как aptly, нет.
Но есть createrepo и reposync, и обертка над ними y10k.
| |
2.12, Сергей (??), 18:29, 10/11/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
apt-cacher-ng прекрасно работает с rpm
В yum.conf
proxy=(url с портом)
| |
|
|
|
3.11, Аноним (-), 16:27, 10/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Очень хорошая штука. Сейчас на rpm дистрибутивах "сижу", мне такого функционала, как в ней есть, не хватает.
| |
|
4.15, Андрей (??), 02:35, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Уже запланировано:
> See upcoming features
> RPM support
> Support for yum repositories, mirroring, snapshots, local repos, publishing, searching, ... | |
|
|
2.16, Андрей (??), 02:47, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Оно может быть лучше apt-mirror для такого сценария: сделать список установленных пакетов (2-3 архитектур), сделать зеркало для них, обновлять каждый день так, чтобы всегда были доступны последняя и предпоследняя версия каждого пакета? Если да - то чем?
| |
|
3.18, АнонимХ (ok), 04:18, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
А этот кейз юзабелен? Всегда захочется доутановить какую-нибудь либу. В зеркале ее нет, а ты оффлайн. Или для чего твое нужно?
| |
|
|
5.30, АнонимХ (ok), 06:03, 13/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Такой риск всегда есть.
> Чтобы обновлять то, что уже есть.
Для меня это не риск, а 100%-й случай. Спасибо за ответ.
| |
|
|
3.23, freehck (ok), 13:19, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> сделать список установленных пакетов (2-3 архитектур), сделать зеркало для них, обновлять каждый день так, чтобы всегда были доступны последняя и предпоследняя версия каждого пакета? Если да - то чем?
Разумеется. aptly как раз под это и заточен: вы задаёте список пакетов, он публикует их в репозиторий в том виде, в каком его ожидает увидеть apt. Выкачивать зеркала тоже умеет, сливать репозитории воедино - тем более.
Ваша задача решается навскидку просто:
1) Скриптуете ежедневный запуск aptly на зеркалирование нужного репозитория
2) Скриптуете слияние двух последних воедино
3) Публикуете результат слияния.
Если Вы обновляетесь каждый день, то изменённые пакеты как раз будут в двух экземплярах.
И кстати, операция публикации репозитория - очень быстрая с aptly. Вы можете в принципе выбрать снапшот зеркала за любое число, и опубликовать его. aptly просто создаёт hardlink-и. В некотором смысле это такой локальный аналог stapshot.debian.org
| |
|
4.27, Андрей (??), 17:57, 11/11/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Спасибо за подробный ответ!
> Ваша задача решается навскидку просто:
> 1) Скриптуете ежедневный запуск aptly на зеркалирование нужного репозитория
> 2) Скриптуете слияние двух последних воедино
> 3) Публикуете результат слияния.
> Если Вы обновляетесь каждый день, то изменённые пакеты как раз будут в
> двух экземплярах.
Вот тут не совсем понимаю. Ведь потом они будут и в 3-х, и 4-х, и т.д. экземплярах? И т.к. пакеты обновляются не все в одно время, то дропнуть снапшоты так, чтобы именно каждого пакета осталось в последних двух версиях не выйдет. (Мне нужно, чтобы на диске было занято минимум места: две последних версии кажется хорошим компромиссом.)
> И кстати, операция публикации репозитория - очень быстрая с aptly. Вы можете
> в принципе выбрать снапшот зеркала за любое число, и опубликовать его.
> aptly просто создаёт hardlink-и. В некотором смысле это такой локальный аналог
> stapshot.debian.org
Да, регулярно заглядываю туда, чтобы вручную downgrade'нуть подозрительные на баг изменения. Поэтому и решил хранить локально также предпоследнюю версию, чтобы пореже вручную возиться.
| |
|
5.29, freehck (ok), 23:54, 12/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>> 1) Скриптуете ежедневный запуск aptly на зеркалирование нужного репозитория
>> 2) Скриптуете слияние двух последних воедино
>> 3) Публикуете результат слияния.
>> Если Вы обновляетесь каждый день, то изменённые пакеты как раз будут в
>> двух экземплярах.
> Вот тут не совсем понимаю. Ведь потом они будут и в 3-х,
> и 4-х, и т.д. экземплярах? И т.к. пакеты обновляются не все
> в одно время, то дропнуть снапшоты так, чтобы именно каждого пакета
> осталось в последних двух версиях не выйдет. (Мне нужно, чтобы на
> диске было занято минимум места: две последних версии кажется хорошим компромиссом.)
Если Вы объединяете два последний снапшота, то у вас там будет либо одна версия, либо две.
При чистке базы aptly удаляются все пакеты, не относящиеся ни к одному снапшоту.
Вы, конечно, можете подойти к решению этой задачи в лоб: после очередного зеркалирования (укачивания пакетов с репозитория и создания связанного с ним снапшота), обойти список всех пакетов, выбрать по две последнии версии каждого пакета, и поместить их в новый снапшот. Затем все остальные снапшоты удалить, и почистить базу.
Написать будет несколько сложнее, но зато это уже совсем то, что Вы хотите.
| |
|
6.31, Андрей (??), 08:04, 22/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Если Вы объединяете два последний снапшота, то у вас там будет либо одна версия, либо две.
Похоже, не попробовав, так и не пойму, почему версии не будут накапливаться. Но с оригинальным репозиторием не удобно пробовать, так как нет контроля, когда пакет обновится. Но, наверное, можно попробовать пообъединять 4 Debian snapshot репозитория: 2-ой ещё без обновления какого-то определённого пакета, 3-ий с обновлённым и 4-ый снова с обновлённым. Хотя эти snapshot репы здоровые. Интересно, не слишком долго операции по времени будут.
> Вы, конечно, можете подойти к решению этой задачи в лоб
Спасибо за совет. Если первый вариант не выйдет, то останется только так.
| |
|
|
|
|
2.21, freehck (ok), 13:11, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Согласен, но всё-таки aptly не для зеркалирования предназначен, а для создания репозиториев и управления ими. Он не может сделать полноценное зеркало: дизайн у него под это не заточен[1]. Вы можете выкачать пакеты нужного вам репозитория, но чтобы сделать из этих пакетов полноценное зеркало, Вам надо опубликовать их, подписав своим ключом.
Иными словами, при зеркалировании репозитория через aptly вам придётся свой ключ в обязательном порядке на машины пользователей.
apt-mirror же куда более простая утилита: он просто копирует репозиторий, как он есть, выкачивая только то, что вы хотите отзеркалировать.
[1] http://freehck.ru/ru/articles/mirroring-debian-repository-is-simple.html
| |
|
3.24, Аноним (-), 16:31, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Вам надо опубликовать их, подписав своим ключом.
Для меня лично это даже лучше, мне эта особенность нравится в aptly.
| |
|
|
1.17, Андрей (??), 02:55, 11/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> После года не активности выпущен ... 0.5.2
Года? Целых два с половиной:
0.5.2 released on Nov 8, 2016
0.5.1 released on Apr 12, 2014
| |
|
|
3.25, Андрей (??), 17:49, 11/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
Точно, я смотрел в дебиановский git: думал, что это их родная прога. А она на github, оказывается.
| |
|
|
|