Beiträge von peterpw

Danke für den Tipp! Ich werde die Einstellungen überprüfen und dann berichten.

Hallo,

ich habe für meine Website ein Problem mit der Seiten Indexierung durch Google. Google behauptet, dass eine Datei doppelt vorhanden sei, ich sie nicht als kanonisch festgelegt habe und sie deshalb nicht indexiert werden könne. Diese Einstufung kann ich nicht nachvollziehen, weil sie wirklich nur einmal vorhanden ist.

Es handelt sich um die Datei, die mit folgendem Link aufgerufen wird:

Meine Schrift ist so groß, dass sie wichtige Elemente verdeckt – Apfel-Helfer

Die Informationen, die ich über die Google Search Console erhalte, geben mir keine Auskunft darüber, welches der doppelte Weg sein soll. Siehe Screenshot

Das Ganze ist insofern sehr ärgerlich, als ein Großteil der vorhandenen Seiten auch nicht mehr indexiert wird.

Ich habe die Index.xml Datei sowie den Menüpunkt mit Aimy Sitemap in der kostenlosen Version erstellt, da die Website weniger als 50 Seiten umfasst.

Ich bin ziemlich ratlos.

Wäre es eine Lösung, die Datei einfach umzubenennen?

Herzlichen Dank im Voraus

Peter Schütz

Hier die versprochenen Links:

URL der Website: https://apfel-helfer.de

URL der Seite, in der das oben beschriebene unerwünschte Phänomen auftritt: https://apfel-helfer.de/tipps/siri-einsteiger

Hinweis: Es wird nur auf einem iPhone oder iPad mit dem Browser Safari sichtbar.

Der Tipp mit garantiert nicht verwendeten Nummern ist gut. Das werde ich als Provisorium erst einmal umsetzen.
Eigentlich hast du mit deinem Hinweis auf die Fähigkeiten von blinden Menschen nicht unrecht. Aber dieser Beitrag richtet sich an Personen, die das erste Mal ein iPhone mit Siri bedienen wollen.

Ich hoffe, dass ich es am Wochenende schaffe, die Website freizuschalten. Ich werde die URL hier veröffentlichen, sobald dies erledigt ist.

Des ungeachtetet würde mich grundsätzlich interessieren, ob die Möglichkeit besteht, eigene Header Tags in eine ausgewählte Seite einer Website einzubinden. Deshalb lasse ich diesen Thread noch auf unerledigt stehen und hoffe, dass jemand eine Lösung dafür aufzeigen kann.

Vielen Dank. Aber dieser Vorschlag scheint mir nur bedingt brauchbar zu sein. Gerade für Personen, die sich den angezeigten Inhalt vorlesen lassen müssen, ist es wichtig, ein komplettes Beispiel eines solchen Befehls zu hören. Also in meinem Beispiel "Siri: Rufe 0152 123456789" . Auf jeden Fall muss gewährleistet sein, dass nicht unbeteiligte Dritte in irgendeiner Form durch Anrufe belästigt werden. Und das könnte der Fall sein, wenn jemand dann aus zum Beispiel aus um Kenntnis auf den Button mit der Telefonnummer klickt.

Gruß Peter

Hallo, ich möchte auf einer von mir betreuten Seite Anleitungen für Blinde und Sehbehinderte veröffentlichen. Dazu gehört auch ein Beispiel, wie man mit Siribefehlen auf einem iPhone ein Telefonat beginnen kann. Die Nummer ist natürlich eine Fantasie Nummer. Leider wird sie auf Apple Geräten beziehungsweise Apps als echte Nummer interpretiert und als Link markiert, so dass man sofort telefonieren könnte. Siehe Bildanhang. Das ist aber nicht gewünscht.

Meine Recherche im Internet haben ergeben, dass man das unterbinden kann, wenn bei der betreffenden Seite im Header folgende Zeile steht:

<meta name="format-detection" content="telephone=no">

Meine Frage: Gibt es irgendwo eine Stelle in der Bearbeitung eines Beitrages, einen Punkt, wo man eine entsprechende Vorgabe eintragen könnte? Oder Benötige ich dafür eine Erweiterung? Wenn ja, welche?

Vielen Dank im Voraus!

Peter

Danke für die Information. Werde ich wieder zurückstellen.

Peter

Leider habe ich das Thema in einer falschen Rubrik eröffnet. Kann ich das korrigieren? Aber wie? Oder müsste das ein Administrator tun?

Sorry Peter

Hallo, kürzlich habe ich das Update von Version 4 auf Version 5 eingespielt. Welche Einstellung ist jetzt für den Update-Server vorzunehmen?

Soll ich ihn auf "Joomla! Next" stehen lassen?

Oder kann ich ihn auf "Standard" zurückstellen?

Vielen Dank im Voraus.

Peter

Herzlichen Dank noch einmal für alle Beiträge

Gruß

Peter

Hallo,

Zitat von JoomlaWunder

Es scheint aber doch parallel zu Joomla zu liegen, welches in einem Unterverzeichnis liegt. Insofern ist das gar kein Problem.

Eigentlich nicht, wie es bei anderen Joomla-Installationen auch funktioniert, bzw. funktioniert hat.

Bezüglich der Versionsnummer:

Ich habe noch einmal nachgeschaut, es ist doch die Version 9.6.2 (2023-06-30). Sorry!!!

Durch Zufall habe ich die Ursache inzwischen selbst herausgefunden.

Eigentlich habe ich immer den Backup-Ordner nach folgendem System benannt, damit ich bei mehreren Projekten nichts verwechsle:

Installation: "Test1" Backup: "SIK-Test1".

Dieses System habe ich dieses Mal durchbrochen und für den Backup-Ordner den Namen "Test1-SIK" gewählt. Nachdem ich zum alten System zurückgekehrt bin und den Ordner entsprechend umbenannt habe, funktioniert alles einwandfrei.

Eigentlich könnte ich damit dieses Thema als erledigt markieren, aber es bleibt trotzdem rätselhaft, wie es zu diesem Phänomen kommt.

Wenn der Name des externen Backup-Ordners mit dem Namen des Ordners der Joomla-Installation beginnt, dann streikt Akeeba.

Geht es nur mir so, oder kann jemand dieses Phänomen bestätigen?

Eine Rückfrage an die Moderatoren bzw. Meister: Sollte ich dafür lieber einen neuen Thread erstellen? Dann würde ich dieses Thema als erledigt markieren.

Herzlichen Dank an alle, die hier versucht habe, eine Lösung zu finden.

Gruß

Peter

Und nun zu meinem eigentlichen Anliegen, den ich in einem separaten Post veröffentliche.

Wie aus der online Hilfe für das Output Directory hervorgeht (Siehe Anhang), bietet Akeeba drei Optionen an, die jeweils über unterschiedliche Makros ausgeführt werden:

[DEFAULT_OUTPUT]

Hier wird folgender Pfad eingetragen: /administrator/components/com_akeebabackup/backup

[SITEROOT]

Hier hat man die Wahl, einen anderen Ordner zu wählen, solange der sich innerhalb der jeweiligen Joomla-Installation befindet.

Diese beiden Optionen habe ich ausprobiert und sie funktionieren.

[ROOTPARENT]

Hier soll es möglich sein, das Backup in einem Ordner zu sichern, der außerhalb der Joomla-Installation liegt.

Damit deutlich wird, warum ich das möchte, hier ein paar Hintergrundinformationen.

Wenn ich eine neue Website einrichten oder auch nur etwas ausprobieren möchte, dann lege ich unterhalb meines Root-Verzeichnisses für den Account einen entsprechend benannten Ordner an, in dem ich dann Joomla installiere und die gewünschten Einstellungen und Einträge vornehme. Wenn ich dabei in eine Sackgasse gerade, möchte ich einen früheren funktionierenden Zustand mit Akeeba wiederherstellen. Da ich den betreffenden Ordner komplett leeren muss, ist es sinnvoll, von vornherein einen separaten Ordner zu haben, in dem die Back-ups gespeichert werden.

Ich stelle mir inzwischen die Frage, ob nicht das Makro, dass die URL für den Speicher Ort erstellt bzw. benutzt, fehlerhaft sein könnte.

Eine Log-Datei kann ich zur Fehlersuche nicht auswerten, weil sie nur dann erstellt wird, wenn das Back-up durchläuft.

Ich habe auch versucht eine relative Pfadeingabe manuell einzugeben (../mein Zielordner) Die wird vom System erst einmal gespeichert, aber dann bleibt der Prozess irgendwann stecken.

Ist die Pfadangabe, die Akeeba erzeugt, in irgendeinem Datenbankeintrag enthalten, die ich einmal auslesen könnte? (in diesem Revier kenne ich mich leider nicht so gut aus.)

Die Versions Nummer von Akeeba dürfte richtig sein, denn sie wurde mir vom Update System nach der Aktualisierung auf Joomla 4.3.3.angeboten.

So weit für heute.

Liebe Grüße

Vielen Dank für die vielen Antworten. Damit nichts verloren geht, werde ich in zwei Etappen antworten.

Hier zunächst zum Thema Akeeba. Den ersten Beitrag von joomdev habe ich als sehr aufdringliche Werbung wahrgenommen. Sein Vorschlag, auf ein professionelles Service System umzusteigen, war sicher nicht für mich bestimmt, sondern für die Leserschaft, die sich meine Anfrage anschaut. Dass er dann doch noch konkrete Hinweise zu meinem System gegeben hat, hat mich etwas versöhnt, weshalb ich in meiner ersten Reaktion darauf auch sehr vorsichtige Formulierungen benutzt habe.

Aber dennoch frage ich mich, ob er nicht zu mindestens in Teilen gegen die Foren Regeln für kommerzielle Anbieter verstoßen hat, auch wenn er sich in seinem letzten Beitrag bedeckt gehalten hat, inwieweit er zum kommerziellen Anbieter gehört oder nicht.

Mit Akeeba bin ich bisher sehr gut gefahren. Gerade bei der Entwicklung von Webseiten war es eine große Hilfe, wenn ich in einer Sackgasse gelandet bin. Mithilfe von Kick Start konnte ich problemlos und sehr schnell die letzte noch brauchbare Version wiederherstellen. So weit dazu.

Vielen Dank für die vielen Antworten. Inzwischen habe ich einiges ausprobiert. Hier meine Rückmeldungen dazu.

Der Support von all-inkl war auch ziemlich ratlos, hat aber bestätigt, dass die richtigen Dateirechte eingetragen sind. Hat angeregt, dass ich eine Subdomain für den Ordner mit der Joomla Installation einrichten möge. Habe ich gemacht, aber das Problem besteht immer noch.

Pro ist nicht notwendig, da es mit der anderen Joomla-Site auch in der Free-Version läuft.

Der Configuration Wizard hat auch nicht geholfen.

Die Werbetrommel von joomdev hat mich hier in diesem Forum doch etwas irritiert.

Die Umstellung auf PHP 8.1 habe ich bisher immer zurückgestellt, weil ich hier im Forum immer wieder gelesen habe, dass es noch Probleme geben könnte.

Ich habe auch ausgeschlossen, dass es irgendwie am Browser liegt, Ich habe es mit Safari, Firefox und Chrome versucht.

Hier zur genaueren Fehlersuche meine Schritte:

Ich habe in der Komponente Akeeba die Konfiguration eines weiteren Back-up Profils (SIK-Extern) geöffnet.

Dann habe ich den Directory Browser für das Feld "Output-Directory" geöffnet.

Habe mich dann über den Button <up one level> so weit in der Ordnerhierarchie hochgearbeitet, bis ich den von mir gewünschten Zielordner (sik-demo4) sehen konnte.

Den habe ich angeklickt , so dass er in der Pfadangabe zu sehen war.

Danach habe ich nacheinander die Buttons "Go" und "Use" angeklickt, so wie ich es in einer Anleitung gefunden hatte.

Danach war in Output-Directory der Wert "[ROOTPARENT]/demo4-sik" zu sehen. Dieser bleibt auch erhalten, wenn ich nur auf "Speichern" klicke
--> siehe Foto im Anhang

Wenn ich aber über Speichern und Schließen zurück zum Dashboard will, dann wird mir angezeigt, dass der Output-Ordner nicht beschreibbar sei.

Das einzige, was funktioniert, ist, wenn als Output-Directory der Wert [SITEROOT]/meinWunschordner eingetragen ist.

Falls keine andere Idee auftauchen sollte, hätte ich noch eine weitere Hypothese. Ich habe Joomla über das Angebot von All-Inkl zur Software-Installation eingerichtet. Vielleicht ist da etwa schief gelaufen. Das kann ich wohl aber nur herausfinden, wenn ich die komplette Installation selbst durchführe.

Aber ich gebe die Hoffnung noch nicht auf.

Peter

Hallo,

Ich habe im Rahmen einer Neuinstallation von Joomla versucht, für Akeeba einen Zielordner für die Backups auszuwählen, der außerhalb der Joomla-Installation liegt [ROOTPARENT]/meinWunschordner.

Das war aber nicht möglich, sondern ich erhalte die Fehlermeldung, dass der gewünschte Ordner nicht beschreibbar sei. Ich hatte den vorgesehenen Zielordner mit FileZilla eingerichtet und die Dateirechte auf 755 gesetzt. Aber selbst ein Ändern auf 777 brachte nicht das gewünschte Ergebnis.

Ursprünglich wurde als Ziel für das Backup der Standardpfad /administrator/components/com_akeebabackup/backup gespeichert.

Nach einige Versuchen habe ich es dann geschafft, das Backup auf einen anderen Ordner innerhalb der neuen Joomla-Installation einzurichten: [SITEROOT] /meinprovisorischerOrdner

Ich bin jetzt ratlos, weil bei anderen Joomla-Installationen , die ich beim selben Provider betreue, das problemlos funktioniert hat.

Hier die Daten zum System

Joomla 4.3.3.

Akeeba 9.6.3

Provider: all-inkl

PHP: 8.0.28

Datenbank: mysql 5.7.37

Vielen Dank im Voraus

Peter

Vielen Dank Elwood, ich hatte nur einen falschen Port gewählt.

Heute habe ich noch einmal alles durchprobiert und keine Fehlermeldung mehr registrieren können. Ich hoffe, dass es auch so bleibt. Deshalb werde ich diese Konversation auch auf erledigt setzen.

Dennoch bleibt für mich das grundsätzliche Problem, wie es zu dieser Fehlermeldung überhaupt kommen konnte. Im Moment sehe ich nur zwei Alternativen

• Es ist ein Bug von Joomla im Kontext der php Mail Funktion
• Irgendjemand hat es trotz aller Vorsichtsmaßnahmen meinerseits geschafft, diese Website so zu kompromittieren, dass ein solcher Fehler auftritt.

Wenn ich ein wenig mehr Zeit habe, werde ich noch einmal in den Logfiles stöbern, ob ich dort irgendwelche Hinweise finde.

Ggf. werde ich einen neue Thread eröffnen, damit geklärt werden kann, ob es sich um einen Joomla-Bug handelt.

Herzlichen Dank an alle, die mir geholfen haben.

Liebe Grüße

Peter

Zwischenbericht:

Das Ändern der htaccess Datei hat leider nicht geholfen, weil die von Dirk (WM-Loose) angebotene Fassung bei mir (aus welchen Gründen auch immer) nicht funktioniert.

