表題の通り。

FreeBSD、意外と面倒。

とりあえずOSインストール。CUIが入る。

GUIを入れる。ソースから入れると何時間かかるかわからないのでバイナリから。makeしても半日はかからなそうなので、portsでxorgをmake install cleanしたほうが賢そうです。あとで別なマシンに入れようとしたらPACKAGEROOTを書き換えてインストールする手法うまくいきませんでしたし。gnome2はすごく時間が掛かるのでpkg_addした方がいいと思います。

PACKAGEROOT="ftp://ftp2.jp.freebsd.org/pub/FreeBSD/ports/amd64/package-9.1-release/Latest/"

をどうにかして環境変数に流しこんであげて、（2013/06/26追記：いつのまにかいきなりpkg_addできるようになっていました）

# pkg_add -r xorg

してXorgを入れて

# pkg_add -r gnome2

してGNOMEを入れる。
VMware ToolsはFreeBSD 9に対応していないので、Hephaestus: Installing VMWare Tools on FreeBSD 9.1を見ながらVMware Toolsを入れる。#vi /etc/stable-supfileの時にFreeBSDバージョンを9か9_1か判断して必要に応じて書き換えること。さもなければ、makeした時にCould not find bsd.compiler.mkとか言われて止まる。

# pkg_add -r xf86-video-vmware xf86-input-vmmouse

してドライバを入れる。

# Xorg -congigure

とかするとxorg.conf.newとかができるのでそれを/etc/X11/xorg.confにコピー。
/etc/rc.confをいじる。

CUiでマウスが有効になっていたら無効に

moused_enable="NO"

GUI周り

dbus_enable="YES"
hald_enable="YES"
gdm_enable="YES"

あとは色々設定を反映させるために再起動。
とりあえずこんなんで動いた。VMware Toolsには相変わらずXが認識されないのとマウスをVmware Playerから出し入れした時の挙動がやや怪しいけど。

あとは、

# vmware-toolbox-cmd timesync enable

なぜかVMware Toolboxは時刻同期の初期設定がDisabledなのでEnabledに。

とりあえずこんなんでハードウェア周り（？）の設定は終わるはず、あとはFreeBSDの普通のマニュアルに沿って日本語周りだの必要なソフトだのを入れていく。
# portsとかから入れていくわけだが、随分時間かかるし、デスクトップで使用するにはちょいきついような。サーバーでは問題にならないが。portsはソースから入れるから革命的な遅さだが、バイナリパッケージをインストールするpkg_addもUbuntuのaptとかのような速さを想像していると絶望するぐらいには遅い。

追記：CUIインストール時？の対応

CUIだからかVMware ESXiとVMware Playerの差なのかわからないが、vmware-toolbox-cmdがライブラリを要求してきて動かないときはforgottheaddress: freebsd 8.2 vmware-toolbox-cmd timesyncに書いてある通り

# ln -s /usr/local/lib/libintl.so.9 /usr/local/lib/libintl.so.8
# ln -s /usr/local/lib/vmware-tools/lib64-63/libpcre.so.0/libpcre.so.0 /usr/local/lib/

とかやると動いた。古いバージョンのライブラリがないという問題。

無理矢理感あって残しておくのも後々問題になりそうで気持ち悪いし、toolboxでの設定を終えたら作ったシンボリックリンクは消してしまったほうがいい気がする。

自宅サーバー初心者（@kyos_1704）のサーバーの構築をSkype経由で見たりしていたのでその時のSkypeログとかからおおまかな流れを抜粋。※初心者向けの記事ではない

事前準備

• ルーターにログインできることを確認する。
  • デフォルトゲートウェイをipconfigで調べて、そのアドレスをブラウザのアドレスバーにいれて接続
  • パスワードがわからなかったりするケースがある
• 自宅にグローバルIPアドレスが来ていることを確認する。
  • ルーターにログインした時にでも調べる

ハードウェアを組む

• 好きなように
• 流用でもいいし、既成品でもいいし、自作できる人なら自作でもいいでしょう
• 具体的に何かに使いたいならそれに見合う性能や信頼性は必要

