空落科技

LGA775以降，インテルCPUのヒートシンクはプッシュピンで止めるようになりました．
しかし不肖私ソラオチめはこのプッシュピンを満足に止められません．すごく硬いし，どこまで回せばいいか分からないし，途中からどっちに回すのかよく分からなくなってきます．
さらに，ちゃんと取り付けたはずなのにある日突然外れてCPUが熱暴走することもあります（実例）．
面倒臭くなったので，自宅にあったM5のネジで取り付けてしまいました．
取り付けたクーラーはグランド鎌クロスです


グランド鎌クロスのプッシュピンを


取り外して


ネジ止め

まんまSocket 478時代のPAL穴ですね．
Pen4のマザボにはリテンションキットが付いていて，失くすと中古屋に売れなかったりするわけですが，LGAは元々ついてないので安心です．

さっき知ったのですがAinex BS-1156という便利グッズもあるようです．次回からはこれにしよう．

動く．
Originで”We’re sorry, an error has occurred. there is a problem with your game’s setup. Please reinstall the game”などのエラーが出る場合，xinputをインストールする

AmazonでMicrosoft Office Personal 2010 アップグレード優待（以下分かりやすさのため本ソフトウェアと表記）を購入した．
インストール手順は次の通りだった．

0. Office 2000 正規版を用意．アップグレード元となるパッケージが無い場合，手順1のシュリンクラップ契約の締結に瑕疵が生じることとなります．必ずアップグレード優待の条件を確認すること．
1. 本ソフトウェアのパッケージの開封（シュリンクラップ契約の締結）
2. 光学ドライブに本ソフトウェアのメディアをセット
3. 本ソフトウェアのAutorunで指定されたファイルを実行
4. インストール中に本ソフトウェアのパッケージに記入されたプロダクトキーを入力
5. 電話にて本ソフトウェアの認証
6. 終わり

本エントリーは作業手順を記した日記にすぎず，他の環境で同様の手順となることを保証するものではない．本エントリーを見たことにより生じたいかなる損害の責も私は負わないものとする．
また，質問は受け付けない．

GRUB のアップデートをした後や，Linux のインストール直後にGRUB Error が出てシステムが起動しないことがあります．そんなときの対処法を書いておきます．
なお，GRUBの設定ファイルは，GRUB2では/boot/grub/menu.lst が廃止され，/etc/default/grub と# grub-install を実行したあとに生成される/boot/grub/grub.cfg になったようです．

まず，システムをLiveCDから起動するか，母艦のUSBにレスキューしたいハードディスクを繋ぎます．
/boot パーティションが/ と分けられている場合は別途mount してあげる必要がありますが，流れは全く同じです．
パーティションのUUIDは$ blkid で調べられます．よく分からなければgparted を使うといいかもしれません．
今回は/media/UUID に自動でmount されていることを仮定しています．

母艦の/ や/boot と，レスキュー対象の/ や/boot を混同しないように気を付けましょう．

# /boot パーティションのUUID．/ 上に/boot があるなら省略
BOOT_UUID=0e0670da-9711-4eab-8025-b26dba90d576

# / のUUID
SYS_UUID=21427729-aef2-4a52-8d28-d6e90804c659

sudo mount --bind /proc /media/${SYS_UUID}/proc
sudo mount --bind /sys /media/${SYS_UUID}/sys
sudo mount --bind /dev /media/${SYS_UUID}/dev
# / 上に/boot があるなら省略
sudo mount --bind /media/${BOOT_UUID} /media/${SYS_UUID}/boot

sudo chroot /media/${SYS_UUID}
# たとえば/dev/sdeに grub をインストールしたい時
grub-install /dev/sde
update-grub
exit

sudo umount /media/${SYS_UUID}/proc
sudo umount /media/${SYS_UUID}/sys
sudo umount /media/${SYS_UUID}/dev
# / 上に/boot があるなら省略
sudo umount /media/${SYS_UUID}/boot


/media/${SYS_UUID} にchroot を設定し，# update-grub を実行しています．
ただし，その為には（CHROOT_DIR 下に）/proc ，/sys ，/dev が必要なので，動いているシステムのものをそのままmount しています．ですので，LiveCDから起動した方がより堅実かもしれません¹．
mount の--bind オプションは，chroot 下でもmount 先にアクセスできるようにするためのものです．

1. そこまで気にすることもないと思いますが，AMD64の環境をIA-32のシステムでmount したらどうなるのだろう・・・試してないので分かりません [↩]

簡単なように思えて，結構ハマったのでメモしておきます．
SSH サーバは既に稼働していることを前提に書きますので，SSH，SSHd の細かい設定は他サイト様に委ねます．

仕様および前提

sftpを許可するユーザ: ftpuser（シェルでのログイン不可）
ftpuserの所属グループ: ftpgroup
ftpuserのhome: /home/ftpuser
ftpuserに公開したいディレクトリ: /pass/to/chrooted

環境

$ lsb_release -drc
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric

$ uname -r
3.0.0-13-generic

$ ssh -v
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011

まずサーバ側でftpgroup，ftpuser を作成します．

