После анализа взлома сайта потребовалось выставить для всех файлов и папок определенную дату и время, выполняем:

cd /var/www/
find ./ -type f -exec touch -t 201611211300 {} + 
find ./ -type d -exec touch -t 201611211300 {} +

Получаем дату модификации 2016г. 21 ноября 13-00

Для создания резервной копии воспользуемся утилитой pg_dump, которая позволяет создать дамп для указанной БД. Создание дампа происходит без блокирования таблиц и представдляет снимок БД на момент выполнения команды. Т. е. вы можете создавать дампы во время работы пользователей, в то время как для создания резервной копии средствами 1С вам нужен монопольный доступ к базе.

Синтаксис pg_dump предельно прост, нам нужно указать имя базы и расположение и название файла дампа. Просмотреть список баз можно командой:

psql -U postgres -l

Кроме списка баз вывод содержит ряд полезной информации, например о кодировке базы, данная информация пригодится нам при восстановлении БД на другом сервере.

Теперь, уточнив наименование баз на сервере создадим резервную копию базы unf14:

pg_dump -U postgres unf14 > ~/unf14.pgsql.backup

sudo -u postgres pg_dump chat > /home/user/chat.sql

результатом выполнения команды будет файл дампа в домашней директории. Расширение файла мы рекомендуем указывать таким образом, чтобы по нему было понятно назначение данного файла и оно может быть любым. В нашем случае мы используем pgsql.backup, глянув на такой файл сразу станет понятно о его назанчении, это может быть важно, если поиском дампов будут заниматься ваши коллеги. Также мы не рекомендуем использовать расширение .bak, потому что многие утилиты «для оптимизации» удаляют такие файлы.

При необходимости можем создать сжатый дамп:

pg_dump -U postgres unf14 | gzip > ~/unf14.pgsql.gz

Сжатие позволяет уменьшить размер дампов примерно вдвое, поэтому следует его использвать при передаче резервных копий по сети интернет или при ограниченном размере хранилища.

Перед восстановлением дампа следует создать целевую БД (при ее остутсвии), хотя мы рекомендуем делать это всегда. Еще одна БД есть не просит, зато избавляет от распространенной ситуации, когда залили не тот дамп или не в ту базу. Для создания базы выполним:

createdb -T template0 unf14

На платформе Линукс эта команда будет выглядеть так:

psql -U postgres unf14 < ~/unf14.pgsql.backup

sudo -u postgres psql chat < /home/user/chat.sql

Добавляем на маршрутизатор в conf t

snmp-server community ciscoswitch RO

После этого создаем конфиг свитча

/usr/local/bin/cfgmaker ciscoswitch@192.168.88.1 —output=internet.cfg

tmux

— это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как

screen

, только лучше (в первую очередь потому, что использует модель клиент—сервер).

Очень хороший способ запустить tmux:

tmux attach || tmux new

 — делая так, вы сперва пытаетесь подключиться к уже существующему серверу tmux, если он существует; если такого ещё нет — создаёте новый.

После этого вы попадаете в полноценную консоль.
Ctrl+b d — отключиться. (Точно так же вы отключитесь, если прервётся соединение. Как подключиться обратно и продолжить работу — см. выше.)

В одной сессии может быть сколько угодно окошек:
Ctrl+b c — создать окошко;
Ctrl+b 0...9 — перейти в такое-то окошко;
Ctrl+b p — перейти в предыдущее окошко;
Ctrl+b n — перейти в следующее окошко;
Ctrl+b l — перейти в предыдущее активное окошко (из которого вы переключились в текущее);
Ctrl+b & — закрыть окошко (а можно просто набрать

exit

в терминале).

В одном окошке может быть много панелей:
Ctrl+b % — разделить текущую панель на две, по вертикали;
Ctrl+b « — разделить текущую панель на две, по горизонтали (это кавычка, которая около Enter, а не Shift+2);
Ctrl+b →←↑↓ — переходить между панелями;
Ctrl+b x — закрыть панель (а можно просто набрать

exit

в терминале).

Недостаток — непривычным становится скроллинг:
Ctrl+b PgUp — вход в «режим копирования», после чего:
PgUp, PgDown — скроллинг;
q — выход из «режима копирования».

Открываем EMS (Exchange Management Shell) и вводим вот такую строку.

Get-OfflineAddressbook | Update-OfflineAddressbook

еще как вариант можно перезапустить службу Помощники по обслуживанию почтовых ящиков Microsoft Exchange, это тоже поможет сделать обновление адресной книги в Exchange 2013.

net stop MSExchangeSA & net start MSExchangeSA

Потом на клиентской машине в Outlook 2013 нажимаем на ленте Отправка и получение > Группы отправки и получения > Загрузить адресную книгу

ntp update-calendar
ntp server 64.90.182.55

Router(config)#clock timezone MSK 4
Router(config)#clock calendar-valid

Router#show clock
11:17:44.500 MSK Tue Feb 26 2013

Для выставления правильного времени в логах:

service timestamps log datetime localtime

Ну и заодно в режиме отладки

service timestamps debug datetime localtime

Защита ssh от перебора

login block-for 60 attempts 3 within 20 # устанавливает задержку в 60 секунд, если было 3 попытки входа в течение 20 секунд
login delay 5 # задержка в 5 секунд между попытками входа
login on-failure log
login on-success log

Подключатся нужно к порту 6432 (Он, кстати, стал стандартом...).
Вобщем у меня всё заработало.

Для просмотра диагностики pgBouncer`a

sudo psql -p 6432 pgbouncer -U postgres

Список команд — тут.

Для затравки:
show help;
show pools;
show clients;

Часто приходится встречать на форумах, посвященных системам хранения от IBM, жалобы пользователей, столкнувшихся с проблемой: «вставляю диск в систему, а она его не видит. что делать??!!». На вопрос «откуда взяли диски», обычно, следует ответ «на ebay купили...». Оно и понятно — стандартная гарантия IBM на популярные модели DS4800, DS4700  в большинстве своем, давно закончилась, сервисную поддержку далеко не все продлевают, вот и выкручиваются люди, как могут.

Итак. Купили диск (на ebay), вставили в систему, но диск не идентифицируется. Или проще — вытащили из одной своей системы заведомо исправный диск, вставили в другую...  а диск не распознается. Кто виноват и что делать?

Для начала, немножко ликбеза.

Обычно, когда в систему вставляется новый, чистый диск, IBM’овские СХД инициализируют его, записывая в начало  диска служебную область размером 512 Мб, которая называется DACstore. Там хранится различная информация о конфигурации системы хранения: конфигурация логических  дисков, MEL логи, информация о подключенных хостах и т. п. Подробнее о DACstore можно почитать тут. Если диск ранее использовался в другой системе DS System Storage, то существующий DACstore будет перезаписан. И вот тут есть ньюанс. Начиная с версии микрокода 7.10, формат DACstore поменялся. Поэтому, если на системе более старая версия прошивки версии 7.xx и любая версия прошивки 6.хх (даже та, которая вышла позже 7.10), СХД просто не сможет инициализировать диск. Это и есть ситуация «не видит диск». Такие б/у диски, хоть и с фирменной лейбой IBM, но не очищеные должным образом предыдущими владельцами — не редкость даже на складах системных интеграторов. Что уж говорить про диски «с ebay».

«Лечение» в данной ситуации следующее:

-> luall
.......Logical Unit........:    :Channels.:Que ............IOs...........
Devnum Location Role   :ORP : 0 1 2 3 :Dep  Qd  Open  Completed  Errs
---------- -------- ------ :--- : - - - - :--- --- ----- ---------- -----
00000010  t0        Encl :++  : A   B   :  1   0     0        148     6
00100001  t0,s1     FCdr :+++ : *   +   : 16   0     0        178     2
00100002  t0,s2     FCdr :+++ : +   *   : 16   0     0        176     2
00100003  t0,s3     FCdr :+++ : *   +   : 16   0     0        177     2
00100004  t0,s4     FCdr :+++ : +   *   : 16   0     0        179     2
00100005  t0,s5     FCdr :+++ : *   +   : 16   0     0        177     2
00100006  t0,s6     FCdr :+++ : +   *   : 16   0     0        298     5
00100007  t0,s7     FCdr :+++ : *   +   : 16   0     0        470     4
00100008  t0,s8     FCdr :+++ : +   *   : 16   0     0        473     3
00100009  t0,s9     FCdr :+++ : *   +   : 16   0     0         25     1
0010000a  t0,s10    FCdr :+++ : +   *   : 16   0     0         25     1
0010000b  t0,s11    FCdr :+++ : *   +   : 16   0     0         25     1
0010000c  t0,s12    FCdr :+++ : +   *   : 16   0     0         25     1
0010000d  t0,s13    FCdr :+++ : *   +   : 16   0     0         25     1
0010000e  t0,s14    FCdr :+++ : +   *   : 16   0     0         25     1
0010000f  t0,s15    FCdr :+++ : *   +   : 16   0     0         25     1
00200000  t0,s16    FCdr :+++ : +   *   : 16   0     0        571     7
00e00011   c,this     Bm :++  : + * + + : 32   0     0          0     0
00f00011   c,alt      Am :++  : + * + + : 32   0     0       3532     1

Подробно объяснять вывод данной команды не буду, обратите внимания лишь на вторую колонку: это номер корзины расширения (ID на LED индикаторе на ESM, сзади полки)+номер диска. К примеру t0,s16 — 16-й диск на полке с ID 0. Очистка dacStore выполняется командой isp cfgWipe1,0x<DEVNUM> для версии микрокода 6.хх, в нашем случае:

isp cfgWipe1,0x00200000

Команда для очистки для версии 7.хх

isp dsmWipe 0xdevnum, 0

Обратите внимание — если последним параметром указать 1, то DACstore будет перезаписан сразу после очистки. В нашем случае — мы указываем 0, поэтому DACstore будет записан только после извлечения и повторной вставки диска в СХД (ну или при выполнении процедуры SOD, но это уже совсем другая история).

Сброс цикла жизни батарей

Если батарейка в норме, то можно попробовать сделать так:

Please disable the caches using the following script commands:
set allLogicalDrives writeCacheEnabled=false; set allLogicalDrives mirrorCacheEnabled=false;

For each Logical Drive, the WCMir and WC can then be enabled again with the following script commands:
set logicalDrive [«logical_drive_name»] mirrorCacheEnabled=true; set logicalDrive [«logical_drive_name»] writeCacheEnabled=true;

В данной статье хочу рассказать о том, как немного повысить производительность хоста ESXi с помощью SSD кэширования. На работе и дома я использую продукты от компании VMware, домашняя лаборатория построена на базе Free ESXi 6.5. На хосте запущены виртуальные машины как для домашней инфраструктуры, так и для тестирования некоторых рабочих проектов (как-то мне пришлось запустить на нем инфраструктуру VDI). Постепенно приложения толстых ВМ начали упираться в производительность дисковой системы, а на SDD все не помещалось. В качестве решения был выбран lvmcache. Логическая схема выглядит так:

Основой всей схемы является ВМ svm на базе CentOS 7. Ей презентованы HDD диски средствами RDM и небольшой диск VMDK с датастора SSD. Кэширование и зеркалирование данных реализуются программными средствами — mdadm и lvmcache. Дисковое пространство ВМ монтируется к хосту как NFS датастор. Часть датастора SSD отведена ВМ, которым требуется производительная дисковая подсистема.

Вычислительный узел собран на десктопном железе:

MB: Gygabyte GA-Z68MX-UD2H-B3 (rev. 1.0)
HDD: 2 x Seagate Barracuda 750Gb, 7200 rpm
SSH: OCZ Vertex 3 240Gb

На материнской плате имеется 2 RAID контроллера:

— Intel Z68 SATA Controller
— Marvell 88SE9172 SATA Controller

Завести 88SE9172 в ESXi у меня не получилось (There is a bug in the firmware of some Marvell adapters (at least 88SE91xx)), решил оставить оба контроллера в режиме ACHI.

RDM

— Виртуальный режим — работает так же, как и в случае с файлом виртуального диска, позволяет использовать преимущества виртуального диска в VMFS (механизм блокировки файлов, мгновенные снэпшоты);
— Физический режим — предоставляет прямой доступ к устройству для приложений, которые требуют более низкого уровня управления.

В виртуальном режиме на физическое устройство отправляются операции чтения\записи. RDM устройство представлено в гостевой ОС как файл виртуального диска, аппаратные характеристики скрыты.

В физическом режиме на устройство передаются практически все команды SCSI, в гостевой ОС устройство представлено как реальное.

Подключив дисковые накопители к ВМ средствами RDM, можно избавиться от прослойки VMFS, а в физическом режиме совместимости их состояние можно будет мониторить в ВМ (с помощью технологии S.M.A.R.T.). К тому же, если что-то случится с хостом, то получить доступ к ВМ можно, примонтировав HDD к рабочей системе.

lvmcache

При попытке чтения данных выясняется, имеются ли эти данные в кэше. Если требуемых данных там нет, то чтение происходит с HDD, и попутно данные записываются в кэш (cache miss). Дальнейшее чтение данных будет происходить из кэша (cache hit).

Запись

Так выглядит сброс данных из кэша (write-back) на диски:

Настройка системы

220Gb — DATASTORE_SSD
149Gb — Отведено для особых ВМ
61Gb — Том для кэша и метаданных
10Gb — Host Swap Cache

Виртуальная сеть выглядит следующим образом:

Создан новый vSwitch:

Networking → Virtual Switches → Add standart virtual switch — указываем желаемое имя виртуального свитча (svm_vSwitch, в названиях я использую префикс svm_), остальное оставляем как есть.

К нему через порт группу подключается VMkernel NIC:

Networking → VMkernel NICs → Add VMkernel NIC
— Port group — New Port group
— New port group — Имя порт группы — svm_PG
— Virtual switch — svm_vSwitch
— IPv4 settings — Configuration — Static — указываем IP и маску сети

Создана порт группа, к которой будет подключена ВМ svm:

Networking → Port Groups → Add port group — указываем имя (svm_Network) и свитч svm_vSwitch

Подготовка дисков

Отобразить пути всех подключенных дисков:
	# ls -lh /vmfs/devices/disks/
lrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434845535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*E
lrwxrwxrwx    1 root     root          72 Feb 22 20:24 vml.01000000002020202020202020202020203956504257434b46535433373530 -> t10.ATA_____ST3750525AS_________________________________________9*F

Перейти в директорию, где будут размещаться «mapping file»:
	# cd /vmfs/volumes/DATASTORE_SSD/

Создаем RDM в режиме виртуальной совместимости:
	# vmkfstools -r /vmfs/devices/disks/vml.01000000002020202020202020202020203956504257434845535433373530 9*E.vmdk
	# vmkfstools -r /vmfs/devices/disks/vml.01000000002020202020202020202020203956504257434b46535433373530 9*F.vmdk

Подготовка ВМ

Настройка NFS сервера довольно проста:

# yum install nfs-utils
# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server
# vi /etc/exports
	/data 10.0.0.1(rw,sync,no_root_squash,no_subtree_check)
# exportfs -ar
# firewall-cmd add-service=nfs permanent
# firewall-cmd add-service=rpc-bind permanent
# firewall-cmd add-service=mountd permanent
# firewall-cmd —reload

Подготавливаем тома кэша и метаданных для включения кэширования тома cl_svm/data:

Инициализация диска и расширение группы томов:
	# pvcreate /dev/sdc
	# vgextend cl_svm /dev/sdc
Создание тома с метаданными, в «man» написано, что этот том должен быть в 1000 раз меньше тома с кэшем:
	# lvcreate -L 60M -n meta cl_svm /dev/sdc
Создание тома с кэшем:
	# lvcreate -L 58,9G -n cache cl_svm /dev/sdc
Создание кэш-пула из томов:
	# lvconvert type cache-pool cachemode writethrough —poolmetadata cl_svm/meta cl_svm/cache
Связываем подготовленный кэш-пул с томом данных:
	# lvconvert type cache cachepool cl_svm/cache cl_svm/data 
Статистику можно посмотреть в выводе:
	# lvs -o cache_read_hits,cache_read_misses,cache_write_hits,cache_write_misses
CacheReadHits    CacheReadMisses  CacheWriteHits   CacheWriteMisses
            421076           282076           800554          1043571

Уведомления о изменении состояния массива:

В конце файла /etc/mdadm.conf нужно добавить параметры, содержащие адрес, на который будут отправляться сообщения в случае проблем с массивом, и, если необходимо, указать адрес отправителя:

MAILADDR alert@domain.ru
MAILFROM svm@domain.ru

Чтобы изменения вступили в силу, нужно перезапустить службу mdmonitor:

#systemctl restart mdmonitor

Почта с ВМ отправляется средствами ssmtp. Так как я использую RDM в режиме виртуальной совместимости, то проверять состояние дисков будет сам хост.

Подготовка хоста

Добавляем NFS датастор в ESXi:

Storage → Datastores → New Datastore → Mount NFS Datastore
Name: DATASTORE_NFS
NFS server: 10.0.0.2
NFS share: /data

Настройка автозапуска ВМ:

Host → Manage → System → Autostart → Edit Settings
Enabled — Yes
Start delay — 180sec
Stop delay — 120sec
Stop action — Shut down
Wait for heartbeat — No

Virtual Machines → svm → Autostart → Increase Priority
(Автозапуск не сработал, пришлось удалить ВМ из Inventory и добавить заново)

Данная политика позволит ВМ svm запуститься первой, гипервизор примонтирует NFS датастор, после этого будут включаться остальные машины. Выключение происходит в обратном порядке. Время задержки запуска ВМ подобрано по итогам краш-теста, т. к. при малом значении Start delay NFS датастор не успевал примонтироваться, и хост пытался запустить ВМ, которые еще недоступны. Также можно поиграться параметром

NFS.HeartbeatFrequency

.

Более гибко автостарт ВМ можно настроить с помощью командной строки:

Посмотреть параметры автозапуска для ВМ:
	# vim-cmd hostsvc/autostartmanager/get_autostartseq
Изменить значения автостарта для ВМ (синтаксис):
	# update_autostartentry VMId StartAction StartDelay StartOrder StopAction StopDelay WaitForHeartbeat
Пример:
	# vim-cmd hostsvc/autostartmanager/update_autostartentry 3 «powerOn» «120» «1» «guestShutdown» «60» «systemDefault»

Небольшая оптимизация

Включить Jumbo Frames на хосте:

Jumbo Frames: Networking → Virtual Switches → svm_vSwitch указать MTU 9000;
Networking → Vmkernel NICs → vmk1 указать MTU 9000

В Advanced Settings установить следующие значения:

NFS.HeartbeatFrequency = 12
NFS.HeartbeatTimeout = 5
NFS.HeartbeatMaxFailures = 10
Net.TcpipHeapSize = 32 (было 0)
Net.TcpipHeapMax = 512
NFS.MaxVolumes = 256
NFS.MaxQueueDepth = 64 (было 4294967295)

Включить Jumbo Frames на ВМ svm:

# ifconfig ens224 mtu 9000 up
# echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-ens224

Производительность

Используемое ПО на тестовой ВМ:

— ОС CentOS 7.3.1611 (8 vCPU, 12Gb vRAM, 100Gb vHDD)
— fio v2.2.8

Последовательность команд запуска теста:
	# dd if=/dev/zero of=/dev/sdb bs=2M oflag=direct
	# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=1 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio -readonly -name=rr -rw=randread -bs=4k -runtime=300 -iodepth=24 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio  -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=1 -filename=/dev/sdb -ioengine=libaio -direct=1
	# fio -name=rw -rw=randwrite -bs=4k -runtime=300 -iodepth=24 -filename=/dev/sdb -ioengine=libaio -direct=1

Полученные результаты представлены в таблицах (* во время тестов отмечал среднюю загрузку ЦП на ВМ svm):

Результаты, которые можно потрогать руками, получились при одновременном запуске пяти ВМ с Windows 7 и офисным пакетом (MS Office 2013 Pro + Visio + Project) в автозагрузке. По мере нагревания кэша, ВМ грузились быстрее, при этом HDD практически не участвовал в загрузке. При каждом запуске отмечал время полной загрузки одной из пяти ВМ и полной загрузки всех ВМ.

Время загрузки одиночной ВМ составило:

— HDD VMFS6 - 50 секунд
— NFS с выключенным кэшем - 35 секунд
— NFS с включенным и нагретым кэшем - 26 секунд

В виде графика:

Краш-тест

Отключение питания

Выход из строя HDD (имитация)

Неприятным моментом оказалось, что при потере диска гипервизор просит для ВМ svm ответить на вопрос — «You may be able to hot remove this virtual device from the virtual machine and continue after clicking Retry. Click Cancel to terminate this session» — машина находится в состоянии фриза.

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

Выход из строя SSD

Обслуживание (Замена диска)

Посмотреть общее состояние массива: 
	# cat /proc/mdstat 
или для каждого устройства: 
	# mdadm —detail /dev/md126 /dev/md126
Пометить разделы неисправными:
	# mdadm manage /dev/md127 fail /dev/sda1 
	# mdadm manage /dev/md126 fail /dev/sda2
Удалить сбойные разделы из массива:
	# mdadm manage /dev/md127 remove /dev/sda1
	# mdadm manage /dev/md126 remove /dev/sda2

В настройках ВМ нужно «оторвать» погибающий vHDD, затем заменить HDD на новый.
После чего подготовить RDM накопитель и добавить к ВМ svm:

Перечитать список устройств, где X — номер SCSI шины Virtual Device Node в настройках vHDD:
	# echo «- — -» > /sys/class/scsi_host/hostX/scan
С помощью sfdisk скопировать структуру разделов:
	# sfdisk -d /dev/sdb | sfdisk /dev/sdc
Добавить получившиеся разделы в массив, установить загрузчик и дождаться окончания синхронизации:
	# mdadm manage /dev/md127 add /dev/sdc1
	# mdadm manage /dev/md126 add /dev/sdc2
	# grub2-install /dev/sdc

Аварийный доступ к данным

# mdadm assemble scan
# lvremove cl_svm/cache 
# lvchanange -ay /dev/cl_svm/data
# mount /dev/cl_svm/data /mnt/data

Также я пробовал загрузить систему непосредственно с диска, настроил сеть и на другом хосте подключил NFS датастор — ВМ доступны.

Резюме