Самое важное ПО по мнению военных США

technologyreview.com — Гуглопереовод в первом
Новости, Технологии | gl00m 14:49 26.07.2022
76 комментариев | 34 за, 1 против |
#1 | 14:49 26.07.2022 | Кому: Всем
гуглопервод без правок

Военные США хотят разобраться в самом важном программном обеспечении на Земле

Открытый исходный код работает на каждом компьютере на планете и обеспечивает работу критической инфраструктуры Америки. DARPA беспокоится о том, насколько ему можно доверять

Не будет большим преувеличением сказать, что весь мир построен на основе ядра Linux, хотя большинство людей никогда о нем не слышали.

Это одна из самых первых программ, которая загружается при включении большинства компьютеров. Он позволяет оборудованию, на котором работает машина, взаимодействовать с программным обеспечением, регулирует использование ресурсов и выступает в качестве основы операционной системы.

Это основной строительный блок почти всех облачных вычислений, практически каждого суперкомпьютера, всего Интернета вещей, миллиардов смартфонов и многого другого.

Но ядро ​​также имеет открытый исходный код, что означает, что любой может писать, читать и использовать его код. И это серьезно обеспокоило экспертов по кибербезопасности в вооруженных силах США. Его природа с открытым исходным кодом означает, что ядро ​​Linux — наряду с множеством других частей критически важного программного обеспечения с открытым исходным кодом — подвергается враждебным манипуляциям способами, которые мы до сих пор едва понимаем.

«Теперь люди понимают: подождите минутку, буквально все, что мы делаем, основано на Linux», — говорит Дэйв Эйтел, исследователь кибербезопасности и бывший специалист по компьютерной безопасности АНБ. «Это основная технология для нашего общества. Непонимание безопасности ядра означает, что мы не можем защитить критически важную инфраструктуру».
Связанная история
Интернет работает на бесплатном программном обеспечении с открытым исходным кодом. Кто платит за ремонт?

Волонтерские проекты, такие как Log4J, поддерживают работу Интернета. Результатом является неустойчивое выгорание и риск для национальной безопасности, когда что-то идет не так.

Теперь DARPA, исследовательское подразделение вооруженных сил США, хочет понять конфликт кода и сообщества, который заставляет эти проекты с открытым исходным кодом работать, чтобы лучше понять риски, с которыми они сталкиваются. Цель состоит в том, чтобы иметь возможность эффективно распознавать злоумышленников и предотвращать их нарушение или повреждение критически важного открытого исходного кода, пока не стало слишком поздно.

Программа DARPA «SocialCyber» — это 18-месячный многомиллионный проект, который объединит социологию с последними технологическими достижениями в области искусственного интеллекта для картирования, понимания и защиты этих огромных сообществ с открытым исходным кодом и кода, который они создают. Оно отличается от большинства предыдущих исследований, поскольку сочетает в себе автоматизированный анализ как кода, так и социальных аспектов программного обеспечения с открытым исходным кодом.

«Экосистема с открытым исходным кодом — одно из величайших предприятий в истории человечества, — говорит Сергей Братусь, руководитель программы DARPA, стоящий за проектом.

«Теперь он вырос из энтузиастов в глобальную инициативу, формирующую основу глобальной инфраструктуры, самого Интернета, критически важных отраслей и критически важных систем практически повсюду», — говорит он. «Системы, которые управляют нашей промышленностью, электросетями, судоходством, транспортом».
Угрозы открытому исходному коду

Большая часть современной цивилизации сейчас зависит от постоянно расширяющегося корпуса открытого исходного кода, потому что он экономит деньги, привлекает таланты и упрощает работу.

Но хотя движение за открытый исходный код породило колоссальную экосистему, от которой мы все зависим, мы не до конца ее понимаем, утверждают такие эксперты, как Айтель. Существует бесчисленное множество программных проектов, миллионы строк кода, многочисленные списки рассылки и форумы, а также океан участников, чьи личности и мотивация часто неясны, что затрудняет их привлечение к ответственности.

Это может быть опасно. Например, в последние годы хакеры неоднократно незаметно внедряли вредоносный код в проекты с открытым исходным кодом. Бэкдоры могут долго оставаться незамеченными, и, в худшем случае, целые проекты были переданы злоумышленникам, которые пользуются доверием людей к сообществам с открытым исходным кодом и коду. Иногда происходят сбои или даже захваты тех самых социальных сетей, от которых зависят эти проекты. Отслеживание всего этого было в основном — хотя и не полностью — ручным усилием, что означает, что это не соответствует астрономическим масштабам проблемы.

Братус утверждает, что нам нужно машинное обучение, чтобы переваривать и понимать расширяющуюся вселенную кода — имея в виду полезные приемы, такие как автоматическое обнаружение уязвимостей, — а также инструменты для понимания сообщества людей, которые пишут, исправляют, реализуют этот код и влияют на него.

Конечной целью является обнаружение и противодействие любым вредоносным кампаниям, направленным на отправку ошибочного кода, запуск операций влияния, саботаж разработки или даже получение контроля над проектами с открытым исходным кодом.

Для этого исследователи будут использовать такие инструменты, как анализ настроений для анализа социальных взаимодействий в сообществах с открытым исходным кодом, таких как список рассылки ядра Linux, который должен помочь определить, кто настроен позитивно или конструктивно, а кто негативно и деструктивно.

