I am running nexus3 on a Linux Mint 19.3 Tricia, named "horst" (=CNAME).
The machine has several DNS aliases like (and for example) "jenkins", "nexus" etc.
So, until I updated Mint today, the (http-)URL nexus:8081 worked (like jenkins:8081, horst:8081 and every other alias, on that port of course) meaning it started nexus.
There was no update of nexus.
Now, after the update, any URL pointing to port 8081 opens nexus with http,
EXCEPT "nexus:8081" which tries to redirect to https and results in an respective error message, as https is not configured in nexus.
When I curl nexus:8081, I don't get a redirect in return, but the proper start page with proper content.
I checked with different browsers, clean cache and security settings, same symptom.
I am irritated why this happens with exactly this one URL, why it comes up now - and where to solve this problem.
Related
I am trying to use a Raspberry Pi 4 Model B as a small web server. It works fine for unsecured http, both within my home LAN and over the net. I have obtained a domain name and SSL certificate and key file. I am testing the server by accessing it within my local network using a browser and the Pi hostname. Unsecured http works fine, but making an https request results in a delay and then a "host refused to connect" message on the browser.
I have found conflicting instructions on the Web as to which Apache configuration file needs to be edited to include paths to the SSLCertificateFile and SSLCertificateKeyFile.
Within /etc/apache2 there are sites-available and sites-enabled subdirectories and more than one *.conf file, but apparently I have not edited the right one.
So, first, which is the correct configuration file to edit with the certificate paths, and second, does Apache produce a log file somewhere that would reveal any error messages produced by errors in the certificate?
I found a more complete set of instructions that showed how to add a port 443 virtual host to the default-000.conf file. It is working now.
I'm having trouble trying to side-load an add-in in MS Word, getting the error
'ADD-IN ERROR: A problem occured while trying to reach this add-in.' The add-in needs to be hosted on a local docker environment to be integrated in the rest of a web aplication.
Setup
The add-in files are hosted on a local docker machine, accessible through both an ip-address and a https://dev.local address. The add-in is reachable through Internet Explorer and Edge Chromium without any certificate errors. It doesn't matter whether I try to reach the IP address of the locally mapped dev.local, the add-in refuses to load and just crashes. I'm on Word version 2002 build 12527.20194. Another word-addin that we host externally works fine.
What i've tried
I've been messing around with the settings in Internet Explorer (moving the sites to local zone, trusted zone, enabling and disabling the protection there).
I've upgraded Edge to edge Chromium. I've tried to use the Preview of
Edge Developer Tools, but that crashes when the error occurs.
I've tried using Fiddler and activate the runtime logging, but can't get more information on what's going wrong.
I've used the Yoman validation on the manifest.xml and everything checks out.
I've also enabled loopback through CheckNetIsolation LoopbackExempt -a -n="microsoft.win32webviewhost_cw5n1h2txyewy"
I'm pretty much at a loss now: what can I do to get more information on what's crashing the add-in?
OK so I managed to finally get this to work, leaving this here for anyone who might run into the same issues.
Because the local sideloading did work, I figured we needed to emulate the localhost situation with the docker. So I instructed the virtual machine to forward localhost:3000 to the Docker Toolbox port 443. I also copied over the SSL certificates generated by Yoman in <userhome>/.office-addin-dev-certs to the Nginx docker and instructed Nginx to use those SSL certificates for port 443.
I'm not entirely sure if adapting all of the other settings (such as enabling the loopback interface and using the about:flags page to always allow https on localhost are also neccesary, maybe just emulating the webserver on localhost is enough. Hope this helps someone!
I have a Windows development machine with an Ubuntu VM set up via vagrant. The VM has Nginx running on port 80 and the Vagrant configuration maps port 8080 on the host Windows machine to port 80 on the VM. For various reasons the project that I'm working uses 127.0.0.1 instead of localhost so, in my browser on the Windows machine, I hit a URL such as:
http://127.0.0.1:8080/foo/bar/baz
The application on the VM is built with Zend Framework 1.12.
If I click a link that has an href="/foo/bar/baz" then all is fine and I go to:
http://127.0.0.1:8080/foo/bar/baz
However, if in one of my controllers I use a redirect to "/foo/bar/baz" then the browser loads:
http://127.0.0.1/foo/bar/baz - i.e without the port in it.
If I then manually edit the URL in the browser's address bar to add the port and hit enter then the page comes up correctly.
I've tried various ways of doing the redirect programatically in ZF, and even tried typing a hard coded URL into the code, but whatever I do it always strips out the port component when the redirect takes place.
Any ideas/suggestions as to how to keep the port in the redirect would be much appreciated.
I have a problem. I am trying to run a simple JSP page from Eclipse:
http://postimg.org/image/z268cl1s3/
But when I run this page i get a 404 error:
http://postimg.org/image/h0rosix4z/
When I put in:
localhost
127.0.0.1
in the browser it works fine:
http://postimg.org/image/8js6hlsg3/
I can see eclipse is running it from localhost:8080, but when i type that in at the browser it gives me this error:
http://postimg.org/image/7lbtfbf43/
Does anyone know how I can activate localhost on my mac. I looked up several tutorials, but i didnt find the answer. MySQL is also running fine on the computer, so I guess there is something that dont let me access [http://localhost:8080?]
Hope someone can help me?
Best Regards
Mads
There are two issues you are having:
There is a difference between http://localhost/ (and its equivalent http://127.0.0.1) and http://localhost:8080 - the first uses port 80, the second 8080. The Tomcat server listens only to the latter, that is shown by the servers error messages, and not generic 404 messages. In other words, do not forget to add the 8080 port numbers to the end of the localhost url
The Tomcat error messages show that the resources are not available, so I would look at what Java web applications are installed - e.g. the root web application is missing (the localhost:8080 url) for sure, and I am not sure whether your MySQL connector is.
Search google for how adding an entry to the hosts file on your mac.
You'll basically link localhost to 127.0.0.1 there
I have a simple angular application that works just fine when deployed on my local JBoss instance, but when I deploy the same war file in our sandboxed environment (also JBoss) the application doesn't load. Just shows up as a blank page. When viewed on Chrome or FF it works fine as well.
Not a lot to go on, but any pointers in the right direction would be very helpful.
Edit: Just another piece of info, it doesn't work locally on IE either when the address contains the computer name and not localhost. So http://localhost:8080/angularapp works but http://[machinename]:8080/angularapp does not.
In the post you don't make completely clear in what environments you've the problem (it's clear it doesn't work using IE, but does it work in all cases with Chrome and FF?).
But the problem you're experiencing when trying to access using the machine name (http://machinename:8080/...), may be caused because you've not defined properly the IP bindings in the JBoss startup: by default JBoss binds only to localhost (127.0.0.1), if you want JBoss to be accessed from any other network interface, you've to define it. That can be done using the -b parameter of the startup script (run.sh for Jboss 3.x/4.x/5.x/6.x or standalone.sh if it's JBoss 7). For example:
./run.sh -b xxx.xxx.xxx.xxx (where xxx.xxx.xxx.xxx is your server IP) will make the JBoss accessible only from that IP (and its corresponding machine name, provided is correctly defined in the DNS or /etc/hosts ...), but not from localhost.
./run.sh -b 0.0.0.0 will make the JBoss accessible from all the networks interfaces of your server.