<休日出勤>
(ヒタキを見つめるツグミ)
(ヒタキを見つめるツグミ)
ヒバリは家族旅行。成績が悪目立ち。DVD返さなきゃ。

試してみたことをメモ。考えたことをメモ。おっちょこちょいは治せない。
ファイアーウォールの設定のためか、WiFiでの接続ができず、ローカルでスマホを使ったチェックができていない。(PCブラウザのスマホモードで対応)
php8 WordPress プラグイン「search-regex」が存在するとエラーで進めなくなる。
(有効無効関係ない)
php7.4と切り替えができると良いが、php7.4のサポート期限が比較的近いので、php8で割り切る。
| 2020 | 2021 | |
| apache | A | arm | 
| bind | B | Big Sur | 
| CentOS | C | chillin | 
| dovecot | D | DKIM | 
| E | EV | |
| firefox | F | false | 
| GMO | G | |
| height | H | HDMI | 
| Interlink | I | IPv6 | 
| Jitsi Meet | J | |
| K | ||
| Let’s Encrypt | L | nslookup | 
| MakeShop | M | M1 | 
| nextcloud | N | |
| onlyoffice | O | ONU | 
| proxy | P | php8 | 
| Q | ||
| rgba | R | RTX830 | 
| SSH | S | Search Console | 
| thunderbird | T | Thunderbolt | 
| Ubuntu | U | USB3.0 | 
| VPN | V | virtualmin | 
| webmin | W | webmin | 
| X | XAMPP | |
| Y | yum -y | |
| zoom | Z | zone | 
10年遠回りした感じ
IPv6の接続プランで、ルーターにもよるが、手元のパソコンが外から見える状態になることがある。ONU直結でIPv6接続であれば確実に見えるだろう。
ただし、相手がこちらのIPv6アドレスを知る必要がある。
ローカルでワードプレスなどをみられるようにApacheが起動していること前提。
システム環境設定>ネットワーク>IPv6のアドレス
表示されているアドレスは、テキストとして選択、コピーが可能。
IPv4
http://192.168.101.33
IPv6(アドレスを[]で囲む)
http://[ここにあどれす]
ブラウザで確認する。手元のPCならみれるはず。
同じ環境の WiFiだと見えてしまうことがあるので、
スマホのキャリア回線で確認して、見えれば外部から確実に見える状態。

「詳細」をクリックすると、IPv6のアドレスがいくつかある。
タイミングの詳細は知らないが、これらのアドレスが、直近で使われたもの。

(上の画面で、「IPv6の設定」を「リンクローカルのみ」でも外部からは見えなくなる。外への接続もIPv6ではなくなる。)
システム環境設定>セキュリティとプライバシー>ファイアーウォール
ファイアーウォールを「ON」として、さらに「詳細」で、ブロックが設定されているか確認。最初に確認したときは、httpd がブロックされていなかった。
見えるか確認してみる。
Windows はファイアーウォールがデフォルトで効いているようだけれでども、Mac の場合は、デフォルトで On になっていない。
近いうちに、httpd まわりのない状態でOSが提供されるようになると、どこかで知ったが、こういった流れを組んでということかしら。
 
  
 
