ただつらつらと日記が書かれていくようです。
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プロバイダを導入しまくって、VPNを張って喜んで早2年。さすがに儲からないのか、サービス終了のお知らせがエイプリルフールに…。
【重要なお知らせ】livedoorプロバイダサービス終了のお知らせ:
http://blog.livedoor.jp/connect_staff/archives/1804038.html
誠に勝手ながら本サービスは、2015年6月30日をもちましてサービスを終了させていただくこととなりました。ご利用のお客様には大変ご迷惑をお掛けしますが、何卒ご理解の程よろしくお願い致します。長きにわたりlivedoorプロバイダをご愛顧いただき誠にありがとうございました。
今回終了する、このサービスのユーザーを救済するのは、livedoorプロバイダサービスのバックボーンのVectant系のQitってサービスらしいんだけど…サービス終了が6月末で、救済サービスの申し込みが6月アタマからってなかなかドキドキするので、Interlinkとか別の固定IPくれるISPへの移行を試みる予定。いやはや…なかなか面倒だな。
AWSのCloudSearchを使ってみているけれども、これで使われているインスタンスって、m1.smallとかm3.mediumなんだよなぁ。どうせなら、コストパフォーマンスよさげなt2インスタンスとか使えるようにならないかなぁと思うけど、t2インスタンスのCPUクレジットを使い切って性能がガクッと落ちたら切ないか。うん、それは切ない。…みたいなアホなエントリーを書いているけれど、一向にindexingが終わらない…。うーむ、とりあえず安いsearch.m1.smallインスタンスだと、何やらせても時間かかるなぁ(遠い目)
zabbixのagentでphp-fpmの監視をどうするかなぁと思ったけど、Google先生に聞いてみたら、テンプレートがあった。php-fpmでステータスを吐き出させるようにしておいて、zabbixエージェントとphp-fpmのステータス表示をつなげるシェルを置いておく、という方式のようで。
Template php-fpm：
https://github.com/jizhang/zabbix-templates/tree/master/php-fpm
まぁ、このサイトはサーバが物理的に遠いところにあるので、ネットワークのレイテンシーが大きいとはいえ、SPDYの効果は多少はありそうなので、SPDYを使えるシーンではできるだけ対応してみたいと思った…が、しかし。
今、運用している別サイトでは、AWSのELBを使ってSSLの処理をオフロードしているんだけど、その状態ではSPDYは使えない。ELBがSPDYしゃべってくれないもんなぁ。
というわけで、ELBではHTTPSのコネクションの振り分けだけやってもらって、SSLの処理は配下のnginxとかApache httpdで受けなきゃいけないってことになり、SPDYを使えるようにするためにSSLの処理を配下に持ち込むのもなんかなぁ…(いやまぁ、たいしたトラフィックじゃないけど、ELBの料金のなかでSSLのオフロードもしてもらっていると思うと、できればSSLの処理はELBに押しつけたいような)
…というわけで、AWSのELBでSPDYをしゃべれるようになって欲しいなぁと。ここまで書いて、ふと思ったのは、ELBからユーザーの環境までをSPDYにしても意味ないんだっけ…あれ(汗)
SPDYに対応させるとどうなるか試してみたかったので、このサイトのコモンネームでSSL証明書を買ってきて、nginxのspdyモジュールを使ってspdyを利用可能にしてみた。
ブラウザにSPDY Indicatorとかのアドオンを入れると、SPDYを使っていることが確認できる。まぁ、このサーバは米国の西海岸にある物理サーバで動いているVPSなので、通信部分のレイテンシーが大きいせいか、「多少は早くなったかなぁ…」という印象。まぁ、いっか(遠い目)
WordPressをSSL化するときには、とりあえず、「設定」から「一般」を開いて、「WordPress アドレス (URL)」と「サイトアドレス (URL)」のsheme部分をhttpsに変更すると基本的には対応が完了しそうな雰囲気ではあるけれど、過去に貼っちゃった画像なんかはhttpで参照されそう。うーむ、まぁ、SSL化は最初からやった方がいいんだなと思いつつも、WordPressもschemeなしのURLで画像のURLを書いておいてもらえると便利なんだけどなぁと。
あとは、nginxでHSTSを返すようにしてみた。検索エンジンなんかも、HSTSを参照してSSLで参照してくれたりするんだろうか。ちょっと試してみるか。
memcachedをビルドした後、make testを実行するために、いくつかperlのモジュールが必要なので、そのPerlモジュールをメモ。実行環境はAmazonLinux 2014.09。
sudo yum install perl-Test-Harness
sudo yum install perl-Test-Simple
完全に備忘録。nginxのアップデートを行おうとしてソースからビルドしようとしたけれど…今、動いているnginxのconfigureオプションがどうなっていたのか思い出せない…。というわけで、調べたらnginxコマンドにオプションを付ければよさげということが分かった。
# nginx -V
ま、別にroot実行する必要がないのかもしれないけど。えーと、とりあえず、大事なのは小文字のvを付けるとnginxのバージョンしか帰ってこないけれど、大文字のVを付けてあげることでconfigureオプションが返ってくるというところかな、と。
ふらっと駅に行ってみたら、運行状況を案内するデジタルサイネージが死んでた(笑)
死んでる案内用サイネージ
ディスプレイに表示されている内容を見る限り、ああいうサイネージの画面を作ってるコンピュータは、汎用的なPCなんだなということを改めて認識、と。ま、きっとブート用のドライブが故障しちゃったのかな、と。ということは、「調整中」にはなっているけれど、オンサイトの保守待ちってことになりそうだな、と。
SONYのNEX-5Rを使っているが、先日、うっかりNEX-5Rを落っことしてしまった。幸か不幸か、カメラが落下して地面とぶつかったのはレンズ部分ではなく、プラスチックのバッテリーカバー部分。しかも、本体とカバーのつなぎ目の部分が割れてしまって、カバーが本体から脱落したみたいな感じ。ま、カバーがなくてもバッテリーはツメで固定されているので、撮影できないことはないが、(割れて)とがった部分が指にあたって、なかなかドキドキする。
NEX-5Rのバッテリーカバー
これを自分で修理するといっても、もはや本体から割れてしまっているので、くっつけるのも難しいだろうと思って修理に出すしかないな、と。そういえば、ヨドバシカメラのポイント(修理などに使えるポイント)が貯まっていて修理代金に充足できそうだったので、ヨドバシカメラに修理に出すことにした。
ヨドバシカメラもどこか修理を担当する会社に委託しているらしく、修理の見積もりができたら、そこから電話がかかってくることになっていると告げられた。…で、数日くらいしたら電話がかかってきて見積もりを教えて貰った。バッテリ-カバーの取り替えで、ざっくり7000円ほど(正確な金額を聞いたけど忘れた)と言われた。ま、他にどうしようもないので、素直に発注することにした。
あと、ついでにコンデジのDSC-WX200(いわゆるサイバーショット)のコネクタカバーのツメが割れて閉められなくなっていたので、それも見積もりをもらっていたけれど、こっちは4,000円ちょっと(これまた正確な金額を忘れた)とのことだった。WX200は、本体の値段が2万円していないのに、コネクタカバーの修理に4,000円はなかなか切ないので、修理を断念した。
修理に出してから修理完了まで2週間くらいはかかったけど、無事に修理されて帰ってきて一安心。
© 2025 ただのにっき。
Theme by Anders Noren — 上へ ↑