:::: MENU ::::
Posts tagged with: CentOS

PHP5.6のgd-lastがyum更新で失敗する

CentOS/sl6のyumにて、いつも通り更新を行ってましたが、gd-lastで引っかかってました。

エラー: パッケージ: gd-last-2.2.5-1.el6.remi.x86_64 (remi)
要求: libwebp.so.5()(64bit)

libwebpを要求しているようなので、epelからlibwebpをインストールするだけで解決

epelがまだインストールされていない方は、
# yum -y install epel-release
# yum update
libwebpをインストール
# yum -y install libwebp --enablerepo=epel

gd-lastをインストール
# yum -y install gd-last --enablerepo=remi


今更ながらSubsonicをSSLでサブドメインにて運用

このサイトでも幾度か、Subsonicの記事を投稿しておりますが、今更ながら、SSL証明書によるHTTPS化して、ついでにサブドメインにてアクセスするように設定した。

環境

  • CentOS 6.x
  • Nginx 1.10.x (ssl設定済み)
  • Subsonic 6.0
  • DNS管理はCloudFlare
  • SSL証明書はLet’sEncyptにて取得

現状は、CentOS上にSubsonicを運用しており、http://localhost:4040にて稼働しております。

今回作業する項目

CloudFlareにてサブドメインを設定し、nginxでサブドメイン用confファイル作成、SSL証明書発行後、confファイルに適用と言う流れになります。

サブドメイン設定

私は、DNS管理をCloudFlareに任せていますので、CloudFlareにログインします。

https://www.cloudflare.com/a/login

上記項目のDNS設定をクリックし、下記の囲んだ部分にサブドメインを記入して、追加します。

  • 左のレコードタイプをA
  • 次にサブドメイン名(今回はsubsonic)
  • サブドメインのIPアドレス (通常、subsonicを動作させているIP)
  • TTLは通常Automaticですが、早く反映させたいので、2min
    DNS反映後は、Automaticに戻しましょう
  • CloudFlareを通さない設定にしておかないと、この後の証明書発行ができませんので、雲マークがオレンジではなくグレイになるようにクリックしておきます

DNS反映には、しばらく時間がかかるので、コーヒーを飲んだり出かけたりすると良いかもしれません
一応、確認としては、CloudFlare上で設定が反映されていれば、
$ dig @ns6.cloudflare.com subsonic.xxx.xxx にて、設定したIPアドレスが表示されればOK
そして、サブドメイン(subsonic)上の端末から、
$ dig subsonic.xxx.xxx にて設定したIPアドレスが表示されれば、次に進めます

NginxのSubsonicサブドメイン用設定ファイル作成

設定ファイルは、/etc/nginx/sites-available/内にsubsonic.confと言う名前(任意でも)で作成します。

# cat subsonic.conf

