zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

PostGISのconfigureでchecking for library containing GDALAllRegister... no　って言われたメモ

# What's PostGIS
# →PostGIS (ぽすとじす) は PostgreSQL データベースで地理空間情報を扱うための拡張である。
# 　GNU General Public License のオープンソースソフトウェアとして配布されている。

【問題】

Chapter 2. PostGIS Installation

必須モジュールおよびバージョン
PostgreSQL 9.2 or higher
GNU C compiler (gcc)
GNU Make (gmake or make)
Proj4 reprojection library, version 4.6.0 or greater
GEOS geometry library, version 3.3 or greater
LibXML2, version 2.5.x or higher
JSON-C, version 0.9 or higher
GDAL, version 1.8 or higher

モジュール群を上記URLにある取得元からそれぞれwgetしてconfigureしてmakeしてmake installしたのち、

wget http://download.osgeo.org/postgis/source/postgis-2.3.2.tar.gz
tar -xvzf postgis-2.3.2.tar.gz
cd postgis-2.3.2
./configure

としたところ、以下のエラーとなってハマった。GDALもインストールしたのだけど。。

checking for library containing GDALAllRegister... no
configure: error: could not find GDAL

【解決】

postgisのconfig.logに

/usr/bin/ld: warning: libpq.so.5, needed by /usr/local/lib/libgdal.so, not found (try using -rpath or -rpath-link)

っていうのがあった。libpq.so.5は　/usr/local/pgsql/lib　の下にあったので

/etc/ld.so.conf　の末尾に以下を追記

/usr/local/pgsql/lib

↓↓

 -------------- Compiler Info -------------
  C compiler:           gcc -g -O2
  SQL preprocessor:     /usr/bin/cpp -traditional-cpp -w -P

 -------------- Dependencies --------------
  GEOS config:          /usr/local/bin/geos-config
  GEOS version:         3.6.1
  GDAL config:          /usr/local/bin/gdal-config
  GDAL version:         2.2.0
  PostgreSQL config:    /usr/local/pgsql/bin/pg_config
  PostgreSQL version:   PostgreSQL 9.3.4
  PROJ4 version:        49
  Libxml2 config:       /usr/bin/xml2-config
  Libxml2 version:      2.7.6
  JSON-C support:       no
  PCRE support:         no
  PostGIS debug level:  0
  Perl:                 /usr/bin/perl

 --------------- Extensions ---------------
  PostGIS Raster:       enabled
  PostGIS Topology:     enabled
  SFCGAL support:       disabled
  Address Standardizer support:       disabled

 -------- Documentation Generation --------
  xsltproc:
  xsl style sheets:
  dblatex:
  convert:
  mathml2.dtd:          http://www.w3.org/Math/DTD/mathml2/mathml2.dtd

通った。。。

【シェルスクリプト】手動で叩いたら動くのにcron経由で動かすと動かない場合の確認方法

以下の様にして、特定ログフォルダの中身をAWS S3に同期してから日付を指定して削除するシェルスクリプトを作ってみたとき、手動で実行したら問題なく動いたのに、cronで動作すると、発火はしている様なのに、失敗している。

スクリプト本体

vi /home/hoge/bin/move-logs-s3.sh

#!/bin/sh
MYEIP=`curl -q http://169.254.169.254/latest/meta-data/public-ipv4`
S3BUCKET="S3バケット名"
OLDLOGDIR="対象ログDIR"

# s3 sync
aws s3 sync ${OLDLOGDIR} s3://${S3BUCKET}/${MYEIP}/logs --region ap-northeast-1

# tmpwatchで30日以上経過したファイルを削除
tmpwatch -m 720 ${OLDLOGDIR}

crontab

crontab -e

# move logs to S3
0 0 * * * /home/hoge/bin/move-logs-s3.sh > /dev/null 2>&1

cronのログを見るためには

MAILTO=メールアドレス
0 0 * * * /home/hoge/bin/move-logs-s3.sh

のようにして実行してみると、ログがメールで飛んでくる。
※今回はaws s3コマンドでリージョンが指定できていなかったためのエラーと分かった。上記のは修正済みです。

【さくらのクラウド】マイアーカイブからのサーバ作成時のディスク修正機能について

さくらのクラウドの「マイアーカイブ」からサーバ立てたらIPは衝突するわresolv.confは書き換えられるわでハマった。

【ひとまずの結論】

アーカイブ元のサーバでネットワークの設定をカスタマイズしている場合、そもそも[ディスク修正]機能は利用するべきではない。

□ディスク修正対象ファイルは以下にまとめられている。

cloud-news.sakura.ad.jp

3. ディスク修正機能により修正される項目(指定可能な修正項目)

例えば、スイッチ配下のインナーネットワークの端末のifcfg-eth0に

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
GATEWAY0=192.168.1.100
NETMASK=255.255.255.0
IPADDR0=192.168.1.101

みたいにセカンダリありきの書式で設定してしまっていると（CentOS7の例）、アーカイブから起動するときに「ディスク修正」で
GATEWAY=192.168.0.100
IPADDR=192.168.1.102
で書き換えを指定したとき

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
GATEWAY0=192.168.1.100
IPADDR0=192.168.1.101
GATEWAY=192.168.1.100
PREFIX=24
DNS2=210.188.224.11
IPADDR=192.168.1.102
DNS1=210.188.224.10

みたいになって、アーカイブ元のIPが生きたままになってしまい、既存サーバ群と衝突する（衝突した……）
ネットワークの設定をカスタマイズしている場合、そもそもディスクの修正機能は利用するべきではない。
逆にクラウドで運用するメリット（スケールのしやすさなど）を享受するためには、できるだけクラウド提供側の設定を遵守すべき。