Die vorhandene htaccess Datei habe ich mit der Anregung von Christine2 verbessert.

Dann habe ich versuchsweise einmal die Mail Funktion ganz ausgeschaltet. Und danach hatte ich keine Probleme mehr. Hoffentlich bleibt das so.

Der Versuch, eine einen Mail Versand per SMTP kriegen einzurichten, ist in den ersten Anläufen gescheitert. Wenn es dabei bleibt, würde ich eine neue Anfrage aufmachen.

Soweit für heute Abend

Vielen Dank für die bisherigen Rückmeldungen.

Liebe Grüße.

Peter

Zitat

Die Meldung bezieht sich aber auf deine SMTP-Mail Einstellungen.

Was wurde denn dort eingestellt?

In der Systemkonfiguration habe ich unter "Server" das Versenden von E-Mails per php-Mailer aktiviert.

(Ich setze die Erweiterung Mailster in der Version 1.7.8 für den Versand von Newslettern ein.)

Oder gibt es an anderer Stelle noch Eintragungen, die ich überprüfen müsste?

Der Eintrag in der configuration.php lautet: public $live_site = '';

Der Inhalt der htaccess-Datei

##
# @package    Joomla
# @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
# @license    GNU General Public License version 2 or later; see LICENSE.txt
##

##
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
#
# The line 'Options +FollowSymLinks' may cause problems with some server configurations.
# It is required for the use of Apache mod_rewrite, but it may have already been set by
# your server administrator in a way that disallows changing it in this .htaccess file.
# If using it causes your site to produce an error, comment it out (add # to the
# beginning of the line), reload your site in your browser and test your sef urls. If
# they work, then it has been set by your server administrator and you do not need to
# set it here.
##

## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes

## No directory listings
<IfModule mod_autoindex.c>
    IndexIgnore *
</IfModule>

## Suppress mime type detection in browsers for unknown types
<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
##
# Disable Federated Learning of Cohorts (FLoC)
# If you uncomment the below directive you have to allow this technology in the
# Global Configuration of Joomla. Read more about this in the Post-Installation
# message in the backend.
##
# Header always set Permissions-Policy "interest-cohort=()"
</IfModule>

## Protect against certain cross-origin requests. More information can be found here:
## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)
## https://web.dev/why-coop-coep/
#<IfModule mod_headers.c>
#    Header always set Cross-Origin-Resource-Policy "same-origin"
#    Header always set Cross-Origin-Embedder-Policy "require-corp"
#</IfModule>

## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag
<FilesMatch "\.svg$">
  <IfModule mod_headers.c>
    Header always set Content-Security-Policy "script-src 'none'"
  </IfModule>
</FilesMatch>

