Zockertown: Nerten News

Es geistern mehrere Lösungen rum, die netdata mit basic auth und nginx abzusichern.

Es geht aber auch mit einer reinen Apache Lösung, die auch in der Doku von netdata beschrieben ist.

Hier meine Gedächtnisstütze.

ich verwende ISPconfig, entsprechend sind hier die notwendigen Einträge bei der Website in der Config.

Apache Direktiven:

  RewriteEngine on
  RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]

    
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    

    
        Require all granted
    

    # Local Netdata server accessed with '/netdata/', at localhost:19999
    ProxyPass "/netdata/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
    #ProxyPass "/netdata/" "unix:/var/run/netdata/netdata.sock|http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on


If
    ProxyPassReverse "/" "http://localhost:19999/"
    # if the user did not give the trailing /, add it
    # for HTTP (if the virtualhost is HTTP, use this)
    RewriteRule ^/netdata$ http://%{HTTP_HOST}/netdata/ [L,R=301]
    # for HTTPS (if the virtualhost is HTTPS, use this)
    #RewriteRule ^/netdata$ https://%{HTTP_HOST}/netdata/ [L,R=301]
    # add a  section
    
        AuthType Basic
        AuthName "Protected site"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
        Order deny,allow
        Allow from all
    

Damit ist Let's Encrypt frei Haus, da die Hauptdomain bereits ssl enabled ist.

Jetzt nicht vergessen, mit

htpasswd -c /etc/apache2/.htpasswd monitoruser

einen user für die "basic auth" anzulegen.

und dann kann in   /etc/netdata/netdata.conf bind auf localhost gestellt werden.

Ich bin Fritzbox Nutzer, ich verwende den integrierten DNS Server, (genauer wohl ein resolver Cache)

Da ich auch einige Domain mit DNS Robot von Hetzner betreue, kommt es nach IP Änderungeen dort zu merkwürdigen Seiteneffekten.

Wenn es Unterschiede in der DNS Auflösung  zwischen dig, host und ping gibt, könnte es daran liegen, das in der FB ein Cache benutzt wird, den ping abfragt.

Die Lösung könnte sein, dass man einmal den DHCP-Server deaktivieren und gleich wieder aktivieren muß.

Das hier ist keine Anleitung, sondern dient mir als Stütze, was ich gemacht habe.

Gmail möchte verstärkt die absendenen Mailserveradmins dazu bewegen, SPF zu verwenden. Andere große eMail Provider übrigens auch. Es kommt vereinzelnt zu solchen Einträgen im mail.log

said: 421-4.7.0 This message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best protect our users from spam, the 421-4.7.0 message has been blocked. Please visit 421-4.7.0  https://support.google.com/mail/answer/81126#authentication for more 421 4.7.0 information. e15-20nmnmnmxmxmnmn.517 - gsmtp (in reply to end of DATA command))

Eine sehr gute Erklärung ist hier bei it-zeugs.de zu finden.  Hier auch: blog.k-webs.ch 

Deshalb erspare ich mir eine Wiederholung.

Es gibt auch Kritik an SPF. Schön auf den Punkt gebracht hat es meiner Meinung nach  tec-bite.ch/warum-mag-google-meine-mails-nicht/

Links:

Einen gesetzen SPF TXT Record kann man hier  testen.

appmaildev.com/en/spf 

spf-record.de/spf-lookup/

www.kitterman.com/spf/validate.html

https://www.mailhardener.com/tools/spf-validator

mxtoolbox.com/SuperTool.aspx?action=spf

Oder zu Fuß:

Eine email per roundcube oder imap Mailclient an eine eigene  gmail.com Adresse senden.

Die empfangene email unter "mehr", im Original anzeigen. Dort die SPF Einträge untersuchen.

Oder auch so: 

dig -t txt zockertown.de +short
"v=spf1 +a +mx +ip4:xx.yy.zz +ip4:xx.rr.ff.fe -all"

Hinweis:

Unterschied -all und ~all

~all ist die entschärfte Variante

Sollte man die Einträge nicht mit einem Webtool o.ä. machen, sondern auf der Console, bitte daran denken, dass die Serial hochgezählt wird, es gibt sonst evtl. unschöne Nebeneffekte, wie ich erleben durfte.

Wenn man Softraid verwendet, sollte einem klar sein, dass da eine monatliche Prüfung die Daten im Monitoring versaut.

Zum Unterschied von collectd und netdata hier ein Beispiel.

