グーグルマップのセキュリティアップ?

ぃやぁ〜参りました。
自分の写真を以前から公開していますが、その中で撮影地点の確認と移動の経路を軌跡として描画表示するために、グーグルマップを利用させて頂いてます。
公開前の編集時点では、手元のノートパソコンを利用して、以前はそのURI サーバー名を http://localhost/ として記述して、自分自身のノートパソコン内で起動しているウェブサーバーを指定していました。
その中でグーグルマップに表示させる情報も編集していて、データの作成と確認ができてから、問題ない状態になった時点で公開サーバーに転送していました。
最近になってだろうと思うのですが、localhost ではサーバー名が不適だとして、エラーになっているようで、マップ表示が出来なくなっていて、編集や確認が出来なくて困りました。
仕方なく公開しているサーバー名の URI を含ませた名前で、適当にデバッグ用のサーバー名を考えて、apache2 の定義を少し直して、最近では触ることの無かった /etc/hosts に、自分自身のループバック 127.0.0.1 として追加して、急遽対応しました。
取敢えず対処できたので、問題はなかったのですが、一時は状況がわからずに焦りました。
セキュリティ向上の一環なのでしょうか?
そして 1日2日経過した頃に、再び手直しでもしようかと思い操作すると、今度は擬似サーバー名でもグーグルマップが利用できなくなっているようでした。これは困ったことです。
仕方なく、公開サーバー名で自分自身のウェブサーバーにアクセスするように /etc/hosts を編集して確認すると、全く問題なくグーグルマップが表示されました。セキュリティでは色々な問題があるので強化は仕方がないことですが、どのように編集して公開するか悩みます。
それと、公開サーバーは他にも問題を抱えていて、スクリプトを自分で組んで公開していますが、自分で組んだとしても作ってから年月が経ち記憶が薄れ、肉体は老朽化が進み頭の回転は遅くなり、最近は HTML5 CSS3 とかも一般化してきたようで、利用している jQueryライブラリも時代に合わせ進化しているようで、見直してどうにか手を加えようと考えているのですが、思うように進められていないのが現状です。


以下は、後から追加 2017-09-16
今現在は、 http://localhost/ でのアクセスでも、グーグルマップが起動されて正常に利用できているようです。数日前のゴタゴタは何だったのでしょうか。
グーグルでの単なるミスだったのでしょうか、ミスはどこでも起きますから、私なんて時々ミスしてリカバリーに追われることがあります。グーグルマップの利用では、過去にも利用できなくて、それに吊られるように他の機能も利用できなくなって、仕方なくグーグルマップ機能を切り離すオプションを追加したこともありました。
その時には、数日待ってから確認すると、特に問題もなく利用できていましたので、今回もあり得ることだとは思っていたのですが、セキュリティのポリシーが変更になったのかと考えたのと、早めに公開写真の編集を終わらせたかったので仕方なく対応していました。

sudo にハマってしまいました

