ラベル Raspberry Pi の投稿を表示しています。 すべての投稿を表示
ラベル Raspberry Pi の投稿を表示しています。 すべての投稿を表示
2024年2月24日土曜日

Raspberry Pi 4上のUbuntuにKubernetesを構築する

本ブログでは、数回に分けてKubernetesの構築手順を記載してきた。

今回は、Raspberry Pi 4上のUbuntuに対してKubernetesを構築する手順を記載する。

環境

今回の手順を検証した環境は以下となる。

  • HW: Raspberry Pi 4 Model B(RAM 4GB)
  • OS: Ubuntu 22.04.4 LTS
  • コンテナランタイム: Docker : 24.0.1
  • CRI: cri-dockerd: 0.3.10-dev
  • Kubernetes: v1.28.5

手順

1. Dockerのインストール

Dockerのインストールはaptを使って実施するが、その際に利用する前提パッケージを先にインストールする。

sudo apt install apt-transport-https ca-certificates curl software-properties-common

Dockerのリポジトリを登録する。以前はapt-keyコマンドでも同様の登録ができてが、現在は非推奨となっていることから、curlでキー情報を入手し、登録する手順を実施する。

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Docker CEやその他必要となるパッケージをインストールする。

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Dockerの初期設定として、daemon.jsonを作成する。

$ sudo vi /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2",
  "insecure-registries": [
    "192.168.11.50"
  ]
}

Dockerのサービスを起動する。

sudo systemctl daemon-reload
sudo systemctl enable docker
sudo systemctl restart docker

2. Kubernetesインストール

Dockerと同様、Kubernetesもaptでインストールするため、リポジトリを登録する。

Kubernetes 1.28.xを使用する場合

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring_1.28.gpg
echo \
  'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | \
  sudo tee /etc/apt/sources.list.d/kubernetes_1.28.list
sudo apt update

Kubernetes 1.29.xを使用する場合

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo \
  'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update

kubelet、kubeadm、kubectlをインストールする。今回は既存のKubernetesクラスターに追加するため、バージョンを1.28.5に固定している。さらにapt-mark holdをすることで、インストールしたパッケージが想定されないタイミングでバージョンアップされないようにしている。

sudo apt-get install kubelet=1.28.5-1.1 kubeadm=1.28.5-1.1 kubectl=1.28.5-1.1
sudo apt-mark hold kubelet kubeadm kubectl

kubeletのサービスを起動する。

sudo systemctl daemon-reload
sudo systemctl enable kubelet
sudo systemctl restart kubelet

3. Swap無効化

Kubernetesの前提条件として、Swapを無効化する必要がある。Raspberry PiのUbuntuの場合は、そもそもSwapが設定されておらず、totalの値が0になっているため、このまま作業を続行する。

$ free
               total        used        free      shared  buff/cache   available
Mem:         3880992      226264     2100932        3552     1553796     3472052
Swap:              0           0           0

4. cri-dockerdインストール

cri-dokerdはGo言語でコンパイルする必要があるため、まずはGoのインストールを行う。なお、Ubuntuの標準リポジトリのGoはバージョンが古いため、PPA (Personal Package Archives)のリポジトリ追加を行ったうえでインストールを行う。

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt update
sudo apt install golang-go

なお、今回のインストールされたGoのバージョンは、1.21.7となる。

$ go version
go version go1.21.7 linux/arm64

cri-dockerdのビルドと配置を行う。

