Обновить
3

Пользователь

0,2
Рейтинг
Отправить сообщение

Как-то не хорошо получается.
В заголовке про Рутокен. А в статье только реклама следующей части.

Вот только ЭП будут на разные ФИО/ИП. Вот какое в ФИО/ИП в карточке клиента совпадет - тот и владелец "тапок".

А если по занудствовать, то вообще окажется, что вокруг Тринклер-моторы. Ибо Дизель изобрел форкамерный двигатель. И оригинальный цикл Дизеля, отличается от обще употребимого цикла дизельного двигателя.

Использовали в лондонском метро.

А как вам задача про двух пешеходов которые по расчету сближаются со скоростью более 100 км/ч? И ведь формально правильно. А то что с нулями в задачнике опечатка, то студента формально не интересует. Усэйн Болт, со своими 45км/ч, просто в пролете.
С появлением ML/LLM это просто мультиплицируется.

ЕМНИП есть нюансы. Ключ должен быть создан самим Рутокен. А не импортирован, как контейнер из Крипто ПРО.

Возможно, опять за 15 лет, что-то пересмотрели в ITIL... (Хотя в ITIL V4 радикальных изменений от V3 вроде нет)...
Но раньше ITIL был о методологических практиках, а не о конкретных технологиях и тем более продуктах.
Без git, CI/CD и тем более AI, компании вполне соответствовали необходимым ITIL V2/V3 уровням даже 20 лет назад.
К сожалению складывается практика, как с DevOps, что все выливается в погоню за модными продуктами. На примере повсеместного запихивания k8s в любой проект, из одного nginx, с десятком полу статических страниц. Вместо понимания и внедрения целостной методологии.

"Миграция с VMware в 2026. Архитектурное сравнение альтернатив"
Я так понимаю это была вводная часть цикла статей?
Когда будет продолжение об "архитектурном сравнении альтернатив"?

Наймите нашего лучшего аутсорсера (ChatGPT, etc...) и, при необходимости передайте ему весь свой опыт и знание, за свой счет. А потом мы продадим его вашим конкурентам.
Если "коллега" выдал слабую работу в очередной раз, то его скорее заменят более подходящим по уровню, чем будут бесплатно, вне рабочего времени, подтягивать до необходимого уровня.

ИМХО. За правку системного sshd_config хочется уже руки отрывать. Есть отдельный каталог sshd_config.d для своих настроек.
Перед самым новым годом дважды пришлось спасать использующих эту старую пагубную практику.
Для "спокойствия" за безопасность на долгих новогодних праздниках они сделали обновления серверов. С которыми прилетели "обновленные" sshd_config. И они потеряли удаленный доступ к системам.

Спасибо за статью. Она с подвигла меня наконец немного разобраться в текущих возможностях "зоопарка" ПО и творящегося "цирка".

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

Когда надо подключить домашние тестовые виртуалки, или старый телевизор в youtube, то все становится как-то печально. Из-за невозможности запуска на них "однокнопочных" графических клиентов до VPS.

Моя практическая сборка для дома оказалась значительно проще.
1) Голый Xray, в режиме клиента, на домашнем Linux маршрутизаторе. Можно обойтись и железным маршрутизатором с OpenWRT.
2) VPS, с 3x-ui. Пришлось по выбирать не забаненные за нарушения ip адреса у хостера.

Xray умеет быть socks (и другими видами) прокси. В него можно завернуть хоть весь трафик правилами nftables.
Так же можно настроить правила по geoip, или фильтрацию по доменам. Но на клиенте я этого делать не стал.
На стационаром ПК использую браузер с несколькими профилями. Один из которых идет в интернет через socks на Xray, в домашнем маршрутизаторе.

"Фильтрации" доменов в собственной голове я доверяю больше. Могу читать недоступные по geoip статьи на данном ресурсе и на многих других. Достаточно просто открыть второе окно браузера, с другим профилем через socks. Тогда сайт решит, что браузер из далекой Германии.

P.S. Хорошо, что open source пока доступен на github и там есть актуальная документация. Т.к. перепечатываемые руководства, с картинками, очень часто неактуальны для текущих реализаций.

Если статья для новичков, то наверное будет правильно рекомендовать им изучать что-то актуальное и свежее.
1) Зачем ставить и изучать ufw, если на Debian 12-13 уже работает nftables?
2) Зачем рекомендовать генерацию rsa ключей, если широко распространены более компактные ed25519?
3) Зачем править системный sshd_config, если в системе специально есть целый каталог sshd_config.d, для пользовательских изменений? А еще sshd_config может по недосмотру затереться настройками "по умолчанию" при обновлении системы.
4) KbdInteractiveAuthentication no надо добавить, иначе парольная аутентификация продолжит работать.
5) Неплохо бы проверить IPv6 на VPS. А то VPS может оказаться доступна всем.
6) Работа из под root пользователя не самая лучшая рекомендация для начинающего.

Это всегда было только про деньги.

Возможно я ошибаюсь, но с 2022 все Windows, не купленные и не активированные в составе с ПК, уже нелицензионные/контрафактные.
Официально MS ничего не продает в России. Старые контракты SA уже закончились (ЕМНИП контракты до трех лет). Все корп и ентерпрайз редакции не разрешалось использовать без действующего SA контракта.
Но возможно что-то и поменялось в лицензионной политике MS после пандемии.

Осталось дождаться открытого аукциона, со свободными ставками на машину?
Или регуляторы это не разрешат?

Это в первую очередь определяется наличием бухгалтерских документов.

Вот была статья: https://habr.com/ru/articles/320278/
Ей уже почти 9 лет! Но мы продолжаем тащить legacy из системы в систему.
Вот еще статья: https://habr.com/ru/companies/ruvds/articles/580648/
Ей уже 4 года!

Возможно я "альтернативный" ретроград... Но повторю опять:
1. Зачем тащить iptables, ufw, net-tools в ситему 2025 года?
2. Зачем портить sshd.config, если есть целая директория sshd_config.d для кастомизации?
3. Почему используете
PasswordAuthentication no
PermitRootLogin no

но не добавляете
KbdInteractiveAuthentication no
4. Зачем неконтролируемый автоапдейт на удаленном сервере? Можно нежданно получить или автозамену конфигов, или обновленные сервисы, которым не понравятся старые конфиги. Тривиально, какие-то опции ушли в deprecated, или отменены.

Вы абсолютно правы. Но я говорил о процессорных ядрах. И о том, что один rphost не выходит далее одной NUMA-ноды. Что при высокопроизводительной настройке сервера равно одному физическому процессору.
ЕМНИП одна база не работает сразу с несколькими rphost.
На вскидку нашел https://its.1c.ru/db/metod8dev/content/5903/hdoc
И по докладам Антона Дорошкевича запомнил рекомендацию, что rphost должно быть в два раза больше, чем NUMA нод.

Возможно я ошибаюсь. Вы предлагаете на типовом двух-четырех процессорном сервере включить Node Interleaving? (С другими способами объединения памяти для всех процессоров не встречался). Но тогда можно на 30%-40% получить падения производительности из-за задержек операций с памятью.

Информация

В рейтинге
2 740-й
Зарегистрирован
Активность

Специализация

DevOps-инженер