We Keep Coding

java.security.properties - changes not applied

I try to append security properties to java.security.
Hence I add a property "java.security.properties" specifying the file to be appended.
I checked that security.overridePropertiesFile is set to true.
For some reason the changes to the security policy are not applied.
If I change the file "java.security" directly everything works fine.
Either the file cannot be found or the content of the file is not correct.
I do not get any error message about the location. I tried absolute, relativ paths.
The content of the file is the following (one line):
jdk.tls.disabledAlgorithms=ECDH, DH, RC4, DES, MD5withRSA, 3DES_EDE_CBC, DESede, DES, anon, NULL
I guess there is something wrong with the path but don't know since there are no logs about it.
Couln't find good information about the path though. All examples are relativ paths which do not work either for me.
I am using JDK11.

Try running your application with -Djava.security.debug=properties on the command line. If there is an issue loading the file, you should get a message such as "unable to load security properties from <filename>" with an exception stack trace.
Also, you should set the java.security.properties system property on the command line if possible. If not, it should be set as early as possible in your code; otherwise depending on what the application does, it may read and cache the values of security properties from the java.security file before it loads your properties file.

Invalid path of external Kafka keystore and truststore

My app connects to Kafka topic and everything goes well in local environment when truststore and keystore are stored under classpath, but when I try to switch to Dockerized external environment and point to those files localized on a server, then the app crashes.
Snippet in a local environment where it works:
spring.kafka.ssl.trust-store-location=file:src/main/resources/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:src/main/resources/keys/application.keystore.jks
Snippet of application.properties on a server side when the app is launched inside a docker container and does not work. Both keys are stored in /deployment/keys folder inside the container:
spring.kafka.ssl.trust-store-location=/deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=/deployment/keys/application.keystore.jks
The following java exception occurs:
NoSuchFileException: /tmp/tomcat-docbase.45456574985379.8080/deployment/keys/application.keystore.jks
So for an unknown reason Spring Boot inside Docker container adds the /tmp/tomcat-docbase.45456574985379.8080/ prefix to the keystore and truststore location.
I have also tried:
spring.kafka.ssl.trust-store-location=file:/deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:/deployment/keys/application.keystore.jks
and
spring.kafka.ssl.trust-store-location=file:///deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:///deployment/keys/application.keystore.jks
but none of them seem to work. I would not like to change the code but what comes to my mind is to create a Properties object and create strings with those paths. Then inject them to the KafkaTemplate as a bean. However, I have not yet checked if this could help. Would rather focus just on adjusting application.properties file than correct the code. Could you please help me find the solution?

Fuseki server doesn't show datasets

I'm new to Tomcat, Fuseki and the Shiro.ini file, so forgive me for asking silly questions.
System:
MacMini ==> OS.X 10.13 (acts as dev-server)
Java ==> 8
Tomcat ==> 9.0.10
Workflow:
Via a Plist file, the Tomcat instance gets started on each boot of the server.
in /Users/username/tomcat/webapps I've put the fuseki.war file which got extracted successfully.
I inserted a custom made RDF-file, which gets loaded after reboots and served
(this is where the good things end)
Problem:
I can access the RDF file through: http://localhost:8080/fuseki, I can perform SPARQL-queries and everything else I need to get done. However, when connecting the dev-server to a PC and accessing it through it's IP: e.g.http://192.168.0.112:8080/fuseki; I end up seeing the server which has a green status, and the entire web-interface works except for the datasets. When I go to http://192.168.0.112:8080/fuseki/dataset and press 'query' (or any other button) it displays: "Please select a database"
**Cause:
I found this thread fuseki webinterface does not show datasets (SO), which lead me to investigate the shiro.ini file. As it turns out I don't have one.
I then searched for shiro.ini and found a reference in /Users/username/tomcat/webapps/fuseki/WEB-INF/web.xml:
<context-param>
<param-name>shiroConfigLocations</param-name>
<!-- Try a path in: FUSEKI_BASE, FUSEKI_HOME, war resource
If a "file:" then look there and there only.
-->
<param-value>shiro.ini</param-value>
</context-param>
This made me think that I'd need to put the shiro.ini file in my root folder (Users/username/tomcat/webapps/fuseki/shiro.ini) and not in (Users/username/tomcat/webapps/fuseki/run/shiro.ini). However neither work.
I also looked in a logfile: catalina.out, based from that it seems that the shiro.ini file gets loaded (or at least there are no indiciations that there's an error with it.)
Here's the relevant extract from that log:
[2018-07-31 09:18:54] Config INFO FUSEKI_HOME=unset
[2018-07-31 09:18:54] Config INFO FUSEKI_BASE=/etc/fuseki
[2018-07-31 09:18:54] Config INFO Shiro file: file:///etc/fuseki/shiro.ini
[2018-07-31 09:18:55] Config INFO Context path = /fuseki
[2018-07-31 09:18:55] Config INFO Configuration file: /etc/fuseki/config.ttl
I can't find however any folder etc/fuseki/? So what's up with this to start with?
Here is the shiro.ini file:
[users]
admin=passXXX #non-default
[main]
#localhost=org.apache.jena.fuseki.authz.LocalhostFilter
[roles]
[urls]
##control open to anyone
/$/status = anon
/$/ping = anon
##rest restricted to Localhost
## see above for localhost
#/$/** = localhost
/**=anon
I'm not sure what's going on at this point, so any pointers are more than welcome.

Turns out the issue had more to do with my unfamiliarity with the MAC OS, than with Tomcat or Fuseki.
The folder /etc/fuseki which was referenced in the catalina.out file is tightly locked and it's actual path is /private/etc/fuseki (though this doesn't seem to matter)
By default you can't enter the fuseki folder due to no rights at all. Even doing:
sudo cd /private/etc/fuseki
or
sudo cd /etc/fuseki
won't work. I needed to give myself read/write access to the folder via getinfo (though I think you could achieve this as well via chown.
Now I could view that folder's content, yet all files and folders in there had the same issue and required the same solution. So now I could customize the shiro.ini and configuration/rdf.ttl file.
If I do
sudo cd /private/etc/fuseki
or
sudo cd /etc/fuseki
now, then I can successfully view the content.

Accessing HDFS on Cloudera with Java and Kerberos Keytab from Windows

I'm trying to connect to my HDFS instance running on Cloudera. My first step was enabling Kerberos and creating Keytabs (as shown here).
In the next step i would like to authenticate with a keytab.
Configuration conf = new Configuration();
conf.set("fs.defaultFS", "hdfs://cloudera:8020");
conf.set("hadoop.security.authentication", "kerberos");
UserGroupInformation.setConfiguration(conf);
UserGroupInformation.loginUserFromKeytab("hdfs#CLOUDERA", "/etc/hadoop/conf/hdfs.keytab");
FileSystem fs = FileSystem.get(conf);
FileStatus[] fsStatus = fs.listStatus(new Path("/"));
for (int i = 0; i < fsStatus.length; i++) {
System.out.println(fsStatus[i].getPath().toString());
}
It fails with the following error
java.io.IOException: Login failure for hdfs#CLOUDERA from keytab
/etc/hadoop/conf/hdfs.keytab:
javax.security.auth.login.LoginException: Unable to obtain password
from user
The question is: how do I correctly handle the keytab? Do i have to copy it to my local machine?

When running a Hadoop client on Windows to reach a kerberized cluster, you need a specific "native library" (i.e. DLL).
As far as I can tell there is no good reason for that, because that lib is not actually used outside of some automated regression tests (!?!) so it's a pain inflicted to Hadoop users by Hadoop committers.
To add extra pain, there is no official build of that DLL (and of the Windows "stub" that enable its use from Java). You must either (a) build it yourself from source code -- good luck -- or (b) search the internet for a downloadable Hadoop-for-Windows runtime, and pray that is does not contain any malware.
The best option (for 64-bit Windows) is here: https://github.com/steveloughran/winutils
...and the ReadMe explains why you can reasonably trust that run-time. But if you are stuck with an older 32-bit Windows, then you are on your own.
Now let's assume you deployed that run-time on your Windows box under
C:\Some Dir\hadoop\bin\(the final bin is required; the embedded space is just extra fun)
You must point the Hadoop client to that run-time with a couple of Java properties:
"-Dhadoop.home.dir=C:/Some Dir/hadoop" "-Djava.library.path=C:/Some Dir/hadoop/bin"
(note the double quotes around Windows args as a whole, to protect embedded spaces in the paths, which have been translated to Java style for extra fun)(in Eclipse, just stuff these props under "VM Arguments", quotes included)
Now, there's the Kerberos config. If your KDC is your corporate Active Directory server, then Java should find the config parameters automatically. But if your KDC is a standalone "MIT Kerberos" install on Linux, then you have to find a valid /etc/krb5.conf file on the cluster, copy it on your Windows box, and have Java use it with an additional property...
"-Djava.security.krb5.conf=C:/Some Other Dir/krb5.conf"
Then let's assume you have created your keytab file on a Linux box, using ktutil (or an Active Directory admin created it for you with some AD command) and you dropped the file under C:\Some Other Dir\foo.keytab
Before anything else, if the keytab is for a real Windows account -- i.e. your own account -- or a Prod service account, then make sure that keytab is secure!! Use the Windows Security dialog box to restrict access to your account only (and maybe System, for backups). Because that file could enable anyone, on any machine, to authenticate on the cluster (and any Kerberos-enabled system, including Windows).
Now you can try to authenticate using
UserGroupInformation.loginUserFromKeytab("foo#BAR.ORG", "C:/Some Other Dir/foo.keytab");
If it does not work, enable the Kerberos debug traces with both an environment variable
set HADOOP_JAAS_DEBUG=true
...and a Java property
-Dsun.security.krb5.debug=true
(in Eclipse, set these in "Environment" and "VM Arguments" respectively)

Do you have set proper permissions?
chown hdfs:hadoop /etc/hadoop/conf/hdfs.keytab
chmod 440 /etc/hadoop/conf/hdfs.keytab

webservices - wsimport hangs on parsing WSDL

These are my environment variables:
System variables:
JAVA_HOME C:\Program Files\Java\jdk1.8.0_20\
Path:
...;C:\Program Files\Java\jdk1.8.0_20\bin;...
I key the following in the command line:
c:\wsimport>wsimport http://www.webservicex.net/geoipservice.asmx?WSDL -Xdebug
I receive the following message
[DEBUG] Authorization file "C:\Users\myPC.metro\auth" not found. If
the WSDL access needs Basic Authentication, please provide
authorization file with read access at C:\Users\myPC.metro\auth or
use -Xauthfile to give the authorization file and on each line
provide authorization information using this format : http[s]://user:password#host:port//
parsing WSDL...
Where my configuration is incorrect?

I am not sure what happened but it's working now. It seems like my issue was perhaps related to my internet connection. I was online but the connection was pretty slow. Now everything's back to normal and my wsimport command is working.