Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Recent Items
 
Attack of the Naughty Bees
 
What Do You Do When Security Software Cocks-It-Up?
 
All Right, Now What?

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12

Do We Have a Firewall or a Development Web?

In the previous installment, we left von Clueless in the stew:

• The update to Zone Alarm Pro 5.0 blocked access to the local IIS web site via browser and via FrontPage.
• Attempting to revert to version 4.5 failed for lack of a VSUBRUN.dll that is nowhere to be found.
• We were wondering what ZoneLabs technical support would have to offer in a day or two.
• Meanwhile, with ZAPro 5.0 reinstalled, I was looking for a way to quickly disconnect from the net, bring the firewall down, do my web development work under an administrator account, pop the firewall back up, and reconnect the net.

I simply didn't want to do anything so laborious, failure-prone and just bloody risky.

Could I Have a Little of Each, Please?  Then I remembered that I might not have to perform anything so laborious.  From earlier experiences when I didn't have a proper network configuration for some reason, I'd learned that FrontPage could work directly with the file directories of IIS instead of via the TCP stack.  It even recognized what folders were configured as webs, continued to use FrontPage extensions, and coordinate with my version-control system (Visual Source Safe: VSS).  That would allow me to do everything I needed to do without taking the firewall down at all.  If it works in this particular situation, I can operate this way for a long time until the firewall problem is repaired.

Using FrontPage Directly With IIS Files

Clean the Slate First.  To change from web-access by FrontPage to disk-file access by FrontPage,

1. It is valuable to operate in a non-administrator account that has full access rights to the IIS service's file directory (on my machine, C:\Inetpub and its subfolders) and to subdirectories of the version control system (on my machine, C:\VSS).
2. Arrange, directly through version control, to check in all files that were checked out to locations in the web server.  Otherwise, the file-system access from FrontPage may see those as checked out by another account and you won't be able to work on them.  If you aren't using a version-control system on your development web (why not?), you can ignore this part.

Check It Twice.  Next, bring up FrontPage to confirm that file-system access to your development web is working:

3. Open FrontPage.  Do not use File | Recent Webs ► or File | Open Web....  Instead, use File | Open....
    
   
    
   Specify (or browse to) the file-system location of the Web you want to open in FrontPage.  To work on the http://compagno/orcmid/ local web, I open any file in C:\Inetpub\wwwroot\orcmid\.  FrontPage will open up just as it does for a web, except that it displays a file-system path as the root of the web being edited.
    
   
    
4. The first time after switching over this way, perform the FrontPage Tools | Recalculate Hyperlinks... operation to synchronize this new view of the site.  This is a valuable precaution if you are using version control.
5. Afterwards, you will see that the file-system view of the web site is available in the File | Recent Web ► list, and you can get right to work.
    
   

When the happy day arrives that you again have web access to your local web site, you can revert back to using the URL locations.  Just remember to check in all checked-out versions and run Tools | Recalculate Hyperlinks... once back in the URL view.

What's Up With the Firewall?

Before Monday noon, I received an e-mail response to my technical-support request:

• "Zone Labs is currently investigating incompatibility concerns with IIS and Visual Studio. We are researching a work-around, and will provide notification once a fix is ready."  I got it.  There's a problem.  Don't call us, we'll call you.
• "In the meantime, if you encounter this problem, you may opt to roll back to the earlier v.4.5 version."  Laborious instructions for uninstalling 5.0 are then provided.  This seems like a form response, and I must have failed to communicate that the previous versions fail to install because of a missing DLL.  I might not have mentioned it or I may have simply included too much information, a common mistake in my e-mail communications with technical-support contacts.

At this point, I am prepared to go to the ZoneLabs site and see if there is any FAQ about VSUBRUN.dll.  Before I do that, I see there is notification of a new update to version 5.0.  Should I try it and risk new destabilization?  My on-line security-engineering class started today.  I think I will download the update and research the nature of the change and still-known problems.  I will wait until after I have turned in my homework for this week before I mess with my configuration any further.  I can wait the full 8 weeks of the course if I have to.  Oh, wait.  In the syllabus they want us to have a software firewall and they recommend that we get one from ZoneLabs.  That could be exciting ... .

posted by orcmid at 6/24/2004 11:17:18 PM, rating data by NewsGator Online