Status for Andrew DeFaria

• Rearranged Informatica script code to be more oriented to what Don needs
• Helped William Dean with issues regarding Clearcase. I think we are all OK now so I closed the Paragrine ticket for this. This has, however, opened up the issue that CLEARCASE_PRIMARY_GROUP needs to be set in some cases

In order to make the pushing of Rational Tools more automatic it's important to either eliminate all user specific settings or to come up with a way to determine the setting for the user at login time. As such I have been researching if the CLEARCASE_PRIMARY_GROUP needs to be set at all. In most cases it doesn't need to be. (It was thought that mkelem would make the element and that the protect trigger would -chgrp <vob group owner> of the element. But if the user does not have CLEARCASE_PRIMARY_GROUP set then they are often considered part of Domain Users which isn't usually on the vob's group list). However today I found out a case where it needs to be. According to What is the CLEARCASE_PRIMARY_GROUP variable used for?

If the vob is owned by more than one group and a user is a member of more than one of those groups and the user's group list does not exceed 32, they need the CLEARCASE_PRIMARY_GROUP variable set in order to create elements in that vob.

If the vob is owned by more than one group and a user is a member of more than one of those groups and the user's group list does exceed 32, they need the CLEARCASE_PRIMARY_GROUP & CLEARCASE_GROUPS variable set in order to create elements in that vob.

Unfortunately this is the situation that we have. In particular Core_automation is owned by more than one group and users are members of more than one of those groups. Thus CLEARCASE_PRIMARY_GROUP needs to be set.

Also, we tend to have many groups and if we have more than 32 groups we can run into problems. Setting CLEARCASE_GROUPS helps narrow the problem down but a user can only be a member of at the maximum 33 Clearcase oriented groups or else they will need to be shifting around CLEARCASE_GROUPS in order to operate.

So what I'm proposing is that the Clearquest Tools database functionality be expanded yet again to provide for associating a userid to the appropriate CLEARCASE_PRIMARY_GROUP and appropriate CLEARCASE_GROUPS. Some of this functionality is already present in the Tools database. What it lacks is the ability to designate which of the groups is the users primary group.

There's also the issue of backfilling the Tools database and filling out the necessarily information for the users currently entered into the Tools database as well as filling the Tools database from that Access database...

Posted by at 6:11 PM | Permalink

• Spent most of the day wrestling with permissions problems. Anje was having problems as vobadm with EAG vobs in a UCM view. Attempted to recreate the problem and understand why it's not allowing her to create elements. Seems the EAG_VMS vob is owned by AsapAdm and group CC-EAG-VMS but vobadm is not the owner. vobadm is in the group and the group has write permission but vobadm can't write.
• Started writing WSH keystroke module for the Informatica process that Don is working on

Posted by at 7:21 PM | Permalink

• Noticed the CC-TTE-EMP-* groups have been created. One has the wrong name (should be CC-TTE-EMP-SCR but is CC-TTE-EMP-SRC. My fault! Typo when I requested the group). Applied these groups to the folders in Core_automation
• Changed protect trigger to set group owner to that of the parent directory. This is needed for this fix
• Removed Permissions trigger. This trigger was ineffective and is no longer needed

Posted by at 7:28 PM | Permalink

• Changed cmverify to report username in the logfile name and in report itself
• Changed protect trigger to use the parent directoy's group as the group owner for new elements

Posted by at 11:19 AM | Permalink

• Started documenting usage of groups within groups
• Helped John with mktriggers modifications

Posted by at 7:10 PM | Permalink

• Wrapped up the 3 things we want to do to configure during install into a cmd script - cmconfig.cmd
• Performed a lot of investigation regarding group permissions problem - writing web page for this

Posted by at 5:06 PM | Permalink

• Submitted a few task for improvements with the TOOLS database
• Changed cqverify to deliniate between username not found and password wrong. Changed return status such that if the username is not in the Clearquest database that's an error. But if the user is in the Clearquest database but the password is not default then that's just a warning
• Assisted TTE member to add ASAP_WinRunner to his view

Posted by at 6:42 PM | Permalink

• Implemented setregion.vbs. This command will set the region for the passed in region name. Or, if no region is given, it uses the users ID and the TOOLS database to determine that user's home region
• Requested SQL folk to allow monitoring of SQL service
• Changed cqverify to attempt connecting to Clearquest database using the user's username and password
• Changed ccverify to not consider an empty CLEARCASE_PRIMARY_GROUP as an error

Posted by at 1:27 PM | Permalink

• Worked on setting up What's Up alarms and alerts
• Created setregion.vbs. This script will set the region to the passed in region. If nothing is passed in it will attempt to find the region associated with the project for the currently logged in user through the CQ TOOLS database. If it can't find it then it will leave the registry setting alone

Posted by at 6:31 PM | Permalink

• Spent most of the day investigating how best to solve the issue of supplying Desktop Support a group/region for a user. Started writing VBScript to interrogate the CQ TOOLS database. Have the code functionally working but we need to add Region to a Project in CQ TOOLS. Also need to orient all of our .reg files to be .reg files.
• Implemented COMMENT_SQL_CODE trigger for BUCS_SRC

Posted by at 8:47 PM | Permalink

