PC設定覚書と雑記

サーバー運用とPC日記

職場PC-LinuxMintを使ってみよう!

 新しい職場には、準備室にPCがなく、
webでの調べもの、メール連絡等が出来なくて不便な状態でした。
先週の金曜日、放置されていた旧型PCを準備室に持って行って良いと許可がおりました!

Dell-Dimention4700C という機種です。
内部を掃除しながら調べたところ、チップセットはintel915世代でした。
CerelonD2.53GHz、DDR2メモリ256MB×2(2GBまでOK)、HDDはSATA40GB
といった内容でLinuxでもディストリビューションを選べば軽快に動作しそうです。
Lubuntu か、 LinuxBean あたりかなぁと思っていたんですが、
ふと LinuxMint の Debian エディション(LMDE)の記事が目にとまりました。
リソースの消費量が少なく、PentiumM等のNonPAEのCPUでも動くとのこと。
このDellマシンはPAE対応なんですが、
カミさんの教室にある PentiumM ノート(NonPAE)がLinuxBeanで動いているので
これを LinuxMint Debian エディションに入れ替えて様子を見ようという訳です。

日本語化対応が十分でないようなので、その対処法を調べました。
親切なページがありました! Linux Mint Japan のページです。

  http://linuxmint-jp.net/index.html

これで準備OKです。
インストールDVDを作成し、まずは自宅のAtomマシンに入れたところ
軽快な動作と共に結構いい感じです!
PentiumM ノートにもインストールし終わり、カミさんにも使ってもらうことにしました。
明日以降、時間がある時に職場のPCをLMDE(Mate版)に入れ替える予定です。


以下、Linux-Mintについてです。

 洗練され、最新で快適なLinuxデスクトップを提供することを目標としている。
Linux Mintは2006年フランス出身のクレマン・ルフェーブルにより設立された。
2010年7月に製作側はUbuntuの代わりにDebianをベースとしたLinux Mintをテストしていることを明らかにした。


ベースをUbuntuからDebianへすることの主なメリットとして、
コンピュータリソースの使用量を抑えられ、Ubuntuベースよりも快適に動くことを挙げている。
また、2010年9月にはLinux Mint Debian Edition (LMDE) をリリースした。

職場PC−本体の整備

 前回の続きです。
まず、PC本体を開け、内部をていねいに掃除します。

メモリはDDR2の256MBが2枚刺しになっていました。
これを手持ちの1GB×2(pc6400)に換装します。
ところがビープ音が鳴りBIOSが立ち上がりません。
調べてみましたが、この規格なら認識するはずです。
いろいろ試したところ、1GBの1枚刺しで起動OK。
その後2枚刺しにしたら無事立ち上がりました。
デュアルチャンネルモードで動作しています!

HDDは手持ちの500GB(WD blue)に換装。
容量の壁は一昔前が137GBで、次が2TBなのでOKです。
HDDは世代が新しいものの方が一般的に高速です。

次はCPUですが、2次キャッシュがCerelonの4倍のPentium4に変えましょう。
Pentium4の終わりに近いプレスコット(コードネーム)で、メーカーカタログを調べると3.4GHzの550までOKとあります。
しかし、電源容量と放熱処理が大丈夫なのか?
TDPは、オリジナルCerelonDが73w、Pentium520が84w、Pentium550は115wもあります。
オリジナル電源で115wのCPUは無理があるかもしれません。
4700Cがグレードによらず、すべて同じ電源かどうかも分かりませんでした。
CPUの中古価格も調べてみたら、オークションに結構でてました! しかも安い!
400円なんて感じですから、「はぁ~」ですね。当時3万円弱はしたCPUですから。
実はこのPentium4プレスコットは高消費電力で悪評高いCPUでした。
あと、CPUファンがものすごくうるさい! 発熱を抑えないと騒音にも悩まされます。
このファンは、注油と温度センサーの掃除でかなり静かにはなりましたが。
以上のことから、Pentium520(2.8GHz)を400円で落札(即決)。送料の方が高いけど千円ちょっとでCPUが届きました。
ヒートシンクの接合面をきれいに拭き取り、ファンのほこりもすべて取り除き、CPUを換装。
BIOS認識OK。Hyper-threadingもONに変更します。
PC本体の起動も無事OKでした!

やっとOSインストールに進んだんですが、すぐに問題発生。
続きは次に書きます。

職場PC−ネットワークつながらず

ネットワークにつながりません・・・!
LinuxMintがネットワークインターフェースを認識していない?
ちょっと時間がかかりましたが、少しずつ分かってきました。
インターフェースは認識されているようなんです。
ところがこのインターフェースのデバイスが機能していない、つまり壊れているんだろうと推測。
DHCP環境に置いてみて再セットアップしてみましたが、
自動で接続されるはずのネットワークにまったく繋がりません。
また、自hostにpingは通るけど、他のどこにもunreachableという状況です。
DELLの中古PCを買った時に、これと全く同じ状況にあたったんです。
そうだ、この時装着したネットワークカードを流用すれば解決!
で、職場に持って行ったら、PCIスロットがない! PCI-Expressスロットしかありません。
古いPCだからと思っていたのですが、ここのところはちょっとだけ新しかった。
で、PCI-Expressネットワークカードを発注。送料込みで2200円の出費でした。

さて、ネットワークカードが届くまで、まだ整備できる箇所は?
調べてみると、CPUまだupgrade出来そうな情報が・・・
続きは次に。

職場PC-CPU更にupgrade

 このDimension4700Cのメーカーカタログを見ると、
最上位機種では、Pentium4-550(3.4GHz、2次キャッシュ1MB、TDP115w)が使われています。
現在、電源容量を気にして、Pentium4-520(2.8GHz、2次キャッシュ1MB、TDP84w)に換装した訳です。
この520 を 550 に換装しても、発熱は増えるが、体感的な効果はほとんど感じられないと自分は思います。

ここでさらに調べてみたところ、Pentium4-630(3.0GHz、2次キャッシュ2MB、TDP84w)への換装が成功している記事を見つけました。
2次キャッシュ倍増はメリット大だと思います! しかもTDPは増加しないので、変更する価値ありですね!
中古市場で630の上位版Pentium4-650(3.4GHz、2次キャッシュ2MB、TDP84w)も探してみましたが、現在のオークションでは630までしか見つかりませんでした。
また660以上だとTDPは115wになってしまいます。
さらに、Pentium4-651(3.4GHz、2次キャッシュ2MB、TDP65w)が載せられれば、発熱が減りbestだったんですが、このCPUに換装して成功した記事は見つかりませんでした。(BIOSが対応していない模様)

ここで、最後にもう一度考えました。
電源容量、CPUファンの騒音が何とかなるのなら、TDP115wのCPUも候補になります。
するとbestは、Pentium4-670(3.8GHz、2次キャッシュ2MB、TDP115w)?
いや、このへんでやめておきましょう。
電源トラブルとか、ファンの交換など大変なことになりそうな予感がしますし、ここまでやると投資しすぎですね。
とにかく、やり始めると、成功しようが失敗しようが、止まらなくなってしまうのでまずいんです。(笑)
今回はいさぎよく、換装成功の記事のあったPentium4-630に決めることにしました。
オークションで、無事630が入手できました。送料込みたったの416円でした!

さて、このCPUに換装するためには、BIOSをupdateしなければなりません。
最近のBIOSupdateはOS上で簡単に出来てしまうので、このやり方ばかりやってきましたが、今回はDOSを立ち上げてからのupdateでないとダメでした。
このDOSを立ち上げてからのやり方は、以前はフロッピーディスクで簡単に出来ていました。
しかし、フロッピーディスクドライブ(FDD)なんてもう付いていません。
では、どうすれば良いのか?
この続きは、次に書きます。

職場PC-BIOSupdate

 BIOSupdateなんて簡単です。
OS上から出来なくったって、以前のフロッピーを使ったやり方があります。
フロッピーが使えなくったって大丈夫でしょう。
要は、DOSというOSを立ち上げて、そのDOSシステムにコマンドを打ち込んで、アップデートファイルを実行させればいいんですから。
そんな感じで軽く考えていました。

検索してみると、
USBメモリ、またはCDを起動メディアにする方法が載っていました。
探してきた1GBのUSBメモリをPCに差し、ダウンロードしたフリーソフトを実行。
フォルダオプションでシステムファイル等が見える状態にしてから、USBメモリを覗いてみると、確かにDOSのシステムファイルが書き込まれています。
ところが ・・・ 自宅PCでも、職場PCでも、このUSBメモリからは起動できませんでした。
そこで、別の2GBのUSBメモリで試したところ、自宅PCからは無事DOSシステムが起動!
このメモリにBIOSupdateファイルを書き込み、職場に持っていきました。
早朝の職場で期待を込めて、USBメモリを差してからスイッチオン。 
 ・・・ これでいけると思ったのに、起動しません!
もちろん、起動順はUSBメモリを1番にしてあります。
結局、なぜダメかは分からずじまいのまま、他の方法を試すことに。

もう一つの起動CDディスクを作るやり方は、ちょっと面倒でした。
まず、仮想FDドライブを作るフリーソフトをダウンロード、インストールします。
これで、作業中のPCに仮想のFDが出来ます。
この仮想FDをフォーマットする時、「DOS起動ディスクを作る」にチェックを入れてフォーマットします。
昔、FDをMSDOS起動ディスクにした時の要領ですね。それを仮想ドライブに対して行う訳です。
これが終わったら、このFDドライブにBIOSupdateファイルを書き込みます。
さて、こうして出来た仮想FDドライブはイメージファイルとして保存できるようになっています。
そして、ISOファイル作成フリーソフトで、上記のイメージファイルをISOファイルに変換。
これをCDに焼き付けます。(イメージライティング)
今回は、これでDOS起動CDディスクが出来ました!

BIOSも無事update出来ました!

職場PC-最終調整

 BIOSもupdateでき、Pentium4-630もすでに届いているので、これに換装します。
CPUファン、温度センサーも改めて念入りに掃除し、
放熱グリスをまんべんなく、しかし多くなり過ぎないよう塗ります。
CPU装着。無事、起動し、BIOS上からも正常に認識されています!
動作周波数3GHz、2次キャッシュ2MBです。
最新環境での動きにはもちろん敵いませんが、
このPCでのLinuxMintDebianEdition2 Mate版の動きはなかなか軽快です!

さて、最初につまずいたネットワークインターフェースが解決していません。
BIOSも新しくなったので、オンボードのネットワークインターフェースの設定を変更してみます。
有効、無効、の設定変更を繰り返して動作確認しましたが、やはり状況は変化なしで、
オンボードのネットワークインターフェースの故障は間違いないようです
では、注文しておいたネットワークカードを装着してみます。
PCI Express x1端子への増設です。
機械的にきちんと装着されていることを確認してから、
AC電源プラグを刺し、PowerオンしてBIOS設定。
「オンボードネットワーク無効」にしてあることを再度確認します。
そして再起動。さて、このOSは、新しいネットワークカードを認識してくれるか?
起動後、ifconfig、pingコマンドで正常動作が確認できました!

ここまでたどりついたので、せっかくですから、
OSインストールを最初からやり直すことにしました。
インストール用起動メディアは、高速USBメモリを使った方が絶対に早いです!
CDやDVDメディアを使うよりOSインストールが早く終わるので、
テストサーバーを作ったりする時もストレスが少ないです。再インストールもすぐできます。
インストール用USBメディアは、別マシンWindows上で、Unebootin等のフリーソフトを使って簡単に作成出来ます。

もう一つ、職場等でのproxy設定は、OSインストール後のGUIによる設定では不充分でした。
 /etc/environment
 /etc/apt/apt.conf.d/02proxy
 /etc/wgetrc

上記ファイルに職場のproxy情報を追記する必要がありました。

こんな感じで、時間がかかりましたが、職場PCの設定は無事終了し、
現在、結構いい感じで安定動作しています。
ファンの爆音も解消されています。

以上、今回のPC整備は成功だったと思います!


Debian8 Jessie登場

 Linux、Debianの次期ヴァージョンが出ました!
Debian8、コードネームは Jessie です。

自宅のSambaファイルサーバをDebian7で作ったばかりだったんですが、カーネルも新しいし、Sambaもver4になっているので、作り直すことに。
今回、ファイル置き場のhomeディレクトリはそのままにして、
他のディレクトリはフォーマットもして、OSを新規インストールしました。
だいたい上手くいったのですが、
カミさんと娘のSamba内のファイルが消えていました・・・
(あ、もちろんバックアップがあったので大丈夫でしたが)
自分(初期ユーザ)のファイルは無事でした。
サーバー出来立ての時は初期ユーザだけですから、他のユーザは存在できず、それが原因でファイル消えたのかも。
ディレクトリの権限は、Sambaでコントロールされる訳だから、
最初から、オーナーはrootにして、パーミッションは777にしておけばいいような気がしてきました。

また、aptでowncloud8もインストールできました。
apacheは2.4になっていたので、設定の仕方を調べておかないとnetcommonsを入れる時につまずきそうです。

でも、何とかなりそうかな? と思っています。

SSHサーバー

 webサーバーを維持管理するためには、リモートアクセスの仕組みを作っておく必要があります。
今までは別の手段でリモート管理していたのですが、Debian8環境のテストサーバーではうまく動かない場面が出てきました。
そこで、SSHログインを試すことにしました。
LAN内では鍵認証方式もうまくいったのに、WAN環境では結局うまくいきませんでした。
ポートは開けたつもりだったんですが、ルーターのポートがどうも開いていなかったようです。現地のルーターは遠隔操作できません。
サーバー設置場所に出向いていって作業するしかありませんね。

SSHサーバー(続)

 午後に、入間市のサーバー設置場所に到着。
ルーターの設定を確認すると、やはりポートが開いていませんでした。
とりあえず、決めておいたポートを開けましたが、
今度は、設置場所でのWANアクセステストは出来ない訳です。
夕方、川越の自宅に帰り、openssh-serverをリモートでインストールし、
(どうやってリモートインストールした?)
configファイルを修正し、SSHサーバーを再起動。
Teratermから無事にアクセス出来ました!
このTeraterm、scpも実装されていて、ファイル転送も出来るんです!

kona-linux lite

 古いマシンでも動きの軽いLinuxに注目しています。
puppy-linux、lubuntu、linux-bean、linux-mint(lmdeも)くらいかと思っていましたが、
国産の kona-linux というディストリがあり、その中にも色んなタイプがあるようです。
debianベースで、non-paeのCPUにも対応していて動作も軽い!とのこと。
kona-linux3.0lite は、debian8 がベースになっている軽量版です。
早速、職場のPen4デスクトップpcにインストールしてみたいと思います。

kona-linux lite 2.3

 職場のデスクトップPC、カミさんのノートPCは、どちらもkona-linux lite2.3に落ち着きました。
kona-linux lite3.0、kona-linux black も試しましたが、ブラウザ動作中の軽快感はどれも変わらない感じでした。
3.0 はOSカーネルが最新版になっていますが、これらの環境ではメリットが感じられませんでした。また、blackではデスクトップにアイコンが置けません。
ということで、kona-linux lite2.3 を使用中です。
しかし、Firefoxを立ち上げてフル画面描写させただけで、CPU利用率がすぐに80%を超えたりするのにはちょっと驚きました。

WebServerマシンの掃除

 本日、18:20から10分間ほど
WebServerマシンの目視点検と清掃を行いました。
webアクセスが無い事を確認して、
リモートでシャットダウンし、作業を行いました。
ホコリが随分たまっていたので、エアダスターで取り除きました。
目視では異常がなく、復旧後も正常に動いています。

連絡せずにシャットダウンしましたが、
不都合等ありましたら、ご連絡ください。

WebServerマシンの大幅メンテナンス

 一昨日から、かなり長い時間かかりましたが、
WebServerマシンのOS入れ替え作業を行いました。

 まず、3つのwebサイト本体のバックアップ、
ヴァーチャルホストの設定ファイル、DDNSへの通知スクリプトファイルも忘れないようバックアップ。

 次は、ルーターのIPマスカレード設定を無効にして、外部からアクセスを受けないようにします。
そして、マシン内部の掃除、異常がないか、目視点検です。
電源、マザーボード、HDD等、温度異常もありませんでした。
HDDをまっさらにする前に、もう一度忘れている作業がないか、一息考えます。

 では、いよいよOSの再インストールから始めます!
OSはDebianの最新版、Jessie64bit版を使います。
webサイトが正常にリストア出来るか、LAN内でですがテストはしておきました。
クライアントのWindowsマシンで、netinst.isoファイルをダウンロードし、フリーソフunetbootinでインストール用USBメモリを作っておきます。
CDRでインストールディスクを作るより、手軽で確実で早いです! 
CDドライブはwebサーバー運用中は不要ですから、尚更です。USBメモリインストールで決まりでしょう。
USBメモリは高速タイプがいいです。今回64GBメモリはうまくいかず、4GBメモリを使いました。
HDDは、3.5インチ2TBを2台ソフトウェアRAID1とし、パーテイションは2つに分けました。
OSインストールは最小構成です。デスクトップ、GUIはもちろん、基本的なユーティリティも入れません。
apache、mysqlも最初にはインストールしません。aptでowncloudをインストールする際に、依存関係も含めて、またphp等必要なものも一緒にインストールしてくれるからです。

 作業手順ですが、
OSインストール → OSアップデート → rootログイン禁止 → ユーザsudo設定 → サーバーリモートログオン設定 →ファイヤウォール設定 → 必要なrepository設定 → 再度OSアップデート → owncloudインストール → owncloud設定 → netcommonsインストール →  netcommonsリストア(作業手順はこちら) → ルーターIPマスカレード設定 → 動作確認
こんな感じで進めていきます。

今回も、結局徹夜の作業となってしまいましたが、何とか完了しました!

Windows10へのアップグレード

自宅にある数代のWin7機に、Win10へのアップグレードの通知が頻繁に来ていました。
ずっと無視していたら、カミさんに貸していたデスクトップPCがupdateでつけっ放しにしていたところ、やられました! (皆さんもやられたと思いますが!)
次の日に、何か変だから見てくれる?と言われ、確認したらWin10にされちゃっていました。
ところが、起動やソフトの動きは、ほぼ速くなっているようで、
この新しいカーネルはいいんじゃない? と簡単に、自分もWindows10に寝返ることにしちゃいました!
ただIE11は頻繁にフリーズするようになってしまい、MS Edge、Chrome等も併用してしのいでいます。
プリンタも含めたデバイスの認識や、常用しているソフトの動きに問題がなければWin10にしてしまった方がいいと思います。
実は、アップデートではなく、クリーンインストールする方法も見つけたので、
DAWマシン、ラジオサーバーはその方法で作成しました。
(これは2016年6月の記録です)

Webサーバーハードウェア更新

久しぶりにwebサーバーのハードウェアを入れ替えました。
マザーボードは、Asrock社の J3710M(Pentium J3710オンボード)です。
前回 Celeron 847 からの比較では、TDP 17W → 6.5W、クロック 1.1GHz → 1.6GHz(ターボ 2.6GHz)、コア数 2 → 4 で、省電力化しているのに、基本性能は向上しているのが嬉しいところ。
しかもSOCなので、チップセット込みで 6.5W なんです!
キャッシュは 2 MB と変わらずですが、コア数 2 倍になっているので 1 コアあたりは減少していますね。
送料手数料込みで 9,970円でした。
RAID 1 にする HDD は、WD 社の Red 2TB 2台としました。
メモリーはDDR3-8GB × 2がそのまま流用できました。この板でもデュアルチャンネル動作はOKでした。
電源ですが、今年 4月に壊れて新調したばかりなので、これも流用しました。(Corsair RM550x)
デバイスが省電力なので、BIOSはパフォーマンス優先設定としました。
試しに、Ubuntu16、Ubuntu14、Debian8、をインストールしてみましたが、なぜか最新の Ubuntu16 は立ち上がりがかなり遅かったような気がします。何かしらの新しい機能追加でしょうか?(メーカー発表の対応OSには Ubuntu16 、Debian8 は載っていないのですが
ハードウェアより OS が若干新しい程度ですから、デバイスの認識に難があったとは思えません。
使いたい netcommons2 は、php7 非対応なので 
Ubuntu16 はダメ。
で、最初から身軽な debian がやはりいいだろうということで、debian8_64bit版に決定しました。
apache、php
のキャッシュ方法、mysqlの最適化をちょっと勉強して設定してみました。
webサーバーの動作は、以前よりキビキビしているようですし、今のところ順調に動いています!

netcommons3 への移行ツール

netcommons もやっと ver3 が出て、提供元の netcommons3 関係のサイトも開設されました。
netcommons2 から 3 にアップデートするには、アップデートパッチを当てるとかではなく、移行ツールなるものを使わないとダメなんです。(システムが全く別物になっている)
ところが、この移行ツールがまだ見当たりません。
今年の 8月のユーザーカンファレンスのプログラムには、「移行ツールの使い方」が公表されているので、この夏に出るのかもしれません。
このサイトも、移行ツールで 
netcommons3 にリニューアルする予定です。
新しくしたい最大の理由ですが、OS の php がほとんど ver7 になってきているのに、netcommons2 は php7 では動かないんです。( debian9 も php7 )
netcommons2 が php7 対応になってくれればいいんですが、どうもそれはやってくれなさそうです。
また、owncloud も php7 で動かした方がパフォーマンス等良くなるでしょう。
ということで、nc3 への移行ツールを心待ちにしているところです。
でも不安が・・・
簡単に、すべての内容が移行できるのか?
また、超長~い時間ハマって苦しむんじゃないかなあ・・・ 

新調サーバー内のNetcommons3環境にNetcommons2サイトを移行しました

この夏に、Netcommons3への移行作業に手を出してしまい、結局、かなりの日数を費やしてしまいました。

Netcommons2サイト運用で問題はなく、Netcommons3自体が完成までもう少しではないのか?という感じもあったので、迷ったのですが、夏休みでないと、移行作業のためのまとまった時間が取れないということもあり、移行を決心しました。

同一webサーバー内での移行手順を記しておきます。nc2サイトは動かしたままで出来ますが、閲覧停止状態にしておいて下さい。

 

 ① nc3用DB3作成。この時、user、passwordを、旧nc2のDB2のuser、passwordと同じにして作成。DB名は同じでなくて良い。(この場合、同じにはできませんが)

 ② 別のヴァーチャルホストを作成し、別ドキュメントルートにnc3ファイルを展開しnc3をインストールする。DB3のprefixはDB2とは別にする。

 ③ インストールが終了したら、サーバーOSにログインし、インストールディレクトリ / app に移動。カレントディレクトリを移動せずに、フルパス指定で実行するとcakeがうまく動かない。

 ④ # ./Console/cake Nc2ToNc3 --database NC2のDB名 --prefix NC2のテーブルプレフィックス名 --upload_path NC2のアップロードファイルフォルダーパス --base_url NC2のベースURL --nc3base NC3のベースパス

を入力してEnter(実行)。

実行文の例を参考にして下さい。また、このページのやり取りも参考になりました。上記「NC3のベースパス」は自分の場合は、ヴァーチャルホストのドキュメントルートにnc3ファイルを展開したので、「/」としました。

 ⑤ 実行経過が順次示されていくので観察する。実行が最後まで進んでも、エラーが出ると完成サイトにアクセスできない等のトラブルが起こることがある。(かなり長い時間がかかる。自分の場合は20分以上!)

 ⑥ 完成サイトにアクセスして、トップページのお知らせモジュールを削除、phpメモリ設定、送信メール設定等を行う。失敗していたら、DB3削除、nc3インストールディレクトリ削除して、最初からやり直し。

 ⑦ 旧urlでアクセスしたいのなら、/app/config/application.yml の fullBaseUrl:を旧urlに書き直す。

 ⑧ 各フォルダのパーミッションを確認して設定しておく。このページの、インストール後のパーミッション参照。

 ⑨ 新ヴァーチャルホストの、servername、ドキュメントルートパス等の記述を書き換え、設定を読み込む。またnc2サイトのヴァーチャルホスト設定は無効にする。その後apache再起動。

 

 以上ですが、恥ずかしいことに、最初は全く分からず、cakeを別にinstallしなければいけないのか(実際は不要)、とか、上記DB2、DB3のアクセス情報が同一でなかった(これではツール動かない)、とか手探りの状況でした。

もちろん、「Netcommons問い合わせ」にメールで質問はしたのですが、どうもNetcommons開発母体が有償サポートの方針のようなんです。

多様なニーズ、セキュリティ面など、今後のアプリケーション開発はますます大変になっていくだろうと思われます。当然、開発費用もかなり必要になってくるでしょう。ということで、利用に際してある面では有償になるということは、止むを得ないのでしょうか。

こちらは、全くの無料で使わせていただいているので、やはり文句は言えないのかな、と考え直した次第です。

 

実は、そんな中で、貴重なアドバイスを下さったエンジニアの方もいらっしゃったんです!

Netcommons3開発者の一人である天野さんという方です。

この方のアドバイスを「NC3サイトのバックアップリストアについて(3~5)」に記しましたので、是非読んで下さい!

 

さて、自分のサーバーでは、Netcommons2サイトを3つ公開していました。

上記の方法で2つのサイトは何とか移行できましたが、残り1つがどうしても上手くいきませんでした。

移行ツールは途中エラーが出ながらも最後まで走るんですが、完成サイトにアクセスすると「不正なリクエストの可能性があります」と表示され、さらに無限ループの応答になり、失敗します。

エラーを見ると、Undefined index : room_id、Undefined index : user_id が出ています。さらに、移行できないphotoalbum dataがある、というような内容でした。

nc2サイトに戻り、まず退会したユーザを削除して、再度移行を試しましたが失敗。

そこで、今までのnc2サイトでの運用をたどってみて、ある利用者Nさんの管理者権限をユーザ権限に変更したことを思い出しました。photoalbumもNさんの作成だったんです。

で、nc2サイトのNさんの権限を再度、管理者権限に戻し、移行をやり直しましたが、結果は変わらずで失敗。

結局、Nさんの作った photoalbum を削除して、やっと移行が成功しました!(ここまで1週間近くかかりました)

Nさんが管理者の時に作っていた photoalbum と 画像データは、Nさんをユーザ権限に変更した時点でnc2内での扱いがおかしくなっていたのでは? と想像しています。

ユーザ権限では、photoalbum を作ったり編集したりできない訳ですから。

 

まあ、とにかく、ここまででやっと何とかなったようなんですが、この後手を出した件で再び泥沼にはまることに・・・

Netcommons3サイトのバックアップリストアの正しい方法は?(1)

実は、Netcommons3に移行しても、未解決の大問題が残っています。

それは、Netcommons3サイトの引っ越し(リストア)の正しい方法がまだ分からないということです。

これが出来なければ、ハードディスクの交換やサーバーの新調もあるでしょうから、運用はいずれストップしてしまいます。

Netcommns2で用意されていたバックアップ機能が、新Netcommns3にはまだ搭載されていません。(2018.8.21現在)

そこで、Netcommns2の時と同じようにやれば出来るだろうと思い、実験をしておきました。その方法は・・・

 

 ① 旧DB3のダンプファイル △△△.sql 作成。

 ② fileuploadディレクトリ( app / webroot / files / upload_file)取得。圧縮して持ってきました。

 ③ 新環境に新DB3作成(prefixのみ旧サイトと同一に)してnc3を新規インストール。

 ④ インストール完了したら、③の新DB3をいったん削除。

 ⑤ 再度③と同様にして新DB3作成 → mysqlコマンドで、use 新DB; → source /○○○/○○○/△△△.sql; で旧DB3インポート。

 ⑥ app / webroot / files / upload_file ディレクトリを②の解凍ディレクトリと置き換える。

 

これで、ブラウザからアクセスして、トップページが見えました!

出来た! と大喜び。

これで行ける、と検証せずに終わらせちゃっていたんです・・・

 

今回、nc2サイトをnc3サイトに移行出来たので、ハードウェアも新調して、新サーバーに引っ越ししようと、再度このリストア法を使ってみました。

作業完了してトップページが見えました!

ところが・・・!!

何と、ログインが出来ない!! ん、パスワード間違えたか? いや・・・何かおかしい・・・

「パスワードがわからない方はこちら」のリンクも表示されません。

何度確認してもダメでした。

そうだ、旧Configディレクトリを上書きしてみよう。

エラーが出てダメでした・・・ この方法では何か足りないんでしょう。

以前、DBテーブル内のパスワードデータを確かめようとしたことがあるんですが、ID等と違って、暗号化された(?)文字列でした。この暗号化データを復号させるしくみがどこかにあるのかな?とか。

 

で、最終的にどう引っ越しさせたのか?

nc2サイトを移行したばかりのnc3ディレクトリを丸ごと持って来たんです・・・!

DBは、ダンプファイルにして、新DBにインポートしました。

今の自分にはこれしか手がなかったんです。

このサイトもこのやり方で出来ているんですが、今のところ不具合はありません。(と言っても、まだ1週間も経っていませんが・・・) 

 

nc3サイトの正しいバックアップ、リストアの方法を教えて下さる方、どうかよろしくお願い致します!!

そして、Netcommons3にもこの仕組みが組み込まれますよう、熱望しています!! 

 

<追記>

2018.9.13現在、Netcommons 3.1.10 までの対応ですが、このページをご覧ください。

NC3サイトのバックアップ・リストアについて(2)

NC2と同様の方法でバックアップ・リストアを試したら、ログインが出来なくて失敗に終わった、と前回書きました。

しばらく、ない頭でずっと考えていたのですが、ちょっと思い当たる件をいくつか書いてみます。

 ① NC3ではログイン情報(id、パスワード)の扱い方がNC2とは変わっているのでは?

 ② ユーザのパスワードはそのままの値ではなく、何らかの規則で変換されているはず(以前DB内のid、パスワード、を表示させてみたら、idはそのままの値、パスワードは意味不明の長い文字列だった)

 ③ 職場では、NC2による個人情報を入力してもらうような受け付け方法を禁止する通達が来た。この件が示しているように、NC2では現状のセキュリティレベルを満たさなくなっているのではないか?

 ④ よって、NC3では、ログイン情報、その他の個人情報の扱い方は、NC2より進化して改良されていると考えられる。(当然か)

 

この④の件について、何か分かれば前進するかもしれません・・・

 

NC3サイトのバックアップ・リストアについて(3)

 2018年のユーザカンファレンスの「バックアップ」に関する資料に、「大事なファイル3点」という項目を発見!

 

このファイル、ディレクトリ、3つをインストールしたての新規NC3に上書きすれば、いけるに違いない!

と思い、早速やってみました。

引っ越し前の上記すべてのファイルをtarファイルにして、また、引っ越し前mysqlのデータベースはdumpファイルにして、testサーバー機に移動させました。

そして、testサーバーに作成した新規NC3に、ファイル上書き、DBインポートを行いました。

その結果は、残念ながら、アウト!

前回、app / Config フォルダをコピーした時と同じ結果でした・・・

「内部エラーが発生しました」が出てしまいます。

ディレクトリのオーナー、パーミッションも確認しましたが、ダメでした。

もうお手上げです・・・

「ディレクトリ丸ごと移動」という最後の手段があるからいいのかな、とも思いました。

「ファイル全部でもOK」と上記の資料にもありますしね。

ただ、今回、NC2をNC3に移行した時は、同一サーバー(debian8)内で行ったんです。

よって、出来たNC3サイトは php5.6 環境で install したものです。

このNC3サイトを、php7.0(debian9)環境にそのままコピーしてもいいのか? 何とか動いているように見えるだけで良くないんじゃないか? という気もするんです。

この手詰まりの時に、救いの一手を差し伸べて下さったエンジニアがいらっしゃったんです! 

NC3サイトのバックアップ・リストアについて(4)

Netcommons(nc)3サイトのバックアップ・リストア(サーバー引っ越しの時必要!)の正しい方法をアドバイスして下さったのは、株式会社RYUSの代表、天野龍司さんという方です。

天野さんは、Netcommons3のコアプログラムの開発を行っており、また自社で「nc3+ NetCommons3 をより便利に」というNetcommons3プラグイン、テーマその他の開発も行っていらっしゃるエンジニアなんです!

 

実は、昨年、nc2をnc3に移行しようと奮闘していて上手くいかなくて悩んでいる時に、天野さんのブログを発見したんです。

そのブログの中で

「移行ツールでうまく移行できないような特殊ケースとかNetCommons2用に開発したプラグインをNetCommons3に移植したいようなケースがありましたらご相談ください^^;」

とありましたので、こちらは企業でもないのに相談にのってくれるだろうか、と思いながらメールしたんです。

その時、意外にも、こちらのスキルを推し量りながら適切なアドバイスを下さり、とても感激したんです!

結局、その時は、自分にはまだ無理な面があり、移行は成功したのか不明だったのですが、今年の夏に再度移行に挑戦した訳なんです。

nc2→nc3移行にあたりnc2側の準備について、開発元のページには次のように記してあります。

「現状NC2のDB及びNC2のアップロードファイルを取得して、NC3と同じ環境にDBインポート及びファイル配置をしてください。」

ここまでは何とかできたものの、この後移行ツールを実行すると、エラーが出て上手くいきません。

この時、自分はnc2のDB、nc3のDBのログイン情報は違った状態でやっていました。nc2のDBのログイン情報がないとDBに接続できないはずなのに、この情報をどこから引っぱってきているんだろう? と、素人の自分でもさすがに感じていました。

この時の天野さんのアドバイスは、「NC3のDB接続につかってるアカウントでNC2DBにも接続できるようにすると解決するかなと思います。」というものでした。

そうか! nc3のDBをnc2DBの接続アカウントと同じにして作らないとダメなんだ!と、やっと分かりました! 

目の前が開けたような感じでした!

これは専門家には当たり前のことで「NC3と同じ環境にDBインポート」という文に含まれている内容だ、ということなんでしょうね。

このあと、移行ツールは走るようになりましたが、成功しているのか、失敗している部分があるのか確かめる手段も分からず、まとまった時間がないと実験も出来ないので放置してありました。

そしてこの夏、まず、方法、手順、アドバイスをおさらいし直して、徹夜したりしながら、何とかnc3に移行出来たのかな、というところまで来れました!(このサイトは移行して出来たものです)

天野さんからのDB接続についてのアドバイスがなければ、今もnc2からnc3への移行は出来ていなかったと思います。

素人相手に適切なアドバイスを下さった天野さんに、本当に感謝しています!!

 

さて、本題に戻ります。

サーバー引っ越しの時などに必須の作業、nc3サイトのバックアップ・リストアははたして出来るのでしょうか?

 

NC3サイトのバックアップ・リストアについて(5結論)

<ご注意下さい!>

以下の方法は、ver 3.1.10 までのものです。ver 3.2.0 からは、uploadディレクトリの場所が変更されたようです。実験して検証が済みましたら、訂正記事を載せたいと思います。

 

さて、本題の、Netcommons3サイトのバックアップ・リストアがどうやって成功したか、についてです。

繰り返しになりますが、以下の⑥までは以前と同じ内容です。また⑥までがNetcommons2の時と同じやり方です。

 

 ① サイトを閲覧不可にする、又はwebサーバーを停止してから、旧DB3 *** のダンプファイル △△△.sql 作成。

        # mysqldump -u root -p *** > △△△.sql (mysql の root パスワード聞かれるので入力)

 ② files ディレクトリ( app / webroot / files )取得。アーカイブして持ってくる。

 ③ 新環境に新DB3 ○○○ を作成する。

       mysql > create database ○○○ default character set utf8;

  mysql> grant all privileges on ○○○ to ユーザー名@localhost identified by 'パスワード';

  その後、 prefix のみ旧サイトと同じにして、nc3を新規インストール。

 ④ インストール完了したら、mysql にログインして、③の新DB3をいったん削除。

  mysql > drop database ○○○; 

 ⑤ 再度、③と同様にして新DB3○○○ 作成。作成後、旧DB3ダンプファイルインポート。

  mysql > create database ○○○ default character set utf8;

  mysql > use ○○○;

  mysql > set names utf8;

  mysql > source / home / bk / △△△.sql;  (/ home / bk に dumpファイルがある場合)

 ⑥ app / webroot / files ディレクトリを②の解凍ディレクトリと置き換える。

 ⑦ 旧サイトの app / Config / application.yml ファイルを、新サイトに上書きする。

以上の方法で、上手くいきます!!

 

上手くいったのは、もちろん、天野さんからのアドバイスのおかげなんです!

application.yml を上書きしないと、アカウント関係の情報が引っ越し前と違ってしまうので、ログインできない状況になってしまう、と教えていただきました。

そして、新サイトで出来たDB情報を、引っ越し前環境で出来たDB情報に上書きするのはおかしい、ということなんだと思います。なので、旧サイトの database.php で上書きしてはいけません。自分は上書きしてみた後、このファイル内のDB情報を編集してみたりしましたが、エラーは直らずダメでした。

今年のユーザカンファレンスの資料にあった、 「database.php が大事なファイル」というのは、「prefix 情報の確認のために database.php が大事なファイル」という意味で、上書きしなさいということではないのだろうと判断しました。

 

以上の貴重な情報は、すべて天野さんからのアドバイスによるものです!

前回お世話になったので、あつかましくもまたメールで助けを求めてしまいました。

やはり、自分のスキルにあった適切なアドバイスをいただき、本当に感謝しています!

天野さん、有難うございました!!

重ねて御礼申し上げます。

 

最後に、天野さんが注力されている「nc3+ NetCommons3 をより便利に」というプロジェクトについて、ぜひ書いておきたいと思います。

Netcommons3関係のプラグイン、pluguin開発の要望引き受け、Netcommons3レンタル、などの開発をしているとのことで、自分もとても興味が湧きました!

特に、Netcommons3のテーマも開発中とのことで、武骨なデザインのNetcommonsがカッコ良くなるのでは? と自分も期待しているんです!

Netcommons3のバックアップ・リストアのプラグインも、間もなく発表となっています!!

この天野さんのプロジェクトのHPは、以下のリンクからたどってみて下さい。nc3で出来ているのにカッコいいんですよ!

https://nc3plus.com

Debian9サーバー機新調(OSインストールまで)

この夏、ようやくDebian9(php7.0)の新環境にすることが出来ました。

Netcommons2がphp7 では動かないので、(今後もphp7には対応させる予定はないとのこと)Debian8のままでしたが、この夏に、何とかnc2サイトをすべてnc3サイトに移行出来たので、ハードウェアも新調してOSも最新版にすることにしました。

アスロックPentium J5005マザー、メモリー4GB×2、HDDはWDRed2TB×2でRaid1構成とし、OSはDebian9を使うことにしました。

いつものようにUSBメモリでインストールを始めました。

UEFI install の表示が出て、おや? と思ったのですが、そのまま続行。

パーテイション作成では、swap 領域は各 HDD ごとに設け、あとはすべて Raid1領域としました。

インストールが進んでいく途中で、動きが重くなっているような気が。

HDDアクセスledが点滅ではなく、点きっぱなし、HDD のアクセス音も途絶えずに鳴りっぱなしです。

こんなことは初めてで、さらにインストール終了まぎわの grub インストールでつまづきました!

grubがインストールできません!!

調べてみると、UEFI インストールの時、ブートローダーが必要とするディスク容量は、BIOSインストールの時よりかなり大きくなる、つまり今までの「予約容量」では小さすぎる、ということのようです。

Raidを構築する前に、EFI system partition 分をディスクに用意しておく必要があるようです。

ということで、パーテイション作成からやり直しです。

ESP(UEFI ブートローダー用パーテイション?)を、各 HDD に約500MBずつ、

また、swap 領域は各 HDD 8GBずつ、さらに各 HDD に約250MBずつの /boot、/boot2 用パーテイション、を割り当てました。

そして、残りをすべて RAID1 パーテイションとして、再度 OS インストール開始。

やはり、インストールが進んでいくと、はっきりと動きが重くなっています。HDDled も赤く点きっぱなしです。

しかし、今度はインストールは最後まで進みました。

再起動すると、やはり HDD はアクセス動作しっ放しの状況です。

HDD がおかしいのか? もしかして Raid 関係の不具合?

Windows 機で検索してから、proc / mdstat コマンドを打ち込むと、「resync」と「残り時間」の表示が出てきました。

Raid の再同期? Raid 作成後に最初に resync が走るような設定になったんだろう、ということで、

不具合ではないと思ったので、初期設定から少しずつ済ませておくことにしました。

今回は firewall の設定を最初に済ませました。

そして、OSupdate → OSupgrade → SSH設定(sshd_cofig 編集も)→ NTP設定 、と進んで行きました。

ここまでで、Raid resync を終わらせるために、サーバーを動かしたまま寝ることに。

次の日、Raid の resync は終了していて、HDD のアクセス led も通常通りになっていました。ホッと一息。

そう言えば、以前ubuntu16サーバーをインストールしてみた時、動きが重いと感じたのは、この Raid resync が走っていたからかもしれません。 

 

さて、php5.6のセキュリティサポートは、今年いっぱいまでだそうです!

セキュリティ面からも、phpのバージョンアップには付いていかないとダメらしいんです。

ところが!! 何と、php7.0のセキュリティサポートは、今年12/3までなんだって。 えぇ?

php5.6のセキュリティサポート期限の方が、ずるずると伸びていったらしいんですね。

でも、php7.0までにしておけば、OSアップデートでphpのバージョンも上がっていくでしょう。

ちなみにphp7.2は、2020年11/30までのサポートです。

という訳で、今回のサーバー機新調作業となりました。 

Debian9サーバー機新調(完成まで)

OSインストール、初期設定まで終わったので、owncloud、Netcommons を動かせるようにします。

Mariadb → apache2、php その他 → owncloud リポジトリ設定後 owncloud-file 、とインストールしていきます。

前回は、apt-get install owncloud で、mysql 、apache も同時にインストールされたんですが、

DB、Webserverは各自で選んでください、と変更されたようですね。

・・・白状しますが、Web検索で見つけたコマンド文を、コピペでSSHクライアントに貼り付ける、というセコイやり方を覚えてしまいました!  (SSHクライアントはRloginを使っています)

apache バーチャルホストの設定ファイル、DDNS の cronjob ファイルも、旧サーバーから持って来てしまします。

owncloud は、ssl 通信になるように設定することが重要だと思います。

この時の ssl 証明書は、自己証明書を作ったり、Let's Encrypt を使ったりしていたのですが、

OSから再インストールし直す機会が多くなってしまったのと、また、ほとんど自分専用ということもあり、

OS内の snakeoil 証明書を使うという安易なやり方にしちゃっています。(ファイルアップロードダウンロードの機能を貸し出す時だけ、アクセス時に警告が出ることについて、事情を説明しています)

旧 owncloud 内のユーザデータは、引っ越しではなく、owncloud-client でクライアントに保管してあるデータに再同期させて新owncloudに取り込むやり方にしています。

owncloud のインストールが終わったら、Netcommons3のインストールに進みます。

また、Netcommons3の引っ越しは、今回はディレクトリ、ファイル全部を持ってきましたが(DBは別に引っ越し)、次からは教えていただいた方法で実行できます!(本当に感謝です!)

もう一つ、php5.6 と php7.0 では、計測してはいないのですが、php7.0 の方がかなり早くなっているような気がします。

 

さて、最後に、旧サーバーではどうだったっけ? と、旧サーバーを覗きに行かなきゃならない場面もしばらくは出てきます。

IPアドレスを別々にして、新旧とも動かしながら作業するのがいいと思ったんですが、

今回は、IPアドレスは新旧同じにしたまま、必要な方だけ電源を入れて切り替えるというやり方で何とかなりました。SSH は旧サーバーのみ鍵認証を切って使いました。

 

こんな感じで、かなり省力化(手抜き?)したやり方なんですが、今後とも、特にOS等の基盤は最新の状態にしておかなければならないので、今後もOSから再インストールという機会は少なくないと思っています。

やり直さなきゃいけない、という状況になった時、身軽に動けるようにするため、とい言ったら怒られるでしょうか? 

php7.0セキュリティサポート終了

以前書いたように、php7.0は、php5.6より一足先にセキュリティサポートが切れてしまいます!

今すぐ不具合が生じることはないと考えますが、年末までにはphp7.2環境にしてしまう予定です。

でも、多分、何か所かハマリそうだし、時間がかかるでしょう。

はたして年末に時間がとれるか?

しかし、どうせやるなら、HDDミラーリングもやめて、SSD1台にしてしまおうと無謀な計画を立てています。

これにOSクリーンインストールからやってしまいます!

さあ、出来るかどうか? いつ出来るのか・・・

php7.3最新環境への引っ越しは・・・まだ何とも言えない

現行サーバーのハードウェアを変更し、

そこにdebian9、php7.2環境を構築し、

そこに現在のwebページ3つを引っ越しする。

という計画ですが、

ついさっきまで、TESTサーバー機にdebian9、php7.3環境を構築するところまでは出来ました。

そこにNetcommons3をインストールしようとしたところ、Mariadbへの接続でつまずきました。

明日も朝から早いので、残念ながら今日はここまでです・・・

php7.2環境への引っ越し完了!

昨日まで、この自宅サーバー(debian9)は、php7.0環境でしたが、

php7.0は、アクティブサポート、セキュリティサポート共に、12/3に終了していました。

これを何とかしたかったのですが、せっかくなので、OS新規installからやることにしました。

ついでにHDDミラーリングをやめてSSD1本に。

SSDが壊れるリスクについては、定期的なバックアップで対応しようということに。

特にowncloudでは複数のクライアントが繋がっているので、これらのファイルがバックアップになります。

また、最近リリースされたphp7.3もテスト機で試してみましたが、急に不具合が出る可能性もあり、

普段の時間がない時には対応が出来ません。

php7.2は、アクティブサポートが2019年11/30、セキュリティサポートが2020年11/30 までで、まだ余裕があります。

ということで、debian9にphp7.2以降のリポジトリ設定をしてから、php7.2環境を作成しました。

そのあとは、php7.2モジュール、apache2、mariadb、とインストールしていき、割とスムーズに作業が出来ました。

ただ、SSDのパーテイション作成で、マザーボードがBIOSではなくUEFIだったので、UEFIbootパーテイションをあらかじめ作っておく必要がありました。(Windowsインストールなら特に意識しなくていいのかも)

サイトの引っ越しは、以前教えていただいて勉強しておいた方法を再確認しながら進めました。

Netcommonsの内部構造が変わった部分はそれに合わせてバックアップ、リストア方法を変更しましたが、うまくいったようです。

現在、SSDの動きはさすがに早いのですが、以前の高速化の対策がまだ反映されていません。

徐々に対応していこうと思っています。

Netcommons3アップデート作業は、基本に忠実に

Netcommons3もver.3.2.2 まで来て、動作も含めて、大きく改善されてきたと感じます!

これからも、ユーザサイドでアップデート作業を継続していかなければなりません。

ほぼ2か月に1度のペースで発表されるアップデートですが、作業の細かい点をどうしても忘れがちです。

結果オーライに安心して、バックアップ作業を省略したりもしていました。

しかし、突然何かアクシデントがあった時に対応できるよう、やはり基本に忠実に作業しておかないといけませんね。

何となく作業していたのでは、このwebサイトを失う原因にもなりかねません!

そこで、作業手順を細かく記録しておくことにしました。

 

<事前準備・バックアップディレクトリの作成>

 # cd /home

 # mkdir 20190126bkup

<事前準備・最新ファイルの用意>

(1)https://www.netcommons.org/NetCommons3/download より、

最新ファイルを取得して、例えば /home に配置

(2)(1)のファイルを解凍。

 # cd /home

 /home# unzip NetCommons-3.2.2.zip

解凍ディレクトリ NetCommons3 が生成されます。

(3)解凍ディレクトリをリネーム(後でバージョン等不明にならないように)  

 /home# mv Netcommons3/ nc322/

<対象NC3サイトを、閲覧不可にする>

メッセージ文は前もって書いておくと良い

<アップデート前のバックアップ>(自分は、OS、mysql 共に root ユーザで作業しました)

(1)データベース 〇〇〇 のバックアップ(バックアップファイル 〇〇〇.sql 保管先/home/20190126bkup)

 # cd /home/20190126bkup

 # mysqldump -u root -p 〇〇〇 > 〇〇〇.sql 

 (mysql root のパスワードを入力)

(2)ソースのバックアップ(バックアップ先 /home/20190126bkup)

 # cp -r /var/www/NC3インストールディレクトリ/app/Config /home/20190126bkup/

 # cp -r /var/www/NC3インストールディレクトリ/app/Uploads /home/20190126bkup/

以上のバックアップがあれば、アップデートに失敗しても、最悪、アップデート前の状態には戻せます。

インストールディレクトリ全部のバックアップでもいいと思います。

<Netcommons3本体のアップデート>

(1)リネームディレクトリ下のファイル、ディレクトリを、既存NC3インストールディレクトリに上書き

 /home# cp -r nc322/* /var/www/インストールディレクトリ/

上書きが終わったら、上例のnc322ディレクトリは、例えばhokanディレクトリ下に移動等しておく。

(2)cakeコマンド実行してアップデート

 # cd /var/www/インストールディレクトリ/app

 ・・・/app# Console/Cake PluginManager.update_all 

 画面に「一括アップデート」が表示されるので、画面の指示どおり、S を入力してEnter

 アップデート処理中、ざっと眺めておく。エラーは黄色表示になるはず。

(3)インストールディレクトリの所有者を「webサーバー(debianならwww-data)に戻しておく。

 # chown -R www-data:www-data /var/www/インストールディレクトリ

<サイトをブラウジングして確認>

外部PC等から、アップデートしたサイトにwebアクセスして、ログイン等出来れば完了です! 

Netcommons 3.2.1.1 から 3.2.2 に update した時の不具合 

Netcommons 3.2.1.1 から 3.2.2 にアップデート作業を行いました。

手順に沿って、ていねいに作業し、問題なく完了したように見えていました。

ところが、カミさんのスタジオのホームページに問題発生!

カレンダーに日程の書き込みや編集をしようとすると、「内部エラーが発生しました」となり、操作できないとのこと。

慌てて、3つ作ってあるNetcommons3サイトをすべてチェックしてみたところ、さらに不具合を発見!

管理ページでの、会員管理、権限管理、会員項目設定、の各操作をしようとすると、「内部エラーが発生しました」となり、この3項目は操作できないことが分かりました。

現在のこのサーバー環境は、Debian9、apache 2.4.25、Mysql 10.1.37、php7.2 です。

 

さて、検索したり、Netcommons3の掲示板を見たりしましたが、手掛かりがつかめません。

そこで、公式サイトにユーザ登録して、トラブル報告として書き込ませていただきました。

以前、Githubに書き込んだ時には、全く応答してもらえなかったので不安でしたが、

今回は、1時間後には、対応策を書き込んで下さっていました。

その対応策に沿って修正作業してみたところ、見事、一発で、すべてのエラーは解消しました!

対応のアドバイスを下さった、牟田口様、天野様、本当にありがとうございました!!

 

この件の詳細について書いておこうと思います。

Netcommons3.2.1.1 の時に、サイトの引っ越しをしていました。

この時、引っ越し先の自分の新調サーバーは、 php7.2 環境にアップしてあり、

まずは、このサーバーにNetcommons3.2.1.1 の新規インストールを行う必要がありました。

その際、php7.2に対応させるために、app/Plugin/Migrations/Lib/CakeMigration.php ファイル17行目の「Object を CakeObjectに書き換える」作業が必要でした。

これで出来たNetcommons 3.2.1.1環境に、php7.0で動いていたNetcommons 3サイトのバックアップからのリストアを行った訳です。

そして今回は、Netcommons 3.2.2 は php7.2 にすでに対応しているだろうから、CakeMigration.php ファイルの修正はせずにアップデート完了するだろうと思い込んでいました。

しかし、Netcommons 3.2.2 のCakeMigration.php ファイルは、まだ php7.2 には対応していなかった、ということでした。

対応していなかった理由は良く分かりませんが、レンタルサーバーの多くは、まだ php7.1 あたりなのではないか、とか推測しています。

考えられる多くの環境があるでしょうから、そのどれに対応させるのか、判断が難しいのかもしれません。

または、本当に忙しくて、全ての対応に手が回らない、ということもあり得ると思います。

いずれにしても、これからも、すんなりといかない場面が多く出てきそうですから、

こちらも一生懸命やりながら、多くのエンジニアの方々に助けてもらっていかなければならないと思っています!

Netcommons(ネットコモンズ)3のこと

このサイトのシステムであるNetcommons(ネットコモンズ) は、国立情報研究所が開発するWebシステムです。

CMSとグループウェアの機能を持っています。

 

具体的には、Netcommons で Web サイトを構築することができますが、

これで作成した Web サイトは、掲示板、ブログ、回覧板、アンケート、小テスト、動画掲示板、カレンダー、フォトアルバム、その他のコンテンツ、を表示させ、機能させることが可能です。

これらを機能させるプラグインの使用権限を設定し、複数の関係者がこれらのプラグインを使って、

サイト内の色々な部分を、分担して構築できるようになっています。

1人の専門家だけに全ての構築を任せる必要がなくなる、というメリットがあります!

これが、CMS(コンテンツマネージメントシステム)の機能です。

このような特徴は、色々な部署を持つ企業や学校などのWebサイト構築に向いている訳です。

 

また、特定のグループに掲示板の内容を配信したり、上記のプラグインの機能を利用させたり出来るシステムが、グループウェアです。

複数の各グループ毎に、異なった内容の運用をさせる事が出来る訳です。

 

さらにこのソフトウェアは、オープンソースなので無償で使用することが出来ます!

自分は、無償OS Debian上に、このNetcommonsをインストールしているので、ソフトウェアにかかる費用はゼロです 。

また、この「実験と魚料理」は個人的なサイトなので、構築は全て自分1人でやっています。

 

さて、Netcommonsは、このような特徴のおかげで、学校やNPO、自治体や中小企業などに急速に広まっています。

埼玉県内の学校のWebサイト(ホームページ)にも、広く活用されています。

ただ、埼玉県内の学校のサイトでは、まだ Netcommons2(旧バージョン)のままです。

自分のこのサイトは、 昨年8月に Netcommons2 から Netcommons3 へ移行作業を行いました。

特にNetcommons3サイトは、スマホでアクセスしてみると分かりますが、違和感なくブラウジングが出来、

応答も速く、表示もとてもきれいになっていることが分かります!(レスポンシブデザイン)

また、セキュリティ対策が非常に強力に施されています。

 

ここに来て、ようやく埼玉県立高校のWebサイトも、Netcommons3にバージョンアップされそうな気配です!

現在の Netcommons2サイトと、バージョンアップ後の Netcommons3サイトを見比べると興味深いと思います。

埼玉県立高校のWebサイトがバージョンアップされたら、お知らせしようと思います。 

先ほどの、Webサイト不調のお詫び

先ほど、このWebサイトのOSのアップデートを行ったところ、

珍しく再起動が必要な状況でした。

そこで、大変申し訳なかったのですが、予告なくOSの再起動を行い、同時にルーターの再起動も実施しました。

全作業4分間ほどでしたが、再起動後のWebサイトの挙動から判断して、

この時間にファイルのダウンロードも含めて、アクセスしていた方がいらっしゃったようです。

大変申し訳ありませんでした!

以降、再起動のタイミングについては気を付けて行うよう、注意致します。

Webサイト apache バーチャルホスト設定ファイルの再読み込み

先日15日に、このWebサイトを動かしているOSの再起動を行った際、

Webサイトの応答が目に見えて悪くなりました。

そこで、Webminからの操作でapache本体の再起動を行い、何とかしのいでいました。

ところが、今日に至るまで、Webサイトの応答速度が悪いままでした。

そこで、apache バーチャルホスト設定ファイルの再読み込みを試してみました。

 # a2dissite 〇〇〇

 # systemctl reload apache2

 # a2ensite 〇〇〇

 # systemctl reload apache2

この間、一瞬Webサイトは停止しますが、ほぼ問題なしと思います!

さて、現状このサイトの応答はどうでしょうか・・・

サーバー機メインメモリー増設

今日の早朝、サーバーマシンのメインメモリを増設しました。

4GB × 2 を 8GB × 2 に交換する作業です。

このマザーボードの Pentium Silver J5005 の最大メモリー容量は 8GB なので、無意味に思えます。

また、このマザーボードのマニュアルにも、最大メモリー容量 8GB が記載されています。

ところが、 メモリーサポート一覧表には 16GB が記載されていて、実際にこの容量で動かしている例も紹介されています。

また、今までの計8GBの運用では、キャッシュを含めてほぼメモリー容量を使ってしまっている状況でした。

見にくくてすみません。6.48GBcashed、7.64GBtotal という部分です。

期限の切れそうな固定Tポイントがあったので、これで新たにメモリを入手して、試してみることにしました。

さて、現在は計16GBのメモリがマザーボードには認識されている状況なんですが、

ハードウェア、ソフトウェア共にこの16GBの容量を活用してくれるのかを観察している段階です。

お風呂で音楽を聴くための Windows10マシン

自宅の1Fに、ラジオサーバー(現在NHKラジオ自動録音機)として日中稼働させている省電力PCがあります。

このPCにbluetoothアダプターを付けて、2Fの浴室でbluetoothスピーカーからの音楽を聴こうとしていました。

しかし、この距離では残念ながらbluetooth接続が出来ませんでした。

そこで、2Fに音楽専用小型PCを作り、これにbluetoothアダプターを取り付けることにしました。

有線ネットワークを使って、このPCを1Fの自分のメインPCからリモート接続でコントロールしようという試みです。

2FのPCにディスプレイ、キーボード、マウスを付けていれば、1Fからリモート接続なんて不要なんですが、

2FにPCを置くと怒られそうなので、2Fの押し入れにPC本体を閉じ込めて使う感じなんですね!

このPCは、浴室で音楽を聴く時だけ稼働させます。

ということで、低スペックながら余ったパーツ(もちろん省電力仕様)でPCは組み立ることにして、

OSのWindows10pro(proでないとリモート接続できない)をどうやって入手するかが、悩みどころなんです。

まともにパッケージ版とかを購入すると、DSP版(ハードウェア同時購入版)でさえ結構な値段です。

そこで、まずMicrosoft社のWebサイトから、Windows10のインストールファイル(ツール)をダウンロードします。

そのファイル(ツール)からインストールUSBメモリを作成します。

作成したPCの起動順位をUSBメモリ第1に設定してから、このインストールUSBメモリでWindows10をインストールします。

ここまでは、実は簡単なんですね。

自作PC、メーカー製PCにWindows10をクリーンインストールしたくて困っている人がいたら、周りの詳しい人に聞いてみて下さい!

もちろん、自分からもアドバイスはできますよ!

で、最後に必要なのは、Windowsのライセンスキーなんです。

実はこのライセンスキーを以前Amazonで格安で入手したことがあるんです。(正規認証品です)

最近見かけなくなったと思っていたら、yahooストアにありました!

これも正規認証品ということを確認してから発注しました。

届くのは、メール文で送られてくるプロダクトキーだけです。

しかし、最後にプロダクトキーを入力すれば、キチンと正規認証されたWindows10PCが出来上がるんです!

Windows7、8 のサポート終了期限など

Windows7 は 2020年1月まで、Windows8 は 2023年1月まででOSのサポートが終了されます。

Windows に限らず、どんなOSもサポート終了後は使用しないのが原則です。

その最大の理由は、セキュリティ面のリスクです。

自分のシステムやファイルはもちろん、自分以外の他のユーザにも被害が及ぶことが考えられます!

現在のPCは、ネットワークにつなぐ前提で動かされていますので、

ネットワーク経由でのセキュリティリスクは、色々と言われている通りで、無視することは絶対にできません!

そこで、Windows なら、最新バージョンの Windows10にアップグレードする、ということになるでしょう。

さて、すごくザックリと言ってしまえば、Windows 7,Windows 8 が動いているマシンなら、動きが悪くなることはほぼないと思います。

自分のケースですが、Windows 7環境を Windows10環境にして、動きがむしろ良くなりました!(それもはっきりと)

アップデートして使えなくなるソフトもごくわずかあるようですが、自分は割り切ってあきらめました。

代替ソフトも探せる場合があります。

 

では、 Windows10 にアップデートする決心がついたら、次はどうやってお金をかけずにアップデートするかです。

実は、Windows 7,Windows 8 の正規ライセンスを持っていれば、 Windows10 にへの無償アップグレードは、まだ可能なんですね。

 https://applica.info/windows10-upgrade

この記事を参考にして下さい。

また、こだわる人のために、 Windows10 をクリーンインストールする手もあります!

最後に、Windows 7,Windows 8 のライセンスを持っていない人。

安価に何とかする手があるようですよ!

 

やっかいなことですが、これからも、常に最新版のOSを使うようにするしかないんですね!

あ、スマホしか使ってない人は、スマホのOSである、iOS、AndroidOSのバージョン等に気を配って下さい! 

今後のNetcommons3の利用について

ここ数か月、Netcommons3のバージョンアップの状況、またフォーラム等を見ていて、

当初とは状況が変わってきている感じがしていました。

2か月に1度程度行われるはずだったバージョンアップも、今年1月からピタリと止んだままです。

不安を感じながら、今年のユーザカンファレンス関係の情報がないか気にしていました。

先日のカンファレンス終了後の主催者とユーザーのやりとりを一部読むことが出来ました。

 

それについての感想ですが、

現在のNET環境、特にWeb上で多くの個人情報を扱うグループウェアが置かれる環境では、

セキュリティ対策が非常に重要で、これについての対応がどんどん難しくなってきている。

しかも、その対応自体も、年々変えていかなければならない状況でしょうから、容易ではないことは明白です。

これを実現させるために、多くの技術者や予算の確保が必要だと思われます。

まず、この点が難しい状況になってきているという感じがしました。

さらに、レンタルサーバーを使うにせよ、個人でWebサーバーを構築するには厳しい環境になってきている。

システムとサーバー、セキュリティやネットワークの管理は専門業者に任せるSaaSというサービスを使うべきだとの指摘です。

このような、プロジェクトリーダーからの指摘がなされたので、今までのようなアップデートパッケージ版の配布が止まったようなんです。

こんな風に、Netcommons3の利用についての方針が急に変わってきてしまいました。

個人的には、まだ良くのみ込めていないし、どう対処していいのか、戸惑っているところです。

 

一応、次のようなアナウンスはされています。

最新版はNetCommons3としてGitHubから自由にダウンロードし、どなたでも利用することができます。

管理者にはGitHubから最新版のNetCommons3を都度ダウンロードし、パッケージ化して利用して下さい。

この自宅サーバーのセキュリティー対策は?

自分が使っている自宅サーバーのセキュリティー対策はどうなっているのか、書いておく必要がありそうです。

まず、OSですが、現在はDebianの最新版を最小構成でネットワークインストールしたものを使っています。

使わないソフトは入れず、必要なソフトはその都度追加する方法です。

また、apt コマンドでインストールできないソフトは、リポジトリを登録してからインストールしています。

こうしておくと、apt update コマンドでアップデートのチェックがすぐに行えます。

Netcommonsだけは手動インストールによっているので、Netcommonsのみ手動で最新バージョンにアップデートするようにしています。

また、光回線とつながるルーターからサーバーへは、ポートフォワーディングによって指定されたポートの信号のみ転送しています。

さらに、ファイヤウォールによる設定で、数個のポート以外のポートは全てブロックしています。

SSH等のリモート接続は、ローカルのみ、つまりマイクライアント以外は接続出来ないように設定してあります。

FTPは最初からインストールしていません。

大雑把にはこんな感じなんですが、

運用を初めてから、毎日のようにチェックしているのは、OSとアプリケーションソフトのアップデートです。

アップデート通知が出ていれば、すぐにアップデート作業を行っています。

セキュリティアップデートのみは自動にする手もあるんですが、

以前apacheのアップデートを行った時、Webサイトが停止してしまったことがあったので、手動でアップデートし、不具合が出たらその時点ですぐ対応するようにしています。

また、ベースのOSに新バージョンが発表されたら、

使用しているWebアプリケーションが動作するか調べて、OKなら、出来るだけ早く新バージョンのOS環境にします。

最近はphpのバージョン対応に注意する必要があります。phpのバージョンアップの方がどんどん先行している感じです。

新バージョンOS環境にする時は、ストレージは新調してOSの新規インストールからやり直します。

この時、Webサイトはデータベースも含めて引っ越し作業を慎重に行います。

また、同時にハードウェアの点検もして、マザーボードその他も一新することもあります。

こんな感じなんですが、自宅サーバーでセキュリティ対策が手に負えなくなってきたら、SaaSのようなクラウドサービスについて考えようとは思っています。

Netcommons3 git composer によるアップデート作業を何とか覚えたい・・・

現状では、Netcommons3 のアップデート作業が今までの方法では出来なさそう(もしくは対応が遅れそう)なので、

 https://github.com/NetCommons3/NetCommons3/wiki/NetCommons3開発ドキュメント

の中の、「NetCommos3をcomposerでインストール」を一生懸命読んで、必死にチャレンジしていますが・・・

自分の力量では、まだまだ追いつけません。

git、bower のインストールまで終わり、リポジトリのクローンまでは出来ましたが、まだ先が見えません・・・

Windows 10大きなアップデート?

自分のWindowsクライアントも、起動させると毎回アップデートチェックを行っています。

昨日もアップデートのダウンロードがあり、インストールが終わってから使おうと思っていたら、なかなか終わらない。

じゃあ、先にご飯食べちゃおうと、リビングに行ってスイカも食べて戻ってきたんですが、何とまだ終わってない!

その後、風呂から出てきても、まだ延々とアップデート作業が続けられていました!

自分はアップデートを溜めてしまうことはなく、すぐに完了させるようにしているので、今回のアップデートが非常に大きかったことになります!

今回のように、アップデートが数時間もかかるような場合、最初から分かっていれば対処できますが、

突然アップデート作業に入ってしまった時は、とても困ることがあるんじゃないでしょうか?

この間、クライアントでの作業が自由には出来ない訳ですから。

今回の Windows10の大型アップデート、早めに余裕を持って作業されるようにした方がいいと思います!

Debian9の php7.2アップデートは・・・

Debian9のデフォルトの php は ver7.0で、セキュリティサポートは2018年12月に終了しています。

このサーバーのOSは Debian9ですが、php7.2(セキュリティサポート 2020.11まで) を別途インストールしています。

この方法ですが、まず、packages.sury.org/php から gpg キーを取得し、apt-key コマンドでサーバーに取り込みます。

次に、/etc/apt/sources.list.d にリポジトリ設定を書き込み、apt-update、さらに apt-install php7.2 でインストールできます。

ところが、最近 apt-update を実行すると、「gpg キーが有効になっていない」というエラーが出て php のアップデートが完了しなくなってしまいました。

これについての対応は、取得先から最初と同じように gpg キーを再度取得し、apt-key で再度サーバーに取り込めばいいようです。

このあと、apt-update、apt-upgrade、を実行すれば php7.2が最新版に更新されます。

他のモジュールやアプリケーションなども、gpg キーを取得しているものはキーの有効期限があるようですから、キーを再度取得すると上手くいくかもしれません。

すでにDebian10安定版が発表されていて、php7.3(セキュリティサポート 2021.12まで) がデフォルト搭載されてもいるので 、早くこの環境にしてしまいたいんです。

ところが、owncloud、Netcommons3共に php7.3にはまだ対応していないようです。

これらの対応が完了したら、出来るだけ早くDebian10の最新環境に更新する予定です!

自分の趣味はアップデートです? ・・・

この前 Windows10 の大型アップデート1903が配信されて、常用クライアント機のアップデートに数時間かかってしまいました!

ラジオサーバー機、風呂音楽用サーバー機は、ほっときながらアップデートしたので、それほど気にはなりませんでしたが。

それなのに、この更新は CPU 使用率が異常に高くなるという問題を抱えたままなんです。

そして、この問題を解消するアップデートはまだ配信されていません。(まもなく配信されるらしい?)

Web サーバー機の Debian9 も次期 Debian10がすでに発表されていますが、使用アプリケーションの php7.3対応が完了すればアップグレードしたいと思っています。

もちろん、Debian9で配信されるアップデートは、毎日欠かさずチェックして更新しています。

そして、スマホの iOS ですが、昨日寝ている時間にダウンロードを済ませ、iOS 13.1にアップデートしました。

アップデートにもバグや動作不具合はつきものです。完全を待ってから!なんてことは実際無理だと思った方がいいです。

なので、アップデートが発表されたら、基本、「すぐにダウンロードしてインストールする、でOK!」と思います。

自分は、アップデート操作は、素人に出来るセキュリティ対策の基本だと考えています。 

iOS13.1配信の3日後に、iOS13.1.1が配信されています!

iPhone、iPad 用のOSである iOS13.1が配信されて、早くも3日後に修正版の iOS13.1.1が配信されました。

動作不具合のバグ修正のためのアップデートとのことです。

このタイミングなら、修正版の配信を待っても良かったことになりますが、最近はこのようなケースは珍しくありません。

特にOSのアップデートは、やはり、毎日チェックすることを習慣にしておくのがいいと思います。

そして、今回のようにアップデートに時間がかかる場合は、作業は週末にやるとかの対応でいいんじゃないでしょうか。 

Netcommons3最新版パッケージが発表されるようです!

本日、Netcommons3最新版が近日中にリリース予定との発表がありました!

今後、一般ユーザーが、個人でNetcommonsをインストール、アップデートすることが難しくなるのか? または全く出来なくなるのか?

とても気になっていたので、本日の発表を知ってとても嬉しい気持ちです!

このプロジェクトリーダーとスタッフの方々、そして開発エンジニアの方々に感謝の気持ちをお伝えしたいと思います!

NetCommons3.3.0がリリースされました!!

待ち望んでいたNetCommons3の最新版が、ほぼ9か月ぶりにリリースされました!

NET環境も、特にセキュリティ面での対策を筆頭に、非常に細かい対応が必要になり、また状況が日進月歩で変化していくようですから、システムをメンテナンスしていくことは想像以上の苦労があると思われます。

自分のような末端ユーザーは、その恩恵にあずかることしか出来ず申し訳なく思っています。

そんな中での今回の最新版発表は特に嬉しく、有り難さを強く感じました!

台風が来た12日の朝に発表されていましたが、12日は家に閉じこもっていたので、その日にアップデート作業を行いました。

一応、以下が備忘録です。 

 

※ OS、mysql 共に root ユーザで作業の場合です。不可ならsudoコマンドを付加して。 

<事前準備>

 (1)バックアップディレクトリ等作成。

   # mkdir -p /home/hokan/20191013bkup

 (2)最新NC3zipファイルをクライアントPCにダウンロード。

 (3)webサーバーOSに(2)のダウンロードファイルをアップロード。

 (4)(3)のファイルを解凍。

 (5)解凍ディレクトリをリネームしておく  

   # cd /home/hokan/20191013bkup

   ・・・/20191013bkup# unzip NetCommons-3.3.0.zip

   ・・・/20191013bkup# mv NetCommons3/ nc330/

 

<アップデート前のバックアップ>

 (1)対象NC3サイトを閲覧不可にしておく。

 (2)データベース $$$ のバックアップ(バックアップファイル &&&.sql 保管先/home/hokan/20191013bkup)

   # cd /home/hokan/20191013bkup

   ・・・/20191013bkup# mysqldump -u root -p $$$ > &&&.sql

    (mysql root のパスワードを入力)

 (3)ソースのバックアップ(保管先 /home/hokan/20191013bkup)

   # cp -r /var/www/NC3インストールディレクトリ/app/Config /home/hokan/20191013bkup/

   # cp -r /var/www/NC3インストールディレクトリ/app/Uploads /home/hokan/20191013bkup/

 

<Netcommons3本体のアップデート>

 (1)対象NC3サイトは閲覧不可にしたままで。

 (2)リネームディレクトリ下のファイル、ディレクトリを、既存NC3インストールディレクトリに上書き。

   ・・・/20191013bkup# cp -r nc330/* /var/www/NC3インストールディレクトリ/

 (3)cakeコマンド実行してアップデート

   # cd /var/www/NC3インストールディレクトリ/app

   ・・・/app# Console/cake PluginManager.update_all

   画面に「一括アップデート」が表示されるので、画面の指示どおり、S を入力してEnter。

   アップデート処理中、ざっと眺めておく。エラーは黄色表示になるはず。

 (4)インストールディレクトリの所有者を「webサーバー(debianならwww-data)に戻しておく。

   # chown -R www-data:www-data /var/www/NC3インストールディレクトリ

 (5)常用クライアントPC等から、アップデートしたサイトにアクセスして、ログイン出来ることを確認。

    サイトを閲覧可に戻して作業完了です! お疲れさまでした! 

 

  ※ 関係者の方々、特に膨大な作業によって最新パッケージを作成して下さったエンジニアの皆様に感謝申し上げます!

   今後とも、どうかよろしくお願いいたします!

Nextcloud17のインストール、アップデート等の方法を調べています

owncloud から Nextcloud へ乗り換えを検討中です!

・・・で、今ほとんど書きあがっていた内容が、タイムアウトして消えてしまいました!

時間をかけて書き込む際は、時々「一時保存」しましょうね・・・!

明日、もう一度書きたいと思います。

ちょっとだけ付け加えておきたいと思います。

昨日、owncloud 10.2 から 10.3 へアップデート作業している時に上手くいかなくて、かなり焦りました!

それと、Debian10、php7.3環境へのアップグレードも検討中だったということもあります。

まずは、実験機で一からインストールして試してみないとダメだなと思っています。

Nextcloud と owncloud

Nextcloud は、owncloud を生んだエンジニアがフォークして新しく作りあげた、オンラインストレージサービスを実現させるWebアプリケーションソフトです。

owncloud も当初はオープンソースソフト(OSS)でしたが、有償のエンタープライズ版が無償のコミュニティ版と共に作られ、コミュニティ版は追加機能が削られていきました。

Nextcloud 社は、元々 owncloud 社が持っていた OSS の精神を大切にしたいという想いから新たに設立されたようです。

また、追加機能の実装についても Nextcloud の方が先を行っているようです。

こんな感じなので、個人ユーザは Nextcloud を是非とも使いたいところです!

ただ、Nextcloud は、まだ日本語化されていません。(日本語データを扱うことはもちろん出来ます)

興味深い情報として、「snapコマンドによるインストール」がありました。

これは、Debian だと apt のようなインストール関係の作業を管理するコマンドのようです。

このsnapコマンドを使うと、Nextcloud のインストールでは、apache、mysql、php のインストールと環境作りまでもやってくれるようなんです! 

ここら辺の検証も含めて、実験機でDebian10のインストールからやってみようと考えているところです。

Netcommons3.3.0の検索ボックスの挙動

現在、このサイトに限らず、Netcommos3で作られたサイトの検索ボックスの挙動がおかしいようです。

iPhone からのタイピングでは、例えば通常のローマ字入力モードで「ネット」と入力するために「netto」とタイピングすると、以下のようになってしまいます。

 

この症状をNetcommons3公式サイトのヘルプデスクに報告してあります。

以前、Youtube の検索ボックスでも同様の症状が発生したらしいです。

ただ、Netcommons3のエンジニアの方々はかなり忙しいようで、改善されるのはまだ先になるかもしれません。

 

もう一つ別件ですが、埼玉県立の各高校の Web サイトもNetcommos3にバージョンアップされたようですが、動きが非常に悪い状態のようです。

これは、埼玉県の Web サーバー側で対応しないといけない問題だと思います。

1校あたりの Web サイトへのリソースの割り当てをもっと増やすべきなのでは?

具体的には、リソース中のメモリ量を増やし、webサーバー、データベースがもっと多くのメモリを使えるようにするといったことではないかと感じています。 

設定変更のためWebサイト一時不通になりました。すみません!

光BBユニットの接続設定のため、Webサイトがお昼を前後して一時不通になりました。

申し訳ありません!

NTTの光回線はそのままで、明日2/4にプロバイダをニフティからソフトバンクに切り替えます。

スマホ等のモバイル通信と自宅での固定光回線を同一業者のサービスにした方が、毎月の費用が抑えられるからです。

明日以降は、ソフトバンクのBBユニットで、有線ルーター機能、Wifiルーター機能、そしてWebサイト公開のためのポートフォワーディングの機能と、3つの機能を働かせるんですが、やってみないとどうなるか不明なところがあります。

また明日ハマってしまって、長時間費やすかも・・・

特にWebサイト関係で、出来るだけ迷惑をかけないようにしたいと思っています。

プロバイダ切り替え完了

本日、プロバイダをNiftyからSoftbankに切り替えました。

本日も、Webサーバーが一時不通になったことをお詫びいたします。

一応、これで設定は完了したので、以降、Webサーバーにも安定してアクセスが可能と思います。

 

さて、今までのプロバイダNiftyの環境では、NTT回線の光終端装置にルーター機能がセットになっているPR-400NEが提供されていました。

この装置にUser設定を加えていたので、変更はスムーズには行かないかもしれないと思っていました。

そこで、行き帰りの通勤で歩きながらあれこれと考えてはいたんです。

さて、本日プロバイダの切り替えの日だったんですが、手順書通りにやっても案の定うまく行きません!

まずは、以前のNiftyのアカウントでNET接続しているので、これを消さないといけないんですが、PR-400NEの初期化にちょっとコツが必要でした。

初期化スイッチをかなり長い間押したままにしておかないとダメなんです。

さて、次の盲点だった所です。

SoftbankのBBルーターが切り替えに先立って届いていたので、すぐに接続してWifi機能だけ使っていました。

そして、当初PR-400NEにはルーター機能もあったので、IPアドレスは「192.168.〇.1」を割り振ってありました。

そこで、BBルーターには「192.168.〇.2」を割り振ったんです。

切り替えの前日までは、これでNiftyの接続は問題なく利用できていました。

そして今日、PR-400NEを初期化してこれは終端装置だけになったので、これでインターネットに繋がるはずでした。

ところが、有線LAN内のPC、そしてwebサーバー、全部インターネットに繋がりません!

でも、この時点で、Wifi接続のスマホはインターネットに繋がっているのを発見できたのは幸いでした。

すると原因は、有線LAN内の設定も含めた不具合だけに特定できます。

しばらく考えて、そうだ! と気付きました。

有線LAN内のPCはすべて固定IPを振ってあって、ゲートウェイを以前のルーターの「192.168.〇.1」に設定してあったんです。

新ルーターのIPは「192.168.〇.2」に設定したのでした。

ですから、LANから外のWANに出ていくゲートウェイが無い状態だった訳です。これではインターネット接続は出来ませんよね。

そしてもう「192.168.〇.1」は使われていないので、再度、新softbankルーターのIPを「192.168.〇.1」に設定し直しました。

さあ、新ルーターを再起動して・・・

やっと、有線LAN内のPCもすべてインターネット接続出来ました!

最後は肝心のWebサーバーです。

新ルーターにポートフォワーディングの設定をし、サーバー内の自動実行スクリプトを手動で走らせて、DDNSサービスの提供先に現在のIPアドレスを知らせておきます。

これをやらないと、サーバーがキチンと外部アクセスを受け付けているか、すぐには調べることが出来ないんです。

さて、結果はどうでしょうか?・・・

ここまでの作業で、ようやく我が家のインターネット環境がすべて正常になりました!

やれやれ! これで一安心と思ってコータの散歩に出かけたんですが、ふと心配になって我が家の固定電話に電話をかけてみました。

呼び出しはしてるのに、家の電話機は呼び出し音鳴ってない様子!

散歩から戻って、再度設定を調べてみました。

その結果、新ルーターだけでも電話機能は使えるんですが、NTT割り当ての電話番号はPR-400NEで処理をしているので、今までの電話番号を使うのなら(使いますよね!?)、PR-400NEの電話信号を新ルーターに追加して送ってやらなければならないということが、やっと分かりました!

これで、今度こそ設定完了です!!

まあ、最初の設定って、ものすごく手間と時間がかかるってことですね!

どうも納得いかなかったので、さらに設定を変更

またWebサーバーをダウンさせてしまい、申し訳ありませんでした。

NTTの終端装置にルーター機能が付いているのに、それを無効にしてBB光ルーターを追加するのが気に入りませんでした。

この2台の消費電力は60W近くにもなるんです。それを常時消費してる訳ですから納得できません!

 

しかし・・・

BB光ルーターを外した設定を一からやるのにここまで時間がかかってしまいました・・・!

これで何とかなってるんですが、速度アップとかの詳細設定は後日やることにします。

明日早いので、今日はここまでにします!

Netcommons3、今までのリストア法ではダメ?!・・・

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

いきなりやるのは怖いので、Debian10のテストサーバーを作り、そこに php7.4をインストールして、テストをさんざんやりましたが・・・

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

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

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

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

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

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

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

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

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

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

悩み中です。

OS、PHP共に最新にアップデートはしましたが・・・

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

SSDにEFIパーテイションを作成する所からつまづきました。

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

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

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

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

Netcommons3.3.1でのサイト引っ越し方法覚え書き

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

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

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

今回は、新規ストレージにDebian10をインストールし、phpは7.4を使用することにします。

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

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

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

 

<手順>

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

 ②マザーボードBIOS(UEFI)のアップデート

 ③ストレージ(SSD)の交換

 ④SSDにEFIパーテイション256MB作成(マザボがBIOSタイプなら不要)

 ⑤Debian10最小構成インストール

 ⑥ファイヤウォール設定

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

 ⑧php7.4リポジトリ追加して、php7.4、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ブラウザでアクセスして、正常にログイン出来ればOK!

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

以上です!

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

オンラインストレージを自宅サーバーで構築

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

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

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

使う手ですが、

 ①省電力自作PCを用意(省電力タイプならメーカー製パソコンでも可)

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

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

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

こんな感じです。

 

では、具体的に。

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

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

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

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

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

②の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をおすすめしておきます。

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

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

コマンド文入力、コマンド文編集のために必須のツールです。ただし、vim、nanoといったツールでもOKです。

 

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

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

さて、それからは?

(1)SSHサーバーインストールして、ポート変更、rootログイン禁止設定

(2)ファイヤウォールUFWをインストール

(3)UFWのポートは443、123、SSH分、Webmin分だけ開けておきます。

(4)時刻合わせにntpサーバーインストールして設定変更

(5)snapdインストール

(6)snap install nextcloud

(7)source /etc/profile.d/apps-bin-path.sh

(8)nextcloud.manual-install

(9)nextcloud.enable-https self-signed

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

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

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

 https://〇〇〇

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

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

 

(補足1)

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

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

 wget http://www.mydns.jp/login.html --http-user=mydns●●●●●● --http-password=パスワード -O /dev/null

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

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

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

 

(補足2)

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

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

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

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

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

 

(補足3)

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

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

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

昨夜、DDNS関係、そしてハードウェアのトラブル!

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

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

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

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

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

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

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

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

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

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

そうだ!

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LAN内DNSサーバーの構築・・・

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

LAN内DNSサーバーの構築(続き)

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

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

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

これを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内名前解決について(現状での結論)

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

 

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

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

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

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

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

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

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

 

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

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

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

 

最後にもう一つ。

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

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

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

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

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

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

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

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

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

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

そこで、2つめの Apache をインストール!

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

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

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

 

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

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

それならば!

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

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

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

どうでしょうか?

LAN内名前解決について(今度こそ最後!・・・?)

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

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

 

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サーバーの動作を止めて行う必要があるので、今夜から明朝にかけてサイトを一時停止します。

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

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

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

メモリーテスト8時間かかりました。動作正常です!

昨夜0時からメモリーテスト(memtest86使用)を実施しました。

4時間ほどで終わるかな? と思っていましたが、たっぷり倍の8時間かかりました!

前回のテストでは8GB4時間、今回16GB8時間で容量に比例したキチンとしたテストをやってくれたようです。

テストの結果エラーは全くなしで、ひとまず安心です!

調べてみると、メモリーモジュールは時間が経って不良になるケースはままあるようです。

業務用サーバーではECC付メモリーのような高信頼品を使うんですが、

こうなるとマザーボードから対応していないとダメで、ハードウェアにかなりの額を投資する必要が出てきます。

ただ、民生用も昔以上にハードウェアの品質が向上し、PC自作派も多くなったので、デバイスの相性問題や不良率も相当に改善されているようです。

 

さて、メモリー関係でぜひやった方がいいことがあるんですが、

①新規購入してマシンを動作させる前にメモリーテストをしっかりとやっておく。(memtestがいいと思います)

②マシンのメンテナンス等で中を開けることがあったら、内部の掃除終了後に、メモリーを抜き差しする。

メモリーの抜き差しは結構力が要りますが、慎重ににやって下さい。

このメモリーの抜き差しですが、いわゆるメモリーとスロットの接点のセルフクリーニングをやる訳ですね。

故障PCを見て欲しいと依頼されて、このメモリーの抜き差しだけで直った経験が何度かあるほどなんです。

 

もう一点。

今回からマシンメンテ中に、別のテスト用Webサーバーから「サイト休止中」の表示を出すようにしておきました。

AtomD525を使ったちっちゃなDebianサーバーマシンです。

サイトのSSL化

 サイトをSSL化するには、暗号化、ポート変更だけでなく、SSL証明書が必要になります。

元々サーバーには、自分で自分を証明する「自己署名証明書」が最初から用意されています。

「自己署名証明」とは、自分自身で「私は安全ですよ」と証明するんですから、おかしなもので公的な証明にならないのは明らかです。

「自己署名証明書」を「オレオレ証明書」とは良く言ったものですよね。(笑)

あれ? こんな証明書があらかじめ用意されているサーバーなんて怪しいじゃないか! と自分も最初は思いました。

https 通信にはSSL証明書が必ず必要な仕組みになっているのですが、例えばネットワーク上で https 通信を自分だけで使う場合などは「オレオレ証明書」で問題ない訳です。

こんな理由でowncloud、nextcloud運用の際は「自己署名証明書」を使っていました。

ところが、最近nextcloudの運用でPCやタブレット端末で時々警告が出るようになって煩わしくなってきたんです。

それから、自分のWebサイトもSSL化する必要がありますね。

そこで、以前試したことがある LetsEncrypt について調べているんですが、すごく便利な方法を見つけました!

まだ色々と調べているんですが、この手を利用させてもらおうと今頑張って勉強中です!

Lets Encrypt 設定

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 で自動実行させるよう設定しておけば良い!

職場など出先で自由にインターネット接続出来るタブレットPC

 職場で、授業や補講などでプレゼン風に文書、画像、動画、音声、スライド、アニメーション、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 のスロットに差し込むんですが、下の写真のヘッドフォン端子の左側がスロットです。

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

大丈夫でした!!

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

ダウンロードファイル名文字化け、サイト内検索についての不具合について

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

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

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

そこで、

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

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

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

 

以上です

NetCommons3.3.2.patch1適用

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

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

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

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

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

iOS14が直に発表されるようですが・・・

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

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

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

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

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

自分はOSのアップデートは直ぐにしてしまいます

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

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

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

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

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

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

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

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

データの保管、保護について改めて考えてみる

 普段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システムを復旧させてみる。

 

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

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

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が起動する。

ソフトウェアRAID1、今後障害対応出来そうです!

 ソフトウェアRAIDは、当然ですが、OSが立ち上がった後でないとRAIDが機能しません。

ということは、OSが立ち上がるまではRAID動作ではないし、RAID動作開始までは1本のみのディスクで動いているということになります。

ですから、起動ドライブ(ドライブ1)に不具合が発生してしまうと、起動さえも出来なくなってしまいます。

これを避けるために、「ドライブ2にもMBRを用意しておきgrub 等のブートストラップローダーをドライブ2にもインストールしておけば良い」と書かれています。

しかし、今までこの作業をしてきませんでした。

RAIDシステムが出来上がって機能し始めれば、トラブルが起こるまでは対応は必要ないし、「まあ後で対応すればいいや」と思いながら結局対応しないままになっちゃっていたんです。

さて、サーバーOSのインストールはインストールメディアから立ち上がるインストーラーに任せていますが、最後のgrubインストールで/dev/sdaを指定してインストールが終わった後に、再度grubを/dev/sdbに手動でインストールするようにと、手引きには書いてありました。

ところが、この作業がエラーになってしまい上手くいきません。

試行錯誤している中で、今日試してみた作業がたまたま上手くいったので書いておきます。

 

 RAID構築が終わったあと、インストールメディアをレスキューモードで起動させます。

①ディスク1、ディスク2をRAIDドライブとして認識させる。

②RAIDドライブを構成している/dev/sdbを指定してgrubをインストールする。

これでうまく行きました!

 もちろん、うまくいったかどうかの検証が必要ですね。

まず、ディスク2を外して電源を入れてみます。

起動してディスク1本のみの環境を作っているようです・・・

この後しばらくしてログイン画面となりました。

起動完了したようです。

 では、次にディスク1を外して電源を入れ、ディスク2からの起動を試みます!

立ち上がりましたね!

先ほどと同様、ディスク1本のみの環境を作っているようです・・・

この後、しばらくしてログイン画面が表示されました!

ディスク2からの起動もOKのようですね!

最後にディスクを2本とも元通りに接続して、電源を入れてみます。

2つのディスクを完全に同期させる動作を行っているようです・・・

このあと最終的な結果が表示され、RAID1環境が完全に出来上がっていることが確認できました!

もう少し実験したいことがありますが、これで重要な一区切りまでは行けたようですね! 

RAID1システムまだ正常動作していませんでした

 Debian10サーバーによるRAID1システムが出来上がったので、Sambaファイルサーバーの運用を再開しました。

ところが、Webminでディスクの状況を確認してみたところ、赤字で「degraded」の警告らしきものが出ていました。

degraded?

「劣化? 退化? 低下?」!!

異常の通知のようですね!

 

このディスクはWD社REDのNAS用モデルなんですが、Webサーバーのシステムディスクとして1年以上ノンストップ連続運転させていたお下がりなんです。

エラーも出ていないしまだ使えるだろうと思っていたんですが、やっぱりもうダメかな? と調べてみることにしました。

すると、どうもこの前やった実験(RAID構築後に片側ディスクだけで起動するか)のあと、両方のディスクを接続し直しただけではRAID1システムは再構築されていないようだということが分かってきました。

RAIDが不完全なまま動いているようで、これではダメですね!

きちんと復旧させておかなければいけません。

そしてその復旧作業のあと、念のために、どちらの片側ディスクからも起動することをもう一度確かめておく必要があります。

もちろん、最終的には再度RAID1復旧作業を行って終わりにしておかないといけませんが。

こういう実験は今回のような自粛期間中にどんどんやっておきたいと思います!

外で動けるような日に室内に閉じこもって作業するのはイヤですからね!(笑)

Wordpressに簡易グループウェア機能を持たせることが可能?

自分のWebサイトを今後どうするのか、いつまで運用できるのか、良く考えるんですが、

 ①自分自身でサーバーマシン、システムのメンテ、サイトの更新が出来る時まで

 ②このNetcommons等のWebアプリケーションの開発が続き、自分自身で更新していける時まで

 ③無料DDNSサービスが継続するまで

さしあたってはこんな感じなんですが、②のNetcommonsに関しては不安があるんです。

自分が持っている程度のスキルでNetcommonsのメンテを続けていくためにはWeb上での多くの情報が必要ですが、現状では情報があまり得られていません。

Netcommonsの運営方針も昔とは異なってしまい、今後どうなっていくのか現時点では不透明です。 

自分もあと数年で教育現場から完全に引退すれば、グループウェアもあまり使わなくなってくるかもしれません。

 今日何気なくサイトを見ていたら、「Wordpressがグループウェア的に使える」といった感じの記事が目に留まりました!

Wordpressは、大規模なWebサイト構築に使われているCMSで世界中で広く利用されています。

また2020年の統計では、世界中のCMSの60%以上、世界中のWebサイトの35%以上のシェアを持っているソフトです。

Wordpressの運用情報は非常に多く、このシステムの構築とメンテナンスを続けていくことに関しては先が明るい感じがします。

Netcommonsのような高度なグループウェア機能はないかもしれませんが、ちょっと気になる情報でした。

現状では、例えば以下のようなプラグインを使うことでグループウェア機能を実現しているようです。

ということは、今後新しいプラグインも開発されていくかもしれませんね!

なぜ自宅サーバー?

 このサイトは自宅サーバーでの運用ですが、自宅サーバー運用はデメリットの方が非常に多い訳です。

自宅サーバーのデメリットは検索すれば沢山出てきますが、デメリットの中で最も怖いのは、

 ①サーバーマシンから発火して火災が発生する!

 ②セキュリティーを破られて不特定多数の方に迷惑をかける!

 

 自分でサーバーマシンを組み立てて、ソフトをインストールしてシステムを作るというのはもちろん楽しいことではありますが、上記のデメリットだけで充分大きなリスクですね!

自分のサーバーでは、今のところですが、運用当初よりトラブルはなく安定しているのですが、常に面倒を見続けなければならない状況はこれからも変わらないでしょう。

ところで、自分が自宅サーバーを始めた理由ですが、

 ①職場と自宅の間の大容量ファイルのやり取りをする環境が必要だった。

 ②一般的なクラウドを使って仕事で使うファイルをやり取りすることは当初職場では禁止されていたし、許可されていたとしても自分には抵抗があった。

 ③校務でネット上のグループウェア(Netcommons2)を操作しているうちに、自分の仕事にも活用できそうだと思った。

 ④音楽ファイルをサーバーに貯めておけば、ネット上でアクセスできる。容量が非常に大きな音楽ファイルでも自宅サーバーなら容易に実現できる。

 

 今の仕事を続けている間は、自分にとって①~③は重要ポイントなんです。

完全退職後は、①~③は不要になりますし、これらの一部機能はレンタルサーバー上で実現すればOKでしょう。

④は車の運転中にタブレット等を使って音楽を流しておくとかで残したい機能なんですが。

といった感じで、今のところは充分に気をつけながら自宅サーバーを運用していこうと思っています。

 

 実は今もう一つ、作りたいものがあるんです。

震災や風水害等の大災害が発生した時の連絡システム、安否確認が出来るシステムです。

災害時の連絡ツールはLINEが良さそうですが、LINEでもシステム障害が起こったことはあるそうですし、LINEよりデータの流れがシンプルなものを作れないかということなんです。

この件についてはまた別の機会に書こうと思います。 

災害時等連絡システム(1)

 阪神淡路大震災、そして東日本大震災でも経験したんですが、このような時、連絡を自由自在に取り合ったり、安否をすぐに確認したりということが難しくなりますよね?

このような事態に遭遇した時、どのように連絡を取り合うのか、いい方法がないか考えています。

例えば、3.11東日本大震災の教訓から生まれた「LINE」という素晴らしいアプリケーションがありますね!

LINEは災害時の安否確認等にも威力を発揮してくれると思うのですが、過去、システム障害が発生したことがあるそうです。

他のサービスでも同様だと思いますが、図中クラウド上のサーバーに多数の利用者のデータが集中すれば、さばき切れなくなることは予想できます。

自由に連絡が取りあえるシステムを何とか作れないでしょうか?

たとえば、レンタルサーバー上にチャット機能を持たせた簡単なサイトを作るとかです。

Peer to Peer接続であれば、サーバーを介さず1:1で通信できるので、緊急時の連絡システムとしてはこれが一番良さそうです。

LINEは、ユーザーIDなどのアカウント情報は管理していますが、データファイルやトーク履歴などはLINEサーバーを介さずユーザー同士が直接管理しているそうです。

(しかし、実際の通話やチャットの中身のやり取りはPeer to Peerではないそうです)

 

 最近、ふと思いついたことがあるんです。

もし、自宅までの光回線が、クラウド上のサーバーまでの光回線と同じくらいの程度で安定であれば、ルーターやサーバー本体への電源をしっかりと確保した自宅サーバーでも使い物になるのではないかということです!

つまり大規模停電等が起こっても自宅までの光回線がダウンせず、サーバー周りへの給電は太陽電池と充電池を組み合わせたもので行うようなシステムにしておけばいいのではないか?

まだ実験の段階なので、運用中の自宅サーバーを使って試している最中です。

RocketChatサーバー(snapインストールだともの凄く楽でした!)はインストールしてみましたが、緊急事態に突然初めてのユーザーが利用するには、初期設定等かなり面倒でした。

LINEと同程度に簡単にすぐ利用開始できるものがいいですね!

(続く)

災害時等連絡システム(2)

 全く偶然ですが、自宅サーバーで運用している Nextcloud に Talk というプラグインが用意されていて、通話、ビデオチャットも含めたチャット機能が備わっているのを発見!!

早速プラグインを有効にしてみました。

また、android、ios用のアプリも用意されていて、スマホに無料でインストールできます!

昨夜、早速娘とチャットのやり取りとチャット通話の実験をしてみました。

(娘のニックネームはネズミなんです! 笑 )

これ、LINEとほぼ同じ感覚で使えそうですね!

すごい!!

これでいけるかも。

しばらく色々な実験をして、安定に使えるか確かめてみたいと思います。

GPGキー期限切れのupdateエラー

 いつものようにサーバーOS(Debian10)のアップデートをしていたら、エラー表示が!

 

---@aaa:~# apt update

Err:4

https://packages.sury.org/php buster InRelease
The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php buster InRelease: The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

Failed to fetch https://packages.sury.org/php/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

Some index files failed to download. They have been ignored, or old ones used instead.

 

このエラーはGPGエラーで、署名が無効だと言っています。

アップデートファイルをダウンロードする時、GPGキーという公開鍵を使って正しい配布先からのファイルであるかのチェックをしているんですが、GPGキーには有効期限があるんです。

ということで、GPGキーを新たに取得してきます。


---@aaa:~# wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
--2021-05-02 11:00:22-- https://packages.sury.org/php/apt.gpg

Resolving packages.sury.org (packages.sury.org)... 2606:4700:3037::6815:1294, 2606:4700:3030::ac43:b696, 172.67.182.150, ...

Connecting to packages.sury.org (packages.sury.org)|2606:4700:3037::6815:1294|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1769 (1.7K) [application/octet-stream]

Saving to: ‘/etc/apt/trusted.gpg.d/php.gpg’

/etc/apt/trusted.gpg.d/php 100%[======================================>] 1.73K --.-KB/s in 0s

2021-05-02 11:00:22 (8.70 MB/s) - ‘/etc/apt/trusted.gpg.d/php.gpg’ saved [1769/1769]

 

新しいGPGキーを取得できたようです!

では、再度アップデートしてみます。

 

---@aaa:~# apt update

Get:1 https://packages.sury.org/php buster InRelease [6,823 B]

Get:7 https://packages.sury.org/php buster/main amd64 Packages [316 kB]

Fetched 316 kB in 3s (122 kB/s)

Reading package lists... Done

Building dependency tree

Reading state information... Done

24 packages can be upgraded. Run 'apt list --upgradable' to see them.

 

エラーなくアップデート出来ました!

新しい24個のアップデートパッケージが見つかったので、この後 apt upgrade コマンドでこれらのパッケージを適用しました。

このGPGエラーは期限切れで発生するので、あせらずにGPGキーを再取得してアップデートしてみて下さい!

MydnsのDDNSサーバーがダウンしているようです・・・

 現在、20時16分ですが、LAN内からブログ更新しています。

しかし、外部つまりWANからのアクセスが出来ない状況です。

お世話になっているMydnsのDDNSサーバーがダウンしているようなんです。

このサーバーが復旧してくれないと、このサイトはWAN上に公開できないのです・・・

 

DDNSサーバーが復旧した時、この記事が見えているはずです。

DDNSサービスについて

 10月に入って、サイトのメンテ中に光モデムルーターを再起動して、WANからのアクセスがしばらく出来なくなったんですが、今回は復帰までの時間がちょっと長かったんです。

光モデムルーターを再起動すると、割り当てられているグローバルIPアドレスが変わります。

一方、DDNSサーバーへの通知は30分おきにしかしていないので、DDNSサーバーが持っている情報は最長30分は古いままです。

 

①最長30分後、DDNSサーバーは更新情報を受け取ります。

②DDNSサーバーからDNSサーバーへ新しいDNS情報が通知されます。

 

①のあと、②はすぐに行われると思っているのですが、多くのDNSサーバーに情報が行き渡るのには時間がかかるでしょう。

 

 固定ipを持っていないサーバーではこんな感じになり、WANからアクセスできない時間がしばらく発生してしまう訳です。

今回の件で、今まで何気なく利用させていただいてきたDDNSサービスについて、改めてありがたさを感じました。

自分はMydnsを使わせていただいているのですが、最近は国内の無料DDNSサービスはここだけになってしまったのではないでしょうか?

古くからあったアゴラ社のieserverはサービスを休止(停止?)しているようですので、Mydnsが最後の頼みの綱ということになります。

これまでの自分は、この無料DDNSサービスへの感謝が足りなかったと反省しているところです。

 

 もう一つ、Mydns の twitter に次のような内容が tweet されていました。

 

 Ban4ip は IPv4 及び IPv6 用の、/64のようなネットマスクでもBAN可能な防御(ロックアウト)ツールです。

ホワイトリスト(非制限アドレス)機能もあるので安心です。

 

このツールは、サーバーへの悪意あるアクセスをアクセスログの解析等によって防御するものらしく、Mydnsサーバーへのアクセスについて審査されていると思われます。

当然、自分のサーバーからもMydnsサーバーに毎日30分毎にアクセスしているので、不正アクセスでないか審査が行われているものと推測されます。

DDNSサービスが動いているか停止しているか表示してくれる別サイトがあるのですが、自分はこのサイトの情報を見てMydnsのDDNSサービスがdownしているんだと判断していました。

現在も、この別サイトの情報によると、Mydnsサービスはdownしていることになっているのですが、どうも違うのではないかと思っています。

しばらく様子を見てみようと思っています。

また、Mydnsサーバーへのアクセスコマンドですが、とりあえず使用例にならって、curl から wget に変更しておきました。

このサイトの不具合と格闘中

 このサイトの表示に関する不具合についての正しい対処法が未だに掴めていません。

現時点での対処ですが、新しいNetcommons3.3.4ディレクトリを上書きして、アップデートコマンドを実行させるという作業を行いました。

この上書きの際、元ファイルのパーミッションを保持したままのコピーとし、最後にディレクトリとファイルの所有者をwebサーバーに変更しておきました。

これでしばらく様子を見てみます。

サイト不具合に対する現時点での対応

 不具合の原因を素人なりに色々と考えながらいくつかの作業をやってみました。

 

①Netcommons3.3.4の不具合かもしれないと思い、3.3.3バージョンに戻してみた。

 → 作業直後は正常に戻ったように見えていたが、一晩後にはまた表示がおかしくなっていた。

 

②cashe、expireといったキャッシュ設定が悪さをしているかもしれないと考え、これらを無効にしてApacheを再起動。

 → 変化なし

 

③google pagespeedモジュールを無効にしてみた。

 → 嘘のように全く正常な表示に復帰!

 PCからもスマホからも正常に表示されるようになった。

 Netcommonsも最新の3.3.4に戻した。

 

理由はどうしてなのか分かりませんが、とりあえずこれで様子を見てみます。

どうかこのまま正常動作していて欲しいと願っています!

何をやってもダメならサイト運用を停止しないといけなくなりますが、今はグループウェアとしても使っているのでサイト停止はしたくないんです。

Sambaファイルサーバー設定(1)

 LinuxSambaによるWindowsファイルサーバー(NAS)を作って知人宅に設置しようとしていたんですが、知人宅内のネットワークアドレスが自分の家でのネットワークアドレスと異なっていました。

ローカルIPアドレスは、通常 192.168.〇.△ のような数値になっていますが、この第3オクテット(〇)の値が、通常の値ではなかったんです。

ならば、こちらで設定をほぼ済ませてからNASを知人宅に持って行って、そこで最後の設定をすればいいや、と考えていました。

NASはLAN内からのファイルアクセスの他に、LinuxServerの設定、修正、updateが出来るように SSH、Webmin が使えるようにしておく他、Serverの電源OnOffをリモートで出来るようにしておいた方がいいだろうと考えていました。

現状では、セキュリティ強化の面からWindowsUpdate等によって、以前は簡単に出来ていた事が出来なくなってきているようです。

現に、今回Sambaの設定でつまづいてしまいました。

ということで、知人宅と同じネットワークアドレスを作った上で、実験を繰り返しながらこのNASを完成させた方が良さそうです。

で、最近偶然に分かったことなんですが、自宅のLAN環境にもう1台のルーターを直列に入れれば、第3オクテットを変えたネットワーク環境が作れるんですね!

このやり方で今日、Debian11のSambaファイルサーバーが90%ほど完成しました!

あとは、Wake on lan が上手く動くように明日頑張ってみたいと思います!

Sambaファイルサーバー設定(2)

 本日は代休ということもあり、昨日の作業の続きに没頭しました。

Debian11のSambaサーバー(NASとして仕上げる)ですが、クライアントマシンからリモートで電源onに出来ないと不便です。

ということで、Wake on Lan の設定作業です。

今までの認識では、起動させようとするマシンは眠っている訳ですから、BIOSの設定だけでOSの設定は関係ないと思っていました。

今回は、マザーボード側で「Power On By PCI/PCIE Devices」をオンにしておく必要がありました。

ネットワークインターフェイスデバイスはPCIEデバイスの1つなんですね。

network boot はこの設定では関係ありません。

さて、これだけで起動してくれると嬉しいな~ と思ったんですが、やっぱりこれだけではダメでした・・・

そういえば・・・

以前 Windows 機を Wake on Lan させようとした時、デバイスマネージャーで NIC のプロパティをいじった記憶があるんです。

そこで、Debian 機の Wake on Lan 設定を検索で何とか見つけ出しました。

 

/etc/init.d ディレクトリ内に

wakeonlan といったファイルを作っておき、

そのファイルに以下を書き込みます。

 #!/bin/bash

 ethtool -s eno1 wol g

 exit

このファイルの権限を変更します。

 #chmod +x /etc/init.d/wakeonlan

さらに、このファイルを自動起動するよう設定します。

 #update-rc.d -f wakeonlan defaults

また、

/etc/network/interfaces ファイル最終行に以下を書き加えます。

 iface eno1 inet static

 ethernet-wol g 

 

以上の設定で、ようやくDebianサーバー機を wake on Lan させることが出来ました!

クライアント側の wake on Lan ソフトですが、nWOL というフリーソフトがとても良く作られていました!

また、電源Offですが、やはりSSHクライアントソフト(Rlogin等)を使ってコマンドを打ち込むようなやり方になりそうです。

 これ以外に行った設定は、ファイヤウォールはもちろんですが、IPV6無効化、ローカルネットワーク外からのアクセス禁止(SSH、Webmin、Samba)等です。

これで、このサーバー機は嫁入り出来る状態までに仕上がったと思います! 

今回のストレージですが、WD-REDではなく東芝のNAS用HDD12TBを2台使いました。

この2台をOSによるソフトウェアRAID1としましたが、ブートローダー grub は両方のHDDにインストールしてあります。

Sambaファイルサーバー仕上げ

 Sambaのファイルサーバー機が嫁入りする前に、もう少し細かいところを手直ししてみます。

PowerOnにしたあと、まずはUEFIのpost画面が出ますが、この画面の表示時間を短くするには、UEFI設定で「fast」といった項目を選びます。

このマザーボードでは「ultrafast」設定がありました。

そしてUEFIがデバイスのチェックや初期化を終えると、OSのブートメニューが表示されます。

Debian11では、Grub2のブートメニュー画面ということになります。

このブートメニュー画面の表示時間がデフォルトでは結構長めなのでこの表示時間を短くしたいと思います。

 /etc/boot/grub/grub.cfg

ファイルを直接編集して、

 timeout = 5

等と書き換えて上書き保存しても上手くいきません。

起動時にファイルが書き戻されてしまいます。

 /etc/default/grub

ファイルを編集するようです。

 timeout = 1

と書き換えてみました。

このあと、

 # update-grub

を忘れずに。

これで、Power On から起動するまでの時間がかなり短縮されました!

Sambaファイルサーバー仕上げ(追加)

 ファイルサーバーのリモート On Off ですが、電源 On は Windows クライアント側での WOL(フリーソフト)は使用感がとてもいいです。

初期設定の NIC の MAC アドレス取得とかも非常に楽で、すぐ使えるようになります。

ファイルサーバー側の OS が完全に立ち上がってから音を鳴らしてくれる機能も good です!

サーバー側が完全に立ち上がる前に Samba にアクセスすると、ファイルアクセスだけでなく、OS のコマンド操作、Webmin からのアクセスも出来なくなることがあるので。

さて、サーバーのリモート電源 Off ですが、SSH を使ってコマンドを打ち込むやり方しか思い当たりませんでした。

Webmin からでも電源 Off は出来ますが、手順が多くちょっとやっかいなんです。

そこで、

Windows クライアントに SSH クライアントソフト Rlogin(フリーソフト) を入れておきます。

初期設定はちょっとだけで済みます。

次回の接続からはログインまで自動です!

さて、そこからですが、自分ならいつも su- コマンドで root に遷移してからシャットダウンコマンドを打ち込んでいました。

今回は、ちょっとだけですが、より簡単な操作に出来そうだということで、使用ユーザーに権限が与えられる sudo コマンドを使うことにしました。

まず sudo をインストールし、sudoユーザーの設定ファイルを編集します。

 /etc/sudoers

ファイルに、権限を与えるユーザについての行を書き込んで保存します。

 # User privilege specification

の下に

 gonta ALL=(ALL:ALL) ALL

といった記述を書き込めば、ユーザー gonta には root 権限が与えられた上でコマンド操作が出来るようになります。

指定したコマンド操作をする時だけ root になれるということですね!

ユーザー gonta がサーバー機をリモートシャットダウンしたい時は、

 gonta@server :~$ sudo shutdown -h now

とコマンドを打ち込みます。

その後パスワード入力を求められるので、パスワードを打ち込めば命令が実行されます。

なんだ! 結構手間がかかるじゃないか! と思いますが、

コマンド操作の入力履歴は、キーボード「↑」を打てばワンタッチで出てくるんですね!

ですから、サーバーの電源 Off の操作は

 ① Rlogin を起動(タスクバーにアイコンを置いておくと良い)

 ②ログイン先をクリックしてログイン(自動)

 ③「↑」キーを1回押して、(sudo shutdown -h now を表示させて)「Enter」キーを押す

 ④パスワードを入力して「Enter」キーを押す

以上です!

面倒そうに見えますが、一連の流れでスムーズに操作出来ます!

Linux 系 OS での操作ですが、良かったら試してみて下さい。

php8にまだ対応してないアプリケーションへの処置

 先日、Netcommons3のヴァージョンを、3.3.4から3.3.5に上げようと、いつもの手順で作業していました。

しかし、今まで見たこともないエラーが・・・

しばらく考えていましたが、情報も得られずエラーメッセージも分からない。

でも、もう一度良く見てみると、

 

Error: ReflectionMethod::__construct(): Argument #2 ($method) cannot be null when argument #1 ($objectOrMethod) is an object
> #0 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/Shell.php(358): ReflectionMethod->__construct()
> #1 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/Shell.php(423): Shell->hasMethod()
> #2 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/ShellDispatcher.php(222): Shell->runCommand()
> #3 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/ShellDispatcher.php(66): ShellDispatcher->dispatch()
> #4 /var/www/html/app/Console/cake.php(35): ShellDispatcher::run()

 

phpの動きに問題?

このサーバーのphp環境は7.4だったはずなんですが、調べてみたらなんと8.1に上がっていました!

こまめにOSのアップデートをしていますが、その時にphpもアップデートされてしまうのは知りませんでした。

最初にOSインストールした時、phpのリポジトリ登録は手作業でやったんですが、この関係?

ここで、Netcommonsプロジェクトにメールで相談してみました。

手掛かりがなければ、phpを元の7.4に戻してみようと思っていました。

ところが何と!

嬉しいことに、すぐ返信が届いたんです!

「Netcommons3はphp8に対応させる予定はあるが、まだ見通しが立っていません」

「サーバーをphp7環境に戻して使って下さい」

この情報で、対処の見通しがつきました!

 

# update-alternatives --config php

このコマンドを実行すると、出力は、

 

選択肢 パス 優先度 状態
------------------------------------------------------------
* 0 /usr/bin/php7.4 74 自動モード
1 /usr/bin/php7.3 73 手動モード
2 /usr/bin/php7.4 74 手動モード

現在の選択 [*] を保持するには <Enter>、さもなければ選択肢の番号のキーを押してください

 

といった感じでメッセージが出るので、

希望するヴァージョンのphpを選んで番号を入力、Enterすれば使用phpの切り替えが簡単に出来ます!

この後Netcommonsのヴァージョンアップの作業を再度やってみたら、無事にアップデート完了しました!

Netcommonsプロジェクトの中島様、それからプロジェクトの皆様、

本当にありがとうございました!

WordPressサイトを作成

 デザイン性に優れた新しいウェブサイトを利用したい、という依頼がありました。

そこで、商業的なウェブサイトとしても利用実績が多く人気の高い WordPress でサイトを作ってみることにしました。

WordPress は CMS に分類される Web アプリケーションです。

オープンソースソフトで無料で利用できます。

 

構築の仕方ですが、

 ① Web サーバーを用意

  レンタルサーバーと契約、又は自前のサーバーを作る

 ② データベースを用意

  ①のサーバー内に Mysql 等のデータベース環境を用意して、WordPress サイト用のデータベースを作成する

 ③ WordPress 本体を WordPress.com サイトからダウンロードして、①のサーバー上で解凍し、ドキュメントルートに配置

 ④ このサイトにアクセスして、初期設定を完了させる

 

これだけです!

興味さえあれば、難しくはありません。

最初は、自宅の LAN 内で1からサーバーを作ってみるのもすごく面白いですよ!

IEモードを有効にするためにはIE機能は有効のままで

 MS社のインターネットエクスプローラーのサポートがついに終了となりました。

他のアプリケーションソフトと同様、サポートが終了されたソフトは使わないようにすべきでしょう。

ということなので、IE11の代わりに他のブラウザを使うようにすればいいんです。

ところが、このブラウジングソフトの機能を使用したシステムが多数存在するようです。

例えば、メーカー提供のシステムをネットワークアクセスして使うような用途では、ほぼWebブラウジングソフトが使われているんですね。

このような時、システムを作成するメーカーは、Windows標準だったインターネットエクスプローラー使用を前提とした設計をしたんでしょう。

さて、一般的には、WebブラウジングだけならブラウザソフトをEdgeやChrome等に変更すればいいだけで、

その時WindowsのIE11機能を無効にしておくと、より安全性が高まると思います。

 

 

 

 しかし、MS社Edgeのインターネットエクスプローラーモードを使おうという時は、

このWindowsシステム内のIE機能を有効にしたままでないと上手く行きません!

ちょっと注意して下さい!

Netcommons3サイトのアクセスURL変更

①Netcommons3サイト内のアクセスURLが書いてあるファイルですが、

インストールディレクトリ¥app¥Config¥application.yml です。

この中のアクセスURL(1か所)を書き換えます。

 

②DynamicDNS等の設定は前もって済ませておく。

(certbot --apacheによるLetsEncrypt設定で、外部DNSに新URLを行き渡らせておかないとダメ)

 

③次は、WebサーバーApache2の設定ファイルです。

まず、

#a2dissite 〇〇〇.conf

で、該当サイトへのアクセスを無効にしておきます。

また、

#a2dissite 〇〇〇-le-ssl.conf

も実行しておきます。

#systemctl reload apache2 

 

④新しいURL用の △△△.conf  を作成

 

⑤新URLアクセスを有効にする。

#a2ensite △△△.conf

#systemctl reload apache2

 

⑥LetsEncrypt自動設定

#certbot --apache

あとは対話形式で操作を選んでいけばサイトssl化が完了!

旧サイトのアクセスURL変更

 自分は、旧サイトで初めて Netcommons の運用を始めました。

その時のアクセスURLは、お世話になっている Mydns サイトで取得できるドメイン名を使うことになります。

その時、〇〇〇.mydns.jp より、〇〇〇.pgw.jp の方がかっこいい感じだと思い、ドメインはこれに決めました。

そして、ホスト名 www を付けて http://www.9monotaira.pgw.jp をアクセスURLとしたんです。

ずっとこれで運用していたんですが、ある時TREND.MICRO社の「サイト安全性チェック」で確認したところ、

この「安全」判定にはホッとしたんですが、

 

何と、サイトのカテゴリ評価は・・・

ん? 

 

出会い?!

出会い系サイト?!!

ヒドイでしょう?

汚名だー!

「評価内容変更のリクエスト」は当然しました!

これで一度は改善されたんですが、

サイトをSSL化したところ、またも「出会い」カテゴリに分類されてしまったんです!

 

 しばらく考えてみたんですが、これは、ドメイン名 pgw.jp を使うことに問題があるのではないかと思いあたりました。

例えばこのドメインが悪用された例があるとか。

試しに、存在しないサイト名 https://kakuu.pgw.jp を「サイト安全性チェック」で同様にチェックしてもらうと、

予想通り「出会い」カテゴリと診断されました!

これで状況が掴めました!

こんな訳で、旧サイトのアクセスURLをドメインも含めて変更できないか考えることにしたんです。

旧URLへのアクセスを新URLへ導くには?

 旧URLのアクセスがあった時への対応はどうしようか迷ったんですが、

対応しないというのも不誠実だと思い、調べてみました。

「Redirect」を使うというのは何となく分かっていたんですが、

旧URLを使ったサイトを用意する必要があるのではないかと思い込んでいました。

今回、時間がたっぷりとあったので、色々と調べたり考えたりしているうちに、

apacheの、旧URLに対応したヴァーチャルホストの設定ファイルに、Redirect設定を書き込めば?

と思いあたりました。

旧URL用httpアクセス設定ファイル 〇〇〇.confの中身は

 <VirtualHost *:80>
  ServerName 〇〇〇.pgw.jp
  Redirect / https://△△△.mydns.jp/
 </VirtualHost>

だけです!

このあと、LetsEncrypt自動設定を行います。

#certbot --apache

旧URL用の処理を選ぶと、旧URL用httpsアクセス設定ファイルを自動で作ってくれます!

 

さて、以上の設定を済ませて運用した結果ですが、

現状、これで旧URLアクセスを新URLサイトに導けているようです。

旧URLサイトの特定のページも、新URLサイトの同じページに誘導出来ています!

 

 

補足ですが、旧URL、新URL共に利用できるよう、

DDNSサービスサイト(MyDNS)に定期的に通知を送信し、DNS情報を更新し続けていただいています。

iOS、iPadOS 出来るだけ早くアップデートを!

 アップルは、スマートフォンなどの基本ソフト(OS)について

「ハッカーが端末に侵入する恐れのある安全上の脆弱性が見つかった」と発表しました。

 

アップルによると、

OSの脆弱性によって影響を受けるのは

「iPhone」の「6S」以降のモデル、

第5世代以降の「iPad」

「iPadプロ」のすべてのモデルなどです。  

 

アップルは、

ハッカーがこの脆弱性を利用して端末を乗っ取ったり、

悪意を持って作成されたWEBコンテンツを通じて端末に侵入することができる、

といった恐れがあるとしています。  

 

アメリカ政府のサイバーセキュリティ当局は

「ハッカーはこれらの脆弱性を悪用する可能性がある」

と警告していて、

できるだけ早く必要なアップデートを行うようユーザーに呼び掛けています。

8/20(土) 4:49配信

サイトのバックアップ

 自分の自宅サーバー内のサイトのメンテナンス(バックアップ等)についてです。

低TDPの安価な新型マザーボードが出るタイミングで、

マザーボードとストレージ(SSDとHDD)を交換し、OS(Debian)もヴァージョンアップしてきました。

ところが、今回はまだ新型マザーボードが発表されていません。

そこで、ハードウェアの交換を待たずに、Webサイトのバックアップのみ昨夜行いました。

 

現サイトは個人運用ですから、

サーバーの故障や破壊があった時は、

状況によってはサイトも復旧できず、全て内容が失われることになります。

例えば地震や火災などで、サーバーマシンごと完全に壊れてしまうリスクはゼロではありません。

そんな時は、さすがに仕方ないとあきらめようとは思っています。

しかし、このサイトに備忘録として書き留めてある内容などは、自分にとってかなり貴重なものですし、

昔の想いや考えを過去に遡って読めるようにしておくことも、やっぱり自分には貴重なことです。

 

そこで、やはり、バックアップといった自分で出来ることは、定期的にやっておこうということになります。

 

<Netcommonsサイトのバックアップ>

 ①データベースのバックアップと、バックアップファイルの保管

 ②インストールディレクトリをそのままコピーして保管

<Wordpressサイトのバックアップ>

 ①Wordpressに実装されているバックアップ機能を使い、バックアップファイルを保管

 

現状では、この方法が最も手っ取り早いのではないかと思います。

素人的な方法だと思いますが、サイトのuploadディレクトリが肥大化していたりしても、

ローカルサーバーですし、ハードディスクを追加してそこにSSD内のファイルをコピーしたりも簡単に出来ます!

さらに、自宅内であっても、別の部屋のバックアップサーバーにファイルコピーをする等すれば、

多少であっても安全性は高まるでしょう。

AC電源の極性

 家庭用AC電源の極性について、最も一般的な注意事項は、

「電気工事その他配線の際、接地極を必ず指定された側に接続する」というのがあります。

接地極と大地は常に同電位ですから、通常、人が接地極に触れたとしても感電はしません。

電極に直に人が触れることはほとんど無いはずですが、

例えば電球のネジ側の極には触れてしまう危険性があります。

ですから、電球のネジ側の極には、接地側の線を配線しなくてはならない規則になっています。

また、電気製品の金属部分を触った時に、

感電まではしなくてもピリピリする感覚を経験したことはないでしょうか?

このピリピリする感覚は、電源プラグを逆に刺し直すと低減することがあります。

感電を避けるという観点だけから見ても、電気製品の電源プラグの刺し方で差が生じるのです。

自分は今まで、AC電源の極性については、

感電を避ける理由で「大地に対して電位差が生じないように」意識していました。

 

 ところが、今日初めて、

電源プラグの刺し方によってはWifiルーターが不安定になる(!)

という記事を見つけました!

Wifi系の機器は電源ノイズが大敵だと。

そして、「Wifiを含めたネットワーク機器の電源は、極性を合わせてAC電源に繋ぐべきだ」

とも書かれていました!

Wifiを使うスマートプラグに接続の極性があるのも、そういう理由だったのか!

と初めて納得出来ました。

 

 

 

また、自宅のWebサーバー、ルーター、ハブ等、

全て電源の極性を合わせて、正しく接続してみようと考えているところです。 

 

<参考資料>

 

 

NetCommons3.3.6リリース!

 最新版 NetCommons3.3.6 が、ほぼ1年ぶりにリリースされました!

「重大なセキュリティバグの修正」が含まれるとのことでしたので、

先ほどupdateを済ませました。

関係の方々に感謝申し上げます!

 

接続切れてたBluetoothマウスが使えるようになった件

 仕事で使っているモバイルPCのマウスですが、

Bluetoothマウスの接続切れが、設定変更等どうやっても直せませんでした。

代わりにUSBポートに無線レシーバーを刺してワイヤレスマウスを使っていました。

Bluetooth機能がPCに内蔵されているのに、仕方なくこの手を使っていたんです。

で、つい最近、OSやドライバも頻繁にアップデートしているんだから、もしかしてと思い、

Bluetoothマウスを繋いでみました。

そうしたら、接続切れがうそのように無くなっていて快適にマウスが使えるんですね!

今は安定してBluetoothマウスが使えています。

OS、ドライバーが最新のものになったからだろうと、その時あまり深くは考えませんでした。

今日、何気なくBluetooth関連の検索をしてみて初めて分かったんですが、

Bluetooth規格もどんどんヴァージョンアップされていて、現在はv5.2なんだそうです。

そしてこのBluetoothのヴァージョンアップは、ファームウェアをアップデートしないとダメなんです。

ファームウェアということは、Bluetoothデバイスのハードウェアを直接制御するプログラムなので、PC本体のメーカーの提供がないとダメな訳です。

OSやドライバーのアップデートではダメなんですね。

幸い、自分の使っているDELL社は、ファームウェア(BIOSも)、ドライバー等のアップデートを頻繁に出してくれています。

他のメーカーも、おそらくこのようなサポートをしているんじゃないでしょうか?

Bluetoothマウスの接続が改善されたのは、ファームウェアアップデートのおかげだったかもしれないのです。

また、他のデバイスのファームウェアアップデートでも、基本的機能の追加や改善が期待できると思います。

これからも、特にIT機器の進化の度合いは加速していくと思われます。

そんな中で、デバイスに新機能が必要になったとします。

どうすればいいか?

昔ならハードウェアを交換するしかなかったと思います。

現在では、ファームウェア、BIOSのアップデートにより、

ある程度のハードウェア更新が可能になっているという概念なんだと思います。(間違っていたらご指摘願います・・・)