 |
|
|
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は、一覧表示されたタイムゾーンの名前というかラベルというか。 当然ながら、インスタンスを再起動したら、デフォルトのタイムゾーンに戻ります。
PR |
|
|
|
|
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 |
|
|
普段はあまり使わないコマンド
DBのデータが削除されており、誰が消したか調査 ってか、消すな！ 全てのユーザーの最終ログインを確認
$lastlog [-u ユーザー] [-t n日] まぁ、最終ログインなので、これでは今回求めているものではありません。 直近のログイン履歴を確認
$last [オプション] [ユーザー] [tty...]
-n 行数を指定
$last -n 5 root
とすると、rootでログインした履歴が5件分表示
ユーザ名を変えて、コマンド入力 はい、ありました。 ってか、消すな！
|
|
|
|
|
2018 10,27 00：32 |
|
|
今の現場でデットロックが起きたようで
なんでか、こっちに軽く飛び火 はっきり言って、そういう設計だから、そうなるんだよって話がある 今回起きた原因としては、SELECT FOR UPDATEの部分のようで 詳しくソースを追っていないので、正直原因は分かりません。 ただ、「SELECT FOR UPDATE」という文法を、何も考えずに使うとはまりそうなので 今後のために残す。 （基本、この文法はあまり使わないです、私は） 当然ながら、MyISAMでは利用できない これが、うっかり忘れそう トランザクションの中で利用しないと、SELECT FOR UPDATEをした時に行ロックがかかりません。結果、普通のSELECTと変わらなくなってしまいます。
ちょっと考えれば、当然ですよね。UPDATEするんだもん。 でも、SELECTと記述しているから、トランザクションを忘れることもありそうなので。 一意に取得できないクエリを発行したりすると、ギャップロックやネクストキーロックが発生する（簡単に言うと、特定範囲の行が一気にロックされる）ことがあるようです。 なので、ロックした後は、速やかに情報を更新してコミットする。 SELECT FOR UPDATEをしている時点で、結構更新頻度が高めのテーブルを操作しているはずです。例外発生時などに、きちんとrollback等で後始末をしないと、デッドロックが起こってパフォーマンスが落ちます。
|
|
|
|
|
2018 10,16 22：17 |
|
|
久しぶりに
テーブルの変更を行うにあたり、グループIDごとに採番する必要が出てきたので その方法を調べていました。 既にIDというAUTO INCREMENTでPKのカラムがあるけど、それとは別で採番 参考にさせて頂いたブログ http://www.umikabuto.com/blog/archives/5909 UPDATE target as t1
INNER JOIN
(
SELECT tA.group_id, COUNT(tA.group_id) AS seq, tA.id AS dmyid
FROM target as tA, target as tB
WHERE tA.group_id = tB.group_id AND tA.id >= tB.id
GROUP BY tA.group_id, tA.id
) as t2
ON t1.id = t2.dmyid
SET t1.seq = t2.seq; へぇ～、updateでもjoinできるんだ、初めて知った ってか、使う用途がなかったからなぁ ためになったなぁ
|
|
| 忍者ブログ [PR] |
