2020 12,14 17:03 |
|
結構、はまったので。
開発のAWSでは動作する それをコピーして、本番を作ったのに、本番では動作しない なぜ? まぁとりあえずは、本番の構築が先だったので、その対応を 参考にしたサイト https://qiita.com/ryujimiya2361/items/4b0212e7e3c04124f47d 同じように dllをapache/bin 配下に入れた 入れておくと、動作するやつ
deplister ext/php_curl.dll で依存関係を調べられるって知らなかったなぁ 参考サイトさん、感謝です。 HTTP クライアントである Guzzle は内部で PHP 組み込みの curl を利用しているので、 どうにもこうにもハマった PR |
|
2020 12,14 17:00 |
|
久しく更新していなかったが、書くことは沢山あり。。。
でも時間と風化 とりあえず、覚えていることから。。。 AWS EC2 Windows Server でタイムゾーンを変更する方法 公式にも記載されているが。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/windows-set-time.html コマンドプロンプトで、 tzutil /l と入力し、タイムゾーンの一覧を表示 tzutil /s "Pacific Standard Time" で設定
Pacific Standard Timeは、一覧表示されたタイムゾーンの名前というかラベルというか。 当然ながら、インスタンスを再起動したら、デフォルトのタイムゾーンに戻ります。 |
|
2019 04,04 23:10 |
|
昔、サーバ屋に頼んで設定してもらったfail2ban
postfixのsaslが設定されてないじゃん!! おかけで、こっちに連絡が羽目に。。。 そんなわけで、久しぶりのlinuxで設定 /etc/fail2ban/jail.conf に以下を追加 [sasl-iptables]
ignoreip = 127.0.0.1/8
enabled = true
filter = postfix-sasl
backend = gamin
action = iptables[name=postfix-sasl, port="smtp", protocol=tcp]
sendmail-whois[name=postfix-sasl, dest=root, sender=fail2ban]
logpath = /var/log/maillog
maxretry = 5
findtime = 600
bantime = 1209600 そんでもって vi /etc/fail2ban/filter.d/postfix-sasl.conf に新規ファイルを作成 内容は以下の通り [Definition]
_daemon = postfix/smtpd
#failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$
# フィルタールール
failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w
# 正規表現を無視する記述
ignoreregex =
と保存し、fail2ban をrestart 久しぶり過ぎて、reloadの方法を忘れてしまったので。。。 ログを見てみると fail2ban.actions: WARNING [sasl-iptables] Ban XXX.XXX.XXX.XXX うん、ちゃんとBanしてくれてる ローカルホストは、Banはされてみたいだから、OKかな? |
|
2019 02,18 22:14 |
|
2018 10,27 00:32 |
|
今の現場でデットロックが起きたようで
なんでか、こっちに軽く飛び火 はっきり言って、そういう設計だから、そうなるんだよって話がある 今回起きた原因としては、SELECT FOR UPDATEの部分のようで 詳しくソースを追っていないので、正直原因は分かりません。 ただ、「SELECT FOR UPDATE」という文法を、何も考えずに使うとはまりそうなので 今後のために残す。 (基本、この文法はあまり使わないです、私は) 当然ながら、MyISAMでは利用できない これが、うっかり忘れそう トランザクションの中で利用しないと、SELECT FOR UPDATEをした時に行ロックがかかりません。結果、普通のSELECTと変わらなくなってしまいます。
ちょっと考えれば、当然ですよね。UPDATEするんだもん。 でも、SELECTと記述しているから、トランザクションを忘れることもありそうなので。 一意に取得できないクエリを発行したりすると、ギャップロックやネクストキーロックが発生する(簡単に言うと、特定範囲の行が一気にロックされる)ことがあるようです。 なので、ロックした後は、速やかに情報を更新してコミットする。 SELECT FOR UPDATEをしている時点で、結構更新頻度が高めのテーブルを操作しているはずです。例外発生時などに、きちんとrollback等で後始末をしないと、デッドロックが起こってパフォーマンスが落ちます。 |
|
忍者ブログ [PR] |