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

投稿

11月, 2018の投稿を表示しています

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も無料で利用できます。 そ...

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 上が対処前で下が対処後の画像。 この時点では目に見えて効果は出ていませんが、長期的には効果があると思いたい所です...

docomoのタブレットを活用してみました(Kindle)

今日は夜勤明けだったので帰りながらドコモショップに寄って機種変してきた。 どうせならXperiaXZ3にしたかったけど、在庫が無かったためXZ2で妥協せざるを得なかった。 あとプラン見直して浮いた金額でタブレット買っていたけど、色々活用出来そうだし、まあ良いかという感想。 — ランタ (@t_ranta) 2018年11月14日 ・・・と言うことで機種変した際に購入したdocomoのタブレット。 タブレットを活かすにはスマホより大きな画面と言うことで、以前から興味があった電子書籍を読んで見ることにしました。 PrimeVideo目的で加入していたAmazonPrimeのお陰で、一部の電子書籍を無料で読むことが出来ます。PrimeReadingというサービスだそうですが、本当に一部です。 ただ興味ある本が何冊かあったので、それらをダウンロードして暇な時に読んでます。 今まで画面が小さいスマホしか使っていませんでしたので電子書籍と縁が無かった事もあり知らなかったのですが、月額約1000円で結構な本が読み放題になるkindle Unlimitedというサービスもあるそうで、そちらも気になってはいます。 ただ月額と見ると少し高めの料金設定なので、躊躇してしまいます。 とりあえずPrimeReadingで読みたい本が無くなったら考える事にします。

windows7サポート終了に際してはLinuxも検討するべきか

ご存知の方も多いでしょうが、windows7のサポート終了まであと1年程度です。 OS にはサポート期限があります! 自分もまだwindows7で、PCの低スペックだったため10には切り替えませんでした。 そして未だにPC買い換える事が出来るか微妙な状況です。 もっとも昨年から今年のにかけての求職期間がまともに響いているわけですが・・・ ただwindows10も未だに不安定な印象で、先月に windowsupdateでファイルを消したり しているので、10に更新していれば万事OKだったかと言えばそういう訳でもなさそうです。 ちなみに以前働いていた会社では、会社PCに入っているマカフィーが消されてしまうため、アップデートするなという通達があったりしました。 もっともMicroSoft的にはWindowsDefenderで十分だから他のセキュリティソフトは不要という認識かも知れませんが・・・ Windows10がXPや7ほどの安定感が無いのであれば、Linuxに切り替えるのも一つの手では無いかと思い、サブのノートPCに国産Linuxディストリビューションである「 LinuxBean 」をインストールし直しました。 ある程度のスペックのPCなら比較的メジャーな Ubuntu とか LinuxMint も良いかも知れません。 LinuxBeanは低スペックでも使えるOSを目指しているそうで、扱いやすい印象なので個人的には気に入っているディストリビューションです。 今回は試験として長期的に使ってみることにしました。 ただ、最初から入っているブラウザのOperaがなんか不便だったので、削除してMidoriに切り替えました。 LinuxBeanデフォルトのデスクトップ画面。(DropBoxはスクリーンショットを移すために自分でインストールしたものです) ターミナルとブラウザ(Midori)を開いた状態。 Midoriは最初から入ってるリポジトリだとバージョンが古かったため、 こちらの記事 を参考にして、最新のバージョンにしました。 Windows7のサポートが切れるまであと1年ほどですが、それまでにLinuxに切り替える事が出来るか色々試して見たいと思っています。

怒りの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...