投稿

ラベル(FTP)が付いた投稿を表示しています

たまに掃除は必要!熱暴走…

イメージ
 そんなに暑くないのに… 本日、午前中にオンラインで打合せをしていると、突然マシンがダウン。 一瞬、停電か?と思ったもののディスプレイの電源は入っている。 あれっ?と思い、すぐさまノートで打合せを継続。 その間に、再度マシンの電源を投入。 問題なく起動する。 でも、CPU温度がたまたま目に入り、95℃を超えて徐々に上昇していく。 105℃あたりで再度マシンダウン。 これは、熱暴走によるダウンの可能性が高い。 以前、CPUをRyzen7→9にした頃は、60℃〜70℃程度だった記憶がある。 本当はGW中にSSDの載せ替えを行う予定だったけれど、忙しくて先延ばしにしていた。 その時やっていれば、多分掃除もしただろうに…。 ということで、午後からマシンを解体し、掃除をすることに。 ケース本体のFANはホコリがかなり溜まっている。 GPUのFANは問題ない。 電源とCPU FANはひどい。 一旦、CPU FANを取り外し、きれいにする。ついでにCPUグリスも塗り直しセット。 動作確認すると、投入直後で40℃台。 そりゃ、熱暴走も起こすわけだ。 せっかくバラしたので、SSDの載せ替えを実施。 OSは500GBで、ユーザ領域(/home)は1TBを使用しているもののAIのmodelをいくつも落としていたり、DockerのImageが多種置いてあるため、結構容量を食っている。 今回、2TBのSSD( Hanye SSD ¥17,800- で入手済)を用意してあるので、 1TB→2TB, 500GB→1TBと玉突きで移動させることを計画していたので実施する。 本当は、ddコマンドで移すつもりだったのだけれど、3月にお客さんのところで使いそうだったので、 ORICOのクローン機能付SSDアダプタ を入手済。 裸族のSSD版ですね…。1万円程度の品です。 これに、新品のSSDとこれまでの1TBのSSDを差し込んでクローン開始。 そこそこ時間はかかるものの、放置でOK。 ただ、HanyeのSSDについているヒートシンクが引っかかるため、一旦取り外してクローン後取り付ける必要があった。 続いて、500GB→先程の1TBに書き込み。 ただ、1TB(samsungの980pro)が、先程のクローンでかなり熱くなっていたため、速度低下が激しい感じ。1TB→2TBよりも時間がかかった感じ。 ...

vsftpd の動作がおかしい

イメージ
ftpで接続できない vps上の設定を行っていていよいよ最終段階に。 webコンテンツをUPしようと、ftpサーバを立てる。 $ sudo apt-get install vsftpd まあ、これだけの話だ。 でもって、気持よくFileZillaで接続しようとするも接続できない??? 500 OOPS: vsftpd: refusing to run with writable root inside chroot () と文句を言ってくる。 おや、前に違う環境で立てた時は、こんなことはなかった。 まあ、今回はvirtual hostをいくつも切るために、アカウントごとにchrootしているので、これまでとは状況が違うといえば違うのだけれど…。 今回利用しているのは、vsftpd 2.3.5だ。 ググってみっるとこんなタイトルの情報が… 「 Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot () 」はいはい。まんまじゃないですか…。 バグでも潜んでいるんかと、読んでみる。 対策として、 chmod a-w /home/user しろとな。これで試すと、問題なく接続できる。 いやぁ、しかし書き込み権限をなくせばOKと言われましても、これじゃUploadできないわけで…。 試しに、Uploadしてみるが、書き込みできないと言われる。 そりゃ、当たり前だ。 もしくは、次の2つの方法があるらしい。 vsftpdなら allow_writeable_chroot=YES vsftpd-extなら allow_writable_chroot=YES にしろと。(どうして記述の方法を変えたのか…) vsftpd-extってなんじゃい?と思いつつ、とりあえず上の方法で試すも撃沈。 他の情報を探してみる どうやらvsftpd2.3.5になった時に、セキュリティ強化のために導入されたらしい。 じゃ、2.3.4で行けばと思ったら、脆弱性が見つかっているので、止めた方がいいらしい。 手詰まりか?と思ったら、 方法は3つ。 Extended vsft...

wordpressでFTP接続情報を求められた

イメージ
WordPressって便利にはなってるよね すでに最新バージョンは3.5に上がっていて、随分機能UPしたもんだ…。と感心しながらも、サイト構築を手軽に済ますためにお世話になっております。 さて、講義の都合上、各自にお手軽ではないインストールをさせる(といっても環境さえあれば5分もかからないんだけど)ために、事前にテストを行なっていたら、あんまり見たことのない画面に出会って手こずったので、まとめておこうと…。 条件 1台のサーバを共有しているので、ユーザ毎にインストールをする。 MySQLはすでに、ユーザ毎のDBは作成済み。 DBには、ユーザの作成と権限をある程度与えてある。 さて、この条件で設定を行なっていく。 まずは、wordpress本体のダウンロード。( 日本語版 ) でもって、public_html以下に保存&解凍。 wordpressというディレクトリに展開してくれるので、アクセスするときのディレクトリを変えたければ、この時点でrenameすればOKと…。 パーミッションをapacheに書き込み権限を与えておく。 ブラウザから、このディレクトリ(http://xxx.xx.xx.xx/~user/wordpress)をアクセスすれば、インストール画面に。 使用するDB名やらユーザ名、パスワードなど入れてやればOK。接頭辞はDBを共有する場合には変更が必要ですな。今回はwp_のままでOK。 これで、完了。 うまくいったように見えたが…。 管理者でログインしてやると、ダッシュボードが表示され、サンプルも存在する。テーマ関係も変更してみたが問題無さそう。 プラグインを確認。 AkismetとWP Multibyte Patchの更新があると言われたので、更新する。 おっと、FTPの接続画面が…。 このサーバはFTPが立ててなかったが、以前使った時、こんな画面を見た記憶が無い。 一応、vsftpdを入れて動作確認する。 すると、エラーが…。 「ディレクトリを作成できませんでした …/wp-content/upgrade」とな。 パーミッションを確認するが、問題はない…。謎だ。 一応、ググってみると、事例はいくつも上がっておりました。 ...