[sisyphus] специфика wget

[sisyphus] специфика wget

[Vladimir]

Привет всем.

Так как в rsync после 2.6.2 несколько изменилось поведение ключей,
для удаленной синхронизации стал больше внимания уделять wget.
При этом были замечены странности, по которым хотелось бы
услышать отклики специалистов.

Почему то в файле .listing, полученном с разных ftp в одном случае
используется "возврат каретки, перевод строки", в другом только
"перевод строки". Первый вариант, например, с сайта ftp.altlinux.ru,
второй, например, с ftp.kaspersky.com (там несколько серверов и
иногода получается первый вариант). Конечно, это не проблема
и в sh сценарии можно прогнать .listing через "фильтр-нормализатор".
Вместе с тем вопрос. Почему это не делает сам wget?

Владимир

Re: [sisyphus] специфика wget

[Dmitry V. Levin]

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

Hi,

On Fri, Dec 24, 2004 at 01:02:04PM +0300, Vladimir wrote:
> Так как в rsync после 2.6.2 несколько изменилось поведение ключей,

Что именно в поведении rsync вас беспокоит?

> для удаленной синхронизации стал больше внимания уделять wget.

Небезопасная это штука - wget.


-- 
ldv

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

Re: [sisyphus] специфика wget

[Vladimir]

Dmitry V. Levin пишет:

>Hi,
>
>On Fri, Dec 24, 2004 at 01:02:04PM +0300, Vladimir wrote:
>  
>
>>Так как в rsync после 2.6.2 несколько изменилось поведение ключей,
>>    
>>
>
>Что именно в поведении rsync вас беспокоит?
>
>  
>

У меня синхронизация репозитория настроена примерно так.

Имеются вспомогательный каталог для синхронизации и каталог рабочий.
В "установившемся" состоянии в рабочем каталоге лежат реальные
файлы, а в дополнительном - symlinks на них.

Раньше, при синхронизации, rsync удалял устаревшие ссылки и загружал новые
файлы. После этого у новых файлов проверялись md5sum и gpg sign.
Если все OK, то файлы перемещались в "рабочий" репозиторий, замещаясь
ссылками на них. Если нет, то перемещались в "карантин".

Дополнительно, из рабочего каталога во временную "корзину" уходили
файлы с удаленными ссылками. Это же "ядро" хорошо работает и с
off-line синхронизацией от CD срезов Sysiphus.

Теперь rsync воспринимает гибкую ссылку в dest каталоге как "неправильный"
файл. Т.е. удаляет все гибкие ссылки, на какие бы файлы они не указывали и
выполняет синхронизацию "с нуля".

Ключи в команде для синхронизации выглядят так:

 rsync -avz --delete --progress --copy-links 
rsync.altlinux.org::ALTLinux/updates/Master/2.4/i586/RPMS.updates/ 
${LOCAL_PATH}

и работает по разному в версии 2.6.2 и 2.6.3
В списке изменений для версии 2.6.3 написано об исправлении ошибки для 
ключа --copy-links и
появлении нового ключа --keep-dirlinks. Но это не совсем то (нужно что 
то типа --keep-symlinks).
Попытка подобрать другие ключи для получения старого результата не удалась.

Владимир

Re: [sisyphus] специфика wget

[Ivan Fedorov]

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

Vladimir пишет:

> У меня синхронизация репозитория настроена примерно так.
> 
> Имеются вспомогательный каталог для синхронизации и каталог рабочий.
> В "установившемся" состоянии в рабочем каталоге лежат реальные
> файлы, а в дополнительном - symlinks на них.
> 
> Раньше, при синхронизации, rsync удалял устаревшие ссылки и загружал новые
> файлы. После этого у новых файлов проверялись md5sum и gpg sign.
> Если все OK, то файлы перемещались в "рабочий" репозиторий, замещаясь
> ссылками на них. Если нет, то перемещались в "карантин".
> 
> Дополнительно, из рабочего каталога во временную "корзину" уходили
> файлы с удаленными ссылками. Это же "ядро" хорошо работает и с
> off-line синхронизацией от CD срезов Sysiphus.
> 
> Теперь rsync воспринимает гибкую ссылку в dest каталоге как "неправильный"
> файл. Т.е. удаляет все гибкие ссылки, на какие бы файлы они не указывали и
> выполняет синхронизацию "с нуля".
> 
> Ключи в команде для синхронизации выглядят так:
> 
> rsync -avz --delete --progress --copy-links
> rsync.altlinux.org::ALTLinux/updates/Master/2.4/i586/RPMS.updates/
> ${LOCAL_PATH}
> 
> и работает по разному в версии 2.6.2 и 2.6.3
> В списке изменений для версии 2.6.3 написано об исправлении ошибки для
> ключа --copy-links и
> появлении нового ключа --keep-dirlinks. Но это не совсем то (нужно что
> то типа --keep-symlinks).
> Попытка подобрать другие ключи для получения старого результата не удалась.

Ну во первых прочтите man rsync ПОЛНОСТЬЮ.

А во вторых, лучше научитесь пользоваться --link-dest - куда более
правильный вариант.

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

Re: [sisyphus] специфика wget

[Vladimir]

Ivan Fedorov пишет:

>>Ключи в команде для синхронизации выглядят так:
>>
>>rsync -avz --delete --progress --copy-links
>>rsync.altlinux.org::ALTLinux/updates/Master/2.4/i586/RPMS.updates/
>>${LOCAL_PATH}
>>
>>и работает по разному в версии 2.6.2 и 2.6.3
>>В списке изменений для версии 2.6.3 написано об исправлении ошибки для
>>ключа --copy-links и
>>появлении нового ключа --keep-dirlinks. Но это не совсем то (нужно что
>>то типа --keep-symlinks).
>>Попытка подобрать другие ключи для получения старого результата не удалась.
>>    
>>
>
>Ну во первых прочтите man rsync ПОЛНОСТЬЮ.
>
>А во вторых, лучше научитесь пользоваться --link-dest - куда более
>правильный вариант.
>  
>


--link-dest=DIR Не то.
Мне нужно, чтобы увидив в dest каталоге symlink, rsync сравнивал удаленный
файл не с самой гибкой ссылкой, а с файлом на который она указывает.

Старый rsync так и делал, с новым не получается.

Владимир

Re: [sisyphus] специфика wget

[Ivan Fedorov]

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

Vladimir пишет:
>>
>>
>> Ну во первых прочтите man rsync ПОЛНОСТЬЮ.
>>
>> А во вторых, лучше научитесь пользоваться --link-dest - куда более
>> правильный вариант.
>>  
>>
> 
> 
> --link-dest=DIR Не то.
> Мне нужно, чтобы увидив в dest каталоге symlink, rsync сравнивал удаленный
> файл не с самой гибкой ссылкой, а с файлом на который она указывает.
> 

ЗАЧЕМ вам симлинки, если есть хардлинки???

Я так например ежедневно обновляю
ftp://sisyphus.irkutsk.ru/pub/distributions/ALTLinux/Sisyphus-daily/

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

Re: [sisyphus] использование rsync

[Dmitry V. Levin]

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

Hi,

On Fri, Dec 24, 2004 at 02:58:27PM +0300, Vladimir wrote:
> Dmitry V. Levin пишет:
> >On Fri, Dec 24, 2004 at 01:02:04PM +0300, Vladimir wrote:
> >
> >>Так как в rsync после 2.6.2 несколько изменилось поведение ключей,
> >
> >Что именно в поведении rsync вас беспокоит?
> 
> У меня синхронизация репозитория настроена примерно так.
> 
> Имеются вспомогательный каталог для синхронизации и каталог рабочий.
> В "установившемся" состоянии в рабочем каталоге лежат реальные
> файлы, а в дополнительном - symlinks на них.
> 
> Раньше, при синхронизации, rsync удалял устаревшие ссылки и загружал новые
> файлы. После этого у новых файлов проверялись md5sum и gpg sign.
> Если все OK, то файлы перемещались в "рабочий" репозиторий, замещаясь
> ссылками на них. Если нет, то перемещались в "карантин".
> 
> Дополнительно, из рабочего каталога во временную "корзину" уходили
> файлы с удаленными ссылками. Это же "ядро" хорошо работает и с
> off-line синхронизацией от CD срезов Sysiphus.

Немного другую схему, реализующую описанную выше задачу, можно посмотреть
на следующем примере:

1. создаём модель:
$ mkdir src dst backup
$ touch src/same src/new dst/old
$ cp -a src/same dst/
$ echo src >src/changed
$ echo dest >dst/changed

2. готовим каталог для синхронизации:
$ cp -al dst new

3. закачиваем:
$ rsync -rt src/ new/ --partial --delete-after --backup --backup-dir=$PWD/backup

4. анализируем результат:
$ find backup -type f
backup/changed
backup/old
$ find new -type f -links 1
new/changed
new/new
$ find new -type f -not -links 1
new/same


-- 
ldv

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

Re: [sisyphus] использование rsync

[Ivan Fedorov]

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

Dmitry V. Levin пишет:
>>Дополнительно, из рабочего каталога во временную "корзину" уходили
>>файлы с удаленными ссылками. Это же "ядро" хорошо работает и с
>>off-line синхронизацией от CD срезов Sysiphus.
> 
> 
> Немного другую схему, реализующую описанную выше задачу, можно посмотреть
> на следующем примере:
> 
> 1. создаём модель:
> $ mkdir src dst backup
> $ touch src/same src/new dst/old
> $ cp -a src/same dst/
> $ echo src >src/changed
> $ echo dest >dst/changed
> 
> 2. готовим каталог для синхронизации:
> $ cp -al dst new
> 
> 3. закачиваем:
> $ rsync -rt src/ new/ --partial --delete-after --backup --backup-dir=$PWD/backup

IMHO лучше 2 и 3 объеденить, используя ключ --link-dest у rsync.
Результат тот же, но немного быстрее, и за 1 проход...
> 
> 4. анализируем результат:
> $ find backup -type f
> backup/changed
> backup/old
> $ find new -type f -links 1
> new/changed
> new/new
> $ find new -type f -not -links 1
> new/same

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

Re: [sisyphus] использование rsync

[fmfm]

Dmitry V. Levin пишет:

>>У меня синхронизация репозитория настроена примерно так.
>>
>>Имеются вспомогательный каталог для синхронизации и каталог рабочий.
>>В "установившемся" состоянии в рабочем каталоге лежат реальные
>>файлы, а в дополнительном - symlinks на них.
>>
>>Раньше, при синхронизации, rsync удалял устаревшие ссылки и загружал новые
>>файлы. После этого у новых файлов проверялись md5sum и gpg sign.
>>Если все OK, то файлы перемещались в "рабочий" репозиторий, замещаясь
>>ссылками на них. Если нет, то перемещались в "карантин".
>>
>>Дополнительно, из рабочего каталога во временную "корзину" уходили
>>файлы с удаленными ссылками. Это же "ядро" хорошо работает и с
>>off-line синхронизацией от CD срезов Sysiphus.
>>    
>>
>
>Немного другую схему, реализующую описанную выше задачу, можно посмотреть
>на следующем примере:
>
>1. создаём модель:
>$ mkdir src dst backup
>$ touch src/same src/new dst/old
>$ cp -a src/same dst/
>$ echo src >src/changed
>$ echo dest >dst/changed
>
>2. готовим каталог для синхронизации:
>$ cp -al dst new
>
>3. закачиваем:
>$ rsync -rt src/ new/ --partial --delete-after --backup --backup-dir=$PWD/backup
>
>4. анализируем результат:
>$ find backup -type f
>backup/changed
>backup/old
>$ find new -type f -links 1
>new/changed
>new/new
>$ find new -type f -not -links 1
>new/same
>
>  
>

Прошу прощения за длительный off-line

Когда то этот код у меня работал с hardlink. Потом выяснилось, что это
решение не может считаться универсальным и вот почему.

Например, может быть несколько "рабочих" репозиториев с общими пакетами,
которые являются hardlink. В этом случае выяснение вопроса
"сколько hardlinks у пакета" без дополнительных уточнений
не содержит всей необходимой информации.
SymLinks, напротив,  хорошо изолируют "рабочую" область от "загрузочной" 
при
минимальных требованиях к дисковому пространству.

Еще одна причина "неуниверсальности" hardlinks в следующем. С symlinks 
становится удобной
загрузка вручную. Т.е. можно в mc удалить устаревшие ссылки и копировать 
новые
пакеты в "загрузочной" области. Текущий промежуточный результат в mc виден
"невооруженным" глазом. Когда все сделано, выполняется загрузочный сценарий
(или наоборот, rollback).

Изоляция областей - предпосылка для модульности кода. Например, код для 
off-line
импорта со сменных CD процентов на 70 использует код для on-line 
синхронизации
по сети. Как дополнение. Чтобы добавить возможность синхронизации на wget
мне потребовалось дописать и протестировать только одну функцию (и добавить
пункт в меню).

Таким образом, неизменяемое --resolv-dst-symlinks=off в rsync это потеря 
функциональности.

Владимир