お知らせ

  1. ホーム
  2. お知らせ
  3. VPS
  • パソコン関連

AWS勉強会

noimage

AWS勉強会

今週に社内で小さなAWS勉強会を行いました。 勉強会の内容としてEC2インスタンスをひとつ作り、WEBサーバーをインストールするという内容でした。 EC2という名前は知っていても実際に使ったことがない、というハードルは簡単に乗り越えることができますよ、というのが開催の主旨です。 AWSのコンソールからほんの数回クリックするだけでAmazon Linuxサーバーのインスタンスが作成され、SSHログインするための用意がほぼ自動的に終わってしまうので本当にそこまでであれば20分も必要でないくらいでした。 そこからSSHログインのためのRSA暗号鍵についての説明や、WindowsのSSHクライアントPuttyでのインストールにはゆっくりと時間をかけて説明できたかなと思います。 RSA暗号鍵について、仕組みさえ分かってしまえば現在最も安全な認証方式と納得してもらるはずなので、その辺りについてはできるだけ話をしておきたいという気持ちはありました。 安全性よりも手軽さを優先させてパスワード、パスフレーズでのログインへは逆行したくないと、今後のサーバ管理を行うメンバーの間では徹底できたら良いなと思っています。 残りの時間はyumによるパッケージのインストールと、その手軽さについて理解してもらうために時間を使いました。 Linuxソフトウエアの導入についてはWindows利用者にしてみると、どのような手続きなのかわからない、あるいはややこしそうという印象を持たれているかもしれないので、全くそのようなことがないというのを理解してもらえていたら嬉しいところです。 基本的にyumコマンドでパッケージを検索したり、依存関係などを解決しながらインストールできることを体験してもらいました。 その他にもAWSのクラウドがどのような機能を備えているか、どのような拡張性があるかを大まかにお話をして、実際に事例などを学んで自分のものとして獲得していってもらえればと思っています。
  • パソコン関連

AmazonのVPSサービスLightsailが値下げ

noimage

AmazonのVPSサービスLightsailが値下げ

Amazonが展開するクラウドサービスAWS(Amazon Web Service)のVPSサービスであるLightsailが値下げを行いました。 VPSサービスはクラウド上に構築され提供される仮想サーバーで、契約者が管理権限を持ち専用で利用できるものです。 それぞれが独自のIPアドレスを割り振られ、メールサーバーやWEBサーバーなどを公開することが簡単にできます。 LightsailはAWSが提供するVPSで、主力のEC2が従量課金なのに対し、Lightsailは月額固定であることが差になります。 Lightsailはサーバースペックがあらかじめ決められており、用途に応じて月額費用を決めて利用する形になります。 価格としてはメモリ512MBのインスタンスが月額$3.5、1GBで5$とスモールスタートあるいはテスト環境などを構築するのに大変使いやすい価格となっています。 ストレージやCPUスペックはそれぞれ金額プランに応じて設定されています。 512MBのプランでも簡単なWEBサイト、サービスなどの開発などには十分な内容であるため、手軽に試すことができ、たくさんあるVPSサービスの中でも十分な魅力を持っています。
  • パソコン関連

レンタルサーバーとVPS

noimage

レンタルサーバーとVPS

WEBサーバーを手軽に公開するためにホスティング企業と契約し、レンタルサーバーを借りることがWEBの初期から行われてきました。 レンタルサーバーがあるおかげで企業ホームページや個人ホームページが少ない費用で開設でき、WEBの発展に役立ってきました。 現在レンタルサーバー企業でVPSのサービスを行っているところは少なくありません。 VPSとはバーチャルプライベートサーバーを省略したもので、一つのサーバーの中に複数の仮想サーバーが格納されたものです。 仮想サーバーは多くの場合固定のIPアドレスを一つ与えられ、ユーザーは管理権限を持つことができるのでサーバー内で様々なことを設定したりソフトウェアをインストールすることができます。 レンタルサーバーではホスティング企業がWEBサーバーの環境を整え、例えばPHPやMySQLのバージョンはどれかというのは固定か用意された複数の中からの選択になります。VPSであれば古いバージョンのOSや最新バージョンのOS、最新のPHPやMySQLのバージョンを選択したり、WEBサーバーにnginxなどApache以外を選択することができたりなど、どのような組み合わせを選ぶことも可能です。 そのため一般のレンタルサーバーでインストールできないWEBシステムなども、システム構築ができれば導入することができます。 ただ難しい点としては扱うOSについてそれなりの知識が必要なことや、セキュリティについて自ら行わねばならないなどがあります。また自由に設定できるものであるため、サポートは限定的です。それぞれ何を行ったかのログなどはホスティング企業には残されないため、利用者はサーバー内での障害や機能の衝突などについてサポートに解決してもらうことはほぼ不可能です。 自己責任という部分が非常に大きくなりますが、自由度とのトレードオフになります。 レンタルサーバーでもシェアの大きなWEBアプリはほとんど動作しますので、それ以上に難しいものやニッチなものについてはVPSを使うなどが選択肢になります。
  • パソコン関連

仮想化とは何か

noimage

仮想化とは何か

最近IT関連で、仮想化という言葉、仮想マシン、仮想サーバなどという言葉をよく耳にするかもしれません。 仮想化技術により、一台のコンピュータは、その中に複数のコンピュータが存在するかのように振る舞います。 パソコンで例えるなら、一台のパソコンの中にWindows7とWindows8、Windows10をインストールした3つのパソコンが独立して存在しているように見え、それぞれを個別に操作しアプリなどを立ち上げることができるようになります。 主にサーバの世界で、規模の大きいコンピュータのなかに複数のサーバーが存在して、それぞれが個別の役割(複数のWebサーバ、DBサーバなど)を果たすように使われることが多いです。 仮想化の仕組み パソコンは大まかに切り分けると、機器、OS、アプリケーションの三つの層で動作しています。 機器はCPU、メモリ、ハードディスク、DVDドライブ、USBポート、電源など機械としてのコンピュータそのものです。 OSはアプリケーションの操作を受け取り、機器を認識し、電気的な信号を用いて制御し、応答を待ちます。 これらの機器がセットになったコンピュータをパソコンの上にソフトウェアで作り出したものが仮想機械、仮想マシンと呼ばれるものです。 仮想化はOSに仮想マシンを認識させ、機器を制御するための信号を仮想マシンが受け取り、仮想マシンが応答を返します。 OSから見れば、正しく認識でき、制御、応答してくるものがあれば、それを機器とみなし動作します。 仮想化ソフトウェアはCPUの演算、メモリの読み書き、ハードディスクの読み書きなどこれらの処理を、実機、物理的に存在するコンピュータに割り当てます。 仮想化ソフトウェアがハードディスクへの書き込みの処理を仮想マシンから受けた場合、実機のハードディスクへ書き込みが行われるまでにワンクッションを置くことになります。 その分、実機で直接動作するOSよりも動作の遅れが発生しますが、これを解消するためにハイパーバイザという技術も採用されています。 ハイパーバイザは仮想マシンが直接実機の機器へアクセスするための手法です。 仮想化のメリット 仮想化のメリットとしては、機器を複数台メンテナンスせず、複数のサーバを運用することができるようになることです。 Webサーバ1、Webサーバ2、DBサーバ、3台のサーバが同時に動作していないと正常に動作しないシステムがあるとします。 これら3台のうち、1台でも故障になれば動作しなくなるのであれば、3台の非常に堅牢なサーバーを用意するか、それぞれにバックアップのためのサーバを運用して6台を動作させ続けなければならないことになります。 実際はもっと複雑ですが、ここでは単純な考え方を使います。 ここに3台分の処理能力を持つ高性能なサーバを用意し、それぞれ3つのサーバを仮想化して動作させるとすれば、バックアップ機を用意するとしても、運用に必要なコストは3分の1になります。 機器購入の初期費用も、ある程度は高性能なサーバーになりますので高くなりますが、それでも3台分の費用と比べると格段に安価になります。 このような形でWebサーバーのホスティングなどを提供するVPSなども、専用サーバーと価格差を強調できるのでレンタルサーバー運営企業がユーザー向けに提供しています。 開発などでも仮想化は便利に利用され、開発環境ごとに別々の仮想マシンを利用すれば、再インストールの手間を省いて全く別の環境を同じパソコンの上に作り出すことができます。
  • シスキュー技術部

amavisd-newの問題解決

noimage

amavisd-newの問題解決

spamassassinの日次アップデートスクリプトがエラーを送ってくるようになったので、その原因を調査して解決しました。 spamassassinは迷惑メール定義ファイルを持ち、迷惑メールをサーバー側で削除してくれるプログラムです。 sa-update.cronを日次処理で実行させると、cronがエラーのメールを送ってきます。 タイトルは /usr/share/spamassassin/sa-update.cron 2>&1 | tee -a /var/log/sa-update.log 内容は The amavisd daemon is apparently not running, no PID file /var/run/amavisd/amavisd.pid という風になっています。 amavisdはamavisd-newというサーバー側のウィルスメールスキャナーで、spamassassinと連動して動作しています。 このエラーメッセージを見ると、amavisdが起動していないのかな？と考えます。 サーバーにログインして、 [bash] service amavisd status [/bash] としてみて、停止しているかどうかを確認してみます。 結果は amavisd (pid xxxxx xxxxx xxxx) is running... となって、プロセスは動作しているようです。 では再起動させようとして、 [bash] service amavisd restart [/bash] としてみると、 amavisd を停止中: The amavisd daemon is apparently not running, no PID file　/var/run/amavisd/amavisd.pid amavisd を起動中: [  OK  ] 同じエラーが出ます。 [bash] ls /var/run/amavisd/ [/bash] してもamavisd.pidが確かにありません。 設定ファイル /etc/amavisd/amavisd.conf には $pid_file = “/var/run/amavisd/amavisd.pid”; とあります。 この辺を検索してみると、 $pid_file = “$MYHOME/var/amavisd.pid” という記述もあるので、もしかしたら、と/var/spool/amavisd/var/を確かめるとamavisd.pidはありました。 DaemonをStopするのにも、別のところのpidファイルを探しに行っていたようなので、一度Service amavisd statusで表示されたプロセスをkillしてみます。 そして再度起動、さらに再起動してみます。 [bash] service amavisd restart [/bash] amavisd を停止中: [  OK  ] amavisd を起動中: [  OK  ] というわけで、うまくいきました。 [bash] ls /var/run/amavisd/ [/bash] すると amavisd.pid があることが確認できます。
  • シスキュー技術部

CentOSにMailmanのインストール

noimage

CentOSにMailmanのインストール

メーリングリストサーバーをVPSに構築した際のメモです。 オープンソースのメーリングリストサーバーMailmanを利用します。 ApacheとPostfixが稼働している状態から開始します。 yumでインストールできるパッケージがMailmanの2.1.13でしたので、 http://docs.python.jp/contrib/mailman/releases.html こちらから最新版を取得します。 こちらでダウンロードできるバージョンは細かい日本語向けカスタマイズが施されています。 [bash] yum -y install python-devel [/bash] pythonのインストールを行います。 [bash] groupadd mailman useradd -c "GNU Mailman" -s /sbin/nologin -M -g mailman mailman mkdir /usr/local/mailman chown mailman. /usr/local/mailman chmod a+rx,g+ws /usr/local/mailman [/bash] Mailmanのグループとユーザーを作ります。 [bash] wget http://docs.python.jp/contrib/mailman/_static/mailman-2.1.14+j7.tgz tar zxvf mailman-2.1.14+j7.tgz mv mailman-2.1.14+j7 /tmp/ chown -R mailman. /tmp/mailman-2.1.14+j7.tgz [/bash] Mailmanの最新バージョン2.1.14+j7をダウンロードし解凍、/tmp/以下に移動させます。 [bash] cd /tmp/mailman-2.1.14+j7 su mailman -s "/bin/bash" -c "./configure --with-cgi-gid=apache" su mailman -s "/bin/bash" -c "make" && make install [/bash] makeを実行し、インストールフォルダにインストールします。 [bash] cd /usr/local/mailman/ ./bin/check_perms -f ./bin/check_perms [/bash] アクセス権チェックを行います。-fオプションで自動的に修正してくれます。 [bash] rm -rf /tmp/mailman-2.1.14+j7/ [/bash] ソースを削除します。 [bash] vi /usr/local/mailman/Mailman/mm_cfg.py [/bash] ここでMailmanのコンフィグファイルを設定します。 [text] DEFAULT_URL_HOST = 'hostname' DEFAULT_EMAIL_HOST = 'hostname' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) MTA = 'Postfix' DEFAULT_SERVER_LANGUAGE = 'ja' DEFAULT_URL_PATTERN = 'http://%s/mailman/' [/text] URLホスト名には、正確なURLを記述してください。ここが実際アクセスするものと違う場合、管理画面でエラーになります。 EMAIL_HOSTにはメールサーバーのドメイン名を入力してください。 ここに入力した文字列が、メーリングリストへの投稿先となります。 メーリングリスト名@DEFAULT_EMAIL_HOSTが投稿先となります。 mm_cfg.pyには新たにメーリングリストを作成する際のデフォルト値をいろいろと設定することができます。 GUIの管理画面からも設定できる部分ですが、同じような性格のメーリングリストを複数作成する際は、ここに記述しておくと便利です。 このような設定があるとすると、mm_cfg.pyには [text] DEFAULT_MAX_MESSAGE_SIZE=0 [/text] のように記述しておくと、新規に作られるメーリングリストにあらかじめ適用されます。 [text] /usr/local/mailman/bin/mmsitepass password [/text] Mailman全体のパスワードを設定します。 [bash] crontab -u mailman /usr/local/mailman/cron/crontab.in [/bash] MailmanのCronの設定を行います。 [bash] /usr/local/mailman/bin/genaliases chown mailman. /usr/local/mailman/data/aliases* chmod g+w /usr/local/mailman/data/aliases* [/bash] Mailmanのエイリアス設定を行います。 メーリングリストを作成する度に、メーリングリスト用に新たな複数のエイリアスが作成されます。 入退会用、コマンド送信用、メーリングリスト送信用などです。 [bash] vi /etc/postfix/main.cf [/bash] main.cfの中の以下に、mailmanのaliasesを設定します。 [text] alias_maps = hash:/etc/aliases, hash:/usr/local/mailman/data/aliases [/text] これをpostfixに反映させます。 [bash] service postfix reload [/bash] Apacheの設定ファイルをMailman用に作成します。 [bash] vi /etc/httpd/conf.d/mailman.conf [/bash]   [text] ScriptAlias /mailman/       /usr/local/mailman/cgi-bin/ <Directory /usr/local/mailman/cgi-bin/> AllowOverride None Options ExecCGI Order allow,deny Allow from all </Directory> Alias   /pipermail/     /usr/local/mailman/archives/public/ <Directory /usr/local/mailman/archives/public/> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> [/text] これを保存し、 [bash] service httpd checkconfig service httpd graceful [/bash] apacheをリスタートします。 [bash] /usr/local/mailman/bin/newlist mailman [/bash] 管理用メーリングリストを作成します。 管理者メールアドレスと、mailmanパスワード、を入力し、エンターを入力すると、作成が完了します。 [bash] /usr/local/mailman/bin/config_list -i /usr/local/mailman/data/sitelist.cfg mailman [/bash] メーリングリストの初期設定を行います。 [bash] cp /usr/local/mailman/scripts/mailman /etc/rc.d/init.d/ /etc/init.d/mailman start chkconfig --add mailman chkconfig mailman on [/bash] 起動スクリプトを設定して、自動で起動させます。 ここで http://hostname/mailman/admin にアクセスし、Mailmanの管理画面が表示されれば、インストール完了です。 アイコンが表示されていなかったので、アイコンをwww配下のiconsディレクトリにコピーします。 [bash] cp /usr/local/mailman/icons/* /var/www/icons/ [/bash] これでアイコンも正常に表示されました。 設定次第で、双方向のメーリングリストや、メールマガジン風など様々な設定が可能で、つかいやすい印象です。 ユーザーも管理画面から様々な操作ができますが、今回必要なメーリングリストは閉じたものですので、認証をかけて管理画面にアクセスできないようにしました。 Mailmanの設定項目はかなりいろいろありますので、最適な設定を探してみてください。
  • パソコン関連

ownCloudのテスト中の使用感

noimage

ownCloudのテスト中の使用感

Dropboxの代替手段として紹介したownCloudですが、いろいろとテストしてみています。 まだまだ実用ベースで利用できるという判断はしていませんが、現在までのざっくりとした感想を書いてみようと思います。 Web経由ですと、php.iniのファイルアップロードの上限を受ける以外に、仕組み上の1GBの制限があるようですが、クライアント経由、WebDAV経由であれば、それらの制限は受けないようです。 4GBのファイルを試みにアップロードしましたが、owncloudディレクトリ配下のユーザーディレクトリに同期されました。 そこから他のマシンへの再同期は現在試していません。 あまり大きなファイルを扱うのは得意ではないと考えられますが、バックアップ用として、サーバに格納されればよいのであれば、使い道はあります。 転送速度について フォルダを同期しながらのファイルコピーは大きな時間がかかりますので、 同期を一時停止してからファイルをコピーし、そこから再開することで、ファイルコピーとファイルの転送を分けて行うことができ、大きなファイルは円滑にアップロードできるように感じます。 この方法で、700MB程度のファイルの転送に要した時間は9分でした。 1.3MB/秒ほどのアップロード速度が出ていますので、テストした環境では、dropboxへのアップロードよりは、はるかに高速に行われているという感覚です。 Dropboxは独自の通信手段と、暗号化、サーバーもアメリカにあるという事ですから、参考程度の数値ではありますが、筆者の環境では300KB/秒ほどが平均的なアップロード速度です。 大容量、長時間のアップロードについて 個人所有のVPSにownCloudを設定し、就寝前に、個人所有のそれなりに大容量で多数のファイル、21GBをクライアント経由で同期するテストを行いました。 起床までに転送は終了しており、ログによると転送時間は6時間程度かかり、おおよそ0.9MB/秒ほどの速度が出ていたことになります。 Dropboxでは有料でないと21GBの転送を試すことはできませんので、Dropboxでは同等のことを試すことは筆者にはできません。 アップロードしたものは、複数の日本語を含むファイルでしたが、iPhoneのownCloudアプリでファイルを確認したところ、正常にファイル名をみることができました。 LTE圏内であれば、一つのファイルが数秒でダウンロードされます。 ownCloudクライアント自身では音楽の再生機能はないので、そこからGoodReaderで開くを選択することで再生も可能でした。 このようなサーバ経由のメディアファイルの取り扱いは、法的な解釈が分かれるところであり、このサーバーを他者とも共有しない限りは違法性は薄いと考えますが、あくまでわかりやすい規模のボリュームの、アップロードのテストとして行っていることを付け加えておきます。 SSL通信について PCやMac、iOSのクライアントを介したものも、HTTPSを設定していれば、すべてSSLで通信されているようです。 アップロードもダウンロードもSSL通信で行われていることが、ログからも確認できます。 コストなどについて 今回使用した自己所有VPSテスト用サーバーはさくらのVPS2Gプランを使用しています。 Dropbox有料プランと、さくらVPSの価格を単純に比較してみます。 Dropboxは100GBの容量が年間$99.00、200GBで$199、500GBで$499です。 費用はこれだけで、あとはプロバイダなどの一般的な通信費用となります。 さくらVPSであれば、1Gプランディスク容量100GBで10,780円、2Gプラン200GBで16,800円、4Gプラン400GBで47,760円です。 VPSですのでシステム領域が必要ですので、すべてをストレージとして使用することはできません。 これに追加して、SSL通信を行うためにドメイン、SSL証明書で年間約4000円～の費用が最低でもかかります。 Dropboxは割安なうえに、導入までに必要な手間は全く違いますので、簡単に比較できるものではありません。 コスト的な面で見るとこのような差があります。 ownCloudの有利性 自己管理のサーバーであるため、さまざまなVPNソフトや、iptables、htaccessを利用した、アクセス制限をニーズに合わせて設けられることが、Dropboxに対する優位性と考えます。 社内保有のサーバーなどにも導入することができますので、データのバックアップや完全な消去などを自己の管理下で行うことができます。 これからまた、様々な形でテストを行い、ownCloudの有用性を探っていきたいと思います。
  • シスキュー技術部

