Pautomount-自動マウント、スクリプトの実行などのためのデーモン

私の前にタスクがありました-Debianにストレージデバイスを挿入すると自動的にアクションを実行します。 たとえば、単に自動的にマウントします。 または、デバイスがわかっている場合は、データをマウントして同期することもできます。 または、彼のclamavであらゆる種類のゴミをチェックし、USBワクチンのようなものを実行します。 所有者がコンピューターの近くにいない場合、サイレンをオンにすることもできます=）



たとえば、フラッシュドライブは5〜7個あります。 それぞれが独自のものを持っています。1つはブート可能、1つはドキュメント、1つはプログラム、1つは音楽と写真です...そして、フラッシュドライブにはすべてのコピーがすべてあるサーバーが自宅にあります。 ドキュメントを1つのフラッシュドライブ、他のフラッシュドライブ、音楽、写真、3番目のブートイメージなどと同期させたい。 これは、SSHを介してサーバーに登ってハンドルですべてを編集するたびに適切ではないため、どうにかしてこのビジネスを自動的に開始する必要があります。 したがって、フラッシュドライブを登録し、接続時に必要なアクションを設定できる場所が必要です。 同期スクリプトを作成したら、それで終わりです。



ここにしか準備が整っておらず、Googleで完全に適切なものが見つかりませんでした。 いくつかのソリューションには多くの依存関係が含まれ、ヘッドレスインストール用に設計されていないもの、時代遅れのもの、必要な機能をすべて備えていないもの、これを可能にするものがありますが、あまりにも退屈で構成が難しく、一般的にNIHがあります;-)自動マウントデーモンです。私はここに投稿しています。おそらく他の誰か、おそらくホームサーバーの同じ所有者がフラッシュドライブを同じ方法でホームNASと同期させたいと思うでしょう。 はい、誰かにコードを批判し、エラーを指摘し、いくつかの問題の解決策を提案してもらいたいです。トピックの最後をご覧ください。





どういうわけかiPodを持っていた。 Linuxを搭載したコンピューターから充電する必要が生じることがありました。 しかし、コンピュータに接続するとすぐに、すぐに同期モードがオンになります。 充電を停止するには、ハードウェアソリューション（特別に閉じた接点を備えたオス-メスのUSBアダプター）またはeject / dev / sdx1が必要です。これにより、同期モードがオフになり、充電モードになります。 したがって、毎回このコマンドを実行する必要があります-アダプターのはんだ付けはとても怠...です...そのようなスクリプトが生まれました-umipod.sh：（UnMount-iPOD）







コードの品質に唾を吐かないでください、それは2年前に書かれたもので、記事にはたくさんのコードがあります-唾液の世話をしてください=）最後の行は簡単です-ループでは、特定のUUIDを持つデバイスが接続されているかどうかを確認しますデバイスをブロックして、これを実行します。 プレーヤーをコンピューターに接続すると、数秒後に自動的にオフになりますが、充電は続行されます。音楽を聴き続けることができます。 それは非常に便利でした...私がプレーヤーを失うまで=（それ以来、そのようなデバイスの必要性は事実上なくなりました。



そして今、私はメディアを接続するときに自動アクションを必要とするいくつかのタスクに直面しています。 だから私はそれを修正することにしました。今だけで、Bashに近づきませんでした=）長い間プログラミング言語を選択する必要はありませんでした。率直に言って、私は最近Pythonをやっています。 その後、デーモンを作成するか、ループ内で新しい未処理パーティションがあるかどうかを確認するか、またはフラッシュドライブが接続されたときにプログラムがコールバックとして呼び出されるようにudevに固執するかどうかを検討する必要がありました。 2番目のオプションはより少ないリソースを消費するようです-最初のオプションはudevに依存せず、より簡単です=）したがって、安全に自動実行できるデーモンを作成することにしました。



実際、 彼はここにいます。 デバイスと機能について説明し、構成方法を説明するのが最も簡単です。 しかし、それでも、作業の原則について簡単に説明します。

1. デーモンはn秒ごとに/ dev / disk / by-uuidをチェックし、データから利用可能なパーティションのリストをコンパイルします
2. このリストは、n秒前に作成されたリストと比較され、以前は存在しなかったセクションが定義されます
3. 接続されたばかりのセクションがある場合、configのエントリによって、無視するセクションとアクションを実行するセクションが決まります。
4. 後藤1

