This happens on all my CMS guests on my z/VM 7.20 system, running on a z14. I have tried REIPLing but that hasn't fixed the problem.
The 'Shared S-STAT not available' or 'Shared Y-STAT not available' messages appear at logon when either the 190 S-disk or 19E Y-disk respectively were changed after the CMS NSS was last saved. You just need to rebuild the CMS NSS to make these go away.
To rebuild the CMS NSS:
Logon to the MAINTrvm service ID for your release. Ex: For z/VM 7.20: MAINT720.
Issue PUT2PROD SAVECMS
Related
I've installed Flowable 3.6.1 in my localhost. But when I changed the Host configuration in Tomcat folder, I found flowable-design was unable to publish app to flowable-engage.
After tens of times attempts, I found the configuration located at Tomcat/webapps/flowable-engage/WEB-INF/classes/flowable-default.properties as following:
flowable.common.app.idm-url=http://localhost:8080/flowable-work
flowable.common.app.idm-admin.user=admin
flowable.common.app.idm-admin.password=test
So, I changed admin's password here, but it was not working actually. However, I guess the file name was the problem. Then I changed the file name to flowable.properties, it was still not working.
REMEMBER: In Tomcat/webapps/ROOT/index.html, flowable told that username and password in different flowable application is independent. If you want to change admin's password, you had to know which application you are going to apply these changes.
After a long time digging, I finally found the solution to put these three configuration in Tomcat/bin/setenv.bat as following:
set "JAVA_OPTS=%JAVA_OPTS% -Dflowable.common.app.idm-url=http://<domain>/flowable-engage/ -Dflowable.modeler.app.deployment-api-url=http://<domain>/flowable-engage/app-api -Dflowable.modeler.app.undeployment-api-url=http://<domain>/flowable-engage/platform-api/app-deployments -Dflowable.common.app.idm-admin.user=admin -Dflowable.common.app.idm-admin.password=<password>"
And these properties are loaded in flowable-ui-design-conf module, look
at
com.flowable.design.conf.ApplicationConfiguration#basicHttpClientProvider(FlowableCommonAppProperties commonAppProperties) for more information.
Cause I want my flowable-design to be able to deploy app to flowable-engage, so I changed admin's password in flowable-engage.
I have Data Virt running via the standalone.sh script, and can log in with my username and password. My next task is configuring it so that it automatically runs whenever the instance is up and running (without having to execute standalone.sh), and uses SSL (port 443) rather than my username and password to log me in. I added the vault.keystore, dv_keystore.jks, and dv_truststore.jks files, and modified both standalone.sh and standalone.xml, according to the JBoss and other online documentation, to account for using these files. I start the standalone.sh script, which runs without any errors. When I browse to:
http://<IP>:8443/dashboard
after starting standalone.sh, I get the following error:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://:8443 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4, which is not considered secure. Please contact your site administrator.
The settings Use TLS-1.0-ON, Use TLS-1.1-ON, and Use TLS-1.2-ON are all checked in the Browser properties.
By contrast, when I browse to
http://<IP>:8443/dashboard
when standalone.sh is not running, I get the following:
This page can't be displayed
- Make sure the web address https://:8443 is correct.
- Look for the page with your search engine.
- Refresh the page in a few minutes.
It appears the browser is sensing something going on when standalone.sh is running, but something is not allowing the browser to access the dashboard.
What am I missing here?
Have you validated any other ssl access? Is it just an issue with the dashboard application?
A client of mine has trouble with TortoiseSVN. It was working fine till now. She did her last commit on Thursday Feb. 23. 2013 But now she gets the following error:
OPTIONS SSL handshake failed: SSL error: sslv3 alert illegal parameter
She cannot access the Repository anymore. No update, no checkout, no log, etc.
It is difficult to locate the problem. It shows up with tsvn 1.7.4 and 1.7.11
She cannot use tsvn with the ProjectRepository
She cannot use svn commandline client (http://www.sliksvn.com/en/download) with the ProjectRepository
She can use tsvn with a PlaygroundRepository on another Server
She can access ProjectRepository with IE and with Firefox
She can access ProjectRepository with SmartSvn
I can use tsvn in their network with the ProjectServer from my macbook with parallels.
I entirely uninstalled/reinstalled tsvn -no success
I deleted %appdata%\Roaming\Subversion -no success
As an act of desperation, I installed smartsvn which makes her work again, but this cannot be the solution.
It must be the combination of tsvn, her machine and the ProjectRepository/Server. Her Machine works with PlaygroundRepository on another server.
Any Idea is highly welcome. In paticular due to the fact that it worked last week with tsvn 1.7.4.
So the only thing which might have changes is some updates on the windows box.
Check for the installation of MS012-006 on the client. That hot fix broke a lot of things. Roll it back and see if connects are successful.
Our code-signing certificate recently expired. It's been renewed, but now whenever I try to package the app with the renewed cert (whether I attempt a migration of the expired cert or not), after installation, I get the following message any time I try to run the app:
"This installation of this application is damaged. Try re-installing or contacting the publisher for assistance."
Opening up the package contents, the publisherid file inside Resources/META-INF/AIR is blank. This is apparently the problem, because if I manually edit it to contain our previous publisherID, the app will run.
But of course, it's not like we can tell all our users "oh install it then manually edit this file inside the package."
Has anyone encountered this or know how to fix it?
Ah, after a bit more banging my head against my desk I got it.
For anyone who comes after me:
I had to change a couple things in my app descriptor file.
First I had to change the namespace to point at AIR 1.5.3 instead of 1.5
<application xmlns="http://ns.adobe.com/air/application/1.5.3">
And then I had to manually specify our old publisherID in the descriptor as well
<id>OurAppID</id>
<publisherID>OurOldPublisherID</publisherID>
Now it works just as it's supposed to, installs as an update to our old version instead of a new app, and actually runs instead of just throwing that error.
While I was trying to start ApacheDS 1.5.7 on windows platform, An Error 04450 occurs and the apacheds-rolling.log contains:
[21:07:27] ERROR [org.apache.directory.shared.ldap.entry.DefaultServerAttribute] - ERR_04450 The value {0} is incorrect, it hasnt been added
[21:07:27] ERROR [org.apache.directory.server.Service] - Cannot start the server : reuseAddress can't be set while the acceptor is bound.
How can i fix this problem? Anybody could help me? many thanks!
The warning log message is a bit misleading, actually this is not a serious issue, the server should be running despite of this warning, this has been fixed a while back in the latest trunk code (which will be released as 2.0 instead of 1.5.8).
According to this post, the dc=example,dc=org context entry is not created by default anymore but no one has updated the documentation to reflect this. I installed 1.5.7 and it looks to me like the partition was created fine, but I'm getting the same error as described above. I suggest installing an older version.
The 2nd error message suggests that the port is already in use. Is there a chance that you already had another ApacheDS process running, or that another program is using the ports?
This isn't a domain controller perchance, is it? If so, the default LDAP ports 389 & 636 are already in use for Active Directory, so you'll need to choose another. However, I believe the defaults for ApacheDS are 10389 (LDAP) and 10636 (LDAPS), in which case they would typically be open on a Windows box.
You can check for processes on the ports with the netstat -abn command, and look through the list for the process listening on port 10389 or whichever custom port you chose.