cockpit は PAM(8) を使ってローカルユーザの認証を行っています。
PAM は access.conf(5) でユーザ/グループ/IP 制限がかけられるのでこれを利用することで cockpit にログインできるユーザを制限することができます。

PAM の設定

インストールすると /etc/pam.d/cockpit ができているので
適当なエディタで編集してpam_access.so の行を追加します.
accessfile=path/to/access.config はなくてもかまいません。指定しなければ /etc/security/access.conf が利用されます。

/etc/pam.d/cockpit

#%PAM-1.0
# this MUST be first in the "auth" stack as it sets PAM_USER
# user_unknown is definitive, so die instead of ignore to avoid subsequent modules mess up the error code
-auth      [success=done new_authtok_reqd=done user_unknown=die default=ignore]   pam_cockpit_cert.so
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
auth       optional     pam_ssh_add.so
account    required     pam_nologin.so
account    required     pam_access.so accessfile=/etc/security/cockpit_access.conf ★この行を追加
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    optional     pam_ssh_add.so
session    include      password-auth
session    include      postlogin

追加する箇所は account include password-auth より前にする必要があります。
この順序を逆にすると、account include password-auth で読み込まれている password-auth に　sufficient 行が含まれているため、そこで認証に成功しているとそのあとに書いた制限が評価されません。

access.conf の設定

accessfile に指定したパスに access.conf(5) の書式でファイルを用意します。
例えば、 cockpit グループを作ってそのグループに入っているユーザのみログインできるようにする場合は以下のようにします。

/etc/security/cockpit_access.conf

-:ALL EXCEPT (cockpit):LOCAL

書き方は <permission>:<user or group>:<access> で
- <permission> は '-' (許可) または- (拒否) のどちらか
- user または group 名、ALL は全ユーザまたは全グループにを表していて、 EXCEPT は続くユーザ・グループの除外を指定します
- group の時は () をつけたほうがいいらしい？
- ALL EXCEPT (cockpit) は cockpit に属するユーザを除く全ユーザが対象
- <from> はアクセス元
- cockpit の場合は LOCALのみ利用している（？）

確認

ログインしてみて Permission Denied が出れば成功

はじめに

LPIC 1 で習った内容だが，実践する機会に恵まれなかったLinux での外部ストレージのマウントの方法について，実際に実行してみたのでまとめてみた．

前提

• OSはRedHat Enterprise Linxu 7.6
• 追加のデバイスがOS に認識されている
• /data01 (マウント先)が作成されている

デバイスの確認

lsblk コマンドを実行し，デバイスを確認する．今回は，ディスク容量30 GB のsdb をマウントする．

実行コマンド

# lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0   20G  0 disk
tqsda1                8:1    0    1G  0 part /boot
mqsda2                8:2    0   19G  0 part
  tqrhel-root       253:0    0   17G  0 lvm  /
  mqrhel-swap       253:1    0    2G  0 lvm  [SWAP]
sdb                   8:16   0   30G  0 disk
sr0                  11:0    1  4.2G  0 rom

LVM ボリュームの作成

fdisk コマンドを実行し，LVM ボリュームを作成する．

実行コマンド

# fdisk /dev/sdb

パーティションの確認

パーティションの状況を確認する．

実行コマンド

# fdisk -l /dev/sdb
Disk /dev/sdb: 32.2 GB, 32212254720 bytes, 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

物理ボリュームの作成

pvcreate コマンドを実行し，物理ボリュームを作成する．

実行コマンド

# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created

物理ボリュームの確認

pvdisplay コマンドを実行し，作成結果を確認する．
※以下は，すでにボリュームグループが作成されている

実行コマンド

# pvdisplay
--- Physical volume ---
  PV Name               /dev/sdb
  VG Name               VG01
  PV Size               30.00 GiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              7679
  Free PE               255
  Allocated PE          7424
  PV UUID               tpt0pP-tsYc-phBj-FFsc-wksq-Zoka-8xD3Q4

ボリュームグループの作成

ボリュームグループを作成する．今回はVG01 という名前にする．

実行コマンド

# vgcreate VG01 /dev/sdb
Volume group "VG01" successfully created

ボリュームグループの確認

vgdisplay コマンドを実行する．

実行コマンド

# vgdisplay
--- Volume group ---
  VG Name               VG01
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <30.00 GiB
  PE Size               4.00 MiB
  Total PE              7679
  Alloc PE / Size       7424 / 29.00 GiB
  Free  PE / Size       255 / 1020.00 MiB
  VG UUID               ed3Iv8-pR0h-qxr1-6iaA-InIe-CKN4-8mvEa6

