投稿

ラベル(QNAP)が付いた投稿を表示しています

QNAP NAS の RAID 1 ミラーディスクの追加エラー

イメージ
QNAP の NAS(2 ドライブ)を RAID 1(ミラーリング)で運用している。HDD は WD Red 6TB × 2。この NAS が夏の停電時に、古い方のドライブ 1 の HDD でエラーが発生し、ドライブ 2 のみの片肺運転となっていた。 QNAP の GUI 上で操作しても状況が変化しないので、一旦、ドライブ 1 を取り外し、外付け HDD ケースに入れ、Windows PC に接続し、パーティションを全て削除して、単一パーティションを作り、NTFS で完全フォーマットをし直した(完全フォーマットなので丸一日を要した)。Windows 上で S.M.A.R.T. 情報を見る限り、問題は発生していないようである。 QNAP に HDD を戻したが、個別情報でドライブ 1 はステータス「準備完了」、S.M.A.R.T. 情報「良好」となっているものの、論理ボリューム(RAID 1 のミラーリングディスク)としては追加されずに、エラー(Add drive 1 to the volume failed)となった。 HDD を再度 Windows PC に戻して、Windows 上で パーティションを削除してパーティションが存在しない状態にしてから 、QNAP に HDD を戻した。すると今回は、ミラーリングに追加され、フォーマット処理が無事開始した。 QNAP でミラーリング(フォーマット処理含む)が終了後、S.M.A.R.T. の完全テストも行ったが、何のエラーも検出されなかった。元のエラーは何だったのだろうと思うが、多分、QNAP の OS が馬鹿だっただけだろう。 以上、QNAP に HDD を追加する・し直す場合には、追加する HDD はパーティションを削除した状態で追加しなければならないという話. 余談 1:WD Red WD Red シリーズ は元々は CMR 方式だったのだが、後に RAID に不向きな SMR に変更されてしまった( 参考 )。単に Red だからと安易に信用せず、CMR 方式の型番であることを確認して購入した方がよい。 WD 公式ブログのリスト によると、2TB 〜 6TB の EFAX が SMR なので、買ってはいけない型番。一方、8TB 〜 14TB の EFAX

iTunes と macOS Catalina (10.15) と QNAP の問題

イメージ
これまで長い間 QNAP の NAS と Mac を使っていながら、iTunes を使ったことがなかった。自分が全然 iTunes で音楽を聴くというような行動スタイルがなかったからだ。ところが、家族が Mac で NAS に取り込んだ音楽を聴けるようにする要請があり、今さら、QNAP の NAS を iTunes サーバー化してみようかということになった。 元々、QNAP が iTunes にも対応しているということは管理画面でも知っていたが、調べてみると、 たった 1 ページの説明 で済む簡単な作業のようだった。 ところが、iTunes Server を有効化して、macOS (Catalina) のミュージック.app から QNAP 上の iTunes サーバーが見えるようになるまでは簡単にできたのはいいのだが、NAS 上のアルバムを選択しても、再生ができない。調べてみると、macOS Catalina (10.15) から新しくなったミュージック.app の仕様の変更が原因で、古い DAAP( Digital Audio Access Protocol )に対応しなくなったため(プロトコルのメッセージ中の「:」が「@」に変更されているとか)。原因はそれなのだが、悪いのはむしろ、とっくの昔に開発が停止した古い DAAP 用のサーバーアプリ(Firefly)のままで放置している QNAP の怠慢である(同じ台湾メーカーの Synology も似たりよったりな状況らしい)。Firefly の後継の forked-daapd にとっくの昔にリプレースしておくべき話だという。 Docker で forked-daapd を入れる(Docker) そこでどうにかする方法としてネットに出ているのが、 Docker を使って forked-daapd を入れてしまう という方法。ところが、Docker を入れられないモデルの NAS の場合はどうしようもない! そう、うちの QNAP の NAS、 HS-210 がそうだ。ふざけんな QNAP! macOS Catalina に iTunes.app を入れる(Retroactive) 仕方がないので、以前の iTunes.app を入れることで、当面の時間稼ぎをすることにした。 Retr

QNAP の SSH のアクセス元制限の不完全な仕様

OpenVPN で実家の LAN につなぎ、VPN 経由で NAS(QNAP)にアクセスできるようになったので、ネットワークセキュリティを強化すべく、NAS の SSH にアクセス元制限を付けた。/root/.ssh/authorized_keys の公開鍵リストに、from="(ネットワークアドレス)" のオプション設定を追記したわけだ。 ところで、元々ブリッジモードの VPN 設定だったのを、ルーターモードに変更したため、アクセス元のクライアント機のネットワークアドレス(192.168.11.0/24)は NAS 側のネットワークアドレス(192.168.0.0/24)と異なるものとなった。そのため、from にカンマ(「,」)区切りでネットワークアドレスを列挙する必要がある。 from="192.168.0.0/24,192.168.11.0/24" ssh-rsa AAAAB3N... しかし、どうやら QNAP の SSHd では仕様が不完全なようで、from として列挙したものを与えると、正常に動作しない(すべてのネットワークからアクセスできなくなった。仕方なく、一時的に telnet を使って復旧作業をする羽目になった)。 つまり、authorized_keys の from 設定としては列挙で設定することはできず、一種類の設定しか与えることができないのである。 簡単に思い浮ぶのは、VPN をルーターモードで運用するのをやめて、ブリッジモードに戻すことである。そうすれば、クライアント機のネットワークアドレスは NAS 側のネットワークアドレスと同一なので、from のエントリーは一種類で済む。 それでもせっかくルーターモードにしたのにブリッジに戻すのも何となく嫌だったので、(専門家でもないのに独学でネットワークエンジニアの資格をパスしたという“昔取った杵柄”を活用できたのか)ポク・ポク・ポク・チーンと思い付いたのが、ネットワークアドレスに、192.168.0.0/23 という値を使う方法。 23 ビットというネットマスクを使う奇策 である。この設定は、192.168.0.0 〜 192.168.1.255 の範囲の IP を意味するネットワークアドレスである。 from="192.16

SSH の公開鍵認証+IP制限

過去に NAS(QNAP)の SSH の設定を色々いじっている時にも SSH について触れたこと があったが、その時は rsync の環境を構築しようとしていた記事の中で SSH も含めていたため、なぜ SSH 単独の話題ではなかったのかという事情についてまでは忘れていた。その時の本目的はあくまでも NAS を使ったデータのバックアップ環境の確立だったので、SSH 自体は使っても使わなくてもよかったからだ。 その当時においては、当初、VPN から NAS にアクセスして、NFS を使う方策を試みたが、VPN が PPTP を使ったセキュリティ的に脆弱なものであり、SSH によって rsync ができるようになったので、VPN も NFS も忘れていた。ところが、今現在、OpenVPN でセキュリティ的に十分な環境が整い、Mac から VPN 経由で NAS をクラウド的に利用する方法を模索し始めてみると、Samba よりも NFS の方がちゃんと動くし、Windows 抜きで Mac か Linux かで動かすのだから、よりによって(本来 Windows ちゃんと仲良く戯れるための)Samba など使わないに越したことはないのだ。 ともかく、VPN 前提で考えてみると QNAP の SSH のセキュリティも改めてちゃんと見直したくなり、アクセスを LAN からのアクセスに制限できないかと調べてみると、ちゃんと方法があったので、早速そうした。方法はサーバー(QNAP)側 .ssh/authorized_keys のエントリーに、from="192.168.0.0/24" のような形式のオプションを追加することである。次のような感じで: from="192.168.0.0/24" ssh-rsa AAAAB3...AgRiOf my Ubuntu from="192.168.0.0/24" ssh-rsa AAAAB3...v17zrd my Macbook こうすることで、SSH は LAN 内からの接続しか受け付けなくなった。 注 1: VPN 経由での接続 OpenVPN を使ってアクセスする際、ssh admin@192.168.0.1 のように、IP アドレスで NAS にアクセス

QNAP で仮想ホスト運用を断念

実家の QNAP NAS の貧弱な性能では、CGI が使い物にならず、Web サーバーは結局、さくらインターネットでマルチドメインを運用することを廃止できないという結論に達した。その上、StartSSL が使い物にならなくなってしまったため、Let's Encrypt に移行したのだが、その機会に、QNAP のポートの割り当ても、デフォルトに戻した。つまり、Web UI 用に、80 (HTTP) と 443 (HTTPS) を割り当て、仮想ホストに 8080 (HTTP) と 8081 (HTTPS) という形である。index.php も元のものにした。 XXX.myqnapcloud.com 用のセキュリティ証明書だけ、Let's Encrypt で用意し、Web UI に HTTPS でアクセスしても証明書エラーが出ないようにしておいた。

QNAP の Web UI にログイン不可能になった場合の対処法

仮想ホストの HTTPS や証明書の設定をしていた時、何かの拍子、というか XXX.myqnapcloud.com の証明書の設定をリセットした拍子に、Web UI にログインできなくなり、困った状態になった。延々と Web 画面がリダイレクトされるループ状態になってしまう。 原因は、デフォルトでは、Web UI の HTTP ポートが 80、HTTPS ポートが 443 で、仮想ホストの Web サーバーの HTTP ポートが 8080、HTTPS ポートが 8081 のところを、Web UI と仮想ホストで入れ替えて、Web UI が HTTP(8080)と HTTPS(8081)、仮想ホストが HTTP(80)と HTTPS(443)にしていた。さらに、Web UI を HTTPS のみでログインできるようにして、HTTP ではログインできないようにしていた。ポート設定が、証明書のリセットのタイミングで Web UI のポート設定がデフォルトに戻り、HTTP はログインを拒絶して HTTPS にリダイレクトするのだが、リダイレクト先が間違っており、仮想ホストの無効なポートへのアクセスとして処理されて Web UI の HTTP へとリダイレクトを戻す、というループに陥ってしまったようだ。 最悪、NAS の設定をリセットして再起動すればいいわけだが、SSH によるログインはまだできる状態だったので、リセットが避けられればそれに越したことはない。情報を検索すると、 QNAP のフォーラム にまさしく同じ状況に陥っている人がいて、達人の pwilson さんが対処法を回答していた。お蔭様で、設定リセットすることなく、復帰することができた。 pwilson さんは一連のコマンドをアドバイスしてくれているが、僕のケースでは、HTTP でのログインさえ再び有効化すればよかったので、SSH で、 setcfg System 'Force SSL' '0' /etc/init.d/Qthttpd.sh restart /etc/init.d/stunnel.sh restart だけ実行して、HTTP でのログインを有効にして、あとは、HTTPd と stunnel を再起動するだけで十分だった。 それで Web UI にログイン

SSLLabs のテストで A 評価を得る

イメージ
中間証明書の問題はクリアしても、 SSLLabs のテスト は、RC4 を使っているせいで B 評価となる。ところが、myqnapcloud の方は A 評価なのに気付いた。 これもおそらく、QNAP の中の人が、仮想ホストでの使い勝手を考慮していないためだろう。 myqnapcloud の設定は、/etc/config/apache/extra/apache-ssl.conf ではないかと推測し、その SSLCipherSuite の設定を /etc/config/apache/extra/httpd-ssl-vhosts-user.conf に移植してみた: - SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!SSLv2:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM + SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL

QNAP の仮想ホストで SNI

