移行するのは写真や大容量のファイルを保存するため使用していたサーバーです。2008年製のWindows Vista搭載パソコンをサーバーに改造して使っていましたが、もっと起動を速くしたいこと、データベースへのアクセスが遅くNextcloudの同期に時間がかかるため、使っていなかったSSD（Crucial BX500 120GB）に移行します。

• OS：CentOS 7.4
• メモリ：2GB DDR2-800 dual channel
• OS用ストレージ：HDD320GB（2008年製 HITACHI HDP72503 320GB）
  →Crucial BX500 120GBに移行します
• ストレージ（メイン）：WD Blue 4TB
• ストレージ（バックアップ）：WD Blue 4TB

あらかじめOSのバックアップは取っておきましょう。また、作業前にデータ用ディスクは取り外しておきます。

ファイルシステムの構成を考える

既存のファイルシステムは以下の通りです。

#parted -l
モデル: ATA Hitachi HDP72503 (scsi)
ディスク /dev/sda: 320GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
ディスクフラグ:

番号  開始    終了    サイズ  タイプ   ファイルシステム  フラグ
 1    1049kB  31.5GB  31.5GB  primary  ext4              boot
 4    31.5GB  250GB   218GB   primary  ext4
 2    250GB   270GB   20.0GB  primary  ext4
 3    270GB   271GB   1023MB  primary  linux-swap(v1)

#df -Th
ファイルシス   タイプ   サイズ  使用  残り 使用% マウント位置
/dev/sda1      ext4        29G   15G   13G   55% /
devtmpfs       devtmpfs   900M     0  900M    0% /dev
tmpfs          tmpfs      915M     0  915M    0% /dev/shm
tmpfs          tmpfs      915M  9.0M  906M    1% /run
tmpfs          tmpfs      915M     0  915M    0% /sys/fs/cgroup
/dev/sda2      ext4        19G  3.4G   14G   20% /home
/dev/sdc1      ext4       3.6T  2.8T  866G   77% /sambadata
tmpfs          tmpfs      183M     0  183M    0% /run/user/0
/dev/sda4      ext4       200G   85G  105G   45% /mnt/sd
tmpfs          tmpfs      183M     0  183M    0% /run/user/1001

Linuxを触り始めたばかりの頃に適当に自作したため、めちゃくちゃなパーティション構成になっています。今回のSSD以降を機にもっと拡張性に優れた構成に変更したいと思います。

上記の表のような構成にすることにしました。既存の構成では/home用のパーティンションを作っていましたが、廃止して/に統合します。swapは必要なさそうでしたが、一応作っておくことにしました。

新しいSSDにパーティションをつくる

SSDを取り付けてサーバーを起動します。誤操作によるデータ損失を防ぐため、データ用など不要なディスクは外しておきましょう。

ディスクのパスを確認します。

lsblk
parted -l

既存のOSディスクが/dev/sda、SSDが/dev/sdbであることが確認できました。

partedでパーティションを操作します。Enterキーを押すごとに変更が反映されていくため注意しましょう。

まず、GPTラベルを付与します。

parted /dev/sdb --script mklabel gpt

次にパーティションを作成します。

parted /dev/sdb
mkpart primary 1MiB 2MiB
set 1 bios_grub on

mkpart primary ext4 2MiB 1026MiB
mkpart primary ext4 1026MiB 110GB
mkpart primary linux-swap 110GB 100%
quit

ファイルシステムを作成します。

mkfs.ext4 /dev/sdb2
mkfs.ext4 /dev/sdb3
mkswap /dev/sdb4

SSDにデータをコピーしていく

マウント先のディレクトリを作成し、SSDをマウントします。

mkdir -p /mnt/newroot
mount /dev/sdb3 /mnt/newroot

mkdir -p /mnt/newroot/boot
mount /dev/sdb2 /mnt/newroot/boot

rsyncでコピーします。

rsync -aHAXv --exclude={"/proc/*","/sys/*","/dev/*","/run/*","/tmp/*","/mnt/*","/media/*","/lost+found"} / /mnt/newroot

fstabの変更

新しいSSDに対して、fstabを変更したりブートローダーをインストールしたりします。

chrootしておきます。

mount --bind /dev /mnt/newroot/dev
mount --bind /proc /mnt/newroot/proc
mount --bind /sys /mnt/newroot/sys
mount --bind /run /mnt/newroot/run

chroot /mnt/newroot /bin/bash

ディスクのUUIDをチェック。

blkid
 #SSDのUUIDを確認

/etc/fstabを編集。

vi /etc/fstab

UUID=<UUID_boot>  /boot    ext4  defaults  1 2
UUID=<UUID_root>  /        ext4  defaults  1 1
UUID=<UUID_swap>  swap     swap  defaults  0 0

ブートローダ（GRUB2）のインストール

grub2-install /dev/sdb
grub2-mkconfig -o /boot/grub2/grub.cfg

サーバーの再起動

chrootから抜けます。

exit
umount -R /mnt/newroot

サーバーをシャットダウンします。

shutdown -h now

HDDを取り外し、正常に起動することを確認しましょう。

まとめ

無事にSSDへの移行が完了しました。

体感速度は大幅に向上。これまで30秒ほどかかっていた起動時間が10秒ほどに短縮されました。Nextcloudの同期も爆速になり快適です。

どちらもWordPressで運用しているのですが、月に1～2回は突然「データベース接続エラー」が発生し、サイトが落ちてしまいます。

今回はこの問題の原因と解決法をご紹介します。

原因：メモリ不足によるMySQL（MariaDB）のダウン

ほとんどの場合、「メモリ不足によるMySQL（MariaDB）のダウン」が原因です。

サーバーのコンソールでデータベースの稼働状況を確認しましょう。動作が停止していることが確認できると思います。

LinuxにはOOM-Killer（Out-of-memory Killer）という機能が搭載されており、メモリが不足すると、メモリを多く消費しているプロセスから強制終了を行います。

MySQLはメモリ消費が大きいほうなので、Webサイトへのアクセスが集中するなどしてメモリ不足が起こると、まずもってMySQLもkillされてしまいます。

結果的にデータベースにアクセスできない＝「データベース接続エラー」が発生するというわけです。

対策：メモリを増やす＋OOM-Killerの監視対象から外す

対策は次の2つです。

• メモリを増やす
• OOM-Killerの対象から外す

メモリを増やす

一番かんたんなのはメモリを増やすことです。

メモリに余裕があれば、OOM-Killerも発動しなくなり、サーバーの動作にも余裕が出ます。普段から空きメモリに余裕がない場合はメモリを追加したほうがいいでしょう。

OOM-Killerの監視対象から除外する

一方で、Webサーバーのメモリ使用率は、アクセス状況によって大きく変動します。

どんなにメモリを増やしたところで、アクセスが集中したときにメモリ使用量が瞬間的に増加し、OOM-Killerが発動する可能性は完全には排除できません。

そこで、OOM-Killerの対象からMySQLを外すことにします。

サービスの定義ファイルでOOMScoreAdjustという数値を設定すると、OOM-Killerの監視対象から除外することができます。MySQL（MariaDB）のサービス定義ファイルを編集し、OOM-Killerの監視から除外します。

# systemctl edit mariadb.service

エディタが開くので、以下を追加します。

[Service]
OOMScoreAdjust=-1000

セーブしてmysqlを再起動します。

# systemctl restart mariadb.service

これにより、どんなに空きメモリに余裕がなくなっても、MySQLはkillされなくなります。

まとめ

今回はWordPressのデータベース接続エラーの解決法についてご紹介しました。

「ちゃんと稼働できていたのに、ある日突然データベース接続エラーが出てしまう」というケースでは、ほとんどがメモリ不足によるMySQLのダウンが原因です。

メモリ増設に加え、OOM-Killerの設定を調整することで、意図しないデータベースのダウンを避けることができますよ。

ベーシック認証のような簡易的なものではなく、任意のプログラムでアクセス許可・拒否を実現できるようにします♪

auth_requestモジュールを使った認証システム

Nginxのauth_requestモジュールを活用すると、任意のプログラムでアクセス許可を制御することができます。

auth_requestを使うと、本番のアクセス前に外部のHTTPサーバーに認証リクエスト（サブリクエスト）を送り、アクセスを許可して良いか確認してくれます。許可が得られた場合のみ、リバースプロキシを介したアクセスを通してくれるようになります。

具体的な処理の流れは以下の通りです。

1. クライアントのリクエストがNginxに到達する。
2. Nginxから認証サーバーに向けてGETアクセスが飛ぶ（サブリクエスト）
   • 指定された認証サーバーのパスに対して「アクセス許可していいですか？」というGETアクセスを行います。（これを”サブリクエスト”という）
3. 認証サーバーがリクエストを処理。
   • 認証サーバーはリクエストを受け取り、クライアントが認証されているかどうかを判断します。
4. 認証サーバーの応答に基づいてアクセスが許可または拒否される。
   • 認証サーバーがステータスコード200を返した場合は、Nginxは元のリクエストを処理し、設定通りにリバースプロキシします。
   • 認証サーバーがステータスコード200以外を返した場合は、Nginxはアクセスを拒否し、エラーページを返します。

auth_requestモジュールを使用することで、Nginxに組み込まれた認証を使用する代わりに、外部の認証サーバーを利用してリクエストを検証できます。認証に失敗したときは、任意のログインページにリダイレクトさせることもできます。

OAuthと組み合わせたり、Google Authoricatorを導入したり、自由に認証をプログラムすることができるようになります。

auth_requestを使うメリット

NginxであればBASIC認証やDigest認証を使うことができますが、これらとは異なり、任意のフォームで認証ページを作ることができます。

