①anacondaの画面フロー変更。 ②GUIでのパッケージ選択を廃止 ③6.5➡7へのupgradeをサポート CentOS6.5➡7にupdateするには下記 CentOS6.5 ➡ Centos7にアップグレード eth0などはそのまま引き継がれる。 サービスは停止するもの(例えばntpなど)があったり、 6.5で動いてたものが正常に動作しなくなる可能性があるので、upgradeは推奨はしません。
①anacondaの画面フロー変更。 ②GUIでのパッケージ選択を廃止 ③6.5➡7へのupgradeをサポート CentOS6.5➡7にupdateするには下記 CentOS6.5 ➡ Centos7にアップグレード eth0などはそのまま引き継がれる。 サービスは停止するもの(例えばntpなど)があったり、 6.5で動いてたものが正常に動作しなくなる可能性があるので、upgradeは推奨はしません。
こういったインフラ周りは日頃触らず忘れやすいので、自分の備忘録としてまとめておきます。 環境はAmazon EC2です。 CentOS6.xと7の主な変更点 「service」コマンドと「chkconfig」コマンドが、「systemctl」コマンドに統合 「iptables」が「firewalld」に変更 「ntpd」が「chronyd」に変更 「ifconfig」が「ip」コマンドに変更 ユーザーを「centos」から「root」に切り替える方法 CentOS7の場合、初期ユーザが「centos」でした。 「root」になるには新しくパスワードを作成する必要があるようです。 Apachのインストール 「service」コマンドは「systemctl」コマンドに変わったので、以下になります。 chkconfig -listの代わりに 以下のコマンドで、自動起動設定を一覧で確認出来ます。
最近またAnsibleでAWSの構成を書き始めました。 selectattrとmapが便利 次のような値を with_items で回してサブネットを作るとともに、publicなものを取り出してルートテーブルを作りたくなったのですが、selectattr()とmap()を使うと取り出すことができました。 --- vpc_subnets: - { name: bastion, az: ap-northeast-1a, cidr: 10.0.1.0/28, tier: bastion, public: true } - { name: web1a, az: ap-northeast-1a, cidr: 10.0.10.0/24, tier: web, public: true } - { name: web1c, az: ap-northeast-1c, cidr: 10.0.11.0/24,
MySQLの標準ストレージエンジンは、MyISAMです。 これを InnoDBに変更するとMTの再構築が速くなった事例があるそうです。 ネタ元はこちら。 [N] ネタフルのMT再構築が劇的に速くなったレシピはコレ! ということで今回、奏効したレシピはこんな感じです。 ・ストレージエンジンをMyISAMからInnoDBに変更する ・InnoDBのバッファプールのキャッシュ率を高めるようにmy.cnfの設定 (innodb_buffer_pool_size) を変更する 「ストレージエンジンをMyISAMからInnoDBに変更」したのが大きいみたいですね。 ストレージエンジンというのは、データへのアクセスを制御するところのようで、これを変更してキャッシュをチューニングしたところ、それまで7時間以上かかっていた個別エントリーの再構築が‥‥ 30分になっちゃったんです!!! サイト全体でも約1時間
負荷的に厳しくなってきたので sakuratan.biz を Apache(さくらスタンダード)から nginx(さくら VPS 512)に移転しました。 頻発していた 503 もほとんど出なくなって快適です。 Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたので、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。 結構長文になってしまいましたので、先に索引を載せときます。 nginx とは nginx が速い理由 リバースプロクシ さくら VPS にインストールするシステム構成 EPEL パッケージリポジトリのインストール MySQL のインストール PHP のインストール nginx のインストール nginx と PHP FastC
さくらのVPS v3 2Gプランを借りたので、最初にやったことをメモ。 環境確認 契約後メールで送られてきたパスワードでログイン。まずはrootパスワード変更。 $ passwd 3コア。 $ cat /proc/cpuinfo | grep "model name" model name : Intel(R) Xeon(R) CPU E5645 model name : Intel(R) Xeon(R) CPU E5645 model name : Intel(R) Xeon(R) CPU E5645 メモリ2GB。 $ cat /proc/meminfo | grep Mem MemTotal: 2054804 kB MemFree: 1482476 kB $ free -m total used free shared buffers cached Mem: 2006 558 144
MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視サーバ構築編) 2012-05-18 MySQLをリソース監視する仕組みにはいくつかあるが、対象のMySQLサーバが5台以上ある場合はCactiがおすすめ。導入のしやすさだけでMuninを選ぶ人が多い気がするが、その選択基準は間違っている! Cactiのいいとこわるいとこ 多数のグラフを見やすく並べられる muninと比べて多数のサーバから軽快に情報を収集・表示できる 監視対象には、MySQLのユーザを追加するだけでかなりの項目数を監視できる データの保存にデータベースが必須だったりしてセットアップがやや面倒 慣れるまで監視プラグインを書くのに手間取る Muninのいいとこわるいとこ 監視プラグインを書くのが簡単 監視サーバにデータベースなどが必要なく、セットアップが簡単 グラフの並び方などが
はじめに Linux のセキュリティ設定ってなかなかまとまったものがないので、いろんなサイトを参考にしながら設定をまとめてみました。想定はWeb サーバーで、使用している Linux は CentOS 6.2 です。 設定内容は以下のようになります。 全パッケージのアップデート リモートからの root ログインを無効にする 公開鍵暗号方式を使用した SSH ログイン設定 iptables 設定 SSH ポート番号の変更 不要なサービスを停止 ログ監視設定 ファイル改ざん検知ツール設定 ウィルス対策ソフト設定 Apache の設定 全パッケージのアップデート 最初に以下のコマンドを実行して、全パッケージを最新の状態にする。 # yum –y update 後は脆弱性が発見された時、または定期的にパッケージのアップデートを行う。 リモートからの root ログインを無効にする リモートからメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く