Das liest sich für mich, als ob es ein sehr hilfreiches Feature wäre, wenn Kunden im Webhosting das IP-basierte Logging einfach komplett deaktivieren könnten ...
Nein, bloß nicht. Ich möchte mich im Fall der Fälle ja auch verteidigen können.
Einfach so antworten, wie NaN in #11 dargelegt hat.
Liebe [netcup] Christina R., ich danke Dir für deine Moderation und den Support im Forum.
Ich wünsche Dir alles Gute in deinem nächsten Job.
Mach's gut und vor allem hab' viel Spaß!
durch den unverschlüsselten key gewinne ich ja bequemlichkeit.
soetwas würde ich niemals weglassen und auf meinen ssh-servern ist eh' nur key-login erlaubt.
eventuell auch die des übergeordneten Ordners.
Was meinst du mit übergeordnet. Der übergeordnete zu tmp ist hier ja / mit 710 und owner hostingXXX:psaserv
Wenn man Stripe Glauben schenkt, dann sind nach den Gesetzen der Logik alle abgelehnten Kunden keine "legitime Kundschaft". Immerhin heißt es dort
Link-blabla…
Durch Radar wird i.d.R. die Kartenakzeptanz bei Zahlungsvorgängen erhöht, und nicht vermehrt abgelehnt, weil man gerade die üblich auftretenden Grenzfälle besser erkennt. Im Prinzip basiert das auf 3DSecureV2 und läßt irgendwas mit KI über die anfallenden Daten laufen. Wir haben bisher jedenfalls positive Erfahrungen mit Stripe als Zahlungsanbieter gemacht.
Bist du sicher, dass du der Besitzer bist?
/tmp ist ja typischerweise root-owned und ge-stickybit-et.
Nur zur Sicherheit sind eventuelle Fallstricke noch zu beachten:
1. /backup vom Backup ausschließen.
2. Platzbedarf der Backup(s) beachten, besonders wenn man beide * (plesk-internes und ftp-wcp-lokales) Backup-Ziele aktiviert.
* [Backups wachsen dann evtl. fast quadratisch und man schiesst sich schneller ab, als man sich mit 2FA einloggen kann]
Man kann die Backups auch via ftp auf 127.0.0.2 ins wcp-filesystem ( z.b. /backup) schreiben lassen und dann von aussen pullen.
Das wurde hier im Forum auch schon bezgl. der plesk-1gb-backup-size-problematik besprochen.
Jaaa, das gute, alte Gästebuch…
ja das passt.
du kannst an den enden … \; durch … + ersetzen, dann passiert der -exec … jeweils in einem rutsch.
und mit … chmod -v … siehst du sämtliche änderungen.
wer's loggen will, hängt noch jeweils ein | tee -a chmod.log an's ende der find's.
find und chmod sind verfügbar – man kann die Rechte also auf zwei Rutschs anpassen.
Naja wie es aussieht fehlten bei stripe für den Prozess wichtige/richtige Stammdaten.
Nix naja. Wo sollen denn da Stammdaten fehlen. Es geht um ID-Überprüfung bei Neukunden und wenn es für Stripe nicht koscher aussieht, weil es einer wiedermal schafft, zwei verschiedene Adressen anzugeben, dann wird eben abgelehnt (ganze Liederbücher könnte man damit füllen).
Netcup bekommt ja nur die Info, ob die Überprüfung mit bestimmten Merkmalen erfolgreich war oder nicht.
AFAIR war das hier schonmal ein Thema und lag am ausgehenden Spamcheck.
Am Lustigsten finde ich gerade, wie sich das Problem aus Post #6 hier im selben Thread, selbst auf Wiedervorlage gesetzt hat. 
Aber wofür ist diese Auswahlmöglichkeit gut?
Es ist halt im Plesk, was normalerweise auch DNS verwalten und dann auch Wildcards ordentlich behandeln kann.
Aber eben nicht hier bei uns. 
Wobei im Wiki ja explizit und deutlich auf die Wildcardbesonderheit hingewiesen wird.
https://helpcenter.netcup.com/de/wiki/webhosting/ssl-verschluesselung-webhosting
der download ist nur für dich und wird bald gelöscht, weil es eine alte (noch dazu '…pre') version ist.
ich hatte nur gestern nix neueres zum hochladen griffbereit.
Sofern getfacl verfügbar ist
nein, ist nicht verfügbar.
wünsche ebenfalls ein schönes wochenende.
ich hab's auf einem WH2000 (ohne reseller) nachvollziehen können.
mit rsync.amd64 und -p und umask 0022 (auf beiden seiten) bekomme ich das gleiche verhalten, wie vom TS:
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1336) [sender=3.2.7]es liegt am rsync.amd64.
probier mal folgenden rsync:
*link gelöscht*
# sha256
46df116d4b7ea50602cc113192f5945e85a1b0b8d87e0d2647952f6abbb17c6f rsync-3.2.4p.tar.gz