[devel] по поводу security-announces & mirrors

[devel] по поводу security-announces & mirrors

[Denis Ovsienko]

Господа! (до чего удобное обращение, дам-то нету ;)
На фоне сегодняшней обоймы писем от security-announce это видно особенно
хорошо: у нас не все зеркала на момент публикации синхронизированы.
Давайте как-то контролировать это дело, иначе эффект от зеркал падает
порядочно. Вот сидит админ на работе, получает security-announce, а у него
несколько десятков машин настроено на (например) ftp.linux.kiev.ua,
который синхронизируется поздней ночью. Варианты его действий:
1. Перестраивает все машины на updates.altlinux.com, при этом эффект от
киевского зеркала в данном случае нулевой.
2. Делает как я когда-то, то есть держит локальный ftp с updates, который
синхронизирует по крону или/и по команде, а все машины строит на это своё
зеркальце. Не все так делают, даже редко кто, я бы сказал.
3. Проявляет сознательность и уходит домой, не сделав dist-upgrade, чтобы
утром вытянуть пакеты с зеркала. Утром приходит и считает неприятные
сюрпризы.
Давайте немного изменим процедуру security-announce: как только обновился
updates.altlinux.com, ответственное лицо в офисе провоцирует серверы из
sources.list синхронизироваться. Как --- детали. Где-то есть 24/7
techsupport, где-то хостер может дать (restricted) shell для запуска
rsync, где-то формочку можно на PHP прикрутить с паролем, которая будет
дропать где-то триггер, который кроновская задача скушает. Способов масса.
Так вот: пусть на эту процедуру отводится 30 минут, к примеру. По их
истечении в письмо от security-announce нужно будет вставить фразу:
"Зеркала ftp.domain1.com, ftp.domain2.ru и ftp.domain3.com на момент
отправки письма синхронизированы и содержат данное обновление. Для их
использования отредактируйте файл /etc/apt/sources.list. Остальные зеркала
синхронизируются в обычном порядке."
И уже это письмо рассылать.
Я думаю, такой подход сильно облегчит жизнь администраторам наших систем и
выгодно отразится на ALT Linux Team вообще.

--
    DO4-UANIC

Re: [devel] по поводу security-announces & mirrors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Mon, Aug 04, 2003 at 09:09:10PM +0300, Denis Ovsienko wrote:
> Господа! (до чего удобное обращение, дам-то нету ;)
> На фоне сегодняшней обоймы писем от security-announce это видно особенно
> хорошо: у нас не все зеркала на момент публикации синхронизированы.
> Давайте как-то контролировать это дело, иначе эффект от зеркал падает
> порядочно. Вот сидит админ на работе, получает security-announce, а у него
> несколько десятков машин настроено на (например) ftp.linux.kiev.ua,
> который синхронизируется поздней ночью. Варианты его действий:
> 1. Перестраивает все машины на updates.altlinux.com, при этом эффект от
> киевского зеркала в данном случае нулевой.
> 2. Делает как я когда-то, то есть держит локальный ftp с updates, который
> синхронизирует по крону или/и по команде, а все машины строит на это своё
> зеркальце. Не все так делают, даже редко кто, я бы сказал.
> 3. Проявляет сознательность и уходит домой, не сделав dist-upgrade, чтобы
> утром вытянуть пакеты с зеркала. Утром приходит и считает неприятные
> сюрпризы.

Эта проблема есть у большинства зеркалируемых дистрибутивов.

> Давайте немного изменим процедуру security-announce: как только обновился
> updates.altlinux.com, ответственное лицо в офисе провоцирует серверы из
> sources.list синхронизироваться. Как --- детали. Где-то есть 24/7
> techsupport, где-то хостер может дать (restricted) shell для запуска
> rsync, где-то формочку можно на PHP прикрутить с паролем, которая будет
> дропать где-то триггер, который кроновская задача скушает. Способов масса.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] по поводу security-announces & mirrors

[Denis Ovsienko]

> Эта проблема есть у большинства зеркалируемых дистрибутивов.
Можно решить её первыми.

