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

カテゴリー: ITめいたこと (8ページ目 (31ページ中))

クリーンインストールしたWindows7 SP1でWindowsUpdateが始まらない。

古いノートPCが渡された。Windows10に無料でアップグレードできたというのに、アップグレードし忘れていてWindows7 HomeのままのThinkPad E130。とりあえず、HDDをSSDに換装して、USBメモリに取ってあったリカバリイメージから起動して、工場出荷状態にまでは戻すことができた。

…で、山のように積もったWindowsUpdateのパッチを適用しようと思って、一晩、WindowsUpdateを実行したままにしておいたが、いつまで経っても適用するべきパッチの検索が終わらない。とはいえ、世の中のWindows7マシンでWindowsUpdateができなくなったという話も聞かないので、結局のところ、ThinkPadの出荷時の時点のWindows7では、現在のWindowsUpdateを適用できないってことであり、何かを手動でアップデートして、まずはWindowsUpdateがフツーに走る状態にするしかないということだろう。うん、面倒くさい。

ただ、当たりもつけずにやみくもにパッチをダウンロードして、片っ端からインストールしていくのも時間の無駄っぽいので検索してみたら、以下のWebサイトを見つけた。書いてあるパッチのいくつかを入れようとしてダウンロードして実行してみたが、やはり、ローカルのパッチの検索をしているとかで、一向に終わらない。うーむ。

終わらないWindows Updateの問題を解決する(2016年9月版)

クリーンインストールしたWindows 7 SP1では、標準のWebブラウザがInternet Explorer(IE) 8になっている。IE 8では、マイクロソフトのWebサイトの閲覧に際してスクリプトの処理などに時間がかかり、システム更新準備ツールやWindows Updateクライアントのダウンロードが正常に行えないので、最初にIEを最新版にしておく。

まぁ、IEのアップデートなら、他のパッチに依存してないような気がするし、Windowsがインターネットと通信するときのモジュールとして使われているっぽいし、まず、手始めに適用してみるパッチとしてはいいかもしれないということで、IE11のインストーラーを落としてインストールしてみた。んで、先に落としておいたパッチを適用してみたが、あっさりと実行することが出来た。ローカルのパッチ(適用済みパッチ?)を検索していて先に進まないのに、IE11にして進むようになるのもどこか理解できないが、とりあえず、WindowsUpdateを実行してみようと思う。

はてさて、成功するにsiteも、失敗するにしても、いずれにせよ時間かかりそうだ…。

追記:
これまではWindowsUpdateを一晩実行してもパッチの検索が終わらなかったのに、IE11にしてからは、たった20分くらいでWindowsUpdateのアプリケーションがパッチをダウンロードし始めた。やっぱり、クリーンインストールしたら、まずはIE11にするところから始めるのがよさそうだ。…てか、IE8でもWindowsUpdateが実行されるようにしておいて欲しいところだが…いやはや。

Linodeが「Tokyo 2」を開設したようで。

ふと、Linodeのブログを見てみたら、東京に2つ目のリージョンである「Tokyo2」が開設されたようだ。Tokyo2がLinodeにとっての9番目のデータセンターになるようだ。

We are proud to announce the opening of our ninth datacenter: Tokyo 2. There has been high demand for additional Linode capacity in this region and we’re excited to open up availability.

この記事を見ている限り、Tokyo2はたっぷり帯域幅が用意されているような感じだし、特にTokyoプレミアムが載ってなさそうなのはTokyo1リージョンと同じ感じ。東京のデータセンターでメモリ2GBを搭載していながら、$10/月でインスタンスが使えるってのは、かなり安いような気がする(…となると、どこのデータセンターを借りているんだろうって辺りは、ちょっと気になる)Tokyo1と同様に早々にキャパシティが埋まってしまいそうな気がする。

ただ、Tokyo1は相変わらずキャパシティが足りていないようで、ハイパーバイザがKVMのインスタンスを起動することはできないままらしい。KVMなサーバを用意するためには、新しいサーバを設置する必要があるものの、ラックがもう一杯なんだろうなぁ。でも、Tokyo2ができたことで、Tokyo1からTokyo2にマイグレーションするユーザーがでてくれば、キャパシティに余裕が出てきて、KVMなインスタンスが使えるようになるかもしれないなぁと思いつつ。

KVMで仮想化したCentOS7の時計について

もはや完全にわかってなかった…っていうそれだけのことだけど…。

CentOS6で動いているサーバがあって、そのサーバの上で、KVMで仮想化したCentOS7を動かそうとしていて、無事にインストールできたもののCentOS7の時計がなんか変ってことでウダウダした際のメモ。

とりあえず、結論から書いちゃうと、仮想化されたCentOS7はKVMが提供するkvm-clockを参照するようになっている。んで、kvm-clockがゲストOSに提供する時刻のタイムゾーンは仮想化されたサーバごとに設定で変更することができて、ゲストOSにCentOS6を使っていた時には、JSTで提供するように設定してあって特に問題はなかったんだけど、どうやらCentOS7からはUTCで提供されることが前提になったらしい。

CentOS7の設定を帰ると、kvm-clockがUTCじゃなくて、特定のタイムゾーン(今回はJST)の時刻で提供されることを前提にすることもできるけど、そうするとWarningが出力されてしまい、まぁ、Warningだし、いっかと思いつつ、ちょっと気持ちが悪かった。そういうわけなので、KVMの設定ファイルを書き換えて、UTCでkvm-clockを出すようにすると問題なく動くようになった。

まず、CentOS7で時計回りがどうなってるかは、以下のコマンドで確認する。

# timedatectl status

表示される結果の中で「RTC in local TZ: no」となっていれば、kvm-clockはUTCで提供されるもんだと、CentOS7は思っているようですな。KVM側でkvm-clockを提供する際のタイムゾーンをどうするかは、各ドメインの設定XMLの中でこんな感じで(下記のようにすると、UTCで提供される)

CentOS6時代のまま、KVMの設定ファイルのoffsetがlocaltimeになっていると、JSTで提供されてしまうので、CentOS7の方でJSTをUTCとして扱ってしまうので、まったく違う時間を保持してしまうと。…まぁ、NTPでの同期を設定してあれば、そのうち、修正されるだろうけど、気持ち悪いし、システムの時計がすごい幅で修正されてしまうのでドキドキする。

んで、kvm-clockがUTCじゃなくて、特定のタイムゾーンの時刻で提供されることをCentOS7に教えるには、さきほどのtimedatectlコマンドを使って

# timedatectl set-local-rtc 1

って実行すれば、教えることができるけれど、

This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments.

ってビミョーなWarningが出てくる、と。

密かに想像するに、CentOS7から導入されたsystemdって、デフォルトで時刻をUTCで扱うようなので、kvm-clockをUTCであるものとして動くってのも、その絡みのなんだろうなぁ。システム内部ではUTCで持っておいて、設定に応じて、そのタイムゾーンに合わせた時刻を返すってのが、いろいろと間違いないやり方ではあるような気はするけども…(遠い目)

東京リージョンのEC2のインスタンスが値下げされるのは本当だろうか。(追記有り)

AWSブログを眺めていたら、EC2のC4インスタンスなど、特定のインスタンスタイプを対象に値下げが行われるらしい。

EC2 値下げ (C4、M4、そしてT2インスタンスで) 東京リージョンも!より:

2016年12月1日からEC2の価格を下げるアナウンスをできることを非常に嬉しく思っています。これで皆さんの年末シーズンがすこし楽しくなることでしょう!我々の技術に対する投資と、規模と長年のキャパシティ管理の経験に基いて、コストを抑えることができることになりましたので、皆さんにお伝えします。

まぁ、私の場合、検証用のサーバはだいたいt2インスタンスで起動しているし、本番用のサーバもC4インスタンスを使っているので、これはありがたい話ではあるんだけど、ちょっと気になることがあった。

そもそも、このブログは、AWSのChief EvangelistのJeff Barrさんが英語で書いたモノを、日本のアマゾンウェブサービスジャパン株式会社の中の人が日本語に訳しているモノのはず。しかし、今回の記事は微妙に原文と日本語訳の内容が異なる点があった。

そもそも英語で書かれた記事の方では、C4インスタンスの値下げ対象について、こういう書き方になっている。

C4 – Reductions of up to 5% in US East (Northern Virginia) and EU (Ireland) and 20% in Asia Pacific (Mumbai) and Asia Pacific (Singapore).

んで、これを日本語訳するとこうなっている。

C4 – アメリカ東部(北部バージニア)とEU(アイルランド)とアジア太平洋(東京)で5%削減、アジア太平洋(ムンバイ)とアジア太平洋(シンガポール)では20%削減

原文の方では東京に関する記載がないにも関わらず、日本語訳の方には東京に関する記載があるという状況だ。

もちろん、冒頭に「For example:」と記載されているから全てを記載しているわけではないだろうし、実際の値下げが行われると料金表も改訂されるから、そこで全てが明らかになるんだろうとは思うけれど。ぱっと見た感じ、東京リージョンのEC2は本当に値下げされるんだろうか、とちょっと不安になった。

例えばだが、原文の日本語訳は日本語訳として記載してもらって、日本語版を読んでいる人達の中には東京リージョンを使っている人が多いので、東京リージョンの値下げのことも紹介したいというのであれば、日本語訳の後に、訳者による追記のような形で、東京リージョンでも値下げ予定があることを記載してもらえると少しは安心できるような気がする。

追記:
改めて、該当の記事を確認してみたら、原文には記載がないものの、東京リージョンにおいても値下げが行われる旨が追記されていた。追記、ありがとうございました>AWSのなかの人。

※訳注: 原文には東京リージョンへの言及が特別にありませんが、今回の値下げは全てのリージョンが対象のため、東京リージョンの価格変更情報も追記しています。

サンディスク SSD Dashboardの自動アップデートが失敗

自宅のPCには、秋葉原で安売りされてたサンディスクのSSDのUltraIIを使っていて、SSDのステータスを見たり、SSDのファームウェアのアップデートのチェックと更新ができたりする「サンディスク SSD Dashboard」をインストールしてある。このツールからTrimをかけることもできるので、たまーに起動してSSDの様子を眺めているのだが、今回は「サンディスク SSD Dashboard」自体のアップデートがリリースされているという表示が出ていた。

とりあえず、何にも考えずにアップデートを実行。裏でインストーラーをダウンロードしているようで、「OK」を押したらインストールが始まるというダイアログが出たので、そっと「OK」。インストーラーが旧バージョンを削除して…新バージョンのインストールに失敗。そして、「サンディスク SSD Dashboard」はいなくなった(遠い目)

ヲイヲイということで、サンディスクのWebサイトから、手動でインストーラーをダウンロードしてインストールしたんだけど、Webに載ってるリリースノートが古くて、ダウンロードできる新バージョンに関する記述がない。きっと、英語版なんかではリリースノートが用意されているんだけど、日本語へのローカライズが間に合ってないとかなんだろう。

まぁ、マウスやキーボードと違って、モノがSSDなんで、それなりの信頼性を期待したいなぁというか、きっとSSD自体の信頼性は高いのかもしれないけれど、ユーザーとしてそれを実感できる機会はほぼない(うっかり壊れた時に、あーってなって、なんとなくの信頼感が失われるくらい)ので、こういう周辺ソフトウェアがしっかりしててほしいなぁと思う。

GoogleMaps APIの課金が始まったか…

Googleからメールが来ていた。

On October 12, 2016 we will begin enforcing the Google Maps APIs Standard Plan policy updates that were announced in June. Starting October 12th, your website will generate charges if requesting more than 25,000 daily map loads for an API.

雑に訳すと、こんな感じだろうか。

2016年の10月12日から、Google Maps API Standard Planのポリシーの更新を強制します。この更新自体は6月にアナウンスしたものです。10月12日以降は、1日あたり25,000回を越えたリクエストについては課金されます。

というわけで、一日あたり25,000回を越えたAPIの呼び出しについては、1000回あたり$0.5の課金が行われるようですな。…というか、これを強制するってコトは、APIキーを付けていない呼び出しはブロックされるってことだろうなぁ。Googleが細かい制御をどこまでやるかはわからないけれど、APIの呼び出し回数は無料の範囲内で収まっていても、APIキーを貼ってなくて、GoogleMapが表示されないってことが普通に起こりそうな予感…(遠い目)

Amazon Linux AMI 2016.09がリリースされた

商用環境のAmazon Linuxのアップデートを適用した翌日の今日、Amazon Linux AMI 2016.09がリリースされた…。まぁ、リリースされたてのものにアップデートするかどうかはあるとしても…むむむ。

Amazon Linux AMI 2016.09 Release Notes

リリースノートをざっと読んでみたが、BTRFSで管理されているソフトウェアRAIDを使っていると、起動時に自動マウントされないってあたりはなかなか切ないけれど、BTRFSは使ってないから、まぁ、いっか。んで、後は、Linuxカーネルが4.4.19になった(追記:後で調べて見たら、2016.03も4.4.19だった。あれ?)ってのも、まぁ、いっか。yumレポジトリに入ってるPHPが7も使えるようになったようで。これも、まぁ、いっか。

ちょっと興味深いのは、ブート時の性能を改善したようで、SSHできるようになるまでの時間が短縮されたようで。簡単なベンチマークが載ってたけど、c4.largeインスタンスで2016.03と2016.09で比較すると7秒くらい早く起動するようになったらしい。まぁ、たいしたことじゃないけど、再起動かけた後、ちょっとドキドキしながら待つ時間が短くなるのは悪いことではないと思う。

あと、nginxやPHPが新しいバージョンに入れ替えられる中で、jdk1.6.0やtomcat6が削除されたようで。

昨日、やったばかりではあるけれど、そのうち、またスケジュール組んでアップデートの準備をするかな…(遠い目)

KB3189866のせいで、WindowsUpdateが終わらない

手許のWindows10マシンでWindowsUpdateでパッチが見つかったのでインストールしようとしたら、ファイルのダウンロードの進捗が45%で止まったまま、進まなくなった。再起動してもダメ、シャットダウンしてみてもダメ(やってることは実質的に同じだけど)。

問題のパッチは「x64ベースシステム用のWindows 10 ver 1607の累積的な更新プログラム(KB3189866)」というモノ。んで、調べて見ると、以下の記事が見つかった。

Windows Updateに不具合? 「KB3189866」のダウンロードが終わらないとの報告が多数あがる

まぁ、要するに「KB3189866」には何らかの問題があるのだが、Microsoftとしてはまだ原因が掴めていないようで、とりあえずWindowsUpdate経由ではなく、MicrosoftUpdateカタログからパッチをダウンロードすればパッチをあてられると言うことのようだ。

しかし、Microsoft Updateカタログにアクセスするためには、古式ゆかしいInternet Explorerが必要。つまり、Edgeじゃダメっぽい。しかも、Firefoxでアクセスしたら、SSLの警告が出た。Microsoft独自のRootCAの証明書なんだろうか。まぁ、Internet Explorerならではの、Windowsと密接にくっついた仕組みでMicrosoft Updateカタログにアクセスさせたいのはわかるんだけどなぁ。SSL証明書くらい、誰にでも使える証明書を使ってもバチは当たんないんじゃないかと思うけども。

…と思ってたら、MicrosoftのTwitterアカウントが対処法をtweetしてた。やはり、Microsoft Updateカタログを使ってダウンロードをするようだ。

とりあえず、IEを探し出して起動してMicrosoft Updateカタログにアクセス。んで、「KB3189866」を検索すると、WindowsServer向けのパッチと、Windows10の32bitと64bit向けのパッチの3つが見つかる。対象のマシンはWindows10の64bitマシンなので、それ用のパッチをダウンロードして実行してみた。Windows Updateの方は相変わらずダウンロード途中ではあったが埒があかないので、そのまま実行することにした。インストールに多少時間はかかったものの、無事、再起動して、パッチの適用に成功したようだ。今のところ、普通に動いている。

postfixのログをサマリーするにはpflogsummだけど。

Postfixでメールをホイホイ投げるようなサーバだと、postfixが吐き出すmaillogを見やすくまとめてもらって、たまーに眺められるようにしておくのがいいかなぁと思う。んで、ちょっと調べて見たら、pflogsummというPerlで書かれたスクリプトにmaillogを食わせると、ログのサマリーを作ってくれるらしい。

CentOSのyumレポジトリにもあるらしいのだが、先人達のブログを読むと

# yum -y install postfix-pflogsumm

でインストールできるとのことだが、「postfix-pflogsumm」というパッケージが見当たらない。収録されなくなったか、名前が変わったかのどちらかだろうなぁと思いつつ、yum search postfixを実行してみると、「postfix-perl-scripts」っていうパッケージが見つかった。んで、yum info postfix-perl-scriptsを実行してみると、説明の1行目にこんな記載があった。

This package contains perl scripts pflogsumm and qshape.

qshapeっていう、キューの状態を確認できるPerlスクリプトと同じパッケージにまとめられたような感じだろうか。というわけで、「postfix-perl-scripts」をインストールすると、pflogsummが使えるようになった。

MacのOfficeのアップデートでCompile Error

Office365をMacで使っている。昨日だったか一昨日だったかに、アップデートが降ってきた。その際に、64bitなOffice 2016に入れ替えられたらしい。

その後、Excelを起動する度に、なにやら「Compile Error」ってメッセージが出てくるようになった。Excel自体は起動しているものの、セルをいじる度にエラーメッセージが出てきて使い物にならない。

いろいろと調べて見たところ、Mac向けのOffce自体は64bit化されたものの、インストールしてあるアドインが64bit対応していないと何やらエラーが出るらしく。個人的にはOfficeにアドインなんか入れた覚えがないのだが…と思って調べてみたら、ATOK Passportをインストール際に一緒に入れたっぽい、「Office連携ツール」なるアドインがいることがわかった。Excelから「Office連携ツール」の中のアイコンをクリックしても何の反応もなく、動いてなさそうなことからして、まぁ、これだろうなということで。

ワークアラウンドとしては、Office連携ツールが64bitのOfficeに対応してアップデートされるのを待つ(…ワークアラウンドになってないか…)か、Office連携ツールを削除するかのどちらかだろう。ということで、Office連携ツールの存在を意識してなかったくらいなので、後者を選択しようとしたけれど、Officeのアドインのアンインストールの仕方がピンと来ない。Excelの環境設定を眺めてみたけど、アドインの追加をできそうな画面はあったけど、アンインストールはできなさそうだった。

調べてみたら、「Mac Office 2016連携ツール for ATOK 2015」のインストーラーにアンインストール機能があるようだったので、インストーラーをダウンロードして、アンインストールしてみたら(笑)、無事にOffice連携ツールをアンインストールできた。その後、Excelを起動してみると「Compile Error」が出なくなり、何事もなく動くようになった。

MacでOffce365と、Atok Passportの両方を使っている人って少ないのかどうかはわからないけれど、Atokのサイトを覗いてみても、Officeの64bit化に伴って、Office連携ツールが64bit未対応でエラーが出るって情報も出してなかったので、アップデートには時間かかるかもしれないなぁ。

« Older posts Newer posts »