だめだめ日記

■ [SYSTEM]いちおう復活

長らくInternal Server Errorのまま放置してましたが、一念発起してみましたです。

192.168.0.1ねたをひさびさ見たくなったのもありますし。

まぁ、ほとんど追記はしないと思いますが、ほそぼそ続けていこうかと思いますです。

■ [Samba]FreeBSD 10.0/10.1でsamba-tool domain provisonが動作しない

自分のところだけかもしれませんが、FreeBSD 10.0と10.1でsamba-tool domain provisionが動作しません。 具体的には、次のような感じで、pythonがSegmentation Faultになってしまいます。

# samba-tool domain provision --domain=ADDOM8 --realm=ADDOM8.AD.LOCAL --adminpass=P@ssw0rd
Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Segmentation fault (core dumped)

FreeBSD 10.2では直ってましたが、特にバグレポートも上がってないようですし、何が原因だったのか……。

■ [原稿]某書籍の原稿執筆完了!

4月ごろからずっと書いてた某書の原稿、ようやく書き上げましたです。10月からは別の書籍の翻訳に取り掛かろうかと思ってます。

■ [Samba][Linux]CentOS 7のSambaパッケージに/etc/pam.d/sambaがない

検証をしていて気づきましたが、CentOS 7でSambaを構成するパッケージには/etc/pam.d/sambaファイルがありません。ちなみにCentOS 6.Xでは、sambaパッケージに含まれていました。

このままだと、SambaでPAM関連の設定を行っても有効にならないので、CentOS 7では、手動で次のようなファイルを作成し、/etc/pam.d/sambaとしておいておきましょう。

auth        required    pam_nologin.so
auth        include     password-auth
account     include     password-auth
session     include     password-auth
password    include     password-auth

■ [Samba][Windows]Windows 10からSambaドメインへ参加する

以前ここでもつぶやいたネタですが、Windows 10からSambaドメインへ参加できるかを検証してみました。

Samba側は次のように最低限のsmb.confを設定

[global]
  workgroup = SAMBADOM
  domain logons = yes
  add machine script = /usr/sbin/useradd -d /dev/null -s /bin/false %u

  # Windows 10のSAMBAドメイン参加には次の設定が必須
  server max protocol = NT1

# 動作確認用のファイル共有
[homes]
  writeable = yes
  browserable = no

例のレジストリを変更してから参加させてみたところ、次のようにちゃんと成功しました。

ちなみに、Windows 10をSambaサーバと別IPサブネットに移動したうえで、Sambaサーバで

wins support = yes

を指定し、Windows 10側でもWINSサーバの設定をして試してみましたが、ちゃんと参加できました、ということで、Windows 10でもWINSクライアント機能はちゃんと動作する模様……

追記（2015/09/22）

ビルド10130での画像ですが、より詳細な画像を既にアップ済でした。

Facebookのページから参照してください（誰でも参照できるように設定したつもり）。

■ [Samba]Samba 4.3.0リリースノートの翻訳

しました。

• Samba 4.3.0 リリースノートの翻訳
• Samba 4.3.0 Available for Download（原文）

■ [Linux]tdiaryのバージョンアップ（文字コード問題）

それはそうと、tdiaryを文字コードがEUC-JPの2.2.Xから、文字コードUTF-8の4.1.3にバージョンアップしたんですが、文字コード周りでかなりはまりました。

tdiary 3.0.0のリリースノートを見ると

過去の日記データも表示する際にEUC-JPからUTF-8に自動的に変換されます。

という記載があるんですが、これがばぐっているようで、EUC-JPからよくわかんない文字コードに自動的に変換してました。 バックアップしてあったデータを手動でUTF-8に変換したところうまく表示されたのでよかったんですが……。

見ていると、ほかでも同じ不具合の報告がいくつかありました。

• [tdiary] tDiary アップデート (tDiary-2.2.0 => tDiary-3.2.2)
• tdiary 3.2.0

■ [Windows]Windows 10の更新プログラムの提供方法

Microsoft社のブログにもありますし、このあたりに細かい画面イメージがありますが、Windows 10では、更新プログラムをP2P機構を使用して、インターネット上のどっかのPCから取得する動作がデフォルトになってます。

これは良いんですが（よくないですが……）、Windows Update の配信の最適化に関する FAQにある以下の記載が気になりました。

「従量課金接続が使われていることが検出された場合」はデータの自動送信は行われない（無用のトラフィックは発生しない）とのことですが、モバイルルータでNATしている環境などで「従量課金接続の検出」に失敗する可能性が否定できないということで、怖い機能だなぁと。

この機能のせいで、気づいたら従量課金がとんでもないことになっていたという事例が絶対に出てきそうな……。

あと、レジストリで設定できるようですが、FAQをみるとWifi接続での従量課金接続検出とあるので、PCからみてWifi接続でないケースでは、そもそもレジストリの設定がちゃんと効くのかとか、いろいろ微妙な気がします。

■ [Windows]Azure Active Directoryに参加

とりあえず、手元のWindows 10をAzure Active Directoryに参加させてみました。

ちなみにパケットキャプチャしながら見てたんですが、SSL通信をひたすらやってるだけなので、眺めていても無意味……

サインイン画面では、次のような感じでユーザ名を入力

サインイン後、「組織」が変わっていることを確認。

さらにユーザ情報も確認。

こんな感じで AzureAD\ユーザ名 というユーザとして認識されている模様。この AzureAD というドメイン名？は、AADの名称とは無関係に一律付与されるようでした。

ローカルユーザではないので、net user コマンドを実行しても一覧には表示されず。ただ、いわゆる AD に参加しているわけではないので、net user /domain コマンドを実行しても、次のような感じでエラーでした。

■ [Windows]Azure Active Directoryにプロキシ経由で参加できるか

やってみました。

先ほど参加できたWindows 10の環境で、いったんAADから抜けたうえで、デフォルトゲートウェイを削除してみました。

SSLも含め、プロキシ経由でインターネットに出られることは、IEとEdgeとで確認の上、参加を試みたんですが……

こんな感じのエラーで参加できませんでした。

Integrating your on-premises identities with Azure Active Directoryという記事を見つけて、machine.configを設定してみたんですが、状況変わらず。

エラーコード 801c000c で検索しても何も情報ないし、Wiresharkで見てた感じ、HTTPS以外の通信はないですし、通信上はまったくエラーもないので、何が原因かわからないままです。