Для ЛЛ: Бабаробот — производит наш завод. Бабаробот — ни забот, и ни хлопот
Фирма Realbotix показали первую более-менее "почти как живую" робота Арию в Лас-Вегасе. Исскуственный интеллект, и остальные бонусы, типа быстрой прошивки, смены лица (на магнитах). Поддерживает 15 разговорных языков и 147 диалектов.
Цена .. 175 тысяч долларов.
Для лиги лени. Не произошло. И не планировалось.
Особенно в русскоязычном сообществе мне нравится то, что и про импортозамещение "вообще", и про переход на опенсорс, рассказывают люди, не способные выйти из vi, считающие query execution plan – ругательством, а FORCED PARAMETERIZATION – призывом демонов.
Мне же иногда пересылают ссылки на телеграм и форумы, причем такие, что по прочтении у меня глаз дергается, и начинаются флешбеки из 2015 года, рассказы одного Ильи.
Писать про это скучно, читать тоже, и вообще, «who cares where they come down? That's not my department!» says Wernher von Braun. Но, напишу. Раз в квартал можно.
Рассказы и приказы про импортозамещению идут с середины 2000х, начиная с планов, что в 2008 в России возьмут и везде перейдут на Linux. Скоро 20 лет, как переходят.
Начну с самого начала. С разработки «общей схемы» своего кремния.
Его почти нет. Почему «почти»? Потому что ядро Эльбруса, каким бы ущербным с точки зрения производительности, при использовании в гражданском секторе, оно не было, его все же разработали, и даже произвели. Дальше начинаются не озвучиваемые проблемы с мостами, QPI, и так далее. Разработчиков наградить, производство наградить, связистов не наказывать.
Не ядром единым жива вычислительная техника. Нужны контроллеры для Interconnect, нужны ASIC \ FPGA для сетей, нужны видеокарты, нужны дисковые контроллеры, нужны SSD контроллеры, и так далее, вплоть до SFP модулей.
В мире такой разработкой занимается может по 5, может по 10, фирм по каждому направлению. Занимаются очень давно, еще до времен массовых слияния и поглощений.
Скажем, слияния тех же Burroughs Corporation и Sperry в 1986. Или AMD - Xilinx. Или делают что-то комплексное, например Apiary: An OS for the Modern FPGA.
В России этим тоже занимались. При советской власти, то есть с середины 70х развития почти не было.
Что нужно, чтобы такие люди и разработки были? Да почти ничего. В мире есть 100-200 (просто 100-200) человек, на 10-20 дизайн бюро, которые этим занимаются. 200 человек, отобранные из, условно, миллиарда населения Китая и миллиарда объединенного населения Европы и США. Всего то нужно отобрать 200 из 2.000.000.000. И немного их учить, лет так с трех. Желательно учить не учителями по $300, и не в стандартной школе. И немного передавать им производственный опыт, что было сделано, и почему. Мелочи.
Затем теоретическую схему надо переложить на кремний. Что с ним, за исключением отсутствия производства расходных материалов, производства полуфабрикатов, и производства самих станков и запчастей к ним в РФ?
Есть Микрон, и есть линии 180 и 250 нм на нем. Годятся, чтобы делать чипы для паспортов, банковские карты, карты для метро, сим карты, и так далее. Раньше, давно, могли делать первые серии Эльбрусов. Сейчас - уже не могут. Почему – потому. Автор фразы «Птичка упала за террикон» находится в местах, не столь отдаленных. Про связь какой-то птички и ASML догадайтесь сами.
Что в наличии? Есть линии, от ASML и STMicroelectronics. Громко рекламируемый ребрендинг белорусского Интеграла на 350 нм списан на склад, пока не сгниет. Как сгнила купленная еще 2006 линия AMD Fab 30 (Дрезден).
Дальше готовые чипы нужно усадить на материнскую плату, которую тоже надо спроектировать. Современные платы, а не те, на которых деды нынешних экспертов в школе играли в «Ну погоди» - это 22-26 слойные платы, которые тоже надо спроектировать, произвести, и установить на них не только чипы, но и микрокомпоненты. Про микрокомпоненты раньше в школе рассказывали – индуктивности, конденсаторы, все это. Вручную такой сборкой почти не занимаются, для этого станки есть. Еще лет 10-15 назад, бывало, и вручную ставили. Производство микрокомпонентов в РФ и вызывало грусть, и вызывает. Не само производство, а качество (и его отсутствие), и подход к поставкам, номенклатуре, итд.
Можно сказать, что «российского» в импортозамещенном железе столько же, сколько в Москвиче-3.
Закончив с железом, перейду к софту.
Пропущу такие интересные вещи как сети, межсетевые экраны, NGFW и управление ими, а точнее AI анализ трафика, системы хранения данных, и прочее железно-программное. И их возможности, и цены. Даже ролик с рассказом испанца (Хуан Хойя Борха) пропущу.
На замене софта начинается просто праздник.
Есть две большие группы людей.
Одни не могут выйти из vi, и воспринимают Excel , как тетрадь в клеточку.
Другие используют формулы, макросы, VBA, подключаемые внешние источники, AI аналитику, и теперь Python, и все внутри Excel.
У одних база данных на 100 гигабайт – это все данные за пять лет работы фирмы.
У других 100 гигабайт – это объем транзакционных логов за час, если не меньше.
Одни не могут пару лет купить SSD на терабайт, потому что им дорого.
Другие плачут, что 8 терабайт оперативной памяти не хватает для In-memory.
То же самое везде – Tivoli Directory Server против Samba, VIOS против KVM, Pure против Ядро, и так далее.
Первым можно хоть сейчас заменить Excel на Лексикон.Мегатаблицы.
Вторым предлагают вместо Caterpillar D11 купить отвал на джип.
Caterpillar D11
Отвал для снега
Пропущу специализированный софт, все эти REVITы и солидолы.
Самое сладкое начинается в управлении всем этим софтом, а точнее процессами, стоящими за этим софтом. Начинаются требования не к самому софту, "чтобы работал", а к процессам, которые обсепечивает этот софт.
На все вышеперечисленное накладывается четыре фактора
Фактор первый. Смена технологического лидерства, а точнее новый передел мира. Сделка века Газ-Трубы от 1970 года закончилась. Если кто прогуливал историю, то 1 февраля 1970 года между СССР и ФРГ (капиталисты, не путать с передовым социалистическим ГДР) была подписана сделка, определившая историю Европы на 40 лет.
Европа получала газ из Сибири (и нефть, и много чего еще).
СССР получал поставки бесшовных труб большого диаметра (не умели их делать в СССР), технологии их производства, и много чего еще. В том числе технологии турбин для газоперекачки, к ним системы управления, плюс поток валюты, плюс командировки для элиты (номенклатуры) для обмена опытом.
Сейчас в Старой Европе все сложно. Настолько сложно, что достаточно посмотреть рейтинг АфД.
Производство уезжает от дорогих кадров, дорогого социального обеспечения, и налогов на поддержку всяких дармоедов, и людоедов, в Китай.
В том числе поэтому в Европе мало что можно купить. Мерседес можно. Airbus можно. Линию нельзя.
Фактор второй. Смена технологического уклада, переход от остатков четвертого технологического уклада в шестой. Паровозы, то есть автономные домашние сервисы, типа внешних USB дисков, еще ездят, но все уже централизовано, хранится в сети, и предоставляется по запросу. Если работает, а не опять упало, потому что индус, которым импортозаместили разработчика в Cloudflare, опять накосячил.
Поэтому стащить не получается.
Фактор третий. Смена поколений. 30 лет назад, когда уже не молодой Ричард Мэттью Столлман выступал за «даешь опенсорс бесплатно в массы», и проекты были попроще, и нагрузки поменьше, и код почище, и трава получше, и из Южной америки поставлялись экологически чистые продукты, а из Европы – лучшее из Грибоедова (Clavicipitaceae и Strophariaceae).
Сейчас продукты стали сложнее, нагрузка на работника повыше, и желания заработать «для себя» - побольше. Уже много лет идет отмирание опенсорса. Часть продуктов закрывается, часть переписывается с ноля (и не делается при этом лучше), часть меняет лицензии.
Разработчики уходят - Brendan Gregg announced he has resigned from Intel.
В большом ИТ идет индусозамещение.
При этом персонажи, которые уже освоили выход из vi, и даже сделали один раз
git clone https://github.com/Hello/world.1
говорят, что это же так просто, склонировали себе продукт на пару миллионов строк и переписали. Конечно просто. Взять и склонировать. И хотя бы прочитать. Включая зависимости.
Тот же KVM:
150 тысяч строк кода (и это не ядро, это сам KVM)
90 тысяч строк тестов
Это только один модуль.
Теперь сейчас еще и половину настроек k8s переписывать, для перехода с Ingress NGINX на Gateway API. Я сегодня планировал искупаться и поплавать, ну поплавал максимум в бассейне, сижу, читаю, и плачу. В перерыве плачу с бывшими коллегами, потому что у меня то только k8s, а у них еще и «импортозамещение». Истории в нем – одна удивительнее другой, а уж какие планы, ой.
Фактор четвертый. Уход с рынка ряда коммерческих продуктов
14 сентября 2022 года Microsoft обьявила про завершение жизненного цикла Exchange 2019.
14 октября 2025 года история Exchange offline закончилась, теперь только Exchange SE по подписке. Заменять его нечем в РФ, и нечем в мире.
2 октября 2025 года закончилась поддержка offline VMware by Broadcom, теперь только по подписке, и задорого. То же самое Broadcom устроила с FC коммутаторами. Чрезвычайно уважаемые люди еще тогда предвидели - будет как в Computer Associates и UCC-7 - CA-7.
Заменять Broadcom тоже нечем.
Ряда продуктов просто не существовало, и не существует, в опенсорсе. Знающие люди мне уже давно насовали ключевых слов, типа SpaceWalk:Satellite(CentOS:RHEL), AptcacherNG, Foreman и Katello, но это очень не то же самое, чем русифицировать salt stack и назвать это импортозамещением, и не имеющим аналогов убийцей SCCM (ранее System Center Configuration Manager, теперь Microsoft Configuration Manager).
Итоговые ошибки внедрения и тестирования «типа импортозамещения» просто не выносят из изб. Такой .. тяги и коричневых потоков не было с 6 июля 2012 года, если вы понимаете, о чем я.
Прорыв реальных новостей
О каком импортозамещении и переходах "на опенсорс" речь, если только за последний месяц случились React2Shell CVE-2025-55182 и Grafana CVE-2025-41115, какой там "контроль кода".
И это в масссово используемых продуктах, уже повсеместно.
Нельзя просто так взять продукт для малого и очень малого бизнеса, хоть Samba Server, хоть Postgres SQL, с их врожденными ограничениями, и натянуть на хотя бы среднего размера инфраструктуру. Ирония в том, что ограничения указаны прямо в документации, причем в документации на русском:
Максимальное количество столбцов таблицы дополнительно уменьшается в связи с тем, что сохраняемый кортеж должен умещаться в одной странице размером 8192 байта. Например, если не учитывать размер заголовка, кортеж, состоящий из 1600 столбцов int, будет занимать 6400 байт и поместится в странице кучи, тогда как 1600 столбцов bigint займут 12800 байт и в одной странице не поместятся. Поля переменной длины, например типов text, varchar и char, могут храниться отдельно, в таблице TOAST, когда их значения достаточно велики для этого. При этом внутри кортежа кучи должен остаться только 18-байтовый указатель. Для более коротких значений полей переменной длины используется заголовок из 1 или 4 байт, и само значение сохраняется внутри кортежа в куче.
Теоретически каждая таблица может хранить до 2^32 отделённых значений. Более подробно такие значения описаны в Разделе 66.2. Данное ограничение вызвано использованием 32-битных OID для идентификации каждого такого значения. В реальности же лимит значительно ниже, поскольку как только всё пространство для OID занято, найти свободный OID становится сложно, что замедляет работу операторов INSERT/UPDATE. Обычно это происходит только с таблицами объёмом в несколько терабайт.
Заключение
Построишь? Куплю.
Классика советской мультипликации, но почему-то летающие корабли не продаются всем подряд. Единственное, что точно удалось национализировать, это один из сайтов по рассказм про все подряд, превратившегося из сайта «про ИТ» в сайт с разрешенными новостями от Минцифры.
Бывает. Press F.
Странно, что сайт целиком не купила Астра, и что Астра даже не стала покупать на нем блог, ограничившись платными статьями. Но, это дело тех, кто платит еще и этот своеобразный налог, окончательно завалив сайт сгенерированными статьями, и статьями космического масштаба и космической же глупости.
Литература
Похоже, лично мое клатбисче используемых проектов* в этом году пополнится Ingress NGINX – проект все, Ingress NGINX Retirement: What You Need to Know. Предлагается переход на Gateway API, сколько всего придется переделать, переписать и переставить – пока даже не представляю.
автор - kadabrus
Интересно даже не это, а то, сколько заброшенных или забрасываемых проектов выявляется каждый год. И замены им нет, и не будет.
И даже не это интересно, как то, что разработчики Ingress NGINX два года пытались найти кого-то, кто бы помог в разработке опенсорса. Но нет, использовать можно, сказать бесплатным разработчикам ВЕЗИ МЕНЯ ТВАРЬ «давайте чините» можно, самим делать – нет.
На первом месте в моем личном каталоге «проблем от заброшенных компонентов» – Apache Log4j. 4 года назад (9 декабря 2021 года) в проекте, который теоретически должен был быть 100 раз просмотрен и проверен, потому что использовался везде, нашли огроменную дыру, Log4Shell (CVE-2021-44228). Куда смотрело все сообщество?
На втором месте – огроменная дыра в Linux под названием EternalRed (она же SambaCry), она же CVE-2017-7494. Дыра существовала с 2010 года, обнаружена была только в 2017, и то, не «обнаружена», а была проэксплуатирована с огромными последствиями. Куда смотрело все сообщество?
На третьем – свежая огромная дыра, размером с дверь ангара, в grafana - CVE-2025-41115. 10 из 10. Куда смотрело все сообщество?
Если говорить только о заброшенных проектах, то я до сих пор скучаю по заброшенному 10 лет назад RatticWeb. Не видел ничего лучше с тех пор. Мне особо не нужно, мне и Hashicorp Vault хватает, коллеги хвалят teampass, но все равно не то.
Что тут сказать?
Меняется вся модель opensource. «Давно», даже «очень давно», во времена победившей сексуальной революции и зарождения опенсорса, продукты были куда проще, а времени куда больше, так что продукты как-то писались и эксплуатировались.
Сейчас? Недавно у коллег (не в РФ) случились эффективные менеджеры, которые волевым способом продавили переход на новый, свежий Ceph.
Проработал Ceph полтора месяца и свалился, с потерей данных.
Смешно во всем этом даже не то, что Ceph свалился, и не то, что Ceph до сих пор тормозное и дорогое (отдельные сервера, отдельные сети, отдельные люди) решение, а то, что одной из причин стало
Support for GlusterFS is dropped
As GlusterFS is no longer maintained upstream, Proxmox VE 9 drops support for GlusterFS storages. Setups using GlusterFS storage either need to move all GlusterFS to a different storage, or manually mount the GlusterFS instance and use it as a Directory storage.
Drop support for GlusterFS starting with PVE 9, as it is unmaintained.
Proxmox Roadmap - Proxmox VE 9.0
Так и живем.
* отсылка к pet sematary, правильное написание Pet Cemetery, книга и кино.
Для того, чтобы получать и разбирать логи, и реагировать на результаты в логах, уже много лет существуют:
Windows Event Collector. Это, наверное, еще в школах изучают.
100500 разных Syslog collector. Rsyslog и syslog-ng. Вот сходу первый попавшийся список - Top 10 best free syslog servers. Сходу там упомянуты:
ELK (Elasticsearch). Открываешь вторую страницу AWS, статью Что такое стек ELK?, и читаешь.
Если хочется чего-то новее, то открываешь для себя тройничок: Promtail, Loki, Grafana
Сбоку от этого всего висит Filebeat.
Все вместе – часть огромного куска го пирога с го модного и стильного направления observability. Это тот же мониторинг, но дороже.
Конкретно логи безопасности и реагирование на них - это SIEM: Security Information & Event Management, а что это такое - вы могли бы и сами узнать в курсе Security 101.
Для лиги лени: планов громадье.
Прислали мне ссылку на громадное интервью:
Вскоре после того как в ноябре 2025 года стало известно о создании в России нового серверного процессора на базе архитектуры LoongArch, получившего название «Иртыш», TAdviser побывал в гостях у его разработчика, компании «Трамплин Электроникс», и выяснил подробности — как о самой новинке и особенностях лицензирования технологий, на которых она базируется, так и о дальнейших планах.
Все, что нужно оттуда прочитать, это следующие три строки:
Технологически «Иртыш» — это абсолютно независимый процессор
Исходный процессор Loongson , поддерживающий систему инструкций LoongArch
производиться процессоры «Иртыш» пока будут за рубежом, на территории материкового Китая
Каким образом архитектурно китайский процессор, производимый в Китае, стал "независимым" - я даже не пытаюсь понимать. Мне и не интересно.
Для лиги лени: капитанство
Взлом МТС облака с простоем и потерей данных. Признание взлома? Нет.
Публичный отчет? Нет.
Рекомендации от МТС, регуляторов, консультантов по безопасности ? Нет.
Взлом СДЭК. Смотри выше.
Взлом Аэрофлота. Смотри выше.
Взлом ПЭК.
и при этом, месяц назад на РБК вышло интервью с рассказом: не доверяйте подрядчикам, атака через цепь поставок – реальность,
Вы нашли в итоге уязвимость? Как они получили доступ?
Да, нашли. У нас был подрядчик, который работал с ВМС. У него был открыт порт, пароли слабые или вообще отсутствовали. Через этот порт они и вошли. Самое интересное — что они «копались» в нашей базе почти год до атаки.
Нужно ли платить выкуп хакерам: личный опыт бизнесмена
Особенно смешно, что параллельно с взломом шли оптовые продажи страха, то есть SOC FORUM - Российская неделя кибербезопасности. С рекламой мероприятия через сайт Минсвязи, как же без этого.
Заключение
Имитация безопасности стоит в два раза дороже реальной безопасности. Потому что сначала вы платите за продукт имитационный, идентичный натуральному, а затем разгребаете последствия.
Для лиги лени: продукт есть, но есть куда расти. Некоторые вещи вызывают недоумение.
Медведь годный.
Годный медведь
Учебник по интиму часть 1. Введение
Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом
Часть 3. Давайте пробовать поставить
Часть 4. Немного душноты
Часть 5. Gitflic api
Заключение
Учебник по интиму часть 1. Введение
Пришли ко мне в личку, в запрещенной в РФ сети, бывшие коллеги с вопросом, а знаю ли я, а могу ли я посмотреть, и им показать, что такое гитфлик (GitFlic). Я про такое первый раз слышу, потому что за импортозамещением в ИТ в РФ не слежу. Нет смысла следить за переименованиями, типа Debian 10-11-12 – Astra, Samba – ALD, Панголин – PostgreSQL, и так далее.
Тут вот, свой продукт.
Погуглил.
На сайте новостей Минцифры – две рекламные статьи, обе от 2021 года:
Первая - GitFlic. Российский GitHub и вторая, ответ на нее, «GitFlic: нас обвинили в «распиле». На этом все.
Остальное – 3 рекламные статьи, и два треда на лоре «как это работает вообще без техподдержки».
И, внезапно, статья от 1с – Инфостарт, Автоматизация процесса разработки с помощью сервиса GitFlic.
Пока дописывал статью, нашлась еще одна минцифровая статья «Cборка Java-проектов в GitFlic Kubernetes-агентом»
GitFlic не является форком какого-либо решения. Он написан с нуля и создан без иностранного участия, поэтому не зависит от внешних факторов и сторонних разработок.
В отличие от GitLab и GitHub, которые разработаны на Ruby и Ruby on Rails, GitFlic написан на Java. Это обеспечивает стабильность и производительность даже для крупных проектов.
Это Java то про производительность? Ну ладно
В 2023 году продукт был куплен Астрой
ГК «Астра» продолжает реализацию стартовавшей в 2020 году M&A-стратегии и объявляет о вхождении в контур группы ООО «РеСолют», разработчика GitFlic —сервиса для работы с исходным кодом и его хранения. Сделка проводится в два неразрывных этапа, по завершении которых в конце текущего года ГК «Астра» получит мажоритарную долю 51%. Оставшаяся часть акций будет по-прежнему принадлежать основателям компании: Алексею Синицину, Максиму Козлову, Тимуру Миронову, Денису Рамазанову и Константину Леоновичу. Стратегические договоренности компаний предполагают, что в дальнейшем ГК «Астра» сможет еще увеличить свою долю в разработчике.
Ну был и был, мало ли чего скупила Астра.
Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом
Продукт позиционируется как комбайн с вертикальным взлетом – тут и хранение кода (вместо GitLab Self-Managed), и хранение итогов сборок вместо Maven (Реестр пакетов Maven), Nexus, и так далее. С релиза 3 объявили что «Релиз 3.0.0 отличается удобным интерфейсом, развитой функциональностью и способен стать полноценной заменой зарубежных продуктов GitHub, GitLab, Nexus, Artifactory, Jenkins и т.д.»
Пишут, что теперь работает и с OneScript (это для 1с).
Обещают замену не только хранению кода, но и CI\CD, почти как в GitLab Runner или в GitHub Actions.
В версии 4.6 пообещали что уже добавили:
Проксирование реестра пакетов Deb
Проксирование реестра пакетов Helm
Прочее - 4.6.0 Что нового
Обещают, что к проекту подключилось 100500000000 пользователей, но на этом все. Просто все.
Зато в 4.4 отобрали манифесты:
Из стандартных пакетов убраны манифесты для k8s. На смену им пришли Helm Charts
При этом примеров «как это работает» и рассказов, кроме «мы внедрили, интерфейс красивый» - нет. Реклама есть. Сообщества нет. Примеров нет. Чат в телеграмме есть.
У продукта два исполнения – облачное и self-hosted. Облачное ни коллегам, ни мне не интересно, а на self-hosted можно и посмотреть.
Дальше я буду попутно сравнивать с GitLab Community Edition. Не потому, что он какой-то супер, а потому что я его видел, и с ним время от времени сталкиваюсь. У GitFlic Self-Hosted возможностей вроде сильно побольше, но посмотрим.
Gitlab CE (Community Edition ). Ставится в одну команду по инструкции с официального сайта -
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce
Все.
На самом деле нет, если посмотреть Gitlab CE Self-compiled installation, то там английским по белому написано: In GitLab 18.0 and later, PostgreSQL 16 or later is required.
GitFlic Self-Hosted. Требует Redis и PostgreSQL.
Зачем им редис – не понимаю. Но, GitLab Community Edition включает NGINX, Postgres, Redis, так что, есть и есть, как и у GitLab CE
Сама web страница загрузки (их репо) малость странное. Сверху указывается «N дней назад», и только внизу указано 2025-11-06, причем зачем-то этот фрагмент как-бы-защищен (нет) от выделения и копирования.
В реестре контейнеров последний бесплатный дистрибутив -
gitflic-server-ce
Бесплатный дистрибутив GitFlic
Версия latest
Опубликован 26 марта 2025 г.
Скачан целых 5 (пять) раз.
Дистрибутивы: Gitlab CE в варианте gitlab-ce_18.3.6-ce.0_arm64.deb.
GitLab Community Edition (including NGINX, Postgres, Redis)
Package Size 1.31 GB
Installed Size 3.55 GB
MD5 7244b435f26e74991f02a6525c4d3d26
SHA1 11c154d0bb4df6e9be39af864185d0cdfac7ea9e
SHA256 6b3e1ae33d8dd89c7344338fc51f98e39d992b2c87e6b6e0167d91b496390868
SHA512 479be83c2f8eb0247637097e5b1863f2eafe1787ed9e9b843e470eed343e8328799187b5153d723b6c756405e64005fd9b4faa59da471ded412a259643e254cf
Все вместе с опубликованными MD5 лежит открыто.
Дистрибутивы:gitflic .. все сложно.
По ссылке – лежит описание по 4.6.0
По другой ссылке
Лежит короткий readme, ссылка на сам файл gitflic-server_onpremise_4.6.0.zip, и ничего кроме.
MD5 ? SHA? Не завезли.
Ссылку для wget ? Не завезли.
Прямая ссылка на сейчас -
https://gitflic.ru/project/gitflic/gitflic/release/7f32e898-...
Файл gitflic-server_onpremise_4.6.0.zip размером 780590717 байт.
MD5 25C91261305A3EDA778684363D1D9D4F
SHA256 67DE3A8EFAD516DB39196E9DA6726E4A5287D51F60950951C62106C22CC4301D
На момент начала написания статьи обновление вышло буквально вчера (статья писалась почти 2 недели, работы привалило, откуда не ждали). Буду смотреть сразу свежее.
Часть следующая, давайте пробовать офлайн
У дебиан опять поменялась страница загрузки, так что, например, отсюда
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/
берем debian-13.2.0-amd64-DVD-1.iso
Тестовая VM, 2 vCPU, 4 Гб памяти, 45 Гб жесткий диск, Debian 13. Next-next-без графики-готово-забираем обновления – готово.
Правим /etc/network/interfaces и /etc/apt/sources.list
Заодно правим /etc/sysctl.conf от ipv6 и /etc/resolv.conf для DNS
Убеждаемся в том, что по неведомым причинам /usr/sbin/ так и не прописан в путях по умолчанию, делаем ребут.
/usr/sbin/shutdown
Смотрим – получилось меньше 5 Гб всей виртуальной машины.
Заливаем туда gitflic-server_onpremise_4.6.0.zip, отключаем сеть на уровне гипервизора и идем читать инструкцию
В инструкции куча слов про создание папок и установку из zip, но ни слова про то, что jar файлы по умолчанию запускать нечем.
Между тем, ПО идет как jar -
gitflic.jar, размером 444275979,
MD5 7ADC17898B22007B71C8C3D305777B42
SHA256 19468BAE05E83ADB6F56792C7BB6C946CE40CFD2F35F47B72BF77CAF879DF7B4
Поэтому, кроме упомянутого в руководстве apt install unzip , нужно сделать и apt install default-jdk. Еще в инструкции по установке везде стоит sudo, его тоже нет в debian по умолчанию. Хотите – ставьте.
Дальше хотелось бы делать по инструкции, но так не выйдет.
Потому что инструкцию надо было читать с самого начала, раздела «Предварительные условия», а не как я, сразу перейдя к установке приложения.
В предварительных условиях указано:
OpenJDK 11
default-jdk на момент написания статьи - openjdk 21.0.9 2025-10-21, OpenJDK Runtime Environment (build 21.0.9+10-Debian-1deb13u1)
Затем, везде в инструкции стоит использование sudo. Его по умолчанию нет в Debian, поэтому
apt install sudo
В инструкции указан PostgreSQL 11. Последняя версия, 11.22, вышла два года назад, 2023-11-09.
Актуальная версия – 18.1, или хотя бы 17.7. А тут 11.
Попробую с 16, что еще делать.
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc|sudo gpg --dearmor –o /etc/apt/trusted.gpg.d/postgresql.gpg
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
apt install -y postgresql-16
и дальше пойдем по инструкции из раздела Астры для PostgreSQL 11.
Файла мандатного доступа etc/parsec/mswitch.conf у меня нет, и хорошо. В инструкции в пути мелкая опечатка, и в части установки расширений забыли написать \q
дальше ставим Redis, ну или keyDB. Я поставил Redis - apt install redis, redis-cli ping отработал.
Остается сразу перевесить порт сервера с 22 на, скажем, 1122. Найду конфиг
find / -name "sshd_config" , и поправлю. Потом ребут, и
Перейду к самой установке по инструкции
mkdir /tmp/gitflic
unzip gitflic_*.zip -d /tmp/gitflic – эта команда не сработает с ошибкой
unzip: cannot find or open gitflic_*.zip, gitflic_*.zip.zip or gitflic_*.zip.ZIP.
Будьте добры писать команду целиком,
unzip gitflic-server_onpremise_4.6.0.zip -d /tmp/gitflic
cd /tmp/gitflic
for d in cicd repo img releases registry; do sudo mkdir -p "/var/gitflic/$d"; done;
эта команда .. ну, я от рута делал, так что на sudo ругнется.
sudo mkdir -p /opt/gitflic/bin
sudo mkdir -p /etc/gitflic
sudo mkdir -p /var/log/gitflic
sudo cp gitflic.jar /opt/gitflic/bin
sudo cp application.properties /etc/gitflic/application.properties
sudo mkdir -p /opt/gitflic/cert
sudo ssh-keygen -t ed25519 -N "" -q -f /opt/gitflic/cert/key.pem
И так далее. Шаг 13, конечно, тоже не сработает – нужно не useradd, а
/usr/sbin/useradd --no-create-home --system --shell /sbin/nologin gitflic
Дальше в инструкции идет раздел «Конфигурация SSH порта». На .. то есть – зачем?
Раздел «Конфигурация SSH порта» ссылается на следующий раздел, «Конфигурация и запуск». Это многое объясняет.
Если же читать инструкцию с начала, а не с середины, то в разделе «Предварительные условия» написано – зачем:
Для того, чтобы было возможным использовать remote-url вида git@gitflic.ru:gitflic/gitflic.git, необходимо освободить стандартный 22 порт ssh сервера!
Раздел написан корректно, но можно чуть-чуть улучшить. Например, переписав весь список главы «установка под Астру» в раздел «просто установка». Но, можно и не переписывать, продукт куплен Астрой.
Все бы хорошо, но нельзя просто так и сделать только по инструкции. Не работает. Например, сделав
systemctl status gitflic-server.service
видно, что сервис есть, а веб консоли – нет. Почему? Потому что надо смотреть инструкцию лучше, сервис по умолчанию стартует как [::ffff:127.0.0.1]:8080
В инструкции написано:
После запуска перейдите по адресу, указанному при конфигурировании и проверьте работоспособность сервиса
Но в инструкции нет пункта «адрес конфигурации».
Точнее, в самом начале инструкции указано:
Перед конфигурацией приложения, ознакомьтесь с назначением параметров на странице Конфигурация application.properties
По пункту 9 инструкции по установке понятно, что параметры лежат в
/etc/gitflic/application.properties, и внутри там написано
# Дефолтное значение адреса localhost
server.address=127.0.0.1
gitflic.base.url=http://localhost:8080 .
Заодно и логи указано где хранить, logging.file.name=/var/log/gitflic/server.log
Ну, окей, все понятно, слушаем на локалхосте. Ничего такого. Там же указано:
# При необходимости также можно указать порт, на котором будет запущен SSH сервер для работы
# SSH транспорта git. Дефолтное значение порта 22
ssh.server.port=2255
Ничего не понятно, но очень интересно.
Ну да ничего. Правим в конфиге IP и делаем systemctl restart gitflic-server.service. Перезапускается пару минут (в ограниченной по ресурсам виртуалке), и появляется WEB консоль.
Медведь хороший, мне нравится! Настолько хороший, что я выкинул из черновика картинки Kadabrus.
Остается зайти:
Стандартный пользователь и пароль
Почта - adminuser@admin.local
Пароль - qwerty123
Зашло. Работает.
И даже работает после перезагрузки.
Итого по установке
Медведь выбран удачно.
Инструкция достаточна для установки. Есть мелкие недоделки, типа пропущенного в одном месте слеша, или \q для выхода из psql, но ничего критичного.
PostgreSQL 11 надо менять на 16, 17 или лучше сразу 18. 11 – устарел.
JDK тоже указан старый.
В инструкции по LDAP авторизации сделано что-то не очевидное, но сейчас с этим разбираться лень
Часть 4. Немного душноты
С чем у коллег проблемы? Проблемы с тем, что они не разработчики, и им Git не нужен. Зато нужно брать секреты из Vault, и забирать к себе готовые плейбуки, ямл, открытые ключи, скрипты и так далее. И, кстати, контейнеры.
Что умеет забирать файлы из онлайна?
Если говорить про Linux, то это curl, wget, docker - docker push, далее со всеми остановками вроде Automate Ansible With GitLab и Build enterprise-grade IaC pipelines with GitLab DevSecOps.
Если говорить про Windows, то есть Desired State Configuration, но иногда людям хочется интима и единообразия, так что мы получаем invoke-webrequest и Invoke-RestMethod. И то и другое относится к (кажется) System.Net.Sockets, но про это не будем.
В Windows есть и wget, но это оболочка для invoke-webrequest, и есть два curl: один как командлет, и отдельный curl как честный curl.exe. Вот с этим всем и надо попробовать, как чего работает.
Часть 5. Gitflic api
Что есть в документации? Есть документация по REST-API. И есть небольшая репа gitflic-api, которую надо читать.
Начало простое:
Отправка любого REST-API метода требует авторизации. Для этого необходимо создать токен доступа и указать его в заголовке запроса в следующей форме ..
Создам проект MyNewproject01, в нем ветку master, в нем файл myfile01 с содержанием content01.
Для создания токена доступа через интерфейс необходимо:
Перейти в профиль пользователя
Перейти в раздел API токены
Нажать кнопку Создать
Сказать что инструкция «не очевидная» - это ничего не сказать. Профиль пользователя виден и в левом меню, и в правом верхнем. И токены API генерируются в правом верхнем меню
Вот сюда не надо!
СЮДА НЕ НАДО
Надо вот сюда!
Надо вот сюда!
Токены то есть, но токена «чтобы только читал» там нет.
В Gitlab сделано понятно, надо дать
read_repository: Grants read-only access to repositories on private projects using Git-over-HTTP or the Repository Files API.
read_user (Grants read-only access to your profile through the /user API endpoint, which includes username, public email, and full name. Also grants access to read-only API endpoints under /users. )
read_api (Grants read access to the API, including all groups and projects, the container registry, and the package registry.)
а тут как?
Просмотр информации о пользователе – ну, допустим.
Просмотр информации о проектах пользователя – окей,
Просмотр информации о реестре пакетов
Создание пакетов реестра
Удаление пакетов реестра
Где простой read_repository_only ?
Дам все права сразу, потом разбираться буду.
Замечу, что кроме API токенов и транспортных токенов, в проекте есть еще какие-то токены развертывания, но перечня «есть три типа токенов» в руководстве нет. Или где-то дальше, как транспортные токены.
Впрочем, не важно.
сообщение про токен читаемое, в моем случае:
Скопируйте токен. Он показан один раз и при перезагрузке страницы его получить иными способами не получится: af71db42-9683-40b4-b615-d31c9e5f7a16
Что с ними делать?
Для того, чтобы создать REST-API запрос, необходимо обратиться на определенный адрес (endpoint), который должен иметь следующее начало:
api.gitflic.ru для работы с API на gitflic.ru
localhost:8080/rest-api для работы с API в self-hosted сборкахДомен и порт при работе с self-hosted решением могут отличаться.
Для взаимодействия с публичным API GitFlic необходимо указать полученный access token в заголовке запроса в следующей форме:
Authorization: token <accessToken>
Что мешало написать пример для curl или хоть чего-то?
Пример с настройкой header для любителей Windows:
$headers = @{
'Content-Type' = 'application/json'
'Authorization' = 'Bearer your_access_token'
'X-Custom-Header' = 'MyCustomValue'
}
Invoke-WebRequest -Uri 'https://api.example.com/data' -Method 'GET' -Headers $headers
Примеры для моего случая, правильные и неправильные
$headers01 = @{'Authorization: token' = 'af71db42-9683-40b4-b615-d31c9e5f7a16'}
$headers02 = @{'Authorization' = 'token af71db42-9683-40b4-b615-d31c9e5f7a1'} # однозначно ошибочный токен
$headers03 = @{'Authorization' = 'token af71db42-9683-40b4-b615-d31c9e5f7a16'}
Делаем пример 01:
Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers01 –Verbose
Получим ошибку:
Specified value has invalid HTTP Header characters.
Parameter name: name
Делаем пример 02:
Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers02 –Verbose
Очевидно, тут в токене сознательно сделана ошибка, и результат:
The remote server returned an error: (403) Forbidden.
Делаем пример 03
Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers03 –Verbose
Результат:
VERBOSE: GET with 0-byte payload
Invoke-WebRequest : The remote server returned an error: (404) Not Found.
Ну … ладно. Оно, допустим, работает, но можно же было бы и вернуть «токен ОК, а дальше не знаем». Но ответ (404) Not Found - пугает.
Можно же было сделать пример для запроса «токен ок, запросите чего-то еще». Валидации токена не хватает. Или я не искал и не нашел. А он – есть.
Ты проверку токена видишь? И я не вижу
Методы для работы с данными пользователей
Поиск пользователей
GET admin/user?email={email}&username={userAlias}
Сделаю чуть меньше букв
$h04 = @{'Authorization' = 'token af71db42-9683-40b4-b615-d31c9e5f7a16'}
$Ad02 = 'http://192.168.21.61:8080/rest-api/admin/user'
iwr -Uri $Ad02 -Method 'GET' -Headers $h04 -Verbose
Ответ:
VERBOSE: GET with 0-byte payload
VERBOSE: received -1-byte response of content type application/hal+json
StatusCode : 200
StatusDescription :
Content : {123, 34, 95, 101...}
RawContent : HTTP/1.1 200
Если посмотреть чуть внимательнее, и сделать
$Ret01 = iwr -Uri $Ad02 -Method 'GET' -Headers $h04 -Verbose
И посмотреть $Ret01.RawContent, то мы увидим
{"_embedded":{"restUserAdminModelList":[{"id":"()","username":"adminuser","email":"adminuser@admin.local","name":"Admin user","surname": null,"fullName":"Admin user","avatar":"http://localhost:8080/static/image/avatar.jpg","cover":"http://localhost:8080/static/image/user-cover.png","confirmed":true}]},"page":{"size":10,"totalElements":1,"totalPages":1,"number":0}}
Стало быть, работает.
Получение настроек сервиса
GET /admin/settings
Запрос возвращает объект со всеми настройками сервиса.
Делаем:
$h04 = @{'Authorization' = 'token af71db42-9683-40b4-b615-d31c9e5f7a16'}
$Ad03 = 'http://192.168.21.61:8080/rest-api/admin/settings'
$Ret03 = iwr -Uri $Ad03 -Method 'GET' -Headers $h04 -Verbose
$Ret03.RawContent
Ответ содержит вполне понятный строчный объект, типа
{"disableLdapAuth":false,"disableSamlAuth":false,"disableOidcAuth":false, и так далее}
Уже неплохо. Наверное, его можно даже распарсить в какой-то объект, но это не является темой для статьи
Через curl тоже работает:
curl.exe --verbose --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03
Ключ --verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости
Так что в windows можно делать
$Ret032 = curl.exe --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03
В Linux все как-то не так.
head1='Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16
ad03='http://192.168.21.61:8080/rest-api/admin/settings'
echo $head1
echo $ad03
curl --header $head1 $ad03
Вот так мы не работает, нам видите ли токен не нравится. "status":403 и до свиданья
Зато вот так
curl --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $ad03
все работает. Причем кавычки я, конечно, проверил и одинарные и двойные, все равно что-то не идет токен через переменные.
Методы получения проектов
Получение списка публичных проектов
GET /project?q={title}
Делаем:
$Ad04 = 'http://192.168.21.61:8080/rest-api/project'
$Ret04 = iwr -Uri $Ad04 -Method 'GET' -Headers $h04 –Verbose
$Ret04.RawContent
Ответ несколько непредсказуем. Заголовок – есть, ответ StatusCode: 200 есть, а внутри – ничего нет. Ни массива, ничего. Потому что публичных проектов у меня нет. Хотя бы вернули 200, а не (404) Not Found.
Получение проекта по псевдониму
GET /project/{ownerAlias}/{projectAlias}
Запрос возвращает проект с указанным псевдонимом
Делаем:
$Ad05 = 'http://192.168.21.61:8080/rest-api/project/adminuser/mynewproject01/'
$Ret05 = iwr -Uri $Ad05 -Method 'GET' -Headers $h04 –Verbose
$Ret05.RawContent
Работает. Возвращает
{"id":"(какой-то)","title":"MyNewproject01","description":"","alias":"mynewproject01"," итд}
Метод для получения содержимого файла
GET /project/{ownerAlias}/{projectAlias}/blob?commitHash={commitHash}&file={fileName}
Запрос возвращает содержимое файла, который был изменен в указанном коммите, строкой. Если размер файла больше, чем 15МБ, или же он бинарный/картинка необходимо использовать следующий метод
commitHash. Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория
И как это понимать? Какой еще хеш коммита? Зачем ?
Сравните для Gitlab :
curl --header "PRIVATE-TOKEN: glpat-norDQhvwoTxyAtM9ANhV" http://192.168.1111.2222/api/v4/projects/2/repository/files/first.sh/raw?ref=main -o ot08.txt
И вот это. Какой еще коммит? Если мне надо не коммит, а всегда latest, то что?
Но, метод работает. Одна проблема, где взять хеш коммита. И вторая, как указать ветку, видимо по хешу. Очень странно.
С хешем просто. Его можно получить двумя способами.
Первый способ, простой. Нужно зайти в историю коммитов файла в GUI и справа будет 7 значный (почему 7 ?) номер коммита
Второй способ, чуть сложнее. Нужно ткнуть на RAW, откроется длинная ссылка вида
http://192.168.21.61:8080/project/adminuser/mynewproject01/blob/raw?file=myfile01&commit=9e12345(длинный хвост)
Первые 7 цифр в ID коммита – хеш. Остальное – даже не представляю, UUID какой-то.
Код
$Commi2 = '9e12345'
$Long4S08 = http://192.168.21.61:8080/rest-api/project/adminuser/mynewproject01/
$Ad08 = $Long4S08 + "blob?commitHash=" + $Commi2 + "&file=myfile01"
$Ret08 = iwr -Uri $Ad08 -Method 'GET' -Headers $h04 –Verbose
$Ret08.Content
И теперь то же самое для curl
curl.exe --verbose --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad08
--verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости
Метод для получения списка файлов
GET /project/{ownerAlias}/{projectAlias}/blob/recursive?commitHash={commitHash}&directory={directory}&depth={depth}Запрос возвращает список файлов с информацией о них, начиная с определенной папки и до определенной глубины. Папки не возвращаются.
Опять commitHash. Опять «Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория».
Заключение
Приложение работает, API работает.
Документация вызывает ряд вопросов, но их уже без меня пусть бывшие коллеги решают.
Получение файла и чего угодно вообще через хеш коммита, а не последней (текущей) версии файла выглядит крайне странно. Как и часть инструкции, где этот хеш коммита упомянут, а где его брать – нет.
Не очевидно оформляется токен, где не совсем понятно, как сделать read_repository_only
Как это будет работать с докером, ансиблом, и так далее – не проверял, и не хочу. Наверное, как-то работает.
PS.
Пока писал статью: оказалось что дело было не в бобине, и коллеги и сами справились. Просто у них опять кое-кто накрутил с сертификатами, проверками, и прочей безопасностью, и не сознавался.
Пока писал статью: программа набрала 10000000 очков в рейтинге - GitFlic признана лидером среди российских DevOps-платформ по версии CNews.
Литература
Для лиги лени: последнее обновление содержит патч от активно эксплуатируемой уязвимости
Если кто-то опять все пропустил, то вышли:
2025-11 Security Only Quality Update for Windows Server 2008 for x64-based Systems (KB5068909)
2025-11 Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems (KB5068904)
2025-11 Security Monthly Quality Rollup for Windows Server 2012 for x64-based Systems (KB5068907)
2025-11 Security Monthly Quality Rollup for Windows Server 2012 R2 for x64-based Systems (KB5068905)
2025-11 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5068864)
2025-11 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5068791)
2025-11 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5068787) (это вроде MS server 2022)
2025-11 Cumulative Update for Microsoft server operating system version 23H2 for x64-based Systems (KB5068779)
2025-11 Cumulative Update for Microsoft server operating system version 24H2 for x64-based Systems (KB5068861) (26100.7171)
Да, даже для 2008 выходят обновления.
Учитывая, что MS реализовала Windows 11 25h2 и Windows 11 26H1, то путаница «что куда» будет продолжаться.
Мой тестовый Windows server 2025 24 h2 до обновлений был 10.0.26100.6584 (с патчем KB5065426).
Обновление (для 2025 сервера) - windows11.0-kb5068861-x64_acc4fe9c928835c0d44cdc0419d1867dbd2b62b2.msu , размером 3568349734,
MD5 AEB8B0FB094F2452084C5E32D77C3047,
SHA256 C2E317DB8A422A52C966B685B3B33FCFAF11867B6913EBB8A757C817644690EB, ставится, как обычно, 100 лет.
После обновления KB5068861:
Для 2025 сервера Microsoft Windows [Version 10.0.26100.7171]
Для windows 11 25h2 Microsoft Windows [Version 10.0.26200.7171]
Согласно статье на bleepingcomputer, обновлений более чем достаточно, но главное, что к одному из исправленных багов есть эксплойт, и баг на 9.8 из 10
Microsoft lists one bug under active attack, but none are publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug under active attack:
- CVE-2025-62215 - Windows Kernel Elevation of Privilege Vulnerability
This is the bug currently under exploit
The November 2025 Security Update Review
Заключение
Кто не обновился – сам виноват.
PS. Наверное, опять AD 2025 сломали. Каждый раз ломают.
