Ubuntu12.04 LTSをインストールしたLenovo G500を再起動するたびに画面が真っ暗になる件

以前Linux専用機として運用するためにLenovo G500を購入して、Ubuntu 12.04 LTSを入れたのですが、再起動するたびに画面が真っ暗になって、その度バックライトの輝度を最大まで上げていたのですが、いい加減窓からマシンをかなぐり捨てたいぐらいにいやになってきたところです。

Ubuntuがいけないのかと思って、その他のディストリビューションを検討したのですが、ラップトップマシンに最適なディストリを考えたときCentOSDebianSlackwareFedoraもSLもどうにも、、、なんかなぁという感じでした。だいぶUbuntuも設定してしまったのでまた他の入れなおすのは気が重いです。

なのでUbuntuでどうにかならないか検索してみました。
調べてみると

# echo xxx > /sys/class/backlight/acpi_video0/brightness

で輝度を調整できるみたいです。で、G500の輝度のMAX値を調べると

# cat /sys/class/backlight/acpi_video0/brightness
100

なので

# echo 100 > /sys/class/backlight/acpi_video0/brightness

として最大の明るさに設定しました。即座に反映されます。でもこのままでは再起動したらきれいさっぱりリセットされてしまうので /etc/rc.local に記述します。実行権限がついていることを確認して

echo 100 > /sys/class/backlight/acpi_video0/brightness
exit 0

とします。exit 0 の前に入れるのがポイントです。

そして再起動。一回目はなぜか真っ暗になってしまったので、なんだよーと思いながら sleep 5 とか入れたらディスプレイマネージャが立ち上がらなくなってしまいました。なので sleep 5 を削除して、改めて再起動したら今度は反映されました。なんだったんだろう。。。

それにしてもこのマシン、テンキー邪魔だな・・・。エンターキー小さいし・・・。

参考文献

AWS SDK for PHP 2を使ってEC2のインスタンスを起動してみる

Amazon Web Services ガイドブックのEC2セットアップスクリプトの内容をAWS SDK for PHP 2用に書きなおしてみました。

動くようになるまで結構大変でした。。。
ただ、APIから仮想サーバー立ち上げられるってすごいなあと改めて実感。
S3のときなどと違ってEC2は高価だから心臓に悪いですね。
こういうのいじるときはこまめにアカウントアクティビティチェックして、開放漏れのIPや無駄にインスタンス、スペックの高いインスタンスを知らずに立ち上げてしまっていないか注意しないといけないですね。

細かいセットアップについては

にゆずります。

では以下がスクリプトとなります。

