おは代々木ダイアリー

いろいろ試したメモを書きます。このブログはアフィリエイトを使用したプロモーションを含みます

WSL2 Bashを使うことですべての問題が解決したかと思われたWindowsリモート開発だったが結局WSL2にSSHした件

Windows10 HomeなゲーミングPCに乗り込んでリモート開発すべく、WindowsにOpenSSHサーバーを導入してVisual Studio Codeのリモート開発拡張機能を使ってきました。開発を進めていく上で遭遇した

  • SSH経由のgit pullがハングする
  • DevContainersが使えない

といった不具合を乗り越えるため、WSL2 Bashをデフォルトシェルに指定することで解決するという内容を前回記事で書きました。

ohayoyogi.hatenablog.com

まだ残っていた問題

デフォルトシェルをWSL2にすることで、当初の「SSH経由でのgit pull」や「DevContainersの利用」はできるようになったものの、新たな問題が発覚しました。

それは

  • ssh-agentのForwardingが効かない

ということです。「WSL Bash SSH Agent Forward」みたいなググり方をすると、使用するSSHクライアントによって癖があるようで、「Windowsssh-agent.exeに登録した鍵をWSL2 SSHで使用する」みたいな内容がよく出てきました。が、今回はそれとは違うような気がしています。

(そもそも、SSHのAgentForwardingってどうやって実現されているのかよくわかってないです。SSHサーバーが環境変数に参照すべきAgentの宛先を設定して、それをSSHクライアントが使用している…?詳しい人いたら教えてください…)

で、さんざん調査してわかったのはどうやらWindows向けのOpenSSHサーバーはAgentForwardingには未対応ということです。おお、マジか・・・

Agent Forwarding Windows client to Windows host not working? · Issue #1865 · PowerShell/Win32-OpenSSH · GitHub

というわけで、AgentForwardningが効かないのはちょっと(だいぶ)つらいので、頑張って解決してみようという内容になります。

解決方法

いままで開発してきて、Windows向けのOpenSSHクライアントからLinuxのOpenSSHサーバーに向けてつないだ時はAgentForwardingが機能することは確認できていたので、WSL2のLinuxに直接SSH接続すればいい ということになります。

が、ここで立ちはだかるのは2つの壁です。

  • WSL2でsshdを動かす
  • WSL2のsshdへ何とか繋がるようにする

一番目のsshdの動かし方は wsl sudo service sshd start とかやっちゃえばまぁ解決です。問題は二番目の「WSL2のsshdへの繋ぎ方」です。

これについては何が問題かというと、WSL2で使用されるIPアドレスは起動のたびに変わってしまうということが言われていて、現在固定する方法がない(Hyper-V使える人は固定できるみたい?まぁWindows Proエディションの話なので今回は対象外)ということです。

世の中の先人たちは、これに対して WSL2のIPアドレスを取得してnetshでポートフォワーディングの設定を書く という対処方法をよくとっているみたいです(著者調べ)。以下、参考にしたサイトです。

リモートマシンのWSLにOpenSSHサーバとDockerを入れてVSCodeからリモートアクセスできるようにする - てのひら

ただ、これ開発時以外もずっとポートフォワーディングしてるのが非常に気持ち悪いですし、そもそもタスクスケジューラとか普段使わないので設定したことを忘れて放置してたりしそうで怖いです。何よりファイアウォール開けるのが嫌ですね・・・

というわけで、別の方法をとりたいと思います。

Windowsホストを踏み台にしてWSL2にログインする

Windowsに開発時以外もポートフォワーディングさせるのちょっと怖いですし、昔ながらの「SSHのProxyCommandを使って接続する」という方法をとってみたいと思います。「踏み台」ってやつですね。

【ポートフォワーディングさせる場合】
クライアントマシン ==SSH==> WSL2(開発機)

【踏み台にする場合】
クライアントマシン ==SSH==> Windows(開発機) ==SSH==> WSL2(開発機)

そうだnetcatしよう

さて、踏み台にするにあたって「WSL2のIPアドレスはどう扱う?」という問題は依然としてあります。

が、ここで天啓。これ、フツーに「WSL2にnetcatさせればいいのでは????」となりました。

つまり、ProxyCommand で踏み台に wsl nc localhost 22 させればよいのです。

やりかた

というわけで早速 .ssh\config を書きました。WinHomeは開発機のホストで、DevWSLは開発機内のWSL2のホストです。

Host WinHome
  HostName 1.2.3.4
  # 以下略

Host DevWSL
  HostName localhost
  Port 22
  ProxyCommand ssh WinHome wsl nc %h %p
  # 以下略

接続時は ssh DevWSL とするだけでOK!。VSCode からもDevWSLを開くようにポチポチしているだけでWSL2に入って開発することができます。

結局、AgentForwardingならず

はい、ここまで引っ張っておいてアレなんですが、結局AgentForwardingできていません。なんかどうもWSL2に導入するOpenSSHのバージョンによってはForwardingできない問題が発生するそうです。なんじゃそりゃー!

WSL2のOpenSSH Agent Relayが動かなくなったので調査した

結局DevContainersでいく

結果としては失敗に終わりましたが、実はAgentForwardingできる方法がありました。

