Re: In SMART we trust?, Re: Генерация pool-based репозиториев
On Fri, 29 Mar 2019, Stanislav Vlasov wrote: 28.03.2019, Mykola Nikishov написал(а): Лично у меня после чтения zfs-devel сложилось впечатление, что полагаться на SMART можно всё меньше и меньше. Вплоть до того, что enterprise-grade SSD может в течении длительного времени быть живее всех живых и сдохнуть без предупреждения. У меня такое ощущение за счёт сбора статистики на серверах, где из SSD собраны рейды 10 и иногда 6. Сегодня - чистый статус, завтра - дохлый диск. Мне кажется, что надо различать два способа подыхания дисков. Если речь идет о смерти контролера, то тут SMART не помощник. «Да, SSD смертен, но это было бы еще полбеды. Плохо то, что он иногда внезапно смертен, вот в чем фокус!» (c) Второй способ - постепенная деградация за счет исчерпания циклов перезаписи. Кроме простого подсчета таких циклов SMART содержит счетчик "reallocation blocks". И если этот счетчик начинает постоянно расти, то это неплохой повод немного удивиться. SMART не был панацеей и для обычных HDD дисков. Контролеры HDD более надежны, по причине, что они проще, но заклинивание мотора не такая уж редкая вещь. В общем SMART как градусник. Повышенная температура повод для беспокойства, но нормальная температура не спасает от визита налогового инспектора... Ю.
Re: In SMART we trust?, Re: Генерация pool-based репозиториев
28.03.2019, Mykola Nikishov написал(а): > Лично у меня после чтения zfs-devel сложилось впечатление, что > полагаться на SMART можно всё меньше и меньше. Вплоть до того, что > enterprise-grade SSD может в течении длительного времени быть живее всех > живых и сдохнуть без предупреждения. У меня такое ощущение за счёт сбора статистики на серверах, где из SSD собраны рейды 10 и иногда 6. Сегодня - чистый статус, завтра - дохлый диск. -- Stanislav
In SMART we trust?, Re: Генерация pool-based репозиториев
Eugene Berdnikov writes: > Пому что в 99% случаев софтописатель не проверяет на EIO и вообще > транзакционной целостностью не озабочен. Он знает, что диски достаточно > надёжны: сбой может случиться через 5, 10 или 15 лет, и, как правило, > smartd поднимет тревогу до того, как диску придёт капец. Чтобы говорить, что на SMART можно полагаться, нужно иметь какую-то статистику, а с ней у SOHO пользователей неважно. Лично у меня после чтения zfs-devel сложилось впечатление, что полагаться на SMART можно всё меньше и меньше. Вплоть до того, что enterprise-grade SSD может в течении длительного времени быть живее всех живых и сдохнуть без предупреждения. -- Mykola
Re: Генерация pool-based репозиториев
Привет On Tue, 26 Feb 2019 12:24:48 +0300 Victor Wagner wrote: > Коллеги, > > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ > reprepro? reprepro меня не устроил потому что 1. не может добавить один и тот же пакет к нескольким дистрибутивам 2. не может добавить несколько версий одного пакета Я пользуюсь freight. Мои потребности полностью удовлетворяет. Им можно пользоваться вообще с командной строки https://github.com/freight-team/freight Я делаю так - все пакеты разложены по папкам для каждого дистрибутива, те что идут сразу во все дистрибутивы - в папку уровнем выше. На эту папку натравливаю 20-строчный скриптик (могу прислать), которые вызывает freight с параметром соответствующим имени папки - тот генерирует/обновляет локальный репозиторий и потом с помощью rsync закидываю на сервер. rsync нужно использовать в два прохода для репозиториев, типа такого rsync --password-file=$HOME/rsync.repo.secret -aH --numeric-ids \ --exclude 'Packages*' --exclude 'Sources*' --exclude 'Release*' \ --exclude=InRelease --include='i18n/by-hash/**' --exclude='i18n/*' \ --exclude 'ls-lR*' ./freight/cache/* \ u...@repo.mooo.com::repo/dir rsync --password-file=$HOME/rsync.repo.secret -aH --numeric-ids \ --delete ./freight/cache/* \ u...@repo.mooo.com::repo/dir -- Best regards, Sergey Spiridonov
Re: Генерация pool-based репозиториев
Eugene Berdnikov wrote: > On Tue, Mar 05, 2019 at 09:58:17PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov wrote: > > > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > > > Eugene Berdnikov wrote: > > > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > > > ... > > > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще > > > > > > какую-то > > > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > > > на которое fuse выбросит I/O error, твоя приблуда не сломает > > > > > репозиторий. > > > > > Потому как автор её скорее всего просто не предполагал, что > > > > > репозиторий > > > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > > > привыкли, что типа "жосткий диск" он "рядом". > > > > > Не только я, всё человечество к этому привыкло. Все пишут софт под > > > эту парадигму, потому что диск в системнике и бэкап в соседнем это > > > для большинства задач нормально по надёжности и оптимально по деньгам. > > > > Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла > > диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а > > софтина этого не заметила - > Заметила или нет неважно, главное что сломала базу/репозиторий/etc. > Пому что в 99% случаев софтописатель не проверяет на EIO и вообще > транзакционной целостностью не озабочен. Он знает, что диски достаточно > надёжны: сбой может случиться через 5, 10 или 15 лет, и, как правило, > smartd поднимет тревогу до того, как диску придёт капец. Ага. Блаженны верующие. Предыдущий SSD от OCZ сказал кря без объявления войны, просто нагревшись контроллером градусов до 80 и отвалившись от интерфейса. smartd даже не взвизгнуло. Нагрузки на него не было, он просто был подключен. > А сетевой диск через fuse сбойнёт если не завтра, то послезавтра точно, > и что смешно, никто об этом заранее не предупредит. Да верьте в ваш S.M.A.R.T. верьте, вам никто не запрещает. Только вот еще может по дороге китайский кабель попасться, который рассохнется и отвалится и еще миллион причин. Но верить в smartd надежнее, я понимаю. > > так ну её в /dev/null ту софтину. Каким образом > > поможет от этого бакап - моя не понимайт. Его то на данный момент нету? > Бэкап есть, вчерашний. Только с обычным диском он может вообще никогда > не понадобиться, а с сетевым может понадобиться три раза за день. :) > Почувствуйте разницу. Мы говорим о разном. В моём случае тот бакап нужен был на 5 минут назад. Датасет то который писали в диск - проё, в бакапе его нет и хорошо, что это у нас репозиторий, который можно просканировать и создать датасет по новой, а не какие-нибудь скажем логи от невдомой херни, которые именно такими уже не получишь. > А насчёт "софтину в /dev/null" это скажи своему работодателю. Возможно, > он тебе ответит, что тебе лучше отдохнуть полгода-год за свой счёт, > а на досуге почитать что-нибудь про технологии работы с различного рода > ошибками -- аппаратными, сетевыми, человеческими и т.п., и что твоя > задача из ненадёжных дисков, глючных материнок и полных багов софтверных > продуктов строить надёжные ИС для его бизнеса. А если ты не умеешь > или не хочешь это делать -- найдутся другие, которые не станут ныть > и предлагать переписать 1С с нуля. Ты свой пафос то поприкрути, а то перегорит от перегрева. В случае с отстойным 1С - за дядин счет можно хоть в 8 ЦОДах держать ноды с синхронной репликацией. Ну и бакап этой 1С можно из бумажек раскатывать, зря их чтоль 3 года хранят в любой лавке? А мне нужно - для себя и с минимумом затрат. И жена стойку в кладовке не оценит и жить в серверной я не готов. А платить всем по периметру за "трехзвенки", "транзакции" и прочие "дедупликации" over модная-хипстерская-технолоджи и прочие линки в терабиты до хранилищ в петабайты - совсем не готов. Пропертарь выкинуть в /dev/null - готов. И даже opensource поправить под себя - готов. А работать на работодателей, которые будут мне рассказывать с чем и как мне работать - не готов. Они вмести со своим совтом идут в /dev/null, в обнимку. PS: и как показывает практика - самая нужная 1С, она стоит в одном экземпляре у буха на ноуте и НИКУДА НЕ РЕПЛИЦИРУЕТСЯ. Хорошо, если кто-нибудь умный сделал шифрованные бакапы в халявную помойку.
Re: Генерация pool-based репозиториев
On 02/03/2019 11:52, Igor Savluk wrote: Для твоих запросов тебе всеравно прийдется использовать утилиту с бд. Без них нет утилит. А я думал только на лоре не принято по ссылкам ходить. https://wiki.debian.org/DebianRepository/Setup#mini-dak * No database (the pool is the database) https://wiki.debian.org/DebianRepository/Setup#mini-dinstall * Doesn't require a PostgreSQL database. -- sergio.
Re: Генерация pool-based репозиториев
On Tue, Mar 05, 2019 at 09:58:17PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > > Eugene Berdnikov wrote: > > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > > ... > > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще > > > > > какую-то > > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > > на которое fuse выбросит I/O error, твоя приблуда не сломает > > > > репозиторий. > > > > Потому как автор её скорее всего просто не предполагал, что репозиторий > > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > > привыкли, что типа "жосткий диск" он "рядом". > > > Не только я, всё человечество к этому привыкло. Все пишут софт под > > эту парадигму, потому что диск в системнике и бэкап в соседнем это > > для большинства задач нормально по надёжности и оптимально по деньгам. > > Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла > диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а > софтина этого не заметила - Заметила или нет неважно, главное что сломала базу/репозиторий/etc. Пому что в 99% случаев софтописатель не проверяет на EIO и вообще транзакционной целостностью не озабочен. Он знает, что диски достаточно надёжны: сбой может случиться через 5, 10 или 15 лет, и, как правило, smartd поднимет тревогу до того, как диску придёт капец. А сетевой диск через fuse сбойнёт если не завтра, то послезавтра точно, и что смешно, никто об этом заранее не предупредит. > так ну её в /dev/null ту софтину. Каким образом > поможет от этого бакап - моя не понимайт. Его то на данный момент нету? Бэкап есть, вчерашний. Только с обычным диском он может вообще никогда не понадобиться, а с сетевым может понадобиться три раза за день. :) Почувствуйте разницу. А насчёт "софтину в /dev/null" это скажи своему работодателю. Возможно, он тебе ответит, что тебе лучше отдохнуть полгода-год за свой счёт, а на досуге почитать что-нибудь про технологии работы с различного рода ошибками -- аппаратными, сетевыми, человеческими и т.п., и что твоя задача из ненадёжных дисков, глючных материнок и полных багов софтверных продуктов строить надёжные ИС для его бизнеса. А если ты не умеешь или не хочешь это делать -- найдутся другие, которые не станут ныть и предлагать переписать 1С с нуля. -- Eugene Berdnikov
Re: Генерация pool-based репозиториев
Eugene Berdnikov wrote: > On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov wrote: > > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > ... > > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > > > > экзотику и работать с ней как с локальным диском - бесценно. > > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > > на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий. > > > Потому как автор её скорее всего просто не предполагал, что репозиторий > > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > > привыкли, что типа "жосткий диск" он "рядом". > Не только я, всё человечество к этому привыкло. Все пишут софт под > эту парадигму, потому что диск в системнике и бэкап в соседнем это > для большинства задач нормально по надёжности и оптимально по деньгам. Что-то тут у вас, бгатенька, не сходится. Если при записи воонтаго файла диск радостно отрапортовал UNC и ошибка поднялась до write(...) = -EIO а софтина этого не заметила - так ну её в /dev/null ту софтину. Каким образом поможет от этого бакап - моя не понимайт. Его то на данный момент нету? Нету. Записываемый датасет - того, агась. Тут бы конечно можно было применить drbd/ceph/gluster и прочую синхронщину - но оно для "ынтерпрайза" с терабитными каналами и стойками серверов. rsync и всякие надстройки вокруг него - тоже не помошники. Особенно если файлы по 10+G, rsync медленно и верно превращается в тыкву пожирающую процессор (если считает crc кусочками), а если не читает - то тыква жрет интернет гигабайтами. > А написать работающий с файлами транзакционно выверенный софт это столь > муторно, что получается лишь у профессионалов, занимающихся базами данных > и кластерами. У остальных обычно не получается. Например, стоит положить > файловую 1С с 5-15 юзерами на нестабильный канал, как через 2-3 месяца она > разлетается вдрызг, а техподдержка 1С тихо сопит и советует перейти на > трёхзвенку, т.е. архитектуру с транзакционным слоем снизу. Там и диски > по отношению к слою приложения оказываются локальными, неудивительно, > что на том же канале трёхзвенка 1С стабильно работает. Эмм, а причем тут эта виндовая хрень, которая на офтопике работает через "дай денег, дай, еще дай, ещё-ещё-ещё"? У неё задача такая - рассыпаться от любого чиха.
Re: Генерация pool-based репозиториев
Victor Wagner -> debian-russian@lists.debian.org @ Tue, 5 Mar 2019 07:27:45 +0300: >> > Прикрутить туда осмысленную систему exclusive и shared блокировок >> > при условии того, что задания крутятся на куче разных машин и в >> > репозиторий ходят apt-ом весьма нетривиально. >> >> Любая система с блокировками содержит race condition :) Один мутекс >> еще нет, а любая система уже да. > Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди, > способные грамотно спроектировать систему блокировок - найдутся. > > В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы > это один репозиторий, все убунты - другой, а каждая астра - отдельный) > тут хватит. > Основная проблема - гарантировать то, что при любых сбоях сборочного > задания, в том числе и при ошибке установки пакетов-зависимостей, > блокировка будет снята. Собственно, не знаю, как нынче в конторах, которые занимаются разработкой СУБД, а вообще в мире параллельных выполнений нынче модно, если ресурсы позволяют (ага, это несколько дороже, чем блокировки, порой заметно дороже, зато надежнее) оптимистическая конкуренция. Это вот то, что в описанном случае выражается в виде "сделаем свою копию, эксклюзивную по построению, и потом попытаемся заменить ею оригинал". Если операция замены обломалась по причине неконсистентности, откатываем все нафиг (ну, "все", вообще говоря, контекстно, не факт, что всю сборку целиком) и повторяем заново. Обычно при реализации какая-то блокировка для момента замены (она, как водится, _почти_ атомарна) употребляется, но она уже простая, и ее можно сделать надежной. Если говорить о вышеописанной реализации, то можно сделать специально обученного демона, которому делегируется эта операция. Она простая, а запросы можно выполнять строго по очереди.
Re: Генерация pool-based репозиториев
Victor Wagner -> debian-russian@lists.debian.org @ Tue, 5 Mar 2019 07:27:45 +0300: >> Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом >> _почти_ атомарная пара rename либо перевешивание симлинка (тоже >> _почти_ атомарное). Второе лучше (см. ниже). > Вот для этого у rsync есть --link-dest. Которым уже довольно давно > научился пользоваться rsnapshot. Поэтому создавать копию можно прямо > тем же rsync-ом в процессе. Ух, а вот это я прощелкал... >> > Отдельное развлечение случается когда у тебя параллельно работает >> > десяток jenkins-овских заданий, собирающих разные пакеты, зависящие >> > друг от друга. Может запросто получиться так, что задание 1 сделало >> > apt-get update, потом задание 2 выложило новую версию своего >> > пакета и перергенерировало packages, а потом задание 1 захотело >> > этот пакет поставить, потому что он у него Build-Depends. >> >> В таком раскладе либо задание 2 не должно удалять старую версию пакета >> (а делать это должен кто-то третий в конце всего прогона или еще по >> какому-то критерию "старая версия больше никому не нужна"), либо у >> тебя неконсистентность прямо в постановке задачи. >> >> То, что задание 2 перегенерировало packages, само по себе для задания >> 1, которое уже сделало apt-get update, по барабану. Важно, чтобы пакет >> оставался. > В принципе, конечно да. Если бы поднимать версию пакета при каждом > билде, можно было бы действовать и так. Хотя сформулировать критерий > "эта версия пакета больше никому не нужна" крайне нетривиально. > Но в процессе отладки пакета его можно пересобрать и десять, и двадцать > раз, и в распределенной системе сборки он каждый раз должен попадать во > внутренний репозиторий, доступный для других заданий. > Поэтому у меня сейчас во внутреннем репозитории допустима замена пакета > без изменения его версии. А вот тут уже неатоммарность пары apt-get > update - apt-get install вылезает в полный рост. А вот для "на автомате" я бы добавлял какой-нибудь изменяемый хвостик... И критерий "больше никому не нужна" — есть хвостик от автомата, версия не самая свежая, и файл старше некоторого интервала, за который любая сборка, которая могла бы его использовать, если она не зависла, должна была закончиться. С ручной сборкой, конечно, хуже. Вручную каждый раз хвостик менять... Впрочем, тоже можно заскриптовать. А когда у тебя пакет отладился, ты собираешь его без этого хвостика в версии. >> Другое дело, что race condition вида "у задания 1 прямо в процессе >> apt-get update могли оказаться Release и Packages разных версий >> репозитория" все равно остается. >> >> Чтобы его не было, см. выше про симлинк. Перед apt-get update делается >> readlink, прочитанное имя пишется в sources.list, и уже с этим > readlink по http? Можно и по http. Скрипт, который реагирует на запрос "мне, пожалуйста, актуальную строчку для sources.list для такого-то дистрибутива". Вот он уже на раз сделает readlink. >> отрезолвленным именем, где заведомо консистентный репозиторий, который >> уже никогда не поменяется, можно работать. > Это для отрелизенных пакетов я могу себе позволить хранить > заведомо-консистентные репозитории на каждый момент времени. Если это > делать по схеме rsnapshot-а, т.е. каждый пакет хранить один раз и > держать на него десяток хардлинков из разных снапшотов. > А если хранить репозитории вечно для всех промежуточных билдов, > успевших собрать хотя бы один пакет (а ведь туда для консистентности > придется копировать все остальные пакеты из старого репозитория) > никакого storage не хватит. Я не сказал "хранить вечно". Я сказал "никогда не поменяется". Но может быть удален целиком. Хранится вечно только то, что отрелизено. И да, хардлинки. Или, если аккуратно обходиться с версиями, то можно pool просто общий держать. >> > Прикрутить туда осмысленную систему exclusive и shared блокировок >> > при условии того, что задания крутятся на куче разных машин и в >> > репозиторий ходят apt-ом весьма нетривиально. >> >> Любая система с блокировками содержит race condition :) Один мутекс >> еще нет, а любая система уже да. > Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди, > способные грамотно спроектировать систему блокировок - найдутся. > > В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы > это один репозиторий, все убунты - другой, а каждая астра - отдельный) > тут хватит. > Основная проблема - гарантировать то, что при любых сбоях сборочного > задания, в том числе и при ошибке установки пакетов-зависимостей, > блокировка будет снята. Во-во. > Вообще говоря, для практических целей можно было бы обойтись > троекратной попыткой повтора пары apt-get update/apt-get install > с задержкой. Вероятность того что задание при этом обломится и > потребует ручного перезапуска упадет до практически приемлемой. ... или так.
Re: Генерация pool-based репозиториев
04.03.2019, Victor Wagner написал(а):
> Чтобы миррор всегда был консистентным, необходимо действовать в
> следующей последовательности:
>
> 1. Сначала скачать все новые пакеты
> 2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
> единомоментно атоммарной операцией из заменить.
> 3. Удалить более ненужные пакеты.
>
> А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
> файлы, а потом уже копирует новые. Ну и о том, что Release содержит
> контрольную сумму Packages и менять их нужно одновременно - тоже не в
> курсе.
У rsync есть много опций для delete. Вот например подходящие:
--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not during
--
Stanislav
Re: Генерация pool-based репозиториев
В Mon, 04 Mar 2019 23:10:10 +0300 Artem Chuprina пишет: > > Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом > _почти_ атомарная пара rename либо перевешивание симлинка (тоже > _почти_ атомарное). Второе лучше (см. ниже). Вот для этого у rsync есть --link-dest. Которым уже довольно давно научился пользоваться rsnapshot. Поэтому создавать копию можно прямо тем же rsync-ом в процессе. Правда, по-моему авторы всяких дебмирроров об этом пока не задумывались. > > > Отдельное развлечение случается когда у тебя параллельно работает > > десяток jenkins-овских заданий, собирающих разные пакеты, зависящие > > друг от друга. Может запросто получиться так, что задание 1 сделало > > apt-get update, потом задание 2 выложило новую версию своего > > пакета и перергенерировало packages, а потом задание 1 захотело > > этот пакет поставить, потому что он у него Build-Depends. > > В таком раскладе либо задание 2 не должно удалять старую версию пакета > (а делать это должен кто-то третий в конце всего прогона или еще по > какому-то критерию "старая версия больше никому не нужна"), либо у > тебя неконсистентность прямо в постановке задачи. > > То, что задание 2 перегенерировало packages, само по себе для задания > 1, которое уже сделало apt-get update, по барабану. Важно, чтобы пакет > оставался. В принципе, конечно да. Если бы поднимать версию пакета при каждом билде, можно было бы действовать и так. Хотя сформулировать критерий "эта версия пакета больше никому не нужна" крайне нетривиально. Но в процессе отладки пакета его можно пересобрать и десять, и двадцать раз, и в распределенной системе сборки он каждый раз должен попадать во внутренний репозиторий, доступный для других заданий. Поэтому у меня сейчас во внутреннем репозитории допустима замена пакета без изменения его версии. А вот тут уже неатоммарность пары apt-get update - apt-get install вылезает в полный рост. > Другое дело, что race condition вида "у задания 1 прямо в процессе > apt-get update могли оказаться Release и Packages разных версий > репозитория" все равно остается. > > Чтобы его не было, см. выше про симлинк. Перед apt-get update делается > readlink, прочитанное имя пишется в sources.list, и уже с этим readlink по http? > отрезолвленным именем, где заведомо консистентный репозиторий, который > уже никогда не поменяется, можно работать. Это для отрелизенных пакетов я могу себе позволить хранить заведомо-консистентные репозитории на каждый момент времени. Если это делать по схеме rsnapshot-а, т.е. каждый пакет хранить один раз и держать на него десяток хардлинков из разных снапшотов. А если хранить репозитории вечно для всех промежуточных билдов, успевших собрать хотя бы один пакет (а ведь туда для консистентности придется копировать все остальные пакеты из старого репозитория) никакого storage не хватит. У меня сейчас логи билдов всего лишь за год 700 гигов занимают. А репозитории имеют объем примерно на порядок -два больше, чем логи. > > Прикрутить туда осмысленную систему exclusive и shared блокировок > > при условии того, что задания крутятся на куче разных машин и в > > репозиторий ходят apt-ом весьма нетривиально. > > Любая система с блокировками содержит race condition :) Один мутекс > еще нет, а любая система уже да. Ну, слава богу, в конторе, которая занимается разработкой СУБД, люди, способные грамотно спроектировать систему блокировок - найдутся. В принципе, одного мутекса НА КАЖДЫЙ РЕПОЗИТОРИЙ (например, все дебианы это один репозиторий, все убунты - другой, а каждая астра - отдельный) тут хватит. Основная проблема - гарантировать то, что при любых сбоях сборочного задания, в том числе и при ошибке установки пакетов-зависимостей, блокировка будет снята. Вообще говоря, для практических целей можно было бы обойтись троекратной попыткой повтора пары apt-get update/apt-get install с задержкой. Вероятность того что задание при этом обломится и потребует ручного перезапуска упадет до практически приемлемой. -- Victor Wagner
Re: Генерация pool-based репозиториев
Victor Wagner -> debian-russian@lists.debian.org @ Mon, 4 Mar 2019 17:28:51
+0300:
> Чтобы миррор всегда был консистентным, необходимо действовать в
> следующей последовательности:
> 1. Сначала скачать все новые пакеты
> 2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
> единомоментно атоммарной операцией из заменить.
> 3. Удалить более ненужные пакеты.
> А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
> файлы, а потом уже копирует новые.
rsync --delete-after
и вообще почитать, какие там бывают варианты у delete.
> Ну и о том, что Release содержит контрольную сумму Packages и менять
> их нужно одновременно - тоже не в курсе.
А вот этого он уже не знает, конечно.
Есть еще чуть более хитрый вариант — cp -al, rsync в копию, и потом
_почти_ атомарная пара rename либо перевешивание симлинка (тоже _почти_
атомарное). Второе лучше (см. ниже).
> Отдельное развлечение случается когда у тебя параллельно работает
> десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
> друг от друга. Может запросто получиться так, что задание 1 сделало
> apt-get update, потом задание 2 выложило новую версию своего пакета
> и перергенерировало packages, а потом задание 1 захотело этот пакет
> поставить, потому что он у него Build-Depends.
В таком раскладе либо задание 2 не должно удалять старую версию пакета
(а делать это должен кто-то третий в конце всего прогона или еще по
какому-то критерию "старая версия больше никому не нужна"), либо у тебя
неконсистентность прямо в постановке задачи.
То, что задание 2 перегенерировало packages, само по себе для задания 1,
которое уже сделало apt-get update, по барабану. Важно, чтобы пакет
оставался.
Другое дело, что race condition вида "у задания 1 прямо в процессе
apt-get update могли оказаться Release и Packages разных версий
репозитория" все равно остается.
Чтобы его не было, см. выше про симлинк. Перед apt-get update делается
readlink, прочитанное имя пишется в sources.list, и уже с этим
отрезолвленным именем, где заведомо консистентный репозиторий, который
уже никогда не поменяется, можно работать.
> Прикрутить туда осмысленную систему exclusive и shared блокировок при
> условии того, что задания крутятся на куче разных машин и в репозиторий
> ходят apt-ом весьма нетривиально.
Любая система с блокировками содержит race condition :) Один мутекс еще
нет, а любая система уже да.
Re: Генерация pool-based репозиториев
On 3/4/19 1:01 AM, Stanislav Vlasov wrote: > 04.03.2019, Tim Sattarov написал(а): > >>> У меня reprepro свято уверен, что репозиторий на локальной машине. >>> >> у S3 и файловых систем на нём основанных есть одна забавная особенность: не >> поддерживает файлов с >> неизвестным заранее размером. >> то есть `cat >/mnt/s3fuse/file.txt` обломится >> Потому что это не ФС, а объектное хранилище > Извращение тех времён, когда на работе пытались сделать своё S3-хранилище: > https://github.com/stanislavvv/stdin2s3 > > Вполне себе пишет файл на s3 c stdin и неизвестным размером. > Использовался ровно так, как написано в README. > > Ну то есть объектное-то оно объектное, но докачку поддерживает. > О, прикольно, гляну. Спасибо :)
Re: Генерация pool-based репозиториев
On Mon, Mar 04, 2019 at 04:19:58PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov wrote: > > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: ... > > > > в принципе, залить файлы в хранилище много ума не нужно. > > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > > > экзотику и работать с ней как с локальным диском - бесценно. > > > У меня reprepro свято уверен, что репозиторий на локальной машине. > > > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > > на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий. > > Потому как автор её скорее всего просто не предполагал, что репозиторий > > может быть удалённым, а дороги к нему будут перепаханы и минированы. > Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто > привыкли, что типа "жосткий диск" он "рядом". Не только я, всё человечество к этому привыкло. Все пишут софт под эту парадигму, потому что диск в системнике и бэкап в соседнем это для большинства задач нормально по надёжности и оптимально по деньгам. А написать работающий с файлами транзакционно выверенный софт это столь муторно, что получается лишь у профессионалов, занимающихся базами данных и кластерами. У остальных обычно не получается. Например, стоит положить файловую 1С с 5-15 юзерами на нестабильный канал, как через 2-3 месяца она разлетается вдрызг, а техподдержка 1С тихо сопит и советует перейти на трёхзвенку, т.е. архитектуру с транзакционным слоем снизу. Там и диски по отношению к слою приложения оказываются локальными, неудивительно, что на том же канале трёхзвенка 1С стабильно работает. -- Eugene Berdnikov
Re: Генерация pool-based репозиториев
On Sun, 3 Mar 2019 15:32:47 +0300
Eugene Berdnikov wrote:
> On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote:
> Возможно, конкретно для reprepro проблемы нет, но в общем случае
> лучше делать репозиторий локальным, а с облаком синхронизовать после
> успешного завершения всех локальных транзакций, т.е. когда всё уже в
> файлах и в консистентном виде. Сохранить целостность при передаче в
> облако несложно, но это так лишь потому, что технология отработана --
> авторы rsync/etc тщательно продумали все возможные сценарии сбоев, и
> мы этим пользуемся.
C сохранением консистентности конкретно у репозиториев есть
определенные проблемы.
Я давно не смотрел на современные средства мирроринга репозиториев, но
когда мне это было надо, при мирроре возникала
проблема, что целевой миррор может оказаться неконсистентным пока
работа миррорящего скрипта не закончена.
Чтобы миррор всегда был консистентным, необходимо действовать в
следующей последовательности:
1. Сначала скачать все новые пакеты
2. Потом скопировать Packages{,.gz,.bz2} Release и Release.gpg и
единомоментно атоммарной операцией из заменить.
3. Удалить более ненужные пакеты.
А rsync --delete делает не так. Он СНАЧАЛА удаляет более ненужные
файлы, а потом уже копирует новые. Ну и о том, что Release содержит
контрольную сумму Packages и менять их нужно одновременно - тоже не в
курсе.
Отдельное развлечение случается когда у тебя параллельно работает
десяток jenkins-овских заданий, собирающих разные пакеты, зависящие
друг от друга. Может запросто получиться так, что задание 1 сделало
apt-get update, потом задание 2 выложило новую версию своего пакета
и перергенерировало packages, а потом задание 1 захотело этот пакет
поставить, потому что он у него Build-Depends.
Прикрутить туда осмысленную систему exclusive и shared блокировок при
условии того, что задания крутятся на куче разных машин и в репозиторий
ходят apt-ом весьма нетривиально.
--
Re: Генерация pool-based репозиториев
Eugene Berdnikov wrote: > On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > > Tim Sattarov wrote: > > > On 3/2/19 3:52 AM, Igor Savluk wrote: > > > > > > > > Можеш поставить dak там вообще postgresql. > > > я с aptly, потому что он умеет публиковать на амазоновский S3. > > > может ли это делать dak? > > > в принципе, залить файлы в хранилище много ума не нужно. > > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > > экзотику и работать с ней как с локальным диском - бесценно. > > У меня reprepro свято уверен, что репозиторий на локальной машине. > А у меня, к сожалению, нет уверенности в том, что при моргании сети, > на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий. > Потому как автор её скорее всего просто не предполагал, что репозиторий > может быть удалённым, а дороги к нему будут перепаханы и минированы. Он всегда такой, т.к. любая софтина пишет в неведомые дали. Эт вы просто привыкли, что типа "жосткий диск" он "рядом". > Возможно, конкретно для reprepro проблемы нет, но в общем случае лучше > делать репозиторий локальным, а с облаком синхронизовать после успешного > завершения всех локальных транзакций, т.е. когда всё уже в файлах и в > консистентном виде. Сохранить целостность при передаче в облако несложно, > но это так лишь потому, что технология отработана -- авторы rsync/etc > тщательно продумали все возможные сценарии сбоев, и мы этим пользуемся. За дядин счет можно хоть в три места бакапы бакапить. Лично для меня сдохший репозиторий с бинарными пакетами - неприятность, не стоящая того, чтоб засирать место на дисках, оно там для других целей больше нужно.
Re: Генерация pool-based репозиториев
04.03.2019, Tim Sattarov написал(а): >> У меня reprepro свято уверен, что репозиторий на локальной машине. >> > у S3 и файловых систем на нём основанных есть одна забавная особенность: не > поддерживает файлов с > неизвестным заранее размером. > то есть `cat >/mnt/s3fuse/file.txt` обломится > Потому что это не ФС, а объектное хранилище Извращение тех времён, когда на работе пытались сделать своё S3-хранилище: https://github.com/stanislavvv/stdin2s3 Вполне себе пишет файл на s3 c stdin и неизвестным размером. Использовался ровно так, как написано в README. Ну то есть объектное-то оно объектное, но докачку поддерживает. -- Stanislav
Re: Генерация pool-based репозиториев
On 3/3/19 6:31 AM, Andrey Jr. Melnikov wrote: > Tim Sattarov wrote: >> On 3/2/19 3:52 AM, Igor Savluk wrote: >>> >>> Можеш поставить dak там вообще postgresql. >> я с aptly, потому что он умеет публиковать на амазоновский S3. >> может ли это делать dak? >> в принципе, залить файлы в хранилище много ума не нужно. > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > экзотику и работать с ней как с локальным диском - бесценно. > У меня reprepro свято уверен, что репозиторий на локальной машине. > у S3 и файловых систем на нём основанных есть одна забавная особенность: не поддерживает файлов с неизвестным заранее размером. то есть `cat >/mnt/s3fuse/file.txt` обломится Потому что это не ФС, а объектное хранилище
Re: Генерация pool-based репозиториев
On 3/3/19 8:14 AM, Victor Wagner wrote: > > Но вот о чем совершенно не подумали авторы ни одной из рассмотренных > утилит, так это то, что Debian не единственный на свете дистрибутив. > При таком запросе я боюсь что всё закончится чем то вроде fpm[1] пол интернета этой фигнёй пакуют и радуются, что совместимы со всеми дистрибутивами 1: https://github.com/jordansissel/fpm/wiki
Re: Генерация pool-based репозиториев
В Sun, 3 Mar 2019 14:19:37 +0300 Aleksandr Sytar пишет: > сб, 2 мар. 2019 г. в 15:33, Victor Wagner : > > > В Sat, 2 Mar 2019 11:52:55 +0300 > > Igor Savluk пишет: > > > > > > База данных - это не единственное средство организовать дурацкий > > поиск. Вообще говоря, в deb-файле содержится более чем достаточно > > информации, чтобы сгенерировать Packages file entry. > > > > > База данных, наверно едиственный способ сделать это предсказуемо > быстро за ограниченное время. Сканирование deb-пакетов всегда будет > иметь сложность не менее O(n). Поэтому в общем случае так никто не > делает. При разумно-реалистичных N зачастую выгоднее сделать n! но при маленьком О, чем бороться за O(n) или O(log n) ценой увеличения O. Как правило, у людей, которые делают репозитории своих программ под Debian (каковой сценарий явно имели в виду авторы aptly и reprepro) имеется довольно небольшое количество пакетов. Поэтому нужно стремиться не ускорять генерацию файла Packages, а упрощать обработку ошибок при выкладывании. Типичная ошибки например, "в дженкинсе собралось не то и не так" или "при подъеме апстрим-версии забыли сбросить в единичку версию пакета". Или "пакет оказался настолько глюкавым, что мы его сейчас распубликуем обратно до следующего релиза". Но вот о чем совершенно не подумали авторы ни одной из рассмотренных утилит, так это то, что Debian не единственный на свете дистрибутив. Почему-то до сих пор мне попадались ровно два варианта: Либо мы не обращаем внимания на существование в природе чего либо, кроме нашего любимого дистрибутива, либо мы начинаем изобретать свой собственный формат пакетов, что приводит к невозможности подтягивания по зависимостям софта из пакетов, и самостоятельного пакетирования perl, python, openssl et cetera et cetera. -- Victor Wagner
Re: Генерация pool-based репозиториев
On Sun, Mar 03, 2019 at 02:31:02PM +0300, Andrey Jr. Melnikov wrote: > Tim Sattarov wrote: > > On 3/2/19 3:52 AM, Igor Savluk wrote: > > > > > > Можеш поставить dak там вообще postgresql. > > я с aptly, потому что он умеет публиковать на амазоновский S3. > > может ли это делать dak? > > в принципе, залить файлы в хранилище много ума не нужно. > При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то > экзотику и работать с ней как с локальным диском - бесценно. > У меня reprepro свято уверен, что репозиторий на локальной машине. А у меня, к сожалению, нет уверенности в том, что при моргании сети, на которое fuse выбросит I/O error, твоя приблуда не сломает репозиторий. Потому как автор её скорее всего просто не предполагал, что репозиторий может быть удалённым, а дороги к нему будут перепаханы и минированы. Возможно, конкретно для reprepro проблемы нет, но в общем случае лучше делать репозиторий локальным, а с облаком синхронизовать после успешного завершения всех локальных транзакций, т.е. когда всё уже в файлах и в консистентном виде. Сохранить целостность при передаче в облако несложно, но это так лишь потому, что технология отработана -- авторы rsync/etc тщательно продумали все возможные сценарии сбоев, и мы этим пользуемся. -- Eugene Berdnikov
Re: Генерация pool-based репозиториев
Tim Sattarov wrote: > On 3/2/19 3:52 AM, Igor Savluk wrote: > > > > > > Можеш поставить dak там вообще postgresql. > я с aptly, потому что он умеет публиковать на амазоновский S3. > может ли это делать dak? > в принципе, залить файлы в хранилище много ума не нужно. При наличии fuse - совсем не нужно. Смонтировать s3fs/sshfs/еще какую-то экзотику и работать с ней как с локальным диском - бесценно. У меня reprepro свято уверен, что репозиторий на локальной машине.
Re: Генерация pool-based репозиториев
сб, 2 мар. 2019 г. в 15:33, Victor Wagner : > В Sat, 2 Mar 2019 11:52:55 +0300 > Igor Savluk пишет: > > > База данных - это не единственное средство организовать дурацкий поиск. > Вообще говоря, в deb-файле содержится более чем достаточно информации, > чтобы сгенерировать Packages file entry. > > База данных, наверно едиственный способ сделать это предсказуемо быстро за ограниченное время. Сканирование deb-пакетов всегда будет иметь сложность не менее O(n). Поэтому в общем случае так никто не делает.
Re: Генерация pool-based репозиториев
On 3/2/19 3:52 AM, Igor Savluk wrote: > > > Можеш поставить dak там вообще postgresql. я с aptly, потому что он умеет публиковать на амазоновский S3. может ли это делать dak? в принципе, залить файлы в хранилище много ума не нужно. я сейчас пытаюсь вынести создание пакетов и публикацию их с Jenkins сервера с настроенным aptly на GitlabCI. в Gitlab всё происходит на уровне контейнеров, поэтому ни о какой базе которая бы мигрировала и обновлялась вслед за каждым билдом речи быть не может встаёт задача вынести базу куда то ещё, постгрес для этого в принципе подойдёт. Насколько умён dak, чтобы уметь закинуть сгенерированный пакет в репу не имея под рукой ничего кроме инструментов и эфемерного окружения Ну и внешней базы конечно...
Re: Генерация pool-based репозиториев
В Sat, 2 Mar 2019 11:52:55 +0300 Igor Savluk пишет: > On 26/02/2019 22.57, Victor Wagner wrote: > > В Tue, 26 Feb 2019 11:16:38 -0500 > > Tim Sattarov пишет: > > > >> On 2/26/19 4:24 AM, Victor Wagner wrote: > >>> Коллеги, > >>> > >>> А чем в наше время можно генерировать pool-based репозитории, > >>> КРОМЕ reprepro? > >> я использую для этого aptly > > > > Штука еще более высокоуровневая и навороченная, чем reprepro. > > Обладает тем же нредостатком - хочет испольовать какую-то левую > > базу данных. > > > Для твоих запросов тебе всеравно прийдется использовать утилиту с бд. База данных - это не единственное средство организовать дурацкий поиск. Вообще говоря, в deb-файле содержится более чем достаточно информации, чтобы сгенерировать Packages file entry. Я на самом деле уже выяснил, что apt-ftparchive generate при правильно описанном конфиге мою задачу решает. Ну или почти решает. Во всяком случае текстового filelist хватит для того, чтобы заменить базу данных. Поскольку единственная информация, которая не извлекается однозначно из самого пакета - это к какому suite он относится (и это сделано намеренно, потому что пакеты мигрируют из unstable в testing, testing превращается в stable, a stable в oldstable, а некоторые пакеты по-моему не пересобираются релиза по четыре). > Без них нет утилит. Можеш поставить dak там вообще postgresql. В Только у криворуких идиотов. > документации я так понял ты про архитектуру не читал и зачем эти > утилиты юзают бд ты смотрел? Потому что это вообще традиция современной IT. Нужно сайт, который обновляется через веб-интерфейс - лепят туда базу данных, нужно хранить закладки в браузере - лепят туда sqlite. Более того, пользоваться базами данных эти криворукие идиоты тоже не умеют, о referential integrity, например, вообще обычно не слышали и чем 2 НФ от 4 отличаются не в курсе. Использование dak с клиент-серверной БД для полного дебиановского архива еще можно как-то оправдать - там десятки тысяч пакетов. Но мне-то нужно от силы пара десятков пакетов, зато под 30 дистрибутивов, далеко не все из которых Debian и Ubuntu (отдельная призовая игра - это astra, которая использует deb-пакеты и apt, но при этом у нее codename означает вовсе не версию и для разных codename может быть разная политика версионирования). Поэтому если уж заводить базу данных, то ее надо заводить для всего этого хозяйства. а не отдельно для Debian, отдельно для Ubuntu. отдельно для RHEL. -- Victor Wagner
Re: Генерация pool-based репозиториев
On 26/02/2019 22.57, Victor Wagner wrote: В Tue, 26 Feb 2019 11:16:38 -0500 Tim Sattarov пишет: On 2/26/19 4:24 AM, Victor Wagner wrote: Коллеги, А чем в наше время можно генерировать pool-based репозитории, КРОМЕ reprepro? я использую для этого aptly Штука еще более высокоуровневая и навороченная, чем reprepro. Обладает тем же нредостатком - хочет испольовать какую-то левую базу данных. Для твоих запросов тебе всеравно прийдется использовать утилиту с бд. Без них нет утилит. Можеш поставить dak там вообще postgresql. В документации я так понял ты про архитектуру не читал и зачем эти утилиты юзают бд ты смотрел? У того хотя бы нет глобального (уровня юзера) конфигурационного файла и каждый репозиторий, в каком бы месте файловой системы он не находился, абсолютно незевисим. Ну и добавлять пакеты в репозиторий можно не только на основании файлов changes, но и отдельными .deb и .dsc. А здесь я этого как-то не увидел. Я помнится, в reprepro .changes-файлами намучался, когда мне потребовалось поддерживать всего-то три архитектуры.
Re: Генерация pool-based репозиториев
В Tue, 26 Feb 2019 11:16:38 -0500 Tim Sattarov пишет: > On 2/26/19 4:24 AM, Victor Wagner wrote: > > Коллеги, > > > > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ > > reprepro? > я использую для этого aptly > Снапшоты в aptly, конечно, замечательная штука. Но оно же не умеет ни yum, ни apt-rpm, а использовать для одних дистрибутивов один механизм снапшотов а для других - другой крайне неудобно. -- Victor Wagner
Re: Генерация pool-based репозиториев
On 26/02/2019 12:24, Victor Wagner wrote: А чем в наше время можно генерировать pool-based репозитории, КРОМЕ reprepro? https://wiki.debian.org/DebianRepository/Setup#mini-dak ? Просто нагуглил, сам не пробовал. -- sergio.
Re: Генерация pool-based репозиториев
В Tue, 26 Feb 2019 11:16:38 -0500 Tim Sattarov пишет: > On 2/26/19 4:24 AM, Victor Wagner wrote: > > Коллеги, > > > > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ > > reprepro? > я использую для этого aptly Штука еще более высокоуровневая и навороченная, чем reprepro. Обладает тем же нредостатком - хочет испольовать какую-то левую базу данных. У того хотя бы нет глобального (уровня юзера) конфигурационного файла и каждый репозиторий, в каком бы месте файловой системы он не находился, абсолютно незевисим. Ну и добавлять пакеты в репозиторий можно не только на основании файлов changes, но и отдельными .deb и .dsc. А здесь я этого как-то не увидел. Я помнится, в reprepro .changes-файлами намучался, когда мне потребовалось поддерживать всего-то три архитектуры. -- Victor Wagner
Re: Генерация pool-based репозиториев
On 2/26/19 4:24 AM, Victor Wagner wrote: > Коллеги, > > А чем в наше время можно генерировать pool-based репозитории, КРОМЕ > reprepro? я использую для этого aptly
