「未分類」カテゴリーアーカイブ

node.jsをインストールすることから始めます。

今回は、node.jsをインストールすることが目的ではないのですが、この後に書く予定のdeck.glをインストールするために、node.jsをインストールする必要が生じたため、手順を踏んで記録に残すことにしました。

node.jsのリポジトリを登録する。

またしても、CentOS 7上に環境を構築します。
以下のサイトを開いて、最新版を確認します。

https://github.com/nodesource/distributions/tree/master/rpm

執筆時点では、setup_12.xが最新版でした。
最新版をインストールするため、以下のコマンドを実行します。

これで、基本的なインストールは完了です。

実は、過去にnode.jsをインストールしていたマシンだったので、こんなメッセージが表示されました。

「sudo yum remove -y nodejs npm」ということで、削除します。

その後の情報も確認しつつ、node.jsのパッケージをインストールします。

これで完了です。
バージョン確認を実施し、最新版のnode.jsがインストールされていることを確認しましょう。

無事インストールが完了しておりましたので、今回はここまでとなります。
続きは別途。。。

CentOS 8 リリース待ち→リリースされた2019-09-24(^^)

2019年5月7日にRHELがリリースされてからもうすぐ100日が経過しようとしている。

<2019-09-25追記>
現地時間9/24、CentOS 8がリリースされました!
これで使えるようになりますが…問題は、VirtualBoxでGUIを含む状態でインストールする場合には、問題があるようです。
以前(CentOS 7)から気にはなっていたのですが、基地の問題として残っているようです。
仮想マシンとして考えている方で条件が合致される場合は、他の仮想か技術を考えた方が良いかも知れませんね。

意味が違ったようですm(__)m
「Server With a GUI」/「サーバ(GUI)」を選択してインストールするとGUIが立ち上がらない障害がある様です。
詳しくは以下のサイトをご参照下さい。
https://wiki.centos.org/ja/Manuals/ReleaseNotes/CentOS8.1905#head-9ed7a1765d703716a543781d18c13e50868f0516

と言いつつ、読んでみてもよく解らなかったので調べてみることにしたら、こちらの記事が解り易かった。
https://qiita.com/edward999th/items/d199125dbb8286d91152

「ベース環境」の選択で「Server with a GUI」もしくは「サーバー(GUI)」を選択してインストールすると既知の問題に遭遇するらしい。
インストーラのバグか?という感じですが、原因までは調べていません。
「ワークステーション」を選択してインストールする分には問題が無いようなので、GUIを使いたい場合には別の選択肢を関g萎えた方が良さそうですね。

<2019-09-23追記>
なんか、明日(2019-09-24)にリリースされるそうです。
9月に入ってからのダタバタ劇はなんだったのか?踊らされていたのか?
とにかく、現地時間の明日にはリリースされるとのこと、期待して待ちましょう。

※2019-08-26 時点でまだリリースされていません。
※2019-09-15時点でまだリリースされていません。

※2019-09-23時点でまだリリースされていません。

<2019-09-15追記>2019年8月にリリースされたRHELに対応するため、CentOS 7.1909の更新準備が先行されているのですが、wikiを見てみると約1ヶ月くらい掛かるみたいです。10月以降にならないと開発は再開される見込みは無さそうですね。年内にリリースされるのかなぁ?

RHELのクローンとしては、CentOS/Scientific Linux/Oracle Linuxなどが知られているが、以前にCentOSよりリリースが早くて話題となったScientific Linuxは8以降のリリースを行わないとの表明が行われていますね。

単純な比較は難しいところですが、CentOSとOracle Linuxはクローンと言われているけど、Oracle Linuxは少し違いますよね。

Oracle Linux 8は7/18にリリースされました。
CentOSはまだ少し掛かりそうです。

進捗状況は以下のURLで公開されています。

https://wiki.centos.org/About/Building_8

もうカウントダウンですねw

