Any reason why I can't configure ClearCase VOB server to be multihomed with one NIC on my lab network and the other the developers' network?
A bunch of lab systems need access to our ClearCase VOB server but it's on a different network with a firewall in between. I'd like to avoid the nightmare of firewall configuration by creating a dualhomed system.
If this something which ClearCase supports, has problems with, or is oblivious to?
I don't know if a multihomed host (In the Internet Protocol (IP), a host that is connected to more than one network) is supported or not for ClearCase.
I know:
this kind of configuration isn't mentioned in the system requirements for ClearCase.
I have multihoming (as in "multiple hostnames on the same network over the same communications line") enabled on Linux and Solaris10 (but with zones, meaning each zone represent an independent host in itself).
If you mention as server name the name associated with a given IP, it works without any particular issue.
Related
I can't get ClearTeam Explorer to register a new license server. It keeps referring to the old one.
The error I get back when I try to connect is that it can't connect to LICENSE_HOST_X.
I've changed the setting in 'Home Base's control panel to point to the new LICENSE_HOST_Y, which works for the clearlicense tool and clearcase doctor but not for the team explorer.
The license settings are contained in the Windows Registry at HKLM\Software\Wow6432Node\Atria\ClearCase\CurrentVersion\Licensehost for Atria licenses.
For FlexNet licenses, the PortAtHost value at HKLM\Software\Wow6432Node\Rational Software\Licensing\8.0\ServerList comes into play as well.
The odds are VERY good that you're dealing with Windows registry virtualization. If you open the legacy "control panel" on Windows 10, run the "ClearCase" control panel as Administrator (or open "cc.cpl" from an elevated command prompt) and check the server information there. If you see different values for EXPLICITLY elevated and non-explicltly elevated control panel starts, you have entries in the "user specific" virtual registry store. Please note that this is a WINDOWS function, and not a ClearCase one.
Disabling the albd service on the license server is a very bad idea unless that is the only function the albd is providing. Disabling it on the client will essentially kill any local views AND the ability to map views to drives when the "credential manager" service that depends on this service fails to start.
Check if any of elements mentioned in "How to change the hostname in the IBM Rational ClearCase environment" might have an influence in your case.
IBM Rational ClearCase supports two types of licenses, the Rational Common Licensing (FlexLM) and the Classic Atria licensing.
Update these files with the new host name:
Rational common licensing (FlexLM):
/var/adm/rational/clearcase/config/flexlm_host
Rational ClearCase Classic/Atria licensing:
/var/adm/rational/clearcase/config/license_host
So it can help to know if the new license server is of a different nature than the old one.
At the client level:
UNIX/Linux clients:
Update the new registry server's host name in the file /var/adm/rational/clearcase/config/rgy_svr.conf
Update the License Server using the instructions in the server configuration guidelines.
Windows clients:
Update the new registry and license server hostname information using the IBM Rational ClearCase control panel located under the Windows control panel.
If nothing work, I would, if my client is on Windows, search for the old license server name in the Windows Registry, and replace or even delete those entries.
On Windows, the OP V.Bogd confirms in the comments:
The problem went away after I disabled an "Atria Location Broker" service.
That was the service needed, as seen in this thread, for the old license manager:
No license available from ClearCase license manager;
Use clearlicense to display license usage
You can see more on albd_server.exe here.
We have Clearcase version 9.x is running with Linux host. We have started experiencing the view disconnected issues on post-reboot of the user systems ( which are running with Windows pro 10 & windows ClearCase client 8.x). The view mapping drives show as disconnected and we need to re-map the view drives to fix it each time the system reboots. Some cases the view shortcut alone disconnected from the ClearCase explorer and we need to add the view shortcut again to map the drives. The default view drive M: shows, as disconnected in few systems, starting the ClearCase services and adding view shortcuts again, helps here. And few other systems with same configuration working fine without any issues.
I have a few questions on this,
Am I missing anything specific with Windows say like patching, Anti-virus etc
Is the issue exist & common with Windows 10 operating system
How the mapping issues can be fixed, I am looking for some solutions which can be tested
Kindly suggest if you come across this issues
Regarding the drive M:\, thus us directly linked to the ClearCase MVFS service: make sure the "Credentials Manager Service" service is set to run automatically
Check the MVFS (for ClearCase 9.0) is properly installed: that will enable the dynamic views.
Regarding the shortcuts, check "Mapping an automatic view root directory to a drive letter": they should be subst command, which you can make persistent across reboot
But if those subst involve dynamic views, then again, the MVFS service needs to be correctly started, or those drive letters won't show up.
This can happen if the albd is not started by the time the user logs in, this delays the start of the credential manager service. The fast-logon optimization can allow the user to in before services start.
If the views you're using are not local, you can decouple the credential manager service from its dependency on the albd service, and this could help.
( which are running with Windows pro 10 & windows clearcase client 8.x).
You need to upgrade to 9.0.1.x. ClearCase 8 has not been supported for (exactly) 2 years. If your hosts are running Windows 10/1909, you will need to update to 9.0.1.9 as that is the version that has been tested with 1909. Also, the MVFS "network provider" information does not survive a windows "feature update" install as that install is really a full OS install folloed by settings migrations, and MS's migration still leaves something to be desired.
You may want to do the upgrade via the "clean install" method of:
Uninstall ClearCase 8.0.x & reboot
Navigate to C:\ProgramData\IBM and remove the Rational.preserve* directories.
Navigate to \Windows\System32\Drivers and ensure that MVFS*.sys files are no longer present
Install ClearCase 9.0.1.9
ClearCase 9.0.1.8+ changed the MVFS from a 2-part (MVFS + MVFS Storage Filter) to a 1-part (MVFS only) driver configuration. We have seen reports of the old MVFS drivers not being completely removed on upgrade. In the worst cases, the old MVFS driver files were both present alongside the new MVFS driver, and all 3 were somehow loaded. This caused post-upgrade blue screens.
just curious:
I see in my school that all instances of SQL Server ( and other programs) are installed in a Virtual Machine. Is there a reason to install software in a VM instead of directly into the machine's hard drive? I assume it may be a matter of faulty installation of software somehow affecting the host PC , while if there is a problem within the VM, the VM can just be deleted and the problem disappears, without affecting the host. Is this it, or is there more to it?
From a lab administrator's standpoint, it would be FAR easier to administrate multiple VMs in a classroom/lab setting.
Here is one great example (among others):
At the start of the semester, the admin can make a clean install (new OS, new SQL Server, etc.) on a new VM. Once the machine has everything needed, he can take a snapshot of the VM. After that, he can assign you to use that VM to your heart's content: Create DBs, install games, infect the OS, whatever.
When you have finished your studies, the admin can then easily apply the snapshot, and, voila, the VM is back to the original state as when it was given to you earlier. No reformatting, no uninstalling, etc.
Also equally compelling: From that one initial VM image, an admin can clone as many VM copies as needed (one step) without having to go through the minutae of installing/configuring software over and over.
I created a wpf application which connect to some sql database tables.
When i run this application on my pc every thing works fine,but when i try to run it from other pc on the local network i got an error: "The file ("file name") is on a network path that is not supported for database files".
What is the best way to create a WPF application that have to run from some pc's on the local network that share a common DB?
Have you considered a database server, SQL Server, MySQL, or something similar? If you really want to stick to a file based database (something I wouldn't recommend for security reasons) then you can use something like SQLite.
You will only be able to connect to your server (your pc in this case) instance from another pc if you have 'named pipes' enabled. You can also enable TCP\IP etc. if needs be, but this is probably why you are getting the error.
Named Pipes is not available in the Compact or Free versions of MSSQL.
A database server or pc with a proper version of MSSQL is your best bet.
yepppp solved.
Thanks for your answers.
I did some things that finally solved my problem:
1. Remove the "uid=Tomer, pwd=, and pooling=False" from the connection string.
2. Enable Port 1433(sql port) in the firewall.
3. Enable the TCP/IP and the 'named pipes' as i mentioned before.
Thanks alot for your help.
I would like to know:
How to Load two vobs in two different views where both vobs are in different registry and vob servers in a single client windows machine?
Different registry??? I dont think thats possible, because in the first place the View will not be the same across different registry.
Different VOB server in the same registry is not an issue, just load it normally.
Maybe I misunderstood your problem.
You need:
to pick one registry server
declare (mktag and register) the other vob from the other registry server in the first one
make sure the global path of the other vob is accessible from your client and from the first vob server (Windows to Unix can work, with, for instance, Samba. But if your VOB server, the one that you pick, is a Unix one, it won't be able to access VOB managed by a Windows Vob server)
Note: the hard part is to mktag and register the other vob in your registry server: you cannot do it in command line, because it will try to modify some files in the vob storage (which your first registry server has no right to do)
You can however do it graphically:
launch ccadminconsole.msc
Select the 'Registry' section:
create a new VOB object