mieki256's diary

一番雷が少ない県はどこなのだろうと気になってググってみたら意外なことが分かった。

_都道府県別年間雷日数 - とどラン

福島県、実はこれでも少ないほうなの…？

いや、そうでもないらしい。昔は落雷数が少なかったけど、ここ数年は多い模様。印象は間違ってなかった。

_2021年 ｜ 雷統計データ ｜ 雷（らい）ぶらり

FFFTP Ver.5.8 32bit Copyright(C) 1997-2010 Sota & cooperators.
Copyright (C) 2011-2018 FFFTP Project (Hiromichi Matsushima, Suguru Kawamoto, IWAMOTO Kouichi, vitamin0x, unarist, Asami, fortran90, tomo1192, Yuji Tanaka, Moriguchi Hirokazu, Fu-sen, potato).
Copyright (C) 2018- Kurata Sayuri.
...
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト www7.plala.or.jp ([2400:7800:0:3003::1:7]:21) に接続しています.
接続できません.

FTPS接続についてググってたら、以下の情報を見かけた。

_Windows : FTPSで大量のファイルを転送すると接続が切れる | INCOMPLETE++
_FFFTPで大量ファイルを転送すると途中で切断、おかしくなる場合の対応 - ブログ運営のためのブログカスタマイズ
_rental-server-new__002.pdf

FFFTP の、ツール → WindowsファイアウォールのステートフルFTPフィルタの設定 → いいえ、を選んでファイアウォールを無効にすることで状況が変わることもあるらしい。

以下を実行して、StatefulFTP が無効になっているか確認できる。

netsh advfirewall show global

> netsh advfirewall show global

グローバル 設定:
----------------------------------------------------------------------
IPsec:
StrongCRLCheck                        0:無効
...
StatefulFTP                           無効
StatefulPPTP                          有効
...

試してみたけれど、今回の不具合は解決しなかった。

どうやらこの話は、サーバにアクセスができて、ファイル転送をしている時に絡んでくる話のようだなと…。

今回は FreeBSD-13.1-RELEASE-i386-disc1.iso を入手した。i386、CD版。

_Get FreeBSD | The FreeBSD Project

VMware で仮想PCを新規作成する際は、FreeBSD 12 を選んだ。RAM: 1GB, CPUコア: 3 で作成。

解説記事を眺めながら作業していったら比較的スンナリとインストールができた。ただ、途中で日付と時刻を尋ねてくるあたりは変更しないといけないらしい。また、最初のユーザ追加時は、group に wheel も指定しておく。

インストールが終了して、再起動したら root でログイン。以下を打ち込んでパッケージを最新版に更新。

freebsd-update fetch
freebsd-update install
pkg update
pkg upgrade
portsnap fetch extract
portsnap fetch update

デスクトップ環境が欲しいので以下を打ち込む。

pkg install xorg

startx で、twm が起動する。

vim や xfce も欲しい。日本語フォントも少しインストールしておく。

pkg install vim
pkg install xfce
pkg install ja-font-std ja-font-vlgothic ja-font-takao

sudo と、GUIで利用できるパッケージ管理ツール octopkg その他をインストール。

pkg install octopkg sudo
pkg install portmaster

sudo を設定。

visudo

先頭の行の「#」を消してコメントアウトを外す。これで、wheelグループに属しているユーザは sudo が使えるようになる。

%wheel ALL=(ALL) ALL

VMware上で動かしているので、Open VM Tools もインストール。Open VM Tools をインストールすれば、ホストPCのデスクトップと仮想PCのウインドウ内でマウスカーソルをシームレスに移動できたり、クリップボードの共有ができるようになる。

pkg install -y xorg open-vm-tools xf86-video-vmware xf86-input-vmmouse

vim /etc/rc.conf

dbus_enable="YES"

vim /usr/local/etc/X11/xorg.conf.d/input-vmmouse.conf

Section "InputClass"
        Identifier      "Mouse0"
        Driver          "vmmouse"
        MatchIsPointer  "on"
EndSection

Xfceが起動するように、~/.xinitrc を修正しつつ、VMware関連ツールも実行するように指定。

vim ~/.xinitrc

. /usr/local/etc/xdg/xfce4/xinitrc
nohup vmware-user-suid-wrapper 2>&1 > /dev/null &

この状態で startx をすれば、Xfceが起動する。

デスクトップ環境(X-Window)が起動すると、キーマップが英語になってしまう。日本語キーボードの配置になるように変更。

vim /usr/local/etc/X11/xorg.conf.d/input.conf

Section "InputClass"
    Identifier          "libinput keyboard catchall"
    MatchIsKeyboard     "on"
    MatchDevicePath     "/dev/input/event*"
    Driver              "libinput"
    Option              "XkbRules"      "evdev"
    Option              "XkbModel"      "jp106"
    Option              "XkbLayout"     "jp"
    Option              "XkbOptions"    "ctrl:nocaps"
EndSection

FreeBSDはデフォルト状態だと、シェルが sh だったりするらしい。不便。bash にしたい。以下の記事を参考にして作業させてもらった。

_FreeBSD: ログインシェルをbashに変更手順 - よしまさのブログ

echo $SHELL
which bash
chsh -s /usr/local/bin/bash

~/.bash_profile を作成。もし ~/.bashrc が存在するなら読み込むように指定しておく。

vim ~/.bash_profile

# .bash_profile
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi
PATH=$PATH:$HOME/bin:$HOME/usr/local/bin
export PATH

~/.bashrc を作成

vim ~/.bashrc

# .bashrc

alias cp='cp -i'
alias mv='mv -i'
alias rm='rm -i'
# alias l='ls -CF --color=auto'
# alias la='ls -A --color=auto'
# alias ll='ls -alF --color=auto'
# alias ls='ls --color=auto'
alias l='ls -CFG'
alias la='ls -AG'
alias ll='ls -alFG'
alias ls='ls -G'
alias vi='vim'

FreeBSd標準のlsは -G をつけるとカラー表示になるっぽい。--color=auto つけてカラー表示になるのは GNU ls らしい？

_lsをカラー表示にする - FreeBSD入門

以下を参考にして日本語入力ができるようにしておいた。

_FreeBSDで遊ぼうのこーな
_デスクトップ環境の設定 [Share FreeBSD based information]

pkg install ja-font-std ja-font-vlgothic ja-font-takao 
sudo pkg install ja-fcitx-mozc

~/.xinitrc を修正。

vim ~/.xinitrc

#!/bin/sh
export LC_ALL=ja_JP.UTF-8
export LANGUAGE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=xim
export XMODIFIERS=@im=fcitx
/usr/local/bin/mozc start
fcitx -r -d
setxkbmap -layout jp
. /usr/local/etc/xdg/xfce4/xinitrc
nohup vmware-user-suid-wrapper 2>&1 > /dev/null &

~/.xseesion も同じ内容で作成した。

_FreeBSDに日本語入力できるようにする - OpenBSD で システム構築
_Starting X

実行権限をつけておかないといかんらしい。

cp ~/.xinitrc ~/.xsession
chmod 744 ~/.xsession

余談。ログアウトするときに「セッションを保存」にチェックを入れていると次回ログインできなくなる…。加えて、どうも時々 ~/.xinitrc の中身が昔の内容に書き戻されてしまう時があるような気がする…。何故だろう…。

ディスプレイマネージャとして slim をインストールしてみたのだけど、どうせ自分しか触らない環境なので、自動ログインをさせたい。

_Xfce - Autologin with SLiM to XFCE4 | The FreeBSD Forums

/usr/local/etc/slim.conf を編集。

sudo vim /usr/local/etc/slim.conf

default_user        YOURNAME
auto_login          yes

しかし上手く行かない。真っ黒な画面しか出てこない。とりあえずコメントアウトして自動ログインは諦めた。

• ユーザ追加 : adduser
• ユーザ削除 : rmuser
• パッケージ削除 : pkg delete PACKAGE_NAME

今回の環境(Windows10 x64 22H2 + VMware)では、snd_es137x が使われるらしい。/boot/loader.conf に以下を追記しておいた。

snd_es137x_load="YES"

mixer を起動して vol と pcm のボリュームを調整しないと音が小さくて聞こえなかった。

mixer
mixer vol 100 pcm 100

_FreeBSD で音がでなかったのは mixer の値が悪かったから: uyota 匠の一手

xfce4-mixer をインストールすると、Xfceのパネルに音量アプレットを追加することができるようになる。xfce4-mixer-full をインストールしてしまうと gstreamer がどうとか言われて調整できないので注意。

sudo pkg install xfce4-mixer

ただ、OS起動時に何故かミュート状態になってしまう。何故。

_番外編: VMware Player を使って Windows 10 に FreeBSD をお招きする _FreeBSDで遊ぼうのこーな
_FreeBSD 13.1 楽してデスクトップ環境を構築したい（その１） | INSUKO.NET
_FreeBSD 13.1 楽してデスクトップ環境を構築したい（その２） | INSUKO.NET
_FreeBSD デスクトップ環境の構築　1 (a). FreeBSDのインストール(FreeBSD Latest) - [SILVER SACKの自画自賛]
_FreeBSD デスクトップ環境の構築 - 2(a). FreeBSDの初期設定とPackage/Portsに関連する初期作業(FreeBSD Latest) - [SILVER SACKの自画自賛]
_FreeBSD デスクトップ環境の構築 - 3(a). xorgのインストールとデバイスに関連する設定作業(FreeBSD Latest) - [SILVER SACKの自画自賛]
_VMware Workstation Player で，仮想マシンの新規作成と，ゲスト OS として FreeBSD バージョン 12.1 をインストール
_FreeBSD で portupgrade を用いて，アプリケーションソフトウェアの再インストールや全更新

gimp 2.10.34 をインストールしてみた。

sudo pkg install gimp

FreeBSD 13.1 i386版上で、GIMP + Python-Fu (Gimp-Python) が使えるのかどうか確認したくて、今回 FreeBSD をインストールしてみたのだけど。やはりダメだった。Python-Fu は動かない。

どうやら現状では、32bit版の Linux や BSD上で、Python-Fu (Gimp-Python) は動かせないようだなと…。

ちなみに 64bit版の Linux なら、flatpak版のGIMPをインストールすることで、まだ Python-Fu を動かせる。flatpak は 64bit版のバイナリしか提供してないので、32bit OS では動かせない。

余談。FreeBSD 13.1 上では、Python 2.7 は python2.7、Python 3.x は python という実行ファイル名で用意されていた。

$ python2.7 -V
Python 2.7.18
$ python -V
Python 3.9.17

VMware + FreeBSD 13.1 i386 で、何度か再起動やシャットダウンをしているうちに、一般ユーザがデスクトップにログインできない状態が何度も発生した。調べてみると、~/.xsession、~/xinitrc、~/Desktop/、~/Downloads/ が消滅していたり、ファイル内容が以前の内容に書き戻されていることに気づいた。

zfs なるファイルシステムでインストールしてしまったせいだろうか…？ VMware と zfs は相性が悪いのか…？ あるいは、zfs には、まだ致命的なバグがある？

それとも、ホストOSが64bit、ゲストOSが32bit(i386)だと、こういうことが起きるのだろうか…？

FreeBSD 13.1 のバグだろうか？ FreeBSD 12.4 なら、まだマシだったりするのかしらん。公開された日付は、12.4 のほうが新しいのだよな…。

VMware上で動かすからいかんのだろうか。例えば VirtualBox上で動かせば、あるいは実機上で動かせば、安定動作するのだろうか。

ぷららのサイトでは、FTPツール、FFFTP 1.96d で接続できているかのような記述があるのだけど。

_プライベートホームページマニュアル | その他 | ぷらら
_FTPソフト設定（ファイル転送ソフト）FFFTP（Windows） - ffftp.pdf

しかし、FFFTP 1.96d は、今現在は入手不可能。元々の作者様のページで現在公開されているのは 1.97b (ffftp-1.97b.exe, ffftp-1.97b.zip, ffftp-1.97b-src.zip) なわけで…。

_Sota's Web Page (FFFTP)

Web Archive も調べてみたけど、1.96d は無かった…。Filter 入力欄に「ffftp-1.9」と打ち込めばセットアップファイルがリストアップされるけど、FFFTP 1.96d は無い。ちなみに、FFFTP 1.96d のセットアップファイル名は、ffftp-1.96d.exe、ffftp-1.96d.cab だったらしい。

_http://www2.biglobe.ne.jp/sota/product/* - Wayback Machine
_Sota's Web Page (FFFTP) - (WebArchive, 2010/01/09)

もう入手できないバージョンを使って、「ウチでは動作確認取れてますけど？」と言い出すのは…ソレってどうなの？ と思わないでもない…。

ネットから入手するのは難しいけれど、幸い手元のHDDの中を漁っていたら、どうにか ffftp-1.96d.exe を発掘することはできた。残しておいてよかった…。インストーラ版しか残ってなかったのは痛いけど、一応インストール。

動作確認をしようとしたのだけど…。


御覧の通り、「ホストの設定」ダイアログに、「暗号化」タブがそもそも存在しなかった。これではFTPS接続するための設定ができない。

オイコラ、NTTドコモ！ てめえらふざけてんじゃねえぞ！(憤怒)

ドキュメントにツールのバージョンまで書いておくのは偉いですなと一瞬思ってしまったけれど、今ではもう入手不可能な上に、動作するわけがないバージョンがしれっと書いてあるとかさあ…。コレ一体どういうことなんですか…。自分が使ったツールのバージョンを確認して明記することすら満足にできないのですか…。いやまあ、そもそも動作確認すらしてないのかもしれんけど。

該当バージョンを入手しようとめちゃくちゃググりまくって探しまくったのに、何ですか、このオチ。ふざけんな。ぷんすか。

ちなみに、FFFTP 1.96d はGumblarウイルスがパスワードを盗み取ることが問題になってたバージョンで…。

_Sota's Web Page (GumblarによるFFFTPへの攻撃について)
_FTP アカウント情報を盗むマルウエアに関する注意喚起について | Security Alert | 京都大学情報環境機構
_FFFTPのバグ 〜必要なGumblar対策を: パソコンのツボ 〜 Office のTIP
_「FFFTP」のパスワードが“Gumblar"ウイルスにより抜き取られる問題が発生 - 窓の杜

わざわざそんなバージョンをドキュメントに書いておくとか、NTTドコモだかぷららだかどこが担当してるのか知らんけどお前等大丈夫か？ という気分に…。

とりあえず、今まで手元で使ってた FFFTP 4.5 x86 や、今現在入手できそうな FFFTP のバージョンを色々試してみた。

ちなみに、現行バージョンは窓の杜や github から入手できる。

_「FFFTP」定番FTPクライアントソフト - 窓の杜
_Releases - ffftp/ffftp - GitHub

FFFTP 1.98g 等のバージョンはOSDNから入手できる。

_リリース FFFTP（日本語版） 1.98g - FFFTP - OSDN

ショートカットファイルがこんなにたくさん。

• FFFTP 1.96d : 「ホストの設定」に「暗号化」タブが無いので論外。FTPS接続の設定ができない。
• FFFTP 1.97b : これも「ホストの設定」に「暗号化」タブは無かった。
• FFFTP 1.98g : これは「暗号化」タブがあった。
• FFFTP 4.5 x86 : これも「暗号化」タブがあった。
• FFFTP 5.8 x86 : これも「暗号化」タブがあった。

FFFTP 1.98g 以降であれば、FTPS接続できる機能は持っているようだなと…。

ただ、どのバージョンを使っても、ぷららのFTPサーバ(www7.plala.or.jp)には接続できなかった。

