jupyter notebookをバックグラウンドで起動する

普段のPythonプログラミングには、jupyter notebook を使用しています。
AWSのサーバーに立てたnotebookを使っている時は良いのですが、
ローカルのMacで動かしている時は
ターミナルを立ち上げっぱなしにしておかないといけないので少し不便です。

そこで、jupyterをバックグラウンドで動かすようにします。
利用するのは nohupコマンドです。
頻繁に使用するので、下記のような内容でスクリプト化しておくと便利です。


#!/usr/bin/env bash
nohup jupyter notebook >> jupyter.log 2>&1 &

これを実行すると、notebookが立ち上がり、しかも端末を切っても動き続けます。

Simple Mathjax を導入

現状、ブログ構築やMacの環境構築関係の記事ばかりですが、近々データサイエンス関係の記事を増やしたいので、
このブログに数式を入れられるようにしておく必要があります。
ということで、Simple Mathjax というプラグインを追加しました。
これで記事中でTeXによる数式が書けるはずです。

インラインの場合は\$マークで囲めば良いそうです。たとえば、三角関数の公式であれば、$\tan\theta=\frac{\sin\theta}{\cos\theta}$と表示できます。

\$\$で囲むことによってブロック表示になります。
活性化関数としてよく使われる、ReLUを書いてみましょう。

