とーますメモ

Ruby on Rails / Goなどの学習メモ

【Python】Python初心者がMac上で環境構築をしてみる

homebrewが既に入っており、Python3環境を作成するのが前提。

新しい言語を使用するときに、自分がまず調べることは以下の2つ。

1)デバック方法の把握
2)グローバル環境を汚染せず「プロジェクト毎の環境(バージョン及びパッケージ)」が構築できるツールの使用法

1)については以下で書いたので、2)ついて今回はまとめる。
thoames.hatenadiary.jp

① Pythonバージョンを自由に変更して使用する方法

「pyenv」を使う方法が一般的みたい。
複数の異なるバージョンのPythonを利用したいときに使用する。
3.3.0と3.3.1といった細かいバージョンわけまで管理可能。
2系と3系との切り替えにも便利。

インストール

$ brew install pyenv

パスを通す

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile

バージョン確認

$ pyenv --version

インストール可能なバージョンを確認

$ pyenv install --list

現時点(2019/02/10)での最新の2系(2.7.15)と3系(3.7.2)の安定版バージョンをインストール

$ pyenv install 2.7.15
$ pyenv install 3.7.2

pyenvを通してインストールされたバージョンの確認

$ pyenv versions

※ちなみにアンインストールしたい場合は以下。簡単。

$ pyenv uninstall <version>

[変更前] 現在のPythonのバージョン確認

$ python -V

3.7.2をグローバル環境で使用する例

$ pyenv global 3.7.2

現在いるディレクトリ内だけで特定バージョンを使用したい場合は、globalではなくlocalコマンドを利用する。
localコマンドを利用すると、そのディレクトリ内にPythonバージョンが記載された.python-versionファイルが作成される。
またglobal及びlocalの両方が設定されている場合、localのPythonバージョンが優先される。
なので、まずは普段使いするバージョンをglobalで設定し、
プロジェクト毎にバージョン変更する場合は、localを使用するという使い方になる。

2.7.15をローカル(現在のディレクトリ内だけ)で使用する例

$ pyenv local 2.7.15

[変更後] 現在のPythonのバージョン確認

$ python -V

この時点で、pyenvで指定したバージョンに変更されていればOK。
変更されていない場合は、以下の記事を参照
pyenvのインストール、使い方、pythonのバージョン切り替えできない時の対処法 - Qiita

② [簡易版・小規模] Pythonパッケージをプロジェクトごとにインストール/使用する方法

Python2では「virtualenv」という仮想環境ツールを別途インストールし使用するが
Python3.3からはこのツールの機能が「venv」という名前で標準ライブラリに取り込まれたので
この記事では「venv」を使用する。

「project-hoge」という名前の仮想環境を作成する例
※ 「-m」オプションを使うと、インストールされているモジュールをスクリプトとして実行できる。

$ mkdir ~/Python/env
$ cd ~/Python/env
$ python -m venv project-hoge

※仮想環境作成時に、どの仮想環境内でどのPythonバージョンを使用するかを決めることができるので
pyenv localコマンドを使用する必要がないとのこと。詳細は以下の記事より。
Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita


「project-hoge」仮想環境を有効化

$ cd ~/Python/env
$ source hoge/bin/activate

上記のコマンドを打つことで、仮想環境を有効化するとコマンドプロンプトの頭に仮想環境名が
入り、現在どの仮想環境内で作業しているのかがわかるようになる。
仮想環境有効化した状態で、パッケージなどを好きにインストールすると、インストールしたパッケージは
仮想環境内だけで適用されるため、他の仮想環境内からは見えなくなる。

「project-hoge」仮想環境を無効化

(project-hoge) ユーザ名$ deactivate

③ [中規模以上] Pythonパッケージをプロジェクトごとにインストール/使用する方法

簡単なパッケージをインストールするぐらいなら、②で紹介した方法でも良いが
パッケージが複雑に絡み合うようなプロジェクトを作成する場合などでは
「パッケージ管理」を滞りなく行ってくれるツールを使ったほうがよい。
記事を書いている時点で、「Pipenv」と「Poetry」というツールが候補に上がったが
以下の理由で最終的に「Pipenv」を使用することにした。

1)単純にGithubのスター数が圧倒的に、Pipenvが多かった
2)日本語情報がPipenvの方が多そうだった
3)PipenvからPoetryへの以降はそれほど難しそうではない

インストール

$ pip install pipenv

プロジェクトのディレクトリを作成し、初期ファイルを作成
サンプル用のflaskプロジェクトを作成

$ mkdir ~/Python/projects/flask
$ cd ~/Python/projects/flask

# 以下のようにしてしまうと、「~/.local/...」で仮想環境がまとめられてしまう。
# 自分の場合は、プロジェクトディレクトリ内に、仮想環境を作成してほしかったので
# 
# $ pipenv install

次に「pipenv install」を行って、初期ファイルの「Pipfile」と「Pipfile.lock」を作成するのだが
そのままコマンドを入力してしまうと、「~/.local/...」で仮想環境がまとめられてしまう。
自分の場合は、プロジェクトディレクトリ内に、仮想環境を作成してほしかったので
PIPENV_VENV_IN_PROJECTという環境変数を以下のように設定する。

またpipenvのコマンドを補完をサポートしてくれる「pipenv --completion」の設定も追加

パスを通す

$ echo 'export PIPENV_VENV_IN_PROJECT=true' >> ~/.bash_profile
$ echo 'eval "$(pipenv --completion)"' >> ~/.bash_profile
$ source ~/.bash_profile

初期ファイル作成

$ pipenv install  

上記のようにすることで、仮想環境は、プロジェクト内の「.venv」というディレクトリ内に作成される。

仮想環境を有効化

$ pipenv shell

仮想環境外から仮想環境内のコマンドを叩くときは以下のようにする。
仮想環境外からpythonコマンドを叩く例

$ pipenv run python

仮想環境内で「exit」コマンドを使用すれば、仮想環境から抜けられる。

次にflaskをインストール

$ pipenv install flask

flaskがインストールされていることを確認

$ pipenv shell
(flask) bash-x.x$ pip list

または

$ pipenv run pip list

app.pyを作成

# coding: utf-8

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello World!'

@app.route('/ja')
def hello_world_ja():
    return 'こんにちは 世界!'

if __name__ == '__main__':
    app.run()

※ 初期状態だと、flaskの実行環境(Environment)が「production」になっているので
「WARNING: Do not use the development server in a production environment.」というエラーがでる。
このエラーを消すために、FLASK_ENV環境変数にdevelopmentを指定する。

$ echo 'export FLASK_ENV=development' >> ~/.bash_profile
$ source ~/.bash_profile

flaskを起動

$pipenv run python app.py

起動に成功したら、「http://127.0.0.1:5000/」にアクセスすることで
「Hello World!」が表示される。

備考

元々、Pythonを使おうと思ったのは単純に簡単なFlaskを使用したWebサービスを作ってみたかったから。
FlaskについているWebサーバはあくまでも開発用っぽいので、実際に大量のアクセスをさばくような
Webサービスを開発するとなると、ApacheなりNginxなりを使用する必要がありそう。

検索してみたら、いい感じのuwsgi + Nginx + flaskのdockerイメージが合ったので
本番環境を構築するときは、これを使ってみたい。
uwsgi-nginx-flask-dockerでFlaskを楽々Docker運用 - Qiita



[参考]
pyenvのインストール、使い方、pythonのバージョン切り替えできない時の対処法 - Qiita
pyenv を用いた Python3 インストール - Qiita
Python 仮想環境 | pyenv と vertualenv による Python の開発環境の構築
Pythonの環境管理ツール良し悪し - Zopfcode
Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita
Python3 Pipenvの導入メモ - ikap
[Flask] Flaskの基本的な構成(を思い出す) | Today's Commit

【Python】デバック方法について

自分用メモ。

Rubyのbyebugみたいなやり方を探していたら、
以下の一行を入れれば良いだけ。

import pdb; pdb.set_trace()

でも長すぎる・・・

JetBrainsのPyCharmやVSCode入れれば、上記のコード入れなくても
ブレークポイントをエディタ上でつけられるので良さげ。

まずは無料のVSCodeで試してみたい。

[参考]
Pythonでデバッグしたい - Qiita

【WordPress】Wordmoveで、ローカルのDocker環境をProductionのDocker環境へpushする

以前の記事の続き。
thoames.hatenadiary.jp

以下がプロダクション環境のdocker-compose.ymlの設定。
本当は細かく各ミドルウェアのバージョンを指定したほうが良いが
今回は省略。

またこの記事ではWordMoveのmovefile.ymlの説明も省略する。

version: "3"
services:

  #################################
  #           WordPress           #
  #################################

  wordpress:
    image: wordpress:latest
    container_name: wordpress

    links:
      - dbms:mysql
    ports:
      - 8080:80
    restart: always
    env_file: .env
    volumes:
      - ./wordpress:/var/www/html



  #################################
  #              MySQL            #
  #################################

  dbms:
    image: mariadb
    ports:
      - 4306:3306
    container_name: mysql
    restart: always
    env_file: .env
    volumes:
      - ./mysql:/var/lib/mysql



  #################################
  #           PHPMyAdmin          #
  #################################

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: phpmyadmin
    env_file: .env
    links:
      - dbms
    ports:
      - 8090:80
    volumes:
      - ./phpmyadmin:/sessions

ポイントとしてはMySQLのポートをデフォルトの3306番を使用するのでハンク
4306番(任意)を使用しているところ。

この設定で、movefile.ymlの存在するディレクトリ上で「wordmove push -e production --all」すると
データベースのpush以外は同期でき、データベースのエラーとして

mysqldump: command not found (Wordmove::ShellCommandError)

と表示される。

原因としては、エラーそのままだが、Docker元のサーバにmysql-clientが存在しないため発生している。
本来はmysqlコンテナ内のmysqldumpコマンドを叩くべきだが、WordmoveではDocker元のサーバでmysqldumpコマンドを
叩いているため上記のエラーがでる。

aliasコマンドなどを使用して

alias mysqldump='docker exec CONTAINER /usr/bin/mysqldump'

のようにすれば、mysqlコンテナ内のmysqldumpを叩くことも可能だが、
そうすると、もしdocker-compose.yml内のvolumnsのパスと、movefile.ymlのwordpress_pathが違う場合
ディレクトリが見つからないというエラーがでる。

自分の場合は、あまりやりたくなかったが、Docker元サーバにもmysqldumpをするためだけの
mysql-clientをインストールした。

$ apt install mysql-client

自分の場合は、これで「wordmove push -e production -d」も通った。

Production Docker内での設定について

Production内のDocker環境内で、プラグインを更新するためには以下の設定が必要。

FTPを経由せずプラグインを更新するために必要

wp-config.php

define('FS_METHOD', 'direct');

by WordPress FTPなしでプラグインダウンロードできる設定 - Qiita

パーミッションの設定

plugins以下を

$ chown -R www-data:www-data /path/to/site

[参考]
Wordmove not friendly with dockerized production environments · Issue #421 · welaika/wordmove · GitHub

【Docker】docker-composeで立ち上げたphpmyadminコンテナのbashに入れない

phpmyadminコンテナ内で使用されているconfig.inc.phpの中身を見たかったので
以下のコマンドでphpmyadminのコンテナに入ろうとしたが入れなかった。

$ docker exec -it [container_id] /bin/bash

※ちなみにphpmyadminのイメージは公式の「phpmyadmin/phpmyadmin」を使用。

調べてみるとbashではなく、ashというシェルを使用すれば良いとのこと。

Can't enter phpmyadmin container · Issue #480 · laradock/laradock · GitHubを参考にして
以下のような感じコマンドを叩く。

$ docker exec -it [container_id] ash

これでコンテナに入れた。

【セキュリティ】Ubuntu上で、Auditを使用しファイル監視を行ってみた。

以下のサイトがすごくまとまっている。
第7章 システム監査 - Red Hat Customer Portal

Auditを使用することで、システム上のファイルやディレクトリの読込/書込情報を追跡し、監視ログを出力することができる。
またそれに付随するログ検索ツール(ausearch)とレポート出力ツール(aureport)を使用できる。

セキュアなシステムでは、このような原因究明につながる対策を行うことは非常に重要。

Audit以下のような用途で使用できる。

