I am trying to install Elasticsearch on my computer. I am following this tutorial for the purpose. The steps mentioned in this tutorial works fine in one computer. But when I am trying to install ElasticSearch in another computer, I found that the config file is entirely commented unlike the config file of the previous computer in which I could install the Elastic search. I have tried downloading elasticsearch multiple times, but every time I found that the config file is commented. I have also tried manually pasting the config file in the second system, but that attempt fails as well. Is there any issue with my system that prevents the config file from getting downloaded in the right manner? Also what should be done in my case. Any help in this regard will be of great value.
Related
I've just installed Elasticsearch and Kibana's latest versions (same versions) on Windows. When I launch Elasticsearch it starts just as normal and I can check through the browser that it's on the required port. But when I launch Kibana it gives me the error "\config was unexpected". I checked the configurations and made sure that Kibana knew where to connect to ES and tried re-installs but nothing changed. When I tried it on an Ubuntu virtual machine the two worked normally. I don't know where the issue is. Hope someone can help.
Thanks.
I solved the problem. I'll just leave this for future reference:
Some people solved this by downgrading their Java: I did the same thing going from Java 15 to Java 8 but it didn't solve the issue for me. But still something to try.
What solved this for me was simply to change the path of the Kibana directory. Apparently Windows had some trouble reading its own default name for the parent directory. Moving the kibana folder to a simpler directory (like C:) and even renaming the folder to simply "kibana" instead of including the version etc. made it run as normal.
Yesterday I downloaded redis from github in zip format. In the first place everything seems working fine: the redis-server started up fine, the installing of the service was also going well. But as soon as I started the redis-cli.exe nothing happens, I just get a blank dos window. I also tried connecting using the c# client, but I couldn't connect at all.
I didn't change anything int the .conf files, so the redis.windows.conf is the same file as the .conf file from github.
I hope someone can help me further.
I'm running an instance of Galaxy NGS in an Ubuntu server, with a basic configuration, postgresql database, and apache.
When I log in as Admin in the Galaxy interface, and try to add a new tool through the tool shed, the tool is installed and I can use it without problems
However, if Galaxy needs to be restarted, the tool does not appear anymore
I followed the instructions here to configure a folder to keep the installed tools, like it explains there, adding a line in config.ini with the desired folder
tool_dependency_dir = dependency_dir
But that doesn't do the trick and the tools are not stored in the folder anyway
Does somebody have a clue on what could I be missing?
The problem was solved after switching from apache to nginx, and changing the line I posted to
tool_dependency_dir = /home/galaxy/tool_deps
I found a nice resource that helped me with the configuration in case somebody faces the same issue.
https://wiki.galaxyproject.org/Events/BioITWorld2014/W14#Setting_up_a_Local_Galaxy_Tutorial_.28Part_I.29
I am trying to install and understand ODE.
I set up Tomcat7 no problem
I set up ODE WAR distribution
I copied the examples folder as per instructions.
Then I ran it, and it failed.
Then I RTM some more and saw
The sendsoap executable can be found in the distribution bin directory. The urls should be updated according to the address defined in the WSDL file for the process service.
The executable script using the command line given fires an exception.
could not find or load main class org.apache.ode.tools.sendsoap.cline.HttpSoapSender
latest version.
If there is some update to URLs required there are no directions to do that anywhere in the install instructions. Given that new users do installs this has to be one of the most brain dead careless instruction sets I have read in years regardless of the fix. But can someone enlighten me?
Just to be clear, the startup screen on port 8080 comes up just fine.
The command line tools seem to have some class path issues. I'd suggest to use SoapUI instead, it provides a better UX as well.
Update: Quickstart to verify the installation:
For a simple test, just copy the helloworld2 example from the dist package to tomcat/webapps/ode/processes. The process should then appear in the web console. Copy the Axis2 WSDL URL of the helloworld process http://localhost:8080/ode/deployment/services/, which is most likely
http://localhost:8080/ode/processes/helloWorld?wsdl. Open SoapUI, start a new SOAP project, paste the WSDL URL into the "Initial WSDL" form and create the project. SoapUI will create sample request "Request 1" for the hello operation. Double click, play with the content and invoke the method using the green "play" button.
Due to a build problem the JAR files in the lib directory of the 1.3.6 WAR/JBI distributions don't work (Bug Report). Use the 1.3.5 distribution instead until this is fixed.
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.