Beiträge von Servior

Zitat von Robert;16242

Bei meiner Konfiguration ist es so, dass FTP-Benutzer, die ich für die Verwaltung von Webseiten anlege, mit den Rechten vom Apache laufen. Ich habe PHP als Apache-Modul, daher läuft auch PHP unter www-data. Wenn die Benutzer unterschiedlich sind, kann es vorkommen, dass in PHP oder per FTP angelegte Dateien im jeweils anderen nicht geschrieben/gelöscht werden können.

Das Problem ist ganz normal bei der Konfiguration.

Entweder vergibst du dem Webserver Berechtigung auf die Dateien und passt deinen FTP-Server entsprechend an. (Nachteil daran ist dass beim Betrieb mit mehreren Benutzern die Sicherheit leidet)

ODER

Du beschäftigst dich mit Suexec.
http://wiki.hetzner.de/index.php/Apache_PHP5_fcgi_und_SuExec

Da gibts ne recht gute Anleitung dazu, dann werden die Dateien unter dem FTP Benutzer ausgeführt.

chown -R 2001:2001 htdocs
Dann sollte das Überschreiben usw. auch möglich sein.

Ansonsten musst du schon mitteilen was funktionieren soll.

Was genau soll es denn bringen die Berechtigung auf den Webserver zu übertragen?

Du musst dort schon den FTP User und dessen Gruppe angeben. Lad halt einfach mal ne neue Datei hoch und guck dir an welche Berechtigung diese bekommt.

Wieso setzt du die Berechtigung nicht einfach wieder, den dafür nötigen Root Zugriff scheinst du ja zu besitzen.
Automatisch setzen braucht man da nichts, das ist mittels "chown user:gruppe datei" bzw. "chown -R user:gruppe ordner" innerhalb von einer Minute korrigiert.

Wenn die Dateien allerdings unterschiedlichen Benutzern gehörten, dann musst du selbst erstmal gucken wer worauf Zugriff haben sollte.

Nebenbei, was hat das ganze mit PHP bzw. dessen Konfiguration zutun?

Nein, nicht /var/backups sondern /backup

Das kopieren könnte man sich allerdings sparen indem man die Dateien in /backup kopiert.

Die Dateien im Backup-Ordner sollten bei einer Neuinstallation übers VCP erhalten bleiben.

Du siehst die Fehlermeldung doch schon..

: FTP session opened.
: USER user1: Login successful.
: notice: unable to use '~/' [resolved to '/var/kunden/webs/user1//']: No such file or directory
: Preparing to chroot to directory '~/'
: user1 chroot("~/"): No such file or directory
: error: unable to set default root directory
: FTP session closed.

Wenn das Verzeichnis nicht existiert wird die Sitzung beendet.

Und welche PHP Version verwendest du?

Wenn du Version 5.X benutzt, dann solltest du auch die Lib für PHP5 installieren.

Für mich liegt die Entscheidung darin begründet dass ich gerne alles aus einem Guss habe.

Webserver - Mysql
TS3 - Mysql

und alles andere was ne Datenbank benötigt würde ich, sofern es unterstützt wird, auch mit Mysql laufen lassen.
Verschiedene Systeme mögen gut sein, nur wenn aus den 2 Systemen dann mal 3,4 und 5 werden verliert man ggf. die Übersicht.

Copy&Paste.

Du kannst einstellen welche Berechtigung du benötigst um eine Datei hochzuladen (needed_upload_power) und halt welche der Benutzer wirklich hat (upload_power).

Wenn du in einem Channel keinen Upload haben willst, dann kannst du die Berechtigung einfach auf 100+ setzen.
Genauso kannst halt nur den Admins den Upload in einem Channel erlauben, während im nächsten dann alle dürfen.

Versuchs halt telefonisch, da kann man dir ggf. schneller helfen.

Natürlich wurde man per Email informiert, nur wenn man die Informationen hier zusammen trägt, dann sollen die Infos aus den Emails hier schließlich auch irgendwann angezeigt werden.

