t-hom’s diary

主にVBAネタを扱っているブログ…とも言えなくなってきたこの頃。

Amazon AWS S3とSambaサーバーの組み合わせで、自宅用の実用的なアーカイブソリューションを構築してみた

今回はAmazon AWS S3とSambaサーバーを組み合わせて、とりいそぎ使えそうなアーカイブソリューションが構築できたのでご紹介。
めったに参照しないけど無くなると困るファイルを、安全かつ恒久的にアーカイブする。

概要と使い方

仕組みを説明したのが以下の図。
f:id:t-hom:20220410223600p:plain

  1. Sambaサーバー上にあるToArchiveというフォルダーに大事なファイルを配置する。
  2. cronジョブにより実行されるバッチがToArchive内のファイルをAmazon S3へアップロードする
  3. 上記バッチはアップロードが完了したローカルファイルをSambaサーバー上のArchiveフォルダへ移動する。

この仕組みのメリットは図上の吹き出し参照。

特にファイルを間違って消しそうになっても、Archiveフォルダは書き込みアクセス権が無くて弾いてくれるのがありがたい。
f:id:t-hom:20220410230213p:plain

各種設定

/etc/samba/smb.conf

[global]
        dos charset = CP932
        unix charset = UTF-8

        workgroup = WORKGROUP
        security = user

        interfaces = 192.168.1.107 127.0.0.1
        bind interfaces only = yes
        socket address = 192.168.1.255

        printcap name = /dev/null
        log level = 1

[Archive]
        path = /mnt/pool/Archive
        writeable = no

[ToArchive]
        path = /mnt/pool/ToArchive
        writeable = yes

ここでのポイントは[Archive]のwritableをnoにしておくこと。

設定ファイルを保存したらsmbを再起動。

sudo systemctl restart smb.service

SE Linux環境でsambaに特定フォルダへアクセスを許可する設定コマンド

sudo chcon -t samba_share_t /mnt/pool/ToArchive
sudo chcon -t samba_share_t /mnt/pool/Archive

cronから実行するシェルスクリプト /home/thom/archive.sh

#!/bin/bash
FILES="/mnt/pool/ToArchive/*"

if [ -n "$(ls -A /mnt/pool/ToArchive/)" ];then
  for f in $FILES
  do
    echo "Processing: $f"
    /usr/local/bin/aws s3 cp $f s3://ここにS3バケット名/ --profile ここにユーザー名
    mv $f /mnt/pool/Archive/
  done
else
  exit
fi

crontab

*/1 * * * * /home/thom/archive.sh

関連のある過去記事

thom.hateblo.jp
thom.hateblo.jp

要改善点

同名の別ファイルをうっかりToArchiveに置いてしまうと恐らくアーカイブが上書きされてしまうので、バッチ処理にif文でArchiveに同じファイル名が存在するときは処理をしないか、あるいはArchiveErrorというフォルダを作ってそこに移動するか等考えたい。
これはさっさとやらないとまずそう。Redmineにタスク登録しておこう。

あと暗号化の仕組みもまだ導入できてない。
検証は以下の記事で終わってるので面倒くさがってるだけなんだけど、Redmineタスクには登録したので、近いうちに組み込みたいと思う。
thom.hateblo.jp

Linux(CentOS 7)からAWSのS3ストレージへ重要ファイルをクラウドアーカイブする

今回はAmazon AWSのS3ストレージサービスを活用して重要なファイルをクラウドにアーカイブしてみる。

アーカイブとは

バックアップとアーカイブの違いは、日常的に更新するかどうかである。
例えばWindows10には標準でOneDriveが付いてくるので、ここに入れておけばハードディスクが故障してもクラウド上にファイルは残る。そういう意味でクラウドバックアップは既に普段使いしていると言える。

ただ、ユーザー操作のミスでファイルを書き換えてしまったり消してしまった場合はクラウド上でもそうした操作が同期されてデータが消失するリスクが残る。

したがって、更新はしないけど無くなると困る重要なファイルは、どこか別のところに避けておきたい。
これが基本的なアーカイブの考え方である。大切な思い出の写真とかが分かりやすい例かなと思う。

