• 1 Post
  • 16 Comments
Joined 1Y ago
cake
Cake day: Jul 09, 2023

help-circle
rss
Announcement by the creator: https://forum.syncthing.net/t/discontinuing-syncthing-android/23002 > Unfortunately I don’t have good news on the state of the android app: I am retiring it. The last release on Github and F-Droid will happen with the December 2024 Syncthing version. > Reason is a combination of Google making Play publishing something between hard and impossible and no active maintenance. The app saw no significant development for a long time and without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance an app requires even without doing much, if any, changes. > Thanks a lot to everyone who ever contributed to this app!
fedilink

If you are port forwarding. I recommend not exposing it on the default port of 25565 and instead expose it as a random port. Then, assuming you have a domain name, create an SRV record that points to your IP and port. This will cut down on the drive by scanners who scan by ports, but won’t totally eliminate it. If you do use the SRV record, your friends won’t even notice there’s a different port.


I actually have a double sided male A cable. I was shocked when I got it but I have this laptop cooler that has two A ports on it, presumably to allow a pass through but I’m always nervous that I’ll plug it in and fry something.


There’s two main ways of doing geo-based load balancing:

  1. IP Any-casting - In this case, an IP address is “homed” in multiple spots and through the magic of IP routing, it arrives at the nearest location. This is exactly how 1.1.1.1 and 8.8.8.8 work. It works fine for stateless packets like DNS, however it has some risks for stateful traffic like HTTP.
  2. DNS based load balancing. A server receives a request for “google.com”, looks at the IP of the DNS server and/or the EDNS Client IP in the DNS query packet and returns an IP that’s near. The problem is that when you’re doing Wireguard, it goes phone -> pi-hole (source IP is some internal IP) -> the next hop (e.g. 1.1.1.1 or 8.8.8.8), which sees the packet is coming from your home/pi-hole’s public IP. Thus it gets confused and thinks you’re in a different location than you really are. Neither of these hops really knows your true location of your phone/mobile device.

Of course, this doesn’t matter for companies that only have one data center.


Sorry, what do you mean route it directly? Maybe I didn’t clarify well enough.

My DNS is routed over the VPN but Internet traffic is routed directly. The problem is the load balancing is done based on where the DNS server is so say Google even though the traffic egresses directly to the internet bypassing the VPN it still goes to a Google DC near my home. Not all websites do this so its not always an issue.


Yes, but if you hit a company doing DNS based load balancing, DNS is going to return an IP that’s near to your DNS server which may not be near your device. That’s going to add to the latency.


I have Wireguard and I forward DNS and my internal traffic from my phone over the VPN to my pi-hole at home. All other traffic goes directly over the Internet, not the VPN. So that means only DNS encounters higher latency.

However, because a lot of companies do DNS based geo load balancing that means even if I’m on the east coast all my traffic gets sent to the West Coast because my DNS server is located there. That right there has the biggest impact on latency.

It’s tolerable on the same continent, but once I start getting into other continents then it gets a bit slow.


Accidentally typo your password and get blocked. And if you’re tunneling over tor, you’ve blocked 127.0.0.1 which means now nobody can login.


Paperless does support defining a folder structure that you can use to organize documents within that paperless media volume however you should treat it as read only.

OP could use this as a way to keep their desired folder structure as much as possible, but it would have to be separate from the consumption folder.


I don’t fully understand what you’re saying, but let’s break this down.

Since you say you get an NGINX page, what does your NGINX config look like? What exactly does the NGINX “login page” say? Is it an error or is it a directory listing or something else?


Then try something like:

Create Quanity unit of ml and a liter unit

In your product use: Unit stock: bottle or liter Unit purchase: bottle Consume: ml Price unit: ml

Set a product specific QU conversion of bottle to ml

Weirdly, the quick consume unit is based on the stock unit, not the consume unit. That seems like a bug.


The problem with Grocy is that going too fine grained means you’re unlikely to keep it up to date or it be accurate. I would not try to track your usage in ml. Just track it at the bottle level.

However you can still track the price per ml because grocy lets you independently set units. Just define a mapping between bottle and ml.


If you’re running Docker for servers not development, then you can make Hyper-V work. I used to do that before I got a separate Linux server and it worked out.

Just setup a network adapter that gets bridged to your Ethernet adapter, then create a VM that uses that bridged adapter. The Linux VM will appear like its another computer on your LAN and you can use Docker with host Network.


What is your threat model or goal? It could hide the device you use to connect to the instance, however a lot of actions you do on Lemmy, including all upvotes, are public to other instances.


It’s not generally a hardware problem. It’s a resourcing problem. Companies like GitHub will have complex software and architecture. IPv6 requires them to get a pool of IP addresses, come up with an IP address management strategy, make sure all hosts have IPv6 addresses meaning that now provisioning systems and tooling to management DNS has to plumb IPv6 addresses through too.

Then the software stack has to support it. Maybe their fraud detection or auditing systems have to now support IPv6 which means changes to API schemas.

None of this is a good reason why they shouldn’t do it, but I’ve had to make similar decisions at my job as a software engineer on what looks to be simple but actually requires changes across systems.


There was an uncaught exception to boot gunicorn workers

That’s odd that it didn’t cause the Docker container to immediately exit.

What now? So now that it looks like everything is working. What is the best practice for the nginx.conf? Leave it all in /etc/nginx/nginx.conf (with user as root), reestablish the out box nginx.conf and /etc/nginx/conf.d/default.conf

My suggestion would be to create /etc/nginx/conf.d/mycooldjangoapp.conf. Compared to conf.d/default.conf, this is more intuitive if you start hosting multiple apps. Keep it out of the nginx.conf because apt-get or other package managers will usually patch that with new version changes and again it gets confusing if you have multiple apps.


First the basics. Connection refused means that nothing is running on “http://192.168.0.2:8020/

  1. Is 192.168.0.2 the IP address of the Django container? If it’s the host’s IP, does docker ps show that the port is bound to the host? e.g. 0.0.0.0/8082->8082

Confirmed upstream block container is running and on the right exposed port

What steps did you do to confirm that this is running?