Zwar erst mit einem Login, damit man nicht alle Informationen sieht, nur frage ich mich was dagegen spricht dies bis dahin allen zur Verfügung zu stellen.

Über den Abschluss der Arbeiten wird man nicht per Email informiert, auf einer Status Seite sieht meistens wenn diese abgeschlossen sind.

Vielleicht ist ja genau das sein Problem.

Wenn man nur Zugriff per localhost erlaubt, dann wird die Angabe der IP (sofern diese nicht 127.0.0.1 ist), bzw. der Domainname nicht funktionieren.

Wird auf der Seite eigentlich noch irgendwas gepflegt?

Mail von 20:43:

Guten Tag ___,

  auf Grund eines wichtigen Kernelupdates wird Ihr VServer im Laufe der nächsten Stunde neugestartet.

  Mit freundlichen Grüßen

  netcup Team

Auf der Webseite sieht man dazu jedenfalls nichts.
Zumindest laut meiner Uhr ist der Neustart gute 8 Minuten überfällig (grade während des schreibens wird der Neustart durchgeführt).

Ich will die Fähigkeiten deines kollegen nicht in Frage stellen, aber was genau klappt denn jetzt nicht?

Wenn dein Server offline ist solltest den über VCP wieder starten, da gibts dann ggf. auch ne Fehlermeldung die genug aussagt.
Falls der Server an ist, kommst du per SSH drauf? Wenn der Dienst nicht antwortet, den Server mal neu starten.. solltest dann immernoch nicht drauf kommen ist entweder die IP/Port Kombination falsch oder du hast deinen SSH Daemon gekillt.

Da heißts dann entweder im Rescuesystem rumbasteln, oder neu aufsetzen (dürfte vermutlich einfacher sein wenn eh nix drauf is).

Wenn SSH läuft und dir antwortet: Stimmt das Kennwort noch? Ändern kannste das im VCP, bzw. bei einer neuinstallation wirds angezeigt wenn die Installation abgeschlossen ist.

Zugangsdaten stehen in der Datei /root/zugangsdaten.txt

Edit: Ansonsten bleibt nur zu sagen das man sich ohne Grundwissen keinen vServer holen sollte.

Wenn du den allerdings behalten willst kann man dir ggf. bei der Ersteinrichtung & Absicherung helfen. Alles danach müsstest dann aber selbst einrichten und absichern.

Nur weil du das Problem bei einem Freehoster noch nie hattest, musst du deswegen nicht gleich auf Netcup rumhacken.

Ich hatte es bei Freehostern auch noch nicht, das liegt aber daran dass die sich nicht um Sicherheit kümmern.

Hier wird Suexec oder ähnliches eingesetzt, das bei 777 bzw. 775 einfach streikt.

Wer seine Dateien freiwillig mit der Berechtigung 777 betreibt, muss sich nicht wundern wenn da mal andere drauf zugreifen können.
Sicherheitslücken gibt es überall, wenn man dann aber noch absichtlich die Berechtigung falsch setzt...

Der Cron-Daemon hat, bis auf dass er für das ausführen der Cronjobs zuständig ist, nichts mit Syscp zutun.

Wenn du diesen neustartest heißt das noch nicht dass die Cronjobs vom Syscp auch korrekt funktionieren.

Zum einen solltest du gucken wie die Cronjobs von Syscp eingetragen sind, also ob das überhaupt richtig ist.
Wenn dort alles korrekt ist, solltest du versuchen die Befehle aus dem Cronjob von Hand zu starten, wenn das funktioniert musst du gucken warum der Cronjob nicht ausgeführt wird.

Dazu musste dann allerdings Logs durchsuchen.

Wie hast du das ganze denn versucht?

Mittlerweile hat sich rausgestellt dass die sql Datei defekt ist.

Ne ältere Version scheint funktioniert zu haben.