2018年12月5日水曜日

ldap.cidict.cidict

何年前の話してるんだよと言われそうだが、python-ldap で search_s とかで返ってくるディクショナリが case-insensitive じゃないてことで、わざわざ key(属性名)を lower() して reduce() で別のディクショナリ作って in とかで存在確認したりしてたとかもう誰にも言えないけど自分への戒めでここにメモっておきたい。

ldap.cidict.cidict(result[0][1]) で case-insensitive なディクショナリで返してくれるっていや、ホント知らなかった。ググっても意外と少ない。例えば以下のように objectClass の C が大文字でも小文字でも cidict した後なら in で存在チェックできる。

>>> 'objectclass' in ret[0][1]
False
>>> 'objectClass' in ldap.cidict.cidict(ret[0][1])
True

2018年9月28日金曜日

NGINX の proxy_pass のちょっとだけメモ

NGINX の proxy_pass で GET リクエストがどうなっちゃうのかいつもわからなくなるのでメモ。

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

まぁ全ては上記の NGINX に書いてあるんだけど、ここでは前方一致のやつだけ。

  • proxy_pass に URI が含まれる場合
  • location /name/ {
        proxy_pass http://127.0.0.1/remote/;
    }
    上記の NGINX ドキュメントページにおける「URI」という用語はどうも NGINX における $uri と同じで、ホスト名より後ろの文字列のようだ。上記例だと /remote/ という部分と思われる。

    この場合は、normalized URI (URI のデコード後: // を / にしたり %xx をデコードしたり)の location に定義した部分に一致する箇所を、proxy_pass て定義した URI 部分に置き換えて後ろのサーバに渡す模様。上記設定例の場合は例えば以下のようになる。
    http://www.example.com/name/foo?bar=baz
    ↓
    http://127.0.0.1/remote/foo?bar=baz
    (/name/ を /remote/ に置き換えて GET リクエストはそのまま)

  • proxy_pass に URI が含まれない場合
  • location /some/path/ {
        proxy_pass http://127.0.0.1;
    }
    上記 NGINX ドキュメントには、proxy_pass に定義された値がホスト名部分で終わっちゃう場合は request uri ($request_uri)をそのまんま後ろのサーバに渡すって書いてある(または完全な normalized URI = $uri)。

    つまり上記設定例の場合は以下のような感じ。
    http://www.example.com/some/path/foo?bar=baz
    ↓
    http://127.0.0.1/some/path/foo?bar=baz
    (ホスト名の後ろからはそのまま)

  • proxy_pass で変数を利用している場合
  • location /name/ {
        set myhost myhost.example.com;
        proxy_pass http://$myhost/;
    }
    この例のように proxy_pass 内で変数を利用してしまうと proxy_pass に指定した値のまま後ろのサーバに渡してしまう。つまり:
    http://www.example.com/name/foo?bar=baz
    ↓
    http://myhost.example.com/
    (とにかく proxy_pass で指定したものしか渡さない)
    もしリクエストを渡したい場合、proxy_pass は以下のようにすれば良いだろう。
    proxy_pass http://$myhost$request_uri;

2018年9月20日木曜日

Dockerfile の EXPOSE もしくは docker run --expose の意味

どこのサイトとは言わないが、docker の EXPOSE について誤った情報が蔓延しているような気がしてならない。

そのサイトは docker0 で繋がっているコンテナ同士の通信のために EXPOSE が必要と書いている。つまり EXPOSE しないと他のコンテナからそのポートにアクセスできないということを言っている。

しかし Dockerfile に EXPOSE なんて書かなくても(docker run で --expose を与えなくても)、あるポートを listen しているコンテナに対して他のコンテナから接続することは可能だ。

嘘だと思うなら以下のような Dockerfile から作ったイメージを --expose せずに docker run して、他のコンテナから「nc -vz <相手> 8080」でもしてみるといい。普通に connected になるはず。
FROM fedora:28
RUN dnf install -y nc
ENTRYPOINT ["/usr/bin/nc", "-kl", "8080"]

私の EXPOSE の理解は以下。間違ってたらコメント等で指摘ください。

EXPOSE で指定されたポートは docker run に -P (--publish-all) を付与した際の対象ポートとなる。つまりコンテナ内のポートを -P でホストの任意ポートにマッピングしたい場合にEXPOSE でポートを明示する必要がある。

2018年8月30日木曜日

curl で Proxy Protocol

NGINX で proxy_protocol を設定しちゃうと、curl なんかのクライアントから直接 NGINX のサーバにアクセスできなくなっちゃって辛い。
検証やテストなんかのときに応答を確認したいのに、上段のロードバランサ等を介さなくちゃならないのは非常に辛い。
そこで curl に Proxy Protocol オプションが無いかなと探してたらありました。7.60.0 からの実装だそうです。


--haproxy-protocol
(HTTP) Send a HAProxy PROXY protocol v1 header at the beginning of the connection. This is used by some load balancers and reverse proxies to indicate the client's true IP address and port.
This option is primarily useful when sending test requests to a service that expects this header.
Added in 7.60.0.

Fedora はまだ追いついてないや(7.59.0)。バックポートもされてない。


2018年8月25日土曜日

fcitx-mozc for Fedora 28

Fedora Copr で fcitx-mozc を build してみました(fedora-28-x86_64 のみ)。

https://copr.fedorainfracloud.org/coprs/ryohayakawa/fcitx-mozc/

よろしければどなたか使っていただけるとうれしかったり。不安な方は src.rpm 見てみて下さい。怪しいことはしてません。

まぁそのうち epel とか Fedora 29 の chroot もやろうかと。


2018年8月6日月曜日

最近の Fedora でマウスが速い

Fedora 27 にアップデートした頃からだったか、マウスの動きがぴゅんぴゅん速くなってしまい年寄りには結構厳しい状態に...仕方ない、xset m でチョチョイと、、、あれ?遅くならない????

と、その後忙しさにかまけて調べず我慢してそのまま使っていたが、最近会社 PC を X1 Carbon 6th にして Fedora 28 を入れていて良い機会なのでこれを直すことに。

最近の Fedora は Wayland がデフォルトのようだが、私は未だに自分の .xinitrc を設定して startx から起動するって流れで Xorg から抜けきれない老人である。しかし Xorg でも libinput というナウな入力デバイスのドライバが主流のようで、Fedora 28 でも /usr/share/X11/xorg.conf.d/40-libinput.conf にデフォルト設定として定義されている。

この libinput だが、アクセラレーションのモードとして adaptive と flat があり、adaptive の場合 xset m が効かないらしい。このモードは libinput コマンドの list-devices オプションで確認できる。adaptive がデフォルトとのこと。

$ sudo libinput list-devices
   :
Device:           TPPS/2 Elan TrackPoint
Kernel:           /dev/input/event15
Group:            10
   :
Accel profiles:   flat *adaptive
Rotation:         n/a

xset が効かないとなるとどうやって,,, ということでググって xinput でやるべしということがわかった。まず、マウスのデバイス名の確認。

$ xinput --list --short
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ Synaptics TM3288-011                        id=12    [slave  pointer  (2)]
⎜   ↳ TPPS/2 Elan TrackPoint                      id=13    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]

X1 Carbon の赤ポチは「TPPS/2 Elan TrackPoint」という名前のようで、この設定情報を見てみる。

 $ xinput --list-props "TPPS/2 Elan TrackPoint"
Device 'TPPS/2 Elan TrackPoint':
    Device Enabled (146):    1
    :
libinput Accel Speed (301):    0.000000
    :
この「libinput Accel Speed」を -0.5 くらいに修正してみる。
$ xinput --set-prop "TPPS/2 Elan TrackPoint" "libinput Accel Speed" -0.5


おぉ、遅くなったぞ。良かった。これを .xinitrc に書いておこう。