サーバー本体の引っ越し５月２０日 - サイトー企画へのご意見 - スレッド01423, 2022/05/17

サーバー本体の引っ越し５月２０日

秀まるお2 さん　22/05/17 08:49

　うちのWebサーバー、コミュニテックス、メールサーバーの引っ越しを、５月２０
日金曜日の早朝に実行することにします。

　一応、早朝に引っ越し作業して、９時頃には引っ越し完了状態でアクセスできるよ
うになると思います。

　早朝（たぶん６時頃）にコミュニテックスを保守モードにしてデータを新サーバー
に引っ越しし、DNSのIPアドレスを新サーバーに書き換えてコミュニテックスも再開
させます。旧サーバーにアクセスが来た場合には「引っ越ししました」の案内表示を
します。

　ニュース掲載とコミュニテックスフォーラム管理者への案内も今日中に行います。

RE:01423 サーバー本体の引っ越し５月２０

陸さん　22/05/17 08:57

　こんにちは。

　了解しました。

　1つだけアドバイスです。
　できるのであれば、AレコードのTTLを60秒とか、短くしておくとよいと思います。
　その分DNSサーバーに頻繁にアクセスが発生しますが、DNSが新サーバーに向くのに
最低限の時間だけでよくなるはずです。
　切り替えが完了して、2・3日経ってから今と同じ値に戻すとよいと思います。
　現在は600秒（10分）になってるようなので、これでも十分かとは思いますが。

　それでは。

RE:01424 サーバー本体の引っ越し５月２０

秀まるお2 さん　22/05/17 09:17

　陸さんいつもアドバイスありがとうございます。

　TTLは、残念ながら僕では書き換え出来ないです。カゴヤジャパンのコントロール
パネルでDNSの書き換えが可能なんですが、いろいろ制限があって、TTLは書き換え不
可のようです。

　DKIMを設定する用に「s._domainkey.maruo.co.jp」のようなTXTレコード追加もし
ようとしたんですが、これも不可でした。サポートに確認してもダメって言われまし
た。

　一応、引っ越し前のサーバーにアクセスが行ったら、そこに「引っ越し中です」っ
て案内を出しつつ、引っ越し先のサーバーに別ホスト名でアクセスできるようにはし
ます。さらには旧サーバーにメールによる書き込みがなされても、それも新サーバー
に転送されてちゃんと書き込みされるような仕組みも作りました。

　あと他に不安点として、コミュニテックスのユーザーさんの設定の「メール転送」
をONにしてて、会議室の発言をメールで転送するのがちゃんと届くかどうかの不安は
ありますが・・・・、一応SPFレコードも設定したしSpamhHausの解除申請も通ったの
で大丈夫だろうと思います。

RE:01425 サーバー本体の引っ越し５月２０

秀まるお2 さん　22/05/20 07:44

　一応ここにテストも兼ねて書き込みさせていただきます。

　コミュニテックスの引っ越し＆DNS書き換えは午前６時頃に完了したつもりでした
が、会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。気づいたの
が７時２０分頃でした。それまで会議室の発言が見られませんでした。

　今は大丈夫になりました。

RE:01428 サーバー本体の引っ越し５月２０

でるもんたいいじま さん　22/05/20 11:11

でるもんた・いいじまです。

> Subject: hidesoft.1:01428| RE 01425 サーバー本体の引っ越し５月２０日
>
> 　一応ここにテストも兼ねて書き込みさせていただきます。

>
> 　コミュニテックスの引っ越し＆DNS書き換えは
> 午前６時頃に完了したつもりでしたが、

> 会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。

> 気づいたのが７時２０分頃でした。

> それまで会議室の発言が見られませんでした。

>
> 　今は大丈夫になりました。

おつかれさまです。

でもちょっと、変な挙動らしきものがあります。

さきほど
https://www.maruo.co.jp/turukame/3/x10794_.html#10797
を投稿したのですが、なぜか、不必要な改行が入っています。

スクショ↓

http://e231.tokyo/@/20220520-maruo-hikkoshi/

別件の都合でメーラーの設定をUTF-8にしているのですが、

もしかしてその影響でしょうか？

とりあえずもういちど、UTF-8で投げてみます。

RE:01428 RE01425 サーバー本体の引っ越し

