自宅では24時間稼働のホームサーバ(録画サーバ兼ファイルサーバ)を稼働させているんだけども、アイドル時の消費電力18Wとはいえ、24時間稼働させっぱなしなのはもったいない。
ほとんどの時間は何もしておらず、主にタイマー録画の他、番組表、DLNA、sshのリクエスト時に応答させるために24時間つけっぱなしになっている。
もしスリープ運用させた場合、最初に少し待たされるのは仕方ないとして、手順を変えずに運用可能かを検証したみた。
スリープの設定は、ネットワークアクセスがあれば復帰する設定にしている。(WOLではない)
以下その検証結果。
(1).TVrock録画予約 (○:問題なし)
録画開始前に自動で復帰するため問題なし。
録画中や、録画後のエンコード中は無操作となるが、スリープ移行はSleep Toolにて抑制できる。
(2).番組表、ファイル、RDP等 (○:初期レスポンスが遅い以外問題なし)
http, RDP等、何らかのネットワークリクエストを受け取ったら自動で復帰するため問題なし。(UDPでは復帰しない)
例えば、番組表(http)を表示しようとした場合、ホームサーバがスリープ状態だと10秒近く待たされるが、待っていれば表示される。
(3).PS3 Media Server(PMS) (○:運用でカバー)
PMSの場合、スリープ状態だとPS3上にDLNAサーバとしてPMSが表示されない。
上記の通り、httpリクエストで復帰するので、少し工夫をしてみた。
まず、テレビのWebブラウザのデフォルトページをホームサーバの番組表にしておき、テレビリモコンのブラウザボタンで、番組表が表示されるようにしておく。
学習リモコンに、テレビのブラウザボタン、外部入力切り替え、の一連の動作を、外部入力切り替えボタンに登録しておけば、普段通りのリモコン操作で、スリープ復帰を意識することなくPMSを利用可能となる。
PMS配信中は、PMSの設定でスリープを抑制できるため問題なし。
(4).ssh接続 (×:問題あり)
上記の通り、ネットワークアクセスで自動で復帰し、接続することはできる。
しばらくするとホームサーバがスリープに入ってしまい、sshのコネクションが切断されてしまう、という問題がある。
Sleep Toolではプロセス指定でスリープ抑制可能であるが、sshdは常に動作しているため、Sleep Toolにsshdを登録すると、スリープに移行できなくなってしまう。
ちなみにsshは、外部からのアクセス用にsshトンネルを作成するために利用している。
上記検証結果から、sshdを使わなければスリープ運用できるのだが、sshdは止められないという事情がある。
でも考えてみれば、sshdだけなら超省電力のLinuxボックスが代替品として利用できそうだ。
というわけでLinuxボックスを探してみると、超激安の以下の2つが見つかった。
Raspberry Pi
http://www.raspberrypi.org/faqs
4500円程
BeagleBone Black
http://beagleboard.org/Products/BeagleBone%20Black
5000円程
BeagleBone Black のほうがスペックはいい。
Raspberry Piのほうが圧倒的に情報量が多いんだけど、ハードのカスタマイズはしないし、Linuxさえ動けばBBBでもなんとかなるだろう、と思ってBBBを購入することにした。
消費電力はわずか2W。
これなら心おきなく24時間稼働していただける。
このカテゴリの記事一覧です。
- 省電力Linuxボックスの検討
- BeagleBone Black 購入&動作確認
- BeagleBone Black 内蔵eMMCの初期化
- BeagleBone Blackをfedoraで動かす その1
- BeagleBone Blackをfedoraで動かす その2
- BeagleBone Black 自作ケース
- BeagleBone Black fedoraのデスクトップをリモート表示
- BeagleBone Black fedora SDカードの残り領域をマウントする
- BeagleBone Black fedoraにgccをインストール
- BeagleBone Black fedoraにDLNA(PMS)をインストール
- BeagleBone Black fedoraにプロキシ(squid)をインストール
- BeagleBone Black fedora にsambaインストール
- BeagleBone Black fedora USBストレージがI/Oエラー(解決)
- BeagleBone Blackに fedora 20 をインストール
- BeagleBone Black fedora 20 USBを認識しない(解決)
- BeagleBone Black fedora 20 sshdポート変更
- BeagleBone Black fedora20 デフォルトrunlevelを変更する
- Fedora20 リモートデスクトップまとめ(XDMCP & VNC)
- fedora20のOpenSSLをアップデート
2013年09月15日
2013年09月19日
BeagleBone Black 購入&動作確認
BeagleBone Black(BBB) A5Cが届いた。

裏面(マイクロSD挿してます)

というわけで早速動作確認を。
公式サイトの手順だとPCとUSB接続して、USB仮想ネットワークドライバをインストールするわけだけど、
USBドライバなんてインストールしたくないぞコノヤロゥ!
って向きには以下の確認方法がある。
LANケーブルを繋いで起動(USBかAC給電)すると、DHCPでIPアドレスを取得してくれるので、割り振られたIPアドレスが判るのであれば、そのIPアドレスにsshで接続できる。rootでパスワードなし。
これができるのであれば以下は試さなくてもOK。
以下は公式サイトの手順についてのメモ。
キーボード、モニタがなくとも、PCとUSB接続するだけで、内蔵eMMCの Angstrom linuxを起動し、sshログインまで確認できる。
■用意するもの
・USBケーブル(BBB付属品)
■動作確認方法
PCにUSB接続
BBBとPCをUSBにて直結する。BBBにはこのUSBのみ接続で、他は何も接続していない。
→ USB給電されてBBBが起動する。起動すると、70MBほどのUSBストレージとしてWindowsから参照できる。
USB仮想ネットワークドライバのインストール
http://beagleboard.org/Getting%20Started#step2
上記のリンクから環境に合ったドライバをダウンロードしてインストール。
うちはWindows (64-bit)を利用。
完了するとネットワークインタフェースが作成され、IPアドレスは以下となる。
Windows側 192.168.7.1
BBB側 192.168.7.2
http://192.168.7.2 にアクセスするとドキュメントやサンプルスクリプトが確認できる。
ssh接続確認
teraterm等で192.168.7.2にssh接続。
root/パスワードなしで接続できる。(はず)
ここまでできればとりあえずの初期動作確認はOK。
はず、というのは、問題のない製品であれば接続できているはず。
うちに届いたBBBは、最初は以下のエラーでssh接続できなかった。
これはIPアドレス等のアクセス制限に引っ掛かった場合に出るエラー。
新品で絶対これはあり得ない。
sshアクセスできなければ何もできないではないか!
そもそも届いた時から化粧箱と、静電気防止袋の開封確認シールが切られており、上からセロテープで封をした状態だった。
きっと誰かがいじり倒して返品されたものを、上辺だけの簡単な動作確認で再出荷したのだろう。
非常に腹立たしいので、レビューに書いたら翌日には消されていた。けしからんので店名を晒しておく。
やっぱやめた。
ちなみに公式から内蔵eMMCをダウンロードして初期状態に戻し、同じことを実施したところ、上記問題は発生しなかった。
やはり、前使用者がhosts.denyあたりでIPアドレス制限を掛けていたのは間違いない。
内蔵eMMCの初期化についてはこちらを参照。
とりあえず、これで動作確認はできた。
参考サイト:Getting Started with BeagleBone & BeagleBone Black
http://beagleboard.org/Getting%20Started

裏面(マイクロSD挿してます)

というわけで早速動作確認を。
公式サイトの手順だとPCとUSB接続して、USB仮想ネットワークドライバをインストールするわけだけど、
USBドライバなんてインストールしたくないぞコノヤロゥ!
って向きには以下の確認方法がある。
LANケーブルを繋いで起動(USBかAC給電)すると、DHCPでIPアドレスを取得してくれるので、割り振られたIPアドレスが判るのであれば、そのIPアドレスにsshで接続できる。rootでパスワードなし。
これができるのであれば以下は試さなくてもOK。
以下は公式サイトの手順についてのメモ。
キーボード、モニタがなくとも、PCとUSB接続するだけで、内蔵eMMCの Angstrom linuxを起動し、sshログインまで確認できる。
■用意するもの
・USBケーブル(BBB付属品)
■動作確認方法
PCにUSB接続
BBBとPCをUSBにて直結する。BBBにはこのUSBのみ接続で、他は何も接続していない。
→ USB給電されてBBBが起動する。起動すると、70MBほどのUSBストレージとしてWindowsから参照できる。
USB仮想ネットワークドライバのインストール
http://beagleboard.org/Getting%20Started#step2
上記のリンクから環境に合ったドライバをダウンロードしてインストール。
うちはWindows (64-bit)を利用。
完了するとネットワークインタフェースが作成され、IPアドレスは以下となる。
Windows側 192.168.7.1
BBB側 192.168.7.2
http://192.168.7.2 にアクセスするとドキュメントやサンプルスクリプトが確認できる。
ssh接続確認
teraterm等で192.168.7.2にssh接続。
root/パスワードなしで接続できる。(はず)
ここまでできればとりあえずの初期動作確認はOK。
はず、というのは、問題のない製品であれば接続できているはず。
うちに届いたBBBは、最初は以下のエラーでssh接続できなかった。
ssh_exchange_identification: Connection closed by remote host
これはIPアドレス等のアクセス制限に引っ掛かった場合に出るエラー。
新品で絶対これはあり得ない。
sshアクセスできなければ何もできないではないか!
そもそも届いた時から化粧箱と、静電気防止袋の開封確認シールが切られており、上からセロテープで封をした状態だった。
きっと誰かがいじり倒して返品されたものを、上辺だけの簡単な動作確認で再出荷したのだろう。
非常に腹立たしいので、レビューに書いたら翌日には消されていた。けしからんので店名を晒しておく。
やっぱやめた。
ちなみに公式から内蔵eMMCをダウンロードして初期状態に戻し、同じことを実施したところ、上記問題は発生しなかった。
やはり、前使用者がhosts.denyあたりでIPアドレス制限を掛けていたのは間違いない。
内蔵eMMCの初期化についてはこちらを参照。
とりあえず、これで動作確認はできた。
参考サイト:Getting Started with BeagleBone & BeagleBone Black
http://beagleboard.org/Getting%20Started
2013年09月20日
BeagleBone Black 内蔵eMMCの初期化
内蔵eMMCはAngstrom Linuxがプリインストールされている。
公式ページよりAngstrom Linuxのイメージをダウンロードして入れ替えることで、初期状態に戻すことができる。
■用意するもの。
・4GB以上のマイクロSDカード
・USBケーブル(給電用)
・内蔵eMMCイメージ
ダウンロード:http://beagleboard.org/latest-images
上記より、BeagleBone Black (eMMC flasher) をダウンロード。
BBB-eMMC-flasher-2013.06.20.img.xz 369MB
・7zip (上記.zx解凍用)
ダウンロード:http://www.7-zip.org/download.html
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
■内蔵eMMCの更新
eMMCイメージの解凍
ダウンロードした BBB-eMMC-flasher-2013.06.20.img.xz を7zipで解凍。
以下が生成される。
BBB-eMMC-flasher-2013.06.20.img 3.57GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。

