Laravelで時間がUTCになってしまう
保存している時間がおかしい
Laravelでアプリ開発をしていてログを作る機能があったので何気なく
$date = date('Y-m-d H:i:s');
と言う変数にdate関数で日付と時間を入れ実行。
期待結果
2023-12-07 10:00:00
となるはずが
実行結果
2023-12-07 01:00:00
と記録されている。UTC時刻になってしまっている事が発覚。
ローカルでとりあえず作ったDockerと言う事もあり設定の見直し。
Linux側の時間の変更
### オリジナルをバックアップ cp /etc/localtime /etc/localtime.org ### タイムゾーンファイルの変更 ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
これで実行しても直らない。
と言う事はphp.ini側かと思い、php.iniの設定を見直すと
date.timezone = "Asia/Tokyo"
記載されていた。
となると最終的にはアプリケーションかと思い
/config/app.php を確認
/* |-------------------------------------------------------------------------- | Application Timezone |-------------------------------------------------------------------------- | | Here you may specify the default timezone for your application, which | will be used by the PHP date and date-time functions. We have gone | ahead and set this to a sensible default for you out of the box. | */ 'timezone' => 'UTC',
変更
/* |-------------------------------------------------------------------------- | Application Timezone |-------------------------------------------------------------------------- | | Here you may specify the default timezone for your application, which | will be used by the PHP date and date-time functions. We have gone | ahead and set this to a sensible default for you out of the box. | */ 'timezone' => 'Asia/Tokyo',
上記変更をしてテストを実行すると
2023-12-07 10:10:00
変更確認。
Laravel側が最終的に時間の概念を持っているとは思わなかった。
ただ自分としても他のDocker環境と変わらないのに時間がズレた事の根本原因をサーバーではなくアプリケーション側と断定するまでの判断が遅い。
反省。
PHPのfwriteでのエラー
管理画面でfwriteを使ってCSVを作成し、zipに圧縮してダウンロードさせる物があるのだがzipが開けないと言う報告を請けた。
既に運用して1年くらい経っていて、今までそんな兆候すらなかったシステムでのエラーなので不可解に思ったが調査。
まずはLinuxのエラーログ
PHP Warning: fwrite(): iconv stream filter ("utf-8"=>"cp932"): invalid multibyte sequence in /hoge/fuga/mogu/export.php on line 012, referer: https://ore.jp/system/hoge.php
iconv steram filter 上でマルチバイトの文字列がおかしくなっとるぞ。と。
エラーログに指摘されている行数ではfwriteをしている。
他のデータをエクスポートしながらログを追うとエラーログが出力される事はない。
また、このzipファイルになる前のtmpファイルのcsv自体はftpから落とすとexcelで正常に開ける。
zipファイルに圧縮する際に何かしらのエラーが発生して正しく動作していない物と思われる。
ここで考えられる事として、DB上に格納されたデータの文字列(特に2バイト文字)に何かしらの不備があると思われる。
ただ行数が多すぎて何がダメかと言う事自体を特定するのは運用しつつなので現実的ではない。
このファイル作成にあたる宣言部分は
stream_filter_append($file,'convert.iconv.utf-8/cp932');
となっているが
stream_filter_append($file, 'convert.iconv.utf-8/cp932//TRANSLIT');
と、TRANSLIT宣言を加えるとzipファイルの解凍が正常に出来るようになった。
取り急ぎすぐデータがほしい物との事だったので回避策として。
原因自体はデータから探すしかないか。
AWSのロードバランサにSSLにある際の強制SSLリダイレクト
サーバー側とアプリケーション側で開発が別れていると、サーバーサイド側の構成をあまり意識せず書いてしまう事が多いが
強制SSLのリダイレクトを.htaccessに書くと
<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
何も意識せずhttpでのリクエストはsつけてリダイレクトね。ってハナシで良いのだがAWSのロードバランサ側にSSLの設定がある場合は
ロードバランサ上ではSSLだがサーバーに到達する時に80の通信に変更している。
当然ロードバランサ側の設定をWebサーバー側は知らないワケだから、SSLに変換しようとして無限リダイレクトに陥ってしまう。
なのでAWSでELBを使った構成で、SSLがロードバランサ側にある場合は
<IfModule mod_rewrite.c> RewriteEngine On # Force HTTPS RewriteCond %{HTTP:X-Forwarded-Proto} !=https RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L]
M1 MacでDockerコンテナからsystemctlが利用できない
そろそろ前に買ったMacbookProが3年、vagrant + vmwareの構成でローカル内開発を行ってきた。
ただ、この環境もいつ壊れるか分からないと言う含みがある。
と言うのも、OSを現在のMontereyにアップグレードした際に、Vagrantが対応出来なくなって色々と難儀したと言う事を加味してもそろそろ新しいProがほしいと思っていた。
折しも半導体価格が様々な要因から円安も重なり一気に値上げしそうな予感。
と言う事で、MacbookPro2021(M1チップ10コア)を購入。
何気なく現行で使っている開発環境をそのままアカウント移行した。
$ cd /develop/001.centos/
$ vagrant up
いつものようにvagrant upを行ったが端的に言えばM1チップとなったMacではIntel、AMDCPUとは違ったモノなのでエミュレーション出来ないと言う事みたい。
chico-shikaku.com
こうなってしまうと、仮想環境をどうにかして作らねばならないと言う事と今までVagrantでやってきた事もあり手をあまり出していなかったDockerでの開発環境を作る事にした。
基本的にはDockerをインストールして、centosのimageをpullしてそこから環境構築となる。
はずだった。と言うかコマンドからdockerの実行と仮想環境内でのコマンド接続まではできた。
$ yum update $ yum install httpd ## sshが入っていないのでインストールする $ yum install openssh-server
と言う事で、SSHサーバーまでインストールしてサービスを開始する
$ systemctl start sshd.service Failed to get D-Bus connection
D-Busが失敗していますと出て起動時のオプションを変える等の手立てをしたが解決しない。
最終的にたどり着いた
zenn.dev
上記のリンク内
# デフォルトは false(v1を使わない) 設定 % cat ~/Library/Group\ Containers/group.com.docker/settings.json|grep deprecatedCgroupv1 "deprecatedCgroupv1": false, # false --> true に変更 % vi ~/Library/Group\ Containers/group.com.docker/settings.json % cat ~/Library/Group\ Containers/group.com.docker/settings.json|grep deprecatedCgroupv1 "deprecatedCgroupv1": true,
この通りにファイルを編集して、一旦マシンを再起動し再びコンテナを起動してsystemctlコマンドを打つと見事に動いた。
今後IntelチップのMacからAppleシリコンのチップに変わりゆく際に、多分同じような部分で詰まるのか。
それともその時代にはVagrantやDocker自体が対応しているかは定かではないが、2022年4月の段階では回避策としてはこんな感じでやらなきゃいかんよ。と言うメモ。
ワクチン三回目
3月16日11時にモデルナ接種、そのまま帰宅し自宅で開発作業を継続。特に大きな問題はなし。
20時 体温を計ると36.8度 そろそろか。
23時 寝る前に検温、37.2度 寝てる間は厳しいかなと覚悟
23時37分 地震で飛び起きる
24時30分 検温、38.4度 かなりきている
3時 毛布2枚と掛ふとんをかぶっている状態でも震えが止まらず。
一旦水分補給の為に立ち上がるも倦怠感が酷く身体が動きづらい。ポカリを接種し解熱剤も接種
検温すると39.4度、その後1時間ほど震えながら布団で我慢し意識がなくなる
6時30分 起床、身体の倦怠感がひどく身体を動かそうとしてもかなり軋んだ感じに。
検温すると38度
8時 解熱剤とポカリを接種し検温38.2度、多分まだ長引くと思われる。
身体の重さが尋常ではない、一度横になってしまうと動く気力が失われるのでなるべく座った状態にする。
9時 検温38.4度 あがっとるやないかい!
現在まだ体調悪い中だけど一旦記録。
ckEditorに属性を入れる
ckEditorと言えば、htmlタグを自由に編集出来るエディターとして自分は重宝している。
そのまま吊るしの状態で使う分には非常に使い勝手がよく、kcFinderと連動させると画像のアップロードも簡単なので
htmlタグをあまり知らなくても、この見出しとこのリンクと。と言う、使う物さえはっきりすれば簡単に出来る。
ただ、これが専門的にこうしたい
って言う部分として、要素に属性を入れたい
例)
<h2 id="hogehoge">ほげげ</h2>
のように属性を付けて保存をしても、基本的なセッティングのままでは保存の際に消えてしまう。(POSTする際にタグを抜かれてしまう)
属性を付与する為には以下のconfigを追加する
/ckeditor/config.js
CKEDITOR.editorConfig = function( config ) { ##これを追加する config.allowedContent = true; };
allowedContentと言う一文を追加すると属性タグが保存されるようになる。
配列をmb_convert_encodingするとアプリが動かなくなる
ありがちな事だが、テスト用サーバーは古いシステムも新しいシステムも混在する。
なので古いシステムにコンポーネントを合わせて環境がセットアップされている。
新しいシステムで、CSVのアップロードが必要との事でローカルの開発環境は常に最新の環境にしてるので何気なしに動かしていたのだが
テストしていただいた運用さんから「CSVアップロードしてもちゃんと動いていない」と言う報告が。
プログラム自体はローカルで動いた物をそのまま反映しているので、何だろう。。と考えてみると、環境差異。
ローカル開発環境:PHP7.2
テストサーバー:PHP7.0
まさにこの部分だった。
webty.jp
PHP7.2ではmb_convert_encodingを配列に無意識的にかけていたが、PHP7.0ではこの機能は対応しておらず。
ローカルで動いているからと言う絶対的自信は灯台下暗しとして足元をすくわれる可能性がある。
テストでコンポーネントをアップデートするとその他が動かなくなるので、ステージングサーバーでの確認の依頼と言う事で今回はフィックス。
無意識的に便利と使っている関数も、ちゃんと対応しているか自分で確認が必要だなと反省。