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.
Having an issue getting a SQL Server linked server to Oracle working while using a tnsnames.ora file on a network share.
If I copy the tnsnames.ora file to the local server, the linked servers work fine. However, we keep the file on a network share. My sql service accounts have read access to the share. I configure TNS_ADMIN system variable to the network share, the linked servers no longer work. I get ora-12154: could not resolve the connect identifier specified. tnsping and sqlplus work on the server. When I use process monitor to investigate further, I see:
Operation: createFile
Result: ACCESS DENIED
...
Impersonating: domain\MyLogin
This seems like an issue, but is maybe a false positive? If a process is trying to impersonate my account and access a remote resource it will fail since we don't have Kerberos configured to handle double-hop.
SQLPlus and TNSPing work just fine with the network share configured.
I've looked at this post and tried the items that seemed relevant, but had no success.
Additional Info:
sqlnet.ora has this:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
I am able to open a file browser as a service account and open the tnsnames file.
I had this same issue while trying to connect a oracle 10g database via my WCF serivce developed in .NET 4.0 framework.
I was having multiple instances of ORACLE installed in my system. So, I modified the ORACLE_HOME to point to the Oracle 10g and it worked.
Also check the following:
Your service name might have an alias, so Make sure that your listener is listening for the same service name that you are using and check for both local and global entries. Check:
$ORACLE_HOME/network/admin/tnsnames.ora
Check your global_name setting with this SQL:
select * from global_name;
Also, Please make sure you add the Key TNS_ADMIN in the registry and create a enviroinment variable with name TNS_ADMIN
Regedit->HKEY_LOCAL_MACHINE->Software->Oracle->RightClick NEW->StringValue and name
Specify the correct path where the oracle is installed for Example
X:oracleproduct32bit10.0.1.0.0NETWORKADMIN
Edit
The below video also looks quite helpful. Please check.
https://www.youtube.com/watch?v=Sec8WG8gQPg
As an Oracle DBA I sometimes have to work with Windows. Maybe you can adopt from my experiences with Oracle on Windows.
Scenario:
An Oracle DB runs under a domain user. I want to restore a database from a backup which is located on a Windows share (sounds like "read" but it obviously isn't). I (or let's say the windows team) did not manage to find the proper way to grant the required permissions.
After many tries, the admins grant "everything" to the entire Oracle server.
Even though the Oracle process runs in a user context we did not find a set of permissions for the user only. Only the permissions for the entire server enabled the restore process to access the data.
From security point of view this is a horrible solution! But maybe it will help you to come closer to a solution (and if so, please share :-)).
I'm writing a WPF .NET application (fwk 4.0) which references log4Net and must be installed in the 'Program Files(x86)' directory on a Windows 7/8/10 64bits OS.
The application logs created by the application are .txt files created in the installation sub-directory of the 'Program Files(x86)'
This application also uses on the SQL Server CE 4.0 in the same subdirectory.
C:\Program Files(x86)\MYAPP\APP1\APP1.txt
C:\Program Files(x86)\MYAPP\APP1\CEDatabase.sdf
The application is installed by a local administrator.
To start the application, a standard user is prompted by UAC to start with an elevated acess token (admin privileges) to run the application because it won't start otherwise (I think ACL not granted to create and write logs).
The WPF application build holds no application manifest.
My client is frustrated by the fact that a standard user can not start the application without the UAC elevation. Moreover, it wants to keep on installing in the 'Program Files (x86)'.
What can I do to manage this situation?
I'd strongly suggest not writing the log files to the same location as you install your application, but instead to one of the standard public locations, which you can access by environment variables.
See this link for more details on how to set this in Log4Net : How to specify common application data folder for log4net?
The two common locations to log to which avoid UAC restrictions are:
CommonApplicationData (https://msdn.microsoft.com/en-us/library/windows/desktop/aa367992(v=vs.85).aspx) which is a location where all users can write to, so you might want to use this if you want a common logging location regardless of who is logged on to Windows and running your application.
LocalAppData (https://msdn.microsoft.com/en-us/library/windows/desktop/aa369768(v=vs.85).aspx) which is a location specified to your currently logged on user. This would allow you to keep your log files from different Windows users separate from each other.
I'm not sure off the top of my head whether you'd have the same issue with writes to the SQL Server CE database. The pattern I've followed in the past to work with UAC is to install all static files under Program Files, then all data under one of the above 2 mentioned folders depending on whether the application data and logging was per-user or per-installation.
I used to install clearcase client on one particular windows domain and was ok. I want to install clearcase in different windows domain but it is not allowing me to map network drive. Do you know if this new domain will allow me to install cc client? One thing to remember: when type "net group /domain", no cc groups are found ....Is there a way to proceed there?
Thanks for any help !!
This is usually because the albd account user isn't allowed to map that new network drive.
See "Domain user and group accounts".
Plus, installing to a new Windows domain will have side effects on the existing ClearCase Views.
I'm wondering what techniques you use to store the database credentials for your application. I'm specifically concerned with java webapps, but I don't think there's any need to limit the questions to that.
things to consider:
Do you use property files,xml configs, other?
Is it bundled into your application(ie in a jar file) or stored seperately on the file system somewhere?
Is the password encrypted? If so, what encryption scheme do you use?
Since you're leaving the question open to platform, I'll add that database credentials for .NET apps are stored in the web.config file. From version 2.0 and above, there is a specific ConnectionStrings section that allows for easier programmatic access to the connection string.
In addition to having IIS automatically block direct requests to the web.config file by default, you can also use an IIS command to encrypt the ConnectionString section of the web.config file. This encryption is machine specific, adding to its strengths, and the .NET runtime will also decrypt the connection string on the fly when you access it, so there is no need for additional coding in your application to work with it.
With Java, database connection pools should be passed into webapps by the container. This is in the standard declarable in WEB-INF/web.xml as resources. The same applies to mail sessions and other external resources that may vary from installation to installation. Look up JNDI for more information on this)
The nice part with this is that the application doesn't care about how to actually connect to anything outside. It will not see any passwords, because the container itself will use them.
In tomcat this is configured either from context files (e.g.) in conf/Catalina/localhost/ , conf/server.xml or - preferably only for dev environments, from the webapps META-INF/context.xml. Other environments have their own configuration location or application.
The encryption of passwords actually depends on the container. Tomcat stores them in plaintext, but the application itself won't see it. I don't know about the mechanics in other environments.
On the Microsoft stack, things can be very nice.
You create a network user account in Active Directory with almost no permissions. You configure IIS to run your webapp as that user. You grant that user read access to the web folders and files on the disk. You configure SQL Server to grant that user read/write permissions on the tables you want. And in the connection string, you instruct the db client to connect as the user account which the webapp is currently being run as.
There is only one actual user account, although it is visible in multiple places. This user account has extremely limited permissions. There is no storing passwords anywhere, even if encrypted. There is no configuration that has to be done in code for this to work (it's all in setting up the permissions).
Depends on the app server.
I usually use JNDI lookups for the data source, so credentials are stored on the app server that handles the connection pool. No need to put anything other than the JNDI name in configuration that way.
Yes, the password is encrypted on WebLogic.
On Tomcat things can be dicey. Connection info is in META-INF/context.xml, which means plain text for the password. I only do that for development, never in production.
In Django, the credentials are in your settings.py configuration file. Since this is not generally kept in your /var/www/ directory tree, it's very safe.
Also, a single Django application may be used (and reused) for many web sites or web servers on the same host, each with it's own distinct settings. So the settings.py configuration is not bundled with the app, but is part of a single deployment of the app.
For asp.net:
I store global parameters such as the connection string and repository paths in the Registry and then a reference to the registry entry in the web.config.
The main reason being that I often find I have to write a stand alone executable to run background tasks and other automated features that require access to the same parameters. Therefore keeping everything that is truly global in one easily accessible place makes for an easier life.
As stated before, no platform specified, and using some ideas from earlier answers:
I am considering a containerised application. You could store the password for the database in a file in the container. The first step of your application would be to establish the database connection, even before listening on web requests. With a successful db connection the file with the credentials is deleted and the variables containing the these, are removed. So when you start serving requests, the only thing that remains, is an open database handle to use from this moment on. If for any reason the database connection is lost, you simply quit and wait to restart the container, the credentials file will be there again.
Which of these are good places to keep your web app’s database credentials?
In a separate file in your source code
In a separate file on your web server host
In your database
None. The database credentials should never be stored