BBB-eMMC-flasher-2013.06.20.img とSDカードのドライブを選択して書き込み実行。
BBB内蔵eMMCの入れ替え
上記イメージを書き込んだマイクロSDに挿入し、S2スイッチを押しながらUSB給電を開始する。

↑S2はこっち側のスイッチ
入れ替え処理が開始されたかどうかは、インジケーターの点滅具合でわかる。
以下公式ページの画像より

USR0 ハートビート(定期点滅)
USR1 SDカードアクセス
USR2 CPU稼働状況
USR3 内蔵eMMCアクセス
USR1のSDカードアクセスと、USR3の内蔵eMMCアクセスが頻繁(点灯したままが長く続く)であれば、cMMCのフラッシュが行われている。SDカードアクセスがほとんどなければ、内蔵cMMCが起動してるだけなのでやり直すこと。
更新の終わりははっきりとはわからないので、自分の場合は寝る前に開始して朝終わっていた。
どれだけ時間がかかるかわからないが、USR1のSDカードアクセスが無くなるので、そこで判断できるとは思う。
後は動作確認を行って問題なければ成功。
参考サイト:Update board with latest software
http://beagleboard.org/Getting%20Started#update
公式ページよりAngstrom Linuxのイメージをダウンロードして入れ替えることで、初期状態に戻すことができる。
■用意するもの。
・4GB以上のマイクロSDカード
・USBケーブル(給電用)
・内蔵eMMCイメージ
ダウンロード:http://beagleboard.org/latest-images
上記より、BeagleBone Black (eMMC flasher) をダウンロード。
BBB-eMMC-flasher-2013.06.20.img.xz 369MB
・7zip (上記.zx解凍用)
ダウンロード:http://www.7-zip.org/download.html
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
■内蔵eMMCの更新
eMMCイメージの解凍
ダウンロードした BBB-eMMC-flasher-2013.06.20.img.xz を7zipで解凍。
以下が生成される。
BBB-eMMC-flasher-2013.06.20.img 3.57GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。

BBB-eMMC-flasher-2013.06.20.img とSDカードのドライブを選択して書き込み実行。
BBB内蔵eMMCの入れ替え
上記イメージを書き込んだマイクロSDに挿入し、S2スイッチを押しながらUSB給電を開始する。

↑S2はこっち側のスイッチ
入れ替え処理が開始されたかどうかは、インジケーターの点滅具合でわかる。
以下公式ページの画像より

USR0 ハートビート(定期点滅)
USR1 SDカードアクセス
USR2 CPU稼働状況
USR3 内蔵eMMCアクセス
USR1のSDカードアクセスと、USR3の内蔵eMMCアクセスが頻繁(点灯したままが長く続く)であれば、cMMCのフラッシュが行われている。SDカードアクセスがほとんどなければ、内蔵cMMCが起動してるだけなのでやり直すこと。
更新の終わりははっきりとはわからないので、自分の場合は寝る前に開始して朝終わっていた。
どれだけ時間がかかるかわからないが、USR1のSDカードアクセスが無くなるので、そこで判断できるとは思う。
後は動作確認を行って問題なければ成功。
参考サイト:Update board with latest software
http://beagleboard.org/Getting%20Started#update
2013年09月21日
BeagleBone Blackをfedoraで動かす その1
※2013/12/23追記
Fedora 20 のインストールはこちら
以下はFedora19のインストール。
内蔵eMMCのAngstrom linux はなんだかよくわからないので、馴染みのあるRedHat系のfedoraをインストールしてみることにした。なんと最新のfedora19が用意されている。
内蔵eMMCのAngstrom linuxはそのままに、SDカードに作成したfedoraのOSイメージから起動することができる。
ただ厄介なことに、fedora19を導入してそのまま起動してもネットワークが設定されておらず、ネットワークアクセスができない。
また、内蔵eMMCのAngstrom linux のように、仮想USBネットワークアクセスも提供されない。
つまり、最初はモニタとキーボード、マウスを接続してセットアップしなければならない。
あるいは別のlinuxが動作している環境で、当該SDカードをマウントし、ネットワーク関連の箇所を書き換えた後、BBBに戻せば最初からネットワークアクセスが可能と思われる。
自分の場合はBBBの画面を見てみたいこともあり、環境を用意した。
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・モニタ出力用マイクロHDMIケーブル
・USBハブ
・USBキーボード、USBマウス
・LANケーブル
・fedora19イメージ
ダウンロード:http://parasense.fedorapeople.org/
上記より、f19-beagleboneblack-MATE.img.xz 846MB をダウンロード。
・7zip (上記.zx解凍用)
ダウンロード:http://www.7-zip.org/download.html
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
■fedora19のイメージをSDカード上に展開
ダウンロードした f19-beagleboneblack-MATE.img.xz を7zipで解凍。
以下が生成される。
fedra19-beagleboneblack-MATE.img 約7.2GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。
fedra19-beagleboneblack-MATE.img とSDカードのドライブを選択して書き込み実行。

■fedora19起動
上記fedora19のマイクロSDに挿入し、HDMI、キーボード、マウス、LANケーブルを接続。
マイクロSDを挿入した状態でUSB給電を開始すると、SDカードのOSが起動する。
※eMMCをフラッシュする時のような、S2スイッチを押しながらの起動は不要。
しばらくするとMATEのデスクトップが立ち上がる。
画面が出てくるまでは4分40秒ほど。長い・・・

デスクトップは、guestとしてログインされている。
rootのパスワードはわからないが、sudo でrootになれる。
あとはとりあえずネットワークが使えるようにして、rebootできちんと立ち上がることが確認できれば、物置の奥で稼働させる予定。
ちなみにRedHatのつもりで少しいじったけど、なんかもう自分の知っている時代のRedHat(ES4)とは別もの、って感じ。
いろいろ作法が変わっていて、こうすれば動くはずのものが動かなくて、ここにあるはずのものがなくて、正直かなりゲンナリしてます。
つづく。
Fedora 20 のインストールはこちら
以下はFedora19のインストール。
内蔵eMMCのAngstrom linux はなんだかよくわからないので、馴染みのあるRedHat系のfedoraをインストールしてみることにした。なんと最新のfedora19が用意されている。
内蔵eMMCのAngstrom linuxはそのままに、SDカードに作成したfedoraのOSイメージから起動することができる。
ただ厄介なことに、fedora19を導入してそのまま起動してもネットワークが設定されておらず、ネットワークアクセスができない。
また、内蔵eMMCのAngstrom linux のように、仮想USBネットワークアクセスも提供されない。
つまり、最初はモニタとキーボード、マウスを接続してセットアップしなければならない。
あるいは別のlinuxが動作している環境で、当該SDカードをマウントし、ネットワーク関連の箇所を書き換えた後、BBBに戻せば最初からネットワークアクセスが可能と思われる。
自分の場合はBBBの画面を見てみたいこともあり、環境を用意した。
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・モニタ出力用マイクロHDMIケーブル
・USBハブ
・USBキーボード、USBマウス
・LANケーブル
・fedora19イメージ
ダウンロード:http://parasense.fedorapeople.org/
上記より、f19-beagleboneblack-MATE.img.xz 846MB をダウンロード。
・7zip (上記.zx解凍用)
ダウンロード:http://www.7-zip.org/download.html
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
■fedora19のイメージをSDカード上に展開
ダウンロードした f19-beagleboneblack-MATE.img.xz を7zipで解凍。
以下が生成される。
fedra19-beagleboneblack-MATE.img 約7.2GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。
fedra19-beagleboneblack-MATE.img とSDカードのドライブを選択して書き込み実行。

■fedora19起動
上記fedora19のマイクロSDに挿入し、HDMI、キーボード、マウス、LANケーブルを接続。
マイクロSDを挿入した状態でUSB給電を開始すると、SDカードのOSが起動する。
※eMMCをフラッシュする時のような、S2スイッチを押しながらの起動は不要。
しばらくするとMATEのデスクトップが立ち上がる。
画面が出てくるまでは4分40秒ほど。長い・・・

デスクトップは、guestとしてログインされている。
rootのパスワードはわからないが、sudo でrootになれる。
$ sudo su
#
あとはとりあえずネットワークが使えるようにして、rebootできちんと立ち上がることが確認できれば、物置の奥で稼働させる予定。
ちなみにRedHatのつもりで少しいじったけど、なんかもう自分の知っている時代のRedHat(ES4)とは別もの、って感じ。
いろいろ作法が変わっていて、こうすれば動くはずのものが動かなくて、ここにあるはずのものがなくて、正直かなりゲンナリしてます。
つづく。
2013年09月22日
BeagleBone Blackをfedoraで動かす その2
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
その1のfedora19の導入についてはこちらを参照。
物置に設置する前に、最低限リモートアクセスできるようにしておく。
■ネットワークの確認
DHCPのIPアドレスを取得してみる。
取得したIPアドレスの確認
■タイムゾーンの変更
日本時間に変更
時刻合わせ
■スタートアップの準備
rc.localが使える。
ただし初期は/etc/rc.d/rc.local が無いので作成する。
ネットワーク設定は後できちんとやるとして、取り急ぎdhclientを登録してみる。
/etc/rc.d/rc.local ファイル例
実行権付与
以上でOK。
ちなみにsystemctl による rc-local.service の登録は不要。
再起動してDHCPでIPアドレスが拾えていることを確認。
とりあえずここまでで一旦終わらせて、物置の片隅に設置することにした。
ちゃんとしたネットワーク設定はその後で。
その1のfedora19の導入についてはこちらを参照。
物置に設置する前に、最低限リモートアクセスできるようにしておく。
■ネットワークの確認
DHCPのIPアドレスを取得してみる。
# dhclient
取得したIPアドレスの確認
# ifconfig
■タイムゾーンの変更
日本時間に変更
# ln -fs /usr/share/zoneinfo/Japan /etc/localtime
時刻合わせ
# ntpdate ntp.nict.jp
■スタートアップの準備
rc.localが使える。
ただし初期は/etc/rc.d/rc.local が無いので作成する。
ネットワーク設定は後できちんとやるとして、取り急ぎdhclientを登録してみる。
/etc/rc.d/rc.local ファイル例
#!/bin/sh
/sbin/dhclient
実行権付与
# chmod 755 /etc/rc.d/rc.local
以上でOK。
ちなみにsystemctl による rc-local.service の登録は不要。
再起動してDHCPでIPアドレスが拾えていることを確認。
とりあえずここまでで一旦終わらせて、物置の片隅に設置することにした。
ちゃんとしたネットワーク設定はその後で。
2013年09月24日
BeagleBone Black 自作ケース
ネットワークアクセスできるようになったので、あとは物置の片隅にでも置いておけばいいわけだが。。。
BeagleBone Black(BBB)は基板だけで売られているコンピュータである。
このままで使うことこそ男らしい。
商品名の「Black」にもそのような意味も込められている。(と思う)
よし、このまま使おう!
と思ったけど、物置にアクセスするのは自分だけではないので、仕方ないがケースに入れることにする。
専用のケースを購入しようと思ったんだけど、amazonで2600円もするじゃないの。
5000円の本体にケースが2600円というのもなんだかね。
いや、トータル7600円のコンピュータを買ったと思えば安いもんだけど、なんだろうね、こんなただのアクリルケースを2600円で買うのがばからしい。
とりあえず家の中で適当なケースを探してみたところ、なんと名刺ケースがジャストサイズなんですね。
5000円のコンピュータにはこれで十分だと思います、はい。
端子の位置に合わせて、こんな感じに超音波カッターで穴を空けてみた。