8/15にボストン大学でDevConfが開催されるので、その頃にはRC版が出てくれそうな感じかな?
残念ながら発表はありませんでしたね(^^ゞ

9/10に動きがありました。
7.7がリリースされるそうです。そのため、8の開発が停止してしまいました。
もうすぐ!と思ったら、まだ先になりそうです。
首を長くして待ってます。

正式リリースが待ち遠しいですが、更にクラウド(VPSなど)で使えるようになるには、まだまだ時間が掛かりそうな雰囲気です。

リリースされたら、インストール方法などをまとめたいと思っています。

8/15時点では、Release Workを残すのみ!
最終段階か?と思いきや・・・

こんな感じで、まだ更新中だったりしています(^^ゞ
https://koji.mbox.centos.org/koji/index

UTC 2019-08-15 15:50頃

でも、ここまで来ると本当に「あと少し!」って感じですね。

早ければ明日にもリリースか?とか期待してしまいますが、土日は進捗が止まっているので、来週8/21辺りが最短リリースじゃないかな?と、期待してます(#^.^#)

さてさて、まだまだリリースされる感じがしない。
8/20から全く更新する気配すら感じられなくなりました。
オープンソースカンファレンスの影響だろうか?
ここまで来たら、来月中にはリリースされるでしょう。
CentOSのサイトでは、「いつリリースされるの?」というコメントが出ていたり、首を長くして待っている人がいらっしゃいますね。
もう、ほとんどの作業は済んでいるはずなので、最後の詰めがしっかりされて発表して頂ければと思います。
しばらく、期待して待ちましょう。


2019-09-10 According to this thread, work was stopped on CentOS 8 after upstream released 7.7. Since so many more users have CentOS 7.x in production, and no one has 8 yet, priority has been given to the 7.7 update… and once it is done, work will continue on 8.

https://wiki.centos.org/About/Building_8

9/10時点で7.7のリリース作業のため、8の作業が停止してしまいました。
ちょっと厳しいなぁ~
今月中のリリースはあるのか?

仮想OSでインストールしたWindows 10がLAN上のNASに繋がらない時の対応

概要

VirtualBoxでWindowsをインストールした時に、LAN上のNASが接続出来ない状況が発生しました。
その対処についてまとめます。

最終的な結果として、プレインストールのWindows PCで同現象が発生していないことから、Windowsをメディア等からインストールした時に発生する現象であると思われます。
私の環境では、Windows 10で現象が確認されましたが、Windows Server 2016でも同現象が発生するもとの思われます。
その他Windowsの各バージョンにおいて発生した場合でも参考になるかも知れません。

Windows からNASに接続出来ない場合の対処法として記録します。

具体的な現象

VirtualBoxでWindows 10の環境を構築しました。
VirtualBoxでLAN上のネットワークに接続する方法は他にもありますが、ブリッジ接続を選択しました。
プライベートネットワークとして接続しています。

この状態で、通常のプレインストールされたWindows PCであれば、特に気にすることなく接続出来ると思うのですが、新規にインストールしたWindowsからは見えませんでした。

対策内容

幾つかの対策を行いました。
それぞれ順を追って説明しますが、以下に一覧を記します。

VirtulaBoxにおけるネットワークの設定

WindowsをVirtualBoxで仮想OSとして構築した場合について記載します。
ホストOS(Physical OS)の場合は、この項目の内容を飛ばして、次の設定に進んでください。

Windows側のネットワークの設定

Windowsのネットワーク設定がパブリックになっている可能性があります。
当初、私の環境ではパブリックになっていたのでプライベートに変更しました。設定は以下の手順です。

「ネットワークとインターネットの設定」を開きます。

画面右下のネットワークアイコンを右クリックすると以下のポップアップが表示されます

「ネットワークとインターネットの設定を開く」を選択します。

赤枠で囲んだイーサネットのアダプタをクリックします。

「パブリック」になっていたら、「プライベート」に変更してください。

ネットワークと共有センターの設定

ネットワークと共有センターの設定は、一つ前の画面にある「ネットワークと共有センター」を選択すると移動が楽です。

左メニューの「共有の詳細設定の変更」を選択します。

「ネットワーク探索を有効にする」を設定してください。

ワークグループの設定

「コントロールパネル」→「システム」を開きます。

「設定の変更」を開きます。

「変更(C)」で開かれるダイアログで、ワークグループを適切に設定してください。

ここまで来ると、エクスプローラで「ネットワーク」を選択すると、対象となるNASの名前が表示されたりします。
表示されない場合もありますので、あまり深く考えないで次へ進みましょう。

レジストリの設定

最大の難関はここでした!

「regedit」を起動します。
次に、以下のレジストリを探します。

「AllowInsecureGuestAuth」の項目を確認し、「1」をセットします。

再起動を行うことをお勧めしますが、私の場合は再起動なしでもNASへアクセス出来る様になりました。

ただ、このレジストリが見つからない場合もあります。
環境に依存している可能性もあり、判断が難しいところですが、新規に作ってしまうという手もあるのか?ご自身の責任で試してください。
レジスタを追加するのは、最後の手段にしておく方が良いでしょう。
保証も何もありません。

最後に

この現象はWindowsのアップデート後に発生している方も多い様です。
SMB絡みの不具合でもあると思いますが、MS社からすれば仕様なのかな?
そもそもWindows自体が安定性に乏しいということなのでしょう。
この問題は、Windows Server 2016でも報告されているので、アップデートの際にきちんとしてくれるとかないのかねぇ?MS社は無駄な労力をこういうところで強いるので、サポートをもっと手厚くしてほしいですね。

これがWindowsカテゴリ最初の投稿になるとは・・・w

GeoTiff 座標系変換と結合

前提

国土地理院の地理院地図やGoogle Mapで提供されている航空写真を用いずに、独自に入手した衛星画像や航空写真を用いて広範囲の画像を表示させようとした時、座標系の変換と画像の結合が必要となります。

一般に入手される航空写真などで提供されている画像の座標系はJGD2011など、Web上では使い難い座標系を用いている場合が多く見受けられます。
その為、多くの場合には、座標系を変換する必要が生じるのです。
本資料では、この作業を行うための環境について説明し、衛星画像や航空写真などを用いて、座標系変換を行ってから画像を結合する以下の手順について説明します。

  1. 環境準備
  2. 画像の座標系を確認する。
  3. 座標系を変換する。

では順番に進めましょう。

環境準備

環境準備と言いましても、インストール方法については割愛します。
既に、本サイトでも紹介をしているOSGeo4Wをベースにお話しを進めます。
ただし、衛星画像や航空写真を結合する作業を行うには、正直申し上げてWindows環境はあまり適している環境とは言えません。
その理由としては以下が考えられるでしょう。

  • コマンドライン(シェル)が使い難い
  • 元々メモリの消費が激しく、大量のメモリを消費する作業では使い勝手が悪い。

数枚の画像を扱う程度であれば、GISツール(QGISなど)を用いて、ちまちま行うという方法もあるでしょう。パッチ処理などでまとめて出来るよ!という方もいらっしゃるとは思いますが。。。無視!

ということで少し作業がやり易いように1つツールを入れて作業を行っています。
また、一部の操作に関しては、Linux上で作業を行うかも知れません。

環境としては、以下の環境を準備しました。

Windows 10
OSGeo4W (GDALが入っていればOK!)
 参考情報:https://trac.osgeo.org/osgeo4w/wiki/OSGeo4W_jp
 過去の参考情報:https://tech.godpress.net/?p=368
Gow
 参考情報:https://ja.wikipedia.org/wiki/Gow

実際の作業ではGDALを使用します。
GDALのみをインストールした環境を準備されている方は、その環境を用いてもOKです。(って、そんな環境造っている人が、このサイトを参考にされるとは思いませんが。。。)

画像の座標系を確認する

OSGeo4Wをインストールしている場合、QGISで確認しちゃおう!という方は、GUI上でプロパティ確認で終わっちゃいますね。
でも今回は、コマンドライン操作が基本となりますので、コマンドで対処します。

Gowをインストールしていると、Linuxと同じような感覚でコマンドラインの操作が行える様になります。

なんでコマンドラインで作業を行うかと言いますと、入手した画像が全て同じ座標系であれば、あまり大したことではないのですが、時折、異なる座標系の画像を提供されて結合する場合があり、全ての画像を同じ座標系に統一しないと画像を結合した時にズレが生じて隙間が発生するのです。
間違って座標変換を行わないためには、事前に元画像の座標系を確認しておく必要があるためです。
では、実際のコマンド操作に関して説明します。

以下のコマンドは1つのファイルに対して座標系の確認を行うためのコマンドです。

複数のファイルに対し一括して確認を行う場合は、対象ファイルがあるフォルダーへ移動してから、以下のコマンドを実行します。

「gfind」コマンドは、Linuxの「find」コマンドをGowが実装したコマンドになります。

最初の引数「.」は対象となるフォルダーを指定しています。
対象フォルダーへ移動せずに、直接フォルダーを指定しても構いません。

-name *.tif :対象となるファイル名を指定します。ここではワイルドカードを用いた指定を行いました。全てのtifファイルが対象となります。

「|」で次のxargsコマンドへ出力結果を引き渡しています。
xargsコマンドでは-n 1とすることで、ファイル名を一つづつ処理します。
gdalinfo <ターゲットファイル>がファイル数分処理されます。

最後に、grepで必要な行だけを取得しています。

座標系を変換する

今回は、以下のフォルダー構成を想定して作業を進めます。
<作業フォルダー>—<EPSG102617>
         |
                                   +<EPSG4326>
コマンド操作は、<作業フォルダー>で行います。
<EPSG102617>は元の画像が保存されているフォルダーです。
先程の確認で座標系がEPSG:9001となっていましたが、内部ではEPSG:102617が正式な座標系となるためこの様にしています。

<EPSG4326>は座標変換後の画像ファイルを出力するためのフォルダーです。

既にお分かりのことと思いますが、本資料では、EPSG:102617(9001)→EPSG:4326の座標系変換を行います。

少し長くなりますが、以下のコマンドを実行してみましょう。

gfindコマンドで対象ファイルを特定し、そのファイル名だけを抜き出し、gdalwarpコマンドへ引き渡しています。

gdalwarpコマンドでは、-s_srsで元の座標系(102617)を-t_srsで指定される座標系(4326)へ変換を行うことを指定しています。
-srcnodataでは、元画像の中にある不要なデータのカラーコードを指定しています。同様に-dstnodataで出力時のノーデータを指定しています。

-srcnodataや-dstnodataを指定しなかった場合、画像の繋ぎ目に隙間が生じ、黒く筋が入ってしまうと思います。
座標変換に伴う歪により生じた隙間が黒色で塗潰され、それが隙間となってなって見えている状態になります。

これを除外するために、-srcnodataと-dstnodataを用いて不要なデータ部分を見えなくしているのです

余談・・・画像結合に関して

これだけの画像を準備したのですから、画像結合の話を少しだけ。。。
実は、画像結合してタイル画像を作成する予定だったのですが、マシンの不調とその必要性が無くなってしまったので、余談として記載します。

画像の結合にはgdal_mergeを使用します。

コマンドはこんな感じです。

-a_nodata “255 255 255″を追加した方が良さそうに思います。
環境変数GDAL_CHACHEMAXの値を出来るだけ大きくすると良さそうです。
ちなみに、gdalbuildvrtで仮想ファイルを作成して作業を行う方が効率良いとも思います。

こんな感じでしょうか?
タイル化などにご興味のある方は、別途ご連絡ください。

cudaGetDeviceCount が-1だった。

OpenCVでcudaGetDeviceCountを用いて、Cudaが利用可能な状態か調べていたのだが、通常はデバイスの認識がされていないと0が返されるところで、-1が返されていた。

結論は、NVIDIAのドライバとcudaのバージョンが合わなかったためでした。

NVIDIAのドライバをバージョンアップすることで、解決しました。

【小ネタ】CentOS 6/7における安全なhttpd再起動の再起動方法

小ネタです。

今更感が強いです。

でもメモしておきます。

ここ最近、ブログさぼってました。
ついでに、Apache Http Server 2.2系から2.4系に移行しようとして、ガッツリ嵌ってしまいました。
その結果、ここのブログが10日ほど障害発生&クローズ状態が続いておりました。
閲覧者の方にはご迷惑をお掛けしたことと思います。
お詫び申し上げます。

さて、気を改めて、HTTPサーバを再起動する時に誰かが閲覧中だったりすると困りますよね。いきなりサーバが落ちて正常に反応してくれない!バグってる!!落ちた!!!

そんなことを少しでも起こさない様にしたい!ということで、今回の小ネタです。

CentOS 6における安全なHTTPサーバ再起動方法

コマンドはこんな感じです。

ご存知の方も多いですよね。
今更ですよね。
でも知らない人も多いんですよ。・・・きっとw

CentOS 7における安全なHTTPサーバ再起動方法

CentOS 7ではserviceコマンドが非推奨となってしまいました。
systemctlコマンドへ移行されています。
systemctlコマンドではgracefulのオプションがありません。
ではどうやってやるのか悩ましいところでもあったりします。
でも、以外に解り易いオプション名に変更になったのではないでしょうか?

ということで、コマンドは以下の通りです。

設定の「再読み込み」と覚えておけば、今までよりも解り易くないですか?私だけかな?

ということで、小ネタでした。

 

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アドレスを追加します。

こんな感じです。

以上で完了です。

最後に確認

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

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

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

 

プロセスの監視と再起動(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を追加しただけです。

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

 

 

解ってきたPVの上がり方!

このブログを書き始めて、少しづつPVが上がる傾向が解って来た。
#今更ですね。
全く気にしていなかったかというと嘘になりますが、PVが増えると少しは見てくれている人が増えているんだなぁ~と、少しはヤル気に繋がります。

このブログは技術的なメモを記録しているだけで、技術的に特化したトピックスに注力したブログではなく、ある意味では書き散らかしているという感があるので、参考にならないかもしれませんが、概ね4ヶ月後ぐらいに書いたページを閲覧してくれる人が増える傾向にあります。

つまり、書いた直後からPVが増えることは無く、検索エンジンに登録されて閲覧数が増えてくるのは3ヶ月後くらいからという感じになります。

内容によっては鳴かず飛ばずもありますが、概ねその後成長し続けるか衰退するかは5ヶ月目以降の推移に傾向が現れます。

ブログを下記始めの頃は検索エンジンで検索出来るようになったら、いきなり増えてくると思ってしまうかも知れませんが、実際は数か月後に現象が現れるということを覚えておくと良いでしょう。

逆に、私の場合は繁忙期が3月頃に集中するため、2~4頃に記事を書かなくなった経緯がありました。
その反動は、6月頃から現象が現れ始めました。
現在8月の段階で著しい落ち込みが顕在化しています。

コンスタントに記事を書き続けることが、PV安定化の道ですね。
増やすためと考えるよりも、安定化させるために記事を書いていると、少しづつPVが増えることになるのではないでしょうか?

 

OpenSceneGraphをLinuxへインストールする。(2回目)

前回に引き続きOpenSceneGraphをLinuxへインストールします。

前回の記事では、CUIのcmakeを使って作業を行いましたが、今回からはcmake-guiを使用します。

まずは、前回記事の最後に記したcmake-guiのインストールから説明します。

cmake-guiインストール

簡単です。

これだけです。

cmake-guiを実行すると、こんな感じで見ることができます。

OpenSceneGraphのソースがあるディレクトリへ移動して

 

#前回記事をそのままコピペしましたw

さて、ここから使い方を説明します。
起動直後は何も設定されていません。
ソースコードの在りかと、出力先を指定する必要があります。

where is the source code:  ここにOpenSceneGraphのディレクトリを指定します。

where is build the binaries: ここに出力先を指定します。OpenSceneGraph/binで良いと思います。(フルパスで指定してください。)

これで準備は完了です。

画面左下にある「Configure」をクリックすると新しい画面が開きます。

Linux上で使用するだけであれば、何も変更する必要はありませんので「Finish」をクリックします。

あとは勝手にチェックして結果を出してくれます。

前回色々なパッケージを追加しましたが、まだ足りないパッケージが幾つかありそうです。

パッケージの追加

それでは頭から見ていきましょう!

ASIO:Audio Stream Input Output
オーディオ関係のライブラリです。OpenSceneGraph(そろそろ面倒なのでOSGと今後称します。)では音響も扱えるために準備されているようです。
特に必要なければ放置して構いません。

COLLADA:COLLADA形式の3Dモデルを使用する場合に必要となります。
今回はこちらも必要ないので入れません。

DCMTK:同様です。DICOMファイルを扱う為のパッケージです。

FBX:こちらも同様に必要ありません。

GIFLIB:こちらはGIFのライブラリですね。
テクスチャなどで使う可能性がありますので、後程インストールします。

INVENTOR:こちらも同様に必要ありません。

LAS:librasで探すと見つかります。点郡データのフォーマットを処理するためのライブラリです。こちらも同様に必要ありません。

LIBVNCCLIENT/LIBVNCSERVER:VNCを使う為のパッケージです。必要ではないのです。

NVCORE/NVIMAGE/NVTT:本来いれたいところなのですが、実行環境の都合で今回はインストールしません。NVIDIAのライブラリです。

OPENEXR:画像フォーマットのライブラリですが、今回は必要ありません。

OPENVRAML:VRMLも今回は必要ありません。

PERFORMER:これももう使いません!

Qt5:気になります。出来ればインストールしてみようと思いますがQt4が既に入っているので消極的です。

SDL2MAIN:これが入っていないのはちょっと不思議。でも見つからなかった。
ググっても殆ど情報無いので、多分要らないだろうと思うことにする!
多分、SDLが入ってるからなんとかなるだろう!

XINE:動画関連のライブラリで入れたい。。。けど面倒だった記憶が甦る。

ざっとこんな感じですね。

では、インストールを進めます。

それぞれ以下のコマンドでインストールします。

これでデフォルトの環境構築ができる状態にまで至りました。

でも、サンプル動かしてみたいですよね。

ということで、サンプルを動作さえる為には、一つオプションを追加する必要があります。

BUILD_OSG_EXAMPLEにチェックを入れてください。
その後、Configureを再度行うと。。。。

FLTKとwxWidgetsはウィジェットエンジンですね。
FOXもFoX ToolkitというGUIのウィジェットエンジンですね。

FLTKとwxWidgetsについてのみインストールします。

 

やっと来ました!

「Configure」を実行してインストール漏れが無いことを確認したら、忘れてました!

怒られています。

もう一度!「Configure」を実行してインストール漏れが無いことを確認したら、続けて「Generate」を実行します。

行けたみたいですね。

とは言ってみたものの、まだ何も出来ていません。

正確に言うと、まだ準備が終わっただけです。

ここまで来たら疲労感が激しい。
でも、ここからが大変なんです。

コンパイル

ここからコンパイル作業を開始します。

コマンドライン上で、以下を実行します。

 

make時に出たエラーは、適宜エラー内容を評価して必要なパッケージをインストールしてください。
また、バージョンが低いためにコンパイルできないとかも発生します。
特に、cmake-gui画面でパスが設定されていない項目に関しては、必要に応じてパスを設定した上で再度コンパイルを実行する必要があります。

環境により異なることになりますので説明から除外しますが、基本的なプログラムはこの段階で概ね生成可能です。

つづけて

 

作成された実行モジュールが適当な場所にインストールされます。

ここで、サンプルデータをダウンロードして保存します。
データは以下からダウンロードします。

https://www.openscenegraph.org/index.php/download-section/data

ダウンロードしたファイルは、適当なディレクトリに解凍します。
ここで仮に/home/OpenSceneGraph-Dataとします。

データを保存した場所を環境設定します。

~/.bashrcなどに以下を追記します。

必要に応じてコマンドラインを再起動したり、もしくは以下のコマンドで再設定を行います。

 

テスト的に、以下のコマンドを実行します。

 

これで、牛のモデルが表示されたら完了です。

以上で完成です。