2012/02/24

nginxのログをLogWatchにセットする

nginxのログをLogwatchにセットしておくのを忘れていました。
ということで設定します。

Logwatchの設定ファイルを ユーザ設定ディレクトリに作成します。
# touch /etc/logwatch/conf/logfiles/httpd.conf
作成したファイルをエディタで開いて...
# vi /etc/logwatch/conf/logfiles/http.conf
LogFile = nginx/*access.log
Archive = nginx/*access.log.*.gz
*ExpandRepeats
*ApplyhttpDate 
という感じで、nginxのログファイル名とアーカイブファイル名、オプションを記述。

尚、nginxの設定によりログは/var/log/nginx/下に出力するよう設定しています (→前記事)。
また、ログローテートはlogrotateを利用しており、/etc/logrotate.d/nginxで設定済みです。

ちなみに、Logwatchの設定ファイルの配置構成ですが・・・
(※間違っている可能性があります)
  • /usr/share/logwatch/default.conf/ - デフォルトの定義設定が格納されたディレクトリ
    • logfiles/〇〇〇.conf - ログファイルグループの定義設定
      　("ログファイルのパス"が指定されている。)
    • services/△△△.conf - サービスフィルタの定義設定
      　(サービスフィルタが処理する"ログファイルグループ名(○○○)"が指定されている。)
  • /usr/share/logwatch/dist.conf/ - ディストリによる定義設定が格納されたディレクトリ
    • 〃
    • 〃
  • /usr/share/logwatch/scripts/ - デフォルトのサービスフィルタ(処理スクリプト)が格納されたディレクトリ
    • logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
      　(ログファイルグループ"○○○"に対する処理スクリプト)
    • services/△△△ - サービスフィルタ (Perlスクリプト)
      　("△△△"のログ内容に対する処理スクリプト)
    • shared/***
  • /etc/logwatch/conf/ - ユーザによる定義設定を格納するディレクトリ
    • logfiles/〇〇〇.conf - ログファイルグループの定義設定
    • services/△△△.conf - サービスフィルタの定義設定
  • /etc/logwatch/scripts/ - ユーザによるサービスフィルタ(処理スクリプト)を格納するディレクトリ
    • logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
    • services/△△△ - サービスフィルタ (Perlスクリプト)
となっているようです。たぶん。(間違いあれば、ご指摘お願いします！)

元々、/usr/share/logwatch/default.conf/logfiles/下には"http.conf"が存在しており、
そこにApacheのためのログファイルグループ定義が記述されています。


今回はさらに、/etc/logwatch/conf/logfiles/下に"httpd.conf"を新しく作成して
そこにnginxのための定義を記述しました。
こうすることで.../usr/share/logwatch/default.conf/logfiles/下の"http.conf"で定義された内容に加えて(上書きではなく追加で)、今回の定義した内容が追加されて処理されるようです。
つまり、nginxの定義設定を Apacheのための定義設定に追加したことになります。
そのため、ログの処理は、Apacheのためのスクリプトがそのまま利用されます。
nginxのログはApacheのログと形式が殆ど同じであるためにこれが可能なのですね。
尚、実際のログレポートは、Apacheとnginxのログが混ざった形で送られてきます。
(Apacheのためのログファイルグループ定義を上書きしたのではなく、あくまでそこに追加しただけであるからです。)

LogWatchによって生成されるレポートメールは
# logwatch -service http -print
でテスト出力を行うこともできます。
(この例では、httpサービスフィルタのテスト。)
あと、設定にもよりますが・・・
動作チェックのためにわざとログに残るようなアクセスをしてみても、
Logwatchのレポート出力範囲が”昨日分”だったりするので、
うっかり忘れていたりすると戸惑いましたw 注意ですね(＾＾；))

参考にさせていただきました(感謝♪):
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2012/02/23

nginxによるリバースプロキシ＋Apacheによるバックエンドの構成 (with SSL)

nginxによるリバースプロキシ＋Apacheによるバックエンドの構成をしてみました。
1台のサーバ上で、nginxとApacheが共存している状態です。
  • example.com 203.0.113.0
    • nginx - リバースプロキシ
      • 127.0.0.0 :80
      • 127.0.0.0 :443 (SSL)
    • Apache - バックエンド
      • 127.0.0.0 :8080 - ローカルのみ
      • 127.0.0.0 :8443 - ローカルのみ
nginxとApache間は、ローカルでHTTP通信をしています。
(SSLであっても、nginxでSSLを取り払って、Apacheへ渡しています。)

[課題]
問題としては、”Apache側のポート番号”がありました。
バックエンドであるApache自身でリッスンしているポート番号が8443であるために、
Apache上のCGIがリダイレクトなどを行う際に、
ユーザから見える本来のポート番号である"443"(＝nginxのポート番号)ではなく
"8443"へリダイレクトしてしまうという状態となったのです。

もし、複数台のサーバ環境であれば、nginxとApacheを1台に共存させる必要がないため、
Apacheのポート番号を、nginxのポート番号と同じにしておけば良いのですが・・・。
今回はとりあえず、Apacheが都合よく、自分のリッスンしているポート番号ではなく
本来のポート番号をCGIなどに伝えてくれれば良いので、
Apache側の設定で環境変数を書き換えして解決しました。
これについてご指摘や正しい解決方法などありましたら、アドバイスお願いします m(_ _)m

[おことわり]
この構成ではあまりリバースプロキシにする意味がないのですが、
実は...この記事は端折っていて、実際の運用では
バックエンドとして、Apacheだけでなく他のアプリケーションも用意しており、
この記事のApacheへの振り分けと同様に
nginxのLocationディレクティブで振り分けるようにしています。
また、キャッシュや圧縮をnginx側で行なってもらっていたりします。
今回は、あくまでSSLまわりの設定の仕方をメモすることが目的の記事であるため、
これだけの内容に端折りました。 あとの詳しいことはまた追々（汗；）


nginxは、先日インストールしたものです:
Masanoriのプログラミング日誌＋＋: nginxをEPELから導入して最新版上書き＆モジュール導入

Apacheに”mod_rpaf”モジュールを適用。
http://stderr.net/apache/rpaf/
http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
尚、Apache 2.2なので、デフォルトでUseCanonicalName Off。

/etc/nginx/nginx.conf :
リバースプロキシであるnginxの設定
user              apache apache;
error_log  /var/log/nginx/error.log;
〜
http {
    access_log  /var/log/nginx/access.log  main;
    server {
        listen 80;
        listen 443 default_server ssl;
        server_name _;
     
        ssl_certificate        /etc/pki/tls/certs/server-chained-ca.crt;
        ssl_certificate_key  /etc/pki/tls/certs/server.key;
     
        charset utf-8;
     
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Remote-Addr          $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $host;
        proxy_set_header X-Forwarded-Server     $host;
        proxy_set_header X-Forwarded-Proto      https;
        proxy_set_header X-Forwarded-Port       $server_port;
     
        location ~ ^.+ {
                #この例では全てのアクセスを振り分けている
                if ($server_port = 80){
                        proxy_pass      http://127.0.0.1:8080;
                        break;
                }
                if ($server_port = 443){
                        proxy_pass      http://127.0.0.1:8443;
                        break;
                }
        }
        〜
    }
}
/etc/httpd/conf.d/vhost.conf :
バックエンドであるApacheのHTTPアクセス時設定
NameVirtualHost *:8080
Listen 8080
<VirtualHost *:8080>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName example.com:80
    CustomLog /var/log/apache/access.log combined
    ErrorLog /var/log/apache/error.log
    SetEnv SERVER_PORT 80
</VirtualHost>
/etc/httpd/conf.d/vhost_ssl.conf :
バックエンドであるApacheのHTTPSアクセス時設定
LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:8443
Listen 8443
<VirtualHost *:8443>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName https://example.com:443
    ErrorLog /var/log/apache/ssl_error.log
    CustomLog /var/log/apache/ssl_access.log combined
 
    SetEnv SERVER_PORT 443
    SetEnv HTTPS ON
 
    SSLEngine off
</VirtualHost>
別に..ファイルを分ける必要も、LoadModuleする必要も無い気がしますが（汗；）

/etc/httpd/conf.d/rpaf.conf :
Apacheの”mod_rpaf”モジュールによって、
アクセス元であるリバースプロキシのIPアドレス(127.0.0.0)を
実際のアクセス元のIPアドレスに置き換えるための設定。
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1
こんな感じです。

参考にさせていただいたページ(感謝♪):
投稿者 時刻: 0 件のコメント:
ラベル: ,

2012/02/22

nginxをEPELから導入して最新版上書き＆モジュール導入

nginxをEPELから導入したいと思います。
最新版は1.0.12ですが、EPELには最新版がありません。
また、nginxのモジュールの組み込みにはビルドしなおす必要があります。
だったら完全にソースから...となるのですが、それはそれでinit.dの準備などなど面倒です。
そのため、EPELからnginx-0.8.55-1を取得して...これを基に、
nginx-1.0.12と、モジュール ngx_cache_purge-1.5 を適用します。

今回は...
http://sakuratan.biz/archives/4582 と
http://sakura.off-soft.net/centos/apache-nginx-1-reverse-proxy-install.html
を参考にさせていだきます。感謝♪
（参考というか大半写しですね...自分用のメモを兼ねているのでお許しを m(_ _)m
以下の内容を参考にされる方は、そのまえに上記のサイトをじっくりお読みください。）

前準備にパッケージをインストール。
$ sudo yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

次にEPELからnginxのSource RPMをダウンロード。
nginxの最新版は1.0.12なわけですが、ここにあるのは0.8.55-1。
http://dl.fedoraproject.org/pub/epel/5/SRPMS/repoview/nginx.html
$ wget http://dl.fedoraproject.org/pub/epel/5/SRPMS/nginx-0.8.55-1.el5.src.rpm
インストール。
$ sudo rpm -ivh nginx-0.8.55-1.el5.src.rpm
警告: グループ mockbuild は存在しません - root を使用します

とりあえず、このエラーは無視で構わないそうです。

次は、このインストールしたnginxに対して
最新版のnginxとモジュールで上書きをします。

まずはインストールしたソースディレクトリへ移動して...
$ su
# cd /usr/src/redhat/SOURCES
nginxの最新版(1.0.12)のパッケージをダウンロード。
# wget http://nginx.org/download/nginx-1.0.12.tar.gz
次に、ngx_cache_purge モジュールの最新版(1.5)のパッケージをダウンロード。
# wget http://labs.frickle.com/files/ngx_cache_purge-1.5.tar.gz
さらに、SPECファイルを編集します。
SPECディレクトリへ移動して、nginx.specをエディタで開きます。
# cd /usr/src/redhat/SPECS
# cp nginx.spec nginx.spec.org
# vi nginx.spec
11行目付近：バージョン番号を変更。
Version:        1.0.12

42行目付近：モジュールのパッケージファイル名を追加。
Source10:   ngx_cache_purge-1.5.tar.gz

51行目付近：パッチのための記述をコメントアウト。
#Patch0:     nginx-auto-cc-gcc.patch

60行目付近：同様にコメントアウト。
#%patch0 -p0

61行目付近：ビルド前処理としてモジュールパッケージを展開する記述を追加。
%setup -T -D -a 10

69行目付近：文字コードを設定する記述を追加しておきます。
export LANG='ja_JP.UTF-8'

106行目付近：モジュールを追加しているため、ここの記述も書き換え。
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --add-module=%{_builddir}/nginx-%{version}/ngx_cache_purge-1.5
make %{?_smp_mflags}

110行目付近：モジュールのドキュメントファイルの名前を変更する記述を追加。
mv ngx_cache_purge-1.5/CHANGES ngx_cache_purge-1.5/CHANGES.ngx_cache_purge
mv ngx_cache_purge-1.5/README.md ngx_cache_purge-1.5/README.ngx_cache_purge

168行目付近：モジュールのドキュメントファイルをnginxに追加。
%doc ngx_cache_purge-1.5/CHANGES.ngx_cache_purge ngx_cache_purge-1.5/README.ngx_cache_purge

これで上書きします。

あとは・・・ビルド。
# rpmbuild -bb nginx.spec
〜〜〜
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-1.0.12-1.x86_64.rpm
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-debuginfo-1.0.12-1.x86_64.rpm
実行中(%clean): /bin/sh -e /var/tmp/rpm-tmp.56019
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd nginx-1.0.12
+ rm -rf /var/tmp/nginx-1.0.12-1-root-root
+ exit 0

ビルドが終わったようです。
あとは、今できあがったパッケージをインストールします。
# cd ../RPMS/x86_64/
# rpm -Uvh nginx-1.0.12-1.x86_64.rpm

これで完了ですね。

投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

pacoでパッケージインストール管理

paco(pacKAGE oRGANIZER)を使うと、
Linuxでmake installによってソースからパッケージをインストールする際に
インストールしたソフトウェアを管理することができるそうです。
基本的にyumやaptitudeを使っているので...知りませんでした・・・。

ということで、yumから、pacoをインストールします。

$ sudo yum install paco
Installed:
  paco.i386 0:2.0.9-7.el5               paco.x86_64 0:2.0.9-7.el5              
OKですね。

実際の使い方は...
パッケージのアーカイブを展開してconfigure、makeをした後、
"sudo make install"をする際に、
$ sudo paco -D make install
のようにpacoを通して行えばいいようです。
("-D"オプションは、pacoで管理する際のパッケージ名に、
現在のカレントディレクトリ名を使うことを意味する。)

詳しくは...
make install"したソフトウェアを管理できる超便利ツール「Paco」 - RX-7乗りの適当な日々
に書いてくださっているので、そちらを。(感謝♪！)


投稿者 時刻: 0 件のコメント:
ラベル: , ,

2012/02/12

Trac-0.12.2.ja1のチケットとSubversionを連携させる

Subversionのコミット時に、Trac-0.12.2.ja1（チケット機能含む）を連携させたいと思います。
Trac-0.12は大変楽になっているようですね。

まず、Subversionのリポジトリディレクトリ下の"hooks/post-commit"に
次の記述を行います。（/var/svn/hogeprojectは自分自身のSVNリポジトリディレクトリパス。
(default)は、Trac上で設定しているSVNリポジトリの名前です。初期設定どおりなら(default)はなず。$2は変数で、リビジョン番号に置き換わります。）
#!/bin/sh
export LANG=ja_JP.UTF-8
/var/svn/hogeproject/hooks/trac-svn-hook "\"(default)\"" $2
この”post-commit”に対して、実行権限を与えておきます。


次に、同ディレクトリ(hooks/)に、”trac-svn-hook”ファイルを置きます。
このファイルは、Trac-0.12.2.ja1のアーカイブの"contrib/"ディレクトリに含まれます。

さらに、”trac-svn-hook”ファイルのConfigurationセクション(48行目あたりから)を編集します。
(対象のTrac環境のディレクトリパスと、Pythonの実行パス、ライブラリパスを指定します。)
# == Configuration
#
# Uncomment and adapt to your local setup:
#
export TRAC_ENV=/var/trac/hogeproject
export PATH=/usr/local/bin/python2.7:$PATH
export LD_LIBRARY_PATH=/usr/local/lib/python2.7:$LD_LIBRARY_PATH
”trac-svn-hook”も、実行権限を与えておきます。

最後に...Tracのプラグイン管理画面で、
"CommitTicketReferenceMacro"および"CommitTicketUpdater"を有効にする。

これだけで...できあがりです。


[2012/02/12 追記]
"hooks/post-commit"に
#!/bin/sh
export LANG=ja_JP.UTF-8
REV=”$2″
trac-admin /var/trac/hogeproject changeset added "(default)" $REV
みたいな感じで直接、trac-adminコマンドを実行するように記述するだけでも良いらしいです。（こちらのほうがさらに楽ですね。）

[2012/02/13 追記]
うまく動作しないときにチェックすること:
  • ”trac-svn-hook”、"post-commit"内の記述(パスなど)
  • ”trac-svn-hook”、"post-commit"の所有者/実行権限
  • Trac環境の"log"ディレクトリの権限
  • Tracのプラグイン設定
    ("CommitTicketReferenceMacro"および"CommitTicketUpdater"が有効か。)
参考にさせていただきました(感謝♪):


投稿者 時刻: 0 件のコメント:
ラベル: ,

2012/02/11

Tracでgraphvizを使えるように・・・できなかった・・解決！

・・・ということで...graphvizと、graphvizpluginを導入して
Tracでフローチャートを描画できるようにしたいと思います。
（※失敗談も含めて順をおってしか書いておりません。あんまり役に立たないかもしれません。
　　しかも失敗した理由は、完全に初歩的ミスです...。こういう時もあるということで(汗；)...）

＜2012/02/11現在、失敗しています。:-p ＞

まずは、graphviz。yumからインストールします。
バージョンは、2.12。
# yum install graphviz 
Downloading Packages:
(1/12): libtool-ltdl-1.5.22-7.el5_4.i386.rpm             |  37 kB     00:00  
(2/12): libXpm-3.5.5-3.i386.rpm                          |  45 kB     00:00  
(3/12): libXmu-1.0.2-5.i386.rpm                          |  62 kB     00:00  
(4/12): libgsf-1.14.1-6.1.x86_64.rpm                     | 113 kB     00:00  

(5/12): libcroco-0.6.1-2.1.x86_64.rpm                    | 129 kB     00:00  

(6/12): librsvg2-2.16.1-1.el5.x86_64.rpm                 | 178 kB     00:00  
(7/12): libXaw-1.0.2-8.1.i386.rpm                        | 324 kB     00:00  

(8/12): ghostscript-fonts-5.50-13.1.1.noarch.rpm         | 801 kB     00:00  
(9/12): graphviz-2.12-8.el5.i386.rpm                     | 1.1 MB     00:00  
(10/12): graphviz-2.22.0-4.el5.rf.x86_64.rpm             | 2.5 MB     00:04  
(11/12): urw-fonts-2.3-6.1.1.noarch.rpm                  | 4.5 MB     00:00  
(12/12): ghostscript-8.70-6.el5_7.6.x86_64.rpm           | 8.9 MB     00:01  
--------------------------------------------------------------------------------
Total                                           2.3 MB/s |  19 MB     00:08  
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Check Error:
  file /usr/bin/gxl2dot conflicts between attempted installs of graphviz-2.12-8.el5.i386 and graphviz-2.22.0-4.el5.rf.x86_64

・・・この様である。

というわけで・・・調べる...。
ふむふむ。

# yum install graphviz.x86_64
Installed:
  graphviz.x86_64 0:2.22.0-4.el5.rf                                          
Dependency Installed:
  ghostscript.x86_64 0:8.70-6.el5_7.6   ghostscript-fonts.noarch 0:5.50-13.1.1
  libcroco.x86_64 0:0.6.1-2.1           libgsf.x86_64 0:1.14.1-6.1            
  librsvg2.x86_64 0:2.16.1-1.el5        urw-fonts.noarch 0:2.3-6.1.1          
Complete!
はいっ。これでよさそうですね。

次に、Trac用のプラグインを導入します。
バージョンは、0.13。(←これがミスでした。詳しくは後述ｗ)

# /usr/local/bin/python2.7 /usr/local/bin/easy_install http://trac-hacks.org/svn/graphvizplugin/0.13/
Tracを配置しているディレクトリ下のhtdocsディレクトリに
画像書き出し用のディレクトリを作り、書き込み可能にしておく。
# cd /var/trac/hogeproject/htdocs
# mkdir graphviz
# chown apache:apache graphviz
Tracでgraphvizプラグインをenabledに。

[components]
graphviz.* = enabled

httpdを再起動。
# service httpd restart
するも、Tracの管理画面のプラグイン画面に
Graphvizプラグインが表示されない・・・。

Tracのログを見ると...
2012-02-11 11:12:34,798 Trac[loader] ERROR: Skipping "graphviz = graphviz":
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/loader.py", line 68, in _load_eggs
    entry.load(require=True)
  File "/usr/local/lib/python2.7/site-packages/setuptools-0.6c12dev_r88846-py2.7.egg/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/bdist.linux-x86_64/egg/graphviz/__init__.py", line 17, in <module>
  File "build/bdist.linux-x86_64/egg/graphviz/graphviz.py", line 33, in <module>
ImportError: cannot import name find_element
Graphvizプラグインがインポートエラーを出している。
何故だ・・・。

とりあえず、該当ファイル(graphviz.py)のソースコードを見る。
...
from trac.mimeview.api import Context, IHTMLPreviewRenderer, MIME_MAP 
from trac.util.html import escape, find_elementfrom trac.util.text import to_unicode 
from trac.util.translation import _
...
うーん。

Tracのソースコードを見る...。
(Trac-0.12.2.ja1/build/lib/trac/util/html.py)
...
import re
from genshi import Markup, escape, unescape
from genshi.core import stripentities, striptags, START, END
from genshi.builder import Element, ElementFactory, Fragment
from genshi.filters.html import HTMLSanitizer
__all__ = ['escape', 'unescape', 'html', 'plaintext', 'TracHTMLSanitizer']
class TracHTMLSanitizer(HTMLSanitizer):
...
Pythonのことは全然わからないんですが、
このファイルを全部見たところ、”find_element”なんか存在しないのです...。
（だったら他でインポートされているのだろうか・・・）
どうしたらいいんだろうー (´；ω；｀)

似たような問題のチケットはTrac-hacksに発見したが：
http://trac-hacks.org/ticket/9180 (放置されたまま5年経過しているようだ)

うーん。

[2012/02/11 12:02 追記]

・・・もしかして。

http://trac.edgewall.org/browser/trunk/trac/util/html.py
(最新版のTrac(Trac 0.13)のhtml.py)

・・・なるほど！ｗｗｗ

私はやっぱりアホだったようです(>ω<；)

現在、graphvizpluginのリポジトリに存在するバージョンは
0.9、0.10、0.11、0.13...の4つ。
http://trac-hacks.org/browser/graphvizplugin

そして私が導入しているTracは、Trac 0.12ですから...。
0.12用のgraphvizpluginが無いからということで
何の気なしに、最新版のgraphvizplugin 0.13を選んでしまいました。

ちなみに・・・リポジトリには
/Readme.txt
というファイルが置かれていて、インストール前にこれは読んでみたのですが、
ここに、0.13に関する情報はなかったです。（だからって選ぶなよ、私ｗ）

さらに、0.13のディレクトリには、
ReleaseNotes.txt
というファイルが含まれていますが、これについては0.7.1用の文書を
そのままコピーしただけで未更新のようでした。とても古い。
（これも...だからって気にせずインストールしてしまうとは、私ってやつは...www）

いつもはもうちょっと気をつけるのですが。
うっかりですね・・・(汗；)

ちなみに...言い訳をすると、この記事の手順はちょっと端折っていて、
実際には、個別のTrac環境にプラグインをインストールして試用をしてみています。
自分の環境で動作確認がとれていないものを、実稼動しているTrac全体に導入するのは流石に危ないので・・・。

...とりあえず、graphvizplugin 0.13を削除。

# rm /usr/local/lib/python2.7/site-packages/graphviz-0.13.0.6-py2.7.egg

気を取り直して、graphvizplugin 0.11をインストール。
（尚、今度はsvn exportしてくることにします。）
http://trac-hacks.org/svn/graphvizplugin/0.11/
# svn export http://trac-hacks.org/svn/graphvizplugin/0.11/ graphvizplugin-0.11/
# cd graphvizplugin-0.11
# /usr/local/bin/python2.7 setup.py build
# /usr/local/bin/python2.7 setup.py bdist_egg
# cd dist
# /usr/local/bin/python2.7 /usr/local/bin/easy_install *.egg
httpdを再起動。
# service httpd restart
きましたわーーーーーーーっ！(>ω<)（←

あとは、trac.iniに、[graphviz]セクションを。
cache_dir = htdocs/graphviz

これで・・・。

Wikiになんか書いてみる。


{{{
#!graphviz
digraph G {Hoge->Piyo}
}}}

おおー。


描画できました。
それにしても、Wikiでフローチャートが表現できるとは...すばらしいですね！

参考にさせていただいたサイト(感謝♪):




投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2012/02/06

TracのIniAdminプラグインを導入したらエラーが。


Trac 0.12.2.ja1にIniAdminPluginを導入したところ、
導入自体はうまくいったのですが、
実際に管理画面からIniAdminによる設定をしようとすると・・・
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinal not in range(128)
というエラーが・・・。

検索してみると同様の症例が見つかりました：
日本語ファイル名があるディレクトリをTracのSVNリポジトリで見るとエラーが発生する場合の対処 — ディノオープンラボラトリ
感謝(´；ω；｀)♪

で...なるほど・・・文字コードの問題・・・。
(たしかに設定ファイルに日本語が含まれるセクションだけエラーになるわけだ・・・。)

とりあえず...
/usr/local/lib/python2.7/site.py を、
先のページに従い、
encoding = "ascii" # Default value set by _PyUnicode_Init()
をコメントアウトし、
#encoding = "ascii" # Default value set by _PyUnicode_Init()
encoding = "utf-8"  # Default value set by _PyUnicode_Init()
としたら、たしかに正常に動作しました。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2012/02/01

UbuntuにNet::SSLeayがインストールできない件

開発環境であるUbuntu(10.10)に、Net::SSLeayをインストールしようとしたのですが・・・
$ sudo cpan Net::SSLeay
〜〜〜〜
SSLeay.xs:43: fatal error: openssl/err.h: そのようなファイルやディレクトリはありません

などという非情なエラーがｗ

ちょうど同様の事象と解決方法を発見(感謝！♪)

解決方法としては、先にlibssl-devをインストールすることだそうです。
$ sudo apt-get install libssl-dev
$ sudo cpan Net::SSLeay
できましたｗ

...いや、PerlからPOP3サーバ(on SSL)に接続を試みているものの
SSL通信が使えず...困っていたのですが、これで解決です。
(あとは、IO::Socket::SSLなんかをインストールして完了。)
投稿者 時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)