isLandcenter 非番中

ブログトップ | ログイン

今は”パーソナルコンピュータ業界”は Windows 10 の無料アップデートでお祭り状態です。特に「無償アップデート」が決定している事で、

「Windows は無料になる」

という考え方が浸透してきました。

ところで、いわゆる”PC”は進化してきたのでしょうか。Windows 8/10 にせよ「画期的で斬新なアップデート」と世間で騒がれているほどの進化か、と聞かれれば、私は

「No、全然進化していない」

と答えざるを得ません。なぜなら、Windows7 が発売された 2008 年頃のPCであっても無償で Windows 10 へアップデートできるのです。これでは5年前のPCであっても最新の Windows が使える。

つまり、最新のオペレーティングシステムは必ずしも最新のハードウェアを要求しないということなのです。

-進化を止めたハードウェア-

「ムーアの法則が止まった」とはまだ誰も言い始めていませんが、現実にこの10年あまりで、マイクロプロセッサの処理クロックは3Ghz代で止まっています。

CPUの処理性能は単純にクロックに比例します。一つの命令を実行するために10クロックが必要であれば、現在のコンピュータでも、10年前のコンピュータでも同じ処理性能なのです。

ただし、ムーアの法則が止まっていない理由として、例えば10クロックかかって処理していた命令が5クロックで終わる様にマイクロコードが改良されたり、多コア化、省電力化などの面でムーアの法則がまだ生きているからなのです。この傾向は、タブレット用 ARM コア、サーバー、ノートブックなどで顕著です。10年前3GhzクラスのXEONプロセッサは今時8コア16スレッドなどの化け物に進化しています。ノートブック用マイクロプロセッサは、省電力面で進化していますが、微妙な所でしょう。

一方、デスクトップ用プロセッサの進化はここ数年、止まってしまったように思えます。微細化、高クロック化も非常に微妙です。インテルから新しいコアが出ても、ワクワクする様な事もなくなってしまいました。

-オペレーティングシステムは進化しているか-

上に乗るOSの基本的な機能では進化していません。あえて進化しているとすれば、クラウドとの連携したアプリケーションであり、オペレーティングシステム自体は、進化ではなく「変化」に過ぎません。Windows 7 --> Windows 8 --> Windows 10 への変化は、 Windows 7 をクラウド化して、コスメティックなユーザインターフェース(化粧)を与えただけなのです。

これは 「Windows が進化した」というより「Windowsが変化した」とだけしか言わざるを得ません。


-もっともっと変化するか-

実際、Windows も Linux もこの数年で必要とするハードウェエアスペックは変わりません。また、基本的な機能も変わっていません。もっとも利用する我々が進化しているわけではありません。利用方法が変化しただけです。

改善して欲しい基本的な機能とは、マルチタスクプロセスの管理であるとか、アクセスしっぱなしのファイルシステムであるとか、容易にハッキングされない強力なセキュリティ機能、余分なメモリを簡単にクリアできるガーベジコレクション、PnPによる簡単なデバイスの脱着、拡張子ではなく実行フラグを書き換えない限り容易にスクリプト実行できない実行管理などです。

Linux に関しては、様々なファイルシステムが開発され、よりスマートになりつつあります。一方でUIに関しては、リーナス氏も激怒するような、「どーしょーもない」タコなUIが出てきたりしますが、基本的にはカーネル、ファイルシステム、共に進化しているのは実感していますが、やはり画期的なモノがない。変化を感じさせる変化がないのです。その証拠に、Linux のデスクトップ利用者は5%にも満たない事があります。


- Windows は終わった -

Windows 10は最後のメジャーアップグレードになる?


一部のメディアで報道されている通り、Windows というヤツは Windows 10 でなくなるらしいと言う事。一般的な評価としては Windows は無料で使えるが、「月間いくら」のサービスアライアンス、サブスクリプション方式になるんじゃないか、とかウワサされています。

これがどの様な結果になるかはまぁ想像に任せておくにしても、「パーソナルコンピュータ」そのものの有り方に影響してくるのかも知れません。PCはオフラインでも使えるものでなければならないでしょうし、クラウドに全て依存する事が好ましいとは思えないのです。

