カテゴリー: コンピューター

カテゴリー
2025年 Linux LPIC Ubuntu トラブルシューティング 技術一般 管理

複数の宛先に ping を打つことができる「fping」


にほんブログ村

Windows には「Exping」という便利なツールがあるのですが、ExpingはLinuxでは使えません。でも、Linuxには「fping」があります。今回は、「fping」の使い方をまとめてみました。

fping のインストール

「apt install」でインストールできます。

$ sudo apt update
$ sudo apt install fping

ping の使い方

基本的な使い方は、１つの宛先に対して ICMP Echo Request を送ります。通常の ping と同じです。

ICMP Echo Reply が返ってこれば「xxxx is alive」、返ってこなければ「xxx is unreachable」と表示されます。

KKIntt@jackson:~$ fping 172.16.26.1
172.16.26.1 is alive
KKInt@jackson:~$ fping 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
172.16.26.5 is unreachable

もちろん、IPアドレスだけでなく、ホスト名を指定することもできます。

KKInt@jackson:~$ fping www.yahoo.co.jp
www.yahoo.co.jp is alive

宛先の複数指定

単純に、ICMP Echo Request を送信したい宛先を並べて指定します。

KKInt@jackson:~$ fping 172.16.26.1 172.16.26.2 172.16.26.4
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive

範囲を指定しての宛先指定

-g オプションを使うことで、指定した範囲の IPアドレスに対して ICMP Echo Request を送信することが出来ます。

以下の例では、172.16.26.1から172.16.26.5までを範囲として指定しています。そのうち、4オクテッド目が3と5のIPアドレスからはICMP Echo Reply が返ってていません。

KKInt@jackson:~$ fping -g 172.16.26.1 172.16.26.5
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
172.16.26.3 is unreachable
172.16.26.5 is unreachable

サブネットマスクを指定しての宛先指定

-g オプションを使用すると、サブネットマスク単位で ICMP Echo Request を送信する範囲を指定することも出来ます。

「172.16.26.0/29」を指定する場合は、以下のように指定します。

最初の 172.16.26.0 はネットワークアドレス、最後の172.16.26.7 はブロードキャストアドレスになるため、「172.16.26.0/29」の場合、172.16.26.1 – 172.16.26.6 がPing の対象となります。

KKInt@jackson:~$ fping -g 172.16.26.0/29
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.6
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.6
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.6
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.6
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.5
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.3
172.16.26.3 is unreachable
172.16.26.5 is unreachable
172.16.26.6 is unreachable
kanta@jackson:~$

ファイルから読み込んで範囲指定

-f オプションを使用すると、ファイル読み込んでfpingを実行することが出来ます。

まず、ping-list というファイルを作成し、 以下のように宛先IPアドレスを記述しました。

KKInt@jackson:~$ cat ping-list 
172.16.26.1
172.16.26.2
172.16.26.4
172.16.26.7
172.16.26.8

-f オプションで対象のファイルを読み込んで fping を実行することで、ファイルに記載されている宛先 IPアドレスに対して ICMP Echo Request を送信することが出来ます。

KKInt@jackson:~$ fping -f ping-list
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
172.16.26.7 is alive
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
172.16.26.8 is unreachable

結局はLinux上での操作ですので、ファイルの読み込ませ方は、いろいろできます。

「<」でファイルを fping に渡せますし、

$ fping < ping_list.txt

cat で表示させたファイルの内容を fping に渡すことも可能です。

$ cat ping_list.txt | fping

送信回数指定

-c オプションを使用すると、ICMP Echo Request を送信する回数を指定することが出来ます。

3回送信したい場合は、以下のように実行します。

KKInt@jackson:~$ fping -c3 172.16.26.1
172.16.26.1 : [0], 64 bytes, 0.203 ms (0.203 avg, 0% loss)
172.16.26.1 : [1], 64 bytes, 0.234 ms (0.218 avg, 0% loss)
172.16.26.1 : [2], 64 bytes, 0.150 ms (0.195 avg, 0% loss)

172.16.26.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.150/0.195/0.234

送信し続ける

ICMP Echo Request を送信し続けたい場合は -l オプションを使用します。

「Ctrl + C」で、Echo Request の送信を停止することができます。

KKInt@jackson:~$ fping -l 172.16.26.1
172.16.26.1 : [0], 64 bytes, 0.226 ms (0.226 avg, 0% loss)
172.16.26.1 : [1], 64 bytes, 0.132 ms (0.179 avg, 0% loss)
172.16.26.1 : [2], 64 bytes, 0.125 ms (0.161 avg, 0% loss)
172.16.26.1 : [3], 64 bytes, 0.195 ms (0.169 avg, 0% loss)
172.16.26.1 : [4], 64 bytes, 0.205 ms (0.176 avg, 0% loss)
172.16.26.1 : [5], 64 bytes, 0.223 ms (0.184 avg, 0% loss)
^C <<< Ctl + c で終了
172.16.26.1 : xmt/rcv/%loss = 6/6/0%, min/avg/max = 0.125/0.184/0.226

送信間隔(ミリ秒)

-i オプションを使用すると、ICMP Echo Request を送信する間隔を指定することが出来ます。

指定する時間の単位はミリ秒なので、3秒間隔ならば「3000」と指定します。

KKInt@jackson:~$ fping -c3 -i 3000 172.16.26.1
172.16.26.1 : [0], 64 bytes, 0.185 ms (0.185 avg, 0% loss)
172.16.26.1 : [1], 64 bytes, 0.138 ms (0.162 avg, 0% loss)
172.16.26.1 : [2], 64 bytes, 0.186 ms (0.170 avg, 0% loss)

172.16.26.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.138/0.170/0.186

ICMP Host Unreachableを表示させたくない

ICMP Echo Request が失敗した際に表示される「ICMP Host Unreachable 〜」というメッセージを表示させたくない場合の方法です。

「ICMP Host Unreachable 〜」は標準エラー出力なので、「2>」を指定してエラー出力を /dev/null に送ることで、メッセージの表示を抑えることができます。

KKInt@jackson:~$ fping -f ping-list 2> /dev/null 
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
172.16.26.7 is alive
172.16.26.8 is unreachable

alive なホストのみ表示

-a オプションを使用すると、ICMP Echo Replyを返す（Alive）ホストのみを表示することができます。

以下の例では「ICMP Host Unreachable 〜」のメッセージを/dev/null に送って表示させないようにしています。

KKInt@jackson:~$ fping -a  -f ping-list 2> /dev/null 
172.16.26.1
172.16.26.2
172.16.26.4
172.16.26.7

-a オプションを使わなくても、以下のように grep で抽出することもできます。

KKInt@jackson:~$ fping -f ping-list 2> /dev/null | grep alive
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
172.16.26.7 is alive

unreachable だけ表示

-u オプションを使用すると、ICMP Echo Reply を返さないホスト（unreachable）のみを表示することができます。

KKInt@jackson:~$ fping -u -f ping-list 2> /dev/null 
172.16.26.8

unreachable のメッセージも合わせて表示させたい場合は、fping の結果を grepに渡すことで unreachable のみ表示させることもできますね。

KKInt@jackson:~$ fping -f ping-list 2> /dev/null | grep unreachable
172.16.26.8 is unreachable

統計情報表示

-s オプションを使用すると、実行結果の統計情報を表示します。

