エレクトリック・ボディ・ビート: 7月 2017

2017年7月10日月曜日

Proselfを弄ってみた。

Proselfを弄ってみた。
詳しいことは書かないけど、弄る機会がありまして。
UIは、なんというか、owncloudチック、というか丸パクリ感。
使いやすいUIをまんまパクるそのスタイル、嫌いじゃ無いです。
ver.4はまだ昔のストレージ感あるのにね。
機能面では、痒いところに手が届く感じはしました。gigaccとは大違い。
なんというか、Proselfは、ユーザフレンドリーなのに対して、gigaccは大上段に構えてる感じ。
詳しく弄ってない前提で、印象だけ語ると、色んな意味でがちがちなのはgigacc。組織ベース。上長確認システムとか旧態歴然とした組織にはがっつりはまります。でも融通は利かない。
Proselfは、ファイル主体。組織システムにがっちり合わせるというよりも、個人とグループというまとまりで管理するから、昔のはんこ回しとかはやらないよ、という。
FAQにもそれは現れていて、きめ細かいFAQが載っているのがProselfの方だったり。

FAQの話ついでに。
SSLプロキシを設定してから分かってきたことは、XSS対策としてリファラの参照を用いることが多いようなこと。
詳しく見てないけど、恐らくadobeもgoogleも画面遷移させる上でやってる。
Proselfもそうで、
https://www.proself.jp/support/faq341/
https://www.proself.jp/support/faq335/
とのこと。うちは勿論リファラ全切りなので（ブラウザは偽装だし）、勿論引っかかる。
ただ、リファラの偽装は昔からの手段で、携帯サイトを覗きたかったり、ブラウザ指定を回避する際にも弄る場所（だよね？）
XSS対策で入れるのは分かるけど、コントロールしたい人や企業は相当苦労しそう。
だからProselfは外せるようにしているんだろうし。

2017年7月6日木曜日

ntpを設定するのと、squidプロキシを噛ませてyum出来るようにする

最近ファイルスタンプのずれが気になるという声が「やっと」聞けたので、ntpを設定していこうと思い立った。
もののついでに、SSLプロキシがはまったせいで、yumさえ出来なかったサーバプロキシの設定をしてyum出来るようにする。

まずゲートウェイサーバをNTPサーバにする。と言っても、外部NTPサーバと同期させるというだけである。
詳しいNTPについては
http://tech.ckme.co.jp/ntp.shtml

環境はcentos5~7、192.168.168.1がプロキシ兼NTPサーバとする。

yum install ntp

設定ファイルを編集

vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

あと同ファイルで

server ntp.nict.jp#<<公開NTPサービス
server ntp1.jst.mfeed.ad.jp#<<公開NTPサービスに同期している会社の公開NTP
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server 契約しているISPのNTPサービス
#server 0.centos.pool.ntp.org iburst#デフォルトのはコメントアウトして負荷を減らす
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

これで設定終了。

ntpdate ntp.nict.jp

で手動同期。

systemctl start ntpd
systemctl enable ntpd

で自動起動させる。

iptablesでFW機能をさせているので、iptablesにローカルから自機へのNTP問い合わせ許可設定をする
iptables -I INPUT -p udp --dport 123 -s $trusthost -d $mylanip -j ACCEPT
*$trusthostはローカルIP群、たとえば192.168.168.0/24、$mylanipは、LAN側のIP（この場合は192.168.168.1）。厳密にしないなら-sと-dは無くても良い。

次に、クライアント側設定。
プロキシを通すので、yumの設定ファイルにプロキシを追加

vi /etc/yum.conf

で

#proxy=http://PROXY-SERVER.ADDRESS:port
proxy=http://192.168.168.1:8080

プロキシの噛ませ方は、以下のページが詳しい
http://fj.hatenablog.jp/entry/2014/08/20/204554

で、サーバと同じようにyumでNTPを入れる

yum install ntp

~~設定ファイルを編集~~

~~vi /etc/ntp.conf~~
~~#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集~~
~~restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap~~

~~更に、サーバはnictを登録したけど、クライアントはnictを参照させず、NTPサーバを参照させるので~~

~~server 192.168.168.1~~

~~とする。~~

~~ntpdate 192.168.168.1~~

~~で手動同期。~~

~~systemctl start ntpd~~
~~systemctl enable ntpd~~

~~で自動起動させる。~~

追記
上記でも良いけど、設定しながら「これってntpdateをcronで動かした方がリソース消費しなくね？」という事実に気付き、上記の設定ファイルの編集をせず、たとえば
vi /etc/cron.daily/ntpdate_update.sh
とかで新規ファイルを作って
#!/bin/sh
ntpdate 192.168.168.1
で保存し、
chmod +x ntpdate_update.sh
で実行権限付けて、デーモンは動かさないことにした。クライアントなんだから走らせ続ける意味はないわな。
まあ別に走らせても良いと言えばいいわけで（どうせローカル参照だし）、取り消し線で済ませておくことにする。

手動あわせしようとした際に出る「the NTP socket is in use, exiting」というエラーメッセージは、読んで字のごとく、「NTPソケットはもう使ってるから！」と言われている。
おとなしく
systemctl stop ntpd
なり
service ntpd stopなりでNTPを止めてから再度実行して下さい。

備忘録
オレオレ証明書等ルート証明書をlinuxに読ませる場合
centos7
https://cloudpack.media/14148

/usr/share/pki/ca-trust-source/anchors

に証明書をコピーして

update-ca-trust extract

を実行

centos5~6
https://wp.kaz.bz/tech/2013/05/02/1651.html

/etc/pki/tls/certs/にコピーか、
/etc/pki/tls/certs/ca-bundle.crtに追記する。

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アドレスを２つ（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
DNS2=172.16.YYY.YYY

のように登録して、DNS1は既に取り外していたこと。

後者も同じように、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

登録: 投稿 (Atom)