Offline setup
-
@JaredBusch said in Offline setup:
@scottalanmiller said in Offline setup:
One would assume that he means he wants an internal system that will not have internet access after setup.
This project is not a good idea for that.
You're right. I want to use on my internal network. I tried npm packages install with "cache-min" and "save" params. But still not good working.
Thank you.
-
@ofaruksahin which requests aren't working / are slow? ACP pages?
-
@ofaruksahin said in Offline setup:
@JaredBusch said in Offline setup:
@scottalanmiller said in Offline setup:
One would assume that he means he wants an internal system that will not have internet access after setup.
This project is not a good idea for that.
You're right. I want to use on my internal network. I tried npm packages install with "cache-min" and "save" params. But still not good working.
Thank you.
Oh I see, sorry.
Check DNS to make sure that DNS is working when offline. Or at least pointing to a DNS server that will report back quickly.
-
@PitaJ said in Offline setup:
@ofaruksahin which requests aren't working / are slow? ACP pages?
as I said. I'm running docker containers on localhost. And when I connect to the internet, it's all good. Otherwise, when disconneted to internet the main page is loading slowly and login a request lasts about 50ms. I think there trying to download the * .js dependencies from the internet?
-
@scottalanmiller said in Offline setup:
@ofaruksahin said in Offline setup:
@JaredBusch said in Offline setup:
@scottalanmiller said in Offline setup:
One would assume that he means he wants an internal system that will not have internet access after setup.
This project is not a good idea for that.
You're right. I want to use on my internal network. I tried npm packages install with "cache-min" and "save" params. But still not good working.
Thank you.
Oh I see, sorry.
Check DNS to make sure that DNS is working when offline. Or at least pointing to a DNS server that will report back quickly.
No, it's not about DNS. I'm working on localhost with containers.
-
@ofaruksahin said in Offline setup:
@scottalanmiller said in Offline setup:
@ofaruksahin said in Offline setup:
@JaredBusch said in Offline setup:
@scottalanmiller said in Offline setup:
One would assume that he means he wants an internal system that will not have internet access after setup.
This project is not a good idea for that.
You're right. I want to use on my internal network. I tried npm packages install with "cache-min" and "save" params. But still not good working.
Thank you.
Oh I see, sorry.
Check DNS to make sure that DNS is working when offline. Or at least pointing to a DNS server that will report back quickly.
No, it's not about DNS. I'm working on localhost with containers.
Why would either of those things apply here? Knowing that you are on a localhost and using containers is why I suggested DNS specifically, because there might be calls going out and waiting for DNS to time out. That you are on a localhost is precisely why I asked, and containerization is definitely unrelated.
-
@ofaruksahin said in Offline setup:
as I said. I'm running docker containers on localhost. And when I connect to the internet, it's all good.
In this exact scenario, DNS is often the culprit. Hence why I asked. In a case like this, when you "go slow" when going offline, DNS is the culprit more than half of the time. Especially if things work, just really slowly. because the delay can come from DNS timeouts.
-
@scottalanmiller said in Offline setup:
@ofaruksahin said in Offline setup:
@scottalanmiller said in Offline setup:
@ofaruksahin said in Offline setup:
@JaredBusch said in Offline setup:
@scottalanmiller said in Offline setup:
One would assume that he means he wants an internal system that will not have internet access after setup.
This project is not a good idea for that.
You're right. I want to use on my internal network. I tried npm packages install with "cache-min" and "save" params. But still not good working.
Thank you.
Oh I see, sorry.
Check DNS to make sure that DNS is working when offline. Or at least pointing to a DNS server that will report back quickly.
No, it's not about DNS. I'm working on localhost with containers.
Why would either of those things apply here? Knowing that you are on a localhost and using containers is why I suggested DNS specifically, because there might be calls going out and waiting for DNS to time out. That you are on a localhost is precisely why I asked, and containerization is definitely unrelated.
Sorry. I want to say, It's not about the DNS in my internal network. Cause I connect directly with IP.
@scottalanmiller said in Offline setup:
@ofaruksahin said in Offline setup:
as I said. I'm running docker containers on localhost. And when I connect to the internet, it's all good.
In this exact scenario, DNS is often the culprit. Hence why I asked. In a case like this, when you "go slow" when going offline, DNS is the culprit more than half of the time. Especially if things work, just really slowly. because the delay can come from DNS timeouts.
Yeah, you're right. Because my request is not respond 404. It's going slowly and sometimes 504 time out. So what do you suggests me?
Thank you. -
@ofaruksahin said in Offline setup:
Sorry. I want to say, It's not about the DNS in my internal network. Cause I connect directly with IP.
That would mean that it is not the DNS settings of your workstation, but that's not what I was questioning. That's different. It is the DNS settings of the server running NodeBB that you should check. Make sure that they point to a working DNS server on your local network so that they can prompt responses when you are offline. Even if the responses are errors, they will be fast rather than timeouts. The timeouts could lead to things like 404 errors.
-
@ofaruksahin said in Offline setup:
Yeah, you're right. Because my request is not respond 404. It's going slowly and sometimes 504 time out. So what do you suggests me?
Thank you.Start with the DNS. If it is slow and only breaks sometimes, DNS is the most likely thing and might be just slow enough that sometimes it works barely and sometimes it fails. 504 is server side error unable to respond.
If JS files are trying to be pulled from remote, then DNS has to be used. If DNS is pointing externally, we'd expect the delay. If it works sometimes, that means that there is some sort of fallback that is likely just timing out sometimes.
