2021年01月09日(土) - 20:35 | カテゴリ:
PC
エ○ゲソングのジャケット画像取込みや、私用文章を残す為にスキャナーを使っていたのだが、
複合機のスキャナーを使っていたのでスキャンの度に起動して毎回インクを浪費していた。
流石に毎回インクが無くなるのは嫌になってきたのと、
複合機も10年近く使いそろそろ買い換えようと思っていたので時間を見つけて機種を物色。
結果、筆者の使い方ならスキャナーとプリンターを分離した方が得策という結果になった為、
Canon製のスキャナーを買ってみた。
ポイントを使って1万円以下で購入。意外と安くする事が出来た。
内容物はシンプルで、本体・ドライバCD・USBケーブル・スタンドの4つ。
電源はUSBケーブル越しにPCから取る機種なのでACアダプターは無かった。
電源をUSBから取るのが結構曲者で、USB延長ケーブルやUSBハブを噛ますと電圧が足りず起動しない。
上手く起動する場合もあるのだが、スキャンすると電圧不足に陥って停止した後に再起動ループに突入する。
さらに、付属のUSBケーブルが1.5mと微妙に短く、置き場所によってはUSBケーブルが届かなくなる。
これだと購入したのに使えないので、エレコムのUSB TypeCケーブル(U2C-AC20BK)に変更して使う事にした。
本体の仕様書を読むとデータ転送速度はUSB2.0になっているので、恐らくUSB2.0ケーブルでも問題無いはず。
ただ、USB3.0相当の900mAを供給すれば最高速でスキャン出来ると書いてあるので、
フルスペックで動かすならUSB3.0版のTypeCケーブルを購入した方が良いと思う。
スキャン台は普通の物。素材はポリカーボネートか何かみたいだった。
天板はペラペラで軽い為、スキャン対象を密着させるには上に重しを置いた方が良いかもしれない。
軽いからこそ縦置きが出来るメリットもあるので、利用者の捉え方で変わると思う。
紙を1枚スキャンすると普通に閉じる事が出来るが、厚みを持った対象は挟むことが出来ない。
という事で部屋にあったDOS/Vパワレポ(2021冬)を挟んでみた。
挟んでみて判ったのだが、対象が厚い時はヒンジが起き上がり余裕が出る様になっていた。
ノイズキャンセリング等のフィルター加工をせずに、1600dpiで読み取った後に縮小のみしたのがこちら。
CISセンサー機種なので斑目状のノイズが出やすい筈だが意外にノイズは出なかった。
高い機種を替えばCCDセンサーになるので、LiDE 400よりも鮮やかにスキャンする事が出来るが、
そこまで高性能な物は求めていない上、実際は画像補正を使うので気にしない事にした。
普通の人は複合機付属のスキャナーを使う事が多いと思うが、付属機能なのでそれなりなのも事実。
スペック的には大差無くても実際にスキャンするとノイズ量で差が出てくる。
何より、複合機でスキャンするとスキャナーだけ使うのにインクを使いコストがかかるので、
スキャナーを使う頻度が多い人は、いっその事スキャナー単独で購入するのも一つの選択視になると思う。
« 続きを隠す
2020年12月05日(土) - 21:32 | カテゴリ:
Network
筆者はNWラボに物理装置を使う事が多かったのだが、
物を揃えたら置き場が無くなってきたのと、稼働させる電気代が増えてきて困っていた。
また、本職の都合上物理装置を使った検証をする事が減ってきた事もあり、
昨年から今年にかけて実施していた自宅サーバ刷新を機にラボをGNS3に全面移行していた。
という事で、今回はNW仮想ラボ環境をネタとして紹介しようと思う。
適当にトポロジを組んで稼働させたステータスがこちら。
トラフィックを流していないので、CPU負荷は低いがIOSを動かす為にメモリ使用率が高い。
NWラボを構築する場合、資金がある人は実機を揃えたりCMLを購入して動かす事が多そうだが、
実機を動かすにはNW装置の置き場と稼働させる電気代が課題となる。
CMLも同様にサーバが必要となる上、Ciscoにライセンス料を払うのでお金がかかる。
という事で、本格的にNW検証をしないが簡単な検証は行う事を目的に据えてGNS3を選択した。
………
従来のGNS3はクライアントPCで全部エミュレートしていたのだが、
最近のバージョンはクライアントPC上で動くGNS3コンソールと、
実際にルータをエミュレートするGNS3 VMの二つを動かす必要がある。
GNS3 VMはVirtualBoxやHyper-Vでも動くので、
仮想サーバホストを準備せずにクライアントPC単体でも環境を構築出来る。
他にはVMwareに対応しており、本領を発揮するのはVMware版となる。
今回はこのVMware版を使い、VMware ESXi上でGNS3 VMを稼働させる構成となる。
この構成の場合、クライアントPCはコンソールだけをインストールすれば良いので環境を汚しにくい。
GNS3 VMの方はインスタンスイメージをインポートすれば動くので、ラボ環境を構築しやすい。
仮想サーバホストとなるVMware ESXiを構築するのが大変ではあるが、
VMware Workstation版も存在するので、クライアントPCだけでもNWラボを構築出来る。
クライアントPCからGNS3 VMに接続する際はコツがあるので注意。
通常はHTTPS接続を行う事でGNS3の制御を暗号化すると思うが、
バージョン都合なのかHTTP接続でTCP:80を指定しないと接続出来なかった。
GNS3のメリットは無料である事に尽きる。対応するIOSを持っている場合はサーバ準備のみで動く。
デメリットはIOS-XEなど最近のIOSが動かない所。コレばかりは仕方無いので実機を使う必要がある。
ただ、GNS3でもOSPF・BGPは問題無く動くので最低限のルーティングテストは出来ると思う。
………
AWSなどIaaSと閉域網接続をする時にはルーティングにBGPを使う事が多く、
今後も同様のスキルは求められる。
今まではネットワークを弄った事が無い人が必要に迫られて弄る場合、
手軽に準備が出来るGNS3を使うのも一つの手段になるかもしれない。
« 続きを隠す
2020年11月21日(土) - 23:48 | カテゴリ:
Linux
6月末に検証用ドメインを購入していたが、今まで他の検証をしていて忘れていた (´・ω・｀)
折角購入した物を放置するのも勿体無いので、DSレコード申請が出来るレジストラの調査を再開したら、
バリュードメインも一部のgTLD/ccTLDにはDSレコード申請に対応している事が判明した。
そうなればシメた物。今回の検証ドメインはバリュードメインで購入していたので、
レジストラトランスファーを行わずにDSレコード申請が出来る事となる。
という事で、自力で解決不可能な問題は無くなったので、実際に自鯖権威DNSにDNSSECを導入してみた。
元ネタは、IIJエンジニアブログで公開していた次の記事。
バリュードメイン利用時のDSレコード申請方法は、筆者の技術wikiに纏めてみた。
今回はお試しでDNSSECを触ってみたかったのと、粗探しの検証も兼ねているので、
構成はIIJのサンプルを流用して変に躓かないようにした。
ゾーン管理にはBIND、ゾーン署名にKnot、DNSクエリ処理にNSDを使う多段構成になっている。
最初はKnotを使わずに、スクリプトとansibleを組み合わせてゾーン署名の自作を考えていたのだが、
レコードを書き換えた時のロック処理や、署名の自動更新が複雑で実装が凄く面倒臭かったので諦めた。
………
今回一番躓いたのはDNSSECの仕組み把握する事。関連技術が多い上、文献も多く中々大変だった。
とは言っても、正しく把握しないと運用出来ないのでJPRS資料を片っ端から読んでなんとかした。
資料にも書かれていない細かい仕様があったりするが、
運用する上で必要な情報はゲット出来たので結果オーライだと思う。
ソフトウェア面ではKnotを使うのが初めてだったが、
1週間程度弄っていたらチューニングのコツは大体わかった。
DNSSECの実装範囲はソフトウェア毎に違うので、結果として弄るのが最善・最短となった。
という事で、DNSSECオプションを有効にしてDNS名前解決したのがこちら。
実際はもっと長いレコードが返ってくるのだが、画像が横にデカくなってしまうので割愛。
サンプルでは個別にAAAAレコードも指定しているが、ちゃんとRRSIGレコードが付与されている。
………
本来はメイン利用の権威DNSにもDNSSECを導入したいのだが、、
サーバをマルチマスターかつansibleでゾーン管理をしているのでサーバの改修が必要となった。
また、DNSSEC運用を間違えたら名前解決が全滅するので、いきなり適用するのは見送った。
検証ドメインを購入して何でも出来る様に、メイン利用のドメインと別に用意した訳なので、
暫くはこのまま検証ドメインで運用を続け、軌道に乗ったらメイン利用のドメインに反映しようと思う。
形は置いといてDNSSECの導入は出来たので、当初の目的は達成出来たとしてヨシとしよう。
« 続きを隠す
