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 だからだろうか?

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

2013年12月10日火曜日

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 などとしてしまって、吐出されたやつをファイルに保存
しているが、もっと良い方法あるんだろう。

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

2013年11月13日水曜日

Locust なる load testing tool

軽量な Web アプリのロードテストツールを探してたところ、Locust なる
Powered by Python なプログラムを発見。これ結構使える。
動作は Python コードで書くので柔軟性がある。

インストールは pip で一発だが、CentOS6 で可能な限り rpm で入れたいので
以下のように。そのうち自分で spec 作るか。

mater ブランチ持ってきてもいいけど、一応タグ打ってある版をここから
持ってきた。

# yum install python-devel python-zmq libevent-devel
# wget https://github.com/locustio/locust/archive/v0.6.2.tar.gz  -O locust-0.6.2.tar.gz
# tar xvzf locust-0.6.2.tar.gz
# cd locust-0.6.2
# python setup.py install

インストールが終わったら、適当に使ってみる。今回はユーザ毎にパラメータ
を変更した GET リクエストをたくさん投げる負荷テストをしてみたかったので
以下のような簡単なソースに。

テスト対象の動作の定義は、TaskSet クラスを継承したクラス(ここでは
MyFirstTasks) に適当な名前のメソッドを作り、その中でリクエストの URL
とパラメータを self.client.get() に指定すればいいだけ。複数メソッドを定義
した場合はランダムにそれを実行してくれる模様。@task(n) の n は、そのメソッ
ドの実行割合らしい。

実行順を定義したかったらクラスの定義をネストすれば良いらしい(私はまだやっ
たことがないが)。

Locust クラスを継承したクラス(ここでは MyFirstUser)は、操作するユーザ
を模したクラスらしい。この中の task_set という attribute に、上記した TaskSet
のクラス名を定義する。min_wait と max_wait はようわからんのだが、ユー
ザインスタンス間の実行間隔を定義しているらしい。
from locust import Locust, TaskSet, task
import random

class MyFirstTasks(TaskSet):
    @task(1)
    def myfunc(self):
        teststr = "teststr-" + "%04d" % random.randint(1,100)
        self.client.get("/mytest/?teststr=%s" % teststr)
class MyFirstUser(Locust):
    task_set = MyFirstTasks
    min_wait = 500
    max_wait = 1500

上記ファイル名を myfirsttest.py としたとして、下記のように実行する。

    locust -f myfirsttest.py -H http://www.fastriver.net

-H はリクエストを送るホストを定義する。

すると、http://localhost:8089 に管理画面が表れ、ここでスタート/ストップが
できたり、実行結果がわかったりする。

とまぁ超簡単な動作はこんな感じでできるが、複雑なもテストも動作を Python で
書けるので、Form に送る値を csv ファイル等に定義しておいて、ランダムにそれ
を送出するようなテストもできそう。

あと、master/slave 構成にもできるようなので、テストクライアント自体の
負荷分散も可能でかなり多くのリクエストを同時に送ることができそう。

また時間があったら詳しい使い方なんかを書いてみようと思う...書けたらいいな。。




2013年11月7日木曜日

Google の Service Account の p12 ファイルのパスフレーズ

Google Cloud Console または Google APIs Console において、
service account 用の pkcs#12 ファイルのパスフレーズっていったい何?
と思って調べたところ、Python の API のソースにその答えがあった。

notasecret だそうで。client.py:

    908         private_key,
    909         scope,
    910         private_key_password='notasecret',
    911         user_agent=None,
    912         token_uri=GOOGLE_TOKEN_URI,

実際の環境で使う場合は結び直した方が良さげ。

SignedJwtAssertionCredentials のコンストラクタ第4引数で指定する。