[–] 3 points 2 hours ago (2 children)

Die rechten Trottel werden nicht die Fresse halten.

Warum sollten sie auch? Einfach laut Lügen in die Welt schreien ist einfach, diese widerlegen und sich mit tatsächlichen Fakten auseinandersetzen zu müssen kostet hingegen Ressoucen.

  • source
  • parent
  • context
  • [–] 26 points 19 hours ago* (2 children)

    Lustig wie die Bundes-CDU in Berlin unverhohlen mit den "Konsequenzen" droht, sollte jemand mit den Linken regieren (inklusive absolut unwürdiger Idee, wie die im Grundgesetz vorgesehene Vergesellschaftung zu verbieten, oder dem Bundesland den Geldhahn abdrehen zu wollen), aber auf der anderen Seite in Sachsen-Anhalt brav still ist, während ihr eigener Landesverband freiwillig, unnötig und ohne jeden Zwang für AfD Politiker stimmt, die deren Stimmen nicht mal benötigen. Deutlicher kann man nicht auch dem Letzten verkünden, welche Faschisten ihre Wunschkoalitionspartner sind.

  • source
  • [–] 4 points 19 hours ago*

    Is the rise of AfD in Germany a concern, what has the other parties done to slow it down?

    Nothing. All they do is help accelerating the AfD's rise by parroting any lie the AfD tells. Because the AfD isn't a problem for them but the chance to finally get rid of that pesky democracy that sets limits on their corruption.

    That's the common denominator for all "conservatives". If they have to chose between democracy and power they will chose the latter every single time.

    Their only other option would be actual sensible policies. But that's not actually a real option if you are deeply corrupt and just looking for a way to implement policies for your ultra-rich donors. So diversion via culture war and right-wing propaganda it is instead. Not a long-term solution when you will be eaten up by far-right parties this way. But who cares for long-term when it's about money and nice board positions now...

    (And so they are happily abolishing transparency laws already while helping to implement more surveilance and more police powers. Because they are totally not planning to cooperate with fascists soon *wink wink*.)

  • source
  • [–] 1 point 20 hours ago

    If you use the shortlived profile and your key is compromised, you benefit from the short lifetime.

    Maybe I'm just too stupid to understand how those certificates work.

    But in what scenario is my key compromised but not my server? Because someone getting control of my server can just get an new long-term certificate. That was my actual point in the comment above. I understand the argument of added security if they only issue short-term certificates. But where is the benefit of my short-term certificate when someone compromising my server can just get a new long-term one in seconds?

    Also we are talking about self hosting. I understand the issue of revoking certificates when you have a massive userbase where some might miss the revocation for quite some time. Not so much with the dozen max family and friends.

  • source
  • parent
  • context
  •  

    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 ›