• ホスト設定の「PASVモードを使う」の有効無効を切り替え。
• ホスト設定の「ネットワークの種類」を、「自動」「TCP/IPv4」「TCP/IPv6」にそれぞれ切り替え。(FFFTP 1.98g には設定項目があった。FFFTP 4.5、5.8 に該当の設定項目は無い)

これらの設定を変えてみたけれど、結果は変わらなかった。

一応、メッセージ欄の表示も貼っておく。

FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
Copyright (C) 2011-2013 FFFTP Project (Hiromichi Matsushima, Suguru Kawamoto, IWAMOTO Kouichi, vitamin0x, unarist, Asami, fortran90, tomo1192, Yuji Tanaka, Moriguchi Hirokazu).
デフォルトのマスターパスワードが使われます.
マルウェアの攻撃を防ぐため，固有のマスターパスワードを設定することをおすすめします
OpenSSLが読み込まれました.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト www7.plala.or.jp を探しています. (TCP/IPv4)
ホスト www7.plala.or.jp を探しています. (TCP/IPv6)
ホスト www7.plala.or.jp (2400:7800:0:3003::1:7 (21)) に接続しています. (TCP/IPv6)
ホスト www7.plala.or.jp (60.43.63.107 (21)) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
接続できません. (TCP/IPv6)

接続できません.

FFFTP Ver.4.5 32bit Copyright(C) 1997-2010 Sota & cooperators.
Copyright (C) 2011-2018 FFFTP Project (Hiromichi Matsushima, Suguru Kawamoto, IWAMOTO Kouichi, vitamin0x, unarist, Asami, fortran90, tomo1192, Yuji Tanaka, Moriguchi Hirokazu, Fu-sen, potato).
Copyright (C) 2018-2019, KURATA Sayuri.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト www7.plala.or.jp ([2400:7800:0:3003::1:7]:21) に接続しています.
接続できません.

FFFTP Ver.5.8 32bit Copyright(C) 1997-2010 Sota & cooperators.
Copyright (C) 2011-2018 FFFTP Project (Hiromichi Matsushima, Suguru Kawamoto, IWAMOTO Kouichi, vitamin0x, unarist, Asami, fortran90, tomo1192, Yuji Tanaka, Moriguchi Hirokazu, Fu-sen, potato).
Copyright (C) 2018- Kurata Sayuri.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト www7.plala.or.jp ([2400:7800:0:3003::1:7]:21) に接続しています.
接続できません.

余談。1.98g も試したのは、以下のつぶやきを見かけたから。

_Shu ENKZNさんはTwitterを使っています: 「懸案だったぷららホームページのアップロード問題が... / X

懸案だったぷららホームページのアップロード問題が解決する。FFFTP については、FFFTP（64bit版）v5.7を使っていたが。動作が不安定で。FFFTP for Windows V 1.98g に変更したら Windows 11 でも問題なくアップロード可となる。

もしかしてウチの環境は、IPv6しか提供されてないサーバにアクセスできないのではないか…？ などと不安になったので、IPv6で接続できるかどうかチェックできそうなサービスをググってみた。

_あなたの IPv6 をテストしましょう。
_IPv6接続確認 | 株式会社JPIX
_IPv4/IPv6接続判定ツール

どれも「IPv6でアクセスできるよ」と表示される…。うーん。

そもそも、2023/08/02の時点では、1度はたしかにぷららのFTPサーバにFTPS接続できていたわけで…。

WinSCP 6.1.1 や、FileZilla 3.65.0 でも試してみたけど、やはりサーバに接続できないと表示されてしまう…。

_「WinSCP」SCP/SFTP/FTPS対応のFTPクライアント - 窓の杜
_FileZilla - The free FTP solution

ホームページビルダー V20、FFFTP も含めて、4つのFTPクライアントソフトで試してみても接続できないこの状況はあかんやろという気がする…。

Ubuntu Linux 22.04 LTS + FileZilla 3.58.0 でも試してみたけど、やはりサーバに接続できないと表示されてしまう。

sudo apt install filezilla

状態:   www7.plala.or.jp のアドレスを解決中
状態:   60.43.63.107:21 に接続中...
状態:   接続を確立しました。ウェルカム メッセージを待っています...
エラー: サーバーによって接続が閉じられました
エラー: サーバーに接続できません

OSを変えてもダメか…。

お問い合わせ → フォームでお問い合わせ、から問い合わせてみた。

_お問い合わせ | 会員サポート | ぷらら

朝方送信しておいたところ、夜になってメールが届いた。「ホスト名に www7.plala.or.jp を指定しているところを IPv4 のIPアドレス、xx.xx.xx.xx にしてみよ」とのこと。

メールに記述されていたIPアドレスは、FFFTP 1.98g で試したときに表示されたIPアドレスと同じだった。

ということは、www7.plala.or.jp からIPアドレス(IPv4)への変換はできてる、ということになるのかな。ただ、FFFTP 4.5, 5.8 では www7.plala.or.jp が IPv6 に変換されてしまう。FFFTP 1.98g のような古いバージョンじゃないと IPv4 のIPアドレスが得られない。

メールにIPv4アドレスが記述されていたあたり、「IPv6でアクセスはするな」ということでもあるのだろう…。FFFTP 1.98g のホスト設定で、「ネットワークの種類」を「TCP/IPv4」にしてみた。ちなみに、FFFTP 4.5, 5.8 では、その設定項目は無くなっている。古い FFFTP じゃないと IPv4 に制限できないわけで…。ぷらら側のサーバ設定はマズい気がする。

メールには、「『暗号化ありで接続を許可』にチェックを入れろ」と書いてあったけれど、そんな設定項目は無い…。ただ、「暗号化なしで接続を許可」という項目はあるので、そこのチェックを外しておいた。というか、サポートマニュアルのスクリーンショット通りにやってるから、既に外してあった。

とりあえず試してみたけど、やはりダメだった。

FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
Copyright (C) 2011-2013 FFFTP Project (Hiromichi Matsushima, Suguru Kawamoto, IWAMOTO Kouichi, vitamin0x, unarist, Asami, fortran90, tomo1192, Yuji Tanaka, Moriguchi Hirokazu).
デフォルトのマスターパスワードが使われます.
マルウェアの攻撃を防ぐため，固有のマスターパスワードを設定することをおすすめします
OpenSSLが読み込まれました.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト 60.43.63.107 (21) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)

接続できません.

他の組み合わせでも試してみたけれど。

• Windows10 x64 22H2 + FFFTP 5.8
• Windows10 x64 22H2 + WinSCP 6.1.1
• Windows10 x64 22H2 + FileZilla 3.65.0
• Ubuntu Linux 22.04 LTS + FileZilla 3.58.0

やはり結果は変わらず。サーバに接続できない。

ちなみに、Ubuntu Linux 22.04 LTS + FileZilla 3.58.0 の結果は以下。

状態:   60.43.63.107:21 に接続中...
状態:   接続を確立しました。ウェルカム メッセージを待っています...
エラー: サーバーによって接続が閉じられました
エラー: サーバーに接続できません

ユーザ名やパスワードが間違っている可能性も考えたけど、それ以前の段階で接続できてない気がする。

と言うのも、自宅サーバを相手にして、FFFTPからわざとパスワードを間違えた状態でアクセスして結果を確認したところ、どの場合もユーザ名の送信まではそれなりに進む(コマンドが送られて返事が戻ってくる)し、パスワードが間違ってたらFFFTPが「パスワードが違う」とちゃんと尋ねてくることが分かったので…。

FTPサーバがユーザ名を受け付けたところまで進んでいて、そこでログインできなかったら、これはユーザ名やパスワードが間違ってると推測できるけれど。今回はそこまで全然進んでないので、ユーザ名やパスワードがおかしいというわけではないのだろう。問題はもっと前の段階で起きてる。

そもそも、FFFTP等から正常にFTPSで接続できた際、どういうログが表示されるのだろう。そこからして分からなかったので、LAN内でFTPS (Explicit) 接続できるFTPサーバを立てて動作確認してみようと思い立った。

とりあえず、足元に置いてあるサブPC、Ubuntu Linux 22.04 LTS (Core i3-6100T機)に、FTPサーバ、vsftpd 3.0.5-0ubuntu1 がインストール済みだったので、設定(/etc/vsftpd.conf)を変更して、FTPS(Explicit)接続ができるようにしてみる。

• 接続先はLAN内の Ubuntu Linux 22.04 LTS + vsftpd 3.0.5。ぷららのFTPサーバじゃなくて、LAN内の実験用サーバ。
• FTPクライアントを動かしたOSは、Windows10 x64 22H2。

動作確認に使ったFTPクライアントは以下。 LAN内 の Ubuntu Linux + vsftpd にFTPS接続できたかどうかの結果も書いておく。勘違いされるとマズいので再度書く。ぷららのFTPサーバじゃないよ。LAN内の、だよ。

FTPクライアント	接続成功/失敗
FileZilla 3.65.0	Success
WinSCP 6.1.1	Success
Cyberduck 8.6.2	Success
FFFTP 1.98g	Success
FFFTP 2.00 x86	Success
FFFTP 4.5 x86	Failure
FFFTP 5.8 x86	Failure
FFFTP 5.8 x64	Failure

自分の手元の環境では、FFFTP 3.x以降のバージョンは、ことごとくFTPS接続に失敗している。

FFFTP は、2.00までと、3.x以降で、SSL/TLS関係の処理がごっそり変わっているそうで。2.00までは自前でSSL/TLS関連ファイルを持って処理をしていたけれど、3.x以降はWindowsが持ってる機能を使って処理するようになって、そのせいか環境によってFTPS接続ができたりできなかったりするらしい。

ネット上では「FTPS接続したいならFFFTPで」的に紹介されていることが多いけれど、今現在、一般的に入手しやすい FFFTP は 3.x以降なので、この状況はマズい気がする…。FTPサーバの種類、サーバ側設定との相性がかなりあるのではないか…。安易にFFFTPを推奨するのは危ない…。そのあたり、ぷららは分かっているのだろうか？ もちろん、フツーのFTP接続なら悪い選択肢では無いだろうけど。自分も普段使っているし。

ちなみに、「FFFTP の 32bit(x86) と 64bit(x64) で動作が変わるのではないか？」「OSが64bit版なら FFFTP も64bit版を選ばないとダメなのではないか？」と思ったけれど。試したところ、そのあたりは関係なさそう。動作に違いは無かった。

念のため、FFFTP 5.8 x64 から、 Ubuntu Linux 22.04 LTS + vsftpd にアクセスしてみた際のログ(?)も書いておく。ぷららのFTPサーバじゃないよ。

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.5.8 64bit Copyright(C) 1997-2010 Sota & cooperators.
 ...
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t (192.168.1.11:21) に接続しています.
 接続しました.
 220 Welcome to blah FTP service.
 >AUTH TLS
 234 Proceed with negotiation.
 ## InitializeSecurityContextW() failed(0x80090326): 予期されない、または形式が間違ったメッセージを受信しました。
 ログインできません.
 ## Skt=2208 : Socket closed.

FTPクライアント側(FFFTP)が、AUTH TLS を送信した直後にエラーが出て失敗している。

逆に考えると、FTPサーバ側がそこそこ真っ当に設定できていれば、FTPクライアントから AUTH TLS を送信するところまでは少なくとも進むはず、と言えそう。

しかし、ぷららのサーバはそこまで進まず、上記で言えば 220 すら返ってこない状態なので、やはりぷらら側で何かを間違えてしまっているとしか思えないわけで…。

各FTPクライアントは以下から入手できる。

_FFFTPの詳細情報 : Vector ソフトを探す！ (FFFTP 2.00が入手可能)
_Releases - ffftp/ffftp - GitHub (FFFTP 3.x以降が入手可能)
_FileZilla - The free FTP solution
_Cyberduck
_「WinSCP」SCP/SFTP/FTPS対応のFTPクライアント - 窓の杜

本来、FFFTP 2.00以前は OSDN から入手できるはずなのだけど、OSDNがずっと 504。つい最近、OSDNが中国企業に売られてしまったことが関係しているのだろうか…？

_接続不調が続く「OSDN」、米「SourceForge」がプロジェクトの勧誘に乗り出す - やじうまの杜 - 窓の杜

ググっていたら、Vector から FFFTP 2.00 を入手できることが分かった。下のほうにスクロールしていくと 2.00 (ffftp-2.00.zip) がある。助かった。

_FFFTPの詳細情報 : Vector ソフトを探す！

以下を参考にしながら vsftpd の設定をしていった。

_Ubuntu 22.04 LTS : Vsftpd Over SSL/TLS 設定 : Server World
_Ubuntu 20.04 で SSL/TLS を使用して FTP サーバー (vsftpd) をインストールおよび構成する方法
_vsftpd over TLS/SSL@cbreeze
_CentOS vsftpdでSSL/TLS暗号化接続が出来ないまたは途中で止まる - POCH-7003 BEATout!
_vsftpd - Over SSL/TLS 設定すると FileZilla でエラー！ - mk-mode BLOG

vsftpd に、FTPS接続の設定をしていく。

FTPS接続を可能にするためには、証明書なるものが必要らしい。外部に公開するサーバならちゃんとした証明書が必要らしいけど、今回はあくまでLAN内で実験するだけなので、自己署名の証明書なるものを作成して作業を進める。

以下を実行して、/etc/ssl/private/vsftpd.pem として証明書を作成。途中で国コードやら何やらを尋ねてくるので入力する。

sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

$ sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

...+.......+..+...
...
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP                                # 国コード
State or Province Name (full name) [Some-State]:Fukushima           # 地域(都道府県名)
Locality Name (eg, city) []:Sukagawa                                # 都市
Organization Name (eg, company) [Internet Widgits Pty Ltd]:RAD11    # 組織名
Organizational Unit Name (eg, section) []:                          # 組織の部門名 
Common Name (e.g. server FQDN or YOUR name) []:i36100t              # サーバのFQDN
Email Address []:yourname@example.com                               # 管理者のメールアドレス

サーバのFQDNとやらは、そのPCの hostname をそのまま入力したほうが良さそう。

念のためにアクセス権を変更。Ubuntu Linux 22.04 LTSの場合、最初から600になってた。

sudo chmod 600 /etc/ssl/private/vsftpd.pem

sudo vi /etc/vsftpd.conf

# 149行以降

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO

ssl_ciphers=HIGH

# ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

# ssl_ciphers=kEECDH+AESGCM+AES128:kEECDH+AESGCM:kEECDH+AES128:kEECDH+AES:!aNULL:!eNULL:!LOW:!EXP

force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
# ssl_tlsv1_1=YES
# ssl_tlsv1_2=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO

strict_ssl_read_eof=NO

# Passive mode
pasv_enable=YES
# pasv_min_port=40000
# pasv_max_port=40030
pasv_min_port=60000
pasv_max_port=60010

vsftpdを再起動。

sudo systemctl restart vsftpd.service

これでFTPS接続ができるようになった。

FFFTP 1.98g でFTPSサーバ(vsftpd)にアクセス後、ファイルを転送してみたら以下のエラーが出た。

426 Failure reading network stream.

以下で解説されていた。

_vsftpdにアップロードしたら"426 Failure reading network stream."エラーが出るときの解決法 - Qiita

マニュアルのstrict_ssl_read_eofの項目にはDefault: NOと書いてあるがマニュアルの誤記で実際にはデフォルトYESである。

設定ファイルを変更して、strict_ssl_read_eof=NO を追記したところ、エラーは出なくなった。

sudo vi /etc/vsftpd.conf

strict_ssl_read_eof=NO

