カテゴリー別アーカイブ: ネットワーク

梨がうまいですね。

雨が止んでほしいと思うと止んだという天候を操るラッキーから、自宅のベランダで仕事ができるなんていうゆったりとしたラッキーまで、日々ラッキーづくしです。

最近とにかくツイています。

ジムに行っては空いている、キウイを食ってはうまい、梨を食ってはうまい、スイカを食ってはうまい、ももを食ってはうまい、ももに至っては安いなんていうためしてガッテンの視聴者層的なラッキー比率が多いですが、ラッキーはラッキーです。

ポジティブといいながらラッキーばっかり言ってますが、その辺も込み込みでラッキーでありポジティブなんでしょうね。

 

[`evernote` not found]
Pocket

脱・折れない心

折れない心を作らなければならない、という言葉があまり好きではない。

私は見かけによらず、心がぽきぽき折れるタイプだ。折れない心を作れと言われても困ってしまう。

しかし、世の中を見渡すと、アニメの主人公から、芸能人から、自己啓発書作家から、部活に励む小学生まで、折れない心が大好きだ。みんな折れない心づくりに躍起になって、どうやれば折れない心が作れるかを探している。折れない心作りに腐心して、心身ともに疲弊してしまっている人すらいるように思う。
そこまでして折れない心は作らなければならないのか。

折れない心を持っている人の実例にあげられるような戦国武将や剣豪たちは、本当に折れない心を持っていたのだろうか。

歴史書なんかを読んでいると、結構ぽきぽきいってるじゃないかと思うことがよくある。
彼らは鋼の心を持っていたわけではなく、実際はぽきぽき折りながらも、手をかえ品をかえ、時にはずるをしたりだまされたりしながら、目標に向かって進んだという方が正しいと思う。
マクロで歴史をとらえるから心が折れていないように見えるだけで、ミクロを見ていくと、彼らだって折りまくった心の屍の上を歩いていたはずだ。

現代でも、折れない心を持っているとされている人は、いろいろな挫折を味わっている。
心が折れても、その度に立ち上がってなんとか成功しているということだ。彼らの中から、目標へのやり方やアプローチの仕方をかえずに成功した人を探すのは大変だ。みんなぽきぽきと心をおられたから、手をかえ品をかえ、目標に向かってがんばったのではないか。

重要なのは、折れない心を作ることではなく、折れちゃってもいい細めの心をいっぱい作ることではないか。
いっぱい作っておけば、一つの心がだめでも新たに次の心を使って挑戦できる。100回心をおられても、101回目の心があれば、別になんてことはない。
100回も心をおられているうちに、もう心を折られた回数なんて数えていないだろうし、些細なことは結構どうでもよくなっているはずだ。

折れない一本の心を丹念に育て上げるのもいいが、それだとリスクが大きすぎる。それが折れたらおしまいだ。だから折れないようにするんだ、と言われるかもしれないが、外的要因で仕方なく心を折られてしまうことだってある。例えば交通事故などがそうだ。
歩道の真ん中を、非常に注意深く、誰にも迷惑をかけず、自転車がきたら脇によけ、人とすれ違うときは道を譲り、笑顔で挨拶を交わしながら歩いていたとしても、一台の暴走トラックから自分の身を守ることはできない。

ビジネスだってそうだ。一社のお得意様からの売り上げが突出していたら、それはすばらしい事である反面、事業リスクでもあるわけだ。少し売り上げが低くても、複数のお取引先からまんべんなく売り上げられている状態のほうがいい。お取引先を失ったときのリスクを極小化できる。

別に折れない心を一本持っていようが、折れてもいい心を数千本持っていようが、最終的に目的地が同じであればそれでいいはずだ。数千本の折れてもいい心は、それだけ多くの可能性を検討できるということだし、人間としての幅も広がるように思う。

折れない心なんて無理して作る必要はない。作れ作れと九官鳥のように繰り返す人が、折れない心を持っているかどうか確かめてからでも遅くない。
折れてもいいように嫌なことから逃げつつ、回り道しつつ、自分を騙しながら目的地へ近づけばいいと思う。折れない心を作ろうと頑張っているうちに心が疲弊してしまっては意味がない。

