А и Б сидели на трубе
Сегодня пятница и хочу рассказать один забавный случай, и поучительный.
Позвонил мне третьего дня хороший друг и товарищ, мол купил я на дом еще одну камеру, настрой ее и подключи к серверу видеонаблюдения.
Да фигня вопрос. Друг – адвокат и всегда выручает меня советом, когда надо, поэтому такую услугу окажу с удовольствием.
Подключаюсь к его ПК через TeamViewer, запускаю SADP – это такая удобная утилита от Hikvision, которая видит камеры по MAC и позволяет цепляться к ним, менять сетевые настройки, ставить пароль и все такое прочее лишний раз не вставая с дивана.
В общем ставлю на камеру стандартный пароль и иду в веб-интерфейс настроить потоки, часовой пояс и все такое прочее. И с удивлением вижу, что неправильный логин/пароль.
Ну как-так, я же стандартный ставил. Ну а вот так, неверно и все!
Ладно, звоню другу, он берет стремянку, лезет, сбрасывает камеру кнопкой.
Все повторяется, снова неверный логин и пароль. Снова стремянка и сброс кнопкой.
Понимаем, что какая-то фигня. Открываем Блокнот, набираем пароль, но в SADP копирование пароля не работает, только ручками.
Поэтому решаем настроить контрольный вопрос, чтобы можно было сбросить пароль, не прибегая к сбросу камеры.
И тут вот наблюдаем изумительную картину: в SADP если была нажата клавиша А, то какую бы вы клавишу не нажали – следующая снова будет А.
Причем такой фокус проявляется только через удаленное подключение, локально все нормально. Отключились и снова подключили TeamViewer – снова стало все нормально.
Поэтому во всех подобных непонятных ситуациях всегда следует проверять в любом свободном поле приложения как именно набираются символы, потому что средства удаленного доступа иногда преподносят такие вот фокусы.
Сегодня пятница и хочу рассказать один забавный случай, и поучительный.
Позвонил мне третьего дня хороший друг и товарищ, мол купил я на дом еще одну камеру, настрой ее и подключи к серверу видеонаблюдения.
Да фигня вопрос. Друг – адвокат и всегда выручает меня советом, когда надо, поэтому такую услугу окажу с удовольствием.
Подключаюсь к его ПК через TeamViewer, запускаю SADP – это такая удобная утилита от Hikvision, которая видит камеры по MAC и позволяет цепляться к ним, менять сетевые настройки, ставить пароль и все такое прочее лишний раз не вставая с дивана.
В общем ставлю на камеру стандартный пароль и иду в веб-интерфейс настроить потоки, часовой пояс и все такое прочее. И с удивлением вижу, что неправильный логин/пароль.
Ну как-так, я же стандартный ставил. Ну а вот так, неверно и все!
Ладно, звоню другу, он берет стремянку, лезет, сбрасывает камеру кнопкой.
Все повторяется, снова неверный логин и пароль. Снова стремянка и сброс кнопкой.
Понимаем, что какая-то фигня. Открываем Блокнот, набираем пароль, но в SADP копирование пароля не работает, только ручками.
Поэтому решаем настроить контрольный вопрос, чтобы можно было сбросить пароль, не прибегая к сбросу камеры.
И тут вот наблюдаем изумительную картину: в SADP если была нажата клавиша А, то какую бы вы клавишу не нажали – следующая снова будет А.
Причем такой фокус проявляется только через удаленное подключение, локально все нормально. Отключились и снова подключили TeamViewer – снова стало все нормально.
Поэтому во всех подобных непонятных ситуациях всегда следует проверять в любом свободном поле приложения как именно набираются символы, потому что средства удаленного доступа иногда преподносят такие вот фокусы.
👍78
VPN и сетевое окружение
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
👍69❤8🔥8
Резервные копии Active Direcitory
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
Вынесенная в заголовок тема давно служит предметом споров, в частности многих смущают противоречивые, я бы даже сказал – взаимоисключающие рекомендации, которые звучат примерно так: резервные копии контроллеров домена делать надо, но восстанавливать их из резервных копий не следует!
В чем причина? А причина в USN Rollback – главной страшилке системных администраторов былых времён. Сейчас получить USN Rollback все так же можно, но никаких особых последствий у вас не будет.
Чтобы понять, что такое USN Rollback нужно немного углубиться в работу репликации базы данных AD. Для того, чтобы не гонять каждый раз по сети всю базу контроллеры передают только измененные объекты.
Каждое изменение метаданных AD снабжается специальным идентификатором контроллера домена - Invocation ID - и последовательным номером – USN.
Другие контроллеры, выполнив репликацию, запоминают этот идентификатор и USN, после чего при следующей репликации будут запрашивать объекты с USN указанного номера.
При USN Rollback у контролера уменьшается текущий максимальный номер USN, и он начинает создавать изменения, которые никогда не будут реплицированы, чем переводит базу AD в рассогласованное состояние.
Чем это чревато? Различными тяжелыми глюками и ошибками работы AD, вплоть до ситуации полного хаоса в сети, когда пользователи аутентифицируются через раз, политики работают не так как следует и т.д. и т.п.
Начиная с 2012 Microsoft добавила ряд функций препятствующих такому развитию событий, в частности обнаружение USN Rollback, когда контроллер перед началом репликации запрашивает сохраненные USN с других контролеров в сети.
Если полученное значение превышает собственный максимальный USN, то на контроллере полностью блокируется репликация, а службы Active Directory переводятся в приостановленное состояние.
Но если у контроллера долгое время не было связи с AD и на нем активно вносились изменения, то может оказаться, что максимальный USN контроллера окажется выше и обнаружения USN Rollback не произойдет, после чего мы снова получим весь спектр чудес в одном флаконе.
Ситуацию осложняет еще и то, что современные администраторы скорее всего никогда не сталкивались с этой бедой, не знают ее симптомов и будут искать не там, где нужно, а там, где светлее.
Что касается восстановления контроллера через родной режим службы восстановления каталогов (вам понадобится резервная копия, сделанная службой Windows Server Backup), то в конце восстановления контроллеру меняют Invocation ID, что заставляет остальные контроллеры считать его новым контроллером в AD и начать репликацию с ним «с чистого листа».
Поэтому мы не видим насущной необходимости восстанавливать сбойный КД, в лучшем случае вы потратите на восстановление столько же времени, сколько на настройку нового КД, а то и гораздо больше, так как настройка КД – задача привычная, а восстановление – новая и не совсем понятная.
В худшем, если бекап был сделан программой не умеющей восстанавливать KД (а именно менять Invocation ID), то вы потеряете контроллер и вам все равно придется настраивать его заново.
Так для чего же нужна резервная копия контроллеров AD? А нужна она на случай, если вы серьезно нарушите текущую структуру AD или внесете туда несовместимые с нормальной работой изменения.
В этом случае вам придется понизить все контроллеры кроме одного, восстановить его из резервной копии, а затем снова добавить нужное количество контроллеров.
Но мы надеемся, что данной ситуации у вас не возникнет.
👍33
Сталкивались ли вы в своей практике с USN Rollback?
Anonymous Poll
13%
Да
55%
Нет
33%
Ничего не понятно, но очень интересно
Чем отличаются DHCP Option 015 (DNS Domain Name) и DHCP Option 119 (Domain Search List)
Не так давно в обсуждениях снова всплыли плоские имена и связанные с ними проблемы.
Что такое плоское имя? Это имя компьютера из одного слова, например,
Чтобы обратиться к компьютеру по сети, мы должны преобразовать (разрешить) его имя в IP-адрес. Для плоского имени это можно сделать только при помощи широковещательных протоколов сетевого обнаружения или WINS-сервера.
Широковещательные протоколы не самый лучший вариант с точки зрения нагрузки на сеть и их работа ограничена широковещательным доменом (т.е. текущим сегментом сети).
WINS снимает эти проблемы, но данный протокол является устаревшим и уязвимым, поэтому в современных сетях его использовать не следует.
В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:
Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция
Если мы передали в этой опции домен
Вроде бы все хорошо, но сети растут, количество доменов в нем увеличивается и коллеги вполне могут прислать ссылку с плоским именем:
Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.
Поэтому была введена опция
DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.
Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.
Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.
Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.
Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.
В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику
Не так давно в обсуждениях снова всплыли плоские имена и связанные с ними проблемы.
Что такое плоское имя? Это имя компьютера из одного слова, например,
SERVER-01 или PC-003. Чтобы обратиться к компьютеру по сети, мы должны преобразовать (разрешить) его имя в IP-адрес. Для плоского имени это можно сделать только при помощи широковещательных протоколов сетевого обнаружения или WINS-сервера.
Широковещательные протоколы не самый лучший вариант с точки зрения нагрузки на сеть и их работа ограничена широковещательным доменом (т.е. текущим сегментом сети).
WINS снимает эти проблемы, но данный протокол является устаревшим и уязвимым, поэтому в современных сетях его использовать не следует.
В тоже время задачу разрешения имен призван решать DNS-сервер, но он не работает с плоскими именами, точнее DNS-клиент дополнит плоское имя до FQDN следующим образом:
SERVER-01.
Что обозначает домен первого уровня SERVER-01, аналогичный RU или COM. Естественно, такой зоны на вашем DNS-сервере найдено не будет и поиск закончится неудачей.Поэтому нужно научить DNS-клиент правильно дополнять плоские имена до FQDN и для этого предназначена опция
DHCP 015 (DNS Domain Name), которая задает имя домена используемое при разрешении имен на DNS-сервере. Также ее часто называют DNS Suffix.Если мы передали в этой опции домен
example.office, то любое плоское имя будет дополнено как:SERVER-01. example.office.
После чего запрошенное имя будет легко разрешено обслуживающим зону DNS-сервером.Вроде бы все хорошо, но сети растут, количество доменов в нем увеличивается и коллеги вполне могут прислать ссылку с плоским именем:
http://webserver-005/otchet.pdf
Где указанное плоское имя соответствует веб-серверу филиала на хуторе Гадюкино который использует домен example.gadykino.office. Как быть в таком случае? Опция 015 не предусматривает передачу нескольких имен, хотя некоторые реализации DHCP-клиентов в Linux умеют разбирать строку, состоящую из нескольких значений.
Поэтому была введена опция
DHCP 119 (Domain Search List), которая содержит список доменов используемых для разрешения имен, теперь мы можем передать в нем как example.office, так и example.gadykino.office. DNS-клиент будет выполнять поиск в порядке следования доменов в списке, поэтому «родной» домен указывайте первым.
Таким образом опции 015 и 119 фактически выполняют одно и то же действие. Только 015 передает единственный домен, а 119 – список доменов.
Что будет, если опции 015 и 119 указаны одновременно? Стандарты не описывают данную ситуацию, поэтому все отдается на откуп конкретной реализации DHCP-клиента.
Общая рекомендация: указывать домен из опции 015 первым в списке доменов опции 119.
Какую из них использовать? Если домен поиска один, то используйте 015, это обеспечит наибольшую совместимость с оборудованием и ПО. Если несколько, то 119.
В доменных сетях от использования опций DHCP 015 и 119 лучше отказаться и настроить домены поиска через GPO используя политику
Computer Configuration -> Administrative Templates -> Network -> DNS Client and open DNS Suffix Search List.
👍66👌1
Окончание поддержки Windows Server 2012 R2
Сегодня, 10 октября, закончилась поддержка Windows Server 2012 R2. Настала пора планировать обновления и переезжать на новую версию. Актуальная версия серверной ОС на сегодня – это Windows Server 2022.
Следует помнить, что серверные версии Windows не поддерживали и не поддерживают бесплатное обновление между версиями и даже Server и Server R2 – это разные продукты.
Право на понижение версии (downgrade) дает возможность использовать с текущей лицензией версии на два выпуска ниже.
Т.е. Windows Server 2022 дает право использовать Windows Server 2019 и 2016.
Лицензии клиентского доступа CAL и удаленного доступа RDS CAL совместимы сверху вниз, т.е. CAL 2022 можно использовать для доступа к системам, работающим на любом выпуске Windows Server ниже 2022, а, например, CAL 2016 уже нельзя использовать для доступа к системам на новых выпусках Windows Server.
Так что вместе с ОС вам придется купить новый комплект лицензий клиентского доступа (текущую ситуацию с доступностью лицензий мы в расчет не берем, а рассказываем, как делать лицензионно правильно).
Теперь о том, как обновляться. Windows Server последних версий (начиная с далекой 2008) поддерживает обновление «на месте» (in place) или говоря привычным языком – поверх.
Некоторые, особенно бывалые админы, могут шарахаться от такого обновления как черт от ладана, но на самом деле это не так страшно, современные системы не перезаписывают системные файлы поверх, как это было до выхода NT 6 (Vista и Server 2008), а разворачивает новый, чистый образ, на который переносит настройки, программы и документы.
По сути, мы имеем чистую установку с переносом не нее всего пользовательского окружения. Хотя с некоторым ПО могут возникнуть сложности, но они возникнут в любом случае.
Обновляться «на месте» можно также на два выпуска вперед, т.е. с Windows Server 2012 R2 можно перейти на Windows Server 2016 или 2019, а для перехода на Windows Server 2022 нужно выполнить два последовательных обновления.
Единственный сценарий, в котором обновление «на месте» не рекомендуется – это обновление контроллеров домена, в этом случае лучше ввести в домен новые контроллеры, на новой версии ОС, а затем понизить и вывести из эксплуатации старые.
А вы уже готовы попрощаться с Windows Server 2012 R2?
Сегодня, 10 октября, закончилась поддержка Windows Server 2012 R2. Настала пора планировать обновления и переезжать на новую версию. Актуальная версия серверной ОС на сегодня – это Windows Server 2022.
Следует помнить, что серверные версии Windows не поддерживали и не поддерживают бесплатное обновление между версиями и даже Server и Server R2 – это разные продукты.
Право на понижение версии (downgrade) дает возможность использовать с текущей лицензией версии на два выпуска ниже.
Т.е. Windows Server 2022 дает право использовать Windows Server 2019 и 2016.
Лицензии клиентского доступа CAL и удаленного доступа RDS CAL совместимы сверху вниз, т.е. CAL 2022 можно использовать для доступа к системам, работающим на любом выпуске Windows Server ниже 2022, а, например, CAL 2016 уже нельзя использовать для доступа к системам на новых выпусках Windows Server.
Так что вместе с ОС вам придется купить новый комплект лицензий клиентского доступа (текущую ситуацию с доступностью лицензий мы в расчет не берем, а рассказываем, как делать лицензионно правильно).
Теперь о том, как обновляться. Windows Server последних версий (начиная с далекой 2008) поддерживает обновление «на месте» (in place) или говоря привычным языком – поверх.
Некоторые, особенно бывалые админы, могут шарахаться от такого обновления как черт от ладана, но на самом деле это не так страшно, современные системы не перезаписывают системные файлы поверх, как это было до выхода NT 6 (Vista и Server 2008), а разворачивает новый, чистый образ, на который переносит настройки, программы и документы.
По сути, мы имеем чистую установку с переносом не нее всего пользовательского окружения. Хотя с некоторым ПО могут возникнуть сложности, но они возникнут в любом случае.
Обновляться «на месте» можно также на два выпуска вперед, т.е. с Windows Server 2012 R2 можно перейти на Windows Server 2016 или 2019, а для перехода на Windows Server 2022 нужно выполнить два последовательных обновления.
Единственный сценарий, в котором обновление «на месте» не рекомендуется – это обновление контроллеров домена, в этом случае лучше ввести в домен новые контроллеры, на новой версии ОС, а затем понизить и вывести из эксплуатации старые.
А вы уже готовы попрощаться с Windows Server 2012 R2?
👍17🫡4🤮2
Как вы предпочитаете обновлять современные версии Windows
Anonymous Poll
8%
Поверх, за редкими исключениями
6%
Предпочитаю поверх
41%
Предпочитаю чистую установку
26%
Только чистую установку
9%
Пофиг, когда как
10%
Ничего не понятно, но очень интересно
Какие версии Windows Server у вас в эксплуатации?
Anonymous Poll
3%
NT 4
2%
2000
13%
2003 / 2003 R2
5%
2008
36%
2008 R2
8%
2012
49%
2012 R2
45%
2016
52%
2019
22%
2022
Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Windows
Лицензия на сервер 1С:Предприятие позволяет запускать на одном компьютере неограниченное количество экземпляров сервера что может быть полезным, если вам нужно одновременно иметь несколько различных версий платформы или просто разделить сервера, например, на разработку и рабочий.
Процесс это не сложный, описан в официальной документации, но имеет некоторые свои тонкости, которые мы рассмотрим в данной статье. Также добавим некоторую дополнительную информацию, которая может вам пригодиться.
https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-win.html
Лицензия на сервер 1С:Предприятие позволяет запускать на одном компьютере неограниченное количество экземпляров сервера что может быть полезным, если вам нужно одновременно иметь несколько различных версий платформы или просто разделить сервера, например, на разработку и рабочий.
Процесс это не сложный, описан в официальной документации, но имеет некоторые свои тонкости, которые мы рассмотрим в данной статье. Также добавим некоторую дополнительную информацию, которая может вам пригодиться.
https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-win.html
👍37🌭3👌1
О пользе систем управление конфигурациями или тайная жизнь ваших сетевых устройств
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
👍60
Netrunner 23 - манная каша со вкусом KDE
Не так давно мы рассматривали KDE Neon - дистрибутив от разработчиков KDE, которые предлагают пользователю интересное сочетание плавающих релизов KDE Plasma на базе стабильной платформы Ubuntu LTS, поэтому мы не могли пройти мимо другого аналогичного дистрибутива - Netrunner.
Их объединяет то, что также как и Neon, Netrunner находится под крылом Blue Systems GmbH - крупного спонсора KDE и бывшего главного спонсора Kubuntu.
Но впоследствии их пути разошлись и текущие выпуски Netrunner основаны на Debian.
Нам же данный дистрибутив интересен как взгляд на то, как должна выглядеть KDE-система со стороны одного из главных спонсоров проекта.
https://interface31.ru/tech_it/2023/10/netrunner-23-mannaya-kasha-so-vkusom-kde.html
Не так давно мы рассматривали KDE Neon - дистрибутив от разработчиков KDE, которые предлагают пользователю интересное сочетание плавающих релизов KDE Plasma на базе стабильной платформы Ubuntu LTS, поэтому мы не могли пройти мимо другого аналогичного дистрибутива - Netrunner.
Их объединяет то, что также как и Neon, Netrunner находится под крылом Blue Systems GmbH - крупного спонсора KDE и бывшего главного спонсора Kubuntu.
Но впоследствии их пути разошлись и текущие выпуски Netrunner основаны на Debian.
Нам же данный дистрибутив интересен как взгляд на то, как должна выглядеть KDE-система со стороны одного из главных спонсоров проекта.
https://interface31.ru/tech_it/2023/10/netrunner-23-mannaya-kasha-so-vkusom-kde.html
👍10👌2
И снова про рекламу и донаты
Эта тема уже неоднократно поднималась на данном ресурсе и непременно будет подниматься вновь, так уж устроен человек.
Мы сейчас не будем бросаться в крайности, потому что всегда найдется категория читателей, которая в принципе не переносит рекламу и считает, что автор должен персонально им и вообще должен быть голодным.
Мы же будем говорить о читателе адекватном, который в принципе понимает, что количество и качество публикуемых материалов каким-то образом связано с количеством рекламы и где-то там соглашается с позицией: нет рекламы – нет контента.
Сегодня мы хотим показать другую сторону этой всей кухни – то, как создаются материалы и сколько времени это занимает.
Все материалы в канале делятся, собственно, на материалы канала и анонсы статей сайта. Обязательный план – минимум одна заметка в день.
Средняя техническая заметка для Telegram занимает 1-2 часа времени. Потому что нужно найти материал, проверить его, скомпоновать, упорядочить и придумать как уместить все это в 4000 символов.
Короткая заметка за жизнь, типа этой, также занимает не менее часа, потому что нужно сделать подводку, выразить основную мысль и сделать заключение, опять-таки в пределах тех самых 4000 символов.
Нет, можно, конечно, выплеснуть сразу из головы, только будет это нечитаемая каша, мутный поток сознания.
Итого по нашему плану имеем 1,5 х 7 = 10,5 часов, полный рабочий день с переработкой. Это только на подготовку коротких заметок в канал.
Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее.
Даже такой простой обзор, как вчерашний требует куда больше времени, чем заметка. Прежде всего надо изучить что уже написали по этой теме, на что обратить внимание самому и вообще, есть ли смысл писать. Минимум от часа времени.
Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью.
План статьи – еще час, делается либо параллельно, либо по горячим следам. Потому что бес плана статью можно писать только с колес, уже на следующий день многое из того, что обратило на себя внимание забудется.
По мере составления плана может оказаться что не хватает каких-то скриншотов или надо проверить некоторые иные моменты, возвращаемся в предыдущий пункт.
Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса.
Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать.
Технические статьи занимают еще больше времени. Там тоже все начинается с этапа изучения уже написанного, тот же час.
Затем изучается документация, еще час-два. Потом стенд и кропотливая запись каждого действия.
Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три.
Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем.
Если результат нас устроил и показывает повторяемость, то составляем план статьи, готовим скриншоты, схемы и т.д., это еще один чистовой прогон. Еще два часа.
Само написание текста, в зависимости от сложности оформления, еще несколько часов, от двух до четырех.
Итог? Опять по минимуму 9-10 часов, на одну статью.
Итого в месяц получаем 40-50 часов работы с контентом, это полноценная рабочая неделя (пяти или шестидневная).
Можно ли тащить такой объем на энтузиазме? Или донатах, которых за прошлый год набралось целых шесть с хвостиком тысяч рублей? Совмещая это с основной работой, семьей, бытом? Занимаясь этим регулярно, через «лениво» и «не хочу»?
Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»
Эта тема уже неоднократно поднималась на данном ресурсе и непременно будет подниматься вновь, так уж устроен человек.
Мы сейчас не будем бросаться в крайности, потому что всегда найдется категория читателей, которая в принципе не переносит рекламу и считает, что автор должен персонально им и вообще должен быть голодным.
Мы же будем говорить о читателе адекватном, который в принципе понимает, что количество и качество публикуемых материалов каким-то образом связано с количеством рекламы и где-то там соглашается с позицией: нет рекламы – нет контента.
Сегодня мы хотим показать другую сторону этой всей кухни – то, как создаются материалы и сколько времени это занимает.
Все материалы в канале делятся, собственно, на материалы канала и анонсы статей сайта. Обязательный план – минимум одна заметка в день.
Средняя техническая заметка для Telegram занимает 1-2 часа времени. Потому что нужно найти материал, проверить его, скомпоновать, упорядочить и придумать как уместить все это в 4000 символов.
Короткая заметка за жизнь, типа этой, также занимает не менее часа, потому что нужно сделать подводку, выразить основную мысль и сделать заключение, опять-таки в пределах тех самых 4000 символов.
Нет, можно, конечно, выплеснуть сразу из головы, только будет это нечитаемая каша, мутный поток сознания.
Итого по нашему плану имеем 1,5 х 7 = 10,5 часов, полный рабочий день с переработкой. Это только на подготовку коротких заметок в канал.
Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее.
Даже такой простой обзор, как вчерашний требует куда больше времени, чем заметка. Прежде всего надо изучить что уже написали по этой теме, на что обратить внимание самому и вообще, есть ли смысл писать. Минимум от часа времени.
Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью.
План статьи – еще час, делается либо параллельно, либо по горячим следам. Потому что бес плана статью можно писать только с колес, уже на следующий день многое из того, что обратило на себя внимание забудется.
По мере составления плана может оказаться что не хватает каких-то скриншотов или надо проверить некоторые иные моменты, возвращаемся в предыдущий пункт.
Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса.
Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать.
Технические статьи занимают еще больше времени. Там тоже все начинается с этапа изучения уже написанного, тот же час.
Затем изучается документация, еще час-два. Потом стенд и кропотливая запись каждого действия.
Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три.
Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем.
Если результат нас устроил и показывает повторяемость, то составляем план статьи, готовим скриншоты, схемы и т.д., это еще один чистовой прогон. Еще два часа.
Само написание текста, в зависимости от сложности оформления, еще несколько часов, от двух до четырех.
Итог? Опять по минимуму 9-10 часов, на одну статью.
Итого в месяц получаем 40-50 часов работы с контентом, это полноценная рабочая неделя (пяти или шестидневная).
Можно ли тащить такой объем на энтузиазме? Или донатах, которых за прошлый год набралось целых шесть с хвостиком тысяч рублей? Совмещая это с основной работой, семьей, бытом? Занимаясь этим регулярно, через «лениво» и «не хочу»?
Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»
👍79🫡6❤5🤝2
SMART атрибуты NVMe дисков
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
▫️
▫️
▫️
▫️
🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
Если SATA SSD имели набор атрибутов SMART унаследованный от жестких дисков, многие из которых были бесполезны и не отражали реального состояния устройства, то NVMe диски получили обновленный набор атрибутов, разработанный как раз с учетом специфики устройств.
Ниже будем указывать атрибуты в форме ID Наименование RU (Наименование EN)
🔹 01 Критические предупреждения (Critical Warning) – флаг, указывающий на критические состояния накопителя, не является статическим, может изменять состояние динамически, возможные значения:
▫️
0x01 – доступное свободное пространство упало ниже порогового значения▫️
0x02 – температура вышла за пороговые значения (как вверх, так и вниз)▫️
0x03 - надежность подсистемы NVM ухудшилась из-за значительных проблем, связанных со средой передачи данных, включая ошибки, снижающие надежность подсистемы NVM ▫️
0x04 – накопитель перешел в режим только чтения▫️
0x08 – устройство энергозависимой памяти (DRAM) вышло из строя 🔹 02 Температура всего устройства (Composite Temperature) – средняя температура накопителя в градусах Кельвина, для перевода в градусы Цельсия необходимо вычесть из значения 273.15. Рекомендации о порогах температур задаются именно для этого значения.
🔹 03 Доступно резервных блоков (Available Spare) – процент оставшихся резервных блоков, в норме 100 и это значение будет уменьшаться
🔹 04 Критический остаток резервных блоков (Available Spare Threshold) - при падении запаса ниже указанного значения для этого поля контроллером будет сформировано событие.
🔹 05 Процент износа (Percentage Used) - показывает процент износа устройства согласно указанного производителем ресурса, 100% обозначает полный износ, значение может превышать 100, максимальное значение 255.
🔹 06 Всего прочитано данных (Data Units Read) - количество прочитанных блоков по 512 байт, единица означает тысячу прочитанных блоков.
🔹 07 Всего записано данных (Data Units Written) - количество записанных блоков по 512 байт, единица означает тысячу записанных блоков.
🔹 08 Количество команд чтения (Host Read Commands) – количество команд чтения, выполненных контролером.
🔹 09 Количество команд записи (Host Write Commands) – количество команд записи, выполненных контроллером
🔹 10 Время занятости контроллера (Controller Busy Time) – время, которое контроллер обрабатывал команды ввода-вывода или когда в очереди находились запросы. Значение представлены в минутах.
🔹 11 Количество включений питания (Power Cycles) – счетчик включений накопителя
🔹 12 Количество отработанных часов (Power On Hours) – общее время работы накопителя в часах, учитывается также время нахождения в режимах энергосбережения
🔹 13 Небезопасных выключений (Unsafe Shutdowns) – количество выключений, когда питания накопителя было отключено прежде, чем он получил от системы уведомление о выключении питания
🔹 14 Количество неисправимых ошибок (Media and Data Integrity Errors) – счетчик неисправимых ошибок ECC, вычисления контрольных сумм CRC или несоответствия LBA
🔹 15 Записей об ошибках в журнал (Number of Error Information Log Entries) – количество записей об ошибках, произведенных в журнал контроллера
🔹 16 Время работы при высокой температуре (Warning Composite Temperature Time) – время, в минутах, которое накопитель работал с превышением порога температуры
🔹 17 Время работы при критической температуре (Critical Composite Temperature Time) - время, в минутах, которое накопитель работал с превышением критического порога температуры
🔹 18 Термодатчик 1 (Temperature Sensor 1) – первый сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего контроллер.
🔹 19 Термодатчик 2 (Temperature Sensor 2) – второй сенсор температуры, точно узнать размещение сенсора можно только из описания диска, чаще всего NAND.
👍71🔥17⚡2❤1
Стандартные systemd target в Linux
Говоря о юнитах systemd, нельзя не отметить такой тип юнита как
Вы можете создать собственный таргет из взаимозависимых служб и, скажем, одновременно перезапускать все относящиеся к веб-серверу службы: веб-север, СУБД, PHP и т.д.
Но об этом мы поговорим как-нибудь позже, а сегодня наше внимание займут стандартные таргеты.
Посмотреть список стандартных целей можно командой:
У некоторых целей может быть сразу несколько вариантов, например, существуют сразу три сетевых таргета:
▫️
Данная цель должна использоваться как
Собственно
И, наконец,
Отдельного разговора заслуживают
▫️
▫️
▫️
▫️
▫️
Также существует загрузочный таргет по умолчанию -
Узнать текущее состояние по умолчанию можно командой:
По-умолчанию
Также мы можем переключаться между уровнями загрузки без перезагрузки системы при помощи команды
Ну и напоследок весьма злая шутка:
После чего можно принимать ставки как быстро коллега разберется в чем дело. Но такие шутки довольно вредны для здоровья. Минздрав предупреждает!
Говоря о юнитах systemd, нельзя не отметить такой тип юнита как
таргет (цель, taget). Таргет – это особый тип юнита, который позволяет объединить несколько юнитов в группу и управлять ими как единым целым. Вы можете создать собственный таргет из взаимозависимых служб и, скажем, одновременно перезапускать все относящиеся к веб-серверу службы: веб-север, СУБД, PHP и т.д.
Но об этом мы поговорим как-нибудь позже, а сегодня наше внимание займут стандартные таргеты.
Посмотреть список стандартных целей можно командой:
systemctl -–type=target
После чего мы увидим список всех активных таргетов, чтобы увидеть полный список используйте команду:systemctl -–type=target -–all
Что в этом полезного и для чего мы можем их использовать? Прежде всего для указания зависимостей. Допустим нам нужно, чтобы наша служба запускалась после того, как будет инициирована сеть, нет ничего проще:After=network.target
Если вы используете сетевые файловые системы, такие как NFS или CIFS/SMB и ваша служба должна запуститься после того, как они будут смонтированы:After=remote-fs.target
И не нужно ничего придумывать, systemd уже подумала за вас.У некоторых целей может быть сразу несколько вариантов, например, существуют сразу три сетевых таргета:
▫️
network-pre.target
▫️ network.target
▫️ network-online.target
Цель network-pre.target представляет собой точку состояния системы перед запуском сетевых служб и может быть использована для запуска тех служб, которые обязательно должны быть активны на момент запуска сети, например, брандмауэр.Данная цель должна использоваться как
Before=network-pre.target или Wants=network-pre.target.Собственно
network.target обозначает состояние запуска всех сетевых служб системы и для прочих юнитов, которым нужна сеть мы должны использовать After=network.target, т.е. состояние после того, как все сетевые службы были запущены.И, наконец,
network-online.target – это точка состояния системы, когда все сетевые службы успешно и гарантированно запущены. Используется только с Wants= и After=, используется в основном для устаревших служб или сценариев, которые некорректно работают с After=network.target.Отдельного разговора заслуживают
Boot targets – цели загрузки, эти таргеты являются аналогами уровней запуска init. Существуют следующие загрузочные таргеты:▫️
poweroff.target (runlevel 0) – выключение системы▫️
rescue.target (runlevel 1) – режим восстановления системы▫️
multi-user.target (runlevel3) – многопользовательский режим (консольный режим без графики)▫️
graphical.target (runlevel 5) – режим графического окружения▫️
reboot.target (runlevel 6) – перезагрузка системыТакже существует загрузочный таргет по умолчанию -
default.target, который является символьной ссылкой на один из загрузочных таргетов и определяет в какой именно режим будет загружена система по умолчанию. Узнать текущее состояние по умолчанию можно командой:
systemctl get-default
А установить новую цель загрузки можно командой:systemctl set-default graphical.targetПри этом
graphical.target имеет одну особенность, при отсутствии графики он запускается и работает аналогично multi-user.target и поэтому не следует удивляться, увидев его в системе без графической оболочки или в контейнере.По-умолчанию
graphical.target для систем без графического окружения используют Debian и Ubuntu.Также мы можем переключаться между уровнями загрузки без перезагрузки системы при помощи команды
isolate. Так если мы выполним в графической среде: systemctl isolate multi-user.target
То все графические модули будут остановлены, и система перейдет в режим командной строки.Ну и напоследок весьма злая шутка:
systemctl set-default reboot.target 👻👻👻После чего можно принимать ставки как быстро коллега разберется в чем дело. Но такие шутки довольно вредны для здоровья. Минздрав предупреждает!
👍36🔥7❤2
Linux – права файловой системы
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
rw- r—- r—-
Обозначает право на запись и чтение для владельца и только чтение для группы и прочих.Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
110 100 100
Или в более привычной восьмеричной форме:644
Да, несмотря на то что запись ведется привычными десятичными цифрами система указания прав использует восьмеричную систему.Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
755 -> 111 101 101 -> rwx r-x r-x
Т.е. полные права у владельца и чтение и исполнение для остальных.Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
SUID – SGID – stiky
sticky-бит – он же 001 или 1 – может быть установлен только для каталога, его установка для файлов игнорируется. В переводе stiky означает – липкий, что полностью соответствует его работе. При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
011 111 101 101 -> 3755 –> rwx r-s r-t
Указанная комбинация часто используется на файловых серверах, когда нужно нарезать права на основе дополнительных групп, а также запретить пользователям удалять чужие файлы.Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
👍50⚡14🔥8❤1👌1
Используете ли вы дополнительные атрибуты: stiky-бит, SUID, SGID?
Anonymous Poll
18%
Да
40%
Нет
24%
Только сейчас узнал
18%
Ничего не понятно, но очень интересно
👍3
Мониторинг. Внешний и внутренний.
Про важность мониторинга говорить не нужно, это все знают и понимают. Но, чаще всего, система мониторинга располагается в периметре сети и в некоторых случаях может оказаться бесполезна.
Система мониторинга внутри периметра является внутренней и рассчитана на классический сценарий: рядом с ней, внутри этого же периметра всегда есть сотрудник, который всегда может отреагировать и оценить ситуацию.
Скажем, если в здании пропало электроснабжение, то сотрудники об этом узнают раньше, чем им придет алерт от системы мониторинга.
Но сейчас ситуация сильно изменилась, очень многие сотрудники работают удаленно, да и администратор тоже может быть достаточно далеко и лишившись доступа к внутреннему мониторингу он станет подобен слепому котенку, полностью утратив контроль за ситуацией.
Что произошло? Упал интернет? Выключили электричество или выбило питающий стойку автомат? А может это просто Zabbix упал?
Чтобы иметь возможность получить ответы на эти вопросы и понадобится внешний мониторинг.
В простейшем случае это пинговалка по внешнему адресу, которая скажет жив внешний адрес сети или нет. Это уже лучше, чем ничего, но все еще не дает ответов на основные вопросы: что происходит и куда бежать.
Поэтому нам нужна, может быть менее сложная, но полноценная система внешнего мониторинга с доступом во внутреннюю сеть. Это можно легко организовать при помощи VPN.
При этом не следует собирать бездумно все метрики, для внешнего мониторинга нам нужны только ключевые. Это поможет произвести разбор полетов и понять, что произошло в сети, почему и нужно ли туда ехать прямо сейчас.
Например, внешний мониторинг поможет быстро понять, что это не во всем здании электричества нет, а выбило отдельную стойку. Или что перед тем, как пропасть с радаров связь на точке серьезно ухудшилась.
При этом важно мониторить также внешний адрес и доступность сервисов на нем. Так если VPN упал, но внешний адрес и порт доступны, то стоит проверить сам VPN-сервер или срок действия сертификатов к нему (как клиентских, так и серверных).
Мы чаще всего реализуем эту схему как Zabbix в качестве внутреннего мониторинга и The Dude на CHR в качестве внешнего. Эта связка позволяет не усложнять схему, все-таки Zabbix сложный и тяжелый продукт, но получать максимум актуальной информации, для проверки сетевой доступности и снятия ключевых показателей The Dude подходит достаточно неплохо.
А как решаете подобные задачи вы? Используете разделение мониторинга на внешний и внутренний?
Про важность мониторинга говорить не нужно, это все знают и понимают. Но, чаще всего, система мониторинга располагается в периметре сети и в некоторых случаях может оказаться бесполезна.
Система мониторинга внутри периметра является внутренней и рассчитана на классический сценарий: рядом с ней, внутри этого же периметра всегда есть сотрудник, который всегда может отреагировать и оценить ситуацию.
Скажем, если в здании пропало электроснабжение, то сотрудники об этом узнают раньше, чем им придет алерт от системы мониторинга.
Но сейчас ситуация сильно изменилась, очень многие сотрудники работают удаленно, да и администратор тоже может быть достаточно далеко и лишившись доступа к внутреннему мониторингу он станет подобен слепому котенку, полностью утратив контроль за ситуацией.
Что произошло? Упал интернет? Выключили электричество или выбило питающий стойку автомат? А может это просто Zabbix упал?
Чтобы иметь возможность получить ответы на эти вопросы и понадобится внешний мониторинг.
В простейшем случае это пинговалка по внешнему адресу, которая скажет жив внешний адрес сети или нет. Это уже лучше, чем ничего, но все еще не дает ответов на основные вопросы: что происходит и куда бежать.
Поэтому нам нужна, может быть менее сложная, но полноценная система внешнего мониторинга с доступом во внутреннюю сеть. Это можно легко организовать при помощи VPN.
При этом не следует собирать бездумно все метрики, для внешнего мониторинга нам нужны только ключевые. Это поможет произвести разбор полетов и понять, что произошло в сети, почему и нужно ли туда ехать прямо сейчас.
Например, внешний мониторинг поможет быстро понять, что это не во всем здании электричества нет, а выбило отдельную стойку. Или что перед тем, как пропасть с радаров связь на точке серьезно ухудшилась.
При этом важно мониторить также внешний адрес и доступность сервисов на нем. Так если VPN упал, но внешний адрес и порт доступны, то стоит проверить сам VPN-сервер или срок действия сертификатов к нему (как клиентских, так и серверных).
Мы чаще всего реализуем эту схему как Zabbix в качестве внутреннего мониторинга и The Dude на CHR в качестве внешнего. Эта связка позволяет не усложнять схему, все-таки Zabbix сложный и тяжелый продукт, но получать максимум актуальной информации, для проверки сетевой доступности и снятия ключевых показателей The Dude подходит достаточно неплохо.
А как решаете подобные задачи вы? Используете разделение мониторинга на внешний и внутренний?
👍29
Программные лицензии 1С – как узнать причину слета лицензии и быстро активировать ее заново
Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.
Но на самом деле работа программных лицензий подвержена жесткой логике, которая описана в тоненькой желтой книжке, которую никто не читает.
При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:
▫️ Особенности применения программных лицензий 1С:Предприятие
Итак, если лицензия слетела, то первым делом нужно открыть подробную информацию в окне, где вам об этом сообщается, вы увидите примерно то, что показано на рисунке.
В данном случае причиной слета лицензии было изменение дисковой конфигурации компьютера, что соответствует реальному положению дел.
Но не следует спешить активировать новую лицензию. Сначала внимательно изучите текущий список оборудования. В нашем случае в него затесались два внешних жестких диска. Их перед получением лицензии следует отключить.
Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.
Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.
Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.
В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.
Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.
Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:
▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла
Обратите внимание на новый, четвертый сервис, который позволяет получить данные лицензии из файла, что очень удобно если вы не знаете какая именно лицензия была активирована на данном устройстве.
Про программные лицензии ходит много мифов, мол они сильно капризные, слетают на ровном месте и т.д. и т.п.
Но на самом деле работа программных лицензий подвержена жесткой логике, которая описана в тоненькой желтой книжке, которую никто не читает.
При отсутствии этой самой тонкой желтой книжки всегда можете обратиться к нашей статье:
▫️ Особенности применения программных лицензий 1С:Предприятие
Итак, если лицензия слетела, то первым делом нужно открыть подробную информацию в окне, где вам об этом сообщается, вы увидите примерно то, что показано на рисунке.
В данном случае причиной слета лицензии было изменение дисковой конфигурации компьютера, что соответствует реальному положению дел.
Но не следует спешить активировать новую лицензию. Сначала внимательно изучите текущий список оборудования. В нашем случае в него затесались два внешних жестких диска. Их перед получением лицензии следует отключить.
Потому что добавлять в конфигурацию оборудование можно, удалять нельзя.
Кстати, после того как вы отключите внешние диски, то запустите 1С еще раз и снова посмотрите Журнал поиска ключа, чтобы четко понимать какие именно накопители будут влиять на текущую лицензию и уже после этого занимайтесь ее восстановлением.
Если у вас нет резервного ПИН-кода, то следует воспользоваться сервисами самообслуживания, либо написать письмо на адрес [email protected]. Письмо желательно писать с того адреса, на который зарегистрирована лицензия.
В нем в произвольной форме указываете номер поставки и просите выдать резервный пин-код.
Если пишите с другого адреса, то укажите также текущий пин-код и сведения о владельце лицензии.
Теперь о сервисах самообслуживания, это быстро и удобно, сейчас их четыре:
▫️ Восстановить данные о лицензии
▫️ Получить текущее состояние пин-кодов
▫️ Получить резервный пин-код
▫️ Получить лицензию из файла
Обратите внимание на новый, четвертый сервис, который позволяет получить данные лицензии из файла, что очень удобно если вы не знаете какая именно лицензия была активирована на данном устройстве.
🔥28👍11❤3👌2
Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Linux
Запуск нескольких экземпляров сервера на одном компьютере является штатной возможностью сервера 1С:Предприятие и позволяет использовать несколько платформ одновременно или разделить сервера на рабочие и тестовые.
Важным обстоятельством является то, что все запущенные экземпляры используют единственную серверную лицензию, что позволяет серьезно экономить денежные средства при наличии вычислительных возможностей.
Процесс установки дополнительных экземпляров сервера 1С:Предприятие на платформе Linux в целом несложен, однако официальная документация скупа и обрывочна, поэтому исправим данный пробел.
https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-linux.html
Запуск нескольких экземпляров сервера на одном компьютере является штатной возможностью сервера 1С:Предприятие и позволяет использовать несколько платформ одновременно или разделить сервера на рабочие и тестовые.
Важным обстоятельством является то, что все запущенные экземпляры используют единственную серверную лицензию, что позволяет серьезно экономить денежные средства при наличии вычислительных возможностей.
Процесс установки дополнительных экземпляров сервера 1С:Предприятие на платформе Linux в целом несложен, однако официальная документация скупа и обрывочна, поэтому исправим данный пробел.
https://interface31.ru/tech_it/2023/10/ustanovka-i-zapusk-neskolkih-ekzemplyarov-servera-1spredpriyatie-na-odnom-kompyutere-platforma-linux.html
👍25🔥3
Как интересно, оказывается, живут люди. Прямо вот сейчас выяснилось, что оказывается у меня нет ни одной своей статьи, а все материалы на сайте я перевожу из зарубежных источников. Ну и ссылок на оригиналы не проставляю...
По Windows c задержкой в два дня, а по Linux в три… Интересно почему… Трудности перевода, не иначе.
И, оказывается, за рубежом есть ресурсы по 1С. Надо Борису Нуралиеву написать, он, походу, не в курсе.
А еще я несколько раз расстрелял товарища и написал ему всяких гадостей в личку, но это строго после того, как он меня разоблачил.
Но выяснилось, что сей пассажир жив и здоров, пришлось исправить это недоразумение 5 минут назад.
Я все понимаю, но подобное поведения для меня загадка. Зачем? Почему? Что он получил от этого?
По Windows c задержкой в два дня, а по Linux в три… Интересно почему… Трудности перевода, не иначе.
И, оказывается, за рубежом есть ресурсы по 1С. Надо Борису Нуралиеву написать, он, походу, не в курсе.
А еще я несколько раз расстрелял товарища и написал ему всяких гадостей в личку, но это строго после того, как он меня разоблачил.
Но выяснилось, что сей пассажир жив и здоров, пришлось исправить это недоразумение 5 минут назад.
Я все понимаю, но подобное поведения для меня загадка. Зачем? Почему? Что он получил от этого?
😁51🤡20👍4🤔3🤮2
Невеселые новости от Oracle Cloud.
При очередном входе система потребовала безальтернативно подключить MFA.
А это потребует либо дополнительных телодвижений от зарубежных контрагентов (которые могут быть вообще не в курса таких технических сложностей), либо самостоятельных телодвижений по обеспечению этой самой MFA.
Фактически это очень и очень сильно усложняет использование бесплатных VPS от Оracle, особенно с их любовью выключать сервера за "неактивность".
А использование для MFA мобильного приложения со страной отличной от страны платежных данных еще и чревато блокировкой аккаунта.
При очередном входе система потребовала безальтернативно подключить MFA.
А это потребует либо дополнительных телодвижений от зарубежных контрагентов (которые могут быть вообще не в курса таких технических сложностей), либо самостоятельных телодвижений по обеспечению этой самой MFA.
Фактически это очень и очень сильно усложняет использование бесплатных VPS от Оracle, особенно с их любовью выключать сервера за "неактивность".
А использование для MFA мобильного приложения со страной отличной от страны платежных данных еще и чревато блокировкой аккаунта.
👍12😁4