klär das doch mit dem support, da php glaube ich als cgi läuft kan man viel. deine einstellungen anpassen od. du kannst es evtl. in einer .htaccess aufheben.
Sie haben eine ausführliche eMail von mir erhalten. Hier wird auch erklärt warum wir den Safe_Mode als sicher betrachten und nicht abschalten. Der Safe_Mode ist in PHP generell aktiv und die Default-Einstellung.
Wir haben Ihnen eine Stornierung des Vertrages aus Kulanz angeboten.
Und weil Safe_Mod ja so eine tolle Erfindung ist, wird er mit php6 auch weiter supported.
Findet die ironie.
Zitat von Lucan;23487Und weil Safe_Mod ja so eine tolle Erfindung ist, wird er mit php6 auch weiter supported.
Findet die ironie.
ist doch hupe. (Nichts neues das es abgeschaft wir)
jedem seins.
Der Safe Mode wird in PHP 6 definitiv abgeschafft. Nichts mit nicht deaktivierbar. Er ist nicht umsonst in PHP 5.3.0 DEPRECATED und keine Standardeinstellung mehr;)
Hier auch ein Statement dazu direkt von php.net:
ZitatThe PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
Zitatwarum wir den Safe_Mode als sicher betrachten und nicht abschalten
Die Begründung würde ich gerne sehen.
Und ja SafeMode seid PHP5.3 standardmäßig deaktiviert und ab PHP6 entfernt.
Naja, Leute. Im Prinzip haben wir als Kunde nicht das Recht, Netcup vorschreiben zu wollen, ob sie den safe_mode aktiviert lassen (denn ich denke mal, dass das System vor PHP 5.3 aufgesetzt wurde und somit der safe_mode von Anfang an aktiv war) oder nicht.
Natürlich ist es nicht ganz zu vergleichen, aber dann könnte man als Kunde ja gleich fordern, exec, shell_exec und system frei und global nutzen zu können. In der PHP-Version, die ich auf meinem vServer aufgesetzt habe, war dies nicht per Default deaktiviert, was also in das Argument mit der standardmäßigen Deaktivierung ab 5.3 und völligem Ausbleiben ab 6.0 passen würde.
Ich finde schön, dass das Problem zu beiderseiten Zufriedenheit gelöst werden konnte: Netcup hat keinen Kunden verloren, sondern hostet nun ein anderes Paket statt dessen, der Kunde hat, was er will.
Allerdings könnte Netcup tatsächlich bei der Produktbeschreibung einen Hinweis geben, dass der safe_mode aktiv ist. Denn ganz so selbstverständlich wie, dass absolut sicherheitsrelevante Funktionen wie z.B. die obigen deaktiviert sind, ist es ja doch nicht. 
ZitatIn PHP6 wird der Safe_Mode z.B. gar nicht mehr abgeschaltet werden können.
Das der Safe_Mode in PHP6 rausfliegt, weil er sich als nutzlos erwiesen hat, und das man ihn nicht mehr deaktivieren kann sind aber 2 paar Schuhe 
Eigentlich wurde er ja nur als einfache Version erfunden, den Zugriff auf bestimmte Dateien zu verhindern, auf die man keinen Zugriff haben sollte, da dies aber eigentlich eine Funktion des Betriebssystems ist, wird es in Zukunft rausfliegen und vor allem weil mit mehreren PoCs bewiesen wurde, dass er seine Ansprüche nicht halten kann und es immerwieder genug Möglichkeiten gibt aus dem Safe_Mode auszubrechen.
Eine andere Frage die man sich stellen sollte ist, welche Software benötigt heutzutage noch einen ausgeschalteten Safe_Mode? Welche Funktionen hat die Software, dass sie einen ausgeschalteten Safe_mode benötigt?
Die mir einzig bekannte sind ausführbare kompilierte Dateien die durch den eingeschalteten Safe_Mode nicht möglich sind.
Wir sehen den Safe_Mode als zusätzlichen wertvollen Schutz an, sollte ein anderer Schutz, wie z.B. disable_function aus irgend einem Grund (z.B. eine Sicherheitslücke) nicht greifen.
Wir können mit Stolz sagen, dass bei uns noch nie ein Server kompromittiert werden konnte. Ich denke das haben wir unserer guten Sicherheitspolitik zu verdanken.
Da hier scheinbar vermehrt der Wunsch nach einem ausgeschalteten Safe_Mode geäußert wird (warum auch immer), arbeiten wir eine Lösung aus, die noch auf zusätzliche Weise sicher stellt, dass ein Kunde aus seinem vHost mittels PHP nicht ausbrechen kann (dieses wird direkt über den Kernel realisiert werden). Anschließend werden wir den Safe_Mode de-aktivierbar machen.
Dieses Feature wird zusammen mit einer neuen Generation von Webhosting-Tarifen eingeführt werden. Wir werden z.B. auch in jedem Tarif (bei bestehenden auf Anfrage) das Memory_Limit verdoppeln um damit häufig geäußerten Kritikpunkten gerecht werden zu können.
Mit dem Release ist schon morgen zu rechnen.
neija, wie schon genannt würde es ja reichen, die Information, dass der safe_mode an ist, in die Produktbeschreibung zu übernehmen.
Genauso wie es schön wäre, z.B. in den Starter-Tarifen die Info einzutragen, dass mod_rewrite nicht vorhanden ist, es ist denke ich da einfach nur ein wenig mehr Transparenz nötig
Wo ich dabei bin, eine tabellarische Übersichtsgrafik (Produktmatrix) worin sich alle Webhosting-Pakete unterscheiden, wäre wirklich sehr angebracht, alle Pakete durchzuschauen welches Modul dort (nicht) vorhanden ist, ist ziemlich nervig.
Ansonsten: Klasse Support und Reaktion, dass auf Grund dieses doch eher unbedeutenden Foren-Threads neue Produkte eingeführt werden mit einer Funktion, die jemand vermisst hat.
Darf ich dann auch gleich einen Wunsch äußern? Ein Webhosting-Paket mit PHP 5.3 
Damit hättet ihr im deutschen Webhostingraum zur Zeit ein fast Alleinstellungsmerkmal, das müsste man natürlich halten und auch sagen wir z.B. immer 4-5 Wochen nach erscheinen einer neuen Version upgraden.
ZitatAnsonsten: Klasse Support und Reaktion, dass auf Grund dieses doch eher unbedeutenden Foren-Threads neue Produkte eingeführt werden mit einer Funktion, die jemand vermisst hat.
Darf ich dann auch gleich einen Wunsch äußern? Ein Webhosting-Paket mit PHP 5.3
Ich denke das dafür der Arbeitsaufwand riesig wäre.
Aber Netcup hat uns schon öfter üebrrascht....
Ach und @ Felix... Mit dem deaktivierten SafeMod werde ich wieder eines dieser Pakete bestellen. Da es grundsätzlich nichts an netcup auszusetzen gibt.
Zitat von Scaleo;23711Ich denke das dafür der Arbeitsaufwand riesig wäre.
Aber Netcup hat uns schon öfter üebrrascht....
PHP aus dem Sourcecode zu kompilieren ist zuviel Arbeit? :eek:
nicht wirklich.
Entweder ein eigener Server, der auf PHP5.3 setzt, es für alle Profi-Pakete aktivieren (Abwärtskompatibilität ist geben) oder eben per CGI.
Was mich nur an jedem Webhoster stört, ist dieses dauerhafte Leben in der Vergangenheit, weil die Debian-ReleasePolitik verbietet mittendrin eine neue Version in die Paketquellen einzupflegen. PHP 5.3 ist mittlerweile 13 Monate draussen, und noch immer bekommt man es nirgends, weil alle zu faul sind, es selbst zu kompilieren. Normalen Anwendern mag das egal sein, deren Wordpress oder Drupal basiert eh noch auf PHP4, aber als Entwickler ist eben PHP 5.3 mit Namespaces für größere Anwendungen Pflicht.
Zumal die nächste Generation aller relevanten Frameworks (Doctrine 2, Zend Framework 2, ...) auch auf PHP5.3 setzen wird, und ob PHP 5.3 genutzt werden kann, wenn die rauskommen ist wieder eine Frage.
Und genau so geht es mit jeder PHP- oder MySQL-Version, man ist auf Grund der Faulheit dazu gezwungen für alte Releases zu entwickeln und so möglicherweise gute Funktionen nicht nutzen zu können.
Ich fordere ja nicht, dass jedes Minor-Update eingespielt wird, aber abwärtskompatible Major-Version könnten doch wenigstens mal in einem Zeitraum von 4-8 Wochen eingespielt werden, bis dahin ist auch bekannt, ob sich grobe Fehler eingeschlichen haben oder nicht, bis dahin sind die auch wieder stabil, sollte mal ein Fehler auftreten.
Zumal die neuen Versionen (bis auf ein PHP 5.x.0 :D) sowieso meistens stabiler und schneller sind.
Ich rede ja auch nicht von experimentellen Version, sondern wirklich nur von als stabil klassifizierter Software.
Wenn alles so einfach wäre, würde sicher ja jeder Webhoster werden...
Wir betreuen eine Serverfarm mit mehreren tausend Kunden. Hier kann nicht mal eben eine Software kompiliert und eingespielt werden. Unsere Server sind keine Spiel- und Testwiese sondern sie sind für einen Umsatz von mehreren 100000 Euro / Jahr bei uns verantwortlich (wenn wir die Umsätze unserer Kunden mit ein-berechnen, wären es mehrere Millionen).
Ich finde es beängstigend mit welcher Einstellung manche meinen unser Handeln beurteilen zu können. Wir sind bestimmt nicht faul und tun alles um zufriedene Kunden zu haben, soweit dieses uns möglich ist.
Wer dieses nicht glaubt, darf gerne ein Praktikum bei uns machen, um sich davon zu überzeugen.
Zitat von [netcup] Felix;23726Wenn alles so einfach wäre, würde sicher ja jeder Webhoster werden...
dem ist doch schon lange so.
Zitat von [netcup] Felix;23726Wir betreuen eine Serverfarm mit mehreren tausend Kunden. Hier kann nicht mal eben eine Software kompiliert und eingespielt werden. Unsere Server sind keine Spiel- und Testwiese sondern sie sind für einen Umsatz von mehreren 100000 Euro / Jahr bei uns verantwortlich (wenn wir die Umsätze unserer Kunden mit ein-berechnen, wären es mehrere Millionen).
wie ich bereits sagte, rede ich auch von stable Releases, also keine Spielwiese und 8 Wochen sind doch nun wirklich ausreichend um aus der Community des Projektes und selber Erfahrungen zu sammeln, ob dies der Wahrheit entspricht.
Und das dies technisch nicht einfach möglich ist, komm, wir wissen beide das dem nicht so ist, es wird auf die offiziellen Debian-Paketquellen gesetzt, weil es angenehmer ist.
Ein eigenes Repository mit eigenen Builds drinnen und man kann in Minuten ein Build über tausende Server fahren, und das ist normale Praxis.
Zitat von [netcup] Felix;23726Ich finde es beängstigend mit welcher Einstellung manche meinen unser Handeln beurteilen zu können. Wir sind bestimmt nicht faul und tun alles um zufriedene Kunden zu haben, soweit dieses uns möglich ist.
ich habe meinen Post nicht auf euch speziell bezogen, sondern auf die Allgemeinheit, dass ihr eben auf Grund einem veralteten PHP-Release auch darunter fallt, ist eben eine andere Sache.
Was spricht denn also technisch sowie gewährleistungstechnisch gegen PHP 5.3? Es ist stabiler, schneller und sicherer als die hier eingesetzte Version. Aktuell wäre nämlich PHP 5.2.14, eingesetzt wird PHP 5.2.6-1+lenny8, also irgendeine gepatchte Version bei der man nicht einmal weiß, welche Bugs gefixxed sind.
In 5.2.12 ist z.B. eine Schutz gegen Upload-ddos-Attacken vorhanden, und in vielen weiteren Releases wurden andere Sicherheitslücken gefixxed (z.B. die Möglichkeit aus dem safe_mode auszubrechen: 5.2.13)
Der Hauptgrund ist, dass die vielen einzigartigen Scripte unserer Kunden funktionieren müssen. Daher setzen wir auf eine Distribution und deren Versionen. Würden wir jetzt auf einen Schlag PHP 5.3 heraus bringen, hätten wir viele unzufriedene Kunden und der Support würde zusammenbrechen.
Es ist bei den meisten unserer Kunden so, dass sie einen Preis einen Massenproduktes bezahlen. Gegen entsprechende Vergütung stellen wir auch komplett individuelle Umgebungen bereit. PHP 5.3 ist hier dann auch möglich.
Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.