# groupadd ftpgroup
# useradd --create-home --home /home/ftpuser --shell /bin/false -g ftpgroup

確認

$ getent group | tail -n 1
ftpgroup:x:133:ftpuser

$ getent passwd | tail -n 1
ftpuser:x:1001:133::/home/ftpuser:/bin/false

/etc/group や/etc/passwd を直接編集するという強行手段でも構わないのですが，ログオフが必要な上に結構危険です．
編集するにしても，vigr やvipw という専用のコマンドがあります．

クライアント側でRSA鍵ペアを作成します．既に作成済みの場合，飛ばしてください．

$ ssh-keygen -t RSA -b 2048


できたら，エディタでもUSBメモリでもscp でも構わないので，クライアントの~/.ssh/id_rsa.pub をサーバの/home/ftpuser/.ssh/authorized_keys にコピーします．¹
通常のSSHと同じですね．
パーミッションは以下のように設定します．

/home 　　　　　　　 　 　　 　 755　 　root:root (おそらくデフォルトでOK)
/home/ftpuser　　　　　　 　　　755　 　root:root
/home/ftpuser/.ssh　　　　 　　 700　 　ftpuser:ftpgroup
/home/ftpuser/authorized_keys　 600　 　ftpuser:ftpgroup


処理系によっては，authorized_keys が700 の場合もあるようです．既にSSH ログイン可能なuser の/home/user/.ssh を確認してみてください．
ここで注意しなければならないのが，/home/ftpuser の所有者がroot だということです．とはいえ，ここまでは単にchown すればいいだけです．
問題はここからです．　/pass，pass/to/，/pass/to/chrootedもそれぞれ所有者がroot かつ他ユーザの書き込み不可である必要があります．
「そうすべき」ではなく「そうする必要があります」．
これは，セキュリティの観点からルール化されたものです．詳しい背景はここに書いてあります．
それじゃあ/pass/to/chrootedを/media/hard_disk/ftp にしたいけど，/media/hard_disk の所有者は一般ユーザに残しておきたい・・・ということができないかというと，そんなことはありません．以下に方法例を書いておきます．と言ってもSimLink貼るだけです．

# cd /home/ftpuser
# ln -s /pass/to/chrooted ./
# chown root:root /pass/to/chrooted
# chmod 755 /pass/to/chrooted


/home/ftpuser の所有者はroot に設定してあるので，/pass，/pass/to（あるいは/media，/media/hard_disk）の所有者がroot である必要はなくなります．
また，/pass/to/chrooted の所有者はroot である必要があるのですが，/pass/to/chrooted/data の所有権はftpuser:ftpgroup で構いません．
普段使ってるユーザをftpgroup に加えておくか，/pass/to/chrooted/data のパーミッションを777 にでも設定すれば管理が楽でしょう．おそらく前者のほうがセキュリティ的には好ましいと思われます．

次に/etc/sshd_config をエディタで編集します

#AuthorizedKeysFile %h/.ssh/authorized_keys
AuthorizedKeysFile %h/.ssh/authorized_keys

#Subsystem sftp /usr/local/libexec/sftp-server
Subsystem sftp internal-sftp

# 最後の行に以下を追記．全角スペースは半角に変換
Match user ftpuser
　ChrootDirectory /home/ftpuser/chrooted
　AllowAgentForwarding no
　X11Forwarding no
　AllowTcpForwarding no
　ForceCommand internal-sftp


internal-sftp を使うのは，ftpuser はchroot をかけたディレクトリの外に出られないからです．
つまり，/usr/local/libexec/sftp-server にもアクセスできなくなるからです．

書けたら

/etc/init.d/ssh restart

クライアント側からサーバ（192.168.1.1）にアクセスしてみます．ssh -p の-p はポートですが，sftpでは-P（大文字）です．

$ ssh -p 10000 ftpuser@192.168.1.1
Enter passphrase for key '/home/client_user/.ssh/id_rsa':
This service allows sftp connections only.
Connection to 192.168.1.1 closed.

$ sftp -P 10000 ftpuser@192.168.1.1
Enter passphrase for key '/home/client_user/.ssh/id_rsa':
Connected to 192.168.1.1.
sftp> exit


上手くいかなければssh -v，sftp -v してみれば何か分かるかもしれません．
もう一度，所有権をまとめて書いておきます．

/home/ftpuser/:
drwxr-xr-x root:root .
drwxr-xr-x root:root ..
lrwxrwxrwx root:root share -> /pass/to/chrooted

/home/ftpuser/.ssh:
drwx------ ftpuser:ftpgroup .
-rw------- ftpuser:ftpgroup authorized_keys

/pass/to/chrooted
drwxr-xr-x root:root .
drwxrwxrwx ftpuser:ftpgroup data

nautilus のFile -> Connect to Server にでも登録しておくと便利かもしれません．

参考サイト
restrictive ssh problem (ForceCommand, ChrootDirectory): Write failed: Broken pipe
あるシステム管理者の日常: sftpとChrootDirectory(3)
　

1. 今回はPC1 -> PC2 へはssh可能，PC2 -> PC1 へはsftp のみ可能としたかったので，scp 使えるならsftp 要らないじゃん，というツッコミは無しで． [↩]