:::: MENU ::::
Browsing posts in: Network

Coreserverリニューアル後にWordPress閲覧不可に

Coreserver上にて、とあるブログサイトをWordPressで運用していたのですが、数日前から閲覧不可になってた。

どうやら、Coreserverにて大規模なリニューアルが行わたのが原因のようです。

https://www.coreserver.jp/info/brandnew2017/

CPUコア数やメモリ増強、SSD対応など機能的にはかなりアップしたようなのですが、PHP/MySQL/Apacheなども最新のバージョンが採用された影響で、今まで動作していたWordPressが動作しなくなってしまいました。

調べてみると、WordPress自体が動作していなく管理画面すら入れない状況でした。

画面上では、真っ白で何も表示されていないので、SSHでログインし、デバッグを有効にしてみました。
すると、下記のようなエラーが残されていました。

PHP Warning: require_once(/wp-content/plugins/db-cache-reloaded-fix/db-module.php)

db-cache-reloaded-fixのプラグインが既に更新されておらず、PHP71にも対応していないようなので、WordPress管理画面にも入れないのでプラグインディレクトリからdb-cache-reloaded-fixを除外。
しかし、それでも同様のエラーが表示されるので、キャッシュディレクトリ内を削除。
これでもエラーが解決されないので、プラグインディレクトリ自体をリネームしてみました。
やはり、同様のエラーが続くので、調べてみると、wp-content内にdb-cache-reloaded-fixがdb.phpを作成するらしく、これも削除しなければならないようでした。

そして、他のプラグインを戻してみましたが、やはりWordPressは動作せず。

仕方ないので、「PHPスクリプトが動かなくなりました」の対応通りにPHP5.xに戻してみたところ、一瞬だけWordPress画面だけ表示されましたが、すぐに真っ白な画面に戻った。

もうプラグインやテーマ内の不具合を探すのが億劫になってきて、新規にWordPressを作成し、MySQLのデータベースだけを読み込んでみた方がてっとり早いと思ったら、なんと文字化け。
エンコードをEUCやSHIS、UTF8など、どれを選択しても化ける。

PHPで構築したページが文字化けしている」を参考に、PHPやらMySQL関連を弄ってみるが、全てをUTF8になっているはずなのに、一向に文字化けが治らない。

さて、どうしたものかと、WordpressのMySQLデータ内部を覗いてみると、データ部が文字化けしている。
一週間前にDBのバックアップを取っていたので、それと比較してみた所、バックアップのDBは文字化けしていない事が判明。

結局、PHP71+MySQL5.7の最新バージョン上にて、WordPressを新規構築し、インポートしたバックアップのDBを読み込むことで、復旧した。

尚、Coreserver上でFast-cgiを利用する場合には、php.iniに相当するファイルも設定する必要があるので、下記を参考にすることもお忘れなく!

https://www.coreserver.jp/support/faq/php-cgi.php

1日がかりで疲れたわ。


ApacheのバージョンによりAuthTypeエラー

幾つかのApacheサーバー関連で、セキュリティ強化のため、httpd.conf内の制限を強くしていったところ、下記のエラーでトップのページが表示されなくなってしまった。

configuration error:  couldn’t perform authentication. AuthType not set!: /

原因は、Apache 2.2系の設定に、下記を追加したことによるものでした。

<Directory "/var/www/html">
...
...
Require GET POST
</Directory>

Require記述は、2.4系からなので、Require行を削除したところ、復帰しました。

Requireの書式を記述しても、configtestは通って、Syntax OKになるので注意ですね。

 


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

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

環境

現状は、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へリダイレクトされてログイン出来れば完成です。

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


QNAPをZabbixの監視対象にする

Zabbix Serverで監視対象のホストを順次登録しているのですが、NASのQNAPシリーズも監視対象にしたい。

しかし、QNAPのアプリではZabbixは存在しないので、下記の手順でインストールした。

QNAP側 (Zabbix Agent)

  1. Zabbixのフォーラムにて、配布されているQPKGファイルをダウンロード
    https://www.zabbix.com/forum/showthread.php?t=40955
  2. QNAPに管理者でログインし、App Centerを開く
  3. 「手動でインストール」 をクリックし、ダウンロードしたQPKGファイルを選択し、インストール
  4. Zabbix _agentのインストールが完了後、起動をON
  5. 次に、QNAPへTelnet若しくはSSHで管理者にてログイン
  6. zabbixの設定ファイルを編集
    # vim /etc/zabbix/zabbix_agentd.conf
    ….
    Server = xxx.xxx.xxx.xxx (Zabbix ServerのIPに設定)
    ….
  7. zabbix agent再起動
    QNAP側で、起動しているので、一旦停止して起動させます。

    # /etc/init.d/zabbix_agentd.sh stop
    # /etc/init.d/zabbix_agentd.sh start
  8. zabbix agent起動確認
    # ps aux|grep zabbix
    13738 zabbix 696 S /usr/bin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.c
    13743 zabbix 860 S /usr/bin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.c
    ….

