2014年9月1日月曜日

A start job is running for dev-disk-by ...

Fedora 20 でなんか起動時に下記メッセージが出て起動がめちゃくちゃ遅い。

A start job is running for dev-disk-by...

Web 調べたところ、fstab に書いてある UUID が見つからないからこんな症状
になるらしい。

  A start job is running for dev-disk-by\x2dlabel-swapspace.device
  https://bbs.archlinux.org/viewtopic.php?id=161814

/dev/disk/by-uuid/ 以下にちゃんと UUID の symlink を作ればいいっぽい。

2014年7月24日木曜日

Fedora 20 yum update したら ibus-mozc で入力できんぞ

Install Date から考えておそらく ibus-mozc だろう。
yum update して再起動したら日本語入力ができなくなった。
Shift-space で mozc の選択はできるんだけど、その後日本語が入力できん。
mozc 自体は先月にアップデートしたっきりだから、ibus-mozc のせいと思ってる。

仕事ができないので取り急ぎ以下実行
yum downgrade ibus-mozc mozc emacs-common-mozc emacs-mozc emacs-mozc-el

ibus-mozc-1.15.1814.102-1.fc20.x86_64

ibus-mozc-1.12.1599.102-1.fc20.x86_64

これで一応治ったが…
根本原因は後で調査しよう。。。あとで。。

2014年7月2日水曜日

www.jpcert.or.jp の証明書

https://www.jpcert.or.jp/ を firefox のホームにしてるんだけど、なんか
今日から急に証明書が信頼できない旨の警告が出始めた。
Verisign の中間の Symantec の証明書を使っているらしいのだが、Firefox
の設定を見るとデフォルトでは Symantec が入ってない...
一昨日の yum update が問題だったか?

しかし jpcert としても中間証明書を流していないのか? と疑問に思い
s_client で確認すると以下のような chain になっていて、確かに Symantec
の中間証明書を流していない(0と1の間に Symantec の証明書が必要なのでは)。

これでいいんすかね?


Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0100-05-006504/C=JP/postalCode=101-0054/ST=Tokyo/L=Chiyoda-ku/street=Hirose Bldg. 11F, 3-17 Kanda-nishikicho/O=Japan Computer Emergency Response Team Coordination Center/OU=System Administration Group/CN=www.jpcert.or.jp
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3

 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5


 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

2014年6月26日木曜日

keystone に endpoint 登録で "Malformed endpoint URL"

OpenStack の keystone に endpoint 登録したのはいいが、その後 keystone endpoint-list とか
の関連コマンドを実行すると以下のエラーが出て苦しんだ。

Malformed endpoint URL (http://hoge.example.com:8080/v1/AUTH_%{tenant_id}s)
どうやら URL の中括弧がまずいらしい。正しくは %() と普通のカッコだった。
どうにもコマンドが実行できないので、直接 mysql にログインして endpoint テーブル
から該当の行を直接 delete したら治った...

ちなみに mysql の接続情報は keystone.conf にある。

Qcow2 のローカルマウント

Qcow2 のイメージの中をちゃちゃっと見たいとき、qemu-nbd を使うのが良いらしいが、
RHEL6 や Cent6 には標準で入ってないっす。

この場合 guestmount ってのを使うと良いようで、RHEL6 の場合、
yum install libguestfs-tools すればインストールされる。

で、hoge.img を /mnt/tmp 下にマウントしたい場合以下のコマンド実行

guestmount -a hoge.img -m /dev/sda1 /mnt/tmp

取り急ぎ調べたので -m を指定する意味がイマイチわからんが、あとで調べるってことで。

2014年6月19日木曜日

Fedora 19 -> Fedora 20 の fedup でハマったこと

# fedup --network 20 -v --debuglog /var/tmp/fedup.log --disablerepo google-chrome 
でエラーなくコマンドが終了したんだけど、一向に grub.cfg が書き換わらず、
仕方ないので fedup のソースを追ったところ boot.py 内で new-kernel-pkg なる
コマンドで grub の設定ファイルをいじっていることを発見。
このコマンドを手動で実行してみるも何のエラーもなし。
-v つけてみたところ、どうも /boot/grub2/grub.cfg は書き込み対象じゃないら
しい。以下のように /etc/grub2.cfg が対象の模様。
$ sudo new-kernel-pkg -v --initrdfile /boot/initramfs-fedup.img --banner 'System Upgrade' --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0' --make-default --install fedup
initrdfile is /boot/initramfs-fedup.img
found /boot/initramfs-fedup.img and using it with grubby
/etc/grub.conf does not exist, not running grubby for grub 0.97
/etc/grub2.cfg does not exist, not running grubby for grub 2
/boot/efi/EFI/fedora/grub.cfg does not exist, not running grubby for grub 2 with UEFI
/etc/lilo.conf does not exist, not running grubby
/etc/extlinux.conf does not exist, not running grubby for extlinux
 仕方ないので ln -s /boot/grub2/grub.cfg /etc/grub2.cfg しました。
で、再起動後アップグレード処理が完了。

しかし今度は grub の起動時にFedora20 のカーネルで立ち上がらん。
以下のエラー。
alloc magic is broken at 0x8a9b0360: 73......
Aborted. Press any key to exit.
いろいろ調べたところ、 grub.cfg で initrd を指定するところの
パラメータ名が initrdefi になってなかった(EFIな環境)。
initrdefi /boot/initramfs-3.14.8-200.fc20.x86_64.img
上記に書き換えたら起動した。

あと、起動後音が出なかったのだが、これは以前経験済みで alsaunmute コマンドで
解決。

2014年5月22日木曜日

Google Groups の From が "送信者名" via "グループ名" <グループアドレス> になっちゃう件

@yahoo.com やら @yahoo.co.jp やら @aol.com などのメアドから Google Groups
にメールを送信するとメッセージヘッダの From: が以下に書き換えられる現象が
最近多発しているとのこと。

From: "送信者名" via "グループ名" <グループアドレス> 

どうも、Yahoo や AOL が DMARC レコードに p=reject を付与したことが要因
らしい。

$ dig +short _dmarc.yahoo.com txt
"v=DMARC1\; p=reject\; sp=none\; pct=100\; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com\;"

例えば、Google Groups が From の書き換えをしなかったとしたらどうだろう。

example@yahoo.com のメアドを持つ人が Google Groups 宛にメールを出すと、
Google Groups はそのままメンバーにそのメールを配信する。
そして配信されたメンバーのプロバイダが DMARC チェックしていたとしよう。
yahoo.com のポリシーは p=reject なので、外部からのメールは拒否しろという
指示に従い、そのメンバーのプロバイダはメールを受け取らず拒否する。

というわけで、Google はその対策として p=reject なドメインからの
Google Groups へのメールについて、その From: ヘッダをグループのメール
アドレスに書き換えるという暴挙に出たらしい(暴挙は大げさか)。

本当の送信者は X-Original-Sender ヘッダで確認できるようだ。

以下に議論があった。

Why do some messages sent to a group get rewritten From, X-Original-From headers?
https://productforums.google.com/forum/#!topic/apps/KHQceAbom5g

ただ、@yahoo.co.jp の DMARC は何も設定されていないのにこの目にあって
しまうのはなんで?