技術

2017年05月10日

ちょいはまり。
iptables もOKです。ポートもLISTENしていました。しかしログインできないのです。

接続は受け付けているように見えるので、ファイアーウォール系では無いように思えました。
で、結論。

/etc/hosts.deny でした。
sshd:ALL という記載が。

とりあえず自分のIPを解除しました。



stock_value at 20:31|この記事のURLComments(0)

2017年05月09日

そこそこな規模でのトラブルについてコメントを求められました。
仕事で収益が発生しないというのがつらいところですね。


僕はある種炎上している現場でコメントを求められました。そのため、みなさんと僕の気持ちは若干異なっているように感じました。

状況として、数百台のクライアント端末を既存の環境に無線APとともに導入。既存環境へのアクセスを確保するために、そのままの状態で追加した。
ということでした。

既存で何台の端末が展開されていたのかはわかりません。しかし数百台の端末を既存環境に追加するのは、そうとうなリスクを伴います。そもそもおそらく一般的と思える /24 の環境では 255 台までしか配置できません。既存の環境を /23 に変更するなどというのは、おそろしすぎます。既存のネットワークを熟知していなければ難しいでしょうし、もしくはよほど小規模でないと現実的だとは思えません。

すでに様々な業者があつまって議論をしていました。そのときまでに出ていた結論としては、DHCPのレンジを増やすということでした。現在のDHCPでは、64台ぐらいのIPアドレスしか配布していないので、これを255台フルに配布するようにするという。
そのような考え方では、すぐに破綻します。64台の配布で破綻しているか、255台の配布で破綻するかの違いでしかありません。

またそうしたDHCPに焦点を当てているときに、各種のスイッチの config から不備が見つかったようです。そのネットワークはもう数年も運用されているという実績があるにもかかわらず、設定値を正しい値にすることに意味があるのか。そのように考えることは理解に苦しみます。

僕の考えた結論は非常に単純で、新たに追加する数百台の端末は、新たなセグメントを発行し、そこから利用するというものでした。
しかしこれでは、既存のネットワーク環境に機器の追加もしくは設定の追加が必要になります。

応急処置として、根本的な解決にならない可能性が高いですが、結局以下の方法で様子を見ることになりました。
それは追加で導入した無線APで、 nat を行うというものです。既存環境では、DHCPの枯渇によることが原因でした。そのため数百台の端末が接続されても、 nat であれば消費するIPは1つで済みます。

こうして当初よりは安定稼働したようですが、まだ予断を許しません。

stock_value at 12:48|この記事のURLComments(0)

2017年05月08日

技術者としてユーザーのサポートをしているとき、大げさに申告されることはよくあります。そしてそれはとても気持ちがわかるので、あまり気にしません。

例えばインターネットの接続ができないとき、各種のログを確認していると本当にアクセスできていない時間は5分ぐらいだった場合。ユーザーからの申告は最低でも10分以上できない。そのように言われますし、場合によっては30分できないと言われる場合もあります。
そして復旧しても、まだ遅いとか。

こういう申告は日常的にあり、ユーザーの事実なのか主観なのかわかりませんが、解決までなるべく最短であるように務めるだけです。

一方で、完全なウソの場合があります。
特定の人とメールができない状態なのにも関わらず、メールがすべてできない。とか。

もちろん、本当にメールをしたい一人とすぐにメールができない状態であれば、不特定多数の意味の無いメールがどれだけできても望んでいる状態ではないと思います。それはよくわかります。

しかしトラブルを素早く解決するには、そのような事実に反する申告はかえって解決に時間がかかってしまいます。
先日もサーバーの切り替えに伴う、DNS設定の変更がありました。

しかし新サーバーは、メールサーバーだけの利用であったため、そこまでリスクを伴うものではありませんでした。
週末の土曜か日曜に切り替えを行う旨を伝えていました。
すると土曜日に連絡が。「ホームページが見られなくなりました!大至急DNSの設定を元に戻してください。」と。

どうやら昨日までは正常に見られていたホームページが土曜になって突然見られなくなったらしいのです。そしてその原因はDNSの切り替えしかない、と。
「なるほどわかりました。が、僕自身はまだDNSいじっていませんよ。僕に起因した設定は何も変わってないので、別な原因ではないでしょうか?」そのような状態でした。突然見られなくなったというのはきっとウソなんでしょう。

週が明けてからも連絡がありました。「今日になってメールが届かないというクレームがユーザーからたくさん届いています。そして私のところにもメールがとどきません。」と。

メールサーバーの切り替えで、新旧ともに同じ設定が入っている場合、エラーメールが戻っている可能性は限りなくゼロだと思われます。
にもかかわらず、エラーメールが送信元に戻るというのは、どういう状況なのかちょっと想像できません。そしてこの想像できないエラーについては、詳細に状況を聞かなければならないのです。

で、「今回のDNS切り替えで、エラーメールが送信元に戻るというのは考えにくいのですが、どのようなエラーメールが戻っているか転送してもらうことは可能でしょうか?もちろんエラーになっているということなので、第一優先でサーバーの切り替えは元に戻したいと思います。ただしエラーメールの件が解決できない限りは、再度切り替えることができないため、お手数なのですがお送りいただきますようにお願いいたします。」と。

そうなると結局は、いやエラーメールが戻っているのは1件だけです。とトーンダウンしていました。そしておそらくその1件というのもウソなのだと思われます。

大変な状態になっていることを伝えるために、ウソや間違いは混ざっているのは、トラブル解決に時間がかかると思いました。

stock_value at 11:39|この記事のURLComments(0)

2017年05月07日

いつも忘れてしまうのでメモ。

スイッチの設定をするとき、Ciscoでは毎回必ずやるであろう設定があります。例えばそれは日時を設定するために、JST 9 の設定とか、ホスト名とか。

そのような必ず指定しなければならない設定は覚えていますが、その他細かい設定はつい忘れてしまいます。

service password-encryption
clock timezone JST 9 0
ip subnet zero
no ip source-route
no ip domain-lookup
ntp server 192.168.0.1

interface GigabitEthernet 1/0/X
description XXX
switchport nonegotiate
no cdp enable



nonegotiate と no cdp のコマンドをつい忘れてしまいます。

stock_value at 17:31|この記事のURLComments(0)

2017年05月06日

パスワードを設定してください。そのようにいわれて、設定する場合に、どのぐらいの文字数、文字の種類を利用すればいいのか迷うことがあります。
基本的に僕はパスワードの利用は通常無意味であることが多いため、基本的にはパス無しでのファイル交換がほとんどです。
しかしそれでも、各種理由によってパスワードを設定することが多くあります。

たいていの場合、先方がパスワードを付与してくることが多く、日付とか会社電話番号とか、簡単な文字列であることがほとんどです。そしてそれらはなんだか無意味な感じがしてしまいます。

で、海外の Wikipedia には、パスワードの強度について記載がありました。
また日本語でDITという会社がレポートを公表していました。
セキュリティ調査レポートVol.3 パスワードの最大解読時間測定 【暗号強度別】

上記レポートでは、10桁+英大小文字+数字+記号になれば、結構現実的な感じがします。最低限英大小文字+数字ぐらいはほしいところです。

だからもし僕がパスワードを決定できる場合、無意味と考えている場合にはいわゆる社会通念に従った簡易なパスワードを。そしてちゃんとした強度を求められている場合には、ちゃんとしたパスワード生成ソフトを利用して、強固だと思われるパスワードを設定しています。

なお自分で考えるパスワードはとても弱いものだと思われるので、だいたいはジェネレーターを利用しています。そしてもし自分で考える場合には、フレーズを利用しています。文章→英数に変換って感じです。
例) 今日もブログを書きました。 → #Kyomo-Blogwo-kakimashita!#"
こうすれば、比較的長いパスワードを決めることが可能です。問題は覚えていられないことだ・・。

参考
Password strength : wikipedia

stock_value at 15:08|この記事のURLComments(0)

2017年05月05日

Webホスティングはさくらインターネットを利用しています。メールサーバーは、 wadax を利用しています。
そのような環境で、先日の通り、Webサーバーにフォームを設置し、メールを飛ばそうとしたのです。

現在契約しているメールサーバーが別途あるので、WP-Mail-SMTP を利用して、wadaxのサーバーをメールサーバーとして指定しました。
すると、以下の通りエラーが。

There was an error trying to send your message. Please try again later.

で、仕方が無いので、手元にある別なサーバーを指定すると、そのときは問題無く送信されるのです。
重要なのは、常にテストでは成功しながらも、フェームからのメール送信は失敗するところ。

またいくつかオリジナルのカスタマイズメール送信フォームもあるようで、そこでは添付ファイルを利用しており、関連するかわかりませんが、こちらも上記と同様のエラーに。

結論からいうと、通常のフォームが失敗するのは wadax 以外のサーバーをりようすれば問題無く送ることができました。原因は不明です。
添付ファイル等のオリジナルメールフォームは、常に失敗しており、原因は不明です。まだ解決していません。

wordpress では wp_mail() という関数を利用しているようで、なおかつこれは、PHPMailer に関連しているようです。
バージョンの整合性などの問題も考えられますが、おそらくプログラムで何らかのエラーを吐いているのだと想像できるのですが、そこを調査する時間はまだ無くて・・。

ということで、代替案を考えたいと思います。


stock_value at 15:28|この記事のURLComments(0)

2017年05月04日

Wordpressを利用する案件です。

Webサーバーとメールサーバーが同居していないシステムがありました。同居していないのですが、ホスティングの設定上、同居しているような挙動となってしまいます。そのため、Webのフォームからメール送信が行われる場合、自身のメール機能を利用して送信すると、ローカルで配信してしまうのです。そこでエラーに。

この場合やっかいなのは、普通のホスティングサービスであれば、ローカル配信でエラーになったエラーメールはユーザーには届かず、原因究明が難しいのです。

そしてこれを解決するには、メール送信をする際に、外部のメールサーバーを指定すればいいのです。
しかしながら、MW WP Formでは、外部のメールサーバーを指定することができないようです。

とりあえず解決策としては、外部のメールサーバーを指定するためのプラグインが別にあるので、それを利用すればいいのです。
PHPのバージョンで、いくつかトラブルがあるようなので、 SMTP Mailerを利用するのが無難な感じです。※ただし現時点ではまだ日本語対応ではありません。

僕の環境では、WP-Mail-SMTP というプラグインを利用していました。ここでは WordPressの全てのメールをSMTP経由で送信する。 を選択し、各種適切に設定を行います。
これで基本的には問題無く送信できるようになるはずです。
※PHPのバージョンによっては、証明書絡みの件があるようで、正しく動作しないかもしれません。

僕の調査した環境ではまだこの先がありましたので、明日の記事に。

stock_value at 15:19|この記事のURLComments(0)