vgscan コマンドを実行する．

実行コマンド

# vgscan
Found volume group "VG01" using metadata type lvm2

論理グループの作成

lvcreate コマンドを実行し，論理グループを作成する．

実行コマンド

# lvcreate --name data --size 29GB VG01
Logical volume "data" created

論理グループの確認

lvdisplay コマンドを実行し，作成結果を確認する．

実行コマンド

# lvdisplay
--- Logical volume ---
  LV Path                /dev/VG01/data
  LV Name                data
  VG Name                VG01
  LV UUID                FF3Hzc-sI0v-NO8b-Kryt-cHiv-NUy5-galnkF
  LV Write Access        read/write
  LV Creation host, time localhost.localdomain, 2020-02-13 09:49:20 +0900
  LV Status              available
  # open                 1
  LV Size                29.00 GiB
  Current LE             7424
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:2

ファイルシステムの作成

以下のコマンドを実行し，ファイルシステムを作成する．

実行コマンド

# mkfs.xfs /dev/VolGroup01/data01
meta-data=/dev/VG01/data isize=512    agcount=4, agsize=1900544 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=7602176, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=3712, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

マウントの実行

/etc/fstab の末尾に追記をして，マウントを実行する．

/etc/fstab

/dev/mapper/VG01-data  /data  xfs  defaults  0  0

設定を反映する．

実行コマンド

# mount -a

エラーメッセージが出力されなければ，OK．

ディスクサイズの確認

最後に，ディスクサイズを確認する．

実行コマンド

# df -h
/dev/mapper/VG01-data  29G   33M   29G   1%  /data

ちゃんとマウントされていて，ディスクサイズも確認できる．

はじめに

VMware-Tools をインストール方法で，いつもと違う方法をとる必要があったため，その方法を備忘録としてメモする．

前提

• OSはRedHat Enterprise Linux 7.6
• VMware-Tools はVMware 公式サイトよりダウンロード
• 対象ソフトウェアは，VMware-Tools-10.1.0-core-4449150.tar.gz

ファイルのダウンロード

VMware 公式サイト (https://my.vmware.com/web/vmware/details?downloadGroup=VMTOOLS1010&productId=614) より
VMware-Tools-10.1.0-core-4449150.tar.gz をダウンロードする．

ダウンロードしたファイルのアップロード

TeraTerm やscp 等を用いて，/tmp にファイルをアップロードする．

実行コマンド

scp VMware-Tools-10.1.0-core-4449150.tar.gz [ユーザ名]@[IPアドレス]:/tmp

ls コマンドで，実行結果を確認する．

確認結果

ls /tmp
VMware-Tools-10.1.0-core-4449150.tar.gz

ファイルを解凍する

アップロードしたファイルを解凍する

実行コマンド

cd /tmp
tar zxvf VMware-Tools-10.1.0-core-4449150.tar.gz

ls コマンドで，実行結果を確認する．vmtools ディレクトリが作成される．

確認結果

ls /tmp
vmtools

iso をマウントする

作成されたディレクトリの中にある linux.iso をマウントする．

実行コマンド

mount /tmp/vmtools/linux.iso /mnt

ファイルを解凍する

linux.iso の中にあるVMwareTools-10.1.0-4449150.tar.gz を解凍する．このファイルを既に持っていれば，上記の手順は不要であり，適当なディレクトリで本ファイルを解凍すればよい．

実行コマンド

mkdir /tmp/work
cp /mnt/VMwareTools-10.1.0-4449150.tar.gz /tmp/work
cd /tmp/work
tar zxvf VMwareTools-10.1.0-4449150.tar.gz

ls コマンドで，実行結果を確認する．vmware-tools-distrib ディレクトリが作成される．

確認結果

ls /tmp/work
vmware-tools-distrib/

インストーラを実行する

ようやく見慣れた光景にまできた．
インストーラのperl スクリプトを実行する．

実行コマンド

cd /tmp/work/vmware-tools-distrib/
./vmware-install.pl

この時点で，以下のようなエラーメッセージが出力された場合，perl がインストールされていないので，perl をインストールする．

エラーメッセージ

-bash: ./vmware-install.pl: /usr/bin/perl: 誤ったインタプリタです: そのようなファイルやディレクトリはありません

perl をインストールする．

perlのインストール

yum install perl 

再度インストーラを実行する．

実行コマンド

./vmware-install.pl

設定をウィザード形式で尋ねられるが，お好みの設定にしてください．最後に，Enjoy というメッセージが出てくれば，インストール完了です．

個人開発でWebサービスを運営しています。
長らく月額500円のレンタルサーバーでなんとかやっていましたが、下記の理由でサーバーを移行することを考えました。

・ミドルウェアなど自由にインストールできない
・スケールアップできない
・アクセスログがリアルタイムで見れない
・TLS1.0/1.1の廃止スケジュールなどレンタルサーバー側で決められる
・DKIMを設定してメールの到達率を上げたい

AWSも触ってみましたが、業務でBigQueryに慣れ親しんでいたので、Google Cloud Platformを使うことにしました。

普段はWebアプリケーションの開発がメインなので、インフラは軽く触る程度ですが勉強がてら構築してみます。

構成

ロードバランサ （Cloud Load Balancing) 1台
本番Web・DBサーバー (Compute Engine、CentOS) 1台
メンテ用Webサーバー (Compute Engine、CentOS) 1台

ロードバランサの後ろに本番Web・DBサーバーと、メンテ用Webサーバーのインスタンスをおきます。

ロードバランサを使う理由

あまり大きくないサイトでもロードバランサを使う理由を書きます。

グローバルIP1つで運用できる

レンタルサーバーから移行するときのDNS設定は、AレコードをロードバランサのIPに変更するだけ済みます。

IP直などの不正なリクエストを除外したい

サーバーを公開すれば、直IPなどで不正なリクエストが来るようになります。.gitディレクトリへのアクセス、脆弱性ファイルのスキャンなど、そのようなアクセスは本番Webサーバーにリクエストが来ないようにします。

Webサーバーの複数台構成などスケールできる

DBはCloud SQLなどを使って独立させて、本番Webサーバーを複数台構成にするなどスケールアップが可能です。

ロードバランサにSSL証明書を設定できる

ロードバランサがSSL終端となり、ロードバランサから後ろのWebサーバーはHTTPのアクセスとなります。WebサーバーでSSLを復号化するより負荷は少ないかと思っています。また、Webサーバーを複数台にしたときに証明書をロードバランサに集中することができます。

ロードバランサの振り分けのみでメンテ中にできる

例えば本番Webサーバーのインスタンスを停止させて性能を上げたいときに、ロードバランサの振り分けをメンテ用サーバーに向ければ簡単にメンテ中にできます。

メールサーバー

メールの送信はWebAPIで使える外部のサービスを使うことにしました。

運用について

SSL証明書の更新

SSL証明書はLet's Encryptを使っています。Webサーバーでcertbot certonlyコマンドで作成したものを、ロードバランサの設定画面に貼り付けます。3ヶ月に一度やる必要があるのでちょっと面倒です。

スナップショット

定期的にインスタンスのスナップショットを取ります。スナップショットはインスタンスの稼働中でも可能です。もしもの時にスナップショットから新しくインスタンスを作成することができます。

まとめ

全部お守りしてくれるレンタルサーバーと違って、費用もやることも増えましたが開発の自由度が上がって提供できるサービスレベルも格段に上がりました。

色々と触ってみながら、徐々に最適な運用方法を見つけていきたいと思っています。

Virual boxでubuntu立ててdocker使ってたらubuntu(というか仮想マシン)自体のディスクが足りなくなった。
拡張めんどい。あとでまたやるときのために記録残しとく
LVMではなく物理パーティション向け

仮想マシン > 設定 > ストレージ > コントローラー: SATAのHDDの+アイコンを押して、新規ディスクの作成
VDIを選択(元々他のファイルタイプ選んでればそれを選択) > 固定サイズ(可変サイズでもいい) > パスとサイズを入力して作成 > 処理終わったらVM起動！

fdisk -lで新ディスクのブロックボリューム名確認

ディスク /dev/sdb: 20 GiB, 21474836480 バイト, 41943040 セクタ
Disk model: VBOX HARDDISK
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

cat /etc/fstabで現在のファイルシステムを確認
※UUID=345dde19-65a3-4580-bbd6-3cbb16f964a3 / ext4の、ext4がほしい情報

root@user-VirtualBox:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=345dde19-65a3-4580-bbd6-3cbb16f964a3 /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0

root@user-VirtualBox:~# parted /dev/sdb
GNU Parted 3.2
/dev/sdb を使用
GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。
(parted) mklabel gpt
(parted) mkpart
パーティションの名前?  []? newdisk
ファイルシステムの種類?  [ext2]? ext4
開始? 0%
終了? 100%
(parted) p
モデル: ATA VBOX HARDDISK (scsi)
ディスク /dev/sdb: 21.5GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前     フラグ
 1    1049kB  21.5GB  21.5GB  ext4              newdisk

(parted)

root@user-VirtualBox:~# mkfs.ext4 /dev/sdb1
mke2fs 1.44.6 (5-Mar-2019)
Creating filesystem with 5242368 4k blocks and 1310720 inodes
Filesystem UUID: 8985105d-d482-41f6-85f7-82afeba1172b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

いっぱい容量食ってるdockerイメージの置き場は/var/lib/dockerのようなので、
もともとの/var/lib/dockerを一時的にリネームして、新規にdockerディレクトリをつくって、新規パーティションをそこにマウント。dfで確認。で、そっちに元々のデータもうつす。わすれずにfstab書く

root@user-VirtualBox:/var/lib# mv docker _docker
root@user-VirtualBox:/var/lib# mkdir docker
root@user-VirtualBox:/var/lib# mount /dev/sdb1  /var/lib/docker
root@user-VirtualBox:/var/lib# df -h
/dev/sdb1        20G   45M   19G   1% /var/lib/docker
root@user-VirtualBox:~# vi /etc/fstab
/dev/sdb1                                 /var/lib/docker ext4    default         0       0

OS再起動してマウントされてて、dockerも普通に起動すればOK！

Virual boxでubuntu立ててdocker使ってたらubuntu(というか仮想マシン)自体のディスクが足りなくなった。
拡張めんどい。あとでまたやるときのために記録残しとく
LVMではなく物理パーティション向け

仮想マシン > 設定 > ストレージ > コントローラー: SATAのHDDの+アイコンを押して、新規ディスクの作成
VDIを選択(元々他のファイルタイプ選んでればそれを選択) > 固定サイズ(可変サイズでもいい) > パスとサイズを入力して作成 > 処理終わったらVM起動！

fdisk -lで新ディスクのブロックボリューム名確認

ディスク /dev/sdb: 20 GiB, 21474836480 バイト, 41943040 セクタ
Disk model: VBOX HARDDISK
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

cat /etc/fstabで現在のファイルシステムを確認
※UUID=345dde19-65a3-4580-bbd6-3cbb16f964a3 / ext4の、ext4がほしい情報

root@user-VirtualBox:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=345dde19-65a3-4580-bbd6-3cbb16f964a3 /               ext4    errors=remount-ro 0       1
/swapfile                                 none            swap    sw              0       0

root@user-VirtualBox:~# parted /dev/sdb
GNU Parted 3.2
/dev/sdb を使用
GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。
(parted) mklabel gpt
(parted) mkpart
パーティションの名前?  []? newdisk
ファイルシステムの種類?  [ext2]? ext4
開始? 0%
終了? 100%
(parted) p
モデル: ATA VBOX HARDDISK (scsi)
ディスク /dev/sdb: 21.5GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前     フラグ
 1    1049kB  21.5GB  21.5GB  ext4              newdisk

(parted)

root@user-VirtualBox:~# mkfs.ext4 /dev/sdb1
mke2fs 1.44.6 (5-Mar-2019)
Creating filesystem with 5242368 4k blocks and 1310720 inodes
Filesystem UUID: 8985105d-d482-41f6-85f7-82afeba1172b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

いっぱい容量食ってるdockerイメージの置き場は/var/lib/dockerのようなので、
もともとの/var/lib/dockerを一時的にリネームして、新規にdockerディレクトリをつくって、新規パーティションをそこにマウント。dfで確認。で、そっちに元々のデータもうつす。わすれずにfstab書く

root@user-VirtualBox:/var/lib# mv docker _docker
root@user-VirtualBox:/var/lib# mkdir docker
root@user-VirtualBox:/var/lib# mount /dev/sdb1  /var/lib/docker
root@user-VirtualBox:/var/lib# df -h
/dev/sdb1        20G   45M   19G   1% /var/lib/docker
root@user-VirtualBox:~# vi /etc/fstab
/dev/sdb1                                 /var/lib/docker ext4    defaults        0       0

OS再起動してマウントされてて、dockerも普通に起動すればOK！

忙しい方へ

インストール先はrootユーザのディレクトリなので、そうじゃないディレクトリに置いてパスを通すことができるよ、というだけです。
これで何をやってるかわかるのであれば以後は読まなくていいかもｗ

本題

今週、AWS CLIのV2がGAになりました。
AWSのブログ
クラスメソッドさんのブログ

個人的にはまだ全然試せてないのでこれからなんですが、使うにはまずはインストールしなければいけないですよね。
インストールの方法は公式に載っています。
自分の環境は仕事でも個人でもMacなのですが、もともとcliはbrewでインストールしてました。
何かしらのパッケージマネージャによって管理される状態にしておきたかったからですね。

なのでできたらbrewで行きたかったんですが、これを書いている時点ではまだbrewではインストールできません。
（なので、brewでインストールできるようになったらこの内容は不要かもしれません。）

インストールの手順を抜粋すると下記です。
Macでのインストール手順ですが、対象のファイルが変わるだけでLinuxでの手順もほぼ同様です。

Macでのインストール手順

curl "https://d1vvhvl2y92vvt.cloudfront.net/awscli-exe-macos.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

問題なのはsudo ./aws/installで、仕事用のPCのユーザでは管理者権限を制限されていてsudoできない、なんてことがあるかと思います。
そうしたらせっかく試そうと思ったのに試せないじゃん、となっちゃいますが、回避する方法がきちんとドキュメントに書いてあるのでここに残しておきます。

インストールスクリプトの中身

./aws/installの中身は全部抜粋すると長くなるので割愛しますが、ざっくりいうと/usr/local/aws-cliというディレクトリを作ってその中に動作させるプログラムを配置し、/usr/local/bin/aws2というシンボリックリンクを作成する、という動作をするようです。
sudoさせられるのは、通常/usr以下に書き込むにはroot権限が必要な状態になっているからかと思います。
/usr/loca/binにシンボリックリンクを置くのはPATHが通っているディレクトリにシンボリックリンクを置いてどこからでも使えるようにするためでしょう。
（記憶が曖昧なんですが、そもそもデフォルトでPATH通ってましたっけ…？）

※そもそもこのディレクトリなんなのみたいな話は話が逸れるので参考サイトを置いておきます
https://linuc.org/study/knowledge/544/

ただ、インストール先のディレクトリとシンボリックリンクを置くディレクトリは変更することができる、と書いてあります。

以下ドキュメントから抜粋

--install-dir または -i

このオプションは、すべてのファイルをコピーするフォルダを指定します。次の例では、/usr/local/aws-cli という名前のフォルダにファイルをインストールします。このフォルダを作成するには、/usr/local への書き込み権限が必要です。

デフォルト値は /usr/local/aws-cli です。

--bin-dir または -b

このオプションは、インストールフォルダ内のメイン aws プログラムが、指定されたパス内のファイル aws2 にシンボリックリンクされるように指定します。この例では、シンボリックリンク /usr/local/bin/aws2 を作成します。指定したフォルダへの書き込み権限が必要です。パスにすでに存在するフォルダへのシンボリックリンクを作成すると、インストールディレクトリをユーザーの $PATH 変数に追加する必要がなくなります。

デフォルト値は /usr/local/bin です。

つまり、適当なディレクトリにファイルを置いて、自分でPATHを通した任意のディレクトリにシンボリックリンクを配置することでsudoを使わないでインストールすることができます。

インストール先ディレクトリを変える

自分の場合は使っているユーザのホームディレクトリ配下に下記のようなディレクトリを作りました。

ディレクトリを作成し、PATHを通す

mkdir $HOME/awscli2
mkdir $HOME/local/bin

もちろん$HOME/local/binにはPATHを通してあります。

Bashの場合は~/.bash_profileに

.bash_profile

export PATH=$PATH:$HOME/local/bin

を追記して.bash_profileを読み込み直しましょう。
source ~/.bash_profileを実行するか、ターミナルを立ち上げ直せばOKです。

自分はfishを使っているのでユニバーサル変数に追加しています。
fishの環境変数の設定の仕方はbashとはちょっと違ってやや混乱するので注意。
.fish/config/config.fishに環境変数を設定するコマンドを追記するのでもいいと思います（お好みで）
ただ、下記は永続的な設定なので.fish/config/config.fishのではなくターミナルで一回実行するだけにしましょう。
$fish_user_pathsの中身が間違って空になったりすると後で面倒なことになります（1敗）
参考
https://qiita.com/ledsun/items/8ca1a450b21c8ebc9670

fish