でるもんたいいじま さん　22/05/20 11:13

でるもんた・いいじまです。
念のためISO-2022-JPでも投げてみます。

> Subject: hidesoft.1:01428| RE 01425 サーバー本体の引っ越し５月２０日
>
> 　一応ここにテストも兼ねて書き込みさせていただきます。
>
> 　コミュニテックスの引っ越し＆DNS書き換えは
> 午前６時頃に完了したつもりでしたが、
> 会議室のHTML形式ファイルの再生成って作業をやるの忘れてました。
> 気づいたのが７時２０分頃でした。
> それまで会議室の発言が見られませんでした。
>
> 　今は大丈夫になりました。

おつかれさまです。
でもちょっと、変な挙動らしきものがあります。

さきほど
https://www.maruo.co.jp/turukame/3/x10794_.html#10797
を投稿したのですが、なぜか、不必要な改行が入っています。

スクショ↓
http://e231.tokyo/@/20220520-maruo-hikkoshi/

別件の都合でメーラーの設定をUTF-8にしているのですが、
もしかしてその影響でしょうか？

UTF-8のメールは投げましたので、今度はISO-2022-JPで投げてみます。

RE:01430 サーバー本体の引っ越し５月２０

陸さん　22/05/20 11:23

　こんにちは。

　毎回毎回、メールの件で申し訳ないんですが、今回も1つだけ気になったので。
　フォーラムのメールが送信されているサーバーですが、できれば逆引きレコードを
設定したほうがいいと思います。
　移行前は「www.maruo.co.jp」が指定されていたので、こちらを指定しておくとよ
いかと思います。
　Windowsプランでできるのかわからないんですが、インスタンスのページを開き、
「逆引き設定」のところにある「編集」ボタンをクリックして、「www.maruo.co.j
p」を指定するといいかと思います。
　ちなみに、今はカゴヤのデフォルトの逆引きレコード「v133-18-225-194.vir.kago
ya.net」が指定されています。

　参考：逆引き設定の追加
https://support.kagoya.jp/vps/manual/index.php?action=artikel&cat=40&id=51&artlang=ja

　以上、ご検討いただけると幸いです。

　それでは。

RE:01430 RE01425 サーバー本体の引っ越し

秀まるお2 さん　22/05/20 11:36

　スクリーンショット確認しました。引用行に余計な改行が入ってるみたいですが、
たぶん前々からおかしかったんだろうと思います。

　ぼちぼち調べてみます。

RE:01431 サーバー本体の引っ越し５月２０

秀まるお2 さん　22/05/20 11:37

　逆引きの設定があるのは分かってましたが、何もいじってませんでした。www.maru
o.co.jpに設定してみます。

RE:01432 RE01425サーバー本体の引っ越し

でるもんたいいじま さん　22/05/22 09:34

でるもんた・いいじまです。
＃このメールはISO-2022-JPで投げています。

> スクリーンショット確認しました。
> 引用行に余計な改行が入ってるみたいですが、
> たぶん前々からおかしかったんだろうと思います。
>
> ぼちぼち調べてみます。

よろしくお願いします。

とりあえず原因の切り分け（UTF-8からISO-2022-JPに変換する際に問題が起きている
のか、BASE64デコーダーが出力するCRLFの受け取りをアスキーモードにしていないせ
いなのか、それとも他に何かあるのか）が必要かと思いますので、簡単なテストデー
タをご用意させていただきました。

前回のスクリーンショットと同じ
http://e231.tokyo/@/20220520-maruo-hikkoshi/
に本日2022-05-22づけのzipファイルを1つ追加してありますので、よろしければご利
用ください。

RE:01434 RE01425サーバー本体の引っ越し

秀まるお2 さん　22/05/23 15:56

　再現できました。秀丸メールのバグが原因だと思います。

　まず、秀丸メールのバージョンが、Version 7.11正式版以下だろうと思います。

　それで、送信済みフォルダに残ってる投稿したメールを見ていただくと、引用行の
右端の改行記号が、普通の下矢印じゃなくて、右下ななめ方向の矢印になってると思
います。

　そういう改行になってると、メールの改行コードが２倍になってしまうバグがあり
ました。

　最新βに入れ替えていただくと、以後大丈夫だと思います。すみませんがとりあえ
ず最新βに入れ替えて、この発言にコメント投稿お願いしたいです。

