ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。予めご了承ください。 なお、コメントspamと判断されたツッコミは自動的に消去されます。ご容赦ください。
【改訂新版】Samba [実践]入門 |
Linux教科書 LPICレベル3 300試験 |
マスタリング Nginx |
実践 パケット解析 第2版 |
改訂版 Sambaのすべて |
アンドキュメンテッド Microsoftネットワーク |
その他の書籍は だめだめ日記のおみせ@本店でどうぞ。
長らくInternal Server Errorのまま放置してましたが、一念発起してみましたです。
192.168.0.1ねたをひさびさ見たくなったのもありますし。
まぁ、ほとんど追記はしないと思いますが、ほそぼそ続けていこうかと思いますです。
自分のところだけかもしれませんが、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では直ってましたが、特にバグレポートも上がってないようですし、何が原因だったのか……。
検証をしていて気づきましたが、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
以前ここでもつぶやいたネタですが、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クライアント機能はちゃんと動作する模様……
ビルド10130での画像ですが、より詳細な画像を既にアップ済でした。
Facebookのページから参照してください(誰でも参照できるように設定したつもり)。
それはそうと、tdiaryを文字コードがEUC-JPの2.2.Xから、文字コードUTF-8の4.1.3にバージョンアップしたんですが、文字コード周りでかなりはまりました。
過去の日記データも表示する際にEUC-JPからUTF-8に自動的に変換されます。
という記載があるんですが、これがばぐっているようで、EUC-JPからよくわかんない文字コードに自動的に変換してました。 バックアップしてあったデータを手動でUTF-8に変換したところうまく表示されたのでよかったんですが……。
見ていると、ほかでも同じ不具合の報告がいくつかありました。
Microsoft社のブログにもありますし、このあたりに細かい画面イメージがありますが、Windows 10では、更新プログラムをP2P機構を使用して、インターネット上のどっかのPCから取得する動作がデフォルトになってます。
これは良いんですが(よくないですが……)、Windows Update の配信の最適化に関する FAQにある以下の記載が気になりました。
「従量課金接続が使われていることが検出された場合」はデータの自動送信は行われない(無用のトラフィックは発生しない)とのことですが、モバイルルータでNATしている環境などで「従量課金接続の検出」に失敗する可能性が否定できないということで、怖い機能だなぁと。
この機能のせいで、気づいたら従量課金がとんでもないことになっていたという事例が絶対に出てきそうな……。
あと、レジストリで設定できるようですが、FAQをみるとWifi接続での従量課金接続検出とあるので、PCからみてWifi接続でないケースでは、そもそもレジストリの設定がちゃんと効くのかとか、いろいろ微妙な気がします。
とりあえず、手元のWindows 10をAzure Active Directoryに参加させてみました。
ちなみにパケットキャプチャしながら見てたんですが、SSL通信をひたすらやってるだけなので、眺めていても無意味……
サインイン画面では、次のような感じでユーザ名を入力
サインイン後、「組織」が変わっていることを確認。
さらにユーザ情報も確認。
こんな感じで AzureAD\ユーザ名 というユーザとして認識されている模様。この AzureAD というドメイン名?は、AADの名称とは無関係に一律付与されるようでした。
ローカルユーザではないので、net user コマンドを実行しても一覧には表示されず。ただ、いわゆる AD に参加しているわけではないので、net user /domain コマンドを実行しても、次のような感じでエラーでした。
やってみました。
先ほど参加できたWindows 10の環境で、いったんAADから抜けたうえで、デフォルトゲートウェイを削除してみました。
SSLも含め、プロキシ経由でインターネットに出られることは、IEとEdgeとで確認の上、参加を試みたんですが……
こんな感じのエラーで参加できませんでした。
Integrating your on-premises identities with Azure Active Directoryという記事を見つけて、machine.configを設定してみたんですが、状況変わらず。
エラーコード 801c000c で検索しても何も情報ないし、Wiresharkで見てた感じ、HTTPS以外の通信はないですし、通信上はまったくエラーもないので、何が原因かわからないままです。
_ いっぱん妻 [あとは、FastCGI対応にして、処理速度をあげることが課題でしょうね...。]