スキップしてメイン コンテンツに移動

投稿

ラベル(WordPress)が付いた投稿を表示しています

Cosense(旧scrapbox)による情報整理

(この記事は2018/11/16の記事をリライトしたものです) ## 経緯など 自分は以前から、オンライン上のメモアプリとしてEvernoteとGoogle Keepを中心に使っていました。 もともとEvernoteがメインで、Google Keepは簡単なメモを残す程度の使い方という形で使い分けていました。 Evernoteは多機能で便利な一方、テキストを中心に気軽に情報を蓄積していく用途では、少々大掛かりに感じることもありました。 以前は自宅サーバーに個人的なWikiを置いて色々書き込んでいましたが、自宅サーバーを廃止したこともあり、クラウド上でWikiのようにテキストを蓄積できるサービスを探していました。 いくつか候補があった中で使い始めたのが、当時「Scrapbox」という名称だったサービスです。 Scrapboxは2024年5月にサービス名を変更し、現在は**Cosense(コセンス)**となっています。 この記事を最初に書いた2018年からかなり時間が経ち、名称だけでなく一部の機能や仕様も変わっているため、現在の内容に合わせて書き直してみます。 ## 機能や特徴など Cosenseは、クラウド上にページを作り、それぞれのページをリンクで結びつけながら情報を蓄積していくサービスです。 一般的なメモアプリのようにフォルダ分けして整理するというよりも、関連するページ同士をリンクさせることで情報をつなげていくところに特徴があります。 ### Projectについて Cosenseでは、**Project**という単位の中にページを作成していきます。 Evernoteで言えばノートブック、Wikiで言えば一つのWikiサイトに近いものと考えると分かりやすいでしょうか。 Projectには公開設定の**Public Project**と、非公開の**Private Project**があります。 Public ProjectはURLを知っていればログインしていない人でも閲覧できますが、編集できるのはProjectのメンバーだけです。 一方、Private ProjectはProjectのメンバーだけが閲覧・編集できます。 個人利用や趣味のグループ、勉強会などではPrivate Projectも無料で利用できます。 そ...

WordPress5.0に更新したらエラーが出たので対処

WordPressがメジャーアップデートしてバージョン5.0になりました。 現在管理しているサイトは全てWordPressで作ってますので、それらも随時更新して行きます。 ただ大した事ではありませんが、場合によっては記事投稿する際にエラーが発生する場合がありますので、その対応についてです。 このサイトのWordPressをアップデートした後、記事投稿画面を確認しようとしたら下記のようなエラー画面になりました。 慌てて他の画面を確認しましたが、問題なし。 どうやら記事投稿画面のみのようです。 ふと思い当たって、プラグイン画面を確認しましたが、「Gutenberg」や「Classic Editor」と言ったエディタプラグインがインストールされていない事に気づきました。 「Classic Editor」はインストールしていたつもりでしたが、忘れていたようです。 (ちなみに日記ブログは予め「Classic Editor」をインストールしていたためエラーは発生しませんでした) 肝心の「Gutenberg」は確か強制的にインストールされていたはずですが、アップデートの際に削除された模様です。 とりあえず「Classic Editor」をインストールして、問題なく記事投稿出来るようになりました。

wordpressのwp-cronを止めて負荷を軽減する

タイトルの通りです。 ここしばらく外部からのアタックという負荷要因と格闘してましたが、今回は内部からの負荷要因への対応です。 wordpressにはwp-cron(代替cron)と呼ばれる機能があり、予約投稿などが無いかチェックしているのだそうです。 しかしブログにアクセスがあったりする度に、wp-cronが起動するため、結構な負荷となりアクセスログでもwp-cronによるログが結構な割合を占めます。 負荷軽減という視点からすると、これは放って置けないため、 こちらの記事 を参考にして止める事にしました。 サーバにログインして、wp-config.phpファイルを編集します。 sudo vi /var/www/wordpress/wp-config.php そして先頭に以下の行を追加してwp-cronを止めます。 define('DISABLE_WP_CRON', 'true'); それからwhichコマンドでphpのパスを確認し、それを元にcronを設定します。 which php sudo su -vi /etc/crontab そしてcrontabの記載内容は以下の通りです。 # Example of job definition:# .---------------- minute (0 - 59)# | .------------- hour (0 - 23)# | | .---------- day of month (1 - 31)# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat# | | | | |# * * * * * user-name command to be executed * * * * * apache /bin/php /var/www/wordpress/wp-cron.php > /dev/null 2>&1 上が対処前で下が対処後の画像。 この時点では目に見えて効果は出ていませんが、長期的には効果があると思いたい所です...

