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

For example:

We have two storages (e.g., SSD): /dev/sda and /dev/sdb.

Install Windows on /dev/sdb (so it creates its own ESP);

Install Linux on /dev/sda (so it creates its own ESP), with a normal/manual partitioning:
- /boot/ (for Kernels I have 4 GiB+);
- /boot/efi/ (commonly, from 128 to 512 MiB is enough);
- Here I normally also have a swap partition, and separate: /home/, /var/;
- Select Grub to be installed on the /dev/sda;

Boot the Grub in /dev/sda;

Update Grub within Linux, so it finds the Windows EFI on another drive via its os-prober.

Here, I believe efibootmgr should show the existing EFI, or you could check it manually in /boot/efi after.

Windows should operate on its own ESP it created on its own storage, and don’t overwrite the Grub.

At voila!

Then Windows will fuck up your EFI entries. Which is not a big deal if you know what you are doing but a completely different story for the audience you are explicitly addressing here when you even explain how to check those entries in the first place.

Also you did not actually mention that fastboot needs to be disabled in Windows, thus a clueless person will not understand the random hardware errors on Linux caused by not properly initialized devices and will blame Linux.

(And let's not even talk about some of the really insane stuff like pre-installed Microsoft SecureBoot keys that brick you whole system when removed because idiotic OEMs signed their own hardware's EFI drivers with the keys already pre-installed just because they can...)

So no, it's not "quite odd to see so many people having the issue when Windows". That's what Windows is causing, often intentionally so. Is most of this easily fixable? Sure... But it's a very effective deterrent for many people, so they never reach the point where they understand and be able to fix that stuff.

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

Then Windows will fuck up the EFI entry itself. Easy to fix of course but a pain in the ass when you are just starting with Linux and have barely any idea other than reinstalling for the 10th time in a few weeks.

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

Alternativer Titel:

"Weniger als 1% interessieren sich für die Demokratie. Der Rest ist längst zu dumm, zu uninteressiert oder schlichtweg durch propaganda-induzierten Schaden bereits zu hirntot"

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

That's bullshit. Hot rivers can cool down reactors quite well (you just don't want even hotter rivers for different environmental reasons) and so can closed cooling loops.

The actual reason against nuclear is that it's economical insanity, always has been and always will. Everything else is just smoke and mirrors. Stories about imaginary reasons against nuclear out there are actually a helpful tool for the pro-nuclear side. They have something to easily debunk while also keeping the discussion away from the only thing that actually matters: the ridiculous costs.

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

Leaving an EU country for another EU country to avoid EU-wide legislation is a very good idea anywway...

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

Based on the C*U only losing a few percent and massive amounts changing to the "the same insanity, but even more corrupt, more radical and with screaming more absurd lies"-alternative... No, they definitely can't. Quite the contrary actually. Not only can they not see the difference, they actively believe destroying the country even harder will somehow magically fix it.

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

Who are "we"? The majority is brain-dead and does elect the same corrupt morons again and again because obsolete industry clinging to their dying business model, the fossil fuel industry (same, same...) and billionaires making money off the people's stupidity tell them to do it.

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

It is also really important to just be honest with where the German economy stands right now

Exactly where most of it stands for decades. It's based on constant lobbying of "We want back to the 1980 at the very latest. Give public money so we can refuse any innovation and adapt legislation to stifle any competition for us. Thx, here are some board meberships in exchange."

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

Welt-Pommes-Tag ist im August.

Der 13. Juli ist French-Fry-Day in den USA. Tun wir schon wieder so als wären die die Welt?

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

Und man kann sogar einfach den großen Einbau-"Air Fryer" in der Küche benutzen... 😂

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

That's an improvement over always being the dedicated tech support anyway, no matter how often you explain to them that you have not bothered to take a look at Windows and all its specific issues for a decade or more...

[-] Ooops@feddit.org 8 points 15 hours ago

What does "getting caught" mean? They do it quite openly with everyone knowing and zero real consequences.

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