zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

CloudEndure入門（CentOS5環境をAWSに無停止レプリケーション！）

この記事の最終目的

オンプレミスのCentOS5世代の環境をそのままAWSに移設する必要が出てきた。この機会にCloudEndureを試してみる

CentOS5は対象なの？

https://docs.cloudendure.com/Content/Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm
条件付き（Nitoroインスタンスが使えないとか）で行けるっぽい。やった！

作業に当たっての参考

AWS公式
https://aws.amazon.com/jp/cloudendure-migration/
クラスメソッド様のhowto記事
https://dev.classmethod.jp/articles/cloudendure-no-charge/
こちらにたいへんよくまとまっているのでまずは通読してから作業


【作業概要】

やってみた

1)CloudEndureサービスへのサインアップ

Sign up for your CloudEndure account
https://console.cloudendure.com/#/register/register
　→メール経由でID/PWを承認

2)CloudEndureの管理画面で初期設定

AWSでCloudEndureが提示するポリシーを作成し、専用のIAMにアタッチします

  • ポリシーの作成

[create policy] -[JSON]
ポリシーは以下の中身をそのまま貼り付けます。
https://docs.cloudendure.com/Content/IAMPolicy.json
（CloudEndure管理画面左ペインの[Stup & Info]-[AWS CREDENTIALS]のThe Project must have these permissionsのリンク先）

  • IAMの作成

専用のIAM Userを作成し、上記ポリシーをアタッチします

UserNmae： CloudEndure
アクセスの種類：プログラムによるアクセス

→アクセスキーが発行されますので、これをCloudEndureに登録しましょう。

  • CloudENdureの管理画面

CloudEndureの管理画面にサインインします
https://console.cloudendure.com/#/signIn

CloudEndure管理画面左ペインの[Stup & Info]-[AWS CREDENTIALS]でアクセスキーとシークレットアクセスキーを設定します。


3)レプリケーションの設定（1）レプリケーションサーバの用意

CloudEndure管理画面左ペインの[Stup & Info]-[REPRICATION SETTINGS]でレプリケーション設定を行います。

Migration Source:Other Infrastructure
Migration Target:AWS Asia Pacific(Tokyo)
Choose the Replication Server instance type:t3.micro
Choose the subnet where the Replication Servers will be launched:任意のサブネット

上記で[SAVE REPLICATION SETTINGS]

4)レプリケーションの設定（2）移行元にエージェントのインストール

CloudEndure管理画面左ペインの[Machines]-[AddMachines]でAgentインストール用のコマンドが得られます。

For Linux machines
Download the CloudEndure Agent Installer for Linux:

wget -O ./installer_linux.py https://console.cloudendure.com/installer_linux.py
sudo python ./installer_linux.py -t <付与されたトークン> --no-prompt

このコマンドをそのままレプリケーション元のサーバで実行します。

※今回検証時にはEventlogに
agentInstallFailed Failed to install agent on machineエラーが出ました。
cloudendure.logによればgccが入っていなかったのが原因だったので、gccをインストールしています。
※末尾にCentOS5へのgcc追加メモを追記しています。

sudo python ./installer_linux.py -t <Token> --no-prompt
The installation of the CloudEndure Agent has started.
Running the Agent Installer for a 32 bit system...
Connecting to CloudEndure Console... Finished.
Identifying disks for replication.
Disk to replicate identified: /dev/sda of size 20.0 GiB
All disks for replication were successfully identified.
Downloading CloudEndure Agent... Finished.
Installing CloudEndure Agent... Finished.
Adding the Source machine to CloudEndure Console... Finished.
Instance ID: <インスタンスID>.
Installation finished successfully.

上記ログを確認後、EC2に以下のインスタンスが起動していることを確認

インスタンス:  i-xxxxxxxxxxxxxxxxxxx (CloudEndure Replication Server conxx)
5)レプリケーションの設定（3）テスト

CloudEndureの管理画面-Machinesで、登録されているマシンの同期が完了するとテストが可能になります（旗が黄色になっています）。
[BLUEPRINT]でインスタンスの構成を定義できます。

MachineType：t3.micro→上記制限のため利用できない（ちゃんとエラーになる）のでt2.microで確定
Launch type：On demand
Subnet：任意
Security Group：任意
Private IP：Create New
EIP：None
PublicIP ：Yes

あとはデフォルトで[SAVE BLUEPRINT]

設定したら、テストモードで仮想マシンを移行先で起動します。
[Launchi target machine]-testmode
→この時、AWS上ではコンバーターインスタンスが起動して死んでいく

■Job Progressで進捗確認

Launch Test   |   Completed Successfully

2020/5/4 17:55:30	Job started
2020/5/4 17:55:30	Started waiting for latest snapshot
2020/5/4 17:56:12	Finished waiting for latest snapshot
2020/5/4 17:56:15	Started cleanup of volume Volume:vol-hogehoge
2020/5/4 17:56:16	Finished cleanup of volume Volume:vol-hogehoge
2020/5/4 17:56:19	Started machine conversions
2020/5/4 17:57:43	Finished machine conversions
2020/5/4 17:58:54	Started creating a replica for instance localhost.localdomain
2020/5/4 18:00:25	Finished creating a replica for instance localhost.localdomain
2020/5/4 18:00:26	Job finished

