20191219のLinuxに関する記事は9件です。

投稿日：2019-12-19T21:00:52+09:00

絶対にデータを復旧する

0. 概要

年末の忙しい時期にハードディスクのデータが全て消えるという体験はしたことがありますか？
先輩として忠告しておくと凄い悲しい気持ちになります。

そこで、頭記にもある意気込みでデータ復旧をしていったので、備忘録として残しておきます。

1. 前提条件

まず置かれている状況。

1.1. 状況

初めに、rm -rf *を実行します。
目的とするソースコードやファイルが全て消えたことを確認してからがスタートラインです。

この状況から概ね以下の方法をとるでしょう。
- 急いでやってしまったマシンをシャットダウンする
- 他のPCでLinuxのライブUSBを作成
- LinuxのライブUSBでやってしまったマシンを起動する
- ライブOSからやってしまったマシンのディスクをfdisk -lで見て確認
- 後は、TestDiskやext4magic、foremost、extundeleteを駆使してファイルを復旧

普通なら、ここまですれば凡そのファイルは復旧されます。
しかしながら、この場合でも頑なに復旧を拒まれる場合があります。

1.2. 条件

ここで現状の条件をまとめておくと、

TestDiskやext4magic、foremost、extundeleteでファイルを復旧できない

ディスク自体は物理的に破損していない

ハードウェアRaid 1+0

ext4のファイルシステム

問題発生後すぐにシャットダウンしたのでinodeが切れているだけで論理的にはファイルが残っていそう

データ復旧業者に断られる

最後は、データ復旧業者にお願いしたところTestDiskやext4magic、foremost、extundeleteで復旧出来ない場合は、相当やってしまっているので無理ですと言われ、
どうしてもお願いしますと価格交渉したところ、最低でも100万円からですと言われました。

2. データを復旧する

まず物理的に逝ったわけではなく、インデックスが外れてしまっただけで目的とするファイルはディスク中の情報の海にいると仮定します。
そこでまずは、RAIDがややこしいのダンプして1つのファイルにします。その次にファイルを復旧させていきたいと思います。

dump

以下でダンプをする。
# 対象のディスクを確認する
$ sudo fdisk -l
> sda1
# ダンプする
$ dd if=/dev/sda1 of=./dump.img bs=512M
これで1つのファイルになった。

今回、復旧させたいのは主にソースコード。
そして、そのソースコードは多分、このダンプファイルのどこかにいる。

recover

ダンプファイルが1テラくらいあり、どこに何のデータがあるかなんてまるで見当もつかない。
そこで、ソースコードの1部を想像して、あるテキストのバイナリコードがあるところを引っ張ってくるようにする。
そう、Grepを使う。
grep -i -a -B[size before] -A[size after] 'SEARCH_TEXT' DEVICE > OUTPUT_PATH
-iはケースセンシティブにしない(大文字小文字を区別しない)
-aはバイナリサーチ

例えば、pythonであれば#!/usr/bin/pythonなんて書かれていたりする。
その場合は、こんな感じで使う。
grep -i -a -B10 -A1000 '#!/usr/bin/python' /dev/sda1 > ./backup.txt
これで地道にソースコードを追っていった結果、部分的に復旧することが出来た。
なお、画像なら画像のヘッダーを同様に検索にかければよい。

因みに\r->^Mで検索を掛ければ大体のテキストを持ってこれる。

部分的にデータは引っ掛かるものの、この部分データから1つのファイルに成型していくのが、地獄の作業。

一先ず、この方法でかけらでも復旧できないようなら諦めた方が良さそう。
データは消さないに限る。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T19:51:09+09:00

Ubuntu 16.04 にサポートされていない古いJDKを入れるプロキシ環境対応

目的

Ubuntu16.04には現在JDK8かJDK9の二つがサポートされているが、古いバージョンのJDKをプロキシ環境下で入れる方法をまとめる

今回は例としてJDK7を導入する。

実施概要

PPAリポジトリよりJDK7用のリストを取得

インストール可能なパッケージの一覧を取得

JDK7の本体を取得

JDKのバージョン切り替え

実施詳細
環境変数にプロキシアドレスを入力
下記コマンドを実行して環境変数にプロキシのアドレスを入力する。
$ export http-proxy=プロキシアドレス
PPAリポジトリよりJDK7用のリストを取得
下記コマンドを実行してJDK7をインストールするリストを取得する。(オプション-Eを付けることにより環境変数に格納した値を使用して実行することが可能になる)
$ sudo -E add-apt-repository ppa:openjdk-r/ppa
・
・
・
>Reading package lists... Done
インストール可能なパッケージの一覧を取得
下記コマンドを実行してインストール可能パッケージ一覧を取得する。
$ sudo apt-get update
・
・
・
>Reading package lists... Done
JDK7の本体を取得
$ sudo apt-get install openjdk-7-jdk
バージョンの切り替え
複数のJDKバージョンをインストールしているときはJDKのバージョン切り替えを行う(下記の出力があったら、チェンジしたいJDKのバージョンの行の最初に記載されている数字を入力してEnter、今回はJDK7にしたいため1を入力後Enter)
$ sudo update-alternatives --config java
>There are 2 choices for the alternative java (providing /usr/bin/java).
>Selection    Path                                            Priority   Status
>------------------------------------------------------------
>* 0            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      auto mode
>1            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manual mode
>2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode
>Press <enter> to keep the current choice[*], or type selection number: 
バージョンの確認
下記コマンドを実行してJDKのバージョンを確認する。(下記の様になっていればOK)
$ java -version
>java version "1.7.0_95"
>OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-3)
>OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T18:25:38+09:00

