Acess to /nosh folder on apache server

[shihjay2]

From @rumsant on March 31, 2017 2:50

This has happened to me in the past, but I've just done a reinstall because I was working on other problems with the install:

After NOSH working fine, at some point I vagrant halt, and then vagrant up at some point later on. When I try to access either the local-ip/nosh or the domain/nosh (both of which worked find previously) I get taken to a page that says "Forbidden - You don't have permission to access /nosh on this server.

I think that each time this has happened the only thing that has changed has been a change in the local ip address assigned to the ubuntu/xenial64 virtual machine.

I'm guessing that there is a file I have to modify somewhere, or something like that, but I just don't know what or where it is.

Copied from original issue: shihjay2/nosh2#42

[shihjay2]

You can try a static IP address respective to your router - make sure you set the IP to fall outside of what is assigned through DHCP (it's a range of addresses - you can shorten the range, last 3 numbers) so that you can assign a number. Some routers allow you to assign a static IP based on a MAC address too so that's one method. Another method:

In Vagrantfile add the ip option after "public_network" and choose an ip that is outside the range for DHCP by router config.vm.network "public_network", ip: "192.168.0.17"

Save, and vagrant reload

[shihjay2]

Will move this issue to nosh-in-the-box project as topic pertains more to that project than to nosh2

[rumsant]

One more thing relating to this issue of static local IP: the best practice would seem to be defining a static ip address in Vagrantfile because you enter your domain for SSL certification at the initial setup right after the first "vagrant-ssh". This will automatically lead to an attempt to obtain the certificate at the end of the initial install process. To accomplish this successfully you will need to have port 443 forwarded prior to the installation. But you don't know which IP address to forward port 443 to unless you set it in Vagrantfile, so I don't see how you could successfully install the SSL certificate unless you set a static IP in Vagrantfile.

The other option would be to leave the domain blank and finish the install. Then determine the MAC address of the virtual machine by looking at your router, and set a static IP in the router for that machine. The restart the machine with the newly assigned static IP and do install-ssl.

This is all very easy to mess up, I've found.

[rumsant]

I have gotten this 403 error again after doing a new install last night. This new install included using a static ip as mentioned above. Specifically the error reads: "Forbidden You don't have permission to access /nosh/ on this server. Apache/2.4.18 (Ubuntu) Server at 192.168.1.150 Port 80"

I don't know enough about apache to really understand this, but from what I can glean from searching, might this be fixed by doing something to an httpd or .conf file that sets permissions?

It's not that this directory doesn't exist, but that something has changed with respect to permission to access it.

[shihjay2]

Can you output your nosh2.conf file in /etc/apache2/sites-enabled? Can you output your terminal for the command cd /noshdocuments/nosh2 and ls -a

[rumsant]

Hmmm, I guess there isn't a nosh2.conf file in /etc/apache2/sites-enabled. I think I was looking at a nosh2.conf file in a different directory and assumed that was the correct place for it.

Here is the output for the command cd /noshdocuments/nosh2 and ls -a:

[shihjay2]

You might have the old version (v3.0 moved the nosh2.conf file over to sites-enabled) directory. Just out of curiosity, can you to ls -a of the /etc/apache2/sites-enabled to see what's there (should be empty for the old version) The nosh2. conf is in the /etc/apache2/conf-enabled for the old version so post that if you can. Can you do ls -l for the /noshdocuments/nosh2 directory?

[rumsant]

I know that I used the most up-to-date nosh-in-a-box file when I installed last night (v2.9, I believe). Here is the output for those directories:

[rumsant]

Just spit-balling here, but could it have anything to do with using the "install-ssl" script? Does this change the placement of files and need to be updated?

[shihjay2]

Yes, that was what I suspected. just out of curiosity, there is the 000-default.conf and 000-default-le-ssl.conf which should not be present and may be causing conflict to the nosh2.conf You can use the command sudo a2dissite 000-default and sudo a2dissite 000-default-le-ssl to remove them; restart apache2 sudo systemctl restart apache2

v3.0 is the latest and moved the nosh2.conf file to the sites-enabled directory so that letsencrypt can work on that file correctly to address the error messages you menetioned in a different bug report.

[rumsant]

Running those commands didn't change anything as far as I can ascertain, if that's what you were wondering.

I didn't know about v3.0 - I don't think it was up yet when I installed.

I think I am going to vagrant destroy and start from scratch with 3.0 -- shall I try that now?

[rumsant]

And should I install v3.0 by entering the domain at initial installation? Or wait and run install-ssl?

[shihjay2]

I would try to enter the domain at the initial install - that was the reason for the error message as it was looking for a conf file in sites-enabled directory but there wasn't any. I changed that in V3.0.

[rumsant]

Nice. v3.0 installed with letsencrypt cert smoothly it appears.

[rumsant]

After uploading the JSON file and going through the initial practice setup, I click the Install button and I get a similar error about too many redirects:

"The 192.168.1.150 page isn’t working

192.168.1.150 redirected you too many times. Try clearing your cookies. ERR_TOO_MANY_REDIRECTS"

The only thing I am doing that is different is replacing the provision as explained in #4 because I cannot get access outside the LAN unless I do so. I don't see how this would be responsible for this error, but I'm not the expert.

edit: Again, I am able to clear cookies and get to the /nosh page after this happens, but then when I try to login, I get the same error.

edit: to create the JSON file, I used https:///nosh/googleoauth This is correct, yes? Curious b/c the example when creating the credential uses the "oauth2callback" appendage instead of the "googleoauth" in your directions.

[shihjay2]

Did you have a domain name registered to your WAN IP with port 80 and 443 port forwarding to your VM? I'm confused with your error message since it has a numerical IP address so it's not going to resolve correctly if you are using your domain name for Google to redirect back to googleouth (ouath2callback is just a generic reference for Google) - googleoauth is the route in NOSH where it registers with Google to get a refresh token for future calls (to send out emails).

[rumsant]

Sorry, I could see how that would be confusing. To answer your questions, yes, the domain is registered and pointing to my public IP with ports properly forwarding, and the certificate is issued via letsencrypt.

I just happened to be using the numerical IP because I was on the host computer. If I try to use the domain, I can access /nosh if I clear my cookies, but after I try to log in or click a link I get the same thing. And if I try to access outside of the LAN, I get the same thing.

[shihjay2]

Same thing meaning the "too many redirects" error or error 403 when you try to access outside the LAN? Have you checked our DNS server configuration (in your router or host computer?) Something seems to be weird about that and not related to the VM given that you can access using the domain name from the host computer. Is you host computer a laptop?

[rumsant]

Same thing "too many redirects". I'm not sure about what to check regarding DNS. Yes, right now I am using a laptop for this.

[shihjay2]

When you check to access the VM from outside of your domain, are you using the same host laptop to get to it or from another device? Reason being, if your host IP changes, your VM relies on your host IP for networking and that changes everything from the domain name association since the domain name is tied to your router, not the VM

[rumsant]

I am using a different device, so there is no host IP change.

By the way, should I make sure that my host IP is also set to static just in case there is a change? There hasn't been any changes because the DHCP lease is long enough, but I'm wondering if that is a good idea.

[shihjay2]

Host IP shouldn't matter in that case as long as it's connected to the same router. You can check your DNS settings in your router (usually with DHCP)

[rumsant]

In my router I have a section titled "Router IP" and it has a line titled "Local DNS" which is 0.0.0.0 Under "Network Address Server Settings (DHCP)" there are 3 lines titled "Static DNS 1" (and "...2" and "...3"), and they are all at 0.0.0.0 as well.

[rumsant]

Does it matter if choose whether HTTPS access is required or optional when I set up letsencrypt?

Also, I don't know if I mentioned it, but I am able to get to https:// just fine. It brings me to the Apache ubuntu default page. It's just when I try to get to the /nosh when the redirect happens.

[shihjay2]

Letsencrypt allows you to access your NOSH through HTTPS by setting up an SSL certificate. You can access both but NOSH defaults to HTTPS by security default.

Check if you have DNS servers assigned in your host and/or VM by this command nslookup www.google.com The DNS server is indicated on the Server: line It should be the same between your host and VM as it is typically assigned by the router. It's strange that your router is giving a DNS server of 0.0.0.0;

[rumsant]

I am checking this on two different installations that both have this same problem. The first is using desktop Windows10 host, and host server line is "Netgear". Virtual machine server line is "10.0.2.3".

The second installation is using laptop Ubuntu 16.04 host and host server line is "127.0.1.1". Virtual machine server line is "10.0.2.3".

edit: there is a line that says "Server:" and a line directly beneath that says "Address:" -- do you want the address line?

[rumsant]

One more thing I've found. Apparently the redirect error is what I get if I try to access /nosh without https.

If I use "https://mylocalip/nosh" (from within the LAN), or "https://mydomain/nosh" (from outside the LAN), I get an error page instead of a redirect. The error page reads:

For "https://mylocalip/nosh" (from within LAN): "ErrorException in BaseProvider.php line 178: file_get_contents(): Peer certificate CN=noshrsc.top' did not match expected CN=192.168.1.152' (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php) (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php)"

For "https://mydomain/nosh" (from outside LAN): "ErrorException in BaseProvider.php line 178: file_get_contents(https://noshrsc.top/nosh/assets/css/font-awesome.min.css): failed to open stream: Connection timed out (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php) (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php)"

Perhaps that will give a clew.

[shihjay2]

SSL certificates only apply to domain names so you'll get an error when you use https://mylocalip/nosh. (hence the "not match" response). From within the LAN, you'll need to use https://mydomain/nosh. Some routers will allow "loopback routing" so you can do this without running into problems.

Yes the redirect error will occur if you use http instead of https because the default apache configuration forces you to use https and it will go into a redirect loop since the OAuth2 call requires that it matches exactly; Google will "think" it's going to the right place but it's not really and it's stuck in a loop. So remember to use https.

Now the second error is strange because you're making a call to https://mydomain/nosh but then there's another domain called noshrsc.top (?) unless mydomain is noshrsc.top. If that's so, that is even more strange since you're able to connect externally to noshrsc.top/nosh in the first place and then it's saying it can't in the same subsequent call....

....so after thinking about all this - what is the domain name associated to? It needs to be associated to your WAN IP address (not a 192.168.x.x address) - but whatever IP address was assigned by your ISP going to the router. You should be able to see it in your router IP admin application. If it's not static, you'll need an app with your host or router that allows dynamic DNS assigning and that way, the domain is always pointing to your router - not your VM.

[rumsant]

noshrsc.top is the associated domain (I just got a cheap domain to test with). It is properly associated with my WAN IP address, and I can confirm that because I can access the apache server from outside my LAN.

[shihjay2]

OK, then it sounds like there's a problem for you to make a call using https://noshrsc.top from within your LAN - that's where the timeout is coming from - I was able to verify by accessing https://noshrsc.top/nosh/assets/css/font-awesome.min.css from my web browser but not https://noshrsc.top/nosh - the error comes NOSH building the css and javascript modules but it is making a call to the same domain name to do it but since you can't make a call within your LAN, it's timing out.

A temporary measure until you figure out about configuring your router to doing a loopback is to edit /etc/hosts in your VM: 192.168.1.152 noshrsc.top and save it.

192.168.1.152 is the IP of your VM

[rumsant]

Okay, I will look into seeing how to enable NAT loooback.

Though, I don't see how this explains the error I get when trying to access /nosh from a device outside of my LAN.

[shihjay2]

In my last explanation, I was able to verify that I can access the resource https://noshrsc.top/nosh/assets/css/font-awesome.min.css externally (try it yourself - you'll see text code for the css file). That means Apache is configured correctly and it's pulling up the /nosh alias correctly.

The reason the error pops up for just https://noshrsc.top/nosh is because the default URL will take you directly to https://noshrsc.top/nosh/login which is pulling up a page that requires compilation of css and javascript code that happens behind the scenes - it needs to generate the compiled file through opening some files like https://noshrsc.top/nosh/assets/css/font-awesome.min.css internally.

However, because you can't call that inside your LAN due to the NAT loopback error, the internal call is stalling and then it times out. Then that's the error that you get on /nosh

Sorry it's a little convoluted but you're one step away from getting it working. The temporary solution above will force the VM to skip the domain name translation step and internally point to the VM's IP address which should prevent the stalling and timing-out.

[rumsant]

Quick question before I start tinkering with my router: If, from my host machine and my virtual machine, I am able to ping both my own public/WAN IP address and my domain, doesn't this mean that NAT loopback is working just fine? Wouldn't I get a timeout or some packet loss if NAT loopback wasn't working? Or is this thinking incorrect?

[shihjay2]

You need to ping noshrsc.top (not IP address) from within your VM. If it works, then NAT loopback is enabled. If it doesn't then it's not.

[rumsant]

Yes, I mentioned that I was able to ping both my WAN IP AND my domain (ping noshrsc.top) and they both showed all packets transmitted as received with 0% packet loss.

[shihjay2]

Yes then in means NAT loopback is working

[rumsant]

As an experiment I did the following:

1. I destroyed my current installation.
2. I reinstalled nosh-in-a-box without entering a domain for letsencrypt (however my domain is pointed to the WAN IP) 3. I used mylocalip/nosh to upload the correct JSON file for google stuff.
3. I entered the initial practice setup information and admin login.
4. I got the same redirection errors.

THEN:

1. I destroyed the machine.
2. I reinstalled nosh-in-a-box without entering a domain for letsencrypt (however my domain is pointed to the WAN IP) 3. I DID NOT upload a JSON file.
3. I went to mylocalip/nosh and entered the initial practice setup information and admin login.
4. I was forwarded without redirect error to the login and was able to login and create users, etc.

With this information--does it not seem as though the cause of the redirect error has something to do with the JSON file? The only variable in this is that file upload, and after all, there is a "URI REDIRECT" field when creating the credential. In the past I have been entering the following in that field: "https://rscnosh.top/nosh/googleoauth". That is correct, as far as I can tell from the instructions.

[shihjay2]

I think maybe Google has changed their API requirements recently. My instructions in the wiki didn't mention it but after doing some research, I'm wondering that during the registration for the refresh token from Google that it's rejected because you may not have activated the Gmail API (it used to be an all encompassing Google API and I guess anyone who set it up previously that was grandfathered in) but now it seems you need to enable it on the Developer Console. So go back to Google and look for this screen in the Developer Console when you click on Dashboard and Enable API:

Once you're enabled, go back to setting up the domain name and JSON upload and see if it stops the loop. NOSH apparently is going through a loop because Google is sending nothing back for an error and NOSH keeps hammering it trying to get it to give it a refresh token but you didn't enable the API.

[rumsant]

Okay, I will do that. However, I am beginning to think that my previous suspicion about the JSON file may be wrong. I did a total reinstall using a new domain (rscconf.us) and entered my domain during install and successfully had a certificate issued. When I then go to https://mylocalip/nosh from host machine I get this familiar error: "ErrorException in BaseProvider.php line 178: file_get_contents(): Peer certificate CN=rscconf.us' did not match expected CN=192.168.1.151' (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php) (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php)"

BUT if I go to http://mylocalip/nosh from the host, I successfully get to the "Upload JSON File..." screen.

Alternatively, if I try to go to https://mydomain/nosh from OUTSIDE the LAN, I get this familiar error: "ErrorException in BaseProvider.php line 178: file_get_contents(https://noshrsc.top/nosh/assets/css/font-awesome.min.css): failed to open stream: Connection timed out (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php) (View: /noshdocuments/nosh2/resources/views/layouts/app.blade.php)"

And all of this is before I upload the JSON file, so it seems like that wasn't the issue. But I'll try what you mentioned above anyway.

[rumsant]

Also, what do I do once I get to that screen you mentioned?

edit: okay, figured it out. Turned on Gmail API.

And just so you know, I don't think that the product logo you specify in your directions is available: https://noshchartingsystem.com/SAAS-logo-120.jpg

[rumsant]

If I go to my credential, there is a tab title "Domain verification" that says "You need to verify domain ownership to allow webhook notifications to be sent to your external domains. Google verifies that the user owns each of the listed domains via Search Console."

That seems like maybe it's important?

[rumsant]

Almost forgot to mention this:

I remember you mentioning a file called "nosh2.conf" awhile ago and you mentioned it should be in /etc/apache2/conf-enabled. If this is true, I would like you to know that it is not present in that location.

[shihjay2]

URL for logo is now https://cloud.noshchartingsystem.com/SAAS-Logo-120.jpg.

Fixed wiki.

I believe the Domain verification seems important too but technically NOSH is not using webhook notifications; but I guess it wouldn't hurt.

nosh2.conf in v3.0 is now in /etc/apache2/sites-enabled

[rumsant]

Just looking for anything that might be the problems at this point, but (as you know) I don't have the background knowledge to determine if something is actually a possible problem.

That being said, I've seen the following line of thinking come up in several forum threads related to the redirect problems I'm getting, so I thought I'd drop it here and see if you think it's a possible contender:

You are requesting via SSL over port 443 when you hit the ELB, but then you are requesting to the backend as insecure port 80. This is fine, but then your config has no idea that this is supposed to be over 443 because you are reverse proxying it. To the web server, this is just a port 80 insecure request, so it will try to redirect to SSL port 443, which is why it's looping.

[shihjay2]

I'm not sure that's the reason since by default configuration I have set any port 80 calls to go to 443 automatically and Laravel (which NOSH's framework is based on) will automatically make any internal calls to HTTPS since the original call is 443 before Laravel sees it. As you can see in the error messages, the URL starts with https which means Laravel respects port 443 when it sees it.

[shihjay2]

So even with activating Gmail API you're still having the redirect issues?

[rumsant]

Yes. That didn't seem to make any difference.

[rumsant]

What does this part of the error seem to mean to you?: "Peer certificate CN=rscconf.us' did not match expected CN=192.168.1.151'"

[shihjay2]

It means your calling the URL with https://192.168.1.151 instead of https://rscconf.us - it'll throw that error because your SSL certificate is associated with https://rscconf.us

[shihjay2]

Have you tried editing the /etc/hosts file in the VM as instructed earlier?