SEEDS Creator's Blog

Windows 10にしたら Macからリモートデスクトップが繋がらなくなった

こんにちは、はらぐちです。
最近までWindouwsのパソコンを起動すると、デスクトップ画面右下のインジケーターに 「Windows10を入手する」というボタンが表示されるようになっていましたが、皆さんご存知でしょうか? これは、今年7月にリリースされた、Windows10への無料アップグレードを予約できるというもので、 Windows利用者の間で話題になっています。

私もこの機会にアップグレードしてみたのですが、その際Remote Desktop Client for Macを使った リモートデスクトップが使用できなくなってしまったので、その時のお話しをします。
具体的には、Windows10にしてから「接続先のコンピューターのIDを確認できません。」 というエラーが出て繋がらなくなりました。 Windows8Windows Server 2012でも同様の現象となる、との事。

AppStoreにある Microsoft リモート デスクトップというアプリだと問題ないのですが、 こちらはキーボードのキーバインドが個人的に気に入らないので、 Remote Desktop Client for Macを使い続けたいと思っているので、調べてみることにしました。


結果、以下のようにすると接続できるようになりました。

検索で "gpedit.msc" を入力し、以下のように設定を変更します:
ローカルコンピュータポリシー
コンピュータの構成
管理用テンプレート
Windows コンポーネント
リモートデスクトップサービス
リモートデスクトップセッションホスト
セキュリティ
リモート(RDP)接続に特定のセキュリティレイヤーの使用を必要とする: 有効
オプションパネルで、セキュリティレイヤーを "RDP" に変更する
リモート接続にネットワークレベル認証を使用したユーザー認証を必要とする: 無効
再起動

(参考) http://zakkied.hatenablog.com/entry/2013/09/30/132342

具体的にどのような作業なのかよくわかっていないのですが、ローカル内で使いたいだけなのでOKとしました。

なにかの参考になれば幸いです。

読み込みのタイミング

こんにちは、永井です。

最近はなかなか多忙な日々を送っており、業務で手一杯になってしまうので 何か+αできるように頑張っていきたいと思います。

さて今回は、業務中に困ったことがあったので、それについて書きたいと思います。

追従メニューが最後まで動きません

javascriptで画面スクロールに追従するメニューを設置したのですが、 意図しない中途半端な位置で追従が止まるという挙動になり困りました。

原因

意図しない誤動作の原因とは、ウィンドウの高さの取得などを行い、 追従のプログラムを組んだのですが、その際に値が正しく取得できていなかったためでした。 なぜ正しく取得できなかったかというと、ページ内のコンテンツに画像が複数設定されており、 その画像の高さが定義されておらず、その影響でウィンドウの高さが正しく取得できなかったようです。

解決策

結果から述べますと、"読み込みのタイミング"を変えることで解決できました。 最初はjQueryのお約束の

$(function(){
  ここにプログラムを書き書き...
});

としていたところを

$(window).load(function(){
  こっちにプログラムを書き書き...
});

と読み込みのタイミングを変えることで、キチンと最後まで追従するようになりました。

$(function(){})と$(window).load(function(){})の違い

正直なところよくわかっておらず、どちらもそこまで違いがないものと思い込んでおりました。 そこでGoogle先生にご相談したところ、ざっくり述べると、

$(function(){})は、HTMLの構築が完了した時点で処理を実行する。 $(window).load(function(){})は、HTMLの構築だけでなく、画像やFlashなどのデータの読み込みが完了してから処理を実行する。

だそうで、$(window).load(function(){})内ににプログラムを書くことで、コンテンツ内の画像データも含めて ウィンドウの高さなどを取得することができるようになり、解決につながりました。

注意点

ただし、$(window).load(function(){})には注意すべき点があります。 それは、”画像やFlashなどのデータの読み込みが完了してから”なので、使用箇所、使用機能によっては ユーザーは反応が遅く感じてしまうことがあると思われるので、 その辺りは、実際にテストを行い考慮していく必要がありそうです。

まとめ

普段は気にせず$(function(){})内に書き込んでいましたが、プログラムによっては 読み込みのタイミングを考慮する必要があるとわかりました。 また、できたから良いのではなく、機能の反応のユーザー体験(ユーザーエクスペリエンス)を 考えるということも大事なのだと思いました。

td-agentにてAWSのRDS(postgres)のログをTDに送信

AWSのRDSはLinuxサーバではない為、こちらからいろいろな設定ができません。

その為、どのようにPostgresのログを送信すればよいか、いろいろ試行錯誤したのでその備忘録です。 前提として、RDSに接続できるLinuxインスタンスにtd-agentが入っている状態が必要です。

fluent-plugin-rds-pgsql-log

https://github.com/shinsaka/fluent-plugin-rds-pgsql-log RDSのpostgresのログを取得するには上記のプラグインを利用します。

このプラグインはAWS RDSのログを取得し、td-agentのsourceとして利用できるようにするプラグインです。

ただ導入にあたり、依存関係に「AWS SDK」があるのですが、パッケージで導入したtd-agentでは fluentd-gem fluent-plugin-rds-pgsql-log にて導入ができませんので、以下のように導入します。

まず、td-agentに入っているrubyからaws-sdkをインストール

/usr/lib64/fluent/ruby/bin/gem install aws-sdk

fluent-plugin-rds-pgsql-logのプラグインを直接プラグインディレクトリにほおりこむ

wget https://raw.githubusercontent.com/shinsaka/fluent-plugin-rds-pgsql-log/master/lib/fluent/plugin/in_rds_pgsql_log.rb -P /etc/td-agent/plugin

これでpostgresのログをTDに送信できました。

<match td.postgres.log>
  type tdlog
  apikey *****************************
  auto_create_table
  database postgres
  table log
  buffer_type file
  buffer_path /var/log/td-agent/buffer/td
  flush_interval 180s
</match>


<source>
  type rds_pgsql_log
  region ap-northeast-1
  db_instance_identifier prod-auth
  access_key_id ******************
  secret_access_key *********************************
  refresh_interval  30
  tag td.postgres.log
  pos_file /var/log/td-agent/pgsql-prod-auth-log-pos.dat
</source>

こんな感じのデータが送信されます

{"message_level"=>"LOG", "time"=>"1436510427", "ident"=>"postgres", "host"=>"10.0.0.21(22112)", "database"=>"[unknown]", "user"=>"[unknown]", "pid"=>"6080", "log_file_name"=>"error/postgresql.log.2015-07-10-00", "message"=>"  connection received: host=10.0.0.21 port=53253"}

host部分がSQL発行元IPになる

管理の上ではhost部分はRDSの名前になっているのが望ましいので、host部分を強制的に変更します。 データをリフォームする為に「fluent-plugin-record-reformer」というプラグインを利用しました。

https://github.com/sonots/fluent-plugin-record-reformer

wget https://raw.githubusercontent.com/sonots/fluent-plugin-record-reformer/master/lib/fluent/plugin/out_record_reformer.rb -P /etc/td-agent/plugin

最終的なtd-agent.confは以下のようになりました。

<match td.postgres.log>
  type record_reformer
  renew_record false
  enable_ruby false
  tag reformed.td.postgres.log
  # 強制的に文言を変更する
  host rds-postgres01
  ident postgres
</match>


<match reformed.td.postgres.log>
  type tdlog
  apikey *****************************
  auto_create_table
  database postgres
  table log
  buffer_type file
  buffer_path /var/log/td-agent/buffer/td
  flush_interval 180s
</match>


<source>
  type rds_pgsql_log
  region ap-northeast-1
  db_instance_identifier prod-auth
  access_key_id ******************
  secret_access_key *********************************
  refresh_interval  30
  tag td.postgres.log
  pos_file /var/log/td-agent/pgsql-prod-auth-log-pos.dat
</source>

あの名作がやってまいりました!

こんにちは、WEBエンジニアのyuchiです。
突然ですが、みなさん映画はお好きでしょうか? というのも、有名なあのSF映画「スター・ウォーズ/フォースの覚醒」が、 今年の12月ついに公開されるようです。

私も密かにこれまでの全作品を見たことがありまして、スターウォーズが好きな人からすると 待ちに待った公開となるのではないでしょうか。
スター・ウォーズ/フォースの覚醒 http://starwars.disney.co.jp/movie/force.html
また、スターウォーズには欠かせない武器「ライトセーバー」ですが、最新作では形が十字架になっていて、 今までにない新しいライトセーバーに注目が集まっています。 しかも、この十字架のライトセーバーのデザインについて助言をしたのが、アップルのデザイナーであるあの 「ジョナサン・アイブ」なのだとか。
ジョナサン・アイブ氏と言えば、あらゆるアップルの製品をデザインされたすごいお方です。 ライトセーバーについては監督に「あまり厳密でなく、ちょっとだけ粗野にしてはどうか」 「そうすればもっとアナログで原始的で、なんでか不吉な感じが出せるのでは」と提案したそうです。

シンプルなデザインほど類似のデザインが生まれるから一番難しいと良く聞きますが、そんな中でも 何かしら新たな発想を生みだしているんですね。
とにかく、そんな見どころ満載の「スター・ウォーズ/フォースの覚醒」とても楽しみです。

