zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

【お名前.com】メール転送設定メモ

【参考】
https://www.onamae.com/guide/details.php?g=31#autoreply

example.jpのメール転送設定で

  • hoge@example.jpへのメールをhoge@aaa.bbb.jpに転送
  • fuga@example.jpへのメールをhoge@aaa.bbb.jpに転送したうえで自動返信

としたい
※上記によれば転送は必須みたい。

上記の場合の設定

■転送設定

転送元メールアドレス 転送先メールアドレス 状態 自動返信
hoge@example.jp hoge@aaa.bbb.jp 有効 設定なし
fuga@example.jp hoge@aaa.bbb.jp 有効 以下の様に設定

■自動返信設定設定

状態 有効
自動返信期間 2007/01/01　00時　～　2017/12/31 23:00まで
メール件名（Subject） fuga@example.comは送信専用です
メール本文（Body） fuga@example.comは送信専用です。……

【SVN】authzSVNによるディレクトリごとの閲覧コントロール

【概要】

Subversionで、リポジトリ単位でbasic認証による認証は行っていたが、その下階層について、階層ごとに閲覧権限を制限したいという要望があった。authzsvnが使えたのでメモ。

【今回の要望】

ユーザグループ：

mgr:マネージャ。下記のすべてのリポジトリを閲覧、更新可能
gp?u：/reporoot/gpxディレクトリ以下のみ閲覧、更新可能

階層
reporoot/　…….htpasswdで一括Basic認証を設定
|-- gp1　……mgrとgp1userのみ閲覧、更新可能
|-- gp2　……mgrとgp2userのみ閲覧、更新可能
|-- mgr　……mgrのみ閲覧、更新可能
【作業メモ】
# モジュール確認
apachectl -M
#  dav_svn_module (shared)
# →OK


vi /etc/httpd/conf.d/httpd-ssl.conf

 <Location /reporoot>
  DAV svn
  SVNPath /var/www/svn/reporoot/repository
  AuthType Basic
  AuthName "Restricted Area"
  Require valid-user
  AuthUserFile "/var/www/svn/reporoot/.htpasswd"
  AuthzSVNAccessFile "/var/www/svn/reporoot/authzsvn.conf"
 </Location>

vi /srv/projects/reporoot/root.authzsvn.conf

[groups]
# Managers
mgr = mgr1,mgr2

# group users
gp1u = user1, user2
gm2u = user3, user4

[/]
@mgr = rw

[reporoot:/gp1]
@gp1u = rw

[reporoot:/gp2]
@gp2u = rw

[reporoot:/mgr]
【参考】

http://a4dosanddos.hatenablog.com/entry/2013/07/12/003058
https://qiita.com/skinoshita/items/82f943d3f17b4ad3f183
http://park1.wakwak.com/~ima/centos4_subversion0002.html

【ACM】SSL証明書年次更新について

AWS

【概要】

ELBに設置していたワイルドカードSSL証明書（ACM）について、年次更新の案内メールが来た。FQDNならメールもなく自動更新らしいがワイルドカード証明書だとメール確認が必要。
新規取得時と同様のメールアドレスに承認メールが届くため、承認URLから承認すると、証明書の期限が自動的に1年延長される
（マネージドコンソールでの作業は不要）


【案内メール】

タイトル：Certificate renewal for example.com requires approval
メール本文：

Greetings from Amazon Web Services,

An SSL/TLS certificate for example.com is nearing its expiration date and requires your approval to renew.

Verify that the following domain, AWS account ID, AWS Region, certificate identifier, and expiration date correspond to a certificate that you or someone in your organization is using.

Domain: *.example.com
AWS account ID: xxxx-xxxx-xxxx
AWS Region name: us-east-1
Certificate identifier: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Expiration date: Dec 07, 2017 at 12:00:00 UTC

To approve this request, go to Amazon Certificate Approvals
<承認URL>
and follow the instructions on the page. 

If you choose not to approve this request, you do not need to do anything; however, the certificate will expire, which might make your website unreachable. To prevent future approval requests for this certificate, delete the certificate. See the AWS Certificate Manager User Guide for details.

This email is intended solely for authorized individuals for example.com. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com.

Sincerely,
Amazon Web Services

【更新完了案内メール】

タイトル：Your certificate is renewed
メール本文：

Greetings from Amazon Web Services,

This notification is to notify you that AWS Certificate Manager (ACM) has completed the renewal of an SSL/TLS certificate for the following domains: 
*.example.com

AWS account ID: Xxxxxxxxxx
AWS Region name: us-east-1
Certificate identifier: arn:aws:acm:us-east-1:xxxxxxxxxx:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Your new certificate expires on Nov 25, 2018 at 12:00:00 UTC. 
If you have questions about this process, please use the Support Center at https://console.aws.amazon.com/support to contact AWS Support. If you don’t have an AWS support plan, post a new thread in the AWS Certificate Manager discussion forum at https://forums.aws.amazon.com/forum.jspa?forumID=206

This notification is intended solely for authorized individuals for *.legend-of-war.com. To express any concerns about this notification or if it has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com.

Sincerely,
Amazon Web Services

【メモ】リンク時にリファラを切る

【先に結論】

rel=noreferrer

a 要素や area 要素に rel=noreferrer を指定すると、そのリンクは Referer: を送信しなくなります。

<a href="http://www.example.com/" rel=noreferrer>リンク</a>

アクセスログ

rel=noreferrerなし（普通のリンクタグ）
xxx.xxx.xxx.xxx - - [10/Oct/2017:16:21:43 +0900] "GET /hogefuga.php?s=xxxxx HTTP/1.1" 200 6694 "-" "http://hoge.jp/fuga.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"

→リファラ：http://hoge.jp/fuga.html　が記録されている

rel=noreferrerあり
xxx.xxx.xxx.xxx - - [10/Oct/2017:16:22:15 +0900] "GET /hogefuga.php?s=xxxxx HTTP/1.1" 200 6694 "-" "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"

→リファラは"-"

【参照】

こちらがたいへん詳しい
https://qiita.com/wakaba@github/items/707d72f97f2862cd8000


# see.HTML Standard
https://html.spec.whatwg.org/#link-type-noreferrer
「4.6.6.12 Link type "noreferrer"」

【メモ】Wordpressの引っ越し/開発環境作成など：all-in-one-wp-migrationが完璧すぎた

ロリポのWordpressのサイトの開発環境を作ろうと思ってちょっとググったら以下のプラグインが推奨されていたので使ってみた。
All-in-One WP Migration — WordPress プラグイン
結果としてはもうこれでいい、これでパーフェクト！という感じ。

手順はいろんなところにあるので適当にググってもらうとして
（この辺とか）
webboy.jp


今までファイルとDBを個別にDLしたりアップロードしたりしていたのがウソのような楽ちんさ。
今後の自分のためにメモっておく

【DNS/MXレコード】twitterの承認メールが届かなかった(MXレコードにはIPアドレスではなくFQDNを）

【状況】

自前でqmail+vpopmailサーバを動かしていて、twitterからの承認メールが届かない。
大抵のメールサーバからはメールが届いているのだけど、twitterの承認メールは失われている。

【原因と解決】

smtpdのログにも足跡が無いのでDNSの設定を疑ったところ、DNS(Route53)の設定で
MXレコードがIP直打ちになってた（誰だこれやったの＞俺だ）。
RFCでMXレコードには、ホスト名を記述することになっている。
detail.chiebukuro.yahoo.co.jp

→そのように変更したところ、twitterからのメールが届いた。

【Route53でMXレコード修正】

【参照】
blog.apar.jp

1)メールサーバのAレコード追加

　Nameにサブドメイン「mail」
　ValueにサーバのIPアドレスを入力して作成

2)MXレコードを登録

　Nameは空欄
　Valueに「＜プライオリティ＞ ＜メールサーバのFQDN＞」を入力して作成
　ex. 10 mail.hoge.com.
※メールサーバのFQDNの mail.hoge.com. 最後のピリオドを忘れないように！

dig hoge.com mx
;; ANSWER SECTION:
hoge.com.                300     IN      MX      10 mail.hoge.com.

【AWS】EC2のディスク（EBS）拡張_ext4の場合

【参考】
docs.aws.amazon.com

Amazon EBS Elastic Volumes - Amazon Elastic Compute Cloud
★LVMの場合は以下を参照のこと。
KUSANAGI AWSでLVMディスクを拡張 | 合同会社ジョートー

■マネジメントコンソールよりディスクボリューム拡張

[EC2ダッシュボード]-[ボリューム]
→対象のボリューム: vol-hogehogeを選択

[アクション]-[ボリュームの変更]
「ボリュームの変更」ウィンドウに、ボリューム ID とボリュームの現在の設定
(タイプ、サイズ、IOPS など) が表示されます。
これらの設定のいずれかまたはすべてを 1 回のアクションで変更できます。

f:id:zuntan02:20170929113135p:plain

■ボリュームサイズ変更後の Linux ファイルシステムの拡張

ファイルシステムを確認のうえ、EBS ボリュームのファイルシステムを拡張します

ファイルシステムの確認
sudo file -s /dev/xvd*
/dev/xvda:  GPT partition table, version 1.0（省略）
/dev/xvda1: Linux rev 1.0 ext4 filesystem data（省略）

→ext4なのでresize2fsで拡張することになる。
※ファイルシステムがXFSの場合は
【AWS】EC2のディスク（EBS）拡張_xfsの場合 - zuntan02のはてなブログ
をご参照ください。

現在の容量確認
df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        991M   56K  991M   1% /dev
tmpfs          1002M     0 1002M   0% /dev/shm
/dev/xvda1      7.8G  7.1G  589M  93% /
list block devices確認
lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
 - xvda1 202:1    0    8G  0 part /

→ルートボリュームであるdev/xvdaは100GiBに拡張されているが、パーティションxcda1はまだ8GiBのまま

growpartコマンド(※)でEBSのルートボリュームサイズにあわせて、ボリュームを拡張

※デバイス名とパーティション番号の間にスペースがある点に注意してください。

sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=209711070,end=209715166

※AmazonLinuxは最初から入ってるけどCentOS6のAMIだと入ってない模様。growpartが入ってない時は以下で。あとCentOS6の場合はgrowpartの後再起動が必要です。

yum install epel-release
yum install parted cloud-utils cloud-utils-growpart
list block devices再度確認
lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
 - xvda1 202:1    0  100G  0 part /
各ボリュームでファイルシステムを拡張

拡張実行：ext4なのでresize2fs

sudo resize2fs /dev/xvda1
確認
df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        991M   56K  991M   1% /dev
tmpfs          1002M     0 1002M   0% /dev/shm
/dev/xvda1       99G  7.1G   92G   8% /

→拡張された

■コマンドについて

lsblkコマンド
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-sysinfo-filesystems.html

growpartコマンド
[AWS] EC2 HVMタイプを使う時のファイルシステム周りの作業1(容量拡張、growpart利用) – harumaki.net

マウントされたストレージサイズが上がるだけでOSから認識されたファイルシステムの容量は変更されない。
この部分はcloud-utils-growpartに含まれるgrowpartコマンドを用いて、手作業でファイルシステムの容量を増やす必要がある。

■その他参考
dev.classmethod.jp