怒りのiThemes Security導入

前回の記事を投稿し、確認しようとした所ブログが非常に重い・・・ 取り急ぎサーバにログインし、topコマンドを叩いて見ます。 これはちょっと酷いですね・・・ とりあえずApacheを再起動します。 systemctl restart httpd そしてアクセスログを確認します。 [11/Nov/2018:16:54:50 +0900] "GET /help.php HTTP/1.1" 404 19288 "-" [11/Nov/2018:16:54:53 +0900] "GET /java.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:54:59 +0900] "GET /_query.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:01 +0900] "GET /test.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:02 +0900] "GET /db_cts.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:06 +0900] "GET /db_pma.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:08 +0900] "GET /logon.php HTTP/1.1" 404 19288 "-" [11/Nov/2018:16:55:14 +0900] "GET /help-e.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:19 +0900] "GET /license.php HTTP/1.1" 404 21021 "-" [11/Nov/2018:16:55:23 +0900] "GET /log.php HTTP/1.1...

Table of Contents Plusとeasy table of contentsを試した感想

主に日記ブログにて、ユーザビリティ向上の一環として目次を表示する事にして、現在作業中です。あちらは総記事800を超えているとは言え、目次を入れる程の分量の記事は多く無いはずです。 とは言え仮に半分程度だったとしても、400記事程度にはなりそうなので作業量としては結構な物になりそうです。 この作業はプラグインを使っていますが、結果的に二つのプラグインを使う事になり、その使用感に多少の違いがあったため、比較してみます。 目次設定 見出しタグ(hタグ)で囲んだ文章を目次に表示する。 入れ子構造に出来る。 h1~h6までのタグをどこまで目次に表示するか設定出来る。 上記の点はどちらも共通です。 しかし決定的な違いとして Table of Contents Plus ツール設定で見出しの階層や最低見出し数を設定する。 easy table of contents 記事ごとに階層や最低見出し数を設定する。 後者は記事毎に細かく設定出来るのが特徴ですが、後から導入すると作業量が増えるので記事が多いサイトに導入するのは不向きと言えます。 外見設定 Table of Contents Plusの場合はいくつかあるパターンから選択する形になります。 easy table of contentsはの場合はパーツごとに細かく色を設定できますが、設定画面で表示の確認をすることは出来ません。 easy table of contentsは細かい設定が出来る代わりに分かり難く、Table of Contents Plusは扱いやすい代わりに細かい設定は出来ません。 総合的感想 いろんな意味で細かく設定したいのならeasy table of contents。それ以外ならTable of Contents Plusが扱いやすいと思われます。 ただTable of Contents Plusはこの記事を書いている時点では、長い間更新されていないのが、気掛かりではあります。現状最新版wordpressでも問題なく使用出来ているように見えますし、更新の必要性は無いということなのかも知れません。 あと、Table of Contents Plusはサイトマップ機能もあるようです。 そういう訳で、記事数が多い日記ブログはTable of Contents Plusを使ってます。こちらのブログは現在のところ比...

SiteGuard WP Pluginでwp-login.phpを変更する