KKInt@jackson:~$ fping -f ping-list -s
172.16.26.1 is alive
172.16.26.2 is alive
172.16.26.4 is alive
172.16.26.7 is alive
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
ICMP Host Unreachable from 172.16.26.11 for ICMP Echo sent to 172.16.26.8
172.16.26.8 is unreachable

       5 targets
       4 alive
       1 unreachable
       0 unknown addresses

       4 timeouts (waiting for response)
       8 ICMP Echos sent
       4 ICMP Echo Replies received
       4 other ICMP received

 0.207 ms (min round trip time)
 0.229 ms (avg round trip time)
 0.249 ms (max round trip time)
        4.107 sec (elapsed real time)

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2024年 Azure Microsoft MS Azure Administrator MS Azure Fundamentals クラウド コンピューター 技術一般 認定資格

MS Azure を学ぶ (3) リソースグループの作成と管理 2


にほんブログ村

合格した Azure Administrator (AZ-104）の更新日がだんだんと近づいてきましたので、復習を兼ねて少しずつアウトプットしていきたいと思います。

私が勉強に使った教材は、こちらでブログで紹介しています。

リソースグループのメリット

リソースグループにリソースをまとめておくことで、次のようなメリットがあります。

  • リソースの閲覧がしやすくなる
  • リソースグループごとに課金情報を整理することで、各グループの費用を明確把握できる
  • 不要になったリソースを複数まとめて削除できる
  • リソースグループを対象としたテンプレートを活用することで、複数のリソースを一括してデプロイできる
  • 権限やポリシーを複数のリソースに対してまとめて付与できる
  • リソースへのアクセス権限を集中管理し、セキュリティーを強化できる

パソコンに例えると、テキストや Excel、Word などのファイルを「フォルダに格納して整理」することに似ています。

パソコンで、フォルダごと削除、フォルダに権限を付与するといったことが可能なように、Azure ではリソースグループを使って、まとめて管理が可能となります。

リソースグループの一般的な使われ方

ライフサイクルの異なるリソースごとで分類するのが一般的な使い方となります。

  • 開発環境
  • 検証環境
  • 本番環境　など

特に、一時的にテストや検証で利用したい環境などを作成し、後からまとめて削除する場合は、一つのリソースグループにまとめておくと便利です。

リソースグループの注意点

リソースグループを使う上で、いろいろと注意点があります。

  • リソースグループは入れ子にできない
  • リソースグループに所属するリソースのリージョンは別々でもOK（別リージョンにある各リソースを、同じリソースグループに入れることが可能）
  • リソースは、複数のリソースグループに所属できない（どれか一つのリソースグループにのみ所属）
  • 後から別のリソースグループに移動させることもできる

リソースグループの移動

移動操作の間は、ソース グループとターゲット グループの両方がロックされます。

つまり、これらのリソース グループに対する書き込み操作および削除操作は、移動が完了するまでブロックされます。 このロックはリソース グループでリソースを追加、更新、削除できなくなることを意味します。 リソースは停止されません。

たとえば、Azure SQL 論理サーバー、そのサーバーのデータベース、そのサーバーに依存している他のリソースを新しいリソースグループやサブスクリプションに移動しても、そのデータベースを使用するアプリケーションにダウンタイムは発生しません。 引き続きデータベースの読み取りと書き込みを行うことができます。

ロックは最大 4 時間継続できますが、ほとんどの移動は短い時間で完了します。

リソースを移動しても、新しいリソース グループまたはサブスクリプションに移動されるだけです。 リソースの場所は変わりません。

仮想マシンの作成

それでは、今後は移動対象となるリソースを作成したいと思います。

「作成」ボタンを押します。

リソースの作成

マーケットプレースの画面が表示されます。

Fedora Linux を起動させてみましょう。

インスタンスの起動

「作成」ボタンを押します。

インスタンスの作成

Fedora 向けに、以下の項目を指定してきます。

  • サブスクリプション
  • リソースグループ
  • 仮想マシン名（Fedora Linux の名前）

ここで指定するリソースグループは、デフォルトの名前を使用します。これにより、その名前のリソースグループが新規で作成され、リソースがそこに作成されます。

管理アカウントの認証の種類では、今回はパスワードを指定します。

ログインの際に使用するユーザー名とそのパスワードを指定します。

「次：ディスク」を押して次に進みます。

インスタンスの作成

テストで動かすだけの仮想マシンなので、最小の構成にしておきます。

「次：ネットワーク」を押して、次に進みます。

インスタンスの作成

テストなので、ここも基本的にはそのままで良いでしょう。

「確認および作成」をクリックして、次に進みます。

ネットワークの作成

最終確認をして「作成」ボタンを押します。

インスタンスの作成

仮想マシンの作成が始まりました。これには少し時間がかかります。

インスタンスのディプロイ

作成が完了しました。

ディプロイ完了

リソースグループの作成

Azure ポータルにログインして、サービス一覧を表示しますと、「リソースグループ」が見えます。それをクリックします。

リソースグループの表示

上部メニューから「作成」をクリックして、新規でリソースグループを作成します。

リソースグループの作成開始

以下の項目を指定していきます。

  • サブスクリプション
  • リソースグループ（新規リソースグループの名前）
  • リージョン

移動先のリソースグループとして、「KKInternational-test」という名のリソースグループを新規作成します。

リソースグループの名前とリージョンを指定

「作成」ボタンを押します。

リソースグループの作成

リソースグループが新規作成されました。

リソースグループ作成完了

リソースグループの移動

それでは、作成した仮想マシン（Fedora）を、別のリソースグループに移動させてみたいと思います。

ただいま、この仮想マシンのリソースは、KKInternationa-Linux-test_group という名前のリソースグループ内にあります。

移動元になるリソースグループ名をクリックして、リソース一覧を表示させます。

移動させる対象となるリソースをクリックします。今回は全てのリソースを移動させます。

上部メニューにある「移動」ボタンを押します。

プルダウンメニューが表示されるので、「別のリソースグループに移動する」を選択します。

インスタンスを別のリソースグループへ移動

リソースの移動画面が表示されます。

「リソース」のところで、移動先になるリソース名（先ほど作成したもの）をプルダウンメニューから選択します。

「次へ」を押して進みます。

移動先のリソースグループを指定

検証保留中となり、対象のリソースが移動できるかのチェックが開始されます。

移動の確認中

検証が終わり、全てのリソースが「成功」と表示されました。全てのリソースの移動ができるみたいですね。

「次へ」を押して進みます。

確認完了

「リソースの移動」画面が表示されます。

チェックボックスにチェックを入れ、「移動」ボタンを押します。

さあ、リソースの移動が始まります。

リソース移動の開始

リソースの移動が始まりました。

この移動には、結構時間がかかります。

リソースの移動完了

リソースの移動が完了したら、元のリソースグループ名（KKInt -Linux-test_group）をクリックして、中を見てみましょう。

仮想マシンの作成時に見えていたリソースの一覧がなくなっています。

古いリソースグループの内容（リソースが無くなっている）

今度は、移動先のリソースグループ名（KKInternational-test）をクリックしてみます。

選択した全てのリソースが見えていますね。

新しいリソースグループの内容（リソースが移動して表示されている）

リソースの移動が完了しました。

合格対策Microsoft認定試験AZ-104:Microsoft Azure Administratorテキスト&演習問題

posted with カエレバ

（模擬試験付き）徹底攻略 Microsoft Azure Administrator 教科書 [AZ-104] 対応

posted with カエレバ

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2024年 DNS Linux Raspberry Pi Ubuntu ガジェット コンピューター 広告ブロック

Raspberry PiでのPi-Hole設定ガイド


にほんブログ村

Pi-Hole の動作環境

Pi-Hole の動作環境は、以下の通りとなります。

1台目は、Raspberry Pi 4 (4GB) に Raspberry Pi OS 64ビット版をインストールし、そこに Pi-Hole をインストールしました。

2台目は、VMWare のハイパーバイザー（ESXi）の上で動かしている Ubuntu デスクトップにインストールしました。

どちらも快適に動作しています。

Pi-Hole のインストール手順

Curl を使って、Pi-Hole をインストールします。

curl -sSL https://install.pi-hole.net | bash

このような画面が表示され、

インストールが始まります。

インストーラーが動き出します。

「OK」で進みます。

「Pi-HoleはOpen Source Software です」のお知らせです。

「OK」で進みます。

「スタティックIPアドレスが必要です」と出ています。

Pi-Hole は DNS サーバーとなりますので、IPアドレスは固定にする必要があります。

「Continue」を選択して進みます。

通常は、Raspberry Pi のオンボードのイーサネットポートである「eth0」を選択でしょう。

私の環境では、ブリッジインターフェース（br0）を作っていて、そこに IP アドレスを設定していますので、 br0 を選択しています。

選択して、「Select」を押して決定します。

サーバーなので、スタティック IP アドレスを使いましょう。

「Yes」を選択して「Continue」で次に数みます。

ネットワーク上に、IPアドレスの重複がないかを確認します。

重複がなければ「OK」を押して、次に進みます。

Upstream DNS プロバイダーを選択します。

私は Google を使っています。「OK」を押して、次に進みます。

「サードパーティーのブロックリストを使ってますよ」とのことです。

「OK」を押して、次に進みます。

ウェブベースの管理インターフェースです。

今後、Pi-Hole を管理する上で便利なのでインストールしておきましょう。

「Yes」を押して、次に進みます。

管理インターフェースがウェブベースですので、ウェブサーバーが必要となります。インストールしましょう。

Lighthttpd と PHP のモジュールを使っているようですね。

「Yes」を押して、次に進みます。

運用が始まってからの管理で、ログも必要になるはずです。ロギングも有効にします。

「Yes」を押して、次に進みます。

FTL の説明はこちらにあります。

「Show everything」を選択し、「Continue」を押します。

モジュールのインストールが始まります。

これには、結構時間がかかります。

私の環境では、20分くらいかかったと思います。Raspberry Pi はそれほどマシンパワーがないからでしょう。仮想マシンのLinuxにインストールした時は、数分で完了しました。

「Installation Complete!」のメッセージが表示されたら、インストールは無事完了です。

「OK」を押す前に、管理インターフェースのURLと、ログインパスワードが表示されていますので、メモしておきます。

「OK」を押して次に進むと、インストールの完了です。

早速、先ほどメモした内容で、管理インターフェースにログインしてみましょう。

フィルターカウンターが上がらない時の対応

最初にPi-Hole をインストールした時に遭遇した事象です。

テスト PC の DNS を Pi-Hole に向けてあるのですが、何もカウントが上がっていないようでした。

おかしいなあと悩んだ結果分かったのですが、Pi-Hole 側でもDNS の設定できるみたいです。

Settings > DNS  の画面に進み、「Upstream DNS Servers」のところに、Pi-Hole が問い合わせるNDS サーバーのIP アドレスを指定します。

ブロックカウンターが上がり、グラフも表示されるようになりました。

広告リストの追加

デフォルトで登録されている広告リストだけでは足りないので、さらに広告をブロックできるように、広告リストを追加します。

ウェブ管理画面にて、Adlists >> Adlist Group Management の順にアクセスして、広告リストを追加していきます。

The Firedog

緑色で表示されているものがお勧めのようです。

Setup Pihole To Block TikTok

pihole-block-tiktok

ポルノ系ブロックリスト

広告リストを追加したら、Update を行って適用しないといけません。忘れないようにUpdate しておきましょう。

Tools >> Update Gravity のページの Update ボタンです。

面白かったら、フォローしてください！

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2024年 iSCSI Linux LPIC QNAP Ubuntu コンピューター ストレージ

UbuntuとQNAPのiSCSI統合方法


にほんブログ村

Ubuntu を使って、外部ストレージの iSCSI ターゲットに接続させた時のメモです。

今回の構成は、以下の通りです。

Ubuntu と QNAP は同じセグメントに設置していますが、別のセグメントであっても OK です。ただし、遅延がない程度の距離にした方が良いです。

以前 10ミリ秒 もないくらいの距離で試しましたが、遅くて使い物になりませんでした。同じ LAN 内にした方が良いです。

iSCSI イニシエーターのインストール

iSCSI イニシエーターのモジュールをインストールします。

kk@Jackson:~$ sudo apt -y install open-iscsi 
[sudo] password for kk: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
　　　　　＜省略＞
Processing triggers for libc-bin (2.35-0ubuntu3.6) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for initramfs-tools (0.140ubuntu13.4) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-15-generic
kk@Jackson:~$

iSCSI の設定

「/etc/iscsi/」のフォルダーができますので、その中の「initiatorname.iscsi」のファイルを編集します。

kk@Jackson:/etc/iscsi$ ls -la 
total 36
drwxr-xr-x   2 root root  4096 Feb  6 12:01 .
drwxr-xr-x 149 root root 12288 Feb  6 12:01 ..
-rw-------   1 root root   348 Feb  6 12:01 initiatorname.iscsi  <<< このファイルを編集
-rw-r--r--   1 root root 13334 Jan 19  2022 iscsid.conf
kk@Jackson:/etc/iscsi$ 
kk@Jackson:/etc/iscsi$ sido vim initiatorname.iscsi

iSCSI ターゲットとなるストレージ側で設定しているターゲット名（IQN）を指定します。

## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator.  The InitiatorName must be unique
## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
# InitiatorName=iqn.2004-10.com.ubuntu:01:c317f55f6df
InitiatorName=iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748  <<< iSCSI ターゲットを指定

次に、同じフォルダーにある「iscsid.conf」ファイルを編集します。

kk@Jackson:/etc/iscsi$ ls -la 
total 36
drwxr-xr-x   2 root root  4096 Feb  6 12:10 .
drwxr-xr-x 149 root root 12288 Feb  6 12:01 ..
-rw-------   1 root root   415 Feb  6 12:10 initiatorname.iscsi
-rw-r--r--   1 root root 13334 Jan 19  2022 iscsid.conf  <<< このファイルを編集
kk@Jackson:/etc/iscsi$ 
kk@Jackson:/etc/iscsi$ sido vim iscsid.conf

58行目から70行目にかけて設定をしていきます。

まず、CHAP 認証を有効にします。

次に、iSCSI ターゲット側で設定しているユーザー名とパスワードを指定します。

# *************
# CHAP Settings
# *************

# To enable CHAP authentication set node.session.auth.authmethod
# to CHAP. The default is None.
#node.session.auth.authmethod = CHAP
node.session.auth.authmethod = CHAP  <<< コメントを外して有効化

# To configure which CHAP algorithms to enable set
# node.session.auth.chap_algs to a comma seperated list.
# The algorithms should be listen with most prefered first.
# Valid values are MD5, SHA1, SHA256, and SHA3-256.
# The default is MD5.
#node.session.auth.chap_algs = SHA3-256,SHA256,SHA1,MD5

# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
#node.session.auth.username = username
#node.session.auth.password = password
node.session.auth.username = kkint  <<< ユーザー名を指定
node.session.auth.password = 1234567890abcde  <<< パスワードを指定

iSCSI のデーモンを再起動して、設定変更を読み込ませます。

kk@Jackson:/etc/iscsi$ sudo systemctl restart iscsid open-iscsi 

kk@Jackson:/etc/iscsi$ systemctl status iscsid open-iscsi.service 
● iscsid.service - iSCSI initiator daemon (iscsid)
     Loaded: loaded (/lib/systemd/system/iscsid.service; disabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-02-06 12:18:43 JST; 18s ago
TriggeredBy: ● iscsid.socket
       Docs: man:iscsid(8)
    Process: 808615 ExecStartPre=/lib/open-iscsi/startup-checks.sh (code=exited, status=0/SUCCESS)
    Process: 808618 ExecStart=/sbin/iscsid (code=exited, status=0/SUCCESS)
   Main PID: 808620 (iscsid)
      Tasks: 2 (limit: 4488)
     Memory: 4.4M
        CPU: 42ms
     CGroup: /system.slice/iscsid.service
             ├─808619 /sbin/iscsid
             └─808620 /sbin/iscsid

Feb 06 12:18:43 Jackson systemd[1]: Starting iSCSI initiator daemon (iscsid)...
Feb 06 12:18:43 Jackson iscsid[808618]: iSCSI logger with pid=808619 started!
Feb 06 12:18:43 Jackson systemd[1]: Started iSCSI initiator daemon (iscsid).
Feb 06 12:18:44 Jackson iscsid[808619]: iSCSI daemon with pid=808620 started!

○ open-iscsi.service - Login to default iSCSI targets
     Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2024-02-06 12:18:43 JST; 18s ago
             ├─ ConditionDirectoryNotEmpty=|/etc/iscsi/nodes was not met
             └─ ConditionDirectoryNotEmpty=|/sys/class/iscsi_session was not met
       Docs: man:iscsiadm(8)
             man:iscsid(8)

Feb 06 12:01:54 Jackson systemd[1]: Condition check resulted in Login to default iSCSI targets be>
Feb 06 12:18:43 Jackson systemd[1]: Condition check resulted in Login to default iSCSI targets be>
kk@Jackson:/etc/iscsi$

iSCSI 接続

ディスカバリーをしてみます。

iSCSI ターゲットの IP アドレスを指定します。

ストレージが見えましたね。

kk@Jackson:/etc/iscsi$ sudo iscsiadm -m discovery -t sendtargets -p 172.16.26.4
172.16.26.4:3260,1 iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748
kk@Jackson:/etc/iscsi$

状態を確認します。

こちらでもストレージが見えています。

kk@Jackson:/etc/iscsi$ sudo iscsiadm -m node -o show 
# BEGIN RECORD 2.1.5
node.name = iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748
node.tpgt = 1
node.startup = manual
node.leading_login = No
iface.iscsi_ifacename = default
iface.net_ifacename = <empty>
iface.ipaddress = <empty>
iface.prefix_len = 0
iface.hwaddress = <empty>
iface.transport_name = tcp
　　　　　<省略>
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
# END RECORD
kk@Jackson:/etc/iscsi$

iSCSI ターゲットにログインします。

「successful」が表示されれば OK です。

表示されない場合、IQN や IP アドレス、ユーザー名、パスワードが間違っている可能性があります。

kk@Jackson:/etc/iscsi$ sudo iscsiadm -m node --login -p 172.16.26.4
Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748, portal: 172.16.26.4,3260]
Login to [iface: default, target: iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748, portal: 172.16.26.4,3260] successful.
kk@Jackson:/etc/iscsi$

接続確認

確立しているセッションを確認します。

kk@Jackson:/etc/iscsi$ sudo iscsiadm -m session -o show 
tcp: [1] 172.16.26.4:3260,1 iqn.2004-04.com.qnap:ts-231k:iscsi.jonathan.45e748 (non-flash)
kk@Jackson:/etc/iscsi$

QNAP の方の設定も見てみます。

Ubuntu (172.16.26.10)から接続されていますね。

システムの起動時に自動で接続するようにするには、以下の設定を入れておきます。

kk@Jackson:/etc/iscsi$ sudo iscsiadm -m node -p 172.16.26.4 -o update -n node.startup -v automatic 
kk@Jackson:/etc/iscsi$

パーティションを見てみましょう。

「sdb」で、ストレージの iSCSI 領域が見えてますね。 

kk@Jackson:/etc/iscsi$ cat /proc/partitions 
major minor  #blocks  name

   7        0          4 loop0
   7        1      64988 loop1
   7        2      65444 loop2
   7        3      75892 loop3
   7        4      75676 loop4
   7        6     268812 loop6
   7        7     358084 loop7
   8        0   31266648 sda
   8        1     524288 sda1
   8        2   30740480 sda2
   7        8     358088 loop8
   7        9     508804 loop9
   7       10     508908 loop10
   7       11      93888 loop11
   7       12      47032 loop12
   7       13      12620 loop13
   7       14      41836 loop14
   7       15      41400 loop15
   7       16        452 loop16
   7       17        428 loop17
   7       18     268380 loop18
   8       16 2411724800 sdb  <<<
   8       17 2411722752 sdb1
kk@Jackson:/etc/iscsi$

面白かったら、フォローしてください！

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2023年 Cron Linux LPIC コマンド コンピューター 技術一般 自動化

Linux の Cron の基本的な使い方と設定方法


にほんブログ村

こんなことしたいと思ったりしませんか？

  • 毎日、ある時間にプログラムを実行したい。
  • 一時間に一回、コマンドを実行したい。
  • 毎月一度、バックアップを取りたい。

Linuxには、定期的にコマンドを実行するために cron と呼ばれるデーモンプロセスがあります。これを使うと、決まった時間にコマンドを実行させたりすることができて便利です。

今回は、Cron（クーロン）の基本的な使い方をまとめてみます。

cron は、「crond（デーモン）」と「crontab」 で構成されます。1分ごとに crond が起動され、crontab ファイルに定義されたスケジュールを調べて、そこに実行すべきジョブがあれば実行します。

スケジューリングの編集は、以下の2つの方法で行えます。

  • crontabコマンド を利用する
  • /etc/crontab に書き込む

今回は、Crontab に定義を書き込む形で設定していきます。

Crond が動いているか確認

まず、使用しているシステムで、Cronデーモンが動作している必要があります。

「systemctl status <デーモンの名前>」コマンドを使って確認します。

kkint@ubuntu:/etc$ systemctl status cron.service
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-10-06 12:01:47 JST; 3 days ago
Docs: man:cron(8)
Main PID: 985 (cron)
Tasks: 1 (limit: 4555)
Memory: 1.3M
CPU: 841ms
CGroup: /system.slice/cron.service
└─985 /usr/sbin/cron -f -P

Crond が動いていれば、上記のように「active（running）」の表示が出ます。

もし動いていない場合は、以下のコマンドで起動できます。

systemctl start cron.service

Crontab で設定

「/etc/crontab」ファイルに書き込む方法での設定手順です。まずは、Crontab ファイルを開いて見て見ましょう。

cat /etc/crontab

「cat」コマンドで、Crontab ファイルを指定して開いてみます。

kkint@ubuntu:/etc$ cat /etc/crontab

/etc/crontab: system-wide crontab

Unlike any other crontab you don't have to run the `crontab'

command to install the new version when you edit this file

and files in /etc/cron.d. These files also have username fields,

that none of the other crontabs do.

SHELL=/bin/sh

You can also override PATH, but by default, newer versions inherit it from the environment

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

Example of job definition:

.---------------- minute (0 - 59)

| .------------- hour (0 - 23)

| | .---------- day of month (1 - 31)

| | | .------- month (1 - 12) OR jan,feb,mar,apr …

| | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat

| | | | |

* * * * * user-name command to be executed

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
kkint@ubuntu:/etc$

下の方に、「＊」が 5つ並んでいる行が見えますね。ここに定義を記入していきます。

この「＊」印ですが、左から順に「分、時、日、月、曜日、実行ユーザー、 実行するコマンド」となっています。
時間は24時間で表記をします。

指定できる値は、下記のようになります。

指定対象指定範囲
分0〜59
時0〜23
日1〜31
月1〜12 または jan〜dec
曜日0〜7 または sun〜sat

「分　時　日　月　曜日 ユーザー　コマンド」の順に記入していきます。

< 記述例 >

1時に実行

  • * 1 * * * [ユーザー] [コマンド]

13時に実行

  • * 13 * * * [ユーザー] [コマンド]

5分おきに実行

*/5 * * * * [ユーザー] [コマンド]

1時、2時、5時、6時、7時、8時に実行

  • * 1,2,5-8 * * * [ユーザー] [コマンド]

もう少し例を見ていきましょう。

kkint というユーザー権限で実行し、kkint ユーザーのデスクトップに test.txt を作成する例です。

1分ごとに実行

* * * * * kkint touch /home/kkint/Desktop/test.txt

1:00 – 1:59 まで１分ごとに実行

* 1 * * * kkint touch /home/kkint/Desktop/test.txt

毎日14:00 に実行

0 14 * * * kkint touch /home/kkint/Desktop/test.txt

毎月10日から20日の 00:00 に実行

0 0 10-20 * * kkint touch /home/kkint/Desktop/test.txt

毎週月曜日から金曜日の 13:00 に実行

0 13 * * 1-5 kkint touch /home/kkint/Desktop/test.txt

Cron のログを出力する

デフォルトでは、Cron のログは出力されないようになっていますが、これを出力するようにすると、動作確認の際に便利です。

「/etc/rsyslog.d/50-default.conf」ファイルの設定を変更します。

kkint@ubuntu:/etc$ cat /etc/rsyslog.d/50-default.conf | grep cron

#cron.* /var/log/cron.log  <<<<< この部分

cron,daemon.none;\

まず、vim などのエディターを使って、上記ファイルを開きます。

$ vim /etc/rsyslog.d/50-default.conf

次に、対象の部分のコメントを外します。

#cron.* /var/log/cron.log
        |
        *
cron.* /var/log/cron.log  <<<<< コメントアウトする

最後に、rsyslogを再起動して、変更を適用します。

$ sudo service rsyslog restart

ログの確認例

2分おきに df コマンドを実行し、その結果をテキストファイルに書き込み、デスクトップに保存した時のログの出力は、以下の通りです。

Crontab ファイルには、以下のように記載しています。

*/2 * * * * kkint /usr/bin/df -h > /home/kkint/Desktop/df_results.txt

ログを見ると、指定したコマンドが実行されているのが分かりますね。

kkint@ubuntu:/etc$ cat /var/log/cron.log
Oct 9 13:45:01 ubuntu CRON[9087]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 13:55:01 ubuntu CRON[9164]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 14:01:01 ubuntu cron[985]: (system) RELOAD (/etc/crontab)

Oct 9 14:45:01 ubuntu CRON[10567]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Oct 9 14:46:01 ubuntu CRON[10575]: (kkint) CMD (/usr/bin/df -h >> /home/kkint/Desktop/df_results)
Oct 9 14:46:01 ubuntu CRON[10576]: (kkint) CMD (date >> /home/kkint/Desktop/df_results)

面白かったら、フォローしてください！

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2023年 Linux SNI (Server Name Indication) Windows クラウド コンピューター 証明書

Server Name Indication (SNI) とは


にほんブログ村

まず、ウェブサーバーなどで使われているバーチャルホストという技術が、どのようなものなのかを知っておく必要があります。

通常はWebサーバやメールサーバを運用するのにドメインの数以上のサーバコンピュータが必要となる。バーチャルホストを利用すると1つのサーバコンピュータで複数のドメインを運用することができ、サーバコンピュータの数を減らし運用のコストを下げることができる。また、後述する名前ベースバーチャルホストの場合はIPアドレスも節約することができる。 また、ドメインの追加も容易で、小規模Webサイトの運営や安価なレンタルサーバサービスなどでの利用が盛んである。

ウィキペディア

SSL/TLS では「同じサーバーは 1つの SSL サーバ証明書しか使えない」のが基本です。

ただ、このままだと不便な場合もあります。例えばレンタルサーバサービスをしているとしましょう。同じサーバを複数のユーザが利用し、更にユーザーごとに異なるドメインを利用するという使い方ができなければ、レンタルサーバーのサービスは成り立ちません。

このために出てきたのが、バーチャルホストです。

バーチャルホストの種類

今時のウェブサーバーでは、1台で複数の ウェブサービスを提供することが当たり前になっています。この技術をバーチャルホストと呼びます。

バーチャルホストには 2種類があります。

  • IP ベース
  • 名前ベース

IP アドレスが複数必要のない名前ベースのバーチャルホストの方が主流ですが、実際は、両方を混在させて使うケースもあります。

名前ベースのバーチャルホストの設定例

IP アドレスは同じで、複数のウェブサイト（ドメイン）を提供するのが特徴です。

# Ensure that Apache listens on port 80
Listen 80

# Listen for virtual host requests on all IP addresses
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot /www/kkint1
ServerName www.kkinternational.com

# Other directives here

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/kkint2
ServerName www.kkinternational.work

# Other directives here</VirtualHost>

IP ベースのバーチャルホストの設定例

ウェブサイト（ドメイン）毎に、異なる IP アドレスを使うのが特徴です。

Listen 80

<VirtualHost 172.30.30.100>
DocumentRoot /www/kkint1
ServerName www.kkinternational.com

</VirtualHost>

<VirtualHost 172.30.30.200>
DocumentRoot /www/kkint2
ServerName www.kkinternational.work

</VirtualHost>

なぜ SNI が必要なのか

このバーチャルホスト（特に名前ベースの方）が使われ始めたのが理由です。

名前ベースのバーチャルホストには、

  1. 同じ IP アドレスで、複数のウェブサービス（ドメイン）を提供する
  2. それらのウェブサービスは HTTPS を使っていて、サーバー証明書で暗号化されている（現在は HTTPS がほぼ必須）

という特徴があります。

上記 1の特徴から、バーチャルホストを使うウェブサーバーは、「家」よりも「アパートの建物」に似ていると言えます。アパートは、複数の部屋に分かれています。これらの部屋が、ウェブサービスでありドメインです。

次に上記 2の特徴です。この「HTTPS でサーバー証明書を使っている」というところがポイントです。基本的な SSL/TLS の仕様では、サーバー証明書は、同じ IP アドレスにつき 1ドメインしか運用できません。

上記1と2の特徴を考えると、複数のドメイン名をホストするため、IP アドレスだけでは、ユーザーが到達しようとしているドメインを示すのに十分ではありません。

なぜなら、間違った SSL 証明書を表示する可能性があり、HTTPS 接続ができなかったり、または終了されたりしてしまうというケースが発生する訳です。

じゃあ SNI があると？

Server Name Indication（SNI）は、この問題を解決するために作られました。

SNI は、HTTPS で使用される TLS プロトコルの拡張機能として提供されています。

TLS/SSL ハンドシェークに含まれていて、クライアント PC が、到達しようとしている ウェブサイトの正しい SSL 証明書を確認することができるようにします。

Server Name Indication（SNI、サーバー ネーム インディケーション、サーバ名表示）は、SSL/TLSの拡張仕様の一つである。SSLハンドシェイク時にクライアントがアクセスしたいホスト名を伝えることで、サーバ側がグローバルIPごとではなくホスト名によって異なる証明書を使い分けることを可能にする。

ウィキペディア

SNI を利用すると、クライアント PC は SSL/TLS ハンドシェイクの際に「これから通信したいサーバのドメイン名」をサーバに通知します。ウェブサーバーは「どのドメインに対応するサーバ証明書を利用すべきか」を、判断することができるようになります。

これにより、接続したいウェブサービスに必要なサーバー証明書が入手できるという訳です。

SNI をサポートしてないウェブブラウザー

SNI はクライアント側（ブラウザー）で、この機能をサポートしていないといけない訳ですが、古いブラウザーですと SNI をサポートしていません。

  • Windows XP 以前の全ブラウザ
  • IE 6 以前
  • いわゆる「ガラケー」のブラウザ

まあ、こんな古い環境でインターネットのブラウジングをしている人もいないと思いますが。

SNI をサポートしているブラウザーの一覧はこちら

SNI をサポートしているウェブサーバー

  • Apache 2.2.12 以降 + mod_ssl もしくは mod_gnutls
  • Apache Traffic Server（英語版） 3.2.0 以降
  • Cherokee（英語版） (コンパイル時 TLS サポートを有効にした場合)
  • lighttpd 1.4.24 以降(それ以前の1.4.xはパッチ)
  • Nginx と OpenSSL
  • F5 ネットワークス Local Traffic Manager 11.1 およびそれ以降
  • Hiawtha（英語版） 8.6 またはそれ以降
  • IBM HTTP Server 9.0 およびそれ以降
  • LiteSpeed 4.1 およびそれ以降
  • Pound 2.6 以降
  • Apache Tomcat (Java 7 およびそれ以降)
  • Microsoft IIS 8
  • PageKite tunneling reverse proxy
  • Citrix NetScaler 9.3 以降
  • Radware Alteon ADC (AlteonOS 28.1 以降)

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2023年 ガジェット コンピューター 認定資格 趣味

Video CC TranslatorでUdemyを快適に学ぶ


にほんブログ村

Udemy は IT技術を含め、さまざまな内容を学習できる便利なサイトです。私もIT技術を学ぶために活用してます。

私が使っているコンテンツのほとんどは、AWS か Azure の試験向けのものなのです。非常に人気のある基礎や初級向けのものですと日本語で提供されているものが多いのですが、中級以上の内容になると、英語やその他の言語でしか提供されていないものがほとんどです。

Udemy の動画には、翻訳して字幕をつける機能もあります。ですが、日本語の字幕がないものも結構あります。私が今受講しているコースもそれです。

英語で受講しても分かるのですが、やはり疲れます。そんな時に便利な機能を見つけました。

これです。

Video CC Translator

Udemy や YouTube を自動で翻訳してくれる Google Chromeの拡張機能です。使い方も簡単です。

Video CC translator の使い方

Video CC translator のページにアクセスし、Google Chrome に拡張機能を追加します。


今回は Udemy の翻訳のみをしたいので、Udemy のみを有効にします。

Udemy の画面を開いてコースを開始すると、動画のウィンドウの右下にVideo CC translator のアイコンが追加されているのが見えます。表示されない時は、ウィンドウをリフレッシュするか、Google Chrome を再起動した方が良いです。

Video CC Translator のアイコンをクリックして、メニューを表示させます。

CCが、Udemy 側のビデオで表示する言語です。私が今回受講しているコースの言語は英語で、字幕も英語で表示させています。

その下の白と黒のマークのところが、Video CC Translator で翻訳した結果として表示したい言語です。ここで日本語を選択します。

設定をするとすぐに、日本語の字幕が表示されます。見事に翻訳されました。

でも、これでは画面に字幕が被ってしまって、コース内容の動画が見にくいですよね。

一番下の「Caption Settings」をクリックします。

セッティングメニューを開いたら、一番上の「Display under video」を有効にします。

有効にすると、が動画ウィンドウの下に移動します。これで邪魔にならなくなりました。

この拡張機能は便利ですね。コースの内容を理解することに集中できます。今後も活用していこうと思います。

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2023年 Linux LPIC コマンド コンピューター 技術一般

LPIC を学ぶ（1） lsof コマンドについて


にほんブログ村

オープン中のファイルやプロセス、待ち受けポート番号などを、リストで表示するコマンドです。

lsof（エルエスオーエフ）コマンドは”list open files”の意味であり、多くのUnix系オペレーティングシステムで、オープン中のファイルやそのファイルをオープンしているプロセスのリストを出力するコマンドである。このオープンソースのユーティリティは、パデュー大学コンピューティングセンターの元アソシエートディレクター、ビクター・A・アベルによって開発・サポートされた。lsofはいくつかのUnix系OSで動作し、サポートされている。

https://ja.wikipedia.org/wiki/Lsof

lsofコマンドの書式

lsof [オプション]

「オプション」で、よく使うものは以下のものがあります。

　オプション　意味
-Pポート番号をサービス名に変換しない
-cプロセス名を指定する
-pプロセス ID を指定する
-n名前解決なしで IP アドレスで表示する
-uユーザー名を指定する
-iネットワークソケットを表示する
よく使うと思われるオプションのみ抜粋

lsof コマンドの出力には、以下の10個の項目があります。

　項目　意味
COMMAND表示されているコマンド
PIDプロセス ID
USER実行ユーザー名
FDファイルディスクリプター
TYPEタイプ
DEVICEデバイス
SIZE/OFFファイルサイズ
NODEプロトコル
NAMEファイル又はポート

コマンド出力例

それでは、「c」オプションの出力例を見ていきましょう。

「c」オプションでは、プロセス名を指定します。

まずは、ps コマンドでプロセス一覧を見てみましょう。

root@kelly ~]# ps aux | more
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.9 173312  7044 ?        Ss   01:42   0:02 /usr/lib/systemd/systemd rhgb --switched-root --system 
--deserialize 31
root           2  0.0  0.0      0     0 ?        S    01:42   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        I<   01:42   0:00 [rcu_gp]
root           4  0.0  0.0      0     0 ?        I<   01:42   0:00 [rcu_par_gp]
root           5  0.0  0.0      0     0 ?        I<   01:42   0:00 [netns]
root           7  0.0  0.0      0     0 ?        I<   01:42   0:00 [kworker/0:0H-events_highpri]
root           9  0.0  0.0      0     0 ?        I<   01:42   0:07 [kworker/0:1H-events_highpri]
root          10  0.0  0.0      0     0 ?        I<   01:42   0:00 [mm_percpu_wq]
root          12  0.0  0.0      0     0 ?        I    01:42   0:00 [rcu_tasks_kthre]
root          13  0.0  0.0      0     0 ?        I    01:42   0:00 [rcu_tasks_rude_]

