Вообщем можно применять разные подходы для отправки писем на внешний почтовый ящик. Но в большинстве случаев у нас нет собственного почтового сервера для беспроблемной отправки сообщений в мир.
Вот и у меня так. Почтовый домен висит на службах гугля. А с одного из серверов надо отправлять сообщения. Можно в принципе использовать конфигурацию по умолчанию с поднятым каким-либо MTA, но тогда велика верояность попадания таких писем в спам.
Таким образом если у нас есть почтовый ящик на gmail, то мы можем использовать этот логин для отправки писем от этой учетной записи. Как пишут есть ограничение — 500 писем в сутки.
Появился «проблемный» mysq сервер. Проблема заключалась в том, что место на разделе где лежат файлы mysql подошло к концу. При этом реальный объем всех баз был значительно меньше того которое они реально занимали на разделе. Это объясняется тем, что это тестовый сервер в который очень много загнали данных, а потом большую часть удалили. При этом параметр innodb_file_per_table изначально не был активирован в конфиге, а был добавлен уже в процессе работы сервера. Поэтому файл ibdata1 вырос до огромных размеров — 80% от размера раздела.
Вообщем со всем этим надо было что-то делать. И решение быстро нашлось.
Вообщем это мега костыль. Суть в том, что есть один из нагруженных серверов, который доживает последние дни в предверии перезда на новый инстанс. При этом появился глюк, что php не удаляет устаревшие сессии на диске.
Когда необходимо что-то автоматизировать можно воспользоваться таким инструментом как
expect
. Мне он пригодился когда было необходимо выполнить определенные действия на удаленных хостах под управлением linux и sunos. Также expect отлично подходит для автоматизации задач связанных с сетевым оборудованием.
У каждого админа есть загрузочная флешка с той или иной ОС или какими-либо утилитами. Мне нужна была мультизагрузочная флешка с различными linux, windows и некоторыми дополнительными утилитами.
В наличии openSUSE 12.3 x86-64 на которой установлен mysql 5.5.32.
Также есть рабочий комп с этой же версий ОС.
Соответсвенно надо собрать rpm-ки для сервера, чтобы не заниматься ерундой — сборкой на самом сервере.
Сборку будем осуществлять под юзером builder.
Приходит время когда даже мощный и
оптимизированный сервер mysql
не справляется с нагрузкой. Чтобы вернуть былую скорость необходимо время от времени проводить очистку базы данных OTRS. Под очисткой я имею ввиду удаление успешно закрытых и объединенных тикитов. Чтобы иметь возможность в дальнейшем просмотреть эти тикиты необходимо перед очисткой произвести перенос тикитов и их вложений на архивный сервер OTRS.
Когда у вас в OTRS несколько тысяч пользователей, более тысячи очередей, групп и ролей намного эффективнее получать и работать с информацией через запросы к БД нежели через web-интерефейс.
Для облегчения администрирования OTRS я использую некоторые SQL запросы.
Используемая версия OTRS 2.4.9. В качесте БД — MySQL 5.
В наличии архивный сервер OTRS на который раз в несколько месяцев сливаются старые тикиты с промышленного сервера. На этом сервере не хватает места под хранение файлов на жестком диске. При этом сервер относительно современный (IBM eServer BladeCenter HS21) и его можно использовать под более нагруженные задачи, чем архивная копия OTRS. А OTRS в свою очередь можно перенести на менее мощный сервер у которого более объемные жесткие диски.
Используемая версия OTRS — 2.4.9.
Преимущества перед старым скриптом:
1. Бекап всех БД mysql
2. Уведомление на e-mail
3. Не используется временный каталог для бекапа
4. После копирования удаляет старые архивы на удаленном сервере
5. Удаляет последний архив на локальном сервере