昨日はどうにか仮想ホストでちゃんと中間証明書を有効にする方法を確立した。さらに一日経って、頭が整理できて、全体的により洗練されたやり方に行き着くことができた。昨日の成功をベースにして SNI(仮想ホストのそれぞれで別々の証明書を使い分けること)も余裕でできることがわかったので、それも含めて、全体を整理し、洗練したやり方になったので、それをまとめておこうと思う。 Web サーバーのポートの設定 Web UI 用のポートは「システム設定 > 一般設定 > システム管理」で 8080(HTTP)と 8081(HTTPS)に設定した。さらに、「HTTPS のみを使用する」設定にした。 Web サーバーのポートは「Webサーバ > Webサーバ」で 80(HTTP)と 443(HTTPS)に設定した。さらに仮想ホストの設定で、 443(HTTPS)の設定の仮想ホストだけをエントリーした。 StartSSL での証明書の取得 StartSSL で、仮想ホストそれぞれの証明書と、XXX.myqnapcloud.com 用の証明書もついでに取得する。これらの中間証明書はすべて共通(StartSSL)の中間サーバーのものとなるので、中間証明書は別々に用意しなくてもいいのが洗練されたやり方となるポイント。 それぞれの Web サイト認証は、「Website Control Validation」のリンクをクリックして、認証用の HTML をダウンロードし、ウェブサイトのルートに設置してから、認証ボタンを押して、認証を成功させることができる(認証後は、認証用 HTML を削除して構わない)。ちなみに、XXX.myqnapcloud.com のルートは、/share/Web そのものである。 XXX.myqnapcloud.com 用の証明書の設定 XXX.myqnapcloud.com(Web UI)用の証明書は、Web UI から「システム設定 > セキュリティ > 証明書とプライベートキー」で行える。StartSSL からダウンロードした zip の中の さらに ApacheSever.zip の中の 2_XXX.crt を証明書としてアップロード、秘密キーには、StartSSL のツールボックスの「Decrypt Private

仮想ホストで中間証明書を有効にする方法

イメージ
QNAP で HTTPS のために SSL 通信用のデジタル証明書をセットアップできたと思っていたら、PC 等他の環境では問題がないものの、Android の Chrome でセキュリティ警告(NET::ERR_CERT_AUTHORITY_INVALID)が出るという問題に直面した。 SSLLabs のテスト では incomplete chain や extra download と言われる。 丸一日かかって、どうやら完全に問題を克服することができた。 だいたい、こういうノウハウというのは、英語の情報(QNAP のフォーラム等)を参照すればどうにかなるもので、ほとんどのプロのエンジニアの人でも、正解となる先人の情報をどう見付けてくるかという話で、それをそのまま自分のブログに記録しているだけのケースが基本だろう(特に日本語においては)。(プロではないただのエキスパートなだけの)僕も、そういうつもりでいたのだけど、今回は、既存の情報が、低レベルなものしか見付からず、結局、自分の要求する水準のものを実現するために、自分でオリジナルに解法を確立する他なかった。 まず、何が馬鹿馬鹿しいかというと、QNAP の Web UI のセキュリティ設定があって、あそこで証明書を設定するものだと思っている人がほとんどだと思うのだが、あれがまず、騙し。あれって、myqnapcloud.com の Web UI 用の Web サーバーにしか関係がない、というかその用途しか、QNAP の中の人も念頭にない。仮想ホストで、独自ドメインを使って Web サーバーを使う場合のことは、全く蚊帳の外という……。 ほんで、英語の情報をどんなに探し回っても、Web UI 用の Web サーバーに対する証明書のセットアップについて、中間証明書を有効にする方法ばかり。それも古い情報が多いなと思ってたら、Web UI 用の Web サーバーについては、Web UI から中間証明書がコピー&ペーストで設定できるように今では対応済なんだから、当然。 もう、しょうがないので、最後は「ランボー怒りのリバースエンジニアリング」。Apache 関連のコンフィグを眺め回して、試行錯誤繰り返して、やっと仮想ホストでデジタル証明書を中間証明書を含めて適切に設定する方法を突き止めた。 httpd-ssl-v

Entware-ng で最新の Perl 環境

