Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Не сказал что советы именно в домашних условиях, как раз на днях нужно было настроить vps и советы дельные
session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности
Вы серьезно считаете, что это помогает «безопасности»?
error_reporting = E_ERROR
И плевать, что PHP во всю глотку орет Warning'ами, что не может открыть файл или подключиться к базе?
У меня закрались серьезные сомнения в Вашей компетентности.
Нууу. Я же написал, что рекомендую E_ALL | E_STRICT при качественном коде, во всех новых приложениях у меня так и стоит. Какой смысл от логов, если в них 100500 Warning'ов не инициализированной переменной. Код же не от сисадмина зависит. При качественном коде, ну словите 10-20 ошибок, сможете отладить.
Если сервер начинает работать не стабильно и тому есть какие-либо подтверждения, то конечно надо врубать ВСЕ логи на сервере, которые только сможете на всех уровнях и находить проблему, читая или ища в гигабайтных файлах.
Просто так записывать пустые гигабайты не считаю правильным. Пожалуйста, расскажите почему я могу быть не прав в своем мнении?
Если сервер начинает работать не стабильно и тому есть какие-либо подтверждения, то конечно надо врубать ВСЕ логи на сервере, которые только сможете на всех уровнях и находить проблему, читая или ища в гигабайтных файлах.
Просто так записывать пустые гигабайты не считаю правильным. Пожалуйста, расскажите почему я могу быть не прав в своем мнении?
Какой смысл от логов, если в них 100500 Warning'ов не инициализированной переменной
Не инициализированная переменная бросает notice. А warning происходит при ошибках include, file_get_contents, mysql_connect и т.д. Вы считаете, что это мелочи? Это же зародыши более критичных ошибок!
Меня всегда бросает в холодный пот, когда люди говорят, что «варнинг — фигня, жить можно». Представьте, что Ваши денежные транзакции обрабатывает такой код:
$money = file_get_contents('money.txt');
$money = $money + $newTransaction;
file_put_contents('money.txt', $money);
Так вот если file_get_contents бросит варнинг (потому что прав, например, нет), ваши сбережения станут равны нулю (плюс новая транзакция). Вот тебе и «мелочи». Понятно, что я сгущаю краски, но так лучше видно последствия игнорирования ошибок.
Я не понял кто целевая аудитория Ваших статей. Вы свои проекты так хостите?
Да. Ступил по поводу notice. Тогда согласен. Подправил статью. В остальном, считаю, что Вам стоит быть немного более уравновешеннее, не все такие профессионалы как Вы. А если вы изволите, то напишите важные дополнения к циклу статей, я с удовольствием сделаю ссылку на них.
Вам стоит быть немного более уравновешеннее, не все такие профессионалы как Вы
Не назвал бы себя профессионалом по настройке серверов, я, все же, веб-разработчик. Но те ошибки, на которые я указал, они, как бы это назвать… в общем говорят, о том, что Вы, скорее всего, имеете мало опыта.
Вот я спросил о Вашей целевой аудитории, т.е. кому Вы адресуете этот мануал. Я, например, веб-сервер использую, в основном, для разработки и я не могу даже придумать, зачем мне может понадобиться игнорировать ошибки, ведь это сигнал о том, что я что-то делаю не так. И я не знаю, как можно использовать сторонние скрипты, которые фонтанируют ворнингами и т.д. Это так же не разумно, как игнорировать повышение температуры, рвоту и головокружение — к добру это не приведет.
По поводу смены имени сессионной куки. Вроде бы ничего такого, но Вы это записали в разряд «повышение безопасности» и это очень и очень плохо. Понимаете, Вы ничего не скрыли и не повысили безопасность. Это просто имя куки. Вот если «хабр» переименовать в «забр» что изменится? Имена кук не влияют на безопасность. Вообще. Никак. Содержимое — да, влияет. Имена — нет. Эта Ваша рекоммендация дискредитирует всю статью. Другие пункты безопасности тоже не ахти. В общем, раздел «базовая безопасность» имеет к безопасности такое же отношение, как просмотр боевиков к самообороне.
А если вы изволите, то напишите важные дополнения к циклу статей
Знаете, иногда одолевает желание «пролить свет истины», но потом как-то отпускает :) Приходится ворчать в комментариях :) Может и разрожусь как-нибудь.
Что-то я увлекся. Пора спать. Старался быть конструктивным. Ничего личного.
ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5"
Ох спасибо, мил человек! Заглянул в /tmp а там...! Уже 20 минут удаляется.
Стоит выбросить прослойку апача из схемы и использовать PHP-FPM.
memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
Предупреждение любителям закручивать: если вы обрабатываете загружаемые пользователями картинки с помощью PHP-GD (или других библиотек PHP), а не через exec, то особо настройку не закручивайте. Примерно опытным путем установлено, что иногда 256 Мб памяти бывает недостаточно для обработки (уменьшения, кадрирования, наложения watermark) 4-5-мегабайтных JPG. А с нынешних камер могут засунуть картинки и потяжелее. Где-то в тырнете был точный расчет памяти, не могу найти…
За обработку изобрвжений за пределами выделенной под это очереди нужно отбивать руки, головы и прочие выступающие части тела.
При чем тут очередь? 256 Мб может быть недостаточно для обработки одного изображения.
Имеется ввиду отдельное приложение, обрабатывающее картинки. Т. е. пользователь загружает картинку, но контроллер ее не обрабатывает, а создает задачу в job queue; специальное приложение слушает эту очередь и обрабатывает картинки в ней. Таким образом, для web контроллеров можно «закрутить» как вы говорите, размер памяти, выделяемый для php скриптов.
Спасибо. Жду следующей статьи из цикла.
Две мысли.
1. Почему не работал сборщик сессий?
Проверьте значения
Дело в том, что в дебиане и производных по умолчанию числитель этой дроби установлен в ноль, соответственно, сборщик сессий не запустится никогда.
Вместо этого имеем
То есть всё это делается не средствами php, а просто find -delete, запускаемым по расписанию. Такой вот debian-way.
У себя на серверах, где хостится, например, много тестовых сайтов, я пишу сессии в пользовательские директории
2. Рекомендую
В один прекрасный день один прекрасный разработчик записал в одну прекрасную InnoDB-таблицу порядка сотни гигов блобов. Потом-то, конечно, он их удалил, а вот
1. Почему не работал сборщик сессий?
Проверьте значения
session.gc_probability и session.gc_divisor в php.ini. Два этих параметра вместе определяют вероятность, с которой сборщик сессий запустится перед выполнением очередного запроса (session.gc_probability/session.gc_divisor). Дело в том, что в дебиане и производных по умолчанию числитель этой дроби установлен в ноль, соответственно, сборщик сессий не запустится никогда.
Вместо этого имеем
/etc/cron.d/php5:09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -deleteТо есть всё это делается не средствами php, а просто find -delete, запускаемым по расписанию. Такой вот debian-way.
У себя на серверах, где хостится, например, много тестовых сайтов, я пишу сессии в пользовательские директории
/srv/www/*/tmp и точно так же хожу по ним уже своим аналогичным cronjob'ом.2. Рекомендую
innodb_file_per_table. Без этой опции все данные из всех InnoDB-таблиц валятся в файл %DATADIR%/ibdata1. Этот файл, кроме всего прочего, никогда не уменьшается в размере.В один прекрасный день один прекрасный разработчик записал в одну прекрасную InnoDB-таблицу порядка сотни гигов блобов. Потом-то, конечно, он их удалил, а вот
ibdata1 так и остался распухшим. Высвободить место я смог только перезаливкой баз (запустил два экземпляра mysql, один смотрел в старый datadir — на нём делался mysqldump, другой — в новый datadir и в него этот дамп сразу же и вливался). В общем, получилось грустно и печально.
Почему при apc.shm_segments = 16:
NOTICE: PHP message: PHP Warning: PHP Startup: apc.shm_segments setting ignored in MMAP mode
When APC is compiled with mmap support (Memory Mapping), it will use only one memory segment, unlike when APC is built with SHM (SysV Shared Memory) support that uses multiple memory segments. MMAP does not have a maximum limit like SHM does in /proc/sys/kernel/shmmax. In general MMAP support is recommeded because it will reclaim the memory faster when the webserver is restarted and all in all reduces memory allocation impact at startup.
Это означает, что вы нашли баг в статье. Сейчас исправим.
Это означает, что вы нашли баг в статье. Сейчас исправим.
Читаю уже вторую статью данного автора с надеждой на что-то вменяемое.
Автор! Иногда лучше не писать ничего, чем писать кое-как.
Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
— ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5" — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляется — стоило погуглить 5 минут и найти дебиановский багрепорт, чтобы понять, что такова особенность реализации очистки сессий в дебиане. Всё чистится в кроне. И вот уже эту информацию можно было выложить в статье.
В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно…
…
Сам не являюсь профи по настройке баз данных — не профи, но научу вас, как правильно настроить mysql..
Базовая защита
session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности — no comments.
error_reporting = E_ERROR — уже поправили.
memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
— 128 мало для большинства задач, но говоря уже о фреймворках вроде yii.
datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные. — Зачем это? Какая защита? От кого? Если это так критично, то напоминаю, что по дефолту в дебиане только пользователь mysql имеет доступ в /var/lib/mysql. Кстати разбиение на разделы более чем странное. Хранить базы в /home очень нестандартное решение.
По mysql весьма поверхностно прошлись. Где переменные innodb_flush_log_at_trx_commit, innodb_file_per_table, sync_binlog ?
Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духе — а может не надо?
Даже на хабре есть несколько таких статей + howtoforge в гугле выходит наверное в первой тройке по запросу «postfix dkim»
соответственно разъясню все нюансы связанное например со стандартами именований принятые у меня — советую почитать стандарты именований принятые во всём мире и следовать им.
Автор! Иногда лучше не писать ничего, чем писать кое-как.
Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
— ОЧЕНЬ ВАЖНО: session.save_path = "/var/lib/php5" — это обязательно надо установить так! По стандарту debian именно там должны находиться сессии. Не знаю почему, но в сборке debian эта переменная не выставляется — стоило погуглить 5 минут и найти дебиановский багрепорт, чтобы понять, что такова особенность реализации очистки сессий в дебиане. Всё чистится в кроне. И вот уже эту информацию можно было выложить в статье.
В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно…
…
Сам не являюсь профи по настройке баз данных — не профи, но научу вас, как правильно настроить mysql..
Базовая защита
session.name = SESSID изменил с PHPSESSID на SESSID, для пущей скрытности — no comments.
error_reporting = E_ERROR — уже поправили.
memory_limit = 128M — это то, какое максимальное количество памяти может потребить скрипт. PHP не будет выделать больше памяти, чем указано в этой настройке. Данная настройка указывается в зависимости от задач исполняемых на сервере. Для более точного расчета ресурсов следует закручивать этот параметр как можно сильнее и пытаться писать софт как можно качественнее.
— 128 мало для большинства задач, но говоря уже о фреймворках вроде yii.
datadir = /home/mysql — при настройке сделана отдельная директория в /home для mysql с защитой от доступа другим пользователям, кроме mysql. Это сделано, что бы перенести данные из /var/lib/mysql (если я не ошибаюсь) в раздел /home — самый большой раздел диска на сервере, где и хранятся все данные. — Зачем это? Какая защита? От кого? Если это так критично, то напоминаю, что по дефолту в дебиане только пользователь mysql имеет доступ в /var/lib/mysql. Кстати разбиение на разделы более чем странное. Хранить базы в /home очень нестандартное решение.
По mysql весьма поверхностно прошлись. Где переменные innodb_flush_log_at_trx_commit, innodb_file_per_table, sync_binlog ?
Если данная статья будет по вкусу, то собираюсь написать про настройку mail() + postfix + dkim в духе — а может не надо?
Даже на хабре есть несколько таких статей + howtoforge в гугле выходит наверное в первой тройке по запросу «postfix dkim»
соответственно разъясню все нюансы связанное например со стандартами именований принятые у меня — советую почитать стандарты именований принятые во всём мире и следовать им.
> Читаю уже вторую статью данного автора с надеждой на что-то вменяемое.
Ну написал же — не являюсь профессионалом в настройке WEB-серверов. Если вы профессионал, напишите Вашу статью, я с удовольствием её почитаю и буду вас боготворить, вы сэкономите другим людям уйму времени на гугле и нахождения до селе им неизвестного.
> Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание? Вменяемо оно или не вменяемо, оно работает, а настройки сделаны под сервер который я указал выше. Бери, разворачивай, читай рекомендации и дальше сам, вдупляйся в документацию. Мне кажется это хороший пинок вперед для тех кто начинает — каким когда-то был и я. Если я не прав, поясните.
По поводу названий сессий, допустим согласен. Но все-равно лучше вообще слово PHP не употреблять нигде (заголовках, варнингах, названий кук, при отправки письма, нигде) ИМХО.
Ну написал же — не являюсь профессионалом в настройке WEB-серверов. Если вы профессионал, напишите Вашу статью, я с удовольствием её почитаю и буду вас боготворить, вы сэкономите другим людям уйму времени на гугле и нахождения до селе им неизвестного.
> Ни одной капли полезной информации, всё это можно прочитать в официальной документации mysql и php, причём там это описано гораздо лучше.
Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание? Вменяемо оно или не вменяемо, оно работает, а настройки сделаны под сервер который я указал выше. Бери, разворачивай, читай рекомендации и дальше сам, вдупляйся в документацию. Мне кажется это хороший пинок вперед для тех кто начинает — каким когда-то был и я. Если я не прав, поясните.
По поводу названий сессий, допустим согласен. Но все-равно лучше вообще слово PHP не употреблять нигде (заголовках, варнингах, названий кук, при отправки письма, нигде) ИМХО.
Ну написал же — не являюсь профессионалом в настройке WEB-серверов — Статья про веб и базы. По обоим направлениям вы не профессионал. В мою логику не укладывается, как можно учить чему-то, если сам в этом не разбираешься.
Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание? — чтобы настроить всё правильно, а не бездумно копировать чужие, не всегда верные конфиги.
Вменяемо оно или не вменяемо, оно работает — до первого сбоя, после которого кто-то будет бегать и восстанавливать базу например.
Зачем (обычному человеку/новичку) который делает первый шаг, вдуплять неделю во все это второй раз, если есть уже все конфиги, и то, на что следует обратить внимание? — чтобы настроить всё правильно, а не бездумно копировать чужие, не всегда верные конфиги.
Вменяемо оно или не вменяемо, оно работает — до первого сбоя, после которого кто-то будет бегать и восстанавливать базу например.
Хабр нуждается в Вас! =). Я уже понял насколько я мелочен перед вами. Но пока в избранное добавляют более 500 за статью, будем продолжать помогать людям с непрофессиональной стороны, пока вы профессионалы ничего не пишете, а нам совершенно неумелым девелопарам приходится побираться по заграницам и документациям, тратя время на непрофильное занятие.
Я не утверждал ничего подобного. Не проецируйте на меня свои фобии =)
Я ничего не проецирую. Просто очень резкие и на половину конструктивные комментарии, где слишком много жирного. Если вы реально хорошо разбираетесь, то потрудитесь напишите вашу статью с вашими настройками, я сделаю на нее ссылочу. Чем больше перелинкованной между собой информации тем лучше сможет разобраться человек который будет читать. Я наоборот жду, когда кто-нибудь с хорошей квалификацией соизволит это сделать.
Жирным я выделяю свои ответы для повышения читаемости и не более.
Если вы реально хорошо разбираетесь, то потрудитесь напишите вашу статью с вашими настройками, я сделаю на нее ссылочу — бессмысленно писать что-то на тему LAMP, неоднократно обмусоленную со всех сторон.
Не вижу смысла дальше переливать из пустого в порожнее, поэтому в последний раз выражу свою мысль:
Каждым делом должен заниматься профессионал. Человек, занимающийся программированием и в свободное время настраивающий сервера достоин уважения, но это совершенно не значит, что он должен публиковать статьи на профильном ресурсе, причём на темы, в которых он, по его же собственным словам не сильно разбирается.
Я не пишу статью про python, хотя частенько использую его в работе и написал на нём достаточно небольших программ.
Если вы реально хорошо разбираетесь, то потрудитесь напишите вашу статью с вашими настройками, я сделаю на нее ссылочу — бессмысленно писать что-то на тему LAMP, неоднократно обмусоленную со всех сторон.
Не вижу смысла дальше переливать из пустого в порожнее, поэтому в последний раз выражу свою мысль:
Каждым делом должен заниматься профессионал. Человек, занимающийся программированием и в свободное время настраивающий сервера достоин уважения, но это совершенно не значит, что он должен публиковать статьи на профильном ресурсе, причём на темы, в которых он, по его же собственным словам не сильно разбирается.
Я не пишу статью про python, хотя частенько использую его в работе и написал на нём достаточно небольших программ.
Для MySQL неплохо было бы еще charset правильный поставить в конфигах.
Плюсую, автор, не торопитесь с выводами. А те кто минусуют, лучше бы написали, что в статье не так, ведь дельные комментарии не менее ценны чем сама статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка Nginx + LAMP сервера в домашних условиях Часть 2: Настройка backend: PHP + MySQL