Amazon AWS S3とは

AWS S3は低価格なストレージサービスで、バケット(要するにバケツ)という場所にファイルをどんどん放り込んでいくという使い方をする。一般的なファイルシステムのようにフォルダーで整理するということは想定されておらず、とにかく一個所にファイルを放り込んでいくイメージ。またデフォルトで3か所のデータセンターにデータが保存されるのでデータの耐久性は99.999999999%(イレブンナイン)。今回のアーカイブ用途にはうってつけだ。

料金表はこちら。
aws.amazon.com

多く見積もって最大で100GB保管する想定で計算してみたところ、月額515円と個人でも十分支払い可能な料金である。(22年4月10日現在の為替レートによる)
f:id:t-hom:20220410132942p:plain

※情報が間違っていても責任は負いかねるので実際に活用される方は自己責任で。

※S3ストレージが安いだけで、他のAWSサービスは普通に高いので注意。特にインターネットで一般公開するようなサーバーはアクセス量が予測できないのでちゃんと調べて計算しないと怖い印象。

実際に設定してみる

※AWSのアカウント取得とかは割愛。
※ここで紹介するのは私がこうやったという手順なので、適切かどうかは保証しない。

アクセスユーザーの作成

まずサービスメニューからIAMを開く
f:id:t-hom:20220410135054p:plain

IAMというのはIdentity and Access Managementの略で、要はIDとアクセス権限の管理。

ユーザーメニューからユーザーを追加をクリック
f:id:t-hom:20220410135646p:plain

ユーザー名を決めて、アクセスキー・プログラムによるアクセスにチェックを入れて次のステップへ
f:id:t-hom:20220410135716p:plain

既存ポリシー直接アタッチを選択してs3を検索、出てきたAmazonS3FullAccessを選択して次のステップへ
f:id:t-hom:20220410135752p:plain

タグは特に要らないのでそのまま次のステップへ
f:id:t-hom:20220410135946p:plain

確認画面で問題なければユーザーの作成をクリック
f:id:t-hom:20220410140008p:plain

アクセスキーとシークレットアクセスキーを控えておく
f:id:t-hom:20220410140034p:plain

以上でユーザー作成は完了

S3ストレージの開設

サービスメニューからS3を開く
f:id:t-hom:20220410140310p:plain

バケットメニューからバケットを作成する
f:id:t-hom:20220410140326p:plain

バケット名とリージョンを選択した後、下のほうにスクロールして作成をクリック
f:id:t-hom:20220410140424p:plain
バケット名は他人とも被ってはいけないらしい。
とりあえずテストで作る場合は日付時刻を入れると被る可能性が極めて低いのでおススメ。

S3のリージョンはローカルにもコピーを持つ前提で災害対策を考えるなら自分が住んでる地域とは少し離れてる方が理想。私は関西住まいなので東京リージョンを選択した。
f:id:t-hom:20220410141130p:plain

これで、Linuxにインストールするawsのクライアントからは「s3://testbacket202204101241/」としてアクセスできるようになる。
また、このページからブラウザ上でのアップロード・ダウンロード・削除などの操作も可能。

Linux上の設定 (CentOS 7の場合)

CentOS 7の場合は次のようにしてpython3とawscliをインストール

sudo yum update
sudo yum install python3
sudo pip3 install awscli

awscliの接続設定を行う
aws configure --profile AWSのIAMで作ったユーザー名 と入力するとアクセスキー、シークレットキー、デフォルトリージョン名、出力フォーマットを聞かれるので順次入力する。つぎに環境変数でデフォルトプロファイルに設定。

aws configure --profile testuser1

# 上記を実行すると以下4点が順番に質問される。
AWS Access Key ID [None]: ここにさっき控えたアクセスキーを張る
AWS Secret Access Key [None]: ここにさっき控えたシークレットアクセスキーを張る
Default region name [None]: ap-northeast-1
Default output format [None]: json

