2020年1月 – ページ 2 – OSAKANA TAROのメモ帳

GL.iNet GL-MV1000をバッファロー WSR-2533DHP2-CBのルーター機能の代わりに導入した。

うちはいまだにフレッツ光ネクスト+IPv6オプション環境なので、どうなるかなぁ？と思ったら標準設定ではIPv6での接続がうまくいかなかった。(注:BIGLOBE側の契約表記が「Bフレッツマンションタイプ」のままなんだけど、フレッツ側の契約を確認してみるといつの間にか「フレッツ光ネクスト」に切り替わっていた)

どうすればいいのかな？とググったら「フレッツ光 + OpenWrt で IPv6 を使う」に書いてある通りのことで対応できた。

GL.iNet GL-MV1000の標準状態で DHCPv6 クライアントの設定までは行われていたので、 /etc/config/dhcp のファイルを編集するだけで済んだ。

変更するためにはsshでアクセスして、rootユーザでログインすればOK

#初期状態
＜略＞
config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option force '1'
	option dhcpv6 'server'
	option ra 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'
＜略＞

lanのところのdhcpv6とraの「server」を「relay」に変更し、ndpを追加

wan6を新規で追加し、項目を追加

# BフレッツIPv6対応
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option force '1'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config dhcp 'wan6'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'
        option master '1'

参考にしたblogだとコマンドで「uci commit /etc/config/dhcp」を実行すればOKとあったが、うまく行かなかったので、ルータを再起動したところうまくいった。

なお、手動で変更したあと、luciのGUIを確認してみたが、変更された項目はなかったので、「 Powered by LuCI openwrt-19.07 branch (git-19.218.48058-9177466) / OpenWrt 19.07-SNAPSHOT r10273-2b88d02」「GL-MV1000 version 3.027」ではGUIの変更ができないようでした。

2020年1月16日2020年9月2日

ONTAP9でボリューム削除して再作成しようとしたら空き容量がないと言われる

Check

NetApp ONTAP8 7-modeで使用中のボリュームがあり、それをNetApp ONTAP9.5環境に対してtransitionのsnapmirrorを行った。

が・・・元ボリュームがqtree snapmirror中であったため、最後の処理で失敗した。(event log showの結果より)

1/14/2020 05:52:49  netapp95         ERROR         smc.snapmir.init.fail: Initialize from source volume 'netapp7mode:vol211' to destination volume 'netapp95svm:vol211' failed with error 'Transfer failed.'. Relationship UUID 'a3555a83-3360-11ea-a0b6-00a098f844df'.
1/14/2020 05:52:49  netapp95         ERROR         replication.dst.err: SnapMirror: destination transfer from netapp7mode:vol211 to vol211 : replication transfer failed to complete.
1/14/2020 05:52:49  netapp95         ERROR         snapmirror.dst.OnlineErr: SnapMirror not able to bring destination volume vol211 online, CR_TRANS_QTREE_REPLICA.
1/14/2020 05:52:46  netapp95         ERROR         wafl.voltrans.qtree.replica: The source of volume vol211 is a qtree replica. It cannot be transitioned to clustered Data ONTAP.

これについては、元のボリューム(netapp7mode:vol211)が受け側となっているqtree snapmirror全てに対して、「snapmirror quiesce netapp7mode:/vol/vol211/～」と「snapmirror break netapp7mode:/vol/vol211/～」を実行し、snapmirrorのステータスが「Broken-off」であれば7mode→ONTAP9へのtransition snapmirrorが成功することを確認。

で、snapmirrorの初期化(snapmirror initialize)にした場合、受け側のボリューム(今回はnetapp95svm:vol211)を削除して、再作成する必要がある。

netapp95上で「snapmirror delete -destination-path netapp95svm:vol211」でsnapmirror登録を消した後、ボリュームを「volume offline -vserver netapp95svm -volume vol211」でオフラインにしてから「volume delete -vserver netapp95svm -volume vol211」で削除。

そして、「volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP」で作成！

netapp95::> volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP
[Job 351] Job is queued: Create vol211.                                        

Error: command failed: [Job 351] Job failed: Failed to create the volume on
       node "netapp95svm". Reason: Request to create volume "vol211" failed
       because there is not enough space in aggregate "aggr名". Either
       create 10.9TB of free space in the aggregate or select a size of at most
       11.2TB for the new volume. 
netapp95::>

おや？

netapp95::> storage aggregate show
Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
--------- -------- --------- ----- ------- ------ ---------------- ------------
＜略＞
aggr名 
           29.41TB   11.29TB   62% online       2 netapp95svm      raid_dp,
                                                                   normal
＜略＞
netapp95::>

まだ使用中という認識になっている？？？

いろいろ調べた結果、ONTAP 8.3より導入されたVolume Recovery Queueにより、削除したボリュームは１２時間残しておく、という機能によるものだった。

・How to use the Volume Recovery Queue feature in clustered Data ONTAP 8.3
・How to enable the volume recovery queue in clustered Data ONTAP 8.3
・After deleting a volume, the volume is brought offline with type DEL

強制的に削除するにはdiagモードにあるvolume recovery-queue purgeを使用する。

netapp95::> set diag 
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

netapp95::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
netapp95svm vol211_1032_1032 
                      Thu Jan 16 14:33:18 2020               12

netapp95::*>

上記の「volume recovery-queue show」で現在保持している削除したボリュームを確認できる。

削除は「volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032」というような感じで実行する。

netapp95::*> volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032 
Queued private job: 251                                                        

netapp95::*> volume recovery-queue show
This table is currently empty.

netapp95::*>

消えたのでaggregateは復活したはず！！！

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
＜略＞
aggr名                    29TB       18TB       11TB      61%
aggr名/.snapshot            0B         0B         0B       0%
＜略＞
netapp95::*>

あれ？？？？

なぜだろー？？

なぜだろー？？？としばらく検索してから、再度実行

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
＜略＞
aggr名                    29TB       16TB       12TB      57%
aggr名/.snapshot            0B         0B         0B       0%
＜略＞
netapp95::*>

おや？空き容量が少し増えてる？

「df -A」の実行に切り替えてみると、徐々に空き容量が増えていっていることが判明。

どうやら内部処理に時間がかかっているだけのようでした。

ちなみに別件でトラブった時にサポートに聞いたら、この徐々に空き容量が増える、という内部処理を無くすことはできない、とのことでした。

2020年1月7日

ワコムの廉価液タブWacom Oneの使えるペンとAndroid対応機種

Check

ワコムからEMRペン採用の廉価液晶タブレットWacom Oneが出るそうで

・製品ページその１
・製品ページその２

ワコムの比較的廉価ラインや他社WindowsタブやAndroidタブで使われるWacom Feel IT technologysのうち、EMRペン(電磁誘導方式ペン)を採用しているとのこと。

(AESペン/ アクティブ静電結合ペンではない)

EMRペンは、ドスパラが出した絵描き向けWindowsタブレットraytrektab とか、CES2020で発表されたAcerの絵描き向けタブレット(Acer、イーゼルヒンジ採用のクリエイター向けPCなどのクリエイター向けのConceptDシリーズ)とかで使われている。

数年前まではAESペン採用例が多かったけど、最近のワコム採用タブレットというとEMRペン採用例が多いような気がする。

Amazonで簡単に買えるあたりだと↓のような感じ

Samsungスマホ向けの以下も使えるはず。

で、今回のWacom Oneは一部のAndroidでも使えると記載されているのでどんな機種か確認・・・

SamsungとHuaweiの一部のみ対応？？

Androidスマホを液晶につないでパソコンみたいにつかう？

そういえば、SamsungもHuaweiもそういったオプションを提供しているぞ、と確認

「HUAWEI MateDock 2対応機種」

Compatible devices with the HUAWEI MateDock 2
The HUAWEI MateDock 2 is compatible with devices with USB-C and DP ports and supports wired projection. The following phone, tablet, and laptop models are compatible with the HUAWEI MateDock 2: HUAWEI P20 series, HUAWEI P30 series, HUAWEI Mate 10 series, HUAWEI Mate 20 series, HUAWEI Mate RS Porsche Design series, HONOR V20 series, HUAWEI MediaPad M6 10.8″, HUAWEI MateBook series, and HONOR MagicBook series.

「Samsung Dex Station対応機種」

Samsung DeX device requirements
Mobile Device: Samsung Galaxy S8, S8+, S9, S9+, and Note 8, Note 9, and Tab S4.

Samsungのリストの方はちょっと古いけど、だいたい重複している。

おそらく、Android本体のディスプレイとペンタブ部分を同時に使える機能を実装しているのは、こういった特殊なオプションを用意しているメーカ以外にはないと思うので、これから先もおそらくSamsungとHuaweiの高い機種以外での対応は増えないでしょうね。

もう１つ気になる点は、Wacom Oneとパソコンを繋ぐケーブルについて

