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

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

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


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



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

https://my.vmware.com/group/vmware/get-download?downloadGroup=CONV553_GA

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


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

無線中継器を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の応答が悪くなる謎

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


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

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


症状としては・・・

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

なお、

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

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

相性の問題?

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

環境

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 を指定するとエラーになる

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 で運用すれば回避はできる。

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

yum で古いパッケージをインストールする方法

何らかの理由で、古いパッケージをインストールしたい時のためのメモ。

yum で利用可能な古いパッケージを探すには、--showduplicates オプションを付加して検索する。

利用可能なパッケージは、RHELCentOSでは、動作が異なるらしい。
 RHEL :過去のバージョン全てを利用可能(たぶん、全てと思われる)
 CentOS:過去のバージョンの一部


RHEL 6.10の例

$ yum search --showduplicates nmap
・・・略
2:nmap-5.21-3.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.21-4.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-2.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-3.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-4.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-6.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-6.el6.x86_64 : Network exploration tool and security scanner


CentOS 6.10の例

$ yum search --showduplicates nmap
・・・略
2:nmap-frontend-5.51-6.el6.noarch : The GTK+ front end for nmap
2:nmap-5.51-6.el6.x86_64 : Network exploration tool and security scanner
2:nmap-5.51-6.el6.x86_64 : Network exploration tool and security scanner


CentOSの場合、パッケージによって利用可能なバージョンの数が異なる模様。

$ yum search --showduplicates firefox
・・・略
firefox-52.8.0-1.el6.centos.i686 : Mozilla Firefox Web browser
firefox-52.8.0-1.el6.centos.x86_64 : Mozilla Firefox Web browser
firefox-60.1.0-5.el6.centos.i686 : Mozilla Firefox Web browser
firefox-60.1.0-5.el6.centos.x86_64 : Mozilla Firefox Web browser
firefox-60.1.0-6.el6.centos.i686 : Mozilla Firefox Web browser
firefox-60.1.0-6.el6.centos.x86_64 : Mozilla Firefox Web browser
firefox-60.1.0-6.el6.centos.x86_64 : Mozilla Firefox Web browser


インストールの際は、パッケージ名のみでなく、バージョンまで含めて指定するとインストールできる。

# yum install firefox-52.8.0-1.el6.centos.x86_64

tcpdump でNSDのクエリログを取る

【環境】
CentOS 7.5
nsd-4.1.20-1.el7.x86_64


NSDDNSサーバ)だと、標準の機能ではクエリログを取得できない。
nsd-4.1.20 の時点では)

権威サーバでクエリログが必要なニーズが無いのかもしれないが、どれだけのクエリがあるのか調べたかったので、ログを取る方法を考えた。

で、思い付いたのが tcpdump でログを取ること。

#!/bin/bash

NIC="ens160"
DST_IP="192.168.1.20"
DST_PORT="53"
LOG_FILE="/var/log/nsd-query/query.log"
ROTATE_SIZE=10485760
REMOVE_RANGE=129600

# check log rotate
if [ ${ROTATE_SIZE} -lt $(ls -l ${LOG_FILE} | awk '{print $5}') ] ; then
  pkill -9 tcpdump
  mv ${LOG_FILE} ${LOG_FILE}"-"$(date "+%Y%m%d-%H%M%S")
fi

# remove old files
find $(dirname ${LOG_FILE}) -type f -name $(basename ${LOG_FILE})"*" -mmin +${REMOVE_RANGE} -delete

# start logger
if [ $(ps aux | grep tcpdump | grep -v 'grep' -c) -lt 1 ] ; then
  /usr/sbin/tcpdump -p -l -nn -tttt -i ${NIC} dst host ${DST_IP} and dst port ${DST_PORT} >> ${LOG_FILE} &
fi

このスクリプトは、以下のような動作を行う。

  • キャプチャするNIC、そのNICのIP、ポート番号を指定
  • クエリログの出力先を指定
  • クエリログをローテーションするファイルサイズ(バイト)の閾値を指定
  • 古いクエリログファイルを削除するための閾値(秒)を指定
  • クエリログのファイルのサイズが設定値を超えた場合、tcpdump プロセスをkill してログファイルをリネームしてmv
  • 指定秒より古いクエリログファイルがあれば削除
  • ps コマンドでtcpdump プロセスが見つからない場合だけ(重複起動をチェック)、ログ取得のためのtcpdump を実行

これを cron などで定期時刻すれば、重複実行を避けつつクエリログを取得し、ログファイルのローテーションを行う。
テキストファイルなので、cat(圧縮したものはzcat)で開き、適当な条件で grep する。


ログファイルのローテーションと言えば、logrotate が手軽だが、tcpdump をローテーションしようとすると、anacron がゾンビのように残ってしまい、うまくローテーションされなかった。

tcpdump にも、出力ファイルをローテーションするオプション(-G)があるが、tcpdump -w で生データを書き出す場合、-r オプションでしか読めず、gzip圧縮して出力場合は直接読み込めない。

圧縮して出力すると、いったん非圧縮ファイルへ書きだす必要があり、圧縮するのを止めようか迷ったが、容量圧迫のプレッシャーに勝てず断念。

また、tcpdump のローテーションでは、古いファイルを削除する仕組みが無い。

これらをうまく解決できず、シェルスクリプト側で無理やりローテーションするようにした。