Clearquest License Server
- Investigated Clearquest License server
Time Spent: 3 Hours
Time Spent: 3 Hours
Time spent: 3 hours
Time spend: 7 hours
Total time: 5 hours
I don't see how my tinkering with things could have messed up IPSEC. I did mess with the Local Computer Polices and Default Domain Policies attempting to add rights to the local user sons-sc-cc\sshd_server. I'm not sure how this effects IPSEC. This user is used by the sshd and inetd Cygwin services. Since these services need to "switch user" to the user ssh'ing or rsh'ing they need some elevated rights. Prior to 2003 Server the Local System Account (known as SYSTEM in Cygwin) had enough rights to do this. But with 2003 Server Microsoft lessened the rights that the Local System Account has. Cygwin's answer to this is to create a new user ID, sshd_server, and assign it the necessary rights to be able to switch user. Then this user would only be used for Cygwin services. In fact they have a script /bin/ssh-host-config which creates a local sshd_server user for you (as well as sets up the hosts ssh key and adds a service for sshd). However even after running that script ssh was not working.
The inetd service, which is the super server, provides services like rsh, telnet, ftp, etc. that also needs to switch user. Similarly with cron. You see the service is running as an executable under some users credentials (normally the SYSTEM user) and needs to become the requesting user. So I was trying to run these services by using the local sshd_server user that ssh-host-config creates and adds the necessary rights to switch user.
Since I was having troubles I was removing the locally created sshd_server user and having the ssh-host-config script recreate it. At one time I decided to run mmc and add the Group Policy snap in then go under Local Computer Policy: Computer Configuration: Windows Settings: Local Policies: User Rights Assignment and make that the local sshd_server user had the following rights:
One time, when adding the Group Policy Object Editor I decided to click on the Browse button and saw a Default Domain Policy and thought perhaps there was something in there overriding the Local Computer Policy. So I added that and again I made sure that sons-sc-cc\sshd_server had the above rights. I have put a copy of this mmc polices thing under C:\Polcies.msc in case Ron wants to look at it. I notice a number of SIDs in there, probably from my past creations and recreations of sons-sc-cc\sshd_server.
As I don't know what Ron did to get sons-sc-cc running again and as I see the local sshd_server as having only deny network login right I don't want to mess with anything. Right now rsh is still broken as inetd cannot switch user since it's using the sshd_server user and that user doesn't have enough rights.
Here's an exert from /usr/share/doc/Cygwin/openssh.README:
Important note for Windows 2003 Server users:
2003 Server has a funny new feature. When starting services under SYSTEM account, these services have nearly all user rights which SYSTEM holds... except for the "Create a token object" right, which is needed to allow public key authentication :-(
There's no way around this, except for creating a substitute account which has the appropriate privileges. Basically, this account should be member of the administrators group, plus it should have the following user rights:
- Create a token object
- Logon as a service
- Replace a process level token
- Increase Quota
The ssh-host-config script asks you, if it should create such an account, called "sshd_server". If you say "no" here, you're on your own. Please follow the instruction in ssh-host-config exactly if possible. Note that ssh-user-config sets the permissions on 2003 Server machines dependent of whether a sshd_server account exists or not.
I copied (and modified) the crontab for ccadmin@sons-clearcase -> ccadmin@sons-sc-cc changing sons-clearcase -> sons-sc-cc where appropriate. I had also commented out the ctmerge lines. We don't want to be doing ctmerges on sons-sc-cc just yet as sons-sc-cc doesn't yet master the branches that sons-clearcase does. If we did we'd have to establish a whole new branching structure like sc_1.0, etc. That would be doable but since sons-clearcase will be decommissioned I think it's cleaner to simple transfer mastership of everything over to sons-sc-cc. However before we can do that we need to get all the users off of sons-clearcase and using sons-sc-cc.
The only thing currently left in ccadmin's crontab on sons-sc-cc are:
00 02 * * * //sons-sc-cc/Views/official/Tools/bin/update_view -q official
00 00 * * * /usr/bin/find /tmp -type f -ctime +3 -exec rm -f {} \;
01 03 * * Sat //sons-sc-cc/Views/official/Tools/adm/bin/dum -s /dev/d/Views/* > /tmp/viewspace.log
These three things are mostly administrative, updating the view official, cleaning out old files in /tmp and doing a report of the size of the snapshot views -> /tmp/viewspace.log. Sons-clearcase also does that. The report has the disk usage of all of the folders in the Views share sorted by the biggest users.
As we move off of sons-clearcase and onto sons-sc-cc you should instruct the engineers in Santa Clara to do the following:
This goes for both snapshot views on the server (//sons-clearcase/Views) and local snapshot views on your desktop as well as any dynamic views you may have. It is not required that you remove local snapshot views however by removing the snapshot views on the server (//sons-clearcase/Views) we get a better picture of what views remain.
When all of your elements have been successfully checked in, all your view private files saved and all of your views removed you can switch to the new server by executing /view/official/Tools/bin/switch-sons-sc-cc at a Cygwin prompt. Close any of your Clearcase tools (e.g. Clearcase Explorer) first. Then start Clearcase Explorere and create new views and proceed with your work. If you saved view private files and wish to restore them then copy them from the saved locations into a newly created view.
We all know what file/directory elements are and what a checked out file/directory is. View private files are files in your view that have not been added to source control. These can be the result of a compile (e.g. foo.o AKA a derived object because they have been derived and can be re-derived if necessary) or they can be simply a file that you created (e.g. file.txt). Sometimes you may create a view private file that you want to keep, possibly wanting to add it to source control at some later time. You generally don't need to worry about derived objects (IOW you can regenerate foo.o provided foo.c is in source control). But if you say created some new files that you use in the build but have not yet added them to source control, but intend to, then you obviously want to keep them. Perhaps it's time to add them to source control...
To list view private files use:
$ ct lsco
In your view.
Most people know how to Find Checkout. But to find all checkouts easily from a command line you can do:
$ ct lsco -avobs
Again this needs to be done in a view context (cd /view/official for example). This way you can see what's left to check in for everybody. We're aiming for 0!
Time Spent: 3 hours
Time Spent: 1 Hour
I feel we've reached a time where we can migrate users over to the new system. I've worked out how to migrate the CQ database, build issues for both the old (salira) and new (salira2) vobs, multisiting is working, by and large scripts work as well as CQD. The following is a plan for migrating Salira to the new server. Please let me know your comments and concerns.
Time Spent: 2 hours
TIme Spent: 2 hours
TIme Spent: 2 Hours
Time Spent: 2 hours
Time Spent: 2 Hours
Time Spent: 4 Hours
OK, trying this methodology:
Back on the new server:
The filename you have specified is not a Share. If other users will need access to this database, you should browse through "Network Neighborhood" to place is in a share. Continue with this name?I select No because I do want other users to be able to access this database. Next I change the D:\Clearquest\salira.db -> \\sons-sc-cc\Clearquest\schema.db and click Finish. At this point I get a error dialog stating that it was "Unable to connect to the database server". After much scratching of the head I realize that I should use D:\Clearquest\schema.db, ignore the warning, then go back in and set the Physical Database Name to \\sons-sc-cc\Clearquest\schema.db.
At this point I'd like to run Clearquest Designer and do Test Work so I can at at least verify that I can access the converted to SQL_ANYWHERE test.db. Unfortunately there is a checked out version of the schema in the schema database that I copied over and I'm not the owner of that checked out schema. And I can't login as that user.
By chance I tried Schema Repository: Upgrade: Selected connection in the Clearquest Maintenance Tool and in stepping through those dialog boxes it say "The schema repository that you want to upgrade has checked-out schemas. If you continue the upgrade process, the checked out schema versions cannot be upgraded and will be deleted from the system". I continue onward and manage to "upgrade" the schema and test database. I proceed into Clearquest Designer and manage to Test Work and viola! I got it up. I am nothing if not tenacious!
Total Time: 2 hours
Time Spent: 4 hours
Time Spent: 4 hours
Time Spent: 4 hours
(List not exhaustive nor necessarily in sequence)
Time spent: 5 hours
After speaking to Ron and getting the remote access working I did a few more things last night I:
Tonight I intend to create the initial replica packets for the vobs then ship them over to sons-sc-cc and setup Multisite syncing. I will first Multisite a vob like Tools or perhaps hardware just to go through the procedure and get the syncing jobs set up. Then I will do both salira and salira2.
There's probably still loose ends that need to be looked at but my plan is basically to be able to build in salira (I don't know how to build in salira2!) using only sons-sc-cc.
At that point we could create some views there for say Simon and teach him how to switch regions to the new SC region. Then he'd be working with the new vob server. He could build and otherwise check it out.
Time Spent: 3 Hours
Went to Salira to help Shuqing to set up a rel_3.1 branch.
Total time: 2 hours
Assisting with Hok's merging of his FX -> 2.4 stuff.
Lots of merging and building with 2 releases today. Still working through problems with us_2340 <-> china_2340 merging. Had to merge flmFiles.h from 2.3 -> us_2340 to pick up some definintions. Also had to build mksf.exe because some changes were coming from China and some from here at the same time. Merging the .exe is not possible in such situations so after insuring that all sources were merged I rebuilt the .exe
Fixed bug in build_view:
Fixed problem counting errors in output. This is a common problem: How do you distinguish between real errors and file elements or variable that contain the string "error". The approach was:
errors=$(grep -i error $card.build.log | grep -v "Errors: 0" | grep -vc "cli_errors.c")which looks for errors in general, weeds out the "Errors: 0" that the NP complier puts out and then makes an exception for the file element named cli_errors.c. Well with onu2311 comes new output that contains the string "error" but is not an error. Notably:
dmt_main.c: In function `reportErrorPort':For now we will make an exceptions for "ErrorPort" and "PortError" but this is not an ideal solution to the problem in general.
More WebSAM Testing. Almost done...
Was trying to get all of my WebSAM testing completed but was not able to. Got kicked onto another test system and that one had problems. Luckily Asad and Jeff helped fix things up for me. Got a lot done but may need to do more tomorrow.
2.3.0.4 bring in the FX branch into the 2.3 release line. It also has fairly major functionality identified by bug ID 3605 (287 elements changed!) and a new card, onu2311.
Please let me know when you guys and gals make a new card! While updating the makefile will indeed insure that the new card is build when one types make, I use scripts and processes that rely on the definition of cards defined in /Tools/adm/etc/cards and need to update that file when a new card appears. Thanks.
Regarding the FX branch: The FX branch was a temporary branch for engineers to work on until 2.3 stablized. As such, with it's successful merge I plan on destroying both us_fx and china_fx branches. A destroy means that the branch, element versions on that branches, any labels on those element versions and merge arrows to and from the FX branches will disappear. It will be as if suddenly a bunch of new FX related code got checked into the 2.3 release line. Since the FX branch was indeed temporary I don't see any problem with destroying it though. Let me know if you have any objection to this.
Before I destroy the FX branches however Hok has to check in his code and merge it to 2.4.
Built 2.3.0.3. Not sure if it's officially done yet in that there may be some problems with the ONU2310 FPGA image.
Meantime I've been trying to figure out why sometimes the build process says all is OK when there are build errors. Turns out to be a shell problem with tee. When building I'm doing:
$ make $card.sf 2>&1 | tee -a $teefile > $card.build.log
Seems this tee thing messes up the return code from make. This can be demonstrated simply by:
$ ls nonexistance_file 2>&1 | tee -a /tmp/ls.log > /tmp/ls2.log; echo $? 0
Need to figure out how to fix this...
Merged NeoPON.ccp from 2.2 -> 2.3 by drawing merge arrow. This was after Zhiyi OKed this merge.
Worked out remaining merge issues on other branches. These were largely "can't check in identical file" type problems.
Attempted an FX -> 2.3 merge. Only like 40 elements to merge but some manual merging was required. Due to 2.3.0.3 build for KDDI this was put on hold. Need to merge this then allow Hok to check in before destroying this branch.
Fixed bug in CheckInPost.pl. This bug was caused by an element having a space character in it (e.g. a directory named "source code"). The checkin trigger had the following line:
$result = system ("cleartool mklabel -replace $bugid $pname");
This line assumes that $pname does not contain a space character. The fix was:
$result = system ("cleartool mklabel -replace $bugid \"$pname\"");
The \"'s surround $pname and thus protect it.
Continuing onward with WebSAM testing...
Shirley/Ying approached me today asking to merge the us_fx branch into the rel_2.3 branch. As rel_2.3 has not be stablized yet (2.3.0.1 has not be officially built) I was hesitant and suggested instead ot merge the reL_2.3 branch into the us_fx. This caused a massive amount of merging (561 elements) probably due to the fact that lots of stuff changed in reL_2.3 that the FX engineers did not care about (other areas of the platform code as well as the web pages, SAM, etc). There were a few elements that require manual merging. Shirley is aware of these.
Built ONU 2360 bootrom
Finished up processing of 2.1.12. The Shanghai link was down so I was not able to push out 2.1.12 to Shanghai. Finished that today.
Started testing of new SAM for Linux 2.3 on new SuSe 8.2 sonslinux machine.
As per Jeff's instructions I rebuilt 2.1.12 after insuring that the ONU FPGA was checked in on the China side and merged to the US side. Also insured that the label was properly applied.
Also got sonslinux's web server up and running and installed mod_php.
Build new 2.1.12 image with new ONU FPGA.
Finally figured out the XDMCP problem on sonslinux - problem was that there are multiple places where kdmrc exist. I was editing /opt/kde3/share/config/kdm/kdmrc and should have been editing /etc/opt/kde3/share/config/kdm/kdmrc!
I decided to check sons-clearcase after Ron implemented his fix for our router problems. Turns out I can't access it again. Not sure if it's the router, the fix or something else. I can VPN into my desktop. I can ping servers such as sonscentral and sonsservices but not sons-clearcase. I tried pinging the gateway and it still dropping packets.
Then when I was attempting to ping sons-clearcase I got the following:
$ ping sons-clearcase
Pinging sons-clearcase.SALIRA.COM [192.168.0.99] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.1: Destination host unreachable.
Ping statistics for 192.168.0.99:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Not sure what this means. Guess I'm gonna have to drive into work again...
Checked sons-clearcase from home and couldn't get to it. Drove in and analyzed the situation. Saw things in the Event Viewer possibly indicating that the network card was bad. Rebooted machine. Couldn't get it up on the network. Ran network trouble shooter and it suggested replacing the network cable. Didn't want to do that. It also suggested to try to plug the network cable into another spot on the hub. Tried that and it worked! Not sure if that was the fix or if sons-clearcase's network card is flaking out. Rebooted once again to come up clean.
Went in around 3 PM. Rebooted sons-clearcase. It's back up and running. Noticed that our backups are not really working well (never have been actually). Performed backup by hand.
BackupExec doesn't seem to want to properly do the pre and post commands necessary to backup the vobs. It seems to say that it can execute the cleartool lock command on the remote machine but always fails with an error stating that the pre command failed.
What was really confusing about this is that the Tools vob backup appears to work. Well then I found out that the Tools vob backup was configured to run the pre command but accept non 0 as an OK status whereas the Salira vob was not accepting non 0 as an OK status.
In any event ct lock vob:\
Need to speak to Veritas regarding this on Monday and get this finally working correctly.
Meantime at least we have one good backup!
I saw some email saying that there was some possible problems with some Clearcase stuff and decided to investigate. I had talked with Ron on Friday and he is aware of our network problems. But today I could not contact sons-clearcase at all. I can seem to ping and otherwise contact other machines such as sonscentral, sonsservices and engineer's desktops such as dko and gtsang. I can even ping sons-cc in Shanghai! I fear there might be something wrong with sons-clearcase itself - perhaps the network card. Why can I contact other machines but not sons-clearcase?
Not sure if I should go in to reboot sons-clearcase and see if she comes up OK. I guess I oughta...
Hmmm... I can't ssh adefaria@adefaria either. Doesn't accept my password. ssh ccadmin@adefaria doesn't work either. Could this be an Active Directory problem too?
Was able to remote desktop to sonscentral. Doesn't seem like my account is locked. Neither is ccadmin. Can't tell if this network issue is just sons-clearcase or a larger problem.
Still have Clearquest problems, almost daily, where I come in and people cannot access Clearquest. Worked on the phone for a while with Rational. Came down to a theory that this is caused by networking problems. Checked with Ron, yes indeed we are experiencing network problems.
After receiving a file from MTeng I had built and released 2.2.1.5. As MTeng has not yet checked in this file, and there is another bug on the 2.2.1.5 list, I do not consider 2.2.1.5 done yet. I have built and put a label down but this is sort of an unofficial build.
Also worked ag getting XDMCP running on sonlinux again. Still not working right.
Upgraded sonslinux to SuSE 8.2
Helped Yan with Clearcase problems. Investigating installing SuSE on sonslinux. SuSE appears to be more of a market leader.
Initial reports seem to indicate that Web SAM works on:
| Operating System | Internet Explorer 6.0 | Netscape 7.1 | Firebird | Konqueror 3.1.0 |
|---|---|---|---|---|
| Windows | Yes | Yes | Yes | N/A |
| Linux (Mandrake 9.1) | N/A | Yes | Yes | No |
| Solaris 7.0 | N/A | Yes | N/A | N/A |
Fixed long standing Clearquest bug for Yan
Helped Ying get the contents of the IPTV CD onto our anonymous ftp area. This required getting anonymous ftp to work again.
Got it, although I had to get it through a patch cluster, which finally worked! The above patch required other patches, which, of course, required other patches and was a nightmare. Not that installing the patch cluster was that easy either. In any event I eventually managed to get SAM for Solaris up and running!
Haven't been able to get SAM running on Solaris:
Downloaded and installed SAM 4 Sun. Unfortunately it didn't run. The error message I get when attempting to start the server is:
Warning! The libthread.so on your system is an older version than
the one this VM was tested with. Please read the install
documentation for
patch installation instructions.
Could not create the Java virtual machine.
Leonal says there's a patch...
Received a CD from Shirely with Solaris 7.0 on it and managed to get sonssun installed and on the network again. Still more to do like install a decent browser and get its XDMCP working but at least it's up.
Spent a lot of time still trying to get Samba on sonslinux to function properly
Not much done today - guess it's just the holiday thing. Still trying to get sonslinux to play nicely with the Windows environment. Helped James with his Linux setup. 2.2.1.5 was not built, perhaps when I get back from Vegas...
Built and release 2.2.1.2
Worked more on getting sonssun up and running.
Worked on problem with 2.2.1.1 and websam
Attempted to gain access to sonsun today. Found out that it's powered off and not connected to the net. Sam lacks an IP drop in his cube.
Set up both 2.4 and china_2.4 and set up synchronization of branching for all of 2.2, 2.3, 2.4.
Worked on getting show system stuff into discovery