2018年 12月 19日
クライアントPCのBCP対策 D:ドライブにドキュメントを保管・バックアップ
ここでは、普通 C:\users\myname の下に作られるドキュメント等のフォルダをD:ドライブに作成し、バックアップを容易にする方法を説明します。
私がノートパソコンを買った場合、初期状態で必ず、D:ドライブを分けて、データとシステムドライブと分けています。いつもこの方法で個人的に運用しています。C: ドライブに分散して存在するファイルは、システムファイルと混在してバックアップは面倒です。PCを初期化したりHDDが故障したりで、システムの再インストールが必要な事故だと、目が当てられません。悲劇を避けるために、C:ドライブにファイルを保存せず、常にD：ドライブに無意識にデータを保管して、データドライブだけ簡単にバックアップできるよう、コンピュータをセットアップすることが重要です。
- 使い込んだPCの準備--できるだけC:をコンパクトに -
購入したての場合は問題ないのですが、購入して使い込んだPCの場合は、C:ドライブにかなり余分なデータが溜まっています。そのため、C:ドライブを減らして、データ用 D:ドライブが十分に確保できないことがあります。
まず、やる事は
- C:users\myname\ の下にある重要なデータやC:ドライブのファイルは外付けHDDや、NASに"移動"して、できるだけC:ドライブを開けてしまいます。
- 明らかに不要なファイルは削除します。
- 必要であれば、再インストールが容易なアプリケーションはアンインストールします。ストアアプリのゲーム、めったに使わないツールとかですね。何らかのアカウントと同期するSNSアプリなどは残しておいたほうがいいでしょう。
- 次に C: ドライブのディスクをクリーンアップします。エクスプローラーから C: ドライブをポイントして、右ボタン > プロパティで、「全般」タブにある「ディスクのクリーンアップ」をウィザードに従って実行し、不要なデータをC:ドライブからパージします。
- C:ドライブをデフラグします。C:ドライブのプロパティから「ツール」タブを開いて「最適化」をウィザードに従って行います。C:ドライブの空き領域を、後半のセクタにマージしてしまうのですね。
この処理には時間がかかります。
- パーティションを分ける -
エクスプローラーの自分のコンピュータ名をポイントして、右クリックから「管理」を選びます。
コンピュータの管理から「記憶域」＞「ディスクの管理」を開きます。
- ここまでが、現在使用中のコンピュータのディスクの整理、準備作業です。コンピューターが初期状態、あるいはまだ使い始めの場合は不要かもしれません。
- D:ドライブの作成 -
ここで「ディスク０」のC:ドライブをポイントして、右ボタンから「ボリュームの縮小」を選びます。
この時点で縮小できるサイズの初期値は「縮小できる領域の最大サイズ」です。このサイズを調整します。
全部縮小してしまうとC:ドライブの空きが全くなくなるため、「縮小後の合計サイズ」が８０Gバイトから１２０Gバイト程度に調整するのが理想でしょう。多くのオフィス系のソフトウェアや Windows Update に必要な領域は最低でも６０～１００G程度あれば十分です。アプリケーションが全てインストールされていても、２０Gb程度は空きが確保できればOKです。
私はいつも新規購入したPCのC:ドライブは１００Gbに調整していますが、問題になったことはありません。６０Gbでは Windows10 のメジャーアップデートに不足した場合がありました。８０Gbから 120Gb 程度に調整できれば適量でしょう。
図では別な所にできていますが、通常１ドライブシステムの場合、C:を縮小した後は C:の後ろに「未割り当て」の領域が現れます。この部分をD:ドライブに割り当てます。
「未割り当て」の領域をポイントして右ボタンから「新しいシンプルボリューム」を作成します。
ウィザードに従って作業します。
新しく作った「ボリューム」に任意の名前を割り当てます。
完了を押して、作業を終わります。
- ドキュメントフォルダをD:ドライブに変更する -
「ドキュメント」をポイントして右ボタン、プロパティの「場所」タブを開きます。通常、"C:\Users\MyName\Documents" になっているので、"C:"の部分を "D:" に書き換え、「適用」します。
確認ダイアログに「はい」
"C:Users\MyName\Documents" の内容が、"D:Users\MyName\Documents" に"コピー"されます。移動ではない事に注意してください。
- この作業を”ピクチャ”、”ビデオ”など、全てに繰り返します。
これで、アプリケーションから「名前を付けて保存」する場合、”ドキュメント” フォルダなどに保存するファイルはD:への保存になります。
エクスプローラから "D:\Users\myname\Document" にファイルを作ると、"コンピュータ名\ドキュメント"にも同じファイルが作成されればＯＫです。
- アプリケーションのデータ保管先の変更 -
アプリケーションによっては、決め打ちで "C:\users\MyName\Documents" にデータを保存するものがあります。大抵はアプリケーションの"環境設定オプション"などで任意のディレクトリを指定できるので、"D:\users\MyName\Documents" に変更しなければならないものがあります。
はがき印刷ソフトや、会計と言った、素人さん向けのソフトウェアにはそういう設計の物が多いようです。重要なデータですから、必ず使うアプリケーションのデフォルト保存先を確認してください。
- Outlook の場合
Outlook の場合、マイクロソフトの次の文書が役に立ちます。
Exchange Server 環境で使用している Outlook 2010 のデータを保存、復元、または移動する方法オフィスデータをＤドライブに移す方法を教えてくださいOutlook で個人用フォルダー (.pst) ファイルを参照、移動、またはバックアップする方法
- Thunderbird の場合
Thunderbird は
C:\Users\<username>\AppData\Roaming\Thunderbird\Profiles\xxxxxxxx.default\
にデフォルトのメールストアが作成されます。 これをD:にコピーして、コマンドプロンプトから Thunderbird.exe -p を実行するとプロファイル作成モードになるので、コピー先のプロファイルを指定してプロファイルの作成をします。次のドキュメントが参考になるでしょう。
Thunderbird のプロファイルThunderbird のデータを新しいコンピューターに移動する複数のプロファイルを使用する
- Evernote の場合
Evernote は通常 C:\Users\MyName\AppData\Local\Evernote\Evernote\Databases に巨大なデータベースがあるので、一旦 Evernote を終了して、これを削除して、起動して同期が始まる前に、ツール ＞ オプション > 「全般」、から「ローカルプロファイル」の保存先を D:ドライブの任意の保存先に変更して同期するとクラウドに保存されたデータベースがD:ドライブに新規作成されます。これでC:ドライブがデータベースでパンパンになることを防げます。
Evernote for Windows でデータをバックアップおよび復元する方法
※ DBの再構築の時にログインが求められます。誤りがないように事前に Evernote のIDとパスワードを WEB 版で確認しておきましょう。
※ ちなみに Evernote の動作が重い場合はデータベースを削除して再作成するのが一番効果がある様です。DBのサイズも小さくなります。
※ ちなみにストア系アプリでクラウド同期しない物は、ほとんどが C: に保管するようです。これは変更できるものは少ないようです。全くダメな仕様ですね。
- バックアップの実施 -
バックアップ用のバッチファイルを作成します。次のサンプルは Windows の robocopy ツールを使ったファイルサーバーへのバックアップ用のバッチファイルです。バッチファイルは、バックアップ先のメディア（ファイルサーバーや外付けHDD）に用意するのが良いでしょう。バックアップメディアが使えるときにこのバッチファイルを実行すれば、バックアップが開始されます。
net use n: /delete /yesnet use n: \\<MYNAS.local.mydom_or_MyNAS_IP_Address>\<share_for_backup>pauserobocopy /S /E /R:1 /W:1 /LOG:n:\backup.log D:\<SrcPath>\*.* n:\<backup_DST>\net use n: /delete /yespause
※ robocopy には /MIR オプション（ミラー同期で削除もあり）は付けません。誤って「消してしまった」ファイルのバックアップのためです。
コピー先パスは、NAS でも構いませんし、USBの外付けHDDでも構いません。上の例では Samba ファイルサーバーを n: ドライブに指定しています。途中でログインを確認するための pause が入っています。"/user:MyName PassWord" オプションを付ければ、接続も自動化されますが、ファイルサーバーのパスワードがまんま書かれているため、セキュリティの問題があります。タスクとして自動化したい場合は注意が必要です。
バックアップ先を複数のディスク、ディレクトリとするバッチファイルを作ることで、サーバー側のディスクトラブルを回避することもできます。
また JBOD 対応の USB 接続の HDD 多連装外付けケース（センチュリー製、裸族のマンションシリーズみたいなの）を使って、「物理＝別々の論理ディスク D:E:F:G:H:」を作り、月金のバックアップを、別玉にスケジューラでファイルサーバーをバックアップしたケースもあります。
テープバックアップより単純な考え方なのでリストアは楽ですね。ディスクを取り外して交換・フォーマットして差し替えすると、永久保存用アーカイブになります。
Robocopy は差分だけコピーしますので、バックアップの頻度、サイズ、作成/変更したファイル数にもよりますが数分から、数十分でバックアップコピーが完了します。 /LOG オプションでログを取っているのでログを確認して「失敗」をキーワード検索して、下の様に正しくバックアップできたかを確認できます。
合計 コピー済み スキップ 不一致 失敗 Extrasディレクトリ: 2860 0 2860 0 0 0ファイル: 33242 155 33087 0 0 3バイト: 69.629 g 1.011 g 68.617 g 0 0 71.4 k時刻: 0:01:02 0:00:25 0:00:00 0:00:37
- バックアップのコンセプト -
私は、バックアップは誤消去したファイルを保護するためでもあるので、Robocopy を使って、ミラー同期はしません。ただ、この方式であればどんどん削除されたファイルも含めてバックアップがファイルサーバーの中で膨らんでしまいます。その場合は、バックアップ先のファイルで不要なファイルを、別な手段でアーカイブするか、整理して削除しています。
サーバー内部では、データを Linux の rsync で別メディア、別サーバーにコピーしています。
どうせ、古いファイルはいらないから不要なのであり、断捨離ついでにファイルも整理してしまいます。
新しいPCを購入した場合、必要なファイルだけをバックアップから、新しいモバイルノートPCにの容量の少ないストレージにコピーして使うようにして、できるだけ、バックアッ:プの負荷を減らすことにしています。
- Keyword -
クライアントPCのバックアップ、BCP、C:ドライブの分割、D:に保存、データだけバックアップ
▲
by islandcenter
| 2018-12-19 17:58
| プライベートクラウド
|
Comments(0)
2018年 11月 03日
SUSE Linux: YOU(YaST Online Update) によるパッケージアップデート
SUSE Linux (openSUSE/SUSE Linux Enterprise) で、パッチなどのパッケージアップデートを行うには二つの方法があります。一つは zypper コマンドによる
# zypper update
で一挙にアップデートパッチを適用する方法です。
コマンドラインツールによるソフトウェアの管理
初回のアップデートを行うには単純で便利な方法ですが、必要か必要でないかのパッチを全てアップデートされてしまいます。細かなアップデートをコマンドラインで全部覚えるのは、ただでさえ少ない私たち（私だけ？）の脳味噌メモリをパンクさせてしまいます。
- YOU によるアップデート -
もう一つの手段が YOU (YaST Online Update) を使ったパッチの適用です。
YaSTオンラインアップデート
YOU (YaST Online Update) によるオンラインアップデートは GUI(yast2) またはメニュー形式(yastコマンド)の操作なので、zypper コマンドラインのオプションや、パッケージ名をウル覚えで、よく知らなくても容易にアップデートを行うことができます。デスクトップから yast アイコンを起動するか、X ターミナルから
# yast2 & （GUI版の場合）
か
# yast (メニュー形式の CUI 版の場合)
を起動して、 Software > Online Update を選択することで YOU を起動し、必要なパッチをチェックして適用します。
openSUSE の場合 "Configuration" メニューを開くと、YaST のメニュー画面から "Online Update Configuration" のメニューアイコンが追加されるので、ここから、定期的な Online Update を自動的に行うことができます。
テキスト版 yast の YOU 画面
ダウンロード中
--個人的には、zypper を使ったアップデートは初回だけ。次回以降は YOU を使って自動的にパッチを受け取るか、手動でフィルタを使ってパッチを選択するのが手軽で良いと考えています。
YaST (yast2) による SUSE Linux のパッケージ管理, インストールと削除SUSE Linux 15 YaSTの基本
How to install samba on SUSE Linux Enterprise 15 (SLES15) インストール
--SUSE Linux, openSUSE, SUSE Linux Enterprise, zypper, yum, apt, update,SUSE Linux, SUSE Linux Enterprise Server, SUSE Linux Enterprise Desktop, パッケージのインストール、パッケージのアップデート、パッケージの削除、パッケージの依存性, apt, yum, zypper, rpm コマンド,opensuse update コマンド,opensuse パッケージ管理, suse linux update, suse アップデート, suse package update, suse linux コマンド, suse yum update, opensuse update command
▲
by islandcenter
| 2018-11-03 11:23
| SUSE
|
Comments(0)
2018年 10月 17日
計画停電時の対策 SUSE (SLES11, SLES12,15) XEN/KVM 遮断マニュアル
商業ビルなど６００Ｖ以上の電源契約の事業者は電気事業法により電源設備の検査が義務付けられており、オフィスビルでは年に１度は計画停電があります。もちろん、先日の胆振東部地震による、大規模ブランクアウトというような致命的な停電も実際あるのです。
UPSも付いているし、UPSが正しく機能すれば、通常は正しくシャットダウンします。そして商用電源が復活すれば、正常に起動することを期待したいものです。
期待すべき事は、設計通りにシステムの自動遮断、復電、サービスの再開が行われることです。
期待通りであればです。
しかしUPS の不具合や、電源投入のタイミングによっては自動起動できないシステムがあったり、思わぬトラブルがサーバーシステム以外にも存在します（実際、復電後、UPS が付いていない HUB が飛んで１フロア全滅というケースがありました）。計画停電の際、都合が良ければシステム管理者は現場に休日出勤でアテンドして経験を積み、不慮の停電の際の運用マニュアルを作っておきたいものです。
また、計画停電の現場にアテンドして UPS に任せて、実際の遮断/復電の際に、どの様な動きや不具合があるかを確認するチャンスです。そこで現実に問題となった場合のインシデントをまとめて、現実に起こりえるアン・アテンド状態でのサーバールームやITシステム全体の弱点を確認、対策を立てる良い機会になります。
ここでは、SUSE Linux 11,12,15 の XEN/KVM 環境での計画停電前の安全な手動でのシステム遮断、システム復帰のケースを考え、オペレーション手段をマニュアル化して、考えられる復電/復電後のトラブルやチェックポイントを確認します。
- X サーバーソフトウェア -
ベアメタルシステムのコンソールを使わないで、Windows 端末から movaXterm もしくは xlaunch X サーバーを使って、各ハイパーバイザーごとに仮想マシンマネージャを起動します。ベアメタルサーバーのコンソールは、ハイパーバイザーの遮断、起動の状態を確認するだけで、できるだけ使わない様にします。
ここでは mobaxterm Home Edition を使って説明しています。
-仮想マシンの安全な遮断-
全て CPU 装置と UPS の停電遮断機能が動作するかチェックして、「放っておいて動作をチェックする」のも一手段ですが、アテンドして停電前に、各システムを安全に遮断します。
Windows からの場合、上のMovaXterm の Session ボタンから、各ホストの IP アドレスを指定して root で接続します。
仮想マネージャ GUI を起動します。
# virt-manager &
もしくは
# yast2 &
> Virtilization > Virtitual Machine Manager
local host Not Connected の行を右ボタンで "Connect"
Connect できたら、稼働中のVMを選んで、右ボタンから "Shut Down" > Shut Down" を選び、確認のダイアログに対して OK ボタンを押します。
この処理を各 VM 毎に行い、ハイパーバイザー上の仮想システムを遮断します。
それ以外の VM は、上で動作しているサービスにもよりますが、およそ数十秒～数分（２～３分）以内に遮断します。遮断中の状態は "Open" メニューを開いて仮想コンソールで確認してください。
各VMが正常に停止状態になる事を virt-manager か xm list, virsh list コマンドで確認します。
- 停止しない場合 -
※ Windows7系、Windows2008 系システムは仮想環境で正常に停止（電源OFF状態）にならない場合があります。その際は virt-manager > アクティブなVMを選び右ボタンから > "Open" で仮想VMのコンソールを開きます。 Windows が "シャットダウン中"の最後の状態で 30 秒以上経っても、電源 OFF 状態にならない場合は、仮想 OS が物理的な電源オフを待っている状態なので "Force Off" (destroy) を実行しても構いません。「これ幸い」とばかりに、 Windows Update が走っている場合があるので、要注意です。
Unix/Linux 系システムはサービスの内容によりますが数十秒から数分以内に正常に遮断します。何か異常があって、あるいはサービスによっては１０分以上かかる場合もあります。やりたくないのですが Pause するか Force Off するしかありません（復電後が怖いですけど...）。焦らない事です。
※ Reset, Force Reset の二つの操作は行わないでください。再起動してしまいます。万が一、再起動を選んでしまった場合、正常に起動するまで待って、シャットダウンの操作をもう一度行ってください。
- コマンドラインでの操作 -
アテンドして、手動で操作する場合、覚えておくべきテキストコマンドラインです。リモートのテキストコンソールしか使えないケースや GUI が使えない環境ではこれらのコマンドラインツールを使います。
SUSE Linux (SLES) 11 の XEN 環境の場合
xm shutdown myvm .... myvm を正常シャットダウンします。
xm destroy myvm .... myvm を強制シャットダウン（電源OFFと同じ）します。
xm reboot myvm .... myvm を正常シャットダウンしてリブート（再起動）します。
xm create -f /etc/xen/vm/myvm .... myvm を指定された VM ファイルから起動します。
xm list .... リストされている vm の状態（動作中か、稼働中か）を表示します。
xm console myvm_or_vmID .... myvmmyvm(もしくは ID No.) のテキストコンソールに切り替えます。Windows では使えません。"Ctrl+]" キーでエスケープします。
SUSE Linux (SLES12, SLES15) の XEN/KVM 環境の場合
virsh shutdown myvm .... myvm を正常シャットダウンします。
virsh destroy myvm .... myvm を強制シャットダウン（電源OFFと同じ）します。
virsh reboot myvm .... myvm を正常シャットダウンしてリブート（再起動）します。
virsh create -f /etc/libvirt/qemmu/myvm.xml .... myvm を指定された VM.xml ファイルから起動します。
virsh list .... リストされている vm の状態（動作中か、稼働中か）を表示します。
virsh console myvm_or_vmID .... myvm(もしくは ID No.) のテキストコンソールに切り替えます。Windows では使えません。"Ctrl+]" キーでエスケープします。
virsh cosole コマンドが使えない場合は次の対策が必要です（VM の再起動が必要です）
KVM on SUSE Linux(SLES12) virsh console が起動/接続できないAccessing the VM Guest via Console
- 自動起動の設定(共通) -
VM の自動起動は virt-manager の "Details" > "Boot options" にある "Autostart" をチェックしておきます（KVM/XEN共通）。
SLES11 の XEN 環境では /etc/xen/auto に /etc/xen/vm/MyVm のシンボリックリンクが作成されます。
SLES12,15 KVM 環境では /etc/libvirt/qemu/autostart に MyVm.xmlのシンボリックリンクが作られます。
- ハイパーバイザーの停止 -
ベアメタルハイパーバイザー SLES OS を停止( halt )します。
- 共通事項 -
- バックアップソフトウェア -
もちろん計画停電前には、重要なデータのバックアップを取ります。
バックアップが終わったらバックアップソフトウェアを停止させます。バックアップジョブが完了しているかを確認してください。バックアップジョブが走っている状態で、停電になると、どのような結果となるか想像がつきません。特に壊れやすいオートローダーには要注意です。計画停電がある場合、その時間帯に想定されるジョブは、サスペンド状態にしておくべきです。
Dell Software の NetVault の場合
# /etc/init.d/netvault stop
を実行します。
- ベアメタルハイパーバイザーの停止 -
# shutdown -h 0
でシャットダウンを開始します。正常に遮断しているかどうかの状態の確認は、リモートコンソールではなく、実コンソールで確認します。
正常に halt を実行した場合は、system halted ... の後、主電源が切れます。system halted .... の後、電源が切れない場合はメインスイッチで電源を落としてください。
また、
誤って halt ではなく Reboot を行った場合、 再起動してすぐの BIOS チェックのステージで電源を切ります。放置してしまい OS の起動ステージまで行った場合は、システムが完全に起動してから、再びVMの遮断から halt までの手続きを行ってください。時間がかかりますので要注意です。
- 考慮すべき事 -
- 一度に電源を入れない -
アンアテンドで復電してしまった場合、電源が一斉に入るため、UPS やフロアの電源ラインに一斉に負荷がかかります。できるだけ、コピーや複合機、エアコンと言った、電源容量の大きな装置は、アテンドできるなら事前に主電源を切っておくかコンセントを抜いておくべきでしょう。
ちょうど自宅でブレーカーが落ちた時、エアコンや電子レンジといった機器のコンセントを抜いてから、ブレーカーを上げるようなものです。
また、各ベアメタルサーバーのBIOSメニューの中に、復電後の電源 ON のディレイ（遅延）パラメータを設定できるものがあります。「松竹梅」の「竹クラス」以上のサーバーハードウェアにはこのディレィを設定できたり、復電後に自動的にランダムに遅延起動する機能があります。また、周辺機器（例えばテープのオートローダーやiSCSI SAN ストレージなど）にも起動に時間がかかるものがあるため、電源 ON のディレイタイマーが利用できるなら設定しておくべきです。ラック内のシステムにランダムに起動がかかるようにすれば、UPS や電源ラインに余計な負荷をかけずに復電作業ができます。
- 復電後の自動起動は正しく動作するか -
BIOS の設定状態によっては、停電後、電源ボタンを操作しないと復電できない設定のものがあります。アンアテンドで、停電してしまうと、これらの装置は実際に出向いてスイッチを押さなければなりません。「松竹梅」の「梅クラス」のハードウェアには良くある話です。インフラ経験の少ないソフトウェア専門の SIベンダーのサポートを受けているお客様で、その問題に悩んでいる方がいらっしゃいました。
また、私がテストで使っているような「梅以下」の安物ハードウェアでは、モニタの電源が入っいない、マウス、キーボードが付いていない、などで BIOSチェックで停止してしまうものがあります。
また SUSE の様に手堅いシステムでは、長時間安定運用しているため、fsck が行われていません。大抵の場合、fsck してデータのチェックのシーケンスに入ります。ここも焦らずじっくり付き合う必要があります。
- プリンタ、複合機 -
復電後、プリンタ、複合機と言った電力を食う周辺機器の主電源を投入します。この作業は分担として、利用者部門に任せても構わないかも知れません。計画停電と言っても、実際電源工事やビル点検の際に、作業が完全に終わらなくても復電してしまい、また急遽、主電源が切られる場合もあります。こうした起動後のチェックに時間がかかり物理的な動作をする機器は、物理動作をする部品が急に電源が切られて故障する場合もあります。
プリンタや複合機、Wifi のアクセスポイントなどで snmp 監視ができる機能が搭載されていれば、有効にすべきです。zabbix などの監視ツールのコンソールから snmpwalk を実行して、返事が返ってくればシステム管理者の側では問題なしと判断できます。物理的に故障していない事を祈ります。
snmpwalk でデバイスの snmp 状態を確認する
--
他にも、エレベータが使えないとか、電源が切られて、セキュリティ装置が動かず、サーバールームにカードで入れない。内線もつかえなければトイレすら使えない（！）と言った、システム以外に想定、憂慮すべきモンダイと言うものが、全館計画停電というイベントには含まれます。
停電、復電というプロセスは意外と想定外の現象が出てくるものです。実際にビル全館停電がある場合は、実際にアテンドして、停電を体験してみることも重要なのです。BCPプランの策定に役立つでしょう。
また、ビルメンテナンスの業者の担当者や関係者の間で携帯電話の番号を交換しあうことも重要です。トイレに閉じ込められて出られない、なんて笑って済む問題から、行きたいのにトイレに入れないと言ったもっと生理的にもっと深刻な問題まで、店子と業者との間で十分コミュニケーションをとる事も大事なのです。
--
SUSE, SLES, KVM, XEN, 仮想化, ハイパーバイザー, 計画停電, BCP, マニュアル
▲
by islandcenter
| 2018-10-17 09:47
| SUSE
|
Comments(0)
2018年 10月 08日
ユーザアカウント名は８文字以内にすべきか？ユーザの命名規則の理由と対策
私はほとんど無意識にですが、
「ユーザＩＤは８文字以内の英数字にすべし」
というのが暗黙の考え方としてありました。
--
実際、海外の数万人規模の巨大企業でも、単一のディレクトリサービスでその様な ユーザアカウントの Naming Standard (命名規則) で運用している所をよく見ました。近年は、ユーザＩＤもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでＩＤ管理に複雑な機能が要求されます。
- UNIX系 OS の場合 -
UNIX 系 OS のネーミングスタンダードでは、POSIX 準拠した場合、ユーザ ID は 9 バイトで、お尻の１バイトは NULL 文字で、実質８バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。
limits.h
{_POSIX_LOGIN_NAME_MAX}The size of the storage required for a login name, in bytes (including the terminating null).Value: 9
一応の決まりですが実際には、今のディストリビューションやメーカー独自の UNIX 系システムは、独自拡張されており、現在、販売もしくは配布されている多くの Linux ディストリビューションや Unix 系 OS では多くの場合 32 バイトです。ただし、 UID とユーザ名を関連付けるライブラリにバグがあったりすると、表示上 ８文字以上のユーザ名が UID に化けてしまうと言った問題もでてきます。
アカウントと連動するアプリケーション側が、古い標準に従って８文字に制限している場合もあるので
「システム的には管理運用上ユーザアカウント名は８文字以内」が無難
であると考えます。
ps doesn't display usernames > 8 characters
ちなみに MySQL は 16 バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。
6.3.1 ユーザー名とパスワード
- Windows の場合 -
Windows (2000/XP) のユーザアカウント文字数の最大長は２０文字でした。
ユーザーアカウントとログオンパスワードの最大文字数について（Windows(R)2000/XP）
Windows10 に関しては情報がみつかりませんでしたが、Windows7 も２０文字なので、恐らく最大２０文字の制限は引きずっているでしょう。AD の場合も２０バイトの様です。
Windows 10でユーザーアカウント名に使用できる文字の制限について
Object namesCommon-Name attribute
それにしても CON とか LPT とかの文字列が使えないってのもなんだか笑わせられます。こんな制限は、DOS 時代を知らない、若い方々には訳が分からないでしょう。俗にいう「CONCONバグ」 の残骸です。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。
特殊文字はハイフンやアンダースコアは OK の様です。文字間にドットが入っても問題ない様です。カンマは不可。
ちなみに、マイクロソフトアカウントでユーザ作成した際の文字数が５文字を超えると、\Users\xxxxx のユーザフォルダ名は５文字にトランケート（丸めて短くされる）されます。そのため、５文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが５文字を超えると「色々と楽しくて痛ましい事故？」が起こるようです。例えば
robocopy c:\users\%login_name\*.* \\nas\backup
などとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。困ったものです。
User folder name truncated
[Windows 10] ユーザー フォルダーの名前が Microsoft アカウントのアドレスの最初の 5 文字になっているのですが、なぜなのか分かりません。
- メールアドレス -
メールアドレスは、ドメイン名も含めた最大長 256 文字、＠以前の、いわゆるローカルアカウント部分は最大６４文字です。これに＠以下のドメインを含めて最大 256 文字という事です。
ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー（クライアント側）の制限により、その限りではありません。もっと制限がかかっている場合があります。
https://ja.wikipedia.org/wiki/メールアドレス
一般的なマルチユーザのシステム単体(Unix だの VAX だの)では、ローカルホスト内でメールが使えればよかったので「ログイン名＝メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。
- NetIQ eDirectory/LDAP の場合 -
ちなみに NetIQ eDirectory の CN (Common Name : UserID) は64 バイトまで許容しています。と言うより AD や Notes の認証のために LDAP 自体が x.500 の標準として 64 バイトに制限されているようで、eDirectory そのもの自体に制限は無いようです。
attribute length restrictions
しかし、NetIQ のドキュメントではスタンダードな命名規則の事例として、８バイトの英数小文字と ”-” ( ハイフン ) を推奨しています。万物共用の命名規則として通用するわけです。
そこで eDirectory や LDAP でユーザアカウントを管理して、長いオブジェクト名や特殊文字を使用すると、マルチベンダーシステムで Windows や Linux のログインや動作で問題が起こります。LDAP との互換性のため、特殊文字にドットは使えません。ドットは、 eDirectory のコンテナ区切り文字です。特殊文字はハイフンだけ許可されます。LDAP サーチする場合は ＣＮ にカンマや＠が入っているとURLと間違えられ問題があるからでしょう。
Sample Standards Document#
Tip: Valid Characters in eDirectory
GroupWise はデフォルトで eDirectory の CN (common name) がメールアドレスのローカル部分になります。
- という事で -
また、Unix 系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。Windows 系システムではケースセンシティブではありません。
レガシーなホストコンピュータなどのプリケーションの一部では、やっぱり８バイトが最長ユーザアカウントというケースもあり、
どうも「ユーザアカウント長、文字制限は８文字以内の英数小文字とハイフン」
というのが ID 管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード（命名規則）構築方法でしょう。
セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。
- 文字数を８文字以内にする法則 -
- アカウントの長さは６～７文字の英数字 -
後に述べる「同姓同名問題」を解決させるため、８文字目は丸めて最大７文字とします。８文字使う場合は特例とします。もちろん、ユーザ名が"津・浦子"さんの場合 "tsuu" と短くなるのは構わないとは思いますが、必要に応じて文字を追加して６文字以上(tsuurrk)にする、と言った方法も良いと思います。８文字以上のＩＤを要求する場合、長ければトランケートして８文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。
もちろん２バイト文字や特殊記号の利用は厳禁、特別に許されても”－”ハイフン位にしておきます。ただ ”-” 文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。
- ファミリーネーム＋ファーストネームイニシャル -
大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを１文字加えて「同姓異名」を区別します。
よく、イニシャル＋ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。
- 同姓異名、同姓同名の区別 -
同姓同名、同姓異名で、ファーストネーム＋イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。
Nakajima Kenji : nakajik
Nakajima Kensaku : nakajkn
Nakajima Kenichi : nakajkc
Nakajima Kenji(2): nakaknj
という感じです。
- 回避できない場合は８文字目を数値にする -
Nakakjik と nakajik2 ですね。これで例外があっても８文字に収まります。
- 表記はヘボン式 -
普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式（日本式）ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。
ヘボン式ローマ字東京都生活文化局 - ヘボン式ローマ字綴方表
また、外国人の場合、帰化しない限り日本の戸籍名がないので、原則として「通称」を使うことになります。その際も母語のスペルを使うのが原則でしょう。 Bob Smith さんの場合 "SmithB" であり "SuMiSuB" になってはいけないわけです。母語がアルファベットで表記できない場合もあるので、その例外措置も考慮すべきです。
まぁ、例外規則に命名規則＋「本人の希望」というものがあってもいいわけです。
- 使ってはいけない文字（列）がある -
一般的にOSでファイル名として利用できない特殊記号や文字列、システム間で互換性のない文字（列）などは、or 条件の最大公倍数で禁忌とすべきです。
Unix 系OSでは "0","/" などが禁忌文字ですし、mac の場合は "/" だけ。":"や "|" とか "<>" もパイプに相当するためやめた方がいい。おそらく "Null" などの特殊なデバイスを意味するユーザIDもやめるべきでしょう。 Windows 系OSでは前述したように、特殊文字と "CON" とか "LPT1" とかのファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。モノによっては "-" も文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。
また、当たり前ですが機種依存文字（○付数字やカッコつきの「株」「〒」）とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「５C文字」を含む。
つまりはすべての漢字を含め２バイトの文字は使うべきではありません。
正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。
「英数小文字６～８バイト以内」とするのが && 条件で絞り込んだ最小公約数として命名規則に加えるべきです。
- 改姓をどうするか -
主に姓が変わるのは、お年頃の女性が多いと思いますが、男性でも次男坊、三男坊が一人娘を娶った場合なんかは、戸籍上「婿入り」するわけで、そのような場合はどうするのかという事も決めておかなければなりません。ユーザID＝戸籍名なのか、ユーザID＝通称名とするかですね。
「ユーザID=戸籍名」で、メールアドレスを決めてしまうと、幸か不幸か何度も結婚を繰り返しちゃった女性（男性も）、メールアドレスが頻繁に変わるわけですから、あまり好ましいものとは思えません。
本籍名を使うのか、通称を使うかの判断は「本人の希望があれば」認めるべきですが、業務上「頻繁に変更できない」というルールが必要です。
- 重要なのは文書化しておく事 -
忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って８文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。
--
とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に８文字運用している現場で、たまたま９文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、８文字に短くして問題が解決しています。
NetIQ の eDirectory を使ったID管理システム自体が、&& 条件で最小公倍数の 「8 文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。
もっともこう言った問題点は社内システムでは問題になりますが、今時 google のアカウントを８バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ただウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限８文字以上が必須だったりしますし。”８文字”（以下）が無難だ、というのはどこでもあり得る話なのです。
ログインIDが短いと、セキュリティ上問題があるんじゃないかとも思われますが、IDもパスワードもブランクで不明なアカウントをブルーフォートアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。
ユーザのログインＩＤの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザＩＤは何文字が許されるか」も併せて調べるともっと面白いかも知れません。
▲
by islandcenter
| 2018-10-08 16:42
| Identity Management
|
Comments(0)
2018年 04月 10日
Mac からSUSE Linux のX アプリケーションを使う
エラく久しぶりにMac を購入したのでMacintosh macOS からSUSE Linux を管理するためにX アプリケーション（特にYaST）を使う方法を探しました。何しろ YaST2 コントローラと FireFox がないと、アクティベーションや管理、アプリケーション登録なんかもできません。最低限 Mac から Linux の X アプリケーションを操作できる環境が必要です。
Mac 用の X11 についてX11 は Mac に付属しなくなりましたが、X11 のサーバとクライアントのライブラリは、XQuartz プロジェクトから入手できます。
--
macOS 用の X11 のサーバ／クライアントライブラリは、XQuartz プロジェクト (www.xquartz.org) から入手できます。提供されている最新バージョンをダウンロードしてください。
色々検索すると、古い macOS X にはx11 が標準だったのですが、macOS sierra にはついてこないらしい、ということで Apple さんお勧めの XQuartz を使ってみます。
XQuartz
よりダウンロード、インストールします。
Xquartz を起動して、「アプリケーション」から「ターミナル」を起動
$ ssh -Y user_name@Your_SUSE_host_ip_or_DNS
で接続します。
bash-3.2$ ssh -Y root@192.168.1.239Password:Last login: Mon Apr 9 09:41:50 2018 from 192.168.1.11sles11:~ ˙# yast2 &[1] 27936sles11:~ # firefox &[2] 27978sles11:~ # gedit &[3] 28016sles11:~ #
おお！
とこんな感じです。
macOS, HighSierra, 10.13.3, Linux 管理, X サーバー, X 端末, GUI アプリケーション起動
▲
by islandcenter
| 2018-04-10 14:35
| MacOS
|
Comments(0)
2018年 04月 10日
MacOS を英語に切り替える方法
また、海外製ソフトウェアのマニュアルを読んで、インストールや操作をするときに Finder のメニューの意味が日本語ではわからない事もあります。英語を母語とする、ソフトウェアのサポートデスクに症状を伝えるときに、日本語で説明する訳には行きません。
英語の画面のハードコピーなどが必要なわけですね。
という事で、Macを英語にしてしまうにはどうすればいいのか、というお話です。
- インターフェースを英語化するには -
「林檎」 > 「システム環境設定」 > 「言語と地域」 で左のペインに + キーで ”English” を追加します。英語が一番上に来るようにドラックして、この画面を閉じます。閉じる際に再起動を要求しますが。ログオフ、ログインで言語の変更は有効になります。
別に英語に変えても、日本語表示はおかしくないですし、IMEも使えます。
どうやらシステムのロケールも英語になるので、ターミナルからSSH で接続したLinux のロケールも「怪しいニホンゴ」から「正しい英語」になりました。おかげで SUSE Linux の YaST ツールも意味不明の日本語版から、ナチュラルな英語版になりました。ヨカッタ....
macOS, HighSierra, 10.13.3, 英語, 日本語, 切り替え
▲
by islandcenter
| 2018-04-10 14:07
| MacOS
|
Comments(0)
2018年 04月 10日
MacOS sierra で時刻同期先をLAN内や国内の任意のNTPサーバーに変更する
macOS では、デフォルトでは設定した地域内（日本では time.asia.apple.com.）のNTP サーバーに同期します。
しかし、これは、アドレスを調べるとアジアではなく実体はアメリカのApple にあるサーバーです。時刻のネットワークの経路によっては揺れが多く、何十台、何百台とある内部ネットワークコンピューターがバラバラな経路で外部に問い合わせる事は好ましいとは思いませんし、それぞれの端末が同じ時刻ソースにアクセスしないと微妙なタイムラグが起こります。
できれば、社内に ntp.nict.jp などの国内のパブリックntp サービスと既に同期をしている代表の構内 LAN 専用のNTP サーバーや、国内の近い経路にあるパブリックntp サービスに変更したいものです。
macOS の場合、「林檎」 > 「システム環境設定」 > 「日付と時刻」から「日付と時刻の自動設定」を変更することで、構内NTP に変更できます。
まずこの「日付と時刻」の左下にある「鍵」アイコンをクリックして、管理者用パスワードで鍵を解除します。 「日付と時刻の自動設定」がグレーアウトから、編集可能になるので
同期先 NTP サーバーのIP アドレスかDNS 名を設定して「鍵」をかけます。
これでNTP サービスはより近い、よりWAN回線や無料で提供されているパブリックntp の運営者に迷惑をかけない方法で、LAN内のコンピューターの時刻を同期させることができます。
SOHO 環境ならまだしも、ある程度以上の規模のネットワークであれば、内部のNTP サーバーを参照したほうが、それぞれのコンピュータが勝手に外部からバラバラに時刻同期を取るより、最短の経路で単一のNTP ソースを使うのがベターだと思います。
時刻同期は、文字通り「同期」です。NTTの１１７と全く同じである事よりも、構内ネットワークのそれぞれのデバイスが「ほぼ同じ時間」に同期していることが重要なのです。
macOS, HighSierra, 10.13.3, 時刻同期, NTPサービス
▲
by islandcenter
| 2018-04-10 13:30
| MacOS
|
Comments(0)
2018年 04月 10日
Mac の恥ずかしい「最近使った項目」を表示させない方法
近年、 BYOD だとか「働き方改革」などと言うキーワードで、モバイルノートの配布だとか、「仕事で自分のPCの持ち込み」なんかがOKになったりします。
まぁ、自宅持ち帰りPCで、プライベートな目的で使う事ってあまりないでしょうが、ついつい、仕事中にプライベートなデータにアクセスしちゃうという事は頻繁にあるわけですね。
そこで Mac で問題となるのは「最近使った項目」です。
Mac で「林檎」マークから、スクロールダウンすると、その途中で出てくるのが、この「最近使った項目」
これメッチャ恥ずかしいンですね。
昨日の夜に「妖しいデータを見ていた」
「下ネタサイト」みてて「キャハハ」と盛り上がった。
ナンてこと忘れて、いきなり朝から客先直行でプレゼンなんかすると
「最近使った項目」
にズラズラと、昨夜の「昨夜の妖しい」ファイルがリストされるわけですね。
何しろ、昨日の夜、黄表紙だとか枕本を見ていたとか、そういった「アンタは昨日何見てたのよ」という履歴がズラズラと、林檎マークの下にリストされるわけです。
つまりあなたのネクタイの下の品格、と言ったものまで疑われるわけです。
まぁ、仕事用であれば当然ミットモナイ事でも笑って誤魔化すって事になるんですが、自宅でコンピュータの前を離れたときに、同居人なんかに「林檎マークの下半身」を見られると、鍵かけずにトイレに入ってケツ拭いている時に、いきなり家族にドアを開けられた位に
「スマン、恥ずかしい」
と反省する訳ですね。
となると
「最近使った項目」は恥ずかしい。
という事で、Mac 版「最近使った項目」を表示させない方法です。
関連記事 Windows 版はこちらWindows10 の恥ずかしいクイックアクセスを表示しない
「林檎」 > 「システム環境設定」> 「一般設定」にある「最近使った項目」を "0" に設定します。
「最近使った項目」が消えました。
これで、あなたのネクタイの下の品格は保護され、コッパズカシイ想いをしなくて済むのです。
Linux でフォルダ容量制限付き Mac 向けファイルサーバー
macOS, HighSierra, 10.13.3 最近使った項目を非表示, 隠しフォルダ表示, 非表示, 過去の履歴を表示しない。mac 最近使った項目 保存場所,最近使った項目 履歴 削除,finder 最近使った項目 非表示, high sierra 最近使った項目 削除. 最近使ったフォルダ 削除, 最近使った項目 削除, 最近使った項目 編集, 最近使った項目 フォルダ 削除, 最近使った項目 表示
▲
by islandcenter
| 2018-04-10 13:13
| MacOS
|
Comments(0)
2018年 03月 05日
OES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫
あわせて読みたい
Novell OES Linux ファイルサーバーをファイルのゴミ箱にしない工夫OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバーOES 2018 が出荷されたようなので、評価版 ファーストインプレッション。
ファイルサーバーが常に抱える問題-ファイルサーバーはファイルのゴミ箱
部屋の中は、不要なもので一杯、ここで断捨離しなければ、と思いつつ、つい要るもの要らないものがブックシェルフに混在しているのが、私たちの暮らしなのですね。これが大家族なら、オカぁちゃんが「これ捨てるよ」と言っても、「いやぁだぁー」と子供に泣かれると困ってしまう。間違って捨ててしまうと晩飯も「食べたくねぇ」とゴネられます。
という事で、本棚にはよく読む本を置いておき、押し入れには、読むことはないけれど、時々必要になって引っ張り出してくる捨てられないデータというモノがあるんですね。子供のころのアルバムだとか、学校の卒業写真、人生でたった一度だけ取った英語の１００点満点のテスト、先祖が残した貴重な資料。まそんなところでしょうか。
同じ事が、企業の中のファイルサーバーにも当てはまるわけです。ある調査では、サーバーの中の３０％のファイルは「死んでるデータ」だそうです。
機械的に、「生きているデータ」「取っておきたいデータ」「死んでるデータ」「不要なデータ」と区分けして断捨離するのはシステム管理者としてできない事。実際のファイルの重要性の判断は、エンドユーザがある程度行わなければいけないわけです。目に見える倉庫の棚や、本棚と違って、目に見えないファイルサーバーのストレージは「醜い」「汚い」「乱雑だ」という事には気が付かず、ファイル整理の判断は難しいものです。
ファイルの断捨離は、利用者が行うべきであり、管理者はそのテンプレートを作ってやることが仕事となります。エンドユーザには中々嫌われる業務になるかも知れませんが、机の中や目に見える限られたスペースしかない物理的なファイルキャビネットの整理と同じく、利用価値のないファイルの整理もユーザの仕事なのです。
Linux 管理者なら、「アーカイブ」というのは tar とかのコマンドでファイルを圧縮してしまう事なのですが、業務の中でどのデータが重要でアーカイブして保存しておくことが重要かの判断はなかなか付かないものです。しかもいったん圧縮した内容は解凍しないと利用できないのですから、ユーザ側からすると、「アーカイブしたの忘れてた」という事になります。ましてやテープなどの外部メディアにアーカイブとっても、実際にその中のアーカイブデータが利用できるまでの道のりは低いわけですね。外部メディアにアーカイブするのはあくまでも「アーカイブのバックアップ」を目的とすべきでしょう。
ファイルサーバーはつねに増大するストレージにより、永遠に問題を抱えています。
何しろ、最近ではPCはノートブックやタブレットが主流になり、１２８GbのSSDとかしか記憶容量がないのです。しこに２０Tbもの巨大なファイルサーバーがあると、たとえそいつは１００人で共用している事にも気が付かず、「じゃぁディスクを増設して C:ドライブ丸ごとバックアップ」なんて無法な事をするエンドユーザもいるのです。
エンドユーザには気にならないものですが、ファイル共有用ファイルサーバーというのは、単にディスク一つを追加増設するだけでも大変な作業で、バックアップとリストア、バックアップに必要なメディアの確保、という膨大な作業が必要となります。
そこで、契約書や保存期間が法令や社内基準で定められているファイルを保管し、アーカイブとすることで、通常の「読み書き可能な共有フォルダ」「読み出し専用のフォルダ」「特定のユーザは書き込みや削除、移動はできるが読み込みと書き換えのできないアーカイブフォルダ」を作る事を考えてみましょう。
OES Linux のNSSファイルシステム
他のファイル共有システムのように「読み込み専用」「読み書き自由」の２種類の属性しかないファイルシステムと違い、Microforcus/Novell Open Enterprise Server(OES Linux) の NSS (Novell Storage Service)では[SRWCEMFA] のファイル・ディレクトリのトラスティやフォルダの属性が豊富で、フォルダのディスク容量クオータ（ディレクトリ単位の容量制限）ができるので、豊富なトラスティと属性を合わせて容量制限が利いたアーカイブ専用のフォルダ・ディレクトリを簡単に作ることができます
iManager からの Archive フォルダのアクセス権限
まず、Archive 専用のディレクトリを作り、このフォルダの読み込みだけのユーザと、読み込み、書き込みはできないが、ファイルの移動や削除ができるユーザ、グループを作ります。
エクスプローラのフォルダのプロパティから見た場合
Sales グループユーザはファイルの読み込み[ R F ]はできますが、移動、作成、削除[ WCE M ]が許可されていません。
ArchiveManager のグループユーザは、ファイルの読み込み、書き換え[ RW ]は許可されていませんが、ファイルの削除、作成（コピーや移動、上書き）[ CEFM ]は許可されています。
Sales グループのユーザはファイルの読み出しだけは許可されています。もし、Sales グループのメンバーは、普段使いのフォルダに作った「消さないでフォルダ」をアーカイブに移動させてもよいとするならば [ R C F ] の( create )権限を与えます。これにより、メンバーは「消さないでフォルダ」を「アーカイブに移動」させて、ArchiveManager グループメンバー以外は、削除したりアップデートできないようになります。
ただし、「ファイルの作成」はできても「削除、名前の変更」はできないので、誤ってこのフォルダで「新しいフォルダの作成」などを右クリックしてしまうと、当人には「削除できないフォルダ、ファイル」ができてしまいます。
一方、ArchiveManager グループのユーザはファイルやフォルダの作成、削除、移動は許可されますが、ファイルの閲覧、書き換えは許可されません。
条件は論理和ですから、両方のグループに所属している場合、[ w ] (書き込み)権がないだけなのでファイルの作成、コピー、削除、閲覧はできますが、ファイルの更新は許可されません。
ディレクトリ（フォルダ）のクォータ管理（容量制限）
ワークグループのディレクトリ（フォルダ）にはクオータ（容量制限）がかけられます。いくらファイルのセキュリティ機能があっても、フォルダのクォータ管理ができないと、狭い部屋（限られたリソース）にある、本棚はすぐに一杯になってしまいます。そこで、フォルダにクォータ（容量制限）をかけます。この作業は簡単で、システムが稼働中でも数クリックで設定され、即時有効になります。ある特定のユーザが大量のデータを作り、残りのメンバーはあまり使わない、というケースでもフォルダ容量制限が利いている限り、ユーザには関係なく、フォルダの容量制限が有効になります。
例えば、Sales フォルダには、外歩きであまりファイルを作らないユーザと、見積書の清書を行うアシスタントでは、作るファイルの量というのは違うという事です。ユーザクォータではこの様な気の利いた小回りができません。
例えば、普段使いのグループフォルダには１０Gb、アーカイブフォルダには２０Gbのクォータをかけておき、グループ作業用フォルダがクォータで満杯になった場合は、ArchiveManager グループに所属するユーザがグループフォルダから、アーカイブ専用のフォルダにファイルを移動させて、容量を開ける事ができます。
また、クォータが利いているアーカイブ専用フォルダがいっぱいになれば、まずファイルサーバーの中で参照されることがないだろうと思われるファイルは、光メディアやテープバックアップを行い、アーカイブの整理を行います。
また、容量制限がかかったアーカイブ専用フォルダは、普段あまり使われないファイルが多いという前提で、フォルダを作った時に「即時圧縮」の属性をつけておけば、ファイルの内容にもよりますが、 2～30% 程度は圧縮されるため、わざわざ ZIP 化したり tar.gz にする必要もありません。ファイルによっては、「ちょっと開くために時間がかかる」程度でユーザはファイルを開くことができます。
「部外秘」のフォルダからは「権利継承」を削除する
「部外秘フォルダ」からは「権利継承」( Inherited Rights Filter ) から全ての権限を Revoke （はく奪）する事で、部外者からは表示されないようにします。
明示的に「部外秘フォルダ」に Trustee を与えない限り、ユーザやグループにはフォルダすら見えなくなります。
このような感じでReadOnly フォルダ内の「部外秘フォルダ」自体が他部署では不可視になります。
おまけ ポスト用フォルダ
Microforcus/Novell OES の NSS ファイルシステムでは、[ c ] 権だけのフォルダを作ることができます。このフォルダは、私は「ドロップボックスフォルダ」と呼んで位います。C権を与えられたユーザは、このフォルダにドラック＆ドロップでファイルを保存する事だけはできます。しかし、フォルダを開いてファイルの読み書き、削除、変更どころか、フォルダを開く操作さえ拒否されます。つまり郵便箱( PostBox )のような使い方ができるわけですね。もちろんこの郵便箱を開いて中のファイルを収集するポストマンが必要なわけで、彼らにはファイルの移動、削除は許可されても、封筒を開封する（読み出し書き込み）権利はありません。
例えば、健康診断などのセンシチブなデータのポスト場所や、学校の宿題の投函場所として使うことができます。一般ユーザは「春の健康診断」のPDF ファイルをポストして、ポストマンは、例えば「田中の健康診断データ.pdf」を「総務の投函場所に移動」させることはできるが、内容は読むことができない、という事になります。この場合、ファイルを読み書き可能なディレクトリにコピーしてしまえば読み書き可能なので、PostManager のアカウントは厳重に利用してもらう事になります。
--
ファイルサーバーは企業のシステムとしては実に原始的で、古くから利用されているシステムです。過去も未来も、「ファイルサーバーのゴミ箱化」は避けて通れない問題で、システムコストの数十％を無駄に投資しています。
OES Linux は NetWare 時代からの「専用ファイルサーバーOS」です。はるか昔から、ファイルのトラスティ、ディレクトリクォータなど、豊富なファイル管理機能を備えています。
ディレクトリクォータを厳しく設定し、フォルダの管理を「生きているファイル」「あまり使われないファイル」「ほとんど使わないが保管すべきファイル」「死んでるファイル」とランク付けし、フォルダのアクセス制限を設計してしまえば、後は利用者側が限られたリソースを有効に利用できるのですね。
ファイルサーバーゴミ箱化,ファイルのゴミ箱化,ディスク容量制限,フォルダ容量制限,フォルダクォータ,ファイルサーバーのゴミ箱化,死んでるファイル,必要なファイル,アーカイブが必要なファイル,Linux, Windows,ファイルサーバー
▲
by islandcenter
| 2018-03-05 12:09
| OES Linux
|
Comments(0)
2018年 01月 28日
Thunderbird から gmail にログインできない。
2018/1 より、gmail の認証方式が変わったらしく、Thunderbird からログインできなくなりました。というより、昨年から、認証方式が変わったのですが、「Google アカウントで見つかった 1 件のセキュリティの問題を解決してください」との謎のメールが google 様から送り付けられ、通りにやったらログインできなくなってしまったという事。
"Please login via your web browser"「ブラウザからログインしろ」、との事なので
ブラウザから gmail.com にログインして、
右上の「アカウント」＞「ログインとセキュリティ」＞ 右のカラムの一番下にある「安全性の低いアプリの許可」: 「有効」に設定します。
次に Thunderbird 側の「ツール」＞「アカウント設定」から、gmail のアカウント名の下の「サーバー設定」から「認証方式」をトグルして "OAuth2" に変更してOKします。
その後、Thunderbird 内部でブラウザが起動するので google のアカウントのパスワードを設定します。その後Thunderbird のマスターパスワードを問われるのでマスターパスワードで認証します。
「安全性の低いアプリへのアクセスが有効になりました」というメールが google から届きます。
これで、gmail に Thunderbird からログインできるようになりました。
Oauth2 というのは、簡単に言うと ID/パスワード認証の仕組みではなく、「サービス vs. アプリケーション」の信頼関係、を作り出す仕組みだそうです。
この後、Thunderbird は、gmail にアクセスするために、google の パスワードではなく Thunderbird のマスターパスワードを要求するようになりました。
サーバーをゴミ箱にしない工夫
Thunderbird, gmail, ログインできない, パスワードが間違っている, 認証されない, Windows, Linux, gmail にブラウザからログインできるが、Thunderbird からログインできない。
▲
by islandcenter
| 2018-01-28 15:01
| Identity Management
|
Comments(0)
