作業記録メモ

Linuxサーバー立ち上げ設定等のメモ(忘れないための作業記録)

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。




再起動時のディスクチェック

借りているVPSをたまにはアップデートしようと軽い気持ちでリブート

暫くしてもサーバが使えない、、、
そう言えば、/dev/xxx とかってのがコンソール接続時に出ていたような、、、

15分位して無事に使えるようになったが念の為に確認

tune2fs -l /dev/xxx で確認してみるとやはりディスクのチェックが掛かっていたみたい

次からは勝手にチェックが掛からないように設定変更

tune2fs -c -1 /dev/xxx で回数によるチェックを無効に
tune2fs -i 0 /dev/xxx で時間によるチェックを無効に
※ Ubuntu 12.04 いずれも root 権限で

とりあえず次からは再起動時に勝手にディスクチェックが掛からなくはなったので一安心
どのタイミングでディスクチェックするかは自分で決めたほうがいいね




スポンサーサイト

NGINXでBASIC認証を設定してハマったこと

NGINXでBASIC認証を設定してみよう!


元々の設定がこんな感じであったわけですが
~ 省略 ~
location / {
    try_files $uri $uri/ /index.html;
}

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

location ~ /\.ht {
    deny all;
}
~ 省略 ~

あちこちで参照したところ「auth_basic」と「auth_basic_user_file」なるものを記述すればOKな感じで書いてあったので早速以下の記述を追加(赤字の箇所
~ 省略 ~
auth_basic "secret";
auth_basic_user_file "/path/to/.htpasswd";


location / {
    try_files $uri $uri/ /index.html;
}

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

location ~ /\.ht {
    deny all;
}
~ 省略 ~

するとまんまと全てのページが認証ページに、、、

サブドメイン切ってそこは全て認証ページにって事であればこれでOKなんでしょうが、特定のパスだけに適応したい場合はこれでは使えないので以下のように修正(赤字の箇所
~ 省略 ~
location / {
    try_files $uri $uri/ /index.html;
}

location /secret/ {
    auth_basic "secret";
    auth_basic_user_file "/path/to/.htpasswd";
}


location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

location ~ /\.ht {
    deny all;
}
~ 省略 ~

で、http://hoge/path/to/secret/ と実行したところBASIC認証のダイアログが!!

これでスッカリ安心しきっていたのですが次の日に認証パスに入っている「adminer.php」を開くと認証が出てこないで直接実行されてしまうという自体に、、、

で、あれこれ試行錯誤している時にみたこちらのページによると location の優先順位がなんたらと

要するにどの location が選ばれるかはプレフィックスが = > ^~ > ~,~* > なし の順番で評価され、同じ優先度であれば先に記述しているものでマッチするものが選ばれる
ただしプレフィックスなし(前方一致)の場合は最長でマッチするものが選ばれるということなようです

なので上記設定の場合 http://hoge.path/to/secret/ であれば location /secret/ が選択されますが、http://hoge/path/to/secret/adminer.php だと ~ を含んでいる location ~ \.php$ が選択されてしまう訳です、、、orz

なので以下のように修正してみる(赤字の箇所
~ 省略 ~
location / {
    try_files $uri $uri/ /index.html;
}

location ~ /secret/ {
    auth_basic "secret";
    auth_basic_user_file "/path/to/.htpasswd";
}


location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

location ~ /\.ht {
    deny all;
}
~ 省略 ~

すると http://hoge.path/to/secret/ でも http://hoge/path/to/secret/adminer.php でもBASIC認証のダイアログがシャキーン!と表示(この場合 /secret/ だと全て認証になっちゃいますが、、、)
ひとまずめでたしめでたし!!

が、喜びもつかの間、、、
IDとPWを入力したところ adminer.php のダウンロードが開始されるという自体に、、、

色々と考えた挙句 location ~ /tools/ が適用されているから location ~ \.php$ が適用されていないって結論で以下のように修正(赤字の箇所
~ 省略 ~
location / {
    try_files $uri $uri/ /index.html;
}

location ~ /secret/.*\.php$ {
    auth_basic "secret";
    auth_basic_user_file "/path/to/.htpasswd";
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}


location ~ /secret/ {
    auth_basic "secret";
    auth_basic_user_file "/path/to/.htpasswd";
}


location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

location ~ /\.ht {
    deny all;
}
~ 省略 ~

一応上手く実行されるようにはなったもののなんとも長ったらしい設定になってしまった、、、(この記事も)
もっとシンプルに書く方法ってないのかな?



テーマ:サーバー - ジャンル:コンピュータ

PostgreSQLの接続数を増やすとサービスがエラーになる

PostgreSQL で接続を増やす必要があった場合に問題があったので記録

max_connections のデフォルトが 100 になっていたので、ユーザー数の増加に伴い設定を変更してみる。

ざっくりと接続数を増やしてみて、サービスを再起動してみると

FATAL: could not create shared memory segment: Invalid argumen


いきなりエラーが出てきて、PostgreSQL のサービスが起動しない、、、

こりゃイカンと設定を元に戻してひとまず復旧

エラーの内容を調べてみると、エラーに表示されてある通りですが、shared memory が確保できないようで、、、
カーネルのパラメータを変更してやる必要があるみたい、、、

sysctl -a|grep -i kernel.


で調べてみると、Ubuntu10.04 の初期値では shmmax の値は 32M となっており、これが少ないために上のエラーが発生しているみたい

サーバ自体のメモリはフンダンに積んであったのにこれじゃあきません、、、

/etc/sysctl.conf を開いて、値の編集を行う(設定されてある行はなかったので一番最後に追加)

kernel.shmmax=134217728


とりあえず 128M(1024x1024x128) 位にしてみる

OSの再起動を実行したところ、今度は接続数を増やしているにも関わらず PostgreSQL のサービスが無事に起動

いやはや、よかったよかった、、、



詳しい計算等はここを参照




テーマ:UNIX/Linux - ジャンル:コンピュータ

WordpressのTwitterToolsでハマった事

WordpressのTwitterToolsを導入する際にハマりました、、、

Twitterのカスタマーキーだのアクセストークンなんぞはよくわからない英語を辿りながら無事に登録できたのですが、
いざ!「Connect To Twitter」を押すと、、、

Fatal error: Call to undefined function curl_init() in /home/~

あー無情、、、

で、色々調べたところ、
と言うかエラーに出ているまんまですが、curlのPHPライブラリがUbuntu標準では導入されていないようです
カールおじさんガッカリ(意味不明、、、)

で、さっそくaptです
sudo apt-get install php5-curl

そして再実行、、、

Fatal error: Call to undefined function curl_init() in /home/~

がーーーん!

でも、この手の事には慣れたもので(悲しいけど)
apacheを再起動しないといけない事に気が付く(笑)

再起動後に再実行、、、

今度はTwitterToolsの設定画面が無事表示されました




Ubuntu 10.04 サーバ版(ディスクトップ版?)にVMwareサーバを入れる

前回(Ubuntu 10.04 サーバ版にDesktopのGUI環境を導入する)からの続きですが、、、

こっちもすったもんだあって導入に苦労しましたが
記事をきちんとまとめる時間がないので
覚書程度に、、、


無事?サーバ版にディスクトップ環境を導入した訳ですが
VMwareサーバの2.0.2バージョンを導入しようとすると
以下のエラーが、、、

make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-config3/vmmon-only'
Unable to build the vmmon module.

サーバ版にディスクトップ環境を入れた祟りかどうかは不明ですが、、、
検索していると英語の文献はいくつか発見
CurseとかOmenとかの記述はなかったので祟りではないかも???

どうやらパッチが出ているようなのでそれをソースにあててから
コンパイルをすればよいとのこと

まずはパッチを入手
wget -N http://risesecurity.org/~rcvalle/VMware-server-2.0.2-203138-update-2.patch

作業フォルダにてVMwaretar.gzを解凍して
tar -xzf VMware-server-2.0.2-203138.i386.tar.gz

パッチをあてるソースの場所へ移動して
cd vmware-server-distrib/lib/modules/source/

ソースの復元
tar -xf vmci.tar
tar -xf vmmon.tar
tar -xf vmnet.tar
tar -xf vsock.tar

解凍した直下のフォルダへ戻り
cd ../../../ (vmware-server-distrib/になります)

そしてパッチをあてる
patch -p1 < ../VMware-server-2.0.2-203138-update-2.patch

パッチをあてたソースの場所へ再び移動して
cd lib/modules/source/

再びアーカイブ
rm -f vmci.tar
rm -f vmmon.tar
rm -f vmnet.tar
rm -f vsock.tar
tar -cf vmci.tar vmci-only/
tar -cf vmmon.tar vmmon-only/
tar -cf vmnet.tar vmnet-only/
tar -cf vsock.tar vsock-only/

またまた解凍した直下のフォルダへ戻り
cd ../../../ (vmware-server-distrib/になります)

やっとのことでインストーラの起動
sudo ./vmware-install.pl


すると、、、

先程のエラーは解消されて無事にコンパイル出来ました


で、VMwareも無事に動作する事が出来ました
めでたし、めでたし、、、




次のページ

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。