2025年11月13日にリリースされた『ライザのアトリエトリロジーDX』。
グラフィック廻りが一新され、一部のボイスがアニメに準拠したものへと差し替わっているなどがありましたが、Steam版に強烈な不満がありましたが、修正を確認しました。
壊滅的に遅かったロード画面
※2025/11/18のアップデートによりこの遅さは劇的に改善されました。よって、これ以降の記事は取り下げます。
2025年11月13日にリリースされた『ライザのアトリエトリロジーDX』。
グラフィック廻りが一新され、一部のボイスがアニメに準拠したものへと差し替わっているなどがありましたが、Steam版に強烈な不満がありましたが、修正を確認しました。
※2025/11/18のアップデートによりこの遅さは劇的に改善されました。よって、これ以降の記事は取り下げます。
前にも述べた『むこうぶち』の江崎のこの言葉。
「船が陸にたどり着く寸前に生憎の嵐…… どうすればいいと思います?
いったん沖に引き返すんですよ
船ってのは水に浮かぶようにできているんです
無闇に上陸を焦って座礁する事が一番怖い」
この言葉が持つ意味を手順書の「切り戻し」により、改めて掘り下げていきます。
等によって起きた障害・サービスダウンを「無かったことにする」技術全般です。Linuxサーバで言うならば
等による、逆転時計(タイムターナー)のような存在です。これは、ITの最大のメリットと言ってもいい技術。医療や建築のような「不可逆性」を“ある程度”緩和してくれます。
これは、物流・メーカー・医療・その他諸々の業界の方には釈迦に説法でしょう。
は、予測不能なリスクを奇跡的な幸運から乗り切ったから言える生存バイアスです。
このような、予測不可能なミスを少しでも減らし、起きてしまったことを「無かったことにする」技術が、バックアップからの切り戻しです。
https://barrel.reisalin.com/books/950a4/page/mysql
こちらでも少し触れている「Webアプリで不具合が発生した際の切り戻し」の方法。
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
等としてバックアップを取っておき、
mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql
で戻す。多くのシングル構成のDBは(つまり、個人運用程度であれば)これで復旧するパターンがほとんどです。筆者はサーバ移行や「やっちまった」時のリカバリのほとんどをこれで復旧させることができました。
これが、「手順書によるコントロール」に他なりません。
という、一種の逆順処理を取ります。筆者が紹介した手順において
を含めるのは、「何かあったときに元に戻せる」を確実にするためです。
「行ってこい」の精神であればここまではやりませんし、やる必要はありません。しかし、情報という価値あるものを「維持する」ためにも戻り道という名のPoint of Returnable(回帰可能点)を随所に作っておくための確認、照合は必要なのです。
こちらを言及した方がよりよいでしょう。
「control」が現在の「制御する」「管理する」といった意味になるまでの主な流れは以下の通りです。
この流れから、「control」のコアな概念は、記録を照合して物事を正しくチェックし、それに基づいて物事を支配・管理するという点にあることが分かります。
拙稿でも述べた「Manual」の語源が「手を動かす」から来るように、「Control」の語源は記録することにあります。
いくらバックアップがあるから安心はできるといっても、それは両翼の片方に過ぎません。このバックアップでどうやって「破滅を回避するか」というもう一つの翼を担うのが「切り戻しの手順」というお話。
この姿勢を貫くためにも、筆者は“片羽の妖精”ことラリー・フォルクのこの言葉を目につくところに掲げて自らの戒めとしています。
Those who survive a long time on the battlefield start to think they are invincible. / 不死身のエースってのは戦場に長く居たものの過信だ。
I bet you do too, buddy. / お前のことだよ相棒。
――Ace Combat Zero
筆者はサーバ運用の、ほぼすべてを手順化しています。
「なぜ、趣味の一環なのにプロのような手順を設けているのか」を疑問に持った方もいるでしょう。
これに関しての理由付けを示します。
これに尽きます。私の性格上、一度躓いた作業は二度目以降も同じところで詰まります。
「この私なら絶対にやらかす」
という、自分の信頼のなさへの信頼感があるため、
などのPoint of No Return (回帰不能点)を少しでも減らすための強力なアンカーとしてマニュアルを作成しています。
特に、障害というやつは「起きてほしくないタイミングで起きる」から障害なのですから。
そもそも「マニュアル(Manual)」とは、ラテン語の「manus(手)」という単語に由来しています。
元々は「手を使う」「主導の」と言った意味の形容詞でしたが、そこから派生して「手引き」や「取扱説明書」といった名詞の意味で使われるようになりました。
なども、すべて同じ語源から来ており、「手」に関する言葉となっています。
古代ローマ軍が規格外の強さを誇った背景には、「行動が全てであり、一定の標準的機能の遂行が勝敗を決定する」という思想があったとされています。
特に、古代ローマ軍の圧倒的な強さは「各人が優れた土木技術者であり、野営のみならず街を作ることすら可能だった」ことにも現れています。
各軍人が軍事技術だけではなく土木技術の手引き書も共有化されていたからでした。
マニュアル通りとは、漫画や小説で言う
という意味ではないと筆者は考えます。むしろ「想定外の出来事が起きたとしても標準以上の行動ができるための引き出し」として定義しています。
など、すべての人が生み出した技術は言語化される余地があります。この言語化というやつは「自分の意を伝える」「相手の意をくみ取る」の両方で必要であり、他者からのフィードバックをもらうための最高の機会となります。
失敗した部分のロギングです。
「マニュアルのどこが行けなかったのか?」を確認することで、すっ飛ばしたところや、怠った事による裏目がすべて結果となって現れます。
以下、筆者が過去に行った「Ubuntuサーバにスワップを設定する」手順です。ここで、実際にどのような点に気をつけてマニュアルを作っていったかを解説します。
### 環境
- Ubuntu 24.04
- 4GBメモリ/80GBディスクのインスタンスを利用
### さっくりとした手順
1. 現在のメモリとディスク容量を確認します。
1. Swap領域を確保します。
1. 確保したSwap領域を有効化します。
1. Swap領域が増えたことを確認します。
1. fstabを修正します。
1. fstab修正後にシステムを再起動し、Swap領域有効化を確認します。
#### 作業の前に
ディスク起動時のオプションなど、特に重要なシステム領域の設定ファイルを修正する作業です。
失敗時に復旧できるようシステム全体のバックアップを取ることを強く推奨します。
これは、先に挙げたPoint of No Return (回帰不能点)を「Point of Returnable (回帰可能点) 」とするためのおまじないです。最悪の事態を挙げておくことで、もしもの時に備えます。
#### 現在のメモリ情報を確認
- メモリ情報を確認
free -h
-hオプションは(human readable)の略だそうです
- 実行結果
total used free shared buff/cache available
Mem: 3.8Gi 450Mi 2.9Gi 2.5Mi 688Mi 3.4Gi
Swap: 0B 0B 0B
Swapが全く作成されていません。
#### 現在のディスク容量の確認
- 要領確認
df -h
- ○実行結果
Filesystem Size Used Avail Use% Mounted on
/dev/root 78G 5.0G 73G 7% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 784M 980K 783M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/vda15 105M 6.1M 99M 6% /boot/efi
tmpfs 392M 12K 392M 1% /run/user/1001
容量は問題ありません。実メモリと同じ4GBの領域を作ります。
と、作業の前の確認を行います。Markdownの判定で省いていますが、
1コマンド1ブロック というルールを遵守するように筆者は心がけています。
それがたとえ、参照するための
free -h
であってもです。この、最初の一歩を確認できない場合は
sudo rm -rf ./*
などの重要で致命的なコマンドも疎かにしてしまうからです。
#### Swap領域の確保
- Swap領域作成
sudo fallocate -l 4G /swap
- ファイル作成確認
ls -ldh /swap
指定ディレクトリに4GBのファイルがあることを確認します。
#### Swapの有効化
- /swapのパーミッション変更
sudo chmod 600 /swap
- パーミッション変更確認
ls -ldh /swap
rootのみが読み書き可能なことを確認します\
#### /swapの設定
- Swap領域作成
sudo mkswap /swap
- 実行結果
スワップ空間バージョン 1 を設定します。サイズ = 4 GiB (4294963200 バイト)
ラベルはありません, UUID=08cf06da-757e-4ab4-b049-e7da8ee73341
★/swapの有効化
sudo swapon /swap
#### Swap有効化確認
- メモリ情報確認
free -h
- ○実行結果
total used free shared buff/cache available
Mem: 3.8Gi 446Mi 2.9Gi 2.5Mi 689Mi 3.4Gi
Swap: 4.0Gi 0B 4.0Gi
4GBのSwap領域が確保されました。
ここで、作業手順を一気に書きます。ここでも、一つ一つの確認を行うことで、「すっ飛ばしたときのリカバリー」を容易にしています。
#### fstab設定
- /etc/fstabのバックアップ
sudo cp -pi /etc/fstab /path/to/backup/directory/fstab.$(date +%Y%m%d)
- バックアップ作成確認
diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab
差分が無いことでバックアップが取れていることを確認します。
- /etc/fstab追記
cat <<- __EOF__ | sudo tee -a /etc/fstab
/swap none swap sw 0 0
__EOF__
- 差分確認
diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab
- 差分
+/swap none swap sw 0 0
ここでは、「単にスワップを作成しただけでは終わらない」というLinuxのファイルシステムに言及しています。この/etc/fstabはディスク全体を司るテキスト群。そのため、
teeによる追記と、「実際に作業を行ったか」を感覚では無くコマンドという冷静で絶対的な眼として確認します。
#### 再起動後の修正確認
- システム再起動
sudo reboot
- 再起動後の確認
以下が確認できれば作業完了です。
1. サーバにログインできること
1. Webサービスなど既存システムが設定前と同様に稼働すること
1. free -h を実行し、Swap領域が確保されていること
ここで、最終確認を行います。rebootを実施するのは、それだけシステム全体に関わる作業を行うからです。
ようやく筆者の「標準」といえる手順書が作成されました。まぁ、最初にここまでやるというのは酷な話ではあると思いますが
systemctl status apache2.service→sudo systemctl restart apache2.service程度で構いません。と、ある程度の段階を積んでいくことが、より確実な手順と言えます。
「自分で作った手順書が有効かどうか、第三者に実際に行ってもらう」手法は極めて有効です。
その手順書で失敗してしまったら → 確実に作成した自分自身の責任です。
この、言語化・共有化というのは「間違った手段も共有される可能性がある」からです。私もそうならないよう気をつけますが、
『超電磁マシーン ボルテスV』の
岡長官
「そんな杓子定規な」
左近寺博士
「杓子結構、定規賛成」
という、割とガチめの引用で以て本稿を締めくくります。
2025年10月にサポート終了を迎えたWindows 10。
巷では
などの記事を見かけたと思います。
しかしながら
程度ではビジネスユースはおろか日常の
の同時利用には「とうてい耐えられない」と言い切れる根拠。
言い換えると「絶対に越えられない壁」という奴を「リソースの消費量」という形で証明します。
それも、巷にあるベンチマークソフトを使わずに。『アカギ』で言うところの「俺はもっと ストレートに行くよ……」です。
のみです。
テキストエディタを用いて、以下のパワーシェルスクリプトを作成します。
C:\batあたりにディレクトリを掘っておくといいでしょう。
# --- ユーザー設定 ---
# ファイルサーバ上のWordファイル(UNCパス)
# サンプルとして、ファイルサーバー名、共有名、ディレクトリ名を一般的なものに変更しています。
# 実際の環境に合わせてパスを変更してください。
$FilePath = '\\YourFileServer\ShareName\SampleProject\TestDocument.docx'
# ログファイル(ローカル保存)
$LogPath = "C:\Temp\Log\word_benchmark_log.txt"
# ------------------
# --- ログ出力関数(リトライ付き) ---
function Write-Log {
param (
[string]$Message,
[string]$Color = "White"
)
# コンソール出力
Write-Host $Message -ForegroundColor $Color
# ログファイル出力(リトライ付き)
$maxRetries = 5
$retryDelay = 500 # ミリ秒
for ($i = 0; $i -lt $maxRetries; $i++) {
try {
# ログファイルのディレクトリが存在しない場合は作成
$LogDir = Split-Path -Path $LogPath -Parent
if (-not (Test-Path $LogDir)) {
New-Item -Path $LogDir -ItemType Directory | Out-Null
}
Add-Content -Path $LogPath -Value ("[{0}] {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $Message)
break
} catch {
Write-Host "WARN: ログ書き込みに失敗しました。リトライ中... ($i/$maxRetries)" -ForegroundColor "DarkYellow"
Start-Sleep -Milliseconds $retryDelay
}
}
}
# --- 初期化 ---
# ログファイルをクリア
Clear-Content -Path $LogPath -ErrorAction SilentlyContinue
Write-Log -Message "--- Word(UNCパス指定)ベンチマークテスト ---" -Color "Yellow"
# --- ファイル存在確認 ---
if (-not (Test-Path $FilePath)) {
Write-Log -Message "エラー: 指定されたファイルが見つかりません。パスを確認してください: $FilePath" -Color "Red"
return
}
# --- 既存のWordプロセスを終了 ---
Write-Log -Message "INFO: 既存のWordプロセスをクリーンアップします..." -Color "White"
Get-Process winword -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep -Seconds 2
# --- 変数初期化 ---
$wordApp = $null
$document = $null
$TimeTaken = $null
$ProcInfo = $null
# COMメソッドの省略可能な引数に使用する値
$Missing = [System.Reflection.Missing]::Value
try {
# 1. Word起動とファイルオープンの時間を計測
Write-Log -Message "1. Wordの起動とファイルオープンを計測中..." -Color "White"
$TimeTaken = Measure-Command {
# Wordアプリケーションのインスタンスを作成
$wordApp = New-Object -ComObject "Word.Application"
# ファイルを開く (引数: FilePath, ConfirmConversions, ReadOnly, AddToRecentFiles, PasswordDocument, PasswordTemplate, Revert, WritePassword, Format, Encoding, Visible)
$document = $wordApp.Documents.Open(
$FilePath,
$false, # ConfirmConversions
$false, # ReadOnly
$false, # AddToRecentFiles
$Missing, # PasswordDocument
$Missing, # PasswordTemplate
$false, # Revert
$Missing, # WritePassword
$Missing, # Format
$Missing, # Encoding
$false # Visible (False: 開いた直後は非表示)
)
}
# Wordを可視化し、プロセスが完全に立ち上がるのを待つ
$wordApp.Visible = $true
Start-Sleep -Seconds 2
$StartTimeSec = [math]::Round($TimeTaken.TotalSeconds, 2)
Write-Log -Message " [結果] 起動&ファイルオープン時間: $StartTimeSec 秒" -Color "Green"
# 2. リソース使用量の計測
Write-Log -Message "2. リソース使用量を計測中..." -Color "White"
Start-Sleep -Seconds 3 # リソースが安定するのを待つ
$ProcInfo = Get-Process winword -ErrorAction SilentlyContinue
if ($ProcInfo) {
# 複数のwinwordプロセスがある場合の合計を計測
$TotalMemMB = [math]::Round( ($ProcInfo | Measure-Object -Property WS -Sum).Sum / 1MB, 2)
$TotalCpuSec = ($ProcInfo | Measure-Object -Property CPU -Sum).Sum
if ($TotalCpuSec -eq $null) { $TotalCpuSec = 0 }
$TotalCpuSec = [math]::Round($TotalCpuSec, 2)
Write-Log -Message " [結果] メモリ使用量 (WS 合計): $TotalMemMB MB" -Color "Green"
Write-Log -Message " [結果] CPU使用時間 (Total 合計): $TotalCpuSec 秒" -Color "Green"
} else {
Write-Log -Message " [警告] Wordプロセスが見つかりませんでした。" -Color "Yellow"
}
} catch {
Write-Log -Message "致命的なエラーが発生しました: $($_.Exception.Message)" -Color "Red"
# エラーの詳細ログ
Write-Log -Message "エラー詳細: $($_.ScriptStackTrace)" -Color "Red"
} finally {
# 3. クリーンアップ
Write-Log -Message "3. クリーンアップを実行します。" -Color "White"
if ($document -ne $null) {
# 変更を保存せずに閉じる
try {
$document.Close($false)
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($document) | Out-Null
} catch {
Write-Log -Message "WARN: Document COMオブジェクトのクリーンアップ中にエラー: $($_.Exception.Message)" -Color "DarkYellow"
}
}
if ($wordApp -ne $null) {
try {
$wordApp.Quit()
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($wordApp) | Out-Null
} catch {
Write-Log -Message "WARN: Application COMオブジェクトのクリーンアップ中にエラー: $($_.Exception.Message)" -Color "DarkYellow"
}
}
# 変数の解放
Remove-Variable wordApp, document, ProcInfo, TimeTaken -ErrorAction SilentlyContinue
# 残っているWordプロセスを強制終了
$remaining = Get-Process winword -ErrorAction SilentlyContinue
if ($remaining) {
Write-Log -Message "INFO: 残留Wordプロセスを強制終了しました。" -Color "White"
$remaining | Stop-Process -Force
}
Write-Log -Message "--- テスト完了 ---" -Color "Yellow"
}
開きたいファイルを正確に指定し、文字コードをUTF-8(BOMつき)で保存します。
まず、Windows Powershellを開きます。(管理者権限である必要はありません)
次に、スクリプトに一時的な実行権を与えます。(デフォルトでは自作のスクリプトの実行権が与えられていないため)
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
そうした上で、
& "C:\script\benchmark_word.ps1"
を実行。
結果は以下の通りです。
--- Word(UNCパス指定)ベンチマークテスト ---
INFO: 既存のWordプロセスをクリーンアップします...
1. Wordの起動とファイルオープンを計測中...
[結果] 起動&ファイルオープン時間: 1.36 秒
2. リソース使用量を計測中...
[結果] メモリ使用量 (WS 合計): 289.7 MB
[結果] CPU使用時間 (Total 合計): 4.44 秒
3. クリーンアップを実行します。
INFO: 残留Wordプロセスを強制終了しました。
と、300MB近くの使用量がありました。数MB程度の文書を開く際でも、ワードのようなモダンアプリケーションはメモリもCPUもそれなりに使うことが判明。
続いて、ブラウザの場合はどうなるでしょうか? 先ほどのフォルダに
benchmark_chrome.ps1
を作成します。
# --- ユーザー設定 ---
# ログファイル(ローカル保存)
$LogPath = "C:\Temp\Log\chrome_benchmark_log.txt"
# Chromeの実行ファイルパス (通常はこのままでOK)
$ChromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"
# 検索するURLとクエリ
$InitialUrl = "https://www.google.com/search?q=wikipedia"
# ------------------
# --- ログ出力関数(リトライ付き) ---
# (前回のスクリプトから変更なし)
function Write-Log {
param (
[string]$Message,
[string]$Color = "White"
)
Write-Host $Message -ForegroundColor $Color
$maxRetries = 5
$retryDelay = 500 # ミリ秒
for ($i = 0; $i -lt $maxRetries; $i++) {
try {
$LogDir = Split-Path -Path $LogPath -Parent
if (-not (Test-Path $LogDir)) {
New-Item -Path $LogDir -ItemType Directory | Out-Null
}
Add-Content -Path $LogPath -Value ("[{0}] {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $Message)
break
} catch {
Write-Host "WARN: ログ書き込みに失敗しました。リトライ中... ($i/$maxRetries)" -ForegroundColor "DarkYellow"
Start-Sleep -Milliseconds $retryDelay
}
}
}
# --- 初期化 ---
Clear-Content -Path $LogPath -ErrorAction SilentlyContinue
Write-Log -Message "--- Chrome Webアクセス・ベンチマークテスト ---" -Color "Yellow"
# --- 実行ファイル存在確認 ---
if (-not (Test-Path $ChromePath)) {
Write-Log -Message "エラー: Chrome実行ファイルが見つかりません。パスを確認してください: $ChromePath" -Color "Red"
return
}
# --- 既存のChromeプロセスを終了 ---
Write-Log -Message "INFO: 既存のChromeプロセスをクリーンアップします..." -Color "White"
Get-Process chrome -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep -Seconds 2
# --- 変数初期化 ---
$TimeTaken = $null
$ProcInfo = $null
try {
# 1. Chrome起動、Google検索、Wikipedia移動の時間を計測
Write-Log -Message "1. Chrome起動からWikipedia表示までの時間を計測中..." -Color "White"
# ストップウォッチを開始
$Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
# Chromeを起動し、Google検索URLへ移動
# -Wait: プロセスが終了するまで待機(この場合はタブを閉じるまで待機してしまうため使用しない)
$Proc = Start-Process -FilePath $ChromePath -ArgumentList $InitialUrl -PassThru
# プロセスが完全に立ち上がり、ページがロードされるのを待機
# ページの完全なロード完了を正確に捕捉するのは困難なため、ここでは固定の待機時間を使用します。
Start-Sleep -Seconds 5
# ストップウォッチを停止
$Stopwatch.Stop()
$TimeTaken = $Stopwatch.Elapsed
$StartTimeSec = [math]::Round($TimeTaken.TotalSeconds, 2)
Write-Log -Message " [結果] 起動&Webアクセス時間: $StartTimeSec 秒" -Color "Green"
# 2. リソース使用量の計測
Write-Log -Message "2. リソース使用量を計測中..." -Color "White"
Start-Sleep -Seconds 3 # リソースが安定するのを待つ
# Chromeは複数プロセスで実行されるため、全てを対象とする
$ProcInfo = Get-Process chrome -ErrorAction SilentlyContinue
if ($ProcInfo) {
# 複数のchromeプロセスの合計を計測
$TotalMemMB = [math]::Round( ($ProcInfo | Measure-Object -Property WS -Sum).Sum / 1MB, 2)
$TotalCpuSec = ($ProcInfo | Measure-Object -Property CPU -Sum).Sum
if ($TotalCpuSec -eq $null) { $TotalCpuSec = 0 }
$TotalCpuSec = [math]::Round($TotalCpuSec, 2)
Write-Log -Message " [結果] メモリ使用量 (WS 合計): $TotalMemMB MB" -Color "Green"
Write-Log -Message " [結果] CPU使用時間 (Total 合計): $TotalCpuSec 秒" -Color "Green"
} else {
Write-Log -Message " [警告] Chromeプロセスが見つかりませんでした。" -Color "Yellow"
}
} catch {
Write-Log -Message "致命的なエラーが発生しました: $($_.Exception.Message)" -Color "Red"
Write-Log -Message "エラー詳細: $($_.ScriptStackTrace)" -Color "Red"
} finally {
# 3. クリーンアップ
Write-Log -Message "3. クリーンアップを実行します。" -Color "White"
# 確実にChromeプロセスを終了
$remaining = Get-Process chrome -ErrorAction SilentlyContinue
if ($remaining) {
Write-Log -Message "INFO: 残留Chromeプロセスを強制終了しました。" -Color "White"
$remaining | Stop-Process -Force
}
Write-Log -Message "--- テスト完了 ---" -Color "Yellow"
}
まず、Windows Powershellを開きます。(管理者権限である必要はありません)
次に、スクリプトに一時的な実行権を与えます。(デフォルトでは自作のスクリプトの実行権が与えられていないため)
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
そうした上で、
& "C:\script\benchmark_chrome.ps1"
を実行。以下の驚くべき結果が出ました。
--- Chrome Webアクセス・ベンチマークテスト ---
INFO: 既存のChromeプロセスをクリーンアップします...
1. Chrome起動からWikipedia表示までの時間を計測中...
[結果] 起動&Webアクセス時間: 5.03 秒
2. リソース使用量を計測中...
[結果] メモリ使用量 (WS 合計): 1413.37 MB
[結果] CPU使用時間 (Total 合計): 17.97 秒
3. クリーンアップを実行します。
INFO: 残留Chromeプロセスを強制終了しました。
--- テスト完了 ---
なんと、メモリは1.4GB利用。単にWikipediaを計算しただけです。
補足しておくと、この検証に使用した筆者の環境は
と、ビジネスユースにしては「化け物」なスペックであってもです。
という現代の環境において、以下のポイントが、「ネット閲覧程度であれば云々」の神話を打ち破る主要な論拠となります。
Chrome(および他のモダンブラウザ)が採用しているマルチプロセスアーキテクチャが、メモリ消費量の最大の原因です。
結果として、たった1つのタブを開いているだけでも、タスクマネージャー上では10〜30個のchrome.exeプロセスが立ち上がり、ベンチマーク結果のように、それらの合計で1GBを優に超えるメモリを消費します。
そして、現在のWebサイトは、単純なテキストや画像で構成されていません。
| アプリケーション | 目的 | メモリ消費量 (WS 合計例) |
|---|---|---|
| Word (COM操作/UNCファイル) | 文書作成(重量級ローカルアプリ) | 約 290 MB |
| Chrome (Google検索 → Wikipedia) | ウェブ閲覧(単一タブ) | 約 1,413 MB |
この対比から、現代の「ウェブ閲覧」が、伝統的なローカルの重量級アプリケーションよりも、起動直後で約5倍近いメモリリソースを要求することが明確に示されます。
ここに、
が加わるとなると、古い、低スペックのハードウェアをLinuxに変えた「程度」では、付け焼き刃にすらなりません。
したがって、「ネット閲覧程度」の利用を想定してPCのスペックを決める場合、最低でも16GBのメモリを搭載しないと、動作が非常に緩慢になるリスクが高いという結論になります。
なぜなら、2025年現在、通常のインターネット環境でのビジネスや学習というのは「ブラウザのタブ多重起動」を前提に作られているのですから。
ジェレミー・クラークソン(旧TopGearやGrandTour司会者)の
Power is EVERYTHING. More is better.
( パワーはすべてを解決する。気筒数は多ければ多いほどいい)
や
A horsepower, A horsepower!
Horsepower for my kingdom!
「馬力だ! 馬力の代わりに我が王国をやるぞ!」
は、こと、PCのリソース割当については「反論の余地がない真である」という結論で本稿を締めくくります。
前回、「万年筆」を
という理由で使い始めました。その書き味や機能性に惹かれて言った結果、なぜLAMY Safari(AL-Star)を選択したかという部分について解説します。
『メリー・ポピンズ・リターンズ』の『本は表紙じゃ分からない/Cover is not the Book』に曰く
Cover is not the book / 心が目に見えないように本も
So open it up and take a look / 表紙の美しさに騙されちゃダメ
'Cause under the covers one discovers / 中身読んだらやさしい王様
That the king may be a crook / 詐欺師だとわかるかも
とあります。この、「きちんと中身を読んだ」結果として、今の自分はLAMY Safari(AL-Star)になったという形です。
これが一番、自分が良かったと思うポイントです。LAMY万年筆最大の特徴と言えるクリップ付きのキャップ。筆記時、これを後ろにつけることで重心が後ろ寄りになります。これにより、必然的に重心は親指と人差し指の付け根にフィット。
軽く支えるだけでさらさらとした書き味を保証してくれます。
より重いアルミを用いたAL-Starはそれを更に補強。ひんやりとした金属の素材感と相まって「よりしっかりした書き味」を楽しめます。
持ちやすさ、と言い換えてもいいでしょう。持ち手の上が自然にカット(三角形のカーブ)があることで、手になじむような形にフィット。
何よりも、この持ち手が明示されていることで万年筆にありがちな「どこがペン先の上か?」を一切気にする必要がありません。
この場合の速度は
のスタートです。多くの高級万年筆は(キャップレスでない場合は)ネジ式のキャップであるため「キャップを取り外す」がハードルになります。
ですが、LAMY万年筆はシンプルなキャップ式を採用。「取り外す」手間が秒単位で速くなります。

通常色、限定色、チャーム付きなど、多彩なカラーバリエーションがあります。
単に物欲を充たしてくれるのはもちろんのこと、ボディに沿った色のインクを詰めることで、インク補充時に「このライトグリーンには『翠玉』のインクを。黄色には『夕焼け』を選ぶ」と、直感に従ったインク補充が可能になります。
おおよそ道具というものは使ってなんぼ、壊れてなんぼという考えです。なので、「書く」という「思考を伝達する道具」の替えが効かないというのは、それ自体が単一障害点(SPOF: Single Point of Failure):その部分に障害が発生すると、システム全体が停止してしまうような、代替手段のない単一の要素になります。
しかし、LAMY Safariであれば
という、「替えが効く」理由としては十分です。紛失、破損などがあっても「ペンそのものを用意できる」という安心感は非常に有用です。
これに落ち着く前、中華万年筆を使っていました。「安いに越したことはない」と。しかし、
という「安物買いの銭失い」を地で行く結果となりました。この「授業料」の結果、ある程度は出費を覚悟しても(それでも高級万年筆よりは安価です)それなりのものとして白羽の矢が立ったのがLAMY万年筆でした。
最初は「樹脂製のデザイン」等がハードルとなっていましたが
という、量産品の強みが前面に打ち出されたのです。
以上、「格好良さ」から始めた万年筆は、
という筆者のプラグマティズムにより、これを求めたという結論。コレクションを手放すことになったとか、壊れたという話でない限り、他のブランドに手を出すのはまだまだ先となりそうです。何せ、前の記事でお話ししたとおり5年前のSafariが未だに現役なのですから。
ここで、「量産品の強み」を最も的確に表した『ガールズ&パンツァー』、サンダース大付属のアリサがM4シャーマン戦車を
「丈夫で壊れにくいし、おまけに居住性も高い!
バカでも乗れるくらい操縦が簡単で、
バカにも扱えるマニュアル付きよ!」
と評した言葉を以て、本稿を締めくくります。
基本的に筆者はプラグマティズムを以て道具を選びますが「それ以上の理由」。即ち
の2つで使い始めた結果として、この万年筆というスタイルが確立されたという話です。
まずこちらを。

LAMY Safari / AL-Starを中心に、一部は
が一部混じっています。筆者が帰る範囲で諸々を試し、これに落ち着きました。これらは筆者のアナログの言葉通りの意味で屋台骨として支える道具。2025年現在、一番長く使って13年。短くても2年は愛用しています。
結論から言います。万年筆はデメリットが多い道具です。
他の筆記具とベースの価格が違います。(全ての道具は天井知らずなので一般的に買えるものに絞ります)
これら3つは100均でも見かけるものでしょう。
ですが、万年筆は、入門用に限った上でも
おおよそ「500円台〜6,000円台」まで。(Copilot調べ)
| 価格帯 | 特徴・用途例 | 主なモデル例(参考) |
|---|---|---|
| 〜500円 | 超低価格帯。プラスチック製で軽量。試し書きや学生の練習用に最適。 | プラチナ プレピー、ダイソー製品など |
| 1,000〜2,000円 | 初心者向けの定番。カートリッジ式が多い。 | PILOT カクノ、セーラー ふでDEまんねん |
| 2,000〜4,000円 | 書き心地やデザイン性が向上。 | プラチナ プレジール PILOT ライティブ |
| 4,000〜6,000円 | 金属製や透明軸など、質感やインクの楽しみが広がる。長く使える1本に。 | ラミー サファリ、セーラー プロフィットJr.、パイロット コクーン |
| 6,000円以上 | 本格派の入門機。耐久性・筆記性能ともに高く、長期使用を前提とした設計。 | パイロット カスタム74(入門上級) |
と、桁が違います。
ここに「インク」が加わります。日本のボールペンの筆頭ブランドである『Jet Stream』シリーズとカートリッジ式、これら、一つでどこまで書けるのかを見てみます。
| 筆記具 | インク容量の目安 | 書ける文字数(概算) | 原稿用紙(400字詰)換算 | 備考 |
|---|---|---|---|---|
| ジェットストリーム(0.5mm) | 約0.4〜0.5ml | 約20,000〜25,000字 | 約50〜60枚 | 油性・低粘度インクで長持ち |
| パイロット 万年筆カートリッジ | 約0.9ml | 約4,000〜5,000字 | 約10〜12枚 | 字幅や筆圧により変動 |
| セーラー 万年筆カートリッジ | 約1.0ml | 約5,000〜6,000字 | 約12〜15枚 | 染料インクでやや多め |
この時点で、ボールペンのコストパフォーマンスは圧勝。
もっとわかりやすく言うと原稿用紙換算では
というより、ボールペンのインク切れを体験するという方はかなり少ないのではないでしょうか。(書き味が怪しくなったら新しいボールペンを買うというのが基本的な運用だと思います)
また、カートリッジもインクも高額です。(インク沼という言葉を聞いたことがあるかと思います)
万年筆のカートリッジ交換はボールペンとほぼ同じぐらいとは言え手間です。
インク補充式ともなると
と、別次元の手間が加わります。
万年筆は、上記のシャープペンシルや鉛筆、ボールペンなどに比べて「誰でも使える」筆記具ではありません。断じて。
再掲しますが:
漫画『MASTERキートン』に以下のやりとりがあります。
「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
だが、拳銃はデリケートな道具だ。
弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」
万年筆は
全てが劣ります。特に、品質が悪いものともなると、使った瞬間にインクが漏れて服に付着するなんてこともあります。
この、一般的な筆記具ではなく万年筆を筆者が使い続ける理由を述べます。
これに尽きます。ハッキリ言って、これ以外の理由は全て『後付け』に過ぎません。
全てが「他の人と違う特別感」が、使い始めたきっかけでした。
上記、述べたインク補充は、サーバのメンテナンスのごとき、手間をかけることで「自分のものである」という愛着を持つことができます。
自分で組み立てたものなど、自分の手で労力をかけたものに対して、本来の価値以上の価値を見出す心理的な傾向
いわゆる「イケア効果」の発露の表れです。
これもまた別格でした。筆圧が強い方だったので、力を入れずにさらさらと書ける、滑るような書き心地は、一度慣れてしまうと他に戻れなくなった次第です。
上述した通り、手入れされた万年筆は圧倒的な強度を誇ります。
「万年」の名は伊達ではありません。
最終的に
が加わり、ちょっとした万年筆のコレクション群を持ち歩き、日々使い続けているという話でした。では、なぜLAMY Safariに落ち着いたかというのはまた次に機会を設けて記事を記します。
映画『Back to the Future』の
「If you're gonna build a time machine into a car, why not do it with some style?」
「タイムマシンを車にするなら、カッコよく作らなきゃだろ?」
という言葉を以て、本記事はひとまず区切りとします。
Rome was not built in a day.
の言葉を引き合いに出すまでもなく、「趣味での個人Webサーバの運用・管理」というやつは一筋縄ではいきません。
等など、続ければ続けるほど、そして知識を得れば得るほど課題が増えます。そんな中で、どうやってモチベーションを維持していくかという筆者なりの回答です。
『メリー・ポピンズ』と共に筆者が困ったときに立ち返る『サウンド・オブ・ミュージック』。
Raindrops on roses
And whiskers on kittens
Bright copper kettles
で始まる、自分の好きなものを並べた歌詞『My Favourite Things』は
When I’m feeling sad
I simply remember my favourite things
And then I don’t feel so bad
と、「お気に入りのもの」を思い浮かべることで実際軽減される。
ポジティブな注意の転換と感情の自己調整という心理的メカニズムが働くとかなんとか。
ここまでは前にも紹介したもの。
ここに
の3つを加えます。

今年購入したThinkPad。中古とは言え
を有していて、何よりもデザイン性もお気に入り。
重要なのは、ここを介してSSH接続を行える「自分のサーバへのアクセスゲートである」ことです。この、お気に入りの道具を介してサーバ制御を行うというのがモチベーションを維持していくことができます。
写真にも示したのは『夢の島熱帯植物館』。
と、集中にはこれ以上無いほどの条件が揃っています。
そのため、先の歌詞に示した「悲しいとき」でも訪れることにしています。
実際問題として:この夢の島熱帯植物館を舞台に「WebArena → XServerへのWebサイト移行」を行うことができたほどです。


これはあくまでも「自分にとっての」という意味です。美味しい食べ物がモチベーションを以下に高めるかは今更説明するまでもないでしょう。
こちらのコメダ珈琲の「重軽食」とも言えるようなボリュームある食事と糖分は、頭を使うサーバ管理になくてはならないものです。(これは一例ですが)
この『My Favourite Things』の私の学びは
「サーバ作業のような一瞬のミスですべてが持って行かれる作業に際しては、心身共に平衡を取るマインドセットが必要」
ということに尽きます。どっちかが崩れていれば、本当にアホみたいなミスを行ってしまうというのが筆者が様々な失敗という「授業料」での気づきなので。
徹底した金銭のリアリズムを描いた『ナニワ金融道』において以下のやりとりがあります。
「えらい早いやないか灰原君 君は金融屋に向いとるで!」
「いや まぐれですよ まぐれ」
「いやちがう これはあんたの宿命やで!
この業界はのー 不渡りが不渡りを呼ぶんや
だからワシ等はゲンを担ぐんや
初日のしょっぱなで(融資の見込み客を)ひっかけたんや
金融屋になるのはあんたの宿命やで!」
と、この、リアリズムに生きている世界ですら「ジンクス」とか「験を担ぐ」というマインドセットが必要という身も蓋もない結論を以て本稿を締めくくります。
筆者が取得している
の2つ。この、「取れてしまった」ドメインと、そのドメインという『かんばん』を通して、何故、サーバ維持でドメインが大切かという問いかけからのお話と、それを取得するためのちょっとしたコツについてです。
街角の店舗が看板を掲げるように、インターネットの世界でも「ここに存在しています」と示すための名前がドメインです。
ドメインとは、
でもあります。
インターネット上で情報を発信したり、サービスを提供したり、世界に向けて何かを伝えたいなら、まずは「かんばん」を立てることから始まります。
ここに、もう一つ。筆者はこのやりとりを加えます。ダンディズムの規範としている池波正太郎の著作から。
「人間、落ちるところへ落ちてしまっても、なにかこう、この胸の中に、たよるものがほしいのだねえ」
「たよるもの、ねえ…」
「いえば看板みたいなものさ」
「かんばん、かね…?」
「人間、だれしも看板をかけていまさあね。旦那のお店にもかけてござんしょう」
――『にっぽん怪盗伝』
つまり、筆者は「サーバ維持の強烈な推進剤」として、このドメインを取得。「すべてはこの看板の名に恥じないような」ものとして
を書いています。言うなれば「伊達」と「酔狂」の4文字2単語を元にサイトを運営しています。
そこで、次から「個人でサイトを運営してみたい」という方を対象としたドメイン選びのコツについて筆者の経験を交えながらご紹介です。
ドメインを取るにはそれなりのコツがあります。
これが一番です。
どんな平易で短い文字列でも、自分に馴染みがなければ無意味です。
逆に、どんなに長く難しい文字列でも、自分が覚えられれば自分にとってのドメインとなります。
Supercalifragilisticexpialidocious
など、知らない人に取ってみれば「何この長い単語」ですが、『メリー・ポピンズ』を知っている人にとっては歌を口ずさむことができる程度のリズムで言えるでしょう。
「自分のサイト」である以上、「自分のわがまま」を最優先としましょう。
とはいえ、インターネットのドメインとは絶対的なルールがあります。
の2点。特に前者は重要です。
いくら自分にぴったりな、「自分の推しを体現する」ドメインを持っていたとしても、「既に登録されている」というメッセージが出たら、それに従うほかありません。その場合は
等を行いましょう。後者の「恐ろしく高い」に関しては、それを出す価値があるという確固たる自信があり、それを発展させていくだけの継続力があるならば「身代を潰さない程度に」と言葉を濁します。
それ故に、筆者が
のドメインが空いており、かつ、定価で取得できると知ったときは
ほどです。
多くのドメイン取得サービス業者(レジストラ)は「今なら○○円が無料!」などと謳われていますが条件に注意しましょう。
まず、ドメインは「買って終わり」ではありません。その後、使い続ける以上は「維持費」が必要になってきます。以下に示すのは安いTLD/高いTLDです。
| TLD | 特徴・用途 | 備考 |
|---|---|---|
| .com | 最も一般的。企業・個人問わず人気 | 更新料も比較的安定 |
| .net | 技術系やインフラ系に多く使われる | .comと同程度 |
| .info | 情報提供サイト向け | 初期費用が安いことも |
| .xyz | 新興TLD。自由度が高く人気上昇中 | キャンペーン多め |
| TLD | 特徴・用途 | 備考 |
|---|---|---|
| .jp | 日本国内向け。信頼性が高い | 年間約3,500円〜6,000円 |
| .co.jp | 法人限定。企業向けの信頼性が高いTLD | 年間6,000円以上(後述するWhois情報公開代行は利用不可) |
| .tokyo | 地域性を強調。ブランド戦略向け | 年間3,000円〜5,000円 |
| .shop | ECサイト向け。商用利用に最適 | 年間4,000円〜6,500円 |
例えば某ドットコムなどは
「レンタルサーバサービスの申込で無料」と但し書きがつきます。
そのレンタルサーバが(初年度は無料の代わりに)割高というパターンがあります。その罠に騙されないようにしましょう。
更に、「サービス維持調整費」と称して、更新費用とは別の手数料を取ってくるパターンもあります。
ただ、そのサービス維持調整費との合計を加味しても「他のレジストラと比べて妥当な金額」というケースもありますので、それは「隠れて金取りやがって某ドットコム許すまじ」という怒りはほどほどに。
ドメイン取得時や取得後に、Whois情報公開代行サービスを設定することで、登録者の個人情報の代わりに、ドメイン業者の代理情報が表示されるサービスです。
など、個人/匿名で活動したい人には極めて重要なサービスです。これにより、自宅凸といった物理的な障害から排除されます。
そもそもドメイン(domnain)とは
と言った自分の間合い、領域、世界を表す言葉。それ故に、自分が趣味などで運用するドメインは
ものを選ぶべきと言う、「自分勝手な中での合理性」を持ちましょうという話でした。
巷で言われている「某ドットコム」のレジストラはホントに評判が悪いのか?
に際しては、以下の古くからのコピペを以て、締めの言葉に代えさせていただきます。
お前ら某ドットコムはクソとか言ってるけど実際に登録してドメイン管理をして言ってんの?
ろくにサイト運営すらもしないで某ドットコム批判してんじゃねーよ
インフルエンサーのお気持ち表明に影響されて某ドットコム批判かよ
俺はここでドメインを取得して某ドットコムが言うほど高くないのを知った
そして思ったんだけどやっぱり門倉ってクソだわ
筆者が用いているWebへの攻撃を防ぐ、MOD_SECURITYとApache設定、シェルスクリプトの連携「ONE OUTSシステム」。これは「実際にWebサイトにアクセスした者」への盾として機能していますが、「アクセス未満」での低レイヤーでの攻撃を仕掛ける者を防ぎきることができません。
例えば、SYNフラッド攻撃はWebサイトへの攻撃を仕掛けるわけではないのでログに残らず、じわじわとリソースを奪っていきます。
かといって、これらのSYNフラッド攻撃は極めて広範囲のIPレンジから仕掛けてくるので
sudo ufw insert 1 deny from xxx.xxx.xxx.xxx
とするには、ufwでのルールが広範になりすぎてメンテナンス性ならびにシステムパフォーマンスの低下を招きます。
これを解決するための手段を設けました。
これは、カーネルメモリにufwのブロックリストを付与する、「破壊的アップデート」の可能性が発生します。
を 組織単位 で行う必要があります。
※筆者の好みでaptitudeを用いています。環境に合わせてapt等に読み替えます。
sudo aptitude update
sudo aptitude install ipset
※ 要注意 ※
ここでは、ipset-persistantコマンドを入れていません。なぜなら、ufwと競合する結果、パッケージ管理はufwを破壊する可能性があるからです。
ipset -v
ipset v7.19, protocol version: 7
ipset v7.19: Kernel error received: Operation not permitted
※この、not permittedは、root権限で実行していないため許可されていないというメッセージです。
これは再起動時に消えます
sudo ipset create ufw-blocklist hash:net
sudo cp -pi /etc/ufw/before.rules /path/to/backup/before.rules.$(date +%Y%m%d)
→ バックアップ先は任意のものを指定します
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules
※ここでsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです
/etc/ufw/before.rules を開き、# End required lines という行を探し、その直後にルールを挿入します。# ... (省略: *filter や :ufw-... の行) ...
:ufw-not-local - [0:0]
# End required lines
# ===================================================================
# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
# (一番最初に評価させるため、初期化行の直後に記述)
-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
# ===================================================================
# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
# ... (以下、既存のルールが続く) ...
※ RELATED,ESTABLISHED の許可ルールは、デフォルトの before.rules ではさらに下の方に記述されているか、あるいは ufw 本体が自動的に管理するため、ここに明示的に書かなくても機能します。
(もし明示的に書く場合でも、必ず上記の DROPルールの下 に来るようにしてください)
修正後の diff は以下のようになるはずです。
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines
+# ===================================================================
+# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
+-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
+# ===================================================================
+
# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
さて、ここまで手順通りに行えばufwのリロードは正常に完了します。しかし、ここで今一度
sudo ipset create ufw-blocklist hash:netを実行したか?/etc/ufw/before.rulesを編集したか?を確認しましょう。確認しなければ、この先に待ち構えているのは「失敗した場合の自分自身のロックアウト」にもつながります。
よく深呼吸しましょう。実行前に何か飲み物を飲んでおいてもいいぐらいです。
sudo ufw reload
ファイアウォールを再読込しましたのメッセージが出れば成功です!
sudo ufw status
でも状態:アクティブを確認します。
ipset-persistent の代わりに、UFW自身の起動・停止スクリプトに、リストの保存・復元を組み込みます。
まず、ipset のリストを保存するファイルを決めておきましょう。 ここではIPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"と定義します。
ufw が起動する前に、保存したリストを読み込むようにします。
sudo cp -pi /etc/ufw/before.init /path/to/backup/before.init.$(date +%Y%m%d)
でバックアップを取ります。(バックアップディレクトリを一括にしているならbefore.init.$(date +%Y%m%d)の前にbefore.rules.$(date +%Y%m%d)を作っているはず。「タブの補間はせず、確実にファイルのバックアップを取りましょう)
sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init
で、バックアップが成功していることも確認します。※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです
/etc/ufw/before.initを編集します。
ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。
IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
# 起動時に ipset リストをファイルから復元する
if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
fi
sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init
#!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 起動時に ipset リストをファイルから復元する
+if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
+ ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
+fi
を確認。
ufw が停止(またはリロード、シャットダウン)する後に、現在のリストをファイルに保存するようにします。
sudo cp -pi /etc/ufw/after.init /etc/conf_backup/after.init.$(date +%Y%m%d)
sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init
※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです
/etc/ufw/after.initを管理者権限で編集します。 ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。
IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
# 停止時に現在の ipset リストをファイルに保存する
ipset save -f "$IPTABLES_IPSET_SAVE_FILE"
追記後、
sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init
で差分を確認します。
#!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 停止時に現在の ipset リストをファイルに保存する
+ipset save -f "$IPTABLES_IPSET_SAVE_FILE"
sudo chmod +x /etc/ufw/before.init /etc/ufw/after.init
→ コマンドを追記しているので重要です!
ここでも
/etc/ufw/before.initを編集し、差分通りか?etc/ufw/before.initを編集し、差分通りか?/etc/ufw/before.init /etc/ufw/after.initに実行権限が付与されているか?を確認しましょう。確認しなければ、こちらも自分自身のロックアウトにつながります。
よく深呼吸しましょう。今度は手元にあればお茶菓子を食べてもいいぐらいです。
sudo ufw reload
ファイアウォールを再読込しましたのメッセージが出れば成功です!
sudo ufw status
でも状態:アクティブを確認します。
これは、対象のIPアドレスをシャットアウトする「慈悲なき王」です。
ブロック対象は慎重に慎重を期します。
sudo ipset add ufw-blocklist IPアドレス・NWアドレス
→ 実際のIPアドレスを半角で入力しましょう。
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save
(sudo ipset save ではない点に注意してください)
cat /etc/ufw/ipsets.save
として
create ufw-blocklist hash:net family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xcce80b68
add ufw-blocklist IPアドレス・NWアドレス
等と表示されれば成功です。
※この作業はufwリロード不要です。※
「相手が回りくどい攻撃をしてきたら、更に回りくどい方法をとらなければならない」という形。
正直、この作業は二度とやりたくない部類に入ります。ですが、一度設定してしまえば
sudo ipset add ufw-blocklist IPアドレス・NWアドレス
で永続的に執拗な攻撃を仕掛ける攻撃者に対処することが可能です。
Powered by WordPress & Theme by Anders Norén