折れてもいい心をバンバン量産していくのがいい。新しいことに挑戦すれば心なんて何度も折れるに決まってるんだから、折れても残るくらい大量に生産しておけばいい。

「このへんで一発、二、三本折っとくか」くらいのゆるい感じで折っては作り、折っては作りを繰り返していけば、心の鍛冶職人探しに苦労することなく、今を全力で走り抜けられると思う。

[`evernote` not found]
Pocket

人類の敵「その他」フォルダ対策

どうも、人間というのは「その他」が好きです。

分類がめんどくさいからなのか、分類を考えるのが嫌なので後回しにしているのか、あるいはその両方か。明確に分類されたフォルダ構成の中に、「その他」が混ざってくると、あっという間に「その他」使用率があがります。

かく言う私自身も「その他」愛好家ですので、仕事のデータから過去の資料から、何から何までとりあえず「その他」につっこむ癖があります。

「その他」につっこんだ後には、「その他」の中で階層分けをしてディレクトリを切って行くなんてことも始まってしまうので、「その他」主導の政治が始まってしまい、正規のディレクトリ住民たちが被害を被るなんて話もよくあります。

私の場合も例外でなく、過去に作成した資料やデータ、「参考のために!」という高い志でダウンロードしたホワイトペーパーなどを崇高な「その他」フォルダにつっこんでいたのですが、いよいよどこにあるかわからなくなって困ってきたので、整理を考える事にしました。

 

とまあ、色々考えたふりなどをしてみたのですが、我が家のファイルサーバはLinuxなので、とりあえずシェルを書いて自動分類しよう、というのは即決です。

問題は分類の方式なのですが、資料の方向性ごと、用途ごとなど、感情の挟まる隙間があるとどうしようもなくなってしまうので、拡張子ごとに整理するという方式をとりました。

拡張子で分類されてしまえば、「パワポ、パワポ、あのときのパワポ・・・」と無駄な時間を過ごす必要もなくなり、該当する拡張子フォルダさえ探してしまえばいいからです。

 

さて、書いたシェルはこちらです。

raspberry piで動かして、問題なく動いているので、Linux環境であれば動くと思います。

 

シェルを叩くと、最初に拡張子を入力させます。

pdfならpdfと打てば、srcフォルダ内の.pdfファイルを探し出して、 dstフォルダ内にpdfというディレクトリを切り、そこに移動してくれます。

mvコマンドに-bのオプションがついていますので、同名のファイルも上書きされずにチルダがついてバックアップファイル扱いになります。

あまり汎用性が高くないですが、個人事業の仕事ファイルを分類するには十分な便利さとスピードです。

これでさらに「その他」フォルダの活用が増えそうという本末転倒な結末を迎えそうな気がしますが、その時はこのシェルにがんばってもらう事にしましょう。

[`evernote` not found]
Pocket

カタカナの怖さ

先日、とあるお仕事でのことですが、「Route」のことを「ルート」と表記した資料を元にいろいろと話を進めていました。

わかりにくいのでアルファベットにしましょうか、という提案をしたところ、本来「Route」となるべき所が、「Root」(スペルを勘違いされていた)となってしまったことがありました。

「Route」と「Root」はどちらもITインフラ周りではよく出てくる用語ですので、一見すると意味が通ってしまったりして大変ややこしい思いをして苦労しました。

 

私は自分で資料を作る際には、ほとんどの場合において、類似のカタカナ語が存在する場合はアルファベット表記を使うことにしています。

この例であげたRouteとRootや、PacketとBucketなんかもそうですし、PathとPassなんかもわかりにくいです。WeightとWaitなんか、両方ともお尻に値がついて「ウェイト値」という言葉で使われることが多いので、大変わかりにくいです。

これらをカタカナにして表記しておくと、一見しただけではどちらの意味かつかめず、暴走してトラブルにつながることがあり得ます。直接的に大きなトラブルにつながることはないかもしれません。しかし、例えば、Linuxに対して「Routeの設定を変更」というような曖昧な指示が出た場合「Rootの設定を変更」と勘違いして暴走してしまったら大変です。