・ファイルアクセスの監視。ファイルやディレクトリがアクセス、修正、実行されたか、またファイル属性の変更も追跡可能
・システムコールの監視
・ユーザーが実行したコマンドの記録
・セキュリティイベントの記録(ex: 失敗したログイン試行)

インストール

$ sudo apt-get install auditd

設定

設定ファイルの場所は「/etc/audit/auditd.conf」
例)

#
# This file controls the configuration of the audit daemon
#

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 10
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = hostname
max_log_file = 30
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key

ルール定義

7.5. Audit ルールの定義 - Red Hat Customer Portal

ルール定義をすることで、どのイベントの記録をとるかを設定する。
ルール定義の方法はauditctlで動的に設定変更もできるが、
永続化するならルールファイルに記述する方が良い。

ルール定義ファイルの場所:「/etc/audit/audit.rules」

現在設定されているルールの確認

$ auditctl -l
No rules

初期設定時は何もルールが設定されていないので、No rulesとなる。

ルールの書式は以下。

-w path_to_file -p permissions -k key_name
  • w: 監視するファイルもしくはディレクトリを指定
  • p: 監視アクション許可 r – 読込, w – 書込, x – 実行, a – ファイル属性の変更.
  • k: ログ内でルールを識別するために割り当てる任意の文字列。監視ルールが提要されるとこの文字列がログ内に表示される。

設定例)/etc/passwd への書き込みアクセスと属性変更を passwd_changes というキーをログに記録する例
/etc/audit/audit.rules

-w /etc/passwd -p wa -k passwd_changes

設定後は、auditdの再起動

$ service auditd restart

再起動後、/etc/passwdファイルを編集すると、以下のようなログが/var/log/audit/audit.logが出力されていることがわかる。

type=CONFIG_CHANGE msg=audit(1479097266.018:224): auid=500 ses=2 op="updated_rules" path="/etc/passwd" key="passwd_changes" list=4 res=1
type=CONFIG_CHANGE msg=audit(1479097266.018:225): auid=500 ses=2 op="updated_rules" path="/etc/passwd" key="passwd_changes" list=4 res=1

設定例は「/usr/share/doc/auditd/examples」の場所にあるので参考にすると良いだろう。
自分の場合は、以下の4つの設定例があった。

・capp.rules.gz・・・Controlled Access Protection Profile (CAPP)
・lspp.rules.gz・・・Labeled Security Protection Profile (LSPP)
・nispom.rules.gz・・・NISPOM (National Industrial Security Program Operating Manual)
・stig.rules.gz・・・セキュリティ技術実装ガイド (STIG: Security Technical Implementation Guide)

ログ検索ツールの使い方

以下のサイトが詳しい。
7.7. Audit ログファイルの検索 - Red Hat Customer Portal

【cron】改めてcronの設定方法について勉強し直してみた

今までなんとなく使ってきたが
以下の4つのパターンで設定することができるらしく
何が違うのかはっきりさせたかったので、学習し直すことにした。

1)/etc/cron.(daily|weekly|monthly)/内に設定する方法
2)crontabコマンドで設定する方法
3)/etc/crontabで設定する方法
4)/etc/cron.d/内に設定する方法

先に結論

/etc/corn.d/内に拡張子なしのテキストファイルを置く。
例)/etc/cron.d/test_cron

文法は以下

*[Space]*[Tab]*[Space]*[Space]*[Tab]root[Tab]Commands   

テンプレート

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
# 分 時 日 月 曜日 ユーザー コマンド

# 1分ごと
* *    * * *  root   touch /home/ubuntu/test.txt

# 1:00〜1:59まで1分ずつ実行
* 1    * * *  root   touch /home/ubuntu/test.txt

# 毎日1:00に実行
0 1    * * *  root   touch /home/ubuntu/test.txt

# 毎月12日~20日00:00に実行
0 0    12-20 * *  root   touch /home/ubuntu/test.txt

# 毎週月曜日〜金曜日00:00に実行
0 0    * * 1-5  root   touch /home/ubuntu/test.txt

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

前提知識

cronとは?

cronは指定日時にジョブの自動実行を行うジョブスケジューラです。UNIX系のOSであれば実装の違いこそあれ,ほぼ標準でインストールされています。