• Had problems with cron not being able to find scripts
• Spent much of the day researching whether or not we need to use CLEARCASE_PRIMARY_GROUP at all
• View server needed rebooting

Posted by at 5:48 PM | Permalink

• Worked on trying to sort out the differences between AD groups/groups.dat and the .reg files. Need to investigate if all this is required in the first place.
• Finished up setup_cygwin. Added links for .inputrc, .Xdefaults and .vimrc. Added stuff for verbose and debug

Posted by at 5:56 PM | Permalink

• Added more of an environment into CM_TOOLS
• Clearquest has been down all day. Server threw a shoe. Won't be up 'til tomorrow
• Seems we may not have a 1-to-1 correspondance between groups.dat/AD Groups and .reg files. Trying to work out the problems here

Posted by at 7:04 PM | Permalink

• Had problems with the Permissions trigger. Something we forgot or didn't think about. If the user attempts to add elements to source control they should be permitted in folders that have .perms. However part of adding to source control checks out the parent directory first. At the parent directory level there is no .perms to permit the user to check out the parent directory! This causes Add to Source Control to fail. Solution was to change the algorithm to account for this
• Finished up CommentSQLCode trigger. Added stuff to triggers.dat and documented things in CM_DOCS. Waiting for code review.
• Got this bright idea to take GetCCGroups.vbs and make another script that will simply dump the users for the given groups. Useful command line tool called whois
• Worked on trying to get PC to install the new Rational Web Server for John

Posted by at 4:38 PM | Permalink

• Implemented CommentSQLCode Trigger - need to do code review, triggers.dat, and documentation
• Assisted Loren, Padma and William in getting the Permisisons working

Posted by at 6:35 PM | Permalink

Here are the requirements as I understand them for the trigger that Steve Lipson wants for the SQL checkins. Basically he desires a trigger that will capture the checkin comment and other information and insert that information in the form of a comment at the top of the checked in element. This trigger will:

• Be a postop trigger for the checkin action
• Not be an all element trigger rather it will be attached to certain file elements in the vob
• Be made for the <fill in vob name here> vob
• Only work on file elements - directory elements are to be skipped
• Only work on file elements that have an extension of .sql - other elements will be skipped

Roughly the psuedo code for this trigger will be:

# Get name of element and its type
$pname        = $ENV{CLEARCASE_PN};
$element_type = $ENV{CLEARCASE_ELTYPE};

# Skip directories and elements that aren't .sql
exit if $element_type =~ /directory/i || $pname !~ /\.sql$/i;

# Get comment and user
$comment   = $ENV{CLEARCASE_COMMENT};
$userid    = $ENV{CLEARCASE_USER};

# Format timestamp
$timestamp = getCurrentTime;

# Parse output of lsactivity -cact -long
($activity_id, $activity_title, $activity_owner) = parseLSActivity;

# Open up $pname for reading and $pname.trig for writting
open PNAME_IN, $pname
  or die "Unable to open $pname for reading - $!\n";

open PNAME_OUT, ">$pname.trig"
  or dir "Unable to open $pname.trig for writing - $!\n";

# Add comment to top of file
print $PNAME_OUT <<END;
-- Date:	    $timestamp
-- Activity: $activity_id: $activity_title
-- Owner:    $activity_owner ($userid)
-- Comment:  $comment
END

# Append $pname
while () {
  print PNAME_OUT $_;
} # while

close PNAME;
close PNAME_OUT;

# Switch $pname.trig -> $pname
unlink $pname;
rename "$pname.trig", $pname;

# Allow checkin to proceed
exit 0;

Posted by at 6:54 PM | Permalink

OK, licenses are all OK now. BTW hostid is not a combination of IP address and MAC address - it's simply MAC address of the NIC card. Problem appears to be that during the server move the NIC card changed! I verified this with the Rational rep this morning. The current MAC address of the NIC card as shown by ipconfig /all (it's the Physical Address) is 00-0f-20-6d-09-97. I gave the old license strings to the rep and she determined our old MAC address of the NIC card was 00-0b-cd-9b-f4-27.

Looking at the Device Manager on the servers I notice that we have two Network Adapters listed:

1. HP NC7781 Gigabit Server Adapter
2. HP NC7781 Gigabit Server Adapter #2

Why we have 2 NIC cards I don't know (perhaps merely for the ability to be multihomed). Normally I see #1 being disabled and #2 being enabled. Rtnlprod01 is like this. Rtnlprod02 has #1 enabled and #2 disabled. For the vob and view servers this does not matter. Either card will work. For rtnlprod03 however, since licenses are tied to the NIC card's MAC address, switching from #1 -> #2 (or #2 -> #1 as I suspect has happened here) will invalidate all licenses. We need to insure that the network adapter for rtnlprod03 remains nailed at either #1 or #2.

Since it appears that the network adapter has changed and since I have obtained a new set of licenses for this new network adapter and still have the old set, I have installed both sets so that in the event that the network adapter switches again we'll be covered. However, if we order additional licenses for say card #1 and somehow we get switched to card #2, those additional licenses will not be represented, hence the desire to nail the NIC card to either one or the other.

Posted by at 6:47 PM | Permalink