ただのにっき。

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

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

Buffaloの「BSKBU13」は予想以上にコンパクトだった(汗)

2015年11月25日 / / 0件のコメント

自宅ではレノボのThinkPadキーボードを愛用していたのだが、気がついたらEnterキーの辺りがおかしくなってしまった。具体的には、Enterキーを押下しても数回に一回くらいの頻度でしか効いてくれないという、なかなか切ない状況。というわけで、代替キーボードを探してみたのだが、とりあえず小さいものであればいいやってことで、Amazonで安売りしていたこともあってBuffaloの「BSKBU13」を買ってみた。

…届いてみると、確かにコンパクトなのだが、キーピッチ(キートップのサイズ)が小さすぎた。普通の…というか、よく見るキーボードは19mmちかくだが、「BSKBU13」は17mm。単純に小さい。普通のキートップのサイズになれてしまっているとどうも打ち間違えてしまう(まぁ、慣れでなんとかなる世界はかなりあるんだろうとは思うけど…)

あと、なかなかツラいのはEnterキーが小さい。どうしてもコンパクトキーボードは無理矢理に詰め込んでいるので、必然的にしわ寄せはフツーのキーボードだと割と大きなEnterキーに来てしまう。要するにEnterキーが小さいのだ。Enterキーが小さいとどうなるかというと、本人はEnterキーを押下しているつもりなのだが、気がついたら閉じかっこ(」)を入力してしまっていることが多い。TeraTermだと、コマンドを入力して実行するつもりでブラケットを入力してしまうことになるので、これはなかなか切ない。

こればっかりはちゃんと確認しなかった私が悪いので、「BSKBU13」のことはすぱっと忘れることにして、次はサンワサプライの「SKB-SL18BK」を試してみることにした(これもAmazonde安く販売されているので、なかなかドキドキするけれど…)キーピッチも19mmだし、多少はEnterキーも大きそうだ。はてさて、私のキーボードはどうなることやら。ただ、買い直して、結局、2台のキーボードを買うことになっても、総額ではレノボのThinkPadキーボードを買うよりは安く上がりそうなので、サンワサプライの「SKB-SL18BK」がイイ感じなら良しとしたい。

[amazonjs asin=”B013D22XN8″ locale=”JP” title=”iBUFFALO 有線コンパクト&スリムキーボード ブラック BSKBU13BK”]

CentOS7のNTPサーバ/クライアント

2015年11月4日 / / 0件のコメント

CentOS7から、ntpdに代わって(…という割にはntpdも普通に使えるんだけども)chronyがNTPクライアント/サーバになったらしい。ntpdが普通に使えていたので、chronyの存在しならないままだったけど、ひょんなことからchronyの存在に気付いた…。

というわけで、備忘メモ。

インストールするとき

普通にCentOSをインストールするとchronyもインストールされてそうだけど、最低限のインストールを行うと入ってないこともあるようだ。

sudo yum install chrony

chronydの設定ファイル

CentOS7だと、/etc/chrony.confが設定ファイル。NTPサーバを指定する書き方はntpd.confとよく似ているけど、微妙に違う(そりゃ当然だ)

OS起動時に起動する/起動する

ま、普通にsystemctlに御願いする。

sudo systemctl enable chronyd

sudo systemctl start chronyd

NTPサーバとの同期状況の確認

以下のコマンドで概況を知ることが出来そう。今、同期に使っているサーバとズレを確認するコマンドはこんな感じ。

chronyc tracking

んで、ソースに指定しているNTPサーバとの通信状況を確認するには、こっちのコマンド。

chronyc sources

まぁ、こういうのも慣れなので、今度、CentOS7を使うことがあればntodではなくchronydを使ってみることにしよう。

[amazonjs asin=”4798043591″ locale=”JP” title=”CentOS7で作るネットワークサーバ構築ガイド (Network server construction gu)”]

WordPressのメモリー使用量上限値はデフォルトで256MBだった。

2015年9月30日 / / 1件のコメント

運用しているWordPressが吐き出すPHPのログに「PHP Fatal error: Allowed memory size of 268435456 bytes exhausted」みたいなエラーが出ていた。これが出ていたときには、管理画面が真っ白になっていた(遠い目)まぁ、256MBもメモリーを食ってる処理をどうにかしなきゃいけないとは思うけど、とりあえず、上限値を押し上げてみて動くようなら、それで乗り切ってしまおう…と思った(ま、ヒマが出来たら調べてみようかと)

何にも考えずにphp.iniをいじって「memory_limit = 512M」としてhttpdを再起動(Apache httpdとmod_phpで動いてる)を再起動してみたが、やはりどこかでメモリー制限がかかっているようで、php.iniの設定が有効にならない。で、仕方ないのでWordPressのソースコードを読んでみたり、プラグインのソースをチェックしたりぐぐってみたりしているうちに、「WP_MAX_MEMORY_LIMIT」って定数の存在に気がついた。→詳細はこちら