4. ディスク修正機能により修正される項目(自動的に行う修正項目)

メモまで。

【さくらのレンタルサーバ】RewriteCond %{HTTP_HOST} でwww.hogehogeとhogehogeを分岐

【概要】

さくらのレンタルサーバの[サイトに関する設定]-[ドメイン設定]で

マルチドメインとして使用する（推奨）

を選択している場合
http://hogehoge.jp/
http://www.hogehoge.jp/
は同一のHTTP_HOSTとして扱われる模様
→http://www.hogehoge.jp/　でアクセスしても、%{HTTP_HOST}はhogehoge.jp(wwwがない)。
.htaccessでwww.hogehoge.jpにアクセスに来たらhogehoge.jpに301リダイレクトしたいとき、

RewriteEngine on 
RewriteCond %{HTTP_HOST} ^(www\.hogehoge\.jp)$ [NC] 
RewriteRule (.*) http://hogehoge.jp%{REQUEST_URI} [R=301,L]

では動いてくれない。

【回避策】

1)ServerName www.hogehoge.jp に当たる設定を追加する

[ドメイン設定]-[新しいドメインの追加]-[5. 他社で取得したドメインを移管せずに使う]
ドメイン名：www.hogehoge.jp で[送信する]。
※ネームサーバの設定は、ルートドメインの設定時に行われている前提。

2)hogehoge.jpのマルチドメイン設定を変更
wwwを付与せずマルチドメインとして使用する（上級者向け）

に変更

これで、www.hogehoge.jpから流入したときの{HTTP_HOST}に入る値がwww.hogehoge.jpとなるため、上記.htaccessが動作する。

前にも同じことでハマった気がするのでメモしておく。

【参考】

www.harukas.org

【MySQL】レプリケーション時のスレーブでread_only設定するかどうか問題

【メモ】

MySQLでレプリケーションするとき、間違ってスレーブを更新してしまわないよう、スレーブのmy.cnfに

[mysqld]
（省略）
read_only

を追記してる例を見た。今までやってなかった。slaveでupdateが無くもない人生なので、今後つけるかどうか検証

nippondanji.blogspot.jp
”スレーブを参照専用にするには、my.cnfファイルでread_onlyオプションを指定しておくと良い。read_onlyを指定しておけば、SUPER権限のないユーザは更新が出来なくなる。”
「SUPER権限を持つアカウント以外の更新クエリーは実行できなくなる」はず

【結論】

SUPER権限のあるユーザでやってしまえば更新処理ができちゃうけど、習慣としてはつけておくべき、とのこと。
ただ、フェイルオーバーを考えると、read_onlyはつけない方向で。
(Masterが死んだとき、hostsの向き先変更だけでSLAVEに書き込み開始したい）


【結論に至る調査メモ】

■SUPER権限って？
→SUPER権限の有無は以下で確認可能

mysql> SELECT user, Super_priv FROM mysql.user ;
+-----------+------------+
| user      | Super_priv |
+-----------+------------+
| root      | Y          |
| mysql.sys | N          |
| repl      | N          |
+-----------+------------+

→replはレプリケーションユーザだけど、必要ないの？
MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.1.1.3 レプリケーション用ユーザーの作成
”レプリケーションの目的にだけアカウントを作成する場合、そのアカウントには REPLICATION SLAVE 権限だけが必要です。”
ということらしい。

【試してみた】

Super権限じゃないユーザを作成
GRANT ALL PRIVILEGES ON `testdb`.* TO 'nosuper'@'localhost' IDENTIFIED BY 'パスワード';
FLUSH PRIVILEGES;


# マスターにnosuperユーザでログインし、insert
→insertできた

# スレーブにnosuperユーザでログインし、insert
→ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
→マスタでinsertした値はレプリケーションされている。


■その他大変ありがたい参考記事

http://blog.hypermkt.jp/my-conf_readony/

WordpressのMySQLがoom_killerで落とされた

【状況】

Wordpressのサイトが
データベース接続確立エラー
とか
Error establishing a database connection
とか言ってきた。

サーバに入ってMySQLのプロセスを確認
ps aux | grep mysql
→ない。
→ログ確認
/var/log/messages

May 22 14:46:25 hogehoge kernel: [36271139.069945] php-fpm-5.5 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

cat /var/log/messages | grep Killed

May 22 14:46:25 hogehoge kernel: [36271139.527800] Killed process 2559 (mysqld) total-vm:2066588kB, anon-rss:761800kB, file-rss:0kB

MySQLがoom-killerにより落とされた模様。

■mysqlのoom_killerの優先度を下げる

【参照】
http://hacknote.jp/archives/8356/hacknote.jp


強制終了プロセスの優先順位を以下の様にすることで
mysqlは殺されないようになる

vi /srv/bin/oom_update.sh

#!/bin/sh
 
# down mysql score 
mysql_pid=`cat /var/run/mysqld/mysqld.pid`
 
if [ "$mysql_pid" != "" ]; then
  echo "-17" > /proc/${mysql_pid}/oom_adj
else
  echo "can't get pid number"
fi


chmod +x /srv/bin/oom_update.sh
/srv/bin/oom_update.sh

# 確認
dstat --top-oom

--out-of-memory---
    kill score
php-fpm: pool  52

■PHP-FPMの子プロセス数を減らす

なおメモリのほとんどはphp-fpmが食っているので、プロセス数を減らした。

/etc/php-fpm.d/www.conf

;pm.max_children = 25
pm.max_children = 15

service php-fpm restart
service nginx restart

これで様子見・・・・・・