動的IPとLet's EncryptでOwncloudをゼロから作成します。 千匹の象！*

私は長い間、ホームサーバーまたは500人までのユーザーがいる小さな会社でOwncloudを構築するための完全なチュートリアルを書きたいと思っていました。 Owncloudは素晴らしいオープンソースプロジェクトであり、あなたはあなた自身のインフラ上であなた自身のバージョンの同期サーバーを上げることができます。 その機能はDropboxに非常に似ていますが、いくつかの点でそれらを上回ります。 巨大なプラス-ストレージボリュームに対する制限の欠如、サーバーに対するフルコントロール。 マイナスも明らかです。あなた自身がこの不名誉をすべて守り、メザニンまたはクローゼットの中にあるサーバーの信頼性を心配する必要があります。



ごく最近、私はホームクラウド環境でOwncloudを展開するという課題に直面しました。 私は正直に2リットルのコーシャ・ロシア・インペリアル・スタウトを作成し、すべてをまとめて自分の経験を共有することにしました。 そこで、今日は次のことを見ていきます。

1. 現在のLEMPスタックの展開
2. Https。 自動証明書更新でNginxで暗号化しましょう
3. Owncloud用のNginxの構成
4. PHP apcuキャッシング
5. NFSを介して外部外部ストレージを接続する

スターターキット

サーバーのオペレーティングシステムはUbuntu 16.04.1 Server （ torrent ）です。 最適なオプションは仮想マシンです。 これは、移行の容易さ、リソース、スナップショット、およびその他の利点を動的に割り当てることができるため、非常に優れたソリューションです。 仮想マシンのサイズは10〜15 GBです。 これはシステムにとって十分以上です。



すべてのデータが保存される外部ストレージ （owncloudのデータディレクトリ）。 サイズ-ニーズに応じて。 100 GBのオプションを検討することをお勧めします。 ストレージとコアサーバーロジックを分離すると、構成の柔軟性が向上します。 この場合-システム用のSSDとデータ用のNASのHDD。 外部データパーティションを接続する場合、移行に関して柔軟性があり、突然必要になった場合に速度またはボリュームを増やすことができます。



ドメインと外部IPアドレス -無料のipv4アドレスの死にかけているプールの状況では、プロバイダーは白い外部アドレスだけを提供する可能性は低くなります。 灰色のアドレスがある場合、実行できることはほとんどありません。 VPNトンネルを白いIPでVPSに転送し、そこから踊りましょう。 ただし、プロバイダーは完全に白いアドレスを提供する場合がありますが、静的ではなく、動的です。 さらに、アドレスは左かかとの要請で簡単に変更でき、セッションは真夜中に中断し、加入者は新しいIPを受け取ります。 現在のケースでは、RouterOS v6.14以降、無料のダイナミックDNSを実行できるMikroTikルーターがあります。 この喜びはIP / Cloudセクションにあります。 機能を接続した後、ルーターは123456b7890f.sn.mynetname.netという形式のドメイン名を受け取ります。 このドメインは、プロバイダーが提供するipv4アドレスを常に指します。







ドメインは第4レベルを提供します。 レベル2を所有していない場合、通常のStartSSLおよび他の認証センターは機能しません。 以前は、これによりブラウザが呪われた自己署名証明書が使用されていました。 さて、Let's Encryptが登場し、問題を解決しました。



動的IPユーザーspectreobを使用した出版物ホームホスティングサイトで 詳しく説明されている代替オプションがあります。

LEMPを展開する

おそらく、最も使い慣れた作業用ユーティリティのインストールから始める価値があります：htop、iotop、iftop、mc。 次に、LEMP自体（Linux、Nginx（エンジンXと発音）、MySQL / MariaDB、およびPHP）に進みます。 すでにLinuxがあります。 Ubuntu 16.04はなぜDebianやCentOSではないのですか？ 私はrpmが好きではありません。Ubuntuでは、最新のソフトウェアバージョンを使用したリポジトリの点で簡単です。 バトルサーバーでの「make install」の練習は本当に好きではありません。 それでも、最善の方法はパッケージマネージャーを使用することです。 この原則を順守します。



UPD最初に、通常のsudo apt install nginxを作成して、新しいリポジトリに更新した後、すべての構成が通常の場所に残るようにします。



nginxの最新バージョンでリポジトリを追加します。 いくつかのバグと脆弱性がクローズされました。 Nginx開発者のGPGキーをコピーし、aptの新しいリポジトリソースを作成します。

wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key sudo nano /etc/apt/sources.list.d/nginx.list
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ubuntu 16.04 Xenialのリポジトリリンクをファイルに追加します。

deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx

deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx







nginxをインストールし、後で構成します。

 sudo apt-get update sudo apt-get install nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MariDB（MySQLの現在のフォーク）をデプロイし、サービスの保守性を確認します。

 sudo apt-get install mariadb-server mariadb-client sudo systemctl status mysql.service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

強化手順を実行し、テストベースとその他の潜在的なセキュリティホールを切断します。

 sudo mysql_secure_installation
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一連の質問に答える必要があるダイアログが開始されます。 同じダイアログで、rootのパスワードを設定します 。 後でowncloudのベースを作成するときに必要になります。



PHP7.0、php-fpm、およびowncloudが関連サービスと連携するために必要なモジュールをインストールします。

 sudo apt-get install php7.0 php7.0-mysql php7.0-fpm php7.0-gd php7.0-json php7.0-curl php7.0-zip php7.0-xml php7.0-mbstring
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Owncloudは環境変数を編集する必要もあります：

 sudo nano /etc/php/7.0/fpm/pool.d/www.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の行のコメントを解除します。

 env[HOSTNAME] = $HOSTNAME env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /tmp env[TMPDIR] = /tmp env[TEMP] = /tmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Let's Encryptを設定してNginxを設定します

Let's Encryptは、無料の自動化されたオープンな認証機関を提供する非営利団体です。 彼らに感謝します。 おそらく、本質的に評判を販売する認証センターは、現在、組織認証（OV）または拡張認証（EV）の高級証明書から主な利益を得ることを余儀なくされるでしょう。 このタイプの証明書は法人のみが利用でき、条件付きLLC Horns and Hoovesの存在を確認します。 同時に、ドメインの所有権、会社自体、公証されたドキュメント、その他のニュアンスがチェックされます。



個人使用の場合、Let's Encryptのドメイン検証証明書で十分です。 このオプションは基本的に、example.comドメインに接続しているという事実のみを確認します。 同時に、Man-in-the-Middle攻撃、ランディングページへのあらゆる種類のゴミの注入（MosMetro Wi-Fiとモバイルオペレーターに挨拶します）から私たちを保護し、パブリックネットワークを使用するときにパスワードを傍受します。 自分のOwncloudに最適です。 自己署名証明書を使用しないのはなぜですか？







Owncloudには、ファイルまたはディレクトリへのリンクを人に転送できる優れた「共有リンク」機能があります。 突然50 GBのデータを転送する必要がある場合に非常に便利です。より使い慣れたDropboxとGoogleドライブでは、これを無料で許可していません。 間違いなく、会計士オリンピアード・シギスムドヴナに、彼女のブラウザが赤く光っていて、 パキスタンのハッカーが無効な証明書のためにひどくクラックしたと叫ぶ理由を説明したくありません。 さらに、すべてが非常に簡単です。







Let's Encryptの主なアイデアは、90日間の短い有効期間で証明書を自動的に発行することです。 プロジェクトの作成者によると、これにより、侵害された証明書が流通から自動的に削除されるため、セキュリティが向上します。 ドメイン検証のために、サービスはいくつかのシナリオでcertbot-autoを提供します。

1. Apache -Apache 2.4の証明書を自動的に取得してインストールします。 ポート443を使用
2. Nginx - Nginxの証明書を自動的に取得してインストールします。 アルファ版 、早期生産。 ポート443を使用
3. webroot-アクティブなサーバーのルートディレクトリにドメイン検証に必要なファイルを作成します。 ポート80を使用
4. スタンドアロン -検証のために外部からの必要な要求に応答するスタンドアロンサーバーを起動します。 ポート80または443を使用します。 機能するWebサーバーを持たないシステムおよびその他の場合。
5. 手動 -手動コピーペーストが必要な完全手動モード。 ターゲットマシン上にないキーを生成するときに使用されます。 たとえば、ルーターの場合。

その結果、サーバーを完全に制御できない状況など、さまざまな使用シナリオに適した汎用セットが用意されています。 アルファステータスのため、Nginxでの証明書の自動インストールは使用しません。また、動作中のWebサーバーの構成の編集は非常に密接なプロセスです。 私は本当に、デバッグされたスクリプトの曲がった仕事に出会いたくありません。 それでも、証明書を取得するプロセスは自動化されています。



開始するには、certbotの最新バージョンをダウンロードしてインストールします。

 cd /usr/local/sbin sudo wget https://dl.eff.org/certbot-auto sudo chmod a+x /usr/local/sbin/certbot-auto
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginxの設定を編集し、webbot certbotオプションが書き込まれるディレクトリへのアクセスを許可します。

  sudo nano /etc/nginx/sites-available/default
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