CentOSとownCloudで社内用のDropboxをつくる

noimage

CentOSとownCloudで社内用のDropboxをつくる

オンラインストレージ、Dropboxなどはかなりメジャーな存在となっています。 クライアントをインストールしておくと、指定フォルダーの内容をサーバーにアップロードし、同じアカウントを登録してある他のPCと同期します。 またwebブラウザを介して、ファイルのダウンロードもでき、公開用URLを設定して、他の方との共有も可能です。 このDropboxはファイル送信経路や、ファイルサーバー側での暗号化は行われており、無料から利用できるとはいえ、セキュリティー的な部分で不安なものではありません。 しかしながら、たとえば消去や、取り出し、バックアップなど、具体的なデータの取り扱いについて、完全にコントロール下におけるものではありませんので、社内ポリシーで禁じられている、あるいは一定以上のセキュリティー基準を設けて、重要なファイルを置かないようにする、などさまざま運用方針を持っている方もいらっしゃると思います。 これを自社保有のサーバーで同じような仕組みを提供するもので、ownCloudというオープンソースソフトウェアがあります。 今回はこれを試してみます。 ownCloudのインストール CentOS6.3+apache2+mod_SSL+PHP5.3.3+PostgreSQLがあらかじめ構築されたVPS環境を利用しました。 ownCloudは仕組み的にはWebDAVを利用しますので、経路暗号化のために、自局認証ではなく公的認証局によるSSL証明書を用意しておくことが重要です。 ownCloudのwebサイトから、Install、LinuxPackagesでCentOSを選び、指示された通りにリポジトリを追加し、yumでインストールします。 これで必要な他のパッケージとともにインストールされます。 [bash] cd /etc/yum.repos.d/ wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_CentOS-6/isv:ownCloud:community.repo yum install owncloud [/bash] これで [text] /var/www/html/owncloud/ [/text] 以下にインストールされます。 初回セットアップの前にpostgreSQLにデータベースとユーザーを作っておきます。 [bash] su - postgres createdb -E UTF8 -U ユーザー名 -T template0 owncloud [/bash] https://yourhost/owncloud にアクセスすると、セットアップが始まります。 今回、gdがないというエラーが出ましたので、gdをインストールし、 [bash] yum -y install gd [/bash] apacheをリスタートします。 [bash] service httpd restart [/bash] 再度セットアップをはじめます。 ここで管理ユーザーとパスワード、使用するDBをPostgreSQLを設定します。 Finish Setupを選択します。 ここでoc_ユーザー名にテーブル作成権限がない、というエラーが出ましたので、owncloudデータベースに権限を与えます。 [bash] su – postgres psql GRANT ALL PRIVILEGES ON DATABASE owncloud TO oc_ユーザー名; [/bash] 再度セットアップを行うと、無事インストールが終了しました。 owncloud/config/config.php に [text] 'forcessl' => true, [/text] と加えておくとssl接続に限定されます。   インストール後の利用方法 ひとまず管理者でログインし、動作を確認しましょう。 新規ボタンでファイルをアップロードできます。 DropboxのWebを利用したことがあれば、すぐに操作方法はわかります。 管理者であれば、左下の設定アイコンからメニューを出して、ユーザーを追加できます。 その他にもプラグインや、全体設定などを操作することができます。この辺りはDropboxにはない操作ですので、いろいろ試してみてください。 WebDAVですので、 [text] https://yourhost/owncloud/remote.php/webdav/ [/text] でアクセスできます。 PC・スマートフォンのクライアント PC・Mac・iOS・Android各クライアントで動作を確認しました。 http://owncloud.org/support/install/ PC・Macでは任意のフォルダと同期、iOS、Androidでは、ダウンロードしたファイルを開いたり、写真をアップロードしたりできます。 PC版 Windows8のスタート画面ではこんな感じです。 Mac版 iPad版 Android版 それぞれ、 https://yourhost/owncloud ユーザー名 パスワード を入力して、認証が通れば、すぐに使用可能です。 PC・Mac版は無料、iOSは85円、Androidは99円（記事作成時の価格）でした。 セキュリティーなど httpsでの接続でなければ、経路の暗号化はできませんし、公的認証でなければ成りすましを防ぐ方法はないので、SSLの公的認証は必須と言えるでしょう。 それさえクリアできれば、細かい使い勝手の差はありますが、Dropbox等と同じように利用し始めることができます。 少なくとも自己管理できる範囲で、状況を把握でき、独自運用できるものとしては、かなり簡単な仕組みです。 一通りのLinuxOSの構築ができていれば、1~2時間もあれば、十分使い始められます。 ファイルはownCloudディレクトリ内に暗号化されずに保管されます。 .htaccessによって、外部からのアクセスはできませんが、サーバーの管理権限があれば、自由に閲覧、移動、削除などが可能です。 プラグインによって、保管ディレクトリの暗号化はできますが、その際は制約があるようです。 プラグインによって、様々な機能を追加できるのもownCloudの利点ですが、それによる不都合も出てくる可能性は考慮すべきです。 運用にあたっては、ownCloudの脆弱性、Apacheの脆弱性などについて、情報収集が必要となりそうです。 あとはユーザー名、パスワードのみの認証ですので、十分複雑なパスワードを設定する必要があります。 VPNでさらに通信の暗号化や、iptablesによって公開するグローバルIPアドレスなどを自社の各拠点や取引先に限定する、などを行えば、さらにセキュリティーの向上が望めるのは自己管理のサーバーならではの利点でしょう。
  • パソコン関連

WinSCPを利用した遠隔地バックアップ

noimage

WinSCPを利用した遠隔地バックアップ

この二十年ほどで、いくつかの大きな災害に見舞われ、拠点に被害が及んだ場合、社内の情報資産をすべて消失してしまう、といった出来事も起こっています。 複数拠点をもつ企業様であれば、拠点間のVPNや専用線を用いて、バックアップを行う体制をもつところも多いと思います。 このような複数拠点間VPNなどを持たない場合、どうしても業務遂行上必要な日常バックアップを、定期的に遠隔地に保管しておきたいという需要はあると思われます。 ディザスタリカバリなどという言葉もありますが、なんらかの対策の必要性を求められている方も、増えてきているのではないでしょうか。 ここで重要視されるのは、経路間の安全性確保、保管の安全性などになります。 経路の暗号化を確保したうえで、Windowsで始められる簡単なバックアップを考えてみます。 WinSCPとは WinSCPとはLinuxなどで標準的に取り入れらている、通信プロトコルSSHに対応したファイル転送クライアントです。 SSH接続機能のあるサーバに接続した後の操作は、一般的なFTPクライアントと、大きな違いはありません。 それならFTPを使ってレンタルサーバーなどに保存しても変わらないのではないか、と思われるかもしれませんが、FTPとSSHでは大きな違いがあります。 SSHは認証と経路の安全性を、暗号化により確保しています。 FTPは暗号化されていないユーザー名とパスワードを送信して認証し、ファイルの転送も暗号化されていません。 そのため、経路途中でだれかに盗聴されていても、気が付く方法はありません。 身近に起こる盗聴の例としては、誤った無線LANアクセスポイントに接続してやり取りした内容は、暗号化されていなければ盗聴されている可能性は十分あります。 SSHを利用した場合は、このような場合でも盗聴は不可能です。総当たり攻撃によるパスワードの突破や、経路途中の盗聴を防ぐ方法が用意されています。 他にWindows向けSSH利用のファイル同期アプリケーションとしてcwRsyncがありますが、フリーソフトから商用ソフトになりましたので、フリーソフトであるWinSCPを利用したフォルダの同期を行うこととします。 バックアップ先のサーバーについて ここではあらかじめ、公開鍵認証型のSSHサーバーが用意されていることを前提として、記述いたします。 サーバーの管理権限のない方は、サーバーの管理者と協調して設定してください。 レンタルサーバーでSSHを利用できるものもありますが、ほとんどがパスワード認証形式で、より安全な公開鍵認証方式によるものより、総当たりのパスワード突破攻撃に弱くなります。 同一価格帯でも、レンタルサーバーとVPS（バーチャル・プライベート・サーバー）では利用できるハードディスク容量はVPSの方が、多く割り当てられているものが多いので、設定には専門性が必要となりますが、VPSがお勧めできます。 WinSCPの設定方法 WinSCPのダウンロードサイトからWinSCPをダウンロードして、インストールを行います。 公開鍵と秘密鍵の作成 スタートメニューにWinSCPが登録されますので、鍵関連ツールからPuTTYgenを起動します。 ここで認証用の鍵を作成します。 ここでGenerateをクリックし、鍵の作成を始めます。 鍵のタイプは画面下の方、SSH-2 DSA 1024bitを選択します。 緑色のプログレスバーの下の空白を、マウスポインタでぐりぐりとしていると、ランダムな暗号が生成されます。 上部ボックスに表示されている、アルファベット数字記号の混ざったものが公開鍵です。 このボックス内をコピーして保存し、サーバーに公開鍵として登録します。 Key Passphareseには秘密鍵のパスフレーズを入力し、Save Public Keyと、Save Private Keyをクリックして保存します。 秘密鍵のパスフレーズはできるだけ長いことが求められます。 この秘密鍵と秘密鍵のパスフレーズが漏えいすると、SSHサーバーにアクセスできてしまいますので、管理できることろに保管します。 WinSCPでサーバーとの疎通確認 ふたたびスタートメニューから今度はWinSCPを起動します。 ログイン画面が出るので、ホスト名に接続先、ポート番号にSSHポート番号、ユーザ名にはサーバでのユーザー名、秘密鍵に先ほど作成した秘密鍵を指定します。 ここで保存をクリックすると、接続情報が保存されます。 ログインを押すと、サーバとの接続が始まります。 はじめて接続するサーバであると、サーバ鍵の指紋（フィンガープリント）が送られてきますので、これを鍵のコピーをクリックして、テキストファイルに保存し、はいをクリックします。 ここで登録されたサーバの指紋は保存され、今後同一のサーバーであっても指紋が違う場合は警告が表示されるので、接続経路の詐称に対応でき、サーバーの同一性が確保できるようになります。 ここで鍵作成時に登録した秘密鍵のパスフレーズを入力し、OKを押します。 認証が完了すると、WinSCPの操作画面が開きます。 ここでファイルを一つコピーして、書き込み権限などがあることを確認します。 これでWinSCPの作業は設定は終わります。 Pageantの設定 今回は自動的にバックアップ処理が動作することを目指しますので、バックアップの際に毎回秘密鍵のパスフレーズを入力することを省力するためにPagentを設定します。 鍵関連ツールの中にあるPageantを実行します。 Pageantは秘密鍵とパスフレーズの設定をしておくとWinSCPの認証時に、パスフレーズの入力を省略できるものです。 ここでAddKeyをクリックし、先ほど保存した秘密鍵を選択します。 パスフレーズの入力を求められるので、入力すると登録され、Pageantは常駐します。 この状態でWinSCPで先ほどのサーバーに接続すると、パスフレーズを入力せずに認証ができます。 Pageantを終了するたびに、鍵の登録はクリアされます。 WinSCPによる自動バックアップ WinSCPによるバックアップを自動化するために、次のことを行います。 ・Pageantをログイン時に自動起動 ・WinSCPを自動的に起動しファイルの同期 それぞれバッチファイルを作成し、タスクで起動させます。 Pagent自動起動バッチファイルの作成 メモ帳を開き、 [text] "C:\Program Files\WinSCP\PuTTY\pageant.exe" "C:\Users\Username\winscp\id_dsa.ppk" [/text] 上記のように、pageantの場所と、秘密鍵の場所を指定します。 Pageantの場所はデフォルトではこの場所になります(32bitWindows)。秘密鍵の場所は、保管されている場所を登録してください。 これを名前を付けて保存、ファイルの種類にすべてのファイルを選んで、pageant.batという名前でバッチファイルとして保存します。 バッチファイルを起動させて、タスクトレイに帽子をかぶったパソコンのアイコンで、Pageantが起動することを確認してください。 WinSCPバッチファイルの作成 まずWinSCPに送信するコマンドをファイルにまとめます。 同じようにメモ帳を開き、 [text] # バッチモードに設定し、確認/問い合わせを無効にする option batch on # ファイル上書きの確認などを無効にする option confirm off # サーバーに接続 open <a href="mailto:username@hostname">username@hostname</a> -hostkey="ssh-rsa 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx" #サーバー側とファイルを同期 synchronize remote C:\Users\Username\Documents\backup\ /home/username/backup #接続終了 close #WinSCP終了 exit [/text] 上記を参考に、コマンドを作成し、テキストファイルとして保存てください。 -hostkeyには先ほど保存したサーバー鍵の指紋をコピーしてください。これで 設定方法については、詳しい参照先をご覧ください。 これをWinSCPへ入力するバッチを作成します。 [text] "C:\Program Files\WinSCP\winscp.exe" /console /script=C:\Users\Username\Documents\WinSCP-Batch.txt [/text] WinSCPの場所はデフォルトのままです(32bitWindows）。 /script以下には先ほど作成したコマンドのテキストファイルを指定し、バッチファイルとして保存します。 バッチファイルをクリックし、必要な動作が行われることを確認します。 タスクへ登録 スタート画面からアクセサリーシステムツールータスクスケジューラを起動します。 タスクに名前を付けます。 Pageantであればログイン時、WinSCPのバックアップであれば、毎日など必要な頻度を設定します。 バッチを実行するのでプログラムの開始を選択します。 バッチファイルの場所を設定します。 このような形で登録が完了します。 プロパティ設定で、必要であれば設定を行ってください。 設定後、Pageantと、WinSCPのタスクからの起動を確認できれば、完了です。 設定後のことなど 今回、比較的省コストで身近なもので、一定のセキュリティーを確保したバックアップ手段を試してみました。 経路暗号化には、SSH以外にも、VPNを使う方法もあり、VPNを利用して別拠点にファイルコピーを行うなど、さまざまなパターンがあります。 経路暗号化したインターネット越しのファイル転送はあまりスピードが出ない場合もあり、今回テストしたケースでは、600KB/秒程度のスピードですので、大きいファイルであればかなりの時間がかかってしまうことも考えられます。 ここからアレンジして、たとえば圧縮ファイルを利用することで転送時間を短くするなど、様々な方法が考えられます。 本格的な導入を行うのであれば、商用サービスも様々ありますので、事態が発生する前に、情報収集や準備をしていくことも必要になってきていると考えます。
  • シスキュー技術部