イメージ
QNAP の AppCenter で色々と追加パッケージをインストールできるという話だけど、Perl のバージョンが 5.10 というのはやる気がなさ過ぎる。 ……で、そもそも、QNAP のサーバーは初めて使うので、元々 Optware だとかのその手の類のものは何もインストールされていない状態だったのだけど、調べてみると、Entware、Optware、QNAPware、Itsy OPKG というのは、ぜ〜んぶ古くて、今は Entware-ng が活きてるものらしい。しかし、ネットで QNAP の情報を調べても、特に日本語では、古い情報が比較的多く残ってるので、この点は要注意だと思った。そこまで QNAP を使い倒しているような人が少ないせいだと思う。 Entware-ng については非常に情報が少なく、さらに、自分の使っている HS-210 で使えるかどうかも全く不明な状態だったが、今まで AppCenter も使ったことのない状況で、いきなり、 apps.qnap.community というサイトから qpkg をダウンロードし、AppCenter の設定からファイルを指定して手動でインストールするという、冒険に出た。全く確信はなかったが、これ以上情報を調べるのはもっと面倒臭かった。 すると、インストールは簡単に終ったようで、AppCenter のマイアプリに Entware-ng のアイコンが加わっているので、アンインストールも簡単そうだ。 それで、次に、ちゃんと動くのかどうか、SSH でログインしてみた。Perl が目的だったから、perl -v したが、何も反応なし。 perl -v -sh: perl: command not found どうやら、Entware-ng がインストールされた状態で、Entware-ng を使って、Perl などの個別のモジュールをインストールするようだ。それには opkg コマンドを使うらしい。Ubuntu の apt-get みたいなものだろう。下のような流れで Perl をインストールした: opkg update Downloading http://pkg.entware.net/binaries/armv5/Packages.gz. Updated list of availabl

QNAP の Apache で .htaccess を有効化

QNAP の Apache では、.htaccess がデフォルトでは無効化されているので、有効にするには、apache.conf の設定を 1 ヶ所、変更する必要があります。 <Directory /> Options FollowSymLinks - AllowOverride None + AllowOverride All Order deny,allow Deny from all </Directory> apache.conf は /etc/config/apache/apache.conf にあります。vi を使って編集してもいいですが、僕の場合は、scp を使ってローカルにコピーし、gedit で編集して、scp でアップロードして戻すやり方で作業しています。

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 3 / 3

rsync は SSH 越しでも行えるので、QNAP の SSH サーバーをセットアップすれば、「VPN を経由した NFS による rsync」(👉 その 2 )という少々器用な真似をせずに済むようになる。 ※ただし、QNAP の SSH は admin しかログインできない点には留意する。以下の作業ではすべて、admin で SSH 接続するためのものである。 QNAP の SSH 環境を整備する 自機側で RSA キーペアを作成する。 ssh-keygen -t rsa -C " 作成するキーペアに関するコメント情報 " 作成したキーペアのうち、公開鍵(id_rsa.pub)の方を QNAP (NAS) へ scp コマンドで転送する。当然、この際は、QNAP 側の SSH サービスはオンにしておく必要があり、admin アカウントとパスワード認証で scp の処理を実行することになる。 scp ~/.ssh/id_rsa.pub admin@ (NAS IP Address) :~ (admin にとっての ~ へコピー) SSH で QNAP に admin でログインし、~/id_rsa.pub を ~/.ssh/authorized_keys へ(追記)コピーする cat id_rsa.pub >> .ssh/authorized_keys chmod 600 .ssh/authorized_keys rm id_rsa.pub 以上で、QNAP 側の準備は終わり。 SSH から一旦ログアウトし、再び SSH で QNAP にログインすると、(自機側によって)パスフレーズを尋ねられる。問題なければ、ログインに成功する。これでパスワード認証ではなく、公開鍵認証によるログインができるようになった。 ※自機にある作成したキーペアはちゃんと管理しておくこと(セキュリティ面と、バックアップ面の両面において) 一応、SSH を利用するための作業としては以上である。SSH というのは、公開鍵をサーバー側にアップロードしておいて(公開鍵をアップロードできるのは、本人であるという前提による)、その公開鍵(サーバー側)と暗号鍵(本人側)をペアで使って、本人認証を行うというのが基本コンセプト。 ただし

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 2 / 3

イメージ
👉 その 1 では主に rsync コマンドの記述について説明したので、ネットワーク経由で NAS の指定した path にバックアップする方法の詳細については述べなかった。今回からは、その部分について、僕が試行した方法について説明する。 NAS の特定のフォルダを、NFS を使って自機にマウントして、自機のフォルダとして利用する まず最初に僕がやったのが、NFS を使って自機にマウントして、自機のフォルダと見做せるようにし、rsync では、ローカルのフォルダー間での同期として扱うやり方である。この場合、rsync の dest_path の指定において、NAS のネットワークアドレスに関する(admin@XXX.XXX.XXX.XXX: の部分の)記述は不要となり、次のような形で済む: rsync -auv --delete --progress ~/mydata /mnt/qnap/backup Linux(UNIX 系 OS)の非常に優れた文化が、このように、ネットワークドライブであろうが、さらには、入出力デバイスであろうが、すべて「ファイル」としてアクセスできるように、スッキリと極めてスマートに整えられている所である。 それはいいとして、この場合、rsync 側では、ネットワークのことは意識する必要はなくなるものの、NFS を使ってマウントする際には、ネットワークアドレスを指定する必要があるので、実質的には違いはない。誰が請け負うかが変わっただけである。 1: QNAP 側 で NFS を設定する QNAP 側では、「権限 > 共有フォルダ > NFS ホストのアクセス」で homes を「アクセス権:制限なし」にする。 2: Ubuntu 側で NFS を設定する まず、NFS をインストールする: apt-get install nfs-common NAS の共有フォルダを、Ubuntu 側に NFS としてマウント: マウント用ディレクトリを用意: mkdir /mnt/qnap マウントする: mount -t nfs XXX.XXX.XXX.XXX :/homes/ username /mnt/qnap (参考: How To Set Up an NFS Mount on

Ubuntu (Linux) と QNAP (NAS) 間で rsync - その 1 / 3

実家に設置している QNAP 製の NAS に、自機(Ubuntu)からデータを rsync でバックアップする体制を確立する。 rsync は、最初に一度バックアップしてしまえば、以降は差分(変更したもの)だけを修正する形になるので、毎回全体を丸ごとバックアップするような重い作業とはならず、極めてスマート。 rsync コマンドの使い方 rsync コマンドは、man rsync すれば詳細は調べられるとして、自分にとって必要な形は次の通り: rsync -auv --delete --progress src_folder dest_path -a はアーカイブ用オプションで、ファイルの権限情報の保持などのいくつかのオプションのセット指定。-u は、タイムスタンプが新しくなる場合にのみ更新する。-v --progress は詳細な情報を作業の進行とともに表示。--delete は、削除したファイルも同期して削除する。 src_folder と dest_path は他の多くの人が指摘するように、ひとつのハマりポイントなので注意すること。通常、バックアップする場合は、あるフォルダーを丸ごと NAS にコピーする意識で行う。こういった場合、 src_path の指定はフォルダー名で終わり、/ を付けない形で記述する。/ を最後に記述してしまうと、そのディレクトリの中の各ファイルを意味してしまい、バックアップ先に、そのディレクトリ直下の各ファイルが直接ぶち撒けられる形となるので、要注意。 一方、 src_path の指定をフォルダー( src_folder )にした場合、 dest_path は、そのフォルダーが置かれるべきパスにするべきである。つまり、バックアップ元の最後尾にあるフォルダー名は抜いた、そのフォルダーが配置されるべきディレクトリ名を指定する必要がある。初回のバックアップでは失敗しても気付かないかもしれないが、もし失敗した場合、同じフォルダー名のディレクトリが二重で置かれることになる。次回のバックアップでも同じ指定をするのなら、それでもいいのだが、もし一貫性がないと、前回のバックアップと別物として扱われ、差分ではなく、また新たに丸ごとがバックアップされてしまうようなことにもなりかねない。 例えば、自機の ~/mydata