Remedieは15分でインストールできるのか

あらかじめ書いておきますがネタです。

[O] これから15分で Remedie を始めるための資料には

インストール自体は15分で終わらない場合が多いでしょう。

とある。

タイトルと中身が矛盾しているが、環境によりけりということのようだ。そこで、果たして本当に15分でインストールできるかどうか、PerlとRemedieを一からインストールしたときの時間を計ってみた。

0. 準備

Xcodeとgitを入れておく。

正確に時間を計測するために~/.cpanを削除。

% rm -rf ~/.cpan
% 

1. ActivePerlのダウンロード（30秒）

ブラウザでActivePerlのサイトからダウンロードしてもいいが、時間を計測するためにcurlを使う。

% cd /tmp
% time /usr/bin/curl -sO http://downloads.activestate.com/ActivePerl/MacOSX/5.10/ActivePerl-5.10.0.1004-darwin-9.4.0-287188.tar.gz
/usr/bin/curl -sO   0.32s user 1.59s system 8% cpu 23.030 total
% time tar zxf ActivePerl-5.10.0.1004-darwin-9.4.0-287188.tar.gz
tar zxf ActivePerl-5.10.0.1004-darwin-9.4.0-287188.tar.gz  1.45s user 1.17s system 63% cpu 4.144 total
%

2. ActivePerlのインストール（15秒）

お遊びなので/tmp/activeperlに入れる。

% cd ActivePerl-5.10.0.1004-darwin-9.4.0-287188
% time ./install.sh --prefix /tmp/activeperl --license-accepted --no-install-html --no-manifest-check
....
./install.sh --prefix /tmp/activeperl --license-accepted --no-install-html   3.57s user 2.56s system 58% cpu 10.523 total
%

ついでにパスの設定も行う。

% export PATH=/tmp/activeperl/site/bin:/tmp/activeperl/bin:/usr/bin:/bin
%

3. Remedieのダウンロード（10秒）

% cd /tmp
% time /opt/local/bin/git clone git://github.com/miyagawa/remedie.git
....
/opt/local/bin/git clone git://github.com/miyagawa/remedie.git  0.44s user 0.30s system 9% cpu 7.754 total
%

4. 必要なモジュールのダウンロード（18分）

時間を節約するため、依存関係の処理をいちいち聞かないで勝手に処理してくれるように設定。

% export PERL_AUTOINSTALL="--defaultdeps"
%

いざcpanコマンドを実行。途中で5か所プロンプトが出るがリターンを押せばよい。あらかじめ5回リターンを押してもいいはず。ちなみにyesコマンドはLeopardにはついてこないので使わない。

% cd remedie
% time cpan -i .
....
M/MS/MSCHWERN/ExtUtils-MakeMaker-6.50.tar.gz is just needed temporarily during building or testing. Do you want to install it permanently? (Y/n) [yes] リターン
....
*** Press return to continue (or wait 60 seconds) リターン
....
*** Press return to continue (or wait 60 seconds) リターン
....
Do you want to build the XS Stash module? [y] リターン
Do you want to use the XS Stash by default? [y] リターン
....
cpan -i .  582.42s user 125.23s system 66% cpu 17:48.14 total
%

起動。

% bin/remedie-server.pl 
HTTP::Engine::Interface::ServerSimple : You can connect to your server at http://localhost:10010/

まとめ

全部で19分。この記事を書くためにActivePerlとRemedieを10回以上インストールしたが、15分を切ることはできなかった。回線の太さよりもmakeのスピードに依存しそうなので、速いコンピュータなら15分でできるかもと思う。

Remedieをインストール

家の前の川に飛行機が飛んできたのは1月のことだ。家にいながらこれにまったく気づかなかったその夜、消防車や救急車の音で窓の外が騒がしいので見てみたら、川の中に飛行機があって驚いた。とりあえず写真を撮ってブログのネタにした。

飛行機が川に不時着したのはすごいできごとだが、何よりも驚いたのは日本の人たちが事故のことを何時間も前から知っていてTwitterで話題にしていたことだった。

前にも書いたが私はテレビをほとんど見ない。ニュースは新聞が主な情報源で、インターネットでニュースにアクセスするとしても動画はほとんど見ないテキスト派だ。