<?php
error_reporting(E_ALL);
// Composer
require_once('vendor/autoload.php');
use Aws\Ec2\Ec2Client;
// AWSアクセストークン
$config = array(
'key'    => 'AKIAIOSFODNN7EXAMPLE',
'secret' => 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'
// 東京リージョン指定
'region' => \Aws\Common\Enum\Region::AP_NORTHEAST_1,
);
$ec2 = Ec2Client::factory($config);
try {
$options = array(
// Amazon LinuxのAMIを使う
'ImageId' => 'ami-b1fe9bb0',
// インスタンス1個
'MinCount' => 1,
'MaxCount' => 1,
// キーを指定
'KeyName' => 'securekey',
// セキュリティグループを指定
'SecurityGroups' => array(
'webserver' // sg-134678
),
// インスタンスタイプはマイクロインスタンスを立ち上げる
'InstanceType' => 't1.micro',
);
$result = $ec2->RunInstances($options);
} catch (Exception $ex) {
exit("Instance Launch failed.: " . $ex->getMessage() . "\n");
}
// インスタンス情報を取得
$instance = $result['Instances'][0];
$instanceId = $instance['InstanceId'];
$availabilityZone = $instance['Placement']['AvailabilityZone'];
echo "Instance ID: $instanceId\n";
echo "Availability Zone: $availabilityZone\n";
// EC2インスタンスの準備ができるのを待つ
do {
$result = $ec2->describeInstances(array(
'InstanceIds' => array(
$instanceId
)
));
$status = $result['Reservations'][0]['Instances'][0]['State']['Name'];
$runnning = ($status == 'running');
if (!$runnning) {
echo "instance is currently in $status, waiting 10 seconds.\n";
sleep(10);
}
} while(!$runnning);
try {
// ElasticIPを割り当て
$result = $ec2->allocateAddress();
$publicIp = $result['PublicIp'];
echo "allocate IP Address: $publicIp\n";
} catch (Exception $ex) {
exit("Allocate IP Address failed. " . $ex->getMessage() . "\n");
}
try {
// ElasticIPをインスタンスにアタッチ
$ec2->associateAddress(array(
'InstanceId' => $instanceId,
'PublicIp' => $publicIp,
));
echo "Associated IP address : ${publicIp} to ${instanceId}\n";
} catch (Exception $ex) {
exit("IP Address Association failed. " . $ex->getMessage() . "\n");
}
try {
// 先ほど得られたアベイラビリティゾーンに1GiBのボリュームを2つ作成
$res1 = $ec2->createVolume(array(
'Size' => 1,
'AvailabilityZone' => $availabilityZone,
));
$res2 = $ec2->createVolume(array(
'Size' => 1,
'AvailabilityZone' => $availabilityZone,
));
$volumeId1 = $res1['VolumeId'];
$volumeId2 = $res2['VolumeId'];
echo "EBS Volume: $volumeId1, $volumeId2 created.\n";
} catch (Exception $ex) {
exit("EBS Volume create failed. " . $ex->getMessage() . "\n");
}
// ボリュームが使えるようになるまで待つ
do {
$result = $ec2->describeVolumes(array(
'VolumeIds' => array(
$volumeId1, $volumeId2
)
));
$status1 = $result['Volumes'][0]['State'];
$status2 = $result['Volumes'][1]['State'];
$volumeReady = ($status1 == 'available' && $status2 == 'available');
if (!$volumeReady) {
echo "volumes are currently in ($status1, $status2), waiting 10 seconds.\n";
sleep(10);
}
} while(!$volumeReady);
try {
// ボリュームをインスタンスにアタッチ
$res1 = $ec2->attachVolume(array(
'VolumeId' => $volumeId1,
'InstanceId' => $instanceId,
'Device' => '/dev/sdf',
));
$res2 = $ec2->attachVolume(array(
'VolumeId' => $volumeId2,
'InstanceId' => $instanceId,
'Device' => '/dev/sdg',
));
echo "Volume $volumeId1, $volumeId2 has been attached successfully.\n";
} catch (Exception $ex) {
exit("EBS Attache failed. " . $ex->getMessage() . "\n");
}
echo "Finished!!\n";

で、出力は以下のようになります。

$ php ec2_setup.php
Instance ID: i-11223344
Availability Zone: ap-northeast-1c
instance is currently in pending, waiting 10 seconds.
instance is currently in pending, waiting 10 seconds.
allocate IP Address: 54.111.95.222
Associated IP address : 54.111.95.222 to i-11223344
EBS Volume: vol-12345ba, vol-653ac created.
volumes are currently in (creating, creating), waiting 10 seconds.
Volume vol-12345ba, vol-653ac has been attached successfully.
Finished!!

AWS Management Consoleで確認したらちゃんとインスタンスが立ち上がってElasticIPがアタッチ、ボリュームもきちんとアタッチされていました。いいこいいこ。

参考文献

Amazon Route53の設定管理ツールのRoadworkerを使ってみた

Amazon Route53をRuby DSL設定ファイルで管理するRuby製のツール。
もちろんDSLで記述されているのでバージョン管理システムとの相性も抜群です。

環境

インストール

Gemfile

僕はGemfileを用意します。

source "https://rubygems.org"
gem 'roadworker'

そして

$ bundle install --path ~/vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Using json (1.8.1)
Using mini_portile (0.5.2)
Using nokogiri (1.6.0)
Using uuidtools (2.1.4)
Installing aws-sdk (1.29.1)
Using systemu (2.5.2)
Installing macaddr (1.6.1)
Installing net-dns (0.8.0)
Installing tins (0.13.1)
Installing term-ansicolor (1.2.2)
Installing uuid (2.3.7)
Installing roadworker (0.3.10)
Using bundler (1.3.5)
Your bundle is complete!
It was installed into /Users/noguchiwataru/vendor/bundle

特にhomebrewでインストールするパッケージが必要なわけでもなくインストールできました。

$ bundle exec roadwork --version
roadwork 0.3.10

使う

当然ですが、AWS APIアクセスのためのアクセスキーに関する環境変数が事前にセットアップされている必要があります。

export AWS_ACCESS_KEY_ID='...'
export AWS_SECRET_ACCESS_KEY='...'

初期設定

Routefileに現在管理されている Hosted Zone の設定を出力する。

$ bundle exec roadwork -e -o Routefile
Export Route53 to `Routefile

中身はどうなっているか

RubyのDSLになっています。

hosted_zone "example.com." do
rrset "example.com.", "A" do
ttl 300
resource_records(
"11.33.99.91"
)
end
rrset "*.example.com.", "A" do
ttl 300
resource_records(
"11.33.99.91"
)
end
rrset "yunocchi.example.com.", "CNAME" do
ttl 300
resource_records(
"hatenablog.com"
)
end
rrset "miyako.example.com.", "A" do
ttl 300
resource_records(
"111.222.333.444"
)
end
rrset "nori.example.com.", "CNAME" do
ttl 300
resource_records(
"domains.tumblr.com"
)
end
end

適用してみる

まずは --dry-run してみる。

$ bundle exec roadwork --dry-run -a -f Routefile
Apply `Routefile` to Route53 (dry-run)
Update ResourceRecordSet: example.com. A (dry-run)
set resource_records=[{:value=>"11.33.99.91"}] (dry-run)
Update ResourceRecordSet: *.example.com. A (dry-run)
set resource_records=[{:value=>"11.33.99.91"}] (dry-run)
No change

問題なければ適用。
2回目の実行ではちゃんと変更なしとなっている。
冪等性ばんざい。

$ bundle exec roadwork -a -f Routefile
Apply `Routefile` to Route53
Update ResourceRecordSet: pg1x.com. A
set resource_records=[{:value=>"11.33.99.91"}]
Update ResourceRecordSet: *.pg1x.com. A
set resource_records=[{:value=>"11.33.99.91"}]
$ bundle exec roadwork -a -f Routefile
Apply `Routefile` to Route53
No change

AWS Management Console上で見てみるとちゃんと適用できている。
すばらしい。

いじわるしてみる

AWS Management Console上でレコードを1行追加してみました。
本来ならRoutefile上で管理するつもりなので、あってはならないことです。
まあ、コンテキストによってはAWS Management Console上で変更したやつはRoutefileにも反映してほしい気もしますが、
そんな虫のいい話はないですね。
なので、ここではRoutefileにないレコードは消えてくれることを期待します。

$ bundle exec roadwork --dry-run -a -f Routefile
Apply `Routefile` to Route53 (dry-run)
Delete ResourceRecordSet: localns.pg1x.com. A (dry-run)
No change

余計な行が増えているよと教えてくれました。
--dry-run を消して適用すればOKです。
AWS Management Console上からはきれいさっぱり消えています。

参考サイト

クラスメソッドさんの説明がとても参考になりました。

Gemfile初期化

いつも Gemfile のテンプレ手作業でコピーしてた。
コマンド一発で生成できるのしらなかった。。。

$ bundle init
Writing new Gemfile to /Users/noguchiwataru/Documents/repositories/bitbucket/roadworker-wnoguchi/Gemfile

で、出力内容は以下のようになる。

$ cat Gemfile
# A sample Gemfile
source "https://rubygems.org"
# gem "rails"

GitHubを2段階認証にしたときのSourceTreeの対応方法

当然ですが、GitHubに2段階認証を設定したらSourceTreeのGitHub連携機能が使えなくなりました。
その対応方法。

  1. 設定画面に行きます。
  2. サイドメニューの Applications をクリックします。
  3. Personal Access Tokens の Create new token で好きなアプリ名を入れて、トークンを生成します。
  4. あとは SourceTree のGitHubアカウント欄のパスワードにそのトークンを設定すればOK。

参考サイト