:::: MENU ::::
Browsing posts in: Linux

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


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



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

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


DockerでOpenVAS起動

脆弱性をスキャンするソフトにOpenVASと言う無償ソフトがあります。

脆弱性スキャナ「OpenVAS」でのセキュリティチェック

一時的に利用するのであれば、Docker上で起動したほうが楽ですね。

Dockerが起動する環境にある事が前提で、DockerHubのOpneVASを利用します。
https://hub.docker.com/r/mikesplain/openvas/

インストール・起動

OpenVASのインストールから起動完了まで、下記の一行で済みます。

$ docker run -d -p 4000:4000 --name openvas mikesplain/openvas:9

この後に、https://:4000にアクセスし、
Username: admin
Password: admin
にて、ログインし、脆弱性をスキャンしたいホストを追加していきます。

パスワード指定で起動

尚、パスワードを変更して起動したい場合は、こちら
$ docker run -d -p 4000:4000 -e OV_PASSWORD=<任意のパスワード> --name openvas mikesplain/openvas:9

ローカルにデータ保存指定で起動

また、Docker上のOpenVASをアップデートした場合や、再起動した際に環境が初期に戻る場合があります。
登録したホスト状況などをローカルに保存しておきたい場合は、Volume機能を追加します

ローカル側に予め保存用のディレクトリを作成しておき、下記のコマンドで起動します

$ mkdir data
$ docker run -d -p 4000:4000 -v $(pwd)/data:/var/lib/openvas/mgr/ --name openvas mikesplain/openvas9

これでローカル側にデータが残るのですが、何故かログインに失敗してしまいます。(調査中)

ログを見てみると、
$ docker logs openvas
.....
.....
omp:WARNING:2017-02-17 04h17.13 utc:224: Authentication failure for 'admin' from 900::900:0:0:0
.....


SSL(HTTPS)で画像が読み込まれなくハマった

とあるサイトで、サイトをSSL化(HTTPS)したところ、画像だけが読み込まれないトラブル

環境は、CentOS7上のApache 2.4で、ssl.confを主体に、confファイルをいろいろ調べてみても解決せずにハマりました。

原因は、「画像の直リンク禁止」設定にしていたからでした。

画像ディレクトリ(images)内の、.htaccessで下記のように直リンク禁止設定にしていました。

<Files ~ "\.(jpg|gif)$">
SetEnvIf Referer “http://www.xxx.xxx/" OK
SetEnvIf Referer “http://localhost/" OK
Order allow,deny
allow from 127.0.0.1
allow from env=OK
</Files>

はい、もうお分かりですね。

記述されているSetEnvIf RefererのURLがhttpになっているので、httpsだと☓なんですね。

ある意味、正常動作

HTTPSでも画像を表示したいので、http:を削除し、//www.xxx.xxxに修正すればOKです。


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

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

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

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

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

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

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


Zabbixサーバとエージェントの通信が取れないよくある症状

Zabbixサーバーが既に稼働してあるものとして、情報を取りたいエージェント(Agent)側にzabbix agentをインストールすることが多々あります。

そのままインストールして、デフォルトのまま起動すると、大抵、サーバー側と通信取れないことがよくあるのでメモしておきます。
Zabbix Agentのインストール手順については割愛します。(yum,aptでzabbix agentをインストールするだけなので)

確認事項と対応

ファイヤーウォール

  • 使用しているOSのファイヤーウォールが起動しているのか?
  • ファイヤーウォールでポートがブロックされていないか?
  • SELinuxが起動していないか?

SELinuxやファイヤーウォール(iptables)が起動していたら、一旦無効にしてみましょう。(手っ取り早いので)

zabbix_agentd.confの設定

デフォルトでは、#Server = 127.0.0.1となっているので、ここをZabbixサーバーのIPに変更しましょう。

デフォルトのままの設定で通信出来ない場合は、下記のようなログが残っているはずです。

failed to accept an incoming connection: connection from “xxx.xx.xx.xx" rejected, allowed hosts: "127.0.0.1"

PIDが作成出来ないエラーの場合

稀に、zabbix agent起動時に、PIDファイルが作成出来なくて、起動に失敗する場合があります。

ログを確認すると、下記のようなエラー

zabbix_agentd [890]: cannot create PID file [/var/run/zabbix/zabbix_agentd.pid]: [2] No such file or directory

これは、OSを再起動した際に、tmpfsの影響により、ディレクトリやファイルが消される場合があります。
この場合には、/var/run/zabbixのディレクトリがあるか確認することとパーミッションを確認しましょう。

# mkdir /var/run/zabbix
# chown zabbix:zabbix /var/run/zabbix

この後に、zabbix agentを再起動し、/var/run/zabbix/zabbix_agentd.pidが作られていることを確認

その他

現在のZabbix最新版は3.xであり、以前からzabbixを利用していれば2.x以前を利用している場合もあるかと思います。
バージョンによる不具合も起きるかもしれませんので、なるべくバージョンは合わせたほうが良いでしょう!


ページ:1234567...15