Валерий Рябошапко

чисто средствами крона этого не сделать из-за разного кол-ва дней в месяце, у вас будет тоже что сейчас с днями недели.
можно написать несколько правил под 30 и 31 дневные месяцы, но весокосный февраль все рано будет мешать,
так что если период вам критичен - запускайте раз в день и в скрипте уже отсчитывайте сколько прошло с предыдущего запуска

По вашему вопросу много сказали ранее.
Я вам, да и всем, просто рекомендую передавать доступ к серверу отдельным актом работ по каждому серверу. В этом акте работ должны быть следующие пункты (возможно дополнение):

• Создан новый пользователь для нового администратора (помним же, что под рутом сидеть атата)
• Новому пользователю предоставлены права администратора (доступ к sudo)
• Новый пользователь смог зайти в свою учетную запись и поменял свой пароль
• Новый пользователь сменил пароль пользователя root
• Старый пользователь, под которым работали вы удален. Полностью
• Новому администратору продемонстрировано, что старый пользователь не имеет доступа как под своей учетной записью, так и под root (это так, на всякой случай)

Подпись обеих сторон желательна напротив каждой строчки. Составляется в двух экземплярах.

DNSу принципиально пофигу по какому протоколу идет запрос, его задача имена преобразовывать, отсеять их проще простого, запрещаем на фаирволе 443 порт и все дела, в 99% случаев это поможет. Еще можно для прокси задать разные правила работы с http и https, не хватает данных по задаче. Что значит распределение трафика? Http через один канал, https через другой? Так это решается правилами форвардинга портов.

Я считаю, что в каждом отдельном случае надо выбирать оптимальное решение.
Да, облака определенно хранят данные (во многих случаях их содержимое доступно создателям) на территории вероятного противника и вне юрисдикции законов РФ.
Да, облака зачастую еще и обрабатывают ваши данные и метаданные, для своих целей.
Но, они обеспечивают заведомо более высокую доступность, более быструю разработку продукта или более легкий и дешевый старт бизнеса, снимают с вас временные затраты и позволяют сосредоточиться на бизнесе.
Во многих случаях,следует воспользоваться конкурентным преимуществом облака, если у вас нет гос.\финансовой тайны конечно. В бизнесе надо быть гибким.

Те кто держит арендованные VPS\VDS или аппаратные серверы, часто забывают о доступности физических носителей информации в ДЦ, о возможности перехвата трафика внутри ДЦ. Поэтому перед принятием решения посчитайте каких характеристик должен быть сервер в ДЦ для поддержания работы сервиса + нагрузки от криптодиска и криптотуненей. Сравните со стоимостью своей аппаратной серверной. И сравните с решением для облака. И выберите то что укладывается в бюджет.

Так же помните что никакое облако не отменяет бекапов вне облака.

Область действия переменных учите вначале.

$name = John;
function uzver($name) {
   echo "Привет $name";
}

Тут [$name] и [($name) в функции] - две РАЗНЫХ переменных.
По-умолчанию в PHP переменные создаются "на-лету" при присваивании значений (или упоминании) и действуют в своей области.

Работал в банке, там вся банковская финансовая система была написана на php. Ей нонстоп пользовались 20 операционисток. В минуту проходило до 1000 проводок от пользователя к нам а затем в ЦБ. Те кто знают что такое банковская CRM, представляют ее сложность.
И все работало на ура.

Так что не вижу разницы.
Что нравится, на том и пишите.

P.S.
Сейчас под php библиотек, классов и т.д. просто немерено. Стоит только поискать на git

Согласно официальной документации рекомендуют использовать такую конструкцию:

server {
        listen 80;
        server_name example.com;
        return 301 https://$server_name$request_uri;  # enforce https
#        rewrite ^(.*) https://www.example.com$uri permanent;
}

Смотрите под каким пользователем работает apache и кому принадлежит директория в которую пытаетесь писать. Не используйте 777 на директории, используйте 750 или даже 700.

Сервер работает под своим php.ini, cron запускает php в cli-режиме, в этом режиме используется другой php.ini.

Увеличьте память для скрипта где-то в районе: /etc/php5/cli/php.ini

Если вы запускаете скрипт через cron, то он выполняется в cli режиме. А в cli режиме у php нет лимитов на время выполнения скрипта.

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

Если проблема с памятью, то можно увеличить лимиты, как советует @merryjane, или же поискать и оптимизировать места, где у вас идут утечки памяти.

UPD: но вы, всё же, можете сделать поэтапное выполнение скрипта: сгенерировать дополнительным скриптом подзадачи, положить эти задачи в какую-нибудь БД, а потом запускать ваш основной скрипт несколько раз, а он уже будет брать задачи из такой вот кустарной очереди. Ну или можно использовать какие-нибудь готовые менеджеры очередей :)

Можно воспользоваться анализаторами логов. Например самые популярные Webalizer и AWStats:
www.webalizer.org
www.awstats.org
Однако, надо понимать, что такой анализатор в момент обсчета логов создает дополнительную нагрузку на сервер (иногда существенную, если логи большие). Также необходимо писать логи в стандартных форматах или менять настройки формата лога в анализаторе, если Ваш web-сервер пишет лог в своем формате.

RewriteCond %{REQUEST_FILENAME} !-f # не файл
RewriteCond %{REQUEST_FILENAME} !-d # не директория
RewriteCond %{REQUEST_FILENAME} !-s # не сим.линк
RewriteCond %{REQUEST_FILENAME} !-l # не линк
RewriteRule ^(.+)$ /index.php?hash=%{QUERY_STRING} [L]