> > Давайте немного изменим процедуру security-announce: как только обновился
> > updates.altlinux.com, ответственное лицо в офисе провоцирует серверы из
> > sources.list синхронизироваться. Как --- детали. Где-то есть 24/7
> > techsupport, где-то хостер может дать (restricted) shell для запуска
> > rsync, где-то формочку можно на PHP прикрутить с паролем, которая будет
> > дропать где-то триггер, который кроновская задача скушает. Способов масса.
>
> Именно эта масса и доставляет проблемы.
> Если бы механизм досрочного зеркалирования можно было бы запустить
> каким-нибудь одним, желательно неинтерактивным способом, то это можно было
> бы попробовать реализовать.
grep "# *Master" /etc/apt/sources.list|wc -l
даёт 12 сайтов, включая основной. Если бы у нас было 500 официальных
зеркал, тогда задача была бы труднее. Мне кажется, один из самых
простых вариантов, на которые могут согласиться держатели зеркал --- через
procmail. Тогда можно будет инициировать процесс неинтерактивно. А чтобы
исключить возможность abuse, можно придумать что-нибудь с ключами gpg или
проверкой времени последнего срабатывания rsync.
При таком варианте желающему завести зеркало можно будет брать этот скрипт
и посылать заявку на mirror-update-request@altlinux.ru, где mailman её
обработает и при следующем security announce нужно будет только
предварительно черкнуть письмо в mirror-update@altlinux.ru, а потом
вставить те зеркала, которые отчитались о зеркальности в течение получаса.
Вроде бы рабочая схема...

--
    DO4-UANIC

Re: [devel] по поводу security-announces & mirrors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Mon, Aug 04, 2003 at 11:19:14PM +0300, Denis Ovsienko wrote:
> > > Давайте немного изменим процедуру security-announce: как только обновился
> > > updates.altlinux.com, ответственное лицо в офисе провоцирует серверы из
> > > sources.list синхронизироваться. Как --- детали. Где-то есть 24/7
> > > techsupport, где-то хостер может дать (restricted) shell для запуска
> > > rsync, где-то формочку можно на PHP прикрутить с паролем, которая будет
> > > дропать где-то триггер, который кроновская задача скушает. Способов масса.
> >
> > Именно эта масса и доставляет проблемы.
> > Если бы механизм досрочного зеркалирования можно было бы запустить
> > каким-нибудь одним, желательно неинтерактивным способом, то это можно было
> > бы попробовать реализовать.
> grep "# *Master" /etc/apt/sources.list|wc -l
> даёт 12 сайтов, включая основной. Если бы у нас было 500 официальных
> зеркал, тогда задача была бы труднее. Мне кажется, один из самых
> простых вариантов, на которые могут согласиться держатели зеркал --- через
> procmail. Тогда можно будет инициировать процесс неинтерактивно. А чтобы
> исключить возможность abuse, можно придумать что-нибудь с ключами gpg или
> проверкой времени последнего срабатывания rsync.

На самом деле нужно и то, и другое.

> При таком варианте желающему завести зеркало можно будет брать этот скрипт
> и посылать заявку на mirror-update-request@altlinux.ru, где mailman её
> обработает и при следующем security announce нужно будет только
> предварительно черкнуть письмо в mirror-update@altlinux.ru, а потом
> вставить те зеркала, которые отчитались о зеркальности в течение получаса.
> Вроде бы рабочая схема...

Осталось только написать проверяющий скрипт...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: по поводу security-announces & mirrors

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Tue, 5 Aug 2003 00:24:14 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

<skipped/>

> > При таком варианте желающему завести зеркало можно будет
> > брать этот скрипт и посылать заявку на
> > mirror-update-request@altlinux.ru, где mailman её обработает
> > и при следующем security announce нужно будет только
> > предварительно черкнуть письмо в mirror-update@altlinux.ru, а
> > потом вставить те зеркала, которые отчитались о зеркальности
> > в течение получаса. Вроде бы рабочая схема...
> 
> Осталось только написать проверяющий скрипт...

Процесс зеркалирования всегда инициируется зеркалом?

Зеркало забирает файлы всегда с altlinux.*, или может с соседних
зеркал?

Есть вариант синхронизации rsync over ssh, инициируемый с
altlinux.*

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: по поводу security-announces & mirrors

[Denis Ovsienko]

> > Осталось только написать проверяющий скрипт...
> Процесс зеркалирования всегда инициируется зеркалом?
Это как посмотреть. По приходу правильного письма на зеркало скрипт
синхронизирует updates/ и отсылает отчёт.

> Зеркало забирает файлы всегда с altlinux.*, или может с соседних
> зеркал?
Оттуда, куда несколько минут назад были выложены обновления, то есть с
updates.altlinux.com. В штатном порядке пусть хоть на компактах таскают, а
тут нужна оперативность и достоверность.

> Есть вариант синхронизации rsync over ssh, инициируемый с
> altlinux.*
Не все согласятся у себя ставить специальный шелл для rsync over ssh или
тем более давать unrestricted shell.

--
    DO4-UANIC

Re: [devel] Re: по поводу security-announces & mirrors

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On Tue, Aug 05, 2003 at 12:34:07PM +0400, Vitaly Ostanin wrote:
> > > При таком варианте желающему завести зеркало можно будет
> > > брать этот скрипт и посылать заявку на
> > > mirror-update-request@altlinux.ru, где mailman её обработает
> > > и при следующем security announce нужно будет только
> > > предварительно черкнуть письмо в mirror-update@altlinux.ru, а
> > > потом вставить те зеркала, которые отчитались о зеркальности
> > > в течение получаса. Вроде бы рабочая схема...

Примерно так и говорил (кажется) год назад.

> > Осталось только написать проверяющий скрипт...

Я могу попробовать.  Все равно ftp.linux.kiev.ua зеркалится с
ftp.altlinux.org.ua (2 pilot: => ftp лагает чуть _больше_), равно
как и наш офис, и меня не устраивает cronjob.

> Процесс зеркалирования всегда инициируется зеркалом?

Полагаю, да.  Другое дело, что решение о инициации по-хорошему
должно быть семафоренным, а не таймерным.

Мне кажется, что осмысленным вариантом есть подписанное письмо на
некий mirror-update@, которое может содержать в качестве полезной
нагрузки пару полей статистики (+/- байт/пакетов) и как минимум
список обновленных пакетов, возможно -- с --lastchange.  Роботов
это не напряжет, а люди получат дополнительное удобство "за те же
деньги".

> Зеркало забирает файлы всегда с altlinux.*, или может с
> соседних зеркал?

Думаю, всегда с, если речь идет об официальном зеркале.

> Есть вариант синхронизации rsync over ssh, инициируемый с
> altlinux.*

Нет такого варианта.

PS: разбивать sources.list с ортогонализацией используемого
зеркала и дистрибутива не предвидится?  Вместе с добавлением туда
не только updates, но и .main?

PPS: s/ftp.linux.kiev.ua/ftp.altlinux.org.ua/g там может быть
уместен, хотя, вероятно, быстрее эти записи будут перекинуты на
один хост (когда перетащу дебиан).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: по поводу security-announces & mirrors

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Mon, 4 Aug 2003 21:09:10 +0300 (EEST)
Denis Ovsienko <pilot@dgtu.donetsk.ua> wrote:

> Господа! (до чего удобное обращение, дам-то нету ;)

Есть.

> На фоне сегодняшней обоймы писем от security-announce это видно
> особенно хорошо: у нас не все зеркала на момент публикации
> синхронизированы. Давайте как-то контролировать это дело, иначе
> эффект от зеркал падает порядочно. 

Я бы предложил дублировать (ссылками) security updates,
выкладываемые в sisyphus, в отдельном каталоге/репозитории,
откуда их проще добыть, например, rsync'ом.

Например, я бы в таком случае сразу запустил бы не синхронизацию
всего sisyphus, а сначала security updates.

Кстати, рассинхронизация зеркал - ещё одна причина для указания
номера "хорошей" сборки из Sisyphus в анонсах.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: по поводу security-announces & mirrors

[Denis Ovsienko]

> > Господа! (до чего удобное обращение, дам-то нету ;)
> Есть.
Дамы и господа! :)

> Я бы предложил дублировать (ссылками) security updates,
> выкладываемые в sisyphus, в отдельном каталоге/репозитории,
> откуда их проще добыть, например, rsync'ом.
Для Sisyphus, на мой взгляд, нужно ещё хорошо всё обдумать, потому что так
просто это не решится. Давайте сделаем для начала часть, касающуюся
обновлений релизов, так как именно они являются рабочими системами.

> Например, я бы в таком случае сразу запустил бы не синхронизацию
> всего sisyphus, а сначала security updates.
Я в оригинальном письме имел в виду не "сначала", а "только", иначе в
полчаса security team не уложится.

> Кстати, рассинхронизация зеркал - ещё одна причина для указания
> номера "хорошей" сборки из Sisyphus в анонсах.
Небесполезная опция.

--
    DO4-UANIC

Re: [devel] Re: по поводу security-announces & mirrors

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Tue, Aug 05, 2003 at 12:31:28PM +0400, Vitaly Ostanin wrote:
> Я бы предложил дублировать (ссылками) security updates,
> выкладываемые в sisyphus, в отдельном каталоге/репозитории,
> откуда их проще добыть, например, rsync'ом.

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

Чувствительные места _не_ рекомендуется держать на сизифе.
Совсем.

Если кто держит -- есть подозрение, что он выкрутится из такой
ситуации, например, кронированием последовательности:

rsync updates/$prev_stable
apt-get update; apt-get upgrade
rsync Sisyphus/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]