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

Nette Idee, aber wie immer eher symbolisch.

Anreize die Mobilitätsgewohnheiten zu ändern schafft man praktisch nie durch kurzfristige Aktionen, sondern nur durch langfrisitge, sinnvolle Planung.

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

Das Problem sind aber kurze Entwicklungszeiträume. Solche Abfangdrohnen kannst du im Kriegsfall entwickeln und in Masse produzieren, um spezifisch genau gegen die Drohnen zu wirken, die der Gegenr gerade benutzt.

Die selben Dinger bauen und als Luftverteidigung einlagern ist hingegen völlig nutzlos. Denn in 5 Jahren kommt ein Gegner einfach mit etwas modifiziertem, das z.b. etwas höher fliegt, und dann sind die alle nutzlos.

Bei allem Hype um Drohnen ergibt es durchaus Sinn, dass sich exakt kein Militär der Welt da gerade an der Entwicklung verausgabt, und stattdessen komplexere Systeme entwickelt und gebaut werden, die eben wesentlch mehr leisten und auch noch über Jahrzehnte modifiziert werden können. Für preiswerte Abwehrdrohnen gegen ebenso preiswerte Sättigungsangriffe brauchst du halt das grundsätzliche Know-How und die Zielerfassung/Autonomie, aber es hat absolut keinen Sinn, sowas im Vorraus in relevanten Stückzahlen zu bauen.

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

Ein kurzer Feuerstoß genügt aber doch...

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

People tend to read them the first time when installing stuff, yet rarely think about the scenario of a well used package taken over by a malicious actor making changes.

[-] Ooops@feddit.org 10 points 14 hours ago

I actually think it's a good idea. If this is too dangerous then by definition the same is true for all cyclists. So there is no need to address those specifically instead of improving safety for all kinds of bikes.

[-] Ooops@feddit.org 13 points 14 hours ago

Keitrucks are the designed result of regulations.

So exactly as this "cargo-e-bike"... especially designed to work within the existing regulation for cargo-e-bikes.

[-] Ooops@feddit.org 11 points 14 hours ago

Still doesn't make these vehicles a problem per se. And it definitely isn't a problem that should be addressed specifically. Instead tune the laws and regulations for e-(cargo-)bikes accordingly to benefit all ebikes and other future ideas to exploit loopholes.

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

Bei "Wir brauchen kein Social-Media-Verbot, sondern nur vernünftige Förderung der Medienkompetenz" erwarte ich die leider inzwischen die selbe Verarsche wie bei "Wir brauchen keine neuen Schulden, sondern nur eine vernünftige Beschränkungen unsinniger Ausgaben" oder "Wir brauchen keine Verbote für Klimaschädlinge, sondern nur vernünftige CO₂-Bepreisung".

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

People not even checking the PKGBUILDs will also not check sandboxed applications to see if it was actually done properly...

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

Ich krieg nicht einmal 'ne Autogrammkarte? 🥲

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

Naja, aber irgendwie müssen die Leute ja beschäftigt werden. Ölpreise, die gar nicht so verrückt hoch sind, könnten den Menschen den Eindruck vermitteln, dass man sich nur auf ihre Kosten bereichert, und das muss definitv vermieden werden. Also lieber noch ein paar Titelzeilen mit "aufgebrauchten Reserven"...

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

Oh, nein... in 3 Monaten wurden fast 0,5% der Reserve (so winzig ist nämlich der Teil, der freigegeben wurde) aufgebraucht? Was machen wir bloß, wenn die 50 Jahren dann ganz weg sind? Ich fang schonmal an panisch im Kreis zu rennen.

30
submitted 1 week ago by Ooops@feddit.org to c/unixporn@lemmy.world

26
submitted 2 months ago* (last edited 2 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