[Plesk] 残っているユーザー情報をコマンドから削除するの巻

CentOS

2013.10.11

私自身Pleskは利用していないのですが、当ブログのコメントにてご共有頂いた有用かと思われる情報を記事にさせていただきます。情報提供頂いたくりくりさん、ありがとうございます。

ユーザーが「example」、ドメインが「example.com」の場合のPleskに残っているユーザー情報の削除方法です。

ユーザーの削除

ユーザーの存在を確認

# grep example /etc/passwd

ユーザー設定のバックアップ

# for f in passwd password- group group- shadow shadow- gshadow gshadow- ; do cp -p /etc/$f /etc/$f.back ; ls -la /etc/$f* ; done

ユーザーの削除実施

# /usr/local/psa/admin/sbin/usermng –del-user –user=example

ユーザー削除を確認

# grep example /etc/passwd

データーベースからの削除

adminパスワードの確認(平文らしいｗｗ)

#cat /etc/psa/.psa.shadow

MySQLのデーターベースのバックアップを作成
# 「mysqldump -u ユーザー名 -p DB名 > 保存先」でバックアップがとれる
# バックアップからも戻す時は「mysqldump -u ユーザー名 -p DB名< バックアップファイル」

# mysqldump -u admin -p psa > /root/psa.db.back

MySQLにログインしてユーザーを削除する

# mysql -u admin -p
Password: パスワード入力
>use psa;
>select * from sys_users where login=’example’;　←消す前の確認
>delete from sys_users where login=’example’;　←削除実行
>flush privileges;
>exit;

これで削除ができるようです。

お試しください。

以上!

くりくりより:
2013年10月17日 09:39
おはようございます。
書いて頂けたのですね。ありがとうございます。
nginxとapacheの併用をしていますが、nginxでToo many open files エラーがでてしまいnginxはとめることにしました。
これが普通のサーバーならなおせますが
pleskだとバージョンアップもしくはhttp://kb.parallels.com/en/115139/?show_at=jpとなります。
しかし、この方法もマイクロアップデート(週単位)で上書きされてしまいまた修正しないといけません。
今週やっと一台サーバー移転がおわりましたが、解決したエラーが20以上・・・。時間にして3週間です。
こんだけエラーが出た原因はドメインが300近くありpleskの想定外の使い方をしているからです。
trippyboy より:
2013年10月20日 11:56
くりくりさん
現在利用されているサーバーは専用サーバーとお伺いしておりましたが、そうですよね？(^。^;)
専用サーバーであれば、open filesの上限を変更出来るかと思うのですが、その点お試し済みでしょうか。
サイトは色々あるかと思うのですが、http://d.hatena.ne.jp/akishin999/20130213/1360711554 などのページで
open filesの上限を変更する方法が紹介されているので、まだ試しておられない場合はお試しください！
くりくりより:
2013年10月20日 20:51
専用サーバーですがpleskからの操作はサポート対象ですが
シェルからのログインはサポート対象外になっています。
Too manyエラーもhttp://kb.parallels.com/en/115139/?show_at=jp以外の方法で恐らく修正可能でしょうけど、
サポート対象外になることをいわれました。遊びならいいけど、もう動いてるので怖くてできません。
さてtrippyboyさんはnginxとapacheを両方つかっているみたいですが、
nginxはリバースプロキシーでapacheでphpとperlを処理してるんでしょうか？
本来のpleskは上記設定ですからnginx.confをみてみたんですけど、
worker_processes 1;
worker_connections 1024;
この設定じゃ性能が発揮できないようなきがします。ちなみにCPUのコア数4です。
trippyboy より:
2013年10月21日 10:00
くりくりさん
おはようございます。
open filesのリミットは上限を上げることは一般的に行われることなのでやっても大きな問題はない可能性が高いのですが、
実運用中で問題なく動く打開策があるとのこと、さらにはサポート対象外になってしまうとのことなので、現在のApacheでの
運用で良いとおもいます。
はい、nginxとApacheを利用しております。
利用しているサーバーでは２つのIPアドレスが利用できるのですが、一方をnginx、一方をApacheでやっています。
というのも、nginxでのVirtualHostの設定がうまくできなくて、メインで利用しているblog.trippyboy.comをダウンさせながら
設定の試行錯誤を行うと支障がありまして(^^;　（練習用のサブドメインを設定してやれって話ですがw）
なので、Apacheでは、過去の産物になっております news.trippyboy.com の方を利用しています。
nginxは、nginxとphp-fpmを用いてPHPを用いています。リバースプロキシの運用ではなく、nginxは80番ポートのアクセス
を待ち受けている状態です。
>worker_processes 1;
>worker_connections 1024;
そうですね、もしかすると発揮できていないかもしれませんが、発揮できている可能性もあります。
woker_process の数は最高でCPUのCore数と同じ値を設定することができます。CPUのCore数を
超えると、その値は有効ではありません。CPU１Coreに対して、nginxのworkerプロセスは１つしか有効ではないようです。
worker_processes の値を 4 にしてみてもいいと思います。
DTIのVPSは、どういうわけか16コアになっていました(*´∀｀*)　仮想サーバーなので仮想のあたいと思いますが、
ゲストからしてみれば物理CPUと同じ認識なので16をworker_processに指定して様子を見ています。
[root@vps1 ~]# grep processor /proc/cpuinfo | wc -l
16
[root@vps1 ~]#
worker_process 16 * worker_connection 1024 なので、16384のアクセスを同時に処理出来ると考えますが、、あってるのかな。
こんなに必要ないですけどね(笑)