Ankündigung

Einklappen
Keine Ankündigung bisher.

Wamp-Server Projekt root auf ein Netzlaufwerk legen?

Einklappen

Neue Werbung 2019

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

  • #16
    Jetzt funktionierts, auch über den Service wenn ich dem Service einen User gebe. Über das Systemkonto geht es nicht. Vorhin hat es nicht funktioniert weil vermutlich der Path nicht so gepasst hat wie er ihn braucht.
    Das einzige was nicht geht, ist die index.php die ich nicht brauche und das keine virtual hosts über das Wampmenü erzeugt werden können. Das ist mir auch egal. Ich kann die Virtual Hosts auch manuell bearbeiten.

    Tausend Dank dir und noch eine schöne Zeit.



    Code:
    <VirtualHost *:80>
        ServerName mp
        DocumentRoot "\\\\192.168.1.23\\F\\PHPWorkspace\\www"
        <Directory  "\\\\192.168.1.23\\F\\PHPWorkspace\\www\\mp\\">
            Options +Indexes +Includes +FollowSymLinks +MultiViews
            AllowOverride All
            Require local
        </Directory>
    </VirtualHost>
    Nachtrag: So funktioniert es auch und ist angenehmer zu lesen:

    Code:
    <VirtualHost *:80>
        ServerName MP
        DocumentRoot "//notebook/F/PHPWorkspace/www"
        <Directory  "//notebook/F/PHPWorkspace/www/mp/">
            Options +Indexes +Includes +FollowSymLinks +MultiViews
            AllowOverride All
            Require local
        </Directory>
    </VirtualHost>
    Analog dazu muss auch die httpd.conf nach dem gleichen Schreibweise angepasst werden.
    Der Dienst darf nicht über das Systemkonte gehen sondern über den User der auf dieses Netzwerk Zugriff hat.
    Der ganze Zirkus deshalb da meine Entwicklungsumgebung in einer VM ist und die Projektverzeichnisse auf der Hostmaschine liegen die über das Netzwerk erreichbar sind.

    Kommentar


    • #17
      Grundsätzlich scheint es zu funktionieren, und würde für ein Produktiv-System wahrscheinlich auch funktionieren, doch leider sind für die Entwicklungsumgebung weitere Probleme aufgetaucht so dass ich wieder zurück rudern muss auf lokales DocumentRoot.
      PHPStrom meckert das die Projektfiles nun auf ein Netzlaufwerk sind und dadurch kann er sie nicht überwachen und es sei langsamer. Es ist tatsächlich spürbar langsamer obwohl das Lokale- und das Netzlaufwerk jeweils schnelle SSDs sind. Der Umweg über das Netzwerk brems schon spürbar. Auch gab es Problem beim ausführen direkt aus PHPStorm.

      Nur für denjenigen der nicht den kompletten Thread gelesen hat: Ich habe eine leistungsfähigen Laptop auf dem VM-Ware Workstation 15 installiert ist. Das Host und Gast Betriebssystem ist jeweils Win10. In einer VM habe ich den WampServer, PHPStorm und ein paar Browser für die Entwicklung installiert. Der WampServer ist also in der VM c:\wamp64 installiert. Ich wollte das DokumentRoot außerhalb der VM auf ein freigegebenes Laufwerk welcher sich auf dem Host selbst befindet auslagern.

      Kommentar


      • #18
        Warum muss PHPStorm in der VM laufen? Kannst du das nicht einfach auf der Host-Maschine verwenden?

        Kommentar


        • #19
          Gerade für die Entwicklung sind VMs perfekt. Ich kann SnapShots erstellen oder gar die komplette VM Klonen und irgendetwas ausprobieren. Danach einfach die VM löschen oder das SnapShot löschen und fertig.
          Um nur ein Beispiel zu nennen: Ich habe mehrere VMs auf denen Chrome und das PlugIn xDebug installiert ist. Eines Tages war bei einer VM das PopUp-Menu fast nicht mehr sichtbar. Ich habe viele Stunden danach gesucht was denn die Ursache sein könnte. Irgendwann hatten alle Installationen das gleiche Problem. Es ist nicht wirklich ein Problem denn um den Debug zu aktivieren muss ich auf den ersten Button klicken, ist nicht wirklich tragisch, ärgerlich ist es schon. Gestern hatte ich die Nase voll und habe einfach eine neue VM angelegt. Vor jeder Installation habe ich ein SnapShot gemacht und immer das das PopUp anzeigen lassen ob es denn noch da wäre. Natürlich hatte ich alles installiert und das PopUp war immer sichtbar. In VMWare gibt es die VM-Ware Tools die man eigentlich immer installiert, das ist Standard. Und genau die verursachen das Problem! Ich habe das SnapShot zurückgesetzt, das PopUp war wieder sichtbar und dann habe ich die Tools wieder installiert. Und schon hatte ich die Ursache. In diesem Fall hat es sogar gereicht die Tools zu deinstallieren damit das PopUp wieder sichtbar wird. Ohne die Tools kann man aber nicht leben. Da ich jetzt die Ursache kennen ist mir das sowas von Egal. Ich habe die VM zwar noch aber nach dem Testen kann ich die VL löschen und mein Produktiv-System ist davon nicht betroffen da es auf einer anderen VM liegt. Das ist ein gewaltiger Vorteil beliebig viele VMs=Maschinen zu haben.


          2020-03-20_091629.png

          Kommentar


          • #20
            Zitat von R1100 Beitrag anzeigen
            Gerade für die Entwicklung sind VMs perfekt. Ich kann SnapShots erstellen oder gar die komplette VM Klonen und irgendetwas ausprobieren. Danach einfach die VM löschen oder das SnapShot löschen und fertig.
            Ja, aber was hat da die IDE drin verloren?

            Kommentar


            • #21
              Damit eben alle Werkzeuge die benötigt werden in einem System sind. Ich komme leider nicht drauf wie du vorgehen würdest. Du meinst die IDE incl. Project files auf der Host-Maschine und was sollte dann in der VM laufen? VM würde so keinen Sinn machen.

              Kommentar


              • #22
                Zitat von R1100 Beitrag anzeigen
                Damit eben alle Werkzeuge die benötigt werden in einem System sind. Ich komme leider nicht drauf wie du vorgehen würdest. Du meinst die IDE incl. Project files auf der Host-Maschine und was sollte dann in der VM laufen? VM würde so keinen Sinn machen.
                Die VM stellt die Laufzeitumgebung für die Anwendung zur Verfügung. Also Webserver, Datenbankserver, usw. Nicht mehr und nicht weniger.

                Wenns dir darum geht historische Stände der Anwendung zur Verfügung zu haben, dafür gibts Versionierungssysteme wie Git, SVN, usw.

                Kommentar


                • #23
                  Ah, ich verstehe. Git habe ich natürlich auch im Einsatz. Ich bin bis jetzt recht gut damit gefahren innerhalb der VM zu arbeiten. Aktuell wollte ich Wamp von 3.1.7 auf 3.2.0 hochziehen. Das neue twig release möchte php 7.3.*. Jetzt habe ich die Instruktionen von Wamp gelesen. Ein Update ist nicht einfach machbar. Man muss auf einiges achten. Das Risiko meine Entwicklungsumgebung zu beschädigen wollte ich nicht eingehen. Somit habe ich eine neue VM hergenommen und alles neu installiert. Dabei ist meine Entwicklungsumgebung absolut save da sie in einer anderen VM ist. Ich hätte auch eine snapShot der VM machen können und anhand der Wamp Anleitung das Update durchziehen. Da ich das Problem mit dem Crome xDebug untersuchen wollte, hab eich mich für die neue VM entschieden.
                  Alles hat eben seine Vor- und Nachteile.

                  Kommentar


                  • #24
                    Also ehrlich gesagt, wenn man schon eine VM verwendet, dann würde ich gleich Linux verwenden. Windows ist da eher suboptimal, da gefühlt 99% aller PHP-Produktivumgebungen unter Linux laufen. Und die Entwicklungsumgebung sollte immer der Produktivumgebung ähneln (Betriebssystem, Software-Versionen, usw.).

                    Mal davon abgesehen, dass Linux auch wesentlich ressourcenschonender ist als so ein Windows-Klotz in einer VM. Außerdem braucht ja jede Windows-Installation eine Lizenz, was höhere Kosten bedeutet. Vor allem Window Server Intallationen. Und ein "normale" Windows (also 7, Vista, 10) hat IMHO auf einer Serverinstallation nichts verloren.

                    Kommentar

                    Lädt...
                    X