2017年5月22日月曜日

Windows 10で、Chromeがおかしくなった。

Windows 10 にして、Chromeの挙動がおかしい時が多々ありましたが、
今回Creators Updateを当てたところ、機能拡張を入れるとフリーズ。リンクやボタンにマウスカーソルを持って行ってもクリックできない。プルダウンメニューが選択できない。ページが表示されない。など動作に支障が出るレベルになり、
キャッシュクリア、プロファイルの削除、Chrome再インストールなど試したがどれも効果なく。
怒りでFFに乗り換えるか。とも思いましたが、ググるとどうもグラフィックドライバ回りが怪しいとの情報が。
そういえばこのPC、インテルが正式にはグラボドライバ出していなく、MS製の割と不安定な奴が入っていました。
試しにIntelのドライバ更新プログラム走らせるも、該当ドライバは出てくるがインストール時不明なエラーでインストールできずOrz
うーんと設定眺めていると怪しそうなものを発見!!

なんとこれで直りました!!

2017年5月14日日曜日

SourfeTree 2.0で過去開いたリポジトリが出ない

SourceTree2.0系が出ましたね。
画面や操作性が結構変わっていて戸惑います(汗

そんな中で、1.9系にあった、過去開いたリポジトリの選択画面がない!!
となったので、ちょっとしたTipsです。
(ちなみに、インストール時にちゃんと出ていることを後で確認しました・・・)



なんか空のタブが開きそうなUIですが、これをクリックしますと・・・


こんな感じで出てきます。

2017年4月25日火曜日

Let's Encryptで証明書を取得する

ググればいくらでも出てくるのですが、防備のために。

Ubuntu 16.04で試しました。

まず、取得のためには、Webサーバが外部に公開されている必要があります。
つまり、Port443(or 80)で外部よりサーバへアクセスできる必要があります。
また、当然ですが名前解決できる必要があります。
しかし、DDNSだと、週に取得できる上限が20個までという制限に引っ掛かる為、
一部のDDNSを除いて、取得しようとすると以下のようなエラーになります。
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: dip.jp
Please see the logfiles in /var/log/letsencrypt for more details.
 なので、気長に待ちましょう。一日に何回もたたいても取得できないものは取得できません。

自分は取得できるまではオレオレ証明書で過ごしました。Cronで1日一回取得コマンドを叩いてチェックする感じ。一か月くらいかかったかな?

では、新規取得について。cerbotという自動取得プログラムをセットアップします。
cd /usr/local
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto -n
これで、インストールが完了しました。
必要に応じパスを通すなどしてください。
次に、証明書を取得します。自分は既にオレオレ証明書で外部にWebサーバを公開していたので、
そこを利用する設定にしました。
/usr/local/certbot/certbot-auto certonly --webroot \
-w /var/www/html -d xxxx.dip.jp \
-m admin@example.com --agree-tos -n --dry-run
-mで指定する連絡先メールアドレスは、証明書の更新期限が近づいてくると連絡が来るそうなので、管理用メアドをセットします。

まずは--dry-runにて動作を確認後、OKなら外して動かします。
デフォルトではPort443で通信するようです。

気長に待つと、そのうち下記のようなメッセージが出て、取得できます。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xxxx.dip.jp
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0020_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0020_csr-certbot.pem
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem. Your cert will
expire on 2017-0X-XX. 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"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
早速取得できた証明書をApache、PostFix、Dovecotにセットします。
Apache:
SSLCertificateFile /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/xxxx.dip.jp/chain.pem
PostFix:
smtpd_tls_cert_file = /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/xxxx.dip.jp/chain.pem
Dovecot:
ssl_cert = </etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem
ssl_key = </etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
このパスは当然ながら最新の証明書へのシンボリックリンクとなっており、
証明書が更新されてもパス、ファイル名が変わらないようになっています。

無事セット出来たら、次は更新処理を行います。
以下のスクリプトを作成し、cron.dailyあたりに放り込んでおきます。
(なお、取得は制限がありましたが、更新は制限がないようです。)
#!/bin/bash
/usr/local/certbot/certbot-auto renew --no-self-upgrade --post-hook "service dovecot restart && service postfix restart && service apache2 restart" --dry-run
ここでは、--post-hookを利用して、証明書が無事取得できたら、Apache、PostFix、Dovecotを再起動するようにしています。
これも、ちゃんと動作するかdry-runでテストを行いますが、
dry-runでも--post-hookは発動してサービスが再起動しますので注意です。
証明書の取得更新作業は今まで大変面倒で、しかも決して安くはないうえに、来るのは数十キロバイトの文字列だし、なんで自動化できないのか。これは一部独占企業による既得権益なのか?(こら
と思っていましたがやっと自動化になりましたね。
Amazonも自動証明書発行やったり、インフラがコードでどんどん自動化、使い捨てが進んでいく流れで、自動化を推進するのは大変良いことです。

2017年4月24日月曜日

Thunderbirdで何故か違う送信者で送信される

Thunderbirdで複数アカウントを登録している場合、
正しいアカウントでメールを送信したにもかかわらず、登録されている違うアカウント名義で送られることがあります。

これ、質が悪いのが、ちゃんと正しいアカウントの送信トレイに残り、しかもそこのFromのアドレスは正しいのですが、実際送られたメールのFromは違うアカウントになっています。

で、原因はこれです。




複数アカウント毎に通常それぞれSMTPサーバが設定されているのですが、
何かの拍子に既定のSMTPサーバになることがあります(汗

でどうなるかというと、このアカウントの受信は問題ないのですが、送信時はこの規定のSMTPサーバから送られます。
この時アカウントを記憶させておくと、しれっとFROM書き換わって送られます(汗

ThunderbirdはSMTPサーバの設定がここともう一か所あります。



ここが正しいからと言って、各アカウントのSMTPサーバ設定の選択とペアで合わせないとこういうことになります。
ちなみに、何故か各アカウントのサーバ設定項目ではなく、アカウント名をクリックしたところにあるので非常に見つけにくいです。

気を付けましょう。