set -U fish_user_paths $HOME/local/bin $fish_user_paths

オプション指定してインストールする

その上で、インストール時にこんな感じでオプション指定しました。
※環境変数でホームディレクトリ指定してますが、実際にはフルパス指定しています。

./aws/install -i $HOME/awscli2/ -b ＄HOME/local/bin/

これで実行できるようになります、なお、現在はv1との併用のためaws2という名前でシンボリックリンクが作られます。

aws2 --version
aws-cli/2.0.0dev4 Python/3.7.4 Darwin/18.7.0 botocore/2.0.0dev3

ドキュメントより

AWS CLI バージョン 2 のプレビューリリースでは、AWS CLI バージョン 1 とバージョン 2 がサイドバイサイドで共存できるよう、シンボリックリンクに aws2 という名前が付けられます。AWS CLI バージョン 2 の今後のリリースでは、このコマンド名が変更される可能性があります。

ともあれ、これでV2になったaws cliを試すことができるようになりました。

気になるポイント

• あくまでも手動インストールなのでアップデートがあったら自分でやらなきゃいけないこと
• 一部下位互換性のない変更がある
  • https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cliv2-migration.html

関連

venvを使ってAWS CLI（v1）とAWS CLI v2を使い分ける（Mac, Linux編）
AWS CLI v2をソースコードからインストールする

VIMは主にLINUX環境下で使われるテキストエディタです。
非常に癖があって、未経験の人にとっては異世界の産物のように見えますが、ある程度使って行けば自転車の乗り方を覚えるようにスムーズに操作できるようになります。

VIMのいいところは

・読み書きが非常に速い（通常、膨大な量のJSONなどを読み書きすると処理落ちする）
・キータッチする範囲がせまいため、指への負担が少ない
・.vimrcを書き換えるだけである程度素敵なカスタムが出来る（来夢のカスタマイズはウィジェットが関わることがあって面倒だしものによっては重くなる）

ということがあげられます。

最近はVSCodeなどに移っていってVIMから離れる人、最初からVIMを使わない人も結構いるようですが、コーディングをしないにせよ、Linux内のファイルを開いたり編集したりすることを考えると覚えておくに越したことはありません。

以下、VIMなんて経験ないよと言う人が、まず「使ってみたいな」という人のためのイントロ的な部分について説明します。
これだけ覚えておけば、コーディングではないちょっとした文章加工程度なら苦労なくできるようになります。

０．全機能をいきなり使いこなすのは無理

VIMにはいろいろな機能があり、現時点で使い始めて1年足らずの筆者も恐らくポテンシャルの三分の一も使えていません。
リンク先に「一か月でガチVIMMER」という記事がありますが、少なくともこの領域には達していません。

新人達を1ヶ月でガチvimmerにした方法

まあ、どういうカスタマイズが便利で、どんなコマンドを使いたいのかとなると、それは人によって変わってくるので、個々人で少しずつ使えるコマンドを増やしていくことが重要です。

１．コマンド初歩の初歩

とりあえず最初は以下のコマンドだけは頑張って使いながら作業してみましょう。できるならば他にも使うコマンドを増やせばいいが、「一か月はこれだけを徹底的に使ってみる」というスタンスでも構わない…と思います。

・「iまたはo」と「ESC」
編集モードとコマンドモードの切り替え。これを使わないと何もできない。

・「:w」と「:q」
セーブと、VIMから抜けるコマンド。これもないと何もできない

・「hjkl」
上下左右への移動。方向キーを使うのは邪道だそうですが、多少そっちに手が行ってしまうのは仕方ない…と思う。
縛りプレイを徹底すれば上達は早まる。

・「yy」「dd」「p」
コピー、切り取り、貼り付け。行丸ごと対応してくれる。
これは無理してでも使いこなせるようになるべき。
ちなみに「数字＋yy」で指定した行数をコピーしてくれる（ddも同じ）

・「gg」「G」
最後尾行ないし、先頭行へワープ。

・「shift+v」または「ctrl+v」
複数行または一行の任意文字数を選択。その後yyなりddなりできる。
張り付ける位置には若干癖がある。

・「/（文字列）」と「n」
「/」から文字列を入力してエンターを押すと、文字列の場所にワープします。あとはnを押し続けると次の候補に飛んでいきます。

とりあえず、上記のコマンドを徹底的に使ってみること。あとは、自分のペースでできることを増やしていく。

２．vimrcの設定

