OD Receiver restrict allowed file extensions?

Howdy,

OpenDeploy 5.6

I got the following query from the owner of our production web servers. Since I don't have access to any of the OD manuals, I don't think I can give a definitive response.

"Is it possible to define what file types are or are not allowed in the receiver configuration file?" For example, set up the receiver to reject requests to deploy any .exe or .dll file.

I can understand the request, as all binary files are deployed through a separate, non-TS process, which this person owns. So, he wants to make sure that we don't overwrite his changes with any "temporary" versions we may have in TeamSite to enable preview.

My initial thought from looking through the odserver56.dtd is that the answer is no. But I would be pleased to be wrong in this case.

Jonathon
Independent Interwoven Contractor

Find more posts tagged with

Comments

Migrateduser

> he wants to make sure that we don't overwrite his changes with any "temporary" versions we may have in TeamSite to enable preview.

Can you remove these from TeamSite and configure IW proxy so that they redirect to an appropriate location, or do they have to exist in TeamSite?

Dwayne

I don't believe that this is possible on the receiver. It's certainly possible to configure the deployment on the base to exclude those files, but I don't know of any way on the receiver to enforce that restriction.

Unless, of course, you want a Rub-Goldberg-like creation, where the the receiver isn't a receiver at all, but another base server, and the deployments go into a "mirror" location. It would then be the responsibility of deployment writers on the "real" source to invoke a subsequent deployment on the target machine to deploy to the "live" location. Since that deployment config would be on the destination server, you'd have more confidence that it was set up properly to filter out the undesirable files.

--

Current project: TS 5.5.2/6.1 W2K

JonathonG

We can probably do the cleanup from TeamSite, but (and I didn't include this above) the web server owner is a bit paranoid, because we just had someone "oops" and deploy a bunch of files that shouldn't have been deployed to our staging environment. If it had been production, it would have been really bad. So, he's looking for some way that he can, from his end (as the owner of the receiver files), prevent this from happening again.

I feel a bit of a need to explain a little further how this "oops" happened. This will take a bit, so feel free to skip this if you don't care. Basically, we have a farm of servers that we always deploy to using file list deploys. Some of these servers live behind a firewall. We upgraded to new hardware on our TS server and thus needed the firewall ports opened. The firewall owners needed a 2-week turnaround to get this done. So, there was a period of time during which we had to take this set of servers out of our deployment configurations (otherwise the whole deployment would fail). We decided that the best thing to do would be just to run a directory comparison deployment from TeamSite to sync things back up once the firewall was fixed. Well, I said we should do a simulated deploy first, but I wasn't clear about the reason for that. So, the person who ran it thought the simulate was just to check the connection, when I meant that we should look at what files it was going to deploy and make sure they were the right ones. Well, he didn't check that, and he had date_different="t" set. So, we deployed a whole bunch(~2000) of old files, and thus broke things on those servers. So, if you've read this far, you can probably understand why the server owner is concerned. Like I said above, we usually use filelist deploys, so I haven't been overly concerned about having these old files around (many of them are from a year-old copy of the website that someone brought into TeamSite just to see how quickly they could get it up).

Jonathon
Independent Interwoven Contractor

JonathonG

I don't believe that this is possible on the receiver.

Thanks for the confirmation.

Unless, of course, you want a Rub-Goldberg-like creation

Um, thanks, but no thanks. I don't think its worth that much effort/cost/maintenance/overhead. But, if we get desperate, I'll think about it some more.

Jonathon
Independent Interwoven Contractor

Migrateduser

If they only need to be in workareas, maybe configure autoprivate?

JonathonG

Yeah, that would probably work. But the point of the question was so the webserver owner could own the restriction. Any TeamSite solution won't completely satisfy him, because he doesn't own that.

Jonathon
Independent Interwoven Contractor

Migrateduser

I guess it's a feature request...

Reuse Totals.rptdesign

JonathonG

Yeah...and maybe if Todd sees this thread, he'd be willing to file it. As I've stated in other threads, opening a feature request is not something I'm able to do. The group here that owns the support contract doesn't like to open support cases

Jonathon
Independent Interwoven Contractor

Adam Stoller

So you're looking for something like a global-to-receiver filter list that could be placed in the odrcvr.xml / odbase.xml (as opposed to the deployment configuration file itself) where you could tell the receiver to skip the sending of any files that match a certain path or pattern - yes?

Interesting idea, especially in those environments (like yours apparently) where the web server / receivers may be "hosted" by a 3rd party who doesn't have control over the deployment configurations being using on the base servers.

I have to agree that I don't think that's possible to do in OD 5.6, and I don't think it's possible to do in OD 6 either - though it might be (I haven't completely come to grips with all the new features and pieces of OD6 yet)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

So you're looking for something like a global-to-receiver filter list that could be placed in the odrcvr.xml / odbase.xml (as opposed to the deployment configuration file itself) where you could tell the receiver to skip the sending of any files that match a certain path or pattern - yes?

Yes. Although, it could also work as an extension to the "allowedDirectories" functionality. Something like an "excludedPatterns" tag in the odrcvr.xml. Then, if the sender tried sending one of those, fail the whole deployment (or just fail those files in the case of non-transactional). Either way, I don't think the files should be quietly skipped.

So, as stated earlier, sounds like a good FR.

Jonathon
Independent Interwoven Contractor

Migrateduser

Feature request filed -- #55497. (Would have done it sooner, but I've been out on holiday for a couple weeks.) Fyi, in general you can also file feature requests through Interwoven Technical Support.

Cheers,

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

excelOutput.JPG

Adam Stoller

Todd - Filing through Technical Support is only available to customers, and to consultants whose customers have enabled them to do so.

JonathonG has already indicated that he doesn't fit into the above two categories - and hence his post (as I don't need this functionality, it doesn't make sense for me to file it on behalf of my customer).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

Thanks Todd. Hope your holiday was a good one Smiley Happy

Jonathon
Independent Interwoven Contractor