WARNING - deployment receiver is DANGEROUS

[ftoth]

Hi again,

Not one response from Alfresco on my previous post, eh?

I know a little bit more about this now. It's completely repeatable, and has
to do with, apparently, only the initial deploy to a "fresh" deployment receiver.

Be very cautious when you define the value for "root" in the targetData
property. It should be a completely empty directory, except for a
single sub-directory named "ROOT". If you have any files in either the
target directory or in the ROOT subdirectory that are not managed by
alfresco, the deployment receiver will remove them for you on the first
deployment.

It seems that the first deployment is the key. The deployment receiver must
establish some sort of base-line from that first run. Afterwards, you can
add non-Alfresco stuff and it won't be deleted.

At least as far as I know. I wish I could be sure of this last point.

What happened to me:

My web site's root was "/usr/www/ROOT". As I mentioned before, I am
using Alfresco for only a small subset of the site. So /usr/www was
filled with lots of stuff, as was, of course, /usr/www/ROOT.

I set "target" to "/usr/www".

I created a single folder with 2 files in Alfresco and did a deploy.

The files deployed nicely. And the deployment receiver deleted
everything in /usr/www and in /usr/www/ROOT except for the newly
deployed files.

I'd call this a very dangerous bug!

Thanks,

Fred

[vijay_alfresco]

It depends on where you set the target, for example

If you have created a webproject (website1) and want to maintain within Alfresco WCM then you need to have complete project in Alfresco WCM and while setting the deployment folder, make sure it deploys to the correct location

like, in Tomcat, the webapplication should go to

…webapps\website1 and alfresco will manage(delete, update, add..etc) the content within this website1 only.


–Vijay

[ftoth]

By default, WCM wants to deploy to "ROOT", right?

So, by your logic, like in tomcat, you would want deployment to
go to "/webapps/ROOT". To accomplish this, you have to set the
deployment receiver's target to "/webapps".

What I'm calling a bug is that, if you do the above, the deployment
receiver will happily delete everything else under /webapps. If you happen
to have other webapps there, they're now gone.

This is not a bug?

Thanks,

Fred

[mikeh]

It does sound like a bug.

Please raise in JIRA.

Thanks,
Mike

[vijay_alfresco]

Actually, I have extended alfresco to edit the ROOT webappfolder while creating the webproject, you can find this at

http://forums.alfresco.com/viewtopic.php?t=9499

and hence I can specify the target as ….webapps/website1, so that only the
website1 will be managed and not entire webapps.

[kvc]

Everyone:


Alfresco ensures that when you deploy a snapshot, what you get on the remote end is what you have in your snapshot, excepting for any limitations you put on source path and excludes (newly exposed in our upcoming 2.2 in our new deployment configuration wizard). 

Whether deploying to a remote file system or remote Alfresco server, the sending server connects and verifies what snapshot exists on the second machine.  If everything is OK, the sending side calcs deltas and send over a stream of files (to elimate unnecessary over the wire comparisons).  It then snapshots the remote server, which in the case of a remote FS receiver means updating book-keeping entries (computed hash values to compare in future deployments) to note the transactionally delivered snapshot.

If you are deploying for the first time, or if something is awry in the remote server such that the snapshot it thinks it has is not indeed correct (site was hacked files were removed, for example), Alfresco does a FULL synchronization.  That includes what you saw; it removes things that as far is it knows should not be there.

The server does source regex excludes in the event you do need to deploy your content to a root source but leave certain non-managed files or directories on the remote end.  That capability is not exposed for configuration via our GUI until release 2.2 in the next few weeks.

The deployment receiver is doing exactly as intends; it is dangerous only in that if not targeted in the right way with the right config, you will get exactly what it's intended to do.  If it succeeds, what you thought you were deploying it exactly what is on the other server.

I will take note to put a warning in our wiki that what transactional deployment means is that the remote server is essentially slave to the sending server.  Whatever your target directory is, do take care:  aside from our 2.2 excludes, that directory is a strongly managed one.


Kevin

[ftoth]

Thanks for your explanation, Kevin. However, this behavior is a
show-stopper for me. Here's why…

Let me start with observed behavior:

1. On an initial deploy, the receiver will synchronize completely. This
means that anything under the target that alfresco doesn't know about
will be removed. If your target happens to be <tomcat_home>/webapps,
you will lose all of your webapps other than ROOT. And ROOT will
be cleaned out of any extra files.

2. After the intial deploy, however, this extra synchronization no longer takes
place. The target can have any number of non-alfresco files and folders
and the deployment receiver will ignore them.

Until your post, I thought #1 was a bug, but #2 was a work-around
I could live with. According to your post, #2 may well be a bug! You're
warning us that the target is "strongly managed". So it sounds like
I can't rely on #2. Some future version might allow later deploys to
delete non-alfresco stuff.

As I've mentioned before, we are attempting to manage just a portion
of our site with alfresco. For example, we have several high-level
categories, "news", "reviews", "research", "reports", etc. We are
attempting to deploy alfresco to help manage our "news" section.

It appears that I have to abandon the deployment receiver, or wall it
off somehow in a safe sandbox where it can't do any harm to the rest
of my site.

So one engineer, Mike, said that #1 was a bug and asked me to raise
a JIRA issue. http://issues.alfresco.com/browse/WCM-996

Now Kevin has said #1 is not a bug and observed behavior #2 may not
be reliable.

Further clarification would we welcome.

Thanks,

Fred

[kvc]

Fred:


Yes, #2 is the bug … #1 is expected behavior.

Aside from exposing exclude paths in our 2.2 deployment config wizard, there are probably two other enhancements to note here for future releases:

*  Expose ability to 'test' deployments.  The server supports a dry-run
    facility to show what would deploy if it really did.  You'd have been
    able to catch the unexpected (even if intended) behavior in that case.
    That capability even in 2.2 is not exposed in the web client.

*  Support a 'dont_delete' option.  This was intended to be in the
    original version of the FSR, but ultimately it did not make the cut.
    Really, although we are doing what we think is the right thing, you
    may want different behavior.  It should be a configuration option.

And I do apologize for your troubles.  At a minimum, this points to
better documentation on our wiki so that others know what to expect
when deployment happens.

And in advance of that, your sharing your experience on the forums is
appreciated.  I hope everyone is reading this thread!!!


Kevin

[scottf]

Hi,
I am seeing the same behaviour at the moment and I am using the recent ENT 3.1 release.

Is there a solution to this problem?

Like Fred I am using Alfresco to manage only the static content of my site, so cannot have the FSR deleting non-alfresco content when deploying snapshots.

Kevin, if you are around can you shed some light on if there has been any progress on this for 3.1? or is this still the behaviour? Is it configurable at all? you mentioned a "do not delete option"?

Fred, if you are still around, how did you address this problem?

Thanks for any help.

[mrogers]

http://wiki.alfresco.com/wiki/FSR

The behaviour of the FSR was changed in the 3.0 to only delete content managed by Alfresco.    Are you using a V3 FSR?      

When you start up a V3 FSR you should see messages in the log relating to validating the filesystem.