Das Formular war 3 Seiten lang. Der beiliegende Zahlschein war auf ~A4 ausgedruckt. Das Foto jedoch, wichtigstes Indiz bei der "Zeugenbefragung", war nicht enthalten. Ich konnte mich auf einer Website der Brandenburger Polizei einloggen, um mir die Bilder anzusehen. Recht umständlich.

Wahrscheinlich ist es eine Web 2.0-Offensive der Polizei -- ein anschauliches Beispiel des Mitmach-Webs: Bürger können sich auf einer Polizei-Website einloggen und irgendwie auch abstimmen. In meinem Fal über die Qualität der Bitzerfotos.

Prinzipiell begrüße ich ja solchen Bestrebungen sehr. In diesem Fall wäre es jedoch sinnvoller gewesen, die Fotos auf Seite 4 des Protokolls auszudrucken und die zusätzlichen Druckkosten bei Überweisungsträgern im Formt A5 wieder reinzuholen.

Da ich nicht weiß, wie lange die ursprünglichen Websites noch "am Netz" sind, möchte ich auf dieser Seite alle Ressourcen zusammentragen.

Drush-Session v1.0 in Deutsch

Beim Drupal Day MV im März 2011 hielt ich den Drush-Vortrag zum ersten Mal und in Deutsch.

• Vorstellung der Session auf der DrupalDay-Website
• Drush - Website-Administration leicht gemacht als PDF
• Drush-Website-administrationLeichtGemacht, der Video-Mitschnitt auf archive.org

Drush-Session v2.0 in Englisch

Ich hatte die Session vom Drupal Day MV noch mal für das DrupalCamp in Berlin eingereicht, diesmal in Englisch. Die Gelegenheit habe genutzt, die "Folien" nicht nur ins Englische zu übersetzen, sondern auch inhaltlich zu überarbeiten und mit meinem Wissensstand abzugleichen. Dem Englisch-Kundingen empfehle ich also dieses PDF (aber nicht das Video ;)

• Vorstellung der Session auf der DrupalCamp-Website
• Drush - managing drupal - the easy approach als PDF,
• Drush - managing drupal - the easy approach, der Video-Mitschnitt auf Vimeo.

Damit haben ich (nahezu) alles zu Drush gesagt, für meine nächste Session werde ich mir ein neues Thema suchen. Wenngleich die site aliases mit ihrer Mächtigkeit noch ein paar Blogposts verdient hätten. :)

Auf dem Server setzte ich Debian Linux als Betriebssystem und duplicity als Backup-Software ein. Dieses Backuptool verschlüsselt die Backups mit GPG-Schlüssel, somit braucht man eine intakte (vorzugsweise unixartige) Systemumgebung und den GPG-Schlüssel, mit dem das Backuparchiv erstellt wurde. Meine Herausforderung war nun, die auf einem Linux-Server erstellten Backup-Archive auf dem Mac wieder auszupacken, um die wiederhergestellten Git-Repositories auf einen anderen Server zu verschieben.

Duplicity bekommt man mit Homebrew in Sekundenstelle installiert, ebenso das Skript duply, ein Wrapper für duplicity, der die Konfiguration und Bedienung extrem vereinfacht.

sudo brew install duplicity

sudo brew install duply

nun braucht man die duply-Konfiguration, lag auf dem Server unter /etc/duplyund kann auf dem Mac in ~/.duplyabgelegt werden. Ich nenne das Backup-Set mal "gitrepo", das Backup-Set liegt in ~/backups. Es muss noch in der Datei ~/.duply/gitrepo/conf der Pfad zu den Backup-Ordnern geändert werden, z.B.

TARGET='file:///var/backups/duply/gitrepo/'

in

TARGET='file:///Users/drue/backups/gitrepo/'

Nun kann man die Wiederherstellung starten, der GPG-Schlüssel-ID und das Passwort steht in der Duply-Konfiguration. In diesem Beispiel soll das Backup ins Verszeichnis ~/gitrepo wiederhergestellt werden.

$ duply gitrepo restore ~/gitrepo

Start duply v1.5.4, time is 2012-02-03 16:11:46.

