AWS EC2でタイムゾーンがUTCに戻る場合の対応 | ことえりブログ
タイムゾーンって/usr/share/zoneinfo/Asia/Tokyoを/etc/localtimeにコピーするなりシンボリックリンクを貼るなりすると思うんですけど、EC2の場合はyum updateのタイミングでUTCに戻ってしまう場合があります。ありました ということで、/etc/sysconfig/clockを書き換えましょう。 /etc/sysconfig/clockは、ハードウェアクロックから読み込んだ値を制御するそうです。 http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-ja-4/ch-sysconfig.html /etc/sysconfig/clockの内容は ZONE=”UTC” UTC=true となってると思います。それを ZONE=”Asia/Tokyo” UTC=false と書き換えましょう。 私の場合は今の
glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば
RHEL, CentOS, Amazon Linux (6以前) /etc/localtime を /usr/share/zoneinfo 以下から上書きしたりシンボリックリンク張ったりという手法が横行していますが、 /etc/localtime は glibc パッケージに含まれるためパッケージを更新すると上書きされてESTとかに戻ってしまうわけです。 当然ながら、ディストリビューションとして正しい設定方法が用意されているので、こちらを使います。 /etc/sysconfig/clock にタイムゾーンを書きます。*1sudo sed -i -e "s/^ZONE/#ZONE/g" -e "1i ZONE=\"Asia/Tokyo\"" /etc/sysconfig/clock tzdata-update を実行します。sudo /usr/sbin/tzdata-update これだけで
GHOST 脆弱性は如何様に使うのか | Webシステム開発／教育ソリューションのタイムインターメディア
先日 GHOST と呼ばれる glibc の脆弱性が発表された。なんでも、「リモートから任意のコードを実行できる可能性がある」らしいではないか。しかも様々なプログラムで利用されているライブラリ部分の問題とあって、影響範囲がとても広い。なかなか厄介なことである。 はて、しかし一体全体どうやってリモートから任意のコードを実行しようというのだろう？ 話を聞くに、たかが数バイトの情報を範囲外のメモリに書き込める可能性があるだけだという。実際それだけのことでサーバーの乗っ取りなどできるものなのだろうか。そんなわけで、その疑問に答えるべく、本記事では以下の URL で解説されている実際の攻撃方法を若干端折って紹介してみようと思う。 http://www.openwall.com/lists/oss-security/2015/01/27/9 なお、本記事はこの脆弱性そのものに対する緊急度などについて言
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
