著者:takahashi
QNAPのNASが凄すぎて最早ただのサーバ機と化している件
知人が自宅サーバー代わりにQNAPのNASの利用を検討しているとのことで、自分も気になって調べていたところ、QNAP製NASに搭載されているOS”QTS”の操作を実際に体験できる公式のライブデモサイトを発見。
早速触ってみました。
日本からの利用の場合は、ライブデモ-Asiaを利用すればOKかと思います。
／私、QNAPのNAS。こっちはQTSのログイン画面。＼
既にNASのログイン画面とは到底思えない装い。
その完成度にビビりつつも早速ログイン。
ログインID/PWはデモページ入り口に記載されているものを入力すれば入れます。
ログインに成功するとようこそ画面が出現。
そのままチュートリアルを読み進め、ウインドウを閉じると
iOSとGnomeを足して2で割ったような（？）UIが出現。
ブラウザのバーとかなかったら普通にPC用のOSに見間違いそうな完成度です。
NASストレージ内に保存されたファイルや
Nasの動作設定などもわかりやすい画面で確認・設定ができます。
が、そんなところでとどまらないのがこのQTS。
なんと普通のスマホやPCと同様にアプリをインストールすることで様々な機能を追加することができます。
さすが、伊達にOSと呼ばれはいないようですね…
しかししかし、OSたるもの、どんなアプリが対応しているか、というのも非常に重要なポイントです。
ということで、早速アプリストアをチェック
開いてみて驚いたのはその対応アプリの多さ。
めっちゃあるwwww
まずすごいのは、NASなのに
CMSがうごいちゃう！
NASなのに…
DHCPサーバーや仮想スイッチをたてれちゃう。
極めつけは…
えっNASなのにNode.jsやRuby on RailsやPostgreSQLも動くの…
普通に開発環境として使えちゃうじゃないですかやだー！！
ストレージ内に保存された音楽をブラウザ上やLAN内のDLNA機器などを経由して再生できるメディアプレイヤー機能
フォトライブラリなど、マルチメディア周りの機能も充実しています。
ちなみに、
S3互換のオブジェクトストレージサーバーアプリもあるので、S3とほぼ同じようなAPIをたたいてファイルを取得できるようにすることもできるようです…ﾋｪｰ（（
ちなみのちなみに、
RAID対応NASですので、搭載HDDの状態も勿論画面上から確認できます。
ここでふと気づいてしまいました…
自分が自宅サーバーでやりたかったことの大半….
もしかしてQNAP NASでできてしまうのでは….
できれば気付きたくなかったですが、これだけのものをアプリストアからインストールするだけで、しかもブラウザ上のGUIから自在にコントロールできるという簡単さは目から鱗レベルによくできています。
今回見た画面は飽くまでQTSのデモ版なので、実際にインストールして動かしたりとかまではできないので、実際の動作感までは分かりませんが、”自宅でサーバー動かしたいけど難しい操作は覚えたくない…”という人にとっては夢のようなガジェットかもしれません。
ここまでくると、本体のお値段が気になってきたので、現時点でのお値段をAmazon.co.jpで調べてみました。
HDDスロットが2つの、恐らくエントリーモデルと思われる製品。
約2万3千円という、標準的なNASに比べると結構しますが、下手に新品のPCを買うよりもお得かもしれません。
自宅サーバー歴5年の自分ですが、ここにきて心変わりの危機に瀕しております。
めっちゃほしい…
著者:takahashi
GDPRの影響でWhois情報公開が停止する可能性
EUのGDPR(EU一般データ保護規則)の影響ががついにWhoisデータベースにまで及びました。
ドメイン所有者の連絡先などが含まれる「WHOIS」データがGDPR発効の影響で一時的に非公開になる可能性 – Gigazine
GDPRはEU圏内に住む人々の個人情報について、所定の許可なく公開することを禁止する法律で、特徴的なのは域外の企業や事業者に対しても適用される点。
具体的には、一人でもEU圏内の人の個人情報を登録しているサービスでは、GDPRに則らないと制裁をうけるということです。
発効を前に、対象になった企業や団体が対応に追われている状況ですが、最近のニュースで特に大きな影響を受けるだろうとされるサービスが浮上してきました。
それが、世界中のgTLDドメインを管理するICANNによるWhoisデータベースです。
ICANNでは、Whoisにドメイン取得者の情報を登録することを義務付けており、従わない場合はドメインの登録を停止、取り消される規約になっていました。
この情報の中に住所や取得者の氏名などの個人情報が含まれています。
gTLDは世界的に使われているドメインなので、当然EU圏内の人もドメインを登録しているはずです。結果的にこのGDPRの影響をもろに受ける形になりなり、ICANNはWhoisの制度を見直さざるを得なくなりました。
現在、ICANNでは議論がされているようですが、答えが出るのに相当な時間がかかるため、GDPR発効までに対応版Whoisを構築することは難しく、暫定的な対応としてWhoisデータベースの公開制限や停止が行われる可能性が浮上しているようです。
ICANNのWhois情報公開の意義としてドメインの不正利用や犯罪の防止の目的もあり、今回のICANNの対応に対して、海賊版コンテンツに悩む各国の著作権団体からは抗議も上がっているようです。
GDPR規制によるWHOIS情報の制限に権利者団体が反発「海賊版の取り締まりを難しくする」 – P2Pとかその辺のお話R
ここからは個人的な意見ですが、僕はむしろ今回のGDPRによって、Whois情報が非公開化することは、”インターネットの個人利用”という観点からよかったのではないかなと考えています。
というのも、Whoisデータベースに氏名や住所などを載せないといけないのは企業だけではなく、ドメイン取得するすべての利用者が対象になります。
勿論ドメインを取得するのは法人だけとは限らないので、個人でドメインを取得する場合は自宅の住所なども公開する必要があるのです。
こんな状況でドメインを登録してしまうと、ドメインから一般の人に自分の住所が特定されてしまったりなどかなりリスクが高く、かといって自分のドメインを取得できない場合、個人的にサーバやサイトを建てる際にかなり制限を受けてしまう(SSL証明書が取得できないなど)の問題があり、”個人のサービスやサイトを公開するのに自分の自宅の住所をさらさないといけない”状態になっていました。
最近ではパブリッククラウドの普及などで、個人でも普通にサーバーを持つ時代になっていますし、この”法人を前提”としたWhoisの仕組みについて、個人的にかなり疑問に思っていました。
また、対応策としてレジストラによってはWhois代行公開サービスを提供している場合もありますが、ICANNの方針的に、いつ禁止されるかもわからない状況でした。
今回のGDPRの影響で結果的にWhoisの”だれでも情報にアクセスできる”状況の見直しが必要になったことで、Whoisの情報公開方法が見直され、”個人ユーザーにやさしい”Whoisの仕組みになることを期待したいと思います。
著者:takahashi
[要注意]MySQL 5.7からは初期状態でrootにランダムなパスワードが設定されている
先日、自宅のPCにUbuntu 18.04 LTSをインストールしたことを書きましたが、18.04でデフォルトになっているMySQLのバージョン”5.7″からMySQLのrootユーザーのパスワードが初期状態で自動設定される仕様に変更になったようです。
MySQL 5.7 をインストールしたら最初に行うセットアップ – WEB ARCH LABO
初期設定をする際、このことを全く知らなかったため、いつも通りmysqladminでrootパスワードを設定しようとしたのですが、何度やってもaccess deniedになり、パスワードなしてrootにログインすることもできなかったのでかなり焦りました。
ちなみにUbuntu 18.04の場合、初期状態であれば
sudo mysql
と、ユーザ名・PWすべて省いて実行したとことパスワード無しでログインできました。わかるかｯ！！！
ちなみに、設定したrootパスワードも、デフォルトで一定期間後にパスワード変更が求められるらしく、その際はパスワードを変更しない限りログインできなくなるようです。（設定の記述で無期限化は可能。）
とかなりセキュリティ的に厳しい仕様になっていますので、これから使われる方はご注意ください。
著者:ym
G Suite の DKIM 認証設定
今では送信ドメイン認証もいろいろありますが、今回は DKIM 。
以前は無償だった 元Google Apps (G Suite) をいくつか持っているのですが、SPF レコードは追加していました。けど、いまさらならが DKIM 署名ができることを発見したので追加しておきました。
Google G Suite DKIM
G Suite の管理画面で [アプリ]－[G Suite]－[Gmail の設定] を開くと、DKIM の公開鍵を生成できます。発行された DKIM 鍵を DNS へ登録し、認証を開始すれば DKIM 宣言できますよ！
著者:ym
常時VPN
先日のISP、NTTグループのブロッキングに続いて、mineoは画像の最適化を開始する様です。
解説：mineoが悪名高い「通信の最適化」を開始。 – すまほん!!
内容を見ると https (SSL/TLS接続) の場合は改ざんしない様なので、常時SSL化ではなく常時VPN化も検討してみることにします。
Android には、常にVPN通信する設定があるので、L2TP/IPsec を設定して、常時VPNをオンにします。しかし何故か、VPNサーバのアドレスと、DNSサーバのアドレスを IP アドレス指定で設定しなければならない様子。
VPNサーバはクラウドVPSを利用するので通信速度の劣化には無いとは思いますが、数日使って見て少し厄介だったのが、バンドオーバー時の再接続待ち。
それと、接続した無線LANに応じて、同じ FQDN でも、内部DNSやパブリックDNSで返すIPアドレスの値を変化させている部分。DNSサーバを複数指定して見ようと思いましたが、スペース区切りでも常時VPNの場合は1個しか記述できない様子です。
著者:takahashi
ソースからビルドしたApacheで、service statusが確認できないときの対処法
セットアップ中のサーバーで稼働状況を確認するために
sudo service httpd status
をした際、下記のようなエラーが発生しました。
<html>
Not Found
The requested URL /server-status was not found on this server.
__________________________________________________________________
Apache/2.2.34 (Unix) Server at localhost Port 80
殆どパッケージ版のApacheしか触ったことないので、見慣れない表示に、一瞬びっくりしてしまいましたが、なんとか心を落ち着けて解決方法を検索。
こちらのサイトで、解決策を見つけました。
VirtualHost設定 apache2サーバでのserver-status参照設定 – Check!Site
どうやら、/server-status というディレクトリの表示結果を見て稼働状況を判断しているということで、
http(s)://ドメイン名/server-status
にアクセスされたときに、ページを返すように設定すればエラーも解消するとのこと。
自分の場合、httpd.confに次の設定を追記
<VirtualHost *:80>
ServerName localhost
DocumentRoot "/usr/local/apache2/localhost"
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from localhost
</Location>
</VirtualHost>
あとは適当な内容のhtmlファイルを作成し、
/usr/local/apache2/localhost
へ配置しました。
この状態で、再度statusコマンドを打ってみます。
Apache Server Status for localhost
Server Version: Apache/2.2.34 (Unix) DAV/2 PHP/5.3.3
Server Built: Jul 27 2017 11:48:48
__________________________________________________________________
Current Time: Thursday, 26-Apr-2018 13:39:55 JST
Restart Time: Thursday, 26-Apr-2018 13:39:14 JST
Parent Server Generation: 12
Server uptime: 41 seconds
1 requests currently being processed, 7 idle workers
_W______........................................................
................................................................
................................................................
................................................................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
ばっちり、チェック結果が出るようになりました。
お困りの方の参考になりましたら幸いです。
著者:takahashi
MySQLで日本語が文字化けしてしまうときの対処方法
MySQLを使って良くやらかすミスの一つとして、文字コードの設定ミスがあります。
MySQLの場合、デフォルトのまま利用すると、テーブルやdbが意図していない文字コード(例えばlatin1)になってしまうことがあります。
この状態でselectなどで日本語を取り出そうとすると文字化けしてしまい、”??????”のような文字列に置き換わってしまいます。
使っているMySQLのデフォルトの文字コードを確認するには、SQL文を
show variables like 'character%';
とします。すると
mysql> show variables like 'character%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | latin1 | | character_set_connection | latin1 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.00 sec)
のような形で確認することができます。
上の表示を見ていただくとわかるように、”character_set_connection”がlatin1になっていると日本語部分が文字化けしてしまい、where構文で日本語をフィルタしてもヒットしなくなってしまいます。
mysqlをパッケージからインストールした際、大抵/etc/my.cnfという名前でmysqlの設定ファイルが作成されているかと思います。
この設定ファイルに対して、次の4行を追加します。
[mysqld] character-set-server=utf8 [client] default-character-set=utf8
この設定を追加後、再度mysqlの文字コード設定を確認してみます。
mysql> show variables like 'character%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.00 sec)
すべてutf8に変更されていることが確認できるかと思います。
この状態でselectすれば、日本語が文字化けせずに表示され、またwhere構文で日本語を検索しても、ちゃんとヒットするようになります。
サーバー側の設定を変更できなかったり、変更しても文字化けが治らない場合も、様々な方法があるようですので、お困りの方は確認してみてください。
MySQL のテーブルの文字コードを utf8 に変更する – UCWD-Studio – @matsuoka_UCWDjp ‘s Private Projects.
著者:ym
RIPE Atlas probe
RIPE Atlas probeが到着してから2ヶ月程、動かし続けています。
RIPE Atlas – RIPE NCC
RIPE はヨーロッパの IP アドレスを管理する団体なのですが、その団体がこの装置プローブ (probe) を世界中に無償配布して世界中のインターネットの状況をリアルタイム観測しようとするプロジェクトになります。GoogleMapの様な地図があってグリグリ動かして見る事ができます。
このサイトをGoogle翻訳すると、ビジョンや利点等、詳しく書かれています。
いま時点では、静岡県内に 4 個ありますね。で何？といった装置ですが一応ネットワーク携わっているのでね。今更設置してみました。先日メールが送られて来ましたが、なにか動きもありそうです。
著者:ym
QNAPとSSDキャッシュ
買おう買おうと思いながらも、全然買わない。買えない状況ではありますが。
QNAP の家庭向けグレードに新製品が加わっていました。
4 スロットでは大すぎるけど、でも 2 スロットの RAID1 ではな、とも思っていたのでジャストな 3 スロット。
そういう使い方ではなく、RAID1 + 1 スロットをSSDキャッシュアクセラレーションとして使うこともできます。
勿論 1 本オフライン待機は必要ですが。
VMware上でFreeBSDのNAS化したサーバを動かしているものの、ほぼバックアップとして動いている状況。
さらにはクラウド・ストレージ＋PC接続DASという構成でほぼ生活に満足している現状があるので、なかなかNASの必要性を感じないのですが。
Docker含めて仮想化も充実してるし魅力的なアプリ機能が登載サれているので、いつか手を出したい所ですが、今の所見るだけ。
著者:takahashi
自宅サーバーを始めるときに最低限気を付けたい3つのこと
最近、自分の周りで、自宅サーバーを始める方が増えてきました。
自分も自宅サーバーを稼働させているのですが、今回はサーバーについて今まで勉強してきた中で、始めるにあたって最低限気を付けたいことをまとめてみました。
-
OSやファームウェアのアップデートは可能な限りこまめに行う
LinuxやWindows、サーバーを構築するにあたって、必ず何かしらのOSをセットアップするかと思います。
このOS、人間が作っているためどうしても何かしらのバグが出てくる可能性があります。
このバグですが、場合によっては権限のない利用者に対して管理者の許可なくサーバーを操作する手段を与えてしまう”脆弱性”になる可能性があります。
大抵の場合、これらの脆弱性は、開発元が定期的に修正したものを配信しており、それを受信・適用する”アップデート”機能が必ず備わっていると思います。
普段使っている、使うときにしか電源を入れない”クライアントPC”は通常直接インターネット上に公開されていない上に、ネットワーク上にその存在があるかどうかも調べなければ外部からは分からないので、アップデートをさぼっていてもすぐにやられる可能性はまだ低いですが、サーバーの場合はインターネットからいつでもアクセスできる状態である上、その存在もネット上に一般公開されているため、だれでも簡単に接続できます。したがって、脆弱性が見つかったら直ちにパッチをあてないと侵入されてしまう危険性が出てくるのです。
ただ、実際のところ、パッチを適用する際にOSの再起動が必要になることも少なくありません。
実際に運用する際は、アップデートの有無を定期的に確認するようにし、もし再起動の必要のない更新がある場合はすぐに適用、もし再起動が必要なものについてはあらかじめメンテナンス日時を決めておき、利用者に通知したうえで適用するようにするといいと思います。
OS以外にも、使用しているネットワーク機器(ルーターなど)や、仮想環境で使っている場合はホストマシンのOSやハイパーバイザーのアップデートなども併せて確認しておきましょう。
-
メールの不正中継対策を行う
自宅のサーバーでメールサーバー(SMTP)を建てる場合、特に注意しないといけないのはメールの不正中継対策です。
例えば、自分のサーバーでSMTPサービス(postfixやsendmailなど)を立ち上げ、外部からアクセスできるような状態にしている場合、SMTPサーバーから認証なしにメールを送信できるようにしていると非常に危険です。
スパムメール業者などは、使用しているメールサーバーから大量に迷惑メールを送信している関係上、各メールサービスプロバイダからブロックされやすい為、常にブロックされていない新たなメールサーバーを探している可能性があります。
もし不正中継対策をしていないSMTPサーバーを公開してしまうと、こういった業者に、迷惑メールやウイルスメールなどの送信に使われてしまう可能性があります。
もし上記のようになってしまった場合、たとえ自分が送ったわけではないことが証明できたとしても、社会的信用を失ったり、場合によってはその責任を求められる可能性が出てきます。
パソコンが「踏み台にされる」という表現を目にすることがあります。踏み台にされると何が起きるのか、またどんな対策をすればいいのか教えてください。 – マルウェア情報局
対策として、自分のSMTPサーバーを認証なく利用できないように設定しておくと、不正中継を防ぐことができます。
【図解】初心者にも分かるメールの仕組み（SMTP、POP、IMAPの違い) – SEの道標
また、自分のサーバーが不正中継されない設定になっているかテストができるサイトがあります。
-
火事に注意
こちらは技術的な話からは離れるのですが、自宅で24時間PCを動かしていると、サーバーマシンが壊れた際に火事になるリスクがあるようです。
ノートPCをサーバーにして大惨事になった話 – VPS比較メモ
危険なのはノートPC、UPSなどのバッテリーを積んだ機器を使って稼働させている場合。
特にノートPCは持ち運びできるようにするために筐体を小さくすることに重点を置いて設計されており、長時間動作させることはあまり想定されていないようです。
そのため、サーバーのような24時間稼働させるような使い方をすると熱がこもり、バッテリーの爆発や中にたまったほこりなどに引火して火事になってしまうことがあるようです。
一方、デスクトップPCの方も火事になることはあまりないようですが、電源周りがショートして中で火花が飛ぶ、といったことが起こる可能性はあるようです。
自作PCからの出火が原因で火事になる確立はどのくらいでしょうか？- Yahoo!知恵袋
こちらもやはり、定期的なメンテナンスを設けて、ほこりの除去などの定期的な手入れをした方がよさそうです。
また、監視ツールなどを使ってハードウェアの状態を常に監視しておくことも有効かもしれません。
-
最後に
自宅サーバーの稼働には確かにリスクがあります。
それ故に「VPSなどを使えば事足りるし、安くて安全だし、自宅にサーバーを置くべきではない」という論調も目立ちます。
しかし、実際のところは、ガッツリサーバーを利用したい場合はVPSはかなり高くつきます(例えば、1TBのストレージを使おうと思ったら、自鯖ならHDDを追加すれば済みますが、VPSやクラウドの場合は月額でだいたい1万弱かかります)し、ハード構成やネットワークも含めて、一から自分で設計・構築ができるのはかなり魅力だと思います。
また、データはすべて自分が管理しているマシンの中に納まっているので、業者の不手際による情報流出や情報の不正利用のリスクを防ぐことができます。
ちなみに、有名なITニュースサイト Gigazine は、自分たちの発信する情報に対して圧力がかかっても公開が停止させられることがないように、という理由で、敢えてオンプレミスで運用している、という例もあります。
海外にディザスタリカバリを複数箇所設置 – Gigazine
自宅サーバーとクラウド(VPS)、どちらが優れているのかはそのままオンプレミスかクラウドか、の議論に発展していくわけですが、個人的にはこの議論はナンセンスだと思っています。
クラウドもオンプレミスも一長一短があり、どの形態が適しているのかは自分がどういったサービスを建てたいのかで決まってくるからです。そしてその選択肢として、クラウド(VPS)も自宅サーバー(オンプレミス)いずれもなり得えるということです。
また、どちらを選んだとしても、ネット上に自分の環境を公開することはリスクを伴います。そのリスクに対してどう対応していくか、考えていくのも勉強の一つだと思います。
普段何気なく利用しているWebサイトやWebサービスですが、その裏側がどうなっているのかを知ることはとても面白いです。
自分が構築したインフラやコンテンツが、インターネットを通じて全世界の人に見てもらえることの楽しさを、ぜひ多くの方が体験出来たら素敵だな、と思っています。