花豆を買って帰りました

シーズン最後のスキー帰りに花豆ゲット

シーズン最後のスキーに、湯の丸スキー場に行きました。帰りに恒例の昼食として小木曽製粉所上田店の蕎麦ですが、通り道の温泉施設 湯楽里館に回りました。

約1年前の記憶にあった建物は果物や野菜の店

久しぶりに地ビールを飲みたくなり、購入を考えて少し回り道して湯楽里館に立寄ったのですが、購入の記憶が残る建物には地ビールがありませんでした。そこは果物や野菜を置く店舗に変更になっていて、ここで目に付いたのが乾燥した紫花豆で、調理したこともなくて迷いましたが購入しました。

重量記載はなく価格と生産者名のみ

特に袋には重さが書かれてなく、ラベルには生産者の名前があり価格は700円と650円でした。品質と価格差に因果関係を見いだせずに、安い650円の物を選んで買いました。帰ってから重さを測ると丁度300gでした。

自分で調理が必要な乾燥している花豆を購入したのは初めてです。金額的に高いのか安いのかも分かりませんし、調理方法も知りません。

思っていた以上に貴重な食材らしい

楽天とかでの販売情報からは、思ってた以上に高価な食材らしく、300g / 650円はかなり安い買い物らしいです。

何気なく食べていたけど、でもどのような物

後から色々知らべてみると正式名称は、ベニバナインゲンで、メキシコの高原原産で、導入当初は観賞用で暖かい地域では、花が咲いても実を付けないらしいです。寒冷な場所として栽培地域が特定されるため、長野県や群馬県の高地で栽培されているようです。

ネットの情報ですが、農家で花豆が売られていた場所には、水で戻すのに4日から7日位必要だと書かれていたらしく、それを検証した内容が説明されていて、その記事では 3日位で重さが頭打ちになると書かれてました。

これらのネット情報を参考にして、水で戻す作業をしています。

自分で吸水の検証、最適は1週間位か

自分でも吸水の検証をしてみたのが、次の記載ですが、4日過ぎても少しずつ増加しているようで、まだ水に浮いていて硬い豆も存在しているので、本当にちゃんとした吸水をさせるなら1週間位が妥当かと思います。

  • 3/14 夕方 300g 吸水開始
  • 3/15 07:00 323g
  • 3/15 19:00 650g
  • 3/16 06:50 702g
  • 3/16 20:45 739g
  • 3/17 06:30 745g
  • 3/17 20:30 761g
  • 3/18 07:20 768g
  • 3/18 21:00 780g
  • 3/19 06:30 787g
  • 3/19 19:00 795g (300g ⇒ 800g 吸水5日)

1週間は待てずに硬めのものを選別

約1日で皮が水を吸い、少しずつ中に浸透していくのでしょうか

吸水を待つのが我慢できずに一部の豆を炊き込んでみました。

炊飯時に花豆を混ぜ炊き込み御飯

炊飯時に混ぜて炊き込む方法は昔からあって、色々な豆で行われているので、水を吸わせても硬めだった豆を選別して、適当な分量を混ぜて炊き込みご飯を作ってみました。

ネットで紫花豆の炊き込みご飯を見掛けない

高い花豆をご飯に炊き込むのは勿体無いから作らないのでしょうか、特に違和感なく美味しくいただけます。

食べた感想は、思っていたより歯応えがあって、一般的な栗ご飯のような感じです。花豆で炊き込みご飯の情報をネットで見掛けませんが、これもありかなと思います。

紫花豆を単体で少し甘く煮込んで、市販のものと比較を楽しんでみようと思います。

オールシーズンタイヤ

もう今シーズンのスキーも終わり

先週金曜日の3/13で、今シーズンのスキーは滑り納めにしました。その2週間前に雪の降った後の地蔵峠を上ったのですが、新たに履き替えたオールシーズンタイヤを試す機会となりました。

雪面も何とか走れそう

雪面に食い付くとはお世辞にも言えませんが、滑りながらもそこそこ登って行きました。

カーブの出口では、アスファルト道路のように勝手に進行方向に車が向くことはなく、滑らせないように慎重にアクセルワークとタイヤの向きを操る必要があります。

スタッドレスより慎重に運転かな

スタッドレスタイヤでも差の大小があるものの似たような動きなので、挙動の癖を理解すれば何の問題も無さそうです。

オールシーズンタイヤは、晩秋の北海道の布石ですが、コロナウイルスがどうなるのだろう、心配ですね。

東御市のワイナリー

湯楽里館がリニューアルしてた

湯の丸でスキーを楽しみ、地ビールが飲みたくなって、東御市の温泉施設の湯楽里館に久し振りに行ってみました。

そう言えば昨年風呂を利用した時に、2階を工事していたような気がします。

施設の配置が変わっていて、2階には東御市のワイナリーを紹介するディスプレイが置かれ、有料でワインの試飲ができるコーナーがありました。

話好きな感じのお姉さんが親切です

市内にワイナリーが10箇所程あるらしく、ブドウの栽培をして、他に依頼してワインを製造している農園もあり、それらも合わせると20箇所位になると教えてくれました。

今回は何気なく立寄ったのですが、収穫がありました。

公開ウェブの障害

前触れも無くサーバーダウン

安定していたのに、突然に死活監視メールが飛び交う事態になってしまいました。最初は気に止めていなかったのですが、確認すると確かに動作していないように見えました。

2020年3月7日 10:30 頃から発生、復旧は 14:00 少し前までの3時間半の間、人的ミスが原因でした。

公開ウェブサーバーにアクセスしても繋がらなくて、IPV4のプライベートアドレスで SSHでの接続ができない。でも ping には反応していました。

システムリブートで効果無し

IPV6 からリモートで接続可能

手っ取り早い方法のシステムリブートを試みるも成果なし、試しにと思い IPV6のアドレスから SSHすると接続できました。

ログインで IPV4の IPアドレス無し

ifconfig コマンドで、振られているアドレスを確認するとイーサネットのポートの IPアドレスの IPV4が消えていて、 IPV6側は普通に設定されていました。

色々な事を試しましたが効果が無く、何故か DHCP で自動で割振られるアドレスは問題無く設定されるようです。

原点に戻って落着いて考え直し

障害を大きく見ると今までの経験からは、ハードの故障、ソフトのバクや設定の誤り、それと人的ミスが関係する場合が多いと考えられるので、色々な場面を考え直して見回しました。

えっそう言えば作業に新しく接続した

あっ…と気が付いたのは、不要な CD / DVD を廃棄する作業をしていて、中のデータを取出しまとめて、保管していた CD を廃棄しようと考えサーバーに転送していました。

無線LANより安定して早い有線のイーサネットを利用しようと思い、繋いだのが障害を作った原因でした。

普段は無線LANでしか使用していない常用PCの有線側に固定アドレスを設定していたらしく、たまたま公開ウェブサーバーのアドレスと被っていました。

やってしまった接続ミス

何と言うミスで障害を招いてしまったのか、情けない人的ミスでした。思考や記憶、判断力等が衰えてきているのは仕方のない事ですが、3時間半も対処に掛かり情け無いと感じます。

新型肺炎今後はどうなるの?

新型コロナの先が見えません

2020/03 で学校に休校指示を出した新型コロナウイルスですが、北海道では全域で拡散しているようで、東京オリンピックや札幌開催のマラソン等先行きが見えません。

旧型の肺炎球菌ワクチンなら

昨年市役所から通知が来ていて、再通知を受け今年になって肺炎の23種混合ワクチンの接種は受けました。でも効かない菌には意味がありませんね。高齢になって亡くなる原因は、肺炎と癌がほとんどらしいですね。

予定ではオリンピック後の秋

ウラシマツツジの紅葉が見たい

半年先の事ですが、例年のように大雪山系の北側に位置する愛山渓温泉から登り、究極の紅葉の景色を見たいと思っています。

例年は夏から秋にかけて長期に道内で滞在することが多く、昨年は台風で被害の大きかった道路の復旧が遅れると思い込み、夏前に訪れてしまい行けませんでした。

復旧を待ち望んだ愛山渓温泉への道路は、北海道を離れて帰宅した2週間後位に、開通した事をニュースで知りました。知っていれば帰らずに秋まで滞在していた気がします。、

気が付かなかったけど復旧工事だったの?

そう言えば長期滞在していたキャンプ場の横から旭峠を越えて愛山渓温泉の方へ向かう林道にトラックが出入りしてました。これが国道から愛山渓温泉への流された道路の復旧だったのでしょうか。

今年こそ再チャレンジしたいので成り行きが気掛かりです。

ブラック企業?

令和元年に流れで勤めてしまった仕事

今は平日の昼間に仕事に通ってます。かなり昔、福島の原子力発電所が東日本大震災でダメージを受けた頃に、長く勤めた会社グループを早期退職。その直後は失業保険で生活してから、目に付いた数社の派遣会社に登録したのです。

そのころから短期の紹介メール等は受取ってましたが、一度も仕事をしないまま忘れてしまった派遣会社も数多くありました。その様な派遣会社から時々電話があり、仕事を紹介される事があります。

数ある登録派遣会社の1つから紹介され

そんな紹介の物件ですから、引受手のいないような内容や条件の物です、皆に避けられる仕事内容だろうとの予想はします。内容的に自分にできる内容なら暇な時間もあるので、受けても良いかなとの思いもあって勧誘に負けました。

面接を受け、お試しで仕事を始め

今の仕事はその様な経緯で、長続きする人は少ないだろうと思うキツイ内容ですが、もう4ヶ月続いてます。

私も色々な所に通ってみましたが、家に近く社会保険にも加入で、今までの仕事と比べると時給1,150円と高時給な条件です。それと経験のない未知の仕事に触れてみたい思いもあって工場見学となったのでした。

お試し的に通い始めて、これは長期的には無理だなと思ったのですが、営業に断るタイミングを逸している間に新しい延長の契約書が家に送られてきてしまいました。

それでも無理だと判断して断っても良かったのですが、新しい契約書に書かれている期日の3月末までは続けてみようかと思い直して現在に至ってます。

どのような会社かと言うと

この会社の仕事内容は、大きな物から小さな物まで各種のポンプを分解してパーツに分けて洗浄し、不良品を選別廃棄して、再生品や新品のパーツを組合せて、再組立し製品として戻して出荷する作業をしているようです。

どのような所で使用されているポンプなのかの詳細は知りませんが、国内のシェアは高いらしいです。利用先はトンネルや池、沼、湖、海辺とかなのでしょうか、色々な付着物があり磯の香りがするものもあります。

担当している仕事は

私が担当しているのは、分解されたパーツを洗浄や研磨して再生品のパーツとして戻す仕事です。

洗浄では、泥やカルキが固まって厚く付着したり、錆びていたりする物を空気圧で太いピアノ線を打出すタガネや、細い金属ワイヤーを高速で回転させて削り取るバフ、1ミリ程の小さな鉄と研磨材を混ぜた砂状の物を高速で打ち付けてショット洗浄する機械があって、状況でそれらを組合せて実施します。

担当している仕事上の危険性

