2019年01月23日

muninで「[FATAL ERROR] Lock already exists: /var/run/munin/munin-graph.lock. Dying.」

新しいサーバを可動させたので、munin-node をインストールし、既存の munin サーバに監視対象として追加しましたが、グラフが更新されるタイミングで下記のようなエラーメールが root 宛に届いてしまいました。
[FATAL ERROR] Lock already exists: /var/run/munin/munin-graph.lock. Dying.
at /usr/share/perl5/vendor_perl/Munin/Master/GraphOld.pm line 406.


これは、グラフ更新用に munin を起動したが、すでに他の munin が起動していたため起動を取りやめたという意味ですので、まず最初にチェックするポイントとして、監視対象が多すぎて監視間隔(通常は5分)以内に終わらない状況になっていないか確認します。サーバを1台ずつ追加していても、ふと全体を見返すと意外に多くなっていることもあります。

次の対策としては、設定ファイルに「fork no」を追加します。
# vi /etc/munin/munin.conf
fork no


munin を再起動します。
# systemctl restart munin-node


posted by はるこち at 20:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年12月19日

Linuxで動作する既存のCプログラムソースをPHPのエクステンション化する

Linux(CentOS)上で動作するC言語で書かれた既存のプログラムソースがあるのですが、これをPHP7のエクステンションとして読み込めるようにしました。プログラムはコマンドラインで動作しテキスト処理を行うだけの単純なものです。

参考資料
PHP7 でのエクステンションの書き方を調べた - Qiita
PHP Extensionの開発@ - Qiita

