既存のSamba 4.5以前を4.7へアップデートする場合の注意点


あまり考えずに既存のSamba 4.4.x環境を最新のSamba 4.7.xにアップデートをした。
ようは、configure;make;make install。

が・・・「Updating Samba」を見ると、Samba 4.5.0で「replPropertyMetaData」の取り扱いが変わったので修正しなければならない、という記載が・・・

修正が必要かどうかは「samba-tool dbcheck –cross-ncs」で確認出来る、とのこと

問題なければ、下記の出力・・・

# samba-tool dbcheck --cross-ncs
Checking 3602 objects
Checked 3602 objects (0 errors)
#

問題がある場合は下記の様な形でエラーが報告されます。
ちなみに、エラーのテキスト出力が6.5MBありました・・・

# samba-tool dbcheck --cross-ncs --fix --yes
Checking 3602 objects
CN=MHS-OR-Address,CN=Schema,CN=Configuration,DC=adosakana,DC=local: 0x0009030e
CN=MHS-OR-Address,CN=Schema,CN=Configuration,DC=adosakana,DC=local: 0x00090177
<略>
Checked 3602 objects (3467 errors)
#

「samba-tool dbcheck –cross-ncs –fix –yes」を実行することで修正されました。

また、4.0以前のバージョンからアップデートした場合にSYSVOLの修復を行うために「samba-tool ntacl sysvolreset」を実行するという記述があったので、試しにSYSVOLのチェック「samba-tool ntacl sysvolcheck」を実行してみると、下記のエラーが発生。

# samba-tool ntacl sysvolcheck

ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO directory /usr/local/samba/var/locks/sysvol/adosakana.local/Policies/{20AA5877-2399-4CBC-8BA4-7F23D8810774} O:DAG:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/netcmd/ntacl.py", line 270, in run
    lp)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/provision/__init__.py", line 1723, in checksysvolacl
    direct_db_access)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/provision/__init__.py", line 1674, in check_gpos_acl
    domainsid, direct_db_access)
  File "/usr/local/samba/lib64/python2.6/site-packages/samba/provision/__init__.py", line 1621, in check_dir_acl
    raise ProvisioningError('%s ACL on GPO directory %s %s does not match expected value %s from GPO object' % (acl_type(direct_db_access), path, fsacl_sddl, acl))
#

「samba-tool ntacl sysvolreset」を実行して修正。

# samba-tool ntacl sysvolreset
# samba-tool ntacl sysvolcheck
#

単3電池駆動の携帯電話SpareOneは会社ごと死亡


非常時に使える単三乾電池で駆動する携帯電話Spare One
最近話題を聞かないけど、どうしたのかなぁ、と調べて見た

2013/06/06: 単3電池駆動のシンプルフォンSpare Oneに新モデルSpare One plus登場
2014/06/06: 単3乾電池で動作する携帯SpareOneがComputex Debut!の謎
2016/07/26: 単3電池駆動の携帯電話SpareOneの3Gモデルが登場していた

サイトにアクセスしてみると・・・

ドメイン消滅済み。

調べて見ると、アメリカでSpare Oneを販売していたこともあるAT&Tからお知らせがでているのを発見。
SpareOne service no longer available
AT&TのプリペイドSIMで販売したSpareOne Emergency Phone向けのサービスは2017年10月15日で終了します。という告知。

いまだにAmazon.comで売ってるSellerがいる、というのもアレだけど、レビューを読むとAT&Tの告知は2017年8月31日ぐらいにでて、9月7日頃にはSpareOneのWebもサポートも連絡が取れなくなった模様。

まぁ、緊急時の警報通報サービスシステムが使えなくなっている、というだけなので、電話として使うことはできるようなんですが、GSM自体も先が無いですし、見込まれた終焉って感じがしなくもないですね・・・

samba 4.7.4で作ったActive Directory環境でWindowsServer2016フェールオーバークラスターを動作させた


以前試したときはうまくいかなかったが、どうやら、動くらしい、という話を聞いて試してみた。

Samba 4.7.4で、ドメインレベル/フォレストレベルをWindows Server 2008R2に設定した状態で実施。
(レベルの確認・変更については「samba 4.xでドメイン/フォレストの機能レベルを変更する」を参照のこと)

クラスタの検証は問題なく通過し、実際に組んで見るとネットワークへのリソース名登録周りでエラーが発生。

ログの名前:         System
ソース:           Microsoft-Windows-FailoverClustering
日付:            2018/02/28 18:41:44
イベント ID:       1194
タスクのカテゴリ:      ネットワーク名リソース
レベル:           エラー
キーワード:         
ユーザー:          SYSTEM
コンピューター:       server1.adosakana.local
説明:
クラスター ネットワーク名リソース 'クラスタリソース1' は、ドメイン 'adosakana.local' の関連付けられたコンピューター オブジェクトを作成できませんでした (期間: Resource online)。

関連するエラー コードのテキストは次のとおりです: アクセスが拒否されました。

ドメイン管理者と協力して、次のことを確認してください。
- クラスター ID 'クラスタ名$' が、コンピューター オブジェクトを作成するためのアクセス許可を持っていること。既定では、すべてのコンピューター オブジェクトがクラスター ID 'クラスタ名$' と同じコンテナー内に作成されます。
- コンピューター オブジェクトのクォータに達していないこと。
- 既存のコンピューター オブジェクトがある場合は、[Active Directory ユーザーとコンピューター] のツールを使用して、クラスター ID 'クラスタ名$' にそのコンピューター オブジェクトに対するフル コントロールのアクセス許可があることを確認してください。

解決方法はMicrosoftのKB「クラスター環境においてクライアント アクセス ポイントを作成または削除した際、イベント ID 1222 と 1197 が記録される。」にあるままでした。
下記の設定を行ったところ、クラスタが起動するようになりました。

1. Domain Administrator権限を持っているユーザで「Active Directory ユーザーとコンピューター」を開く
2. 「表示」-「拡張機能」を選択し、セキュリティなどの設定が表示される状態に変更
3. 「Computers」コンテナのプロパティを開く
4. 「セキュリティ」タブの「詳細設定」を開く
5. 「追加」を開く
6. まず、「プリンシパルの選択」のリンクをクリック
 「オブジェクトの種類」を開き、「コンピュータ」にチェックを入れる
 「選択するオブジェクト名を入力してください」の下の欄にエラーがでた「クラスタ名」を入力
 「名前を確認」してOK
7. 種類「許可」、適用先「このオブジェクトとすべての子オブジェクト」が選択されていることを確認
8. アクセス許可は「すべてのプロパティの読み取り」と「すべての子オブジェクトの作成」にチェック
 他の項目は標準設定のままで良い
9. この設定でセキュリティの追加を完了する

メールソフトの設定自動検出用DNSレコード


久しぶりにメールサーバの設定をいろいろやった。
その際にテスト用にメールソフトを設定したが、何やら自動検出の仕組みがあるようだ
調べて見ると、RFC6186により定義されているDNSのSRVレコードにより、IMAP/POP3/SMTPのサーバ名、ポート番号情報を広報することができるらしい。

SRVレコードの定義:RFC2782 A DNS RR for specifying the location of services (DNS SRV)
SRVレコードでメールサーバ定義を配布:RFC6186 Use of SRV Records for Locating Email Submission/Access Services

設定例としてmailcowの「DNS records」にちょうどいい感じのがあったので引用

Example DNS server configuration
mail                IN A       1.2.3.4
autodiscover        IN A       1.2.3.4
autoconfig          IN A       1.2.3.4

@                   IN MX 10   mail

_imap._tcp          IN SRV     0 1 143 mail.example.org.
_imaps._tcp         IN SRV     0 1 993 mail.example.org.
_pop3._tcp          IN SRV     0 1 110 mail.example.org.
_pop3s._tcp         IN SRV     0 1 995 mail.example.org.
_submission._tcp    IN SRV     0 1 587 mail.example.org.
_caldavs._tcp       IN SRV     0 1 443 dav.example.org.
_carddavs._tcp      IN SRV     0 1 443 dav.example.org.
_autodiscover._tcp  IN SRV     0 1 443 autodiscover.example.org.

@                   IN TXT     "v=spf1 mx ~all"
default._domainkey  IN TXT     "v=DKIM1; k=rsa; t=s; s=email; p=..."
; _dmarc            IN TXT     "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.org"

「_サービス名.tcp IN SRV 優先度 ウェイト ポート番号 サーバ名」というのが基本書式
優先度は0が最優先。最大は65535。
優先度が同じもののなかで、どちらが使われるかをウェイトで定義。ウェイトは数が大きい方が優先される。こちらも値は0~65535の範囲。

例えば、SSL無しのアクセスを禁止する場合、下記のように禁止するサービスの名前解決を「.」が返るようにする

_imap._tcp          IN SRV     0 0 0 .
_imaps._tcp         IN SRV     0 1 993 mail.example.org.
_pop3._tcp          IN SRV     0 0 0 .
_pop3s._tcp         IN SRV     0 1 995 mail.example.org.

IMAPを優先して使わせたい場合は、以下のようになるようだ。

_imap._tcp          IN SRV     0 1 143 mail.example.org.
_imaps._tcp         IN SRV     0 1 993 mail.example.org.
_pop3._tcp          IN SRV     10 1 110 mail.example.org.
_pop3s._tcp         IN SRV     10 1 995 mail.example.org.

Outlookの場合は、DNSの_autodiscoverについてのSRVレコード登録から、Webサーバ上にあるxmlファイル内にアクセスして、サーバ設定を読み込むようになっているようだ
Outlook 2010 におけるユーザー アカウント自動構成の計画

Exchange互換のSOGoを使う場合の設定は「6.5. Name Service Configuration for Web Services」に記載がある。

このページにSPF/DKIM/DMARCの動作確認「HAD Email Test Tool」が紹介されていたので記載されているメールアドレスに「test」と書いたメールを送ってみた。

・・・30分ぐらい待ってもメールが来ない
「 A reply will be sent with the findings」とあるから、何か見付かったらメールが来るってことで、来ないってことは問題ないということでいいのかな?っと

ESXi 6.5でVMDirectPath I/Oが設定できるけど使えない


ESXi6.5環境において、16Gb FC HBAのQLogic QLE2662に対して、VMDirectPath I/Oで仮想マシンから直接使える様にパススルー設定をした。
設定は問題なくできたものの、仮想マシンを起動してみると、全然認識してくれない。

よく、パススルー設定で選択できない、という話は聞くが、今回は、設定は出来ている。
ためしに8GbのFC HBA QLE2540 を使ってみると、同様の手法で設定でき、仮想マシンからちゃんと認識している。

ここら辺に糸口があるな、と調査。

<調査過程は省略>

結論からすると「VMware vSphere VMDirectPath I/O:プラットフォームとデバイスの要件」(英語版:VMware vSphere VMDirectPath I/O: Requirements for Platforms and Devices)の「PCI 機能リセット」設定の問題だった。

パススルー設定したPCIeデバイスは、物理サーバ起動時に初期化しているが、接続されている仮想マシンが起動する毎にPCIeデバイスの初期化を行う必要がある。
この初期化手法をどういう風に行うか、という設定を適切に行わないと、仮想マシン側で認識できないようだ。

設定はESXi上の /etc/vmware/passthru.map で行われている。

うまく動いたQLE2540のVender ID/Product IDを「esxcfg-info」コマンドで確認すると「1077」「2523」。
これは /etc/vmware/passthru.map で「1077 2532 default false」という定義で設定されている。
意味は、初期化手法がdefaultで、fptShareableがfalseなので全体初期化になる、というもの。
全体初期化であるため、1枚に複数ポートがある場合、別の仮想マシンに割り当てることができず、同じ仮想マシンに全部のポートを割り当てる必要がある、ということになる。

動かなかったQLE2662の方は「1077」「2031」。
記載が無いので、適切な初期化方法を見つけて追加する必要がある。
KBに「PCI ホスト ブリッジ直下の PCI 機能を VMDirectPath I/O で使用するには、FLR または D3Hot リセットをサポートする必要があります」とあるため「flr」の場合と「d3d0」の場合をそれぞれ実験。
結果、「d3d0」の時のみ仮想マシン側でもデバイスを認識してくれた。

ということで、/etc/vmware/passthru.mapの最終行に「1077 2031 d3d0 default」という記載を追加した。

なお、設定後は、ESXiを再起動する必要がある。

# cd /etc/vmware/passthru.map
# passthrough attributes for devices
# file format: vendor-id device-id resetMethod fptShareable
# vendor/device id: xxxx (in hex) (ffff can be used for wildchar match)
# reset methods: flr, d3d0, link, bridge, default
# fptShareable: true/default, false

# Intel 82579LM Gig NIC can be reset with d3d0
8086  1502  d3d0     default
# Intel 82598 10Gig cards can be reset with d3d0
8086  10b6  d3d0     default
8086  10c6  d3d0     default
8086  10c7  d3d0     default
8086  10c8  d3d0     default
8086  10dd  d3d0     default
# Broadcom 57710/57711/57712 10Gig cards are not shareable
14e4  164e  default  false
14e4  164f  default  false
14e4  1650  default  false
14e4  1662  link     false
# Qlogic 8Gb FC card can not be shared
1077  2532  default  false
# QLogic QL45604 cards need to be reset with "link" and cannot be shared
1077  1634  link     false
1077  1629  link     false
1077  1636  link     false
1077  1656  link     false
1077  1644  link     false
1077  1654  link     false
# LSILogic 1068 based SAS controllers
1000  0056  d3d0     default    
1000  0058  d3d0     default
# NVIDIA
10de  ffff  bridge   false
# for QLE2662
1077  2031  d3d0     default
#