さくらのVPSのサイトをHTTPS化

さくらの VPS で運用しているサイト(Railsアプリ)を Let’s Encrypt で HTTPS 化した。言っとくけどこのブログじゃないよ。

HTTPのポートを開放

まず、HTTPS のポート 443 を開放する。/etc/sysconfig/iptables ファイルを編集。

[takatoh@tk2-254-36564 ~]$ cd /etc/sysconfig
[takatoh@tk2-254-36564 sysconfig]$ sudo vim iptables

つぎの行を追加。

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

iptables を再起動。

[takatoh@tk2-254-36564 sysconfig]$ sudo service iptables restart
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
iptables: Loading additional modules: ip_conntrack_ftp [ OK ]

certbot-auto のセットアップと証明書の自動生成

「certbot-auto」は Let’s Encrypt が提供しているクライントツールで、SSL証明書を取得したり延長したりできる。ここでは、最新版を取得する。

[takatoh@tk2-254-36564 bin]$ sudo wget https://dl.eff.org/certbot-auto
--2019-01-13 09:41:36-- https://dl.eff.org/certbot-auto
dl.eff.org をDNSに問いあわせています… 151.101.72.201, 2a04:4e42:36::201
dl.eff.org|151.101.72.201|:443 に接続しています… 接続しました。
HTTP による接続要求を送信しました、応答を待っています… 200 OK
長さ: 63562 (62K) [application/octet-stream]
`certbot-auto' に保存中

100%[======================================>] 63,562 --.-K/s 時間 0.002s

2019-01-13 09:41:39 (24.3 MB/s) - `certbot-auto' へ保存完了 [63562/63562]

[takatoh@tk2-254-36564 bin]$ sudo chmod 700 /usr/bin/certbot-auto

いまインストールした certbot-auto を使って、証明書を自動生成する。

[takatoh@tk2-254-36564 ~]$ sudo certbot-auto certonly --webroot -w /var/www/lathercraft/public -d www.lathercraft.net --email lathercraft@gmail.com

途中、いろんなパッケージをインストールしたりするのでy(yes)を入力する。しばらくすると利用規約が表示されるので、A(agree)を入力。最後に↓こんなメッセージが出ればOK。

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.lathercraft.net/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.lathercraft.net/privkey.pem
Your cert will expire on 2019-04-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew all of your certificates, run
"certbot-auto renew"
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

- We were unable to subscribe you the EFF mailing list because your
e-mail address appears to be invalid. You can try again later by
visiting https://act.eff.org.

……じゃないな、e-mail が invalid だと言ってる。あとから試せるとも言ってるので、とりあえず先に進む。この時点で証明書類はこんな感じになっている。

[takatoh@tk2-254-36564 ~]$ sudo ls -l /etc/letsencrypt/live/www.lathercraft.net/
合計 4
-rw-r--r-- 1 root root 692 1月 13 09:53 2019 README
lrwxrwxrwx 1 root root 43 1月 13 09:53 2019 cert.pem -> ../../archive/www.lathercraft.net/cert1.pem
lrwxrwxrwx 1 root root 44 1月 13 09:53 2019 chain.pem -> ../../archive/www.lathercraft.net/chain1.pem
lrwxrwxrwx 1 root root 48 1月 13 09:53 2019 fullchain.pem -> ../../archive/www.lathercraft.net/fullchain1.pem
lrwxrwxrwx 1 root root 46 1月 13 09:53 2019 privkey.pem -> ../../archive/www.lathercraft.net/privkey1.pem

Nginxの設定

SSL 対応にする。こんなふうに書き換える。

    #listen      80;
    listen      443 ssl;

    ssl_certificate      /etc/letsencrypt/live/www.lathercraft.net/cert.pem;
    ssl_certificate_key  /etc/letsencrypt/live/www.lathercraft.net/privkey.pem;

Nginx を再起動。

[takatoh@tk2-254-36564 conf.d]$ sudo service nginx restart
Stopping nginx: [ OK ]
Starting nginx: [ OK ]