# 今作ったプロファイルをデフォルトに指定
export AWS_DEFAULT_PROFILE=testuser1

以上で使う準備が完了。

使用方法

Linux上でアップロードしたいファイルを指定する。

# aws s3 cp アップロードしたいファイル s3://バケットのパス/
aws s3 cp test.jpg s3://testbacket202204101241/

あとはブラウザからAWSのS3にアクセスしてバケットを覗くとちゃんとデータが入ってるのが分かる。

AWSを初めて触る方にオススメの書籍

あんまり重たい書籍だと途中で嫌になるけど、以下の書籍はさくっと読めて概念を理解するのにちょうどよかった。

この記事で書いたような具体的な手順は解説されていないが、参考URLが書かれているのでそこまで困らないと思う。

ただしある程度のインフラ知識が前提なので、IT未経験ですという人に向けた書籍ではない。
基本情報技術者程度の知識か、もしくは自分でオンプレミスのサーバー運用経験があればよく理解できると思う。

以上

gzipとOpenSSLを使ったファイル圧縮&暗号化&復号化

今回は特定フォルダ内のファイルを個別に圧縮&暗号化するBashスクリプトをご紹介。

挙動

Archiveフォルダに入れた複数ファイルを①gzipで圧縮し、②OpenSSLで暗号化し、③Encryptedフォルダに出力し、④処理済のオリジナルファイルはArchivedに移動させる。
f:id:t-hom:20220409175757p:plain

用途

最近自宅にSambaサーバーを立てたのだが、重要なファイルはこれだけでは障害時に不安が残るので、AWSのS3ストレージ等に自動転送しておきたい。
その際に流出対策として今回暗号化の仕組みを作成した。

暗号化するコード

今回はパスワードもコード内に入れてしまう。
クラウド保存時の流出対策なので、ローカルで見えてしまうのはまぁ良しとする。

#!/bin/bash
FILES="/home/thom/Test/Archive/*"
TIMESTAMP=`date +'%Y%m%d%H%M%S'`
PASSWORD="pass"

for f in $FILES
do
  echo "Encripting: $f"
  gzip -c $f | openssl enc -e -aes-256-cbc -pbkdf2 -iter 99999 -salt -k $PASSWORD -out /home/thom/Test/Encrypted/${TIMESTAMP}_$(basename -- $f).aes
  mv $f /home/thom/Test/Archived/
done

実行するとArchiveフォルダに入っているファイルが処理され、YYYYmmddHHMMSS_オリジナルファイル名.aesとしてEncryptedフォルダに保存される。
処理前のオリジナルはArchivedに移動される。

復号化するコード

これを実行するとEncryptedフォルダ内のファイルがDecryptedフォルダーに復号化される。

#!/bin/bash
FILES="/home/thom/Test/Encrypted/*"
PASSWORD="pass"
for f in $FILES
do
  echo "Decrypting: $f"
  openssl enc -d -aes-256-cbc -pbkdf2 -iter 99999 -salt -k $PASSWORD -in $f | gzip -d > /home/thom/Test/Decrypted/$(basename -- ${f%.*})
done

参考サイト

qiita.com
qiita.com

アーカイブと圧縮と暗号化について

Windows文化だとあんまり意識することなく、パスワード付きzipとして一緒くたにしているケースが多い。
本来はそれぞれ別の概念なので、軽く説明しておこうと思う。

アーカイブ

複数ファイルやフォルダ等を一つのファイルにまとめる機能。
Linuxだとtarコマンドが有名。

圧縮

特定の圧縮アルゴリズムを用いてファイルの容量を削減する機能。
Linuxだとgzipコマンドが有名。
Linuxでよく見かける.tar.gzという拡張子はtarでアーカイブした後にgzipで圧縮されているファイルということ。

暗号化

特定の暗号化アルゴリズムを用いてファイルの中身を第三者に知られないようにする機能。
Windowsのパスワード付きzipはツールを使えば比較的簡単に暗号化を破られると言われているので今回はOpenSSLというツールでAESというより強力な暗号化アルゴリズム使って暗号化した。

以上

