共有フォルダを利用中のユーザーを特定する方法（ファイルサーバー再起動前に使うテク） | IT trip
本記事では、共有フォルダにアクセスしているユーザーを特定する方法を解説します。ファイルサーバーの再起動前に使うテクニックです。 管理コンソールの起動 ファイルサーバーでファイル名を指定して実行に、「mmc」と入力してください 管理コンソールが立ち上がります。「はい」を選択 管理コンソールの設定 ファイルを選択し、「スナップインの追加と削除」を選択してください 利用できるスナップインから「共有フォルダー」を追加します。 デフォルトのままで問題ありません。 共有フォルダ利用中のユーザーを特定 管理コンソールで「共有」「セッション」「開いているファイル」の３項目が選択できるようになります。 共有では、共有フォルダ毎に接続しているクライアント数を確認できます。 セッションでは、共有フォルダに接続しているユーザーの一覧が確認できます。 開いているファイルでは、現在開かれているファイルの一覧を確認でき
KNOPPIX 等を用いてサーバの HDD を抹消するメモ - [ぴ](2013-01-12)
_ [システム運用] KNOPPIX 等を用いてサーバの HDD を抹消するメモ 最近聞かれたのでメモを置いておきます。 BIOS の RAID 設定画面を開き、ホットスペアがあった場合は解除のうえ、全ディスクをアレイに割り当てる。 (機種により開き方、操作方法は異なる。RAID タイプは1や10等、できるだけ実効容量が少なくなる構成にしておいた方が効率的に抹消できる。)KNOPPIX 等で起動し、Terminal Emulator を開く。sudo gparted を開き、右上に表示されるディスクデバイス名を全て確認する。 (大抵 /dev/sda だが、機器によって異なる場合がある。RAID 構成で論理ディスクを複数設けてある場合は、/dev/sdb 等2番目以降のディスクが存在する場合もあるので注意。)sudo shred で抹消する。 2回ランダムの場合 → sudo shred
](https://cdn-ak-scissors.b.st-hatena.com/image/square/d228e8be070c32c738781e15c25aeb18f4dc6807/height=288;version=1;width=512/https%3A%2F%2Fpmakino.jp%2Ftdiary%2Ftheme%2Fogimage.png)
daemontoolsで勝手にプロセスが終了していたという悲しい状況を防ぐ | Act as Professional
Ruby1.9スクリプト(Twitterbot)をLinuxデーモン化する方法 にて、Rubyスクリプトをデーモン化して、簡単に自動起動と停止できるようにしました。 ですが、何らかの影響で、Rubyスクリプトが終了してしまった場合にスクリプトが落ちたままになってしまいます。これは精神衛生上非常に良くない。 今回は、daemontoolsを使用して、プロセスが終了しても自動的に立ち上げ直す状態をつくります。 よって、名残惜しむことなく、前回つくったデーモンを停止して設定などを削除します。 $ sudo /etc/init.d/tweet stop $ sudo update-rc -f tweet remove daemontoolsとは？daemontoolsとは、バグが無いと有名なqmailの作者であるD. J. Bernstein氏が作成したテーモンの制御ツールです。 デーモンプロセス
RAIDボードのWriteCacheの考え方についての誤解: わがままWEBシステム
最近、おかしな誤解をしていたことが発覚しました。 サーバ電源障害時における、RAIDボードのライトキャッシュの動きについてです。 RAIDボードでライトキャッシュ付、バッテリー付のものがあります。 存在は知っていたけど、使ったことはなかったんです。 なんとなく理屈とか効果は知っていました。でも、電源系の障害が発生した時の動きについての理解がぜんぜん間違っていてびっくり。 自分の勝手な理解 ・サーバの電源が落ちる ・キャッシュの内容を早くDISKに書かなきゃ！ ・バッテリーが生きてるうちに、DISKもバッテリーで駆動させて がんばって書き終えるんだ～（おそらく数秒で書き込み完了） ・バッテリーが上がっても、もう大丈夫 と、こんな感じ。 これだとDISKの電源はRAIDボードにつながったバッテリーからも給電を受けられるような機構が必要で、当然、そうなっているものと思っていました。 現実（DEL
ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ハードウェア編)
尾藤正人です。 ウノウでは最近新オフィスに引越ししたのですが、新オフィスにサーバルームを設置してフォト蔵のサーバをホスティング業者から自社サーバに移行しました。 自社サーバに移行のは下記のような理由からです。 フォト蔵のようなストレージ系のサービスの場合、十分な帯域を確保する必要があるが、広帯域を確保するにはコストがかかる フォト蔵のようなストレージ系サービスの場合、大容量のHDDが必要になるが、大容量のHDDを搭載したマシンはハイエンドマシンになり、増設コストがかかる マシンの増設に時間がかかりフレキシブルに対応できない というわけで自社サーバに移行したわけですが、自社サーバに移行するにあたって様々なノウハウがたまってきました。 サーバ構築にはいろいろトピックスがありますが、今回はハードウェア的な部分について書きたいと思います。 ・マシンは全て同じ構成にする 数多くのサーバを運用するに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
申し込み時のちょっとした裏技 - とあるプログラマの日記 @s025236
