IT Berater – Java, J2EE, WebSphere Portal, Lotus Domino
RSS icon Home icon
  • Installing Tomcat 6 on Debian Squeeze

    (10 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 13 March 2010 Sebastian Thomschke*/?> 10 comments

    This post describes how to setup Tomcat 6 on Debian Squeeze. The configured Tomcat serves requests on port 80 without the need of an additional web server. This is especially good for virtual servers (VPS) providing limit memory. It also has multiple virtual hosts configured, each with it’s own webapp with context root / and optional support for PHP via the Quercus PHP implementation.

    Installing Sun Java 6

    Ensure the non-free section is enabled for the APT repository configuration in /etc/apt/sources.list, e.g. “deb http://ftp.de.debian.org/debian testing main contrib non-free”

    apt-get update
    apt-get install sun-java6-jdk
    echo 'JAVA_HOME="/usr/lib/jvm/java-6-sun"' >> /etc/environment
    echo 'JRE_HOME="/usr/lib/jvm/java-6-sun/jre"' >> /etc/environment
    

    Installing Tomcat 6

    apt-get install tomcat6 tomcat6-admin
    /etc/init.d/tomcat6 stop
    

    Creating standard Tomcat directory layout (optional)

    mkdir /opt/tomcat
    cd /opt/tomcat
    ln -s /etc/tomcat6/ conf
    ln -s /usr/share/tomcat6/bin/ bin
    ln -s /usr/share/tomcat6/lib/ lib
    ln -s /var/lib/tomcat6/webapps webapps
    ln -s /var/log/tomcat6/ logs
    

    Creating a Tomcat admin user

    In /opt/tomcat/conf/tomcat-users.xml add an entry like:

    <user name="ADMIN_USERNAME" password="ADMIN_PASSWORD" roles="admin,manager" />
    

    Setting up virtual hosts

    For each virtual host execute the following command. Replace “mydomain.com” with the desired virtual host name, but omit the “www.” part.

    mkdir -p /opt/tomcat/webapps.mydomain.com/ROOT
    

    In the <Engine> tag of “/opt/tomcat/conf/server.xml” add one host entry for each virtual host.

    <Host name="mydomain.com" appBase="/opt/tomcat/webapps.mydomain.com">
        <Alias>www.mydomain.com</Alias>
        <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="mydomain_access_log." suffix=".txt" pattern="common"/>
    </Host>
    

    The <Alias> tag tells Tomcat to redirect from www.mydomain.com to mydomain.com.
    The <Valve> tag enables access logging in the standard logging format.

    Using xinetd to configure port 80 for Tomcat

    Binding a service on port 80 requires root permissions. Thus we use port forwarding to “bind” Tomcat to port 80. My VPS does not support the use of “iptables -j REDIRECT” therefore I am using xinetd as a web proxy.
    Ensure that no other service is listening on port 80/443:

    netstat -pan | grep ":80\|:443"
    

    Register the required xinetd services:

    echo echo "
    service www
    {
            socket_type     = stream
            protocol        = tcp
            user            = root
            wait            = no
            bind            = 88.80.198.181
            port            = 80
            redirect        = localhost 8080
            disable         = no
            flags           = REUSE
            log_type        = FILE /var/log/wwwaccess.log
            log_on_success  -= PID HOST DURATION EXIT
    
            per_source      = UNLIMITED
            instances       = UNLIMITED
    }
    
    service https
    {
            socket_type     = stream
            protocol        = tcp
            user            = root
            wait            = no
            bind            = 88.80.198.181
            port            = 443
            redirect        = localhost 8443
            disable         = no
            flags           = REUSE
            log_type        = FILE /var/log/httpsaccess.log
            log_on_success  -= PID HOST DURATION EXIT
    
            per_source      = UNLIMITED
            instances       = UNLIMITED
    }
    " > /etc/xinetd.d/tomcat
    /etc/init.d/xinetd restart
    

    If you want to use a different service name, e.g. “tomcat” instead of “www” you must add this service to /var/services, e.g. “tomcat 80/tcp”
    In /opt/tomcat/conf/server.xml modify the <Connector> as follows:

    <Connector port="8080" protocol="HTTP/1.1"
                   connectionTimeout="20000"
                   redirectPort="8443" proxyPort="80" address="127.0.0.1" />
    

    This binds Tomcat to localhost. It also tells Tomcat that port 80 is the proxy port which is necessary for correct URL generation.
    From now on the Tomcat admin applications are only accessible via localhost. You can use SSH port forwarding to still access the applications from your workstation’s web browser. E.g. if you are using PuTTY you can use this command line option “-L 8080:localhost:8080” to forward the server’s local 8080 port to your workstation’s local 8080 port. On your workstation’s browser you then simply enter http://localhost:8080/manager/html and are connected to the server’s Tomcat admin application.

    Enabling PHP support (optional)

    Download Quercus.

    mkdir -p /opt/downloads
    wget -o /opt/downloads/quercus-4.0.3.war http://caucho.com/download/quercus-4.0.3.war
    

    Install Quercus as a shared library.

    unzip -j /opt/downloads/quercus-4.0.3.war \*.jar -d /opt/tomcat/lib
    

    Enable PHP support for the virtual hosts by installing the quercus web.xml. For each virtual host execute:

    unzip /opt/downloads/quercus-4.0.3.war *web.xml -d /opt/tomcat/webapps.mydomain.com/ROOT
    

    Starting Tomcat

    /etc/init.d/tomcat start
    

    References

  • [Behoben] Leere Seiten mit WordPress 2.6.x

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 13 September 2008 Sebastian Thomschke*/?> 2 comments

    Nach dem Upgrade auf WordPress 2.6 kam es immer wieder vor das im Browser leere Seiten angezeigt wurden. Eine Seitenaktualisierung mittels STRG+F5 behob in den meisten Fällen das Problem. Heute habe ich meinen Blog auf WordPress 2.6.2 aktualisiert und danach war es nicht mehr möglich die Verwaltungsseite für Plug-ins aufzurufen. Egal was ich probierte, die Seite blieb im Browser leer.
    Auf der Suche nach einer möglichen Lösung im Internet bin ich auf verschiedene Diskussionen über dieses scheinbar allgemein bekannte Phänomen gestossen. Leider half in meinem Fall keine der skizzierten Lösungsansätze.
    Daher habe ich mich einmal mehr in die Untiefen des WordPress Codes gestürzt und die – für meinen Fall – entscheidenden Programmzeilen lokalisieren können. Das Problem wird durch mehrere (object) Casts in der Datei strong>wp-includes/taxonomy.php verursacht, welche Arrays in Objekte transformieren:

    $wp_taxonomies['category'] = (object) array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['post_tag'] = (object) array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['link_category'] = (object) array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false);
    

    Da weder Fehlermeldungen im Browser noch in den Log Dateien erscheinen habe ich leider keine Idee wieso diese Casts zum Abbruch der Skriptausführung führen. Die installierte PHP Version entspricht der aktuellen stabilen 5.x Version und sollte daher eigentlich nicht die Ursache des Problems sein.
    Um das Problem zu umgehen habe ich eine Methode eingeführt die ebenfalls Arrays in Objekte transformieren kann, welche jedoch nicht auf der PHP Objekt Casting Funktion beruht.

    function arr2obj($arr) {
    	foreach ($arr as $k => $v) $obj -> {$k} = $v;
    	return $obj;
    }
    
    $wp_taxonomies['category'] = arr2obj(array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['post_tag'] = arr2obj(array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['link_category'] = arr2obj(array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false));
    
  • DD Sitemap Generator Plug-in und mehrsprachige Blogs

    (2 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 1 May 2008 Sebastian Thomschke*/?> 3 comments

    Um ein zweisprachiges Blog mit WordPress betreiben zu können, verwende ich das Language Switcher Plug-in. Dieses erlaubt es, durch die Verwendung spezieller Tags in den üblichen Titel und Inhaltsfeldern zu deklarieren, welche Teile in welcher Sprache geschrieben sind (z.B. “[ lang_en]Hello World[ /lang_en][ lang_de]Hallo Welt[ /lang_de]”). Wenn ein solcher Beitrag im Browser angezeigt wird entfernt das Plug-in diese Tags sowie die Inhalte in den nichtausgewählten Sprachen.

    Ich verwende das DD Sitemap Generator Plug-in für WordPress zur automatischen Erzeugung einer Sitemap basierend auf den Beiträge und Kategorien meines Blogs. Auf dieser generierten Sitemap werden jedoch bei den Kategorienamen und Beitragstiteln die Übersetzungen in allen Sprachen auf einmal angezeigt inklusive der speziellen Tags.

    Um dies zu beheben habe ich mich etwas im Code von WordPress und dem Language Switcher Plug-in umgesehen. Das Language Switcher Plug-in entfernt die Tags und überflüssigen Übersetzungen indem es sich der Filters API bedient – eine Art ereignisbasierter RückrufmMechanismus. Plug-ins können Ihr Interesse an bestimmten Textfilterereignissen signalisieren indem sie die Funktion add_filter(the_event_id, the_name_of_a_function_to_callback) unter Angabe der ID eines Filterereignisses und des Namens der aufzurufenden Funktion im Falle des Auftretens des entsprechenden Ereignis. Neben dem Registrieren für Filterereignisse können Plug-ins auch selbst solche Textfilterereignisse auslösen indem sie Funktion apply_filters(the_event_id, the_text_to_be_filtered) unter Angabe einer ID des Filterereignisses und des zu filternden Textes aufrufen. WordPress führt dann alle für dieses Ereignis registrier Filtermethoden auf dem übergebenen Text aus und die apply_filters Funktion gibt als Ergebnis den “gefilterten” text zurück. Wenn WordPress beispielsweise die Titel von Beiträgen oder Seiten darstellt löst es ein Filterereignis mit der ID “the_title” aus. Dies ermöglicht Plug-ins den Titel zu prozessieren/modifizieren bevor er dargestellt wird. Das Language Switcher Plug-in registriert sich daher selbst für dieses und eine Reihe anderer Filterereignisse um mehrsprachig eingegebene Texte vor der Darstellung um die Sprachtags und die nicht relevanten Übersetzungen zu entfernen.

    Leider löst das DD Sitemap Generator Plug-in die entsprechenden Filterereignisse bei der Erstellung der Sitemap nicht aus. Daher ist auch das Language Switcher Plug-in nicht in der Lage die Kategorienamen und Beitragstitel zu bearbeiten.

    Um das Problem zu lösen habe ich daher den Quellcode des DD Sitemap Generator Plug-in analysiert und die fehlenden apply_filters Aufrufe an den entsprechenden Stellen hinzugefügt. Wer ebenfalls von diesem Problem betroffen ist kann sich wie folgt behelfen:

    1. Die Datei <wordpress_root>/wp-content/plugins/sitemap-generator/sitemap-generator.php (oder <wordpress_root>/wp-content/plugins/dd-sitemap-gen/dd-sitemap-gen.php) in einem Editor öffnen
    2. Den folgenden Text lokalisieren
         $tmp_array[‘title’] = $pages[$k]->post_title;
      und ersetzen durch
         $tmp_array[‘title’] = apply_filters(‘the_title’, $pages[$k]->post_title);
    3. Den folgenden Text lokalisieren
         $tmp_array[‘title’] = $cat_data[$c][‘cat_name’];
      und ersetzen durch
         $tmp_array[‘title’] = apply_filters(‘the_category’, $cat_data[$c][‘cat_name’]);
    4. Den folgenden Text lokalisieren
         $tmp_array[‘title’] = $posts[$k]->post_title;
      und ersetzen durch
         $tmp_array[‘title’] = apply_filters(‘the_title’, $posts[$k]->post_title);
    5. Die Änderungen speichern. Das sollte es gewesen sein.

    Mit diesem Verfahren kann man auch andere Plug-ins für ein gutes Zusammenspiel mit dem Language Switcher Plug-in korrigieren.

  • [Behoben] WordPress 2.5 One-Click Plug-in Upgrades – Could not create directory

    (6 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 25 April 2008 Sebastian Thomschke*/?> 42 comments

    Vor einigen Tagen habe ich meine WordPress Installation auf das neue 2.5 Release aktualisiert. Aufgrund meiner Trägheit im Hinblick auf administrative Tätigkeiten wollte ich natürlich auch die neue on-click plug-in upgrade Funktion nutzen um ein paar Plug-ins zu aktualisieren. Allerdings scheiterten alle meine Versuche die Funktion zu nutzen mit der ziemlich nutzlosen Fehlermeldung “Could not create directory”. Daher begab ich mich auf die übliche Netzsuche und bin relativ schnell auf einige Beiträge gestossen, welche die Ursache in unzureichenden Berechtigungen auf bestimmte Verzeichnisse ausmachten. Das manuelle Anlegen des Verzeichnisses /wp-content/upgrade und das “chmodden” auf 777 des selben sowie der Plug-in Verzeichnisse würden das Problem lösen. Leider nicht bei mir. Daher blieb mir nichts weiter übrig als die Ärmel hochzukrempeln und WordPress zu debuggen…

    Lange Rede, kurzer Sinn, ich bin schließlich auf den PHP Bug Report #42739 mkdir doesn’t like a trailing slash when safe_mode is enabled gestossen und es zeigte sich, daß dies genau das Problem war, welches sich mir auf meinem Hosting Account entgegenstellte. Die PHP Option safe_mode war dort aktiviert und WordPress versucht vergeblich mit Schrägstrich endende Verzeichnissepfade anzulegen (z.B. /htdocs/wp-content/upgrade/the-plugin/).

    Nachdem mir der Grund also bekannt war, konnte ich einen Workaround entwickeln und endlich den one-click plug-in updater nutzen. Für alle die das gleiche Problem haben, hier meine Lösung:

    1. Die Datei <wp_root>/wp_admin/includes/class-wp-filesystem-direct.php lokalisieren und in einem Editor öffnen
    2. Nach “function mkdir” in der Datei suchen
    3. Die nachfolgenden Codezeilen in die Methode einfügen. 
      function mkdir($path,$chmod=false,$chown=false,$chgrp=false){
      	if( ! $chmod)
      		$chmod = $this->permission;
      
      	// workaround for http://bugs.php.net/bug.php?id=42739 starts here
      	if(ini_get('safe_mode') && substr($path, -1) == '/')
      	{
      		$path = substr($path, 0, -1);
      	}
      	// workaround for http://bugs.php.net/bug.php?id=42739 ends here
      
      	if( !@mkdir($path,$chmod) )
      		return false;
      	if( $chown )
      		$this->chown($path,$chown);
      	if( $chgrp )
      		$this->chgrp($path,$chgrp);
      	return true;
      }
    4. Mit der Ein-Klick-Aktualisierung beginnen!

    Nachtrag:

    1. Die Änderung funktioniert auch mit WordPress 2.5.1
    2. Falls diese Änderung nicht zum gewünschten Erfolg führt, kann der Fehler noch eine zweite Ursache haben. Daher sollten die Berechtigungen des Verzeichnis /wp-content/upgrade/ und dessen Unterverzeichnisse überprüft und gegebenenfalls per chmod auf 777 gesetzt werden. Falls das upgrade Verzeichnis gar nicht existieren sollte, reicht es vielleicht schon dieses einfach manuell anzulegen.

    Nachtrag 2:

    1. Falls sich das Problem weiter besteht sollte geprüft werden ob das Plug-in AskApache Password Protect installiert ist.
    2. Wenn ja, kann es helfen, dieses vor dem Aktualisieren anderer Plug-ins zu deaktivieren.

  • myPodder – ein mobiler Podcatcher

    1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 20 April 2008 Sebastian Thomschke*/?> 1 comment

    Vor zwei Wochen habe ich zum ersten Mal damit begonnen, Podcasts ernsthaft auszuprobieren – bis jetzt hauptsächlich Aufzeichnungen vom Deutschland Funk (http://www.dradio.de/podcast/). Ich habe mir die Audiodateien zu interessant klingenden Themen heruntergeladen und auf dem Weg zum/vom Büro in der U-Bahn angehört. Das hat wirklich Spaß gemacht – insbesondere da ich mir nun die Berichte und Diskussionen anhören konnte die mich wirklich interessieren und ich nun nicht mehr an deren Sendezeiten gebunden war. Allerdings fand ich es ziemlich umständlich erst auf der Webseite nach den einzelnen Podcasts zu suchen, diese dann einzeln auszuwählen, herunterzuladen und schliesslich auf meinen schicken Samsung T9 zu überspielen.

    Auf der Suche nach möglichen Programmen die diesen Prozess vereinfachen könnten bin ich auf die Software myPodder gestossen. Diese wird kostenlos von Podcast Ready bereitgestellt. Podcasts Ready stellt einen Onlinekatalog verfügbarer Podcasts unterschiedlichster Quellen bereit und zu meiner Überraschung waren auch die Podcasts des Deutschlandfunks aufgeführt. Das interessante an ihrer Software ist die Tatsache, daß sie sich direkt auf Audioplayern installieren läßt und man diese so konfigurieren kann, daß sie beim Anschliessen des Players an einen Computer automatisch startet. Somit kann man auf einfachste und sehr komfortable Weise über quasi jeden internetfähigen Computer seinen Player mit neuen Podcasts bestücken. Read the rest of this entry »

  • Meine favorisierten WordPress Plugins & Ressourcen

    (2 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Loading...
    Posted on 30 September 2007 Sebastian Thomschke*/?> 3 comments

    Jetzt, da ich ein paar Erfahrungen mit WordPress sammeln konnte, habe ich eine Liste meiner favorisierten WordPress Plug-ins und Tutorials zusammengestellt:

    Read the rest of this entry »