投稿

ディスクの状態を確認するためにsmartctlを利用しました

記事の更新日:2026/09/30 評価を加筆 1.概要 smartctl は、ストレージデバイス(HDDやSSD)の健康状態や S.M.A.R.T. 情報を監視・診断するためのコマンドラインツールです。S.M.A.R.T.を利用すると、使用時間や電源投入回数、温度、不良セクタ数を調べることができます。実際に、ディスクの状態を確認するためにsmartctlを利用しました。その内容を記述します。 私の評価は以下の通りです。 (1) smartctlは標準機能です。ストレージ障害に備えて利用方法を学習しましょう (2) 使い方は簡単ですが、表示内容の理解が難しい (3) 短期的な観察よりも、長期的な視点で観察することを求められる (4) ストレージ運用の経験値を上げることが重要なこと 2.詳細 (1)調査を始めた理由 500GBのディスクがクラッシュのメッセージを出力して、grubによるブートができなくなりました。しかし、不思議なことにfsckを実行するとエラーなし、各パーティション内のファイルも参照できます。パーティションテーブルを再構築して、再度試しても状況は同じになります。この内容に関して記述します。 障害を解析した訳ではないので、詳細に関しては不明瞭な点が多数あります。grubを利用したbootだけがだめになってしまたディスクのようです。別の代替ディスクに交換して、環境を再構築すると問題はなくなりました。つまり、ディスクはクラッシュしていたと言うことですが、gparted, fsck, fdisk, mkfsでエラーにならない故障でした。 fdiskでディスクを調べていて、2048セクター以前の領域はユーザ側で利用できないことに気が付きました。0〜2047セクターなので、2048 * 512 = 1MBの領域です。ここには、パーティションテーブル以外にもbootに必要な情報が保管されています。私はmsdosパーティションテーブルを利用しているので、MBRが存在します。今回の故障はMBRは無事ですが、2047セクター内のmsdosパーティションテーブル以降の場所でクラッシュが起きたようです。ユーザーが普通利用する領域は無事なのでデータディスクとしては使えるようです。 (2)smartctlの調査 S.M.A.R.T.(Self-Monitoring Analysi...

openSSHで脆弱性の大きな問題が発生 ( openSSH / openSSL / SLUBStick )

記事の更新: 2026/08/31 1.概要 openSSHで脆弱性の大きな問題が発生して対応した内容です。既に過去のことになっていますが、openSSHで問題が発生すると影響が大きいので、すぐに修正を適用しましょう。 また、openSSHに関連したツール類の利用に関して試したことを追記しています。色々なことがopenSSHを基盤に実施することができます。参考にしてください。 2.詳細 ubuntu terminalから下記コマンドでsshのVersionを確認します。 ssh -V (a) ubuntu 20.04.6 6月頃の少し古い環境です OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020 アップデートをしました。 OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020 このバージョンは過去に修正済みで問題ないようです。 (b) ubuntu 22.04.4 6月頃の少し古い環境です OpenSSH_8.9p1 Ubuntu-3ubuntu0.7, OpenSSL 3.0.2 15 Mar 2022 アップデートをしました。 OpenSSH_8.9p1 Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022 (c) ubuntu 24.04 6月頃の少し古い環境です OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024 アップデートをしました。 OpenSSH_9.6p1 Ubuntu-3ubuntu13.3, OpenSSL 3.0.13 30 Jan 2024 3.所見 OpenSSHは利用されている範囲が広く、使われているOS環境も異なります。修正情報を提供する側も大変ですが、適用する側も間違えないように適用するのは大変です。 4.追加 本件に関連して調べたことや試したことを参考として追記します。 (1) openSSHで脆弱性の大きな問題が発生をWindows11のwslで確認 Windows11のWSL上のopenSSH脆弱性対応が気になったので試してみました。 まず、Windows updat...

jenkinsをdocker環境で起動

記事の更新日:2026/09/30 評価を加筆 1.概要 CI/CDを支えるツールで日本製品といえばjenkinsです。jenkinsの環境構築は様々なインターフェイスを準備するために手間が必要で面倒でした。しかし、jenkinsをdocker環境で起動すると手間は大幅に改善されます。物理環境や仮想環境に導入して保守をするよりもDocker環境を構築して運用する方が楽になると考えます。その内容を記述します。 私の評価は以下の通りです。 (1) 処理の自動化は作業効率を向上します、Jenkinsは効率化ツールです (2) Dockerのコンテナを利用することで導入を手間を削減できます (3) まず、評価利用することです、改善の第一歩です (4) 開発者全員がメリットあると感じることが重要です 2.詳細 参考資料に従って、jenkins/jenkins:ltsを利用します。jenkinsにもubuntuの用にLTS(Long-Term Support:長期サポート版)がありました。2年間は利用できるので良い選択肢です。 Docker Compose with Jenkinsにdocker-compose.ymlが記述されています。 今回は必要最低限の構成で導入します。 (a) docker-compose.yml version "3" services:   jenkins:     image: jenkins/jenkins:lts     ports:       - "8080:8080" (b) 起動 $ docker-compose up -d で起動します。 (c) ブラウザから接続 Firefoxにて、http://localhost:8080 で接続します。 Unlock Jenkinsが表示され、Administrator passwordを要求されます。 docker-compose logs とterminalで入力をして、 Please use the followin password to proceed to installationの下に記述されている文字列をコピー&ペーストでFirefoxの入力エリアに入力します Customaize Jenkinsでは、...

Ubuntu/LinuxMintのKVM環境にWindows11をローカルアカウントでインストールする方法

記事の更新日:2026/09/30 評価を加筆 1.概要 Windows11をローカルアカウントでインストールする方法をKVM環境で試してみました。Windows11はライセンス認証なしでも短期間の評価利用ならばインストール可能です。実機確認や簡単な評価には良い方法だと思ったので、この内容を記述します。 私の評価は以下の通りです。 (1) Windowsは有償製品のため試験をするには様々な制限があります (2) 試験をするための評価用の環境構築は90日間の評価期間が設定されています (3) Windows11の導入にはマイクロソフトアカウントが必要です (4) 評価用にローカルアカウントでインストールする方法を試してみました 注意事項 Windowsの利用にあたっては、Microsoftが定める使用許諾契約(EULA)を遵守する必要があります。ライセンス違反(不正なプロダクトキーの利用、規約外の商用利用など)は違法行為となるため、必ず正規のライセンスを取得・確認した上で操作を行ってください。 2.詳細 (a) Windows11のISOファイル入手 Windows11のISOファイルは、Microsoftサイトから入手しました (b) 仮想環境(KVM) Ubuntu/LinuxMintにKVM環境を導入しました。 (c) 仮想TPMとUEFI Windows11のインストール条件をクリアするために導入します。 $ sudo add-apt-repository ppa:stefanberger/swtpm-focal $ sudo apt-get update $ sudo apt-get install swtpm swtpm-tools (d) Windows11仮想マシンについて Memory=8192MB, CPU=2, Disk=80GBに設定しました また、参考資料に沿って、BIOSとTMPを設定後、Boot OptionをCD-bootにします (e) Windows11インストール ライセンスキーはなしで、特に問題なく実行できます。 (f) Windows11の設定 参考資料に沿って、「ネットワークに接続しましょう」で、Shift+F10でコマンドプロンプトを表示 cd oobe BypassNRO.cmd 再起動になり、Windowsの設定を最初...

Ubuntu/LinuxMintをmicroSDに導入する方法

記事の更新日:2026/09/30 評価を加筆 1.概要 ubuntuのresucue用途としてusb boot形式のubuntu liveCD, systemrescue, boot-repairなどを利用していますが、通常利用している環境のubuntuを利用したresucue用のboot usbが欲しいと思っていました。microSDをusbに変換するアダプターを購入したので、64GBのmicroSDにubuntu環境を構築しました。この方法はLinuxMintでも利用できます。その内容を記述します。 microSDからBootするにはBIOSを利用します。LegacyBIOSの場合は問題ありませんが、uefiBIOSの場合でWindows11が導入済みであり、かつ、secure bootをOnになっているとmicroSDからBootできません。secure bootがOnになるとWindows専用機になってしまいます。 私の評価は以下の通りです。 (1) 緊急時の起動用USBを作成するためにmicroSDを利用しました (2) USBメモリと比較して、容量を確保できるので普段利用環境を構築できます (3) USBに変換するアダプターを利用します (4) 性能面では問題ありません、SSDには及びませんが、十分な性能が出ます 2.詳細 (a) microSDの初期化 usb変換アダプターにmicroSDを取り付けます。usb bootのubuntu liveCD(20.04.6 desktop)を利用して、起動をしてからgpartedでmicroSDのpartion tableをmsdos形式で初期化します。更に、microSDの64GB領域全てをext4で初期化します。 (b) ubuntu-20.04.6 install usb bootのubuntu liveCD(20.04.6 desktop)からinstallerを起動して、microSDのext領域(私の場合は/dev/sdd1)にinstallします。bootは/dev/sddを選択します。問題なくインストールできました。 (c) 起動 non-uefi BIOSでusb boot可能なPC(私の場合は古いNotePCを利用)にusb変換アダプターにmicroSDを取り付けて、BIOSの設定をUSB...

Ubuntu環境でバックアップをリストア後、keyringの認証が発生

記事の更新日:2026/09/30 評価を加筆 1.概要 以前のOSバックアップをリストアして、ログインキーリングの認証が発生しました。ubuntuをBackupからリカバリ後、keyringに登録したID/Passwordを利用すると下記ポップアップメッセージが表示され、認証パスワード入力を求められます。この対処に関して記載します。 表示されたメッセージは下記内容でした。 認証が必要です コンピューターへのログインに使用するパスワードがもはやログインキーリングのパスワードと一致しなくなっています 最初にメッセージを見た時、何が起きたのかわかりませんでした。まず、再実行をして再現性のある事象であるか否かを確認することから始めました。 私の評価は以下の通りです。 (1) バックアップにはkeyringの設定情報が含まれています (2) バックアップをリストア後、Userのパスワードを変更するとkeyringと不整合が起きます (3) keyringを利用するものにmail-clientがあります (4) 設定にあるパスワードと鍵からロックを解除する方法で対処します 2.詳細 発生原因は良くわかりません。今までに発生した経験がなく、何か変わったと思います。 下記3つの要因が関係しているようです。 (a) Ubuntuをバックアップからリストア (b) Ubuntuのuserのパスワードを変更(root user) (c) keyringを利用するプログラム(mail-client)を導入後、データをバックアップからリストア この問題に遭遇した時、少し動揺して、まず、バックアップからリストアを再実行しました。何かリストアで問題が起きたのではないかと考えたからです。再度、リストアを実行して結果が同じになることが判明してから何かが起きていると認識をして調査を始めました。 パスワード変更が鍵かもしれないと思って、変更することを中止して作業をすると問題が発生することはありません。ここで初めてuser情報に関する何かの問題であると考えました。トラブルが発生すると、原因を追求するために再実行を何度も実施します。時間が取られてしまい予定した作業をすべて後回しにせざるを得なくなってしまいます。 原因が判明して改善策がわかると、結果を残して備忘録を作成します。記録を残すことをしないと同じ問...

boot-repairによるubuntuのboot loader復旧

記事の更新日:2026/09/30 評価を加筆 1.概要 マルチブート環境を操作しているとトラブルに遭遇することも多くなります。特に、BIOSとuefiBIOSで差異があるためbootできない問題が発生すると、まず、問題改善のためにboot-repairを利用します。bootできない問題への対処は再導入が最終手段ですが、その前に必ずboot-repairを試します。 マルチブート環境でない場合でもLegacyBIOSの場合と異なり、ueifBISOの場合はストレージに存在するboot定義ファイルを何らかのプログラムが変更してしまうとアクティブな領域が変わり、ブートできなくなる場合があります。こんな場合もboot-repairを利用します。 私の評価は以下の通りです。 (1) Regacy BIOSとuefi BIOSではブート方式が異なります (2) 異なるブート方式設定ではOSをブートすることができません (3) 手作業で復旧することは非常に難しく、簡単ではありません (4) 再導入や再リストアをする前に、boot-repairによる復旧を試すのがおすすめです 2.詳細 boot-repairの起動方法は2つの手段があります(参考資料参照) (1) 1つ目の選択肢:ブート修復機能を含むディスクを入手する(ネット接続なし) Boot-Repairを最も簡単に使用する方法は、 Boot-Repair-Disk(Boot-Repairを自動的に起動するディスク)のライブUSBディスクを作成し、それを使って起動することです。 (2) 2つ目の選択肢:UbuntuにBoot-Repairをインストールする(ネット接続あり) Ubuntuライブセッションから起動して、インターネットに接続後、コマンドでインストールする。 boot-repairは普段利用するツールではないので、2つ目の選択肢を利用していました。 実行するコマンドは2つです。 $ sudo add-apt-repository ppa:yannubuntu/boot-repair && sudo apt update $ sudo apt install -y boot-repair && boot-repair 起動後、recommended repairを選択...