I installed the Dreamfactory Framework from GitHub on a Debian 11 driven Virtual Server.
After installation I can access the login dialog and the data are correctly evaluated, allowing me to access the framework. However instead of the control panel, I just receive the following message:
Sorry, there was a problem loading system config. Please contact your
system administrator.
Does anybody have an idea, what I can do to solve the issue?
Related
Having problem where the Mirth Connect Server Manager UI points to an earlier, non-working install version of the Admin interface.
Installed Mirth once and had to reinstall because the original install had set the password requirements to something that the default admin account could not pass. When I did this, the installer said that it detected that Mirth was already installed and asked if I wanted to re-install and I said yes. However, the Admin UI that the Mirth Connect Server Manager windows that remains in the upper menu bar of my desktop still appears to be using the old install with the password issue.
The Mirth Connect Server Manager icon in the upper menu bar takes me to wrong setup. Can't log in from the Admin UI that this bring up (told can't authenticate or connect (which was the problem I had with the earlier install)).
Need to use the Program from here
and make sure that I chose the right one, then I am able to use the default admin account to log in and proceed as normal.
Anyone know how to fix this (eg. somewhere in the underlying files where I can change this)? Anything else I should check that may be messed up due to this problem that I may not be noticing? I am on Ubuntu 18.04.4LTS MATE.
In the installation folder\conf\mirth.properties file, change the HTTP and HTTPS ports to values different from the prior one. Get to your browser type localaddress:new_http port then click on the icon -launch Mirth Connect administrator. Clicking the saved shortcut will launch an admin launcher which will allow you to edit and save the functional instance.
I've been installing our very own ArcGIS Enterprise instance on AWS.
The instance I chose is ArcGIS Enterprise on Ubuntu.
It is important to mention that this installation was conducted without using Cloudbuilder. I know it is a tool that automates the process but I was introduced to it only after I have already started to attack my current instance problems head-on. So, please don't advise me to restart the whole process from scratch using it.
The current status of my instance is that my ArcGIS Server is working. I can access it, upload services and we have already started using it in out Staging environment.
I have authorized all of the software on the server and verified it is licensed. The Portal for ArcGIS is my main problem.
Whenever I try to access it externally(from my office computer) it seems to redirect to the internal IP for some reason, and then times out on that request.
for example typing(from my browser):
https://[dns address]:7443/arcgis/home
redirects to:
https://[internal IP]:7443/arcgis/home
and this times out. (...took too long to respond error)
The funny thing is I can access the portaladmin area.
it's only the portal itself which doesn't work.
Also, another curious thing is that if I type without using the ports, I can access a window but exceptions are thrown in the browser.
For example:
https://[dns address]/arcgis
This will lead to a window where the ArcGIS world icon can be seen but nothing else loads and there are exceptions for "resource not found" 404 on some of the components of this page.
Any ideas? What further information should I include to answer this question?
I've looked everywhere but Esri's documentation is not very forthcoming with examples and information to understand what it is I did wrong.
Also, I don't think this is a ArcGIS software issue. It looks like this might be a proxy issue. Anyone else experienced something like this?
Thanks!
I found the solution.
It was a combination of two problems:
Tomcat that was running the web adaptor service was crashing because of an entirely different and unrelated issue.
The Portal was missing a web adaptor configuration and therefore did not have the WebContext property set with the web adaptor URL.
After fixing both of these problems, I was able to access the portal correctly.
I've installed the latest W-Systems DocuSign module for SugarCRM and I followed the installation guide to the T (https://www.w-systems.com/media/DocuSign/SugarConnectortoDocuSign_InstallationUseGuide.pdf). However, my problem start at the end of page 7 where I click "Configure DocuSign" or "DocuSign User Settings > Log In". Nothing happens.. no error message, no dialog window, nada.
I've run "Rebuild JS Grouping Files", "Quick Repair and Rebuild", cleared the cache and tried multiple browsers.
Has somebody else encountered this problem? Any suggestions on how to solve it?
EDIT: I was able to use the module without problems on a co-workers machine, but I still cannot use it on my own.
The SugarCRM <-> DocuSign Connector is written and maintained by SugarCRM, not DocuSign. The only integrations (Connectors) that DocuSign implements and maintains are its integrations with Microsoft, Google, and Salesforce.
With that said, if you're running into bugs/issues with the connector you'll need to contact SugarCRM and go through their support to resolve.
After being in contact with W-Systems support, they found out (by looking at the debug logs) that the database tables hadn't been correctly set up. The problem was fixed by uninstalling the module (without removing the tables), reinstalling the module, Admin > Quick Repair and Rebuild, and finally hard refresh (for me Ctrl+F5).
Everything now runs normally.
I'm having difficulty in integrating AEM 5.6.1 with Site Catalyst. It allows me to connect in the configuration successfully, but does not work on the framework setup.
I've followed the standard procedure to connect AEM to SC and it accepts my login in the configuration, but fails on the framework set up with the browser message 'We were not able to login to SiteCatalyst. Please check your credentials and try again.'. Behind the scenes in the server log;
12.12.2014 14:10:06.967 *WARN* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.SitecatalystHttpClientImpl Data center 'https://api3.omniture.com/admin/1.3/rest/' responded with errors {"error":{"code":500,"message":"Internal Server Error"}}
12.12.2014 14:10:06.967 *ERROR* [0:0:0:0:0:0:0:1 [1418393406764] POST /libs/cq/analytics/sitecatalyst/service.json HTTP/1.1] com.day.cq.analytics.sitecatalyst.impl.servlets.SitecatalystServlet Call to SiteCatalyst method 'Company.GetReportSuites' failed com.day.cq.analytics.sitecatalyst.SitecatalystException: not authenticated
I've tried accessing via the API Explorer and it works.
I've tried the troubleshooting guide without success.
I can log in to Site Catalyst, I'm an admin, I am in the web services access group.
I've tried using a clean install of CQ5.6.1 with geometrixx - it doesn't work either.
I've tried this from a server and from a localhost/dev machine with the same results. No proxy. I've even tried using the shared secret as the password but then it doesn't connect at all, and fails on the configuration screen.
What might cause this to fail?
If it doesn't work with a fresh install and Geometrixx, then it's probably an Adobe bug. That's typically the first thing support will ask you about.
I would also verify using Geometrixx Outdoors, or a more recent demo site, on your fresh install, just to ensure it's not an outdated ClientLib issue.
I know this isn't a direct answer to your question, but honestly, I would approach the integration differently. I've worked with the AEM-SC framework and it's buggy at best. It's very finicky, it doesn't REALLY work the way the documentation claims, and it requires that you're very specific about what Clientlibs are on the page.
Moving forward, I think using Adobe Dynamic Tag Manager is the better approach, for many reasons. My understanding is that it's Adobe's recommendation as well. I'd consider moving to that. In AEM 5.6.1, you'll have to customize your integration with DTM, but it's not very hard.
Solution: Add a property on the configuration node for sitecatalyst: (eg. /etc/cloudservices/sitecatalyst/my-sc-configuration)
server=https://api.omniture.com/admin/1.2/rest/
it also seems to work with newer API versions such as https://api3.omniture.com/admin/1.3/rest/
It would appear that for 5.6.1 it ignores the OSGi configuration, at least for the configuration screens. With this extra property, the framework page loads without error and allows selection of the RSID.
I've got SQL Server 2008 with SSIS/SSRS installed on my development box. I followed through the installation notes and everything appeared to install just fine - no errors or anything. I've got it configured using all the defaults for now until I figure out what is what. So the server can be accessed via http://localhost:80/ReportServer and the reports via http://locahost:80/Reports.
I've created a dummy report against the AdventureWorks database to test report creation and deployment and after some initial headaches which were resolved by running BIDS as an administrator, I'm having problems accessing the reports via the web interface and indeed, I'm having the same issue accessing the report server via the web interface.
When I open the URLs in any browser - IE/Firefox/Chrome they all prompt me for credentials. My dev box isn't part of a domain and the credentials I use to log into the machine don't appear to be what it is after as they don't connect successfully. I don't really understand why it's asking for credentials at all due to the fact that the address is an intranet address. In either case, IE is configured to pass through my Windows credentials when logging into machines on the intranet.
Did I configure something incorrectly when I set it up? Does anyone have any decent tutorials for not only installing SSRS, but configuration for development machines.
Try opening your browser with elevated (Administrator) privelages. Did that help?
This may also be related...
http://blogs.msdn.com/b/lukaszp/archive/2008/07/18/reporting-services-http-401-unauthorized-host-headers-require-your-attention.aspx