これでOKのはず。まだアプリが SSL 対応していないのでバナー画像に https でアクセスしてみたら、ちゃんと表示された。なのでここまではOKのようだ。

RailsアプリのSSL対応

これは簡単。config/envronments/production.rb ファイルのつぎの箇所を修正すればいい。

# config.force_ssl = true
config.force_ssl = true

コメントアウトしてあるのを外すだけだ。そして再起動。

[takatoh@tk2-254-36564 environments]$ sudo service unicorn_lathercraft restart
reloaded OK

OK。大丈夫そうだ。

httpをhttpsにリダイレクト

最後に、http でのアクセスを https にリダイレクトする設定をする。Nginx の設定に戻ってつぎの設定を追加する。

server {
    listen       80;
    server_name  www.lathercraft.net;
    return       301 https://www.lathercraft.net;
}

Nginx を再起動して完了。

証明書の自動更新設定

Let’s Encrypt の証明書は有効期限が3ヶ月と短いので、自動更新するように設定する。更新は certbot-auto renew コマンドでできるので、これを root ユーザの cron に登録する。

[takatoh@tk2-254-36564 ~]$ sudo -s
[root@tk2-254-36564 takatoh]# crontab -l
no crontab for root
[root@tk2-254-36564 takatoh]# crontab -e
0 4 * * 0 certbot-auto renew --post-hook "service unicorn_lathercraft restart" > /dev/null 2> /dev/null

これで毎週月曜日の午前4時に更新するようになる。

[追記]

上の、Nginx のリダイレクトの設定では、http でのアクセスはどんなパスでも全て https のルートにリダイレクトされてしまう。なので、つぎのように変更した。

server {
    listen       80;
    server_name  www.lathercraft.net;

    location ~ ^/(.*)$ {
        return 301 https://www.lathercraft.net/$1;
    }
}

これで各ページも https にリダイレクトされるようになった。

sshで接続できるようにする

bigswifty を WiMAX に接続したので、他のマシンとはネットワーク的に切り離されてしまった。まぁ、これは意図した通りなんだけど、ssh で接続できないのも不便なので、インターネット経由で接続できるように設定する。

ここからは bitswifty 上での作業。

sshdの設定

ポートを変更。

Port 12345

root でのログインを禁止。

PermitRootLogin no

設定を反映するために sshd を再起動。

[lcstorage@bigswifty ~]$ sudo systemctl restart sshd

ファイアウォールの設定

ポートを開ける。

[lcstorage@bigswifty ~]$ sudo firewall-cmd --add-port=12345/tcp --zone=public --permanent
success

設定をリロード。

[lcstorage@bigswifty ~]$ sudo firewall-cmd --reload
success

WiMAX端末のポートマッピング

192.168.100.1 にブラウザで接続して、設定ページから、ファイアウォール設定→ポートマッピングと進んで、WAN ポートの12345 を bitswifty の12345 番ポートに接続するようにする。と、ここで気が付いたんだけど bigswifty のポートは変更しなくても良かったんじゃないか?まぁいいか。

接続テスト

別のマシンからインターネット経由で ssh 接続してみると、無事接続できた。

公開鍵での認証

認証方法をパスワード認証から公開鍵認証に切り替える。公開鍵は GitHub からもってきた。

[lcstorage@bigswifty ~]$ mkdir .ssh
mkdir: ディレクトリ `.ssh' を作成できません: ファイルが存在します
[lcstorage@bigswifty ~]$ cd .ssh
[lcstorage@bigswifty .ssh]$ wget -O authorized_keys https://github.com/takatoh.keys
--2018-12-15 05:32:26-- https://github.com/takatoh.keys
github.com (github.com) をDNSに問いあわせています... 192.30.255.112, 192.30.255.113
github.com (github.com)|192.30.255.112|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 特定できません [text/plain]
`authorized_keys' に保存中

[ <=> ] 381 --.-K/s 時間 0s

2018-12-15 05:32:27 (2.28 MB/s) - `authorized_keys' へ保存終了 [381]

[lcstorage@bigswifty .ssh]$ chmod 600 authorized_keys[lcstorage@bigswifty .ssh]$ ls -al
合計 12
drwx------. 2 lcstorage lcstorage 48 12月 15 05:32 .
drwx------. 19 lcstorage lcstorage 4096 12月 15 04:34 ..
-rw------- 1 lcstorage lcstorage 381 12月 15 05:32 authorized_keys
-rw-r--r--. 1 lcstorage lcstorage 185 12月 4 03:56 known_hosts

接続テスト

再び、別のマシンから接続テスト。ちゃんと公開鍵認証で接続できた。

パスワード接続を禁止

最後に、もう一度 /etc/ssh/sshd_config ファイルを編集して、パスワード接続を禁止する。

PasswordAuthentication no

sshd を再起動。

[lcstorage@bigswifty .ssh]$ sudo systemctl restart sshd

これで完了。

参考ページ

CentOS: マシンを再起動するとサービスが動かない件

一昨日のエントリでは書かなかったけど、マシンを再起動したら uWSGI のサービスが起動しなかった。仕方がないので手動で起動してたんだけど、今日、問題が解決した。
原因は、ソケットファイルを作る /run/uwsgi ディレクトリがマシンを再起動すると消えてしまうこと。何故なら、/run は tmpfs というタイプのファイルシステムだかららしい。

[lcstorage@bigswifty ~]$ df -h
ファイルシス                      サイズ  使用  残り 使用% マウント位置
/dev/mapper/centos_bigswifty-root    50G  4.3G   46G    9% /
devtmpfs                            1.8G     0  1.8G    0% /dev
tmpfs                               1.8G  8.7M  1.8G    1% /dev/shm
tmpfs                               1.8G  9.8M  1.8G    1% /run
tmpfs                               1.8G     0  1.8G    0% /sys/fs/cgroup
/dev/sdb1                           917G  3.4G  867G    1% /mnt/wiwaxia
/dev/sdc1                           917G   77M  871G    1% /mnt/ottoia
/dev/sda1                          1014M  286M  729M   29% /boot
/dev/mapper/centos_bigswifty-home   179G  507M  178G    1% /home
tmpfs                               359M   32K  359M    1% /run/user/1001

詳しくは分からないけど、↓このページに解決策があった。

 cf.  /var/run の中身が再起動すると消えてしまうので・・・ – cles::blog

要するに、次のような内容で /etc/tmpfiles.d/uwsgi.conf  ファイルを作ってやればいいようだ。

d /run/uwsgi 0777 root root

これで無事、マシンを再起動しても大丈夫になった。

bottleアプリにNginx経由で接続できるようにする

1日空いてしまった。
uWSGI でデーモンとして動かすことに成功したので、今日は Nginx をリバースプロキシにして lcstorage というホスト名で接続できるようにする。

Nginx の前に、uWSGI の設定をちょっと変更。リクエストを待ち受けるのにポートじゃなくて UNIX ソケットを利用するようにする。

[uwsgi]
uid = lcstorage
gid = lcstorage
#http = :8080
socket = /run/uwsgi/lcstorage.sock
venv = /home/lcstorage/lcstorage/env
wsgi-file = /home/lcstorage/lcstorage/index.py
master = true
pidfile = /home/lcstorage/lcstorage/lcstorage.pid
daemonize = /home/lcstorage/lcstorage/lcstorage.log

http の設定をコメントアウトして socket を設定している。
でもって、sochekt のディレクトリをつくる。

[lcstorage@bigswifty ~]$ sudo mkdir /run/uwsgi
[lcstorage@bigswifty ~]$ sudo chmod 777 /run/uwsgi

つぎに、Nginx のバーチャルホストの設定。
/etc/nginx/conf.d/lcstorage.conf ファイルを作る。

upstream uwsgi-lcstorage {
    server unix:/run/uwsgi/lcstorage.sock;
}

server {
    # port
    listen      80;

    # server name
    server_name lcstorage;

    # document root
    #root        /home/lcstorage/lcstorage;

    # index
    #index       index.php index.html index.htm;

    client_max_body_size    4G;

    # log files
    access_log /var/log/nginx/lcstorage/access.log main;
    error_log  /var/log/nginx/lcstorage/error.log warn;

    keepalive_timeout     60;
    proxy_connect_timeout 60;
    proxy_read_timeout    60;
    proxy_send_timeout    60;

    location / {
        #root       /home/lcstorage/lcstorage;

        include uwsgi_params;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        uwsgi_pass unix:/run/uwsgi/lcstorage.sock;
    }
}

ログファイル用のディレクトリをつくる。

[lcstorage@bigswifty ~]$ sudo mkdir /var/log/nginx/lcstorage

そして、SELinux を無効化。コレ重要。

最後に、マシンをリブートして終了。
無事にバーチャルホストにアクセスできることを確認した。

CentOS 7上でbottleアプリをuWSGIで動かす(2)

一昨日の続き。今日は、アプリをデーモンとして動かす。
まず最初に、uWSGI の設定ファイルをちょっと書き換える。

最後の行を変更した。logger を daemonize に変えると何故かデーモンとしてバックグラウンドで動くようになるという、uWSGI のよくわからない仕様。

無事バックグラウンドで動くようになったら、systemd のサービスになるように設定ファイル /etc/systemd/system/lcstorage.service を書く。

これでいいはず。試してみよう。

[lcstorage@bigswifty system]$ sudo systemctl start lcstorage
[sudo] lcstorage のパスワード:
[lcstorage@bigswifty system]$ ps ax | grep uwsgi
28937 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28946 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28947 ?        S      0:00 /usr/bin/uwsgi /home/lcstorage/lcstorage/lcstorage.ini
28949 pts/1    S+     0:00 grep --color=auto uwsgi

成功のようだ。他のマシンのブラウザからも確認できた。

最後に、マシンの起動にあわせて自動的に起動するようにする。

[lcstorage@bigswifty system]$ sudo systemctl enable lcstorage
Created symlink from /etc/systemd/system/multi-user.target.wants/lcstorage.service to /etc/systemd/system/lcstorage.service.

さあ、あしたは Nginx 経由でアクセスできるようにしよう。時間があったらだけど。

Railsアプリのログをローテーションした話

Web を見ていてログローテーションの記事を見かけたので、そういえばさくらの VPS で動かしている Rails アプリのログはどうなってるんだろう、と思った。で、調べてみるとつぎの通り。

[takatoh@tk2-254-36564 log]$ ls -lh
合計 1.2G
-rw-r--r-- 1 root root  25K  5月  5 09:53 2017 development.log
-rw-r--r-- 1 root root 1.2G 12月  5 03:56 2018 production.log

うわあああああ、production.log が 1.2GB もあるううう!!!!!

こりゃ、ぜひともログローテーションしなきゃ、と思って調べてみると、Rails にはログのローテーションをする機能があるらしい。アプリのディレクトリ以下の config/environments/production.rb ファイルで、つぎのようにすればいいようだ。

ところが、実際に動いているアプリのファイル(の該当部分)を見てみるとつぎのようになっている。

コメントアウトしてあるのはいいとしても、Rails のバージョンのせいなのか何なのか、全然違う。はっきりいってこういうのはウカツに弄りたくない。

というわけで、logrotate でやってみることにした。さくらの VPS では logrotate がデフォルトで動いている(らしい)ので、/etc/logrotate.d 以下に設定ファイルを書いて置いてやればいい。

参考にしたページ:
cf. さくらのVPSの設定 – logrotateの設定
テストしてみる。

[takatoh@tk2-254-36564 logrotate.d]$ logrotate -dv unicorn_lathercraft
reading config file lathercraft
reading config info for /var/www/lathercraft/log/production.log 

Handling 1 logs

rotating pattern: /var/www/lathercraft/log/production.log  after 1 days (14 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/lathercraft/log/production.log
  log does not need rotating
not running postrotate script, since no logs were rotated

エラーらしきものは出てないので、いいのかな。
とりあえずこれで様子を見てみよう。

CentOS 7上でbottleアプリをuWSGIで動かす

専用ユーザーの作成

[takatoh@bigswifty ~]$ sudo useradd lcstorage
[sudo] takatoh のパスワード:
[takatoh@bigswifty ~]$ sudo passwd lcstorage
ユーザー lcstorage のパスワードを変更。
新しいパスワード:
よくないパスワード: このパスワードには一部に何らかの形でユーザー名が含まれています。
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。

よくないパスワードとか言われてるけど無視。sudo する権利をつける。

[takatoh@bigswifty ~]$ sudo usermod -G wheel lcstorage

ここからは新しいユーザーでの作業になるので、ログインし直し。

bottleアプリの配置

bitbucket.org から clone。

[lcstorage@bigswifty ~]$ git clone https://takatoh@bitbucket.org/takatoh/lathercraft-storage-py.git lcstorage
Cloning into 'lcstorage'...
Password for 'https://takatoh@bitbucket.org': 
remote: Counting objects: 127, done.
remote: Total 127 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (127/127), 13.63 KiB | 0 bytes/s, done.
Resolving deltas: 100% (55/55), done.

中に入って virtualenv を作成。

[lcstorage@bigswifty ~]$ cd lcstorage
[lcstorage@bigswifty lcstorage]$ virtualenv env
New python executable in /home/lcstorage/lcstorage/env/bin/python2
Also creating executable in /home/lcstorage/lcstorage/env/bin/python
Installing setuptools, pip, wheel...
done.
[lcstorage@bigswifty lcstorage]$ source env/bin/activate
(env) [lcstorage@bigswifty lcstorage]$

依存ライブラリのインストール。

(env) [lcstorage@bigswifty lcstorage]$ pip install -r requirements.txt
Collecting PyYAML==3.12 (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/4a/85/db5a2df477072b2902b0eb892feb37d88ac635d36245a72a6a69b23b383a/PyYAML-3.12.tar.gz (253kB)
    100% |████████████████████████████████| 256kB 6.9MB/s 
Collecting bottle==0.12.10 (from -r requirements.txt (line 2))
  Downloading https://files.pythonhosted.org/packages/5c/a9/f157af11b37834db992b14e43ade37a1bdc141485657cfa36dc1d99420a6/bottle-0.12.10-py2-none-any.whl (88kB)
    100% |████████████████████████████████| 92kB 8.9MB/s 
Collecting requests==2.12.3 (from -r requirements.txt (line 3))
  Downloading https://files.pythonhosted.org/packages/84/68/f0acceafe80354aa9ff4ae49de0572d27929b6d262f0c55196424eb86b2f/requests-2.12.3-py2.py3-none-any.whl (575kB)
    100% |████████████████████████████████| 583kB 8.1MB/s 
Building wheels for collected packages: PyYAML
  Running setup.py bdist_wheel for PyYAML ... done
  Stored in directory: /home/lcstorage/.cache/pip/wheels/03/05/65/bdc14f2c6e09e82ae3e0f13d021e1b6b2481437ea2f207df3f
Successfully built PyYAML
Installing collected packages: PyYAML, bottle, requests
Successfully installed PyYAML-3.12 bottle-0.12.10 requests-2.12.3

アプリの設定ファイルを作って、起動確認。設定はとりあえずはデフォルトのままで。

(env) [lcstorage@bigswifty lcstorage]$ cp config.yaml.example config.yaml
(env) [lcstorage@bigswifty lcstorage]$ python index.py
Bottle v0.12.10 server starting up (using WSGIRefServer())...
Listening on http://0.0.0.0:8080/
Hit Ctrl-C to quit.

よし、大丈夫そうだ。じゃ、virtualenv をぬけて uWSGI に行くぞ。

uWSGIで起動

まずは uWSGI のインストール。

[lcstorage@bigswifty lcstorage]$ sudo pip install uwsgi
Collecting uwsgi
  Using cached https://files.pythonhosted.org/packages/a2/c9/a2d5737f63cd9df4317a4acc15d1ddf4952e28398601d8d7d706c16381e0/uwsgi-2.0.17.1.tar.gz
Installing collected packages: uwsgi
  Running setup.py install for uwsgi ... done
Successfully installed uwsgi-2.0.17.1
You are using pip version 8.1.2, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

上では省略しちゃったけど、最初のインストールの時にエラーが出て、sudo yum install gcc python2-devel しなきゃならなかった。
ともかくインストールできたので、コマンドラインから起動してみる。

[lcstorage@bigswifty lcstorage]$ uwsgi --http :8080 --wsgi-file index.py -H env

他のマシンからアクセスしたら、ちゃんと動いていたのでOK。

設定ファイルを書く。

起動確認。

[lcstorage@bigswifty lcstorage]$ uwsgi lcstorage.ini
[uWSGI] getting INI configuration from lcstorage.ini

OK。大丈夫そうだ。

とりあえずここまで。

USB外付けHDDを接続する

さて、今度は bigswifty に USB の外付け HDD を接続してみる。
マシンを起動した状態で繋いで見ると次のようになる。

[takatoh@bigswifty ~]$ sudo blkid
[sudo] takatoh のパスワード:
/dev/sda1: UUID="4c426dd3-8999-4bc0-ba95-2a21ffe751f1" TYPE="xfs" 
/dev/sda2: UUID="3JSzi4-m7uB-BxAK-ue4f-DaUl-d3G5-pIbs9U" TYPE="LVM2_member" 
/dev/mapper/centos_bigswifty-root: UUID="b05ee492-4803-4e72-9b6b-e180623577f0" TYPE="xfs" 
/dev/mapper/centos_bigswifty-swap: UUID="48a4fa87-45ef-4fce-acaf-3020d65d8874" TYPE="swap" 
/dev/mapper/centos_bigswifty-home: UUID="4e1e2a4f-ebce-49e9-bf84-4c5e53306c6a" TYPE="xfs" 
[takatoh@bigswifty ~]$ lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                         8:0    0 232.9G  0 disk 
├─sda1                      8:1    0     1G  0 part /boot
└─sda2                      8:2    0 231.9G  0 part 
  ├─centos_bigswifty-root 253:0    0    50G  0 lvm  /
  ├─centos_bigswifty-swap 253:1    0   3.8G  0 lvm  [SWAP]
  └─centos_bigswifty-home 253:2    0 178.1G  0 lvm  /home
sdb                         8:16   0 931.3G  0 disk

sudo blkid コマンドでは出てこないけど lsblk コマンドでは sdb ってのが出てくる。これが外付け HDD だろう。もともとは Windows マシンで使っていたものだけど、ディスク消去ソフトでデータを消去してあるので、ファイルシステムも何もない。これを ext4 にフォーマットして使う。

まずはパーティションを切ることから。

[takatoh@bigswifty ~]$ sudo fdisk /dev/sdb
[sudo] takatoh のパスワード:
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x7a9ef1d0.

コマンド (m でヘルプ): p

Disk /dev/sdb: 1000.0 GB, 1000010997760 bytes, 1953146480 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x7a9ef1d0

デバイス ブート      始点        終点     ブロック   Id  システム

コマンド (m でヘルプ): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): 
Using default response p
パーティション番号 (1-4, default 1): 
最初 sector (2048-1953146479, 初期値 2048): 
初期値 2048 を使います
Last sector, +sectors or +size{K,M,G} (2048-1953146479, 初期値 1953146479): 
初期値 1953146479 を使います
Partition 1 of type Linux and of size 931.3 GiB is set

コマンド (m でヘルプ): p

Disk /dev/sdb: 1000.0 GB, 1000010997760 bytes, 1953146480 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x7a9ef1d0

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdb1            2048  1953146479   976572216   83  Linux

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。

パーティションができたら、次はフォーマット。

[takatoh@bigswifty ~]$ sudo mkfs -t ext4 /dev/sdb1
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61038592 inodes, 244143054 blocks
12207152 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2392850432
7451 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done     

これでOK。確かめてみる。

[takatoh@bigswifty ~]$ sudo blkid
/dev/sda1: UUID="4c426dd3-8999-4bc0-ba95-2a21ffe751f1" TYPE="xfs" 
/dev/sda2: UUID="3JSzi4-m7uB-BxAK-ue4f-DaUl-d3G5-pIbs9U" TYPE="LVM2_member" 
/dev/mapper/centos_bigswifty-root: UUID="b05ee492-4803-4e72-9b6b-e180623577f0" TYPE="xfs" 
/dev/mapper/centos_bigswifty-swap: UUID="48a4fa87-45ef-4fce-acaf-3020d65d8874" TYPE="swap" 
/dev/mapper/centos_bigswifty-home: UUID="4e1e2a4f-ebce-49e9-bf84-4c5e53306c6a" TYPE="xfs" 
/dev/sdb1: UUID="3bdf3a15-2722-4992-9c77-cf1c2349b385" TYPE="ext4" 
[takatoh@bigswifty ~]$ lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                         8:0    0 232.9G  0 disk 
├─sda1                      8:1    0     1G  0 part /boot
└─sda2                      8:2    0 231.9G  0 part 
  ├─centos_bigswifty-root 253:0    0    50G  0 lvm  /
  ├─centos_bigswifty-swap 253:1    0   3.8G  0 lvm  [SWAP]
  └─centos_bigswifty-home 253:2    0 178.1G  0 lvm  /home
sdb                         8:16   0 931.3G  0 disk 
└─sdb1                      8:17   0 931.3G  0 part

最後に、/etc/fstab ファイルに設定を書き込んで再起動すればマウントされるはずだ。マウントポイントは /mnt/wiwaxia にした。

再起動した結果、次のようになった。

[takatoh@bigswifty ~]$ lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                         8:0    0 232.9G  0 disk 
├─sda1                      8:1    0     1G  0 part /boot
└─sda2                      8:2    0 231.9G  0 part 
  ├─centos_bigswifty-root 253:0    0    50G  0 lvm  /
  ├─centos_bigswifty-swap 253:1    0   3.8G  0 lvm  [SWAP]
  └─centos_bigswifty-home 253:2    0 178.1G  0 lvm  /home
sdb                         8:16   0 931.3G  0 disk 
└─sdb1                      8:17   0 931.3G  0 part /mnt/wiwaxia
[takatoh@bigswifty ~]$ df -h
ファイルシス                      サイズ  使用  残り 使用% マウント位置
/dev/mapper/centos_bigswifty-root    50G  3.9G   47G    8% /
devtmpfs                            1.8G     0  1.8G    0% /dev
tmpfs                               1.8G   30M  1.8G    2% /dev/shm
tmpfs                               1.8G  9.7M  1.8G    1% /run
tmpfs                               1.8G     0  1.8G    0% /sys/fs/cgroup
/dev/sda1                          1014M  223M  792M   22% /boot
/dev/sdb1                           917G   77M  870G    1% /mnt/wiwaxia
/dev/mapper/centos_bigswifty-home   179G  305M  178G    1% /home
tmpfs                               359M   32K  359M    1% /run/user/1000

CentOS7: ノートPCを閉じてもサスペンドさせない

CentOS をインストールしたノートPCをサーバとして動かすとき、ふだんは閉じていると思う。だけど、デフォルトの設定では、閉じるとサスペンドしてしまって、サーバの役目を果たさない。これはどうにかしなきゃならない。
というわけで、ググってみたらちょうどそのまんまの記事をみつけた。

 cf. CentOS7でノートPCを閉じてもサスペンドさせない – Qiita

/etc/systemd/logind.conf ファイルを下のように編集する。

コメントアウトしてあるのがもともとの設定(もとからコメントアウトしてあった)で、下の 3 行が変更した設定。
logind をリスタートして変更を反映させる。

[takatoh@bigswifty ~]$ sudo systemctl restart systemd-logind

これで一晩おいてから確かめてみると、閉じている状態でもちゃんと動いていることが確認できた。

CentOS7でNginxを動かす

OS のインストールが終わった bigswifty、Web サーバにするので Nginx をインストールする。と言っても、過去記事があるのでそこにリンクするだけにしておく。

cf. CentOS 7にNginxをインストールする

上の記事に、インストールからファイアウォールの設定、Nginx の起動まで書いてある。

別のマシンからブラウザでアクセスしてみて、ちゃんと動いているのを確認した。