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

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

AmazonLinuxでsendmailをpostfixに入れ替える…けど、依存パッケージはそのままで。

なぜか、Amazon LiunxのデフォルトのMTAはSendmail。ま、ベースとなっているRHELのデフォルトのMTAがSendmailだからなんだろうな、いやはや。最近はPostfixしか使っていないので、AmazonLinuxでサーバを構築する際は、まずはsendmailをアンインストールして、Postfixに入れ替えるという作業を行うことになる。

AmazonLinuxのサーバをオフィシャルなAMIから構築する場合には、sudo yum remove sendmailでsendmailをアンインストールして、sudo yum install postfixすれば、MTAの交換ができてしまうのだが、sendmailに依存するパッケージに「crontabs.noarch」があったりするのがちょっと…。ま、postfixを入れた後、再インストールすればいいわけだけど、うっかりわすれるとcronが動かなかったりする。「このサーバではログのローテーションが実行されないなー、不思議だなー」とか思っていると、MTA入れ替え後の「crontabs.noarch」の再インストールを忘れているってことがある(遠い目)

…で、こちらの記事「yumで複雑に依存しあった複数のパッケージを入れ替える」によると、yumはsendmailのアンインストールとpostfixのインストールを1つのトランザクションとして依存性を解決することができるらしい。

まずは、yumのシェルを起動。削除したいものとインストールしたいものを指定。その後、依存性の解決を行った後、で、そのトランザクションを実行という流れらしい。

sudo yum shell

remove (パッケージ名)
install (パッケージ名)
transaction solve
transaction run

試しに、sendmailをremoveして、postfixをinstallしてトランザクションの依存性を解決してみたが、sendmailに依存しているcrontabsなどは削除されることなく、そっとsendmailがアンインストールされ、postfixが必要とするmysql55-libとspostgresql92-libsと一緒にpostfixがインストールされた。

…って、これはAmazonLinuxに限ったことではなく、yumが使えるRHEL系のLinuxなら同じ事ができますね、はい。

zabbix-proxy-mysqlをrpmでインストールしたときのスキーマの置き場所

zabbix-proxyをrpmでインストールした際に、zabbix-proxy用のMySQLにテーブルを作るためのSQLがいつもどこに置かれているのか分からなくなる。もう少し、proxyをインストールする機会があればいいけれど、そうもいかない。

というわけで、備忘のためにメモ。インストールした環境はAmazonLinux 2017.03。

/usr/share/doc/zabbix-proxy-mysql-2.2.18/create

…あ、そういえば、そろそろzabbixのバージョンも上げなきゃなぁ…。

VPCの中で既存のNICを使ってインスタンスを起動しようとするとpublic IPがもらえない…

EC2のインスタンスを起動するときに、VPCで既に設定してあるNICを使って起動しようとすると、ちょっと前は、そんなNICにもpublic IPが割り当てられてたような気がするんだけど…。さっき、既存のNICを使って起動としたら、以下のようなメッセージが出てきた。

We can no longer assign a public IP address to your instance

The auto-assign public IP address feature for this instance is disabled because you have selected an existing network interface for eth0. Public IPs can only be assigned to new network interfaces for eth0. To re-enable the auto-assign public IP address feature, please select a new network interface for eth0.

既存のNICはVPCのIPアドレスを固定するものだったので、それはそれとして割り当てて、public IPアドレスを付けたい場合は素直にElastic IPを使えってことだろうか。

追記:
ENIのNICを使うとPublic IPが割り当てられずに「…なんでだろう…」と悩み続けていた。VPCの「Auto-assign Public IP」もYesに変更したのになぁ…。で、仕方ないからNATインスタンスでも立てるかと思って、t2.microインスタンスを立ててiptablesの設定もして…最後にVPCの「Route Tables」を更新してインスタンスを起動してみると、Public IPが割り当てられた状態で起動してきた。結局、WebからのVPCの設定変更では変更が反映されなくて、「Auto-assign Public IP」がnoのままで、「Route Tables」を変更したタイミングで「Auto-assign Public IP」がYesに変わったような…なんか妙な感じしかしないけど、とりあえずPublic IPが割り当てられた…。んで、NATインスタンスを落として、VPCの「Route Tables」を元に戻した。

Linodeの「Tokyo2」は品川なのか。

久々にLinodeのステータスページを眺めていたら、Tokyo2リージョンのコアルーターのメンテナンス情報が出ていたのを見つけた。

On Thursday, June 15th, 2017 we will be performing a code upgrade on our core network devices in our Tokyo 2 (Shinagawa, SHG1) data center.

Tokyo2として記載されているものの、括弧書きで「Shinagawa, SHG1」と書かれている。ってことは、品川にあるデータセンターに入っているんだろうな、ってことで。品川のデータセンターか…ってことは…といろいろと妄想してみたが、品川区だとすると割といろいろありそうな気がするな(笑)

Microsoft Azureの試用をしようとしたら

たまには、Azureでも試用してみようかと思って、Microsoftアカウント…というか、outlook.jpなメールアドレスを作成して、サインアップしたんだが、Azureの管理画面が重い。Office365のポータルもそうなんだけど、Microsoftのサービスの管理画面のレスポンスが遅い時のどうしようもない感じ、それも、とてもWebのレスポンスじゃないくらいのながーい待ち時間はなんなんだろうか。うーむ、AWSの方がいいな。

しかも、試用用のサブスクリプションを作成しようとしら、いきなりエラー。試用サブスクリプションもないのに、いきなりサポートのお世話になることになった。この時点で試用する気分じゃなくなって来てるんだけど、どうしたものか、いやはや。

追記:
とりあえず、サポートに投げてみたら電話がかかってきた。しかも、何回も取れなかったのに、諦めることなくかけてくれて、やっと出たら、とても丁寧な対応をいただいた。やはり、まー、この辺の電話サポートって辺りがAWSなんかとの差別化のための施策なんだろうなぁと思ってみたり。

GoogleBookmarksでリダイレクトの嵐

GoogleBookmarksにとあるサイトのURLを入れていて、アクセスしようとしたらリダイレクトの嵐…。うーむ、Googleにはログインしてあるのになんか変だなー。

めまぐるしく、くるくる変わるURLを眺めていると、sidというパラメータをどうにかしようとしているようで…。というわけで、ブラウザのCookieの管理画面を引っ張り出して、google.comのCookieの中で「SID」ってパラメータがあったので、それを削除。改めて、Google Bookmarksにアクセスすると無事にアクセスできた。なんとなーくバグっぽい動きをしているあたり、最近のGoogleでは珍しい気もするけど、とりあえず回避できたからいいや。

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インスタンスが利用可能になりました。

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