さらに-すでにconfigの説明が必要です=）configは通常4つのセクションで構成されており、いずれも安全にスキップできます。

 { "globals": { "interval":3, "debug":false, "noexecute":true, "comment":"Everything that is in this section will be exported as a global variable in the script, replacing if there's something to replace." }, "exceptions": [ {"uuid":"ceb62844-7cc8-4dcc-8127-105253a081fc", "comment":"System boot partition"}, {"uuid":"6d1a8448-10c2-4d42-b8f6-ee790a849228", "comment":"System root partition"}, {"uuid":"9b0bb1fc-8720-4793-ab35-8a028a475d1e", "comment":"System swap partition"} ], "rules": [ {"uuid":"E02C8F0E2C8EDEC2", "mount":{"mountpoint":"/media/16G-DT100G2"}}, {"uuid":"7F22-AD64", "mount":{"mountpoint":"/media/16G-DT100G3"}}, {"uuid":"406C9EEE6C9EDE4A", "mount":{"mountpoint":"/media/80G-Music"}}, {"uuid":"52663FC01BD35EA4", "mount":{"mountpoint":"/media/32G-Data"}} ], "default": { "mount":true, "comment":"Configuration section for the actions that are taken if drive isn't in either exception or rule list." } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1）セクション「グローバル」

ここではすべてが簡単です-このセクションの変数は、そのような気取らない機能でデーモンのグローバル名前空間にエクスポートされます：





シンプルかつ高速で、エクスポート用の変数のリストを作成したり、すべての変数を辞書にプッシュしたりする必要はありません。



便利な変数：

main_mount_dir-マウントパスが不明であるか、相対パスとして指定されている場合のマウント用のメインディレクトリ。 デフォルトは「/ media」です。

default_mount_option-デフォルトでマウントするとき、他のオプションが指定されていないときのオプション。 「rw」はそこに残しますが、ファイルシステムのドライバーでデフォルトで既に指定されているかどうかはわかりません=）

logfile-ログファイルへのパス。 変更する必要がある場合は、絶対を指定することをお勧めします。相対=）を指定した場合、悪魔はログの保存先を知っている可能性が高くなります。

interval-新しいパーティションのチェック間隔。 私に関しては-1秒の間隔でも、シングルコアのCeleron 900MHzでもプロセッサに大きな負荷はかかりません=）



それほど有用ではない変数：

デバッグ -ここではすべてが明確です。 ログファイルのサイズの増加を大幅にスピードアップします。実際には必要ないでしょう=）

super_debug-ログファイルの拡張子をさらに高速化します。 必要になる可能性はさらに低くなります。

noexecuteはデフォルトで有効になっているオプションで、デーモンは外部コマンドの呼び出しのみをシミュレートします。したがって、最初に起動してからオプションが削除されるまで、何もマウント/実行されません。 デーモンをセットアップする前に、fstabを使用してすでにマウントされているパーティションをマウントしないようにするために作成されました。

2）セクション「例外」

このセクションにUUID /ラベルがリストされているセクションは、すべて無視されます。 実際、主な使用例は、システムがfstabからブートするときに自動的にマウントされるパーティションです。 つまり、このセクションの通常のエントリは次のようになります。

  "exceptions": [ {"uuid":"ceb62844-7cc8-4dcc-8127-105253a081fc", "comment":"System boot partition"}, {"uuid":"6d1a8448-10c2-4d42-b8f6-ee790a849228", "comment":"System root partition"}, {"uuid":"9b0bb1fc-8720-4793-ab35-8a028a475d1e", "comment":"System swap partition"} ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、「コメント」などのあらゆる種類のキーは自然に無視されます。 辞書内のキーの再利用トリックを除き、これはJSON =形式の設定ファイルにコメントする唯一の方法です

3）セクション「ルール」

特別な場合のルールはここで説明されています。 たとえば、ここでタイプのルールを指定できます。

  {"uuid":"E02C8F0E2C8EDEC2", "mount":{"mountpoint":"/media/16G-DT100G2", "options":"rw,uid=1002,gid=1002"}},
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなルールがある場合、UUID E02C8F0E2C8EDEC2のパーティションは、オプション「rw、uid = 1002、gid = 1002」を使用して、パス「/ media / 16G-DT100G2」に常にマウントされます。

4）セクション「デフォルト」

ここではすべてが簡単です-セクションが前の2つのセクションのエントリに対応していない場合、このセクションがデフォルトのアクションを担当します。 通常、「mount」：trueまたは「mount」：falseのみが含まれます。

ルール

ご覧のとおり、ルールの最後の3つのセクションには、2種類の変数があります。

最初のタイプは、特定のセクションを識別するための変数です。 これまでのところ、「uuid」、「label」、「label_regex」の3つのタイプがあります。

• 「Uuid」 -ここではすべてが明確です。
• 「ラベル」 -セクションのラベルを設定できます。設定されている場合、アクションが実行されます。
• 「Label_regex」 -re.match（）を使用して、ドライブラベルを指定された正規表現に一致させます。 入力では、当然、Perlのような正規表現が期待されます。

2番目のタイプは、アクションを示す変数です。 それらの3つもあります。

• 「マウント」には、true（自動的にマウント）、false（マウントしない）、またはマウント用の追加の引数を持つ辞書（true）の値を指定できます。 これまでのところ、辞書の有効なキーは「mountpoint」（マウントポイントを指定）および「options」（マウント用の追加オプション）です。
• 「コマンド」は、実行するコマンドへのパスを含む文字列です。 ここではすべてが明確です=）
• 「スクリプト」は、引数「DEVICE_PATH UUID MOUNTPOINT LABEL」で呼び出されるカスタムスクリプトの一種です。 最後の2つではなく、マウントポイントまたはパーティションラベルがない場合は、なしになります。

当然、「例外」セクションを処理するとき、指定されていてもアクションは受け入れられず、識別変数は「デフォルト」セクションで処理されません-意味がありません=）



構成にいくつかのルール例を追加します。

 { "globals": { "interval":1, "debug":false, "default_mount_option":"noexec,noatime,rw" }, "exceptions": [ {"label":"Root", "comment":"System boot partition"}, {"uuid":"6d1a8448-10c2-4d42-b8f6-ee790a849228", "comment":"System root partition"}, {"uuid":"9b0bb1fc-8720-4793-ab35-8a028a475d1e", "comment":"System swap partition"} ], "rules": [ {"label":"MULTISYSTEM", "mount":{"mountpoint":"/media/MULTISYSTEM", "comment":" ,        =( "}}, {"uuid":"7F22-AD64", "mount":{"mountpoint":"/media/16G-DT100G3"}, "command":"/usr/local/bin/sync_dt100g3.sh"}, {"uuid":"406C9EEE6C9EDE4A", "mount":{"mountpoint":"/media/80G-Music"}, "command":"mocp --server; mocp -P", "comment":"    "}, {"label_regex":".*iPhone.*", "mount":true, "script":"/usr/loca/bin/iphone_factory_restore.sh", "comment":"   ;-) "} ], "default": { "mount":false, "comment":"  ,    " } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なんで？

最後に-この悪魔は何を許可しますか？ 接続されたデバイスにパーティションを自動的にマウントするのに役立つことに加えて、次のことにも使用できます。

1. Linuxホームサーバーなどのリムーバブルメディアファイルの同期
2. USBモードスイッチの一種で、iPodでも同じ状況を覚えている
3. メディアのウイルススキャン
4. 他の誰かのiPhone / Android /フラッシュドライブ/カメラからのデータを静かにマージ=）
5. ネットワーク経由でメディアにアクセスするためのサンバボールを作成する

すべてが記述され、完全に実行されていますが、まだ完全に洗練されていないので、セキュリティを改善し、悪魔を書くことで長年にわたって発展してきたいくつかの伝統に従うためにいくつかの質問があります。

1. この悪魔を常にルートの下に維持することは可能ですか？ 問題は、すべてのコマンドを実行するための特権が必要なことです。たとえば、外部スクリプトのマウントと実行の両方があり、その中には、たとえば同じrsyncがある場合があります。 設定ファイルのセキュリティは同じオペラからのものです。 スクリプトがルートの下で実行され、 誤って MBRとMFTを消去するコマンドが構成に書き込まれている場合、それは楽しいでしょう。
2. スクリプトとコマンドを実行するには、間違いなく、近い将来、バックグラウンドで、別のスレッドで必須の実行を行う必要があります-さもなければ、数秒以上動作するコマンドはデーモン全体をブロックします。 原則として、インストール中に同じ状況が発生する場合があります。 しかし、ジレンマがあります-バックグラウンドでマウントすると、マウントの前にコマンドまたはスクリプトを実行できます。これは競合状態=です（各パーティションの処理を個別のスレッドに分離するため、マウントがハングした場合は競合状態がないかハングしますあなたはまだFSを修正する必要があるという事実のために。
3. デーモンはそれ自体でバックグラウンドに入る必要がありますか、それともオプションですか？ これまでのところ、このように配置されています-デーモン自体はバックグラウンドモードに入る方法を知りません。initスクリプトのstart-stop-daemonによって行われます。
4. ブロックデバイス（/ dev / sdxZ）への道は、マウントされているかどうかを確認する最も簡単で最速の方法ですか？ 外部コマンドを使用して、標準的なPythonモジュールを使用することをお勧めします。 そうすれば、同じパーティションをダブルマウントすることに関連する問題を取り除くことが可能になります。 mtabを解析し、UUIDをブロックデバイスへのパスにマッピングすることは、依然としてタスクです;-)
5. 最初の起動の前にfstabから例外リストを生成する価値がありますか、それともペンで一度これをノックするユーザーに頼ることができますか？
6. 外部スクリプトを実行するときは、パーティションラベルに誤って「&& rm -rf /」（外部スクリプトの実行時に機能する）や「../../etc/」(「/などの代わりにセクションをマウントできる」など）の可能性がある特殊文字を考慮する必要があります"）;-)質問-この穴を完全に保護するには、どの特殊文字をフィルタリングする必要がありますか？ 「＆」、「/」、および「;」がすぐに思い浮かびますが、おそらくそれ以上です。

Github

ちなみに、この記事は私が約束した内容の続編と見なすことができますが、 Debianを使用したポータブルサーバーのセットアップに関する一連の記事の中断としてほぼ1年間です。 ファイルサーバーを実装するフレームワーク内でこのようなことをしようとしていましたが、そのときだけ既製のソリューションを見つけることができませんでした...そして今、私は自分で=を書きました）近い将来、このコースのテーマに合う記事をさらに2つ書くことを考えています。