1. Айпи привязывается к домену через А-запись в DNS. Вы зайдите во вкладку IP&DNS панели управления Скалакси: там второй блок называется «Обратные зоны» и в нем должен быть прописан домен и айпишник.
2. В /etc/hostname должен быть прописан домен, с адреса которого отправляются письма. То есть, если у Вас адрес (с которого отправляются уведомления) aaaa@bbbb.ccc, то именно bbbb.ccc и должно быть прописано в файле. У вас какой домен, если не секрет?
3. Аналогично второму пункту. Надо прописывать вместо OG — доменное имя.
4. Вы сервер сами настраивали? Какая операционка, версия?
6. Я привязываю домен к Google Apps, чтобы пользоваться почтой гугла с именем ящика на своем домене. ИМХО это проще и надежней, чем устанавливать на своем сервере почтовый сервер. Не говоря уже о том, чтобы настраивать антиспам, который у гугла на мой взгляд один из лучших.
У самого 2 проекта ЛС на Скалакси. Сталкивался с проблемой попадания письма в спам на мэйл.ру и других почтовых сервисах.
Проблему решил следующим способом. Пусть почта отправляется с адреса info@mysite.ru (для примеров).
1. В идеале на одном айпишнике должен быть один сайт. В панеле Скалакси во вкладке IP&DNS прописываем для основного домена обратные зоны PTR (привязываем к домену айпи). В некоторых сервисах антиспам проверяет корректность обратных зон. Пример: mysite.ru в «обратных зонах» должен быть привязан к айпишнику на котором он находится.
2. Прописываем в hostname домен. Пример: набираем в SSH-терминале сервера «hostname mysite.ru» и проверяем в файлике /etc/hostname правильно ли указан домен.
3. Смотрим в файлике /etc/hosts, правильно ли указан домен. Пример: 188.127.229.85 mysite.ru.clients.scalaxy.ru mysite.ru
4. Внимательно настраиваем EXIM (если он используется в качестве MTA, например как у меня). Набираем в SSH-терминале сервера: dpkg-reconfigure exim4-config и следуем по шагам. В гугле-яндексе можно найти много описаний как пройти эти шаги.
5. Можно просмотреть все настройки EXIM в конфиге (у меня находится в /var/lib/exim4/config.autogenerated). Например, могут возникнуть домены, если почта домена привязана к Google Apps. Тогда в файлике надо прописать «MAIN_LOCAL_DOMAINS=:localhost:» вместо «MAIN_LOCAL_DOMAINS=@:localhost:localhost.localdomain». Только учтите, что файл config.autogenerated перезапишется при автоматическом конфигурировании (с помощью dpkg-reconfigure exim4-config).
6. Правильно прописать SPF в TXT-записи для домена. Например, у меня прописано так (почта привязана к гуглу):
Вроде все. Главное в логах смотреть /var/spool/exim4/ — туда падают возвращенные письма. Ну и /var/spool/exim4/msglog/ — текст сообщений об ошибках. Главный лог EXIM: /var/log/exim4/mainlog. Я по логам начинал разбираться, находя в интернете решения по кодам ошибок.
Если такого файла нет, то создаем и добавляем строчку.
3,8,13,18,23,28,33,38,43,48,53,58 — это минуты в течении часа, по которым происходит индексация. Тут каждые 5 минут, начиная с третьей минуты.
3,23,43 — это каждые 20 минут, начиная с третьей минуты.
Почему с третьей? ИМХО, главное, чтобы было не кратно 0,5,10..., так как другие сервисы при установке любят забивать минуты кратные пятерке. А одновременно выполнять несколько скриптов — создавать пиковые нагрузки, когда можно без этого обойтись, разнеся выполнение по времени.
Как часто индексировать зависит от того, насколько нужен актуальный поиск. На проекте, где в минуту несколько комментариев и каждые час 1-2 топика, я ставлю индексацию раз в 5 минут. И пользователи активно пользуют поиском (например, проверяя, есть ли топики на срочное событие, чтобы не дублироваться).
Под дебиан squeeze установка намного проще (на данный момент в репозитарии версия 0.9.9):
apt-get install sphinxsearch
В /etc/default/sphinxsearch устанавливаем START=yes
В /etc/sphinxsearch/ редактируем файл (или тупо копируем), меняя 3 значения (обозначены звездочками) sphinx.conf как тут. В файле все прокомментировано по русски.
В ЛивСтрите соответственно указываем в {папка сайта}/config/modules/search/config.php (конфиг сфинкса, лежит изначально):
$config['entity_prefix'] = 'MAIN';
— это сделано для того, чтобы была возможность индексировать несколько разных сайтов на ЛС, указывая разные префиксы.
и настраиваем ее на регулярное выполнение (у меня раз в 10 минут индексируется сайт).
Перезапускаем сфинкс:
searchd --stop
searchd
Проверяем доступность порта:
telnet localhost 3312
Если «Connected to localhost.», то все отлично. Нажимаем «Ctrl-]» и выходим из телнета — «с».
Можно запустить принудительную индексацию вручную (чтобы не ждать следующей индексации по крону):
/usr/bin/indexer --quiet --rotate --all
Работоспособность и возможные ошибки можно выявить в логах (указанных в вышеприведенном конфиге), которые лежат в каталоге /var/log/sphinxsearch/.
Вроде все. Установка должна занять не более 10 минут.
(Хотя, когда я только начинал администрировать сервак, долго разбирался даже по мануалам).
Есть глюк с плагином Draft Auto Save: при редактировании поста через некоторое время он делает автосейв в черновики и сбивает дату. Причем, если не нажать на кнопку публикации поста — пост останется в черновиках.
Нет, только в редких случаях. Подозреваю, что такое случается, когда одновременно с удалением кто-то из пользователей постит комментарий в удаляемый топик.
Я так думаю по тому, что у меня было несколько случаев, когда я удалял очень обсуждаемые топики (комментарии постились примерно каждые 10 секунд). И с тех пор, когда я начал перед удалением сохранять топик в черновики — ошибка больше не возникала.
Если сайт хорошо посещаемый, то при удалении топика очень вероятно получить ситуацию, когда в это время кто-то будет постить комментарий. Пару раз нарывался — после чего чистил базу данных вышеописанным способом. Чтобы минимизировать или избежать такой ошибки, теперь я сначала отправляю топик в черновики, жду 10 минут, а затем удаляю его.
Такая ошибка может возникнуть, когда удаляешь топик с комментариями. Причем при удалении топика комментарии не удаляются и нарушаются связи в базе данных (БД).
В phpmyadmin (или в другом менеджере БД сайта) сделайте запрос:
select * from prefix_comment where target_id not in (select topic_id from prefix_topic) AND target_type = "topic"
Если появится список таких непривязанных комментариев — можете их удалить вручную (по одному) или попытаться удалить командой:
delete from prefix_comment where target_id = XXX
, где ХХХ — это ID-шник удаленного топика, от которого остались висеть комментарии (его номер Вы можете увидеть в таблице вывода предыдущего запроса — у «висящих» комментариев target_id обычно один и тот же, вот его и надо указывать в ХХХ).
Если было удалено несколько топиков, то у «висящих» комментариев будут несколько разных target_id. Следовательно нужно сделать несколько запросов delete…
Если среди «висящих» комментариев есть вложенные, то удалить сразу все такие комментарии одной командой не получится. В таком случае можно вывести список:
select * from prefix_comment where target_id = XXX
и удалять вручную по несколько штук, начиная с последнего комментария (обратная сортировка по comment_id).
Внимание: delete выполняйте на СВОЙ страх и риск. Если Вы хорошо не разбираетесь в MySQL, то нечаянно этой командой Вы можете грохнуть БД сайта.
Сам вначале разбирался около часа, потом (если возникает) делаю за пару минут.
А вообще, подробней можно почитать на Хабре: habrahabr.ru/post/147745/
Выглядит и работает так.
2. В /etc/hostname должен быть прописан домен, с адреса которого отправляются письма. То есть, если у Вас адрес (с которого отправляются уведомления) aaaa@bbbb.ccc, то именно bbbb.ccc и должно быть прописано в файле. У вас какой домен, если не секрет?
3. Аналогично второму пункту. Надо прописывать вместо OG — доменное имя.
4. Вы сервер сами настраивали? Какая операционка, версия?
6. Я привязываю домен к Google Apps, чтобы пользоваться почтой гугла с именем ящика на своем домене. ИМХО это проще и надежней, чем устанавливать на своем сервере почтовый сервер. Не говоря уже о том, чтобы настраивать антиспам, который у гугла на мой взгляд один из лучших.
Например, могут возникнуть проблемы, если почта домена привязана к Google Apps.
Проблему решил следующим способом.
Пусть почта отправляется с адреса info@mysite.ru (для примеров).
1. В идеале на одном айпишнике должен быть один сайт. В панеле Скалакси во вкладке IP&DNS прописываем для основного домена обратные зоны PTR (привязываем к домену айпи). В некоторых сервисах антиспам проверяет корректность обратных зон. Пример: mysite.ru в «обратных зонах» должен быть привязан к айпишнику на котором он находится.
2. Прописываем в hostname домен. Пример: набираем в SSH-терминале сервера «hostname mysite.ru» и проверяем в файлике /etc/hostname правильно ли указан домен.
3. Смотрим в файлике /etc/hosts, правильно ли указан домен. Пример: 188.127.229.85 mysite.ru.clients.scalaxy.ru mysite.ru
4. Внимательно настраиваем EXIM (если он используется в качестве MTA, например как у меня). Набираем в SSH-терминале сервера: dpkg-reconfigure exim4-config и следуем по шагам. В гугле-яндексе можно найти много описаний как пройти эти шаги.
5. Можно просмотреть все настройки EXIM в конфиге (у меня находится в /var/lib/exim4/config.autogenerated). Например, могут возникнуть домены, если почта домена привязана к Google Apps. Тогда в файлике надо прописать «MAIN_LOCAL_DOMAINS=:localhost:» вместо «MAIN_LOCAL_DOMAINS=@:localhost:localhost.localdomain». Только учтите, что файл config.autogenerated перезапишется при автоматическом конфигурировании (с помощью dpkg-reconfigure exim4-config).
6. Правильно прописать SPF в TXT-записи для домена. Например, у меня прописано так (почта привязана к гуглу):
7. Есть хорошие сервисы для проверки SPF: www.openspf.org/Why?show-form=1
8. Ну и интересная статья: habrahabr.ru/post/114852/
Вроде все. Главное в логах смотреть /var/spool/exim4/ — туда падают возвращенные письма. Ну и /var/spool/exim4/msglog/ — текст сообщений об ошибках. Главный лог EXIM: /var/log/exim4/mainlog. Я по логам начинал разбираться, находя в интернете решения по кодам ошибок.
Если такого файла нет, то создаем и добавляем строчку.
3,8,13,18,23,28,33,38,43,48,53,58 — это минуты в течении часа, по которым происходит индексация. Тут каждые 5 минут, начиная с третьей минуты.
3,23,43 — это каждые 20 минут, начиная с третьей минуты.
Почему с третьей? ИМХО, главное, чтобы было не кратно 0,5,10..., так как другие сервисы при установке любят забивать минуты кратные пятерке. А одновременно выполнять несколько скриптов — создавать пиковые нагрузки, когда можно без этого обойтись, разнеся выполнение по времени.
Как часто индексировать зависит от того, насколько нужен актуальный поиск. На проекте, где в минуту несколько комментариев и каждые час 1-2 топика, я ставлю индексацию раз в 5 минут. И пользователи активно пользуют поиском (например, проверяя, есть ли топики на срочное событие, чтобы не дублироваться).
В /etc/default/sphinxsearch устанавливаем START=yes
В /etc/sphinxsearch/ редактируем файл (или тупо копируем), меняя 3 значения (обозначены звездочками) sphinx.conf как тут. В файле все прокомментировано по русски.
В ЛивСтрите соответственно указываем в {папка сайта}/config/modules/search/config.php (конфиг сфинкса, лежит изначально):
— это сделано для того, чтобы была возможность индексировать несколько разных сайтов на ЛС, указывая разные префиксы.
Проверяем, есть ли следующая строчка в CRONе:
и настраиваем ее на регулярное выполнение (у меня раз в 10 минут индексируется сайт).
Перезапускаем сфинкс:
Проверяем доступность порта:
Если «Connected to localhost.», то все отлично. Нажимаем «Ctrl-]» и выходим из телнета — «с».
Можно запустить принудительную индексацию вручную (чтобы не ждать следующей индексации по крону):
Работоспособность и возможные ошибки можно выявить в логах (указанных в вышеприведенном конфиге), которые лежат в каталоге /var/log/sphinxsearch/.
Вроде все. Установка должна занять не более 10 минут.
(Хотя, когда я только начинал администрировать сервак, долго разбирался даже по мануалам).
Для участников социальной сети, для которой был приобретен ваш плагин, это стало проблемой и мы не смогли использовать плагин автосохранения.
Я так думаю по тому, что у меня было несколько случаев, когда я удалял очень обсуждаемые топики (комментарии постились примерно каждые 10 секунд). И с тех пор, когда я начал перед удалением сохранять топик в черновики — ошибка больше не возникала.
Если сайт хорошо посещаемый, то при удалении топика очень вероятно получить ситуацию, когда в это время кто-то будет постить комментарий. Пару раз нарывался — после чего чистил базу данных вышеописанным способом. Чтобы минимизировать или избежать такой ошибки, теперь я сначала отправляю топик в черновики, жду 10 минут, а затем удаляю его.
В phpmyadmin (или в другом менеджере БД сайта) сделайте запрос:
Если появится список таких непривязанных комментариев — можете их удалить вручную (по одному) или попытаться удалить командой:
, где ХХХ — это ID-шник удаленного топика, от которого остались висеть комментарии (его номер Вы можете увидеть в таблице вывода предыдущего запроса — у «висящих» комментариев target_id обычно один и тот же, вот его и надо указывать в ХХХ).
Если было удалено несколько топиков, то у «висящих» комментариев будут несколько разных target_id. Следовательно нужно сделать несколько запросов delete…
Если среди «висящих» комментариев есть вложенные, то удалить сразу все такие комментарии одной командой не получится. В таком случае можно вывести список:
и удалять вручную по несколько штук, начиная с последнего комментария (обратная сортировка по comment_id).
Внимание: delete выполняйте на СВОЙ страх и риск. Если Вы хорошо не разбираетесь в MySQL, то нечаянно этой командой Вы можете грохнуть БД сайта.
Сам вначале разбирался около часа, потом (если возникает) делаю за пару минут.