RE:01435 RE01425サーバー本体の引っ越し

秀まるお2 さん　22/05/23 16:08

　すみません。Version 7.12βの最新βでも、V7.11正式版で作成した送信済みメー
ルを元にしてテストしたらダメでした。

　V7.12βで返信メールを作成すると、引用部分の改行コードが右下ななめじゃなく
て、下方向の矢印になりまして、それだと再現しないと思いますが、一応これもテス
トしてみます。

RE:01436 RE01425サーバー本体の引っ越し

秀まるお2 さん　22/05/23 16:15

　やっぱり秀丸メールとは関係なく、utf-8で投稿されたメールのデコードの問
題のような気がします。とにかく再現方法は分かったのでなんとか修正してみま
す。二転三転の書き込みでお騒がせしてすみません。

RE:01434 メールが BASE64 でエンコードさ

Iranoan さん　22/05/23 21:21

秀まるおさん今日は Iranoan です

どこあてに投稿するのが妥当のか? が良くわからないのですが、
この返信元のメール
> でるもんた・いいじまです。
> ＃このメールはISO-2022-JPで投げています。
あたりから、
> Content-Type: text/plain; charset=iso-2022-jp
> Content-Transfer-Encoding: base64
と BASE64 でエンコードされて送られています

仕様を変更したのならそれはそれで構いません
「意図せずそうなっているなら、お知らせしたほうが良いかも」と持った次第です

また秀丸メールを使っているユーザは、そもそもデコード済みデータが保存されるの
関係ありませんが、それ以外の MUA を使っているユーザは、BASE64 でエンコードさ
れていると、grep などの処理が面倒になるので、困る人がいるかもとも考えました

逆に意図して BASE64 でデコードしているなら、
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
になれば、JIS 外文字が使えるのでやり取りがしやすくなり有り難いです

RE:01438 メールが BASE64 でエンコードさ

秀まるお2 さん　22/05/24 08:39

　コミュニテックスのメール配信はここ何年もいじってませんが、しいて引っ越しに
よって変更されたとしたら、メールサーバーが、以前のIMail ServerからPMailServe
r Pro2に変更したってのはあります。しかし、メール本文のエンコードがbase64にな
るのは、以前からの仕様です。しいて言うなら同じ処理は秀丸メールでもやってます。

　メール本文の中の１行の長さの最大がある程度以上の長さになってる場合はbase64
エンコードするようにしています。そうしないと、古いメールサーバーとかで１行が
1024バイトくらいでぶった切られてしまうことが以前あったからだと思います。（は
っきりそうなった事例を把握してた訳じゃないかもしれないけど）

　最近の秀丸メールで、送信するメールの折り返し無しが標準になったり他のメール
ソフトでもそういう動作になってきてるので、base64エンコードされるケースが増え
たんだと思います。

RE:01437 RE01425サーバー本体の引っ越し

秀まるお2 さん　22/05/24 09:06

　テスト環境でテストしても再現せず、本番マシンでテストして再現し、いろいろ調
べたら、どうもPMailServer Pro2のバグのような気がします。

　メールボックスに入ってる一時ファイルに余計な改行が入ってるようなので。

　そっちに問い合わせしてみます。

RE:01439 メールが BASE64 でエンコードさ

Iranoan さん　22/05/24 13:32

秀まるおさん今日は Iranoan です
> 　メール本文の中の１行の長さの最大がある程度以上の長さになってる場合はbase
>64エンコードするようにしています。そうしないと、古いメールサーバーとかで１
>行が1024バイトくらいでぶった切られてしまうことが以前あったからだと思います。
>（はっきりそうなった事例を把握してた訳じゃないかもしれないけど）
JIS でなぜデコードされているのだろう? と思ったのですが、一行の長さでも切り替
えているんですね
失礼しました

RE:01440 RE01425サーバー本体の引っ越し

秀まるお2 さん　22/05/24 15:14

　作者さんの所でも確認してもらったので、PMailServer2側のバグで間違いないよう
です。僕の方でも対処は可能なんですが、面倒なのでPMailServer2側で対処されるの
を待とうと思います。

　とりあえず現状でも改行が増えるだけで大した害は無いと思うので、そのまま気に
しないで書き込んでほしいです。