「そういえばRootのパスワードを変えるかも?みたいな話が出ていたなあ」といった偶然が重なってしまったら、ある日突然root権限のパスワードが変更されていて、パニックが起きるかもしれません。

 

ネットワーク機器の話をしているときは、スタンバイという言葉の雑な使い方も、個人的には気になっています。

HSRPにおいてはstandbyという文法で設定を行いますが、HSRPというプロトコルは同様にスタンバイルータを構築するためのものです。

会話の中で、「スタンバイの設定」という言葉が出てきた場合、「HSRPの設定を行う」のか、「スタンバイ側機器の設定を行う」のかが、わかりにくくなってしまいます。

ハインリッヒの法則によると、大きなトラブルは軽微なトラブルの積み重ねによって起こるとされています。曖昧なまま確認しなかったことで、自分がトラブルを起こしてしまうことはできれば避けていくほうがいいでしょう。

ですので、私は「カタカナ表記=依頼者の中で定義が曖昧=注意」と自分の中でリンクして考えることにしています。カタカナ満載の資料が届いた時には、必ずカタカナ語の意味を確認することにしています。

その際、最も重要なのは、「依頼者側は専門家ではないため、しっかりと用語定義ができている必要はない」ということだと思います。用語の履き違え、意味の取り違えがあった場合、悪いのは確認しなかった専門家側にあるということだと思うのです。

[`evernote` not found]
Pocket

設定作業に集中できる、Console設定

検証や設定途中にログアウトすると、検証の中断となったり集中力が途切れたりします。下記の設定を入れておくことで、console設定中の邪魔を可能な限り防ぐことができます。

exec-timeout 0 : タイムアウトによるログアウトが発生しません
privilege level 15 : enableモードの状態でログインします
logging synchronous : consoleメッセージに邪魔されることがありません

 

[`evernote` not found]
Pocket

EEMでinterfaceがDownした際に、別のintefaceをDownさせる

EEMでFastEthernet0のinterface downを検知した際に、FastEthernet1もdownさせます。また、EEMが起動したことをlogに記録します。

 

[`evernote` not found]
Pocket

「無線LANのメール丸見え 成田、関西、神戸の3空港」の記事を読んで

私の仕事と関連が深い部分もあり、少し気になる記事でした。

http://www.47news.jp/CN/201408/CN2014082601001440.html

 

記事自体は非常に短いですが、内容をまとめると、「空港のFree WiFiにつないだら、通信の中身が全て丸見えでした」というものです。

 

神戸大学の教授が発表した内容を検索しても出てこなかったため、何とも言えませんが、少なくともこの記事にはミスリードか作為的なものが感じられます。

そもそも、Free WiFiというものはそういうものです。事前に定めたキーワードやパスワードを知らない人でも自由に使用できるように、暗号化せずに解放しているWiFiのことです。

利用するかしないかは自己責任ですから、利用したくないと思えば、ある程度のセキュリティが施されている事前登録型の暗号化WiFiスポットを探して使えばいいわけです。

この記事では、「そもそもFree WiFiというものがそういうものだ」という前提条件を取っ払って、いきなり「中身丸見えだよ」と言っているわけですから、無駄に規制の対象増加をあおるような言い方です。

 

あわせて、記事の内容も気になりましたが、私個人として気になるのは、神戸大教授の実地試験の方法です。

記事が短すぎることと、内容が紹介されていないことから、あくまで推測でしかありませんが、この試験は2つの端末をFree WiFiスポットにつなぎ、片方からもう一方の通信を覗き見するような仕組みで試験したのではないかと思います。

Free WiFiのAP自体にアクセスできてしまうと、実地試験をやる意味はあまりありませんから、あくまで試験は一般クライアントとして行ったと想定されます。ですので、なんらかのパケットキャプチャなどを用いて、一方の試験PCが通信中の内容を傍受し、その中身を後から解析するような試験になるのかな、と想定されます。

通信傍受中はFree WiFiにアクセス中の試験PCだけではなく、試験に全く関係のない一般利用者端末の通信情報まで傍受できてしまう可能性があります。