cronを実行したログを出力する設定

はじめに

cronを実行したログを、ログファイルに出力する設定を行った。

環境

Ubuntu 16.04.5 LTS

手順

このファイルを開く。
vi /etc/rsyslog.d/50-default.conf
デフォルトで、この行がコメントになっている筈なので、コメントを外して更新する。
cron.*                         /var/log/cron.log
しかし、ReadOnlyになっていたため更新ができず。書き込みできるように、パーミッションを変更する。
sudo chmod 646 /etc/rsyslog.d/50-default.conf
（変更前）　-rw-r--r--
（変更後）　-rw-r--rw-
cronのログは、rsyslogで出力する仕組みになっている。上記の設定を有効にするために、rsyslogのサービスを再起動する必要がある。
service rsyslog restart
サービスが起動されている事を念のために確認しておく。
service --status-all | grep rsyslog
ログはここに出力されるようになります。cronのログを、rsyslogが、書き込んでくれます。最初のログが、cron.logに書き込まれるタイミングで、cron.logが新規作成されます。
/var/log/cron.log
参考

https://qiita.com/skyfish20ch/items/46db70e1ff88166ead87

cronのログを、rsyslogで書き出すのではなく、cronで実行されたコマンドを、標準出力したログにする

crontab -eで、下記の２行を追加する。
1 12 * * * cd $HOME && date "+\%Y/\%m/\%d \%H:\%M:\%S" >> ./syori01.log
2 12 * * * cd $HOME && /usr/local/rbenv/shims/ruby syori01.rb >> ./syori01.log
解説

12時01分に、システム日付と時間を、syori01.logに書き込み、続けて、12時02分に、syori01.rbというrubyのブログラムを実行して、syori01.logに標準出力します。注意点は、cronに日付を指定する場合、%をエスケープしないと上手くいなかいという点です。

・rubyが入っている場所は、which rubyをして見つけます。
・当処理は、Homeディレクトリで実行しています。

参考

https://qiita.com/doitnow420@github/items/70bc148d782e96492282

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T12:47:32+09:00

threads-max の上限値について

