Зачем создавать VPC, плясать с бубном и SSH-ключами (ужас, в 2023 при наличии Session Manager) и запускать EC2-инстанс? Для работы с ECR ничего этого не нужно, ни VPC, ни маршруты, ни S3, ни EC2.
Что мешает локально (со своей машины) создать репозитарий с конфигурацией сканирования, сделать docker pull, авторизоваться в ECR и сделать docker push (итого 5 строк)? Статью можно уместить в 1 абзац. Какую-то антирекламу курса по DevSecOps сделали.
В развитых странах нет обязательного наличия паспорта. Паспорт в развитых странах имеет лишь часть населения, получают добровольно для выезда зарубеж.
На примере Австралии: Для общения с госорганами или банками в развитых странах нужен ID. Это может быть ID-карта, водительсткое удостоверение, просто идентификационная карта итд. В определенных случаях одного лишь ID недостаточно, и нужен более чем один документ (например один документ с фотографией, например водительские права + один документ без фотографии, например свидетельство о рождении + один документ с указанием адреса и именем, например счет за воду или электричество).
Счета в банках не привязаны к сроку действия каких-либо удостоверяющих документов. Для путешествий внутри страны (в том числе на самолетах и поездах) не нужно никакого удостоверения (но вот при заселении в отель ID попросят).
Впрочем, посмотрев на фото расположения АНАЛОГОВОГО выхода "FiiO M3 MQA" в непосредственной близости от НЕЭКРАНИРОВАННОГО "Raspberry Pi" (наводки? "Нет, не слышали" (с)) сомнения в компетентности автора полностью испарились.
Про MQA написаны уже толмуды - никакого отношения к Hi-Fi этот кодек не имеет (так как является кодеком с потерями). Писать об MQA как о "FLAC на стероидах" - это из серии нонсенса. Уж либо "без потерь" (тот же FLAC, например), либо "мы тут внесли искажений и потеряли часть звука..." (MQA).
Nest Thermostat отлично подходит для простых систем отопления/кондиционирования, в которых (например) нет вариации уровня нагрева (хотя 2-х шаговый режим они поддерживают) или регулировки уровня вентиляции (этого вовсе нет - только on/off). О "многозональных" системах и вовсе - умолчу (системы, поддерживающие многозональность не поддерживаются Nest Thermostat "никак"). Иными словами - хорошо подходит для систем отопления/кондиционирования, превалирующих на рынке Северной Америки. И именно поэтому, например, термостаты Nest не поставляются официально в Австралию (где довольно давно эти функции были добавлены проприетарным способом на уровне каждого производителя и начался "отход" от крассического управления замыканием контактов на 24В в сторону проприетарных протоколов управления).
В общем - подходит для ограниченных сценариев использования при условии, что у вас "простая" аналоговая система на 24В, управляемая методом "замыкания контактов".
Полностью поддерживаю. Уже давно использую Syncthing для синхронизации между телефонами и компьютером. Безопасно, просто, надежно, опенсорсно: https://syncthing.net/
GPL. Модификация Samba. Все модификации кода должны быть свободно предоставлены.
Собственно, о чем статья - непонятно. Samba4 (на любом дистрибутиве Linux) поддерживает групповые политики. Ссылка в статье ведет на сайт с документацией к АльтЛинукс (на котором описание работы с Samba4 на уровне командной строки). Что "нового" было изобретено (и где исходники модифицированной под GPL Samba) - так и не ясно.
Судя по ссылкам на "новости" - просто освоили госбюджет на написание аналога Group Policy Editor - компонента RSAT от Microsoft (дабы не использовать GUI от Microsoft). Как это относится к модификации Samba - тоже непонятно.
Очень неоптимальное решение, имеющее следующие проблемы:
1) надо удостовериться, что команда, сливающая статистику в файл и отправляющая данные (периодически) запускается (например, по крону) или же мониторить факт поступления данных
2) надо удостовериться, что файл действительно обновляется свежими данными (например, ошибка записи в файл оставит данные старыми или невалидными).
Вообще, архитектура (связка) cron -> cli -> промежуточный файл -> скрипт парсинга -> zabbix_sender — слишком длинная и имеет много возможных точек отказа.
Намного проще и надежнее сделать по-другому. В Zabbix 3.4 появились зависимые элементы данных (dependent items), позволяющие получить данные одним запросом через агент с ОДНИМ единственным юзерпараметром (не надо описывать отдельно ничего, получаем целиком весь вывод nmcli) и заполнить все зависимые данные через внутренний парсинг самого zabbix-сервера (item preprocessing).
Это позволяет исключить cron, промежуточный файл, скрипты обработки и утилиту отправки данных.
Итоговая архитектура предельно проста и гарантирует получение свежих данных.
Парсить данные надо средствами самого zabbix-сервера и раскладывать данные по зависимым элементам (выполнив один-единственный атомарный запрос, без использования кучи юзерпараметров).
Вы забыли оценить стоимость затраченного вами времени. Если потраченное время (почасовая ставка специалиста вашего уровня * количество часов) стоит меньше 24000 за нормальную колонку (лишенную устраняемых недостатков) - то вы в плюсе.
Вы ссылаетесь на сообщение в форуме 5-дневной давности (которое лишь подтверждает, что мартовское обновление пришло не на фиксированную дату месяца, и именно потому, что эти важные обновления и добавляли в патчсет - ожидаемо).
Данные по уязвимостям опубликовали 16 марта 2023 (согласно политике через 90 дней после первичного обнаружения) - по вашей же ссылке. Уже 20-го марта 2023 (на 4-й день) Гугл выпустили обновление (хотя предоставляют патчи Самсунг - это у них в коде для модема "косяк".) Таймлайн доступен по ВАШЕЙ же ссылке. Сегодня 21-е, обновление уже устанавилось (прямо сейчас) на мой Pixel 6 Pro. Размер патча 270 МБ.
Выпустить патч за 4 дня - весьма неплохо. Вывод может быть только один - у Гугл нет проблем с обновлениями (особенно с обновлениями безопасности).
Полностью поддерживаю. Discovery на стороне сервера напрямую Zabbix'ом с CRM + автоматическое создание items.
Опять же автор опубликовал решение на основе старых (и весьма неоптимальных) практик (да еще и крон и пароль админа для доступа в API в тектовом файле - а если крон-задача отвалится или данные авторизации API "протухнут" - будем верить, что items все еще актуальны?).
Я прекрасно понимаю ваши доводы. Сам начинал мониторить LSI с этого решения. В итоге когда был сбой (не помню, вроде с sudoers что-то, давно было) и временный файл, содержащий "ответ" от опроса контроллера попросту не обновлялся, на сервер отправлялись старые данные (из необновленного файла). nodata триггеры в этом случае не сработают (данные-то приходят! правда этим данным уже несколько месяцев и за это время рейд посыпался - только вот об этом никто не узнает!). Так что заявленный мною сценарий "проблемы" при таком подходе был выстрадан на живой системе на практике (поэтому я так "топлю" за правильные подходы).
А потом мы поставили в новый сервер новые карты, которые уже не работали с MegaCLI. StorCLI решил все проблемы (он универсален, поддерживает json и работает со старыми картами вместо MegaCLI). Решение с мониторингом я переписал, чтобы не было временных файлов. Заодно сделал безопасным в плане передачи агрументов. Работодателя с тех пор сменил и решения уже не осталось (на github не выклыдывал).
Zabbix развивается семимильными шагами, и те практики, что использовались ранее (зачастую далекие от идеала) теперь лучше избегать.
"Оторвал взгляд от клавы, посмотрел на экран…" (c)
Дальше читать эту муть не стал.
Автор - при наборе на клавиатуре смотреть надо ИСКЛЮЧИТЕЛЬНО на экран!
Зачем создавать VPC, плясать с бубном и SSH-ключами (ужас, в 2023 при наличии Session Manager) и запускать EC2-инстанс?
Для работы с ECR ничего этого не нужно, ни VPC, ни маршруты, ни S3, ни EC2.
Что мешает локально (со своей машины) создать репозитарий с конфигурацией сканирования, сделать docker pull, авторизоваться в ECR и сделать docker push (итого 5 строк)?
Статью можно уместить в 1 абзац.
Какую-то антирекламу курса по DevSecOps сделали.
Вы написали очень много текста для вопроса, суть которого сводится к "где вы были 8 лет"...
По теме: меня больше смущает лицензионная чистота (как я понял, закрытых) доработок (частично извользуемой) Samba, которая идет под GPL!
В развитых странах нет обязательного наличия паспорта.
Паспорт в развитых странах имеет лишь часть населения, получают добровольно для выезда зарубеж.
На примере Австралии:
Для общения с госорганами или банками в развитых странах нужен ID. Это может быть ID-карта, водительсткое удостоверение, просто идентификационная карта итд.
В определенных случаях одного лишь ID недостаточно, и нужен более чем один документ (например один документ с фотографией, например водительские права + один документ без фотографии, например свидетельство о рождении + один документ с указанием адреса и именем, например счет за воду или электричество).
Счета в банках не привязаны к сроку действия каких-либо удостоверяющих документов.
Для путешествий внутри страны (в том числе на самолетах и поездах) не нужно никакого удостоверения (но вот при заселении в отель ID попросят).
Впрочем, посмотрев на фото расположения АНАЛОГОВОГО выхода "FiiO M3 MQA" в непосредственной близости от НЕЭКРАНИРОВАННОГО "Raspberry Pi" (наводки? "Нет, не слышали" (с)) сомнения в компетентности автора полностью испарились.
Желаю приятного прослушивания "Hi-Fi" звука!
Про MQA написаны уже толмуды - никакого отношения к Hi-Fi этот кодек не имеет (так как является кодеком с потерями).
Писать об MQA как о "FLAC на стероидах" - это из серии нонсенса.
Уж либо "без потерь" (тот же FLAC, например), либо "мы тут внесли искажений и потеряли часть звука..." (MQA).
Вкратце можно посмотреть хотя бы это (на английском):
https://www.youtube.com/watch?v=pRjsu9-Vznc
https://www.youtube.com/watch?v=NHkqWZ9jzA0
Это даже не говоря о том, что компания MQA (патентодержатель) обанкротилась:
https://www.whathifi.com/features/mqa-has-gone-into-administration-what-does-this-mean-for-tidal-and-supported-products,
а сама компания Tidal объявила, что отныне FLAC является их приоритетом для аудио высокой четкости (high-resolution audio):
https://www.techhive.com/article/1974696/tidal-flac-preferred-hi-res-format-not-mqa.html
Автор - вы действительно понимаете значение слова "Hi-Fi"?
Судя по статье, возможно, вы - жертва маркетинга.
Nest Thermostat отлично подходит для простых систем отопления/кондиционирования, в которых (например) нет вариации уровня нагрева (хотя 2-х шаговый режим они поддерживают) или регулировки уровня вентиляции (этого вовсе нет - только on/off). О "многозональных" системах и вовсе - умолчу (системы, поддерживающие многозональность не поддерживаются Nest Thermostat "никак").
Иными словами - хорошо подходит для систем отопления/кондиционирования, превалирующих на рынке Северной Америки.
И именно поэтому, например, термостаты Nest не поставляются официально в Австралию (где довольно давно эти функции были добавлены проприетарным способом на уровне каждого производителя и начался "отход" от крассического управления замыканием контактов на 24В в сторону проприетарных протоколов управления).
В общем - подходит для ограниченных сценариев использования при условии, что у вас "простая" аналоговая система на 24В, управляемая методом "замыкания контактов".
Полностью поддерживаю.
Уже давно использую Syncthing для синхронизации между телефонами и компьютером.
Безопасно, просто, надежно, опенсорсно: https://syncthing.net/
Спасибо!
Решение представляет собой модификацию свободной разработки проекта Samba, дополненную инструментарием управления групповыми политиками. (с)
Samba is Free Software licensed under the GNU General Public License (с)
GPL. Модификация Samba. Все модификации кода должны быть свободно предоставлены.
Собственно, о чем статья - непонятно.
Samba4 (на любом дистрибутиве Linux) поддерживает групповые политики. Ссылка в статье ведет на сайт с документацией к АльтЛинукс (на котором описание работы с Samba4 на уровне командной строки). Что "нового" было изобретено (и где исходники модифицированной под GPL Samba) - так и не ясно.
Судя по ссылкам на "новости" - просто освоили госбюджет на написание аналога Group Policy Editor - компонента RSAT от Microsoft (дабы не использовать GUI от Microsoft). Как это относится к модификации Samba - тоже непонятно.
Конфигурировать можно через API calls. Зачем кликать мышкой, если GUI вообще не обязателен?
'lsb_release -a'
lsb_release входит в Linux Standard Base и должна присутствовать на каждом дистибутиве
1) надо удостовериться, что команда, сливающая статистику в файл и отправляющая данные (периодически) запускается (например, по крону) или же мониторить факт поступления данных
2) надо удостовериться, что файл действительно обновляется свежими данными (например, ошибка записи в файл оставит данные старыми или невалидными).
Вообще, архитектура (связка) cron -> cli -> промежуточный файл -> скрипт парсинга -> zabbix_sender — слишком длинная и имеет много возможных точек отказа.
Намного проще и надежнее сделать по-другому. В Zabbix 3.4 появились зависимые элементы данных (dependent items), позволяющие получить данные одним запросом через агент с ОДНИМ единственным юзерпараметром (не надо описывать отдельно ничего, получаем целиком весь вывод nmcli) и заполнить все зависимые данные через внутренний парсинг самого zabbix-сервера (item preprocessing).
Это позволяет исключить cron, промежуточный файл, скрипты обработки и утилиту отправки данных.
Итоговая архитектура предельно проста и гарантирует получение свежих данных.
Парсить данные надо средствами самого zabbix-сервера и раскладывать данные по зависимым элементам (выполнив один-единственный атомарный запрос, без использования кучи юзерпараметров).
Документация: www.zabbix.com/documentation/3.4/ru/manual/config/items/itemtypes/dependent_items
Вы забыли оценить стоимость затраченного вами времени.
Если потраченное время (почасовая ставка специалиста вашего уровня * количество часов) стоит меньше 24000 за нормальную колонку (лишенную устраняемых недостатков) - то вы в плюсе.
Собственно, само обновление: https://source.android.com/docs/security/bulletin/pixel/2023-03-01
Все исправленные CVE там перечислены (включая упомянутые 4).
Вы ссылаетесь на сообщение в форуме 5-дневной давности (которое лишь подтверждает, что мартовское обновление пришло не на фиксированную дату месяца, и именно потому, что эти важные обновления и добавляли в патчсет - ожидаемо).
Данные по уязвимостям опубликовали 16 марта 2023 (согласно политике через 90 дней после первичного обнаружения) - по вашей же ссылке.
Уже 20-го марта 2023 (на 4-й день) Гугл выпустили обновление (хотя предоставляют патчи Самсунг - это у них в коде для модема "косяк".)
Таймлайн доступен по ВАШЕЙ же ссылке.
Сегодня 21-е, обновление уже устанавилось (прямо сейчас) на мой Pixel 6 Pro.
Размер патча 270 МБ.
Выпустить патч за 4 дня - весьма неплохо.
Вывод может быть только один - у Гугл нет проблем с обновлениями (особенно с обновлениями безопасности).
netstat давным-давно legacy и не должен использоваться.
Только ss.
Zabbix-агент прекрасно читает файлы через vfs.file.contents
Нет никакой необходимости использовать "cat" (подпроцесс и лишний overhead).
Полностью поддерживаю.
Discovery на стороне сервера напрямую Zabbix'ом с CRM + автоматическое создание items.
Опять же автор опубликовал решение на основе старых (и весьма неоптимальных) практик (да еще и крон и пароль админа для доступа в API в тектовом файле - а если крон-задача отвалится или данные авторизации API "протухнут" - будем верить, что items все еще актуальны?).
Я прекрасно понимаю ваши доводы.
Сам начинал мониторить LSI с этого решения.
В итоге когда был сбой (не помню, вроде с sudoers что-то, давно было) и временный файл, содержащий "ответ" от опроса контроллера попросту не обновлялся, на сервер отправлялись старые данные (из необновленного файла). nodata триггеры в этом случае не сработают (данные-то приходят! правда этим данным уже несколько месяцев и за это время рейд посыпался - только вот об этом никто не узнает!).
Так что заявленный мною сценарий "проблемы" при таком подходе был выстрадан на живой системе на практике (поэтому я так "топлю" за правильные подходы).
А потом мы поставили в новый сервер новые карты, которые уже не работали с MegaCLI.
StorCLI решил все проблемы (он универсален, поддерживает json и работает со старыми картами вместо MegaCLI).
Решение с мониторингом я переписал, чтобы не было временных файлов. Заодно сделал безопасным в плане передачи агрументов. Работодателя с тех пор сменил и решения уже не осталось (на github не выклыдывал).
Zabbix развивается семимильными шагами, и те практики, что использовались ранее (зачастую далекие от идеала) теперь лучше избегать.