Raspberry Piと赤外線人感センサーを使った睡眠時間ロギングシステム

今回はRaspberry Pi Zeroと赤外線人感センサーを使って睡眠時間のロギングシステムを構築したので紹介。

といっても全然大したものではなくて、単純にベッドに人感センサーを向けて定期的に検出を行い、検出されたらログに追記するという仕組み。

モノ

試作1号。。ひどい見た目だけど検証用途としては要はデータ取れたらなんでも良いのでマスキングテープが活躍。
f:id:t-hom:20220409095643p:plain
ラズパイのGPIOピン18番に人感センサーのデータピンを接続している。

センサーはAmazonでHC-SR501を検索すると適当なメーカーのものがいくつもヒットする。
私はHiletGo社のものを買ったけど今は在庫切れのようだ。まぁどれでも同じだと思う。

プログラム

ラズパイで実行させる検出プログラム

以下は10秒ごとに人体検出を試み、検出されたらファイルに記録して次の検出まで60秒間検出停止する。
まだ検証段階なので特にデーモン化等は考えておらず、SSHで繋いで実行させたらSSHセッションそのまま保持させている。

from datetime import datetime
import time
import RPi.GPIO as GPIO

INTERVAL = 10
SLEEPTIME = 60
GPIO_PIN = 18

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

if __name__ == '__main__':
    try:
        print ("To Cancel:CTRL+C")
        cnt = 1
        while True:
            if(GPIO.input(GPIO_PIN) == GPIO.HIGH):
                with open('/home/thom/data.csv', 'a') as f:
                    print(datetime.now().strftime('%Y-%m-%d %H:%M:%S') + ', 1', file=f)
                print(datetime.now().strftime('%Y-%m-%d %H:%M:%S') + ', 1')
                cnt = cnt + 1
                time.sleep(SLEEPTIME)
            else:
                print(datetime.now().strftime('%Y-%m-%d %H:%M:%S'))
                time.sleep(INTERVAL)
    except KeyboardInterrupt:
        print("Closing")
    finally:
        GPIO.cleanup()
        print("GPIO cleaned")

PCでデータ加工用に作成中のプログラム

出力データはそのままでは非常に見づらいのでpandasを使って1時間単位の検出回数を集計する。

import pandas as pd

df = pd.read_csv('./sleepdata.csv', header=None, parse_dates=[0])
df = df.resample('60T', on=0).sum()
df = df.loc[df[1] > 0]

with pd.option_context('display.max_rows', None, 'display.max_columns', None):
    print(df)

1週間記録してみたデータ

プログラムで加工しただけでも一応分かるものの、入眠と起床が分かりにくいので空行で区切ってコメントを付けてみた。
見返すと酷い生活リズム。。最近色々テクノロジー系にハマってたのでその弊害かなと思う。

# 仮眠
2022-04-01 17:00:00  55
2022-04-01 18:00:00  29

# 睡眠
2022-04-02 01:00:00  10
2022-04-02 02:00:00  12
2022-04-02 03:00:00  40
2022-04-02 04:00:00  28
2022-04-02 05:00:00  37
2022-04-02 06:00:00  20
2022-04-02 07:00:00  30
2022-04-02 08:00:00  60
2022-04-02 09:00:00  45
2022-04-03 06:00:00  32
2022-04-03 07:00:00  35
2022-04-03 08:00:00  42
2022-04-03 09:00:00  53
2022-04-03 10:00:00  36

# 仮眠→爆睡
2022-04-03 17:00:00  13
2022-04-03 18:00:00  36
2022-04-03 19:00:00  50
2022-04-03 20:00:00  35
2022-04-03 21:00:00  52
2022-04-03 22:00:00  14

# 睡眠
2022-04-04 02:00:00  34
2022-04-04 03:00:00  13
2022-04-04 04:00:00  40
2022-04-04 05:00:00  39
2022-04-04 06:00:00  43
2022-04-04 07:00:00  59
2022-04-04 08:00:00  25
2022-04-05 03:00:00  20
2022-04-05 04:00:00  47
2022-04-05 05:00:00  52
2022-04-05 06:00:00  35
2022-04-05 07:00:00  53
2022-04-05 08:00:00  51
2022-04-05 09:00:00   5

# 仮眠
2022-04-05 17:00:00  18
2022-04-05 18:00:00  58
2022-04-05 19:00:00  60
2022-04-05 20:00:00  48

# 睡眠
2022-04-06 02:00:00  14
2022-04-06 03:00:00  37
2022-04-06 04:00:00  50
2022-04-06 05:00:00  22
2022-04-06 06:00:00  48
2022-04-06 07:00:00  45
2022-04-06 08:00:00  52

# 睡眠
2022-04-06 23:00:00  28
2022-04-07 00:00:00  31
2022-04-07 01:00:00  55
2022-04-07 02:00:00  49
2022-04-07 03:00:00  52
2022-04-07 04:00:00  44
2022-04-07 05:00:00  60
2022-04-07 06:00:00  60
2022-04-07 07:00:00  51
2022-04-07 08:00:00  46
2022-04-07 09:00:00   9

# 仮眠
2022-04-07 17:00:00  10
2022-04-07 20:00:00  10

# 睡眠
2022-04-07 22:00:00  14
2022-04-07 23:00:00  52
2022-04-08 00:00:00  55
2022-04-08 01:00:00  44
2022-04-08 02:00:00  51
2022-04-08 03:00:00  60
2022-04-08 04:00:00  60
2022-04-08 05:00:00  17
2022-04-08 06:00:00   8

ちなみに平日の9時台に数件検出されてるのはサボりとか遅刻ではなくて、センサーの検出時間を最大にしてるのでベッドを離れても数分検出が続くためだ。ここ2年くらいは在宅勤務なので8時55分くらいまで寝てることがある。。

難点と改良

最初はセンサーの感度をMAXにしてたけど、部屋の前を横切っただけでベッド上にいる判定になってしまうので、検出感度を下げてみた。ところが感度が低いと検出精度が悪かったので取り付け方向を変えて段ボールフードで覆うことで枕を狙い撃ちすることにした。これまたひどいビジュアルだけど。。
f:id:t-hom:20220409102214p:plain

あとそもそも人感センサーは動きを検出するので静止してると検出しない。
普通の人間は寝てる間もモゾモゾするので検出しないわけではないものの、周期的に静止状態になるので深い眠りに落ちている間の検出ができなかったりする。本当は15分単位でデータ集約したかったんだけど、それだと起きてる判定になる時間が多かったので精度を落として1時間単位の集約とした。

まぁそもそもベッドに居る=寝てるとは限らないので、Kindle読んでたりスマホいじってたりする時間を除くと最近十分な睡眠がとれているかどうかは怪しいのだが。

今後の展望としてはデータ加工まではラズパイ側で対応して、メイン機に転送してグラフ表示をしたい。
3Dプリンターでちゃんとしたラズパイケースとかセンサー用のフードを作るのはそこまでできた後で良いかな。。ダサイけど。

以上

ターミナルサーバーCisco2511経由でルーターのコンソールをリモート操作

最近ネットワークの知識獲得に(2つの意味で)ハマっていて、Ciscoの自宅ネットワークラボ用に買い集めた機材が詰みあがっている。
上から、ルーター3台、L2スイッチ3台、L3スイッチ3台という品揃え。
f:id:t-hom:20220403020300p:plain

端末はそれほど沢山ないので基本的にはOracle VirtualBoxを使ってなんとかするんだけど、これは先日書いたUSBデバイスサーバーを使うことで遠隔化の目途が立った。
thom.hateblo.jp


最後の問題は、ネットワーク機器の設定である。
通常、Ciscoなど業務用ルーター・スイッチは挿しただけでは動作せず、初期設定が必要になる。

ネットワークに繋げるための設定をネットワーク越しにやりたい。



は?


ちょおま、何いってんのそんなことできるわけ

はいドーン。ターミナルサーバーCisco 2511!!
f:id:t-hom:20220404190631p:plain

買ってしまった。わざわざアメリカから。
国際送料が6315円。仲介サイトの手数料を含めると23,835円。
まぁでもターミナルサーバーってヤフオクとかにもあんまり出回ってなくて、日本で出回ってるセイコーソリューションズのSmartCSという製品が3万円以上するので、若干安く済んだかなと思う。

それに個人的に気に入っているCisco製品だし満足度も高い。

緑のASYNCというポートは非同期通信(まだよく分かってない)用で、普通のLANではなくてネットワーク機器のコンソールポートに繋ぐ。要はこのCisco 2511という機器にさえネットワーク接続できれば、あとはこのASYNCポートから各ネットワーク機器のコンソールポートに繋げて操作ができるという仕組み。

ただイーサネットポートはAUIという15ピンの見たこともない形状なので、別途RJ45へ変換するアダプタを付ける必要がある。これはヤフオクで2,000円くらいで入手できたので接続。
f:id:t-hom:20220404192735p:plain

ちょっと台無し感があるけどまぁ仕方ない。

トラブル

先日のFujitsuでもハマったけど、こちらも前提知識なしで「まぁなんとかなるやろ」と軽い気持ちでポチったので、いざ届いてみると案の定トラブった。ちょっとプロの方に見られると恥ずかしいレベルの知識不足&初歩的なミスが原因だったのでさらっと流していこうと思う。

日本語サイト・英語サイトを一巡してtelnet経由でコンソールサーバーに接続できるところまでは確認できたのだが、その後何も表示されない。本来なら接続先ルーターのプロンプトが出てくるはずなんだが。。

さんざん設定を疑った結果、たまたまたどり着いた以下のサイトで、「もしかして普通のLANケーブルじゃダメなのでは?」と気づいた。
www.homecomputerlab.com

どうやらロールオーバーケーブルというものを用意する必要があるらしい。
差し込み口はRJ45(Registered Jack No.45 : 登録された差し込み口No.45)という普通のLANケーブルと同じ規格。しかし結線方法が違う。

そんなの持ってないし、近所に売ってるのも見たことない。

そこで、こいつの出番。
f:id:t-hom:20220404195028p:plain

ないなら作れば良いんだ。

そして完成。
f:id:t-hom:20220404195449p:plain

普通のケーブルと間違えないようにジャックカバーの色を変えてみた。


これでようやくTELNETでつながった!
が、、どうも様子がおかしい。表示はされるのに入力を受け付けないのだ。

また設定がおかしいのかと悩み倒した挙句、まさかと思ってケーブルを確認してみると。。
f:id:t-hom:20220404195733p:plain

カシメ不良。。

今回特殊なケーブルを作るので、両端ができてちゃんと並び順をチェックしてからカシメようと思って、片方のジャックを仮で差し込んだ状態でもう片方の作成をしてたんだけど、その際に線が引っ張られて一部の長さが変わってしまったようだ。

カシメ直前に奥まで押し込んだつもりが、そもそも線の長さがバラバラになってたので奥まで届かない線がでて失敗した模様。
やっぱ片側のカシメが終わってからもう片側に取り掛からないとダメだな。

ということで失敗作の頭を切り落として再度接続。
f:id:t-hom:20220404200315p:plain

これでつながった。

2511の設定について

色々なサイトで解説があるけど、比較的シンプルなのがこちら。
nikumaki.exblog.jp

上記サイトに倣って設定するとCisco 2511からCisco2511(自分宛)へのTelnetでコンソールポートに接続できるようになる。
あとは通常のルーターと同じくInterface Ethernet 0とかにIPを設定してLANに繋げば手元のPCからTelnet接続で使用できるようになる。

接続先ポートは2000 + 接続したいASYNCポートの番号となる。
最大で16台までの機にコンソール接続できるらしいが、まぁこんだけあれば埋まることは無いだろう。

以上

ラックマウントサーバーでファイルサーバーを作成してみた

今回は富士通の型落ちラックマウントサーバーを調達したのでファイルサーバーを作ってみた。

機材

ラックマウントと言っても専用のサーバーラックは持ってないので普通のスチールラックに収納。
f:id:t-hom:20220403010301p:plain

Ciscoスイッチを上に置いたところ高さ的にちょうど収まったので良かった。

奥行が大体60cmくらいある。本当はプラス20センチの排熱スペースを設けないといけないんだけど、5cmしか取れなかった。

f:id:t-hom:20220403010843p:plain

今回はセットアップにすごくハマった。
なんせサーバー機なんて触るのは初めてだし、そもそもメルカリで調達したので通電とBIOS起動までしか保証されていない。
何かあるたびに、故障なのか使い方が間違ってるのか悩むことになる。

まずソフトウェアRAID(レイド)が標準でサポートされているらしいのだが、起動したらいきなりドライブ3をリビルドしろと言われ、とりあえずやってみる。
f:id:t-hom:20220403011302p:plain

いやそもそもリビルドって何?。。と思いながら待つこと5時間。
ようやく終わったんだけど、特にOS入ってるわけでもなく結局何だったのかは分からなかった。

ちなみにRAIDというのは複数のHDDを仮想的にひとつのドライブとして扱う技術で、分散書き込みによる高速化や、並列書き込みによるデータの冗長化(片方ディスク死んでも大丈夫)など目的によってRAID0、RAID1、RAID5、RAID6、RAID10などの種類がある。

ハードウェアRAIDの場合、機材の方でひとつのハードディスクのフリをするのでシステムからは単純に1つのハードディスクに見えるんだけど、ソフトウェアRAIDというのは結局システム自体が「これは1つのハードディスクなんだ」と自己暗示してるようなものなので、導入するOSとの相性が悪いとうまく騙されてくれない。つまりエラーになる。

こんなのとか。
f:id:t-hom:20220403012016p:plain

こんなのとか。
f:id:t-hom:20220403012940p:plain
あ、これはRAID関係ないやつかも。。

まぁとにかく、標準のソフトウェアRAIDはCentOSもUbuntuサーバーもダメだった。
RAIDツールでRAIDを解除して、BIOSからSATAコントローラーをRAIDからAHCIモードに切り替えたところ、CentOS Stream 8がインストールできた。
f:id:t-hom:20220403013313p:plain

まぁこの後結局SSHのレスポンスが遅いとか色々ハマって、まともに動くのがUbuntu20サーバーとCentOS 7だけということが判明した。

今日は構成やバージョンやディストリビューションを変えながら計7回くらいLinuxインストールを行った。
すぐにエラーでダメになった試行も含めると15回以上はやってるか。。
今日まじでLinuxインストールしかしてないな。。

結局OSはCentOS 7にした。サポート期間が2024年6月末まであるので、とりあえず2年は遊べそう。
期限が迫ったらまた考えようと思う。

ファイルサーバー構築

一通り検証が終わったので、とりあえず4つあるドライブの1つはOS用にSSDに換装した。
普通のPCと違ってサーバー機はSATAのドライブでも前面のパネルから簡単に取り出せるようになってるので、かなり簡単だ。
サクっと入れ替え完了。
f:id:t-hom:20220403014202p:plain

その他の3ドライブのうち2つはLinux自体のRAID機能を使ってミラーリングするようにした。
色々調べたところ、今はベンダーのソフトウェアRAIDとか使わずにOS自体のRAID機能を使うケースが増えているらしい。

CentOSでのRaidについては以下のサイトを参考にさせていただいた。
2017.l2tp.org

ファイルサーバーのSAMBAについてはサイトによって表記がマチマチで、一応動きはしたけど作法とかセキュリティが分からない。
ということでちゃんとSAMBAの書籍を買ってみた。

そして書籍の通りインストール・設定を実施。
特に難しいこともなくすんなり導入できた。