意図的にサーバを止めている間、警報音が鳴らないように、アプリを終了、もしくはスマホの電源を切っても、アプリを起動した瞬間、スマホから警報が流れる。
深夜にためしたので焦った。
インストール直後、やたらと警報がなるので、おかしいと思ったら、サーバーのIPv6の設定に間違いがあったためだった。WiFiからスマホの回線に切り替わるタイミングで警報がなった。
NTTのIPv6のアドレスが変化するためと思って、変わりにくい接続に変えたら安定している。
サーバーの機材で、ネットラジオの音楽番組をかけっぱなしにするという、ぬるい監視方法をしていた。
==========================================================
Summary of Results
==========================================================
SPF check: pass
“iprev” check: pass
DKIM check: pass
Mac(M1)から送信すると、上記のような結果になるが、
DNSを確認しようとして、コマンドからnslookupをかけても応答がない。
IPv6が優先されていないのが原因だけれども、時々、IPv6になる。
残念。
IPv6 にすると外部から直接端末にアクセスできるようになる。
ということで、Mac の、システム環境設定>セキュリティとプライバシー>ファイアーウォール ON
で、この状態で外部からIPv6 のアドレスで、アクセスしてみると、Mac は無反応になるが、
(mac のデフォルトのApacheも見えなくなる)あれ、見える。自動起動しないようにする。
XAMPP は見えてしまう。
XAMPP のトップページには、データベースへの入り口もある。
とりあえず、.htaccess へ追記「Require local」とする。
今までは、MySQLをインストールして、ローカル環境を整えていたけれども、phpのバージョンを変えたりしたかったので、XAMPP を使い始めていた。
M1 Apple Silicon の機材が手に入ってので、改めて、XAMPP を設定。
php -v
WARNING: PHP is not recommended
PHP is included in macOS for compatibility with legacy software.
Future versions of macOS will not include PHP.
PHP 7.3.24-(to be removed in future macOS) (cli) (built: Nov 23 2020 06:45:14) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
将来アップデートで削除されるとのこと
2021.01.20(19)リリースのphp7.4.14バージョン をダウンロードしてみる
xampp-osx-7.4.14-0-installer.dmg
ProFTPを起動しようとすると、再起動になってしまう。
xampp-osx-7.4.14-0-installer.dmg で動作確認
vm がつかないバージョン。
Apache configuration file: /Applications/XAMPP/xamppfiles/etc/httpd.conf, /Applications/XAMPP/xamppfiles/etc/extra/httpd-xampp.conf
PHP configuration file: /Applications/XAMPP/xamppfiles/etc/php.ini
MySQL configuration file: /Applications/XAMPP/xamppfiles/etc/my.cnf
ProFTPD configuration file: /Applications/XAMPP/xamppfiles/etc/proftpd.conf
prohtpd.conf
アクセス権の変更
<Limit SITE_CHMOD>
# DenyAll
AllowAll
</Limit>
ワードプレスや、プラグインの更新ができるように
cd /Applications/XAMPP/xamppfiles/
sudo chown -R daemon:daemon htdocs
Finder で自分のアクセス権も追加して、内包しているファイルにも適用。
(daemon を自分のユーザ名にしてみたが、MySQLでもdaemon が使われているようで、XAMPP のServer Event に赤い文字が出たのでやめた。)
下記の関連ドメインを削除
履歴の削除
/Users/ユーザ名/Library/Application Support/Firefox/Profiles/0yukulfc.default-release
.htaccess に下記を記載 ローカルフォルダと、公開しているドメインのサイトルート
Header set Strict-Transport-Security “max-age=0;”
2021.01.28追記
/Applications/XAMPP/xamppfiles/etc/httpd.conf
以下
コメントアウト
#LoadModule ssl_module modules/mod_ssl.so
#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>
https://www.apachefriends.org/jp/faq_stackman.html
の
How do I increase the size of the XAMPP-VM disk?
インストール直後はだめと書いてある。少なくとも1回は起動していないといけない。
50G 増やせた。
購入時は8G、巷によくある情報を使って、32Gにしている。
しかし、かなり忙しく使っても、8Gを超えない。少し前は、16Gを超えない程度での履歴もあった。
システムレポートでは、32ギガと認識しているけど、何かしらの「設定」を施さないと、メモリを有効に使いきれていないのではないだろうか。
ブレーキがかかるようなもどかしい動作がある。
購入時に32G、64G のものか、ストアで増設してもらうと、どのようになるか見てみたいな。
・仮想OS を二つ(内一つは、Windows 10)
・ローカルサーバ
・Adobe のソフト イラストレータ、フォトショップ、プレミア
・Acrobat  (起動するだけでかなり消耗する)
https://support.apple.com/ja-jp/HT208198
試してみる?
夏ごろのOSのアップデートで落ち着いていた「予期せぬ再起動」が、ここ最近2回のアップデートから、再発するようになってきていた。
Big Ser への更新案内もシステム環境設定に出てきている。
新しいM1を搭載したMacには、T2が搭載されていない。
以上のことから、もしかして、T2をキャンセルできるようにな設定項目が追加された?と思って「mac T2 停止」検索したら、上記のページがヒットした。
この後、試してみよう。
追記
上記ページに従って操作する。
コマンド+R 後の起動は普段よりもずっと遅い。
・セキュリティなし
・外部メディアからの起動を許可
とする。
直近のリブート
reboot ~ Thu Dec 3 21:41  今回のセキュリティ設定変更
reboot ~ Thu Dec 3 12:19  予期せぬ再起動
reboot ~ Sun Nov 22 20:05  予期せぬ再起動(不確か、メモ残っていない)
reboot ~ Mon Nov 16 17:03  予期せぬ再起動
reboot ~ Sun Nov 15 16:24 アップデート
調子の悪かった時と同じように、常時電源の入った状態で、一週間弱で落ちる。
さて、今回の設定の結果が出るのは、2週間以上落ちずに済むかどうかだ。
https://support.apple.com/ja-jp/HT208862
新しい Mac mini 2020 M1には T2はない模様。
購入が1年早かったかな。
今日も、予期せぬ再起動が起きた。アプリの更新通知のタイミング。
高価下取りで交換してくれないかな。
新しく用意したCentOS8サーバでcgiが動かない。
cgiを使わないようにすれば良いとも考えたけれども、既存サイトを引っ越してくるときにcgiをphpなどに置き換えるのは大変。
perl -v ある
which perl パスもOK
perl が、AP_DOC_ROOT=”/var/www” の中にないと動かないことになっている。
suexec -V で確認できる。
AP_DOC_ROOT=”/var/www”
で、suexec では SetEnv は効果ない。とのこと。
CentOS8 では、Apache のインストール時に AP_DOC_ROOT が決まっていて、ほかのバージョンの httpd をインストールすると更新できなくなってしまう。
ということで、新しく追加する仮想サイトを ”/var/www” 内にすることにした。
/var/www/html にしてはいけない。
期待通りに動いてくれている。
追記
違った
CentOS8 にて、boot, home の容量が決まっていて、/var/www では将来心配。
別の方法を検討。
boot の容量が足りなくて、新しいサーバに、リストアしたら、”/var/www”においたサイトが”/home”にリストアされた。
追記
CentOS 8 インストール時に、home エリアは削除。
リストア前に、テンプレートのホームディレクトリを、var/www にすることで解決。
REST API リクエストはエラーのために失敗しました。
CentOS8 の hosts にローカルIPを追記:192.168.8.13 ****.jp
このままでも、ワードプレスやプラグインの更新ができないわけではない。
調べたページには、パーマリンクや.htaccessをいじることで解決した例がある。
数年前に組んだ CentOS7 の仮想サーバでは、同じ問題が出ていなかった。
このサーバで「Broken Link Checker」が正常に動いていなかったので、hostsいじったなあ、という経験から。自分自身を正常にチェックができないなら、経路の問題ということで、試したら解決。
CentOS8 のLAN設定にDNSに「192.168.8.13」を追加しても解消しなかった。
サーバ本体のドメインは、hostsに反映されていたけど、
サイトを追加するたびに、hosts にも追記が必要なのは面倒だなあ。
やったこと
いろいろな問題が重なったりして、解決までに9か月。
間違っている対処もあるかと思うが、ひとまず決着としてしまおう。