threads-maxはシステム全体でカーネルが一度に使用できるスレッドの最大数を
設定するkernel parameterです。
このパラメータに設定できる値が、MAX_THREADS よりも大幅に
小さな値しか設定できないというregressionが最近までありました。
具体的には kernel-4.0 (2015年4月）から kernel-5.4-rc3 (2019年10月）までの間、
そのような状況が続いていました。
これは kernel-5.4 で修正されました。

昔からの動作 (4GB RAM環境でテスト)
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
1073741823

regressionありのkernel (4GB RAM環境でテスト)
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
31348

実メモリのサイズに合わせて、kernelに設定できる上限値を自動的に
決めてくれるようなお節介な動作となりました。　
アプリケーションがこのパラメータを調整しないと
動作できないような環境では問題となった事でしょう。

LKMLにこんなメールが流れてきて議論が始まりました。。。。
https://lkml.org/lkml/2019/9/17/294
Hi,
I have just stmbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max
observe limits") and I am really wondering what is the motivation behind
the patch. We've had a customer noticing the threads_max autoscaling
differences btween 3.12 and 4.4 kernels and wanted to override the auto
tuning from the userspace, just to find out that this is not possible.

Why do we override user admin like that? I find it quite dubious to be
honest. Especially when the auto-tunning is just a very rough estimation
and it seems quite arbitrary.

意訳：「うちのお客が threads-max が auto tuningが働いて入力した値を書き換える
動作を見つけたんだけど、パッチ16db3d3f1170 って何を意図しているんだ?」

開発者返答して曰く
https://lkml.org/lkml/2019/9/17/570
set_max_threads() sets the upper limit (max_threads_suggested) for
threads such that at a maximum 1/8th of the total memory can be occupied
by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB
system this results in 254313 threads.

With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
a user cannot set an arbitrarily high number for
/proc/sys/kernel/threads-max which could lead to a system stalling
because the thread headers occupy all the memory.

意訳: set_max_threads()が threadの上限値をRAMの8分の1に制限してくれるから、
メモリをthreadのデータで埋め尽くしてシステムがストールするようなことは起こらなくなったよ!

SUSEのエンジニアが答えて曰く
https://lkml.org/lkml/2019/9/17/589
This is still a decision of the admin to make. You can consume the
memory by other means and that is why we have measures in place. E.g.
memcg accounting.

意訳:そんなもの、管理者が決めることだろ。
そのためにmemcgのような計測ツールがあるわけだし。

You do not change the software to overcome artificial bounds based on
guessing.

意訳: 勝手な推測で上限値を設けるような変更を入れないでください。

別なエンジニアが
https://lkml.org/lkml/2019/9/17/705
a) The logic to set the default number of threads in a system
has not changed since 2.6.12-rc2 (the start of the git history).

意訳: gitで管理を始めた2.6.12-rc2から変わってなかった動作がパッチにより変わった

Limiting threads_max to the auto-scaling value is a regression.

意訳: threads-max の入力値を auto-scaling value に調整するのは Regressionだな。

https://lkml.org/lkml/2019/9/19/113
Any take on this Heinrich? If there really is not strong reasoning about
the restricting user input then I will suggest reverting 16db3d3f1170
("kernel/sysctl.c: threads-max observe limits")

意訳：該当パッチをリバートすることを提案する。

Andrew Morton出てきて一言
https://lkml.org/lkml/2019/9/19/748
I agree, based on what I'm seeing in this thread.

意訳：　このスレッドを見てたけど、リバートするのは賛成。

こうして、b0f53dbc4bc4c371f38(kernel/sysctl.c: do not override max_threads provided by userspace) というパッチがメインライン kernel に入り、
そのパッチが以下のstable relase にバックポートされていきました。

Mainline 5.4
stable 5.3.7
stable 4.19.80
stable 4.14.150
stable 4.9.197
stable 4.4.197

これらのkernel versionでは、
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
1073741823
という昔からの動作に戻りました。

Stable relaseにパッチがバックポートされたことで、Fedora 31のkernelにも threads-maxの修正が入りました。

以上

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T12:24:36+09:00

Docker コンテナを CGroup V2 なホストLinuxで動かす

Fedora 31 などでCGroup V2 (unified CGroup 階層) がデフォルトになっているので、そういうLinuxホストでpodman を用いて動かす話です。手順としてはUbuntu/Debian向けに書いてあります。fedora 31ならここに書いてあるように作業すれば（下記のpodman-compose以外は）できるはずです。

Project Atomic のAPTソースの設定

Ubuntuの場合（rootで）
apt-get install software-properties-common
add-apt-repository ppa:projectatomic/ppa
とすると /etc/apt/sources.list.d/projectatomic-ubuntu-ppa-eoan.list が出来るので、それをエディタで開いてリリース名（eoanなど）をdiscoかbionicに変える。これは上記PPAがbionicとdiscoのパッケージしか用意していないからである。

Debian Bullseyeの場合（rootで）
/etc/apt/sources.listの末尾
deb [ allow-insecure=yes ] http://ppa.launchpad.net/projectatomic/ppa/ubuntu disco main
を追加。

Project Atomicからパッケージインストール (Ubuntu&Debian共通）

apt-get -t disco install buildah podman skopeo slirp4netns fuse-overlayfs containernetworking-plugins (discoは前項のリリース名と同じにすること）

crun のインストール

podman 標準のruncがCGroup V2非対応であるから、CGroup V2対応のcrunをインストールする。

Debian の場合

apt-get -t bullseye install crun

Ubuntu の場合

https://packages.debian.org/testing/main/crun からdebファイルをダウンロードして、dpkg -iまたはgdebiを用いてインストールする。

設定ファイルの変更

https://github.com/projectatomic/registries/blob/master/registries.fedora の内容を /etc/containers/registries.conf にコピーする

/usr/share/containers/libpod.conf の中の runtime = "runc" の等号の右辺を"crun"に変更し保存する

上記の作業で docker ナントカのかわりにpodman なんとか と打てば同じことができる（ただしsudoではなくてrootログインが必要かも知れない）。一般ユーザーでのpodman使用は公式にはできることになっているがうまくいかなかった。

podman-compose

docker-compose に対応するコマンドは上記の作業ではインストールされない。それでは困る場合 pip3 install -U podman-compose を用いてpodman-composeコマンドをインストールする。CGroup V2なUbuntu Eoan上でLaTeXで年賀状を作るに示されたdockerコンテナを podman-composeで動かし年賀状を作成することができた。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T10:47:42+09:00

Windows10 マシンにインストールしたubuntuを削除する

Jetson TX2,AGX Xavierセットアップの際、一時的に必要となったubuntu18.04をwin10マシンから削除することにしたので備忘録

デュアルブートは、削除の手順が大事です。

ubuntuの削除は手順通り行わないと、GRUBが逝ってしまうため注意が必要とのこと。
パーテーションの削除からするなどはNG

手順１：bcdeditによるubuntuのデリート
・コマンドプロンプトを管理者実行し、下記コマンドを入力
bcdedit /enum firmware
ファームウェアに関する情報が返ってくるので、ubuntuについて記載されたファームウェアアプリケーションを探す。
ファームウェア アプリケーション (101fffff
--------------------------------
identifier              {bc999fa4-b20c-11e9-93c3-806e6f6e6963}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\UBUNTU\SHIMX64.EFI
description             ubuntu
・ubuntuと表示された上記の identifierの{~}を括弧ごと右クリックでコピーする。
　下記を実行
bcdedit /delete {~}
「この操作を正しく終了しました。」と表示されるので、再度 bcdedit /enum firmwareを実行し、ubuntuが消えているか確認。

削除完了後、OSを再起動し、起動時にubuntuが表示されないか確認する。

手順２：パーテーションの削除

diskpart実行
C:\WINDOWS\system32>diskpart

Microsoft DiskPart バージョン 10.0.17134.1

Copyright (C) Microsoft Corporation.
コンピューター: ---------
ディスクリストをチェック
DISKPART> list disk

  ディスク      状態           サイズ   空き   ダイナ GPT
  ###                                          ミック
  ------------  -------------  -------  -------  ---  ---
  ディスク 0    オンライン           476 GB      0 B        *
ディスク0を選択
DISKPART> sel disk 0

ディスク 0 が選択されました。
ボリュームリストをチェック
Volume 3 SYSTEMラベル　Fs:FAT32　がubuntuの入ったボリュームなので、
DISKPART> list vol

  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0     D                       DVD-ROM         0 B  メディアなし
  Volume 1     C   Windows      NTFS   Partition    413 GB  正常         ブート
  Volume 2         WinRE_DRV    NTFS   Partition   1000 MB  正常
  Volume 3         SYSTEM       FAT32  Partition    260 MB  正常         システム
ボリューム3をチェック
DISKPART> sel vol 3

ボリューム 3 が選択されました。
UEFIシステムパーテイションを選択しマウント
DISKPART> assign letter=X:

DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。
DISKPART> exit

DiskPart を終了しています...
X dirへ移動
C:\WINDOWS\system32>cd /d X:

X:\>dir
 ドライブ X のボリューム ラベルは SYSTEM です
 ボリューム シリアル番号は xxxx-xxxx です

 X:\ のディレクトリ

2019/07/26  06:20    <DIR>          EFI
2018/07/18  04:18    <DIR>          BOOT
               0 個のファイル                   0 バイト
               2 個のディレクトリ     233,144,320 バイトの空き領域
EFI を覗くと…
X:\>cd EFI
ubuntuがありました。
X:\EFI>dir
 ドライブ X のボリューム ラベルは SYSTEM です
 ボリューム シリアル番号は xxxx-xxxx です

 X:\EFI のディレクトリ

2018/07/18  04:18    <DIR>          .
2018/07/18  04:18    <DIR>          ..
2018/07/18  04:18    <DIR>          Microsoft
2019/07/26  06:21    <DIR>          Boot
2019/07/26  06:21    <DIR>          ubuntu
               0 個のファイル                   0 バイト
               5 個のディレクトリ     233,144,320 バイトの空き領域
rmdir /S で削除
X:\EFI>rmdir /S ubuntu
ubuntu、よろしいですか (Y/N)? y
再度dirコマンドで、ubuntuが消えてるか確認
X:\EFI>dir
 ドライブ X のボリューム ラベルは SYSTEM です
 ボリューム シリアル番号は xxxx-xxxx です

 X:\EFI のディレクトリ

2018/07/18  04:18    <DIR>          .
2018/07/18  04:18    <DIR>          ..
2018/07/18  04:18    <DIR>          Microsoft
2019/07/26  06:21    <DIR>          Boot
               0 個のファイル                   0 バイト
               4 個のディレクトリ     236,957,696 バイトの空き領域
ubuntuが無事、削除されていることを確認できました。

OSを再起動し、終了です。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T02:52:57+09:00

Oracle Cloud InfrastructureでOS Management Serviceがリリースされたよ

0. 前提条件

Oracle Cloud Infrastructure Compute

Oracle Linux 6, 7, 8

1. OS Management Serviceがリリース！

Linux好きの筆者にとって興味のあったOracle Autonomous Linux。世界で一番早く一番詳しい記事を書いた、と勝手に思っている。

Oracle Autonomous Linuxをハックする Part 1, Part 2, Part 3

そして、ついに待望のOS Management Serviceがリリースされた。

2019/12/17 OS Management Service Released

ただし、以下のドキュメントを見ると「東京リージョン」は含まれていない。

In an Industry First, Oracle Brings Autonomous Operation to Linux

OS Management Service is currently generally available in the following Oracle Cloud Infrastructure regions: US East (Ashburn), US West (Phoenix), Canada Southeast (Toronto), UK South (London), Germany Central (Frankfurt).

2. マニュアルを眺める

マニュアル「Overview of OS Management」が公開されているので、サクッと眺めてみよう。

The Oracle Cloud Infrastructure OS Management service provides tools for common operating system management tasks for Compute instances, focusing initially on managing software packages for Oracle Linux instances.

OS Management Serviceは、Computeインスタンスのオペレーティング・システム管理ツールで、最初はLinuxインスタンスのパッケージ管理機能を提供する。

気になるところをピックアップすると以下のとおり。

OS Management ServiceでComputeを管理するには、OS Management Agentのインストールが必要

OS Management Serviceを有効にすると、Computeにインストールしたパッケージを参照／追加／更新／削除できる

OS Management Service管理下のインスタンスは、個別もしくはグループ化して管理できる

Computeインスタンスのパッケージ管理は、ジョブとして即時実行やスケジュール実行（1回、定期間隔）ができる

OS Management Service管理下のインスタンスは独自のリポジトリを参照し、リポジトリはルート・コンパートメントに配置される

対象のOSは、Oracle Linux 6, 7, 8

インスタンスをOS Management Serviceに登録すると、既存のYumリポジトリは無効化される。再度有効にするには設定が必要

テナントで最初にOS Management Serviceを利用するときは、インスタンスを登録してから60分から90分かかる。利用できるようになるとメールが送られてくる

「あれっ、OS Management ServiceはOracle Autonomous Linux固有の機能じゃないの？」

ほとんどの機能は想定内だが、一番驚いたのはOracle Autonomous Linux以外もサポートされることだ（あとで、このことも覆る）。

3. Oracle Autonomous Linuxインスタンスの作成

最初はろくにマニュアルを読まなかったこともあり、早速PhoenixでOracle Autonomous Linuxインスタンスを作成する。

以前と作成画面の違いは以下の点だ。

Oracle Autonomous Linuxは、Oracle ImagesではなくPlatform Imagesから選択する

ページ下方の[Show Advanced Options]をクリックすると[Use Oracle Cloud Agent to mange this instance]が表示されること。東京リージョンなど非サポートリージョンでは表示されない

ログインすると、いきなりNotificationsとの連係を促すメッセージが表示された。
Welcome to Autonomous Linux
Effective kernel version is 4.14.35-1902.8.4.el7uek.x86_64
Please add OCI notification service topic OCID with
$ sudo al-config -T [topic OCID] ★この行までがログインメッセージ
[ opc@hostname ~]$
Part 1でNotificationsの事前準備は終わっているので早速実行。成功すると、メールが送信されてくる。
$ sudo al-config -T ＜トピックのOCID＞
4. OS Management Serviceを使う

準備が整ったので、目的のOS Management Serviceを使ってみよう。

4-1. OS Management Agentのインストール

マニュアルに書いてあるとおりにosms-agentをインストールする。あれっ、パッケージがない。
$ sudo yum install osms-agent
Loaded plugins: langpacks, ulninfo
No package osms-agent available. ★無いと言っている
Error: Nothing to do
yum searchやyum list availableを使っても見つからない。ひょっとしてYumリポジトリへのアップロードが遅れているのか？　それともリポジトリのインデックス・ビルド忘れか？などとブツブツ。

ひょっとしてol7_ociyum_configリポジトリにあるのでは？

リポジトリの詳細は、こちらのエントリを参照。OCI固有のリポジトリで、通常は認証が必要なものが公開されている。なおol7_ociyum_configとoci_yum_includedは同じリポジトリで名前が違うだけだ。
$ sudo yum repolist all
Loaded plugins: langpacks, ulninfo
repo id                        repo name                           status
al7/x86_64                     Autonomous Linux 7Server (x86_64)   enabled: 1569
★中略
ol7_latest/x86_64              Oracle Linux 7Server Latest (x86_64 disabled
ol7_latest_archive/x86_64      Oracle Linux 7Server Latest (x86_64 disabled
ol7_ociyum_config              OCI specific release packages Oracl disabled　★こいつ
イェーイ、ビンゴ！！！　ol7_ociyum_configにあった。
$ sudo yum --enablerepo=ol7_ociyum_config search osms-agent
Loaded plugins: langpacks, ulninfo
=========================== N/S matched: osms-agent ============================
osms-agent.x86_64 : OS Management Service Agent

  Name and summary matches only, use "search all" for everything.
osms-agentをインストールする。
$ sudo yum --enablerepo=ol7_ociyum_config install osms-agent -y
Oracle Autonomous Linux 7の場合
何だかメッセージが表示される。Oracle Autonomous Linuxのコア・パッケージal-configと両立できない？
Running transaction
  Installing : osms-agent-0.0.1-444.el7.x86_64                              1/1
OSMS Agent: Not permitted to run: "al-config" package is present
  Verifying  : osms-agent-0.0.1-444.el7.x86_64                              1/1

Installed:
  osms-agent.x86_64 0:0.0.1-444.el7

Complete!
インストールできたがサービスは停止している。
$ sudo systemctl is-active osms-agent
inactive
Oracle Linux 7の場合
Oracle Linux 7にインストールするとメッセージは表示されない。osms-agentを提供するリポジトリはデフォルトで有効なので、明示的に有効にする必要は無い。
$ sudo yum install osms-agent -y
★中略
Running transaction
  Installing : osms-agent-0.0.1-444.el7.x86_64                                  1/1
  Verifying  : osms-agent-0.0.1-444.el7.x86_64                                  1/1

Installed:
  osms-agent.x86_64 0:0.0.1-444.el7

Complete!
osms-agentサービスは起動している。
$ sudo systemctl is-active osms-agent
active
Oracle Linux 7ではインストールに成功したが/var/log/messagesにはエラーが出まくっている。また「OS Management Serviceの登録に成功した」メールも来ない。管理コンソールをみてもダメっぽい。

いろいろ試したけれどNG。ひょっとしてバグ？それとも何か足りない？

現在のパッケージ情報はこちら。なんと「0.0.1」というプロダクションとは思えないバージョン番号。さらにVendorは通常「Oracle America」なのに個人IDっぽい。個人の環境でビルドしている？
$ rpm -qi osms-agent
Name        : osms-agent
Version     : 0.0.1　★！！！
Release     : 444.el7
Architecture: x86_64
Install Date: Wed 18 Dec 2019 11:42:07 PM JST
Group       : default
Size        : 50250298
License     : https://oss.oracle.com/licenses/upl/
Signature   : RSA/SHA256, Fri 13 Dec 2019 07:30:36 AM JST, Key ID 72f97b74ec551f03
Source RPM  : osms-agent-0.0.1-444.el7.src.rpm
Build Date  : Fri 13 Dec 2019 05:01:24 AM JST
Build Host  : a44c08b17889
Relocations : /
Packager    : <@a44c08b17889>
Vendor      : @a44c08b17889　★おかしい
URL         : https://docs.cloud.oracle.com/iaas/
Summary     : OS Management Service Agent
Description :
OS Management Service Agent
4-2. ここまでのまとめ

冷静に考えれば、Oracle Autonomous Linuxは毎日アップデートを適用する仕組みだ。それに対してOS Management Serviceは、ある程度のサーバをまとめて、定期／不定期に管理する仕組みに思える。

つまり相反する思想である。

OS Management ServiceはOracle Autonomous Linux専用のサービスだと思っていたけれど、どうやら勘違いだったようだ。

5. まとめ（仮）

まだ使えていないので、まとめを書くのは早急だが、推測を含めて書いてみる。

OS Management ServiceはOracle Linux 6, 7, 8を対象としたサービス。Oracle Autonomous Linuxは対象外

複数のサーバー群をまとめたパッケージ管理ができる

「OS Management Service管理下のインスタンスは独自のリポジトリを参照し、リポジトリはルート・コンパートメントに配置される」という記述から

OS Management Serviceは、Red Hat Satelliteや、そのクローンであるSpacewalkのようなパッケージ管理ツール

と推測できる。マニュアルにはfocusing initiallyと書いていたので、今後は拡張するのだろうけど。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T01:58:17+09:00

php7.2をインストールした後、phpコマンドが効かない件

php7.2のインストール

以下のコマンドを打ちました。
# sudo wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# sudo rpm -ivh epel-release-latest-7.noarch.rpm
# sudo yum-config-manager --enable remi-php72
# sudo yum install -y php72 php72-php
さてさて、ちゃんとインストールできたか確認するか。
# php -v
phpのバージョンを確認
-bash: php: command not found
ん？？

phpのコマンドが見つからないだと。。。
# php72 -v
これならうまくいくのです。

ただ、コマンドがphp72ではなく、phpでないと結構不便が出てきたり。。。
scl enable php72 bash
このコマンドを打つことによって、一時的にだがphpコマンドが使えるようになる。
一度ログアウトすると設定は消える。

　 Tweet
Qiitaで続きを読む

投稿日：2019-12-19T01:11:38+09:00

お手軽防犯システム「Ban-Ken Johnny」を作ってみた?

MAN WITH A MISSION
頭はオオカミ、体は人間の究極の生命体。
彼らは自分たちの音楽で世界征服を目指す、最高にアツい集団だ。

そんな「MAN WITH A MISSION」のGt,Vo,Rap ジャン・ケン・ジョニー(Jean-Ken Johnny)と番犬をかけあわせた、というのが「Ban-Ken Johnny（番犬ジョニー）」の由来である。
オオカミと番犬、イヌ科の奇跡のコラボレーション!
センスしかないですね(笑)
ファンクラブ会員限定の１０周年記念ツアー当たって欲しいなぁ...

はい、前置きはこれぐらいにして「Ban-Ken Johnny」の機能を紹介します。

「Ban-Ken Johnny」の機能

人感センサーで人の気配を感知したら、スマホにアラートメッセージを送る

自分が家にいる間はセンサーが反応して欲しくないので、監視機能のON/OFFを切り替えできる。

毎回家出る時にon/offするのはメンドイので、家の外からオンラインでアラート通知をON/OFFできる

「Ban-Ken Johnny」にできることはざっとこれぐらいです。
イメージがつきやすいように「Ban-ken Johnny」のデモをしました。

1.監視機能をON

監視機能はOFFになっているので、startボタンを押してONにします。

ONになりました。

2.家に誰か侵入（ラズパイの人感センサーに反応）

監視機能がONの状態で、

家に設置されているラズペリーパイの前を誰かが横切ります（なぜか物悲しい写真ですね...笑）

そうすると、

自分のスマホに通知が飛んできました！
まあこんな感じです笑
デモでイメージを掴んでいただいたところで、「Ban-Ken Johnny」の仕組みを紹介します。

「Ban-Ken Johnny」の概要

図だけ見てもよくわからないと思うので、ここからは仕組みを少しだけ詳しく説明して行こうと思います。
興味ないよーという方は編集後記まで読み飛ばしてください

1.Mattermost

Mattermostは自分が侵入者検知メッセージを受け取るために使用します。
別にSlackでも良かったのですが、勉強のためにも自分でチャット環境を用意してみることにしました。
今回MattermostはEC2上でdockerを使って動かします。
個人利用なので、preview版を使うことにしました。
mattermost/mattermost-preview
preview版は一つのコンテナ内に、mattermostアプリとmysqlが動作していて、コンテナ一つを動かすだけでmattermostを使用できます。

加えてmattermostの前段にnginxも置いてみることにしました。(理由はなんとなくカッコイイから)
Mattermostは親切なので、Mattermost用のnginx.confを用意してくれています。
これをありがたく使わせてもらいます。

それらを踏まえると、mattermostを動かすためのdocker-compose.ymlはこんな感じになります。
docker-compose.yml
version: "3"
services: 
  nginx:
    image: nginx:1.17
    container_name: nginx
    volumes: 
      - "./etc/nginx:/etc/nginx"
      - "./var/log/nginx:/var/log/nginx"
    ports: 
     - 8080:80
    links: 
     - mattermost

  mattermost:
    image: mattermost/mattermost-preview
    container_name: mattermost
    volumes: 
      - "./mysql:/var/lib/mysql"
ディレクトリ構成はこんな感じです。
./mattermost
├── ./docker-compose.yml
├── ./etc
│   └── ./etc/nginx
│       └── ./etc/nginx/nginx.conf
├── ./mysql
└── ./var
    └── ./var/log
        └── ./var/log/nginx
今回はEC2で動かして、その前段にELBとRoute53を置きます（ELB置くならnginxいるのか？というツッコミはなしで）
Route53で設定したドメイン名（ban-ken-johnny.example.comとします）にアクセスしてみます

はい、無事表示されました。
（よくわからないところで凝り性を発揮してしまい、https対応のためにAWS Certificate Manager使って証明書発行したり、ALBでHTTPtoHTTPS対応したりしたんですが、長くなるのでまたの機会に書けたらなぁと...）

とりあえずアカウントを作成してログインします。
ログインしてやったこととしては、「Ban-Ken Johnny」がアラートメッセージを送って来れるように、Incominng Webhookの設定と、プッシュ通知サーバーの設定をしました。
ただ自前でpush通知用サーバーを用意するほど余裕がなかったので、Mattermostが用意してくれているテスト確認用のサーバーを使うことにしました。
あんまり通知飛ばさないと思うのでMattermostさんご容赦を...

さて、もろもろを終えると「Ban-Ken Johnny」からWebhook経由でメッセージを送り、スマホに通知がくるということができるようになります。

イイ感ジデスネ、YES!YES!

2. Flask App

オンラインからをアラート通知をon/offにするために、アラートの状態を管理してくれるアプリをFlaskで実装しました。
本当に簡単なアプリで、機能としては

/startや/stopのGETリクエストがきたら、DBのstatusカラムの値を変更する

という本当にただそれだけのアプリです。
このアプリもdockerを使ってEC2上で動かします。
docker-compose.yml
version: "3"
services: 
  nginx:
    image: nginx:1.17
    container_name: nginx_flask
    volumes: 
      - "./etc/nginx:/etc/nginx"
    ports: 
     - 8081:80
    links: 
     - flask-app

  flask-app:
    build: ../
    image: flask-app
    container_name: flask-app
    environment:
      - DB_USER=root
      - DB_PASSWORD=setting_password
      - DB_HOST=mysql_flask
      - DB_NAME=flaskdb
    links: 
      - mysql

  mysql:
    container_name: mysql_flask
    image: mysql:5.7
    environment:
      - MYSQL_ROOT_PASSWORD=setting_password
      - MYSQL_DATABASE=flaskdb
    volumes:
      - ./sql:/docker-entrypoint-initdb.d
    command: "mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci"
ディレクトリ構成はこんな感じです。
./flask-app
├── ./Dockerfile
├── ./config
│   └── ./config/config.py
├── ./definitions
│   ├── ./definitions/__init__.py
│   └── ./definitions/database.py
├── ./docker
│   ├── ./docker/docker-compose.yml
│   ├── ./docker/etc
│   │   └── ./docker/etc/nginx
│   │       └── ./docker/etc/nginx/nginx.conf
│   └── ./docker/sql
│       └── ./docker/sql/init_ddl.sql
├── ./models
│   ├── ./models/__init__.py
│   ├── ./models/alert_status.py
│   └── ./models/dao
│       ├── ./models/dao/__init__.py
│       └── ./models/dao/alert_status.py
├── ./requirements.txt
└── ./server.py
これにより、アラートの状態を管理してくれる簡単なAPIが完成しました。

これぐらいならAmazon API Gateway → AWS lambda → Amazon DynamoDBの完全サーバレス構成にできそうなので、時間ができたらサーバレス構成に変更して見たいと思います。

3. S3(Front End)

スマホからオンラインでアラートのON/OFFを命令するためのフロントエンドは、Amazon S3 での静的ウェブサイトのホスティングを使って動かすことにしました。
正直フロント技術はほとんど触ってきていないところで、かつデザインのセンスもないのでパパッと手軽に実装して、S3にデプロイしちゃいました。
本当はVue.jsとか使いたいし、CSSも初心者感を無くしたいし...
そんなのは夢のまた夢で、イケてない見た目になっちゃいました...
ごめんねジョニー...

4. RaspberryPi

さあ最後に、ラズパイを触っていきます。
「Ban-Ken Johnny」を作るために、今回初めてラズパイを購入しました。
今年一年頑張った自分へのクリスマスプレゼントですね

ラズパイには、「人感センサーをつけて、人の気配を検知したらMattermostにアラート通知する」という、根幹の部分を担ってもらいます。
このプロセスは常時動きながら家を監視しておいて欲しいので、systemdを使ってデーモンプロセスとして動かすことにしました。

プロセスとして動かすpythonのスクリプトはこんな感じ。
ban-ken-johnny.py
#!/usr/bin/python3

import requests
import json
from time import sleep
from datetime import datetime
import dateutil.tz as tz
import sys
import RPi.GPIO as GPIO

GPIO_PIN = 18

GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN, GPIO.IN)

STOPPED_STATUS = 2
WEBHOOK_URL = 'https://ban-ken-johnny.example.com/hooks/abcdefghijklmnopqrstuvwxyz'

def is_alert_stopped():
    response = requests.get("https://ban-ken-johnny.example.com:8080/getAlertStatus")
    content = json.loads(str.strip(response.content.decode("utf-8")))

    if int(content['status']) == STOPPED_STATUS:
        return True

    return False


def post_alert():
    headers = {'content-type': 'application/json; charset=UTF-8'}
    now = datetime.today().astimezone(tz.gettz('Asia/Tokyo')).strftime('%Y/%m/%d %H:%M')
    payload = {
                    "text": "侵入者ヲ検知シマシタ!:wolf:",
                    "channel": "town-square",
                    "attachments": [
                        {
                            "text": "**Time:** "+now,
                            "mrkdwn_in": ["text"]
                        }
                    ]
              }
    response = requests.post(WEBHOOK_URL, data=json.dumps(payload), headers=headers)
    res = {
        "status" : str(response.status_code),
        "mesage" : response.content.decode("utf-8")
    }
    return json.dumps(res)


if __name__ == "__main__":
    try:
        while True:
            if GPIO.input(GPIO_PIN) == GPIO.HIGH:
                if is_alert_stopped() == False:
                    post_alert()
                sleep(10)
    except Exception as err:
        print(str(err))
        sys.exit(1)
    finally:
        GPIO.cleanup()
このpythonプロセスをsystemdを使ってデーモンプロセスとして登録するために、ban-ken-johnny.serviceファイルを用意します。
ban-ken-johnny.service
[Unit]
Description=Ban-Ken Johnny
Requires=network.target

[Service]
Type=simple
ExecStart=/opt/ban_ken_johnny.py
Restart=always

[Install]
WantedBy=multi-user.target
このban-ken-johnny.serviceを/etc/systemd/system直下に置き、ban-ken-johnny.pyは、serviceファイルのExecStartで指定しているように、/opt直下に置きます。
準備ができたらコマンドを実行して、ban-ken-johnny.serviceを起動します
#rootにpython-dateutilをインストール
$ sudo pip3 install python-dateutil
$ sudo systemctl daemon-reload
$ sudo systemctl start ban-ken-johnny.service
#OSが起動したらプロセスも自動起動する様にする
$ sudo systemctl enable ban-ken-johnny.service
プロセスのステータスを確認してみます。
$ sudo systemctl status ban-ken-johnny.service
● ban-ken-johnny.service - Ban-Ken Johnny
   Loaded: loaded (/etc/systemd/system/ban-ken-johnny.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-12-12 21:20:20 JST; 8s ago
 Main PID: 3010 (ban_ken_johnny.)
    Tasks: 1 (limit: 2200)
   Memory: 11.7M
   CGroup: /system.slice/ban-ken-johnny.service
           └─3010 /usr/bin/python3 /opt/ban_ken_johnny.py

12月 12 21:20:20 raspberrypi systemd[1]: Started Ban-Ken Johnny.
ちゃんと動いてますね?
あとは人感センサーが反応したら、ちゃんと通知がくるか確認するだけです!

無事動作しました！！
ちゃんとON/OFFにしたがって、通知を飛ばしてきてくれます！！
ヤッタゼ！！

これで「Ban-Ken Johnny」は完成です。
お手軽と言いながら、地味に時間かかっちゃいました...
これで家の留守中も安心です?

編集後記

完成して使い始めたは良いものの、なぜか２分置きにGPIOからinputを検知してしまうという不具合が発生しました。
そのため２分置きに「侵入者ヲ検知シマシタ！?」と送信してきます。
鬼メッセージ送信機へと成り下がってしまったジョニーをどうにかして直したいのですが、ラズパイ初心者の私にはお手上げ状態です...
アドベントカレンダーの締め切りもあったので、すぐに届くセンサーをAmazonで選んで購入したのですが、そのセンサーが悪かったのかもしれません...
今見たら誰も評価してないし...

一応GitHubにも公開しているので、参考までに...
トリアエズ有識者ノ皆サマ、是非オ助ケヲ！！