要するに、WordPressはデフォルトでメモリー使用量上限値を設定していて、そのデフォルトが256MBらしい。普通は、この上限値で問題ないと言われれば確かにそうだろうなぁと思うが、php.iniで設定しても反映されなかったときはプラグインのどれかで設定しているのかなぁ…と調べてしまった(All in One SEO Packは制限値を変更できる機能がありそうだったが、デフォルトは256MBだった)

というわけで、wp-config.phpにて「define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ );」と追記したら、メモリーを使い切った系のエラーは出力されなくなった。とりあえず、一件落着ということで…原因調査はそのうちに…。

nginxがHTTP/2に対応したらしいので…

2015年9月25日 / / 0件のコメント

どうやらnginx1.9.5でHTTP/2に対応したらしい。→「Nginx 1.9.5登場 – HTTP/2モジュール搭載」

このサイトのnginxをバージョンアップするついでにHTTP/2に対応させてみた。このサイトではSPDYに対応させていたので、まずはnginxのconfigureオプションから「–with-http_spdy_module」を削除した(nginx1.9.5からSPDYモジュールは削除されたらしいので)。その上で、オプションに「–with-http_v2_module」を追加。あとのオプションはそのままでビルドしてみた。

nginx1.9.5をインストールして再起動する前に、nginx.confを修正。spdyを有効にしてあったが、もうSPDYモジュールはいないのでspdyの記載を削除して、代わりにhttp2を追加した。

listen 443 default spdy ssl;
↓
listen 443 default http2 ssl;

あとは、nginxを再起動してみたら、HTTP/2が有効になっていた…はずだがブラウザで表示させただけではわからないので、Chromeに「HTTP/2 and SPDY indicator」ってChrome拡張をインストールしてみたら、アドレスバーの脇にブルーの稲妻が表示されていたのでHTTP/2で通信しているんだろうってことで。…なんかWordPressのレスポンスが早くなった気がするようなしないような…(遠い目)

追記：
nginxのバージョンアップをした後で、nginxの「ngx_http_v2_module」モジュールのページを見てみると、パラメータがいくつか設定できるらしいので、あとで設定を追加してみようかなぁと。

aws cliで大きなファイルをS3にアップロードしようとしたらコケた

2015年9月15日 / / 0件のコメント

とあるサーバのバックアップデータをS3に格納しておこうと思って、サーバにAWS CLIをインストールした。

データをtarで固めて、「aws s3 cp –region ap-northeast-1 test.gz s3://(バケット名)/」みたいな感じでアップロードしようとしたら無慈悲にも下記のようなエラーメッセージが出て、何回もアップロードに失敗した。どうやら、大きいファイルは分割してアップロードするが、その欠片のアップロードがどこかでコケるらしい。数GBくらいはある大きなデータではあるけれど、S3のファイルサイズ制限はテラバイトオーダーなので、数GBくらいのfairは問題なくアップロード出来るはずだ。

upload failed: ./test.gz to s3://(バケット名)/test.gz
Unable to parse response (syntax error: line 1, column 0), invalid XML received:
x-amz-id-2: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
x-amz-request-id: XXXXXXXXXXXXXXXXXX
Date: Tue, 15 Sep 2015 10:35:40 GMT
ETag: “XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx”
x-amz-storage-class: REDUCED_REDUNDANCY
Content-Length: 0
Server: AmazonS3

エラーをざっくりと読む限りは、S3のサーバから不正なXMLが返っていてParseに失敗しているけれど、AWS CLIを使っているだけの私にとっては謎すぎて手が出ないので、途方に暮れていた。ふと気付いたのは、他の環境では同じくらいのサイズのファイルのアップロードに成功していて、AWS CLIのバージョンが1.8.2であること。…というわけで、失敗している環境のAWS CLIのバージョンを戻して、成功している環境と同じバージョンにしてみた。

# pip install awscli==1.8.2

バージョンを戻してみたところ、問題なくアップロードできてしまった。AWS CLIのリリースノートを見てみたけど、それっぽい記述もなくて…なかなか悩ましい。

Linode TokyoにはKVMが来ていない

2015年8月14日 / / 0件のコメント

Linodeのブログを読んでいたら、こんな記事があった。「Linode turns 12! Here’s some KVM!」

To celebrate, we’re kicking off the next phase of Linode’s transition from Xen to KVM by making KVM Linodes generally available, starting today.

どうやら、Linodeが仮想化基盤をXenからKVMに切り替えるらしい。KVMだと準仮想化ドライバが使えるようになるけど、一旦は完全仮想化から始めるらしい。とはいえ、起動とか速くなるぜとのことではあったんだけど。

