FreePBX откат конфигурации
For example. Open a root shell
mkdir /tmp/etc_asterisk cp -a /etc/asterisk/* /tmp/etc_asterisk
Apply changes in FreePBX and then in the shell
diff -r /etc/asterisk/ /tmp/etc_asterisk/
Позднее
Ctrl + ↑
Сброс настроек IPMI Supermicro через Ubuntu или Esxi 5.5
Для сброса закидывает всю папку linux\x64 и выполняем
chmod +x IPMICFG-Linux.x86_64; ./IPMICFG-Linux.x86_64 -fd
Ждем рестарта SMC и после этого входим по DHCP с логином паролем ADMIN ADMIN
Flashcache + munin на Ubunt 16.04
Устанавливаем пакеты и компилим с исходников
sudo apt-get install dkms build-essential linux-headers-$(uname -r) gitgit clone git://github.com/facebook/flashcache; cd flashcachemake -f Makefile.dkmsmake installПосле этого подгружаем модуль
modprobe flashcache
Дальше добавлем кеш к диску sdaX в режиме writeback
sudo flashcache_create -p back fcache /dev/sdbX /dev/sdaX
Для проверки попаданий в кеш вводим
dmsetup status cachedev
Для размонтирования кеша с выгрузкой грязных данных используем
dmsetup remove cachedev
Файл /etc/fstab не менялся, т. к. кеширование делается на уровне md-устройтва, поєтому домашний каталог доступен без бубнов и танцев сразу после загрузки системы.
Твики в sysctl.conf:
dev.flashcache.sda+md2.fallow_delay = 240
dev.flashcache.sda+md2.fast_remove = 1
dev.flashcache.sda+md2.reclaim_policy = 1
dev.flashcache.sda+md2.skip_seq_thresh_kb = 1024
Убрать кеширование.
1. umount /home
2. sysctl -w dev.flashcache.sda+md2.do_sync=1
(может занять продолжительное время для записи данных на медленный диск)
3. vgchange -an vg1
3. dmsetup remove ssd
4. flashcache_destroy /dev/sda
Теперь логический раздел vg1-home можно примонтировать без SSD кеша
5. vgchange -ay vg1
6. mount /dev/mapper/vg1-home /home
Ставим munin
Шаг 1. Установка Munin-master и Munin-node
Установить Munin можно из стандартных репозиториев операционной системы :
sudo apt-get update
sudo apt-get install munin
sudo apt-get install munin-node
Шаг 2. Настройка Munin-master
Откроем конфигурационный файл Munin:
nano /etc/munin/munin.conf
Для начальной настройки необходимо изменить только имя хоста, которое будет выводиться в графиках. Для этого в секции конфигурационного файла «# a simple host tree» отредактируем строку
[localhost.localdomain]
Имя хоста можно указать, например, так:
[srv-01.example.com]
Вот и всё. Сохраняем внесённые изменения и выходим из текстового редактора.
Шаг 3. Настройка Munin-node
Как и при настройке Munin-master, для начала необходимо открыть конфигурационный файл :
nano /etc/munin/munin-node.conf
В файле нужно найти строку
#host_name localhost.localdomain
Она нужна для того, чтобы изменить имя хоста. Именно её потребуется отредактировать — например, так:
host_name srv-01.example.com
Обратите внимание, что строку нужно раскомментировать (удалить символ # в начале).
Управление плагинами
Чтобы посмотреть список доступных плагинов, необходимо сделать листинг директории /etc/munin/plugins
ls -l /usr/share/munin/plugins/
Для установки плагина нужно создать на него символическую ссылку.
Перейдём в директорию для установленных плагинов.
cd /etc/munin/plugins/
Установим какой-нибудь плагин (в нашем примере это плагин для DNS-сервера Bind):
ln -s /usr/share/munin/plugins/bind9
После добавления всех необходимых плагинов перезапустим Munin-node для примерения изменений:
service munin-node restart
Шаг 4. Настройка доступа к Munin через Apache и Nginx
Результаты мониторинга Munin отображает в виде графиков. Для этого потребуется HTTP-сервер — например, Apache или Nginx.
Настройка доступа к Munin через Apache
Для настройки доступа к Munin через Apache необходимо в конфигурацию любого виртуального хоста (в то числе стандартного) внести директиву <Location /munin>
Для этого в файл виртуального хоста потребуется вставить следующие строки
<Location /munin>
AuthType Basic
AuthName «Munin Statistics»
AuthUserFile /etc/munin/.passwd
Require valid-user
</Location>
После внесения изменений Apache нужно будет перезапустить:
service apache2 restart
Настройка доступа к Munin через Nginx
Для настройки доступа к Munin через Nginx также понадобится внести изменения в конфигурацию любого виртуального хоста:
location /munin {
alias /var/www/munin;
autoindex on;
auth_basic «Munin Statistics»;
auth_basic_user_file /etc/munin/.passwd;
}
Чтобы настройки вступили в силу, Nginx нужно будет перезагрузить.
service nginx restart
Шаг 5. Создание файла паролей
По завершении настройки создадим файл с паролями пользователей, имеющих доступ к Munin.
Для этого выполним следующую команду:
htpasswd -c /etc/munin/.passwd user
После выполнения данной команды будет предложено два раза ввести пароль от пользователя, после чего файл будет записан. В этой команде можно заменить user на любое удобное имя пользователя.
В конфиге для Nginx ставим
alias /var/cache/munin/www;
После этого добавляем модуль flashcache
wget https://raw.github.com/pkhamre/flashcache-munin/master/flashcache_stats
chmod +x flashcache_stats;mv flashcache_stats /usr/share/munin/plugins/; ln -s /usr/share/munin/plugins/flashcache_stats /etc/munin/plugins/
Установка для дебиан
aptitude install flashcache-dkms flashcache-utils
modprobe flashcache
Ускорение датасторов HP в esxi 5.5
Установлено: VMware-ESXi-5.5.0-Update3-3568722-HPE-550.9.6.5.9-Dec2016.iso
Версия драйвера дисков: — scsi-hpvsa-5.5.0.100-1OEM.550.0.0.1331820
Как выяснилось, HP что-то испортили в драйвере дисковой подсистемы для ESXi 5.5 и работа с дисками стала … скажем так, не очень эффективной. Более того, как выяснилось позже, такая же проблема существует и в гипервизорах ESXi 6.0/6.5 от HPE.
Насколько не эффективно? Результаты замеров в статье. Сразу скажу — оглушающие.
Пообщавшись со знакомыми и покопав Интернет было выяснено, что всему виной и правда, драйвер, который HPE включила в свой кастомный образ с установщиком гипервизора ESXi 5.5 и более поздних версий.
Но, решение этой проблемы есть. Совместными усилиями Интернет-сообщества (https://homeservershow.com) был найден драйвер, который реально ускоряет работу с дисками в HP Microserver Gen8.
Версия драйвера: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820
Сам драйвер можно легально, бесплатно и без регистрации, скачать c сайта HPE:
https://support.hpe.com/hpsc/swd/…b1dfc5314e02bc01b1436b
Type: Driver — Storage Controller
Version: 5.5.0-88.0(9 Sep 2014)
Operating System(s): VMware vSphere 5.5
File name: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib (707 KB)
Осталось его установить. Как это сделать, описано ниже.
В первую очередь проверяем версию установленного драйвера и, если отличается, то заменяем на правильный.
А) Заходим в консоль ESXi хоста через PuTTY под именем root и запускаем команду
esxcli software vib list | grep scsiВот, что было у меня до смены драйвера
~ # esxcli software vib list | grep scsiscsi-hpsa 5.5.0.124-1OEM.550.0.0.1331820 HPE VMwareCertified 2018-04-10
scsi-hpdsa 5.5.0.52-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 LSI VMwareCertified 2018-04-10
scsi-bfa 3.2.6.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2fc 1.713.20.v55.4-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2i 2.713.10.v55.3-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-qla4xxx 644.55.37.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
То есть. Не тот. Почему? А вот, что показал тест производительности. Не то чтобы тест, но из приведенных команд видно, что тестируется.
Выполняем следующие команды из консоли ESXI:
cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000
Примечание: Не забудьте поменять [datastore] на имя вашего реального DataStore.
Получаем результат:
1000000+0 records in
1000000+0 records out
real 14m 12.62s
user 0m 12.23s
sys 0m 0.00s
Вроде бы не плохо, да?
Для сравнения, в той же конфигурации, но с установленным, ESXi 5.1U3 получаем примерно следующее:
1000000+0 records in
1000000+0 records out
real 17m 25.62s
user 0m 7.23s
sys 0m 0.00s
То есть, налицо видимое улучшение по сравнению с предыдущей версией гипервизора. Но, вам придется поверить мне на слово, а потом посмотреть на совсем другой результат. Дочитайте до конца.
Итак, приступаем к смене драйвера.
Процедура достаточно простая. Предполагается, что нужный драйвер Вы уже скачали с сайта HP, по приведенный ранее ссылке.
- Останавливаем все запущенные VMs
- Если не включено, включаем ssh
- Копируем файл «scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib» to /tmp (например, с помощью WinSCP)
- Подключаемся к консоли гипервизора ESXi с помощью PuTTY (с правами root, естественно)
- Меняем текущую папку на ту, куда положили файл, то есть на папку /tmp
cd /tmp - Копируем vib-файл в папку из которой он будет инсталлирован
cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/ - Переводим гипервизор в Maintenance Mode
esxcli system maintenanceMode set --enable true - Удаляем текущий драйвер дисковой подсистемы
esxcli software vib remove -n scsi-hpvsa -f - Инсталлируем правильный драйвер scsi-hpvsa-5.5.0-88OEM из файла
esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode - Перезапускаем ESXi, отключаем Maintenance Mode, запрещаем ssh (если нужно) и запускаем свои виртуальные машинки.
Примечание: Отключить Maintenace Mode можно из клиента или из консоли, командой:
esxcli system maintenanceMode set --enable falseВсе просто? Да, просто.
Но ведь всегда хочется убедиться, что автор не наврал.
Проверяем, что версия драйвера изменилась.
esxcli software vib list | grep scsiscsi-hpsa 5.5.0.124-1OEM.550.0.0.1331820 HPE VMwareCertified 2018-04-10
scsi-hpdsa 5.5.0.52-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2018-04-10
scsi-mpt2sas 15.10.06.00.1vmw-1OEM.550.0.0.1198610 LSI VMwareCertified 2018-04-10
scsi-bfa 3.2.6.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2fc 1.713.20.v55.4-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-bnx2i 2.713.10.v55.3-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
scsi-qla4xxx 644.55.37.0-1OEM.550.0.0.1331820 QLogic VMwareCertified 2018-04-10
Да. Изменилась на правильную.
А скорость? Не обманули? Проверяем! Что я и сам сделал. Запустил, повторно, тест производительности. Результат меня, мягко говоря, ошеломил
cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=10000001000000+0 records in
1000000+0 records out
real 2m 6.73s
user 0m 5.21s
sys 0m 0.00s
Это в СЕМЬ раз быстрее, чем с предыдущим драйвером и почти в 9 раз быстрее чем на ESXI 5.1U3
На форуме пользователи подтвердили, что примерно такой же, не правильный, драйвер устанавливается и при инсталляции ESXi 6.0 и 6.5. И замена его на версию scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820 приводит к такому же ускорению работы дисковой подсистемы.
flashcache Centos
Разбивка в installimage
SSD: так как он первый, то закомментирован. Остальные секции
DRIVE: переименованы по номерами на 1 и 2.
SWRAIDLEVEL = 1
( по умолчанию на 3-х пытается создать 5-й RAID)
PART swap swap 32G PART /boot ext3 512M PART lvm vg0 all LV vg0 vz /vz ext4 600G LV vg0 root / ext4 all
Далее, в соответствии с установщиком. Нажимаем f10 и enter.
После загрузки сервера в обычном режиме с установленным чистым Centos, ставим OpenVZ. Установка описана здесь.
Теперь начинается самое интересное.
Установка flashcache
К сожалению, это не быстрый способ установки. Возможно, это из-за OpenVZ ядра. Мануал всего из двух строчек:
1) Подключаем репозиторий
rpm -Uvh http://elrepo.reloumirrors.net/elrepo/el6/x86_64/RPMS/elrepo-release-6-4.el6.elrepo.noarch.rpm
2) И устанавливаем
yum -y install kmod-flashcache flashcache-utils
На момент написания статьи было ядро OpenVZ rhel6-2.6.32 версии 042stab074.10.
Так как для сборки FlashCache требуются некоторые внутренние заголовочные файлы, которые не входят в состав пакета kernel-headers/devel, требуется загрузить и установить полный код ядра. Нам же не хватало vzkernel-headers.
yumdownloader —source kernel-`uname -r` rpm -ivh kernel-`uname -r`.src.rpm
Далее скачиваем и устанавливаем:
git clone https://github.com/facebook/flashcache.git cd flashcache make -f Makefile.dkms
Esxi 5 получение данных smart
esxcli storage core device smart get -d t10.ATA_____SG9XCS1F50GMIBM______43W7729_59Y1873IBM_____________501010LJ
Parameter Value Threshold Worst
————————————— — -—— -—
Health Status N/A N/A N/A
Media Wearout Indicator N/A N/A N/A
Write Error Count N/A N/A N/A
Read Error Count N/A N/A N/A
Power-on Hours N/A N/A N/A
Power Cycle Count N/A N/A N/A
Reallocated Sector Count N/A N/A N/A
Raw Read Error Rate N/A N/A N/A
Drive Temperature N/A N/A N/A
Driver Rated Max Temperature N/A N/A N/A
Write Sectors TOT Count N/A N/A N/A
Read Sectors TOT Count N/A N/A N/A
Initial Bad Block Count N/A N/A N/A
Smartctl установка в esxi 5.5 u2 6.0 и прочие
Для полуяения полного отчета ставим пакет
- Download
- Copy the VIB to the /tmp/ directory of an ESXi host
- SSH to the ESXi host
- Set the VIB acceptance level to CommunitySupported
- # esxcli software acceptance set —level=CommunitySupported
- Install the package (Maintenance Mode or Reboot is not required)
- #esxcli software vib install -v /tmp/smartctl-6.6-4321.x86_64.vib
The tool is located at /opt/smartmontools/smartctl and works just like the Linux version.
Locate physical disks with ls -l /dev/disks/
/opt/smartmontools/smartctl -d [Device Type] —all /dev/disks/[DISK]
# smartctl -d sat —all /dev/disks/t10.ATA_____Samsung_SSD_850_EVO_M.2_250GB___________S24BNXAG805065D_____
smartctl 6.6 2016-05-10 r4321 [x86_64-linux-6.0.0] (daily-20160510)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 850 EVO M.2 250GB
Serial Number: S24BNXAG805065D
LU WWN Device Id: 5 002538 d404b9f9f
Firmware Version: EMT21B6Q
User Capacity: 250,059,350,016 bytes [250 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
SMART support is: Available — device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 133) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always — 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always — 5040
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always — 35
177 Wear_Leveling_Count 0x0013 094 094 000 Pre-fail Always — 122
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always — 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always — 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always — 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always — 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always — 0
190 Airflow_Temperature_Cel 0x0032 049 034 000 Old_age Always — 51
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always — 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always — 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always — 26
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always — 6345601655
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
Warning! SMART Selective Self-Test Log Structure error: invalid SMART checksum.
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
255 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Node red сохранение данных
Prior to Node-RED v0.19.0, data could be stored in context as a global, flow or node. This was stored in memory and would be reset with a restart of Node-RED. As of v.0.19.0 you can now store node, flow and global context data in memory OR in a file which will persist over restarts. (the data will be stored in the userDir, which is normally $HOME/.node-red, in a folder ’context’ with subfolders for each flow or node and one folder for all globals.)
In order to store the data, you must make a change to
settings.jsThe contextStorage property in settings.js is used to configure how context data is stored:
contextStorage: { storeName : { module: "storeModule" } },
storeNamestoreModule: Node-RED provides two built-in store modules:
memoryand
localfilesystem. It is also possible to create custom store plugins. You must specify localfilesystem (or your own custom module) to make the data persistent. For details on creating custom modules, see the api pages.
If you only have one option in contextStorage, it will always be used. If you have two options and one has the storeName
defaultgetsetExample: say these are your entries in setting.js:
contextStorage: { storeInFile: { module: "localfilesystem"}, default : { module: "memory" } },
And you use the following set’s (this applies to any node that can access context directly like the change, inject, or change nodes):
flow.set("count", 123); // stored in memory, count = 123 flow.set("count", 234, "default"); // stored in memory, count now - 234 flow.set("partid", "b301", "storeInFile"); // stored in file, partid = "b301" flow.set("color", "red", "InFile"); // invalid storeName // - stored based on 'default' rules // - a 'storeName' of `default` exists and is used // - stored in memory, color = 'red'
Note: Having multiple entries in settings.js can lead to confusion. If you have:
contextStorage: { default : { module: "memory" }, storeInFile: { module: "localfilesystem"}, memoryOnly : { module: "memory" } },
and run the following code:
flow.set("count", 123); // the value is stored in memory flow.set("count", 234, "default"); // the value is stored in memory flow.set("count", 345, "memoryOnly"); // the value is stored in memory
the first line stores ’123’ in default:count.
the second line replaces ’123’ with ’234’ in default:count
the third line stores ’345’ in memoryOnly:count
If you forget to specify the location in a
getsetSUGGESTION: If you want have all your context data be persistant, setup your settings.js file with the following:
contextStorage: { default : { module: "localfilesystem"} },
GRAYLOG проверка и очистка накопленных данных
Первая помощь: проверьте, какие индексы присутствуют:
curl http://localhost:9200/_cat/indices
Затем удалите самые старые индексы (вы не должны удалить все)
curl -XDELETE http://localhost:9200/graylog_1
curl -XDELETE http://localhost:9200/graylog_2
curl -XDELETE http://localhost:9200/graylog_3
Исправить: Затем вы можете уменьшить параметр elasticsearch_max_number_of_indices в файле /etc/graylog/server/server.conf до значения, соответствующего вашему диску.
Исправление после того как кончилось место и данные не пишутся
docker exec -it 48694fef984b /bin/bash
curl -XPUT -H «Content-Type: application/json» http://127.0.0.1:9200/_all/_settings -d ’{«index.blocks.read_only_allow_delete»: null}’
Elsa тормоза в схемах и инструкциях
Есть решение для 64 разрядной ОС
Пуск — выполнить — regedit — ok
Находим раздел в реестре:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ Jet\4.0\Engines\Jet 4.0\MaxBufferSize
Прописать значение: 500000 режим турбо =)
А так же если 32 разрядная windows 7 и в папке wow6432node пусто. (может конечно от ОС не зависит?) Почти тот же реестр:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Jet\4.0\Engines\Jet 4.0\MaxBufferSize
Прописать значение: 500000
Ранее
Ctrl + ↓