Раздача зеркала репозиптория по сети через rsync

[rits]

У кого нибудь имеется рабочий конфиг rsyncd.conf для раздачи файлов с зеркала репозитория? Покажите cat rsyncd.conf,
cat /etc/xinetd.d/rsync, cat /etc/xinetd.conf

[rits]

Уже разобрался, осталось только учесть тонкости безопасности.

# Настройка раздачи файлов репозитория ПО с помощью rsync-server
# Установка rsync-server

apt-get install rsync-server

# Настройка запуска rsync-server с помощью xinetd

cat /etc/xinetd.conf

Код: [Выделить]

# Simple configuration file for xinetd
# Закоментируем only_from = 127.0.0.1 для доступа с сетевых машин к службам
defaults
{
log_type = SYSLOG authpriv info
log_on_success = PID HOST DURATION
log_on_failure = HOST
instances = 100
per_source = 5
# only_from = 127.0.0.1
}

includedir /etc/xinetd.d
cat /etc/xinetd.d/rsync

Код: [Выделить]

# default: off
# включаем сервер rsync disable = no
service rsync
{
disable         = no
socket_type     = stream
wait            = no
user            = root
nice            = 10
rlimit_as       = 16M
server          = /usr/bin/rsync
server_args     = --daemon
}

cat /etc/rsyncd.conf

# Открываем доступ к на чтение к двум зеркалам с разных мест

lock file = /var/run/rsync.lock
log file = /var/log/rsyncd/rsyncd.log
pid file = /var/run/rsyncd.pid

# rpm [p9] rsync://lin-server-upd/AltLinuxP9/AltLinux p9/branch/x86_64 classic
[AltLinuxP9]
        path = /mnt/diskdata/ftp
        comment = Mirror AltLinux P9

# rpm [p10] rsync://lin-server-upd/AltLinuxP10/AltLinux10 p10/branch/x86_64 classic
[AltLinuxP10]
        path = /mnt/smb/documents/diskdata/ftp
        comment = Mirror AltLinux P10

# Запуск rsync сервера через xinetd
service xinetd start
# Установка автозагрузки в SysVinit
chkconfig xinetd on


# Расположение каталогов зеркал на сервере rsync

dirtree -L 4 /mnt/diskdata/ftp/

Код: [Выделить]

/mnt/diskdata/ftp/
└── AltLinux
    └── p9
        └── branch
            ├── files
            ├── i586
            ├── noarch
            ├── x86_64
            └── x86_64-i586
dirtree -L 4 /mnt/smb/documents/diskdata/ftp

Код: [Выделить]

/mnt/smb/documents/diskdata/ftp/
└── AltLinux10
    └── p10
        └── branch
            ├── files
            ├── i586
            ├── noarch
            ├── x86_64
            └── x86_64-i586
# Настройка подллючения репозиториев на клиентах
cat /etc/apt/sources.list.d/alt.list

# ALT Linux Platform 9
rpm [p9] rsync://lin-server-upd/AltLinuxP9/AltLinux p9/branch/x86_64 classic
rpm [p9] rsync://lin-server-upd/AltLinuxP9/AltLinux p9/branch/x86_64-i586 classic
rpm [p9] rsync://lin-server-upd/AltLinuxP9/AltLinux p9/branch/noarch classic

# ALT Linux Platform 9
#rpm [p10] rsync://lin-server-upd/AltLinuxP10/AltLinux10 p10/branch/x86_64 classic
#rpm [p10] rsync://lin-server-upd/AltLinuxP10/AltLinux10 p10/branch/x86_64-i586 classic
#rpm [p10] rsync://lin-server-upd/AltLinuxP10/AltLinux10 p10/branch/noarch classic

# Пример синхронизации зеркала репозитория p10 с серверов AltLinux с помощью sisyphus-mirror

sisyphus-mirror -c /etc/sisyphus-mirror/sisyphus-mirror_p10.conf -L /var/log/mirror

cat /etc/sisyphus-mirror/sisyphus-mirror_p10.conf | sed -e '/^#/d' -e '/^$/d'

Код: [Выделить]

SRCROOT=rsync://rsync.altlinux.org/ALTLinux
DESTROOT=/mnt/smb/documents/diskdata/ftp/AltLinux10
LIST="p10/branch"
ARCH="noarch i586 x86_64 x86_64-i586 x86_32"
LINK_LIST="p10/branch"
ARGS="-rltmvH --delete-delay --delete-excluded --stats"
INTERACTIVE=0
TMPDEST=.new
EXCLUDE_FILE=/etc/sisyphus-mirror/exclude
INCLUDE_FILE=/etc/sisyphus-mirror/include
RSHOME="$HOME/.sisyphus-mirror"
 

[Nicom]

Подскажите, rsync доступ к репозиториям даёт какой-то ощутимый прирост производительности на клиентах, по сравнению с FTP?
Или Вы это сделали для уменьшения нагрузки на сервер?

Я использую скрипт запускаемый раз в неделю по cron

Код: [Выделить]

#!/bin/bash

HOSTNAME="rsync.altlinux.org"
REPO="ALTLinux/p10/branch/"
LOCALDIR="/srv/ftp/ALTLinux/p10/branch/"
FEXCLUDE="exclude_ALTLinuxPx.lst"
LOGFILE="/var/log/mirror_repo/ALTLinuxP10.log"
LOCK="/var/lock/mirror_repo/ALTLinuxP10"

if [ -f "$LOCK" ]; then
    echo "Another copy of AltLinux-P10 script already running";
    exit 0;
else
    touch "$LOCK";
    echo -e '\n\n#################################################\n\t' >> "$LOGFILE";
    date >> "$LOGFILE";
    echo >> "$LOGFILE";
    rsync -aHv --partial --stats --timeout=1800 --delete --delete-after --delay-updates --exclude-from="$FEXCLUDE" "$HOSTNAME"::"$REPO" "$LOCALDIR" >> "$LOGFILE" 2>&1;
    rm -f "$LOCK";
fiа клиенты получают обновления по FTP.

Файл исключений, который используется для всех релизов exclude_ALTLinuxPx.lst

Код: [Выделить]

*debuginfo*
*arm/**
*aarch64/**
*armh/**
doc/**
*SRPMS*
contents_index
*.src.*
*ppc64le/**

[Speccyfighter]

Подскажите, rsync доступ к репозиториям даёт какой-то ощутимый прирост производительности на клиентах, по сравнению с FTP?

Скорее всего нет. Поскольку даже если кеш apt не очищать, при обновлении системы, в кеш apt скачиваются другие новые *.rpm файлы с другими именами.
Огромную разницу по трафику rsync даст при синхронизации локального зеркала и обновлении инсталляционного образа до текущего в свежей версии. Разница по трафику по rsync, по сравнению c http, может быть в гигабайтах.
Ключевая особенность rsync, - man rsync:
- Благодаря этому протоколу rsync передает только различия между двумя  наборами  файлов  через  сетевое  соединение,  используя  эффективный алгоритм поиска контрольных сумм (cheksum-search algorithm), описанный в сопровождающей этот пакет документации.

Как частный случай:
Например при обновлении по rsync имеющегося на винчестере инсталляционного образа alt-workstation-9.1-x86_64.iso до текущего alt-workstation-9.2-x86_64.iso, объём трафика будет точно не 5 гигабайт. Что может быть критично для пользователя с узким каналом.


Обновление образа до свежего по rsync

Например имеем образ объёмом в 1356300288 байт скачанный за 9 минут 48 секунд при анлиме в 25 мегабит:
http://nightly.altlinux.org/p10/release/
(обратите вниманние на разницу в форматах линка: rsync использует модуль nightly (после org и слэша))

Код: [Выделить]

$ rsync --progress rsync://nightly.altlinux.org/nightly/p10/release/alt-p10-mate-20210805-x86_64.iso ./
Welcome to ALT Linux Team public rsync archive!

alt-p10-mate-20210805-x86_64.iso
  1,356,300,288 100%    2.20MB/s    0:09:48 (xfr#1, to-chk=0/1)

sent 43 bytes  received 1,356,631,519 bytes  2,297,428.56 bytes/sec
total size is 1,356,300,288  speedup is 1.00


Код: [Выделить]

$ du -b ./alt-p10-mate-20210805-x86_64.iso
1356300288 ./alt-p10-mate-20210805-x86_64.iso

и его нужно обновить до свежей бета объёмом в 1356300288 байт

Код: [Выделить]

$ wget http://nightly.altlinux.org/p10/beta/alt-p10-mate-20210812-x86_64.iso
...
Длина: 1356300288 (1,3G) [application/octet-stream]
Сохранение в: «alt-p10-mate-20210812-x86_64.iso»

alt-p10-mate-20210812-x86_64.iso        0%[                                                                        ]  11,79M  4,17MB/s               ^C


Код: [Выделить]

$ rm -f ./alt-p10-mate-20210812-x86_64.iso

Зачем это ^^^^^^ нужно, - прерывание wget с удалением файла?
Чтобы получить размер образа в байтах, который возвратит wget. А альтовый сервер выводит размер образов в мегабайтах и гигабатах. Но не в байтах. Когда разница в объёме между образами заметна даже беглым взглядом.

Переименовываем текущий релиз в новую бета

Код: [Выделить]

$ mv ./alt-p10-mate-20210805-x86_64.iso ./alt-p10-mate-20210812-x86_64.iso

Синхронизируем:
http://nightly.altlinux.org/p10/beta/

Код: [Выделить]

$ rsync --progress rsync://nightly.altlinux.org/nightly/p10/beta/alt-p10-mate-20210812-x86_64.iso ./alt-p10-mate-20210812-x86_64.iso
Welcome to ALT Linux Team public rsync archive!

alt-p10-mate-20210812-x86_64.iso
  1,356,300,288 100%   15.40MB/s    0:01:23 (xfr#1, to-chk=0/1)

На 25-ти мегабитах, синхронизация прошла за 1 минуту 23 секунды на средней скорости 15.40MB/s, что просто нереально при используемом тарифе:

Код: [Выделить]

$ echo '15.40*8' | bc # мегабит
123.20

В пике, при синхронизации блоков, скорость синхронизации достигала 113MB/s, что просто за пределами фантастики. И при тарифе в 25 мегабит просто совершенно нереально:

Код: [Выделить]

$ echo '113*8' | bc # мегабит
904

И если бы эта скорость была бы реальным скачиванием, то тариф должен был быть не 25 мегабит, а 900 мегабит.

Но соль в том, что:
man rsync
- Благодаря этому протоколу rsync передает только различия между двумя  наборами  файлов  через  сетевое  соединение,  используя  эффективный алгоритм поиска контрольных сумм (cheksum-search algorithm), описанный в сопровождающей этот пакет документации.

Т.е. за 1 минуту 23 секунды, на синхронизации, максимум могло быть скачано, около 271974400 байт (~270 мегабайт)

Код: [Выделить]

25/8*1024^2*(60+23)
271974400.00000000000000000000


тариф_мегабит / бит_в_байте * перевод_мегабайт_в_байты * (секунд_в_минуте + секунды) = реально скачанных байт

Но в реальности их и того меньше, учитывая реальную пропускную способность сервер-клиент и что скорость скачивания не может быть всегда в максимуме по тарифу.


Выигрыш использования rsync для синхронизации образа до свежего, более чем очевиден. Это значительная экономия и времени и трафика.
И лет 12 назад, такой метод обновления образа был без вариантов. По тем временам, мой анлимовый adsl не слишком далеко ушел от диалапа. И скачивание образа в свежей версии в 2-4 гигабайта, было бы проблемой. Да и сейчас временами этот метод более чем актуален. Иногда на роутере, одновременно может одновременно сидеть до 5-6 клиетов. Да и внешний канал иногда временами сильно загружен. И здесь rsync даёт ошутимые преимущества. В общем и целом, такая же история и с синхронизацией локального зеркала.

[Speccyfighter]

...
Обновление образа до свежего по rsync
...

Занёс в справочник:
(содержание с ссылками, в первом соощении темы справочника)

Приёмы профессиональной работы в shell
Обновление образа до свежего по rsync
https://forum.altlinux.org/index.php?topic=32361.msg362433#msg362433

[rits]

Огромную разницу по трафику rsync даст при синхронизации локального зеркала и обновлении инсталляционного образа до текущего в свежей версии.

Спасибо за подробный анализ, кстати очень интересный прием скачивания образов. Даже не подумал, что так возможно. Взял на заметку.

Подскажите, rsync доступ к репозиториям даёт какой-то ощутимый прирост производительности на клиентах, по сравнению с FTP?
Или Вы это сделали для уменьшения нагрузки на сервер?

Пока не проверял по этим параметрам и чисто имперически не сравнивал. Все намного проще. У меня тоже все раздается по ftp(proftpd). На одном из серверов на диске 320ГБ стоит зеркало на p9 и нужно уже сейчас было пощупать переходы с p9 на p10 без переустановки на разном железе клиентов. Закачал зеркало p10 и из-за неимения места разместил на рейд разделе в этом же системнике. С китайским xml конфигом proftpd, с ходу не разобрался, как с разных каталогов организовать раздачу в сеть, вот решил rsync сервер поднять, так как минимум настроек.
Спасибо за скрипт.

[Speccyfighter]

Огромную разницу по трафику rsync даст при синхронизации локального зеркала и обновлении инсталляционного образа до текущего в свежей версии.

Спасибо за подробный анализ, кстати очень интересный прием скачивания образов. Даже не подумал, что так возможно. Взял на заметку.

В статью в справочнике, добавил комментарий к команде. Как вариант получения по rsync образа новой версии без потери текущего образа на винчестере. Очевидно, что это само-собой разумеется, но счёл необходимым добавить пояснение.