server {
 listen 80;
 server_name subsonic.xxx.xxx;
 access_log /var/log/nginx/subsonic-access.log;
 error_log /var/log/nginx/subsonic-error.log;

location / {
 proxy_pass http://127.0.0.1:4040;
proxy_redirect http:// https://;
 }

保存後に、sites-enabled内にシムリンクを張ります

# ln -s /etc/nginx/sites-available/subsonic.conf /etc/nginx/sites-enabled/

書式に間違いないか確認

# service nginx configtest

エラー表示がなく、Syntax OKが表示されれば、適用します

# service nginx reload

これで問題がなければ、サブドメインのURLでアクセスすると、Subsonicの画面が表示されるはずです。

SSL証明書取得・設定

ここでは、無料のSSL証明書(Let’sEncypt)をサブドメインに適用します

Let’sEncryptをインストール

すでに、Let’sEncryptのプログラムは導入済みなのですが、初めての方は下記でインストールします。

# git clone https://github.com/letsencrypt/letsencrypt <directory>
# cd <directory>

サブドメイン用の証明書取得

# ./letsencrypt-auto —nginx
(初めて起動の方は、ここで、いろいろなプログラムがインストールされます)

1. aaa.xxx.xxx
2. bbb.xxx.xxx
3. subsonic.xxx.xxx
….

サーバー内nginx設定ファイルが自動で読み込まれるので、適用するドメインを使用します。
ここでは、subsonicなので3を選択

登録するにあたり、規約のPDFを見て承諾するか尋ねられるので、AgreeのAを打ち込む

初めての方は、登録するメールアドレスを求められるので記入します

1: Easy – Allow both HTTP and HTTPS access to these sites
2: Secure – Make all requests redirect to secure HTTPS access

今まで通りhttpでもアクセス可能にするか、全てhttpsで接続させるかを任意で指定

これで、Congratulations!が表示されれば、サブドメインのsubsonic.confにssl設定が追記されています

一応、設定ファイルを読み込んでおきます

# service nginx reload

そして、サブドメインのSubsonic(subsonic.xxx.xxx)へhttpでアクセスして、httpsへリダイレクトされてログイン出来れば完成です。

作業時間より、この記事書くほうが時間かかってしまいました。(^_^;)


Subsonicをアップデートしたらエラー警告がでるようになった

Subsonicのbeta版で特に問題なく利用できていたので、ずーっと放置状態でしたが、年末に時間がとれたので、beta版から正式の6.0へアップデートしました。

アップデート作業は、以前記事にした通りなので割愛します。

Subsonic 4.xから6.0betaへアップデート

問題なく設定も引き継がれたのですが、ブラウザで開いてみたところ、下記のエラーが出るようになりました。

Failed to find parameter: instanceId (check server log for more info).

どうやら、ブラウザのキャッシュの問題のようで、ブラウザを変更してみるか、ブラウザのキャッシュ・クッキーを削除して解決


CentOS7でネットワーク不調だった原因

CentOS7をインストール後に、nfsに接続できなかったり、digでDNS情報が引けなかったりと、四苦八苦してました。

NFSでは、下記の環境

  • Firewall無効
  • SELinux無効
  • NFS関連のプログラムはインストール済み
  • 関連プログラムは、起動済み
  • tcp_wrapperrrで制限はしていない
  • Google等へのpingでネットワーク疎通確認
  • autofsも起動している

autofsで指定しているフォルダにアクセスしても、手動でmountコマンドを打っても、しばらく経ったあとに、Connection timed out.で接続できない。
また、接続先を変更してみても、接続できないので、サーバー側で弾かれているわけではなさそう。

ググってみると、状況によっては、IPアドレスと名前のマッピングも関係する場合があるとの情報もあったので、hostsやDNS関連も確認した。

この作業の途中で、DNSのdigコマンドで自分のホストを確認しようとしてみたところ、なぜかdigの情報がGoogle等では引けるのに、自分のDNSでは引けないことに気づく。

なぜ?と、徐ろに、ipコマンドを打ってみた。

# ip addr
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
 link/ether 00:0cxx:b0:xx:e0 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.37/32 brd 192.168.1.37 scope global ens32

もう、お分かりになったでしょう!

サブネットマスクが32になっているではありませんか。

CentOS7のネットワーク設定で、nmtuiコマンドによりネットワーク設定を行ったわけですが、IPアドレス入力欄で192.168.1.37だけを入力した時に、自動的に192.168.1.37/32へ設定されていたようでした。

もう一度、nmtuiを起動して変更しても構いませんが、下記を編集して手動で対処した。

# vi /etc/sysconfig/network-scripts/ifcfg-en32
PREFIX=24  #32から24へ変更して保存
# systemctl restart network

これにて、NFSもdigも一件落着しました。


ルート領域がフルになりそうなのでコマンドラインで確認してみる

このサイトでは、Sientific Linux 6.xの64bitで運用しており、ハードディスク容量を見てみたところ、99%使用で、危うく100%超しそうでした。

WindowsやMacでは、GUIでグラフィカルなHDD容量チェックルーツがたくさんあります。もちろんLinuxでもないわけではありませんが、コマンドラインの方が簡単で慣れてるので、コマンドラインでチェックです。

全体の容量を見るには、df -Hでパーティション毎に、容量情報を見ることが出来ます。
調べてみたところ、ルート(/)領域が99%で、その中でも/usr以下がほぼ占めてた。

それで、/usr/以下を下記コマンドで調べてみた。

# du -s /usr/* | sort -n
1.5M ./bin
4.0K ./etc
4.0K ./games
4.0K ./lib64
4.0K ./libexec
4.0K ./sbin
4.0K ./src
36G ./vpnserver
87M ./lib
382M ./rbenv
436K ./share
688K ./include

vpnserver下が圧倒的に容量を喰っていたので、さらに調べていったら、ログが溜まっていたのが原因でした。
あっさりとログを削除したころ、HDD空き容量が99%から20%にも減りましたとさ。


expressをインストールしてもnot foundになる

node.js関連でexpressをインストールする場合があるかと思いますが、ネット上の情報では、下記みたいに書いている事が多いです。

# npm install -g express

でも、この通りにインストールして、expressを実行しようとすると、command not foundと見つからないのです。

# express
express: command not found.

パスが必要なのかと思って探してみても、expressが見つからないのです。

どうやら、express 4.xでは、下記のようにインストールするようです。

# npm install -g express-generator

これで、expressが動作した。



CentOSにYUMでownCloudをインストール

CentOS 6.xにYUMのリポジトリを追加して、yumにてownCloudをインストール

# cd /etc/yum.repos.d/
# wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_CentOS-6/isv:ownCloud:community.repo
# yum update 
# yum info owncloud
Name        : owncloud
Arch        : noarch
Version     : 6.0.2
Release     : 8.1
Size        : 46 M
Repo        : isv_ownCloud_community

# yum install owncloud --enablerepo=epel

ownCloudの依存パッケージで下記のようなエラーが出る場合にはepelリポジトリを読み込む事。

Error: Package: owncloud-6.0.2-8.1.noarch (isv_ownCloud_community)
Requires: php-pear-MDB2-Driver-mysqli
Error: Package: owncloud-6.0.2-8.1.noarch (isv_ownCloud_community)
Requires: php-pear-Net-Curl

ちなみに、他のLinuxディストリビューションのインストールは、こちらにて。


wrkのインストール

ベンチマークツールのwrkをインストールしました。

Macでは、brewパッケージで簡単に導入できます。

$ brew install wrk

Linuxでは、パッケージが用意されていないので、githubのリポジトリを利用してインストールします。

$ cd /tmp
$ git clone https://github.com/wg/wrk.git
$ cd wrk/
$ make
$ sudo cp wrk /usr/local/bin/.

使い方

$ wrk -t スレッド数 -c 接続数 <url>

Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  Connections to keep open
    -d, --duration    <T>  Duration of test
    -t, --threads     <N>  Number of threads to use

    -s, --script      <S>  Load Lua script file
    -H, --header      <H>  Add header to request
        --latency          Print latency statistics
        --timeout     <T>  Socket/request timeout
    -v, --version          Print version details

  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

 


APCからZend OPcacheへ変更

Scientific Linux(sl6)で運営しているこちらのサイトで、APCをやめて、Zend OPcacheへ変更してみた。

現状の環境は、

Scientific Linux: 6.4
PHP: 5.4.19 (php-fpm)
nginx: 1.4.2
APC

Zend OPcache導入

redhat系のsl6,CentOS,Fedoraではパッケージが用意されていないようなので、githubからソースプログラムを引っ張って、コンパイル・ダウンロードする。

その前に、php-deveが必要なので、php-develをインストールしておく。

# yum install php-devel --enablerepo=remi

githubからインストールまでの作業

$ sudo yum install php-devel --enablerepo=remi

$ git clone https://github.com/zend-dev/ZendOptimizerPlus.git
$ cd ZendOptimizerPlus
$ phpize
$ ./configure --with-php-config=/usr/bin/php-config
$ make
$ make test
$ sudo make install

make installで、/usr/lib64/php/modules/opcache.soがインストールされるので、これをphp.iniで読み込む

php.iniに下記を追記

/usr/lib64/php/modules/opcache.so

APCが読み込まれているので、これを無効にする。

# cd  /etc/php.d/
# mv apc.ini apc.ini.bak

nginx再起動し、確認

# /sbin/service nginx restart
# php -v
PHP 5.4.19 (cli) (built: Aug 22 2013 08:03:53)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
  with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies

with Zend OPcacheが表示されればOK。


ページ:12345