OSインストール

• OSを選んでダウンロードする
  • 初心者ならとりあえずUbuntu Serverとかどうだろう
• ISOファイルをCDに焼く
• CDからブートする
• インストールする、ここで何か余計なものを入れる必要はない。
• 起動する

設定

• IPアドレスを設定する
  • IPアドレスを決める
  • 決め方が判らなかったらIPアドレスの仕組みの勉強は後回しにして決められる人が決めてあげる
  • 設定ファイル（Ubuntuとかなら/etc/network/interfaces）に書き込む
  • そのためにsudoのやり方を教える
  • Ubuntu/インストール後の設定とかを参考に設定してもらう
  • よく考えたらCUIのエディタの使い方を教えていないことに気づく
  • Vimを布教する
  • DNS設定も書き込む（新しいUbuntuなら/etc/network/interfaces）
  • ネットワークをリロードする（Ubuntuならsudo service networking restart）
  • ifconfigとかして新しいIPアドレスを確認する
• sshをインストールする
• sshを設定する
  • 初期設定は22ポート、パスワード認証可なのでつなぐ
  • WindowsならPuTTYGenとかで鍵を作る
  • .ssh/authorized_keysに貼り付ける
  • PuTTYでのコピペのやり方を教える（ドラッグするとコピー、右クリックで貼り付け）
  • 鍵でつながることを確認する
  • つながらない
  • cat ~/.ssh/authorized_keysして結果を見せてもらう
  • Vimのコマンドモードでそのまま右クリックして公開鍵の冒頭のssh-rsaの最初のsが挿入モードに入るだけになってて入力されてない
  • 直す
  • 鍵で繋がる
  • /etc/ssh/sshd_configを開く
  • 鍵認証のみ有効にする（PasswordAuthentication を見つけてyesからnoにする、コメントアウトされていたらコメントアウト外す）
  • 必要に応じてポート番号も変える（そのままでいい気もする）
  • sshdを再起動する
  • 新しい設定でつながる（Ubuntuならservice ssh restart）
• ルータにログインして静的NAT（ポート開放などとも表現する）を設定する
• さっきのsshの他に80, 443あたりをつながるようにする
• DDNSを設定する
  • ieServerとかにユーザー登録する
  • スクリプトをホームディレクトリ上のディレクトリ（←作る）に設置する
  • crontabを設定する
  • 更新間隔10分とかになってるし、TTLがあるから最大15分とかかかる
  • 酒でも飲む
  • nslookupとかで更新されていることを確認する
  • ついでにログファイルが吐き出されていることを確認する
• Apacheをインストールする
• とりあえずsudo aptitude install apache2とかすると起動はしてくれる
• サーバーのプライベートIPをブラウザに入れてつなぐ
• It works!
• さっき設定したDDNSのアドレスを入れてもらう
• 繋がらなくて絶望する
• ヘアピンNATは普通のルーターにはついてないので諦める
• 部屋の外にいる人が教えてあげるか、モバイル回線とか携帯電話を使って外からウェブページが見れていることを確認する
• とりあえず設定完了
  • 中からもドメインで繋ぐ場合はいくつか方法があるが、面倒なので必要になってから教えることにする
  • クライアントの/etc/hosts（WindowsはC:\Windows\System32\drivers\etc\hosts）をいじる方法はそのパソコンを持ちだした時面倒
  • ヘアピンNATは多分ついてない
  • そのサーバーにdnsmasqとかを突っ込んでそのサーバーの/etc/hostsをいじって、かつルーターのDNS設定を書き換える方法は教えるのが面倒
  • そういえばルーター側でそういうのをいじる機能がついていたらありかもしれない

Pukiwikiは便利なので使っている団体も多いと思う。

そしてPukiwikiにはBasic認証がついているし、一応認証をかけることもできるのだが、これは人数などによってはパスワードの管理がめんどくさいこともある。