Исследователи хотят получить представление о том, какие события и поведение могут разрушить или навредить сообществам с открытым исходным кодом, какие члены заслуживают доверия и существуют ли определенные группы, которые оправдывают повышенную бдительность. Эти ответы обязательно субъективны. Но прямо сейчас есть несколько способов найти их вообще.

Эксперты обеспокоены тем, что слепые пятна в отношении людей, использующих программное обеспечение с открытым исходным кодом, делают все здание готовым для потенциальных манипуляций и атак. Для Братуса главная угроза — это перспектива «ненадежного кода», управляющего критически важной инфраструктурой Америки, — ситуация, которая может преподнести неприятные сюрпризы.
Вопросы без ответов

Вот как работает программа SocialCyber. DARPA заключило контракты с несколькими командами, которых оно называет «исполнителями», в том числе с небольшими специализированными исследовательскими центрами кибербезопасности с глубокими техническими знаниями.

Одним из таких исполнителей является нью-йоркская компания Margin Research, которая собрала для этой задачи команду уважаемых исследователей.

«Существует острая необходимость относиться к сообществам и проектам с открытым исходным кодом с более высоким уровнем заботы и уважения», — сказала София д'Антуан, основатель фирмы. «Большая часть существующей инфраструктуры очень хрупкая, потому что она зависит от открытого исходного кода, который, как мы полагаем, всегда будет существовать, потому что он всегда был там. Это отказ от безоговорочного доверия, которое мы питаем к базам кода и программному обеспечению с открытым исходным кодом».

Margin Research сосредоточена на ядре Linux отчасти потому, что оно настолько большое и критичное, что успех здесь, в таком масштабе, означает, что вы можете добиться успеха где угодно. План состоит в том, чтобы проанализировать как код, так и сообщество, чтобы визуализировать и, наконец, понять всю экосистему.

Работа Margin показывает, кто и над какими частями проектов с открытым исходным кодом работает. Например, Huawei в настоящее время является крупнейшим поставщиком ядра Linux. Другой участник работает в Positive Technologies, российской фирме по кибербезопасности, которая, как и Huawei, попала под санкции правительства США, говорит Аитель. Margin также сопоставил код, написанный сотрудниками АНБ, многие из которых участвуют в различных проектах с открытым исходным кодом.

«Эта тема убивает меня, — говорит д’Антуан о стремлении лучше понять движение за открытый исходный код, — потому что, честно говоря, даже самые простые вещи кажутся столь новыми стольким важным людям. Правительство только сейчас осознало, что в нашей критической инфраструктуре работает код, который может быть написан в буквальном смысле лицами, находящимися под санкциями. Прямо сейчас."

Этот вид исследования также направлен на выявление недоинвестирования — критически важного программного обеспечения, которым полностью управляют один или два добровольца. Это более распространено, чем вы думаете, — настолько распространено, что одним из распространенных способов измерения риска в настоящее время в проектах программного обеспечения является «фактор автобуса»: не развалится ли весь этот проект, если хотя бы один человек попадет под автобус?

Хотя важность ядра Linux для мировых компьютерных систем может быть самой насущной проблемой для SocialCyber, оно также будет решать другие проекты с открытым исходным кодом. Некоторые исполнители сосредоточатся на таких проектах, как Python, язык программирования с открытым исходным кодом, используемый в огромном количестве проектов искусственного интеллекта и машинного обучения.

Есть надежда, что большее понимание облегчит предотвращение будущих катастроф, независимо от того, вызваны они злонамеренными действиями или нет.

«Практически куда бы вы ни посмотрели, вы найдете программное обеспечение с открытым исходным кодом, — говорит Братусь. — Даже когда вы смотрите на проприетарное программное обеспечение, недавнее исследование показало, что на 70% или более оно имеет открытый исходный код».

«Это критическая инфраструктурная проблема, — говорит Айтель. «У нас нет контроля над этим. Нам нужно взять себя в руки. Потенциальное воздействие заключается в том, что злоумышленники всегда будут иметь доступ к компьютерам Linux. Это включает в себя ваш телефон. Это так просто."
#2 | 15:03 26.07.2022 | Кому: Всем
Вот же злобные пидоры. Контроль над опенсорсом решили устроить.
Ну, в первую очередь, из всех опенсорс проектов они выкинут русских разрабов.
Далее будут проверять остальных на предмет их цвета кожи и сексуальных предпочтений. И довольны останутся, видимо, когда опенсорсы будут клепать негры и педерасты. Чем полностью этот самый опенсорс убъют к хуям.
Митра
Иисусе{4k} »
#3 | 15:08 26.07.2022 | Кому: Всем
Запретить опенсорс и всего делов!
#4 | 15:10 26.07.2022 | Кому: speaktr
> Контроль над опенсорсом решили устроить.

Опенсорс страшен. Ибо он есть общественный характер производства плюс общественный характер присвоения результатов труда. Ну, т.е., коммунизм. Это необходимо прекратить.
#5 | 15:14 26.07.2022 | Кому: speaktr
> Ну, в первую очередь, из всех опенсорс проектов они выкинут русских разрабов.
> Далее будут проверять остальных на предмет их цвета кожи и сексуальных предпочтений. И довольны останутся, видимо, когда опенсорсы будут клепать негры и педерасты. Чем полностью этот самый опенсорс убъют к хуям.

