trueten.de

The default character limit for new toots in Mastodon is 500. But what if you want to increase or decrease it? With Mastodon version 4.2.*, the previous instructions for adjusting or increasing the number of characters in posts are obsolete. Basically, the compose.js file is now called differently and must be edited in a different path. I show how, with a big thank you to drakfrid, whose instructions I have adapted accordingly:

We will edit three different files, two which set the character limit on your instance, and one which tells other clients or apps what your custom character limit is (for those that support it).

1. Switch to the mastodon user

su - mastodon

2. Edit the file live/app/javascript/mastodon/features/compose/component/compose_form.js in your favourite text editor,

nano live/app/javascript/mastodon/features/compose/components/compose_form.js

find the number 500 (it should be written in two different locations). Change both of them to whatever you like.

3. Edit live/app/validators/statuslengthvalidator.rb,

nano live/app/validators/status_length_validator.rb

and once again find the number 500 (should exist only once) and change it to the same number as you wrote in the previous file.

4. Edit live/app/serializers/rest/instance_serializer.rb,

nano live/app/serializers/rest/instance_serializer.rb

and find the row starting with
:languages, :registrations,
(should be the ~8th row), and change it so it includes ”:maxtootchars” after ”:registrations”, such as
:languages, :registrations, :maxtootchars,
where the full row now looks something like
:languages, :registrations, :maxtootchars, :approvalrequired, :invitesenabled

At the end of the same file, above where it says private, add the following code:

def max_toot_chars
   <your value here>
end

and change <your value here> to the same value you wrote previously.

5. Enter the live directory and recompile Mastodon,

RAILS_ENV=production bundle exec rails assets:precompile

6. Switch to the root user (with exit), and restart the Mastodon services,

systemctl restart mastodon-sidekiq
systemctl reload mastodon-web

and optionally restart the streaming API server,

systemctl restart mastodon-streaming

And you’re done! You should now be able to see the new character limit on your Mastodon instance.

---

Bei der Verwendung des Softwareinstallationsscriptes add-apt-repository - das im Paket software-properties-common enthalten ist - auf Debian 12 kommt es zu folgender Fehlermeldung:

sudo add-apt-repository ppa:bashtop-monitor/bashtop
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in
    sys.exit(0 if addaptrepo.main() else 1)
                  ^^^^^^^^^^^^^^^^^
  File "/usr/bin/add-apt-repository", line 345, in main
    shortcut = handler(source, *shortcut_params)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line 40, in shortcut_handler
    return handler(shortcut, *kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 86, in init
    if self.lpppa.publishdebugsymbols:
       ^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 126, in lpppa
    self.lpppa = self.lpteam.getPPAByName(name=self.ppaname)
                  ^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 113, in lpteam
    self.lpteam = self.lp.people(self.teamname)
                   ^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'people'

Was ärgerlich ist, kann doch mit diesem Script eine Softwarequelle einfach zu den Systemquellen des Rechners hinzugefügt werden ohne sich groß mit den nötigen gpg Keys usw. befassen zu müssen - diese werden nämlich gleich mit heruntergeladen und installiert. Ein guter Komfortgewinn für faule User. ;-)

Die Fehlermeldung kommt von der fehlenden Python Bibliothek python3-launchpadlib. Nach Installation derselben funktioniert add-apt-repository einwandfrei.

Nach einem Hinweis von dieser Quelle bearbeitet.

---

Bei der Installation eines NextCloud Servers nach der Anleitung von Rafael Nockmann auf einer Synology Diskstation fiel mir auf, daß die zum Betrieb notwendigen cronjobs nicht funktionieren. Synology biegt offenbar so einiges im DSM System um. Da dieses jedoch auf Linux basiert, gibt es Hoffnung. ;-)

Zum Glück braucht es für wiederkehrende Aufgaben wie in diesem Fall nicht zwingend den cron Daemon, auch über systemd gibt es die Möglichkeit, solche zu erledigen. Langer Vorrede kurzer Sinn:

1. per ssh auf die Diskstation einloggen und dann als root per sudo -iH weitermachen. Alternativ als normaler User arbeiten und vor die Befehle dann sudo stellen.

2. mit nano /etc/systemd/system/nextcloudcron.service eine Datei mit folgendem Inhalt anlegen:

[Unit]

Description=Nextcloud cron.php job

[Service]

User=root

ExecStart=/bin/sudo -u http /usr/local/bin/php82 --define apc.enable_cli=1 /volume1/web/nextcloud_app/cron.php

KillMode=process

3. mit nano /etc/systemd/system/nextcloudcron.timer eine Datei mit folgendem Inhalt anlegen:

[Unit]

Description=Run Nextcloud cron.php every 5 minutes

[Timer]

OnBootSec=5min

OnUnitActiveSec=5min

Unit=nextcloudcron.service

[Install]

WantedBy=timers.target

