:::: MENU ::::

QNAP再起動後にNFSでマウントできなかった

QNAPをNFSサーバーにして、各クラアントからAutofsでマウントして、正常に動作していたはずなのに、QNAPを再起動した後から、NFSによるマウントが出来なくなってしまった。

数台のクライアントからAutofsでQNAPにマウント出来ていたはずが、どれも、正常にマウントしない症状。

QNAP上のNFSを再起動してみても変わらずで、mountの詳細を見てみると、

mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.1.2:/data

明らかにサーバー側で拒否されてる

QNAPサーバー側では、接続してくるIPを制限しているので、QNAPへSSHで入り、/etc/exportsを確認してみた所、

“/share/MD0_DATA/data” 192.168.1.1192.168.1.1.2192.168.1.3(rw,async,no_subtree_check,insecure,no_root_squash)

許可するIP部分が勝手に連結されているのが原因でした。

exportsを書き換えても、ウェブ管理画面のGUIで設定を行うと再び連結されるので、QNAPマネージャーのバグなのでは?

仕方ないので、ウェブ管理画面上の権限設定→共有フォルダ→アクションボタンの共有フォルダ権限の編集→権限タイプの選択でNFSホストのアクセスに進み、接続を許可するIPを一つづつ記入し、適用する事で、各クライアントから正常にAutofsが働くようになった。

何だかんだQNAPのバグには悩まされる…


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


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日がかりで疲れたわ。


Dockerのインストール方法が変わってた

DockerがCE/EEとなり、インストール方法が変わってるんですね。

公式やQuiita参照で、ほぼ解決します

https://docs.docker.com/engine/installation/linux/docker-ce/debian/#prerequisites

http://qiita.com/adnap2501/items/e00248dd697059969203

古いバージョンをアンイストして、入れたほうが良いかもしれません。

新しいリポジトリ追加して、apt更新時に上手く取得できない症状に遭遇しましたが、
そのままインストールしちゃいました。

docker-composeもaptでインストール出来るので楽ですね

ちなみに、Redhat/CentOS系は下記のQuiitaで良いでしょう

http://qiita.com/sawadashota/items/2bed41598d825d488701



dyld: Library not loaded: /usr/local/opt/jpeg/lib/libjpeg.8.dylib

久しぶりにHomebrewでUpgradeかけたら、下記のエラーが出た

dyld: Library not loaded: /usr/local/opt/jpeg/lib/libjpeg.8.dylib

ほぼ、下記の記事が参考になる

http://qiita.com/maimai-swap/items/9ba6e5f877274079d755

私の環境の場合、jpegのバージョン8d,9bが混在しているようなので、下記のコマンドで戻せばOKでした。

# brew switch jpeg 8d

ESXiでゲストOS新規作成でネットワークデバイスが認識されない?

ESXi上で、普通にLinuxのゲストOSを作成しようとしたら、ネットワークデバイスが認識されてない?

ESXiのバージョンはそのままで、今まで、何度もLinuxのゲストOS作成しているので、OSが新しく(今回はCentOS7)なったことにより、デバイスが認識されなくなったのかと思ったら、初歩的なミスでした。

新規仮想OSを作成する際に、アダプタがVMware独自のVMXNETになっていただけでした。(^_^;)

ここのアダプタをイーサネットデバイス(私の場合、E1000)に変更でOKです。

ちなみに、構成後にアダプタを変更する場合は、一旦ネットワークデバイスを削除して追加するしかないようですね。


ESXiでscpが無反応?

ESXiで以前は利用できていたはずのscpが無反応で使えず。

どうやらESXi5.xからファイアウォールでブロックされているようでした。

vSphere Clientで管理者にてログインし、構成からセキュリティプロファイル内のファイアウォール→プロパティでSSH Clientにチェックを入れればOKです。

SSHは使えていて、コマンドにもscpがあるので、てっきりscpは使えるものだとばかり思ってました。(^_^;)


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

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


ページ:1234567...25