VSCodeのDevContainersのAgentForwarding機能を使用する という方法です。

これ、どうやらSSHとは異なった経路(?)でAgentForwardingしているようで(確かにDockerに入るのSSHじゃないもんな)、たぶんバケツリレー的に経由するホストの各地点でAgentForwardingできていなくてもSSHクライアントと連携できるんだと思います。(適当言ってます。間違ってたら指摘してください…)

devuser@0cf0909ae8ca:/workspaces/hogehoge $ ssh -T git@github.com
Hi ohayoyogi! You've successfully authenticated, but GitHub does not provide shell access.

え?じゃあこれWSL2 Bash経由で繋いでてもDevContainersだったらPortForwardingできたってこと~~~????っていう疑問もわくんですが、怖いので調べていません・・・(情報求む)

終わりに

というわけで、WSL2に対してnetshによるポートフォワーディングを使用せずにSSHで繋ぐ方法を考えてみました。

WSL2にAgentForwardingできたら最高だったんですが、それは時間が解決してくれるということで、今は頑張って何とかWSL2内でpullしてから鍵を使った作業はDevContainers内でどうにかするという方法をとりたいと思います。

それでは、みなさまもよきリモート開発ライフを。

nodeなどのコンテナイメージでdevcontainerを使うとuidが変わらなくて困る問題への対処

Visual Studio CodeのRemote Containers機能(Dev Containers)には、VSCodeの実行ユーザーのUIDでコンテナ内のユーザーのUIDを更新してくれる便利な機能があります。

例えば、UIDが1002のユーザーでVSCodeを立ち上げていて、コンテナ内で作成したユーザー devuser を使用したとき、コンテナ内の devuser のUIDは1002に上書きされるといった挙動になります。これは、手元のディレクトリをコンテナ内にマウントしていて、それをVSCodeでいじる場合に、UIDが異なってしまうという問題を回避することができるのでとても便利。

使い方

使い方は簡単で、devcontainer.json に以下のように remoteUserupdateRemoteUserUID を指定するだけ。remoteUser にコンテナイメージ内に存在するユーザー名を指定することでコンテナを開いたときに使用されるユーザーを指定でき、かつ updateRemoteUserUID を有効にすると 指定したユーザーのUIDが現在のログインユーザーのUIDになってくれます

{
  "remoteUser": "devuser",
  "updateRemoteUserUID": true,
}

説明のためupdateRemoteUserUID も念のため指定していますが、このオプションはデフォルトで有効になっているので明示的な設定は省略可能です。

DevContainersに使用するコンテナイメージには、以下のようなDockerfileを考えてみます。

FROM ubuntu:20.04

ARG USERNAME=devuser
ARG USER_UID=1234
ARG USER_GID=$USER_UID

# Create the user
RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m -s /bin/bash $USERNAME 

Dockerfile では UID 1234 で devuser というユーザーが作成されていますが、Dev Containersで開いてみると、見事IDなどが変わっていることがわかります。

devuser@cbb03f77d869:/workspaces/devcontainer_example$ id
uid=1000(devuser) gid=1000(devuser) groups=1000(devuser)

devuser@cbb03f77d869:/workspaces/devcontainer_example$ ls /home/devuser -la
total 28
drwxr-xr-x 1 devuser devuser 4096 Jan 12 04:17 .
drwxr-xr-x 1 root    root    4096 Jan 12 04:17 ..
-rw-r--r-- 1 devuser devuser  220 Feb 25  2020 .bash_logout
-rw-r--r-- 1 devuser devuser 3771 Feb 25  2020 .bashrc
-rw-r--r-- 1 devuser devuser  807 Feb 25  2020 .profile
drwxr-xr-x 6 devuser devuser 4096 Jan 12 04:17 .vscode-server

ちゃんと HOME のパーミッションも変わっていてとてもGOODですね。

問題点

「指定したユーザーのUIDが現在のログインユーザーのUIDになってくれます」と書きましたが、これが効かないケースもありました。

というのも、変更先のUID(つまりログインユーザーのUID)がコンテナイメージ内ですでに使われていた場合、このオプションは有効に働かず、コンテナイメージ内のUIDがそのまま使われてしまいます。

例えば、「node」のコンテナイメージはデフォルトで node というユーザーがUIDが1000で作成されているので、VSCodeを起動しているユーザーのUIDが1000だった時にバッティングしてしまい、devuser は作成した時点の UID 1234 の状態のままでDev Containersが立ち上がってしまいました。

解決方法

ここで、この問題を解決できる方法を考えてみました。

1. そのユーザーをそのまま開発にも使う

すでに使いたいUIDが使用されてしまっているのであれば、remoteUser にそのUIDが割り当てられているユーザーを指定してしまうのも手です。

ただ、これだとユーザー名が自由に選べませんし、意図した通りにセットアップされているかはDockerfileを読み解いていくしかありません。そもそも、Dev Contaienrsで乗り込むコンテナにユーザーがあったとしても、そのユーザーをそのまま活用するケースに出会ったことがありませんし、こういうユーザーは封印前提で次に示す解決策2を取るのがいいのかなと思います。

2. そのユーザーのUIDを変えてしまう

1でも書きましたが、これはこのユーザーがDockerfile作者の想定した通りに使えなくなる可能性があるので、「封印前提」で考えるべきでしょう。

RUN groupmod -g 12345 node && \
    usermod -u 12345 -g 12345 node

上記のように、node ユーザーがすでに使いたいUIDを使っていて邪魔なのであれば、そのユーザーのUIDを使わない値にしてしまえという発想です。(消しちゃってもいいのかもしれない)

このようにすることで、uid 1000がすでに使われていたとしてもログインユーザーのUIDに合わせてDevContainers内のUIDを上書きすることができるようになりました。

終わりに

以上、ゴリゴリっと書いてしまいましたが、DevContainersのremoteUser の問題と対処でした。

(読み返すとUID, VSCode, DevContainersと表現が揺れまくっているのが気になる…)

WindowsへのVSCode SSH Remoteに疲れたのでWSL bashを使ってLinuxっぽく使うことにした

リモート開発、便利ですよね。今回はWindows 10 HomeなPCに乗り込んで開発するという内容で記事を書いてみたいと思います。

想定読者

この記事はこんな方に向けて書いています。

  • Windows マシンに乗り込んでリモート開発をしたい!
  • Windows 10 ProのライセンスがないのでHomeでもできる方法を探している

ぼくはDellのG5 5000というゲーミングPCを開発環境として使っていて、先月も増設用のメモリなどを買ったところなんですが、これをリモート開発に使用したい!だけどOSがWindows 10のHomeエディションといういかんともしがたい状況なのです。

ohayoyogi.hatenablog.com

追記20230112:やっぱり駄目でした

どうもやはりssh-agent周りが厳しく、期待通りとはいきませんでした。ほかにやり方考えます。

背景

そもそもなぜリモート開発をしたいかというと、

  • どこからでも1つの環境に乗り込んで手慣れた環境で開発をしたい
  • かといって軽いノートパソコンではスペックが足りない
  • あんまりヘビー(物理)なマシンを持ち歩きたくない

などなど、皆様様々な理由があると思います。自分もインタプリタ系の言語でツールを書いているうちは試行錯誤に時間がかかるので問題にはならないんですが、TypeScriptなどトランスパイルを挟む言語だったり強力な補完を効かせたい言語で開発を行っているとなかなかにストレスが溜まってきます。

補完なんて使わずにメモ帳でも書けて、試行錯誤も1回で済むスーパーマンであればそういったストレスも少なくて済むのでしょうが、ぼくはゴリゴリにトライアルアンドエラーを繰り返して物を作っていく人間なのでそうはいきません・・・

リモート開発環境候補

ここに至るまでに考えた(試した)ものを記載します。

1. リモートデスクトップVNC, RDP, TeamViewer)

VNCやRDPを通して開発するという方法です。GUIを使う方法でネットワークの帯域は必要になりますが、ローカルネットワークであれば快適に開発できます。

「パワーで解決」という感じなので、ネットワークなどの環境に左右されがちなのが難点でしょうか。これがどんなところでも快適にできる未来が来るといいですね。

また、RDPを使うにはWindowsのProライセンスが必要になるので、使える人は限られるのではないかと思います。(自分が開発に使用しているゲーミングPCもHomeライセンスです)

2. Visual Studio Code のリモート開発機能(Linux

???「SSHでよくね?」

はい、昔ながらの方法、「SSH経由でVIM」。これが最強です

・・・ではなくて、最近はVisual Studio Codeのリモート拡張機能を使うとVSCodeの言語サーバー(補完などを提供するサーバー)をリモートで動かしつつ手元に表示して開発することができます。

おお、それなら無料で使えるOracleCloudのARMインスタンスを使ってみてはどうか?ということで、VSCodeのリモート機能で乗り込んで開発してみました。(ARMインスタンスは普段以下のような使い方をしています。)

ohayoyogi.hatenablog.com

が、やはりゲーミングPCのパワーは強く、見劣りするなぁというのが正直な感想です。まぁ使えなくはないんだけど…

3. Visual Studio Code のリモート開発機能(Windows

実はVisual Studio Codeのリモート機能にはSSHWindowsにも乗り込むことができます。

「エーWindowsSSH?」と思われる方もいるかもしれませんが、Windows 10には、とあるバージョンから「OpenSSHサーバー」をオプション機能としてインストールする機能が備わっていますので、簡単にSSHを導入できるのです。

実際に使ってみると、デスクトップPC内で作業しているような快適さでリモート開発できることがわかると思います。

Visual Studio Codeを使用したWindowsでのリモート開発の問題

というわけで、ここまで試してきた中でリモートのゲーミングPC(Windows 10 Home)にSSH経由でVSCodeで乗り込むという方法で快適なリモート開発環境が構築できました。これでしばらくは問題なく開発することができていたんですが・・・

しかし、これにも問題が…

  • SSH周りで問題がありそう?(SSHでgit pullできないとか)
  • devcontainerが使えない

一番目はターミナルでSSHしている場合は普通にgit pullできるのでVSCode拡張機能側の問題で、二番目はdevcontainerの拡張機能Windowsに対応していない(/etc/passwdとか参照しようとしてコケてる)というのが問題です。

Windowsでリモートはやはりマイナーなのか・・・

これについてはLinux互換の何かを動かせばよいので方法は複数考えられて、

  • VirtualBox など VMを立てる
  • WSL2 の LinuxSSHサーバーを立てる
  • デフォルトシェルをWSL2にしてみる

などがあります。が、1つ目はリソースをフルに活用できない問題、2つ目はWindowsとWSLでは内部で異なるIPアドレスになっているのでフォワーディングが別途必要になるなどから、今回取ってみるのは3つ目のWindowsのデフォルトシェルをWSL2のbashにしてみるという作戦です。

解決手順

解決は以下の3ステップです。

デフォルトシェルをWSL2のbashにする

まずはリモートで乗り込む先のWindowsマシンのデフォルトシェルをWSLのbashに変えてしまいます。サーバーにログインした後、レジストリエディタで HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSHDefaultShell という名前で C:\Windows\system32\bash.exe という値の文字列を登録します。

HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH

PowerShellで行う場合は以下の通り。

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\system32\bash.exe" -PropertyType String -Force

参考: OpenSSH Server configuration for Windows | Microsoft Learn

VSCode Remote SSH の設定を「Linux」に

これでデフォルトシェルがWSLのbashになったので、VSCode側のリモート接続設定を Linux にしましょう。

設定の "remote.SSH.remotePlatform" の値を ホスト名: "linux" という形式で記載します。

{
  "remote.SSH.remotePlatform": {
    "hogemachine": "linux"
  }
}

このようにすることで、対象マシンがLinuxマシンと判断され、VSCodeもsh前提の動作をしてくれるようになるようです。

Windows設定のままだと以下のようなエラーが出てしまいます。PowerShellとかcmdとか探そうとしてしまうみたいですね。

[10:40:38.083] "install" terminal command done
[10:40:38.083] Install terminal quit with output: ]0;C:\Windows\System32\cmd.exebash: powershell: command not found
[10:40:38.083] Received install output: ]0;C:\Windows\System32\cmd.exebash: powershell: command not found
[10:40:38.084] Failed to parse remote port from server output