この中で、今回は「rcu_gp」を指定してみます。

[root@kelly ~]# lsof -c rcu_gp
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.
COMMAND PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
rcu_gp    3 root  cwd       DIR  253,0      235  128 /
rcu_gp    3 root  rtd       DIR  253,0      235  128 /
rcu_gp    3 root  txt   unknown                      /proc/3/exe
[root@kelly ~]#

「rcu_gp」に関する表示が出ましたね。

次に「i」オプションを見てみましょう。

「i」オプションでは、ネットワークソケットを表示します。

[root@kelly ~]# lsof -i | more
COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
avahi-dae   772  avahi   12u  IPv4  22478      0t0  UDP *:mdns 
avahi-dae   772  avahi   13u  IPv6  22479      0t0  UDP *:mdns 
avahi-dae   772  avahi   14u  IPv4  22480      0t0  UDP *:38624 
avahi-dae   772  avahi   15u  IPv6  22481      0t0  UDP *:55406 
chronyd     798 chrony    5u  IPv4  22365      0t0  UDP localhost:323 
chronyd     798 chrony    6u  IPv6  22366      0t0  UDP localhost:323 
NetworkMa   949   root   28u  IPv4 122860      0t0  UDP kelly.kanan.com:bootpc->_gateway:bootps 
cupsd       956   root    6u  IPv6  23433      0t0  TCP localhost:ipp (LISTEN)
cupsd       956   root    7u  IPv4  23434      0t0  TCP localhost:ipp (LISTEN)
sshd        958   root    3u  IPv4  23448      0t0  TCP *:ssh (LISTEN)
sshd        958   root    4u  IPv6  23459      0t0  TCP *:ssh (LISTEN)
firefox   36564  kxxx   56u  IPv4 209042      0t0  TCP kelly.kk.com:49672->239.237.117.34.bc.googleusercontent.com:htt
ps (ESTABLISHED)
firefox   36564  kxxx  124u  IPv4 173714      0t0  TCP kelly.kk.com:35908->ec2-35-161-139-221.us-west-2.compute.amazon
aws.com:https (ESTABLISHED)
[root@kelly ~]#