1.PHP7ソースを入手
$ sudo yum install git
$ git clone git@github.com:php/php-src.git
$ cd php-src
$ git tag --list
:
php-7.1.24
:
$ php -v
PHP 7.1.24 (cli) (built: Nov 7 2018 18:45:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
$ git checkout php-7.1.24

自分の環境には git が入っていなかったので git のインストールから必要でした。
また、Permission Denied のエラーが表示されてしまったので、SSH Keyの登録を行いました。
自分の環境にインストールされているPHPのバージョンを確認したところ 7.1.24 だったので、git checkout でこのバージョンをダウンロードします。

2.エクステンションの雛形ファイルを作る
$ cd ext
$ ./ext_skel --extname=sampleext

sampleext というディレクトリが作成され、その中に必要なファイルが作られます。
まずは下記のコマンドを入力してエクステンションが作られるか確認します。
$ cd sampleext
$ vi config.m4
$ pipize
$ ./configure
$ make
$ php -d extension=./modules/sampleext.so sampleext.php
Congratulations! You have successfully modified ext/sampleext/config.m4. Module myext is now compiled into PHP.

config.m4 ファイルの下記の部分をアンコメントします。(dnl という文字を削除する)
PHP_ARG_WITH(myext, for myext support,
Make sure that the comment is aligned:
[ --with-myext Include myext support])

Conguratulations! 〜〜という表示が出れば成功です。

3.自分のプログラムのソースを準備する
既存プログラムはコマンドライン上で起動するものでしたが、シェアードライブラリとしてコンパイルすることでエクステンションから呼び出せるようだったので、コンパイルし直すことにしました。
$ mkdir myprg
$ cd myprg
※このフォルダ内にソースを準備する
$ vi Makefile
$ make

ソースファイルは php-src/ext/sanpleext/myprg/ の中に入れます。
シェアードライブラリとしてコンパイルするために Makefile の CFLAGS と CPPFLAGS に -shared -fPIC を追加します。
CFLAGS = -shared -fPIC -pipe -Wall -W -O2 -w
CXXFLAGS= -shared -fPIC -pipe -Wall -W -O2 -w

最終的にコンパイルされたライブラリは php-src/ext/sampleext/myprg/lib ディレクトリの中に libmyprg.so という名前で保存されるようにします。

4.PHPエクステンションにリンクする
既存プログラムのリンクは config.m4 を修正することで設定します。
$ cd ..
$ vi config.m4

config.m4 の修正点は以下のとおりです。
・if test "$PHP_SAMPLEEXT" != "no"; then の行から下の行のコメント(dnl)を解除
・SEARCH_PATH に ./myprg を追加
・PHP_ADD_INCLUDE(./myprg)
・LIBNAME=myprg
・LIBSYMBOL=myfunc

LIBNAME はリンクするシェアードライブラリの名前を指定します。上記のように書くと ./myprg/lib/libmyprg.so がリンクされます。
LIBSYMBOL はリンクするシェアードライブラリを取り違えていないか確認するためのもので、中に入っている関数名(シンボル)を指定することで、正しいライブラリであることが確認されます。

5.既存プログラムを呼び出す部分を修正する
PHP側とC言語側の間を取り持つのは sampleext.c になりますので、この中に作成していきます。
5-1.関数の宣言
下記の部分にPHPから呼び出すときの関数名を登録します。
const zend_function_entry sampleext_functions[] = {
PHP_FE(confirm_sampleext_compiled, NULL) /* For testing, remove later. */
PHP_FE(call_myfunc, NULL) /* added */
PHP_FE_END /* Must be the last line in sampleext_functions[] */
};

PHP_FE に指定する関数名は PHP 側で見えるものなので、C言語のプログラムソース内の関数と同じ名前でも大丈夫ですが、混乱を避けるために call_myfunc のように変えておくのが良いと思います。第2引数はとりえあずNULLでも動きますが、できれば指定したほうが良いようです(詳細は省略)。
5-2.関数本体の定義
PHP_FUNCTION(confirm_sampleext_compiled) が定義されていると思いますので、その下あたりに定義を追加します。
PHP_FUNCTION(call_myfunc)
{
zend_long a;
char *str;
size_t len;
int status;

ZEND_PARSE_PARAMETERS_START(2, 2)
Z_PARAM_LONG(a)
Z_PARAM_STRING(str, len)
ZEND_PARSE_PARAMETERS_END

/* 何らかの処理 */
status = myfunc(a, str);

RETURN_LONG(ret);
}

引数の受け取りについては他に詳しい記事がありますので参照していただくとして、上記の例では、引数2個、1個めは数値、2個めは文字列を受け取ります。
戻り値を返すには、RETURN_LONG を使うと数値、RETURN_STRING を使うと文字列を返せます。

6.動作確認
テスト用のPHPスクリプト(test_sampleext.php)を作成して走らせることで動作確認しました。
<?php
$r = call_myfunc(1, "abc");
echo "$r\n";

下記のようにして実行します。
$ php -d extension=./modules/sampleext.so test_sampleext.php


7.トライアンドエラー
2つの異なる世界のプログラムを連携させているので、一筋縄ではいかないと思います。実際、エラーメッセージとにらめっこしながら何度もコンパイルをやり直しました。
$ vi config.m4
$ phpize
$ ./configure
$ vi sampleext.c
$ make
$ php -d extension=./modules/sampleext.so test_sampleext.php


8.インストール
稼働中のPHPにインストールするには make install を使用します。
インストールされた sampleext.so を読み込むには /etc/php.ini を修正します。
sampleext.so が変更されたら apache を再起動する必要があります。
$ sudo make install
$ vi /etc/php.ini
extension=./modules/sampleext.so
$ sudo apachectl restart

posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年08月30日

OwnCloud開発環境構築はPHP7.0.xには対応していない

OwnCloudの開発環境を作るために Development Environment − ownCloud Developer Manual 10.0.9 documentation を参考にしながら進めていたのですが、ソースコードを git で取得したあと make しようとしたらエラーが発生してしまいました。どうやら PHP7.0 だとうまくいかないようで、PHP7.1 に入れ替えたらうまくいきました。

$ cd core
$ make
Building core

Note: You can type 'make help' for more targets

cd build && ./getcomposer.sh
php build/composer.phar install --dev
You are using the deprecated option "dev". Dev packages are installed by default now.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 122 installs, 0 updates, 0 removals
- Installing ocramius/package-versions (1.3.0): Downloading (100%)
PHP Fatal error: Uncaught TypeError: Return value of PackageVersions\Installer::activate() must be an instance of PackageVersions\void, none returned in /var/www/html/core/lib/composer/ocramius/package-versions/src/PackageVersions/Installer.php:62
Stack trace:
#0 phar:///var/www/html/core/build/composer.phar/src/Composer/Plugin/PluginManager.php(236): PackageVersions\Installer-&gt;activate(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#1 phar:///var/www/html/core/build/composer.phar/src/Composer/Plugin/PluginManager.php(205): Composer\Plugin\PluginManager-&gt;addPlugin(Object(PackageVersions\Installer))
#2 phar:///var/www/html/core/build/composer.phar/src/Composer/Installer/PluginInstaller.php(62): Composer\Plugin\PluginManager-&gt;registerPackage(Object(Composer\Package\CompletePackage), true)
#3 phar:///var/www/html/core/build/composer.phar/src/Composer/Installer/InstallationManager.php(173): Composer\Installer\PluginInstaller-&gt;install(Object(Composer\Repository\InstalledFilesystemRepository), Object(Composer\Package\Com in /var/www/html/core/lib/composer/ocramius/package-versions/src/PackageVersions/Installer.php on line 62

Fatal error: Uncaught TypeError: Return value of PackageVersions\Installer::activate() must be an instance of PackageVersions\void, none returned in /var/www/html/core/lib/composer/ocramius/package-versions/src/PackageVersions/Installer.php:62
Stack trace:
#0 phar:///var/www/html/core/build/composer.phar/src/Composer/Plugin/PluginManager.php(236): PackageVersions\Installer-&gt;activate(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#1 phar:///var/www/html/core/build/composer.phar/src/Composer/Plugin/PluginManager.php(205): Composer\Plugin\PluginManager-&gt;addPlugin(Object(PackageVersions\Installer))
#2 phar:///var/www/html/core/build/composer.phar/src/Composer/Installer/PluginInstaller.php(62): Composer\Plugin\PluginManager-&gt;registerPackage(Object(Composer\Package\CompletePackage), true)
#3 phar:///var/www/html/core/build/composer.phar/src/Composer/Installer/InstallationManager.php(173): Composer\Installer\PluginInstaller-&gt;install(Object(Composer\Repository\InstalledFilesystemRepository), Object(Composer\Package\Com in /var/www/html/core/lib/composer/ocramius/package-versions/src/PackageVersions/Installer.php on line 62
make: *** [lib/composer/phpunit] エラー 255


PHP のバージョンを確認。
$ php -v
PHP 7.0.31 (cli) (built: Jul 17 2018 15:30:29) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies


このサイト(Error when using Composer 1.6.4 with PHP 7.0 ・ Issue #64 ・ Ocramius/PackageVersions ・ GitHub)によると、Composer が PHP7.0 のときうまくないらしいことがわかりましたが、対応策がよくわからなかったので、PHPを7.1に入れ替えました。
# yum remove --enablerepo=remi-php70 php php-devel php-mbstring php-pdo php-gd php-mysqlnd php-xml php-zip php-intl php-process
# sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
http://rpms.famillecollet.com/enterprise/remi-release-7.rpm を取得中
準備しています... ################################# [100%]
パッケージ remi-release-7.5-2.el7.remi.noarch は既にインストールされています。
# yum install --enablerepo=remi-php71 php php-devel php-mbstring p
hp-pdo php-gd php-mysqlnd php-xml php-zip php-intl php-process
posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年07月26日

Google Cloud SDK を使って Amazon S3 にファイルをコピーしてみる

Google Cloud Storage (GCS) にファイルを出し入れするには Google Cloud SDK をインストールして gsutil というツールを使いますが、AWS のクレデンシャル情報(認証情報)を設定してやれば、そのまま S3 にもアクセスできることがわかりました。Google Cloud SDK を Windows にインストールするには下記のようにして行います。

まずは gsutil をインストールする  |  Cloud Storage ドキュメント  |  Google Cloud にアクセスし、Windows版のCloud SDKのインストーラをダウンロードします。

インストーラを起動しインストールします。途中で選択肢が表示される箇所もありますが、デフォルトのまま進めても大丈夫です。
20180726-googlecloudsdk-001.png

インストーラの最後の画面で Launch が選択されていると Cloud SDK Shell が表示されます。
また、デフォルトの状態だと初期設定(gcloud init)が実行されます。
20180726-googlecloudsdk-002.png

英語でずらずらとメッセージが表示されますが、下記の質問には Y と答えます。
You must log in to continue. Would you like to log in (Y/n)?


そうするとブラウザのウインドウが勝手に開いてログイン画面が表示されますので、使用したいアカウントでログインします。次にプロジェクトの選択が表示されますので、数字を入力します。
Pick cloud project to use:
[1] gcp-small
[2] Create a new project
Please enter numeric choice or text value (must exactry match list item):


またさらに英語のメッセージがたくさん表示されますが、終了したら gsutil が使えるようになっています。試しに GCS に作成済みのバケット一覧を表示してみます。
gsutil ls
gsutil cp C:\Users\(ユーザー名)\Downloads\test_20180724.zip gs://gcp_bucket_name/


次に AWS S3 にアクセスできるよう設定します。まずは Amazon のクレデンシャル情報(認証情報)が必要ですので、Amazonにログインします。自分のアカウントメニューの中の「セキュリティ認証情報」を選択します。
20180726-s3-001.png

「アクセスキー(アクセスキーIDとシークレットアクセスキー)」をクリックして開き、新しいアクセスキーの作成をクリックします。新しいアクセスキーが作成され、ダウンロード可能な状態になるのでダウンロードします。
20180726-s3-002.png

ダウンロードしたファイルは rootkey.csv というファイル名になっていますが、中身は普通のテキストファイルになっていて下記の2行が記載されています。
AWSAccessKeyID=XXXXXXXXXXXXXXX
AWSSecretKey=YYYYYYYYYYYYYYYYYY


次に手元のPCの .boto というファイルを開きます。パスは C:\Users\(ユーザー名)\.boto になります。この中のS3に接続するためのクレデンシャル情報を設定する行を修正します。アクセスキーとシークレットアクセスキーに対応する情報を貼り付けます。
aws_access_key_id = XXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYY


これで AWS S3 にアクセスできるようになったので表示してみます。
gsutil ls s3://
gsutil cp C:\Users\(ユーザー名)\Downloads\test_20180724.zip s3://s3_bucket_name/


GCS から S3 に直接(手元のPCにダウンロードすることなく)ファイルをコピーすることもできるようです。
gsutil cp gs://gcs_bucket_name/file_name s3://s3_bucket_name/file_name

posted by はるこち at 18:21| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年07月20日

ESXi仮想サーバにNICを2個設定したら外から通信できなくなったとき

ESXiに仮想サーバを作ってNICを2個設定し、片方はグローバル、もう片方はプライベートLANに接続するように設定しました。(いわゆる2本足構成)

OSとしてはCentOS7をインストールし、それぞれのNICにIPアドレスを設定して、プライベートLAN上のPCからはどちらのNICに対しても通信できていたのですが、外からアクセスしようとしたらできない状態になってしまっていました。

しばらく調べてわかったことは、両方のNICにデフォルトルートが設定されていて、しかもプライベートLAN側が優先されていた(metricの数値が小さい)ことがわかりました。
# ip route
default via 172.xx.xx.xx dev eno16780032 proto static metric 100
default via 202.yy.yy.yy dev eno33559296 proto static metric 101
172.xx.0.0/16 dev eno16780032 proto kernel scope link src 172.xx.xx.xx metric 100
202.yy.yy.0/26 dev eno33559296 proto kernel scope link src 202.yy.yy.yy metric 101


デフォルトルートが172で始まるネットワーク(プライベートLAN)に流されるようになっていたので、PCからはグローバルアドレスに対するアクセスが、プライベートLANの方から帰ってくる状態になっていたようです。この状態では外から(グローバルアドレスから)アクセスすると、返答がプライベートLANに流されてしまい、受け取れなくなってしまうようです。

まずは nmtui でプライベートLAN側がデフォルトゲートウェイにならないように設定しました。
nmtui.png
ゲートウェイの欄を空欄にして、「このネットワークはデフォルトのルートには使用しない」にチェックマーク(X)を入れました。

これで保存してネットワークを再起動すると、デフォルトルートがグローバル側の1個になり、外からも無事にアクセスできるようになりました。
# systemctl network restart

posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年07月19日

さくらレンタルサーバの乗り換えを行いました

さくらインターネットのレンタルサーバ(スタンダード)で運用しているサーバがあるのですが、先日、WordPressがちょっと早くなるサーバへの乗り換えキャンペーンのメールが届きました。PHP7のモジュールモードを使用することでWordPressのレスポンスが改善されるとのことです。
現在使っているサーバは、夜10時前後の時間帯になると重くなりWordPressの管理画面の接続が切れてしまったりするので、多少でも速くなればと思って乗り換えを行うことにしました。

乗り換えのおおまかな手順は下記のとおりです。(スタンダード版からスタンダード版への乗り換えです)

旧サーバにSSHログインし、www フォルダ以下をアーカイブする。
tar zcf ./www.tgz ./www


www.tgz ファイルを新サーバに転送する。転送方法はいろいろありますが、サーバ間で直接転送してみました。転送先サーバのパスワードが求められるので入力するとコピーが行われます。
scp www.tgz ユーザー名@新サーバ.sakura.ne.jp:www.tgz


新サーバで展開します。
tar zxf ./www.tgz


旧サーバのコントロールパネルでドメイン名を解除します。
・SSLを解除
・ドメインを解除
※ドメインを解除した後は2時間は再設定ができないそうですので、待ちます。

新サーバのコントロールパネルでドメイン名を設定します。
・ドメイン名を設定
・SSLを設定
※ドメイン名を設定したあとDNSに反映されるのに30分〜1時間かかるとのことですので、SSLを設定するのは少し待ってからにします。
ドメイン名に設定してあるDNSサーバ情報は変更しなくても大丈夫です。

静的なホームページの場合はここまでの手順で引っ越しが完了すると思いますが、WordPressやPHPスクリプトを駆使しているサイトの場合はもうちょっと作業が必要になります。

まずはWordPressのデータベースを移行します。
旧サーバのデータベース管理画面(PHPMyAdmin)に接続し、データベースをエクスポートします。エクスポートファイルはパソコンにダウンロードされます。

新サーバのコントロールパネルで新しいデータベースを作成します。DBサーバのホスト名が新しいものになるので、mysqlxxx.db.sakura.ne.jp のホスト名をメモしておきます。また、新サーバになるときユーザー名が変わっているはずですので、データベース名の前半部分が変わります。
新サーバのデータベース管理画面(PHPMyAdmin)に接続し、データベースをインポートします。パソコンにダウンロードしたエクスポートファイルを指定しアップロードします。

WordPressの設定ファイルを編集します。
vi wp-config.php

define('DB_NAME', 'username_wpblog'); ←上記で作成したDB名を指定します
define('DB_USER', 'username'); ←新サーバでのユーザー名に変更します
define('DB_PASSWORD', 'パスワード'); ←パスワードはDBを作成したときに指定したものを入力します
define('DB_HOST', 'mysqlxxx.db.sakura.ne.jp'); ←上記でメモしたホスト名を入力します

今回の乗り換えで PHP5 → PHP7 に変わったため、いくつか影響が出ている箇所がありました。

プラグイン qtranslator-X
関数呼び出しで参照渡しをしている箇所があるのですが、& 記号を指定する必要がなくなったため & 記号を削除する必要があります。
qtranslate-frontend.php の 523行目と597行目

split() が使えない
Fatal error: Uncaught Error: Call to undefined function split()
昔自作したソースコードの中にあった split() がついにエラーになりました。explode() に置き換えます。

以上のような箇所を修正することで、WordPressサイトが動き始めました。それほど混む時間帯でなくてもレスポンスが向上していることが実感でき、ちょっとだけ嬉しくなりました。

夜10時頃に記事の更新をしてみたところ問題なく更新ができ、サムネイルの生成も以前よりずっと短時間で終わるようになりました。サイトのメンテナンスを頑張らなければ。。
posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

読めないエラー:\xe3\x83\x87\xe3\x83\xbc\xe3\x82\xbf\xe3\x83\x99\xe3\x83\xbc\xe3\x82\xb9\xe3\x82\xa8\xe3\x83\xa9\xe3\x83\xbc

error_log などに日本語が出力されると文字化けして読めない状態になってしまうのですが、トラブっているときなど、どうにかして読みたいことも多いです。例えば下記のようなメッセージが出力されていたとします。
\xe3\x83\x87\xe3\x83\xbc\xe3\x82\xbf\xe3\x83\x99\xe3\x83\xbc\xe3\x82\xb9\xe3\x82\xa8\xe3\x83\xa9\xe3\x83\xbc


文字化けを解読するサイトがいくつかあるので、入力して解析してみようと思っても、なかなか日本語が出てきませんが、以下のようにすると日本語を取り出すことができます。

1.「\x」を「%」に置換する
vim なら :%s/\\x/%/g とします。

2.URLデコードします
下記のサイトなどでできます。
Web便利ツール/URLエンコード・デコードフォーム/処理完了 - TAG index

3.得られた日本語は
「データベースエラー」

日本語が得られましたが、おおざっぱすぎてよくわかりません(;´Д`)
とりあえずこれを手がかりに調べてみることにします。
posted by はるこち at 00:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年04月02日

WWWサーバにアクセスするとパーミッションに関するエラー

CentOS7のサーバで、これまでWWWサーバ(httpd)を動かしていなかったのですが、httpd を起動してブラウザからアクセスしたらパーミッション関係のエラーが表示されてしまいました。

httpdの起動は下記のように行いました。特に設定は変更していませんが、エラーが表示されなかったので起動したと判断しました。
sudo systemctl start httpd


ブラウザから http://xx.xx.xx.xx/es/ などにアクセスすると error_log にパーミッションのエラーが記録されていました。
[Mon Apr 02 11:49:18.729539 2018] [core:error] [pid 26369] (13)Permission denied: [client x.x.x.x:49677] AH00035: access to /es/index.php denied (filesystem path '/var/www/html/es/index.php') because search permissions are missing on a component of the path

ファイルを指定せずにディレクトリを指定すると下記のようなメッセージになりました。
[Mon Apr 02 11:52:55.548063 2018] [autoindex:error] [pid 26368] (13)Permission denied: [client x.x.x.x:50337] AH01275: Can't open directory for index: /var/www/html/es/


これは SELinux の制限がかかっているためで、SELinux の制限を解除すればエラーはなくなります。

SELinux の状態を確認してみます。
getenforce
Enforcing


SELinux が有効になっているようです。SELinux を一時的に解除するには下記のコマンドを実行します。
sudo setenforce 0


SELinux の状態を確認してみます。
getenforce
Permissive


SELinux の状態を永続化するには /etc/selinux/config を編集し enforcing を disabled に変更します。
SELINUX=disabled

ファイルを変更した場合は、システムを再起動すると反映されます。
posted by はるこち at 12:05| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2018年03月06日

docker-compose up -d workspace で大量の warning

CentOS7 上で Laradock をインストールしてみようとしてウェブ上の記事を参考にしながら進めていたのですが、docker-compose up -d workspace を実行したところで大量の warning メッセージが表示されてしまいました。
$ docker-compose up -d workspace
WARNING: The PMA_USER variable is not set. Defaulting to a blank string.
WARNING: The PMA_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The PMA_ROOT_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: The PMA_DB_ENGINE variable is not set. Defaulting to a blank string.
WARNING: The PMA_PORT variable is not set. Defaulting to a blank string.
WARNING: The RETHINKDB_PORT variable is not set. Defaulting to a blank string.
WARNING: The DATA_SAVE_PATH variable is not set. Defaulting to a blank string.
WARNING: The DOCKER_HOST_IP variable is not set. Defaulting to a blank string.
WARNING: The PHP_IDE_CONFIG variable is not set. Defaulting to a blank string.
(以下略)


環境変数が設定されていないのが原因であり、下記のように対応します。
$ cp env-example .env

posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

Laradock で環境を作ったのに Nginx が 404 Not Found を返してしまう

Laravel の環境を作るために Laradock を始めて使ったのですが、何度インストールをやり直しても Nginx が 404 Not Found を返してしまうという問題にハマりました。
20180306-nginx-notfound.png

いろいろ調べても原因がわからないまま数時間がすぎましたが、Nginx のコンテナに入って Nginx の設定を確認したところ、root の参照先ディレクトリが想定と異なっていることに気が付きました。というか、基本設定が重複して読み込まれているようです。
nginx -T

具体的には、/etc/nginx/conf.d/laravel.conf と、/etc/nginx/sites-available/default.conf の両方が読み込まれており、後で読み込まれた default.conf のほうが優先されているように見えました。
sites-available の中のファイルは読み込まれないと思っていたのですが、拡張子が *.conf になっていると読み込まれてしまうようだったので、default.conf.example にリネームしました。
リネームしてから、下記のコマンドを実行して設定ファイルを読み込み直したところ、Laravel の初期ページが表示されました。
nginx -s reload


20180306-nginx-laravel.png
posted by はるこち at 18:51| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年11月16日

WordPressのバックアップをDropboxに保存する

WordPress のデータをバックアップするのに BackWPup を使っている人は多いと思いますが、バックアップファイルの保存先として Dropbox を指定してみましたので紹介します。

BackWPup – WordPress Backup Plugin − WordPress プラグイン

Dropbox へのアクセス権限として、全フォルダにアクセスできるモードで連携する権限と、「アプリ」フォルダに限定して連携する権限のどちらかを選べるようです。今回は、バックアップにしか使用しませんので、「アプリ」フォルダに限定した権限で設定したいと思います。

まず BackWPup のジョブを編集で開き、バックファイルの保存方法として「Dropbox にバックアップ」にチェックを入れます。
20171116-backwpup-001.png

設定を保存すると、上部に「宛先: Dropbox」というタブが増えていますので、これをクリックします。
20171116-backwpup-002.png

最初は「認証されていません!」と赤字で表示されるのでギョッとするかもしれませんが、そこは無視して「Dropboxのアプリ認証コードを取得」というボタンをクリックします。テキストボックスは空欄でかまいません。
20171116-backwpup-003.png

すると新しいブラウザタブが表示されて、Dropboxとの連携画面になります。Dropboxにログインしていない場合はここでログインしてください。ログインが完了すると下の図のような表示になりますので、「許可」をクリックします。
20171116-backwpup-004.png

「許可」をクリックすると認証コードが表示されます(下の図でグレーになっている部分)。この認証コードをコピーします。
20171116-backwpup-005.png

ブラウザタブを閉じるなどして BackWPup 画面に戻り、Dropbox アプリへのアクセスのテキストボックスに認証コードをペーストします。
20171116-backwpup-006.png

そうしたら画面を下にスクロールして、「変更を保存」ボタンをクリックします。処理が完了すると緑の文字で「認証済み!」と表示されます。これで Dropbox が使えるようになりました。
20171116-backwpup-007.png

次にバックアップファイルを Dropbox に転送する設定を行います。

保存先フォルダー:/home/アプリ の中にこの名前でフォルダーを作成してバックアップが保存されます。自分でわかりやすい名前をつけることができます。

ファイルを削除:バックアップファイルを保持する個数を指定します。デフォルトは15ですが、実際にはもっと少なくてもよいのではないかと思います。自分の場合は、アップロード画像が多くバックアップファイルのサイズが大きくなってしまったので 3 に設定しました。

設定を保存したら試しに実行してみます。ジョブ一覧の画面で「いますぐ実行」をクリックするとバックアップが始まります。しばらく見ていると Dropbox に転送する様子もわかります。
20171116-backwpup-009.png

処理が終わったら、バックアップファイルが Dropbox に登録されているか確認してみます。ブラウザで Dropbox にアクセスした場合、ファイル容量が表示されていませんが「…」メニューの中にある「バージョン履歴」をクリックすると、ファイルサイズを表示することができます。
20171116-backwpup-010.png

文字が重なっていてよく読めないのでクリックしてみます。
20171116-backwpup-011.png

287.44MBであることがわかりました。思ったよりサイズが大きいので、バックアップファイルを保持する個数を3個に減らすことにしました。
posted by はるこち at 19:00| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年08月25日

WordPress の コマンドラインツール WP-CLI のインストール

WordPress をコマンドラインからアレコレできるという、WP-CLI というものがあるということなので、インストールしてみました。インストールはとても簡単ですが、下記のような感じです。

1.ダウンロード
$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4191k 100 4191k 0 0 3519k 0 0:00:01 0:00:01 --:--:-- 3522k


2.確認
$ php wp-cli.phar --info
PHP binary: /usr/bin/php
PHP version: 5.4.16
php.ini used: /etc/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/takesita_haruhiko
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 1.3.0


3.インストール
$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /usr/local/bin/wp


これでインストールは完了です。
ちゃんと動くか試してみます。

4.起動確認
$ wp cli version
WP-CLI 1.3.0


問題ないようです。
posted by はるこち at 14:44| Comment(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年07月04日

GCPのf1-microインスタンスが頻繁にフリーズした話

f1-micro インスタンスを us-central に作れば無料で使えるというプランを利用して、CentOS7 の上に WordPress をインストールしてみました。

インストールもスムーズに終わり無事稼働したように見えたのですが、なんか不定期にフリーズしているっぽい。記事の編集をしている最中に帰ってこなくなることがあり、コンソールから %CPU のグラフを見てみると、誰も使っていない夜中にフリーズしたりしているようです。

20170704-gcp-wordpress.png

共有CPUだから誰か他の人がCPUをブン回していてその影響を受けているのかなとか思いましたが、どうやらそうではなかったみたいです(自分がブン回している側だった)。

アレコレ調べてみたんですが、決定打になったのはシリアルコンソールでした。グラフの下の方を見ていくと、Serial Console (port 1) というリンクがありますのでクリックします。
20170704-serial-console.png

いきなり沢山のログが表示されましたが、どうやらフリーズするたびにリセットしていたのでその起動時のログが沢山たまっているらしい。そうすると、再起動する直前に何か情報があるかもしれないと思い、見てみたらありました。

[22264.746837] Out of memory: Kill process 2252 (yum-cron) score 170 or sacrifice child


どうやら、yum-cron に関係するプロセスがメモリ不足を起こしているようです。おそらくデフォルトで定時実行が設定されており、そのために知らないタイミングでフリーズしていたようです。

yumの自動更新を停止するために、以下のコマンドを実行しました。

$ sudo systemctl list-unit-files -t service
(稼働中のサービス一覧を表示)

yum-cron.service enabled
(yum-cronが有効になっている)

$ sudo systemctl disable yum-cron
(yum-cronがサービスとして起動するのを解除)

$ sudo systemctl stop yum-cron
(現在起動中のyum-cronを停止)
posted by はるこち at 18:24| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年03月29日

Google Cloud Platform(GCP)からメールを送ってみる(1)

Google Cloud Platform(GCP)からEメールを送信したいと思っていろいろ設定したんですが、ようやく思った通りに動き始めたので備忘録を兼ねてまとめてみます。

まず、なぜGCPかというと、2017/3/16より特定の範囲内に収まれば無料というものが始まったからです。
Google Cloud、マイクロインスタンスを無料に。App Engineは1日28時間、Cloud Storageは月5GB、Cloud Functionsは月200万回など、無料枠を拡大 − Publickey
・f1-micro インスタンス(USリージョン)
・30GBのHDDと5GBのスナップショット
・北米から1GBの月間ネットワーク(中国およびオーストラリアを除く)
ちなみに f1-micro インスタンスは下記の通り。
・vcpu:0.2(バースト機能有効)
・メモリ:0.6GB
・利用料金:$0.008(1時間あたり)

上記のサーバを使用して、1日1回Eメールを送信するスクリプトを走らせたいと思います。
メールの送信先は Evernote です。愛用している iOS アプリの「100年日記」(100YearDiary)が日記をノートとして Evernote に同期できるようになっており、特定の時刻にノートを作成したいと思ったからです。
100年日記 - エバーノートと同期できるダイアリーを App Store で

GCP に無料枠で登録する方法については、下記のサイト様をはじめとして多くのサイトで紹介されていると思いますので、参照していただければと思います。
いつでも無料!Google Compute Engine 常時無料枠の使い方 | あぱーブログ

まずは既存の Google アカウントを使用して Google Cloud Platform にログインします。Google アカウントを持っていない人は適当に作ってください。
Google Cloud Platform

「無料トライアルを開始」をクリックします。利用規約と同時に、国を選ぶ画面が表示されます。USリージョンを使うからと思って「アメリカ合衆国」を選んでしまったのですが、「日本」でも問題はないみたいです。
gcp-new-000.png

Google アカウントのログインとパスワードが再度求められますので入力します。
支払情報(クレジットカード情報)の登録を行います。「お金を払うつもりはないのに…」と心配になりますが、クレジットカードを登録しても予告なく請求されることはないそうなので、渋々登録します。
自分が入力したときは、「都道府県」と「郵便番号」の欄が何を入力してもエラーになってしまったのですが、エラーメッセージを見ると米国の州と郵便番号になっているかチェックしているようだったので、強引ですが「NewYork」「10992」と入力して次へ進みました。

登録が完了したら、まずはプロジェクトを作成します。以前、GAEか何かを試したときに作成したプロジェクトが残っていましたが、GCP用に新しいプロジェクトを作成します。名前はなんでも良いと思いますが、とりあえず「gcp-small」としました。
gcp-new-001.png

コンソール画面が表示されたら、画面左上のハンバーガーメニュー(三本線のアイコン)をクリックし、「Compute Engine」を選択します。
インスタンスを作成します。
名前は適当に入力します。
ゾーンは us- で始まるものを選択します。
CPUは micro を選択します。
gcp-new-002.png

ブートディスクの[変更]をクリックし、ディスクを設定します。
OSは自分が必要なものを選択します。
ディスクサイズは、せっかくなので無料枠いっぱいの30GBにします。
gcp-new-003.png

Webサーバにする場合は、HTTPトラフィックを許可します。
gcp-new-004.png

これで「作成」をクリックするとサーバが作成されます。Linuxサーバの場合、ログインするにはインスタンス一覧に表示される [SSH] というボタンをクリックすると、ブラウザからSSHログインできるようになります。

私は Windows で TeraTerm を使用していますので、下記の記事を参考にSSH鍵を作成し、TeraTermからログインできるようにしました。
めもちょー Tera TermでGCPにssh接続する プロジェクト共通sshキー

次の記事では、サーバからEメールを送信する方法について紹介したいと思います。
posted by はるこち at 18:01| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年03月28日

RabbitMQのエラー「Authentication failed」エラー

Windows7 に RabbitMQ をインストールしていたのですが、アンインストールして再度インストールしたら、不思議なエラーに悩まされてしまいました。

コマンドプロンプトから rabbitmqctl.bat コマンドであれこれ実行しようとしてみましたが、下記のようなエラーが表示されてしまいます。

rabbit@machine:
* connected to epmd (port 4369) on machine
* epmd reports node 'rabbit' running on port 25672
* TCP connection succeeded but Erlang distribution failed

* Authentication failed (rejected by the remote node), please check the Erlang
cookie


ネットで検索したところ、2個の .erlang.cookie ファイルの中身が異なっているとエラーになることがわかりました。

C:\Users\[username]\.erlang.cookie
GXKMCOHWNKVKXGURYAMQ

C:\Windows\.erlang.cookie
STRYCEXENXZQKADISVLM

上記の2個のファイルの内容が確かに異なっていましたので、C:\Windowsの方のファイルをコピーして、C:\Users\[username] に上書きコピーしたところエラーは解消しました。
posted by はるこち at 17:52| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2017年02月15日

pgAdmin4 でサーバに接続しようとしたら unrecognized configuration parameter "bytea_output" というエラー

pgAdmin4 を使って PostgreSQL サーバに接続しようとして、ホスト名、IP、ユーザー名、パスワードを入力して Save ボタンをクリックしたらエラーが表示されてしまいました。

bytea_output.png


Error saving properties: UNAUTHORIZED
Unable to connect to server:
ERROR: unrecognized configuration parameter "bytea_output"


エラーメッセージの意味はよく分かりませんでしたが、調べてみたら、「pgAdmin4 は、PostgreSQL 9.0 以前には接続できない」のだそうです。バージョンが合わないから表示されていたエラーのようです。

このようなときは、pgAdminIII をダウンロードして使用します。
https://www.pgadmin.org/download/
posted by はるこち at 16:58| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2016年10月25日

Cannot retrieve repository metadata (repomd.xml) for repository: rpmforge

以前インストールした CentOS5.2 ですが、サポートが終了してからだいぶたちますので、セキュリティのために入替えを計画しています。
yum を実行したところ、以前対応したのと同じエラーメッセージが表示されました。
Loading "priorities" plugin
Could not retrieve mirrorlist http://apt.sw.be/redhat/el5/en/mirrors-rpmforge error was
[Errno 14] HTTP Error 404: Not Found
Error: Cannot retrieve repository metadata (repomd.xml) for repository: rpmforge. Please verify its path and try again

前回は自分のサーバ側の設定ミスだったのですが、今回は違うようです。

調べてみたところ、rpm-forge のサイトが2016年7月以降停止しているということのようです。対処方法としては、rpm-forge の設定を enabled=0 にします。

# sudo vi /etc/yum.respos.d/rpmforege.repo
# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag
# URL: http://rpmforge.net/
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 0 ←ここが1になっているのを0にします
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1


これでyumが動くようになりました。早いところ新しいOSに乗り換えなければ。
posted by はるこち at 11:48| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2016年09月15日

VirtualBox にインストールした CentOS7 のネットワークを有効にする

これまで CentOS6 ばかり使っていたのですが、ついに CentOS7 を使う機会がやってきたので、VirtualBox の仮想マシンとして CentOS7 をインストールしました。

VirtualBox 側でブリッジネットワークの設定にして、CentOS7 のインストールが完了したところでコンソールからログインしてみましたが、どうもネットワークが繋がっていないみたい?

あれこれ調べてみたのですが、どうやら nmtui コマンドを使ってインタフェースを有効(active)にしてやらないといけないみたいです。

virtualbox-centos7-nmtui.png

nmtui コマンドで Active を実行したところ、メインとなる enp0s3 というインタフェースに * 印が表示されました。これで普通にネットワークが使えるようになりましたが、ファイアウォール等の設定がまだできていないので、そのあたりの設定も急がないといけませんね。
posted by はるこち at 14:21| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2016年09月14日

CentOS6 の 32bit 環境では centos-release-scl がインストールできないため Let'sEncrypt が使えなかった

Let's Encrypt を使うとSSLサーバ証明書が無料で手に入るよ!という話を聞いたので、VMWareの仮想環境で動いているサーバに入れてみようと思いましたが、CentOSの32bit環境では実現できませんでしたので顛末を紹介します。
Let's Encrypt については色々な方が記事にしてくださっていますので、それらのページを参考にしてください。

Let's Encrypt 総合ポータル

Let's Encrypt で手軽に HTTPS サーバを設定する - Qiita

Let's Encryptの証明書をnginxに設定してhttps化した | tsuchikazu blog

さて、Let's Encrypt のSSL証明書の取得は Let's Encrypt の使い方 - Let's Encrypt 総合ポータル に書かれている手順で行うのですが、CentOS6を使っている場合は64bit版でもエラーが表示されるので別ページにまとめられている手順を行います。

CentOS 6 で発生するエラーの対処法 - Let's Encrypt 総合ポータル

./certbot-auto を実行したところ手順どおりに「./certbot-auto: line 530: virtualenv: コマンドが見つかりません」というエラーメッセージが表示されたので、順調、順調、と思いながら次の手順に進みました。

ですが、「yum install centos-release-scl」が何度やっても失敗してしまいます。

# yum install centos-release-scl
読み込んだプラグイン:fastestmirror, refresh-packagekit, security
インストール処理の設定をしています
Loading mirror speeds from cached hostfile
* base: ftp.riken.jp
* extras: ftp.riken.jp
* updates: ftp.riken.jp
パッケージ centos-release-scl は利用できません。
エラー: 何もしません


そこで、新しい仮想マシンを CentOS6 64bit版で作成し、上記と同じ手順を行ったところ、問題なくインストールできました。

CentOS6 32bit版のリポジトリに見つからないので、どこか他のリポジトリに登録されているかもしれないのですが、そのあたりについてはわからないので環境依存ということで諦めることにしました。
posted by はるこち at 11:27| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

2016年09月02日

PHPでWebSocketを体験する

WebSocketを使用したクライアントモジュールを開発する必要が出てきたので、WebSocketがどんなものかを体験するということで、下記のサイトを参考にWebSocketを試せる環境を作りました。

PHPのみでHTML5のWebSocketを体験する方法 - [Swb:]渋谷に住むWEBデザイナの備忘録

この記事のとおりにファイルをダウンロードしてサーバにアップロードすることで、WebSocketを使ったチャットルームが簡単に動作しました。ありがとうございました。

さて次のステップに進むためにクライアント側を自分で作成してみたのですが、どういうわけかサーバに接続できません。サーバで動いているPHPスクリプトからエラーが出力されています。※ダウンロードした状態では @socket_read() という感じに警告表示が抑止されているので @ を削除すると表示されます。

最初のエラー
PHP Warning: socket_read(): unable to read from socket [104]: Connection reset by peer


次のエラー
PHP Warning: socket_getpeername(): unable to retrieve peer name [107]: Transport endpoint is not connected


ダウンロードした client.php では問題なく接続できるので、自分で作成したクライアントモジュールに問題があるのかもしれませんが、どんなに調べても原因がわかりません。

クライアント側のエラー
Handshake Error: Invalid Accept Key


WebSocketで接続したときに行われるハンドシェイクで問題が起きているようです。とは言ってもよくわからないので、やりとりされる内容をパケットキャプチャで調べてみることにしました。すると。。。

サイトからダウンロードした server.php がハンドシェイクするときに Sec-WebSocket-Accept を返すのですが、その行の区切り文字のコロンの後ろに半角スペースが入っていないために、クライアント側で取り込めていないことがわかりました。

修正前: "Sec-WebSocket-Accept:$secAccept\r\n\r\n";
修正後: "Sec-WebSocket-Accept: $secAccept\r\n\r\n";

違いがわかりにくいかもしれませんが、$secAccept の前に半角スペースを追加しています。

これで無事WebSocketの通信が行えるようになりました。

ちなみにチャットルームのサンプルプログラムのダウンロード元は
http://www.sanwebe.com/downloads/50-websocket-example
です。
posted by はるこち at 12:07| Comment(0) | TrackBack(0) | サーバ関連 | このブログの読者になる | 更新情報をチェックする

×

この広告は180日以上新しい記事の投稿がないブログに表示されております。