Linux MINT 22.1 Cinnamon Edition on Dynabook

壊れかけの dynabook Satellite B754/98LB に Linux MINT 22.1 Cinnamon Edition を入れた。Fedora,Manjaroでは荷が重すぎるので丁度いい塩梅で軽快に動作してくれている。インストール情報は


System:
  Kernel: 6.8.0-63-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0 clocksource: tsc
  Desktop: Cinnamon v: 6.4.8 tk: GTK v: 3.24.41 wm: Muffin v: 6.4.1 vt: 7 dm: LightDM v: 1.30.0
    Distro: Linux Mint 22.1 Xia base: Ubuntu 24.04 noble
Machine:
  Type: Laptop System: TOSHIBA product: dynabook Satellite B754/98LB v: PB75498LBXBW
    serial: <superuser required>
  Mobo: TOSHIBA model: Portable PC v: MP serial: <superuser required> part-nu: PB7549
    uuid: <superuser required> UEFI: Insyde v: 1.70 date: 01/24/2014
 

こんなデスクトップ。インストール自体は通常通りインストーラーから普通に入れただけ。日本語入力環境の整備だとかブラウザをGoogle-Chromeに換装だとかは検索すればいくらでも出てくるので Firewallネタ。

 

まず、標準インストールされているファイアーウォールを起動し、設定していく。gufwとなる。

 

 

 

gufwの歯車アイコンを押して上記設定画面から設定する。

 

私は、

 

TCP IN 445 sambaのポート

 

UDP OUT 53 DNS , 51820 VPN WireGuard

TCP OUT 80,443,445,465,515,993

を開けた。そして、public とし、IN,OUT を DROPとしている。

 

まあ、普段遣いには十分。これは、使う人のポリシーだからお好きに。

 

とても、快適なのでMint22.1のサポートが切れるまでこのままかな。

 

古いPCを活用したい人向けにとても良いディストリビューションだと思う。

Fedoraインストール時の落とし穴：AnacondaがUS配列でパスワードを記録する件

🧭 はじめに

Fedora をインストールする際、多くの人は Live ISO から起動して、GUIベースの Anaconda インストーラーを使うことになります。

日本語環境を選択すれば、当然ながら「日本語キーボード（jp106/109A）」も選んでいるはず――ですが。

実はこの時点で、将来的にログインできなくなる“罠”が仕掛けられていることをご存じでしょうか？

💥 問題の概要：AnacondaはUS配列でパスワードを処理している

FedoraのAnacondaインストーラーには、以下のような一見すると問題なさそうな手順があります：

  1. Fedora Live ISO を起動

  2. 日本語を選択

  3. ロケールやタイムゾーン、キーボードも「日本語（jp106）」を選択

  4. ユーザーを作成し、パスワードを入力

ここで安心してはいけません。
パスワードの入力だけは「US配列（us101/104）」で処理されているのです。

その結果：

  • 設定したはずのパスワードでログインできない

  • 表示と記録されたパスワードの内容が異なっている

  • 特に記号を含むパスワードは、高確率で「入力ミス」扱いになる

という致命的な事態が発生します。

🔍 詳細な現象

Anaconda の UI 上では日本語キーボードを使用しているように見えますが、
パスワード設定に限ってはキーボードレイアウトが us に固定されているため、
JIS 配列と US 配列でキー位置が異なる記号を使うと、完全に別の文字列として保存されてしまいます。

🔐 Anaconda でのパスワード入力時の注意点：使用する文字種に制限あり

⚠️ 特に避けるべき記号（JIS配列とUS配列で位置が異なるもの）

