Синхронизация файлов и прав

[capricious]

Добрый день

есть необходимость ежедневно синхронизировать данные с Netware 6.5 ( несколько серверов) на OES2 SP2a (linux) + права на файловую систему. Запускаться все (скрипты ) должно с сервера приемника.

Если по поводу переноса файлов вопросов нет - это rsync , то как права синхрить (на раз два) пока не понятно.

Если бы это надо сделать один раз то вопросов нет , тем же Adrem Server Managerom можно быстро управиться .

Кто что думает по этому поводу ?

Может сначала на Netware по крону запускать trustee.nlm а потом результат преобразовывать в правильный вид и скармливать линуксовой команде rights ?

**************** из форума ***************************

there is one such utility (it is actually a part of migfiles)

if you take a look in /opt/novell/ncpserv/sbin/ of your OES2 server you will find a utility "tcnvlnx.nlm"

Copy this to your sys:\system directory on netware and just load the file.
It will scan all filerights and ownerships of volumes and put it in xml files located in sys:\etc\tcnvlnx\


----------------- Caution, the following can mess up your server ---------------------
For the really brave admins, this file is the exact same syntax as the file _NETWARE\.trustee_database.xml on your OES2 volume.

You can replace this trustee_database file with the generated file as following:
copy the volume.xml to the _NETWARE directory
after that, as root issue the commands :

- chmod 700 .trustee_database.xml
- mv .trustee_database.xml .trustee_database.xml.old
- cp <volume.xml> .trustee_database.xml
- chmod 000 .trustee_database.xml

after this action, restart your server to let NSS read the XML file (only at startup of NSS it seems).

Кто пробовал ?

Hi,

Here is a part of a script I wrote to migrate data from Netware to OES2.

I use mls and migrights which are installed by novell-migration.rpm

migcred -i NWsrvIPaddr -l
#you are prompted to enter your credentials

mls -s NWsrvIPaddr -v DATA:/DIR --use-casa > /tmp/trustees.yaml
sed -i -e 's#'DATA:/DIR'#'OESVOLNAME:/OESPath'#' /tmp/trustbar.yaml
#In case of the paths are not the same on the source and the target
sed -i -e 's/file/dst-file/' /tmp/trustbar.yaml

migrights -i /tmp/trustbarUTF8.yaml

It works well for me.

*********************** из документации ****************************

Tree-to-Tree Migration with Trustees Already Migrated to the New Tree and Reorganized in the New Tree.
The following example shows how to migrate data from a source NetWare server in one tree to a target OES 2 Linux server in another tree. In this example, the target volume is an NSS volume, and the users have already been migrated by using tools like Novell Identity Manager so that they now reside in different contexts in the target tree. In this example, the migration tools are used only to only migrate the data and map the trustees correctly.

Create a list of files and trustees on volume V1 on the source server with IP address 192.168.1.3:

mls -s 192.168.1.3 -V V1 > mls.yaml

Match the users on the source server to the users on the target server:

migmatchup -s 192.168.1.3 -d 192.168.1.67 -k ‘ou=re-org,o=company’ > migmatchup.yaml

migmatchup searches for the trustees in their source context. If it doesn't find a matching trustee, it searches the container specified with the -k option recursively and matches the first trustee with the same name. If the trustee with the same name is not found, it is not matched.

If the trustee name is changed, then the output of migmatchup can be edited so that each source trustee is mapped to the corresponding user on the target tree.

(Conditional) When you are migrating to a NCP Linux volume, if you want to preserve file ownership in the target tree, you should LUM-enable the migrated users before continuing. For more information on LUM-enabling users, see LUM Implementation Suggestions in the OES 2 SP2: Planning and Implementation Guide.

Migrate the data from source volume SRCVOL to target NSS volume TGTVOL:

migfiles -s 192.168.1.3 -V SRCVOL -x /media/nss/TGTVOL/ -i --no-trustees

After the users have been migrated (this only needs to be done once), various data volumes can be migrated. Repeat this command to migrate other volumes on the source server.

Map the trustee rights on the source server:

maprights -V SRCVOL --matchup-file migmatchup.yaml -x /media/nss/TGTVOL/ mls.yaml > maprights.yaml

Migrate the trustee rights to the target server:

migrights -i maprights.yaml

Repeat Step 5 and Step 6 for each source volume being migrated.

[Музалёв Николай]

А инициализация с приёмника - это непреложно?

[Антон Фридрих]

А в нетваре есть утилита metamig? В линуксе я синхронизирую (бэкап восстановление) ей права квоты и т.д.

[capricious]

migutils работают через tsa

что-то мне уже разонравилось это решение

[Музалёв Николай]

Да, через TSA... А чем это плохо??

[solomin]

Хочу поднять тему:
Если я синхронизирую не все файлы с томов а только нужную чать, или еще по какм-либо причинам, как можно синхронизировать права?
Оба сервера Linux, права могу залить с помошью, напрмер, "metamig restore VOLUME -m t -n -f /DIRECTORY <trustee.metamig" (-n чтобы работать с не NSS томами), но возникает проблема при регулярной синхронизации, а именно metamig не удаляет существующие права на объекты.
Есть некрасивый вариант: перед восстановлением прав пробегать по всем объектам командой rights и потом ей же удалять текущие права. Есть более красивый способ?

P.S. Поправка: для не NSS томов просмотр/удаления прав только через конструкцию ncpcon rights show/del

