:::: MENU ::::

SSH接続後にCan’t open display等でXが起動出来ない

sshで接続先のX Windowsを利用したGUIアプリを起動すると、よく下記のエラーなどで陥る罠

Error: Can't open display:
unable to open X server `'
unable to open display :0.0
Warning: No display specified. You will not be able to display graphics on the screen.

Xの環境変数やら、ディスプレイ番号も絡んで来ると思いきや、SSH接続でX転送が有効になっていない事が多々あるのでメモ

$ ssh -Y <remote_host>

接続後に、リモートホスト側のXアプリを起動。


CORESERVERのmysqlとmysqldumpのパス

CoreServerで動かしているWordPressでDBのバックアップが取られていない事に、今更気づいたので、確認した所、mysqlmysqldumpが見つかりませんとの表示が出ていた。

CoreServerでは、mysqlとmysqldumpのパスが違う所にあるようなので、下記のパスに設定

mysqldump : /usr/local/mysql/bin/mysqldump
mysql : /usr/local/mysql/bin/mysql

これでOKです。

せめて、/usr/local/bin下にでも入れてくれればいいのにね。


Homebrewでwarning: Insecure world writableが出るようになった

ここ最近、Homebrewでまた下記のパーミッション警告が出るようになった。

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin13/rbconfig.rb:213: warning: Insecure world writable dir /usr/local in PATH, mode 040777

下記のコマンドで警告は出なくなった。

$ sudo chown $(whoami):admin /usr/local && sudo chown -R $(whoami):admin /usr/local
$ sudo chmod go-w /usr/local
$ brew update

CentOS7.xでSamba4.2が起動しない

職場のウェブサーバーでWindows共有が接続できないとの連絡を受け、確認したところ、Sambaが起動していなかったので、下記コマンドで起動を試みる。

# systemctl start smb

すると、下記のエラーで起動しない。

Job for smb.service failed because the control process exited with error code

Selinuxを確認

 #getenforce
 Disabled

Firewallを確認

 # systemctl status firewalld
 firewalld.service - firewalld - dynamic firewall daemon
 Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
 Active: inactive (dead)

はて?何だろう?とログを確認

# less /var/log/log.smbd
 ../source3/smbd/server.c:1256(main)
 error opening config file '/etc/samba/smb.conf'

何だか、設定ファイルのsmb.confでエラーが出ている模様

なので、設定ファイルをデフォルトに戻してみた。

# cd /etc/samba
# cp smb.conf smb.conf.bak
# cp smb.conf.rpmnew smb.conf
(私の環境だと.rpmnewになっていたが、.defaultの場合もある)

再度、Sambaを起動

# systemctl start smb

無事、起動できた。


CentOS7のyum updateでkernelを除外

CentOS7上で、yum更新した後、再起動した際に、起動できないことが度々起こりました。

具体的には、通常にyum更新をかけると、kernelのアップデートがあった場合に、アップデートされ、次回の起動時には、アップデートされたkernelで起動しますが、これが下記のエラーで止まったまま、正常に起動しないということです。

dracut-initqueue[685]: Warning: /dev/root does not exist

このエラーは今まででも何度か体験しているので、yum 更新でkernelを除外設定にした。

yum設定ファイルを編集

# vi /etc/yum.conf

....

exclude=kernel* <--追記

(サーバーとして運用しているので、xorg*やcentos*も実際には追記しています)

 

アップデートされた場合でも、勝手に新しいkernelで起動しない設定

# vi /etc/sysconfig/kernel

....

UPDATEDEFAULT=no <--yesから変更

この2つの設定をしておくと、yum更新でkernelのアップデートが適用外となり、万が一、kernelアップデートされたとしても、現在のkernelで起動できるようになります。


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/


homebrewのアップデートで失敗は、phinzeが原因

久しぶりにbrewの更新をかけたら、下記のエラー

$ brew update
==> Tapping homebrew/core
Cloning into '/usr/local/Library/Taps/homebrew/homebrew-core'...
....
Error: Could not link phinze/cask manpages to:
  /usr/local/share/man/man1/brew-cask.1

Please delete these files and run `brew tap --repair`.

どうやらphinzeは、しばらくメンテされていないようで、uptapしてあげれば良さそうです。

$ brew untap phinze/cask
$ brew update; brew cleanup; brew cask cleanup

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


ページ:1234567...25