Опенсорс хорош тем, что его всегда можно форкнуть и развивать свой форк без обязательного участия негров и пидарасов.
#6 | 15:17 26.07.2022 | Кому: Всем
Военная разведка США, видимо, не знает про университет Беркли в Калифорнии, где под лицензией BSD выпускались юниксовые BSD дистрибутивы, которые можно использовать в коммерчиских целях закрыв исходный код. Например, в Apple для МакОси или АйОси, посылая нахуй юзеров, возмущающихся, почему им не дозволено то, что легко дозволено юзерам Андроидов.
#7 | 15:19 26.07.2022 | Кому: dse
> Опенсорс хорош тем, что его всегда можно форкнуть и развивать свой форк без обязательного участия негров и пидарасов.

Опенсорс хорош тем, что он опенсорс - всегда можно залезть в исходники и посмотреть, что же там происходит. Кто это написал - негры, пидарасы, азиаты, арийцы, совершенно перпендикулярно.
Митра
Иисусе{4k} »
#8 | 15:22 26.07.2022 | Кому: Brazigger
> Военная разведка США, видимо, не знает про университет Беркли в Калифорнии, где под лицензией BSD выпускались юниксовые BSD дистрибутивы, которые можно использовать в коммерчиских целях закрыв исходный код. Например, в Apple для МакОси или АйОси, посылая нахуй юзеров, возмущающихся, почему им не дозволено то, что легко дозволено юзерам Андроидов.

Почему выпускались? Фряха, например, живее всех живых!
#9 | 15:22 26.07.2022 | Кому: gl00m
> Опенсорс хорош тем, что он опенсорс - всегда можно залезть в исходники и посмотреть, что же там происходит. Кто это написал - негры, пидирасы, азиаты, арийцы, совершенно перпендикулярно.

Да-да, и форкнуть его, а потом не пустить в свой форк негров и пидарасов, независимо от цвета их кожи, пола, возраста, их половых предпочтений и того, на что они тратят своё свободное время.
#10 | 15:26 26.07.2022 | Кому: Митра
> Почему выпускались? Фряха, например, живее всех живых!

Но всюду пихают, почему-то, линух, а не фряху.
#11 | 15:29 26.07.2022 | Кому: Митра
> Почему выпускались? Фряха, например, живее всех живых!

Если я правильно помню, универ сейчас только отвечает за свою лицензию. А фряха жива, да.
#12 | 15:35 26.07.2022 | Кому: dse
> Опенсорс хорош тем, что его всегда можно форкнуть и развивать свой форк без обязательного участия негров и пидарасов.

Мне вообще не понятно, почему надо убивать опенсорс, когда у них для критичной инфраструктуры есть вполне себе RHEL и SLES.
Развивать свой форк хорошо, но на примере наших Astra и RedOS - это хуже, медленнее и очень дорого.
Митра
Иисусе{4k} »
#13 | 15:36 26.07.2022 | Кому: dse
> Но всюду пихают, почему-то, линух, а не фряху.

Наверное потому, что больше разрабов готовы развивать линукс. На фряхе до сих пор бяда с драйверами для гражданских устройств, но некоторые дистро уже стали почти так же удобны для простого смертного, как и линукс.
Митра
Иисусе{4k} »
#14 | 15:38 26.07.2022 | Кому: speaktr
> Развивать свой форк хорошо, но на примере наших Astra и RedOS - это хуже, медленнее и очень дорого.

Их развивают полтора человека.
#15 | 15:43 26.07.2022 | Кому: Митра
> На фряхе до сих пор бяда с драйверами для гражданских устройств, но некоторые дистро уже стали почти так же удобны для простого смертного, как и линукс.

Это же противоречие. Либо хорошо с драйверами (и удобно для большинства), либо жопа с драйверами и, тогда, пользуются полтора БыЭсДыЭмКопа.
#16 | 15:44 26.07.2022 | Кому: dse
> Но всюду пихают, почему-то, линух, а не фряху.

Линуксы издаются под своей лицензией GPL. Она позволяет разработчикам распространять свой софт за деньги, брать деньги за поддержку софта, но запрещает накладывать коммерческие ограничения на софт и исходный код - что крайне удобно для сообщества конечных пользователей. Например, именно поэтому под Андроид устройства написано сообществом дохера неплохих прошивок, а Айфончики простым смертным хер получится хотя бы зарутить.
#17 | 15:48 26.07.2022 | Кому: Митра
> Их развивают полтора человека.

Ну так. А каноническое ядро, и патчи этих самых майнтайнеров или как их там?
И смысл форка без серьёзной команды разрабов тогда в чем? Отстать от прогресса?
#18 | 16:01 26.07.2022 | Кому: speaktr
> Мне вообще не понятно, почему надо убивать опенсорс, когда у них для критичной инфраструктуры есть вполне себе RHEL и SLES.

Не надо убивать опенсорс. Там просто у американских топов очко сыграло, а вот у нас тут везде линух стоит, а ведь чуть ли не большая его часть сейчас написана китайцами и русскими, а мы тут с первыми воевать собираемся, а с другими уже воюем, чужими руками, правда, но они ж не совсем дураки, эти русские, понимают, кто им драку с хохолами заказал и оплачивает. А ну как китайцы с русскими возьмут и в это самое ядро нам втихую подгадят, а у нас тут от этого всё завянет и рухнет? Слышь, АНБ, нукабыстрабл*дь узнали кто у нас тут за что в ядре этого самого поганого линуха отвечает и куда нагадить может, чтобы мы, в свою очередь, прикинули, сколько нам баксов заказать ФРС напечатать на импортозамещение этих частей, бегомбл*, ещё вчера нах!!!
#19 | 16:05 26.07.2022 | Кому: speaktr
> И смысл форка без серьёзной команды разрабов тогда в чем? Отстать от прогресса?