-- 実際、日本の居住地の90数%がブロードバンド利用可能と言っても100%ではない。実際、僻地へ行けばADSLも光ファイバーのサービスもない所は沢山ある。高速道路の長いトンネルの中で、あるいは八丈島へ行くフェリーの中でインターネットにアクセスして情報をチェックできる日は来るのだろうか。勿論スマートフォンではなくPCでの話だ。 --

そもそも、クラウドサービスは「下り回線優先」のシステムでは使いづらい。「上り下り」が両立しないと使いないものなのです。

と言うより 「Windows がどうなるか」ではなく、次のPC用オペレーティングシステムはどうなるのか、という事が問題になります。Windows をベースに単に名前を変えたモノなのか、全くリニューアルされたシステムなのかです。

おそらく、I/F 自体はそれほど大きく変わらないでしょう。コンシューマが受け入れられない。

個人的には、今の肥大化して、セキュリティ上の問題を沢山抱えた Windows コードベースのシステムよりも、全く新しいオペレーティングシステムを期待しています。Apple が OSX を開発してレガシーな Mac OS を捨て去り、更には Power PC から Intel Mac にになったように、完全にコードを書き直すべきです。まだクラウドとタブレットの敗者である Microsoft はその力が残っているのです。

年賀状の印刷から、メール、システム開発まで全てをこなせるモノが「パーソナルコンピュータ」がPCと言われる所以なのです。PCは終わったとは思いません。まだまだPCの時代と役割は残っています。

異なるプラットフォームに従来の Windows の UI と互換APIを被せたオペレーティングシステム、それが私の希望です。


- 新しい Windows に必要なのはコンパイラ -

実は Windows 10 に「今一番欲しい機能」はコンパイラです。コンパイラがあれば、多くの Windows 向けフリーウェアがオープンソース化されるでしょう。現在の様にコンパイラが標準装備されていない事が、Windows を脆弱にしています。

例えオープンソースを基にバイナリ配布しているソフトウェアでも、結局は Windows 向けのバイナリ作成は最後になってしまう訳ですね。最悪の場合、SSHの様にバイナリ自体が更新されない。結局オープンソースではないフリーウェアは、作者や提供元の「やる気」だけで作られているため、永遠にコミュニティ化されないのです。だから、インストーラにマルウェアもどきの機能を付けたり、バイナリの配布サイトがハックされてマルウェアをインストールされたりしてしまう。

Windows 自体は別にオープンソース化されなくても、コンパイラが配布されれば、今流通している多くのすぐれたオープンソースソフトウェアの Windows への移植が始まるでしょう。使い物にならない、Windows サーバー用の DNS/DHCP やIIS の代わりに Apache や bind9 などが普及することになります。

-Windows サーバーはどうなる-

今、Windows サーバーでなければ動かないソフトウェアと言うのは、サードパーティ製品を除けば、SQLサーバーとか Active Directory 程度になってしまいました。ADすら Samba に搭載されてしまっているため、あえて Windows サーバーを選ぶ理由がほとんど消滅しています。せいぜい、

「クライアントと同じGUIで操作できる」

ところがメリットである程度で、これでさえクラウド化が進めば、あえてオンプレミスで運用する以外の目的であれば、全くWindows サーバーを選ぶ理由はなくなってしまいました。

もちろんサードパーティのソフトウェアが Windows オンリーであれば、それは立派で消極的な選択理由です。

下手をすると、ファイルサーバーという、オンプレミスにしたくなるシステムですらクラウドに移行してしまいます。

そうなると、クラウドベンダーとしてはリソースを大食いする Windows よりも Unix 系OSを選択するでしょう。いくら「クラウドベンダー化」に変身しようとしているマイクロソフトとしても、自社のクラウドサービスを Windows だけで運用するのは困難になります。これは「クラウドベンダー化した」マイクロソフトが歩むべき道となるのかも知れません。

マイクロソフトにとっても Cloud = Windows である必要は全くありません。Windows を捨て去り Clout サービスに移行する Microsoft にとっては Windows はもう不要で過去の遺産になる可能性もあるのです。もっとはっきり言おう。

Microsoft がクラウドベンダーになるには Windows は全く関係ない、むしろ足枷なのだ。

これでは Windows 帝国の崩壊です。

