Vagrant. Die richtige Config fürs LAMP?

[Meta.Morph]

Servus,
Aktuell treibt mich zwar ein spezifisches "Problem" jedoch wollte ich dann doch noch etwas allgemeiner bleiben.

In der Ausbildung haben wir ein Debian-Server mit Apache, msql und PHP erstellt und in Vagrant geladen - natürlich unter Windows. Jetzt sollen wir das zu hause nachvollziehen.

Ich arbeite aber mit Arch. Gut, ich hab mich belesen und hab nun ein funktionierendes Setup gefunden - denke ich zumindest...

Nun zur Frage:
Um Ordner zu teilen, wird häufig diese Zeile Vorgeschlagen:

config.vm.synced_folder "../data", "/vagrant_data"

So weit, so nett. Funktioniert bei mir nur nicht.
Nach langer Recherche, habe ich diese Lösung gefunden:

config.vm.synced_folder "www/", "/var/www", type: "nfs", mount_options: ["vers=4,tcp"]

Es funktioniert tatsächlich. Jedoch bekomme ich während der Apache Installation einen Fehler ausgeworfen:

Sub-process /usr/bin/dpkg returned an error code (1)

Diesen Fehler konnte ich bereits selbst lösen: ohne die Sync-Funktion läuft die Installation durch.

Nun bin ich verunsichert. Wie soll ich meine Ordner am besten in Zukunft synchronisieren? Oder wird meine Methode keine Fehler mehr produzieren (also im laufenden Betrieb)?
Eine andere Frage: welche Ordner könnte man - sinnigerweise - noch Synchronisieren?

Vagrant.configure("2") do |config|
  #config.vm.box_check_update = false
  config.vm.box = "debian/bullseye64"
  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.network "forwarded_port", guest: 3306, host: 3306
  config.ssh.insert_key = true

   #während der Installation deaktivieren
  config.vm.synced_folder "www/", "/var/www", type: "nfs", mount_options: ["vers=4,tcp"]

  config.vm.provider :libvirt do |libvirt|
    libvirt.host = "bullseye"
    libvirt.uri = "qemu+unix:///system"
    libvirt.memory = 2048
    libvirt.cpus = 4
    libvirt.cpuset = '1-4,^3,6'
    libvirt.cputopology :sockets => '2', :cores => '2', :threads => '1'
  end

  config.vm.provision "shell", inline: <<-SHELL
    export DEBIAN_FRONTEND=noninteractive
    bash /vagrant/vagrant.sh
  SHELL

end

#! /bin/bash
function phpInstall()
{
    while read var
    do
        IFS=" "
        set $var
        unset IFS
        apt-get install -y $1
    done < $1
}

apt-get update
apt-get -y install apt-transport-https lsb-release ca-certificates curl
curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg
sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
apt-get update && apt-get upgrade -y

apt-cache search php8.1 > php81
phpInstall php81

apt-get install -y apache2 mariadb-server net-tools wget curl git gpg vim zip unzip fish ranger htop

Gibt es an meinen Einstellungen irgendetwas auszusetzen?
Mal abgesehen davon, das ich sämtliche PHP Module Installiere (ist das Sinnvoll? Kann es mir nicht richtig vorstellen). Das ist die Vorgabe unseres Dozenten...

Freue mich auf Feedback!

 

[patrick888]

Diesen Fehler konnte ich bereits selbst lösen: ohne die Sync-Funktion läuft die Installation durch.

/var/www wird zu grösster Wahrscheinlichkeit vom apache Paket verwaltet, sprich soll während der Installation angelegt werden. Wenn es jetzt dummerweise noch einen UID mismatch deines Shares gibt, NFS gibt UID / GID deines hosts, also deiner Arch Installation, weiter, dann ist klar warum apt keine Freude damit hat.

Ich würde dir raten den mount stattdessen in ein anderes Verzeichnis zeigen zu lassen, /mnt/share z.B.. Je nach Verwendungszweck kannst du dann mit Symlinks arbeiten. Das Thema der Rechte musst du dir so oder so anschauen.

Die PHP Installation mit dem Schreiben der Paketnamen in eine Datei, der Übergabe an eine Funktion, die den IFS manipuliert ... kann man machen, kommt mir aber sehr umständlich vor. Das wäre eine Alternative:

apt install $(apt-cache search php8.1 |awk '{print $1}' |tr "\n" " ")

Eine statt 12 Zeilen Code. Zum Lernzweck eine Funktion mit Übergabeparameter zu haben und ein bisschen bash gespiele, okay, fair enough. Aber "Produktionscode" ist das nicht

Deine Vermutung bzgl. der Module und der Sinnhaftigkeit ist korrekt. Dass du alle Module willst, ist praktisch ausgeschlossen. Gerade die ganzen PECL Extensions die Ondrej im Repo bereitstellt, machen nur situativ Sinn. Du wirst z.B. selten (oder nie) Setups haben, die sowohl pecl-memcache, pecl-memcached und dann auch pecl-redis nutzen. 2 Key Value Stores und 3 Klassen dafür .. das ist nicht sehr realitätsbezogen. Die Liste liesse sich weiterführen. Es vereinfacht die Handhabung, aber auch da: "Produktionscode" ist das nicht.