中小企業のマーケティングやブランディングのコンサルティング。事業運営、組織運営のPDCA改善やホームページの制作、ウェブサイト改善などITネット活用を中心にサービスを提供しています。

sudo「コマンドが見つかりません」PATHが初期化されているときの対処法

sudo でコマンドを実行すると、「command not found」とエラーに。環境変数 PATH が通っていないと思って設定しても変わらず。実は sudoers の設定でセキュリティ上環境変数が初期化されている。そのときの対処備忘メモ。

現象

  1. sudo でコマンドを実行
  2. 「command not found」 (コマンドが見つかりません) とエラーに
  3. .bash_profile にパスを設定してみる
    vi ~/.bash_profile
    
    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
    

    から

    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin:/usr/local/bin
    

    に変更。

  4. sudo でコマンドを実行
  5. 再び「command not found」 (コマンドが見つかりません) とエラーでパスが通っていない

さらに突き詰めると、

sudoers の env_reset オプションが有効になっている

原因

sudoers の env_reset オプションが有効になっている場合、セキュリティ上環境変数が初期化されて secure_path に設定しているパスが使われるので、環境変数 PATH が通らない。

解決

3つの方法でパスを通す

sudoers はデフォルトでは env_reset オプションが有効になっている。無効化するか、環境変数を引き継ぐか、または secure_path にパスを設定することで環境変数 PATH を通す。

sudoers は visudo コマンドで編集できる。設定が間違っていたらエラーチェックもしてくれるので、直接ファイルを編集することは控える。

1. 無効化する場合

コメントアウトして env_reset オプションを無効化。

#Defaults env_reset

2. 環境変数を引き継ぐ場合

以下を追記

Defaults env_keep += "PATH"

そして以下をコメントアウト

#Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

.bash_profile に設定したパスが通ります。

3. パスを設定する場合

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

から

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

に変更してパスを追加

sudo でコマンドを実行して確認。
complete!!

教訓

環境変数 PATH の設定の他、env_reset が有効化されているかどうかも確認しよう。

関連サイト

「#!/usr/bin/perl –」はFTP転送モードの問題? 実はFTPサーバ設定の問題

Perl のパス 「#!/usr/bin/perl -w」では正常に動くのに、「#!/usr/bin/perl」では「Internal Server Error」に。

cgiスクリプトの記述や設定が正しくなかったり、サーバ内部でエラーが発生した場合に返されるのが「Internal Server Error (HTTPステータスコード500)」。エラーがあるのは分かるが、原因がわからない、Webエンジニアにとって頭を悩ます「Internal Server Error」。

その原因も様々。原因が明らかにできなければ対策も解決もできない。Perl パスの問題かと思いきや、FTPの転送モードの問題?、実はFTP サーバ設定の問題というちょっと複雑。そんな問題に直面した備忘メモ。

現象

  1. FTP を使ってアスキーモードでファイルをアップロード
  2. Perl のパス 「#!/usr/bin/perl」 では cgi が 「Internal Server Error (HTTPステータスコード500)」に
  3. Perl のパス 「#!/usr/bin/perl -w」 または 「#!/usr/bin/perl –」 では正常に動作する

  4. 改行コードが問題と思ってファイルの改行コードを「LF」に変換
  5. 再度、FTP を使ってアスキーモードでファイルをアップロードしても同じ現象に
  6. 「あれれ」無限ループにはまる。

さらに突き詰めると、

シェル上でスクリプトを走らせると、

/usr/bin/perl^M: bad interpreter: No such file or directory

とエラーに

さらに突き詰めると、

FTP サーバに vsftpd を使っている

原因

FTP サーバ vsftpd では、ファイルの改行コードが変換されないこと。

解決

改行コードを「LF」に変換するだけという、単純なものではありません。

実際は、ファイルをアスキーモードでFTPアップロードしても、改行コード「LF」に変換されません。

それは、FTP サーバ vsftpd ではアスキーモードでのダウンロード・アップロードのデフォルト設定が無効になっているから。

ということで vsftpd の設定をしてみる。

1. vsftpd の設定をする

シェル上で vsftpd.conf を編集。

vi /etc/vsftpd/vsftpd.conf

設定内容を

ascii_download_enable=NO
ascii_upload_enable=NO

から

ascii_download_enable=YES
ascii_upload_enable=YES

に変更して有効に

2. vsftpdを再起動

service vsftpd restart

3. ファイルを再度アップロードする

4. 確認。Perl のパス「#!/usr/bin/perl」でうまく表示できた。

complete!!

教訓

FTPの転送間違えの他、視野を広げてFTP サーバの設定も診てみよう。

関連サイト

専用サーバ運営では必須の不正アクセス対策 SSHのポート番号変更

サーバを運営していると、SSH経由でユーザ名とパスワートの総当たりで不正な接続を試みる攻撃 (ブルートフォースアタック) を受けることが多い。ログ監視ツール Logwatch から毎日送られてくるレポートでも多数確認できる。root には数千件の数で試みられているのが見受けられることも。

対策は、ssh のポート番号を変更すること。デフォルトのポート番号 22 での接続を避ける。

デフォルトのポート番号 22 から別の番号に変更することで断続的な不正アクセスを無くして、サーバの負荷軽減にもなる。

ということで、sshのポート番号を変更。

設定ファイルを編集。

$ vi /etc/ssh/sshd_config

デフォルトではコメントアウトでポート番号 22 が使われているので、任意のポート番号 **** に変更。ポート番号は、使用されていない 0~1023 (ウェルノウンポート) 以外のポート番号に変更しましょう。

#Port 22
Port ****

SSHを再起動。

$ /etc/init.d/sshd restart

iptablesの設定

iptables でファイアウォールの設定をしている場合、変更したポートを通す必要があります。設定せずに ssh の接続を切ってしまうと、ssh に接続できなくなるので要注意。

$ vi /etc/sysconfig/iptables
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

から

-A INPUT -p tcp -m tcp --dport 任意のポート番号 -j ACCEPT

に変更。

iptablesを再起動して、設定を再読み込み。

$ /etc/rc.d/init.d/iptables restart
iptables: Setting chains to policy ACCEPT: filter [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Unloading modules: [  OK  ]
iptables: Applying firewall rules: [  OK  ]

接続確認

接続確認は、念のため元のターミナルでの接続を保ちつつ、新規ウインドウでターミナルを立ち上げて接続を確認することをおすすめします。

まずはポート番号 22 で接続。

$ ssh ユーザID@ホスト名
$ ssh: connect to host **.**.**.** port 22: Connection refused

ポート番号 22 では接続が拒否される。

変更したポート番号で接続。

$ ssh -p ポート番号 ユーザID@ホスト名

接続できれば完了。

analogのログフォーマット (turn debugging on or try different LOGFORMAT)

Cron からアラートメールが返ってくる。

/etc/cron.daily/logrotate:
/usr/bin/analog: analog version 5.32/Unix
/usr/bin/analog: Warning L: Large number of corrupt lines in logfile stdin:
turn debugging on or try different LOGFORMAT
(For help on all errors and warnings, see docs/errors.html)
Current logfile format:
%v %S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r%wHTTP%j" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r%wHTTP%j" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%r" %c %b "%f" "%B"\n

analog のログフォーマットが違うみたいだ。Apache のログ形式は combined なので、analogの LOGFORMAT ( /etc/analog.cfg ) を確認。なかったので末尾に以下を追記。

LOGFORMAT COMBINED

Apache のログ形式を変更したときには見直すことを忘れずに。

サーバ管理ツール Plesk アップデートエラー対処法

サーバ管理ツールである Parallels Plesk Panel をバージョン 8.6.0 から 9.x.x にアップデートすると、管理画面にアクセスできなくなった。届いてるメールは「Plesk autoupdate success report」だけど。

メールの内容をみると、Plesk の起動に失敗している。

Trying to start Plesk...
Stopping Plesk... done
Starting xinetd service... done
Starting named service... done
Starting mysqld service... done
Starting postgresql service... done
Starting psa-spamassassin service... done
Plesk: Starting Mail Server... already started
Starting Plesk... failed
Starting drwebd service... failed

再びサービスを開始しても同じに。

$ /etc/rc.d/init.d/psa start

ログをみると、どうやら SSL でエラーになっているようだ。

$ tail /var/log/sw-cp-server/error_log
2010-10-24 18:44:44: (log.c.75) server started
2010-10-24 18:50:27: (log.c.135) server stopped
2010-10-24 18:50:34: (log.c.75) server started
2010-10-24 18:50:34: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-10-24 18:50:34: (log.c.75) server started
2010-10-24 18:50:34: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)

対処方法は、Latest update of openssl breaks Parallels Panel を参考にパッケージをインストール。

$ wget -c http://kb.parallels.com/Attachments/12669/Attachments/sw-cp-server-1.0-6.201004011105.centos5.i386.rpm
$ rpm -Uhv sw-cp-server-1.0-6.201004011105.centos5.i386.rpm
$ /etc/rc.d/init.d/psa start
startStarting xinetd service... done
Starting named service... done
Starting mysqld service... done
Starting postgresql service... done
Starting psa-spamassassin service... done
Plesk: Starting Mail Server... already started
Starting Plesk... done
Starting drwebd service... done

と無事に Plesk が起動して管理画面にアクセスできるようになった。

関連サイト