Google Home Mini は firewall 内では使えない

Google Home Mini (system firmware version 100429)をiOSアプリの Google Home で設定する場合.

Google Home Mini を無線LANに(routerに)接続するところまでは, インターネット接続不要で実行できる. そこで, Google Home Mini が初期登録のために Googleのサーバに接続しようとするが, firewall内で実行している場合は, そこから先に進めなくなる. なお, この firewall 内にある無線LANでは DHCPwpad で, http, https, socks proxy プロキシが通知されている.

いったん firewall 外に持っていって初期登録を行うと, iOSGoogle Homeアプリで デバイス>設定 メニューが現れるが, ここには手動や自動のプロキシ設定はない.

この後, firewall 内すなわち別の無線LAN下に持って帰ってくると, Google Home Mini は, 初期登録した無線LANがなくなったことに気づいて, 再び自分が router になり, 新しい無線LANへの接続を促す(従って, 無線LANを変更するたびにfactory resetする必要はない). しかし, この場合でも, プロキシ経由の接続はできない.

Google によれば,

Step 1: Disable Access Point/AP isolation, also known as Client isolation or guest mode, on your router

Step 2: Enable UPnP (Universal Plug and Play) also known as Multicast on your router

https://support.google.com/googlehome/answer/7300406?hl=en

とのこと.

store.google.com

macOS 10.13 High Sierra で MacPorts 2.4.1 TeXlive 2017で日本語フォントが使えなくなった → 修復

macOS 10.12 から10.13に上げ, MacPortsmigrate して2.4.1にしたところ, TeXLive 2017のdvidfmx がヒラギノ明朝を扱えなくなった. 何のバージョンを示したらいいか怪しいが, 下のものを使っている.

texlive @2017_0+doc+medium (active)
texlive-lang-cjk @44207_0+doc (active)
texlive-lang-japanese @44377_0+doc (active)

原因は, /System/Library/Fonts 内のフォントファイル名が変化し, /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate からの symbolic link が切れたこと. これらは以前に

sudo cjk-gs-integrate --link-texmf --force

で作ったもの. 再実行すればいいのかもしれないが, 奥村先生の美文書のページを参照させていただいて, 次をターミナルで実行するととりあえず修正できることがわかった. sudo が必要

ln -sf /System/Library/Fonts/"Hiragino Sans GB.ttc" /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate/"Hiragino Sans GB W3.ttc"
ln -sf /System/Library/Fonts/"Hiragino Sans GB.ttc" /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate/"Hiragino Sans GB W6.ttc"
ln -sf /System/Library/Fonts/ヒラギノ丸*.ttc /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate/HiraginoSansR-W4.ttc
ln -sf /System/Library/Fonts/ヒラギノ明*.ttc /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate/HiraginoSerif-W3.ttc
ln -sf /System/Library/Fonts/ヒラギノ明*.ttc /opt/local/share/texmf-local/fonts/truetype/cjk-gs-integrate/HiraginoSerif-W6.ttc
mktexlsr

[改訂第7版]LaTeX2ε美文書作成入門

[改訂第7版]LaTeX2ε美文書作成入門

Mac の R の ggmcmc で「フォントタイプが不正です」エラー → file=NULL とフォント指定で解決

統計ソフトウェア Rのパッケージ ggmcmcは, rstan, rjags rbugs などの MCMCによる推定をするパッケージの収束の様子を trace plot などとして可視化するためのもの.

Mac macOS OS X の R で使ったところ, こうなった.

fit<-rstan(file="model.stan)
ggmcmc(ggs(fit))
> ...
grid.Call.graphics(L_text, as.graphicsAnnot(x$label), x$x, x$y,  でエラー: 
   フォントタイプが不正です

ああ, ggmcmc は ggplot2 を使ってるから, Mac ではフォント設定に注意ね.

fit<-rstan(file="model.stan)
theme_set(theme_bw(base_family="HiraKakuProN-W3"))
quartz(type="pdf",file="plot.pdf")
ggmcmc(ggs(fit))
dev.off()
> ...
grid.Call.graphics(L_text, as.graphicsAnnot(x$label), x$x, x$y,  でエラー: 
   フォントタイプが不正です

あれっ変わらないってどういうこと?

実は, ggmcmcは独自のグラフィックスドライバ(不正確な用語でしょう)を持っているので, 上のようにしても, themeやquartzの設定と無関係に, 独自のドライバで ggmcmc-output.pdf に書こうとしちゃうとのこと. その過程に対してフォント指定できてないからエラーになるのね. file=NULLで明示的に無効化しないといけない.

fit<-rstan(file="model.stan)
theme_set(theme_bw(base_family="HiraKakuProN-W3"))
quartz(type="pdf",file="plot.pdf")
ggmcmc(ggs(fit),file=NULL)  ##### 変更行
dev.off()

pdf 
  2 

NFS Server Debian 9 Stretch から NFS Client macOS 10.12.6 へのNFS Export / NFS Mount したディレクトリ内に resource folk (dot underscore ._ ファイル)が作れず lockd not responding, ビーチボールアイコンになる問題への対症療法

問題の表面的かつあいまいな記述. 具体的な export / mount option は書いてない.

Debian 7 以前から, Debianext3 filesystem を, NFS v3で macOS = OS X に static mount していた. しかし, 次のような不具合が, 両者のバージョンアップとともに発生するようになった.

  • Mount したディレクトリを mac OS の Finder で開き, 日本語の濁点半濁点を含むファイル名に変更/新規ファイルを保存しようとすると, 「そのファイル名は使えません」と言われる
  • Debian 側で Dropbox を動かして, 特定のディレクトリを, macOSの(NFS mountされたものでないHFS+ filesystem 上の)ディレクトリと同期していると「ファイル名(NFS Server ホスト名の競合コピー日付)」という名前で重複してファイルが作られることがある
    • 同時編集(NFS側も含め)しているわけではない

Debian 9 にバージョンアップした直後から, さらに次の問題が発生するようになった.

  • macOS 側で NFS mount されたディレクトリのファイルを Preview.app で編集したり, Microsoft Office でファイルを保存したりすると, busy cursor (ビーチボールまたは砂時計カーソル)となり, 保存できない
    • ターミナルで cp や touch してもこのようなことは起きない
  • この状態で, ターミナルから当該ディレクトリ内のファイルにアクセスすると,
nfs server サーバ名:ディレクトリ名: lockd not responding
nfs server サーバ名:ディレクトリ名: lockd live again

のような警告がでてアクセスできない.

砂時計になるのは,

  • ACL拡張の情報が resouce fork すなわち dot underscore ファイル( ._元のファイル名) に新たに保存されようとするとき,

であるようだ( resource forlk はしょせんただのファイル(名)であるので NFS transparent でないのは不思議に思えるが). このような事象のレポートとして次がある. ファイヤウォール(的にlockdのportが開いてるか)やNFSを確認しろとのことだが.

https://discussions.apple.com/thread/2733032?start=0&tstart=0

これに対する対症療法のひとつとして, NFS client 側で

mount -o locallocks ...

を指定すると解消することがわかっている. 副作用のありそうな療法である.

Debian 8 Jessie から 9 Stretch へ, Moodle 3.1.5+ から Moodle 3.1.7+ へアップグレード

Debian 8 Jessie から 9 Stretch へ, 次いで, Moodle 3.1.5+ から Moodle 3.1.7+ へアップグレードしたときのいくつかの事情の記録.

  • Apache は 2.4.* のままだから問題ない.
  • PHPは5. から 7. に変化する. apt-get update; apt-get dist-upgrade の結果 php5 が消えたので, php(=7のこと)を改めて手動で導入する. 関係ライブラリも, php5-curl のかわりに php-curl を導入, などが必要. 何が足りてないのかわからないので, Moodle も Upgrade して, notification でチェックしてもらうことに(邪道).
  • MySQLMySQL から Mariadb に. データベースは引き継がれる. Moodleの側では, MySQLのバージョンが低いというチェック失敗になる. しかし, default-mysql-server=mariadb のバージョンが低いという意味ではなく, Moodle の config.php
# $CFG->dbtype='mysqli';
$CFG->dbtype='mariadb';

と手で編集する必要がある, という話. * unoconv などは jessie-backports から得ていたが, 自動的に stretch から得るようになったように見える * unoconv は, owner permission 関係で, MoodleDoc に載っているscript で起動することはできていない. HOME=/tmp として, 手動で起動.

追記(2017-09-15)

その後, アップロードファイル上限, MathJax, STACK は手動で調整が必要になった.

数学オンラインテストモジュール STACK 3.5.* を LMS Moodle 3.1 on Debian GNU/Linux 8 Jessie にインストール - hig3の言い忘れたこと書き間違えたこと

数学オンラインテストモジュール STACK 3.5.* を LMS Moodle 3.1 on Debian GNU/Linux 8 Jessie にインストール

概要

MoodleオープンソースのLMS, 数学オンラインテストSTACKはMoodleのQuizのひとつのQuestion Typeであるモジュール.

Moodle 3.1, STACK 3.5.5, STACK-Maxima library 2016082901 を Debian 8 Jessie にインストールしたときに遭遇した困難と解決, STACK 3.5.6, STACK-Maxima library 2016122100 にアップデートしたときに遭遇した困難と解決の記述.

STACK 3.5.5のインストール

インストール手順は

MoodleがインストールされたDebianの場合,

apt-get install maxima gnuplot

で必要なパッケージが追加され, 実行ファイルは /usr/bin に置かれた.

maxima --list-avail
Available versions:
version 5.34.1, lisp gcl
Maxima 5.34.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12 (a.k.a. GCL)

とのことで, GCL=GNU Common Lispdependency でインストールされた.

ところが Health Check

したところ,

CAS result
loadfile: failed to load /usr/share/maxima/5.34.1/share/draw/draw.lisp -- an error. To debug this try: debugmode(true);

FAILED  あなたの要求したMaximaパッケージのいくつかの読み込みに失敗しているようです。このエラーに対する注意については,インストール手順を参照してください。 CASは期待したとおりデータを返しましたが,エラーがありました。

だそうで, draw.lisp がloadできないというエラー. 即物的には, このファイルはあるのか? Pathが正しいか? Owner and Permisson は正しいのか, などと調べ始めるわけだが, そういうことでなく, もっと深く精妙なことで, バージョン依存であるらしい, というのが下のスレッドで書かれている.

上のスレッドでは回避方法として, ライブラリをあらかじめ読み込んで最適化した maxima のイメージを保存すればいい, と言っている. GCLの場合のその手順はここで説明されている.

ただし, Debian では

apt-get build-essential

であらかじめ gcc がインストールされていることが必要. 最後に Moodle のSTACK設定で, maxima コマンドを

timeout --kill-after=6s 6s /path/to/moodledata/stack/maxima-optimised -eval '(cl-user::run)'

と指定しようとするが, このinput formには single quote や paren を書くと正しく認識されないようだった.

に書かれているように,

#!/bin/sh
/path/to/moodledata/stack/maxima-optimised -eval '(cl-user::run)'

だけからなる wrapper shell script maxima-optimised.sh を作成し

timeout --kill-after=6s 6s /path/to/moodledata/stack/maxima-optimised.sh

とすると, Health Checkを通過した.

追記: STACK 3.5.6 へのアップグレード

その後,

cd /path/to/moodle/question/type/stack
git pull

したところ, 正誤判定は正しくされるものの, プレビューでの「正解を表示」fill in right answer 『正解概要」が効かなくなり, 学生にも, 正解は表示されるが正解入力文字列が表示されなくなった.

Health Check したところ,

FAILED   The version of the STACK-Maxima libraries being used (2016082901) does not match what is expected (2016122100) by this version of the STACK question type. Please rebuild your optimised Maxima executable.

というエラーになった. そう, 最適化した maxima イメージは, STACK の update のたびに再生成しなければいけないのだった. 3.5.5 インストール時の手順をやり直したところ, Health Check を通過し, 正解入力文字列も表示されるようになった.

追記: STACK 4.0.1, Maxima 5.38.1, Moodle 3.3.2, Debian 9 stretch へのアップグレード(2017-09-15)

もちろんまた

FAILED 期待されるMaximaのバージョン:"5.38.1"。実際のMaximaのバージョン:"5.34.1" CASは期待したとおりデータを返しましたが,エラーがありました。

FAILED 使用されているSTACK-Maximaライブラリのバージョン (2016122100) はSTACK問題タイプで必要とされているバージョン (2017082400) と一致していません。最適化されたMaxima実行ファイルの再構築を行ってください。

と言われるようになった. こんどは, WebのSTACK設定で, いったんぜんぶ default に戻して, 「Maximaのイメージを作成」ボタンを押すだけで, Unix-optimised になって, ぜんぶ正常に機能するようになった…ように今のところ見えている. STACK4では, テキスト内に書く CAS expression の dellimiter が @exp(x)@ から {@exp(x)@}になったという表面的には大きな変更がある.

iOS iPhone iPad を, スリープボタンを使わずに, タッチスクリーンだけでソフトウェア的に再起動する方法

iPhoneでは, ほとんどの操作はタッチスクリーンで行える. ホームボタンさえ, Accessibility > TouchAssist によってタッチスクリーンで代替できる. 唯一, タッチスクリーンの操作だけで行えないのは, 電源OFF, 再起動.

ちなみにMacでは, 電源OFF, 再起動は林檎メニューからGUIで行えるが, 起動の際にはハードウェアキーボードの接続を促され, ログインの際にはハードウェアキーボードが必要となる(スクリーンキーボードはある).

これを考えると, iOSでタッチスクリーン操作による電源OFF, 再起動を許していないのは不思議. ソフトウェアアップデート後には自動的に再起動することを考えると, APIが存在しないわけでもないはず. 実際, jailbreak 脱獄を要するアプリの中には電源OFF, 再起動を行うものがある.

jailbreak もせず, タッチスクリーンだけでiOSを再起動する, wild でおすすめできない方法だが, 要するに, iOSをクラッシュさせる操作を行えばよい. 例えば執筆時点の最新のiOS 9.2.1 は, Mobile Safarihttp://crashsafari.com にアクセスすると, Mobile Safari の道連れになってクラッシュし, iOSの再起動が発生する. このサイトは, JavaScript で特定のAPIを特定の方法で呼び出して, 再起動を引き起こしているそう. 副作用がないかどうかは保証の限りではないが.