I'm trying to use JetS3 to access Amazon S3 in an app which also uses Jersey with Grizzly (unsure if that is relevant). My dev environment is Eclipse on OSX 10.7.3 using JRE version 1.7.0u.jdk.
I've read that it relates to not being able to find a "keystore", whatever that is - but it shouldn't need to use any local keys, I'm already providing it with the authentication information for S3 programmatically.
I don't know if this is an issue with my code, or with my dev environment, can anyone help?
edit: I added the following on the command line:
- Djavax.net.ssl.keyStore=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home/jre/lib/security/cacerts
This file exists, but I'm still seeing the same error :-(
The intersection of Java's file tree and Apple's packaging system strikes again!
I just solved something similar to this (I think the legacy of a botched beta upgrade). Same error, at least. The situation I found on my disk was that there were symbolic links in my JDK installation instead of actual files (including cacerts):
> ls -lt /Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Home/lib/security/
total 24
lrwxr-xr-x 1 root admin 79 Apr 7 15:11 blacklist -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist
lrwxr-xr-x 1 root admin 81 Apr 7 15:11 cacerts -> /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
lrwxr-xr-x 1 root admin 87 Apr 7 15:11 trusted.libraries -> /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries
Unfortunately the linked Deploy.bundles did not exist.
In my case, I was able to look back in Time Machine, and find the deleted bundles and restore them.
You may have some older versions already in place that you could link to. At the least you should be able to look and see if you've got a similar underlying issue.
Sorry it's not a complete solution, but I hope it gets you a little farther down the road.
You could always just get the distribution from Oracle, and pop the cert files in place, though if your installation is missing other items there might be other problems.
On google I found this blog:
http://architecturalatrocities.com/post/19073788679/fixing-the-trustanchors-problem-when-running-openjdk-7
The problem there is the openjdk not including the files, and he recommends linking to the Bundle file that I had to restore in my case.
Related
In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
I am facing issues while trying to run mule 3.5.3 as non root user in docker container. It works fine when the root user is used.
The Mule startup process is creating a file tx1.log during startup, this file does not have any permissions and later during the startup it tries to read this file which leads to (java.io.FileNotFoundException - Permission denied).
The file location is /.mule/.agent/queue-tx-log/tx1.log.
I also tried with umask 777 added to /mule and /launcher scripts, but it did not help.
Is there a do's and dont's for running mule as non root?
Any help/pointers are appreciated.
note: chown and chmod have been used where ever I felt necessary necessary.
Mule runs perfectly well as non root and that is the recommendation because of security best practices. The only issue I have seen is if it is started as root first, it creates files with root ownership, then a non privileged user is not able to use those files.
From the comments I can see that the problem seems to be on the operating system or docker/kubernetes. Mule just doesn't do weird things with permissions.
Aside that, note that Mule 3.5.x will reach it's end of life sat July 15, 2019. I recommend to migrate to a newer version.
I want to collect some buggy files.
So, I found data-set that present which file has a bug.
In data set, document said that Tomcat,6.0.389418,org.apache.jasper.compiler.Compiler file has a bug
In order to get bug file, i visit apache svn repository. And I found archive tomcat version 6_0_38 (http://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38)
But I cant get file more detail version (6.0.389418) there is only 6_0_38
Can I think of two versions as the same?
Thank you.
Most importantly, you should know that Tomcat 6 has seen its end of life in December 2016, and the latest version that I can find in the archives is 6.0.53.
Based on this alone: Upgrade! First to the latest version in the 6.0 branch, then to a version that actually will continue to get security fixes. I've never seen any problems when upgrading within the same major version - the tomcat developers do a great job keeping their upgrades compatible.
And last, to the letters of your question instead of the spirit: The third digit of Tomcat version numbers is counting up, one by one. There is no 6.0.389418. As Tomcat uses Subversion, and subversion counts up the commits one by one, you might be lucky to find something around commit #389418 or #9418. Note: I've not even looked at their SVN to check if these are legitimate commits in the time that you're referring to (not even what the current commit is).
Eh, it might be quite hard to really nail this build number, but there is also a good chance this is a build you are asking for. Read for explanation.
You are asking for version: 6.0.389418
If you look into this file:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/dist.xml
You can learn how build number is being built:
<property name="version.number" value="${version.major}.${version.minor}.${version.build}.${version.patch}"/>
values are taken from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/build.properties.default
# ----- Version Control Flags -----
version.major=6
version.minor=0
version.build=38
version.patch=0
version.suffix=
So the missing part of your version is 9418 which is should correspond to ${version.build} or (more unlikely) to ${version.patch}
In either case it might be not unambiguous, because often there is a build script used which performs multiple actions and as a result, appends its own version at the end of real package. I'd lean towards this explanation, because if this were to be a patch number, there would be some /patches directory in SVN, which I don't see in any other directories for more recent development.
But then, there is:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/version.sh -> running function from:
https://svn.apache.org/repos/asf/tomcat/archive/tc6.0.x/tags/TOMCAT_6_0_38/bin/catalina.sh
elif [ "$1" = "version" ] ; then
"$_RUNJAVA" \
-classpath "$CATALINA_HOME/lib/catalina.jar" \
org.apache.catalina.util.ServerInfo
else
Try to download it and run ./bin/version.sh
[2]> (ql:quickload "cl+ssl")
To load "cl+ssl":
Load 1 ASDF system:
cl+ssl
; Loading "cl+ssl"
*** - Unable to load any of the alternatives:
("libssl32.dll" "ssleay32.dll")
After three days of banging my head against the wall, I'm asking my first question on stack overflow. And with any luck it won't get deleted, and with heaps more there will be a solution.
While trying to install Humbler via quicklisp, CL+SSL (one of several dependencies) complained of being "Unable to load any of the alternatives: (libss132.dll "ssleay32.dll")
I soon learned that I had to install the OpenSSL dlls, easily enough done. I also learned I may have to point CFFI in the direction of my dlls, and that I had to be sure to get the 64 bit versions. But that error has persisted.
Using Clisp 2.47 on Win 7 64
Things I have tried already:
Installing open ssl dlls
Installing VS 2008 Redist
Putting those dlls in system32
Putting them in the same folder as the Clisp .exe
Putting them in in the installation folder created by OpenSSL
Pointing to the exact location of each individual dll using "use another library instead" restart
Pushing various locations to the CFFI:Foreign-Library-Directories list
Break 1 CL+SSL[3]> :R2
Enter a new value (unevaluated): ("C:\OpenSSL-Win64\libssl32.dll")
*** - Unable to load foreign library (LIBSSL32.DLL-8079).
FFI:OPEN-FOREIGN-LIBRARY: Cannot open library "C:\OpenSSL-Win64\libssl32.dll"
Uninstalling and then installing all the different OpenSSL builds
available Running Clisp as an administrator Deleting Quicklisp's
cache of CL+SSL Doing all of the above steps in SBCL and Lispworks
Turning it off and on again
I've never asked a question on stack overflow before. Then again I've never spent three days trying to get a dependency to load. Please help before I have a stroke.
It turns out I did need the 32 bit version of OpenSSL v 1.0.1
I guess the bit depth of the compiler reigns supreme. Sounds obvious in retrospect.
I've pushed my artifact to oss nexus repo, added it as dependency to another project. Idea keeps me warning:
[warn] Unable to reparse com.github.kondaurovdev#jsonapi_2.11;0.1-SNAPSHOT from sonatype-snapshots, using Fri May 13 17:12:52 MSK 2016 [warn] Choosing sonatype-snapshots for com.github.kondaurovdev#jsonapi_2.11;0.1-SNAPSHOT
Maybe i pushed artifact somehow in a wrong way? But i did it earlier, everything was ok. How to get rid of these warnings? Or just ignore them?
I had the same issue.
Did you publish your SNAPSHOT version to your artifactory? If so this might be your problem.
As you know when publishing locally your snapshot version is stored in the .ivy2/local directory. The remote version are stored in the .ivy2/cache directory.
When looking into the .ivy2/cache/{dependency} folder you will see that it has only downloaded the xml and properties file. So just the metadata and no jars. This is the actual reason why it can't be parsed since it's not there.
Since the .ivy2/cache takes precedence over .ivy2/local it won't see your local published version. There are 2 ways to fix this.
Update your snapshot version number(recommended)
Remove the SNAPSHOT from your artifactory and remove the .ivy2/cache/{dependency} folder on every client that has a local version.
In my opinion the first one is the way to go.
I had the same issue, and it goes away after I add the follow in my build.sbt:
updateOptions := updateOptions.value.withLatestSnapshots(false)
You can find more detail from https://github.com/sbt/sbt/issues/2650