https万歳!と言いたくなるのも分からなくは無いけど、非暗号化通信も良いことはある。
たとえば検索ログが残る。
これによって、非対称のコミュニケーションが成立するのである。
以下が検索結果に対する答え。
large mtu をwindows 10で有効化する
windows8~は既定で有効になっている。
thunderbird メールボックス 4gb
メールボックスをzipで管理しているので、Thunderbirdには4GBの壁がある(zipの仕様で圧縮前のファイルサイズが4GBを超えると破損する)。
回避するには、そもそもメールボックス1つあたりの容量を4GB以下に調整する(一つのボックスに貯めない)か、
64bit版にして、メールボックスの形式をmboxからmaildir形式にする(未検証。検索バグがあるかも)。
unable to connect to cups server localhost:631 - connection refused
http://roserogue.blogspot.com/2008/08/unable-to-connect-to-cups-server.html
参照のこと。
dhcpは何台接続可能なのか
IPアドレスのアドレスクラスをクラスAにすれば、理論上は16777214台にIPアドレスを振り出すことが出来る。あとはdhcpサーバの物理性能次第。
但し、思った以上にパワーは使わないので、エントリーマシンでもNICの数があれば十分捌ける。
wireshark 2 6 0インターフェース認識しない
pcap(npcap)がバックグラウンドで立ち上がっていない可能性を疑う。
2019年9月4日水曜日
2017年7月1日土曜日
別環境にファイルサーバを据えたら認証で待たされる(遅くなった)。サーバが参照するdnsサーバを疑え
念願のclassB環境にネットワークを移行させたのは良いものの、結局トラブった。
classC環境(いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間(数十秒)待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。
結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。
まず疑ったのが、クライアントPCのルーティング。
「クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを2つ(BとC)持たせていたので、別に不自然だとは思わなかった。
次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い。
google先生に
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係(DNS)がらみなのではと疑い出す。
ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に(移行中だったからだけど)NICの設定ファイル(ifcfg-foobar)にも書いていた。
ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル(/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。
前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので
後者も同じように、nameserver=でいくつでも登録出来るので、使う(使える)DNSサーバだけにする。
これで問題なくなった。
以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。
自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html
sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html
classC環境(いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間(数十秒)待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。
結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。
まず疑ったのが、クライアントPCのルーティング。
「クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを2つ(BとC)持たせていたので、別に不自然だとは思わなかった。
次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い。
google先生に
「iptables "-L" ローカルIPアドレス 遅い 表示」で聞いてみると、どうやら名前を逆引き出来ないから、という結論に。
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係(DNS)がらみなのではと疑い出す。
ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に(移行中だったからだけど)NICの設定ファイル(ifcfg-foobar)にも書いていた。
ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル(/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。
前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、
vi /etc/sysconfig/network-scripts/ifcfg-eth1で、正しいDNSサーバのIPアドレスを指定する。たとえば
DNS=192.168.0.1と記述してやる。
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので
DNS1=192.168.XXX.XXXのように登録して、DNS1は既に取り外していたこと。
DNS2=172.16.YYY.YYY
後者も同じように、nameserver=でいくつでも登録出来るので、使う(使える)DNSサーバだけにする。
これで問題なくなった。
以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。
自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html
sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html
2017年6月20日火曜日
DHCPサーバを立てたくてraspberry piを買う。そして御作法に泣かされる
ラズベリーパイ、それは苦行・・・。
基本的にサーバは仮想化せず、全て別サーバとして立てている。仮想化したり統合することのメリットはよく分かっているのだけれども、パフォーマンス分析やら不具合やらに付き合うとろくでもなかった経験がある。
よっていつも通り別サーバを組んでいこうと思ったのだけれども、予算が無い。
なので今流行の(いや遅い・・・)ラズベリーパイで組んでみようと思い立った。
DHCPサーバは、基本設定を流し込めば終了なので、なんとでもなるだろうと思っていたのが運の尽き。
前提として、僕が付き合ってきたのはcentosである(≒RHEL)。
なので、centosの「御作法」は分かっているつもりである。が、Rasberryはdebian(Rasbianなら)である。御作法が違う。
ログインユーザが「pi」
・・・このユーザは何なのだ。
あと、キー配列が英。コンフィギュレーションを出して編集。
おかしいだろ・・。
気を取り直して少し弄る。
sudoは通る。ただ、ログアウトしてpiで入ろうとするとパスワードが分からない。
・・・とりあえず、rootパスワードを設定する。
sudo passwd rootその次に、得体の知れないpiから離れるために、自分のユーザを作る。
useradd foobarよく分からない住所やらが求められるが、気にせずエンターで済ませる。
ここではまったのが、なんとsudoerでなければGUIログイン出来ない・・・。
sudoerに追加する。
sudo gpasswd -a foobar sudoで、piを消す。
sudo userdel -rf pi
次にネットワークだ。
NICに一意の固定IPを持たせるために、/etc/network-scr...と探そうとすると、無い。ググると/etc/network/interfacesがネットワーク情報とのこと。
ううむ・・・とりあえず編集する。
sudo vi /etc/network/interfacesここで驚愕の事実。
ラズパイのviは、viだった・・・。
使い慣れているのはvimである。もう泣きたい。
カーソルの動かし方だけなんとなく思い出して必死に編集。
HJKLでキー移動。カーソルはそれぞれ←↓↑→に対応。
注:192.168.xxx.1はゲートウェイサーバ
eth0のところを
iface eth0 inet static
address 192.168.xxx.xxx
netmask 255.255.255.0
gateway 192.168.xxx.1
とするが、繋がらない。
ifconfigでeth0を見ると、169.254...が出る。
本当に泣きたい。
更にググると、dhcpcd.confに書き込めとのこと。
http://qiita.com/MarieKawasuji/items/b088ffb252a92eee8f5d
・・・どういうことかさっぱり分からない・・・自分自身にDHCP機能を使っているということ?
と思っていたら、dhcp「c」d.confだった。
・・・もう何も気にせず書くことにする。
sudo vi /etc/dhcpcd.confinterface eth0
static ip_address=192.168.xxx.xxx/24
static routers=192.168.xxx.1
static domain_name_servers=192.168.xxx.1
・・・繋がった・・・。
sudo apt-get update更に、digを入れたいが無いと言われる。
sudo apt-get upgrade
ググると
http://d.hatena.ne.jp/rx7/20080306/p1
dnsutilか・・・。
sudo apt-get install dnsutilsvimも入れる。
sudo apt-get install vim
・・・次。DHCPサーバ。
sudo apt-get install isc-dhcp-servercentosもそうだけど、linuxは少しはパッケージ名とか気を遣ってほしい。
これが入ってるパッケージはこれ!みたいなのがさっぱり分からない。
vim /etc/dhcp/dhcpd.confddns-update-style interim;
#クラスBで立てるので、IPアドレスは172.16.X.X。
subnet 172.16.16.0 netmask 255.255.254.0 {
option routers 172.16.16.1;
option subnet-mask 255.255.254.0;
option domain-name "ufotable.net.local";
option domain-name-servers 172.16.16.1;
option time-offset -18000; # Eastern Standard Time
default-lease-time 65530;
max-lease-time 65535;
}#EOS
host insert_client_name {
hardware ethernet HO:ST:MA:CA:DD:RE;#SS
fixed-address 172.16.16.XXX;
}
}#EOT
やっと書けたが、次はサービス追加が分からない。弄っているとsystemdな事が判明するが、dhcpdを立ち上げようとし続けてはまる。
そう、isc-dhcp-server(名前が違うんだ・・・)。
sudo systemctl start isc-dhcp-serverエラーで止まる。
ううむ・・・。
http://www.mugbot.com/2016/08/21/raspberry-pi%E3%81%ABisc-dhcp-server%E3%82%92%E8%A8%AD%E7%BD%AE%E3%80%81%E8%87%AA%E5%8B%95%E8%B5%B7%E5%8B%95%E3%81%95%E3%81%9B%E3%82%8B/
/etc/default/isc-dhcp-serverの編集
・・・はあ?
もう本当によく分からない。
INTERFACES=""・・・。
の””の中にeth0を挿入
sudo vim /etc/default/isc-dhcp-serverでINTERFACEにeth0を指定。
クラスCで指定した固定IPアドレスは、走らせる前にクラスBに指定し直さないと走らないので注意。
しかもその時、interfacesも弄らなきゃいけなくて、全く直感的じゃないし面倒なだけという・・・。
とりあえず諸々で、再度sudo systemctl start isc-dhcp-serverで走った。
自動化は
sudo systemctl enable isc-dhcp-server
御作法、恐るべし・・・。
個人的にはデスクトップ用途でしかdebian≒ubuntu≒mintを弄っていなかったので、良い勉強になった。嘘です。もうCUIで正直弄りたくありません・・・。
慣れって大事。本当に・・・。
登録:
投稿 (Atom)