Ankündigung

Einklappen
Keine Ankündigung bisher.

VServer erste Schritte

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Es wird nirgendwo eine "Idioten" Schritt für Schitt Anleitung geben, die dir jeden einzelnen Befehl aufsagt. Dafür gibt es einfach viel zu viele Unterschiede bei den Distributionen, in der Umgebung, etc...
    (Manche brauchen umbedingt eine Klickibunti Oberfläche ala Plesk, andere können sowas nicht ausstehen)
    Ich zB halte nicht viel davon, da ich lieber komplette Kontrolle über das System haben will und mir kein Programm irgendwo rumpfuschen soll, ausserdem zuviel schlechte Erfahrung damit gemacht.......

    Aber fangen wir mal an.

    Für was dient der vServer überhaupt? Was soll alles rennen?
    Wie ich sehe hast du Plesk installiert, also wohl Web,DB & Mailserver?

    Kommentar


    • #17
      Zitat von ragtek Beitrag anzeigen
      Es wird nirgendwo eine "Idioten" Schritt für Schitt Anleitung geben, die dir jeden einzelnen Befehl aufsagt. Dafür gibt es einfach viel zu viele Unterschiede bei den Distributionen, in der Umgebung, etc...
      (Manche brauchen umbedingt eine Klickibunti Oberfläche ala Plesk, andere können sowas nicht ausstehen)
      Ich zB halte nicht viel davon, da ich lieber komplette Kontrolle über das System haben will und mir kein Programm irgendwo rumpfuschen soll, ausserdem zuviel schlechte Erfahrung damit gemacht.......

      Aber fangen wir mal an.

      Für was dient der vServer überhaupt? Was soll alles rennen?
      Wie ich sehe hast du Plesk installiert, also wohl Web,DB & Mailserver?
      Ja, Ubuntu und Pelsk habe ich drauf. Dienen soll es wie du richtig sagst für WEB, DB und Mail.

      Jetzt weiß ich nur nicht ob es denn sicher genug ist wenn ich das komplett dem Programm überlasse, und es wäre mir lieber wenn ich das selber lernen könnte.

      Deswegen suche ich nach einer Anleitung die mir die Grundlagen erstmal erklärt. Wenn ich die habe kann ich mich ja immer noch nach mehr umschauen.

      Kommentar


      • #18
        Es heißt "Plesk" mein Gott. Vielleicht solltest Du die Begriffe, die Du suchst, wenigstens richtig schreiben. "Google" als Pauschalantwort kann jeder schreiben, mittlerweile überzeugt mich das nicht mehr, dass jemand aktiv etwas gesucht hat.

        Results 1 - 10 of about 1,270,000 for serveradministration tutorial. (0.24 seconds)
        Sorry, aber so schwer kann das nicht sein.
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #19
          Tutorials und Howtos für Rootserver gibt es ja nun wirklich wie Sand am Meer.

          Tutorial Installation Debian ETCH Server
          Artikel::Rootserver-HOWTO - Pro-Linux
          The Perfect Setup - Debian Etch (Debian 4.0) | HowtoForge - Linux Howtos and Tutorials

          Gut, ist jetzt speziell für Debian, aber Ubuntu ist ja nicht so viel anders. Ich würde Debian vorziehen, möchte jetzt aber keinen Glaubenskrieg lostreten

          Du kannst ja mal die Tutorials zu hause auf einer virtuellen Maschine durchgehen und dein perfektes Setup finden. Dann spielst du ein minimales Image auf deinen Vsever ein (ohne diesen "Plesk-Müll") und richtest den Server dann live nach deinen Bedürfnissen ein.

          Bei speziellen Fragen kannst du dich auch RootForum Community • Resources for System-Administrators wenden oder stöberst vorab schon mal darin.

          Kommentar


          • #20
            ohne diesen "Plesk-Müll"
            Ich gebe zu bedenken, dass es manchmal auch andere Stakeholder gibt, die Interesse haben, irgendeine Zugangsform zu dem, was der Admin da macht, zu besitzen. Auch wenn das nur Klickibunti ist und zum Angucken benutzt wird.
            --

            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


            --

            Kommentar


            • #21
              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

              Kommentar


              • #22
                Zitat von robo47 Beitrag anzeigen
                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.
                Und warum sollte man das machen und auf den Komfort des Paketmanagers verzichten?

                Kommentar


                • #23
                  Zitat von hpf Beitrag anzeigen
                  Und warum sollte man das machen und auf den Komfort des Paketmanagers verzichten?
                  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

                  Kommentar


                  • #24
                    Zitat von robo47 Beitrag anzeigen
                    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 ? ....
                    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?

                    Kommentar


                    • #25
                      Sicher ist es ganz nett, wenn man das kann, es ist aber nicht unbedingt notwendig,
                      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..
                      --

                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                      --

                      Kommentar


                      • #26
                        Zitat von hpf Beitrag anzeigen
                        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?
                        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

                        Kommentar

                        Lädt...
                        X