Duley Noted

Cisco ASA 5510 initial setup problem resolution

2010-02-19T08:21:00.000-05:00

Problem:

Using a Sony Vaio laptop connected only to the management port of a new Cisco ASA 5510, and a static IP address for the laptop within the Cisco defined range (192.168.1.3), the ASDM Launcher on the desktop could not connect to the ASA device so that I could configure it.

Additional Details:

Exploring other options to use ASDM, it seemed I could successfully open the ASDM GUI via pointing the browser to 192.168.1.1, and running the Java applet. Howver, the host was showing up in the GUI as “ciscoasa.default.domain.invalid", and if I reconfigured the device (to provide my own host and domain name, the ASDM launcher would not recognize it.

So that others may put this problem into context when working with their ASA 5510, here is my version info:

ASA v7.0(8)

ASDM 5.0(8)

ASDM Launcher v1.5(20)

Browser: IE 6.0

OS: Windows XP 5.1

License: 3DES-AES

I noted that the laptop had been using Java 1.5_0_05, so I upgraded it to the latest version, jre-6u18. This still did not work when attempting to use the ASDM launcher, as the Java console revealed error messages (I think in this case an array index out of bounds).

Solution:

The solution to my problem was provided by a user in the Cisco Support Forum, where he stated that he found jre-6u7-windows-i586-p.exe (available at www.java.sun.com/products/archive/j2se/6u7/index.html - appears in the Java console as jre 1.6.0_07) to be the most stable version for the ASA 5510, and suggested I uninstall my Java and use that instead.

I am now able to successfully use the ASDM launcher via the desktop icon, and the host now shows as ciscoasa.local as I would expect.

Note: I also disabled Norton Internet Security on the laptop, as that seemed a possible problem cause, even though I was not connected to the internet.

How to Map a Tree Structure

2009-09-25T07:26:00.000-04:00

To answer the question I had on how I could map my directory tree structure so I could easily see layout all at once, I turned to an example I found in the book “Windows Server Hacks” by Mitch Tulloch, copyright 2004 O’Reilly & Associates, Inc., ISBN 0-596-00647-0.

Seen below is the snipet of VB code. Simply open Notepad with WordWrap turned off, and paste it in. Save the file as “vbtree.vbs” to whatever point in the directory you wish your mapping to start.

I have slightly modified the introductory comments for clarity.

—————————————————————————————————

‘This script is used to show a simple directory tree
‘In command prompt, navigate to directory folder where this file is stored
‘Type cscript vbtree.vbs to display the tree
‘Type cscript vbtree.vbs > tree.txt to redirect the output to a text file
‘Source: Windows Server Hacks

Option Explicit
Dim sArg, oFSO
Set oFSO = CreateObject("Scripting.FileSystemObject")

‘Get folder (default is current directory)
If Wscript.Arguments.Count > 0 Then
sArg = Wscript.Arguments(0)
Else
sArg = “.”
End If
sArg = oFSO.GetAbsolutePathName(sArg)

‘Process entire tree (if valid folder)
If oFSO.FolderExists(sArg) Then
Wscript.Echo “Folder tree for: “, sArg
ShowTree “", oFSO.GetFolder(sArg)
End If

Set oFSO = Nothing
Wscript.Quit(0)

Sub ShowTree(sIndent, oFolder)
Dim oSubFolder, ix
ix = 1
For Each oSubFolder In oFolder.SubFolders
Wscript.Echo sIndent & “+–” & oSubFolder.Name
If ix <> oFolder.SubFolders.Count Then
ShowTree sIndent & “| “, oSubFolder
Else
ShowTree sIndent & ” “, oSubFolder
End If
ix = ix + 1
Next
End Sub

Regedit vs Regedt32

2009-04-24T10:35:00.002-04:00

Here is a decent article from Microsoft explaining "The Differences between Regedit.exe and Regedt32.exe": http://support.microsoft.com/kb/141377 .

I would highlight that when using Windows 2000 Server, you want to use Regedt32.
While the String Editor (associated with file type REG_SZ) appears to operate the same using either executable, the Multi-String Editor (associated with file type REG_MULTI_SZ) functions properly only if Regedt32 is used.

The Microsoft article warns that "If you try to edit either of these data types (REG_MULTI_SZ or REG_EXPAND_SZ), Regedit.exe saves it as REG_SZ, and the data type no longer performs its intended function."

Forward Confirmed reverse DNS

2009-04-23T10:49:00.002-04:00

I read this article on wikipedia: http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS.

There, I found this tool:
http://ipadmin.junkemailfilter.com/rdns.php.

In my email account, I then select a message and right-click and choose "View message source."
About the fifth line down, I see the IP address that the message was received from.
I can then plug that IP into the tool above and validate it.

Are your skills heading in the right direction?

2008-12-15T13:58:00.001-05:00

Check out http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html for a fascinating look at trends in languages.

The Dirt on Scrum Development

2008-12-08T13:14:00.034-05:00