Чтобы после проведённых специсследований на отсутствие закладок в код не напихали новых закладок.
#20 | 16:12 26.07.2022 | Кому: dse
> а вот у нас тут везде линух стоит, а ведь чуть ли не большая его часть сейчас написана китайцами и русскими

пруфы
#21 | 16:19 26.07.2022 | Кому: dse
> сколько нам баксов заказать ФРС напечатать на импортозамещение этих частей, бегомбл*, ещё вчера нах!!!

Так чем им RHEL и SLES не подходят? Даже у нас для КИ использовали исключительно их, а не убунты-шмубунты.
Или они на nginx`ы с haproxy беспокоятся?
Скорее всего это очередная чиновничья некомпетентность. Разобраться надо, какие дистры они для КИ используют, а потом выть, биться и хрипеть в ужасе.
#22 | 16:19 26.07.2022 | Кому: gl00m
> > а вот у нас тут везде линух стоит, а ведь чуть ли не большая его часть сейчас написана китайцами и русскими

> пруфы


В той же статье упоминается, что Хуавей является одним из крупнейших контрибьюторов в ведро линуха. Российская Positive Technologies тоже этим занимается, а вообще она занимается верификацией кода, в том числе, и с целью выявления закладок. А насчёт «чуть ли не большей части» было художественным преувеличением с моей стороны. Просто сам факт того, что иерархическая система принуждена использовать некую технологию, источник которой не полностью ею контролируется, вызывает у любой такой системы адские страдания.
#23 | 16:21 26.07.2022 | Кому: dse
> Чтобы после проведённых специсследований на отсутствие закладок в код не напихали новых закладок.

Ну перевел я тут пару контор на Astra Linux SE 1.7, это пиздецкий пиздец, хоть отдельного человека нанимай для общения с их деревянной подержкой.
На 70% запросов вообще ответ: это ограничения защищенной версии, не исправить никак, ждите релизов.
#24 | 16:22 26.07.2022 | Кому: speaktr
> Так чем им RHEL и SLES не подходят?

Видимо, тем, что невозможно взять и заставить всех производителей разного электронного барахла, в том числе и военного, использовать только ядро RHEL или SLES.
#25 | 16:23 26.07.2022 | Кому: dse
> А насчёт «чуть ли не большей части» было художественным преувеличением с моей стороны.

Ну, т.е. ты - пиздабол.
#26 | 16:24 26.07.2022 | Кому: speaktr
> Ну перевел я тут пару контор на Astra Linux SE 1.7, это пиздецкий пиздец, хоть отдельного человека нанимай для общения с их деревянной подержкой.
> На 70% запросов вообще ответ: это ограничения защищенной версии, не исправить никак, ждите релизов.

Ну и? Либо доверенная ОС, либо шашечки и удобство.
#27 | 16:24 26.07.2022 | Кому: gl00m
> > А насчёт «чуть ли не большей части» было художественным преувеличением с моей стороны.

> Ну, т.е. ты - пиздабол.


Тебе понятен смысл словосочетания «чуть ли не»?
Тебе понятно, от чьего имени мною была подана информация о том, что большую часть линуха якобы написАли китайцы и русские?
Как у тебя вообще с пониманием прочитанного?

P.S. aspav, перелогинься!!!
#28 | 16:33 26.07.2022 | Кому: dse
> Ну и? Либо доверенная ОС, либо шашечки и удобство.

Т.е. когда отваливается сканер штрих-кодов и невозможно сопровождать автоматизированный процесс производства с использованием MES-системы (которая детали по технологическим цепочкам отправляет на основании уникальных их номеров, забитых в наклеенном штрих коде) и встаёт всё производство на час-два - это шашечки и удобство?
Нет это пиздец и невозможность использования "доверенной ОС".
Или когда у диспетчера гарнитура отсыхает в процессе руления фурами по логистическому ценру, и образуется пробка из трёх десятков фур, это тоже не шашечки, а пиздец.
#29 | 16:35 26.07.2022 | Кому: speaktr
> Нет это пиздец и невозможность использования "доверенной ОС".

Основное назначение этой Астры — доверенность. Вот в ней она сильна как никто и никогда. А во всём остальном она не сильна, нет. Во всём остальном она — обычный линух.

> Т.е. когда отваливается сканер штрих-кодов …

> Или когда у диспетчера гарнитура отсыхает в процессе руления фурами по логистическому ценру, …

Это всё USB? Если USB, то на тебе таблетку для сброса контроллеров USB. Мопед не мой, я его нашёл где-то на просторах интернета.

Сброс контроллера USB 2.0
echo -n "0000:00:1a.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/ehci-pci/unbind && \
echo -n "0000:00:1a.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/ehci-pci/bind
echo -n "0000:00:1d.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/ehci-pci/unbind && \
echo -n "0000:00:1d.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/ehci-pci/bind
Сброс контроллера USB 3.0
echo -n "0000:03:00.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/xhci_hcd/unbind && \
echo -n "0000:03:00.0" | /usr/bin/sudo /usr/bin/tee /sys/bus/pci/drivers/xhci_hcd/bind
Митра
Иисусе{4k} »
#30 | 16:40 26.07.2022 | Кому: gl00m
> Это же противоречие. Либо хорошо с драйверами (и удобно для большинства), либо жопа с драйверами и, тогда, пользуются полтора БыЭсДыЭмКопа.

Удобство это про понятность. Впрочем у меня никаких проблем с драйверами не было.
#31 | 16:45 26.07.2022 | Кому: Всем
В обалденнии от прочитанных комментариев!

"Как хорошо, что все мы такие развитые!" (с) Венедикт Ерофеев, "Москва-Петушки"
Митра
Иисусе{4k} »
#32 | 16:45 26.07.2022 | Кому: speaktr
> И смысл форка без серьёзной команды разрабов тогда в чем? Отстать от прогресса?

Вот пусть и нанимают. Может я и спизданул про полтора человека на конкретно этих дистро. Но альт точно развивают полтора.
#33 | 16:54 26.07.2022 | Кому: dse
> Это всё USB? Если USB, то на тебе таблетку для сброса контроллеров USB. Мопед не мой, я его нашёл где-то на просторах интернета.

Не только про USB, еще и про другое. Это как яркие примеры в последних проектах в стадии внедрения.
Про таблетки мои админы, думаю, справились. Но мне, как архитектору и ГИПу интересно:
А эту таблетку надо каждый раз применять когда оператор отошел покакать и у него комп залочился? (а отвал гарнитуры - каждый раз)
А если у оператора нет прав на sudo? (а их нет)
А если электрик в 2 часа ночи выполнил регламентные работы по питанию в цеху, ИБП промышленного ПК не дотянул до конца регламента, локальной консоли у ПК нет, после старта производственной линии в 4 утра сраные сканеры не заработают без внешнего вмешательства сонного админа?

В общем нет. Такой футбол нам не нужен.
И слава ТНБ я настоял на периоде тестирования на вторичном оборудовании в отдельно взятых сегментах, ато же заказчик хотел прямо в продуктив и на всю инфраструктуру. Чтобы дешевле и быстрее.
#34 | 16:59 26.07.2022 | Кому: Митра
> Вот пусть и нанимают. Может я и спизданул про полтора человека на конкретно этих дистро. Но альт точно развивают полтора.

Нанимают. Тут в марте нам Астра в уши дула на очередной презентации, что прям так деньги попёрли, что они до конца года штат чуть ли не удесетерят.
Ждём.

[ картинка Ждуна ]
#35 | 17:30 26.07.2022 | Кому: speaktr
>
> Открытый исходный код работает на каждом компьютере на планете и обеспечивает работу критической инфраструктуры Америки. DARPA беспокоится о том, насколько ему можно доверять

АХАХАХАХАХАХАХАХХАХА. Ты видимо по несознанке попал пальцем в скандалище причем уже давнишний. Пидоры-линуксисты таки собрались и решили всех, кто пидоров не поддерживает выкинуть из сообщества.
#36 | 17:40 26.07.2022 | Кому: speaktr
> А эту таблетку надо каждый раз применять когда оператор отошел покакать и у него комп залочился? (а отвал гарнитуры - каждый раз)
> А если у оператора нет прав на sudo? (а их нет)

А зачем оператору права «на sudo»?

Во-первых, эту таблетку можно засунуть в скрипт и дать операторам право исполнения конкретно этого скрипта с таблеткой от имени root через sudo, можно даже без пароля.

Во-вторых, вместо того, чтобы заставлять что-то делать операторов, таблетку можно обернуть в скрипт-демон, который будет мониторить syslog на предмет появления в нём сообщений про отвал нужного устройства USB и сброса в этот момент контроллера USB. Скрипт настроить на запуск при старте системы.

Ну и в третьих, если отвал наступает после блокирования/разблокирования компа, так надо отключить компу вообще всё энергосбережение, потому что, скорее всего, пока оператор срал, комп просто заснул. И вот про последний способ можно наверняка прочитать что-нибудь в интернетах на тематических форумах, потому что проблема с отвалом разных устройств после выхода компьютера из режима энергосбережения относится к линуху вообще, и потому нечего ковырять ею мозг поддержке конкретно Астры.

> А если электрик в 2 часа ночи выполнил регламентные работы по питанию в цеху, ИБП промышленного ПК не дотянул до конца регламента, локальной консоли у ПК нет, после старта производственной линии в 4 утра сраные сканеры не заработают без внешнего вмешательства сонного админа?


Всё то же самое. Делается скрипт, который проверяет наличие и работоспособность критически важного оборудования. По логам dmesg, по наличию/отсутствию загружаемого модуля в ведре, с помощью тестов, не важно. В случае успеха скрипт завершается штатно, с кодом 0, в случае ошибки проверки берёт и сбрасывает контроллеры, к которым подключено это оборудование, снова проверяет его наличие, в случае успеха завершается с кодом 0, а в случае повторной неудачи обламывается с кодом ошибки, отличным от нуля. Затем на каждый экземпляр оборудования создаётся один сервис systemd, который тягает нужный скрипт с параметром, указывающим на конкретное устройство и настраивается, например, трёхкратный перезапуск каждого сервиса в случае ошибки. И тогда при старте системы она опросит наличие/отсутствие нужного оборудования, и если обнаружит его отсутствие, три раза даст по башке ответственным контроллерам. Этого должно хватить в большинстве случаев. Тут, главное, извернуться и не начать сбрасывать один и тот же контроллер разными сервисами. Для этого можно, например, использовать lock-файлы, и перед сбросом конкретного контроллера сначала проверять наличие соответствующего ему lock-файла, в случае отсутствия создавать такой lock-файл, сбрасывать контроллер и удалять lock-файл, а в случае наличия вставать и ждать некоторое время, пока он не исчезнет.

> В общем нет.


В общем, про linux way тебе мало что известно.

> Такой футбол нам не нужен.


Ну, не сделаешь ты — найдётся какой-нибудь более подкованный в линухе интегратор.

> И слава ТНБ я настоял на периоде тестирования на вторичном оборудовании в отдельно взятых сегментах, ато же заказчик хотел прямо в продуктив и на всю инфраструктуру. Чтобы дешевле и быстрее.


Не, ну предварительное тестирование — это правильно, да.
#37 | 18:12 26.07.2022 | Кому: gl00m
> План состоит в том, чтобы проанализировать как код

Миллионы человекочасов ушедшие на разработку и план все это проанализировать и понять?

Ну удачи
#38 | 18:30 26.07.2022 | Кому: dse
> Просто сам факт того, что иерархическая система принуждена использовать некую технологию, источник которой не полностью ею контролируется, вызывает у любой такой системы адские страдания.

А с эффективными менеджерами наоборот – "давайте отдадим всё на аутсорс". Человеки никогда не бывают довольны тем, что имеют. Нелогичные дурнопахнущие биологические приматы способны испортить всё, до чего дотянутся, а если вооружить человеков отвёртками и ломами, то даже целому инопланетному флоту непоздоровится.
#39 | 18:37 26.07.2022 | Кому: Всем
я такое ТЗ лет 12 назад читал еще. смеялись - дескать кегебешники ретрограды.
#40 | 18:38 26.07.2022 | Кому: Brazigger
> которые можно использовать в коммерчиских целях закрыв исходный код.

про это в предпоследем абзаце написано
#41 | 19:19 26.07.2022 | Кому: dse
> Во-первых, эту таблетку можно засунуть в скрипт и дать операторам право исполнения конкретно этого скрипта с таблеткой от имени root через sudo, можно даже без пароля.
>
> Во-вторых, вместо того, чтобы заставлять что-то делать операторов, таблетку можно обернуть в скрипт-демон, который будет мониторить syslog на предмет появления в нём сообщений про отвал нужного устройства USB и сброса в этот момент контроллера USB. Скрипт настроить на запуск при старте системы.

>

> Ну и в третьих, если отвал наступает после блокирования/разблокирования компа, так надо отключить компу вообще всё энергосбережение, потому что, скорее всего, пока оператор срал, комп просто заснул. И вот про последний способ можно наверняка прочитать что-нибудь в интернетах на тематических форумах, потому что проблема с отвалом разных устройств после выхода компьютера из режима энергосбережения относится к линуху вообще, и потому нечего ковырять ею мозг поддержке конкретно Астры.

В энергосбережение на очень многих системах Астра Линух не умеет. Поэтому отключается везде сразу же.
Блокировка компа через 5 минут - это требование ИБ и отключить это нельзя. В корп.среде так положено.
Запускать от root из под пользователя ничего нельзя - это требование ИБ. В корп.среде так положено.
Делать костыли в обход решений вендора нельзя - это требования корпоративной архитектуры. Или решение работает, или, если оно не работает, значит оно требует доработки со стороны вендора, а не со стороны заказчика. Это корпоративные стандарты внедрения.
Астра Линукс сейчас не отвечает требованиям корп. среды и поэтому мы ебём поддержку, за которую заплачены деньги. Если вендор не устраняет замечания на этапе апробации, то он меняется на другого.
Тут вмешиваются два фактора: требования об импортозамещении и желание заказчика показать Сами Знаете Кому в ближайшей перспективе супер-навороченный роботизированный производственно-логистический комплекс на полностью импортозамещенных решениях.
И, конечно же, на этапе MVP будут и костыли и ручное допиливание напильником. Но после показа MVP всё это опять уйдёт в девелоп и тестирование пока АстраЛинух не решит все проблемы, не выкатит нам пакет официальных патчей, не обеспечит поддержкой это решение. Так принято.

>

> > В общем нет.
>
> В общем, про linux way тебе мало что известно.

А тебе про стандарты внедрения ит-решений в крупных корпоративных средах. Уж извини.

>

> > Такой футбол нам не нужен.
>
> Ну, не сделаешь ты — найдётся какой-нибудь более подкованный в линухе интегратор.

Да я то сделал, работает. Просто так нельзя делать, особенно на объектах КИ.
Мы поставлены раком: требование минпромторга - отечественный линух. Требование ФСТЭК - Astra Linux SE. Мы поставлены раком, а раз нас поставили раком органы, мы поставим раком этот самый Астра Линух. Будем открывать бесчисленные тикеты, будем выставлять уточненные ФТТ.
Конечно, мы накостылим там решений чтобы Сами Знаете Кто посмотрел как всё свистит и огоньками переливается красиво. Но после его отъезда всё будет переделано на то, на чем оно нормально работает, пока компания AL не соизволит сделать лучше. Увы.
#42 | 19:24 26.07.2022 | Кому: Пальтоконь
> А с эффективными менеджерами наоборот – "давайте отдадим всё на аутсорс".

Ну да, а воевать и руки выкручивать как потом, если твой завтрашний враг написал софт, например, для твоей системы ПРО? Это ж ужас, жуть и катастрофа!

> Человеки никогда не бывают довольны тем, что имеют.


Это потому, что это то, что они имеют, у них вечно портится, прокисает, сгнивает и рушится, в общем, всем не хватает.

> дурнопахнущие биологические приматы способны испортить всё, до чего дотянутся, а если вооружить человеков отвёртками и ломами, то даже целому инопланетному флоту непоздоровится.


Да! Не суйся в нашу щёлочку, инопланетный флот!
#43 | 19:38 26.07.2022 | Кому: speaktr
> Делать костыли в обход решений вендора нельзя - это требования корпоративной архитектуры. Или решение работает, или, если оно не работает, значит оно требует доработки со стороны вендора, а не со стороны заказчика. Это корпоративные стандарты внедрения.

В чём проблема? Ты вендор? Нет. Ты заказчик? Тоже нет. Ты — интегратор! Поэтому делать костыли ты имеешь полное право! Тем более, никаких решений по автоподъёму упавших USB устройств вендор не предоставляет и потому никаких «в обход» тут не будет. Я понимаю, ядро бы падало в панику каждые полчаса, и ты написал патч, который это падение устраняет, а тут фигня какая-то.

> Но после показа MVP всё это опять уйдёт в девелоп и тестирование пока АстраЛинух не решит все проблемы, не выкатит нам пакет официальных патчей, не обеспечит поддержкой это решение.


Какие патчи-то? Это ж набор скриптов.

> Да я то сделал, работает. Просто так нельзя делать, особенно на объектах КИ.


Отлично! А теперь зашли в Астру свои автоподнимальные скрипты и прямым текстом обрисуй им ситуацию: если они хотят продавать свой линух, пускай включают их в дистрибутив. Не хотят — продать не смогут. И не тушуйся, действуй через верх.

> Но после его отъезда всё будет переделано на то, на чем оно нормально работает, …


Без сертификата ФСТЭК? Не взлетит.

> … пока компания AL не соизволит сделать лучше.


А она не сможет. Вряд ли у них найдётся специалист, способный перелопатить модули для USB и добиться их устойчивой работы.
#44 | 19:46 26.07.2022 | Кому: dse
> Ну да, а воевать и руки выкручивать как потом, если твой завтрашний враг написал софт, например, для твоей системы ПРО? Это ж ужас, жуть и катастрофа!

Логика и эффективные менеджеры? Оксюморон!
#45 | 19:58 26.07.2022 | Кому: Пальтоконь
> Логика и эффективные менеджеры? Оксюморон!

Но воевать и эффективно выкручивать руки уже не получится. PROFIT!!!
#46 | 20:04 26.07.2022 | Кому: dse
> В чём проблема? Ты вендор? Нет. Ты заказчик? Тоже нет. Ты — интегратор! Поэтому делать костыли ты имеешь полное право! Тем более, никаких решений по автоподъёму упавших USB устройств вендор не предоставляет и потому никаких «в обход» тут не будет. Я понимаю, ядро бы падало в панику каждые полчаса, и ты написал патч, который это падение устраняет, а тут фигня какая-то.

У крупных корпов решение интегратора проверяется внутренними и внешними экспертами. Внутренние сверяют их с НМД, внешние оценивают их соответствие best practices и работоспособности в целом.
Костыль - это не соответствует НМД. Если это костыль, значит я обязан заставить вендора этот костыль превратить в патч, указать в релизе патча, что этот патч решает вот эту проблему, продемонстрировать это всем крючкотворам от юристов до экспертов, и потом перевесить поддержку этого костыля на вендора.
Как то так это работает.


>

> > Но после показа MVP всё это опять уйдёт в девелоп и тестирование пока АстраЛинух не решит все проблемы, не выкатит нам пакет официальных патчей, не обеспечит поддержкой это решение.
>
> Какие патчи-то? Это ж набор скриптов.

Даже если это набор скриптов, то он должен быть прописан в доках вендора, как необходимый набор скриптов. Прям вот черным по белому в бумагах. И если ты позвонишь в поддержку AstraLinux и скажешь, что у тебя демон get_usb_back_again не работает - поддержка вендора должна будет тебе рассказать, как это решить на 1-й, 2-й и 3-й линиях.
Понимаешь? Покупается у Astra Linux техподдержка, в случае поломки скриптов ей звонить будут, а не мне.
Если этот набор скриптов требуется для работы ПО, которое накатано на ОС, то то же самое должно быть прописано в документации к ПО и так же должна осуществляться поддержка этого решения на 1,2,3 ЛП но уже со стороны разработчика ПО.
Я, как ГИП и архитектор, считаю, что проблема именно в ОС и ебу именно Астру, а не вендора ПО. Так как до этого на убунте в тестах на стендах у них всё работало, а теперь - нет.

>

> > Да я то сделал, работает. Просто так нельзя делать, особенно на объектах КИ.
>
> Отлично! А теперь зашли в Астру свои автоподнимальные скрипты и прямым текстом обрисуй им ситуацию: если они хотят продавать свой линух, пускай включают их в дистрибутив. Не хотят — продать не смогут. И не тушуйся, действуй через верх.

Заслано. Обрисовано. Работа идёт. Обещают, но сроков не дают. А у меня сроки на проект конкретные.
Я просто констатирую тут факт, что форкнутая Астра работает хуже, чем другие развивающиеся опенсорсные ветки. Начался то весь разговор с форков и их разрабов.
#47 | 20:22 26.07.2022 | Кому: speaktr
> Я, как ГИП и архитектор, считаю, что проблема именно в ОС и ебу именно Астру, а не вендора ПО. Так как до этого на убунте в тестах на стендах у них всё работало, а теперь - нет.

А как у заказчика на его площадке с наводками на кабели? Что с заземлением? Почему бы не накатить на стенд астру вместо убунты, чтобы убедиться в том, что глюки появляются именно на астре? И, кстати, разве астру форкнули не из дебиана? А то, вроде бы, не все патчи к убунтовским ядрам доходят до дебиановских.

> Я просто констатирую тут факт, что форкнутая Астра работает хуже, чем другие развивающиеся опенсорсные ветки.


В астру вкорячили слишком много безопасности, она может работать «хуже» именно из-за этого. Может, там какой-нибудь модуль хочет что-то сделать в случае отвала оборудования, но вот криво настроенная принудительная система контроля доступа ему этого сделать не даёт.

> Начался то весь разговор с форков и их разрабов.


Разговор начался с того, что если в основной ветке какого-то опенсорсного проекта началось нездоровое брожение, никто не в силах помешать форкнуть проект и развивать его самостоятельно. Само собой, успешность форка будет целиком и полностью зависеть только от того, чья команда разработчиков окажется более грамотной и подкованной.
#48 | 20:48 26.07.2022 | Кому: dse
> > Я, как ГИП и архитектор, считаю, что проблема именно в ОС и ебу именно Астру, а не вендора ПО. Так как до этого на убунте в тестах на стендах у них всё работало, а теперь - нет.
>
> А как у заказчика на его площадке с наводками на кабели? Что с заземлением? Почему бы не накатить на стенд астру вместо убунты, чтобы убедиться в том, что глюки появляются именно на астре? И, кстати, разве астру форкнули не из дебиана? А то, вроде бы, не все патчи к убунтовским ядрам доходят до дебиановских.

Стенд делался год назад. Заказчику хотел убунту, он её получил. У него вообще вся инфра на ней, и это не я тут руку приложил.
А теперь вот так. Всё меняется, как обычно.

>

> > Я просто констатирую тут факт, что форкнутая Астра работает хуже, чем другие развивающиеся опенсорсные ветки.
>
> В астру вкорячили слишком много безопасности, она может работать «хуже» именно из-за этого. Может, там какой-нибудь модуль хочет что-то сделать в случае отвала оборудования, но вот криво настроенная принудительная система контроля доступа ему этого сделать не даёт.

Да нет. Вся причина в том, что Астра не умеет нормально с устройствами работать, если у пользователя права чуть ли не гостя.
По какой-то неведомой причине они даже и не предполагали, что пользователю могут быть зарезаны все без исключения права, кроме запуска браузера и evolution. И что один раз настроенное под пользователем устройство может отвалиться и для настройки потребуются танцы с бубном.
Вот мой ноутбук при загрузке с виндой всегда помнит параметры монитора у меня на даче, хоть я там и полгода не бываю, когда я его подключаю на даче к монитору, он выставляет частоту и разрешение того монитора без проблем.
А при загрузке с Astra CE 2.12 я каждый раз при подключении монитора выставляю заново частоту и разрешение, иначе пиздец. Ну что это?

>

> > Начался то весь разговор с форков и их разрабов.
>
> Разговор начался с того, что если в основной ветке какого-то опенсорсного проекта началось нездоровое брожение, никто не в силах помешать форкнуть проект и развивать его самостоятельно. Само собой, успешность форка будет целиком и полностью зависеть только от того, чья команда разработчиков окажется более грамотной и подкованной.

В итоге ставлю Астре тройку пока. Может даже с минусом за то, что у них ядро в SE младше ядра в CE аж на 4 года. (так мне это сказал админ мой, не знаю, правда ли, проверять лезть лень).
#49 | 22:04 26.07.2022 | Кому: speaktr
> Да нет. Вся причина в том, что Астра не умеет нормально с устройствами работать, если у пользователя права чуть ли не гостя.

Странно, насколько мне известно, в линухе от уровня доступа консольного пользователя в работе с устройствами ничего не зависит.

> А при загрузке с Astra CE 2.12 я каждый раз при подключении монитора выставляю заново частоту и разрешение, иначе пиздец. Ну что это?


1. Отсутствие/нарушение работоспособности DDC.
2. Отсутствие прав доступа на запись в файл, в котором сохраняются настройки монитора.

> Может даже с минусом за то, что у них ядро в SE младше ядра в CE аж на 4 года.


Да, в SE 1.7 ведро версии 5.4, а в последнем, прошлогоднем релизе CE 2.12 ведро проапгрейдили до 5.10. Но не думаю, что это так уж критично.
cp866
интеллектуал »
#50 | 03:55 27.07.2022 | Кому: Митра
> Но альт точно развивают полтора

Не соглашусь. Когда мне последний раз пришлось обновлять комп, альт один из немногих туда смог нормально установиться. И только у него была нормальная версия remmina для доступа по rdp.
Войдите или зарегистрируйтесь чтобы писать комментарии.