Вопрос

У меня есть Mac, на котором я могу запустить либо версию OS X Leopard (10.5), либо версию OS X Snow Leopard (10.6).Я использую его для веб-разработки / тестирования перед публикацией файлов на моем производственном хостинге.

На рабочем хостинге корневой каталог doc моего сайта находится в домашнем каталоге (например/home/stimulatingpixels/public_html), и я хотел бы дублировать это местоположение на Mac.К сожалению, это скрытый и заблокированный заполнитель на Mac, который выглядит как подключенный диск, на котором ничего нет, расположенный в папке / home.

По опыту я знаю, что неразумно перемещать это и удалять в свой собственный каталог / home, потому что обновления могут привести к его удалению (и, кстати, оно не сохраняется в резервной копии TimeMachine).

Итак, вопрос: есть ли способ безопасно использовать / home на Mac либо Leopard, либо Snow Leopard?

(Примечание:Я понимаю, что это очень специфично для Mac, и я также задам этот вопрос на форуме Apple.Просто хотел спросить здесь в дополнение, чтобы охватить все основы.)

Обновить:Чтобы помочь описать, почему я хочу это сделать, в дополнение к интерфейсному веб-сайту у меня есть серия скриптов, которые я также хотел бы запустить.Одна из основных целей использования каталога / home (и, более конкретно, того же пути от корневого каталога сервера) заключается в том, чтобы можно было использовать те же пути вывода на компьютере Mac для разработки, что и на производственном сервере.Я знаю, что есть способы обойти это, но я бы предпочел не иметь с этим дела.Реальная цель состоит в том, чтобы все файлы на компьютере Mac для разработки имели тот же путь к файлу из / root дерева каталогов, что и рабочий сервер.

Еще одно Обновление:Другая причина, о которой я забыл упомянуть ранее, заключается в настройке путей .htaccess при использовании базовой аутентификации.Поскольку эти пути ведут из корня файловой системы, а не из docroot веб-сайта, они в конечном итоге проходят через "/ home", когда это часть дерева.

Это было полезно?

Решение

ПРИМЕЧАНИЕ:Начиная с 2015 года, я больше не использую и не рекомендую этот метод.Вместо этого я использую Бродяга настройка виртуальных машин для разработки и тестирования.Это бесплатно, относительно просто и позволяет лучше соответствовать производственной среде.Это полностью разделяет среду разработки, и вы можете создавать столько, сколько вам нужно. Настоятельно рекомендуется.Я оставляю оригинальный ответ ниже для потомков.


Я нашел ответ здесь, на форумах Apple.

Для того, чтобы вернуть себе /home каталог, отредактируйте /etc/auto_master файл и закомментируйте (или удалите) строку с /home в нем.После этого вам нужно будет перезагрузиться, чтобы изменение вступило в силу (или, согласно комментарию nilbus, попробуйте запустить sudo automount -vc).Это работает с Mac OS X 10.5 (Leopard).Ваш размер может отличаться для разных версий, но он должен быть одинаковым.

Как отмечалось в том сообщении на форуме, вы также должны знать, что Машина времени автоматически исключает /home каталог и не делает сделайте резервную копию.


Одно предупреждение, обязательно создайте резервную копию вашего /home каталогизируйте вручную перед выполнением обновления системы.Я полагаю, что одно из обновлений, которые я сделал (например, с 10.6 по 10.7), уничтожило то, что я сохранил в /home без предупреждения.Я не уверен на 100%, что именно это произошло, но это то, чего следует остерегаться.

Другие советы

Я попробовал это на Yosemite (OS X 10.10.1) в sudo automount -vc не сработало, мне пришлось использовать sudo umount /home.

Поэтому мой рабочий процесс был бы:

# 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

Собирая все это воедино с помощью приведенных выше советов:

  • Редактировать /etc/auto_master # закомментируйте строку с помощью /home в нем.

  • перемонтировать:

    sudo automount -vc

  • создайте программную ссылку на каталог mac-ified:

    sudo ln -s $HOME /home/$USER

На этом этапе ваши пути должны совпадать с вашими производственными путями. env переменные по-прежнему будут указывать на /Users/xxxx, но все , что вы жестко закодировали в пути в вашем .bashrc --или, скажем, в ~/.pip/pip.conf-- должно быть по существу эквивалентно.Сработало на меня.

ре: "Реальная цель состоит в том, чтобы все файлы на компьютере Mac для разработки имели тот же путь к файлу из / root дерева каталогов, что и на производственном сервере".

На производстве моя работа по развертыванию может выполняться в /opt/projects/projname, поэтому я просто удостоверюсь, что моя учетная запись может записывать в /opt/projects и идите оттуда.Я бы начал с того, что сделал что-то вроде этого:

sudo mkdir /opt/projects sudo chown $USER /opt/projects mkdir /opt/projects/projname cd /opt/projects/projname

С помощью LVM я установлю отдельный раздел для /opt/, и записывать туда данные приложения вместо $HOME.Тогда я смогу вырастить /opt файловая система в тех случаях, когда мне нужно больше места на диске для проекта (LVM - ваш друг).

Почему бы вам просто не запустить MAMP и не воспользоваться каталогом Sites?Вы можете разрабатывать с помощью localhost и просто иметь кучу псевдонимов для своих сайтов.Я не уверен, зачем вам конкретно нужно использовать домашний каталог.


Редактировать:Хорошо, я думаю, вы подходите к решению своей проблемы неправильным путем.

Если вас беспокоят HTML-пути, начинайте все с косой черты "/", которая по умолчанию будет относиться к домашней директории.

Если это ссылки в вашем PHP, то вам нужно создать глобальный (или аналогичный) и установить его в качестве корневого каталога вашего сайта.Затем вы можете ссылаться на все из глобального, и когда вы переводите сайт из dev в production, все, что вам нужно изменить, - это global.

Пытаться обходным путем разрабатывать из / home, потому что это больше похоже на производственный сервер, - плохая идея.

Установите MAMP, создайте глобальный где-нибудь высоко в иерархии и начните повторно ссылаться.В долгосрочной перспективе это будет меньше причинять боли.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top