$ReLU(x) = \max(0,x) =\left\{\begin{array}{ll} 0 & (x<0) \\ x & (x\geq0) \end{array}\right.$

pyenvにより発生するようになったHomebrewのWarningに対応する

以前対処した時のメモがあるので記事化しておきます。

Macにpyenvをインストールすると、brew doctorでwarningが出るようになります。

yutaro の部分はそれぞれの環境のユーザー名で読み替えてください。


$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
  /Users/yutaro/.pyenv/shims/icu-config
  /Users/yutaro/.pyenv/shims/libpng16-config
  /Users/yutaro/.pyenv/shims/python3.7-config
  /Users/yutaro/.pyenv/shims/python3.7m-config
  /Users/yutaro/.pyenv/shims/python-config
  /Users/yutaro/.pyenv/shims/python3-config
  /Users/yutaro/.pyenv/shims/ncursesw6-config
  /Users/yutaro/.pyenv/shims/pcre-config

要するに、 PATH の中に、 Homebrewが知らない -config ファイルがあると文句を言っています。
環境変数のPATHを確認すると、.pyenv/shims: が追加されているのでこれが問題です。


$ echo $PATH
/Users/yutaro/.pyenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

対応としては、brewコマンドを実行する時だけ、PATHから、 .pyenvディレクトリを外します。
.bash_profileを開いて、下記のエイリアスを追加します。


alias brew="env PATH=${PATH/\/Users\/yutaro\/\.pyenv\/shims:/} brew"

ターミナルを再起動して、結果が反映されていることを確認します。


$ brew doctor
Your system is ready to brew.

Macにpyenvとanacondaをインストールする

Mac book Pro のOSをMojave にアップデートして以来、Homebrew関係の環境がおかしくなってしまっているので、最近環境を作り直しています。
その一環でpyenvも入れ直したので記事にしておきます。

まず前提として、pythonには2系と3系があり、macに標準で入っているのは 2系です。


$ python --version
Python 2.7.10

これはOSも使っているそうで、直接このpythonのバージョンをあげるのは良くないこととされているので、
pyenvというツールを使って、独立した環境に3系のpythonを入れます。
また、機械学習等に使うのが目的なので、便利なライブラリが同梱されたディストリビューションである、
Anacondaを使います。

pyenvの導入手順は リポジトリのReadmeの該当箇所を参考に、以下のコマンドを順に実行します。


$ brew update
$ brew install pyenv
$ echo -e 'if command -v pyenv 1>/dev/null 2>&1; then\n  eval "$(pyenv init -)"\nfi' >> ~/.bash_profile
$ exec "$SHELL"

.bash_profile への initの追記についてですが、
shell configuration fileの最後に書けと書いてありますので、
今後.bash_profile ファイルを編集するときにこの後ろに何か書いてしまわないように、注意書きか何かコメントしておきましょう。

Please make sure eval “$(pyenv init -)” is placed toward the end of the shell configuration file since it manipulates PATH during the initialization.z

pyenvが入ったら、Anacondaの導入です。 下記コマンドで、インストール可能なバージョンが一覧表示できます。


$pyenv install -l
-- 略 --
  anaconda3-5.1.0
  anaconda3-5.2.0
  anaconda3-5.3.0
  anaconda3-5.3.1

今回は anaconda3-5.3.1 を導入します。


$ pyenv install anaconda3-5.3.1

さらに、導入したバージョンを利用するように設定して、確認します。


$ pyenv global anaconda3-5.3.1
~$ python --version
Python 3.7.0

昔の Anacondaは version表示するとその名前が出てきた覚えがあるのですが仕様が変わったのかもしれませんね。

MacにMeCabをインストールする

Mac Book Proに 形態素解析ソフトのMeCabをインストールします。

homebrewを導入済みであれば簡単です。
ソフトウェア本体と、IPA辞書を順番にインストールします。


brew install mecab
brew install mecab-ipadic

入ったらテストしましょう。mecabコマンドで起動したあと、形態素解析したい文章を入力します。


~$ mecab
すももももももものうち
すもも	名詞,一般,*,*,*,*,すもも,スモモ,スモモ
もも	名詞,一般,*,*,*,*,もも,モモ,モモ
も	助詞,係助詞,*,*,*,*,も,モ,モ
もも	名詞,一般,*,*,*,*,もも,モモ,モモ
の	助詞,連体化,*,*,*,*,の,ノ,ノ
うち	名詞,非自立,副詞可能,*,*,*,うち,ウチ,ウチ
EOS

終了は Ctrl + d です。

WordPressの一般設定にあるURLをhttpsに変える

証明書の自動更新まで設定し終わった段階で、https化の作業は終わったと思っていたのですが、
まだ残っているのがありました。

WordPressにログインし、一般設定を見ると、
WordPress アドレス (URL) と サイトアドレス (URL) という設定を見ると、
どちらも https://analytics-note.xyz と、httpのURLが設定されてしまっていて
しかも網がかかっていて修正ができません。

記事中でブログ内でリンクを貼る時など、いろんな場面で利用する設定のようで、
このままでは不都合ありそうです。

WordPressの日本語ドキュメントの一般設定から引用します。

WordPress のアドレス(URL)
WordPressのコア・アプリケーションのファイル(たとえばwp-config.php, wp-admin, wp-content, wp-includesなど)を含むディレクトリの正式なURLを入力します。たとえば、あなたが「blog」という名前のディレクトリにWordPressをインストールした場合は、WordPressのアドレスはhttp://example.net/blogとなります(example.netは利用者のドメイン名です)。もしも、WebサイトのルートにWordPressをインストールした場合は、このアドレスはhttp://example.netとなります。URLの最後にスラッシュ(/)を付けた場合は自動的に省かれます。wp-config.php ファイル内で WP_SITEURL 定数を定義すると、定義した値がこのフィールドに入り、管理画面から編集することはできません。

サイトアドレス(URL)
WordPressサイトを呼び出す時に、ブラウザに閲覧者が入力するURLを入力します。このURLは、WordPressのindex.phpがインストールされているディレクトリです。 WordPress を専用ディレクトリに配置する場合以外は、ブログのアドレス(URL)と前述のWordPressのアドレス(URL)が同一です。URLの最後にスラッシュ(/)を付けた場合は自動的に省かれます。wp-config.php ファイル内で WP_HOME 定数を定義すると、定義した値がこのフィールドに入り、管理画面から編集することはできません。

要するに、 wp-config.php で設定されていると管理画面から変更ができないそうなので、
wp-config.php から編集します。

参考:サイト URL の変更

編集するファイルは
/opt/bitnami/apps/wordpress/htdocs/wp-config.php
です。
中に確かに次のような記載がありました。


define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');

これを下記のようにhttpsに書き換えます。


define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/');
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/');

保存したら自動的に反映されたようです。

Let’s Encrypt の証明書を自動更新する

このブログのhttps化のために導入したLet’s Encrypt の証明書ですが、90日ごとに期限が切れてしまうそうです。
更新手順が用意されていますが、毎回行うのは面倒なのでそれを自動化します。

手順は、証明書を導入した時と同じbitnamiのドキュメントの下の方にあります。
Generate And Install A Let’s Encrypt SSL Certificate For A Bitnami Application
これの Step 5: Renew The Let’s Encrypt Certificate がそれです。

rootユーザーにsuし、
/etc/lego/renew-certificate.sh
というファイルを作ります。中身はこれです。
ドキュメント中の”EMAIL-ADDRESS” と “DOMAIN” は自分のものに置き換える必要があります。


#!/bin/bash

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /usr/local/bin/lego --email=メールアドレス --domains=analytics-note.xyz --path="/etc/lego" renew
sudo /opt/bitnami/ctlscript.sh start apache

スクリプトファイルを作成したら実行できるように権限を修正します。(ユーザーはrootで実行)


chmod +x /etc/lego/renew-certificate.sh

そして、このスクリプトを cronに設定します。
下記コマンドを実行して編集画面を起動。


sudo crontab -e

最終行に先ほど作ったスクリプトを登録して保存したら完了です。


0 0 1 * * /etc/lego/renew-certificate.sh 2> /dev/null

Googleアナリティクス導入

ドメインも取得し、https化も済んだのでこのブログのURLがある程度固まります。
この段階で、今後アクセスを分析するためにGoogleアナリティクスを導入しておきます。
実はGoogleアナリティクスの学習/実験環境を手に入れるのがこのブログの目的の一つでもあります。

アカウント作成手順は非常に簡単で、
Googleアナリティクスで検索して出てきたページにアクセスし、Gmail等で利用しているアカウントでログインします。
あとはアカウント名、サイト名、トップページURLを入力して終わり。
つまずくとしたら、アカウント名に何を入れたらいいかくらいだと思いますが、これは本当になんでもよく、あとで変えられるようです。

ブログ側に設定するため、トラッキング IDという UAと数値で構成されたIDを取得し控えておきます。
これを ALL in One SEO というbitnamiのWordpressに初めから入っているプラグインに設定して完了。

GAのリアルタイム画面で自分のアクセスが検知できればテスト完了です。

httpのアクセスをhttpsにリダイレクトする

せっかくhttps通信を使うように証明書を設定しましたが、そのままではhttpでもアクセスできてしまいます。
対応として、httpでアクセスがあったらhttpsのURLへリダイレクトするようにします。

これも人によって方法の流儀があるようですが、bitnami のドキュメントにそって設定します。

Force HTTPS Redirection With Apache

方法は簡単で、設定ファイルを書き換えてapachを再起動するだけです。

書き換える設定ファイルはこれ。
/opt/bitnami/apache2/conf/bitnami/bitnami.conf
DocumentRoot の設定の下に3行追加します。


<VirtualHost _default_:80>
  DocumentRoot "/opt/bitnami/apache2/htdocs"
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^/(.*) https://analytics-note.xyz/$1 [R,L]
  <Directory "/opt/bitnami/apache2/htdocs">

設定したらapachを再起動。ちなみにコマンドはこちらです。


sudo /opt/bitnami/ctlscript.sh restart apache

あとは、httpのURLでアクセスして、httpsページが表示されたらOKです。
Chromの開発者ツールで通信をみるとリダイレクトされていることも確認できます。

LightsailのWordPressサーバーにLet’s Encryptの証明書を設定してhttps通信できるようにする

httpのままだと通信が安全でないなどの警告が出るため、https化を試みます。
本当は利用サービスをAWSに寄せていくため、AWS Certificate Managerを使いたくて、
色々調べていたのですが、結局ここで発行した証明書はサーバーに配置できないことがわかりました。
ロードバランサーに設定するそうですがロードバランサー自体がいいお値段するので断念し、
Let’s Encryptというのを利用することにしました。

各所で色々な人が手順を書いていくれていて、微妙に異なるので正しい手順がわからず混乱していたのですが、
bitnami の公式ドキュメントに、Let’s Encryptを使う手順がありますしたのでここの手順を採用します。

Generate And Install A Let’s Encrypt SSL Certificate For A Bitnami Application

ただし、ドキュメント場では下記のスクリプトを使えば簡単なように書いてありますが、Lightsailのサーバーにはこのファイルが無かったので、代替手順(Alternative Approach)の方を採用します。
/opt/bitnami/letsencrypt/scripts/generate-certificate.sh

注意点としては、X.Y.Zを最新のバージョン番号に読み替えるとか、DOMAINやEMAIL-ADDRESSを正しいものに読み替えて実行することと、
自分の場合は wwwのサブドメインを使っていないので、コマンドに含めないようにすることでしょうか。

Lego Client のインストール

サーバーにssh接続して下記コマンドを入れます。


cd /tmp
curl -s https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
# ドキュメント場の記載
# tar xf lego_vX.Y.Z_linux_amd64.tar.gz
# 実際は、curlで取得されたファイルに合わせて、バージョン番号を入れる
tar xf lego_v1.2.1_linux_amd64.tar.gz
sudo mv lego /usr/local/bin/lego

自分のドメインの証明書を作成する

Bitnami servicesを全て止める


sudo /opt/bitnami/ctlscript.sh stop

legoを実行。


# ドキュメントの記載
# sudo lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/etc/lego" run
# 実際に打ったコマンド(ただしメールアドレスは伏せます)
sudo lego --email=メールアドレス --domains=analytics-note.xyz --path="/etc/lego" run

証明書を利用するようにサーバーを設定する

Apache用の手順を使用します。


sudo mv /opt/bitnami/apache2/conf/server.crt /opt/bitnami/apache2/conf/server.crt.old
sudo mv /opt/bitnami/apache2/conf/server.key /opt/bitnami/apache2/conf/server.key.old
sudo mv /opt/bitnami/apache2/conf/server.csr /opt/bitnami/apache2/conf/server.csr.old
# sudo ln -s /etc/lego/certificates/DOMAIN.key /opt/bitnami/apache2/conf/server.key
sudo ln -s /etc/lego/certificates/analytics-note.xyz.key /opt/bitnami/apache2/conf/server.key
# sudo ln -s /etc/lego/certificates/DOMAIN.crt /opt/bitnami/apache2/conf/server.crt
sudo ln -s /etc/lego/certificates/analytics-note.xyz.crt /opt/bitnami/apache2/conf/server.crt
sudo chown root:root /opt/bitnami/apache2/conf/server*
sudo chmod 600 /opt/bitnami/apache2/conf/server*

お恥ずかしながら、DOMAIN.key や DOMAIN.crtのDOMAIN を見落とし、置き換えないまま実行してしばらくここで詰まりました。

Bitnami servicesを再開


sudo /opt/bitnami/ctlscript.sh start

アクセステスト

https://analytics-note.xyz/
にアクセスします。
正常につながったのでOKです。

一旦設定は完了ですが、このままでは、
httpでも普通にアクセスできてしまうのと、
数ヶ月おきに証明書の有効期限が切れる問題があるのでそれぞれ対応します。