QGIS2.18と3.0.1のインストールした環境設定一覧

QGIS3.0.1と2.18を共存させた結果のインストーラのパッケージ選択画面を公開しておきます。
私の個人環境なので、他の人が必ずしも同じになるとは限りません。参考情報です。

トライされる方は、前の記事は以下です。

QGIS 3.xをインストールしてみた。QGIS 2.18と共存。

通常不要なものも含まれていると思いますので、ご自身でご判断下さい。

 

QGIS 3.xをインストールしてみた。QGIS 2.18と共存。

背景

QGIS 3.0がリリースされて、OSGeo4Wがインストールされていない綺麗な環境にインストールするのは、何も気にせずにインストール出来たのですが、QGIS 2.18がインストールされている環境にインストールしようとしたら、ちょっとだけ引っかかったので、記録に残します。

既に、QGIS 2.18.xがインストールされている環境を前提に進めます。
インストールを行った環境はWindows 10です。

追記:どうも、QGIS 2.18.xからだと上手く3.0.1をインストール出来たのですが、2.12からだとNGでした。そこで、私の環境設定内容を下記に貼り付けておきます。

QGIS2.18と3.0.1のインストールした環境設定一覧

はじめに

私は、QGIS 2.18.xを使用しており、いきなりQGIS 3.xへ更新するには抵抗がありました。使えなくなるプラグインなどがあり、仕事で使うにはちょっと困ります。
そこで、QGIS 2.18.xを残しつつ、QGIS 3.xをインストールしたいと思いました。

と言うことで、以下ではQGIS 2.18.xを残しながら、QGIS 3.xをインストールしてどちらも使用できる環境を構築します。
ただし、OSGeo4Wを使用していることを前提とします。

準備

準備と言いましても、特に何をダウンロードしてとか必要ありません。
新規でインストールされる方は、下記URLより環境に応じたインストーラをダウンロードしてください。

https://qgis.org/ja/site/forusers/download.html

 

OSGeo4WのSetupを起動します。

ここで、「アドバンスインストール」を選択します。

「インターネットからのインストール」で次へ

次も特に気にせず次へ

更に、次へ。

まだまだ次へ。

 

こいつも次へ・・・・楽々インストール?

やっと来ました!ここから本番です\(^o^)/

「Desktop」の前にある「+」ボタンをクリックして展開します。

ここでは既に3.xがインストールされた状態の画面を示していますが、上記の状態になる様に、インストール対象を選択します。

具体的には、以下の内容になります。

qgis:QGIS Desktop
qgis-dev
qgis-dev-pdb   <==必要ないかも?
qgis-full
qgis-full-dev
qgis-ltr            <==これは2.18を残すためです。それ以前のバージョンを使っている方は、更新されてしまいます。
qgis-ltr-full
qgis-rel-dev
qgis-rel-dev-pdb

これ以外は気にしないで大丈夫です。
上記の中にも不要なものが含まれているかも知れませんが、私の環境ではこんな感じでした。
間違って、3.0.0-4をインストールすると、上手く動作しませんでした。

これで、設定が終わりましたので、次へ進みます。

後は勝手にインストールが進みます。

!!!!!!!!!!!
ここで問題が!!!!!!!
!!!!!!!!!!!

OSGeo4WのSetupでインストールすると、qgis(Desktop)が最初は3.0.0-4しかインストール出来ません。
それが原因でQGIS 3.0を起動してもエラーで落ちる現象が確認できました。

解決方法は、再度、上記のインストール方法を繰り返すと、今度は3.0.1-1がインストール出来る様になります。
これでインストールし直すと、正常に起動出来る様になるみたいです。

Windowsメニューから両方のバージョンのQGISが起動することを確認してみてください。
一つの環境だけしか試していないので、大丈夫かな?

Rで日本語表示 Linux(CentOS)

Rで日本語表示が出来なくって困った。
RはCentOS上で動作しています。
CentOS 6でもCentOS 7でもどちらでも対応出来たので、記録します。

対策は、フォントを追加してやればOK!
凄く簡単だった。

