ytooyamaのブログ

サーバ構築とか、仕事で発見したこととか、趣味のこととかを書いています。

OS Xのメールアプリで複数のGmailアカウントを追加して起動すると動作停止する問題の解決方法

普段使用で使っているメールアドレスはGmail (正確に言うとGoogle Appsのメール)なのですが、普段いろいろなサービスの登録用などに使っているメインのアドレスのほか、OSS系の活動用に使っている別のGmailアドレスを追加したところ、そのアカウントを有効にしてメールアプリを起動するとハングアップしてしまう問題に悩まされていました。

f:id:ytooyama:20170401003351j:plain

症状でWeb検索すると、「/がついたラベルをリネームするか削除するといいよ」(日本語の解説) とか「インデックスを削除して再生成すればいいよ」とか、「一旦アカウントを削除して設定し直すといい」とか、「安全性の低いアプリがアカウントにアクセスするのを許可する」といった方法があるようなのですが、どれを試してもダメでした。

以前El Capitanを使っていた時はそんなことはなかったので、Googleが推奨するクライアント固有の設定があるのではと思って検索したところ、次のような情報を見つけました。やっぱりありましたね。

support.google.com

アカウントを追加したデフォルトの設定は「メールボックスの特性」という設定のすべてが「サーバーに保存」がオンになっていました。これをGoogleの推奨に合わせて迷惑メールの「迷惑メッセージをサーバーに保存」以外の項目は「すべてオフ」、「消去しない」に設定しました。

また「詳細」の設定の中の「すべての添付ファイルを自動的にダウンロード」をオフにしてみました。

これらの設定変更によって、メールアプリにGmailアカウントを複数追加してもメールアプリがフリーズしなくなりました。もし同じように困っている方がいましたらお試しください。

なお、複数のアカウントを設定してからメールアプリを起動するとクラッシュしてしまうので、一旦一つ目のアカウントだけを有効にして設定変更→二つ目の設定変更…のようにやってください。

最近はメールはブラウザーで見ることが多いのでメールアプリは滅多に使いませんが、複数のアカウントのメールを一つの画面で見られるのでまだまだメールクライアントは手放せません。

ちなみに会社ではThunderbirdを使っています。家と会社で使っているメールアプリが違うのはちょっとした気まぐれです。Thunderbirdは文字化けに強いですから。

CentOS 7でVagrantとPackstackでOpenStack Ocataの構築

そろそろ触ってみようかと思い、試してみました。 アンサーファイルの中身、ずいぶん増えたなあ。ダッシュボードのOpenStackのロゴ、新しくなりましたね。

なお、CentOS 7はVirtualBoxVagrantを使ってデプロイする都合で、ちょっとだけ面倒なことをしています。

OpenStackのデプロイまでの流れ

0.CentOS 7のデプロイ、起動

デプロイするCentOS 7のVagrantイメージは公式のものをダウンロードし、登録しておきます。

vagrant up もしくはvagrant up XXなどでCentOS 7を起動します。

$ vagrant up

1.CentOS7が起動したら、面倒なのでrootユーザーになる

$ sudo -i

2.リポジトリーを有効化

CentOSのOpenStackパッケージは「centos-release-openstack-XX」という名前のパッケージをインストールすると有効になります。現行の最新版はOcataです。

# yum install -y centos-release-openstack-ocata

ちなみに現時点ではインストールするパッケージを変更することで、Mitaka,Newtonをデプロイするのも成功しています。

3.すべてのパッケージをアップデート

# yum update -y

4.再起動する(推奨)

カーネルの更新があった場合は再起動が必要です。vagrant reloadコマンドで仮想マシンを再起動します。

# exit
$ exit
$ vagrant reload
$ vagrant ssh

5.ifupコマンドでeth1をアクティブにする

VMNICを追加するか、事前に二つ目を追加するようにVagrantfileに記述しておき、CentOS起動後に追加したデバイスをUpします。今後のVagrantのバージョンアップでこの処理が不要になるかも知れません。

# ifup eth1

6.eth1インターフェイスを確認

# ip a s eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.213/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe10:63dc/64 scope link
       valid_lft forever preferred_lft forever

7.openstack-packstackパッケージのインストー

# yum install -y openstack-packstack

通常、1Nodeインストールする場合、この後packstack --allinoneコマンドを実行してall-in-oneインストール!

…するわけですが、そのまま実行すると想定したように構築できない(VirtualBoxはNATのIPアドレスには外から中へアクセスできない)ので、以下の方法で事前にデプロイする環境のBind IPアドレスを変更する。

8.アンサーファイルの作成

# packstack --gen-answer-file=answer.txt

9.IPアドレスが「10.0.2.15」と設定されている箇所をeth1のIPアドレスに変更

実行例

# sed -i 's/10.0.2.15/192.168.0.213/g' answer.txt

10.0.2.15はeth0が持つIPアドレス(NAT接続)。VirtualBoxのNAT接続は中から外の通信のみ可能なので、このインターフェイスを使うと構築したOpenStackにアクセスできない。これを回避するためにアクセスできるeth1の方に切り替える。

eth1は「Host Only Adapter」を割り当てると良い(ちなみに他のユーザーに公開したい場合はブリッジなどを使う)。

10.その他、設定したい箇所があれば編集する。 インストールしたい、したくないコンポーネントを設定…など。

11.インストール開始

# packstack --answer-file=answer.txt
...
 **** Installation completed successfully ******

Additional information:
 * Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
 * Warning: NetworkManager is active on 192.168.0.213. OpenStack networking currently does not work on systems that have the Network Manager service enabled.
 * File /root/keystonerc_admin has been created on OpenStack client host 192.168.0.213. To use the command line tools you need to source the file.
 * To access the OpenStack Dashboard browse to http://192.168.0.213/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
 * The installation log file is available at: /var/tmp/packstack/20170319-123201-RWxEWA/openstack-setup.log
 * The generated manifests are available at: /var/tmp/packstack/20170319-123201-RWxEWA/manifests

OpenStackの利用

adminユーザーのログインパスワードはkeystonerc_adminに、demoユーザーのログインパスワードはkeystonerc_demoに書かれています。

f:id:ytooyama:20170319220612p:plain

セキュリティーグループでICMPとSSHを許可してインスタンスを起動。pingsshによるログインができることを確認。

ちなみにkeystonerc_adminやkeystonerc_demoをsourceコマンドで読み込むと、コマンドによるOpenStackの操作も可能です。

なお、VirtualBoxではNested Virtualizationできないので、Nova ComputeをKVMモードで動かすことができません。QEMUモードで動かすので、ほとんどのOSは素早く起動しない点に注意しましょう。

KVMで動かしたい場合は、LinuxVagrantLinux KVMをインストールして、VagrantLibvirtプラグインvagrant plugin install vagrant-libvirtでインストール可能)とVirtIO用のVagrant Box ImageでCentOS7を起動してその中で実行しましょう。同じように動作するはずです。ちなみにvagrant pluginがうまく通らない場合は公式のVagrantインストーラーでインストールしてから実行すると良い感じです。

OpenStack環境の停止と再開

デプロイしたOpenStackをインストールした環境はVagrantならそのままサスペンドができます。vagrant resumeコマンドを実行したら元通り。

1.環境の一時停止

$ vagrant suspend

2.環境の再開

$ vagrant resume

QEMUじゃなくてKVMモードでComputeをデプロイするには?

VagrantLibvirtプラグインを使って、Linux KVMにデプロイするような設定をすればいける!

UbuntuでLinux Kernelの特権昇格の脆弱性(CVE-2017-6074)に備える

Linux kernelの特権昇格の脆弱性( CVE-2017-6074 )が報告されている。

www.softbanktech.jp

oss.sios.com

この脆弱性を3行で解説すると?

  1. ユーザーログインできるサーバーで
  2. 脆弱性コードを実行すると
  3. root権限のユーザーになれて悪意のある行動し放題!

…ログインできることが条件ですが、やばい脆弱性であることは間違いありません。

脆弱性への対応

この問題を回避するには速やかにUbuntuに修正済みのカーネルを適用して再起動することである。 また、カーネル4.0以降であればライブパッチ機能を使って脆弱性に対応することもできる。 しかし、すぐに再起動できない場合は次のように実行しておき、良きタイミングでUbuntuを再起動するという対応が可能である。

回避策を設定

$ sudo vi /etc/modprobe.d/blacklist-dccp.conf
alias net-pf-2-proto-0-type-6 off
alias net-pf-2-proto-33-type-6 off
alias net-pf-10-proto-0-type-6 off
alias net-pf-10-proto-33-type-6 off 

回避策を適用

次のコマンドでモジュールの設定に従って先の設定やその他のモジュール設定の適用、モジュールの読み込み、アンロードが実行される。意図しないモジュールが読み込まれる場合があるので注意する。

$ sudo depmod -a

Ubuntuのアップデート

アップデート後は新しいカーネルをロードするために再起動が必要。

$ sudo apt update
$ sudo apt upgrade && sudo reboot

Ubuntuの各バージョンに対するパッチのリリース状況は以下のページで確認できる。

PoCのテスト

