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

Linux で iSCSI イニシエーター設定 (Ubuntu 編)

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

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 の基本的な使い方

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

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

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

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分ごとに実行

* 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) とは

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

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

通常は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年 Linux LPIC コマンド コンピューター 技術一般

LPIC を学ぶ(1) lsof コマンドについて

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

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

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)に合格しましたので、覚えた内容を忘れないように、これから少しずつアウトプットしていきたいと思います。

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

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

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)に合格しましたので、覚えた内容を忘れないように、これから少しずつアウトプットしていきたいと思います。

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

リソースグループとは

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

Learn Microsoft の画面

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

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

リソースグループの作成

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

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

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

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

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

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

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

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

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

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

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

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

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

リソースグループの削除

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連する記事:

最近の人気ブログ TOP 10:

最近の記事:

カテゴリー
2022年 Apple ガジェット コンピューター バックアップ 自動化

MacOS の Time Machine がうざいので設定を変えたい

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

MacOS に標準で搭載されているバックアップアプリに、「Time Machine」があります。

標準で付いてくるアプリなのですが、必要最小限の機能はちゃんと搭載されており、非常に便利なアプリです。バックアップは、ちゃんと取っておかないと、何かあった時に泣くのは自分ですからね。

でもこのアプリ、やり過ぎなんです。1時間に一度バックアップを走らせてます。昼間に仕事している時にでもバックアップが走ります。かといって、自動バックアップを止めて手動で行うと、これはこれで面倒です。

そして、自動バックアップのバックアップ間隔の変更とかができないです。

これが不便に感じて、設定変更できるツールってないのかなと思って探したら、ありました!「TimeMachineEditor」です。

ここからダウンロードできます。

TimeMachineEditor のインストール

ダウンロードしたPKGファイルを、ダブルクリックしてインストールします。

インストーラー画面が表示されますので、画面に従って進めていきます。「続け」るをクリックして進みます。

Macへのログインパスワードが求められたら、パスワードを入力します。「ソフトウェアをインストール」をクリックして進みます。

これでTimeMachineEditorのインストールは完了です。非常に簡単ですね。

TimeMachineEditor の起動と設定

早速、TimeMachineEditorを起動してみましょう。

アプリケーション一覧からTimeMachineEditorを探して、打プルクリックで起動します。

まず「Back up」のチェックボックスにチェックを入れます。

その隣のプルダウンメニューをクリックしてみると、「不使用時」「インターバル」「カレンダー」の3つが選択できることが分かります。

不使用時の設定

ここでは、Time Machine のバックアップを使用したくない時間を指定することができます。

  • Do not back up from
    • 指定した何時から何時までの間はバックアップを行わない
  • Don’t backup when an app prevents display sleep
    • アプリがディスプレーのスリープを妨げる場合、バックアップを行わない
  • Don’t backup when an app prevents system sleep
    • アプリがシステムのスリープを妨げる場合、バックアップを行わない
  • Don’t backup when not wired to the network
    • ネットワークにケーブル接続されていない場合、バックアップを行わない
  • Create local snapshots every hour
    • スナップショットを毎時、ローカルに作成する

私の場合ですと、朝の9時から夜中の12時まではパソコンを触ることが多いので、この時間を指定して、バックアップ処理が走らないようにしています。つまり、バックアップは、夜中の12時から朝の9時までの間に処理するということです。

インターバル

ここでは、バックアップの間隔を指定することができます。

具体的には、何時間ごと、何日ごと、何週間ごとと単位で指定ができ、「1」以上の整数を入力していきます。

私の場合は、1日に1回のバックアップを取得するように設定しています。

カレンダー

ここでは、カレンダーを使って、バックアップを処理する曜日をや時間を指定できます。

「+」を押していくことで、複数の設定を行うことができます。

ちなみに私の場合は、毎日バックアップは取得しておきたいので、この機能は使用していません。

最後に、「適用」を押して設定を完了させます。

設定の適用

「適用」ボタンを押すと、こんな画面が表示されます。

実は、これが非常に重要です。

肝心なところが英語でしか表示されていないので見逃しがちなのですが、

Please make sure to disable automatic backup in System Preference in order to turn off the system scheduler.

です。

つまり、標準搭載されているTime Machineの設定で、自動バックアップを停止する必要があるのです。

この画面の左側にある「Back Up Automatically」のことです。

私はこれを読んでおらず、この自動バックアップのチェックボックスにチェックを入れたままにしてましたので、TimeMachineEditor で指定した間隔でのバックアップが行われず悩んでました。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

最近の人気ブログ TOP 10:

関連する記事:

最近の記事:

カテゴリー
2022年 AWS AWS Solutions Architect - Associate クラウド コンピューター 技術一般 認定資格

AWSを学ぶ(25)VPCエンドポイントを理解しよう

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

例えば、S3 や DynamoDB などといったサービスは、インターネットから直接利用できる、VPC 外の AWS サービスとなります。

これらへのアクセスは、VPC 内の AWS リソースからインターネットゲートウェイを経由して通信します。つまり、通信がインターネットに一度出ます。

セキュリティーを考えると、インターネットには出したくないというケースもあるでしょう。そこで VPC エンドポイントです。

VPC エンドポイントとは

VPC エンドポイントは、セキュリティ上の制約でインターネットとの通信が制限されているプライベートサブネット内の AWS リソースから、インターネットゲートウェイを経由せずに、VPC 外の AWS サービスへアクセス可能にする機能です。

VPC エンドポイントの種類と特徴

VPC エンドポイントには 3種類があり、それぞれ利用できるAWS サービスが異なります。

1. ゲートウェイエンドポイント(ゲートウェイ型)

ゲートウェイエンドポイントは、Amazon S3 または DynamoDB のみ対応しています。

S3 や DynamoDB へ接続したいリソースが配置されている VPC に VPC エンドポイントを割り当て、ルートテーブルにターゲットが VPC エンドポイントのルーティングを設定します。

ゲートウェイエンドポイントを使って S3 や DynamoDB にアクセスする時のイメージ

DynamoDB はゲートウェイ型のみ利用できますが、S3 はゲートウェイ型と PrivateLink の両方で利用可能です。

ゲートウェイエンドポイントは料金なしで使用できます。

2. インターフェイスエンドポイントAWS PrivateLink(インターフェイス型))

インターフェイスエンドポイントは AWS PrivateLink を使用し、サービスを送信先とするトラフィックのためのポイントとして Elastic Network Interface (ENI) を使用します。

サービスへ接続したいリソースが配置されているサブネットにプライベートIPアドレスを持つENIを作成し、ENIとサービスをリンクさせます。

AWS PrivateLink を使って CloudWatch や S3 にアクセスする時のイメージ

数多くの AWS サービスに対応しています。

AWS PrivateLinkと統合できる AWS のサービス

プライベート IP アドレスを使用して、VPC 内、オンプレミス、または VPC ピアリングや AWS リージョン を使用する別の AWS Transit Gateway にある VPC から Amazon S3 にリクエストをルーティングすることにより、ゲートウェイエンドポイントの機能を拡張します。

時間単位の使用料金とデータ処理料金が課金されます。

ゲートウェイ型とインターフェース型の比較

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3

3. Gateway Load Balancer エンドポイント

ゲートウェイロードバランサーのエンドポイントは AWS PrivateLink を使用し、サービスを送信先とするトラフィックのためのポイントとして Elastic Network Interface (ENI) を使用します。

時間単位の使用料金とデータ処理料金が課金されます。

VPC エンドポイントポリシー

エンドポイントの作成時、または変更時にエンドポイントにアタッチする IAM リソースポリシーのことです。

注意点は、以下の通りです

  • エンドポイントの作成時にポリシーを適用しない場合、サービスへのフルアクセスを許可するデフォルトのポリシーが適用
  • サービスがエンドポイントポリシーをサポートしていない場合、エンドポイントはサービスへのフルアクセスを許可

エンドポイントポリシーは、IAM ユーザーポリシーやサービス固有のポリシー (S3 バケットポリシーなど) を上書き、または置き換えません。これは、エンドポイントから、指定されたサービスへのアクセスを制御するための別のポリシーであるためです。

また、1つのエンドポイントに複数のポリシーを関連付けることはできません。

ポリシーはいつでも変更可能です。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

最近の人気ブログ TOP 10:

関連する記事:

最近の記事:

カテゴリー
2022年 QNAP VMWare コンピューター ストレージ 技術一般

ESXi サーバーのデータストアとして QNAP を使う(iSCSI 編)

PVアクセスランキング にほんブログ村 にほんブログ村 ブログブログへ
にほんブログ村

自宅で使っている VMWare ESXi のローカルハードディスク上のデータストア領域が少なくなり、以前、NFS を使って QNAP のストレージ領域をマウントして使ってみました。

今度は、iSCSI でもマウントをやってみたいと思い試してみました。

私がやりたいのは、こんな感じです。

VMWare ESXi 側の準備

まず、ESXi サーバー側のファイヤーウォール機能で、iSCSI が通信許可されているかを確認します。

Networking > Firewall Rules > Software iSCSI Client

「Outgoing Ports」で使用するポートが通信許可されていれば OK です。

QNAP での iSCSI 設定

iSCSI & ファイバーチャネル」から設定を行います。

左側メニューの中から「iSCSI ストレージ」を選択します。

「作成」をクリックし、「新しい iSCSI ターゲット」を選択します。

iSCSI ターゲット作成ウィザードが表示されます。

「次へ」をクリックして進みます。

iSCSI ターゲットプロファイル」を設定していきます。

  • 名前: iSCSI ターゲットの名前
  • ターゲットエイリアス:上の名前の別名(同じでもよい)