それはマイクロソフトとしても避けたいところでしょうから、サーバーOSそのものも Windows 後継製品は Windows とは似て異なるものになるのかも知れません。 とにかく 「Windows10」 以降の Windows と名前が付かない 「マイクロソフト製サーバー」というのはちょっと楽しみです。


「最後の Windows」というネタから、様々なとりとめのない妄想が生まれてしまいました。

islandcenter.jp
by islandcenter | 2015-06-26 09:31 | Windows | Comments(0)

意外な事に、未だに NetWare 3.x をご利用の環境があります。

90年代に工場や研究施設を新設した時に、計測機器や制御機器を DOS 接続するために構築された環境です。多くの場合、「装置一式」の固定資産として資産計上されている事。また、経営上、「装置一式」をリプレースする資金がない事、あるいは、「装置一式」自体をリプレースする必要が全くないケースなどです。

また、90年代から2000年にかけて導入した現状の製造関連装置(ハードウェア)が、専用のI/Fカードでなければ動かない、とか、装置そのものをアップデートする必要すらない、という場合もあります。こう言ったシステムは DOS/Windows2000/WindowsXP などで使い続けられています。

現実に、まれにキオスク端末であるとか、何等かの表示板に Windows の「ブルースクリーン」があった、というSNSの報告であるとかタレこみなどを見つける事があります。

街角エラー画面コレクション @nifty

これらのシステムは別にネットワークに接続しているわけでもないですし、そもそも「機器一式」を更新する必要すらないシステムなのです。そもそも、例えばニュース速報をテキストで流すだけの装置にしても、装置そのものは省電力化、効率化、高信頼性化されていても、システムそのものは別に更新する必要がなければ、そのまま使い続けられるでしょう。わざわざ作り替える必要もありません。

また、20年も30年も「新製品」を開発する必要がない製造業もあります。この様な現場では、既存の装置を使って製造し、品質をチェックします。

従って、ITビジネスを行う側からすると「レガシーは捨てて新しいシステムにしろ」と喧伝されるわけですが、運用する側からするならば、

「壊れて修理ができなくなるまで徹底的に使い倒せ」

という、ごく自然な考え方で運用されています。何しろ、経理上コンクリートの建屋の固定資産は30年です。その中にある装置自体も30年年のレベルで運用を想定しているお客様は沢山いるのです。

システム屋としては心配でもありますが、そういう考え方もあって当たり前だろうなとも思います。それでもPCサーバーを核としたこれらのシステムは、やはり経年劣化や、保守部品の不足などで「立ち上がらなくなったら怖いな」という事になります。修理部品がないわけですね。

という事で、意外な事なのですが、NetWare 3.x が以外な所で利用されているケースが2015年現在でもまだごく普通にあります。

- Windows がネットワークにつながらない -

こうしたシステムで、DOS + NetWare で運用していたシステムはほとんどのケースでは Windows XP でも繋がるため、問題なく利用できていました。しかし、 DOS + NetWare はプロトコルは IPX です。 Windows XP では標準で IPX が利用できたのですが、Windows 7 以降 IPX は実装されなくなりました。そこで、今まで運用してきた生産管理システムであるとか、品質管理システムだとか、キオスク端末などに、Windows(7/8) をつなげると

「あれれ!」

という事になります。

DOS の時代は最大メモリが 640Kb という壁があったため、IP を実装してアプリケーションを動かすことは非常に困難でした。動いても実用的ではありません。 i80386 の時代になってやっとメモリ空間を有効に利用できるようになりましたが、まだ主力が i80286 の時代だったので、共通の環境でファイル共有するという事自体困難だったのです。

NetWare 3.x の少ないメモリで動作する IPX と言うプロトコルはそんな時代背景の中で非常に貴重でした。

また、Windows NT サーバーがまだ不安定だった時代の事ですから、安定している NetWare 3.x を Windows 2000/XP などで IPX接続で、継続して使い続けるケースは、ごく自然な事でした。

- IPX を継続して使いたい -

と言う事で、「NetWare + IPX をまだ使いたい」というニーズを満たす方法と、最新の Windows 7/8 間でファイルをやり取りするには、今、提案できる事は NetWare 6.5 を仮想環境で動かす事です。

なぜ仮想環境が必要かと言うと、既に NetWare 6.5 の開発、サポートは終了しており、ハードウェアベンダーの互換性リストからも消え去ってしまったという理由です。

