Ooops

joined 2 years ago
[–] Ooops@feddit.org 5 points 1 day ago

While I understand the idea in general Tux, the penguin, is basically freely available, do whatever you want with it, and you are explicitly encouraged to integrate the design into Linux related projects... as long as you mention the author should someone ask (source)

I wouldn't even buy a pre-fabricated sticker but do one myself. But that wasn't the question...

PS: the Impressum here or here, down at the bottom labeled "Impressum"?

[–] Ooops@feddit.org 2 points 4 days ago* (last edited 4 days ago) (2 children)

While you are right in general, you are just creating a file with a : line without any identifying context. So have fun searching the world for where I might have actually used it. Sounds like a really bad use of ressources to create list of passwords.

PS: Yes, as an Arch user I am still pissed that this tool is not available in the repos beside installing the complete Apache server...

[–] Ooops@feddit.org 2 points 4 days ago* (last edited 4 days ago) (7 children)

The options to password protect it are in the (usually /etc/radicale/)config file under [auth].

For proper security you could use

type = htpasswd

htpasswd_filename = /etc/radicale/users

htpasswd_encryption = bcrypt

then create a users file with apache tools (htpasswd -c -B users User1) or one of the million online htpasswd file creators.

[–] Ooops@feddit.org 1 points 1 week ago* (last edited 1 week ago)

You could click the link already provided above. Just the Table of Contents at the top gives you a good overview about issues with Brave without reading anything else...

[–] Ooops@feddit.org 3 points 2 weeks ago (1 children)

upgrade to next kernel version != patch the kernel with backported security fixes

[–] Ooops@feddit.org 10 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

Debian daring to suggest that using your real name to identify yourself on the system is a reasonable choice for most people. So get the torches and pitchforks...

Also don't tell those people about the fact that such fields for additional information (like real name, address etc) exist in most user-handling parts of their software since forever.

You get asked for your real name when creating a new user for longer than Linux even exists. It's just that noone actually cares. But now that's suddenly an horrific anti privacy policy because the narrative demand that it is.

[–] Ooops@feddit.org 2 points 3 weeks ago

Occasionally I need to run an “occ” command after an install to fix some indexes

That then fails and breaks it (in about 1 out of 3 cases). Which requires rolling back everything, running the commands again pre-update, then updating and praying to not have to do another re-install (~ 1 out of 5).

[–] Ooops@feddit.org 6 points 3 weeks ago* (last edited 3 weeks ago) (5 children)

I actually moved away from classical self-hosted cloud storage solutions after trying the usual suspects like opencloud, nextcloud etc.

And for me the time and effort (also the ressource-hogging if you don't use quite overpowered servers) just weren't worth it. Not when the used interfaces most of the time are open standards anyway and simpler solutions do the job:

Radicale for contacts and dates via a webdav subset. Webdav concidently being widely supported for integrating online storage into any filesystem (or as the backend for several other things like for example syncing my bookmarks over several devices and browsers). SFTP or the million tools being just a frontend for it.

One shiny platform like for example Nextcloud to do it all might be nice for a lot of users when they have someone dedicated to maintain it. But for selfhosting (as in: mainly for myself) the constant attention needed to fix stuff was quite tedious.

When I think of "Google Drive" or "Dropbox" alternatives nowadays it's just a drive hooked up to some low-spec device and accessed via one (or several) already existing open standards.

(Bonus point: that lost phone is simply cut off by deleting its keys - unlike so many dedicated platform where you have to manage -if you even can- multiple dedicated users and their rights just to easily separate your personal access from your devices that are by design not all equally secure.)

[–] Ooops@feddit.org 18 points 1 month ago* (last edited 1 month ago)

Have in mind that compressed filesystem would be slower.

Often the opposite is true, depending on case. Compressed files load faster, so if you have the cpu power to spare (which you usually have in games while loading) and loading speed is the bottle-neck then compression speeds things up, often considerably.

And even in the age of ssds processing data and moving it through ram is much faster than the disk, so even for writing some amount of transparent compression is possible without affecting speeds.

[–] Ooops@feddit.org 2 points 1 month ago

Might be just my experience but what actually keeps people from switching is a proper support time line. Long-term and rolling releases can keep people using them for years after which they actually know what they want, what they can get used to and they don't wanjt. Most distros however screw up something at the inevitable upgrade long before that, which then leads to "well, guess I could reinstall and try something else anyway".

 

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 ›