/etc/vsftpd.conf 内に記述する内容について、以下のような記述も見かけたが、実際に /etc/vsftpd.conf に記述してしまうと、Windows10 x64 22H2 + FFFTP 1.98g、FFFTP 2.00 x86、FileZilla 3.65.0 でFTPS接続できなくなってしまった。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
ssl_tlsv1_1=YES
ssl_tlsv1_2=YES

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.2.00 Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t を探しています. (TCP/IPv4)
 ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
 ## #### Connect: Error=10061
 接続できません. (TCP/IPv4)
 ## Skt=2236 : Socket closed.

以下の記述なら、FTPS接続ができた。何故。

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

巷の解説記事では、以下のように、TLS 1.2 のみを有効にしている指定が多いのだけど…。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=NO
ssl_tlsv1_1=NO
ssl_tlsv1_2=YES

皆、一体どのOS/FTPクライアントを使って動作確認してるのだろう…？

また、以下のような記述も見かけた。

ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

これを設定しても、FFFTP 1.98g、FileZilla 3.65.0 から接続できた。でもまあ、今回は以下の指定にしておく。

ssl_ciphers=HIGH

FFFTP 1.98g で、vsftpd にFTPS接続できた時の結果は以下。

FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
...
OpenSSLが読み込まれました.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト i36100t を探しています. (TCP/IPv4)
ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
220 Welcome to blah FTP service.
>AUTH TLS
234 Proceed with negotiation.
>PBSZ 0
200 PBSZ set to 0.
>PROT P
200 PROT now Private.
>USER hogeuser
331 Please specify the password.
>PASS [xxxxxx]
230 Login successful.
>FEAT
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
>TYPE A
200 Switching to ASCII mode.
>PASV
227 Entering Passive Mode (192,168,1,11,225,252).
ダウンロードのためにホスト 192.168.1.11 (57852) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
>LIST
150 Here comes the directory listing.
226 Directory send OK.
...

この結果から、いくつかのことが分かる。

1. まず、FFFTP が「接続しました. (TCP/IPv4)」と言ってきた直後、FTPサーバから送られてきたウェルカムメッセージ、「220 Welcome to blah FTP service.」が表示される。
2. その直後、FTPクライアントは、「AUTH TLS」を送信する。暗号化通信関係のコマンドだろうか。サーバ側は「234 Proceed with negotiation.」を返してきて…。
3. その後、何度かやり取りして、暗号化通信が有効になるのだろう。そこでようやくFTPクライアントは、ユーザ名を「USER hogeuser」で送信する。
4. サーバから「331 Please specify the password.」が返ってきたら、FTPクライアントはパスワードを「PASS [xxxxxx]」で送信してやる。
5. パスワードが間違ってなければ、サーバは「230 Login successful.」を返してくる。
6. そこから、PASVモードを有効にしたり、ファイルの一覧を取得したり、といったやり取りになっていく。

つまり、正常にFTPS接続できているなら…。

• まずサーバは、ウェルカムメッセージを 220 で返してくる。
• そこでようやくFTPクライアントは「おい磯野、暗号化通信しようぜ！」的に「AUTH TLS」を送信する。
• ユーザ名やパスワードのやり取りをするのは、「AUTH TLS」が通った後の話。

まずはFFFTPのログに「AUTH TLS」が出てこないと話にならない。

「AUTH TLS」が出てきていないのに「ユーザ名やパスワードが間違ってませんか？」「パスワードが短すぎるのでは？」などと言い出すのは頓珍漢な話、ということになるのだろう。たぶん。

FileZilla 3.65.0 でアクセスした時の結果は以下。

状態:           i36100t のアドレスを解決中
状態:           [2405:6583:3200:b100:cdd6:8f8c:4b36:a61f]:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 Welcome to blah FTP service.
コマンド:       AUTH TLS
レスポンス:     234 Proceed with negotiation.
状態:           TLS を初期化しています...
トレース:       TLS Handshake successful
トレース:       Protocol: TLS1.3, Key exchange: ECDHE-SECP256R1-RSA-PSS-RSAE-SHA384, Cipher: AES-256-GCM, MAC: AEAD, ALPN: ftp
状態:           TLS 接続が確立されました。
コマンド:       USER hogeuser
レスポンス:     331 Please specify the password.
コマンド:       PASS ********
レスポンス:     230 Login successful.
状態:           サーバーは non-ASCII の文字をサポートしていません。
コマンド:       PBSZ 0
レスポンス:     200 PBSZ set to 0.
コマンド:       PROT P
レスポンス:     200 PROT now Private.
状態:           ログインしました
トレース:       Measured latency of 4 ms
状態:           "/public_html/plala" のディレクトリ リストを取得中...
コマンド:       CWD /public_html/plala
レスポンス:     250 Directory successfully changed.
コマンド:       TYPE I
レスポンス:     200 Switching to Binary mode.
コマンド:       EPSV
レスポンス:     229 Entering Extended Passive Mode (|||60004|)
トレース:       Binding data connection source IP to control connection source IP 2405:6583:3200:b100:bc64:5065:7fdf:7cb5
トレース:       Trying to resume existing TLS session.
コマンド:       LIST
レスポンス:     150 Here comes the directory listing.
トレース:       TLS Handshake successful
トレース:       TLS Session resumed
トレース:       Protocol: TLS1.3, Key exchange: , Cipher: AES-256-GCM, MAC: AEAD, ALPN: 
レスポンス:     226 Directory send OK.
状態:           "/public_html/plala" のディレクトリ リストの表示成功

やはり、サーバから220が返ってきてから AUTH TLS を送ってる。FFFTPと違って、AUTH TLS を送って 234 が返ってきたら、すぐにユーザ名やパスワードを送って、その後、PBSZ 等を送ってるようだなと…。

ところで、今朝、再度ぷららのサイトのフォームから問い合わせをしてみたわけで…。以下のFFFTPのログも一緒につけて、「FTPS接続できません。何かこちらで試せることはありますか？」と尋ねてみたわけで…。

 FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト 60.43.63.107 (21) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)

 接続できません.

夕方頃、ぷららサポートセンターからメールで返事が来たわけで…。「パスワードが短すぎるのかもしれない。7文字以上にしてみてくれ」とのこと。

あのさあ。こちらから送ったFFFTPのログを眺めれば、そこじゃないと分かるだろうよ…。

もちろん、サポートさんの仰る通り、一応、念のため、パスワード変更も試してみたけれど、やはり状況は変わらず。当たり前だけど。

だって、パスワードを送るどころか、ユーザ名すらFTPクライアントから送ることができてないし、そもそも「おい磯野、暗号化通信しようぜ！ (AUTH TLS)」すらあちらに送れてないわけで…。「おい、いそ」と言い出す前にカツオ(www7.plala.or.jp)が電話ガチャン、みたいな。カツオのスマホの電話番号(IPアドレス)に電話してるから、おそらくカツオが電話を取ったんじゃねえかな、ぐらいは想像できるけど、取り付く島もないというか。

ログを見ればそういうことが分かるはずなんだけど、最初から見る気ゼロで答えてるんだろうな…。 *1

これはもう只の邪推と愚痴だけど。ぷららでは、サポート担当の人と、サーバの設定をしてる人の間で、連絡を取り合う手段が一切何もなくて、もう返事のしようもないのかもしれない。だから「パスワードを」とか言ってお茶を濁そう(?)としてるのかも。

あるいは、メールを返してきているのは、AIなのかもしれない…。どうも話が通じていない感があるし…。AIが相手では、そりゃFFFTPのログを見せても理解できるわけがないよな…。

しかし、だとしたら、よくないなあ。せっかくユーザがサービスの障害報告をしてくれても、対応をAIに任せてたら、しかるべき部署に連絡が一切行かなくなる。サービスが正常動作してないのに、そのことすら把握できなくなる。どう考えてもマズい。もっとも、AIに置き換えてしまえば人件費が、なんて上の人が安易に考える時点で、当の昔にサポート担当は他部署から完全に分離・断絶されているのだろうから、人間がやってもAIがやっても結局状況は変わらないのかもしれないけど…。

どうすりゃいいんだ、コレ。サポートに連絡してもこんな状態ではなあ…。このサービス、詰んでないか。

そもそも本来、「FTPS接続しか受け付けません」ではなくて…。

• Webブラウザ経由で更新できる仕組みも用意しておくとか (昔、Yahoo! GeoCities がそういう仕組みも提供してた)、
• 申請があったユーザだけはFTP接続を許可するとか、

他のアクセス方法も何かしら用意しておかないといかんだろう…。だって、ユーザがファイルを一切更新できない状況に追い込まれかねないわけで。何かしらの救済手段を用意してから切り替えないと。

動作確認が取れているFTPクライアントの種類とバージョンをサポートページに列挙してないのもなんだかなあ。いやまあ、どうせほとんど動作確認してないから書きようもないんだろうけど。今では入手できない上に暗号化通信機能を持ってないFFFTPのバージョンを平気でサイトに書いちゃってるぐらいだし。

それにしても、どうして急にこんな余計なことを…。セキュリティ強化以前に、ユーザがサーバにアクセスできなくなったら、それはもうサービスとして成立しないだろう…。 *2

FFFTP 2.0 のホスト設定についてメモ。

• 基本 → ホスト名(アドレス) → IPv4アドレスを直接入力してある。
• 拡張 → PASVモードを使う → チェックを入れて有効化。
• 拡張 → ネットワークの種類 → TCP/IPv4 を選択。(この項目は、FFFTP 5.8 には無い)
• 暗号化 → 暗号化なしで接続を許可 → チェックを外す。
• 暗号化 → FTPS (Explicit)で接続 → チェックを入れる。
• 暗号化 → FTPS (Implicit)で接続 → チェックを外す。
• 暗号化 → 弱い暗号化方式を試用しない → チェックを入れる。(この項目は、FFFTP 5.8 には無い)

FFFTP 2.00 のログは以下。

 FFFTP Ver.2.00 Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト 60.43.63.107 (21) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)
 220 FTP Server Ready
 >AUTH TLS
 234 AUTH TLS successful
 >PBSZ 0
 200 PBSZ 0 successful
 >PROT P
 200 Protection set to Private
 >USER xxxxxxx
 331 Password required for xxxxxxx
 >PASS [xxxxxx]
 230 User xxxxxxx logged in
 >FEAT
 211-Features:
  MDTM
  SSCN
  TVFS
  MFMT
  SIZE
  PROT
  CCC
  PBSZ
  AUTH TLS
  MFF modify;UNIX.group;UNIX.mode;
  REST STREAM
  MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
  EPRT
  EPSV
 211 End
 >TYPE A
 200 Type set to A
 >PASV
 227 Entering Passive Mode (60,43,63,107,229,155).
 ダウンロードのためにホスト 60.43.63.107 (58779) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)
 >MLSD
 150 Opening ASCII mode data connection for MLSD
 226 Transfer complete
 ファイル一覧の取得は正常終了しました. (2233 Bytes)
 ファイル名の漢字コードの判別結果はUTF-8です.
 >>CD D:\hoge\fuga\plala\
 >XPWD
 257 "/" is the current directory
 >TYPE A
 200 Type set to A
 >PASV
 227 Entering Passive Mode (60,43,63,107,217,48).
 ダウンロードのためにホスト 60.43.63.107 (55600) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)
 >MLSD
 150 Opening ASCII mode data connection for MLSD
 226 Transfer complete
 ファイル一覧の取得は正常終了しました. (2233 Bytes)

「接続しました.」と表示された後、FTPサーバから 220 が返ってきてるし、FTPクライアントから AUTH TLS も送信できて、サーバから 234 も返ってきている。その後、ユーザ名とパスワードも、USER と PASS で送信できている。

これが、正常にFTPS接続できた時の、コマンドとレスポンスの流れ、ということだなと…。

FFFTP 5.8 x86 のログも残しておく。

FFFTP Ver.5.8 32bit Copyright(C) 1997-2010 Sota & cooperators.
...
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト 60.43.63.107 (60.43.63.107:21) に接続しています.
 接続しました.
 220 FTP Server Ready
 >AUTH TLS
 234 AUTH TLS successful
 証明書の検証エラー: 0x800B010F: 証明書の CN 名が渡された値と一致しません。 
 >PBSZ 0
 200 PBSZ 0 successful
 >PROT P
 200 Protection set to Private
 >USER xxxxxxx
 331 Password required for xxxxxxx
 >PASS [xxxxxx]
 230 User xxxxxxx logged in
 >FEAT
 211-Features:
  MDTM
  SSCN
  TVFS
  MFMT
  SIZE
  PROT
  CCC
  PBSZ
  AUTH TLS
  MFF modify;UNIX.group;UNIX.mode;
  REST STREAM
  MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
  EPRT
  EPSV
 211 End
 >>CD D:\hoge\fuga\plala
 >XPWD
 257 "/" is the current directory
 >TYPE A
 200 Type set to A
 >PASV
 227 Entering Passive Mode (60,43,63,107,253,160).
 ホスト 60.43.63.107 (60.43.63.107:64928) に接続しています.
 接続しました.
 >MLSD
 150 Opening ASCII mode data connection for MLSD
 証明書の検証エラー: 0x800B010F: 証明書の CN 名が渡された値と一致しません。 
 226 Transfer complete
 ファイル一覧の取得は正常終了しました. (2233 Bytes)

接続できなかった FileZilla 3.65.0 のログは以下。

状態:           60.43.63.107:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 FTP Server Ready
コマンド:       AUTH TLS
レスポンス:     234 AUTH TLS successful
状態:           TLS を初期化しています...
エラー:         GnuTLS エラー -8: A packet with illegal or unsupported version was received.
状態:           "ECONNABORTED - 接続が閉じられました" への接続の試行が失敗しました。
エラー:         サーバーに接続できません

FileZilla 3.58.0 + Ubuntu Linux 22.04 LTS のログは以下。

状態:           60.43.63.107:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 FTP Server Ready
コマンド:       AUTH TLS
レスポンス:     234 AUTH TLS successful
状態:           TLS を初期化しています...
エラー:         GnuTLS エラー -8: A packet with illegal or unsupported version was received.
状態:           "ECONNABORTED - 接続が閉じられました" への接続の試行が失敗しました。
エラー:         サーバーに接続できません

FileZilla 3.65.0 + Windows10 x64 22H2 と同じに見える。

220 も受け取ってるし、FTPクライアントが AUTH TLS を送信するところまでは進んでいるなと…。

"GnuTLS error -8: A packet with illegal or unsupported version was received." でググってみた。

_Filezilla GnuTLS error preventing connection to server (Solved)
_GnuTLS error -8 when using client version 3.57.0 - FileZilla Forums

「サーバ側の設定に問題アリ」ということらしい。TLSのバージョン絡みのようだなと…。

昨日メモするのを忘れてたのでメモ。ひょっとすると、ぷららのFTPサーバは、IPアドレスに基づいてアクセスを規制しているのではないかと疑った。

であればと、ルータの再起動をして、ウチのIPアドレスを変えてみてからFTPサーバへの接続を試してみたのだけど。その時は、相変わらず接続できなかった。2回ほどIPアドレスを変更してから試しても結果は同じだったので、おそらくIPアドレスで接続が禁止されている状態ではないのだろうと判断した。

そもそも、例えばサーバの hosts.deny 等にIPアドレスを記述してFTPアクセスを禁止した場合、FTPクライアントには「FTPサービスは提供していませんよ」的レスポンスが残る。しかし、それも残ってなかったので、やはりIPアドレスで何かしてるわけではなさそう、とも考えた。

もっとも、ぷらら側でセキュリティ対策云々を優先して、サーバ側が何も返さない設定にしてある可能性もあるのかなと…。そうなると、一体何が原因で接続できないのか、ユーザ側で推測するのは難しくなりそう。

