Всё, что продаётся на рынке - товар. Но в товаре может быть продукт, а может быть покрытая толстым слоем костылей раскривушка поверх oVirt за неадекватно много денег.
Меня печалит не то, что оно продаётся, и не то, что продаётся за ценник, который выбить из руководителя очень многих контор не реально (а некоторые просто не засунут в бюджет это нечто физически). Меня печалит, что для большинства это всё просто товар, на который есть спрос и перегретый рынок, и очень мало народу пытаются сделать продукт.
Тот же PostgresPro стоит бешеных денег. Может любители решений Oracle не согласятся, но большинство простого народу ценник может сильно травмировать. Но при этом цена вызывает только недоумение, а не как в отношении других решений на базе PostgreSQL тихую ярость. Почему? Потому что благодаря именно этим бешеным бабкам, по PostgreSQL самая божественная документация. Она полностью переведена на русский и находится в синхроне с официалом. Учебные материалы, включая видеокурсы, когда не нужно бегать кругами с поиском нужного, всё в одном месте собрано. Не нужно качать с торрентов спираченное со специалиста, оно тупо в Ютубе лежит. Ну и знакомые люди, которые лично причастны ко многим приятным вещам. Понятно, за что деньги, и есть шанс, что оно не растворится в закате, когда страсти поутихнут и рынок подохладеет. И вот таких примеров, к сожалению мало.
На рынке каждый хочет заработать, но кто-то при этом работать не хочет, от слова "совсем"...
Основной проблемой отечественного софта является то, что по большей части (по крайней мере в верхней части списка самых продаваемых решений) он создан под задачу - импортозамещение. То есть, мимикрирует под популярные решения, пытаясь забрать себе этот рынок. При этом проработки у данных заместителей минимальное количество. Фокус продукта в прибыли, а не в решении некоторого класса задач. Есть исключения, но их мало. К сожалению в создавшейся ситуации, когда нужно было просто собраться, разобрать задачи, возникшие после ухода вендоров с рынка, и покрыть выпавшие РЕШЕНИЯ, народ кинулся занимать освободившийся рынок, пытаясь присвоить себе ПРИБЫЛИ. Ушли Оракл и MS SQL - даёшь PostgreSQL-ей мешок! Причём большая часть решений - стабилизированная ванила с наложенными патчами с обмазанная стандартными решениям + свой выстраданный web-интерфейс (пожалуй единственное, что на 100% разработано у данных вендоров, если не считать что они построены на имеющихся фреймворках и используют давно и прекрасно работающий функционал). И этот самый web-интерфейс далеко не факт что решает Ваши задачи. Он решает задачи которые придумали себе эти вендоры, и местами не очень решает. В результате рынок рвут на части, существенная часть функционала в секторах с меньшей маржёй не закрыты вовсе, а остальная часть бо большому гамбургскому счёту требует стабилизации, а цену оно имеет как у больших (памятуя об опыте первых участников рынка импортозамещения)... То есть ради сиюминутной коммерческой выгоды был продолбан неплохой шанс сделать по человечески... У нас не такой большой рынок, но зато 100500 инфраструктурных решений по ОС, виртуализации и прочему. Разработка приклада - АД кромешный, стабильность данных платформ условна, чудоковатость решения оперативных ежедневных задач иногда зашкаливает... Остальные проблемы отечественного софта вытекают отсюда.
Горе от ума. Ленивые люди берут базовый тариф на лоукостере, там где почти нет диска, почти нет процессора, но есть безлимитная полоса в 100 Мбит/с и поднимают там OpenVPN. Остальное описано в книжках по сетям и NAT. В таком конфиге оно может даже быть вполне полезным. DDoS-ы не переживёт, а для добросовестного использования вполне хватит.
Там можно даже сайтики почти нормально хостить, выбросив на этот недохост на VDS провайдере nginx, а всё мясо развернув на узле дома....
Но нет, нужен телега-бот написанный на С++ который по curl-у с другого ресурса запрашивает IP и отдаёт его в телеге. Вся надежда на телегу, сайтик с определением IP и вот это вот всё....
Да, для других извращенцев, которым тоже простые решения как серпом по телу: как-то делал на bash раскривушку. Она получала IP из переменной окружения и регистрировала его на ns сервере. В том случае был BIND, но собрать такое на NSD нет проблем, даже проще. А дальше прописываем этот сервер 3-м уровнем (на второй нужна пара серверов), и конектимся по SSH. Всё нужное openssh положит в переменные окружения, останется только прописать команду на подключение по определённому ключу (в авторизованные ssh-ключ можно прописывать команды, стартующие при использовании этих ключей), откуда эта груда костылей получает имя (его прописываем в эту самую команду для ключа), регистрирует IP с которого проведено подключение и завершает сеанс. Конектится можно хоть раз в минуту, NSD переживёт.... Вот и халявный свой DynDNS с блек-джеком и всем, что развёртывающий вздумает на него навесить.... Можно даже узлы c NS и терминальный для соединений разнести по разным виртуалкам или контейнерам, если очень нужно.... У меня загнулось на этапе прототипа. Тесты прошло и было похерено, как рабочий концепт на случай атомной войны, поскольку решение с калиткой (точкой входа на дешёвой VDS) имеет больше перспектив и более управляемо и предсказуемо.
Упоминаемый Национальный Удостоверяющий Центр - это коммерческая шаражкина контора, созданная Гарантом на фоне роста рынка цифровых подписей и прочих ЭДО, о чём можно легко посмотреть по ИНН. Он такой же "национальный" как nic.ru, который должен быть основным регистратором для зоны RU (исходя из имени, и по началу даже был), но что-то пошло не так, рыночек порешал по-видимому... И эта контора уже не очень, даже как коммерческий регистратор. То что у нас бардак в наименованиях скажем спасибо либерализЬму и прочем свободам идиотизЬмов, когда за самым пафосным именем, скрывается самое ущербно ООО. Народ из министерства просто не заморачивался с названием. И прав по своему. При проблемах можно просто прибить АО....
Министерство - уполномоченное ведомство. Оно создало НУЦ - уполномоченный центр. В чем проблема? В том что НУЦ относится к министерству а не выделено в отдельную юр. морду.... Ну здесь на любителя, по мне, то что названо национальным, должно контролироваться государством полностью, иначе - это введение в заблуждение.
То что через ведомство попилили бабла, так не только в нём. У нас тут ГосОблако имени Ростелекома взлетает уже лет 10 на ежегодной основе. И ничего, пока не летит, в прошлом году снова поднимался вопрос об ГосОблаке.... Почему попиленный бюджет в прошлом должен стать препятствием к созданию НУЦ, не до конца понятно.
Вы можете входить из любого браузера на офф. порталы. Они просто должны доверять НУЦ. Пока доверяют из коробки двое. Остальные не хотят. Но есть сертификат, который им можно скормить. Если Браузер не принимает сертификат, то это проблема браузера а не УЦ его выпустившего...
И да по тому, что в сфере ГосИТ у нас не просто бардак, а пылающий звёздный бардачело даже не спорю. В такие непроходимые джунгли из поделий, недопродуктов и процего, без всякого намёка на стройную структуру, всё это довести прямо талант нужен. Наши люди талантливы... Но конкретно по НУЦ претензий нет, главное чтобы это был спец. комплекс а не роль Центра сертификации Microsoft на компе одного из админов в Министерстве.
Возможно это утверждение сделано на основе психологической травмы, нанесённой эксплуатацией этого чуда. Я верю, что знаючи эту тварь дотошно, её можно сделать адекватной (у людей то как-то выходит...). Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы... это само собой напрашивается на проблемы.... Вот что мешало эти долбаные объекты инициализировать json файлами???...
А так, при общей популярности темы сайтостроительства и общей уверенности, что выучив PHP можно почти сразу разбогатеть на непыльной работе (ну по крайней мере в горизонте прошлых лет), в отрасли полно людей склонных использовать инструменты криво, опасно и даже преступно... Вот только в сочетании с Bitrix это становится просто идеальным штормом...
Эта дрянь должна писать в себя, чтобы жить. Писать она может даже то, что потом она будет исполнять. И МАЛЕЙШЕЕ отверстие, позволяющее выполнить свой (атакующего) код в контексте сервера (а судя по тому, какая круговерть творится вокруг движка, пока он творит свою чёрную магию, этих отверстий там порядком), либо малейшая дрянь которую можно положить через механизмы движка на сервер а затем исполнить php-интерпретатором, даёт полный контроль над всем движком. И червяк начинает методично разбрасывать обфусцированные сниппеты по всем index.php и прочему бардаку, что обильно разбросан по всему движку, на всю, местами неадекватную, глубину вложенности. Я как администратор не могу с этим справится, в Bitrix нет такого каталога, где лежит код, и куда пользователь (лицо взаимодействующее с сайтом даже через админку) писать не должен, и каталога, где лежит переданное от клиента, и от которого должен держаться подальше php-fpm (ну по крайней мере не исполнять от туда скрипты). И это бесит! Я не в силах понять, что творится при создании контента. Простыни инициализируемых объектов мало чем сами отличаются от вредоносов. Ну нет там смысла для взгляда человеческого и нельзя в среднем объять мозгом простынь на 4-10 скролов с перечислением каких-то инициализируемых свойствах убер объекта...
Итого:
Битрикс делает невозможной пассивную защиту, поскольку нельзя реализовать классическую схему W^X (то куда можно записать не должно исполняться)
Он не позволяет легко понять, что на ресурсе происходит что-то не то. Оно штатно разбрасывает неожиданные php файлы в непостижимые места, многие из которых плохо выделяются на фоне вредоносов...
Эта штука умудряется заразиться кажется даже быстрее чем Windows XP с SP1 выставленная голой жопой в интернет. При этом если XP от интернета можно держать на расстоянии, то с Bitrix это не выйдет совсем...
И при всех своих заслугах оно стоит дичайших денег.....
Сталкивался с Bitrix несколько раз в качестве специалиста по "заставить это как-то работать" (aka эксплуатация на максималках). Все разы меня терзал странный вопрос: как это чудо света (а это без сомнения чудо света, ибо совершенно не постижимо как при наличии уже понимания, что нужно разделять в сущности представление, действия над ней её данные, всего накопленного опыта CMS можно было породить ЭТО) достигло своих высот.
Для меня как эксплуатации, данная CMS является головной болью. Ей нельзя запретить писать в собственные директории на сервере. То есть, без специальных извращений с несколькими экземплярами PHP под разными пользователями, один из которых под публичную часть, второй под админку, эта штука не способна защитить себя от различных червей. Мне приходилось иметь дело с дырявой Joomla. И манипуляция с правами пользователя PHP на файлы и директории давала достаточно защиты от червей. Да нужно обновляться но сидя в конторе в одно лицо, без умных (ну или просто) семпаев, задача "не ушатай" становится более приоритетной... Такой фокус с Bitrix не прокатит, там нужно иметь 4-й дан в эксплуатации PHP, чтобы защитить это чудо без постоянных обновлений. При чистой эксплуатации, когда все изменения в сайте производит разработка, либо заказчик, а я просто держу это на плаву, единственным решением задачи защиты стало обернуть всё в меркуриал репозитарий, выполнения с некоторой периодичностью status и если там что-то появилось отправку diff на почту, для дальнейшего выяснения, кто-куда-зачем.... Даже, когда разработки утверждала, что оно обновлено, раз в неделю diff давал 100500 файлов загаженных сложно вычленяемыми на фоне остального говнокода сниппетами заразы...
Работа сабжа со стилями вызывает трепет. Если не знать того единственного правильного способа (который мне лично не известен), оно порождает миллион css файлов, и весь этот миллион тянется пользователем при запросе страницы. И эти файлы однотипны и отличаются только штампов времени в конце. Понять откуда это всё без вдумчивого изучения решительно нельзя...
Поменять что-то на странице, если это не предусмотрено разработчиком модуля, вёрстки и прочего, даже при наличии доступа к коду, практически не реально. Понять куда там запрягают коней без специальных курсов решительно нельзя. В админке найти нужно тебе опцию - квест повышенной сложности. Если оно падает, то никто кроме поднимавшего не сможет вернуть всё взад (ну или разворачивание резервной копии с потерей всего, что сделано после её создания). Если человек, кто разворачивал, делал это методом тыка - ничто не поможет кроме бекапа....
Если кто-то сможет объяснить почему оно ТАК популярно, нижайше прошу просветить, иначе у меня создаётся впечатление о клиническом садомазохизме всей отрасли российского сайтоделательства. Нет, как коммерческий продукт, для создателей этой CMS - это просто шедевр: эксплуатация будет платить за лицензию, потому что ей нужны будут обновы. Там есть место облачным сервисам, поскольку НУЖНО регулярное резервное копирование и не помешает CDN, особенно если это чудо развёрнуто на shared-хостинге с драконовскими лимитами по диску. Но блин, что это кроме откатов даёт эксплуатации не ясно. Даже знакомый разработчик сайтов мне не смог внятно ответить о плюсах "продукта", но живописал великим и могучим своё к нему отношение....
Учиться работать с БД в рамках языка программирования с того, чтобы учиться работать с БД в целом, ИМХО плохая затея. Ибо человек такое создание, что склонно терять лес за деревьями, а реляционная логика, понятие множеств и действий над ними, на которых она строится и общая логика работы СУБД даст достаточно деревьев, чтобы за ними напрочь, месяцев на 6 минимум, полностью потерять GO из виду =))))) Эту часть квеста лучше проходить заранее....
А в рамках топика, о ALL, а никто не порекомендует обновляемый, адекватный, online справочник по синтаксису и стандартной библиотеке Go на русскомязыке.
Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
Считать максимум рабочих процессов от памяти - способ отстрелить себе пол организма под нагрузкой. Конкурирующие за вычислительный ресурс рабочие процессы будут друг-друга сильно тормозить. Такой фокус можно использовать только при том, что большая часть этих процессов будет спасть в ожидании данных с БД, и то до того момента как от DBA не прилетит не иллюзорная звездюлина, поскольку ему тоже вряд ли досталась SUN Niagara и количество исполнительных каналов процессоров у него на сервер БД также ограничено, а памяти и прочего процессы СУБД жрут не в пример больше чем php-fpm даже при достаточно кривом php коде...
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
То что браузеры исполняют их в песочнице не помешало эксплуатировать спектру с JS. Поэтому я и говорю, что времена, когда мы все были в домике и глаз хватало, чтобы быть в безопасности давно прошли.
Если скрипты и проникнут на ваш компьютер, то скорей через эти самые антивирусы, которые разрабатываются мелкими компаниями и безопасность которых никто толком не проверяет, в отличие от браузеров.
Я дико извиняюсь, но антивирусные компании очень даже немаленькие, а мантру о том что множество глаз БДИТЕЛЬНО следят мы проходили во времена heartbleed. Не помогло OpenSSL, за которым следили параноики, почему должно помочь браузерам.
А нода здесь как самый яркий пример того, как обычная человеческая лень программеров увеличивает поверхность атаки на порядок, а бардак в их модной инфраструктуре вполне может спровоцировать получение JS-зловреда с уважаемого сайта, и уберечься от этой дряни, хотя бы спустя некоторое время, сможет помочь только антивирусник.
И да, я читаю ежедневный отчёт от Kaspersky Cecurity Center по моей маленькой непримечательной сетке, и крайне счастлив, что вся эта дрянь из отчёта осталась за пределами сетки.
Все системы антивирусной защиты делятся на дырявое решето и имеющие функцию подмены сертификата. Как вы предлагаете проверять js-дрянь, идущую по SSL каналу. Кончилось то время когда на Web-е лежали файлики, и если не позволять им запускаться - то всё будет зашибись. Сейчас с помощью js Вас могут завязать в узел и сложить из Вас оригами почти не приходя в сознание с использованием только штатных API. А если к этому добавить не контролируемое вовсе мракобесие с node.js и просто разбросанными по интернету файлы с кусками фреймворков, в время от времени находят разное.
Вообще есть прекрасный способ сделать так, чтобы за пользователем не следили и он был в безопасности. Нужно по сайтикам лазить ка Столман. Где-то на хабре вроде была статья с его рецептом успеха. А в остальное время, приходится использовать проверку SSL-трафика, и внимательно следить за исключением трафика всяких банк-клиентов, которые это местами страсть как не любят.
Я правильно понимаю, что пересменка происходит на АТП, куда машина гонится с РЦ уже гружённая на следующий рейс? Если да, то не до конца понятно:
Почему пересменку нельзя сделать на РЦ, доставив туда новых водителей попутно другими машинами, либо просто установив точку рандеву на РЦ, перенаправив туда служебный вахты с водителями, которые должны начать рейс в ближайшее время.
Зачем гнать на АТП машину, когда большую часть проверок можно провести по окончании рейса, а на РЦ дежурный механик просто проведёт общий осмотр машины перед погрузкой и после неё на предмет базовых технических проблем. В конце концов машина должна уйти с АТП здоровой, и маловероятно, что по дороге у неё произойдёт что-то, что не сможет увидеть техник напару с водителем, закреплённым за машиной. Явно сейчас его там нет, но можно отправлять народ с АТП по графику на дежурство на РЦ на отдых за "особые заслуги". Тогда не нужно печатать документ до рейса, рейс начнёт уже сменщик и распечатает себе документы. Вся задумка с QR исключительно из-за того, что водители явно исполняют обязанности и экспедиторов и отвечают за груз, поэтому необходимо следить за погрузкой. Если снять с водителей такую ответственность через упаковку товара в контейнеры (на колёсиках) и оставить за водителями только ответственность доставить соответствующее количество контейнеров на соответствующие точки, а разборки по загруженной номенклатуре предоставить сборщикам и контролёрам на РЦ, принимающими специалистами на точках, обеспечив надёжные средства доказательства невмешательства водителя в груз, то водителям вообще должно быть без разницы: один доставил машину на РЦ и поставил на погрузку, тем самым завершив смену, второй просто принял гружёную машину вцелом, проверив что все места на месте, и пошёл распечатывать на неё документы, по которым после уже начинает свой рейс.
Просто мне кажется, что описанный в статье процесс слишком наворочен и разухабист. Очень похоже, что героически решили проблемы, возникшие из-за того, что "всегда так делали и вы задолбётесь пересогласовывать бизнес процессы целиком, но можно согласовать несколько костылей к ним, и обойтись малой кровью и не сдохнуть в совещаниях с топами сразу нескольких неповоротливых дивизионов, где каждый будет отстаивать незыблемость своих бизнес процессов, ибо если их колыхнуть, то сразу 100500 тысячмилионов долларов убытков ежеминутно" (с) Очень хочется верить что хоть у вас нету такой фигни....
Так и не понял, зачем такие сложности. Машина и водитель, вообще ИМХО разные сущности. Водитель вернул машину в РЦ (пересечение ворот), тем самым закрыл свой рейс, отметилось время. После этого машина обслуживается и попадает в планирование на рейсы в очереди. При необходимости, если в смене водителя осталось время, он её подаёт под загрузку. Загрузка происходит по планшетам, и склад формирует фактическую загрузку, и формируются документы в электронном виде. После загрузки уже тот водитель, который повезёт груз подходит к принтеру, которых может стоять батарея, сканирует QR из приложения на планшете/телефоне, ему отдаются накладные на все точки, которые уже по факту визируются и он едет. То есть машину рассматриваем отдельно, а водителя на неё планируем отдельно. А не вот этот человекомашинный комплекс с переходным состоянием "у первого водителя смены не хватит на следующий рейс, поэтому пусть он загрузит, а второй разгружать будет". Здесь есть вопросы с экспедицией, но если рассматривать сборку тележки (та хрень на колёсиках, которая в сетях и является местом груза) отдельно, то есть привязывать комплектовщика к этой тележке, накладывая на него ответственность за сборку и учёт собранного, и качественно опечатывать, на ценный груз используя прочные чехлы, на малоценку использовать продуманные механизмы опечатывания и фотоотчёты, может получится даже несколько гармоничней.
Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...
Всё, что продаётся на рынке - товар. Но в товаре может быть продукт, а может быть покрытая толстым слоем костылей раскривушка поверх oVirt за неадекватно много денег.
Меня печалит не то, что оно продаётся, и не то, что продаётся за ценник, который выбить из руководителя очень многих контор не реально (а некоторые просто не засунут в бюджет это нечто физически). Меня печалит, что для большинства это всё просто товар, на который есть спрос и перегретый рынок, и очень мало народу пытаются сделать продукт.
Тот же PostgresPro стоит бешеных денег. Может любители решений Oracle не согласятся, но большинство простого народу ценник может сильно травмировать. Но при этом цена вызывает только недоумение, а не как в отношении других решений на базе PostgreSQL тихую ярость. Почему? Потому что благодаря именно этим бешеным бабкам, по PostgreSQL самая божественная документация. Она полностью переведена на русский и находится в синхроне с официалом. Учебные материалы, включая видеокурсы, когда не нужно бегать кругами с поиском нужного, всё в одном месте собрано. Не нужно качать с торрентов спираченное со специалиста, оно тупо в Ютубе лежит. Ну и знакомые люди, которые лично причастны ко многим приятным вещам. Понятно, за что деньги, и есть шанс, что оно не растворится в закате, когда страсти поутихнут и рынок подохладеет. И вот таких примеров, к сожалению мало.
На рынке каждый хочет заработать, но кто-то при этом работать не хочет, от слова "совсем"...
Основной проблемой отечественного софта является то, что по большей части (по крайней мере в верхней части списка самых продаваемых решений) он создан под задачу - импортозамещение. То есть, мимикрирует под популярные решения, пытаясь забрать себе этот рынок. При этом проработки у данных заместителей минимальное количество. Фокус продукта в прибыли, а не в решении некоторого класса задач. Есть исключения, но их мало. К сожалению в создавшейся ситуации, когда нужно было просто собраться, разобрать задачи, возникшие после ухода вендоров с рынка, и покрыть выпавшие РЕШЕНИЯ, народ кинулся занимать освободившийся рынок, пытаясь присвоить себе ПРИБЫЛИ. Ушли Оракл и MS SQL - даёшь PostgreSQL-ей мешок! Причём большая часть решений - стабилизированная ванила с наложенными патчами с обмазанная стандартными решениям + свой выстраданный web-интерфейс (пожалуй единственное, что на 100% разработано у данных вендоров, если не считать что они построены на имеющихся фреймворках и используют давно и прекрасно работающий функционал). И этот самый web-интерфейс далеко не факт что решает Ваши задачи. Он решает задачи которые придумали себе эти вендоры, и местами не очень решает. В результате рынок рвут на части, существенная часть функционала в секторах с меньшей маржёй не закрыты вовсе, а остальная часть бо большому гамбургскому счёту требует стабилизации, а цену оно имеет как у больших (памятуя об опыте первых участников рынка импортозамещения)... То есть ради сиюминутной коммерческой выгоды был продолбан неплохой шанс сделать по человечески... У нас не такой большой рынок, но зато 100500 инфраструктурных решений по ОС, виртуализации и прочему. Разработка приклада - АД кромешный, стабильность данных платформ условна, чудоковатость решения оперативных ежедневных задач иногда зашкаливает... Остальные проблемы отечественного софта вытекают отсюда.
Горе от ума. Ленивые люди берут базовый тариф на лоукостере, там где почти нет диска, почти нет процессора, но есть безлимитная полоса в 100 Мбит/с и поднимают там OpenVPN. Остальное описано в книжках по сетям и NAT. В таком конфиге оно может даже быть вполне полезным. DDoS-ы не переживёт, а для добросовестного использования вполне хватит.
Там можно даже сайтики почти нормально хостить, выбросив на этот недохост на VDS провайдере nginx, а всё мясо развернув на узле дома....
Но нет, нужен телега-бот написанный на С++ который по curl-у с другого ресурса запрашивает IP и отдаёт его в телеге. Вся надежда на телегу, сайтик с определением IP и вот это вот всё....
Да, для других извращенцев, которым тоже простые решения как серпом по телу: как-то делал на bash раскривушку. Она получала IP из переменной окружения и регистрировала его на ns сервере. В том случае был BIND, но собрать такое на NSD нет проблем, даже проще. А дальше прописываем этот сервер 3-м уровнем (на второй нужна пара серверов), и конектимся по SSH. Всё нужное openssh положит в переменные окружения, останется только прописать команду на подключение по определённому ключу (в авторизованные ssh-ключ можно прописывать команды, стартующие при использовании этих ключей), откуда эта груда костылей получает имя (его прописываем в эту самую команду для ключа), регистрирует IP с которого проведено подключение и завершает сеанс. Конектится можно хоть раз в минуту, NSD переживёт.... Вот и халявный свой DynDNS с блек-джеком и всем, что развёртывающий вздумает на него навесить.... Можно даже узлы c NS и терминальный для соединений разнести по разным виртуалкам или контейнерам, если очень нужно.... У меня загнулось на этапе прототипа. Тесты прошло и было похерено, как рабочий концепт на случай атомной войны, поскольку решение с калиткой (точкой входа на дешёвой VDS) имеет больше перспектив и более управляемо и предсказуемо.
Что за поток создания?
Упоминаемый Национальный Удостоверяющий Центр - это коммерческая шаражкина контора, созданная Гарантом на фоне роста рынка цифровых подписей и прочих ЭДО, о чём можно легко посмотреть по ИНН. Он такой же "национальный" как nic.ru, который должен быть основным регистратором для зоны RU (исходя из имени, и по началу даже был), но что-то пошло не так, рыночек порешал по-видимому... И эта контора уже не очень, даже как коммерческий регистратор. То что у нас бардак в наименованиях скажем спасибо либерализЬму и прочем свободам идиотизЬмов, когда за самым пафосным именем, скрывается самое ущербно ООО. Народ из министерства просто не заморачивался с названием. И прав по своему. При проблемах можно просто прибить АО....
Министерство - уполномоченное ведомство. Оно создало НУЦ - уполномоченный центр. В чем проблема? В том что НУЦ относится к министерству а не выделено в отдельную юр. морду.... Ну здесь на любителя, по мне, то что названо национальным, должно контролироваться государством полностью, иначе - это введение в заблуждение.
То что через ведомство попилили бабла, так не только в нём. У нас тут ГосОблако имени Ростелекома взлетает уже лет 10 на ежегодной основе. И ничего, пока не летит, в прошлом году снова поднимался вопрос об ГосОблаке.... Почему попиленный бюджет в прошлом должен стать препятствием к созданию НУЦ, не до конца понятно.
Вы можете входить из любого браузера на офф. порталы. Они просто должны доверять НУЦ. Пока доверяют из коробки двое. Остальные не хотят. Но есть сертификат, который им можно скормить. Если Браузер не принимает сертификат, то это проблема браузера а не УЦ его выпустившего...
И да по тому, что в сфере ГосИТ у нас не просто бардак, а пылающий звёздный бардачело даже не спорю. В такие непроходимые джунгли из поделий, недопродуктов и процего, без всякого намёка на стройную структуру, всё это довести прямо талант нужен. Наши люди талантливы... Но конкретно по НУЦ претензий нет, главное чтобы это был спец. комплекс а не роль Центра сертификации Microsoft на компе одного из админов в Министерстве.
Возможно это утверждение сделано на основе психологической травмы, нанесённой эксплуатацией этого чуда. Я верю, что знаючи эту тварь дотошно, её можно сделать адекватной (у людей то как-то выходит...). Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы... это само собой напрашивается на проблемы.... Вот что мешало эти долбаные объекты инициализировать json файлами???...
А так, при общей популярности темы сайтостроительства и общей уверенности, что выучив PHP можно почти сразу разбогатеть на непыльной работе (ну по крайней мере в горизонте прошлых лет), в отрасли полно людей склонных использовать инструменты криво, опасно и даже преступно... Вот только в сочетании с Bitrix это становится просто идеальным штормом...
Эта дрянь должна писать в себя, чтобы жить. Писать она может даже то, что потом она будет исполнять. И МАЛЕЙШЕЕ отверстие, позволяющее выполнить свой (атакующего) код в контексте сервера (а судя по тому, какая круговерть творится вокруг движка, пока он творит свою чёрную магию, этих отверстий там порядком), либо малейшая дрянь которую можно положить через механизмы движка на сервер а затем исполнить php-интерпретатором, даёт полный контроль над всем движком. И червяк начинает методично разбрасывать обфусцированные сниппеты по всем index.php и прочему бардаку, что обильно разбросан по всему движку, на всю, местами неадекватную, глубину вложенности. Я как администратор не могу с этим справится, в Bitrix нет такого каталога, где лежит код, и куда пользователь (лицо взаимодействующее с сайтом даже через админку) писать не должен, и каталога, где лежит переданное от клиента, и от которого должен держаться подальше php-fpm (ну по крайней мере не исполнять от туда скрипты). И это бесит! Я не в силах понять, что творится при создании контента. Простыни инициализируемых объектов мало чем сами отличаются от вредоносов. Ну нет там смысла для взгляда человеческого и нельзя в среднем объять мозгом простынь на 4-10 скролов с перечислением каких-то инициализируемых свойствах убер объекта...
Итого:
Битрикс делает невозможной пассивную защиту, поскольку нельзя реализовать классическую схему W^X (то куда можно записать не должно исполняться)
Он не позволяет легко понять, что на ресурсе происходит что-то не то. Оно штатно разбрасывает неожиданные php файлы в непостижимые места, многие из которых плохо выделяются на фоне вредоносов...
Эта штука умудряется заразиться кажется даже быстрее чем Windows XP с SP1 выставленная голой жопой в интернет. При этом если XP от интернета можно держать на расстоянии, то с Bitrix это не выйдет совсем...
И при всех своих заслугах оно стоит дичайших денег.....
Решительно отказываюсь понимать происходящее.....
Какой ужас....
ППКС.
Сталкивался с Bitrix несколько раз в качестве специалиста по "заставить это как-то работать" (aka эксплуатация на максималках). Все разы меня терзал странный вопрос: как это чудо света (а это без сомнения чудо света, ибо совершенно не постижимо как при наличии уже понимания, что нужно разделять в сущности представление, действия над ней её данные, всего накопленного опыта CMS можно было породить ЭТО) достигло своих высот.
Для меня как эксплуатации, данная CMS является головной болью. Ей нельзя запретить писать в собственные директории на сервере. То есть, без специальных извращений с несколькими экземплярами PHP под разными пользователями, один из которых под публичную часть, второй под админку, эта штука не способна защитить себя от различных червей. Мне приходилось иметь дело с дырявой Joomla. И манипуляция с правами пользователя PHP на файлы и директории давала достаточно защиты от червей. Да нужно обновляться но сидя в конторе в одно лицо, без умных (ну или просто) семпаев, задача "не ушатай" становится более приоритетной... Такой фокус с Bitrix не прокатит, там нужно иметь 4-й дан в эксплуатации PHP, чтобы защитить это чудо без постоянных обновлений. При чистой эксплуатации, когда все изменения в сайте производит разработка, либо заказчик, а я просто держу это на плаву, единственным решением задачи защиты стало обернуть всё в меркуриал репозитарий, выполнения с некоторой периодичностью status и если там что-то появилось отправку diff на почту, для дальнейшего выяснения, кто-куда-зачем.... Даже, когда разработки утверждала, что оно обновлено, раз в неделю diff давал 100500 файлов загаженных сложно вычленяемыми на фоне остального говнокода сниппетами заразы...
Работа сабжа со стилями вызывает трепет. Если не знать того единственного правильного способа (который мне лично не известен), оно порождает миллион css файлов, и весь этот миллион тянется пользователем при запросе страницы. И эти файлы однотипны и отличаются только штампов времени в конце. Понять откуда это всё без вдумчивого изучения решительно нельзя...
Поменять что-то на странице, если это не предусмотрено разработчиком модуля, вёрстки и прочего, даже при наличии доступа к коду, практически не реально. Понять куда там запрягают коней без специальных курсов решительно нельзя. В админке найти нужно тебе опцию - квест повышенной сложности. Если оно падает, то никто кроме поднимавшего не сможет вернуть всё взад (ну или разворачивание резервной копии с потерей всего, что сделано после её создания). Если человек, кто разворачивал, делал это методом тыка - ничто не поможет кроме бекапа....
Если кто-то сможет объяснить почему оно ТАК популярно, нижайше прошу просветить, иначе у меня создаётся впечатление о клиническом садомазохизме всей отрасли российского сайтоделательства. Нет, как коммерческий продукт, для создателей этой CMS - это просто шедевр: эксплуатация будет платить за лицензию, потому что ей нужны будут обновы. Там есть место облачным сервисам, поскольку НУЖНО регулярное резервное копирование и не помешает CDN, особенно если это чудо развёрнуто на shared-хостинге с драконовскими лимитами по диску. Но блин, что это кроме откатов даёт эксплуатации не ясно. Даже знакомый разработчик сайтов мне не смог внятно ответить о плюсах "продукта", но живописал великим и могучим своё к нему отношение....
Учиться работать с БД в рамках языка программирования с того, чтобы учиться работать с БД в целом, ИМХО плохая затея. Ибо человек такое создание, что склонно терять лес за деревьями, а реляционная логика, понятие множеств и действий над ними, на которых она строится и общая логика работы СУБД даст достаточно деревьев, чтобы за ними напрочь, месяцев на 6 минимум, полностью потерять GO из виду =))))) Эту часть квеста лучше проходить заранее....
А в рамках топика, о ALL, а никто не порекомендует обновляемый, адекватный, online справочник по синтаксису и стандартной библиотеке Go на русском языке.
Попробуйте [bookstack](https://www.bookstackapp.com/). Этим приложением завершился мой поиск идеала. Что-то лучше найти уже не надеюсь
Не совсем. Есть баги, которые появились по недомыслию, скудоумию, невнимательности, а есть атомный фугас неуправляемой универсальной функциональности оставленной без присмотра, только потому, что он "Open Source" и "тысячи программистов по всему миру его проверили"(с). Есть множество ПО долгое время живущее без проблем просто потому, что не стремятся покрыть собой весь мир. И тот же log4j жил бы спокойно, если к тому обычному для него километру конфигов нужно было явно добавить строки с подключением модулей для парсинга этих выражений. Глядишь и парсилось бы быстрее...
Что меня порадовало в этой истории, так это то, что сначала создали интерфейс удобный, красивый и способный забрать что угодно и откуда угодно. Потом внедрили его много где (включая логер) поскольку он универсальный и удобный. А потом БАЦ!!!, "батюшки святы"(с) он же может получить что угодно и откуда угодно!
А на кой леший это создано, и зачем везде внедрено! Возможно Log4Shell открывает другую проблему в Open Source, а именно - черезмерное сремление к универсальности и всепогодности-всепроходности. Я вообще с трудом могу себе представить зачем нужен этот монстр (хотя бы он и миленький и удобненький) в практических случаях. Кому-то хотелось подтянуть строчку из LDAP или CORBA без лишних телодвижений? Это крайне похоже на стиль мышления Java (достаточно здравый на мой взгляд, если мы говорим о прикладных задачах) - наколбасить многомегабайтную библиотеку, чтобы в прикладе иметь возможность закрыть вопрос парой нотаций и одним объектом. Но вот глубина этого всего, что можно таким образом провернуть, явно великовата.
А что касается до аудита кода, то безопасный код пишется по другому. Безопасные библиотеки не удобны для новичков, и требуют понимания происходящего. По настоящему осознание "безопасность" приходит при чтении исходников OpenBSD. Я в своё время за пару часов с базовыми значниями sh прочитал скрипт запуска и установки этой системы, и мне стало КРИСТАЛЬНО понятно, что там происходит, поскольку было написано понятно, и прекрасно укладывалось в голову, без лишних сущностей. Подобное сейчас не пишут, а если и пишут то это не модно. На эти грабли вставали ещё во времена эпичных дыр в OpenSSL и с тех пор мало что изменилось.
Считать максимум рабочих процессов от памяти - способ отстрелить себе пол организма под нагрузкой. Конкурирующие за вычислительный ресурс рабочие процессы будут друг-друга сильно тормозить. Такой фокус можно использовать только при том, что большая часть этих процессов будет спасть в ожидании данных с БД, и то до того момента как от DBA не прилетит не иллюзорная звездюлина, поскольку ему тоже вряд ли досталась SUN Niagara и количество исполнительных каналов процессоров у него на сервер БД также ограничено, а памяти и прочего процессы СУБД жрут не в пример больше чем php-fpm даже при достаточно кривом php коде...
Не смотря на то что сейчас 2021 год, космические корабли уже вылетают за пределы нашей солнечной системы, интернет существует уже 52 года, 30 лет как существует World Wide Web, 20 лет как существует wikipedia и порождённая ей культура всяких wiki, не смотря на всё на это, в нашей многострадальной, богом хранимой стране (ну или по крайней мере на нашем великом и могучем языке) так и не смогли создать ресурс, на котором всё вот это собиралось бы и хранилось. Есть миллион бложеков, сотня-другая тысяч мануалов, подробно описывающих как подключить базовый репозитарий к убунте и установить php с настройками по умолчанию. Возможно среди них и затесалась та самая статья которая описывает все эти известные с древнейших времён прописные истины, очевидные каждому адепту *nix администрирования. Но она там утонула и чтобы её найти нужно провести полноценные археологические раскопки. А так базовые циферки прямо на хабре.
Ну а вообще, к сожалению, материала с простыми базовыми опорными формулами задания основных параметров всякого софта типа "сервер приложений", с которых можно хотя бы начать играться с цифрами не так чтобы много. А если много, ссылки в студию.
То что браузеры исполняют их в песочнице не помешало эксплуатировать спектру с JS. Поэтому я и говорю, что времена, когда мы все были в домике и глаз хватало, чтобы быть в безопасности давно прошли.
Я дико извиняюсь, но антивирусные компании очень даже немаленькие, а мантру о том что множество глаз БДИТЕЛЬНО следят мы проходили во времена heartbleed. Не помогло OpenSSL, за которым следили параноики, почему должно помочь браузерам.
А нода здесь как самый яркий пример того, как обычная человеческая лень программеров увеличивает поверхность атаки на порядок, а бардак в их модной инфраструктуре вполне может спровоцировать получение JS-зловреда с уважаемого сайта, и уберечься от этой дряни, хотя бы спустя некоторое время, сможет помочь только антивирусник.
И да, я читаю ежедневный отчёт от Kaspersky Cecurity Center по моей маленькой непримечательной сетке, и крайне счастлив, что вся эта дрянь из отчёта осталась за пределами сетки.
Все системы антивирусной защиты делятся на дырявое решето и имеющие функцию подмены сертификата. Как вы предлагаете проверять js-дрянь, идущую по SSL каналу. Кончилось то время когда на Web-е лежали файлики, и если не позволять им запускаться - то всё будет зашибись. Сейчас с помощью js Вас могут завязать в узел и сложить из Вас оригами почти не приходя в сознание с использованием только штатных API. А если к этому добавить не контролируемое вовсе мракобесие с node.js и просто разбросанными по интернету файлы с кусками фреймворков, в время от времени находят разное.
Вообще есть прекрасный способ сделать так, чтобы за пользователем не следили и он был в безопасности. Нужно по сайтикам лазить ка Столман. Где-то на хабре вроде была статья с его рецептом успеха. А в остальное время, приходится использовать проверку SSL-трафика, и внимательно следить за исключением трафика всяких банк-клиентов, которые это местами страсть как не любят.
Взрыв мозга, а не ОС. На фоне DOS-ов и первых форточек, так вообще звездолёт. Это мои первые впечатления....
Я правильно понимаю, что пересменка происходит на АТП, куда машина гонится с РЦ уже гружённая на следующий рейс? Если да, то не до конца понятно:
Почему пересменку нельзя сделать на РЦ, доставив туда новых водителей попутно другими машинами, либо просто установив точку рандеву на РЦ, перенаправив туда служебный вахты с водителями, которые должны начать рейс в ближайшее время.
Зачем гнать на АТП машину, когда большую часть проверок можно провести по окончании рейса, а на РЦ дежурный механик просто проведёт общий осмотр машины перед погрузкой и после неё на предмет базовых технических проблем. В конце концов машина должна уйти с АТП здоровой, и маловероятно, что по дороге у неё произойдёт что-то, что не сможет увидеть техник напару с водителем, закреплённым за машиной. Явно сейчас его там нет, но можно отправлять народ с АТП по графику на дежурство на РЦ на отдых за "особые заслуги". Тогда не нужно печатать документ до рейса, рейс начнёт уже сменщик и распечатает себе документы. Вся задумка с QR исключительно из-за того, что водители явно исполняют обязанности и экспедиторов и отвечают за груз, поэтому необходимо следить за погрузкой. Если снять с водителей такую ответственность через упаковку товара в контейнеры (на колёсиках) и оставить за водителями только ответственность доставить соответствующее количество контейнеров на соответствующие точки, а разборки по загруженной номенклатуре предоставить сборщикам и контролёрам на РЦ, принимающими специалистами на точках, обеспечив надёжные средства доказательства невмешательства водителя в груз, то водителям вообще должно быть без разницы: один доставил машину на РЦ и поставил на погрузку, тем самым завершив смену, второй просто принял гружёную машину вцелом, проверив что все места на месте, и пошёл распечатывать на неё документы, по которым после уже начинает свой рейс.
Просто мне кажется, что описанный в статье процесс слишком наворочен и разухабист. Очень похоже, что героически решили проблемы, возникшие из-за того, что "всегда так делали и вы задолбётесь пересогласовывать бизнес процессы целиком, но можно согласовать несколько костылей к ним, и обойтись малой кровью и не сдохнуть в совещаниях с топами сразу нескольких неповоротливых дивизионов, где каждый будет отстаивать незыблемость своих бизнес процессов, ибо если их колыхнуть, то сразу 100500 тысячмилионов долларов убытков ежеминутно" (с) Очень хочется верить что хоть у вас нету такой фигни....
Так и не понял, зачем такие сложности. Машина и водитель, вообще ИМХО разные сущности. Водитель вернул машину в РЦ (пересечение ворот), тем самым закрыл свой рейс, отметилось время. После этого машина обслуживается и попадает в планирование на рейсы в очереди. При необходимости, если в смене водителя осталось время, он её подаёт под загрузку. Загрузка происходит по планшетам, и склад формирует фактическую загрузку, и формируются документы в электронном виде. После загрузки уже тот водитель, который повезёт груз подходит к принтеру, которых может стоять батарея, сканирует QR из приложения на планшете/телефоне, ему отдаются накладные на все точки, которые уже по факту визируются и он едет. То есть машину рассматриваем отдельно, а водителя на неё планируем отдельно. А не вот этот человекомашинный комплекс с переходным состоянием "у первого водителя смены не хватит на следующий рейс, поэтому пусть он загрузит, а второй разгружать будет". Здесь есть вопросы с экспедицией, но если рассматривать сборку тележки (та хрень на колёсиках, которая в сетях и является местом груза) отдельно, то есть привязывать комплектовщика к этой тележке, накладывая на него ответственность за сборку и учёт собранного, и качественно опечатывать, на ценный груз используя прочные чехлы, на малоценку использовать продуманные механизмы опечатывания и фотоотчёты, может получится даже несколько гармоничней.
Ну вообще, проблему качественно разработали и досталось всем. AMD не исключение. Intel просто перегнул палку с оптимизациями. Другое дело, что с OoO сложно что-то сделать в подобных сценариях атак, поскольку есть общий кеш и исполнение кода, из будущего уже в настоящем. Чтобы качественно закрыть все возможности атак, нужно либо предисполнение делать на другом наборе кешей, либо эти кеши как-то особо закрывать, что явно угробит весь профит от данного предисполнения...