そこで、現在利用可能な最新のハードウェアでは NetWare が動作する可能性が少なく、SUSE Linux が公式にサポートされている Dell や HP と言った外資系ベンダーのハードウェアを選択します。外資系ベンダーでは、 RedHat, SUSE のみならず Unbuntu から CentOS まで検証しているケースがほとんどです。 国産ベンダーでは SUSE Linux は「マイナー」と判断されているのか、まず、世界第二位のシェアがある SUSE の商用版をサポートせず、Windows サーバー以外では精々 RedHat 程度しか検証はしていません。

従って、ハードウェア互換性リストにリストされているハイパーバイザー上で、NetWare を動かす事が一番確実な方法となります。Novell と SUSE はかつて同じ企業だった時代があり、現在も同じ資本グループで協業体制があります。そこで、SUSE Linux 上では NetWare は XEN 仮想環境でも KVM 仮想環境でも最新のハードウェアで動作させる事ができます。SUSE Linux には標準で NetWare 5.6 のテンプレートが含まれているため、SUSE ハイパーバイザーでは簡単、確実に NetWare 6.5を動作させることができます。
a0056607_1020175.jpg

a0056607_10232974.jpg

ただし、NetWare 6.5 と IPX は既に販売、サポート共に、Novell Inc. およびノベル株式会社でも終了している事はリスクとして十分認識しておくべきです。

※ できれば OES2 NetWare 6.5 番ではなく Linux 版をお勧めしたいのですが、次の点で問題があります。

- バインダリエミュレーションがない
- IPX がサポートされていない

また本筋とは離れていますが
- NWFS(従来の NetWare のファイルシステム)がない。

という点が制限となります。そこで Linux 版は IPX, バインダリ接続は出来ません。

Novell Client for Windows (XPまで) では プロトコル IPX を優先する事ができます。
a0056607_10215277.jpg

また Novell Client for Windows(XP) が使える環境であれば、バインダリ接続もできるため、バインダリ接続した場合、自動的に SYS:Mail に接続ユーザの mail ディレクトリが作成されるため、ここにログインスクリプトを記述することができます。
a0056607_14460923.jpg
バインダリエミュレーション

a0056607_14465110.jpg
プロトコル IPX


- Windows7/8 から NetWare 6.5 へのip/ipx接続 -


Novell Client 2 (Vista/7/8/10) をインストールした Windows PC より、 NetWare 6.5 サーバーに接続することができます。

これは、NetWare 5.x/6.x が ipx/ip デュアルスタックゲートウェイとなるため、古い DOS+IPX マシンでも、最新の Windows 7/8 でも全く問題なく利用できる、という事です。
a0056607_104139.jpg
日本の大手SIベンダーでは「既にサポートされていないソフトウェアはリスクが多すぎてサポートしない」のが原則です。そこで、現調して、新しい Windows サーバーと、最新のソフトウェア、一桁違う莫大なソフトウェア開発費を見積もってくるでしょう。そういう「大人の事情」がある訳です。

一般的な事務系、情報系システムと異なり、組み込み系、制御系にはそうした特殊な事情を理解している開発会社さんも居らっしゃる一方、制御系システムを一般的な情報系システムと同じレベルで考えている業者さんも居らっしゃるという事です。

OES 2018 SP1 Install
https://islandcnt.exblog.jp/239279772/


問い合わせは
islandcenter.jp
もしくはノベル株式会社さんへ





-Keyword-
Windows 7 Windows 8 NetWare に繋がらない。IPX バインダリ接続 PC9801 サーバー NetWare IP
by islandcenter | 2015-06-25 11:26 | Native Netware | Comments(0)

ちょっと旧聞になりますがSUSE Linux Enterprise Server 12 for SAP Applicationsリリースされました。

SUSE Introduces SUSE Linux Enterprise Server 12 for SAP Applications

SUSE Linux Enterprise Server 12 の SAP アプリケーション向けバージョンは、SLES 12 で標準となった Snapper と組み合わせ、DBのスナップショットを管理し、従来の SLES for SAP の様に、SAP での最適化されたチューニングが行われています。

a0056607_16232868.jpg


SAP のインストールウィザードはデフォルトで yast メニューにないため、 yast > software から "wizard" などのキーワードで見つけます。

a0056607_1625747.jpg


a0056607_16253943.jpg

by islandcenter | 2015-06-07 16:25 | SUSE | Comments(0)

あわせて読みたい

OES Linux サーバで容量制限付きアーカイブ専用フォルダ:サーバーをゴミ箱にしない工夫

OES 2018 が出荷されたようなので、評価版 ファーストインプレッション。

OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)

OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバー

共有ファイルサーバーというのは、便利な物なのですが、多人数で使っていると、自動的に「要らないファイルのゴミ箱化」、「将来性のないファイルの墓場化」「ファイルのゴミ屋敷化」されてしまう事になります。その「ファイルサーバーのゴミ箱」をセッセと多大なコストと暇を掛けてバックアップを取るというのは実に愚かしい行為です。Windows ファイルサーバーは、一般的に使いづらく、「データのアーカイブ」には便利ですが、「アーカイブ」の条件は個々のユーザが判断するため、一般ユーザは、「とりあえずバックアップしておきたい」ファイルを丸ごとコピーしてしまう傾向があるようです。特に C:\users なんてのは、丸ごと2世代バックアップを取る、なんて事はユーザさんは平気でやっちゃってくれます。

管理者は、こうした「行儀の悪い」ユーザにメールを送って削除を依頼したりするわけですが、この警告から実際にユーザがファイルを削除するかどうかの判断はユーザの勝手な判断でもあり、何のシステム的なルールもありません。共用部分でも、退職したユーザが残したゴミファイルで一杯。部署の担当者にとっても所有者不明で削除していいものなのかの判断もできません。

どうも Windows ファイルサーバーは特に「ファイルのゴミ箱」として使われるケースが多いようです。

もともとマンションの住民にとっては自分の部屋しか見えません。見えない共用部分の廊下やエレベーターホールが「ゴミ屋敷化」してもそれは管理者が勝手に片づけてくれるもの、という意識があります。

しかし、この様な状況は、例え、Linux + Samba であっても、Novell OES NetWare でも変わりがありません。しかし、Novell Open Enterprise Server (OES Linux) では Linux で使える様々なツールを使い回すことで、無秩序なファイルサーバーの運用ルールに一定の「決まり」を作ってしまえば、ファイルサーバーを「ゴミ箱」化してしまう運用に決定的な方法を作り出すことができます。年金機構の情報漏えいにしても、本来一時的に利用して消してしまえば良いデータを、いつまでも共有サーバーに保管しておいた、という運用上の不適切なルールが徹底されていなかったからなのですね。

要らないファイルはサッサと消してしまえ。

という提案です。

ファイルサーバーをゴミ箱にしないために何をすべきでしょうか。

1) フォルダにクォータ(ディレクトリ容量制限)をかける

残念ながら、Windows2012 以前 と Linux+samba ではボリューム単位、ユーザ、グループでしかクォータ管理ができません。iSCSI で割り当てる容量や、Linux ではdd コマンドで作った指定した容量を仮ストレージとしてユーザボリュームにマウントするとか、そもそもパーティションを細かく分けるとか、強引な方法はいくつかあるようです。

Novell Open Enterprise Server ならば、ユーザ+ボリューム単位、ユーザを無視したフォルダ・ディレクトリ単位でクォータ管理が数クリックの操作でできます。例えば VOL1:Share\Sales などに Sales グループの書き込みトラスティを与えて、ディレクトリクォータをかける、という設定が容易にできます。これで Sales グループが利用できる全体量を10Gバイトとかに制限をかける事ができます。この機能は、NetWare 時代から OES に引き継がれた当たり前に揃っている機能です。

ちなみにこの操作はオンラインで Novell Client がインストールされた Windows のフォルダのプロパティや iManager ツールで稼働中にオンライン一発で簡単に変更できます。いったん広げたディレクトリクォータも、簡単に制限を厳しくすることもできます。容量をオーバーしたときはフォルダがリードオンリーになります。ユーザはセッセと不要なファイルを削除しなければなりません。

a0056607_12393973.jpg

