Ejabberd: Unterschied zwischen den Versionen
Dirk (Diskussion | Beiträge) K code → ic |
|||
Zeile 68: | Zeile 68: | ||
=== Nutzer-Registrierung === | === Nutzer-Registrierung === | ||
Über diese Option {{ic| | Über diese Option {{ic|auth_method}} im Abschnitt {{ic|AUTHENTIFICATION}} wird definiert, ob das interne Datenbanksystem (Mnesia), oder ein anderes verwendet werden soll. Zur Wahl stehen hier ein externes Script, eine beliebige Datenbank (ODBC), MySQL, PostreSQL, PAM oder LDAP. | ||
PAM oder LDAP können direkt in diesem Abschnitt konfiguriert werden, ODBC benötigt die Konfiguration der Datenbank im darauffolgenden Abschnitt. Es können voreingestellt MySQL oder PostgreSQL verwendet werden. Allerdings unterstützt ejabberd jede ODBC-Kompatible Datenbank. | PAM oder LDAP können direkt in diesem Abschnitt konfiguriert werden, ODBC benötigt die Konfiguration der Datenbank im darauffolgenden Abschnitt. Es können voreingestellt MySQL oder PostgreSQL verwendet werden. Allerdings unterstützt ejabberd jede ODBC-Kompatible Datenbank. |
Version vom 29. Mai 2013, 12:15 Uhr
XMPP ist eine von der IETF standardisierte Sammlung diverser XML-basierender Netzwerkprotokolle, die ein erweiterbares Messaging- und Anwesenheitsprotokoll darstellen.
Anders als die meisten anderen Messaging-Dienste ist XMPP dezentral aufgebaut. Die nötige Server-Software sowie das Protokoll um einen XMPP-Server zu betreiben sind ebenfalls frei verfügbar. So steht jedem Anwender die Möglichkeit offen, selbst einen XMPP-Server aufzusetzen.
XMPP eignet sich daher nicht nur, um großen, öffentlichen Nutzergruppen eine Möglichkeit der Kommunikation zu bieten, sondern auch, um im kleinen Rahmen schnell und einfach, und ohne große Hürden (XMPP-Clients sind für alle gängigen Architekturen und Systeme verfügbar) eine Kommunikationsmöglichkeit bereitzustellen.
Installation
ejabberd ist im community
-Repository verfügbar, und kann aus diesem mittels Pacman installiert werden.
pacman -S ejabberd
Nach der Installation sollte der Service noch mittels systemctl enable ejabberd
für den automatischen Start markiert werden. Allerdings sollte man vor dem ersten Start noch einiges anpassen und konfigurieren, und das System ein mal in einem Live-Modus testen.
Erster Start
Vor der Inbetriebnahme des XMPP-Servers sollte dieser konfiguriert werden. Alle Einstellungen werden in der Datei /etc/ejabberd/ejabberd.cfg
vorgenommen. Änderungen an dieser Datei bedürfen eines Neustarts des Services.
Aufbau der Datei
Die Datei hat eine für viele User vielleicht etwas ungewöhnliche Syntax.
% Dies ist ein Kommentar {definition, "wert"}. {anderedefinition, ["gruppe", "von", "werten"]}. {weiteres, [{wert, "mit"}, {gruppe, "die"}, {weitere, "definitionen"}, {setzen, "kann"}]}.
Der besseren Lesbarkeit halber können diese Definitionen auch umgebrochen und zudem innerhalb der Definitionen auch mit weiteren Kommentaren versehen werden.
{weiteres, [ % Setzt „wert“ und „gruppe“ {wert, "mit"}, {gruppe, "die"}, % Hier werden weitere Werte gesetzt {weitere, "definitionen"}, {setzen, "kann"}, % Verschachtelungen gehen auch noch {untergruppe, [ {optiona, "werta"}, {optionb, "wertb"}, {optionc, "wertc"} ]} ]}.
In der ejabberd-Konfigurationsdatei ist vor allem die letzte Form stark vertreten. In der Konfigurationsdatei werden Kommentare mit %%
oder %%%
versehen, was hier aber ignoriert werden kann.
Die Datei ist intern durch ausführliche Kommentierung in verschiedene Abschnitte unterteilt und gut dokumentiert.
Konfiguration
Vor dem ersten Start von ejabberd müssen noch einige Dinge angepasst werden. Zum Beispiel wurde noch kein Administrations-User angelegt, und der Hostname wurde zudem auch noch nicht definiert. Es wird hier nur die Grundkonfiguration mit nur einem einzigen Server (in der XMPP-Terminologie Node
) beschrieben. Dinge, auf die nicht eingegangen wird, können so belassen werden.
Hostname
ejabberd ist in der Lage, mehrere Hostnamen anzubieten. Allerdings muss der Rechner, auf dem ejabberd läuft, per DNS über den Hostnamen erreichbar sein, damit man diesen auch zum Anmelden nutzen kann.
In kleineren Umgebungen, die XMPP ausschließlich im LAN anbieten, ist es ausreichend, den LAN-Hostnamen zu verwenden. Sobald der Server aber auch von außen erreichbar sein soll, ist es ratsam, einen vollständigen Domain-Namen zu verwenden.
Die Hostnamen, mittels derer man sich am XMPP-Server anmelden kann werden im Abschnitt SERVED HOSTNAMES
in der Konfigurationsdatei definiert.
{hosts, ["xmpp", "xmpp.example.org"]}.
In diesem Fall werden zwei Hostnamen, xmpp
, und jabber.example.org
definiert. Es können am Server mit beiden Hostnamen Accounts registriert werden. Mit jabber
-Accounts kann man sich allerdings nicht an jabber.example.org
-Accounts anmelden, und umgekehrt.
Der Einfachkeit halber ist es also sinnvoller, ejabberd nur einen Hostnamen anbieten zu lassen, allerdings muss dieser auch als Liste deklariert übergeben werden.
{hosts, ["xmpp.example.org"]}.
So wird von ejabberd nur der FQDN angeboten. Verwirrungen durch verschiedene Hostnamen sind dadurch nicht mehr möglich. Zudem vereinfacht dies die Konfiguration.
Nutzer-Registrierung
Über diese Option auth_method
im Abschnitt AUTHENTIFICATION
wird definiert, ob das interne Datenbanksystem (Mnesia), oder ein anderes verwendet werden soll. Zur Wahl stehen hier ein externes Script, eine beliebige Datenbank (ODBC), MySQL, PostreSQL, PAM oder LDAP.
PAM oder LDAP können direkt in diesem Abschnitt konfiguriert werden, ODBC benötigt die Konfiguration der Datenbank im darauffolgenden Abschnitt. Es können voreingestellt MySQL oder PostgreSQL verwendet werden. Allerdings unterstützt ejabberd jede ODBC-Kompatible Datenbank.
{auth_method, internal}.
Wenn nichts elementar Wichtiges dagegenspricht, sollte der ejabberd-internen Nutzerverwaltung der Vorzug gegeben werden. Hier können mehrere hundert User verwaltet werden, und die Datenbank arbeitet dennoch performant.
Einschränkung der Registrierung
Wenn man einen festen Benutzerkreis hat, möchte man eventuell nicht, dass sich jeder beliebige Nutzer am Server registrieren kann, auch wenn der Server im Internet verfügbar sein sollte.
Im Abschnitt ACCESS RULES
kann definiert werden, dass die externe Nutzer-Registrierung nicht möglich ist. So kann nur der Administrator einen Nutzer anlegen.
{access, register, [{deny, all}]}.
Im selben Abschnitt können auch weitere Regeln definiert werden. Für den normalen Betrieb sind alle Regeln bereits mit sinnvollen Voreinstellungen belegt, so dass es hier keiner weiteren Änderung bedarf.
Administrator
Der erste Administrations-User ist der einzige User, der händisch in der Konfigurationsdatei angelegt wird. Dieser User besitzt alle Rechte, vergleichbar mit root. Es können allerdings beliebig viele „root“-User angelegt werden. Konfiguriert wird der Administrations-Account im Abschnitt ACCESS CONTROL LISTS
.
{acl, admin, {user, "root", "xmpp.example.org"}}.
Der so definierte User mit der User-ID root
am Server xmpp.example.org
verfügt somit über alle Rechte. Allerdings wurde der User noch nicht angelegt und verfügt noch über kein Passwort.
Darauf, wie ein User angelegt wird, wird später in diesem Artikel eingegangen.
Serversprache
Wenn man einen internationalen Server betreibt, ist englisch natürlich die erste Wahl, was die Statusmeldungen des Servers betrifft, wenn man hingegen einen rein von deutschsprachigen Nutzern verwendeten Server betreibt, kann man die Sprache natürlich auf deutsch stellen. Dies geschieht im Abschnitt DEFAULT LANGUAGE
{language "de"}.
Wenn man einen Server mit mehreren Hostnamen betreibt, kann man die Sprache auch je Hostname definieren.
Module
Über Module kann der XMPP-Server um Funktionen erweitert werden. Module werden im Abschnitt MODULES
geladen und konfiguriert.
Mehrbenutzer-Chat
Das standardmäßig aktivierte Modul mod_muc
erlaubt Mehrbenutzer-Chaträume auf dem Server. Standardmäßig ist der Hostname hierfür conference.HOST
, wobei HOST
der Hostname ist. Wem dies nicht zusagt, kann das angepasst werden.
{mod_muc, [ {host, "chat.@HOST@"}, {access, muc}, {access_create, muc}, {access_persistent, muc}, {access_admin, muc_admin} ]},
Hier wird der Mehrbenutzer-Chat-Host auf chat.@HOST@
gesetzt, @HOST@
wird durch ejabberd selbständig durch jabber.example.org
ersetzt. Diese Angabe bedarf keiner weiteren Konfiguration, da ejabberd sich selbständig um die Auflösung der Second-(bzw. Third-)Level-Domain kümmert.
Willkommens-Nachricht
Wenn man die User-Registrierung nicht deaktiviert hat, und sich ein neuer Benutzer am Server anmeldet, ist es möglich, diesem Nutzer per Server-Nachricht eine Meldung zukommen zu lassen, und jemanden darüber zu informieren, dass ein User-Account registriert wurde. Dies wird über das Modul mod_register
konfiguriert.
{mod_register, [ {welcome_message, {"Hallo!", "Willkommen auf diesem XMPP-Server!", "Immer schön artig bleiben!"}} {registration_watchers, ["regadmin@xmpp.example.org", "admin2@xmpp.example.org"]},
Über diese Konfiguration wird jedem neu registrierten User bei erster Anmeldung eine Nachricht geschickt.
Hallo! Willkommen auf diesem XMPP-Server Immer schön artig bleiben!
Zusätzlich werden regadmin@xmpp.example.org
und admin2@jabber.example.org
per Nachricht darüber informiert, dass ein neuer User-Account registriert wurde. Diese User müssen dafür natürlich existieren
Verteilte Kontaktliste
Damit man sich in Netzwerken nicht selbst darum kümmern muss, ob und wie alle Nutzer die weiteren User-Accounts auf dem Server in ihre Kontaktliste eintragen, gibt es eine Funktion, die sich „Shared Roster“ oder „Autoroster“ nennt. („Roster“, engl.: Mitgliedsverzeichnis). Diese Funktion wird über das Modul mod_shared_roster
verfügbar gemacht.
Wenn dieses Modul aktiviert (sprich: nicht auskommentiert) ist, ist es möglich, zu definieren, dass die Kontaktliste allen angemeldeten Mitgliedern automatisch zur Verfügung gestellt wird. So haben Nutzer, die sich erstmalig anmelden, sofort alle weiteren registrierten User-Accounts in ihrer Kontaktliste, ohne, dass sie diese manuell hinzufügen müssen.
Die Konfiguration der verteilten Kontaktliste kann später über das Web-Interface einfach konfiguriert werden. Dort können dann auch Nutzergruppen und deren gegenseitige Sichtbarkeit definiert werden.
Test-Start
Nach der Konfiguration in der ejabberd-Konfigurationsdatei sollte man den Server nicht gleich als Daemon starten, sondern vorerst einen Live-Test vornehmen. Dass dabei noch kein User existiert ist nebensächlich, es geht lediglich um die Funktion des Servers.
ejabberdctl live
Hiermit wird ein Live-Start ausgeführt. Alle Meldungen des Servers werden direkt auf der Konsole ausgegeben. Es wird vorerst allerdings ein Warntext ausgegeben, an den man sich halten sollte. Wenn man sich komplett „verrant“ haben sollte, oder den Test beenden will, einfach zweimal Strg+C drücken.
Nach dem Druck einer beliebigen Taste laufen viele Statusmeldungen durch das Terminal. Wenn am Ende der Statusmeldungen …
=PROGRESS REPORT==== 29-Apr-2009::12:04:39 === application: ejabberd started_at: ejabberd@localhost
… steht (Datum variiert natürlich), wurde der Server erfolgreich gestartet. Dies kann zudem auch mittels nmap auf den Host überprüft werden.
nmap xmpp.example.org
[…] PORT STATE SERVICE […] 5222/tcp open unknown 5280/tcp open unknown
Port 5222/tcp wird von XMPP für die Kommunikation verwendet. Port 5280/tcp wird vom Administrations-Webinterface verwendet. Sollten die beiden Ports nicht in der Portliste von nmap erscheinen, so muss die Firewall so konfiguriert werden, dass diese Ports weitergeleitet werden.
Der Live-Test auf dem Server kann dann mittels zweimal Strg+C beendet werden.
Nun kann entweder mittels ejabberdctl start
, dem Ausführen von systemctl start ejabberd
, oder einem Neustart des Systems, wenn zuvor systemctl enable ejabberd
eingegeben wurde, der XMPP-Server gestartet werden.
User anlegen
Zuerst sollte nun über ejabberdctl
der Administrations-Nutzer angelegt werden. Diese ist nötig, um auf das Web-Interface zugreifen zu können.
Da die Passwörter mit dieser Methode in Plaintext in der Bash-History angezeigt werden, sollte man diese entweder vorher deaktivieren, hinterher löschen, oder das Passwort auf etwas unkritisches stellen und die Nutzer zum Ändern des Passwortes auffordern.
ejabberdctl register root xmpp.example.org adminpasswort
Weitere User werden im selben Stil angelegt, man kann sich das Anlegen mehrerer User-Accounts allerdings vereinfachen.
for USER in frank dirk anton susanne michael andreas jana martina do ejabberdctl register $USER xmpp.example.org changeme done
Mittels dieses Scripts werden mehrere User gleichzeitig angelegt. Allen Usern wird das Passwort changeme
zugewiesen. Geändert werden kann das Passwort wahlweise durch den Administrator im Webinterface, oder von den jeweiligen Benutzern selbst über die Funktionen des von ihnen verwendeten Clients.
Sollte man die externe Registrierung nicht deaktiviert haben, ist es nicht nötig, weitere User über das Administrationstool anzulegen. Zudem kann in einem solchen Fall der administrative Account ebenfalls direkt über einen Client angelegt werden.
Wenn man bei deaktivierter externer Anmeldung lieber grafisch arbeitet, kann man die User auch über die Weboberfläche anlegen, nachdem der administrative User angelegt wurde.
Weboberfläche
Die Weboberfläche ist unter der Adresse http://xmpp.example.org:5280/admin
zu erreichen. Als Nutzername muss der Jabber Identifier (JID) des Administrations-Users verwendet werden, das Passwort ist jenes, das beim Anlegen des User-Accounts verwendet wurde. Also beispielsweise
- Username: root@xmpp.example.org
- Passwort: adminpasswort
Die Verwaltung des Servers erfolgt an zwei Stellen. Zum Einen gibt es die generelle Verwaltung, diese umfasst alle direkt erreichbaren Menüpunkte. Zum Anderen gibt es die spezielle Server-Verwaltung. Diese Befindet sich unter „Virtuelle Hosts“. Dort wählt man Namen des Hosts aus, dessen Einstellungen man bearbeiten möchte.
Man befindet sich durch die Auswahl des Hostnamens in einem Unter-Konfigurationsinterface. Hier können alle hostbezogenen Einstellungen vorgenommen werden. Mit einem Klick auf den Hostnamen über dem Menü gelangt man wieder zur Startseite der Host-Konfiguration, mit einem Klick auf den Header des Administrationsinterfaces gelangt man zurück zum Gesamt-Konfigurationsinterface.
Es wird nachfolgend immer vom Unter-Konfigurationsinterface ausgegangen. Änderungen, die über die Web-Oberfläche vorgenommen werden, bedürfen keines Neustarts des Daemons.
Userverwaltung
Über den Punkt „Benutzer“ gelangt man in die User-Verwaltung. Hier werden alle registrierten User-Accounts inklusive letztem Anmeldedatum des Nutzers angezeigt, zudem können hier weitere Accounts angelegt werden.
Durch einen Klick auf die JID eines Nutzers kann man weitere Einstellungen vornehmen und man bekommt zudem detailierte Informationen über den Account. So kann man hier das Passwort ändern, sieht die Offline-Nachrichten-Informationen des Users, und kann sich zudem die Kontaktliste anzeigen lassen, und diese auch bearbeiten.
Der Menüpunkt „Angemeldete Benutzer“ zeigt alle derzeit aktiven Benutzer auf dem Server. Ein Klick auf die JID führt zur selben User-Informations-Seite, wie unter „Benutzer“.
Automatische Kontaktliste
Die automatische Verteilung der Kontaktliste wird über den Menüpunkt „Gruppen der gemeinsamen Kontaktliste“ verwaltet. Zuerst sollte man eine Gruppe Alle
anlegen. In diese Gruppe werden per Alias alle Benutzer eingefügt.
Mit einem Klick auf Alle
wird diese Gruppe geöffnet. Hier können nun weitere Einstellungen vorgenommen werden. „Name“ und „Beschreibung“ sind frei wählbar. In das Feld „Mitglieder“ muss nun der Alias @all@
für alle User eingefügt werden. Damit gehören alle User dieser Gruppe an.
Nun hat man zwei Möglichkeiten. Im Abschnitt „Angezeigte Gruppen“ kann man nun entweder „Alle“ reinschreiben, oder man definiert hier weitere Gruppen, und lässt „Alle“ weg.
Autoroster-Beispiel
Der Aufteilung in Gruppen sind keine Grenzen gesetzt. So könnte man zum Beispiel in einem Unternehmen Gruppen je Abteilung anlegen. Für das Beispiel werden zwei Zusatz-Gruppen angelegt, um die Kontaktliste in Männer und Frauen zu trennen.
Es wird zunächst eine Gruppe „Alle“ angelegt. In das „Mitglieder“-Feld wird der Alias @all@
geschrieben. „Angezeigte Gruppen“ wird mit Männer
und Frauen
gefüllt.
Es wird nun eine Gruppe Männer
angelegt. „Mitglieder“ enthält hier nun keinen Alias mehr, sondern eine Liste der Benutzer, die dieser Gruppe angehören sollen.
andreas@xmpp.example.org anton@xmpp.example.org dirk@xmpp.example.org frank@xmpp.example.org michael@xmpp.example.org
Das Feld „Angezeigte Gruppen“ bleibt vorerst leer.
Der selbe Vorgang wird nun auch für die Gruppe „Frauen“ ausgeführt, diesmal werden in das „Mitglieder“-Feld nur die Useraccounts der weiblichen Nutzer eingefügt.
jana@xmpp.example.org martina@xmpp.example.org susanne@xmpp.example.org
Nun bestehen drei Gruppen. In der Gruppe „Alle“ sind durch den Alias @all@
alle User Mitglied. In der Gruppe „Frauen“ sind nur die User-Accounts der weiblichen Nutzer Mitglied, und in der Gruppe „Männer“ nur die User-Accounts der männlichen Nutzer. Dadurch, dass in der Gruppe „Alle“ als „Angezeigte Gruppen“, die Gruppen „Männer“ und „Frauen“ definiert wurden, werden allen Usern, die in der Gruppe „Alle“ sind, diese beiden Gruppen angezeigt.
Änderungen an der Shared-Roster-Funktion werden automatisch an die Clients weitergeleitet und sind in den Clients nahezu in Echtzeit nachvollziehbar.
Nun sei es so, dass für männliche Nutzer und für weibliche Nutzer getrennt Assistenz-Systeme eingerichtet werden sollen, die könnten zum Beispiel User-Accounts für Bots sein. Da die Kontaktliste aber kompakt gehalten werden soll, sollen die jeweiligen Assistenz-Systeme nur der entsprechenden Gruppe sichtbar sein.
Man legt nun für die Assistenz-Systeme jeweils eigene Gruppen an, und fügt die User diesen Gruppen hinzu. Sei die Assistenz-Gruppe für Männer MA
und für Frauen FA
. Die User seien ma1
bis ma3
, bzw. fa1
bis fa3
. So werden zwei Gruppen erzeugt, und diesen die jeweiligen Mitglieder hinzugefügt.
- MA
- ma1@xmpp.example.org
- ma2@xmpp.example.org
- ma3@xmpp.example.org
- FA
- fa1@xmpp.example.org
- fa2@xmpp.example.org
- fa3@xmpp.example.org
Nun wird die Gruppe „Männer“ geöffnet. In das noch leere Feld „Angezeigte Gruppen“ wird nun der Name der Männer-Assistenz-Gruppe MA
hineingeschrieben, und das Ganze bestätigt. In der Gruppe „Frauen“ wird analog dazu FA
in das Feld geschrieben.
So sehen Mitglieder der Gruppe „Männer“ nur die Gruppe MA
. Mitglieder der Gruppe „Frauen“ sehen hingegen nur die Gruppe FA
. Würde man die Gruppen MA
und FA
als angezeigte Gruppe in der „Alle“-Gruppe hinzufügen, würden alle User diese Gruppen sehen können.
User-Zuordnung
Soll im obigen Beispiel der User dirk@xmpp.example.org
, obwohl er in der Männer-Gruppe ist, das Assistenz-System FA2@xmpp.example.org
direkt sehen können, so ist unter „Benutzer“ auf dirk@xmpp.example.org
zu klicken. Auf der User-Informationsseite ist dann unter „Kontaktliste“ die JID fa2@xmpp.example.org
hinzuzufügen.
Zusätzlich sollte man diesen Vorgang für fa2@xmpp.example.org
wiederholen, und dort dirk@xmpp.example.org
zur Kontaktliste hinzufügen. Allerdings sollte ein Assistenz-System wie ein Bot die Authorisierung selbständig durchführen, so dass dies im Normalfall nicht nötig ist.
Der so hinzugefügte User erscheint im Client dann unter keiner Gruppe, bzw. in Pidgin unter der generischen Gruppe „Buddys“.
Transports
Mit ejabberd ist es möglich, auch andere Messaging-Dienste zu verwenden. Dies geschieht mit Hilfe von Transports. Transports sind Zusatzprogramme, mittels derer ein XMPP-Server fähig ist, auch als Server für andere Messaging-Dienste benutzt werden zu können. Es gibt für alle gängigen Dienste Transports. Für dieses Beispiel wird der Transport für ICQ installiert und konfiguriert.
Installation
Der Transport für ICQ heißt pyicqt und muss aus dem community
-Repository installiert werden.
pacman -S pyicqt
pyicqt muss dann noch aktiviert und gestartet werden.
systemctl enable pyicqt systemctl start pyicqt
Ob der Transport schon läuft, oder nicht, wenn ejabberd gestartet wird, ist nicht von Bedeutung.
Konfiguration pyicqt
Nach der Installation sollte aus Sicherheitsgründen ein Schlüsselwort gesetzt werden. Dies wird in der Datei /etc/ejabberd/pyicq.xml
konfiguriert. In diesem Fall wird key
als Schlüsselwort verwendet.
<secret>key</secret>
Zusätzlich muss in dieser Datei noch der Host eingestellt werden, unter dem der XMPP-Transport erreichbar sein soll. Dieser Host muss über das DNS auflösbar sein.
<jid>icq.xmpp.example.org</jid>
Es können noch weitere Einstellungen vorgenommen werden: So kann in der Zeile port
zum Beispiel der Verbindungs-Port angegeben werden, über den der Transport erreichbar ist. Auch können unter icqPort
und icqServer
die Konfiguration der ICQ-Seitigen Einstellungen vorgenommen werden. Für alle Einstellungen wurden sinnvolle Standardwerte gesetzt.
Konfiguration ejabberd
Der ICQ-Transport muss ejabberd noch in der Datei /etc/ejabberd/ejabberd.cfg
hinzugefügt werden, so dass dieser den ICQ-Dienst anbieten kann. Im Abschnitt LISTENING PORTS
wird ein neuer Eintrag erstellt.
{5347, ejabberd_service, [ {access, all}, {hosts, ["icq.xmpp.example.org"], [{password, "key"}] } ]},
Starten
Danach muss ejabberd (neu) gestartet werden. Ebenfalls muss pyicqt gestartet werden.
ejabberdctl start systemctl start pyicqt
Wenn man will, kann man auch erst pyicqt starten, und danach ejabberd mittels ejabberdctl live
in den Live-Modus versetzen, um eventuell auftretende Fehler direkt sehen zu können.