削れた物が飛び散ったり、バフの細い金属線が折れたり抜けたりして刺さる危険があるので、作業では支給されているメガネの着用が指示されています。

回転するバフの金属線の抑えが不適格であったり、集中力を切らせた時に持っている機器が弾かれて身体に触れ怪我をすることもあります。

折れたり抜けたりした細い金属片は、色々な場所に刺さったり付着したりしています。靴底にも多数の金属片が刺さり、突き抜けて足に刺さって知らない間に出血していることも日常茶飯事です。

短期間に自分にも起きた怪我

バフで研磨している時に集中力を切らし、飛ばされ回転した金属線が右手首に触れ、布製の手袋の手首付近がズタズタになって皮膚も擦っていたことがありました。これも労災の1つだと思いますが、自分の不注意なので大袈裟にしないで静かに直しました。

この程度の軽微な怪我なら時々起きていますので、危険な仕事内容だろうと思います。

目にゴミが入ったような違和感

そんな中で、仕事の終了頃に左眼に異物が入ったようで、瞬きするとゴソゴソした感じで違和感がありました。目にゴミが入る程度は日常的に普通にある事なので、原因を特定できないままその日は寝ました。

当然と言えば当然ですが、自分で鏡に向かって見ても分からないし、妻に言っても老眼の目で近くの小さな物を見付けることなどできません。

翌朝になっても左眼の違和感が続いてましたが、その状況についてライン長に話をして眼科に行く決心をしました。しかし、行こうとした眼科がその日は定休日のようで持越しになりました。

違和感を感じた日から1日置いた3日目に、仕事を早退して眼科の診察を受けると、何かが目に付いているとの初期診断です。

単にゴミが入って取れなかった訳ではなかった

麻酔をして除去手術が必要との説明がされました。

それなりに除去手術には費用も掛かるようなので、状況を派遣会社の営業に電話するとハッキリしない返答を返されました。そうは言っても眼に刺さったままなのがわかっていて、何もしない選択肢はありません。

今までに労災になるような危険な場所や仕事の経験はなく、営業と眼科の担当者と電話で話してもらい除去手術を受けました。

除去手術内容は

時間を掛けながら、3度麻酔薬を点眼して刺さっていた金属片の除去です。説明では錆びていた金属が刺さっていたとの説明でした。もう少し奥まで刺さっていたら失明もあったとも言われました。

その日は、請求額の全額分の持ち合わせは無く、五千円だけを払って隣の薬局で除去して開いた穴を修復するような物だと思われますが、目薬を出してもらい帰宅しました。

派遣会社営業に対しての不信感

翌日になって派遣会社の営業に電話して、直接会って現場を確認してもらいましたが、発生日や場所の特定ができないから労災の申請はできないとか、申請しても受け付けられないと拒まれてしまいました。

同じ派遣会社からその会社で長く仕事している人が言うには、最近小さいものから大きなものまで多数の労災認定が出されていて目を付けられているので、自分達の首を絞める事になるから出せないのだとか世間話的に説明されました。

失明しちゃっていれば、放置はできないでしょうから仕方無く労災になっていたでしょう。(運良く?/運悪く?)紙一重で失明一歩手前だったので自己負担で怪我を直すことになったようです。

世間の評判は良いけど、ラ◯◯タッドってブラック企業?

ポンプのサ◯エー工業、派遣会社ラ◯◯タッドってブラック企業だったんですね、世間の評判は良いのですが、実態は違っていたと言うことなのでしょうね。

大げさや誇張でもなく事実を並べているだけなので、別に名前を隠す必要も無いとは思いますが、でもグーグルやヤフーの検索でブラックを検索キーにすると一対一で会社名が出るようになるのも少し可哀想かなと思い、一応名前の一部を伏せ字にしておきます。

失明していれば労災認定されていたのでしょうか、運悪く失明までは至らなかったので自己負担3割の社会保険での処置になったのでしょうね。納得できないまま後日保険証を持って精算に行ってきました。

失明した方が良かったのか、失明しなくて良かったのか心境としては複雑ですね。ただ、短い残りの人生なので、失明して北海道の大自然で極楽の様な景色を見る趣味が絶たれなかったことを良しとしましょう。

それではいつ辞めることにするのか

この会社には、年配の人も多くて、派遣社員でも6年を越える人も多数いて、多分良い会社の1つなのだろうと思います。接してくれる人達の大半は親切で良い人達です。ただ私には先の人生の目標があって、長く伸ばしても勤めるのは夏までなのですが、今回の事もあって早めに辞めようと決意しました。

お金は多くても困らないですが、足りなくて困っているわけでもないので、もっと早く辞めても良いのですが、今の契約書の期日までは通うつもりでいます。

他に辞めたい理由

ついでに書き留めます。食堂には『ハラスメントは許しません…』的な内容が貼られてますが、多分私はイジメにあってます。本人がイジメられていると思っていなくて怒鳴りつけてしまいそうで恐いです。

志村けんの変なオジサンを思い出してしまう雰囲気の人がいて、私が作業している近くで視界の中にいます。その人の仮名を田町さんとしておきます。歳は本人が1だと答えました。考えられるのは、41/51/61/71/81 私より年上の 71 かとも思えるのですが、実際はよくわかりません。

それと別の派遣会社から来ている50代前半の血気盛んな人、仮名を石池さんとしておきます。この人は悪い人とは思えないのですが、田町さんのスピーカーとして難癖をつけてくることがあります。

田町さんと石池さんはとても仲が良くて、お互いに仕事が足りてないのか、サボるように時々つるんでます。情報交換も必要なので、それも別に悪い事ではありません。

直接言えずに言わせているようです

田町さんは直接私と目を合わすことはなくて、すれ違う時も目をそらしていて、ボソボソと呟きます。そして言い掛かりを付けたい時には石池さんを使って言い掛かりを付けてくるので、言ってる本人は内容をちゃんと理解していないらしく辻褄の合わない事を言ってきます。

先日も、いつも見ているけど仕事が遅いとか、研磨材が周りに散らばっていて滑るから時間の空いたときには掃除しろとか言い掛かりを言われました。私は仕事が多すぎて対応できていないのですが、ストーブの前で動かずにずっと他人を観察できるような時間が余っているなら手伝って掃除して欲しいです。

ほんとに暇そうでセレブに仕事

田町さんは、仕事が無くて暇らしく、休み時間や昼の休憩時間前には、必ずではないですがほとんど毎回のように、5分前や30分前位になるとエアガンで自分のホコリ落としを念入りに始めます。追われるように仕事している私には、時間を気にしていられる余裕があって羨ましい限りです。

仕事が足りないらしく他人を観察していられる

私はいくつもの作業を同時に効率よく行えとライン長から言われていて、平行して2人で行うような作業を1人でこなしているので、他人を観察する余裕等ありませんが、他人を観察していられるほどのセレブな仕事ぶりで、羨ましいかぎりです。

食堂で出された物に、自分の髪の毛を載せてクレームを言うのと同様な行為で言い掛かりを付けられたりしているようです。昭和のホームドラマで姑と小姑のイジメのような光景です。

私が心配することではないですが

作業が危険で仕事がキツくて、近くには姑と小姑のような人達からのイジメのように突かれたら長くは留まれないだろうと思います。まっ私が案ずる事では無いですけど。

会社を少しフォローしておきます

バレンタインデーには社員も派遣も分けずお菓子を集めた紙袋が渡されたり、くじ引きでビールや小物を配ったりと良い会社です。

夏を待たず3月で辞めるのは

派遣会社の営業に対する不信感が最大の要因ですが、仕事の嫌いな田町さんを近くで見ているのも腹立たしい気になりますし、仕事内容も危険で怪我をしても自分持ち、最近になってリスクに見合う時給でないと思える様になりました。

残りの日数はストレス解消しながら休み休みかな

何れにしても失明のリスクを孕んだ危険な仕事環境なので、仕事の数を減らしたいのが気持ちです。残り少ない人生、片目では景色も半減、マニアルの確認も支障がありそうに思えます。

最後に一言

このブログに訪れた人に一言です。感じ方には個人差があります。田町さんと石池さんの事はあくまで私が感じた事で、あちらから見たら私の方が変なオジサンと見えているのかも知れません。

物事は見る角度で見え方が違って見えたりするので、難しいですね。話半分で見てください。

退職して20日後位に追記

3月末でサ◯エー工業を辞めました。渡されていた契約書の期日がこの日だったので、区切りとして最後まで通いました。

最後の1月は長くて辛い日々でした。仕事が嫌いなわけではないのですが、前述の変な人達、田町さんと石池さんのコンビを見ているのが辛く毎日が地獄のようで1日過ぎる毎に安堵している始末でした。

まだ健康保険はそのまま

仕事中は社会保険に加入していました。辞めたので国民健康保険に変更しなければいけないのですが、営業からは返却用の通知と市役所に持って行く脱退証明書?が送られてくるので、それで手続きして返納してくださいと言われてますが、まだ届いていません。

4月中もこの今の健康保険証は有効なのでしょうか。少し疑問ですが、想像できないくらいの人達を抱える派遣会社なので指示が来るのを待つことにします。

今だに鉄粉が散らばってます

勤めている時は仕事柄、洗浄用の小さな丸い鉄粉が作業着や色々な個所に付着して、現地で落としても落とし切れない物が家の中に落ちてました。

1ミリにもみたない小さな鉄球なので、カーペットや掃除機の先端に付いた回る刷毛のような中に紛れ込む事が多く、取り切れなくて難儀しました。飛行機でも持ち上げる空気の力なので小さな鉄球も吸い込む事は吸い込むのですが、でも掃除機では中まで吸い込めないらしく床に残ったままになっていました。

洗濯した衣類の中にも残っている事があって、風呂上りに着ようと思い広げたらパラパラと音を立てて床に落ちる事もありました。

いつになったら片付くのやら

磁石を使い色々な場所を掃除しましたが、想像を越える程の量と数の微細な鉄が集まりました。たぶんまだ取り切れてないだろうと思ってます。

新型コロナと重なった通勤

今年になって世界的に猛威を奮いだした武漢発新型コロナウイルスですが、ちょうど私のサ◯エー工業通いと重なりました。仕事中の最後の1月位は工場長が毎朝非接触の体温計で、全員の体温を記録していました。辞めたのでその後の事は分かりません。

色々あってフォーシーズンタイヤ

古くなった脚と言うか、日常の友と言うか、あちこちに連れ出してくれている車ですが、ノーマルタイヤが摩耗して交換必須。
冬になると雪が降っても降らなくてもスタッドレスタイヤに履き換えていました。そして例年通り今シーズンもスタッドレスの状態でした。

予想はあっても動揺するメール

週末の仕事帰りに車の中で、訃報のタイトルが目に付くメールを受けました。本人は動揺したとは思っていませんが、周囲に対する注意が散漫になったのかもしれません。

注意が散漫になったのか、やってしまった

過去に一度だけ対向の自転車を避けるようにして、左折で左後輪を縁石に接触したことがあって、その時に凄く大きな音がして、注意して大回りしないと危険だと認識していました。
にもかかわらず同じ箇所で、同じ様に再び左折で縁石の上を通ってしまったようです。

前回と同様に暗い夜道で、畑と道の境目も認識できないような場所です。後で近くから確認して認識したのですが、低くて見え難いコンクリートの角が尖ったものでした。
年を取ると若い頃にはまず考えられない様な、単純なミスが色々な場面で増えてくるのを感じます。高齢者の運転による重大事故もこの延長線上にあるのだと頷ける気がします。

まさかのタイヤがパンク

1度目は特に被害は無かったようなのですが、2度目はタイヤがパンクしていてぺちゃんこです。訃報メールを受けても焼香に出向く事もできませんでした。

パンクはなかなか遭遇しないことの1つです。車では私が過去からの乗り継いだ歴史の中で、道路の陥没に気づかずに落ちてパンクしたのが1度記憶に残っているだけで、多分2度目だろうと思います。

さてどのように対処しようか

そんな経緯もあって、一部で話題になっているフォーシーズンタイヤを検討することにしました。
スタッドレスと比較すると氷上性能が劣るとか、雪上でも少し劣ると言われているようですが、ヨーロッパでは普及しているらしく、1つのスタッドレスでも新品と古くなってからでは性能が異なるので、過信しなければ特に問題無い様に思われます。

悩んだ末、丁度良いタイミングと判断

夏の終にノーマルタイヤで北海道に長期滞在して、秋の紅葉から季節の遷り変わりを楽しんでいて、降雪時期に近付くと潜在的な意識としてタイヤが気になってきます。

その様な中で、例年は夏からスタッドレスで訪れるのが良いのかと悩んでいました。解決策としてのフォーシーズンタイヤの選択は最高のチョイスかと思われます。

ネットで確認するとサイズあり

タイヤ市場では、フォーシーズンタイヤのメーカーを選択することもでき、推奨の安いタイヤも扱っているので、パンクしたスタッドレスタイヤを装着していたアルミフォイールにフォーシーズンタイヤを組合せて、元々のオリジナルの鉄フォイールとそれに装着されている古いノーマルタイヤも合わせて処分してもらいました。

フォーシーズンズタイヤの使い心地は

年間で履かせっ放しになるので摩耗の進みも速いと思いますが、使ってみないと分からないのでどの様に推移していくのか楽しみです。

平日は、新しく装着したタイヤで仕事場に通っていますが、スキー場にはまだ行けていません。試せるチャンスは近々来るだろうと思っています。

グーグルマップで店舗の評価を追加

その後グーグルマップのタイヤ市場に評価を追加しましたが、店舗で目に止まったらしくて店長名で返信がありました。(2020-02-02)

公開サーバー交換完了

大晦日から続いた移行作業

大晦日から自信のないまま公開サーバーを置き換えようと模索して、物理的にも旧 PogoPlug が設置されていたスペースに収まりました。

経験のないことで苦労の連続

終ってみれば簡単に事が推移したようにも思えますが、ブログの移行は苦労の連続で、有料プラグインでのマイグレーションではデータを移行するのも簡単らしく書かれていますが、次があるのかいつなのかも不明のまま出資するのに抵抗を感じて、現状のツールだけで進めたいと考えました。

バックアップもマイグレーションも有料オプション

バックアップツールで思い出したように、バックアップだけはしていましたが、このデータからリストアで新しいシステムに戻せるのだろうかと不安でした。結論から言うと PHP のバージョンも大きく変わっていて、直ぐにエラーとなり利用できませんでした。

結局、移行前のサーバーから移行後のサーバーに、ブログの本体である WordPress のディレクトリを rsync コマンドでフルコピーして、MariaDB のデータベースを設定して、アクセスできるユーザーの情報を WordPress のファイルに記述して、バックアップのデータからリストアを試みました。

rsyncでコピーしても同じ動作にならない

それでも移行元の動作状況とは、見た目も動きも程遠くてテーマの設定やら背景の画像やらとしばらく格闘しながら移行前の動作状態に近付けて行きました。

早いサーバーに移行できストレス減少

今回は、なかなか味わえない良い経験をさせていただきました。前のサーバーでは、非力過ぎて待ち時間が長かったのが、そこそこのレスポンスで稼働しているのは安心でき肩の荷が下りた気がします。

物理的にも入替えが終わり、一安心と思っていたのですが、スマホに大量のメールが届いていました。忘れてました大事なことを、データのバックアップ等をさせているサーバーを使い cron で、 ping / http / ssh で公開サーバーに対して5分毎にチェックをしているのです。

消すのも大変なほどのメールが溜まってしまい、慌てて更新しました。

死活チェックに振り回されました

実は、上手く対応できたと思ったのですが、単純に ping して結果をチェックする処理で、その後も5分毎にエラーメールが届いていました。IPv6 のアドレスが、誤って設定されたので気付き直したつもりが、使用を止めたつもりの旧公開サーバーのDNSで名前解決されていて、直したはずの新しいデータがそこには無くて、実在しない IPv6 アドレスに ping を送っていました。

調べてみるとゴーストのイタズラかな

resolv.conf に古いネームサーバーを参照する情報が残っているようで、わけのわからない結果を招いていました。この辺りの動作は何か良くわからない動きをするので困りものです。

/etc/dhcpcd.conf は要注意

対策できたと思って安心していると、その後も5分毎にエラーメールが届きます。更に調べるとエラーメールを送るそのサーバーは、固定アドレスを設定するために、 /etc/dhcpcd.conf の中に固定アドレスを記述しているのですが、一緒にネームサーバーも記述していて、稼働対象外のサーバーアドレスを指定していました。まともな動きをしないのは仕方ないですね。

稼働対象外のサーバーも元はマスターのネームサーバーで稼働していたものなので、定義を変えてスレーブで立上げ直して、しばらく残そうと思い、 /etc/bind/slaves のディレクトリを追加して、マスターから配布されるように設定したつもりでしたが、一向にファイルの配布が行われませんでした。

/etc/bind/slaves の所有者とアクセス権

配布されなかった理由は正確には不明ですが、ディレクトリのオーナーを bind にして、アクセス権を変更して、更に rndc reload のコマンドをマスター側とスレーブ側のサーバーで実行して少し経つとファイルの配布が行われたのを確認できました。

Webalizer も文字化けが解消

文字コードを修正してソースからメイクする情報がネット上にもあるのですが、その中で説明しているファイルを置いていたサーバーが現在接続できなくなっているようです。

最終的には何とか日本語化できたような感じです。見た目の文字列は日本語化されていない部分があちこちに見られますが、文字化けで読めない箇所はないようなので成功したと考えます。しばらくこのまま運用を続けたいと思います。

対策前は、漢字コードが昔懐かしい、euc で書かれていて、UTF-8 として表示しているのか、結果はこんな文字化けが起こって読めません。

文字化けしている表示

文字コードを UTF-8 に変換した結果は、次のような結果となって読めているようなので問題ないレベルになっていると思います。

コードを UTF-8 に変換した結果

家屋内のネームサーバー

ローカルのネームサーバー

細かいことは知りませんが、現在 IPv4で機能するネームサーバーを家の中に立てています。家屋内のプライベートアドレスを割り振る DHCPサーバーに、ローカルのネームサーバーのアドレスを渡して、IPv4 / IPv6 アドレス共に名前解決をしています。

日本国内では、IPv4/IPv6が混在しているらしい

ゆくゆくはネット環境が、IPv6の世界に完全移行して不要になるのだろうと思っています。趣味で北海道とか出歩くこともあって、旅先からリモートで家に置かれた公開サーバーを操作することも時々あるのですが、場所によっては IPv4 だったり IPv6だったりしています。

IPv4 なら家に置かれたホームゲートウェイで、入口のグローバルアドレスから家屋内に置かれたプライベートアドレスの公開サーバーにアドレス変換して接続しますが、IPv6 のアドレスは家屋内の機器にも一律に割り振られていて、外部に置かれた DDNS で名前から直接アドレスが引かれると、そのままダイレクトに機器に接続されるイメージなので家屋内にローカルのネームサーバーは不要のようです。

たぶん当面はローカルのネームサーバーが必要かと

いずれにしてもローカルで、IPv4 を併用している機器が家屋内に現存している限り、ローカルのネームサーバーが必要なのだろうと思っています。

公開Webサーバーをローカルネームサーバー仕立てます

そこで、ハード的には余裕のあるオーバースペックのラズパイで、このブログが利用している公開サーバーをローカルのネームサーバーの1つとして機能追加しようと考えたのですが、過去の立上げから長い年月が過ぎているので作業内容も曖昧です。次があるのかは分かりませんが、トラブった時の参考資料としても有効かと思いまとめることにしました。

ネームサーバーのBIND9 をインストール

次のファイルリストが、ネームサーバーの BIND9 をインストールした時の初期状態のファイル群です。以前にカスタマイズした時は、 db.root のファイルがあったようですが、同様のファイルが別の場所に移されたようです。 → /usr/share/dns/root.hints

root@web-server:~# ls -l /etc/bind
合計 48
-rw-r--r-- 1 root root 2761  6月 21  2019 bind.keys
-rw-r--r-- 1 root root  237  6月 21  2019 db.0
-rw-r--r-- 1 root root  271  6月 21  2019 db.127
-rw-r--r-- 1 root root  237  6月 21  2019 db.255
-rw-r--r-- 1 root root  353  6月 21  2019 db.empty
-rw-r--r-- 1 root root  270  6月 21  2019 db.local
-rw-r--r-- 1 root bind  463  6月 21  2019 named.conf
-rw-r--r-- 1 root bind  498  6月 21  2019 named.conf.default-zones
-rw-r--r-- 1 root bind  165  6月 21  2019 named.conf.local
-rw-r--r-- 1 root bind  846  6月 21  2019 named.conf.options
-rw-r----- 1 bind bind   77  1月  1 12:10 rndc.key
-rw-r--r-- 1 root root 1317  6月 21  2019 zones.rfc1918

db.root の移行は、named.conf.default-zones の中の頭の部分に記載されています。

複数サーバーを立て、マスターとスレーブに仕立てます

このラズパイサーバーをマスターにして、他に稼働するネームサーバーをスレーブとしてデータを受取りながら稼働するサーバーに仕立てる予定です。

bind.keys  …そのまま
db.0     …そのまま
db.127   …そのまま
db.255   …そのまま
db.empty …そのまま
db.local …そのまま
named.conf …そのまま
named.conf.default-zones …そのまま
named.conf.local   …変更する (自分で定義したいゾーンをここで指定する)
named.conf.options …変更する (全体的な動作を定義するらしい)
rndc.key      …そのまま
zones.rfc1918 …そのまま
ゾーンの定義はファイルを追加、ファィルとの対応を記述

自分で定義するゾーンファイルを作成して、このディレクトリに追加すると共に、このファイルが配布の元になるマスターか、配布されたコピーのスレーブなのか、更にはどこから配布を受取るのかや、どこに配布するのかも含めて、 named.conf.local ファイルに記述します。

サーバーの全体的な振舞を定義

また、ローカルのネットワークの流れや解決できない情報を上位のサーバーに渡す先についてのサーバー全体の動作に関する情報などは、 named.conf.options ファイルに記述するようです。

named.conf.options には、次のブルーの部分の追加と修正を行いました。どこからの情報かは不明ですが、いままで同様の設定で稼働しているので、深く考えずにそのまま移行します。

// LAN内のIPアドレスグループをLOCALと定義
acl "LOCAL" {
  192.168.11.0/24;
  240d:1a:34d:7f00::/64;
  localhost;
  localnets;
};

// ネームサーバー共通設定
options {
	directory "/var/cache/bind";

	// If there is a firewall between you and nameservers you want
	// to talk to, you may need to fix the firewall to allow multiple
	// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

	// If your ISP provided one or more IP addresses for stable 
	// nameservers, you probably want to use them as forwarders.  
	// Uncomment the following block, and insert the addresses replacing 
	// the all-0's placeholder.

	forwarders { 8.8.8.8; 8.8.4.4;};

        allow-query { LOCAL; };
        allow-query-cache { LOCAL; };

	allow-transfer  { none; };

	masterfile-format text;

	//========================================================================
	// If BIND logs error messages about the root key being expired,
	// you will need to update your keys.  See https://www.isc.org/bind-keys
	//========================================================================
	dnssec-validation auto;

	auth-nxdomain no;    # conform to RFC1035
	listen-on-v6 { any; };
};

192.168.11.0/24 が、IPv4 のローカルネットアドレスで、 240d:1a:〜::/64 が IPv6 のローカルネットアドレスです。

管理するゾーンの名前とアドレスの対応表を作ります

そして、自分で定義したゾーンファイルは、後で識別しやすいように 〜.zone をファイルの最後に付加しておくことにします。

sunao-mita.pgw.jp.zone      …名前からアドレスに変換する定義
11.168.192.rev.zone         …IPv4のアドレスから名前に変換する逆引きファイル
240d:1a:34d:7f00::.rev.zone …IPv6のアドレスから名前に変換する逆引きファイル
MyMemories.localdomain.zone …試験的に変換させるオマケのファイル

管理するゾーン定義の関連付け

初期の named.conf.local ファイルは、次のようになっているので対応するゾーンの定義と対応するファイル、マスターとして転送する場合は送り先のアドレス、スレーブとして受取るならマスターになるサーバーのアドレス等を記述します。

//
// Do any local configuration here
//
  // この部分にゾーン情報を追加します
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";  // コメントから有効に変更
定義の関連付け例

単純に単独で機能させるだけのサーバーなら、正引き逆引きの各ゾーン毎に定義して、次のような内容を追加します。この場合は、/etc/bind ディレクトリ下に sunao-mita.pgw.jp.zone と命名したファイルが置かれています。

シンプルな記述例、単独でファイル管理
zone "sunao-mita.pgw.jp" {
        type master;
        file "/etc/bind/sunao-mita.pgw.jp.zone";
};
マスターファイルを管理し、スレーブに転送

なお、複数のネームサーバーを稼働させていて、マスターのサーバーのデータを更新したら、スレーブ側のサーバーに自動転送させるには、各ゾーン毎に次のような記述を追加します。

zone "sunao-mita.pgw.jp" {
        type master;   // 転送先のスレーブサーバーを列記
        allow-transfer { 192.168.11.23; 192.168.11.20; 192.168.11.21; };
        notify yes;
        also-notify { 192.168.11.23; 192.168.11.20; 192.168.11.21; };
        file "/etc/bind/sunao-mita.pgw.jp.zone";
};

示したゾーンの定義は、マスターとして管理しスレーブ3台に配送する定義です。スレーブ側では、受取ったデータを自分で管理するマスターのデータと混乱しないように、slaves のディレクトリを作成してその中に受取るようにします。

スレーブで、マスターから受取るディレクトリを分ける
zone "sunao-mita.pgw.jp" {
        type slave;
        masters {
                192.168.11.2;  // マスターのデータを管理するサーバー
        };
        file "/etc/bind/slaves/sunao-mita.pgw.jp.zone";
};

マスターデータは、各ゾーン毎に定義するため、複数サーバーで、各ゾーン毎にマスターデータを管理するサーバーを決めて稼働することができます。

少し実行させてみて、スレーブ側のサーバーにマスターで更新した最新のシリアルナンバーのデータが配布されたようで、置かれているのを確認できたので、これで完了でしょう。

編集したマスターデータと配布されたコピー

スレーブにコピーされたデータは、マスター側の更新したデータを直接コピーしたものではなく、適度に編集されて配布されるようです。

参考までにマスター側の原本とスレーブ側のコピーの中身を表示しておきます。素人の記述内容に問題が多くて違いが大きいのかは分かりませんが…

;;  sunao-mita.pgw.jp

$TTL    86400
@      IN      SOA    sunao-mita.pgw.jp.  root.sunao-mita.pgw.jp. (
        2020010202      ;Serial
        3600            ;Refresh
        900             ;Retry
        604800          ;Expire
        86400           ;Minimum TTL
)
                IN      NS      dns.sunao-mita.pgw.jp.
                IN      NS      dns2.sunao-mita.pgw.jp.
                IN      NS      gate.sunao-mita.pgw.jp.
                IN      MX      10 mail.sunao-mita.pgw.jp.

                IN      A       192.168.11.2
                IN      AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
dns2            IN      A       192.168.11.20
dns             IN      A       192.168.11.2
ubuntu-sv       IN      A       192.168.11.199
rpi1-disk       IN      A       192.168.11.23
rpi1-disk       IN      AAAA    240d:1a:34d:7f00:11cf:af0d:3b62:8501
ubuntu-dtp      IN      A       192.168.11.100
gate            IN      A       192.168.11.1
virt            IN      A       192.168.11.105
Radio           IN      A       192.168.11.20
DebianPogo      IN      A       192.168.11.22
DebianPogo      IN      AAAA    240d:1a:34d:7f00:225:31ff:fe00:9df0
mail            IN      A       192.168.11.2
mail            IN      AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
PogoV6          IN      AAAA    240d:1a:34d:7f00:225:31ff:fe00:9df0
dns2            IN      AAAA    240d:1a:34d:7f00:ba27:ebff:feac:28a8
dns             IN      AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
www             IN      A       192.168.11.2
www             IN      AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
RadioV6         IN      AAAA    240d:1a:34d:7f00:ba27:ebff:feac:28a8
rpi1-com2       IN      A       192.168.11.21
rpi1-com2       IN      AAAA    240d:1a:34d:7f00:ba27:ebff:fe0c:5ef3
note            IN      A       192.168.11.51
note            IN      AAAA    240d:1a:34d:7f00:3906:1714:acef:3e46
web-server      IN      A       192.168.11.2
web-server      IN      AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae



collection      IN      CNAME   virt
share           IN      CNAME   rpi1-disk

なお、動きが把握できていませんが、記述ミスに気が付き修正してマスター側で bind9 を restart すると、内容が直ぐに反映しましたが、その後も配布されているにも関わらずスレーブ側のデータ内容は古いシリアルの物を受取っているままでした。

$ORIGIN .
$TTL 86400      ; 1 day
sunao-mita.pgw.jp       IN SOA  sunao-mita.pgw.jp. root.sunao-mita.pgw.jp. (
                                2020010202 ; serial
                                3600       ; refresh (1 hour)
                                900        ; retry (15 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      dns.sunao-mita.pgw.jp.
                        NS      dns2.sunao-mita.pgw.jp.
                        NS      gate.sunao-mita.pgw.jp.
                        A       192.168.11.2
                        MX      10 mail.sunao-mita.pgw.jp.
                        AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
$ORIGIN sunao-mita.pgw.jp.
collection              CNAME   virt
DebianPogo              A       192.168.11.22
                        AAAA    240d:1a:34d:7f00:225:31ff:fe00:9df0
dns                     A       192.168.11.2
                        AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
dns2                    A       192.168.11.20
                        AAAA    240d:1a:34d:7f00:ba27:ebff:feac:28a8
gate                    A       192.168.11.1
mail                    A       192.168.11.2
                        AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
note                    A       192.168.11.51
                        AAAA    240d:1a:34d:7f00:3906:1714:acef:3e46
PogoV6                  AAAA    240d:1a:34d:7f00:225:31ff:fe00:9df0
Radio                   A       192.168.11.20
RadioV6                 AAAA    240d:1a:34d:7f00:ba27:ebff:feac:28a8
rpi1-com2               A       192.168.11.21
                        AAAA    240d:1a:34d:7f00:ba27:ebff:fe0c:5ef3
rpi1-disk               A       192.168.11.23
                        AAAA    240d:1a:34d:7f00:11cf:af0d:3b62:8501
share                   CNAME   rpi1-disk
ubuntu-dtp              A       192.168.11.100
ubuntu-sv               A       192.168.11.199
virt                    A       192.168.11.105
web-server              A       192.168.11.2
                        AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
www                     A       192.168.11.2
                        AAAA    240d:1a:34d:7f00:a284:cc24:64bd:daae
マスターの更新を直ちにスレーブに反映させるには

修正を直ちに反映させるためには、何かのアクションが必要のようです。ネットで調べてみると reload のキーワードが見付かりました。他にも強制的に配布するコマンドもあるようです。

# service bind9 reload

実行してみるとスレーブ側のデータも最新のシリアルに更新されたようです。 定義の中に、$TTL 86400 ; 1day の記述がありますが、更新されても1日は前の情報を保持する指定なのでしょうか。

やっと念願の公開サーバー交換

宿題事項だったサーバーの交換

2020年元旦になって、数年前から懸念していた公開サーバーを入れ換えることができました。交換したサーバーは、現在の状況で最新版のラズパイで、Raspberry pi 4 B+ / 4GBメモリ で一応最強モデルです。

長く放置できそうな OS

利用する OS は、色々悩みましたが使い慣れているラズパイではデフォルトとなる Raspbian の最新版に落ち着きました。このハードなら色々な OS の選択肢もあるようですが、今までの公開サーバー(PogoPlug E02) のように数年で交換を悩まなそうな見通しを考慮し、日常的で簡単な保守だけで長く安定的に公開させられればとの考えもあっての選択です。

多少のオーバースペックは安心材料

処理速度やメモリ量から考えるとハード的には、完全にオーバースペックのように思います。しかし、ラズパイって昔発売の低スペックのモデルも最新の処理能力の高いモデルも入手する金額に大きな差がないようなので、処理が遅すぎて後で悔やむよりも少し奮発しておけば気が楽になります。

悲願だった交換が完了

換える前のサーバーが非力で、OS の Debian も少し古くなったバージョンで、組込みLinuxを代表するようなシステムだったので、日常的な保守では簡単にバージョンアップができないシステムでした。そのため、このブログ WordPress が稼働する PHP もバージョン5 までしか対応できなくて、セキュリティレベルが低いと警告されていました。

いずれにしても、見た目には同じような動作のままで入替えができたようなので安心しています。使ってみた感じでは、反応がかなり早くなっているので、このブログでも写真の公開でもストレス無く反応しているように感じました。