Задача: монтировать nfs-ресурсы в макоси.

В принципе, в макоси уже встроена поддержка nfs и соответствующие сетевые ресурсы можно монтировать через Finder (⌘K), однако чтобы это работало для обычного юзера, требуется некоторое шаманство на стороне linux-сервера.

И заодно важный момент: я монтирую только на чтение, поскольку если разрешить запись, то макось загадит диск своими служебными файлами.

На линукс-машине в /etc/exports прописываем что-то вроде:

/home/user/downloads 192.168.13.12(ro,sync,no_subtree_check,insecure)

Здесь адрес 192.168.13.12 — это айпишник макосной машины. После чего в Finder стандартным образом (через ⌘K или меню Go → Connect to Server...) монтируем ресурс, адрес указываем в виде nfs://nfs-server.name/home/user/downloads.

Опция insecure как раз и нужна, чтобы можно было простым юзером монтировать, без неё будет выдаваться маловразумительная ошибка.

Ещё одна вредная и очень трудноуловимая проблема связана с макосной интерпретаций кодирования «составных» букв в именах файлов, например, «й» или «ё», или «ü». Если имя файла (или вообще где-то в пути до файла встречается) содержит такую букву, то файл просто не откроется, причём с невразумительной ошибкой типа “The application can’t be found.” Я в детали не хочу вдаваться, можете сами погуглить по ключевым словам “mac os x nfc nfd unicode”.

Решение достаточно простое: нужно изменить опции монтирования nfs-ресурсов по умолчанию, для этого добавьте в файл /etc/nfs.conf такую строчку:

nfs.client.mount.options = nfc

Теперь можно монтировать через Finder и всё будет в порядке.

Ну и команда для всяких тестов, вдруг пригодится:

/sbin/mount_nfs -v 192.168.13.12:/home/user/downloads /Volumes/test

Здесь описаны мои текущие настройки и дополнительные программы для расширения функциональности макоси на макбуке.

Обновлено 2015-06-13: теперь всё рассказывается про Yosemite.

Стандартная конфигурация лично мне не особо нравится, плюс выведенными в интерфейс крутилками также не всё можно настроить, поэтому пришлось гуглить и экспериментировать. Чтобы ничего не забылось, традиционно сливаю всё накопленное в один большой пост со скриншотами, который буду держать в актуальном состоянии. Всё описанное касается версии Mac OS X Yosemite (10.10) с английским интерфейсом.

Как использовать curl для отладки HTTP, то есть для отправки на сервер HTTP-запросов. У меня потребности небольшие, поэтому здесь только конкретно нужные мне команды. Оформлено всё традиционно: описание задачи, решение, описание решения.

Отправить GET-запрос и показать ответ вместе с заголовками¶

curl -Gi http://google.com

Опция -G указывает использовать HTTP GET, опция -i — включить заголовки в вывод.

Обновлено 2016-06-26: инструкция изменена для El Capitan

В стандартной конфигурации (речь дальше пойдёт про Mac OS 10.9 Mavericks и выше) при использовании ssh-ключей во встроенном ssh-клиенте парольная фраза запрашивается через макосный security-фреймворк (и стандартный диалог запроса пароля соответственно). После первого ввода пароля запускается ssh-agent и при дальнейших вызовах ssh или git c этим ключом пароль больше не запрашивается.

На мой взгляд, такая схема слишком небезопасная и нужно какое-то разумное ограниченное время жизни «запомненного» ключа в агенте, например, пара минут. Cделать это штатными средствами через диалоги/настройки невозможно, однако можно изменить файл запуска агента и выставить там нужное время жизни ключа в агенте. В результате практически при каждой попытке использовать любой ключ будет выскакивать диалог запроса парольной фразы.

Homebrew — клёвая штука, однако она крайне небезопасная в обычном режиме установки — файлы ставятся в каталог /usr/local с правами текущего пользователя, поэтому, если в систему пролезет зловред, он легко сможет изменить очень важные для безопасности файлы в этом каталоге. В homebrew faq очень не советуют ставить brew через sudo, однако там неявно имеется в виду установка с правами суперюзера. Так действительно жить нельзя, поэтому пойдём другим путём — выделим для brew отдельного юзера и отдельную группу, и все операции по установке будем проводить через него.

Когда-то я писал о личном опыте использвания Sublime Text 2, а после выхода Sublime Text 3 решил начать новую статью, ориентированную именно на версию 3 с небольшим акцентом на миграцию с 2 на 3.

Sublime Text — это профессиональный программерский текстовый редактор. Он завоевал очень большую популярность благодаря проработанности интерфейса, кроссплатформенности, удобной и простой расширяемости плагинами. Мои впечатления со времён написания первой статьи не особо изменились, поэтому я второй раз их переписывать не буду.