My suggestion is to check if somebody tries to add whole /var to tukit.conf and bail out with an hard error.
With all the required special handling of /var, this has to fail and will only break the system.

Axel, the correct way would be to fix your RPM to be FHS conform (FHS clearly states, that all data below /var will be generated at runtime of the program, not installed by a package, and that the package can scope with the fact, that somebody deletes the files in /var), the second best option is to only mount /var/www, not full /var.

But all this broken packages will vanish hopefully quickly anyways, as they don't work with any of the new concepts (e.g. see https://www.uapi-group.org).

(In reply to Thorsten Kukuk from comment #1)

> Axel, the correct way would be to fix your RPM to be FHS conform (FHS
> clearly states, that all data below /var will be generated at runtime of the
> program, not installed by a package, and that the package can scope with the
> fact, that somebody deletes the files in /var), the second best option is to
> only mount /var/www, not full /var.

The package maintainer is following upstream to install under /var/www/html
 
> But all this broken packages will vanish hopefully quickly anyways, as they
> don't work with any of the new concepts (e.g. see
> https://www.uapi-group.org).

(Certificate error)

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-filesystem-fhs#s3-filesystem-var does IMO not deny to install in /var/www.
Current location was triggered after the discussion in boo#1204307

So we have 2 point:
- you are saying that /var/www is the wrong place - which is the right one?
- that still does not justify that automount of /var deletes everything....

(In reply to Axel Braun from comment #2)

> So we have 2 point:
> - you are saying that /var/www is the wrong place - which is the right one?

There is no correct one, this depends on the use case. But everything delivered by an RPM and outside /usr will create problems.

> - that still does not justify that automount of /var deletes everything....

That the package does not follow FHS does not justify it, correct, but that you mount /var on a t-u system justifies that you loose data.
That's unavoidable, as t-u needs /var but you overwrite it with an outdated version.
That's why I suggested to Ignaz to abort with a hard error if somebody makes this mistake and to you to only mount /var/www, not complete /var.

Between, I would not follow RHEL5 documentation, that's like following SLES10 or openSUSE 10.3 documentation, completely outdated.

> Current location was triggered after the discussion in boo#1204307

And in this discussion I wrote that /var/www is the same bad idea then /srv/www.

(In reply to Axel Braun from comment #2)
> - that still does not justify that automount of /var deletes everything....

I'll have a look at it at least, though it's likely it will end up implementing Thorsten's suggestion to just abort if the complete /var is supposed to be bind mounted.

How to deal with the issue that e.g. /var/www can not be mounted inside a t-u shell as long as its not a separate partition (error message: not in fstab) ?

Just add BINDDIRS[1]="/var/www" to /etc/tukit.conf - or am I missing something?

(In reply to Ignaz Forster from comment #6)
> Just add BINDDIRS[1]="/var/www" to /etc/tukit.conf - or am I missing
> something?

That seems to work - but not manually with 'mount'