Cronjobs

[Serpiente]

Hallo,
wie ich bereits aus VHCS, der Wishlist und meiner eigenen ispcp-installation weiß, sind Cronjobs für Domainbenutzer zur Zeit nicht umgesetzt. Ich würde dies gerne Implementieren, da ich ende des Jahres / Anfang nächstes Jahr meinen nächsten Root mit ispcp aufsetzen würde.

Ich habe mir über vmware ne box erstellt und ubuntu 8.05 Hardy installiert. heute morgen noch die Installation von ispcp durchgeführt. Hierbei ist mir aufgefallen dass das Paket libperl5.10 für ubuntu nicht verfügbar ist, zumindest nicht über apt-get und aptitude - steht soweit ichs gesehen habe aber schon im bugtracker.

So, nun zu meinen Fragen zum Design: Hat jede Domain einen eigenen Serverbenutzer und läuft Apache/PHP mit den Berechtigungen von diesem Benutzer oder wie in VHCS einen www-data Benutzer? Wie wurde der Cage für die jeweilige Domain gelöst?

und zu guter letzt, wenn ich das lauffähig bei mir hinbekomme, wie submitte ich dann diese erweiterung und kann die noch mit in die erste stable kommen?

[gurge]

Soweit ich weiß läuft jeder Serverbenutzer unter seiner eigenen Berechtigung.

Wenn ich ein Cronjob brauche lege ändere ich einfach die crontab von dem user. Klappt bis jetzt ohne Probleme.

Ich weiß jetzt nicht ganz was du mit Cache willst?

Am einfachsten du erstellst erstmal ein Patch wenn du fertig bist.

[Serpiente]

war n rechtschreibfehler, ging um den chroot cage. ich werde es mir nachher mal anschauen und gucken wie man das gut integrieren könnte.

[ZooL]

die idee ist wunderbar, ich glaube weiss es aber nun nicht ob es noch aktuell ist am anfang waren die gui datein für cronjobs noch vorhanden....

mfg

[Cube]

Quote:So, nun zu meinen Fragen zum Design: Hat jede Domain einen eigenen Serverbenutzer und läuft Apache/PHP mit den Berechtigungen von diesem Benutzer oder wie in VHCS einen www-data Benutzer?

ispCP nutzt FastCGI und somit laufen Skripte unter dem jeweiligem Benutzer.

Quote:und zu guter letzt, wenn ich das lauffähig bei mir hinbekomme, wie submitte ich dann diese erweiterung

Neues Ticket eröffnen und Patch anhängen.

Quote:und kann die noch mit in die erste stable kommen?

Kommt drauf wann du fertig bist, wie die Qualität des ganzen ist und was die Devs dazu sagen.

[ephigenie]

Wie schon an anderer Stelle geschrieben zum Thema cronjobs - die Vorraussetzung für eine ordentliche Implementierung von cronjobs wären ordentlich chroot umgebungen (pro user !)
es gibt da 2-3 Wrapper Skripte - die soetwas für CGI's bereitstellen - aber das ist alles nicht ganz trivial -> es beeinflusst das gesamte Handling angefangen von fastcgi bis eben zu cgi's usw.. ausserdem dürften dabei pro User nochmal min. 20-40MB extra anfallen - nur für die chroot umgebung. Natürlich könnte man das auch mit geschickt gesetzten Hardlinks usw. deutlich verkleinern. Aber da hängt viel Arbeit dran.

Der Crondaemon selber muss nat. dann auch wissen wo die Crontabs dann liegen usw (können ja dann nur noch im chroot liegen ... )
als Nebeneffekt könnte man den Usern dann auch z.B. scponly / "full ssh" Zugriff ermöglichen.

[Serpiente]

ephigenie Wrote:Wie schon an anderer Stelle geschrieben zum Thema cronjobs - die Vorraussetzung für eine ordentliche Implementierung von cronjobs wären ordentlich chroot umgebungen (pro user !)
es gibt da 2-3 Wrapper Skripte - die soetwas für CGI's bereitstellen - aber das ist alles nicht ganz trivial -> es beeinflusst das gesamte Handling angefangen von fastcgi bis eben zu cgi's usw.. ausserdem dürften dabei pro User nochmal min. 20-40MB extra anfallen - nur für die chroot umgebung. Natürlich könnte man das auch mit geschickt gesetzten Hardlinks usw. deutlich verkleinern. Aber da hängt viel Arbeit dran.

Der Crondaemon selber muss nat. dann auch wissen wo die Crontabs dann liegen usw (können ja dann nur noch im chroot liegen ... )
als Nebeneffekt könnte man den Usern dann auch z.B. scponly / "full ssh" Zugriff ermöglichen.

Chroot ist kein Sicherheitsfeature! Wichtiger wäre es vernünftige Dateirechte zu setzen und zumindest unter Linux den User somit auszusperren.

Für die Cronjobs dachte ich an eine Datenbankunterstützung;
Kunde wählt über einen File-Browser die gewünschte Datei aus, das Skript trägt den Cron in die DB, der daemon liest die DB aus und arbeitet die Cronjobs ab.

[ephigenie]

User im chroot einsperren zu können ist sehr wohl ein zusätzliches Sicherheitsmerkmal.
Die damit aufgebaute Barriere erschwert bzw. vereitelt im günstigsten Fall eine Ausbreitung eines Angreifers auf das gesamte System.

Natürlich ist das kein Allheilmittel - ein Unix System ist von Hause aus recht sicher und multiuser geeignet. Trotzdem hat sich die Komplexität der Software in letzter Zeit unglaublich erhöht - dazu kommt - dass viele Systeme nicht so gepacht und auf aktuellem Stand gehalten werden wie das normalerweise sein sollte.

[ZooL]

angefangen mit der chroot jail im Red-Hat aufgehört in dem nichtvorhandensein bei Debian..

mfg

[Serpiente]

wie lösen andere verwaltungsprogramme dieses problem? so wie ich das mitbekommen hab gibt es in Confixx die Möglichkeit Crons anzulegen.