Ausgangssituation: In beide Tools wird auffallend hoher Load angezeigt, die Ursache liegt aber nicht an wild gewordenen Prozessen, eingeschleppte Schädlinge, sondern lediglich am 4 Wöchentlichen Rebuild des Raid1. Man muss halt nur wissen, welche Grafiken einem das verraten.

cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb2[1] sda2[2]
      2929609152 blocks super 1.2 [2/2] [UU]
      [==============>......]  check = 70.0% (2050771840/2929609152) finish=222.2min speed=65892K/sec
      bitmap: 5/22 pages [20KB], 65536KB chunk

md0 : active raid1 sdb1[1] sda1[2]
      523712 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Hier sieht man es auch sehr schön. Na klar, sda zeigt es genauso

Siehe auch http://zockertown.de/s9y/index.php?/archives/1630-Den-UEberblick-behalten-collectd-update.html

Hier noch das Ende. Leider kann man nicht minutengenau die Start und Ende Punkte erkennen. Aber das ist jammern auf hohem Niveau. Allerdings ist es bei netdata einfacher den Zeitpunkt zu erfassen.

Vor ein paar Wochen hatte ich einen langsam steigenden Load auf dem Server entdeckt.

Was auffiel, war ein schlechtes Antwortverhalten verschiedener CMS Systeme.

Scheinbar besonders betroffen waren Sites mit relativ vielen Redirects.

Es hat eine Weile gedauert, bis ich den Übeltäter fand.

Die inotify Log-Datei war riesige 27GB groß!

Da die Partition voll lief, hat mich mein Monitoring freundlich darauf hingewiesen und ein ncdu -x / hat mir den Übeltäter offenbart.

Sobald die Logdatei gelöscht war, lief alles wieder mit voller Geschwindigkeit.  Maldet und inotify war nicht in den Log-Rotationsprozess eingebunden, also habe ich dies getan, um die inotify Logdatei rotieren zu lassen.

Dazu habe ich den  Vorschlag verwendet. War zu faul mir selbst etwas auszudenken

Auch  Load ist wieder Prima.

Auf unserem Server werkelt ein postfix / Dovecot Gespann.

Die Konfiguration von Postfix ist über Jahre immer verfeinert worden.

Seit ein paar Jahren hatte ich ein zusammen gezimmertes Script, welches mir eine Übersicht über diese Thematik lieferte.

Häßlich, aber funktionell.

Gestern habe ich mich hingesetzt und das Script überarbeitet. Weg von einer notdürftigen Grafik und hin zu einer dedizierten Seite, die mehr Informationen bietet.

Nicht mehr ganz so häßlich und informativer.

Meine Spam Blocklisten sind:

http://rootgemeinschaft.de/geblockter-spam.html

Wenn jemand Interesse an dem Script hat, bitte melden, ich kann es auch hier im Blog zum Download bereit stellen.

Update: http://zockertown.de/s9y/index.php?serendipity[subpage]=downloadmanager&thiscat=7&file=62

Das Script muss etwas an die eigenen Verhältnisse angepasst werden. (Pfad zur Target Html Datei)

(Das Script ist ein Vorläufer.)

Notiz für mich.

Let's encrypt stellt ja auch Wildcard Zertifikate aus. D.h. für rootgemeinschaft.de; www.rootgemeinschaft.de; smtp.rootgemeinschaft.de usw. gibt es nur ein Zertifikat, das vermeidet Meckern vom Browser und Mail Client.

Derzeit stelle ich die Domains Zug um Zug auf Wildcard Domains manuell um.

Nebenbei funktioniert die automatische Verlängerung nicht mehr, weil das ACME Protokoll V1 nicht mehr akzeptiert wird.

Meine Versuche, das zu lösen waren bisher nicht erfolgreich.

Update: Der Schlüssel zu einem neuen Script für das Renew ist wohl hier:

https://community.hetzner.com/tutorials/letsencrypt-dns

Wenn ich hier wieder auf Reihe bin, werde ich das umsetzen. 

Egal, hier die notwendigen Schritte zu Ersterstellung von Wildcard Zertifikaten und was zusätzlich nötig sein könnte.

certbot certonly --manual -d *.rootgemeinschaft.de -d rootgemeinschaft.de --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Man wird dann aufgefordert, einen TXT Eintrag in der DNS Zone einzutragen: _acme-challenge.rootgemeinschaft.de Value="FgHjU89_asdvFetrxBlaFasely"

Der Eintrag im DNS Robot bei Hetzner für die Domain rootgemeinschaft.de muss dann so lauten​​:

Also ohne .rootgemeinschaft.de, das wird automatisch ergänzt, da hatte ich ein Verständnisproblem.

