「Apache」と一致するもの

ふと思い出してAN HTTP Server Home Pageにアクセスしてみたところ、403ページとなっていました。
Twitterで検索してみたところ、2015年2月頃には公開停止していたようですね。

最初に利用したWebサーバソフトウェアはAN HTTPdでした。
Windowsに気軽にインストールでき、CGIも使用できたので、Windowsで自宅サーバを運営していた時代はよく利用しました。
その後、自宅サーバを玄箱に移行し、Linuxで運営してからは、あまり利用しなくなりましたが、Apacheで動かす程ではないという時には非常に便利なWebサーバソフトウェアでした。

最新版の1.42pは2006年4月に公開されたもので、かれこれ10年前ですしね。
最近は更新されておらず、セキュリティの脆弱性にも強いとは言えない状況でしたので、やむを得ないのかもしれません。

AN HTTPd作者の中田昭雄様、かつては大変お世話になりました。
この場を借りて御礼申し上げますm(_ _)m

今回は、analogの設定をした際の俺専用メモです( ̄∇ ̄)ノ♪(ぇ?(笑)

# apt-get install analog
apt-getを使ってanalogをインストール

# vi /etc/analog.cfg
テキストエディタでanalogの設定ファイル(analog.cfg)を以下の様に編集:

LOGFORMAT combined
LOGFILE /var/log/apache2/access.log
LOGFILE /var/log/apache2/access.log.*
↑の設定にすることで、ログローテーションされてgz(GZIP)圧縮されたログも含めて解析してくれる(≧∇≦)

OUTFILE /var/www/axsanalyze/result.html
解析結果の出力先を設定する

INTSEARCHQUERY OFF
INTSEARCHQUERYをONからOFFにしないと、cron実行時に以下の様な警告が発生する:
/usr/bin/analog: analog version 5.32/Unix
/usr/bin/analog: Warning R: Turning off empty Internal Search Query Report
(For help on all errors and warnings, see /usr/share/doc/analog/errors.html)

それ以外のanalog.cfgの設定は割愛(ぇ?


# perl -MCPAN -e shell
cpan > install Jcode
Jcodeのインストール

Graffiti - analog関連より、analogurldecode.plをダウンロードし、analog解析結果出力先(今回は/var/www/axsanalyze/直下)に設置

# cd /var/www/axsanalyze/
# chmod 644 analogurldecode.pl
パーミッションを設定

# cd /usr/local/bin/
# touch analog.sh
# chmod 755 analog.sh
cron用のスクリプト(analog.sh)を作成し、パーミッションを設定

# vi analog.sh
テキストエディタでanalog.shを以下の様に編集:

#!/bin/bash

/usr/bin/analog

cd /var/www/axsanalyze/

perl analogurldecode.pl result.html > result_jp.html


$ crontab -e
cronを使用し、毎日10時15分にanalogを起動する様に設定:

15 10 * * * /usr/local/bin/analog.sh
※cronで正常に動作するかのテストをする場合、現在の時刻+2分で設定し、保存すること。現在の時刻+1分だとcronのリロードが間に合わず、起動に失敗することがある。


crontabで上記の設定をしたら、Ctrl + Xキー→Yキーで保存し、作業終了(≧∇≦)

その後、Apache 2で/var/www/axsanalyze/のresult_jp.htmlにあたるページにアクセスすると、日本語キーワードがエンコードされて表示された解析結果が表示される。
ただし、検索結果のURLを直接参照したい場合にはresult.htmlからアクセスすると良い。


・今回の記事を書くにあたり参照したページ:
Linux で自宅サーバ - Apache ログ解析 Analog の導入
Graffiti - analog関連
Linuxべんりな動作情報 ナレッジベース:環境設定 - cron の設定ガイド
定番Linuxフリーウェアまとめ - crontabで一分後に実行設定したが動かない

OASでLog4Jが原因のデプロイエラーが発生する

OAS(Oracle Application Server)に、WARファイルをデプロイしようとしたところ以下のエラーが発生し、失敗しました:
Operation failed with error: org/apache/log4j/Category 

今回作成しようとするシステムの中には確かにLog4Jのログ出力が含まれている訳ですが、それが原因で失敗してしまったら、実に困りものな訳ですね。
デプロイ時の設定に問題があると思いまして調査したところ、やっぱりデプロイ時のOASの共有ライブラリの設定に問題がありました。

共有ライブラリのインポート設定で[apache.commons.logging]のチェックボックスを外しましょう。
OASの共有ライブラリのインポート設定って結構くせ者ですよね...
しかも、Oracle製品だけあって相変わらず情報が少ない(;_;)

同様の悩みを抱えている方も、この情報が役に立つことを祈ってます( ̄∇ ̄)ノ♪

Apache Tomcatでアクセスログを出力する

Apache TomcatではWebページへのアクセスログが出力はできません。つまりどのファイルにアクセスされたとか、404エラーが発生しているパスとかの調査はできません。

...ってそう思っていた時代が俺にもありました。
マジで、かれこれ4年間本当にそう思っていましたorz

JSP & Servletコンテナだから仕方ないと思っていたのですが、最近、アクセスログ用いて調査しなくてはいけない懸案が発生したので、Google大先生に聞いてみました。
そしたら普通にあるじゃんorz

"(Tomcatのインストールフォルダ)\conf\"に存在するserver.xmlを開きます。

現在、私がインストールしているバージョンでは、341行目〜345行目に以下のような記述がされています。

<!-- <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> -->

ご覧の通り、デフォルトではコメントアウトされていますのでコメントアウト部分の「<!--」と「-->」をさくっと削除してしまいましょう。

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>

すっきり!(某番組風)

このように設定した後、Tomcatを再起動すれば、"(Tomcatのインストールフォルダ)\logs"に「localhost_access_log.2008-06-21.txt」のようなファイルが出力されるようになります。

めでたしめでたし。

Apache Tomcatで動作したWebアプリケーションをOracle Application Server(OAS)で動作させようとしたら正常に動作しなかった問題とその解決法について紹介します。

事の発端は以下の通り:
Eclipse+Tomcatで製作したWebアプリケーションを、一度、WARファイルに固めました。
そして、OASに配置して動作試験を行いました。
しかし、EL(Expression Language)を使用しているページで式言語がそのままの文字で出力されてしまう問題が発生しました。

JSPでEL式が使えない場合の対策で書いたことを疑いましたが、そもそもWARファイルに固めているのでライブラリも含まれています。

なんだかんだで必死に原因を調べたのですが、思わぬところに理由がありました。

@ITのJ2EE 1.4に対応したweb.xmlを記述するの記事に、J2EE 1.3とJ2EE 1.4の場合のweb.xmlが書かれています。

J2EE 1.3の場合のweb.xmlは

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
  ...中略...
</web-app>

J2EE 1.4の場合のweb.xmlは

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

  ...中略...
</web-app>

となっています。

問題のWebアプリのweb.xmlは以下のようになっていました:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

  ...中略...
</web-app>

もうお分かりですね、J2EE 1.3の設定とJ2EE 1.4の設定が混ざっていたんですorz

今回の原因を考察してみました。
今回Apache TomcatはVer5.0.24を使用しておりJ2EE 1.4に準拠すること前提で製作されているため元々EL式を読み込むようになっているようです。対して、OASの方はWebサーバこそApache Web Serverのソースを流用していますが、Servletコンテナはそうではないようです。そのため、Apache Tomcatより厳密にweb.xmlを解釈しているものと思われます。
<web-app>タグより前に存在するDOCTYPE宣言を見た上で、J2EE 1.3のアプリケーションと認識してしまったようですね。

説明し忘れましたが、EL式(式言語)がデフォルトで対応になったのはJ2EE 1.4からです。それ以前のバージョンはJSTL(JSP Standard Tag Library)のライブラリとweb.xmlの設定をして初めて対応になります。

OASではELは動作する情報しか出てこない中、OASの情報がそもそも少ないので今回の原因調査には何日も掛かってしまいましたorz
それでも解決できて何よりでした。