通信しているもののみが表示されました。

「i」オプションでは、「i:<Port#>」とすることでポート番号を指定することもできます。例えば、HTTP（TCP/80）を指定する場合は、「i:80」と指定します。

以下は、HTTPS（TCP/443）を指定した例となります。

[root@kelly ~]# lsof -i:443 | more
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
firefox 36564 kxxx   56u  IPv4 209042      0t0  TCP kelly.kk.com:49672->239.237.117.34.bc.googleusercontent.com:https 
(ESTABLISHED)
firefox 36564 kxxx  124u  IPv4 173714      0t0  TCP kelly.kk.com:35908->ec2-35-161-139-221.us-west-2.compute.amazonaws
.com:https (ESTABLISHED)
[root@kelly ~]#

次に「u」オプションを見てみましょう。

「u」オプションでは、指定したユーザー名でフィルターして表示します。以下の例では、root ユーザーを指定しています。

[root@kelly ~]# lsof -u root | more
COMMAND     PID USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
systemd       1 root  cwd       DIR              253,0       235        128 /
systemd       1 root  rtd       DIR              253,0       235        128 /
systemd       1 root  txt       REG              253,0   1949240     496091 /usr/lib/systemd/systemd
systemd       1 root  mem       REG              253,0    582323     579363 /etc/selinux/targeted/contexts/files/file_cont
exts.bin
systemd       1 root  mem       REG              253,0     45408   33959961 /usr/lib64/libffi.so.8.1.0
systemd       1 root  mem       REG              253,0    153600   33883645 /usr/lib64/libgpg-error.so.0.32.0
systemd       1 root  mem       REG              253,0     28552   33978142 /usr/lib64/libattr.so.1.1.2501
systemd       1 root  mem       REG              253,0    102568   33871561 /usr/lib64/libz.so.1.2.11
systemd       1 root  mem       REG              253,0     32528   33959999 /usr/lib64/libcap-ng.so.0.0.0
systemd       1 root  mem       REG              253,0     41056   34639057 /usr/lib64/libeconf.so.0.4.1

