I installed tomcat-7.0.59, after g did the deployment of alfresco on tomcat (share.war, alfresco.war, solr4.war), I also copy the two folders common and libreoffice on tomcat, after restarting Tomcat, the platforms share and alfresco running except an error that appears concerant ImageMagick, the displayed one is as follows: err: .convert.bin: UnableToOpenConfigureFile `delegates.xml '# warning / configure.c / GetConfigureOptions / 616.
Ensure the XML resources are deployed to the system/environment. ImageMagick will search the following directories.
From Resources docs...
$MAGICK_CONFIGURE_PATH
$MAGICK_HOME/etc/ImageMagick-7
$MAGICK_HOME/share/ImageMagick-7
$PREFIX/share/ImageMagick-7
$XDG_CACHE_HOME/ImageMagick
$HOME/.config/ImageMagick/
<client path>/etc/ImageMagick
<current directory>
I would highly suggest setting the environment variable MAGICK_CONFIGURE_PATH to ensure deployments are consistent.
This would be a great time to ensure policy.xml exists, and had be adjusted to protected against attacks.
Related
When I start my development rails server I get this following message first. To my knowledge WSL2 is a virtual environment.
I would have expected it to now reference a Java directory that resides on my Windows host. Is this likely something I carried over in the project from when I was using WSL1? How would I safely correct this?
/home/daveomcd/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/railties-6.0.3.2/lib/rails/app_loader.rb:53:
warning: Insecure world writable dir /mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath
in PATH, mode 040777
I experienced the same problem when trying to fix the slowness of WSL2. The recommended solution was to move the files from the mounted NTFS drive to the root ext4 filesystem (using \\$wsl\<distroname>), so I did that.
I set up /etc/wsl.conf as below:
# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=0033"
mountFsTab = false
[interop]
enabled = true
appendWindowsPath = true
And ran rails bundle to update dependencies.
Also make sure that your file permissions and owner settings are updated. Hope it helps.
Sorry, I'd love to make this more of a comment to see if I'm on the right track before committing to an answer. However, since there's too much info here for that, I'll make an attempt at getting you an answer here.
While it is a virtual environment, by default WSL provides several "Windows Interop" features that allow it to:
automatically mount Windows drives in /mnt/{c,d,...}
append the Windows path to the Linux path
run Windows executables inside Linux
share Windows environment variables with Linux (although this is not something that happens by default)
I can't be sure (long, long time since I've used Rails), but it looks like something in the app_loader.rb is checking permissions on Java directories in the path. It may be using some logic like "check each path entry and look for a java or java.exe there. If found, check permissions." Or something like that. That means that (2) and (3) above may be confusing it.
You can see this in action with which java.exe, which will likely return a Windows path. Or run notepad.exe, which will launch the Windows Notepad executable from within Linux/WSL (magic! 😉).
These are both very useful features, so I hate to disable them completely, but it's the easiest way to figure out if that's the problem. Create a /etc/wsl.conf with the following contents:
[interop]
enabled=false
appendWindowsPath=false
Exit your WSL instance and then:
(from PowerShell, CMD, or Windows Start) Run wsl --list --verbose to see the name of your distribution (most likely Ubuntu)
Likewise, run wsl --terminate <distro> to terminate that distribution.
Restart your WSL instance
Try running /mnt/c/Windows/system32/notepad.exe (assuming a normal C:\Windows installation) (should fail, since interop is disabled)
Try which notepad.exe (should fail, since the Windows path should no longer be appended to the Linux path)
Try to start your Rails dev server again - Might work (might not, I could easily be wrong about the root-cause here)
If it does work, then you can try to correct the situation with several less invasive methods than disabling those features entirely:
If you plan on only using WSL for your development, then you could remove the Windows JDK.
Or at least remove the Windows JDK from the PATH in Windows.
Or, if you want to keep it installed and in the Windows path, you could have a shell startup file (e.g. .bashrc) that removes it from the path only in WSL. I'll point you to this question which contains multiple techniques for doing so.
Or you could keep the appendWindowsPath=false in your /etc/wsl.conf but then add back in the paths you want manually in your startup config.
I'm trying to clean start karaf on Windows using clean option.
It does delete data directory with bundles cache but it copy new bundles into data directory from system directory not local maven repository. But system directory has stale jars in comparison to local maven repository which cause karaf to start with stale bundles.
Is this a 'feature' of clean option? Am I missing something? How could I start Karaf with latest code from maven repo not dealing with file system?
You can't as the system directory is per default the one to use.
The clean does mean to clear up bundles in a awkward state and is only rarely used. Sometimes this happens if you start and stop the karaf container very close to each other then bundle might be in an incomplete state and since those bundle state is kept only a clean will help. Another way of cleaning is to delete the data folder.
So what you look like to be intending is to update certain bundles that are installed from the systems folder. For that you need to install the never version cause Karaf nows which versions are in the systems folder, those bundles are defined in the framework feature which is the basic feature to be used by Karaf itself.
If you have your own bundles in the system folder there is no way of updating those as those are regarded to be bootfeatures. In case you want to update those you'll need to make sure those features aren't boot features anymore and after that just do install the never versions of your bundles and uninstall the older ones. This can be done with the command shell.
One side note, it's usually best to ask those questions on the users mailinglist of Karaf, you get more people to answer your questions there.
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.
I am attempting to get a Grails project working but need help setting it up. I have an Ubuntu server running on a VM that has Redis installed. The project won't run unless I create a config file that can use Redis on the Ubuntu server. This is the settings I pulled down from GitHub located in the grails-app/conf/Config.groovy file.
http://snag.gy/eYhUY.jpg
I was told I need to create a separate config file that will override these parameters so my project will talk to the ubuntu server on my machine. This is a noob question but where do I create a config file? I can't seem to find a .grails folder. I know I'm suppose to reference my config file, once i've created one, in the grails-app/conf/Config.groovy file
http://snag.gy/SpGGt.jpg
Look at the grails.config.locations specified in your Config.grooy and you can create any of those locations for creating the external Config file.
I prefer using the classpath route. Here is what I would do.
Create a folder (say appConfig) and place it in the tomcat/conf folder.
Add the application config file (proghorn-config.groovy in your case) to the folder, with the required configurations in the file.
Add the folder to the Tomcat classpath by updating either the tomcat/conf/catalina.properties or by creating the tomcat/bin/setenv.sh
The location of the .grails folder depends upon the user account running the container (Tomcat, Jetty, etc.) which hosts your Grails application.
For example on Debian 6 running Tomcat 6.x the location is:
/usr/share/tomcat6/.grails/
You can also use static paths as well:
file:/usr/local/tomcat/conf/myspecific-config.groovy
When packaging the application using warbler, the symbolic links are lost and the actual contents the symlink points to are packaged as part of the WAR.
In my case, I have a symlink from public/images/upload to /var/myproject/upload. After I deploy the war in tomcat, in the exploded folder public/images/upload has all the contents of /var/myproject/upload copied to it instead of linking to the folder.
UPDATE: My questions is "will warbler retain the symbolic links inside the project when deployed as a war?"
Environment Info:
jruby 1.6.2 (ruby-1.8.7-p330) | warbler 1.3.1 | Cent OS 5.5 | Java SE "1.6.0_26"
I had the same problem. I solved it by creating global (##) variables for each path that I used in the environment files. For example my production.rb file contains ##rejectedPage="/pathto/page/in/tomcat", while in my development.rb file I set ##rejectedPage="/the/normal/path". This way I can easily switch from my development environment to my production environment.
Warbler does not support symbolic links currently, so it tries to copy its contents. Your best bet is to configure Warbler to ignore the link and post process the .war file with some other program that would store the link.
Feel free to file a feature request for this, or better, submit a patch/pull request.