vsftpd Over SSL/TLS についてググっていた際、openssl s_client というコマンドでSSL/TLS関係の動作確認をすることができると知った。

_openssl s_client コマンドでウェブサーバーの SSL/TLS 対応状況を診断する - ラボラジアン
_openssl s_clientコマンドでウェブサーバのSSL/TLS対応状況を確認

$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

例えば、Linux上で以下のようなコマンドを打つと、色々と情報が返ってくる。

openssl s_client -connect 60.43.63.107:21 -starttls ftp

昨日と今日、Ubuntu Linux 22.04 LTS 上で、ぷららのFTPサーバ(www7.plala.or.jp, 60.43.63.107)を相手にして試してみたのだけど…。

2023/08/05の時点。

$ openssl s_client -connect 60.43.63.107:21 -starttls ftp
CONNECTED(00000003)
4027A7E3B77F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1952:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 133 bytes and written 310 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

2023/08/06の時点。

$ openssl s_client -connect 60.43.63.107:21 -starttls ftp
CONNECTED(00000003)
40376175A27F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:308:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 310 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

違いが判らん…。いや、微妙に違うか…。

> diff -u openssl.20230805.log.txt openssl.20230806.log.txt
--- openssl.20230805.log.txt    Sun Aug  6 23:02:04 2023
+++ openssl.20230806.log.txt    Sun Aug  6 23:02:26 2023
@@ -1,12 +1,12 @@
 $ openssl s_client -connect 60.43.63.107:21 -starttls ftp
 CONNECTED(00000003)
-40376175A27F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:308:
+4027A7E3B77F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1952:
 ---
 no peer certificate available
 ---
 No client certificate CA names sent
 ---
-SSL handshake has read 0 bytes and written 310 bytes
+SSL handshake has read 133 bytes and written 310 bytes
 Verification: OK
 ---
 New, (NONE), Cipher is (NONE)

昨日は 0byte だったところが、今日は133byte になってる。

手元で動かしている Ubuntu Linux 22.04 LTS + vsftpd (Over SSL/TTS) を相手にして試したら、全然違う結果になった。

$ openssl s_client -connect localhost:21 -starttls ftp
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
verify return:1
---
Certificate chain
 0 s:C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
   i:C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  4 19:12:18 2023 GMT; NotAfter: Aug  1 19:12:18 2033 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID2zCCAsOgAwIBAgIUfQw5di5DcU3RMb2uur6jhK0o28wwDQYJKoZIhvcNAQEL
