公開サーバー交換完了

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

大晦日から自信のないまま公開サーバーを置き換えようと模索して、物理的にも旧 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 までしか対応できなくて、セキュリティレベルが低いと警告されていました。

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

気持ちだけ焦ってしまう

公開サーバーの更新

遅いし、PHPがバージョンアップ不能

ウェブ用のサーバーを更新しようと思い立ったのは、いつだったのだろうと考えてしまうくらい長い月日が流れてしまいました。

問題は色々あって進まない

自分の能力不足だったり、最適と思える価格と能力を持つ機材が思い当たらなかったり、時間が無かったりと、タラタラと言い訳が出てしまいそうで情けないです。

ラズパイの最新版登場

一応ラズパイも、メモリー搭載が大きくなって処理能力が格段に改善された最新モデルも発売になったので、これを利用して置き換えようと思い立ちました。

簡単な試行では機敏な反応、期待できそう

まずはサーバーとしての基本を設定しなければなりません。素の状態で動作させ始めると確かに速そうな感触です。置き換えられれば反応の悪さが改善しそうな予感です。

Apache稼働でレスポンス良さそう

今動いているこのブログの機能の移行が最大の問題点なのですが、Apacheを稼働させ、写真の公開データをコピーして稼働出来る事を確認しました。単純な作りなので移行も簡単です。

さて、大問題のこのブログですが、WordPressで構成され、PHP上のアプリとして機能して、Mysqlと呼ばれるデータベースを使用しています。

Mysqlが無くなってしまいました

最新のラズパイのOSからはMysqlが削除されて、代替としてMariadbに変わったようです。Mysqlが、Oracleに吸収されたような話を聞いた記憶がありますが、中立性のオープンソースデータベースでしょうか。

操作上の違いがあるのか、ないのかも不明で、ブログの素人の移行作業には更にハードルが上がったとしか思えません。参ったものです。

まずはメールやシステムログのレポート

その前に色々な機能を追加して、サーバーとして稼働させられる様な状況を作る必要があります。

稼働したシステムログを監視して、メールで毎日通知する機能だとか、メールを発信できる機能が必須です。

他のラズパイサーバーが、Postfixでニフティにメールをリレーしているので、それをコピーして稼働させることにしましたが、バージョンも上がっているようで、予想外の四苦八苦です。

システムログのサマリーがメールで届くのか?

明日の朝以降に、Logwatchのメールが届けば、次のステップとしてブログの移行について試行錯誤のテストに移行しようかと考えてます。

スマホへの対応を模索

プライベート写真の公開を始めてから、すでに長い年月が経過したように思ってます。

元々アルバムに撮り溜めた写真が簡単には見られないのもあって、簡単に見返しができるのを考えた末に、辿り着いたのが今の写真公開です。

昔はパソコンが主体で、知識も能力も無い中で、試行錯誤しながら少しずつ作って思いつくままに機能拡張したのが今の状態です。

昔作り始めた頃には自分にパソコンしか無く、ガラケーの電話はあったもののブラウザも非力で改良する気力も起こらなかったまま推移しました。

その後世の中が大きく推移し、スマホが普及して私でも利用している状況になり、自分自身がスマホで写真を見ようと思う状況になってしまいました。

当初は検証もできる環境がなくて、地図と併用しての写真表示は出来ないように制限していました。でも、自分で表示してみて写真と地図が連動して見られないのはやはり問題を感じてしまいます。

それと、スマホの画面は縦長が基本ですが、簡単に横長になったり全体が小さめに広がって表示され、個々の表示物が小さ過ぎて見えづらいのを感じます。特に地図上の写真撮影場所を示すピンが小さくて見えない事が気になります。

元々のシステム構築が、スマートな保守を考えて制作したものではなく、自分の使い勝手から思い付で追加したものなので、色々な場所に分散していて作った自分でも記憶が不確かなのが困った状況です。

時間を見付けながら少しずつ手を掛けようと考えています。長い目で見てやってください。少しずつは改善して行くだろうと考えてます。

連動地図の機能を拡張

山歩きでは地理院の地形図

私が古くから公開していたプライベート写真のページですが、撮影場所や移動経路をマークして表示できるグーグルマップを組込んでいます。しかし山歩きではちょっと役不足のようですね、やはり国土地理院の紙地図で提供されていたあの地形図の 1/25,000 が何と言っても最適な気がします。

一長一短で、地形図も万能ではない

