CIFSマウント時の SMB バージョンのデフォルトが 1.0 ではなくなった

CentOS7 NAS

【環境】
CentOS Linux release 7.6.1810 (Core)
kernel-3.10.0-957.1.3.el7.x86_64
util-linux-2.23.2-59.el7.x86_64


CentOS 7.5 → 7.6 へ更新したら、CentOS からNASをCIFSマウントできなくなった。

/var/log/messages へ次のようなエラーが出力される。

Dec  8 08:22:16 host_name kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.

バージョンが上がった事で、SMB接続する際のデフォルトバージョンが1.0→2.1 になったらしい。

どのパッケージが影響したか分からない。
　・カーネル（cifs.ko.xz？）
　・util-linux（mountコマンドが入っている）
あたり？


SMB1.0で接続したければ、マウント時に vers=1.0 オプションを指定しろとの事。

autofs でマウントする場合も同様に、このオプションの指定がなければマウントエラーになる。

マウントするNASが古いなどで、SMB 1.0にしか対応していない場合は、このオプションが必要。

手元のNAS（Linuxベース）も古いので、「ついに使えなくなったか！？」と一瞬焦った。

光コラボらしき勧誘が来て困る

インターネット

ネットにも多くの情報があるのですが、我が家にも光コラボと思われる勧誘の電話がありました。

せっかくなのでメモ。

「」：会話
（）：心の声


相手「NTTフレッツ光の料金の件でご案内の御電話となります」

私「えっ？は、はい？」

相手「来月以降もNTTフレッツ光りをご利用の場合、来月から料金が安くなります」

私「そうなんですかー」

相手の社名を聞き逃したかと思って、

私「NTTさんでしょうか？ハガキなどで以前にもご案内頂いていましたか？」

相手「NTTから委託されています、○○サポートと申します。今回はお電話での案内となります」

続けて、

相手「今は6000円～7000円くらいの月額かと思われますが、これがもっと安くなります」

私「ご案内頂いているものは、ホームページでも確認できますか？」

相手「いいえ、このお電話でのご案内となります。フレッツ光をご利用の方に特別のご案内をしております」

私（！？怪しい・・・）

私「は、はぁ」

相手「NTTフレッツ光りのホームページから、転用承諾番号をご確認頂くと、すぐに手続きが可能となります」

私「この部屋にはパソコンがありませんので、確認できないのですが・・・」

相手「それでは、お部屋をご移動頂いて、5分後くらいにもう一度お電話いたします」

私「すみません。パソコンはデスクトップで移動できませんし、この固定電話は、有線なので移動できません」

相手「それでは携帯電話を教えて頂ければ、そちらへお掛けしますが」

私「携帯電話番号を教えるのはちょっと・・・。こちらから掛け直す電話番号はありますか？」

相手「ございません。発信専用の電話となっております」

私（相手も情報を出さないなぁ・・・）

私「料金は今のもので不満はありませんし、他社へ変更するつもりはありません。すみませんが、お断りいたします」


といった感じでした。


この手の勧誘電話は、総務省からも注意が出ています。

光コラボレーションモデル 不適切な電話勧誘にご注意ください！ - 総務省
http://www.soumu.go.jp/main_content/000388714.pdf


何度か同じような電話を受けているのですが、今はもう面倒なので、「光コラボの勧誘ですか？不要ですので」と言って終わります。

いつも思うのは、以下の点。

  • 相手の社名を聞きとれない（もしくは最初に名乗らない）
  • やたら使われる「NTT」という名前に意識が行ってしまう（NTTからの電話に思ってしまう人がいるかもしれない）
  • どうにかして転用承諾番号を確認、取得させようとする（NTTからの電話だと思った人は、教えてしまいそう）
  • ホームページや問い合わせ先の情報を要求しても、教えてくれない


ADSLだった頃、「光へ移行しませんか」という電話が多く掛って来た時期がありました。

光を使っていると、今度は「コラボへ移行しませんか？」な勧誘が来るのです。

光コラボそのものや自社のサービスの案内をせず、とりあえず転用承諾番号を確認、取得させようとするところも不審な訳ですが、

そもそも「フレッツ光を使っているという事を知って勧誘電話してくる」のが嫌で、

こういうの何とかならないのかなぁと思った次第でした。


で、調べてみると・・・NTT東西にて、勧誘停止登録受付窓口なるものがあるらしい。

www.ntt-east.co.jp

www.ntt-west.co.jp


読んでみると、

勧誘を停止するにあたり、停止登録頂いた電話番号及び住所・氏名等お客さま情報を弊社代理店等へ提供いたしますので、予めご了承願います。

えーーーーー、でも停止するための情報を伝えるとなると、そうなるか・・・。

これの効果がどれほどか分かりませんが、もう暫し様子を見たり調べたりして考えよう。


と、光コラボそのものが悪いと言っている訳ではありません。

ユーザによっては、プロバイダやdocomoなどの光コラボがマッチするケースもあり、サービスそのものが悪い訳ではありません。

得体の知れない変な勧誘が悪いのです。



最後に、光コラボらしき勧誘には気をつけましょう。

もし、同居していない実家に勧誘電話がかかってきたら、両親が契約してしまうかもしれません。

気をつけましょう。

VMware vCenter Converter Standalone 5.5.3 のダウンロード

VMware

止められない古い仮想マシンがあり、そのパーティションサイズを変更したかったが、Converter 6.x では出来なかった。

古いバージョン（5.5）を使おうと思ったものの、公式サイトでリンクを辿っても、6.x へリダイレクトされてしまい、ダウンロードリンクが見つけられなかった。


色々探していたら、コミュニティで直リンクを見かけた。
communities.vmware.com



以下は、2018/11/5時点では有効なダウンロードリンクだが、いつか消えると思われる。
ダウンロード先は公式サイトのURLだけど、サイト検索しても辿り着けないので直リンクを。

ダウンロードには、VMwareアカウントが必要。


同じ境遇の人がいるかもしれないので、メモ。


【2022/8/24追記】
Converter はダウンロードを停止しています。以下の記事に書きました。
shobon.hatenablog.com

無線中継器をPLCアダプタ（TP-LINK TL-WPA4220 KIT）へ置き換えた話

ネットワーク セキュリティ

家のネットワークには、

  • 1階にONU（無線なし、ルータ）と無線ルータ
  • 2階に無線ルータ

があった。

モバイルはWifi接続で良いが、2階にあるデスクトップPCやNAS、プリンタは有線が必要で、どうにかして1階と2階のネットワークを繋ぐ必要があり、無線中継器を使っていた。

無線ルータは、2台とも NEC Aterm WR8165N。構成は以下のような感じ。

f:id:savakan:20181107144520p:plain

WR8165N は、コンパクトで軽く、設置するには非常に優秀な無線ルータだった。
ただ、時々ネットワークに接続できない事があった。

はっきりした原因は追究できなかったが、以下が、類似例。とても参考になった。
d.hatena.ne.jp

私の環境の場合、有線接続したデスクトップPCでもWifiでも接続出来ない現象が発生した。
DHCPがダメなのかと思い、試しにデスクトップのIPを固定IPに設定してもダメだった。
無線の電波は良好で、Androidアプリのアナライザで調べた限りは、周辺と競合している感じもしない。

PCの場合は、切断されるとブラウザが応答しなくなる等で気が付くが、スマホの場合は自動的にキャリア回線に切り替わり、気付きにくい。
その間にギガを食っていくので、これはマズイと思った。


この機種の前は、BUFFALOの無線ルータで中継器を構成していたが、片方のルータのACアダプタが故障してしまい、代用を探せなかったためWR8165Nを2台購入した過去がある。
shobon.hatenablog.com


別な中継器にするか、PLCにするか悩んだが、また中継器で失敗するのも怖いのでPLCを購入する事にした。

PLCアダプタを探すと・・・

という事で、TP-Link にした。


TP-LinkのPLCアダプタは、Wifi機能を持たない製品（TL-PA4010 KIT）とWifi機能を持つ製品（TL-WPA4220）がある。

私の場合、1階と2階をPLCで接続して2階から既存のWifiルータで無線を飛ばしても、1階ではその電波が弱くなるようだった。

このTP-Linkの機種は、片方が無線機能を提供できるので、その点では良い仕様だった。

1階から2階へPLCで有線を引くと同時に、1階ではPLCアダプタからWifiの電波を飛ばせる。

価格・機能的には良いのだけど、これが国産だったら良かったなぁ（´・ω・｀）


楽天のTP-Linkから購入。

私が購入したのは、2018年の9月。
価格は、7,072円（税込）だったが、クーポン300円を適用して6,772円で購入。


製品が届いたら、開封の儀。 f:id:savakan:20181107141530j:plain 筐体は小さいが、Wifi機能を持った方は少し大きい。 f:id:savakan:20181107141525j:plain コンセントに他の機器を挿していると、邪魔になるかもしれない。 f:id:savakan:20181008114243j:plain LANケーブルが付属してきたけど、Cat5 だった。使わない。
さっそく設置して配線。ネットワーク構成は以下のようになった。
f:id:savakan:20181107201343p:plain
PLCで問題として取り上げられる速度の測定。
USENのサイトで、2階のPCから以下の3パターンを測定した。

  • 無線中継器の構成（WR8165N）：35Mbps
  • PLC（2階だけACタップにPLCアダプタを配線）：35Mbps
  • PLC（2階もPLCアダプタをコンセントに直結）：50Mbps


やはり、ACタップを経由すると速度は落ちるらしい。

以前より早くなったので良し。

1ヶ月くらい使ったが、以前の構成の時のようにネットから切断されなくなったので、目的は達成したかな・・・。

Windows 10でNFSクライアントを有効にするとSambaの応答が悪くなる謎

CentOS6 CentOS7 Samba Windows

【環境】
クライアント：Windows 10 1803
サーバ：CentOS 6/7 の標準リポジトリのSambaで構築した共有フォルダ


コンパネからWindowsの機能として、NFSクライアントを有効にしたところ、Sambaの共有フォルダの応答が悪くなった。

ちょっとテストでWindowsクライアントが必要になり、Windowsの機能から有効にした時に気が付いた。


症状としては・・・

  • NFSクライアントを有効にしただけ（マウントしていない状態）で発生する。
  • ファイルをクライアント→Sambaの共有フォルダへコピーすると、99%のところで停止し、Windowsのエクスプローラーが応答しなくなる。
  • 共有フォルダ上のファイルを右クリックしてプロパティを出そうとすると、出ない。Windowsのエクスプローラーが応答しなくなる。
  • Samba側のログにエラーなどは出ていない

なお、

  • 同じクライアント～サーバ間で、FTP/SFTPでやり取りする分には、問題ない。
  • WindowsでNFSクライアントを無効にしてWindowsを再起動すると、問題は起こらなくなる。

なので、WindowsのNFSクライアントが原因と思っているけど、調査に難航しそう。

相性の問題？

freshclam コマンドが「Can't create new socket」を出す

CentOS6 CentOS7 セキュリティ

環境

CentOS 6.x/7.x
clamav-0.99.4-1.el6.x86_64 ~ clamav-0.100.0-1.el6.x86_64
clamav-0.99.4-1.el7.x86_64 ~ clamav-0.100.0-2.el7.x86_64

2018年の5月下旬頃からか、以下のエラーが出るようになった。

/etc/cron.daily/freshclam:

ERROR: Can't create new socket: Address family not supported by protocol

cronで定期実行されているclamavのシグネチャの更新時に、何やらエラーが出ているようだった。

エラーメッセージを見る限り、IPv4/IPv6関係か（？）と思い、
/etc/freshclam.conf　の設定を見ると、

　DatabaseMirror

