Re: 夜更かし日記 第3夜
日々のメモ書きです。 自分が見返すため。後から自分と同じ道をたどる人のための記録です。
2018/08/21
祝 BloggerのカスタムドメインのHTTPS対応
cloudflareでのHTTPSに必要な証明書の発行に時間がかって、設定が完了できませんでした。
そして証明書が発行されてからも期待したHTTPSでの動きをしなかったので断念しました。
ところが、今気づくて、2018年の2月からBloggerがカスタムドメインのHTTPS化に対応されたようです。
以下が公式ヘルプの設定手順になります。
https://support.google.com/blogger/answer/6284029?hl=ja
これで安心をして使えますね。
2017/12/21
BloggerのカスタムドメインでのHTTPS対応 その1
BloggerのカスタムドメインでのHTTPS対応
こんばんは。井谷です。
ブログを再開するにあたって、Bloggerのコンパネを見ていると、HTTPSに対応していた!
なぜカスタムドメインはHTTPSに対応しないのか?
- URLと証明書の記載のドメインの一致
- ここでは、URLにある「www.google.com」と証明書の中の「*.google.com」が一致しています。*はなんでも良いという意味です。
- 証明書の発行元が信頼がおける証明書の発行会社がどうか?
- 図中の「Geo Trust」の部分になります。
- サーバが証明書に対応した秘密鍵を持っているか?
事前調査
- http://www.howtoshout.com/enable-https-blogger-blog-custom-domain/
- https://www.bloggingprince.com/2017/06/how-to-enable-free-https-ssl-on-blogger-custom-domain.html
どうやってHTTPS化するのか?(先に結論)
ブラウザ <ー> Blogger(カスタムドメインでのHTTPS未対応)
という状態なので、ブラウザとBloggerはHTTPで通信をしています。
ブラウザ <ー①ー> cloudflare<ー②ー>Blogger
これを上図のように間にcloudflareを入れます。
ブラウザとcloudflare間はHTTPSで通信を行い、cloudflareとBlogger間はHTTPで通信をすることでHTTPS通信を実現します。
cloudflareは無料サービスが提供されており、証明書も共有証明書であれば無料で利用できます。
その2では、実際にHTTPSの設定をしていく過程を説明しますね。
2017/12/16
再始動
5年間、ブログを休んでいましたが、また書き溜めて行こうと思います。
この5年間で、転職して、離婚して、再婚して、東京から千葉の外房に引越をして、いろいろとありました。
そのあたりも、おいおい追記していこうと思います。
リスタートにあたり、ブログ名も「Re:夜更かし日記 第3夜」として初めたいと思います。
2012/08/07
メールが配送されなくなった。
Postfixを2.7から2.8にアップグレードしたら、メールが配送されなくなりました。
原因は、/etc/mail/aliases ファイルが読めなくなったこと。
以下は/var/log/mail.logから、1行目の「error」が元凶をしめす。
Aug 7 03:10:08 stem postfix/local[6104]: error: unsupported dictionary type: btree
Aug 7 03:10:08 stem postfix/local[6104]: warning: btree:/etc/mail/aliases is unavailable. unsupported dictionary type: btree
Aug 7 03:10:08 stem postfix/local[6104]: warning: btree:/etc/mail/aliases: lookup of 'root' failed
Aug 7 03:10:08 stem postfix/local[6104]: F2B7915F402B: to=<root@**********>, orig_to=<root>, relay=local, delay=1.7, delays=1.7/0/0/0.02, dsn=4.3.0, status=deferred (alias database unavailable)
つまり、/etc/postfix/main.cf内の
alias_maps = btree:/etc/mail/aliases
が読めないらしい。2.7では読んでくれてたんだけど。。。
これはGentoo Linuxの固有の設定ですが、ビルドオプションとして、USEフラグは、
「hardened pam ssl」
しか指定しなかった。この場合にサポートするファイルタイプを調べた。
#postconfi –m
# postconf -m
cidr
environ
fail
internal
memcache
pcre
proxy
regexp
static
tcp
texthash
unix
こんな状態でbtree も hash もありません。
先ほどのUSEフラグに「berkdb」を追加してビルドすることで、
# postconf -m
btree
cidr
environ
fail
hash
internal
memcache
pcre
proxy
regexp
static
tcp
texthash
unix
btreeとhashが追加されました。
これで問題解決です。
2012/03/21
MegasasをMegaCliで操作してみた
うちのサーバは、FUJITSU(富士通)のPrimergyのTX200S3です。
以前、構築に苦しんだのを延々と3年間使っています。
最近のディスクが弱いのか、Hotspareを入れた直後に、別のディスクが調子を崩してしまわれました。
具体的には、以下のようなエラーです。
# megasasctl
a0 MegaRAID SAS 8300XLP encl:1 ldrv:1 batt:FAULT, module missing, pack missing, charge failed
a0d0 1TiB RAID 5 1x7 optimal
hot spares : a0e248s0
a0e248s0 279GiB hotspare
a0e248s1 279GiB a0d0 online
a0e248s2 279GiB a0d0 online
a0e248s3 279GiB a0d0 online
a0e248s4 279GiB a0d0 online
a0e248s5 279GiB a0d0 online
a0e248s6 279GiB a0d0 online errs: media:1 other:0
a0e248s7 279GiB a0d0 online
ハードエラーは出てないのですが、怖いディスクは早めに取り替えるということで、交換を依頼を出したら、ハードエラーでないと抜きづらいということで、コマンドラインで操作をしてみました。
ちなみにエラーが出ているのは、「a0e248s6」というディスク
頭の「a0」はアダプターID、「e248」がエンクロージャーID、「S6]がディスクのIDだと思われる。
参考にしたサイトは、「DELL PERC5/i Integrated (LSI Logic MegaRAID)– Emergency Cheat Sheet –」というページの「8 Walkthrough: Change/replace a drive」の章。
# MegaCli -PDOffline -PhysDrv[248:6] -a0
Adapter: 0: EnclId-248 SlotId-6 state changed to OffLine.
Exit Code: 0x00
これによって、以下のような状態になります。
# megasasctl -v
a0 MegaRAID SAS 8300XLP bios:MT25 fw:2.02.01-0156 encl:1 ldrv:1 rbld:80% batt:FAULT, module missing, pack missing, charge fa
iled/0mV/0C
a0d0 1TiB RAID 5 1x7 DEGRADED
row 0: *a0e248s0 a0e248s1 a0e248s2 a0e248s3 a0e248s4 a0e248s5 a0e248s7
unconfigured : a0e248s6
a0e248s0 SEAGATE ST3300655SS 279GiB a0d0 rebuild
a0e248s1 SEAGATE ST3300655SS 279GiB a0d0 online
a0e248s2 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s3 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s4 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s5 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s6 FUJITSU MBA3300RC 279GiB ready errs: media:1 other:0
a0e248s7 FUJITSU MBA3300RC 279GiB a0d0 online
HotSpareだった「a0e248s0」が「rebuild」状態になり、エラーがでていた「a0e248s6」が「ready」状態となります。
次に、「a0e248s6」にミッシングマークを付けます。
# MegaCli -PDMarkMissing -PhysDrv[248:6] -a0
Adapter: 0: Failed to change PD state at EnclId-248 SlotId-6.
FW error description:
The specified device is in a state that doesn't support the requested command.
Exit Code: 0x32
これはアダプタが対応していなかったようです。
このままディスクを取り外します。
# MegaCli -PDPrpRmv -PhysDrv[248:6] -a0
Prepare for removal Success
Exit Code: 0x00
コマンド実行から、1分程度時間がかかりましたが、正常終了
# megasasctl -v
a0 MegaRAID SAS 8300XLP bios:MT25 fw:2.02.01-0156 encl:1 ldrv:1 rbld:80% batt:FAULT, module missing, pack missing, charge failed/0mV/0C
a0d0 1TiB RAID 5 1x7 DEGRADED
row 0: *a0e248s0 a0e248s1 a0e248s2 a0e248s3 a0e248s4 a0e248s5 a0e248s7
unconfigured : a0e248s6
a0e248s0 SEAGATE ST3300655SS 279GiB a0d0 rebuild
a0e248s1 SEAGATE ST3300655SS 279GiB a0d0 online
a0e248s2 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s3 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s4 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s5 FUJITSU MBA3300RC 279GiB a0d0 online
a0e248s6 FUJITSU MBA3300RC 279GiB ready errs: media:1 other:3
a0e248s7 FUJITSU MBA3300RC 279GiB a0d0 online
こんな感じで状態は変化してないですね。「other」のエラーが3個増えていますけど。。。
あとは、SEさんにHDDのエラーランプが表示されていることを確認していただいて、交換ですね。
2012/01/05
JAVAの所有者の変更
SUNがOracle(オラクル)に買収されたので、
ライセンスは、そのままですが表記が
SUNからOracleに変更になったみたいです。
古いGentooマシンをアップデートしてぶつかりました。
こちらに書いてあります。2010年に発覚する問題だったみたい(汗)
http://forums.gentoo.org/viewtopic-t-894276-start-0.html
ライセンスは、/etc/make.confに以下のように記述することは知っていましたが、
ACCEPT_LICENSE="Oracle-BCLA-JavaSE"
/etc/portage/package.licenseに以下のように記載する方法もあるのですね(未検証)
cat /etc/portage/package.license
#dev-java/sun-jdk dlj-1.1
dev-java/sun-jdk Oracle-BCLA-JavaSE
2011/12/26
GCC 4.5.3のビルドエラー
最近になって、GCCをリビルドする必要があった。
それでエラーがでていて、英語メッセージだったの放置をしていたのだが、
GCCのUSEフラグにCXXが無かったためでした。
エラーの一節
久しぶりのエラーだったので、スクリーンショットというかエラーの画面をコピーするのを忘れました。
黄色の部分のメッセージがあれば該当します。
now that we have USE=cxx, and base/make.defaults has USE=cxx, i'd like to
migrate gcc away from USE=nocxx.
since this can be a pickle, i'd propose toolchain.eclass grow the checks:
- use cxx && use nocxx && die
- use !cxx && use !nocxx && die
原因
/etc/make.cnf で USEフラグに「-*」としている人だと思われる
対策
/etc/portage/package.use で「sys-devel/gcc cxx」を追加