Rewrite in Apache does not work anymore

Installed Apache on Suse Linux 10. Configured httpd.conf including a rewrite rule in a virtual host.

No configuration errors, but it did not work at all! After a while I discovered that the mod-rewrite module had been installed, but not  enabled with this version of Apache (2.2.x). This URL gives a pretty good hand-out how to do this. Because I’m not sure this link will last for ever, a copy of (part of) the text in it with a small addition of my side:

  1. Edit the file /etc/sysconfig/apache2 as root:
    1. search for APACHE_MODULES, you should find a line like this
      APACHE_MODULES="suexec access actions alias auth auth_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif userdir ssl php4"
    2. Add rewrite to the content in the list between the “
  2. Save the changes and quit
  3. run /etc/init.d/apache2 restart to restart the Apache server
  4. run SuSEconfig to update the apache configuration files

Now, the mod_rewrite is enabled and integrated.


By | June 21st, 2010|Categories: App. Server|Tags: , , |0 Comments

While migrating discoverer sso-connections, ‘ssomig’ hangs

Helped a collegae who was migrating a discoverer configuration to another node with a different version (from 10.1.2 to 10.1.4) with now a 10.2 – infrastructure database in a separate home. The OID-users were already successfully migrated, with a little help of the example-script here, but one of the problems was that discoverer didn’t use the single-sign on. The other was that the private and public connection users had made, had disappeared.

By enabling Single Sign-On for Discoverer (is not default when installed) the first problem had been solved:


By | May 30th, 2010|Categories: App. Server|Tags: , , |1 Comment

How firefox 3.6 accelerates the phasing out of Jinitiator (and frustrates Metalink..)

Customer using Webforms, Application Server with Jinitiator on the client. Planning to upgrade the client to Java 6.17 / 6.18, so these java-versions are already installed on the clients. We’re testing the java-configuration on the web-server (formsweb.cfg), but production still works with the old Jinitiator.

Also the customer is using Firefox, 3.5 in this case, and Internet Explorer (6!). Suddenly the application does not work anymore for a lot of clients, as a matter of fact, the firefox-users.

They had upgraded their Firefox to 3.6., and got the message that an add-on must me installed ( appears to be the JRE  / Jinitiator) . After installing this, it still does not work.

The answer comes from here :  no more Java < 6.10 anymore in  Firefox 3.6 and above…. So the plans we had for upgrading JRE to Java 6.17 or 6.18, we have to accelarate these… No  more Jinitiator.

By the way: ever tried to open notes in  Metalink with Firefox 3.6 ? Does not look nice.  Following  this item at the support page of Mozilla.

By | March 15th, 2010|Categories: App. Server|Tags: , , , |0 Comments

Suse 10 and OAS, The Oracle at Delphi

Simple question:  is Oracle Application Server with Forms and Reports certified on Suse Linux 10.  The customer is forced to move to Suse 10, and is not quite happy to upgrade to, for that could have numerous consequences for Forms, Designer, Java etc.

The OTN-note about this implies it is not certified. But when you read this thoroughly, there’s an escape:

72     “Oracle Identity Management and OracleAS Metadata Repository” and “OracleAS Metadata Repository” installation types are not supported due to the fact that the 10gR1 database that comes with seeded Metadata Repository is not supported on this platform.

73     SLES 10 is supported with patchset and higher.  For additional information regarding installation, applicable patches, and operating system requirements please refer to MetaLink note number 947193.1 on My Oracle Support.


By | February 16th, 2010|Categories: App. Server|Tags: , |0 Comments

Logrotating of files like default-web-access.log with help of Linux

What to do about the ever growing files on Oracle Application Server as:

and more..

These files are not logrotated (at least in the ‘older versions’ of OAS) and cannot always be deleted or renamed manually on a ‘normal’ way (I know, there is a way..), and it must be scripted to avoid extraordinary large log-files.
Quite annoying, until Frits Hoogland pointed me at a standard Linux-functionality, ‘logrotate’.

For example, to logrotate the files default-web-acces.log and server.log in the directory  $ORACLE_HOME/j2ee/home/log/home_default_island_1, create a script like this:


/software/oracle/product/10.2/middle/j2ee/home/log/home_default_island_1/*.log {
maxage 30
rotate 7


(an explenation of these parameters follows at the bottom of this post,  pay special attention to ‘copytruncate’, which is very suitable for several files of the application server.)

This script should be (on Linux) in /etc/logrotate.d/  (as root).   Call it ‘ora_logrotate’ for example.
The Linux-program ‘logrotate’  is daily executed (from /etc/cron.daily/) and will run the scripts in /etc/logratate.d .

You can test this manually by running it like ‘/etc/cron.daily/logrotate ora_logrotate’. The file ora_logrotate will be executed when it is place in /etc/logrotate.d .
When there is a standardised environment you can also make a script like this:


By | October 27th, 2009|Categories: App. Server|Tags: , |0 Comments