СНГ Open source проекты .NET
Всем привет
Дайте ссылок на Open source проекты, хочется посмотреть, что интересного делают у нас.
Всем привет
Дайте ссылок на Open source проекты, хочется посмотреть, что интересного делают у нас.
По профессиональной своей деятельности случаются задачи по оперативной диагностике промышленной техники. В моем случае силовые агрегаты техники, как правило, дизельные двигатели самостоятельно или в паре с автоматической трансмиссией. Система управления силовых агрегатов построена на CAN шине и использует протокол J1939.
Поскольку по работе я не в ИТ, но по хобби давно и плотно с этим связан, то решил я собрать просмотрщик параметров сам. Импортозаместить, так сказать, готовые дорогие заморские решения.
Конечно правда жизни такова, что не использовать импортные компоненты и программные решения уже невозможно, и поэтому в конечном устройстве из отечественного - желание и время.. ну и денег немного. И даже исходники были выложены на “не наш” Github, но это из-за github pages для демонстрации веб интерфейса. В конце концов хватит работать в стол и пришло время тоже бесплатно что-то отдать обществу.
Продукт довольно нишевый и не предназначен для широких масс, но тем не менее я надеюсь, что мои наработки позволят кому нибудь получить ответы на какие-то свои вопросы или быстро стартануть свой проект, если возникнет необходимость использовать подобный стек. А стек здесь такой - в качестве сервера ESP32. В качестве языка backend - c++ в качестве фреймворка бэкенда - ESP-IDF. Для фронтенда использовал Vue3, Typescript, Vite…
Обзор устройства начну с конца, постепенно раскрывая детали:
Комплектующие:
Схема:
Прошивка:
Железо и backend:
По схеме тут все просто - используются готовые компоненты. Задача понижающего преобразователя напряжения - получить 5v из бортовой сети двигателя (24-28v). На плате Devkit ESP32 имеется свой преобразователь и он из 5v делает 3.3v, что и используется непосредственно ESP32. На входе преобразователя я еще дополнительно припаял диод как элементарную защиту от переполюсовки, хотя по идее можно поставить диодный мост и тогда по поводу перепутать плюс и минус можно не заморачиваться. А переполюсовка тут актуальная тема т.к. у разных производителей на одном и том же разъеме плюсы и минусы на тех же пинах, но поменяны местами. CAN трансивер необходим для преобразования физического уровня CAN шины для работы с обычными цифровыми пинами микроконтроллера.
Для создания программы для микроконтроллера использовался VS Code с установленным официальным расширением от Espressif - Espressif IDF. Может быть используя Arduino платформу какие то вещи можно было бы сделать удобнее, но был интерес въехать и потрогать немного FreeRTOS как бы непосредственно. Немного непривычно поначалу, но если разобраться, то все хорошо. Могу сказать, что система сборки у Espressif норм.
Микроконтроллер при старте инициализирует SPIFFS хранилище (аналог файлового хранилища, где хранятся файлы фронтенда), поднимает точку доступа, файловый сервер, websocket сервер, инициализирует CAN драйвер, начинает слушать CAN шину и при получении сообщений рассылать их всем websocket клиентам подключенным к серверу. Кстати CAN драйвер в ESP32 называется TWAI , что , как я понял , связано с какими-то лицензионными заморочками.
Особенностью файлового сервера является то, что при запросе клиентом файла он пытается отдать этот файл , а если его нет, то пытается отдать заархивированный файл {имяфайла}.{расширение}.gz и только если нет ни того ни другого отвечает ошибкой. Что касается протокола J1939, то на микроконтроллере реализовано только чтение обычных сообщений , широковещательных сообщений переданных по транспортному протоколу (более 8 байт) и отправка простых (8 байт) сообщений в шину. По задумке устройство может отправлять в шину только сообщения об очистке сохраненных ошибок, но тот же самый механизм используется при отправке сообщений для управления желаемой скоростью вращения двигателя и желаемой передачи АКПП. Расшифровка же сообщений происходит в браузере клиента.
Фото:
Frontend:
Для веб интерфейса использовал современные инструменты веб разработки последних ревизий:
Проект веб приложения имеет 3 сценария сборки:
build_preview - собирает проект для предпросмотра на локальном сервере (preview)
build_embedded - собирает проект непосредственно для микроконтроллера. Генерируются только архивированные файлы gz. Разделение на части не производится т.к. опытным путем установлено, что файловый сервер ESP32 быстрее отдает один файл побольше чем несколько разделенных файлов. Весь проект в архивированном виде имеет размер 498kB и отлично помещается в памяти ESP.
build_deploy - этот сценарий добавлен недавно и создает файлы для публикации приложения на github pages. Пример настройки альтернативного именования файлов, поскольку сборка по умолчанию (preview) генерирует файл с символом “_” в начале, что в результате порождает ошибку при скачивании файла браузером.
Помню в начале знакомства с веб разработкой у меня было непонимание - где конкретно находятся файлы веб приложения и как они исполняются. И если у кого-то возникает такой вопрос, то работает это все так: При обращении из браузера (клиента) к какой-либо странице, сервер отвечает файлом index.html. В этом файле есть список файлов веб приложения и браузер запрашивает эти файлы с сервера, разархивирует и далее действует по инструкциям из этих файлов. Таким образом файлы веб приложения изначально находятся на сервере, скачиваются и выполняются браузером.
На веб приложение ушло больше всего времени. Изначально я сделал все с использованием замечательной библиотеки element-plus, но почему-то выловил жесткую утечку памяти и месяц бился с этим явлением. Постепенно заменяя компоненты из element-plus самописными.
Общий алгоритм работы приложения такой- приложение получает массив байт от микроконтроллера, далее этот массив декодируется с помощью данных из JSON файла. (Как я искал и парсил доступную инфу по J1939 - тема для отдельной статьи.)
Поскольку вся спецификация протокола довольно объемна, то хранить ее на мк не выйдет , по крайней мере в стандартной комплектации ESP32 Devkit с 4 Mb флеш памяти. В связи с чем решено было хранить данные для декодирования параметров и передаваемых ошибок на стороне клиента в браузере. При первой загрузке веб приложения эти файлы создаются автоматически, но имеют немного данных для декодирования и можно изменить данные в этом файле в текстовом редакторе или загрузить по указанным в приложении ссылкам.
При загрузке файлов правильность их структуры проверяется с помощью отличного AJV по схеме файла. Данные хранятся в памяти браузера и при использовании из другого браузера или с другого устройства надо опять подгружать файлы.
Поиск по параметрам осуществляется с помощью FuseJS через интеграцию VueUse. Вообще библиотека VueUse должна быть дефолтной частью проекта на Vue3 поскольку содержит огромное количество очень полезных функций, которые намного облегчают код и работают напрямую с реактивными объектами Vue.
В приложении есть возможность строить графики изменения параметров. Добавление параметра на график осуществляется включением соответствующего переключателя в меню параметра. Графики строятся используя гениальный Echarts и в коде в частности есть пример переключения темы графика “на лету”.
И все это дело собирается в 498Kb! По моему не плохо. Собранные файлы помещаются в папку spiffs_images проекта для микроконтроллера и сохраняются в его памяти при прошивке. Из этой области памяти файловый сервер ESP32 отдает файлы по запросу браузера.
Среди вопросов по работе остался момент периодической “заморозке” вебсокет сообщений, которые были замечены из браузеров на линуксе и на андройде, причем периодичность их появления не зависит ни от чего. Из браузеров виндовса подобная проблема ни разу не проявила себя, что наталкивает на мысль о какой-то глубокой малозаметной ошибке в реализации протокола либо на стороне ESP либо на клиентской стороне.
Вообще в целом реализация проекта подарила интересный опыт и полезные наработки, что, думаю, может пригодиться в будущем (если оно будет)).
Фото в “полях”:
P.S. Поскольку я сам не в ит и для знакомых я занимаюсь непонятными делами и разговариваю непонятными словами, то мне была бы интересна обратная связь, замечания и предложения по коду и реализации проекта.
Есть в Интернете программы, которые позволяют отслеживать изменения на сайтах.
Правда есть у них свои недостатки: что-то платное, что-то неудобное, где-то ограничения по количеству отслеживаемых страниц, некоторые работают как расширения браузера, и его необходимо держать постоянно запущенным и т.д.
Раз "я ж программист", то решил написать простенькую альтернативу с нужным мне функционалом, и раз уж программа написана, может она пригодится еще кому-то, так что решил её опубликовать с исходниками и описанием на GitHub.
Основные хотелки к программе были такие:
1. Должна работать с моего компьютера, а не из облака.
2. Нужна подсветка изменений произошедших на сайте.
3. Должна быть возможность отслеживать страницы на сайтах, которые доступны только после авторизации
4. Программа должна уведомлять пользователя при обнаружении изменений на страницах
С результатом моего "творчества" можно ознакомиться на https://github.com/hronoas/SiteWatcher
Скачать можно оттуда же.
P.S. А раз программу я писал под себя, то и лишние "рюшечки" мне не нужны: английский интерфейс мне не нужен, я ни разу не дизайнер и работаю на винде.
Бонжур!
Доработал недавно (как и обещал в предыдущей публикации - Ansible. Network-scripts. RHEL8) функционал ansible-хелпера "conf_int_ipv4_via_network_scripts". Теперь изменения сетевых настроек возможно применить временно (например, на период тестирования). Для этого достаточно:
1) сконфигурировать целевые интерфейсы посредством правки файла "config";
2) задать время отката настроек на предыдущие через конфиг "additional_configs/config_temporary_apply_ifcfg" (по умолчанию = 10 минут);
3) запустить скрипт "apply_temporary_ifcfg.sh". Выполняет действия, аналогичные "apply_immediately_ifcfg.sh" (т.е. реконфигурирует сеть в соответствии с файлом "config"), но перед рестартом сервиса "network" запускает на удалённом хосте bash-скрипт "rollback_ifcfg_changes.sh", который возвращает сетевые настройки к виду до модификации через временной промежуток, определённый в файле "config_temporary_apply_ifcfg";
4) протестировать сетевые связанности целевых хостов (вероятно, когда-нибудь реализую утилиту на основе стека "ansible + bash + perl");
5) если всё в порядке, то запустить скрипт "apply_immediately_ifcfg.sh", который остановит исполнение сценария "rollback_ifcfg_changes.sh".
Итого, два варианта на выбор пользователя - либо применить новые настройки незамедлительно (just run "apply_immediately_ifcfg.sh"), либо применить их временно (run "apply_temporary_ifcfg.sh") до осуществления тестирования и отмены возврата к предыдущей конфигурации сети хоста (run "apply_immediately_ifcfg.sh").
Конечно, неплохо бы добавить централизованный сбор наименований сетевых интерфейсов и соответствующих им MAC-адресов, дабы в автоматическом режиме (при попытке применить конфигурацию) сверять с тем, что пользователь напишет в конфиге (и прекращать выполнение софта, если, например, для интерфейса задан некорректный MAC), но эту фичу, думаю, реализую позже.
P.S. На очереди небольшой сюрприз для любителей разрешать доступ только к тем сетевым портам, которые необходимы для конкретного сервиса.
===
Ссылка на репозиторий: https://github.com/vladimir-chursin000/ansible_helpers
Приветствую!
В рамках создания ansible-helper-а "conf_int_ipv4_via_network_scripts" дописал скрипт ("generate_dynamic_ifcfg.pl") генерации сетевых интерфейсов для network-scripts по заранее заданным конфигурациям, который вполне допустимо использовать отдельно от хелпера (файл конфигурации с примерами = config_examples).
Чтобы использовать perl-программу вне контекста репозитория, потребуется:
1. Залогиниться на хост/ВМ с ОС Linux и установленным Perl5.
2. Скопировать скрипт "generate_dynamic_ifcfg.pl", например, в директорию "/opt/generate_dynamic_ifcfg".
3. Скопировать файл конфигурации (config), файл с примерами конфигурации (config_examples) и папку "ifcfg_tmplt" (содержит шаблоны конфигураций интерфейсов) в директорию со скриптом.
4. Откорректировать параметры скрипта из блока "STATIC VARS", т.е. задать директорию с шаблонами ifcfg-файлов и директорию для размещения сконфигурированных сетевых интерфейсов (ifcfg-файлов с конкретными значениями: имя интерфейса, MAC-адрес и проч.).
5. Отредактировать файл config, задав свои настройки сетевых интерфейсов (обычный интерфейс, bond, bridge, etc).
6. Запустить скрипт.
7. PROFIT!
P.S. №1. Увы, сам хелпер пока далёк от завершения. Предстоит ещё многое сделать, в т.ч. и, например, реализовать механизм временного применения сетевых настроек, например, на 3-4 минуты с последующим откатом к предыдущей конфигурации (наверняка для кого-то сия опция окажется весьма полезной).
===
P.S. №2. Ох и объёмная же статья (на основе репозитория ansible_helpers) для Хабра получится.
===Доброго вечера (утра/дня/ночи)!
В рамках репозитория "ansible_helpers" добавлено новое приложение "install_nfs_client" ( https://github.com/vladimir-chursin000/ansible_helpers ), позволяющее централизованно управлять nfs-клиентами на множестве ОС вида "rhel8_based" (также произведены косметические изменения на ранее созданных "приложениях").
Ключевая особенность - единый файл конфигурации, на основе которого динамически формируются yml-файлы с заданиями (tasks) на монтирование nfs-ресурсов. Т.е. достаточно заполнить inventory-файл "nfs_client_hosts" (вписав ip-адреса целевых хостов), внести изменения в файл "dyn_mount_config" и запустить скрипт "install_nfs_client.sh" (или "just_apply_new_mounts.sh", если необходимый софт для доступа к сетевым файловым системам уже установлен), чтобы получить результат.
===
P.S. На очереди "приложение" для развёртывания набора сетевых сервисов в комплексе (samba + vsftpd + webdav + etc).
Только половина компаний применяют политики безопасности программного обеспечения с открытым исходным кодом. Open Source стал жертвой собственного успеха, поскольку его повсеместное распространение сделало его мишенью для атак на целые цепочки поставок и проектов. Об этом говорит Robert Lemos в журнале Data Center Knowledge. Рассмотрим вопрос более детально.
Программное обеспечение с открытым исходным кодом (open source software — OSS) имеет значительные преимущества в разработке приложений, но компании также должны быть готовы и к недостаткам. Согласно одному из отчетов, приложение JavaScript имеет наибольшее количество зависимостей — в среднем 174 на проект, что примерно в семь раз больше, чем язык с наименьшим количеством зависимостей, Python — 25 на проект.
Данные также показывают, что разные языки, как правило, имеют разную серьезность недостатков. Средний проект, написанный на Java, например, имел более 47 уязвимостей высокой степени серьезности и 28 уязвимостей средней степени серьезности, что намного выше, чем у проектов на JavaScript, которые имели в среднем 18 и 21 уязвимость соответственно. Однако у Python было больше всего уязвимостей с низкой степенью опасности, в среднем 20 на проект.
На количество и типы уязвимостей влияет множество факторов — сложность проектов, количество разработчиков и популярность. Наиболее популярные проекты, скорее всего имеют и больше всего ошибок.
Что касается исправления ошибок, то приложения, написанные на .NET, например, имели самое большое среднее время — 148 дней, за ними следует JavaScript. Между тем приложения, написанные на Go, имели самое быстрое время для исправления и обычно исправлялись за треть этого времени — за 49 дней.
Хотя наличие большого количества зависимостей необязательно является недостатком, если у организации есть способы отслеживать связи между проектами. Однако только около половины фирм имеют политику безопасности при работе с открытым исходным кодом, при этом 60% число малых компаний либо не имеют таких политики, либо даже не знают, есть ли она у них.
Малые предприятия имеют небольшой ИТ-персонал и небольшие бюджеты. Нехватка ресурсов и времени — основная причина того, что организации не применяют передовые методы обеспечения безопасности OSS. Вместе с тем даже легкая политика в этом направлении является хорошим началом.
Хотя справедливости ради нужно заметить, что только 60% компаний с так скажем зрелым уровнем безопасности полагаются на отраслевые рекомендации по уязвимостям. Автоматический мониторинг пакетов на наличие ошибок используют также 60%, а уведомления от сопровождающих пакетов 49%.
===
Немного фактографии
Приводим выдержки трех новостей из различных ниш свободно распространяемого ПО:
1) Специалисты безопасности цепочек поставок ПО Sonatype обнаружили очередные вредоносные пакеты Python PyPi, посредством которых подтягивалась конфиденциальная информация, включая учетные данные AWS. Среди них: loglib-modules, pyg-modules, pygrata, pygrata-utils и hkg-sol-utils. При этом первые два пакета закамуфлированы под известные проекты на PyPI, вводя в заблуждение невнимательных или неопытных разработчиков в ходе их имплементации, последние три не имеют явного таргетинга, но все имеют сходство кода или взаимосвязи.
Перехватываемые данные хранились в формате TXT и передавались через домен PyGrata. com. При этом конечная точка не была защищена должным образом, в связи с чем аналитики могли ознакомиться со всем, что утекло.
2) Тайваньский производитель QNAP, похоже что, нашел причину новых атак на владельцев своих сетевых хранилищ (NAS). Разработчики сейчас находятся в стадии активного исправления критической уязвимости PHP трехлетней давности, которая приводит к RCE. Уязвимость затрагивает версии PHP 7.1.x ниже 7.1.33, 7.2.x ниже 7.2.24 и 7.3.x ниже 7.3.11 с кривой конфигурацией nginx (с конфигурациями, отличными от настроек по умолчанию). Она отслеживается как CVE-2019-11043 и имеет рейтинг серьезности 9,8 из 10 в системе оценки CVSS.
Однако пока производитель пытается бороться с DeadBolt, владельцев NAS с выходных начали атаковать вымогатели ech0raix, согласно отчетам пользователей и образцам, представленным на платформе ID Ransomware. При этом вектор заражения, используемый в новых кампаниях DeadBolt и ech0raix, остается неизвестным. До момента выяснения всех обстоятельств QNAP рекомендует клиентам перейти на новейшую версию операционных систем QTS или QuTS hero, а также отключить устройства от интернета. Если устройства имеют такие подключения, то пользователям следует отключить функцию переадресации портов маршрутизатора и UPnP QNAP NAS.
3) Разработчики WordPress обратились к принудительному обновлению в рамках противодействия масштабной кампании, нацеленной на уязвимые версии плагина Ninja Forms, который используют ежедневно более 1 млн пользователей платформы. Такое решение было принято после обнаружения ресерчерами Wordfence критической уязвимости RCE в дикой природе. Уязвимость затрагивает несколько выпусков популярного плагина для создания форм, начиная с версии 3.0 и выше.
Злоумышленники, не прошедшие проверку подлинности, могут удаленно использовать ошибку для вызова различных классов форм Ninja в функции слияния тегов, что позволяет им полностью захватить неисправленные сайты WordPress с помощью нескольких цепочек эксплуатации, одна из которых приводит к удаленному выполнению кода посредством десериализации для захвата целевого веб-сайта.
С момента исправления уязвимости 14 июня без официального уведомления более 730 000 сайтов WordPress были принудительно обновлены ввиду ошибки плагина. Подробности атак не разглашаются, однако следует все же рассматривать новую RCE серьезной угрозой и если плагин еще не был автоматически обновлен до версии 3.6.11, то это необходимо сделать вручную.
===
Комментарий дата-центра
Мы, безусловно, рекомендуем нашим клиентам соблюдать хотя бы самые минимальные политики безопасности. Например, нужно следить за публикациями на специализированных ресурсах, таких как cve. org и не только, постоянно проверять систему и код на наличие уязвимостей, используя сканеры OpenVAS, Nmap и другие, своевременно обновлять программное обеспечение. Если самостоятельно выполнять комплекс проверок затруднительно, то можно заказать аудит безопасности на стороне или у хостинг-провайдера.
Мы и сами активно используем OSS-продукты под различными лицензиями. Например, на веб-серверах применяем LAMP-стек, nginx, защиту от атак fail2ban. Собственные разработки выполняем также на основе свободного ПО (VS Code, PHP, JS, фреймворки Vue, Nest, и т.д., поэтому резюмируя вышесказанное делаем банальный вывод: используйте Open Source (особенно в свете нынешних подвижек на российском рынке), но не пускайте дело на самотек — следите за политиками безопасности, поскольку без свободно распространяемого ПО уже невозможно представить себе работу интернета.
===
Материал подготовлен дата-центром ITSOFT
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.