2026-05-12 SMB共有フォルダのアクセス権変更 【背景・目的】 norizuki.com の SMB 共有フォルダは LAN 内からのみアクセスし、使用者は3名のみ。 利便性向上のため、Internal 共有を全ユーザー(everyone)で読み書き可能にする。 ただしセキュリティを担保するため、全共有のゲストアクセスは無効化する。 【作業前の状態】 sharing -l で確認した共有3つ: - Internal (/Volumes/LACIERAID2TB/Internal): SMB, ゲスト=可 - aneeson.com (/Users/niac/web/aneeson.com): SMB, ゲスト=不可 - niacのパブリックフォルダ (/Users/niac/Public): AFP+SMB, ゲスト=可 【実施内容】 1. 全共有のゲストアクセスを無効化 sudo sharing -e 'Internal' -g 000 sudo sharing -e 'niacのパブリックフォルダ' -g 000 ※ 途中 -s 100 の意味を誤解し SMB を一旦無効化してしまったため、 sudo sharing -e 'Internal' -s 001 と sudo sharing -e 'niacのパブリックフォルダ' -s 101 で復元。 sharing コマンドのフラグは AFP/FTP/SMB の3桁順。 2. Internal に対し everyone への ACL を再帰付与 sudo chmod -R +a 'everyone allow read,write,delete,append, readattr,writeattr,readextattr,writeextattr,readsecurity, file_inherit,directory_inherit' \ /Volumes/LACIERAID2TB/Internal 対象 483,550 件中 246 件で "Operation not permitted" が発生。 調査の結果、これらは古い AppleWorks 6.app バンドル内部の 0バイト互換ファイル(HFS Classic Mac OS 時代の遺物)で、 SMB 共有実用上は影響なし。 ルートおよび一般ユーザーディレクトリ(DCIM, Desktop, FileMaker等) には正しく ACL が継承され、新規作成ファイルにも自動継承される。 【作業前のサーバー状態確認】 - uptime: load avg 3.33 (4論理CPU / 2物理コアなので許容範囲。 起動 20 分後で mdworker による Spotlight indexing が主因と判断) - df: LaCieRAID2TB 98% 使用、空き 48GB 【最終状態】 共有名 | プロトコル | ゲスト | everyone 権限 Internal | SMB | 無 | rw (継承付き) aneeson.com | SMB | 無 | 変更なし niacのパブリック | AFP+SMB | 無 | 変更なし 【メモ】 - ゲスト無効化により、SMB 接続は登録ユーザー(niac, menou, yuria, boss, aneeson 等) での認証が必要。3名の使用者にはアカウント共有を周知すること。 - 古いファイル名に ":" を含むものや AppleWorks 6.app 内のファイルは ACL 設定不可だが実害なし。 ---------------------------------------------------------------------- 2026-05-18 MariaDB 接続枯渇障害の復旧と再発防止 【背景・目的】 「norizuki.com の MariaDB が止まっているか」との問い合わせ。 調査の結果、mysqld は稼働していたが "Too many connections" で 新規接続を一切受け付けられず実質ダウン状態だった。原因究明と恒久対策。 【原因】 - mysqld が *:3306 で全インターフェース待受。norizuki.com はグローバル IP直付け(NAT無し)で、pf のルール上 3306 は whitelist 限定にもオープン ポートにも入っておらず外部から到達可能になっていた。 - 3306 への接続 133 件が全て CLOSE_WAIT で滞留(正常利用ゼロ)。 発生元は外部スキャナ/ブルートフォースbot (104.236.201.180 が 61 件、他 121.167.15.73 / 116.30.192.132 / 152.32.250.21 / 71.6.165.200 等)。 - my.cnf に max_connections 設定なし=デフォルト 151。滞留分で枠が 埋まり正規クライアント・管理者とも接続不可。 - 5/18 11:47 頃からスキャナ攻撃で枯渇、err ログに "Too many connections (unauthenticated host)" が連続。 【作業前のサーバー状態確認】 - uptime: load avg 1.17(2 users)、復旧作業中一時 1.80 まで上昇 - mysqld PID 46859 稼働、socket /tmp/mysql.sock、 datadir /usr/local/var/mysql(plist の --datadir 優先で稼働) 【実施内容】 1. pf で 3306 を whitelist 限定化(承認済み) /etc/pf.anchors/blacklist の block in quick proto tcp to any port {...} に 3306 を追加。 whitelist の pass quick が先なので作業Mac(159.28.108.1)/ 自宅(221.170.61.15)/localhost からは引き続き接続可。 常習bot 5IP を blacklist.txt に追加し sort -u。 pfctl -a blacklist -f /etc/pf.anchors/blacklist でリロード。 ※ 副次効果: blacklist テーブルが pfctl 未ロード状態(0件)だったのを アンカー再読込で蓄積済み数千件を全件有効化。 2. /usr/local/etc/my.cnf の [mysqld] に bind-address=127.0.0.1 追加 (mysqld 自体が外部インターフェースを待受けないよう二重防御)。 3. MariaDB 再起動(LaunchAgent homebrew.mxcl.mariadb 経由 unload→load)。mysqld がシャットダウンで滞留スレッド "did not exit" によりハングしたため kill -9 で強制終了 (InnoDB クラッシュセーフ、再起動時リカバリ正常完了・破損なし)。 4. 地雷除去: my.cnf の datadir=/Volumes/LACIERAID2TB/mysql_data 行を削除。これは過去に DB を LaCie RAID へ移そうとして Catalina の TCC(daemon は /Volumes/* が EPERM 拒否)により 断念した際の消し忘れ。plist の --datadir 優先で不活性だったが、 --datadir 無し起動時に空 datadir 新規作成/起動失敗の地雷のため除去。 【最終状態】 - mysqld 稼働(PID 57740)、127.0.0.1:3306 のみ待受 (err ログ "Server socket created on IP: '127.0.0.1'." で確認) - ping 正常、DB 5件(information_schema/mysql/niac/ performance_schema/test)健全 - CLOSE_WAIT 133→解消、外部到達不能で再発防止 - load 1.41 に低下 - バックアップ: /usr/local/etc/my.cnf.bak_*、 /etc/pf.anchors/blacklist.bak_*、blacklist.txt.bak_* を取得 【メモ】 - 外部ブルートフォース対策は「3306 を 127.0.0.1 待受 + pf 遮断」で 構造的に成立不能とするのが最強(レート制限より確実)。 - 25/80/443/587/993 は受信用に開放必須。これらは既存の auth-fail-blacklist.sh(2回失敗でBAN)+ DKIM/LE で運用継続。 - ローカルアプリ(as/ 等)は socket /tmp/mysql.sock 接続のため bind-address=127.0.0.1 / pf 遮断の影響なし。 ---------------------------------------------------------------------- 2026-05-18 旧業務システムの3月決算修正をWeb会計DB(niac)へ反映 【背景・目的】 旧業務システム(/Volumes/Internal/業務システム/会計＆販売管理)で 2026年3月分(会計年度2025・月12)の決算整理仕訳を実施・修正。 これをWeb会計システム(as/, MariaDB niac)へ反映する。 【調査でわかったこと】 - 移行手順は migrate_to_mariadb.py(Dropbox/www/業務システム/会計＆販売 管理/)。振伝/繰越バイナリ + 設定/勘定科目 を読み migration.sql を生成 →mysqlで流す「全件 TRUNCATE→全年度再投入」型(月単位パッチ機能なし)。 CommonDB.rdb は読まない。会計期は各レコードの日付で決定。 - 正本は /Volumes/Internal。スクリプトが読むDropboxコピーは未同期で古い。 - 決算整理仕訳は3/31付。今日の更新は振伝2026:02/03・繰越2026:04に入る (振伝2025:12は未変更)が、日付判定でFY2025月12へ正しく取込まれる。 - Web固有データ: FY2026(slip_date>=2026-04-01)43伝票はWeb入力分で要保全。 partner_id紐付け10件(補助簿の取引先タグ。うち8件FY2026/2件FY2025・3月)。 【実施内容】 A. バックアップ(TS=20260518_145738): 全gl_*を mysqldump (/Users/niac/db_backups/niac_gl_*.sql(.gz)) + 同一DB内に __bk_TS 複製。全件照合OK。 B. Web固有退避: gl_journal_slips/lines__web2026_TS(43/150)、 partner_id自然キー gl_partner_links__bk_TS(10件)。 C. 正本(/Volumes/Internal)読取りで migration_internal.sql 生成 (4845伝票/13540明細/科目120)→検証用DB niac_stg へ投入し検証 (FY2025/12=58件¥31,460,488、貸借一致0不整合、不明科目0、 FY2017-2024は本番と完全一致)。 D. 本番反映。※インシデント: 移行SQLは gl_settings だけ TRUNCATE 対象外で5/13分4行とPK重複し1回目停止(slips/lines/cf は TRUNCATE 済=空、accountsは再投入済の部分適用状態)。サーバ上SQLの gl_settings INSERT→REPLACE で冪等化し完全再投入で復旧。 続けて単一Txで: reload分FY2026(旧8件)削除→Web FY2026(43/150)を 新id採番マップ(slipmap)で復元(科目idは bk→名称→新id で再マップ、 partner_id保持)→FY2026 slip_no再採番→2026-04-01前partner_idを 自然キー再適用。 E. 検証。 【最終状態】 - 伝票4880/明細13656/繰越4784/科目120/取引先2 - 伝票毎 借方=貸方 不一致0、ヘッダtotal≠明細計 0 - FY2017-2024 bkと差分0(履歴不変) - FY2025・月12=58件¥31,460,488(決算反映)、FY2026=43件¥11,658,515 (Web保全、旧8件不採用) - partner_id 8/10。FY2025・3月の2件(旧line13541/13542,(株) オブジェクト 売掛金1,050,000/仮受消費税10,500)は決算再取込で 摘要が「(株)オブジェクト 2月売上」→「207 株式会社 オブジェクト」に 変化し自動再マッチ不発(安全側)。該当売上行は新データに実在 (例 line13484, partner_id=0)。会計残高に影響なし、補助簿の 取引先別表示のみ。対応(緩めキーで再設定/UIで手動/保留)は未定。 【再発防止】 - migrate_to_mariadb.py の gl_settings を INSERT→REPLACE に修正済 (Dropbox/www/業務システム/会計＆販売管理/migrate_to_mariadb.py、 構文チェック済)。次回からは再実行で重複停止しない。 【残置物(動作確認後に整理)】 - 同一DB内: gl_*__bk_20260518_145738(6表)、 gl_journal_slips/lines__web2026_20260518_145738、 gl_partner_links__bk_20260518_145738、検証DB niac_stg - サーバ: /Users/niac/db_backups/niac_gl_20260518_145738.sql(.gz)、 migration_internal_20260518.sql(.orig) 【SSH補足】 - 作業中 "Too many authentication failures" で一時切断あり。 -o NumberOfPasswordPrompts=1 / ConnectTimeout 付与で安定。 切断時はサーバ側未実行(セッション確立前)=本番無影響を都度確認。