投稿

3月, 2019の投稿を表示しています

ミラーレス一眼カメラを LAN に接続 ~ Raspberry Pi で作った NAPT ルーター経由

イメージ
先日購入したミラーレス一眼カメラである OLYMPUS OM-D E-M10 III の Wi-Fi 機能を使って、Raspberry Pi 3B+ で作った NAPT ルーター経由で LAN に接続したよ、って話です。思い付きでやってみた感じで、設定も比較的単純な内容なのですが、他に記事になっているようなものを見かけなかったことと、やってみて、思ったように出来たこと、出来なかったことがありますので、まとめてみたいと思います。 プロジェクトの概要 ミラーレス一眼カメラでも、最近の上位機種は、LAN ポートを持っていたりして、直接ネットワークに接続できるものもあるようです。ですが、私の持っているものも含めて、現状の多くのカメラの場合、Wi-Fi 機能があると言っても、大抵は次のような使い方を想定したものであるようです。 カメラ側が Wi-Fi アクセスポイントとして機能するため、そこに接続するスマートフォンなどは、既存のインターネットなどの接続を切断した上で、新たに接続し直す必要があります。カメラがネットワークに組み込まれるわけではなく、Wi-Fi という形を取りながらも、ピア・トゥ・ピアでの接続となります。 屋外で使う前提でいくとこの形がいいのはわからなくもないのですが、既に LAN が導入され、Wi-Fi が飛び交っているような屋内で使おうとすると、手間ばかりかかります。他の PC などでも使おうとした場合、それぞれに接続し直さなきゃいけないし、デスクトップ PC などの場合は、そもそも Wi-Fi インタフェースを持っていない場合も多いし。ノート PC などで、Wi-Fi を使っていたとしても、既存の LAN やインターネットの接続を切ってつなぎ直さなきゃなきゃならないというのは、NAS などへのアクセスもできなくなることを意味するので、たとえば、カメラから取り込んだデータを NAS に保存したい場合などだと、作業に制限が出てしまいます。 というわけで、次の図みたいにできたら、便利なんじゃないかなー、という思い付きです。調査してみたところ、カメラとスマートフォンの間の通信プロトコルは、HTTP だということも判明したので、もしかしたら WebDAV が使えるのではないか、と期待してテストはしてみたのですが、そ

micro SD カードが 2 枚たて続けにご臨終 (-.-)

イメージ
どちらも 2 年位前に使いだしたもので、酷使したあとなんですけどね。ここにきていきなり 2 枚です。改めて、寿命が存在するのだと認識した次第です。 寿命かなぁ … とは思ったものの、その時点で調べたわけではないので、ツールを使って確認してみました。使用したツールは、 Check Flash というもの。 1 枚目 …。 最初に、読み取りだけのテストをしたんですが、そこではエラーにならず。CRC の整合性をチェックしているみたいなんですが、そこは大丈夫だったようです。で、読み書きのテストをしたら、いきなりエラーでした。壊れた部分が偏っているのかどうかとか、気になったので、一応、書き込みの最後まで回したのですが、全面エラーでした(赤い部分)。続いて、最初に戻って読み取りを行うみたいなんですが、当然ながら、エラー(黄色い部分)なんで、打ち切りました。… 残り時間の表示が 8 時間を超えているので。 2 枚目 …。 こちらも、冒頭からエラーです。ダメですねぇ。 なんか、問題なのは、同時期に買って使いだした micro SD が、まだ、他にあるってことなんですよ。いざって時に、泣きをみないように、準備しておきたいですね。貴重なデータは別の媒体へのバックアップが必須でしょうし、ライブ収録のカメラやレコーダーなどに使うような場合は、定期的に新しいものに取り替えるくらいのつもりの方がいい気がしてきました。 とりあえず、Raspberry Pi のシステム関係は、ちゃんとバックアップを取っています。ユーザーデータの方は、基本、ハードディスクなんで、とりあえず、ここでの心配には当てはまらないですし。ただ、micro SD カードの予備媒体だけは、用意しておかなくちゃね。特に、 最近運用を始めた DNS - DHCP サーバー は、micro SD カードオンリーの運用なんで、どのくらいの負担になっているか、まだ、未知なところもあって、正直、ビクビクはしています。 ま、徹底的に書き込みを減らすような設定も可能なんでしょうけど、期待としてはフラッシュメモリーであってもある程度は耐久性があると思いたいですし、ログを減らしすぎるような設定は、何かあった時に原因究明に手間取るし、そんなところで書き込み減らしても、定期的に行っている OS のバージョン

