Ваш Linux – это черный экран и консоль, а то ли дело…
Да, то ли дело… Третьего дня выяснилось, что сразу на нескольких точках поломался Диспетчер служб IIS, это такая специальная графическая оснастка, позволяющая рулить веб-сервером мышкой, в непринужденной и расслабленной обстановке.
Именно графические инструменты являются «железобетонным» аргументом для многих Windows администраторов. Мол у нас все для человека, все понятно и дружелюбно, а не то, что эти ваши черные экраны.
Ладно, поверим, ну не может же быть что сломалось совсем и навсегда. Смотрим логи, ясности они не добавляют, но становится ясно что сломалось что-то в сборке ASP.NET…
А зачем нам эта ASP.NET? Нам тут только 1С опубликовать, да присматривать за ней время от времени.
Но назвался груздем – полезай в кузов. Проверили то, проверили это, восстановили, перерегистрировали – толку ноль.
Для человека знакомого с Linux это даже как-то дико становится. Система живет своей жизнью, чего ей надо – непонятно, на заклинания не реагирует…
Что там дальше советуют? Переустановить IIS, ну да иного мы и не ожидали, классика же…
Хотя погодите, а зачем его переустанавливать? Он же работает, сломался только диспетчер – инструмент по управлению. И все, что этот диспетчер делает – это изменения текстовых конфигурационных файлов. Да, IIS точно также использует текстовые конфиги.
Ну и нафига нам тогда диспетчер? Открываем старую добрую консоль, только разве что вместо черного окно тут может оказаться синим. Но принципиальной разницы нет.
И все прекрасно работает, настраивается, изменяется, перезапускается. Надо только немного вникнуть и разобраться.
Кстати, эта тенденция в Windows прослеживается уже достаточно давно и плотно. Попробуйте найти инструкцию по установке последних версий Exchange, думаете там Next-Next-Finish?
Не угадали, там будут некие заклинания белыми буквами по синему экрану. И никакого тыканья мышкой в кнопочки.
В целом администрирование вернулось к тому, от чего ушло (а в мире Linux никогда и не уходило) – командной строке и простым текстовым интерфейсам.
Да, Windows все еще остается системой, ориентированной на графику, но уже сегодня возможно то, что было немыслимым лет 20 назад – полноценное администрирование системы без графической оболочки, в т.ч. и удаленное.
Сегодня мы можем привычно подключиться через SSH, запустить PowerShell и спокойно работать. Хотя «привычно» — это не про традиционных Windows администраторов. К сожалению, многие из них остались в далеких и светлых нулевых и искренне считают, что «в ролях Windows Server ничего принципиально не изменилось».
На самом деле мир давно стал другим, равно как стал другим и Windows и для нормальной конкуренции нужно выходить из привычного комфорта графики и погружаться в суровую среду консоли.
Но суровая она только на первый взгляд. Когда вы поймете, что текстовый интерфейс предоставляет такие же, а то и более богатые возможности, но при этом гораздо более послушен чем графика вам не захочется в нее возвращаться.
А потом, может быть, и полностью откажетесь от графического окружения на своем Windows Server.
Да, то ли дело… Третьего дня выяснилось, что сразу на нескольких точках поломался Диспетчер служб IIS, это такая специальная графическая оснастка, позволяющая рулить веб-сервером мышкой, в непринужденной и расслабленной обстановке.
Именно графические инструменты являются «железобетонным» аргументом для многих Windows администраторов. Мол у нас все для человека, все понятно и дружелюбно, а не то, что эти ваши черные экраны.
Ладно, поверим, ну не может же быть что сломалось совсем и навсегда. Смотрим логи, ясности они не добавляют, но становится ясно что сломалось что-то в сборке ASP.NET…
А зачем нам эта ASP.NET? Нам тут только 1С опубликовать, да присматривать за ней время от времени.
Но назвался груздем – полезай в кузов. Проверили то, проверили это, восстановили, перерегистрировали – толку ноль.
Для человека знакомого с Linux это даже как-то дико становится. Система живет своей жизнью, чего ей надо – непонятно, на заклинания не реагирует…
Что там дальше советуют? Переустановить IIS, ну да иного мы и не ожидали, классика же…
Хотя погодите, а зачем его переустанавливать? Он же работает, сломался только диспетчер – инструмент по управлению. И все, что этот диспетчер делает – это изменения текстовых конфигурационных файлов. Да, IIS точно также использует текстовые конфиги.
Ну и нафига нам тогда диспетчер? Открываем старую добрую консоль, только разве что вместо черного окно тут может оказаться синим. Но принципиальной разницы нет.
И все прекрасно работает, настраивается, изменяется, перезапускается. Надо только немного вникнуть и разобраться.
Кстати, эта тенденция в Windows прослеживается уже достаточно давно и плотно. Попробуйте найти инструкцию по установке последних версий Exchange, думаете там Next-Next-Finish?
Не угадали, там будут некие заклинания белыми буквами по синему экрану. И никакого тыканья мышкой в кнопочки.
В целом администрирование вернулось к тому, от чего ушло (а в мире Linux никогда и не уходило) – командной строке и простым текстовым интерфейсам.
Да, Windows все еще остается системой, ориентированной на графику, но уже сегодня возможно то, что было немыслимым лет 20 назад – полноценное администрирование системы без графической оболочки, в т.ч. и удаленное.
Сегодня мы можем привычно подключиться через SSH, запустить PowerShell и спокойно работать. Хотя «привычно» — это не про традиционных Windows администраторов. К сожалению, многие из них остались в далеких и светлых нулевых и искренне считают, что «в ролях Windows Server ничего принципиально не изменилось».
На самом деле мир давно стал другим, равно как стал другим и Windows и для нормальной конкуренции нужно выходить из привычного комфорта графики и погружаться в суровую среду консоли.
Но суровая она только на первый взгляд. Когда вы поймете, что текстовый интерфейс предоставляет такие же, а то и более богатые возможности, но при этом гораздо более послушен чем графика вам не захочется в нее возвращаться.
А потом, может быть, и полностью откажетесь от графического окружения на своем Windows Server.
👍27🤡2🤬1🤮1
Я календарь переверну…
Сегодня многие отмечают известный день, в который надо переворачивать календари и жечь костры из рябин. Не меньшее количество товарищей настроены к этим многим негативно и с самого утра подвергают их обструкции.
Но мы не будем касаться этих народных развлечений и поговорим о вещах более серьезных.
Не так давно один наш коллега спросил, а как можно изменить триггер Zabbix, чтобы он срабатывал только в рабочее время.
На самом деле очень просто, добавляем к условию срабатывания:
В данном случае триггер будет срабатывать между 09:45 и 22:15, в остальное время тревожить он вас не будет.
Но оказалось, что триггер работает неправильно.
Первое, о чем тут хочется спросить – часовой пояс.
Да, с часовым поясом все нормально, Zabbix показывает события точно по времени, а вот триггер по времени работать не хочет.
А теперь вспоминаем, что веб-интерфейс Zabbix – это отдельное приложение, которое имеет собственные настройки часового пояса, в то время как сама система хранит все события с временной меткой UTC.
И вот здесь важно понимать, что аппаратные часы Linux идут в UTC, а уже потом система или отдельные приложения делают поправку на свой часовой пояс.
Что касается веб-интерфейса Zabbix, то там у каждого пользователя есть свои настройки часового пояса, так как пользователей у системы мониторинга может быть много и собирать события она может из разных часовых поясов.
Сам же сервер Zabbix работает в часовом поясе операционной системы на которой запущен и что там установлено в веб-интерфейсе его волнует мало.
Таким образом у нашего коллеги оказалось, что веб-интерфейс Zabbix имел правильные настройки пояса – MSK (UTC +3), а вот сам сервер работал, как и был из коробки – т.е. в UTC.
Поэтому события в интерфейсе показывались с правильным временем, а вот триггеры срабатывали с отставанием на 3 часа, потому как считали, что сервер находится в часовом поясе UTC (Гринвич).
Ошибка эта распространенная, можно сказать – типовая. Поэтому никогда не забывайте настраивать правильный часовой пояс в самой ОС, причем сразу после установки. Также как и рабочую локаль. Избежите многих потенциальных сложностей.
Сегодня многие отмечают известный день, в который надо переворачивать календари и жечь костры из рябин. Не меньшее количество товарищей настроены к этим многим негативно и с самого утра подвергают их обструкции.
Но мы не будем касаться этих народных развлечений и поговорим о вещах более серьезных.
Не так давно один наш коллега спросил, а как можно изменить триггер Zabbix, чтобы он срабатывал только в рабочее время.
На самом деле очень просто, добавляем к условию срабатывания:
and time()>=094500 and time()<=221500
В данном случае триггер будет срабатывать между 09:45 и 22:15, в остальное время тревожить он вас не будет.
Но оказалось, что триггер работает неправильно.
Первое, о чем тут хочется спросить – часовой пояс.
Да, с часовым поясом все нормально, Zabbix показывает события точно по времени, а вот триггер по времени работать не хочет.
А теперь вспоминаем, что веб-интерфейс Zabbix – это отдельное приложение, которое имеет собственные настройки часового пояса, в то время как сама система хранит все события с временной меткой UTC.
И вот здесь важно понимать, что аппаратные часы Linux идут в UTC, а уже потом система или отдельные приложения делают поправку на свой часовой пояс.
Что касается веб-интерфейса Zabbix, то там у каждого пользователя есть свои настройки часового пояса, так как пользователей у системы мониторинга может быть много и собирать события она может из разных часовых поясов.
Сам же сервер Zabbix работает в часовом поясе операционной системы на которой запущен и что там установлено в веб-интерфейсе его волнует мало.
Таким образом у нашего коллеги оказалось, что веб-интерфейс Zabbix имел правильные настройки пояса – MSK (UTC +3), а вот сам сервер работал, как и был из коробки – т.е. в UTC.
Поэтому события в интерфейсе показывались с правильным временем, а вот триггеры срабатывали с отставанием на 3 часа, потому как считали, что сервер находится в часовом поясе UTC (Гринвич).
Ошибка эта распространенная, можно сказать – типовая. Поэтому никогда не забывайте настраивать правильный часовой пояс в самой ОС, причем сразу после установки. Также как и рабочую локаль. Избежите многих потенциальных сложностей.
👍17🤔1🤮1👌1👀1