古いノートパソコンに Lubuntu をインストールし、無線 LAN を有効化したメモ

うちの親がパソコンを買い替えました。

動作があまりにも遅くなっていて、 Windows の起動に 10 分弱、最初にブラウザを立ち上げるのにも 2 分以上かかっていたためです。ハードディスクが末期なのか、システムファイルも一部アクセス不能になっているようでした。

再インストールを頼まれたのですが、幸か不幸かリカバリディスクが見つからず。

そんなわけで、この疲れきったパソコンは廃棄となりました。

…。

ただ、もったいないなぁ。

そういや、軽量版の Linux って使ったことないなぁ。

…。

てことで、 Ubuntu の軽量版である Lubuntu をインストールしてみました。

無線 LAN の設定に一番手こずったのと、ネットに繋ぎさえすればなんとかなるだろうってことで、無線 LAN の有効化までがメインになってます。

参考

環境

PC

OS

その他

  • 有線 LAN を使わない。
  • 起動ディスクの作成やデータ移動のため、今回環境を構築する PC のほかにもう一台 PC がある。

Lubuntu のインストール

起動ディスクの作成

Lubuntu のサイト から OS のイメージファイルをダウンロードし、起動ディスクを作成する。

Comapq 6710b は 32 bit なので x86 系をダウンロード。

インストール

Lubuntu のディスクから Compaq を起動。画面の指示に従って、普通にインストールをおこなう。

インストール時、ネットワークに繋がっていないことを注意されるが無視。

完了

ディスクを抜いて再起動。

…。

これで Lubuntu のインストールは完了。

インストールの時間自体は 20 分ほどかかったが、操作はちょっとしたボタン操作が 10 手順あるかないか程度だった。

無線 LAN の設定

今回設定をおこなった Compaq 6710b と Lubuntu 15.04 の環境では、インストール直後の状態で PC 本体に備わった無線 LAN 機能を使うことが出来ない。

そのため、別途ファームウェアのインストールと設定が必要になる。

必要なファームウェアの確認

以下のコマンドで調査する。

lspci は PCI デバイスを出力するコマンド。 -nn オプションで出力に デバイスの ID と名前を含めている。

0280 はデバイスのクラス ID 。前半 02 がネットワーク・コントローラ、後半 80 がその他を意味している。無線は比較的新しい技術なので、このその他に属することが多いようだ。

とはいっても 0200 に存在する場合もあるので、前述のコマンドで検索しても無線っぽい文字列 (Wireless, WiFi, 802, 等) がなければそっちも調べてみよう。

で、 Compaq 3710b の場合は 0280 で検索すると以下のような出力が現れる。

ここで重要になるのは Broadcom や BCM4311 や [14e4:4312] といった部分だ。

これらは無線 LAN 装置の製造会社や型番だ。

Linux Wireless という、 Linux カーネルのサイトにある無線 LAN 用の Wiki で検索すると装置に合ったインストール方法が書かれたページを見つけることができる。

以下、ファームウェアのインストール方法に続くが、これらは Compaq 3710b の場合である。

インストール (有線 LAN で接続する場合)

一応、メモ代わりに書いておく。

ネットワークの接続を確認して、以下のコマンドを入力するだけで完了する。

あとは SSID とキーを設定するだけ。

インストール (有線 LAN で接続しない場合)

準備

Compaq 3710b の場合、ファームウェアの設定に必要なのは以下となる。

  • b43-fwcutter
  • firmware-b43-installer

これらの .deb パッケージを別のパソコンでダウンロードし、 USB やディスク等の記録メディアに保存する。

一応書いておくと、 Lubuntu は実質 Ubuntu である。そのため各ファイルは Ubuntu や Debian のパッケージ・リポジトリから落とすことになる。

fwcutter のインストール

出力内容が重要になるので、ここではターミナルの画面からインストールをおこなう。

記録メディアのパスは /media/{UserName}/{MediaName} なので、カレントディレクトリを移動してから、以下のようにしてインストールをおこなう。

firmware-b43-installer のインストール

同じように、以下のような感じで実行する。

しかし、この処理は途中で失敗する。

原因はインストールの作業に外部サーバーからファイルを取ってくる処理が含まれているからだ。ネットワークが繋がっていないので、当然この処理は失敗する。

出力のうち、以下のような部分を探す。

ダウンロードを実行した日時と URL だ。

この行のアドレスのメモを取り、別の PC でダウンロードする。そして再び記録メディア経由で移動する。

firmware-b43-installer はこれだけのために使う。

fwcutter の実行

取ってきたファイルを解凍し、 fwcutter を実行する。

再起動すると、起動時の not found なんたらのメッセージが消えているはずだ。また、この時点で Wi-Fi 機器の状態を示すハードウェア・ランプも点灯する。

あとは接続先の設定をするだけだ。

ネットワークの接続先の設定

準備

基本は SSID とキーのパスのメモを探すだけだが、ほんの少し小技。

SSID

SSID は iwlist wlan0 scanning | grep SSID で検索できる。

出てこない場合は Wi-Fi を起動し直すと解決することが多い。 Compaq 6710b の場合、ハードウェア・ランプがボタンになっているので押して ON と OFF を切り替えると手軽でよい。

小技も小技だが、コピペが可能になり作業が少し楽になる。

Network Connections を使う場合

一気に書く。

デスクトップのスタートメニューから 設定 (Preferences) → Network Connections を開き、 Add ボタン → Wi-Fi → Create ボタンでアクセスポイントの設定画面を開き、使用する無線ルータの SSID とセキュリティ情報を入力して Save ボタンで保存。

保存後、再起動するとインターネットが使用可能になる。

Lubuntu を GUI で扱う場合、こっちで設定しておいた方がいい。通知も出るし、タスクバーにも電波状況が表示されるので便利。

コマンドラインでやる場合

方法は複数あるが、 /etc/network/interfaces に直接記す方法をとった。

iwconfig からやる方法もあるようだが、 SSID やキーの設定がなぜか通ったり通らなかったりして、うまくいかなかった。

キーの生成

無線 LAN で使う WEP とかのキーは interfaces に直接書くことができない。 16 進数の値に直す必要がある。

標準でインストールされている変換ツールは見つからなかったが、これは Lubuntu に標準インストールされている言語でやると簡単だった。

Python でのやり方と Perl でのやり方を併記しておく。

いずれの場合も 16 進数に変換された値が出力される。

個人的には、後から見ても何をやっているかわかりやすい Python の方が好み。

/etc/network/interfaces への追記

これは有線 LAN の場合とほとんど同じだ。

以下のように追記する。

そして再起動する。

…。

GUI 上では認知されていないような感じだが、無事ネットワークに繋がっているはずだ。

感想

今回 Lubuntu 環境を構築したのは Windows XP 時代の古い機種でした。中古で買ったこれには Windows 7 が搭載されていて、メモリが多少拡張されていようとも買った瞬間からとんでもなく鈍い代物でした。

それがどうでしょう。

10 分以上かかっていたデスクトップの起動は 1 分ちょっとで完了し、アイコンをダブルクリックしてから 2 分の硬直があったブラウザは数秒で検索したりブックマークを開いたりできるようになりました。

HDD が劣化しているため大切なデータは預けられませんし、速度もこれから急速に落ちていく可能性は否めませんが、掘り出し物を手に入れたような気分です。

そして何より、なんとなく触れてこなかった Linux での無線 LAN まわりの設定を少しでも知れてよかったです。

設定が面倒なのは古い機種を使っているせいかと思いきや、調べているとどうやら Linux では OS をインストールしてすぐに無線 LAN を使えないのは珍しくないようです。

面倒でしたが、今後、いつかきっとためになることを学べたような気がします。

ありがとう、 Compaq 6710b 。

仮想マシンファイルの移動 (VirtualBox)

ディスク容量の都合で、仮想マシンの構成ファイルの移動をおこなった。

昔やったときはもっと面倒だった記憶があるのだが、驚くほど簡単になっていたので軽くメモ。

