ホーム » 2022 (ページ 12)

年別アーカイブ: 2022

2025年7月
 12345
6789101112
13141516171819
20212223242526
2728293031  

検索・リンク

2021年度 卒業研究発表会

2021年度 電子情報工学科 卒業研究発表会が 3/2(水),3(木) と行われています。

コロナ対策で、リモートを交えながら実施しています。5年間に勉強してきたことをこの1年間の卒研で総仕上げとしての発表で、緊張している人もいますが皆さん頑張ってしてしています。

{CAPTION}

{CAPTION}

 

発表の時は普通の不織布マスクを

発表などで緊張する人は、マスクに気を付けてもいいかも。
私は発表する時は大声でしゃべる方だけど、左のような色付きマスクは通気性が悪く、講師仕事が終わったら酸素不足だったのか酷い頭痛になったことがある。右のような普通の不織布マスクの通気性の良いものを使いましょう。感染拡大の視点ではあまりお薦めしちゃいけないのかもしれないけど、酸素不足の懸念がある時は通気性のいいウレタンマスクかな。
{CAPTION}

情報構造論2021全講義録

オブジェクト指向プログラミング2021全講義録

データベース2021全講義録

情報制御基礎2021全講義録

自室UPSの交換

今年に入り、たびたび自室の UPS がピーピー鳴くようになってきた。バッテリーの日付を確認すると7年以上前だった。apcupsd などのツールで監視はしていて、バッテリー供給可能時間 30分 はあったので、さすがに古くても瞬間停電には耐えられるだろうと使っていた。最近は1日に数回アラームが鳴るし、apctest コマンドを使って バッテリーの日付を新しくしておいたけど、やっぱりアラームが鳴る。

年度末に向けて、交換用の 新しい UPS (APC ES 750 USB: 外観は違うけど中身は今まで使っていたのと同じ) を購入しておいたので、ようやく交換した。バッテリーも購入したので、古い UPS の中身と入れ替えて、別に使う予定。

Emotet チェックツール EmoCheck

Emotet は、メール添付の マクロ付き Word / Excel によって拡散するマルウェアで、感染者のメールの Reply などを装って送信されるため間違って開く可能性が高く、広範囲に被害がでている。

全国の高専の中でも発生が確認されており、注意が必要となっている。(私の手元には、2月4日現在では届いていないけど)

このため、「Emotet の感染確認のためのツール EmoCheck での確認せよ」とのお達しが出ている。

ぜひとも、EmoCheck で感染確認をしましょう。

セキュリティワークショップin鯖江

セキュリティワークショップ

鯖江公民館でのセキュリティワークショップにて、CTFの問題作りと解説を担当させて頂きました。
コロナ感染の拡大で、中学校や高校からの参加予定者が急遽参加できなくなったりで、リモートでの参加者も多かったのですが、無事終えることができました。
{CAPTION}

新しく作ったCTF問題(簡単)

このCTFのために、新しく作った問題を以下に掲載しておきます。

壊れかけたHDDから取り出したファイルを復元

知り合いのパソコンが壊れかかっていたようで、chkdsk.exe が動き出し、File0000.chk, File0001.chk といったファイルが作られた。そのファイルの1つが zip 圧縮で送られてきた。そのファイルの中から CTF のフラグ FLAG{xxxxx} といった情報を見つけてください。

この川の名前がフラグ

この写真に写っている川の名前を答えてください。ただし、流域全体で呼ばれている名前ではなく、この地区で呼ばれている名前が答えです。


この問題、File0000.chk をメールで送ったりすると、最近のメーラやブラウザは頭がいいので、答えがすぐに見えたりするので、zip 圧縮の設定にしたり、担当者の方に川のファイルを Facebook メッセンジャーで送ったら、Exif 情報が消されたりと、色々とデータのやり取りで手間取りました。

NoSQLと Google firestore

データベースシステムとして、最近は NoSQL (Not Only SQL) が注目されている。この中で、広く使われている物として、Google FireStore などが有名である。教科書以外の最近のデータベースの動向ということで、最後に NoSQL の説明を行う。

リレーショナルデータベースシステムの問題

リレーショナルデータベースのシステムでは、大量の問い合わせに対応する場合、データのマスターとなるプライマリサーバに、そのデータの複製を持つ複数のセカンダリサーバを接続させる方式がとられる。しかしながら、この方式ではセカンダリサーバへのデータ更新を速やかにプライマリサーバに反映させる、さらにその結果が他のセカンダリサーバに反映させる必要があることから、大量のデータに大量の問い合わせがあるようなシステムでは、これらのデータ同期の性能が求められる。しかも、プライマリサーバが故障した場合の復旧なども考えると、こういったプライマリ・セカンダリ・サーバ構成での運用・管理は大変である。

NoSQLの利点

NoSQLのデータベースでは、すべてのデータを複数のサーバ(別のデバイス,ネットワーク)に冗長化したうえで分散して保存する。この際に、どのサーバがプライマリサーバといった概念はない。もし1つのサーバが故障したとしても、分散して保存されたデータから元のデータを自動的に修復できるような構造となっている。

データの分散保存であれば、ハードディスクの RAID システムなども関連知識となるであろう。

  • RAID0 – ストライピング(データを別デバイスに分散保存し、並行読み出しで高速化)
  • RAID1 – ミラーリング(データを複数デバイスに同じものを書き込んで、データ故障耐性を実現)
  • RAID5 – データを複数デバイスに分散保存する際に、データ誤り訂正のデータも分散保存し、高速化と故障耐性を実現
  • RAID6 – データ誤り補正のデータを複数もたせて、分散保存

リレーショナルデータベースで大量のユーザからアクセスされる場合、データが安全に取り扱うことができたり、システムに障害が発生した時の対応や、システムのスケーラビリティ(利用状況に応じて処理するプロセッサなどを増やしたり減らしたりする機能)が重要となる。NoSQLのシステムでは、中心となるプライマリサーバを作るのではなく、データを複数のシステムに分散して保存し、障害が発生しても、分散したデータから自動的にデータを修復できるような構成とする。

NoSQLのシステムでは、データ格納形式から、キーバリューストア型、カラムストア型、ドキュメントデータベース、グラフデータベースに分類される。最も代表的なものは、保存するデータ(Value)に対し検索するためのキー(Key)だけの基本的なデータ検索だけを提供する キーバリューストア(Key-Value store)である。こういった構成ではSQLとは違い、複数のテーブルをまたがった検索などができない(サブコレクションなどを使えば代用可能)。

Google の Firestore

NoSQLのデータベースを構築したのは、Google が先駆けであった。現在、このGoogle の NoSQL のシステムは、Firestore として利用されている。(データベースはFireBase)

Firestore は、ドキュメントモデルデータベースの一種であり、すべてのデータはドキュメントとコレクションに保存される。ドキュメントは、データベースでのレコードに相当するが、属性名とそれに対応したデータの JSON オブジェクトである。コレクションは、キーにより対応するドキュメントを取り出せるデータ群である。ドキュメントの中に、サブコレクションを保存することもできる。

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー