Testing my action via wsk command when in the vagrant VM it gets the parameters successfully but when attempting to open a file it throws:
FileNotFoundException: /ild/data/workspaceArtifacts/workspaceArtifacts_bc3d43ab-1529-41c8-8571-b7155e53e3ff.json
However, when I list the file it is there:
ls -l /ild/data/workspaceArtifacts/workspaceArtifacts_bc3d43ab-1529-41c8-8571-b7155e53e3ff.json
-rw-r--r-- 1 vagrant vagrant 37457375 Jul 6 21:57 /ild/data/workspaceArtifacts/workspaceArtifacts_bc3d43ab-1529-41c8-8571-b7155e53e3ff.json
Does OpenWhisk (running locally) have sandbox limitations for where it is allowed to open files? My action is a Java action and I'm attempting to open a FileReader.
All directories referenced are owned by vagrant:vagrant and have read permissions for all.
Openwhisk runs actions inside a docker container and the files outside the container won't be visible to the action. You can zip the files along with the code and create the action. You can look at this for reference.
https://www.raymondcamden.com/2017/01/10/creating-packaged-actions-in-openwhisk
https://console.bluemix.net/docs/openwhisk/openwhisk_actions.html#openwhisk_actions
Related
I have installed RD 4.8 CE on a Windows 2019 server + MariaDB. The application is up and I can login with the admin account. Service is Windows integrated.
I'm trying now to allow AD users to login and perform activities. I haven't found much documentation on how to configure RD on Windows. So I'm grabbing from here and there. So far I have done the following:
Created a file called jass-multiauth.conf in server/config/ folder as listed below:
multiauth {
com.dtolabs.rundeck.jetty.jaas.JettyCombinedLdapLoginModule sufficient
debug="true"
contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
providerUrl="ldaps://xxxxxxxxxxx:636"
bindDn="CN=xxxxxx,OU=Service Accounts,OU=Admin Users and Groups,OU=xxx,DC=xxx,DC=xxx,DC=xxx"
bindPassword="x$xx<x>xx"
authenticationMethod="simple"
forceBindingLogin="true"
userBaseDn="OU=Admin Users,OU=Admin Users and Groups,OU=xxx,DC=xxx,DC=xxx,DC=xxx"
userRdnAttribute="sAMAccountName"
userIdAttribute="sAMAccountName"
userPasswordAttribute="unicodePwd"
userObjectClass="user"
roleBaseDn="OU=Groups,OU=Admin Users and Groups,OU=xxxx,DC=xxx,DC=xxx,DC=xxx"
roleNameAttribute="cn"
roleMemberAttribute="member"
roleObjectClass="group"
cacheDurationMillis="300000"
timeoutRead="10000"
reportStatistics="true"
supplementalRoles="user";
org.eclipse.jetty.jaas.spi.PropertyFileLoginModule required
debug="true"
file="E:/rundeck/server/config/realm.properties";
};
when I restart rundeck service the AD users are not recognized and no error at all is displayed in the log. I can however login with the admin account. So to troubleshoot this I added:
java %RDECK_CLI_OPTS% %RDECK_SSL_OPTS% -Drundeck.jaaslogin=true -Dloginmodule.conf.name=jaas-multiauth.conf -Djava.security.auth.login.config=E:\rundeck\server\config\jaas-multiauth.conf -Dloginmodule.name=multiauth -jar rundeck.war --skipinstall -d >> %CURDIR%\var\logs\service.log 2>&1
to the start-rundeck.bat file and in fact when I launch it I see an error which is quite weird:
[2022-12-22T18:58:09,409] ERROR config.GrailsApplicationPostProcessor - Error loading spring/resources.groovy file: java.io.IOException: E:\rundeck\server\config\jaas-multiauth.conf (No such file or directory)
java.lang.SecurityException: java.io.IOException: E:\rundeck\server\config\jaas-multiauth.conf (No such file or directory)
the file is there, path is correct and permission is set as on any other file in same directory. I deleted the file and created it again, but same error.
Also, I have a question: I understand that I should not edit the profile file. Hence, when the problem above is fixed, considering that the rundeck service is Windows integrated, where shall I put the line:
java %RDECK_CLI_OPTS% %RDECK_SSL_OPTS% -Drundeck.jaaslogin=true -Dloginmodule.conf.name=jaas-multiauth.conf -Djava.security.auth.login.config=E:\rundeck\server\config\jaas-multiauth.conf -Dloginmodule.name=multiauth -jar rundeck.war --skipinstall -d >> %CURDIR%\var\logs\service.log 2>&1
to refer the jass-multiauth.conf file?
Your multiauth config file is saved as jass-multiauth.conf but the launcher script is looking for jaas-multiauth.conf (jass =! jaas). That is the reason of "No such file or directory" error. Rename the file as jaas-multiauth.conf and relaunch the Rundeck service.
I'd like for my webapp which is deployed as a war ROOT.war to have write access to /var/www/html/static/images so that it can write uploaded and converted images to that folder so nginx can serve it statically. Currently it doesn't work and triggers a java.nio.file.FileSystemException exception together with the Filesystem is read-only message.
But the filesystem is not read-only and is in great condition. The folder has already been chmodded 777.
Extra info:
The tomcat setup is running on an Ubuntu 18.04 Azure VM with managed disk. The folder is residing on an Ext4 formatted drive
Let's start with: chmod 777 is great for testing, but absolutely unfit for the real world and you shouldn't get used to this setting. Rather set the owner/group correctly, before you give world write permissions.
Edit: A similar question just came up on the Tomcat mailing list, and Emmanuel Bourg pointed out that Debian Tomcat is sandboxed by systemd. Read your /usr/share/doc/tomcat9/README.Debian which contains this paragraph:
Tomcat is sandboxed by systemd and only has write access to the
following directories:
/var/lib/tomcat9/conf/Catalina (actually /etc/tomcat9/Catalina)
/var/lib/tomcat9/logs (actually /var/log/tomcat9)
/var/lib/tomcat9/webapps
/var/lib/tomcat9/work (actually /var/cache/tomcat9)
If write access to other directories is required the service settings
have to be overridden. This is done by creating an override.conf file
in /etc/systemd/system/tomcat9.service.d/ containing:
[Service]
ReadWritePaths=/path/to/the/directory/
The service has to be restarted afterward with:
systemctl daemon-reload
systemctl restart tomcat9
Edit 2022: Note that these are the 2019 paths - validate the file locations for later versions. From the comments to this answer (thank you to V H and Ng Sek Long) here are some updates:
In current Ubuntu file is here: sudo vi /etc/systemd/system/multi-user.target.wants/tomcat9.service – V H Feb 26, 2022 at 19:55
Mine (Ubuntu 20) is installed here /lib/systemd/system/tomcat9.service smh everybody use a different path. – Ng Sek Long Mar 28, 2022 at 8:36
End of edit, continuing with the passage that didn't solve OP's problem, but should stay in:
If - all things tested - Tomcat should have write access to that directory, but doesn't have it, the error message points me to an assumption: Could it be that
Tomcat is running as root?
The directory is mounted through NFS?
The default configuration for NFS is that root has no permissions whatsoever on that external filesystem (or was it no write-permission? this is ancient historical memory - look up "NFS root squash" to get the full story)
If this is a condition that matches what you are running, you should stop running Tomcat as root, and rather run it as an unprivileged user. Then you can set the permissions on the directory in question to be writeable by your tomcat-user, and readable by nginx, and you're done.
Running Tomcat as root is a recipe for disaster: You don't want a process that's available from the internet to run as root.
If these conditions don't meet your configuration: Elaborate on the configuration. I'd still stand by this description for others who might find this question/answer later.
So I was trying to make a 1.17.1 minecraft server on my mac. I couldn't open my 1.17.1_server.jar with Java 8 so I download Java 16.0.2.
Unfortunately, everytime I was opening the 1.17.1_server.jar file, I got
"The Java JAR file "1.17._server.jar" could not be launched." .
I first thought that it was because the file was launch by Java 8 instead of 16.
So I went into the terminal and run :<path to java> -jar 1.17.1_server.jar
I then got this : Error: Unable to access jarfile 1.17.1_server.jar
Finally i tried to put the path of the jar file in the command...
So I've run : path to java -jar path to server
and got this :
[main/ERROR]: Failed to load properties from file: server.properties
[15:57:35] [main/WARN]: Failed to load eula.txt
[15:57:35] [main/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info.
So why I have to agreed Eula if i've never launched it ? Does it think that he already been launched ?
As stated in the error message
[15:57:35] [main/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info.
You have to open the file and check yes
Okay find the solution: my eula and server properties file were in my user folder dk why (never moved them so...)
When I call PDField.setValue to set the value for a form field, I get the following stacktrace:
FileSystemFontProvider.saveDiskCache(349) | Could not write to font cache
java.io.FileNotFoundException: /.pdfbox.cache (Permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
at java.io.FileWriter.<init>(FileWriter.java:73)
at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.saveDiskCache(FileSystemFontProvider.java:290)
at org.apache.pdfbox.pdmodel.font.FileSystemFontProvider.<init>(FileSystemFontProvider.java:226)
at org.apache.pdfbox.pdmodel.font.FontMapperImpl$DefaultFontProvider.<clinit>(FontMapperImpl.java:130)
at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getProvider(FontMapperImpl.java:149)
at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFont(FontMapperImpl.java:413)
at org.apache.pdfbox.pdmodel.font.FontMapperImpl.findFontBoxFont(FontMapperImpl.java:376)
at org.apache.pdfbox.pdmodel.font.FontMapperImpl.getFontBoxFont(FontMapperImpl.java:350)
at org.apache.pdfbox.pdmodel.font.PDType1Font.<init>(PDType1Font.java:145)
at org.apache.pdfbox.pdmodel.font.PDType1Font.<clinit>(PDType1Font.java:79)
at org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:62)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:143)
at org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.processSetFont(PDDefaultAppearanceString.java:164)
at org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.processOperator(PDDefaultAppearanceString.java:131)
at org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.processAppearanceStringOperators(PDDefaultAppearanceString.java:107)
at org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.<init>(PDDefaultAppearanceString.java:85)
at org.apache.pdfbox.pdmodel.interactive.form.PDVariableText.getDefaultAppearanceString(PDVariableText.java:93)
at org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.<init>(AppearanceGeneratorHelper.java:94)
at org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
at org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:228)
at org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
I am running PDFBox 2.0.4 which is the newest version. My webserver most likely does not have access to write to .pdfbox.cache in the default location (which seems to be the JVM property user.home). Is there any way to disable the disk caching or change the location of the cache file?
I did notice that I can set a JVM wide system property called pdfbox.fontcache, but my webapp shares a jvm with other applications so this isn't an optimal solution. I also tried using that solution and setting the pdfbox.fontcache to /tmp, but it didn't actually create a file (although it now only throws the stacktrace once per boot).
I looked into the code in the FileSystemFontProvider and the problematic code seems to be in the saveDiskCache method. In that method, it first tries to write the file, but a FileNotFoundException is thrown instead of a SecurityException. FileNotFoundException inherits from IOException.
File file = getDiskCacheFile();
try
{
writer = new BufferedWriter(new FileWriter(file));
}
catch (SecurityException e)
{
return;
}
When you set pdfbox.fontcache with a temporary folder like /tmp where your JVM can write new file inside then a cache file called .pdfbox.cache can be created when you generate PDF with PDFBox (I also use PDFBox 2.0.4).
Maybe your JVM cannot create a new file inside your /tmp directory? To check this try to create a new file with the user running your JVM with an interactive command prompt (shell).
With the command ls -lA /tmp you should see a .pdfbox.cache file in the temporary folder that you configure (example with a tomcat JVM and user):
-rw-r--r-- 1 tomcat tomcat 2050 Dec 29 16:13 .pdfbox.cache
It's not an optimal solution because you can't set multiple pdfbox.fontcache system property on a single JVM.
I have been trying to use a home grown test tool and after doing an update to Centos 6.4, I am no longer able to run the tcl based tool. I am getting the following error and I have no internet access on this server. Kindly advise how do I solve this problem?
Thanks
"XpUtils::iload -d /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1 tclblend" failed:
couldn't load file "/usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1/libtclblend.so": libjava.so: cannot open shared object file: No such file or directory
while executing
"error "\"XpUtils::iload -d $dir tclblend\" failed:\n $errMsg""
(procedure "loadtclblend" line 168)
invoked from within
"loadtclblend /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1"
("package ifneeded java 1.4.1" script)
invoked from within
"package require java"
("eval" body line 1)
invoked from within
"eval package require $pkg"
("foreach" body line 2)
invoked from within
"foreach pkg $pkgList {
set ::${pkg}Version [eval package require $pkg]
}"
(file "/usr/local/testtool/testtool" line 165)
If you read the error message trace, you'll see that it says that this is all caused by:
libjava.so: cannot open shared object file: No such file or directory
The first steps would then be to ensure that you've got a version of Java actually installed, to check that it includes the file libjava.so, and that the file has been indexed by the system shared library catalog.
It might also be worth checking that all its dependencies are also present and that you've got the architecture for the Tcl library and the Java library matched (e.g., both 32-bit) as those can cause odd failures when they go wrong.