by 第25回 cron周りのベストプラクティス(1):Perl Hackers Hub|gihyo.jp … 技術評論社

cronの用途

cronの使い途は,主に次の3つが考えられます。

a.アプリケーションのジョブの実行
b.システムに関わるジョブの実行
c.監視用途
a.はアプリケーションで定期的に実行したいジョブの実行です。たとえばランキングの更新処理などの用途です。b.はログのローテートやバックアップなどの用途です。c.の用途は少し意外に感じられるかもしれませんが,毎分確実に実行されることを利用して,簡易な死活監視などに利用するといった用途があります。

by 第25回 cron周りのベストプラクティス(1):Perl Hackers Hub|gihyo.jp … 技術評論社

タイムゾーンの設定

Ubuntu 18.04のデフォルトは、UTCになっていた。

Tips:

タイムゾーンは crond の起動時にのみ実行環境に設定されている値を取得しています
起動後にはタイムゾーンの更新は行われないので crond の起動後にタイムゾーンを変更しても変更前のタイムゾーンのまま動作します

cron の意外な落とし穴! - もろず blog

このためタイムゾーンを更新したら、必ずcrondを再起動すること

$ sudo service cron restart

確認コマンド

$ timedatectl
Local time: Wed 2020-03-04 17:16:21 UTC
Universal time: Wed 2020-03-04 17:16:21 UTC
RTC time: Wed 2020-03-04 17:16:22
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no

なので、タイムゾーンを直す。
タイムゾーン名一覧は以下
List of tz database time zones - Wikipedia

例)Asia/Tokyo
$ timedatectl set-timezone Asia/Tokyo
$ timedatectl
Local time: Thu 2020-03-05 02:28:08 JST
Universal time: Wed 2020-03-04 17:28:08 UTC
RTC time: Wed 2020-03-04 17:28:09
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no

ログ出力設定(Ubuntuの場合)

以下記事を参考
[ubuntu] cronのログが出力されない時の対処方法 | BlueBear I/O

cronのログは、将来的に問題が発生した場合などの原因究明に役に立つので有効化しておく。
ログの出力されていない場合は、以下のように変更

/etc/rsyslog.d/50-default.confを編集

$ vi /etc/rsyslog.d/50-default.conf


cronログ設定のコメントを外す。

-#cron.* /var/log/cron.log
+cron.* /var/log/cron.log

rsyslogの再起動

$ service rsyslog restart

crondの起動及び確認方法

Ubuntuの場合は以下。

確認

$ service cron status

停止

$ service cron stop

起動

$ service cron start

[参考]
Linux Start Restart and Stop The Cron or Crond Service - nixCraft

1)/etc/cron.(hourly|daily|weekly|monthly)/内に設定する方法

実行時間は「/etc/crontab」で設定されている。
※CentOS6であれば「/etc/anacrontab」

/etc/crontabの中身例

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
# 分 時 日 月 曜日 ユーザー コマンド
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

文法は以下

*[Space]*[Tab]*[Space]*[Space]*[Tab]root[Tab]Commands   

スクリプトの実行時間に対して、厳密な時間に実行するなどのルールが
なければ、任意のディレクトリに実行ファイルを入れておけば
勝手に実行されるのでこの方法が一番簡単。

2)crontabコマンドで設定する方法

この方法でcronを設定する場合は、crontabコマンドを使用する。
主に使用するコマンドは
「crontab -l」:設定内容の確認
「crontab -e]:設定の編集

まずは「crontab -e」でcron設定を行うためのエディタを設定

$ vi ~/.bashrc

デフォルトエディタをvimに設定する例

$ export EDITOR=vim
$ source ~/.bashrc

設定を行うとユーザ毎に/var/spool/cron/crontabs/[username]というファイルが作成される。
このファイルは直接編集することは推奨されていないので
編集するときは必ず「crontab -e」を使用する。

書式は左から、[分] [時] [日] [月] [曜日] [コマンド]

5分おきにfuga.shを実行する例