PoCがgithubに公開されているので、再起動前であれば試しに実行してみることができる。次の手順に従ってテストできる。PoCのテストをするつもりがなければ、このステップはスキップしてください。

重要なサーバー上で絶対に実行しないでください。

$ wget https://raw.githubusercontent.com/xairy/kernel-exploits/master/CVE-2017-6074/poc.c && wget https://raw.githubusercontent.com/xairy/kernel-exploits/master/CVE-2017-6074/trigger.c

$ sudo apt update && sudo apt install gcc -y && gcc -o pwn poc.c

$ ./pwn
[.] namespace sandbox setup successfully
[.] disabling SMEP & SMAP
[.] scheduling 0xffffffff81064550(0x406e0)
socket(SOCK_DCCP): Socket type not supported 

なお、以下のサイトではUbuntuSELinuxをインストールして脆弱性を回避できるか試行されているが、UbuntuSELinuxをインストールするのは推奨されない。UbuntuにはApparmorというセキュリティ機能がインストールされており、ApparmorとSELinuxが衝突してしまうためである。

oss.sios.com

またそもそもUbuntuSELinuxを使っているユーザーは少なく、何が起こっても解決できる保証はないことや、もはやUbuntuSELinuxやそれを支える関連するツールは積極的にメンテナンスされていないため、インストールすることは推奨されない。

困難を理解した上でインストールしたい場合は次のドキュメントが参考になるかもしれない。

RHEL7 vs CentOS7 & Scientific Linux 7

RHEL7

CentOS 7

[追記] 2017年3月4日 kernel-3.10.0-514.10.2.el7.x86_64を確認しました。

$ sudo yum list|grep kernel
kernel.x86_64                              3.10.0-514.6.1.el7          @koji-override-1
kernel.x86_64                              3.10.0-514.6.2.el7          @updates  #今の所の最新

Scientific Linux 7

何が言いたいか簡潔にいうと、本当にCentOS 7でいいんですか?…ってことです。

RHELやCentOSなどでPython 3を使う

Python 3の環境をCentOS 7で作るのは大変と聞いたのでブログにまとめようと思いました。

Python 3環境をLinuxで作るんだったら迷わず FedoraUbuntuopenSUSEをオススメします。これらは比較的新しいパッケージを提供するためです。

ただし、どうしてもRed Hat Enterprise LinuxとかCentOSyumコマンドでインストール/アップデートできないと嫌なんですけど…という人には、「Software Collections」をオススメしたいと思います。

Software Collectionsについてはここら辺にまとまっています。簡単に言うと、システムに影響を与えることなくRHELRHELクローン上でシステム標準パッケージよりも新しいバージョンを使えるような仕組みです。便利ではあるのですが、割とご存じない人が多いみたいですね。

access.redhat.com

その他

使い方

例えばPython 3.5を例にすると「Python 3.5 by Software Collections」の手順通りです。その他のパッケージは検索してみてください。Software Collectionは定期的に新しいバージョンに更新されるので、サイトの情報よりも新しいパッケージが提供されている場合もあります。

ちなみに2017年3月2日現在はPython 3.3、3.4、3.5がインストールできるようです。

ディストリビューション別の導入方法

Software CollectionsをRHELRHELクローンで使う方法です。代表的なものをいくつか取り上げます。

Red Hat Enterprise Linux 7
$ sudo yum-config-manager --enable rhel-server-rhscl-7-rpms
CentOS 7
$ sudo yum install centos-release-scl
Scientific Linux 7
$ sudo yum install http://ftp1.scientificlinux.org/linux/scientific/7x/external_products/softwarecollections/yum-conf-softwarecollections-2.0-1.el7.noarch.rpm
Oracle Linux 7

Public YumにSCLがあるのでおそらく使えると思います。

CentOS 7で実際に使ってみた

インストールします。

$ sudo yum install rh-python35

もともとはPython 2.7.5が入っているようです。

$ python -V
Python 2.7.5

シェルを切り替えてpythonを叩くと、今度はPython 3.5.1が呼ばれることがわかります。 Software Collectionsによりインストールされるバイナリーは大抵/optの下にインストールされます。 シェルを切り替えずにメインのシェルで動かすにはそのパスを叩けば良いですが、決して/usr/bin/pythonを張り替えて「yumが動かない!」とか言わないでください。動かない原因を作ったのはあなたですからw

$ scl enable rh-python35 bash
$ python -V
Python 3.5.1
$ which python
/opt/rh/rh-python35/root/usr/bin/python

いつもの「こんにちは世界」でも動かしますか。

$ echo 'print("Hello world!")' > hello.py
$ python hello.py
Hello world!

