2018/05/20

Homebrew の auto-update を止める

いつからか、Homebrew が upgrade や install の際に auto update をするようになりました。
しかし毎回 update が走るのは煩わしい。
特に連続で何かを install する時などは「さっきも update したじゃん」となります。
なので auto-update を止めました。


環境

  • macOS Sierra: 10.12.6
  • Homebrew 1.6.1-7-g6233b9d
  • Homebrew/homebrew-core (git revision 9623af; last commit 2018-04-16)
  • zsh: 5.5 (x86_64-apple-darwin16.7.0)


HOMEBREW_NO_AUTO_UPDATE を set

とはいえやることは環境変数を追加するだけです。
  • export HOMEBREW_NO_AUTO_UPDATE=1
あたりを .zshrc に追記
これで煩わしい auto-update を無効にできます。
あと、 man brew を読むといろいろと環境変数に指定できることが分かります。が、今はこれだけで良いかな。


参考

2018/05/13

Ubuntu 16.04 に CUDA を install する

過去に CentOS7 に CUDA 環境を構築したことがある のですが、Ubuntu 16.04 上にも構築してみたのでそのログ。


環境

  • Ubuntu: 16.04
  • CUDA: 9.1

Install

手順は公式のドキュメントが懇切丁寧に解説しています。
指示された通りに
  • # apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
  • # wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
  • # dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
  • # apt update
  • # apt-get install -y cuda cuda-drivers
したらおしまい。
ダウンロードは 1.3GB とかかな。使う disk は 4GB くらい。
特に問題も無く構築できたので良きかな良きかな。


参考

2018/05/06

ssh した先で GUI Application を起動する

前回の記事では IP Reachable であれば DISPLAY を設定することで GUI Application も動く、と書きました。
ssh に関して言えば、もっとスマートな解決方法があったようです。


ssh と -X -Y option

man ssh を見ると、 X11 に関するオプションがいくつかありますね。
特に X11Fowarding が yes で -X か -Y を付けると
  • The DISPLAY value set by ssh will point to the server machine.
とのこと。勝手に DISPLAY を設定してくれるっぽい。便利。

X11Fowarding option は sshd_config の方(サーバ側)の option で見たことがあります。
なるほど、ここで使うのか(というか ssh した状態で GUI 使うって発想がそもそも無かった……)。


-X option with ssh proxy

-X や -Y の方が優れている点として、ssh proxy を通していても GUI が使える点があります。
具体的には -W option を使って、
  • global IP を持っているマシンに ssh
  • そこから local IP を持っているマシンに ssh
をしている状態でも動きます。

ちなみにその時の DISPLAY の値は
  • $ ssh -Y 10.20.30.40
  • $ echo $DISPLAY
    • localhost:10.0
とか。localhost の host はどこなの状態。IP reachable とかそんなレベルじゃない。

いやまー、 22 番にアクセスしてきた socket を使ってデータを送受信している、みたいなオチだとは思う。
が、「通信が相互に疎通可能である状態ならGUIでもOK」と書いた身としては、すみません嘘つきました、という気持ち。


参考

2018/04/29

GUI application を docker で起動する

私は Host の環境を汚したくないので、開発環境の構築は Docker でなるべくやっています。
今のところDocker 固有の凶悪な問題に遭遇していないので、軽いVM みたいな形で使ってます。
centos:7 でコマンドを試した後、 ubuntu:16.04 でもそのコマンドを試す、とか。ぽんぽん立ち上げられるのが良い。
CUI の場合はガンガンコンテナを作るのですが、GUIはさてどうするんだろう、と疑問。
それで調べたりしたログがこの記事です。

結論としては、この記事は Docker の話では無く X11 の話です。
正確には「X11 に詳しいと、プロセスが走る場所がコンテナ内でも ssh 先でも、GUI を表示できる」という話。


環境

  • macOS Sierra: 10.12.6
  • Docker: 18.03.0-ce-mac60 (23751)
  • XQuartz: 2.7.11 (xorg-server 1.18.4)


GUI Application Container

GUI を利用する Container を調べていたら実行コマンド付きの firefox がありました
XQuartz を起動して、いろいろオプションを足せばOKみたいです。


XServer の起動

X11 の Server として XQuartz を使っていたっぽい。

まずは Server(GUI への remote access を許可) を起動するために
  • Preferences > Security > Allow connections from network clients
にチェックを入れる。
これで XQuartz を起動時に 6000 番とかで listen してくれる。
  • $ netstat -at
とかして :x11 とかがあればOK。
xauth とかで access control もできるっぽいんだけれど、まずは全てのアクセスを許可。
  • $ xhost +
これで X11 Server 側は準備OK。


XServer を指定してコンテナ起動

XServer の情報をオプションで run する時に渡せば firefox が起動しそうです。
元ページのコマンドは
  • $ docker run -d -e DISPLAY=$ip:0 -v /tmp/.X11-unix:/tmp/.X11-unix jess/firefox
ですが、今回は volume の mount はいらないので
  • $ docker run -d -e DISPLAY=$ip:0 jess/firefox
にしてみる。$ip には XServer の ip が入っていると仮定します。
実行すると X11 Server 側で firefox が起動します。やったね。
ちなみに 10.0.0.10:2.0 などのフォーマットはこういうことらしいです。



コンテナの中で DISPLAY を設定してみる

さて、docker run の時の -e オプションは単に環境変数を渡すだけみたいですね。
ということは後から変更できたりするかも。
一旦 centos:7 を起動して、後から DISPLAY を設定してみる。
  • $ docker run -it centos:7
    • # yum install -y epel-release
    • # yum install --enablerepo=epel xcalc
    • # export DISPLAY=10.0.0.30:0.0
    • # xcalc
xcalc は x11 を使う計算機です。
firefox の setup などは難儀なのでこれで代替。
まー、こいつも epel を入れるとか、ちょっとだけ面倒ですが割愛。

結論としては、run した後から DISPLAY を設定しても GUI は起動します。ふむふむ。


ssh 先での GUI Application

DISPLAY が設定できていれば GUI は起動する。
その前提として docker for mac <-> XQuartz 間の疎通が必要。
何故かといえば IP でディスプレイを指定しているからです。

なら、 docker on ssh server <-> XQuartz も可能?
ということで ssh した先でも DISPLAY を設定して xcalc 。
表示される計算機。
なるほど、別に docker だろうと、 ssh 先の linux だろうと、 DISPLAY にデータが送れるのなら GUI process は起動できるっぽい。

この場合、 GUI の描画は X11 経由で mac に、Application のプロセスは ssh した Server の中の docker が起動、なんて状態に。複雑。

ということで、 DISPLAY を適切に設定できれば GUI はぽこぽこ生やせる。


結論

DISPLAY を設定すれば GUI Application も docker で動きます。
というか DISPLAY を設定すれば ssh 先のサーバだろうと何だろうと GUI Application は動きます。


おまけ: xhost 

  • $ xhost +
は全てのIPからGUI access を許可するので危なすぎる。
  • $ xhost -
で access control を再び有効にできます。
本来なら 
  • $ xhost + 10.0.0.20
とかするらしいです。

Docker 触ってると思ったら X Window を触っている。
トレンドを追ってるのか、過去を追ってるのか分からなくなってきます。


参考

2018/04/22

https proxy があるネットワークで Docker を動かす

時にプロキシを介さないと外に出られないネットワークがあります。
curl とかは http_proxy や https_proxy の環境変数を設定するだけで外に出られるので楽。
具体的にはこんな感じ。

  • $ export http_proxy=http://192.168.100.200:12345
  • $ export https_proxy=https://192.168.100.200:54321

しかし docker は環境変数の設定だけでは外に出られない。
具体的には docker pull ができなかった。
docker pull はデフォルトだと https で docker.io に image を取るので引っかかる。


環境

  • Ubuntu 16.04 LTS
  • Docker: 1.5-1

proxy 設定

素直に公式のドキュメントを見る。
具体的には
  • $ mkdir -p /etc/systemd/system/docker.service.d
  • $ vi /etc/systemd/system/docker.service.d/http-proxy.conf
    • [Service]
    • Environment="HTTP_PROXY=http://192.168.100.200:12345"
    • [Service]
    • Environment="HTTPS_PROXY=https://192.168.100.200:54321"
でOK。
systemctl restart docker をすると proxy 経由で pull ができるようになります。


参考