オタク日記
(Mac と Linux, RasPi, 2024Q2)

目次

2024-06-05 (Wed): 外部サーバ(1: とりあえず更新・起動)
2024-06-19 (Wed): 外部サーバ(2: 疑似環境の整備)
2024-06-26 (Wed): 外部サーバ(3: Bogofilter)

古い日記:
2019Q3   2019Q2   2019Q1  
2018Q4   2018Q3   2018Q2   2018Q1  
2017Q4   2017Q3   2017Q2   2017Q1  
2016Q4   2016Q3   2016Q2   2016Q1  
2015Q4   2015Q3   2015Q2   2015Q1  
2014Q4   2014Q3   2014Q2   2014Q1  


2024-06-05 (Wed): 外部サーバ (1: とりあえず更新・起動)

そろそろ、オタク日記他を再開しようかな、と思いつつ、ダラダラと 5 年も経ってしまった……今度再開する時はああもして、こうもして、 と思っていたけど、まあ、そのせいでのびのびになったんだろうな。 という事で、とりあえず形式上は何も変えずに書き始める事にした。

waremo.com と otacky.jp を DigitalOcean の droplet (4GB, 80GB) 二個に載せていた。OS は Ubuntu-18.04。これを 5 年も使って(放置して) きたわけだ。

更新を始める前に、これをもうちょっと何とかしてみようと思ったが、 それにあたって色々な方策が有る中で、droplet に login する度に勧められる、do-release-upgrade をやってみようと…… www.waremo.com の server (droplet) の copy を作って、その上で 18.04 → 20.04 → 22.04 と upgrade する訳だ。やってみたら、殆ど問題なくうまく行っ た。(実は微妙なひっかかりが有ったのだが、詳細は忘れてしまった。)それで 安心して、ホンチャンの droplet で upgrade を実施、その後一月あまり、 www.waremo.comdms.waremo.com の運用を 続けているが、問題は無さそう。"So Far, So Good."

ところが、otacky.jp の方はそうは易々といかなかった。上と同様に droplet の copy の上で、do-release-upgrade をやるのだが、upgrade 自体に問題が多 い上に、upgrade をなんとか完成させても、httpd も mail、 mailman もうまく働いてくれない。随分難儀したが、mailman はアプリが通常の更新がで きなかったので、これについては一旦は諦めて、ホンチャンの droplet へ移行 する事にした。(しかし、これが大間違い、そう簡単には mailman は動いてく れず、その後一月あまりも mailman が停 止している。)

で、この間 mailman と格闘していたのだが、ふと、Apache (HTTPD server) の不具合も触った方が良いかな等と思ったせいで、また違う横道に逸れてしまっ た。ともあれ、最初の方の困難は忘れてしまったが、


2024-06-19 (Wed): 外部サーバ (2: 疑似環境の整備)

実は、大昔(5 年前?)は、手元のサーバ (OS X, Yosemite, 一つ前の Mac-mini) の上に、よく似た環境を作って、rsync で同期させていた。詳細はよく覚えていないが、 それで結構便利に使えていた。なので、今回も…と考えたのだが、なかなか。

とにかく、Apache をインストールする必要がある。ざっと紹介記事を読んだが、 最新の macOS にはインストールされていないかも、とか有ったので、 念のために

fukuda@octal:~% ps ax | grep apache2
とやってみたが、何もひっかからなかった。しかし、それも当然で、
fukuda@octal:~% ps ax | grep httpd
16549   ??  Ss     0:00.29 /opt/local/sbin/httpd -k start
16550   ??  S      0:00.01 /opt/local/sbin/httpd -k start
.....
16557   ??  S      0:00.00 /opt/local/sbin/httpd -k start
16558   ??  S      0:00.00 /opt/local/sbin/httpd -k start
16883 s000  S+     0:00.00 grep httpd 
てな具合に、apache2 ではなく、httpd に全て置き換わっているのだった。兎に角、 しばらく後に :-) 殺した。
fukuda@octal:~% sudo apachectl stop
fukuda@octal:~% ps ax | grep httpd    
17512 s000  S+     0:00.00 grep httpd

で、httpd が動いているのも知らずに MacPorts の Apache2 をインストールする。

fukuda@octal:~% sudo port install apache2
fukuda@octal:~% sudo port load apache2
fukuda@octal:~% ps ax | grep apache
16545   ??  Ss     0:00.02 /opt/local/bin/daemondo --label=apache2 
--start-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper start ; 
--stop-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper stop ; 
--restart-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart ; 
--pid=none  
17538 s000  S+     0:00.00 grep apache
この状態で、Firefox の http://localhost にアクセスしたら、"It works!" と答えた。 Nice! (httpd は殺した状態で。)

rsync で、サイトの模擬環境を作る。

fukuda@octal:~% resync_web () { rsync -Cuav otacky.jp:/var/www/ /Users/fukuda/public_www }           
fukuda@octal:~% resync_web 
fukuda@octal:~% ls -l public_www/html
.....
-rw-r--r--   1 fukuda staff    91240  6 17 18:17  otaku_comm-19Q1.html
-rw-r--r--   1 fukuda staff    90096  6 17 18:17  otaku_comm-19Q2.html
-rw-r--r--   1 fukuda staff    44219  6 17 18:17  otaku_comm-19Q3.html
-rw-rw-r--   1 fukuda staff    11824  6 19 18:11  otaku_comm-24Q2.html
.....
fukuda@octal:~% ls -l public_www/cgi-bin
total 64
-rwxr-xr-x  1 fukuda staff     8080  6 19 14:47 counter5.cgi*
-rwxr-xr-x  1 fukuda staff     7458  9 27  2014 counter_wa.cgi*
drwxr-xr-x 12 fukuda staff      384  5 19 07:13 data/
drwxr-xr-x  6 fukuda staff      192  7 15  2013 data_wa/
-rwxr-xr-x  1 fukuda staff     6487  9  1  2018 each_page.cgi*
-rwxr-xr-x  1 fukuda staff     5010  5 22 16:35 get_stat_div.cgi*
-rwxr-xr-x  1 fukuda _appstore 2060  6  4 12:25 show_graph.cgi* 
そっかぁ、www-data (元の外部サイトの所有グループ名)なんてものは、 このサイトには無いからな。

しかも、インストールしてみて判ったのだが、apache2 が外部サーバのそれとは随分違う。インストール先が、/opt/local になっているのは仕方無いにしても、httpd.confapache2.conf か、 から始まって、全く違っている。ちょっと気が遠くなるが… ともあれ、 /opt/local/etc/apache2/extra/httpd-vhost.conf

<VirtualHost *:80>
      ServerName localhost
      serverAlias octal.local

      ServerAdmin fukuda@otacky.jp
      DocumentRoot "/Users/fukuda/public_www/html"
      ScriptAlias /cgi-bin/ /Users/fukuda/public_www/cgi-bin/
      <Directory "/Users/fukuda/public_www/html">
            Options Indexes FollowSymLinks Includes
        	# AddHandler server-parsed .html   
		#		 XbitHack On
	    Require all granted
      </Directory>
	      
      <Directory "/Users/fukuda/public_www/cgi-bin">
   	     	AllowOverride None
   		Options Includes
   		Require all granted
      </Directory>

      ErrorLog "/opt/local/var/log/apache2/error.log"
      CustomLog "/opt/local/var/log/apache2/error.log" combined

</VirtualHost>
と書き変え、/opt/local/etc/apache2/httpd.conf の
# Virtual hosts
#Include etc/apache2/extra/httpd-vhosts.conf 
を uncomment して、
fukuda@octal:~% /opt/local/sbin/apachectl -t
AH00557: httpd: apr_sockaddr_info_get() failed for octal
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
fukuda@octal:~% sudo port unload apache2
Password:
--->  Unloading startupitem 'apache2' for apache2
fukuda@octal:~% sudo port load apache2
--->  Loading startupitem 'apache2' for apache2 
として、apache の構成(文法)の確認と、リセット(ストップ、スタートによって) する。(以降、構成を変更したら、いつもこれでリセットした。)ここまでで、
<!--#include virtual="xxxx" --> 
が無視された表示が得られる。つまりは、menu_div や counter の表示が全く無い、 main div のみが表示される。

上のリセットのやり方は、 MacPorts の Apache2 のページ から採ってきた。 同ページには、必須の include file を入れる方法が書いてあり、それをそのまま 当て嵌めて実行したら、少し前進した気がした。

こうなると、元のサーバで Load している .so ファイルをこっち (macOS) でも、 Load すれば良いはずだが、これがなかなか難しい。 なぜなら Ubuntu 22.04 では、conf ファイルの include や mods ファイルの include は、/etc/apache2/xxxx-available にあるファイルを /etc/apache2/xxxx-enabled に link を作る事で制御していた。 (これも実は Ubuntu 18.04 の方法を、do-release-upgrade のせいで、 引っぱっているだけかも知れない。)そこで仕方なく、xxxx-enabled に作られた link がどんな .conf ファイルや .so ファイルを include しているかを推察して、 /opt/local/etc/apache2/httpd.conf の対応部分を uncomment して行った。

勿論、httpd.confhttpd-vhost.conf の他の部分の調整も効いているに違いないが、ここまでの結果として、macOS の側の httpd が、https に未対応である事と、明確な URL を持たない事による制限を 除けば、今のところの問題は、access counter を担っている counter5.cgi がエラーを返す事くらいだろう。勿論重大な「制限」だが、まあでもこの環境では、 見え方を確認しつつ local の Emacs でページを編集するのが目的なので、 これで良い(としたい。)

2024-07-03 (Wed): などと、一旦は諦めたような事を書いたのだが、実はその後もダラダラと手を出していた。 主に counter5.cgi を色々と書き直していたのだが、 あんまり捗々しくないので、data/count.* の属性を変えてみた。
fukuda@octal:~% chown fukuda:staff public_www/cgi-bin/data/*
fukuda@octal:~% chmod o+w public_www/cgi-bin/data/*   
fukuda@octal:~% ls -l public_www/cgi-bin/data
total 132252
-rw-rw-rw- 1 fukuda staff       20  7  3 05:34 count
-rw-rw-rw- 1 fukuda staff     1983  7  3 05:34 count.cache
-rw-rw-rw- 1 fukuda staff        0  7  3 05:34 count.lock
-rw-rw-rw- 1 fukuda staff 15061094  7  3 05:34 count.stat
-rw-r--rw- 1 fukuda staff 27694031 11  9  2013 count.stat-2013-05-22
.....    

すると、counter5.cgi の動作がすっかり変って、これまでの 「count.cache に書けない…」で始まるエラーが無くなった。

そこでさらに調子に乗って、散々弄ってきた counter5.cgi を、 元の形に戻しても、ちゃんと動く。その時の data/count.cache を確認してみると次の通り。

fukuda@octal:~% tail ~/public_www/cgi-bin/data/count.cache
1719918507 127.0.0.1 20questions.html
1719918713 127.0.0.1 20questions.html
1719951447 127.0.0.1 index.html
1719951486 127.0.0.1 otaku_comm-24Q2.html
1719951504 127.0.0.1 otaku_comm-24Q2.html
1719952188 127.0.0.1 index.html
1719952239 127.0.0.1 index.html
1719952458 127.0.0.1 otaku_comm-24Q2.html
1719952471 127.0.0.1 index.html
1719952477 127.0.0.1 otaku_comm-24Q2.html

つまりは、data/count* の属性を変えたら、 os.environ.get('REMOTE_ADDR')os.environ.get('DOCUMENT_NAME') に正しく値が設定され、 "file lock failed" エラーも起きなくなった。

うーむ、めでたい! が、少しずつ訂正してきた counter5.cgi が一挙に元に戻ってしまった。


2024-06-26 (Wed): 外部サーバ (3: Bogofilter)

あまりよく覚えていないのだが、 2019年 Q1 の記録によると、 この時に SpamBayes から切り替えたらしい。 しかも、bogofilter-1.2.4+dfsg1 のソースに MeCab の patch を当ててコンパイルしている。

よし、それでは…と意気込んだが、Ubuntu 22.04 では、 bogofilter-1.2.5 なのに bogofilter-1.2.4+dfsg1 のまま。それでも、再コンパイルすれば MeCab は新しくなるが…

かなり迷ったが、ここは触らずに行く事にする。しかしそうすると、 crontab でフィルターをかけるたびに出てくる email:

To: fukuda@otacky.jp
Subject: Cron <fukuda@digoc04> source bogotrain
From: root@otacky.jp (Cron Daemon)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-Id: <20240625181001.EB91517C223@digoc04.otacky.jp>
Date: Wed, 26 Jun 2024 03:10:01 +0900 (JST)

Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied
Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied
を何とかしないといけない。

(色々やった馬鹿げたあれこれはさておいて)ちょっと真面目にやったらこうだろう、 というのを書くと、何より 3 時間ごとにエラーメッセージが出力されるので、 crontab から…

fukuda@digoc04:~% crontab -l
SHELL=/bin/bash
PATH=/usr/local/bin:~/scripts:/usr/bin:/bin
USER=fukuda
.....
57 4 */3 * * python ~/scripts/sitemap_gen.py --config=sitemap/config.xml 
10 */3 * * * source bogotrain 
この、bogotrain というのは、
fukuda@digoc04:~% cat scripts/bogotrain
#!/bin/bash
bogofilter -s -B ~/Maildir/.spambayes.spam_new
bogofilter -n -B ~/Maildir/.spambayes.ham_new
doveadm move spambayes.spam MAILBOX spambayes.spam_new ALL
doveadm move spambayes.ham MAILBOX spambayes.ham_new ALL
のこと。しかし、この先がどうにも解らない。そもそも、bogofilterdoveadm も、その詳細はかなりおぼろになっている。 いろいろ当てずっぽうをやったが、その中で上の email のエラーメッセージをそのまま Google にかませたら、それらしいサジェスチョンが出てきた。 (勿論、最初から正解はもらえなかったが。)結局、doveadm の user:goup が問題のようで、
fukuda@digoc04:~% cat /etc/dovecot/dovecot.conf
 .....
# A config file can also tried to be included without giving an error if
# it's not found:
!include_try local.conf

service stats {
     unix_listener stats-reader {
        group = mail
        mode = 0666
    }
    unix_listener stats-writer {
        group = mail
        mode = 0666
    }
}
service anvil {
    unix_listener anvil {
        group = mail
	mode = 0666
    }
}
として、bogofilter のトレーニングがやれて、 なおかつエラー・メッセージが出なくなった。
375/1,781,620 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2024-06-26 (Wed) 17:58:29 JST