Castopod (1): Installation, Sicherheit und Fallstricke

Castopod ist ein ziemlich neues Content Management System, das speziell auf Podcasting abzielt. Seit dem 18. Oktober 2022 ist das CMS aus der Beta-Phase heraus und es verspricht eine ganze Menge. Einerseits sollen darüber veröffentlichte Podcasts sehr stark mit dem Fediverse verknüpft sein, einem ganzen Wust von verschiedenen Anwendungen, die Twitter, Instagram und Youtube ähneln. Andererseits rühmen sich die Entwickler damit, besonders viele Features der Podcasting 2.0-Initiative zu integrieren. Grund genug, sich das System genauer anzusehen und das funktioniert am Besten dadurch, dass man es am lebenden Objekt ausprobiert.

Eines schicke ich direkt vorweg: Ich bin kein Software-Entwickler und kein Server-Admin, ich habe keine Ahnung von SSH, sudo oder sonst irgendwas, das über die Benutzung eines FTP-Clients und der Weboberfläche meines Shared Webspaces hinaus geht. Mutmaßlich gibt es also Wege, die viel schneller zum Ziel führen. Die Idee dieser Serie von Tutorials ist jedoch, Castopod einer breiten Masse von möglichen Nutzer*innen nahezubringen und das möglichst niedrigschwellig.

Download & Installation

Castopod gibt es grundsätzlich in einer kostenpflichtigen und in einer kostenlosen Variante. Auf Castopod.com kann man einen Hostingvertrag abschließen und muss sich nicht weiter um die technische Administration kümmern. Ich habe mein Installationspaket von Castopod.org heruntergeladen; alle Download-Links dort führen direkt zu einem ZIP-File mit der jeweils aktuellen Version. Das habe ich in einen lokalen Ordner entpackt und die Dateien anschließend per FTP in einen Ordner auf meinem Shared Webspace bei all-inkl.com hochgeladen.

Während der Upload lief, habe ich eine Datenbank angelegt, die für Castopod genutzt werden soll. Dabei ist es wichtig, dass eine MySQL-Version größer als 5.7 genutzt wird. Für das Installationsverzeichnis habe ich PHP-Version 8.1 aktiviert.

Wichtig ist auch, auf welcher Engine die Datenbank läuft. „InnoDB“ ist das präferierte „Datenbank-Betriebssystem“ für Castopod. Wenn du die Datenbank anlegst, kannst du in der myPHPAdmin-Oberfläche im Reiter „SQL“ diesen Befehl eingeben:

ALTER TABLE Dein_Tabellen_Name ENGINE = InnoDB;

So stellst du sicher, dass die Installation auch wirklich funktioniert. Bei all-inkl.com war eine alte MySQL-Engine im Einsatz, mit der Castopod nicht kompatibel ist.

Nach dem Upload lege ich eine Subdomain an, die auf meinem Webspace auf den Ordner /castopod/public zeigt. Danach rufe ich den Ordner /cp-install im Browser auf, wo direkt der Installations-Assistent startet:

Hier kann man zum Start erstmal alles so lassen wie es ist: Die Domain wird automatisch erkannt, die Medien-Basis-URL benötigt man nur, wenn die Mediendateien nicht auf der eigenen Domain liegen – wenn also etwa ein Content Delivery Network (CDN) genutzt wird. Admin- und Auth-Gateway dürfen so bleiben, wie sie sind. Aus Securitygesichtspunkten könnte es aber sinnvoll sein, hier etwas anderes einzustellen. Warum das so ist, erkläre ich später im Abschnitt „Sicherheit„.

Hier trägst du die Zugangsdaten zu deiner Datenbank ein. Aus Sicherheitsgründen rate ich dazu, das Tabellenpräfix in irgendwas abzuändern, das nicht „cp_“ ist. Warum ich das für sinnvoll halte, erkläre ich gleich im Abschnitt „Sicherheit„.

Diesen Schritt können vermutlich 90% aller Nutzenden problemlos überspringen. Wichtig ist hier der Hinweis „Belasse den Standardwert, wenn du keine Ahnung hast, was er bedeutet.“

Auch das ist selbsterklärend: Du legst hier den Nutzernamen, die E-Mail-Adresse und das Passwort für den Superadministrator fest. Castopod bietet die Möglichkeit, beliebig viele Podcasts und beliebig viele Podcastende zu verwalten. Der Superadministrator steht über allem und kann Podcasts und Nutzerkonten anlegen. Letztere haben abgestufte Privilegien, die sich entweder über das gesamte Netzwerk oder über einzelne Podcasts erstrecken.

Und los geht’s!

Cronjobs

Mit Castopod wird dein Podcast Teil des Fediverse. Damit deine Instanz auch richtig föderiert, musst du noch ein paar Cronjobs anlegen. Das geht bei spezialisierten Hosting-Anbietern im Webinterface oder, wenn du dich damit auskennst, auch über SSH oder wie das heißt. (Du merkst, ich kenne mich damit nicht aus und mag mein Klickibunti-Webinterface.)

Die Jobs müssen jeweils auf die index.php zeigen, einer heißt „scheduled-activities“ und einer „scheduled-websub-publish“. Wenn auf deinem Server ffmpeg installiert ist, solltest du auch den Cronjob „scheduled-video-clips“ anlegen. Die Entwickler*innen empfehlen, die Jobs jede Minute laufen zu lassen. Im Admin-Interface von all-inkl sieht das so aus, das dürfte sich aber von Anbieter zu Anbieter unterscheiden.

Für das Podjournal habe ich mich entschieden, die Cronjobs zunächst nicht so wahnsinnig oft laufen zu lassen. Ich weiß, dass nur einmal im Monat eine Episode erscheinen wird, deswegen reicht es meines Erachtens, dass scheduled-websub-publish eine Minute nach Veröffentlichung der Episode feuert. Was scheduled-activities macht, werde ich beobachten, vielleicht reicht es, wenn der alle 15 Minuten läuft. Gegebenenfalls passe ich das an die Empfehlung an.

Update: Nach einigen Tagen kann ich sagen: Lege die Cronjobs so früh wie möglich an, idealerweise noch bevor du die erste Episode veröffentlichst. Ich hatte ein paar Probleme mit der Einrichtung und deswegen liefen die Cronjobs bei mir erst an Tag 5 nach der ersten Veröffentlichung. Die hatten Einiges aufzuholen, entsprechend lange Skriptlaufzeiten und Fehlermeldungen waren die Folge. Das Ärger kannst du dir sparen, indem du diese Funktion von Anfang an mit an den Start bringst. Inzwischen laufen meine Cronjobs zuverlässig einmal pro Minute durch und die Interaktion mit dem Publikum funktioniert blendend.

Sicherheit

Wie immer im Internet sollte man sich Gedanken um die Sicherheit seiner Zugänge machen. Kein System ist wirklich sicher, aber man kann es möglichen Angreifern so schwer wie möglich machen. Meine IT-Kenntnisse sind, wie erwähnt, sehr limitiert, aber ein paar Best Practices möchte ich hier trotzdem hinterlassen.

Diese kommen aus meinem langjährigen Umgang mit WordPress, dem Content Management System auf dem nach Herstellerangaben rund 40% aller Seiten im Internet laufen. Weil WordPress so beliebt ist, gibt es eine Menge vorkonfigurierter Programme, die bekannte Schwachstellen attackieren und denen kann man zumindest ein paar Steine in den Weg legen.

Eingangs habe ich erwähnt, dass man aus Sicherheitsgründen den Admin-Gateway abändern sollte. Bei WordPress heißt der Link zum Einloggen /wp-admin, bei Castopod wird /cp-admin vorgeschlagen. Beides kann man im Installationsprozess ändern und so jemandem eine Brute Force-Attacke auf die Installation erschweren, weil der Angreifer nicht über den Standartlink zum Login kommt. Da Castopod noch nicht besonders weit verbreitet ist, ist das Risiko für so einen Angriff vermutlich her gering.

Außerdem habe ich dazu geraten, den Datenbank-Präfix zu verändern. Auch das ist ein Best Practice aus dem WordPressumfeld. Etwas mehr Sicherheit soll hier dadurch entstehen, dass deine Installation nicht ganz genau so aussieht, wie alle anderen.

Die Entwickler selbst geben eigene Sicherheitstipps, die sich auf die Ordner auf deinem Server beziehen. Diese Tipps solltest du aber erst nach der Installation befolgen. Wenn Du diese Anweisungen vor dem Installations-Assistenten ausführst, schlägt die Installation fehl!

Setze die Ordner „writeable“ und „public/media“ auf Lese- und Schreibzugriff und alle anderen Ordner auf read-only.

Fallstricke

Ich hatte bei der ersten Installation einige Probleme. Das lag aber daran, dass ich die Installationsanweisungen nicht vollständig verstanden habe. Der wichtigste Fehler war, dass ich direkt nach dem Upload die Ordnerberechtigungen gemäß den Sicherheitsregeln gesetzt habe, bevor ich den Installationsassistenten gestartet habe.

Auch beim nächsten Installationsversuch ging nicht alles glatt. Ich konnte mich zunächst nicht als Superadmin einloggen. Die Entwickler bieten aber ganz großartigen Support auf ihrem Discord-Server und mit deren Hilfe habe ich dann herausgefunden, dass die Datenbank-Engine meines Hosters nicht mit Castopod kompatibel war und was ich tun musste, damit sie kompatibel ist. Diesen Schritt habe ich weiter oben erklärt.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert