ただのにっき。

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

8ページ目 (40ページ中)

Raspberry PiのRaspbian JessieでIPを固定できなくて困った。

一昔前のRaspberryPi Zeroを引っ張り出してきた。んで、microSDを刺して、さらに、いろんなものをUSB経由で刺してなんとかRaspbian Jessieをインストールして起動することができた。一昔前のUSB Ethernetアダプタ(IOデータの「ETG-US2」。Windows向けのデバイスドライバはWindows10でリリースされてないような感じ。一応、「ASIX AX88178」を使っているとして認識されている)が無事に認識されたところで、IPアドレスを固定したいと思った。

んで、最近のRaspbianでIPアドレスを固定したい場合は、dhcp周りの設定ファイルをいじるってことでいじりはじめたものの一向にIPアドレスが固定されずに、ネットワーク上にいるDHCPサーバからIPを取ってしまう(遠い目)

ふとした瞬間、いじるファイルが間違っていることに気付くまで必死に、/etc/dhcpd.confをいじっていたけど、これはRaspberry PiがDHCPサーバとして動くときの設定ファイル。dhcpクライアントとして動作するときのファイルに固定IPを記載すべきだったのだ。んで、そのファイル名が/etc/dhcpcd.conf。ま、ややこしいといえばややこしいが、違うと言えば確かに違う。dhcpcd.confに設定を追記して再起動したら、無事にIPが固定された。

…いやはや、年中こんなことばかりやってる気がする(遠い目)

LinodeのTokyo2でインスタンスを立ててみたら

ふむ、Tokyo2のサーバはBroadwellなXeonであったか。…ま、実はいろんな世代の物理サーバが混じっていて、たまたまBroadwellなXeonだった可能性は否定しきれないんだけども。

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz
stepping : 1
microcode : 0x1
cpu MHz : 2299.994
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
bugs :
bogomips : 4601.65
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual

いつの間にか、GoogleのPublic NTPがstratum1になってた。

ちょっと前、GoogleがPublic DNSに加えて、Google Public NTPをリリースしていた。しばらくの間はtime1.google.com
などはstratum2のサーバとして動いていたと思うが、さっき確認したら、stratum1のサーバ群になってた。

日本国内のLinuxマシンから、time4.google.comを指定してntpdを動かした時の、ntpq -pの結果がこんな感じ。

remote refid st t when poll reach delay offset jitter
==============================================================================
time4.google.co .GOOG. 1 u 5 64 1 35.928 -0.607 0.000

ソースの「.GOOG.」ってなんだろうって感じではあるが、一応、stratum1らしい。ネットワークのdelay的には、台湾あたりのサーバっぽいなという感じだけど、はてさて。

そういえば、EC2のC5インスタンスって。

AWSのEC2のC4インスタンスのリザーブドインスタンスの有効期限を確認していて、ふと思い出したんだけども…。

去年の12月1日の「AWS re:Invent 2016」でSkylakeコアを使ったXeonを搭載したC5インスタンスのリリースが発表されてたはずだけども…。発表から半年近く経過した今でもC5インスタンスがリリースされていない。同時に発表されたF1インスタンス、R4インスタンスやt2.xlargeなどはリリースされているだけどなぁ。

C5インスタンスとC4インスタンスを比較すると、シンプルにHaswellコアのXeonを、SkyLakeコアのXeonでリプレースしただけのように見えなくもないだけに、なんでだろう。

んで、ちょっと調べてみたら、SkylakeなXeonのE5シリーズE7シリーズってまだ出荷されてなかった。で、いつ頃に登場するかってことについては、

2017年のサーバープロセッサ動向・Intel編:
http://cloud.watch.impress.co.jp/docs/column/virtual/1041290.html

って記事に

Xeon E5 v5、Xeon E7 v5のリリーススケジュールは、2016年11月に米国で開催されたSuperComputing 16(SC16)において、2017年中盤と発表された

って書かれていた。まぁ、具体的な日程まではわからないけれど、もうちょっとするとSkylakeなXeonがリリースされそうってことか。ただ、EC2向けのXeonはAWS専用のカスタマイズ品だろうから、一般的なXeonの出荷と比べると、AWS向けの出荷はもう少し遅くなるのかもしれない。

ま、とりあえずC4インスタンスのリザーブドインスタンスを買っとくか。

追記:
2018年2月に、C5インスタンスが利用可能なリージョンが拡大されたけれど…。

  • 米国東部 (オハイオ)
  • アジアパシフィック (ムンバイ)
  • アジアパシフィック (シドニー)
  • カナダ (中部)

東京リージョン含まれず…orz

追記:TokyoリージョンでもC5インスタンスが利用可能になりました。

Windows7のスリープ失敗がまるでハード障害

古い自作PCにWindows7Proでもインストールしておいて、リモートデスクトップで使おうと思って、粛々とインストールを完了。

とりあえず、LAN越しにアクセスできるようにIPアドレスを固定して、Windows7側でリモートデスクトップの接続を許可。はてさて、うまくいくか不安になりながらMacでリモートデスクトップクライアントを起動。…無事に接続完了。

