サーバー運用とPC日記

新年度の準備のため、サーバーの OS と php のアップデートをやって、Netcommonsの引っ越しもやろうとしていました。

いきなりやるのは怖いので、Debian１０のテストサーバーを作り、そこに php７.４をインストールして、テストをさんざんやりましたが・・・

エラーの連続で上手くいかない！

エラーも何種類か出てきて、apache、mysql、Netcommons、それぞれのエラーログを見て対処できたものもありました。

しかし、丸１日かかって色んな方法を試した結果、上手くいったのはディレクトリ丸ごとコピーの方法だけでした・・・

もちろん、データベースは元のバックアップをdumpファイルで作って、これを新規データベースにインポートするんです。

php７.２環境で出来たサイトを丸ごと持ってきてから、php７.４環境に出来たのは幸運だったんですが。

でも、この方法しか分からないということは、各サイトのNetcommonsディレクトリを定期的に丸ごとバックアップし、同時にデータベースのバックアップも取っておかなければなりません。

そして、作業中に気付いたんですが、Uploadディレクトリのサイズが異様に大きくなっていたんです！

自宅サーバーだからということで、写真等もサイズを圧縮せずに載せ続けていたのが原因でしょう。

この調子で運用を続けていけば、サイトの容量がどんどん大きくなり、外部サーバーへの引っ越しとかも出来なくなります。

うーん、どうしよう・・・

悩み中です。

予定より２時間半も余計に時間がかかってしまいました・・・

ＳＳＤにＥＦＩパーテイションを作成する所からつまづきました。

ただ、旧システムが入ったＳＳＤをそのままＳＡＴＡ接続して、新システムにマウント出来たのは助かりました。

この手が使えれば、Uploadディレクトリが肥大化しても短時間でコピーが出来ます。

しかし、今までのリストア方法が使えなかったので、今回はNetcommonsディレクトリを丸ごと持ってきたんですが、

今後もこれで上手くいくのかが分かりません・・・

Netcommons３.３.１サイトの引っ越し方法は、今までの方法では上手くいかなくなってしまいました。

今回のバージョンアップは、コアに関するDBテーブルが変更になったとありましたので、そのことが関係しているのかもしれません。

そこで、今回の引っ越し方法を新たに記録しておこうと思います。

今回は、新規ストレージにDebian１０をインストールし、phpは７.４を使用することにします。

さらに、同一サーバー内にあったowncloudはインストールせず、その代わりに、新規に作った別のサーバーマシンにnextcloudをインストールすることにしました。

nextcloud環境の作成については、おすすめの方法が見つかりましたので、別の機会に書きたいと思います。

また、引っ越し前のwebサイトは、閲覧不可にしてからmysqldumpでデータベースのバックアップファイルを取っておくことを忘れないように。

＜手順＞

　①サーバーマシン内の点検と清掃、メインメモリ抜き差ししてメモリ接点のセルフクリーニング

　②マザーボードBIOS（UEFI）のアップデート

　③ストレージ（SSD）の交換

　④SSDにEFIパーテイション２５６MB作成（マザボがBIOSタイプなら不要）

　⑤Debian１０最小構成インストール

　⑥ファイヤウォール設定

　⑦SSHサーバーインストール、ポート変更、ローカル以外からのアクセス不可、rootログイン不可に

　⑧php７.４リポジトリ追加して、php７.４、php追加モジュールインストール

　⑨Apache、MariaDBインストール（mysql-secureインストレーションも忘れずやっておく）

　⑩acpuインストール

　⑪/etc/php/php7.4/apache/php.iniの編集（file upload関係、opcache、acpu設定等）

　⑫webminリポジトリ追加して、webminインストール

　⑬webminポート変更、ローカル以外からのアクセス不可、rootユーザー削除設定

　⑭powerOFF後、旧SSDをSATA端子に接続してpowerON、新SSDから起動するよう注意（UEFIでは別画面で設定？）

　⑮新SSDにマウント用ディレクトリ作成して旧SSDをマウント

　⑯旧SSDのnetcommonsインストールディレクトリを、新SSDのドキュメントルートへ丸ごとコピー

　⑰コピーしたnetcommonsディレクトリ以下の所有者をapacheにしておく（Debianならwww-data）

　⑱mysqldumpファイル、ヴァーチャルホストディレクティブファイル、DDNS通知用スクリプトファイルを旧SSDから新SSDにコピー

　⑲poweroffして、旧SSDを外す

　⑳新規データベース作成（例　MariaDB [(none)]> create database nc3db default character set utf8;）

　㉑旧サイトからのデータベースリストア（例　MariaDB [(none)]> source /home/hokan/20200419/nc3db.sql;）

　㉒データベースuserを今までのuser名で作成（例　MariaDB [(none)]> GRANT ALL PRIVILEGES ON nc3db.* to ncuser@'localhost' IDENTIFIED BY 'password';）

　㉓データベース設定反映（MariaDB [(none)]> flush privileges;）

　㉔ルーターのポートフォワーディング設定

　㉕外部からwebブラウザでアクセスして、正常にログイン出来ればＯＫ！

　㉖webサイト閲覧不可を解除

以上です！

これでも割と手はかかりますね！

GoogleDrive、Dropbox、icloud、Onedrive等のオンラインストレージサービスを、容量制限なしにどこでも自由にしかも無料で使いたいと考えたことはありませんか？

今回、自分で試してみて、結構すんなりと構築できる方法を見つけたので、紹介したいと思います！

自分が今まで使っていた owncloud より多機能で、しかも構築が早く確実にセキュアに出来るんです！

使う手ですが、

　①省電力自作ＰＣを用意（省電力タイプならメーカー製パソコンでも可）

　②OSはLinux（WindowsServerでも可だが、高性能かつ無料ならLinuxで）

　③自宅用ネットワークプロバイダ契約（通常のインターネット契約で可）

　④DDNSサービスの設定（固定IP契約しているのなら不要）

こんな感じです。

では、具体的に。

①ですが、まず省電力マザーボードを選びます。

自分は、Asrock社のCPUオンボードタイプを良く使います。

今話題になっているRaspberry Pi を使うのもアリだと思いますし、これは面白そうだしいずれやってみたい！！

でも、省電力だからとノートPCを使うのはやめましょう！ 本体やアダプターの発熱で火事になった例を見かけましたから！

ストレージは、WD社のRedあたりがいいと思います。SoftwareRaid１で構築するとさらに良し。

②のOSです。Linuxは色々なディストリビューションがありますが、つまづいた時に症例や答えをWebで見つけやすいものにした方が絶対にいいです！

すると、Ubuntu、CentOSあたりでしょうか？ 自分は専らUbuntuの原型Debianを使っています。

Desktop環境（GUI）は入れずに、コマンドを打ち込んでいくCUI環境で作るのですが、CUIは難しそうだと思ったら、GUIサーバーでもいいんです。

でもCUIでも、SSH端末をクライアントで操作する時はコピペでどんどん操作出来ますし、WebminというGUI風の操作が出来る強力な助っ人もあるので、ぜひCUIサーバーに慣れて下さい！

あ、自分はセキュリティ上、SSHとWebminはローカル（LAN）外からのアクセスは受け付けないように設定しています。

③は自宅でパソコンとインターネットを使っている環境ならそれでOKです。

SoftBank社のAC電源に差すだけでWifiなんていうルーターがありますが、これでもいけそうかな？

④は、MyDNSをおすすめしておきます。

最後に！ これだけは覚えて欲しいのがテキストディタ ｖｉ の操作法です！

やや特殊ですが、使っているうちに慣れると思います。

コマンド文入力、コマンド文編集のために必須のツールです。ただし、ｖｉｍ、ｎａｎｏといったツールでもＯＫです。

さて、準備が出来たら、ＯＳをUSBメモリでインストールしましょう。

インストール終了したら、update、upgrade して最新の状態にします。

さて、それからは？

（１）SSHサーバーインストールして、ポート変更、rootログイン禁止設定

（２）ファイヤウォールUFWをインストール

（３）UFWのポートは443、123、SSH分、Webmin分だけ開けておきます。

（４）時刻合わせにntpサーバーインストールして設定変更

（５）snapdインストール

（６）snap install nextcloud

（７）source /etc/profile.d/apps-bin-path.sh

（８）nextcloud.manual-install

（９）nextcloud.enable-https self-signed

これで、Webサーバー、データベースサーバーを含めたnextcloud環境を一気に構築出来、https通信も可能になりました！！

Webサーバーの細かい設定、データベースの作成等も不要なんです！

あとは、DDNSサイトで取得したドメイン名〇〇〇で外部ブラウザからアクセスして下さい！

　https://〇〇〇

これでインストール完了です！

ちょっと説明を簡略化していますが、もし興味があったら調べてみて下さい。もちろん、問い合わせ頂いてもＯＫです。

（補足１）

自分のサーバーマシンからDDNSサービスを提供しているサイトに定期的にアクセスをする必要があります。

その時のスクリプト（実行）ファイルは、例えばこんな感じです。

　wget http://www.mydns.jp/login.html --http-user=mydns●●●●●● --http-password=ﾊﾟｽﾜｰﾄﾞ -O /dev/null

　（この方法ではip情報更新できなくなったようです。他にもやり方が色々あるようです）

自分は、このファイルを、/etc/cron.d/ディレクトリにおいて、webminで１５分おきに実行させています。

注意点は、rootがこのファイルを実行する時、所有者はrootで、パーミッションは700でないといけない点です。

（補足２）

インターネット契約をした時に提供されたルーターに、ポートフォワーディング設定が必要です。

つまり、DDNS設定をしたあとは、登録したドメイン名に外部からアクセスがあると、自分の所に信号が来るようになります。

それが、https通信（ポート443）であれば、自作したサーバーマシンに信号を通すようにする作業です。

ルーターのマニュアルを見て下さい。ipマスカレード設定等とも書かれています。

補足ですが、この機能のおかげでhttps以外の信号はサーバーマシンに到達できなくなる訳ですね！

（補足３）

Linuxサーバーを構築する時に、またサーバーの初期設定をする時にすごく参考になるサイトです！

色々なＯＳについて、またそれらのＯＳの最新版について、分かりやすく書かれています！

　https://www.server-world.info/

昨夜遅く、突然外部からこのサイトへのアクセスが出来なくなりました！

LAN内クライアントからサイトへのアクセスは可能で、クライアントからWAN外部サイトへのアクセスもいつも通り出来ていました。

DDNSサービスの提供元Mydnsの障害状況、Mydnsからの障害報告メールもチェックしましたが、異常はなさそうでした。

そこでまず、ルーターの設定を再確認し、ルーターの再起動を行いました。

そしてクライアントからnslookupコマンドでサーバー機のグローバルip情報確認したら、ie-serverのDNS情報は更新されているのに、Mydnsでは更新されていない。

ルーターの再起動などでWAN側のipアドレスが変わると、DNS情報も変更される訳ですが、

この反映には時間がかかるんだろう（今までは直ぐに反映されていたようなんだけど・・・？）と、明け方３時ごろだったので、まずはとりあえず寝ちゃうことにしました。

ところが、朝７時ごろ起きて確認したら、MydnsのDNS情報は相変わらず更新されていない。

cronjobを実行させてログを見てみると、Mydnsサイトにアクセスは出来ているのにログインが出来ていない模様！

もう一方のDDNSサービスie-serverへのアクセスは今まで通りログインまで出来ているのに、どうしたんでしょう？

そうだ！

Mydns側でセキュリティを向上させる等の対策が新たにされて、ログイン出来なくなったことは充分考えられます。

そこで次の手ですが、「wget http:// ・・・」のアクセスログイン法から「curl https:// ・・・」の方法へ変更し、cronスクリプトファイルを書き換え、実行させてみました。

この方法で、ようやく３つのサイトをいつも通りWeb上に公開させることが出来ました！

と、ここまで書いてきた所で、突然このサイトが固まってしまい、apacheを再起動してもサイトが動かなくなってしまいました！

そこで、サーバーマシンを再起動しようとしたところ、全く予想外の事態が。

システムが、それにUEFIも立ち上がらない！

これには参りました・・・

しばらく考えたんですが、数年前電源ユニットが突然死したことを思い出しました。

業務用ノンストップタイプでもない電源を２４時間動かしていたので、これが一番怪しいと思ったんです。

ところが、電源を取り換えてみたんですが、原因はこれではなかった！

その次は、マザーボードからデバイスを徐々に外して起動を試みていくテストを続けました。

もう、珍しいけどマザーボードの故障だろうと諦めかけていた時、メインメモリを１枚だけ差した状態で起動！

しかも、もう１枚のメモリだけだと起動しない！

これで、特定のメモリの不良が原因だと分かりました！！

それなら、以前に使っていた２枚のメモリをデュアルチャンネルで動かすことにしました。

そして、念のためにMemtestを４時間弱かけて実行させました。

メモリーエラーはありませんでした！

しかし、DDNS関連はともかく、ハードウェアがなぜこのような状況になってしまったのか？

単に、メモリに故障が発生しただけなら直っているんですが、他の要因ということもあり得ます。

機械が壊れかかったまま動いているという状況だと、あとあと非常にやっかいなことになるんです。

原因が分からないままだということと、他のハードウェアも巻き添えで故障する可能性もあるんですね。

また、サーバーに対して外部からの攻撃も、あり得ないことではなくなってきています。

最近はハードウェアの設定を変更するような極めて高度な攻撃もあるそうですから！

そこで、サーバーへの外部からのアクセスを制限するように、設定を数か所変更しておきました。

はあ・・・疲れましたね・・・

さあ、これでキチンと直ってくれたでしょうか・・・？ 

自宅エリアではスマホは Wifi 接続にしないと、モバイル通信量がどんどん増えていきますよね？

このWifi接続にした時、LAN内の外部公開用Webサーバー、外部公開用Cloudサーバーに接続が出来なくなります。

その理由は、指定したURLをIPアドレスに変換する外部DNSサーバーは、WANでのグローバルIPアドレスを通知してくるのですが、

LAN内でのアクセスに必要なのは、プライベートIPアドレスなんです。

分かりやすく例えるなら、外から居場所を調べるには、東京千代田区永田町１－７－１といった住所が必要ですが、

その建物の中からは、２階の東から３番目の部屋といった情報が必要になるという感じですね。

ところが、特に iPhone 等のスマホを使わないのであれば、PC内のhostsファイルをちょこちょこっと書き換えてやれば、この件はすんなり解決してしまうんです！

実は、iPhone だって内部のhostsファイルを書き換えれば済んでしまうんですが、この行為は「脱獄」！ なんて呼ばれている禁じ手なんです・・・

これをやってしまうと、サポートが受けられなくなったり不都合がかなり出てくるらしいんです。

そこで、LAN内専用のDNSサーバーを立てよう！ということになる訳です。

我が家のLAN内には、Webサーバー以外に、Windowsで動いているラジオ録音用サーバーが常時動いています。

まずこのラジオサーバーにDNSサーバー「Bind」をインストールし、設定を試行錯誤で続けていました・・・

もう、自分には泥沼ですね・・・

設定ファイルを書く時のルールが細かくあって、半角スペースが全角スペースになっただけでもう動かないんです！

夕方の柴犬コータの散歩中に、そうだ！ と気付いたことがありました。

稼働中のWebサーバーにDNSサーバーを共存させても大丈夫だろうということです。

IPアドレスは当然同じになるんですが、ポートが違うので、別々にアクセスが可能だろうと。

散歩から帰宅してすぐにWebサーバーマシンにBindをインストールしました。

あれから延々６時間は経ちましたが、まだ終わりが見えません・・・

せめて、原因とか見通しとかわずかでも掴みたい・・・ 

今朝早朝３時半まで頑張ったんですが、DNSサーバーBindはどうしても上手く動かせませんでした。

checkconf、checkzoneコマンドも使って、構文エラーはずい分と解消されたんですが、定義文がどうしてもエラーになるんです。

自分は、DDNSサービスを２つのサイトから受けていて、Webでアクセスする全く異なるフルドメイン名が計４つもあるんです。

これをDNSの定義文に書いて実行しても受け付けてくれないんです。（複数ドメイン名は受け付けない？）

もう、クタクタです・・・

しかし、いまだにiPhoneのhostsファイルを書き換えること（脱獄）はやる気になれません！

そこで、最後の手を使うことにしました。

LAN内にプロキシサーバーを立てる手です。

RADIOサーバーはWindows機で動かしていて、このWindows機のhostsファイルはすでに書き換えてあります。

このWindows機にプロキシアプリをインストールしてみることにします。

プロキシアプリは、CCproxyを使ってみました。

動かしてみると、今までの苦労がウソのように解決！！

昼過ぎにやっと食べ物も口にして、カミさんのAndroidスマホの設定もやって、少しのんびりしていました。

が・・・

そう上手くは済まないものですよね！

CCproxyサイトから「ライセンス認証をしなさい」と通知が来ました！

フリーソフトと思っていましたが、違ってたんですね。

で、これはアンインストール・・・

では、ApacheをWindows機にインストールして、ApacheをProxyサーバーとして稼働させればいいんじゃないか？

ちょっと大変そうだけど、ApacheはLinuxでちょっとは馴染んでるし・・・

やはり時間はかなりかかりましたが、Windowsのコンパネの「サービス」、「イベントビューア」も上手く使わせてもらって、なんとかApacheの最新版をインストールできました！

そして、恐る恐る最後の設定をしてから、アクセス！

あれー？

Apacheの初期画面が出るだけ！

またまたググって、Apacheでプロキシサーバーを構築しているサイトを見つけました。

Proxyサーバーは代理サーバーであって、ここを経由させるだけなんですね。

環境定義文（http.conf）に「via proxy」の記載が必要でした。

これで、Apacheをもう一度再起動して、WifiLAN内のスマホから祈るような気持ちでアクセス・・・

成功です！ ついに完成しました！！

もちろん、出来たことは嬉しいんですが、

外で体を動かして汗ビショになってる方が気持ちいいですよね！ ？

昨日の続きですが、一応これで今回は落ち着きました。

たとえ話ですが、LAN内というのはＴさんの職場の中、WANは職場の外全ての場所だと思って下さい。

自分が外からＴさんに会いに行く時、住所録で住所を調べてＴさんの職場にたどり着けます。

　→　ここでの住所録がWANにあるDNSサーバーに相当します。

そして、職場の受付の方にＴさんの居場所を聞いて、Ｔさんの所にたどり着ける訳です。

　→　ここでの職場の受付の方がポートフォワーディングと同じ役目を果たしている訳です。

ところが、自分がすでにＴさんの職場内にいる時は、もう住所録でＴさんを探しても無意味な訳ですね。

LAN内からLAN内にあるサイトにアクセスを試みると、通常は外のWANにあるDNSサーバーに問い合わせに行く設定になっているので、上手くいかないという訳なんです。

さて、今回次に使った手は、LAN内に Proxy（代理）サーバーを立てる手でした。

この Proxyサーバーは、Proxyサーバーを稼働させているホストPCのhostsファイルをWANのDNSサーバーより先に参照するので、hostsファイルに記載されているLAN内の「居場所」をもとに目的のサイトにアクセスできる仕組みです。

実は、Proxyサーバーの積極的な使い方は、むしろ他にあるので、やはりLAN内専用のDNSサーバー構築が今後の課題です。

最後にもう一つ。

自宅のWindows機Radioサーバーは午前０時に自動シャットダウンして、午前５時に自動起動するように設定してあります。

昨日はこのWindows機に Proxyサーバー Apache を導入したんですが、

２４時間稼働している LinuxWeb サーバー機へ導入できないか、一生懸命考えていました。

すでにWebサーバー Apache が稼働しているところに２つ目のWebサーバーをインストールできるのか？

色々と調べてみましたが、 何とか行けそうな感じです！

エイヤッと、apt install Nginx でインストール実行！

インストールの最後にエラーが出るのは、ポート（８０）がバッティングしてしまうからです。

しかし、インストールは最後まで進むので、設定ファイルを書き換えてポート番号を変更し、Nginxを再起動させます！

これで２つめのWebサーバーを共存して起動させることが出来ました！

と、もう一息だったんですが、Nginx は初めてだったので Proxy設定が出来ませんでした・・・

そこで、２つめの Apache をインストール！

最初にインストールした Apache は、snapシステムで導入していたので、apt install apache2 で２つめの Apache はすんなりとインストール出来たんですね！

あとは、ポート番号を変更してApacheを再起動させ、Proxy の設定を行いました。

現在、この Proxyサーバーはしっかりと稼働してくれています！！（外部からのアクセスには関係していませんが）

今後、もし時間が出来れば、LAN内の複数サーバーを、仮想サーバー内で稼働させ、複数のサーバーマシンを出来るだけ少なくまとめていけるといいかな、と考えています。

この手は非常に合理的でカッコ良く、ベストのようにも思えるんですが、メンテナンスや故障対応は相当に大変そうです！！

それならば！

集中したアクセスが少ないオンラインストレージサーバー、Proxyサーバーあたりを Raspberry Pi で構築し、メインサーバーマシン内に設置してしまうのはどうでしょうか？

あ、出来ることなら、ProxyサーバーではなくDNSサーバーを構築したいですね。

電源もメインサーバーマシン内でもらうんです！

どうでしょうか？

また新しいことが分かりました！

でも、今度こそこれで終わりにしたいと思います！

LAN内専用のDNSサーバーって本当にないのかな？

いつも Bindのような設定の大変なソフトを使ってるんだろうか？

どうしてもこの疑問が頭を離れませんでした。（コータの散歩してる時も！）

そして、悪いクセでまた色々と調べ続けちゃったんです。

すると、YAMAHA社のルーターとかは、自身にDNS機能を持たせてあって、LAN内の名前解決に使えるとのこと。

でもこのルーターは高価で、それだけのためにこれを買うことは考えられません。

そう言えば、Windows機で自宅のネットワークを作った時、PCにつけた名前でアクセス出来た経験があるでしょう？

DNSサーバー設定していないのになぜ？

あれは、WindowsのNetbiosという機能で可能になっているらしいです。

そんなこんなでさらに検索していると、LAN内DNSサーバーDnsmasq という由緒あるらしいLinuxソフトを発見！！

もう、ホントにどうしてこれが昨日までの検索でひっかからなかったのか？！

検索の仕方がヘタクソだ！ と言われればそれまでなんですが・・・

そしてこのDnsmasq、設定もシンプルで分かりやすい！

すごい大発見！！（大げさですみません）

さっそくインストール！　そして設定も終わらせて起動させました・・・

何と、ついにLAN内DNSサーバーは完成に至ったんです！！（また大げさ・・・）

もちろん、WANにある外部サイトには、セカンダリDNSサーバーに問い合わせをしてアクセス出来るんです！

あ、昨日構築したプロキシサーバーは休止させました。（まだ残してはあります）

これで iPhone の写真や環境ファイルのバックアップ等も、自宅に居ても自分のオンラインストレージに保存できます！

iCloud の追加容量料金なんて払いたくないですからね。（笑）

さあ、今度こそ一件落着したんですが、またまたちょっと不思議なことを体験してしまいました・・・！

もしかすると気のせいかもしれないんですが、昨日のプロキシサーバー経由の方が、サイトからの反応が早い！？

えっ？　そんなバカな！

だって、データの流れは、プロキシサーバーを使うと、

Webサイトサーバー　→　プロキシサーバー　→　クライアント（スマホ）なんです。

LAN内DNSサーバー使用の時のデータの流れは、

Webサイトサーバー　→　クライアント（スマホ）となり、経路が短いんです！

ああ、それはDNSサーバーからの応答が遅いせいじゃないか？　と自分も最初は思いました。

でも、この軽量のDNSサーバーの応答が遅いんでしょうか？

Dnsmasqがサーバー機のhostsファイルを参照するだけだから、動作即完了ですよね？

プロキシ使用の方が速いとすれば、プロキシサーバーのキャッシュ機能とかが効いてるんじゃないでしょうか！？

リバースプロキシとかは、そのような効果も期待して構築するようですから！

あ、でも、今はもう手を出しません！

こんなことばかりやってると、他のことがお留守になってしまいますから！

もうすでに、時間を大量に費やしてしまっているんです・・・

先日、このWebサーバーマシンが不調になったことを書きましたが、原因はメインメモリの故障でした。

メモリーモジュールが故障するのは珍しいと思いますが、過去にも数回経験はありました。

ただ、常時稼働のWebサーバー機ですから、メモリーもバルク品ではなく信頼性のありそうなものを選んだんです。

JEDEC規格、永久保証の新品（panram社）でした。

ForNotePCとありますが、これは大丈夫でしょう。

さて、故障がはっきりしたので、販売店に問い合わせたところ、修理のため返品して下さいとの返事。

返品したところ、販売店経由でメーカーまで送られたようです。

結局修理不能で、新品を新たに送り返してくれました！

ということで、今回は稼働前にこのメモリーのテストを念入りに行うことにしました。（memtest実施）

万一、再度不良の場合もここで見つけておかなければなりません。

また正常ならば、はっきりと解決！ですね。

今日メモリーが届けられたので、販売店にも出来るだけ早く報告する必要もあるんです。

メモリーのテストはWebサーバーの動作を止めて行う必要があるので、今夜から明朝にかけてサイトを一時停止します。

またまた急で申し訳ありません！

テストは４時間ほどで終了するはずですが、遅くとも明日午前８時にはこのサイトを再開出来ると思います。

２４時からテスト開始します。