容量制限(クォータ)はフォルダ単位で与えることができるので、グループ、ユーザごとのボリュームクォータはほとんど OES 環境では使いません。(一度ユーザのボリュームクォータは使った事がありますが、運用上では非常に使いづらいですね。この設定は運用を停止してパーティションの切り直しも必要とせず、 OES Client Windows や iManager といったツールで1クリックで設定でき、運用中に即時反映されます。

これは、共用サーバーを運用する側にとっても重要で、年間の運用にかかるコスト(管理にかかる人日、バックアップメディアの購入費用、サーバー本体の償却費用)をそれぞれのグループに割り当てたフォルダの容量で頭割りする事で、この共用ファイルサーバーにかかる部門単位のコストを割り出す原資になります。

実際に、Windows や Linux+Samba でのボリューム(パーティション)単位、ユーザ単位でクォータを掛けてたとしても、社内常駐で、例えば Sales フォルダのファイルの作成や更新をセッセとやっている営業アシスタントと、そのファイルを参照するセールスマンの仕事のスタイルに違いがあります。一般的に、ユーザ+ボリューム(パーティション)単位でクォータを掛けても、社内業務を主に行うユーザと、更新より参照系の業務が多いユーザを区別することはありません。

そもそも、それ以前に Linux + Samba では、パーティションの設計が非常に難しくなります。したがって本格的、大規模に利用されているケースが、検索してもあまり見当たらないのは、公開もできない何らかの理由があるからでしょうか。

したがって、あまりユーザ、グループをボリューム単位でクォータをかけるのは良い事ではありませんし、ほとんど意味がなく、まず実際には使われていないように思えます。したがって、トラスティがある「営業部のフォルダは10G、開発部は20Gですね。ホームディレクトリは5Gに制限します」とディレクトリクォータをかけた方が良いわけです。これで、ユーザは自然に「大事なファイル」だけをセッセと共有フォルダに保存するように心がけ、無駄なファイルを置かない習慣ができるのです。Linux + Samba ではこの機能はありませんし、 Windows では 2012 以降に利用できる様になったようですがサクセスストーリーが見当たりません。残念ながら、Windows でディレクトリクォータを使うケースを紹介している記事はあまり見ません。つまり、Windows ファイルサーバーは単なる「ファイルのゴミ箱」なのです。

2) アクセスのないファイルを削除してしまう。

それでも、ファイルサーバーは一つ間違えると「ファイルのゴミ箱」となってしまいます。重要なアーカイブであるならまだしも「生きていない」ファイル「死んでいるファイル」を片付けるには、実際にアクセスのないファイルを探して削除してしまう方法が一番でしょう。 Novell Open Enterprise Server は SUSE Linux ベースなので、NSSボリュームに対しても、一般的は find コマンドを使って "find -exec rm" でアクセスのないファイルを自動削除する事ができます。 NetWare が Linux に移植されて、使い勝手が良くなった点の一つです。

これが今回の主題です。

ファイルの更新日時を変えてみる

oes11x1:/media/nss/VOL2 # touch -d "2010/1/1" test/old-text.txt

oes11x1:/media/nss/VOL2 # ls test -alu
total 1384
drwxrwxrwx 1 root root 4096 May 29 15:55 .
drwxrwxrwx 1 root root 4096 May 29 15:43 ..
-rw-rw-rw- 1 root root 707395 May 29 15:53 old-butnew_text.txt
-rw-rw-rw- 1 nobody root 707395 Jan 1 2010 old-text.txt

a0056607_1251628.jpg



oes11x1:/media/nss/VOL2 # ls test -l
total 1384
-rw-rw-rw- 1 root root 707395 May 29 15:53 old-butnew_text.txt
-rw-rw-rw- 1 nobody root 707395 Jan 1 2010 old-text.txt

30 日以上アクセスがないファイルを探してみる
oes11x1:/media/nss/VOL2 # find test -atime +30

.. 見当たらない..

一日以上アクセスのないファイルを探してみる
oes11x1:/media/nss/VOL2 # find test -atime +1
test/old-butnew_text.txt
test/old-text.txt

..あった..

一日以上変更のないファイルを探してみる

oes11x1:/media/nss/VOL2 # find test -mtime +1
test
test/old-butnew_text.txt
test/old-text.txt

.. 二つあった ..

そのうちの一つを開いてみる(保存はしない vi で開いて :q! で逃げる)

