I am attempting to use Liquibase to deploy changes to SQL Server.
I have set up the sqljdbc jar file and placed it in my local maven repository. I then attempt to use the liquibase-maven-plugin to run the changes placed in the changelog for the given connection URL.
Here is what my connection URL is: jdbc:sqlserver://localhost:1433;user=Jenkins_BuildServices;password=hi;
I already created the login on my localhost and gave it sysadmin privileges. I also have made sure that the properties -> security is set to both SQL Server and Windows Authentication mode. Any ideas as to why the url being passed in is giving me back this error and not reading it from the URL?
Related
We have configured the visualsvn server in remote machine, while accessing the repository from the browser in our local machine, we are getting the below error in the internet explorer browser
'The XML page cannot be displayed'
Cannot view XML input using XSL style sheet. Please correct the error and
then click the Refresh button, or try again later
In the server machine's Event viewer, we found the log 'get /svnindex.xsl forbidden'.
Please note that we are able to connect the repository in TortoiseSVN & other subversion command line tools.
Is any setup or permission is needed to browse the repository in the browser ?
The account that runs VisualSVN Server service (the account is "Network Service" by default) must have Read & Execute permissions to %VISUALSVN_SERVER%. It seems that in your case the account does not have Read access to %VISUALSVN_SERVER%htdocs or %VISUALSVN_SERVER%htdocs\svnindex.xsl. Check the permissions in order to solve the issue.
Read the article KB37: Permissions required to run VisualSVN Server for more information.
I am using Liferay 6.2 and I am trying to do LDAP Authentication. The LDAP Server is provided by another organization and I do not have access to any configuration, I just have credentials for a system account to look up the directory. When I try to log in Liferay with user credentials from the LDAP Server the authentication fails with the following error code:
13:54:05,738 ERROR [http-bio-8080-exec-3][LDAPAuth:341] Problem accessing LDAP server
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr:
DSID-0315270B, problem 2001 (NO_OBJECT), data 0, best match of:
'O=uni,C=de' remaining name 'ou=people,o=uni,c=de'
The same error that occurs when trying to log in with a user that does not exist in the LDAP directory. Nevertheless, the mapping still works. After trying to log in with valid user credentials there is an entry in the liferay database with the corresponding user data. Accessing Liferay is not possible though.
These are my settings in portal-ext.properties (Test LDAP connections returns success, connection settings are pseudonymised):
ldap.base.provider.url=ldaps://ldap.ldap-server
ldap.base.dn=ou=people,o=uni,c=de
ldap.security.principal=uid=prox,ou=prox,o=uni,c=de
ldap.security.credentials=secret
#auth.pipeline.enable.liferay.check=false
ldap.auth.enabled=true
ldap.auth.required=true
ldap.auth.method=bind
ldap.import.enabled=false
ldap.import.on.startup=false
ldap.import.interval=10
ldap.export.enabled=false
ldap.export.group.enabled=false
ldap.auth.search.filter=(uid=#screen_name#)
ldap.import.user.search.filter=(objectClass=inetOrgPerson)
ldap.attrs.transformer.impl=com.liferay.portal.security.ldap.DefaultAttributesTransformer
ldap.user.mappings=screenName=cn\npassword=userPassword\nfirstName=givenNam\nlastName=sn\njobTitle=title\ngroup=groupMembership
users.email.address.required=false
users.email.address.auto.suffix=#no-emailaddress.com
users.email.address.generator=com.liferay.portal.security.auth.DefaultEmailAddressGenerator
users.email.address.validator=com.liferay.portal.security.auth.DefaultEmailAddressValidator
ldap.password.policy.enabled=false
ldap.import.user.password.enabled=true
ldap.import.user.password.autogenerated=false
ldap.import.user.password.default=test
Check the FQDN on the LDAP side, including the prefixes (cn, ou, etc.), and ensure that it matches the directory configuration within Liferay.
You can try configuring it from the control panel it will be easier for you as it allows to check whether the connection is made or not. You can check the users are fetched or not and it doesnt even need a server restart.
It works now. There were two issues:
I changed ldap.base.dn=ou=people,o=uni,c=de to ldap.base.dn=o=uni,c=de and
ldap.import.user.search.filter=(objectClass=inetOrgPerson) to ldap.import.user.search.filter=(objectClass=*)
I'm trying to connect to an admin server in WLST using config and key files. There are no error messages but I am prompted for a username and password. These files were created (by another developer who is long gone[1]) with the storeUserConfig() command. My call to connect looks something like this: connect(userConfigFile=configFile, userKeyFile=keyFile, url='t3://somehost:7031')).
Is there some restriction in using these files, such as it can only be used on the host where created, or it needs access to the domain's boot.properties file?
Note: I'm trying to connect to an admin server on a different host and non-standard port (e.g. not 7001). The server I am running WLST on and the remote host are the same version of Weblogic.
Some of the things I have tried:
verified that these files appear correct, the key file being binary data and the config file having a line for "weblogic.management.username={AES}..." and "weblogic.management.password={AES}...".
verified that there is a server on the specified port by entering a known login and password that is successful
specified the admin server in the connect parameter
turn on debug(true); the only output is <wlst-debug> connect : Will check if userConfig and userKeyFile should be used to connect to the server and another line giving the path to the userConfig file
turn on Python logging in jython with -Dpython.verbose=debug; nothing relevant to decryption operation
Munging the key or the config files generates no error messages and behaviour as above
[1]: These files are still used today by other existing WLST scripts. However, these scripts are so convoluted and deliberately obfuscated that they are very difficult to reverse-engineer how connect() is being called.
You do not need to access to the domain's boot.properties file. You just need to make sure the configFile and keyFile pointing to the right files. FYI, here is one of the commands we are using:connect(userConfigFile='./user.secure',userKeyFile='./key.secure',url='t3://somehost:7001')
Have you check the network connectity that might be having a firewall in between that troubling you, check the traceroute from the script machine to the Remote machine. Recently I have faced simalar issue. once the routing table updated with allow the WL admin server port everything got set.
Hope this could helps you!
I had this problem too. In a script, I exported the Linux variables userConfigFile and userKeyFile. Then I connected by running:
url='t3://localhost:7002'
userConfigFile='$userConfigFile'
userKeyFile='$userKeyFile'
connect(userConfigFile=$userConfigFile, userKeyFile=#userKeyFile, url=url)
That all worked in a script, but would not work interactively. I changed to doing the following:
url='t3://localhost:7002'
userConfigFile='/users/me/weblogic-2014/weblogic-admin-WebLogicConfig.properties'
userKeyFile='/users/me/weblogic-2014/weblogic-admin-WebLogicKey.properties'
connect(userConfigFile=userConfigFile, userKeyFile=userKeyFile, url=url)
And that worked interactively.
We are running Glassfish 3.1.2.2 authenticating against an Active Directory realm. Authentication works correctly the vast majority of the time, but occasionally, authentication will suddenly start failing for all users, and we'll see errors like this in the server log:
[#|2014-03-19T21:37:32.331+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=1098;_ThreadName=Thread-2;|WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for jeff.|#]
Note that the error message is failed file login. It appears as if Glassfish is occasionally reverting back to the file realm rather than the active directory realm.
When this problem happens, after a short time without any intervention on our part, authentication will suddenly start hitting Active Directory again and users will be able to login again.
Any ideas why Glassfish would occasionally revert to authentication against the file realm when we've configured it to use Active Directory? Should I delete the file realm altogether?
I finally determined the trigger for this. We had been connecting JVisualVM to our Glassfish instance to monitor performance. Everytime I connect JVisualVM (over JMX connection using Glassfish admin credentials), Glassfish immediately reverts to using the file realm instead of the LDAP realm. I have no idea why JVisualVM would cause this behavior in Glassfish, but it is consistently reproducible. The only workaround I have discovered is:
Disconnect JVisualVM.
In Glassfish admin console go to -> Configurations -> server-config -> Security
Change default realm (to anything other than LDAP realm), Save.
Change default realm back to LDAP realm, Save.
Clients should now again be able to authenticate against LDAP.
I have Openfire 3.7.1 installed on my Mac and have XAMPP installed aswell. I am having trouble configuring OpenFire. In the server settings I have given san-imac.local.lan as the domain name. The selected Standard database connection and picked MySql Database Driver. This is the databse URL jdbc:mysql://localhost:3306/test and given the username password of XAMPP phpmyadmin. But it says
A connection to the database could not be made. View the error message by opening the "/logs/error.log" log file, then go back to fix the problem.
First of all there is no such file in the /logs folder. What should I do to get this working and follow the procedures to get OpenFire up and running.
I need to build an app to connect to openfire for IM chatting like Gmail, Facebook, Yahoo using XMPP. If anybody could provide any guidance aswell, it will be very helpful.
Make Sure that your database is setup correctly including the name of your database, database username, and user's password. If you have this correctly configured then your opens ire should work just fine. Note that it will not accept if the database username has an empty password or not enough access rights to the database.
I hope that those hints will solve your problem.
check your password and username, I had the same error and it took me a while to figure out that I had my username wrong.
Resolved the issue.
log file is not getting created due to file write permission. To resolve this run OF server as follows
Run the openfire.sh file from terminal with sudo. This will start the OF with root access Now the error log file will be created.
My log file has error message as access denied to user #localhost. As I kept the user field blank in db connection page of openfire set up.
Keep the user field as root#localhost if u are using localhost.