Технологический консалтинг и разработка ПО
142,03
рейтинг
18 ноября 2014 в 18:26

Разработка → Теоретический минимум *nix-based-систем для WebDev-падавана tutorial



Помни: сила рыцаря-джедая — это сила Вселенной.
Но помни: гнев, страх — это всё ведет на темную сторону Силы.
Как только ты сделаешь первый шаг по темному пути,
ты уже не сможешь с него свернуть…


Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.



Для любителей пруфов — welcome.

Т. ч. в нашем ремесле без знания *nix-систем никак. Давайте проведем экскурс в мир *nix и поймем, какими знаниями должен обладать юный падаван.

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

1-й юниорский

Начнем с самых азов — забудьте про GUI, только консоль, только хардкор ^_^!


Несколько красивых консолей в xmonad для повышения мотивации.

Наше приключение начинаем с того, что надо добраться до консоли (в случае SSH-подключения мы там будем сразу). Кстати, если вы windows user, вам поможет волшебная программка putty.

Если же вы уже в линуксе и вы его поставили, верю, что сможете найти там консоль и как в нее попасть. Если же нет, вот мануал на примере ubuntu с самыми популярными DWM. Там же найдете описание базовых команд консоли. Рассмотрим сей список поподробнее и немного сгруппируем.

Давайте посмотрим на структуру файловой системы.

Да, не пугайтесь, привычных C: и D: тут нету, всё идет от корня (/).



/ Корневая директория, содержащая всю файловую иерархию.
/bin/ Основные системные утилиты, необходимые и в однопользовательском режиме, и при обычной работе всем пользователям (cat, ls, cp).
/boot/ Загрузочные файлы (в том числе, файлы загрузчика, ядро и т. д.). Часто выносится в отдельный раздел.
/dev/ Основные файлы устройств системы (например, физические устройства: sata-винчестеры /dev/sda, видеокамеры или TV-тюнеры /dev/video или псевдоустройства, например, «черные дыры» /dev/null, /dev/zero).
/etc/ Общесистемные конфигурационные файлы и файлы конфигурации установленных программ (имя происходит от et cetera).
/home/ Содержит домашние директории пользователей, которые, в свою очередь, содержат персональные настройки и данные пользователя. Часто размещается на отдельном разделе.
/lib/ Основные библиотеки, необходимые для работы программ из /bin/ и /sbin/.
/media/ Точки монтирования для сменных носителей (CD-ROM, DVD-ROM, flash-диски).
/opt/ Дополнительное ПО.
/proc/ Виртуальная файловая система, представляющая состояние ядра операционной системы и запущенных процессов в виде каталогов файлов.
/root/ Домашняя директория пользователя root.
/sbin/ Основные системные программы для администрирования и настройки системы, например, init, iptables, ifconfig.
/tmp/ Временные файлы (см. также /var/tmp).
/usr/ Вторичная иерархия для данных пользователя; содержит большинство пользовательских приложений и утилит, используемых в многопользовательском режиме. Может быть смонтирована по сети только для чтения и быть общей для нескольких машин.
/var/ Изменяемые файлы: файлы регистрации (log-файлы), временные почтовые файлы, файлы спулеров.
/var/cache/ Данные кэша приложений. Сюда скачиваются пакеты перед установкой в систему, здесь же они какое-то время хранятся.
/var/lib/ Информация о состоянии. Постоянные данные, изменяемые программами в процессе работы (базы данных, метаданные пакетного менеджера и т. п.).
/var/log/ Различные файлы регистрации (log-файлы).
/var/www/ Директория веб-сервера Apache, всё, что находится внутри, транслируется им в интернет (конфигурация по умолчанию)


Теперь мы узнали, как выглядит файловая система *nix.

Потом рекомендую узнать, как перемещаться в пространстве (cdwww.linfo.org/cd.html), создавать файлы (touchwww.linfo.org/touch.html) редактировать и удалять тоже (понять шутку про sudo rm -rf / — настойчиво рекомендую загуглить тем, кто не в курсе), познакомиться, как работает консольный текстовый редактор (например, Nano) — да-да, не надо пугать новичков Vim и Emacs. Еще есть симпатичный вариант mcedit.


Nano


MCEdit

Чип и Дейл спешат на помощь! В любой непонятной ситуации вводите man %commandName%, и восхитительная утилита man в *nix-системах вам расскажет как работает та или иная команда (программа) в bash.
Если вы потерялись в файловой системе, поможет команда pwd.

Теперь давайте обозначим еще некоторые особенности этого семейства OS.

*nix-системы отличаются регистрозависимостью т. е. file.txt и File.txt — разные файлы. И директории /uploads и /Uploads — тоже разные директории.

Еще несколько важных отличий:

  • Разные слеши Win — Backslash “\”; *nix — Slash “/”



  • Символы переноса строки Win — “\r\n — CRLF”; *nix — “\n — CR”; mac — “\r — LF” статья по теме: en.wikipedia.org/wiki/Newline


В PHP-разработке для ликвидации этих проблем кроссплатформености рекомендуется использовать PHP_EOL для новой строки в консоли и DIRECTORY_SEPARATOR для правильных слешей.

В контексте обсуждения файловой системы и фич linux давайте рассмотрим интересную фичу — симлинки (symlinks). Если объяснить по-простому — это ярлыки, как в всем известной windows, только тут ярлык может быть и на другой сервер, и на директорию, и на файл. Отличие от ярлыков в windows в том, что тут ярлыки используют не только на рабочем столе, а во всей файловой системе. По поводу этого есть хорошая статья на вики en.wikipedia.org/wiki/Symbolic_link и немного синтаксиса с вики debian вдогонку: wiki.debian.org/SymLink.

Почему многие developer-ы любят *nix-системы? Да потому что они стандартизированы системой стандарта POSIX, что их все роднит и помогает спокойно мигрировать из одной стандартизированной OS в другую (и разработчику, и юзеру. Тема раскрыта тут: en.wikipedia.org/wiki/POSIX.

Продолжаем знакомство.

Основное отличие *nix-систем — их многопользовательский подход. Из этого следует логический вывод: если есть много пользователей, надо разграничивать их сферы влияния. Один из основных инструментов для этого — права к файлам и директориям.

Обозначения прав идут в буквенном или цифровом формате.

Увидеть права мы можем через команды ls -l или ls -la, а поменять — через chmod.


Нашел потрясающую картинку, которая объясняет всю суть происходящего.

Добавлю, что в жизни веб-разработчика всегда нужно помнить о правах в linux, поскольку имеет место обыденная ситуация: разрабатывали под windows, задеплоили и внезапно (!) ничего не работает. В целом ничего страшного в них нету, но keep in mind.

P. S. Советую хорошо разобраться в этом моменте, поскольку ставить 777 на весь проект тоже не очень секьюрно.

Для пользователей системы существует режим стандартных правил для создаваемых ими файлов — umask. От него зависит, с какими правами будут создаваться файлы этого пользователя по умолчанию.
Почитать здесь: ru.wikipedia.org/wiki/Umask.

Я вскользь упомянул о наличии пользователей и групп в *nix-системах, но еще есть административный пользователь — root.
Root-юзер помогает вам делать многое: инсталлить софт, маунтить (https://help.ubuntu.com/community/Mount) разделы, разруливать права на файлы и папки где вашего обычного юзера не хватает, и т. п.

Для этого есть волшебная команда sudo. Более подробно предлагаю ознакомиться здесь: help.ubuntu.ru/wiki.

Под рутом надо быть очень аккуратными. Особенно на лайв-серверах. Особенно удаляя что-то через консоль.

Раз уж мы вспомнили о лайв-серверах, у них бывает такое свойство — заканчивается память.

Сначала проверяем, что у нас с ОЗУ, для этого подойдет top/htop.



Давайте также вспомним замечательную тулзу — ps. Она выводит отчет о работающих процессах. Удобна еще и несколькими триками:

  • Удобно пользоваться конвейером и утилитой less для пролистывания выводимой информации с помощью кнопок «вверх» и «вниз», например, ps aux | less.
  • С помощью утилиты grep удобно искать и выводить только нужные процессы, например, ps aux | grep node.


Для проверки, сколько свободного места у нас на харде, есть команды: df -h и df –k.

Если проблема в ОЗУ, смотрим, что у нас потребляет больше, чем надо, и делаем kill, или же, если это нужные процессы, — думаем дальше :).

Если же заканчиваются ресурсы харда и нечего удалить, на помощь приходят архиваторы. Основной архиватор в мире linux — tar. Вот небольшой гайд по сабжу, которого в повседневной жизни вам должно хватить с головой: help.ubuntu.ru/wiki/tar.

Стоит добавить, что в консоли есть варианты работы с несколькими программами одновременно — утилита GNU Screen: help.ubuntu.ru/wiki/screen.

В целом на этом можно и закончить первую степень посвящения, но обрадую немного тех, кто очень боится консоли: есть консольный 2-панельный классический файловый менеджер — Midnight commander.



Продолжим рубрикой «Что делать не надо» :).
  1. Не знаешь, зачем оно и как работает — не удаляй!
  2. Увидел файл или папку, которые начинаются с точечки — тем более не удаляй ^_^!