Using profile '/Users/drue/.duply/gitrepo'.

Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).

Autoset first GPG_KEY entry '09ABCDEF' as signing key.

Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)

Test - Decrypt (OK)

Test - Compare (OK)

Cleanup - Delete '/tmp/duply.17084.1328281906_*'(OK)



--- Start running command RESTORE at 16:11:47.000 ---

Max open files of 120 is too low, should be >= 1024.

Use 'ulimit -n 1024' or higher to correct.



16:11:47.000 Task 'RESTORE' failed with exit code '37'.

OK, es ist eben kein Server. Duplicity beklagt, dass die Höchstgrenze gleichzeitig geöffneter Dateien mit 120 zu gering ist. Das lässt sich mit

ulimit -n 1024

auf jedem unixartigen System hochsetzen. Ein alternatives mac-spezifisches Kommando ist

launchctl limit 1024 10240

Nun ein weiterer Versuch:

drue@ain:~$ duply gitrepo restore ~/gitrepo

Start duply v1.5.4, time is 2012-02-03 16:10:32.

Using profile '/Users/drue/.duply/gitrepo'.

Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).

Autoset first GPG_KEY entry '09ABCDEF' as signing key.

Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)

Test - Decrypt (OK)

Test - Compare (OK)

Cleanup - Delete '/tmp/duply.16860.1328281836_*'(OK)



--- Start running command RESTORE at 16:10:36.000 ---

Synchronizing remote metadata to local cache...

Copying duplicity-full-signatures.20110910T232302Z.sigtar.gpg to local cache.

Traceback (most recent call last):

  File "/usr/local/bin/duplicity", line 1377, in <module>

    with_tempdir(main)

  File "/usr/local/bin/duplicity", line 1370, in with_tempdir

    fn()

  File "/usr/local/bin/duplicity", line 1246, in main

    sync_archive(decrypt)

  File "/usr/local/bin/duplicity", line 1059, in sync_archive

    copy_to_local(fn)

  File "/usr/local/bin/duplicity", line 1008, in copy_to_local

    tdp.move(globals.archive_dir.append(loc_name))

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 617, in move

    self.copy(new_path)

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 443, in copy

    self.copy_attribs(other)

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in copy_attribs

    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/util.py", line 65, in maybe_ignore_errors

    return fn()

  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in <lambda>

    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))

OSError: [Errno 1] Operation not permitted: '/Users/drue/.cache/duplicity/duply_gitrepo/duplicity-full-signatures.20110910T232302Z.sigtar.gz'

An dieser Stelle habe ich aufgehört, mein Glück mit Duply zu veruchen, da es abbricht, weil es ein paar erweiterte Dateiattribute nicht setzen kann. Beim nächsten Versuch habe ich mir das eigentliche Duplicity-Kommando gesucht und im Ubuntu-Hilfe-Wiki gefunden. Wenn man das GPG-Passwort nicht in der Umgebungsvariable PASSPHRASE hinterlegt, wird man bei der Ausführung des Kommandos duplicity restore ... erfragt.

export PASSPHRASE=SomeLongGeneratedHardToCrackKey

duplicity restore file:///Users/drue/duply/gitrepo/ gitrepo

unset PASSPHRASE

Nun kommt noch immer diese Fehlermeldungen:

...

Error '[Errno 1] Operation not permitted: 'gitrepo/repositories/image_server.git/objects/45'' processing .

...

Das Kommando aber läuft durch. Ich hatte meine Git-Repositories zurück und habe sie mittlerweile funktionierend und an neuer Location wieder am Start.

Epilog

Den Beitrag habe ich geschrieben, um alle im Netz verstreut liegenden Infos zusammenzutragen und den Suchmaschinen zu den Fehlermeldungen die passenden Beschreibungen zu liefern. ;)
Ein wichtige Lehre ist wiedermal: Hast Du alle Daten zur Hand, die Du zur Wiederherstellung brauchst. In diesem Fall waren das der GPG-Schlüssel, das zugehörige Kennwort und natürlich ein möglichst aktuelles und konsistentes Backup.

