SFTP用ユーザを作成

# useradd sftpuser
# passwd sftpuser
Changing password for user sftpuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

SFTP用グループを作成、権限付与

# groupadd sftpgroup
# gpasswd -a sftpuser sftpgroup
# chmod 775 /home/sftpuser/
# chown root:root /home/sftpuser/
# mkdir -p /home/sftpuser/work
# chown sftpuser:sftpgroup /home/sftpuser/work/

SUDO設定

# visudo 
sftpuser ALL=(ALL) ALL

# su sftpuser

SSHログイン用設定

# nano /etc/ssh/sshd_config
最後の方に追加する
Match User sftpuser
  PasswordAuthentication yes
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp
  ChrootDirectory /home/sftpuser

# service sshd restart

Chrootディレクトリのバインドマウントを実行、永続化

# mount -B /var/www/vhosts/example.com/wp-content/themes/work /home/sftpuser/work

# nano /etc/fstab
/var/www/vhosts/example.com/wp-content/themes/work /home/sftpuser/work bind 0 0
text-decoration: underline;
text-underline-position: under;
text-decoration-color: hsla(240, 100%, 47%, 0.5);
/*
hsl()ではhue:色相、saturation:彩度、lightness:輝度の3要素で色を指定
hsla()で透明度もあわせて指定
*/

apacheで動いていた CGIを nginxに持ってくると動かない。
さて、どうするか? spawn-fcgiと fcgiwrapで動かします。

spawn-fcgiを入れる

# yum install epel-release
# yum install spawn-fcgi fcgi-devel

fcgiwrapはソースから入れる

# wget http://github.com/gnosek/fcgiwrap/tarball/master
# tar xzvf master
# cd gnosek-fcgiwrap-gnosek-fcgiwrap-99c942c
# autoreconf -i
# ./configure
# make
# make install

spawn-fcgiの設定を書き込む

# nano /etc/sysconfig/spawn-fcgi
OPTIONS="-u nginx -g nginx -a 127.0.0.1 -p 9001 -P /var/run/spawn-fcgi.pid -- /usr/local/sbin/fcgiwrap"

WordPressがメインで入っていることもあって、wp-frontに設定を書いた

# nano /etc/nginx/wp-front

  # location / {
  #     root   /usr/share/nginx/html;
  #     index  index.html index.htm index.php index.cgi;
  # }
    location ~ \.cgi$ {
        root   /usr/share/nginx/html;
        fastcgi_pass   127.0.0.1:9001;
        fastcgi_index  index.cgi;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }

nginx、php-fpm、spawn-fcgiをリスタート

# rm -rf /var/cache/nginx/proxy_cache/
# service nginx restart
# service php-fpm restart
# service spawn-fcgi restart

CGIを動作させると、403 Forbiddenが表示される。

cgiファイルに実行権限がなかったので、「その他のユーザ」に実行権(x)を付与。

ついでに、CGI関係のファイルが Shift_JISだったら、

# nano /etc/nginx/conf.d/example.com.conf
    server {
        charset shift-jis;
    }
