GitHubにはデプロイキーがあって、こいつがあれば、特定のレポジトリをpullできたりcloneできたりするわけですが、こいつの管理ってみんなどうしてるんでしょうか?
例えば退職者とか、悪意がある人がいたとして、デプロイキーとレポジトリのURIさえ知っていれば、レポジトリを社外に持ち出せてしまうわけですよね?
定期的にデプロイキーを更新するという手もあるかと思います。ただ、そればベストとは思えなくてどうしたらうまく回るのかなと迷い中の今日この頃。
熱心に調べてたことが、"""現在"""の問題を一切解決しないと気がついて落胆してる。
— masasuzu 🍶🐫 (@masasuz) November 9, 2017
現実逃避して付箋で紙飛行機作ってた。復活した。
1年前とか2年前はわりかしブログとかTwitterでも技術系のことを書いていたのに、ここ最近ほぼ書かなくなった。勉強会とかも参加しなくなった。
これは、別の趣味に時間とお金を取られていたのが大きなところではある。ただ、エンジニアリングに対するモチベーションが下がっていたからこそ別の趣味に力を入れていたという側面もある。
こうして、(エンジニア的には)怠惰に1年過ごしたわけだが、ここで得たものは焦燥感しかない。技術的成長がほぼなかった(実感として)、新しめやトレンドの技術をほぼキャッチアップできてないそういう状況が目に見えて分かってきたのである。
1年のビハインドどうやって取り戻すか。これから考えているところ。少なくともこれ以上停滞するとエンジニア的には死しかない。
この焦燥感をバネに動くのは今しか無い。これはそういう決意表明的なメモです。
CloudWatch logsの時間表示UTCでちょっとつらいなーって思ってたけど、期間設定の1番右端の"カスタム"のタブからlocaltimeに変更できることを今気がついた。 pic.twitter.com/58KOVVxkcm
— masasuzu 🍶🐫 (@masasuz) March 15, 2017
こんなところにあった。。。 気がつかないよ。。。。
久しぶりにブログ書くな。
上記記事、これあんまりよくなくて、Ubuntu的にはこう変えるのが良い。
UbuntuTime - Community Help Wiki
echo "Asia/Tokyo" > /etc/timezone dpkg-reconfigure --frontend noninteractive tzdata
ただ、Ubuntu 16.04だとこれうまく変わってくれないので timedatectl
を使ってあげる必要がある。
timedatectl set-timezone Asia/Tokyo
こんな感じですね。
root@lab:~# timedatectl status Local time: Thu 2017-02-09 14:42:40 JST Universal time: Thu 2017-02-09 05:42:40 UTC RTC time: Thu 2017-02-09 05:42:40 Time zone: Asia/Tokyo (JST, +0900) Network time on: yes NTP synchronized: yes RTC in local TZ: no root@lab:~# timedatectl set-timezone Australia/Adelaide root@lab:~# timedatectl status Local time: Thu 2017-02-09 16:12:44 ACDT Universal time: Thu 2017-02-09 05:42:44 UTC RTC time: Thu 2017-02-09 05:42:44 Time zone: Australia/Adelaide (ACDT, +1030) Network time on: yes NTP synchronized: yes RTC in local TZ: no root@lab:~# timedatectl set-timezone Asia/Tokyo root@lab:~# timedatectl status Local time: Thu 2017-02-09 14:42:54 JST Universal time: Thu 2017-02-09 05:42:54 UTC RTC time: Thu 2017-02-09 05:42:54 Time zone: Asia/Tokyo (JST, +0900) Network time on: yes NTP synchronized: yes RTC in local TZ: no
MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.1.2.1 パスワードセキュリティーのためのエンドユーザーガイドライン
ここの通りなんだけど。
簡単だけど、セキュアじゃないですね。コマンドラインヒストリーに残る場合もあるし。
-p
の後にスペースを入れないのがポイント
mysql -u USER -pPASSWORD
一般的な方法ですね。
mysql -u USER -p
~/.my.cnf
を作っておくとそこから設定を読み取ってくれます。パスワード情報は他のユーザから読み取られないようにパーミッションを気を付けておくと良いでしょう。
(でも平文のパスワードをファイルで保存するのは良い手ではないです。
cat > ~/.my.cnf <<... [client] user=USER password=PASSWORD ... chmod 600 .my.cnf mysql
この方法はpsコマンドでパスワードが他のユーザから見られてしまう可能性があるので基本的には使ってはいけません。
MYSQL_PWD=PASSWORD mysql -u USER
MySQLのエラーログを見てるとこんなこと言われるのですが、
2016-06-09T06:53:07.219882Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5010) 2016-06-09T06:53:07.219948Z 0 [Warning] Changed limits: max_connections: 214 (requested 1000) 2016-06-09T06:53:07.219954Z 0 [Warning] Changed limits: table_open_cache: 400 (requested 2000)
そんなときは、/lib/systemd/system/mysql.service
のservice
セクションにLimitNOFILE=65535
を足してあげて、下記の様に再起動してあげると良いです。
systemctl daemon-reload systemctl restart mysql
しかし、このwarnins、log_timestamps = system
ってmy.cnf
に入れておいてもUTCでタイムスタンプ出力するんですよね。。。。
Ubuntu16.04で入るMySQL5.7の設定ファイルがこんな感じになってるんですが、 どういう意図なんでしょうね?
MySQL的には読み込むファイルは/etc/mysql/my.cnf
だけど、Ubuntu開発チーム的には/etc/mysql/mysql.cnf
がいじって欲しいファイルってことなんですかね?
# ls -l /etc/mysql/my.cnf lrwxrwxrwx 1 root root 24 Jun 2 16:13 /etc/mysql/my.cnf -> /etc/alternatives/my.cnf # ls -l /etc/alternatives/my.cnf lrwxrwxrwx 1 root root 20 Jun 2 16:13 /etc/alternatives/my.cnf -> /etc/mysql/mysql.cnf # ls -l /etc/mysql/mysql.cnf -rw-r--r-- 1 root root 682 Apr 20 19:04 /etc/mysql/mysql.cnf
中身的にはこうなってるので、includeディレクトリをいじるのが素直だと思います。
!includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mysql.conf.d/