print文はカッコで閉じるんですよ。

iPhone 7 Plusに傷がついてしまった

買ってからそんなに経っていないiPhone 7 Plusにとうとう傷をつけてしまいました。どうやら軽く擦ったような傷になっています。光の加減で傷が見えたり見えなくなったりとちょっときになる傷。

気をつけていたんだけどどこで傷をつけてしまったんだろうなあ。

昔別の用途のために買った、こいつがあったので試しに少量つけて擦ってみました。

最初は指を使って擦ってティッシュで拭き取ってみたのですが、あんまり効果はなさそう。そこで綿棒に少量つけて思いっきり擦ってティッシュで拭き取ってみたら完全に傷を消すのは無理だったけど、だいぶ目立たなくなりました。

あまりやりすぎると別の傷を作ってしまう可能性があるのでほどほどにしました。

Ubuntuとライブパッチ

Linuxでサービスを稼働する上で懸念点となるのがLinuxカーネルのパッチ充て。 LinuxカーネルLinuxの中核であり、通常パッチを充てた後は再起動が必要です。…というのは過去の話。

Linux カーネルのバージョン4.0からライブパッチ機能が実装され、再起動不要でパッチを当てられるようになっています。詳しくは以下を参照のこと。

qiita.com

ただし見てわかるように、ライブパッチを自分で作業するのはちょっと大変です。そんな中、Ubuntuではこういうサービスが展開されています。

第443回 再起動なしにカーネルを更新する「Canonical Livepatch Service」:Ubuntu Weekly Recipe|gihyo.jp … 技術評論社

基本的にこの機能は有償サポートサービスの一部として提供されますが、Ubuntuユーザーでも適用できる数は限定されるものの、ライブパッチ機能をインストール済みのUbuntu Server 16.04に適用することができます。詳しくは公式サイトをどうぞ。

Canonical Livepatch Service | Server | Ubuntu

ちなみにUbuntuのライブパッチ機能を有効にして数ヶ月放置したサーバーにアクセスしたらこんな感じでした。ちゃんとライブパッチが機能しているのがわかると思います。

$ sudo canonical-livepatch status --verbose
client-version: "6"
machine-id: 
machine-token: 
architecture: x86_64
cpu-model: Intel Core i7 9xx (Nehalem Class Core i7)
last-check: 2017-02-23T11:23:29.7+09:00
boot-time: 2017-02-23T11:23:16+09:00
uptime: 6m24s
status:
- kernel: 4.4.0-57.78-generic
  running: true
  livepatch:
    checkState: checked
    patchState: applied
    version: "18.1"
    fixes: |-
      * CVE-2016-0758
      * CVE-2016-1583
      * CVE-2016-2117
      * CVE-2016-2184
      * CVE-2016-2185
      * CVE-2016-2186
      * CVE-2016-2187
      * CVE-2016-2188
      * CVE-2016-3136
      * CVE-2016-3137
      * CVE-2016-3138
      * CVE-2016-3140
      * CVE-2016-3156
      * CVE-2016-3672
      * CVE-2016-3689
      * CVE-2016-3713
      * CVE-2016-3951
      * CVE-2016-3955
      * CVE-2016-4470
      * CVE-2016-4482
      * CVE-2016-4485
      * CVE-2016-4486
      * CVE-2016-4557
      * CVE-2016-4565
      * CVE-2016-4581
      * CVE-2016-4805
      * CVE-2016-5195
      * CVE-2016-5243
      * CVE-2016-5244
      * CVE-2016-5400
      * CVE-2016-5696
      * CVE-2016-5728
      * CVE-2016-5829
      * CVE-2016-6828
      * CVE-2016-7039
      * CVE-2016-7425
      * CVE-2016-8655
      * CVE-2016-8658
      * CVE-2016-8666
      * CVE-2016-9756
      * CVE-2017-6074

ライブパッチ機能サポートはUbuntu Xenialの機能の一つでしかありませんが、LXD、LXC、Juju、MAASといったインフラ構築と管理アプリケーション、柔軟なアプリケーションやハードウェアのサポートなど、Ubuntuには便利なものがたくさんありますし、カーネル更新の手間が軽減できるのを考えると、12.04 LTSや14.04 LTSを使っているユーザーは、Ubuntu 16.04 LTSに移行すべきですね!

[追記] 先の出力について。現在、上記サーバーのUbuntuはkernel: 4.4.0-57.78-genericが利用されており、このバージョン以降のカーネルのセキュリティフィックスがfixesの一覧に列挙されています。カーネル以外のパッケージ更新は次のようにやっておけばよいでしょう。

$ sudo apt-get update
$ sudo apt-get upgrade