Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>~/Sites/ Ordner (Verzeichnis für Apache) über iCloud synchronisieren?

~/Sites/ Ordner (Verzeichnis für Apache) über iCloud synchronisieren?

Stefab
Stefab29.08.2114:54
Hallo!

Im Prinzip sollte es ja möglich sein, dass ich den Ordner Benutzername/Sites/ über die iCloud synchron halte. Aktuell nervt es mich, da ich die einen Tests am iMac mache, die anderen am MacBook unterwegs und nachher ist natürlich alles über die Geräte verstreut.

Prinzipiell sollte das ja möglich sein, in dem ich den ganzen Ordner aufs iCloud Drive kopiere, alle wichtigen Files da rein, dann die lokalen Kopien lösche und dann auf jedem Gerät einen Symlink erstelle.

Soweit so gut, der vorbereitete Sites Ordner liegt am iCloud Drive. Nur hab ich jetzt das Problem, dass ich den Sites Ordner aus dem User-Verzeichnis nicht löschen kann!
Habe schon probiert, den Apache Server zu stoppen, aber es geht trotzdem nicht.

Irgendwie kann ich über Google auch nix brauchbares dazu finden. Hat jemand eine Idee, wie das (möglichst nicht übermäßig umständlich) funktionieren könnte?

Danke schon mal!
0

Kommentare

Stefab
Stefab29.08.2115:13
PS: Eine Notlösung wäre vielleicht erstmal nur einen Unterordner synchronisieren, ich schätze mal, da wird es keine Probleme geben.
Wäre aber deutlich praktischer, den ganzen Ordner synchron zu halten.

Einfacher wäre es wohl auch gewesen, den Symlink zu erstellen, bevor man das Hauptverzeichnis vom Apache dahin leitet, aber das alles wieder zurück bauen, ist schon einiges an Aufwand, hoffe darauf, dass es einen einfacheren Weg gibt.
0
marm29.08.2115:15
Ich verstehe zwar nur Bahnhof, was Du da vorhast, aber ich kann mir nicht vorstellen, dass iCloud Drive grundsätzlich geeignet ist, mehrere Geräte zuverlässig und berechenbar synchron zu halten.
Selbst der Apple Support meinte mal am Telefon, dass iCloud Drive doch nur für Datenaustausch sei. Mir waren Daten verloren gegangen - nur eine Tabelle - aber seitdem meide ich iCloud Drive.
0
FelixE29.08.2116:13
@marm: zur Zuverlässigkeit von iCloud Drive möchte ich widersprechen. Seit Jahren sind auf MacMini und MacBook die Ordner Dokumente und Schreibtisch über iCloud Drive synchronisiert. Das funktioniert bei mir ohne erinnerliche Verluste von Dateien oder Dateiversionen. Die Synchronisierung erfolgt im WLAN zuverlässig innerhalb von Sekunden.
+3
marm29.08.2116:30
FelixE
@marm: zur Zuverlässigkeit von iCloud Drive möchte ich widersprechen.
Du hast dann bestimmt "Mac-Speicher optimieren" deaktiviert. Das nimmt aber in Kauf, dass auf allen Rechnern immer alles synchronisiert ist. Ein Teilsynchronierung ist nur möglich im festen Glauben, dass Apple weiß, welche Dateien wichtig sind - denn Ordner selbst Festlegen ist unmöglich. Deswegen verstehe ich nicht, was Stefab da vorhat:
Stefab
Soweit so gut, der vorbereitete Sites Ordner liegt am iCloud Drive. Nur hab ich jetzt das Problem, dass ich den Sites Ordner aus dem User-Verzeichnis nicht löschen kann!
Stefab
PS: Eine Notlösung wäre vielleicht erstmal nur einen Unterordner synchronisieren, ich schätze mal, da wird es keine Probleme geben.
0
john
john29.08.2116:53
wieso hast du nicht einen richtigen webserver mit einer richtigen staging umgebung wie normale menschen?
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
+2
FelixE29.08.2117:50
@marm: “Mac-Speicher optimieren” für Dateien gibt es bereits eine Weile nicht mehr. Funktioniert trotzdem fast immer perfekt. Länger unbenutzte Dateien werden vollständig nur noch in iCloud gespeichert. Sie sind dann durch ein Wölkchen-Symbol im Finder gekennzeichnet. Sie werden trotzdem von Spotlight gefunden. Die Einschränkung “fast perfekt” ist systemimmanent: fällt mir nach einem Jahr ein, eine raw-Datei nochmals anzufassen muss die erst runtergeladen werden.
+1
marm29.08.2118:07
FelixE
@marm: “Mac-Speicher optimieren” für Dateien gibt es bereits eine Weile nicht mehr.
Doch durchaus, unter Systemsteuerung/Apple-ID.
Vielleicht war es an dieser Stelle arg verkürzt der iCloud Mängel vorzuwerfen. Etwas präziser war bei mir das Problem, dass Time Machine kein Backup der iCloud-Dateien anlegt, wenn die Dateien nicht vollständig geladen werden. Bei kleinen Mengen kein Problem; wer aber hunderte GB in der iCloud hat und den Mac "Speicher optimieren" lässt, um Speicherplatz zu sparen, hat kein Backup.
0
jk35029.08.2122:06
@marm: Wenn mann die Daten in 'iCloud Drive' ablegt werden sie mit der Cloud synchronisiert und sind auch auf dem Backup vorhanden.
PS: Aber was Stefab genau möchte Verstehe ich auch nicht.
0
FelixE29.08.2122:25
@marm: danke für den Hinweis!
0
Stefab
Stefab29.08.2123:05
Ich versuche es etwas genauer zu erklären:

Man kann im Prinzip jeden beliebigen Ordner über iCloud Drive synchronisieren, mit folgendem Trick:

Man verschiebt den Ordner aufs iCloud Drive (egal ob Unterordner oder sonst wo) und erstellt dann einen Symlink zu der originalen Stelle, wo der Ordner war (das dann auf all seinen Macs), dann hat man den Ordner mit allen Funktionen an der alten Stelle, aber überall synchron.

Das Problem ist jetzt, das System lässt mich den "Sites" Ordner im Benutzer-Verzeichnis nicht löschen, damit ich ihn mit dem Symlink ersetzen könnte.

Das liegt daran, dass ich den macOS internen Apache-Server aktiviert habe und mit der Bearbeitung von mehreren Config-Dateien auf ~/Sites als Hauptverzeichnis umgeleitet.
In früheren Systemversionen war das der Standardordner für den lokalen Webserver (aufrufbar dann über localhost im Browser).
Man konnte es sogar direkt in den Systemeinstellungen über das Web-sharing aktivieren.

Bei neueren macOS Version ist das Standardverzeichnis irgendwo platziert, wo es IMHO eher weniger nützlich ist.

Es wäre halt sehr praktisch, wenn jemand einen Trick weiß (am besten jemand, der sich gut im Terminal auskennt), wie ich den ~/Sites/ Ordner jetzt löschen kann, um ihn mit dem Symlink zu ersetzen.

Mir fällt zwar die Möglichkeit ein, die ganzen Config-Dateien wieder auf Originalzustand zurück zu stellen (das wäre aber ziemlich umständlich) und die Frage wäre dann auch, wenn man es wieder auf den Sites-Ordner zurück stellt ob dann das Symlink nicht evt. überschrieben wird.

Apache Webserver stoppen hilft leider nicht, der Ordner lässt sich trotzdem nicht löschen, es heißt immer, dass er wird vom System benötigt wird.
0
Stefab
Stefab29.08.2123:08
PS: Mit Unterordnern würde so schon gehen, also zB. ~/Sites/php/ was im Browser dann localhost/php/ wäre.
Aber ist halt auch nicht so ganz optimal, wesentlich praktischer wäre der ganze Ordner von Webserver.
0
Nebula
Nebula30.08.2102:24
Evtl. kann man Sites löschen, indem man SIP deaktivieren oder über's Terminal.
„»Wir werden alle sterben« – Albert Einstein“
0
Stefab
Stefab30.08.2123:32
Nebula: denke mit SIP wird es nichts zu tun haben, übers Terminal löschen wäre vermutlich irgendwie möglich (mit irgendeinem force delete o.ä).
Vielleicht find ich da ja selbst was raus, wenn es hier niemand weiß. Dachte es sind hier auch einige Terminal/Unix-Experten unterwegs?
Zur Not sollte es schon gehen, die config Dateien vom Apache Webserver wieder auf Standard zurück bauen (hatte gehofft, mir das zu ersparen), dann sollte sich der Ordner löschen lassen, dann Symlink dorthin und hoffen, dass das nicht überschrieben wird, wenn ich’s wieder so konfiguriere, dass das root-Verzeichnis vom Webserver wieder auf den Sites Ordner verweist.
0
Stefab
Stefab30.08.2123:38
john
wieso hast du nicht einen richtigen webserver mit einer richtigen staging umgebung wie normale menschen?
Einen richtigen Webserver gibt es natürlich auch.
Es geht mir darum, verschiedene kleinere Scripts mal auf die Schnelle überall testen zu können (zur Not auch ohne Internet-Verbindung). Da ist der lokale Webserver IMHO noch am praktischsten.

PS: Es funktioniert eh ganz brauchbar, nur sind diese kleinen Testprojekte aktuell noch kreuz und quer auf beiden Macs verteilt, das würde ich gerne noch „beheben“
0
Weia
Weia31.08.2102:58
Stefab
denke mit SIP wird es nichts zu tun haben
Denken ist Glücksache; warum probierst Du es nicht einfach aus, statt endlos Dein Hirn zu wälzen? Das ist doch nur ein Aufwand von ein paar Minuten.

Keine Ahnung, wie Du zu Deiner Auffassung kommst; es ist doch gerade die Aufgabe von SIP, von Apple angelegte Ordner vor dem Löschen durch Nutzer zu schützen. (Ich erinnere allerdings nicht, ob es den Ordner Sites noch gab, als es SIP schon gab …)
übers Terminal löschen wäre vermutlich irgendwie möglich (mit irgendeinem force delete o.ä)
Das irgendeine force delete heißt
rm -Rf ~/Sites
Aber wie gesagt, ich gehe davon aus, dass SIP Dein Problem ist.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
almdudi
almdudi31.08.2104:46
Weia
übers Terminal löschen wäre vermutlich irgendwie möglich (mit irgendeinem force delete o.ä)
Das irgendeine force delete heißt
rm -Rf ~/Sites

In unxioiden Systemen wird nix deletet, da wird ReMoved, und zwar Rekursiv und tatsächlich in diesem Fall mit force (also ohne Rückfrage, Datei für Datei).
Da sollte man aber peinlich darauf achten, nur den/die richtigen Ordner auszuwählen, da gibt es keinen Papierkorb zum Zurückholen.
0
Stefab
Stefab31.08.2110:49
Weia: Danke, der Befehl war's, hat soweit mal funktioniert - der Ordner ist durch einen Symlink ersetzt! Bei Terminal-Befehlen, besonders, wenn die etwas löschen sollen, bin ich lieber übervorsichtig und frag lieber nach, anstatt was aus dem Internet zu kopieren (vor allem, wenn man nicht wirklich weiß, was die Parameter tun, usw.)

almdudi: Kein Problem, die Daten sind (mehrfach) wo anders gesichert.

Leider scheint es eher sinnlos zu sein, gebe aber noch nicht auf . Der Server dürfte zwar auf die richtigen Ordner verweisen, aber irgendwie passen dem Webserver die Zugriffsrechte nicht: "Error 403: Forbidden You don't have permission to access this resource." - wahrscheinlich kann man das auch nur übers Terminal lösen, sehe im Finder keine Unterschiede bei den Rechten.
Ich schau mal, was ich dazu finde, vielleicht hat jemand einen Tipp? Was hier steht, könnte evt. Sinn ergeben, blicke aber nicht wirklich durch:
0
Stefab
Stefab31.08.2111:20
Ok, ich habe eine Lösung, bin nicht sicher, ob die optimal ist, sollte aber absolut ausreichen, und zwar das untere auf der Seite:

Das obere, die "stuepfnick.conf" anzulegen, das ganze reingeschrieben, was dort steht, und abspeichern hat leider gar nix gebracht (u.a. "AllowOverride All" und "FollowSymLinks"), evt. müsste man die Rechte der .config Datei noch ändern, wie angegeben? (weiß aber die genau Systax nicht, irgendwas mit "chmod" vermute ich).

Wie auch immer, der untere Teil hat dann funktioniert, also den Apache WebUser von _www auf meinen Benutzeraccount zu ändern.