## These directives are only enabled if the Apache mod_rewrite module is enabled
<IfModule mod_rewrite.c>
    RewriteEngine On

    ## Begin - Rewrite rules to block out some common exploits.
    # If you experience problems on your site then comment out the operations listed
    # below by adding a # to the beginning of the line.
    # This attempts to block the most common type of exploit `attempts` on Joomla!
    #
    # Block any script trying to base64_encode data within the URL.
    RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
    # Block any script that includes a <script> tag in URL.
    RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
    # Block any script trying to set a PHP GLOBALS variable via URL.
    RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
    # Block any script trying to modify a _REQUEST variable via URL.
    RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
    # Return 403 Forbidden header and show the content of the root home page
    RewriteRule .* index.php [F]
    #
    ## End - Rewrite rules to block out some common exploits.

    ## Begin - Custom redirects
    #
    # If you need to redirect some pages, or set a canonical non-www to
    # www redirect (or vice versa), place that code here. Ensure those
    # redirects use the correct RewriteRule syntax and the [R=301,L] flags.
    #
    ## End - Custom redirects

    ##
    # Uncomment the following line if your webserver's URL
    # is not directly related to physical file paths.
    # Update Your Joomla! Directory (just / for root).
    ##

    # RewriteBase /

    ## Begin - Joomla! core SEF Section.
    #
    # PHP FastCGI fix for HTTP Authorization, required for the API application
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    # -- SEF URLs for the API application
    # If the requested path starts with /api, the file is not /api/index.php
    # and the request has not already been internally rewritten to the
    # api/index.php script
    RewriteCond %{REQUEST_URI} ^/api/
    RewriteCond %{REQUEST_URI} !^/api/index\.php
    # and the requested path and file doesn't directly match a physical file
    RewriteCond %{REQUEST_FILENAME} !-f
    # and the requested path and file doesn't directly match a physical folder
    RewriteCond %{REQUEST_FILENAME} !-d
    # internally rewrite the request to the /api/index.php script
    RewriteRule .* api/index.php [L]
    # -- SEF URLs for the public frontend application
    # If the requested path and file is not /index.php and the request
    # has not already been internally rewritten to the index.php script
    RewriteCond %{REQUEST_URI} !^/index\.php
    # and the requested path and file doesn't directly match a physical file
    RewriteCond %{REQUEST_FILENAME} !-f
    # and the requested path and file doesn't directly match a physical folder
    RewriteCond %{REQUEST_FILENAME} !-d
    # internally rewrite the request to the index.php script
    RewriteRule .* index.php [L]
    #
    ## End - Joomla! core SEF Section.
</IfModule>

## These directives are only enabled if the Apache mod_rewrite module is disabled
<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When Apache mod_rewrite is not available, we instruct a temporary redirect
        # of the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
##     directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,
##     then your server is already gzipping css and js files and you don't need this
##     block enabled in your .htaccess
<IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

    # Serve gzip compressed JS files if they exist
    # and the client accepts gzip.
    RewriteCond "%{HTTP:Accept-encoding}" "gzip"
    RewriteCond "%{REQUEST_FILENAME}\.gz" -s
    RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
    RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
        # Serve correct encoding type.
        Header append Content-Encoding gzip

        # Force proxies to cache gzipped &
        # non-gzipped css/js files separately.
        Header append Vary Accept-Encoding
    </FilesMatch>
</IfModule>

Hallo,

bei meiner zweisprachigen Website treten zwei Fehlermeldungen auf, die möglicherweise zusammenhängen. Leider treten diese Fehler nicht immer auf, sondern nur manchmal, was eine Analyse sehr schwierig macht.

1. Frontend: Beim Aufruf der Startseite kommt die Rückmeldung ”Die angeforderte Seite konnte nicht aufgefunden werden”, sowie weiter unten eine 2 mit dem Text „SMTP Error: data not accepted”.
2. Im Backend erhalte ich diesenText ebenfalls, manchmal schon beim Aufruf der Login-Seite oder wenn ich einen neuen bzw. geänderten Eintrag speichern und schließen will.

Die Ursache für das Frontend konnte ich schon eingrenzen. Beim Aufruf der URL https://amicale.info/ wurde bisher immer automatisch auf https://amicale.info/de/ bzw. https://amicale.info/fr/ umgeswitscht. Wenn der Fehler auftritt, ist jetzt nicht der Fall, es bleibt bei https://amicale.info/

Beim Backend konnte ich bisher keine Eingrenzung ermitteln. Meist hilft es, die Seite erneut aufzurufen, um weiter arbeiten zu können. Wenn das Phänomen nach der Bearbeitung eines Beitrags auftritt, dann sind die eingetragenen Änderungen verworfen und der Beitrag ist gesperrt.

Könnte es vielleicht an den Einstellungen der htaccess-Datei bezüglich rewrite liegen. Da kenne ich mich leider nocht genau aus.

Der Provider (all-inkl) sagt, dass es von seiner Seite keine Probleme geben dürfte.

Herzlichen Dank im Voraus

Peter