ClamAVがアップデートした際にfreshclamが正常に動かない

noimage

ClamAVがアップデートした際にfreshclamが正常に動かない

当サーバはClamAVというアンチウィルスソフトで保護されていますが、このClamAVの日々の更新がうまくいっていない旨のメールが届くようになりました。 メール本文は以下の通り /etc/cron.daily/freshclam:ERROR: Problem with internal logger (UpdateLogFile = /var/log/clamav/freshclam.log).ERROR: Can't open /var/log/clamav/freshclam.log in append mode (check permissions!).   freshclamは定義ファイルの更新プログラムですが、それがログを追記できないのが原因のようです。 早速リモートでサーバーに接続して/var/log/clamavのあたりをチェックしてみます。 すると所有者がclamに変更されており、clamavやfreshclamはclamavの権限で動作するよう設定していますので、この齟齬がエラーの原因と考えられます。 この状態でfreshclamしても、ERROR: Can't open /var/log/clamav/freshclam.log in append mode (check permissions!).ERROR: Problem with internal logger (UpdateLogFile = /var/log/clamav/freshclam.log). メール本文と同じエラーが出力されます。   この/var/log/clamavあたりの所有権を訂正しないと、clamavが定義ファイルを更新できないので、 [bash] # chown –R clamav:clamav /var/log/clamav [/bash] として、/var/log/clamav以下のディレクトリをclamavの所有権に変更します。 これで [bash] # freshclam [/bash] すると、ClamAV update process started at Mon Oct 15 13:39:27 2012nonblock_connect: connect timing out (30 secs)Can't connect to port 80 of host db.jp.clamav.net (IP: 219.106.242.51)Downloading main.cvd [100%]main.cvd updated (version: 54, sigs: 1044387, f-level: 60, builder: sven)Downloading daily.cvd [100%]daily.cvd updated (version: 15460, sigs: 276636, f-level: 63, builder: guitar)bytecode.cld is up to date (version: 190, sigs: 36, f-level: 63, builder: neo)Database updated (1321059 signatures) from db.jp.clamav.net (IP: 211.10.155.48) エラーも出ず、正常に終了しました。 （追記） ふたたびcronが正常に動作していないメールが流れてきていました。/etc/cron.daily/freshclam:ERROR: Can't create temporary directory /var/lib/clamav/clamav-fb2e8913efa2473d6fce1646e98b3a64 定義ファイルを格納してる/var/lib/clamavディレクトリも所有者がclamになっています。 そこで同様に [bash] # chown –R clamav:clamav /var/lib/clamav [/bash]して [bash] # freshsclam ClamAV update process started at Thu Oct 18 10:19:09 2012 main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven) nonblock_connect: connect timing out (30 secs) Can't connect to port 80 of host db.jp.clamav.net (IP: 219.106.242.51) Downloading daily-15461.cdiff [100%] Downloading daily-15462.cdiff [100%] Downloading daily-15463.cdiff [100%] Downloading daily-15464.cdiff [100%] Downloading daily-15465.cdiff [100%] Downloading daily-15466.cdiff [100%] Downloading daily-15467.cdiff [100%] Downloading daily-15468.cdiff [100%] Downloading daily-15469.cdiff [100%] Downloading daily-15470.cdiff [100%] Downloading daily-15471.cdiff [100%] Downloading daily-15472.cdiff [100%] daily.cld updated (version: 15472, sigs: 277314, f-level: 63, builder: ccordes) bytecode.cld is up to date (version: 190, sigs: 36, f-level: 63, builder: neo) Database updated (1321737 signatures) from db.jp.clamav.net (IP: 219.94.128.99) [/bash] 同様のエラーが出力される場合は、いちどClamAVで設定されているユーザーと、ログファイルディレクトリや定義ファイルディレクトリの所有権に齟齬がないかを確認してみてください。