sshして（このときpemはなくレプリケーション元のOSのログインID/PWでログインすることになる）挙動を確認。

6)レプリケーションの設定（4）カットオーバー

最後にカットオーバーモードで起動します。
テストインスタンスは削除され、新しいインスタンスが起動します。

7)後始末

コンソールからターゲットマシンを削除します。
プロジェクト内にターゲットマシンが無くなると、Replication Serverは自動で削除されます。

以上！

■（オマケ）CentOS5にgccを追加したメモ

【参考】

https://qiita.com/Targityen/items/30f7ce886a396cfe46dd

1. CentOS バージョンの確認

cat /etc/redhat-release
# CentOS release 5.9 (Final)

2. リポジトリファイルの更新

vi /etc/yum.repos.d/CentOS-Base.repo
baseurlを以下に変更

[base]
baseurl=http://archive.kernel.org/centos-vault/5.9/os/$basearch
[updates]
baseurl=http://archive.kernel.org/centos-vault/5.9/updates/$basearch/
[extras]
baseurl=http://archive.kernel.org/centos-vault/5.9/extras/$basearch/
[centosplus]
baseurl=http://archive.kernel.org/centos-vault/5.9/centosplus/$basearch/
[contrib]
baseurl=http://archive.kernel.org/centos-vault/5.9/contrib/$basearch/

※ここではバージョンを 5.9 としていますが、手順1で確認した CentOS のバージョンを指定してください。

yum install でgcc入れる

yum install gcc c++

Microsoft Remote Desktop for Macで「Unicode Mode」ってなってから日本語入力ができなくなったけどCtrl+Cmd+Kで復活したメモ

【問題と解決方】

mac OSからWin10マシンにリモートデスクトップ中に別アプリのショートカットでUnicodeModeになってしまって元に戻せなかった。
今まで引っかからなかったのになぜだ……と思ったら以下の様な情報が。
Ctrl+Cmd+Kで復活した。3日くらい悩んだよ。。。

【参照】

https://moshbox.jp/?p=62722
曰く
The key change in this update is the ability to switch between Scancode (CTRL+COMMAND+K) and Unicode (CTRL+COMMAND+U) modes when entering keyboard input.

【モードについて】

Ctrl+Cmd+U
Unicode Mode

Ctrl+Cmd+K
Scancode Mode

これ改悪じゃないの。。

Mac OS 10.15 Catalina以降で　Dell Color Laser 1320c で印刷しようとすると「Filter failed」となって印刷できない問題（20200506現在）

（20200506現在）Mac OS 10.15 Catalina以降で　Dell Color Laser 1320c で印刷しようとすると「Filter failed」となって印刷できない問題がある模様。

以下の情報より、ひとまずFuji Xerox C525A printer driverが代替として使えるらしい。
apple.stackexchange.com

で、実際にドライバをDELL提供のものと差し替えてみたところ、前面差込口からの給紙はできたが、トレイからの給紙ができない。。。

ひとまず全く印刷できない、という危機は回避されたのでメモっておく。
DELL何やっとん・・・はよドライバ出して

（メモ）Apacheでダイジェスト認証

【参照】

qiita.com

曰く

Basic認証はユーザ名とパスワードをBase64エンコードしたものを使う認証で、
Digest認証はユーザ名とパスワードをMD5でハッシュ化したものを使う。

なるほどDigestのほうがよさそう。

【手順】

1)モジュールの確認
apachectl -M | grep digest

で auth_digest_module (shared)　が出てればOK.
→無いときはhttpd.confでいかがコメントアウトされていないか、とか
# LoadModule auth_digest_module modules/mod_auth_digest.so
/etc/httpd/modules の下あたりを確認する
2)htdigestコマンドでパスワードファイルを作成
htdigest [-c] パスワードファイル名 領域名 ユーザー名
  • オプション：初回のみ-cで作成。追加する場合はオプションなし。
  • 領域（レルム）名：下記confで「AuthName」に指定する文字列を設定

例）

htdigest -c /etc/httpd/conf/.htdigest 'Secret Zone' hogeuser
3)ApacheのconfファイルにDigest認証の設定を追記

ユーザー認証によるアクセス制限をかけるディレクトリ

/var/www/html/member

の場合、Apacheの設定ファイル(/etc/httpd/conf.d/hoge.confなど）

<Directory "/var/www/html/member">
    AuthType Digest
    AuthName "Secret Zone"
    AuthUserFile /etc/httpd/conf/.htdigest
    Require valid-user
</Directory>

# もしくは

<Location />
    AuthType Digest
    AuthName "Secret Zone"
    AuthUserFile /etc/httpd/conf/.htdigest
    Require valid-user
</Location>
4)Apacheを再起動して再起動。

