シェルスクリプトで OS によらず時刻をミリ秒単位で取得したい
シェルスクリプトで何かの処理を実行する際に、その実行にかかった時間を秒単位で計測したい場合は次のように実行することができます。
dt_start=$( date +"%s" )
何かの処理
dt_end=$( date +"%s" )
elapsed=$((dt_end - dt_start))
echo ${elapsed}
それでは、今度はミリ秒単位で計測しようと思って次のように実行してみると、Linux では問題なく計測できますが、macOS では意図通りに動作しません。
dt_start=$( date +"%s%3N" )
何かの処理
dt_end=$( date +"%s%3N" )
elapsed=$(( dt_end - dt_start ))
echo ${elapsed}
この理由は、macOS の date コマンドでは "%N" をサポートしていないためです。Linux では次のように結果を返しますが、
$ date +"%s%3N" 1613896343808
同じことを macOS で実行すると、こうなってしまいます。
$ date +"%s%3N" 1613896453N
このため、別の方法での解決策を考えてみたのですが、perl の Times::Hires を用いればミリ秒単位の時刻を取得できることに気づきました。具体的には次のように実行します。
$ perl -MTime::HiRes -e 'printf("%.0f\n",Time::HiRes::time()*1000)'
1613896697373
したがって、macOS のときだけ上記のように実行したいと考えた場合は、uname の値が Darwin の場合だけ perl を用いるように実装すれば良いでしょう。ただし RHEL, CentOS, Ubuntu でも perl はインストール済みのことが多いと思いますので、環境によらず、この方法でミリ秒単位の時刻を取得できると考えて良いでしょう。
今回の例を上記の方法で書き直すと、次のようになります。
dt_start=$( perl -MTime::HiRes -e 'printf("%.0f\n",Time::HiRes::time()*1000)' )
何かの処理
dt_end=$( perl -MTime::HiRes -e 'printf("%.0f\n",Time::HiRes::time()*1000)' )
elapsed=$((dt_end - dt_start))
echo ${elapsed}
古い MacBook に Ubuntu 20.04 LTS をインストールした際に WiFi が利用できない問題を解決する
MacBook 2009 Early に最新の macOS がインストールできなくなってしばらく経ちますが、Ubuntu 20.04 LTS をインストールして予備マシンとして使うことにしました。しかし実際にインストールしてみると、WiFi が認識されませんでした。
ここでは、その認識のために実施した操作をログとして残します。
実際に実施した操作
Ubuntu 20.04.02 LTS をインストールした MacBook で以下の操作を実施します。
有線LAN、または USB-WiFi アダプタを用いるなどしてインターネット側と通信できるようにしておく必要があります。
私の環境では、Buffalo WLI-UC-GNM2 があったので、一旦、これを使って無線LAN接続しました。
sudo apt update sudo update-pciids sudo apt install firmware-b43-installer sudo reboot
これだけの操作により、OS の再起動後は内蔵の WiFi が利用できるようになりました。
参考にしたページ
以下のページにて、2016 年以降の MacBook Pro での WiFi 接続に関する問題の対処方法が記載されていましたので、これを参考にしました。
macbook pro 2016 以降のモデルでも Ubuntu にて Wi-Fi 接続可能に | ioridev blog
この記事では、reboot を実施後に追加の設定を行っていますが、手元の環境ではそれらの設定は不要でした。
参考: Ubuntu 20.04 LTS を MacBook にインストールする際の手順
手元で実施した手順の項目だけをログとして残します。
OpenWrt 19.07 + asterisk でひかり電話ホームゲートウェイ経由の発着信を設定する
フレッツ光でひかり電話を契約している場合は、ひかり電話ホームゲートウェイと同一の内部ネットワークに接続しているスマートフォンに AGEPhone などの SIP アプリをインストールすることで固定電話の発着信が行えます。
しかしフレッツ光回線で DS-Lite による IPv4 接続を行う場合は、これができません。DS-Lite の場合はひかり電話ホームゲートウェイに DS-Lite 対応のルータを接続し、そのルーターの内部ネットワーク側に PC やスマートフォンを収容します。しかしこの構成だと、ルーターの内部ネットワークからひかり電話ホームゲートウェイに接続する際に NAT が発生します。SIP は NAT を超えることが難しいため、このような構成の場合は SIP クライアントでひかり電話を利用できません。
そこで OpenWrt で構成した DS-Lite のルータに Asterisk を導入し、SIP の接続を中継する PBX を構成した際の設定をログとして残します。
前提の構成
以下の構成を前提に設定しました。
パッケージのインストール
OpenWrt 19.07.x では Asterisk 16 が利用できるので、今回の構成にあたり次のパッケージを追加しました。
libxml2 libcap libedit libsqlite3 jansson asterisk16 asterisk16-cdr asterisk16-chan-sip asterisk16-pjsip asterisk16-codec-ulaw asterisk16-res-rtp-asterisk asterisk16-codec-gsm asterisk16-format-pcm asterisk16-res-agi
基本的な挙動を内線通話で確認する
ベースとなる設定ファイルは、次のページで配布されている Asterisk 13 向けの設定を用います。
この設定ファイルには、内線番号 201 - 208 で相互に内線通話できる設定例が含まれています。また sip.conf では permit=192.168.0.0/255.255.0.0 が設定されているので、Asterisk は Class C Private IP address からの接続のみを受け入れるように設定されています。
そこで、この設定ファイルを適用し、2台のスマートフォンやタブレットに AGEphone をインストールして相互に内線通話できることを確認しておきます。
AGEphone への設定は次のように行います。
ドメイン = OpenWrt の LAN 側 IPアドレス ユーザID = 201 - 208 のいずれかの番号 認証ID = ユーザIDと同じ パスワード = pass
ひかり電話ホームゲートウェイを使用する設定を追加する
Asterisk 経由で内線通話の発着信が行えることが確認できたら、ひかり電話ホームゲートウェイ経由で外線の発着信を行う設定を追加します。
これも基本的には「Asterisk 13 サンプル設定ファイル」で示されている例を参考に修正するだけの簡単な作業です。
ただし、この設定例を用いると、外線発信の際に 0 発信が必要となるため、たとえば 03-nnnn-nnnn の番号にかける際には 003-nnnn-nnnn とダイヤルしなければなりません。これはスマートフォンの電話帳に登録した番号にひかり電話でかけるときに面倒なので、0 で始まる市外局番はすべて 0 発信なしに掛けられるように設定変更します。
以下には作業記録をざっくりまとめました。
extensions.conf
MYNUMBER1に はひかり電話の番号に変更する。[defaults]のexten => _0.,n,Dial(PJSIP/${EXTEN:1}@hikari-trunk)はexten => _0.,n,Dial(PJSIP/${EXTEN}@hikari-trunk)に変更する。(0 で始まる番号はそのまま、ひかり電話でかけるようにする）
[from-hikari] は [from-hikari-hgw] に変更する（他の設定ファイルでも from-hikari-hgw と表記しているため）
pjsip.conf
[hikari-denwa]のserver_uri=sip:XXX.XXX.XXX.XXXは、ひかり電話ホームゲートウェイの IP アドレスを記入する。[hikari-denwa]のclient_uri=sip:X@XXX.XXX.XXX.XXXは、ひかり電話側の内線番号とひかり電話ホームゲートウェイのIPアドレスを記入する（例:client_uri=sip:7@192.168.x.1)password=ultrasecretに、ひかり電話側内線番号の認証パスワードを記入するusername=XXXXは 0007 のように内線ユーザーIDを記入する。context=from-hikariはcontext=from-hikari-hgwに変更する。
sip.conf
[general]セクションにregister => 7:password@hikari-hgwを記入する。次のセクションを追加する。(secret, username, fromuser, domain, host は適切に修正する）
[hikari-hgw] context=from-hikari-hgw type=peer secret=XXXXXXXX username=XXXN fromuser=N domain=192.168.X.1 fromdomain=192.168.X.1 host=192.168.x.1 insecure=port,invite disallow=all allow=ulaw dtmfmode=inband
- 201 から 208 の内線番号のパスワードは適切に変更する。
OpenWrt の試験系を VMware 上に作る
OpenWrt の設定を変更する際に、パッケージの追加を伴う変更を実施した場合は構成を切り戻すのが面倒に感じることがあります。
そこで仮想マシン上で動かす方法を調べてみたのですが、次のページに "OpenWrt on VMware HowTo" という情報がありました。
qemu-img コマンドにより、openwrt-x86-generic-combined-ext4.img から VMDK を生成できるので、この VMDK を新規仮想マシンイメージのディスクとして追加すれば良いようです。
また、これらの方法で作成された OpenWrt 15.05 や 19.07 の ova もダウンロードできます。お手軽にテストしたい場合には ova を使うほうが便利ですね。
自分の環境でも試したい設定や構成がいくつかあったけど、切り戻しが面倒なので躊躇していましたが、VMware 上で動かすことができるならスナップショットが使えるので、気軽に試せそうです。
macOS の JIS キーボードで ¥ キーを押したらバックスラッシュが入力されるようにする
会社からは MacBook Pro を貸与されているのですが、キーボードからバックスラッシュ "\" を入力しようと思って ¥ キーを押すと普通に ¥ が入力されてしまいます。バックスラッシュを入力するには option + ¥ を押す必要があるのですよね。
これはデフォルトの動作として正しいのですけど、なぜか違和感をおぼえていました。
なぜだろうと考えてみたら、実は私用の MacBook では ¥ キーを押すと \ が入力されるように設定してました……。
しかも、その設定をどうやって行っていたのかを完全に忘れています。一度設定したら変更しない部分ですし、おそらく、最初に設定したのは10年くらい前なので、覚えているほうが無理、というものです。
そんなわけで、設定場所を探すのに手間取ってしまいました。滅多にやらない設定項目ではありますが、作業ログとして残しておきます。
- システム環境設定より、「キーボード」を開く。
- 「入力ソース」を選ぶ。
- 「"¥" キーで入力する文字」をバックスラッシュに変更する。
これで設定変更できました。
ESET Cyber Security の macOS Big Sur 完全対応版は3月以降のリリース？
ESET Cyber Security の mac OS Big Sur 対応については、2020年後半に暫定版として V6.10.460.1 がリリースされてますが、完全対応版はどうやら2021年3月以降になるようです。
(※2021/02/28 追記: 2021/2/25 に個人向け製品の Big Sur 対応版がリリースされています。ただし日本語版はまだダウンロードできません。https://pslabo.hatenablog.com/entry/2021/02/27/175234 )
ESET 社のこちらのページによると、 support.eset.com
2021年1月時点では6.10.460.1 以降のスケジュールが以下のように公示されていました。Device control 以外の機能をサポートするバージョンが一旦リリースされたのち、全機能をサポートするバージョンがリリース予定、ということになっています。
| ESET Product version | macOS 10.15 and earlier support | macOS Big Sur support | Release plan |
|---|---|---|---|
| Business - 6.10.460.1 Home - 6.10.460.1 |
Full support | Supported - missing features: |
Released |
| 6.10.y | Full support | Supported - missing features:
|
March 2021 |
| 6.10.z | Full support | Full support | March 2021 |
利用者としては安全側に倒すことを考えるなら、macOS Big Sur 完全対応版を待ったほうがよいのかもしれません。しかし、もうじき macOS Big Sur 11.2 も正式リリースされるという状況なので、部分対応とはいえ 6.10.460.1 との組み合わせで利用を始める、というのはアリかもしれません。ただし手元の環境では macOS Big Sur + ESET 6.10.460.1 の環境を再起動する際に50%くらいの確率で下記の issue が発生します。6.10.460.1 はそういうものだと割り切って利用する必要があります。
ちなみに ESET のライセンスは、デバイス数(1, 3, 5), 年数(1,3) の組み合わせから選べますが、デバイス数が2台以上になりそうなら、5台x3年の一択でよいのではと思います。ライセンスの購入方法はいろいろありますが、キヤノンITソリューションズのサイトは定価販売のため、新規ライセンス購入の場合はリセラーから購入したほうが安価に購入できます。たとえば Amazon ではダウンロード版が5台3年 = ￥7,800、1台1年 = ￥4,500 で購入できます。
既存ライセンスをお持ちは、キヤノンITソリューションズのサイトから延長ライセンスを購入するのが最も適切な購入方法ですし、サイトで更新する以外の手間は掛かりません。
ただし、リセラーの新規ライセンスがセール等で安価になっている場合もありますので、そのような場合は価格面だけを考えれば新規ライセンスを購入したくなります。ただし Amazon のサイトには次の注意書きがありますので、購入したライセンスのユーザー登録は、既存ライセンスの残存期間が終了するタイミングで行うことが必要ですし、これによりアクティベーションキーが変わるならば、アクティベーションキーを各デバイスに再設定する必要があるので、その手間が価格差に値するかどうかを考えて購入方法を決めるのが良さそうです。
●新規(有効期限切れ)購入の方…購入後、画面に表示される案内/通知に従い利用開始登録へ進んでください。有効期間の開始日は、購入日ではなく利用登録日です。
●継続(更新)購入の方…現在ESET製品をご利用の方が、延長目的で購入する場合は再度新規ユーザー登録が必要です。再度新規ユーザー登録をした場合、現在ご利用中の残存期間は無効になりますので、有効期限が迫ったのちに利用登録されることをおすすめします。
約1ヶ月の間に OpenWrt 19.07.05, 19.07.06 がリリースされていたので Security fix の内容を調べる
気がついてみると、OpenWrt 19.07.5, 19.07.6 が短い期間のうちにリリースされていました。とりあえず、主要な Security fix だけ確認してみました。
19.07.5 (2020/12/10)
https://forum.openwrt.org/t/openwrt-19-07-5-service-release/81720 https://openwrt.org/releases/19.07/changelog-19.07.5
Security Advisory 2020-12-09-2 - libuci import heap use after free (CVE-2020-28951)
In order to exploit this vulnerability a malicious attacker would need to provide specially crafted config file to uci_import() C API function. For example, this is possible with UCI CLI by following shell command: uci import -f malicious.config
import するときに悪意のあるパッケージ名が含まれていると、開放したヒープを使われてしまう？
Security Advisory 2020-12-09-1 - Linux kernel - ICMP rate limiting can be used to facilitate DNS poisoning attack (CVE-2020-25705)
musl: fix possible destination buffer overflow in some applications (CVE-2020-28928)
OpenWrt is affected in its default configuration. By default, dnsmasq is used to perform DNS resolution and the firewall allows the kernel to reply with ICMP errors when hosts on the Internet send packets to closed UDP ports. An off-path attacker may use this flaw to more easily perform a DNS cache poisining attack on dnsmasq.
DNS キャッシュポイズニングを受ける脆弱性があるそうです。閉じているはずの DNS ポートに対してインターネット側の攻撃者がパケットを送信することで ICMP エラーがカーネルで発生する、ということらしい。
19.07.6 (2021/1/20)
https://forum.openwrt.org/t/openwrt-19-07-6-service-release/85977 https://openwrt.org/releases/19.07/changelog-19.07.6
Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, CVE-2020-25684, CVE-2020-25685 and CVE-2020-25686) 34
Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment.
こちらもキャッシュポイズニングを引き起こす脆弱性。DNSSEC に関連するメモリ破壊とDNS応答を検証する際の処理に問題があるそうです。
openssl: NULL pointer deref in GENERAL_NAME_cmp function can lead to a DOS attack. (CVE-2020-1971)
これは JPCERT からも緊急情報がでている脆弱性。OpenSSL ライブラリの脆弱性により、SSL/TLS を扱うサーバーとクライアントの両方が悪意のある証明書を取り扱うときに NULL ポインタ参照が発生する可能性があるそうです。 https://www.jpcert.or.jp/at/2020/at200048.html
手元の機材は 19.07.6 に入れ替えることにします。
