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.
Vielen Dank für die tolle Beschreibung. Gibt es jemanden, der anhand dieser Beschreibung Castopod aufsetzen konnte? Ich nutze Netcup und kann zum Beispiel (nach Änderung des Dokumentenstamms auf Public) das cp-install nicht aufrufen.
Was mich irritiert, dass es unter Themes den Ordner cp_install gibt, der aber auch nicht aufgerufen werden kann.
Ich habe auch die Anleitung auf der offiziellen Seite befolgt und es geht leider nicht.
Sehr schade, dass es am Ende wohl doch nur ein System für echte Experten zu sein scheint.
Ja, das ist ein wenig schade. Ich kann da nur raten, die Entwickler auf Discord anzuschreiben. Die sind sehr hilfsbereit.
Ich habe leider noch ein Problem mit den Cronjobs. Meine „Aktivitäten“ tauchen nicht im Fediverse auf. Hast du die so mit URL und einem Leerzeichen eingetragen? Auf diese Weise erhalte ich einen „bad request“. Füge ich ein ? zwischen index.php und der variablen ein, läuft es zwar durch und eine Mail wird mit den Aktivitäten wird an mich geschickt, doch mit einem anderen Account erhalte ich die Posts nicht 🙁
Hm, das ist alles ein wenig kompliziert. Ich habe das nicht so detailliert beschreiben können, weil ich es nicht komplett verstanden habe, was da passieren muss. Jedenfalls konnte ich bei all-inkl die Cronjobs nicht so aktivieren, wie es die Installationsanleitung (aus der ich die Passage weitgehend übernommen habe) vorsieht. Letztlich hat mir jemand mit zwei php-Files ausgeholfen, die ich darüber nun aufrufe. Ich werde den Artikel demnächst entsprechend updaten.
ah ok, dann verstehe ich es. Ich denke im php file steht etwas wie exec() und dieses ruft dann den eigentlichen Befehl auf. Danke.
Danke für die Anleitung. Ich murksel bei meiner Castopod-Installation noch herum, denn ich habe bereits relativ früh in der Anleitung ein Verständnisproblem. Du schreibst „Nach dem Upload lege ich eine Subdomain an, die auf meinem Webspace auf den Ordner /castopod/public zeigt.“ Kannst du das etwas ausführen? In der Castopod-Doku steht da „Set the web server document root to the public/ sub-folder within the castopod folder.“ Ich nehme an, das meint beides das gleiche? Bei dem mir zur Verfügung stehenden Server kann ich das dokument root leider nicht anpassen (lassen) – mir kam die Idee, ob das vielleicht mit einem htaccess-Redirect gehen könnte. Wie hast du das denn gemacht/ gelöst?
Das bedeutet das Gleiche. Du kannst beim Anlegen einer Domain oder Subdomain ja festlegen, auf welches Verzeichnis deines Servers diese zeigen soll. Es ist immer sinnvoll deine Projekte in Unterordnern zu organsisieren und das solltest du auch hier tun. Wenn jetzt also deine Castopod-Installation auf deinem Server im Verzeichnis /deineinstallation liegt, dann sollte die Domain http://www.deincastopodprojekt.de eben mit dem Ordner deinserver.de/deineinstallation/public verknüpft sein.