[netatalk-ja:0256] Re: Mac OS X serverからのrsyncでのデータコピーで不具合

[Taiki Kimura]

湯浅さん


木村です。


>> そういえば、前任担当者がaclの設定方法で苦労したといっていました。

> acl関係あるとすれば、そもそもOSXで公開されてるときのユーザとかどういう設定ですか？
> アクセス設定とか細かくされてるのですか？それともただ全員読書出来れば良いとかそんな感じですかね？

> OSXのOpenDirecrtoryユーザの権限の設定されているのであれば、Netatalk側も連携しないといけません。
> （以前にコメントあればすみません。）


イメージでいうとこういう感じです。

・技術グループ
・営業グループ
・人事管理グループ
・経営者グループ

というようなグループとこのグループのメンバー全員が読み書きできるディレクトリがあり、
グループのメンバー管理をOSXのOpenDirecrtoryで行っています。

それぞれのディレクトリには、多のグループのメンバーからはログインすることもできません。

aclは、前任担当者が、色々と苦心し最終的に、各グループのディレクトリに対して次のように設定したところ、

 0: group:技術グループ inherited allow
list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Windowsクライアント、Macクライアント双方から読み書きできる環境になり、そのまま現在でも運用しているという状況です。


>> まだ、全てのファイルのコピーが終わっていないので、コピー完了後、じっくりと調査してみたいと思います。
> 一度全部コピーして、それをベースで作業できるならそれが一番良いと思います。
> それでnetatalk側でサーバのコマンドラインで、user_attrもそうですが、permissionなども確認されると
> 良いのかなあと。（できるんならコピー先の変なフォルダごとにacl削除して、chmod -R 777 とかしてみたら良いのかと思いますが）

> workaround的な話で言えば、コピー先のnetatalkの共有のアクセス設定を後から設定する前提で
> もとのOSXの共有フォルダが外付けだということですから、「ディスクの所有権を無視する」
> でマウントして、aclをコピーしないで、data_fork+resource_fork全てをnetatalkにキチンとコピーする
> ところからやるのもありかと思います。コピーしてから、各フォルダの所有権から設定して行く感じ
> ですかね。。（対応措置的に言って、差分は取ることは出来ないですが）
> ##finderでコピーされる場合は「ディスクの所有権を無視する」にしたりしないとログインしているユーザの
> 権限に左右されます。相手先のNetatalkボリュームもマウントしたユーザの所有権に左右されますし。と思います。
> 「ディスクの所有権を無視する」でマウントするのはもとに戻せますが、その際はサーバを公開してはいけません。
> またOSXで共有のバックアップを取ったりしたり、現在のOSX共有をリードオンリーにして運用したりすることも視野にいれたら良いかと思います。

>>> 前任担当者がaclの設定方法で苦労した
> とのことですので、、OSXの知識も重要かと（Netatalkだけの話ではないのかなと思います。。。）

なるほど。了解しました。
とりあえず、いまはコピー先netatalkの共有アクセス設定はchmod -R 777 hoge:hogeとしています。
コピーが終わったら、hogeグループのメンバー数人にテストWindows・Macから、
ファイル読み書き、削除など、色々とオペレーションしてもらい、
問題が発生したらその都度対応するということを考えています。

で、その問題がある程度解消した時点で、現行環境から切り替えるつもりでおります。

OSXに関する知識も平行して吸収していくようにします。


アドバイスありがとうございました。



>
> On 2013/07/28, at 9:35, Taiki Kimura <taikimura8182 ＠ gmail.com> wrote:
>
>> 湯浅さん
>>
>>
>>
>>
>>
>> 2013年7月27日 1:03 Kyo <sixty7kyo_19 ＠ rock.odn.ne.jp>:
>>> HATさん
>>> こんばんわ
>>>
>>>> もしaclがAppleDoubleファイルに保存されているのであれば、apple_dumpコマンドで
>>>> 見える筈です。
>>>> たぶんそういうことはしてないです。
>>> 確かによく考えたら変ですね。もしかしたら元々smb側から作ったファイルで
>>> そもそもrsyncでaclオプションをつけてなくて、変なパーミションになった形だったと
>>> 思い出してきました。
>>> ---rwxrwxみたいになっちゃうんですよ。
>>>
>>> 木村さんもExcel、Wordってことですが、元々windowsクライアントで作ったファイルとかって
>>> ないですか？本件から外れますが10.5のaclってWindowsで共有すると、Excel、Word系がすぐ書き込めなく
>>> なって難儀しました。aclの設定方法にコツがあるようです。。。
>>
>> はい。ご推察の通りです。
>> Excel、Wordは、Windowsクライアントで作ったファイルも含まれています。
>> そういえば、前任担当者がaclの設定方法で苦労したといっていました。
>>
>> まだ、全てのファイルのコピーが終わっていないので、コピー完了後、じっくりと調査してみたいと思います。
>>
>>
>>
>>>
>>> On 2013/07/25, at 0:04, HAT <hat ＠ fa2.so-net.ne.jp> wrote:
>>>
>>>> HATです。
>>>>
>>>>>> Mac OS X server（10.5.8）で運用しているファイルサーバをLinuxOSへリプレ
>>>>>> イスしようとしています
>>>>> OSXServer10.4からNetatalk2系に共有を引越しするのは何度かやりました。
>>>>> OSX側からNetatalk2をマウントしてコマンドラインでrsync -aEv で大概うまく
>>>>> できたと思います。
>>>>> 差分を取るのはうまくいかなかったと思います。
>>>>
>>>> そうですか。手元のOS X 10.8 + Netatalk 3.0.4では特に問題なく、
>>>> 差分も取れてますね。
>>>> 10.5.8あたりだと、rsyncの実装が甘いかもしれないですね。
>>>>
>>>>> 当てずっぽうですが、
>>>>> 10.5ってことなので、OSX側のaclがうまくコピーされてなくはないですか？
>>>>> 自分がやった時は10.4なので、aclを使ってない頃だったと記憶しています。
>>>>>
>>>>> ##以下参考ですが。。
>>>>>
>>>>> Netatalk2の共有を日次rsyncする先が、Netatalk2からNetatalk3になってしまい
>>>>> ました。
>>>>> 2から3の変換は3がやってくれますが、日次でバックアップするので、毎回
>>>>> .AppleDoubleがコピーされてしまう。。。
>>>>> （サーバー同士でrsync-daemonでバックアップします。）
>>>>> そう思って、rsyncした先はNetatalk3の設定をreadonlyにして、noadoubleとし
>>>>> ました。
>>>>> それでrsync -exclude ".AppleDouble"としてバックアップして、コピー先の
>>>>> Netatalk3の共有を見たところ
>>>>> 木村さんの書かれているような事象が確認できました。
>>>>> サーバでls等して比べたところ、コピー先のファイルのパーミッションがおかし
>>>>> くなっていたようです。
>>>>> それ以上のことはよくわかりませんが、とにかくOSXのacl等の情報がNetatalk2
>>>>> では.AppleDoubleにも記録されていて
>>>>> それとともに、コピーしないとパーミッションが不正になってしまうのかな？と
>>>>> 邪推しました。
>>>>
>>>> もしaclがAppleDoubleファイルに保存されているのであれば、apple_dumpコマンドで
>>>> 見える筈です。
>>>> たぶんそういうことはしてないです。
>>>>
>>>>> #OSX ServerからCentOSへrsync-daemonでバックアップするのは良くやっています。
>>>>> その際は、どなたかが書かれたようにiconv option（UTF8MAC,UTF8）が必要です。
>>>>> リソースフォークはバックアップ出来ませんし、aclも怪しいですが、もともと
>>>>> のパーミッションが変には
>>>>> ならないようです。WEB公開フォルダとか、メールスプールとかをバックアップ
>>>>> してます。
>>>>
>>>> こういうメタデータが必要ないケースなら簡単なんですがねぇ。
>>>>
>>>> --
>>>> HAT
>>>
>