Трассировка TCP
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
Для получение большей информации используйте запуск с ключом -?
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
tcptraceroute ya.ru 443
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
tcproute ya.ru 443
Для получение большей информации используйте запуск с ключом -?
👍19❤1
Что такое Azure Stack HCI и почему это вам не нужно
По мере того, как тикают часы и последней версии бесплатного Hyper-V Server 2019 остаются считанные годы до окончания поддержки (в 2029 году) возникает все больше и больше вопросов – как же жить дальше?
И вот уже не один человек спросил меня про Azure Stack HCI, во многом благодаря ряду статей на Хабре, на наш взгляд – вредных, поэтому ссылки не приводим, кому надо – сами найдут.
Если подходить к вопросу поверхностно, то кажется, что перед нами аналог бесплатного Hyper-V Server – активация не нужна, в основе тот же Windows Core, а для кого это большая проблема, то там и GUI прикрутить можно.
Но отсутствие требования активации еще не означает правомерного использования, лицензирование данной системы подразумевает подписную модель (примерно $10 за ядро в месяц) и обязательное требование хотя бы один раз в 30 дней связаться с Azure Arc.
Последнее легко лечится патчами, но, по сути, это ничем не отличается от «активации» через «левые KMS» или MAS. Тем более, что Azure Stack HCI нет долгосрочных версии, новые сборки ОС выходят каждый год.
Фактически с этим подходом вы будете сидеть на пороховой бочке, сделаю ли «энтузиасты» патч или устанут, вам легче не станет, инфраструктура ваша, вам с ней жить и вам нести за нее ответственность.
И вообще, Azure Stack HCI, это последнее, что стоит тащить в локальную инфраструктуру, но кроме случаев, когда вы активно пользуетесь Azure и вам требуется развернуть ряд возможностей локально.
А как быть остальным? А тут есть только два сценария:
🔸 У вас основная нагрузка – это системы Windows Server, современная система лицензирования завязана на ядра хостовой машины и не важно, что там, Hyper-V или Proxmox.
Если ваш экземпляр Windows Server просто обслуживает виртуальные машины с ролью Hyper-V, то все свои лицензии он передает виртуалкам, т.е. обходится вам бесплатно.
Поэтому если у вас основная рабочая нагрузка Windows – то лицензирование хоста виртуализации погоды не делает, так, на сдачу. Если же у вас там Linux, то зачем вам Hyper-V.
🔸 Если же основная нагрузка – Linux, то смело переходим на Proxmox, родная среда в родной среде, плюс доступны LXC-контейнеры.
Поэтому в целом никакой беды от прекращения поддержки бесплатного Hyper-V нет, в Windows-мире вам даже не потребуются дополнительные лицензии, а в Linux вам проще перейти на родные средства виртуализации и контейнеризации.
По мере того, как тикают часы и последней версии бесплатного Hyper-V Server 2019 остаются считанные годы до окончания поддержки (в 2029 году) возникает все больше и больше вопросов – как же жить дальше?
И вот уже не один человек спросил меня про Azure Stack HCI, во многом благодаря ряду статей на Хабре, на наш взгляд – вредных, поэтому ссылки не приводим, кому надо – сами найдут.
Если подходить к вопросу поверхностно, то кажется, что перед нами аналог бесплатного Hyper-V Server – активация не нужна, в основе тот же Windows Core, а для кого это большая проблема, то там и GUI прикрутить можно.
Но отсутствие требования активации еще не означает правомерного использования, лицензирование данной системы подразумевает подписную модель (примерно $10 за ядро в месяц) и обязательное требование хотя бы один раз в 30 дней связаться с Azure Arc.
Последнее легко лечится патчами, но, по сути, это ничем не отличается от «активации» через «левые KMS» или MAS. Тем более, что Azure Stack HCI нет долгосрочных версии, новые сборки ОС выходят каждый год.
Фактически с этим подходом вы будете сидеть на пороховой бочке, сделаю ли «энтузиасты» патч или устанут, вам легче не станет, инфраструктура ваша, вам с ней жить и вам нести за нее ответственность.
И вообще, Azure Stack HCI, это последнее, что стоит тащить в локальную инфраструктуру, но кроме случаев, когда вы активно пользуетесь Azure и вам требуется развернуть ряд возможностей локально.
А как быть остальным? А тут есть только два сценария:
🔸 У вас основная нагрузка – это системы Windows Server, современная система лицензирования завязана на ядра хостовой машины и не важно, что там, Hyper-V или Proxmox.
Если ваш экземпляр Windows Server просто обслуживает виртуальные машины с ролью Hyper-V, то все свои лицензии он передает виртуалкам, т.е. обходится вам бесплатно.
Поэтому если у вас основная рабочая нагрузка Windows – то лицензирование хоста виртуализации погоды не делает, так, на сдачу. Если же у вас там Linux, то зачем вам Hyper-V.
🔸 Если же основная нагрузка – Linux, то смело переходим на Proxmox, родная среда в родной среде, плюс доступны LXC-контейнеры.
Поэтому в целом никакой беды от прекращения поддержки бесплатного Hyper-V нет, в Windows-мире вам даже не потребуются дополнительные лицензии, а в Linux вам проще перейти на родные средства виртуализации и контейнеризации.
👍12❤2
Ошибка: Не удалось записать RSA сертификат. Попробуйте еще раз
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
java.security.KeyStoreException: invalid KeyStore state: found 3 private keys sharing
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
👍14
САП "Клавдий" - архивация электронной почты для организаций любого масштаба!
• сбор писем с почтовых серверов, архивов и из SMTP-трафика
• поиск по письмам и вложениям
• дедупликация и сжатие
• доступ к архивной почте через веб или любой почтовый клиент
• кластеризация и хранилище с настраиваемой длительностью хранения
• бесплатная версия до 50 почтовых ящиков
САП "Клавдий" - решение для тех, у кого:
• почтовый сервер, который задыхается от старых писем
• возникает необходимость найти и восстановить старое письмо
• есть кладбище PST-файлов и почтовых ящиков уволенных сотрудников
• есть обязательство сохранять всю переписку за несколько лет
• планируется переезд на другой почтовый сервер
• ограниченный бюджет на решение этих проблем
Подключайтесь к онлайн-демо.
Среда, 16 сентября, в 12:00 по Москве.
Ссылка для регистрации: Регистрация на вебинар
Также подключайтесь к нашему тг-каналу: Ссылка на канал
#реклама
О рекламодателе
• сбор писем с почтовых серверов, архивов и из SMTP-трафика
• поиск по письмам и вложениям
• дедупликация и сжатие
• доступ к архивной почте через веб или любой почтовый клиент
• кластеризация и хранилище с настраиваемой длительностью хранения
• бесплатная версия до 50 почтовых ящиков
САП "Клавдий" - решение для тех, у кого:
• почтовый сервер, который задыхается от старых писем
• возникает необходимость найти и восстановить старое письмо
• есть кладбище PST-файлов и почтовых ящиков уволенных сотрудников
• есть обязательство сохранять всю переписку за несколько лет
• планируется переезд на другой почтовый сервер
• ограниченный бюджет на решение этих проблем
Подключайтесь к онлайн-демо.
Среда, 16 сентября, в 12:00 по Москве.
Ссылка для регистрации: Регистрация на вебинар
Также подключайтесь к нашему тг-каналу: Ссылка на канал
#реклама
О рекламодателе
👀4👍1
Спрашивают - отвечаем
хотелось бы узнать у матёрых спецов куда и как правильно бэкапить? Вопрос от малого бизнеса и частных лиц.
Начнем с того, что бекап – это не просто «бери больше – кидай дальше», а целый комплекс мероприятий. Мы об этом уже писали, напомним еще раз: https://interface31.ru/post/kak-pravil-no-organizovat-rezervnoe-kopirovanie-i-spat-spokoyno/
1️⃣ Если коротко. Самый первый бекап должен быть в "шаговой доступности", в формате позволяющем наиболее быстро восстановиться из него и, желательно, без сжатия. Можно, вопреки мемам, хранить на том же самом сервере.
2️⃣ Второй бекап тоже недалеко, но на другом узле и, крайне желательно, в другом физическом месте, вторая серверная или просто где-то на территории, но в другом корпусе. На случай физического выхода из строя основного узла, пожара, затопления и т.д.
3️⃣ Третья копия - в удаленной локации. Облако, NAS дома в чулане и т.д. Это на случай, когда все плохо и первые два бекапа недоступны или уничтожены. Чаще всего они вам не понадобятся, но иметь такую копию нужно.
👆 А теперь о том, чего делать не надо.
Не следует слушать "специалистов", которые любят бросаться фразами: "это не бекап", "это неправильные бекапы" и т.д. и т.п. Любой бекап является правильным, если выполняет свою задачу.
А какая задача бекапа? Быстро восстановить рабочую копию данных. При этом стоимость бекапа (а все имеет свою стоимость) не должна превышать стоимость ущерба от потери рабочей копии данных. Грубо говоря, тратить 1000 руб. на замок, чтобы закрыть лопату за 100 руб. - занятие лишенное всякого смысла.
Поэтому копируйте как вам угодно и куда сочтете нужным. Главное - чтобы копии были. Ну и не забывайте их проверять.
❗️ И еще. Не путайте бекапы с архивами. У них разное назначение и архивы тоже нужно бекапить!
хотелось бы узнать у матёрых спецов куда и как правильно бэкапить? Вопрос от малого бизнеса и частных лиц.
Начнем с того, что бекап – это не просто «бери больше – кидай дальше», а целый комплекс мероприятий. Мы об этом уже писали, напомним еще раз: https://interface31.ru/post/kak-pravil-no-organizovat-rezervnoe-kopirovanie-i-spat-spokoyno/
1️⃣ Если коротко. Самый первый бекап должен быть в "шаговой доступности", в формате позволяющем наиболее быстро восстановиться из него и, желательно, без сжатия. Можно, вопреки мемам, хранить на том же самом сервере.
2️⃣ Второй бекап тоже недалеко, но на другом узле и, крайне желательно, в другом физическом месте, вторая серверная или просто где-то на территории, но в другом корпусе. На случай физического выхода из строя основного узла, пожара, затопления и т.д.
3️⃣ Третья копия - в удаленной локации. Облако, NAS дома в чулане и т.д. Это на случай, когда все плохо и первые два бекапа недоступны или уничтожены. Чаще всего они вам не понадобятся, но иметь такую копию нужно.
👆 А теперь о том, чего делать не надо.
Не следует слушать "специалистов", которые любят бросаться фразами: "это не бекап", "это неправильные бекапы" и т.д. и т.п. Любой бекап является правильным, если выполняет свою задачу.
А какая задача бекапа? Быстро восстановить рабочую копию данных. При этом стоимость бекапа (а все имеет свою стоимость) не должна превышать стоимость ущерба от потери рабочей копии данных. Грубо говоря, тратить 1000 руб. на замок, чтобы закрыть лопату за 100 руб. - занятие лишенное всякого смысла.
Поэтому копируйте как вам угодно и куда сочтете нужным. Главное - чтобы копии были. Ну и не забывайте их проверять.
❗️ И еще. Не путайте бекапы с архивами. У них разное назначение и архивы тоже нужно бекапить!
👍20🔥2❤1
22 октября встречаемся в Москве: Kuber Conf уже совсем скоро!
Что будет на конференции:
– доклады про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру;
– обсуждение Service Mesh, безопасности и экономики платформ;
– темы про bare metal, железо и инфраструктуру ЦОДов;
– активности партнеров и общение с участниками.
После основной программы можно будет продолжить общение на афтепати, познакомиться с коллегами из индустрии и обсудить конференцию уже в более неформальной обстановке!
📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 11:00–19:00
Кстати, после 15 сентября стоимость участия вырастет, так что сейчас самое время присмотреть билет и добавить конференцию в календарь 🔥
А если вы хотите выступить на Kuber Conf, до 15 сентября можно подать заявку на доклад и поделиться с Kubernetes-сообществом своими кейсами и опытом.
👉 Программа, билеты и подробности – на сайте Kuber Conf от АОТ!
Что будет на конференции:
– доклады про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру;
– обсуждение Service Mesh, безопасности и экономики платформ;
– темы про bare metal, железо и инфраструктуру ЦОДов;
– активности партнеров и общение с участниками.
После основной программы можно будет продолжить общение на афтепати, познакомиться с коллегами из индустрии и обсудить конференцию уже в более неформальной обстановке!
📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 11:00–19:00
Кстати, после 15 сентября стоимость участия вырастет, так что сейчас самое время присмотреть билет и добавить конференцию в календарь 🔥
А если вы хотите выступить на Kuber Conf, до 15 сентября можно подать заявку на доклад и поделиться с Kubernetes-сообществом своими кейсами и опытом.
👉 Программа, билеты и подробности – на сайте Kuber Conf от АОТ!
👍1
Гладко было на бумаге, но забыли про овраги...
Про то, что резервные копии нужно не только делать, но и регулярно проверять, вроде бы знают все.
Но одной лишь проверки архивов абсолютно недостаточно для нормального восстановления в аварийной ситуации. Чтобы оценить реальные возможности инфраструктуры и людей, рекомендуется проводить учения — стресс-тесты по подъему сервисов, максимально приближенные к реальности.
Некоторое время назад одни мои коллеги такие учения провели. И с треском их провалили. Причины оказались поучительными и весьма далекими от высоких технологий.
По сценарию учения стартовали во второй половине дня субботы, когда на предприятии остался только линейный персонал. Руководство отсутствует, начальник IT-отдела «в отпуске» (доступен только по телефону).
Оборудование подготовили заранее: сымитировали отказ дискового массива с частичным повреждением данных. Дежурные сотрудники про учения знали, но без деталей — им предстояло самостоятельно диагностировать сбой и поднять тестовую копию сервиса.
И тут начался реальный мир:
1️⃣ Физический доступ в серверную. Ключ от серверной оказался заперт в кабинете начальника охраны, а сам кабинет — опечатан. Начальник службы безопасности к этому моменту уже благополучно добрался до дачи и успел принять рюмочку.
Узнав, что тревога учебная, срываться обратно в город он наотрез отказался. В итоге начальник IT был вынужден лично приехать в офис и вместе с присутствующими менеджерами составлять комиссионный акт, вскрывать опечатанную дверь и добывать ключ.
2️⃣ ЗИП под замком. Когда в серверную наконец прорвались, выяснилось: резервные диски и комплектующие лежат на складе. Склад на выходных закрыт, а материально ответственные лица отдыхают. Вскрывать склад даже коллективно под акт желающих не нашлось: дураков нет.
3️⃣ План «Б» и высота. Родилась идея: в цеху висит ненагруженный сервисный NAS, с которого можно безболезненно сдернуть рабочий донорский диск. Побежали в цех. Но телекоммуникационный шкаф смонтирован под самым потолком — снизу руками не дотянуться, нужна стремянка. А где заперта стремянка? Правильно, на том же самом складе…
На этом этапе учения признали официально проваленными. После чего техническое руководство и топ-менеджмент дружно сели думать над жизнью.
Понятно, что при реальной катастрофе и склад бы разнесли, и замок с печатью срезали. Но аварийный регламент не должен держаться на выбивании дверей фомкой.
Доступ к первичным точкам отказа, аварийный ЗИП «первой линии» и банальный инструмент обязаны быть доступны дежурной смене круглосуточно — без звонков на дачи нетрезвым начальникам охраны.
Про то, что резервные копии нужно не только делать, но и регулярно проверять, вроде бы знают все.
Но одной лишь проверки архивов абсолютно недостаточно для нормального восстановления в аварийной ситуации. Чтобы оценить реальные возможности инфраструктуры и людей, рекомендуется проводить учения — стресс-тесты по подъему сервисов, максимально приближенные к реальности.
Некоторое время назад одни мои коллеги такие учения провели. И с треском их провалили. Причины оказались поучительными и весьма далекими от высоких технологий.
По сценарию учения стартовали во второй половине дня субботы, когда на предприятии остался только линейный персонал. Руководство отсутствует, начальник IT-отдела «в отпуске» (доступен только по телефону).
Оборудование подготовили заранее: сымитировали отказ дискового массива с частичным повреждением данных. Дежурные сотрудники про учения знали, но без деталей — им предстояло самостоятельно диагностировать сбой и поднять тестовую копию сервиса.
И тут начался реальный мир:
1️⃣ Физический доступ в серверную. Ключ от серверной оказался заперт в кабинете начальника охраны, а сам кабинет — опечатан. Начальник службы безопасности к этому моменту уже благополучно добрался до дачи и успел принять рюмочку.
Узнав, что тревога учебная, срываться обратно в город он наотрез отказался. В итоге начальник IT был вынужден лично приехать в офис и вместе с присутствующими менеджерами составлять комиссионный акт, вскрывать опечатанную дверь и добывать ключ.
2️⃣ ЗИП под замком. Когда в серверную наконец прорвались, выяснилось: резервные диски и комплектующие лежат на складе. Склад на выходных закрыт, а материально ответственные лица отдыхают. Вскрывать склад даже коллективно под акт желающих не нашлось: дураков нет.
3️⃣ План «Б» и высота. Родилась идея: в цеху висит ненагруженный сервисный NAS, с которого можно безболезненно сдернуть рабочий донорский диск. Побежали в цех. Но телекоммуникационный шкаф смонтирован под самым потолком — снизу руками не дотянуться, нужна стремянка. А где заперта стремянка? Правильно, на том же самом складе…
На этом этапе учения признали официально проваленными. После чего техническое руководство и топ-менеджмент дружно сели думать над жизнью.
Понятно, что при реальной катастрофе и склад бы разнесли, и замок с печатью срезали. Но аварийный регламент не должен держаться на выбивании дверей фомкой.
Доступ к первичным точкам отказа, аварийный ЗИП «первой линии» и банальный инструмент обязаны быть доступны дежурной смене круглосуточно — без звонков на дачи нетрезвым начальникам охраны.
💯18❤5🤡5👀4👍1
Бесплатный PAM, который уже используют в крупных компаниях!
Jumpserver PAM -- для компаний любых масштабов.
Бесплатная версия с открытым исходным кодом закрывает большинство задач для наведения порядка в сети и безопасного доступа специалистов и подрядчиков к серверам и сервисам.
Для расширенных сценариев есть платная редакция с дополнительными возможностями и поддержкой на русском языке.
JumpServer PAM это:
• Контроль доступа к RDP, SSH, веб-интерфейсам и СУБД
• Фильтрация SQL-запросов и SSH-команд
• Подробный журнал действий
• Встроенный 2FA
• Масштабирование и надёжная кластеризация
• Установка одной командой
Познакомьтесь с JumpServer PAM на вебинаре 17 сентября в 12:00 по Москве
Регистрируйтесь по ссылке: Регистрация на вебинар
И присоединяйтесь к сообществу пользователей (ссылка на телеграм-канал):
• Инструкции и документация
• Кейсы внедрения
• Лучшие практики и рецепты
• Чат с нашими экспертами
#реклама
О рекламодателе
Jumpserver PAM -- для компаний любых масштабов.
Бесплатная версия с открытым исходным кодом закрывает большинство задач для наведения порядка в сети и безопасного доступа специалистов и подрядчиков к серверам и сервисам.
Для расширенных сценариев есть платная редакция с дополнительными возможностями и поддержкой на русском языке.
JumpServer PAM это:
• Контроль доступа к RDP, SSH, веб-интерфейсам и СУБД
• Фильтрация SQL-запросов и SSH-команд
• Подробный журнал действий
• Встроенный 2FA
• Масштабирование и надёжная кластеризация
• Установка одной командой
Познакомьтесь с JumpServer PAM на вебинаре 17 сентября в 12:00 по Москве
Регистрируйтесь по ссылке: Регистрация на вебинар
И присоединяйтесь к сообществу пользователей (ссылка на телеграм-канал):
• Инструкции и документация
• Кейсы внедрения
• Лучшие практики и рецепты
• Чат с нашими экспертами
#реклама
О рекламодателе
Окончание поддержки WinBox 3
WinBox 3 – привычный и удобный инструмент для множества администраторов Mikrotik, особенно старой закалки. Для многих он стал продолжением мышки, где все привычно до уровня мышечной памяти и многие вещи делались не задумываясь, на автомате.
И вот эта эпоха подходит к концу, компания производитель сообщила, что начиная с версии RouterOS 7.25 минимально поддерживаемой версией станет WinBox 4.3.
Если говорить про WinBox 4, в общем и целом, то ничего плохого, кроме багов первых версий, сказать нельзя. Инструмент как инструмент, теперь еще и кроссплатформенный, нативно поддерживающий Linux и macOS.
Но фактически это совершенно другая программа, полностью переписанная, с другим управлением и другим поведением интерфейса, хоть и сделанная внешне похожей на старый WinBox.
Интерфейс полностью унифицирован с веб-версией и теперь, если вы зайдете в веб-интерфейс, то увидите там тот же самый WinBox 4, возможно это и хорошо, но только для тех, кто сразу придет на этот интерфейс и будет учить его с нуля.
Остальных ждут забавные квесты по поиску привычных инструментов и различные крайне неприятные «фокусы». Все привыкли, что функции New и Remove шли первыми и обозначались как плюс и минус, а за ними шли Enable и Disable в виде галочки и крестика. Теперь у нас порядок иной New, Enable и Disable, а только потом Remove, как раз с крестиком.
И таких моментов хватает. Но и производителя тоже можно понять – вечно тащить старое «легаси» невозможно. Поэтому, нравится или нет, переходить на новый WinBox придется. Но при этом помнить – это не обновленная версия старого WinBox, а просто похожая на него совершенно новая программа.
WinBox 3 – привычный и удобный инструмент для множества администраторов Mikrotik, особенно старой закалки. Для многих он стал продолжением мышки, где все привычно до уровня мышечной памяти и многие вещи делались не задумываясь, на автомате.
И вот эта эпоха подходит к концу, компания производитель сообщила, что начиная с версии RouterOS 7.25 минимально поддерживаемой версией станет WinBox 4.3.
Если говорить про WinBox 4, в общем и целом, то ничего плохого, кроме багов первых версий, сказать нельзя. Инструмент как инструмент, теперь еще и кроссплатформенный, нативно поддерживающий Linux и macOS.
Но фактически это совершенно другая программа, полностью переписанная, с другим управлением и другим поведением интерфейса, хоть и сделанная внешне похожей на старый WinBox.
Интерфейс полностью унифицирован с веб-версией и теперь, если вы зайдете в веб-интерфейс, то увидите там тот же самый WinBox 4, возможно это и хорошо, но только для тех, кто сразу придет на этот интерфейс и будет учить его с нуля.
Остальных ждут забавные квесты по поиску привычных инструментов и различные крайне неприятные «фокусы». Все привыкли, что функции New и Remove шли первыми и обозначались как плюс и минус, а за ними шли Enable и Disable в виде галочки и крестика. Теперь у нас порядок иной New, Enable и Disable, а только потом Remove, как раз с крестиком.
И таких моментов хватает. Но и производителя тоже можно понять – вечно тащить старое «легаси» невозможно. Поэтому, нравится или нет, переходить на новый WinBox придется. Но при этом помнить – это не обновленная версия старого WinBox, а просто похожая на него совершенно новая программа.
😢10👍4💯2🫡2
Почему vector — не совсем vector?
Что происходит с Python, когда вызывается C++?
Разбираю C++, Backend, Performance и ML через реальные инженерные проблемы.
⚙️ Меньше теории. Больше того, что происходит внутри.
👉 C++ & ML | Backend to AI
Что происходит с Python, когда вызывается C++?
Разбираю C++, Backend, Performance и ML через реальные инженерные проблемы.
⚙️ Меньше теории. Больше того, что происходит внутри.
👉 C++ & ML | Backend to AI