...
SbShrSFBEcFjzPqxey7q0lkLftO3o2BjxvZl8A1+7Q==
-----END CERTIFICATE-----
subject=C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
issuer=C = JP, ST = Fukushima, L = Sukagawa, O = RAD11, CN = i36100t, emailAddress = hogeuser@example.com
---
No client certificate CA names sent
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 1805 bytes and written 739 bytes
Verification error: self-signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
---
220 Welcome to blah FTP service.
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: B6D3BB3D0172601AC62E8A72C9CD107D259262FBAF7FFB8A37E00EC89D2AF488
    Session-ID-ctx:
    Resumption PSK: 21DAEBE93FE1F65F4B2A4352F98B7F22510571230D5C48D24964F6D24A4F61A2DE8DAA0C210ACCA2D2B97F69700C312A
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    ...

    Start Time: 1691330693
    Timeout   : 7200 (sec)
    Verify return code: 18 (self-signed certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 49D7A917F01AD6C204F0B4E90F26506515C7B8994BF0234CEE8FACC954688BC7
    Session-ID-ctx:
    Resumption PSK: 386A511798FCCF44DD5D47A216F82238EF8BF36265D5D6B007D56B15FA44B7395CA1B474FD6F34F4C9B8EAD1D974E5B8
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    ...

    Start Time: 1691330693
    Timeout   : 7200 (sec)
    Verify return code: 18 (self-signed certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
quit
221 Goodbye.
40877323717F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:../ssl/record/rec_layer_s3.c:308:

FTPサーバ(vsftpd)を動かしてない環境で試すと、以下になる。

$ sudo systemctl status vsftpd.service 
● vsftpd.service - vsftpd FTP server
     Loaded: loaded (/lib/systemd/system/vsftpd.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Sun 2023-08-06 23:10:07 JST; 3s ago
...

$ openssl s_client -connect localhost:21 -starttls ftp
140093346547008:error:0200206F:system library:connect:Connection refused:../crypto/bio/b_sock2.c:110:
140093346547008:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111:
connect:errno=111

FTPサーバ(vsftpd)を動かしてるけど、FTPS接続を有効化してない環境で試すと、以下になる。

$ sudo systemctl status vsftpd.service 
● vsftpd.service - vsftpd FTP server
     Loaded: loaded (/lib/systemd/system/vsftpd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-08-06 23:12:35 JST; 3s ago
...

$ openssl s_client -connect localhost:21 -starttls ftp
CONNECTED(00000003)
139654957172032:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 77 bytes and written 293 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

-tls1_2 をつけて試すと結果が変わることに気づいた。以下はぷららのFTPサーバに対して試してみた際の結果。

$ openssl s_client -connect 60.43.63.107:21 -starttls ftp -tls1_2
CONNECTED(00000003)
40F7BADA097F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1952:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 133 bytes and written 205 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1691334012
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

「Early data was not sent」となってたところが、「SSL-Session」になって、TLSv1.2 がどうとか表示されている。

昨日の段階では、Windows10 x64 22H2 + FFFTP 2.00, FFFTP 5.8, WinSCP 6.1.1 で接続できるようになったのだけど、やっておくべきことを少しまとめておく。

IPv6 は使わないで、IPv4 でアクセスしたほうがいいらしい。FTPクライアントによっては、IPv6 でアクセスしようとして接続に失敗する。

FTPクライアントに設定するホスト名は、「www?.plala.or.jp」ではなくて、IPv4アドレス「xxx.xxx.xxx.xxx」にしておく。「www?.plala.or.jp」にしてしまうと、FTPクライアントによってはIPv6アドレスを取得してしまって接続できなくなる。ただ、ぷらら側で、FTPサーバのIPv4アドレスを変えてしまう可能性もありそうなので、急に接続できなくなった時はそのあたりを疑ってみるのもアリかもしれない。

尚、Windows10なら、ping を使って「www?.plala.or.jp」のIPv4アドレスを知ることができる。「-4」オプションを指定すればIPv4の使用を強制できる。 *2

ping www?.plala.or.jp -4

以下は ping の使用例。「www7.plala.or.jp」が「60.43.63.107」だと分かる。

> ping www7.plala.or.jp -4

www7.plala.or.jp [60.43.63.107]に ping を送信しています 32 バイトのデータ:
60.43.63.107 からの応答: バイト数 =32 時間 =31ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =16ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =19ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =17ms TTL=247

60.43.63.107 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 16ms、最大 = 31ms、平均 = 20ms

FFFTP は、FFFTP 2.00 を使ったほうがいいのかもしれない。FFFTP 2.00 なら、ホスト設定に、「ネットワークの種類」を「TCP/IPv4」に制限する設定項目があるので…。ちなみに FFFTP 2.00 は以下から入手できる。

_FFFTPの詳細情報 : Vector ソフトを探す！

現在の最新版の FFFTP 5.8 には「ネットワークの種類」という設定項目自体が無い。その代わり(?)、色々なバグが修正されているらしいのだけど…。

_Releases - ffftp/ffftp - GitHub


Windows10のファイアウォールは、FTPS接続した際に接続を切断してしまう可能性がある。

_Windows : FTPSで大量のファイルを転送すると接続が切れる | INCOMPLETE++
_FFFTPで大量ファイルを転送すると途中で切断、おかしくなる場合の対応 - ブログ運営のためのブログカスタマイズ

FFFTP の、「ツール」→「WindowsファイアウォールのステートフルFTPフィルタの設定」を使って、ステートフルFTPフィルタを無効にしておいたほうがいいかもしれない。あるいはコマンドを打ち込んで無効にする方法もあるそうで、その方法については上記の記事で紹介されてる。

まあ、なんというか、「オマジナイ」が増えたなと…。

とりあえず、FFFTP 2.00 で、ぷららのFTPサーバにFTPS接続する際のホスト設定をメモしておく。

今の段階ではこの設定で接続できているけれど、今後ぷらら側がサーバ設定を変えたら、また設定を変更することになるのかもしれないし、もしくは FFFTP すら使えなくなるのかもしれない。

• 「基本」→「ホスト名(アドレス)」は IPv4アドレスにしておく。
• 「基本」→「ホストの初期フォルダ」は空欄にしておく。

• 「拡張」→「PASVモードを使う」のチェックを入れておく。
• 「拡張」→「ネットワークの種類」を「TCP/IPv4」にしておく。(FFFTP 5.8 にこの設定項目は無い)

• 「暗号化」→「暗号化なしで接続を許可」のチェックを外す。
• 「暗号化」→「FTPS (Explicit)で接続」のチェックを入れる。
• 「暗号化」→「FTPS (Implicit)で接続」のチェックを外す。
• 「暗号化」→「弱い暗号化方式を使用しない」のチェックを入れる。(FFFTP 5.8 にこの設定項目は無い)

一応、念のため、ホームページビルダー20上でのFTPS接続転送設定もメモしておく。今現在はこの設定で、ぷららのFTPサーバに対して、サイト公開(FTPサーバへのアップロード)処理ができている。

基本設定タブ。

• プロバイダの選択 : その他
• FTPサーバ名 : IPv4アドレスを指定
• 転送先フォルダ : 空欄のままにしておく

詳細設定タブ。

• 接続方法 : FTPES - FTP over TLS/SSL Explicitモード
• ポート番号 : 21
• パッシブモードで接続する : チェックを入れて有効化

「OK」を押すと、その設定でFTPサーバに接続できるか試行して、問題が無ければ設定ダイアログが閉じるし、サーバと繋がらない場合は「サーバが見つかりません」的な警告ダイアログが表示される。

一応、バージョン表示もメモ。



ところで、ホームページビルダー20は、FTPS接続に対応しているけれど。

_[050780]FTPS 対応について

ホームページビルダー16以前のバージョンは、FTPS接続には対応していないらしい。

_FTPの転送設定　ホームページビルダー編｜ヘルプ｜忍者ホームページ

ただ、FTPRangerというソフトを使えば、FTPS接続に非対応なFTPクライアントでもFTPS接続できる、という話も見かけた。実際に試してないので今でも使えるのかどうかは分からないけれど、一応メモしておく。

_FTPRanger : ユーザーズガイド
_FTPRanger - FTPクライアント用暗号通信化ソフトウェア
_ホームページ・ビルダー 14 で FTPS サーバーへアップロードする。

もっとも、もしホームページビルダーがFTPS接続に非対応だとしても、サイト公開(FTPサーバへのアップロード)は、FFFTP で行ってしまってもいいような気もする。FFFTP のミラーリングアップロード機能を使えば、ローカルフォルダ内とFTPサーバ上のファイルのタイムスタンプを見て、追加/更新されたファイルをアップロード、かつ、ローカルには存在しないけれどFTPサーバ上にあるファイルは削除してくれるので、サイト公開を呼び出すのと似た感じで作業することができるのではないかと…。

例えば以下のようなオプションをつけて FFFTP を呼び出せば、FFFTPの起動と同時にミラーリングアップロードを開始して、処理が終わったらウインドウを閉じて終了、ということもできる。

ffftp.exe --set ホストの設定名 --mirror --quit

昨日試した時点では、FileZilla 3.65.0 で、www7.plala.or.jp にFTPS接続できなかった。

そのあたりをググっていたら、以下のやり取りに遭遇。

_FileZilla won't connect to ftp.keepfree.de - GnuTLS error - FileZilla Forums

That server has very bad security, it only supports TLS 1.0, which is insecure. FileZilla requires at least TLS 1.2 support, in its default configuration.
Additionally, that server has been neglected by staff, they didn't renew their TLS certificate that's expired since last year. :(
As a short-time workaround, set the minimum TLS version in the settings of FileZilla to "TLS 1.0 (insecure)". And you should definitely contact them about their server's security issues!

FileZilla won't connect to ftp.keepfree.de - GnuTLS error - FileZilla Forums より

• FileZilla のデフォルト設定では、少なくとも TLS 1.2 のサポートが必要。サーバ側が古いと接続に失敗する。
• ただし、FileZilla の設定を変更して、「許可されるTLSの最小バージョン」を「TLS1.0(安全ではない)」にすることで、一時的に問題を回避できる。
• しかし、本来は、サーバ管理者に連絡してどうにかしてもらうのが正しい解決の仕方。

だそうで。ぷららのFTPサーバもこういう状態なんだろうなと…。

しかし、おそらくこのあたり、FileZilla に特化してFTPサーバ側の設定を変えてしまうと、今度は他のFTPクライアントがFTPS接続できなくなりそうな臭いがする…。いやまあ、全ての問題を解決できる、真っ当なFTPサーバ設定があるのかもしれんけど…。

試しに、FileZilla の設定を変更したところ、ぷららのFTPサーバ(www7.plala.or.jp, 60.43.63.107) にFTPS接続することができた。

• 編集 → 設定 → 接続 → TLSオプション → 許可されるTLSの最小バージョン → 「TLS 1.0 (安全でない)」に変更して「OK」。

一応念のため、ホスト設定(サイトマネージャ)のスクリーンショットも載せておく。

一般タブ。

• プロトコル : FTP - ファイル転送プロトコル
• ホスト : IPv4アドレスを指定
• ポート : 21 (FTPはデフォルトで21番ポートを使うので空欄のままでもいい)
• 暗号化 : 明示的なFTP over TLSが必要

転送設定タブ。

• 転送モード : パッシブ
• 「同時接続数を制限する」にチェックを入れて、最大接続数を1にする

余談。編集 → 設定 → デバッグ → 「メッセージログのデバッグ情報」を「2 - 情報」にしておけば、FTPサーバから送られてきた情報も表示することができるので、もし接続に失敗する場合は、どこで失敗しているのか分かる、かもしれない。

Ubuntu Linux 20.04 LTS + FileZilla 3.58.0 で www7.plala.or.jp (60.43.63.107:21) に接続した際のログは以下。

状態:           60.43.63.107:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 FTP Server Ready
コマンド:       AUTH TLS
レスポンス:     234 AUTH TLS successful
状態:           TLS を初期化しています...
トレース:       TLS Handshake successful
トレース:       Protocol: TLS1.0, Key exchange: RSA, Cipher: AES-256-CBC, MAC: SHA1, ALPN: 
状態:           TLS 接続が確立されました。
コマンド:       USER xxxxxxx
レスポンス:     331 Password required for xxxxxxx
コマンド:       PASS *********
レスポンス:     230 User xxxxxxx logged in
コマンド:       SYST
レスポンス:     215 UNIX Type: L8
コマンド:       FEAT
レスポンス:     211-Features:
レスポンス:      CCC
レスポンス:      PBSZ
レスポンス:      AUTH TLS
レスポンス:      MFF modify;UNIX.group;UNIX.mode;
レスポンス:      REST STREAM
レスポンス:      MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
レスポンス:      EPRT
レスポンス:      EPSV
レスポンス:      MDTM
レスポンス:      SSCN
レスポンス:      TVFS
レスポンス:      MFMT
レスポンス:      SIZE
レスポンス:      PROT
レスポンス:     211 End
状態:           サーバーは non-ASCII の文字をサポートしていません。
コマンド:       PBSZ 0
レスポンス:     200 PBSZ 0 successful
コマンド:       PROT P
レスポンス:     200 Protection set to Private
状態:           ログインしました
トレース:       Measured latency of 227 ms
状態:           ディレクトリ リストを取得中...
コマンド:       PWD
レスポンス:     257 "/" is the current directory
コマンド:       TYPE I
レスポンス:     200 Type set to I
コマンド:       PASV
レスポンス:     227 Entering Passive Mode (60,43,63,107,247,252).
トレース:       Binding data connection source IP to control connection source IP 192.168.1.11
トレース:       Trying to resume existing TLS session.
コマンド:       MLSD
トレース:       TLS Handshake successful
トレース:       TLS Session resumed
トレース:       Protocol: TLS1.0, Key exchange: RSA, Cipher: AES-256-CBC, MAC: SHA1, ALPN: 
レスポンス:     150 Opening BINARY mode data connection for MLSD
レスポンス:     226 Transfer complete
状態:           "/" のディレクトリ リストの表示成功

完全に余談。投票所の係の人達のほとんどがマスクをしてなくて、目にした瞬間ギョッとしてしまった。この中に、コロナに感染してる人が混ざっていたらどうなるのか。投票に来た人達を次々に感染させていくつもりなのか。ニッコリ笑って「おはようございます」なんて言ってる場合じゃねえだろ。コイツラ何考えてんだ。などと一瞬憤慨しそうになったのだけど、直後にいやいや待て待てと考え直した。この気温の高さで一日中マスクをつけっぱなしでは熱中症になりかねないだろう…。それに扉も窓も全開にしてたから換気はできてるほうだろうし、唾を飛ばしながら大声で喋りかける仕事でもない。この時期に優先すべきは、コロナより熱中症対策だろうよ…。と考えたら、マスクをつけないことが妥当な選択のような気もしてきた。と思ったけれど今になって考えたら、アクリル板を置いとけば済む話だよな…。もっとも、全ての投票所にアクリル板を設置するコストを考えたら…。結局、全ての問題は、お金の問題に帰着するのかもしれない。世の中しょせん銭や。みたいな。

そう考えると、本来議員さんを選ぶときも、そういう視点が必要なのかもしれない。世の中しょせん銭や。自治体が使える金額は決まってるわけだから、リソース配分が上手い人、優先順位の付け方が賢い人、そういった能力が議員さんに求められるのではないか。とは言え、そのあたりの能力を測定できるテストの類が存在するのかどうか…。結局、試しにやらせてみてダメだったら変えてみるという、なんだか行き当たりばったりのやり方しかできないあたり、どうなんだろうと思えてきた。このあたり、各立候補者の能力を数値化して比較できたら選挙の結果にも納得感が…。いや、そうなると、そもそも選挙をする必要も無くなってしまうか。テストを受けて合格したら議員になれる、みたいな感じになりそうだけど、それは民主主義と言えるのかどうか。政治というものは、効率を追求していくと民主主義からどんどん乖離してしまうのではないか。

もしかするとマスクをつけるつけないの話も民主主義の一端を示しているのかもしれない。民主主義が、比較的多くの人が納得できる決定がされているか否かを重視しているものとすれば、マスク装着も同様の話で…。でも、投票所に居た人達は、話し合ってマスクをつけないことを選択したのかどうか。実は上からのお達しで、あるいは、メリットとデメリットをリストアップすることなく単にその場の空気でつけるつけないを決めていた可能性はないか。

なんかもうめんどくさくなってきたから全部AIが決めてくれないかな。AIという巫女のお告げに従って行動できたら楽なんだろうなあ。

今回は、FreeBSD-12.4-RELEASE-i386-disc1.iso (CD版)を入手してインストールに使用。

_Get FreeBSD | The FreeBSD Project
_Index of /releases/i386/i386/ISO-IMAGES/12.4/

ダウンロードページを確認して気づいたけれど、FreeBSD 13.2 がある…。2023/04/11に公開されたっぽい。自分、どうして先日は13.1を入手して使ったんだろう…。

12.4のほうが新しいと思い込んでたけど、公開日が2022/12/05。自分、年を読み間違えていた模様…。

デスクトップ環境のインストールは、先日の FreeBSD 13.1 試用時の作業メモをそのまま繰り返した。デスクトップ環境として Xfce を使えるようにしていく。

_mieki256's diary - FreeBSD 13.1を仮想PC上でインストールして試している

以下を打ったら、どこかのタイミングで zfs がどうのこうのというメッセージが表示されて困惑した。ufsでインストールしたはずなのに…。なんでzfsがどうとか出てくるの…。

freebsd-update fetch
freebsd-update install
pkg update
pkg upgrade
portsnap fetch extract
portsnap fetch update

ググってみたら、「zfsを使いたい時はこうしてくれ」的なメッセージだった模様。焦った。

_FreeBSD - メンテナンス・トラブルシュート - boot 時のトラブル - ZFS対策

他のPCからホスト名を指定してアクセスできるように、avahi もインストールしてみた。これも以前のメモを参照。

_mieki256's diary - FreeBSD 12.1 を Core i5-2500機にインストールした

ただ、巷の解説記事を眺めたら、nss_mdns をインストールしている事例も見かけたので、よく分からんけどソレもインストールしておいた。

pkg install avahi
pkg install nss_mdns

vim /etc/rc.conf

dbus_enable="YES"
avahi_daemon_enable="YES"
avahi_dnsconfd_enable="YES"

vim /etc/nsswitch.conf

hosts: files mdns dns

service dbus enable
service avahi-daemon enable
service avahi-dnsconfd enable

service dbus start
service avahi-daemon start
service avahi-dnsconfd start

OSインストール時に、時刻合わせをするための ntpdate もインストールしておいたので、そのあたりの設定をしておく。

動作に必要らしい /etc/wall_cmos_clock を作成。

sudo touch /etc/wall_cmos_clock

OS起動時の設定ファイル、/etc/rc.conf に、ntpdate が起動するように指定。かつ、NTPサーバも指定。

sudo vim /etc/rc.conf

ntpdate_enable="YES"
ntpdate_hosts="ntp.jst.mfeed.ad.jp"

_INTERNET MULTIFEED CO.
_【FreeBSD】正確な時間を取得する (ntpdate)
_番外編: VMware Player を使って Windows 10 に FreeBSD をお招きする

startx でデスクトップ環境を起動する場合は、~/.xinitrc や ~/.xsession が必要になるらしい。以下を設定した。ただ、 lightdm 等をインストールして使うなら、それらのファイルは作らなくてもいいらしい。代わりに ~/.xprofile を作るっぽいけど。

vim ~/.xinitrc

#!/bin/sh
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/usr/local/etc/X11/xinit/.Xresources
sysmodmap=/usr/local/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

export LC_ALL=ja_JP.UTF-8
export LANGUAGE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=xim
export XMODIFIERS=@im=fcitx
/usr/local/bin/mozc start
fcitx -r -d

setxkbmap -layout jp

. /usr/local/etc/xdg/xfce4/xinitrc
nohup vmware-user-suid-wrapper 2>&1 > /dev/null &

~/.xinitrc を作ったら、~/.xsession としてコピーする。

cp ~/.xinitrc ~/.xsession
chmod 744 ~/.xsession

sudo pkg install -y bash byobu neofetch vim

neofetch は、OS種類その他の情報を表示してくれる。

sudo pkg install -y xfce4-goodies

xfce4-goodies は、Xfce用のアプレットその他を色々増やしてくれる。

sudo pkg install -y xscreensaver

xscreensaver は、*NIXで有名なスクリーンセーバ。膨大な数のスクリーンセーバが入ってる。ただ、Xfce のスクリーンセーバも一緒に動いてるとなんだかよく分からないことになるので、xscreensaver をインストールした際はXfceの「セッションと起動」で Xfce側のスクリーンセーバは起動しないようにしておいたほうがいい。

sudo pkg install -y numlockx

numlockx は、実行するとキーボードの NumLock をONにしてくれるツール。Xfceの「セッションと起動」→「自動開始アプリケーション」で、「名前: numlockx」「コマンド : /usr/local/bin/numlockx」として追加しておいた。これで、Xfceが起動すると、自動で NumLock がONになる。

FeeBSD には Hackgenフォントが用意されていた。素晴らしい。以下でインストール。

sudo pkg install -y ja-font-hackgen ja-font-hackgen-nf
fc-cache -fv

_GitHub - yuru7/HackGen: Hack と源柔ゴシックを合成したプログラミングフォント 白源 (はくげん／HackGen)

OSインストール時のユーザ追加時に指定してあるけれど、念のためにメモ。FreeBSD の場合、pw というコマンドを使うらしい。

sudo pw groupadd wheel -m USERNAME

_グループの管理 - FreeBSD入門

OSが起動したら、GUIのログイン画面を出して、ユーザとパスワードを入力したらデスクトップ環境が起動するようにしたい。ログイン画面を出してくれるソレを、ディスプレイマネージャと呼ぶらしいけど…。

前回は SLiM をインストールしたのだけど。

_軽量ディスプレイマネージャslimと自動ログイン設定 -- ぺけみさお
_SLiM - ArchWiki
_カテゴリ:ディスプレイマネージャ - ArchWiki

今回は LightDM をインストールしてみることにした。というか、上記のページによると SLiM って開発停止してたのね…。

sudo pkg install lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings

おそらく ~/.xprofile が必要になりそうなので作成する。

_今さら .xinitrc, .xsession, .xprofile | ゴルディアスの涙目

日本語で表示するように環境変数を設定。かつ、mozc と fcitx を起動して日本語入力ができるようにした。また、日本語キーボードも指定してる。たぶん。

vim ~/.xprofile

#!/bin/sh
# DSB automounter
# dsbmc-cli -a &
# dsbmc &

# locale settings
export LC_ALL=ja_JP.UTF-8
export LANGUAGE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

# fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=xim
export XMODIFIERS=@im=fcitx
/usr/local/bin/mozc start
fcitx -r -d

# ibus
# export GTK_IM_MODULE=ibus
# export QT_IM_MODULE=xim
# export XMODIFIERS='@im=ibus'
# /usr/local/bin/mozc start
# ibus-daemon -r --daemonize --xim

setxkbmap -layout jp

lightdm が自動起動するように、/etc/rc.conf に指定。

sudo vim /etc/rc.conf

dbus_enable="YES"
lightdm_enable="YES"

今回、VMware上で動かしているので、VMware関係のツールを起動したい。~/.xinitrc や ~/.xsession を作成した時は、VMware関係のツールを起動するために、最後のあたりに以下も記述していたのだけど。

nohup vmware-user-suid-wrapper 2>&1 > /dev/null &

lightdm経由で Xfce を起動してみたら、VMware関係のプログラムは、Xfce の「セッションと起動」→「自動開始アプリケーション」に「VMware User Agent」として登録されていた。どうやら ~/.xprofile に記述しなくても済みそうかなと…。

FreeBSDでよく使われるらしい、lumina というデスクトップ環境も触ってみたいのだけど、インストールしてみたら正常に動作しなくて…。もうちょっと調べてみないと…。

ゆっくり回転していく風景と言えば、「呪術廻戦」懐玉・玉折編でも面白い見せ方があったなと思い出した。とある女性キャラが 撃たれた時、そのキャラの背中にカメラを据えて捉えたカットで…。スローモーションで 倒れていくキャラ。頭は上、体は下の状態で映り続けているのだけど、背景がゆっくりと90度回転していって、キャラが 地面に強く打ちつけられる、という1カット。回転していく背景をわざわざ3DCG( _カメラマップ？ )にしてリアリティを付加してたあたりにも感心したけど、それはさておき。

映像作品において、一般的に風景や背景と言うのは固定してるはずのもの、と見てる側は思い込んでるけど。それが動きを伴って、どんどん傾いていったり、天地が逆になったりすると、「なんか今とんでもねーことが起きてるぞ…」感が増すのだろうなと。このあたり、アニメ監督の原恵一監督が、ここぞというところで背景動画を使う理由と共通する部分がありそうだけど。

もっとも、そう感じさせるためには、そこに到るまでのカットはフツーに見せておかないといけない。常にカメラが動いて背景がガンガン回ってる中で、そこに背景が回転していくカットを挿入してみても効果は得られない。元ピクサーのジョン・ラセター監督が言ってた「コントラスト」が大事なんだろうなと…。何かを際立たせたい時は下準備が必要なのだ、みたいな。 *1

FreeBSD-13.2-RELEASE-i386-dvd1.iso (DVD版) を入手してインストールした。

_Get FreeBSD | The FreeBSD Project

余談。FreeBSD 13.2 が公開されているのに、先日わざわざ 13.1 を入手してしまったのが謎だったのだけど、原因が分かった。日本語版のダウンロードページの内容が古いままだったので、13.1 が現行版なのだと自分は思い込んでしまった模様。

_FreeBSD を入手する | FreeBSD プロジェクト

件のページの最終更新日が下のほうに書いてあって、その日付が2023/02/20となってるので、半年ぐらい古いまま、らしい。

今回も、FreeBSD 12.4 と同様に、zfs ではなくて ufs を選んでインストールしてみた。なんでも zfs はメモリをかなり使うらしくて…。FreeBSDのインストール時にも、zfsにカーソルを合わせると8GBがどうのこうのと表示されていたし…。たぶんそのせいで時々ファイルが消滅してたんじゃないかなと疑っているところ。

OSインストール後、lsblk をインストールして、HDD(仮想HDD)の状態を確認してみた。

pkg install lsblk

$ lsblk
DEVICE MAJ:MIN SIZE TYPE                                          LABEL MOUNT
ada0             0:87   20G MBR                                               - -
  <FREE>         -:-   512B -                                                 - -
  ada0s1         0:88   20G BSD                                               - -
    ada0s1a      0:90   19G freebsd-ufs                                       - /
    ada0s1b      0:91  1.0G freebsd-swap                                      - SWAP

一応、ada0s1a が freebsd-ufs と表示されているので、ufs なのではないかなあ…。分からんけど…。

ちなみに、FreeBSD では、ad* が IDE HDD、da* がSCSI HDD、acd,cd がCD-ROMドライブ、となっているらしい。

_第14章 ストレージ | FreeBSD Documentation Portal

一応念のため、/boot/loader.conf に、zfsを無効にするらしい以下の設定も書いておいた。

vim /boot/loader.conf

vfs.zfs.prefetch_disable=1

_FreeBSD 11.0 RELEASE - OS 起動後の基本的な設定 - ZFS を無効にする
_FreeBSD で ZFS を使う為の調整: uyota 匠の一手
_ZFS優しすぎ涙がでた。 - 春木屋

pkg install -y vim bash neofetch byobu sudo nano
visudo

pkg install -y xorg

pkg install -y octopkg portmaster numlockx arandr
pkg install -y ja-font-std ja-font-vlgothic ja-font-takao ja-font-hackgen ja-font-hackgen-nf
pkg install -y ja-font-ipa ja-font-ipa-uigothic ja-font-ipaex ja-font-ipamjm
pkg install -y gnu-unifont inconsolata-ttf ja-font-migu ja-font-mona-ipa ja-font-mplus-ipa
fc-cache -fv

pkg install -y xfce xfce4-goodies

デスクトップ環境の Luminaが動かない ―― start-lumina-desktop と打ち込んでも起動途中で勝手に終了してしまうので、 コンソールでvtなるものを使えるようにしたら動作が変わってこないかなと期待して試してみた。

vtを有効にすると、コンソール画面上で日本語フォントも表示できる状態になるらしい。最近の FreeBSD は最初から vt がデフォルトコンソールになっている、という話も見かけたけれど、設定しないとフォントは変わらなかった。

_FreeBSDで日本語コンソールvtを使う
_4.2 漢字コンソールの設定 | あらかると

上記の参考ページに習って設定作業。消えると怖いので引用しておく。

/boot/loader.conf に、vt を有効にするための指定を追加。

sudo vim /boot/loader.conf

kern.vty=vt
hw.vga.textmode=0

日本語フォント(ビットマップフォント)を入手。

sudo mkdir /usr/local/share/fonts/vt
sudo cd /usr/local/share/fonts/vt
sudo fetch http://people.freebsd.org/~emaste/newcons/b16.fnt
sudo fetch http://www.wheel.gr.jp/~dai/fonts/jiskan16u.fnt
sudo fetch http://www.wheel.gr.jp/~dai/fonts/jiskan16s.fnt
sudo fetch http://www.wheel.gr.jp/~dai/fonts/unifont-8.0.01.fnt

フォントの入手先は以下。

_Index of /~emaste/newcons/
_bitmap fonts, tools for convert/manipulate fonts
_how to convert BDF fonts for FreeBSD 10.x vt(4) console, make ISO10646 encoded font

OS起動時に日本語フォントに切替。vidcontrol というのが、コンソールの表示状態を変更できるツールらしい。

sudo vim /etc/rc.local

#!/bin/sh

VTFONT="b16.fnt"
#VTFONT="jiskan16u.fnt"
#VTFONT="jiskan16s.fnt"
#VTFONT="unifont-8.0.01.fnt"

if [ -f /usr/local/share/fonts/vt/$VTFONT ]; then
    vidcontrol -f /usr/local/share/fonts/vt/$VTFONT
fi

たしかに、起動時にフォントが変わってくれた。例えば bash上で以下を打つと、日本語フォントで表示されることが確認できる。

$ date
$ LANG=ja_JP.UTF-8 date

しかし、相変わらず Lumina は落ちる。これは関係なかったっぽい。

open-vm-tools 関連の設定が足りてないから Lumina が動かないのだろうかと思って、そのあたりを試してみた。

_VMwareで遊ぼうのこーなー
_いさぽん公式ＷＥＢ
_クラウドストレージwasabi on FreeBSD (fusefs-s3fs): RAJ商会

open-vm-tools関係パッケージのインストール。

sudo pkg install open-vm-tools xf86-input-vmmouse xf86-video-vmware

sudo vim /etc/rc.conf

fusefs_enable="YES"
vmware_guest_vmblock_enable="YES"
vmware_guest_vmhgfs_enable="YES"
vmware_guest_vmmemctl_enable="YES"
vmware_guest_vmxnet_enable="YES"
vmware_guest_kmod_enable="YES"
vmware_guestd_enable="YES"

せっかくだから、VMwareの共有フォルダ有効化もしてみる。

VMware側の仮想PC設定(仮想マシン設定)で、共有フォルダの設定を済ませておくこと。仮想マシン設定 → オプション → 共有フォルダ → 常に有効。共有したいフォルダ(Windows側のフォルダ)を追加。

FreeBSD の /boot/loader.conf に追記して、必要なモジュールをロードするように指定。

sudo vim /boot/loader.conf

fusefs_load="YES"

注意点。昔のFreeBSDでは以下の指定になっているけれど。

fuse_load="YES"

これは FreeBSD 13.2 で機能しなかった。どうやら最近の FreeBSD では、fuse という名前が fusefs にリネームされたようだなと…。

マウントするディレクトリを作成。

sudo mkdir /mnt/hgfs

まずは手作業で共有フォルダをマウントできるのか確認してみる。

sudo vmhgfs-fuse -o allow_other -o uid=1001 .host:/ /mnt/hgfs

もし、ここで、モジュールが正しく読み込まれていないと、以下のエラーメッセージが出てしまう。今回、ずっとこのエラーが出てしまって、何時間もハマった…。

fuse: failed to open fuse device: No such file or directory

マウントできてるか確認。共有したフォルダが見えるはず。

ls -l /mnt/hgfs

OS起動時に自動でマウントするように、/etc/fstab に追記。

sudo vim /etc/fstab

.host:/ /mnt/hgfs fusefs rw,mountprog=/usr/local/bin/vmhgfs-fuse,allow_other,failok 0 0

ちなみに、巷のやり取りでは、以下のような指定も見かけた。

.host:/ /mnt/hgfs fusefs rw,mountprog=/usr/local/bin/vmhgfs-fuse,allow_other,uid=1001,failok 0 0
.host:/ /mnt/hgfs vmhgfs rw,mountprog=/usr/local/bin/vmhgfs-fuse,defaults,allow_other,uid=1001 0 0
.host:/ /mnt/hgfs vmhgfs-fuse failok,rw,allow_other,mountprog=/usr/local/bin/vmhgfs-fuse 0 0

• uid=1001 の指定は、そのユーザIDのユーザにだけアクセスを許可するということだろうか。
• allow_other で、他のユーザもアクセス可能にしている気がする。たぶん。
• vmhgfs や vmhgfs-fuse は、昔はそういう名前だったということだろうか。今は fusefs になってるっぽい？

これで VMwareの共有フォルダは有効になったけれど。それはさておき、相変わらず Lumina は起動してくれない。ここも関係なかったっぽい。

コンソール画面でマウスを有効化しておく。

sudo vim /etc/rc.conf

moused_enable="YES"
moused_type="auto"
moused_port="/dev/psm0"

あるいは以下でも設定できるっぽい。結局、/etc/rc.conf に追記されるようだけど…。

sudo sysrc moused_enable="YES"
sudo sysrc moused_type="auto"
sudo sysrc moused_port="/dev/psm0"

たしかに、コンソール画面でマウスカーソルが出現するようになった。しかし相変わらず Lumina は(以下略。

一応、startx で twm が起動した時のデフォルト解像度を指定しておく。

_番外編: VMware Player を使って Windows 10 に FreeBSD をお招きする
_いさぽん公式ＷＥＢ

sudo vim /usr/local/etc/X11/xorg.conf.d/screen-resolution.conf

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        SubSection "Display"
        Modes      "1400x900"
        EndSubSection
EndSection

VMware上で動かしているなら以下も作成。作成しなくても startx は動いたけど念のため。

sudo vim /usr/local/etc/X11/xorg.conf.d/driver-vmware.conf

Section "Device"
        Identifier      "Card0"
        Driver          "vmware"
        BusID           "PCI:0:15:0"
EndSection

BusIDとやらは以下で確認できるらしい。

pciconf -lv | grep -b3 display

$ pciconf -lv | grep -b3 display
1456-vgapci0@pci0:0:15:0:       class=0x030000 rev=0x00 hdr=0x00 vendor=0x15ad device=0x0405 subvendor=0x15ad subdevice=0x0405
1572-    vendor     = 'VMware'
1598-    device     = 'SVGA II Adapter'
1633:    class      = display
1658-    subclass   = VGA
1679-pcib2@pci0:0:17:0: class=0x060401 rev=0x02 hdr=0x01 vendor=0x15ad device=0x0790 subvendor=0x15ad subdevice=0x0790
1793-    vendor     = 'VMware'

しかし、Lumina は動かなかった。

デスクトップ環境の Lumina が動かない。sudo pkg info lumina で確認したところ、Lumina のバージョンは 1.6.2_1,3 となっている。

コンソール画面で以下を打ち込めば Lumina の起動を指示できることは分かったけれど…。

start-lumina-desktop

スプラッシュ画面のようなものが出て、進捗バーが1/3ぐらいまで進んだところで、グレー一色の画面になって、そこでLuminaが落ちてしまう、というか、コンソール画面に戻ってしまう。




/var/log/Xorg.0.log を見れば何か分かるかなと思って眺めたけれど、うーん。「(EE)」となってるのは、以下の部分ぐらいで…。

less /var/log/Xorg.0.log

[  3657.082] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[  3657.082] (--) Using syscons driver with X support (version 2.0)
[  3657.082] (--) using VT number 9

[  3657.093] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[  3657.093] (EE) vmware(0): Failed to open drm.
[  3657.093] (WW) vmware(0): Disabling 3D support.
[  3657.093] (WW) vmware(0): Disabling Render Acceleration.
[  3657.093] (WW) vmware(0): Disabling RandR12+ support.
[  3657.093] (--) vmware(0): VMware SVGA regs at (0x1070, 0x1071)

というか、startx で twm を起動した時と、/var/log/Xorg.0.log の内容はほとんど変わらないのだよな…。

_xorg.0.log.lumina.txt
_xorg.0.log.twm.txt

> diff -u xorg.0.log.twm.txt xorg.0.log.lumina.txt
--- xorg.0.log.twm.txt  Wed Aug  9 20:39:35 2023
+++ xorg.0.log.lumina.txt       Wed Aug  9 20:39:28 2023
@@ -9,7 +9,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug  9 20:38:55 2023
+(==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug  9 20:35:25 2023
 (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
 (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
 (==) No Layout section.  Using the first Screen section.
@@ -426,7 +426,6 @@
 (**) IntelliMouse: (accel) acceleration threshold: 4
 (II) VMWARE(0): VMMOUSE DEVICE_ON
 (II) VMWARE(0): vmmouse enabled
-(II) VMWARE(0): vmmouse enable absolute mode
 (II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE
 (II) event1  - System keyboard multiplexer: device removed
 (II) event2  - AT keyboard: device removed

startx で twm はちゃんと起動してるわけで…。それらしく起動してる twm とログが同じということは、Xorg 云々で落ちてるわけではなくて、もっと違うところで落ちてるんじゃないだろうか。

利用しようとしているユーザの所属グループがアレなのかなと、そのあたりを設定してみたけれど、変化無し。

sudo pw groupmod operator -m hogeuser
sudo pw groupmod video -m hogeuser

/usr/local/etc/X11/xorg.conf.d/*.conf の記述がいかんのかなと、どれも .bak をつけてみたけど、変化無し。

start-lumina-desktop を直接呼ばずに、~/.xinitrc に記述して startx で起動させるべし、と言う話も見かけたので試してみたのだけど。

vim ~/.xinitrc

exec start-lumina-desktop

これも効果無し。やっぱり Lumina が落ちる。

というか、以下のやり取りによると、「最近の start-lumina-desktop は必要になればX11セッションを開いてくれる」と言ってるようにも見える。それが本当なら、「昔は ~/.xinitrc に書かないと動かなかった」という話なのだろうな…。

_Solved - Unable to launch Lumina on fresh FreeBSD 11 | The FreeBSD Forums

変な設定ファイルが残ってるんじゃないのかと、~/.config の中でそれらしいディレクトリを削除してみたけど。

$ cd ~/.config

$ ls
Thunar                  fcitx                   lthemeengine            neofetch
autostart               gtk-3.0                 lumina-desktop          sakura
dconf                   ibus                    lumina-mimeapps.list    xfce4

$ rm -rf lthemeengine
$ rm -rf lumina-desktop
$ rm lumina-mimeapps.list

変化無し。

Lumina は Fluxbox を使っているらしいので、その Fluxbox とやらが動くのか確認してみた。以下のやり取りによると、exec startfluxbox を ~/.xinitrc に書けばいいらしい。ちなみに、いきなりコンソール画面上で startfluxbox と打っても、Xorg が起動してないからエラーになる。

_FluxBox - Select fluxbox | The FreeBSD Forums

vim ~/.xinitrc

exec startfluxbox

startx

Fluxbox は動いてくれたように見えた。画面内の何もないところで右クリックをすればメニューが表示されて、何かしらを起動したり終了させたりできる。しかし、Fluxbox は動いても、やはり Lumina は動かない。

何故動かないのだろう…。VMwareとの相性なのだろうか。実機、あるいは VirtualBox上で試したら結果が違ってくるのかな。

それとも、ホストOSが64bitOSなのに、ゲストOSが32bitOSのせいだろうか。64bit版の FreeBSD を使ったら違う結果にならないか。

いやまあ、twm が起動するから最低限のGUI操作はできるし、Xfceも起動できるからソレを使えばいいんだけど。そもそも起動すらしないデスクトップ環境なんて他にも色々と不具合を抱えてそうでもあるし、存在を無視するのが賢い選択なのかもしれないけれど…。「BSD用に作られた」という話を見かけて、どんな感じなのか気になったんだけど、動かないのでは試しようもないわな…。

VirtualBox上なら違う結果になるのだろうか…。試してみるか…。

• 今回は、RAM 1GB、プロセッサ 3 CPU にしてみた。
• システム → Enable Hardware Clock in UTC Time にチェックを入れる。
• アクセラレーション → 準仮想化インターフェイスは、デフォルトに。
• 仮想化支援機能 → ネステッドページングを有効化、にチェックを入れてある。
• ディスプレイ → スクリーン → ビデオメモリーは 128MB に。
• グラフィックスコントローラは、デフォルトで VMSVGAだったので、最初はそのまま。この VMSVGA というのは、VMwareのエミュレートらしい。
• ストレージは、IDEよりSCSIのほうが良いという話を見かけたので、ストレージ → IDE を SCSI に入力し直し、かつ、タイプを PIIX4 から Lsilogic に変更。
• ホストのI/Oキャッシュを使う、にチェックを入れる。入れておかないとHDDへのアクセスがかなり遅くなった記憶がある。
• ネットワーク → 割り当てはNATからブリッジアダプターに変更。
• Advanced → アダプタータイプ → Intel PRO/1000 MT デスクトップ (82540EM) のまま。準仮想化ネットワーク (virtio-net) にすれば速くなるという話も見かけたけれど、自分の環境ではそれを選ぶとネットに繋がらなくなった…。

VMware上でインストールした時の手順に加えて、virtualbox-ose-additions もインストール。

sudo pkg install -y virtualbox-ose-additions

sudo vim /etc/rc.conf

vboxguest_enable="YES"
vboxservice_enable="YES"

以下、参考ページ。

_VirtualBox - ゲスト OS として FreeBSD を使用するときの注意
_FreeBSD on Virtual Box
_FreeBSD on virtualbox インストールメモ - murankの日記

VirtualBox 7.x 上でBSD系OSをインストールしようとすると、デフォルトではグラフィクスコントローラの種類が VMSVGA になっている。

_display - VirtualBox の VBoxVGA、VMSVGA、VBoxSVGA の違いは何ですか？ | code-404.net

VMSVGA の場合、FreeBSD側に xf86-video-vmware をインストールしないと、色々な画面解像度を選ぶことができなかった。

pkg install xf86-video-vmware

そして、この状態では Lumina が起動してくれなかった。

VMSVGA から、VBoxVGA か VBoxSVGA に変えてみたいのだけど、設定画面で警告が出る…。が、警告を無視して VBoxVGA にしてみた。

Lumina が起動した…！ コンソール画面で start-lumina-desktop と打てば、Lumina が起動してくれた。

つまり、今まで Lumina が起動しなかったのは、仮想PCのグラフィックスコントローラ、あるいはビデオドライバのせいだったようだなと…。VMware系のグラフィックスコントローラ(VMSVGA)では Lumina がクラッシュしてしまうけど、VirtualBox の古いタイプのグラフィックスコントローラ(VBoxVGA)なら Lumina が動く、ということなのだろう。

ストイックでシンプルでオシャレで軽量な印象を受けた。メモリ使用量も500MB前後で収まってる感じがするし、RAMが1GB程度のスペックでも使えそうな気がする。 *1

ただ、使い勝手は、残念ながら(?) Xfce や LXDE のほうが良さそうな…。例えば、デスクトップ上のアイコンをマウスドラッグで選択したいと思っても、Lumina はそういうことができないっぽい。Windows95の頃からできていたことが、できない。そういった、ちょっとしたところでチラチラとツライ瞬間があるといえばあるような。「あー。コレ、できないのね…」みたいな。

あえて Lumina を選びたいと思うほどの何かは、少し触ってみた程度では見出せなかった。ユーザ数も少ないっぽいから、何かトラブルが起きた時の解決策も見つけにくいのではと予想もできるし…。それに、FreeBSDハンドブックのデスクトップ環境の章でも、Lumina は紹介されてないし。コミュニティからそういう扱いを受けてるデスクトップ環境なのかなと邪推してしまった…。 *2

_FreeBSD ハンドブック | FreeBSD Documentation Portal

でもまあ、どんな感じのデスクトップ環境なのか実際に触って確認することができたので、これでようやく気分的にスッキリ。

今回、VirtualBox 7.0.10上で、FreeBSD 13.2 amd64 (64bit版)をインストールしたけれど、せっかくだから i386 (32bit版)も VirtualBox上でインストールしてみようと思い立った。

しかし、FreeBSD 13.2 i386 のインストール作業を進めていったところ、virtualbox-ose-additions パッケージが見当たらなくて…。

これは勝手な想像だけど、おそらく FreeBSD i386版は、最近の VirtualBox上で動かすことを想定していないか、もしくは、最近の VirtualBox が32bit版OSを動かすことを切り捨てにかかっていて、32bit版OS用の virtualbox-ose-additions も用意していないのではないかな、と…。

ただ、virtualbox-ose-additions-legacy-5.2.44_5 といったパッケージは用意してあるようなので、VirtualBox 5.x までバージョンを落とせば FreeBSD i386版も動かせる、といった状態なのかもしれない。

元々、64bit非対応のCPUが載ってる古いPCでも動かせそうなOSは何があるだろう、という視点でアレコレを試用していたので、こういうところで「64bit版を使え」的な圧をかけられると、ちと厳しい。64bit版OSを選べるなら、ユーザ数も比較的多い上に色々と整備してある Ubuntu Linux や Linux Mint あたりを最初から選ぶし…。実際、手元のサブPCのほとんどは、そのあたりを入れて使ってるわけだし。

それはともかく、現時点では以下のような選択になるのだろうか。

• FreeBSD 13.2 + Lumina を触ってみたい → VirtualBox上で FreeBSD amd64版を試用。ただし、i386版は使えないので注意。
• FreeBSD 13.2 i386 を触ってみたい。Lumina は使わない → VMware Player上で FreeBSD i386版を試用。
• FreeBSD 13.2 i386 + Lumina を触ってみたい → 実機でどうぞ。

とりあえず仮想PC上で動かせれば、どんな感じのソレなのか結構気楽にお試しができるわけだけど。実機を用意して、実機にインストールしないと動きませんよ、というのは、ちょっとハードルが高くなるなと…。

でもまあ、昔は仮想PCなんて無かったから、お試しだろうと何だろうと、とにかく実機にインストールして触ってみるしかなかったわけで、そんな時代と比べたら良い時代になったわけですが。この楽ちんさを知ってしまうと、昔には戻れない…。

FreeBSDの設定関連記事を眺めていたら、ee というコマンドが目に入った。なんやそれ。

_エディタ(ee)の使い方
_ee(1) FreeBSDドキュメントJMan
_FreeBSD上にデスクトップ環境を構築するには | ITドカタ

FreeBSD に標準で入ってるエディタらしい。そんなものがあったとは…。

カーソルキーでカーソル移動して、キーを叩けばそこに文字を挿入できる。終了は、ESC → leave editor。もしファイルが編集されていたら、保存するか保存しないかを尋ねてくる。あるいは、ファイル操作メニューは ESC → Cキーで出てくるらしい。

ちょっとだけ触ってみたのだけど、これって Undo はあるのだろうか…？ undelete line (Ctrl+L), undelete char (Ctrl+J) というのがソレっぽいと思ったのだけど、試してみたら、あくまで最後に削除した行 or 文字だけを戻してくれるだけで…。変更箇所をどんどん遡って戻してくれるわけではなさそう。

それはともかく。めちゃくちゃ検索しにくいエディタ名だなと…。

Windows10 x64 22H2 + VMware Workstation 17 Player 17.0.2 build-21581411 上で動かしてる FreeBSD 13.2 i386 に、LXDE, LXQt, MATE をインストールしてみた。

VMware上では Lumina が動かないことが分かってきたので、だったら他のデスクトップ環境が動きそうかどうか、少し確認してみたいなと。

sudo pkg install -y lxde-meta
sudo pkg install -y lxqt
sudo pkg install -y mate brisk-menu dconf-editor

どれも一応動いてくれた。ただ、アイコンが表示されなかったり、自動起動アプリの設定が反映されなかったりしたけれど…。とりあえず、Xfce と LXDE だけ残して、他はアンインストールしておく。

sudo pkg delete -y lxqt mate brisk-menu dconf-editor
sudo pkg autoremove

_LXDE - FreeBSD 13.2 RELEASE - 環境構築
_LXQt - FreeBSD 13.2 RELEASE - 環境構築
_MATE - FreeBSD 13.2 RELEASE - 環境構築

TP-LINKのルータも危ないよなと。

_TP-Linkの無線LANルーターなどで高頻度でNTPサーバーにリクエストを投げる設定が発覚し問題に | スラド IT
_TP-LINKのルーターが NTPクエリを5秒ごとに送信しているらしい。 - satoweb-blog
_“DoS攻撃並み"のトラフィックでまひ寸前! 福岡大学NTPサービスの悩み(2/3 ページ) - ITmedia NEWS
_福岡大学、公開NTPサーバーを停止する方針を決定 | スラド IT
_福岡大学、公開NTPサービスの終了に向け一部サービスの実験的停止を実施 | 24Wireless
_TP-LINK(RE450v1)のフィルタ設定のお願い | Null Gamer Exception

他所様のサーバにDoS攻撃相当をしてしまうルータ。酷い。IPアドレスをハードコーディングしていたというのが更に酷い。

まあ、基本的に、TP-LINK とエレコムのルータは買ってはいけないのだろう…。とは言え、だったらどこのメーカの製品なら大丈夫そうなのかというと…。うーん。

オープンソースのファームウェアを使ったルータって無いのかなと気になってググってみたら、そういうものもあるらしい。

_OpenWrt - Wikipedia
_PCを自宅ルーターに! x86版OpenWrtのインストール手順を解説【イニシャルB】 - INTERNET Watch
_約15年前の「無線LANルーター」が今でも販売され続けている理由とは? - GIGAZINE
_米Netgear、オープンソースの無線ルーターWGR614L | OSDN Magazine
_【第 1 回】 OpenWrt開発入門 - イントロダクション _私がルータを買う時はOpenWRT対応かどうかを見てる話
_OpenWRTってそんなに良いのか? | ばすにっきTips

OpenWRT というワードでググっていけば色々見つかりそう。

TOTPアプリの一つ、Microsoft Authenticator を試用してみようと思ったのだけど…。

_Microsoft Mobile Phone Authenticator App | Microsoft Security

Microsoft Authenticator は、PC版が無くて、Android版かiOS版しか無いらしい。

しかし、手持ちのスマホ、HUAWEI P9 lite で Google Play の該当ページを開こうとしても、「このアプリはお前の持ってる機種をサポートしてねえよ」と言われてページすら表示できない。

別の手持ちのスマホ、iPhone5 に、App Store 経由でインストールしようとしても「iOS 14.0以上が必要だ。お前のiPhoneはダメ」と言ってくる。iPhone5 は iOS 10.3.4 なのだ…。

なんでPC版が無いんや…。Micorosoft は Windows を作って販売してる会社とちゃうんかい…。スマホ向けアプリしかないってどういうことや…。

GitHub Mobile なるアプリをインストールできないかと、HUAWEI P9 lite + Google Play で検索してみたけど、これまた「お前の機種はサポートしてねえ」と言われる。

iPhone5 + App Store で検索したけれど、これも iOS 15.0以上が必要らしい。

Authy というアプリを HUAWEI P9 lite にインストールしたところ、インストールはできたものの、初回起動時に電話番号を要求された。SMSでパスワードを送ってくるので、それを入力しないと使えないらしい。自分は携帯電話サービスを契約してないので、SMSも使えない。つまり、この Authy も使えない。

ここ最近、どいつもこいつも、SMSを使えることを前提にしてサービス提供するのだよなあ…。

1Passwordとやらについてググってみたところ、PC + Webブラウザ上で拡張機能としてインストールできそうなのだけど…。どうやら有償のサービスっぽい…。

GitHub上で提示されてるTOTPアプリの一覧には無かったけれど、Google Authenticator というスマホアプリも存在しているらしい。

_GitHubを使おう! ログイン方法や2段階認証設定を徹底解説 | 侍エンジニアブログ
_Google Authenticator - Google Play のアプリ
_Google Authenticator - Wikipedia

どうやら スマホ + Google Authenticator でも GitHub の二段階認証とやらを利用できるらしい。このアプリなら、HUAWEI P9 lite にもインストールすることができた。

GitHubのアカウント管理画面で、何かのQRコードが表示されるので、それを Google Authenticator を使ってスキャンすると、6桁の数字が出てきた。

その数字を GitHubのサイト上で打ち込んだところ、リカバリーコードなるものが16個ほど表示された。何か問題が起きてアクセスできなくなってしまった場合は、このリカバリーコードとやらが役に立つらしい。ダウンロードしてどこかに保存しておく。

「二段階認証が有効になったよ」という画面が出てきたので、一旦 GitHub からサインアウトして、またサインインしてみた。メールアドレスとパスワードの入力後、追加でパスワードを入れろと言ってくる。

スマホ(HUAWEI P9 lite)上で Google Authenticator を起動してみたら、6桁の数字が表示されている。どうやら一定時間でこの数字は次々に変わっていくらしい。

この数字を GitHub上で打ち込んでみたら、自分のアカウントにサインインすることができた。

これ、リポジトリにアップロードする時はどうするんだろう…？ ググったら、以下のような感じになるっぽい。

_GitHubで2段階認証設定後にTortoiseGitからレポジトリ操作を行う - MRが楽しい
_TortoiseGitをGithubの二段階認証に対応 - schima.hatenablog.com

Personal access tokens なるものが絡んでくるようだなと…。

ふと疑問が湧いた。コレって、スマホ持ってない人はどうするの？

貧乏人は、あるいは宗教上の理由でスマホを持てない人には、GitHubを使わせないぜ、ということだろうか。仮にその人がプログラマーとしてどれだけ優秀でも、スマホを持ってなかったらそれだけで門前払いということか。もしそうだとしたら、スマホを持ってない人、SMSを使えない人は、もはや人間に非ずって感じがして、とても嫌だな…。いやまあ、そもそもインターネットを利用できる環境に無い人達も、既に社会から人間扱いされてないのであろう予感もあるけれど。

スマホが無い場合でもどうにかならんかとググってみたら、WinAuthなるものを使うことで、PCだけでもどうにかなりそうな感じがしてきた。

_WinAuthでGitHubの二段階認証を設定する方法【PCだけでできる】│NAOZUMIBLOG
_二段階認証／WinAuth（ワンタイムパスワード）導入手順
_Windows Authenticator for Google, Blizzard, Guild Wars, Rift
_winauth/winauth: Authenticator on Windows

試してみた。WinAuth-3.5.1.zip を入手。解凍すると WinAuth.exe という実行ファイルがある。実行。

• Add → Authenticator を選択。
• Name : github, Secret Code : GitHub のアカウントページで入手した謎の文字列を入力。

GitHubにサインインしてる状態で、Settings → Password and authentication → Two-factor authentication の Authenticator app の右の Edit をクリック。QRコードが表示されるけど、よく見ると setup key というリンクがあるのでクリック。これで謎文字列が表示されるのでコピーする。

WinAuth の Secret Code 入力欄に謎文字列を貼り付けて、Verify Authenticator のボタンをクリックすると、その下に6桁の数字が出てくるので、それを GitHub 上の Verify the code from the app に打ち込んで save。

WinAuth側でOKボタンを押すと、Protection画面が出てくる。パスワードを設定しておくとより安全、ということらしい。設定しない状態にもできるけど、今回は一応設定しておいた。

これで、WinAuth が生成したワンタイムパスワードを使って、GitHub にサインインできるようになった。

スマホが無くてもどうにかなりそうだなと…。Windows機さえあれば、一応人間扱いしてもらえる…。

ただ、セキュリティ的には弱くなってる状態らしい。そのPCさえあればアカウントにサインインできてしまう状態より、PCとは別にスマホが ―― PCとは異なるデバイスが無いとサインインできない状態のほうが安全、ということなのだろう。

WinAuth は Windows上でしか動かないので…。SMSを使えないしそもそもスマホも持ってない、PCは持ってるけれど Windows は使ってなくて普段は Linux を使ってます、という人は一体どうしたらいいのか。伝説級の凄腕ハッカーでもスマホかWindowsを持ってないと門前払いなのか。

Linuxの場合、oathtool というCLIコマンドが使えるらしい。

_第508回　Ubuntuでコマンドラインからワンタイムパスワードを扱う | gihyo.jp
_Ubuntu Linux 22.04 LTSで、oathtoolを使ってコマンドラインでTOTPのワンタイムパスワードを生成する - CLOVER
_oathtoolをインストールする（二要素認証のワンタイムパスワードをsecretから生成する） - やってみる
_LinuxのCLI上で二段階認証クライアント(MFA)を実行する - Qiita

良かった。Linuxをバリバリ使う凄腕ハッカーもGitHubから門前払いされずに済みそう。

座り心地はイイ感じ。ヘッドレストがあると、こんなに楽なのかと。ロッキング機能とやらはほとんど効いてる感じがしないけど、そのあたりは昔からそんなに使ったことがないので…。

座面を一番低くすると41cmぐらいになる点は助かった。ギリギリだけど、一応PCデスクの下に入ってくれる。

予想外だったのは、背もたれの固定方法。背もたれを、肘掛けが両側から挟み込んで、肘掛け部分に背もたれをネジ止めする設計だった。座面部分に固定するのかと思ってたけど、そうではなかったのだな…。肘掛けを外したままで使えないかなと甘いことを考えていたけど、それは無理。肘掛けが回転して背もたれに並ぶタイプを選ぶべきだったか…。もっとも店頭にそういうタイプは無かったので、そういうのが欲しければ通販で買うしかないけれど。

わざわざ肘掛け付きの製品を買っておきながらアレだけど、想像していた以上に肘掛け部分が邪魔というか…。今までこういうタイプを使ったことが無いので、ここまで存在感が大きいとは知らなかった。いや、腕はたしかに楽なのだけど、肘掛けがあると椅子の上で胡坐を組めないのだな…。もっとも、取扱説明書の注意事項には「椅子の上で胡坐をかくな」とわざわざ書いてあるので、フツーはそういうことをしちゃいかんのかもしれない。椅子の上で変なポーズを取ろうとしないなら何の問題も無く使えそう。

後は耐久性が不安。どのくらい持ってくれるのか…。

リサイクルショップ、アメ横須賀川店を初めて覗いてきた。オフィスチェアもいくつかあって、座面が大きめ、かつ、回転する肘掛け付きのタイプが6,600円だった。フツーのサイズで、表面が毛羽立ってたり、汚れてたりする品なら660円。背もたれがハイバックの品があれば良かったのだけど…。

「fooocus インストール」でググったら解説記事が結構あった。ありがたや。

_【西川和久の不定期コラム】次世代Stable Diffusion(SDXL)をWindows上で一発で使用可能にする「Fooocus」 - PC Watch
_Fooocusのインストール【web UIとComfyUI以外の選択肢】 | ジコログ
_SDXLを手軽に扱える「Fooocus」のインストール方法・使い方まとめ!簡単操作でハイクオリティな画像を生成しよう | くろくまそふと
_Fooocus のインストール,Stable Diffusion XL (SDXL) による画像生成の実行(Fooocus,Stable Diffusion XL,PyTorch,Python を使用)(Windows 上)
_Fooocus: 超軽量でシンプルイズベスト、なSDXLクライアント|かいりん
_Stable Diffusion - Fooocusの概要と導入方法・使い方 | 紫雲雑想

Fooocus_win64_1-1-10.7z を入手して解凍。

_lllyasviel/Fooocus: Focus on prompting and generating

以下のモデルデータを入手して、Fooocus\models\checkpoints\ に置いた。

• sd_xl_base_1.0_0.9vae.safetensors
• sd_xl_refiner_1.0_0.9vae.safetensors

_stabilityai/stable-diffusion-xl-base-1.0 at main
_stabilityai/stable-diffusion-xl-refiner-1.0 at main

run.bat を実行したら、必要なファイルをDLした後、画像生成を指示するためのUI画面がWebブラウザで開かれた。ちなみに今回は D:\aiwork\fooocus\ にインストールしておいた。

Stable Diffusion web UIと違って、Webブラウザが自動で起動するっぽい。

1152x896 の解像度でお姉さん( a girl, japanese, ) を生成してみた。

最初の生成時は、6GB以上もあるモデルデータをHDDからロードするので、かなり時間がかかる。タスクマネージャでパフォーマンスを確認したら、HDDがずっと100%。9分ぐらい過ぎたあたりで、ようやく100%状態が終わった。SSDに置いておけばもっと速くなるのだろうけど、自分の環境はSSD側の空き容量が厳しいので…。

生成を指示して10分ぐらい経ってから、モデルデータのロードその他の処理が終わったようで、そこからようやく生成処理っぽいものが走り始めた。

画像を1枚生成するのに、4〜5分ほどかかった。それでもちゃんと、それらしい画像を生成してくれた。VRAM 6GB でも、たしかに動いた…。しかし、さすがに時間がかかるなと。今時のGPUが欲しくなるなあ…。

手のデプスマップを上書きしてくれる拡張機能、depth-lib をインストールすると、本体が dataset 云々のエラーを出して動かなくなることに気づいた。

_jexom/sd-webui-depth-lib: Depth map library for use with the Control Net extension for Automatic1111/stable-diffusion-webui

以下の修正をすればエラーが解決するらしいけど…。

_Quick fix for KeyError: 'dataset' - Issue #36 - jexom/sd-webui-depth-lib

venv\Lib\site-packages\gradio_client\serializing.py の COMPONENT_MAPPING という辞書リストに以下を追加せよ、と書いてあるのかな。

"dataset": StringSerializable,

また、この拡張機能は放置気味なので fork した人が居るらしい。

_New fork with additional features - Issue #39 - jexom/sd-webui-depth-lib
_wywywywy/sd-webui-depth-lib: Depth map library for use with the Control Net extension for Automatic1111/stable-diffusion-webui

とりあえず fork版をインストール、かつ、前述の修正をしたところ、エラーが出ない状態になった。

ググってみたところ、自作してる方が結構いらっしゃるようで。

_【フットレストDIY】1000円以下でできる!在宅ワークによるむくみ・姿勢対策アイテムを自作してみた - 特選街web
_姿勢よく椅子に座るために足置き台を設置してみました。 | ぴらめこな生活
_【簡単DIY】フットレストを自作しました。 - diymemo
_机/リメイク/昭和の家/築50年以上/勉強スペース...などのインテリア実例 - 2020-09-18 21:42:21 | RoomClip(ルームクリップ)
_ダンボールでフットレストを自作!!日本人は低身長で短足なんだからもっと低い椅子とデスクを作ってよ!!! | おばちんです。
_足置き 自作 - 車いじりとB級グルメ好きな日常生活

その中でも、発泡スチロール製のブロックを利用して自作した例が気になった。その手があったか…。

_安価なフットレストを作ってみました。 - YouTube

ダイソーで、発泡スチロール製のミニブロックを2個、すのこを1つ、買ってきた。

• 発泡スチロール製 ミニブロック。24.5 x 12 x 6.2cm。2個購入。
• 桐すのこ。40x25cm。

これを以下のようにすればフットレストモドキにならないかなと…。

すのこと発泡スチロールの接着は、両面テープを使った。紙を貼り合わせるフツーの両面テープじゃなくて、「なんでも貼り付けられるよ」と謳う、 3M スコッチ KPU-12(超強力両面テープ、プレミアゴールド、スーパー多用途、薄手、12 mm x 1.5 m) を使った。

そんな感じで、こうなった。


たまたま偶然、PCデスクの下の板の高さと、ほぼピッタリの高さになった…。

高さは十分イイ感じだけど、問題点がありそう。まず、発泡スチロール + すのこなので、めちゃくちゃ軽い。どっしり感が一切無いので、ちょっと足を動かしただけで位置がずれてしまう。

それと、すのこの角が危ない予感。そのうち絶対、足をうっかり引っかけて、足に擦り傷ができそう。角を丸く削っておいたほうがいいのかもしれない。

すのこの強度も不安。かなり薄い板なので、一瞬でも全体重を乗せたら、あっさり割れるだろうなと…。まあ、しばらく使ってみて、調子が良さそうならちゃんとした板を買ってくるのもアリだろうか。

手持ちの折り畳み踏み台をフットレスト代わりにできないかと検討したのだけど、測ってみたら高さが20cm以上あって、ちょっと使えないなと。PCデスクとの組み合わせ的に、12cm前後じゃないと厳しい。

_100均の踏み台を全て購入!ダイソーなど主要3社を徹底比較したよ | くまのお役立ちサイト。

ダイソーやSeriaの品は高さがあり過ぎるけど、CanDoの品ならちょうど良かったかもしれない。ただ、入手できそうな気はしないけど…。近所のCanDoは店舗が小さいので、あまり商品を置いてない…。ネットで見かけて欲しいと思っても、まずその商品は売ってない…。

ホームセンターで売られてそうな、プラスチック製の踏み台や、木製の踏み台も良さそうだなと思ったけれど、DCMのネットショップで検索してみたら2,000円前後で、ちょっと高いなと…。もうちょっとプラスすればフットレストとして売られている製品が買えてしまう。もっとも、踏み台として売られているだけあって全体重を乗せても壊れないぐらいの強度があるから、ちょっと高いところをアレコレしたい場面で流用できたりして、フツーに重宝しそうでもあるなと…。

親父さん用PC周りの電源コードの配線に手を入れた。置いてある機器の数からして、6個口電源タップ x 2個で足りるはずと予想していたけど、やはりそれで足りてくれた。これで少しは安心できる…。

電源タップの裏に、ネジに引っ掛けるための穴が開いていることに気づいた。現状では、電源タップはスチール製デスクの下にそのまま置いてあるけれど、磁石 + ネジのソレがあれば、デスクの側面にくっつけることができそう。しかし、その場合コンセントが抜けかかったりしないだろうか。ただ、そのまま下に置いておくと、親父さんがアレコレを無頓着に机の下に押し込んで、危険な状態になりそうだし…。コンセント収納ボックスの類を導入したほうがいいのかな…。

書いてみたサンプルソースは以下。

_gzoom_01.hsp

    ; gzoom を使って画像を拡大縮小描画する

    #define IMG_FILE    "char1_256.png"
    #define SCR_W       512
    #define SCR_H       288

    ; 同梱ファイル
    #pack   IMG_FILE
    
    #packopt name "gzoom_01"    ; 生成ファイル名
    #packopt type 0             ; .exe生成を指定
    
    #packopt xsize SCR_W
    #packopt ysize SCR_H
    
    ; ウインドウの初期化とサイズ取得
    screen 0, SCR_W, SCR_H, 0
    gsel 0
    ; width SCR_W, SCR_H
    dispw = ginfo_winx
    disph = ginfo_winy
    cls 4

    ; 画像を読み込み
    imgid = 3
    buffer imgid, 2048, 2048
    picload IMG_FILE
    imgw = ginfo_winx
    imgh = ginfo_winy

    ; 仮バッファ作成
    tmpid = 4
    buffer tmpid, 4096, 4096
    
    angle = 0

    ; onkey goto *jobend      ; 何かキーが押されたら終了する

*mainloop

    ; ESC key to exit
    stick k
    if k & 128 : goto *jobend
    
    redraw 0
    gsel 0          ; ウインドウID0 を描画先として選択
    
    ; 背景を青一色で塗り潰し
    color 0, 128, 255
    boxf
    
    ; 描画先、描画元の座標やサイズを求める
    scale = sin(deg2rad(angle)) * 2.5 + 3.0
    dst_w = int(double(imgw) * scale)
    dst_h = int(double(imgh) * scale)
    dst_x = dispw / 2 - (dst_w / 2)
    dst_y = disph / 2 - (dst_h / 2)
    src_w = imgw
    src_h = imgh
    src_x = 0
    src_y = 0

    kind = 2
    switch kind
    case 0
        ; gzoomのみを使った事例
        ; 拡大縮小描画はできているが、透明色を扱えない
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gzoom dst_w, dst_h, imgid, src_x, src_y, src_w, src_h, 0
        swbreak
        
    case 1
        ; gcopy を使った事例
        ; RGB=(0,0,0)を透明色として扱えるが、拡大縮小描画はできない
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gcopy imgid, src_x, src_y, src_w, src_h
        swbreak
        
    case 2
        ; 仮バッファを使ってgzoomで透明色を扱ってるように見せかける事例
        ; 拡大縮小しつつ、RGB=(0,0,0)が透明色になっている
        
        ; 一旦、仮バッファに gzoom で拡大縮小描画
        gsel tmpid
        pos 0, 0
        gzoom dst_w, dst_h, imgid, src_x, src_y, src_w, src_h, 0

        ; 仮バッファから実スクリーンに gcopy でコピー
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gcopy tmpid, 0, 0, dst_w, dst_h
        swbreak
    swend
    
    redraw 1
    
    angle += 3
    
    await (1000 / 60)
    goto *mainloop
    
*jobend
    end

使用画像は以下。

_char1_256.png

ソース中の、kind を、0,1,2 に変更すれば動作が少し変わる。

まず、gzoom だけで描画してみた事例。

        ; gzoomのみを使った事例
        ; 拡大縮小描画はできているが、透明色を扱えない
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gzoom dst_w, dst_h, imgid, src_x, src_y, src_w, src_h, 0

拡大縮小描画はできているが、透明色を扱えないので、キャラクターの周辺が黒いまま。

gmode gmode_rgb0 を実行することで、gcopy 等で RGB=(0,0,0)を透明色扱いにした描画ができるようになるのだけど、gmode の設定は gzoom に反映されないらしい。あくまで gcopy だけが gmode 設定の影響を受けるとのこと。


次に、gmode と gcopy を使ってみる。

        ; gcopy を使った事例
        ; RGB=(0,0,0)を透明色として扱えるが、拡大縮小描画はできない
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gcopy imgid, src_x, src_y, src_w, src_h

RGB=(0,0,0) の部分を透明色として扱うことができてる。ただ、拡大縮小描画はできない。


次に、gzoom で仮バッファに描画してから、仮バッファ内容をソースにして gcopy してみる。

        ; 仮バッファを使ってgzoomで透明色を扱ってるように見せかける事例
        ; 拡大縮小しつつ、RGB=(0,0,0)が透明色になっている
        
        ; 一旦、仮バッファに gzoom で拡大縮小描画
        gsel tmpid
        pos 0, 0
        gzoom dst_w, dst_h, imgid, src_x, src_y, src_w, src_h, 0

        ; 仮バッファから実スクリーンに gcopy でコピー
        gsel 0
        gmode gmode_rgb0    ; RGB=(0,0,0)を透明色として扱う
        pos dst_x, dst_y
        gcopy tmpid, 0, 0, dst_w, dst_h

拡大縮小描画をしながら、透明色も扱えているように見える。ただ、2回描画しているので、処理時間が増えているはず。たぶん。

gzoom を使って拡大縮小描画ができることが分かったので、別のサンプルも書いてみた。Windows10 x64 22H2 + HSP 3.51, 3.6, 3.7beta6 で動作確認した。




ソースは以下。

_gzoom_02.hsp

使用画像は以下。gzoom_02.hsp と同じフォルダに images というフォルダを作成して、その中に入れる。

_trees_512x512_32col.png
_bg_16col.png

木の画像は自作画像なので CC0 / Public Domain 扱いということで。背景画像は Pixabay から入手して加工したので、そちらのライセンスに従うということで…。

_Pixabay
_デスヴァレー 道 風景 - Pixabayの無料写真 - Pixabay

HSPでソート処理を書かないといかんのかなと思っていたけれど、sortval というソート処理命令があるようで、わざわざ自分で書かずに済んだ。ググった感じでは、2015年頃、HSP 3.5 beta1 の時点で標準機能として取り込まれた模様。

_hsp3関連 更新履歴

今のところ、HSPのソースを書く際に、Mery 3.5.4 x64 というエディタを使用している。

_Haijin Boys Online
_MeryWiki
_プラグイン:HSPコンパイル実行プラグイン - MeryWiki

HSPコンパイル実行プラグインを導入して、HSPRun.ini 内でHSPインストールフォルダを指定して、該当プラグインの呼び出しに F5キーでも割り当てておけば、ソースを書いてF5キーを叩くと即座に動作確認できて楽だなと。ただ、HSP 3.7 beta6 を利用すると、何故か実行ファイルの作成に失敗してしまう。HSP 3.6 なら生成できるようだけど…。

HSPに標準で添付されてるエディタもイイ感じなのだけど、単語補完機能が無いあたりがちょっとツライ。

せっかくダイソーに寄ったので、組立式コンセント収納ボックスも購入。200円。木目調。30 x 14 x 10 cm。おそらく以下で紹介されてる商品、だと思う。たぶん。

_高見栄えケーブル隠し！100均ダイソー「組み立て式コンセント収納ボックス」 | 格安スマホマイスターぴざまん
_ダイソー「自分で組み立てるケーブルボックス」　試したら想像以上に便利だった - Sirabee

電気パーツ関連のコーナーに置いてあった。電源コードをまとめるマジックテープとか、そういうのが置いてあるコーナー。

コレを使って、親父さん用PCの電源を取っているテーブルタップを入れて整理できないかなと。

どうもこの見た目は個人的に我慢できない。もうちょっとどうにかしたい。ダイソーでリメイクシートを買ってきた。「組木風木目柄」と書いてある。45 x 90cm。100円。

12 x 3 cm のサイズで切ったモノを4枚用意して、今回追加した木片の周りに貼ってみた。色が白系から茶色系になっただけでも見た目が改善された気がする。

リメイクシート裏面の糊が弱いので、すぐ剥がれそうな気もするのだけど、その際は両面テープで再度貼り直せばいいかなと…。木工用ボンドの類でも良さそうな気もするけど。

リメイクシートを貼った状態の写真を撮影してみた。こんな感じ。

今まで使っていたソレより音漏れが大きい気がする…。音を出す部分の口径が大きくなったからだろうか。あるいは、穴に被せてある部分の材質が違っていて、音が抜けやすくなっているのだろうか。

ただ、音は今まで使っていたものより、ちゃんと聞こえるようになった気もする。Lの音が小さいということもない。やはり今までのイヤホンは何かが壊れてしまっていたようだなと…。