nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Autoprivate related question

System

ARCHITECTURE:
Teamsite 5.5 on Solaris
--------------------------
HISTORY:
We are blocking certain 'bad' file extensions on our web servers using a FilesMatch directive in apache

<FilesMatch "\.(asa|asp|backup|bak|bat|ear|war|err|htm~|inc|ksh|lck|LOG|log|new|old|original|out|properties|sav|save)">
Order allow,deny
Deny from all
</FilesMatch>

Certain people in our company don't think files with these extensions should even get deployed to our web servers. I tend to agree. So we're trying to correct the problem after the fact.

We have 650+ OpenDeploy descriptors so it is impractical to try to implement this type of filtering here. It would be a maintenance nightmare.

So I've been looking at autoprivate.cfg. Doing some testing, it looks like I've got a course of action that will work.
---------------------------
SUMMARY:
1. Put rules in autoprivate.cfg
2. iwreset
3. move files with bad extensions from staging area to a temporary directory and then back into the workarea at which point the 'P' icon appears
4. Remove files with bad extensions from the STAGING areas <----see below
5. Remove files with bad extensions from the web servers

Regarding step 4, it doesn't look like I can manipulate the STAGING area filesystem.
$ cd /default/main/tstp/Dave_site/STAGING/
$ rm testme.rodney
rm: testme.rodney: override protection 555 (yes/no)? y
rm: testme.rodney not removed: Read-only file system

--------------------------
QUESTION:
Has anyone written a script to remove files from the STAGING areas?
Does the course of action above sound reasonable

Find more posts tagged with

Comments

Adam Stoller

Are you sure that no file with any of those extensions should ever be versioned?
(specifically I'm thinking of asp, LOG, log, and possibly properties)

You cannot remove a file from staging directly (as you proposed). To remove a file from staging you need to delete it from the workarea and then do a submit of the deletion (may possibly need Overwrite mode enabled)

You probably should update your OD config files to exclude these files too.

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

Migrateduser

Fish is correct about needing Submit w/'overwrite' to remove files from STAGING, at least as of my first version of TS: 4.x this was true. Thus the main problem I see with your plan is the order you're planning on doing things in. You'll probably need to remove the offending files before making them autoprivate. Otherwise autoprivate will most likely prevent the submit from removing them from STAGING. I'm stating these as probabilities because I'm not willing to experiment with it on our server. But confident in the prediction.

In consideration of Fish's question, I'd not autoprivate _any_ file that is req'd to operate your site AND is built by human hands. Any files that ought not be deployed should be restricted through some other means, as autoprivate will remove any history tracking of the files in question. After due consideration of Fish's question on the correct list of extensions, I'd recommend that you to revise the plan to something like this:

1) temporarily limit access to TS server (e.g. remove all user roles except an administrator)
2) confirm a recent backup worked (in case a file type was misidentified as unnecessary)
3) remove undesired files from STAGING (submit w/overwrite)
4) add rules to autoprivate.cfg
5) execute iwreset
6) restore access to TS server

HtH

Migrateduser

Well, looking over the list, there are some files that we still want teamsite to version, so even if it was in the FilesMatch directive I posted, that wasn't really the focus of the question. We've got .properties, .war, and .ear files in our system that need to be versioned and these won't be in the autoprivate.cfg file.

Regarding promoting through a deletion to make sure it gets the file out of STAGING, I understand that I need to do this. But I have no desire to use the GUI. I guess I should have phrased the question a little better. I'm looking for a script that can promote through these deletions instead of needing to
delete from the WORKAREA, view modified, check the files that were deleted, and submit direct.

Adam Stoller

From a script you can create a list of files to be deleted, delete them in the workarea and then create a temporary file list in which the entries are specified like this:

/vpath/to/deleted/file-1

submit comment for deleted file-1

/vpath/to/deleted/file-2

submit comment for deleted file-2

...

And then use the iwsubmit CLT with the "-f" flag to submit the deleted files from the workarea.

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