Это dotfiles — спрятанные файлы, просто по ls их не видно, можно увидеть через ls –la. Зачастую это системные файлы или файлы программ (иногда — настройки). И тут тоже вики хорошо раскрывает тему: en.wikipedia.org/wiki/Hidden_file_and_hidden_directory.

2-й юниорский


Первый юниорский нам поможет сделать что-то, но для повседневных задач web-developer’а этого мало, так что давайте пойдем дальше осваивать уровень, которого нам хватит для резолва ежедневных задач.

Первое, о чём надо упомянуть на этом уровне — пакетный менеджер aptitude (разбираем на примере ubuntu, да и в целом debian-based systems).
С его помощью можем устанавливать и удалять программы в й системе, подробнее рекомендую почитать, как говорится, на сайте производителя: help.ubuntu.ru/wiki/apt.

Следующая повседневная задача — установка lamp (linux apache php mysql)-сервера.



Вы не поверите, но после установки сервера на Windows в Ubuntu это делать просто и приятно, буквально в несколько команд: help.ubuntu.com/community/ApacheMySQLPHP

Конечно же, нам пригодятся Virtual Hosts. Файл хостов находится по адресу /etc/hosts, а хосты надо редактировать под рутом.

Пришло время упомянуть базовые команды Apache.

Включаем модули в apache, в том числе, модуль PHP (если ставим руками) — a2enmod %moduleName%.
Рестарт сервера — sudo service apache2 restart.

Вернемся к хостам. В apache, да и в nginx система хостов не очень сложная, но, как показывает практика, лучше рассказать, чтобы не видеть потом огромные и ужасные httpd.conf/nginx.conf.

Хосты, которые настроены и существуют (но не факт, что включены!) лежат отдельными файликами в папке /etc/apache2/sites-available. А хосты, которые используются и активны в данный момент, лежат симлинками в папке /etc/apache2/sites-enabled.



In real life выглядит все так: мы создаем файл конфига для нового хоста в sites-available, потом командой a2ensite %hostName% apache создает симлинк в папке sites-enabled, тем самым активируя хост. Обратная процедура — a2dissite.

Когда вы делаете это руками или просто пишете в файл основнового конфига, где-то плачет один котик, ну, или собачка — кому кого больше жаль :).

Ещё распространенная задача — поднять https. Хороший мануал здесь:
help.ubuntu.ru/wiki/apache_%D0%B8_https.


Картинка, обьясняющая суть того, зачем нам https.

Если вас всё ещё терзает вопрос зачем эта вся секьюрность, советую почитать на тему секьюрности для разработчиков хороший мануал: www.owasp.org/index.php/PHP_Security_Cheat_Sheet — тут на примере PHP, но многое актуально для всех Web разработчиков.

Также при работе с lamp старайтесь закрывать использование exec (выполнение команд в консоли OS через php) www.php.net/manual/ru/function.exec.php.

На уровне php это потенциальный пробел в вашей защите.

