DNS over TLS/HTTPS

昨年から DNS over TLS (DoT)、DNS over HTTPS (DoH) にまつわる動きが急速に活発になっています。

この一文から始まる、以下のリンクを読んだ。

https://eng-blog.iij.ad.jp/archives/2954

関連するこちらを読むと DNS over TLS/HTTPS サービスの提供が増えてきたらしい。
https://public.dns.iij.jp/


パブリック DNS を提供する事業者が増えてきたけど、次期 Android Ver 9 でも DNS over TLS/HTTPS を利用できるようになるらしいし、潮流なんだろうか。

備忘なブレース展開と変数展開

ブレース展開やら変数展開を時々忘れるうえに意味も取り違えてたりするので、備忘代わりに。

ブレース展開

まず、ブレース展開は {} とかで展開する機能。
ブレース(Braces) は { と } の呼称(日本語だと中かっこと呼ぶ感じ)なので、ブレース内をいろいろ触るものと覚えておけば良い感じ。


よく使うのは、次の2通り。


一つ目は、羅列。

# cp /etc/hosts{,_$(date +%Y%m%d)}

これは、次のコマンドに同じ。

# cp /etc/hosts /etc/hosts_$(date +%Y%m%d)

不安な場合は、先に echo しておくと良い。

$ echo /etc/hosts{,_$(date +%Y%m%d)}
/etc/hosts /etc/hosts_20190505

それと2つ目、連続する数字の出力。

$ echo {0..10}
0 1 2 3 4 5 6 7 8 9 10

と書くと、0~10 の数字が連続で出力される。

$ echo {000..10}
000 001 002 003 004 005 006 007 008 009 010

と書くと、000~010 という 0 パディングされた数字が連続で出力される。

$ echo {a..z}
a b c d e f g h i j k l m n o p q r s t u v w x y z

だと、a~z までの小文字だし、

$ echo {A..Z}
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

だと、A~Z までの大文字になる。

途中からの出力 {8..12} や、途中までの出力 {a..f} 等も OK だった。

$ echo {8..12}
8 9 10 11 12
$ echo {a..f}
a b c d e f
$ echo {A..D}{00..15}
A00 A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 A13 A14 A15 B00 B01 B02 B03 B04 B05 B06 B07 B08 B09 B10 B11 B12 B13 B14 B15 C00 C01 C02 C03 C04 C05 C06 C07 C08 C09 C10 C11 C12 C13 C14 C15 D00 D01 D02 D03 D04 D05 D06 D07 D08 D09 D10 D11 D12 D13 D14 D15
$ echo data_{A..C}_201905{01..5}.txt
data_A_20190501.txt data_A_20190502.txt data_A_20190503.txt data_A_20190504.txt data_A_20190505.txt data_B_20190501.txt data_B_20190502.txt data_B_20190503.txt data_B_20190504.txt data_B_20190505.txt data_C_20190501.txt data_C_20190502.txt data_C_20190503.txt data_C_20190504.txt data_C_20190505.txt
$ echo {8..03}
08 07 06 05 04 03

変数展開

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html

これの 「Shell Command Language」内「2.6.2 Parameter Expansion」の部分。
Posix の定義としては「変数拡張」と和訳したほうがヨサゲに見える……
とはいえ、英文から日本語の直訳だと意味が通じにくい部分があるので、ある程度意訳しておく。


以下が、変数展開の記述方法と、その出力結果を意訳したもの。


なお、表名が長いくせに分かりにくいので、先に解説を……
「parameter が Null 以外で設定済」とは、たとえば parameter="A" の状態。定義してあるけど、Null(何もない)以外の状態であるということ。
「parameter が Null で設定済」とは、parameter="" の状態。定義してあるけど、Null(何もない)状態であるということ。
「parameter が未設定」とは、そのものズバリ。まだ定義していない状態。

変数展開記述 parameter が Null 以外で設定済 parameter が Null で設定済 parameter が未設定
${parameter:-word} parameter を利用 word を利用 word を利用
${parameter-word} parameter を利用 null を利用 word を利用
${parameter:=word} parameter を利用 word をアサイ word をアサイ
${parameter=word} parameter を利用 null を利用 word をアサイ
${parameter:?word} parameter を利用 エラー終了 エラー終了
${parameter?word} parameter を利用 null を利用 エラー終了
${parameter:+word} word を利用 null を利用 null を利用
${parameter+word} word を利用 word を利用 null を利用


それぞれの意味は、以下の通り

記述内容 意味
parameter を利用 parameter に定義済みの、値が出力される
word を利用 指定した word で、出力される
null を利用 Null で出力される
word をアサイ parameter に word が代入されつつ、出力される
エラー終了 スクリプトがそこで終了する


ちょっと読み方が特殊だけど、たとえば parameter が Null か未設定のとき、指定した文字列を使いたいというときは ${parameter:-word} を使う。これは、parameter の中身をいじらない。
自分の使い方としては、引数の指定とか。

$ Default="filename"
$ SourceFile=${1:-${Default}}

こうすると、引数の1番目に何も指定されてなくても別途指定しているデフォルト値を利用できる。
もちろん他の使い方もある。

さらに同じ条件だけど parameter の中身に指定した文字列を入れておきたいときは ${parameter:=word} を使う。

#!/bin/bash
set -u
value=$1
num=$((${value:=0} + 1))
echo $num

こんな感じかなぁ?
引数に入力した値の確認とか、計算結果のエラーチェックとか、まったくやっていないけど、使い方があんまり思い浮かばない。もうちょっとマシなサンプルを書ければよかったけど。


それから、変数の中に入っている文字列の長さ(数)を取得する指定は、次の通り。
${#parameter}

$ parameter="example"
$ echo ${#parameter}
7


それから、パターンでの文字列削除方法は、次の通り。

${parameter%word} 最短後置パターンの削除
${parameter%%word} 最長後置パターンの削除
${parameter#word} 最短前置パターンの削除
${parameter##word} 最長前置パターンの削除

パターンにマッチさせる使い方として、ディレクトリを例にする。

SamplePath=/var/log/messages

最短後置パターン(ファイル名もしくは最後のディレクトリ名を消す)

$ echo ${SamplePath%/*}
/var/log

最長後置パターン(この例だと全部消える)

$ echo ${SamplePath%%/*}

最短前置パターン(この例だと最初の / だけ消える)

$ echo ${SamplePath#*/}
var/log/messages

最長前置パターン(ファイル名もしくは最後のディレクトリ名だけ残す)

$ echo ${SamplePath##*/}
messages

ちなみに、ディレクトリ名を消すコマンドに basename がある。
basename コマンドの優位点は、残るファイル名にも加工を掛けられること。
たとえば /usr/local/script/example.sh の、example 部分だけを使いたいとき。

ScriptLog=$(/usr/bin/basename $0 .sh).log

こんな感じで、実行パスからログファイル名を生成するなんてこともできる。


それから、Bash 限定と思われるけど、変数内で置換もできる。

$ Parameter="abce"
$ echo ${Parameter/e/d}
abcd

これは一か所だけなので、全部置換したい場合にはこちら。

$ Parameter="abcefg alphabet"
$ echo ${Parameter//e/d}
abcdfg alphabdt

OpenVPN で RDP 通信 トラフィック計算

自宅に VPN 接続して、しばらく RDP でいろいろ弄っていた。
これは固定回線だから気にならないけど、テザリングを利用した場合にどれくらいになるのか…その目安を知っておきたいとおもって調べてみた。

まずは、自宅のトラフィックを参照してみる。

VPN 用の Raspberry Pi だと、こんな感じ。

f:id:KuroNeko666:20190502131538p:plain
VPN 通信量

インターネット側との通信でも、それほど変化はない感じ。

f:id:KuroNeko666:20190502132057p:plain
インターネット側

ということで、僕の作業だと最大で 2.62Mbps 程度のトラフィックがでるみたい。
それから、これは 5 分間隔の情報であって、bps は秒の単位。
つまり 5 分のうちの 1 秒間に平均 2.62Mbit の通信が発生していることを意味している。

( 2.62 (Mbps) * 60 (秒) * 5 (分)) / 8 (bit) という計算。
だいたい 5 分で 19.65 MBのデータ通信。

さらに計算すると、僕の場合 60 分だと最大で 235.8 MB のデータをやり取りする可能性もある。

5GB/月 の通信量で契約しているので、5,000~5120MB *1 として計算。
5,000 MB / 236 MB = 21.186
最悪な条件で計算すると、21 時間程度しかもたない計算。

うわー……

いや、最悪な条件での計算だからもう少し余裕はあるけど、RDP での接続は最低限で済ませられるようにしておいた方が心にも余裕がでるね。

6月に入院生活を送る予定があるから、なおさら。

*1:Byte計算のとき、1024 か 1000 かで変わる。PC だと 1,024 だけど、通信の世界では 1,000で固定

UWSC - ログ出力 (logger) 関数を定義

ときどき、自宅で UWSC を使うのだけれど、たまに使いまわしたい関数があるので備忘的に記録。

 次の関数は、print 文で出力するもの。

function logger(String)

// ログ出力

GETTIME()
    date = "" + G_TIME_YY4 + "/" + G_TIME_MM2 + "/" + G_TIME_DD2
    time = "" + G_TIME_HH2 + ":" + G_TIME_NN2 + ":" + G_TIME_SS2
    Print date + " " + time + " " + String
    Result = 0
fend

使い方は、こんな感じ

    logger ("ログ出力したい文字列")

> 自分への課題
・秒の単位は、1桁~2桁で揃わないので、あとで桁あわせをする処理を追加しておく。
→ 変数名を G_TIME_SS から G_TIME_SS2 に変更するだけで良かった。
・print 文で出力したものは、一度停止したあと、また起動したときに消えてしまうのでログファイルに追加するように処理を変更する。

今回は時間がないなかったので、これで。

追記。
実際にファイルへ追記しているタイプの logger を作成。
出力パスは、dim で定義してもダメみたい。
Const で定義してから function を使うか、logger 関数内部で定義するかしないと、出力されなかった。

Const sLogDir = "c:"
Const sLogFile = "uwsc.log"
Const sLogPath = sLogDir + "\" + sLogFile

logger ("サンプル")

function logger(String) 
	// 実行時刻の取得
	GETTIME()
	date = "" + G_TIME_YY4 + "/" + G_TIME_MM2 + "/" + G_TIME_DD2
	time = "" + G_TIME_HH2 + ":" + G_TIME_NN2 + ":" + G_TIME_SS2

	// ファイルを開く
	fid = FOPEN(sLogPath, F_READ or F_WRITE)

	// ログ出力実行
	FPUT (fid, date + " " + time + " " + String)

	// ファイルを閉じる
	FCLOSE(fid)

	Result = 0

fend

注意点としては、ディレクトリが存在しないとエラーで終わるよっていうこと。ディレクトリの有無を確認するエラー処理を入れると汎用性が増す気はする。
個人が使うスクリプトが、そんな前提情報を満たさない*1とかありえない気もするのでエラー処理はいれていない。

*1:必要なディレクトリなら、実行前に自分で作っておくよね?

工作

前日のヘッドライト取り付け作業。

 

まずは、ステーの穴あけ。

f:id:KuroNeko666:20190414120301j:plain

金具(ステー)の穴あけ

8mmの穴と、10mmの穴をそれぞれ。

 

 

f:id:KuroNeko666:20190414120901j:plain

既存ヘッドライト取り外し

既存のヘッドライトを取り外す。

並べてみる。

f:id:KuroNeko666:20190414121231j:plain

ヘッドライトの大きさ比較

もう少し置く位置を調整すれば良かったかな。

左が新しく付けようとしているヘッドライトだけど、細身かつ長い。

f:id:KuroNeko666:20190414131156j:plain

仮設置

配線加工前に、仮設置。

やっぱり奥行がギリギリ。

 

f:id:KuroNeko666:20190414140005j:plain

エンジン始動時のヘッドライト

さくっと配線加工を終わらせて、エンジンをかけてみる。

配線自体は、同色のケーブルをギボシ端子を使って繋いであげるだけなので、特筆することなし。

光の向きは、夜にならないと調整できないな……。

f:id:KuroNeko666:20190414142637j:plain

取付完了

取り付けのために外していたカバー類も戻して、取り付け完了。

 

夜になってみて光り方を確認してみたけど、Hi と Lo が逆だった……。

中の LED を180度回転させたけど、うーん……。

狙ったところに光が当たらない。

Lo は、光を当てたいところの下側で、Hi は、光を当てたいところの上側。

なんぞこれ。

 

イメージ的には、こんな感じ。

f:id:KuroNeko666:20190423070820p:plain

光の当たり方

上のものが、ノーマルの照射範囲。

今回付けたのは、下のような照射範囲をしていて、使い難い。

 

常に Hi がちょうどいい場所で使うために、Lo は足元を照らしているような位置で固定。

いいや。Hi / Lo なんてなかったんや。

同じ 30/30w でも、今までよりは明るく感じる。

ただ、アイドリング時には明滅するような挙動をするし、オススメはできないかな。

 

他に良い点としては、ノーマルに比べて各段に整備しやすい。レンズを外す作業なんて、深く考えずにネジを回せるのがいいね。

Magna50 へのヘッドライト取り付け案

Magna50 自分メモ

手持ちのヘッドライト

 

 

これに、バイク用LEDランプを取り付けたい。

 

 

すでに両方とも持っていて、ヘッドライトには LED ランプをむりくり内蔵させた。

配線を少し加工すれば、光らせることが出来るのは確認済み。

 

で、このヘッドライトを Magna50 に取り付けたい。

下調べしてみた。

f:id:KuroNeko666:20190413212531p:plain

ノーマルヘッドライトの取り付け図

うん。取り付けられているネジは、8mmだった。

でも取り付けたいヘッドライトは、取り付けネジが 10mm のもの。

f:id:KuroNeko666:20190413212652p:plain

取り付けたいヘッドライト

Magna50 のヘッドライト取り付け部分のネジ穴は、8mm しか入らない。

取り付け穴を 10mm まで拡張したところで、約 165mm と示されているライトは長すぎて本体に干渉する。

 

じゃあ、どうしようか。

f:id:KuroNeko666:20190413212733p:plain

自作ステーの構想図

ステーを自作するしかないでしょう。

 

ということで、今日は自作ステーに出来そうな金具を探してたら夜に……

工作は明日やろう。

 

一応、良い感じの L 字型金具を見つけたので、これで試そう。

配線も少し加工しないとなぁ……

 

謎なトラフィック

4/10 23:00 から続いていた、謎のトラフィック

気になって、4/13 00:00 頃に Wi-Fi ルータの電源を切った。

 

この期間、日中は仕事で家にいなかったのでスマホは繋いでいないし、自分が何か接続してたとかは無かった気がする。少なくとも、Wi-Fi に常時繋いで何かする機械は置いた記憶がない。

 

というか。

自分が寝ていた時間に My docomo へログインしたという通知が来て、怪しいアクセスを探していて妙なトラフィックを見つけた次第。

それで電源を切ってからトラフィックが消えたので、Wi-Fi に誰かが不正アクセスした可能性まである。

困ったね。

とりあえず、My docomo のパスワードは変更しておいたけど、パスワードが漏れてたら嫌だなぁ。

パスワード管理ソフトに登録しているアカウント数が、もう 100 を超えてるんだよ。

 

閑話休題

 

トラフィック自体は、ワイヤレスLANから入ってきているのが分かる。

f:id:KuroNeko666:20190413124542p:plain

謎のトラフィック

スイッチから見て、ワイヤレスLANから入ってきた(Inbound)トラフィックは、そのまま PC や Internet へ抜けていた (Outbound)。

 

f:id:KuroNeko666:20190413125216p:plain

PC側へのトラフィック

 

メインPC側で、期間の前から 4/12 1:00 頃までずーっと続いている Inbound トラフィックは、NAS にある画像のまとめファイル(zip)を、Honeyview というソフトで開きっぱなしにしていたので見えているもの。貼り付けはしないものの、NAS 側へのトラフィックと合っているので問題なし。このソフトが何を読みこんでいるのかは興味あるけど、またそれは別の話。

メインPC側も、インターネット側も、(Inboundが見えないくらい) 入ってきていないので、そちらからのアクセスではないことは分かる。

f:id:KuroNeko666:20190413125349p:plain

インターネット側へのトラフィック

小さいトラフィックはあるけど、Windows 端末は自分のアクセスに備えて常時起動しているし、メールクライアントが定期的にメールチェックをしているので、多分それだろう。

直近の大きな山は自分のアクセスであることを認識しているので、問題なし。

動画って、大きいよねぇ……。

 

Wi-Fi ルータからのアクセスであることは間違いないと思っているけど、それがどんな種類のアクセスなのかは、現状では謎。

Wi-Fi ルータの自動アップデート?

何年も設置してるけど、いままでそんな兆候はなかった。

むしろ経年劣化で壊れた?

その可能性は否定できないな……。

 

しかし、自宅に Wi-Fi がないと不便だね。

新しいものを購入するか?