Beiträge von Robert

    War nicht sonst die Rede von einem Neustart? ;)

    Bei mir laufen sowohl Trac als auch SVN über HTTPS, sodass die Verbindung bei den beiden Sachen schonmal abgesichert ist. Wenn du mit Buildserver sowas wie Hudson meinst, müsste das ja auch über HTTPS gehen. Falls du Anwendungen hast, die nicht über HTTP laufen, kannst du dir Stunnel ansehen. Das wird auf dem Server installiert, der Client muss allerdings das Gegenstück dazu installieren/starten. Angenommen du hast eine Anwendung auf Port 123 laufen. Mit Stunnel würde der Client sich nicht auf den Server verbinden, sondern auf localhost:456 (je nachdem, wie der Stunnel-Client eingestellt ist). Von dort wird eine SSL-Verbindung zum Server aufgemacht, allerdings nicht direkt zu Port 123 (da ja das Programm damit nichts anfangen kann), sondern beispielsweise zu Port 789. Dort lauscht der Stunnel-Server und leitet die Anfrage dann intern an Port 123 weiter. Vorteil: funktioniert für die meisten Fälle. Nachteile: Man muss den Client dafür starten und für die eigentliche Anwendung kommt die Verbindung von localhost statt der externen IP.

    Falls es nicht notwendig ist, dass sich die Empfänger selbst für die Mailingliste an- und abmelden können, solltest du dir Abschnitt 4.3.2 im Handbuch ansehen. Allerdings steht dort, dass die Funktion auf 10 Empfänger begrenzt ist, was wohl etwas wenig sein dürfte. Mehr ist dann vermutlich aber auch nicht ohne zusätzliche Software möglich.

    Port 21 für FTP ist vom inetd belegt. Kann sein, dass man FTP auch über diesen Umweg betreiben kann, allerdings hört bei mir Proftpd direkt auf diesem Port. Offensichtlich ging es ja vorhin noch. Was hast du denn danach eingegeben? Mit "aptitude reinstall proftpd" kannst du Proftpd neu installieren, vorausgesetzt du verwendest aptitude zur Paketverwaltung.

    Es werden nur die Dateien aktualisiert, die sich im SVN geändert haben. Solange sich die Standardkonfiguration nicht ändert, ist daher alles kein Problem. Und auch wenn sich etwas ändert, ist das normalerweise kein Problem: Die beiden Dateien werden einfach zusammengefügt. Nur, wenn die gleiche Zeile in beiden Dateien verändert wurde, gibt es einen Konflikt, den du dann manuell beheben musst. Von dir angelegte Dateien, die nicht im SVN vorhanden sind, werden nicht gelöscht.

    AuthName entspricht "Name des geschützten Bereiches" in dem Formular. Beim Standardwert ist ein Leerzeichen drin, daher funktioniert es nicht. Laut Apache-Handbuch: "Falls der Name des Realm Leerzeichen enthält, muss er in Anführungszeichen eingeschlossen werden." Das ist Problem #1. Allerdings hast du wahrscheinlich auch den Pfad nicht korrekt angegeben. Der sollte mit /var/www anfangen oder so ähnlich. Erstelle einfach eine info.php in dem Verzeichnis, das du schützen möchtest. Dort schreibst du rein
    [PHP]<?php phpinfo()[/PHP]
    und rufst sie im Browser auf. Suche dort nach "DOCUMENT_ROOT", dann hast du deinen Pfad (allerdings erwartet der Generator am Ende des Pfads einen Slash). Dann die info.php löschen und die beiden Dateien hochladen, damit sollte es funktionieren. Oder du versuchst es nochmal mit Confixx selbst.

    Es klingt so, als wäre das ein Webhosting-Paket, da kann man meines Wissens nach den Error-Log nicht ansehen.

    Der Ordner kann vermutlich deswegen nicht gelöscht werden, weil die .htaccess-Datei noch darin liegt. Dateien, die mit einem Punkt beginnen, werden von Unix-Systemen als versteckte Dateien behandelt und sind daher normalerweise nicht sichtbar. Falls Confixx eine Option zum Anzeigen dieser Dateien bietet, versuche es damit. Ansonsten nimmst du ein FTP-Programm wie FileZilla und verbindest dich zum Server. Dort kann man im Menü "Server" die "Auflistung versteckter Dateien erzwingen". Damit solltest du den Ordner löschen können.

    Der Verzeichnisschutz dürfte auch eine .htaccess erstellen. Möglicherweise passiert das mit einer gewissen Verzögerung, sodass der Schutz nicht wirksam wird. Sobald das Passwort eingegeben wurde, wird es vom Browser gespeichert. Spätestens beim Neustart des Browsers muss man das Passwort dann neu eingeben.

    Heißt das, dass dann die momentan angebotenen vServer nicht mehr bestellt werden können? Der vServer Gold kostet ja 14,95 € und hat auch 1 GB RAM garantiert. Da bin ich ja mal gespannt, was man für die zusätzlichen 5 € bekommt. Allerdings ist das sowieso mehr, als ich momentan bereit bin zu zahlen.

    Zitat von sim4000;4253

    Wieso Packst du nicht alles was Backup sein soll in ein *.tar.gz und schiebst es via scp auf den anderen Server. Das geht via Pubkey und auch ohne root.

    Damit würde allerdings dann der große Vorteil von rsnapshot verloren gehen: durch Hardlinks platzsparend mehrere Backupstände aufbewahren können, die man trotzdem einfach wiederherstellen kann.

    Also laut den FAQ von rsnapshot ist das Pushen des Backups auf einen anderen Server (noch) nicht möglich, dort stehen auch ein paar Problematiken. Daher zwei Ansätze, die mir spontan einfallen:

    a) Kannst du möglicherweise doch einen Root-Benutzer anlegen (muss ja nicht root heißen, sondern einfach nur UID und GID 0 haben), der idealerweise nur für die IP deines anderen Servers freigegeben ist?

    b) rsnapshot basiert ja auf rsync, somit kann man auch den Daemon von rsync als Quelle verwenden. Wenn der auf dem Quellserver läuft, können bestimmte Verzeichnisse freigegeben werden, dabei gibt es auch eine Authentifizierung. Das ist allerdings von Haus aus nicht verschlüsselt und die Authentifizierung ist ebenfalls knackbar, daher wird empfohlen, auf rsync über ssh auszuweichen. Mit ssh-Tunneln habe ich bisher keine Erfahrung, aber ich würde vermuten, dass dafür irgendein Benutzeraccount ausreicht, um auf den Server zu kommen, und ab da kann dann wie lokal zugegriffen werden.

    Methode a) sollte bis auf die IP-Begrenzung auf jeden Fall funktionieren, b) wäre vermutlich die etwas schönere Lösung. Ideal wäre natürlich, wenn man direkt pushen könnte, aber das scheint halt nicht zu gehen.

    Für mich sieht der Cronjob-Eintrag nicht richtig aus.

    Code
    1 0 * * * root /usr/bin/php /html/wadriller/wordpress/xyz.php

    Ich bin mir nicht sicher, ob man den Benutzer angeben muss, aber bisher habe ich das immer so gesehen. root ist nur ein Beispiel, es muss halt ein Benutzer sein, der die Datei lesen kann. Möglicherweise - das halte ich aber eher für unwahrscheinlich - ist PHP auch unterschiedlich konfiguriert für Apache und die Kommandozeile. Funktioniert der Aufruf von "/usr/bin/php /html/wadriller/wordpress/xyz.php"?

    Hier wird für Ubuntu beschrieben wie es geht. Der Hinweis auf die Konfig-Datei könnte interessant sein. Wie oben schon erwähnt, einfach mal die Befehle direkt ausführen und sehen was passiert.