GMOペパボを退職しました

2015年から4年間努めたGMOペパボ株式会社を2019年8月いっぱいで退職しました。やってきたことはだいたい以下にまとめてあります。2019年からはシニアエンジニアとして主にサービスのセキュリティ周りの強化をしていました。

kimromi.hatenablog.jp

4年間たくさんのことを経験させていただき社会人としても大きく成長することができ、本当に感謝の気持ちで一杯です。退職の理由などは在職中や送別会でお話したのでここには書きません。

これまでの社会人経験の中で一番実のある時間が過ごせたのではないかと思います。送別の際もあたたかく送り出していただき、たくさんの贈り物も頂戴したりととてもよい送別経験（？）ができました。ありがとうございました。

人生初の次の会社に行く前の有給消化を経験し8月はゆっくり過ごすことができました。ほぼ家族と一緒に過ごしてのんびりしたり科学館やプールなどいろいろ行ったりしながらリフレッシュしました。9月からの新しい職場でスポンジのように吸収していくために頭の中をスッキリさせることができてとてもよい時間を過ごすことができました。

2019年9月から株式会社マネーフォワードの九州・沖縄支社（福岡）でフロントエンドエンジニアとして再出発します。フロントエンドエンジニアは初めてというか、今までフルスタックエンジニアのような動きをしてきて、職種に特化して仕事をしたことがなかったのでとても楽しみです。福岡拠点はまだまだ発展途上で、これからどんどん変革していきそうな雰囲気を感じているので、これまでの経験を活かして役に立つ動きができるように精進していきます。

ということであれです。
https://amzn.to/2UocjYB

DNSのTXTレコードに自己紹介を書いてみる

おもしろ自己紹介ができたので、ぜひコマンドを叩いてみてください。

% dig kimromi.me TXT +short
"Work=Muumuu-domain.com at GMO Pepabo Inc."
"GitHub=@kimromi"
"Twitter=@kimromi"
"Blog=http://kimromi.hatenablog.jp/"

(追記)
もし別の目的ですでにTXTレコードを使っていたら introduction.kimromi.me などのサブドメイン使ってやるのがいいかもしれません👌

TXTレコード (テキストレコード)

AやMXのような特定の用途などはなく、ドメインに関する様々な付帯情報を自由に持つことができます。よく見るものとしては、メールを使う場合に送信元ドメインのIPアドレスを保証するために利用するSPFや、SSL証明書発行の際にドメインの管理者かどうかを発行者が確かめるためにTXTレコードに指定された文字列を入れることで認証したりするときに使います。

このTXTレコードに入れられる文字列はどんなものなのか気になったのでRFCを覗いてみました。

RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes

一般的に用いられる書式は以下のような書式です。

"<属性名>=<属性値>"

ダブルクオートで囲まれた文字列で、属性名と属性値を=(等号)でつないだ形です。

属性名 - Attribute Names

• ASCII印字可能文字(後述)を指定することができる
• Attribute Nameに=(等号)が入る場合はグレイヴ・アクセント記号またはバッククオートを前におくことで利用できる
• 大文字小文字は区別されない
• DNSレコードの検索時、"(ダブルクオート)で囲まれておらず、=(等号)も含まれないレコードは無視される
• 空の属性名の場合も無視される
• 前後のスペースは無視される
  • しかしバッククオートでエスケープしたときは別

   Attribute Names

   Any printable ASCII character is permitted for the attribute name.
   If an equals sign is embedded in the attribute name, it must be
   quoted with a preceding grave accent (or backquote: "`").  A
   backquote must also be quoted with an additional "`".

   Attribute Name Matching Rules

   The attribute name is considered case-insensitive.  For example, a
   lookup of the attribute "Favorite Drink" would match a TXT record
   containing "favorite drink=Earl Grey tea".

   During lookups, TXT records that do not contain an unquoted "=" are
   ignored.  TXT records that seem to contain a null attribute name,
   that is, the TXT-DATA starts with the character "=", are also
   ignored.

   Leading and trailing whitespace (spaces and tabs) in the attribute
   name are ignored unless they are quoted (with a "`").  For example,
   "abc" matches " abc<tab>" but does not match "` abc".

   Note that most DNS server implementations require a backslash (\) or
   double quote (") in a text string to be quoted with a preceding
   backslash.  Accent grave ("`") was chosen as a quoting character in
   this syntax to avoid confusion with "\" (and remove the need for
   confusing strings that include sequences like "\\\\").

属性名 - Attribute Values

