投稿

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

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

イメージ
 そんなに暑くないのに… 本日、午前中にオンラインで打合せをしていると、突然マシンがダウン。 一瞬、停電か?と思ったもののディスプレイの電源は入っている。 あれっ?と思い、すぐさまノートで打合せを継続。 その間に、再度マシンの電源を投入。 問題なく起動する。 でも、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よりも時間がかかった感じ。 ...

MEGAにも弱点があった?

イメージ
クラウドストレージMEGAを愛用中 DropboxもOneDriveもGoogleDriveも全部使っていますが、最近はMEGA( https://mega.nz/ )がお気に入りです。 Dropboxは手軽で便利なんだけど、初期容量が2GBと少ない。 もちろん、あれやこれや工夫して14GBまで無料枠を増やしているけど、不足気味。 OneDriveは、Office365をサブスクで使っているので、容量は1TBと多いけど、Linuxで使うには少々面倒。WindowsOSなら使い勝手が良さそうなんだけどね。 同様に、GoogleDriveも15GBとやや少な目。 で、MEGAです。無料枠は50GBです。 しかも、デスクトップの常駐同期アプリがGNOME版もあるので、通常使いにはとても便利…。起動しておけば、勝手に同期してくれるし…。 もちろん、Webインターフェイスもあるので、同期していなくても使用可能。 ところが… 今回、Ryzenマシンを調達し、さくっとUbuntu入れて、MEGA入れて同期開始。 作業を行っている間に、同期終わるやろうと思って、休憩がてら確認してみる。なんと! 止まっている!! 無料転送容量制限を超過したので、しばらくウェイティングタイムだよ!って…。 どうやら、6時間で7.5GB転送すると、待て!がかかるらしい。 4時間後に再度、転送開始するよと出ていた。 上のスクリーンショットは、残り時間あと2時間40分と表示されている。 そんな制限、いままでかかったことなかったので気づかなかったよ。 ローカルマシンに同じデータが有るので、LAN経由でコピーしておけばよかった(笑) 偶然回避策を見つけた そのまま放置しておけば、そのうち終わっただろうけど、さっさと終わらせたいなと思い、LAN経由でコピーをし始めた。 ただ、MEGAの常駐アプリとコンフリクト起こすと嫌なので、一旦終了。 大きなサイズのものをコピー。 再度MEGAの常駐開始。 すると、転送制限は無かったかのように同期し始めた(笑) まあ、そういう仕様なのか、チェックが甘いのか…。 クラウド側でこの後、判定がかかるのかもしれないけれど、とりあえず順調に同期して完了した。...

オプションミスで慌てた

サーバの管理をしていて クラウド上のサーバを管理するために、いつも通りsshで接続。sudoでルート権限に上がる。 さて、今回webコンテンツも触る関係上、自分ユーザをapacheグループに入れておこうと。 別段、よくやる作業なので、気楽に…。 # usermod -G apache 自分 とやってしまっていた。 正しくは、 # usermod -a -G apache 自分 でないと、まずいのだ…。でも、この作業をした時に、ユーザの追加やら、グループの変更など、色々やって最後に自分の設定をして間違えていた。 この後、webコンテンツを、/var/www/htmlにコピーして、apacheグループに入れておいて便利〜などと浮かれていた。 ログアウトして、翌日、ログのチェック等作業を行おうとコンソールからsshする。 そして、sudo -sでルートに上がる。 [ユーザ名]はsudoersのファイルにありません。 とつれない表示。??? この時点では、何が起きたかわかっていない。 ことの重大さに気付き、冷や汗を書いたのだが・・・。 行った作業 おかしいな、sudoersに無いなんて、編集していないしなと思い、確認することに。 less /etc/sudoers パーミションが無いと言われる。 そりゃそうだ。 はっ!!! 見たり編集するためにはroot権限が必要だが、root権限を得るためにはsudoが使えないといけない。 詰んだ… rootでのsshは許可していないし、変更するにはsudoが必須。→ダメ historyで昨日の作業を見なおして、chmodのミスに気づく。 じゃ、wheelにも追加してやればいいじゃん。root権限が必要→ダメ /etc/groupを書き換える?root権限が必要→ダメ 結局、自分にroot権限を付与するためには、root権限が必要なわけだが、自分からroot権限を剥奪している以上、付与できないという綺麗な循環が成り立った。 ということは、このクラウドでは、rootに上がれず、何もできないことが判明。 解決策はちゃんとあった クラウドを借りてから、ずっとsshで作業していたけれど、そういえばWEB上の...