vol30. Windows/Linux on virtual machine/Linux on remote でクリップボードの共有
私の開発環境は、windows PCとその上で走る仮想マシン上でLinux、そして、remote に
desktop PCのLinuxを使用している。
これらのクリップボードの共有のしくみは以下の通り
-
- vmware-toolsを利用
Linux OS on virtual - tmux
- xclip を利用
- .tmux.conf に以下の設定
bind-key -t vi-copy 'y' copy-pipe "xclip -sel clip -i"
bind-key p run-shell 'xclip -sel clip -o | tmux load-buffer -; tmux paste-buffer' - tmux list-buffers コマンドでクリップボード確認
Linux OS on virtual - Linux OS remote
- X forwarding を利用
- ssh -X でremote にログイン
一枚の絵で書くと以下のとおり。
X forwarding を利用するとremote のPCとクリップボードが共有できるのは知らなかった。
vol29. SIOCADDRT: File exists/RTNETLINK answers: File exists エラー
$sudo systemctrl restart networking
を実行すると、以下のエラー
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.
ログ通りに
$journalctl -xe
を実行すると、
May 15 16:24:12 pc-linux avahi-daemon[598]: Joining mDNS multicast group on interface enp5s0.IPv4 with address 192.168.0.63
May 15 16:24:12 pc-linux avahi-daemon[598]: New relevant interface enp5s0.IPv4 for mDNS.
May 15 16:24:12 pc-linux avahi-daemon[598]: Registering new address record for 192.168.0.63 on enp5s0.IPv4.
May 15 16:24:12 pc-linux dhclient[12150]: bound to 192.168.0.63 -- renewal in 241 seconds.
May 15 16:24:12 pc-linux ifup[12133]: bound to 192.168.0.63 -- renewal in 241 seconds.
May 15 16:24:12 pc-linux ifup[12133]: SIOCADDRT: File exists
May 15 16:24:12 pc-linux ifup[12133]: ifup: failed to bring up enp5s0
May 15 16:24:15 pc-linux avahi-daemon[598]: Joining mDNS multicast group on interface enp8s0.IPv4 with address 192.168.101.2
May 15 16:24:15 pc-linux avahi-daemon[598]: New relevant interface enp8s0.IPv4 for mDNS.
May 15 16:24:15 pc-linux avahi-daemon[598]: Registering new address record for 192.168.100.20 on enp8s0.IPv4.
May 15 16:24:15 pc-linux ifup[12133]: RTNETLINK answers: File exists
May 15 16:24:15 pc-linux kernel: IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
May 15 16:24:15 pc-linux ifup[12133]: ifup: failed to bring up enp8s0
May 15 16:24:15 pc-linux systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
May 15 16:24:15 pc-linux systemd[1]: Failed to start Raise network interfaces.
どうやら以下のログのとおり、ネットワークインターフェース enp5s0 と enp8s0 のifup で失敗している模様だ。
ifup[12133]: SIOCADDRT: File exists
ifup[12133]: ifup: failed to bring up enp5s0
ifup[12133]: RTNETLINK answers: File exists
kernel: IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
ifup[12133]: ifup: failed to bring up enp8s0
ifup は/etc/network/interfaces の設定ファイルに基づいて、 ネットワークインターフェースの立ち上げを行うコマンド。
/etc/network/interfaces の設定は、
auto enp5s0
iface enp5s0 inet dhcp
post-up route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
auto enp7s0
iface enp7s0 inet static
address 192.168.101.2
netmask 255.255.255.0
gateway 192.168.101.1
auto enp8s0
iface enp8s0 inet static
address 192.168.100.20
netmask 255.255.255.0
gateway 192.168.100.1
ifup は -v オプションで詳細なログが表示される。 まずは、enp5s0が失敗する原因について調査。
$sudo ifdown --force enp5s0
$sudo ifup -v enp5s0
ifup: configuring interface enp5s0=enp5s0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/dhclient -4 -v -pf /run/dhclient.enp5s0.pid -lf /var/lib/dhcp/dhclient.enp5s0.leases -I -df /var/lib/dhcp/dhclient6.enp5s0.leases enp5s0
....
DHCPDISCOVER on enp5s0 to 255.255.255.255 port 67 interval 6
DHCPREQUEST of 192.168.0.63 on enp5s0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.0.63 from 192.168.3.254
DHCPACK of 192.168.0.63 from 192.168.3.254
bound to 192.168.0.63 -- renewal in 275 seconds.
route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
SIOCADDRT: File exists
ifup: failed to bring up enp5s0
なるほど、 route add コマンドの実行結果が、SIOCADDRT: File exists につながっているのね。
route add コマンドの直前まで、マニュアルでコマンドを実行して、routing table を表示してみると、
$sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.3.254 0.0.0.0 UG 0 0 0 enp5s0
192.168.0.0 0.0.0.0 255.255.248.0 U 0 0 0 enp5s0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 enp8s0
192.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 enp7s0
route add コマンドで実施したいdefault gatewayがすでに追加されている。dhclient コマンドで設定されるみたいだ。
よって、/etc/network/interfaces から以下の行を削除。
post-up route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.3.254
同様の手順で、enp8s0 のerror の原因を調査してみると、以下の行が問題だったため、 削除。
gateway 192.168.100.1
最後にもう一度動作確認。
$sudo systemctrl restart networking
よし。エラーなし！！
ちなみに、以下のようにifdown コマンドでinteface not configured エラーになる場合は、 /run/network/ifstate が壊れている。 ifconfig コマンドを使ってネットワークを立ち上げたり、ifup/ifdown コマンドが失敗したりして、ifstate ファイルの更新が失敗して、 実際のネットワークインターフェースの状態と不整合が起きた時に発生する。
その場合は、--force option をifup/ifdown コマンドに渡してあげれば、ifstate ファイルの状態を無視してコマンドを実行してくれる。
$sudo ifdown -v enp5s0
ifdown: interface enp5s0 not configured
ネットワーク立ち上げ後は、以下が正常な状態
$ cat /run/network/ifstate
lo=lo
enp5s0=enp5s0
enp7s0=enp7s0
enp8s0=enp8s0
以下はネットワークがダウンしている状態
$ cat /run/network/ifstate
lo=lo
vol28. eclipse環境を構築する2
以下の記事の続き。
eclipse のdebug環境は、バックエンドにgdb を利用し、フロントエンドのGUIにgdb
の結果を出力したり、アイコン操作をgdbの各種コマンドに紐づけているといった仕
組みになっている。
native 環境では、gdbのみを利用するが、クロス環境では、target でgdb serverを
走らせ、hostでクロス向けのgdb を走らせる。debug前にgdb server をtargetで自動
的に走らせるために、sshやtcf等を利用する。
本来やりたかった、eclipseをwindows 上にインストールして、そこから仮想マシン
上で走るLinuxのアプリのデバッグやremote マシン上で走るアプリのデバッグでも、
クロス向けのgdbを準備する必要があり、これが一苦労だ。
ネット上で、自分の所望のクロス向けgdbを探してくるか、自分でgdbのソースコード
をダウンロードし、windows上でビルドする必要がある。gdbのビルド環境として、
cygwinやmingwといったwindows 環境向けのGNU開発環境を準備する必要がある。
結局、この手間を嫌い、eclipse をwindows上で走らせるのは断念。
動きがもっさりするけど、vmware上のlinux でeclipseを走らせ、その画面をx
forwarding でwindows 環境に飛ばす手法をとることにした。
vol27. ssh 接続問題奮闘記
先日開発のサブPCとして、desktop PC を入手。
そこにLinux をインストールし、メインのLinuxからsshでログインして、サブPCを使用
する環境で作業をしてきた。サブで立ち上げたいGUIアプリは、X forwarding を利用
して、メインPCに飛ばす使い方だ。
ただ環境を構築してから、数日間、ssh connection が切れる問題についてずっと悩
まされてた。
write failed: Broken pipe
のメッセージを残して、ssh 接続が切れる。
問題解決のために以下のことを実施した。
google 先生に聞いてみると、 ssh サーバーやクライアントの設定で、
以下をいじると直るとの投稿が多数あるため、試すも効かず。
ServerAliveInterval
ServerAliveMax
ClientAliveInterval
ClientAliveMax
TCP keep alivessh server 側の/var/log 下のログで、問題発生時に、更新のあったものを全て
目を通したが怪しいものはない
ssh client 側も debug オプションを最大にして(-vvv) 試すも、手がかりとな
るメッセージはないssh server 側のネットワークカードを違うもので試したが改善せず
ハードウェアの問題ではなさそう。問題発生時は、ssh server - client 間のping が一定時間(数秒) 繋がらず
ただ、ssh connection をつないだ状態で、意図的にserver 側のnetwork
interface をifconfig eth0 down で遮断しても、client 側では、
ssh でつないだシェルが応答しないだけで、
write failed: Broken Pipe とはならない。
よって、何らかの理由でnetwork が一定時間遮断されても問題ないはず。
そもそも、上記#1の設定がそのような状況に対応するためのものだ。以下の投稿を発見。カーネルの問題があるかもしれないとか。
私の環境では、ssh server にdebian stretch を使っており、
kernel のversion は4.9.0.6。怪しい。
https://unix.stackexchange.com/questions/259225/packet-write-wait-broken-pipe-even-leaving-top-runningそこで、とあるnetwork キャプチャーソフトを使って、問題発生時のTCP port22
のメッセージを観測していた所、Reset flag がセットされたTCP message が観測さ
れた!! 上記ブログの通りだ。
kernel のdriver の問題なのか？ stretch で他に利用できるkernel がないか調べ
たら、4.16.0があったのでそれで試したが、まだ問題発生。
ダウングレードしないといけないか？そして、最後にnetwork switch を介さずssh server とclient で直接接続したら、
！！！問題が発生しなくなった。すくなくとも一晩。
Ethernet switch の問題？
だが、違うEthenrnet switch を接続して試しても問題発生。うーむ。。。どういうことだ？？
結局今は、Ethernet switch を介さず直接接続で運用しています。
vol26. eclise環境(リモートデバック環境)を構築する1
私は現在、Linux base の組み込み機器を開発する仕事に従事している。
開発環境は、 windows PC 上に、仮想マシンを用意し、そこにlinux をインストール
して使用している。組み込み機器でソースコードをいじる部分は、linux device
driverやlinux 上のアプリ郡で、ほとんどシェル上で閉じた作業となる。
たまに、gstreamer のplugin といった複雑なアプリをデバッグする場合、GUI を用
いたデバッグをしたくなる。そこで、linux 上に、統合開発環境としてよく用いられ
ているeclipseをインストールしてみた。しかし、vmware 上でGUIを走らせるとGUIの
ウインドウの描画に時間がかかるせいか、動きがもっさりとしてとても開発効率が悪
い。
そこでeclipseをwindows 上にインストールして、そこからリモートデバッグ機能を
利用した環境を構築することにした。
この環境を構築しておけば、今後アプリのデバッグ効率も高まるはず。
後に、環境の構築方法や便利な設定を投稿していきたい。
vol25. apt-get install が遅い - DNS server 設定が原因
最近、開発用のマシンとして、Desktop PC を入手し、debian stretch をインストールし
た。すこぶる快適なのだが、1点、apt-get install がとても遅い。Network 速度が遅い
というわけではなく、実際にpackage をダウンロードし始めるまでに、数秒間待たされる
のだ。待たされた後、一瞬で、package をダウンロードし、インストールが完了する。
これは何かおかしい。。そう思い、簡単な試験を実施してみた。
すると、以下の事がわかった。
1. firefox でブラウザ開くときも遅い
2. ping www.google.com がやたら遅い
3. ping ipaddress は早い
どうやら、host名の名前解決に時間がかかっているようだ。DNS server の設定がおかしい。
そこで、DNS resolver の設定ファイル(/etc/resolv.conf) をみてみると
domain ol.csi.178
search ol.csi.178
nameserver 68.87.xx.130
nameserver 68.87.xx.134
DNS server のIP address が二つ登録されている。
ping してみると、68.87.xx.134 からは反応があるが、.130 からは反応がない。
こいつが犯人だ。
応答のないDNS server の設定をコメントアウト、これで早くなった。
どうやら、最初のDNS serverで名前解決を試みるが、応答がなくtimeout。
その後、次のDNS server から応答を取得し、名前解決が完了
といったプロセスになっているようだ。
これで一件落着、と思いそのまま使用していると、再起動後、問題が再発生。
/etc/resolv.conf ファイルが元通りになっているではないか。
誰かが上書きしているみたい。
ググると、dhcp-client が設定を上書きするとの情報。
dhcp-client の設定ファイル(/etc/dhcp/dhclient.conf)を変更
domain-name-servers, dhcp6.name-servers を取り除く
これで問題解決
vol24. セーラー服
友人との会話で、祖先がセーラーという話題になった。セーラーと言えば、日本では女子
中学生や女子高生の制服が連想される。
セーラー服(sailer)は、その名の通り、海軍において、水兵の切る軍服が由来である。特
徴的な大きな襟は、襟を立てて海の上での集音力を高めるためとか。
そのような軍服がなぜ日本の女子中高生の制服に採用されたの？
ふと疑問に思ったのでその由来を調べてみた。
- セーラー服は、18世紀に、ヨーロッパの貴族にもてはやされ、子供服として定着
- イギリス海軍は1857年にセーラー服を制服として採用
- 日本海軍でも1872年には取りいれられ、現在も自衛隊の水夫の制服として存続
イギリス海軍を真似て、日本海軍がセーラー服を導入したのが、日本におけるセーラー
服の歴史の始まり。 - 1920年（大正９年）に京都の（現）平安女学院が採用したのが女子中高生の制服とし
ては最初 - その後、女子用学校制服としてセーラー服は次々と採用されるようになっていった
最近ではブレザーが増えてきて、セーラ服を採用する学校がだいぶ減っているとか。
日本の文化の一つとして大切にしてもらいたいなぁ。