行を追加します。

 location ~ /.well-known { allow all; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginxサービスの再起動：

 sudo service nginx restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、certbotを実行して、ドメインの証明書を生成できます。 特定のケースでは、これはMikrotik DDNSの4番目のレベルのドメインです。 3番目であっても、他の有効なブラウザ証明書はあなたに署名しません。 UPD ：デフォルトのwebrootパスを間違えました。 Ubuntu 16.04では、/ usr / share / nginx / htmlではなく、/ var / www / htmlです。 念のため、rootディレクティブの後に/ etc / nginx / sites-available / defaultに書かれている内容を確認してください。 たとえば、root / var / www / html;

 sudo certbot-auto certonly -a webroot --webroot-path=/var/www/html -d example.sn.mynetname.net
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダイアログボックスで、メールアドレスを入力し、使用条件に同意する必要があります。











Certbotは、現在のバージョンの証明書を/ etc / letsencrypt / live /ディレクトリに入れ、シンボリックリンクを作成します。 ファイルの中にあります：

• cert.pem：ドメインの証明書
• chain.pem：証明書を暗号化しましょう
• fullchain.pem：cert.pemおよびchain.pemからの結合された証明書
• privkey.pem：証明書の秘密鍵

Diffie-Hellmanキーを生成します。

 sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

素晴らしい。 Nginx構成で/ etc / letsencrypt / live /へのリンクを記述すると、常に現在のバージョンになります。 ドメインの新しい構成を作成します。

 sudo nano /etc/nginx/sites-available/example.sn.mynetname.net
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

owncloudマニュアルで推奨される最適化された既製の設定。 ポート80は自動的に443にリダイレクトします

構成ファイルはコメントを考慮して書き直されました 。 特にgrozamanに感謝します 。 現在、Windows XPおよび一部の古いシステムをサポートしないという代償を払って、セキュリティを改善しました。 Diffie-Hellmanキーも4096に増加しました。これにより、ハンドシェイク時間がわずかに長くなりますが、重要ではありません。 ただし、2048ビットを使用できます。 ssl_staplingといくつかの追加ヘッダーを追加して、セキュリティを強化しました。



この構成オプションを使用すると、サイトはhttps://www.ssllabs.comで A +をダイヤルします 。

また、この構成では、 https：//securityheaders.ioで Aグレードを取得します 。







もちろん、Java、Windows XPなどの古いバージョンとの互換性が必要な場合は、安全でない可能性のあるプロトコルを許可する必要があります。

証明書の更新を自動化する

--dry-runスイッチを使用して証明書の更新を確認します。これは更新をシミュレートしますが、実際には何も変更しません。

 sudo certbot-auto renew --dry-run
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドを実行すると、certbotはEFFサーバーに接続し、可能であればそのバージョンを更新してから、証明書を更新しようとします。 そして、利用可能なすべてのドメインだけではありません。 とても快適です。 証明書を変更する日付が合わなかった場合、何も起こりません。スクリプトはそれについて通知します。

 ------------------------------------------------------------------------------- Processing /etc/letsencrypt/renewal/example.sn.mynetname.net.conf ------------------------------------------------------------------------------- Cert not yet due for renewal The following certs are not due for renewal yet: /etc/letsencrypt/live/example.sn.mynetname.net/fullchain.pem (skipped) No renewals were attempted.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、通常のcrontabスクリプトの実行を追加できます。

 sudo crontab -e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

内部では、証明書を更新し、nginxにリロードする通常のタスクを追加します。

 30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log 35 2 * * 1 /etc/init.d/nginx reload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ウェブサイトをアクティベートします：

 sudo ln -s /etc/nginx/sites-available/418402b5554f.sn.mynetname.net /etc/nginx/sites-enabled/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Owncloudをインストールする

いくつかのオプションがありますが、ほとんどの場合、リポジトリからのインストールが最も好まれます。 パッケージマネージャーに更新に関する頭痛の種を任せましょう。 主なことは、新しいパッケージを展開する前にバックアップすることを忘れないことです。 時には不愉快な驚きがあります。 まず、GPGキーを追加する必要があります。

 wget -nv https://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/Release.key -O Release.key sudo apt-key add - < Release.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、リポジトリを追加し、owncloud-filesパッケージをインストールします。 通常のowncloudパッケージも依存関係に応じてApacheを引き付けますが、必要ありません。

 sudo sh -c "echo 'deb http://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/ /' > /etc/apt/sources.list.d/owncloud.list" sudo apt-get update sudo apt-get install owncloud-files
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、/ var / www / owncloudに必要なものがすべて揃います。 Nginxはルートディレクトリ/ var / wwwを考慮するため、サービスへのアクセスは次のようになります。example.com / owncloud

MariaDBをカスタマイズする

インストールが小さいので、最適化の細かい点には行きません。 したがって、多かれ少なかれデフォルトの構成でデプロイします。 ユーザー名とパスワードは、owncloudがデータベースへのアクセスに使用するものと置き換えます。

 sudo mysql -uroot -p create database owncloud; create user username@localhost identified by 'password'; grant all privileges on owncloud.* to username@localhost identified by 'password'; flush privileges; exit;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外部ストレージを接続します

先ほど言ったように、仮想マシンを、同期されたデータが格納されるサービスとストレージのまさにロジックと共有することをお勧めします。 ここで、必要に応じて既に実行できます。 何もできません。デフォルトのストレージは/ var / www / owncloud / dataになります。 私のように行動して、/ mnt / dataディレクトリを作成できます。このディレクトリに、外部ボリュームがfstabを介してマウントされます。 SSD / HDD、ローカルに配置、または同じローカルネットワークのNASストレージに配置できます。 結果のハイブリッドの速度のみをテストすることを忘れないでください。 これは潜在的なボトルネックです。 私のホームバージョンでは、これはホストマシン上のsambaサーバーです。誰かがNFSを好むかもしれません。



このようなハイブリッド設計の追加の利便性は、必要に応じてより高速な、またはより容量の大きいオプションに簡単に移行できることです。 サービスを停止し、新しい接続ボリューム上の古い/ mnt /データからすべてのファイルを入力し、fstabでマウントポイントを変更して、サービスを再起動するだけで十分です。 突然、古いHDDからSSD RAIDにデータを転送することに決めましたか？

キャッシング

重要なポイント。 メモリキャッシングがなければ、owncloudは非常に思慮深く機能します。 さらに、彼は管理ページでこれを確実に思い出させます。 キャッシュ方法の選択は、システムアーキテクチャによって異なります。 ここから開発者からの推奨事項を見つけることができます。 要するに、個人使用および小規模インストールにはAPCuのみが推奨されます。 小規模な組織の場合、単一サーバーにインストールする場合- ローカルキャッシュにはAPCu、ファイルロックにはRedis 。 大規模な組織のクラスターにインストールする場合： ローカルキャッシュを除くすべてのRedis 。



開発者は、APCuをローカルキャッシュの最速オプションと考えています。 十分なRAMがある場合は、ローカルキャッシュにAPCuを使用し、ファイルロックにRedisを使用することをお勧めします。 十分なメモリがない場合は、両方にRedisを使用することをお勧めします。



このバージョンでは、 APCuのみを使用します。 phpに適切なモジュールをインストールします。

 sudo apt-get install php-apcu
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらをowncloud設定ファイル-config.phpに追加するのはとても簡単です：

 'memcache.local' => '\OC\Memcache\APCu',
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの発案の最初の打ち上げ

すべてのサービスを再起動するために、マシンを再起動します。 example.com/owncloudに移動し 、管理者アカウント、パスワード、データディレクトリの場所（このガイドのように/ mnt / data）、データベースのowncloudユーザーからのユーザー名とパスワードを無差別にすべてのボタンに慎重に入力します。 すべてがうまくいった場合、すぐにサービスのメインメニューが起動し、すべての性交が順番に壊れていることを確認できます。

*千象

最後までこのシートを読んでくださった皆さんに感謝します。 私はすべての詳細を可能な限り完全に記述したかったので、多くの場合、相反するさまざまなソースを探し回る必要はありませんでした。 私はすべてを2回チェックしましたが、どこかでタイプミスや不正確な記述をした可能性があることを除外していません。 間違ってあなたの鼻を突くのは非常にありがたいです。

UPD

正しく指摘されたように、すべての開発者が逃げてきたNextcloudに切り替える必要があります。 私はかなり長い間このシステムに座っていたので、この点を見逃しました。

UPD2

grozamanユーザーが私に連絡し、暗号化の強度やその他の微妙な点に関連する最適でないnginx設定を指摘しました。 ここで追加のマニュアルを入手できます： NGINXに基づいたNextcloudのセットアップ

UPD3

certbot / letsencryptがリポジトリにあることを何度か指摘しましたが、個別にドラッグしても意味がありません。 Ubuntuの場合、これは次のとおりです。

 sudo apt-get install letsencrypt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UPD4

デフォルトのwebrootでエラーを修正し、構成ファイルを完成させました。