環境

  • VirtualBox 4.3.20 r96997
  • Windows 7 Home Premium (64 bit)

手順

前準備

  • ホストマシン上の全ての仮想マシンの電源を切っておく。
  • VirtualBox マネージャも停止しておく。

ファイルの移動

今回移動の対象となったのは以下。

  • 仮想マシンの設定 (拡張子 .vbox)
  • 仮想ディスク (拡張子 .vdi)
  • スナップショット (ファイル名 {????????-????-????-????-????????????}.vdi)

ちなみに自分の環境では、ファイルをこんな感じで設置していた。

通常の Windows のファイル操作と同じように、フォルダを丸ごと移動する。

パスの書き換え

ユーザーのホームフォルダ下のファイルを少し弄る。

%HOME%\.VirtualBox\VirtualBox.xml

MachineEntry タグの src 属性に移動元のパスが書かれているので、それを移動先の拡張子 .vbox のものに書き換える。

パスの書き換え 2

今回移動をおこなった仮想マシンのファイル構成では、設定ファイル内の仮想ディスクファイルへのパスが相対パスになっている。

この場合は設定ファイルと仮想ディスクを同じ位置関係を保ったまま移動すれば、上記のホームフォルダ内の設定を弄ればいいだけだ。

しかしこれが絶対パスで管理されていたり、位置関係を変えて移動をおこないたい場合は、この仮想マシンごとの設定ファイル (拡張子 .vbox) も書き換える必要がある。

HardDisks → HardDisk に仮想ディスクの設定があり、 HardDisks → HardDisk → HardDisk にスナップショットの設定がある。

それぞれ location 属性がパスになっているので、必要があれば修正する。

起動

VirtualBox マネージャを起動し、正常に読み込まれているか確認する。

パスに問題があればエラーが表示され、起動もできない。

エラーもなく、正しく起動し、ゲストマシン内でそれぞれのディスクに問題なくアクセスできれば作業は完了だ。

ちなみに設定ファイルを更新していても、マネージャが更新前のパスを読み込んでいることがあった。もしかすると、マネージャの終了後少し待ってから起動しなおした方が良いかもしれない。

最後に

設定ファイルを直接弄らず、マネージャを利用する方法もあるようだ。というかこっちの方が安全で、普通はそうすべきなようだ。

でもまあ、こうやって設定ファイルを直接弄ることは、ホスト OS が起動できなくなっていちいちマネージャを頼ってられないときとかに使えそうなのでメモとして残しておく。

VirtualBox のマネージャは融通が効かなくていまいち使いづらかったりするし。 (だからこそ安全なのだろうけど)

Unbound を 1.5.1 に更新した

複数の DNS ソフトウェアで脆弱性が発覚したとのニュースを見た。 Unbound もそこに含まれているとのこと。

自分が設定している Unbound はごくプライベートな環境にしか開かれていないため影響の範囲外かと思われるが、緊急の脆弱性を知りながら放置するのものなんだか気持ち悪いので更新してみた。

今回はそのレポートというか、メモ書き。

環境

  • Ubuntu 14.04
  • Unbound 1.4.22 (旧)
  • Unbound 1.5.1 (新)

上記の旧マークがついた Unbound は、標準のパッケージリポジトリからインストールしたもの。

今回、面倒な service 等の設定を流用するため、旧バージョンはインストールした状態で作業をおこなう。

準備

設定のバックアップ

ライブラリやツールのインストール

コンパイルやインストールにコケたら、その都度エラーを見て追加でインストールをおこなう。

configue オプションの確認

unbound -h で出てくる。

参考として、標準のリポジトリからインストールしたものでは以下のようになっていた。

インストール

  • 前半は最新版 Unbound のダウンロードと解凍。
  • ./configure {Options} の Options 部分は事前に確認した Configure のオプション。

動作確認

  • unbound -h でバージョンを見る。バージョンの値が最新になっていればファイルの更新自体は成功。
  • service unbound restart 可能か確認。
  • うまくいかない場合は unbound-checkconfig や直接 unbound を実行してエラーを見る。