Die obere Lösung wäre vielleicht sauberer/eleganter, wenn's funktioniert, da localhost von nem anderen User aufgerufen dann auch funktionieren sollte, aber ich sag mal, das brauche ich eh nicht.

Super, passt! Jetzt das ganze noch am MacBook machen, dann ist es geschafft! Danke nochmals an alle, besonders Weia!
0
Stefab
Stefab31.08.2111:44
Kleiner Nachtrag: Am MacBook mit Big Sur war minimal schwerer, den Ordner zu löschen, musste den Benutzer abmelden und mich (z.B.) als admin einloggen, damit das löschen funktionierte. (evt. hätte es so auch über den Finder funktioniert?) Naja, auch egal, Hauptsache es passt jetzt.

Frage mich nur noch, ob es irgendwelche Vor- oder Nachteile hat, wenn man diese <username>.config anlegt bzw. ob es überhaupt einen Unterschied macht? (wobei <username> natürlich für den jeweiligen username steht )

Aber was soll's, Hauptsache es funktioniert und ich habe meinen kleineren web-code "Experimente" auf beiden Macs synchronisiert! Danke nochmals an alle!
0
Stefab
Stefab31.08.2112:15
Weia: Warum ich ziemlich sicher war, dass es nix mit SIP zu tun hat: Der Ordner entsteht ja erst, wenn man den DocumentRoot Folder auf die ~/Sites/ umleitet (evt. musste man den sogar selbst anlegen, weiß ich nicht mehr)

Und eine Sache will ich noch los werden (zwar nicht sonderlich wichtig, würde es aber gerne verstehen):
Hab die Umleitung von DocumentRoot Folder in nach der (oder sehr ähnlicher) Anleitung gemacht:
Irgendwie scheint es nix zu bringen, wenn man die "<username>.config" entsprechend anlegt, wie die ganzen anderen Änderungen, es scheint vollkommen zu reichen, die DocumentRoot directory in der "httpd.config" zu ändern (bzw. PHP aktivieren, wenn mans braucht).
Hatte am MacBook sogar vergessen in der <username>.config den <username> auf den echten zu ändern, da stand immer noch <username> und hat trotzdem funktioniert.
Am iMac (Mojave) war sowieso nur die httpd.config entsprechend leicht angepasst hab da jetzt sicherheitshalber trotzdem auch alles gemacht, laut Anleitung, auch wenn ich keine Ahnung habe, wofür das gut sein soll.

PS: Schreibe zwar jetzt nur mit mir selbst, aber vielleicht interessiert es ja jemanden, der/die ähnliche Dinge auch mal braucht, und dann kann man es finden.
0
Weia
Weia31.08.2113:22
Stefab
Warum ich ziemlich sicher war, dass es nix mit SIP zu tun hat: Der Ordner entsteht ja erst, wenn man den DocumentRoot Folder auf die ~/Sites/ umleitet (evt. musste man den sogar selbst anlegen, weiß ich nicht mehr)
Den musstest Du sicher selbst anlegen. Dadurch, dass in einer Unix-Konfigurationsdatei ein bestimmter Pfad spezifiziert wird, wird der in aller Regel nicht automatisch angelegt. Es gibt nach dem Start des entsprechenden Unix-Programms einfach eine Fehlermeldung, wenn es den Pfad dann nicht gibt.

Aber vor längerer Zeit war Sites ja einer der Ordner, die Apple in jedem Nutzerkonto angelegt hat, deswegen hätte das schon sein können (wie geschrieben erinnerte ich nicht mehr, ob es Sites noch gab, als SIP aufkam).

Aber wie sich jetzt herausgestellt hat, lässt sich der Ordner ja problemlos löschen (vermutlich hätte es nicht mal des f für force bedurft) und wird nur dadurch „geschützt“, dass der Finder das Löschen verweigert. Ich war einfach nicht auf die Idee gekommen, dass, als Du schriebst, der Ordner könne nicht gelöscht werden, eigentlich nur meintest, der Ordner könne im Finder nicht gelöscht werden. Es gibt viele Dinge, die technisch problemlos möglich, aber im Finder nicht durchführbar sind, weil Apple das nicht will.

