J'ai un Mac sur lequel je peux exécuter la version Leopard (10.5) ou Snow Leopard (10.6) d'OS X. Je l'utilise pour faire du développement/test Web avant de publier des fichiers sur mon hôte de production.
Sur l'hôte de production, la racine de documentation de mon site se trouve sous le répertoire personnel (par exemple/home/stimulatingpixels/public_html) et je voudrais dupliquer cet emplacement sur le Mac. Malheureusement, il s'agit d'un espace réservé caché et verrouillé sur le Mac qui ressemble à un lecteur monté sans rien assis à l'emplacement/home.
Je sais par expérience qu'il n'est pas judicieux de déplacer cela et de le déposer dans votre propre répertoire/home car les mises à niveau peuvent le faire effacer (et il n'est pas stocké dans la sauvegarde TimeMachine, en passant).
Donc, la question, est-il possible d'utiliser/home en toute sécurité sur un Mac Leopard ou Snow Leopard?
(Remarque: je me rends compte que c'est très spécifique à Mac et je le demanderai dans un forum Apple forum aussi. Je voulais juste demander ici en plus de couvrir toutes les bases.)
Mise à jour: Pour aider à décrire pourquoi je veux faire cela, en plus du site Web frontal, j'ai une série de scripts que j'aimerais également exécuter. L'un des principaux objectifs de pouvoir utiliser le répertoire/home (et plus précisément le même chemin depuis la racine des serveurs) est de pouvoir utiliser les mêmes chemins de sortie sur le mac de développement et être également utilisés sur le serveur de production. Je sais qu'il existe des moyens de contourner cela, mais je préfère ne pas avoir à y faire face. Le véritable objectif est que tous les fichiers du Mac de développement aient le même chemin d'accès depuis la racine/de l'arborescence de répertoires que le serveur de production.
Une autre mise à jour: L'autre raison que j'ai oublié de mentionner plus tôt pour cela est la configuration de chemins d'accès .htaccess lors de l'utilisation de l'authentification de base. Étant donné que ces chemins proviennent de la racine du système de fichiers au lieu de docroot du site Web, ils finissent par passer par "/ home" lorsque cela fait partie de l'arborescence.
REMARQUE: depuis 2015, je n'utilise plus ni ne recommande cette méthode. Au lieu de cela, j'utilise Vagrant pour configurer des machines virtuelles pour le développement et les tests. C'est gratuit, relativement facile et permet une meilleure adéquation de l'environnement de production. Il sépare complètement l'environnement de développement et vous pouvez en créer autant que vous le souhaitez. Fortement recommandé . Je laisse la réponse originale ci-dessous pour la postérité.
J'ai trouvé une réponse ici sur les Apple .
Afin de récupérer le /home
répertoire, modifiez le /etc/auto_master
classer et commenter (ou supprimer) la ligne avec /home
dedans. Vous devrez redémarrer après cela pour que la modification prenne effet (ou, selon le commentaire de nilbus, essayez d'exécuter Sudo automount -vc
). Cela fonctionne avec Mac OS X 10.5 (Leopard). Votre millage peut varier pour différentes versions, mais il devrait être similaire.
Comme indiqué sur ce billet de forum, vous devez également savoir que Time Machine exclut automatiquement le /home
répertoire et pas sauvegarder .
Une note d'avertissement, assurez-vous de sauvegarder votre /home
répertoire manuellement avant d'effectuer une mise à jour du système. Je crois qu'une des mises à jour que j'ai faites (de 10.6 à 10.7 par exemple) a effacé ce que j'ai stocké dans /home
sans avertissement. Je ne suis pas sûr à 100% que ce soit arrivé, mais c'est quelque chose à surveiller.
Je l'ai essayé sur Yosemite (OS X 10.10.1) le Sudo automount -vc
Ne fonctionnait pas, j'ai dû utiliser Sudo umount /home
.
Par conséquent, mon flux de travail serait:
# comment out line starting with /home Sudo vi "+g/^\/home/s/\//#\//" "+x" /etc/auto_master Sudo umount /home
# link actual home directory (/Users/<user>) to new 'home' (/home/<user>) ln -s $HOME /home/$USER
Assembler le tout à partir des conseils et astuces ci-dessus:
éditer /etc/auto_master
# commente la ligne avec /home
dedans.
remonter sur:
Sudo automount -vc
créer un lien logiciel vers le répertoire mac-ified:
Sudo ln -s $HOME /home/$USER
À ce stade, vos chemins doivent correspondre à vos chemins de production. env
vars pointera toujours vers /Users/xxxx
, mais tout ce que vous codez en dur dans un chemin dans votre .bashrc
- ou disons, dans ~/.pip/pip.conf
-- devrait être essentiellement équivalent. A travaillé pour moi.
re: "Le véritable objectif est que tous les fichiers du Mac de développement aient le même chemin d'accès depuis la racine/de l'arborescence de répertoires que le serveur de production."
En production, mon travail de déploiement peut se produire dans /opt/projects/projname
, je vais donc m'assurer que mon compte peut écrire dans /opt/projects
et partez de là. Je commencerais par faire quelque chose comme ça:
Sudo mkdir /opt/projects Sudo chown $USER /opt/projects mkdir /opt/projects/projname cd /opt/projects/projname
Avec LVM, je définirai une partition distincte pour /opt/
et y écrire des données d'application au lieu de $HOME
. Ensuite, je peux faire pousser le /opt
système de fichiers dans les cas où j'ai besoin de plus d'espace disque pour un projet (LVM est votre ami.)