そういう原始人のような生活から脱却するために、奮起してRemedieを入れてみた。

1. gitをインストール

MacPortsを使っているので簡単インストール。

# port selfupdate
# port install git-core

2. Remedieのダウンロード

[O] これから15分で Remedie を始めるための資料を見ながらやった。

% cd tmp
% git clone git://github.com/miyagawa/remedie.git

3. 必要なPerlモジュールのダウンロード

まずはRemedieのパッケージにREADME.mkdnというファイルがあるのでそれを読む。「cpan -i .」というコマンドを実行するべしとあるのでそのとおりにするとPerlのモジュールが大量にインストールされる。

% cd remedie
% cpan -i .

インストール済みのモジュールがそれなりに多いせいでトラブルもなく5分くらいで終了。

README.mkdnというファイル名は初めて見たが、mkdnはMarkdownの略だそうだ。Markdownはお手軽マークアップ言語。

4. テストがFAILするので微調整

cpan -i .の最後のほうでRemedie自身のテストが行われる。私の環境だとテストが3個Failした。

Test Summary Report
-------------------
t/99_fail.t                                          (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
t/plagger/plugins/CustomFeed-Script/base.t           (Wstat: 1024 Tests: 4 Failed: 4)
  Failed tests:  1-4
  Non-zero exit status: 4
t/plagger/plugins/Discovery-Sites/base.t             (Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=41, Tests=236, 57 wallclock secs ( 0.16 usr  0.16 sys + 31.11 cusr  3.77 csys = 35.20 CPU)
Result: FAIL
Failed 3/41 test programs. 6/236 subtests failed.

t/99_fail.t

一番最初のt/99_fail.tはFailになるように設計されているので無視する。

t/plagger/plugins/CustomFeed-Script/base.t

これはやや複雑で、私のperlが標準のパス（/usr/bin/perl）にないから起こる。t/samplesディレクトリにあるスクリプトを書き替える。

% perl -pi.bak -e 's{/usr/bin/perl}{/usr/bin/env perl}' t/samples/*.pl

つまり、/usr/bin/perlではなくて自分が使っているほうのPerlを呼び出すようにする。

t/plagger/plugins/Discovery-Sites/base.t

このテストは実行するたびにFailしたりしなかったりする曲者である上にVeohなんて初めて使ったから自信がないのだが、t/plagger/plugins/Discovery-Sites/base.tをこのように書き替えたらエラーが出なくなった。

変更前

like $context->update->feeds->[0]->entries->[0]->thumbnail->{url}, qr/ll-images/;

変更後

like $context->update->feeds->[0]->entries->[3]->thumbnail->{url}, qr/(ll-images|img\.youtube|thumbnails\.cbsig|www\.mtv\.com)/;

5. 再テスト

同じコマンドを再度実行し、t/99_fail.t以外は大丈夫なことを確認する。

% cpan -i .
（略）
Test Summary Report
-------------------
t/99_fail.t                                          (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=41, Tests=250, 60 wallclock secs ( 0.16 usr  0.16 sys + 31.77 cusr  3.91 csys = 36.00 CPU)
Result: FAIL
Failed 1/41 test programs. 1/250 subtests failed.

6. Remedieを起動

% ./bin/remedie-server.pl
Mouse::Meta::Class::__ANON__::SERIAL::1: You can connect to your server at http://localhost:10010/

7. フィードを追加

Remedieのページ（http://localhost:10010/）にアクセスすると真っ黒の画面が出るので、「New」を押してフィードを登録する。

まずは地元のテレビ局ny1.comを登録してみる。NY1のサイトに行ってRSSのURLを見つければいいのだけれど、もしかしてと思い直接「ny1.com」を入れてみる。

ちゃんとRSSのURLを見つけてくれた。これには感動。

というわけで今年度の目標は、日本在住の人よりも早くNYのニュースをキャッチすることです。

MacPortsのselfupdateを忘れた→はまる

MacPortsは各portのバージョンや依存関係といった情報をローカルなファイルに保存している。そのportがインストールされていなくても、である。これがちょっとした問題になることがある。

結論を先に書くと、selfupdateは定期的に実行しなければいけない。

例1：ローカルの情報が古いと旧バージョンのportがインストールされる

caml-sqlite3というportを例に説明してみる。現時点でcaml-sqlite3の最新版は1.3.0だ。

ところが、私の環境でcaml-sqlite3を入れようとすると1.2.0を取りに行く。

# port -v fetch caml-sqlite3
--->  Fetching caml-sqlite3
--->  ocaml-sqlite3-1.2.0.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/caml-sqlite3
--->  Attempting to fetch ocaml-sqlite3-1.2.0.tar.gz from http://www.ocaml.info/ocaml_sources/

こうなるのは、私のLeopard上にあるPortfileが古いからだ。このファイルはMacPortsをインストールしたときに作成されている。

# grep version /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/caml-sqlite3/Portfile 
version             1.2.0
distname            ocaml-sqlite3-${version}
#

例2：portがインストールできないこともある

上の場合は旧バージョンの1.2.0がまだ1.3.0同様ダウンロードできるのでまだ良いが、portによっては旧バージョンがダウンロードできない場合もある。p5-errorがその例だ。

# port install p5-error
--->  Fetching p5-error
--->  Attempting to fetch Error-0.17012.tar.gz from http://ftp.ucr.ac.cr/Unix/CPAN/modules/by-module/Error
（略）
Error: Target org.macports.fetch returned: fetch failed
Error: Status 1 encountered during processing.
#

port installの裏側ではError-0.17012.tar.gzを取りに行っているのにサーバ側には最新版（0.17015）しかないためにダウンロードが失敗している。

解決方法

上の問題を解決するにはselfupdateというコマンドを実行する。

# port selfupdate

出力はこれのどちらかになるようだが

• selfupdate done!
• The MacPorts installation is not outdated so it was not updated

どちらにしても/opt/local/var/macports/sources/rsync.macports.org/release/ports/以下のファイルが更新される。

selfupdateを行った後に先のcaml-sqliteでもう一度試してみると無事1.3.0をダウンロードしてくれる。

# port -v fetch caml-sqlite3
--->  Fetching caml-sqlite3
--->  ocaml-sqlite3-1.3.0.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/caml-sqlite3
--->  Attempting to fetch ocaml-sqlite3-1.3.0.tar.gz from http://www.ocaml.info/ocaml_sources/

selfupdateは定期的に実行する

今までselfupdateはその名前からして/opt/local/bin/portのバイナリを更新するだけのものだと思っていたが、実はそうではなかった。MacPortsのWikiにこうある。

Selfupdate is the command used to automatically download new Portfiles so that your local copy of MacPorts is aware of new MacPorts software or upgrades to existing software that have been committed to the MacPorts infrastructure. Additionally, this command is used to update the MacPorts software itself - think of it is a Software Update, like its name suggests.

（抄訳）selfupdateコマンドを使うと更新のあったPortfile群をダウンロードできる。さらに、selfupdateの名前のとおり、インストールされているMacPortsのバイナリ自身を更新する。

Selfupdate is a command that can safely be scheduled to automatically run, as it doesn't actually update your installed software, it just "teaches" MacPorts about new updates. Take a look at using crontabs to run your selfupdate.

（抄訳）selfupdateコマンドは更新情報をダウンロードするだけのものなので実際にソフトウェアの更新を行うわけではない。そのため自動的に実行しても安全だ。

実行しても安全というか、実行しないと更新情報が同期できないのだ。

私のcronの設定

rootのcrontabをこのように設定した。

# 毎日午前1:23にselfupdateを実行
23 1 * * * /opt/local/bin/port selfupdate

どこか気持ち悪い

上記をまとめると、

• MacPortsを安心して使うにはport selfupdateの実行が不可欠
• selfupdateはcronで定期的に走らせるのが一番

となるのだがどうにも気持ち悪い。

ウェブの世界に例えると、ローカルに保存されたPortfileはHTTPのキャッシュに近いが、自分でキャッシュの更新（selfupdate）をしない限りブラウザが永遠に古いキャッシュを参照しているという状態になっている。Yahooで昨日の検索結果が表示されるのは構わないが、昨日の天気予報が出てくるのはいやだ。

サーバの更新情報をローカルに保存する仕組みの是非はともかく、ユーザが何もしないとその情報が更新されないのが腑に落ちない。MacPortsは他のところがうまくできているので、不思議でならない。サーバ側で走らせるデーモンをrsyncだけにしたかったのだろうか。

OS XでRARファイルを扱う

ファイルの圧縮解凍はZIPかLHAかbzip2か、のような不毛な論争は昔からあるけれど、今日はRARという形式のファイルを受け取った。「ここからRARファイルをダウンロードしてください」と言われたのだが、RAR形式のファイルなんて初めて受け取った。

MacintoshでRARを開くにはUnRarXかStuffIt Expanderが定番らしい。が、ソフトウェアは一元管理ができるといいな、と思いMacPortsを見たらちゃんとunrarがあった。

% sudo port install unrar

としてインストール。ファイルの解凍は

% unrar x hoge.rar

とした。ちなみに、RARファイルのダウンロードが異常に遅かったのでダウンロードの途中で

% unrar -kb x hoge.rar

とすると不完全ながら中身を取り出すことができた。

関連記事

• MacPortsを使ってみる

LeopardでApacheを使う・お手軽入門編

LeopardにApacheが入っているのは話に聞いていたが、ちょっとしたAjaxのコードを試したくなりwebサーバを起動した。簡単ではあったがちょっとクセがあるのでメモしておく。

Apacheの起動

デスクトップOSなのに超簡単。

Leopardのシステム環境設定→共有のメニューに進み、「Web 共有」を「入」にする。

これだけで

http://localhost/

が見られるようになるのはすごい。

どうでもいいが「入」「切」って書いてある電気のスイッチを最近見ないような気がする。

トップページを書きかえてみる

なにもせずにhttp://localhost/を表示するとApacheにようこそ、みたいなページが表示される。このファイルの実態は

/Library/WebServer/Documents/index.html（またはindex.html.ja.iso2022-jpなど）

であるため、このファイルを適当に書きかえて保存すればよい。管理者権限が必要。

ちなみに、このディレクトリがどこで設定されているのかというと

/private/etc/apache2/httpd.conf

というファイルである。/privateというディレクトリは馴染みがない名前だが、Leopardでは/etcが/private/etcへのシンボリックリンクなので

/etc/apache2/httpd.conf

に設定ファイルがあると思ったほうが頭に入りやすい。

ともあれ、このhttpd.confの中のDocumentRootがそれである。

# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/Library/WebServer/Documents"

設定を変えた後は必ず再起動

Apacheの設定を変えた後は必ずApacheの再起動をしなければいけない。上記の「入」「切」のスイッチを使って「切」→「入」としても良いが、ターミナルを使って

sudo apachectl restart

または

sudo /usr/sbin/apachectl restart

としたほうが簡単だ。

UserDir（ユーザディレクトリ）の設定

自分専用のLeopardならば/Library/WebServer/Documents以下のファイルを書き替えてテストを続けてもいいのだが、自分のホームディレクトリ下をブラウザで見られるようにしたほうが後の管理が楽である。URLは

http://localhost/~ユーザ名/

となる。この機能は初期状態のままだと使えないので

/private/etc/apache2/extra/httpd-userdir.conf

なるファイルを編集する。

#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites
UserDir disabled
UserDir enabled ユーザ名

<Directory /Users/*/Sites>
    Order deny,allow
    Deny from all
    Allow from localhost
</Directory>
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

の赤字部分を加えればよい。Apacheの再起動後、

/Users/ユーザ名/Sites/index.html

が

http://localhost/~ユーザ名/index.html

で表示できるようになる。

どうしてpublic_htmlではなくてSitesを使うようになっているのかはよくわからない。

CGIの設定

mod_perlもあるし今どきCGIもないだろうと言われると困るが、お手軽に設定をするのが本稿の目的であるために以下を書いておく。

CGIを使うためには、先ほどのhttpd-userdir.confを開き、以下のように編集する。

#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites

UserDir disabled
UserDir enabled ユーザ名

<Directory /Users/*/Sites>    
    Options ExecCGI
    Order deny,allow
    Deny from all
    Allow from localhost
    AddHandler cgi-script .cgi
</Directory>
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

Apacheを再起動した後、/Users/ユーザ名/Sites/hoge.cgiをテスト用に作って実行可能にする。中身はこんな感じにしておけばよい。

#!/usr/bin/perl
print "content-type: text/html\n\n";
print "Hello";

これで

http://localhost/~ユーザ名/hoge.cgi

にアクセスできるようになる。

もしブラウザ上に「Hello」が表示されない場合は、エラーログを見てみるとヒントがあるはずだ。エラーログは

/private/var/log/apache2/error_log

にある。

セキュリティ関係

蛇足ながら、テストが終わったらweb共有を切っておくほうが事故の防止になって良い。

Macportsのcoreutilsコマンド群はなんでも「g」から始まる

CoreutilsはcatやlsといったUNIX上の基本的なコマンドを集めたGNUのパッケージである。これをMacPortsからインストールしたからGNUのコマンド群が使えるようになるぞ、と思っているとハマることになる。Coreutilsを普通にインストールしても、「ls」はインストールされないのである。

% port file coreutils
/opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/coreutils/Portfile  <- coreutilsはインストールされている
% ls --help
ls: illegal option -- -  <- GNUのlsではない
usage: ls [-ABCFGHLPRSTWabcdefghiklmnopqrstuwx1] [file ...]
% which ls
/bin/ls  <- OS標準のlsが使われている
%

実はlsはglsという名前でインストールされている。cp、mv、df、cat、odもそれぞれgcp、gmv、gdf、gcat、godという名前で入る（godって……）。おわかりのとおり、コマンド全部が「g」から始まるようになっている。

これを回避する方法は一応ある。こうやってcoreutilsをインストールすれば余計なgがつかない。

% sudo port install coreutils +with_default_names

ただこれはあまり推奨されていないようで、おすすめはaliasを設定することだそうだ（下の方にalias一覧をつけました）。

---

以下は蛇足。

これはMacports側の設定で「すべてにgをつけるべし」という設定が意図的にされているからである。

configure.args  --program-prefix=g \
                --disable-nls

つい先日MacPortsのメーリングリストでも「lsはlsとして、gをつけない普通の名前で/opt/local/binに入れるようにしませんか」という提案がなされたのだが（ソース）、「既存のシェルスクリプトはOS標準の（BSD系の）lsを想定して書かれているから動かなくなったら困る」という理由で却下されている。

明確なソースが示されていないので実際どのくらいの影響が出るのかは知らないが、記憶をたどるとこの議論、ずっと前から存在する。FreeBSDのportsでも長い間lsはglsとしてインストールされてきた。古いものはあまり確認できないが、少なくとも2000年時点のfileutilsはそうである（ソース）。

個人的にはlsをls以外の名前で呼ぶことはしたくないし、glsなんていちいち打つ人がいるとも思えない。aliasを設定すれば良いというのはもっともらしく聞こえるが、不出来なシェルスクリプトのつけをユーザに回しているだけという気もする。

どちらのlsでも動くシェルスクリプトを作る方法はあとで考えることにして、とりあえずaliasを設定した。

alias base64=gbase64
alias basename=gbasename
alias cat=gcat
alias chgrp=gchgrp
alias chmod=gchmod
alias chown=gchown
alias chroot=gchroot
alias cksum=gcksum
alias comm=gcomm
alias cp=gcp
alias csplit=gcsplit
alias cut=gcut
alias date=gdate
alias dd=gdd
alias df=gdf
alias dir=gdir
alias dircolors=gdircolors
alias dirname=gdirname
alias du=gdu
alias echo=gecho
alias env=genv
alias expand=gexpand
alias expr=gexpr
alias factor=gfactor
alias false=gfalse
alias fmt=gfmt
alias fold=gfold
alias groups=ggroups
alias head=ghead
alias hostid=ghostid
alias hostname=ghostname
alias id=gid
alias install=ginstall
alias join=gjoin
alias kill=gkill
alias link=glink
alias ln=gln
alias logname=glogname
alias ls='gls -F'
alias md5sum=gmd5sum
alias mkdir=gmkdir
alias mkfifo=gmkfifo
alias mknod=gmknod
alias mv=gmv
alias nice=gnice
alias nl=gnl
alias nohup=gnohup
alias od=god
alias paste=gpaste
alias pathchk=gpathchk
alias pinky=gpinky
alias pr=gpr
alias printenv=gprintenv
alias printf=gprintf
alias ptx=gptx
alias pwd=gpwd
alias readlink=greadlink
alias rm=grm
alias rmdir=grmdir
alias seq=gseq
alias sha1sum=gsha1sum
alias sha224sum=gsha224sum
alias sha256sum=gsha256sum
alias sha384sum=gsha384sum
alias sha512sum=gsha512sum
alias shred=gshred
alias shuf=gshuf
alias sleep=gsleep
alias sort=gsort
alias split=gsplit
alias stat=gstat
alias stty=gstty
alias su=gsu
alias sum=gsum
alias sync=gsync
alias tac=gtac
alias tail=gtail
alias tee=gtee
alias test=gtest
alias touch=gtouch
alias tr=gtr
alias true=gtrue
alias tsort=gtsort
alias tty=gtty
alias uname=guname
alias unexpand=gunexpand
alias uniq=guniq
alias unlink=gunlink
alias uptime=guptime
alias users=gusers
alias vdir=gvdir
alias wc=gwc
alias who=gwho
alias whoami=gwhoami
alias yes=gyes

ちなみに以上はワンライナーで作った。

% port contents coreutils | perl -nle 'print "alias $1=g$1" if m{/opt/local/bin/g(\w+)}'
alias base64=gbase64
alias basename=gbasename
alias cat=gcat
alias chgrp=gchgrp
（略）
%

例外はlsで、「gls -F」にaliasした。

Leopardを再インストールした

Leopardインストール日記ということでLeopardにソフトウェアをインストールしたメモをつらつらと書いてきたのだが、Leopardをインストールすることになるとは思いもしなかった。まだMac miniを買って2週間足らずなのに。

顛末

きっかけは消せないファイルができてしまったことだ。Linuxからrsyncで機械的にコピーしたファイルが、ファイル名に妙な文字を含んでいるらしくターミナルからもFinderからもどうやっても消せなくなってしまったのだ（Finderはファイルの存在すら認識せず、0 itemsと表示する）。

lsはできる。

 % ls
 ☁
 %

ls -lをするとサイズは0である。

ところがrmをすると

 % rm *
 rm: ☁: No such file or directory
 %

*をファイル名一覧に展開するところはできるのに、rmが認識できていない。

ディレクトリごと動かすことはできる。

 % ls a/
 ☁
 % mv a b
 % ls b/
 ☁
 %

ごみ箱に移したらごみ箱を空にすることができない。mvができてrmができないからか、と妙に納得してしまう。

原因

原因はわかっている。rsyncでLinuxからファイルを大量にコピーしたからだ。Linuxで作ったファイルではなく、その前のOSからrsyncしたファイルだと思う。Windowsかもしれない。

rsyncがどんな処理をしてこういう妙なファイルを作ってしまったのかはわからないが、Linuxからrsync --deleteで空のディレクトリをコピーしてもこのファイルは消えてくれなかった。

対処

こういうファイルを放置したらどういう結果になるかは知らないものの、気持ち悪いことには違いない。バックアップをとるたびにエラーメッセージを見るのも愉快ではない。とはいえ、OSの再インストールしか直す方法がないらしい。となると、購入したてのいまがチャンスだ。

LeopardはDVDから立ち上げてデータを失わずに再インストールできる。UNIXでは当たり前のことだけれど、すべてがGUIで完結するのはすごいと思う。

結果

問題のファイルを/tmpに置いてから再インストールしたら、このファイルは無事なくなった。というよりも/tmpにあったファイルはすべてなくなった。

再インストール自体はDVDを2枚使う待ち時間ばかり長い作業だったが、ユーザディレクトリもインストールしたアプリケーションも失うことなく、OSの領域だけきちんと復元できた。

失われたもの

前記のとおり、/tmpにあったファイルは全部なくなった。さらに、/var、/etcにあったと思われる設定・データもなくなった。具体的には

• /etc/sudoers
• /etc/ntp.conf（時刻の設定）
• /var/run/utmpx（ログイン履歴）
• ホスト名（どのファイルかは不明）

しかし逆に考えれば、OSを再インストールしたあとに再設定がほとんど必要なかったのはすごいと思う。