Beiträge von dfroe

n'Abend,
bevor ich näher auf das Thema "Dateianhang per Mail verschicken" genauer eingehe: Bist du dir sicher, dass du das wirklich willst? Du solltest nämlich bedenken, dass du per Mail keine Binär-Daten versenden kannst. Binär-Dateien müssen somit erst MIME/Base64-kodiert werden, wodurch ein deutlicher Overhead entsteht und die Mail etwa 37% größer ist als die eigentliche Datei. Wenn die Mails dann noch durch Viren-/Spam-Scanner wandern müssen und evtl. an einer maximalen Größe scheitern, wird's vielleicht doch nicht gerade das gelbe vom Ei sein.

Bei den Wochentagen müsstest du einfach deinen date-Teil aus deinem ursprünglichen Teil mit `date +%w` ersetzen. Dann bekommt der Dateiname an dieser Stelle eine 0 für Sonntag, 1 für Montag, usw.. Nach einer Woche wiederholt und überschreibt sich das ganze dann.

Moin moin,wäre mir dieses Posting früher aufgefallen, hätte ich hier auch früher geantwortet; aber irgendwie ist mir das entgangen. Möglichkeit 1 mit den Wochentagen.Wenn du im Dateinamen den Wochentag verwendest, so hast du ja schon ein Backup-System, das automatisch alte Backups nach einer Woche wieder mit den neuen überschreibt. Tar überschreibt beim Erstellen eines Archivs nämlich ein ggfs. bereits vorhandenes Archiv.Möglichkeit 2, alte Backups löschen.Du kannst am Ende (oder am Anfang) deines Backup-Scripts einfach per find alle Backups suchen lassen, die z.B. älter als 5 Tage sind, und diese dann löschen lassen.

find /home/mybackup/backups -mtime +5 -delete

Das löschte alle Dateien in dem Verzeichnis die vor mehr als 5 Tagen modifiziert (mtime) wurden.

Hallo,
die Mail bekommst du immer dann, wenn der per Cron abgesetzte Befehl irgendetwas ausgibt.
Du kannst den awstats stumm schalten, indem du in der crontab-Zeile ans Ende der Zeile " >/dev/null" (ohne die Anführungszeichen) anhängst. Damit werden sämtliche Meldungen von awstats ins virtuelle Nirvana (/dev/null) umgeleitet.

Hallo,
ob ein komplettes VPN nach dem Server-Client-Prinzip auf den netcup vServern möglich ist, bezweifle ich.
Das einzige, was auf jeden Fall funktioniert, ist eine Point-to-Point VPN-Verbindung. Dies habe ich selber zur sicheren Datenübertragung zwischen meinen beiden netcup vServer am Laufen.

Server 1:
tun-Device: inet Adresse:10.47.69.1 P-z-P:10.47.69.2

port 1194
proto udp
dev tun1
secret static.key
persist-tun
persist-key
comp-lzo
remote Server2IP
keepalive 60 300

Server 2:
tun-Device: inet addr:10.47.69.2 P-t-P:10.47.69.1

port 1194
proto udp
dev tun1
secret static.key
persist-tun
persist-key
comp-lzo
remote Server1IP
keepalive 60 300

Hierbei hast du nun aber wie bereits gesagt nur eine Punkt-zu-Punkt Verbindung zwischen zwei Rechnern. Es könnte durchaus sein, dass eine Nutzung eines ganzen Subnetzes mit OpenVPN auf Grund der Missbrauchsfälle in der Vergangenheit tatsächlich nicht möglich ist.

n'Abend,
also funktionieren tut awstats definitiv auf einem vServer mit vHosts.

Bei mir sieht's konkret so aus:

[I]edv[/I][I]@edv-froehlich:~# grep -i customlog /etc/apache2/sites-available/edv
[/I][B] CustomLog /var/log/apache2/access.log combined
[/B][I]edv@edv-froehlich:~# grep access.log /etc/awstats/awstats.edv.conf
[/I][B] LogFile="/var/log/apache2/access.log"[/B]

Das ist eigentlich schon das ganze Hexenwerk.
Wenn du getrennte Statistiken für verschiedene (Sub-)Domains haben willst, musst du hierfür soweit ich weiß aber auch getrennte Log-Dateien verwenden. Dann klappt's auch mit dem Standard-Combined-Format. Ansonsten musst du eben wie bereits gesagt mit Zusatzparametern tricksen.

Zitat

deswegen verändere ich auch grundsätzlich nur sachen, die ich verstehe. [...] was hacker angeht.. das einzige, was ich bis jetzt an der vserver konfiguration geändert habe, ist der crontab.

Da könnte man ja meinen, ein vServer wäre out-of-the-box bereits sicher...

Es geht ja nicht nur dadrum, dass du für einen vServer ohne Wartung Probleme bekommen kannst.
Wenn dein vServer z.B. als OpenRelay fungiert und dann gleich das ganze IP-Subnetz auf einer DNS-Blacklist landet, leiden auch die ganzen anderen User darunter, die im selben Subnetz liegen. Solche Vorfälle hatte ich bei meinem alten Anbieter leider des Öfteren, was sehr ärgerlich war, weil dann die eigenen Mails nicht mehr zuverlässig zugestellt werden können.

Von daher, entweder einen Managed Server zulegen, wo dir wie bereits gesagt Netcup die gesamte Administration abnimmt, oder du betreibst in deinem LAN einen Linux-Server und eignest dir da mit learning-by-doing die ganzen notwendigen Kenntnisse an. Letzteres geht auch (diesen Weg habe ich z.B. eingeschlagen), aber da darf man sich dann eben nicht beschweren, wenn man sich erst nach einigen Jahren "traut", die Verantwortung für einen öffentlichen vServer zu übernehmen.

Hallo Sigrid,

Zitat

Dann bekomme ich aber jedesmal die Meldung mit dem blau-grauen Bildschirm der schon nach der Installation erschienen ist.

Also nach dem Durchlesen dieses Satzes bin ich irgendwie auch nicht schlauer wie vorher.
Könntest du uns vielleicht verraten, wie diese Meldung denn lautet? Wenn du mit blau-grauem Bildschirm nämlich die Debian Dialog Boxen meinst, die wollen von dir eben verschiedene Fragen beantwortet haben, um die ganzen Pakete zu konfigurieren.

Zitat

aber in der php.ini sind sie nicht enthalten.

Dann schreib sie doch einfach rein.
Aber ich vermute eher, dass die Extensions über das php/conf.d Verzeichnis eingebunden werden. Schau doch zuerst mal nach, ob es nicht etwa im conf.d-Verzeichnis einen Eintrag für die Erweiterungen gibt. Dann passt nämlich bereits alles, da die Dateien im conf.d-Verzeichnis genauso wie die php.ini geladen werden.

Hallo,
die Aussage würde ich soweit bestätigen, es muss nicht unbedingt ein Kernel-Modul sein. Ein Rootkit ist im Prinzip einfach irgendeine Art von Schadsoftware, die auf deinem Server eine Art Hintür offen hält, über die der Angreifer Zugriff zu deinem System erhält.

Ein klassisches Beispiel hierfür wäre z.B. vor einigen Jahren der Bug im Kernel, wo man durch das Laden eines Moduls Root-Rechte erlangen konnte.

Rein theoretisch könnte es aber auch z.B. ein PHP-Skript sein, dass die ganze Zeit läuft und von seinem Programmierer auf Befehle wartet, die es dann auf dem Server ausführt.
Soetwas würde dann wahrscheinlich chkrootkit und rkhunter aber auch nicht entdecken.

Wie dem auch sei, 100%ige Sicherheit gibt es nicht, und nur das Ausführen von chkrootkit&Co. brint rein gar nichts. Ein Angreifer würde als erstes nämlich das chkrootkit Binary so manipulieren, dass es nicht mehr Alarm schreit.

Wunderbar, wär ja gelacht wenn sich dieses kleine Problem nicht auch lösen ließe.

Hallo,
ich vermute dann aber eher das Problem darin, wie Webmin prüft, ob der Apache läuft. Ein "/etc/init.d/apache2 status" wie z.B. unter SuSE gibt es unter Debian/Ubuntu nicht. Von daher wäre wohl eher interessant, welche Methode Webmin denn für diese Überprüfung benutzt. Da ich Webmin aber nicht kenne, muss ich an dieser Stelle nun passen.
Wüsste man dies, so könnte man wahrscheinlich einfach die entsprechenden Code-Zeilen anpassen, damit's auch in der neuen Ubuntu-Umgebung läuft.

Hallo,
ein Fehler ist das in dem Sinne nicht. Diverse Init.d-Skripte wollen in der aktuellen Ubuntu-Version mittels /dev/console Status-Meldungen wie "Dienst gestartet" auf dem Monitor ausgeben. In einer vServer-Umgebung gibt es aber soetwas wie einen Monitor nicht, das Device-File /dev/console existiert daher auch gar nicht.
Der einfachste Workaround ist wohl, einfach die Zeilen auszukommentieren, die auf /dev/console zugreifen. Bei dir wären das nun konkret in der /etc/init.d/apache2 Zeile 197 und /etc/init.d/rc Zeile 166.

Hallo,
ich denke da kann man dir Entwarnung geben. Diese Meldung erhalte ich nämlich auch auf beiden meiner vServer. Ich gehe einfach mal davon aus, dass Netcup die Wirtssysteme schon sorgfältig und verantwortungsbewusst administriert.

Viel mehr wurmt mich der Debian OpenSSL-Bug, vorallem bei Keys, die bereits mit längerer Laufzeit in kostenpflichtige Dienste eingebunden wurden. :mad:

Achso, dass es sich um einen Managed vServer handelt ist mir neu.
Wenn dem so ist, dann würde ich auf jeden Fall mal den Support kontaktieren. Die dürften das dann auf jeden Fall hinbekommen.

Hallo,
wenn du es dir ganz einfach machen willst, kannst du dir bereits mit diesem einzigen Befehl ein selbst-signiertes SSL-Zertifikat erstellen:

openssl req -new -x509 -days 3650 -nodes -out ssl.pem -keyout ssl.pem

Die Datei ssl.pem enthält dann sowohl den privaten Schlüssel als auch das SSL-Zertifikat zum Einbinden in deinen Web-Server bzw. in den Confixx.
Um einfach nur einen HTTPS-Zugriff auf die Domain zu bekommen sollte das für den Anfang schonmal reichen.

PS: Sorry für den Kauftipp, für die Zukunft weiß ich ja jetzt Bescheid. Ich wollte ja nur die zuvor geposteten 200 Euro nicht einfach so stehen lassen.

Hallo,
die Nutzung des IRC-Ports 6667 ist übrigens nicht nur bei Netcup nicht möglich, sondern diese Sperre ist auch bei vielen anderen Providern gängige Praxis.
So betrifft die Filterung des Ports 6667 nicht nur Netcup-Kunden, sondern grundsätzlich alle, die ihre Server im Hetzner-Rechenzentrum stehen haben.

Siehe auch Hetzner-Wiki: Wieso ist Port 6667 gesperrt?

So etwas lässt sich übrigens auch im Voraus in Erfahrung bringen, wenn man sich bereits vor dem Kauf intensiv über das Rechenzentrum des neuen vServers informiert. Denn schließlich spielt das Rechenzentrum bei Servern neben den Leistungsdaten des eigentlichen Servers und der Kundenbetreuung ja eine zentrale Rolle.

Ob Netcup solche Informationen direkt auf der Homepage veröffentlichen sollte, darüber ließe sich jetzt sicherlich streiten.

And last but not least, das Ausweichen auf einen non-standard Port ist ja wirklich kein Hexenwerk, und vorallem bei kritischen Anwendungen ratsam. Als Tipp am Rande sei hier nur noch kurz erwähnt, auch den SSH-Daemon auf einen non-standard Port umzustellen. Spart auch etliche Ressourcen, wenn sonst mal wieder dutzende Bots versuchen würden, sich gleichzeitig mit hunderten von Standard-Benutzernamen auf dem Server einzuloggen.

Der Web-Server wird dir aus Sicherheitsgründen auf der Error-Page keine weiteren Details verraten.
Aber als Tipp, wirf doch mal einen Blick in das Error Log-File des Apache, bzw. poste hier die letzten Zeilen.

Sicher gibt es Anwendungsgebiete, wo ein solches 20-Euro-Zertifikat nicht mehr ausreicht. Aber da fallen mir zuerst einmal nur Banken&Co. ein sowie Handy-Clients. Für den Normal-User (Internet Explorer, Mozilla, Opera, Safari) ist es i.d.R. vollkommen ausreichend, wenn er sieht "diese Seite ist SSL-verschlüsselt", und "der Herausgeber des Zertifikats ist vertrauenswürdig" da mir mein Browser keine Warnmeldung anzeigt.
Dieses Niveau sollte eigentlich für die meisten "normalen" SSL-Sites vollkommen ausreichen. Auch Mail-Server lassen sich damit ohne Probleme absichern. Und preislich kann wie gesagt sogar ich sowas für 20 Euro anbieten.
Ansonsten tun's die selbst-signierten Zertifikate auch dann, wenn ich ganz genau weiß, dass ich diesem Zertifikat vertrauen kann. Dann hake ich einmal in meinem Browser an "diesem Zertifikat immer vertrauen" und dann bleibe ich auch vor weiteren Warnmeldungen verschont; zumindest solange wie das Zertifikat eben gültig ist.

Im Prinzip hast du schon Recht, dass eine SSL-Verbindung auch mit einem abgelaufenen Zertifikat funktioniert. Aber wenn es schon ein selbst-signiertes ist, dann ist der Aufwand ein neues gültiges Zertifikat zu erstellen mit einem einzigen Befehl auf der Bash doch auch wieder verschwindend gering.

Zitat

Echte geprüfte Zertifikaten kosten leider so viel das es sich nicht rechnen würde.

Wenn du meinst, dass sich 20 Euro pro Jahr für ein geprüftes Zertifikat nicht lohnen. Mir persönlich wären es die 20 Euro wert, dass mein SSL-Zertifikat für meinen Host von einer vertrauenswürdigen CA ausgestellt ist. Schafft doch vorallem auf Seite der Kunden noch ein zusätzliches Vertrauen, wenn man gleich auf eine SSL-verschlüsselte Seite geleitet wird ohne dass der Browser eine Warnmeldung ausspuckt.

---- Gelöscht ----