筆者について
FreeBSDを通じてOSSにささかな貢献を。
- 日本xrdpユーザ会発起人
- xrdp developer
- FreeBSD developer
OSS活動をご支援いただける方を募集しています
2013-02-03 これからは TigerVNC の時代
■ RealVNC から TigerVNC へ乗り換えるべき理由 (2)
本記事は以下の記事の続きです。
タイトルに「(1)」と書いてある通り、はじめから複数回に分けて書くつもりだったんですが、1年以上放置してました。
結論から言います。VNC の派生ソフトウェアは数多くありますが、本家の RealVNC を含めどれを使っていいのかよくわからなければとりあえず TigerVNC を使っておけばいいです。おすすめです。ついでに検索に引っかかるようにいくつか言わせてもらいます。これからは TigerVNC の時代です。今から新規採用するなら TigerVNC を使っておけば間違いないです。
RealVNC はオリジナルの VNC の開発者が設立した会社の社名であり、同時に製品の名前でもあります(以下、会社を表す場合は RealVNC 社といいます)。よって RealVNC はオリジナルの VNC の正当な後継となる製品です。このため「VNC って色々種類があってよくわからないしとりあえず本家っぽい RealVNC を使っとこう」という感じで使われることが多いのですが、RealVNC を使う理由がこの程度であれば TigerVNC を使うことをおすすめします。
ライセンス上の問題 (商用利用ができないなど)
RealVNC にはオープンソース版とプロプライエタリ版の2つに大きく分けられ、さらにプロプライエタリ版をエディションで区別すると以下の4つのエディションがあります。
- オープンソース版
- Free Edition
- Personal Edition
- Enterprise Edition
このうち、無料で使えるのは GPLv2 でライセンスされているオープンソース版と Free Edition の2つです。 RealVNC 社によって公開されているオープンソース版 RealVNC の開発は既に停止していて、4.1.3が最終版です(後述)。この記事を書いた時点でのプロプライエタリ版の最新バージョンが5.0.4なのに比べると遥かに古いです。
一方、新しい方の Free Edition ですがこちらは商用利用することができません。個人での非商用利用に限られています。 企業などで RealVNC の無料版を使っている場合、バージョン 4.1.3 以前を使わなければライセンス違反となる可能性があります。 5以降のバージョンも無料で使えるから会社で使おうと考えている人は、記憶に新しい Adobe CS2 無償配布祭りを思い出してください。
多くのネットワーク帯域を必要とする＆通信が暗号化されない
無料で使えるオープンソース版及び Free Edition は通信データが圧縮されない(全く圧縮していないわけではない)ので、LAN内で使用するにはあまり問題ないものの、インターネット経由で使う場合、消費するネットワーク帯域の多さや動作の重さが問題になります。また、RealVNC 4.1.3 では送信される画面のデータやキーストロークは暗号化されないためそのままではインターネット経由で使用するのは避けるべきです。
オープンソース版はバージョンが古い
GPLv2 で公開されているオープンソース版は、RealVNC 社による開発は終了していて既に時代遅れです。例えば前回の記事で触れたように、スクリーンのサイズを動的に変更する XRandR や他の多くの X 拡張を使うことができません。
もちろんソースコードが公開されているので、オープンソース版 RealVNC の4.1.2や4.1.3をベースにした派生 VNC が数多く存在します。 しかし、数多くの派生ソフトウェアが存在するために実装がバラバラで、異なる VNC 同士で通信すると互換性のために古い RFB プロトコルが使用され、せっかく追加された機能が使えなかったり、ネットワーク帯域や暗号化の問題が解決されなかったりします。
次に、数多くの VNC 派生ソフトウェアの中でなぜ TigerVNC を選択するべきなのかを説明します。
TigerVNC を選ぶ理由
ざっと上げてみるとこれだけあります。
- 最も後発のプロジェクトで開発が活発
- Red Hat 社や ThinLink 社などが開発に参加している
- TightVNC や TurboVNC の開発者が TigerVNC の開発に合流した
- Fedora などいくつかの Linux ディストリビューションで採用されていて RealVNC を置き換える傾向にある
- 多くの VNC 派生ソフトウェアの実装を整理して集約しようとしている
- 画面の動的リサイズに対応している
RHELの開発メーリングリストに流れたメールによると、TigerVNC は2009年2月末頃にスタートしたプロジェクトです。今は2013年なので、もう5年目に入るプロジェクトですが TightVNC の開発者や TurboVNC の開発者が合流したことにより、バラバラに拡張されていた各々の VNC も整理されつつあります。 また、Fedora プロジェクトや RHEL が採用したことで、Red Hat 社の社員が開発に参加したり、シンクライアントメーカーである ThinLink 社もプロジェクトに参加したりしているので、しっかりした開発体制となっています。
他の Linux ディストリビューションにも採用されつつあり、これからは TigerVNC が VNC の標準的な存在になっていくと考えられます。
というわけで TigerVNC は多数ある VNC の派生ソフトウェアを統一して、分散していた開発者を集め労力を集中させるべく生まれたプロジェクトであるため、TigerVNC を使っておけば間違いないです。
TigerVNC プロジェクト発足の経緯
上で取り上げた TigerVNC プロジェクト発足の経緯を説明した Adam Tkak メールの日本語訳を置いときます。
どうして(Fedora 11 の)ベータフリーズの直前に突然 TightVNC の機能が TigerVNC に改名されたのか、 その背景を説明させてください。 Fedora 10 では RealVNC をベースにした VNC を採用していましたが、開発元の RealVNC 社が Fedora プロジェクトの作成したパッチを受け入れようとしなかったため、私達は Fedora 11 では RealVNC を TightVNC で置き換えることにしました。 Fedora 11 に採用されるはずだった現在の TightVNC の "trunk" ブランチは、RealVNC と同じ コードをベースにしています。TightVNC プロジェクトは RealVNC に "Tight" エンコーディング拡張や 他の便利な機能を追加しました。私は1年前に TightVNC の開発に参加し、すべての Fedora によるパッチを 移植することに成功しました。 しかし残念なことに、TightVNC のリーダー開発者は UN*X 版の次のリリースの計画を示すことができませんでした。 UN*X 版の開発者は皆、何の機能が次のバージョンに入るのか、いつリリースされるのか尋ねました。 マイルストーン(リリース目標)なしに開発を続けることが何人かの開発者には受け入れがたかったため、 TigerVNC を派生させました。 TigerVNC は2週間前に始まったばかりの新しいプロジェクトです。TightVNC に残っていたアクティブな UN*X 版の開発者は皆 TigerVNC に参加しました。TurboVNC (3D ゲームなどのパフォーマンスにフォーカスした VNC) のリーダー開発者も参加したので、私達は TightVNC より良い未来があると考えています。 公式の声明もあります(リンク切れ) 以上の理由により、TigerVNC は TightVNC より優れたものになると考えているため、可能な限り早く TigerVNC に 切り替えることを決断しました。
TigerVNC プロジェクト発足の経緯 その2
もうひとつ、各々の VNC 派生ソフトウェアを統一して TigerVNC プロジェクトを立ち上げた中心人物の声明の日本語訳も。 原文はこちら。
Virtual Network Computing テクノロジーは本当に素晴らしいものです。 数百万のユーザがいて、また VNC に触発されて派生した実装やプロジェクトも多数あります。 オープンソースライセンスがコードとアイデアの共有を促し、コミュニティの発展を進めました。 しかし、多すぎる派生実装が開発の成果とユーザの支持を分散させてしまっています。 この6年間、私は VNC コミュニティ、特に TightVNC プロジェクトで協力とで統一に奔走しました。 そして私達は大きな進歩を成し遂げました。1年ほど前に TurboVNC の開発者と Fedora VNC の メンテナがこの勢力に参加したため、私達はこの技術を更に上のレベルの成功へ導き、開発を 加速させることができると信じています。 しかし最近、TightVNC プロジェクトはこの開発をサポートすることができないことが明らかになりました。 これが TigerVNC プロジェクトを発表している理由です。このプロジェクトは TightVNC の trunk の ソースツリーをベースにしています。私達のターゲット層は TightVNC と比べて若干異なるかも しれませんが、私達は高性能で安定した包括的な VNC の実装を提供することを目指しています。 Windows, Linux, そして Java といった複数のプラットフォームのサポートも続けていきます。 最新世代の X.Org は既に導入済みです。 加えて、私達の狙いは 当初 VirtualGL プロジェクトで開発されていた拡張を TurboVNC から マージすることです。Cendio AB はこの取り組みを後援します。 私達は統一するという精神を持っているのに、新たな別の VNC を派生させることは間違っているように 見えるかもしれません。しかし実際は、TightVNC プロジェクトが 4年前に /trunk ソースツリーを 作ってから分岐しました。 TightVNC のコアチームは別のブランチで開発をしています。 /trunk ソースコードをベースにした TightVNC のリリースはなく、異なるブランチ同士をマージ する取り組みも行われていません。 /trunk ブランチを独立したプロジェクトとして開発を続ける ことが前進するための手助けとなるのです。例えば、今私達はバザール方式の開発モデルをとる ことができるのです。 TightVNC の実装は近いうちにリリースされる Fedora 11 と ThinLinc 3.0.0 というソフトウェアに 含まれる予定です。詳しい情報については http://tigervnc.sourceforge.net/ を訪れてください。 Pierre Ossman, Cendio AB Adam Tkac, Red Hat, Inc. DRC, TurboVNC メンテナ を代表して Peter Åstrand, Cendio AB
2013-02-02 走るー走るー
■ E-EK2 の走行距離が17万キロを超えたので1万キロ走行にかかった日数を計算してみた
先日タイヤ交換したけどそういえば走行距離17万キロ超えてた。
16万キロに到達したときにもオドメーターの写真を撮ってたので走行ペースを計算してみる。この写真を取ったのは2012年6月29日。
17万キロ到達したのが1月19日だった。
差し引き205日間で1万キロなのでこれを Google 電卓 に突っ込んでやる。
(10 000 km) / (205 days) = 48.7804878 km / day
1日あたり 49km だった。1年間で換算すると 17804 km まあそんなもんか。このペースだと次の車を買う前に廃車になってしまいそう…。
2013-01-29 FreeBSD とどこでもいっしょ
■ FreeBSD で X11rdp のビルドに成功＆野良 port を作成しました
FreeBSD で x11rdp のビルドに成功しました。X11rdp は xrdp のバックエンドとして動く X サーバです。
xrdp の FreeBSD port である net/xrdp は今のところ net/vnc (RealVNC) に含まれる Xvnc を X セッションの生成に使用していますが、既存のセッションに再アタッチするには解像度と色深度が一致する必要があり、Windows 同士でのリモートデスクトップの使い勝手には及びませんでした。Xvnc の代わりに X11rdp を使用することで Windows 同士でリモートデスクトップ利用するときにかなり近い使い勝手で xrdp を利用できるようになります。
ひとまず X11rdp のビルドに成功したので野良 port を作成しましたので公開しておきます。いつもは redports のリポジトリを公開していますが、redports がまだ復旧していないため github にリポジトリを作成しました。今回ビルドに成功したのは X11rdp のリビジョン 299 です。
まだ気になる部分がたくさんあるので正式に port として登録するのは少し先のことになると思いますがひとまずこれで公開という事で。
2013年6月10日追記
上の github のリポジトリは今は更新していないので、下記の redports のリポジトリからチェックアウトしてください。
■ Finally succeeded to build X11rdp on FreeBSD and made an unofficial port!
I finally succeeded to build X11rdp on FreeBSD!
X11rdp is an X server built for xrdp. FreeBSD port net/xrdp uses Xvnc in net/vnc (RealVNC) to make X sessions for now. But xrdp is not fully functional with Xvnc due to lack of some extensions. XRandR extension is required to resize existing session, XFixes to use clipboard (copy & paste), and so on. In addition, AUTOMATIC resizing won't be available even if Xvnc supported XRandR. If you want to resize screens automatically when you reconnect to existing session, xrdp requires X11rdp.
I made X11rdp's FreeBSD port and you can see it on github. The port is still unofficial because I still have lots more to work on. But in the near future, I submit a PR in order to register my port in official ports tree.
Anyway, please check it out!
Added on June 10, 2013
I no longer the github repository above, please check it out from my redports' repository.
2013-01-26 タイヤ交換
■ オートウェイで買った1本1570円の激安タイヤ Corsa を試してみたら普通だった
中古でシビックを手に入れたときについていたタイヤがあまりにもボロボロだったので交換しました。 下の写真のような状態で、溝はたっぷりあるもののひび割れが酷くあるのは溝だけという有様。これでよく半年1万キロ走ったな…。
今乗っている EK2 は次の車(ロードスターあたり)を買うまでのつなぎなので、この車にかけるお金があったら次の車の資金に突っ込みたい。というわけであまりお金をかけずに最低限必要な整備だけで乗るために格安タイヤに手を出してみました。
選んだのは1本1570円のCorsa 60 185/60R14 82H。インドネシア製らしいです。送料が4本で4200円もしたので結局1本あたり2620円になるけど、それでも十分安いので文句はなしです。実は1本1270円のサイレンというタイヤも選択肢にあったのですが、Corsa を売っているオートウェイの本社倉庫が福岡県京都郡苅田町にあるので、福岡県内ならこっちの方が届くのが早そうというのと、サイレンは中国製なので避けて Corsa にしました。実際に金曜日の午前中に注文してから24時間内に届きました。
こういう感じでタイヤが届いて、いざタイヤを積んでお店に持って行こうとしたら、リアハッチについている2本のタワーバーが 邪魔で積めなかったので4本束ねてあるのをバラして積みました。組替は持ち込みのタイヤ取り付けをやっているお店にお願いしました。費用はあとでまとめます。
で、実際に走ってみた感想は…普通でした。何がすごいのかというと、1本1570円のくせに普通なんです。 特に優れたところがあるというわけではないです。ボロボロのタイヤから新品タイヤの交換なので食いつきの良さに最初だけ感動するのは当然として、それ以外は普通です。あとはバリが多いくらい。若干ウェットのグリップが弱い気がしますが前のボロタイヤよりは遥かにマシだし普通に走れるし、買い物に行くくらいの用途ならこれで十分。
かかった費用まとめ。
- タイヤ本体 1570円/本
- タイヤ送料 1050円/本
- タイヤ交換(脱着、組替、バランス工賃込み) 1000円/本
- 廃タイヤ処理費用 250円/本
- バルブ交換 250円/個
タイヤ交換の方の費用は消費税別なので、税込で全部足すと16780円でした。4本新品タイヤに変えて17000円弱、結構安く上がったと思います。
ついでに同じようにオートウェイで見つけた Corsa タイヤを AW11 に装着した人のブログを見つけたので貼っておきます。
2013-01-14 pkgng
■ 従来のパッケージ管理から pkg (pkgng) に移行してみる
FreeBSD のパッケージ管理を pkg (pkgng) に移行してみます。pkgng については今更説明するほどのものでもないので FreeBSD Daily topics を参照してください。
環境は 9.1-RELEASE で普通にデスクトップ環境として使っていたもので、900近いパッケージが既にインストールされているので全 ports をインストールし直しとかそういう面倒なのは極力避ける方向で。
[meta@icepick ~]$ pkg_info|wc -l
882
はじめに ports-mgmt/pkg をインストール。これはまだ従来のパッケージ管理方法でインストールします。
# portinstall ports-mgmt/pkg
pkg_info から pkg がインストールされているのが確認できれば OK。
次に root で pkg2ng を実行する。
[meta@icepick ~]$ sudo pkg2ng パスワード: Creating backup pkg_info(1) database directory in /var/db/pkg.bak. pkg: duplicate directory listing: /usr/local/lib/X11/fonts/GentiumBasic/, ignoring Installing GentiumBasic-110... done Installing ImageMagick-6.8.0.7... done Installing ORBit2-2.14.19... done Installing OpenEXR-1.7.0... done Installing OpenSP-1.5.2_2... done Installing Thunar-1.6.2_1... done ... !!! Some packages failed to register !!! Please fix them by upgrading them or removing them or rerun "PERMISSIVE=yes pkg2ng" if you *really* must Failed packages: xorg-server-1.7.7_6,1
なんかエラーになった。 途中のログ出力を見てみると、
Installing xorg-server-1.7.7_6,1...pkg: xorg-server-1.7.7_6,1 conflicts with tigervnc-1.2.0 (installs files into the same place). Problematic file: /usr/local/man/man1/Xserver.1.gz Registration of xorg-server-1.7.7_6,1 failed. name: xorg-server version: 1.7.7_6,1 origin: x11-servers/xorg-server comment: | X.Org X server and related programs maintainer: x11@FreeBSD.org prefix: /usr/local licenselogic: single deps:
これは自分で作った野良 port が原因だったのでひとまず PERMISSIVE=yes をつけて再実行して終了。
あとは /etc/make.conf に
WITH_PKGNG=yes
と書いておく。
2012-12-27 2012年のラストコミット？
■ FreeBSD ports/173566: net/xrdp のインストール時の挙動を変更
ports/173566 がようやくコミットされました。PR を出したのが丁度不正侵入が検知されたのと同じ日だったのと 9.1-RELEASE の ports freeze 中だったためにコミットまでにかなり時間がかかりました。
日本の FreeBSD ユーザの中で net/xrdp のユーザはかなり少ないと思うのですが、今回の変更について解説します。
- インストール時にサーバの鍵ペアを新しく生成するように変更
- xrdp と xrdp-sesman の2つのデーモンを独立して制御できるように起動スクリプトを修正
1番はセキュリティ上の都合で RDP の暗号化に使用する鍵をインストール後に自動生成するように変更しました。これまでは配布物に含まれる鍵をそのまま使用していましたが、これでは十分にセキュアでないので sshd などで初回起動時にホスト鍵を自動生成するのと似たような挙動にしました。配布物に含まれる鍵がそのまま使われていた場合、鍵を再生成します。
pkg-message が表示される前にこんなのが出ていれば鍵が再生成されています。
===> Installing rc.d startup script(s) Generating 512 bit rsa key... ssl_gen_key_xrdp1 ok saving to /tmp/xrdp-0.6.0_2_1/etc/xrdp/rsakeys.ini
2番は xrdp を単なる RDP ゲートウェイとして使う場合など、xrdp のセッションマネージャである xrdp-sesman を同じホスト上で動かす必要がない場合のために、xrdp と xrdp-sesman の起動を独立に制御できるようにしました。pkg-message を見るとわかりますが、rc.conf への記述が少し変更になっています。xrdpsesman_enable="YES" と書いていたものが xrdp_sesman_enable="YES" に変わりました。
xrdp_enable="YES" # これは変更なし xrdpsesman_enable="YES" # これまで xrdp_sesman_enable="YES" # これから(必須でなくなった)
2012/12/27 3:30 追記
ports/173566 でコミットされたインストール時の RSA 鍵ペア生成ですが、うまく RSA 鍵を生成できていなかったため、 これを修正する ports/174721 を submit しました。
2013/01/15 8:00 追記
コミットされました。今後は
- net/xrdp - xrdp 0.6.0 系 重要な更新のみだけを行う
- net/xrdp-devel - xrdp 0.7.0 系 最新の開発ツリーを取り込む
という方針でメンテナンスを行っていく予定です。
2012-12-26 年末
■ Happy Hacking Keyboard Lite2 分解洗浄
年末なので大掃除がてら Happy Hacking Keyboard Lite2 を分解洗浄しました。
2枚目の写真にチラッと写っているキートップリムーバーでキートップを外して、洗面器へ。
いつも手に触れるものなので手垢だらけに違いない。手垢と言えばお風呂の洗剤(黄色い液体洗剤)なので洗面器に泡を噴射して揉み洗い。仕上げにタンパク質といえば塩基で溶けるので塩素系漂白剤を薄めて浸けおきしました。最後に組み立てておしまい。すっきりしました。
Happy Hacking Keyboard Pro2 を組み立ての参考に…しようと思ったら無刻印＼(^o^)／
2012-12-25 メリークリスマス
■ 2012年12月24日現在の redports.org の復旧の進捗状況
redports.org の公式 Twitter アカウントによると、
Chances are good that the security review will happen after the christmas holidays. So have a merry christmas and we will be back next year!
— redports.orgさん (@redports) 12月 24, 2012おそらくクリスマス休暇の後にセキュリティ監査が行われます。年明けには復旧するので良いクリスマスを送ってください。
という感じ。システムの再構築はひと通り終わっていて、セキュリティ監査をして安全性が確認できたら再オープンとみてよいでしょう。
ここでのクリスマス休暇がどの程度の休みを指すかによって少し復旧予定が変わってきますが…。 25日のクリスマス祝日が明けてから年末にかけてセキュリティ監査を行って、年明け1月2日以降にオープン。または1月2日以降にセキュリティ監査を行ってオープンはそのさらに後、のどっちかでしょう。
2012-12-13 the status of redports
■ redports.org の現在の状況と復旧計画について
FreeBSD の porter にとって大変便利なツール redports.org ですが、2012年11月のインシデントの影響によりクラスタがダウンしているため、2012年11月10日頃よりサービスと停止しています。
復旧予定について freebsd-ports@ メーリングリストで尋ねてみたところ、
The bottleneck right now are people that can do the security audit and verify carefully which machines are safe and which we need to setup from scratch. I honestly don't know and I'm unable to make an educated guess so all I can do is to inform people once I have some news. But we are surely talking about days or weeks because otherwise I'll reactivate my box in the basement ... Sorry that this incident knocked redports down for such a long time. Redports still isn't critical enough to the project that it gets dealt with immediately so the plan is clear. We need to provide services to the src people and something nice for cluster admins, security teams and core to make them feel the pain like we do when redports is offline.
とのことです。簡単に雑に訳すと、
今ボトルネックになっているのは人的な資源で、セキュリティ監査と行うことのできる人と、スクラッチから構築し直す必要のあるマシンが安全であることを慎重に検証する人の手がボトルネックです。 正直なところ、redports がどのくらいで復旧できるのか正確な予想はできません。私にできるのは何か新しいニュースがあるたびにそれを伝えることだけです。(略) このインシデントが redports のこんなにも長いダウンを引き起こしてしまったことを申し訳なく思います。 Redports はまだ FreeBSD プロジェクトにとって直ちに復旧させるほど重要ではないため、復旧の計画は白紙です。(略)
とのことです。メーリングリストに質問した次点では 9.1-RELEASE のリリース前だったため、そちらのソースコードが侵入の影響を受けていないかをチェックするのに人員を割いていて、コアサービスでない redports にまで人をまわす余裕がなかったようです。
現在は redports の公式 Twitter アカウントができたばかりで、そちらで状況が逐一得られるようなので @redports をフォローしておくとよいでしょう。
つい先ほど、redports の svn リポジトリが11月10日時点のバックアップから復旧したようです。やった！！
svn.redports.org is somewhat available again! It is read-only right now because it was rebuild from the backup from 2012/11/10
— redports.orgさん (@redports) 12月 12, 20122012-12-10 Update japanese/skk-jisyo to 201212
2012-10-13 ZFS! ZFS!
■ ZFS シングルドライブ構成からミラーを経てプールを拡張する
新しいハードディスクを買ったので環境を引越します。
一昔前ならシングルユーザモードで起動してスライスごとに、
# dump -0b 512 -f 0 / | (cd /mnt ; restore -rb 512 -f -) # dump -0b 512 -f 0 /usr | (cd /mnt/usr ; restore -rb 512 -f -) # dump -0b 512 -f 0 /var | (cd /mnt/var ; restore -rb 512 -f -)
なんてやってたのが ZFS なら楽々です。電源を落とすのは新しいハードディスクを取り付ける1回だけ。古いハードディスクはデタッチするだけで取り付けたままにしておいても別に困らないので。ホットスワップ対応なら電源を落とす必要すらない！素敵！
新しいハードディスクは smartmontools で確認してみたら 4K Sectors と出ているので4Kセクタの製品らしい。 出力を見た感じローレベルフォーマットではセクタサイズ4KBなのに、ソフトウェア的には512バイトのように振る舞うちょっと厄介な製品。
# smartctl -i /dev/ada1 === START OF INFORMATION SECTION === Model Family: Seagate Barracuda (SATA 3Gb/s, 4K Sectors) Sector Sizes: 512 bytes logical, 4096 bytes physical
既存のディスクはこんな GPT パーティション構成になってます。
$ gpart show ada0
=> 34 976773101 ada0 GPT (465G)
34 128 1 freebsd-boot (64k)
162 16777216 2 freebsd-swap (8.0G)
16777378 959995757 3 freebsd-zfs (457G)
新しいディスク単独で動作させる予定なので1台目のドライブと同じ様に ada1 に GPT パーティションを切りますが、4Kセクタに境界を合わせるため、-a 4k オプションをつけます。
# gpart create -s gpt /dev/ada1 ada1 created # gpart add -a 4k -s 64k -t freebsd-boot ada1 ada1p1 added # gpart add -a 4k -s 8G -t freebsd-swap -l swap1 ada1 ada1p2 added # gpart add -t freebsd-zfs -l disk1 ada1 ada1p3 added
最終的にこういう構成になる。構成は必ずしも全く同じである必要はなく freebsd-boot と freebsd-zfs の2つがあればなんとかなると思います。
$ gpart show
=> 34 976773101 ada0 GPT (465G)
34 128 1 freebsd-boot (64k)
162 16777216 2 freebsd-swap (8.0G)
16777378 959995757 3 freebsd-zfs (457G)
=> 34 3907029101 ada1 GPT (1.8T)
34 6 - free - (3.0k)
40 128 1 freebsd-boot (64k)
168 16777216 2 freebsd-swap (8.0G)
16777384 3890251744 3 freebsd-zfs (1.8T)
3907029128 7 - free - (3.5k)
新しいドライブにブート用のコードをインストールする。
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 bootcode written to ada1
いよいよ ZFS でミラーリング。ミラーする前はこんな状態です。 後からミラープールを作成するにはOracleのミラー化ルートプールを作成する方法 (インストール後)を参照。
$ zpool status zroot pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 errors: No known data errors
新しいドライブの3つ目のパーティションをアタッチ。
# zpool attach zroot ada0p3 ada1p3 Make sure to wait until resilver is done before rebooting. If you boot from pool 'zroot', you may need to update boot code on newly attached disk 'ada1p3'. Assuming you use GPT partitioning and 'da0' is your new boot disk you may use the following command: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
ブートコードを新しいディスクにも入れろ的なことを言ってくるけどさっきやったのでスルー。
新しいディスクをアタッチした後にステータスを見るとこんな感じ。ZFS ではミラーを作ることを silver というみたい。ちょっとカッコいい。
$ zpool status zroot
pool: zroot
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sat Oct 13 23:01:46 2012
1.11G scanned out of 84.9G at 2.43M/s, 9h49m to go
1.11G resilvered, 1.30% done
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0 (resilvering)
errors: No known data errors
ミラーリングの途中経過を表示させておくには sysutils/topless を使って
$ topless "zpool status zroot"
とするのがおすすめです。
ミラーが完了したら古いドライブをデタッチする。
# zpool detach zroot ada0p3
プールの状態を確認してみると、あれ…サイズが大きくなってない。
$ zpool list zroot NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 456G 85.3G 371G 18% 1.00x ONLINE -
zpool のマニュアルを見ると、-e オプションをつければ容量の拡大ができると書いてあったのでやってみる。
zpool online [-e] pool device... Brings the specified physical device online. This command is not applicable to spares or cache devices. -e Expand the device to use all available space. If the device is part of a mirror or raidz then all devices must be expanded before the new space will become available to the pool.
で、実際にやってみると無事に容量が拡大されました。めでたしめでたし。
# zpool online -e zroot ada1p3 $ zpool list zroot NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 1.81T 85.5G 1.73T 4% 1.00x ONLINE -
参考にしたページ
2012-10-12 検品・選別・返品
■ 購入したハードディスクは smartctl でセルフテストをしてから使い始めよう
アマゾンで買って昨日届いたハードディスクが壊れていたので、返品・返金の手続きをして新たに3台注文しました。今度はヤマト運輸の配送で、昨日の今日で届きました。
いちど壊れたものが届いた以上、次に届くものも壊れていないとは限らないので冗長性を持たせて3台注文、壊れてない1台を選んで残りの2台は返品します。原則全額返金がアマゾンの返金ポリシーです。
ハードディスクのセルフテストをするには FreeBSD なら sysutils/smartmontools をインストール。/usr/local/sbin/smartctl に -t オプションを付けると利用可能なセルフテストの種類が出てきます。
とりあえず conveyance test を実行します。conveyance test は輸送中に障害が起きやすいセクタをテストするらしいです。
# smartctl -t conveyance /dev/ada1 smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.1-RC2 amd64] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Conveyance self-test routine immediately in off-line mode". Drive command "Execute SMART Conveyance self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 2 minutes for test to complete. Test will complete after Fri Oct 12 22:15:29 2012 Use smartctl -X to abort test.
テストには2分かかるようなので、2分待ってから smartctl -a します。
# smartctl -a /dev/ada1 (snip) SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Conveyance offline Completed without error 00% 0 - # 2 Short offline Completed without error 00% 0 -
short test も行ったあとの結果なのでその結果もついてますが、Conveyance offline のところが Completed without error になっていれば異常なし。short についても異常なしだったのでOK。本当は long test も実施したいところですが、4時間近くかかってしまうので見送り。
セルフテストの結果以外にも Raw_Read_Error_Rate と Seek_Error_Rate の値は気にしておきます。
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 006 Pre-fail Always - 14048 7 Seek_Error_Rate 0x000f 100 253 030 Pre-fail Always - 160
一見すると RAW_VALUE がヤバそうですが、通常 RAW_VALUE は無視して VALUE の方を見ます。VALUE が THRESH を下回ってなければ問題なし。最近のハードディスクは記録密度が非常に高いので読み取りエラーは必ず発生します。エラー訂正できていれば問題なし。
テストの結果は、3台とも問題なしでした。今回は3台のうち最も状態のいい1台だけを選んで残りの2台を返品するので、RAW_VAUE の値も考慮しました。
まーそんな感じ。
最初に買った1台が壊れていたので3台買って1台選んで2台返品するという特殊なケースでしたが、新しいハードディスクを買ったら使う前にセルフテストをすることをオススメします。
2012-10-11 アマゾン
■ アマゾンで買ったハードディスクが壊れていたので返品
アマゾンでハードディスクを買いました。 Seagate の Barracuda 7200.14 ST2000DM001 です。
配送が佐川急便だったので案の定というか、やっぱりというか、壊れていました。
dmesg にはこんなメッセージが出力され、
(ada1:ata4:0:0:0): Retrying command (ada1:ata4:0:0:0): WRITE_DMA. ACB: ca 00 02 00 00 40 00 00 00 00 20 00 (ada1:ata4:0:0:0): CAM status: ATA Status Error (ada1:ata4:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (ada1:ata4:0:0:0): RES: 51 04 02 00 00 00 00 00 00 20 00 (ada1:ata4:0:0:0): Error 5, Retries exhausted (ada1:ata4:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada1:ata4:0:0:0): CAM status: Command timeout (ada1:ata4:0:0:0): Retrying command
gpart で GPT パーティションを切ろうにも
# gpart add -s 8G -t freebsd-swap -l swap1 ada1 gpart: Input/output error
という有様。smart でのヘルスチェックもできず。
ハードディスクをこんな梱包で送ってきたらそりゃ壊れるよ…佐川だし。というわけですぐに返品の手続きをとって、箱に詰めなおして佐川急便の営業所にに持って行きました。受け取ってからわずか2時間でした。
返品の際には「交換」ではなく「返金」を選択、同じ Barracuda 7200.14 ST2000DM001 を今度は3台、お急ぎ便で注文しました。メーカーである Seagate に直接 RMA の申請をすることも考えたんですが、代わりの品が届くまで2週間近くかかるようなのでやめました。Amazon のお急ぎ便で注文すれば翌日届くし。
改めて注文したハードディスクがまた壊れていたらたまらないので、冗長性を持たせるため3台注文しました。 3台のハードディスクが届いたらそれぞれテストし、壊れていない1台を選んで、残りの2台は壊れているか否かにかかわらず返品するつもりです。3台注文したら1台のときより梱包も立派になることも期待。
さすがに初回の注文でハードディスクを複数台注文して、すべて開封した後に1台だけ抜き取って残りをすべて返品、とかいうことを繰り返すとアマゾンのブラックリスト行きになりそうですが。今回は最初に1台だけ注文して、その1台が壊れていたから3台買って2台返品するので大丈夫なはず…たぶん…多分大丈夫…。
RMA するなら参考になりそう。
Before...
Σ tact [ソースをDLしましたが、WEBにも解凍したフォルダの中にもインストール方法についての情報が無い。 winswitch..]
Σ meta [> ソースをDLしましたが、WEBにも解凍したフォルダの中にもインストール方法についての情報が無い。 ソースの中の..]
Σ Y [google cloud platformにUbuntu16.04 インストールしてVNCで入ったら灰色の画面(Gr..]