samba 4.10.x環境で出てたsamba_dnsupdateのエラー対処

samba 4.10.7へアップデートしたあと、「systemctl status samba-ad-dc.service」で出力されるログを見てみたら、微妙な感じのエラーがあった。

18月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.287210,  0] ../../lib/util/util_runcmd.c:327(samba_runcmd_io_handler)
28月 29 08:54:02 adserver samba[107156]:   /usr/local/samba/sbin/samba_dnsupdate: ImportError: No module named dns.resolver
38月 29 08:54:02 adserver samba[107156]: [2019/08/29 08:54:02.295161,  0] ../../source4/dsdb/dns/dns_update.c:331(dnsupdate_nameupdate_done)
48月 29 08:54:02 adserver samba[107156]:   dnsupdate_nameupdate_done: Failed DNS update with exit code 1
58月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.430795,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
68月 29 08:54:03 adserver winbindd[107159]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
78月 29 08:54:03 adserver smbd[107151]: [2019/08/29 08:54:03.438943,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
88月 29 08:54:03 adserver smbd[107151]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
98月 29 08:54:03 adserver winbindd[107159]: [2019/08/29 08:54:03.454411,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
108月 29 08:54:03 adserver winbindd[107159]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections

「samba_dnsupdate: ImportError: No module named dns.resolver」の対応

現状の確認方法

1[root@adserver ~]# samba_dnsupdate --verbose
2Traceback (most recent call last):
3  File "/usr/local/samba/sbin/samba_dnsupdate", line 57, in <module>
4    import dns.resolver
5ImportError: No module named dns.resolver
6[root@adserver ~]#

原因はpythonのDNS toolkitがインストールされていないこと。

CentOS7環境で対処するには「yum search dnspython」を実行してモジュール名を確認

1[root@adserver ~]# yum search dnspython
2読み込んだプラグイン:fastestmirror
3Determining fastest mirrors
4 * base: ftp.riken.jp
5 * epel: ftp.riken.jp
6 * extras: ftp.riken.jp
7 * updates: ftp.riken.jp
8=============================== 一致: dnspython ================================
9python-dns.noarch : DNS toolkit for Python
10python36-dns.noarch : DNS toolkit for Python 3
11[root@adserver ~]#

今回使っている環境はpython 2環境なので、「yum install python-dns」でインストール。

1[root@adserver ~]# yum install python-dns.noarch
2読み込んだプラグイン:fastestmirror
3Loading mirror speeds from cached hostfile
4epel/x86_64/metalink                                     | 7.3 kB     00:00
5 * base: ftp.riken.jp
6 * epel: ftp.riken.jp
7 * extras: ftp.riken.jp
8 * updates: ftp.riken.jp
9base                                                     | 3.6 kB     00:00
10epel                                                     | 5.4 kB     00:00
11extras                                                   | 3.4 kB     00:00
12packages-microsoft-com-prod                              | 2.9 kB     00:00
13updates                                                  | 3.4 kB     00:00
14(1/3): epel/x86_64/updateinfo                              | 998 kB   00:02
15(2/3): packages-microsoft-com-prod/primary_db              | 200 kB   00:00
16(3/3): epel/x86_64/primary_db                              | 6.8 MB   00:03
17依存性の解決をしています
18--> トランザクションの確認を実行しています。
19---> パッケージ python-dns.noarch 0:1.12.0-4.20150617git465785f.el7 を インスト ール
20--> 依存性解決を終了しました。
21 
22依存性を解決しました
23 
24================================================================================
25 Package        アーキテクチャー
26                           バージョン                            リポジトリー
27                                                                           容量
28================================================================================
29インストール中:
30 python-dns     noarch     1.12.0-4.20150617git465785f.el7       base     233 k
31 
32トランザクションの要約
33================================================================================
34インストール  1 パッケージ
35 
36総ダウンロード容量: 233 k
37インストール容量: 1.0 M
38Is this ok [y/d/N]: y
39Downloading packages:
40python-dns-1.12.0-4.20150617git465785f.el7.noarch.rpm      | 233 kB   00:00
41Running transaction check
42Running transaction test
43Transaction test succeeded
44Running transaction
45  インストール中          : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1
46  検証中                  : python-dns-1.12.0-4.20150617git465785f.el7.no   1/1
47 
48インストール:
49  python-dns.noarch 0:1.12.0-4.20150617git465785f.el7
50 
51完了しました!
52[root@adserver ~]#

動作確認・・・

1[root@adserver ~]# samba_dnsupdate --verbose
2IPs: ['172.17.44.49']
3Looking for DNS entry A adserver.adosakana.local 172.17.44.49 as adserver.adosakana.local.
4Looking for DNS entry NS adosakana.local adserver.adosakana.local as adosakana.local
5<略>
6Checking 0 100 389 adserver.adosakana.local. against SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.adosakana.local adserver.adosakana.local 389
7No DNS updates needed
8[root@adserver ~]#

それ以外のログについて

samba_dnsupdateに関するエラーについて対処した後、sambaを再起動してログを見てみると、下記の様な感じになっていた。

18月 29 09:06:46 adserver samba[107294]: [2019/08/29 09:06:46.991243,  0] ../../source4/smbd/server.c:773(binary_smbd_main)
28月 29 09:06:46 adserver samba[107294]:   binary_smbd_main: samba: using 'standard' process model
38月 29 09:06:47 adserver samba[107294]: [2019/08/29 09:06:47.021548,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
48月 29 09:06:47 adserver samba[107294]:   daemon_ready: daemon 'samba' finished starting up and ready to serve connections
58月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.157089,  0] ../../source3/winbindd/winbindd_cache.c:3166(initialize_winbindd_cache)
68月 29 09:06:49 adserver winbindd[107312]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
78月 29 09:06:49 adserver winbindd[107312]: [2019/08/29 09:06:49.266323,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
88月 29 09:06:49 adserver winbindd[107312]:   daemon_ready: daemon 'winbindd' finished starting up and ready to serve connections
98月 29 09:06:50 adserver smbd[107311]: [2019/08/29 09:06:50.436561,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
108月 29 09:06:50 adserver smbd[107311]:   daemon_ready: daemon 'smbd' finished starting up and ready to serve connections

RHEL7だと上記出力を赤文字で出力してるけど、内容を見る限りではinformation的なものであるので、特に対処する必要はなさそうである。

qmailの情報収集 2019/08/26

2019/08/26: このURLの初期版作成
2023/11/17: 情報更新


qmailを使ってないけど、このURLや2016年の「qmailの情報収集 2016/03/31」と2012年の「いまさらqmailのパッチ情報収集 2012/02/17」には今もアクセスがあるので内容を更新しておく。

2023/11/17のトピック

・netqmail.orgとqmail.orgのサイト消滅
djbのqmailページは現存しているがメンテナンスはされていない
notqmail2020/05/20に1.08をリリースしたのが最後だが、githubでは開発継続中
s/qmailはURL変更。2023/10/22 4.2.28を出し、4.3を開発中
・openQmailはサイト消滅
・aQmailはgithubあるけど2017年12月以降未更新
・IndiMailはgithubが公式ページ化? ソースコードはgithubsourceforge

継続してメンテナンスされているのは、IndiMail と s/qmail であるようだ。

実際の運用に関して参考になりそうな資料

saGredo.eu linux notePatching qmail
qmailへの各種パッチ適用手法について

saGredo.eu linux noteConfiguring DKIM for qmail
qmailのvirtualdomain環境時に署名を行う手法をindimailによるqmail-dkimパッチ集を使用して解説。なお、IndiemailでのDKIM関連記述


ここから下は以前の記述


うちはqmailを使わなくなったけど、使っていた当時に書いた2016年の「qmailの情報収集 2016/03/31」と2012年の「いまさらqmailのパッチ情報収集 2012/02/17」には、いまでもちらほらアクセスがある。

で・・・最近、qmail的に大ニュースがあったので久々に情報更新。

期待の新星「notqmail」リリース

1998年6月リリースのqmail v1.03に対するパッチをまとめたnetqmail がv1.04として2003年10月にリリースされた。しかし、netqmailは2007年11月のv1.06を最後に更新が無くなった。

今回、qmailでもnetqmailでもないものとして、notqmailがv1.07としてリリースされた。

ゆくゆくはいろんな機能を取り入れることになっていく予定ですが、現状では有名どころの既存qmailパッチ間の差異が大きいようで、notqmailのブランチとして各パッチ適用済みバージョンも提供されている。(詳細は公式ページのPatchesを参照のこと)

BranchOriginal Patch
notqmail-badmailfrom-wildcardTom Clegg’s badmailfrom wildcard
notqmail-badmailfrom-x-relayclientJeremy Kitchen’s badmailfrom-x-relayclient
notqmail-big-concurrencyJohannes Erdfelt’s big-concurrency
notqmail-big-todoRussell Nelson’s big-todo
notqmail-dns-any-to-cnameJonathan de Boyne Pollard’s any-to-cname
notqmail-dns-oversizeChristopher K. Davis’s oversize DNS packet
notqmail-ext-todoAndré Opperman’s ext_todo or “silly qmail syndrome”
notqmail-smtp-authErwin Hoffmann’s smptauth
notqmail-smtp-tlsFrederik Vermeulen’s qmail-smtp-tls
notqmail-smtpd-loggingAndrew Richards’ qmail-logmsg
notqmail-smtpd-spfJana Saout’s qmail-spf

「s/qmail」は細々運営中?

2016年に公式リリースされた「s/qmail」は、2019年6月のv3.3.23が最新リリースとなっている。

ただ、作者のnewsページを見てみると「aqmail is a joint project of Erwin Hoffmann (s/qmail) and Kai Peter (eqmail) to provide an alternative Qmail. Coming soon.」として「aqmail」というものを始めるらしい。

qmail開発者2人によるジョイントプロジェクト「aqmail」

aqmail is a joint project of Erwin Hoffmann (s/qmail) and Kai Peter (eqmail) to provide an alternative Qmail. Coming soon.」として「aqmail」 が2017年に開始されている。

が・・・githubのレポジトリ https://github.com/aqmail/aQmail は全然更新されていないが、元となるs/qmailとeQmailは更新されているという・・・

qlibというeQmail作者が作ったライブラリを利用している。

「eQmail」

サイトとしては「openQmail」という名称となっている。

元のqmailは内部で「djb’s libs」と呼ばれるdjbが作成したライブラリ群を使用しているがこれらはあくまでqmail内部でのみ使われているようなものだった。これを単体ライブラリ化したものがlibdjb(最終リリース2000年10月)となる。そして、このライブラリをGPLとして再実装したものが libowfat(最新リリース2018年10月)というものとなる。

libowfatとdjb’s libsをeQmail作者が使いやすいように実装し直したものが qlib というライブラリになるようで、eQmailではコレを使用している。

こちらは2019年8月リリースのeQmail-1.10.1が最新となっている。

「IndiMail」

IndiMail」という公式ページがあるが管理状況が怪しい。

SOURCEFORGEのIndiMailプロジェクトページを見てみるとそこそこ更新されている。

qmail部分であるindimailパッケージのバージョンとしては2018年10月リリースのindimail v2.6が最新であるようだ。

RHEL7以降のGUIでユーザが初回ログインした際のようこそ画面を消す

RHEL7やRHEL8をGUIつきでインストールすると、各ユーザがログインした際に、gnome-initial-setupコマンドが自動起動し、以下の様な表示を行う。

これは設定をすすめればいいだけではあるんだけど、めんどくさい。

Solaris 7以降でも似たような感じで登録要求画面が表示されてたけど、所定の空ファイルを置くことで表示しないようにできたけど、RHELでもできるかな?と調べて見た。

githubにあるgnome-initial-setupのソースコードを調べていくと、HACKINGに情報を発見。


gnome-initial-setup also has a session mode which activates gnome-initial-setup when a user first logs in. The gnome-initial-setup-first-login.desktop in the
xdg autostart directory utilises gnome-session to check if the user has a
gnome-initial-setup-done file in their XDG_CONFIG_DIR if they don’t
gnome-initial-setup will launch with pages that are suitable for a
non-privileged user and on exiting will write the done file.

各ユーザの環境変数 XDG_CONFIG_DIR で定義されたディレクトリ内に「gnome-initial-setup-done」というファイルがあれば良い、ということ。

しかし、Oracle Linux 8で確認してみると XDG_CONFIG_DIRは定義されていない。

XDG_CONFIG_DIR の定義について調べると「XDG Base Directory Specification」に記載があった。

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

定義されていない場合は、各ユーザのホームディレクトリ内にある「.config」となるとのこと。

つまり「~/.config/gnome-initial-setup-done」というファイルを作れば良い、ということになる。

というわけで「touch ~/.config/gnome-initial-setup-done」を実行することで、gnome-initial-setupの起動をさせないようにできた。


ここまでで紹介した手順は各ユーザ単位で表示させなくする設定。

全体として表示させなくする設定が無いかを確認。

先ほども参照したHACKINGのgnome-initial-setup-doneの話の直前に情報がいくつか。

/etc/gdm/custom.confの[daemon]セクションに「InitialSetupEnable=True」と書くとgnome-initial-setupが起動する、ということなので、逆に「InitialSetupEnable=False」と書けばいいのかと試してみたけど、ダメでした。

InitialSetupEnable 関連で検索して「Bug 1226819 – gnome-initial-setup cannot be disabled, forces user creation」を発見。

ユーザを作成する際に初期配置するファイルを置く「/etc/skel」ディレクトリ内に「.config/gnome-initial-setup-done」ファイルを作っちゃえばいいんじゃん?という話が・・・確かに!( mkdir -p /etc/skel/.config && touch /etc/skel/.config/gnome-initial-setup-done を実行する)

他に書かれている/etc/xdg/autostart/gnome-initial-setup-copy-worker.desktop と /etc/xdg/autostart/gnome-initial-setup-first-login.desktop ファイルを削除する、というのは若干いきすぎた対応な気がするので、こちらはどうなのかな・・・


その後、RedHatのナレッジに「RHEL7 の初期インストール後の実行から gnome-initial-setup を無効にする」というのがあり対処方法が記されている、と聞きました。

ユーザ毎の対処方法は上で書いた手法でした。システム全体手法は上記では書いてない方法をとっていました。詳細についてはURLを見てください。

ESXi上でCentOS7なのにCentOS6だと言われる件

ESXi上でCentOS7をインストールした場合、open-vm-toolsをインストールされていても「CentOS6」だと言われてしまう件について調査した。

なお、何故かvCenter上から見た場合は警告されず、直接ESXi上で仮想マシンを見た際にだけ言われる。

結論めいたこと

open-vm-toolsのバグ(Fix CentOS 7.6 detection)で、open-vm-tools 10.3.10以降で修正されている。

しかし、2019/06/27時点でのCentOS7のopen-vm-toolsは10.2.5であり修正されていないバージョンであるため公式な手法では対処できない。

回避策としては2つある

/etc/centos-release を修正する

今回のバグは「CentOS Linux release 7.6.1810 (Core)」の文字列からOSバージョン判定をする際に「”6.”があればCentOS6」「”7.”があればCentOS7」「”8.”があればCentOS8」という順番で行っているせいで、「7.6.1810」の中にある「6.」を読み取ってしまい「CentOS6」と判定されていることにより発生している。

このため、/etc/centos-release 内の誤判定要素を無くすことで対処できなくもない。

例えば「 CentOS Linux release 7.6 1810 (Core) 」と、「.」を抜いてしまうとか。

ただ、このファイルは他のソフトウェアでもディストリビューション判別に使用されており、そこでの条件の書き方によっては正しく判定できなくなってしまう恐れもあるため、注意が必要である。

もしくはCentOS 7.7以降ではれば、「6.」に引っかかることがなくなるので、アップデートする、という手もとれる。

vSphere仮想マシンオプションのゲストOSを修正する

vSphere6.5以降(仮想マシンバージョン13以降)でCentOS7を使用する場合、仮想マシンオプションで「ゲストOS:Linux」と「ゲストOSのバージョン:CentOS 7(64ビット)」を設定する。

誤判定で「CentOS 6(64ビット)」と認識されているんだったら、仮想マシンオプションの「ゲストOSのバージョン」も「CentOS 6 (64ビット)」にしちゃえばいいじゃん。

という非常に雑な対応手法。

なんでこんなことに

githubにあるopen-vm-toolsのソースコードからopen-vm-tools/open-vm-tools/lib/misc/hostinfoPosix.c を見てみるとひたすら条件が列挙されている。

いままではバージョン表記の中に「.」が2個登場するという想定が無かったようで、Debianでも同様の手法で判定しています。

今回のCentOSでの対応は、いままで「6.」をキーにしていたものを「 6.」と数字の前にスペースが入っていることを検出するようにした、というものになっている。

個人的に結構意外だったのはRedHat Enterprise LinuxとCentOSの判定ルーチンが独立しているという点。

1if (strstr(distroLower, "red hat")) {
2   if (strstr(distroLower, "enterprise")) {
3 
4      /*
5       * Looking for "release x" here instead of "x" as there could be
6       * build version which can be misleading. For example Red Hat
7       * Enterprise Linux ES release 4 (Nahant Update 3)
8       */
9 
10      int release = 0;
11      char *releaseStart = strstr(distroLower, "release");
12 
13      if (releaseStart != NULL) {
14         sscanf(releaseStart, "release %d", &release);
15         if (release > 0) {
16            snprintf(distroShort, distroShortSize, STR_OS_RED_HAT_EN"%d",
17                     release);
18         }
19      }
20 
21      if (release <= 0) {
22         Str_Strcpy(distroShort, STR_OS_RED_HAT_EN, distroShortSize);
23      }
24 
25   } else {
26      Str_Strcpy(distroShort, STR_OS_RED_HAT, distroShortSize);
27   }
28}
1} else if (StrUtil_StartsWith(distroLower, "centos")) {
2   if (strstr(distroLower, " 6.")) {
3      Str_Strcpy(distroShort, STR_OS_CENTOS6, distroShortSize);
4   } else if (strstr(distroLower, " 7.")) {
5      Str_Strcpy(distroShort, STR_OS_CENTOS7, distroShortSize);
6   } else if (strstr(distroLower, " 8.")) {
7      Str_Strcpy(distroShort, STR_OS_CENTOS8, distroShortSize);
8   } else {
9      Str_Strcpy(distroShort, STR_OS_CENTOS, distroShortSize);
10   }
11}

そして、Oracle LinuxはCentOSと同様の記載になっているという点。

1} else if (StrUtil_StartsWith(distroLower, "enterprise linux") ||
2           StrUtil_StartsWith(distroLower, "oracle")) {
3   /*
4    * [root@localhost ~]# lsb_release -sd
5    * "Enterprise Linux Enterprise Linux Server release 5.4 (Carthage)"
6    *
7    * Not sure why they didn't brand their releases as "Oracle Enterprise
8    * Linux". Oh well. It's fixed in 6.0, though.
9    */
10   if (strstr(distroLower, "6.")) {
11      Str_Strcpy(distroShort, STR_OS_ORACLE6, distroShortSize);
12   } else if (strstr(distroLower, "7.")) {
13      Str_Strcpy(distroShort, STR_OS_ORACLE7, distroShortSize);
14   } else if (strstr(distroLower, "8.")) {
15      Str_Strcpy(distroShort, STR_OS_ORACLE8, distroShortSize);
16   } else {
17      Str_Strcpy(distroShort, STR_OS_ORACLE, distroShortSize);
18   }
19}

Oracle Linux 7の /etc/oracle-release の表記はどういう風になってるんだろうかな・・・

vSphere上にRHEL8を日本語でインストールしようとするとインストーラがちゃんと表示されない

vSphere 6.0環境でRHEL8をインストールしようと、日本語インタフェースで進めようとしたら、「インストール概要」の画面以降、仮想コンソールからはみ出た範囲まで使われるようになってしまう。

対処方法を捜索・・・vSphere側の「svga.height」「svga.width」指定ではうまくいかなかったので、Anaconda側のパラメータを「Anaconda Boot Options一覧」から探したところ「inst.resolution」を発見。

起動時のカーネルオプションに対して「inst.resolution=1024×768」を追加することで、下記の様に全てを表示させることに成功した。

StatCounter - Free Web Tracker and Counter