IQN iSCSI でストレージを指定するときに使うアドレスです。「名前」の値が使われるので、使いやすい名前にしておきましょう。

「次へ」をクリックして進みます。

ESXi サーバーから iSCSI ストレージをマウントする際に、認証は必須となります。後からでも設定はできますが、ここで忘れずに設定しておきましょう。

  • CHAP 認証の使用: 有効化
  • ユーザー名: 認証で使用するユーザー名
  • パスワード: 認証で使用するパスワード

「次へ」をクリックして進みます。

設定した iSCSI 向けの内容を確認します。

「適用」をクリックして、設定を適用します。

ブロックベース LUN 作成ウィザード」が起動します。

「ストレージプール」のプルダウンメニューから、iSCSI で使用したいストレージプールを選択します。

この例では「ストレージプール1」を選択しています。

LUN とは、ストレージ上で iSCSI で使用するように設定した領域のことです。

「次へ」をクリックして進みます。

LUN で使用許可する領域のサイズを指定します。

「次へ」をクリックして進みます。

設定内容を確認し、問題なければ「完了」をクリックして、選定を終了します。

iSCSI ターゲットが作成されて表示されました。

ESXi から iSCSI の LUN をマウント

ESXi サーバーにログインします。

左側のメニューの中の「ストレージ」をクリックします。

アダプター」タブをクリックします。

ソフトウェア iSCSI」をクリックします。

「iSCSI の設定」ウィンドウが表示されますので、「有効化」を選択して、ESXi サーバーで iSCSI が使用できるようにします。

設定の詳細項目が表示されます。

  • CHAP Authentication(CHAP認証): CHAP を使用

Static Target(静的ターゲット)

  • Target(ターゲット): iSCSI ターゲットを入力
  • Address(アドレス): QNAP のIP アドレスを入力
  • Port(ポート番号): 3260(変更しているならその番号)

デバイス」タブをクリックします。

新規のデータストア」をクリックします。

データストアの作成ウィザードが起動します。

「名前」に、データストアの名前を入力します。QNAP の iSCSI 領域(LUN)と見て分かるようにしておいた方が、後から分かりやすく便利です。

「次へ」をクリックして進みます。

パーティション設定は、特に何も触りません。

「次へ」をクリックして進みます。

設定内容を確認し、問題なければ「完了」をクリックして、設定を保存します。

ワーニングメッセージが表示されますが、「はい」をクリックします。

設定内容の確認

「データストア」のタブをクリックします。

ESXi サーバー上で利用可能なデータストアの一覧が表示されます。

この中に、先ほど新規作成して追加した QNAP の iSCSI 領域(LUN)が表示されてますね。

左側メニューの中の「ストレージ」から、今回追加した QNAP の iSCSI 領域 (LUN) を選択します。

今回追加した iSCSI 領域 (LUN) が表示されます。

ESXi サーバーから利用可能なストレージサイズが、右上に表示されてますね。

次に VM を作成する際に、この領域を指定すれば、VM は QNAP の iSCSI 領域 (LUN) に保存されます。

左側メニューの「ストレージ」をクリックします。

「デバイス」タブをクリックします。

QNAP iSCSI Disk が見えてますね。

ステータスが Degraded なのですが、これは問題ないみたいです。

QNAP の「iSCSI & ファイバーチャネル」の設定も見てみます。

iSCSI ターゲットリストの中で、今回作成した iSCSI ターゲットを見ると、「接続済み」と表示されており、ESXi サーバーの IPアドレスも見えてます。

詳細を見てみると、ステータスは「接続済み」になっています。

これで設定完了です。

今回は iSCSI 方式を使ったのですが、 NFS 方式を試してみたい場合は、以下のリンクで設定手順を紹介しています。

おもしろかったら、フォローしてください!

世の中には楽しいことがいっぱい - にほんブログ村

関連する記事:

最近の記事:

カテゴリー
2022年 CCNP Enterprise Cisco DDNS VPN コマンド コンピューター トラブルシューティング ルーティング 技術一般 認定資格

Cisco ルーターでリモートアクセス VPN の設定

この設定で、リモートアクセスVPNが正常に張れることまでは確認できたのですが、なぜかルーターのLAN側にルーティングされなくて悩んでます。解決したら、また更新しようと思います。

aaa new-model
!
!
aaa authentication login userauth local
aaa authorization network groupauth local
!
username kkint password 7 kkint-pass
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp client configuration group VPNCLIENT
 key cisco
 dns 172.16.23.254
 domain kkinternational.com
 pool ezvpn1
 save-password
!
crypto isakmp profile vpnclient-profile
   match identity group VPNCLIENT
   client authentication list userauth
   isakmp authorization list groupauth
   client configuration address respond
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto dynamic-map dynmap 1
 set transform-set myset
 set isakmp-profile vpnclient-profile
 reverse-route
!
interface FastEthernet0
 description To the Internet
 ip address dhcp
 duplex auto
 speed auto
 crypto map ezvpnmap