自分のルートディレクトリに「.vimrc」というファイルを作り、その中に好きな設定を書く。好みの設定は本当に人それぞれなので、以下のリンクあたりを参考にして取捨選択していけばいいです。
ただ、とりあえずは「set virtualedit=onemore」で、行末尾の一つ右までカーソルを移動できるようにしないと非常に不便だと思います。

何も考えず~/.vimrcにこれを書くんだ！ 〜vim初心者によるvim初心者のためのvim入門〜

• 苦労して学んだ初級ネットワークエンジニアとして覚えて置きたい
  • 基本的なネットワーク知識
  • トラブルシューティングツール（Windows、Linux）
  • 考え方

基本的なネットワーク知識

• IPアドレス (IP address)
  • 配達員が物を届ける時に使う住所のようなもの、それを見て宛先までゆく。
  • 2種類あって区分できる必要がある。
• Private IPアドレス（内部IPアドレス）
  • パパの部屋、ママの隣、キッチンなどお家の内部の呼び方と一緒で内部では通じる。
  • ルータの内側で使うアドレス、外部のネットとは繋がらない。
  • 10.0.0.0～10.255.255.255
  • 172.16.0.0～172.31.255.255
  • 192.168.0.0～192.168.255.255
• Global IPアドレス、パブリックIPアドレス(Public IPaddress）
  • 東京都一之江xxxの○○マンション2階Gwaklyさんのような公式的な住所
  • 外部に繋がるには必須
• ルートテーブル（Routetable）
  • 通信をどのような道（経路）で行うか書いている設定又は設定ファイル
    • 動的ルーティング（プログラム的にルーティングを実施）
    • 静的ルーティング（いちいち指定して手動で実施）
• ISP（Internet Service Provider）：ネット提供会社（SOFTBANK、ドコモなどなど）
• ONU（Optical Netowork Unit:光回線の終端装置）：
  分かりやすく言うと機器と機器間、機器とパソコンの間中継器
• NAT (Network Address Translation)
  • ある範囲の内部IPアドレスを任意のGlobalIPアドレスに変換、ネットワークが使える技術。
• DNSサーバ：ドメイン名（www.google.com）をIPアドレス(172.217.175.14)に変えてくれるどこかのサーバ
• ゲートウェイ（Gateway）
  • 通信が外に出れるドア、お家だと玄関とも言える。
• デフォルトゲートウェイ（Default Gateway）
  • 主に使うように設定されている外に出るドア、もちろん窓でも外には出れるように必ずではない。

よく問題になるところ

• ハードウェア的問題（ケーブル、電源）
  • 何か問題があったら、電源ぶち抜いたりケーブル差し直すのはよくあるので一旦聞く。
• セキュリティグループ（SG）
  • デフォルトでトラフィックのアウトはすべてOK、インはNGの場合が多い。
  • ホスト、Cloudならインスタンス単位で設定
  • ステートフル
  • 設定されているすべてのルールが提供される
• ネットワークACL
  • サブネット単位で実施
  • デフォルトはイン/アウトのすべての通信が許可されている場合が多い
  • ステートレス
  • 上から順に適用される
• ポート（Port）
  • 各トラフィックが通るドア？？意図的に閉じたり、必要な時は確認。
  • ウェルノウンポート番号 (0–1023)
• VPN （お家へこっそり行ける俺専用堀穴）
  • ざっくり言うとセキュリティーが高い仮想通信トンネル
• DNS

Windows環境

ping

アプリケーション、機器、ネットワークの疎通性を確認するutilityである。

• Echo request messages 送信
• Echo reply messages 受信

C:\Users\Gwakly>ping 8.8.8.8  ?宛先、google.com を入れてもOK

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=22ms TTL=50
Reply from 8.8.8.8: bytes=32 time=34ms TTL=50
Reply from 8.8.8.8: bytes=32 time=54ms TTL=50
Reply from 8.8.8.8: bytes=32 time=135ms TTL=50

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 22ms, Maximum = 135ms, Average = 61ms

• Good
  • 4∼5回の基本的な死活、Echo request/replyの時間、TTLが簡単にできる
  • 反応が早い
• Bad
  • 機器の死活以外は確認が難しい
• オプション
  • -a IPアドレスでホストネーム知りたい場合使う。
  • -n エコリクエストを何回送るか指定する
  • -t Control+C を押すまでにはPingを継続。ホストが再起動をなどをする際立ち上がる流すと便利。

tracert

C:\Users\Gwakly>tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2    32 ms    60 ms    35 ms  61-24-xxx-xxx.rev.xxx.ne.jp [61.24.xxx.xxx]
  3   195 ms    20 ms   209 ms  10.202.xxx.xxx
  4    61 ms    24 ms    76 ms  10.1.xxx.xxx
  5   168 ms   196 ms    32 ms  203-165-19-245.rev.home.ne.jp [203.165.19.245]
  6    78 ms    24 ms    76 ms  c1-h0-0-0-1.ot-dc.zaq.ad.jp [203.165.19.246]
  7   104 ms   102 ms   101 ms  203.165.0.202
  8    93 ms    18 ms   114 ms  220-152-35-118.rev.home.ne.jp [220.152.35.118]
  9    79 ms   101 ms    20 ms  209.85.244.45
 10    55 ms    78 ms    23 ms  172.253.70.183
 11    74 ms    29 ms    74 ms  dns.google [8.8.8.8]

Trace complete.

• Good
  • 機器までの経路が追跡できる
  • pingコマンドとは違ってループなどが確認できる
• Bad
  • pingより遅い
  • 初心者はパットみて分かりずらい

pathping

C:\Users\Gwakly>pathping 8.8.8.8

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
  0  LAPTOP-xxx.edogx1.kt.home.ne.jp [192.168.xxx.xxx]
  1  192.168.xxx.xxx
  2  61-24-xxx-xxx.rev.home.ne.jp [61.24.xxx.xxx]
  3  10.202.xxx.xxx
  4  10.1.xxx.xxx
  5  203-165-19-245.rev.home.ne.jp [203.165.19.245]
  6  c1-h0-0-0-1.ot-dc.zaq.ad.jp [203.165.19.246]
  7  203.165.0.202
  8  220-152-35-118.rev.home.ne.jp [220.152.35.118]
  9  209.85.244.45
 10  172.253.70.183
 11  dns.google [8.8.8.8]

Computing statistics for 275 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           LAPTOP-xxx.edogx1.kt.home.ne.jp [192.168.xxx.xxx]
                                0/ 100 =  0%   |  
  1   20ms     0/ 100 =  0%     0/ 100 =  0%  192.168.xxx.xxx
                                0/ 100 =  0%   | ? 区間でのパケットの送受信状況が分かるので便利
  2   62ms     0/ 100 =  0%     0/ 100 =  0%  61-24-xxx-xxx.rev.home.ne.jp [61.24.xxx.xxx]
                                0/ 100 =  0%   |
  3   86ms     0/ 100 =  0%     0/ 100 =  0%  10.202.xxx.xxx
                                0/ 100 =  0%   |
  4   66ms     0/ 100 =  0%     0/ 100 =  0%  10.1.xxx.xxx
                                0/ 100 =  0%   |
  5   68ms     0/ 100 =  0%     0/ 100 =  0%  203-165-19-245.rev.home.ne.jp [203.165.19.245]
                                0/ 100 =  0%   |
  6   68ms     0/ 100 =  0%     0/ 100 =  0%  c1-h0-0-0-1.ot-dc.zaq.ad.jp [203.165.19.246]
                                0/ 100 =  0%   |
  7   70ms     1/ 100 =  1%     1/ 100 =  1%  203.165.0.202
                                0/ 100 =  0%   |
  8   70ms     0/ 100 =  0%     0/ 100 =  0%  220-152-35-118.rev.home.ne.jp [220.152.35.118]
                                0/ 100 =  0%   |
  9   71ms     1/ 100 =  1%     1/ 100 =  1%  209.85.244.45
                                0/ 100 =  0%   |
 10   75ms     0/ 100 =  0%     0/ 100 =  0%  172.253.70.183
                                0/ 100 =  0%   |
 11   67ms     0/ 100 =  0%     0/ 100 =  0%  dns.google [8.8.8.8]

Trace complete.

• Good
  • 区間でのパケットの送受信状況が分かるので便利
  • 送信経路が分かり安く可視化できる
• Bad
  • 場合によっては時間が結構長いので急ぎの場合は避けた方がよい

nslookup

よくDNSサーバの問題の場合があるのでDNS情報（DNSサーバ）を調べる時に利用

Linux環境

traceroute

参考サイト
Microsoft pathping (https://docs.microsoft.com/ja-jp/windows-server/administration/windows-commands/pathping)
traceroute（tracert）　～ネットワークの経路を調査する(https://www.atmarkit.co.jp/ait/articles/0108/30/news003.html)