ブラウザのパスワードマネージャーやTouchIDによるログインができるのも大きなメリットです！アクセシビリティが向上しますよ♪

また、auth_requestであれば任意の認証バックエンドと連携できますので、KeyCloackなどの認証専用アプリケーションと組み合わせたり、他の認証システムと組み合わせることも可能です。二段階認証も対応できますし、大規模なシステムや複雑なアクセスルールにも柔軟に対応できるようになります。

PHPでリバースプロキシ認証システムをつくる

さっそく構築していきましょう！まずは認証バックエンドを作成します。

今回はPHPでログインフォームをつくり、ログインに成功したときのみリバースプロキシを介したアクセスを許可するようにしてみます。

ログインされていない状態では、自動的にログインフォームに遷移し、ログインを促すようにします。

▼完成イメージ

認証サーバーをつくる

まずはPHPで簡易的な認証サーバーをつくります。

認証サーバーに求められることは次の通りです。

• 認証機能を持つこと
• Nginxのサブリクエストを処理するエンドポイントを用意する
• エンドポイントはログイン済みならステータスコード200を返す。ログインされていないならステータスコード200以外を返す。

KeyCloakなどの認証バックエンドを利用してもよいですが、今回は原理を理解するためにPHPで自作しました。

authディレクトリをつくり、上記のファイルを作成しました。

• login.php（ログインページ）
• index.php（ログイン後に表示されるページ。ログアウトボタンなどを配置）
• logout.php（ログアウトボタンを押すとここに飛んでログアウトする）
• check.php（サブリクエスト用のエンドポイント。ログイン状態ならステータスコード200を返す。）
• functions.php（各ファイルで使う関数はここにまとめて置いている）

基本的な作り方は一般的なPHPのログインフォームと同じです。check.phpについてはステータスコードだけ返せばOKなので、以下のようなコードで十分です。（全体のサンプルコード作れば良かったのですが、時間なくて。すいません）

<?php
    // セッション開始
    session_name("NGINXAUTH_SESSION_ID");
    @session_start();
    // ログインしていれば200を返す
    if (isset($_SESSION['username'])) {
        http_response_code(200);

        echo "200 ログインされています";
        exit;
    }else{
        http_response_code(401);
        echo "401 ログインが必要です";
        exit;
    }  
?>

PHPのサーバー機能を立ち上げて、作成したauthディレクトリをホスティングします。

$ php -S localhost:4001

今回はlocalhost:4001で認証サーバーをホスティングします。

Nginxで認証サーバーによるアクセス制限を設定する

Nginxの設定ファイルを編集し、認証サーバーによるアクセス制限を設定します。

例として、もともと以下のようなリバースプロキシの設定があったとします。

server{      
...略...  
        location /{
                proxy_pass http://hogehoge.com/;
        }
...以下略...
}

auth_requestの設定を追加していきます。太字部分が追加した箇所です。

server{      
...略...  
        location /{
                proxy_pass http://hogehoge.com/;
                auth_request     /auth/check;
                auth_request_set $auth_status $upstream_status;
                error_page 401 = @error401;
        }
//認証バックエンドへのリバースプロキシ設定
       location /auth/ {
                proxy_pass http://localhost:4001/;
                auth_request     off;
                auth_request_set $auth_status $upstream_status;
        }
//サブリクエストを処理するエンドポイントへのリバースプロキシ設定
        location = /auth/check {
                internal;
                proxy_pass_request_body off;
                proxy_set_header Content-Length "";
                proxy_set_header Host $http_host;
                proxy_pass            http://localhost:4001/check.php;
        }
//アクセス拒否されたとき（未ログイン時）にログインページに飛ばす設定
        location @error401 {
                return 302 /auth/login.php?redirect_to=$request_uri;
　　　　　　　　//↑【補足】アクセス時のURIをクエリパラメータで渡しておくと、ログイン後にリダイレクトさせたりしやすいゾ
        }
...以下略...
}

解説

このままだとわかりにくいので、動作の流れを解説しておきます。

上記の設定で最初にNginxにアクセスがあったときの流れは以下の通りです。複雑なので少しクドめに解説します。

1. Nginxの/にアクセスがあると、locationディレクティブ（/） の設定にもとづき、auth_requestが作動します。
2. auth_requestに/auth/checkが設定されているため、Nginxは/auth/checkにサブリクエストとしてGETを送信します。※なお、auth_request setの内容はお決まりとなっています。このままコピペしましょう。
3. 別のlocationディレクティブ（location = /auth/check）で/auth/checkのproxy_passがhttp://localhost:4001/check.phpに設定されているため、2.で発生したサブリクエストは、PHPで自作した認証バックエンドにリバースプロキシされます。※なお、proxy_pass以外の設定内容はお決まりとなっています。このままコピペしましょう。
4. アクセスを受けたcheck.phpはログイン状況を確認します。
   ログインされていれば200を返します。
   ログインされていなければ、401など200以外のステータスコードをNginxに返します。
