みなさんRSS使ってますか?
私は4、5年くらい前に一度使ってたんですが、当時はあまり管理するサイトが多くなかったからか、時間が有り余ってたからなのか分からないですが、いつの間にか使わなくなっていました。
今回はRSSを使って毎日のルーチンワークを効率化できたのでそれについて簡単に書きます。RSSって書いてますけど、atomやxmlフィード全般を差します。
RSSのクライアントはfeedlyとLeafを選びました。
みなさんRSS使ってますか?
私は4、5年くらい前に一度使ってたんですが、当時はあまり管理するサイトが多くなかったからか、時間が有り余ってたからなのか分からないですが、いつの間にか使わなくなっていました。
今回はRSSを使って毎日のルーチンワークを効率化できたのでそれについて簡単に書きます。RSSって書いてますけど、atomやxmlフィード全般を差します。
RSSのクライアントはfeedlyとLeafを選びました。
Vagrantは基本的にVirtualBoxみたいな仮想化ソフトウェアをローカルにインストールして使っている人が多いと思いますが、この仮想化ソフトウェアのことをプロバイダと呼びます。Vagrant AWS Providorプラグインを使うことにより、AWS EC2をプロバイダとして使うことができます。
結構あちこちで解説されているネタでもあるので備忘録的なsomethingとして軽く流します。
なお、AWSについての知識も少なからず必要になるので、事前にVPCとEC2を触って知識をつけてから試すことをおすすめします。
以下の環境が既にインストール済み
– Mac OS X El Capitan 10.11.3
– Vagrant 1.7.4
先週はソリューションアーキテクトになったのですが、目標としてた試験をクリアしてしまうと更に高みを狙いたくなってしまうもの。他のAWS認定資格も集めたくなって、挑戦してみました。
めっちゃハマったのでメモ。環境は Mac El Capitan (10.11.3) 。
周りの人はすんなりインストールできてたりするので、どうしてこうなったのか原因が分からないのだが、うまく抜け出せたので書き留めておきたい。
Macなら初めからpythonが入ってるから2コマンドでいける……らしい。
|
1 2 |
$ sudo easy_install pip $ sudo pip install awscli |
普通ならこれだけでインストールできる。
1行目でpythonパッケージマネージャーのpipを入れて、2行目でawscliをインストール。
これがエラーなく完了すればいいけど、手元の環境ではなぜか2行目でコケてしまった。
こうなった。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ sudo pip install awscli Collecting awscli (略) nstalling collected packages: six, python-dateutil, docutils, botocore, pyasn1, rsa, colorama, awscli Found existing installation: six 1.4.1 DEPRECATION: Uninstalling a distutils installed project (six) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project. Uninstalling six-1.4.1: Exception: Traceback (most recent call last): File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/basecommand.py", line 209, in main status = self.run(options, args) (略) OSError: [Errno 1] Operation not permitted: '/tmp/pip-danB96-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six-1.4.1-py2.7.egg-info' |
よく見るとDeprecatedなSixっていうパッケージをアンインストールしようとしてエラーになってるぽくて、
手動で sudo pip uninstall six ってやっても同じエラーが出てしまう。
|
1 2 3 |
$ sudo -H pip install awscli --upgrade --ignore-installed six (略) Successfully installed awscli-1.10.1 botocore-1.3.23 colorama-0.3.3 docutils-0.12 jmespath-0.9.0 pyasn1-0.1.9 python-dateutil-1.5 rsa-3.3 six-1.4.1 |
うまくいった!
ちなみにSixっていうのはpython2系と3系の差異を埋めてくれるユーティリティライブラリみたいなものらしい。やっぱり自分で入れた覚えはなくてちょっと謎。
AWS ELBに証明書を登録しようとしたときにエラーになったので、その回避策をメモ。
AWS ELBではHTTPSで行われた通信をELBデコードして、バックエンドのサーバーとはHTTPで通信することができます。
こうしておくと証明書更新などで複数台のEC2を直接手を入れることなく、またウェブサーバー側のSSL通信に関わるオーバーヘッドも無くなるため、AWS内で構築する場合には採用することが多いかと思います。
この構成を取る場合、証明書、証明書の秘密鍵をELBにアップロードする必要があります。
軽い内容だけど備忘録として。
要はRDSのMySQLでは、プロセスを殺すためのKILLが使えないよーっておはなし。
例えばSleepプロセスを、root以外の管理ユーザーから殺したいと思ってKILLコマンドを許可する SUPER 権限をそのユーザーに与えたかったのだけど、それができない。
|
1 2 |
mysql> GRANT SUPER ON *.* TO `admin`@`%`; ERROR 1045 (28000): Access denied for user 'root'@'%' (using password: YES) |
今の設定がどうなってるか確認してみると、そもそもroot(※インスタンス起動時に登録したマスターユーザー)にSUPER権限が与えられていない。
|
1 2 3 4 5 6 7 8 |
mysql> SELECT User, Host, Process_priv, Super_priv FROM user; |----------+-----------+--------------+------------+ | User | Host | Process_priv | Super_priv | +----------+-----------+--------------+------------+ | rdsadmin | localhost | Y | Y | | root | % | Y | N | | admin | % | Y | N | +----------+-----------+--------------|------------+ |
試しに他のユーザーのプロセスをKILLしてみる
|
1 2 |
mysql> KILL 751914; ERROR 1095 (HY000): You are not owner of thread 751914 |
やっぱりダメぽい…。
AWS公式のドキュメントでこんなのを見つけた。
mysql.rds_kill – Amazon Relational Database Service
どうやらKILLが使えない代替策で mysql.rds_kill を使えってことらしい。
|
1 2 |
mysql> CALL mysql.rds_kill(751914); Query OK, 0 rows affected (0.00 sec) |
うまくいった。
これを一般ユーザーで使えるようにするためには、一般的なストアドプロシージャの許可と同じようにする。
|
1 2 |
mysql> GRANT Execute ON PROCEDURE `mysql`.`rds_kill` TO `admin`@`%`; mysql> FLUSH PRIVILEGES; |
上表のユーザーリストで rdsadmin となっているのはAWSがRDSインスタンスの監視に使うユーザーであり、私たちはログインできない。
推測になるが、これらRDS管理系のシステム仕様上SUPER権限はユーザーに与えられていないのだろう。そういった類の特権処理について、AWS側の制約により実行できないものは別途ストアドプロシージャが提供されていて、これを介して使うことができるようだ。
それらのストアドプロシージャーはこのRDSのリファレンスページに纏められている。
シェルからKILLを流し込むスクリプトなど、他の環境で使っていたものを流用するときは十分注意したいです。こういった制約とその代替策がいかにもAWSらしいような、そんな気がします。
以前から挑戦したかったAWSの課題のひとつを解決してみようと思います。
AWS EC2やRDSなどのステータスを監視してアラームを上げてくれる、大変便利なCloudWatchですが、管理コンソール以外からアラームを確認する方法としては、SNSトピックに通知した後に自分でSNS連携のアプリケーションを作るなどして対応する必要がありました。
今回はこのアラームを、Slackの任意のチャンネルにポストすることをゴールにしてみます。
gitについて話すときにこの記事をたたき台にしたい。はじめてgitに触れる人の理解の助けになれば。
個別のgitコマンドについては、「頻出gitコマンド入門」で紹介しているのでリファレンス的に使ってください。ここでで紹介しているコマンドに関してはさらっと流して、できるだけシンプルに。
最近、gitの使い方を人に説明することが多くなってきたので、頻出コマンドの使い方をリファレンス的に纏めておこうと思います。
なお、対象読者はgithubを用いてチーム開発をしているプログラマーです。
一人で開発するのであれば、例えばリモートサーバーへのpushやpullなどは無視してよいでしょう。
応用的なコマンドは分量を考えてまた別の記事にするかもしれません。適当にアップデートしていきます。