Using the Wikipedia article on Scrum development (http://en.wikipedia.org/wiki/Scrum_(development)) as my starting point for discussion below, this posting will detail my own experience. In this case, I was part of a very large team working to produce a complex portal application. Although we had not dictated we were following "scrum" (having simply deciding to follow an Agile approach), I see now where this fit in with my experience.

Characteristics:

Our project had a process skeleton in place, with a set of practices and predefined roles.
Our predefined roles included a Product Owner (a customer voice representative embedded on site), stakeholders, a program manager who filled the ScrumMaster role, and a Team of subteams (a requirements team, a framework team, a database team, a developer team, a test team and a training team).

Evaluation:

One setback our team faced was that our practices changed over the course of the project as we started to determine better what did and what did not work. As a result of the learning curve to implement new practices, there was some delay in getting the project really churning.

The boundaries of our roles started to blur as people stretched outside of their area:

Developers started trying to fix framework problems or make database changes
The database team started to add or modify tables without notifying the team, which caused compile errors
Developers observing problems during unit testing started driving requirements
Requirements folks started trying to drive design

In looking back, as part of the developer team, our "sprints" were two weeks long in duration.
During this time, we created our package of "potentially shippable" software.

Roles:

The Wikipedia article defines "Pig" roles of a Product Owner, a ScrumMaster (or Facilitator) and a Team. "Chicken" roles consist of Users, Stakeholders (Customers and Vendors) and Managers.

Evaluation:

Our project became a failure as the Product Owner wrote User Stories that were so vague that it was hard to match up with the list that the requirements team had produced. Stories were prioritized and placed in a Product Backlog.

Our project also failed because the ScrumMaster tried to be the leader of the team, a situation which was implied as he happened to be a program manager for the company. Wearing two hats for him was a problem.

After months of development had gone by, it was also revealed that the Product Owner was not accurately conveying the voice of the customer. In addition, the Stakeholders had signed off on the prototype initial look and feel (i.e. show these tables on these pages), and when it was built out that way, numerous changes were requested. Of course all this snowballs into a list of RFCs which dramatically increased the scope of the project and produced delay.

Meeting:

This method calls for a daily status meeting, or scrum, also called "the daily stand up". The article describes the specifications and what is to be covered. Following each sprint cycle should be a "sprint retrospective", which is basically a lessons learned.

Evaluation:

I'd say that our team held to the principles of the scrum meeting pretty well. The only issue we seemed to have was that the ScrumMaster had to be continually reminded about obstacles in our path of success. The ScumMaster was always being pulled into higher level management meetings, and as a result was unable to act effectively. Our retrospectives enabled the team to define additional required training or cross-training opportunities for team members. In addition, this created a chance for people to visit with folks in other roles to see how one area of work impacted another. This lead to increased understanding and anticipation of the needs of another team.

Artifacts:

The Product backlog is a high-level wish list of what should be built that everyone should have edit access to, with the Product Owner setting the business value and the team defining the development effort.

The Sprint backlog is a granular, unassigned task list broken down into units less than sixteen hours wherein team members sign up for tasks as they wish.

The burn down chart is essentially a task list for a given sprint that indicates which tasks have been completed and which are still remaining (claimed or unclaimed).

Evaluation:

In our project, the Product backlog was not open and editable by anyone other than the Product Owner. The ScrumMaster would provide the development effort only based on sprints. As the project fell behind and the scope kept increasing, the customer demanded that we stop all work and match each requirement (I'm talking in the neighborhood of 50,000 + reqs.) to the corresponding item in the product backlog. I also think that the Product Owner may have not had adequate tools to track a project of this scale. I would recommend looking into workflow products other than just MS Project, which became a beast for the Product Owner to manage effectively.

In our case, I'd say we never implemented the Sprint backlog as described above. The developer team was broken down into different folks being responsible for different component areas of development since the requirements list was so massive. As a result, if your component had work listed for the next sprint, then you had the duration of the sprint to get it done.

Our developer team implemented a burn down chart later in the game, and this became an unanticipated source of animosity. While it was later used for reallocation of resources, it initially became a source or pride or embarrassment. Some developers finished building their assigned components quickly, while others appeared to be lagging (though no fault of their own, this was often due to external dependencies such as database updates or a completion of a linked component). The whole team never had a consolidated accessible burn down chart.

Adaptive management:

Concerning the general practices of Scrum:

We did have the customer heavily involved. However, debate raged within the customer organization as to the selection of the Product Owner and stakeholders. It became highly politicised as each organization had a different vision of what the end product should be and how it should look.

As an agile process, we did provide frequent, functional intermediate deliveries, which allowed requirements and priorities to change. However, with this comes an increase in scope and change in project schedule.

One thing we clearly were missing was a plan for Risk Mitigation, Monitoring and Management. Only when the project was way over budget and delayed numerous times did we put a plan in place to tell the customer that if they wanted change X, here was the cost, and make them approve it.

While we did have some transparency for module development, it seemed to only exist from a given team's perspective. I do not think that we shared a complete overall vision. At the developer level, we only ever seemed to be aware of planning in regards to the current sprint.

We did provide routine stakeholders meetings via the sprint reviews (which as mentioned above had an impact on the project schedule), but what we did not have in place was a mechanism to alert the customer of potential schedule slips.

Conclusion:
While I think that with some modifications, Scrum may be a workable model for development on SMALL applications, I think that large-scale enterprise application development is hampered by it. The Scrum article describes the Team as "5-9 people with cross-functional skills to do the actual work." We had at least fifty developers on this project and were comprised of at least six sub teams! Hopefully this article provides some lessons learned to other organizations.

Follow me on twitter.com!

2008-12-08T12:45:00.001-05:00

Get more frequent updates at http://twitter.com/DuleyNoted.