いつかきちんと仕上げをしようと思う。
ケースに入れたところ。





フル配線したところ。


通常はこの配線。LANとUSB給電のみ。


物置の設置状態。

電源のON/OFFがしやすいよう、スイッチ付きのUSBハブから給電している。
BeagleBone Black(BBB)は基板だけで売られているコンピュータである。
このままで使うことこそ男らしい。
商品名の「Black」にもそのような意味も込められている。(と思う)
よし、このまま使おう!
と思ったけど、物置にアクセスするのは自分だけではないので、仕方ないがケースに入れることにする。
専用のケースを購入しようと思ったんだけど、amazonで2600円もするじゃないの。
5000円の本体にケースが2600円というのもなんだかね。
いや、トータル7600円のコンピュータを買ったと思えば安いもんだけど、なんだろうね、こんなただのアクリルケースを2600円で買うのがばからしい。
とりあえず家の中で適当なケースを探してみたところ、なんと名刺ケースがジャストサイズなんですね。
5000円のコンピュータにはこれで十分だと思います、はい。
端子の位置に合わせて、こんな感じに超音波カッターで穴を空けてみた。



いつかきちんと仕上げをしようと思う。
ケースに入れたところ。





フル配線したところ。


通常はこの配線。LANとUSB給電のみ。


物置の設置状態。

電源のON/OFFがしやすいよう、スイッチ付きのUSBハブから給電している。
2013年09月25日
BeagleBone Black fedoraのデスクトップをリモート表示
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
fedora20の場合はこちらを参照。
BBBは物置の中で稼働させているので、デスクトップの画面をリモートで表示できるように設定する。
そもそもデスクトップは使わないから物置に設置してるわけだが、いざデスクトップを使いたい、ってなった時に、またモニタ、キーボードを配線するのは超絶めんどくさい。
というわけで、デスクトップはリモートからいつでも呼び出せるようにする。
fedora19で動作しているデスクトップはMATEだが、MATEのX関連の設定がいまいちよくわからなかったので、Xserverではなく手っ取り早いところでVNCにすることにした。
BBBのfedora19は、初期状態ではguestがログイン状態のデスクトップが起動するので、とりあえずguestの画面をWindows PCの画面に表示してみる。
■用意するもの
BBB側
・x11vnc
Windows側
・UltraVNC Viewer (v1.1.9.3)
http://www.forest.impress.co.jp/library/software/ultravnc/
とりあえず両方ともインストールを先にしておく。
UltraVNC Viewer のインストールは割愛。
■x11vncのインストール
■動作確認
モニタをつなぐとguestのデスクトップが立ち上がっているはずなので、このデスクトップを転送してみる。
とりあえずguestになってx11vncを起動する。
この状態で、Windowsより UltraVNC Viewer にて接続する。
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

Connect ボタンを押すと、パスワードも聞かれずに以下のようなMATEのデスクトップが表示される。

VNCとしてのレスポンスはいいけど、元々のデスクトップが重いので操作は結構ストレスがたまりますなぁ。
UltraVNC Viewer を終了させると、BBB側のx11vncも終了する。
■常時利用できるよう設定する
常時接続できるよう、セッション断でx11vncの待ち受けを終了させないことと、パスワード設定、自動起動設定を行う。
パスワードの設定
guestになって以下を実行し、x11vncのパスワードを設定しておく。
設定したらそのままx11vncを起動し、Windows側から接続してみる。
Windows側では以下のパスワード入力ダイアログが表示されればOK。

x11vncの自動起動設定
guestユーザ権限で待ち受け、UltraVNC Viewer を終了させてもx11vncの待ち受けは継続させるようにする。
以下のコマンドを、BBB起動時に自動で実行させればOK。
しかし、/etc/rc.d/rc.local に記述してみてもうまく実行されない。
/etc/rc.d/rc.local はきちんと実行されることは確認済なので、タイミングの問題かもしれない。
多分、guestのデスクトップが構成される前に実行されて失敗してるのではないだろうか?
試しに以下のようなスクリプト(/startup.sh)を書いてrc.localから呼び出すようにしたらうまくいった。
/etc/rc.d/rc.local の内容
/startup.sh の内容
うーん、なんだかいろいろスマートじゃないなぁ・・・
このようなsleepによる大雑把なタイミング調整もいやなんだけど、遊びマシンなのでまあ良しとするか。
とりあえずこれでいつでもデスクトップ画面を呼び出せるようになった。デスクトップはあまり使う機会ないけど。
fedora19の導入についてはこちらを参照。
fedora20の場合はこちらを参照。
BBBは物置の中で稼働させているので、デスクトップの画面をリモートで表示できるように設定する。
そもそもデスクトップは使わないから物置に設置してるわけだが、いざデスクトップを使いたい、ってなった時に、またモニタ、キーボードを配線するのは超絶めんどくさい。
というわけで、デスクトップはリモートからいつでも呼び出せるようにする。
fedora19で動作しているデスクトップはMATEだが、MATEのX関連の設定がいまいちよくわからなかったので、Xserverではなく手っ取り早いところでVNCにすることにした。
BBBのfedora19は、初期状態ではguestがログイン状態のデスクトップが起動するので、とりあえずguestの画面をWindows PCの画面に表示してみる。
■用意するもの
BBB側
・x11vnc
Windows側
・UltraVNC Viewer (v1.1.9.3)
http://www.forest.impress.co.jp/library/software/ultravnc/
とりあえず両方ともインストールを先にしておく。
UltraVNC Viewer のインストールは割愛。
■x11vncのインストール
# yum -y install x11vncx11vnc 0.9.13 がインストールされた。
■動作確認
モニタをつなぐとguestのデスクトップが立ち上がっているはずなので、このデスクトップを転送してみる。
とりあえずguestになってx11vncを起動する。
# su - guest
$ x11vnc -display :0
この状態で、Windowsより UltraVNC Viewer にて接続する。
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

Connect ボタンを押すと、パスワードも聞かれずに以下のようなMATEのデスクトップが表示される。

VNCとしてのレスポンスはいいけど、元々のデスクトップが重いので操作は結構ストレスがたまりますなぁ。
UltraVNC Viewer を終了させると、BBB側のx11vncも終了する。
■常時利用できるよう設定する
常時接続できるよう、セッション断でx11vncの待ち受けを終了させないことと、パスワード設定、自動起動設定を行う。
パスワードの設定
guestになって以下を実行し、x11vncのパスワードを設定しておく。
# su - guest
$ x11vnc -storepasswd
設定したらそのままx11vncを起動し、Windows側から接続してみる。
$ x11vnc -usepw -display :0
Windows側では以下のパスワード入力ダイアログが表示されればOK。