*/5 * * * * /home/hoge/fuga.sh
  • 分は0~59の数字で指定
  • 時は0~23の数字で指定
  • 日は1~31の数字で指定
  • 月は1~12の数字で指定
  • 曜日に関しても数字で指定し、0と7が日曜日、1以降は順に、月、火、水、木、金、土となる
  • コマンドは、設定ファイルでパスを通していないものに関してはフルパスで指定するかカレントディレクトリからの相対パスで指定しなければならない。

※各cronのジョブが実行される際のカレントディレクトリは,ユーザのホームディレクトリ。

時間の書き方例

43 23 * * * 23:43に実行
12 05 * * *    05:12に実行
0 17 * * * 17:00に実行
0 17 * * 1 毎週月曜の 17:00に実行
0,10 17 * * 0,2,3 毎週日,火,水曜の 17:00と 17:10に実行
0-10 17 1 * * 毎月 1日の 17:00から17:10まで 1分毎に実行
0 0 1,15 * 1 毎月 1日と 15日と 月曜日の 0:00に実行
42 4 1 * *     毎月 1日の 4:42分に実行
0 21 * * 1-6   月曜日から土曜まで 21:00に実行
0,10,20,30,40,50 * * * * 10分おきに実行
*/10 * * * *        10分おきに実行
* 1 * * *         1:00から 1:59まで 1分おきに実行
0 1 * * *         1:00に実行
0 */1 * * *        毎時 0分に 1時間おきに実行
0 * * * *         毎時 0分に 1時間おきに実行
2 8-20/3 * * *      8:02,11:02,14:02,17:02,20:02に実行
30 5 1,15 * *       1日と 15日の 5:30に実行

※ちなみに全部 * だと毎分実行される。e

by クーロン(cron)をさわってみるお - Qiita

間違いやすい例としては
例えば毎朝5時ちょうどにバックアップを走らせたいというような場合。

○:間違った設定

* 5 * * * /path/to/backup.sh

○:正しい設定

0 5 * * * /path/to/backup.sh

間違った設定をしてしまうと、毎朝5時台の1分毎にバックアップ処理が走ってしまう。

3)/etc/crontabで設定する方法

基本的には2)の方法と同じ書式で設定が可能だが、
あまりこのファイルを直接編集することは推奨されていない。

4)/etc/cron.d/内に設定する方法

ちなみに、「/etc/cron.d/」は
インストールされたパッケージ専用ディレクトリらしいので、
いじる必要なさそう。

by /etc/cron.monthly/ と crontabコマンド の違い - pospomeのプログラミング日記

上記参考記事のような意見もあるが
この方法を使用すると、以降で説明する「crontab -r」で設定を吹き飛ばしてしまう心配がなくなる。

設定する場合は、crontabコマンドの書式と違い、以下のように「ユーザ」を指定する必要がある。
書式は左から、[分] [時] [日] [月] [曜日][ユーザ][コマンド]

5分おきにfuga.shを実行する例

*/5 * * * * root /home/hoge/fuga.sh

またこの方法を使用した場合、複数ファイルに分けて管理ができるため
プロジェクト毎だったり、担当者毎だったりとファイルを分けられることはありがたい。

「crontab -r」対策

詳細は以下ページから参照
crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる

crontabコマンドには「crontab -r」という一発で全ての設定を消してしまうコマンドがあるため
ミスタイプしてしまうと悲惨なことになる。(eとrは隣同士なので間違えるか可能性が比較的高い)
それを避けるために、は以下のような方法がある。

crontabを使用せず/etc/cron.d/内で設定する方法を使用する

上記でも紹介しているので説明は省略

「crontab ファイル名」で、ファイル内の設定をcrontabに反映する

ところで,crontab -eでのcrontabの直接編集は実は好ましくありません。crontab -rによるcrontab全消去のオペレーションミスがたびたび話題になります。実はcrontab とファイル指定することで,その内容をcrontabに反映できます。そして,このファイルをリポジトリ管理するのがベストプラクティスです。

by 第25回 cron周りのベストプラクティス(1):Perl Hackers Hub|gihyo.jp … 技術評論社

crontab -eで設定することは禁止して、常にこの形式で行うことにすれば、-eオプションを付けることが無いわけだから-r事故も起こらない。この場合、~/etc/crontab とか作っておいて、それを読み込ませる、とすると良いだろう。

by crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる

「crontab -l」後に「crontab -e」を行う

こうすることで、スクリーンログを残しておけば、
何かあったときにサルベージできる。
※ iTerm2を使用しているはデフォルトではログは残さない設定になっているので、別途設定が必要

「crontab -l > /path/file/to」でバックアップを作成後、「crontab -e」を行う。

シンプルな方法。

「crontab -e」にエイリアスを付ける

alias cronedit='crontab -e' 

またはcrontabをエイリアスにする

alias crontab='crontab -i'

「/var/spool/cron/crontabs/」内をgitで管理する

$ cd /var/spool/cron/crontab/
$ git init
$ git add root
$ git commit -m "initial commit"

誤って消してしまったら

$ git reset --hard HEAD^

間違えて消してしまったら・・・

「/var/log/cron」から復旧する方法があります。

詳しくはこちらのページより参照
crontab -r とやってしまった時の対処法

結論

長々と書いたが個人的には「cron.d」ディレクトリ内にファイル入れる方法が
一番手順が少なく、間違って消してしまうこともないので良いと思う。
パッケージ用のcronファイルと混ざるのが、少し嫌だが
うまくネーミングを付けて管理すれば、あまり気にならないだろうし。

名称付の例
ex) [プロジェクト名]_[ユーザ名]_[機能名]


[参考]
cron の設定ガイド
第25回 cron周りのベストプラクティス(1):Perl Hackers Hub|gihyo.jp … 技術評論社
cron 設定ファイル (crontab ファイル) の置き場所と書式について - ひだまりソケットは壊れない
crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる
/etc/cron.monthly/ と crontabコマンド の違い - pospomeのプログラミング日記
クーロン(cron)をさわってみるお - Qiita
[ubuntu] cronのログが出力されない時の対処方法 | BlueBear I/O
gitによるcron設定ファイルの管理と実行 - NaN NaN da
【Linux】crontabとcron.dの違い | naoのブログ

【SSH】ログイン時にSlackに通知する

下記のサイトさんのやり方を参考に作成
[Linux]SSHログイン時にメール/Slackで通知する – 備忘録の覚書

以下の"XXX.XXX.XXX.XXX"箇所は信頼できるIPを設定
半角スペースを入れることで複数指定可能。
e.g.) "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY"

{{ slack_login_alert_webhook_url }}にはSlackのwebhook URLを設定。

#!/bin/bash

SOURCE_IP=${SSH_CLIENT%% *}
# 信頼するIPを指定
TRUST_IP_LIST="XXX.XXX.XXX.XXX"

# リストと比較して信頼していないIPからのアクセスならSlackに通知
for HOST in $TRUST_IP_LIST
do
  if [ $HOST == $SOURCE_IP ]; then
    exit 0
  fi
done

url="{{ slack_login_alert_webhook_url }}"

readonly USER=`whoami`
readonly HOST=`hostname`

ip=`who | awk '{print $6}' | cut -d '(' -f 2 | sed -e 's/)//g'`
user=`w -hsi | awk '{print $1}'`
day=`lastlog | grep -w "${USER}" | awk '{print $4}'`
month=`lastlog | grep -w "${USER}" | awk '{print $5}'`
date=`lastlog | grep -w "${USER}" | awk '{print $6}'`
time=`lastlog | grep -w "${USER}" | awk '{print $7}'`

payload="payload={
  \"attachments\": [
    {
      \"color\": \"#36a64f\",
            \"title\": \"'${USER}': SSH Connection has established.\",
      \"fallback\": \"'${USER}': SSH Connection has established.\",
      \"fields\": [
        {
          \"title\": \"HOSTNAME\",
          \"value\": \"${HOST}\",
          \"short\": true
        },
        {
          \"title\": \"Date / Time\",
          \"value\": \"${month} ${date} (${day})  ${time}\",
          \"short\": true
        },
                {
                  \"title\": \"User Name\",
                  \"value\": \"${user}\",
                  \"short\": true
                },
        {
          \"title\": \"from\",
          \"value\": \"${ip}\",
          \"short\": true
        }
      ]
    }
  ]
}"

curl -m 5 --data-urlencode "${payload}" "${url}" > /dev/null 2>&1