Чтобы такой доступ, требуется два действия.

1) В файле postgresql.conf надо установить:

listen_addresses = '*' 

2) В файле pg_hba.conf надо изменить настройки на:

host all all 0.0.0.0/0 md5
host all all ::/0 md5

Если у вас активен фаервол, то надо ещё открыть порт 5432 (или иногда бывает 5433 для Postgres).

Устанавливаем джаву:

yum install -y java-11-openjdk

Проверяем (должна быть 11-ая):

java -version

Заносим в переменную окружения номер последней версии:

export LATEST_VER="8.8.1"

Скачиваем (тут не случайно указано зеркало от РБК, потому что архив с основного зеркала у меня постоянно распаковывается с какими-то ошибками):

curl -O https://apache-mirror.rbc.ru/pub/apache/lucene/solr/${LATEST_VER}/solr-${LATEST_VER}.tgz

Распаковываем:

tar xvf solr-${LATEST_VER}.tgz

Заходим в каталог и устанавливаем:

cd solr-${LATEST_VER}/bin/
sudo ./install_solr_service.sh ~/solr-${LATEST_VER}.tgz

Открываем порт на фаерволе:

iptables -I INPUT -p tcp --dport 8983 -j ACCEPT

И добавляем в файл /etc/sysconfig/iptables строчку:

-I INPUT -p tcp -m tcp --dport 8983 -j ACCEPT

Запускаем solr и добавляем его в автозапуск:

service solr start
chkconfig solr on

Теперь идём проверять по ссылке http://localhost:8983 (вместо localhost поставьте IP-адрес вашего сервера). Если увидели дашборд Solr, то всё ок. Теперь надо настраивать коллекции, доступ и всякое такое.

stat -f --format='%f*%S/1024/1024/1024' / | bc

Сколько свободно мегабайт в корневом разделе:

stat -f --format='%f*%S/1024/1024' / | bc

Ну, вы поняли.

Команда stat -f / выдаёт информацию о свободном пространстве в блоках (%f), а чтобы превратить это в байты требуется умножить на стандартный размер блока (%S). Делим на 1024 для получения КБ, потом МБ, потом ГБ.

Для начала предоставим принимающему серверу доступ на отправляющий. На принимающем сервере из под рута делаем так:

cat /root/.ssh/id_rsa.pub

Если такого файла нет, значит на принимающем сервере не создана пара ключей. Можно создать одной командой, отвечая на все её вопросы вариантами по умолчанию (т.е. просто жмёте Enter многократно):

ssh-keygen -r rsa

Если файл есть (был ранее ли создан вами только что), то при просмотре файла командой cat видим в нём ключ — копируем его целиком.

Затем идём на отправляющий сервер и открываем там на редактирование файл (если файла нет, то и на отправляющем сервере делаем ssh-keygen):

nano /root/.ssh/authorized_keys

Вставляем туда отдельной строкой скопированный ключ, сохраняем (в nano это можно сделать кнопкой F2). Теперь у нас открытый ключ принимающего сервера добавлен на отправляющий сервер в файл с разрешенными для входа ключами. Это значит, что мы можем зайти по ssh с принимающего сервера на отправляющий. Но нам не очень-то нужен ssh с консолью (мы не собираемся выполнять команды), а хватит scp — это программа для копирования файлов через ssh-протокол.

Поэтому на принимающем сервере делаем:

scp -rpC root@domain.tld:/var/www/site/ /root/

Где domain.tld — это отправляющий сервер, а /var/www/site/ — это тот каталог, который вы хотите оттуда скопировать. А скопируется он, соответственно, внутрь каталога /root/ на принимающем сервере.

У scp мы использовали следующие параметры:

• -r — рекурсивное копирование, т.е. со всеми вложенными каталогами и файлами, что нам собственно и надо при копировании целой директории
• -p — сохранять права и дату/время создания и модификации файлов
• -C — сжимать данные при передаче (нет смысла добавлять этот параметр, если вы копируете архив)

Данный метод должен работать на большинстве дистрибутивов «из коробки». Проблемы могут быть только если пользователю root запрещен логин на отправляющем сервере. Но это уже отдельная история. Если что — спрашивайте в комментах.

Если вам не надо, чтобы сохранялся в будущем доступ с принимающего сервера на отправляющий, то надо, соответственно, убрать добавленный ключ из файла /root/.ssh/authorized_keys

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