まー、これでMacからWindows7を使えるようになって、多少便利になるかなーと思って、しばらく放っておいたら、リモートデスクトップがつながらなくなっていた。しかも、ケースの電源ランプは何秒に一回か点灯しては消えるという状態だし、電源ランプが点いたタイミングでケースファンが少し回って止まるということを繰り返していた。

このPC、マザーボードがIntelのDH57JGだったから、かなり古い。インストールしたばかりなのに壊れたかーと思って遠い目になった。しかも、電源ボタン長押しも効かない…。仕方ないので電源ケーブルを引っこ抜き、ため息をひとつ。

ま、試しにってことで、再びケーブルをつないで電源をon。…うっかり普通に起動してしまった。

じゃ、さっきのアレはなんだったんだろうと思って、しばらく放置してみたら、また息も絶え絶えな状況に陥って電源ケーブルを引っこ抜くというのを2回繰り返して、ふと気づいた。このPC、起動して30分近く経ったら前後不覚になってないか…と。

…というわけで、このPCは起動して30分近く経って、律儀にスリープに入ろうとするものの、BIOSか何かのバグを踏んでるのか、スリープに入れずに前後不覚に陥ってるんじゃないかと仮説を立てて、そっとスリープに入らないように設定したら、前後不覚状況を回避できた。

いやはや、古いPCではあるけど、スリープできないってのもなかなかアレだなーと。とりあえずハードウェア障害ではないから、一安心。…でも、いつまで動いてくれるんだろうか…(遠い目)

…いつの間にかSSL証明書が失効してたので、Let’s Encrypt

このブログで使ってるドメイン向けに安いSSL証明書がいつの間にか失効してた…。なんか更新のお知らせのメールが来てたような気がするけど、更新忘れてた(大汗)

SSL証明書を更新しなきゃと思ったけど、このサーバーにはcertbotをインストールしてあるし、systemdで更新プロセスも動いてることだし…ということでLet’s EncryptなSSL証明書を取得して入れ替えた。

自動更新の仕組みさえ、ちゃんと動いてるなら、expireすることもないし…意外と悪くないかもしれない。

文化庁のWebサイトのメンテナンス

先日、文化庁のWebサイトが見られなくなってるのがネットで話題になっていた。ネットで話題になるってことは、誰も文化庁のWebサイトでメンテナンスをやっているという情報を見つけられなかったわけで、まぁ、メンテナンスでダウンするWebサイトにしかメンテナンスのお知らせが出てなかったってことだろうか。

まぁ、文化庁は文部科学省の外局なんだし、文部科学省のWebサイトで文化庁のWebサイトのメンテナンス情報を出しておくとか、なにかできなかったんだろうかと思う。それに、内閣官房とか総務省あたりが、官公庁のWebサイトのステータスを監視、お知らせするためのWeb(正常に稼働してます、メンテやってます、DDoS食らってますとか)を用意してても罰は当たらないような気もするが、そこは縦割りの権化みたいな世界だと、そうもいかないんだろう。

さて、そんな文化庁のWebサイトだが、気がついたら復旧してた。トップページの上部に、赤い文字でフォントサイズ大きめに「文化庁ホームページメンテナンスのお知らせ」というリンクが表示されていて、そのリンクの先には、こんな情報。まぁ、年末年始はメンテナンスやりますよってことがお知らせされていた。

平成28年12月28日(水)18:15から平成29年1月3日(火)23:00まで
(メンテナンス作業状況により,終了時間が前後する可能性があります。)

落ちてたサイトが復帰したってことは、メンテナンスの一部は完了したわけで、何が変わったんだろうと思ってnetcraftで調べてみると、メンテナンス以前(といっても、2016年6月の記録だが)はWindowsのIISがWebサーバで、その前にCitrixのNetscalerが控えていたような感じだが、メンテナンス完了後にはクラウド型WAFの「Scutum」が導入されたようだし、インターネットから見えるIPアドレスもIIJのもの(ってことは、ScutumはIIJのクラウドで動いてるってことか)に変わっていた。今回のメンテナンスの一部は、WAFの導入だったんだろう。

しかし、クラウド型WAFを導入するとなると、確かにDNSをいじる必要が出てくるとは言え、ネットがざわざわするくらいの期間、サイトを見えなくする必要があったのかはよくわかんない。例えば、DNSはWAFに向けつつも、DNSのキャッシュがなかなか更新されない人向けに、直接のアクセスをしばらくの間は許可しておいて、さすがにもういいだろうってタイミングで直接のアクセスを遮断するってのも移行パターンとしてはありかもしれないし。

ふと、文化庁のWebサイトくらいでしか、メンテのお知らせが出てなかったことを思い出すと、実はメンテナンス計画上は停止なしか、止まっても、わずかな期間で済むはずだったにも関わらず、メンテナンス中に予期せぬことが起こって、想定外に止まっちゃったんじゃないかという下衆の勘繰りをしてみたが、実際はどうなんだろうか(笑)

クリーンインストールした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で持っておいて、設定に応じて、そのタイムゾーンに合わせた時刻を返すってのが、いろいろと間違いないやり方ではあるような気はするけども…(遠い目)

«過去の 投稿 新しい 投稿 »