Вообщем можно применять разные подходы для отправки писем на внешний почтовый ящик. Но в большинстве случаев у нас нет собственного почтового сервера для беспроблемной отправки сообщений в мир.
Вот и у меня так. Почтовый домен висит на службах гугля. А с одного из серверов надо отправлять сообщения. Можно в принципе использовать конфигурацию по умолчанию с поднятым каким-либо MTA, но тогда велика верояность попадания таких писем в спам.
Таким образом если у нас есть почтовый ящик на gmail, то мы можем использовать этот логин для отправки писем от этой учетной записи. Как пишут есть ограничение — 500 писем в сутки.
Появился «проблемный» mysq сервер. Проблема заключалась в том, что место на разделе где лежат файлы mysql подошло к концу. При этом реальный объем всех баз был значительно меньше того которое они реально занимали на разделе. Это объясняется тем, что это тестовый сервер в который очень много загнали данных, а потом большую часть удалили. При этом параметр innodb_file_per_table изначально не был активирован в конфиге, а был добавлен уже в процессе работы сервера. Поэтому файл ibdata1 вырос до огромных размеров — 80% от размера раздела.
Вообщем со всем этим надо было что-то делать. И решение быстро нашлось.
Вообщем это мега костыль. Суть в том, что есть один из нагруженных серверов, который доживает последние дни в предверии перезда на новый инстанс. При этом появился глюк, что php не удаляет устаревшие сессии на диске.
curl https:
//
shellshocker.net
/
shellshock_test.sh
|
bash
%
Total
%
Received
%
Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100
2533
100
2533
0
0
3855
0
--:--:-- --:--:-- --:--:--
3867
CVE-
2014
-
6271
(
original shellshock
)
: not vulnerable
CVE-
2014
-
6277
(
segfault
)
: not vulnerable
CVE-
2014
-
6278
(
Florian
's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
.
/
bashcheck
Not vulnerable to CVE-
2014
-
6271
(
original shellshock
)
Not vulnerable to CVE-
2014
-
7169
(
taviso bug
)
Not vulnerable to CVE-
2014
-
7186
(
redir_stack bug
)
Test
for
CVE-
2014
-
7187
not reliable without address sanitizer
Variable
function
parser inactive, likely safe from unknown parser bugs
Когда необходимо что-то автоматизировать можно воспользоваться таким инструментом как
. Мне он пригодился когда было необходимо выполнить определенные действия на удаленных хостах под управлением linux и sunos. Также expect отлично подходит для автоматизации задач связанных с сетевым оборудованием.
У каждого админа есть загрузочная флешка с той или иной ОС или какими-либо утилитами. Мне нужна была мультизагрузочная флешка с различными linux, windows и некоторыми дополнительными утилитами.
Встретил интересную задачку: написать shell скрипт который производил бы анализ процессов mysql и удалял те, что в коннекте более 5 мин исключая системные процессы (к примеру репликации), а так же отсылку по почте предупреждения если в логе ошибок mysql встречается строка ABCDEFGH.
В наличии openSUSE 12.3 x86-64 на которой установлен mysql 5.5.32.
Также есть рабочий комп с этой же версий ОС.
Соответсвенно надо собрать rpm-ки для сервера, чтобы не заниматься ерундой — сборкой на самом сервере.
Сборку будем осуществлять под юзером builder.
Когда админишь более сотни баз, то вопрос переноса некоторых схем с одного сервера на другой не так уж и тривиален — к схемам имеют доступ десятки пользователей с различными правами.
Вообщем навоял скрипт ниже. Для работоспособности необходим
. Работоспособность проверена на openSUSE 12.3.
Задача:
необходимо собрать общую статистику по подключениям к серверу mysql. Интересует следующие данные – пользователь, ip адрес, БД к которой идет подключение.
Задача решается в два этапа:
В наследство досталась лицензия на TeamViewer 5. Возникла необходимость установить данное ПО на все рабочие станции в windows домене. В качестве клиентов – Windows 7 x64.
Задача довольна тривиальна. Однако было потрачено достаточно много времени на выяснение почему не применяются настройки заданные через файл реестра в процессе установки данного ПО.
Приходит время когда даже мощный и
оптимизированный сервер mysql
не справляется с нагрузкой. Чтобы вернуть былую скорость необходимо время от времени проводить очистку базы данных OTRS. Под очисткой я имею ввиду удаление успешно закрытых и объединенных тикитов. Чтобы иметь возможность в дальнейшем просмотреть эти тикиты необходимо перед очисткой произвести перенос тикитов и их вложений на архивный сервер OTRS.