Als TTL nehme ich 60s und warte, bis ich in einem zweiten Terminal Fenster den eingetragenen TXT Record auch finde.

root@rootgemeinschaft ~ # dig -t txt _acme-challenge.rootgemeinschaft.de +short
"FgHjU89_asdvFetrxBlaFasely"

Jetzt kann man Enter drücken und hoffen, das alles klappt.

Falls es sich wie hier um den Mailserver handelt muss auch der Dienst neugestartet werden, sonst wird das neue Zertifikat nicht angezogen.

service postfix restart
service dovecot restart

Oder eben der Webserver.

Danach muss certbot ohne parameter aufgerufem werden, Option 1

Experimentell habe ich heute (22.7.2020) auch mal die Hetzner API ausprobiert. Scheint gut zu laufen, ist aber sehr langsam, aber scheinbar habe ich jetzt den Kanackpunkt gefunden, warum bei mir das Auto Renew mit den Wildcard Domains nicht klappte.

Wenn ich sicher bin, dass es läuft, ergänze ich es hier.

Ergänzung: openssl x509 -dates -noout </etc/letsencrypt/live/rootgemeinschaft.de/fullchain.pem

Ergibt das Expiredate, ich muß noch ein Script machen, dass dovecot durchstartet, wenn ein neues Cert vorhanden ist

Eigentlich nimmt man heutzutage GIT.

Ich nicht, da ich auch nur meine eigenen Spielereien etwas sichern und den Überblick behalten möchte, verwende ich CVS.

Braucht keiner nachmachen, ich schreibs halt hier mal auf, damit ich es wiederfinde, wie ich es aufgesetzt habe.

Schönere Anleitungen gibt es im Netz, hier die Variante, die bei mir werkelt.

Mein Repository liegt auf dem Rootserver.

CVSROOT=/var/CVS

Zugriff kann lokal oder über ssh erfolgen.

Dafür habe ich

export CVSROOT=:extssh:IP-adresse:/var/CVS

in der .bashrc des Client.

Damit das Ganze funktioniert muss der lokale user auch auf dem Server existieren und den sshkey im authorized_key hinterlegt haben.

Jetzt kann auf dem Client z.B. ein Verzeichnis importiert werden.

cvs import Elektronik bed start

Elektronik ist der Ordner Name und bed ist der user.

Selbstredend sollte der Ordner Elektronik frei von unnötigem Zeug sein, sonst wird das auch versioninert. Einige wenige Dateien werden allerdings auch per default ignoriert.

Es öffnet sich nano und fragt nach einem Kommentar. Mit -m "bla fasel" könnte man das umgehen, mache ich gewöhnlich aber nicht.

Jetzt sollte eine Liste von "N Dateinamen" erscheinen, damit ist das importieren erfolgreich.

Danach kann man mit cvs co Elektronik das Verzeichnis ausschecken und so zum bearbeiten vorbereiten.

Ps: Nicht vergessen, 

 /var/CVS 

mit im Backup Script aufzunehmen.

Keywörter: "$Revision$", "$Date$" und "$Log$" 

Nützliche Seite, um die Erinnerung an die Syntax aufzufrischen:

https://gki.informatik.uni-freiburg.de/lehre/ss03/sopra/cvs.html#REVISIONSNUMMERN

Vor einiger Zeit habe ich den Verursacher von erhöhter Prozessorlast gesucht. Mangels detailierter Monitoring Graphen war ich da leider etwas behindert bei der Suche. Schliesslich hatte ich es dann doch gefunden, es war der 4 Wöchentliche Softraid Check, den ich gar nicht mehr auf dem Schirm hatte.

Das war der Anlaß das Monitoring etwas aufzubohren.

Collectd bietet das Plugin Processes.

Das lässt sich individuell für seine eigene Zwecke anpassen.

Ich habe folgende Konfiguration gemacht:

<Plugin "processes">
ProcessMatch pg_autovacuum "postgres:.*autovacuum"
# Ergänzung um typische Verdächtige, wenn Proccess Count zu hoch ist
ProcessMatch webuser "web???"
ProcessMatch webcgi "php.cgi"
ProcessMatch vmail "dovecot"
</Plugin>

Die Idee dabei ist, dass man diese Prozessgruppen detailiert beobachten kann und nicht nur die normale Gesamtprozess Graphen.

Heute habe ich in meinem Imap Postfach aufgeräumt und diverse Archiv Ordner verschoben und indiziert. (Innerhalb von Thunderbird)

So sah das in der Graphik, aus man erkennt deutlich, in welchem Zeitraum das indizieren stattfand.

Das macht Hoffnung, für spätere Ernstfälle

Update 13.03.2020:

Mit den Notifications bin ich nun ein Stück weitergekommen.

Hier ein Ausschnitt aus der threshold.conf:

<Plugin "processes-vmail">
    <Type "ps_count">
        Instance "processes"
        Percentage false
        Hits 4
        WarningMax 4
    </Type>
    <Type "ps_rss">
        Percentage false
        Hits 4
        WarningMax 550000000
    </Type>

#   ps_cputime. Ohne Angabe einer Instance gilt WarningMax für jeden
    <Type "ps_cputime">
        Percentage false
        Hits 4
        WarningMax 25000
    </Type>
</Plugin>

Ach, bevor ichs vergesse, während des experimentierens mit den Werten fand ich AutoRefresh auf den Detail Seiten ganz praktisch.

# In detail.php nach Header() ein Echo und gut.

header("Content-Type: text/html");
echo '<meta http-equiv="refresh" content="30"/>';

Ab- und zu mal einen Blick auf die lang dauernden SQL Queries gucken, macht Sinn

In /etc/mysql/mariadb.conf.d/50-server.cnf

Müssen entsprechende Einträge existieren:

# Enable the slow query log to see queries with especially long duration
slow_query_log
slow_query_log_file     = /var/log/mysql/mariadb-slow.log

Bei mir fehlte slow_query_log. Die Angabe des Logfiles allein reicht nicht.

slow_query_log also einfach hinzugefügt, die Datenbank gestartet und schon kanns losgehen.

Momentan ist es allerdings leer 

In MariaDB 10.2 und später ist das DYNAMIC-Zellenformat das Standardzellenformat. Wenn die Tabellen ursprünglich auf z.B. Compact stehen, kommt es zu Fehlermeldungen im mysql error.log.

[Warning] InnoDB: Cannot add field `basic_auth_password` in table `xxowncloud`.`oc_news_feeds` because after adding it, the row size is 8269 which is greater than maximum allowed size (8126) for a record on index leaf page.

Mit dem folgenden SQL Statement : (irgendwo im Netz gefunden)

SELECT NAME, ROW_FORMAT

FROM information_schema.INNODB_SYS_TABLES

WHERE ROW_FORMAT IN('Redundant', 'Compact')

AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

Gibt man eine Liste der Tabellen, die nicht auf DYNAMIC stehen, aus.

Ein Beispielauszug.

| xxowncloud/oc_properties                                        | Compact    |
| xxowncloud/oc_schedulingobjects                                 | Compact    |
| xxowncloud/oc_share                                             | Compact    |
| xxowncloud/oc_share_external                                    | Compact    |

Da es bei mir mehr als 1000 Zeilen waren, habe ich mit etwas einzeiler Script Magie (Dirty, hat aber geklappt) ein SQL Script generiert, um die Tabellen zu ändern.

Das Ergebnis des oberen SQL Kommandos in eine Datei als repair-inno.sql gespeichert.

Dann mit dem Einzeiler:

​cat repair-inno.sql |awk '{ printf "ALTER TABLE `%s`  ROW_FORMAT=DYNAMIC;\n",$2 }'|sed s'/\//\`.`/g'>innodb2dynamic.sql

die Datei in das hier gewandelt:

ALTER TABLE `xxowncloud`.`oc_properties`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_schedulingobjects`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share_external`  ROW_FORMAT=DYNAMIC;

und mit mysql -u root -p ausgeführt.

Hat etwas gedauert, aber nun sind alle Tabellen geändert, wie ein erneuter Select Befehl zeigt.

Nun ist Ruhe im Error Log

Letzter Selbsttest:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     58160         1050014
# 2  Extended offline    Completed without error       00%     55855         -

Weil die Platte auch älter als 6,5 Jahre ist, habe ich Hetzner angeschrieben.. Das Ergebnis (innerhalb einer halben Stunde)

​wie gewünscht haben wir die defekte Festplatte mit der S/N: xxxxx für Sie ausgetauscht.
Leider haben wir momentan keine 3 TB Enterprise HDDs mehr im Lager,
daher haben Sie von uns eine 4 TB Enterprise HDD bekommen.

Ist ja ok, natürlich eine gebrauchte aus dem Pool.

Als ich nach wenigen Minuten nach dem Einbau der Platte die Partitionierung durchführte und gerade dem Raid wieder die neuen Partionen hinzufügen wollte, stand der Server.