こんな感じの液タブ側はType-Cと同じ形状で、そこから３つに分かれたケーブルになり、１つは電源用USBコネクタ、１つはパソコン接続用のUSBコネクタ、１つはディスプレイ出力用のHDMIコネクタとなっている。

この形状、実は中華タブ系統では以前から見かけるものなんです。

たとえば、HUIONのKAMVAS Pro 13 GT-133/Pro 12 GT-116で使われているケーブルはこんな感じ。

Type-C形状のコネクタがL型配置になっているという点も同じですね。

これ・・・もしかして、同じケーブルだったりしますかね？

ちょっと気になるところですが、単品販売が見つからないので試せないですね・・・

どうなんだろうなぁ・・・

2020年1月6日2022年9月2日

会津バスのスマートバス停を見てきた(PAPERCAST製品利用例

Check

2018年2月に会津バスでスマートバス停が実証試験を始めるというニュースがあった。

(注: 2022年5月時点では物理的に設置はされているものの稼働していませんでした。詳しくは後述)

インプレス:「会津バスに「スマートバス停」、KDDIなど導入支援――LPWA・電子ペーパー活用で外部電源不要」
みちのりホールディングズ:「みちのりホールディングス（会津バス）など会津若松市内で国内初となる次世代スマートバス停の実証実験を開始」
会津バス:「会津若松市内で国内初となる次世代スマートバス停の実証実験を開始します。」

2018年2月17日より運用を始め、設置した２種類をベースに新しいものを2018年4月から１年間で開発する、的なリリースになっていた。

さすがにもう無くなったかな？と会津バスのtwitterアカウントに聞いて見たところ、実用化に課題があるため実証期間を延長し、まだ運用されているとの回答をもらったので見に行ってみた。

レスが遅くなりまして申し訳ございません。２か所に設置したスマートバス停は現在も使用しておりますが、実用化にはまだ課題が残っているため、実証期間を延長しております。
— 会津乗合自動車（会津バス）【公式】 (@aizubus) November 13, 2019

まず、見に行ったのは神明通りバス停。

ちょっと離れたところから、会津若松駅方面のバス停をみたところ、なさそうに見えたので、TSUTAYA前の鶴ヶ城方面のバス停を見てみる。

めっちゃ普通のバス停しかない。

おやー？と思ってもう１回会津若松駅方面のバス停の方を見てみると・・・

おや？奥にもう１つバス停がある？

ありました。

２連タイプのバス停です。

ただし、バスロケーションシステムは稼働していませんでした。

まず、時刻表の表示位置が低すぎるのと、文字が細すぎるの２点があるため、バス停の前でしゃがまないと時刻表を読むのが困難でした。

そして、しゃがんでもなお、注意書きとか細かな経路違い表示とかの文字が小さすぎるし、文字の濃淡が薄すぎて読めない・・・

スマートバス停の後ろ側に普通の時刻表がありましたが、こっちのがハッキリしてて見やすいですね。

横に出てるのはLWPAのアンテナなのかな？

ここについているカメラは何の役割なのかな？

バス停の前に立ったらE-Ink表示のリフレッシュが走ったので人感センサーを兼ねてたりするのかな？

時刻表の下にある銀色の丸スイッチを押すと画面のリフレッシュ処理が実行されました。

続いて、鶴ヶ城入口のバス停まで移動・・・

こちらは会津若松駅から来るバスが止まるバス停にありました。

こちらの１画面タイプは、時刻表の表示位置も適切で、表示内容も比較的見やすい感じでした。

よこからみるとこれくらいの大きさで、まぁ、実際に設置するならこれくらいがいいんじゃないかなぁ、と感じました。

こちらのバス停は「PAPERCAST」というロゴが入っていました。

調べて見ると「PAPERCAST E-Paper Bus Stop Passenger Information Display」という既存製品でした。

２画面タイプのもとになっているのでは？というものもありました。

元々WiFi/3G/LTEモジュールを組み込む前提の製品なようで、会津バスで導入するにあたり、LWPAモジュール連動と日本語表示カスタマイズを行ったようです。

PAPERCAST掲載のサンプル例には、日本のマス目レイアウトの１日の全体を表示するような時刻表は無く、次のバスまで何分、というものばかりでした。

Need a smaller e-paper display for installation in smart bus shelters, totems or kiosks, or for low-frequency bus stops? #BusStop #PublicTransport #EPaper https://t.co/dzj4C5T6O7 pic.twitter.com/JiH4tc44AF
— Papercast (@PaperCast_net) December 30, 2019