x11vncの自動起動設定
guestユーザ権限で待ち受け、UltraVNC Viewer を終了させてもx11vncの待ち受けは継続させるようにする。
以下のコマンドを、BBB起動時に自動で実行させればOK。
/usr/bin/su - guest -c '/usr/bin/x11vnc -usepw -display :0 -forever &'
しかし、/etc/rc.d/rc.local に記述してみてもうまく実行されない。
/etc/rc.d/rc.local はきちんと実行されることは確認済なので、タイミングの問題かもしれない。
多分、guestのデスクトップが構成される前に実行されて失敗してるのではないだろうか?
試しに以下のようなスクリプト(/startup.sh)を書いてrc.localから呼び出すようにしたらうまくいった。
/etc/rc.d/rc.local の内容
#!/bin/sh
/startup.sh
/startup.sh の内容
#!/bin/sh
/usr/bin/sleep 150
/usr/bin/su - guest -c '/usr/bin/x11vnc -usepw -display :0 -forever &'
うーん、なんだかいろいろスマートじゃないなぁ・・・
このようなsleepによる大雑把なタイミング調整もいやなんだけど、遊びマシンなのでまあ良しとするか。
とりあえずこれでいつでもデスクトップ画面を呼び出せるようになった。デスクトップはあまり使う機会ないけど。
2013年09月26日
BeagleBone Black fedora SDカードの残り領域をマウントする
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
fedora19を導入したSDカードは16GBなので、使われていない残りの約8GBをマウントする。
■SDカードのデバイス名取得
ディスク一覧表示し、SDカードのデバイス名を得る。
容量的に/dev/mmcblk0がSDカード。
※使われていないパーティション(約8GB)は、ここではまだ見えていない。
■パーティション作成
/dev/mmcblk0の残り領域にパーティションを作成する。
ここで再起動したくなければ、partprobeで変更を認識させられる。
■作成したパーティションをext3にフォーマット。
■マウントポイントの作成
■マウント
■自動マウント設定
/etc/fstab の最終行に以下のように追記
再起動してマウントされることを確認。
以上。
fedora19の導入についてはこちらを参照。
fedora19を導入したSDカードは16GBなので、使われていない残りの約8GBをマウントする。
■SDカードのデバイス名取得
ディスク一覧表示し、SDカードのデバイス名を得る。
# fdisk -l
Disk /dev/mmcblk0: 15.7 GB, 15720251392 bytes, 30703616 sectors
以下省略・・・
容量的に/dev/mmcblk0がSDカード。
※使われていないパーティション(約8GB)は、ここではまだ見えていない。
■パーティション作成
/dev/mmcblk0の残り領域にパーティションを作成する。
# fdisk /dev/mmcblk0
状態確認
Command (m for help): p
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1953 41015 19531+ c W95 FAT32 (LBA)
/dev/mmcblk0p2 41016 1041015 500000 c W95 FAT32 (LBA)
/dev/mmcblk0p3 1041016 13736328 6347656+ 83 Linux
パーティション作成
Command (m for help): n
Partition type:
p primary (3 primary, 0 extended, 1 free)
e extended
Select (default e): p
Selected partition 4
First sector (13736329-30703615, default 13737984):
Using default value 13737984
Last sector, +sectors or +size{K,M,G} (13737984-30703615, default 30703615):
Using default value 30703615
Partition 4 of type Linux and of size 8.1 GiB is set
状態確認
Command (m for help): p
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1953 41015 19531+ c W95 FAT32 (LBA)
/dev/mmcblk0p2 41016 1041015 500000 c W95 FAT32 (LBA)
/dev/mmcblk0p3 1041016 13736328 6347656+ 83 Linux
/dev/mmcblk0p4 13737984 30703615 8482816 83 Linux ← 作成したパーティション
反映
Command (m for help): w
ここで再起動したくなければ、partprobeで変更を認識させられる。
# partprobe
■作成したパーティションをext3にフォーマット。
# mke2fs -j /dev/mmcblk0p4
■マウントポイントの作成
# mkdir /data
■マウント
# mount -t ext3 /dev/mmcblk0p4 /data
■自動マウント設定
/etc/fstab の最終行に以下のように追記
UUID=b13fbe80-6d24-4a42-aad6-e046e3b15580 / ext4 defaults,noatime 0 0
UUID=0821-5260 /boot/uboot vfat defaults,noatime 0 0
UUID=01643454-060c-4f5d-8ed4-ef6a9a7a1567 swap swap defaults,noatime 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/mmcblk0p4 /data ext3 defaults 0 0
再起動してマウントされることを確認。
以上。
2013年09月27日
BeagleBone Black fedoraにgccをインストール
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
gcc等のコンパイル環境はyumで簡単に導入できる。
■gccインストール
■g++インストール
以上で完了。
かなり時間はかかる。
試したところ、きちんとコンパイルすることができた。
こんなおもちゃのようなコンピュータでもgccで開発できると思うと感慨深いものがある。
fedora19の導入についてはこちらを参照。
gcc等のコンパイル環境はyumで簡単に導入できる。
■gccインストール
# yum -y install gccgcc 4.8.1 がインストールされた。
■g++インストール
# yum -y install gcc-c++
以上で完了。
かなり時間はかかる。
試したところ、きちんとコンパイルすることができた。
こんなおもちゃのようなコンピュータでもgccで開発できると思うと感慨深いものがある。
2013年09月29日
BeagleBone Black fedoraにDLNA(PMS)をインストール
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
BeagleBone Blackのfedora19でDLNAサーバであるPMS(PS3 Media Server)を動かすのはいろいろと面倒だったのでそのメモ。
arm用のパッケージがないものはソースからコンパイルするので、gcc,g++はインストールしておく。gcc,g++のインストールはこちら。
PMS(PS3 Media Server)を動作させるにあたり、インストールしなければならないもの。
■用意するもの
・JAVA jre (必須)
・PS3 Media Server (PMS本体)
・mediainfo.so (多分必須)
・ffmpeg (任意と思われる)
・mplayer (任意と思われる)
以下それぞれのインストールの備忘録。
■JAVA jreのインストール
yumでインストールできる。
■PS3 Media Server (PMS本体)のインストール
http://sourceforge.net/projects/ps3mediaserver/files/
上記より、現在最新のpms-1.90.1-generic-linux-unix.tar.gzをダウンロード。
解凍
PMSはどこに移動させてもよいので、定番の以下へ移動させた。
動作確認
何も設定しなくともデフォルト設定で動作するので、そのまま起動してみる。
ちなみにデスクトップからでなくてもよくて、teraterm等のターミナル上からコマンド実行。
この状態でDLNAプレイヤーから参照できるかを試す。
デフォルトでは「/」が公開フォルダとなり、DLNAプレイヤーから見える。
Android上のTwonky beamからPMSが見え、mp4を再生することもできた。
PS3からは「データが壊れています」とのエラーで再生不可。サムネイルも表示されない。
ちなみにこのmp4は、Windows上のPMS経由でPS3で見る場合は問題なく再生できているファイル。
とりあえず起動できることはわかったので、設定ファイルを調整する。
設定ファイルは、/opt/pms-1.90.1/PMS.conf だが、置き場所はこのフォルダではないので注意。
~/.config/PMS/PMS.conf が正しい置き場所。
PMS.confを正しい置き場所へコピー
PMS.conf 変更点
この状態で起動してもまだPS3で再生できなかった。
パススルーであれば他のツールは不要な気もするが、トレースログではmediainfo.so やMPlayerでエラーになっているので、よくわからんけど他のアプリもインストールすることにした。
■mediainfo.soのインストール
arm用のパッケージは見つからないので、ソースからコンパイルする。
■ffmpegのインストール
こちらもソースからコンパイルする。
■mplayerのインストール
こちらもソースからコンパイルする。
以上でインストール完了。
■PMS動作確認
上記の通り、mediainfo、ffmpeg、MplayerがインストールできたところでPMSの動作確認。
PMS起動
ここまでしてやっとPS3で再生できた。サムネイルも表示された。
■評価
使えるようにはなったものの、いろいろ問題が多くてBBB上のPMSは使い物にならない、というのが現状の評価。
ちょっと残念。
検証したコンテンツは以下の2種類。
1440x1080 mpeg2 ts
1440x1080 H264 mp4 (tsをエンコードしたもの)
トランスコードさせずにパススルーのみの利用。
再生するだけであればコマ落ちなく視聴は可能。
ただし、早送りとかのトリックプレーを行うと、プロトコルエラーが発生し、リセットが必要。
ちなみに同コンテンツをWindows上(i7-4770)のPMS経由だと何の問題もなく超快適。
根本的にBBBのリソース不足ということだろう。予想通りだけど。
fedora19の導入についてはこちらを参照。
BeagleBone Blackのfedora19でDLNAサーバであるPMS(PS3 Media Server)を動かすのはいろいろと面倒だったのでそのメモ。
arm用のパッケージがないものはソースからコンパイルするので、gcc,g++はインストールしておく。gcc,g++のインストールはこちら。
PMS(PS3 Media Server)を動作させるにあたり、インストールしなければならないもの。
■用意するもの
・JAVA jre (必須)
・PS3 Media Server (PMS本体)
・mediainfo.so (多分必須)
・ffmpeg (任意と思われる)
・mplayer (任意と思われる)
以下それぞれのインストールの備忘録。
■JAVA jreのインストール
yumでインストールできる。
# yum -y install jrejava 1.7.0_25がインストールされた。
■PS3 Media Server (PMS本体)のインストール
http://sourceforge.net/projects/ps3mediaserver/files/
上記より、現在最新のpms-1.90.1-generic-linux-unix.tar.gzをダウンロード。
# wget http://sourceforge.net/projects/ps3mediaserver/files/pms-1.90.1-generic-linux-unix.tar.gz
解凍
# gtar zxvf pms-1.90.1-generic-linux-unix.tar.gzフォルダ pms-1.90.1 ができる。
PMSはどこに移動させてもよいので、定番の以下へ移動させた。
# mv pms-1.90.1 /opt/
動作確認
何も設定しなくともデフォルト設定で動作するので、そのまま起動してみる。
ちなみにデスクトップからでなくてもよくて、teraterm等のターミナル上からコマンド実行。
# /opt/pms-1.90.1/PMS.sh何やらたくさん表示される。Error という文字が見えた気もするが気にしないw
この状態でDLNAプレイヤーから参照できるかを試す。
デフォルトでは「/」が公開フォルダとなり、DLNAプレイヤーから見える。
Android上のTwonky beamからPMSが見え、mp4を再生することもできた。
PS3からは「データが壊れています」とのエラーで再生不可。サムネイルも表示されない。
ちなみにこのmp4は、Windows上のPMS経由でPS3で見る場合は問題なく再生できているファイル。
とりあえず起動できることはわかったので、設定ファイルを調整する。
設定ファイルは、/opt/pms-1.90.1/PMS.conf だが、置き場所はこのフォルダではないので注意。
~/.config/PMS/PMS.conf が正しい置き場所。
PMS.confを正しい置き場所へコピー
# cp /opt/pms-1.90.1/PMS.conf ~/.config/PMS/PMS.conf(うちではrootで起動しているので /root/.config/PMS/PMS.conf となる)
PMS.conf 変更点
name = BBB
language = ja
folders = /media ← 公開フォルダ
disable_transcode_for_extensions = mp4,ts ← パススルーする拡張子
この状態で起動してもまだPS3で再生できなかった。
パススルーであれば他のツールは不要な気もするが、トレースログではmediainfo.so やMPlayerでエラーになっているので、よくわからんけど他のアプリもインストールすることにした。
■mediainfo.soのインストール
arm用のパッケージは見つからないので、ソースからコンパイルする。
ソースのダウンロード
http://mediaarea.net/ja/MediaInfo/Download/Source
上記より All in one package のSO をダウンロード。
# wget http://mediaarea.net/download/binary/libmediainfo0/0.7.64/MediaInfo_DLL_0.7.64_GNU_FromSource.tar.bz2
# tar jxvf MediaInfo_DLL_0.7.64_GNU_FromSource.tar.bz2
# cd MediaInfo_DLL_GNU_FromSource/
コンパイル
# ./SO_Compile.sh
インストール
# cd MediaInfoLib/Project/GNU/Library/
# make install
以下のようにlibフォルダにlibmediainfo.soがあればOK
# ls /lib/*mediainfo*
/lib/libmediainfo.la /lib/libmediainfo.so /lib/libmediainfo.so.0 /lib/libmediainfo.so.0.0.0
■ffmpegのインストール
こちらもソースからコンパイルする。
ソースのダウンロード
http://www.ffmpeg.org/download.html
上記より、ページ下のほうの、Download bzip2 tarball をダウンロード。
# wget http://ffmpeg.org/releases/ffmpeg-2.0.1.tar.bz2
bz2の解凍
# tar jxvf ffmpeg-2.0.1.tar.bz2
コンパイル 〜 インストール
# cd ffmpeg-2.0.1/
# ./configure
# make
# make install
動作確認
# ffmpeg
ffmpeg version 2.0.1 Copyright (c) 2000-2013 the FFmpeg developers
built on Sep 20 2013 09:22:28 with gcc 4.8.1 (GCC) 20130603 (Red Hat 4.8.1-1)
configuration:
libavutil 52. 38.100 / 52. 38.100
libavcodec 55. 18.102 / 55. 18.102
libavformat 55. 12.100 / 55. 12.100
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 79.101 / 3. 79.101
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
Use -h to get full help or, even better, run 'man ffmpeg'
■mplayerのインストール
こちらもソースからコンパイルする。
ソースのダウンロード
# wget http://dl.atrpms.net/all/mplayer-1.1.1-92.src.rpm
rpmの解凍
# rpm2cpio mplayer-1.1.1-92.src.rpm | cpio -id
コンパイル 〜 インストール
# cd MPlayer-1.1.1/
# ./configure
# make install
動作確認
# mplayer
MPlayer 1.1-4.8.1 (C) 2000-2012 MPlayer Team
Usage: mplayer [options] [url|path/]filename
Basic options: (complete list in the man page)
-voselect video output driver ('-vo help' for a list)
-aoselect audio output driver ('-ao help' for a list)
vcd://play (S)VCD (Super Video CD) track (raw device, no mount)
dvd://play DVD title from device instead of plain file
-alang/-slang select DVD audio/subtitle language (by 2-char country code)
-ssseek to given (seconds or hh:mm:ss) position
-nosound do not play sound
-fs fullscreen playback (or -vm, -zoom, details in the man page)
-x-y set display resolution (for use with -vm or -zoom)
-subspecify subtitle file to use (also see -subfps, -subdelay)
-playlistspecify playlist file
-vid x -aid y select video (x) and audio (y) stream to play
-fps x -srate y change video (x fps) and audio (y Hz) rate
-ppenable postprocessing filter (details in the man page)
-framedrop enable frame dropping (for slow machines)
Basic keys: (complete list in the man page, also check input.conf)
<- or -> seek backward/forward 10 seconds
down or up seek backward/forward 1 minute
pgdown or pgup seek backward/forward 10 minutes
< or > step backward/forward in playlist
p or SPACE pause movie (press any key to continue)
q or ESC stop playing and quit program
+ or - adjust audio delay by +/- 0.1 second
o cycle OSD mode: none / seekbar / seekbar + timer
* or / increase or decrease PCM volume
x or z adjust subtitle delay by +/- 0.1 second
r or t adjust subtitle position up/down, also see -vf expand
* * * SEE THE MAN PAGE FOR DETAILS, FURTHER (ADVANCED) OPTIONS AND KEYS * * *
以上でインストール完了。
■PMS動作確認
上記の通り、mediainfo、ffmpeg、MplayerがインストールできたところでPMSの動作確認。
PMS起動
# /opt/pms-1.90.1/PMS.sh表示されるトレースログを見て、エラーがないことを確認。
ここまでしてやっとPS3で再生できた。サムネイルも表示された。
■評価
使えるようにはなったものの、いろいろ問題が多くてBBB上のPMSは使い物にならない、というのが現状の評価。
ちょっと残念。
検証したコンテンツは以下の2種類。
1440x1080 mpeg2 ts
1440x1080 H264 mp4 (tsをエンコードしたもの)
トランスコードさせずにパススルーのみの利用。
再生するだけであればコマ落ちなく視聴は可能。
ただし、早送りとかのトリックプレーを行うと、プロトコルエラーが発生し、リセットが必要。
ちなみに同コンテンツをWindows上(i7-4770)のPMS経由だと何の問題もなく超快適。
根本的にBBBのリソース不足ということだろう。予想通りだけど。
2013年10月01日
BeagleBone Black fedoraにプロキシ(squid)をインストール
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
リソースが少ないので、キャッシュを生成しない、オンメモリ動作のプロキシとして動作させる。
■インストール
■設定ファイル
/etc/squid/squid.conf の内容
設定ファイルのチェック
■動作チェック、およびサービス登録
サービス起動
無事起動できることを確認したら、自動起動するようサービス登録。
■評価
性能的に全く期待はしてなかったが、予想外に高性能で、全く問題なく安定稼働。
回線速度計測サイトで、下り76Mbps、上り67Mbps出ていた。
この値はWAN側回線の速度と同じだったので、スループット限界はまだ高いところにあると見ていいだろう。
fedora19の導入についてはこちらを参照。
リソースが少ないので、キャッシュを生成しない、オンメモリ動作のプロキシとして動作させる。
■インストール
# yum -y install squidsquid 3.2.13 がインストールされた。
■設定ファイル
/etc/squid/squid.conf の内容
# Recommended minimum configuration:
#
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
#acl all src 0.0.0.0/0.0.0.0
acl localnet src 192.168.12.0/24
http_access allow localnet
http_access deny all
# for hide local address
forwarded_for OFF
visible_hostname beaglebone
#for no cache
acl NOCACHE src all
cache deny NOCACHE
#for no log
cache_store_log none
cache_log /dev/null
cache_access_log /dev/null
#for hide proxy access
request_header_access X-Forwarded-For deny all
request_header_access Via deny all
request_header_access Cache-Control deny all
# Squid normally listens to port 3128
http_port 3128
# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
設定ファイルのチェック
# squid checkエラーが無いことを確認。
■動作チェック、およびサービス登録
サービス起動
# systemctl start squid.service起動したら他のマシンからプロキシ経由でWebアクセスできるか確認。
無事起動できることを確認したら、自動起動するようサービス登録。
# systemctl enable squid.service
■評価
性能的に全く期待はしてなかったが、予想外に高性能で、全く問題なく安定稼働。
回線速度計測サイトで、下り76Mbps、上り67Mbps出ていた。
この値はWAN側回線の速度と同じだったので、スループット限界はまだ高いところにあると見ていいだろう。
2013年10月04日
BeagleBone Black fedora にsambaインストール
以下はfedora19を導入したBeagleBone Black(BBB)での手順。
fedora19の導入についてはこちらを参照。
smbの設定はいつもいつもいつもハマる!
最初は接続できていた設定ファイルに戻しても接続できなくなるので、もうわけがわからず発狂寸前だったが、今日はついにその原因がわかった。
接続できない状態になると以下のようなダイアログが表示され、こうなってしまうと何をやっても接続できない。

ネットワークエラー
「\\bbb に対するアクセス許可がありません。ネットワーク管理者にアクセス許可を要求してください。」
とのメッセージ。※bbbはわが家でのBeagleBone Blackのホスト名。
うーん、アクセス権も含めて接続できていた設定に全て戻してるのに、さっぱり原因がわかんねーよ。もっと的を射たメッセージを出せないのかね。
いろいろ調べた結果、一度接続した共有名は、Windows上でクリアされないらしい。
Windows上の共有情報は、ログオフか再起動しないとクリアされない。
そのため、一度接続した後、ログオンしたままでsamba側で共有の設定を変更した場合、Windows側は古い共有情報でアクセスしようとするので、おかしな状態になってしまうようだ。
ログオフせずに共有をクリアするには、Windows上で以下のコマンドを実行する。
sambaの設定を変更した後は、毎回これを行うことで、正しく動作確認ができる。
いままではこれをやってなかったから、sambaの設定変更中にドツボ状態だったわけだ。
以上を踏まえた上でfedora19へのsambaのインストールと設定を行う。
sambaインストール
ユーザの追加
設定ファイルの編集
もし設定ファイルを直接いじりたくなければ、以下に示すGUI設定ツールをインストールする。
GUI設定ツールをインストール
smb.confベースはこれで作成して、あとは手動で/etc/samba/smb.confを微調整。
smbは簡単に動かなくなるので、これが一番楽で確実だったりする。
GUIツール system-config-samba のインストール
samba設定
その前にとりあえず既存の/etc/samba/smb.confを削除。
設定は system-config-samba にて行う。(GUIなのでデスクトップ画面で)
BBB上のfedora19のデスクトップの表示はこちらを参照。

このツール上で、sambaユーザの追加、公開フォルダの設定を行う。
難しいところは無いので見ればわかる。
設定後、/etc/samba/smb.conf が生成される。
あとはsmb.confを直接微調整。
最後は以下のコマンドで構文チェックを忘れずに。
-vをつけると、smb.confに指定していないデフォルト値も表示。
最終的なsmb.confの内容
ゲスト不可、ユーザadminのみアクセス可能。
サービス起動させて動作確認
Windowsからエクスプローラで参照できることを確認。
エクスプローラのパス欄に \\サーバ名 でアクセス。
うちの場合、\\192.168.12.100 または \\bbb
ID/パスワードを聞かれるので入力。認証が成功すると、共有設定したフォルダtmpとdataが見えるようになる。
以上、問題なさそうだったら、boot時に自動起動するようサービス登録。
BBBを再起動してsambaアクセスできることを確認できれば完了。
fedora19の導入についてはこちらを参照。
smbの設定はいつもいつもいつもハマる!
最初は接続できていた設定ファイルに戻しても接続できなくなるので、もうわけがわからず発狂寸前だったが、今日はついにその原因がわかった。
接続できない状態になると以下のようなダイアログが表示され、こうなってしまうと何をやっても接続できない。

ネットワークエラー
「\\bbb に対するアクセス許可がありません。ネットワーク管理者にアクセス許可を要求してください。」
とのメッセージ。※bbbはわが家でのBeagleBone Blackのホスト名。
うーん、アクセス権も含めて接続できていた設定に全て戻してるのに、さっぱり原因がわかんねーよ。もっと的を射たメッセージを出せないのかね。
いろいろ調べた結果、一度接続した共有名は、Windows上でクリアされないらしい。
Windows上の共有情報は、ログオフか再起動しないとクリアされない。
そのため、一度接続した後、ログオンしたままでsamba側で共有の設定を変更した場合、Windows側は古い共有情報でアクセスしようとするので、おかしな状態になってしまうようだ。
ログオフせずに共有をクリアするには、Windows上で以下のコマンドを実行する。
> net use * /delete
sambaの設定を変更した後は、毎回これを行うことで、正しく動作確認ができる。
いままではこれをやってなかったから、sambaの設定変更中にドツボ状態だったわけだ。
以上を踏まえた上でfedora19へのsambaのインストールと設定を行う。
sambaインストール
# yum -y install sambasamba4.0.9がインストールされる。
ユーザの追加
# pdbedit -a username
設定ファイルの編集
もし設定ファイルを直接いじりたくなければ、以下に示すGUI設定ツールをインストールする。
GUI設定ツールをインストール
smb.confベースはこれで作成して、あとは手動で/etc/samba/smb.confを微調整。
smbは簡単に動かなくなるので、これが一番楽で確実だったりする。
GUIツール system-config-samba のインストール
# yum -y install system-config-samba
samba設定
その前にとりあえず既存の/etc/samba/smb.confを削除。
# rm /etc/samba/smb.conf
設定は system-config-samba にて行う。(GUIなのでデスクトップ画面で)
BBB上のfedora19のデスクトップの表示はこちらを参照。

このツール上で、sambaユーザの追加、公開フォルダの設定を行う。
難しいところは無いので見ればわかる。
設定後、/etc/samba/smb.conf が生成される。
あとはsmb.confを直接微調整。
最後は以下のコマンドで構文チェックを忘れずに。
# testparm
-vをつけると、smb.confに指定していないデフォルト値も表示。
# testparm -v
最終的なsmb.confの内容
ゲスト不可、ユーザadminのみアクセス可能。
[global]
server string = Samba Server Version %v
log file = /var/log/samba/log.%m
max log size = 50
idmap config * : backend = tdb
cups options = raw
[tmp]
path = /tmp
valid users = admin
read only = No
[data]
path = /data
valid users = admin
read only = No
サービス起動させて動作確認
# systemctl start smb.service
Windowsからエクスプローラで参照できることを確認。
エクスプローラのパス欄に \\サーバ名 でアクセス。
うちの場合、\\192.168.12.100 または \\bbb
ID/パスワードを聞かれるので入力。認証が成功すると、共有設定したフォルダtmpとdataが見えるようになる。
以上、問題なさそうだったら、boot時に自動起動するようサービス登録。
# systemctl enable smb.service
BBBを再起動してsambaアクセスできることを確認できれば完了。
2013年10月05日
BeagleBone Black fedora USBストレージがI/Oエラー(解決)
以下はfedora19を導入したBeagleBone Black(BBB)で試したこと。
fedora19の導入についてはこちらを参照。
BeagleBone Black(BBB)にはUSBポートがあるので、ここにUSBメモリやらHDD等のストレージを利用できる。
しかし残念なことに、マウントしたUSBストレージに書き込んでいると、180MBぐらい書き込んだところでI/Oエラーになって、以後USBメモリにアクセアスできなくなってしまう。
USBメモリの問題かもしれないので、2種類のUSBメモリを試してみたけど、結果は同じ。
今のところ原因不明。
やったこと。
USBメモリのマウント
ext3フォーマット
USBストレージが使えないとなると結構痛い。。。
2013/10/15追記(とりあえず解決)
いろいろ試した結果、原因はおそらくUSBポートの電力不足だと思われる。
・BBB直結だと、USB-HDDは完全にNG、電源すら入らない
・USBメモリは一応使えるが、上記の通り不安定
・BBBへの給電を、5V/2AのACアダプタで給電してみても結果は変わらず
・外部給電のUSBハブに繋げると問題なく利用できる
以上のことから、USBポートの電力不足とみて間違いないだろう。
あと別の問題として、USBポートに挿したものをうまく認識してくれないことが多々ある。この時、dmesgには何も出ない。
この場合は以下のコマンドを試すと認識してくれることがある。
これでだめならあきらめて再起動している。
ちなみに起動時からUSB接続しておけば、100%認識されるので、常設デバイスとして利用は可能。(外部給電のUSBハブ経由)
fedora19の導入についてはこちらを参照。
BeagleBone Black(BBB)にはUSBポートがあるので、ここにUSBメモリやらHDD等のストレージを利用できる。
しかし残念なことに、マウントしたUSBストレージに書き込んでいると、180MBぐらい書き込んだところでI/Oエラーになって、以後USBメモリにアクセアスできなくなってしまう。
USBメモリの問題かもしれないので、2種類のUSBメモリを試してみたけど、結果は同じ。
今のところ原因不明。
やったこと。
USBメモリのマウント
ext3フォーマット
USBストレージが使えないとなると結構痛い。。。
2013/10/15追記(とりあえず解決)
いろいろ試した結果、原因はおそらくUSBポートの電力不足だと思われる。
・BBB直結だと、USB-HDDは完全にNG、電源すら入らない
・USBメモリは一応使えるが、上記の通り不安定
・BBBへの給電を、5V/2AのACアダプタで給電してみても結果は変わらず
・外部給電のUSBハブに繋げると問題なく利用できる
以上のことから、USBポートの電力不足とみて間違いないだろう。
あと別の問題として、USBポートに挿したものをうまく認識してくれないことが多々ある。この時、dmesgには何も出ない。
この場合は以下のコマンドを試すと認識してくれることがある。
# echo -1 > /sys/bus/usb/devices/usb1/power/autosuspend
これでだめならあきらめて再起動している。
ちなみに起動時からUSB接続しておけば、100%認識されるので、常設デバイスとして利用は可能。(外部給電のUSBハブ経由)
2013年12月23日
BeagleBone Blackに fedora 20 をインストール
Fedora 20 が先週リリースされた。
ついにARMが「主要アーキテクチャ」として扱われるとのこと。つまりx86/64と同レベルの「主要アーキテクチャ」となる。
Fedora19より扱いが格段に良くなることが予想されるので、早速BBBにFedora20を導入してみた。
インストールは、BBBはモニタなしのLANケーブル接続のみで実施した。
起動可能なマイクロSDカードイメージの作成は、Windows、Linux上のどちらでも可能。それぞれのやり方のメモを以下に残す。
■■■Linux上でのFedora20 OSイメージ作成方法■■■
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・Linuxが動作しているPC(OSイメージ内を編集するのに必要)
当方はCentOS5.5のVMを利用。
■fedora20のダウンロードとマイクロSD上への展開
http://fedoraproject.org/ja/get-fedora#arm
上記ページより、VFAT ARMv7 イメージ をダウンロード。
デスクトップは好みに応じてどれでもよい。
当方はGNOMEにした。
あと、マイクロSDはUSBリーダ等でPCに接続しておく。
フォーマットは不要。
GNOME VFAT ARMv7 イメージをダウンロード 〜 マイクロSDへの展開
■u-bootの書き込み
まだブートパーティションは空っぽで起動できないので、以下の通りu-bootをブートパーティションにコピーする。
u-bootは、利用するボードの種類ごとに用意されており、上記作成したマイクロSD内から取り出すことができる。
上記マイクロSD作成後、一度抜き挿しすると、マイクロSDは自動マウントされ、パーティションの中が見える。マウントされるフォルダは以下の通り。
u-bootパーティション
/media/uboot
システムパーティション
/media/__
※新しいLinuxだと上記それぞれ以下にマウントされるので読み替えること。
/run/media/username/uboot
/run/media/username/__
BBB用のu-bootを、u-bootパーティションへコピーする。
とりあえずここまでで起動可能なメディアができあがり。
/etc/shadowを編集する。
くれぐれも母艦側を間違って編集しないよう、フォルダに注意。
マウントされたマイクロSD上のシステムパーティション内の/etc/shadowを、以下のように編集する。
/media/__/etc/shadow を編集
rootのパスワードを以下のように付与。このパスワードは「root」になる。
/media/__/etc/shadow 抜粋
次にselinuxを無効にする。
/media/__/etc/sysconfig/selinux を編集
以上でOK。
なお、DHCPで起動してくれるので、システムパーティション内をいじるのは上記2ファイルだけ。
■Fedora20の起動
上記マイクロSDをBBBに挿入し、LANケーブルを接続し、給電開始。
すると電源LED点灯のあと、インジケータLED2つ(USR0,USR1)が点灯。
30秒ほどしてインジケータLEDが消灯。
その後、インジケータLEDは一切点灯しないので注意。
Lチカしないので、てっきりbootに失敗しているかと思うが、待っていればちゃんと起動する。
インジケータLED消灯後、100秒ほどでpingに応答しだす。
DHCPで割り振られたアドレスは調べること。
あとはsshにて、root、パスワードroot、でログインできる。
以上。
なお、/dev/mmcblk0p3(=/)パーティションは、すでに99%使われている。
これでは何もできないので、以下のコマンドで残り領域全体まで
/dev/mmcblk0p3を拡張する。
以上で完了。
■■■Windows上でのFedora20 OSイメージ作成方法■■■
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・Fedora20 のOSイメージ
http://fedoraproject.org/ja/get-fedora#arm
上記ページより、VFAT ARMv7 イメージ をダウンロード。
デスクトップは好みに応じてどれでもよい。
当方はGNOMEにした。
ファイル名:Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz 967MB
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
・u-boot ファイル
http://rpmfind.net/linux/rpm2html/search.php?query=uboot-beaglebone%28armv7hl-32%29
上記サイトより、
uboot-beaglebone-2013.10-3.fc20.armv7hl.rpmをダウンロード。
■fedora20のイメージをマイクロSD上に展開
ダウンロードした Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz を7zip等で解凍。以下が生成される。
Fedora-Desktop-VFAT-armhfp-20-1-sda.raw 約4.6GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。
Fedora-Desktop-VFAT-armhfp-20-1-sda.raw とマイクロSDのドライブを選択して書き込み実行。
ファイル選択時、拡張子が.img限定になっているので、*.*を指定すること。

■u-bootの書き込み
まだブートパーティションは空っぽで起動できないので、以下の通りu-bootをブートパーティションにコピーする。
u-bootは、uboot-beaglebone-2013.10-3.fc20.armv7hl.rpm からファイルを取り出す。
rpmの解凍は、XacRettやLhaForge等を利用。以下の3ファイルが取り出せる。
MLO
u-boot.img
uEnv.txt.beaglebone → uEnv.txt にリネームすること
上記3ファイルをマイクロSDのルートにコピー
マイクロSDをセットしたUSBリーダを一度抜き挿しすると、ボリュームラベルが「uboot」の19MBの空メディアに見えるので、その19MBの領域に3ファイルをコピーする。
MLO
u-boot.img
uEnv.txt
とりあえずここまでで起動可能なメディアができあがり。
あとはマイクロSD上のLinuxパーティションを、Ext2Fsd等を利用してマウントし、sshでログインできるようrootのパスワードを書き換える。
パスワードファイル: /etc/shadow
設定するrootのパスワードとfedora20の起動については、上記Linux上での作成方法で示した、sshログインできるようにする 以降を参照。
以上。
ついにARMが「主要アーキテクチャ」として扱われるとのこと。つまりx86/64と同レベルの「主要アーキテクチャ」となる。
Fedora19より扱いが格段に良くなることが予想されるので、早速BBBにFedora20を導入してみた。
インストールは、BBBはモニタなしのLANケーブル接続のみで実施した。
起動可能なマイクロSDカードイメージの作成は、Windows、Linux上のどちらでも可能。それぞれのやり方のメモを以下に残す。
■■■Linux上でのFedora20 OSイメージ作成方法■■■
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・Linuxが動作しているPC(OSイメージ内を編集するのに必要)
当方はCentOS5.5のVMを利用。
■fedora20のダウンロードとマイクロSD上への展開
http://fedoraproject.org/ja/get-fedora#arm
上記ページより、VFAT ARMv7 イメージ をダウンロード。
デスクトップは好みに応じてどれでもよい。
当方はGNOMEにした。
あと、マイクロSDはUSBリーダ等でPCに接続しておく。
フォーマットは不要。
GNOME VFAT ARMv7 イメージをダウンロード 〜 マイクロSDへの展開
ダウンロード※当方環境ではマイクロSDは/dev/sdbだったが、環境によるので、dmesgやfdisk -l にてマイクロSDのデバイス名を確認しておくこと。
$ wget http://download.fedoraproject.org/pub/fedora/linux/releases/20/Images/armhfp/Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz
マイクロSDに書き込み
$ xzcat Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz > /dev/sdb
■u-bootの書き込み
まだブートパーティションは空っぽで起動できないので、以下の通りu-bootをブートパーティションにコピーする。
u-bootは、利用するボードの種類ごとに用意されており、上記作成したマイクロSD内から取り出すことができる。
上記マイクロSD作成後、一度抜き挿しすると、マイクロSDは自動マウントされ、パーティションの中が見える。マウントされるフォルダは以下の通り。
u-bootパーティション
/media/uboot
システムパーティション
/media/__
※新しいLinuxだと上記それぞれ以下にマウントされるので読み替えること。
/run/media/username/uboot
/run/media/username/__
BBB用のu-bootを、u-bootパーティションへコピーする。
# cp /media/__/usr/share/uboot-beaglebone/* /media/uboot/
# ls /media/uboot/
MLO
u-boot.img
uEnv.txt.beaglebone → uEnv.txt にリネームする
# mv /media/uboot/uEnv.txt.beaglebone /media/uboot/uEnv.txt
とりあえずここまでで起動可能なメディアができあがり。
■sshログインできるようにする
このまま起動しても初期パスワードがわからなくてログインできないので、/etc/shadowを編集する。
くれぐれも母艦側を間違って編集しないよう、フォルダに注意。
マウントされたマイクロSD上のシステムパーティション内の/etc/shadowを、以下のように編集する。
/media/__/etc/shadow を編集
rootのパスワードを以下のように付与。このパスワードは「root」になる。
/media/__/etc/shadow 抜粋
root:$6$lqj7SL8qvAEXeRJX$wX2/cbpgu2wqBRVf3Lnv6IxvZ0DDeIdaRREcbE6mR.l8CtanDDNv9AfN2cpZSaeFmjKQKd4ZY9l4aqEgB9Ceh/:15921:0:99999:7:::
bin:*:15921:0:99999:7:::
daemon:*:15921:0:99999:7:::
・
・
次にselinuxを無効にする。
/media/__/etc/sysconfig/selinux を編集
SELINUX=enforcing → SELINUX=disabled に変更
SELINUXTYPE=targeted
以上でOK。
なお、DHCPで起動してくれるので、システムパーティション内をいじるのは上記2ファイルだけ。
■Fedora20の起動
上記マイクロSDをBBBに挿入し、LANケーブルを接続し、給電開始。
すると電源LED点灯のあと、インジケータLED2つ(USR0,USR1)が点灯。
30秒ほどしてインジケータLEDが消灯。
その後、インジケータLEDは一切点灯しないので注意。
Lチカしないので、てっきりbootに失敗しているかと思うが、待っていればちゃんと起動する。
インジケータLED消灯後、100秒ほどでpingに応答しだす。
DHCPで割り振られたアドレスは調べること。
あとはsshにて、root、パスワードroot、でログインできる。
以上。
なお、/dev/mmcblk0p3(=/)パーティションは、すでに99%使われている。
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p3 3779328 3668304 55580 99% /
devtmpfs 224448 0 224448 0% /dev
tmpfs 253616 0 253616 0% /dev/shm
tmpfs 253616 524 253092 1% /run
tmpfs 253616 0 253616 0% /sys/fs/cgroup
/dev/mmcblk0p1 19474 462 19012 3% /boot/uboot
これでは何もできないので、以下のコマンドで残り領域全体まで
/dev/mmcblk0p3を拡張する。
# resize2fs /dev/mmcblk0p3
resize2fs 1.42.8 (20-Jun-2013)
Filesystem at /dev/mmcblk0p3 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p3 is now 3707825 blocks long.
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mmcblk0p3 14532668 3670200 10807024 26% /
devtmpfs 224448 0 224448 0% /dev
tmpfs 253616 0 253616 0% /dev/shm
tmpfs 253616 524 253092 1% /run
tmpfs 253616 0 253616 0% /sys/fs/cgroup
/dev/mmcblk0p1 19474 462 19012 3% /boot/uboot
以上で完了。
■■■Windows上でのFedora20 OSイメージ作成方法■■■
■用意するもの
・8GB以上のマイクロSDカード (自分は16GBのものを用意)
・Fedora20 のOSイメージ
http://fedoraproject.org/ja/get-fedora#arm
上記ページより、VFAT ARMv7 イメージ をダウンロード。
デスクトップは好みに応じてどれでもよい。
当方はGNOMEにした。
ファイル名:Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz 967MB
・Image Writer for Windows.(SDカードにOSイメージを書き込むツール)
ダウンロード:
http://sourceforge.net/projects/win32diskimager/files/latest/download
・u-boot ファイル
http://rpmfind.net/linux/rpm2html/search.php?query=uboot-beaglebone%28armv7hl-32%29
上記サイトより、
uboot-beaglebone-2013.10-3.fc20.armv7hl.rpmをダウンロード。
■fedora20のイメージをマイクロSD上に展開
ダウンロードした Fedora-Desktop-VFAT-armhfp-20-1-sda.raw.xz を7zip等で解凍。以下が生成される。
Fedora-Desktop-VFAT-armhfp-20-1-sda.raw 約4.6GB
マイクロSD書き込み
マイクロSDをUSBリーダ等でPCに接続し、
Image Writer for Windows.(Win32DiskImager.exe)を起動。
Fedora-Desktop-VFAT-armhfp-20-1-sda.raw とマイクロSDのドライブを選択して書き込み実行。
ファイル選択時、拡張子が.img限定になっているので、*.*を指定すること。

■u-bootの書き込み
まだブートパーティションは空っぽで起動できないので、以下の通りu-bootをブートパーティションにコピーする。
u-bootは、uboot-beaglebone-2013.10-3.fc20.armv7hl.rpm からファイルを取り出す。
rpmの解凍は、XacRettやLhaForge等を利用。以下の3ファイルが取り出せる。
MLO
u-boot.img
uEnv.txt.beaglebone → uEnv.txt にリネームすること
上記3ファイルをマイクロSDのルートにコピー
マイクロSDをセットしたUSBリーダを一度抜き挿しすると、ボリュームラベルが「uboot」の19MBの空メディアに見えるので、その19MBの領域に3ファイルをコピーする。
MLO
u-boot.img
uEnv.txt
とりあえずここまでで起動可能なメディアができあがり。
あとはマイクロSD上のLinuxパーティションを、Ext2Fsd等を利用してマウントし、sshでログインできるようrootのパスワードを書き換える。
パスワードファイル: /etc/shadow
設定するrootのパスワードとfedora20の起動については、上記Linux上での作成方法で示した、sshログインできるようにする 以降を参照。
以上。
2014年01月15日
BeagleBone Black fedora 20 USBを認識しない(解決)
先日、BeagleBone BlackにインストールしたFedora 20。
USBメモリを認識しないので調べてみると、なんとカーネルのバグにより、USBとHDMI出力が機能していないことがわかった。
さらに調べてみると、つい先日(2014-01-13)バグFixされた模様。
https://bugzilla.redhat.com/show_bug.cgi?id=1012025
というわけで早速カーネルのアップデートを実施した。
yumにてアップデートできる。
完了したら再起動。
再起動後、カーネルのバージョン確認。
このアップデートにより、USBメモリは無事認識されるようになった。
USBメモリを認識しないので調べてみると、なんとカーネルのバグにより、USBとHDMI出力が機能していないことがわかった。
さらに調べてみると、つい先日(2014-01-13)バグFixされた模様。
https://bugzilla.redhat.com/show_bug.cgi?id=1012025
というわけで早速カーネルのアップデートを実施した。
yumにてアップデートできる。
# yum update kernelけっこう時間がかかる。計ってなかったが15分くらいと思う。
完了したら再起動。
再起動後、カーネルのバージョン確認。
# uname -a
Linux bbb 3.12.7-300.fc20.armv7hl #1 SMP Fri Jan 10 16:36:34 UTC 2014 armv7l armv7l armv7l GNU/Linux
このアップデートにより、USBメモリは無事認識されるようになった。
2014年01月16日
BeagleBone Black fedora 20 sshdポート変更
fedora20の導入についてはこちらを参照。
sshdのポート変更なんて、/etc/ssh/sshd_config 内のポート番号を変更するだけの話なんだけど、なぜか接続が拒否される。
原因はfirewalld がデフォルトで有効になっているため。
セットアップ中はfirewallなんて邪魔なだけなので無効化する。
以上。
sshdのポート変更なんて、/etc/ssh/sshd_config 内のポート番号を変更するだけの話なんだけど、なぜか接続が拒否される。
原因はfirewalld がデフォルトで有効になっているため。
セットアップ中はfirewallなんて邪魔なだけなので無効化する。
firewalldの停止
# systemctl stop firewalld.service
サービス起動の無効化
# systemctl disable firewalld.service
以上。
2014年01月26日
BeagleBone Black fedora20 デフォルトrunlevelを変更する
fedora20の導入についてはこちらを参照。
fedora20が起動した際、runlevelは5で立ち上がってくる。
デスクトップを使わないのであれば、runlevelは3で運用する。
現在のrunlevelは以下のコマンドで確認できる。
runlevelの変更は /etc/inittab で設定するので、/etc/inittab を編集しようと開いてみると、どうも違うらしい。
またここでもRedHat ES4当時からシステムの設定方法が変わってやがる。
ヽ(*`ε´*)ノ
/etc/inittab の内容を見ると以下の通り。
これによると、/etc/systemd/system/default.target からシンボリックリンクを張れ、とあるので、以下の通り設定を行う。
runlevel 3 にする場合
runlevel 5 にする場合
設定後、再起動すると、設定したrunlevelで立ち上がる。
runlevel 3にするとrunlevel 5より100MB以上メモリを節約できる。
メインメモリは512MBしかないのでこの差はけっこう大きい。
fedora20が起動した際、runlevelは5で立ち上がってくる。
デスクトップを使わないのであれば、runlevelは3で運用する。
現在のrunlevelは以下のコマンドで確認できる。
# runlevel
N 5
runlevelの変更は /etc/inittab で設定するので、/etc/inittab を編集しようと開いてみると、どうも違うらしい。
またここでもRedHat ES4当時からシステムの設定方法が変わってやがる。
ヽ(*`ε´*)ノ
/etc/inittab の内容を見ると以下の通り。
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /etc/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To set a default target, run:
#
# ln -sf /lib/systemd/system/<target name>.target /etc/systemd/system/default.target
これによると、/etc/systemd/system/default.target からシンボリックリンクを張れ、とあるので、以下の通り設定を行う。
runlevel 3 にする場合
# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
runlevel 5 にする場合
# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
設定後、再起動すると、設定したrunlevelで立ち上がる。
runlevel 3にするとrunlevel 5より100MB以上メモリを節約できる。
メインメモリは512MBしかないのでこの差はけっこう大きい。
2014年02月17日
Fedora20 リモートデスクトップまとめ(XDMCP & VNC)
BegleBone Black にインストールしたFedora20のデスクトップをリモート表示する。Fedora20のインストールはこちら。
デスクトップのリモート表示は、XDMCP接続と、VNC接続(2通り)の計3通りあるので、それぞれの方法についてまとめた。
ちなみに、インストールしたFedora20は、GNOMEデスクトップ版だったんだけど、どうしてもGNOMEのデスクトップをリモート表示できなかったので、後からXfceデスクトップをインストールした。
BegleBone BlackのFedora20 GNOMEのデスクトップをリモート表示できた方いましたら、教えていただけると幸いです。。。
本記事内の構成
・前準備(XDMCP、VNC共通)
・XDMCP接続するための設定
・VNC接続するための設定 その1(マルチユーザ対応)
・VNC接続するための設定 その2(シングルユーザ対応)
・各接続方法に関する考察
前準備(XDMCP、VNC共通)
■Xfceデスクトップのインストール
■gdmサービス無効化
■lightdmサービス有効化
■操作をする側(Windows側)の準備
XDMCP用には、適当なX接続ツールを用意。
当方はASTEC-X(有償)を用意。
http://www.astec-x.com/
VNC用には、UltraVNC Viewer (v1.1.9.3)を用意。
http://www.forest.impress.co.jp/library/software/ultravnc/
XDMCP接続するための設定
■lightdmの設定
/etc/lightdm/lightdm.conf の追加箇所
lightdmの再起動
■ASTEC-XによるXDMCP接続
ASTEC-Xの設定は以下のXDMCPの箇所だけ。

接続するとlightdmのログイン画面が表示される。

右上のリストボックスで、GNOMEかXfceを選択できるので、Xfceを選択してログイン。
ログイン後、こんな感じでXDMCP接続でのデスクトップを利用可能。

