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

投稿

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

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

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に切り替える事が出来るか色々試して見たいと思っています。

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

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

tail -fより監視向きのless +Fコマンド

最近ブログが遅いと思って、早くなるようにリソース割いたら遅い原因がbotか何かよるアタックに起因する負荷によるものでした。 そのため、apacheにリソース割いたのが裏目に出て、out of memory発生でmysqlを落とされる有り様でした。 その後は当然リソースを絞り、現状はアタック対策で負荷軽減を目指しています。 そういう訳で、アタックに対抗する方法を色々調べていましたが、記事タイトルにある、less +Fコマンドもその流れで知りました。 このlessコマンドはcat、more、viewなどと同様にファイルの内容を表示するコマンドで、一画面分ずつ表示するという意味で単にmoreの上位互換というイメージでした。 もっとも現場ではシンプルだからかmoreの方が使われてましたが。 例えばgrepした結果をパイプでmoreに放り込んで表示とか。 そしてログのリアルタイム監視をする場合、現場ではファイルの末尾を表示するtailコマンドに、追記があれば更新される-fオプションが使われる事が多かったですね。 一方のlessコマンドでも、リアルタイム監視が出来る+Fオプションがあるそうなので試してみました。 $less +F filename このless +Fはctrl+cで通常モードとなり、ファイル内の検索などが行えます。 そしてF(つまりshift+f)で監視モードに戻り中断していた分も含めて追記されます。 tail -fだと一旦ctrl+cでコマンドを終了しないと検索などが出来ないこともあり、監視を途切れさせないと言う点で優れています。 また、複数ファイル同時表示も可能で、大分前にMultiTailというツールを紹介しましたが、別途ツールを入れなくても複数ファイル同時監視が出来るようになっていたようです。 これから監視を行う必要がある時は積極的に使っていきたいコマンドと言えます。 参考 ソフトアンテナブログ

bashの脆弱性Shell Shockをチェック

bashの脆弱性「Shell Shock」。 関連リンク: bashの脆弱性(CVE-2014-6271) #ShellShock の関連リンクをまとめてみた これに関する対応が必要かどうかチェックしてみました。 参考にしたのは、 bash の脆弱性 “Shell Shock” のめっちゃ細かい話 (CVE-2014-6271)  こちらの記事にあるコマンド  $ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” 上記のコマンドを実行し vulnerable this is a test 上記のような結果が表示されれば脆弱性ありと言うことです。 そして実行結果ですが # env =() { :;}; echo vulnerable bash echo this is a test -bash: syntax error near unexpected token `(‘ エラーでコマンドを実行出来ませんでした。 どうやらこちらで使用している環境のbashには脆弱性は無かった模様です。

ownCloud更新

昨年に何気なくインストールしたownCloudを更新しました。 作業に当っては こちらのブログ記事 を参考にしました。 まずはowncloudフォルダと別にバックアップ用フォルダを作り、そこにconfig、dataフォルダをコピーします。 #cp -r owncloud/config own_bk/config # cp -r owncloud/data own_bk/dat そしてowncloudのファイルをダウンロードして解凍。 # wget http://mirrors.owncloud.org/releases/owncloud-4.5.5.tar.bz2 2 –2013-03-17 03:26:34–  http://mirrors.owncloud.org/releases/owncloud-4.5.5.tar.bz2 mirrors.owncloud.org をDNSに問いあわせています… 50.30.42.17 mirrors.owncloud.org|50.30.42.17|:80 に接続しています… 接続しました。 HTTP による接続要求を送信しました、応答を待っています… 200 OK 長さ: 9168561 (8.7M) [application/x-bzip] `owncloud-4.5.5.tar.bz2′ に保存中 0% [                                                 ] 0           –.-K/s 1% [                                                 ] 160,918      183K/s 100%[================================================>] 9,168,561   2.12M/s 時間 5.4s 2013-03-17 03:26:40 (1.63 MB/s) – `owncloud-4.5.5.tar.bz2′ へ保存完了 [9168561/9168561] # tar -xjf owncloud-4.5.5.tar.bz2 実は先に4.5.7...

MySQLのトラブル

昨日、このブログにログインしようとした所500エラーが出て入れない状況となっていました。

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

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

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

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

phpmyadminへのアタック

昨日phpmyadminへのアタックを確認しました。

UnixBenchを使ってみた

サーバで使用しているUnix系OSの性能を測定するツールであるUnixBenchを使ってみました。

MultiTailインストール

Linuxのログ監視に便利そうなツールをインストールしたので、その時のメモを。 MultiTailはtail -fと同じように追記されるログファイルをリアルタイムで監視できるツールです。 tailコマンドとの違いは複数のファイルを同時に監視できること。 という訳でインストールしてみました。

MeCabを使用できるようにした

そう言えば以前インストールしたMeCabを使ってみようと思ってみたところ # mecab tagger.cpp(138) [load_dictionary_resource(param)] param.cpp(71) [ifs] no such file or directory: /usr/lib/mecab/dic/ipadic/dicrc 上記のメッセージが出ました。 調べてみたところ、どうやら辞書ファイルが存在しない模様。 そういう訳で辞書ファイルをインストールすることに。 MeCabのインストールなどは こちら を参考に。

Apacheによるメモリー負荷増大

nagiosがMemoryFree15%ほどと言うアラートが出ていたので確認。 # vmstat procs ———–memory———- —swap– —–io—- –system– —–cpu—— r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 404752 8112 18464 49092 0 0 32 14 0 1 7 10 82 1 0 まずはキャッシュを解放してみる。 # echo 1 > /proc/sys/vm/drop_caches # vmstat procs ———–memory———- —swap– —–io—- –system– —–cpu—— r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 404752 56188 136 18896 0 0 32 14 0 1 7 10 82 1 0 いくらか良くなったが解決には至らず。 色々調べつつtopで見たところ。  load average: 0.02, 0.03, 0.00 Tasks: 212 total, 1 running, 211 sleeping, 0 stopped, 0 zombie Cpu(s): 6.8%us, 9.9%sy, 0.2%ni, 82.2%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 506808k total, 458820k used, 47988k free, 1312k buffers Swap: 1015800k total, 404584k used, 611216k free, 25564k cached>

clamscanが停止しない場合の対処

数ヶ月前からウイルス対策ソフトのclamavがスキャン後も停止しないというトラブルに見舞われていました。 放置するとclamscanのプロセスがいくつも上がったままになり負荷が非常に大きいです。 そこで何も対処しないと日々プロセスを手動で落とすことになります。 毎日のようにプロセスを落としながら様子を見ているうちに、今月にclamavがアップデートされましたが、この不具合は収まらず・・・ そこでこちらで対処をすることにしました。 情報によれば/sys をscanから外すとちゃんと停止するようです。 自分はclamavはcronで設定していたのでそれに追記することにしました。 0 3 * * * clamscan –exclude=/sys/ –infected –remove –recursive >> /root/hoge.log 斜め部分が追記箇所。 とりあえずこれで収まりました。 [ad#ad_footer]

yumが動作しなかった

久々にサーバー内のパッケージをアップデートしようと思ってyumを叩いたところ反応しませんでした。 # yum -y update Loaded plugins: changelog, fastestmirror, list-data, priorities, security, versionlock これだけで何の反応もなし。 エラーメッセージすら無しで、ログにも記載なし。 仕方ないのでクライアントをサーバーから切断する以外無いという有様でした。 色々調べてみて解決したのが、下記リンクで示されていた方法。 yumが動かないときの対処法 下記リンクに詳しくあります。 rpmコマンドがハングアップしてしまうときは どうやらrpmのトラブルだったようです。 ちなみにこれに辿り着く前に確認したところでは rpm:コマンド動作せず、ヘルプは参照可能。 yum:コマンド動作せず、ヘルプの参照も不可。 まあそれがどうしたという話ですが・・・ 何とか動作しましたが、あまり長々と放置してはいけないと実感しました。 [ad#ad_footer]

php.ini編集

xoopsでwebphotoモジュールをインストールしました。 インストール自体は上手く行ったのですが、画像を投稿しようとすると画面が真っ白で何も表示されないという事態に。 当初は権限関連かと思いましたがググって見たところ、memory_limitが関連している模様。 そこでモジュールの動作チェックで確認したところ、 memory_limmit = 16M という状態でした。 そこでサーバにログインし、rootに切り替えてからetc配下のphp.iniをviで編集。 /memoryで移動すると memory_limit = 16M ; Maximum amount of memory a script may consume とありますのでこれを32Mに設定し、念のためApacheをrestartするとwebphotoの動作チェックにも反映されていました。 [ad#ad_footer]

.htaccessでのリダイレクト

現在自宅サーバにてxoopsでのサイトを構築しています。 そのサイトのアドレスは本当は http://www.aaa.com/ と言ったシンプルなものにしたいと考えて、confファイルのドキュメントルートやxoopsのmainfileを編集することで/home/aaa/public_html/xoopsをaaa.comドメインのドキュメントルートにしようとしましたが上手くいかず。 厳密に言えば http://www.aaa.com/ でxoopsに直接アクセスは出来たのですが、ログインが上手く動作しないようで、ログインしてもゲストの画面に戻されてしまいましたので http://www.aaa.com/ から http://www.aaa.com/xoops にリダイレクトすることに。 リダイレクトにもいくつか方法がある用ですが、今回は.htaccessファイルを利用することにしました。 Redirect permanent /home/aaa/public_html/index.html http://www.aaa.com/xoops/ Redirect permanent /home/aaa/public_html/index.html /home/aaa/public_html/xoops 上記の表記だとどちらも上手く行かず・・・ Redirect permanent /index.html http://www.aaa.com/xoops/ 上の表記だとちゃんとリダイレクトできました、相対パス・・・ですか。 [ad#ad_footer]

バーチャルホストでの複数ドメイン運用

複数ドメイン運用が可能になったので備忘録的に書いておきます。 その前にDNSサーバやDiceでの設定が必要です。 こちらの場合はDiceを使っていますので、新たにイベントと追加して起動させれば問題ありません。 肝心のバーチャルホストに関してはhttpd.confにて。 vi /etc/httpd/conf/httpd.conf ServerName www.aaa.com DocumentRoot /home/aaa/public_html/ ServerName www.bbb.com DocumentRoot /home/bbb/public_html/ ErrorLog logs/bbb_error_log CustomLog logs/bbb_access_log common 当初は上記のように記載しました。 aaaが最初からのドメイン、bbbが今回追加のドメインです。 内容はhttpd.conf内のサンプルを参考にしましたが・・・ しかしこれだとbbb.comがaaa.comと同じページに飛ばされてしまったので見直し・・・ NameVirtualHost *:80 ServerName www.aaa.com ServerName www.bbb.com DocumentRoot /home/bbb/public_html/ ErrorLog logs/bbb_error_log CustomLog logs/bbb_access_log common aaaのドキュメントルートはconfファイル内別の場所に記載しています。 これでそれぞれ別のドキュメントルートに割り振られました。 追記:confファイルを構文をチェックする apachectl configtest というコマンドは結構便利だと思いました。 [ad#ad_footer]