インストール中に起きたトラブル

*/unbound.conf

service を起動できず、直接 unbound を実行したときに確認できたエラー。

設定では切っているはずなのに、 IPv6 での紐付けができないというエラーが発生した。奇妙に思いながら設定ファイルを弄るも変化なし。

原因はコンパイル時のオプションを忘れていたことだった。 unbound-checkconfig を実行すると以下のように表示される。

/usr/local/etc/unbound は Unbound 標準の設定ファイル位置。一方 Ubuntu の標準は /etc/unbound 。

自分が見ていたのは後者の位置にある unbound.conf だった。そっちを書き換えたところで影響あるわけがない。

make clean して ./configure のくだりからやり直した。

root.key

以前の root.key がなぜか使えなくなっていたため、作り直した。環境によってはこの作業は不要だったので、必要があれば、という感じ。

unbound.conf.d/root-auto-trust-anchor-file.conf の auto-trust-anchor-file のパスを確認し、以下のように実行する。

参考サイト

WordPress 移転メモ

環境

移転元

  • さくらのレンタルサーバー (スタンダードプラン)
  • Apache 2.2

移転先

  • さくらの VPS
  • Docker
    WordPress と MySQL 、二種類のコンテナを立ち上げる。WordPress 用のコンテナでは、サーバーソフトウェアとして Nginx を使用する。

Docker のホストとなる環境には、以下のソフトウェアやツールをインストールしておく。

  • Nginx
    リバースプロキシとして使用。
  • Unbound
    コンテナ間通信時の DNS として使用。
  • docker-ip-register
    起動中の Docker コンテナの IP アドレスを Unbound のコンフィグに登録する自作ツール。

移行データの準備

今回サーバーソフトウェアが Apache と Nginx と、移行前後で異なるため、移行対象を投稿データのみに限定した。

投稿データ

ブログ管理画面から、 ツール → エクスポート → すべてのコンテンツ → エクスポートファイルをダウンロード でデータを作業用 PC に落とす。

投稿データには通常のブログ記事のほか、コメント等も含まれる。

画像等

FTP とかでログインし、 WordPress のディレクトリ下にある /wp-contents/uploads を作業用 PC に落とす。

プラグイン

サーバーソフトウェアの違いから、直接ファイルを操作して移行すると不具合が起きる可能性がある。

設定をメモっておき、その情報を元に手動で設定をおこなう。

MySQL

MySQL は Docker を利用しているが、特に設定することは変わらない。

WordPress 用のデータベースを作成し、作業用のユーザーを充てる。

Docker

MySQL のコンテナは Docker Hub Registory で確認できる オフィシャルリポジトリ を使って立ち上げた。

以下のようなシェルスクリプトを書き、実行している。

内容の補足をすると…

  • 変数 DB_PASSWORD は MySQL サーバーの root のパスワード。ホストの外側からアクセスできないようにしているが、変えておいた方がよいと思う。
  • シェルスクリプトのある位置に data という名前のディレクトリを作り、それを MySQL の情報が書き込まれるようにしている。
  • 変数 CONT_NAME をもとに Unbound にホスト名が設定される。以下の場合、 mysql-1.mydocker がホスト名になる。 (mydocker 部分は docker-ip-register が設定する TLD の初期値)

WordPress 用コンテナの作成

Dockerfile Project の dockerfile/nginx リポジトリ を元に Dockerfile を作成している。

Dockerfile の記述は以下のような感じ。

内容の補足をすると…

  • システム時間を日本に。
  • 言語設定を英語圏の UTF-8 に。(癖で書いているが、必要ないかも)
  • PHP の実行環境として php-fpm をインストール。
  • メール通知用にメールソフト (ここでは sendmail) をインストール。
  • リバースプロキシ経由でアクセスすると、接続元の情報がリバースプロキシのものになる。正しい IP アドレスを渡すためのヘッダ情報をセットしている。

Dockerfile を好みで弄って、 docker build -t {イメージ名} . 。ここでつけたイメージ名は覚えておくこと。

WordPress 用コンテナの起動

