Beiträge von Robert

    Zitat von AGB

    netcup ist berechtigt, die für den Kunden zur Verfügung gestellten Dienste vorübergehend zu sperren, wenn der Kunde gegen die vorgenannten Verhaltenspflichten verstößt oder ein entsprechender, konkreter Verdacht besteht. Dies ist insbesondere dann der Fall, wenn Dritte unter Angabe von Gründen Unterlassung der vom Kunden vorgenommenen Handlungen verlangen und diese Gründe nicht offensichtlich unzutreffend sind, oder bei Ermittlungen durch staatliche Behörden.

    Die "vorgenannten Verhaltenspflichten" umfassen in Bezug auf die Nutzung des Webspace:

    Zitat

    # massenhafter Versand von unangeforderten Werbe-Emails (Spam)

    # Hinterlegen und Zugänglichmachen von Daten und Material mit pornographischem, kommerziellem erotischem Charakter und von urheberrechtlich geschütztem Material, zu deren Verbreitung der Nutzer nicht berechtigt ist (z.B. sog. "Warez"-Seiten, illegale MP3-Downloads)

    # Hinterlegen und Zugänglichmachen von Daten und Material mit links- oder rechtsradikalem Inhalt oder beleidigendem Charakter, Aufruf zu Terrorismus und Gewalttaten

    # Betreiben von Serverdiensten , die eine besonders starke Rechnerlast verursachen; dies gilt nicht bei dedizierten und virtuellen Servern

    Also wenn du nicht gerade dazu aufgerufen hast, die Stabilität des Servers mit solchen Attacken zu testen, wüsste ich nicht, welche Handlungen du unterlassen solltest. :confused:

    Wie oben geschrieben: error.log. Die Datei heißt so. Wo sie bei deinem System liegt weiß ich nicht, da ich deine genaue Konfiguration nicht kenne. Ich habe meinen Server so eingerichtet, dass ich für jede Seite einen eigenen error.log habe. Die Standard-Logdatei befindet sich in /var/log/apache2.

    Fehler 500 kann viele Ursachen haben, häufig verursacht durch fehlerhafte Einstellungen in der Apache-Config bzw. in htaccess-Dateien. Schau mal ins error.log, da sollte eine genauere Fehlermeldung stehen.

    Ich habe gerade mal auf dem Webspace von einem Freund nachgeguckt: Dieses phptmp-Verzeichnis wird für den "upload_tmp_dir" genutzt, also neue Dateien werden dorthin hochgeladen. Ich weiß nicht, ob es Gründe gibt, warum PHP-Skripte auf diesen Ort nicht zugreifen sollten - vielleicht wurde daran einfach bei der Konfiguration des Servers nicht gedacht. Standardmäßig (wenn nichts explizit eingestellt ist) wird /tmp benutzt, und darauf dürfen Skripte zugreifen. Also ich schlage vor, du schreibst einfach dem Support ein Ticket, in dem du auf diesen Thread verweist.

    Ich hätte gedacht, dass man sich auch einfach irgendwo einen Nameserver mieten kann, habe aber so spontan keinen Anbieter dafür gefunden. Ist vielleicht eine Marktlücke. ;) Tja, wenn also das nicht geht und du nicht zufällig einen Bekannten hast, der einen Nameserver installiert hat, musst du den wohl selber betreiben. Wobei ich bei meinem Domainanbieter (inwx) die Nameservereinträge unabhängig von meinen registrierten Domains anlegen kann. Wenn ich explizit diesen Nameserver abfrage, spuckt der die eingegeben Daten auch aus, also theoretisch müsste das gehen. Inwiefern das auch erlaubt ist, müsstest du den Anbieter fragen.

    Zitat von Artimis;15092

    Fällt diese Bewertung sehr gut aus, so meint der Absender, kannst du sogar mehr für die Domain verlangen. Wenn nicht, möchte er gerne einen Preisnachlass von 12% bis 15%.

    Ich verstehe die Mail so, dass er den Rabatt generell auf den durch die Bewertung ermittelten Preis haben will, unabhängig davon, ob der Preis höher oder niedriger als dein Angebot ist.

    Mir scheint das auch etwas fraglich... diese Bewertungen sind ja nicht umsonst, d.h. du müsstest erst nochmal selbst investieren. Inwiefern diese Bewertung nun den tatsächlich realistisch ist und wer mit wem gemeinsame Geschäfte macht, kann ich nicht beurteilen. Ich würde aber auf jeden Fall vorsichtig sein.

    Ja, da ist zum einen die Javascript-Datei und das loggende PHP-Skript, das vom .htaccess-Schutz ausgeschlossen werden muss, vielleicht auch noch andere. Als Anstoß:

    http://httpd.apache.org/docs/2.2/mod/core.html#files

    Ich stelle mir das so vor, dass du generell erstmal das Verzeichnis absicherst und dann mit einem Files-Block für diese Dateien den Schutz wieder aufhebst. Ich bin mir nicht sicher, ob das über AuthType etc. wieder aufzuheben geht, evtl. brauchst du Allow from all, Satisfy any.

    In phpinfo() steht zudem auch, welche php.ini(s) verwendet eingelesen wurden. Falls die Standardeinstellung irgendwo überschrieben wurde, dann in einer von diesen Dateien.

    Zitat von Artimis;14790

    zum dritten gibt es vertraulichere Infos als geplante Wartungsarbeiten.

    Solange man sich nicht mit den Daten aus der URL im VCP anmelden kann. Daher ja mein Vorschlag, die Authentifizierung für einen Parameter zu machen, der entweder unabhängig vom Passwort ist oder von diesem abgeleitet (nicht zurückführbar). Letzteres hätte den Vorteil, dass man einfach sein Passwort ändern kann, falls jemand die URL rausfindet, und schon hat derjenige keine Zugriff mehr. Hat aber natürlich auch den Nachteil, dass man die URL bei jeder Passwortänderung neu einstellen müsste.

    Das hatte ich auch schon vorgeschlagen, wurde leider abgelehnt:

    Zitat von [netcup] Alex;14384

    Da zukünftig wie bereits erwähnt ein Login vorgeschaltet sein wird, macht ein RSS Feed an dieser Stelle keinen Sinn.

    Wobei man natürlich auch einen persönlichen RSS-Feed bauen könnte. Also eine zufällige Zeichenkette oder Benutzername + versalzener Hash vom Passworthash oder so in die URL. Ja, dann könnte man die URL mitsniffen. Aber soo kritisch sind die Meldungen dann auch wieder nicht, zumal man mit den Benutzerdaten sich nirgendwo anders einloggen könnte. Und es gibt ja immer noch SSL. Also ich fände es schon sehr vorteilhaft, so einen Feed zu haben.

    Awstats analysiert allerdings im Gegensatz zu Google Analytics/Piwik lediglich die Webserver-Logs (funktioniert allerdings daher auch ohne Javascript).

    Piwik habe ich auch im Einsatz.. ist schon ganz nett, aber auch nicht umwerfend.

    Zitat von bobby5959;14437

    1,5 GB und Webspaceverbrauch im WWW ordner also maximal 2.5 GB zusammen

    Aber der Webspace (/var/www/) liegt doch innerhalb des Rootverzeichnis (/) und müsste damit zu den 1,5 GB im Rootverzeichnis dazuzählen. Oder meinst du mit dem Rootverzeichnis das Homeverzeichnis vom Benutzer root (/root)?

    Welche Skripte sind das denn? Ich habe ja vorhin mal etwas mit den Ordnerrechten rumgetestet und wenn ich nicht etwas übersehen habe, dann ist ein Ordner mit chmod 666 ziemlich sinnlos, weil auf die Dateien darin nicht zugegriffen werden kann... dementsprechend verwundert es mich, dass ein Skript genau das haben will.

    Also das einzige was mir dazu einfällt: Wenn du einem Ordner die Rechte 666 gibst, dann kann keiner (außer root) mehr in das Verzeichnis wechseln oder Dateien darin auflisten/anzeigen lassen. Das scheinen irgendwie die gleichen Effekte zu sein wie bei 000... Mit Rechten 111 geht nur das Auflisten der Dateien nicht.

    Wenn also jeder Lese-/Schreibzugriff haben soll, dann nimm 777, die normale Einstellung ist aber 755 bei Ordnern und 644 bei Dateien.