ホーム » スタッフ » 斉藤徹 » 産学共同

産学共同」カテゴリーアーカイブ

2021年9月
 1234
567891011
12131415161718
19202122232425
2627282930  

最新の投稿(電子情報)

アーカイブ

カテゴリー

緊急連絡システムにSendGridを使ったら

丹南地区の緊急連絡システムを動かしているけど、最近はメールが届かないといった連絡を受けることも多い。

2021/09/10 については、docomo.ne.jp 宛のメールの配送でトラブルが発生し、設定を見直すことで無事に配送ができるように復旧することができました。

基本的に無料で提供しているサービスだけれど、Azure のサーバから送信すると、迷惑メールの送信者と誤認される可能性が高く、最近のキャリアではメールが届かないなどの問題が起こりやすい。

正しく配信されるようにするために、サーバを信用してもらえるような構成にすることも考えられるが、設定のメンテナンスの負担も懸念される。そこで、Azure サーバでメールを配信するための、有料サービス SendGrid を使うことを検討してみた。

最初に、有料システムを利用することになるので、どの課金体系を利用するのかを判断するために、現在の緊急連絡システムの月別のメール流量を集計してみた。この結果、最近ではコロナによる連絡も多いのか平均4万通/月のメールが流れている。多い時には、10万通を超える場合もある。(下図参照)

これを、元にSendGrid を使った場合の費用を算出してみる。一番安い料金 “Essencial 4k” では、1900円/月 (4万通/月,これ以上は、0.125円/通)、”Essencial 10k” では、3800円/月(10万通/月, これ以上は0.094円/通)となる。これを見ると、現状の平均 4万通 からしても Essencial 4k を採用すれば、約 年額 45,000 円 以下に収まると思われる。(下図参照)

 

ゼロトラスト研究会

EVER/IPのコネクトフリーさんが、鯖江市・越前市・福井県・地元企業と協力して、EVER/IPの活用を見いだすためのゼロトラスト研究会が行われました。

{CAPTION}

ゼロトラストとは

  • LANなどの小さなネットワーク内を安全とする境界型セキュリティから脱却し、世界中のコンピュータを結ぶ。
  • 境界型セキュリティの限界。LANの中でも信用しないという考え方

IPv6

  • IPアドレスの詐称の可能性がある

EVER/IP

  • Advanced Security
  • Autonomous Networking
  • Authenticated Connectivity
  • 公開鍵暗号。公開鍵のハッシュがIPアドレス
  • ゼロタッチプロビジョニング

自治体ネットワーク、三層分離の見直し

  • 自治体の3層構造
    • 個人番号利用事業系
    • LGWAN接続系
    • インターネット接続系
  • LGWAN系、インターネット接続系に、リモートワークシステムが接続するには。

Paiza Cloud 使ってみるか

先日、教えてもらった Paiza.io だけど、PHP の中に JavaScript を交えても動くけど、form + onsubmit を使うようなプログラムだと、ちょっとうまく動かない。

こういう時は、Paiza Cloud を使えばいいみたい。24時間の間であれば、無料で仮想サーバを借りて使うことができるみたい。24時間経つと、ファイルは消されちゃうみたいだけど、簡単な講習会だったらこれで十分だろう。

paiza.io 便利だね

講習会の講師依頼があり、プログラミングの基礎を教えることになったけど、場所が学内でもないため、どういった準備をすべきか思案中。

それなら、paiza.io を使ってみたらとの情報をもらう。

https://paiza.io/

これなら、C++, PHP, JavaScript の動作検証も簡単かな。PHPのコードの中に、JavaScript を埋め込んでもそれなりに動くな。

入力のある JavaScript を動かす簡単なプログラム例

<html>
  <head>
    <title>
      じっけん
    </title>
    <script>
      function my_exec() {
        let a = document.getElementById( "a" ).value ;
        let b = document.getElementById( "b" ).value ;
        let c = document.getElementById( "c" ) ;
        c.value = parseInt( a , 10 ) + parseInt( b , 10 ) ;
        return false ;
      }
    </script>
  </head>
<body>
  <h1>たいとる</h1>
    <form method="POST" action="zz.php" >
      <input type="text" name="a" id="a" />
      +
      <input type="text" name="b" id="b" />
      =
      <input type="text" name="c" id="c" />
      <input type="button" value="BUTTON" onclick="my_exec()" />
    </form>
  </body>
</html>

<input type=”submit” … /> とか、<form … onsubmit=”my_exec()” > を使うと、ページ遷移が発生するので、paiza.io の環境では、動かなくなる。<input type=”button” onclick=”my_exec()” /> を使えば、大丈夫。

サーバ廃棄に伴うHDD物理破壊

総合情報処理センターに、置いてあった私管理の、もう稼働してないサーバを廃棄。

個人情報の入っていたサーバなので、契約係の人にHDDは確実に破壊して…と言われたので、ドリルで貫通穴開けました。(^_^)

重要な個人情報の入ったサーバのHDDは、いつもこんな感じで廃棄になります。

{CAPTION}

{CAPTION}

{CAPTION}

緊急連絡システムのicloud問題解決

緊急連絡システムを運営しているけど、最近 icloud.com 宛のメールが届かないといった問題が発生していた。

いくつかのサイトでは、MXレコードを引く際の DNS の情報が大きい場合、qmail が失敗するなどの情報から、対処などを施していたが、icloud の配信でこういった症状が出ていた。

色々と調べてみたが、icloud.com は、メールの X-Header が含まれると、受信を拒否するのが原因ということが見えてきた。

緊急連絡システムでは、トラブルが発生した際の履歴を追えるように、X-EMC-…. という拡張ヘッダを埋め込んでいた。

今回、icloud.com, mac.com, me.com のメールアドレスの場合は、X-EMC- を付けないように処理を加えたところ、無事にメールが送信できることが確認できた。

しかし、こういうキャリア毎の事情は、わからないわ…(x_x;;

緊急連絡システムでrblsmtpd

メモ:緊急連絡システムで、迷惑メールが届いている。変なリレーはされていないけど、エラーメールが配送できずに溜まってる。

設定を改めて確認して、迷惑メール対策が弱いのでブラックリストなメールサーバからの受信をしないように、rblsmtpd を導入。rblsmtpdの設定は、以前の運用経験からすぐに設定できるかと思ったけど qmail が systemd 用に設定ファイルが変わっているので、修正場所を探すのに手間取った。

icloud.com メールが届かない

qmail の DNS 512byte パケット問題のパッチをあてたものを使っているつもりだが、また緊急連絡システムのメールQueueが icloud.com 宛のメールで埋まっていた。

そこで、参考記事(icloud.comやme.comやhotmailにメールが届かない時)を参考に以下の設定を行った。

mail.add_x_header

(( /etc/php/7.0/apache/php.ini ))
mail.add_x_header = Off

smtproutes

(( /var/qmail/control/smtproutes ))
icloud.com:     mx1.mail.icloud.com
me.com:         mx1.mail.icloud.com
nifty.com:      smmx.nifty.com
hotmail.com:    mx1.hotmail.com
:

((2018/11/30))
icloud.com の情報を smtproutes に書き込んで、メールが流れるようになったけど、改めて確認したら、me.com 宛が詰まってた。”me.com:mx1.mail.icloud.com”を追加。

緊急連絡システムのOS更新など

緊急連絡システムのOSが、Ubuntu/trusty でそろそろ、サポート期間に近づいているので、OS の更新を行った。

Ubuntu 更新

更新自体は、do-release-upgrade コマンドで、xenial に更新が進む。

$ sudo do-release-upgrade

しかしながら、openssh-server が、更新でエラーがでて、かなり悩んだ。解ってみれば、単純なミスで、自作の /etc/init.d/script を書いてあったけど、その insserv ヘッダで、ssh をコピーしてヘッダ部の # Provides: sshd の行を書き換えてなかった。

このおかげで、insserv が、ssh はすでに登録されている…と勘違いしていた。

緊急連絡システムの文字コードUTF-8 に変更

Ubuntu の更新をかけたら、php5 が使えなくなったため、php7.0 に更新を行うが、これに合わせ、取り扱い文字コードを EUC-JP から UTF-8 に変更を行った。

緊急連絡システムは、内部でデータベースを利用せず、テキストファイルですべてを管理しているが、最初は利用組織毎の設定ファイルや、データファイルをエディタでチマチマと修正を始めたけど、大量の組織のため、途中で断念。perl でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。

あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。

xenial の snapd いるの?

以前から発生していた、Ubuntu のサーバで snapd がうまくインストールできないトラブル。 install しようとすると古いバージョンを削除するときの prerm script でエラーとかいうメッセージがでるので、/var/lib/dpkg/info/snapd.prerm を編集して、エラーの出る処理の前に exit 0 を入れたりしながら、無理やり削除して、インストールを試みるけど、こんどは、postinst でエラー。

原因がつかめずに、四苦八苦していたけど、「バージョンアップして trusty を使っているなら、/etc/apt/sources.list などの中にある xenial 関係を消せ」という記事を見つける。

まさに、xenial を upgrade した trusty だったので、/etc/apt/ を探すと、php 関係のパッケージで、

deb http://ppa.launchpad.net/ondrej/php/ubuntu xenial main

というのが見つかったので、早々に消してみた。その後、”aptitude update ; aptitude safe-upgrade” を実行したけど、特にパッケージが消されたりもしなかったし、これで OK かな。