Raspberry Pi(Model 3B+)の USB ポートの認識順序

イメージ
Raspbian を含めた Linux、Unix 系 OS の場合、デバイス名(/dev/mmcblk0p1 とか /dev/sda2 とかいうやつ)は、システムが、つながれていることを認識した順序で規則に基づいて自動的に割り振るので、起動時につながれている機器構成が変わると、デバイス名も変わってしまいます。これによって、システムが起動しなくなったりするトラブルは広く知られていて、また、そういったトラブルを避ける設定ファイルの書き方なども、広く提唱されています。 Raspbian の場合も、現行の Strech バージョンになってから、以下の箇所でデフォルトの指定方法が変更になっていました。 /boot/cmdline.txt 内の root= の指定 /etc/fstab 内の第 1 フィールド(fs spec) どちらも、PARTUUID を使った指定になっています。PARTUUID っていうのは、本来は GPT パーティションテーブルを持ったブロックデバイス(USB メモリやハードディスクなど)のパーティションに割り振られる ID ですが、従来からの MBR パーティションテーブルを使ったブロックデバイスでも擬似的に生成されるので、使えます。 これ、意図的に変更したりデバイス間でコピーしたりもできるのですが、基本的には一意に割り振られる ID なので、デバイスの指定にこれを使っておけば、システム上の機器構成が変わることにより起動しなくなるようなトラブルを避けることができます。 良いことばかりではない … これで全てがうまくいくのかというと、新たな問題もあります。 PARTUUID っていうのは、ファイルシステムを作り直す、つまり、パーティションをフォーマットすると、変わります。当然ながら、故障して、物理的なデバイスを交換したような場合にも、変わります。先にも申し上げたとおり、PARTUUID 自体は変更できるし、バックアップの作成と復元に dd コマンドを使うような場合には、ディスク内に書き込まれている PARTUUID ごと記録・回復されるので、そのまま使うことはできます。また、たとえ PARTUUID が変わるようなことがあっても、基本的には、先の 2 箇所、/boot/cmdline.txt と /etc/fsta

Raspberry Pi をハードディスクから起動してみた - 安直な発想で(笑)

イメージ
自宅では、6 台目の Raspberry Pi。位置づけは、予備機、兼、テスト機。まぁ、やっと手に入れたお遊びマシーンとも言えます(笑)。 今まで、3 台の Model 3B と 2 台の Model 3B+ を使ってきたわけですが、それぞれ最初から使用目的を定めて導入したものばかりなので、ヘタにいじってトラブると、ネットワークや生活そのものに支障がでる感じで、あまり大胆なことできないし、新たな機能導入にも慎重にならざるを得なかったです。一方で、万が一、ハード的なトラブルが起こった場合のことも心配になってきたので、ストック的な意味も兼ねて、テスト機の導入となりました。 こちらの既製のケースも、初めての購入です。机上で遊び道具になることを、最初から想定していました(笑)。 で、とりあえず、やってみたかったこと … っていうか、浮いたハードディスクドライブがある今しかできないということで、ハードディスクからの起動テストです。ちなみに、このハードディスクドライブは、別途、使用予定が控えてます。ジャンクかなにかで、もっと小容量のお遊び専用ドライブを探してきてもいいんですが、とりあえず、現在、使えるものでということで。 安直な方法その 1 … 配布されているインストールイメージを直接ハードディスクに書き込んでみた Raspberry Pi の公式サイト(Raspbian ダウンロード) からダウンロードした Raspbian Strech with Desktop のインストールイメージですが、普通は、micro SD カードに書き込みますよね。これ、そのままハードディスクに書き込むだけじゃダメなんだろうか? という、率直な疑問から、とりあえず、やってみました。ハードディスクドライブには、SATA - USB の変換ケーブルを付けてあるので、基本的に、やろうとしていることは、micro SD カードに USB の変換アダプターを付けたのと、同じです。 ただ、普通、これ、PC から書き込むことが多いかと思うのですが、Windows PC の場合、誤操作防止を考えているのかなにか、直接、ハードディスクにインストールイメージを書き込めるアプリケーションソフトが見つからなかった、というか、探すのも面倒くさかったので、別の Raspberry Pi マシー

Raspberry Pi Model 3B で DNS - そのパフォーマンス

イメージ
ご存知の方も多いと思うのですが、DNS というのは、Domain Name System のことです。ま、これが何だって言うと、意外と機能の一部分しか語られていなかったりして、その全体像を説明した文章が少ないような気はするのですが、 Wikipedia(DNS) によれば、1983 に開発されたらしいです。 BIND っていうのは、DNS を管理する DNS Server の実装の 1 つで、こちらも Wikipedia(BIND) によれば、1988 年に書かれたものらしい。 DNS & BIND の教科書といえば、これ。 奥付。 古過ぎ(笑)。 まぁ、今は BIND もバージョンが 9 になって、機能も追加・変更されているけど、基本は、30 年も前から動いていたシステムだってことです。30 年も前だよー。当時のコンピュータの性能や、ネットワークの帯域を考えたら、今の Raspberry Pi でも、余裕で動くような気がするでしょ。 ちなみに、DNS Server の機能は、光回線のゲートウェーになっている機器、ブロードバンドルーターなども持っていることが多いです。家では、ドコモ光(実質は NTT 西日本のフレッツ光)を引いていますが、設置されている PR-500MI にも、簡易的ながら、その機能があります。では、なんでそれを使わないで、わざわざ別に立てるのかと言えば、大きな理由は、LAN 内のアドレスの管理のしやすさと、今後の拡張性です。 そこで、今までは NAS に使っている Raspberry Pi Model 3B に BIND を同居させて使っていたのですが、 LAN 内を管理する DNS サーバーとしては、1 台しかなかった。 他の機能と同一ハード上に同居させているため、メンテナンスなどで停止させることがある。 という理由で、クライアントマシンからの検索要求は、一度、全て PR-500MI の方に投げ、そこから、LAN 内のものは Raspberry Pi の方に振り分ける設定にしていました。Raspberry Pi の方を停止させた時に、Web 上の資料を参照できなくなるというのは、メンテナンスに支障が出る可能性があると考えたからです。 今回、NAS に使っているマシンを Raspberry

ブロガーにツイッターカードをセットアップ(Set my Blogger up for the Twitter Cards)

イメージ
Web 検索すると、結構、複雑なことしなきゃならないようなことを書いてある記事が目につくのですが、現時点、実際にやってみたところ、以下の方法で 1 行追加しておくだけで、過去の記事も含めて、全て有効になるようです。それぞれの記事のタイトルと冒頭の内容も引用されますし、写真も表示されます。ツイッター側の仕様が変更されているのかもしれませんね。 まずは仕様の確認 ツイッター側の仕様は、 こちらのページ(英語) にありました。カードのタイプの指定だけは必要なようですが、その他のプロパティは、全て No Required になっています。もちろん、設定することによるメリットもあるかとは思うのですが、とりあえず、表示するだけなら、1 行で済むということだと思います。あとは、実際の表示を見ながら、必要だと思うものを追加すればいいということになると思います。 ブロガーのどこに追加するか ブロッガーのどこに設定するのがいいかと検討したのですが、「テーマ」の「HTML の編集」で表示される部分がいいようでした。 上の赤く囲った部分です。 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html> <html b:version='2' class='v2' expr:dir='data:blog.languageDirection' expr:lang='data:blog.locale' xmlns='http://www.w3.org/1999/xhtml' xmlns:b='http://www.google.com/2005/gml/b' xmlns:data='http://www.google.com/2005/gml/data' xmlns:expr='http://www.google.com/2005/gml/expr'>   <head>    <meta content='summary' name='twitter:card

NAS に使っている Raspberry Pi Model 3B を 3B+ に換えたら … 驚きのパフォーマンスアップ!

