2014年2月27日木曜日

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
で解除できるんかな?

2014年2月26日水曜日

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 の作業手順を説明するのってなんでこんなにダルいんだろ。

2014年2月7日金曜日

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'

2014年2月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 だからだろうか?

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