5. Nginxはサブリクエスト先から返されたステータスコードを判別します。
   200ならばアクセスを許可します。location/ディレクティブで設定されたproxy_passにリバースプロキシし、クライアントは正常にアクセスできます。これで完了です。
   返されたステータスコードが200以外ならば、エラーとみなされアクセスは拒否されます。同時に指定したエラーコードがクライアントに返されます。ここでは401エラーを返しています。
6. アクセス拒否された場合はlocation @error401ディレクティブにより、401エラーが処理されます。returnによりログインページへのリダイレクトを設定しているため、クライアントはログインページ（/auth/login.php）に誘導されます。/authはアクセス制限を設けていないため、未ログインの状態でもアクセスできますから、問題なくログインページが表示されます。
7. login.phpからユーザーがログインします。POSTが/auth/login.phpに送られますが、/auth以下はアクセス制限していないため、ログインできます。
8. ログインに成功したら、再度ブラウザから/にアクセスします。
   再びサブリクエストがcheck.phpに行われますが、今度はログインが完了しているため200が返され、アクセスが許可されます。

サブリクエストはすべてのアクセスにつき行われます。

auth_requestを設定したlocationに該当するのならば、画像ファイルなどのアセット含め、すべてのアクセスにサブリクエストが生じます。アクセス数が多い場合は、認証バックエンドへの負担を減らす工夫が必要になりそうです。

auth_requestサブリクエストに任意の値を渡すには？

auth_requestで指定したチェックポイントに任意の値（ヘッダー）を渡すには、proxy_set_headerを使用します。

例えば、以下はアクセス元のURIを認証バックエンドに渡します。

    location = /auth/check {
        internal;
        proxy_pass http://localhost/auth/check.php;
        proxy_set_header Host $host;
        proxy_set_header X-Original-URI $request_uri; # 元のリクエストURIを送信
    }

/auth/checkで渡されたヘッダーを取得するには、以下のようにします。

<?php
$_SERVER['HTTP_X_ORIGINAL_URI']

例として、アクセスされたURIを判定してみます。

function startsWith($haystack, $needle)
{
    return $needle === "" || strpos($haystack, $needle) === 0;
}

if (

// /ok1と/ok2から始まるURIだけ許可する
    startsWith($_SERVER['HTTP_X_ORIGINAL_URI'], '/ok1') ||
    startsWith($_SERVER['HTTP_X_ORIGINAL_URI'], '/ok2')
) {
    http_response_code(200);
    echo "200 ログインされています";
    exit;
} else {
    http_response_code(403);
    echo "403 アクセス制限されています";
    exit;
}

上の例では、/ok1と/ok2にアクセスされた場合のみ許可します。それ以外のURIでアクセスされた場合は403エラーを返し、アクセスを拒否します。

まとめ

いかがでしたか？

今回はauth_requestを使った認証リバースプロキシの構築方法について解説しました。

実際に我が家の自宅サーバーで運用していますが、非常に快適です。IPアドレスやパスに応じた詳細なアクセス制限もかけられますし、BASIC認証と異なりブラウザのパスワードマネージャーにID・パスワードを記憶させることもできます。

認証以外の部分も自由に実装できるので、ログインされたらLINE Notifyに通知するなどといったことも可能です。さまざまな場で活躍してくれると思います。

不明点ありましたらコメントでご質問ください。

Apache Guacamoleはサーバーとクライアントの2つに分かれています。

• Apache Guacamoleサーバー：実際のリモート接続を担当する
• Apache Guacamoleクライアント：WebGUIを提供する（Apache Tomcatで動作します）

順にインストールしていきます。個人的メモなのでちょっと雑な記事となりますm(..)m

Apache Guacamoleサーバーのインストール

ドキュメントをみながらインストールしていきます。

Apache Guacamole Manual — Apache Guacamole Manual v1.6.0

guacamole.apache.org

公式サイトからサーバーのファイルをダウンロードします。

Apache Guacamole®: 1.5.5

guacamole.apache.org

https://apache.org/dyn/closer.lua/guacamole/1.5.5/source/guacamole-client-1.5.5.tar.gz?action=download

コンソールで解凍し、インストールを実行します。

自分は/usr/local/guacamole-serverに配置しました。

# configureしてみる
./configure --with-init-dir=/etc/init.d

# 依存関係をインストールしていく
apt install libcairo2-dev
apt install libjpeg62-turbo-dev
apt install libtool-bin
apt install uuid-dev
apt install libossp-uuid-dev
apt install libvncclient1
apt update


apt install freerdp2-dev
apt install libpango1.0-dev
apt install libssh2-1-dev
apt install libtelnet-dev
apt install libvncserver-dev
apt install libwebsockets-dev

apt install libpulse-dev
apt install libssl-dev
apt install libvorbis-dev
apt install libwebp-dev
apt install libguac-dev