イメージ
先日のブログ で少し書いたのですが、元々、NAS に使っていた Raspberry Pi Model 3B を 3B+ に換装したお話です。元は、OS として、Raspbian Jessie Lite を使っていたのですが、この micro SD カードを、単純に 3B+ の方に差し替えてみたところ、起動しなかったというところで、計画変更。原因を追求すれば、起動できた可能性はあるかと思うのですが、そんなことするより、3B+ と Raspbian Strech Lite で一から組んじゃった方がいい、ってことで、ササッと作ってしまいました。 Raspbian の設定は以前よりかなり進化している いや、たしか、Jessie で NAS を組んだときは、NFS や Samba の設定自体はわりとスムーズにできたものの、SYSTEMCTL がまだ未熟で、なんか、起動プロセスでトラブった記憶が …。今回使った Strech は、ホント、スムーズでした。NFS や Samba も、インストールするだけで、自動起動まで設定されます。他にやったのは、設定ファイルに、必要な設定を書き込むだけ。難しいことやっているわけではないので、数行の書き込みで終わった感じです。 パフォーマンス比較です で、試しに、3B+ の方で設定済の Strech の入った micro SD カードを、逆に 3B の方に戻してみたら、全く問題なく起動できたので、同条件で 3B と 3B+ の比較ができる環境ができました。 組んだ NAS の概要です。 本体: Raspberry Pi Model 3B Raspberry Pi Model 3B+ OS: Raspbian Strech Lite プロトコル: NFS SMB(Samba・今回の比較テストはこちら) ストレージ: 32GBytes micro SD カード Class 10 3TBytes ハードディスクドライブ(Western Digital の Blue) × 2 mdadm を用いて RAID1 に構成 SATA - USB 変換ケーブルを使用 ファイルシステムは ext4 /home、/var は、ハードディスクの方に移動 ハードディスク上にネットワーク共有ディレ

Raspberry Pi Model 3B を 3B+ に換装 - Raspbian Stretch with desktop 編

イメージ
いや、本当のこと言えば、予定変更でこうなりました。本当は、1 つ前の OS バージョンである Raspbian Jessie Lite で組んである NAS に使っている Model 3B を 3B+ に換装しようとしたんですが、そのままでは、起動しませんでした。こちらの NAS の方も、最新の Raspbian Strach にバージョンアップするつもりではあるのですが、バージョンアップ作業をする前に、NAS と同居している DNS その他諸々の機能を、別のハード … 換装して外した方の Model 3B を使うつもりだった … に避けちゃってから、Raspbian Strech Lite を使って、純粋に NAS の機能だけを再構築する予定でした。そのためには、先に Model 3B を余らせなきゃいけないわけですが、NAS のハードを単純に換装することはできないみたいだったので、予定が狂った感じです。で、 先日の記事 で書いたデスクトップマシンの方を先に換装することになりました。 Raspbian Strach with Desktop は設定変更なしでそのまま起動 こっちもダメかなぁ … なんてびくびくしていたら … 結論を先に言ってしまえば、何の変更もなくあっさり起動。ただ、当然なんですが、別途購入した動画デコードのハードウェアアクセラレーションのためのライセンスキーは、Soc のシリアルナンバーが変更になったので、そのままじゃ使えません。ま、予定はしていたのですが。それ以外は、問題なく動いています。気分的な問題かもしれないですが、ちょっと軽快になったかなぁ …。 左が Model 3B、右が 3B+ です。よく見ると、かなり変更されています。 裏側。想像していたより、違いが大きいです。 持っていた 3B は日本製。 今回、購入した 3B+ は、英国製です。 換装・組み付け そうそう、このマシン、昨年夏の暑さで、画面隅に温度計マークが表示されたことがしばしばと。ちょっと過熱ぎみでした。これを機会に、ヒートシンクもセットで購入したので、取り付けました。 ヒートシンクもだったのですが、そもそも、上に Pi HAT 仕様のサウンドカード乗っかっていたもので、CPU 周りの風通しが悪

ジェルボール(洗剤)

イメージ
切替時には悩んだのですが、しばらく使い続けてみました。ちなみに、以前、使っていたものは、こちら。 まぁ、なんだかんだ言っても、手間がかからず、楽です。以前は、3 種類、それぞれ計量して入れてたわけですから。詰め替え用の中身を買ってきたときなんか、特に面倒くさかった。気をつけていても、ベタベタしてくるしね。 洗剤の価格だけで比べると、割高って印象もあったのですが、とりあえず、日常的には、漂白剤も柔軟仕上げ剤も使うのをやめて、ジェルボール 1 個にしちゃいました。意外と、安上がりかな。まぁ、今は冬で、汗もあまりかかないし、日々洗っているのは、あまり汚れのひどいものじゃないですしね。暑くなって汗をかくようになったり、汚れのひどいものが出た場合は、また、対応を考えるかもしれないですけど。柔軟仕上げ剤を止めてどうなのかというと、まぁ、ふわふわとは言えないかもはしれないのですが、おそらく、液体(ジェル状?)の洗剤で柔軟仕上げ剤なしの場合よりは、柔らかく仕上がっていると思います。液性が中性なのもあるのかなぁ。個人的には、この程度で OK です。静電気防止の面でも、そう、変わった感じなし。ま、タオルケットみたいに、特別柔らかく仕上げたいものを洗うときは、別途、柔軟仕上げ剤を使えばいいかもしれないですしね。乾いた後にも、それなりに香りはあるかなぁ。強すぎないで、いい感じです。 ジェルボールって言うわけですが、3 部屋に別れたフィルム状の袋の中に、それぞれ液体に近い状態のものが封入されている形です。「ジェル」って、本当はコロイドのうち、流動しない状態のものを指す用語で、流動する状態のものは「ゾル」って言うんですけどね(笑)。 え、流動しないものは、「ジェル」じゃなくて「ゲル」だって? それ、輸入元の言語が違うだけで、元は同じ物でしょ。「gel」です。 裏から見ると、こんな感じ。 仕事に出ちゃうもので、日常的には、部屋干しが多いです。大きなものや、厚手のものとかは、休みの日などに洗って、ベランダに干しています。

モニターアーム

イメージ
以前にも書いたことがある DTM 用のモニターに、モニターアームを付けました。 グリーンハウス  GH-AMCA02 Amazon から購入。こんな感じでとどきました。 このまま(笑)。別の箱に入れられていないのもそうなんですが、この箱、テープ止めもされておらず、開口は折り曲げて差し込まれただけの状態。運送屋さんって、簡単に開け閉めできるような包装だと、受け付けてくれないことが多いと思うんですが、今回は、この状態のまま、宛名シール(青く塗りつぶした部分)が貼られて、届きました。 ま、中身は特に問題はなく、きちんと入っていました。組み立ても難しいことはなく、設置。 ただ、使っていたディスプレーポート用のケーブルの長さが足りない。きちんとアームに収納できるようになっているんですが、長さが足りないので、とりあえず、バラバラしております。なんか、Amazon のサイトの写真だと、素材感とかわかりづらい感じですが、想像していたより、がっしりしている作りです。 こちらの製品にしたのは、値段が手頃な中では、高くまで上がりそうだったからです。 こんな感じで、使わないときに、上の方によけちゃいたいってのが、購入した大きな理由。ただ、譜面台を置いてはみたのですが、とりあえず、オーディオインタフェースやキーボードは、立てかけて避けた状態。ま、これは、譜面台にちょっとゲタを履かせて、置いてあるものやモニターアームの台座をまたげるようにすればいい話なんで、なんか適当に貼り付けようと思います。 台座自体はしっかりしたものなんですが、そこに貼り付けてあったクッションシート(写真の左)が、どことなく頼りない感じ。両面テープで貼り付けてありましたが、剥がしてしまって、転がっていたベニヤ板の切れ端を挟んでおきました。 これ、実用上は問題ないのですが、製品の構造上、モニター位置を低く下げた状態だと、あまり奥に引っ込めることができなくなります。2 本のアームがクロスする形になってしまうからです。あまり奥行のない台に設置したので、モニター位置を後ろの壁近くまで引っ込められた方が便利かと思ったのですが、その場合、こちらの  GH-AMCD01 の方がよかったかもしれないですね。