SVX日記

　 休むが勝ちである。

　 とりあえず

　 休み終盤。グダグダと漫画のデスノートを読みふけっては、ニンテンドーDSのテトリスの通信対戦を繰り返し、順調に一週間の休みを無駄に過ごしつつある今日この頃だが、一度も行かないワケにもいかんだろう(？)……と、いうことで、秋葉に行く。

　 いやはや、すでに家に「文字通り売るほどに」電子パーツを揃えてしまっているので、今さら買うモノも少ないのだが、まぁ、なんとなく工作ネタもあるので、ポツポツとパーツを買う。

　 例によって、アチコチとゲーセンを回るが、なんだかアレだねぇ、興味のあった「連合vsZAFTII」も前作と代わり映えしないし……デストロイに乗ってみたかったんだが、プレイヤとしては乗れないし。対COM戦をしようにも、対戦台ばっかりだし。入っても瞬殺されるのわかってるからヤル気せんわ。グラディウスして、グラディウスIIして、19XXして、レイクライシスして……はなまるうどんでしょうゆうどんの大盛りを食って……なんだか、コッチも代わり映えしない。

　 ヒサビサに書泉ブックタワーに登る……が、こんなにオタッキーな本屋だったっんだっけ、ココ。懐かしいゲームブックの「火吹山の魔法使い」を思わず買いそうになりつつ、情報処理試験の教本を軽く値踏みして帰る。しかし、デカい本屋も久しぶりですな。最近、高い本はAmazonで買ってばかりのオイラである。

　 帰って買ってきたパーツをウジャウジャとイジっていたら、なんとなくヤル気になってきた。ではまた。

　 どうも、小出しにされる新規艦娘や改二につられて、いまだやめるにやめられない艦これであるが、イベントということで、普段に加え、イソイソと取り組んでしまうオイラなのであった。

　 今回、AL/MI作戦という事で、片方に参加した艦娘は、もう片方に参加できないという縛りが設けられているが、これまた、絶妙な新要素といえよう。しかも早々に、MI作戦後に最終作戦があることがバラされてしまい、AL作戦は三軍でクリアしなければならないことが判明。毎度ながら、艦これ運営のゲームデザインの巧みさには感服する次第だ。

　 で、極端にシブった艦隊編成で、E1に挑戦したが……10連続大破撤退を喫してしまう……どうも運が悪いとかいうレベルの問題ではないようだ。

　 結局、先人の艦隊編成の例を参考に再挑戦。それでも大破撤退率は50%を超えたが、ボスに到達してしまえば楽勝でS勝利。ようやく、海域クリアと相成った。

　 ウェブ上の情報では、E1が一番ツラい、という情報が多いが、この調子でポンポンとE5まで進められるとよいのだが。

　 CUIで無線LAN接続に成功したものの、アホな無線ルータに散々に悩ませられたが、ローエンドな無線LANルータを買って解決。次なる目標はラズベリーパイをルータにすることだ。こんな感じに。

　 インターネット─[モデム]─宅内LAN─[無線ブリッジ]…無線LAN…[ラズベリーパイ]─直結LAN─[対象機器]

　 ……んが、ラズベリーパイをルータにすると、対象機器へのルーティングの定義が必須となる。めんどい。ここは、ラズベリーパイもブリッジとするべきではないか。それならば、対象機器へのIPの払い出しも、宅内LANにつながっているLinuxルータで一括管理できるし。

　 しかし、ラズベリーパイに導入したRaspbianは、Debian系なので個人的に土地勘がない。ブリッジってどうやるんだ？

root@xxxpi:/etc/network# diff -bc interfaces.org interfaces
  auto lo
  iface lo inet loopback
  
! iface eth0 inet manual
  
! allow-hotplug wlan0
! iface wlan0 inet manual
      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
--- 9,27 ----
  auto lo
  iface lo inet loopback
  
! auto eth0
! iface eth0 inet static
!     address 0.0.0.0
  
! auto wlan0
! iface wlan0 inet static
!     address 0.0.0.0
      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
  
+ auto br0
+ iface br0 inet dhcp
+     bridge_ports eth0 wlan0

　 ……と、できてみれば単純な設定だが、無線の設定とも絡んで、かなり手こずらされた。無線の設定は、先日の/etc/wpa_supplicant/wpa_supplicant.confに設定しておけばいい。

root@xxxpi:/etc/network# ifconfig
br0       Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:52
          inet addr:172.xx.xx.xxx  Bcast:172.xx.xx.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
eth0      Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:52
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
 
wlan0     Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:74
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

　 ブリッジが形成されると、ブリッジのメンバであるeth0とwlan0にはIPアドレスが割り当てられなくなり、br0にIPアドレスが割り当てられる。ブリッジはレイヤ2動作のため、当然、IPアドレスを持たないのだが、このbr0のIPアドレスはブリッジの上にいる自ホストに割り当てられたIPアドレスという感じか。はじめて目にした時にはかなり混乱し、理解するまでに時間を要したっけ。

root@xxxpi:/etc/network# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.xxxxxxxxxxxx       no              eth0
                                                        wlan0

　 ブリッジの様子を見ると、確かにeth0とwlan0がメンバになっている。

　 で、こうする。

　 先日から愛用しているミニコンポを有線LAN接続するのである。

　 これにより、ミニコンポからは有線LAN接続でDLNAサーバにアクセスし、音楽を再生できるようにはなったのだが、なぜかラズベリーパイ上で宅内LAN上のサーバへのnfsアクセスが不安定。fstabに書いておいても起動時にmountしてくれないし、以下のコマンドでmountできる時とできない時がある。またしても無線LANブリッジが怪しいのだが、不安定なだけに調べようがない。うーむ、どうしてくれよう。

root@xxxpi:~# systemctl start rpcbind
root@xxxpi:~# mount /mnt/mediatomb/

　 なんでこれまで無線LAN接続で使っていたミニコンポをワザワザ有線LAN接続に変更するのか、なんでラズベリーパイからnfsアクセスが必要なのか、については、また後日(まぁ、だいたい想像がつきそうなもんだが)。

　 だいぶ間が開いてしまったが、東北から戻ってから、自宅の外壁工事が始まったり、ロードスターを外の駐車場に退避しておいたらブツけられたり、筋トレを緩めたせいなのか体が緩んだり、なんやかんやで、どうも気分的に不安定になっていたりする。

　 男性にも更年期があるとかで、そのせいなのか、自宅やクルマというテリトリが侵され気味のせいなのか、仕事の環境が微妙なせいなのか、暑い中を動きすぎて塩分が足りてないのか、どうも気分は曇り空である。時々、晴れ間が覗くような、そうでもないような。

　 何かに取り組んでいないと気がすまない性格なのに、どうも取り組む気が起きず、ダラダラとゲームしたりしてしまう。ゲームが悪いわけではないのだが、そういう気分の時にゲームすると罪悪感のようなものを感じてしまって、ますます気が滅入る。我ながら面倒くさい性格とは思うのだが。

　 そんな日々の中、今日はすっかり存在を忘れていた休日なのだが、なんとなく気分に晴れ間が覗いたからか、以前から作ってみたいと思いつつ、ディスクの容量などの都合で断念していた「リモートデスクトップコンテナ」の構築を始めてみた。

　 自分はFedoraでMATEの人なのだが、コンテナのビルドで「MATEデスクトップ」をインストールしようとすると、なぜかディスクの容量制限にかかって失敗してしまうのだ。そんなら、ということで、姑息ながら小分けインストールしたみたところ、そんな方法でインストールに成功してしまった。

　 突き詰めていくと「MATE」と「MATE Desktop」に分けるだけで十分なようだ。何度かつながらない状況をトラブルシュートしながらアレコレした程度で、それほど苦労することもなく、アッサリと「リモートデスクトップ接続(RDP)」からの接続に成功してしまった。

　 以下にDocker関連ファイルを示す。

 # cat Dockerfile
 FROM fedora:38
 
 LABEL maintainer="Furutanian <furutanian@gmail.com>"
 
 ARG http_proxy
 ARG https_proxy
 
 RUN set -x \
     && dnf groupinstall -y 'MATE' \
     && dnf groupinstall -y 'MATE Desktop' \
     && dnf install -y xrdp \
     && rpm -e thunderbird thunderbird-librnp-rnp \
     && rm -rf /var/cache/dnf/* \
     && dnf clean all
 
 RUN set -x \
     && ln -sv /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target \
     && systemctl enable xrdp \
     && systemctl disable firewalld
 
 EXPOSE 3389
 
 ENTRYPOINT ["/sbin/init"]

 # cat docker-compose.yml
 version: '3'
 services:
     crd:
         image:
             docker.io/furutanian/crd
         container_name:
             crd-alpha
         build:
             context:
                 .
 #           args:
 #               http_proxy: http://user_abc:password@proxy.example.com:8080/
 #               https_proxy: http://user_abc:password@proxy.example.com:8080/
         ports:
             - "13389:3389"
         restart:
             always
         stop_grace_period:
             1s
         privileged:
             true
         environment:
             TZ: Asia/Tokyo
 #           http_proxy: http://user_abc:password@proxy.example.com:8080/
 #           https_proxy: http://user_abc:password@proxy.example.com:8080/
         volumes:
             - pv:/home
 
 volumes:
     pv:
         driver: local
 # データを永続的に保持する領域として
 # mkdir -pv pv しておくこと
         driver_opts:
             type: none
             o: bind
             device: $PWD/pv

　 一応、/homeはPVに出してあるが、コンテナなので再起動すると、良くも悪くもほとんどの設定がブッ飛んでしまうし、現状、コンテナを上げる都度、ユーザを作らなければならないし、英語環境だし、キーボードはヘンだし、タイムゾーンはUTCだしで、まだ詰めは甘い。が、そのへんの直しとか、愛用のメーラであるMAVEの導入とかは、このコンテナを継承する形にするべきで、これはこれで完成形かな。

　 しかし、これが完全に実用になったならば、常に最新のFedoraに乗り換え続けることも容易になるな。これは、Windowsを捨てFedoraに移行して以来のデスクトップ環境の革命かもしれん。