この点においては、試験中に全く影響を与えない措置を講じていたのか、傍受できていたのだとしたら、諸々法的には大丈夫なのか、そういったあたりが非常に気になります。

 

こういった試験は非常に重要な意味を持つと思いますし、今後も継続してほしいところですが、試験内容に問題がないという説明をする意味でも、試験内容の公開をしてほしいと思います。

個人的には勉強もしたいので、ぜひ公開してほしいです。

 

ちなみに私が調べた森井教授のページは以下です。

http://srv.prof-morii.net/~morii/

http://www.research.kobe-u.ac.jp/eng-es3/

 

便利なものが出てくると、それを一方的に批判するような記事が出ることはよくあることですが、そのことでイノベーションが阻害されているかと思うと、微妙な気分になります。

Free WiFiは確かに非暗号化通信ですが、Free WiFiの存在自体は否定されるものでも悪く言われるものでもありません。自動車や包丁と同じです。

一方で、Free WiFiについて、漠然とした不安をお持ちの方は、「使わない」という選択肢を取るべきです。

確かに便利なものですが、使わないことに勝るセキュリティ対策はありません。攻撃手法は時々刻々進化していますから、一度セキュリティの対策をしても、それが翌日には不十分になっている可能性があります。

使わないことだけが、唯一色あせないセキュリティ対策です。

どうしても使う必要があるのであれば、それはそれなりの学習や、対策を施し、リスクを認識しながら使用するのがいいと思います。

[`evernote` not found]
Pocket

「コミュニケーション能力」への違和感

今更感もありますが、コミュニケーション能力という言葉の使い方に違和感があります。

コミュニケーションというのは送り手と受け手で成り立つ意思の疎通のことを言う訳ですが、本来、送り手が伝えたいと思ったことがどれだけ正確に受け手に伝わっているか、送り手の伝えたいと思っていることをどれだけ正確に受け取れるか、ということがコミュニケーション能力の本分であるはずです。

ですが、昨今のコミュニケーション能力の意味は、「思いやり」だとか、「優しい言い方」だとか、「話が面白い」だとか、そういう人柄の部分に重きが置かれており、「伝達したいことを可能な限り正確に伝達する能力」は重視されていないような気がします。

 

コミュニケーションについて正確に把握するために、コミュニケーションをステップに分割すると、以下のようになります。
1.送り手が伝えたい事を思いつく
2.送り手が独自の経験等に基づき、伝達切り口を決定する
3.送り手が言葉にする
4.環境、情勢などの外的ノイズが送り手の言葉に付加情報を与える
5.受け手の耳に入る
6.受け手が送り手の言葉を独自の経験等に基づき、解釈する

私が考える限り、上記のような6つのステップを経て、送り手の考えが受け手に伝わる事になる訳ですので、ステップ1とステップ6では全く違うこととして伝わっている可能性もあります。

本来のコミュニケーション能力というのは、1と6の差分を定量的に確認し、1と6が限りなく近づくまで繰り返し繰り返し伝達する、あるいは、繰り返し繰り返し確認する能力のことを言うはずです。
ところが、最近求められているコミュニケーション能力というのは、2と6の部分がいかにそつなくできるかというところしか見ていないように感じます。

コミュニケーション能力の巧拙で考えると、伝えようとする切り口、解釈の切り口がどうあれ、伝えられたか、受け取れたか、が重視されるべき点です。そつなく出来ていなくても、1と6の差を可能な限り埋めていれば、笑顔で話すことよりも評価されるべきなのです。

面白い話ができるとか、笑顔で話せるとか、そういったところは会話の雰囲気作りに関するテクニック的な能力であって、コミュニケーション能力とは違うものであると思います(重要ではないという意味ではありません)。

私は、コミュニケーション能力という言葉を、面白い話をする、笑顔で話せる、という意味で使っている人ほど、本来のコミュニケーション能力に劣っているように感じます。

そういう人に限って、「伝えたはずだ」、「言ったはずだ」、「言っておいたのだが」というような一方的通達をコミュニケーションととらえているような発言をしがちに感じます。

私は、誰かが「伝えたはずだ」、「言ったはずだ」、「言っておいたのだが」というような発言をしたのを耳にした場合、その誰かと仕事をするときは、必要以上に意図を確認する事にしています。