[$erg]

Да действительно metamig не удаляет права
И плюс ко всему у утилиты rights нет нужных ключей для удаления всех прав на данный ресурс, только сразу show , затем "-r none trustee "кому"", очень не удобно.
Может у кого есть пример написание данного скрипта?

[solomin]

Ищет права от заданного каталога и удаляет. Минус один - не работает с каталогами кирилицей.... поэтому ввел ограничение maxdepth. По аналогии можно переписать для утилиты rights, у которой с кириллицей все впорядке - но мне она не подходит т.к. не работает с NCP шарами.

#!/bin/bash
vol_=VOL
dir_=HOME
nix_vol_=`/bin/cat /etc/opt/novell/ncpserv.conf|/usr/bin/grep "VOLUME ${vol_}"|/usr/bin/awk '{print $3}'`
#echo $nix_vol_
/usr/bin/find ${nix_vol_}/${dir_} -maxdepth 1 -type d|/usr/bin/awk -F"${nix_vol_}" '{print $2}'|while read dirs_;do
/sbin/ncpcon rights view ${vol_}:${dirs_} 2>/dev/null|/usr/bin/grep "\] ."|/usr/bin/awk -F"] ." '{print $2}'|while read users_;do
# echo "ncpcon rights rem ${vol_}:${dirs_} ${users_}"
/sbin/ncpcon rights rem ${vol_}:${dirs_} ${users_}
done
done

[solomin]

Господа, может я чего не понмаю а все молчат?
Судя по мануалу (http://www.novell.com/developer/ndk/xat ... r_nss.html), если включить опции (http://www.novell.com/communities/node/ ... -xattr-oes)
/ListXattrNWMetadata
/CtimeIsMetadataModTime
, то можно абсолютно не мучаться и обычным rsync'ом бэкапить права, irf, владельца и пр??

[solomin]

ЭВРИКА!!!!!!!!!!!!! ключик -X к rsync и наступило счастье:)

P.S. Неужто у нас никто не пользуется Linux решениемя OES2? Или все все платаят непонятно зачем огромные суммы за средства бэкапа?

[Dimerson]

огромные платить не хотим . берем ПО от SEP GMBH. работаем тоже через xattr

[$erg]

ЭВРИКА!!!!!!!!!!!!! ключик -X к rsync и наступило счастье:)

P.S. Неужто у нас никто не пользуется Linux решениемя OES2? Или все все платаят непонятно зачем огромные суммы за средства бэкапа?

Не-то что то я не понимаю, не-то что то не так работает
Права то копируются, если они назначены, а если не назначены - не копируются. Имеем следующую ситуацию:
Каталог к примеру HOME с правами группе public RF копируем rsync -X.... на другой том, копируется без вопросв с теми же правами RF той же группе public.
Имеем два каталога HOME на разных томах с одинаковыми правами.
Если мы изменим права, к каталогу источнику к примеру RWCEMF группе public, то такие же права, после rsync -X...., станут и на копии.
НО!
Если мы удалим права всем к каталогу-источнику HOME и снова запускаем rsync -X....., то права с копии не удаляются!
Т.е. получается что мы только избавляемся от metamig при синхронизации.

[solomin]

Попробую вопрос задать на форуме новела, может кто подскажет... есть еще идея попробовать более новую версию rsync...

[Dimerson]

ЭВРИКА!!!!!!!!!!!!! ключик -X к rsync и наступило счастье:)

P.S. Неужто у нас никто не пользуется Linux решениемя OES2? Или все все платаят непонятно зачем огромные суммы за средства бэкапа?

Не-то что то я не понимаю, не-то что то не так работает
Права то копируются, если они назначены, а если не назначены - не копируются. Имеем следующую ситуацию:
Каталог к примеру HOME с правами группе public RF копируем rsync -X.... на другой том, копируется без вопросв с теми же правами RF той же группе public.
Имеем два каталога HOME на разных томах с одинаковыми правами.
Если мы изменим права, к каталогу источнику к примеру RWCEMF группе public, то такие же права, после rsync -X...., станут и на копии.
НО!
Если мы удалим права всем к каталогу-источнику HOME и снова запускаем rsync -X....., то права с копии не удаляются!
Т.е. получается что мы только избавляемся от metamig при синхронизации.

то есть вы поверх заливаете ... А если зачищать перед заливкой поверх все в плоть до / , и потом rsync -x ?

сдается мне что если каталог есть оно добавляет аттрибуты.

[$erg]

перегонять большой объем данных с сервера на сервер не есть хорошая идея, ведь rsync позволяет копировать только измененные данные, что позволяет в десятки раз уменьшить объем копируемых данных.
Как вариант:
Выполнять синхронизацию каталогов(не трогая права), а файл с правами будет лежать и ждать, пока им воспользуются в случае ЧП, ведь права восстанавливаются довольно быстро.
Пример:
#копирум все права на том в файл, лежащий в корне тома
metamig save HOME -m a >/media/nss/HOME/metamig.home
# Копируем весь том на такой же том другого сервера(включая файл с правами на данный том)
rsync -a -v --delete --exclude-from=/backup/rsync.excludes /media/nss/HOME/ root@server:/media/nss/HOME/
#держим в уме команду для восстановления прав на резервном сервере, которая в случае чего восстановить все права довольно таки быстро
metamig restore HOME -m a </media/nss/HOME/metamig.home