MacにAWS CLI(Version 1)をセットアップした時のメモです。python3ベースです。
curl -O https://bootstrap.pypa.io/get-pip.py python3 get-pip.py --user
echo 'PATH=${PATH}:/Users/nobuyuf/Library/Python/3.8/bin' >> ~/.bash_profile
echo 'export PATH' >> ~/.bash_profile
$ aws --version aws-cli/1.16.103 Python/3.8.0a1 Darwin/17.7.0 botocore/1.12.93
DBMSアクセスなどで利用するユーザ/パスワードを、アプリケーションのコードに埋め込むとか、APサーバに設定ファイルとしてで腹持ちさせて参照させるとか、セキュリティ的に良くないですがやってしまいがちだと思います。
AWS Secrets Manager はそのような、ユーザ/パスワードなどのシークレット情報を、所有する暗号化キーで暗号化し、AWS Key Management Service (KMS) に保管するサービスです。保管しているシークレート情報は、必要都度に取得して利用します。取得はIAMのきめ細かいポリシーを使用して制限できます。
ここではAWS Secrets ManagerをVPC閉塞空間で利用するための設定し、かつリソースポリシーでシークレット情報を取得可能なVPCを制限する手順を説明します。
SecretsManagerのデフォルトの鍵で暗号化することもできますが、ここでは独自作成したKMSの鍵で暗号化することとし、事前にKMSの鍵を作成します。
APサーバからSecretsManagerのシークレット情報を取得するためのロールを作成します。ロールにはSecretsManagerからの情報取得のポリシーと、KMSからの鍵取得のポリシーを設定します。
EC2インスタンスから、SecretsManagerからパスワードを取得するIAMロールを作成して、EC2インスタンスにアタッチします。
下記の２つのポリシーを指定します(ARNは適時修正してください)。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecrets"
],
"Resource": "arn:aws:secretsmanager:ap-northeast-1:445629031529:secret:Prod/System-A/RDS/testuser-6l08Sp"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:ap-northeast-1:445629031529:key/df0849ea-0c1a-44e3-b86b-43ae43396384"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
作成したEC2インスタンスロールを利用し、KMSのキーを取得できるように、KMS鍵のキーユーザに作成したロールを追加します。
AWS CLIにProxy設定をしている場合、Proxyの除外設定にSecretsManagerのエンドポイントのURL(東京リージョンの場合”secretsmanager.ap-northeast-1.amazonaws.com”)を追加します。追加した後は再ログインして環境変数が反映されていることを確認します。
export HTTPS_PROXY=http://10.1.173.17:3128 export HTTP_PROXY=http://10.1.173.17:3128 export NO_PROXY=169.254.169.254,s3.ap-northeast-1.amazonaws.comi,secretsmanager.ap-northeast-1.amazonaws.com
aws CLIコマンドの" aws secretsmanager get-secret-value"を利用しシークレット情報を取得します。
aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:ap-northeast-1:445629031529:secret:Prod/System-A/RDS/testuser-6l08Sp
RDBにアクセスできるかを確認します。(この例ではMySQLエンジンを利用しています)
mysql --host=<RDSのエンドポイントDNS> --port=<Port番号> --user=<ユーザID> --password='<パスワード>'
SecretsManagerは、リソースポリシーを設定することが可能です。ただしマネージメントコンソールでは設定できなず、AWS CLIでの設定が必要になります。(ここではAWS CLIでSecrets Managerの管理設定を行うための準備作業は割愛します)
今回は特定のVPC Endpoint以外からのリソース情報取得のためのアクセス(GetSecretValue API)を拒否するリソースポリシーを設定します。
AWS CLIを実行する端末上でリソースポリシー用のjsonファイルを用意します。"aws:sourceVpce"には先に作成した、SecretsManager用のVPC EndpointのARNを指定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-0b2b52e1dc7772d50"
}
}
}
]
}
ローテーション用のLambdaの中でDBMSのユーザ＆パスワード更新を実行するため、admin権限のあるDBユーザをSecretsManagerに登録します。
先に設定したリソースポリシーをアタッチしたままでは、ローテーションの設定が一部できないため、リソースポリシーを一時的に解除します。
aws secretsmanager delete-resource-policy --secret-id arn:aws:secretsmanager:ap-northeast-1:445629031529:secret:Prod/System-A/RDS/testuser-6l08Sp
AWS CLIの”aws secretsmanager put-resource-policy ”を利用し、SecretsManagerのシークレット情報にリソースポリシーを再アタッチします。
aws secretsmanager put-resource-policy --secret-id arn:aws:secretsmanager:ap-northeast-1:445629031529:secret:Prod/System-A/RDS/testuser-6l08Sp --resource-policy file://policy.json
マネージメントコンソールの「すぐにシークレットを更新」か、AWS CLIの"aws secrets manager rotate-secret"を利用しシークレットの更新を行います。
ローテーション用のLambda関数を自作することもできます。自作する場合、下記にサンプルのローテーション関数があるのでこちらを参考にするのが良いと思います。
数年前、AIが流行り始めた時に機械学習がなんぞやと調べて時に出たったShieShareのイントロの「識別・認識とは？」の説明が、詩的ででもわかりやすくて、その時ゾクゾクと来たのを思い出したので、備忘録がてら引用しておきます。
ちなみに本文は数学者の方のスライドなので難しくてよくわかりませんでしたが(笑)
上記SlideShareのP19-32から引用
認識とは、不要な情報を捨てること
特徴選択・特徴抽出が
識別・認識の本質色々な特徴や次元を
考えることは
とても役に立つことですが知っている特徴や次元を
何も考えず全部手元に置いておくと
人間は高次元ユークリッド空間で
迷子になってしまいます高次元ユークリッド空間は
私たちの感覚と乖離しやすくもしあなたが無限次元の
ユークリッド空間に放り出されたら
見渡す限り全てのものが
あなたからはるかに遠くにあって
何も見分けがつかなるくなるような
そんな空間ですこれは「次元の呪い」
と言われていますいいものも悪いものも
好きなものも嫌いなものも
関係あるものも関係ないものも見分けがつかなくなってしまう
恐ろしい「呪い」ですね！つまりあなたか
アヒルと白鳥の
雑多な集団の中から
白鳥を探し出しないのならまずあなたはあなたが
白鳥の
どの特徴を選択・抽出して
白鳥を白鳥と
認識しているのか
なるべく正確に
見つける必要があります
開発用途のiOSアプリの署名用に利用する証明書(以下、開発用証明書)をAPNsで作成します。手動もできますが、ここではXcode連携で作成します。
Apple Developerにログインして登録した証明書を確認できます。
アプリケーションを識別するためのApp IDを登録します。
Macを利用して、CSR(Certificate Signing Request)を作成します。
利用する App ID、開発用証明書、端末をそれぞれ紐付けプロビジョニングプロファイルを作成します。
作成したプロビショニングプロファイルは、Xcodeで開発したアプリに組み込みます。
プロバイダー(サーバや、Amazon SNSやAmazon PinpointなどAPNsにプッシュ通知依頼するもと)がAPNsアクセスするときに必要となるAPNs用証明書(.p12) を作成します。
/* <system section="theme" selected="6653812171397406126"> */ @import url("https://blog.hatena.ne.jp/-/theme/6653812171397406126.css"); /* </system> */ /* <system section="background" selected="bg5"> */ body{ background-color:#486079; background-image:url('/images/theme/backgrounds/theme5.jpg'); background-repeat: no-repeat; background-attachment:fixed; background-position: center top; background-size:cover; } /* </system> */ table{ width:100%;} .scroll{ overflow: auto; white-space: nowrap;} .scroll::-webkit-scrollbar{height: 4px;} .scroll::-webkit-scrollbar-track{background: #F1F1F1;} .scroll::-webkit-scrollbar-thumb {background: #454545;} @media screen and (min-width:1350px) { #box2 { float: right; width: 300px; } #main { float: right; width: 740px; } #wrapper { float: left; width: 1030px; } #content-inner { width: 1350px; } }
Pytho処理時間をナノ秒で計測する方法です。
python3.7で追加された、time.clock_gettime_ns()を利用することで実現しています。*1
#!/usr/bin/env python3 # -*- coding: utf-8 -*- import sys import time def main(): start = time.clock_gettime_ns(time.CLOCK_MONOTONIC) <処理内容を記載> end = time.clock_gettime_ns(time.CLOCK_MONOTONIC) print('time: {}'.format(end - start)) if __name__ == "__main__": sys.exit(main())
time.clock_gettime_ns()は、int型を返します(なので上記コードのstart, endはint型)。
int型の場合overflowが気になりますが、python3のint型は仕様上上限なしでメモリサイズに空きがある限り拡大できるようです(python2のlong型がint型になった)
なので、python3の場合はオーバーフロー気にしなくて良さそうですね
Integers
https://docs.python.org/3.1/whatsnew/3.0.html#integers
PEP 0237: Essentially, long renamed to int. That is, there is only one built-in integral type, named int; but it behaves mostly like the old long type.
PEP 0238: An expression like 1/2 returns a float. Use 1//2 to get the truncating behavior. (The latter syntax has existed for years, at least since Python 2.2.)
The sys.maxint constant was removed, since there is no longer a limit to the value of integers. However, sys.maxsize can be used as an integer larger than any practical list or string index. It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options).
The repr() of a long integer doesn’t include the trailing L anymore, so code that unconditionally strips that character will chop off the last digit instead. (Use str() instead.)
Octal literals are no longer of the form 0720; use 0o720 instead.
Python+boto3でPublishするためのサンプルスクリプトです。
sudo yum -y install python2-boto3
$ aws configure AWS Access Key ID [None]: AWS Secret Access Key [None]: Default region name [None]: ap-northeast-1 Default output format [None]:
#!/usr/bin/env python # -*- coding: utf-8 -*- import sys import boto3 TOPIC_ARN=u'arn:aws:sns:ap-northeast-1:999999999:TopicName' def main(): # Get session client = boto3.client('sns') request = { 'TopicArn': TOPIC_ARN, 'Message': u'test message', 'Subject': u'test' } response = client.publish(**request) if __name__ == "__main__": sys.exit(main())
検証で自己署名証明書(オレオレ証明書)でない証明書が必要だったのですが、お金がかけられなかったのでお名前.comで安いドメインを取得し、Let's Encryptで無料証明書を取得してAWS上で検証をしました。この記事はその時の手順をまとめたものです。
この記事では、Let's Encryptから無料のサーバ証明書(ワイルドカード証明書)を取得し、(複数の)apacheサーバに証明書を組み込む手順を説明してます。
Amazon Linux2でLet's EncryptをググるとCertbotを改造するケースが多いですが、この手順では引数を工夫することで改造なしを実現してます。
Let's Encryptの証明書の有効期限は90日で、この記事の手順では更新毎に利用している全apacheサーバに証明書を再配布しなければならないので、PoCや検証などで一時的に正規の証明書が必要なケースを想定した手順になります。
なお、この手順の前提として証明書用のドメインを取得している必要があります。
Let's Encrypt は、「SSL/TLSサーバ証明書」を無料で発行してくれる認証局（CA）で、以下の特徴があります。
非営利団体の ISRG (Internet Security Research Group) が運営しており、シスコ（Cisco Systems）、Akamai、電子フロンティア財団（Electronic Frontier Foundation）、モジラ財団（Mozilla Foundation）などの大手企業・団体が、ISRG のスポンサーとして Let's Encrypt を支援しています。
詳しくは公式サイトを参照してください。
letsencrypt.org
Certbotが稼働可能なLinux、MacOS、Unixを準備してください。Certbotが稼働可能な環境は、Certbotの公式ページを確認してください。
今回は、CertbotではサポートされていないですがAmazon Linux 2上でCertbotを動かします。
Certbotのセットアップは、こちらのCertbotの公式ページに説明があります。
ただAmazonLinux2はこの手順ではできませんので、以下ではAmazonLinux2で動作するように手順をカスタマイズしています。
(a)前提パッケージのインストール
pythonのvirtualenvというツールを内部で利用しているようなのでそれをインストールします。
sudo yum -y install python-virtualenv
(b)Certbotのインストール
今回は、/usr/local/binにインストールします。
$ sudo wget --directory-prefix=/usr/local/bin https://dl.eff.org/certbot-auto $ sudo chmod a+x /usr/local/bin/certbot-auto
(c)Certbotのインストレーション実行
$ sudo /usr/local/bin/certbot-auto --no-bootstrap --install-only Upgrading certbot-auto 0.29.1 to 0.30.0... Replacing certbot-auto... Creating virtual environment... Installing Python packages... Installation succeeded. Certbot is installed.
準備が整ったらサーバ証明書を取得します。Certbotはengixやapacheなど証明書を利用したいwebソフトと連携させることができますが、今回は複数のサーバに配布するためマニュアルモードで証明書を取得します。
(a)Certbotの実行
証明書取得のためコマンドを実行します。モードはマニュアルで、ドメイン使用権の認証方法としてDNSを利用(DNS サーバのTXT レコードに指定されたキーを設定)しています。*3コマンドの詳細は、"certbot-auto --help all"で参照できます。
$ sudo /usr/local/bin/certbot-auto --no-bootstrap certonly \
--manual \
--manual-public-ip-logging-ok \
--domains '*.poc.nopipi.work' \
--email admin@poc.nopipi.work \
--agree-tos;
(b)DNSレコードの登録
上記(a)を実行すると、下記のようにpoc.nopipi.workのドメインに、_acme-challengeという名前のTXTレコードで、"nmdZ・・・"という値を設定するよう指定がありますので、指示に従ってDNSサーバにTXTレコードを登録します。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please deploy a DNS TXT record under the name _acme-challenge.poc.nopipi.work with the following value: nmdZGYXDo6J0DVtfKMCHwhCaXdjtl0eJuYGN4J0XMQk Before continuing, verify the record is deployed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
今回poc.nopipi.workはRoute53を利用しているので、Route53でレコード登録します。
$ dig TXT _acme-challenge.poc.nopipi.work ; <<>> DiG 9.8.3-P1 <<>> TXT _acme-challenge.poc.nopipi.work ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19405 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3 ;; QUESTION SECTION: ;_acme-challenge.poc.nopipi.work. IN TXT ;; ANSWER SECTION: _acme-challenge.poc.nopipi.work. 60 IN TXT "nmdZGYXDo6J0DVtfKMCHwhCaXdjtl0eJuYGN4J0XMQk" <以下略>
(c)作成された証明書の確認
"/etc/letsencrypt/live/ドメイン名" のディレクトリ配下にファイルが作成されますので、確認してください。
sudo ls /etc/letsencrypt/live/poc.nopipi.work cert.pem chain.pem fullchain.pem privkey.pem README
| ファイル名 | 項目 |
|---|---|
| cert.pem | サーバ証明書 |
| privkey.pem | 秘密鍵 |
| chain.pem | 中間証明書 |
| fullchain.pem | 証明書と中間証明書を連結したファイル |
作成した証明書を、apacheをセットアップしているインスタンス内にコピーします。
この手順では、他インスタンスへ証明書をコピーする時作成時と同じディレクトリにデプロイされるものと仮定します。
sslの設定ファイル．ssl.confに取得したサーバ証明書関連のファイルを展示します。
<VirtualHost _default_:443> 中略 SSLCertificateFile /etc/letsencrypt/live/poc.nopipi.work/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/poc.nopipi.work/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/poc.nopipi.work/chain.pem SSLCACertificateFile /etc/letsencrypt/live/poc.nopipi.work/fullchain.pem 中略 </VirtualHost>
この記事を書いた後に気づきましたが、AWSのEC2のユーザガイドにも利用手順ありましたね。
docs.aws.amazon.com
*1:公式:Getting Started - Let's Encrypt - Free SSL/TLS Certificates、非公式解説:Let's Encrypt の使い方 - Let's Encrypt 総合ポータル
*2:公式:ACME v2 Production Environment & Wildcards - API Announcements - Let's Encrypt Community Support、非公式解説:よくある質問 - Let's Encrypt 総合ポータル
*3:この記事などを参考にしています。Let's Encryptでワイルドカード証明書発行してみた · D
この記事では「お名前.com」で取得したドメインに任意のサブドメインを作成し、そのサブドメインの管理をAmazon Route53に委任する手順を説明しています。
お名前.comで取得したドメイン：nopipi.work
Route53に委任するサブドメイン名：poc.nopipi.work
お名前.comでのドメイン取得手順は、いろいろなサイトが説明記事を書いているのでこことでは細かい説明はしません。googleで「お名前 ドメイン 取得手順」で検索すると色々情報が出ますので基本そちらを参照してください。
また、お名前.comでドメイン取得する場合の留意事項を以下に列挙します。
Route 53のPublic Hosted Zoneで控えたNSレコードを、お名前.comにて、取得ドメインのDNSサーバとして登録します。
お名前.comで取得したドメインをAWS上で利用する方法はいくつかあります。３つの例を下に示します。
| 管理 主体 | 方法 | メリット | デメリット |
|---|---|---|---|
| お名前.com | お名前.comのレコードへAWSのFQDNをCNAME登録する |
| |
| AWS | Amazon Route53にドメインを移管する |
| 下記制約があって移管面倒 |
| サブドメインをRoute53に委任 | サブドメインしか管理できない |
*1:参考：お名前.comのドメインをAWSで使用する4つの方法 - Qiita
*2:Public Hosted Zoneは外部からドメイン情報が参照される。Private Hosted Zoneは、関連づけられたVPCにのみ情報が参照できる
起動しなくて困ったので、そんな時の対処方法をメモしておきます。
Macのハードウェアを管理するSMC(System Management Controller)をリセットする。SMCはバッテリー、熱管理、各種センサー管理をしているユニット。
support.apple.com
NVRAM には、音量、画面解像度、選択されている起動ディスク、時間帯、最近起きたカーネルパニックの情報などが保存されています。この情報をリセットします。
support.apple.com
上記でダメなら、セーフモードで原因切り分け。切り分けできなかったらサポートへ。
support.apple.com
ENA(Elastic Network Adapter)は、シングルルート I/O 仮想化 (SR-IOV) を使用したAWSの拡張ネットワーキングです。RHEL7.1にはこのENAのドライバが含まれていないため、RHEL7.1環境でENAを利用する場合は個別にインストールする必要があります。この記事は、RHEL7.1環境にENAドライバをインストールして利用可能にする手順をまとめたものです。
RHEL7でENAがサポートしているのは、RHEL7.4以降になります。RHEL7.1ではENAサポートされていないため、その点は留意下さい。
RHEL7.1をm4インスタンスで起動してenaをインストールします。
(1)RHELのカーネルバージョン、AMI/インスタンスタイプ確認
$ cat /proc/version Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015 $ curl http://169.254.169.254/latest/meta-data/ami-id;echo ami-b1b458b1 $ curl http://169.254.169.254/latest/meta-data/instance-type;echo m4.16xlarge
(2) enaドライバの確認
RHEL7.1でAMIからインスタンスを起動した状態では、enaドライバがないことを確認します。
$ sudo modinfo ena modinfo: ERROR: Module ena not found.
git、 makeコマンド、gccコマンドなど必要なrpmパッケージをインストールします。また、gitが内部で利用するcurlのバージョンが古くgitが動作しないので、curlだけrpmをアップデートします。
$ sudo yum -y update curl $ sudo yum -y install git make gcc $ sudo yum -y install kernel-devel-$(uname -r)
マニュアル*1の内容に従いgitからコードをダウンロードします。
$ git clone https://github.com/amzn/amzn-drivers
$ cd amzn-drivers/kernel/linux/ena $ make
$ sudo insmod ena.ko $ lsmod |grep ena ena 98319 0 <==ドライバが組み込まれていることを確認 $ sudo rmmod ena $ lsmod |grep ena
(a) modprobeのカーネルモジュールロード設定追加
$ sudo sh -c 'cat > /etc/modules-load.d/ena.conf' ena
(b) モジュールのコピー・依存関係の更新・dracutの更新
$ sudo cp ena.ko /lib/modules/$(uname -r)/ $ sudo depmod $ sudo dracut -f -v
$ sudo shutdown -r 0 <SSHログイン後> $ cat /proc/version Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015 $ lsmod|grep ena ena 98319 0
最近のsystemdやudevでのデバイス命名は、enp5s0のような一貫性のある命名をします*2。RHELのAMIから起動した場合は従来のeth0のようなデバイス名称を継続利用するために、このデバイス命名の一貫性の機能を無効化します。
(a) Grubのテンプレートファイルに設定を追加
起動オプションに、"net.ifnames=0"を追加します。
GRUB_TIMEOUT=1 GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="crashkernel=auto console=ttyS0,115200n8 console=tty0 net.ifnames=0" GRUB_DISABLE_RECOVERY="true"
(b)grub2設定更新
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg $ sudo shutdown -r 0
インスタンスがstopの状態で、modify-instance-attributeでENAを有効化します。そして有効化後にインスタンスを起動します。
$ aws ec2 modify-instance-attribute --instance-id i-0180f9795f32bf2c1 --ena-support $ aws --profile dev1 ec2 start-instances --instance-ids i-0180f9795f32bf2c1
dmesgやmessagesで状態を確認します。
[ 22.879003] ena: module verification failed: signature and/or required key missing - tainting kernel [ 22.883928] ena: Elastic Network Adapter (ENA) v2.0.2g [ 22.884033] ena 0000:00:03.0: Elastic Network Adapter (ENA) v2.0.2g [ 22.890297] ena: ena device version: 0.10 [ 22.890299] ena: ena controller version: 0.0.1 implementation version 1 [ 22.938296] ena 0000:00:03.0: LLQ is not supported Fallback to host mode policy. [ 22.938397] ena 0000:00:03.0: creating 8 io queues. rx queue size: 1024 tx queue size. 1024 LLQ is DISABLED [ 22.943929] ena 0000:00:03.0: Elastic Network Adapter (ENA) found at mem f3000000, mac addr 06:b9:68:b9:70:b2 Queues 8, Placement policy: Regular
"ena: Elastic Network Adapter (ENA) v2.0.2g"以下の行で、enaがロードされ初期化されているのがわかります。
Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info> (eth0): carrier is OFF (but ignored) Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info> (eth0): new Ethernet device (driver: 'ena' ifindex: 2) Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/0 Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
$ ll /sys/class/net/eth0/ total 0 -r--r--r--. 1 root root 4096 Dec 10 02:23 addr_assign_type -r--r--r--. 1 root root 4096 Dec 10 02:23 address -r--r--r--. 1 root root 4096 Dec 10 02:28 addr_len -r--r--r--. 1 root root 4096 Dec 10 02:28 broadcast -rw-r--r--. 1 root root 4096 Dec 10 02:28 carrier lrwxrwxrwx. 1 root root 0 Dec 10 02:23 device -> ../../../0000:00:03.0 -r--r--r--. 1 root root 4096 Dec 10 02:23 dev_id -r--r--r--. 1 root root 4096 Dec 10 02:23 dev_port -r--r--r--. 1 root root 4096 Dec 10 02:28 dormant -r--r--r--. 1 root root 4096 Dec 10 02:28 duplex -rw-r--r--. 1 root root 4096 Dec 10 02:28 flags -rw-r--r--. 1 root root 4096 Dec 10 02:28 ifalias -r--r--r--. 1 root root 4096 Dec 10 02:23 ifindex -r--r--r--. 1 root root 4096 Dec 10 02:23 iflink -r--r--r--. 1 root root 4096 Dec 10 02:28 link_mode -rw-r--r--. 1 root root 4096 Dec 10 02:28 mtu -rw-r--r--. 1 root root 4096 Dec 10 02:28 netdev_group -r--r--r--. 1 root root 4096 Dec 10 02:28 operstate -r--r--r--. 1 root root 4096 Dec 10 02:23 phys_port_id drwxr-xr-x. 2 root root 0 Dec 10 02:28 power drwxr-xr-x. 18 root root 0 Dec 10 02:23 queues -r--r--r--. 1 root root 4096 Dec 10 02:28 speed drwxr-xr-x. 2 root root 0 Dec 10 02:28 statistics lrwxrwxrwx. 1 root root 0 Dec 10 02:23 subsystem -> ../../../../../class/net -rw-r--r--. 1 root root 4096 Dec 10 02:28 tx_queue_len -r--r--r--. 1 root root 4096 Dec 10 02:23 type -rw-r--r--. 1 root root 4096 Dec 10 02:23 uevent
eth0に対応するハードウェアが、PCIの"0000:00:03.0”であることを確認し、次じそのデバイス情報を参照します。すると下記の通り、”driver -> ../../../bus/pci/drivers/ena”をドライバとして利用していることがわかり、結果eht0はenaであることが確認できます。
$ ll /sys/devices/pci0000\:00/0000\:00\:03.0/ total 0 -rw-r--r--. 1 root root 4096 Dec 10 02:26 broken_parity_status -r--r--r--. 1 root root 4096 Dec 10 02:23 class -rw-r--r--. 1 root root 256 Dec 10 02:23 config -r--r--r--. 1 root root 4096 Dec 10 02:26 consistent_dma_mask_bits -rw-r--r--. 1 root root 4096 Dec 10 02:26 d3cold_allowed -r--r--r--. 1 root root 4096 Dec 10 02:23 device -r--r--r--. 1 root root 4096 Dec 10 02:26 dma_mask_bits lrwxrwxrwx. 1 root root 0 Dec 10 02:23 driver -> ../../../bus/pci/drivers/ena -rw-r--r--. 1 root root 4096 Dec 10 02:26 enable lrwxrwxrwx. 1 root root 0 Dec 10 02:26 firmware_node -> ../../LNXSYSTM:00/device:00/PNP0A03:00/device:1b -r--r--r--. 1 root root 4096 Dec 10 02:26 irq -r--r--r--. 1 root root 4096 Dec 10 02:26 local_cpulist -r--r--r--. 1 root root 4096 Dec 10 02:23 local_cpus -r--r--r--. 1 root root 4096 Dec 10 02:26 modalias -rw-r--r--. 1 root root 4096 Dec 10 02:26 msi_bus drwxr-xr-x. 2 root root 0 Dec 10 02:23 msi_irqs drwxr-xr-x. 3 root root 0 Dec 10 02:23 net -r--r--r--. 1 root root 4096 Dec 10 02:23 numa_node drwxr-xr-x. 2 root root 0 Dec 10 02:26 power --w--w----. 1 root root 4096 Dec 10 02:26 remove --w--w----. 1 root root 4096 Dec 10 02:26 rescan -r--r--r--. 1 root root 4096 Dec 10 02:26 resource -rw-------. 1 root root 16384 Dec 10 02:26 resource0 -rw-r--r--. 1 root root 4096 Dec 10 02:26 rx_copybreak lrwxrwxrwx. 1 root root 0 Dec 10 02:23 subsystem -> ../../../bus/pci -r--r--r--. 1 root root 4096 Dec 10 02:26 subsystem_device -r--r--r--. 1 root root 4096 Dec 10 02:26 subsystem_vendor -rw-r--r--. 1 root root 4096 Dec 10 02:23 uevent -r--r--r--. 1 root root 4096 Dec 10 02:23 vendor
RHUIとredhat社がカスタマーポータルで提供しているrpmパッケージの中身に差異があるのかどうかという話があったので、２つのファイルのdiffをとって確かめてみた。
→結果、差異はなかった。
(1)redhatのカスタマーポータルからISOを落とす
ここから、下記のisoをダウンロード
(2)ISOをループバックマウントして、rpmファイルをリスト化
RHELのサーバにダウンロードしたisoをコピーして、
mkdir dvd sudo mount -o loop rhel-server-7.5-x86_64-dvd.iso dvd find dvd/Packages/ -name '*.rpm' > rpmlist
(3)RHUIから同じrpmをダウンロード
リストを元にyumdownloaderでRHUIからrpmファイルを取得する以下のようなスクリプトを作成
sudo yumdownloader 389-ds-base-1.3.7.5-18.el7.x86_64 sudo yumdownloader 389-ds-base-libs-1.3.7.5-18.el7.x86_64 sudo yumdownloader ElectricFence-2.2.2-39.el7.x86_64 sudo yumdownloader ElectricFence-2.2.2-39.el7.i686 sudo yumdownloader GConf2-3.2.6-8.el7.i686 sudo yumdownloader GConf2-3.2.6-8.el7.x86_64 sudo yumdownloader GeoIP-1.5.0-11.el7.i686 sudo yumdownloader GeoIP-1.5.0-11.el7.x86_64 sudo yumdownloader ImageMagick-c++-6.7.8.9-15.el7_2.i686 sudo yumdownloader ImageMagick-c++-6.7.8.9-15.el7_2.x86_64 sudo yumdownloader ImageMagick-perl-6.7.8.9-15.el7_2.x86_64 以下略
上記スクリプトを適用に分割して、パラレル実行してrpmパッケージをダウンロード
(4)ダウンロードしたファイルをrpmディレクトリに移動
mkdir rpm mv *.rpm rpm
(5)diffで差分があるか確認
for i in $(cat rpmlist);do file=$(basename $i);diff $i rpm/$file;done
rpmパッケージファイルの中身には差分なし
RHELで、yumレポジトリに接続できない環境のRHELを、最新版でない特定バージョンのカーネルにあげたいという話があり検証した結果です。
インターネット接続が可能なVPCのパブリックサブネット状に、コミュニティAMI(RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2 )からインスタンスを作成する。
(a) アップデートしたいカーネルバージョンがRHUIにあるかを確認
sudo yum --showduplicate list kernel
(b) 該当バージョンのパッケージ名称の確認
sudo yum list kernel-3.10.0-862.14.4.el7
sudo yumdownloader --resolve kernel-3.10.0-862.14.4.el7
アップデート対象インスタンスログイン後に、
cat /proc/version Linux version 3.10.0-327.el7.x86_64 (mockbuild@x86-034.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Oct 29 17:29:29 EDT 2015
tar xzf update_packages.tar.gz cd update_packages
sudo rpm -U *.rpm
sudo shutdown -r 0 <再ログイン後> cat /proc/version Linux version 3.10.0-862.14.4.el7.x86_64 (mockbuild@x86-040.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Sep 21 09:07:21 UTC 2018
今日Re:Inventで発表されたA1インスタンスのcpuinfoとかを見てみますた。
こちらのインスタンスの特徴は、AWS Graviton ProcessorsというAWS謹製のARMプロセッサを利用し、低消費電力
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.77-81.59.amzn2.aarch64 (mockbuild@ip-10-0-3-22) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Mon Nov 12 21:28:57 UTC 2018 [ 0.000000] Boot CPU: AArch64 Processor [410fd083]
AArch64 Processorとあって、まあ”ARM 64bit”てことがわかりますね。当たり前ですが。
[ec2-user@ip-172-31-27-144 ~]$ cat /proc/cpuinfo processor : 0 BogoMIPS : 166.66 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 以下略
ここで注目すべきは"CPU part : 0xd08"。ARM社のページ情報によると、こちらは"Cortex-A72 processor”の設計を利用していることがわかります。"Cortex-A72 processor"は、こちらのwikipediaページによると" ARMv8-A 64-bit instruction set designed by ARM Holdings. "とあるので、ARMが設計した64bit ARM(ARMv8-A 64-bit instruction set)のプロセッサをベースとしていそうですね。
"Cortex-A72 processor”は、2015年にARMが発表した64bitのARMのCPU コア IP で、Android携帯のCPUで有名な Qualcomm, Inc.のSnapdragon(Snapdragon 650)で利用されてたりします。 こちらをみると、Xperiaの一部機種で採用されているようで、スマートホンのCPUがサーバに入っていると考えると、オッ！！と思いますよね。