以下、省略

今度は、kxxx ユーザーを指定してみます。USER の項目が kxxx のもののみが一覧表示されました。

[root@kelly ~]# lsof -u kanta | more
COMMAND     PID  USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
systemd    1828 kxxx  cwd       DIR              253,0       235        128 /
systemd    1828 kxxx  rtd       DIR              253,0       235        128 /
systemd    1828 kxxx  txt       REG              253,0   1949240     496091 /usr/lib/systemd/systemd
systemd    1828 kxxx  mem       REG              253,0    582323     579363 /etc/selinux/targeted/contexts/files/file_con
texts.bin
systemd    1828 kxxx  mem       REG              253,0     45408   33959961 /usr/lib64/libffi.so.8.1.0
systemd    1828 kxxx  mem       REG              253,0    153600   33883645 /usr/lib64/libgpg-error.so.0.32.0
systemd    1828 kxxx  mem       REG              253,0     28552   33978142 /usr/lib64/libattr.so.1.1.2501
systemd    1828 kxxx  mem       REG              253,0    102568   33871561 /usr/lib64/libz.so.1.2.11
systemd    1828 kxxx  mem       REG              253,0     32528   33959999 /usr/lib64/libcap-ng.so.0.0.0
systemd    1828 kxxx  mem       REG              253,0     41056   34639057 /usr/lib64/libeconf.so.0.4.1