使用感はというと、もっさりすぎて全く実用に耐えまへん。
とりあえず接続できて満足して終わり、と言った感じですw
ASTEC-Xを終了させると、デスクトップ上のプロセスも全て終了する。
VNC接続するための設定 その1(マルチユーザ対応)
■lightdmの設定
/etc/lightdm/lightdm.conf の追加箇所
lightdmの再起動
ここでUltraVNC Viewerにて接続するわけだが、この状態で接続しても、UltraVNCがパスワードを要求してきて接続できない。
さらにこのパスワードを設定する方法をあれこれ調べてみたがよくわからない。
結局、先人様のサイトを参考に、VNC接続時に呼び出される/usr/bin/Xvnc をラップして、パスワードを訊かせないようにすることで対処。
パスワードを訊いてこないように/usr/bin/Xvncをラップ
■UltraVNC ViewerによるVNC接続
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

接続するとlightdmのログイン画面が表示される。

右上のリストボックスで、GNOMEかXfceを選択できるので、Xfceを選択してログイン。
ログイン後、こんな感じでVNC接続でのデスクトップを利用可能。

使用感はというと、こちらももっさりすぎて全く実用に耐えまへん。
XDMCPよりは軽いけど、実用に耐えない点では同じ。
XDMCPと同様、とりあえず接続できて満足して終わり、と言った感じですw
ちなみに、XDMCPより50MBほど多くメモリを消費してます。(BeagleBone Black上)
UltraVNC Viewerを終了させると、デスクトップ上のプロセスも全て終了する。
VNC接続するための設定 その2(シングルユーザ対応)
その2では、セッション断後もデスクトップは保持され続けるようにするための設定。
■X11vncのインストール
任意のユーザアカウントにて、Xfce用の.xinitrcを作成
同ユーザにてstartx
さらに同ユーザにてx11vncを起動する。
この状態で、Windowsより UltraVNC Viewer にて接続する。
■UltraVNC ViewerによるVNC接続
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

接続すると、startx を実行したユーザでログインした状態となる。

使用感はVNCその1と同じ。
なお、この接続の場合、パスワードなしで接続できてしまうが、UltraVNCにてパスワードを利かせるようにするには、過去記事を参照。
本接続の場合、UltraVNC Viewerを終了させても、デスクトップ上のプロセスは残ったままとなる。
以上。
各接続方法に関する考察
今回試した接続方法は以下の3つ。
(1).XDMCP接続
(2).VNC接続その1(Xvnc)
(3).VNC接続その2(X11vnc)
それぞれ一長一短があり、まとめると以下の通り。
(1).XDMCP接続
マルチユーザ、超もっさり、メモリ小、セッション断でデスクトップ消滅
(2).VNC接続その1(Xvnc)
マルチユーザ、もっさり、メモリ大、セッション断でデスクトップ消滅
(3).VNC接続その2(X11vnc)
シングルユーザ、もっさり、メモリ大、セッション断でもデスクトップは維持
以上、リソースを抑えたい場合は「XDMCP接続」、セッション断後もデスクトップで処理を継続させたい場合は、「X11vnc接続」といった感じだろうか。
あと「X11vnc接続」は、以前のデスクトップが継続しているので、再接続時のデスクトップ形成は圧倒的に早い。
ただ、いずれも、もっさりすぎて常用には耐えない。
一時的な設定にGUIを使いたいだけであればどの方式でもいいし、デスクトップに常駐が必要なもの(wine経由のアプリ等)であれば、「X11vnc接続」という使い分けだろう。
デスクトップのリモート表示は、XDMCP接続と、VNC接続(2通り)の計3通りあるので、それぞれの方法についてまとめた。
ちなみに、インストールしたFedora20は、GNOMEデスクトップ版だったんだけど、どうしてもGNOMEのデスクトップをリモート表示できなかったので、後からXfceデスクトップをインストールした。
BegleBone BlackのFedora20 GNOMEのデスクトップをリモート表示できた方いましたら、教えていただけると幸いです。。。
本記事内の構成
・前準備(XDMCP、VNC共通)
・XDMCP接続するための設定
・VNC接続するための設定 その1(マルチユーザ対応)
・VNC接続するための設定 その2(シングルユーザ対応)
・各接続方法に関する考察
前準備(XDMCP、VNC共通)
■Xfceデスクトップのインストール
# yum -y groupinstall "XFCE Desktop"いっしょにlightdmもインストールされる。
■gdmサービス無効化
# systemctl stop gdm.service
# systemctl disable gdm.service
■lightdmサービス有効化
# systemctl enable lightdm.service
# systemctl start lightdm.service
■操作をする側(Windows側)の準備
XDMCP用には、適当なX接続ツールを用意。
当方はASTEC-X(有償)を用意。
http://www.astec-x.com/
VNC用には、UltraVNC Viewer (v1.1.9.3)を用意。
http://www.forest.impress.co.jp/library/software/ultravnc/
XDMCP接続するための設定
■lightdmの設定
/etc/lightdm/lightdm.conf の追加箇所
[SeatDefaults]
xserver-allow-tcp=true
[XDMCPServer]
enabled=true
port=177
lightdmの再起動
# systemctl restart lightdm.service
■ASTEC-XによるXDMCP接続
ASTEC-Xの設定は以下のXDMCPの箇所だけ。

接続するとlightdmのログイン画面が表示される。

右上のリストボックスで、GNOMEかXfceを選択できるので、Xfceを選択してログイン。
ログイン後、こんな感じでXDMCP接続でのデスクトップを利用可能。

使用感はというと、もっさりすぎて全く実用に耐えまへん。
とりあえず接続できて満足して終わり、と言った感じですw
ASTEC-Xを終了させると、デスクトップ上のプロセスも全て終了する。
VNC接続するための設定 その1(マルチユーザ対応)
■lightdmの設定
/etc/lightdm/lightdm.conf の追加箇所
[LightDM]
start-default-seat=false
[VNCServer]
enabled=true
command=Xvnc
port=5900
width=1024
height=768
depth=24
lightdmの再起動
# systemctl restart lightdm.service
ここでUltraVNC Viewerにて接続するわけだが、この状態で接続しても、UltraVNCがパスワードを要求してきて接続できない。
さらにこのパスワードを設定する方法をあれこれ調べてみたがよくわからない。
結局、先人様のサイトを参考に、VNC接続時に呼び出される/usr/bin/Xvnc をラップして、パスワードを訊かせないようにすることで対処。
パスワードを訊いてこないように/usr/bin/Xvncをラップ
# mv /usr/bin/Xvnc /usr/bin/Xvnc.bin参考サイト:http://so-young-aws.blog.so-net.ne.jp/2014-01-18
# echo exec /usr/bin/Xvnc.bin $@ -SecurityTypes none > /usr/bin/Xvnc
# chmod ogu+x /usr/bin/Xvnc
■UltraVNC ViewerによるVNC接続
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

接続するとlightdmのログイン画面が表示される。

右上のリストボックスで、GNOMEかXfceを選択できるので、Xfceを選択してログイン。
ログイン後、こんな感じでVNC接続でのデスクトップを利用可能。

使用感はというと、こちらももっさりすぎて全く実用に耐えまへん。
XDMCPよりは軽いけど、実用に耐えない点では同じ。
XDMCPと同様、とりあえず接続できて満足して終わり、と言った感じですw
ちなみに、XDMCPより50MBほど多くメモリを消費してます。(BeagleBone Black上)
UltraVNC Viewerを終了させると、デスクトップ上のプロセスも全て終了する。
VNC接続するための設定 その2(シングルユーザ対応)
その2では、セッション断後もデスクトップは保持され続けるようにするための設定。
■X11vncのインストール
# yum -y install x11vnc
任意のユーザアカウントにて、Xfce用の.xinitrcを作成
$ echo exec /usr/bin/xfce4-session > ~/.xinitrc
同ユーザにてstartx
$ startx &
さらに同ユーザにてx11vncを起動する。
$ x11vnc -display :0 -forever &
この状態で、Windowsより UltraVNC Viewer にて接続する。
■UltraVNC ViewerによるVNC接続
UltraVNC Viewerを起動し、VNC Server 欄に、host:display の形式で以下のように記述。

接続すると、startx を実行したユーザでログインした状態となる。

使用感はVNCその1と同じ。
なお、この接続の場合、パスワードなしで接続できてしまうが、UltraVNCにてパスワードを利かせるようにするには、過去記事を参照。
本接続の場合、UltraVNC Viewerを終了させても、デスクトップ上のプロセスは残ったままとなる。
以上。
各接続方法に関する考察
今回試した接続方法は以下の3つ。
(1).XDMCP接続
(2).VNC接続その1(Xvnc)
(3).VNC接続その2(X11vnc)
それぞれ一長一短があり、まとめると以下の通り。
(1).XDMCP接続
マルチユーザ、超もっさり、メモリ小、セッション断でデスクトップ消滅
(2).VNC接続その1(Xvnc)
マルチユーザ、もっさり、メモリ大、セッション断でデスクトップ消滅
(3).VNC接続その2(X11vnc)
シングルユーザ、もっさり、メモリ大、セッション断でもデスクトップは維持
以上、リソースを抑えたい場合は「XDMCP接続」、セッション断後もデスクトップで処理を継続させたい場合は、「X11vnc接続」といった感じだろうか。
あと「X11vnc接続」は、以前のデスクトップが継続しているので、再接続時のデスクトップ形成は圧倒的に早い。
ただ、いずれも、もっさりすぎて常用には耐えない。
一時的な設定にGUIを使いたいだけであればどの方式でもいいし、デスクトップに常駐が必要なもの(wine経由のアプリ等)であれば、「X11vnc接続」という使い分けだろう。
2014年04月13日
fedora20のOpenSSLをアップデート
OpenSSLが大変なことになっているようだ。
http://www.jpcert.or.jp/at/2014/at140013.html
脆弱性が指摘されているOpenSSLのバージョンは以下の通り。
- OpenSSL 1.0.1 から 1.0.1f
- OpenSSL 1.0.2-beta から 1.0.2-beta1
自分はあまり関係ないけど、とりあえずOpenSSLをアップデートしておく。
Fedora20 armのOpenSSLのバージョンは以下の通り。
というわけでアップデート実施。
アップデートしてもバージョンは変わらずなので、built on:の日付で確認。
2014/4/7 以前ではないのでOK。
以上で完了。
関連情報
https://library.linode.com/security/openssl-heartbleed
http://www.jpcert.or.jp/at/2014/at140013.html
脆弱性が指摘されているOpenSSLのバージョンは以下の通り。
- OpenSSL 1.0.1 から 1.0.1f
- OpenSSL 1.0.2-beta から 1.0.2-beta1
自分はあまり関係ないけど、とりあえずOpenSSLをアップデートしておく。
Fedora20 armのOpenSSLのバージョンは以下の通り。
[root@bbb ~]# openssl version -a1.0.1eなので、見事に脆弱性持ちのバージョンですね。
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Jan 7 14:50:25 UTC 2014
というわけでアップデート実施。
[root@bbb ~]# yum -y install openssl
[root@bbb ~]# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr 8 00:35:57 UTC 2014
アップデートしてもバージョンは変わらずなので、built on:の日付で確認。
2014/4/7 以前ではないのでOK。
以上で完了。
関連情報
https://library.linode.com/security/openssl-heartbleed

