nabeの雑記帳

Dell PowerEdgeサーバに乗っているなんちゃってRAIDコントーラーS150を使用した状態で、Ubuntu Desktop 22.04をインストールしたメモ。

S150とは

よくあるBIOSでRAID化するだけの、実質ソフトウェアRAIDです。S150はLinuxのRAIDに対応しており、BIOSからLinuxで作成したRAID情報を参照できるようです。

つまりRAID化した状態でLinuxをインストールすることができれば、そのRAID化されたディスクから起動することも可能です。

Ubuntu Desktop 22.04のインストール

ミラーリング（RAID1）に設定する場合。

1. BIOSの設定からSATAのモードを「AHCI」から「RAID」に切り替えます。
2. Ubuntu Desktop 22.04をインストールイメージから起動します。
3. インストールではなく「Ubuntuを試用する」を選択します。
4. Terminalを開き、mdadmをインストールします。

   sudo apt-get install mdadm
   

5. ディスク全体でRAIDを構築します。

   sudo mdadm --create md0 --level=1 --raid-disk=2 /dev/sda /dev/sdb
   

   /dev/md127 として認識されます。
6. この状態で、Ubuntuをインストールします。インストール先はディスク全体を削除してインストール（自動選択でmd127）です。md127に2つのパーティションが作られます。
7. 「grub-install /dev/sda の実行に失敗しました」というメッセージが出たら再起動せずにウィンドウを閉じます。
8. /targetにRAIDディスクの/（md127p2）がマウントされていますので、ターミナルで以下の操作をします。

   sudo su
   cd /target
   mount --bind /dev dev
   mount --bind /sys sys
   mount --bind /proc proc
   cp /etc/resolve.conf etc/
   chroot .
   mount /boot/efi
   apt install mdadm
   grub-install
   

   これにより /boot/efi に必要なファイルが配置されますが、EFIブートメニューへの登録には失敗します。
9. EFIブートメニューに項目を登録します。

   efibootmgr -c -d /dev/md127 -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi'
   

あとはターミナルを抜けて普通に再起動すれば、RAID状態のディスクからUbuntuが起動します。

メモ

# EFIメニュー登録状態の確認
efibootmgr -v
# EFIメニューの項目削除
efibootmgr -B -b 0001
# Software RAIDの状態確認
cat /proc/mdstat

# /etc/defult/grub
GRUB_RECORDFAIL_TIMEOUT=3
GRUB_DISABLE_SUBMENU=y

カーネルだけ更新

v5.17.9の場合。

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-headers-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-headers-5.17.9-051709_5.17.9-051709.202205180947_all.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-image-unsigned-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-modules-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.9/amd64/linux-modules-iwlwifi-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb

dpgk -i *.deb

OpenWrtを設定＆構築したメモ。DS-LiteではなくMAP-Eでも参考になるかと思います。

• ことの発端
• 構築目標
  • 前提条件
• OpenWrtと対応機種
• OpenWrtのインストール
• IPv6パススルーの設定
  • 解説
• DS-Liteの設定
• PPPoEとマルチルーティングの設定
  • ルーティングテーブルを増やす
  • pppoeインターフェイスを作成する
  • ルーティング設定
  • 接続が安定しない場合
• ファイヤーウォールの設定
  • ゾーン設定
  • 個別ルールの設定
• フェイルセーフモードと強制復旧方法
  • ファクトリーリセット
  • failsafeモードへ
  • リカバリーモード
• その他の設定
  • ルーティング/NATのオフロード設定
  • PPTP接続（VPN接続）のパススルー
  • サーバの外部公開
• 通信速度例
  • 余談
• まとめ
• メモ

※ネットワークの知識がない方はOpenWrtには手を出さないでください。

ことの発端

家庭内ルーターとして「NEC Atermシリーズ」を使っていたのですが、性能は申し分ないものの問題点があります。

• 最新機種でもDS-Lite使用時PPPoEをパススルーできない。*1
• そのせいで、PPPoEとDS-Liteの併用ができない。*2
• LAN内にDNSサーバを立てるとルータのDNSマスカレード機能が不安定になる。

WG1200HSはDS-Lite非対応なので、PPPoEと併用可能なら新しいのに買い替えてもよかったのですが、こんな状況ではAtermが選択肢に入らない。かといってBuffaloは安定性に問題ありそうなので、いっそのことOpenWrtルーターすればよいのでは？　と。

構築目標

• PPPoEとDS-Liteを併用する
• LAN内の一部のマシンのみPPPoE側を使用する。

前提条件

• ルーターのWAN側にはONU（光回線終端装置）が接続されている。
• IPv6オプション（IPv6ネイティブ通信）が利用可能になっている。
• DS-Lite（or MAP-E等）が使える状況になっている。
• PPPoEが使える状況になっている（プロバイダ側で併用が許可されている）。

続きを読む

Windows10からファイルをコピーしていると「予期しないエラーのため、ファイルをコピーできません」「エラー 0x80070032: この要求はサポートされていません」と表示される問題。

エラーの状況

• コピー元: Windows 10
• コピー先
  • Samba Version 4.9.5 on Linux
  • Filesystem NILFS2

この状況で大量のファイルをコピーしていると、一部のファイルやフォルダでエラーが発生します。

ログの調査

• Windows 7では起きていなかった。
• Samba側のファイルシステムがext4だと起きない。

「log level=10」に設定して、ログを確認しみました。

set_ea_dos_attribute: Cannot set attribute EA on file AU.txt: Error = サポートされていない操作です
open_file_ntcreate: FILE_OPEN requested for file AU.txt and file doesn't exist.

ファイルの作成に失敗しているような感じです。

原因

Sambaは「store dos attributes = yes」のときに、DOS attributeと呼ばれるファイル属性を維持したままファイルを保存しようとします。

DOS attributeとは、Windows登場前の大昔に存在したファイル属性で、古くは「R,S,H,A」の4種類がありました。Windows時代になって不要となったものだと思っていたのですが、知らない間に拡張され続けていたようです……。

Windows では attrib コマンドによってファイル属性（DOS attribute）を確認または変更できます。*1

このうち、比較的最近拡張された「X, P, U」属性があると、NILFSはこれらの属性値に対応していないためコピーに失敗します。

解決策

smb.confに以下を設定します。

	store dos attributes = no

この設定のデフォルトは元々 no だったのですが、Samba 4.9（2018年9月）以降で yes に変更されています。

ext4等のファイルシステムは対応済のようですが、NILFSのようなメジャーではないファイルシステムを使用しているとこの問題に当たるかと思いますので、記録として残しておきます。

雑感

SambaはNTFSのファイルアクセス権限（NT ACL）等、ファイル属性をなるべく維持するように作られていて、ファイルシステム側もそれに対応できるよう拡張されてきた歴史があります。user_xattrでググると色々出てきます。

Linuxのシステム構造の中に、NTのアクセス権限やDOSのファイル属性が残るというのも不思議な感じですが、それが災いしてしまった事件でした。

どれだけ検索しても（海外含め）同じ不具合踏んでる人がいないので苦労しました……。

最近の新しいLinux KernelでNILFS（NILFS2）を使用すると、最初の書き込み時に

BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

となるエラーの解決方法（対処療法）。

• NILFSとは
• 新しいカーネルで動作不安定に
• 簡単な解決策
• やや複雑な解決策
  • 参考文献
• まとめ

NILFSとは

ログ構造化ファイルシステムと言われる、ファイルを変更するたびに常にスナップショットを自動的に保存できるLinux標準サポートのファイルシステムです。

/home 以下などをNILFSにしておくと、間違えてファイルを書き換えたときや、間違えてファイルを削除したときに、1時間前や1週間前の状態に遡ってファイルを復元することができます。

間違ってファイルを削除（上書き）してまうこと、ファイルを直接変更してしまってから元に戻したいことは誰しもあると思いますが、NILFSならいつでも元に戻せるため人為的にミスにとても強く重宝しています。

• Ubuntu 10.04 LTS で NILFS on RAID1 (nilfs2)

新しいカーネルで動作不安定に

このNILFSですが、最近の（ここ1年ぐらいの）カーネルで動作不安定になる不具合があります。Debian 10.4をインストールした際にこの問題に当たってしまいました……。

調べるとカーネルのファイルキャッシュに対するちょっとした変更（パッチ）が原因となっているようです。解決策はLinux系のMLにありました（そしておそらく投稿者の記事）。

要約すると「NILFSをマウントする前に、ダミー書き込みをすれば良い」とのことです。

簡単な解決策

/etc/fstab では自動マウントせずに（noautoオプションをつける）、rc.localでマウントするように変更します。

dd if=/dev/sda6 of=/dev/sda6 count=1
mount /home

/dev/sda6 やマウント場所は該当のパーティション等に合わせてください。ddコマンドで512バイトほどダミー書き込みをしてからマウントします。たったこれだけで問題は解決します。

やや複雑な解決策

rc.local でマウントする方法では、NILFSパティーション以下にDBデータ等サービスで使用するデータを置く場合や/varがNILFSパーティションだった場合に問題があります。rc.local のタイミングでマウントするのでは遅すぎるからです。

