カテゴリー: linux

vixie-cronはAmazon Linuxでは利用できない
はじめに

vixie-cronは、crontabで環境変数を設定可 (PATH、SHELL、HOME等)。それに加え、
crontabファイルの冒頭に
```
MAILTO=""
```
加えるだけで、全てのメール通知を止めることができる便利なツール

Amazon linuxでは

しかし、Amazon linuxではvixie-cronはcronieに置き換わっている。
https://aws.amazon.com/jp/amazon-linux-ami/2011.02-release-notes/#Obsoleted_Packages:

anacron and vixie-cron are obsoleted by cronie

cronieはvixie-cron同様、Cron deamonとして動くようだ

cronie-1.4.4-2.4.amzn1 – Cron daemon for executing programs at set times

yum infoの情報は以下の通り
```
$ yum info cronie
読み込んだプラグイン:priorities, update-motd, upgrade-helper
14 packages excluded due to repository priority protections
インストール済みパッケージ
名前 : cronie
アーキテクチャー : x86_64
バージョン : 1.4.4
リリース : 15.8.amzn1
容量 : 174 k
リポジトリー : installed
要約 : Cron daemon for executing programs at set times
URL : https://fedorahosted.org/cronie
ライセンス : MIT and BSD and ISC and GPLv2
説明 : Cronie contains the standard UNIX daemon crond that runs specified programs at
: scheduled times and related tools. It is a fork of the original vixie-cron and
: has security and configuration enhancements like the ability to use pam and
: SELinux.
```
yum info にあるようにvixie-cronからforkされているようなので、基本的にはvixie-cronをcronieに置き換えるだけで済みそう。
2018年7月26日
gitで間違えたブランチに書き込んだ際の対処
gitで間違えたブランチに書き込んだ

一度退避させた後、ブランチを切り替えて、退避した変更を引き継ぐというやり方。しょっちゅう使っているコマンドの一つ

今回はmasterブランチに書き込んだとする

変更点を退避する

git stashコマンドを使うと、変更点のみ退避することが可能
```
$ git stash
Saved working directory and index state WIP on master: 1169a810 Merge branch 'route53_20180724_120035' into 'master'
$ 
```
この時点でgit statusを実行すると変更点がなくなる。
書き込んだmasterブランチはクリアーになる
```
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean
$
```
新ブランチを作成

本来作業したかったブランチを作成する
今回はCloudWatchAlarmというブランチとする
ここではcheckout -bオプションで作成と同時にgit branchを行う
```
$ git checkout -b CloudWatchAlarm
Switched to a new branch 'CloudWatchAlarm'
$ 
```
当然この時点ではgit statusを実施しても変更はない
```
$ git status
On branch CloudWatchAlarm
nothing to commit, working tree clean
$
```
ブランチは存在している
```
$ git branch
* CloudWatchAlarm
  master
$ 
```
新ブランチに変更点を取り入れる

git stash popコマンドで新ブランチに変更点を取り入れる
```
$ git stash pop
On branch CloudWatchAlarm
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CloudWatchAlarm.sh

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (d081148067aad39eb60500c5fbb2a32a4c6c2566)
$ 
```
まとめ
```
# 一時退避
git stash

# チェックアウト 
git checkout xxx

# 直前のgit stashを取り出す
git stash pop
```
2018年7月24日
パスワードやAPI keyをコンソールから入力を、より安全にする
パスワードやAPI keyを入力する度、神経を尖らせている

今までは
```
HISTCONTROL=ignorespace
```
を定義し、
```
 export __pass=xxxxxxxx
```
のように、頭にスペースを付けることで、hitoryコマンドでパスワードが表示されないよう工夫をしていた

Qiitaを見ててreadコマンドをうまく使うやり方を知った。

Linux 作業手順書からべた書きパスワードをなくすシンプルなアイディア
 https://qiita.com/ktooi/items/ba156bb1848c31f04949
```
$ read -sp "Please input your password: " __pass; echo
※ パスワード は XXX を参照して入力してください。
$ curl -u "user:${__pass}" http://example.com
```
シンプル！

前途した HISTCONTROL を使う方法はキーなどを環境変数に設定するのに使い、
readはパスワードに使うのが綺麗な使い分けかも。
2018年7月24日
SQLで累積和を計算する
はじめに

最近SQLをガリガリ書くことも少なくなってきたので、
redashを使ってこんな情報を集計したいなーと思っても、どうやって書けばいいか頭を悩ませることがある。

単純な合計の場合、sum関数を使えば簡単に表示できるが、累積和を表示しようとした際、工夫が必要だった。

元データ

MySQLが公開している、世界の都市や人口についてまとまっているサンプルデータを利用。

https://qiita.com/S-T/items/923cf689ee5f44525457

やりたいこと

合算し累計を算出したい

元データ
```
SELECT NAME,
       Population
       
FROM city
WHERE countryCode = 'JPN'
  AND ID IN (1532,
             1533,
             1534);
```
累積和を計算
```
SET @cumulativeSum=0;

SELECT NAME,
       Population, 
       @cumulativeSum:=@cumulativeSum+Population AS Population_Sum
       
FROM city
WHERE countryCode = 'JPN'
  AND ID IN (1532,
             1533,
             1534);
```
追加したところは
SET @cumulativeSum=0;と
@cumulativeSum:=@cumulativeSum+計算したいカラム名をいれただけ。

最初このやり方にたどり着くまでに
SQLでcase文書いて、sumして。。という書き方をしたが、かなりシンプルにおさえることができた。

注意事項

残念ながら、ユーザ定義変数はあくまでもSQLの実行・評価前に定義するための変数で、Select内で更新することを想定していない為、値の保証はしていないようだ

https://dev.mysql.com/doc/refman/5.6/ja/user-variables.html

SELECT などのほかのステートメントでは、予想した結果が得られることもありますが、これは保証されません。次のステートメントでは、MySQL が最初に @a を評価し、続いて 2 番目の割り当てを行います。

複数のクエリを試してみたが、動かない場合もあった。
```
SET @gokei=0;

SELECT counseling_date AS date,
       sum(member_status_id = 0 AND ordinal_attendance = 1) AS free_counseling_1,
       @gokei:=@gokei+sum(member_status_id = 0 AND ordinal_attendance = 1) as gokei
       
FROM counseling
WHERE counseling_date BETWEEN '2018-06-01' AND '2018-06-30'
group by date
```
これは工夫が必要なので、case文を使うなど工夫するしかなさそうだ。

解決策ご存知の方はご教示ください
2018年7月13日