Добавлю часто встречающуюся задачу — закрытие сервера для незалогиненных пользователей методами веб-сервера, как на этом скрине.



Сделать так очень просто через htpasswd, вот пример: doc.norang.ca/apache-basic-auth.html.

Пришло время упомянуть о базах данных. В нашем юниорском забеге будем рассматривать MySql. В целом по вопросам Database Administration написано очень много книг и очень многое появляется с опытом, но некоторые базовые вещи просто необходимы.

Первое — конфиг живет по адресу /etc/mysql/my.cnf, заходить в гости, как обычно, под рутом.

Перезапустить «моську» можно командой sudo service mysql restart.

Если вы что-то не то сделали с правами своего рута или просто потеряли пароль рута от mysql, сбросить его и задать новый можно командой sudo dpkg-reconfigure mysql-server-5.5 (или 5.6), в общем, подставите нужную версию :).

Перейдем к следующему животрепещущему вопросу в жизни веб-девелопера:

Хоббит SQL-дампы — туда и обратно.
Для бекапа базы в sql-файл используется прекрасная команда mysqldump со следующим синтаксисом:

mysqldump —opt -u [uname] -p[pass] [dbname] > [backupfile.sql]
[uname] Имя юзера
[pass] Пароль (Будьте внимательны между параметром p и паролем нет пробела)
[dbname] Название нашей базы
[backupfile.sql] Как мы называем файл дампа (можно так же указать путь к нему если вы не в той папке где хотите создать его)
[--opt] Дополнительные опции
Пример: mysqldump -u root -p Tutorials > tut_backup.sql

  • add-drop-table — добавляет в дамп DROP TABLE перед CREATE TABLE.
  • no-data — дампит только таблицы без контента.
  • add-locks — добавляет LOCK TABLES и UNLOCK TABLES в дамп.


А если база большая и VPN-коннект не самый быстрый, можно сразу сжать в архив наш дамп следующей командой:

mysqldump -u [uname] -p[pass] [dbname] | gzip -9 > [backupfile.sql.gz]

Теперь давайте разберем накатку базы (условие: базы не существует, накатка с нуля).
Основной синтаксис будет такой:

mysql -u [uname] -p[pass] [db_to_restore] < [backupfile.sql]

Следуя нашему примеру, получаем что-то в духе:
mysql -u root -p Tutorials < tut_backup.sql

А если мы таки запаковались в архив, будет так:

gunzip < [backupfile.sql.gz] | mysql -u [uname] -p[pass] [dbname]

Если накатываем базу не с нуля, а она уже создана, есть другая команда:

mysqlimport -u [uname] -p[pass] [dbname] [backupfile.sql]

С архивом по аналогии.

Эту прекрасную шпаргалку по дампам взял отсюда: webcheatsheet.com/sql/mysql_backup_restore.php.

Следующий важный момент в MySQL — права Grants. «Моська» у нас многопользовательская, если есть много пользователей, значит, права свои у них будут — life is cruel :). Советую о них почитать. Самая распространенная задача — открыть юзеру вход не с локалхоста Она решается следующим образом:

Удаляем строку bind-address 127.0.0.1 из главного конфига.
Потом выполняем следующие команды:

~# mysql -u root mysql -p
mysql> GRANT ALL PRIVILEGES ON database.* TO username@»%» IDENTIFIED BY ‘password’ WITH GRANT OPTION;
mysql> exit;
~# mysqladmin -u root -p flush-privileges


Здесь database — база данных, к которой назначаем права пользователю username с паролем password, а % указывает на то, что пользователь может прийти не только с локалхоста, а откуда угодно.

Эти команды на респекте собрал отсюда: saradmin.ru/?p=792.

Node JS мы также можем установить в две команды “sudo apt-get install nodejs” “sudo apt-get install npm”.
Node-проекты заводить обычно легко, что-то в духе node server.js
Хочу поделиться интересной тулзой nodemon — она дает нам намного больше возможностей в области девелопмента на nodeJS, т. к. следит за изменениями в файлах проекта и перезапускает сервер автоматически:
nodemon.io



