Moin!
Da unangekuendigte Vulnerability Scans immer mal wieder sehr unangenehm fuer Monitoring-Personal sein koennen, stelle ich die Frage vorab:
Sollten legitime Vulnerability Scans fuer eigene Server im Vorfeld gegenueber Netcup angekuendigt werden?
(Diese Frage stelle ich im Forum, damit andere Kunden mit der gleichen Frage die Antwort hier direkt finden koennen, statt sich jeweils im Einzelnen an den Support wenden zu muessen.)
Danke fuer die Info. Welche der beiden Optionen kam dabei zum Tragen? Wurde die xattr-Option fuer dein bestehendes Dateisystem gesetzt oder ein zusaetzliches, externes Dateisystem (welches auch fuer etwaige Backups interessant sein koennte) eingebunden?
Hattest du mit der Supportanfrage Erfolg?
Zitat von [netcup] Felix;21834Ja, dahinter stehen wieder komplexe Vereinbarungen mit unseren Versicherungen. Unsere Haftpflicht setzt als Bedingung voraus, dass alles auf unseren Websites (Forum ausgeschlossen), unser Eigentum ist. Auch Überwacht ein Rechtsanwalt unser geistiges Eigentum.
Dann spraeche ja prinzipiell nix gegen eine Auftragsarbeit fuer Netcup, welche dann seitens Netcup unter der GPL veroeffentlicht wuerde.
Nur meine 2 Cent...
Absolut kein Interesse.
Windows ist viel zu kompliziert, damit will ich nix mehr zu tun haben.
Zitat von [netcup] Felix;12837Wir müssen das anbieten was das Volk haben möchte. Der letzte v(olks)Server hat ungefähr ein Viertel der im Jahr 2009 von uns verkauften vServer ausgemacht. Daher wurde er jetzt mit Geschwistern neu geboren.
Der v(olks)Server ist ganz klar ein Massenprodukt. Nur so können wir ihn derart günstig anbieten. Dennoch versuchen wir auch die Qualität zu überzeugen, was uns hoffentlich bislang gut gelungen ist.
Ich denke, dass der Erfolg eures volksServers eher dem Preis-Leistungs-Verhaeltnis und dem Mitmach-Faktor (Wunschaeuszerungen) geschuldet ist. Prinzipiell passt der Name auch und die von dir geschilderten Gedanken (Leistungsumfang gemeinschaftlich vom Volk entworfen; Vorbild Volkswagen) sind schluessig.
Durch die Bild sind solche Namensbildungen aber negativ behaftet. Das sticht potentiellen, bildkritisch eingestellten Neukunden vielleicht eher ins Auge.
Mir gehts nicht um Bedenklichkeit. Bei mir wecken die Namen Volkspizza, Volksserver, Volksrasierer, etc. in erster Linie Assoziationen zur Bildzeitung, was ich widerrum mit (persoenliche Wahrnehmung) mit Menschenverachtung und Volksverdummung assoziiere. Und diese Assoziationskette schreckt mich eher vom Kauf ab, als dass sie mich zu selbigem anregen wuerde.
Wobei ich auch die netcup-Argumentation verstehen kann, die laut Felix einen ganz anderen Ansatz verfolgt. Nichtsdestotrotz kommts bei Marketing wohl eher auf den ersten Eindruck an als auf die hinter einem Slogan steckenden Gedankengaenge. Wer sich die Zeit nimmt, die Erklaerung und Herleitung eines Slogans/Schlagworts/Markennamens zu lesen/hoeren, der nimmt sich auch die Zeit, schlicht Preis und Leistung zu vergleichen.
Ich hatte gerade eben das Problem, dass die bestehende SSH-Verbindung zu meinem vServer gekappt wurde. Als ich anschlieszend probiert habe mich erneut zu verbinden, war dies nicht moeglich.
Nach einem einfachen Neustart das gleiche Bild. Erst nachdem ich den Server gestoppt, eine Weile gewartet und ihn neu gestartet hatte, war ein erneuter Login moeglich.
Andere Dienste liefen waehrenddessen. Der Server liesz sich anpingen, nmap hat die ueblichen offenen Ports (einschl. SSH) angezeigt.
Hat jemand eine Idee, was da los war? Insbesondere irritiert mich der unmittelbare Verbindungsabbruch nachdem der Public Key akzeptiert wurde.
/var/log/auth.log: (gekuerzt, Benutzernamen und IP-Adressen geaendert)
Jan 22 20:17:01 manitu CRON[19835]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 22 20:17:01 manitu CRON[19835]: pam_unix(cron:session): session closed for user root
Jan 22 20:21:01 manitu sshd[21875]: error writing /proc/self/oom_adj: Permission denied
Jan 22 20:21:02 manitu sshd[21875]: Accepted publickey for my_user from 123.45.67.89 port 44198 ssh2
Jan 22 20:21:02 manitu sshd[21875]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 22 21:17:01 manitu CRON[16421]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 22 21:17:01 manitu CRON[16421]: pam_unix(cron:session): session closed for user root
Jan 22 22:17:01 manitu CRON[13336]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 22 22:17:01 manitu CRON[13336]: pam_unix(cron:session): session closed for user root
Jan 22 23:17:01 manitu CRON[12547]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 22 23:17:02 manitu CRON[12547]: pam_unix(cron:session): session closed for user root
Jan 23 00:17:01 manitu CRON[12114]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 23 00:17:01 manitu CRON[12114]: pam_unix(cron:session): session closed for user root
Jan 23 01:07:35 manitu su[29523]: Successful su for my_other_user by root
Jan 23 01:07:35 manitu su[29523]: + pts/3 root:my_other_user
Jan 23 01:07:35 manitu su[29523]: pam_unix(su:session): session opened for user my_other_user by (uid=0)
Jan 23 01:07:38 manitu su[29523]: pam_unix(su:session): session closed for user my_other_user
Jan 23 01:17:01 manitu CRON[2438]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 23 01:17:01 manitu CRON[2438]: pam_unix(cron:session): session closed for user root
Jan 23 01:43:05 manitu sshd[21875]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:17:01 manitu CRON[30836]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 23 02:17:01 manitu CRON[30836]: pam_unix(cron:session): session closed for user root
Jan 23 02:33:56 manitu sshd[5218]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:33:56 manitu sshd[5218]: Server listening on 0.0.0.0 port 24.
Jan 23 02:34:04 manitu sshd[5423]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:05 manitu sshd[5423]: Accepted publickey for my_user from 123.45.67.89 port 45009 ssh2
Jan 23 02:34:05 manitu sshd[5423]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:05 manitu sshd[5423]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:08 manitu sshd[5436]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:08 manitu sshd[5436]: Accepted publickey for my_user from 123.45.67.89 port 45010 ssh2
Jan 23 02:34:08 manitu sshd[5436]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:08 manitu sshd[5436]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:10 manitu sshd[5445]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:10 manitu sshd[5445]: Accepted publickey for my_user from 123.45.67.89 port 45011 ssh2
Jan 23 02:34:10 manitu sshd[5445]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:11 manitu sshd[5445]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:15 manitu sshd[5470]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:15 manitu sshd[5470]: Accepted publickey for my_user from 123.45.67.89 port 45012 ssh2
Jan 23 02:34:15 manitu sshd[5470]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:15 manitu sshd[5470]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:19 manitu sshd[5483]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:19 manitu sshd[5483]: Accepted publickey for my_user from 123.45.67.89 port 45013 ssh2
Jan 23 02:34:19 manitu sshd[5483]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:20 manitu sshd[5483]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:32 manitu sshd[5577]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:33 manitu sshd[5577]: Accepted publickey for my_user from 123.45.67.89 port 45014 ssh2
Jan 23 02:34:33 manitu sshd[5577]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:33 manitu sshd[5577]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:38 manitu sshd[5602]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:39 manitu sshd[5602]: Accepted publickey for my_user from 123.45.67.89 port 45015 ssh2
Jan 23 02:34:39 manitu sshd[5602]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:39 manitu sshd[5602]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:42 manitu sshd[5617]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:42 manitu sshd[5617]: Accepted publickey for my_user from 123.45.67.89 port 45016 ssh2
Jan 23 02:34:42 manitu sshd[5617]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:42 manitu sshd[5617]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:34:58 manitu sshd[5713]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:34:58 manitu sshd[5713]: Accepted publickey for my_user from 123.45.67.89 port 45017 ssh2
Jan 23 02:34:58 manitu sshd[5713]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:34:58 manitu sshd[5713]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:35:12 manitu sshd[6363]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:35:13 manitu sshd[6363]: Accepted publickey for my_user from 123.45.67.89 port 41755 ssh2
Jan 23 02:35:13 manitu sshd[6363]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:35:13 manitu sshd[6363]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:35:20 manitu sshd[6390]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:35:20 manitu sshd[6390]: Accepted publickey for my_user from 123.45.67.89 port 41756 ssh2
Jan 23 02:35:20 manitu sshd[6390]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:35:20 manitu sshd[6390]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:35:35 manitu sshd[6451]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:35:36 manitu sshd[6451]: Accepted publickey for my_user from 123.45.67.89 port 41759 ssh2
Jan 23 02:35:36 manitu sshd[6451]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:35:36 manitu sshd[6451]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:36:07 manitu sshd[6628]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:36:08 manitu sshd[6628]: Accepted publickey for my_user from 123.45.67.89 port 41770 ssh2
Jan 23 02:36:08 manitu sshd[6628]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:36:08 manitu sshd[6628]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:36:29 manitu sshd[6739]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:36:30 manitu sshd[6739]: Accepted publickey for my_user from 123.45.67.89 port 41778 ssh2
Jan 23 02:36:30 manitu sshd[6739]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:36:30 manitu sshd[6739]: pam_unix(sshd:session): session closed for user my_user
Jan 23 02:54:06 manitu sshd[14843]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:54:06 manitu sshd[14843]: Server listening on 0.0.0.0 port 24.
Jan 23 02:54:08 manitu sshd[15011]: error writing /proc/self/oom_adj: Permission denied
Jan 23 02:54:09 manitu sshd[15011]: Accepted publickey for my_user from 123.45.67.89 port 42722 ssh2
Jan 23 02:54:09 manitu sshd[15011]: pam_unix(sshd:session): session opened for user my_user by (uid=0)
Jan 23 02:54:23 manitu su[15112]: Successful su for root by my_user
Jan 23 02:54:23 manitu su[15112]: + pts/5 my_user:root
Jan 23 02:54:23 manitu su[15112]: pam_unix(su:session): session opened for user root by (uid=1000)Wenn in Foren Verbesserungsvorschlaege gemacht werden, besteht traditionell der Groszteil der Antworten aus "brauch ich nicht"-Beitraegen. Warum auch immer. 
Ergaenzung: Will man das Backup zu Hause per Cronjob anschubsen, braucht man
Mir ist vollkommen klar, dass sich jeder vServer-Kunde irgendeinen Workaround fuer die Backups basteln kann. Mein Anliegen zielt darauf ab, dass das nicht noetig sein sollte.
Wie aus der Zitatliste hervorgeht, steh ich mit diesem Wunsch nicht ganz allein da. Falls eine solche Funktion eingefuehrt wuerde, bspw. das alte Backup optional ersetzt wuerde, dann waere den Fuersprechern geholfen, waehrend die Gegner ueberhaupt nicht beeinflusst wuerden.
Backup nach Hause ist auch ja nicht schwierig. Recovery mit Flaschenhals-Upload sieht da schon anders aus 
Nun, das scheint zwar in die richtige Richtung zu gehen (wobei die Artikelbeschreibung recht knapp gefasst ist). Den Einsatzzweck dieses Produkts sehe ich aber eher als Backup-Moeglichkeit fuer Webspace, denn da passt es in die Preisstruktur.
Fuer das Backup eines kleinen vServers sind die 5 Euro aber ganz schoen happig, wenn der eigentliche Server kaum teurer oder gar guenstiger ist. Da ist ein zweiter vServer oder ein Webspace-Vertrag finanziell gesehen die bessere Wahl -- wobei das ja nicht der Sinn der Sache ist.
Da es mein eigener Wunsch ist und sich im Thema Neue vServer im Januar 2010 neben mir eine grosze Anzahl an Fuersprechern gefunden hat, eroeffne ich mal ein extra Thema dafuer.
Die Netcup-Backup-Funktion ist leider nur sehr eingeschraenkt nutzbar, da die folgenden wichtigen Funktionen von ihr nicht erfuellt werden.
Es waere daher eine sehr schoene Sache, wenn ein dedizierter (S)FTP-Backupspace eingerichtet wuerde. Dafuer wuerde ich auch gern auf die bisherigen Snapshots verzichten.
Im folgenden eine Zusammenfassung der thematisch passenden Beitraege aus dem Januar-Server-Thread:
Zitat von Lucan;11570(...)
vServer fürs Backup nicht mehr offline (Kann ja wahlweise geändert werden)
Backup downloadbar
Zitat von lupinix;11573Ist es überhaupt möglich ein konsistentes Backup bei laufendem Server zu machen? Während dem Backupprozess könnten sich ja z.B. Dateien ändern.
Downloadbares Backup fände ich auch ganz nett, aber ein meinetwegen 10GB großes Backup wieder Hochladen macht keinen Spaß (außer du lagerst es auf einem anderen Server)
Zitat von toe;11579Ein Backup-Bereich waere schoen. Allerdings nicht fuer vollstaendige Snapshots des Systems, sondern bspw. fuer Backupskripte mit rsync oder aehnlichem.
Evtl. eine Option um etwas vom bestehenden Plattenplatz abzuknapsen und dafuer Backupspace zu bekommen. Mein vServer silber hat bspw. 60 GB Plattenplatz. Wenn ich die Moeglichkeit haette, diesen um 10GB zu reduzieren und dafuer entsprechend Backupspace (auf einem anderen Node) zu bekommen, dann waere das sehr praktisch.
Zitat von chitypo;11580(...)
Ich schiebe gern meine Daten via Script zeitlichabgestimmt auf einen Backupserver.
Zitat von toe;11581Bingo. Und sowas stelle ich mir aus einer Hand (sprich: Server+Backupspace von netcup) vor.
Zitat von kostaki;11584einfach nen zweiten kleinen vserver nehmen und schon gehts auch per rsync. Bei mir isses nen Gold Server den ich als Rsync Backup Server laufen habe, aber nen FTP Backupspace würde sicher schon für die meisten reichen.
Zitat von toe;11585(...)
Mir gehts einfach darum, beispielsweise per Cronjob alle paar Stunden meinen gesamten Emailbestand per rsync auf einen anderen Rechner rueberzuspiegeln. Da bietet sich eher eine Variante an, wie sie von kostaki beschrieben wird. (Kleiner vServer oder FTP-Server.)
Schoener waer's allerdings als Vertragsbestandteil, insbesondere wenn man brachliegende Kapazitaeten hat.
Zitat von theDude;11598Auf meinem vServer 768 erstelle per backup2l ein Backup (...) und spiegle es auf meinem Rechner daheim. (...) Dank einem 20 MBit-Anschluss kein Problem. Bei Datenmengen zwischen 256 kB und ca 450 MB für ein full-backup reichen auch deutlich kleinere Leitungen. (...) Wenn allerdings große, variable Daten auf dem Server liegen sollen muss man sich sicherlich etwas anderes einfallen lassen.
Zitat von bebbo;11603Mein Wunschliste:
(...)
3. (S)FTP Space um Backups zu lagern
(...)
Backup ist für mich kein Thema, das erledigt ein Script (stoppt nur das, was sonst inkonsistent wäre) und das incrementelle Archiv wird heruntergeladen. Das Hochladen wird dann sicher mal dauern...(deswegen wäre 3. prima).
Zitat von ice-breaker;11633(...)
Backups: 0 (sind eh unbrauchbar)
Zitat von theDude;11641(...)
Das aktuelle Backup-System finde ich übrigens kaum brauchbar. Es sei denn man möchte den Server neu aufsetzen und nur sichern, um im Notfall darauf zurückgreifen zu können.
Idee: Standardmäßig kein Backup, dafür aber auf Anforderung ein Backup, dass für - sagen wir - 3 Tage behalten wird. Danach wird wieder alles automatisch gelöscht.
Zitat von thelion;11643Alles anzeigenHier wurde ja schon mehrmals geäußert, das eigene Backupserver besser seien als die Netcup-Backups. Der Meinung bin ich auch, deshalb mein Vorschlag:
Backup-vServer
333 MHz CPU
250 Mb RAM garantiert
1000 Mb RAM flexibel
120 Gb Festplatte
unlimitiertem Traffic
0 Backups
Also einen Server mit wenig Leistung und viel Speicher (Festplatten kosten ja kaum noch was), mit dem man sich günstig einen speziellen Backup-Server einrichten kann. Sonst muss man immer die 2GHz Prozessorleistung mitbezahlen, die man niemals nutzen wird.
Grüße
Jannis
Zitat von P.Se;11783Von der Leistung her bin ich zufrieden. Was ich mir eher wünsche:
Backups die schneller angefertigt werden
Nee, 5 Euro monatlich fuer 10GB reinen Backupspace find ich recht happig -- zumindest im Vergleich zu den knapp ueber 8 Euro die der eigentliche vServer kostet.
Darueber hinaus liest sich die Produktbeschreibung fuer mich so, als wenn die Funktion von diesem Backupspace dem Inklusiv-Backupspace entspraeche. Sprich Server anhalten, Komplett-Backup anfertigen, Server neustarten.
Mir gehts einfach darum, beispielsweise per Cronjob alle paar Stunden meinen gesamten Emailbestand per rsync auf einen anderen Rechner rueberzuspiegeln. Da bietet sich eher eine Variante an, wie sie von kostaki beschrieben wird. (Kleiner vServer oder FTP-Server.)
Schoener waer's allerdings als Vertragsbestandteil, insbesondere wenn man brachliegende Kapazitaeten hat.
Zitat von chitypo;11580Wobei ich Backup für Sinnfrei halte. (höchstens dem traffic gegen zu wirken)
Ich schiebe gern meine Daten via Script zeitlichabgestimmt auf einen Backupserver.
Bingo. Und sowas stelle ich mir aus einer Hand (sprich: Server+Backupspace von netcup) vor.
Ein Backup-Bereich waere schoen. Allerdings nicht fuer vollstaendige Snapshots des Systems, sondern bspw. fuer Backupskripte mit rsync oder aehnlichem.
Evtl. eine Option um etwas vom bestehenden Plattenplatz abzuknapsen und dafuer Backupspace zu bekommen. Mein vServer silber hat bspw. 60 GB Plattenplatz. Wenn ich die Moeglichkeit haette, diesen um 10GB zu reduzieren und dafuer entsprechend Backupspace (auf einem anderen Node) zu bekommen, dann waere das sehr praktisch.
[LaTeX]
Die reellen Zahlen brauchst du dafuer nicht, denn:
Sei $B := \{20GB, 4.8GB, 200MB\}$, so folgt $B \subset \mathbb{N}$. Deine Aussage ist aber natuerlich trotzdem richtig wegen $\mathbb{N} \subset \mathbb{R}$
Dafuer haste aber immerhin den allgemeineren Fall gleich miterschlagen
Lehramt? Bachelor? Diplom?
[/LaTeX]
Die eigentlichen Dateien liegen auf dem Server, es geht nur ums Seeden. Der stuendliche Upload liegt uebrigens unter 200MB, was ca. 4,8GB Tagestraffic entspricht und damit voellig im Rahmen sein sollte.
Konsequenzen fuer Extrem-Traffic sind gelesen und bekannt.
Quelle: http://forum.netcup.de/showpost.php?p=10317&postcount=2
Zitat von [netcup] Felix;10317(...) Kunden (...) auf einen anderen Node verschoben, da sie über lange Zeit (meist einen Monat), extrem die Bandbreite belastet haben und somit andere Kunden einen Nachteil hatten. Bei 20 GB Traffic pro Tag hat man bei uns überhaupt nichts zu befürchten. (...)
Mir gehts lediglich um eine Aussage zur legalen Nutzung von Bittorrent, sowie die Information ob vor einem etwaigen Nodewechsel eine Warnung erfolgt oder nicht.
Tu dir die Ruhe an, der Deckel ist sehr weit unten.
Anlaesslich des 26c3 nutze ich Bittorrent, um einige der Vortrags-Videos herunterzuladen. Selbstverstaendlich legal.
Zwei Fragen:
1.) Spricht etwas gegen die Bittorrent-Nutzung? (Wie gesagt, hier geht es ausschl. um legale Dateien.)
2.) Erfolgt eine Warnung, sobald man ein kritisches Traffic-Level erreicht? (Der Upload ist mittels "--max_upload_rate" nach oben gedeckelt und sollte folglich nicht ausarten. Trotzdem ein interessanter Punkt.)