4. mit systemctl enable nextcloudcron.timer die Änderungen aktivieren.

5. Diskstation neu starten und in NextCloud / Grundeinstellungen kontrollieren, ob der gewünschte Erfolg eingetreten ist.

6. Freuen :-)

Anmerkung: in nextcloudcron.service läuft der Dienst als Benutzer root, der per sudo den User http den Befehl /usr/local/bin/php82 --define apc.enable_cli=1 /volume1/web/nextcloud_app/cron.php ausführen lässt. Leider ist es - zumindest bei mir - nicht möglich, den Dienst als User http laufen zu lassen, ohne noch tiefer ins System einzugreifen.

Die Quelle: NextCloud

---

Hinweis: Einige der Links in diesem Beitrag beziehen sich auf Affilate-Links. Wenn Sie eines der verlinkten Produkte kaufen, unterstützen Sie mich. Das Produkt selbst wird Sie nicht mehr kosten als üblich. Vielen Dank dafür.

Note: Some of the links in this post refer to affilate links. If you buy one of the linked products, you support me. The product itself will not cost you more than usual. Thank you.

---

Wegen ein paar Jahrzehnte alter Leichen im Keller - genauer: inkonsistente Zeichensätze in der Blogdatenbank - kam es mit der gestrigen Umstellung der MariaDB Version auf 10.10 zu einigen seltsamen Zeichen, vor allem bei den (internationalen) Sonderzeichen.

Wir bitten das Ungemach zu entschuldigen. Inzwischen sollten die meisten Beiträge wieder korrekt dargestellt werden. Über Meldungen zur Sichtung übersehener Beiträge freuen wir uns.

Im Zuge der Durchsicht der Beiträge wurden auch gleich nochmal die Hashtags / Schlagwörter überarbeitet, korrigiert und in Teilen zusammengefasst. Ebenso wurden ein paar Links aus unserer Empfehlungsliste entfernt.

---

Manchmal sinnvoll: Ein Watchdog. Wenn dieser nicht schon Bestandteil des Mainboards ist besteht die Möglichkeit entweder zu hoffen, daß der Software Watchdog einen Systemhänger erkennt und diesem noch mit einem reboot des Systems entgegentreten kann. Oder man verwendet einen USB Hardwarewatchdog, den es beim freundlichen Chinesen oder in Jeff's Gemischwarenladen relativ günstig gibt. Von beiden Varianten, die natürlich nicht die Ursache des Hängers lösen und - auch das muss gesagt sein, bei der USB Variante eventuell Probleme mit dem Dateisystem verursachen können, möchte ich hier kurz auf letztere eingehen. Denn manchmal ist ein Reset ausreichend, vor allem dann, wenn man nicht an den Rechner kommt, weil man zum Beispiel im Urlaub weilt und der Server daheim augerechnet dann die Grätsche macht.

Der Watchdog selbst besteht aus einer unscheinbaren Platine, an deren einen Ende ein USB Stecker sitzt und am anderen mit einer Stiftleiste versehen ist. Auf dem Stecker selbst sitzen neben ein paar kleineren Bauteilen zwei deutlich sicht- und beim Einstecken hörbare Relais. Geliefert wird das ganze spartanisch in einer Antistatiktüte, nochmal in einer weiteren Plastiktüte verpackt. Mitgeliefert werden zwei ausreichend lange Kabel für die erwähnte Stiftleiste. Kein Handbuch oder Installationsanleitung, was aber nichts macht, da dem aufmerksamen Besteller:*in die Links in der Artikelbeschreibung aufgefallen sind:

Englische Version der Überwachungs-Software Download: http://www.wfyl.cn/dzyj/PCWatchDog_VX_en.rar
Linux Treiber Download: http://www.wfyl.cn/dzyj/USBWatchdog_LINUX.zip
MacOS-Treiber-Download: http://www.wfyl.cn/dzyj/USBWatchdog_MAC.zip
Android Treiber Download: http://www.wfyl.cn/dzyj/USBWatchdogR_ANDROID.zip

Naja. Ich persönlich lade lieber nichts von Webseiten herunter, die in einer mir unverständlichen Sprache und zudem mit Adobe Flash Animationen versehen sind. Statt dessen fand meine Suchmaschine des Vertrauens heraus, daß es ein git Repository zu diesen Watchdogs gibt, das ein simples Python Script zur Verfügung stellt. Das Repo ist einige Jahre alt, dankenswerter Weise hat Wojciech NiziÅ„ski einen Pull Request eingestellt, der ein Update auf Python3 enthält. Die Dateien zieht man sich im Terminal auf den Zielrechner mit

gh repo clone niziak/usb-watchdog

in das gewünschte Verzeichnis, woraufhin sich die Dateien im Verzeichnis usb-watchdog befinden. Dort startet man nach der obligatorischen Kontrolle der Sicherheit des Quellcodes die Installation als User mit make, danach mit sudo make install das Kopieren der Programmdateien usw.

Der Stick selber wird in den Rechner gesteckt, danach verbindet man die Kabel mit den Mainboard Pfostensteckern für das HDD LED und den Resetschalter. Wichtig sind 2 Punkte:

• Erst den USB Stick einstecken, dann die Pfostenstecker in eingeschalteten Zustand des Rechners verbinden. Ansonsten kann es sein, daß die Relais auf der Platine im Zustand NO / offen sind, wenn der Rechner eingeschaltet wird und man somit in einer Resetschleife landet.
• Die Reaktionszeit / Heartbeat, die man in der Datei usb-watchdog.service unter [Service] in der Zeile
  
  

  ExecStart=/usr/bin/python3 /usr/local/sbin/watchdog.py --hb 360/dev/ttyUSB0

  einstellt, sollte nicht zu knapp bemessen sein, so daß eine kurzzeitige Rechnerlast nicht als Absturz interpretiert und ein Reset eingeleitet wird. Im Beispiel ist diese auf 360 Sekunden eingestellt, und bezieht sich auf den Watchdog, der als /dev/ttyUSB0 eingebunden wurde.

Quellen: David Gouveia

---

Hinweis: Einige der Links in diesem Beitrag beziehen sich auf Affilate-Links. Wenn Sie eines der verlinkten Produkte kaufen, unterstützen Sie mich. Das Produkt selbst wird Sie nicht mehr kosten als üblich. Vielen Dank dafür.

Note: Some of the links in this post refer to affilate links. If you buy one of the linked products, you support me. The product itself will not cost you more than usual. Thank you.

---

Dank eines Hinweises wurde ich auf einige Fehlermeldungen in unserem Blog aufmerksam, die ich beim kürzlichen Upgrade von Serendipity auf die aktuelle Serendipity 2.4-beta1 übersehen hatte. Im Nachhinein stellt sich dieses für mich jedenfalls ordentlich verbuggt dar.: Verschiedene Plugins laufen nicht, weshalb es vorerst unter anderem keine Kommentare mehr gibt, die dargestellt werden und auch keine Social Media Buttons unter den Beeiträgen. Da auch diverse css Sachen ins Leere laufen, bin ich vom Bootstrap Theme wieder auf 2k11 zurück.
 

Weil ich hach einigen Versuchen nur per Zufall darauf gekommen bin - den Hinweis auf dieses Problem hatte ich so noch nirgendwo gefunden:

Q: I encountered a compilation error while executing RAILS_ENV=production bundle exec rails assets:precompile, but no more information is given. How to fix it?

A: Usually it's because your server ran out of memory while compiling assets. Use a swapfile or increase the swap space to increase the memory capacity. Run RAILS_ENV=production bundle exec rake tmp:cache:clear to clear cache, then execute RAILS_ENV=production bundle exec rails assets:precompile to compile again. Make sure you clear the cache after a compilation error, or it will show “Everything's OK” but leave the assets unchanged.

Die Lösung bei unserer Installation bestand allerdings darin, eine nodejs Version 16.x zu verwenden.

Wir betreiben ab sofort auch eine eigene Mastodon Instanz: mastodon.trueten.de Momentan ist dort alles im Testlauf. Man kann sich aber schon registrieren und herumspielen. Bis auf weiteres bin ich selbst bei suma-ev.social aktiv. 

• Rassistische Wissensbestände stellen in deutschen Behörden keine Ausnahme dar. Auch unsere Forschung zeigt: Sie sind strukturell eingebettet und werden institutionell (re-)produziert.
• Handlungsunsicherheiten in Behörden begünstigen die (Re-)Produktion von –šaltem–˜ und –šneuem–˜ rassistischen –šWissen–˜.
• Für Betroffene führen Othering-Prozesse durch Behörden zu differenziellen Ein- und Ausschlüssen von sozialstaatlichen Leistungen sowie zu Stigmatisierungen.
• Um institutionellem Rassismus entgegenzuwirken, bedarf es einer Vielzahl an Maßnahmen, etwa einer kritischen Reflexion behördlicher Routinen, systematischen Monitorings behördlicher Entscheidungen sowie rassismuskritischer Schulungen.

Die aktuelle Studie der Universität Duisburg Essen ist unter diesem Link als PDF online.

Seit einigen Jahren bin ich auf mastodon mehr oder weniger aktiv. Nachdem sich jetzt der SUMA e.V. –“ Verein für freien Wissenszugang entschieden hat, eine eigene Mastodon Instanz aufzusetzen, dachte ich mir, gut, dann packe ich mal meine sieben Sachen und migriere rüber. Ich bin dort unter rumpelstilz@suma-ev.social erreichbar. Der SUMA e.V. betreibt in Zusammenarbeit mit der Universität Hannover die Suchmaschine MetaGer.