で、本当にそれだけなんだろうか?たまたまそれで上手く行っただけかも知れないけど。。。。(^^ゞ

やったことは以下のコマンドを実行しただけ。

全然、Rに関して書いてないけど、Rで日本語表示出来る様になったんで・・・デフォルトのフォントがこれなんですね。

おしまい(^^♪

MariaDBを外部から接続できるようにするCentOS 7

MariaDBを外部サーバからアクセスできるように設定する。

MariaDBは前回導入しましたが、外部からアクセスできるように設定を行います。

外部とは、同一ネットワーク内のサーバからのみアクセスを許可します。全公開するとセキュリティを考慮する必要が生じますので、同一ネットワーク内としています。

環境

CentOS 7.4
MariaDB 10.1

作業項目

  1. ファイアウォールでMariaDBのサービスを許可する。
  2. MariaDB内に外部からアクセスを許可するユーザを作成する。
  3. MariaDBの設定を確認・調整する。

ファイアウォール設定

ファイアウォールにMariaDBのアクセスを許可します。
以下のコマンドで設定します。

firewalldの再起動は以下のコマンドでもOK!

これでfirewalldにmysqlのサービスが許可されました。
mysqlとしましたが、MariaDBは内部にmysqlを含んでいると考えてください。そして、mysqlが許可されればMariaDBへの許可が済んだことになります。

MariaDB内に外部からアクセスを許可するユーザを作成する。

今回は、内部ネットワークなのでrootユーザと同じレベルで作成します。

前回インストールしたMariaDBであれば、これだけでOKのはずです。

私が少し躓いたのは、間に物理的なファイアウォールやUTMを配したネットワークを経由した際に、そのハードルを越えるために設定を施す必要が生じたのですが、同一ネットワーク内であれば、ルータ代わりにUTMを使っている様な下手なことをしていなければこれでつながるはずです。

MariaDBの設定を確認・調整する。

基本的には必要ありませんが、/etc/my.confや/etc/my.conf.d/で設定しているconfファイルで、bind-addressを指定している場合には、その設定を見直す必要があります。

bind-addressで指定が行われている場合、外部からアクセスするアクセス元のIPアドレスを確認して登録します。

対象ファイルは
/etc/my.conf
それ以外は以下の様に確認しました。

これで何か設定が行われていれば、以下の様に接続元のIPアドレスを追加します。

こんな感じです。

以上で完了です。

最後に確認

最後に確認方法ですが・・・・

外部のマシンから以下のコマンドを実行します。

これでアクセスできない場合には、もう一度設定をみなしましょう。
それでも接続できない場合は、ネットワークに問題があるのかも知れません。ネットワーク管理者に相談してみるのも方法かと思います。

 

CentOS 7 へMariaDB 10.1(最新)をインストール

CentOS 7 + MariaDB 最新版をインストール

2018年3月時点における環境は以下の通り。

CentOS 7.4
MariaDB 5.5

この状況ですと、MariaDBの最新版がインストールされていない状態になっています。
MariaDBには、「Galera Cluster」が提供されておりますが、10.1以降ではデフォルトで組み込まれる様になりました。
つまり、10.0までのバージョンでは個別インストールが必要となります。

また、MariaDBとMySQLのバージョン関係を見てみましょう。


MariaDBバージョン MySQQLバージョン
MariaDB5.5.x MysQl5.5
別途Galera Clusterをインストール。
MariaDB10.0.x Mysql5.6
別途Galera Clusterをインストール。
MariaDB10.1.x Mysql5.7を取り入れ、MariaDB独自機能あり。
Galera Clusterは組み込み済み。

正直、現時点でMySQL 5.5はちょっと古い。5.6もしくは5.7をインストールしたい。
デフォルトのCentOS 7ではMariaDB5.5に対応しており、MariaDB10.xをインストールするには別途独自のインストール設定を行わなければならない。

ジレンマはあるが、後々のことを考えると選択肢は新しいバージョンを適用したい。

MariaDB 10.1.xをインストールする!

旧パッケージの削除

まず、既にインストールされているMariaDB関連のパッケージを確認→削除する。

確認すると、mariadb-libsがデフォルトでインストールされているので、これを削除する。

リポジトリの準備

MariaDBの本家からインストールを行えるようにリポジトリを追加する。

以下のサイトでも紹介されています。

https://mariadb.com/kb/ja/yum/

まずリポジトリの定義を行います。
/etc/yum.repos.d/にMariaDB.repoを作成します。
内容は以下の通りです。

MariaDBをインストール

これでMariaDBをyumでインストールできる。

確認してみます。

これでインストール自体は完了です。

MariaDBの初期設定

MariaDBの初期設定を行います。
インストール直後の設定はほとんど何もされていない状態にあるようです。
そこで、インストール設定を行います。
まず、デフォルトの設定ファイルをバックアップしておきます。
#本家では推奨されているわけではないのですが、気持ち的にオリジナルを無くしてしまうのは気持ち悪いw

バックアップ出来たので、初期設定を行います。

文字コードの設定が行われていない状態なので、設定をします。
以下の項目を追記します。

取りあえず、大まかな設定は済みました。
この後は、MariaDBを起動しMariaDBのセキュア設定を行う。

MariaDBの起動

MariaDBを起動する。

 

セキュリティ設定

セキュリティ設定を行います。

※パスワードは適当に入力してください。

これでセキュリティ設定は完了です。

こんな感じで使えるようになります。

 

 

 

Log4cppでログファイルをローテーションする

プログラム開発でログの出力を行いたいと思います。
今回はC++のプログラムで実装してみます。

まず、なんで今更Log4cppについて記述しようと思ったか説明します。
log4cppのサンプルや記述はネット検索ですぐに見つかります。
でも、上位で検索されたサンプルには間違いがそのまま残されていて、実際に動かしてみるとローテーションは行われませんでした。
また、注意深く見てみると、設定のパラメタすら間違ったままになっているのです。
私は、そのWebサイトの間違いに過去引っかかり、無駄な時間を費やしました。なので、そんな無駄な時間を今後費やすことのないように、ここに記述します。
そちらのサイトを批判するつもりはありませんので、当該サイトのURL等については記述しません。
なお、ここの記載内容に間違いがあった場合には、お手数ですがご指摘して頂けますようお願いします。
こちらのサイトを参考にされる方には、コメント欄に指摘されている内容も含め参考にされることを期待します。
なるべく、修正は行っていくつもりですが・・・将来のことなので、ご注意ください。また、Web上の情報は参考情報です。ご利用に際しては、ご自身の責任でご利用ください。

環境

今回実装を試したのは以下の環境です。

OS:CentOS 7.4
gcc バージョン 4.8.5

 

パッケージインストール

 

プログラム

 

設定

ファイルサイズを102400バイトまでとする。
ログは最大8世代まで残す。

ざっとこんな感じ。

コンパイルは以下のコマンドで行う。

 

CentOS 7 NTP設定・・・ちょっと待て!?

こんな感じではじまった

CentOS 7で時刻同期を行おうとNTPの設定を行った。
デフォルトでインストールされているだろうと思い込んで進んだのだが、ntpdが無いではないか!?

そんじゃ・・・ということでyumにお願いしてインストールしてsystemctlをstartとenableやって、ntpqコマンドで動作確認。。。。おっ!動いた!OK(^^♪

と思ったよ!!俺でもこれくらいは出来るぞ!と、思ったよ!

しばらくして、マシンの再起動なんかもして、翌日ntpqで時刻同期はどうなってるかなぁ~なんて、楽しみに見てみたら・・・・

あれ?動いてない?systemctl enable ntpdを忘れてたの?
と再度実行して、再起動してみたものの同じ現象やん!?

やばい!いつも簡単な設定だから適当決め込んでいたのだが、不味い!!((((;゚Д゚))))ガクガクブルブル

ググったら出てきた。CentOS 7からntpdは標準ではなく、代わりにChronydが標準になったのが原因だった。
当然、デフォルトで設定されてたよw

と言うことで本題!

でもって、/etc/chrony.confを開いて以下の部分を適当に変更。

不要なサーバ設定を削除して、必要なサーバを指定(IPは適当なものに置き換えてください)して、再起動したらOKでした。

こんな感じで再起動

ちなみに、

確認はやらなくちゃ!

更に確認方法は・・・

こんな感じで表示されたらOKらしい。(表示されているのはデフォルトの状態で試した時です。)

ほんま焦りますわ(^^♪

ついでにちょっとだけコメント

ちなみに、サーバとして動作させるには、/etc/chrony.confの以下の部分を設定してあげる必要があります。

allowする相手のネットワークを必要に応じて記載することが必要です。

サーバとして動作させる必要が無ければ、この状態でOKです。

ちにみに設定変更を行ったら、サービスの再起動を行うこと!

自動機能もデフォルトで設定されている様ですが、どうしてもやりたい人は、systemctl enableで実施してください。

chronydは嫌だぁ~!って人は、chronydをdisableしてntpdを設定してあげれば良いそうです。

 

プロセスの監視と再起動(monitを使ってみる)

前回はdummyプログラムを用いたサービスの登録方法について説明しました。
今回は、その登録したサービスを監視し異常発生時の再起動を自動的に行いたいと思います。

dummyプログラムは、TCP/IPによる通信を行うサーバ側のプログラムです。
ポート番号10050を使用してクライアントからの接続を待っています。

そのdummyプログラムが異常終了しゴースト化してしまっていたり、プロセス自体が動作していない状態(psコマンドで見つからない時)に、自動的に再起動を行わせます。

準備

プロセスの監視には色々と方法がありますが、今回はmonitを使用します。

monitのインストール

まず最初に、epelリポジトリをインストールします。
デフォルトではインストールされていないので、準備します。

続けて、monitをインストールします。

これだけです。

monitの初期設定

色々と他のサイトでも紹介されている様なので、今回は細かな設定については割愛します。
私がやったことは、以下の通りです。

1)monit.confの設定変更

/etc/monit.confもしくは/etc/monitrcの記述内容を編集します。

当該ファイルの一番下にこんな記述があります。

このままでは、/etc/monit.d/にある全てのファイルがインクルードされることになります。
/etc/monit.d/には各監視対象毎の設定ファイルが置かれることになります。
そこで、以下の様に編集しました。

/etc/moni.d/*.confとすることで、拡張子が.confのファイルだけが対象となります。
この設定を行う場合には、以下の作業も忘れずに行って下さい。

初期状態では、/etc/monit.d/にあるファイルはloggingだけになっています。

loggingファイルをlogging.confにコピーします。ファイル名の変更でも構いません。

これでmonitが動作する環境設定は準備出来ました。
それでは、monitをサービスとして起動します。

OS起動時に自動起動させるためには更に以下のコマンドを実行する。

これで監視が行われる状態になっています。
でも、監視対象が何も指定されいませんので、以下でdummyサービスの監視を行います。

プロセスの監視

前回の設定ではサービスとして登録しましたが、ここでは敢えて単独のプロセスとして監視対象にしました。
サービスとして登録した場合の方法については、別途記載しています。
サービスと登録している状態で、この方法を取ることはお勧めできません。
方法が異なる起動方法によりプロセスが再起動する可能性が発生し、管理上良くないからです。
この方法を採用する場合には、サービスとしての登録は行わない方が賢明です。monit単独で利用されることが望ましいと判断します。この方法とサービスでの起動を両方採用することは、二重起動を引き起こす可能性を含んでいます。
多分、プログラムは正常に動作しますが、異常が発生した場合に何が原因なのか特定することが困難になる気がします。

/etc/monit.d/dummy.confを以下の内容で作成します。

1行目:監視対象を指定します。
2行目:起動方法を指定します。
3行目:終了方法を指定します。
4行目:異常時の処置を指定します。今回はポート10050を使用しており、10050ポートが開いているかどうかを確認しています。
5行目:10回再起動をトライしてダメだったら再起動を取止めるという内容で、再起動の試行回数を指定しています。

後は、monitに設定を読込ませれば完了です。以下のコマンドでmonitに設定内容を読込ませます。

以上で完了です。
監視状況を確認するには以下のコマンドで確認出来ます。

 

サービスの監視

サービスの監視も基本的には同じです。

設定ファイルが以下の通り変更になりますが、実際には同じでも大丈夫です。
サービスとして登録する方法は前回を参考にしてください。

プロセスと異なり、systemctlを使用して起動と停止を行っています。
起動時にsystemctlコマンドを使用することで、サービス側との二重起動が避けられます。PIDはSystemd側で管理されていますので、Systemdを経由した起動の方が都合が良いわけです。
dummyプログラムのPIDを調べれば解ることなので、pkillやkillを使用して停止させることも出来るのですが、Systemd側における管理が煩雑になることを避ける意味から、systemctlコマンドを使うことになります。

サービス登録をしてRestartによる再起動を行った場合は、ポートの状態までは監視してくれませんでしたが、monitを使うことでポートの監視を行える様になっています。
ただし、固定のポートアドレスをハードコーディングで行う必要があるため、ちょっと使い勝手が良いとは言えません。

尚、この場合にはサービス登録側の設定も少し変更した方が良いでしょう。

こんな感じになります。

 

プロセスとして登録した場合とサービスとして登録した場合を敢えて記載しましたが、monitだけで十分では無いか?と考えると思います。通常はmonitだけで十分だと私も思います。

サービスとして登録する意味があまりある様には思えません。

敢えてサービスとして登録する意味はと言えば、一意のファイル名でプログラムが作成されていれば良いのですが、同名の実行ファイル名でプロセスが起動する様な場合には、サービスにしておく意味がある・・・と言うことぐらいでしょうか?

更に突っ込んで!monitが死んだら?

サービスで登録した場合でもプロセスとして登録した場合でも同じことなのですが、monit自体が死んでしまったら、プロセスを再起動することが出来ません。

CentOS 7では、UpStartの設定に従来の/etc/initが使えません。

ということで、/usr/lib/systemd/system/monit.serviceを変更します。

Restart=alwaysを追加しただけです。

これで、自動的に再起動を行ってくれます。

 

 

独自コマンドのサービス登録(CentOS 7)

今回は、CentOS 7上で自分で作ったプログラムをサービスとして登録する方法について説明します。

CentOS 6までとは管理の方法が異なっているため、ご注意ください。

環境はCentOS 7です。

今回のお題は

独自に作成した常駐プログラムをサービスとして登録します。
仮に、dummyというプログラムをサービスとして登録します。
dummyプログラムは単体で動作する時、常に動作状態を維持し障害や何らかの人為的操作以外で停止することが無いプログラムであると仮定します。
なんか難しく書きましたが、要は異常がない限り動き続けるプログラムを準備します。
それをサービスとして登録します。

サービス登録内容の記述

サービス登録を行うためには、設定内容をファイルに記述する必要があります。
そのファイルは以下のフォルダーへ保存します。

試しにdummyプログラムをサービスとして登録する場合の記述内容を以下に記します。

[Unit]ではこのサービスに関する説明を記しています。
Descriptionで簡単な名前を登録します。

[Service]では、以下の内容を登録しています。
Restart:always・・・サービスが停止していた場合に自動的に再起動を行います。
StartLimitInterval=60・・・①
StartLimitBurst=5・・・・・②

StartLimitInterval中にStartLimitBurst回の再起動を試みますが、それが失敗した場合には、次のStartLimitInterva時間は再起動を試みません。という設定になります。

PIDFileはPIDを出力する先を示しています。
ExecStartはコマンドの起動方法です。
ExecStopはコマンドの終了方法です。

[Install]
WanterByでは、OSの起動のセッションを指定しています。
multi-user.targetはinit 3の起動時に相当します。
他にgraphical-user.targetなどを指定することが可能です。
multi-user.targetを指定した場合、graphical-user.target時にも起動されます。これは、graphical-user.targetがmulti-user.targeをベースにしているためです

上記の設定では、プロセスが起動できない状態が発生した場合、永遠に再起動が繰り返されることになります。

また、プロセスがゴースト(defunct)になってしまった場合に、プロセス自体が残るため再起動が行われない可能性が残ります。
そういう意味では、少し問題を抱えていると思っても良いでしょう。

この解決方法については、別途説明したいと思います。

サービスの起動と終了

サービスを起動するには、通常通り以下のコマンドでサービスを起動します。

終了させるには、以下のコマンドです。

startもstopも基本的に何もエコーバックされてこないのでstatusで確認を取るのが賢明でしょう。

startさせた後に、OS起動時の登録を行う場合には以下のコマンドを実行してください。

disableすれば起動時の登録は解除されます。

課題

Systemdで登録したサービスの再起動には、先に述べた通り、プロセスがゴースト化してしまったり、何らかの異常が発生して実際の動作を行っていない場合の対処法がありません。
そんな時には、サービスとしての登録だけは行い、monitなどのプロセス監視を併用すると良いかと思います。

次回は、このDummyサービスをmonitを併用したプロセスの自動再起動をやってみようと思います。

 

WordPressを更新したら、Adsenseが消えた( ゚Д゚)

一か月以上更新をさぼっていたブログ。。。。いつものことですが(^^ゞ

さてさて、見ていて解ると思いますが、ここのブログサイトはほとんど何も手を加えておらず、テーマもそのまま使っている状態です。

ということで、何も気にせずにデフォルトのテーマにAdsenseのコードだけを埋め込んで使っていたんですw

で、更新したら広告が出ていない・・・それもしばらく見ていなかったから、なんで?となっちゃうわけでwww

いや~お粗末!

ということで、同じようなことやってる人が居るだろうということで書いときます。

テーマをデフォルトのままカスタマイズして使っていると、テーマを更新した時にカスタマイズ内容が消えてしまうということです。

と言うことは、バックアップして・・・じゃなくて、コピーして使っておけば良いわけです。

と言うことで、コピーしちゃいましょう!

まずはWordPressをインストールしているディレクトリへ移動して、更に以下のコマンドでテーマが保存されているディレクトリへ移動します。

themesディレクトリには、各テーマのディレクトリが存在します。
その内、カスタマイズを行いたいテーマのコピーを作ります。

上記のコマンドのtheme_nameは対象となるテーマ名を指定してください。私の場合は「twentyfourteen」としました。コピー再帰には「twentyfourteen-clone」を指定しました。
-p は、コピー元の日時を維持してコピーします。
-rは、ディレクトリ毎再帰的にコピー素行います。

普通ならコピーはこれでおしまいなのですが、同じ内容のテーマが2つ存在してしまうことになって、少し面倒です。

そこで、テーマを管理している内容を少しだけカスタマイズしてしまいます。

先程作ったテーマのフォルダーにあるstyle.cssを編集します。

twentyfourteenのクローンを作ってみたのですが、内容はこんな感じです。(2行目と7行目だけ少し変更しました。)

一応、「Theme Name」だけでも変更しておくと良いでしょう。

これで終わりです。
テーマを見てみると新しく作成した「XXXX-clone」のテーマが選択できるようになっているはずです。

このクローンテーマを使ってカスタマイズしておけば、テーマの更新でカスタマイズ内容が消えてしまうことのないはずです。

私の場合は、再度Adsenseのコードを取得し直して、header.phpにコードを割り当てて完了でした!すでに承認が下りていますので、すぐに広告が表示されると思います。

ただ、クローンで作成したテーマは更新が行われないことに注意しましょう!
セキュリティ的な観点からも、そのままクローンを使い続けるのではなく、クローン元のテーマが更新された際には、そのテーマ元に更新を行うことが必要です。
テーマの更新が行われるたびに、毎回同じことを行わなければならないというのが課題です。
うーん・・・・何か良い手はないものだろうか?
何方か、良いアドバイスを頂けると幸いです。
私も気が付いたら、何かやってみようと思います。

以上

気になる技術の使い方を記録しています。マニアックなところもあると思いますので、ご利用は自己判断で。