2018年1月15日月曜日

OpenSSL で暗号化したファイルが復号できない...

機密が含まれるファイルは openldap enc -aes-128-cbc で暗号化して保存してるんだけど、
Fedora 26 アップデートしたら復号できなくなった。。。

error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:569:

↑こんな感じのエラーで復号できない。ググって以下で解決。-md md5 オプションを追加してみた。
openssl enc -d -aes-128-cbc -md md5 -in myfile.enc


2018年1月7日日曜日

fcitx-mozc RPM on Fedora

Fedora 27 にしたら google-chrome で日本語入力が出来ないぞ... 今時 ibus 使ってるのが悪いといえばそれまでだが、歳を取るといろんなことが億劫になるので...

まぁ今の今までアップデートをサボって Fedora 24 だったって方が大問題なんだけどね。

おぉ、fcitx 試したら chrome の問題も解消されるじゃん。と、.xinitrc 書き換えるだけで済むかと思いきや、Fedora に fcitx-mozc 無いじゃんか。anthy 嫌いだしなぁ。

Web 調べると OpenSUSE の fcitx-mozc RPM パッケージを Fedora に流用して使ってる人が多いようで。何か解せないので Fedora 27 用の fcitx-mozc を作ることに。

自分のメインマシンを汚したくなかったので Dockerfile で build するときに RUN で rpmbuild して、docker cp でその RPM パッケージを取り出すことに。流行りに乗って github に Dockerfile と spec ファイルを公開してみた。


明日あたり Docker Hub と連携して automated build するようにしてみようかと。

以上、老人のやったことなのでボケてたり時代錯誤だったりすることがあるに違いない。何かお気づきのことでもありましたらコメント欄でも良いので教えておくんなまし。


2017年12月15日金曜日

Android 8.1 にアップデートしたらテザリングできなくなった

我が Nexus 6P をうかつに Android 8.1 にアップデートしたらいきなりテザリングができなくなった...

得てしてこういう現象は皆が騒いでるものだろうと言うことで、Nexus 6P のフォーラムに行ってみる。

あったあった。

Android 8.1 breaks tethering on Nexus 6P

APN をリセットして回復した人がいるのでやってみる。

Settings -> System -> Reset options -> Reset Wifi,mobile & Bluetooth

これで、思い切ってリセットして、APN (私は mineo) を設定しなおしてみると、テザリングできた!

2017年11月27日月曜日

389 Directory と AD の連携 (LDAP->AD 編)


前々回の389 Directory と AD の連携 (AD-> LDAP 編)の設定で双方向レプリケーションは自然に出来ているはず。が、どうも私の環境だとうまく行かない。389 Directory 側のエントリを modify しても AD に伝播してくれないのだ。

エラーログには以下のメッセージが。

NSMMReplicationPlugin - replica_update_state - Failed to update state of csn generator for replica dc=example,dc=com: LDAP error - 32

該当箇所のソースを見たがすぐにわかるようなものじゃないことが判明。仕方なくデバッグログ(nsslapd-errorlog-level: 8320)を出してみる。すると以下が。

Received result code 50 (00002098: SecErr: DSID-03150E49, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0 ) for modify operation

見覚えのあるエラー。AD 側に作ったレプリケーション用ユーザの権限が甘かったらしい。このユーザを Domain Admins グループに追加したところ OK。ここに書いてあった「Write/Create all child objects/Delete all child objects/Add GUID」は全部確認したんだけどなぁ...

まぁともあれ双方向レプリケーションは出来た。ちなみに LDAP-> AD 向きのパスワード同期については、ldappasswd (LDAPv3 Password Modify -RFC 3062) では駄目で、ldapmodify で userPassword に対して生パスワードを設定する必要がある。



2017年11月25日土曜日

Container Linux Config

Container Linux の設定が coreos-cloudinit でなく "Container Linux Config" で行うようになったけど、自分の頭の中の切り替えも結構必要なようだ。