Hätte die Wiederherstellung auf dem Mac nicht funktioniert, wäre der nächste Programmpunkt, eine Jiffybox mit Debian Linux einzurichten, die Backups auf diesen vServer zu transferieren und mit nahezu identischer Systemumgebung ausgepackt. Hätte aber ein paar Stunden länger gedauert.

Dabei habe ich die drei verlockendsten Arbeitsplatz-Optionen -- das heimische Arbeitszimmer, ein Coworking Space und ein Schreibtisch in einem anderen Büro -- miteinander verglichen und mich für letztere Alternative entschieden.

Somit suche ich zum 1. März einen Platz in einer Bürogemeinschaft in der Rostocker Innenstadt.Wenn Du eine Bürogemeinschaft oder eine kleine Firma mit freiem Schreibtisch kennst, dann schreib mir eine Mail an dirk at niebegeg.net. Ob wir zusammenpassen, können wir dann schnell in einem Gespräch herausfinden. Ich bin schon gespannt!

Mit dem Umzug auf ein Shared Hosting fiel die StreamRipper-option weg. Auch war es nach den ~4 Jahren Zeit, dass ich mir das Skript mal für ein Update vornehme.

Herausgekommen ist CaptuRadio, ein ausschließlich in Python geschriebenem Tool, der mein bisheriges Setup komplett ersetzt und ein paar neue Optionen hinzufügt. Das Projekt besteht aus zwei Skipten:

• capturadio.py zum Mischneiden der Streams und
• create_podcast_feed.py zum Generieren von RSS-Feed-Dateien in den Verzeichnissen mit den Mitschnittdateien.

Weiterhin übernehmen Cronjobs die Zeitsteuerung. Ich will die Mp3-Mitschnitt-Dateien als "private Podcasts" unter einer Subdomain für mich zum Download bereitstellen, nennen wir sie http://music.example.org/. Wie funktioniert das nun?

Nach der erfolgreichen Installation wird eine Datei ~/.capturadiorc oder ~/.capturadio/capturadiorc erstellt und dort die Stream-URLs als Stationen definiert

[settings]

destination = ~/music.example.org/



[stations]

dlf = http://dradio.ic.llnwd.net/stream/dradio_dlf_m_a

dkultur = http://dradio.ic.llnwd.net/stream/dradio_dkultur_m_a

Nun wird ein Cronjob definiert, der das Skript aufruft (Anmerkung: Ich habe capturadio.pyund create_podcast_feed.py nach ~/bin installiert, dieser Ordner ist in meinem Pfad enthalten):

5 1 * * 2   capturadio.py -s dlf -l 3300 -b Nachtradio -t "Jazz zur Nacht"