Es half nur ein manueller Hardware Reset, der bei Hetzner nach wenigen Minuten durchgeführt wurde.

Ursache war

wie gewünscht haben wir Ihren Server überprüft, es schien wohl ein Problem mit der neuen HDD 
im Zusammenspiel mit der alten BIOS-Version auf dem Server zu bestehen.

Wir haben die BIOS-Version auf die aktuellste von uns geprüfte und freigegebene Version 
aktualisiert und den Server ins installierte System starten lassen.

Tja so ist das eben. Naja, Downtime unter 30 Minuten, das Raid synct natürlich noch...

Heute wurde der Server von Stretch auf Buster angehoben.

Caveats:

Bei Dovecot hat sich eine Sache in der dovecot.conf Syntax geändert.

Gut beschrieben ist es hier: https://b4d.sablun.org/blog/2019-02-25-dovecot_2.3_upgrade_on_debian/

Weil ich ispconfig benutze, wurde das auch gleich upgegradet auf 3.1.15p2.

Dabei festgestellt, dass ich noch die diversen php7.3 pakete nachinstallieren musste.

Ich habe auch confluence laufen, also Java und tomcat gedöns. Deshalb ist postgres installiert, welches ein 

postgres reindexdb --all

benötigt. (Man wird aber darauf hingewiesen)

Mal sehen, was es noch für Probleme gibt ...

Wegen eines leicht erhöhten Load hat mich nagios informiert. Was macht man da als Admin? Klar, mal gucken, was das denn schon wieder sein könnte....

Ich habe in einem Joomla Web auf meinem Server einen fiesen Burschen eingefangen, der andere Server  angreift.

   21936     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21938     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21940     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21942     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21944     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21946     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21948     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21950     1  3 17:13 ?        00:00:05 /usr/bin/perl ./jcache domain.de
   21952     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
... insgesamt 18 Prozesse ...

 Das habe ich durch mitlesen der Prozesse durch strace -p Beobachtung herausgefunden.

Abschalten ist kein Problem, es kommt aus dem Joomla.

Wenn ich das Web kurz aktiviere werden die Perl Prozesse innerhalb kurzer (unterschiedlichen Zeiträumen im 1-2 stelligen Minutenbereich) wieder gestartet.

Das Problem ist, dass ich keine manipulierte Datei oder extra Datei im betreffenden Web finden kann. Klar, ich werde ein Backup einspielen, nur ist es schon eigenartig, dass ich keine Spuren finde. Eine Möglichkeit wäre ja, das an der Datei der Datumsstempel manipuliert worden ist. maldet findet auch nichts.

Es wäre gut zu wissen, was ich mir da eingefangen habe. Nach den straces jedenfalls etwas fortgeschrittenes, es liest meine /etc/hosts /etc/resolv.conf und /etc/ssl/certs/ca-certificates.crt aus und greift verschiedene Server auf Port 80 und 443 an um nach Lücken in Wordpress Installationen zu finden.

Allerdings macht mich ein Fund in meinen Traces mißtrauisch .

/var/www/clients/clientN/webMMM/tmp/phpSM2Np7  (deleted);

Möglicherweise wird, nachdem das Script gestart wurde, die Datei auch gleich wieder gelöscht?!

Um den auf die Spur zu kommen, habe ich nun ein kleines Script gebastelt, um das eingespielte Backup zu überwachen, denn das heutige erneute aktivieren des Webs führte nicht zum erneuten aufflammen des jcache Wahnsinns ...

cat ueberwache.sh 
while true; do
    inotifywait -m -e modify,create,delete,move --timefmt '%Y-%m-%d_%H:%M:%S' --format '%T %w %:e %f'  -r /var/www/clients/clientN/webMMM/web >>/root/ueberwachung-webMMM-neu.log

done

Also wirklich dirty Scripting, das könnte man natürlich besser gestalten.

Gestartet habe ich das script mit nohup ./ueberwache.sh&

Danach wurde das zurücksetzte Web dem "Kunden" (Kumpel) übergeben und ich konnte die Funktion schön überprüfen, weil jetzt erstmal alle Addons/Plugins upgedatet bzw deinstalliert wurden.

Ausschnitt:

2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR 
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/imagehandler/ DELETE:ISDIR tmpl
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR imagehandler

Nun ist der erste Tag vorbei und kein erneuter Angriff.

das inotifywait tut aber nicht weh, ich lasse es jetzt einfach mal laufen, wenn dann wieder das, oder was anderes unterwegs ist hilft die Dokumentation und das Log hoffentlich.