robo47

Meine Meinung, dein Ansatz ist hier einfach falsch.

Wenn du Rallye-Fahrer werden willst und noch keinen Führerschein hast setzt du dich doch auch nicht in deiner ersten Fahrstunde ans Steuer und willst durch Kurven driften und co ohne zu wissen wie man schaltet, gas gibt, bremst, was die ganzen Amaturen da bedeuten, wozu die ganzen lustigen knöpfe sind und soweiter ...... .

Bevor du mit dem ganzen Kram wie Webserver, Mailserver, Datenbankserver, Plesk und co anfängst solltest du dich vielleicht erstmal aktiv mit dem Betriebsystem selbst auseinandersetzt und beschäftigen und nicht einfach zuhause ne VM aufsetzen und ab und zu mal damit was machen, sondern wirklich mal Linux installieren und aktiv nutzen, schauen wie gut oder schlechst du damit klar kommst, vor allem auch im non-gui bereich.

Sachen ausprobieren, rumkonfigurieren, ausprobieren, die basics lernen wie und wo deine Distribution was ablegt, wo liegen programme, wo libs, wo configs, wie verteilt die distri ihre configs, etc. Dann Dinge wie man programme selbst kompiliert, was man bei fehlern macht, wie man sie löst, etc.
Und dann irgendwann mal von hand ohne paketmanager und co mal deine Umgebung alla webserver + scriptsprache(n) + datenbankserver + mailserver zusammenstellen, den ganzen kram compilieren, installieren und konfigurieren.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Mister Ad

hpf

Und warum sollte man das machen und auf den Komfort des Paketmanagers verzichten?

robo47

Um Linux kennenzulernen ? Um damit umgehen zu können ? Um zu wissen mit was man arbeitet ? Um im Fall eines Falles dazu fähig zu sein wenn ein update via paketmanager einem zu lange dauert (sicherheitspatch, kritische lücke, etc) sich seinen kram selbst zu kompilieren, wenn man vielleicht mit den versionen die im paketmanager drin sind nicht zufrieden ist ? ....

Man muss im Live-Betrieb dann ja nicht darauf verzichten, aber man sollte ausreichend erfahrung und knowhow haben um auch ohne ihn auszukommen.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

hpf

Sicher ist es ganz nett, wenn man das kann, es ist aber nicht unbedingt notwendig, um einen V-Server zu administrieren.
Z.B. ist bei Debian Etch PHP 5.2.6. Da mir diese Version ausreicht, habe ich es dabei belassen. Wenn man jetzt unbedingt die 5.3er haben möchte, kann man ja seine sources.list um den entsprechenden Testing-Eintrag erweitern - kompilieren muss man trotzdem nichts.
Im übrigen sehe ich das als den entscheidenden Nachteil "(sicherheitspatch, kritische lücke, etc) sich seinen kram selbst zu kompilieren". Für alles was am Paketmanager vorbeiinstalliert wurde, bist du selbst verantwortlich. Der Paketmanager aktualisiert alle Pakete in einem Rutsch und vergisst dabei keines. Und wieviel längert dauert es, bis die Distribution den Patch herausbringt, drei Stunden?

nikosch

Naja, ich weiß nicht. Wenn man wirklich dafür verantwortlich ist (und nicht doch noch den Senior zur Seite hat), dann hat man, wenn es hart auf hart kommt, echt ein Problem ohne Tiefenwissen. Das ist doch auch das, worauf die gesamten „Tu's lieber nicht“ Aussagen hinauslaufen. Auf den worst case. Und wenn über einem keine Instanz mehr steht und man dann nur noch den Stecker ziehen kann..

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

robo47

Die Frage ist doch immer wie lange es wirklich dauert bis die Lücke in irgendeiner Form von Software ausgenutzt werden. Bestes Beispiel bekannte OS-Systeme wie wordpress, joomla, drupal, etc da muss man nur mal in seine logs anschauen und gucken an nem tag wo so ne lücke bekannt wird wie da die zugriffe steigen.

Also den Testing-Zweig produktiv einsetzen halte ich für keine gute Idee, da dort meines wissens nach keine Sicherheitspatches eingeschoben werden wie im stable-zweig, sprich da kommt irgendwann dann mal die neuere version wenn man sich entschieden hat das noch aufzunehmen ins nächste Release.

In Debian Squeeze (6.0 testing) was ich hier lokal aufm notebook nutze kam php 5.3.2 gestern oder vorgestern, released wurde es am 4. Mai!

So oder so bin ich der Meinung dass jemand der für ein solches System verantwortlich, es wartet und pflegt, auch ausreichend Kenntnisse und Fähigkeiten mitbringen sollte um die relevanten Teile seines Systems selbst kompilieren zu können.

Ich selbst nutze ansonsten auch meistens den packetmanager.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework