Latest Publications

MacBookAir2020でマウスのBluetooth接続が切れる

表題通り。

旧MBAからの以降で、元々はトラブルもなく動いていたのに
2020にしてから切れる、つながらないという事例が頻発した。

sudo rm /Library/Preferences/com.apple.Bluetooth.plist
sudo rm /Library/Preferences/com.apple.Bluetooth.plist.lockfile

上記でBluetoothの設定を一旦削除してから再起動すると、
ほとんどの場合でつながるようになる。

新しいマウスを買うまではこれでしのいだ。

EC-CUBE用の拡張モジュールインストール

EC-CUBE4をサーバーに入れてみたら下記のエラー・警告が出た。

[必須] intl拡張モジュールが有効になっていません。
[推奨] apc拡張モジュールが有効になっていません。

[intlの導入]
sudo yum -y install –enablerepo=remi php74-php-intl

/opt/remi/php74/root/usr/lib64/php/modules/intl.so
ができているので、
/etc/php.d/20-intl.ini

extension=/opt/remi/php74/root/usr/lib64/php/modules/intl.so
と書く。

[apcの導入]
sudo yum -y install –enablerepo=remi php74-php-pecl-apc

/opt/remi/php74/root/usr/lib64/php/modules/apc.so
ができているので、
/etc/php.d/20-apc.ini

extension=/opt/remi/php74/root/usr/lib64/php/modules/apc.so
と書くが、
PHP Warning: PHP Startup: Unable to load dynamic library
とエラーになってしまう。

調べると、APCは古くてAPCuというのが新しいらしいので、一緒に入っていたapcu.soを使って
/etc/php.d/20-apcu.ini

extension=/opt/remi/php74/root/usr/lib64/php/modules/apcu.so
を書いた。

httpdをrestartさせるとphpinfoにも表示。
ただ、EC-CUBEの警告は消えないけど、新しいのに対応してないということみたいなのでスルー。

positivesslを新しいapacheに適用させるSSLCertificateFile

cat hoge.crt hoge.ca-bundle > hoge.full

LaravelでのSESメール送信でExpected response code 250 but got code “554”エラー

Laravelのシステムで、メール送信をAWSのSESに切り替えようと設定。

DKIMのドメイン設定にも苦労したが、CNAMEがどうしても認証されない。
色々変更した中で、切り替えてしばらく置いてからretryをしたら通った。
内容同じだったのに。

ようやくできたのでLaravelに設定するも、
Expected response code 250 but got code “554”
のエラー。

SESで登録したメール宛になら送れるのに、外部のメールに送れない。
fromに認証が必要なのはわかるけど、toに認証が必要なんておかしい、と思いつつ
結構時間をかけて色々調べてたら、結局SESのSMTPは初期ではSandBoxモードになっている、というオチだった。

SES管理画面の「Sending Statistics」から制限解除の申請ができる。

wordpressのsrcsetパスを変える方法

WordPressで運用中のシステムについて
ローカルでも動かす時の設定。

DBのwp_optionsで siteurl と home をローカルに変えると動くけど、
問題は記事中の画像パス。

記事としては絶対URLで指定しているので
srcはそのまま出るが、srcsetはそこから自動付加される。
自動付加される時、そのままだとローカルのパスになってしまい、画像を設置していないので表示されなくなる。

探した結果わかったのが、
DBのwp_optionsで upload_path と upload_url_path
を設定する必要がある。

初期設定のままなら両方とも
https://example.com/wp-content/uploads/
というようなパス。

これでsrcsetも指定したドメインのパスを見に行くようになったので
ローカルでも表示できた。

ZaimでのJ-WESTカードの連携

ZaimでJ-WESTカードと連携させようとすると
ログインIDとパスワードの入力画面になるが、
どのID&PWかがわからなかった。

JRおでかけネットの会員情報かと思い登録するもエラー。

結果、MUFG CARD WEBサービスとのことで、カード会社の方のだった。
https://www2.mufgcard.com/inet/jrw/login.html

SynologyのNASでMacのTimeMachine対応させた外付けHDDを使う

SynologyのNASにはUSBがあり、外付けHDDが接続可能。
MacのTimeMachineでも使っている外付けHDDを接続してデータ移動をさせようとすると
「読み込み専用」と認識されてしまい、使えなかったので、無理やり使えるようにしたメモ。

ディスクはhfsplusという形式でフォーマットされていたが、
これがこのままではSynology NASでは読み込み専用になってしまうよう。

まずは外付けHDDをMacにつなげて、terminalから

#diskutil list
で接続状況を確認。

この時には
/dev/disk4
で接続されていた。

#mount
でマウント状況を確認すると、該当ディスクは
/dev/disk4s2
となっていて、その属性に journaled というのがあるが、これを外す必要があるみたい。

#sudo diskutil disableJournal force disk4s2

とするとエラーが出たが、再度
#mount
すると journaled は外れていた。

外付けHDDをMacから外し、SynologyのNASに接続。

MacのterminalからSSHでNASに接続し、
#mount
でマウント状況を確認。
こちらでは
/dev/sdq2 on /volumeUSB1/usbshare1-2
となっていた。

属性の最初にある ro が読み取り専用を表している。
念の為NASのGUIから色々触ってみたが駄目だった。

#sudo -i
自分のパスワードEnterでrootになり
#umount /dev/sdq2
#mount -t hfsplus /dev/sdq2 /volumeUSB1/usbshare1-2
#mount
で確認すると、属性がrwになっていて、無事書き込みができるようになった。

Unable to load dynamic library ‘mcrypt.so’

PHPをアップグレードしたら、表題のエラーが出るようになった。

mcryptはphp7.2から削除されたとのこと。
エラーを出さないようにするにどうしたらいいかと色々やって、

/etc/php.d/mcrypt.iniをリネームしたら消えた。

Androidのエラー ”http://connectivitycheck.gstatic.com/generate_204″

サブ機のAndroidがある日から
“http://connectivitycheck.gstatic.com/generate_204”
にアクセスできません。

というようなエラーを出すようになった。
どんなアプリを使っていても強制的にこのエラー画面が出てくるので困る。

調べてみると、AndroidはこのURLに定期的にチェックをしに行き、
ネットに接続可能かを確かめるとのこと。
ただ、こんなエラーが出るものの他アプリではちゃんとネットにつながっている。

しばらく原因が不明だったが、一度だけエラー画面と同時に
一瞬、タイ語の画面が出た。

そのAndroidは日本ではSIMは運用していないが、
タイに旅行に行った際に買ったローミング用のSIMを2枚入れていた。
SIMは挿してはいるが使っておらず、次にどこか海外に旅行に行く時に設定するため挿したままにしていた。

もしやと思い、設定でSIMを無効にしたらエラーが出なくなった。
SIMを有効にしていると、WiFiにつながっていてもたまにSIMのデータ通信経由でチェックに行くのかもしれない。

Google広告で不承認: 機能していないリンク先

Google広告で、URLは絶対にあってるのに
「不承認: 機能していないリンク先」と出て、原因は500エラーとなる。

旧Search Consoleの「Fetch as Google」でチェックしても表示されてるし
描画もちゃんとされている。

「robots.txt テスター」でチェックしても対象になってる。

色々と調べて、新Search ConsoleのURL検査のライブテストをやったら
ここで500エラーの表示がついに出た。

現象さえ確認できれば後はチェックしていくだけで、
システムの色んなページで可能性のある部分を消しながらチェックしていき、
原因を追求。

今回の原因は
$_SERVER[‘HTTP_ACCEPT_LANGUAGE’]
をそのまま使っていたことが原因で、ブラウザで見てもエラーにはならなかった。

isset($_SERVER[‘HTTP_ACCEPT_LANGUAGE’])をかますことで解決。