タイトルリスト
0 | 1 | 2
 2018/09/30
ディスクスペースを拡張してみる@VMware
VMware はディスクスペースを簡単に拡張できるが、拡張しても実際のディスクスペースは OS 側で拡張しなければならない。
# 拡張しないと「空きスペース」として扱われる。

★OS
% uname -a
FreeBSD leviathan-vmw 11.2-RELEASE-p3 FreeBSD 11.2-RELEASE-p3 #0:
 Thu Sep  6 06:42:08 UTC 2018
  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
★拡張前
% fdisk ada3
******* Working on device /dev/ada3 *******
parameters extracted from in-core disklabel are:
cylinders=22192 heads=15 sectors/track=63 (945 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=22192 heads=15 sectors/track=63 (945 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 20971377 (10239 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 687/ head 14/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
★VMwareで拡張後
cylinders が増えたことを確認する。
% fdisk ada3
******* Working on device /dev/ada3 *******
parameters extracted from in-core disklabel are:
cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 20971377 (10239 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 687/ head 14/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
さて拡張作業。
% sudo fdisk -u ada3
******* Working on device /dev/ada3 *******
parameters extracted from in-core disklabel are:
cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl)
↑★ここの cylinders と blks/cyl をかけ算する。44384x945=41942880 Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Do you want to change our idea of what BIOS thinks ? [n] ↑★リターン空打ちで[]内の返答となる Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 20971377 (10239 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 687/ head 14/ sector 63 Do you want to change it? [n] y ★パーティション1を編集する Supply a decimal value for "sysid (165=FreeBSD)" [165] Supply a decimal value for "start" [63] Supply a decimal value for "size" [20971377] 41942817
↑★計算した数字から start の 63 を引いた数字を入れる Explicitly specify beg/end address ? [n] sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41942817 (20479 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 351/ head 14/ sector 63 Are we happy with this entry? [n] y ★適用 The data for partition 2 is: <UNUSED> Do you want to change it? [n] The data for partition 3 is: <UNUSED> Do you want to change it? [n] The data for partition 4 is: <UNUSED> Do you want to change it? [n] Partition 1 is marked active Do you want to change the active partition? [n] We haven't changed the partition table yet. This is your last chance. parameters extracted from in-core disklabel are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=44384 heads=15 sectors/track=63 (945 blks/cyl) Information from DOS bootblock is: 1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 41942817 (20479 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 351/ head 14/ sector 63 2: <UNUSED> 3: <UNUSED> 4: <UNUSED> Should we write new partition table? [n] y ★適用
この後が超重要。
bsdlabel のオプションは -e (EDIT:編集) を使うこと。
間違って-wしないように!!
やっちまうとパーティション情報がバラバラになるかもしれない。

一応単一パーティションだと問題はなかった (元通りにしたら中が見える) が、あまり良い事では無さそう。
% sudo bsdlabel -e /dev/ada3s1
# /dev/ada3s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  c:   20971377          0    unused        0     0     # "raw" part, don't edit
  d:   20971361         16    4.2BSD        0     0     0

↓

# /dev/ada3s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  c:   41942817          0    unused        0     0     # "raw" part, don't edit
  d:   41942801         16    4.2BSD        0     0     0
c: には fdisk の size で入力した数値を指定。
d: にはその数値からオフセット分 (16) を引いた数値を指定。

この状態でも一応 mount は出来るが、まだ広げたところが使えないので 、広げた部分を newfs してくれる growfs を使う。
指定するデバイスは広げたパーティション。今回は /dev/ada3s1d。
% sudo growfs /dev/ada3s1d
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ada3s1d from 10GB to 20GB? [yes/no] yes  ←★ぶっ壊れる覚悟が出来たら "yes" で広げる。
super-block backups (for fsck_ffs -b #) at:
 21802624, 23085120, 24367616, 25650112, 26932608, 28215104, 29497600, 30780096, 32062592, 33345088, 34627584, 35910080,
 37192576, 38475072, 39757568, 41040064
これで df すると容量が増えてる。

念のためちゃんとバックアップは取っておきましょう。


最終:2018/10/01 00:27:44 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/24
Let's Encryptの証明書をapache 2.2にインストールするときのはまりどころ
ふと OpenSSL で証明書の検証がどうなってるかをチェックしてみた。
% openssl s_client -connect localhost:443 -showcerts < /dev/null
(省略)
    Verify return code: 21 (unable to verify the first certificate)


はい?


しかも Certificate chain が 1つしか出てこない。
おかしいと思ってぐぐってみると、どうも httpd-ssl.conf で SSLCertificateChainFile に中間証明書を指定しなければならないらしい。
というわけで
SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/cert.pem"
SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/chain.pem"
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/privkey.pem"
と指定して再起動してから openssl を叩いてみたら無事に "Verify return code: 0 (ok)" となった。

ちなみに Postfix は smtp_tls_CAfile に中間証明書を指定する。

proftpd は TLSCACertificateFile に中間証明書を指定する。

参考:
% openssl s_client -connect localhost:443 -showcerts < /dev/null

% openssl s_client -connect localhost:25 -starttls smtp -showcerts < /dev/null

% openssl s_client -connect localhost:110 -starttls pop3 -showcerts < /dev/null

% openssl s_client -connect localhost:143 -starttls imap -showcerts < /dev/null

最終:2018/09/24 02:23:40 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/22
certbot-autoの--pre-hookと--deploy-hookと--post-hook
こいつら微妙に違う。
共通して言えるのは「証明書の更新が必要な時に動く」こと。

--pre-hook更新作業前に1度だけ実行
--deploy-hook証明書ごとに実行
--post-hook更新作業後に1度だけ実行

フローチャート

たとえば証明書が複数有り……
  • 両方更新が無ければ何もせずに終了する。
  • 1枚だけ更新があれば pre → deploy → post の順に実行される。
  • 複数更新があれば pre → 複数回 deploy → post の順に実行される。
ここで重要なのは pre と post は 1回しか実行されないことと deploy は複数回実行されること。

使い分けとしては、証明書をサービスごと (例えば httpd と postfix と dovecot) に分けるのであれば、各サービスごとに deploy で証明書のコピーとプロセスの再起動を行えば良い。
pre と post はあまり使わないかも。

無理矢理使うのであれば、証明書の更新の際にメールを送るようにしたいとき、deploy で複数メールを送ると何通もメールが届くので、
preで一時ファイルをクリア

deployでRENEWED_DOMAINSやRENEWED_LINEAGEを追記モード (>>) で一時ファイルにリダイレクト

postで一時ファイルをcatしてメールする
なんて方法がある。

なお、/etc/letsencrypt/renewal-hooks/ の下に pre、deploy、post ディレクトリがあるが、この中にスクリプトを入れておくとそれぞれのタイミングでそのディレクトリの中に有るスクリプトを実行してくれる。
また、オプションで --pre-hook、--deploy-hook、--post-hook により実行するスクリプトを指定出来るが、それらと /etc/letsencrypt/renewal-hooks/ の下に有る pre/deploy/post は共存可能である。
# どっちが先に実行されるかは不明なので順番を考慮しないようにしましょう。



deploy では
RENEWED_DOMAINS:更新されたドメイン名の一覧 (半角スペース区切り)
RENEWED_LINEAGE:新しい証明書と暗号鍵を含む live サブディレクトリ名
の環境変数が利用可能なので有効活用しよう。
ただし FreeBSD の certbot (py27-certbot-0.25.1,1) では変数がセットされたりされなかったりと不安定だったので、RENEWED_LINEAGE については直打ちで対処しよう。

他には CERTBOT_* なんて環境変数もあるが、ろくに使えないので使わない方がいい。
特に CERTBOT_DOMAIN は証明書のコモンネームを保持していると思いきや、証明書で SANs を使うと一番最後にオーセンティケーターで承認したドメイン名が保存されているのでコモンネームと一致しない。
コモンネームを取得したいのであれば RENEWED_LINEAGE を / で区切った一番最後の文字列を取得すると良い。
echo ${RENEWED_LINEAGE} | awk -F/ '{print $NF}'

最終:2018/09/22 04:00:20 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/20
Let's Encryptでワイルドカード証明書を発行する その2
先日の日記で説明した --manual --preferred-challenges dns とフックスクリプトを使った Dynamc DNS による証明書取得だが、スクリプトを使わずとも --dns-rfc2136 を使えば Dynamic DNS による証明書の取得が出来るのでそれを使うことにする。



どうも CentOS では上手く行かなかったので「その1」を使用している。
こちら (その2) は FreeBSD 11.2-RELEASE p3 の
  • py27-certbot-0.25.1,1
  • py27-certbot-dns-rfc2136-0.25.1
を使用しているので、それらを pkg でインストールしておく。



--dns-rfc2136 のドキュメント
Welcome to certbot-dns-rfc2136’s documentation!

やること
  • ACME Challenge 用 Dynamic DNS ゾーン (_acme-challenge.*) の作成
  • Dynamic DNS 操作用鍵の作成
  • certbot certonly --dns-rfc2136 の実行と renew


dnssec-keygen で Dynamic DNS 更新用の鍵を作成する。
アルゴリズムは HMAC-SHA512、キー名は "ac_gwnet" とした。
% dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 256 -n HOST ac_gwnet
Kac_gwnet.+165+18145

% cat Kac_gwnet.+165+00000.key
ac_gwnet. IN KEY 512 3 165 Dummy+Key+Strings=

作った鍵は所有者以外みえないようにしておくように。
% chmod 600 K*

鍵ファイルは /etc/letsencrypt/ (FreeBSD の pkg で certbot をインストールしたら /usr/local/etc/letsencrypt/) の下にディレクトリを作り、その中に入れておくと良い。
# ちゃんと管理出来るならどこでもいい。



ゾーンの作成。
% sudoedit named.conf
# ACME Challenge 用 Dynamic DNS 操作鍵
key "ac_gwnet" {
  algorithm  hmac-sha512;
  secret     "Dummy+Key+Strings=";  ← 作った鍵の中に書いてあるハッシュ値
};

# ACME Challenge 用 Dynamic DNS ゾーン
zone "_acme-challenge.griffonworks.net" {
 type master;
 file "/var/named/dynamic/_acme-challenge_griffonworks_net.zone";
 allow-update { localhost; key ac_gwnet; };
 check-names ignore;
 allow-transfer  { localhost; };
};

ACME Challenge 用ゾーン設定。Dynamic DNS なのでデフォルト TTL とネガティブキャッシュ TTL は短めに。
% /var/named/dynamic/_acme-challenge_griffonworks_net.zone
$ORIGIN _acme-challenge.griffonworks.net.
$TTL 60
@ IN SOA sakura.griffonworks.net. root.griffonworks.net. ( 20180920 3H 10M 1W 1M )
  IN NS  sakura.griffonworks.net.

権限委譲設定。権限委譲元のゾーンに権限委譲先のドメイン名を書く。
% /var/named/dynamic/griffonworks_net.zone
(省略)
_acme-challenge.griffonworks.net.  IN  NS  sakura.griffonworks.net.

DNS の準備が出来たら確認。
できれば受信側の DNS サーバーで named.log を tail しておくと良い。
% nsupdate -k Kac_gwnet.+165+18145.key
>server x.x.x.x    ← DNSサーバーのアドレスを指定。localhost なら localhost。
>update add test._acme-challenge.griffonworks.net. 10 IN TXT "TestRecord"
>send

% digna +noall +ans +ques TXT test._acme-challenge.griffonworks.net.
;test._acme-challenge.griffonworks.net. IN TXT
test._acme-challenge.griffonworks.net. 10 IN TXT "TestRecord"   ←登録出来た

テストし終えたら削除しておく。
% nsupdate -k Kac_gwnet.+165+18145.key
>server x.x.x.x   ← DNSサーバーのアドレスを指定。localhost なら localhost。
>update delete test._acme-challenge.griffonworks.net.
>send

% digna +noall +ans +ques TXT test._acme-challenge.griffonworks.net.
;test._acme-challenge.griffonworks.net. IN TXT



証明書取得のための certbot 用設定ファイルの作成。
今回は certbot から Dynamic DNS の更新リクエストを DNS サーバーに投げるので、それ用の設定ファイルが必要。

[ /etc/letsencrypt/renewal-hooks/griffonworks.net.ini ]
※ファイル名は適当。
# Target DNS server : Dynamic DNSの更新リクエストを投げる先のDNSサーバーアドレス
dns_rfc2136_server = x.x.x.x
# Target DNS port
dns_rfc2136_port = 53
# TSIG key name : 鍵で使用したキー名
dns_rfc2136_name = ac_gwnet
# TSIG key secret : 鍵の中に書かれているハッシュ値
dns_rfc2136_secret = Dummy+Key+Strings=
# TSIG key algorithm : 鍵を作るときに使用したアルゴリズム
dns_rfc2136_algorithm = HMAC-SHA512



では証明書を取得してみる。
まずは --staging で!
% sudo certbot certonly -m griffon@griffonworks.net --staging \
   -d griffonworks.net \
   --manual-public-ip-logging-ok \
   --dns-rfc2136 \
   --dns-rfc2136-credentials /usr/local/etc/letsencrypt/renewal-hooks/griffonworks.net.ini \
   --force-renewal \
   --dns-rfc2136-propagation-seconds 10
オプションの一部を説明。
  • 証明書証明リクエストの認証方式にダイナミックDNS更新を利用する (--dns-rfc2136)
  • ダイナミックDNS更新利用時の設定ファイル (--dns-rfc2136-credentials)
  • ACME サーバーが DNS を参照するまでの待ち時間 (--dns-rfc2136-propagation-seconds)。DNS更新が早いならば短くして良い。
% sudo certbot certonly (省略)
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for griffonworks.net
Waiting 10 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /usr/local/etc/letsencrypt/live/griffonworks.net/fullchain.pem
   Your key file has been saved at:
   /usr/local/etc/letsencrypt/live/griffonworks.net/privkey.pem
   Your cert will expire on 2018-12-19. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
もし Dynamic DNS 更新に失敗したら "PluginError: Received response from server: REFUSED" と言われるので、鍵情報が間違ってないかなどを確認しよう。

参考:named.log (TXT レコードの登録時)
20-Sep-2018 13:25:26.982 update-security: client 219.75.232.51#62490: signer "certbot" approved
20-Sep-2018 13:25:26.982 update: client 219.75.232.51#62490: updating zone '_acme-challenge.griffonworks.net/IN': adding an RR at '_acme-challenge.griffonworks.net' TXT
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_timer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_maintenance: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:26.984 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
参考:named.log (TXT レコードのクリーンナップ時)
20-Sep-2018 13:25:35.673 update-security: client 219.75.232.51#62492: signer "certbot" approved
20-Sep-2018 13:25:35.673 update: client 219.75.232.51#62492: updating zone '_acme-challenge.griffonworks.net/IN': deleting an RR at _acme-challenge.griffonworks.net TXT
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_timer: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_maintenance: zone _acme-challenge.griffonworks.net/IN: enter
20-Sep-2018 13:25:35.675 general: zone_settimer: zone _acme-challenge.griffonworks.net/IN: enter
成功したらあとは certbot renew --cert-name [CN名] で証明書の更新を行う。

ステージングサイトからのドメイン名削除と本番機で反映をお忘れずに。

最終:2018/09/21 19:05:22 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/19
MewとTLS(STARTTLS)とSSL(SMTP over SSL)と
超どはまりした。
6、7時間くらいは失ったんじゃないかな?orz



先に結論を書くと、ちゃんと Mew のマニュアルには書いてあるのだが TLS/SSL という用語がプロトコルの違いだと勘違いしていたのがそもそもの始まりでして。
TLS = STARTTLS
SSL = SMTP over SSL
ということに気がついたのが深夜 3時。
こういうややこしいのは TLS/SSL とか書かないで欲しいんだけど!

9.4 Secure Socket Layer
9.5 Transport Layer Security
SSL と TLS と STARTTLS の違い



事の始まりは .mew.el を触って SMTP 送信しようとしたら "Creating an SSL/TLS connection..." で刺さって帰ってこなくなったので調査開始。

.mew.el に
(setq mew-debug t)
を書いてメールを送信する。
すると "Creating an SSL/TLS connection..." で刺さるので C-g で中止してから C-x b で *Mew debug* を表示させる。
# ちなみに元に戻るにはもう一度 C-x b したら "Switch to buffer (default %inbox):" と聞いてくるのでそのままリターンで Mew に戻れる。

stunnel を使っているので stunnel が利用する一時設定ファイルは /tmp/ に作られる。
こっちもちょっと確認する。

[ (smtp-port . 587) ]
<SSL/TLS: >
2018.09.19 03:29:39 LOG3[0]: s_connect: connect 153.126.183.190:465: Connection refused (61)

% cat /tmp/griffon22650KWU/mew226506hM
client=yes
pid=
verify=0
foreground=yes
debug=debug
libwrap=no
syslog=no
CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/
CAfile=/usr/local/share/certs/ca-root-nss.crt
[11337]
accept=127.0.0.1:11337
connect=mail.griffonworks.net:465
"Creating an SSL/TLS connection..." で刺さる。

んんん?TCP-465?SMTP over SSL?TCP-587を指定してるのに?

一旦 Mew を終了。
なお、送信失敗したメールは +queue に溜まるので C-u C-c C-c で再送できるので、刺さり続けるならば新規メールを作る必要は無い。

[ (smtp-ssl-port . 587) ]
<SSL/TLS: >
2018.09.19 03:34:14 LOG5[0]: s_connect: connected 153.126.183.190:587
<SSL/TLS: > 2018.09.19 03:34:14 LOG3[0]: SSL_connect: 140770FC: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
<SSL/TLS: > 2018.09.19 03:34:14 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.09.19 03:34:14 LOG7[0]: Deallocating application specific data for session connect address 2018.09.19 03:34:14 LOG7[0]: Remote descriptor (FD=7) closed 2018.09.19 03:34:14 LOG7[0]: Local descriptor (FD=3) closed 2018.09.19 03:34:14 LOG7[0]: Service [11065] finished (0 left) % cat /tmp/griffon22698wWU/mew22698giM client=yes pid= verify=0 foreground=yes debug=debug libwrap=no syslog=no CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/ CAfile=/usr/local/share/certs/ca-root-nss.crt [11385] accept=127.0.0.1:11385 connect=mail.griffonworks.net:587
"Creating an SSL/TLS connection..." で刺さる。

今度はちゃんと TCP-587 で繋がってるけど "unknown protocol" で接続出来ん。
というか SSLv2/SSLv3?TLSv1 じゃなくて?

一旦 Mew を終了。

らちが明かないのでバックアップの .mew.el を書き戻すと繋がった。
何がおかしいのかと比較してみたら smtp-port と smtp-ssl-port が両方指定されていたので疑問に思いつつ。

[ (smtp-port . 587) と (smtp-ssl-port . 587) ]
<SSL/TLS: >
2018.09.19 03:37:20 LOG5[0]: s_connect: connected 153.126.183.190:587
<SSL/TLS: > 2018.09.19 03:37:20 LOG5[0]: Service [11442] connected remote server from 192.168.1.10:62152
2018.09.19 03:37:20 LOG7[0]: Setting remote socket options (FD=7) 2018.09.19 03:37:20 LOG7[0]: Option TCP_NODELAY set on remote socket 2018.09.19 03:37:20 LOG7[0]: Remote descriptor (FD=7) initialized <SSL/TLS: > 2018.09.19 03:37:20 LOG7[0]: <- 220 sakura.griffonworks.net ESMTP Postfix 2018.09.19 03:37:20 LOG7[0]: -> 220 sakura.griffonworks.net ESMTP Postfix % cat /tmp/griffon22755fXU/mew22755PjM client=yes pid= verify=0 foreground=yes debug=debug libwrap=no syslog=no CApath=/home/griffon/Mail/#imap/griffon@mail.griffonworks.net#imap/inbox/ CAfile=/usr/local/share/certs/ca-root-nss.crt [11442] accept=127.0.0.1:11442 connect=mail.griffonworks.net:587
protocol=smtp
お、"SMTP LOGIN password (griffon):" でパスワード聞いてきた。

"protocol=smtp" が増えてるって事は…… smtp-ssl-port だけの時の動作不良は opens s_client で -starttls したときにプロトコルを指定しなかったときの動作を同じか。

というわけで冒頭の結果に至る。

STARTTLS を使用するときは smtp-ssl-port と smtp-port の両方を指定しましょう。



Mew でサーバ証明書 (CRT) の検証をする場合。
必要な証明書はルート証明書であり中間証明書 (Let's Encrypt は中間証明機関) は不要。

証明書が Mew を使うサーバーに有る場合は mew-ssl-cert-directory で証明書を保存しているディレクトリを指定する。
# サーバー管理者は http://www.mew.org/Release/certs-*.tar.gz をダウンロードし、鯖の公開出来るようなディレクトリで公開すると良い。
例)
(setq mew-ssl-cert-directory "/usr/local/share/certs")
無い場合は ~/.certs/ にルート証明書を置く。
どの証明書を使うかは、鯖で使っている証明書の証明機関がどこかによって変わる。
例えば Let's Encrypt なら、Lets の証明書を見てみるとルート証明機関は "DST Root CA X3" なので、この証明機関の CRT 証明書を入手する。
# Windows 使いなら IE から "Base64 encoded X.509 (.CER)" で、Firefox なら "X.509 証明書 (PEM)" で証明書をエクスポートすると良い。

ファイル名に法則が有り、以下のようにファイル名を決める。
openssl x509 -hash で出てきた文字列+".0" をファイル名とする。
% openssl x509 -hash -noout -in ./.certs/cafile.crt
2e5ac55d.0
% mv cafile.crt 2e5ac55d.0.0
面倒臭かったら mew-config-alist の中で
; 証明書を検証しない
(ssl-verify-level . 0)
としてもいいけどフェイクサイトかどうか判断出来ないのであまりよろしくはない。

最終:2018/09/20 01:37:13 カテゴリ:
タグ:鯖管理
  • 安田幸子:他に連絡先が見つかりませんでしたのでコメント欄から失礼いたします。以前イギリスのデジタルマーケティング会社の要請で記事コラボレーションのご依頼についてご連絡させていただきました。この度プロジェクト内容に変更があり、謝礼金も大幅に増額されましたので、貴サイトのように信頼あるサイトで再検討して頂きたくご連絡しております。当方クライアント指定のキーワードを使って、指定ウェブページにリンクする記事執筆或いは既存記事への追記というのがご依頼の内容でございます。こちらのサイトの主旨に背かない範囲でのお願いです。そのようなご依頼に対する対応は可能でしょうか。特定商品の宣伝ではない、一般的な文です。もしよろしければ弊社並びにクライアント情報、新しい謝礼金も含めまして詳細についてメールでご説明させて下さい。どうぞよろしくお願いいたします。sachikoyasuda1604@gmail.com
  • G兄:そのような案件はお受けしておりませんのでよろしくお願いします。
TrackBack URL:[]
 2018/09/17
MewでSSL over POP3/SMTPが使えなくなった
さくらのVPSにメール機能を集約するため、POP3 と SMTP の SSL 化を実施。
代表的なメーラー (Thunderbird、秀丸メール、電信八号) で送受信できたので Mew で…と思ったらなんかつながらない。
Creating an SSL/TLS connection...
と出たきり刺さって帰ってこないので C-g で殺す。

結論から言うと
  • stunnel がリンクしてる OpenSSL が古い (SSLv3 で繋ぎに行ってる可能性)
  • stunnel が使う chipher がサポートされていない (FIPS なんちゃらのエラー)
  • Mew が新しい stunnel をサポートしていない
ということだった。



.mew.el に次の1行を書いてログ記録モードにする。
(setq mew-debug t)
これで mew を起動し、"i" でメールを取り込む。
ささったら C-g して止めてから C-x b で *Mew debug* を見る
すると
<SSL/TLS: >
2018.09.17 01:12:07 LOG3[42074:676788736]: SSL_connect: 14094410: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failurer
SSLv3 でアクセスしてる…って、stunnel がリンクしてる OpenSSL のライブラリが古いままだったようなのでビルドし直す。
# ちなみに接続先は SSLv3 をサポートしてません。

こんどはどうだ?と思ったらまだ刺さる。
<SSL/TLS: >
Reading configuration from file /tmp/griffon59303mzo/mew59303x_X
FIPS_mode_set: F06D065: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported
うーん、これは流石に原因がわかるまでに時間がかかった。
とりあえず stunnel が更新されてないかを見てみると stunnel 5.49 があったのでビルド→インストール。
すると刺さりはしなかったがエラーになったので *Mew debug* を見てみると stunnel のヘルプが出ていた。

stunnel のバージョン表示したらなんかわかるかな?と思って表示してみたら
/usr/source/stunnel-4.34% stunnel -version
stunnel 4.34 on i386-unknown-freebsd8.0 with OpenSSL 1.0.2p  14 Aug 2018
:
:
Service-level options
cert     = /usr/local/etc/stunnel/stunnel.pem
ciphers  = FIPS
curve = sect163r2

/usr/source/stunnel-5.49% stunnel -version
stunnel 5.49 on i386-unknown-freebsd8.0 platform
:
:
Service-level options:
ciphers  = FIPS (with "fips = yes")
ciphers  = HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK (with "fips = no")
curve = prime256v1
あぁ、chipherが対応してなかったのか〜というわけで問題は Mew。
Mew で stunnel 5系が使えないのでちょっとぐぐってみると、どうやらバージョンアップが必要なようなので Mew 6.8 を落としてきてビルド→インストール。

そして実行してみると無事 SSL over POP3/SMTP が実行できたとさ。

最終:2018/09/20 01:47:35 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/16
Let's Encryptでワイルドカード証明書を発行する
今回は「さくらのVPS」で Linux OS (CentOS - RedHat6 final) を使っているということもあり、certbot-auto が使えてます。
え?今まではどうやってるのかって?

手動でやってんだよ!!!!

マジクソ面倒臭い。
でも certbot-auto にしても微妙に面倒臭いのは変わりない。 意外と楽でした。



と、その前に。

証明書をインストールしたはいいが、不正な証明書だと言われたら cert.pem から fullchain.pem に変更しよう。
というか fullchain.pem の方がなにかと良い結果になる。
これは OS やブラウザに Let's Encrypt の中間証明書が入っていないのが原因なので、証明書に中間証明書を混ぜ込んでしまう。
# 今回は K-9 Mail でおおはまり。



結論から言うと「Amazon Route53 使ってるならワイルドカードの自動更新は (説明が多いから) 簡単だけど、他の DNS を使ってるならば「どうやればいいのか」を探すところから始めなければならないのでとても面倒くさい。
# 一応、認証方式に Dynamic DNS を使った更新 (certonly → --dns-rfc2136) は有る。

もうワイルドカード使わずに webroot のオーセンティケーター (Apache の Web 型承認) でいいんじゃね?と思う次第。



まずは基本。
  • -m は忘れずに!(期限が近づいてきたらメールで知らせてくれる)
  • 指定した基本的なオプションは conf ファイルに保存される。--staging や --post-hook なども全て。ただし revoke の時は --staging は付ける必要有り。どんなオプションが保存されているかは /etc/letsencrypt/renewal/*.conf を見よう。
  • 更新は certbot-auto renew と叩くだけ。あとは certbot-auto が良きに計らってくれる。複数のドメインを別の証明書で作った場合は --cert-name で CN の名前を指定する。
  • 使い終わった証明書はステージング環境であっても revoke しておこう。まぁ期限が来たら勝手に消えると思うけど。
使い方。
certbot-auto に勝手に証明書をインストールさせないために、サブコマンドは "certonly" を使用すること。
このサブコマンドは証明書を発行して貰いサーバーの /etc/letsencrypt/ に保存するだけのコマンド。
install とか run とか使うとどこかにインストールされてしまうので注意。

httpd が起動している Web サーバーで証明書を発行してみよう。
% sudo certbot-auto certonly --webroot \
    -m [自分のメールアドレス] \
    -w [ホスト名に対するディレクトリルート] \
         -d ホスト名 \
    --manual-public-ip-logging-ok
例)
% sudo certbot-auto certonly --webroot \
    -m [自分のメールアドレス] \
    -w /home/www/defaultroot/public_html/ \
         -d www.example.com \
    -w /home/www/test/public_html/ \
         -d test.example.com \
    --manual-public-ip-logging-ok
オプションの順序は関係ないと思うけど、オーセンティケーターに webroot を使うなら -w を先に書いて -d は後ろに書いた方がいいかもしれない。
# 説明ではそうなってるし。
複数のドメインを含めるならば -w -d -w -d … と続く。

本番機に何度もリクエストを投げるとアクセス制限を食らうので、使い方がよくわからないな〜という人や動きを確認したいだけならば --staging を付けて実行。
これは制限の緩いテスト環境 (conf ファイルでは server = https://acme-staging-v02.api.letsencrypt.org/directory の 1行がある) を使用するオプション。



certbot-auto の使い方は「Let's Encrypt ユーザーガイド」を参照すること。
「コマンド解説(コマンドリファレンス)」は旧式の使い方なので、参考にはなるけど増えてるオプションの解説が無い。



まず前提条件。
ワイルドカードとネイキッドドメインのホスト名部別扱いになる。つまり
example.com ≠ *.example.com
となる。
なので *.example.com の証明書を発行しても example.com の証明書にはならないということ。
# *.example.com だけの証明書を持つサーバーに example.com でアクセスすると不正な証明書になる。
# example.com が記述されていないので当然ではあるが。



テストをする際は最新の certbot-auto だと ACME v2 に対応しているので
% sudo certbot-auto certonly --manual --staging \
    -m [メールアドレス] -d "*.自ドメイン" \
    --manual-public-ip-logging-ok --force-renewal
でテスト可能。

例)
% sudo certbot-auto certonly --manual --staging \
    -m [メールアドレス] -d "*.example.com" \
    --manual-public-ip-logging-ok --force-renewal
説明。
  • オーセンティケーターは手動 (--manual)
  • ステージング環境を使用する (--staging)
  • グローバルIPアドレスを認証局でロギングすることに対する確認を表示しない (--manual-public-ip-logging-ok)
  • 期限が残っていようが問答無用で再発行する (--force-renewal)
--dry-run を着けない場合は既存の証明書が無効な証明書 (=いわゆる「証明機関で証明されていない無効な証明書」俺俺証明書みたいな感じ) で上書きされるが、その場合は先にバックアップを取っておくか、素直に上書きしてあとから正規の証明書を作り直す。
本番で使ってるなら気をつけてね!!
ここで重要なのは

--staging を着けるとテストモードになる。

なんでテストをするのかって?
ちゃんと証明書の発行が出来るか、更新が出来るかを確認するために。
本番環境では証明書発行・更新の回数制限があるので要注意。
なおテストモードは制限がかなり緩い。
詳しくはこちらを。
制限と仕様からLet's Encrypt(ACMEv1)の話



更新するときは certbot-auto renew を実行。
これだけ。すごいかんたん。
証明書の更新時期が来てなければ certbot-auto が勝手に判断して更新せずに終了。
えらい。

cron に登録しておこう。

なお、1つのサーバー上で複数の証明書を管理している場合は --cert-name で CN の名前を指定すると良い。

例)
% sudo certbot-auto renew --cert-name 2nd.example.com
CN とは簡単に言うと証明書が持つメインとなるドメイン名で、-d の一番初めに指定したドメイン名が該当する。
/etc/letsencrypt/ のディレクトリに証明書が格納されている各ディレクトリ名がそれ。



本番環境で作成した証明書を消す場合は、Lets Encrypt サーバーに置いてある履歴を消す必要があるので revoke 処理を行う。
ステージング環境を使用した場合は必ず --staging を付けること。
% sudo certbot-auto revoke --cert-path [fullchain.pem のフルパス]
例)
% sudo certbot-auto revoke \
    --cert-path /etc/letsencrypt/live/www.example.com/fullchain.pem
revoke しても再作成 (再申請) は可能。

消さなくても期限が超えたら消えると思う…。



オーセンティケーターに --manual を選んだとき、ドメイン使用権の認証方式に DNS 認証を使うならば "--preferred-challenges dns" を着ける。
(デフォルトは http)
% sudo certbot-auto certonly --manual --staging \
    -m [メールアドレス] -d [ホスト名] \
    --manual-public-ip-logging-ok \
    --force-renewal --preferred-challenges dns



さて、自ドメインにサブドメイン切って --preferred-challenges dns による自動更新を行ってみる。
参考にしたのは

Certbotによるワイルドカード証明書と自動更新の設定

だが、dns-01 スクリプトの書式に間違いがあったので修正している。
# nsupdate に渡すコマンドの先頭に update の記述が無いので "delete メソッドなんぞ知らぬ!" と怒られる。


まずは Dynamic DNS の準備。
Dynamic DNS のゾーンは分けておかないと元のゾーンが Dynamic DNS によりぐちゃぐちゃにされるのでちゃんと分ける。
以下のように親のゾーンである griffonworks.net. から権限委譲して別ファイルにすると良い。
TSIG 鍵は nsupdate -l で運用する (ローカルホスト限定) ので今のところは不要。
$ORIGIN griffonworks.net.
$TTL 86400
@ IN SOA leviathan.griffonworks.net. root.griffonworks.net. (
:
(省略)
:
ddns IN NS sakura.griffonworks.net.
[ /var/named/dynamic/ddns_griffonworks_net.zone ]
$ORIGIN ddns.griffonworks.net.
$TTL 60
@ IN SOA leviathan.griffonworks.net. root.griffonworks.net.
                            ( 2018091800 10800 600 604800 60 )
                        NS      ns.griffonworks.net.
named.conf は "_" (アンダーバー/アンダースコア) を使用するので "check-names ignore" は必要。
[ /etc/named.conf ]
zone "ddns.griffonworks.net" {
        type master;
        file "/var/named/dynamic/ddns_griffonworks_net.zone";
        allow-update { localhost; };
        check-names ignore;
};
この時、/var/named/dynamic/ddns_griffonworks_net.zone のパーミッションは named が更新する必要があるので named:named に chown しておくこと。
 # mkdir /var/named/dynamic/
 # chown named:named /var/named/dynamic/
 # chmod 770 /var/named/dynamic/
 # vi /var/named/dynamic/ddns_griffonworks_net.zone
 # chown named:named /var/named/dynamic/ddns_griffonworks_net.zone
 # chmod 644 /var/named/dynamic/ddns_griffonworks_net.zone
テストするなら以下のように。
ちゃんと
ホスト名  TTL値  IN  TXT  値
書式でないと受け付けられません。
% nsupdate -l
> update add test.ddns.griffonworks.net. 10 IN TXT "teststrings"
> send
> (CTRL+D で抜ける)

% dig TXT test.ddns.griffonworks.net.
;; ANSWER SECTION:
test.ddns.griffonworks.net.  10 IN TXT  "teststrings"

% nsupdate -l
%gt; update delete test.ddns.griffonworks.net.
%gt; send
> (CTRL+D で抜ける)

% dig TXT test.ddns.griffonworks.net.
(返信無し)

今度は certbot-auto。
まずは前準備としてフック用のスクリプトを用意。
参考:certbot User Guide - Pre and Post Validation Hooks
実行属性は付けておいてください。
オーナーはてきとー。

[ /etc/letsencrypt/renewal-hooks/dns-01-auth.sh ]
#!/bin/sh

# certbot-auto を実行すると CERTBOT_VALIDATION に認証キーがセットされる。
[ "$CERTBOT_VALIDATION" = "" ] && exit 0

# nsupdate を localhost モード (-l) で動かす。
cat <<_TXT_ | nsupdate -l
update delete _acme-challenge.${CERTBOT_DOMAIN}. IN TXT
update add _acme-challenge.${CERTBOT_DOMAIN}. 10 IN TXT "${CERTBOT_VALIDATION}"
send
_TXT_
[ /etc/letsencrypt/renewal-hooks/dns-01-clean.sh ]
#!/bin/sh
cat <<_CMD_ | nsupdate -l
update delete _acme-challenge.${CERTBOT_DOMAIN}. IN TXT
send
_CMD_
まずは初回の証明書発行。
ちゃんとステージング環境 (--staging) で試しましょう。
% sudo certbot-auto certonly \
    -m [自分のメールアドレス] \
    --preferred-challenges dns \
    --staging \
    --manual \
    --manual-public-ip-logging-ok \
    -d "*.ddns.griffonworks.net" \
    --manual-auth-hook /etc/letsencrypt/renewal-hooks/dns-01-auth.sh \
    --manual-cleanup-hook /etc/letsencrypt/renewal-hooks/dns-01-clean.sh 
説明。
  • ドメイン使用権の認証方法に DNS の TXT レコードを使用する (--preferred-challenges dns)
  • 認証の承認リクエストを受けた時に実行するスクリプト (--manual-auth-hook)
  • 認証の承認リクエストを受けた後に実行するスクリプト (--manual-cleanup-hook)
実行結果。
% sudo certbot-auto 〜
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for ddns.griffonworks.net
Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/ddns.griffonworks.net/privkey.pem Your cert will expire on 2018-12-17. 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"
もしスクリプトにエラーがあったらちゃんとエラーが出る。
スクリプトで何をやってるか気になるなら nsupdate -l にパイプしてる内容を一時ファイルに書き出し、一時ファイルを nsupdate に喰わせるスクリプトに変更して、一時ファイルを cat してみると良い。

普段は renew を実行するだけで良い。
% sudo certbot-auto renew --cert-name ddns.griffonworks.net --staging 
試しに強制的に証明書を更新 (--force-renewal) してみる。
% certbot-auto renew --cert-name ddns.griffonworks.net --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/ddns.griffonworks.net.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for ddns.griffonworks.net
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

% openssl x509 -text -in ./live/ddns.griffonworks.net/cert.pem | more
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Fake LE Intermediate X1
        Validity
            Not Before: Sep 18 04:26:13 2018 GMT
Not After : Dec 17 04:26:13 2018 GMT
Not Before: が現在の時間になっていることが確認出来る (夏時間に注意)。
ちなみに "Issuer: CN=Fake LE Intermediate X1" はステージング環境のこと。
本番だと "Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" になる。

いろいろお試しが終わったら revoke しておきましょう。
% sudo certbot-auto revoke --staging \
    --cert-path /etc/letsencrypt/live/ddns.griffonworks.net/fullchain.pem
このフック機能、"certbot User Guide - Pre and Post Validation Hooks" を見ると http にも対応しているので、scp とノーパスの鍵を組み合わせれば certbot-auto 実行サーバーと Web サーバーを分離出来たりするが、それはまた別のお話。

なお、ネイキッドドメインの DNS 認証については、先に紹介したい「Certbotによるワイルドカード証明書と自動更新の設定」の開設で _acme-challenge ゾーンを個別に切って (権限委譲で分離) Dynamic DNS ゾーンにすることで対応出来た。
% sudo certbot-auto certonly \
    -m griffon@griffonworks.net \
    --staging --manual --manual-public-ip-logging-ok \
    -d "*.griffonworks.net" -d griffonworks.net \
    --preferred-challenges dns \
    --manual-auth-hook /etc/letsencrypt/renewal-hooks/dns-01-auth.sh \
    --manual-cleanup-hook /etc/letsencrypt/renewal-hooks/dns-01-clean.sh

最終:2018/09/18 13:37:20 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2018/09/04
台風21号とサーバーメンテナンス
今年最強の台風が来るということで一応警戒はしていたが、予想をはるかに超えた大惨事で外は大変なことになっていた。
# 大阪にしてはこれほど酷いのは珍しい。室戸台風以来?

今日は仕事が休みになったので自宅待機していたが、昼過ぎに暴風が吹いている最中に部屋の電灯がちらちらしはじめる。
と、一瞬ちょっと長めの瞬断が発生。


同時に鯖が電源落ちて死亡。orz
# USP?そんなものはない。


こりゃやばいということで早速シリアルケーブルで繋いで……メインPCにシリアルポートが無い orz
しかたがないのでディスプレイに繋いでコンソールでログオンして確認すると、どうもバッドセクタが出来た模様。
起動するにもかなり面倒なことになっていたが、なんとか復旧したので外付けの USB HDD に dump/restore でシステムドライブのバックアップを取っておく。
# 1年ぶりか?

% mount /dev/da0s1a /mnt
% cd /mnt
% dump -0af - / | restore rf -
※ちゃんと cd してから restore しましょう。

ついでにそのシステムドライブから USB HDD ブート出来るかも確認してみたが、どうもカーネルはロード出来ているがユーザランド(?)がだめっぽい。
しかし何度かいろいろと変更して試していると、なぜか起動出来るようになったのが更に謎。

システムディスクからは きゅ〜↑〜↓〜〜〜↓↑↑↓↑〜〜〜 というグリスの切れたような抑揚する音がかすかに聞こえたのでこりゃシステムドライブ交換かな、と中を開けて見たら、なんとシステムディスクは PATA でした。orz
# ST3120026A って型番で嫌な予感はしてたんだよね。SATA なら AS だし。
マザー:PATA→SATA:HDD という変換基板はあるものの変換基板が入るスペースがない (直上が HDD ベイ) ので USB ブートで凌ぐか、と思いつつ、とりあえず就寝。
# PCI スロットに SATA 増設 IF 着けることも考えたがブート出来ない。
# 内部 SATA に繋いでる RAID HDD 2本を PCI スロットの SATA に繋げば、と思ったが、atacontrol の RAID が degrade する可能性も有るので出来ればやりたくない。

結局日付変更線が変わって早朝 4時頃までかかって作業が終わったので就寝。
しかしどうも鯖の きゅ〜 という音が気になって仕方がないのでシステムドライブを外すべく一度シャットダウンして HDD の電源とケーブルを抜いて電源 ON !


きゅ〜〜〜〜


え?HDDじゃない?まさか RAID 側?と思って青くなりつつ RAID の HDD を 1本ずつ抜いてみたが音は収まらず。
ということは電源ファンか?と思って、爪楊枝をつっこみつつ電源を入れてみたが音は消えず。
しばらく音の出所を考えた結果、CPU ファンと予想。
耳を澄ましてみると確かに CPU ファンから聞こえる。
そこで CPU ファンを買い置きしていたバックパネル用の小さめのファンに交換して電源を入れてみたところ、以前より静かになってフイタ
ファンは CFY-40S というものでヨドバシに売っていたので、届き次第またメンテナンスします。

ファンの買い置き、マジ重要。

最終:2018/09/06 10:02:21 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2014/06/24
久しぶりにディスク障害 - その後
HDD を繋げるのに難儀したがデータのコピーについては支障なく完了。
最終的には PATA Master に障害の出た HDD を、PATA Slave に Seagate ST3120026A (120GB) を繋げて 2.5インチ USB HDD でブート。
Single user mode に落ちて fdisk でパーティション作って bsdlabel でスライス作って newfs して /dev/ad1 (ST3120026A) をマウントして試しに /usr を dump | restore。
# cd /mnt/usr
# dump -0af - /dev/ad0s1f | restore -rf -
3時間くらいかかったもののリトライやタイムアウトもなぜか出ずにコピー完了。
そのまま / と /var を dump | restore してシャットダウン。
ST3120026A を Master に繋げ直して起動したら無事に起動したのでそのまま運用。
世代の違うHDDだから音が静かだわ。
熱が凄いけど。



買ってきた 3.5インチ USB2.0 箱に Seagate 7200.8 の 250GB SATA をつっこんで鯖に接続、fdisk と bsdlabel でスライス切ってパーティション作って dump | restore でバックアップ。
今度からは定期的にバックアップを取ろう・・・。

最終:2014/06/26 11:28:37 カテゴリ:
タグ:鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2014/06/23
久しぶりにディスク障害
こないだは RAID だったので刺し直してリビルドで終わったが、今回はなんとシステムディスク。
Seagate ST380020A (ゴムシールドの着いたアレ) というふる〜い HDD をしぶとく使っていたが、6月22日 21時前に鯖の応答が悪くその後応答が無くなったので強制再起動させてみるとリトライ繰り返してるのであぼん確定。
偶然にも 2.5インチ HDD にバックアップを取っていたので USB ブートしてみるとどうやら 2年前のバックアップのようだ・・・。
しかしあの当時からアプリケーションのインストールなどはやってないしほとんど更新もしていないので一部の更新のみでいけそう。
# apache の俺俺証明書と Twitter IRC Gateway、/usr/local/etc/rc.d/、/etc/ は丸ごとコピーした方が良さそうだ。

なにはともあれ 2.5インチ HDD から 250GB PATA HDD にコピーすべく USB メモリスティックに memstick.img を dd で書き込んだが、どうも FixIT が「USB デバイス見つからんよ!」でシェルが起動しない。
しかたがないので 2.5インチ HDD で起動して dd で
# dd if=/dev/da0 of=/dev/ad0 BS=10240
とやって 250GB PATA HDD にコピーしたら、なんと BIOS のブートシーケンス手前から先に進まなくなってあぼん。
(HDD を繋げているだけでアウト、かつ USB ブート可能だったデバイスを繋げても先に進まないので何も出来ない)
しかたがないので予備の 120GB HDD を繋げてシステムディスクとして使う前準備だけしておく。

次は 2.5inch HDD もしくは障害の出てる HDD から dump | restore かな・・・。

最終:2014/06/23 14:00:24 カテゴリ:
タグ:FreeBSD 鯖管理
  - NO COMMENT -
TrackBack URL:[]
 2013/09/13
ディスクトラブル
事の始まりはMRTGがad4を認識しないことから。
root# atacontrol list
ATA channel 0:
    Master:  ad0 <ST380020A/3.93> ATA/ATAPI revision 6
    Slave:       no device present
ATA channel 2:
    Master:      no device present ←あれ?ad4は?
    Slave:       no device present
ATA channel 3:
    Master:  ad6 <Hitachi HDP725050GLA360/GM4OA5CA> SATA revision 2.x
    Slave:       no device present

root# atacontrol status ar0
ar0: ATA RAID1 status: DEGRADED
 subdisks:
   0 ---- MISSING  ←ad4が居たはず・・・。
   1 ad6  ONLINE


oh・・・。(|||゚д゚)


というわけで再構築。
マスターシード JX-FX300B はホットスワップが可能なので電源を入れたまま HDD を取り出すことが出来る。
壊れた HDD を交換してから detach / attach を行う。
ちなみに作業はマルチユーザーモードでも出来た。
root# atacontrol detach ata2
root# atacontrol attach ata2
ata2:[ITHREAD]
ATA channel 2:
    Master:  ad4 <Hitachi HDP725050GLA360/GM4OA52A> SATA revision 2.x
    Slave:       no device present
念のため list で全ドライブが見えているかを確認。
root# atacontrol list
ATA channel 0:
    Master:  ad0 <ST380020A/3.93> ATA/ATAPI revision 6
    Slave:       no device present
ATA channel 2:
    Master:  ad4 <Hitachi HDP725050GLA360/GM4OA52A> SATA revision 2.x
    Slave:       no device present
ATA channel 3:
    Master:  ad6 <Hitachi HDP725050GLA360/GM4OA5CA> SATA revision 2.x
    Slave:       no device present
あとは addspare → rebuild で再構築。
root# atacontrol addspare ar0 ad4
root# atacontrol rebuild ar0
root# atacontrol status ar0
ar0: ATA RAID1 status: REBUILDING 0% completed
 subdisks:
   0 ad4  SPARE
   1 ad6  ONLINE
root# atacontrol status ar0
ar0: ATA RAID1 status: REBUILDING 6% completed
 subdisks:
   0 ad4  SPARE
   1 ad6  ONLINE

突然認識しなくなった HDD、Windows PC に繋げてみても認識しないので完全にお亡くなりの模様。

最終:2013/09/13 21:35:37 カテゴリ:
タグ:鯖管理
  • バイザー:( 人 ) 怖いですね・・・未だにHDD突然死に直面したことがないです。顧客のHDDは別ですが。
  • 山銀:お疲れ様でした〜。
  • G兄:今までの経験はデータがおかしくなるとかそんな感じだったんですけどね。
    いきなりバスから切り離されて何も見えなくなったのは初めてですよ。
TrackBack URL:[]
 2012/08/11
spam判定
  |l、{   j} /,,ィ//|     / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  i|:!ヾ、_ノ/ u {:}//ヘ     | あ…ありのまま 今 起こった事を話すぜ!
  |リ u' }  ,ノ _,!V,ハ |     < 『LAN内からコメントを付けようと思ったら
  fト、_{ル{,ィ'eラ , タ人.    |  spam認定されてしまった』
 ヾ|宀| {´,)⌒`/ |<ヽトiゝ   | IP詐称だとかDNSエラーとか
  ヽ iLレ  u' | | ヾlトハ〉.   | そんなチャチなもんじゃあ 断じてねえ
   ハ !ニ⊇ '/:}  V:::::ヽ. │ もっと恐ろしいものの片鱗を味わったぜ…
  /:::丶'T'' /u' __ /:::::::/`ヽ \____________________

なんでだよ!なんでローカルアドレスで spam 認定やねん!と思って調べてみたら list.dsbl.org の登録内容死んでね?っていうか片っ端から登録されてるとかそんなかんじ。
直近数件をチェックしてみると全部ヒットしたが、今さっきもう一度調べようとしたらなぜかタイムアウト待ちの挙動。

そこで ROOT DNS からたどっていってみると list.dsbl.org. の NS は ns[1-4].nameresolve.com. とわかったのでそこにもう一度 NS を聞いてみると違う NS を返してきやがった。
lame delegation (返答内容に違いがあること:今回は NIC に登録してある NS と自己が答えた NS に違いがある) じゃねーか!と思ってホスト名をよく見てみると
list.dsbl.org.    3600   IN   NS    stop-using-dsbl.dsbl.org.
つまり使うなってことかい。

というわけで spam 判定用 DB から外したので投稿できると思います。
該当者はお騒がせしました。

最終:2012/08/11 02:57:36 カテゴリ:
タグ:鯖管理
  • maxi:自己診断プログラム?カコイイ!!
  • G兄:数行で判断できる簡単なものですけどね。
    効いてるのか効いてないのか不明・・・w
TrackBack URL:[]
 2010/07/07
鯖の温度
廊下に面している納戸の上に押し込めているのだが、

下がりすぎ

平均 58度、最高 63度って温度高杉だろJK、というわけで扉を開けて 1時間ほど放って置いたら 47度に・・・。
旅行に行く前に自室に引っ越しするべきだなー。
再起動時のトラブルを考えると明日帰ってきてから移設するか。

というわけで 19時頃しばらく止める可能性有り。



移設完了。
自室に置こうと思ったら部屋が暑くなるだろうからリビングに置けよと言われたので TV の裏に置いてみた。

cpu-mb_temp-day.png :  , sec F ISO-

クーラー効いてる部屋だから下がりすぎwww
止めたら温度が上がってるけどそれでも 40度、4時台の高負荷時でも 50度で落ち着いたら温度は下がってるので大丈夫っぽい。
最終:2010/07/08 09:08:56 カテゴリ:
タグ:鯖管理
  • バイザー:この時期の鯖温度上昇は仕方ないですね。ウチも部屋にクーラーがないので、日中はとんでもない事になってます。最近HDDを増設したのでまたファンが増えました・・・・
  • G兄:しかたがないにしてもこの温度はないわーと思いました・・・。
  • きょーちゃん:・・・漏れの私用PCはCPU温度が70度を軽く超えているんだがw
    お陰で負荷の掛かる動作で熱暴走落ちww
    鯖じゃないのにどうすっぺ(^^;
  • G兄:その温度は明らかにおかしいだろJK・・・
    ファンとヒートシンクと吸入口排気口掃除してる?
  • きょーちゃん:綺麗に掃除していても変わらないぜ・・・凄いだろw
    CPUクーラーを交換したら多少まっしになったから、その辺に問題があるかもしれないが・・・でも負荷を掛けたら一気に温度が上がって落ちるんで、マザー含めてどこかおかしいかも(^^;
    さすがソケAの焼き鳥だぜww
  • G兄:あー、そりゃCPUが悪いわ・・・w
  • KAMI:ameblo.jp/bdmeister/entry-10583984319.html

    話を 75度斜め上にねじ曲げてみる
    もちろんG兄は 投票するんでしょう?
  • G兄:いやー、29話意外全部録画してるからいいわーw
TrackBack URL:[]
 2010/02/17
鯖運営でタイーホ!?
「無届けで自宅サーバーを運用していた」として逮捕?

( ゚д゚) ・・・
 
(つд⊂)ゴシゴシ
 
(;゚д゚) ・・・
 
(つд⊂)ゴシゴシゴシ
  _, ._
(;゚ Д゚) …!?

見た瞬間、戦慄が走ったwww

何かの間違いだろ!?と思って読んでいくとどうやら「電気通信事業法」的に問題があったようで。
詳しいことは

自宅サーバを無届けで設置すると逮捕される?

で非常にわかりやすく説明されているので割合。

更に詳しい情報となると

電気通信事業参入マニュアル[追補版] (PDF 注意)

こちらを参考にすると良いが、うちの場合は 22ページ目にある「個人が趣味で運営する電子メール」に該当するので「届け出不要の電気通信事業」になるようだ。

あーびびったびびったw

それにしても blog の中の人はグッジョブ。
よくここまで確認されたもんだ。

最終:2010/02/17 11:47:39 カテゴリ:
タグ:雑記 鯖管理
  • 窓枠:法律上はややこしいことになってますが
    ・世界的ウィルス発信源常習犯が
    ・踏み台上等な鯖上げてた
    って辺りが最大の理由のような気がしますけどね。
    普通にやってる分には問題無しって感じで。
    しっかしリンク先の blog はよく調べたもんですねぇ。
    調べりゃわかる情報とはいえ調べるのもまとめるのも結構大変ですから。
  • あぞっち:あ〜このもと記事、昨日見ましたw
    これ明らかに産経の記事がおかしいんですよねw
    http://sankei.jp.msn.com/region/kanto/saitama/100215/stm1002151538005-(略)
     #この件に関しては「あの」毎日ですらまともな記事を書いていたというのに・・・
    http://mainichi.jp/area/saitama/news/20100216ddlk11040276000c.html
    いやぁ、この記事書いた産経の記者には、記者やめて欲しいぐらい(ぉ
  • G兄:>って辺りが最大の理由のような気がしますけどね
    「仮想電子マネーが盗まれた」ってあるから別件逮捕じゃね?w
    >産経の記事がおかしい
    自分も初め見たときは目を疑いましたよえぇ・・・。
  • かとまい:まあ、これは「仮想マネー云々」がメインでしょうね。
TrackBack URL:[]
 2009/12/14
鯖の物理的移転が完了
とりあえず連絡のみ。

中身は追々。



今回はかーなーり、はまった!

まずは OPT50。
壊れたと思ってたのが実は壊れていなかった件。
というのも、設定でセッション 1用接続設定とセッション 2用接続設定があって、OPT50 はセッション 2用接続設定を内部のデフォルトゲートウェイにしていたので、いくらセッション 1用設定を変更しても接続できなかったわけ。il|l|li orz il|l|li
現在は新居で OPT90@eo光、旧居で OPT50@CyberBBを利用している。

次に DNS。
新鯖の DNS 情報は変更したけどレジストラの DNS 設定と同セカンダリ DNS の参照先の設定を忘れていてしばらく新旧混在でなかなか変わらなかった。
セカンダリ DNS だけ 1時間を超えても旧 IP アドレスを持ったままなのでおかしいなぁと思っていたが・・・。il|l|li orz il|l|li

最後にチョーやべーと思ったのがハブ死亡。
旧居で電源とケーブル抜いて新居の LAN ポートに接続して PC 繋げて「さぁルーターの設定するぞ!」と思って IP アドレスの設定をしたがなぜか ping も飛ばず。
設定を見直してもおかしいところが無かったので OPT90 に直付けすると双方で ping が飛ぶ。
まさかハブ?と思って鯖の LAN ポートのランプを見てみると緑のランプが激しく明滅。(汗)
もう一度 OPT90 に直付けすると明滅はしなくなったのでハブ死亡確定。il|l|li orz il|l|li

ちなみに配線は中央の物置最上段に eo光の WAN ポートが有り、そこに eo光電話アダプタを置いてある。
壁にはリビング行きと寝室行きの LAN ポートがあり、今はリビング行きに OPT90 の LAN を、eo光アダプタの LAN は OPT90 の WAN に接続、リビングで鯖を仮稼動させている。
近日中に物置の一番上に移設しないと・・・。

最終:2009/12/14 11:07:56 カテゴリ:
タグ:鯖管理
  • バイザー:大変お疲れ様でございました。
    >波布
    ここはひとつ、
    つ【Ciscoのスイッチ】
  • 山銀:お疲れ様でした。m(_ _)m
    今まで問題なく動作していたモノ。
    電源を抜いて差し直すと・・・なぜか壊れるものです。(^^;
  • たわし@自宅警備員:ハブなら余ってますぞ(ぉ
    ・・・ちょっとPort数の多いDualスピードの奴ですが(ナニ
    ラック用で24Portだけど極一般的な奴ですな
  • 山銀:ちと気が付いた点を連絡。
    日記のツッコミは問題ないですが、新規投稿すると画面の切り替わりが遅く処理中のまま。
    完了画面に行かないっぽいですが記事は作成されています。
    あと、phpMyAdmin はまだ動作していないみたいですね。
  • G兄@w3m:>Cisco
    いらねええええ!ww
    >なぜか壊れる
    久しぶりにそういうのにヒットしましたよ・・・。
    >デュアルスピード
    もっといらねぇ!!w
    >日記
    あとでちとIDとパスワード借りてテストしてみますね。
    基本的には変わらないはずなんだけどなぁ。
  • 山銀:>テスト
    お願いします。
    1日経過したら変わるかと思ったのですが変化なしでした。
  • カトマイ:内容はサッパリだが、とにかくお疲れサマー
  • 山銀:先程、日記を投稿したら問題なく動作しました。
    お騒がせしました。m(_ _)m
  • G兄@D4:>さっぱり
    用はポカミスと外部に依頼するのを忘れてた、と。
    >問題なく
    お、マジデスカ?それはよかったっす。:)
TrackBack URL:[]
0 | 1 | 2
QRコード
携帯サイト試験運用
https://griffonworks.net/nikki/cgi-bin/k.cgi
1行板

備忘録
  • 無し
物欲リスト
  • cactus RF60 (3本目)
    Godoxに化けました(
  • ZD 50mm Macro
  • TG-TRACKER
  • ニンバス チヌーク
ツーリング ドライブ兼野外撮影予定リスト