2020年04月版：10万円以下のPC、迷ったらこれを買え！メモ

[課題]

エンジニア向けに配布するPC、10万円以下でどれがいい？
→開発環境をローカルで立てることが多くなった（Dockerで開発）のでCPUの性能とメモリが最優先。

[具体的なスペック]

  • CPU 4Core8Thread以上のCPU

具体的には、CinebenchR15で single=150 Multi=750 以上

  • メモリ 16GB以上
  • ストレージ 512GB以上のSSD

※CPUベンチは以下のサイトを参照のこと：
https://chimolog.co/bto-cpu-list/

[上記を踏まえた2020年お勧めノート]

Lenovo IdeaPad C340

※10万円未満だとこれが一番マシかな……という感じ。


  • CPU、i7-10510U(4C8T)、メモリ16GB、ストレージ1TB
  • 税込：96,800
  • メリット：そこそこの性能。大変コスパがよい。タッチパネルも案外使える。
  • デメリット：納期が4週間～。急ぎの時はNG。必要十分な入出力だが、LANポートがないのでほしかったら別途USB-C有線LANアダプタとか買う必要がある。
（参考）ホントはこれくらいほしい

DELL XPS13

  • CPU、i7-10710U(6C12T)、メモリ16GB、ストレージ512GB(NVMe)
  • 税込：168,325

DNS「逆引き」に関する俺理解メモ

以前
http://zuntan02.hateblo.jp/entry/2017/03/17/112857
という記事を書いたが、そもそもメールサーバで設定する「逆引き」とは何なのか。
今朝もう一回調べて以下の腹落ちに達したので自分のためにメモを残します。

【メール送信元サーバが逆引き設定されていないとどんなことが起こるか】

この記事を書くに至った原因、2019年12月、それまで5年以上問題なく送信を受けてくれていたGmailサーバから突然はじかれるようになった。

以下qmailのsendログより：

2019-12-xx xx:xx:xx.xxxxxxxxxx delivery xxxxxxx: failure: 64.233.189.27_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.26_This_message_does_not_have_authentication_information_or_fails_to/550-5.7.26_pass_authentication_checks._To_best_protect_our_users_from_spam,_the/550-5.7.26_message_has_been_blocked._Please_visit/550-5.7.26__https://support.google.com/mail/answer/81126#authentication_for_more/550_5.7.26_information._xxxx_-_gsmtp/

上記参照URLによれば以下の設定が必要

IP のガイドライン
    送信元 IP には PTR レコード（送信元 IP の逆引き DNS）が必要です。また、PTR レコードで指定されているホスト名の DNS の正引き解決によって取得した IP と一致している必要があります。
    送信元ドメインは、SPF チェックまたは DKIM チェックにパスする必要があります。

spfレコードは設定してあったが、逆引きが設定されていないサーバであったため、レンタルサーバ会社に逆引き申請を実施
※さくらの専用サーバの場合：https://help.sakura.ad.jp/206252881/#ac02

逆引きが設定された直後にエラーは止まり、Gmailへのメールが届く様になった。
逆引き重要ですね！

【注意】

ここではメール送信に関する狭義での「正引き・逆引き」についてメモしています。
勉強中のため不正確な記述があり、また不定期に追記・修正あります.

【基本情報】

https://ja.wikipedia.org/wiki/%E9%80%86%E5%BC%95%E3%81%8D
http://akisoftware.com/pmsrv/help/revdns.html

【正引き・逆引きとは】

  • 正引き：ホスト名（ドメイン名）からIPアドレスを引き出すこと
  • 逆引き：IPからホスト名を引き出すこと

【確認方法】

# 正引き
nslookup ホスト名
または
dig ホスト名

# 逆引き
nslookup IPアドレス
または
dig -x IPアドレス

【DNS逆引きレコード(PTRレコード)登録方法】

  • （前提）正引きレコード正引きレコード(Aレコード)でmail.hoge.com　が逆引きしたいIPで登録されている

通常、サーバホスティング業者(AWSの上限緩和申請やさくらのクラウドのコンパネなど)の方で逆引き設定申請パスがあり、申請時に正引き設定されていれば逆引き設定がなされる。
※具体的にはipアドレスを逆に並べた後.in-addr.arpaを付けたアドレスのPTRレコードが生成される
例）

# 正引き
dig mail.hoge.com
mail.hoge.com.       xxxx    IN      A       xxx.xx.xxx.xx

# 逆引き
dig -x xxx.xx.xxx.xx
xxx.xx.xxx.xx.in-addr.arpa. xxxx IN     PTR     mail.hoge.com.

【なんでメール送信元は逆引きできるといいのか】

  • 逆引きはメール送信元サーバ（IP)の信頼性を高める作業

逆引きが出来るホストからのメールの送信のみを受け付け、それ以外からは受け付けないようにすると、身元が不明な（DNS に登録されていない） IP からメールの受信を拒否することにより 一定量の spam を防げる、という発想