PC設定覚書と雑記

電源投入
 ↓
BIOSによるデバイス初期化
 ↓
ブートデバイスの決定
 ↓
ブートストラップローダのロード
 ↓
ブートローダの実行
 ↓
OSの起動

 

 

 

PCの電源を投入すると、マザーボードのROM中のBIOSが起動。

このBIOSの初期化プログラムが、PCに接続されている各種デバイスの初期化を行う。

この過程が POST(Power On Self Test)。(起動直後に画面表示されている)

各種デバイスの初期化が終了すると、BIOSは次の段階に入り、起動するためのドライブを探す。

起動ドライブとなるのは、HDD、 CD-ROM、USBフラッシュメモリなど。

BIOSは起動ドライブを見つけるとそのデバイスをファーストブートドライブとして起動を試みる。

HDDの起動を例にすると、

BIOSはそのブートドライブの先頭セクタのロードという段階に移る。

HDDの先頭セクタは MBR(Master Boot Record)といい、MBRは1台のHDDに1つだけ。

BIOSはこのMBRをメモリ上にロードし、MBR領域にあるプログラムに制御を移す。

このMBR領域にあるプログラムを、ブートストラップローダと呼ぶ。

ブートストラップローダは、パーティションテーブルから起動フラグのあるパーティションを探す。

パーティションテーブルとは、複数のパーティションに関する情報が保存されているMBR内の1つの領域。

この起動フラグのあるパーティションにブートストラップローダから制御が移行。

このとき、ブートストラップローダから呼び出されるのが各基本パーティションにあるブートセクタ。

ブートセクタは各基本パーティションの先頭セクタのことを指し、PBR(Partition Boot Record)と呼ばれる。

PBRに制御が移行すると、そのPBRのプログラムが動作することになる。

このPBRにあるプログラムコードが IPL(Initial Program Loader)で、OSを起動させるためのブートローダの残りの機能を呼び出す機能を持つ。

MBRやPBRは512バイトと非常に小さな領域しかなく、その中のIPLのデータサイズはさらに小さい。

この小さなデータサイズにOSを起動させるためのブートローダのプログラムを全て格納できない。

そのため、IPLはブートローダの一部のプログラムコードを持ち、ブートローダの残りに機能はPBRの後続セクタに置いている。

IPLから呼び出されたブートローダが後続のOSのファイルを読み込んでいき、最終的にOSが起動する。

 普段PCやスマホで扱っているデータが壊れてしまう事はめったにないので、普段は安心しちゃっています。

ですが、やはりトラブルは突然起こるものです。

システムデータが壊れた場合は、PCが起動しなかったり、Webサイトが失われてしまったり(!)という、深刻な事態になってしまいます!!

そこで、改めてデータファイルの保管、システムの保護等について考え直してみることにしました。

 

 自分は、今までの様々なデータをLinuxSambaを使った自作NASに保管していました。

そして、さらにこのデータをWindowsクライアントPCのセカンダリディスクに定期的にバックアップしていました。

このバックアップディスクはWebサーバーで連続稼働させていたお下がりで、いつ壊れてもおかしくないヤツなんですが、バックアップ用なので「まあいいか」と使い続けています。

そしてNASもRAID1で動かしていたので安心し切っていたんです。

 

 トラブルが起こったのは一昨年末でした。

家庭内LANの第3オクテットを変更しようと作業した際、NAS内部のDebian設定でつまずいてしまいDebianが起動しなくなってしまいました。

この時、ソフトウェアRAIDで組んでいたシステムであったのに、RAIDシステムの復旧もHDD内のデータ救出も出来ませんでした・・・!

RAIDの再構築も、セカンダリディスク(呼び方合ってる?)からのシステム立ち上げも出来なかったんです。

これらの方法の練習もやってなかったし、習得もしてなかったんですね・・・

こんな状況ではイザという時に対応なんか出来ませんね!

 

 そこで、再度ソフトウェアRAIDを構築する前に、曖昧だった次の知識についてまず調べることにしました。

 ①MBR

 ②ESP

 ③UEFI

 ④GPT

 ⑤ブートストラップローダー

 ⑥grub

 ⑦/boot

次に、実際に実験機でソフトウェアRAID機を構築して、故意にトラブルを起こしてみることにします。

そして、このトラブルに対処する手順を実習して習得しておこうと考えました。

 ①実験的に片側のディスク(grubがインストールされていないセカンダリディスク)を外して挙動を調べてみる。

 ② ①のあとに新しいセカンダリディスクを取り付けてRAIDを再構築し、RAIDシステムを復旧させてみる。

これが出来るようになったら、

 ①grubがインストールされていないセカンダリディスクに、grubを手動インストールしてセカンダリディスク単独でも起動できるようにしてみる。

 ②grubがインストールされているプライマリディスクを外して挙動を調べてみる。

 ③ ②のあとに新しいプライマリディスクを取り付けてRAIDを再構築し、RAIDシステムを復旧させてみる。

 

 次年度に備えて、今日からこれらの作業に取りかかっていますが、かなり時間がかかりそうです・・・

後日、ここに備忘録を残しておこうと思っています。

 iPhone、iPadのiOSですが、現在ver14.01です。

やはり職場でも、アプリが動かなくなったとか、ログインできなくなった、という話が良く聞こえてきます。

動かなくなったアプリの中に自分も使っているものがありました。

でも、自分にとって使う頻度の少ないアプリだったので今は困っていません。

OSのアップデートでは、セキュリティ面で後退することはなく必ず改善されているはずだと思っているので、それ以外の不具合が出る可能性があっても、自分はすぐにアップデートしてしまいます。

万一セキュリティ上の不具合が見つかった場合ですが、すぐに次のアップデートが公表されます。

アプリ等の不具合は、少し時間がかかっても解消されるはずです。

ということで、クライアントのWindows、サーバーのDebianも直ぐにアップデートしてしまっています。

iPhone、iPad用OSの最新版「iOS14」が配信されることが明らかになりました。

日本では18日未明からダウンロードできるようになるとのことですが、不具合の可能性もあり、更新にはデータのバックアップなどの注意が必要なようです。

インストール済みで現在使っているすべてのアプリがiOS14に対応しているとは限らないのです。

対応完了まで更新は慎重に判断して欲しいとアナウンスされていますので注意して下さい!

すぐに更新せず、ちょっとの間様子を見た方がいいでしょう。

NetCommons3.3.2.patch1適用 2020-09-16 [okamoto]

 9/12に NetCommons3.3.2.patch1 がリリースされていましたが、

「これは重大なセキュリティバグの修正パッチ」とアナウンスされていたので、すぐにこのパッチを当てる作業を行いました。

クライアントPCにいったんダウンロードしたこのパッチファイルをサーバーにアップして解凍し、これを NetCommons3.3.2 インストールディレクトリに上書きするだけです。

よって、サイトは一時停止せず通常動作のまま作業しました。

ただ、自分は root ユーザーとして作業したため、最後にインストールディレクトリ以下の所有者を「Webサーバー」に再度変更しておく作業を付け加えました。

 サーバーメンテナンス作業は正常に終了しました!

サイトも正常動作に戻っています。

 9/6(日)19:00~19:30の予定で

サーバーメンテのためサイトを一時停止します。

Netcommonsのアップデート作業を行います。

作業が終わりましたら、終了の連絡と共にサイトを通常動作に戻します。

よろしくお願いいたします。

 このサイトからファイルをダウンロードするとファイル名が文字化けしていましたが、システム開発エンジニアの方のアドバイスにより修正作業を行いました。

作業の結果、この件は正常に修正されました。

 また、サイト内検索ボックスにキーワードが思ったように入力できない件ですが、まだ修正されていません。(特にスマホからの検索)

そこで、

まず何も入力せずに検索ボタンをクリック(タップ)して下さい。

すると別の検索ボックスが現れますが、この検索ボックスにはキーワードが自由に入力できるはずです。

システム本体が修正されるまで、この手でしのいで下さい。

 

以上です

 職場で、授業や補講などでプレゼン風に文書、画像、動画、音声、スライド、アニメーション、etc を見せるためには PC が必要になります。

ここで、通常の授業の流れを滞らせることのない「素早い操作と素早い表示を即座にさせる」ことが重要なポイントだと自分は思っています。

すると、通常のマウスの操作よりタッチパネルの操作の方が圧倒的に早いんです。

例えば、マウスでのクリックが連続するような場面では、タッチパネルでのタップの方が素早く出来ることは想像できると思います。

ショップなどでビジネスマンがタブレットを素早く操作しているのを見たり、自分で実際に操作してみればはっきりと実感出来るでしょう。

PC 付近にいる時は、タッチパネルをタップ、スワイプして操作し、PC から離れる時はエアマウスを使えばいいのではないかと思っています。(エアマウスはどの機種にするか考えている最中なんですが)

次に無線 LAN(Wifi) 環境のない所でもインターネット接続をさせるには、スマホと同様にモバイル接続できる PC が必要になります。

これはこの分野のパイオニアである iPad が最適だろうと思っていたのですが、WindowsPC との差を埋めるように使うことが自分にはどうしても出来ませんでした。

そこで、Windows の2in1タブレット PC に目をつけてずっと探していました。

余計な機能を付けない実質機能優先の Dell 社の13インチモデルならコロナ給付金で買える価格でした!

本当に武骨なデザインとカラーなんですが、性能的に信頼できるモデルです!

さて、モバイル接続させるには PC に LTE ユニットが内蔵されていることが必要なんですが、これは該当機種を選べばいいだけです。

最後にすごく大変だったのが SIM カードの購入でした!

「ユーザーが SIM カードを購入して PC に取り付ける」というのは、まだ一般的ではないようでした。

自分は現在 Softbank のモバイル回線を使っているので、数か所の Softbank 代理店に電話をかけて相談したんですが、どの店舗に聞いても即答がなく、扱いたくないような雰囲気でした。

自社で取り扱っているスマホやタブレットの販売がほとんどでしょうから、無理もないと思います。

昔と違って今は、ユーザー側で経験のある店舗、スタッフを選ばないとダメなんですね。

昨日やっと対応してくれそうな店舗を見つけました。

でも、自分が買ったタブレット PC のマニュアルにも、「MicroSIM」カードスロットの場所が示してあるくらいで、その他の解説は載ってなかったので対応してくれるのか不安でした。

予約時間に店舗に行ってみると、やはり店舗では経験のない機種で動作保証が出来ないと繰り返し念を押されました。(該当機種に動作実績がない)

ちなみに SIM カードには、ユーザー情報の他に、使用するPCのIMEI番号等が書き込まれてユーザーに渡されます。

このカードがセットされることで、その PC に限ってモバイル通信が出来るようになる訳ですね。

ですから、SIM カードの登録に問題がなく、電波の状況がいいのにモバイル接続が上手く出来ないといった場合は、LTE ユニットの性能が良くないといったハードウェア的な問題の方だろうと考えられます。

そう思っていたので、まあ大丈夫だろうと思っていました。

他の店舗では、2店とも「MicroSIM カードは取り扱っていない」という対応だったんですが、Web で調べてみるとどの店舗でも「マルチ USIM カード」を取り扱っているようで、このカードには切り込みが入れてあり、標準、Micro、Nano、と3つのサイズに切り取れるように作ってあるんですね!

でも、店員さんもこのことを知らない人もいるようでした。

下の写真ですが、上が PC に付属していた「eSIM」と呼ばれる SIM カード、下が購入した Softbank のマルチ SIM カードの残った部分です。

詳しくは分からないんですが、この eSIM は、店舗に出向かずにオンラインで登録できるタイプで、今後使われるタイプになってくるのではないかと書いてありました。(現状で Softbank では対応していないようでした)

さて、このマルチ SIM カードを自分のタブレット PC のスロットに差し込むんですが、下の写真のヘッドフォン端子の左側がスロットです。

今回は、モバイル接続してインターネットに繋がるか、特にドキドキしましたが・・・

大丈夫でした!!

これで、職場でもこのマシンはしっかり仕事してくれるでしょう!

Lets Encrypt 設定 2020-06-03 [okamoto]

Debian10版

 ① /etc/apt/sources.list に以下を追記

   deb http://mirrors.digitalocean.com/debian buster-backports main
   deb-src http://mirrors.digitalocean.com/debian buster-backports main

      # apt update

 ② # apt install python-certbot-apache -t buster-backports

 ③ /etc/apache2/sites-available/ に、site1.conf、site2.conf、・・・を作成しておく。

  site〇.conf 中にはsite のFQDNを書いておく。

 ④ # apache2ctl configtest で構文エラーを教えてくれるので、必要なら .conf ファイルを修正していく。(Syntax OK が出れば完了)

 ⑤ apache の ssl モジュール有効化。

 ⑥ # a2ensite site1.conf # a2ensite site2.conf ・・・ 

 ⑦ # systemctl reload apache2

 ⑧ ファイヤウォールでポート443を開ける。# ufw allow 'WWW Full' でOK。

 ⑨ # certbot --apache

  あとは、対話式に質問に答えていけば良い。複数サイトがある時はサイトを指定せず空「Enter」ですべてのサイトの設定を自動で済ませてくれる! Redirectさせるかどうかまで聞いてくれる!

  90日で失効する証明書の更新は、 # certbot renew コマンド実行で更新される。cron で自動実行させるよう設定しておけば良い!