記号 US 配列のキー位置 JIS 配列での挙動
@ Shift + 2 「（JISでは Shift + [）」
_ Shift + - 「ろ」キー（JIS）
{} Shift + [ / ] 「[」や「]」キーで位置ズレ
" Shift + ' 「Shift + 2」（JISでは @）
= Shift なし（右上） 「Shift + 0」（JISでは ^）

✅ 配列に依存しない「安全なパスワード」の例

  • 半角英数字のみ

  • US/JISどちらでも物理キーが一致する記号（! # $ % &）を使う

パスワード例 安全な理由
Aa13579!$ 覚えやすく、記号も共通
MyPwd2024# よくある形式＋配列に依存しない記号
Strong99Pass! ! はどの配列でも同じ位置
Fedora_1234 _ は避けた方が安全（JISでは「ろ」）
KitaNoYuki84% 日本語っぽさと記号を両立

インストール時のパスワードは、できる限り「英数字のみ or 安全な記号」に限定するのが賢明です。

🛠️ 回避策：AnacondaのUS配列強制を乗り越える手順

✅ ステップ①：Live 起動直後に一時的に US 配列に切り替える

bash

sudo localectl set-keymap us 

sudo localectl set-x11-keymap us

確認：

bash

localectl status

→ VC Keymap と X11 Layout が us になっていればOK。

✅ ステップ②：Anaconda（インストーラー）を起動




bash



anaconda 



この状態なら、表示されたキーボード配列と、実際の保存が一致します。





✅ ステップ③：インストール完了後、日本語キーボードに戻す



bash



sudo localectl set-keymap jp106

sudo localectl set-x11-keymap jp jp106

echo KEYMAP=jp106 | sudo tee /etc/vconsole.conf

 



✅ ステップ④：GRUB 起動時も日本語キーボードに対応させる



 



bash



sudo nano /etc/default/grub 



以下を編集：



bash



GRUB_CMDLINE_LINUX="rhgb quiet vconsole.keymap=jp106" 



保存後、GRUB を再構築：



BIOS（レガシー）：



bash



sudo grub2-mkconfig -o /boot/grub2/grub.cfg 



UEFI：



bash



sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg 





✅ ステップ⑤：ログイン後、パスワードを再設定（日本語配列で）



bash



passwd 



→ これで以後は、日本語配列で正確にパスワード入力が可能になります。





📝 最後に：Anacondaは見た目と内部処理が一致しないことがある



今回の件で分かったのは、「GUIで設定した内容が、必ずしもそのまま適用されるわけではない」ということです。



Anaconda は強力なツールですが、一部の処理（特にパスワード入力）では、内部的に US 配列に固定されてしまうという仕様上の制約があります。





🧠 教訓とおすすめ



    
	
  • 
	
    インストール時のパスワードは「配列に依存しない文字種」で構成する
    • 
	
  • 
	
    必ず localectl で実際のキーマップを確認しながら作業する
    • 
	
  • 
	
    必要なら一時的に US 配列に切り替えてからインストールを行う
    • 

Fedora 42 on TOSHIBA dynabook Satellite B754/98L
Fedora 42 をTOSHIBA dynabook Satellite B754/98LBに入れた。FreeBSD 14.2 で運用していたのだが当面サーバー類をこのPCでは使わないのでリプレース。でもって、インストールは通常のインストーラを使って問題なく完了。各デバイスとドライバも全く問題なし。快適に使える。15年前の機種だっけか。



元々、SE Linuxが標準で動いているが、ついでにFirewalldを起動して（元から入っている）一応セキュリティー対策をしたのでメモ。


 


1. firewalld を起動・有効化


sudo systemctl enable --now firewalld 


2. firewalld の設定


以下、シェルスクリプトを作成して（実行権限を与えて）、root(sudo suして)で実行


 


※ Wireguard VPN 用


 


スクリプト（init_firewalld.sh）


#!/bin/bash



ZONE="FedoraWorkstation"



echo "🧹 既存の設定を初期化中（rich rules・ports・protocols）..."

firewall-cmd --permanent --zone=$ZONE --remove-port=53/udp

firewall-cmd --permanent --zone=$ZONE --remove-port=51820/udp

firewall-cmd --permanent --zone=$ZONE --remove-protocol=icmp

firewall-cmd --permanent --zone=$ZONE --remove-protocol=ipv6-icmp



# 既存の rich rules を一括削除（繰り返し）

for i in {1..50}; do

  firewall-cmd --permanent --zone=$ZONE --remove-rich-rule="rule family='ipv4' source address='0.0.0.0/0' drop" 2>/dev/null

done



# デフォルトポリシーを DROP に設定

echo "🔒 デフォルトポリシーを DROP に設定..."

firewall-cmd --permanent --zone=$ZONE --set-target=DROP



# ポート開放（IN）：UDP 53, 51820

echo "📥 必要な INポート（UDP）を許可..."

firewall-cmd --permanent --zone=$ZONE --add-port=53/udp

firewall-cmd --permanent --zone=$ZONE --add-port=51820/udp



# ICMP の不要なタイプをブロック（DoS対策等）

echo "🚫 不要な ICMP タイプをブロック中..."

for icmp in \

  echo-reply \

  destination-unreachable \

  time-exceeded \

  parameter-problem \

  redirect \

  source-quench \

  router-solicitation; do

  firewall-cmd --permanent --zone=$ZONE --add-icmp-block=$icmp

done



# ICMPv4/v6 で ping/RA/近隣探索などを許可

echo "✅ 必要な ICMP タイプ（ping/RA/近隣探索）を許可..."

for icmp in \

  echo-request \

  neighbor-solicitation \

  router-advertisement; do

  firewall-cmd --permanent --zone=$ZONE --remove-icmp-block=$icmp

done



# rich rules で OUT向け TCP/UDP ポートをホワイトリスト形式で許可

echo "📤 OUT向け TCP/UDP ポートを rich rule で許可..."



for port in 80 139 443 445 465 515 993; do

  firewall-cmd --permanent --zone=$ZONE \

    --add-rich-rule="rule family='ipv4' destination address='0.0.0.0/0' port port=$port protocol=tcp accept"

  firewall-cmd --permanent --zone=$ZONE \

    --add-rich-rule="rule family='ipv6' destination address='::/0' port port=$port protocol=tcp accept"

done



for port in 53 51820; do

  firewall-cmd --permanent --zone=$ZONE \

    --add-rich-rule="rule family='ipv4' destination address='0.0.0.0/0' port port=$port protocol=udp accept"

  firewall-cmd --permanent --zone=$ZONE \

    --add-rich-rule="rule family='ipv6' destination address='::/0' port port=$port protocol=udp accept"

done



# samba と ssh をサービスとして許可

echo "🔧 Samba・SSH サービスを許可..."

firewall-cmd --permanent --zone=$ZONE --add-service=samba

firewall-cmd --permanent --zone=$ZONE --add-service=ssh



# 設定を反映

echo "🔁 firewalld をリロード..."

firewall-cmd --reload



echo "✅ firewalld 初期化と設定が完了しました。"



※　外部からのpingに反応したかったら


sudo firewall-cmd --permanent --zone=FedoraWorkstation \

  --add-rich-rule="rule protocol value='icmp' accept"

sudo firewall-cmd --reload

 


2. ロギング の設定


setup_firewall_logging.sh


#!/bin/bash



echo "🔧 Firewalld + Iptables ログ設定を開始します..."



#=======================

# 1. firewalld rich-rule による DROP ログ

#=======================

echo "🚧 firewalld に DROP ログルールを追加..."

firewall-cmd --permanent --zone=FedoraWorkstation \

  --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" log prefix="FIREWALL DROP: " level="info" drop'

firewall-cmd --permanent --zone=FedoraWorkstation \

  --add-rich-rule='rule family="ipv6" source address="::/0" log prefix="FIREWALL DROP: " level="info" drop'



#=======================

# 2. iptables / ip6tables ログ用チェイン

#=======================

echo "🚧 iptables に LOG チェインを追加..."

iptables -N LOGGING 2>/dev/null

iptables -C INPUT -j LOGGING 2>/dev/null || iptables -A INPUT -j LOGGING

iptables -C OUTPUT -j LOGGING 2>/dev/null || iptables -A OUTPUT -j LOGGING

iptables -C FORWARD -j LOGGING 2>/dev/null || iptables -A FORWARD -j LOGGING

iptables -C LOGGING -j LOG --log-prefix "IPTABLES LOG: " --log-level 4 2>/dev/null || iptables -A LOGGING -j LOG --log-prefix "IPTABLES LOG: " --log-level 4

iptables -C LOGGING -j RETURN 2>/dev/null || iptables -A LOGGING -j RETURN



echo "🚧 ip6tables に LOG チェインを追加..."

ip6tables -N LOGGING 2>/dev/null

ip6tables -C INPUT -j LOGGING 2>/dev/null || ip6tables -A INPUT -j LOGGING

ip6tables -C OUTPUT -j LOGGING 2>/dev/null || ip6tables -A OUTPUT -j LOGGING

ip6tables -C FORWARD -j LOGGING 2>/dev/null || ip6tables -A FORWARD -j LOGGING

ip6tables -C LOGGING -j LOG --log-prefix "IP6TABLES LOG: " --log-level 4 2>/dev/null || ip6tables -A LOGGING -j LOG --log-prefix "IP6TABLES LOG: " --log-level 4

ip6tables -C LOGGING -j RETURN 2>/dev/null || ip6tables -A LOGGING -j RETURN



#=======================

# 3. rsyslog設定の追加（ログファイル分け）

#=======================

echo "📄 /etc/rsyslog.d に設定ファイル作成..."

cat <<EOF > /etc/rsyslog.d/firewall-logging.conf

:msg, contains, "FIREWALL DROP: " -/var/log/firewalld.log

:msg, contains, "IPTABLES LOG: " -/var/log/iptables.log

:msg, contains, "IP6TABLES LOG: " -/var/log/iptables.log

& stop

EOF



#=======================

# 4. logrotate設定

#=======================

echo "📄 /etc/logrotate.d にログローテーション設定..."

cat <<EOF > /etc/logrotate.d/firewall-logs

/var/log/firewalld.log /var/log/iptables.log {

    weekly

    rotate 8

    compress

    missingok

    notifempty

    create 0600 root root

}

EOF



#=======================

# 5. rsyslog 再起動と firewalld リロード

#=======================

echo "🔁 firewalld / rsyslog を再起動..."

firewall-cmd --reload

systemctl restart rsyslog



echo "✅ 完了しました！ログは以下に出力されます："

echo "  ・/var/log/firewalld.log"

echo "  ・/var/log/iptables.log"

 
Buffalo VR-U500X VR-U300W
私は、YAMAHA RTX-1200 を長い間愛用していたのだが、リプレースにあたりRTX-1300を検討したたものの、Wi-Fiアクセスポイントも必要だったので、Buffalo VR-U500X VR-U300Wを購入した。2台でRTX-1300を購入するより安かったからだが・・・失敗した。


 


まずは、２台とも必ず設定用のssh接続を切っておくことをお勧めする。元々、コマンドは非公開だし。フィルターの設定とかはできないし。WEBアクセスで設定するしか現状方法はない。それは構わないのだが、設定用のhttpd は1.8.1 2018でChatGPTによると既知のセキュリティーホールがあるとのこと。まあ、サブネットの内側からしかアクセスできないとして放置するしかないが。nmapで調べて確認して驚いた。


 


続いて、VR-U500Xだ。これは１段目のルーターとして当初PPPoE接続していた。何故というに、IPv6のファイアーウオールでホワイトリスト形式で設定しようとすると、一旦全ての通信を遮断してから必要なポートなり通信なりだけを許可するわけだが、IPoEでそれをやろうとしてもまともに出来なかったからだ。


 


そして、ステートフル動作を謳い文句にしながら出来ないという致命的な欠陥がある。状況をBuffalo(Melco)のサポートに連絡し、設定ファイルとパスワードを提供したところメーカーでも再現したとの連絡がありファームウエアの修正は見込みが立たないと連絡が来た。それが、約１年前。


 


で、３月末に新しいファームウエア 1.40がリリースされ、治ったかと思ったら修正されていなかった。勿論、Melcoからの連絡は全くなし。仕方ないので、バグを回避しながらIPoEに接続方式を変更してファイアーウオールを無理やり張った。ドコモ光１G ISP Biglobeという環境。


 


IN　ICMPv6　通す プロトコル 41,136 通す UDP 5473 通す TCP/UDP 32768-65535 通す 終端で全て通さない。


OUT ICMPv6　通す プロトコル 41,136 通す UDP 53 123 5473 通す TCP 80 443 通す。終端で全て通さない。


 


思いっきり雑だが、こうしないとステートフル動作しないから仕方ない。また、MTUは初期設定の1500のままでないとダメ。


 


IPv4 は一応ステートフル動作してくれるので、普通のホワイトリスト方式で問題ない。YAMAHA RTX-1300にしておけば良かったと泣きが入りながら一旦初期化して設定し直した。ChatGPTでは似たような動作不良の報告ありと言われ妙に納得した。


 


Wi-Fi用のVR-U300Wは、上記バグにつかまらない。VR-U500XからIPv6 自動判別、IPv4 DHCPにでもしておけば、後はファイアーウオールをホワイトリスト方式でがっつり組める。一応、ステートフル動作してくれるので。


 


私は、Wi-FiはWPA3エンタープライズにしてある。但し、接続のIDとパスワードをRadiusでしっかりと設定し、我が家の場合スマホはI-Phoneなのだが、必ず接続は最初からSSIDを直差し、WPA3エンタープライズで設定する。でないと接続情報をクラックされることになる。散々、ただ乗りと侵入をされる羽目になった。おまけに、ルーターを乗っ取られた。


 


ともあれ、きちんと安心に設定運用したいなら YAMAHA RTX-1300 + Wi-Fi AP で組むようにChatGPTに強く推奨された・・・当然、ぶらさがっていたデスクトップPCはWindows 11Pro だがNorton360で、これまたファイアーウオールをきつく張っていても簡単に突破されという事態になっていて、マルウエアとバックドアの宝庫に成り下がっていた。


 


ルーターの設定を全面的に初期化してやり直しした上で、Kali Linuxを使い、AIに散々助けられながら被害を確認し、手作業での復旧をし、Norton360のファイアーウオールも改定したが、どっちみちクリーンインストールするしか道はない。泣けてくる。


 


もう二度とBuffalo製品は買わない。
Cursor-2
Cursorを使って、Freebsdのipfw（ファイアーウォール）のLinux(Fedora 41 Kernel 6.13)への移植実験をしてみた。


 


まず、chatgptと相談した結果


 


IPFW のソースコードは FreeBSD の公式リポジトリから取得できます。以下の手順で入手してください。




1. ソースコードの取得



(1) FreeBSD の Git リポジトリから取得



sh
コピーする編集する
git clone https://git.freebsd.org/src.git freebsd-src
cd freebsd-src



(2) IPFW のソースコードの場所



カーネルモジュール（ドライバ部分）とユーザーランドの実行部は分離されています。




	
		

			
			
コンポーネント

			
			
パス

		

	
	
		

			
			
カーネルモジュール (ipfw.ko)

			
			
sys/netpfil/ipfw/

		

		

			
			
ユーザーランドツール (ipfw コマンド)

			
			
sbin/ipfw/

		

		

			
			
カーネル関連ヘッダ

			
			
sys/netpfil/ipfw/ip_fw.h など

		

	






2. IPFW のカーネルモジュール (ipfw.ko) をビルド



FreeBSD の sys/modules/ipfw/ にあるカーネルモジュールを Fedora 41 に移植するには、Netfilter に適応させる必要があります。



(1) カーネルモジュールのビルド



sh
コピーする編集する
cd freebsd-src/sys/modules/ipfw
make



（Linux への移植では、FreeBSD 固有のコードを Netfilter 用に修正する必要があります。）





3. ユーザーランドツール (ipfw) のビルド



sh
コピーする編集する
cd freebsd-src/sbin/ipfw
make



この ipfw コマンドは、カーネルモジュール ipfw.ko と通信し、ファイアウォールルールを管理します。





IPFW を Fedora 41 に移植する場合、どの機能を優先的に移植したいですか？



    
	
  • 
	
    カーネルモジュール（ipfw.ko） から始めるか？
    • 
	
  • 
	
    ユーザーランド（ipfw コマンド） の移植を優先するか？
    • 




まずは FreeBSD の sys/netpfil/ipfw/ のソースを調査して、Linux への適応を考えるのが良さそうですね。



あなた:



まず、ユーザーランドから開始します。Makefileが無いので作成しなければなりませんが、FreeBSDのソースツリーから切り出せますか？



ChatGPT:



メモリを更新しました



FreeBSD の sbin/ipfw/ には Makefile が含まれていませんが、FreeBSD のソースツリーから ipfw の関連ファイルを切り出し、Linux (Fedora 41) 用の Makefile を作成できます。





1. 必要なファイルを取得



まず、FreeBSD の sbin/ipfw/ にある以下のファイルを取得します：



sh
コピーする編集する
cd freebsd-src/sbin/ipfw
ls



含まれている主なファイル：



    
	
  • 
	
    ipfw.c (メインのコード) 
    • 
	
  • 
	
    ipfw2.c 
    • 
	
  • 
	
    ipfw.h 
    • 
	
  • 
	
    ipfw.8 (マニュアル) 
    • 




また、ヘッダーとして以下も必要です：



sh
コピーする編集する
cd freebsd-src/sys/netpfil/ipfw/
ls



    
	
  • 
	
    ip_fw.h 
    • 
	
  • 
	
    ip_dummynet.h (Dummynet サポート用) 
    • 




以下、略



 



 



gitでfreebsdのソースツリーをコピー(自分のHOMEディレクトリ)して、その中のipfwのディレクトリを同じくHOMEディレクトリのトップへコピーして開始。



 



まず、Cursorで~/ipfwディレクトリを開き、chatで以下指示。



 



freebsdからLinuxへ移植する。



freebsdのソースは~/freebsd*** を走査する。



ユーザーランドのソースツリーを走査し、各ディレクトリにMakefileを生成配置。



 



CursorでMakefileを作成したら、移植開始。単にmakeして出てきたエラーをchatウィンドウへ送り（ターミナルウィンドウから一発）エラー修正を指示。



 



ipfwのソースにはヘッダファイルが無いので当然そのエラーから修正していくことに。具体的なchatgptからの返答がchatウィンドウに出る。それをプロジェクトに反映。



 



ざっとこんな感じ。



 



ドライバは措いてある。テストなので。結果、






のような作業風景になった。あくまでテストなので本番は、いちいちエラーをchatに手動でおくるのでは無く自動で送ることを想定している。



 



さて、できるかどうか。



 



結果：ユーザーランドの部分のビルドは出来たが セグメンテーションフォールトでコアダンプ。原因を探っていたら、使用回数の上限に達した。使用してみての感想だが、どれだけ的確な指示をAIに出せるかと、生成されたコードの確認とデバッグを自分で出来なければ辛いだろうなと。同じお金を出すなら他にも選択肢はあるので試してみてからにしようかなと。また、過渡期なのは否めない。将来、AIを使いながらのプログラミングは必須になるだろうとは思うが、今はおまかせは出来ないというのが実感。