普段 Vultr で CoreOS を使ってるが、running な CoreOS の設定(コンテナじゃなくて CoreOS 自体の設定)を変更しなくちゃならんときは、/usr/share/oem/cloud-config.yml をいじれば何とかなる。しかし、GCE の CoreOS や最新の PXE のイメージで標準になってる "Container Linux Config" の Ignition は本当に起動時にだけ実行され(see: https://coreos.com/ignition/docs/latest/what-is-ignition.html#when-is-ignition-executed)るとのこと。じゃぁ running で設定を変更したいときはどうするんじゃと...

https://www.bountysource.com/issues/43393940-edit-user-in-cloud-config-yml-remains-the-old-one-why あたりを見る限りは、Ignition には ignition.json を変更するというユースケースはないとのこと。

おそらく CoreOS 自体(コンテナじゃなくて)を永続化させるってのが、既にコンセプトと違うんだろう。etcd ver.3 (etcd-member)からは rkt の別コンテナで動かすようになってるし、とにかくステートを持つものはコンテナとして起動させろってことなんだろう。

全然関係ないけど、Vultr でインスタンスを作る時に「CoreOS」という名前のままなのは、レガシィな cloudinit 使ってるからなのか? あ、さらに関係ないけど、Vultr で Container Linux を iPXE で起動しようとして失敗するのは、たいていリソースが足りないからのようだ。Container Linux の本家のドキュメントには initrd を広げるのに最低 2GB の RAM が必要ということだ。ケチって 1GB RAM にすると失敗する。ケチりたいときは iPXE でなく既に用意されている CoreOS で cloud-config.yml をちまちまいじるしかないかも。

2017年11月21日火曜日

389 Directory と AD の連携 (AD->LDAP PassSync編)

先日の389 Directory と AD の連携 (AD-> LDAP 編)の続き。

前回は AD からアカウントの同期は出来るようになった。今回は AD 側でユーザが変更した(管理者が変更するのでもOK)パスワードを、389 Directory に送って同期するようにしてみる。

似たような仕組みは以前自分でも会社のプロジェクトで作ったことがあって、そのときは Windows 上の LSA(Local Security Authority) ってのがコールバックする PasswordChangeNotify() 関数を実装したけどおそらく同じ仕組みだろう。後で 389 のソース確認してみる->自分。

  1. まずは、389 Directory を LDAPS 化する。生でも行けるのかも知れんが、99 % のお客さんは暗号化して欲しいって言ってくるだろう。ただそんな場合でもオレオレ証明書(Self-Signed)で十分。なのでまずは 389 Directory に入れる証明書と秘密鍵を作って certutil に噛ませるために PKCS#12 にする。ここで -name で指定する friendlyname は Server-Cert という名前にしないと後で苦労するっぽい(この情報は Web のどこかに書いてあったんだけど見失ってしまった...)
  2. openssl req -x509 -newkey rsa:2048 -keyout 389.key -out 389.crt
    openssl pkcs12 -export -out 389.p12 -inkey 389.key -in 389.crt -name Server-Cert
    
  3. 上記でできた 389.p12 ファイルを pk12util で /etc/dirsrv/slapd-<インスタンス名>/ 下の NSS データベースに登録。
  4. pk12util -i 389.p12 -d /etc/dirsrv/slapd-ryo/
    
    PKCS#12 のパスワードやデータベースのパスワードを聞かれるので適切に応答する。そして登録できたか確認
    # certutil -L -d /etc/dirsrv/slapd-ryo
    Certificate Nickname                                         Trust Attributes
                                                                 SSL,S/MIME,JAR/XPI
    Windows Server AD CA cert                                    P,,  
    Server-Cert                                                  u,u,u
    
    Server-Cert って証明書があるのがわかる。ちなみにその上の Windows Server AD CA cert ってのは前回作った Windows Server 側の証明書。秘密鍵も確認。
    # certutil -K -d /etc/dirsrv/slapd-ryo
    certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
    Enter Password or Pin for "NSS Certificate DB":
    < 0> rsa      1xxxxxxxxxxxxxxxaff5b7826ec1dxxxxxxxxxx   Server-Cert
    
    ちなみに何らか失敗して p12 ファイルの登録をやり直したい場合に証明書と秘密鍵を消すが、これを certutil の -D で証明書だけ消すと秘密鍵が消せなくなるので注意。この場合は再度同じ p12 を登録してから certutil の -F オプションを使うとよい。数年前のコミュニティの ML でバグだって言っている人がいたが、直してないところをみるとディベロッパはバグじゃないと思ってるんだろう。

  5. あとは 389 Directory の設定に証明書の情報を入れるため以下 ldif を ldapmodify (-D "cn=Directory Manager")で登録。詳細は公式ドキュメント参照。
  6. dn: cn=encryption,cn=config
    changetype: modify
    replace: nsSSL3
    nsSSL3: off
    -
    replace: nsSSLClientAuth
    nsSSLClientAuth: allowed
    -
    add: nsSSL3Ciphers
    nsSSL3Ciphers: +all
    
    dn: cn=config
    changetype: modify
    add: nsslapd-security
    nsslapd-security: on
    -
    replace: nsslapd-ssl-check-hostname
    nsslapd-ssl-check-hostname: off
    
    続けて同様に ldapmodify で、以下 ldif を登録。これは後述の /etc/dirsrv/dirsrv/slapd-<インスタンス名>/下の pin.txt ってファイル(これも ldif ぽい)に関する設定のようだ。以下の nsSSLToken というのは、pin.txt の中の属性名を指し示している模様。
    dn: cn=RSA,cn=encryption,cn=config
    changetype: add
    objectclass: top
    objectclass: nsEncryptionModule
    cn: RSA
    nsSSLPersonalitySSL: Server-Cert
    nsSSLToken: internal (software)
    nsSSLActivation: on
    
  7. NSS データベースのパスワードファイル /etc/dirsrv/slapd-<インスタンス名>/pin.txt を以下のように作成。左辺の「internal (software)」は上記の nsSSLToken の値であることに注意。
  8. internal (software):secret
    
    パーミッションを dirsrv:dirsrv の 0400 にする。
    # chown dirsrv:dirsrv /etc/dirsrv/slapd-ryo/pin.txt
    # chmod 400 /etc/dirsrv/slapd-ryo/pin.txt
    
  9. あとは dirsrv (ns-slapd)を再起動するだけ。
  10. systemctl restart dirsrv@ryo
    
    ss すれば 636 で listen してるはず。

  11. 上記までで LDAPS 化は完了して、あとは AD 側の設定。公式ドキュメント(Installing PassSync)のところに Windows 用バイナリのリンクがあるので、ダウンロードしてインストールする。インストーラの最初の画面で以下の項目を入力する必要がある。
    • Host Name: 389 Directory サーバの FQDN
    • Post Number: LDAPS ポート(636)
    • User Name: 前回 389 Directory 上に作ったレプリケーション用ユーザ (cn=sync user,cn=config)
    • Password: 上記レプリケーション用ユーザのパスワード
    • Cert Token: よくわからない。必須でないので空っぽ。
    • Search Base: 同期するユーザの 389 Directory 側の Base DN

  12. Windows Server に PassSync をインストールし終わったら、PassSync に 389 Directory の LDAPS のサーバ証明書を certutil.exe でインポートする。公式ドキュメント(Configuring PassSync)参照のこと。ここで注意したいのが、前回同様 certutil.exe の -t オプションを "P,," とすること。
  13. cd "C:\Program Files\389 Directory Password Synchronization"
    certutil.exe -d . -A -n "DS CA cert" -t "P,," -a -i \path\to\389.crt
    
    ここで Windows お得意のマシンごと再起動。

  14. 389 Directory に戻ってひとつだけ前回にやっていなかったことがあって、それをやらなくてはならない。前回はレプリケーション用ユーザの "cn=sync user" を 389 Directory 上に作ったが、このユーザに userPassword 属性の書込を許可する aci を与えていなかった。以下 ldif を ldapmodify (-D "cn=Directory manager") で登録する必要がある
  15. dn: ou=people,dc=example,dc=com
    changetype: modify
    add: aci
    aci: (targetattr="userPassword")(version 3.0;acl "password sync";allow (write,compare) userdn="ldap:///cn=sync user,cn=config";)
    

  16. 上記までで設定は完了。 AD 側で、あるユーザのパスワードを変更すると 389 Directory 側の対応するユーザの userPassword 属性が変更されるはず。うまく行かない場合は、Windows Server 側の C:\Program Files\389 Directory Password Synchronization/passsync.log を確認すると良い。



2017年11月17日金曜日

PNF No Root

子供にスマホを買い与えるな馬鹿親!って議論は置いておいて、とりあえず Google の Find My Device (端末を探す)でうちの子がどこにいるかを知りたいわけですよ。
まだそういう監視下に置かせるべき年頃なので。

で、最近 g06+ なるスマホを買って子供に渡す前に、DMM Mobile のデータ SIM (SMS付き)を入れていろいろ実験してみたところ、どうも Find My Device で Can't find device が頻発する事象に悩まされることに。

自分の Nexus 6P + Softbank SIM は全然いつでも Find OK なのに何で? といろいろと調べたところ、以下がヒット。

スリープ後、時間が経つとプッシュ通知が来なくなる件
どうも、格安 SIM に多い現象ということ。上記 URL によれば MVNO 側の NAT テーブルのタイムアウトが、Google の PUSH サーバの Keep-Alive の間隔より短いらしい(ん?NATってことは MVNO が IPv6 対応なら問題ないのかな)。

まぁ Find My Device も PUSH 通知とセッションの維持の仕方は似たようなもんだろうから、早速上記 URL にあった PNF No Root を入れてその間隔を18 分に設定。おぉ、見違えるほど反応がよくなった。副作用として、バッテリーの減り方も遅くなったぞ。うん。

まぁ DMM Mobile の SIM はあくまでも実験で使ってるんであって、最終的には mineo の 音声 SIM を入れるんだけど。

悩んでいる人はお試しください。