Wenn Du die Kommandozeile scheust, hilft in solchen Fällen vielleicht auch eines der Finder-Alternativprogramme?
Und eine Sache will ich noch los werden (zwar nicht sonderlich wichtig, würde es aber gerne verstehen):
Hab die Umleitung von DocumentRoot Folder in nach der (oder sehr ähnlicher) Anleitung gemacht:
Da gibt es nicht viel zu verstehen; der Autor versteht ganz offenkundig selbst nicht, was er schreibt.

DocumentRoot in httpd.conf legt fest, wo apache die Dateien erwartet, die er anzeigen soll. Wenn Du die auf Deinen Sites-Ordner setzt, ist damit alles erledigt.

Nur wird apache normalerweise ja auf Servern mit vielen verschiedenen Nutzern eingesetzt, deren Daten-Ordner natürlich voneinander getrennt sein müssen. Und da greifen dann die user.conf-Dateien, die für jeden Nutzer ein eigenes, getrenntes Wurzelverzeichnis spezifizieren.

Da macOS ja ebenfalls ein Mehrbenutzersystem ist, ist das auch da der saubere Weg, und als Apple Sites noch vorkonfiguriert hat, wurde auch automatisch für jeden Nutzer eine user.conf-Datei angelegt.
Irgendwie scheint es nix zu bringen, wenn man die "<username>.config" entsprechend anlegt
Doch, das erzielt exakt den erwünschten Effekt. Wenn es das bei Dir nicht tut, ist irgendwo ein fehlerhafter Eintrag.
es scheint vollkommen zu reichen, die DocumentRoot directory in der "httpd.config" zu ändern
Ja, logisch, das ist schließlich eine alternative Möglichkeit, den gewünschten Ordner auszuwählen. Nur halt mit dem (prinzipiellen) Nachteil, dass das dann für alle Nutzer Deines Macs gleichermaßen gilt.

Beides zu machen, DocumentRoot zu ändern und eine user.conf[/b]-Datei anzulegen, ist jedenfalls doppelgemoppelt und vollkommen unsinnig. Wer so etwas vorschlägt, hat ganz offenkundig selbst keinerlei Plan.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+1
Stefab
Stefab31.08.2114:44
Weia: Danke, das ist mal eine gut verständliche Erklärung.

Ja, vermutlich dann am besten mal probieren, ob es immer noch funktioniert, wenn man die document root wieder auf den standard-wert setzt?

Bzw. was soll man da reinschreiben, wenn das über die user.config files gelöst wird?
0
Weia
Weia31.08.2114:57
Stefab
Ja, vermutlich dann am besten mal probieren, ob es immer noch funktioniert, wenn man die document root wieder auf den standard-wert setzt?
Es wäre architektonisch „sauberer“, aber wenn Du Deinen Mac mit nur einem Nutzer/Nutzerkonto betreibst, ist es pragmatisch Jacke wie Hose bzw. ist die DocumentRoot-Lösung sogar besser, weil Du dir in der Browser-URL das ~username am Ende sparst (also einfach http://localhost statt http://localhost/~username schreiben kannst).
Bzw. was soll man da reinschreiben, wenn das über die user.config files gelöst wird?
Apple schreibt (bzw. schrieb) da "/Library/WebServer/Documents" rein und in dem Ordner war dann eine HTML-Datei mit dem Inhalt It Works!

Du müsstest erstmal schauen, ob es den Ordner bei Dir überhaupt noch gibt, aber irgendwie ist die ganze Übung etwas sinnbefreit. Wenn nur Du den Mac nutzt, lass es einfach bei DocumentRoot.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Weia
Weia31.08.2115:08
Stefab
Bzw. was soll man da reinschreiben, wenn das über die user.config files gelöst wird?
Nur zur Sicherheit, weil Du das hier konsistent falsch schreibst: die Dinger heißen username.conf!
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
0
Stefab
Stefab31.08.2117:07
Weia: Ok, jetzt funktioniert beides, also http://localhost und http://localhost/~username/ - werde ich wohl so lassen, bzw. falls mal ein neuer User kommt, die entsprechende Datei anlegen.
(und ja, habe eh die Datei nach dem Schema <username>.conf benannt - hab es nur hier falsch geschrieben)
Zumindest kenne ich mich jetzt einigermaßen aus, wie das ganze funktioniert!

Herzlichen Dank nochmals! 👍
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.