Comments 82
А вот объясните мне почему на слабеньком сервачке не обойтись одним nginx, без apache?
потому что запустить бложик на вордпрессе запустить через FastCGI будет сложнее чем поставить апач.
Ну и не все знают что так можно, кмк.
Ну и не все знают что так можно, кмк.
По моему куда проще взять на digital ocean мини инстанс за 5$ и выбрать образ с вордпресс, Все руководство будет две кнопки нажать и ввести код на два бесплатных месяца.
Без инструкции — да, сложнее. Но уж если автор дает настолько подробную инструкцию… в чем разница-то?
Чо сложного-то? Трабл может возникнуть (и, собственно, возникнет) только с ЧПУ, и тот решается плагином со стороны Вордпресса.
В остальном же, натягивается точно так же.
В остальном же, натягивается точно так же.
Нет. php-fpm ставится так же легко как и просто php. Если у человека не хватает соображалки что бы прописать найденный на офф сайте конфиг — то ему нечего серваки настраивать.
Никаких проблем в настройки через FastCGI нет, но существует ли аналог типа mod_itk под nginx? Если да, то приведите пример, возьму его себе на вооружение.
И почему не поставить PHP 5.5 и забыть о eAccelerator
Пока нет необходимости в переходе на PHP 5.5, если необходимо именно 5.5 версия, то замените php5 на php55.
Насчет eAccelerator, можете его не ставить, вам решать нужен он или нет.
Насчет eAccelerator, можете его не ставить, вам решать нужен он или нет.
Почему нет? Более быстрая работа, меньшее потребление памяти, опкеш из коробки и новые фичи, которые, впрочем, использовать никто не застявляет это недостаточный аргумент?
Вы же не себе ставите, а людям рассказываете. В чём проблема ставить актуальную стабильную версию, а не устаревшую? Тут уже PHP 5.6 rc1 вышел, а вы 5.4 ставите…
К тому же если ваш код нормально работает с 5.4 при переходе на 5.5 ничего не сломается с вероятностью 99,999%.
В чём профит?
Вы же не себе ставите, а людям рассказываете. В чём проблема ставить актуальную стабильную версию, а не устаревшую? Тут уже PHP 5.6 rc1 вышел, а вы 5.4 ставите…
К тому же если ваш код нормально работает с 5.4 при переходе на 5.5 ничего не сломается с вероятностью 99,999%.
В чём профит?
А ещё не нужно будет ставить кучу dev пакетов и править конфиги, из которых состоит пол статьи.
Вообще настройка не безопасная (судя по тому что вы предлагаете пароль от рута прямо в команде в терминале вводить), а самая обычная.
И ftp нафиг не нужен, можно обойтись sftp, что, смею предположить, будет безопаснее, и даже быстрее.
В целом — ну и нагородили же вы…
Вообще настройка не безопасная (судя по тому что вы предлагаете пароль от рута прямо в команде в терминале вводить), а самая обычная.
И ftp нафиг не нужен, можно обойтись sftp, что, смею предположить, будет безопаснее, и даже быстрее.
В целом — ну и нагородили же вы…
Напишите статью лучше с php5.6 опкешем и т.д.
То что описано здесь гарантированно защищает и работает, а главное это все проверено опытом, а то что вы говорите это всё мелочи, главное схема, не нравится php 5.4 (хотя они идет по умолчанию при вызове apt-get install php, думаю не зря так!), ставьте 5.6, не нравится eAccelerator не ставите его, а ставите опкеш или другой кеш, проблем никаких. Сразу скажу SFTP работать не будет т.к. у юзера нет консоли! (уже сколько раз писал это в комментах), поэтому только выбор у вас FTP или другой клиент который работает без консоли.
То что описано здесь гарантированно защищает и работает, а главное это все проверено опытом, а то что вы говорите это всё мелочи, главное схема, не нравится php 5.4 (хотя они идет по умолчанию при вызове apt-get install php, думаю не зря так!), ставьте 5.6, не нравится eAccelerator не ставите его, а ставите опкеш или другой кеш, проблем никаких. Сразу скажу SFTP работать не будет т.к. у юзера нет консоли! (уже сколько раз писал это в комментах), поэтому только выбор у вас FTP или другой клиент который работает без консоли.
1) Вы пишете статью по которой потом новички потом ещё 10 лет будут ставить всю эту муть, которая уже сегодня не нужна
2) Есть множество простых способов (намного проще ваших конфигов) которые позволяют открыть sftp и закрыть ssh, и для этого вообще ничего не нужно ставить
Сравнните сами:
Это и ставить, и настраивать, и поддерживать проще. А чем меньше компонентов — тем надежнее всё работает.
2) Есть множество простых способов (намного проще ваших конфигов) которые позволяют открыть sftp и закрыть ssh, и для этого вообще ничего не нужно ставить
Сравнните сами:
Apache 2.2 + PHP 5.4.4 + MySQL 5.5 + NGINX 1.2.1 + eAccelerator + memcached + vsftpd 3.0.2 + exim.
PHP 5.5 + MySQL 5.6 + NGINX 1.4 + memcached + exim.
Это и ставить, и настраивать, и поддерживать проще. А чем меньше компонентов — тем надежнее всё работает.
Не в компонентах дело, а в том, что безопасность для вас видимо ничего не значит. Ставьте свежий необкатанный софт, радуйтесь, что вы современный и в тренде, но только потом не удевляйтесь, почему вас сломали, а сосед Васька со старым софтом пулепробиваемый ;)
php 5.5 не настолько редко обновляемая и малоиспользуемая штука. То что пакет попал в стабильную ветку debian не означает ровным счетом ничего. 5.4 прекратят суппортить уже в марте следующего года, а без выхода обновлений, шансы что там найдут очередную дыру ничуть не уменьшаются.
Ага, небось Васька и OpenSSL обновлять не собирается) Пуленепробиваемый…
Если в официальных репозиториях есть пакет — он по определению не менее безопасен чем другие.
К тому же, если есть старая версия с известными уязвимостями, и новая где они исправлены, но потенциально могут быть другие — я выбираю второе.
Вы правда верите, что PHP 5.5 менее безопасная версия чем 5.4? Либо что Nginx 1.4 менее безопасен чем 1.2? Или MySQL 5.6 уязвима, а 5.5 нет?
Или, в конце концов, наличие eAccelerator и vsftpd более безопасно чем отсутствие этих пакетов?
Если в официальных репозиториях есть пакет — он по определению не менее безопасен чем другие.
К тому же, если есть старая версия с известными уязвимостями, и новая где они исправлены, но потенциально могут быть другие — я выбираю второе.
Вы правда верите, что PHP 5.5 менее безопасная версия чем 5.4? Либо что Nginx 1.4 менее безопасен чем 1.2? Или MySQL 5.6 уязвима, а 5.5 нет?
Или, в конце концов, наличие eAccelerator и vsftpd более безопасно чем отсутствие этих пакетов?
Решать вам, что уязвимо, а что нет, никто не уверен в версиях и в том, что в них появятся критические уязвимости.
А если и появятся, то тут уже никто не застрахован. Но я чисто из своего опыта не спешу обновляться, ибо следую правилу «работает — не трожь», а если вдруг появится какая уязвимость, то патч сделать не составит труда.
А если и появятся, то тут уже никто не застрахован. Но я чисто из своего опыта не спешу обновляться, ибо следую правилу «работает — не трожь», а если вдруг появится какая уязвимость, то патч сделать не составит труда.
opcache — дефолтный опкод кешер. Он идет с версии 5,5 вместе с php и рекомендуем к использованию. Что до дебиана — 5.5 уже можно спокойно ставить не опасаясь что он будет «менее секьюрным» чем 5,4.
По поводу SFTP — есть же WinSCP и прочие гуевые клиенты.
По поводу SFTP — есть же WinSCP и прочие гуевые клиенты.
а passenger?
Кстати вот я вижу настрийки FW, но не вижу в них разрешения ходить по SSH на сервер. Это бага или фича?
Мне нравится, как к этому вопросу подошли в Ubuntu. Есть вариант установки группы пакетов:
Ставит apache, php и MySql с зависимостями, а дальше уже по вкусу. Самое главное, что не нужно знать такого:
и для новичка процесс от «Мне нужно поднять сервер» до «Мой сайт работает» проходит очень быстро и безболезненно.
$ sudo apt-get install lamp-server^Ставит apache, php и MySql с зависимостями, а дальше уже по вкусу. Самое главное, что не нужно знать такого:
Затем одной командой ставим весь необходимый софт: apt-get install много букви для новичка процесс от «Мне нужно поднять сервер» до «Мой сайт работает» проходит очень быстро и безболезненно.
Классная статья — с удовольствием посмотрел, как настраивается удобный веб-сервер на очень ограниченной конфигурации (совсем недавно нечто похожее настраивал, правда, только nginx php-fpm под WP). Кое что для себя взял. Особенно интересна конфигурация iptables (в этом вопросе мне было очень сложно — найти толковый короткий конфиг достаточно затруднительно)
Хотя 256М RAM сегодня это очень мало — $10 за 4Gb Ram у fastVPS или 512M за $5 в DigitalOcean это очень даже не плохо.
Хотя 256М RAM сегодня это очень мало — $10 за 4Gb Ram у fastVPS или 512M за $5 в DigitalOcean это очень даже не плохо.
Разве eAccelerator не устарел как чёрт знает что?
Если для новичков, то неплохо бы еще и веб-панельку какую-нибудь, типа webmin.
Для данной конфигурации сервера (256 мб озу) webmin будет тяжелым, а так его можно поставить просто:
и добавить правило в iptables
Вот и вся установка webmin.
apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl apt-show-versions python
wget http://prdownloads.sourceforge.net/webadmin/webmin_1.690_all.deb
dpkg --install webmin_1.690_all.deb
и добавить правило в iptables
-A INPUT -p tcp --dport 10000 -j ACCEPT
Вот и вся установка webmin.
Отключаем опасные функции
disable_functions = exec,ini_get,ini_get_all,parse_ini_file
А чем не угодили ini_get и parse_ini_file? Последняя вообще не имеет отношения к php.ini и часто используется в CMS для парсинга config.ini и т.д…
Лучше настроить параметр в php.ini
open_basedir = /home/user/domains/name.ru/
А то загруженный через бложик wso даст дорогу ко всем папкам. Так же хорошо проверить файрвол, в wso в разделе Network включить любой порт и попробовать к нему присоединиться через netcat или puTTy (в режиме Raw) для получения командной строки для полного «разгуляя».
А насчет загруженного через бложик wso, в данной конфигурации сервера будет вот:
Думаю тут мало, что можно сделать хэкеру.
Думаю тут мало, что можно сделать хэкеру.
Автор, извините, конечно, но за 777 права на каталоги нужно отрывать руки =)
Также Вы даете очень плохой совет — использовать mod_php, а не itk/FastCGI, ибо если поломают один сайт, поломают все ресурсы, а «новички на VPS» либо вообще не обновляют CMS, либо используют нуленные.
Половину софта вроде exim, vsftpd можно выкинуть, в CMS использовать SMTP авторизацию, а для работы с файлами сайтов WinSCP либо FileZilla + pageant.
Также у Вас присутствуют совершенно не нужные для новичка пакеты вроде gcc ( чтобы хакерам в 777 каталогах было проще собирать малварь? =) ) или apache ruby модулей.
Извините, но безопасность настройки в Вашей статье близится к нулю.
Если я хочу ездить на машине, я либо заказываю такси ( плачу профессионалу ), либо учусь на права ( учусь управлять автомобилем самостоятельно ), если хочу есть, либо иду в кафе ( плачу квалифицированным специалистам за еду ), либо учусь готовить сам, но почему-то, когда все хотят свой сервер, они не хотят платить за настройку ( платные/бесплатные панели управления вроде cpanel,webmin,ISP,FastPanel, либо сис админы ) и не хотят учиться сами, а читают вот такие маны и становятся еще одним зараженным хостом в каком-нибудь большом ботнете.
Также Вы даете очень плохой совет — использовать mod_php, а не itk/FastCGI, ибо если поломают один сайт, поломают все ресурсы, а «новички на VPS» либо вообще не обновляют CMS, либо используют нуленные.
Половину софта вроде exim, vsftpd можно выкинуть, в CMS использовать SMTP авторизацию, а для работы с файлами сайтов WinSCP либо FileZilla + pageant.
Также у Вас присутствуют совершенно не нужные для новичка пакеты вроде gcc ( чтобы хакерам в 777 каталогах было проще собирать малварь? =) ) или apache ruby модулей.
Извините, но безопасность настройки в Вашей статье близится к нулю.
Если я хочу ездить на машине, я либо заказываю такси ( плачу профессионалу ), либо учусь на права ( учусь управлять автомобилем самостоятельно ), если хочу есть, либо иду в кафе ( плачу квалифицированным специалистам за еду ), либо учусь готовить сам, но почему-то, когда все хотят свой сервер, они не хотят платить за настройку ( платные/бесплатные панели управления вроде cpanel,webmin,ISP,FastPanel, либо сис админы ) и не хотят учиться сами, а читают вот такие маны и становятся еще одним зараженным хостом в каком-нибудь большом ботнете.
В данном случае права 777 не играют роли, почему, думаю вам и так понятно.
Прочитав и вникнув например сюда:
Благодаря apache2-mpm-itk мы имеем возможность использовать в конфигах виртуалхоста директиву AssignUserId www-data dapf, которая позволяет запретить web-шеллу, править файлы нашего проекта, кроме тех, на которых стоят права o+w. Т.е. apache сможет спокойно прочитать php-файл, выполнить его и отдать в браузер, но не сможет внести изменения в его содержимое…
Вам стало бы понятнее, но вы же не читали :)
Прочитав и вникнув например сюда:
Благодаря apache2-mpm-itk мы имеем возможность использовать в конфигах виртуалхоста директиву AssignUserId www-data dapf, которая позволяет запретить web-шеллу, править файлы нашего проекта, кроме тех, на которых стоят права o+w. Т.е. apache сможет спокойно прочитать php-файл, выполнить его и отдать в браузер, но не сможет внести изменения в его содержимое…
Вам стало бы понятнее, но вы же не читали :)
Вы меня извините, но 3\4 вашего «топика» можно заменить вот этим вот мануалом с howtoforge, с поправкой разве что на версии софта.
Не совсем, в том мануале абсолютно другой подход и ни одного упоминания о связке apache+nginx, хотя на хабре такие статьи есть ;)
Связка Apache и nginx нужна только в том случае, когда без фич Апача, без того же mod_rewrite или еще чего не обойтись.
98% юзеров, которые хотят поднять свою первую VPS, он нахрен не сдался. Тем более на 256 метрах памяти — при таких лимитах нужно выбирать что-то одно.
98% юзеров, которые хотят поднять свою первую VPS, он нахрен не сдался. Тем более на 256 метрах памяти — при таких лимитах нужно выбирать что-то одно.
см. коммент от alpha6
А скажите, чем этот процесс отличается от процесса под Апачем? Ничем.
Если не включать ЧПУ — работает из коробки, если включать — нужно доставить один мелкий плагин к самому Wordpress, «nginx Compatibility».
И собственно, всё. Не аргумент.
Если не включать ЧПУ — работает из коробки, если включать — нужно доставить один мелкий плагин к самому Wordpress, «nginx Compatibility».
И собственно, всё. Не аргумент.
Помимо WP, есть куча и других CMS, в которых не всем хочется переписывать ЧПУ (mod_rewrite) под nginx, а использовать апач под статику+динамику я считаю сильно большой нагрузкой, логичнее отвести ему только динамику, а статику оставить на nginx, можно и наоборот сделать, только апач будет кушать больше, чем nginx в такой связке.
nginx что так, что так раздаёт статику, один хрен.
А красивые ссылочки надо делать средствами скрипта, а не через веб-сервер, вот честное слово. Почему-то Mediawiki работает из коробки точно так же, тихо и молча, и к ней даже ничего докручивать не нужно.
А красивые ссылочки надо делать средствами скрипта, а не через веб-сервер, вот честное слово. Почему-то Mediawiki работает из коробки точно так же, тихо и молча, и к ней даже ничего докручивать не нужно.
Ну можете нагрузить nginx еще и динамикой, никто не запрещает это дело вкуса. Сервис упадет, всё упадет. А так отвалится тот же апач, nginx будет из кеша тянуть статику и отдавать юзерам, пока апач не перезапустится (можно на эту тему кстать еще одну статью написать :) ).
Ну и Mediawiki это Mediawiki, продумали её разработкичи все эти ньансы.
Ну и Mediawiki это Mediawiki, продумали её разработкичи все эти ньансы.
Посмотрел ваши конфиги. При падении бекенда, nginx в данном конкретном случае будет возвращать 502, и раздавать только статику по прямым линкам.
Тут да, но я же выше написал, что это тема отдельной статьи, т.с. о выгоде связке apache+nginx по сравнению с просто nginx или apache. Причем плюсов этой связки можно много придумать.
И зачем это на Хабре в десятый раз, вот честное слово?
Таких топиков, вам тут уже внизу приводили примеры, как грязи. Нахрена плодить сущности, вместо того, чтоб пользоваться поисковиком?
Таких топиков, вам тут уже внизу приводили примеры, как грязи. Нахрена плодить сущности, вместо того, чтоб пользоваться поисковиком?
Честно читал конфиг виртхоста до написания поста три раза, и только после копипаста от вас увидел, что итк включен. Кстати меня смутило еще то, что у автора в установленных пакетах для установки и mod_itk и prefork стоят, такая команда вывалится в ошибку конфликта.
nikolayvaganov, где можно почитать вашу статью о настройке VPS?
Статей про настройку VPS в интернете более, чем достаточно и для каждого сервера нужно знать, под что именно настраиваешь сервер. Например, под обычный сайт на php на известной CMS Вам на самом сервере хватит nginx + php-fpm + mysql ( почту настраиваем на любой из бесплатных сервисов, DNS нам на сервере не нужен, к CMS подключаем SMTP плагин, FTP не ставим, там как авторизация плейнтекст по сети, да и зачем он вообще нужен. В итоге получается вот такая картина:
root@www:/var/run# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2143/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14157/nginx.conf
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 19158/sshd
tcp 0 0 XX.XX.XX.XX:443 0.0.0.0:* LISTEN 14157/nginx.conf
root@www:/var/run# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 10600 176? Ss Апр25 0:13 init [2]
root 2 0.0 0.0 0 0? S Май25 0:00 [kthreadd/9614]
root 3 0.0 0.0 0 0? S Май25 0:00 [khelper/9614]
root 1710 0.0 0.1 21084 592? Ss Апр25 0:02 /usr/sbin/cron
mysql 2143 0.0 4.8 93180 19744? Sl Июн16 0:05 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plug
root 14157 0.0 0.9 45584 3728? S Июн19 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
www-data 14159 0.0 1.0 46676 4108? S Июн19 0:14 nginx: worker process
root 14223 0.0 1.2 179124 5056? Ss Июн19 0:02 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
root 16091 0.0 1.1 87016 4820? Ss 12:16 0:00 sshd: root@pts/0
root 16093 0.0 0.5 20148 2216 pts/0 Ss 12:16 0:00 -bash
tresnet 16579 0.0 10.3 194812 42384? S 15:09 0:02 php-fpm: pool XXX.ru
tresnet 16580 0.0 8.1 189524 33452? S 15:09 0:02 php-fpm: pool XXX.ru
root 16733 0.0 0.3 17512 1256 pts/0 R+ 17:01 0:00 ps aux
root 19158 0.0 0.2 52204 876? Ss Июн10 0:01 /usr/sbin/sshd
root@www:/var/run# free -m
total used free shared buffers cached
Mem: 400 213 186 0 0 132
-/+ buffers/cache: 81 318
Swap: 0 0 0
Если у Вас что-то сложнее, чем сайт на php ( например CGI скрипты, ruby, svn ) то тогда nginx не самый лучший вариант, и нужно смотреть в сторону апача.
root@www:/var/run# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2143/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 14157/nginx.conf
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 19158/sshd
tcp 0 0 XX.XX.XX.XX:443 0.0.0.0:* LISTEN 14157/nginx.conf
root@www:/var/run# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 10600 176? Ss Апр25 0:13 init [2]
root 2 0.0 0.0 0 0? S Май25 0:00 [kthreadd/9614]
root 3 0.0 0.0 0 0? S Май25 0:00 [khelper/9614]
root 1710 0.0 0.1 21084 592? Ss Апр25 0:02 /usr/sbin/cron
mysql 2143 0.0 4.8 93180 19744? Sl Июн16 0:05 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plug
root 14157 0.0 0.9 45584 3728? S Июн19 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
www-data 14159 0.0 1.0 46676 4108? S Июн19 0:14 nginx: worker process
root 14223 0.0 1.2 179124 5056? Ss Июн19 0:02 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
root 16091 0.0 1.1 87016 4820? Ss 12:16 0:00 sshd: root@pts/0
root 16093 0.0 0.5 20148 2216 pts/0 Ss 12:16 0:00 -bash
tresnet 16579 0.0 10.3 194812 42384? S 15:09 0:02 php-fpm: pool XXX.ru
tresnet 16580 0.0 8.1 189524 33452? S 15:09 0:02 php-fpm: pool XXX.ru
root 16733 0.0 0.3 17512 1256 pts/0 R+ 17:01 0:00 ps aux
root 19158 0.0 0.2 52204 876? Ss Июн10 0:01 /usr/sbin/sshd
root@www:/var/run# free -m
total used free shared buffers cached
Mem: 400 213 186 0 0 132
-/+ buffers/cache: 81 318
Swap: 0 0 0
Если у Вас что-то сложнее, чем сайт на php ( например CGI скрипты, ruby, svn ) то тогда nginx не самый лучший вариант, и нужно смотреть в сторону апача.
Поправил, prefork для тестов был.
Тут дело не столько в инвайте, а в том чтобы не потерялось, иногда бывает нужно найти кое-что, а тут все под рукой.
«Чтобы не потерялось» мне больше нравится использовать вот этот сервис…
А в песочнице точно потерялось бы, повезло вам.
А в песочнице точно потерялось бы, повезло вам.
Спасибо, о хабре я слышал, а про гист нет, попробую и его.
Добавлю app.gistboxapp.com
Debian + make install = ад, так делать нельзя. К тому же, когда php-apc в репозитории.
Не всегда, бывают случаи, когда необходимо под конкретную версию/систему/сборку и т.д. собрать плагин. В данном примере под PHP 5.4, а если будет другая версия, например бетка под которою нет репозитория? Тогда как?
Значит, надо собирать не на боевой тачке. Только безумец компилирует что-то на проде.
хм, всегда считал, что компилировать надо там, где собираешься запускать… Иначе имеешь риск обломиться с запуском.
В чем конкретно риск для продакшна?
И в чем принципиальное отличие make от apt[itude] install в этом плане?
В чем конкретно риск для продакшна?
И в чем принципиальное отличие make от apt[itude] install в этом плане?
Ну, если компилируешь для дебиана под дебианом — никаких проблем не будет, как правило.
Сколько собирал для VPS под wheezy на своем десктопном sid — все работает збс.
А риска как такового нет, по крайней мере, фундаментального, просто засирать нет никакого желания.
Сколько собирал для VPS под wheezy на своем десктопном sid — все работает збс.
А риска как такового нет, по крайней мере, фундаментального, просто засирать нет никакого желания.
Риск в том, что в случае взлома атакующий сможет скомпилировать что угодно: если совсем не повезет, то соберет какой-нибудь эксплоит, повысит привилегии и получит полный контроль над системой.
По поводу принципиального отличия, если это серьезный вопрос: использование make install засоряет систему бинарниками в лучшем стиле Windows DLL Hell. Чем больше софта устанавливается таким образом, тем сложнее поддерживать порядок. Причем затрудняется не только банальное управление установленным таким способом софта, но и есть ненулевая вероятность что-нибудь просто-напросто сломать, скажем, перезаписав нужную библиотеку, установленную ранее из репозитория, другой версией, или грохнув нужный Debian-way симлинк (например, Debian Alternatives), а потом долго думать и ходить вокруг да около с strace и ldd наперевес. Чем «системнее» пакет, тем хуже могут быть последствия от make install.
Если есть менеджер пакетов, нужно им пользоваться. Он обеспечивает разрешение всех зависимостей и минимизирует вероятность что-нибудь очень глупо сломать. Если пакет собран адекватным человеком, при его установке для всяческих инвазивных действий будут использоваться системные средства: скажем, если в системе стоит python2.6, можно рядом поставить python2.7, а потом еще и python3, и все три интерпретатора будут доступны, не будут друг с другом конфликтовать, и в любой момент можно запустить update-alternatives, чтобы изменить используемый по умолчанию интерпретатор. И все это через apt-get безо всякой беготни с тарболлами.
А для крайних случаев всегда есть checkinstall или сборка пакета руками.
По поводу принципиального отличия, если это серьезный вопрос: использование make install засоряет систему бинарниками в лучшем стиле Windows DLL Hell. Чем больше софта устанавливается таким образом, тем сложнее поддерживать порядок. Причем затрудняется не только банальное управление установленным таким способом софта, но и есть ненулевая вероятность что-нибудь просто-напросто сломать, скажем, перезаписав нужную библиотеку, установленную ранее из репозитория, другой версией, или грохнув нужный Debian-way симлинк (например, Debian Alternatives), а потом долго думать и ходить вокруг да около с strace и ldd наперевес. Чем «системнее» пакет, тем хуже могут быть последствия от make install.
Если есть менеджер пакетов, нужно им пользоваться. Он обеспечивает разрешение всех зависимостей и минимизирует вероятность что-нибудь очень глупо сломать. Если пакет собран адекватным человеком, при его установке для всяческих инвазивных действий будут использоваться системные средства: скажем, если в системе стоит python2.6, можно рядом поставить python2.7, а потом еще и python3, и все три интерпретатора будут доступны, не будут друг с другом конфликтовать, и в любой момент можно запустить update-alternatives, чтобы изменить используемый по умолчанию интерпретатор. И все это через apt-get безо всякой беготни с тарболлами.
А для крайних случаев всегда есть checkinstall или сборка пакета руками.
Если нету репозитория, значит вам пока не нужно это ставить. Особенно бетку на прод. Нужна последняя версия под debian — всегда есть штуки типа dotdeb.
Конечно на эту тему можно спорить до бесконечности, но если есть возможность собирать софт из сорцов под конкретную сборку PHP, то почему бы этим не пользоваться?
Пользоваться нужно разумно, а не потому что можно. Если вам нравится собирать что-то, ставьте arch. Debian стабилен только потому что все держится на стабильных пакетах. Должна быть объективная причина для сборки. Тот же node.js можно собрать, а можно просто поставить бинарники, и второй способ проще.
А где безопасность? Где настройка iptables?
А iptables в конце статьи, но подбно можете почитать, например тут.
Что касается защиты от ддос, то это отдельная тема и тут она не рассматривается.
Что касается защиты от ддос, то это отдельная тема и тут она не рассматривается.
А еще можно нагуглить с десяток бесплатных панелек управления хостингом, которые сделают гораздо более правильные настройки для того чтобы сайты Пети не мешали сайтам Васи. Зря их чтоли годами пилят
А почему в место кучи конфигов, не привести конфигурацию для chef-solo или ansible который развернет все это без всяких проблем и любое количество раз?
>> Apache 2.2 + PHP 5.4.4 + MySQL 5.5 + NGINX 1.2.1 + eAccelerator + memcached + vsftpd 3.0.2 + exim.
Кроме того, что выше и так уже написали про Апач и актуальные версии php и nginx и прочее, еще добавлю, что хватит уже мучать этого старика MySQL, поставьте Percona что ли, или MariaDB.
>> apt-get dist-upgrade
отличный совет поломать систему
>> php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-common php5-ming php5-mysql php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
А че так мало расширений. Давайте сразу все 150 поставим. www.php.net/manual/en/extensions.alphabetical.php
Кроме того, что выше и так уже написали про Апач и актуальные версии php и nginx и прочее, еще добавлю, что хватит уже мучать этого старика MySQL, поставьте Percona что ли, или MariaDB.
>> apt-get dist-upgrade
отличный совет поломать систему
>> php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-common php5-ming php5-mysql php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
А че так мало расширений. Давайте сразу все 150 поставим. www.php.net/manual/en/extensions.alphabetical.php
Sign up to leave a comment.
Безопасный и шустрый веб-сервер на Debian 7