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 コマンドで
解決。

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 は何も設定されていないのにこの目にあって
しまうのはなんで?

xfreerdp

rdesktop だと SSL の RDP ができない。以下のエラーが発生しちゃう。

ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.

xfreerdp  というのが対応していた。Fedora 標準で入ってた。
これからこっちが主流?
コマンド実行の時点で ID/Password が必要だったんだけど、これは --no-auth
で解除できるんかな?

AD でオレオレ証明書で ldaps するのに AD CS で作った証明書じゃないとダメというデマ

Active Directory で ldaps するのにオレオレ証明書を使いたい場合、
AD DS(Active Directory Certificate Services)で作ったやつじゃないと
うまくいかないよなどというデマを某所で聞いた。

普通にできますが… 以下 openssl でオレオレ作った場合の例。

openssl で秘密鍵とオレオレ証明書を作成して pkcs12 で結ぶ。証明書を
作るときの CN は AD ドメインコントローラの「フル コンピュータ名」に
する必要あり。

openssl req -x509 -newkey rsa:2048 -keyout my.key -out my.crt
openssl pkcs12 -export -out my.p12 -inkey my.key -in my.crt

出来た証明書ファイルと pkcs12 ファイルを AD ドメインコントローラ
にコピー。んで、AD ドメインコントローラ上で mmc なるツールを起動。
# なんすかスナップインて?

1. 出てきた画面(コンソール1)で「ファイル」→「スナップインの追加と削除」
   を選択。
2. 「スナップインの追加と削除」画面の「利用できるスナップイン」
   のリストから「証明書」して「追加」をクリック。
3. 「証明書スナップイン」の画面で「コンピュータアカウント」を選択。
   「次へ」クリック。
4. 「ローカルコンピュータ」が選択されていることを確認の上「完了」を
   クリック。
5. 「スナップインの追加と削除」画面に戻るので「OK」をクリック。
6. 「コンソール1」に戻るので、画面左の「証明書(ローカルコンピュータ)」
   を開く。
7. 開いたところの「信頼されたルート証明機関」を右クリックして「すべての
   タスク」を選択して「インポート」を選択。これで openssl で作った
   証明書ファイル(上記例だと my.crt)をウィザードに従いインポート。
8. 今度は「個人」を右クリックして「すべてのタスク」を選択して「インポー
   ト」を選択。ここで openssl で作った pkcs12 ファイル(上記例だと my.p12)
   をウィザードに従いインポート。
9. これでドメインコントローラマシンを再起動すれば ldaps が使えるように
   なる。
   

しかし Windows の作業手順を説明するのってなんでこんなにダルいんだろ。

parseExpressionBoolean returns -1

自作の rpm を mock で build すると以下のエラー。

parseExpressionBoolean returns -1

どうやら、Requires の前に以下のような %if をかましているのが原因らしい。
(根本的な原因は違うのだが)

%if 0%{rhel} == 5
Requires:       mod_python
%else
  : 

%rhel の定義は /etc/rpm/macros.dist に含まれるが、BuildRequires にこの
ファイル名もしくは buildsys-macros を記しても、ダウンロードの順序のせ
いかこのファイルが作成されない。

仕方ないので、mock の設定ファイルに以下を追記。

config_opts['macros'] += '%rhel 5'

Google APIs Client Library for python の process-safe 性

Google APIs Client Library for python で OAuth2 のアクセストークンを保存する
Storage として file.Storage を使う場合、アクセストークンのリフレッシュ時に
生じる書き込みにおいて、複数プロセスに対するロックが不完全なような気がする。

oauth2client/file.py には以下のように定義されており、そのロックには threading.Lock
を使っている。

     36 class Storage(BaseStorage):
     37   """Store and retrieve a single credential to and from a file."""
     38
     39   def __init__(self, filename):
     40     self._filename = filename
     41     self._lock = threading.Lock()

これだと同じ Python プロセスの複数スレッドからのアクセスには耐えうるものの、

python プロセスを fork するようなプログラムでは排他出来ないのではないか?

Storage がファイルの場合はロックファイルや共有メモリを使うべきと思うのだが

どうだろう…

実際 mod_python を使ったプログラムに Credentials::authorize() が入っていたり

すると、同時アクセスがあった場合に何度も同時にリフレッシュがかかってしまう

動きをしていた。Prefork だからだろうか?

認識が違ってたら誰かツッコミください。

python の apiclient.discovery.build() が遅い

google-api-python-client で、Resource オブジェクトを取得するのに
毎度 discovery.py:build() を呼ぶと、毎度 https 通信が発生し動作が遅
くなってしまう。Web アプリの場合なんかは、アクセス毎にこれが発生
するのは問題。

なんで https 通信が発生するのかは、Discovery Document なる、Google
API を利用する際に必要な情報が記された JSON 形式のデータを毎度とり
に行っているから。discovery.py の以下の部分。

    190   logger.info('URL being requested: %s' % requested_url)
    191
    192   resp, content = http.request(requested_url)
    193  
    194   if resp.status == 404:
    195     raise UnknownApiNameOrVersion("name: %s  version: %s" % (serviceName,
    196                                                             version))
    197   if resp.status >= 400:
    198     raise HttpError(resp, content, uri=requested_url)
    199 

ただ、この JSON のデータは毎度取りに行く必要もないようで、一度とっ
たらキャッシュしてしまって、build() でなく build_from_document() を
使うのが良い。
キャッシュの仕方なんだけど、今のところ build() 関数にベタに
print content などとしてしまって、吐出されたやつをファイルに保存
しているが、もっと良い方法あるんだろう。

調べてわかったらまたメモります。