По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Утилита Linux fsck (File System Consistency Check - проверка согласованности файловой системы) проверяет файловые системы на наличие ошибок или нерешенных проблем. Инструмент используется для исправления потенциальных ошибок и создания отчетов. Эта утилита по умолчанию входит в состав дистрибутивов Linux. Для использования fsck не требуется никаких специальных шагов или процедуры установки. После загрузки терминала вы готовы использовать функции инструмента. Следуйте этому руководству, чтобы узнать, как использовать fsck для проверки и восстановления файловой системы на Linux-машине. В руководстве будут перечислены примеры того, как использовать инструмент и для каких вариантов использования. Когда использовать fsck в Linux Инструмент fsck можно использовать в различных ситуациях: Используйте fsck для запуска проверки файловой системы в качестве профилактического обслуживания или при возникновении проблемы с вашей системой. Одна из распространенных проблем, которые может диагностировать fsck, - это когда система не загружается. Другой - когда вы получаете ошибку ввода/вывода, когда файлы в вашей системе становятся поврежденными. Вы также можете использовать утилиту fsck для проверки состояния внешних накопителей, таких как SD-карты или USB-накопители. Базовый синтаксис fsck Базовый синтаксис утилиты fsck следует этому шаблону: fsck <options> <filesystem> В приведенном выше примере файловой системой может быть устройство, раздел, точка монтирования и так далее. Вы также можете использовать параметры, относящиеся к файловой системе, в конце команды. Как проверить и восстановить файловую систему Перед проверкой и восстановлением файловой системы необходимо выполнить несколько шагов. Вам нужно найти устройство и размонтировать его. Просмотр подключенных дисков и разделов Чтобы просмотреть все подключенные устройства в вашей системе и проверить расположение диска, используйте один из доступных инструментов в Linux. Один из способов найти диск, который вы хотите просканировать, - это перечислить диски файловой системы с помощью команды df: df -h Инструмент показывает использование данных в вашей системе и файловых системах. Обратите внимание на диск, который вы хотите проверить, с помощью команды fsck. Например, для просмотра разделов вашего первого диска используйте следующую команду: sudo parted /dev/sda 'print' sda - это то, как Linux относится к вашему первому SCSI-диску. Если у вас два, вторым будет sdb и так далее. В нашем примере мы получили один результат, поскольку на этой виртуальной машине был только один раздел. Вы получите больше результатов, если у вас будет больше разделов. Имя диска здесь /dev/sda, а затем количество разделов отображается в столбце Number. В нашем случае это один: sda1. Размонтировать диск Прежде чем вы сможете запустить проверку диска с помощью fsck, вам необходимо отключить диск или раздел. Если вы попытаетесь запустить fsck на смонтированном диске или разделе, вы получите предупреждение: Обязательно выполните команду размонтирования: sudo umount /dev/sdb Замените /dev/sdb устройством, которое вы хотите размонтировать. Обратите внимание, что вы не можете размонтировать корневые файловые системы. Следовательно, теперь fsck нельзя использовать на работающей машине. Подробнее об этом в конце руководства. Запустить fsck для проверки ошибок Теперь, когда вы отключили диск, вы можете запустить fsck. Чтобы проверить второй диск, введите: sudo fsck /dev/sdb В приведенном выше примере показан результат для чистого диска. Если на вашем диске имеется несколько проблем, для каждой из них появляется запрос, в котором вы должны подтвердить действие. Код выхода, который возвращает утилита fsck, представляет собой сумму этих состояний: Смонтировать диск Когда вы закончите проверку и ремонт устройства, смонтируйте диск, чтобы вы могли использовать его снова. В нашем случае мы перемонтируем SDB-диск: mount /dev/sdb Сделать пробный запуск с fsck Перед выполнением проверки в реальном времени вы можете выполнить тестовый запуск с помощью fsck. Передайте параметр -N команде fsck, чтобы выполнить тест: sudo fsck -N /dev/sdb На выходе печатается, что могло бы произойти, но не выполняется никаких действий. Автоматическое исправление обнаруженных ошибок с помощью fsck Чтобы попытаться устранить потенциальные проблемы без каких-либо запросов, передайте параметр -y команде fsck. sudo fsck -y / dev / sdb Таким образом, вы говорите «да, попытайтесь исправить все обнаруженные ошибки» без необходимости каждый раз получать запрос. Если ошибок не обнаружено, результат будет таким же, как и без опции -y. Пропускать восстановление, но выводить ошибки fsck на выходе Используйте параметр -n, если вы хотите проверить потенциальные ошибки в файловой системе, не исправляя их. У нас есть второй диск sdb с некоторыми ошибками журнала. Флаг -n печатает ошибку, не исправляя ее: sudo fsck -n /dev/sdb Заставить fsck выполнить проверку файловой системы Когда вы выполняете fsck на чистом устройстве, инструмент пропускает проверку файловой системы. Если вы хотите принудительно проверить файловую систему, используйте параметр -f.Например: sudo fsck -f /dev/sdb При сканировании будут выполнены все пять проверок для поиска повреждений, даже если будет обнаружено, что проблем нет. Запустить fsck сразу для всех файловых систем Если вы хотите выполнить проверку всех файловых систем с помощью fsck за один раз, передайте флаг -A. Эта опция будет проходить через файл etc/fstab за один проход. Поскольку корневые файловые системы нельзя размонтировать на работающей машине, добавьте параметр -R, чтобы пропустить их: fsck -AR Чтобы избежать запросов, добавьте параметр -y, о котором мы говорили. Пропустить проверку fsck в определенной файловой системе Если вы хотите, чтобы fsck пропустил проверку файловой системы, вам нужно добавить -t и no перед файловой системой. Например, чтобы пропустить файловую систему ext3, выполните эту команду: sudo fsck -AR -t noext3 -y Мы добавили -y, чтобы пропускать запросы. Пропустить Fsck в подключенных файловых системах Чтобы убедиться, что вы не пытаетесь запустить fsck на смонтированной файловой системе, добавьте параметр -M. Этот флаг указывает инструменту fsck пропускать любые смонтированные файловые системы. Чтобы показать вам разницу, мы запустим fsck на sdb, пока он смонтирован, а затем, когда мы его размонтируем. sudo fsck -M /dev/sdb Пока sdb смонтирован, инструмент выходит без проверки. Затем мы размонтируем sdb и снова запускаем ту же команду. На этот раз fsck проверяет диск и сообщает, что он чистый или с ошибками. Примечание. Чтобы удалить первую строку заголовка инструмента fsck «fsck from util-linux 2.31.1», используйте параметр -T. Запустить fsck в корневом разделе Linux Как мы уже упоминали, fsck не может проверить корневые разделы на работающей машине, поскольку они смонтированы и используются. Однако даже корневые разделы Linux можно проверить, если вы загрузитесь в режиме восстановления и запустите проверку fsck: 1. Для этого включите или перезагрузите компьютер через графический интерфейс или с помощью терминала: sudo reboot 2. Нажмите и удерживайте клавишу Shift во время загрузки. Появится меню GNU GRUB. 3. Выберите Advanced options for Ubuntu (Дополнительные параметры для Ubuntu). 4. Затем выберите запись с (recovery mode - режим восстановления) в конце. Подождите, пока система загрузится в меню восстановления. 5. Выберите fsck в меню. 6. Подтвердите, выбрав Yes в ответ на запрос. 7. По завершении выберите resume в меню восстановления, чтобы загрузить машину. Что делать, если fsck прерывается? Вам не следует прерывать работу инструмента fsck, пока он работает. Однако, если процесс будет прерван, fsck завершит текущую проверку, а затем остановится. Если утилита обнаружила ошибку во время проверки, она не будет пытаться что-либо исправить, если ее прервать. Вы можете повторно запустить проверку в следующий раз и дождаться ее завершения. Обзор параметров команды Linux fsck Подводя итоги, ниже приведен список параметров, которые вы можете использовать с утилитой fsck Linux. -а - Попробует автоматически исправить ошибки файловой системы. Подсказок не будет, поэтому используйте его с осторожностью. -А - Проверяет все файловые системы, перечисленные в /etc/fstab. -C - Показать прогресс для файловых систем ext2 и ext3. -f - Заставляет fsck проверить файловую систему. Инструмент проверяет, даже если файловая система кажется чистой. -l - Заблокирует устройство, чтобы другие программы не могли использовать раздел во время сканирования и восстановления. -M - Не проверяет смонтированные файловые системы. Инструмент возвращает код выхода 0, когда файловая система смонтирована. -N - Делает пробный запуск. В выводе печатается, что fsck будет делать без выполнения каких-либо действий. Также печатаются предупреждения или сообщения об ошибках. -П - Используется для параллельного сканирования нескольких файловых систем. Это может вызвать проблемы, в зависимости от ваших настроек. Используйте с осторожностью. -Р - Сообщает инструменту fsck, чтобы он не проверял корневые файловые системы при использовании параметра -A. -р - Распечатать статистику устройства. -t - Укажите типы файловых систем для проверки с помощью fsck. Обратитесь к странице руководства для получения подробной информации. -T - Скрыть заголовок при запуске инструмента. -у - Попытается автоматически исправить ошибки файловой системы во время проверки. -V - Подробный вывод.
img
Всем привет! В сегодняшней статье мы расскажем, как победить очень надоедливый “баг” во FreePBX, который кочует из версии в версию и сильно мешает пользователям, которые используют кириллицу, то есть русские буквы, в именах внутренних номеров своей IP-АТС. Точно можно сказать, что данная проблема присутствовала в FreePBX 13 и перебралась в 14 релиз. /p> Как многие могли догадаться, речь пойдёт о неправильном отображении русской кодировки в модуле CDR, в простонародье – кракозябры в CDR. Предыстория Итак, вот вы установили самый последний актуальный FreePBX Distro SNG7-FPBX-64bit-1707-1, долго ждали когда же наконец закончится загрузка 571 пакета (если устанавливаете на VM) Небольшой оффтоп для тех, кто устанавливает FreePBX 14 на VM и подумал, что процесс установки завис на 571 пакете и надо его прервать – НЕТ, он не завис, наберитесь терпения, правда. Да, это долго, мы, например, ждали полтора часа. Отдохните, попейте кофе, почитайте о нововведениях в FreePBX 14 И, наконец, дождались - всё готово, пора регистрировать абонентов. Вы добавили два внутренних номера с русскими именами, пусть будет Алексей Добронравов и Сергей Злонамеров Зарегистрировали для каждого по софтфону и провели тестовый звонок – успех. А что же в CDR? Открываете Reports → CDR Reports и видите те самые “кракозябры”, которые мало чем напоминают имена наших внутренних абонентов. Знакомо? Тогда читай дальше! Быстро проверим таблицу cdr в базе asteriskcdrdb и убедимся, что там такая же картина: Решение Внимание! Прежде чем повторять дальнейшие инструкции – сделайте полный бэкап системы или снэпшот виртуальной машины. Компания Мерион Нетворкс не несёт ответственности за потенциальные проблемы, которые могут возникнуть на вашей IP-АТС. Неправильное выполнение нижеизложенных действий может привести к полной неработоспособности FreePBX и Asterisk! В интернете можно найти много советов по устранению данной проблемы, начиная от выставления значения charset = utf8 в файле /etc/asterisk/cdr_mysql.conf и выполнения core reload, когда записи опять слетают и заканчивая написанием скрипта, который будет время от времени производить принудительную перекодировку записей. Но всё это либо “костыль”, либо не помогает вовсе. На сайте разработчика freepbx.org по данной проблеме даже заведён официальный Bug FREEPBX-15268, который по сегодняшний день имеет статус (11.10.2017) DEV TESTING: Unresolved, то есть – не решён. Более менее действенным способом решения этой проблемы является снос старого MySQL коннектора и установка mysql-connector-odbc-5.3.9 (ANSI Driver), а затем внесение изменений в файл /etc/odbc.ini следующего вида: [MySQL-asteriskcdrdb] driver=MySQL ODBC 5.3 ANSI Driver После этого записи в CDR, конечно, будут отображаться корректно, однако, все логи будут завалены предупреждениями типа: [2017-10-13 22:31:16] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('CHAN_START',{ts '2017-10-13 22:31:16.974567'},'Алексей Добронравов','175','','','','s','from-internal','SIP/175-00000001','','',3,'','1507923076.1','1507923076.0','','','') [2017-10-13 22:31:18] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('ANSWER',{ts '2017-10-13 22:31:18.631244'},'Алексей Добронравов','175','175','','','175','from-internal','SIP/175-00000001','AppDial','(Outgoing Line)',3,'','1507923076.1','1507923076.0','','','') При этом в самой таблице cel, на которую ругается сервер, всё будет нормально: Вроде решение, CDR корректен, но лог будет буквально забит этими предупреждениями, а мы этого не хотим. Итак, сейчас мы опишем способ решения, после которого и логи будут чистыми и никаких “кракозябр” в CDR вы не увидите. Для начала, нужно удалить текущий mysql-connector-odbc, однако, в силу того, что он связан зависимостями, вместе с ним удалится и сам Asterisk. Поэтому, сначала нужно узнать, какой именно коннектор установлен на сервере, и удалить его отдельно. Для этого пишем команду: rpm -qa | grep mysql-connector-odbc Ну и после предыдущих манипуляций видим, что у нас установлен mysql-connector-odbc-5.3.9-1.el7.x86_64, вероятнее всего у вас будет mysql-connector-odbc-5.3.6. Теперь его нужно удалить, но не учитывая при этом его зависимости. Нам нужно удалить только коннектор, для этого пишем следующую команду: rpm -e --nodeps "mysql-connector-odbc-5.3.9-1.el7.x86_64" Теперь нужно установить новый коннектор, но только не от MySQL, а от MariaDB, для этого пишем: Внимание! Ввод следующей команды без предварительного сноса прежнего коннектора может привести к полному отказу Asterisk! yum install mariadb-connector-odbc Теперь проверьте файл /etc/odbcinst.ini в нём обязательно должна быть запись: [MariaDB] Description=ODBC for MariaDB Driver=/usr/lib64/libmaodbc.so Setup=/usr/lib64/libodbcmyS.so UsageCount=1 Теперь сделаем перезагрузку fwconsole restart и всё готово. Проводим ещё пару тестовых звноков, смотрим в модуль CDR во FreePBX и проверяем таблицу cdr в asteriskcdrbd: И логи тоже проверьте, они будут чистыми, никаких предупреждений :) На этом – всё. Надеемся, что наша статься будет вам полезна и поставит, наконец, точку в истории этого надоевшего всем бага. Выражаем благодарность нашим читателям, которые активно обсуждали данную проблему в комментариях и подсказали правильное направление для её решения.
img
Порой, например, при подключении аналогового телефона через FXS шлюз, на котором отсутствует регулировка громкости, необходимо отрегулировать громкость при разговоре. Предположим, что на FXS шлюзе отсутствует регулировка на порту, к которому подключен телефон. Давайте разберемся: Данная регулировка реализуется на базе VOLUME(TX|RX). Информацию по ней можно посмотреть через консоль Asterisk: asterisk*CLI> core show function VOLUME -= Info about function 'VOLUME' =- [Synopsis] Set the TX or RX volume of a channel. \ можно настроить громкость для канала [Description] The VOLUME function can be used to increase or decrease the 'tx' or 'rx' gain of any channel. For example: Set(VOLUME(TX)=3) Set(VOLUME(RX)=2) Set(VOLUME(TX,p)=3) Set(VOLUME(RX,p)=3) [Syntax] VOLUME(direction[,options]) [Arguments] direction Must be 'TX' or 'RX'. options p: Enable DTMF volume control [See Also] Not available Данная функция имеет 2 параметра: Направление, т.е TX – отправка, RX – прием. Дополнительная опция p, которая активирует контроль над звуком по DTMF На данном этапе мы разобрались с функцией VOLUME. Теперь открываем файл extensions_customs.conf и производим следующие настройки нового контекста: [root@asterisk ~]# vim /etc/asterisk/extensions_custom.conf [volume-set] exten => _X.,1,NoOp(Volume settings) same => n,Set(VOLUME(TX)=5) same => n,Set(VOLUME(RX)=5) same => n,Goto(from-internal,${EXTEN},1) Теперь открываем необходимый нам Extension, и в поле Context, вносим название созданного нами выше контекста - volume-set. Теперь можно регулировать громкость в настройках контекста, изменяя значение с 5 на другое, параллельно проверяя громкость в трубке
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59