そこで、Pukiwikiを適当に改造して独自の認証で特定の条件を満たしたもののみが見ることができるWikiを作ることを考える。前提として、最低限PHPでプログラミングができる程度の知識は必要となる。

まず、独自の認証を追加するかどうかに関わらず、.htaccessが有効になっていることを確認する。Wikiのディレクトリが/wiki/とした時に、/wiki/data/以下のファイルとかに直接アクセスされるようでは認証もへったくれもない。こういう外部のアプリケーションを展開するときは.htaccessが有効になっている方が安全だが、どうしても.htaccessが有効にできない（セキュリティ上の理由がApache以外のウェブサーバーなど）ときは、それを適切に設定する。例えば/wiki/に設置した場合なら/wiki/data/につないだ時にエラーが出れば問題ない。AllowOverRideの設定を修正するわけだが、わからない場合は適当に調べること。

さて、それが完了してかつpukiwiki.iniの初期設定が終わったらPukiwikiを改造する。

Pukiwikiのフォルダの lib/auth.php を開くと色々関数が出てくる。read_authとedit_authを見て、これを自分が望むように編集する。概ね、見せて良い相手の場合はreturn true;とかして、そうではない場合は望むエラーメッセージを表示してexit;するとよいようだ。もともとはbasic_authを呼び出すようになっていて、問題がある場合は中でエラーメッセージを表示するようになっているが、このエラーメッセージ表示の部分をコピペしても最新の更新とかその辺りの一覧が見えてしまってよろしくないし、何より今からログインしたい人宛のリンクがなくて不便。そのため、ログイン画面にheader(‘Location /login.html’);とかで飛ばしてexit;するのが一番よいだろう。こういう内容でread_authとedit_authを書き換える。

……なのだが、PukiwikiにはBasic認証とは別の認証方法をとるページがあって、そういうページにはアクセスできてしまう（もちろんpukiwiki.iniで書いたパスワードを入力する必要はあるので、実際的な問題はないはずだが）。

その対策のため、read/writeなど細かく権限を分ける必要がないなら認証のコードをindex.phpの冒頭に書いてしまうのもバッドノウハウとして有効だと考えている。どうせ独自認証はCookieとSQLが使えれば充分であることが多いと思うので、index.phpの冒頭でSQLに接続、Cookieの中身を検索して閲覧させて問題ないようならスルー、そうでないなら適当なページにリダイレクトしてexit;してしまうなど。

.htaccessをみるとわかるが、Pukiwikiに最初から添付されている画像などのファイルのほかはindex.php以外は.htaccessによってアクセスを禁止されている。そのため、index.phpにだけ認証に必要なプログラムを書き込むことで全体に対して接続を禁止できる。書き込み権限を分けたいのであれば、lib/auth.phpのedit_authだけ書き換えればよい。ページ名は来ているようなので、ページごとに権限をわけることはできるだろう。

具体的なPHPのコードについてはこのページでは言及しない。もし連携を取りたい他のログインしすてむがPHPで書いてあるならそれのライブラリをincludeするなり必要な部分だけコピペするなり、あるいは$_SESSION等を自前でSQLに突っ込むことで認証するなりすることもできるだろうし、他の言語で書いてある場合はその言語が善きに計らってセッション管理してくれているのをまずはSQLにセッションIDと対応するユーザー情報を書き込むように書き換えるところから始めないといけないかもしれない。PHP側でセッションを新たに読みだしてSQL文をひとつふたつ書いてやるのがいいかもしれないし、連携先で使っているライブラリを流用するためにパイプで繋いでやるほうが楽かもしれない。

# それにしても、Pukiwiki、なんとなくこれぐらいならみんな使えるよね的な雰囲気で使わされることも多くあるが、Pukiwikiの編集はプログラミングをしない層にとっては全然そんなことないと思うのだが。少なくともパソコンというものにある程度慣れていてPukiwikiが使える層にとっては非常に便利だからそういう場合はあえて変更する必要もないと思うが、そうではない場合は別なシステム、あるいはWYSIWYGな編集を実現するプラグインを検討する必要もあると思う。管理者の負担は増加するが。