2015年04月18日(土) - 12:27 | カテゴリ:
ロードバイク
今までは安いタイヤ(2000円前後)の、投げ売りされている物を使っていたのだが、
「そろそろグレード上げてみるか～」と思い立ったので、
シーズン始った4月初頭にタイヤを変更してみた。
今回は初めてカラータイヤに変更をしてみた。色はフレームと合わせて黄緑に
本音を言うとPRO3が欲しかったが、予算的に厳しかった(´・ω:;.:…
今回購入したのはSERFASのSECA RS。
購入理由は、
-
フロント・リアで合計7000円以下
-
グリップを最重視。次点に耐久性
-
タイヤカラーが黄緑
という、その筋の人からしたら『「出直してこい!!」( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ』とされそうな理由。
自分はレースとか殆ど出ないし、比重はホビーなのでこの程度が性に合っている。
………
今までカラータイヤを履いた事が無かったのも関係あるのだが、
「ロードバイクの印象が結構変わるなぁ～」というのが第一感想。
今までは黒一色だったので、少し新鮮な気分。最終的には黒に戻ってくるという点は重々承知…
次、手軽に変更出来るとしたらバーテープとかボトルケージ辺りか。
予算に余裕が出来たら、この辺りも変更していってみよう。
こうして、"エ○ゲ+自作PC+NW機器+自転車"と金がなくなっていく(´；ω；｀)
« 続きを隠す
2015年04月11日(土) - 22:31 | カテゴリ:
Linux
"ns-lab BB"の内側では、各サーバの認証用にプライベート認証局をたてておき、
それのCA証明書をPCにインストールする事で認証時のエラーを無くしていたり。
んな事やらなくても、webブラウザ側で例外指定すればOKなのだが、
証明する為に使用している証明書を例外指定するのもどうかと思うので、
面倒臭いのだが、↑のような運用をしている。
で、先日サーバ側の証明書が期限切れになったのと、
巷で細やかに騒がれているSHA2証明書への完全移行が頭に過ぎったのであった。
色々と調べてみた所、今後は"RSA-SHA2"が主力となる見通しなのだが、
次世代暗号方法として楕円曲線暗号(EllipticCurveCryptography)も使われ出している事がわかった。
という事で「自宅鯖なんだから最新技術を追っ掛けてナンボじゃい!!」という事もあり、
プライベート認証局を"RSA SHA-256"と"ECC prime256v1"に対応させてみた。
"ns-lab BB"のとあるサーバ転送量グラフ。自作スクリプトなので適当仕様なのはご愛敬(´・ω・｀)
当たり前だが、プライベート認証局の証明書を使う事で、例外指定をせずにhttps通信が出来ている。
楕円曲線暗号(ECC)については、Syamtecのサイトに詳細が載っているので、そちらを参照。
要は「RSA暗号よりも、低負荷でより強固な暗号化」を行えると思って頂ければ(詳細は違うが…)
RSAにはsha256やsha512、ECCにはprime256v1やsecp521r1等があるのだが、
今回採用したのは"RSA SHA-256"と"ECC prime256v1"の二つ。
「題目がECCなのに、なんでRSAも…?」と突っ込まれそうだが、
自宅で使っているMTAや自作ソフトがECCに対応していなかったので、RSAも残す事に(´・ω:;.:…
ちなみに、sha256とprime256v1は32bit処理に特化したハッシュ関数。
64bit処理に特化させる場合はsha512やsecp521r1の方を使う必要がある。
が、自宅レベルでは二つの違いがわからないのと、
デファクトスタンダードは256bitの方なので、そちらに準拠してみた。
………
そして、実際に"RSA SHA-256"と"ECC prime256v1"を使って認証局を構築してみた。
|
|
RSA SHA-256
|
ECC prime256v1
|
Cirtificate
Signature
Algorithm
|
PKCS #1 SHA-256 With RSA Encryption
|
Object Identifier (1 2 840 10045 4 3 2)
|
|
ページ情報
|
|
|
|
証明書情報
|
|
|
|
証明書の階層
|
|
|
※RSAとECCでの負荷比較については、@ITで紹介されているので割愛。
………
使用感についてだが、昨今のWebブラウザは標準でECCに対応しているので、
違いを気にせずに利用する事が可能だった。
また、証明書をインストールする時の操作性とかも全く問題無し。というよりも違いが無い
という事で、ガラケーが対象のシステム(ガラケーはECC非対応)や、
もの凄く古いOS(こちらはOS次第)を使っていない限りは
ECCタイプの証明書を導入しても問題無さそうという結論になった。
しかし、企業レベルでの導入事例がまだ少ないのと、
2030年まではRSA-SHA2で大丈夫と言われているので、
暫くの間は、今まで通りRSAが主流になりそうな気がする。
しかし、超大規模なECサイトとか、サイト全体をhttps化するような場合には
ECC証明書の導入を検討する余地はありそう。何せ、処理が凄く軽いので
証明書業界としても、ECC証明書の導入を推奨しているらしいので、
SHA2切り替え時に、一足先にECC対応させるのも一つの流れになるだろう。
« 続きを隠す
2015年04月04日(土) - 22:29 | カテゴリ:
Network
この度、初代"ns-lab BB"のメインスイッチとして頑張ってた「CenterCOM GS908M」と、
2代目"ns-lab BB"サーバセグメントスイッチとして頑張ってた「DGS-3100-24」を手放す事に。
特にGS908Mの方はインテリジェントスイッチとして、
自分は初めて使った機種という事もあり色々と感慨深く(´；ω；｀)
と言っても、GS908Mは手元にあと2台(うち1台は現役)あるので、
1台を手放すしても問題は小さいだろう。
今回手放す事にした経緯は、単純に未使用なL2SWの在庫整理をしたかったから。
しかし、対象がかなり古い物である事と、内部を魔改造している為に
オークションに出すのも気が引ける(というよりも面倒くさい)ので、
ギガスイッチを必要としていた知り合いに譲る事にした。
正直、GS908Mは台数持っていても意味無いし… いやはや、昔はRSTPで遊んでいたな～
AlliedTelesis製品は現在進行形で無線APの中継に挟んでいるGS908Mと、
3代目(現)"ns-lab BB"のメインスイッチで使用しているAT-X900-12XT/Sがいるので、
急なAlliedTelesisコマンド復習も問題無いと判断。
DGS-3100-24は、2代目メインスイッチだったので今はいらない子に…
本当ならCatalyst2950と入れ替えてサブサーバセグメントのギガ化に使うべきなのだが、
自宅からCiscoCatalystを全て無くすのは気が引けるので、
やはりDGS-3100-24の使い道がなくなってしまう(´・ω・｀)
という事で、2台が次オーナーの元へと行く事になりましたとさ。
コンデンサーとか、排気ファンとか、ヒートシンクとか取っ替えたりで使い込んだ2台。
次のオーナーの元でも元気にパケットのスイッチングをしてほしい所。
« 続きを隠す