こんな感じのシェルスクリプトを作成して保存する。

補足。

  • シェルスクリプトの位置を基準に、 nginx と www のディレクトリを作成する。
    • nginx の下には certs, log, sites-enabled のディレクトリを作成する。それぞれの意味は docker run の行を参照。
    • www は公開の基準となるディレクトリ。 sites-enabled 内では /var/www として扱う。
  • この時点では sites-enabled 内に設定ファイルがないためコンテナの起動にコケる。

コンテナ の Nginx 設定

上記スクリプト実行後、 sites-enabled 内にコンテナ用の設定ファイルを作成する必要がある。

以下のような内容で作成し、 sites-enabled 内に好きな名前で保存する。

補足。

  • location / の if 部分は WordPress のパーマリンク用。
  • location ~ \.php$ 部分は php-fpm 用の設定。

再度 docker run 用のスクリプトを実行すると、打ち間違いがなければコンテナ内で正常に Nginx が実行されるはず。

今後コンテナ用の Nginx の設定ファイルを書き換えた場合も、同じように docker run 用のスクリプトを実行すると設定が反映される。

ホストの Nginx 設定

この時点で WordPress 用のコンテナが起動できているはずだが、現時点ではホスト側からしかアクセスができない。

ホストの Nginx にリバースプロキシを設定してやる必要がある。

/etc/nginx/sites-enabled 下に、以下のような設定ファイルを作成する。

補足。

  • {ホスト名} の部分は運用時のホスト名を書く。更新日時点のここの場合は blog.indeep.xyz となる。
    • テスト時はまったく別のホスト名を用意したり、別のポートから繋ぐようにした方がいいかもしれない。

ホストの Nginx をリロードすると、上記のホスト名でコンテナ内の Nginx サーバーにアクセスできる。もちろんドメインは事前に通しておく必要がある。

WordPress のインストール

これまでの時点で、コンテナ内の Nginx にアクセスすることはできるようになったはず。

WordPress のインストールは、 docker run スクリプトの下の www ディレクトリ下でおこなう。

特徴のある作業ではないのでざっと書くが、 www ディレクトリに cd して、 wget で WordPress の圧縮ファイルを落として unzip する。 docker run スクリプトの位置から見て、 www/wordpress に WordPress のルートが来るように配置する。

所有者を chown -R www-data:www-data wordpress で変更する。ホストの OS によっては www-data の uid, gid が違う可能性もある。うまく動かない場合は chown -R 33:33 wordpress で変更。

普通どおりに wp-config.php を設定したら、普通どおりに wp-admin/install.php から初期設定をおこなう。

wp-admin/install.php がうまくいかない場合は、 wp-config.php のアドレスを確認したり、ホストの Unbound デーモンを再起動させてみるとよい。ホストの Unbound が Docker コンテナからの接続を許可していることも確認。標準では 172.17.0.0/16 の範囲だ。

データの移行

投稿データ

WordPress プラグイン WordPress Importer をインストールし、有効化する。

ブログ管理画面から、 ツール → インポート → WordPress で事前に落としておいた移行元の xml ファイルをアップロードしてインポート。次の画面でインポート時の著作ユーザーの名前を設定し、チェックボックス Download and import file attachments を有効化し、 Submit 。

画像等

WordPress のディレクトリ下にある /wp-contents/uploads を移行元のデータで上書き。

所有者を www-data:www-data に書き換えるのを忘れずに。

プラグイン

移行前の情報をもとに同じように設定していく。

以上です

自分なりの復習として順を追って書いてみました。

くっそ長いですね。

セキュリティ上の判断と、コンテナ等に自分向けの方言的な設定が混じっていることから各設定を直接 GitHub や Docker Hub に公開することを控えたのですが、これだったら修正してアップした方がラクだったかもしれません。

移行による変化

今回、さくらのレンタルサーバー (スタンダード) からさくらの VPS に移行したのですが、読み込み速度が大きく改善しました。

前回は基本となる HTML 部分を読み込むのに 3 秒はかかっていたのに、今は 1 秒を切りました。以前はブログの設定を変更したり、記事の修正する際にイライラとしていたのですが、これで平然と作業することができそうです。

Docker を使った利点としては、立ち上げ時と運用時に使うファイルがより具体的になったことが挙げられます。コンテナ内部に独自の環境を作り上げているので、今後の作業で環境が汚染されることもありません。いつか問題が起きたときも、調べる範囲が小さく済むことでしょう。

というわけで、記事が縦に長過ぎるという欠点はありますが、作業内容自体はとても身になるものでした。

参考サイト

JScript とレジストリ操作で、直にフォルダにダウンロードする機能を作る

Windows での作業中、作業フォルダとブラウザのダウンロード先フォルダが離れていることがよくあります。

別に普通のことです。しかし例えばフリー素材集めのときなどは、ブラウザがダウンロード先として使うフォルダと、最終的な保存先フォルダを頻繁に行き来することになり少し面倒です。

先日もそういう場面がありました。繰り返し繰り返し、複数のフォルダとブラウザを行き来していると、単純な作業がゆえに居場所を見失いそうになります。

めんどい…。

これ、フォルダの移動を最終的な保存先に限定することで、ちょっとはマシにならないかな…。

そんな想いから作成したのが、今回の簡易ツールです。

仕様等

  • 開発・動作確認環境は Windows 7 64 bit。
  • ここに置いてるのは簡易版。もう少し配慮してるのは GitHub で公開中

基本仕様

  • フォルダ上の右クリックメニューから実行。
  • クリップボード内の文字列を元にダウンロードをおこなう。
    • クリップボードに URL っぽい文字列がある場合のみダウンロード。 ( / が含まれるかどうかで判断)
  • 保存ファイル名は最後の / 以降の文字列を使う。
    • Windows でファイル名に使えない文字は _ に変換する。
    • / 以降の文字がなければ、ファイル名は downloaded_from_clipboard となる。
    • 既に同名ファイルが存在する場合、ユーザーに上書きの許可を求める。承諾時、上書きをおこなう。
  • ダウンロード可能な URL をクリップボードから得られなかったり、保存先として使うファイル名を作れなかった場合は何もせずに終了する。

免責事項

  • 当たり前ですが、使用やセットアップ等は完全に自己責任でお願いします。

セットアップ

スクリプト

どこか適当な場所に以下のスクリプトを保存する。ファイル名は何でも構いませんが、拡張子は .js で。

レジストリ

  1. HKEY_CLASSES_ROOTDirectoryBackgroundshell 直下にキー download_from_clipboard を追加。

  2. download_from_clipboard に文字列 MUIVerb を追加。コンテキスト・メニュー用の項目名として download from clipboard と入力する。

  3. download_from_clipboard 直下にキー Command を追加。 (既定)wscript "{スクリプトの絶対パス}" を入力。

使用

上記セットアップを完了後、フォルダの背景箇所を右クリックすると設定した項目が現れます。

クリップボードに URL が存在する状態で機能を実行すると、実行したフォルダにファイルがダウンロードされます。

作ってみて

ちょっと便利。

ただ、今回初めて触れた JScript (WSH) に関しては微妙な癖の強さを感じました。

簡単な機能だし Windows 標準で使えるこれでいいかと気軽に選んだのですが、単純に文字を出すにも違和感というかなんというか。ブラウザ用の JavaScript に慣れているせいもあるんでしょうけど。

しかし同時に、機能の強力さと制作の手軽さを実感しました。

昔から名前を聞くだけあります。ツールを作ったこと以上に、 WSH の世界に踏み入れたことに心を動かされた感じです。

追記

ただし Wikipedia の WSH の項目 によると、

PowerShellの登場により、Windows Script Hostはその役割を終えたと言える。今後、新しい機能が追加される予定は無いとされている。

とのこと。

…まあ、 PowerShell だとデフォルトでスクリプトファイルを単体で動かせない みたいだから別にいいか。別物別物。 WSH はまだ死んでいない。

興味をもち始めた初学者としては、そう思いたい。

参考サイト

JScript

レジストリ