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

> Ну, в первую очередь, из всех опенсорс проектов они выкинут русских разрабов.
> Далее будут проверять остальных на предмет их цвета кожи и сексуальных предпочтений. И довольны останутся, видимо, когда опенсорсы будут клепать негры и педерасты. Чем полностью этот самый опенсорс убъют к хуям.

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

> Почему выпускались? Фряха, например, живее всех живых!

Но всюду пихают, почему-то, линух, а не фряху.

> И смысл форка без серьёзной команды разрабов тогда в чем? Отстать от прогресса?

Чтобы после проведённых специсследований на отсутствие закладок в код не напихали новых закладок.

> Так чем им RHEL и SLES не подходят?

Видимо, тем, что невозможно взять и заставить всех производителей разного электронного барахла, в том числе и военного, использовать только ядро RHEL или SLES.

> > А насчёт «чуть ли не большей части» было художественным преувеличением с моей стороны.

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

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

P.S. aspav, перелогинься!!!

> А эту таблетку надо каждый раз применять когда оператор отошел покакать и у него комп залочился? (а отвал гарнитуры - каждый раз)
> А если у оператора нет прав на sudo? (а их нет)

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

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

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

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

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

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

> В общем нет.

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

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

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

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

Не, ну предварительное тестирование — это правильно, да.

> Делать костыли в обход решений вендора нельзя - это требования корпоративной архитектуры. Или решение работает, или, если оно не работает, значит оно требует доработки со стороны вендора, а не со стороны заказчика. Это корпоративные стандарты внедрения.

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

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

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

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

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

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

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

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

А она не сможет. Вряд ли у них найдётся специалист, способный перелопатить модули для USB и добиться их устойчивой работы.

> Я, как ГИП и архитектор, считаю, что проблема именно в ОС и ебу именно Астру, а не вендора ПО. Так как до этого на убунте в тестах на стендах у них всё работало, а теперь - нет.

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

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

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

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

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

> С пользовательскими устройствами зависит как то.

Не должно от слова «совсем». udev работает совершенно независимо от того, залогинен кто-нибудь в систему, или нет.

> И это один из основных вопросов к ТП: почему так?

Скорее всего, потому что консольный пользователь не включён в группу доступа к конкретному устроийству, которую файлу этого устройства выдал udev. Ну а тут нет ножек — нет мультиков.

> Как оно "из коробки" сразу нарушилось? Такое только им удалось.

Regression. Взяли, и сломали что-то, причём не в астре, а прямо в самом дебиане, откуда был взят соответствующий пакет.

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

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

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

Странные люди. Объясни им, что «новое» относится не линуху вообще, а к конкретному дистрибутиву.