Режимы кеширования виртуальных дисков KVM в Proxmox VE
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
Производительность дисковой подсистемы очень часто является узким местом многих вычислительных систем, и каждый системный администратор сталкивался и сталкивается с необходимостью оптимизации процессов обмена с накопителями.
Одним из эффективных решений, позволяющих ускорить операции ввода - вывода является кеширование. Proxmox предлагает для виртуальных дисков KVM несколько режимов кеширования, в данной статье мы рассмотрим, как они работают, а также их достоинства и недостатки.
https://interface31.ru/tech_it/2023/01/rezhimy-keshirovaniya-virtual-nyh-diskov-kvm-v-proxmox-ve.html
👍31
Ваш Zabbix напрасно поднимает панику, у нас еще много памяти
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
Не столь давно, после внедрения Zabbix один из заказчиков пожаловался, что Zabbix начал присылать сообщения о том, что недостаточно оперативной памяти, но на самом деле памяти еще достаточно.
На вопрос откуда такая уверенность нам кивнули на веб-интерфейс Proxmox из которого выходило, что памяти действительно еще хватает.
Так что, Zabbix неправильно считает память или напрасно нагнетает панику? Вовсе нет, давайте разбираться.
Давайте возьмем еще один хост с Proxmox и посмотрим, судя по графику у нас в запасе еще около 10 ГБ свободной памяти, неплохо.
Но если запустим команду:
free -h
То картина существенно изменится, как оказывается свободной памяти у нас всего 2,2 ГБ, а доступной 6,3 ГБ.При этом у нас 3,8 ГБ разделяемой памяти и 8,3 ГБ буферной/кеша.
Внимательный читатель, вооружившись калькулятором, скажет: стоп, что-то не сходятся у вас доходы с расходами.
Но в Linux есть некоторая особенность. Неактивные страницы памяти считаются занятыми, так как содержат некоторые полезные данные. В тоже время они считаются доступными, так как могут быть немедленно освобождены и переданы нуждающемуся в памяти процессу.
Т.е. если мы сложим вместе
used + shared + buff/cache то полученное значение не будет соответствовать total – free. Теперь давайте разберемся что значит каждый вид памяти:
▫️ used – использованная, память которая напрямую используется рабочими процессами в системе
▫️ free – свободная, это память которая не используется ни одним процессом и может быть выделена незамедлительно.
▫️ shared – разделяемая, используется для ускорения межпроцессного взаимодействия, что позволяет исключить передачу информации между процессами через ядро.
▫️ buff/cache – буфер ввода-вывода и кеш VFS (виртуальной файловой системы), играет очень важную роль, так как позволяет разместить в памяти наиболее часто запрашиваемые данные, системные библиотеки и т.п.
▫️ available – доступная, память которая может быть выделена процессу без обращения к пространствам подкачки.
И именно доступная (available) память наиболее точно отображает положение дел с наличием памяти в системе, и именно она используется в триггерах Zabbix.
Proxmox же просто показывает нам used, а остальное помечает свободным. Исходя из этого у нас имеется 10 ГБ «свободной» памяти, на самом деле нам доступно только 6 ГБ, где остальное?
А дело в том, что кеш тоже имеет важное значение для производительности системы и его сброс может привести к обратному эффекту – начнется интенсивное обращение к диску и общая производительность системы резко упадет.
Поэтому разные участки кеша и буферов тоже имеют собственный вес и этот вес может давать им преимущество над запущенными процессами.
В некоторых случаях система может решить, что освобождать кеш дорого и дешевле будет отправить некоторые страницы памяти в подкачку или вовсе позвать OOM Killer и пристрелить какой-нибудь жирный процесс. 🔫🔫🔫
Собственно, это мы и видим в данном случае - 4.7 ГБ памяти содержит «дорогой» кеш и не сможет быть быстро освобождена. Точнее, система будет держаться за этот кеш до последнего, потому что после его очистки плохо станет всем, а пристрелят или отправят в своп только некоторых.
Поэтому в данном случае Zabbix прав, с чем наши заказчики скоро столкнулись, когда OOM Killer начал выключать одну из малоактивных виртуалок.
Поэтому при любых непонятках с памятью ориентируйтесь не на графики и показания различных консолей, а проанализируйте ее использование при помощи команды
free.
👍63
Некоторые особенности расхода ресурса SSD или кому верить?
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
Сегодня один наш коллега обратил наше внимание на значение счетчиков отдаваемых S.M.A.R.T., а точнее на их несоответствие.
Есть два диска Kingston KC600 на 1024 ГБ с заявленным ресурсом записи 600 ТБ. Данные диски отдают в S.M.A.R.T. не только процент оставшегося ресурса, но и количество записанных данных блоками по 32 МБ.
Что привлекло внимание и насторожило? Согласно полученным данным износ первого диска составил 14%, а второго 18%. При заявленном ресурсе это должно соответствовать 84 ТБ и 108ТБ записанных данных.
Однако реально диски записали 53 ТБ и 52 ТБ, причем больший износ оказался у того диска, что записал меньше.
Странно…
Но внизу есть у нас еще один показатель - TLCWrites32MiB – который показывает количество блоков по 32 МБ, реально записанных в TLC. Здесь мы как раз можем оценить такой параметр как усиление записи (write amplification).
Путем несложных вычислений для первого диска получим 465 ТБ, что соответствует коэффициенту WA 8,7. Это говорит о том, что фактически на один записанный логический блок диск делает примерно 9 записей. Данный коэффициент не является постоянным и зависит от характера записи, единовременного объема, прошивки диска, параметров кеширования и т.д. и т.п.
У второго диска этот параметр оказался еще выше, при меньшем количестве логических записей – 566 ТБ. И это как раз соответствует показанному самим диском износу. Что касается усиления записи, то этот коэффициент для второго диска еще выше – 10,9, т.е. 11 физических записей на 1 логическую.
Сами абсолютные цифры записи в TLC никакого практического интереса не представляют, так как мы не знаем верхнего порога по этому параметру. Нет, зная процент износа и абсолютное значение мы можем рассчитать верхний порог, но зачем?
В отрыве от процентов это просто сферические цифры в вакууме. Поэтому счетчика в процентах нам достаточно, а запись в TLC без процентов лишена практического смысла.
И вот тут мы подходим к вопросу: а кому верить?
В первую очередь надо верить счетчику диска в процентах износа. Он рассчитывается на основе реального количества записи в TLC, где ресурс измеряется не в единицах объема данных, а в количестве перезаписей ячеек.
Заявленный в описании диска ресурс – TBW – это некое среднее по больнице количество записанных данных с учетом некого среднего коэффициента усиления WA. Ориентироваться на него можно, брать за некую константу нельзя.
Потому что даже если вы знаете ресурс и знаете средний объем ежедневно записываемых данных, то вы все равно не знаете для какого WA рассчитан этот ресурс и какой у вас фактический WA.
Что касается наших дисков, то для них можно попробовать рассчитать реальный ресурс по логической записи. Для первого диска он получится 378 ТБ, для второго 288 ТБ. Т.е. фактически вдвое меньше заявленного.
Это, кстати, объясняет и различные заявления в духе «диск А – отстой, помер, не выработав и половины ресурса», или «диски В – круть, работают вдвое больше заявленного».
На самом деле и тот и другой диск работают в рамках доступного ресурса перезаписи ячеек памяти, который в среднем по больнице одинаковый, а вот WA у каждого разный и поэтому итоговый результат, выраженный в объеме логической записи, может сильно различаться.
Как быть? Если диск предоставляет данные в износе в процентах – ориентируемся только на них. Если таких данных нет, то берем в расчет логическую запись, но ставим триггер далеко от пороговых значений.
Где именно начинать бить тревогу? Сложный вопрос, но при отсутствии в S.M.A.R.T. иных показателей о замене диска следует начинать задумываться после того, как ресурс снизится более чем на 50%.
👍36🔥5❤2🤔1🥱1
VPN и сетевое окружение
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?
Когда поясняешь, что все так и сетевое обнаружение компьютеров за VPN не видит, то сразу спрашивают, а как сделать так, чтобы увидела.
Здесь мы подходим к принципу работы сетевого окружения. Каким образом компьютер в одноранговой сети может найти своих соседей?
Примерно также, как человек в лесу ищет другого человека.
Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»
А ему каждый активный узел отвечает: «есть, меня зовут Имярек»
Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.
Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.
Ну ладно, это мы поняли, но в чем же проблема? Сколько там того трафика? Тем более в наш век, когда гигабит как норма жизни.
Но давайте спустимся с этих сияющих высот на уровень L2 модели OSI, называемый также канальным, так как именно он отвечает за работу сети.
Каждый порт коммутатора, а на L2 мы работаем именно с коммутаторами, может передавать кадр только от одного узла сети. Также обратим ваше внимание, что здесь у нас кадры, а не пакеты.
Реальная скорость коммутатора определяется не мегабитами и мегабайтами в секунду, а количеством кадров в единицу времени. Скорость же будет зависеть от размера кадров.
Здесь можно провести аналогию с лифтом. Вот вам надо поднять на этаж шкаф, и вы стоите ждете грузовой лифт, а на лифте катаются мальчики и он практически пустой ездит между этажами, а вы с грузом стоите и ждете.
Вот так и широковещание, сами широковещательные кадры небольшие, но они как эти мальчики, фактически гоняют сеть впустую, а важные данные вынуждены ожидать своей очереди. И чем больше широковещания, тем больше у нас таких мальчиков.
Благо, широковещание ограничено широковещательным доменом, читай физической сетью, так как выполняется на канальном уровне, а широковещательный домен, по сути, совокупность портов всех коммутаторов сети.
Современные протоколы сетевого окружения, в отличии от NETBIOS работавшего на броадкасте, используют мультикаст, что немного снижает нагрузку на сеть, но принципиально вопроса не решает.
Если пояснять на пальцах, то сетевые устройства теперь уже не орут на всю сеть «есть тут кто-нибудь?», а сначала вступают в группу в мессенджере и устраивают переклички уже там.
Это снижает объем широковещания, но целиком проблему не снижает.
А причем тут VPN, спросите вы? А при том, что желание видеть устройства за VPN в сетевом окружении аналогично желанию устраивать подобные переклички не только в своей, но и в удаленных сетях.
А теперь представьте, к чему это может привести, ведь ваш ПК не один такой и VPN может связывать самые разные сети в самой разной топологии. По факту в сети будет стоять сплошной ор и для полезного трафика там останется совсем мало места.
Поэтому все широковещательные протоколы сетевого обнаружения работают только в пределах своей сети.
А для доступа к удаленным узлам используйте IP-адреса или доменные имена.
И даже в локальной сети не следует лишний раз использовать сетевое окружение, потому что пользователь, желая просто попасть в общую папку на файловом сервере будет устраивать никому не нужные переклички.
Поэтому подключайте сетевые диски, используйте ярлыки и вообще старайтесь следовать прямыми путями, накричаться еще успеете.
👍74🔥6❤4🥱3💯1
О пользе систем управление конфигурациями или тайная жизнь ваших сетевых устройств
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
Не так давно мы рассказывали о том, как установить и настроить свободную систему управления конфигурациями Oxidized.
🔹 Устанавливаем и настраиваем систему управления конфигурациями сетевого оборудования Oxidized
И тогда в комментариях многие писали, мол зачем так все сложно, я скриптами быстрее бекап сделаю.
Но дело в том, что Oxidized – это не бекап, резервное копирование только одна из его функций. Гораздо более ценная и полезная – это система контроля изменений, основанная на Git.
Она позволяет быстро и эффективно выявлять все внесенные в конфигурацию изменения и при необходимости также быстро их сравнивать, объединять или откатывать.
При этом анализ внесенных в конфигурацию изменений помогает выявить разные скрытые от глаз процессы.
Чтобы не быть голословными расскажем одну реальную историю.
Не так давно мы внедрили новому заказчику Oxidized и через некоторое время обнаружили что конфигурация некоторых роутеров меняется.
Мы никаких изменений не вносили, персонал заказчика тоже, поэтому мысли возникли всякие, во многом нехорошие.
Но нет, роутеры никто не взломал, оказалось они тоже могут жить своей жизнью. В частности, на некоторых роутерах самопроизвольно переключался часовой пояс. С Москвы на Самару и обратно.
Таким вот образом почему-то работало автоматическое обнаружение часового пояса.
На первый взгляд довольно незначительная ерунда, особо ни на что не влияющая. И это действительно так. При общении между собой устройства используют время UTC и серьезных проблем быть не должно.
Но могут быть проблемы с анализом логов, когда вы будете искать там события по московскому времени, а они окажутся по самарскому, т.е. на час больше.
И вряд ли кто-то, не находя в логе нужных событий пойдет первым делом проверять часовой пояс.
Но речь совершенно не об этом. Вместо часового пояса там могло быть все что угодно. Речь здесь о другом, что именно благодаря системе управления конфигурациями нам открылась тайная жизнь сетевых устройств, о которой мы даже не догадывались.
Поэтому регулярный контроль изменений, особенно если вы их не вносили, дает администратору возможность выявить и устранить нестандартное поведение устройства, либо на ранних стадиях обнаружить несанкционированный доступ.
Ни одна система резервного копирования таких возможностей не предоставляет, а сравнивать конфигурации в бекапах тем более никто руками не будет.
👍41❤3👌1
Самодеятельность, художественная и не очень
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
Скрипты, как много в этом слове. Я думаю, что у каждого сисадмина в жизни был период, когда он на каждый чих сочинял собственный скрипт.
Как будто это что-то плохое, скажет иной читатель. Ну да как посмотреть, с какой точки зрения.
Начнем с точки зрения самого админа, если админ постоянный, на зарплате, то ему может показаться что ничего страшного в этом нет. Инфраструктура моя, скрипты мои, я все знаю, что может пойти не так?
Мы уже промолчим о том, что все скрипты должны быть документированы. По факту это очень и очень больной вопрос. Даже если изначальная версия скрипта таки прокомментирована и задокументирована, то последующие правки в него этого часто не удостаиваются, особенно мелкие и срочные. Потом это все копится и накладывается, ну вы поняли…
Так в чем же проблема собственных скриптов? Основная проблема в «эффекте автобуса», да да, это про того самого разработчика, который попал под автобус. Причем понимать это надо не буквально, а в том смысле, что неожиданный уход разработчика из проекта делает все эти скрипты бомбой замедленного действия.
Почему так? Про неполноту документации мы уже писали. К этому накладывается еще и дополнительный эффект «это все знают». Разработчик мог вполне сознательно опустить в документации некоторые, очевидные для него, моменты. Которые могут оказаться непонятны окружающим.
Далее сами скрипты. Очень многие скриптовые языки позволяют писать двумя способами: быстро, рационально, но нечитаемо или долго, неоптимально, но читаемо. Надо ли говорить, что чаще всего превалирует первый подход, особенно среди админов-«староверов», которые не используют современные среды разработки с синтаксис-помощниками и автодополнением, а ваяют скрипты буквально на коленках.
Мы, как аутсорсеры, очень часто встречались с такими скриптами, про которые никто ничего не знает и трогать откровенно боится, а написавший их товарищ давно растворился в тумане.
Ничего хорошего в этом нет, равно как и разобраться с ними за разумное время и деньги не представляется возможным. Но самая «мякотка» состоит в том, что они дублируют те возможности и функции, которые могут быть получены штатными пакетами или распространенным и широко известным сторонним софтом.
Да ладно, снова скажет кто-то, зачем тащить целый пакет, когда тут можно десятком другим строк обойтись.
А вот и нет, пакет тащить нужно, потому что ожидаемая конфигурация и ожидаемое поведение системы, в отличие от скрипта. И не важно, что это не красиво, не оптимально, не эффективно, не соответствуем вашим религиозным воззрениями (нужное подчеркнуть).
Причем наступить на эти грабли можно совершенно случайно. Для этого не нужно даже попадать под автобус. Достаточно уехать в отпуск и оказаться на некоторое время без связи.
Если в это время возникнет некоторая нештатная ситуация и коллеги не смогут разобраться в вашем творчестве, то по возвращению вас ждет достаточно неприятный разговор.
Потому что платят вам не за смелые эксперименты и самовыражение, а за поддержание инфраструктуры в стабильном, управляемом и предсказуемом виде, что подразумевает максимальную стандартизацию.
Любое нестандартное решение – это дополнительные затраты на поддержу (часто косвенные) и дополнительные риски, связанные с нестандартностью. Во многих случаях абсолютно неуместные.
А желание отдельных сотрудников использовать собственные костыли к месту и не к месту заставляет серьезно задуматься в плане их профпригодности, причем не в техническом плане (тут обычно все в порядке), а в социальном, в способности работать в коллективе и ставить общественные интересы выше собственных.
Ну а мораль сей басни проста: если есть стандартные и общепринятые решения – то следует их использовать, даже если вы можете за пять минут левым задним копытом набросать скрипт «в 1000 раз лучше».
Ну или пишите и выкладывайте его на GitHub и когда его начнут включать в дистрибутивы и использовать массы – тогда можно будет использовать его как стандартное решение.
👍32🤮6❤4💯4🔥2
Ремесло или магия?
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
Все, кто в школе хоть немного учил историю должны знать историю ремесленничества, когда люди, обладающие определенными знаниями и умениями, объединялись в цеха как для защиты от конкуренции, так и для сохранения и преумножения знаний.
Цеха имели трехуровневую структуру: ученик – подмастерье – мастер. Причем чтобы стать последним, нужно было пройти своеобразный экзамен: собственноручно выполнить работу, которая будет одобрена цехом.
Через какое-то время конкурировать с цехами стало сложно, да, мастер-одиночка тоже мог достигнуть определенных высот, но доходя до всего своим умом и методом проб и ошибок, тогда как цех располагал накопленным объемом знаний и системой их передачи от мастера к ученику.
Причем знания передавались дозировано, более сложные знания передавались после того, как ученик усвоил и научился применять на практике более простые.
Этот принцип перешел в образование, там тоже знания передаются дозированно, чтобы более сложные ложились на базис более простых.
А производственные отношения в целом продолжали цеховые традиции, когда более опытные специалисты передавали свои знания и умения молодым, помогая постигнуть все тонкости профессии.
Но наш век информационной доступности спутал все карты. Сейчас ученик, даже не подмастерье, может спокойно получить рецепты мастера и даже попытаться применить их на практике. Только вот станет ли он от этого мастером? Вряд-ли…
Что отличает мастера от ученика или подмастерья? Знания и опыт. Он знает не только как сделать, но и почему нужно делать именно так, а не иначе. И также он знает в каких случаях надо делать именно так, а в каких случаях делать так, наоборот не надо. Не говоря уже о том, что простые пути не всегда самые верные.
Сегодня сеть дает возможность найти большое количество инструкций «от мастеров» и выбор часто делается по принципу: вот эта инструкция проще и мне больше нравится. Ну а то, что писал эту инструкцию совсем не мастер, а захудалый подмастерье, большинству берущих подобные инструкции неведомо.
Главное, что все быстро, просто и дает желаемый результат. На первый взгляд дает. Потому как уровня знаний, дающих возможность всесторонне оценить решение нет. А настоящий мастер, предлагающий правильное, но излишне сложное решение, представляется некоторым занудой.
Ну что ты там нудишь? Видишь, чего я нашел, тяп-ляп и в продакшен. Дешево и практично.
Прозрение наступает поздно и, иногда, с очень неприятными побочными «эффектами».
И иногда думаешь, что правы были цеховые мастера прошлых лет, ибо известно, что многие знания – многие печали, особенно если они достались неокрепшим умам.
Может кто-то посчитает это за профессиональный снобизм, но знания не должны опережать текущий уровень подготовки.
Раньше с этим было попроще, неподготовленного специалиста никто бы не пустил на участок, явно превышающий его квалификацию.
Теперь же есть сеть, в которой можно найти пошаговое описание обрядов и заклинаний, которые, при их тщательном исполнении дадут желаемый результат.
Ну, и как положено настоящей магии, начали появляться различные волшебные артефакты, которые активируются волшебным словом
docker run. Как они работают – неизвестно, да и не нужно. Что-то пошло не так? Убиваем артефакт и активируем новый. Таким образом ремесло начинает деградировать до волшебства. А далее знания незаметно уступят обрядам и поклонениям высшим силам. И возникнет новая каста жрецов – редких представителей рода человеческого, которые знают, как это все работает и умеющих находит общий язык с «высшими силами», ну или диктовать их волю «простым смертным» к собственной выгоде.
Возможно, я где-то сгустил краски, но в целом тенденция именно такая. Сегодня уже каждый может стать «мастером» найдя и повторив дословно нужный рецепт. А так как знаний от этого не прибавится, то система будет восприниматься некоторым «волшебным» черным ящиком.
Откуда уже недалеко до настоящих черных ящиков – готовых контейнеров. Да и пес его знает, что там внутри, главное же - слушаются заклинаний...
💯40👍12🔥9🤮2👎1
Аппаратные часы и системное время
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
В Linux для переключения на поясное время и обратно используйте:
Время – важный параметр современных систем, так как временная метка является одной из переменных в криптографических преобразованиях и отклонение системного времени от точного может привести к различным проблемам.
Но есть и еще один тонкий момент – аппаратные часы – RTC (Real Time Clock), они же часы CMOS / BIOS.
Они отличаются от системных часов, полностью программных, тем, что являются аппаратными и идут даже тогда, когда компьютер выключен. При загрузке система считывает данные аппаратных часов и принимает их за системное время, после чего начинают работать системные часы.
Системные часы мы можем подвести от часов точного времени благодаря протоколу NTP, тем самым обеспечив соответствие системного времени точному. Затем, при выключении (либо можно выполнить эту операцию вручную), система подводит аппаратные часы на материнской плате.
И вот тут возникает ряд тонкостей. Linux считает, что аппаратные часы показывают время UTC (универсальное время, оно же по Гринвичу). Т.е. если в системе мы установили часовой пояс UTC +3 (Москва) и на часах у нас 15:00, то система установит аппаратные часы на 12:00.
Windows же считает что аппаратные часы идут в поясном времени, т.е. если у нас в системе стоит тот же часовой пояс UTC +3 и на часах 15:00, то и в аппаратные часы будет записано такое-же время.
Это вызывало многочисленные приключения при использовании двойной загрузки Linux и Windows на ПК. Но, казалось бы, те времена давно прошли.
Да, сегодня двойная загрузка проходит по разряду экзотики, но на смену ей пришла виртуализация. Многие системы виртуализации поддерживают синхронизацию времени между виртуальной машиной и гипервизором, а службы синхронизации внутри виртуальной машины отключаются, обнаружив себя в виртуалке.
И вот тут начинаются чудеса. Хост отдает виртуалке время как RTC, при этом отдает согласно собственному пониманию. Т.е. хост на Linux отдаст UTC, а хост Windows – поясное время.
В первом случае Linux-гость правильно прибавит к этому значению поясное время и получит правильное значение, а вот Windows будет считать время локальным и будет отставать (или спешить) на разницу между часовым поясом и UTC.
Во втором Windows-гость покажет правильное время, а Linux добавит к нему смещение часового пояса и будет спешить или отставать.
В большинстве случаев это решается в настройках параметров виртуальной машины, но иногда может потребоваться и ручное вмешательство.
Для того чтобы Windows использовал аппаратные часы как UTC выполните:
reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Чтобы переключиться назад просто удалите этот ключ в реестре.В Linux для переключения на поясное время и обратно используйте:
timedatectl set-local-rtc 1
и timedatectl set-local-rtc 0
Ну и в любом непонятном случае с часами всегда начинайте с того, в каком режиме идут RTC и в каком режиме его воспринимает система.
👍51❤10🔥4
Как скачать DEB-пакет со всеми зависимостями
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
После чего перейдем к скачиванию:
Почему именно
Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
После чего точно также делаем:
После чего переходим в
Необходимость скачать DEB-пакет со всеми зависимостями для дальнейшей локальной установки возникает не так уж и редко. Это могут быть закрытые системы или системы с невысокой скоростью связи или лимитированным трафиком.
Сделать это весьма просто, причем без всякой особой консольной магии, с использованием штатных возможностей apt.
Все скачанные пакеты система размещает в каталоге
/var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.apt clean
После чего перейдем к скачиванию:
apt reinstall --download-only package_name
Почему именно
reinstall? Потому что install будет работать только для неустановленных пакетов, а если пакет уже установлен в системе, то она сообщит об этом и не будет производить установку (в нашем случае скачивание, а reinstall скачает пакеты в любом случае.Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:
dpkg --add-architecture i386
apt update
После чего точно также делаем:
apt reinstall --download-only package_name:i386
После чего переходим в
/var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.
👍56❤7
Субботнее, о «братьях» наших меньших
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?
Читаю тут время от времени соседские новости и наблюдаю привычную многим картину: террор (а по-другому я тут не скажу) бродячих собак по отношению к местному населению и их питомцам.
Выше два ролика из города Курска, где стая агрессивно атакует домашних питомцев и их хозяев. Но это еще не беда, это ее половина, настоящая беда в отношении местной власти к данной проблеме. Ответ администрации просто убивает, выделение мое:
«28.05.2025г. по адресу: г. Курск, ул. Майский бульвар, д. 27 был осуществлен выезд сотрудников подрядной организации. Отловлена одна собака, а так же установлено наличие собак с метками. В соответствии с действующим Федеральным законом от 27.12.2018г. № 498-ФЗ, животные имеющие, метки отлову не подлежат».
Отлично? Да просто зашибись! Поймали, стерилизовали, повесили бирку и отпустили, где взяли. А бирка, по мнению данных товарищей, сразу сделает собаку доброй и пушистой.
Но собака, как бы не хотелось некоторым отрицать данный факт – стайный хищник, с многовековыми инстинктами на подкорке, которые не вытравливаются оттуда не стерилизацией, ни биркой.
И если собака с биркой в единственном экземпляре может быть доброй, ласковой и пушистой, то в стае – это хищник, машина для убийства. Но на это старательно закрывают глаза.
А если человек, исключительно в целях самообороны, возьмет хороший дрын и нанесет собаченьке увечья несовместимые с нормальной жизнедеятельностью организма, то ему грозит вполне реальное административное или даже уголовное наказание.
И вот здесь логика происходящего от меня полностью ускользает. Бродячая собака может изувечить или вообще убить вашего домашнего питомца, и никто за это отвечать не будет. Может нанести увечья и даже убить человека, ответственность за это снова никто не понесет. Проверено неоднократными случаями. Особенно если у собак есть метка.
Если же человек нанесет увечья или, не приведи Господь, прибьет собаченьку – то проблемы ему гарантированы.
Хотя, по логике вещей, если собака – дикий зверь, а бродячая собака – это именно дикий зверь, угрожает жизни и здоровью человека, то такая собака должна быть ликвидирована, просто и без затей.
Представителям зоошизы, у которых все собаченьки добрые и пушистые, а нападают они только в ответ на агрессию человека, могу предложить забрать таких собак себе домой или просто заткнуть рты и помолчать.
Так вот любой дикий зверь, проявляющий агрессию на человека в его естественной среде обитания (городе, селе – не важно), должен быть быстро и без затей ликвидирован.
Бродячая собака – это именно дикий зверь, далеко не в первом поколении. Выброшенные собаки долго на улице не живут они или не переживают зиму, или становятся жертвами бродячих стай. Так что перекладывать ответственность на человека тут тоже не следует.
Но у нас почему-то существует необъяснимый перекос, когда жизнь и здоровье человека ничего не значит против жизни и здоровья собаки, которая оказывается защищена законом гораздо лучше гражданина и налогоплательщика.
Такой вот парадокс, а вы что думаете по этому поводу?
💯74👍12👎6🤡5🤔3
Версии PowerShell
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.
Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.
PowerShell Core имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.
❤18🫡9🥱4👀4🔥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.
👍55🔥13❤7
Что такое PowerShell и чем он отличается от своих аналогов
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
Практически после каждой нашей публикации PowerShell появлются негативные комментарии или вообще агрессивное отрицание данного продукта. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.
Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.
Начнем с небольшого экскурса в историю. Для обеспечения интерфейса командной строки были придуманы командные интерпретаторы, которые представляли собой скриптовые языки с определенным набором возможностей.
Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.
К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.
Одной из характерных особенностей этих языков является текстовый интерфейс взаимодействия, что вынуждает при анализе и обработке результата прибегать к сериализации или парсингу.
Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.
Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.
Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.
Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.
Это же наложило отпечаток и на его синтаксис, он также сильно отличается от синтаксиса языков оболочек и гораздо ближе к обычным языкам программирования.
И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.
Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».
В PowerShell решили подойти с другой стороны и его синтаксис позволяет читать скрипты буквально налету, понимая, что они делают без обращения к документации. При написании скриптов это также не вызывает сложности благодаря возможностям сред разработки.
При этом мы согласимся с тем, что для повседневного администрирования синтаксис PowerShell неудобен и многословен, однако он поддерживает алиасы, позволяющие работать в привычном коротком, но практически нечитабельном, синтаксисе.
Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.
👍30👀3🔥2❤1😱1
Как создать копию драйверов текущего ПК не прибегая к сторонним инструментам
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Кроме PowerShell вы также можете использовать DISM:
Или pnputil, что актуально для старых систем, начиная с Windows 7:
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Export-WindowsDriver —Online —Destination F:\Drivers
Кроме PowerShell вы также можете использовать DISM:
dism /online /export-driver /destination: F:\Drivers
Или pnputil, что актуально для старых систем, начиная с Windows 7:
pnputil.exe /export-driver * F:\Drivers
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
👍101❤10⚡5🔥2
Используем ImDisk для эмуляции флешек и других типов накопителей
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
Современный мир все больше и больше переходит к использованию онлайн-хранилищ и привычные типы физических накопителей потихоньку становятся историей.
При этом необходимость их использования все еще остается, а некоторый специализированный софт может прямо требовать наличие физического накопителя. Но это не всегда возможно, например, в виртуальных средах или на удаленных системах. В этом случае нам на помощь придут эмуляторы.
В данной статье мы рассмотрим работу с ImDisk - простым и мощным решением для работы с виртуальными накопителями.
https://interface31.ru/tech_it/2024/05/ispol-zuem-imdisk-dlya-emulyacii-fleshek-i-drugih-tipov-nakopiteley.html
1👍38🔥2❤1
Немного о телеметрии
Есть темы, при обсуждении которых многие коллеги утрачивают остатки здравого смысла и начинают оперировать домыслами, один другого удивительнее.
Одной из таких тем является телеметрия. И больше всех здесь достается компании Microsoft, которую в чем только не обвиняют, вплоть до сбора скринштов рабочего стола.
При этом включить мозги и подумать, а зачем компании ваши скриншоты – это задача, явно выходящая за пределы пантеона мифов и легенд, к коим относится и телеметрия.
При этом как-то все забывают, что в кармане у каждого есть персональный сборщик телеметрии и не только: смартфон. И объемы собираемой им информации в разы превосходят то, что собирает Microsoft и Windows.
Загляните хотя бы в Цифровое благополучие от Google, оно прекрасно осведомлено о вашем режиме дня и отдыха, месте жительства, месте работы и т.д. и т.п.
Google вместе с Apple также прекрасно осведомлены о ваших передвижениях, способе передвижения, кулинарных, музыкальных и литературных предпочтениях и еще о многом, многом другом.
Также мы носим на руке умные часы или фитнесс-браслеты, которые имеют доступ к данным о состоянии здоровья и физической активности организма. Все это тоже передается на сервера (облачные функции) и как минимум анализируется на базовом уровне, чтобы выдать вам персональные рекомендации.
Кроме того, нашу активность отслеживают сайты, браузеры, мобильные приложения. Собирая данные о наших вкусах, предпочтениях и поведенческих факторах.
И я не скажу, что это плохо. Телеметрия это просто инструмент и использовать его можно по-разному. Например, я предпочитаю, чтобы рекламные сети показывали мне рекламу на основе моих запросов, а не случайно подобранную.
Тем более что таким образом я уже находил интересные предложения, которые вряд ли бы начал искать сам.
Также мне нравится, когда приложение для заказа продуктов предлагает мне что-то новое из тех категорий, которые я предпочитаю, а не непонятно что.
Но это взгляд с одной стороны, стороны потребителя. А теперь поменяем позиции на другую сторону баррикад.
Как владелец сайта я размещаю на нем счетчики, которые не только ведут подсчет посетителей, но и отслеживают их активность в весьма широком диапазоне. Самые известные – это счетчики от Google и Яндекса.
Благодаря их аналитике я могу не только посмотреть сколько страниц моего сайта было просмотрено, но и получить достаточно подробную информацию о посетителях, их устройствах, программному обеспечению, половзрастной структуре, личным предпочтениям и интересам.
Также я могу изучить поведенческие факторы для каждой статьи, например, сколько посетителей дочитало ее до конца.
Все это помогает делать материал на сайте полезнее и увеличивать удобство сайта для посетителей. Скажем, располагая данными об экранных разрешениях устройств можно выбрать оптимальные размеры изображения и макета сайта.
А зная поведенческие факторы более доступно доносить материал. Например, было выяснено, что есть некий предельный объем статьи, после которого количество дочитываний начинает падать. Исходя из этого мы стали делить материал на части меньшего объема.
Выигрывает ли от этого читатель? Конечно выигрывает. Например, я тоже не очень люблю длинные статьи, какие бы интересные они не были. Потому что их прочтение отнимает много времени и внимания.
Но и короткие, поверхностные статьи – это тоже не очень хорошо. Где же золотая середина? Ее как раз дает телеметрия.
Поэтому, повторюсь, телеметрия – это не хорошо и не плохо. Это неотъемлемая часть жизни, делающей ее немного лучше и удобнее в обмен на некоторые наши данные.
Плохо – это когда телеметрия начинает нарушать личные пределы и собирать чувствительную личную информацию и персональные данные. Это, конечно же, недопустимо и этому следует обязательно препятствовать.
Есть темы, при обсуждении которых многие коллеги утрачивают остатки здравого смысла и начинают оперировать домыслами, один другого удивительнее.
Одной из таких тем является телеметрия. И больше всех здесь достается компании Microsoft, которую в чем только не обвиняют, вплоть до сбора скринштов рабочего стола.
При этом включить мозги и подумать, а зачем компании ваши скриншоты – это задача, явно выходящая за пределы пантеона мифов и легенд, к коим относится и телеметрия.
При этом как-то все забывают, что в кармане у каждого есть персональный сборщик телеметрии и не только: смартфон. И объемы собираемой им информации в разы превосходят то, что собирает Microsoft и Windows.
Загляните хотя бы в Цифровое благополучие от Google, оно прекрасно осведомлено о вашем режиме дня и отдыха, месте жительства, месте работы и т.д. и т.п.
Google вместе с Apple также прекрасно осведомлены о ваших передвижениях, способе передвижения, кулинарных, музыкальных и литературных предпочтениях и еще о многом, многом другом.
Также мы носим на руке умные часы или фитнесс-браслеты, которые имеют доступ к данным о состоянии здоровья и физической активности организма. Все это тоже передается на сервера (облачные функции) и как минимум анализируется на базовом уровне, чтобы выдать вам персональные рекомендации.
Кроме того, нашу активность отслеживают сайты, браузеры, мобильные приложения. Собирая данные о наших вкусах, предпочтениях и поведенческих факторах.
И я не скажу, что это плохо. Телеметрия это просто инструмент и использовать его можно по-разному. Например, я предпочитаю, чтобы рекламные сети показывали мне рекламу на основе моих запросов, а не случайно подобранную.
Тем более что таким образом я уже находил интересные предложения, которые вряд ли бы начал искать сам.
Также мне нравится, когда приложение для заказа продуктов предлагает мне что-то новое из тех категорий, которые я предпочитаю, а не непонятно что.
Но это взгляд с одной стороны, стороны потребителя. А теперь поменяем позиции на другую сторону баррикад.
Как владелец сайта я размещаю на нем счетчики, которые не только ведут подсчет посетителей, но и отслеживают их активность в весьма широком диапазоне. Самые известные – это счетчики от Google и Яндекса.
Благодаря их аналитике я могу не только посмотреть сколько страниц моего сайта было просмотрено, но и получить достаточно подробную информацию о посетителях, их устройствах, программному обеспечению, половзрастной структуре, личным предпочтениям и интересам.
Также я могу изучить поведенческие факторы для каждой статьи, например, сколько посетителей дочитало ее до конца.
Все это помогает делать материал на сайте полезнее и увеличивать удобство сайта для посетителей. Скажем, располагая данными об экранных разрешениях устройств можно выбрать оптимальные размеры изображения и макета сайта.
А зная поведенческие факторы более доступно доносить материал. Например, было выяснено, что есть некий предельный объем статьи, после которого количество дочитываний начинает падать. Исходя из этого мы стали делить материал на части меньшего объема.
Выигрывает ли от этого читатель? Конечно выигрывает. Например, я тоже не очень люблю длинные статьи, какие бы интересные они не были. Потому что их прочтение отнимает много времени и внимания.
Но и короткие, поверхностные статьи – это тоже не очень хорошо. Где же золотая середина? Ее как раз дает телеметрия.
Поэтому, повторюсь, телеметрия – это не хорошо и не плохо. Это неотъемлемая часть жизни, делающей ее немного лучше и удобнее в обмен на некоторые наши данные.
Плохо – это когда телеметрия начинает нарушать личные пределы и собирать чувствительную личную информацию и персональные данные. Это, конечно же, недопустимо и этому следует обязательно препятствовать.
🤮14👍11👌11🤔4👀2
🔮 Приглашаем на вебинар по CVoS — узнайте, как зарезервировать облачные ресурсы Yandex Cloud с выгодой до 22%
10 июня в 11:00 по мск эксперты Yandex Cloud, FinOps-платформы «Клаудмастер» и Hilbert Team расскажут, как превратить резервирование ресурсов в надежный инструмент экономии без рисков.
Вы узнаете:
— CVoS: что это и с чем его едят
— Секреты CVoS: как резервирование ресурсов защитит от повышения тарифов и перерасхода бюджета
— Как FinOps-подход помогает оценить объем ресурсов, покрываемых CVoS, без рисков переплаты
— Пошаговый алгоритм подключения CVoS от «Клаудмастер» — начиная с анализа нагрузки и заканчивая оценкой потенциальной экономии
— CVoS в Yandex Cloud: выгодные условия подключения от провайдера
— Разбор полетов: кейсы компаний, которые подключили CVoS и сэкономили до 22% бюджета
Ждем техдиров, DevOps-инженеров, финансовых специалистов и всех, кому интересна тема оптимизации ИТ-инфраструктуры и управления облачными ресурсами.
👉 Регистрируйтесь на вебинар по ссылке
✉️ После мероприятия все участники получат видеозапись вебинара, презентацию экспертов и расширенный доступ к триальной версии FinOps-платформы «Клаудмастер» на 30 дней.
10 июня в 11:00 по мск эксперты Yandex Cloud, FinOps-платформы «Клаудмастер» и Hilbert Team расскажут, как превратить резервирование ресурсов в надежный инструмент экономии без рисков.
Вы узнаете:
— CVoS: что это и с чем его едят
— Секреты CVoS: как резервирование ресурсов защитит от повышения тарифов и перерасхода бюджета
— Как FinOps-подход помогает оценить объем ресурсов, покрываемых CVoS, без рисков переплаты
— Пошаговый алгоритм подключения CVoS от «Клаудмастер» — начиная с анализа нагрузки и заканчивая оценкой потенциальной экономии
— CVoS в Yandex Cloud: выгодные условия подключения от провайдера
— Разбор полетов: кейсы компаний, которые подключили CVoS и сэкономили до 22% бюджета
Ждем техдиров, DevOps-инженеров, финансовых специалистов и всех, кому интересна тема оптимизации ИТ-инфраструктуры и управления облачными ресурсами.
👉 Регистрируйтесь на вебинар по ссылке
✉️ После мероприятия все участники получат видеозапись вебинара, презентацию экспертов и расширенный доступ к триальной версии FinOps-платформы «Клаудмастер» на 30 дней.
❤4👍3🔥2
Философия UNIX и современность
Про философию UNIX слышали многие, это некий неформальный свод правил, которым руководствовались первые разработчики UNIX.
Впоследствии данные правила стали использоваться как прямыми наследниками UNIX (Solaris, BSD), так и системами, сделанными по образу и подобию (Linux) и именно следование данной философии позволяет говорить о семействе UNIX-подобных операционных систем.
Для понимания причин возникновения данной философии следует окунуться в исторический контекст разработки UNIX.
Одной из главных задач разработчики видели переносимость, в те годы не существовало универсальной операционной системы, каждый производитель оборудования писал что-то свое, с другим оборудованием несовместимое.
Второй важный аспект – крайняя ограниченность ресурсов, Кен Томпсон изначально писал новую ОС для компьютера PDP-7 оперативная память которого составляла всего 4000 18-битных слов, что оправдывалось предельно низкой ценой данной модели – 72 000$ (711 000$ по нынешнему курсу).
Сегодня компьютеры уже совсем иные и многие вещи, которые волновали разработчиков UNIX уже неактуальны, но философия, заложенная ими в основу системы живет и иногда сбивает с толку современное поколение администраторов.
К написанию данной заметки нас сподвигло то, что уже не раз и не два читатели высказывали свое недоумение или непонимание работы различных Linux программ, которое вытекало как раз из непонимания философии UNIX.
Обычно это касается старых, классических программ и утилит, но также этой философии могут следовать и многие современные службы.
В основе философии UNIX лежит следующий постулат:
Разрабатывайте программы так, чтобы они выполняли только одну задачу, но делали это хорошо, и чтобы они хорошо работали вместе с другими программами.
В те времена это было как нельзя актуально, ограниченность ресурсов не позволяла писать сложные программы, но можно было вызвать последовательно несколько простых программ, которые вместе дали бы требуемый результат.
Но в этом кроется и более глубокий смысл: каждая программа должна делать что-то одно, но делать это хорошо. Простые программы легче поддерживать, в них меньше ошибок и они работают быстрее.
Но это и первая причина недоумения современных администраторов, когда они спрашивают, а умеет ли данная программа это и сильно удивляются, когда им говорят, что нет и нужно дополнительно использовать еще это, это и это.
С другой стороны подобная гибкость позволяет быстро и просто построить именно то, что требуется в данном случае, без оглядки на реализацию в той или иной программе. Когда система построена из простых кубиков гораздо проще заменить один кубик другим, чем сделать это в сложной системе.
Второй важный постулат – правило тишины. Программы по умолчанию не должны ничего говорить (т. е. не выдавать никаких результатов). Это тоже повергает в ступор многих, привыкших к современному информационному шуму и многословию.
Я ввел команду и ничего не произошло… Как так???
На самом деле команда выполнила свое действие, но если все прошло как надо, то зачем об этом говорить? Ведь это же очевидно. И этот принцип продолжает соблюдаться и во многих современных системах.
Например, перезапуск службы. Если все прошло нормально, то вы не получите никакого результата, но будете уведомлены в случае возникновения каких-либо ошибок.
Ну и третий принцип – это использование читаемого текста для обмена как с пользователем, так и между программами.
Данный принцип часто преподносился как недостаток, мол текст архаичен, неудобен и т.д. и т.п.
Но сегодня мы снова видим возврат к тексту, как средству обмена в информационных системах и, хотя вместо плоского текста чаще используются XML или JSON – это снова текст, который одинаково удобно читается как человеком, так и компьютером.
Поэтому говорить о том, что философия UNIX устарела преждевременно, она жива и оказывает сильное воздействие на современные Linux системы. А каждый администратор должен знать ее хотя вы в общих чертах.
Про философию UNIX слышали многие, это некий неформальный свод правил, которым руководствовались первые разработчики UNIX.
Впоследствии данные правила стали использоваться как прямыми наследниками UNIX (Solaris, BSD), так и системами, сделанными по образу и подобию (Linux) и именно следование данной философии позволяет говорить о семействе UNIX-подобных операционных систем.
Для понимания причин возникновения данной философии следует окунуться в исторический контекст разработки UNIX.
Одной из главных задач разработчики видели переносимость, в те годы не существовало универсальной операционной системы, каждый производитель оборудования писал что-то свое, с другим оборудованием несовместимое.
Второй важный аспект – крайняя ограниченность ресурсов, Кен Томпсон изначально писал новую ОС для компьютера PDP-7 оперативная память которого составляла всего 4000 18-битных слов, что оправдывалось предельно низкой ценой данной модели – 72 000$ (711 000$ по нынешнему курсу).
Сегодня компьютеры уже совсем иные и многие вещи, которые волновали разработчиков UNIX уже неактуальны, но философия, заложенная ими в основу системы живет и иногда сбивает с толку современное поколение администраторов.
К написанию данной заметки нас сподвигло то, что уже не раз и не два читатели высказывали свое недоумение или непонимание работы различных Linux программ, которое вытекало как раз из непонимания философии UNIX.
Обычно это касается старых, классических программ и утилит, но также этой философии могут следовать и многие современные службы.
В основе философии UNIX лежит следующий постулат:
Разрабатывайте программы так, чтобы они выполняли только одну задачу, но делали это хорошо, и чтобы они хорошо работали вместе с другими программами.
В те времена это было как нельзя актуально, ограниченность ресурсов не позволяла писать сложные программы, но можно было вызвать последовательно несколько простых программ, которые вместе дали бы требуемый результат.
Но в этом кроется и более глубокий смысл: каждая программа должна делать что-то одно, но делать это хорошо. Простые программы легче поддерживать, в них меньше ошибок и они работают быстрее.
Но это и первая причина недоумения современных администраторов, когда они спрашивают, а умеет ли данная программа это и сильно удивляются, когда им говорят, что нет и нужно дополнительно использовать еще это, это и это.
С другой стороны подобная гибкость позволяет быстро и просто построить именно то, что требуется в данном случае, без оглядки на реализацию в той или иной программе. Когда система построена из простых кубиков гораздо проще заменить один кубик другим, чем сделать это в сложной системе.
Второй важный постулат – правило тишины. Программы по умолчанию не должны ничего говорить (т. е. не выдавать никаких результатов). Это тоже повергает в ступор многих, привыкших к современному информационному шуму и многословию.
Я ввел команду и ничего не произошло… Как так???
На самом деле команда выполнила свое действие, но если все прошло как надо, то зачем об этом говорить? Ведь это же очевидно. И этот принцип продолжает соблюдаться и во многих современных системах.
Например, перезапуск службы. Если все прошло нормально, то вы не получите никакого результата, но будете уведомлены в случае возникновения каких-либо ошибок.
Ну и третий принцип – это использование читаемого текста для обмена как с пользователем, так и между программами.
Данный принцип часто преподносился как недостаток, мол текст архаичен, неудобен и т.д. и т.п.
Но сегодня мы снова видим возврат к тексту, как средству обмена в информационных системах и, хотя вместо плоского текста чаще используются XML или JSON – это снова текст, который одинаково удобно читается как человеком, так и компьютером.
Поэтому говорить о том, что философия UNIX устарела преждевременно, она жива и оказывает сильное воздействие на современные Linux системы. А каждый администратор должен знать ее хотя вы в общих чертах.
1👍54❤1🥱1💯1
Как установить магазин и современные приложения в Windows 11 LTSC
Уж сколько раз твердили миру, что LTSC редакции Windows – это не для повседневной работы и даже не для корпоративного сектора, а для ряда систем (POS-системы, промышленное и медицинское оборудование и т.д. и т.п.), где на первый план выходит стабильность и неизменность кодовой базы, а не все остальное.
👉 Более подробно (пусть и про Windows 10), можно прочитать в нашей статье: Чем является и чем не является Windows 10 LTSB/LTSC
Но кто же читает большие и скучные статьи, особенно если в них написано совсем не то, что хочется прочитать. Так в очередной раз и случилось. Третьего дня один молодой коллега задал нам вопрос – а сталкивались ли мы с Windows 11 LTSC, потому что он поставил ее к себе на ноутбук и ему теперь кажется, что он скачал и поставил что-то не то.
Почему? Да потому что в системе не оказалось ни нового Блокнота, ни новых Ножниц с распознаванием текста, но это мелочи, в системе даже не оказалось нового терминала, к которому коллега привык и отказываться от которого упорно не желал.
Зачем при этом ставить LTSC-редакции оставим за кадром, так как это тема не рациональная, а из разряда религиозных предпочтений, которые, как известно, являются личным делом каждого.
Но с подобной проблемой могут столкнуться и вполне добросовестные пользователи данной системы, получившие ее с оборудованием.
К счастью, поправить эту проблему несложно, причем не прибегая к никаким нештатным методам, кодовая база у всех редакций Windows общая, разница только в доступных по умолчанию компонентах.
Здесь можно пойти двумя путями: сделать все самому руками или воспользоваться готовыми инструментами, которые сделают все тоже самое за нас.
Если вы решили идти по второму пути, то можно воспользоваться готовыми репозиториями на GitHub, например, этим: https://github.com/QuangVNMC/LTSC-Add-Microsoft-Store
Их содержимое практически одинаково – набор необходимых зависимостей и скрипт для их установки. Скрипт простой, читается быстро и просто. Это к тому, что чужие скрипты перед запуском надо все-таки просматривать.
После его запуска в системе появится поддержка магазина и современных приложений, после чего вы можете установить все, чего вам так не хватало хоть через магазин, хоть посредством WinGet или вообще скачав appx с того же Github.
Уж сколько раз твердили миру, что LTSC редакции Windows – это не для повседневной работы и даже не для корпоративного сектора, а для ряда систем (POS-системы, промышленное и медицинское оборудование и т.д. и т.п.), где на первый план выходит стабильность и неизменность кодовой базы, а не все остальное.
👉 Более подробно (пусть и про Windows 10), можно прочитать в нашей статье: Чем является и чем не является Windows 10 LTSB/LTSC
Но кто же читает большие и скучные статьи, особенно если в них написано совсем не то, что хочется прочитать. Так в очередной раз и случилось. Третьего дня один молодой коллега задал нам вопрос – а сталкивались ли мы с Windows 11 LTSC, потому что он поставил ее к себе на ноутбук и ему теперь кажется, что он скачал и поставил что-то не то.
Почему? Да потому что в системе не оказалось ни нового Блокнота, ни новых Ножниц с распознаванием текста, но это мелочи, в системе даже не оказалось нового терминала, к которому коллега привык и отказываться от которого упорно не желал.
Зачем при этом ставить LTSC-редакции оставим за кадром, так как это тема не рациональная, а из разряда религиозных предпочтений, которые, как известно, являются личным делом каждого.
Но с подобной проблемой могут столкнуться и вполне добросовестные пользователи данной системы, получившие ее с оборудованием.
К счастью, поправить эту проблему несложно, причем не прибегая к никаким нештатным методам, кодовая база у всех редакций Windows общая, разница только в доступных по умолчанию компонентах.
Здесь можно пойти двумя путями: сделать все самому руками или воспользоваться готовыми инструментами, которые сделают все тоже самое за нас.
Если вы решили идти по второму пути, то можно воспользоваться готовыми репозиториями на GitHub, например, этим: https://github.com/QuangVNMC/LTSC-Add-Microsoft-Store
Их содержимое практически одинаково – набор необходимых зависимостей и скрипт для их установки. Скрипт простой, читается быстро и просто. Это к тому, что чужие скрипты перед запуском надо все-таки просматривать.
После его запуска в системе появится поддержка магазина и современных приложений, после чего вы можете установить все, чего вам так не хватало хоть через магазин, хоть посредством WinGet или вообще скачав appx с того же Github.
👍30❤6🥱5👌3🤮1