du -sh /var/www/mysite/public/* | sort -hr

, где /var/www/mysite/public/ — корень исследуемого сайта. На выходе вы получите вес всех директорий сайта, отсортированный по убыванию, примерно так:

897M	/var/www/mysite/public/sites
84M	/var/www/mysite/public/core
28M	/var/www/mysite/public/vendor
17M	/var/www/mysite/public/modules
...

Очевидно, что много тяжелых картинок прячутся где-то в /var/www/mysite/public/sites, узнать где именно мы можем повторив поиск и сортировку уже для этого каталога:

du -sh /var/www/mysite/public/sites/* | sort -hr

Ну, вы поняли. Таким методом можно выяснить, где загружаемые картинки лежат в вашем движке. Примеры путей (относительных, от корня сайта) для некоторых популярных движков:

• Для Drupal (вплоть до новой 8-ой версии) — ./sites/default/files/
• Для WordPress — ./wp-content/uploads/

Дальше для установленного пути выполняем:

find /var/www/mysite/public/sites/default/files/ -type f \
\( -iname "*.jpg" -or -iname "*.jpeg" -or -iname "*.png" \) \
-print0 | xargs -0 mogrify -verbose -resize 1000x1000\>

Здесь find отвечает за поиск файлов с расширениями *.png или *.jpeg или *.jpg, а благодаря ключу xargs для каждого из найденных файлов выполняется mogrify (это аналог convert из ImageMagick, но mogrify перезаписывает изменения в тот же файл, в отличии от convert).

И особый интерес представляет ключ -resize 1000x1000\> — его смысл в том, что мы будем изменять размер картинок, но только тех, которые больше, чем 1000 на 1000 пикселей. То есть картинку размеров 640 на 320 мы не тронем вообще, а картинку 1500 на 1200 пропорционально уменьшим (до 1000 на 800). Такая обработка, во-первых, не увеличит никакие картинки, во-вторых, выполнится быстрее.

Ставим необходимые пакеты:

yum -y install pptpd curl bind-utils

Строго говоря, по-настоящему необходим вам будет только pptpd, остальные программы далее для удобства используются (т.е. если вы новичок, то вам перечисленные пакеты помогут узнать сетевой интерфейс и IP-адрес сервера).

Узнаём свой внешний IP-адрес:

curl ifconfig.me

Узнаём название сетевого интерфейса в системе, к которому привязан этот адрес:

route | grep '^default' | grep -o '[^ ]*$'

Для простоты будем считать, что адрес у нас вышел 185.125.1.2, а интерфейс eth0

Редактируем файл /etc/pptpd.conf, добавляем в его конец:

localip 185.125.1.2
remoteip 10.0.0.100-200

Первая строка здесь указывает IP-адрес на котором будет работать PPTP-сервер, этот адрес мы узнавали в начале инструкции. Вторая строка здесь указывает диапазон IP из которого будут выдаваться адреса, подключающимся клиентам.

Далее редактируем /etc/ppp/chap-secrets, добавляем туда строки с аккаунтами пользователей (каждый аккаунт на отдельной строке). Строка через пробелы или табуляцию содержит следующие данные:

• Имя пользователя
• Имя сервера (в нашем случае pptpd)
• Пароль пользователя
• Набор IP-адресов, с которых клиенту разрешено подключаться (в нашем случае * разрешает подключаться с любого IP)

В общем, ваш файл может выглядеть примерно так:

# Secrets for authentication using CHAP
# client server secret IP addresses
antoshka pptpd ytfiHGmG9Fj *
natashka pptpd mHiufgaJh7v *

Теперь редактируем файл /etc/ppp/options, там указываем:

ms-dns 77.88.8.8
ms-dns 77.88.8.1
#ms-dns 8.8.8.8
#ms-dns 8.8.4.4
lock
name pptpd
require-mschap-v2
require-mppe-128

В примере на первых строках используются DNS-серверы Яндекса, а ниже решетками закомментированы DNS-серверы Google. Какие использовать вам — решайте сами.

Запускаем PPTP-сервер:

service pptpd start

Проверяем командой netstat -alpn | grep :1723, что сервер запустился и ждёт соединений. Если всё идёт хорошо, то вы должны увидеть примерно такой вывода:

# netstat -alpn | grep :1723
tcp  0  0 0.0.0.0:1723  0.0.0.0:*  LISTEN  8291/pptpd

Редактируем файл /etc/sysctl.conf, устанавливаем там:

net.ipv4.ip_forward = 1

И запускаем sysctl -p для применения изменений.

Добавляем правило для NAT в фаервол (здесь мы будем использовать имя сетевого интерфейса, которое узнавали в начале статьи):

service iptables start
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE && iptables-save
service iptables save
chkconfig iptables on

Перезапускаем сервис:

service pptpd restart-kill && service pptpd start

Кстати, именно при таком перезапуске (с использованием restart-kill) будут отключены все текущие клиенты.

Добавляем его в автозапуск:

chkconfig pptpd on

Теперь, чтобы подключиться к VPN-серверу в Windows, надо создать новое подключение и выбрать:

Далее указать адрес сервера (который в нашем примере 185.125.1.2), логин и пароль пользователя (мы их прописывали /etc/ppp/chap-secrets). Пока подключение в Windows будет запущено — весь трафик будет идти через него (включая, разумеется, трафик браузера).

Но сначала ставим зависимости:

yum -y install postgresql-libs unixODBC

Затем идём сюда http://sphinxsearch.com/downloads/release/ и смотрим, какая наиболее свежая версия доступна для CentOS 6. На момент написания статьи — это 2.2.11-release. Проходите по ссылке download и далее сможете скопировать прямую ссылку на rpm-пакет по ссылке click here:

В общем, вы ребята взрослые, поэтому прямую ссылку на свежайший пакет, думаю, найти сумеете, поэтому давайте лучше с этой ссылки скорее пакет установим:

rpm -Uvh http://sphinxsearch.com/files/sphinx-2.2.11-2.rhel6.x86_64.rpm

Для хранения бинарного лога Sphinx использует по умолчанию директорию /var/data, можно это изменить в настройках (binlog_path = /var/data), но можно и создать для него директорию:

mkdir /var/data
chown -R sphinx:sphinx /var/data

Теперь всё готово. Запускаем сервис:

service searchd start

Добавляем автозапуск сервиса:

chkconfig searchd on

Строим индекс:

/usr/bin/indexer -c /etc/sphinx/sphinx.conf --rotate --all

Вообще обновление индекса лучше, конечно, добавить в планировщик (crontab -e -u sphinx), сделав запуск, например, раз в 5 минут:

*/5 * * * * /usr/bin/indexer -c /etc/sphinx/sphinx.conf --rotate --all

Для магазина с несколькими тысячами товаров индекс строится за доли секунды (если точнее, то за 0,2-0,3 с на VPS с 4 ядрами), поэтому можно хоть каждую минуту запускать переиндексацию. Если у вас реально большие объёмы данных для индексации, то можно задуматься о дельта-индексах (чтобы перестраивать не весь индекс целиком, а учитывать только измененные данные), но это уже совсем другая история.

P.S. Всех посетителей поздравляю с наступившим новым годом

Your PHP (5.3.3) is quite old, upgrading to PHP 5.3.4 or higher is recommended.
Composer works with 5.3.2+ for most people, but there might be edge case issues.

На работоспособность оно не влияет. Cтавим Composer так:

cd /tmp
curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

C другой стороны, если вы добрались до такого инструмента, как Composer, то, скорее всего, вам будет богомерзко сидеть на старом PHP, поэтому можете сначала обновить PHP, а затем ставить Composer. Тогда и предупреждения не будет.

Допустим, у нас nginx выступает в роли реверс-прокси перед Апачем. Хотя для ситуации, когда nginx отдаёт запросы на fastcgi, проблема может возникнуть та же и действия по её решению будут аналогичными.

Обычно для того, чтобы nginx сам отдавал статику (картинки, стили, скрипты, документы), не дергая Апач, в конфигурацию nginx добавляют примерно такой кусок:

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|pdf|doc|xls)$ {
  root /var/www/mysite/public_html/;
  expires 7d;
}

Нас тут более всего волнует expires 7d, ведь он прикажет браузеру не обновлять картинки в течение недели. Все картинки. Включая нашим злободневные графики.

И тут внимательный читатель уже понял, что можно написать location с исключениями, где поставить более короткий expires. Это верно. Но бывают более запутанные ситуации, когда длинный expires установлен не nginx`ом, а движком сайта или Апачем.

Тогда нам надо просто добавить location, в котором мы заголовок модифицируем принудительно. Чтобы получилось примерно так:

location ^~ /sites/default/files/graph/ {
  add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
  add_header Pragma "no-cache";
  proxy_pass http://127.0.0.1:8888;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Real-IP $remote_addr;
}

location / {
  proxy_pass http://127.0.0.1:8888;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Real-IP $remote_addr;
}

Первые пару строк первого location как раз допишут такие заголовки, чтоб картинки по урлам */sites/default/files/graph/… не закешировались.