Mastodon ohne Gendern und mit 5000 statt 500 Zeichenbeschränkung

Mich stört bei Mastodon diese Cancel Culture und auch und vor allem das Gendern.
Das ist einfach eine schreckliche, unleserliche, politisch motivierte Verunstaltung der Sprache.

Deshalb habe ich per Hand die Sprachdateien geändert.

Außerdem gefällt mir nicht das man nur auf 500 Zeichen beschränkt sein soll bei der Länge der Posts.
Darum habe ich die Länge auf 5000 Zeichen geändert.

Das ganze gibts als Patch für die Version 4.2.7, aber sie sollte auch für Nachfolgeversionen funktionieren, zum runterladen.
Oben auf “Raw” klicken und “speichern als”.

sshd sftp chroot jail howto

Problem description:

You would like to jail users to their home directories and not allow shell access, only sftp access.

Solution:

SFTP chroot jail

1. Create a system group. Here I call it sftponly.

2. edit the sshd_config file, usually residing in /etc/ssh/sshd_config
(in weird opensuse it’s in /usr/etc/sshd/ )
and append (it needs to be appended at the end):

and restart sshd.

PasswordAuthentication No means, users can only login with their ssh key, no passwords allowed.

3. create the skeleton structure for each new user

we create .ssh htdocs and log dirs.

4. add a user and chown its home directory to root:root and set the login shell to nologin.
Also add this user to the sftponly group and set proper access octals.
On Rocky 9 it’s in /usr/sbin/nologin .

5. add the client’s ed25519 public key to /home/username/.ssh/authorized_keys

Where AAAA… is replaced by the actual public key from the client’s machine.
Check your /home/username/.ssh/id_ed25519.pub file or that of your customer/friend/etc.

And that’s it.
Yes, that’s all there is to it.

The user will be able to transfer files via SFTP in the sub directories you created in step 3, but not write or create directories in the root directory.

Today I learned about NATS, microservice API and security

Actual security, as in identity, is still a 3rd party thing, aka you still need a OIDC IDP (or oauth2 in the broadest sense or similar).
All NATS security does is validate that the credentials you pass the a client are valid and enforce limits, if configured.

The microservice API was necessary, since simple request/reply structure was lacking errors, logging and statistics.
micro.Request actually has a convenience req.RespondJSON() function.

A small example?

So right now I have, ent for the database stuff and nats over websocket for the service requests.
But I’m having big issues with NATS Jetstream.
The ws client is blocking, despite callbacks and async.

The micro package also has a long way to go.
Regular HTTP has middleware, micro doesn’t seem to have it, maybe I’m missing something. OTOH I could just pass the request to a next function, but it’s not very elegant.