Zabbix Server 側

  1. Zabbix Serverへ管理者でログイン
  2. 設定のホスト作成でQNAP用のホストを作成
    IPアドレスにQNAPのIPアドレス
    テンプレートにTemplate OS Linux

これで、しばらく待ち、エージェントの状態が緑になればOKです。

赤のまま表示されていれば、ファイヤーウォールの影響か、ポートの指定、IPの指定等を確認したほうが良いでしょう。

作業した直後、エージェントの状態が赤のままで、調べてみたら、QNAP側のzabbix agentが起動していなかったと言うオチでした。
QNAP上でzabbixを再起動した際に、横着して、zabbix_agentd.sh restartとやっちゃったんです。(_😉


zabbix 2.4.xから3.0へアップデートしたら画面が真っ白

職場のzabbixを2.4.xから3.0へアップデートしたのでメモ

アップデート方法は、ほぼ下記のURL通りです。(手抜き)
http://qiita.com/ryouma_nagare/items/9bcf8f5e3e514103b515

違う点は、pg_dumpでなくて、mysqlを使っている点と、リポジトリの差し替えで、CentOS 6.xの環境だったので、rhelの7を6へ変更したくらいです。

まぁ、すんなりとアップデートが終わり、再起動してみた。

# service start zabbix-server
# service start zabbix-agent

それで、いつも通りにWEBのログイン画面にアクセスすると、画面が真っ白

失敗したのか、zabbixのログを見ても、表示されないエラーは見当たらず、Apacheのログを確認したところ、

PHP Parse error: syntax error, unexpected ‘[‘ in /usr/share/zabbix/index.php on line 29

どうやら、zabbix 3.xからは、php5.6以降が必須らしい。
phpのバージョンを調べたら、5.3.xだったので、早速、phpのアップデートです。
ちなみに、php7は、まだ様子見なので、5.6.xをインストールしました。

下記URLを参考に、remiで5.6をインストールです。
http://syaka.site/2016/03/6/

phpのアップグレード完了後に、Apacheを再起動して、再度WEB画面にアクセスすると、

Not Found The requested URL /zabbix/ was not found on this server.

2.4.xのバージョンまで、同じURLで接続出来ていたのに?と、/etc/httpd/conf.d/zabbix.conを確認したところ、zabbix.conf.rpmsaveに名前変更されたままでしたので、zabbix.confに戻しました。

そして、再度、WEB画面にアクセス。
表示されました! が・・・何だかエラーっぽいのが沢山表示されている。

ふむ、timezoneがどうとか言ってるようで、いつの日からか、timezone設定しなきゃいけなかったのを思い出し、/etc/php.iniを編集して、timezoneを有効にした。

date.timezone = Asia/Tokyo

さらに、Apacheを再起動して、再接続したら、エラーっぽい表示はなくなりましたが、今度は、php内のオプションを変更してね〜とな。

あとは、phpのオプション設定変更と、不足しているモジュールを導入してあげれば良いようです。

/etc/php.ini

post_max_size = 16M
max_execution_time = 300
max_input_time = 300
always_populate_raw_post_data = -1

不足しているモジュールは、bcmathとxml関連なので、

# yum install php-bcmath php-xml

これで、無事に正常動作が確認できました。 はぁ、疲れた。


rainloopでページにアクセス出来ない症状

職場のWebメールをrainloopに変更したところ、ある一人から、アクセス出来ません!と報告がきた。

拝見した所、下記のエラー

Page refresh in case of javascript errors

MacのSafariの環境でエラーが出ていたので、とりあえず他のブラウザーで試してみてと提案。

Google ChromeもFirefoxも入っていなかったので、ダウンロードしようとしたところ、どちらもMac OS X 10.6以降が必須なのでダウンロード出来ませんと表示。

えっ? Mac OS Xのバージョンは?

はい、10.5.xと古かったのです。

rainloopの必要要件では、対象ブラウザーが明記されているものの、バージョンまでは書かれてないようですが、恐らく、これが原因なのでしょう。

http://www.rainloop.net/docs/system-requirements/


Webmin/Usermin接続が拒否される場合

めったに開かないのですが、久しぶりにWebmin/Userminへアクセスしたところ、接続(アクセス)が拒否されるようになっていました。

当然、サーバーは起動しているのを確認し、Webmin/Userminの再起動も行っています。

ところが、古いブラウザでは接続出来るようなのです。

調べてみると、どうやら証明書の鍵長が1024ビット未満の場合には、アクセスが拒否するらしく、古い設定のままのWebmin/Uerminは、デフォルトで512ビットで作られているのが原因のようです。(現在のデフォルト設定は、2048になってます)

これを解決するには、証明書を再作成すると直るようですので、下記の記事を参考にしてみました。

http://www.prox.ne.jp/faq/2_368_ja.html

Webminが開けない

なるほど、そのようにWebmin上で作成するんですね。 って、お〜〜い、そのWebmin/Usermin自体につながらないっつうの!

一番、手っ取り早いのは、Webminサーバー内の設定を一時的に変更してあげる事ではないでしょうか。

$ cd /etc/webmin/
$ vim miniserv.conf ... ssl=0 # ←1を0に変更 ...
$ service webmin restart

コマンドラインで作成するには、下記参照

Replace webmin self-signed certificate to avoid sec_error_invalid_key error

http://d.hatena.ne.jp/kibitaki/20150718/1437231546


複製したVMwareゲストOSがネットワークにつながらない時に確認するポイント

VMware Fusionで他からコピーしてきたCentOSのゲストOSをそのまま起動しようとすると、デバイス名(eth*)が認識されなくてネットワークが利用できません。ちなみにVirtualBoxでも同様だと思います。

# ifconfig -a

loしか表示されず、eth*が表示されない

ここでのポイントは、MACアドレスとデバイス名を確認し、修正する事で、おおよそ解決できるかと思います。

MACアドレスの確認と修正

確認

ゲストOSのCentOSを起動後、ログインし、/etc/sysconfig/network-scripts/ifcfg-eth0(←この数字は環境に合わせて)を確認します。

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
ここで表示されたHWADDRのMACアドレスを確認します

次に、VMware Fusion上の起動したCentOSの設定より、ネットワークアダプターを選び、下部の詳細オプションをクリックします。

表示されたMACアドレスが新しいものなので、ifcfg-eth0内のMACアドレスをこれに置き換えます。

保存後に、ネットワークを有効化します。

# /sbin/service network start

この後に、何もエラーが出ずに、ネットワークが利用できるのであれば、これだけで終了です。

しかし、ほとんどが、下記のエラーが出る場合が多いです。

Device eth0 does not seem to be present, delaying initialization

デバイス名の設定変更

# cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:92:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:65:yy:yy", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

同じネットワークデバイス名が存在し、上記が古いMACアドレス、下記が新しいMACアドレスになっているかと思います。
下記のMACアドレスが、上図の詳細オプションで表示されたMACアドレスになっていることを確認し、上記の古い情報(デバイス、MACアドレス)を削除します。

このままでも問題はありませんが、ネットワークデバイス名がeth0でなく、eth1となってしまうので、eth1をeth0に変更すると良いでしょう。

この後、OS再起動するとネットワークが利用できる環境になっている事と思います。


Windows8で無線のプロファイルを削除

Windows8で、昨日まで動作していた無線ネットワークがつながらなくなったので調べてみた。

XP時はネットワークの修復やWindows7ではワイヤレスネットワークの管理である程度解決に至ったのだが、Windows8では削除されているとの事。

仕方ないので、コマンドラインにて操作

DOSプロンプトかWindowsPowershellを起動

ワイヤレスプロファイルを表示

> netsh wlan show profiles

プロファイルセキュリティキーを表示

> netsh wlan show profile name="プロファイル名" key=clear

プロファイル削除

> netsh wlan delete profile name="プロファイル名"

手動にて無線ネットワークに接続するように

> netsh wlan set profileparameter name="プロファイル名" connectionmode=manual

プロファイルを削除した後に、一応、再起動したら、無事、無線LANへ再び接続出来た。


一部のSSIDでネットが遅い原因はproxypacが一因もある

WiFiルータが複数あって、一部のSSIDに接続するとネットワークが遅い事が起こった。

この原因と思われるSSIDを別端末から接続すると問題ない速度が出るので、WiFiルータが原因でないことが分かる。

何かが怪しいと言うことで、iPhoneのネットワーク設定を調べてみた。

あっ、自動の箇所が以前にONにしたままで、プロキシー経由だった。orz

これをオフにする事で、即解決。

デスクトップPCにせよ、スマホにせよ、プロキシー使っていた場合、偶には確認した方が良いですね。

ちなみに、このプロキシーURLは見る人には分かるよね?
ヒントは「中国以外(日本国内)でもYoukuの動画を見れるChrome機能拡張」記事


ページ:12