kusanagi– tag –

サイト追加で各種設定を確認していた。kusanagiでキャッシュ用のDBを分けることができると見たことがあり、やってみようかどうか確認してみた。うちのサーバー環境ではあまり効果ないなとおもい、やめました。

他のサーバーのアップデートはくるのに、公開サーバーのが来なくなっていた。さすがにおかしいと思って、手動でDNFかける。競合している。mysql-commonとMariaDB-commonだ。困ったのは、何がmysql-commonをインストールしようとしてるのか。KUSANGIなので、フォーラム除いてもでてこない。こういう時は、ケアレスミス。

サーバーでrootにsuすると、ヘルプメッセージが出るようになった。最近だ。なんかやらかしたかと思って調べる。~/.bashrcが実行されるようだ。そのなかに

サイト移転でしばらく、アクセスログ、エラーログをリアルライム監視していたら、xmlrpc.phpにアクセスが頻発していることが分かった。調べると、そういった攻撃があるらしく、KUSANAGIでもxmlrpc.phpを停止する方法など多数あった。これを停止したら、IFTTTでおこなっている新規投稿通知がエラーーになる。xmlrpc.phpで新規投稿をチェックしているらしい。IFTTTからのソースを許可することにした。

サイトリニューアル後、アクセスログをリアルタイムで監視していたら、xmlrpc.phpへのアクセスが永遠に続いていた。見ると、xmlrpc攻撃というのがあるらしい。kusanagiではwp-loginへのbasic認証も出てきたし、xmlrpc.phpを無効にするようにした。サーバー側で無効にする。

kusanagi9がバージョンアップして、管理画面にログインするにbasic認証がついてきた。このアップを境に混乱する。まず、これまで使っていたサイトは、basic認証なしでログインできる。あたらしいprovisionでサイトを追加した。ここでbasic認証がでてきた。ユーザー名パスワードは設定していない。この場合、htpasswdコマンドでログインできるユーザーを追加しなくてはいけないらしい。はじめて作る時は、-cオプションをつける

しばらくぶりにkusanagiサーバーにサイトを追加しようとした。エラーになる。no mysql root passwordでエラーになる。しらべる。kusanagiフォーラムで１つ見つかるが解決には至らない。 initで初期化する。かわらない。別のエラーがでる　/root/.my.confがみつからないとある。別のkusanagiをみると、/root/.my.confがある中身は

たまに、wwwなしのアドレスと、ｗｗｗありのアドレスが違うことがある。大概はdns管理者がうちでない場合そうなる。このとき、kusanagiコマンドでsslをonにすると、letsencryptにwwwなしでも取得しようとするので失敗する

kusanagiでキャッシュをONにしていた。Contactform7でフォームを運用していた。確認画面、サンクス画面がでるようにしていた。すると、問い合わせがあり。別の方の確認画面がでるという。キャッシュだとおもった。

サイト自体をパスワード保護する必要あったのですが、キャッシュを使うと、これが有効にならないのでした。cookieやwordpressのログインでkusanagiのキャッシュを有効にならないようになっているようだけど、ログインしていない状態でのパスワード保護が効かなくなるようでした。

月次処理でcertをアップをおこなっている。先日、行われた。エラーがでる。生成ファイルのディレクトリが0001になってしまった。もともとのkusanagiが作成する証明書をwebminにも適用したくて、いままでつかっていた更新シェルをつかっていた。これだと、古い認証ファイルになっていてエラーになる。いった、kusanagiの処理にもどし、webminの処理を別にすることにした。

山形県の公立高校の入試日。10日から7日にかわっている。天気はぼちぼち、雪なし。いい天気だ。コバルト柔道をみんな合格してほしい。

アドレス変更があるので、 Search-Replace-DB-master でデータベース内の置換をおこなう The script encountered an error while running an AJAX reques うんぬんのエラーがでる どうも、データが多すぎると、エラーになるようだ

kusanagi+nginxでwordpressをやっている。マルチサイトにする時は、apacheでは.htaccessに記述していたが、nginxではconfファイルに記載するようだ

たまに、wwwなしのアドレスと、ｗｗｗありのアドレスが違うことがある。大概はdns管理者がうちでない場合そうなる。このとき、kusanagiコマンドでsslをonにすると、letsencryptにwwwなしでも取得しようとするので失敗する

kusanagi9がバージョンアップして、管理画面にログインするにbasic認証がついてきた。このアップを境に混乱する。まず、これまで使っていたサイトは、basic認証なしでログインできる。あたらしいprovisionでサイトを追加した。ここでbasic認証がでてきた。ユーザー名パスワードは設定していない。この場合、htpasswdコマンドでログインできるユーザーを追加しなくてはいけないらしい。はじめて作る時は、-cオプションをつける

サーバーの移転作業があり 今回、KUSANAGIをつかうことにした

[KUSANAGI] > [翻訳アクセラレーター] で、「高速化を有効にする」にチェックが入っており、「サイトに表示される翻訳された文章」の設定が、「翻訳を停止」となっているようでしたら、「キャッシュを使用」に変更してみてください。

サイト自体をパスワード保護する必要あったのですが、キャッシュを使うと、これが有効にならないのでした。cookieやwordpressのログインでkusanagiのキャッシュを有効にならないようになっているようだけど、ログインしていない状態でのパスワード保護が効かなくなるようでした。

だいぶ使ってきたんで、満足だし納得していますがkusanagai8が対応終了。kusanagi9への移行がカウントダウンしてきた。

DBの移行、wp-contentの移行、nginxと.htaccessを注意して移行してうまくいった。

wordpressのサイトはKUSANAGIで運用してます。wordpressに特化を売りにしてるので早いんだと思います。体感もはやい。それが最近サーバーからエラーログでてまして、

しばらくぶりにkusanagiサーバーにサイトを追加しようとした。エラーになる。no mysql root passwordでエラーになる。しらべる。kusanagiフォーラムで１つ見つかるが解決には至らない。 initで初期化する。かわらない。別のエラーがでる　/root/.my.confがみつからないとある。別のkusanagiをみると、/root/.my.confがある中身は

サーバー移行の時、まず、移行先でHTTPで動作を確認したのちに、SSLを有効にする。profile作る。この時は、SSLなしでつくる。後からSSLを有効にできるのか。特に細工もせず有効にできたので安心する。