ただ、国土地理院の地形図が万能かと言うと難しく、市街地や郊外、山の地形と色々な場面で一長一短があって、一意に決めるのは難しいのが現状です。

技術的な知識不足も能力不足もあって、その辺りをずっと悩んでいました。そして何とかオープンストリートマップと国土地理院の地図を表示する事ができ、次のステップで念願だった国土地理院の地形図をオーバーレイで重ねて表示できる機能を知り、今回の改良に至りました。

色々な地図に地理院の地形図を重ねると最強

改良してみて、色々な地図とのオーバーレイで感じることは、望んでいた地図はこれだと思いました。

グーグルの標準 [地図] や [地図+写真]、 グーグルの地形図 [☑地形]、 オープンストリートマップ [OSM地図]、 国土地理院の地形図 [地理院]、 国土地理院の航空写真 [地理院 航] と選択はありますが、これらと 地理院の地形図 を重ねてみるとなかなか興味深い結果となりました。

昔の写真を掘り起こすように開いてみると、しみじみと地図に見入ってしまいます。

グーグル地図は、右上に配置されている破線で描いたような のボタンで、全画面の地図に移動できますので、広い画面で地図を楽しむことができます。逆に戻ることもできるのでとても便利です。

最近の地図について

ネット上で広く利用されている地図には、グーグルマップやヤフー地図とか色々なものがあります。私も利用方法がネット上に公開されたこともあり、それより先に公開していたプライベート写真にグーグルマップを連動させる処理を追加してきました。

2018年からグーグルマップが有料に

グーグルマップは色々な機能のAPIがあって、移動した軌跡や写真の撮影場所が簡単に表現できる便利さから利用を始めましたが、昨年から利用が有料に移行したこともあり、状況の推移を見守っていました。

無料の地図システムもあるようです

地図を無料でネット公開のページに組込み利用できるリーフレットと呼ばれる地図表示システムも開発されていて利用されているようです。そこに、オープンストリートマップ国土地理院の地図のように、利用条件に依っては無料で利用できる地図を組み合わせることで、有料のグーグルマップの利用を回避することもできます。

私も無料化を検討したのですが、グーグルマップはさすがに有料なこともあって、住所を取得や指定をしたり、経度と緯度の操作を行うAPIが充実してることもあって、現状は継続利用しています。

私も無料の地図を利用してみる

今更とは思いますが、利用方法が分かりやすく説明されていることもあって、私がグーグルマップに写真を連動している機能の中にもオープンストリートマップと国土地理院の地図が選択できるように改良してみました。

やはり山歩きや散策では国土地理院の地図

グーグルマップは良くできていると思いますが、山を歩いたり例えば霧ヶ峰高原を散策したりした時に、後から歩いた軌跡を辿って見ても、若い頃にお世話になったあの国土地理院の 1/25,000 の紙地図のような細かい表現はなく、のっぺりしているのが物足りなく感じていました。

ただグーグルマップは凄いです。最近になって感じたことですが、自宅周辺の地図のポイントから住所を拾ってみたのですが、『何番地の何』か、まで正確に表示してました。 ! グーグル恐るべし !

久し振りなブログ更新

前回の書込みが、6月22日だから、既に最後の更新から2ヶ月半経ってました。
久し振りにログインするとPHPが古いと指摘されました。まずはこの辺の処置から進めないと行けないようですね。

懇切丁寧にPHPバージョン7に更新するメリットについて説明されました。このブログシステムの WordPress って PHP上で稼働するアプリケーションなんですよね、やはり古いとセキュリティや効率的にも影響があって良くないです。分かっているので更新しようと思い立ちました。

と、…思ったのですが、現バージョンが 5.6 です。今稼働中の Debian には古すぎて、PHPバージョン7 は無く、OSの更新から必要になります。長く放置されていた問題の再燃ですね、実際には放置していたわけではなくて、単に技術力が足りていなくて解決されていないだけなのですが…

いま運用中のこのサーバーは、ちょっと非力な PogoPlug E02で動作していますが、基本的には組込みLinuxのファームウェアを Debian Linux のOSとして組込んでいるだけなので、一般的なパソコンやサーバーシステムの利用と異なっているのは、 OSのバージョンアップが標準的なライフサイクルに組込まれていません。

ここで公開している写真類については古く、何世代にも渡って脱皮と言うか、ヤドカリくんの生活に慣れていますが、このブログに関してはWordpressの完成品を借りてきてただ導入しただけなので、仕様も細かいメンテ方法も手探りで慣れていないのがネックになっています。

ここの写真公開システムも、先代のハード不具合に端を発して急遽安定版の最新 Debian より少し古いバージョンをわざわざ選択して、慌ただしく立上げ稼働しています。まだ OSのセキュリティ更新は継続して行われているようですが、そろそろ最新に更新する必要性も感じていました。

最近ではどこにでも使われているラズベリーパイに、載せ替えようかと2年以上前から時間のある時に取り組んでいたのですが、当時はハードとソフトでラズベリーパイが安定していなかったのと、能力的にも見劣りがあって消極的でした。

最近のトレンドはクラウドですが、他人のデーターセンタを有料で一部借りて利用するクラウドにも抵抗があったし、まさかの事件アマゾンAWSのセキュリティ問題とかもあって、最終的には人手に依る管理に起因していると考え、非力でも自分の目や身体で触れる存在がやはり一番安心していられるので、未だ家庭内サーバーシステムです。

ラズベリーパイも高速になって、大勢に揉まれているので色々な意味で洗礼されてきています。未だ初期起動は microSD に依るものと思いますが、起動してしまえばハードディスク運用は可能で、特に問題ないと思われるので今後の取組課題です。

更にラズベリーパイの長所は、当初問題もありましたが、最近では揉まれながらに安定性が増したようで、組込みLinuxと言うより一般的なサーバーと同様な管理体制で専用の Raspbian がメンテナンスされているようです。

ラズベリーパイもここの所の運用状況では、稼働させているサーバーを停止してメンテナンス作業を行う必要がないような状況で、日常のメンテナンス操作上で最新OS へのバージョンアップもできています。長く継続して利用するには必須のアイテムかもしれません。

今は道の駅 摩周温泉

利尻岳の登頂を目標に訪れた今回の北海道ですが、天気は不本意ながら無事に登頂を果たしました。

それ以外にも、この時期に登り直してみたい山の候補がいくつかありますが、天気の悪い中で山を登らない事を心情にしている私としては、チャンスが少ないです。

一応道東に移動して、馴染みの道の駅摩周温泉の滞在者御用達と思われる離れた駐車場に車を入れています。

昨日は途中で、養老牛温泉の湯宿だいいちで温泉を味わってから、この道の駅に来ました。当然ですが車中泊で、薄めたニッカの安価なウイスキーで夕食をツマミにして就寝しました。

足の全体の筋肉は張って痛いのですが、左膝外の筋の痛さはなく、天候次第で摩周岳の散策を考えていたのですが、朝早く起きて曇天でもやった周囲を見て思い留まりました。

今は雨になっていて、車の窓ガラスに水滴が流れ落ちるのを見ています。大した雨では無く、汚れた車にまとわりついている虫を落とすには好都合かも知れません。

弟子屈町では無料のWiFiを公開していて、メールアドレスの登録で利用できるようです。今はそれを利用させて頂いてます。

理由が不明ですが、WiFiは時々切れたりしてます。遠くて電波が弱いからなのでしょうか?

天気が悪い日は、車の中で足を伸ばして寛ぎながら、昔公開した内容を見直すのも良いのかなと思っています。

公開内容が不適切とのご指摘も頂き、具体的なご指摘があれば対応も簡単なのですが、気が付いた箇所を逐次直そうと思います。

今日は一日こんな感じでまったりな感じでしょうか、さすがに傘を開いて観光をしたいとも思いません。

今は雨脚が強くなっています。トイレに行きたいと思ってますが、少し離れているので思い留まったままになってます。

今は稚内で車中泊

天気予報がコロコロ変わり、少なくとも数日は周辺の天気が悪いらしい。

浜益の黄金山も登山口まで行ったものの小雨なので諦めました。そして、暑寒別岳の曲がり口で思案したのですが、利尻岳に注力しようと思い稚内に急ぎました。

その時に発表されていた予報は、数日間は晴れ間が見えるかも知れないと期待させるものでした。

朝起きて小雨が降り、雲の切れ間に青空の少し見える状況ですが、今日がピークで悪化に向かい雨の予想もされているようです。

雨具も用意してることだし、ここまで来たのだから渡って歩いてみようかと、意を決したところです。

相変わらず強い風が吹く事もあり、風の音が大きいです。

どうなることか話の種に、利尻島に渡ります。