I currently have dovecot and postfix set up, and I can log in locally because rainloop web mail works perfectly fine for both sending and receiving. However, all external login attempts simply fail, even with the correct username and password. How can I allow external logins(any config file changes, etc.)?
Please let me know about any error logs that might help, and I'll add them to this question.
I am not sure about what you mean when you say "External login",
but if you want to connect from a Mail client as Outlook for example, you should follow the steps of this tutorial : https://support.rackspace.com/how-to/dovecot-installation-and-configuration-on-centos/
Then you would be able to connect Outlook (or any other mail client) to your local Postfix mail directory from any server that is connected to the same local network
Hope it helps !
Related
I am working on database 19c and Apex 21.1..when I open Apex normal, I get the error message
The request could not be mapped to any database. Check the request URL is correct, and that URL to database mappings have been correctly configured
I checked the service to turn it on, and I got a new service that was not included in the Oracle service
Its name is OracleRemExecServiceV2
And it is the causes a problem, when I run it, the error message appears
windows could not start the oracleremexecservicev2 service on local computer
the system can not find the file specified..enter image description here
please help me to solution this problem
I have successfully installed SnowSQL Client version 1.2.5 and while trying to get log into my snowflake account, using account id, username and password, I am somehow unable to connect and get following error:
snowsql unable to log in
This appears to be networking issue. Have you tried to set that debug logging as directed?
To assist in situations like this, Snowflake has a tool which could help you determine if your client host is able to access all required network endpoints for your Snowflake account, it's called SnowCD, the documents are here and the installation is fairly straightforward:
https://docs.snowflake.com/en/user-guide/snowcd.html
I'd recommend trying SnowCD as your first step, the next step would be to review any required proxy settings your organization might have. I'd also double-check your "account name" argument, the URL looks OK to me but there is a nice writeup on the account name construction at this link:
https://docs.snowflake.com/en/user-guide/connecting.html#your-snowflake-account-name
I hope this helps...Rich
THANKS Rich for doing some R&D and sharing proposals. I got successfully logged into snowsql by providing my account id till ".aws". Hope it will help others struggling so far, like myself:
https://docs.snowflake.com/en/user-guide/getting-started-tutorial-log-in.html
demo log in
I built a Java application which connects to Salesforce to access data. However, this connection only works for the sandbox account and not when I pass the production accounts credentials.
I set up the connection in the following manner,
Connector.newConnection(config)
The error I get is as follows,
[LoginFault [ApiFault exceptionCode='INVALID_LOGIN'
exceptionMessage='Invalid username, password, security token; or user locked out.'
extendedErrorDetails='{[0]}']]
Does anyone know how to solve this? Is there some sort of dependency I am forgetting?
This was an issue with the partner.jar that was used. This has the endpoint hardcoded as test.salesforce.com. Therefore would never work in the production environment as the log in wouldn't even go to the correct URL.
Therefore, you should always remember to generate the partner.jar from the partner.wsdl provided by the production environment and add it. The endpoint here is hardcoded as login.salesforce.com.
All the sites on this DNN installation stopped sending emails yesterday. When you try and test SMTP in host settings, it sends the test email without any issues.
At first I thought my IP might be blacklisted, but then surely the SMTP test would also fail?
I'm pretty sure the Test SMTP setting in Host directly calls the send mail service in DNN's API. But many other emails are queued up for dispatch for scalability.
Check to see if your "Messaging Dispatch" job in Host > Scheduler has been disabled. If not, check the history by clicking the Log icon on the right-hand side of the schedule tasks list. See if there are errors logged in there.
If all is good there, check your Logs in /Portals/_default/Logs for any issues related to messaging or SMTP.
I would start by checking to see if you have defined a valid (usable) email address on your ADMIN account. DNN will "send" emails from whatever the Administrator is in the site settings, so check the email address on that user's profile, make sure that the email/domain is valid and the SMTP settings you are using are allowed to send from that domain.
If you are developed contact-form dynamic module in your DesktopModules folder then you have to call below DNN SendMail method in your submit button click event.
DotNetNuke.Services.Mail.Mail.SendMail(FromEmailAddress, ToEmailAddress, CCEmailAddress, BCCEmailAddress,
DotNetNuke.Services.Mail.MailPriority.Normal,
EmailSubject,
DotNetNuke.Services.Mail.MailFormat.Html,
System.Text.Encoding.UTF8,
EmailBodyMessage, "", "", "", "", "");
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.