自分の得意なコトをやろう

イギリスの経済学者デヴィッド・リカードは言いました。 「自分の得意なコトをやろう」 (※本当は全然違いますが、ニュアンスはこんな感じです。たぶん。)

チームで仕事をする場合、自分は比較的得意な仕事を担当することが 自分にとってもチーム全体で見てもプラスになります。 なんか当たり前のようなことを言っていますが、よく考えると面白いので、ちょっとお話します。

2つの案件

・案件A:PHP2000行、HTML1200行書く。 ・案件B:PHP1000行、HTML500行書く。 この2つの案件を2人でやっつけることを考えます。

パターン1

PHPしかできないプログラマーさんとHTMLしかできないコーダーさん。 この場合、案件A,BのPHP部分をプログラマーさんが、 HTMLはコーダーさんが担当すればいいことがすぐに分かります。 2人が別々に案件A、案件Bをそれぞれ担当しても、片方の作業が全くできないので完遂できません。

パターン2

PHPが得意なプログラマーさんとHTMLが得意なコーダーさん。 今回は、プログラマーさんはHTMLもできます。同じようにコーダーさんもPHPができます。

このケースにおいても、それぞれが別の案件を担当するのでなく、 両案件のPHPプログラマーさん、HTMLをコーダーさんが担当するのが良さそうです。 早く終わって手が空いたらもう片方を手伝う感じですね。

パターン3

最強プログラマーさんと新人プログラマーさん。 お二人共PHPとHTML両方できますが、最強プログラマーさんの方がPHPもHTMLも開発スピードが早いです。 この場合はどう仕事を割り振るのがいいでしょうか?

最強プログラマーさんが1時間あたりPHPのコード100行、HTMLを50行書けるとします。 一方、新人プログラマーさんは1時間あたりPHP50行、HTML20行しか書けません。 とりあえず、それぞれが案件A、案件Bを担当すると

◯最強プログラマーさん ・PHP 100行 2000行 20時間 ・HTML 50行 1200行 24時間

◯新人プログラマーさん ・PHP 50行 1000行 20時間 ・HTML 20行 500行 25時間

となりますね。

ところが、これはベストな采配ではありません。 この場合、新人プログラマーさんは自分のより得意なプログラムに専念した方が早く終わります。

具体的には

◯最強プログラマーさん ・PHP 100行 750行 7.5時間 ・HTML 50行 1700行 34時間 ◯新人プログラマーさん ・PHP 50行 2250行 45時間 ・HTML 20行 0行 0時間

こんな感じです。 新人プログラマーさんの作業量は変わっていませんが、最強プログラマーさんの 作業時間が短縮されました。

新人プログラマーさんのPHP10行はHTML4行の価値しかありませんが、最強プログラマーさんの PHP10行はHTML5行の価値があります。 なので、HTMLはなるべく最強プログラマーさんに任して新人プログラマーは自分の得意とする PHPを書いた方が効率がイイのです( ・∀・)イイ!!

もちろん、実際の現場となるとこんな単純な話ではないですが、自分の得意を伸ばすことが 大事だということが分かると思います。

mysqlのバックアップ(mysqldump)のロック問題

こんにちは、はらぐちです。

今回お話したいのは、mysqlのバックアップ方法についてのあれこれです。

バックアップ mysqldump

mysqlのバックアップといえばmysqldumpです。 以下のような形で使います。

mysqldump -u root -p -x -A > my_dumpall.db

これで全データベースのダンプができます。 特定のデータベースをダンプしたい場合は、以下のようにデータベース名を指定します。

mysqldump -u root -p -x データベース名 > dump.sql

定期的にバックアップを取りたい場合は、シェルスクリプトで以下のようなものを cronで実行してあげるといいでしょう。 二日間のバックアップを保持するスクリプト例です。

#!/bin/bash

MPASS=パスワード

mysqldump --defaults-extra-file=<(printf '[mysqldump]\npassword=%s\n' ${MPASS}) -u root -x -A > my_dumpall_`date +%Y%m%d`.db

OLDDATE=`date "-d2 days ago" +%Y%m%d`
rmfile=my_dumpall_$OLDDATE.db
if [ -e $rmfile ]; then
    sleep 5m
    rm -f $rmfile
fi

ちなみにリストアは以下のような形です。

mysql -u root -p < dump.sql 
mysql -u root -p データベース名 < dump.sql 

バックアップ datadirのコピー

mysqlのdatadirをOS上でコピーしてしまえばバックアップになります。

この方法の最大の利点は、リストアが非常に高速な事です。 通常のリストアはダンプファイル(SQL)をmysqlに渡す事で処理をするのでIndexの再作成などの処理もかかり、 mysqlのcpuがボトルネックとなってきますが、datadirによるリストアはdatadirのファイルを そのまま置き換えてあげるだけですので、簡単かつ高速です。

しかし、同様に整合性の問題がありますので、mysqlを停止してからでなければいけないのが欠点です。 停止となるので完全に止まってしまいます。また、データベース単位でのバックアップなどはできません。

このバックアップ方法をとるのはサーバー移行などの高速なリストアが必要な時です。

mysqldumpのロック問題

mysqldumpコマンドのオプションで「-x」というものがありますが、 これはデータベースのすべてのテーブルをリードロックする、というものです。 データベースをリードロックすると参照系のクエリは発行できますが、 更新系のクエリはロックが解除されるまで待ち状態となります。 これはデータベースの整合性を保つ為に必要です。

しかし、サービス運用中ですと、この「更新系が待ち」になる事が許容できない事があります。 たかだか1Gくらいのデータベースですと、ミッションクリティカルなサーバーでない限り ロックがかかる時間も少ないのでまだ許容できるかもしれませんが、 これが20GBほどのサイズとなると、30分ほどかかったりする事がざらにあります。

セッションをDBで管理してたりすると、すべてのユーザーがサービスを利用できなくなるというわけです。

ロック問題の解決策 single-transaction

データベースがすべて「innodb」であればシングルトランザクションオプションを使ったダンプを行う事で ロックせずにバックアップする事ができます。

mysqldump -u root -p --single-transaction -A > my_dumpall.db

内部的にはスナップショットをとって、そのデータをダンプする事でロックする事なく 整合性のとれたダンプを取る事が可能です。 通常のmysqldumpと異なる点は、ダンプデータが「ダンプが終了した時の状態」ではなく 「ダンプを開始した時の状態」であるという点です。

ちなみに--master-data=2を付けるとbinlogファイルと位置の情報をdumpに含めてくれるので レプリケーションslaveを作る際に大変重宝します。 この方法の最大の欠点はすべてのデータがinnodbである必要がある点です。 myisamなどのテーブルは整合性が取れなくなる可能性があります。

ロック問題の解決策 レプリケーションslaveにてdump

サーバーがもう一台必要ですがレプリケーションしたslaveサーバーにてバックアップを行うと、 ロックをかけてもサービスには影響を与えません。

ロック問題の解決策 LVMのスナップショットでdatadirをコピー

こちらは実際には行った事がないのですが、LVMのスナップショットで datadirのスナップショットを取ってしまえばmysqlの停止なくバックアップ可能です。 ですが、スナップショット作成中は非常に負荷が高くなるそうで、 該当時間の書き込み処理の性能がガタ落ちするそうです。

一番いいのはsingle-transaction

日々のバックアップ用途であれば今までの運用の経験から「single-transaction」オプションでの mysqldumpが一番よかったかなぁと思います。 これからサーバーでmysqlを使う時は、意識的に「InnoDBを使う」という事を心がけていくといいと思います。

デスクトップPC(Windows)が起動しない場合について

こんにちは、中氏です。

先日、普段自分が使用しているデスクトップPC(Windows)が いきなり起動しなくなるという事態が起こりました。

しかし、一言に「起動しない」と言っても、原因はいろいろ考えられます。 パソコンを復活させるためにも、原因を探ってみました。

まず、パソコン本体やキーボードなどの電源が入るかどうか確認しました。 この時、全て入らなかったので、次に一度電源コードを抜きました。 パソコン本体に不必要な電気が帯電している場合、正常に起動しない場合があるので 帯電している電気を放出するといいそうです。これを放電といいます。 (コードを抜いてから1分以上放置し再び繋げるのがいいそうです。)

以前はこれで正常に動いたことがあったのですが、今回は動きませんでした・・・

「パソコンが起動できない場合の対処方法(Windows7)」参照

そこで、次にパソコン本体の中身を見てみると、埃がたくさん溜まっていました。 ファンにも埃がひっかかっていて、うまく動いていなかったようです。 きれいに除去して起動してみると、無事復旧できました。

自分と同じように、埃が原因でパソコンが動かなくなることもあるので こまめに掃除をすることをおすすめします。 初めて分解するときは、壊しそうで少し抵抗があるかもしれませんが ネジを2、3個外しフタを開けるだけで中身のほぼ全体を見ることができるので、意外と簡単です。

みなさんも、パソコンが起動しないときなどは参考にしてください。