Далее рекомендую ознакомиться с работой в консоли самых популярных в мире web development VCS — git и svn. Мануалов по ним очень много разных и хороших, думаю, подберете на свой вкус ;).



По теме VCS может понадобится мануал по генерации SSH-ключей для Git: help.github.com/articles/generating-ssh-keys.
Поделюсь интересным триком: если вам нужен live-вывод изменяющихся файлов в консоль (зачастую логи) — используйте команду tail –f, например, (tail -f /var/log/apache2/error.log).

3-й юниорский


Вот мы и подобрались к 3-му юниорскому! Довольно неплохой уровень, после которого уже идет хардкор, но тут еще ничего страшного тоже нет, всё достаточно интересно и весело.

Начинается опыт реального подъема серверов с фулстеком (lamp + ftp(s) + ssh) по ситуации, с прикруткой CI-систем, также интересен опыт подъёма хостинг-систем типа Virtualmin / WebMin.
В реальной эксплуатации не рекомендуется оставлять чистый ftp-сервер, лучше использовать SFTP (ftp over ssh) для секьюрности.


help.ubuntu.ru/wiki/webmin

Интересен опыт с nginx вместо apache — отличный мануал можно найти тут: help.ubuntu.ru/wiki/nginx-phpfpm.
Также дополню хорошей онлайн-тулзой которая трансформирует rewrite-правила из apache в формат nginx: winginx.com/ru/htaccess.

Еще на этом уровне не нужно бояться BASH-скриптинга и знать, что такое sed и grep. Основы рекомендую почитать тут:
help.ubuntu.com/community/Beginners/BashScripting

Хороший левел — знание vim или emacs. Очень холиварная тема, но не упомянуть нельзя.

Если временами вы очень скучаете по некоторым программам из windows, или у вас есть специфичный софт, который все-таки нужен и аналог никак не можете найти (что же такое страшное вам нужно?!), есть wine — wine is not an emulator.


IE В Ubuntu («работает» еще веселее, чем в нативной среде обитания).

Это действительно не эмулятор windows, а набор библиотек, чтобы заводить виндовые програмы под никсами. Есть база данных, какие программы и даже игры поддерживает wine — appdb.winehq.org.

Давайте затронем сетевую тему, первым в гостем нашей студии станет netstat (network statistics), встречайте! Тулза поможет нам посмотреть статистику сетевой активности, открытые порты, наши сетевые интерфейсы и т. д.

Базовая информация:
en.wikipedia.org/wiki/Netstat

Примеры использования: putty.org.ru/articles/netstat-linux-examples.html.
Спасибо, netstat.
Следующий наш гость — Iptables, встречайте!
IPtables — стандартный интерфейс управления работой брандмауэра.
Базовая информация: en.wikipedia.org/wiki/Iptables
Спасибо, Iptables!

И в заключение сетевой темы давайте позовем нашего хедлайнера — nmap. Поприветсвуем гостя nmap!

Очень известная утилита в области сетевой безопасности, видеть ее мы могли в десятках фильмов ;).


nmap.org/movies

Базовая информация: en.wikipedia.org/wiki/Nmap#Bibliography.
Примеры использования: habrahabr.ru/post/88064.

Спасибо nmap за столь увлекательную историю и счастливое детство.

Предлагаю перейти на немного advanced level MySQL-тюнинга — PIMP MY DB.



В живых проектах очень важно держать MySQL в боевом состоянии, настроенным на максимальную стабильность и производительность, в противном случае получаем очень неприятный bottleneck.

DB Tuning можно условно разделить на две части:

Оптимизация структуры базы данных (нормализация/денормализация, foreign keys, indexes и т. д.).
Оптимизация настроек сервера DB.
Про оптимизацию структуры базы данных написано немало гайдов и мануалов, и серебряной пули тут не существует. Всегда смотрим на конкретный проект и индивидуальные проблемы. Explain в помощь :).

Советую почитать:

ruhighload.com/post habrahabr.ru/post/108418
В вопросе тюнинга и оптимизации настроек DB очень преуспела компания Percona — MySQL-форк. Рекомендую познакомиться с ними поближе.
Из базового набора для тюнинга у них есть тулкит и визард настройки вашего сервера.

www.percona.com/software/percona-toolkit
tools.percona.com/wizard

Также известная тулза — mysqltuner (http://mysqltuner.com/).
Для тестирования нагрузки на MySQL есть интересная тулза sysbench. Почитать про нее можно тут: ruhighload.com/index.php/2010/03/05/sysbench-testiruem-proizvoditelnost-mysql.

Добавим в наше приключение немного стильных, модных и молодежных технологий — CI.



Wiki: Непрерывная интеграция (англ. Continuous Integration) — практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.

На практике это очень удобный софт, позволяющий собирать билды, прогонять все виды тестов, делать минификацию js/css, следить за качеством кода, деплоить, итп.

Самые популярные — Jenkins, Travis, TeamCity.

en.wikipedia.org/wiki/Jenkins_(software)
en.wikipedia.org/wiki/Travis_CI
ru.wikipedia.org/wiki/TeamCity

P. S. Клевая тулза Guake —выезжающая консолько в стиле quake.
Автор: @DataArt
DataArt
рейтинг 142,03
Технологический консалтинг и разработка ПО

Комментарии (36)

  • –10
    Спасибо! Получился отличный сборник советов.
    • +16
      По-моему, получился отличный сборник вредных советов, как делать не нужно. Через строчку — либо откровенно устаревшая информация, либо какие-то недомоловки, либо просто ошибки. Куча картинок не совсем в тему, опять же — большей частью — сильно устаревших. Структура подачи материала (а особенно позиционирование его как какого-то законченного «теоретического минимума») — мягко говоря — странная. Ну какой, нафиг, «тюнинг MySQL» для человека, который, судя по началу, чуть ли не компьютер видит второй-третий раз в жизни?

      Статья, может быть, была бы уместна году эдак в 2000, но мир-то несколько изменился. Человек, которому надо просто поставить WordPress или еще какую-нибудь CMSку, в 99% случаев не будет это все разворачивать вручную — он либо пойдет на hosted-решение, либо на какой-нибудь облачный Amazon / DigitalOcean / etc — и развернет все там из веб-интерфейса в 2-3 клика…
      • +3
        Я бы не сказал, что Percona, Jenkins и другие упомянутые инструменты — это прошлый век. И с чего вы взяли, что статья ориентирована именно на тех, кто ставит WordPress в два клика? По такой логике можно совсем ничего не писать о том, что под капотом.
        • 0
          Про Percona и Jenkins в статье — по 3-4 строчки про каждый. Зачем это туда вообще включили — совершенно непонятно. Ну чем человеку поможет CI, если в нормальном мире CI работает в связке с хоть какой-то VCS (про связку в статье почему-то скромно умолчали), генерируемые результаты работы в виде тестов должны светиться в какой-то общей системы организации работы (баг-, таск-трекере, в идеале — в автоматизированном виде в code review), а артифакты — деплоиться через какую-то систему управления конфигурациями (про что в статье тоже скромно умолчали). В итоге что? Система, на входе у которой неизвестно что, на выходе — неизвестно что, но зато «на практике это очень удобный софт».

          Но это в целом все относительно ерунда, куда большие претензии к началу статьи и к сильно устаревшим объяснениям основ.
  • +11
    странная статья…
    windows вполне умеет симлинки и хардлинки делать…
    про многопользовательский режим написано так, как будто в windows его нет и права на файлы не выставить…
    wine и специфический софт как раз таки почти не совместим…

    почему apache, а не nginx?
    давать совет по поводу GRANT ALL для пользователя, который может залогиниться с любого хоста — очень плохая штука…

    Вообщем не понятно зачем это.
    • +3
      И, кстати, раз уж LAMP, то где must-have тула phpmyadmin? Для начинающего без нее вообще никуда, кмк.
  • 0
    возможно автор хотел написать PUMP MY DB, а не PIMP?
  • +7
    Даешь nginx!
  • +8
    Интересно, несерьёзная статья с аккаунта серьезной компании.
    Как учебник, не пойдет — не структурировано, состоит из своих мыслей о программах и ссылок на них.
    Пойдет, как подборка ссылок.

    Картинка с деревом порадовала, особенно /mnt/zip/music.
    Послушаю-ка я мадонну, где там дискетка с её песнями? :)
    • +1
      Картинка с деревом была, видимо, повзаимствована автором с codeidol.com/img/fedora-4/0672327074/graphics/05fig05_alt.gif — это из статьи про Fedora Core 4, 2005 год. /mnt/zip и X11R6 тогда еще могли быть, да %)
  • –8
    в нашем ремесле без знания *nix-систем никак

    Красноглазики выходят на связь. Слишком категоричный тон, как по мне. Что не отменяет того факта, что знание *nix-систем в целом это неплохо, а в частности полезно специалисту в той или иной области.
  • +7
    Win понимает оба слэша.
    • 0
      Еще один повод минусануть: впервые вижу, чтобы «мускул» называли «моськой»)
      • +8
        минусануть мой коммент, а не статью, забыл уточнить, пардоньте)
  • +4
    Статья хороша, но устарела по существу лет эдак на семь если не более.

    Сейчас в *nix на порядок все интереснее и закрученнее, а окружение в общем и целом каждый строит под себя и в подавляющем большинстве случаев оно разительно отличается от описанного.

    Например, для типичного Rails-разработчика тот же *nix предстает в немного другом свете нежели для PHP-разрботчика, всю жизнь клепающего сайты на виртуальных хостингах под готовыми джумла-перссами.

    Совсем недавно попадалась на глаза очень годная настольная книжка из разряда «галопом по Европам *nix» где предисловие как раз несет свет знаний «зачем оно все нужно и примерно как работает», вот очень пожалел что как раз под рукой лет 7-8 назад такой не было. Парадигма там строилась очень правильно — «в *nix, всё есть файл». И только осознав это, начинаешь действительно на ином уровне работать с системой, в этом как мне кажется ключевая фишка никсов, а уже остальное — уточнения да расширения.
    • +4
      как раз закралось подозрение, что изначально статья или заготовка была написана давно… значит не только у меня.
    • +1
      Не могли бы вы в общих чертах описать, что устарело и как оно сейчас (ну или ссылкой киньте)? Хотел бы проверить свою закостенелость =)
      • +1
        По сути актуальна сейчас только первая часть, дальше идет вкусовщина, ориентированная только на PHP-разработчика с определенными «стандартными» задачами.

        Все что касается настройки — это только от задач зависит. Почитайте по разработке на Node JS — там одно окружение, по Rails — там совершенно другое. Точно также, если вы в принципе не работаете с MySQL, то он вам и не нужен, можете смело пропускать всю эту часть, равно как и LAMP-ы со всякими XAMP-ами, MAMP-ами и прочими Денверами тоже лучше пропускать, т.к. все необходимое окружение лучше ставить ручками — так опыта больше и понимания что где отвалилось и почему может не работать.

        И это я не говорю про очень модный нынче подход работы через изолированные контейнеры по принципу Docker, Vagrant и прочими удобствами.

        Просто в 2014-м году, работа программиста под *nix — это намного более широкий и менее однородный комплекс действий/мер/подходов нежели описано в статье.

        P.S. foxmuldercp комментом ниже продолжил мысль этого коммента
        • +3
          И это я не говорю про очень модный нынче подход работы через изолированные контейнеры по принципу Docker, Vagrant и прочими удобствами.

          Просто в 2014-м году, работа программиста под *nix — это намного более широкий и менее однородный комплекс действий/мер/подходов нежели описано в статье.


          Если бы более широкий.
          Нынче модно делать curl github/repo/install-script | sudo bash, чтобы оно «само поставилось».
          Каждый раз, как вижу такой туториал
          image
  • +7
    Перепечатано с xakep.ru образца конца двадцатого/начала двадцать первого веков?
  • 0
    Еще весь нормальный ентерпрайз давно использует postgresql или оракл, в зависимости от задач, nginx, ну и openvz в качестве виртуализации, а так же активно смотрят на docker.
    А использование webmin считается плохим тоном. он спасает разве что в вариантах, когда на телефоне/планшете есть только броузер и что-то реально поломалось а вы черт знает где и у инженера сапорта нет на это прав. И то, я бы такое выставлял не напрямую, а по впн хотя бы.
    А еще надо бы рассказать про монтирование удалённых файловых систем для бекапов куда-то вне хоста.
    И совет про експерименты в виртуалке недоступной наружу — а то мало ли что откроете или забудете и натворят делов плохие дядьки
  • 0
    Интересно, что за WM используется и в каком окружении на скрине с nmap?
  • +7
    Ощущение, что автора заставили написать статью, вот он и выкрутился. Запахло лабораторными из университета.
    • +1
      Судя по всему да. Не знаю, нубство это (что было бы простительно) или профанация.
  • +5
    Apache лишний.

    «Тюнинг БД» какое отношение имеет к «теоретическому минимуму»??? Кстати, в «максимуме» он тоже противопоказан!

    Не нашел виртуалки — хотя именно с них и надо начинать!

    Почему многие developer-ы любят *nix-системы? Да потому что они стандартизированы системой стандарта POSIX

    Нет. Не за posix, а за простоту, безопасность и надежность.

    Чувствую себя неловко из-за восклицательных знаков в моем комментарии. С одной стороны, автор проделал большую работу, с другой стороны — материал неполон, неверен и оттого очевидно вреден.
  • –5
    Материал хорош однозначно и автору спасибо. Статью не следует воспринимать как сборник догм или аксиом, скорее как путеводитель — что вообще есть, с чего начать и в каком направлении идти, если хочется что-то узнать.
  • +5
    Спасибо автору! Я ощутил себя где-то в начале двухтысячных. Ностальгия, прослезился.
  • +3
    vagrant up
    • 0
      А я думал
      … что точно не пройдёт модерацию:
      • статьи, ранее опубликованные где-либо;
      • +1
        вроде исключения для блогов компаний?
  • +1
    Хосты, которые настроены и существуют (но не факт, что включены!) лежат отдельными файликами в папке /etc/apache2/sites-available. А хосты, которые используются и активны в данный момент, лежат симлинками в папке /etc/apache2/sites-enabled.
    Когда вы делаете это руками или просто пишете в файл основнового конфига, где-то плачет один котик, ну, или собачка — кому кого больше жаль :).

    Ой ли?

    Во-первых, вы описываете просто «debian-way» настраивать Apache/nginx, а не что-то общепринятое и правильное. Просто в какой-то момент мейнтейнеры debian решили, что так удобнее и создали такую сложную структуру. На других системах, дистрибутивах и даже некоторых пакетах не из репозитория debian/ubuntu, а также в nginx и apache по умолчанию нет таких каталогов;

    Во-вторых, удобство такого подхода сомнительно, особенно когда речь идет всего о нескольких виртуальных серверах;

    В-третьих, до недавнего времени такой подход просто приводил к непредсказуемым результатам в случае nginx. Поскольку в отдельных случаях порядок следования блоков server в конфигурации имеет значение, а до версии 1.3.10 файлы включались в конфигурацию в произвольном порядке, так что с этим подходом можно было легко огрести проблем.
  • +1
    Символы переноса строки Win — “\r\n — CRLF”; *nix — “\n — CR”; mac — “\r — LF”


    Перепутали вы всё :) Да и отдельный вариант для Mac актуален только для тех, кто до сих пор пользуется классической Mac OS до 9 версии.

    *nix, включая OS X — \n (LF)
    Mac OS <=9 — \r (CR)
  • 0
    Падаван и без chroot/selinux/ids?! И ещё и в продакшен?! Или я чего-то не понимаю и это уже джедай-скилл?! В современном мире сервер падавана-по-этой-статье если и заведётся в паблике, то будет уложен школотой с вконтактика смеху ради. Со всем уважением к автору.
  • 0
    Начали неплохо. Заинтриговали. И дальше скатились в перечисление ссылок.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка