とある５丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。
Raspberry PI 3に新しいOSをインストールしてNASを立てようとしたところ、どうもうまく行かない。マイクロSDカードが書き込みができなくなっている。
そう言えば、このマイクロSDカードをどこで買ったのか調べてみるとアマゾンだった。アマゾンなどのネットショップは購入履歴が残っているので、いついくらか買ったか、購入保証になるから便利である。お店で買ったらそうはいかない。
このマイクロSDカードはトライセンドの製品である。しかも、アマゾン専売のメモリである。シリアルナンバー（小さくて読めない！）からトライセンドのサイトで調べると無期限保証となっている。アマゾンの購入履歴も見つかったので保障の条件は揃った。
2014年4月に購入した履歴があったので、試しにトライセンドのサイトからサポートの問い合わせをしてみる。無期限保証の看板に偽りがなければ、何らかのアクションをしてくれるはずである。
さて、どうなるか・・・。
Windows10のエクスプローラーのPCのところを見ると、ディスクが真っ赤になっていた。このディスクはDドライブでユーザーデータ用の2TBのハードディスクである。
ユーザーのフォルダをいろいろとプロバティで残りディスクを見てみると（ディスク使用量のよいユーティリティがあるはず）、Dropboxが異常にディスクを食っている。Dropboxの各フォルダを見てみると、ありました、データバックアップのフォルダがとても大きい容量になっている。原因は、EaseUS Todo BackupのバックアップファイルがDropboxに同期されていたことだった。
今回何気にEaseUS Todo BackupのバックアップをQNAPのバックアップ共有フォルダに指定したため、フォルダがDropbox経由でブーメランのごとくPCに同期してしまった。それで、大きなバックアップファイルが同期されて、ディスクの容量が足りなくなってしまったわけである。これは自分のミス。
そこで、PCのバックアップ用にQNAPにフォルダを作成する。これでPCに同期を取らないはずである
以上でディスクは随分空いた。これで作業完了。
お客さんのサイトのテストサイトを自分のところで運用しています。テストサイトを運用しているのはさくらインターネットのVPSなのですが、このサーバーのOSが古くなってきたので別のサーバーに移したいと考えました。移行先はとりあえず、社内のQNAPのDockerコンテナにします。
大量のHTMLファイルを新しいサーバーにコピーします。このサイトは構成が古く基本はHTMLファイルのみで動いています。コピーすれば移行完了と思いきや・・・・。
そう言えば、SSIを使っていたのでした。共通のメニューやフッタが表示できません。Webブラウザでソースを見てみると、
<!--#include virtual="/include/gnavi.html" -->がそのまま出力されて、読み込むべきファイルを展開していません。
「apache ssi 有効」でGoogleさんに聞いて出てきたサイトによると、まず疑うのはSSIの設定している.htaccessを確認です。
Options IncludesでSSLを有効になっていることを確認します。
これは既に設定されていました。
もしかしたら、.htaccessが有効になっていないかも確認します。次に疑うのはhttpd.confでしょうか？
AllowOverride Allで有効になっていました。ファイルの改行コードがLFにしたりしました。念のためにHTTPDコンテナを再起動してみます。
それでも動きません。
.htaccessにrewriteの設定もしていましたので、リダイレクトができているかを確認します。
リダイレクトできていません。もしかしたら・・・・。
httpd -Mをコンテナにアクセスして叩いてみると、mod_rewriteとmod_includeが出てきません。必要なモジュールを有効になっていないようです。そこでhttpd.conf、
LoadModule include_module modules/mod_include.so
LoadModule rewrite_module modules/mod_rewrite.soの2行のコメント（＃）を外してモジュールを有効にします。そしてApacheを再起動します。
無事にSSIが有効になって、メニューとフッタがインクルードファイルから展開して表示できました。単純にモジュールが有効になっていなかったの原因でした。
以上、今回の教訓としては、
Googleさんに聞いて出てきたサイトを、そのまま信じても解決しないよ。
という話しでした。
ポチップ
ポチップ
突然Windows10のPCが起動できなくなった。青い画面でRecoveryと表示される。久しぶりのブルースクリーンである。
まずは起動できないときの定番の方法としてWindows10の回復ドライブで起動する。USBメモリで回復ドライブを作っておいてよかった。
スタートアップ修復をやったが修復できなかった。次にシステムの復元をしても復元ポイントが見当たらないせいか何もできなかった。
これは困ったと思って、次の手段を考える。そう言えば、起動できなくなった前はWindows Updateをやったんだっけと思い出す。と言うことは、起動できなくなった原因はアップデートなのである。焦るとまともな考えに至らない。焦ってはダメ。
今度は更新プログラムのアンインストールをやってみる。しかし、何も変わった様子もない。ますます困った。
ここで一旦再起動してみる。すると、何事もなかったように起動できた。これはとても不思議？？？
先ほどの更新プログラムのアンインストールがうまくいったものと自分に言い聞かせる。PCなんて悩んではだめ。結果オーライ。
で、トラブルの元となったWindows Updateを再度やってみる。今度はうまく再起動できた。これで何とかなった。
四半世紀以上もPCを扱ってきたけど、予期せぬトラブルで焦ってやらかすのはいつものこと。
自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。
お客さんからの依頼でヤマハのRTX1210の設定をした。今回、RTX1210の設定は初めて。
Webでの管理画面が変わっている。以前のRTX1100とかだと、コマンドの設定が中心でWebからだと設定項目が少なかった。RTX820とか小さめのルーターに近いような設定ができるようになった。
でも、Webからの設定はちまちまと面倒だから、今まで使っていたRTX1100からの設定情報をtftpで流し込む。とても楽チン。
そう言えば、このRTX1100は10年くらい使っていたけど、トラブル無しだった。10年間電入れっぱなし。ヤマハのルーターの信頼性は高い。お客さんのほうもヤマハのルーターの信用は高い。10箇所くらい店舗のすべてヤマハのルーターを入れている。
今回も、こちらで設定情報を流し込んでからルーターをお客さんのほうに送っていた。お客さんがルーターをネットワークにつなげて作業完了であった。大抵は、これでトラブルなく開通する。
しかし、今回は他の店舗と若干ネットワーク構成が違うため、念のために出張対応する。インターネットと社内VPNを今までは一緒のフレッツ回線で接続していたが、今回は2回線を別々にするという、少し贅沢な構成となる。最初VLANで分けようかと提案したが、シンプルに行きたいというお客さんからの要望であった。
おそらくルーターを回線につなげて完了となると思うけど、予想外の展開でトラブルになるかもしれない。
それと、RTX1210はシリアルのCOMポートがなくなって、コンソールポートになったのね。慌ててコンソールケーブルを手配した。RTX1210を送った後にケーブルが到着したので、接続できるかまだ試していない。
おそらくこのケーブルで大丈夫だと思うけど、現地で試してみよう。ヤマハ純正のコンソールケーブルはあるけど、値段が高いし今さらシリアルはないでしょ、ということでUSBに直接つなげるケーブルにした。
自社のQNAPサーバーでGitlabをDockerコンテナを動かしているけど、バージョンアップしろ、って出てくる。赤い表示はとても気になる。
自分でメンテナンスをしなければいけいないのはオンプレミスの面倒なところ。
現在は12.7.6である（上の画像では13．0．0になっているけど、最初のスクリーンショットを取り忘れた）。Rubyで書かれたサイトのバージョンアップはうまく行ったためしがない。Rubyのサイトのバージョンアップをしていると、Rubyのためかサイトのためか、バージョンアップしているのかわからなくなるのが辛い。
このままでは放っておけないので、重い腰を上げてGitlabをバージョンアップしてみる。下調べすると、とてもGitlabのバージョンアップをするのに面倒なことが書いてある。一発でバージョンアップできないようだ。Gitlabのサポートページによると、とっても簡単だと書いてあるけど、これは信じてはいけない。
参考にしたサイトは以下のサイトである。
それとGitlabのサポートページに書いてあるメジャーバージョンアップの項目である。
ようするにメジャーバージョンアップは一つづつやれってこと。試しに一気にlatestにまでバージョンアップしたら、案の定動かなかった。つまり、自分のところではGitlabのサポートページに従うと、
12.7.6 -> 12.10.0 -> 13.0.0 -> latest(13.2.1)
と3回の作業が必要となる。12.10.0でデーターベースのPostgreSQLがバージョンしたらしくてマイナーバージョンアップでも一旦バージョンアップしなくていけないそうだ（そんなの知るか！状態）。
念のためにその都度バックアップをとっておく。QNAPのContainerStationを使いながら、以下の操作を繰り返す。
やることは単純だけど、これを3回繰り返すと無事に最新のGitlabにバージョンアップされた。Gitlabのサポートページの言ったとおり簡単だった？
だけど、「データーベースのバージョンアップも途中でやれ」って、あるサイトに書かれていたけど、バージョンアップでコンテナを起動するたびに、自動的にデーターベースのマイグレーションが実行しているようなので、データーベースのバージョンアップはやる必要はなかった。これは後で書いてあるOmnibus GitLab packageのおかげだったのかな？
ついでに同じくRubyで動いているRedmineのコンテナもバージョンアップしておく。こちらは一度プラグインを削除してから、一気に最新版にバージョンをあげる。こちらもコンテナのイメージのバージョンを最新版にして、今のコンテナを削除してから起動する。問題無く最新バージョンにアップデートしてくれた。
以上で、鬼門であるRubyで動いているサイトのバージョンアップが完了した。何かトラブルがあるとRubyのシステムはお手上げ。
そう言えばGilabでデーターベースはPostgreSQLだけど、同じQNAPのPostgreSQLを接続しに行かないなと思ったら、Gitlabのコンテナの中でPostgreSQLも含んで動かしているのね。それがOmnibus GitLab packageだそうだ。初めって知った。もっとドキュメントを読めや。＞ 自分
ポチップ
ポチップ
ポチップSambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。
RedmineとGitlabのリポジトリの連携をした。やることは以前の記事と同じだけど、最初はうまくできなかった。
以上を設定してRedmineのプロジェクトのリポジトリタブにアクセスすると、505インターナルエラーが出てしまって困ったけど、これって裏で一生懸命にリポジトリの処理しているから時間がかかっているだけだった。しばらくすると、正常にリポジトリの表示ができた。
あと、今までのGitlabでクローンするときはHTTPSでアクセスすると、何かライブラリのトラブルで認証のエラーをしていたけど、これがなくなっていた。これはバージョンアップしておいてよかった一つ。
大昔にbasercmsで開発したサイトのメンテナンス依頼が久々に来た。単にメールフォームの項目の追加の依頼だった。
こちらで作業を完了し終了だと思いきや、お客さんからお怒りの連絡が入る。何でも画面に
不正なリクエストと判断されました。 （type:auth）バリデーションまたはコントローラ／アクションの不一致によるエラーです。
となるらしい。そんなときに限って、どういう手順で発生したかも教えてくれない。
こちらもテストも完了しているし、ユーザーのPC環境かと疑ったけど、お客さんのお客さんでも発生しているからって言われて、こちらのせいになってしまった。
ここらで投げ出したい気分になっている。そんなにお金をもらえないし・・・。
間に入っている会社の人がスマートフォンで発生すると言われた。こちらも試してみるとエラーが出た。たまたまhttpsではなくhttpのSSL無しでアクセスすると障害の確認ができたみたいだった。SSLありだと正常に動作する。どうしてこれで動くのか原因を追及するのは時間がないのでやめておく。
しかしながら、こちらは既にサイトをSSL化したものと思い込んでした。しかしhttpでもアクセスできてしまうサイトだった。そもそもそれが障害の始まり。
SSLに対応したのはお客さんなのです。この作業は私は携わっていないし関知していない。以前、httpsに対応した方がいいよ、と言っておいたけど、いつの間にか対応していたのでこちらは何も確認していなかった。何で私がやらなかったかは各会社の事情なのでお察しください。
SSL化するのであれば、httpからhttpsへの強制遷移とかrewriteの設定までしなければいけない。サイトの中を調べてみるとURL直書きなんて残っていたので、httpsからhttpに遷移してしまうリンクなんてありました。
キチンと.htaccessにhttpsに遷移するようにmod_rewriteの設定を書いた。それで再度メールのテストすると正常に動作することを確認した。httpでアクセスしてもhttpsに遷移することも確認した。これで不正なリクエストのエラーが出ないようになったはず。
だけど、作業料が発生しないサービスの作業が多すぎるな。自分の会社としては、これではいけない。
このサイトのメンテナンスはこれでおしまい。
以下は愚痴に近いもの・・・。
せっかくbaserCMSとかWordpressでサイトを作っても、メンテナンスはユーザーさんがやらない（やる気がない）とか多いな。それで何もしなくて放っておくから、古いbaserCMSとかWordpressのシステムのままで悪い人の踏み台サーバーになってしまうことも起きる。開発段階が終わってメンテナンス段階に移ったら、最低限baserCMSとかWordpressのアップデートをやって欲しい（それか依頼してほしい）と思う。それができないのであれは、素のHTMLで作っておけばいいのにと思う。
Gmailの迷惑メールがやけに多いと思ったら、ハッカーさんからたくさんメールをいただいた。
差出人は違うけど、みんな同じところからなんだろうな。何かあったら怖いからメールの中身は見ずに削除しておく。
相変わらずThunderbirdの迷惑メールフィルターには引っかからない。学習させても学習してくれないので、覚えさせがいがThunderbirdには全くない。どうしてThunderbirdの迷惑メールフィルターって、頭悪いんだろうか？？？
と言いつつ、たまにThunderbirdを開いて（Gmailを常用）、受信トレイの迷惑メールを掃除してやる。ぼぼ、ある程度フォルダへの振り分けフィルタで分類すると、残り9割は迷惑メールにとなる。
迷惑メールと言えば、自分に楽天関係のメールを送られても、それば全部迷惑メールとなる。だって、楽天にアカウントを持っていないもの。楽天アカウントを停止したと言われても、それは停止しているから、と突っ込んでおく。
あと、アマゾンのアカウントロックとか支払い情報の更新も全部迷惑メールと思った方がよい。
ポチップ郵便で送ってきたDMに受取拒否スタンプを押して捺印をして郵便ポストに入れると、心ある業者であれば送ってこなくなる。ただし、心ある業者ならばね。ヤマト運輸のＤＭ便はまた違うので注意のこと。
この迷惑メールの詳しい情報は以下の記事に書かれている。
先日はWordpressのGutenbergはいいかもな、と褒めたことを書きましたが、最近はやっぱり使いにくくなりました。
まずはブロックを追加するときに、記事中の表示される＋のアイコンをクリックしてブロックを追加しますが、最近は追加するブロックの種類がおかしくなってしまいました。こんな感じで普段使わないようなブロックが表示されてしまします。
今までは、ここから段落ブロックとか画像ブロックを選んで挿入していましたが出てこなくなりました。今表示してくるブロックは、普段使わないブロックばかりです。このプラスアイコンをクリックしてもこれだと使えません。こちらのブロックを選択する方法があるのでしょうか？ ブロックマネージャを探しても見つかりませんでした。
仕方ないので画面左上のブラスアイコンをクリックして、画面の左にブロック一覧を表示するようにしています。こちらが本来の使い方なのでしょうか？ だたし、画面上のプラスアイコンをクリックすると左のブロック一覧は消えてしまうという謎の動作をしてくれます。
最近はGutenbergのブロックが多すぎて選択するのも手間がかかりますので、ブロックマネージャで選択できるブロックを絞り込んでいます。
あと、Gutenbergで気になるのはWordpressの記事の埋め込みが一発でできなくなったことです。以前は、貼り付けたいWordpressの記事のURLをコピー＆ペーストすれば、一発で埋め込んでくれたのですが、これができなくなりました。今は一旦Wordpressの埋め込みブロックを挿入してから、Wordpressの記事のURLを設定することになります。多少面倒くさくなっています。
突然操作方法が変わるのはWordpressのよくあることなのですが、今回は手順が増えるのでいただけません。これだからアンチGutenbergの人が増えるのではないでしょうか？
あと、以上が自分の設定が原因だったら、誰か教えてくださいね。
＋のアイコンをクリックしてブロックを追加したときに表示するアイコンの件は修正されていました。
しかしながら、「Convert to block」ボタンがクラシックブロックの上に移動したけど、こちらのボタンは本文にショートカットがあるとブロックに変換できないことがあります。こちらは仕様なのかな？
Gutenbergは絶賛開発中って感じだな。
ようやくCentOS＋TeraStarion(iSCSI)のファイルサーバーを停止しました。稼働し始めて12年でした。ノートラブルでよくもまあ動き続けたものです。その間、大きなトラブルもなしで、もちろんデータの消失もありません。
トラブルというとTeraStarionのディスク交換を1回しただけでした。しかも、最近ですので稼働して12年もディスクは回りっぱなしです。
CentOSを動かしているサーバーは、マザーボードから自分で組んだものですし、TeraStarionといい、使っているディスクといい、今回は大当たりを引いたものです。このサーバーは出来過ぎの部類でしょう。
今考えられる長時間トラブル無しに動作した理由としては、半年に一回のファン周りの埃の除去くらいでしょうか。特にCPUファンは念入りに埃をエアダスターで飛ばしています。サーバーは熱に弱そうですので、冷却には気を使っていました。
ただし、CentOSのバージョンも古くなってアップデートも終了仕掛けていますし、TeraStarionなんてファームウェアのアップデートがバッファローから流れてきたこともありません。いつトラブルが起きるかもしれませんので、12年間お疲れ様ということでサーバーを停止することにしました。これからは代わりのQNAPで運用していきす。
ポチップ ポチップ ポチップSambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。
サーバーを停止してから何もトラブルがなさそうだから、正常にサーバーの移行ができたみたい。