# 依存関係をインストールしたらconfigure
./configure --with-init-dir=/etc/init.d

# makeしてビルドする
make
make install

必要な依存ライブラリは以下のドキュメントを参照してください。

Installing Guacamole natively — Apache Guacamole Manual v1.5.5

guacamole.apache.org

Apache Guacamoleサーバーの起動

systemctl start guacd

initファイルは自動的に生成され、systemctlコマンドで起動することができるようになっています。

Apache Guacamoleクライアントサーバーのインストール

こちらに従いJavaとTomcat9(※10は非対応です）をインストール。

How to Install Apache Tomcat on Debian 11

Learn how to install Apache Tomcat on Debian 11 with our step-by-step guide. Get started with Java web development today...

www.rosehosting.com

Apache Guacamole公式サイトからクライアントのファイルをダウンロードします。

Javaなので自前でコンパイルする必要はありません。warファイルをダウンロードしちゃいます。

https://apache.org/dyn/closer.lua/guacamole/1.5.5/binary/guacamole-1.5.5.war?action=download

Tomcatのwebappフォルダに配置しましょう。自動的にコンパイルが走ります。

MySQLを利用できるようにする

ドキュメントに従ってセットアップしましょう。

Database authentication — Apache Guacamole Manual v1.5.5

guacamole.apache.org

データベースと初期テーブルを作成します。やり方は上記ドキュメントを参照してください。

ダウンロードしたExtentionとJDBC driverを配置します。

• extensionは/etc/guacamole/extensionsに配置します
• jdbcドライバーは/etc/guacamole/libに配置します

ドキュメントには$GUACAMOLE_HOME/extensionsなどと記載されています。

$GUACAMOLE_HOMEはデフォルトで/etc/guacamoleがセットされます。つまり、特段の変更をしない限り、配置先は/etc/guacamole以下となります。（Guacamoleのインストール先ディレクトリではないので注意です！）

Nginxでリバースプロキシを立てる

必要に応じてリバースプロキシもセットアップしましょう。Nginxの設定サンプルは以下の通り。

location /guacd/ {
        proxy_pass http://localhost:8070/guacd/;//ここは環境に合わせて変更を。
        proxy_buffering off;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_connection;
        access_log off;
}

動作を快適にするため、上記の設定項目は入れたほうがいいです。bufferingは必ず切りましょう。遅延の原因となります。

起動する

以上でセットアップは完了です。

systemctl restart guacd
systemctl restart tomcat

初期ID・パスワードはguacadminです。

実際に使ってみてですが、とっても便利です。モバイル回線でも遅延が少なく快適に使えています。

MT4を初めとするFX自動売買ツールを稼動させるのに大変有用なサービスとなっています。さらに半額キャッシュバックキャンペーンも行われており、大変おトクに申し込むことができます。

XserverクラウドPCとは？

XserverクラウドPCとは、データセンター上に自分のPCを借りることができるサービスです。

FXをやっていると、自動売買ソフトを24時間稼働させたい！というときが出てきますよね。

そんな方におすすめなのが「XserverクラウドPC」です！

XserverクラウドPCとは、データセンターにあるパソコンを借りることができるサービスです。

24時間365日、つねに立ち上げっぱなしにして、ソフトウェアを起動させておくことが可能ですので、FXの自動売買を昼夜問わず動かすことができます。

今なら半額キャッシュバックキャンペーン実施中！XserverクラウドPCの詳細はこちら

XserverクラウドPCを使う3つのメリット

XserverクラウドPCを使うメリットをご紹介していきます。

①低コスト：24時間稼動させても月額2,860円！

自宅のパソコンで稼働させることもできますが、電気代がかかります。どれくらいのコストがかかるでしょうか。一般的なノートパソコン（消費電力30W）と仮定して試算してみました。

月の電気代はなんと9,618円。これにパソコン本体代を加えるとかなりのコストになります。

24時間稼働させれば、稼働時間が長い分、当然利益をあげる確率も上がりますが、1万円近いコストがかかってしまっては、利益を出すのはとたんに難しくなります。

でもXserverクラウドPCなら、月々たったの2,860円で自分専用の24h稼働できるPCが手に入ります。

今なら半額キャッシュバックキャンペーン実施中！申し込みは下のバナーから

半額キャッシュバックキャンペーン実施中。下のバナーから申し込むと、お試しプランが実質月額1,430円で申し込めます。

XserverクラウドPCに申し込む（半額キャンペーン）

②メンテナンスはすべておまかせ：24時間365日の有人監視

XserverクラウドPCの本体は、有人監視のデータセンターで監視・運用されています。

監視システムのほか、エンジニアが常駐しているため、万が一データセンターにトラブルが起こった場合でも、いち早く対応してくれます。

その他、システムメンテナンスやハードウェアの管理も専門家がきっちり行ってくれますので、安心して運用を続けることができます。

自宅にパソコンを用意した場合は、自分でパソコンの管理もしなくてはなりません。

メンテナンスも含めて、月額1,430円ならかなり安いですよね！

③リモートアクセス：いつでもどこでも自分のFX環境にアクセスできる

XserverクラウドPCは、リモートアクセスに対応しています。

PCやスマホ・タブレットのWebブラウザだけで、いつでもどこからでもXserverクラウドPCにアクセスできます。FX自動売買の動作状況やその日の収益など、時間・場所を問わず確認することができます。

もちろんセキュリティも配慮されており、認証にクリアしないと、自分の環境にアクセスすることはできないようになっています。

まとめ：キャッシュバック実施中！おトクに申し込もう！

いかがでしたか？

今回はFX自動売買にぴったりなサービス「XserverクラウドPC」について紹介しました。

現在、XserverクラウドPCでは、半額キャッシュバックキャンペーンを実施しています！

お試しプラン 通常2,860円/月のところ、今なら実質半額の月1,430円でXserverクラウドPCを利用できますので、この機会にぜひお申し込みください！

▼▼半額キャッシュバックキャンペーンの申し込みはこちら▼▼

XserverクラウドPCに申し込む（半額キャンペーン）

XserverクラウドPCは仮想デスクトップサービス（VDI）というものですが、個人用途でもとても便利なサービスとなっています。

筆者は自作の仮想デスクトップサーバーを自宅に構築しています。

Xサーバークラウドのほうがメリットが大きいため、今後はXサーバークラウドに移行しようかと思っています。

XserverクラウドPCのなにがよいのか、”そもそも仮想デスクトップサービス（VDI）って何？”といったギモンから解説していきたいと思います。

▼▼▼Xserver クラウドPCのお申し込みはこちらから▼▼▼

仮想デスクトップサービス（クラウドPC）とは？

仮想デスクトップ（クラウドPC）とは、ネットワーク経由で利用できるパソコンのことをいいます。

ふつうのパソコンは、本体にディスプレイ・キーボード・マウスを直接つなぎますよね。

仮想デスクトップ（クラウドPC）では、データセンターにある高性能パソコンを借り、手持ちのPCやタブレット、スマートフォンからリモートで操作を行うことができます。

ノートパソコンやスマホなどのモバイルデバイスが、移動式のディスプレイ・キーボード・マウスになり、世界中のどこからでも自分の環境にアクセスできるようになるわけです。

仮想デスクトップサービスを使うメリット

「それならノートパソコンを持ち歩けばいいのでは？」

という声も聞こえてきそうですね。

仮想デスクトップサービス（クラウドPC）のメリットは主に3つあります。

• スマートフォンやタブレットでもWindowsを利用できる
• ワークステーション並みの高性能なPC環境をどこからでも利用できる
• データを持ち歩かなくて済むので、セキュリティ的に良い

まず、スマートフォンやタブレットでWindowsを利用できるようになります。

外出先や急な用件でどうしてもパソコンが使いたいときって意外とありますよね。

最近はアプリも充実していて、スマホでできることも増えていますが、それでも仕事となると話は別です。

「Windowsにしか対応していない会社の業務システムに外出先からアクセスしたい！」

といったときでも、仮想デスクトップ（クラウドPC）があればスマホからリモートアクセスすればOK！

スマホやタブレットで利用できる専用の無料アプリを導入するだけで、自分のWindows環境にアクセスできます。万が一のときのために、いちいち重いノートパソコンを持ち歩かなくてもいいんです。

高性能デスクトップパソコンを持ち歩ける！

高性能なパソコン環境を外出先で利用できるのも仮想デスクトップ（クラウドPC）の大きなメリットです。

個人用途ではこれが最大のメリットといえます。

例えば、写真編集や動画編集をする方。要求スペックの高いアプリケーションを使おうとすると、どうしてもデスクトップパソコンじゃないと動かないことがあります。

最近ではゲーム・クリエーター向けノートパソコンという分野も開拓され、高性能なノートパソコンの選択肢もかなり増えました。しかし、どれも重く大きなものが多く、手軽に持ち出せるとはいえないのが現状です。

そんなときにもクラウドPCが役立ちます！

▼▼▼Xserver クラウドPCのお申し込みはこちらから▼▼▼

クラウドPCならデータセンター上の高性能パソコンを外出先でも利用することができます。

データセンターにある高性能PCで処理を行わせることができるため、動画編集でもAIでの機械学習でも、サクサク行えちゃいます。

クラウドPCなら情報漏洩を未然防止できる

また、強固なセキュリティも大きな特徴の一つです。

通常、パソコンのファイルはPC本体のハードディスクやSSDに保存されています。

ハードディスクやSSDといったデバイスはいとも簡単に解析可能です。端末を紛失し第三者の手に渡ってしまうと、容易にユーザーのデータにアクセスされてしまいます。

対してクラウドPCでは、ファイル・データはすべてデータセンター上にあるPC本体に保存されます。

クラウドPCにアクセスするためのノートパソコンやスマホには、データは保存されないため、万が一紛失・故障しても、情報の漏洩を防ぐことができます。

実は仮想デスクトップ（クラウドPC）は、省庁や大企業、強固なセキュリティが求められる医療・金融などの業界では昔から使われています。

クラウドPCなら端末の紛失や盗難時にもデータの流出を防ぐことができます。

クラウドPC・仮想デスクトップなら「XserverクラウドPC」がおすすめ！

いかがでしたか？

今回は仮想デスクトップ（クラウドPC）の特徴を解説してみました。

クラウドPCを使ってみたいという方は、XserverクラウドPCがおすすめです。お申し込みは下のバナーから！

▼▼▼Xserver クラウドPCのお申し込みはこちらから▼▼▼

当記事ではアフィリエイトリンクを導入しています。

また、タスクスケジューラで自動的にバックアップさせる方法もご紹介します。

仮想マシンをエクスポートするスクリプト

仮想マシンをエクスポートするPowerShellスクリプトがこちらです。

# エクスポートする仮想マシンの名前
$vmName = "仮想マシンの名前"

# エクスポート先の親フォルダパス
$exportParentPath = "バックアップ先のディレクトリ"

# 日付を取得してフォルダ名を作成
$dateSuffix = Get-Date -Format "yyyyMMdd"
$folderName = $vmName+"_"+$dateSuffix

# エクスポート先のフォルダパス
$exportPath = Join-Path -Path $exportParentPath -ChildPath $folderName
$exportPath

# Hyper-V モジュールのインポート
Import-Module Hyper-V

# フォルダが存在しない場合は作成
if (-not (Test-Path $exportPath -PathType Container)) {
    New-Item -Path $exportPath -ItemType Directory
}

# エクスポートコマンドの実行
Export-VM -Name $vmName -Path $exportPath

動作としては次のようになります。

• 指定したディレクトリに「仮想マシン名_日付」という名前のディレクトリを作成する
• 作成したディレクトリに仮想マシンのエクスポートを行う

エクスポートが終わると自動的に終了します。

タスクスケジューラで自動実行させる

タスクスケジューラで新しいタスクを作成し、「操作」タブからタスクを追加します。

• 操作：プログラムの開始
• プログラム：powershell.exe
• 引数の追加：-Command "スクリプトのパス"

OKをクリックして登録すればOKです。

基本的にデフォルトで大丈夫ですが、処理に時間がかかりすぎると強制終了されることがあります。

タイムアウトなど適宜調整してください。

古いバックアップを自動で削除するには？

古いバックアップファイルを削除するには、以下のスクリプトを追加します。

指定したディレクトリ内を検索し、更新日時が最も古いフォルダを削除します。

# 操作対象のディレクトリを指定
$targetDirectory = "バックアップ先のディレクトリ"

# ディレクトリ内のサブディレクトリを取得し、最も古いものを選択
$oldestDirectory = Get-ChildItem -Path $targetDirectory -Directory | Sort-Object LastWriteTime | Select-Object -First 1

if ($oldestDirectory -ne $null) {
    # 最も古いディレクトリを削除
    Remove-Item -Path $oldestDirectory.FullName -Recurse -Force
    Write-Host "最も古いディレクトリを削除しました: $($oldestDirectory.FullName)"
} else {
    Write-Host "ディレクトリが見つかりませんでした。"
}

バックアップするスクリプトの最後に追加するのが良いと思います。

バックアップ（VMのエクスポート）が何らかの原因で行われなかった場合、削除前にスクリプトが終了されるため、「気がついたらバックアップが消えていた」なんて事態を防ぐことができます。

【STEP1】基本の確認

まずはもう一度、間違いやすいポイントを確認しておく。

• AllowOverrideはDirectoryセクションでのみ設定できる。LocationやFileなどほかのタグは不可。
• Directoryタグにはディレクトリのパスを指定する。
• AllowOverrideを設定する場合は、Directoryパスの指定にワイルドカードは使用できない。<Directory "/var/www/hoge/*">のようなタグの中で書いても設定は無効である。
• AllowOverrideはコアモジュールで動作するので、モジュールの有効化は不要である。

なお、スペルミスを疑うように促すサイトが多いですが、スペルミスが原因で設定が反映されていない可能性は低いです。理由は設定ファイルにスペルミスがあるとApacheの起動に失敗するから。Apacheが正常に起動できており、エラーが出てなければ、おそらく問題ない。

【STEP2】とりあえずすぐに直したいとき（姑息的手段）

急ぎで直したい方は、htaccessがあるパスのDirectoryタグを追加し、その中にAllowOverride Allと書いておけば、絶対動きます。

例えば、/var/www/html/hoge/.htaccessを効かせたいなら、apacheの設定ファイルに以下のように追記しておけばOK。

<Directory "/var/www/html/hoge">
    AllowOverride All
</Directory

これで絶対動きます。

これでも動かないならエラーログを参照しましょう。.htaccessやApacheの設定ファイルにエラーがあるはずです。

【STEP3】「でも、前はいちいちAllowOverride Allしなくても動いてくれたのに」というとき

まずはApacheの設定ファイルについて復習。

そもそも、Directoryタグの設定は親を継承する

例えば、/var/www/htmlのhtaccessについては、

①

<Directory "/var/www/html">

にAllowOverrideの記述があれば、それが反映される。

②なければ、

<Directory "/var/www">

にAllowOverrideの記述があれば、それが反映される。

③なければ

<Directory "/var">

にAllowOverrideの記述があれば、それが反映されます。

このように、Apacheでは親のDirectoryタグを辿りながら適用されていきます。

設定がなれければ？

最終的にAllowOverrideの設定が見つからなければどうなるのでしょうか？

最終的に何も記述が無ければ、Apache2.4の仕様により、AllowOverride Allが適用されます。

これはApacheのドキュメントに記載されています。

core – Apache HTTP サーバ バージョン 2.4

今まで動いていたのにhtaccessが効かなくなった・・・

つまり、AllowOverride Allを指定しないと.htaccessが効かない場合は、必ずどこか（親）にAllowOverrideを無効化する設定が書いてあります。

というわけで、Apacheの設定ファイルをくまなくさがしてみましょう。

Debianでは、/etc/apache2/apache2.confの最後にしれっと大本の設定が書いてある。

 # Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
        Options FollowSymLinks
        AllowOverride None
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

#<Directory /srv/>
#       Options Indexes FollowSymLinks
#       AllowOverride None
#       Require all granted
#</Directory>

デフォルトの設定ファイルでAllowOverrideが無効になっている。

このように、Debian11、Apache 2.4.54ではデフォルトでhtaccessが完全無効化されている。だから、htaccessを使う時は、ディレクトリごとにAllowOverrideを記述する必要があるのである。

対処法→/etc/apache2/apache2.confのAllowOverride NoneをAllに変えてやればOK。

これで一件落着となる。

【補足】上位のディレクトリのhtaccessが適応される

上位のディレクトリにhtaccessが存在していると、それ以下のディレクトリすべてに適用されます。

あるディレクトリが公開されている場合、そのディレクトリにhtaccessがなければ、一つ上のディレクトリにhtaccessがあるかチェックされます。htaccessが存在していれば適用され、なければさらに上のディレクトリがチェックされます。

なお、公開ディレクトリより上位のフォルダまで検索されていきます（ここが落とし穴です）。

公開ディレクトリよりさらに上のディレクトリにhtaccessがあり、それが適用されていた！というパターンもあり得ます。

AliasやVirtualDirectory、public_htmlを使用している場合も同様です。サーバー内に実際にファイルが配置されているディレクトリの構成がチェックされていき、上位のディレクトリにhtaccessがあれば、それが適用されます。

無効なURLです。
プログラム設定の反映待ちである可能性があります。
しばらく時間をおいて再度アクセスをお試しください。

このエラーの対処法をご紹介します。

対処法→とりあえず1時間待とう

上記のメッセージは、サーバーの準備が完了していないときに表示されるエラーです。

1時間ほど放置し、再度アクセスしてみましょう。

正常にページが表示されるはずです。

私の場合も１時間ほど放置し、リロードしたらページが表示されました。

待ってもダメなら、キャッシュを削除してみる

このエラーページはステータスコード200（エラーではなく正常に表示されているページとして）で返されているため、ブラウザにキャッシュされる可能性があります。

もし１時間（もしくはそれ以上）待ってもエラーが表示される場合は、キャッシュを削除してみましょう。

一度ブラウザでアクセスした後、Shiftキーを押しながらF5キーを押します。

すると、キャッシュなしでページが再読み込みされ、エラーが解消することがあります。

保存先を変更する

influxDBの設定ファイルを編集します。

vi /etc/influxdb/influxdb.conf

dataセクションにあるdirとwal-dirを変更します。

[data]
  # The directory where the TSM storage engine stores TSM files.
   dir = "/path/to/data"
   #dir = "/var/lib/influxdb/data"

  # The directory where the TSM storage engine stores WAL files.
  wal-dir = "/path/to/wal"
  #wal-dir = "/var/lib/influxdb/wal"

新しい保存先のディレクトリを作成

保存先とする新しいディレクトリを作成します。

sudo chown influxdb:influxdb -R /path/to/data
sudo chown influxdb:influxdb -R /path/to/wal

アクセス権も忘れずに設定しておきましょう。

sudo chown influxdb:influxdb -R /path/to/

influxDBを再起動

influxDBを再起動します。

sudo systemctl restart influxd

これで変更が反映されます。