kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

CORSの理解が不足していたのでメモ

CORSって何?

CORS: Cross-Origin Resource Sharing

オリジン間リソース共有

オリジンって何?

同じところからのリクエストであるかを判別するための方法

URIの、scheme、host、portが一致していると、それは「同一オリジン」である

scheme、host、portとか、URIの呼称については、こちらを参照

kasei-san.hatenadiary.org

どういう時に使うの?

異なるオリジンにAjaxリクエストやWebフォントの読み込みを行う際に使われる

なんで必要なの?

悪意あるサイトがAjaxで勝手にどこかAPIを叩けないよう、同一オリジン以外へのリクエストはブロックされるようになっている

  • これを、Same Origin Policy(同一オリジンポリシー) と呼ぶ

ただし、異なるオリジンにリクエストを投げる必要もあるため、CORS という仕組みが生まれた

どういう風にやるの?

単純リクエストという方式の場合、以下のような流れ

  1. ブラウザ側からリクエスト。リクエストヘッダの中に Origin が含まれる
    • Origin は、リクエストの発生元がどこであるかを示す
  2. サーバ側からレスポンス。レスポンスヘッダの中に Access-Control-Allow-Origin が含まれる
    • Access-Control-Allow-Origin はサーバが許可するオリジンを入れる
    • * の場合は「すべて許可」となるが、非常に脆弱なのでやめるべき
    • 複数の値を含めることはできない。許可すべきオリジンが複数ある場合は、サーバ側で制御する
  3. ブラウザ側で OriginAccess-Control-Allow-Origin が一致していれば、処理が行われる

プリフライトリクエスト

クロスオリジンのリクエストが いろいろな条件を満たさなかった場合、上記の単純リクエストではなく、プリフライトリクエストが行われる

ユーザーデータに影響を与える可能性があるようなリクエストの場合、プリフライトが行われる(らしい)

プリフライトリクエストの流れ

OPTIONS メソッドをつかって、事前に安全にクロスオリジンの通信が行えるかチェックする

以下のような流れ

  1. ブラウザ側で、 OPTIONS メソッドで以下のリクエストを投げる
    • Origin : 単純リクエストと同じ
    • Access-Control-Request-Method : 送るメソッド
    • Access-Control-Request-Headers : 送るリクエストヘッダ
  2. サーバ側からレスポンスを投げる。その時、以下のレスポンスヘッダを含む
    • Access-Control-Allow-Origin : 単純リクエストと同じ
    • Access-Control-Allow-Methods : 許可するメソッド
    • Access-Control-Allow-Headers : 許可するリクエストヘッダ
    • Access-Control-Max-Age: プリフライトリクエストの結果をキャッシュして良い時間(秒)
  3. ブラウザ側でレスポンスヘッダを読み込んで、問題なさそうならば実際のリクエストを開始する

資格情報を含むリクエスト

標準では cookie や basic 認証を含むリクエストに関わる情報は送信されない

そのためには、JavaScript 側で withCredentials というオプションを true にする必要がある

さらに、cookie の情報をやり取りしたい場合は、レスポンスヘッダに Access-Control-Allow-Credentials: true をつけて、許可する必要がある

また、Set-Cookie については、サードパーティCookieと同じく、ドメインが異なるとブラウザの設定によっては読み込めない

あと、 資格情報を含むリクエストの場合 Access-Control-Allow-Origin* は使えない

参考

yamory.io

developer.mozilla.org

Amazon Linux2 に MySQL5.7のクライアントを入れる方法

踏み台サーバに手動で入れる必要が出たので個人的なメモ

参考

dev.mysql.com

dev.classmethod.jp

だいたいここの通りにやればOK

前提1

Amazon Linuxでは、いくつかのパッケージを Extras Library として提供しているが、MySQLは提供していない(mariadbはある)

  • コマンド amazon-linux-extras で提供しているパッケージを確認可能

前提2

80番ポートを開ける必要がある

  • 443だけでやろうとしてめっちゃ苦労して、あきらめた

MySQLのリポジトリのrpmをインストール

sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
  • localinstall は、rpm を yum でインストールするコマンド。 rpm -i と異なり、依存関係がある場合、その rpm もインストールしてくれる
  • Amazon Linux 2 は、RHEL7ベースという噂なので、RHEL7のMySQLのリポジトリをインストール
  • ダウンロード先のURLは、こちら で、「Download」を選択した後に「 No thanks, just start my download.」のリンクを見れば確認可能

リポジトリがインストールされたことを確認

yum repolist enabled | grep "mysql.*-community.*"

デフォルトでは、MySQL8がインストールされてしまうので設定を変更

$ yum repolist enabled | grep "mysql.*-community.*"
mysql-connectors-community/x86_64     MySQL Connectors Community          194
mysql-tools-community/x86_64          MySQL Tools Community               126
mysql80-community/x86_64              MySQL 8.0 Community Server          247
sudo yum-config-manager --disable mysql80-community
sudo yum-config-manager --enable mysql57-community

確認

$ yum repolist enabled | grep mysql
mysql-connectors-community/x86_64     MySQL Connectors Community          194
mysql-tools-community/x86_64          MySQL Tools Community               126
mysql57-community/x86_64              MySQL 5.7 Community Server          504

インストール

sudo yum install -y mysql-community-client

無事インストールされました

$ mysql --version
mysql  Ver 14.14 Distrib 5.7.34, for Linux (x86_64) using  EditLine wrapper

logrotateおぼえがき

RHEL系のお話です

全体設定ファイル

/etc/logrotate.conf

ローテーションごとの設定ファイルが置かれるディレクトリ

/etc/logrotate.d/

