rvdb's questions

I'm trying to set up a space-efficient rotating backup scheme with rsnapshot / rsync from a server to a Hetzner storagebox. I'm having a hard time understanding how hard links on the destination are affecting the disk usage being reported. In short: even though hard links seem in place on the backup destination, they don't seem to be taken into account in disk usage, but instead counted as full files.

Since the destination folder of rsnapshot must be on the local file system, I have set up a workflow consisting of 2 parts:

1. create a local snapshot with rsnapshot, in a local folder on the source server
2. rsync that local snapshot over SSH with rsync to the destination

That seems to work well and fast, but I have one concern: disk usage reported on the destination (with du -sh) seems to cumulate the size of all snapshots, even though they seem to have been copied properly using hard links. Note: since Hetzner storageboxes don't allow interactive SSH login, I'm inspecting this backup destination as a mounted volume with CIFS.

For example, after 3 rounds of this rsnaphsot + rsync combo, the destination folder contains daily.0, daily.1, and daily.2 folders. When checking random files in those snapshot folders for hard links, I do get expected results:

1. find /mnt/user.your-storagebox.de/rsync-backup/ -name "output.file" -print0 | xargs -0 ls -li:

   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.1/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.2/home/user/output.file
   

   returns 3 files with identical inodes, and a link count of 3 (as expected)

2. find /mnt/user.your-storagebox.de/rsync-backup/ -samefile /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file

   /mnt/user.your-storagebox.de/rsync-backup/daily.0/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.2/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.1/var/tomcat/vhosts/output.file
   

   returns 3 files (as expected)

I guess this indicates that these snapshots have been properly copied to the destination as hard links.

Yet... when checking their disk usage on the destination location: du -sh /mnt/user.your-storagebox.de/rsync-backup, a value of 12G is returned. This is unexpected, since the original source folder only is about 4G. Apparently, disk usage is calculated cumulatively, despite the hard links?

OTOH, when inspecting the destination folder via rsnapshot du, I'm getting output that does seem to take hard links into account:

4.3G    /mnt/user.your-storagebox.de/rsync-backup/daily.0/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.1/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.2/
4.3G    total

This is confusing: either the snapshots are being copied with hard links, and should take up minimal space (which seems to be the case when inspecting the inodes), or they are not and are taking up much more space than expected (as suggested by the du -sh output).

My main concern is: is the disk usage reported on this mounted volume correct or nog? Are there any caveats w.r.t. the use of du -sh on mounted volumes I should be aware of?

After installing the latest Java 7 Development Kit (Java SE 7u11) on my Windows 7 Professional 32bit PC with 4Gb RAM, I noticed I can't allocate much memory for Tomcat.

Whereas these memory settings worked for Java Development Kit 6u38:

set JAVA_OPTS=-server -Xms978m -Xmx978m -XX:MaxPermSize=512m

...when run with jdk7, these settings cause the Tomcat launcher to exit with following error message:

Error occurred during initialization of VM

Could not reserve enough space for object heap

Error: Could not create the Java Virtual Machine.

Error: A fatal exception has occurred. Program will exit.

I tried lowering the Xms and Xmx settings, and apparently, it won't work with more than 512m:

set JAVA_OPTS=-server -Xms512m -Xmx512m -XX:MaxPermSize=512m

Yet, systeminfo |find "Available Physical Memory" tells me that I have 1200mb available memory.

Has anything changed w.r.t. memory management of Java 7, and does this mean that Java 7 can only work with lower amounts of memory?

Thanks for any advice,

Ron

I am setting up a reverse proxy configuration where all requests whose path starts with '/apps/' should be proxied by Apache to Tomcat. This IMO has 2 benefits: it makes it possible to reserve proxying to only the '/apps/' part of the URI space, and to use only a single proxy rule for all Tomcat apps (i.e. requests for any Tomcat app should just start with '/apps/').

For example, requests for http://mydomain/apps/my_app/ should be proxied to http://localhost:8082/my_app/. Note the absence of the '/apps/' prefix in the Tomcat URI: 'my_app' lives in the regular location at ${CATALINA_HOME}/webapps/my_app.

I have achieved this using following Proxy rules in an Apache vhost.conf file:

ProxyPreserveHost    on
ProxyPass            /apps/    http://localhost:8082/
ProxyPassReverse    /apps/    http://mydomain/

(Note: I have used ProxyPreserveHost since my Tomcat app needs access to the original host to generate further links). All goes well, except for absolute links that are generated by one part of my Tomcat app. Given above configuration, my Tomcat app will 'see' this request: http://mydomain/my_app, and hence generate links without the '/apps/' prefix that should trigger proxying for those links.

It took me some time, but I understand now that this is essential characteristic of proxying, and that there's no 'standard' way to pass on that '/apps/' prefix of the original request to the proxied app. Hence, I started to investigate another possibility, namely defining a global prefix for all Tomcat apps, and proxy the Tomcat apps with following settings:

ProxyPreserveHost    on
ProxyPass            /apps/    http://localhost:8082/apps/
ProxyPassReverse    /apps/    http://mydomain/apps/

This would proxy requests for http://mydomain/apps/my_app/ to http://localhost:8082/apps/my_app/. Since all apps on the Tomcat server will be accessed behind a proxy, I have no problem that this '/apps/' prefix will be required for all Tomcat apps.

So far, so good. Yet, I am struggling with the Tomcat side of this approach: finding a way to add a global path prefix for requests to Tomcat apps. The closest I got was this: 1. don't touch the physical location of the Tomcat apps: leave them at ${CATALINA.HOME}/webapps 2. change ${CATALINA.HOME}/conf/server.xml as follows:

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="false" deployOnStartup="false">
  <Context path="/apps/my_app" docBase="/my_app/" reloadable="true"/>
</Host>

While this makes the my_app Tomcat app accessible at http://localhost:8082/apps/my_app/, it also suggests that all Tomcat apps should be defined manually in a separate element. This makes it less flexible to add new Tomcat web apps (and would actually mean more configuration work than declaring separate proxy rules for each app in the Apache configuration, without the '/apps/' prefix). I tried this:

<Context path="/apps" docBase="/" reloadable="true"/>

(and @docBase variants such as "", or "."), but this doesn't work: no indication of any webapps being deployed in the Tomcat console output, and all requests return a 404 error.

Hence my question: is there a simple(r) way of 'declaring' a global URI prefix for Tomcat webapps?

Any advice much appreciated!

Ron

I'm struggling with reverse proxying an app running in a Tomcat server on a closed port behind Apache. For convenience, say that I want to reverse proxy requests for 'http://mydomain/apps/my_app/' to the Tomcat app at 'http://localhost:8082/my_app/' on the remote server. All works fine with following proxy settings in an Apache vhost.conf file:

ProxyRequests       off
ProxyPass /apps/    http://localhost:8082/
ProxyPassReverse /apps/  http://localhost:8082/

Except for one part of the app, which generates a Java webstart file that is to be executed on the client and needs to make a connection to the Tomcat app at 'http://localhost:8082/my_app/webstart' (on the remote server).

Crux of the problem is that this connection obviously won't work, since a) the request for localhost will be interpreted relative to the client computer, and b) even if it would point to the remote server, port 8082 is closed there.

Hence, I figured out how ProxyPreserveHost can come to help, so that the host name of the original request will be propagated to the Java webstart request:

ProxyRequests       off
ProxyPreserveHost   on
ProxyPass /apps/    http://localhost:8082/
ProxyPassReverse /apps/  http://mydomain/

This works (even internal redirections in the proxied Tomcat app work by grace of the ProxyPassReverse setting)... almost. One problem remains: the URL that is used by the Java webstart file is missing the '/apps/' part, and will try to connect to 'http://mydomain/my_app/webstart', instead of 'http://mydomain/apps/my_app/webstart', wich will obviously fail since only requests starting with /apps/ are reverse proxied. Apparently, the proxied app does not 'see' the full original URL ('http://mydomain/apps/my_app/'), but only the part that's filtered out by the Proxy handling ('http://mydomain/my_app/').

Is there any Proxy setting I forgot that can make Apache pass on the path from the original URL to the proxied app?

Kind regards,

Ron

I am configuring an Apache HTTP server so it reverse proxies requests starting with /app/ to an eXist-db instance running in a Tomcat server, on port 8082. This port has been closed in the firewall and is inaccessible to the outer world. Following the eXist documentation, I have following rules in place in my httpd.conf file:

ProxyPass           /apps/  http://localhost:8082/
ProxyPassReverse    /apps/  http://localhost:8082/
ProxyPassReverseCookiePath /apps/ /

All goes well for requests to e.g. 'http://mydomain/apps/exist/index.xml'. Yet, the webstart client (accessible at 'http://localhost:8082/exist/webstart/exist.jnlp' on the web server) doesn't work behind the proxy. While 'http://mydomain/apps/exist/webstart/exist.jnlp' does generate a valid exist.jnlp file, that file can't be executed. The reason seems quite obvious: apparently, the eXist-db instance generating the exist.jnlp file only sees the proxied request as: 'http://localhost:8082/exist/webstart/exist.jnlp'. Yet, since the exist.jnlp file is executed on the client, that reference is meaningless (unless the client computer happens to have an eXist-db instance running on that port). Executing the exist.jnlp file hence fails with a 'connection refused' error.

Yet, there's no problem at all connecting a local eXist-db Java client to the proxied eXist instance with the URL xmldb:exist://mydomain/apps/exist/xmlrpc. The problem lies in generating the webstart exist.jnlp file, which seems to need access to a publicly accessible URL. However, opening port 8082 and replacing the Proxy references to 'http://localhost:8082' with 'http://mydomain:8082' IMO rather destroys the point of reverse proxying.

Do others have had success reverse proxying eXist-db on a closed port behind Apache? Are there perhaps some Proxy configuration settings I have overlooked (I'm no expert at all) that can make eXist see the original request instead of the proxied one?

Kind regards,

Ron

[edit]: FWI, thanks to Vadym's comment below, I discovered that I had overlooked to enable mod_proxy_http on my Plesk server. Loading this module (alongside mod_proxy) fixed the original error.

I'm trying to configure reverse proxy rules in vhost.conf. I have Apache-2.2.8 on Ubuntu-8.04, monitored by Plesk-10.4.4.

What I'm trying to achieve is defining a reverse proxy rule that defers all traffic to -say- http://example.com/tomcat/ to the Tomcat server running on port 8080. I have mod_rewrite and mod_proxy loaded in Apache. As far as I understand mod_proxy docs, entering following rules in /var/www/vhosts/mydomain/conf/vhost.conf should work:

<Proxy *>
  Order deny,allow
  Allow from all
</Proxy>

ProxyRequests off
RewriteRule ^/tomcat/(.*)$ http://example.com:8080/$1 [P]

Yet, I am getting a HTTP 500: internal server error when requesting above URL. (Note: I decided to use a rewrite rule in order to at least get some information logged.)

I have made mod_rewrite log extensively, and find following entries in the logs [note: due to a limitation of max. 2 URLs in posts of new users, I have modified all following URLs so that they only contain 1 slash after http:. In case you're suspecting typos: this was done on purpose):

192.0.2.23 - - [19/Mar/2012:16:42:59 +0100] [example.com/sid#b06ab8][rid#1024af8/initial] (2) init rewrite engine with requested uri /tomcat/testApp/
192.0.2.23 - - [19/Mar/2012:16:42:59 +0100] [example.com/sid#b06ab8][rid#1024af8/initial] (3) applying pattern '^/tomcat/(.*)$' to uri '/tomcat/testApp/'
192.0.2.23 - - [19/Mar/2012:16:42:59 +0100] [example.com/sid#b06ab8][rid#1024af8/initial] (2) rewrite '/tomcat/testApp/' -> 'http:/example.com:8080/testApp/'
192.0.2.23 - - [19/Mar/2012:16:42:59 +0100] [example.com/sid#b06ab8][rid#1024af8/initial] (2) forcing proxy-throughput with http:/example.com:8080/testApp/
192.0.2.23 - - [19/Mar/2012:16:42:59 +0100] [example.com/sid#b06ab8][rid#1024af8/initial] (1) go-ahead with proxy request proxy:http:/example.com:8080/testApp/ [OK]

This suggests that the rewrite and proxy part is processed ok; still the proxied request produces a 500 error. Yet:

• Addressing the testApp directly via http://example.com:8080/testApp does work.
• The same setup does work on my local computer.

Is there something else (Plesk-related, perhaps?) I should configure?

I previously had successfully set up a VPN connection that allowed my computer (Windows 7 Professional) to connect to a remote server. Last week, we had to reset our Lynksys WRT54GL wireless router, after which the VPN connection doesn't work anymore.

The problem clearly lies with the WRT54GL router: I still can establish a VPN connection with a wired connection that bypasses the router, or on my home WIFI. OTOH, when attempting either wireless or wired via the WRT54GL router, the message "port opened" is followed for a long time by "connecting to [vpn address] using WAN Miniport (PPTP)", next "connecting to [vpn address] using WAN Miniport (SSTP)", and finally "connecting to [vpn address] using WAN Miniport (L2TP)". In the end, an error code 800 is returned.

I'm no sysadmin wizard at all, and can't see what should have changed in the router configuration. Any help much appreciated, it's driving me crazy.

Ron

I am maintaining a growing base of mainly Cocoon-2.1-based web applications [http://cocoon.apache.org/2.1/], deployed in a Tomcat servlet container [http://tomcat.apache.org/], and proxied with an Apache http server [http://httpd.apache.org/docs/2.2/]. I am conceptually struggling with the best way to deploy multiple web applications in Tomcat. Since I'm not a Java programmer and we don't have any sysadmin staff I have to figure out myself what is the most sensible way to do this. My setup has evolved through 2 scenarios and I'm considering a third for maximal separation of the distinct webapps.

[1] 1 Tomcat instance, 1 Cocoon instance, multiple webapps

-tomcat
  |_ webapps
     |_ webapp1
     |_ webapp2
     |_ webapp[n]
     |_ WEB-INF (with Cocoon libs)

This was my first approach: just drop all web applications inside a single Cocoon webapps folder inside a single Tomcat container. This seemed to run fine, I did not encounter any memory issues.

However, this poses a maintainability drawback, as some Cocoon components are subject to updates, which often affect the webapp coding. Hence, updating Cocoon becomes unwieldy: since all webapps share the same pool of Cocoon components, updating one of them would require the code in all web applications to be updated simultaneously.

In order to isolate the web applications, I moved to the second scenario.

[2] 1 Tomcat instance, each webapp in its dedicated Cocoon environment

-tomcat
  |_ webapps
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp[n]
        |_ WEB-INF (with Cocoon libs)

This approach separates all webapps into their own Cocoon environment, run inside a single Tomcat container. In theory, this works fine: all webapps can be updated independently.

However, this soon results in PermGenSpace errors. It seemed that I could manage the problem by increasing memory allocation for Tomcat, but I realise this isn't a structural solution, and that overloading a single Tomcat in this way is prone to future memory errors.

This set me thinking about the third scenario.

[3] multiple Tomcat instances, each with a single webapp in its dedicated Cocoon environment

-tomcat
 |_ webapps
    |_ webapp1
       |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp2
        |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp[n]
       |_ WEB-INF (with Cocoon libs)

I haven't tried this approach, but am thinking of the $CATALINA_BASE variable. A single Tomcat distribution can be multiply instanciated with different $CATALINA_BASE environments, each pointing to a Cocoon instance with its own webapp. I wonder whether such an approach could avoid the structural memory-related problems of approach [2], or will the same issues apply?

On the other hand, this approach would complicate management of the Apache http frontend, as it will require the AJP connectors of the different Tomcat instances to be listening at different ports. Hence, Apache's worker configuration has to be updated and reloaded whenever a new webapp (in its own Tomcat instance) is added. And there seems no way to reload worker.properties without restarting the entire Apache http server.

Is there perhaps another / more dynamic way of 'modularizing' multiple Tomcat-served webapps, or can one of these scenarios be refined?

Any thoughts, suggestions, advice much appreciated.

Ron