先の記事でアタックを受けているphpファイルを集計した結果、圧倒的多数でwp-login.phpが最多でした。 このファイルはwordpressのログイン画面なので、もっとも狙われ易いと言うのも当然の事と言えます。 こちらも当然、ログイン認証には複数の対策を講じてますので、そう破られるものではありません。 しかし相手がbotで、いくら認証エラー出ようが構わず、ロックされようがロック時間が過ぎると再度と延々とアタックされると負荷になるわけです。 負荷を軽減させる為には、botやアタッカーにログイン画面まで到達させては行けないのではと考えて調べた所、ログイン画面のアドレスを変更出来るプラグインがある事を知りました。 それが今回導入した「 SiteGuard WP Plugin 」です。 これならログイン画面からアタックされる事自体大部分少なくなるかも知れません。 そういう訳で管理画面からインストールしました。 そして有効化した途端、500エラーで弾かれてしまいました。サイト自体アクセス不能な状態に。 仕方無くサーバにログインしてプラグインを削除してもエラーは解消せず。 そこでエラーログを確認したところ、wordpressフォルダにある.htaccessファイルが原因と分かったのファイルをで開くと、プラグインによって追記されたらしく内容がゴチャゴチャになってました。 そこで一旦.htaccessファイルの記述を戻す事で、エラーは解消しました。 どうやらこのプラグインは有効化すると独自で.htaccessファイルを作成する模様です。 それならばと自分で書いた.htaccessファイルを一旦別名にしてからプラグインをインストール、有効化した後に新しい.htaccessに元からあった自分の.htaccessファイルの内容を追記することで無事導入出来ました。 プラグインの管理画面から「ログインページ変更」をクリックして移動し、wp-login.phpファイルの新しい名前を設定します。 実際の所はwp-login.phpファイルへ直接のアクセスを制限し、指定した名前からリダイレクトしているようです。 ログイン画面をブックマークとかしていたなら、当然使えなくなりますし、新しい名前を忘れるとログイン出来なくなりますので、探られにくく覚えやすい名前が良いでしょう。 SiteGuard W...

wordpressでのアタック対象phpファイルを集計する

先の記事でも書きましたが、当ブログが載っているVPSにbotらしきアタックが頻繁に来て負荷を掛けているので、対策を講じなくてはいけません。 アクセスログを見て、すぐにそれと分かるファイルは取り急ぎ対策しました。 しかし他にもアタックを受けているファイルがあり、アクセスログを精査していられない為ログを解析する方法を調べた所、 こちらのサイト で紹介していた方法を用いる事にしました。(ApacheLogViewerで集計する方法の詳細はこちらのページに丸投げさせて頂きます) ただこのブログは普通のレンタルサーバではなく、VPSを利用している事もあり、現在の所アクセスログを簡単にダウンロードする仕組みはありません。 そこでサーバにログインし、アクセスログをユーザディレクトリにまとめて出力します。 #cat /var/log/httpd/access_log* > /home/xxxxxx/access_log そしてWinSCPでダウンロードすればログの準備は完了です。 続いて ApacheLogViewer の準備です。こちらはダウンロードして展開すると、インストーラーではなくexeファイルがあります。 手軽に使えるのが良いですね。 ApacheLogViewerを立ち上げ、ダウンロードしたアクセスログを読み込ませます。 それから「Setting」からphpファイルに絞ってフィルタを掛け、集計しました。 これでアタックを受けているファイルが分かりましたので、対策していきます。

Wordpressのセキュリティ対策について

これまで行ったWordpressへの不正アクセスなどへの対策をまとめて見ます。 1.ユーザー変更 言うまでもありませんが、初期管理ユーザーのadminはまず危険なので削除して新たに管理者ユーザーを変更します。 しかしその後の管理者ユーザーも安全とは言い難い状況となったので変更しています。(投稿の表示がユーザー名だったため) ユーザー名は変更出来ないので流れとしては 新ユーザー作成→新ユーザーを管理者に→新ユーザーでログイン 新ユーザーでログインした後で旧ユーザーを削除しますが、一応ユーザーを削除する際に「すべてのコンテンツを以下のユーザーのものにする」にチェックを入れる事で投稿が削除されないようにする事も可能ですが、自分のようにユーザー削除前に「投稿一覧」から変更しても構いません。 そしてくれぐれも 投稿の表示をユーザー名にしない ようにしましょう。 参考 普段は変更できないWordPressのユーザー名を変更する方法 2.ユーザー名と別のニックネームを設定する 上にも書きましたが、せっかくユーザーを作ってもそのユーザー名で投稿してはセキュリティ面でのリスクが出てきます。 それを防ぐためにプロフィールからニックネーム、表示名の設定をしておきます。 参考 投稿記事から「(ログイン)ユーザー名」がバレるのを防ぐ 3.プラグインによりセキュリティ強化 WordPressの豊富なプラグインにはセキュリティ対策に役立つものも多数あります。 以前の記事 で紹介したLimit Login Attemptsもその1つです。 そして他に導入しているプラグインとしてはStealth Login Pageがあります。 これはログイン画面にもう1つパスワードを設けると言う物でセキュリティ強化に役立ちます。 参考  Stealth Login Page – ログイン画面に2つ目のパスワードを追加できるWordPressプラグイン 他にもありますが、詳しいことが分かったら報告するかも知れません。

テーマ変更

最近サーバが若干重く、前回投稿直後にMemoryFreeが15%切る有り様だったのでキャッシュを削除しました。 そして久々にこのブログのテーマ(外観)を変更しました。 機能的にはだいたい同じで見た目はすっきりした印象です。  

Limit Login Attemptsからのメール

Limit Login Attemptsプラグインからの物と思われるメールが来ていました。 9 failed login attempts (3 lockout(s)) from IP: ○○.×××.○○.×××Last user attempted: adminIP was blocked for 24 hours adminというありがちなユーザー名にログイン出来ず。3回ミスでロック、3回ロックでメール送信と設定しているので、9回ロックされたと言う事なのでしょう。 ○○.×××.○○.××× – – [21/Aug/2012:02:56:00 +0900] “POST /wordpress/wp-login.php HTTP/1.1” 200 3408 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.2) Gecko/20100115 MRA 5.6 (build 03278) Firefox/3.6 (.NET CLR 3.5.30729)” アクセスログにはこんな感じなのが多数ありました。 そこでロック解除までの時間を少し長く設定しました。 その時気付いたのですが、Limit Login Attemptsの設定画面に一度でもロックされた実績が記録されるようです。 それによると思ったより攻撃を受けているようです。

プラグイン一括更新で画面が真っ白に

忙しくて長い間メンテナンスが出来ていませんでしたが、先日WordPressにログインしてプラグインを4つほど一括更新しました。

phpmyadminへのアタック(その2)

最近「phpmyadmin アタック」などで訪れる方が結構いるので、気になって調べたら前回と異なるアタックがあることを知り、昨日ログを見てみたところ案の定というか当日アタックした形跡がありました。

Tweetableプラグインエラー

ブログサイドバーに設置しているTweetableプラグインによるつぶやき表示がエラーになってました。 どうやらTwitterでエラーが発生するとプラグインで読み込みし直さない模様。 地震直後表示されにくかったからそのせいかも知れません。 ちなみにプラグインは一度停止して再度有効化したら問題なく表示されました。

WordPressのWP Super Cacheプラグインインストール

WordPressのWP Super Cacheプラグインをインストールしてみました。 このプラグインは動的ページであるWordPressに静的ページなキャッシュを作ることでページへのアクセスに伴う負荷を軽減させるというものだそうです。 このサイト自体アクセスは少ないですが、何せサーバのリソースが充分とは言えないので、入れてみたほうが良いだろうと判断。

WordPressとTwitterの連携

このWordPressサイトにはTweetableというプラグインをインストールしており、Twitterと上手く連携出来るはずだったのですが、何故か記事投稿した際にリンクが貼られていませんでした。 そこで調べたところ、Tweetableの設定で選択するURL短縮ツールをBit.lyにしたのが原因だった模様です。 Bit.lyを選択した場合はBit.lyに実際に登録し、ユーザー名とBit.lyAPIを入力しなくてはならないようです。 Bit.ly自体便利そうだったので登録してみました。ちなみにAPIはユーザー名→Settingsで見ることが出来ます。 そしてTwitterからこの記事へリンクが貼られていれば連携は成功と言うことになります。 [ad#ad_footer]

自宅サーバへWordPressをインストールした

という訳でその時のメモ。 まずはMySQLにWordPress用のDBとユーザーを作成 # mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 634 Server version: 5.0.77 Source distribution Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer. mysql> create database wordpress; Query OK, 1 row affected (0.12 sec) mysql> grant all privileges on wordpress.* to wordpress@localhost identified by ” ‘パスワード’; Query OK, 0 rows affected (0.08 sec) mysql> quit Bye