По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
diskonaut - простой навигатор дискового пространства терминала, созданный с помощью Rust и поддерживающий Linux и macOS. Чтобы использовать его, укажите абсолютный путь в файловой системе, например, /home/merionet или запустите его в интересующем каталоге, он будет сканировать каталог и сопоставлять его с памятью, позволяя исследовать его содержимое. Он позволяет проверять использование места даже в процессе сканирования. По завершении сканирования можно переходить по подкаталогам, получая визуальное представление о том, что занимает место на диске. Diskonaut позволяет удалять файлы и каталоги и в результате отслеживает объем освободившегося в процессе пространства. Он также поддерживает горячие клавиши для облегчения навигации. В этой статье вы узнаете, как установить и использовать diskonaut в системах Linux. Установка diskonaut на Linux Чтобы установить diskonaut на Linux в система должна поддерживать язык программирования Rust. Если в системе не установлена соответствующая библиотека это можно сделать с помощью следующей команды: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh После того как Rust установлен на вашей системе, также будет необходимо установить пакетный менеджер для Rust – cargo. С помощью cargo нужно установить diskonaut на систему как показано ниже: cargo install diskonaut Если используется система Fedora, Cent OS или Arch Linux вы можете установить последний предварительный релиз diskonaut из репозиториев по умолчанию как показано ниже. sudo dnf install diskonaut yay diskonaut После установки diskonaut можно либо запустить diskonaut в каталоге, который нужно проверить, либо указать абсолютный путь к каталогу для сканирования в качестве параметра. cd /home/user diskonaut Или diskonaut /home/user В нижней части можно увидеть доступные сочетания клавиш для использования с diskonaut. После завершения сканирования можно выбрать подкаталоги, например, виртуальные машины Virtual Box, а затем нажать Enter, чтобы просмотреть его. Репозиторий diskonaut на Github: https://github.com/imsnif/diskonaut Вот и все! diskonaut – это простой терминальный навигатор дискового пространства, используемый для быстрого анализа использования дискового пространства.
img
Друг, начнем с цитаты: Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений. Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим. Про установку Redis в CentOS 8 мы рассказываем в этой статье. Redis как база данных Говорим про случай, когда Redis выступает в роли базы данных: Пару слов про ограничения такой модели: Размер БД ограничен доступной памятью Шардинг (техника масштабирования) ведет к увеличению задержки Это NoSQL - никакого языка SQL LUA скриптинг в качестве альтернативы Это нереляционная СУБД! Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа Доступ по общему паролю. Что скажут ваши безопасники? Теперь про преимущества модели: Скорость Хранение данных в памяти делает быстрее работу с ними Скрипты на LUA Выполнение прямо в памяти, опять же, ускоряет работу Удобные форматы запросов/данных Geospatial – геоданные (высота, ширина, долгота и так далее) Hyperloglog – статистическе алгоритмы Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями Алгоритмы устаревания данных Примеры использования Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля. Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию. А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis. Итого, для указанной выше схемы, мы хотим: Скорость Мы не хотим, чтобы пользователь долго ожидал авторизации Масштабирумость системы Сопоставление ключа (токена) с авторизациями юзера А вот, что на эти вызовы может ответить Redis: Redis хранит данные в памяти – он быстрый. Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста. В Redis куча вариантов хранения списков. Самый простой будет являться набором данных. В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать. Redis как кэш! Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных. Ограничения: Значения не могут превышать 512 МБ Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных Профит: Совместное использование кэша разными сервисами по сети Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом Временные ограничения для данных Еще один кейс Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке. Окей, кейс понятен. Рэдис, что скажешь на такие требования? Кэш должен хранить сортированные наборы данных Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами) Это должно быть быстрее, чем пересчет данных с нуля Что скажет Redis: Хранить наборы данных - легко Может вытаскивать сабсеты из наборов - легко Конечно быстрее. Ведь данные хранятся в памяти Redis как брокер сообщений Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик». Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы: Только тривиальная модель pub/sub Отсутствие очередей сообщений Ну а плюсы, как обычно для Редиса – скорость и стабильность. Кейс напоследок Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще. Требования по этой задаче: Низкая задержка Мы не хотим иметь трудности в процессе совместной работы сотрудников Стабильная работа и непрерывность Масштабирование Кампания растет и развивается Редис, твой выход! Низкая задержка – да, говорили об этом ранее Стабильность – минимальное количество точек отказа в Redis Стабильная работа и непрерывность Масштабирование – сделаем кластер, нет проблем. Выводы Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор. Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.
img
Для присоединения к другим телефонным станциям, в SoftX3000 создаются транковые группы разных типов. Для начала рассмотрим порядок создания SIP-транка, который чаще всего используется для подключения небольших АТС предприятий УПАТС. Для начала следует определиться с правилами нумерации транков и сопутствующих записей внутри нашей АТС. Например, пусть SIP-транки будут иметь нумерацию с 1 по 100, транки ОКС-7 со 101 п 199. В рамках одного транка все команды и записи удобно будет вести с одним номером, чтобы было проще ориентироваться в настройках позже. ADD OFC этой командой создаем направление. Здесь параметры имеют следующее назначение: Office direction number порядковый номер направления. На этот номер будем ссылаться в других команда и таблицах. Office direction name название направления. Для удобства идентификации можно указать любое название. Peer office type тип удаленной станции, может принимать значения: PBX - УПАТС СС местная сельская АТС CMPX местная городская и сельская АТС NATT междугородная АТС INTT международная АТС Peer office level - уровень противоположной станции по отношению к текущей. Значения: HIGH выше текущей станции SAME одного уровня LOW ниже текущей ADD SRT создаем подмаршрут, который будет привязан непосредственно к транку. Можно создать несколько подмаршрутов и объединить их в один маршрут: при проблемах с первым подмаршрутом в списке станция будет пытаться использовать следующий. Параметры команды: Sub-route number порядковый номер подмаршрута. Можно установить любой свободный номер, но предпочтительнее, чтобы он совпадал с номером OFC, заданный в предыдущей команде. Office direction number номер OFC, который задан в предыдущей команде. Sub-route name название подмаршрута любое удобное название. ADD RT создаем маршрут, в котором указываем один или несколько подмаршрутов, созданных предыдущей командой. Если указано несколько подмаршрутов, станция будет пытаться использовать первый в списке, если он не доступен, то следующий по списку. Параметры команды: Route number порядковый номер маршрута. Любое число, но, по договоренности, устанавливаем то же значение, что и в командах ранее. Route name произвольное название. 1 st sub-route первый подмаршрут. Указываем номер подмаршрута, созданного в предыдущей команде. Остальные параметры необходимы, если создано несколько подмаршрутов и необходимо настроить параметры выбора между ними. ADD RTANA правило выбора маршрута. Эта таблица определяет по какому маршруту будет направлен вызов, основываясь на многочисленных параметрах вызова, среди которых: категория абонента, тип А-номера, дополнительный атрибут абонента прочие. Параметры команды: Route selection code код выбора маршрута. На этот код ссылается запись в таблице префиксов CNACLD Route selection source code этот код является одним из параметров callsrc. Caller category категория абонента, задается при создании абонента в командах ADD VSBR или ADD MSBR. Caller category категория абонента, устанавливается в командах ADD VSBR или ADD MSBR в параметре Subscriber type. Так же можно применить данное свойство для транзитных вызовов, задав категорию в команде ADD CNACLR. Service attribute указывает, какие типы вызовов могут использовать данный маршрут (INTT - международные, NATT - междугородные, CITY - местные, ALL - любые) Caller access если необходимо, чтобы маршрут могли выбрать только абоненты ISDN, выбрать ISDN, если только не ISDN-абоненты, то NONISDN. Transmission capability тип поддерживаемого трафика (голос, данные, видео и прочее) Time index временной индекс. Если в станции используется маршрутизация по временным меткам. Если не используется, устанавливается значение по-умолчанию 0. Route number номер маршрута, который задан в команде ADD RT. Signaling as prior приоритет выбора подмаршрута в соответствии с типом сигнализации. Nature of callee address indicator тип вызываемого номера (International, National, Subscriber, ALL) Customized caller type дополнительный параметр абонента, который задается в командах ADD VSBR или ADD MSBR (Customized subscriber type) Called number Plan identity план нумерации вызываемого номера. Чтобы вызов прошел по данному маршруту, должны совпасть все условия. Чтобы какое-то условие игнорировалось при выборе маршрута, необходимо установить значение в ALL или значение по-умолчанию. Применение Пример 1 Допустим, у нас есть направление OFC=1, на которое ссылается подмаршрут SRT=1, на который, в свою очередь, ссылается маршрут RT=1. Допустим, это присоединение УПАТС, и все вызовы на это направление с любых источников должны проходить без ограничений. В таком случае создадим правило RTANA со следующими параметрами: В данном случае: Route selection code = 1 код выбора маршрута, который нужно указать в команде ADD CNACLD Route number указание на созданный ранее маршрут RT=1 Route selection source code параметр, задаваемый в callsrc. Значение остальных параметров установлены так, что при их любом значении вызов будет смаршрутизирован. Пример 2 Допустим, направление из предыдущего примера является выходом на оператора междугородной связи и доступ к нему могут получать лишь те абоненты, которые заключили с ним договор. Эти абоненты имеют отличительный признак - Customized subscriber type=8. В таком случае устанавливаем в параметре Customized caller type значение CUST8, и абоненты, у которых этот параметр отличается от CUST8 не смогут использовать данный маршрут. По такому же принципу работает ограничение и по другим параметрам. Пример 3 Если ограничивающие параметры не применимы для вызова (например, Customized subscriber type невозможно задать для вызовов, приходящих с другого транка), то и ограничения данных вызовов не произойдет. Чтобы ограничить транзитные вызовы со входящих транков, необходимо создать дополнительный callsource и задать в нем произвольный Route selection source code, отличный от значения по-умолчанию: Теперь, если мы назначим входящем транку созданный callsrc, то сможем применять Route selection source code для маршрутизации, указывая его в команде RTANA. Пример 4 Так же мы можем создать несколько правил RTANA с одним и тем же Route selection code, но разными параметрами, как в примере ниже: Здесь приведено правило RTANA для звонков на междугородные направления, а выбора маршрута осуществляется в зависимости от различных параметров вызова (в частности, Caller category и Customize subscriber type). ADD SIPTG создает транк-группу, в которой задается количество каналов, код источника вызова (для входящих вызовов), и номер подмаршрута, к которому привязана транк-группа. Trunk group number порядковый номер транк-группы Call source code код источника вызова, используется для маршрутизации входящих вызовов Sub-route number номер подмаршрута, указываем созданный ранее подмаршрут Maximum caller number restriction максимальное количество вызовов в транке. При достижении этого количества вызовов в транке, все последующие вызовы отбрасываются. Stop call restriction при снижении количества вызовов до числа, указанного в этой команде, ограничение вызовов, сработавшее по предыдущему параметру, снимается ADD SIPIPPAIR задает параметры непосредственного стыка с противоположным оборудованием (ip-адрес удаленной станции, локальный порт для приема сигнализации) Trunk group number порядковый номер транк-группы, указываем номер из предыдущей команды IFMI module number номер модуля IFMI в системе, можно узнать, дав команду LST BRD Local server port порт приема сигнализации SIP Remote URI 1 ip-адрес противоположной станции. Если sip-транк настраивается через SBC, здесь указывается loopback-интерфейс, который назначен транку.` ADD CNACLD этой командой задается префикс выхода на созданную транк-группу. Local DN set номер Local DN set, в которой будет находится префикс набора. Как правило, в станции только один Local DN set, указываем его номер Call prefix префикс набора, по которому вызовы будут направляться в созданное нами направление Service attribute тип исходящего вызова, принимает значения: LCO (Intra-officce) внутренние вызовы станции, LC (Local), LCT (Local toll) местные, NTT (National toll) междугородные (федеральные), ITT (International toll) международные, EMC экстренные вызовы. Route selection code код выбора маршрута, номер, указанный в команде RTANA. Minimum number length минимальная длина номера по данному префиксу Maximum number length максимальная длина номера по данному префиксу Charging selection code код источника тарификации. Настройка SIP -транка в пограничном контроллере сессий Huawei SE 2200 Общие правила настройки sip-транка в SBC Interface LoopBack 1 интерфейс, который указываем в SoftX3000 как противоположную станцию description test - trunk справочное название интерфейса ip address 192.168.33.1 255.255.255.255 адрес созданного интерфейса Interface LoopBack 2 интерфейс, который указываем в противоположной станции как адрес SoftX3000 description test - trunk справочное название интерфейса ip address 192.168.44.1 255.255.255.255 адрес созданного интерфейса acl number 3011 создаем список доступа rule 0 permit ip source 192168.55.1 0 разрешаем трафик от адреса противоположной станции rule 5 permit ip source 192.168.22.0 0.0.0.255 разрешаем трафик от SoftX3000 и сопутствующего оборудования (в этой сети, вероятно, так же будет UMG и прочее оборудование в составе SoftX3000) rule 10 deny ip запретить все прочие адреса Выше обозначенная группа команд необходима для обеспечения безопасности, на нашей сети используются другие методы и эти команды не используются и не проверялись автором. Здесь они приведены для полной информации о правильной последовательности настройки. sbc wellknowport clientaddr 192.168.33.1 sip 5060 разрешаем прием сигнализации SIP по порту 5060 на адресе 192.168.33.1 (от SoftX3000) sbc wellknowport clientaddr 192.168.44.1 sip 5060 разрешаем прием сигнализации SIP по порту 5060 на адресе 192.168.44.1 (от противоположной станции) sbc wellknowport softxaddr 192.168.22.1 sip 5060 обозначаем адрес SoftX3000. (Если SBC уже настроен ранее и работает, данная команда уже, вероятно, есть в конфигурации) sbc mapgroup intercom - ip 1001 создаем mapgroup в сторону SoftX3000 description == test - trunk == - справочное название clientaddr 192.168.44.1 адрес в сторону противоположной станции match acl 3011 проверка адресов согласно списка acl 3011 serveraddr 192.168.33.1 адрес в сторону SoftX softxaddr 192.168.22.1 - адрес SoftX3000 media - clientaddr 192.168.44.1 адрес в сторону противоположной станции media - serveraddr 192.168.33.1 адрес в сторону SoftX enable команда на активацию mapgroup sbc mapgroup intercom - ip 1002 создаем mapgroup в сторону противоположной станции description ==test-trunk== clientaddr 192.168.33.1 адрес в сторону SoftX match acl 3011 - проверка адресов согласно списка acl 3011 serveraddr 192.168.44.1 адрес в сторону противоположной станции softxaddr 192.168.55.1 - адрес противоположной станции media - clientaddr 192.168.33.1 адрес в сторону SoftX media - serveraddr 192.168.44.1 адрес в сторону противоположной станции enable команда на активацию mapgroup
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59