I just downloaded glassfish 4.1.1 (previously I had 4.1). Last time I upgraded I remade my security realm and DB connections. This time I'm wondering if there is an easy way to move those from the previous version used to my new one.
Just downloaded Glassfish 4.1.1 myself and will face the same problem. I will first try the following workaround: Copy the relevant part from the C:\glassfish4\glassfish\domains\domain1\config\domain1.xml (or whatever your domain is called or where it is located) and paste it into the according spot in the new domain1.xml. Provided the relevant external resources exist (databases, LDAP, etc..) and the respective datasources or other glassfish resources exist as well, this should do the trick.
Start by searching your old domain1.xml for any name that you yourself introduced, such as the name of the realm or the datasource. Copy that relevant piece of XML, make a safety copy.
Then look where to fit it into the new domain1.xml.
Funny that security realms cannot be added via a glassfish resource via the NetBeans new-Menu, whereas connection pools and other stuff can. And it all is merely copied into the domain1.xml.
Related
This question has been asked before and I've spent two days chewing through it all, to no avail. I've worked in and around DNN since the very early days (anyone remember the IBuySpy portal from 20 years ago?), and I've migrated more than a dozen sites, all without issue. But in this case, I'm getting the old "object reference not set to..." The EventLog indicates an error in InitializePage but not much more to go on. The logs in the DNN _default folder are for some reason not populating; will check this.
The specifics: DNN 5.03.01 site, has worked fine for a client for years. Needs to be moved to a new server. Different domain name for testing, then we'll redirect the live domain name. Site has a default portal at Portals/0 (no longer used); client's portal is at Portals/1. DB is on same box, MS SQL Server.
What I did: created a Portal Alias in the old, live site to reflect the "test" domain name. Copied all file system content. Duped schema to new DB (same version of MS SQL Server), used Schema Compare to make sure it worked, added all data, used Data Compare to make sure it was all there. Logged into new DB using SMSS; works fine. On the new/test DB, disabled all entries in the WebServers table. Verified new portal alias exists, referencing Portals/1. Verified domain name is live with correct new IP. Set up new site on IIS using that IP, referencing Portals/1. Edited connectionstrings and appsettings entries in Web.config, using the credentials that worked with SMSS. Ran the new site by entering the new/test domain name. I also set the permissions broadly on the DNN folder.
Got: [new domain name]/Default.aspx?error=Object+reference+not+set+to+an+instance+of+an+object.&content=0
So I'm getting to the DNN folder on the new server, but it seems something's not right with PortalSettings (guessing here). Maybe it's going to Portal 0 (the defunct one). This shouldn't happen if I create the new PortalAlias before migrating.
Possible complicating factor: The new server contains another complete instance of DNN which handles the live version (a copy) of the Portals/0 portal on the old machine.
Anybody have any thoughts? Something I overlooked? How can I make absolutely certain I'm hitting the database?
In the older versions of DNN there was a PortalSetting value for DefaultPortalAlias. If that was set to something different it is possible you could see similar behavior.
Also, that version of DNN does not log entries to the /portals/_default/logs directory
I am using database connector component, with vault component to store the database credentials. Now as per the documentation of both components i have created different properties file for each environment to store the encrypted credentials for diff env.
Following is the structure of my mule project
Now the problem with this structure is that i have to build new deployable zip file whenever i have to update the database credentials for any environment.
I need a solution where i can keep all credentials encrypted and centralized and i don't have to create a build every time after updated the credentials, We can afford to restart the server, but building new zip and deploying is really cumbersome.
Second problem we have this approach is a developer needs to know the production db to update it in properties file, this is also a security issue.
Please suggest alternate approach for credentials management for mule projects.
I'm going to recommend you do NOT try to change the secure solution provided to you by MuleSoft. To alleviate the need for packaging and deployment, you would have to extract the properties files outside of the deployment and this would be a huge risk. Regardless of where you store the property files within the deployment if you change the files, you have to package and re-deploy. I see the only solution to your problem as moving the files outside of the deployment and securely storing them. Mule has provided a solution while it may be cumbersome, they are securing these files first with encryption and secondly within the server container. You can move out the property files but you have to provide a custom implementation and you will be assuming great risk to your protected resources.
Set a VM arguement e.g. environment.type=local for local machine on your anypoint studio.
Read this variable in wherever you are reading your properties file in a way that environment type is read dynamically such as below.
" location="classpath:properties/sample-app-${environment.type}.properties" doc:name="Secure Property Placeholder"/>
In order to set the environment type on your production server(or wherever you are using mule runtime), open \conf\wrapper.conf and add the arguement wrapper.java.additional.=-Dserver.type=production. If you already have any property in this file, you may need to set the value of n appropriately. For example 13 or 14.
This way you don't need to generate different deployment artefacts for different environment because correct properties file is picked by using environment specific VM arguement.
im running multiple servers on weblogic domain.
Is it possible to run different ojdbc drivers on servers?
adding classpath under server start configuration doesnt work, also deploying with application and deploying on server as a library doesnt overrride default.
Thanks for help
First, basic checklist...you do use NodeManager don't you (server start tab won't do anything if you don't). Also, you made sure the new driver name is configured in the JDBC datasource (I'm assuming the driver is for a datasource right?)
Deploying in the app shouldn't do anything since the datasource object is created prior to deployment.
You might want to take the old ojdbc6.jar, for JDK 6, and ojdbc5.jar, for JDK 5, out of the directories to make sure they're not seen anymore.
Also, where in the classpath did you put the new path ? When you add another path you should always put it in the beginning (after patches though)
We in our team are planning to use gerrit. So, to get introduced, I did set up a server, used open-id for authentication and created some test-users and test-projects in it.
Now we are ready to use it. But we actually prefer LDAP for real use.
So, can I change my authentication system from open-id from LDAP? What will happen to current users then?
I want to clear test projects and changes. How can I do them?
Can I complete delete existing gerrit setup and initiate a fresh setup in same machine? (I tried extracting the jar in different folder, but I faced some problems in it)
I am using Ubuntu 12.04 as my server.
Please help.
Delete the database (you're not using the H2 database anymore, but some MySQL or PostgreSQL server, don't you?) plus the directory where Gerrit is running (the -d parameter, see docs). Additionally, remove the git repos, if you configured them to be located on a different path.
Then all your data is gone and you can start from scratch.
I have a Glassfish server in production which uses JDBC Realm for authentication.
It works well, but there is the need to change all the roles/groups. I developed a new version of the web application in a test environment changing glassfish-web.xml and web.xml to align them with the groups contained in the groups table on the db for test. Everything works flawlessly. So I moved the web application to the production environment and updated the content of the groups table on production db.
The authentication works well but roles are not recognized. How can I investigate this problem ? I checked the production db and the groups table is fine and can be accessed for select. Glassfish-web.xml and web.xml are the same of the test enviroment. This is a real brain teaser. The only explanation I can give is that Glassfish-web.xml is discarded for unknown reasons or the old file is still present and read from some other location than web-inf directory.
Thanks for any help
Filippo
Explore your domain's folder under GlassFish root folder + \domains. If you are unsure what domain you are on, it is domain1 by default. Under this folder you should have a folder called applications. This folder contains the deployed version of all your applications, and it's the place where to check your application's Glassfish-web.xml configuration file.
Anyway, if you are having this kind of problems, a Clean & Build of your project, followed by a redeploy, usually works.