WSL2内でのdockerの設定を変える

何が原因なのかはわかっていませんが、devcontainerを使用しようとすると以下のようなエラーが出ました。

[2023-01-10T14:30:09.008Z]  => [internal] load build definition from Dockerfile.extended              0.0s
 => => transferring dockerfile: 3.30kB                                     0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
 => ERROR resolve image config for docker.io/docker/dockerfile:1.4         1.0s
------
 > resolve image config for docker.io/docker/dockerfile:1.4:
------
ERROR: failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: `error getting credentials - err: exit status 1, out: `A specified logon session does not exist. It may already have been terminated.``

どうもcredentialsを取得しようとしてるときにエラーが発生しているようなので、設定ファイルを見てみます。

{
  "credsStore": "desktop.exe"
}

desktop.exe とか怪しすぎるので、適当に無効な設定にしてしまいます。

{
}

これで再度devcontainerで開いてみて無事ビルドが通ればOKです。

終わりに

以上、開発環境構築記事でした。Windowsにリモートで乗り込んで開発したいとかいう珍しい方がいらっしゃったら参考になれば幸いです。

AmazonブラックフライデーでDell G5を増強しました

普段開発に使用してるゲーミングPC「Dell G5 5000」にパーツの増設を行ったのでそのメモ。

はじめに

今までもちょくちょくいじってきましたが、年末ということもあるので、PCパーツ買って整理するのもありかなと思い、購入に踏み切りました。

ohayoyogi.hatenablog.com

ohayoyogi.hatenablog.com

買ったもの

既存のゲーミングPCに増設するだけなので、正直そんなインパクトないですw

SSD: KIOXIA EXCERIA PLUS G2 1TB

まずはシステムディスクの増設用のSSDです。これは以前ノートパソコンのSSDを換装して出た余りを使っている状態だった(というかG5もここまで真剣に使うとは思っていなかった)ので、ちゃんと開発に不便しないように大きめのNVMeなSSDを買いました。

ディスクの大きさについては正直、開発のソースコードGitHubに上げますし、写真データもPrime Photoに上げるなどクラウド前提の立ち回りをするつもりなので、そんなに大きな容量は必要ないんじゃないかと思いますが、まぁ大は小を兼ねますので。

一応データ置き場として1TBの2.5インチSSDも積んであります。(以前購入したTranscendSSD

(これは余談ですが、ソースコードや依存モジュールなど、ビルド時に頻繁に読み書きするのを高速なNVMeに置いた方がいいんじゃないかーと思ったりもしますね。これ以上考えると進まなくなるのでとりあえずSATAにデータ、NVMeにシステムとしてしまいました)

写真をぺたー。これも余談ですが、販売はバッファローなんですね。

KIOXIA EXCERIA PLUS G2のパッケージ

さらに余談ですが、エクセリアといえば。(エクバシリーズ好きです)

メモリ: CORSAIR VENGEANCE LPX DDR4-3200MHz 2022限定モデル

続いてメモリです。今まではごちゃまぜのメモリ4×8GB構成でしたが、安かったのでこれを機に2×16GBで32GBとすることにしました。(増えてない)

換装した結果としては、G5で問題なく利用できているのですが、フルスペックは活かせていません。そもそも、このメモリを3200MHzで動作させるにはXMPに対応したマザーボードが必要ですが、Dell G5 5000はこれに対応していないため定格の2133MHzでの動作となる模様です。

Dellのマニュアルを読むと2666MHzでうごくっぽいぞとワクワクしていたんですが、

G5 5000 セットアップと仕様 | Dell 日本

Dell G5 5000のメモリ構成(「G5 5000 セットアップと仕様」より)

そんなことありませんでした。どうやら2666MHzで動作するのはDell純正のものを装着した場合のみ、らしい。

そこまで違いがわかるか、と言われると絶対そんなことないんですが、フルスペック出てないのは気持ちが悪いので、このメモリは自作PCするときにまた活躍してもらおうかなと思います。(とりあえずG5に付けてはおくけど)

CORSAIR VENGEANCE LPX

装着

というわけで、装着~~~~

Dell G5 5000にメモリとSSDを増設

(ほこりが汚い)

システムのセットアップ

と、今回はシステムディスクの換装を行ったので、Dell G5 5000をまっさらな状態にリカバリしてから開発環境を整えました。

OSの再インストール

Dell OS Recovery Tool」というものを使用することで、Dellのマシンに応じたUSBリカバリディスクを作成することができるので、これを使いました。(Optiplex 9020のリカバリでもお世話になりました)

www.dell.com

ポチポチとダイアログに従ってモデルやらOSの種類やらを選ぶとUSBに書き込まれるので、そこまで難しくないと思います。あとはいつも通りWindowsクリーンインストールされるのでWindows Updateで当たるドライバを片っ端から適用していけばOKです。

Windows Subsystem Linuxのインストール

もはや開発環境としてDockerは外せないですね。というわけで、まずは最初にWSL(WSL2)の導入。

最近のWindows10はすごいので、WSLコマンドが初めから入っています。管理者コマンドプロンプトから以下のコマンドをたたいてWSLを最新化したのち、

wsl --update

Microsoft StoreからUbuntuをインストールするだけ。

Microsoft StoreでUbuntuをインストールする

楽ちんですね。WSLのデフォルトバージョンを2にするのには以下のコマンド。

wsl --set-default-version 2

Docker Desktopのインストール

正直Docker DesktopのGUIは要らないんですが、インストールでごちゃごちゃするのも面倒なため、Docker Desktopを入れてしまいました。まぁ個人利用ならライセンス的にも問題ないのでいいかなと。

https://www.docker.com/products/docker-desktop/

その他もろもろ

必要に応じて必要なものを入れていきます。

などなど。まぁdockerを使えるようにしたらpythonだのnodeだのはコンテナで用意すればいいので、実質必要なのはGitとVisual Studio Codeぐらいかなという感じ。

終わりに

リカバリから始めましたが、作業環境を整えるのはそんなに時間がかかりませんでした。ドライバ回りもWindows Updateでほとんどあたりますし、Docker環境とVSCodeが整えば開発ツール系が一式揃ってしまうので、すごい時代になったなぁと感じずにはいられませんね。

と、ここまでをブラックフライデー直後の土日あたりに記事で公開する予定だったんですが、なんだかんだ年を越してしまいましたw今見たらAmazonで買ったパーツ類がブラックフライデー当時より安くなってて悲しくなっています。

TitanSlimが着弾しました

 

キックスターターでTitanSlimに出資していたんですが、8/11についに届きました!!


f:id:ohayoyogi:20220812230649j:image

Unihertz Titanシリーズ

TitanシリーズはUnihertzが手がける、今時珍しいqwertyキーボード付きのスレート型端末です。

以前からTitanPocketなど気になってはいたんですが、出資するタイミングを逃したこと、当時はfelicaを絶対視しており必須条件であったことから購入を見送っていました。しかし今回はタイミングよく出資することができたのでついに手に入れることができました。

 

やはり購入して最初にやることは、TitanSlimのキーボードを活かした文章入力だろうということで、このブログもキーボードを使ってポチポチ打ってます。まだキー配置が覚えられていないのと、打ち込む正確性が低いのでフリック入力のほうが早い気がしていますがそこには練習でなんとかしていきたいと思います。

 

f:id:ohayoyogi:20220812230711j:image

 

写真

とりあえず写真をペター

箱潰れ!!!

セットアップ中・・・

なんか画面(保護フィルム?)表面にムラが…

Titan Slim ホルスターケースも買いました

ホルスターのUnihertzロゴ

ホルスターぶ厚すぎない・・・?

TitanSlim:2枚SIMが入るのはGOOD。赤いボタンもカッコイイ



購入して即座にやったこと

というわけで、これからこのTitanSlimを使い倒していくわけですが、最初にやった設定などを記載していきたいと思います。

 

AquaMozcの導入

最初にやったのはまず、入力環境の整備です。

これについてはなんと、Unihertz Titanシリーズなどのキーボードを搭載しているAndroid向けにIMEを開発してくださってる方がいます!!それがAquaMozcです。


f:id:ohayoyogi:20220812231041j:image

 

MozcってLinuxで使ってたのですごく懐かしいのですが、こんなところで見るとは思いませんでした。WindowsIMEGoogle日本語入力」もMozcベースでしたっけ??優秀な日本語変換システムにモバイル端末のキーボード特有の操作性向けにエンハンスがなされているIMEが提供されているのはとても嬉しいことですね。

AquaMozcのように自分が購入した(もしくはこれからする)機種に特化したアプリが開発されているのって、利用者に積極的なファンがいることの証拠なのでとてもテンションがあがります。

 

HOMEボタンを2回タップに変える

HOMEボタンは指紋認証を兼ねているボタンですがこれは押し込み式ではなく触れると1タップとカウントされてしまいます。なので右手で「戻る」ボタンを押したり左手で「マルチタスク」ボタンを押そうとしたときによく誤爆してしまいます。ひどいときにはTやYに触れただけでも誤爆することがあるので、これはマストな設定かと思います。


f:id:ohayoyogi:20220812225156j:image

 

本来であれば長押しで起動するアシスタントアプリも無効化したかったところですが、どうもデフォルトのアシスタントアプリを「なし」に設定するといった知られている方法ではGoogleアシスタントが使えなくなってしまうようでしたのでこちらは断念しました。いい方法があればどなたか教えていただきたいです。例えばPTTボタンにGoogleアシスタントを設定して使用しようとすると以下のような表示になってしまいます。


f:id:ohayoyogi:20220812231106j:image

 

これが実現できると、Pixel3などで快適だったアクティブエッジによるアシスタント起動といったあの操作感に似た感じにできるのではないかと期待したんですが、どうも断念せざるをえないようです。(解決方法があればどなたかアドバイスお願いいたします)

 

スクロールアシストの有効化(解除済み)

使い始めた当初は指の位置がしっくりこず、キーボードの位置でスクロールできればいいのになーと思っていました。なのでキーボードを撫でることでスクロールを可能にする「スクロールアシスト」はとても便利なんじゃないかと思っていました。

が、やはり気になるのは操作のぎこちない感じと、バッテリー消費料が多くなるということでした。

慣れてしまうとキーボードから指を離してスクロールするのも苦ではなくなりますし、意図しないスクロールが発生してしまうという事故も防ぐことができます。

バッテリー消費については実際に測ったわけではないのでどれほどかはわかりませんが、使わないのにオンにしておくのもアレかなと思い解除してしまいました。

 

DPの変更

どちらかというと画面を見ながらチマチマ操作するのに向いているので、DPは高いほうが向いているのかなと思い、DPを480にしてみました。デフォルトは384だったので微増ですね。

 

 

二週間使ってみた感想

縦長がいい

文章を入力していると特に思うんですが、普段ソフトウェアキーボードで隠れてしまう分TitanSlimの方が画面が広く感じます。特に両手持ちを余儀なくされるため、画面からの距離が遠くなるのも寄与しているのでしょうか、フリック入力だと短文ばかりになってしまったのがTitanSlimを使うと全体を眺めて推敲しやすいような気がしました。

 

やはり重い

届く前からほかの人の写真を見てわかってはいたんですが、どうもデカくて重いのがマイナスですね。多少バッテリーが少なくなってもよいのでもうちょっと「Slim」さがほしかったなと思います。

 

Felica/イヤホンジャックが欲しい

こんだけデカ重なのであれば、機能・インタフェースマシマシにしてもらえるとよかったかなという思いからです。Felicaがない時点で2台持ちを強要されるのがマイナスです。次回に期待!

 

 

現在の使い方:キーボード付きWiFiルーター

  • デカいし重いけど、
  • バッテリー容量があって、
  • SIMカードも二枚刺さる。

これらの特徴から、現在はモバイル決済用キーボード付きWiFiルーター(何)として活用しています。

SIMカードが2枚刺さることからd払いのあの不便なドコモ回線縛り用のSIMを入れて置いたり、大容量の民泊SIMを入れておいてテザリングしたりしています。(メインで使用しているPixelシリーズは民泊SIMでテザリングできないので)。SIMカードが物理で2スロットあるのも、docomoがeSIMを延々とメンテナンスしていた背景を踏まえるとよかったんじゃないかなと思います。もうeSIM発行は普通に行っているらしいですが・・・・

 

あとは、例によってガラケーアプリのエミュレータで遊んでたりしますw

おわりに

だいぶ前に着弾していたんですが、ほかの人のレビュー読んだりダラダラしてたら普通に2か月ぐらい経過してしまいましたし、Amazonでも普通に販売されている状態になってしまいました・・・w

 

 

ほかの人のレビューに比べて、自分の場合「だめだこりゃ」というレベルではなかったので次回またUnihertzが物理キーボード付き端末を出してきたらまた買ってしまうと思います。今度は本当にスリムな端末を希望!!

NEC UNIVERGE IX2207を導入しました

背景:マンションのDHCPがつらい!

マンションのインターネット回線は共用の回線となっており、自宅のネットワークはマンション共用部のMDF室から割り当てられるLANケーブルにハブを接続し、各端末は共用のDHCPサーバーからIPアドレスが割り当てられる仕組みになっています。

そのDHCPの仕様が困ったことに、再接続した際に違うIPアドレスを割り当ててくるので、開発機のIPアドレスがコロコロ変わってしまい厄介でした。そしてどういう制御をしているのか不明ですが、一度割り振られたIPアドレスで固定しても通信不可になってしまう謎の仕様で本当に困りました。

マンションに導入されているネットワークはファミリーネットジャパン(FNJ)が運営する「CYBERHOME」というものなので、そちらに問い合わせてみると

  • 固定IPは使用しないでほしい(DHCPを使用してほしい)
  • 固定したい場合は「固定グローバルIPアドレスサービス」というオプションがあるのでそちらを使用してほしい
  • IPアドレスを固定したルーターで宅内LANを組んでほしい

といった旨の回答をいただきました。

そのオプションは初期費用1650円、月額550円といったものでしたが、どうもVPN利用も可能のようで、宅外→宅内の通信も可能になるっぽく興味深かったので申し込んでみました。

このオプションを使用する場合は、当然共用設備のルーターが賄っているファイアウォールも効かなくなるそうなので宅内でちゃんと設定する必要がでてきます。

というわけで、自宅内でのネットワークを構成するにあたり、性能面でも保守面でも「ちゃんとした」ルーターを選ぼうかなということで「NEC UNIVERGE IX2207」をチョイスすることにしました。

IX2207

迷ったほかの機種

市販のルーターでも十分サポートされて、クリティカルな問題はそうそう発生するようなものでもないというのは認識しており、中でもBuffaloの WSR-2533DHP2 などは非常に良いなと思いました。

普通に使うのに飽きたらOpenWRTでも遊べますし、性能的にもかなり良いそうです。中古の相場もGOOD。

が、純正ファームで有線LANルーターとして使用する場合のレビューなどがなかなか得づらく、調べるのが面倒くさくなってきてしまったので無線LANルーターはあくまでLANの中で使おうかなという気持ちになりました。

IX2207の兄弟機

ギガビットイーサ(1000BASE)のルーターとしてUNIVERGE IXシリーズでは「IX2106」「IX2207」「IX2215」と3種類がラインナップされています。いずれもQorIQというSoCを積んでおり、RAM 256MB、ROM 32MBと共通のスペックとなっています。

異なるのは大きさとインタフェース類、そして消費電力です。

  • 1NIC+4ポートハブのIX2106。幅が一番小さい
  • 2NIC+4ポートハブのIX2207。USBポート2ポートつき。
  • 2NIC+8ポートハブのIX2215。USBポート1ポートつき。奥行きがIX2207より大きい

消費電力はUSB不使用時は IX2106(7W) < IX2207(11W) < IX2215(14W) の順です。IX2106はこの中では比較的新しいモデルで、最低限の機能は保ちつつも小型・省電力な構成となっています。

IX2207はUSBポートが2つとちょっと冗長な印象はありますが、IX2106と比べて古いこともありヤフオクやメルカリなどでこなれた価格で売りに出されており、お財布にも優しいのがGOODポイントです。

IX2207ゲットだぜ

というわけで今回はIX2207をゲット。

取扱説明書

UNIVERGE IXシリーズ IX2000シリーズ 取扱説明書は現在こちらからダウンロードできるのでそれを参照します。

製品マニュアル・詳細: 製品マニュアル・検索一覧 | NEC

コチラの「サンプルコンフィグ作成ツール」はとても参考になります。

サンプルコンフィグ作成ツール : UNIVERGE IXシリーズ | NEC

コンソールケーブル購入

設定など何もわからず設定用のWeb画面にも入れなかったので、設定をいじるべくコンソールケーブルを購入しました。

RS232Cだと面倒だったので、とりあえずUSBのモノを探してみました。謎の会社の出品ですが、配送がAmazonだったのでまぁよいかと購入しました。 レビューにIX2135で使用できた旨書かれていたので安心して購入できました。

ボーレート 9600 bps でなんの苦労もなくつながりました。ドライバはWindows Update経由でインストールされ、普通に使えています。

終わりに

というわけで、IX2207をゲットしました。現在はDHCP + NAPTの最小構成で動かしていますが、消費電力はワットチェッカー読みで9.2Wですね。

消費電力は9.2W

ファームウェアも「UNIVERGE IXシリーズ ソフトウェアダウンロードサイトへの接続申請書」というのを提出すれば最新ファームウェアがダウンロードできるみたいなので、申請してみたいと思います。

大体気に入ってますが、大きさがやはり気になるのでIX2106が安くなってきたら乗り換えちゃおうかなぁなんて。

【ROM焼き】iPlay7t を文鎮から復活させた【7インチタブレット】

以前購入した7インチタブレット「Alldocube iPlay7t」ですが、俺はカスタムロムを焼くんじゃー!!とちょっと無理をしたところ、文鎮化させてしまいました。

今回はそこから復帰したので手順をご紹介したいと思います。対象とするのはブートローダーアンロック済みの iPlay7t です。

公式のロムのありか

文鎮化したタブレットを復活させるために公式の純正ファームウェア(ロム)を焼き直します。

まずは以下のサイトから純正ロムをダウンロードします。

Alldocube iPlay 7T(T701) firmware download – Alldocube Official Site

「iplay7t(T701)-Android9.0-ALLDOCUBE-20200520.rar」というファイルがダウンロードできるはずです。

また、このロムを本体に焼くために「ResearchDownload」というツールが必要になるので、同様に上のURLから「Spreadtrum Upgrade Tool and Guide.rar」をダウンロードします。

ResearchDownloadで焼く

ここからはロム焼きツールResearchDownloadを使って焼いていく手順を紹介します。

ドライバをインストールする

「Spreadtrum Upgrade Tool and Guide.rar」を展開すると、Driverというフォルダがあるので、その中からインストーラーを起動してドライバをインストールします。

Driver > DriversForWin10

ロム焼きツールを使用する

まずはツールで焼くロムを選択します。一番左のボタンからファイル選択画面を開き、「T701_EN_20200520.pac」など、iPlay7t用のロムを選びましょう。

ロードするファイルを選ぶ

ロードが終わったら、次は何(どの部分)を焼くかを決めていきます。左から2番目のボタンで設定画面を開きます。普通であれば何もいじる必要はないと思います。

何を焼くかを選べる

何を焼くかを決めたら、「Start Downloading」ボタンを押します。すると、デバイスが接続されるのを待機する状態になるので、、、

「Start Downloading」で待機状態に

音量(ー)ボタンを押しながらUSBケーブルでiPlay7tをつなぐと、ロム焼きがスタートします。

ロム焼き中

復活!

上記の手順を踏んで、すべてが書き込まれるとリセットがかかり、Androidが起動します。

文鎮状態から復活した iPlay7t

これだけの手順でうまくいけばメデタシメデタシ。

うまくいかない場合

と、まぁこれだけですんなりいけば正直ブログに書く必要はなかったかなと思うんですが、ハマった点や解決法などをご紹介します。

音量(ー)ボタンを押しながらつないでもFlash始まらないんだけど?

これには自分も悩まされました。つないでもWindows側で「USBデバイスが認識されません」と出てしまったり、何も反応がなかったり・・・

当時はドライバが足りないのかな?などと色々と考えたんですが、そもそも自分が文鎮化させてしまったのって、無理にResearchDownloadでほかのロムを焼きこもうとしたせいであり焼くためのドライバは足りていたはずなんですよね。それが認識されない

同様の症状の場合、それはタブレットがハングしてしまっているのかもしれません。ファームウェアを書き込んでいる途中にぶち抜いたり(ぉ、そういう手荒なことをしてしまうとなってしまうのかもしれないです(想像です)

そんな症状に効く方法は1つ 「完全放電を待つ」 です。私は1週間程度タブレットを放置してリトライを試みたところ無事再度書き込めるようになりました。

なお、バッテリーははんだ付けされており、取り外しはしんどそうだったのでオススメしません。私はビビッて触れませんでした。

バッテリーは取り外すのしんどそう

書き込みが途中で止まっちゃうんだけど?

「User canceled」だの「Uart fault」だの、「Disconnected」だのが表示されて(ちゃんとしたエラーメッセージは忘れた)書き込みが完了しない状態にも見舞われました。

これは自分もちゃんとした答えは見つけられていないんですが、「System」「Recovery」「UserData」「Vendor」など大き目のものは後回しにして、「UBOOT_LOADER」など焼けるものから焼いていった方が安定する印象を受けました。以下に自分が試した設定を載せます。

焼けるものから焼く

ただこれ、もしかすると完全放電からやっているのが原因かもしれず、正しいアプローチではないかもしれません。(小さいもの焼いている間に充電された?とか)

まぁ要は根気が大切ということですね。

試したROM

以下、自分が試したROMを記載します。なお、これは改造を推奨するものではありません。問題が発生しても一切の責任を負いませんので自己責任でよろしくお願いいたします。

T701-1101-vbmetapri-vennofbe-systemnore-recpri01.pac

XDAのフォーラムに投稿されていたロムです。言語は中国語か英語に限定されてしまいますが、Magiskを使用できるようになっています。(adb reboot recoveryで起動すると使用可)

iplay 7t (sc9832e processor) root / unlock bootloader suggestions | XDA Forums

言語が不便だったりgappsが入っていなかったりするので、まずは公式のROMを焼いた後、BootとRecoveryのみこちらのモノに差し替えるなどするとよいのかなと思います。

TWRPについても上記フォーラムで配布されていますが、TWRPに入れたもののsystemパーティションはいじれないようだったので、私は使っていません。

wangyiling氏によるROMを焼いてみた

FlokoROM-v4-20220220-UNOFFICIAL-treble_arm64_bvN.img

Flokoも導入してみました! iPlay7t は Project Treble 対応ということで、導入できるみたいだったので、以下URLからダウンロードしてsystemに焼いてみました。

FlokoROM GSI - クリーンで多機能なカスタム ROM

結果、画面が上下反転していたり、異常にモッサリしたため使用は断念しましたが、Project Trebleの可能性を感じました。

Floko(上下が逆)

終わりに

このタブレットを購入してからもう2年以上経っていますが、これを超える7インチタブレットって出てきませんね…

最近タブレットとして銘打って販売されたもの、CPUのスペックは上がっているんでしょうが、解像度が横600だったり完全に廉価に振り切った構成になっている気がします。「ちょっと大きいスマートフォン」みたいなのを買うのが正しいのでしょうか。

もうiPlay7tはAmazonで売られていないヨ・・・