最近の Linux で定番となったディストリビューションの Ubuntu ですが、一般ユーザーで作業している時に root 権限で作業する場面は時々発生しますよね。その時に 1コマンドだけを実行するには sudo コマンドを使用するわけです。使う場面としては、例えば一時的にパーティションをマウントしたり、マウントを解除したり、新しいディレクトリを生成したりと、一般的な作業で日常的に発生する頻度の高い作業です。
sudo コマンドを実行するときに、一般的にはログインしている一般ユーザーのパスワードで認証するのですが、パスワードを省略して作業したい場合もあります。問題としてはデスクトップを放置している場合に他人が操作するセキュリティですが、それよりも深刻なのはシェルの連続動作中に root 権限を必要とするコマンドを利用しなければならないケースです。この場合はパスワードの入力を求められて、対応できなくて異常終了してしまう等の結果になることが多く救いようがなくなります。
sudo コマンドの動作の振る舞いを定義するのは、/etc/sudoers ファイルですが、これを直接編集して問題を起こすと取り返しのつかない問題になるらしく、冒頭のコメントに ‘# This file MUST be edited with the ‘visudo’ command as root.’ と書かれています。
実は昔から私は一般ユーザー(自分のユーザー権限)の作業中に決まったルーチンで、ネットワークで接続しているサーバーに、データを転送したりバックアップするようなことを行っていました。この場合に mount コマンドで一時的に接続したり、umount コマンドで開放したりを動的に実行していました。場合によっては rsync コマンドでデータ転送も行っていましたが、ここで出てくるのが sudo コマンドです。ところが Ubuntu 14.04LTS から Ubuntu 16.04LTS にバージョンアップしてからパスワードを要求されるようになりました。
原因がわからずにしばらく悩む結果となりました。 sudo のセキュリティがアップされて、認証の仕様が変わったのだと思い込んでいました。今までは、NOPASSWD: のキーワードを付けて、パスワード無しで実行できていました。今でも同様の構文が記述されているにもかかわらず何故かパスワードを求められます。/etc/sudoers ファイルに記述された構文や構成要素の意味がわからず手探りでマニュアルを探していました。
ついに日本語のマニュアルを見付けました。もっともそのマニュアルを見ても表現が今ひとつ理解しづらいのですが、でも構文の使用例が多めに載せてあって何となく言おうとすることが理解できるような気になってしまいます。その内容の中に 『複数のエントリがマ ッチする場合は、順番に適用される。矛盾する値がある場合は、マッチする行の最後の値が効果を持つ。』 と書かれていました。これって同じ構文でも順序が大きく影響すると書いてますよね。 …そうでした。構成要素の最後に NOPASSWD: の定義がある構文を移動したらパスワードを求められなくなりました。
知らない、理解していない…って何をするかわからないですよね。改めて自分の知識の無さに情けなさを感じるというか、ある意味怖いですよね。何となく /etc/sudoers ファイルの構文の意味やファイルの構成順に関して少し理解できるようになりました。
最近になって解決したばっかりの問題で、無駄な時間を潰してしまった失敗談です。

久しぶりにラズパイとLCDで遊んでます

今回はラズパイについてです。
ラズパイは当初の想像を超えた大きなブレイクが起こり、今ではネットに多くの情報が溢れ、本屋さんにも書籍が溢れるようになって、関連する周辺機器やオプションも日増しに開発されるようになったのが Raspberry Pi です。 そして、私もご多分に漏れず最初に国内販売された黎明期の入手難な時期から触れているのですが、未だ有用な実用製品として活用もできないまま役立っていません。
それには私の力量不足に多くの問題があるのですが、ただ発売初期の頃のスペックではクロックも低く、非力なシングルプロセッサでメモリも少なく、あまりにも非力過ぎて何をさせるにも役不足の印象でした。
それが時間に追われたままの生活でしばらく離れていると、なんとマルチプロセッサとなり処理能力が改善された Raspberry Pi 2 が公開されて、さらにはWiFiやBluetoothを搭載して性能を上げた Raspberry Pi 3 なる製品も出荷されました。
小さのものから大きなものまでディスプレイ等の周辺機器も次々に開発されています。2年近く前に日経Linuxの記事で紹介されていたaitendoの安価で小さなLCD(液晶ディスプレイ) 2.2インチ液晶モジュール(240×320/SPI)[M-TM022-SPI] を購入して、セットアップしてみて表示ができることを確認しました。 ただ、システムのメインのディスプレイ装置としての利用を考えた場合には、頻繁に提供されているセキュリティアップデート等の実施でカーネルのバージョンやレビジョンのアップが発生した時点で、そのままではその後の表示ができなくなくなります。
今回は、Raspberry Pi 3 の購入と併せて、保護ケースと3.5インチディスプレイとタッチパネル等がセットになっている製品を amazonで購入しました。 ちなみにそのキットに書かれた情報を記述しておきます。『Kuman 3.5インチ ディスプレイ タッチパネル Raspberry Pi 3B 2B/B+/A+ /A/B/Zero に適用 320*480 解析度 保護ケース ヒート ¥ 3,200』20160819_135344-320x180
組み立てた製品イメージは、透明な箱の蓋の部分にLCDモニタが収まっているような形状です。ただし、箱とLCDは一方向に寄ったコネクタで結合しているだけで、コネクタの反対側は空中に浮いたような不安定な構造です。何らかの方法でコネクタの反対を固定する必要があります。
製品群の中には添付のCDが入っていて、その中にたぶんマニアルや専用OSのLCDドライバが組み込まれた Raspbian が micro SDのイメージで入っています。これを使うとシステムが簡単に立ち上がり、そのままデスクトップイメージを表示できます。ただし、実用的に使うためにはセキュリティアップデートや新しいソフトの追加が必要ですが、そこで表示をしなくなります。それに日本語表示の追加等も必要ですよね。でも新しくなったカーネルに何をすれば表示できるようになるのかがわかりませんし、CD内を端からチェックするような時間の余裕もありません。
そこでネットを検索してみました。すると運良く同じLCDを扱った記事が見つかりました。さらに記事の中には最新のドライバのリンクもあり、利用する手順も書かれています。http://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A)
LCD-show-160811.tar.gz をダウンロードして解凍し古いものと入れ替えました。内容について見比べると大きく更新されているようでした。ここに書かれた手順に従って実行すると再び表示できるようになりました。