dryrun

/usr/sbin/logrotate -dv /etc/logrotate.conf

手動実行(root権限で実行すること)

/usr/sbin/logrotate -f /etc/logrotate.conf

最終ローテーション日時が格納されているファイル

/var/lib/logrotate.status

手動実行の流れ

1日1回ローテーションしていて、すでに本日実行済の場合

  • すでにあるローテーション済のファイルをrenameする
  • /var/lib/logrotate.status にある最終実行日を昨日の日付に変更する
  • /usr/sbin/logrotate -dv /etc/logrotate.conf して実行されるか確認
  • 問題なければ、 /usr/sbin/logrotate -f /etc/logrotate.conf で手動実行

手動実行でエラーがでたとき

ローテーション実行時のスクリプトの戻り値が0以外だとエラーになる

なので例えば、最後に実行したコマンドが test コマンドで、testの結果が「偽」の場合、exit 1 になるのでエラーとなってしまう

  • lastaction の実行結果ならば、ローテーション自体は完了している

参考

kotaroito.hatenablog.com

NATインスタンスとNATゲートウェイの料金比較メモ

料金の内訳

  • NATインスタンス
  • NATゲートウェイ
    • NAT ゲートウェイの時間単位料金
      • 東京リージョンで 0.062USD/1hour
    • NAT ゲートウェイのデータ処理料金(in/out問わず
      • 東京リージョンで 0.062USD/1GB
    • データ転送料金(NATインスタンスと同様

NATゲートウェイの料金については、くわしくはこちら

aws.amazon.com

金額的にはどのくらい差が出るの?

NATの上をどれだけデータが通るか次第なので、実測しないといけない

NATの上にどれだけデータが通るかはどうやって調べるの?

コストエクスプローラーから、インスタンスを絞り込んで、使用タイプグループ:EC2: Data Transfer – Internet (Out) EC2: Data Transfer – Internet (In) で絞り込めばわかる

くわしくはこちら

hacknote.jp

実際のところNATゲートウェイにした方が良い?

運用コストがゼロになるので、よっぽどのことがなければしたほうか良い

  • NATインスタンスのセキュリティアップデートとか、スケールアウトとか考えなくて良くなるし

Railsのメンテナンスポリシーおぼえがき

2021/01/12 現在

基本的にはここ見ればOKです

guides.rubyonrails.org

ポイント

  • Railsはセマンティックバージョニング
  • バグ修正は最新バージョンのみ (2021/01/12 現在、 6.1.Z )
  • セキュリティFIXは、メジャーシリーズ全てと、1つ前のメジャーの一番最後のマイナーリリースに適用
    • 2021/01/12 現在、 6.1.Z6.0.Z5.2.Z

Linuxの時計まわりのおぼえがき

対象OS

設定ファイル周りについては、Amazon Linux AMI や CentOS6系以前のお話

ただし、クロックそのもの話は各Linuxでもだいたいおんなじなはず

クロック周りのはなし

時計。Linuxは2種類のクロックをもつ

  • ハードウェアクロック
  • システムクロック

ハードウェアクロック

RTC(リアルタイムクロック)とも呼ばれる。マザーボードが持つ物理的な時計

ボタン電池で電力供給され、電源OFF時にも時刻が維持され続ける

システムクロック

OSのソフトウェアで管理するクロック

OS起動時に、ハードウェアクロックの値を元に設定される

1970年01月01日00時00分00秒 からの経過秒数(UNIX時間) の形式で管理されている

インターバルタイマー

マザーボードの機能の1つ。定期的に割り込みをかけて、システムクロックの時刻を進める

タイムゾーン周りの話

用語

  • UTC: 世界標準時
  • タイムゾーン: 地球上で同一の標準時を採用している地域の集合。UTC±時差 で表記される。日本標準時ならば UTC+9
  • ローカルタイム: タイムゾーンで示される現地時刻

Linuxでのタイムゾーンの設定方法

/usr/share/zoneinfo に各タイムゾーンの設定ファイルが格納されている

  • 東京ならば、 /usr/share/zoneinfo/Asia/Tokyo

/etc/localtime に上記のタイムゾーンの設定ファイルと同様のものをおけば、それがシステムのタイムゾーンとなる

ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

date コマンドなどの時刻を表示するコマンドは、/etc/localtime の設定を見て、システムクロックからローカルタイムを計算する

ハードウェアクロックのタイムゾーン

ハードウェアクロック自体はタイムゾーンを持たないが、ハードウェアクロックの値の解釈を設定することが可能

/etc/sysconfig/clock で設定可能

ZONE="Asia/Tokyo"
UTC=true
  • UTC: ハードウェアクロックの値の解釈
    • true : UTCとして解釈する
    • true : ローカルタイムとして解釈する
  • ZONE: /etc/localtime の参照元を設定

マシンを再起動したり、glibcのupdateなどで /etc/localtime の参照元は、ZONEで指定した値に置きかわる

参考

park12.wakwak.com

www.atmarkit.co.jp

Amazon Linux AMI でのタイムゾーンの変更方法

Amazon Linux AMI でのタイムゾーンの変更方法

先に結論

/etc/localtime だけを変更しても、マシンの再起動やglibcの更新でタイムゾーンがUTCに戻る

そうならないために、 /etc/sysconfig/clock の設定も必要

手順

公式ドキュメントを参照

docs.aws.amazon.com

/etc/sysconfig/clock

タイムゾーンを "Asia/Tokyo" に変える場合

ZONE="Asia/Tokyo"
UTC=true

/etc/localtime

sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

その後、各アプリのタイムゾーンの認識を更新するために、マシンの再起動を行う

reboot now