カテゴリーアーカイブ インフラ

著者:ym

やっぱり VMware 。VMware と Hyper-V 切り替え

昔ながらの BIOS マシンを使用しているので、以下のコマンドで切り替えられます。

VMware を使いたい場合

bcdedit /set hypervisorlaunchtype off
その後 OS 再起動


Hyper-V を使いたい場合

bcdedit /set hypervisorlaunchtype auto
その後 OS 再起動

HDD マシンだから再起動したら 30 分以上かかる。どうにかならんのか、これ。

  • この記事いいね! (0)
takahashi 著者:takahashi

PHPでMS SQL ServerをCygwinで使うべきではない理由

何故なら、公式のMSSQLドライバがCygwin用に提供されていないからです。

GitHubのMicrosoftの公式リポジトリでも、Cygwinはサポートしないとはっきりと明言されています。

Driver in cygwin enviroment #258 – GitHub

Transact SQL クライアントのオープンソースの実装であるFreeTDSについてはCygwinにもドライバがあるので、これを使えば”とりあえずは”Cygwin上のPHPからSQL Serverへ接続することはできます。

しかしFreeTDSではSQL文実行後一定時間経過しても結果が返ってこない場合、接続を切ってしまううえ、この仕様を修正するにはFreeTDSのソースを修正するしかない、という状況になっているようです。(調べて見つけた記事にそのようなことが書かれていたのですが、その記事のURLを見失ってしまいました…また見つけたら追記します。)

代替えとして、Windowsネイティブでありながら、基本的なLAMP環境を簡単に動作させることができるXAMPPというパッケージがあります

XAMPP

こちらなら、SQL Serverの公式PHPドライバが利用可能ですので、 個人的にはこちらを利用するのがおすすめです。

本当はUNIXライクなOSで動作させるのが一番なのですが、もしWindowsでどうしても…という方は一度検討してみてください。

  • この記事いいね! (0)
takahashi 著者:takahashi

MySQL 5.7で厳格になったパスワードポリシーを解除する方法

MySQLは5.7からrootパスワードがデフォルトで設定されていたりと、なにかと面倒な仕様変更が多いのですが、その流れで今回困ったことがあったのでご紹介したいと思います。

とりあえず、開発用のテスト環境としてセットアップをしたサーバーにMySQL5.7をセットアップし、エディタからSQLサーバーへアクセスできるようにするために、いつも通り外部からのアクセスが可能なユーザーを作成しようとしたのですが…

-- 実際にはもっと予想されにくい認証情報を指定しています。
GRANT ALL PRIVILEGES ON DBNAME.* TO user@'%' IDENTIFIED BY 'PASSWD123' WITH GRANT OPTION;
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

