ホームサーバー ～libcryptの古いバージョンへの依存～

ホームサーバーで、運用しているWordPressブログサイト、MataKitena BlogがFedora30へのアップグレードで、またまた起動できなくなったトラブル対応の続きです。今回も、またWebサーバーのapacheを起動させてみたら...何やらライブラリに存在しないものがあると、エラーメッセージを出力して異常終了していました。その解決策をここに残しておきます。

WordPressブログが起動できない原因は

今回も、WordPressブログがどうして起動できないのか調べて分かったことは、データベースであるMySQLは起動出来ているということ。そして、Webサーバーのapacheを起動させてみたら...何やらライブラリに存在しないものがあると、エラーメッセージを出力して異常終了しているようです。これで、原因がはっきりしました。libcrypt.so.1が存在しないので、Webサーバーが異常終了してしまいWordPressブログが起動出来ないのです。

出力されたエラーメッセージの一部
...error while loading shared libraries:libcrypt.so.1: cannot open shared object file: No such file or directory...

対応方法は...

今回の原因は、今使っているミドルウェアなどの中に、libcryptの古いバージョンに依存しているものが存在するためです。Fedora30には、このライブラリの更新されたバージョンが含まれていますが、とりあえずlibcryptの古いバージョンに依存したミドルウェアなどを実行させるために、パッケージをダウングレードさせることも可能ですが、他のミドルウェアなども不安定になってしまう可能性があるので、libcryptx-compatと呼ばれるパッケージをインストールすることにしました。

libcryptx-compatのインストール方法
sudo dnf install libxcrypt-compat 

ホームサーバー 〜Fedora30 grubブートメニューが表示されない〜

Fedora29からFedora30へのアップグレード時、grubブートメニューが表示されずOSが起動出来なくなった件について対応が完了しましたので、記事に対処方法をまとめておきたいと思います。Fedora29へのアップグレード以降、トラブルが続いているホームサーバー、今回のアップグレードでも、またトラブルが発生しました。

トラブルの概要

Fedora29のアップデート完了後、Fedora30へのアップグレードを開始...ダウンロードが完了し、再起動後にインストールが始まるというメッセージを確認して、直ぐに再起動を実施しました。いつものgrubブートメニューが表示されて、アップグレードが完了と思っていたのですが。こんなメッセージと共に、grubプロンプトというものが表示されました。

    Minimal BASH-like line editing is supported. For the first word,
    TAB lists possible command completions. Anywhere else TAB lists
    possible device or file completions. ESC at any time exits.

grub>

この場合は、grubブートメニューを表示するためのGRUB2は正常に起動している状態で、モジュール や/ boot/grub/ディレクトリに格納されている他のモジュールをロードしたが、grub.cfgファイルが見つからなかったことを意味するそうです。他にも、grub rescueプロンプトというものを表示する場合もあるそうです。こちらの場合には、normal.mod が見つからなかったことを意味するそうで、どちらの場合も、ブートに関連するファイルが存在しないことを意味します。
参考までに、トラブル発生時、キーボードの認識がJISキーボードでなく、USキーボードになっていて思ったように文字入力ができない事象も発生していました。同じ事象の場合には、USキーボードの配列を参照しながら文字入力することで対処できます。

どんな対処方法があるの

大きくは、3通りほど存在するようです。1つは、OSのLiveDVDやLiveUSBから起動して環境を修復する方法。もう1つは、grubコマンドを使用して、応急処置を施しOSを起動。その後、恒久的な対処を実施する方法。そして最終手段、GRUB2のレスキューディスク（いくつか種類がありました。）を使って環境を修復する方法。今回は、この3通りのうち、grubコマンドを使用して、応急処置を施しOSを起動。その後、恒久対処を実施する方法でしか対処することができませんでしたので、こちらの方法を記事にしています。

他の2つの方法で対処することができなかったのは、USBブートがサポートされていない古いパソコンで、DVDRAMを搭載しているにも関わらず、CDは認識できるがDVDを認識できないという特殊な環境であるからです。

実際の対処は

インターネットで、たくさんの情報を参考にしましたがGRUBのバージョン、利用している環境（ディスク構成やUEFI、複数OSのマルチブートなど）で実行コマンドやパラメータを変える必要がありますので、本記事を参考にすることはできると思いますが、注意しながら、自分自身で判断して対処を実施して下さい。

まずは、lsコマンドでドライブの構成やパーティションなどを確認します。

最初は、ドライブの構成からです。

grub> ls
(hd0) (hd0,msdos2) (hd0,msdos1)

参考

hd0,1:sda1 hd1,0:sdb1
hd0,2:sda2 hd1,1:sdb2

gpt:Globally Unique Identifiers Partition Table
msdos:MS-DOS Master Boot Record

次に、パーティションの構成です。

最後にスラッシュをつけるのを忘れないように...

/bootパーティション。本来のgrub.cfgファイルの格納ディレクトリgrubとかgrub2を含んだパーティションを探します。

grub> ls (hd0,1)/
... grub2 ...

searchコマンドで検索する方法もあります。

バックアップを作成してりすると複数見つかる場合もあります...

grub> search --file /grub2/grub.cfg
hd0,msdos1

見つかりましたので、rootを設定します。

set root=(hd0,msdos1)

grub.cfgファイルを読み込みます。

自分で作成しておいたバックアップファイルを読み込ませたい場合には、バックアップファイルを指定することもできます。

configfile /grub2/grub.cfg

ドライブ上のGRUBからメニューが表示され、起動するOSを選択することで起動することができました...慌てないでください。まだ、恒久対処を実施していません。
恒久対処として、GRUBの修復を行います。
grub-installコマンドで指定するのは、パーティションでなく、ドライブのブートセクタなので注意してください。再起動したら、恒久対処の完了です。

# sudo update-grub
Generating grub configuration file ...
　～
done
# grub-install /dev/sda
Installing for i386-pc platform...
　～
Installation finished. No error reported.

ホームサーバー 〜Fedora29 アップデート失敗⁈〜

つい先日、アップグレード失敗対応が終わったばかりのホームサーバーにOSのアップデートがありました。ちょっと不安な気持ちになりながらも、今ならシステムもデータベースもWordPressもバックアップがそのまま使える...ということで、思い切ってOSのアップデートを実施しましたが...

嫌な予感的中

OSのセキュリティ・アップデートやブラウザなどのアップデートなど、全部をまとめてアップデート...再起動..............................また、起動できない...エラーメッセージが表示されました。なんじゃこりゃあ。(* ´艸｀)ｸｽｸｽ　笑ってる場合じゃないんだけど。

よく見てみると、journalctlってタイプしてsystem logを見ろといってるみたいなので、コマンドを入力するとシステムログが表示されます。

エラーメッセージ
Generating “/run/initramfs/rdsosreport.txt”

Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot after mounting them and attach it to a bug report.

システムログの確認

表示されるシステムログは、問題のある箇所が赤字で表示されますので、注意しながら見ていると直ぐに問題箇所を見つけることができます。ファイルシステムが壊れていて正常に認識できていないみたいです。

問題箇所
fsck failed .........
　～中略～
Failed to start file System Check on ファイルシステム

ファイルシステムの修復

ファイルシステムのチェックと修復を行うfsckというコマンドを使って、ファイルシステムの修復を試みます。オプションには、障害発生時に修正する場合に利用が推奨されている。-fオプション（ファイルシステムがクリーンな場合でも全てのチェックを行う。）を指定します。コマンド実施後、何度か確認を求められるので、何度もyを入力するのが面倒な方は、修正箇所が見つかった場合に実行者に確認せずに修正を行う。-yオプションも併せて指定すると良いと思います。ファイルシステムの部分には修復するファイルシステム...つまり、システムログの確認で問題箇所として特定したファイルシステムを指定システムを指定してコマンドを実行。修復が完了したら、再起動して作業が完了です。

ファイルシステムの修復
fsck -fy ファイルシステム

今回は、この方法でリカバリーできましたが、必ずリカバリーできるものではないので、自分で運用、保守をしている方は、定期的にバックアップを取ったり、システムに変更を加えた時にバックアップを取ったりして、いざという時に備えるようにして下さいね。

ホームサーバー 〜WordPressブログ バックアップ／リストア〜

以前、レンタルサーバーのCPU使用制限超過でリダイレクトされてしまった時には、WebサーバーもWordPressブログも起動出来ていたので、phpAdminでWordPressデータベース全てのバックアップを取りましたが、今回はWebサーバーもWordPressブログもPHPも動いていない状況です。そして、ホームサーバーなのでFTPは使わずに直接外付けディスクを接続してWordPressブログのWebページをバックアップできます。

データベースバックアップ／リストア

最初にデータベースのバックアップを取ります。ホームサーバーなので外付けディスクを直接接続して、転送容量を気にせずにバックアップを取ることができるので、念のため全データベースのバックアップを取ることにします。何度も調べなくて良いように、特定のデータベースをバックアップ／リストアするコマンドも残しておくことにします。

MySQLデータベースバックアップ
特定のデータベースのみバックアップする場合
mysqldump --single-transaction -u ユーザー名 -p DB名 > 出力ファイル名

全データベースをバックアップする場合
mysqldump --single-transaction -u ユーザー名 -p -x --all-databases > 出力ファイル名

MySQLデータベースリストア
特定のデータベースのみリストアする場合
mysqldump -u ユーザー名 -p DB名 < バックアップファイル名

全データベースをリストアする場合
mysqldump -u ユーザー名 -p < バックアップファイル名

 WordPressブログバックアップ／リストア

次にWordPressブログのバックアップです。こちらも、転送容量を気にせずにバックアップを取ることができるので、念のため全データのバックアップを取ることにします。あちこち見ないで良いように、最低限のデータをバックアップ／リストアする方法も残しておくことにします。リストアは、各ディレクトリにバックアップしたデータを上書きすれば良いのですが。

WordPressブログバックアップ
最低限のデータのみバックアップする場合
1.~/wp-config.php
2.~/wp-content/plugin/　  ⇒　プラグイン格納
3.~/wp-content/themes/　⇒　テーマ格納
4.~/wp-content/uploads/　⇒　アップロードデータ格納

全データをバックアップする場合
WordPressのインストールディレクトリ配下の全データ

データベースのリストアでなく、WordPressのエクスポート機能で出力したXMLファイルをインポート機能でリストアする場合は、以前、使用していたテーマ、プラグインを有効にし、以前と同じパーマリンク設定をしてから、XMLファイルをインポート機能でリストアして下さい。正しく記事が復元されないのでくれぐれも注意して下さい。

使用していたテーマ、プラグイン、以前と同じパーマリンク設定が思い出せなくても手間は掛かりますが、最後の手段が有ります。MySQLのバックアップデータやWordPressのエクスポート機能で出力したXMLファイルは、テキストエディターで開くと記事の内容を読み取ることが出来るので、コピー＆ペーストなどで復元することが可能です。

ただし、データベースのバックアップには、記事の履歴（修正の度に保存される各リビジョンのデータ）も含まれていますので、最新の情報を見るようする必要があります。

ホームサーバー 〜WordPressブログ トラブル復旧〜

ホームサーバーで、運用しているWordPressブログサイト、MataKitena BlogがOSのアップグレード失敗で起動できなくなったトラブル対応の続きです。今回は、Webサーバーのapacheが起動出来て、無事にWordPressブログが起動出来たので、原因と対応方法を記事に残しておきます。データベースのバックアップとリストアについては次回記事にしますね。

WordPressブログが起動できない原因は

WordPressブログがどうして起動できないのか調べて分かったことは、データベースであるMySQLは起動出来ているということ。そして、Webサーバーのapacheを起動させてみたら...何やらPHPのライブラリに存在しないものがあると、エラーメッセージを出力して異常終了しているようです。これで、原因がはっきりしました。libnsl.so.1が存在しないので、Webサーバーが異常終了してしまいWordPressブログが起動出来ないのです。後は、インターネットで情報を探して対応すれば起動できそうです。

出力されたエラーメッセージの一部
...Cannot load modules/libphp7.so into server: libnsl.so.1: cannot open shared object file: No such file or directory...

そして、対応方法を探しに...

こういうことを調べている時に多いのですが、エラーメッセージをコピー&ペーストして検索すると英語のページがたくさん見つかるんです。英語が苦手な方は挫折しそうになっても、もうちょっと頑張って下さい。ここで、Google翻訳の出番です。検索結果のページを丸ごとか、部分的に翻訳すればほとんど日本語になった文書に翻訳されます。下記が、検索結果の中で1番解り易そうなページの要約です。なるほど...

発見した情報
Fedora 28以降で、msendユーティリティを使用しようすると、libnsl.so.1がnot foundと表示されるとのこと。

その原因は
Ferdoa 28以降、libnslパッケージはデフォルトでは含まれなくなり、libnsl2のみになったとのこと。

その対応方法は
後方互換性があるはずなのでlibnsl2ライブラリをlibnslにソフトリンクをしてみるか、libnslをインストールすればいいとのこと。 

ということは...利用しているOSが32bit、64bitのどちらかによって下記のコマンドでインストールできます。MataKitena Blogは、32bitなので、”dnf install libnsl”を実行してコマンドからWebサーバーのapatchを起動...起動完了です。念のため、システム起動時に自動起動されるかも確認しましたが、問題なく起動できました。

libnslのインストール方法
32bit OSの場合：dnf install libnsl
64bit OSの場合：dnf install libnsl.i686

ホームサーバー 〜WordPressブログ システムバックアップ〜

ホームサーバーで、運用していたWordPressブログサイト、MataKitena BlogがOSのアップグレード失敗で起動できなくなったトラブル対応の続きです。システムバックアップとリストアについて記事を残しておきます。

システムバックアップとは

システムバックアップとは、いざという時のためにパーティションやハードドライブ全体のイメージをバックアップすることをいいます。本来は、今回のようにサーバー自体が起動できなくなる可能性があるOSのアップグレードなどの作業を実施する場合には、事前にシステムバックアップをしておけば、リストアすることで元に戻すことが出来るので安心できます。とはいえ、ハードドライブ自体が壊れてしまった場合、復元することは不可能なので壊れる前にバックアップすること。更に、同一システム内のハードドライブでは、不注意や予期しない事態で壊れることもありますので、外付けのハードドライブやクラウドにバックアップデータを保存するようにしましょう。

システムバックアップの方法は

ddコマンドを利用します。ddコマンドはdataset definitionの略で、ディスクに限らずデータをLowレベルで読み書きできるので、データの中身を無視して操作でき、OSが読み取れないファイルシステムでフォーマットされている場合にもバイナリーレベルで読み書きすることができます。 バックアップしたいドライブ以外から起動する必要があるので、Bootable USBやBootable DVDなどを作成しておきましょう。ddコマンドは、ifで指定した入力ファイルを指定されたブロックサイズで、必要に応じて変換をしながらofで指定した出力ファイルにコピーすることができます。OSのディストリビューションやバージョンにより異なる場合もありますので、利用するシステムのmanコマンドで調べたり、確認して下さい。

ddコマンド書式
dd [--help] [--version] [if=file] [of=file] [ibs=bytes] [obs=bytes] [bs=bytes] [cbs=bytes] [skip=blocks] [seek=blocks] [count=blocks] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}]

今回はどうしたの

今回、ディスクユーティリティで起動ディスクを調べてみると.../dev/sda1と/dev/sda2の2パーティションが存在しました。準備しておいたBootable CDから起動して、それに合わせ、より大きな容量の外付けディスクに、より大きなサイズのパーティションを作成してシステムバックアップを実行しました。リストアは、if=で指定した入力ファイルとof=で指定した出力ファイルを入れ替えるだけです。まだ、WordPressブログが起動できていないですが、何か起こったとしても現在の状況までは戻すことが出来ます。

参考：今回実行したコマンド
dd if=/dev/sda1 of=/dev/sdb1 bs=64k conv=noerror,sync status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=64k conv=noerror,sync status=progress

あとは、データベースを含め、WordPressブログをバックアップして、本格的に復旧作業に備えます。

ホームサーバー 〜WordPressブログ トラブル対応〜

先日、MataKitena's Owndで記事にしたように、ホームサーバーで、運用していたWordPressブログサイト、MataKitena BlogがOSのアップグレード失敗で起動できなくなりました。これまで何度も、何事も無く無事にアップグレード出来ていたのですが、手抜きしてバックアップを取っていなかった今回に限って…(_ _。)シュン

ということでトラブル対応開始

キリッ(๑•̀д•́๑)ホームサーバーのトラブル対応を開始することにしました。ところが‼いろいろ対応し始めて、あッそうだった…と思い出すことがたくさん。まずは、現状のシステムバックアップを取るため、古いカーネルイメージを選択して起動されることを確認。そして、いつ無くなっても、おかしくないと思われる32Bit OSのLiveイメージをダウンロードしてBootable USBを作成しておこうと思いましたが。ホームサーバーは、何世代も前のノートパソコン。もしかするとBIOSが対応してないかも知れない。さっそく、インターネットでBIOS画面の表示方法を調べて、Boot Menuを見てみましたが。やっぱり、Boot Deviceとして表示されるのは、Optical Drive、Floppy Disk、Hard Disk、Network…USB機器には対応してませんでした。

まだまだ想定の範囲内

それじゃあ、MAC BookでBootable DVDを作って…でも、作成したBootable DVDから起動しません。他には、DVDドライブ付きのパソコンもない。ということで、古い雑誌の付録に付いていたDVDとCDを用意してホームサーバーの問題の切り分けです。DVD、CDどちらも認識されません。そういえばOSをインストールする時に、同じ様なことをした憶えが。あの時は、CDレンズクリーナーを使ってクリーニングしたはず。見つけたCDレンズクリーナーで2回程クリーニングすると、CDを認識しましたがDVDは認識しません。以前もそうでした。Fedora29 Workstationのネットワークインストールイメージが536MB。これならCDに入ります。取りあえず32BitOSのインストールCDを作成して、CD起動することを確認しました。

一気にクリアインストール？

MataKitena Blogの復活に向けて、一気にクリアインストールとも考えましたが。WordPressブログのバックアップすら作成してません。ここは、手を抜かないで、システムバックアップ、MataKitena Blogのバックアップも作成して、いざとなったら、海外ドラマで見たことのある「じゃあ、プランBで…」みたいな奥の手を作っておくことにします。ということで、いざという時を想定してどんなバックアップを取っておくかを検討するので、この記事は、ここまで。続きは、しばらくお待ち下さい。近日公開予定です。

XOOPS Cube ～ポータルコミュニティサイト構築CMS～

以前、お仕事で使ったことがあった、XOOPS Cubeについて調べてみました。XOOPS Cubeとは、ポータルコミュニティサイトを構築するために開発されたコンテンツ管理システムで、モジュールとテーマを組み合わせてWebサイトを構築できるシステムです。

動作環境 

OS：Linux、Windows
Webサーバー：Apatche
PHP：PHP5.2
データベース：MySQL 5.0以上　 

※XOOPS Cube Legacy 2.2の動作環境です。

モジュールでブログ、掲示板、Wikiなどの機能を追加、テーマでデザインを変更することができます。インストールするには、CMSの機能を実現するためのプログラムを取りまとめたパッケージというものを利用します。

インストールパッケージ 

公式パッケージ（XOOPS Cube Legacy 2.2／略称 XCL2.2）
XOOPS Cube のコアな部分をまとめ、ベーシックな機能を実現しているパッケージです。

サードパーティー製パッケージ（ディストリビューション）
公式パッケージには、ブログ等の機能を実現するためのモジュールが含まれないことから、有志により各種モジュールや機能を追加したサードパーティー製パッケージが各種リリースされているそうです。サードパーティー製のパッケージは、All in One パッケージとも言われ、別名ディストリビューションとも呼ばれているそうです。

現状では、各種モジュールのアップデート管理機能を持つ、X-updateモジュールなどを追加したXOOPS X（ten）が推奨ディストリビューションで、インストール後は、ブラウザ上で様々なモジュールの配置とインストール、アップデートやXOOPS Cube Legacy 本体のアップデートが可能で、サイト構築・運営ができるようになります。
XOOPS Cubeは、ポータルコミュニティサイトを構築するために開発されたコンテンツ管理システムで、モジュールとテーマを組み合わせて、Webサイトを構築・管理できるようになっていて、初心者にも分かり易いシステムでした。

Linux ～Linuxシステムの起動 Systemd～

Linuxのシステム起動について、従来から使ったわれてきたSystem V init（SysVinit)に変わって、Systemdが使われるようになってきています。SysVinitは、古くから使われているので、お仕事の現場などで遭遇することがまだ多いと想います。Systemdは、Linuxオペレーティングシステムのシステムサービスマネージャーで、SysVinitと後方互換するように設計され、起動時のシステムサービスの並行スタートアップやデーモンのオンデマンドのアクティベーション、システム状態のスナップショットのサポート、依存ベースのサービス管理論理などの多くの機能を提供するそうです。

Systemdの概要については、RedHatのCustomerPortalのRHEL7 におけるsystemdの概要という記事が、SysVinitとの機能比較やコマンドの使い方も記載されていて、解りやすいと想いますので、読んでみて下さい。SysVinitの起動手順や設定、ランレベルについては、Linux　～システムの起動／停止手順～も参考にして下さい。ここには、Systemdの起動手順や起動方法、自動起動の設定を記載しておきます。

Systemdの起動手順 

電源ON
    ⇩
BIOSがディスクのMBRという先頭ブロックのブートローダーをメモリ上に読み込みます。
    ⇩
ブートローダーがカーネル（vmlinuz）をメモリに読み込みます。
    ⇩
カーネルが起動し、ドライバなどがロードされて、Systemdプロセスを起動する。
    ⇩
default.targetというファイルに従って、どのターゲットを開始するかを決定し、システムサービスを開始します。

サービスの起動方法

systemctl start サービス名.service
終了　　　　　：stop
再起動　　　　：restart
状態表示　　　：status
設定再読み込み：reload

有効化されているユニットの一覧表示
systemctl list-units

インストールされているユニットファイルの一覧表示
systemctl list-unit-files 

サービスの自動起動設定

systemctl enable サービス名.service

自動起動解除
systemctl disable サービス名.service

設定確認
systemctl is-enabled サービス名.service

Linux ～システムの起動／停止手順～

システムの起動／停止シーケンスを理解することで、Linuxの仕組みや設定に対する理解も深めることができ、システムの運用保守にも役立つといわれています。それでは、さっそくLinuxの起動シーケンスです。

Linuxの起動シーケンス
電源ON
    ⇩
BIOSがディスクのMBRという先頭ブロックのブートローダーをメモリ上に読み込みます。
    ⇩
ブートローダーがカーネル（vmlinuz）とイニシャルRAMディスク（initrd）をメモリに読み込みます。
    ⇩
カーネルが初期化シーケンスを実行し、メモリに読み込まれているinitrdをマウントします。
    ⇩
カーネルがinitrdを使ってrootファイルシステムをマウントします。
    ⇩
カーネルがinitプロセスを生成し、起動時のカーネルオプション指定に従ってinit以外のプロセス（/bin/bashなど）を生成します。
    ⇩
initは起動されるとRun Control Script（/etc/rc.sysinit、/etc/rc）を実行し、/etc/inittabのシステムの各ランレベルの起動サービスの指定に従ってデーモンを起動します。

次に、起動シーケンスに出てきたランレベルです。ランレベルとは、Linuxの動作モードのことで、0から6の7種類あって、そのレベルに従って起動／停止されるサービスが異なります。各ランレベルの意味は、こんな感じになっています。

ランレベル
レベル
　0　　システム停止（シャットダウン）
　1　　シングルユーザーモード（rootのみ）
　2　　ネットワークなしのマルチユーザーモード
　3　　通常のマルチユーザーモード
　4　　未使用
　5　　グラフィカルログインによるマルチユーザーモード
　6　　システム再起動

 そして、起動／停止されるサービスのスクリプトは、/etc/rc.d/rcレベル.dに格納されています。また、頭文字がS（Start）は起動、K（Kill）は停止を表します。続く2桁の数値は実行の優先順位を表していて、数値の小さいものから順に実行されます。
サイト構築をする際には、自動起動するサービスを追加するために設定を行うのですが、設定方法が、これまでよく使われていた起動システムであるSysVinit系と新しい起動システムSystemdで違うので、また別の機会に記事にします。

システム管理者 ～システムの運用・保守～

自宅サーバーでWordPressブログサイトの運用を開始して、8ヶ月が過ぎました。OSやミドルウェアのパッチ、ログの確認などなど…そういえば、これって運用・保守ってこと。それって、システム管理者と呼ばれる人達が行っている作業ということ?…ということでシステム管理者について調べてみました。

システム管理者とは、情報システム及びそれらを構成するコンピュータシステムの管理者であり、システムアドミニストレータとも呼ばれる。情報システムやコンピュータシステムの利用者であり、日常的な運用・保守に関する作業を行い機能を維持する役割を担う。情報システムやコンピュータシステムの停止は事業の停止につながり、その責任は大きい。そして、その役割上、情報システムやコンピュータシステム全般に関する知識が求められるんです。

なるほど…日々、高いスキルが要求される作業を行って、機能を維持してくれる方々がいらっしゃるので、情報システムやコンピュータシステムがいつも通りに快適に使えているということなんですね。

たくさん失敗もして来ました、挫折しそうになったことも何度もありましたが、自宅サーバーでWordPressブログサイトの運用・保守を自分でやってみたから、気付いたこと、勉強になったことがたくさんあります。苦労したからこそ、身に付くことって本当にあるんだなと気付きました。

ということで、これからもMataKitenaのサイトを訪れて頂いている皆様に楽しんで頂けるように、これからも頑張りますので、よろしくお願いします。

MataKitenaのサイトに関わるシステムや機器などを運用・保守して頂いている皆様、いつもありがとうございます。そして、これからもよろしくお願いします。