ですので、理想としてはfstabでマウントする直前にダミー書き込みを実行したいのです。

Debian系のsystemd環境では以下のような設定ファイルを置くことで、fstab実行直前にダミー書き込みを実現できます。

# /etc/systemd/system/nilfs2-dummy-write.service
[Unit]
Description=NILFS2 dummy write
DefaultDependencies=no
After=local-fs-pre.target
Before=local-fs.target

[Service]
ExecStart=/bin/dd if=/dev/sda6 of=/dev/sda6 count=1
Type=oneshot

[Install]
WantedBy=sysinit.target

ファイル作成後、サービスとして認識されたか確認します。

# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             disabled

認識されているようなら、サービスを有効にします。

# systemctl enable nilfs2-dummy-write
# systemctl list-unit-files --type=service | grep dummy
nilfs2-dummy-write.service             enabled

参考文献

• Systemdを使ってさくっと自作コマンドをサービス化してみる

まとめ

• NILFS/NILFS2はとても便利なのに利用者が少ない。
• パッチが出てるので、近々修正されるとは思う。
• systemdの勉強になった。

Apache + php-fpm 環境で Debian 9(jessie) から 10(buster) にアップデートしたら動かなくなったので、メモ。

• 概要
• Debian10での設定
  • php7.3-fpm.confの中身（特に変更せず）
• 以前使っていた古い設定
• 何が変更になったのか
• メモ

概要

Debian付属のmod_phpはスレッドセーフではないため、Apacheを event_mpm や worker_mpm で運用している場合は使用できません（prefork専用）。

そもそも今どきmod_phpで動作させるのはナンセンスなので、FastCGIデーモンによるPHP環境 PHP-FPM を使用します。

Debian10での設定

• Apache 2.4
• PHP 7.3 (php7.3-fpm)

apt-get install php-fpm libapache2-mod-fcgid

php-fpmをインストールすることで自動的に「php-fpm7.3」サービスが起動します。

/etc/apache2/conf-available 以下に php7.3-fpm.conf が作られるので、これを有効にします。

cd /etc/apache2/conf-enabled
ln -s ../conf-available/php7.3-fpm.conf

proxy_fcgi_moduleが必要なのでこれも有効にします。

cd /etc/apache2/mods-enabled
ln -s ../mods-available/proxy_fcgi.load

この状態で、Apacheを再起動すれば有効になっているはずです。ついでに、OPcacheも最初から有効になっています。

php7.3-fpm.confの中身（特に変更せず）

# Redirect to local php-fpm if mod_php is not available
<IfModule !mod_php7.c>
<IfModule proxy_fcgi_module>
    # Enable http authorization headers
    <IfModule setenvif_module>
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    <FilesMatch ".+\.php$">
        SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <FilesMatch ".+\.phps$">
        Require all denied
    </FilesMatch>
    <FilesMatch "^\.ph(ar|p|ps|tml)$">
        Require all denied
    </FilesMatch>
</IfModule>
</IfModule>

以前使っていた古い設定

Debian 9(jessie)でも全く同じ設定で動作するのですが、以前は古い設定を使っていました。その設定を書いておきます。

• php-fpm7.0
• libapache2-mod-fastcgi (Debian9までしか提供されず)

Apache2の libapache2-mod-fastcgi（libapache2-mod-fcgidではダメ）を有効化してから、sites-available/000-default.conf 等に以下の設定を行います。

<IfModule mod_fastcgi.c>
        AddHandler      fastcgi-script  .fcgi
        AddHandler      php7.0-fcgi     .php
        Action          php7.0-fcgi     /usr/sbin/php-fpm7.0
        FastCgiExternalServer   /usr/sbin/php-fpm7.0 -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
        FastCgiConfig           -maxClassProcesses 100

        <Directory /usr/sbin>
                <Files php-fpm7.0>
                        Require all granted
                </Files>
        </Directory>
</IfModule>

何が変更になったのか

外部プログラムを呼び出して、そこから php-fpm サーバに接続するという形式が無効になったようです。上に書いた古い設定は多くの新しいLinuxディストリビューションで無効になっているようです。

この古い設定を行った場合、エラーログ等はなく「404 Not Found」と言われ白紙のページが出るだけなので混乱します。

現在は Apache に直接組み込んだ FastCGIのProxyのモジュール（proxy_fcgi_module）から、直接php-fpmに接続するようになりました。このほうが遥かに効率的です。

メモ

• php-fpmを利用する場合、SuEXECと併用できない。
  • SuEXECと同じことをしたければ、php-fpmデーモン（設定ファイル）を権限（ユーザー）ごとに分ける必要がある。