Полезное
Всякое разное
- Полезные ссылки
- ГОСТ 19.701-90. Блок-схемы
- ГОСТ Р 56920-2016. Тестирование программного обеспечения
- Голосование в Slack
- Nextcloud
- Алгоритмы балансировки
- rfc3339
- HTML URL Encoding
- JWT (JSON Web Token) / JWS (JSON Web Signature) / JWE (JSON Web Encryption) / JWK (JSON Web Key) / JWA (JSON Web Algorithms)
- Zabbix 1.8.22
Полезные ссылки
- https://atlas.ripe.net - RIPE Atlas - глобальная открытая распределенная интернет-измерительная платформа, состоящая из тысяч измерительных устройств, которые измеряют подключение к Интернету в режиме реального времени
ГОСТ 19.701-90. Блок-схемы
http://docs.cntd.ru/document/gost-19-701-90-espd
Схемы состоят из символов, краткого пояснительного текста и соединяющих линий
Схемы могут применяться на различных уровнях детализации, важно чтобы различные части и взаимосвязи были понятны в целом
При начертании символов рекомендуется придерживаться строгих размеров определяемых двумя значениями a и b
b рассчитывается из соотношения 2⋅a = 3⋅b
Данные
-
Данные, хранящиеся в запоминающем устройстве с последовательным доступом (магнитная лента)
-
Данные, хранящиеся в запоминающем устройстве с прямым доступом (магнитный диск)
-
Данные, вводимые вручную во время обработки с устройств любого типа
-
Данные, представленные на носителе в виде карты (перфокарты, магнитные карты)
-
Данные, представленные в человекочитаемой форме на носителе в виде отображающего устройства (экран для визуального наблюдения)
Процессы
-
Предопределенный процесс, состоящий из одной или нескольких операций или шагов программы, которые определены в другом месте (в подпрограмме, модуле). Другими словами, вызов функции
-
Символ отображает модификацию команды или группы команд с целью воздействия на некоторую последующую функцию (установка переключателя, модификация индексного регистра или инициализация программы). Также этот символ используется в циклах (в нем задается условие
-
Решение. Имеет один вход и ряд альтернативных выходов, только один из которых будет выбран после вычисления условия указанного внутри блока
-
Отображает начало и конец цикла. Обе части символа имеют один и тот же идентификатор. Условия для инициализации, приращения, завершения и т.д. помещаются внутри символа в начале или в конце в зависимости от расположения операции, проверяющей условие
Линии
Линия отображает поток данных или управления, при необходимости или для повышения удобочитаемости могут быть добавлены стрелки
-
Передача управления
Отображает передачу управления от одного процесса к другому (тип передачи описывается внутри символа) -
Отображает альтернативную связь между символами или выделяет аннотируемую область
Спецсимволы
-
Соединитель, нужен для обрыва линии и продолжения ее в другом месте
Внутри символа должно быть уникальное обозначение
Пример: -
Терминатор
Выход во внешнюю среду или вход во внешнюю среду (начало или конец программы, внешние источники данных и тд) -
Пропуск, символ из трех точек обозначает пропуск группы символов. Используется только в символах линии или между ними. Главным образом используется для обозначения неизвестного числа повторений
Правила применения символов
- Символ идентифицирует выполняемую функцию независимо от текста внутри него
- Нужно распологать символы равномерно
- Краткий текст для понимания символа должен быть внутри символа, записывать текст нужно слева направо и сверху вниз независимо от направления потока
- Если текст не помещается, то нужно использовать комментарий
- Если символ комментария не вписывается или может запутать читателя, то нужно выносить текст на отдельный лист и давать перекрестную ссылку
- У символа может быть определен идентификатор. Он нужен для использования в справочных целях и указывается слева над символом
- У символа может использоваться описание, это некоторая информация, которая улучшит понимание схемы (объяснение специального применения функции и пр.)
- Некоторые символы отображают способы ввода-вывода информации. Ссылки на документацию для способов вывода нужно располагать справа над символом, а для способов ввода под
- Символы можно использовать как общее представление какого-то процесса. Ссылки на более детальное представление указываются в полосе в верхней части символа
Само подробное описание должно начинаться и заканчиваться терминаторами внутри которых указана та же ссылка что и в полосе описываемого символа - Потоки данных или управления показываются линиями. Стандартное направление потоков - сверху вниз слева направо
- Если поток имеет отличное от стандартного направление, то нужно использовать стрелки
- Следует избегать пересечения линий. Пересекающиеся линии не связаны друг с другом, поэтому нельзя изменять направление потока в точках пересечения
- Две и более линии могут объединяться в одну, место объединения должно быть смещено
- Линии должны подходить к символу либо сверху, либо слева, а исходить либо снизу, либо снизу. Линии должны быть направлены к центру символа
- При необходимости линии в схемах следует разрывать для избежания излишних пересечений или слишком длинных линий, а также, если схема состоит из нескольких страниц. Соединитель в начале разрыва называется внешним соединителем, а соединитель в конце разрыва - внутренним соединителем
- Ссылки к страницам могут быть приведены совместно с символом комментария для их соединителей
Специальные условные обозначения
- Несколько выходов из символа следует показывать:
- Каждый выход должен сопровождаться соответствующим значением условия
- Вместо одного символа с текстом может быть использовано несколько символов с перекрытием изображения, каждый из которых содержит описательный текст (использование или формирование нескольких носителей данных или файлов, ...)
- Когда несколько символов представляют упорядоченное множество, порядок идет от переднего к заднему
Примеры схем
ГОСТ Р 56920-2016. Тестирование программного обеспечения
http://docs.cntd.ru/document/1200134996
Термины
- accessibility testing - удобство использования, степень возможности управления пользователями с разными характеристиками
- actual results - совокупность поведений, условий и прочих связанных данных полученных во время проведения теста
- backup and recovery testing - тестирование надежности. Состояние системы после восстановления из резервной копии при указанных параметрах времени, стоимости, полноты и точности
- black-box testing - тестирование на основе спецификации
- capacity testing - тестирование производительности, для оценки уровня нагрузки при котором начнется деградация производительности
- compatibility testing - тест на совместимость с другими независимыми продуктами
- coverage item - элемент тестового покрытия
- decision - тип оператора выбора одного из двух или более возможных результатов для определения выбора конкретного набора действий
- dynamic testing - когда требуется выполнение элемента тестирования
- endurance testing - может ли элемент долго выдерживать требуемую нагрузку
- equivalence partition - исключить набор входных данных, которые заставляют систему вести себя одинаково и давать одинаковый результат при тестировании программы
- equivalence partition coverage - доля разделов эквивалентности покрываемая набором тестов
- equivalence partitioning - метод проектирования тестирования, при котором контрольные примеры разработаны таким образом, чтобы проверить разделы эквивалентности с помощью одного или более представительных элементов каждого раздела
- error guessing - контрольные примеры берутся на основе опыта тестировщика
- expected results - предсказание поведения на основе спецификации
- exploratory testing - похоже на error guessing, тестирование по наитию
- feature set - набор функций элемента
- Incident Report - документация по инциденту о его проявлении, природе и состоянии
- installability testing - тест переносимости
- load testing - тест производительности для оценки поведения элемента под нагрузкой
- maintainability testing - тест на эффективность изменяемости элемента
- Organizational Test Policy - документ, описывающий назначение, цели, предметная область и тд. применения тестирования в организации
- Organizational Test Process - тесты для разработки орг. спеков тестирования
- Organizational Test Specification - спека по тестированию в организации
- Organizational Test Strategy - универсальные требования к тестам для всех проектов в организации, и описание того как проводить тесты
- pass/fail criteria - правила для решения провален тест или пройден
- performance testing - оценка степени выполнения функций при ограничении времени и ресурсов
- portability testing - тест переносимости
- procedure testing - отвечают ли требованиям пользователя и обеспечивают ли цель их применения процедурные инструкции по взаимодействию с элементом тестирования или по использованию его выходных данных
- product risk - риск наличия дефекта в продукте
- project risk - риск на менеджменте проекта
- regression testing - тесты после изменений
- reliability testing - оценка надежности, оценка частоты отказов за указанный период времени
- retesting - перетест после фиксов
- risk-base testing - тестирование основанное на рисках
- scenario testing - тесты конкретных сценариев
- scripted testing - динамические тесты по скрипту
- security testing - тест защищенности элемента и связанных с ним данных
- specification-based testing - тестирование на основе спецификации (например когда нет исходников), синоним - тестирование методом "черного ящика"
- statement coverage - процент покрытия тестами всех исполнимых операторов
- statement testing - при таком тесте создаются контрольные примеры для выполнения некоторых операторов
- static testing - тестирование без выполнения кода, на основе каких-то критериев и каких-то свойств
- stress testing - тест производительности для оценки поведения элемента при высокой нагрузке или при нехватке ресурсов
- structure-based testing - тестирование на основе структуры
- structure-based testing - анализ структуры элемента, синоним - тестирование методом "белого ящика"
- suspension criteria - критерии для остановки процедуры тестирования
- test basis - свод знаний для тестирования и контрольных примеров (спецификация итд)
- test case - совокупность предварительных условий контрольного примера, входов и ожидаемых результатов
- Test Case Specification - Документация ряда одного или большего количества контрольных примеров
- Test Completion Process - Процесс менеджмента тестирования, необходимый для обеспечения доступности полезных активов тестирования для дальнейшего использования
Голосование в Slack
Через стикеры
Тут и нечего объяснять, просто сообщение и под ним стикеры, может быть со стрелками вправо и влево (если два варианта), или может быть с номерами, или вообще как придумаешь
Polly
Полли это бот который вроде как может кучу всего и у него даже есть платные функции
Я с помощью него сделаю только опрос (дальше лезть не буду)
Не особо врубился как именно правильно добавить это приложение в свой слак. Я добавил через раздел приложения в самом слаке, а потом тыкнул по ссылке в статье и согласился там с разными правилами
https://www.polly.ai/help/slack/creating-polls
После этого становится доступна это страница
https://app.polly.ai
Как видно в левом баре, я добавил полли в рабочее пространство i-Space
Можно оформить опрос как через сам слак, так и через сайт https://app.polly.ai/
На сайте видна некоторая инфа (в самом слаке наверное тоже)
Сделал через сайт (там удобный и понятный интерфейс)
Вставил картинки через публичную шару
Вот так выглядит с телефона
Чтобы добавить голосование в приватный чат, нужно сначала заинвайтить в этот чат polly
Иначе в выпадашке для выбора куда отправить голосование не будет доступен этот приватный чат
Nextcloud
root@mars:~/nextcloud# cat start.sh
docker run --name nextcloud \
-e NEXTCLOUD_ADMIN_USER=vandud \
-e NEXTCLOUD_ADMIN_PASSWORD=ZzaNNoeu.......YP \
-d nextcloud:20.0.5-apache
Алгоритмы балансировки
RoundRobin - Каждое новое подключение передается новому серверу из пула серверов по кругу
WeightedRoundRobin - То же что и обычный RR, но у каждого сервера в пуле есть коэфициент, в соотв. с которым разные серверы из пула получают разное количество подключений (полезно когда сервера разной мощности)
LeastConnections - RR не учитывает количество активных соединений, а least connections учитывает и может передавать соединение на сервер с наименьшим количеством активных подключений (то есть поддерживает равным количество активных соединений с серверам из пула)
WeightedLeastConnections - То же что и обычный LeastConnections, только с весами (полезно когда сервера разной мощности)
SourceIDHash - Выбирает сервер на основе хэша ip-адреса клиента, таким образом клиент привязывается к конкретному серверу
[Least]ResponseTime - Сервер выбирается на основе времени ответа, то есть запрос передается тому кто быстрее
Weighted[Least]ResponseTime - Аналогично тому что выше, только с весами
LeastBandwidthMethod - Балансировка на основе нагрузки на пропускной канал. Запрос будет передан тому кто за определенный промежуток времени использовал меньше канала
ResourceBased - Требует установленного агента на сервере, который сообщает балансеру текущую нагрузку на сервер
FixedWeighting - Администратором четко указываются веса серверов, в соответствии с которыми происходит балансировка
URL Hash - Используется для записи и последующего чтения на распределенные серверы. По хэшу от url вычисляется сервер на который нужно записать файл, а потом по этому же хэшу вычисляется сервер с которого его нужно прочитать
rfc3339
https://datatracker.ietf.org/doc/html/rfc3339
Все даты и время принимаются как происходящие в текущей эре (между 0000AD и 9999AD)
- B.C. - before Christ
- A.D. - anno domini, or "in the year of our lord"
Все время выражается с указанием смещения относительно UTC
Это исключает перепуточки из-за принятия локальных административных решений типа "летнее зимнее время"
"Z" - Суффикс прикладываемый ко времени, обозначающий UTC оффсет от 00:00
Произносится как "Zulu"
Zulu time, больше известное как "GMT" (Greenwich Mean Time) это время на нулевом меридиане
Следующие требования направлены на проблему неоднозначности при обозначения года двумя цифрами:
- Интернет протоколы должны генерить четырех цифровые года
- Использование 2-х цифровых годов отменено. Если был получен двух цифровой год, то он должен быть принят как валидный только в том случае если его интерпретация не станет причиной ошибки в работе протокола
- Некоторые древние программы могут представлять годы после 1999 как трехзначные
Так как правила летнего-зимнего времени для локальных таймзон запутаны и базируются на локальных непредсказуемых законах, то совместимость лучше всего достигается путем использования UTC
Эта спецификация не поставляет правил для локальных таймзон
Разница между локальным временем и UTC высчитвается как "local time minus UTC"
Соответственно UTC может быть высчитан как "local time minus offset"
Например: 18:50:00-04:00 - локальное врeмя и отрицательный оффсет -> 22:50:00Z
Если известно время в UTC, но незвестен оффсет, то такое время может быть представлено с оффсетом "-00:00"
Это не то же самое что и оффсет "Z" или "+00:00", который подразумевает что UTC и есть желаемое время
Если компоненты даты расположены от наименее точного к наиболее точному, то достигается одно очень удобное свойство
Если таймзоны одинаковые и представлены например как "Z" или "+00:00", то даты можно отсоритровать как строки
Человекочитаемость доказала свою важность в интернет протоколах. Человекочитаемость протоколов значительно сокращает стоимость дебагинга, но с другой стороны она добавляет проблемы совместимости
Например дата "10/11/1996" абсолютно непригодна для глобального обмена, потому что она будет интерпретировать по разному в разных странах
Так как нет формата дат легкочитаемого во всех странах, интернет клиенты должны трансформировать дату в локальный формат
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
Символы "T" и "Z" должны быть прописными
Секунда может быть равна 60 или 58 в определенные моменты (leap second, високосная секунда)
Этот момент не может быть предсказан далеко в будущее. О наступлении leap second объявляет за пару недель служба IERS
Примеры:
- UTC с дробной секундой
1985-04-12T23:20:50.52Z
-
1996-12-19T16:39:57-08:00
- local time;-08:00
- offset;1996-12-20T00:39:57Z
- UTC1996-12-19T16:39:57-08:00
- leap second with offset
1990-12-31T15:59:60-08:00
HTML URL Encoding
Урлы могут содержать только ASCII символы
Все символы выходящие за набор ASCII преобразуются в комбинацию из процента %
и следующим за ним hex номером символа из ASCII таблицы
Пробелов в урле быть не может, поэтому они заменяются по той же схеме на %20
или могут быть заменены на плюсы +
JWT (JSON Web Token) / JWS (JSON Web Signature) / JWE (JSON Web Encryption) / JWK (JSON Web Key) / JWA (JSON Web Algorithms)
JWS - https://datatracker.ietf.org/doc/html/rfc7515
JWE - https://datatracker.ietf.org/doc/html/rfc7516
JWK - https://datatracker.ietf.org/doc/html/rfc7517
JWA - https://datatracker.ietf.org/doc/html/rfc7518
JWT - https://datatracker.ietf.org/doc/html/rfc7519
JOSE Examples - https://datatracker.ietf.org/doc/html/rfc7520
Что-то что я узнал из статьи https://ru.wikipedia.org/wiki/JSON_Web_Token:
Буду разбираться на примере jwt-токена который мне сгенерила центрифуга
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwiZXhwIjoxNjU0MTc5MDg3fQ.xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8
Токен состоит из трех частей: заголовок, пейлоад и подпись
Первые две представлены в виде json'а, закодированы в base64 и разделены точками
# echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwiZXhwIjoxNjU0MTc5MDg3fQ.xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8' | sed 's/\./\n/g'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
eyJzdWIiOiIxIiwiZXhwIjoxNjU0MTc5MDg3fQ
xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8
# echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwiZXhwIjoxNjU0MTc5MDg3fQ.xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8' | sed 's/\./\n/g' | head -n 2 | base64 -d - 2>/dev/null | jq
{
"alg": "HS256",
"typ": "JWT"
}
{
"sub": "1",
"exp": 1654179087
}
Header:
-
alg
- алгоритм подписи (если токен не подписанный то в значении ставитсяnone
)(это единственный обязательный ключ) -
typ
- тип токена (JWT
) -
cty
- content type (JWT
)
Payload:
-
iss
- issuer - идентификатор стороны выдавшей токен -
sub
- subject - идентификатор стороны которой выдан токен (должен быть уникальным в рамках одного issuer) -
aud
- audience - список получателей токена -
exp
- expiration - время когда токен протухнет в unixtime -
nbf
- not before - время когда токен станет валидным -
jti
- jwt id - айди токена -
iat
- issued at - когда токен был выдан
Чтобы получить подпись, нужно взять первые две за'base64'ные части, закодировать их с использованием ключа и пропустить через base64
В моем случае ключ был такой:
# grep token_hmac_secret_key /etc/centrifugo/config.yaml
token_hmac_secret_key: "b06abc67-5044-415e-afff-843be892519c"
Пробуем сгенерить подпись:
# echo -n 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwiZXhwIjoxNjU0MTc5MDg3fQ' | openssl dgst -sha256 -hmac 'b06abc67-5044-415e-afff-843be892519c' -binary | openssl base64 -e -A
xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8=
Получается вот такая штука - xy8L4IQO1NsehSN2mkgSeLE2n6QxiTByZ7XHuWFmQh8=
Если выкинуть =
то получается третья часть изначального токена
Zabbix 1.8.22
Zabbix поддерживает опрос данных (пуллер) и получение данных (траппер)
Термины 'pooler' и 'trapper' практически не переводимы на русский язык
Pooler - форк процессов “zabbix_server” и “zabbix_proxy”, который собирает с Zabbix агентов данные по элементам данных или например с SNMP устройств и др
Trapper - форк процессов “zabbix_server” и “zabbix_proxy”, который слушает порт (обычно 10051) и принимает данные от Zabbix агентов по активным проверкам или данные от zabbix_sender
Zabbix Agent'ы нужно обновлять реже чем Zabbix Proxy (при обновлении сервера)
Общее количество требуемого места на жестком диске под базу данных рассчитывается:
Конфигурация + История + Тенденции + События
После установки Zabbix такое дисковое пространство более не будет использовано сразу. Размер базы данных будет увеличиваться со временем, но потом рост все же остановится - это зависит от настроек очистки базы данных (Housekeeper)
Важно чтобы на сервере было точное вермя
Заббикс состоит из:
- Zabbix Server
Проверяет разные сервисы, агенты сообщают ему метрики, является хранилищем (конфиг, статистика, оперативные данные), делает оповещения в случае проблем
Может мониторить без агентов и с помощью snmp - Zabbix Proxy
Необязательный компонент, собирает метрики в буфер потом пересылает в ЗС, может быть использован для распределения нагрузки - Zabbix Agent
Собирает информацию с хоста и передает ЗС, является эффетивным (нативный) - Web
Веб интерфейс
Скачать 1.8.22 тут https://cdn.zabbix.com/zabbix/sources/oldstable/1.8/zabbix-1.8.22.tar.gz
Там все сразу
Установка
- Для сервера нужен непривилегированный пользователь (обычно zabbix), из под рута запускать опасно (процесс zabbix_server имеет защиту от запуска из под рута)
Агент и сервер на одной машине рекомендуется запускать под разными пользователями (иначе агент будет иметь доступ к конфигам сервера и через веб можно будет дернуть конфиг сервера)