ラックマウントサーバーに興味を持った方への注意点

  • 写真で見るとスリムで取り回しがよさそうに見えるかもしれないけど、実物はかなり大きくて重たい。
  • 同じ1UラックマウントサーバーでもDELL・HPは排熱ファンの音がかなりうるさいらしい。
  • 電気代に注意。私が買ったもので、24時間つけっぱなしにすると月に600円~800円くらいの電気代がかかる。ラズパイだと月に1台40円~60円くらいしか電気を食わないのでそれと比べると結構高い。あらかじめメーカーサイトで消費電力を調べることが出来たりするので目安として押さえておくと良いかと思う。
    実際に動作中の電力を計ってみたら見積りの3分の1くらいだったので助かった。
  • 型落ち品ではディスプレイ端子がVGAしか無かったりするので、対応モニターが必要。

以上

Redmine CMDBで自宅機器のセキュリティ状況を把握

最近、自宅端末のエンドポイントセキュリティを見直すためにパスワードの複雑性ポリシーを定めたり、セキュリティ更新状況をちゃんと管理することにした。

全部綺麗になってパッチ適用もオートメーションになればもはや管理することは無くなるんだけど、オフライン端末等も含めるとなかなかそうもいかないのが現状。

ということでRedmineのCMDBにカスタムフィールドを追加して端末ごとの状況を入力してみた。
f:id:t-hom:20220327143604p:plain
※変更が効かないMACさえ隠しておけば何とでもなると思ってる。。

工夫した点

前提としてカスタムフィールドはテキストではなく、なるべく実態に即した型を使用したい。
セキュリティ更新日なら日付型、ポリシー準拠状況は真偽型。

空欄を作ると入力漏れなのか該当する値が無いのか分からないので、全機器セキュリティ項目は埋めたい。
しかしここで問題となるのが追加NICなどのそもそも機器本体ではないケース。
当然NICにパスワードなんてないし、セキュリティパッチを当てるような対象でもない。

そこで次のルールとした

パスワードポリシー準拠欄

  • 準拠可能なものは、はい・いいえで選択
  • 準拠不可(該当しない)の場合、はいを選択

これで、いいえと未記入(記入もれ)だけクエリで拾えば要対応案件が分かる。

セキュリティ更新日欄

  • パッチ適用の対象となる機器のうち、適用日がはっきりしているものは日付を記入
  • パッチ適用の対象となる機器のうち、適用日がはっきりしないものは1111年1月1日を記入
  • パッチ適用の対象とならない機器は、9999年9月9日を入力

これで、古い日付と未記入(記入もれ)だけクエリで拾えば要対応案件が分かる。

運用ポリシーも叩き作成してみたので公開

Redmine内のWikiに書いた内容をコピーしてきた。

パスワードポリシー

複雑性に関するポリシー

  • 大文字・小文字・数字・特殊文字をそれぞれ最低1種類含む、ランダムに生成された16文字のパスワードを使用する
  • 可能な限りKeePassXCによるパスワード自動生成機能を使用し、「すばらしい」と評価が付くパスワードが出るまで繰り返し生成をやり直す

デフォルトユーザー名変更ポリシー

  • ラズベリーパイのデフォルトユーザーpiは名前を変更する

特権に関するポリシー

  • rootがパスワード未設定の場合にログインできない設定になっていることを確認する
  • 上記設定を活かすため、rootにはあえてパスワードを設定しない
  • sudoによる権限昇格時にユーザーパスワードを要求する

セキュリティパッチ運用ポリシー

  • オンライン端末については週に1度更新を確認し、最新パッチを適用する
  • オフライン端末については最低でも半年に1度更新を確認し、最新パッチを適用する

ポリシーの運用方針

もともとダメダメだったので一気にガチガチにしようとはせず、できる範囲からやっていこうと思う。
パスワードについては今ほとんどKeePassXCからのコピペ運用で回ってるのである程度複雑化させても面倒くさがらずに運用できることが実証済。

運用していくなかでポリシーは必要に応じて頻繁かつ柔軟に変えていこうと思う。
そんなブレブレで良いのかと思うかもしれないけど、所詮個人が自宅でやることなので、守れもしないポリシーを見て見ぬフリして実体がコントロール不能に陥いるよりは、防衛ラインを上げたり下げたりしながら、決めたラインで戦い続けるという方が現実的。

以上

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。