oes11x1:/media/nss/VOL2 # vi test/old-butnew_text.txt

一日以上アクセスのないファイルを探してみる

oes11x1:/media/nss/VOL2 # find test -atime +1
test/old-text.txt

.. さっき開いたファイルがリストされなくなった ..

それでは「1日以上アクセスがないファイルを削除」してみます。

oes11x1:/media/nss/VOL2 # find test -atime +1 -exec rm -f {} \;
oes11x1:/media/nss/VOL2 # ls test -lu
total 692
-rw-rw-rw- 1 root root 707395 Jun 1 09:00 old-butnew_text.txt

... アクセスしなかった old-text.txt だけ消えた ....

今度は「更新されていないファイルを削除」してみる
oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

今度は mtime を使ってみる

oes11x1:/media/nss/VOL2 # ls test -lu
total 0

.. 変更されていないため、削除 ..

oes11x1:/media/nss/VOL2 # vi test/newfile

.. 新しいファイルをつくって保存してみる ..

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jun 1 09:43 newfile

1日以上更新がないファイルを削除してみる。
oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

... -mtime ... で一日以上更新のないファイルを探して削除

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jun 1 09:43 newfile

.. 作成したばかりで消えない ..

oes11x1:/media/nss/VOL2 # touch test/newfile -d "2000/1/1"

.. touch して更新日付を変えてみた ..

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jan 1 2000 newfile

.. 変わっている ..

oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

.. -mtime で削除できるか ...

oes11x1:/media/nss/VOL2 # ls test -lu
total 0

... 削除された ...

oes11x1:/media/nss/VOL2 #

... ファイルを作ってみる ....

oes11x1:/media/nss/VOL2 # touch test/newfile
oes11x1:/media/nss/VOL2 # ls test -alu
total 0
drwxrwxrwx 1 root root 4096 Jun 1 10:11 .
drwxrwxrwx 1 root root 4096 Jun 1 10:10 ..
-rw-rw-rw- 1 root root 0 Jun 1 10:11 newfile

... rmdir ... で一日以上古いディレクトリを削除してみる

oes11x1:/media/nss/VOL2 # find . -mtime +1 -exec rmdir {} \;
rmdir: failed to remove `./test': Directory not empty

..ファイルあるので rmdir では削除されない..


※もっとも、ファイルを削除するという事はディレクトリエントリの更新が入るため、ディレクトリの更新時間もアップデートされてしまいます。という事で一日待ってみました。

- 一日後 -

oes11x1:/media/nss/VOL2 # date
Tue Jun 2 11:15:13 JST 2015
oes11x1:/media/nss/VOL2 # ls -alu
total 16
drwxrwxrwx 1 root root 4096 Jun 2 11:15 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 1 10:17 ._NETWARE
drwxrwxrwx 1 root root 4096 Jun 2 11:14 test <-- これ
drwxrwxrwx 1 root root 4096 Jun 2 11:14 test2
drwxrwxrwx 1 root root 4096 Jun 1 17:14 test3

oes11x1:/media/nss/VOL2 # find . -mtime +1 -exec rmdir {} \;
  <-- 一日以上アクセスがないディレクトリを削除
find: `./test': No such file or directory

oes11x1:/media/nss/VOL2 # ls -alu
total 16
drwxrwxrwx 1 root root 4096 Jun 2 11:15 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 11:15 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 11:15 test2 <-- なくなりました
drwxrwxrwx 1 root root 4096 Jun 2 11:15 test3

-r--r--r-- 1 root root 24 Jun 1 17:20 ~DFSINFO.8-P
oes11x1:/media/nss/VOL2 #

ただし find コマンドでディレクトリサーチを行うと、「ディレクトリにアクセスされた」と判断される様で、タイムスタンプが変わってしまいます。それならば、もっとシンプルな方法で、「空のディレクトリは無条件で削除」してみる事にします。

-空のディレクトリを削除-

oes11x1:/media/nss/VOL2 # ls -alu
total 12
drwxrwxrwx 1 root root 4096 Jun 2 12:08 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 12:05 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 12:05 test2
drwxrwxrwx 1 root root 4096 Jun 2 12:05 test3
oes11x1:/media/nss/VOL2 # find . -type d -empty -delete
oes11x1:/media/nss/VOL2 # ls -alu
total 12
drwxrwxrwx 1 root root 4096 Jun 2 12:09 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 12:09 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 12:09 test3 <-- 空ディレクトリが消えた
oes11x1:/media/nss/VOL2 #

-サイズの大きなファイルを削除-
最近はあまり見なくなりましたが、ネットでダウンロードした「同僚に言えないファイル」をセッセと職場のファイルサーバーに保存する不届きなユーザも居ます。管理者からするとバレバレなんですけど、バックアップログを見ていると、こんな無駄なファイルの為にバックアップを毎日取っていると虚しくなります。

そこで、一定以上のファイルサイズのファイル(特にビデオファイルなんか)を削除してみます。

oes11x1:/media/nss/VOL2 # ls test -l
total 278016
-rw-rw-rw- 1 root root 284673464 Jun 2 14:15 Himitsu.AVI
<--- なんじゃこの巨大ファイルは.....
--w--w--w- 1 nobody root 7168 Jun 2 13:59 Thumbs.db
-rw-rw-rw- 1 root root 22 Jun 2 14:05 small.file
oes11x1:/media/nss/VOL2 # find . -size +10000k
  <-- 10M以上のサイズのファイルを探す。
./test/Himitsu.AVI
oes11x1:/media/nss/VOL2 # find . -size +10000k -exec rm -f {} \;
<--- 削除する。
oes11x1:/media/nss/VOL2 # ls test -l
total 12
--w--w--w- 1 nobody root 7168 Jun 2 13:59 Thumbs.db
-rw-rw-rw- 1 root root 22 Jun 2 14:05 small.file
 <--- 巨大なファイルだけ消された。

※ -size は k(バイト) M(バイト) G(バイト) の指定もできます。

 
まとめ

実運用では、テープバックアップなどの作業を行う前に実行されているように、定期的に cron 実行する形式になるでしょう。

また、厳しくクォータをかけたディレクトリと「一定の条件で削除される」フォルダとの違いをユーザに説明しておくことは重要です。ここでは( . ) カレントディレクトリを指定していますが、実際の運用では絶対パスを指定するようなスクリプトを作った方が良いでしょう。

- カレントディレクトリ( . )以下の1日以上アクセスがないファイルを削除 -
find . -atime +1 -exec rm -f {} \;
find . -name "*.*" -atime +1 -exec rm -f {} \;
※ スペースが入っているファイルや漢字ファイルがあるとうまく動かないので -name "*.*" を付けてみました

これでも十分なのですが、空ディレクトリが残ってしまうため

- カレントディレクトリ( . )以下のファイルのない空のディレクトリを削除 -
# find . -type d -empty -delete

事例では1日としていますが、当然90日とか365日とか指定できるため、これは現状に合わせて適度に調整する事になるでしょう。

一定のサイズ以上のファイルを削除
# find . -size +10000k -exec rm -f {} \;
ここでは +10000k 以上、つまり10Mとしてみました。

※ ヒント:実際には "Thumbs.db" などが残ってしまうケースもあり、これを find スキャンするとタイムスタンプが更新されてしまうため、ディレクトリは空にはならない様です。エクスプローラから見てファイルがないのに、ディレクトリが削除できません。が、実際には Thumbs.DB が残っているためです。明示的に削除しないとダメな様です。実際の運用の現場で find を使いこなして、うまく”古くて消したいファイル”を削除する必要があります。

-オマケ-
oes11x1:/media/nss/VOL2/test4 # touch -at 0511121213 file-a
oes11x1:/media/nss/VOL2/test4 # ls -alu
total 0
drwxrwxrwx 1 root root 4096 Jun 4 11:17 .
drwxrwxrwx 1 root root 4096 Jun 4 11:01 ..
-rw-rw-rw- 1 root root 0 Nov 12 2005 file-a


touch -at YYYYYMMDDHHMM file-name.txt (月日年時分年々月日時分) 形式でファイルの最終アクセス時刻を意図的に変更できます。

ファイルサーバーのフォルダ容量制限


- Key Word -
Novell Open Enterprise Server クォータ管理、容量管理、古いファイルの自動削除、ファイルサーバー管理

by islandcenter | 2015-06-02 13:08 | OES Linux | Comments(0)