「言ったはずだ」などの一方的通達を行う人は、受け手も自分と同等の経験をし、自分と同様に考え、自分の言ったことを言った通りに解釈するはずであるという身勝手な前提の上で発言している可能性が極めて高いからです。

あまりに繰り返し確認すると厄介な事になったりしますが、問題が大きくなって面倒なことになるよりは、最初のうちに繰り返し確認してムッとした顔をされておいた方がいいと思っています。勿論、可能な限りムッとされないため、自分を下げるようなインプットを相手にあたえ、確認に持ち込むように誘導するようなテクニックは必要です。

私個人としては、面白い話が出来る人よりも、多少口ベタだったとしても、「受け手は絶対に送り手が伝えたい事と100%同じように解釈することはありえない」、とわかっている人の方が、信頼できると考えています。

[`evernote` not found]
Pocket

【CCIE Lab受験メモ9】Terminal Softの設定

Terminalソフトは使い始める前に必ず設定を見直しておくべきである。

業務であれば必ずそうするように、試験においても設定を確認しておくことは必須である。特にPasteの設定については確実に確認しておかなければならない。あせった時に癖で右クリックし、最悪の事態が訪れる可能性が非常に高いからである。

Terminalソフトは試験の開始に必ず確認し、避けられた事故を起こさないように気をつけたほうがよいだろう。
Puttyの設定において、最低限見ておかなければならないのは、以下の2つである。

・Sessionの設定
・Window⇒Selectionの設定

まず、Puttyの設定はウインドウ左上のアイコンから行う

WS000005

 

コンピュータのアイコンを左クリックすると、画像のとおりメニューが表示される。

表示されたメニューからChange Settingsを選択するとPuttyの設定を変更することができる。

WS000000

 

この設定で見ておくべきはsessionの設定である。
この設定がNever以外になっていると、コマンドラインでexitを打った時に、ウインドウが終了されて鬱陶しい。

 

WS000002

 

この設定がWindows以外になっていると非常に使いづらい。
特にCompromiseになっていると、右クリックでPasteしてしまうので、事故の原因となる。非常に危険である。
この二つ、特にWindow⇒selectionの設定を見ておけば、事故は防げるだろう。

あとは、個人的にPuttyは無駄にフォントが小さいので、その辺も修正しておきたいところだ。

 

WS000001

Window⇒AppearanceからFontのサイズを変更することができる。
12~14くらいにするのが好みだが、慣れてしまえば必須の変更箇所でもないだろう。
他にもPuttyのバージョンは複数取得し、それぞれに設定方法などを知っておくとよいだろう。

[`evernote` not found]
Pocket

Cisco IOSにおけるAliasコマンドの活用

あまり実際に使われているのを見かけないが、aliasコマンドでよく使うコマンドのショートカットを登録しておくと、作業が楽になる。

特に、検証環境などでルールを作成しておくと、長いコマンドをいちいち打つ手間が省け、作業を簡易化することができる。

aliasコマンドでコマンドショートカットを登録するには、

で行う。

たとえば、show ip route ospfをsiroという名前で登録したい場合は以下のとおりである。

 

このコマンド登録以降は、

 

あるいは

 

で同様の結果を表示することができる。

 

非常に長く、覚えにくいコマンドについては登録しておくことを推奨する。

 

このコマンドはstartup-configとrunning-configの差分を表示できるコマンドであるが、非常に長いため、憶え辛い。しかし、下記のようにalias化しておくと、sharcと打つだけで差分を表示できるようになる。

 

他にも、個人的に検証環境に必ず登録するaliasを紹介しておく。

alias コマンドライン
srb show run | beg
srinc show run | inc
sre show run | ex
srint show run interface
srs show run | section

aliasを登録しすぎると、今度はすべてのaliasを記憶するのが大変になるため、あまりお勧めできない。

私のお勧めとしては、show run系や、show ip route系など、ある一種類のshow系コマンドをalias化しておくのが覚えやすくてお勧めである。

勿論、すべて記憶できるのであれば、aliasによって作業は相当に高速化できるはずだ。

 

[`evernote` not found]
Pocket