ただつらつらと日記が書かれていくようです。

投稿者: 管理人 (1ページ目 (39ページ中))

さくらのクラウドのCPUガチャ

さくらインターネットのさくらのクラウドで動いているインスタンスについて、さくらインターネットからメンテナンスを実施する旨の連絡が届いた。とある日までに、当該インスタンスを停止→起動(再起動ではなく)すれば、さくらインターネットが実施する強制的な停止→起動を回避できるとのこと。まぁ、どうせやらなきゃいけないのであれば、ある日、突然、停止→起動されるよりは、調整した上でタイミングを見計らって実施したいところ、ってことで停止→起動を実施してみたら、インスタンスのCPUが変わっていた。
続きを読む

WF-1000XM4をSONYに修理に出してみた

SONYの完全ワイヤレスイヤホンのWF-1000XM4を使っていたのだが、購入してから1年くらい経ったあたりから不自然に右イヤホンのバッテリーのバッテリーの減り方が激しくなったような気がした。言い換えると、バッテリー残量が著しく減ってるような、そんな印象だった。
続きを読む

さくらインターネットのNTPサーバ「ntp1.sakura.ad.jp」ってleap smearしてたのか。

うるう秒は避けられないとしても、それをいかにしておおごとにしないかはなかなか重要なことな気がする。まぁ、そういう観点ではleap smearすることによってなんとかするのも1つではあるけれど、やっかいなことにleap smearしないNTPサーバとleap smearするサーバを混ぜて参照するのは止めた方がよさそうだ(まぁ、普通に混乱するだろうな)

…だがしかし、publicなNTPサーバのうち、leap smearしてるかどうかを明記してるNTPサーバってそんなに数多くない気がする。まぁ、書いてなきゃleap smearしてないんだなくらいの理解でもいいんだろうけれど。
続きを読む

ThinkCentre M720q(Coffee Lake)にRocky Linux8.6をインストールしたら時計がズレまくった。

中古で買ってきたThinkCentre M720q TinyにRocky Linux8.6をインストールした。搭載しているCPUはCore i5-8500Tなので、第8世代のCore i5であり、開発時のコードネームはCoffee Lake。

インストール自体はすんなり終わったけど、よく見てると、まぁ、時計がズレまくっている。timedatectlコマンドの結果を確認してみると、NTPで調整してみても、結果的にRTC time(リアルタイムクロック)の時刻がすさまじい勢いで進んでしまうので、chronydが同期をあきらめてしまうようなレベルでズレていた。
続きを読む

Amazon Linux 2022がなかなかGAにならないと思ったら、Amazon Linux2のEOLが延長された。

Amazon Linux2022のことが発表されて、しばらくプレビュー版のまま。なかなかGAにならないなぁと思ってはいたけれど、もう7月。2022年の半分が終わってしまったことになる。いっそ、Amazon Linux2023くらいにしておいた方がよかったんじゃないかなぁーと無邪気に思ってたら、Amazon Linux2のEOLが延期されてた。延長されたEOLは2024年6月30日。

そっと、Amazon Linux2のFAQページが更新されてるのが興味深い。

AmazonLinux2のEOLが2024年6月30日に1年間延長

AmazonLinux2のEOLが2024年6月30日に1年間延長

PHP8.0を動かすインスタンスを構築しようと思っていて、Amazon Linux2022を待っていたけれど、結局、PHP8.0のEOLが2023年11月26日なのでPHP8.0のEOLの方がAmazon Linux2よりも早くEOLを迎えることになるので、まぁ、なかなかGAにならないAmazon Linux2022を待つよりもAmazon Linux2で構築しちゃおうか。

さくらのクラウドのディスクのクローンで「待機中」

さくらのクラウドで、サーバーをクローンするためにディスクをクローンしようとしているけど、「待機中」のステータスになって、いっこうにディスクのコピーが進捗するする気配がない。ディスクのコピーは常にインスタンスからアクセスされているストレージ(SANだったっけ)のリソース(帯域幅やCPU)をがっつり使うことになるので、コピーの優先度を上げるわけにはいかないだろう。例えば、複数のユーザーからのディスクコピーのリクエストがパラレルに走らないような制御がなされているんだろうけど…。

例えば、ヤバい!って事態に陥って、急遽、サーバをクローンしようとしてこの状況に直面すると切ないだろうな…と思いながら、まったく進まないプログレスバーを眺めてみたりして。

しかし、AWSだとこういう待ち時間がなかったような気がするんだけどなぁ。インスタンスを起動するときにはAMIの裏側のS3からEBSにがっつりデータをコピーしているはずだし、サーバのクローンをする時にもEBSとS3の間でゴリゴリとデータをコピーしているはずだけど、特にちょっと待ってってステータスになっているのは見たことがない気がする。まぁ、さくらのクラウドがショボいというか、むしろ、AWSのEBS周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。

UQ mobileのデータ高速プランを解約してみた。

以前に契約して中途半端にしか使っていなかったUQ mobileのデータ高速プランを解約することにした。

まぁ、データ高速プランはUQ mobileがMVNOっぽいSIMの売り方をしていた時の料金プランで、UQ mobileがKDDIにおけるY!モバイルっぽい立ち位置に移行してからは新規申込みを止めたプラン。今は音声契約が必須になっているので、まぁ、MNOの契約であるにも関わらず、データ専用で(SMSは付いてるけど)3GBで990円というプランは今となっては珍しいと言えるかもしれない。

いざ解約するべく調べてみたら、UQ mobileの解約はコールセンターへの電話のみという…まぁ、今時、なんだかなぁという印象。例えば、Webサイト屋auショップでも解約を受けてくれればいいのに、解約の窓口が電話しか用意しないことで解約のハードルを上げるっていうのはなかなかイケてない気がするけどな。

そして、UQ mobileのWebサイトには「必ず、契約者ご本人さまが、解約をするスマートフォン/携帯電話本体から、電話番号の前に186を付けるなどの方法で携帯電話番号を通知してお電話ください。」と書かれていたが、データ専用プランなので音声の発信ができない。データ通信専用のデータ高速プランなんて忘れられているんだろうな…。いやはや、音声通話できるドコモのSIMが入ったスマホから電話した。

というわけで、UQ mobileのコールセンターに電話したのは日曜日の13時ちょっと前。自動音声応答システムでメニューを選択する方式だった。そして、解約する電話番号と暗証番号を電話機のダイヤルパッドから入力。その後が長かった。オペレーターさんに電話がつながるまでに保留された時間がざっと30分。途中で、このまま待つか、かけ直すような案内もなされるが、休日なんてずっと混み合ってるんだろうし、コールセンターへの電話しか解約窓口を用意してぐったりするくらい保留されて解約を断念してしまったら、解約のハードルを上げてなんとかしようとするKDDIの思うつぼだし。

30分くらい保留音を聞き続けてオペレーターさんにつながった後は早かった。解約にあたっての注意事項が告げられて、それを確認して終了。MVNOなんかはWebで解約を受けてるわけだし、Webでも実現できるとしか思えないやりとりであった。総務省や公正取引委員会はこういうあたりもチェックすべきだと思うんだけどなぁ…。

MySQL5.7をyumでアップデートしようとしたらコケた

CentOS7が動いているサーバにMySQL5.7をOracleのレポジトリからyumでrpmを取得する形でインストールしてあったのだが、そのサーバでyum updateをかけたら、yumがエラーで止まった。

The GPG keys listed for the “MySQL 5.7 Community Server” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

…GPGが何やらおかしいとのこと。で、調べてみると、以前よりOracleのレポジトリで使っていたPGPキー、CentOS7だと/etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlに置かれることになる、この鍵は有効期限が2022年2月16日までだったそうで、新しい鍵に切り替えられたらしい。

そんなわけで、古い鍵ではアップデートが出来なくなったようだ。だったら、新しい鍵をインポートしちゃえばいいってことで。

sudo rpm –import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

を実行すれば、今のレポジトリで使われている鍵がインポートされるので、yumのアップデートが普通に実行されるとのこと。

ただまぁ、前から2022年2月までの有効期限だったはずだけど、極めて最近になって発覚して、急遽、GPG鍵が新しいものになったようで…。

参考:
The MySQL GPG key seems to be incorrect
https://bugs.mysql.com/bug.php?id=106188

Changes in MySQL 8.0.28 (2022-01-18, General Availability)
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-packaging

« Older posts