いざ、XenのLinodeをKVMに切り替えるためにはダッシュボードからクリックするだけで…と書いてあるけれど、dashboardにそんなリンクが見当たらない。んで、試しにカリフォルニアのfremontで動かしてるLinodeのDashboardを覗いてみると…そのリンクが出てきた。ということは、Linode TokyoではKVMが使えないのかも…と思ったけれど、ブログの記事にはそんなこと書いてないのでどうなっているんだろうと思っていたが、forumを覗いてみたら、こんな記事があった。「Linode KVM (beta)」んで、そこにはこんな記載があった…。

The Linode KVM beta is now in all DCs except for Tokyo.

まぁ、つまるところ、Betaリリースしてたときから、TokyoにはKVMのサーバが用意されていなかったようだ。そりゃ、本番投入もないだろうなぁ…いやはや。Tokyoのラックは値段が高いから、なかなか余剰なサーバ(ユーザーのクリックをトリガーによって移行を可能にさせるなら、ある程度の余剰サーバを設置するしかなさそうだし、設備の稼働率の低下は覚悟しなきゃならないだろうな)を突っ込んでおくのが難しいってことだろうか。

そのうち、TokyoにもKVMのサーバが設置されることを首を長くして待っておこう。

シンガポールが遠かった…。

2015年8月14日 / / 0件のコメント

うーむ、やっぱり東京からはシンガポールよりカリフォルニアの方が近かったか…。

東京からシンガポールのLinodeまでのpingのRTTが270msくらい。んで、東京からカリフォルニアのサンノゼ近くのfremont(たぶんHurricane Electricだな)のLinodeまでのpingのRTTが170msほど。日本からアジア各国向けの海底ケーブルが増設されているとは思うけど、日米間の海底ケーブルに比べるとまだまだ規模が小さいんだろうか…。それともネットワーク的に迂回しているとかか。それとも、シンガポールのLinodeのネットワークが混んでるとか…？うーむ。

ec2のt2.microインスタンスを起動してみたら。

2015年7月8日 / / 0件のコメント

ちょっとt2.microインスタンスを起動してみたら、「Intel(R) Xeon(R) CPU E5-2676 v3」でインスタンスが起動してきた。これって、m4インスタンスに導入されたAWS特注のCPUじゃなかったっけ…。

うーむ、t2インスタンスって、いろんな物理サーバで起動するんだろうか、ということで。

[ec2-user@ip-XX-XX-XX-XX ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
stepping : 2
microcode : 0x25
cpu MHz : 2394.542
cache size : 30720 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 ht syscall nx lm constant_tsc rep_good nopl xtopology 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 xsaveopt fsgsbase bmi1 avx2 smep bmi2 erms invpcid
bogomips : 4789.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

64bitなWindowsで動くAccessからODBCでMySQLに接続するとか

2015年6月5日 / / 0件のコメント

64bitなWindowsの上で動く、Office2013のAccessからMySQLにODBCで接続したいときに、ODBCドライバーをどうしたらいいもんだろうかということで、ちょっと調べてみたのでメモ。

結論から書けば、Accessは32bitなアプリケーション(もしかして、64bitなOfficeって…どっかでダウンロードできるんだろうか)なので、ODBCドライバーは32bitのものが必要。…ま、そりゃ当然か。ただし、32bitなODBCドライバーを入れても、コンパネの管理ツールの中にある「データソース(ODBC)」からは、32bitなODBCドライバーに対する設定はできないようだ。実際、確認してみたが、インストールしたはずなのに、MySQLのODBCドライバーが見えない。

…ひっそりと、32bitなODBCドライバー向けの設定プログラム(odbcad32.exe)が「C:\Windows\SysWOW64」に隠されているので、それを使って接続したいMySQLの接続情報を作成する必要があるらしく…。うーむ、かなりややこしい。

livedoorプロバイダ、サービス終了…

2015年4月1日 / / 0件のコメント

ちょっと安いからっていろんな拠点にlivedoorプロバイダを導入しまくって、VPNを張って喜んで早2年。さすがに儲からないのか、サービス終了のお知らせがエイプリルフールに…。

【重要なお知らせ】livedoorプロバイダサービス終了のお知らせ:
http://blog.livedoor.jp/connect_staff/archives/1804038.html

誠に勝手ながら本サービスは、2015年6月30日をもちましてサービスを終了させていただくこととなりました。ご利用のお客様には大変ご迷惑をお掛けしますが、何卒ご理解の程よろしくお願い致します。長きにわたりlivedoorプロバイダをご愛顧いただき誠にありがとうございました。

今回終了する、このサービスのユーザーを救済するのは、livedoorプロバイダサービスのバックボーンのVectant系のQitってサービスらしいんだけど…サービス終了が6月末で、救済サービスの申し込みが6月アタマからってなかなかドキドキするので、Interlinkとか別の固定IPくれるISPへの移行を試みる予定。いやはや…なかなか面倒だな。

« Older posts Newer posts »

© 2024 ただのにっき。

Theme by Anders Noren — 上へ ↑