Da in der Konfigurationsdatei im Abschnitt [settings] ein Wert destination definiert ist, werden die Mitschnitte dort abgelegt. Nun läuft einmal je Stunde per Cronjob das Skript `

@hourly create_podcast_feed.py -r ~/music.example.org/

und erzeugt in allen Ordnern unterhalb von ~/music.example.org/ eine Datei rss.xml, die jeweils alle darunter befindlichen MP3-Dateien als Podcastfeed ausliefern kann.

Letzte Aktion ist, eine Datei .htaccess im Ordner ~/music.example.org/ mit folgendem Inhalt anzulegen:

DirectoryIndex rss.xml   

IndexOptions Type=application/rss+xml

So werden mit den "Podcast"-URLs

• http://music.example.org/ alle vorhandenen Mittschnitte abgerufen
• http://music.example.org/Deutschlandfunk alle vorhandenen Mittschnitte der Station mit dem Namen "Deutschlandfunk" abgerufen
• http://music.example.org/Deutschlandfunk/Nachtradio alle vorhandenen Mittschnitte der Sendung "Nachradio" im "Deutschlandfunk" abgerufen

So kann ich meiner Tochter eine Kindersendung mitschneden und ihr Podcast-Client ruft nur den Feed zu ihrer Sendung ab, währenddessen ich täglich zu tn habe, all die anderen Mitschnitte nachzuhören.

Achja: Ein weitere Cronjob ist für die Verzeichnishygiene verantwortlich und löscht alle Podcasts, die älter als 7 Tage sind.

@daily   find ~/music.example.org/ -mindepth 1 -mtime +7 -type f -name *.mp3 -exec rm "{}" ;

Diese Miniprojekt hat erfreulicherweise nur zwei Abende in Anspruch genommen, auch dank eleganter APIs und Bibliotheken. Und ich hatte nach Jahren der Pause wieder mal Gelegenheit, mich der Programmiersprache Python zu nähern. Hat Spaß gemacht und könnte eine Fortsetzung erfahren. Mit dem Projekt bin ich natürlich auch noch nicht fertig, aber: Es läuft und ist mein aktuelles "Projekt des Monats". :)

Ich hatte viel Spaß mit meinen Kollegen und Mitgründern, habe eine Menge gelernt und viele Projekte mitgestaltet und realisiert. Aber in den letzten Jahren habe ich mein Langzeithobby "Web" zunehmend zum beruflichen Lebensmittelpunkt entwickelt. Das passt nicht in das mit Android, Eclipse und OSGi recht Java-zentrierte Leistungsspekturm meiner bisherigen Firma. Wem all die Buzzwords nichts sagen, hier die Kurzform: Wir haben uns auseinander gelebt.

Ich werde ab März für die Hamburger Firma F2E für die Weiterentwicklung und den Anwendersupport einer Webanwendung verantwortlich sein. Damit kehre ich als studierter Maschinenbauer in meine ursprüngliche Anwendungsdomäne zurück. Ich werde viel mit Windparks, deren Berechnung und Projektanten zu tun haben. Und freue mich schon riesig auf die neue Aufgabe.

PS: Sollte nun jemand fragen, was das mit den in diesem Blog behandelten Schwerpunktthemen zu tun hat: Ich werde mit meiner Familie in Rostock bleiben. Und Drupal wird bei meiner zukünftigen Arbeit eine gewichtige Rolle spielen. Ich werde also der lieb gewonnenen Community und meinem Steckenpferd treu bleiben. Klare Sache!

"Multisite" ist eine raffinierte Funktion, um mehrere Drupal-Websites aus einer Codebasis zu betreiben: Im Webserver werden mehrere Domainnamen auf das selbe Drupal-Installationsvverzeichnis konfiguriert. Beim Seitenaufruf ermittelt Drupal den Domainnamen zum Request, sucht im Ordner sites/ den passenden Ordner mit den Konfigurationsdaten. Wenn es für die gesuchte Domain keinen Ordner gibt, dann wird im Ordner sites/default/ nachgesehen. Die im Konfigurationsordner vorhandene Datei settings.php enthält unter anderem die nötigen Datenbank-Informationen und Drupal liefert mit den in der Datenbank abgelegten Daten schließlich die Webseite aus. Eine detaillierte Beschreibung zu Multisites liefert das Handbuch auf drupal.org sowie die Linkliste am Podcastbeitrag.

Diese Funktion war ein unverzichtbares Hilfsmittel, als Festplattenkapazität auf dem Server kostbar war und FTP die einzige administrative Zugriffsmöglichkeit auf den Server war: Bei der Installation einer neuen Website braucht man nur einen neuen Konfigurationsordner anlegen, die settings.phpdorthin kopieren und anpassen und eine neue Datenbank befüllen. Beim Update eines Moduls kopiert man die von drupal.org heruntergeladene Modulversion per FTP auf den Server und ruft für jede Website die Updatefunktion im Browser auf. Und genau diese Arbeitserleichterng ist das Problem mit Multisites: Nach dem Austauschen der Moduldateien muss man sofort die Datenbank-Updates auf allen Websites durchführen. Das kann natürlich einige Zeit dauern, und so lange sind unter Umständen (bis zu n-1) Websites dieser Multisite-Installation zerbrochen. Und man muss darauf vertrauen, dass das Modul-Update keine der Websites "zerbricht" -- also gleich noch testen, was wiederum wieder viel Zeit beansprucht. Und wie geht man vor, wenn nun Eine der Multisites nach dem Update nicht mehr funktioniert? Viel Handbareit und eine erstmal zerbrochene Website bleiben zurück.

Seit rund 3 Jahren betreibe ich (fast) alle meine Drupal-Sites auf Webhostings, bei denen ich mich per ssh auf dem Server einloggen und die Websites administrieren kann. Bei den großen Anbietern bekommt man solch ein Hosting ab ~10 Euro je Monat. Alternativ dazu kann man sich für den Preis auch einen vServer klicken. Ich bin großer uberspace-Fanboy, dort bekommt man ein Webhosting mit ssh-Zugang (und sehr vielem mehr) für den Preis, den mit das Angebot wert ist. Ich folge mittlerweile der Empfehlung der Betreiber und habe für jede Website einen eigenen Uberspace (also ein eigenes Benutzerkonto auf einem der Uberspace-Server), weil auch die E-Mail-Konfiguration per Uberspace erfolgt und ich so jedem Kunden problemlos Ssh-Zugang zu "seinem" Uberspace geben kann.

Nun fragt Ihr vielleicht, wie viel mehr Zeit ich für ein so verteiltes Hosting investieren muss? Deshalb hier noch ein paar Ausführungen dazu. Ich bin bekanntermaßen begeistert von drush, dem Kommandozeilenwerkzeug für Drupal. Natürlich ist drushauf allen Uberspaces installiert. Ich pflege eine Vorlage für ~/.drush auf meinem lokalen Rechner und die wird -- zusammen mit weiteren Konfigurationsdateien -- in jeden neuen Uberspace kopiert. Aktualisierung des Setups ist auch schnell getan:

cd ~/uberspace_template   

for i in $(uberspaces)   

do

  echo "*** $i ***"

  rsync -var . $i:

done

Das $(uberspaces) habe ich kürzlich beschrieben.

Auf dem Uberspace kann ich nun mit drush schnell ein Backup der Website machen, Module aktualisieren und ein fälliges Update in Sekundenschnelle auf einer Kopie der produktiven Website testen.

drush rsync @live @test   

drush sql-sync @live @test

drush @test up views

# und nun Testen

drush @live bam-backup

drush @live up views

Details dazu und den obligatorischen Hinweis auf environment_indicator.module findet Ihr in dem frühren Blogbeitrag.

Um herauszufinden, welche meiner Drupal-Installationen von einem nötgen Update betroffen sind, läuft dieses Sktipt von meinem lokalen Rechner aus:

for i in $(uberspaces)

do

  echo "*** $i ***"

  ssh $i "find /var/www/virtual/$i -type f -name modulname.module"

done

Um es noch einfacher zu haben, habe ich alle Dateien aliases.drushrc.php vom Server auf meinen lokalen Rechner kopiert und den Namen des Uberspaces als Prefix vorangestellt

for i in $(uberspaces)

do

  echo "*** $i ***"

  scp $i:.drush/aliases.drushrc.php ~/.drush/$i.aliases.drushrc.php 

done

Dann noch die Paramater remote-hostund remote-user in den Aliases ergänzen und ich kann vom lokalen Rechner aus Drush-Kommandos auf dem Uberspace ausführen, ohne mich vorher dort anmelden zu müssen:

drush @uberspacename.live st

Das vergangene halbe Jahr seit meinem Umzug zu uberspace.de mit strengen Separation aller Websites auf eigene Benutzerkonten (Accounts) hat gezeigt, dass dieser Workflow robust ist und mit drush, git, komfortablem Backup auf Systemebene und all den anderen Helferlein keinen Mehraufwand gegenüber einem eigenen Server mit allen Websites unter /var/www bringt. Dafür aber Zuverlässigkeit der Plattform, schnell durchgeführte Drupal-Updates und einen freigestellten Linux-Admin.

Nun bin ich auf Deine Meinung gespannt. Wie administrierst Du Deine Drupal-Sites? Was für Hosting-Pakete favorisierst Du wie passt Dein Provider zu Dir? Und: Nutzt Du noch Multisites und ich habe irgend ein cooles Feature aus den Augen verloren?

Mit dieser Maßnahme schließe ich mich der Protestaktion gegen die US-amerikanischen und europäischen Zensurbestrebungen (SOPA und ACTA) an.

Weitere Informationen dazu findet Ihr im Windflüchter Blog, Spreeblick Blog, beim Digitalen Gesellschaft e.V. sowie den von dort verlinkten Ressourcen.

Beim Wahl der Hosting-Plattform war mir wichtig, dass die Teilnehmer nach dem Kurs wählen können, ob sie

• die Website weiter kostenlos betreiben ohne sich um Updates kümmern zu müssen,
• einen gewissen Jahresbeitrag bezahlen und dafür einen eigenen Domainnamen bekommen,
• die Website selbst hosten, um mehr Performance und Flexibilität bei der Modul- und Themeauswahl haben (und sich dafür mit der Drupal-Administration beschäftigen müssen).

Mittlerweile bin ich jedoch an dem Punkt angekommen, dass ich diese Kurse nicht weiterführen will. Ich hatte in den Kursen und mit den Menschen immer viel Spaß. Aber zu wenige von ihnen sind letztlich dabei geblieben – zu viele haben sich durch den Kurs gequält, viel Geld und Zeit investiert und trotzdem keine eigene Website. Ich erreiche also permanent mein persönliches Kurzziel nicht.

Ich bin mir dank des positiven Teilnehmerfeedbacks sicher, dass es (nach den vier Jahren) nicht primär an mir als Trainer liegt, den Stoff zu vermitteln. Den Teilnehmern fehlt jedoch neben dem Feierabend-Engagement (30 Abendstunden in ~2 Wochen) die Zeit, sich nochmal ~50 Stunden am heimischen PC an das Website-projekt zu setzen. Und ich habe festgestellt, dass Drupal 7 auch mit all den #d7ux-Erfolgen und Verbesserungen an der Bedienoberfläche zu kompliziert für Neueinsteiger ist.

Als Konsequenz könnte ich im Kurs auf WordPress wechseln, die ja auch ein kostenlose Hosting-Plattform anbieten, welches obigen Auswahlkriterien entspricht. Oder mit Jimdo eine kommerzielle Plattform mit Freemium-Preismodell nutzen. In beiden Fällen wäre es aber nicht mehr mein Kurs, ich will eben mit Drupal arbeiten. Die Option “Website-Baukasten-Software auf dem PC installieren und dann ins Intrnet speichern” kommt für mich gar nicht in Frage.

Im Moment denke ich also darüber nach, den Kurs nicht weiterzuführen. Ich habe noch ein paar Wochen Zeit mich zu entscheiden, aber habe (noch) keine gute Idee, wie ich meine persönlichen Erwartungen, die Leistungsfähigkeit der Teilnehmer und die verfügbaren Software-Alternativen zusammenbringen kann.

Ich habe mir ein kleines Script uberspaces geschrieben, welches mir aus meiner Ssh-Konfigurationsdatei ~/.ssh/config die Liste der Ssh-Host-IDs alle Uberspaces liefert, die ich dann in Shellkommandos nutzen kann. Die Ssh-Host-IDs sind dabei mit Leerzeichen voneinander getrennt.

Beispiel: Gib die Crontabs aller Uberspaces aus

for i in $(uberspaces)

do

  echo "*** $i ***"

  ssh $i "crontab -l"

done

Und noch ein Beispiel: Finde alle Drupal-Installationen in allen Uberspaces, in denen ein bestimmtes Drupal-Modul installiert ist. In diesem Fall -- aus aktuellem Anlass -- das date.module

for i in $(uberspaces)

do

  echo "*** $i ***"

  ssh $i "find /var/www/virtual/$i -type f -name date.module"

done

Einzige Voraussetzung ist, dass in der Datei ~/.ssh/config für jeden Uberspace ein solcher Eintrag vorhanden ist:

Host myuberspace

  Hostname servername.uberspace.de

  User myuberspace

Der UserName und der Host-Id müssen nicht übereinstimmen, ich habe diese Konvention gewählt. Weitere Konfigurationswerte zu einem Eintrag sollten nicht stören, sie werden einfach ignoriert.

Auf diese Weise kann man leicht der Empfehlung der Ubernauten folgen, und für jede Website einen eigenen Uberspace einrichten, ohne bei der Administration zusätzlich Zeit investieren zu müssen.