はてなブックマーク

ClamAVのバージョン0.98.7がepelリポジトリで利用可能になった。rpmforgeのClamAVが0.98.4からなかなかアップデートされないので、epelのClamAV 0.98.7に入れ替えることにした。（4月29日にバージョン0.98.6のインストールとして書いたが、5月9日に0.98.7になったので、ClamAV 0.98.7 インストールに修正） インストールされてるclamをアンインストール [root@server2 ~]# yum -y remove clam* 設定ファイルを削除 [root@server2 ~]# rm /etc/cron.daily/clamdscan [root@server2 ~]# rm /etc/tmpfiles.d/clamd.conf yumのリポジトリ確認 [root@server2 ~]# cd /etc/yum.repos.

CentOS 7ではsystemdが導入され、サービスの管理が従来と大きく変わっている。 サービスの起動、終了など 起動 　　　　　　　　　　 systemctl start 終了 　　　 　　　　　　　systemctl stop 強制終了 　　 　　　　　　systemctl kill -s 9 再起動 　　　　 　　　　　systemctl restart 設定反映 　　　　 　　　　systemctl reload 状態表示 　　　　　 　　　systemctl status 自動起動の有効化 　　 　　systemctl enable 自動起動の無効化 　　　 　systemctl disable 自動起動の状態表示 　　　 systemctl is-enabled サービス一覧の表示 　　　 systemctl --type service 起動失敗のユニット表示　　syste

2015年1月4日修正 clamscanでスキャンすると時間が結構かかってたので、より高速に動作するclamdscanでウイルススキャンするように変更。また、除外ディレクトリーも新たに設定。 ※clamdscanはスキャンして、変更の無いファイルは2度目以降のスキャンをスキップするので高速である。 ■Clam AntiVirusをRepoforgeリポジトリからインストール yumでインストールする場合、Repoforgeリポジトリを追加しておく必要がある [root@server1 ~]# yum -y install clamd 読み込んだプラグイン:fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * base: ftp.nara.wide.ad.jp * centosplu

新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。 ■ということで /etc/default/grub を編集 [root@server2 ~]# vi /e

新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。 ■ということで /etc/default/grub を編集 [root@server2 ~]# vi /e

新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。 ■ということで /etc/default/grub を編集 [root@server2 ~]# vi /e

新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。 ■ということで /etc/default/grub を編集 [root@server2 ~]# vi /e

今使ってるスクリプトでDDNSの自動更新がうまくいかないこともあり、たびたびアクセスできなくなることがあったので、自動更新のスクリプトを見直すことにした。この自宅サーバはddo.jpのDDNSを使ってるので、いろいろ調べて見たら、こちらのサイトで紹介されてるスクリプトが良さそうなので使わせてもらうことにした。 自動更新の動きとしては (1)ddo.jpサイトで用意しているリモートIP確認サイトで現在のIPを確認。 (2)前回更新時のIPと変更時間をテンポラリーファイルから読み込む。 (3)前回更新時とIP同じで、かつ前回更新時から2週間以上経ってなかったら終了。 (4)そうでなかったら、DDNSを更新。変更内容をテンポラリーファイルとログに書き込む。 という感じで自動更新されるとのことなので、<2週間以上経ってなかったら終了>の所を1週間に変更して使うことにした。 あとこのスクリプトは、l

新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。 ■ということで /etc/default/grub を編集 [root@server2 ~]# vi /e

今使ってるスクリプトでDDNSの自動更新がうまくいかないこともあり、たびたびアクセスできなくなることがあったので、自動更新のスクリプトを見直すことにした。この自宅サーバはddo.jpのDDNSを使ってるので、いろいろ調べて見たら、こちらのサイトで紹介されてるスクリプトが良さそうなので使わせてもらうことにした。 自動更新の動きとしては (1)ddo.jpサイトで用意しているリモートIP確認サイトで現在のIPを確認。 (2)前回更新時のIPと変更時間をテンポラリーファイルから読み込む。 (3)前回更新時とIP同じで、かつ前回更新時から2週間以上経ってなかったら終了。 (4)そうでなかったら、DDNSを更新。変更内容をテンポラリーファイルとログに書き込む。 という感じで自動更新されるとのことなので、<2週間以上経ってなかったら終了>の所を1週間に変更して使うことにした。 あとこのスクリプトは、l