p.overflow {
  width: 200px;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

white-space:nowrap で、改行を半角スペースとして表示させる。これにより、文字列を 1 行におさめる。
overflow:hidden とする事で、はみ出し部分を切り取っている(=表示しないようにしている)。
text-overflow:ellipsis とする事で、はみ出した際に末尾に「…」が付加される。

CSS で指定幅を超えた文字列を切り取り「…」を付加する方法

レスポンシブでブロック要素(div)を比率を維持しながら可変にしたい。
画像は比率を維持しながら勝手にウィンドウサイズに合わせてサイズが変更されるが、ブロック要素では高さを明確にしない限り難しい。

CSSは、高さ方向にpaddingを%で指定した場合、基準値をwidth(100%)から取得する。
要するに、widthの値が変化すると、paddingの値も同じ量だけ変化するということ。
それを利用することで、widthが可変した時に、高さ方法のpaddingも一緒に移動する。

<div class="adjust-box">
    <div class="inner">
        ブロック要素の中身
    </div>
</div>
.adjust-box {
    position: relative;
    width: 50%;
    height: auto;
}
.adjust-box:before {
    content: "";
    display: block;
    padding-top: 100%;
}
.inner {
    position: absolute;
    top: 0; 
    left: 0;
    width: 100%;
    height: 100%;
}
.adjust-box p {
    line-height:1.5em;
}

【CSSテクニック】ブロック要素の比率を維持しながら可変させる方法

1.パスワードが違うと言われる
2.パスワードの再発行(メールにて)
3.メールのリンクを踏む ⇒ 「そのキーは無効なもののようです。」
4.1に戻る
5.もうこの際だから MySQLでパスワードを書き換えてしまおう

6.md5 ハッシュジェネレーター(md5 Hash Generator)

http://www.miraclesalad.com/webtools/md5.php

String:
Password

MD5 Hash:
dc647eb65e6711e155375218212b3964

7.SSH 接続でサーバにログインして MySQLへ入る

# mysql -u root -pPassword
mysql> show databases;
mysql> use my_db;
mysql> select * from wp_users where id=1;
mysql> update wp_users set user_pass = ‘dc647eb65e6711e155375218212b3964’ where id=1;
mysql> commit;

いまの環境は Amazon Linux なので、これを Amazon Linux2にしたい

AWSでWordPress環境を構築する:Amazon Linux2・・・Session Manager
https://note.com/hiroki_hachisuka/n/nc1d5342c3a9b

AmazonLinux2 Nginx+PHP-fpm環境構築メモ
https://qiita.com/dora1341/items/777e8781bb7ddd03cb4d

nginxのデフォルト(nginx.conf)に書いてあることがある

$ edit /etc/nginx/nginx.conf

location = / {
access_log off;
return 204;
break;
}

nginxがリクエストを処理できなかった場合、つまり、ドメインごとの.confを用意し忘れた場合などは、デフォルト(nginx.conf)が呼び出されて、結果、204を返す。

AWS EC2のロードバランサーのターゲットのヘルスチェックも、ここを通るので、204を返していると、unhealthになってしまう。ここは、200を返すべき。

ディレクトリのみの一覧を取得する
-maxdepth:階層指定

$ find /etc/ -type d
$ find /etc/ -maxdepth 1 -type d

ファイルのみの一覧を取得する

$ find /etc/ -type f

EC2インスタンスにSSHできないときって、今回は何の手違いか、.sshディレクトリごと削除しちゃって。
あーあ、自分は nginxユーザーのホームは /home/nginx だと思ってたんだけど、/var/www/vhosts だったんだ。
誰がこんなクソみたいな設定したんだ! オレだ!
authorized_keys がないと、SSHでログインできないじゃないか。

やること:
SSHできないEC2インスタンス(INS-A)からボリューム(VOL-A)を取り出し、別のEC2インスタンス(INS-B)からボリューム内のファイルの問題となっているファイルを修正する。

インスタンス(INS-A)を停止し、ボリューム(VOL-A)をデタッチする

「EC2 -> インスタンス」から、インスタンス(INS-A)を選択して停止

停止したインスタンス(INS-A)の「ルートデバイス」を選択
「EBS ID」をクリックすれば対象のボリューム(VOL-A)へ

「EC2 -> ボリューム」から、対象のボリューム(VOL-A)を選んで「アクション -> ボリュームのデタッチ」

これで、インスタンス(INS-A)からボリューム(VOL-A)が取り除かれた。
別のインスタンス(INS-B)に取り外したボリューム(VOL-A)をアタッチ。

「EC2 -> ボリューム」から、先程取り除いたボリューム(VOL-A)を選択
「アクション -> ボリュームのアタッチ」

空きドライブに割り当てる(デフォルトでは「/dev/sdf」)

これでボリューム(VOL-A)が別のECインスタンス(INS-B)にアタッチされた。
別のEC2インスタンス(INS-B)にログイン。

# df -h
# lsblk
# mkdir /mnt/vol01
# mount /dev/xvdf1 /mnt/vol01
# df -h

作業が終わったらアンマウント。

# umount /mnt/vol01

インスタンス(INS-B)からボリューム(VOL-A)をデタッチ
インスタンス(INS-A)にボリューム(VOL-A)をアタッチ(/dev/xvda)して起動

「EC2 -> ボリューム」からボリューム(VOL-A)を選択
「アクション -> ボリュームのアタッチ」を選択
デバイスの値を最初と同じ「/dev/xvda」にしてから「アタッチ」