The nginx parser is the worst part about nginx...
> [emerg] "map_hash_bucket_size" directive is duplicate in /etc/nginx/nginx.conf:62
In real world this means that before map_hash_bucket_size there was a map...
The nginx parser is the worst part about nginx...
> [emerg] "map_hash_bucket_size" directive is duplicate in /etc/nginx/nginx.conf:62
In real world this means that before map_hash_bucket_size there was a map...
GRRRR!!!
I just spent the last hour of my life chasing round in circles just because #nginx wouldnt serve up my css file for some reason. I forced the mime types in the nginx config and everything...
Weirdly, Chrome was fine but firefox wasnt when loading this?
Anyway, turns out the reason why is because nginx has this *14 year old* bug that means it falls apart whenever there's a dash in a file name. Wtf?! How has no one looked at that yet
Web sockets don’t like me. I have set up #mastodon on one machine (Podman) and #nginx on another machine (also running as a container). Everything works fine in a browser but all mobile Mastodon clients (apps, iOS) refuse to play media. I don’t see anything suspicious in the logs, it just doesn’t work and I have no idea what’s the cause.
Ive built a setup for hosting websites which consists of:
* Host running #microos with #podman
* #Treafik and #sshpiper at the edge
* #Nginx, php-fpm, #mariadb + phpmyadmin + nginx or #postgres + dbadmin, openssh for each site
It actually works quite well, openssh keybased access is to transfer files into the containers, traefik does the reverse proxying.
I'm just wondering if its a sustainable and maintainable setup. Sometimes just going with a "standard" solution seems so much easier.
#GoAccess pour les journaux #Nginx #Proxy Manager passe en version 1.1.35 https://github.com/xavier-hernandez/goaccess-for-nginxproxymanager
#NoAi #nginx #network #networking #apache #webdev
Yet another AI bot to block:
ChatBot for WordPress with AI – WPBot
https://wordpress.org/plugins/chatbot/
Sample request with UA
34.222.202.101 - - [09/Apr/2025:02:35:32 +0200] "GET / HTTP/2.0" 403 107 "-" "Mozilla/5.0 (compatible; wpbot/1.3; +https://forms.gle/ajBaxygz9jSR8p8G9)"
Just released: #swad v0.2
SWAD is the "Simple Web Authentication Daemon", meant to add #cookie #authentication with a simple #login form and configurable credential checker modules to a reverse #proxy supporting to delegate authentication to a backend service, like e.g. #nginx' "auth_request". It's a very small piece of software written in pure #C with as little external dependencies as possible. It requires some #POSIX (or "almost POSIX", like #Linux, #FreeBSD, ...) environment, OpenSSL (or LibreSSL) for TLS and zlib for response compression.
Currently, the only credential checker module available offers #PAM authentication, more modules will come in later releases.
swad 0.2 brings a few bugfixes and improvements, especially helping with security by rate-limiting the creation of new sessions as well as failed login attempts. Read details and grab it here:
I recently started to replace #nginx with @caddy and it's as satisfying as it is scary to replace a complex config that spans five included files and a total of about 400 lines with a single Caddyfile of around 80 lines.
And on top of that #Caddy also made certbot redundant as it takes care of fetching and renewing the tls certs from #LetsEncrypt and keeps a #ZeroSSL backup for all of my domains.
I think I'm in love..
Released: #swad v0.1
Looking for a simple way to add #authentication to your #nginx reverse proxy? Then swad *could* be for you!
swad is the "Simple Web Authentication Daemon", written in pure #C (+ #POSIX) with almost no external dependencies. #TLS support requires #OpenSSL (or #LibreSSL). It's designed to work with nginx' "auth_request" module and offers authentication using a #cookie and a login form.
Well, this is a first release and you can tell by the version number it isn't "complete" yet. Most notably, only one single credentials checker is implemented: #PAM. But as pam already allows pretty flexible configuration, I already consider this pretty useful
If you want to know more, read here:
https://github.com/Zirias/swad
After trolling through many tags and lists trying to see what folks enjoy for #smallweb site generators and frameworks seems like good old dusty #jekyll and #nginx is probably as good as bet as any. One constraint thats not implicitly met by Jekyll is no javascript, but that’s reliant on themes.
For hosting.. probably just find something reasonable through #lowendtalk since I’ve been unable to convince #linode my account from > 10 years ago is actually mine.
#Documentation ... better start early I guess. What would you think of this sample #configuration file?
Hint: the tokens surrounded by %% will be replaced by my build system before installing this thing.
For context, this is a web #authentication service offering cookie+forms login meant for e.g. #nginx' "auth_request".
DId lots of smaller improvements to #swad ... but first, I had to hunt down a crash . Finally found it was caused by my #poser lib (to be fixed later): A connection there can resolve the hostname of a remote end and does so in a thread job to avoid blocking. If the connection dies meanwhile, the job is canceled. Seems my canceling mechanism relying on a signal to the thread is, well, not reliable (the signal can arrive delayed). Ok, for now just disabled name resolution to sidestep that.
Now, integration with #nginx is much better. I intrdoduced (optional) custom headers to transport the authentication realm and the redirect URI, plus state management in the session, so these can be passed to the "auth" endpoint. This requires to make sure nginx always passes the session #cookie, Unfortunately, I still need a "hacky" redirect configuration for login in nginx. If auth_request could just pass the response body, this would be unnecessary ....
The nginx configuration shows #swad running on "files" and another nginx running on "wwwint" serving #poudriere output there. This nginx instance helpfully adds cache hints, which I have to override, so a redirect works as expected when for example the swad session times out.
I've set up my new #inkscape website AI bot trap. It works by giving everyone a chance to not fall into it.
An anchor link that says "I am a bot" and links to /P3W-451/{datetime}/ it's got a fixed position at top -100px so should never be seen
The robots.txt says "Disallow: /P3W-451/" so if you were reading the robots, you'd know.
Then #nginx logs the requests to a log of their ip-addresses and browser strings and sends them a 301 redirect to google.com
1/2
First "production test" successful ... after band-aid "deployment" (IOW, scp binaries to the prod jail).
#swad integrates with #nginx exactly as I planned it. And #PAM authentication using a child process running as root also just works (while the main process dropped privileges).
So, I guess I can say goodbye to #AI #bots hammering my poor DSL connection just to download poudriere build logs.
Still a lot to do for #swad: Make it nicer. So many ideas. Best start would probably be to implement more credentials checking modules besides PAM.
Si ça continue, nous bloquerons Azure, AWS et consort
I finally poked at my nginx logs, because generally nothing happens on my servers
202.155.137.157 - - [30/Mar/2025:00:53:00 +0100] "GET /mirrors-JapanMapTranslate-github/patch/bin/kanaconv/HiraganaConverterImpl.class?id=c1c09efe21a09ecbd6f95641c8a0086ec538ae39 HTTP/1.1" 200 663 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/312.5 (KHTML, like Gecko) Safari/312.3"
yeah... yeah... ok... this bitch is accessing ONE specific file as Power PC Mac OS X ???
get the fuck outta here.
% Information related to '202.155.137.0/24AS212238'
route: 202.155.137.0/24
origin: AS212238
descr: CV. Rumahweb Indonesia
Jl. Arimbi No. 482
Kel. Banguntapan, Kec. Banguntapan
mnt-by: MAINT-CRI-ID
last-modified: 2025-02-25T00:03:14Z
source: APNIC