Posts by KB19

Quote from derneumann

wer ist denn Fisi?

fisi bzw. fisinger.de

Wartungsarbeiten, wenn ich am vServer Wartungsarbeiten durchführen möchte? Ich kann so nicht arbeiten!

maintenance.png

(War nur das ncLabs-SCP und nach einer Minute funktionierte es wieder.)

Quote from ASS

Bei meiner letzten Installation stand es schon da.

Ich installiere sonst nie Images, deshalb frage ich.

Quote from ASS

Wo siehst du etwas schlechtes darin?

Nirgends, alles gut.

Dieser Hinweis im SCP (unter Images) ist neu, oder?

Quote

Für aktuelle Versionen werden wir zukünftig nur noch Images mit UEFI anbieten. Bis dahin empfehlen wir weiterhin die Installation eines Image mit BIOS. Falls Sie zukünftig ein System mit BIOS verwenden möchten welches nicht angeboten wird, installieren Sie bitte die Distribution Ihrer Wahl manuell von DVD, wie in unserem Helpcenter beschrieben: Help Center

Ist das eigentlich normal, dass neue vServer in NUE eine IPv6 aus 2a0a:4cc0::/32 (bzw. eher 2a0a:4cc0::/40) bekommen?

Normalerweise ist für NUE doch 2a03:4000::/32 vorgesehen, oder? Das andere Subnetz kenne ich bisher wirklich ausschließlich von VIE. Lustigerweise ist das auch nur in ein /40-er unterteilt, bei NUE sind es üblicherweise feinere Unterteilungen in /48-er.

Das IPv6-Routing ist somit auch anders. Von meinem Standort aus geht es bei IPv6 eigentlich immer über RETN nach NUE. Bei diesem vServer läuft aber alles über Core-Backbone, auch bei IPv4.

DerRené rss2email? Aber da wird der ganze Inhalt des Beitrags mitgeschickt. Wobei man das ja sicher leicht patchen könnte…

[EDIT] Geht wahrscheinlich auch ohne Patch, siehe post-process Feature bei rss2email.

Quote from Skeletor

Gibt es hierzu nähere Information, was sich hier geändert hat?

Mir sind nur diese (mMn harmlosen) Umstrukturierungen im Firmengeflecht der Anexia bzw. netcup bekannt: https://forum.netcup.de/sonsti…A4ngste-thema/#post253530

Oder habe ich irgendwas verpasst?

Quote from Ungeheuer

Ich hatte jetzt testweise nach den Infos aus diesem Thread im config-Verzeichnis eine datadirectory.config.php mit folgendem Inhalt angelegt:

PHP

<?php

$CONFIG['datadirectory'] = realpath(nc.meine-domain.de/httpdocs/config/ . '/../../nextcloud_data');

Dies führt allerdings nicht zum Erfolg und bedeutet darüber hinaus, dass sich die nextcloud überhaupt nicht mehr erreichen lässt.

Das __dir__ ist eine magische Konstante, die kannst Du nicht einfach durch einen "String" (bzw. ohne Anführungszeichen eher eine nicht existierende Konstante) ersetzen. Gemeinsam mit realpath() und der relativen Pfadangabe soll daraus ein absoluter Pfad gebildet werden.

Probiere es einmal so, das sollte zu Deiner Beschreibung passen:

<?php

$CONFIG['datadirectory'] = realpath(__dir__ . '/../../nextcloud_data');

Genau so, nichts ersetzen!

[EDIT] Den open_basedir musst Du in Plesk bei der betroffenen Domain (!) dann trotzdem auf die Einstellung mit WEBSPACEROOT abändern, der nextcloud_data Ordner liegt ja außerhalb Deines DOCUMENT_ROOT.

Falls es dann noch immer nicht klappt, würde ich einmal einen Blick ins Errorlog des Webservers bzw. von PHP werfen. Das siehst Du entweder direkt in Plesk oder auch über (S)FTP(S), in welchem Ordner weiß ich aber gerade nicht auswendig.

Quote from Ungeheuer

Mein nextcloud-Datenordner (nextcloud_data) liegt auf derselben Ebene wie der httpdocs […]

Also wahrscheinlich außerhalb des open_basedir? Welche Einstellung hast Du denn dafür aktuell in Plesk ausgewählt?

Und hast Du die Konfigurationsanpassung aus diesem Thread (siehe Beitrag #2) gesetzt? Wie sieht die genau bei Dir aus?

Quote from ASS

Wie geht denn sowas?

Handcodiert?

Mist, jetzt ist es aufgeflogen. Das war doch nur für Verlosungen im Biete-Forum gedacht

aRaphael Von mir ist das Zitat trotzdem nicht

Das wirklich Nervende ist, dass bei viel mehr Domains MS als MX agiert, als man es vermuten würde. (Office 365 mit eigener Domain.)

Und dabei wird genauso fröhlich gewürfelt, was blockiert wird…

Seit Dezember habe ich keine Lust mehr auf den Kontakt mit dem Postmaster Support von Microsoft. Dazwischen funktionierte dort sogar das ganze Formular mehrere Tage nicht mehr ("HTTP 503"), was ein weiterer Anreiz war, es bleiben zu lassen.

Was jedenfalls lustig daran ist: Der Mailversand zu MS funktionierte dann einige Tage später von alleine wieder. Und einige Tage später wieder kurz nicht, was aber nur vorübergehend war.

Aber wenn sich das sowieso von alleine behebt, kann man sich den Stress mit denen manchmal auch sparen? Oft braucht es 5+ Mails, bis nach einigen Tagen etwas passiert. Oft passiert trotzdem nichts, weil sie auch nach der fünften Mail keine Probleme finden. Das Resultat, wenn man gar nichts macht, scheint jedenfalls ziemlich ähnlich zu sein.

(Es könnte natürlich sein, dass dazwischen netcup für das ganze Subnetz interveniert und es deshalb wie von Zauberhand über meine IPv4 wieder funktioniert.)

CCP » SOGo Groupware » Lupensymbol beim gewünschten Paket » E-Mail-Postfächer » Schlüsselsymbol beim gewünschten Postfach

Bei den Wartungsarbeiten wurde 2024 die Abschaltung angekündigt:

Quote

Das Webstatistik-Tool "Webalizer" steht nach dem Upgrade nicht mehr zur Verfügung.

Das stand damals jedenfalls in zwei E-Mails für unterschiedliche Webhosting Pakete.

z.B. den RS Vincent van Bot (Community Event Spezialprodukt) gab es vereinzelt auch in Wien.

Und ein paar VPS 200 G10s sollen Gerüchten zufolge fälschlicherweise in Wien ausgeliefert worden sein.

Ich wünsche allen Forenusern sowie dem ganzen netcup/Anexia Team schon einmal einen guten Rutsch ins neue Jahr!

Auch das Rescue-System ist über SSH auf Port 22 erreichbar. Es dauert aber 1-2 Minuten, bis es nach dem Generieren der Hostkeys erreichbar ist.

Falls SSH auch nach 5 Minuten noch nicht funktioniert, solltest Du über VNC einmal nachsehen, ob der Dienst überhaupt läuft und ob eine IPv4-Adresse konfiguriert ist.

Quote from philw95

Nur zur Info die Firewall im SCP greift beim VLAN nicht.

Eh nicht, aber bei Paketen auf der öffentlichen Schnittstelle, die z.B. eine RFC1918 Adresse als Destination haben.

Quote from Zierleiste

[…] IP-Spoofing […]

Die eigene Source-Adresse muss der Absender nicht unbedingt fälschen, das kann ruhig eine öffentliche IPv4-Adresse sein, die ihm regulär zugewiesen ist. Unerwünschte Pakete mit RFC1918-Adressen als Destination trudeln hier auf der öffentlichen Schnittstelle jedenfalls massenhaft ein...

Bei den Antwortpaketen würde ich mich dann auch nicht darauf verlassen, womit die wirklich rausgehen. Besonders wenn ein NAT im Spiel ist. (Docker & Co. lassen grüßen.)

Quote from SiebenG

Habe gerade eine SSD aussortiert mit 74872 Power_On_Hours. Nicht, weil kaputt, sondern wegen Wechsel auf neue Hardware.

Wenn es eine HDD wäre, wäre ich beeindruckter, obwohl das auch vorkommt. Aber bei einer SSD?

Viel interessanter würde ich jetzt finden, wie viel TB bereits geschrieben wurden und mit welcher TBW die beworben wurde.