• ASCII印字可能文字を入れることができる
• 最初の=がNameとValueのデリミタになる
  • Vaule内は=もバッククオートでエスケープする必要はない

   All printable ASCII characters are permitted in the attribute value.
   No characters need to be quoted with a "`".  In other words, the
   first unquoted equals sign in the TXT record is the name/value
   delimiter.  All subsequent characters are part of the value.

   Once again, note that in most implementations the backslash character
   is an active quoting character (and must, itself, be quoted).

ASCII印字可能文字 (printable characters)

ASCII - Wikipedia

ASCII 32〜126(0x20〜0x7E)までの文字です。

• 半角スペース
• 0〜9
• a〜z
• A〜Z
• !"#$%&'()*+,-./:;<=>?@[]^_`{|}~

例

Name	Value	TXTレコード
color	blue	"color=blue"
equation	a=4	"equation=a=4"
a=a	true	"a`=a=true"
a\=a	false	"a\\`=a=false"
=	\=	"`==\\="
string	"Cat"	"string=\"Cat\""
string2	`abc`	"string2=``abc``"
novalue		"novalue="
a b	c d	"a b=c d"
abc	123	"abc` =123 "

文字数制限

文字数制限に関しては特に記述はなく各DNSの実装によって様々なようです。

参考URL

• RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes
• ASCII - Wikipedia

TXTレコードに自己紹介を書きたくなってみたくなった方はムームードメインで！w

muumuu-domain.com

MySQLでCREATE TRIGGERができなかったので調べてみた

You do not have the SUPER privilege and binary logging is enabled 
(you *might* want to use the less safe log_bin_trust_function_creators variable)

というエラーが出ていて CREATE TRIGGER ができなかった。

結論から言うと、 CREATE TRIGGER などのストアドファンクションの作成、変更はバイナリログが有効な環境の場合にSUPER権限が必要であるが、CREATE TRIGGERを実行しようとするユーザーがSUPER権限を持っていないということだった(エラーメッセージそのままだけど)。

以下の方法で解決できることがわかった。

• DBに接続するユーザーにSUPER権限をもたせる
• log_bin_trust_function_creatorsというグローバルパラメータを1にする

👉SUPER権限でできること(MySQL5.6)

• CHANGE MASTER TO
  • スレーブがマスターに接続する設定をする構文
• KILL または mysqladmin kill コマンド
  • 実行中のクエリを強制終了させる構文
• PURGE BINARY LOGS
  • バイナリログを削除する構文
• SET GLOBAL
  • システムのグローバル設定を変更する構文
• mysqladmin debug コマンド
• ロギングの有効化または無効化
• read_only システム変数が有効な場合の更新の実行
• max_connectionsに接続数が達しても1つの接続を受け入れる
• スレーブサーバー上でのレプリケーションの開始と停止
• バイナリロギングが有効な場合のストアドファンクション作成、変更の権限

またSUPER権限はグローバル権限であるため、システム全体に影響を及ぼすことができる権限である。安易にSUPER権限をもたせてしまうと様々な管理者用の機能を利用できてしまうため危険。ちなみにあるデータベースやテーブルのみのSUPER権限は存在しない。

👉log_bin_trust_function_creators パラメータ

MySQL :: MySQL 5.6 リファレンスマニュアル :: 20.7 ストアドプログラムのバイナリロギング を参考。

ストアドファンクションを利用するための条件は以下。

• CREATE ROUTINE または ALTER ROUTINE権限以外に、SUPER権限が必要
• CREATE FUNCTIONの際は DETERMINISTIC 、 NO SQL または READS SQL DATA の少なくとも 1 つを明示的に指定する必要
  • ファンクションの実行によるデータの変更が確定的である、またはデータを変更しないということを明示
  • 例えば関数内でUUID()などを利用すると実行のたびに結果が違うためレプリケーション時にマスターとスレーブの整合性がとれなくなる
  • ちなみにTRIGGERはDETERMINISTICであるため構文に指定する必要はないが、UUID()などは注意が必要

そして、上記を緩和するためにlog_bin_trust_function_creators パラメータを1にすることでストアドファンクションを作成、変更することができるようになる。しかし上記のようなレプリケーションの整合性の問題を理解し危険がないということを確認の上、設定することが必要ということだった。

その他参考URL

• MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.2.1 MySQL で提供される権限
• MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.4.2.1 CHANGE MASTER TO 構文
• MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.6.4 KILL 構文
• MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.4.1.1 PURGE BINARY LOGS 構文
• MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.1.5 システム変数の使用
• MySQL ストアドプログラムのバイナリロギング メモ - blog @kimromi

このあたり理解していくとMySQLにもっと踏み込めていけそうだ〜。