./LCD35-show

hdmi コネクタに接続したテレビをモニタにするように戻すのも簡単なようです。

./LCD-hdmi

説明によるとモニタを90度づつ回転させることもできるようです。

syslogに残るCRON 認証失敗

何とかセットアップしながらですが、今月からインターネットに公開を始めたPogoPlugで、syslog にCRONの認証失敗が多数記録されています。 この状態だと実行も行われていないようです。

Aug 4 08:58:01 DebianPogo CRON[4789]: 認証失敗
Aug 4 09:00:01 DebianPogo CRON[6354]: 認証失敗
Aug 4 09:03:01 DebianPogo CRON[8696]: 認証失敗
Aug 4 09:08:01 DebianPogo CRON[12609]: 認証失敗

この原因がわからないので、色々と調べました。 /etc/crontab には、実行するユーザーを指定しているので、そのメール環境に原因があるのかと思い、postfixの配送先を見直しましたが、特別な関係は無いようです。

root@DebianPogo:~# nano /etc/aliases
root@DebianPogo:~# newaliases

そこで、実行ユーザーを root に変更して、標準出力やエラー出力の情報を /dev/null に捨てるのを止めると、正常に動作していると思われる結果をメールで受け取ることが出来ました。

There doesn&#039;t seem to be any new mail.<br />Retrieval completed.<br />

syslog を確認するとメールの配送処理が行われているのが記録されていました。
そこで、実行させるユーザーでのログインを試して見ました。すると、syslog に記録されているのと同様に認証失敗の文字列が吐き出されて、ユーザーに対応するシェルが起動しませんでした。

root@DebianPogo:~# su - www-data
su: 認証失敗
(無視)
This account is currently not available.
root@DebianPogo:~# su - nobody
su: 認証失敗
(無視)
ディレクトリがありません。HOME=/ としてログインします
This account is currently not available.
root@DebianPogo:~# su - pogo
pogo:~$ ログアウト

この場合は、ユーザー名の root と pogo だけが認証失敗にならずに実行できるようです。 /etc/crontab で実行させるユーザーを pogo に変更して経過を見ると、この件に関しての認証失敗の記録は無くなりました。
 
 

ブログの公開準備

ローカル設置サーバーにブログを組込み、プライベート写真と一緒に公開しようと思い立ち、セットアップと動作検証を進めていましたが、公開にあたりURLを変更したところ動作不能に陥りました。
安易に開発時のURLを変更して操作するとリンクが切れてしまい、動かなくなってしまうようです。
検索の結果参考になるページを見つけて対応出来ました。日本語で書かれた対処方法は実に参考になります。本当にありがとうございます。
 

新しいWeb公開サーバーにwebalizerの導入

今現在インターネットに公開中のWebサーバー(Buffalo LinkStation)が少し古いOSで稼働しています。
最近は、Windowsを含め、Linuxやその他のシステムでもIPv6がセットアップされていますし、むしろそちらがデフォルトの設定として優先的に機能しているのですが、今の公開サーバーではDebianの古いOSなので、それに対応できていません。
そこで、最新のDebian OSを組込んだ新たなサーバーを立ち上げようとしています。
ただ古いOSとはいえ提供している今の機能としては、何年もの長期間の運用で安定して稼働しています。また、物理的な構造も内蔵ディスクを2台収容しシステム単体でRAID構成が組めてデータの保証もある程度は担保されています。という事で、同様の構成で最新のDebianに載せ替えて運用できれば理想的だと思ってます。
最終的な理想形は目標としてありますが、すでに公開している今のサーバーとしての運用形態は継続させる必要があり、簡単にはシステム更新ができません。そのため一時的にせよ別のサーバーで代替運用しなければなりません。
そのため今回は、代替運用としてPogoplug E02にDebianの最新Jesseを組込み、代替Web公開サーバーとして立ち上げます。apache2.4でセットアップして、現行公開サーバーでは運用できていない機能のブログを追加機能として組み込むこととしました。今稼働中のこのブログがWordPressにより実現されています。
公開サーバーの利用アクセスの概要を確認できるようにWebalizerをセットアップしますが、現サーバーではv2.01で完璧に近い日本語化が行われているのですが、何故か最新のv2.23-08では文字化けしているようです。
日本語化用のファイルは、EUC-JPらしく、ネット情報を参考にUTF-8に変換してソースからメークしましたが、フォントの指定でエラーが出てしまい画像上の文字が化けてしまいます。諦めてUTF-8に変換しただけの中途半端な日本語化で妥協することにしました。
 

BLOGをセットアップしてみようと思い立ち

佐藤さんも旅立ちに向けブログを立ち上げたので、勉強を兼ねて何とか自分でも立ち上げようかと考えました。
実はすでに数年前には@niftyのブログを少しだけ触っていたのですが、何か自分には合わないような気がしていて、ちょっとすっきり出来ずに遠ざかってしまい、その後更新が続かないまま月日が流れてしまいました。
そこで自分で立ち上げるために使うブログソフトを何にするのか…と言うより何があるのかの知識もなく、何を利用しようかと調べていると WordPressと呼ばれるソフトがあるらしい事を知りました。
それが今やっと動き始めたこのブログソフトです。
ここまでの状態に来るまででも数日要して、試行錯誤ですんなり行ってるわけではなく、今文字を打ち込んで検証ができそうな環境になったのもキセキのように感じています。
その苦労をメモとして記述しておきます。


まず組込むサーバーは、最新のDebianを投入したピンクのPogoPlug E02を利用して立ち上げて、公開用の私の写真サイトをフルコピーして、別のディレクトリにWordPressを投入して、URLで /blog/ 以下に設定することにしました。
最終的には外のインターネットからアクセスできるようにするつもりですが、ある程度操作してみて問題がない事の検証が必要です。
WordPressは、日本語にも対応している phpソフトで、色々な部分が部品のように .phpで作成されていて、スタイルシート .css や JavaScript .js 等が混在した状態です。
実行権限を与える必要があり、apache2の設定で、WordPressの入ったディレクトリを /cgi-bin/ と同様にと考えて、 ScriptAliasディレクティブで定義したらエラーが出てしまい、原因がわからず苦労しました。
apache2は、ScriptAlias定義された場所にあるファイルは、スクリプト以外でも全て実行させるように動作するらしく、.css .js実行してエラーになるようです。

[cgid:error] [pid 9402] (13)Permission denied: AH01241: exec of ‘/var/wordpress/html/wordpress/wp-content/themes/twentyfifteen/js/functions.js’ failed

最終的には、以下のように定義しています。
Alias /blog /var/wordpress/html/wordpress
<Directory /var/wordpress/html/wordpress>
DirectoryIndex index.html index.html.var index.php index.cgi
AddHandler cgi-script .cgi .pl .php
Options ExecCGI FollowSymLinks MultiViews
Require all granted
</Directory>