…はいでました、ポリシー違反(汗
MySQL5.6あたりまでは平気で設定できていたパスワードも、ものによっては5.7以降になると単純すぎるとはじかれます。

本番環境であれば十分に複雑で、かつ大文字や記号が入っているパスワードがベストなのはわかっていますが、開発中は手動で何度も接続しないといけない場合があるため、複雑なパスワードにしてしまうとちょっと困ります。(もちろんオフィス以外から接続できないようにするなどの別の対策はとってます。)

なんとか緩いパスワードを設定したいと探したところ、SQL上でパスワードポリシーを変更する方法を見つけました。

mysql5.7でパスワードを変更する – Qiita

MySQLのシェルに入った状態で、次のSQL文を入力します。

-- パスワードの最低文字数を4文字に変更
SET GLOBAL validate_password_length=4;
-- 要求するポリシーレベルを"LOW"に変更
SET GLOBAL validate_password_policy=LOW;

これで再度

GRANT ALL PRIVILEGES ON DBNAME.* TO user@'%' IDENTIFIED BY 'PASSWD123' WITH GRANT OPTION;

を実行してみると…

Query OK, 0 rows affected (0.00 sec)

無事成功しました。

MySQL 5.7から結構あちこち変更されているので、今までのノリで触っていると戸惑ってしまうような変更が結構ありますが、その仕様変更に当たっても、焦らずに一つ一つ解決していきたいですね。

  • この記事いいね! (0)
著者:ym

ロボットと人

Web サイトに対して突然大量のリクエストを投げつけてくるボット。検索エンジンのクローラ系もありますが、全く関係の無いボットもあります。

プロセスで CGI 特定したり、netstat -anl 結果から攻撃元を特定、 さらにはアクセスログと格闘していましたが、今更ですが今回は Apache の server-status 表示を”プログラム”で取得し、集計して判断をするようにしました。 これであれば、リクエスト URI や、常にポートを専有しているかの判断ができそう。

この Status モジュールによりサーバ管理者はサーバがどのくらい の性能で動作しているかを知ることができるようになります。 現時点でのサーバの統計情報を読みやすい形式で表した HTML ページが 表示されます。必要であれば、このページは自動的にリフレッシュさせる こともできます (互換性のあるブラウザを使用している場合)。 別に、現時点でのサーバの状態を単純な機械読み取り可能なリストで 表すページもあります。

https://httpd.apache.org/docs/2.4/ja/mod/mod_status.html

  • この記事いいね! (0)
takahashi 著者:takahashi

LaravelをNginxで動作させる際の設定

LaravelではどのURLを指定されても、(自分の担当するパス配下へのリクエストであれば)Laravel自身を起動させるために必ずpublic/index.phpを経由させる必要があります。

この設定はPHPだけでは限界があるため、Webサーバー側の設定で対応する必要があります。

Laravelのパッケージにはこの”index.phpを必ず経由させる”という設定が書かれた設定ファイルがデフォルトで含まれています。
具体的には

public/.htaccess

上記のファイルがこの設定ファイルにあたります。
ところが、この.htaccessファイルは基本的にApacheなどのごく一部のWebサーバーでしか認識しないので、たとえは先日の記事のようにnginxにPHPをインストールした環境で動作させようとしても、そのままではうまく動いてくれません。

この場合、.htaccessに書かれている設定と同様の働きになる設定をWebサーバーの設定ファイルに指定する必要が出てきます。
ただし、その記述の仕方もApacheとは異なってきますので、各Webサーバー用の書き方に書き換えないといけません。

nginxの場合、.htaccessの中身をnginx用の設定に書き換えてくれるWebサービスがあり、まず最初にこのサービスを使って変換した設定ファイルを使って設定を行ってみました。

元の.htaccess

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

上記サイトで変換後のnginxコンフィグ

# nginx configuration

location / {
  if (!-e $request_filename){
    rewrite ^(.*)$ /%1 redirect;
  }
  if (!-e $request_filename){
    rewrite ^(.*)$ /index.php break;
  }
}

実際に入れ込むと以下のようになります。

server {

  listen        80;
  listen        443 ssl;

  server_name  example.com;

  ssl_certificate       /path/to/ssl/fullchain.pem;
  ssl_certificate_key   /path/to/ssl/privkey.pem;

  root /path/to/docroot;
  client_max_body_size 1g;
  location / {
        if (!-e $request_filename){
                rewrite ^(.*)$ /%1 redirect;
        }
        if (!-e $request_filename){
                rewrite ^(.*)$ /index.php break;
        }      
        index index.php index.htm index.html;
  }
  location ~ \.php$ {
    if (!-e $request_filename){
        rewrite ^(.*)$ /%1 redirect;
    }
    if (!-e $request_filename){
        rewrite ^(.*)$ /index.php break;
    }
    fastcgi_pass   unix:/var/run/php-fpm.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
    allow all;
  }
}

ところが、上記のような設定を行ったところ、リダイレクトループに陥ってしまいます。

いろいろ調べたところ、Nginx向けのLaravel用の設定が公開されていました。

nginxをLaravel5.4用に設定する – Qiita

上記の記事を基に今回の場合の設定ファイルを書き換えてみます。

server{
   listen        80;
   listen        443 ssl;

   server_name  example.com;

   ssl_certificate       /path/to/ssl/fullchain.pem;
   ssl_certificate_key   /path/to/ssl/privkey.pem;

   root /path/to/docroot;

   location / {     
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/var/run/php-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

全然違うじゃん…

やはり、ただ設定を変換しただけではうまく行かないみたいですね。

参考元の記事ではLaravel5.4となっていましたが、5.6の環境でも同様の設定で問題なく動作しました。

Laravel + Nginxの構築でお困りの方の参考になれば幸いです。

  • この記事いいね! (0)
takahashi 著者:takahashi

AmazonLinux 2 + Nginx でPHPを使えるようにする方法

Nginxはリバースプロキシとしてかなり優秀なサーバーアプリケーションで、自分も愛用しているのですが、あくまでリバースプロキシとしてしか使っていませんでした。

しかし、Nginxの本来の役割はWebサーバーですので当然Nginx自身がアプリの動作環境になることも可能です。

今回機会があってAWS EC2上のNginxで直接アプリケーションを動かす必要が出てきたので、実際にセットアップしてみました。

NginxにはApacheのようにモジュールを組み込んでPHPを動作させるような仕組みがない為、CGIを利用して動作できるようにします。
ただ、通常のCGI版PHPだと重いので、Fast CGI版のPHPが利用できるphp-fpmを利用します。

今回はPHP7.1の環境をインストールします。

まずは必要なパッケージをインストールします。

#epelリポジトリをインストール
sudo yum -y install epel-release

#remi リポジトリをインストール
sudo yum -y install http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

#nginxをインストール
sudo yum -y install nginx

#php-fpm(php7.1)をインストール
sudo yum -y install --enablerepo=remi,remi-php71 --disablerepo=amzn2-core  php-fpm
#※--disablerepo=amzn2-coreしておかないと古いphp-fpmがインストールされます。

インストールが完了したら設定していきます。

sudo vi /etc/php-fpm.d/www.conf

次の項目を編集します。

;localから参照するのでUNIX SOCKETを設定。
- ;listen = 127.0.0.1:9000;
+ listen = /var/run/php-fpm.sock

;UNIX SOCKETファイルのユーザーとグループの指定(指定しないとrootとなるが、nginxからアクセスできなくなる。)
- ;listen.owner = nobody
- ;listen.group = nobody
+ listen.owner = nginx
+ listen.group = nginx

Nginx側も設定を変更します。
Nginxでは各バーチャルホストごとの設定を定義するserverセクションに記述します。

server {

  listen        80;
  listen        443 ssl;

  server_name  example.com;

  ssl_certificate       /path/to/ssl/fullchain.pem;
  ssl_certificate_key   /path/to/ssl/privkey.pem;

  client_max_body_size 1g;
  location / {
        root /path/to/docroot;
        index index.php index.html index.htm;
        allow all;
  }
  location ~ \.php$ {
    root           /path/to/docroot;
    fastcgi_pass   unix:/var/run/php-fpm.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;
    allow all;
  }
}

基本的には上記のような設定でOKです。

設定が完了したらphp-fpmとnginxを再起動します。

sudo systemctl start php-fpm nginx
sudo systemctl enable php-fpm nginx

あとはおなじみのphpinfo();をドキュメントルートに置いて、phpが実行されているか確認します。

vi /path/to/docroot/phpinfo.php
<?php
    phpinfo();
?>

あとは

http://example.com/phpinfo.php

のようにして、phpの環境情報が表示されれば成功です。

  • この記事いいね! (0)
著者:ym

無線ネットワークの遅延をグラフ化

ネットワークのトラヒックをグラフ化することはよくありますが、遅延具合をグラフ化することはあまりないかもしれません。

今回は、無線LANと、有線LANで、どの程度の違いがあるか視覚化してみました。

3つのグラフが無線LAN。で最後が有線LANです。

無線LANが、1.2~1.6ミリ秒単位をふらついているのに対して、有線LANは、650~750マイクロ秒前後。

いくら無線LANのセンス速度、リンク速度が早くても、有線LANにはかないません。

数ミリ秒だったとしても、100以上などのコンテンツを取得する倍は遅延も100倍になります。今どき・・・、だけど、やはり有線LANだよなと感じるグラフです。

  • この記事いいね! (0)
takahashi 著者:takahashi

Ubuntuで最新カーネルにアップグレードするとVirtualBoxが動作しなくなった件

ふと社内のUbuntu 16.04で動作しているテストサーバーを再起動したところ…

仮想マシンが立ち上がらなくなってました。
最悪です…

このエラーメッセージが出てくる前に

sudo /sbin/vboxconfig

を実行すれば修復できる旨のメッセージが表示されたので実行しましたが、

# '/sbin/vboxconfig'
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.

となり、/var/log/vbox-setup.log を確認すると vboxdrv のビルドに失敗した、というメッセージ(コンパイルエラー)が出てました。

まずこのエラーで調べたところ、現在実行中のカーネルのカーネルへッダーが足りていないという情報を発見。

Ubuntu上でのVirtualBoxで仮想マシンを立ち上げようとしたときに Kernel driver not installed (rc=-1908) のエラーが出た場合の対処方法 – K-Lab

そういえばカーネルモジュール作るのにカーネルヘッダ必要だったなーと思い

sudo apt update
sudo apt install linux-headers-$(uname -r)

を実行しましたが、

# sudo apt install linux-headers-$(uname -r)
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています                
状態情報を読み取っています... 完了
linux-headers-4.4.0-143-generic はすでに最新バージョン (4.4.0-143.169) です。
linux-headers-4.4.0-143-generic は手動でインストールしたと設定されました。
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
...
これを削除するには 'sudo apt autoremove' を利用してください。
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 18 個。

あれ…既に入ってる…

もう一度

sudo /sbin/vboxconfig

を実行してみるも当然通るはずもなく…

半分パニックになりながらいろいろ調べていたところ、Ubuntuのコミュニティサイト”Ask Ubuntu”の英語の記事でようやく有効な情報にたどり着きました。

VirtualBox error after last (Ubuntu) Software Update – Ask Ubuntu

どうやら、Ubuntu 16.04 に提供されている最新のカーネルをインストールすると、Virtualbox側が対応できていないためカーネルモジュールのビルドに失敗する…ということだそうです。マジかよ…

記事では VirtualBox 5.2.26でエラーが出たと書かれていますが、手元の環境では現時点で最新版の 6.0.4でも全く同じエラーが出ていたので、現時点でもまだ直っていないようです。

手元の環境ではカーネルバージョン 4.4.0-143 でエラーになっていましたが、記事によるとカーネルバージョン 4.4.0-138 であればVBoxがエラーにならず、かつ不具合等も出ず安定しているとのことだったので、このバージョンのカーネルより新しいものをすべて削除してしまうのが今回の解決策になりそうです。

とりあえず下記のコマンドを打ってカーネルをダウングレードします。
なお今回はOSの動作に必要なカーネルをいったんすべて削除するという大変リスキーな作業が含まれますので、十分注意してください。

※作業が完了するまで、絶対にOSを再起動しないでください。
カーネルのダウングレードを完了する前に再起動すると、最悪OSが起動しなくなります。

#問題を起こす新しいバージョンのLinuxカーネルを全て削除(この処理を行ったら必ず最後の処理まで完了させてください。さもないとOSが起動しなくなります。4.4.0-143よりも新しいカーネルがインストールされていれば、適宣削除対象に追加します。)
sudo apt-get purge linux-image-generic linux-headers-generic
sudo apt-get purge linux-image-4.4.0-139-generic linux-headers-4.4.0-139-generic \
linux-image-4.4.0-140-generic linux-headers-4.4.0-140-generic \
linux-image-4.4.0-141-generic linux-headers-4.4.0-141-generic \
linux-image-4.4.0-142-generic linux-headers-4.4.0-142-generic \
linux-image-4.4.0-143-generic linux-headers-4.4.0-143-generic
#上記コマンド実行中に現在実行中のカーネルを削除しようとしている旨のメッセージが出ますが、はい を選択して削除してください。

#残骸のパッケージを削除
sudo apt-get autoremove

#問題を引き起こさない古いカーネルをインストール(ダウングレード)
sudo apt-get install linux-image-4.4.0-138-generic linux-image-extra-4.4.0-138-generic
sudo apt-get install linux-headers-4.4.0-138 linux-headers-4.4.0-138-generic
#再起動前までに必ずここまで完了させてください。

念のため目的のカーネルがインストールされているか確認します。

sudo dpkg --get-selections | grep image
$ sudo dpkg --get-selections | grep -e generic -e headers
libaccount-plugin-generic-oauth                 install
linux-headers-4.4.0-138                         install
linux-headers-4.4.0-138-generic                 install
linux-image-4.4.0-134-generic                   deinstall
linux-image-4.4.0-137-generic                   deinstall
linux-image-4.4.0-138-generic                   install
linux-image-4.4.0-21-generic                    deinstall
linux-image-extra-4.4.0-134-generic             deinstall
linux-image-extra-4.4.0-137-generic             deinstall
linux-image-extra-4.4.0-138-generic             install
linux-image-extra-4.4.0-21-generic              deinstall
linux-modules-4.4.0-143-generic                 install
plainbox-provider-resource-generic              install

linux-headers-4.4.0-138-generic と linux-image-4.4.0-138-generic、 linux-image-extra-4.4.0-138-generic のステータスが install となっていることを必ず確認します。

installとなっていれば再起動しても大丈夫です。

再起動が完了したら、次のコマンドを打って実行中のカーネルを確認します。

uname -r
$ uname -r
4.4.0-138-generic

となっていれば作業完了です。
この状態で

sudo /sbin/vboxconfig

を実行すれば vboxdrv のエラーは解消しているはずです。

VirtualBoxの動作まで確認出来たら、問題が解決されるまでの当面の間、自動でカーネルがアップグレードされないようにaptパッケージマネージャーでカーネルバージョンを固定するように設定します。

sudo vi /etc/apt/preferences.d/linux-kernel.pref

などどして設定ファイルを作成し、下記の内容を書き込みます。

Package: linux-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001

Package: linux-headers-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001

Package: linux-image-generic
Pin: version 4.4.0-138.164
Pin-Priority: 1001

これでaptでパッケージを更新してもカーネルは更新対象にならなくなります。

$ uname -r
4.4.0-138-generic
$ sudo apt update
ヒット:1 http://jp.archive.ubuntu.com/ubuntu xenial InRelease
取得:2 http://jp.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]                                                                       
無視:3 http://dl.google.com/linux/chrome/deb stable InRelease                                                                                      
ヒット:4 http://archive.ubuntulinux.jp/ubuntu xenial InRelease                                                                                     
無視:5 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial InRelease                                                                           
取得:6 http://jp.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]                                                                     
ヒット:7 http://archive.ubuntulinux.jp/ubuntu-ja-non-free xenial Release                                                                           
取得:8 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [925 kB]                                                             
ヒット:9 http://dl.google.com/linux/chrome/deb stable Release                                                                                      
取得:11 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [807 kB]                                                             
取得:13 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main amd64 DEP-11 Metadata [318 kB]                                                
取得:14 http://jp.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [233 kB]                                  
ヒット:15 http://ppa.launchpad.net/danielrichter2007/grub-customizer/ubuntu xenial InRelease                            
取得:16 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [739 kB]                             
取得:17 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [677 kB]                          
取得:18 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 DEP-11 Metadata [252 kB]
取得:19 http://jp.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [350 kB] 
取得:20 http://jp.archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 DEP-11 Metadata [5,964 B]
取得:21 http://jp.archive.ubuntu.com/ubuntu xenial-backports/main amd64 DEP-11 Metadata [3,324 B]         
取得:22 http://jp.archive.ubuntu.com/ubuntu xenial-backports/universe amd64 DEP-11 Metadata [5,104 B]      
ヒット:23 http://security.ubuntu.com/ubuntu xenial-security InRelease                                  
4,531 kB を 1秒 で取得しました (3,831 kB/s)             
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています       
状態情報を読み取っています... 完了
アップグレードできるパッケージが 17 個あります。表示するには 'apt list --upgradable' を実行してください。
$ sudo apt list --upgradable
一覧表示... 完了
base-files/xenial-updates 9.4ubuntu4.8 amd64 [9.4ubuntu4.7 からアップグレード可]
distro-info-data/xenial-updates,xenial-updates 0.28ubuntu0.10 all [0.28ubuntu0.9 からアップグレード可]
google-chrome-stable/stable 73.0.3683.86-1 amd64 [72.0.3626.119-1 からアップグレード可]
libc-bin/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc-dev-bin/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6-dbg/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libc6-dev/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
libpam-systemd/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
libsystemd0/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
libudev1/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
locales/xenial-updates,xenial-updates 2.23-0ubuntu11 all [2.23-0ubuntu10 からアップグレード可]
multiarch-support/xenial-updates 2.23-0ubuntu11 amd64 [2.23-0ubuntu10 からアップグレード可]
snapd/xenial-updates 2.37.4 amd64 [2.34.2ubuntu0.1 からアップグレード可]
systemd/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
systemd-sysv/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]
udev/xenial-updates 229-4ubuntu21.17 amd64 [229-4ubuntu21.16 からアップグレード可]

なお、4.4.0-138-generic 以外のバージョンのカーネルを削除しても、まれにカーネルパッケージの残骸が残っていて、別のバージョンのカーネルがデフォルトで起動してしまうことがあるようです。

その場合は下記記事のような手順で起動時のブートローダ画面で 4.4.0-138 カーネルを指定して起動してください。

Ubuntu カーネルのバージョン変更 – Qiita

それにしても、再起動したらVirtualBoxが起動しなくなるとか本当に困るので、早く修正されてほしいですね…

  • この記事いいね! (0)
takahashi 著者:takahashi

CentOS 7 で仮のSSL証明書をとりあえず簡単に生成する方法

昨今では、Let’s Encryptの登場により、正式な証明書をかなり入手しやすくなりました。

その一方で、社内LAN内でのみアクセス可能なテストサーバー、などといったLet’s Encryptで認証を受けるのが難しいサーバーでSSLを使いたい場合や、正式なSSLを発行する前にとりあえずWebサーバーやメールサーバー等のSSL機能が動作しているか確認したい、といった場面もあるかと思います。

その場合、LAN内でのみ通用する独自の認証局を作り、署名して証明書を作成して…としっかりとした方法で構築することもできますが、”とりあえずSSLエラーが出ても問題ないので、とにかくすぐに欲しい”という場合はちょっと面倒です。

一部のLinuxディストリビュージョンでは、そんな場合に備えて”動作チェック用”のssl証明書を一発で発行してくれるスクリプトやコマンドがあります。

例えばUbuntuの場合、

ssl-cert

というパッケージをインストールすることで、”snakeoil”という仮のSSL証明書を一発で生成することができます。

sudo  apt install ssl-cert
sudo make-ssl-cert generate-default-snakeoil

上記コマンドで下記のように証明書と秘密鍵が生成されます。

証明書:/etc/ssl/certs/ssl-cert-snakeoil.pem
秘密鍵:/etc/ssl/private/ssl-cert-snakeoil.key

一方CentOSでは”make-ssl-cert”コマンドが存在しないようですが、代わりに

/etc/ssl/

make-dummy-cert

というスクリプトが用意されており

cd /etc/ssl/certs
sudo ./make-dummy-cert ファイル名

とすることで、一発で指定されたファイル名で仮の証明書を発行してくれます。

なお、このコマンドで生成されるファイルには SSL証明書と一緒に秘密鍵も入っているので、Webサーバーなどで秘密鍵と証明書を指定するときは、同じファイルをそれぞれに指定すれば動作するかと思います。

ちなみに、nginxを使用してリバースプロキシをする際、nginx側で正式な証明書を設定していれば、nginxと裏側のサーバーとの通信をSSLを行う場合、裏側のサーバーにこの仮のSSLを設定していてもエラーになりません。 (nginxでは基本的に裏側サーバーの証明書のコモンネームと要求されたホスト名が不一致でも警告を行わない)
そのため、実際の運用でもこの仮SSL証明書を裏側のサーバーに対して使用することができます。

ただし、nginxと裏側のサーバーの間をつなぐネットワークが信頼できない場合は、正式なSSLを設定した方がいい場合もあるかと思います。このあたりは使用目的や構築する環境の実態に合わせて選択をしてください。

  • この記事いいね! (0)
takahashi 著者:takahashi

Let’s Encrypt+MyDNSでサブドメインのワイルドカードを取得する方法

以前、無料のSSL発行サービスであるLet’s Encryptと無料のDDNSサービスであるMyDNSを組み合わせて自動でワイルドカード証明書を取得・更新する方法をご紹介しましたが、前回の方法だけではサブドメインのワイルドカード証明書(例:*.hoge.example.com)を取得することはできませんでした。

今回はそのサブドメイン証明書をLet’s Encrypt+MyDNSの環境で自動取得・更新する方法をご紹介します。

本題に入る前に、そもそもなぜサブドメインにワイルドカード証明書が必要なのか、について説明します。

折角ワイルドカード証明書がとれるようになったのだから

*.example.com

の証明書だけとっておけば全部使えるじゃん!

そう思う方もいらっしゃるかもしれません。

ここがややこしいところなのですが、実は*.example.comのSSL証明書は例えばhoge.example.com に対しては有効ですが、 *.hoge.example.com(正式な呼び名ではないですが、ここでは便宜上”サブサブドメイン”と呼びます。)に対しては有効ではありません。

ということで サブサブドメインにも適用可能なワイルドカード証明書を作るためには、サブドメインのワイルドカード証明書が必要である、という説明でした。

それではその”サブドメインのワイルドカード証明書”を、Let’s Encrypt+MyDNSで取得してみましょう。

まず、MyDNSにログインします。

メニューから

USER INFO

を選択すると、登録情報編集画面が開くので、その中の

子ID関連の”追加する子IDの数”を追加するサブドメイン分選択します。

これで登録すると、申請した分の子IDのログイン情報がメールで送られてくるので、その情報をメモします。

次に、親IDにログインしたまま、DOMAIN INFOへ移動して、レコード情報に次のように入力します。

サブドメイン名を入力し、DELEGETEを指定すると、そのサブドメインの設定を行末で指定するmydnsのIDに一任させるように指定することができます。

指定するmydnsのIDは、先ほど登録情報欄で増やしたmydnsIDを選択します。

詳細は公式のドキュメントを参照してください。

https://www.mydns.jp/?MENU=030

ここまで出来たら、後は以前ご紹介した手順をサブドメイン分繰り返します。

ただし、
DirectEdit-master
はサブドメイン分用意する必要がありますので注意が必要です。(txtedit.confに登録できるアカウント情報が1つのみのため、アカウント分用意してそれぞれtxtedit.confを設定する必要があるため。)

ディレクトリ名を変えてインストールなどして対策してください。

これでサブドメインでもワイルドカード証明書の自動取得・更新をすることができました。

サブドメインの証明書が必要な方は是非試してみてください。

  • この記事いいね! (0)