以下、省略

この教材を使って学んでます。

posted with カエレバ

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2023年 Active Directory Azure Microsoft MS Azure Administrator MS Azure Fundamentals クラウド コンピューター 認定資格

MS Azure を学ぶ（2）Azure Active Directory とオンプレ Active Directory の違い

Azure Administrator (AZ-104）に合格しましたので、覚えた内容を忘れないように、これから少しずつアウトプットしていきたいと思います。

私が勉強に使った教材は、こちらでブログで紹介しています。


にほんブログ村

Active Directory（AD） とは

  • AD とは一般的に、Active Directory Domain Service (AD DS) サーバーを指す
  • AD DS とは、認証と認可を行うサーバー
  • ディレクトリーサービスを提供

認証：

  • 「本人確認」のプロセス。
  • コンピューターの世界では、ユーザー名とパスワードを使って本人確認を行う。認証を通じて、「なりすまし」を防止する。

認可：

  • 「その IDが、サービスやアプリケーションにアクセス可能であるか」を確認するプロセス。
  • 認証された IDで、利用できるサービスやアプリケーションの範囲が決定する。

以下、分かりやすく表記するために、オンプレ Active Directoryを AD DS、Azure Active Directory を Azure AD とします。

AD DS と Azure AD の違い

1. 使用範囲の違い

  • AD DS（オンプレ Active Directory）は、オンプレミス向けの認証と認可を提供
  • Azure AD は、クラウド向けの認証と認可を提供

まず、AD DS とAzure Active Directory は、使用の範囲が異なります。

AD DS は、企業の中で、その企業のリソースを管理したり、認証と認可のために使われます。一方で、Azure AD は、クラウド向けの認証と認可とリソース管理のために使われます。

オンプレミス Active Directory
  • 自社データーセンターに AD DS を設置（オンプレミス）
  • 大規模拠点にも AD DS を設置するケースもあり
  • 自社のサーバー（アプリ）へのアクセス制御
Azure Active Directory
  • Azure の自社のテナント上で AD DS を使用（クラウド）
  • Azure の自社のテナント上のサーバー（アプリ）へのアクセス制御
  • Microsoft 365 などの SaaS アプリへのアクセス制御

2. 使用されるプロトコルの違い

  • AD DS は、社内ネットワークで使用され、Kerberos や NTLM を使用
  • Azure AD は、インターネット環境で使用され、SAML、WS–Federation、OpenID Connect、OAuth などのプロトコルを使用

AD DS とAzure AD では、認証と認可でしようされるプロトコルが異なります。

AD DS は、組織内で使われることを前提としており、古くはNTLM、今の主流ですと、Kerberos を使って、認証と認可を行います。

一方で、Aure AD はクラウドを前提としており、SAML、WS-Federation、OpenID Connect、OAuth などといったプロトコルを使って、認証と認可を行います。

オンプレミス Active Directory
  • オンプレ AD DSでディレクトリーサービスを提供
  • Kerberos （古いと LDAP）を使って認証
Azure Active Directory
  • ブラウザーでのアクセスを対象
  • SaaS アプリにアクセスし、Azure AD で認証
  • Azure AD の許可で、SaaS アプリへのアクセス許可を得る

3. 組織構成の違い

  • AD DS は、組織を1つのフォレストとし、その中でドメインを構成し、必要に応じてドメイン同士で信頼関係を結ぶ
  • Azure AD は、Microsoft が提供するAD DS 上で、組織にテナントが割り当てられる

AD DS ではフォーレストという空間を組織毎にドメインで小分けして管理します。それぞれのドメインは、アクセスが必要であれば信頼関係を結びます。

一方で、Azure AD にはドメインという考え方はなく、代わりにテナントいう考え方になります。1つの組織は1つのテナントとして認識されます。信頼関係という考え方もありません。

オンプレミス Active Directory
  • 1つの組織で1つのフォレストを構成
  • フォレストの中にドメインを作成
  • 必要に応じて子ドメインも作成
  • 信頼関係を結ぶことでアクセスの許可
Azure Active Directory
  • Azure AD はマルチテナントで動作
  • 組織は、Azure AD 上で「テナント」として管理
  • 必要に応じて複数のテナントを作成することも可能
  • 信頼関係という考え方はない（それぞれが独立したテナント）

Azure AD は、クラウドベースの ID を一元管理し、アプリケーションへのアクセス要求に対して認証と認可を行います。

また、クラウドサービスとして提供されるものなので、当然ながらドメインコントローラーのようなサーバーの展開はありませんし、ドメインコントローラーのメンテナンスも必要なくなります。

合格対策Microsoft認定試験AZ-104:Microsoft Azure Administratorテキスト&演習問題

posted with カエレバ

（模擬試験付き）徹底攻略 Microsoft Azure Administrator 教科書 [AZ-104] 対応

posted with カエレバ

関連するブログ：

最近の人気ブログ TOP 10：

最近の記事：

カテゴリー
2022年 Azure Microsoft MS Azure Administrator MS Azure Fundamentals クラウド コンピューター 技術一般 管理 認定資格

MS Azure を学ぶ (1) リソースグループの作成と管理

Azure Administrator (AZ-104）に合格しましたので、覚えた内容を忘れないように、これから少しずつアウトプットしていきたいと思います。


にほんブログ村

リソースグループとは

リソースグループとは、Azure上のストレージや仮想マシンなどといったリソースを入れる箱のようなものです。各リソースをまとめて管理できます。

Learn Microsoft の画面

AWSなどでも同じような機能はありますが、必須になってはいませんが、Azureでは、各リソースは必ずどれかのリソースグループに所属する必要があり、必須となっています。

このリソースグループは便利な機能で、例えば各リソースにタグを付けたい場合、リソースグループにタグをつければ、そのリソースグループ内のリソースにも同じタグを付けられますし、リソースグループを削除すれば、そ子に所属している全てのリソースも一斉に削除することもできます。

リソースグループの作成

まず、リソースグループを作成してみましょう。

管理画面トップのテキストボックスに「リソースグループ」と入力して検索します。

メニューに「リソースグループ」が見えました。これをクリックします。

リソースグループの管理画面が開きます。

「作成」をクリックして、リソースグループを新規作成します。

リソースグループの作成画面が開きます。

設定する項目は、以下の3つがあります。

  • サブスクリプション：自分のサブスクリプションを選択
  • リソースグループ：今回作成するリソースグループの名前を入力
  • リージョン：リソースグループを配置するリージョンを選択

サブスクリプションは、課金が発生した際に支払いを行うサブスクリプションを選択します。

リソースグループの名前の注意点ですが、同じ名前のリソースグループは作成できません。以下のようにエラーになります。

リージョンですが、リソースグループに関しては意味はないです。実際にリソースグループの中に入れる各リソースの方は、必ずしもリソースグループと同じリージョンである必要はありません。このリージョンの項目は、単に管理目的となります。

各項目の選択と入力が完了したら、「作成」をクリックします。

リソースグループの一覧に、先ほど作成したリソースグループの名前が表示されましたね。これでリソースグループの作成は完了です。

リソースグループの削除

不要になったリソースグループは削除ができます。

削除したいリソースグループ名をクリックします。

対象リソースグループの管理画面が開きます。

「リソースグループの削除」をクリックします。

削除対象のリソースグループ名を、ここで再度入力します。

削除しようとしているリソースグループが本当に正しいのかを確認するためです。

正しければ、「削除」をクリックします。

リソースグループの一覧から、削除したリソースグループ名が見なくなりました。削除完了です。

このリソースグループの削除で非常に重要なのは、リソースグループを削除すると、そのリソースグループに属している各リソース全てが削除されるという点です。これは非常に便利である反面、非常に危険でもあります。運用稼働中のリソースであっても簡単に削除できてしまうのです。それを回避する機能がロックです。

リソースグループのロック

繰り返しになりますが、リソースグループは、使用する各リソースが入る箱のようなものというお話をしました。リソースグループに所属している各リソースですが、リソースグループを削除すると、その中の全ても削除されてしまいます。

せっかく苦労して作成したシステムも、簡単に削除されてしまいます。

これを避けるために、ロック機能が用意されています。

使用できるロックは2種類となります。

  • 読み取り専用ロック：削除も変更もできなくなります。
  • 削除ロック：削除のみをできなくし、変更は許可します。

まとめると、以下のようになります。

ロックの種類変更削除
読み取り専用ロック　　X　　　　X　　
削除ロック　　○　　　X 　

では実際に、ロック機能を適用してみましょう。

先ほど作成したリソースグループ名をクリックします。

対象リソースグループの管理画面が開きます。

メニューの中から「ロック」をクリックします。

ロックの管理画面が開きます。

「追加」をクリックします。

ロックの種類のプルダウンメニューを開くと、「読み取り専用」と「削除」の2つがあるのが見えますね。

今回は、「削除」ロックを設定してみます。

ロック名は必須です。今回は「delet-lock」とします。

メモはオプションですが、このロックの内容ですとか目的などを入れておくと、後からの管理で便利になります。

「OK」をクリックして、削除ロックを適用します。

作成した削除ロックが適用されたのが分かりますね。

今回適用したのは削除ロックです。リソースグループの削除ができなくなります。それでは試してみましょう。

対象となるリソースグループの名前をクリックし、「リソースグループの削除」をクリックしてみます。

削除対象となるリソースグループの名前を入力し、「削除」をクリックしてみます。

「削除に失敗しました」のメッセージが表示されましたね。削除できなくなっています。

では今度は、削除ロックを解除してみましょう。

対象となるロック名の「削除」をクリックします。

削除が完了し、ロック名が消えました。

それでは、再度、リソースグループを削除してみましょう。

対象となるリソースグループ名をクリックし、「リソースグループの削除」をクリックします。

削除対象となるリソースグループ名を入力し、「削除」をクリックします。

リソースグループの削除が始まりました。

「削除しました」のメッセージが表示されました。

リソースグループの一覧を表示してみましょう。先ほど削除処理したリソースグループ名は見えなくなりました。削除されていますね。

関連する記事：

最近の人気ブログ TOP 10：

最近の記事：