[-] Ooops@feddit.org 1 points 2 hours ago* (last edited 2 hours ago)

I can’t be the only one who had Arch on a system before getting a smartphone

But that issue is solved for many years now. Although it makes a certain kind of sense: a lot of the Arch hate and memes causes we to question if that person has actually used Arch in years. So a lot of those ideas may be indeed ancient experiences surviving purely in memes and stories.

[-] Ooops@feddit.org 1 points 2 hours ago

Also ich kenn mindestens eine VHS, die noch nicht weiß, dass das Internet überhaupt existiert. Die müsste ich wohl persönlich oder per Fax anstubsen, vermutlich mit mäßigem Erfolg.

[-] Ooops@feddit.org 2 points 2 hours ago* (last edited 2 hours ago)

None of those graph ever are. Because Linux users are more prone to tinkering, keeping stuff private and blocking a lot of bullshit scripting, there is big dark area of Linux systems listing themselves as something else (usually Windows because of those asshole websites not playing well with Linux by design without an actual valid reason other than "we don't like Linux").

(PS: For the same reason a lot of sites believe I'm using Chrome. I don't but I know they like to fuck with me when they see that Firefox user agent.)

[-] Ooops@feddit.org 1 points 2 hours ago

Thing is you can often debunk any of these graphs for the same reason. Just a minority of Linux systems actually show up as Linux as the users are usually more inclined to block a lot of stuff for privacy reasons, then often also changing the user agent most tests fall back to.

[-] Ooops@feddit.org 2 points 2 hours ago* (last edited 2 hours ago)

Manjaro which is less stable than Arch in my experience.

That's because their whole concept is bullshit. Delaying updates for two weeks would make sense, when they actually used that time frame for testing and to fix bugs before release. In reality they just delay everything without sense, so you actually get the same bugs, just 2 weeks later because the fixes are also delayed.

And then they add access to the AUR (by default even, where Arch warns people about the risks) which assumes an up-to-date system, not one lagging 2 weeks behind. Which is a big shiny invitation to dependency hell.

[-] Ooops@feddit.org 2 points 2 hours ago

Sadly those benchmarks only tell me that they did test only two file systems on LUKS...

[-] Ooops@feddit.org 6 points 2 hours ago

I was too lazy for scripting the update to check the news and just get a mail when the update has issues... or should get one.

In reality I check if the email process still works once every blue moon because I didn't get one from a failed update in years.

[-] Ooops@feddit.org 3 points 2 hours ago

I think you can get problems once you are a full release cycle behind the last supported one.

Funnily enough it's mostly an issue with mirrors and signing keys, so basically the same fix Arch users need if they are behind for many months: update the packages for keys and mirrors first, everyting else afterwards.

[-] Ooops@feddit.org 5 points 3 hours ago

Well... because of longer testing periods and a lot of stuff never even considered until stale the stable distros indeed have less bugs. The ones that still slip through however will basically not get fixes for years.

On the other hand I have seen a lot of bugs on Arch... but I usually don't care and just assume (rightfully so in 99% of the cases) that they get fixed within hours.

[-] Ooops@feddit.org 2 points 3 hours ago* (last edited 3 hours ago)

I wonder how many Arch haters have actually used Arch and ever ran into a breaking issue.

A lot... they install it, screw up because they didn't bother to read the instructions, then did the usual... a new install.

Those who pass the first basic barrier to just chroot into the system and fix a simple mistake or roll back a package for the few hours it takes to get fixed instead of starting fresh usually stay for a long time...

In fact with the people I know there is a correlation between either "oh, I don't bother to fix anything and just do a fresh install (that idea is especially persistent in Windows users)" or "there's a big distro upgrade that had issues" and distro hopping. Once you settled on a rolling release and learned the basics in terms of fixing stuff the urge to hop yet another time vanishes for many.

[-] Ooops@feddit.org 4 points 3 hours ago

As everyone knew it would happen once the loud, crying propagandists screamed about deporting criminal Afghans while actually nullifying already existing visa for Afghans that helped the German army for years...

35
submitted 1 month ago by Ooops@feddit.org to c/unixporn@lemmy.world

25
submitted 3 months ago* (last edited 3 months ago) by Ooops@feddit.org to c/selfhosted@lemmy.world

As this will -thanks to me being quite clueless- be a very open question I will start with the setup:

One nginx server on an old Raspi getting ports 80 and 443 routed from the access point and serving several pages as well as some reverse proxies for other sevices.

So a (very simplified) nginx server-block that looks like this:

# serve stuff internally (without a hostname) via http
server {
	listen 80 default_server;
	http2 on;
	server_name _; 
	location / {
		proxy_pass http://localhost:5555/;
                \# that's where all actual stuff is located
	}
}
# reroute http traffic with hostname to https
server {
	listen 80;
	http2 on;
	server_name server_a.bla;
	location / {
		return 301 https://$host$request_uri;
	}
}
server {
	listen 443 ssl default_server;
	http2 on;
	server_name server_a.bla;
   	ssl_certificate     A_fullchain.pem;
    	ssl_certificate_key A_privkey.pem;
	location / {
		proxy_pass http://localhost:5555/;
	}
}
#actual content here...
server {
	listen 5555;
	http2 on;
    	root /srv/http;
	location / {
        	index index.html;
   	} 
    	location = /page1 {
		return 301 page1.html;
	}
    	location = /page2 {
		return 301 page2.html;
	}
        #reverse proxy for an example webdav server 
	location /dav/ {
		proxy_pass        http://localhost:6666/;
	}
}

Which works well.

And intuitively it looked like putting Anubis into the chain should be simple. Just point the proxy_pass (and the required headers) in the "port 443"-section to Anubis and set it to pass along to localhost:5555 again.

Which really worked just as expected... but only for server_a.bla, server_a.bla/page1 or server_a.bla/page2.

server_a.bla/dav just hangs and hangs, to then time out, seemingly trying to open server_a.bla:6666/dav.

So long story short...

How does proxy_pass actually work that the first setup works, yet the second breaks? How does a call for localhost:6666 (already behind earlier proxy passes in both cases) somehow end up querying the hostname instead?

And what do I need to configure -or what information/header do I need to pass on- to keep the internal communication intact?

view more: next ›

Ooops

0 post score
0 comment score
joined 2 years ago