go build -o bin/cri-dockerd
sudo install -o root -g root -m 0755 bin/cri-dockerd /usr/local/bin/cri-dockerd
sudo cp -a packaging/systemd/* /etc/systemd/system
sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service

cri-dockerdのサービスを起動する。

sudo systemctl daemon-reload
sudo systemctl enable cri-docker.service
sudo systemctl start cri-docker.socket

5. Kubernetes起動

最後にKubernetesを起動するが、初めてKubernetesクラスターを構成する場合はkubeadm initを、既存のクラスターに参加する場合はkubeadm joinを行う。

それぞれ、過去記事を参考に対応をいただきたい。

新規にKubernetesクラスターを構成する場合

既存のKubernetesクラスターに参加する場合

今回は既存のクラスターに参加した。結果、以下の通りUbuntu 22.04.4 LTSのノードがKubernetesに登録できた。

$ kubectl get node -o=wide
NAME        STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                    KERNEL-VERSION              CONTAINER-RUNTIME
t1015rasp   Ready    control-plane   26h    v1.28.5   192.168.3.5   <none>        Ubuntu 22.04.4 LTS          5.15.0-1046-raspi           docker://25.0.3
t3051kube   Ready    control-plane   276d   v1.28.5   192.168.3.1   <none>        AlmaLinux 8.6 (Sky Tiger)   4.18.0-372.9.1.el8.x86_64   docker://24.0.6
t3052kube   Ready    control-plane   276d   v1.28.5   192.168.3.2   <none>        AlmaLinux 8.6 (Sky Tiger)   4.18.0-372.9.1.el8.x86_64   docker://24.0.6

以上で、Raspberry Pi 4上のUbuntuに対してKubernetesを構築する手順は完了となる。

2024年1月21日日曜日

Raspberry Pi OSなどのDebian系OSのviで、方向キーによる移動やバックスペースを使えるようにする

Raspberry Pi OSなどのDebianベースのOSにおいてviを使う際に、入力モード(i または aを押して文字入力ができる状態)にした際に方向キーで移動しようとすると、ABCDの文字が入力されてしまう。

方向キーと文字の関係は以下の通り。
   A
   |
D -+- C
   |
   B
とても不便なので、viで方向キーを用いても通常通りカーソルを移動できるように設定する。併せてviでバックスペースも正常に使用できるように対処する。

設定手順

各ユーザーのホームディレクトリに.vimrcというファイルを作成し、以下2行の設定を書き込んでやればよい。
set nocompatible
set backspace=indent,eol,start
ワンライナーで設定したい場合は以下の通り実施する。すでに.vimrcがある可能性を考慮して、追記でリダイレクトしている。
$ echo -e "set nocompatible\nset backspace=indent,eol,start" >> ~/.vimrc
$ cat ~/.vimrc
set nocompatible
set backspace=indent,eol,start
これだけで、特に再ログイン等も不要で、次回vi実行時から設定が反映され、入力モードであっても方向キーが使えるようになる。

更新履歴

  • 2018/3/26 新規作成
  • 2024/1/21 補足情報を追記
2021年4月3日土曜日

ESXi Arm Editionをバージョンアップする手順 (v1.3対応)

2020年10月6日にv1.0がリリースされたESXi Arm Editionは、定期的にバージョンアップがされており、2021年4月2日に久しぶりに新バージョンであるv1.3がリリースされた。ビルド番号は以下の通りとなる。

  • v1.0 : Build 16966451
  • v1.1 : Build 17068872
  • v1.2 : Build 17230755
  • v1.3 : Build 17839012

修正内容は以下URLに記載がされているが、私の環境では特にvCenter Serverで管理もしていないことから、大きく影響を受けるようなBug Fixはなさそうに見える。

ただ、今後も頻繁に新バージョンがリリースされそうな雰囲気もあることから、ESXi Arm Editionのバージョンアップを実施した。

環境

前提として、Raspberry Pi 4にESXi Arm Editionがインストール済みであることが必要となる。手順は以下記事を参照いただきたい。

バージョンアップ手順

1. ESXi Arm Editionの新イメージを入れたUSBメモリを作成

当初からESXi Arm EditionがインストールされているUSBメモリとは別に、バージョンアップ用としてもう1つUSBメモリを準備し、「Rufus」を使ってESXi Arm Editionの新しいバージョンのISOイメージ「VMware-VMvisor-Installer-7.0.0-<ビルド番号>.aarch64.iso」を選択し、USBメモリに書き込みを行う。

作成後は、Raspberry Pi 4の空いているUSBポートに接続しておこう。

2. ESXiを再起動

VMware Host Clientなどを利用してESXiサーバを再起動する。

3. ESXi Arm Editionの新イメージのUSBメモリからブートする

Raspberry Pi起動画面が表示されているタイミングでESCキーを押してUEFIにログインし、「Boot Manager」を選択する。ESXi Arm Editionの新イメージのインストーラが入ったUSBメモリを選択してブートする。

4. ESXiのインストール先として既存のUSBメモリを選択する

ESXiのインストーラが起動し、途中ESXiのインストール先の選択画面が表示されるので、当初からESXiがインストールされているUSBメモリを選択する。

この際に、「ESXi and VMFS Found」の画面が表示されるので、「Install ESXi, preserve VMFS datastore」を選択する。

ここで注意事項となるが、ESXi Arm Edition v1.1以降にバージョンアップする際は、VMFSのデータは維持するものの、ESXiとしての設定はすべて初期化されてしまう。これは公式サイトのChangelogでも以下の通り記載されている。

October 22, 2020 - v1.1

Note: Upgrade is NOT possible, only fresh installation is supported. If you select “Preserve VMFS” option, you can re-register your existing Virtual Machines.

したがって、ESXiインストール後に、再度必要な設定を実施する必要がある。

5. インストール後にESXiの再設定を実施

インストールが完了しESXiが起動したのち、ESXiに対して実施していた設定を再度投入する。以下は私の環境で実施した作業となる。特に、NTPサーバを設定しないとかなり時刻がずれた状態で起動してしまうため、忘れずに再設定をすること。

  • 固定IPアドレス設定
  • DNS・ホスト名設定
  • NTP設定
  • ユーザ・権限設定
  • iSCSI設定
  • 仮想マシンをvmxファイルから再登録

以上でESXi Arm Editionのバージョンアップ作業は完了となる。以下はv1.0からv1.1にバージョンアップした際の例となるが、ESXiのバージョン表記が「ESXi on Arm Fling (Build 17068872)」となっていることがわかる。

更新履歴

  • 2020/10/24 新規作成
  • 2021/4/3 v1.3リリースに合わせて情報を最新化
2020年10月17日土曜日

ESXi Arm Edition上のLinuxにopen-vm-toolsをインストールする手順

先日、Raspberry Pi 4にESXi Arm Editionを導入した。

せっかくARMのCPUを使えるESXiが誕生したので、CentOS、Ubuntu、そしてPhoton OSをESXi上にインストールしたのだが、これらのARM版Linuxディストリビューションにはopen-vm-toolsが導入されていない

さらには、現時点(2020年10月)では、ARM版のCentOS、Ubuntuでは、open-vm-toolsのパッケージが提供されておらず、以下のソースからビルドする必要があり、手順が少々複雑となる。

今回、各ARM版のOSに対して、open-vm-toolsを導入する手順を記載する。

作業前提事項

  • gitdnfaptを使うので、インターネット環境が必要
  • 時刻同期設定ができており、時刻がずれていないこと (時刻がずれているとdnf等がエラーになることがある)

ARM版CentOS 8

OSのインストールイメージは以下URLからダウンロードを行い、「最小インストール」にてインストールを行った。本記事執筆時点では、バージョンは「8.2.2004」となる。

以下コマンドを上から順に実行することで、open-vm-toolsをソースからビルドしインストールすることができる。

# パッケージをインストール
dnf install git automake make pkg-config libtool glib2-devel libtirpc-devel -y
dnf --enablerepo=PowerTools install rpcgen -y

# ソースをクローン
git clone https://github.com/vmware/open-vm-tools.git

# ソースよりビルド (10分ほど要する)
cd open-vm-tools/open-vm-tools/
autoreconf -i
./configure --without-x --without-pam --without-ssl --enable-deploypkg=no
make
make install
ldconfig

# systemdに登録
cat << EOF > /etc/systemd/system/vmtoolsd.service
[Unit]
Description=Service for virtual machines hosted on VMware
Documentation=http://github.com/vmware/open-vm-tools

[Service]
ExecStart=/usr/local/bin/vmtoolsd
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
EOF

# open-vm-tools起動
systemctl start vmtoolsd
systemctl enable vmtoolsd

Ubuntu Server for ARM

OSのインストールイメージは以下URLからダウンロードを行い、特にパッケージ追加は行わずにインストールを行った。

以下コマンドを上から順に実行することで、open-vm-toolsをソースからビルドしインストールすることができる。

# パッケージをインストール
sudo apt install automake make pkg-config libtool libglib2.0-dev -y

# ソースをクローン
git clone https://github.com/vmware/open-vm-tools.git

# ソースよりビルド (10分ほど要する)
cd open-vm-tools/open-vm-tools/
autoreconf -i
./configure --without-x --without-pam --without-ssl --enable-deploypkg=no
make
sudo make install
sudo ldconfig

# systemdに登録
cat << EOF | sudo tee /etc/systemd/system/vmtoolsd.service > /dev/null
[Unit]
Description=Service for virtual machines hosted on VMware
Documentation=http://github.com/vmware/open-vm-tools

[Service]
ExecStart=/usr/local/bin/vmtoolsd
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
EOF

# open-vm-tools起動
sudo systemctl start vmtoolsd
sudo systemctl enable vmtoolsd

ARM版Photon OS

OSのインストールイメージは以下URLから「Photon OS 3.0 Revision 2 Update1 Binaries」をダウンロードし、「Photon Minimal」にてインストールを行った。

Photon OSはさすがにVMware社謹製のLinuxディストリビューションだけあって、ARM版であってもopen-vm-toolsのパッケージが用意されており、ソースからビルドする必要はない。ただし、コマンドがdnfではなくtdnfだったりするのでちょっと癖があるので注意。

tdnf install open-vm-tools -y
systemctl start vmtoolsd
systemctl enable vmtoolsd

私の環境ではopen-vm-toolsインストール後、「start condition failed」のエラーとなって起動に失敗した。その場合は、OS再起動を実施してみよう。

# systemctl status vmtoolsd.service
● vmtoolsd.service - Service for virtual machines hosted on VMware
   Loaded: loaded (/lib/systemd/system/vmtoolsd.service; enabled; vendor preset>
   Active: inactive (dead)
Condition: start condition failed at Sun 2020-10-11 06:26:41 UTC; 2s ago
           mq ConditionVirtualization=vmware was not met
     Docs: http://github.com/vmware/open-vm-tools

まとめ

以上で各Linuxディストリビューションに対してopen-vm-toolsを導入することができた。これにより、ESXiから仮想マシンのIPアドレス情報が確認できたり、OSシャットダウンや再起動ができるようになり、一層便利になった。

参考

2020年10月11日日曜日

ESXi Arm EditionをRaspberry Pi 4 (メモリ4GBモデル) にインストールする手順

Raspberry Piにインストール可能な「ESXi Arm Edition」が利用できるようになったとニュースで目にした。ちょうど、使い道が決まってなくて放置していたRaspberry Pi 4 (メモリ4GBモデル) があったので、実際にRaspberry Pi 4にESXi Arm Editionをインストールした

公式でインストール手順が記載されたマニュアル (ESXi Arm Edition | VMware Flingsの「Fling-on-Raspberry-Pi.pdf」) が用意されてはいるが、手順が少々複雑なので、私の方でもインストール手順をまとめておく。

(2020/10/25追記)
10/22にESXi Arm Edition v1.1がリリースされたため、バージョンアップ手順を以下に記載しました。

必要なものを準備

作業前に以下が必要となるため、予め準備をしておくこと。

  • microSDカードとUSBメモリの操作ができるWindowsマシン
  • Raspberry Pi 4 (メモリ4GB以上のもの)
  • Raspberry Pi操作用のモニター・キーボード
  • microSDカード (容量は小さくてOK)
  • USBメモリ (最低でも64GB程度は欲しい)

インストーラをダウンロード

ESXi Arm Editionをインストールするには、OSイメージだけでなく、Raspberry Pi 4のUEFIのデータが必要となる。

それぞれ以下リンクからダウンロードできるので、ダウンロードしておく。

UEFI用microSDカードの作成

通常、Raspberry PiではmicroSDカードにOSイメージをインストールして起動させるが、ESXi Arm EditionはSDカードにOSをインストールすることができない。しかし、OS起動のためにはmicroSDカードにUEFIのイメージが必要となるため、UEFIのためだけにmicroSDカードが必要となる。

1. Windows OSにてmicroSDカードをマウント

Windows OSにてmicroSDカードをマウントさせる。

2. フォーマット

Raspberry Pi OSがインストールされていたmicroSDカードを利用する場合は、UEFI領域が自動で認識するはずなので、この領域を右クリック→「フォーマット」を選択して、以下内容にてフォーマットする。デフォルトから変更する箇所はボリュームラベルのみとなるはずだ。

設定項目 設定値
容量 256MB
ファイルシステム FAT32
アロケーションユニットサイズ 512バイト
ボリュームラベル UEFI
フォーマットオプション クイックフォーマット

ちなみに、未使用のmicroSDカードの場合は、UEFI用のパーティションを切ってフォーマットすればよさそうだが、未検証となる。以前別記事でも記載しているが、Raspberry Pi Imager使えばmicroSDカードのパーティションが間違いなく設定されるので、今回は一度Raspberry Pi OS LightをmicroSDカードにインストールしたのち、UEFI領域のフォーマットを行った。

★【参考】Raspberry Pi Imagerを使ったRaspberry Pi OSのインストール手順

3. 「firmware-master.zip」からファイルをコピー

事前にダウンロードしている「firmware-master.zip」をエクスプローラーで開き、「boot」フォルダーの中身をmicroSDカードにそのままコピーする。

コピーしたのち、「kernel*.img」のファイルが4つあるはずなので選択して削除する。

4. 「RPi4_UEFI_Firmware_v1.20.zip」からファイルをコピー

事前にダウンロードしている「RPi4_UEFI_Firmware_v1.20.zip」をエクスプローラーで開き、すべてのファイルをmicroSDカードにそのまま上書きでコピーする。

5. 「config.txt」を編集 (メモリ4GBモデルのRaspberry Piのみ要対応)

UEFI領域にコピーしたファイルの中に、「config.txt」というテキストファイルがある。こちらのファイルの最下行に「gpu_mem=16」を追加する。

arm_64bit=1
enable_uart=1
uart_2ndstage=1
enable_gic=1
armstub=RPI_EFI.fd
disable_commandline_tags=1
disable_overscan=1
device_tree_address=0x1f0000
device_tree_end=0x200000
dtoverlay=miniuart-bt
gpu_mem=16   ←★追加

この設定は、メモリ8GBモデルでは不要となる。メモリ4GBモデルではこの設定を実施しないと、ESXiインストール時に「MEMORY_SIZE ERROR」が表示され、メモリ不足によりインストールが続行できなくなるので注意

6. microSDカードを取り外す

以上でmicroSDカードに対する事前作業は完了したため、Windows OSから取り外し、Raspberry Piに挿入する。

UEFIの設定

1. 起動時にESCキーを押してUEFIにログイン

Raspberry Pi起動画面が表示されているタイミングでESCキーを押してUEFIにログインする。

2. UEFIの設定変更

以下画面に遷移してUEFIの設定変更を行う。

設定場所 設定項目 設定値
Device Manager > Raspberry Pi Configuration > Advanced Configuration Limit RAM to 3GB Disabled
Device Manager > Console Preference Selection Preferred console Serial
Device Manager > Raspberry Pi Configuration > Display Configuration Virtual 800x600 x
Device Manager > Raspberry Pi Configuration > Display Configuration Virtual 1024x768 x

ESXi Arm Editionのイメージを入れたUSBメモリを作成

1. USBメモリにOSイメージを書き込む

Rufus」を使ってESXi Arm EditionのISOイメージ「VMware-VMvisor-Installer-7.0.0-16966451.aarch64.iso」を選択し、USBメモリに書き込みを行う。

2. USBメモリを取り外す

USBメモリを取り外し、Raspberry PiのUSB3.0のポートに挿入する。このUSBメモリはそのままESXi Arm EdtionにてESXiが上書きインストールされ、データストア領域としても使用される

USBメモリからESXi Arm Editionをインストール

1. USBメモリからブートする

Raspberry Pi起動画面が表示されているタイミングでESCキーを押してUEFIにログインし、「Boot Manager」を選択する。

インストーラが入ったUSBメモリを選択してブートする。

2. VMFS-Lの領域を8GBに減らす

ESXi 7.0はそのままインストールすると、余った領域がVMFS-Lと呼ばれる仮想フラッシュ用の領域で使用されてしまい、VMFS領域を作ることができない (正確には128GB以下のUSBメモリの場合は、すべてVMFS-Lで使用されてしまう)。USBメモリは容量が限られていることから、VMFS-Lの領域を8GBに制限する設定を行う。

ESXiのインストール開始時に「Shift+O」を押し、ブートオプション入力画面に遷移する。ブートオプションは以下を入力する。なお、「runweasel cdromBoot」までは予め入力されている。

runweasel cdromBoot autoPartitionOSDataSize=8192

3. いつものESXiのインストール画面が表示される

ここからはいつものESXiのインストール画面と同じとなる。前述しているが、microSDカードをインストール先に選ぶことはできないので、USBメモリに対してインストールを行う。

4. ブート順位変更

問題なくインストールが完了したら、ブート順位の変更を行う。

Raspberry Pi起動画面が表示されているタイミングでESCキーを押してUEFIにログインし、「Boot Maintenance Manager > Change Boot Order」を選択する。

「Change the order」にてUSBメモリの順位を一番上に変更する。「+」と「-」キーで順位を上下させることができる。

5. NTPを設定

あとは、通常のESXiと同様にIPアドレスやホスト名の設定等を行えばよいのだが、Raspberry Piの仕様でNTPを有効にしないと日時がかなりずれてしまうようなので、最低限NTPサーバに対して時刻同期の設定は行っておこう。

ARM版のCentOS 8を動かしてみる

実際に、ARM版のCentOS 8をESXi Arm Edition上に仮想マシンとしてインストールし動かしてみた。当たり前だが、インストール手順は通常のESXiとなんら変わることはなく起動まで成功した。ただし、CPU・メモリ・USBメモリのI/O性能は高くはないため、最小限のインストールをするだけでも、そこそこ時間を要するので注意。

なお、ARM版のCentOSにはopen-vm-toolsが含まれておらず、2020年10月時点ではパッケージとしても提供されていないため、ソースからビルドする必要がある。以下別記事にて手順をまとめているので参考にしていただきたい。

まとめ

ESXi Arm Editionはまだ開発段階であり、通常のESXiであれば評価期間が60日間であるところが、180日間を評価期間として利用できるようになっている (ちなみに、無償のESXiのライセンスは投入可能だった)。

そのため、ESXi Arm Editionを積極的に使っていくにはまだ早いかもしれないが、私のように自宅で未使用となっているRaspberry Piを持っている人が動作検証する分には大変楽しいのでお勧めとなる。

2020年8月8日土曜日

Raspberry Pi OSインストール手順 (Raspberry Pi Imagerを使ったOSイメージ書き込みと初期設定)【2020年版】

2017年に購入したRaspberry Pi 3 Model Bがあったのだが、途中でRaspberry Pi Zero Wに置き換えたことにより、ずっと使わずに放置していた。ふと使いたくなって久しぶりに起動させようとしたら、Kernel Panicで起動しなくなっていたのでRaspbianをインストールしなおすことにした。

前回のインストール手順は2017年に記事としてまとめていたので、そちらを参考にしつつ、今回も同様にNOOBSを使ってインストールをしようとしたのだが、調べてみるとNOOBSではなく「Raspberry Pi Imager」を使う手順に推奨手順が変わっているらしい。

それどころかRaspbianも名前が変わって「Raspberry Pi OS」に名称が変更されているらしい。

と、いろいろ数年の間に変化があったので、再度インストール手順をまとめてみた。

Raspberry Pi ImagerにてSDカードにRaspberry Pi OSを書き込む

1. Raspberry Pi Imagerをダウンロード

以下からダウンロードする。私のダウンロードしたタイミングでは「imager_1.4.exe」というバージョンとなっていた。

2. SDカードに書き込みを行うPCにRaspberry Pi Imagerをインストール

Raspberry Pi Imagerはexe形式になっているので、実行してPCにインストールすればよい。

3. Raspberry Pi Imagerを起動し書き込み前の設定を行う

Raspberry Pi Imagerを起動するとOSとSDカードの指定を行うシンプルな画面が表示されるので、以下の通り設定する。

  • Operating System : Raspberry Pi OS (32-bit)
  • SD Card : 書き込み先のSDカードを指定

なお、SDカードは書き込み時にフォーマットされるので、未フォーマットの状態であっても問題ない。今回は、過去にインストールしたRaspbianが書き込まれた状態のまま書き込みをしたが、問題なく成功している。

4. 書き込み開始

SDカードの内容はすべて消去される旨のメッセージが表示されるので、「Yes」を選択して書き込みを開始する。

インターネット経由でデータをダウンロードしながら書き込みするので環境に依存するが、おおよそ1時間で書き込みは完了する。気長に待とう。

5. 書き込み完了

書き込みが完了すると、SDカードを自動でアンマウントしてくれるので、そのままPCから抜いて、Raspberry Piに刺せばよい。

Raspberry Piを起動&初期設定

1. 初期設定ウィザードにて設定

Raspberry Pi OS初回起動時には「Welcome to Raspberry Pi」という名前の初期設定ウィザードが表示されるので、以下の通り設定していく。

  • Set Country :
    • Country : Japan
    • Language : Japanese
    • Timezone : Asia/Tokyo
  • Change Password : 適切に設定
  • Set Up Screen : そのまま次へ
  • Set Wireless Network : しばらく待つとWi-FiのSSIDが一覧表示されるので、接続対象のSSIDを選択
  • Enter Wireless Network Password : 適切に設定
  • Update Software : そのまま次へ。アップデートは30分程要するので気長に待つ

ウィザードの最後で再起動を要求されるので、「Restart」を選択し再起動を行う。

2. SSHを有効化

Raspberry Pi OSはデフォルトではSSHが無効となっている。リモート操作ができず不便なので有効とする。端末を開き、以下を実行して「Raspberry Pi Software Configuration Tool (raspi-config)」を開く。

$ sudo raspi-config

raspi-configの画面が表示されるので、「5 Interfacing Options」を選択する。

「P2 SSH」を選択する。

「Would you like the SSH server to be enabled?」と表示される。

この画面で「はい」を選ぶとSSHが有効に、「いいえ」を選ぶとSSHが無効になる。「いいえ」が設定変更をキャンセルする意味ではなく、SSHが無効化されてしまうので注意

ESCキーでraspi-configを抜けて、sshdのステータスを確認し問題なく起動していればOKとなる。

$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-07-29 13:26:11 JST; 3s ago

~(以下略)~

3. 時刻同期設定

Raspberry Pi OSではDebianベースとなるので、時刻同期はntpdやChronyではなく「systemd-timesyncd」が利用されている。

時刻同期の状態を確認すると、「x.debian.pool.ntp.org」に対して時刻同期はされているようだ。

$ timedatectl timesync-status
       Server: 2001:470:1f07:9fe::f00d (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 1
    Reference: GPS
    Precision: 1us (-24)
Root distance: 0 (max: 5s)
       Offset: +6.899ms
        Delay: 196.933ms
       Jitter: 12.925ms
 Packet count: 9
    Frequency: -4.487ppm

私の環境の場合は、NTPサーバが存在することから、以下の折設定を変更する。

$ cat /etc/systemd/timesyncd.conf
~(中略)~

[Time]
NTP=192.168.33.23 ←★追記
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

設定を変更後、設定反映を行う。

$ sudo systemctl restart systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
$ sudo systemctl daemon-reload

反映後の時刻同期のステータスを確認する。「System clock synchronized」がYesであれば問題なく時刻同期が成功している。

$ timedatectl status
               Local time: 水 2020-07-29 13:45:55 JST
           Universal time: 水 2020-07-29 04:45:55 UTC
                 RTC time: n/a
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

同期先のサーバが変更されていればOKとなる。

$ timedatectl timesync-status
       Server: 192.168.33.23 (192.168.33.23)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: 85F3EEA4
    Precision: 1us (-26)
Root distance: 2.532ms (max: 5s)
       Offset: -1.112ms
        Delay: 5.927ms
       Jitter: 1.709ms
 Packet count: 117
    Frequency: -4.424ppm

4. 固定IP設定

DHCPによるIPアドレス設定の場合は、特にデフォルトから変更する必要はないが、固定IPアドレス設定を行う場合は「/etc/dhcpcd.conf」にてIPアドレス等の指定を行う。

$ sudo vi /etc/dhcpcd.conf
~(中略)~
interface eth0                     # 有線はeth0を指定
static ip_address=192.168.11.15/24 # IPアドレスとサブネットマスクを設定
static routers=192.168.11.31       # デフォルトゲートウェイを設定
static domain_name_servers=192.168.11.61 192.168.11.62 # DNSを設定
interface wlan0                    # 無線 (Wi-Fi) はwlan0を指定
static ip_address=192.168.33.15/24 # IPアドレスとサブネットマスクを設定

上記設定後OS再起動を行い、IPアドレスの状態を確認してみた。以下の通り、eth0とwlan0に指定した固定IPアドレスが設定されている。

$ ip a | grep -e eth0 -e wlan0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.11.15/24 brd 192.168.11.255 scope global noprefixroute eth0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.33.15/24 brd 192.168.33.255 scope global noprefixroute wlan0

5. スタティックルート設定

Raspberry Pi OSでルーティングを追加する場合は、以前以下の記事にて説明をしている。

再掲とはなるが、ルーティング追加のコマンドを「/etc/network/if-up.d/static-routes」に記載することで、OS起動時にルーティング追加できる。

$ sudo vi /etc/network/if-up.d/static-routes
#!/bin/sh
# Add Static Route
sleep 10
route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.33.31 metric 1 wlan0

$ sudo chmod +x /etc/network/if-up.d/static-routes

まとめ

以上でRaspberry Pi OSのインストールと初期設定手順は完了となる。

最後に、Raspberry Pi OSのバージョンを確認してみたところ、バージョンは10.4となっていた。

$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

$ cat /etc/debian_version
10.4
2018年3月19日月曜日

ZabbixでAllowRoot=1をせずに/var/log/messagesなどを監視する方法

LinuxのOSログといえば/var/log/messagesとなるが、このログファイルはroot権限がないと読み込みができないログファイルとなっている。

◆Redhat系Linuxの場合
# ls -l /var/log/messages
------------------------------
-rw------- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

◆Debian系Linuxの場合
$ ls -l /var/log/messages
------------------------------
-rw-r----- 1 root adm 157  3月 11 06:25 /var/log/messages
------------------------------

通常、Zabbix Agentのプロセスはzabbixユーザーの権限で動作するため、このログファイルが監視できず困る場面がある。回避策としては、Zabbix Agentをroot権限で動作させるようにすることが考えられる。Zabbix Agentをroot権限で動作させるためには、zabbix_agentd.confに以下の設定を加えればよい。

# cat /etc/zabbix/zabbix_agentd.conf | grep AllowRoot
------------------------------
### Option: AllowRoot
AllowRoot=1
------------------------------

しかし、上記方法は、Zabbix Agentがroot権限で動くことになり、セキュリティ面で推奨されない設定となる。そこで、今回はAllowRoot=1せずにログ監視できる方法を考えてみた。

zabbixユーザーをrootグループに追加して対応する

zabbixユーザーをrootグループ(後述するが、Debian系Linuxではadmグループ)に追加し、監視対象ログの権限をrootグループにて読み取り可能とすることで対応する。Linuxディストリビューションごとに若干手順が異なるため、Redhat系LinuxとDebian系Linuxの手順をそれぞれ記載することにする。

Redhat系Linuxの場合

/var/log/messagesの権限を再掲する。

# ls -l /var/log/messages
------------------------------
-rw------- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

権限は600となっているおり、rootグループのユーザーであっても読み取りができないため、まずは権限変更を行う。

# chmod 640 /var/log/messages
# ls -l /var/log/messages
------------------------------
-rw-r----- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

権限を変えても、ログローテーションされる際にもとの権限(600)に戻ってしまうため、ログローテーション時に、新しいファイルの権限を640として作成する設定を以下の通り追加する。

# cat /etc/logrotate.d/syslog
------------------------------
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    missingok
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    create 640 root root
}
------------------------------

最後にzabbixユーザーをrootグループに所属させる。

# id zabbix
------------------------------
uid=995(zabbix) gid=993(zabbix) groups=993(zabbix)
------------------------------
# usermod -aG root zabbix
# id zabbix
------------------------------
uid=995(zabbix) gid=993(zabbix) groups=993(zabbix),0(root)
------------------------------

Debian系Linuxの場合

/var/log/messagesの権限を再掲する。

$ ls -l /var/log/messages
------------------------------
-rw-r----- 1 root adm 157  3月 11 06:25 /var/log/messages
------------------------------

Redhat系Linuxと異なり、admグループに読み取り権限が付いている。したがって、zabbixユーザーをadmグループに所属させるだけで対処可能である。

$ id zabbix
------------------------------
uid=111(zabbix) gid=116(zabbix) groups=116(zabbix)
------------------------------
$ sudo usermod -aG adm zabbix
$ id zabbix
------------------------------
uid=111(zabbix) gid=116(zabbix) groups=116(zabbix),4(adm)
------------------------------

Zabbixにて確認

zabbixユーザーで読み込み権限のないファイルを監視している場合、該当のアイテムに「ZBX_NOTSUPPORTED」のエラーが表示され、ステータスが「取得失敗」となっているはずである。


ログ監視対象のサーバーのZabbix Agentのログからも、エラーが出ていることがわかる。

# tail -100 /var/log/zabbix/zabbix_agentd.log | grep messages
------------------------------
  4870:20180317:220745.694 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220815.697 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220845.700 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220845.700 active check "log[/var/log/messages,"@messages word",,,skip]" is not supported
------------------------------

zabbixユーザーに対して、必要な権限を付与し、再度監視状況を確認してみる。設定変更後数分待つとエラーが消え、ステータスが「有効」となった。


2018年3月12日月曜日

RaspbianなどのDebian系Linuxでスタティックルートを追加する方法

自宅のネットワーク環境は、仮想ルータ-であるVyOSを使って2つのセグメントに分割している。そのため、2つのセグメント間の通信を正常に実施するために、スタティックルートの設定を実施する必要がある。

先日Raspberry Piを自宅環境に導入する際も、同様にスタティックルートの設定が必要となったが、Raspberry PiのOSであるRaspbianは、CentOSなどのRed Hat系のLinuxと勝手が違ったこともあり、対応に少々苦労した。

今回は備忘録として、Raspbianでスタティックルートを追加した際の手順を記載することにする。なお、RaspbianはDebian系のLinuxとなるため、Ubuntu等の他Debian系Linuxでも同様の手順となると想定される。

環境について

今回はRaspberry Pi Zero Wに対して設定を行っており、Raspbianのバージョンは以下の通りとなる。

$ lsb_release -a
------------------------------
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch
------------------------------

スタティックルート設定手順 (一時的に追加)

取り急ぎスタティックルートを追加したい場合は、routeコマンドを利用すればよい。構文は以下の通り。

route add -net <ネットワークアドレス> netmask <サブネットマスク> gw <ゲートウェイ> metric 1 <インターフェース名>

例として、192.168.11.0/24のゲートウェイを192.168.33.31にしたい場合は、以下の通り設定する。

$ sudo route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.33.31 metric 1 wlan0

確認コマンドはrouteとなる。黄色網掛けのルートが追加されていることがわかる。ただし、あくまで一時的に追加するだけであり、OS再起動をすると消えてしまうので注意。

$ route
------------------------------
カーネルIP経路テーブル
受信先サイト    ゲートウェイ    ネットマスク   フラグ Metric Ref 使用数 インタフェース
default         192.168.33.1    0.0.0.0         UG    302    0        0 wlan0
192.168.11.0    192.168.33.31   255.255.255.0   UG    1      0        0 wlan0
------------------------------

スタティックルート設定手順 (恒久的に追加)

OS再起動してもスタティックルートを消えないようにするためには、「/etc/network/if-up.d/static-routes」という設定ファイル(というかスクリプト)を新規に作成し、起動時にスタティックルートが追加がされるようにすればよい。

$ sudo vi /etc/network/if-up.d/static-routes
------------------------------
#!/bin/sh
# Add Static Route
sleep 10
route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.33.31 metric 1 wlan0
------------------------------

上記の通りスクリプトになっているので、実行権限を与えておく。

$ sudo chmod +x /etc/network/if-up.d/static-routes
$ ls -l /etc/network/if-up.d/
------------------------------
-rwxr-xr-x 1 root root  703  7月 26  2011 000resolvconf
-rwxr-xr-x 1 root root  484  1月 23  2017 avahi-daemon
-rwxr-xr-x 1 root root  972  6月 18  2017 openssh-server
-rwxr-xr-x 1 root root  112  3月  7 21:52 static-routes
-rwxr-xr-x 1 root root 1483  6月  2  2015 upstart
lrwxrwxrwx 1 root root   32 10月 14 21:18 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh
------------------------------

これで、OS再起動時に本スクリプトが実行され、スタティックルートが追加されるようになる。

なお、sleepコマンドで10秒の待ち時間を入れている理由は、DHCPにてIPアドレスを取得する前に本スクリプトが実行されてしまった場合、「SIOCADDRT: ネットワークに届きません」というエラーにてスタティックルートの追加に失敗するためである。何回か私の環境で試したところ、5秒だと失敗することがあるため、10秒と設定するのがよさそうだ。

【参考】「/etc/rc.local」で対応する方法

今回は「/etc/network/if-up.d/static-routes」というファイルにて設定する方法としているが、「/etc/rc.local」もOS起動時に実行されるスクリプトになっており、同様にsleepとrouteコマンドを記載することでスタティックルートの追加が実現できる。

どちらで実装するかは好みの問題ではあるが、スタティックルートはネットワークの設定となるため、static-routesを使う対応が設計としてはわかりやすいと思われる。

2017年10月23日月曜日

Raspberry Pi Zero Wを購入してGPIO Hammer HeaderでGPIOの取り付けをした話

Raspberry Pi 3 Model Bを1台持っているのだが、温度・湿度監視センサーとして利用していることから、それ以外の検証作業に使いにくい状態となっていた。そこで、もう一台Raspberry Piを購入することにしたのだが、せっかくなのでRaspberry Pi Zero Wを購入することにした。

今回はRaspberry Pi Zero Wに対し、Hammer Headerというツールを使ってGPIOピンヘッダーを取り付ける手順について記載する。

Raspberry Pi Zero WとRaspberry Pi 3 Model Bの違い

2製品の違いは大きさだけではなく、性能にも差があることに注意する。特にRaspberry Pi Zero WはCPUがシングルコアなので、重い処理や複数の処理をこなすことには向いていない。

  Raspberry Pi Zero W Raspberry Pi 3 Model B
大きさ すごく小さい 小さい
CPU シングルコア 1GHz クアッドコア 1.2GHz
メモリ 512MB 1GB
USBポート 1個 (Micro USB) 4個
ネットワーク 無し 10/100Mbpsポート x 1
無線ネットワーク IEEE 802.11 b/g/n 2.4 GHz IEEE 802.11 b/g/n 2.4 GHz
Bluetooth Bluetooth 4.1 Bluetooth 4.1
映像出力 mini HDMI HDMI

購入したもの

Amazonで売っている以下セットを購入した。Raspberry Pi Zero WはUSBポートがMicro USBだったり、HDMI端子がmini HDMIだったりするので、変換キットも同梱されているものを最初は選ぶとよいだろう。



内容物としては以下の通り。

・Raspberry Pi Zero W本体
・公式ケース
・USB電源&ケーブル
・8GB microSDカード (NOOBS書き込み済み)
・mini HDMI → 標準HDMI変換アダプター
・Micro USB → 標準USB変換アダプター
・GPIOピンヘッダー (使用する場合ははんだ付けが必要)

付属するmicroSDカードにはNOOBSがインストール済みなので初期設定が楽になる。ただし、初めてRaspberry Piに触るのであれば、経験のためにNOOBSのインストールから実施するのもあり(手順はこちら)。

GPIOをはんだ無しで取り付けるGPIO Hammer Header

上述した通り、Raspberry Pi Zero Wは、GPIOピンヘッダーを取り付けたい場合は、はんだ付けが必要となる。私ははんだ付けの経験が久しくなく、失敗するリスクが高かったので、GPIO Hammer Headerという、言ってしまえば力ずくでGPIOヘッダーを圧着するツールを購入した。

なお、私が購入した際は1,000円未満の金額だったが、時期によっては倍くらいになっている模様。



実際のRaspberry Pi Zero WとHammer Header

Raspberry Pi Zero Wは本体が小さいこともあって、1個の小さなビニール袋に入る分量で届いた。


袋から取り出してみるとこんな感じ。


こちらはHammer Header。


袋には「海賊ロボ忍者さる」と記載されている。意味は以下を参照。

・スイッチサイエンス マガジン - Pimoroniがやってきた!
http://mag.switch-science.com/2017/08/23/pimoroni/


Hammer Headerは、専用のGPIOピンヘッダー(オス型、メス型の2種類)とアクリル製のパーツで構成されている。アクリル製の板が2枚入っているが、作業にはGPIO部分に穴が開いている板を使用する。


GPIOピンヘッダーは基盤との接続部分が膨らんでおり、ここをハンマーで叩いてはめ込むことで圧着されるという仕組みになっているようだ。


Hammer HeaderによるGPIO取り付け

まず、GPIO部に穴が開いている板にネジを通し、その上にRaspberry Pi Zero Wを乗せる。


次にGPIOピンヘッダーを乗せる。


細長いアクリル製の板をさらに上に乗せて、、、


これをハンマーで叩く!叩くといっても強い力は不要で、均等に刺さるように、ちょっとずつ叩いていく感じ。


最終的に以下のような状態になる。


GPIOピンヘッダー接続部の膨らんでいる箇所がはみ出しており、ちょっと深く差しすぎた感があるが、この状態で温度センサーを付けると正常に値の取得ができたので、問題なく使えそうだ。

2017年10月6日金曜日

Amazonで売ってる最安値のUSB温度計「TEMPer」をRaspberry Piで試してみた

AmazonでUSB温度計を検索すると、最安値で出てくる以下のような商品がある。



いろんな商品名で販売されているが、中身はTEMPerという製品のようだ。今回、このTEMPerを試すことができる機会があったので、実際に温度計測を実施してみることにした。


Amazonで売っているこれらの製品には、Windows用の温度計測ツールは用意されているようだが、Linux用は用意されていない。しかし、GitHubには様々な計測用のスクリプトが存在しているようなので、そちらを利用することにする。

当初はESXiのUSBポートに刺してパススルーして、Linuxから使うことを想定していたが、このUSB温度計はパススルーできない仕様のようで、うまく仮想マシンに認識させることができなかった。そこで、Raspberry PiのUSBポートにTEMPerを接続して、温度計測を実施してみることにした。

TEMPerを接続する

とりあえず、TEMPerをRaspberry PiのUSBポートに刺してみる。

lsusbで確認すると、下線部のデバイスが増えていることが確認できる。これがTEMPerとなる。

$ lsusb
------------------------------
Bus 001 Device 004: ID 0c45:7401 Microdia
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
------------------------------

スクリプトをインストールする

今回利用するスクリプトはこちら。

・GitHub - padelt/temper-python
https://github.com/padelt/temper-python

まずは、git cloneでスクリプトを入手する。

$ git clone https://github.com/padelt/temper-python.git
------------------------------
Cloning into 'temper-python'...
remote: Counting objects: 603, done.
remote: Total 603 (delta 0), reused 0 (delta 0), pack-reused 603
Receiving objects: 100% (603/603), 138.40 KiB | 263.00 KiB/s, done.
Resolving deltas: 100% (364/364), done.
Checking connectivity... done.
------------------------------

入手したファイルは以下の通り。setup.pyがインストールするためのPythonスクリプトとなる。

$ cd temper-python/
$ ls -l
------------------------------
-rw-r--r-- 1 pi pi  1232  9月 23 15:44 CHANGELOG.md
-rw-r--r-- 1 pi pi  5443  9月 23 15:44 DEVELOPMENT.md
-rw-r--r-- 1 pi pi 32612  9月 23 15:44 LICENSE.md
-rw-r--r-- 1 pi pi    18  9月 23 15:44 MANIFEST.in
-rw-r--r-- 1 pi pi 14903  9月 23 15:44 README.md
drwxr-xr-x 2 pi pi  4096  9月 23 15:44 etc
-rw-r--r-- 1 pi pi   886  9月 23 15:44 setup.py
drwxr-xr-x 2 pi pi  4096  9月 23 15:44 temperusb
------------------------------

前提となるライブラリをインストールする。なお、snmpdは外部からSNMPを使って温度取得するために必要となるもので、スクリプトのみで温度を取得するだけであればインストール不要となる。

$ sudo apt-get install python-usb python-setuptools snmpd
------------------------------
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
python-setuptools はすでに最新版です。
python-setuptools は手動でインストールしたと設定されました。
以下の追加パッケージがインストールされます:
  libperl5.20 libsensors4 libsnmp-base libsnmp30 perl perl-base perl-modules
提案パッケージ:
  lm-sensors snmp-mibs-downloader perl-doc libterm-readline-gnu-perl
  libterm-readline-perl-perl libb-lint-perl libcpanplus-dist-build-perl
  libcpanplus-perl libfile-checktree-perl libobject-accessor-perl snmptrapd
以下のパッケージが新たにインストールされます:
  libperl5.20 libsensors4 libsnmp-base libsnmp30 python-usb snmpd
以下のパッケージはアップグレードされます:
  perl perl-base perl-modules
アップグレード: 3 個、新規インストール: 6 個、削除: 0 個、保留: 7 個。
9,416 kB 中 5,709 kB のアーカイブを取得する必要があります。
この操作後に追加で 6,785 kB のディスク容量が消費されます。
続行しますか? [Y/n] y

~(以下略)~
------------------------------

次に、setup.pyを実行してスクリプトをインストールするのだが、以下の通りエラーで失敗してしまった。

$ sudo python setup.py install
------------------------------
Traceback (most recent call last):
  File "setup.py", line 10, in <module>
    long_description=open('README.md', encoding='utf-8').read(),
TypeError: 'encoding' is an invalid keyword argument for this function
pi@t3015rasp:~/temper-python $ file -i README.md
README.md: text/plain; charset=utf-8
------------------------------

どうやら、pythonのバージョンの問題のように思われる。Raspbianでは、PythonコマンドはPython2.7のシンボリックリンクになっているので、Python3コマンド(Python3.4コマンドのシンボリックリンク)で試してみると、問題なくインストールに成功した。

$ sudo python3 setup.py install
------------------------------
running install
Checking .pth file support in /usr/local/lib/python3.4/dist-packages/
/usr/bin/python3 -E -c pass
TEST PASSED: /usr/local/lib/python3.4/dist-packages/ appears to support .pth files
running bdist_egg
running egg_info
creating temperusb.egg-info
writing requirements to temperusb.egg-info/requires.txt
writing temperusb.egg-info/PKG-INFO
writing dependency_links to temperusb.egg-info/dependency_links.txt
writing entry points to temperusb.egg-info/entry_points.txt
writing top-level names to temperusb.egg-info/top_level.txt
writing manifest file 'temperusb.egg-info/SOURCES.txt'
reading manifest file 'temperusb.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'temperusb.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-armv7l/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/temperusb
copying temperusb/cli.py -> build/lib/temperusb
copying temperusb/snmp.py -> build/lib/temperusb
copying temperusb/__init__.py -> build/lib/temperusb
copying temperusb/temper.py -> build/lib/temperusb
creating build/bdist.linux-armv7l
creating build/bdist.linux-armv7l/egg
creating build/bdist.linux-armv7l/egg/temperusb
copying build/lib/temperusb/cli.py -> build/bdist.linux-armv7l/egg/temperusb
copying build/lib/temperusb/snmp.py -> build/bdist.linux-armv7l/egg/temperusb
copying build/lib/temperusb/__init__.py -> build/bdist.linux-armv7l/egg/temperusb
copying build/lib/temperusb/temper.py -> build/bdist.linux-armv7l/egg/temperusb
byte-compiling build/bdist.linux-armv7l/egg/temperusb/cli.py to cli.cpython-34.pyc
byte-compiling build/bdist.linux-armv7l/egg/temperusb/snmp.py to snmp.cpython-34.pyc
byte-compiling build/bdist.linux-armv7l/egg/temperusb/__init__.py to __init__.cpython-34.pyc
byte-compiling build/bdist.linux-armv7l/egg/temperusb/temper.py to temper.cpython-34.pyc
creating build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/PKG-INFO -> build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/SOURCES.txt -> build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/dependency_links.txt -> build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/entry_points.txt -> build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/requires.txt -> build/bdist.linux-armv7l/egg/EGG-INFO
copying temperusb.egg-info/top_level.txt -> build/bdist.linux-armv7l/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents...
creating dist
creating 'dist/temperusb-1.5.3-py3.4.egg' and adding 'build/bdist.linux-armv7l/egg' to it
removing 'build/bdist.linux-armv7l/egg' (and everything under it)
Processing temperusb-1.5.3-py3.4.egg
Copying temperusb-1.5.3-py3.4.egg to /usr/local/lib/python3.4/dist-packages
Adding temperusb 1.5.3 to easy-install.pth file
Installing temper-poll script to /usr/local/bin
Installing temper-snmp script to /usr/local/bin

Installed /usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg
Processing dependencies for temperusb==1.5.3
Searching for pyusb>=1.0.0rc1
Reading https://pypi.python.org/simple/pyusb/
Best match: PyUSB 1.0.0
Downloading https://pypi.python.org/packages/8a/19/66fb48a4905e472f5dfeda3a1bafac369fbf6d6fc5cf55b780864962652d/PyUSB-1.0.0.tar.gz#md5=c8a571bfdba778555156af3facaea6fc
Processing PyUSB-1.0.0.tar.gz
Writing /tmp/easy_install-f2wopxqc/pyusb-1.0.0/setup.cfg
Running pyusb-1.0.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-f2wopxqc/pyusb-1.0.0/egg-dist-tmp-3sda3exd
zip_safe flag not set; analyzing archive contents...
Adding pyusb 1.0.0 to easy-install.pth file

Installed /usr/local/lib/python3.4/dist-packages/pyusb-1.0.0-py3.4.egg
Finished processing dependencies for temperusb==1.5.3
------------------------------

温度を計測してみる

それでは、温度取得コマンドを叩いてみる。が、失敗。

$ temper-poll
------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/temper.py", line 95, in __init__
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/temper.py", line 164, in lookup_sensor_count
  File "/usr/local/lib/python3.4/dist-packages/pyusb-1.0.0-py3.4.egg/usb/core.py", line 841, in product
  File "/usr/local/lib/python3.4/dist-packages/pyusb-1.0.0-py3.4.egg/usb/util.py", line 314, in get_string
ValueError: The device has no langid

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/temper-poll", line 9, in <module>
    load_entry_point('temperusb==1.5.3', 'console_scripts', 'temper-poll')()
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/cli.py", line 38, in main
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/temper.py", line 420, in __init__
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/temper.py", line 419, in <listcomp>
  File "/usr/local/lib/python3.4/dist-packages/temperusb-1.5.3-py3.4.egg/temperusb/temper.py", line 97, in __init__
AttributeError: 'ValueError' object has no attribute 'message'
------------------------------

原因はsudoを忘れたことによるものだった。sudoを付けて実行すると、0.5秒ほど間があって温度取得に成功した。

$ sudo temper-poll
------------------------------
Found 1 devices
Device #0: 38.4°C 101.2°F
------------------------------

温度計測の精度について

自宅のRaspberry Piでは、DHT11というセンサーを利用した温度計測も実施している。
※詳細は以下記事を参照

・Raspberry Pi + DHT11 + Zabbixによる温度・湿度監視
https://tech-mmmm.blogspot.jp/2017/08/raspberry-pi-dht11-zabbix.html

TEMPerの計測温度が38.4℃の時のDHT11の温度は32℃となっており、TEMPerの方が計測温度がかなり高い。

これは、Raspberry Pi本体の温度がTEMPer本体に伝わり熱くなってしまうことが原因で、温度が高く計測されてしまっているようだ。したがって、Raspberry Pi本体の熱を伝わらないようにするために、USB延長ケーブルなどで接続する必要がありそうだ。

実際にUSB延長ケーブルでTEMPerを接続すると、以下の通りほぼ同じ温度での計測ができることが確認できた。

・DHT11:33℃
・TEMPer:32.6℃

人気の投稿