の設定値はIPv4のものだけになっていて、IPv6向けの設定はコメントされている。
OS側のネットワーク設定でも、IPv6を無効化しているので、問題ないように思えた。

ClamAVのMailing List Archiveにも、同様の問題が投稿されていて、以下が最後に確認したものだった。
https://lists.gt.net/clamav/users/73099

リプライが途中で終わっていた。

暫くして、ClamAVのMailing List Archive を見たら、
https://lists.gt.net/clamav/users/73229

The error you're referring to has been fixed in 0.100.1. Unfortunately,
unless you enable ipv6 for your computer/network, you'll have to live
with the error until you're able to upgrade to 0.100.1.

とあった。

このバージョンがyumのリポジトリに来るのを待っていたら、7/25 にyum updateしたところ更新された。

更新後のバージョンは、以下の通り。

clamav-0.100.1-1.el6.x86_64
clamav-0.100.1-1.el7.x86_64

このバージョンに更新後、freshclam で同様のエラーが出なくなった。

OpenLDAP の同期（レプリケーション）で refreshOnly を指定するとエラーになる

CentOS7 OpenLDAP

OpenLDAP の同期（レプリケーション）で refreshOnly を指定するとエラーになる

環境（プロバイダ、コンシューマ同じ）

$ cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

$ rpm -qa | grep -i openldap
openldap-servers-2.4.44-15.el7_5.x86_64
openldap-2.4.44-15.el7_5.x86_64
openldap-clients-2.4.44-15.el7_5.x86_64


設定（プロバイダ）

overlay                   syncprov
syncprov-sessionlog       100
index entryCSN,entryUUID  eq


設定（コンシューマ）

syncrepl
 rid=11
 type=refreshOnly
 interval=00:00:05:00
 provider=ldap://192.168.1.11
 bindmethod=simple
 binddn="cn=Manager,dc=master,dc=ldap,dc=local"
 credentials=******
 searchbase="dc=master,dc=ldap,dc=local"
 filter=(objectClass=*)
 scope=sub

※設定は、プロバイダ/コンシューマどちらも、Configuration Backend を使わず従来のテキスト形式で設定している。


ログを確認するため、SLAPD_OPTIONS に "-s 16640" を追加してサービスを起動。

syslogに出力されたログを確認すると、次のようなエラーが出て、同期しない。

slapd[1661]: slapd starting
slapd[1661]: do_syncrep2: rid=011 LDAP_RES_SEARCH_RESULT
slapd[1661]: do_syncrep2: rid=011 cookie=rid=011,csn=20180701054359Z#000000#00#000000
slapd[1661]: slap_queue_csn: queueing 0x7fa68010a010 20180701054359.000000Z#000000#000#000000
slapd[1661]: slap_graduate_commit_csn: removing 0x7fa68010a010 20180701054359.000000Z#000000#000#000000
slapd[1661]: syncrepl_updateCookie: rid=011 be_modify failed (32)


以下、試したこと。

  • コンシューマから、ldapsearchコマンドでは、データを検索できる。

　→FWの設定やLDAPのアクセス権は大丈夫そう。

  • このコンシューマから、同じ設定のまま、CentOS 5.x で構築した同じ設定のプロバイダに接続すると、データは同期する。

　→コンシューマの設定に問題は無さそう？

  • プロバイダ側に問題があるのかと思い、プロバイダ側のモジュール不足の懸念を払拭するため、全てのモジュールをロード

　→変化はない。

  • コンシューマ側にて、type を refreshOnly → refreshAndPersist へ変更

　→エラー無く同期できる。

  • syncrepl_updateCookie をキーワードにして検索

　→類似例は出て来ない。（2018/7/15時点）


とりあえずの結論としては、おそらくプロバイダ/コンシューマが、いずれも openldap-2.4.x の場合だけに発生する問題と思われる。

設定が悪いのか、真っ当な対応が分からないので、同期モードを refreshAndPersist で運用できるなら、refreshAndPersist で運用すれば回避はできる。

引き続き調査して、何か分かったら追記するつもり。