Распознаем речь при помощи Whisper
Недавно у нас возникла необходимость транскрибировать ряд аудиофайлов в текст с таймкодами и точным разбитием по фразам.
Задача даже на сегодняшний день нетривиальная, особенно если вам нужен качественный результат. Бесплатные сервисы либо ограничены по времени, либо сильно страдают по качеству.
Поэтому самое время обратиться к достижениям ИИ, а именно Whisper мощной модели для автоматического распознавания речи (ASR) с открытым исходным кодом, разработанная OpenAI.
Вы можете использовать ее через API, но платно, либо установить на собственном ПК – бесплатно, но вам понадобится ПК уровнем от среднего и выше, наличие быстрого ускорителя NVIDIA приветствуется, но не является обязательным требованием.
На самом деле Whisper – это не одна, а целый набор моделей, предлагающий разное качество распознавания речи и разные требования к ресурсам.
На практике имеет смысл использовать модели:
▫️medium – хорошая скорость, среднее качество, 3-5 ГБ ОЗУ
▫️large – профессиональное качество при небольшой скорости и самых больших требованиях к ОЗУ – 10-12 ГБ.
▫️ turbo – то же самое, что и large, но только быстрее, за счет упрощения модели, требует 6-8 ГБ.
В нашем случае требовалось транскрибировать запись судебного заседания и medium не всегда нормально справлялся с юридическими терминами, large и turbo делали это гораздо лучше, при этом turbo сильно заметно быстрее.
Но так как в юридических делах наиболее важна точность, то мы предпочли модель large, предпочитая качество скорости. На CPU Ryzen 9 5900X скорость ее работы составила примерно 0,25, т.е. на часовую запись у вас уйдет примерно 4 часа времени.
Попробовать Whisper можно совсем не сложно на своем оборудовании, после чего самостоятельно сделать выводы о его пригодности в конкретной ситуации. Для работы нам понадобится Python и FFmpeg.
Установим их при помощи пакетного менеджера Winget:
Так как мы имеем дело с Python, то, чтобы избежать возможных проблем с зависимостями и библиотеками хорошим тоном является запуск проекта в отдельном виртуальном окружении (ENV), для этого перейдем в папку проекта, скажем
И активируем его:
Впоследствии, когда вы захотите поработать с проектом еще раз, вам потребуется только заново активировать окружение командой, указанной выше.
Установим Whisper:
После чего просто запускаем распознавание речи командой:
Путь к файлу укажите в двойных кавычках, в пути используйте прямые слеши
Далее указываем язык, модель и формат вывода, если вам нужны точные таймкоды, то используйте стандартный формат субтитров – SRT.
Для использования ускорения на GPU вам потребуется заменить некоторые библиотеки, в этом же ENV выполните:
Затем к строке запуска добавьте дополнительный ключ для использования CUDA:
Если вам нужно дополнительно распознавание спикеров (диаризация), то установите модуль WhisperX:
И добавьте ключ
Теперь вывод кроме таймкодов будет размечаться метками SPEAKER_00, SPEAKER_01 и т.д Но качество такого распознавания не всегда уверенное, особенно если вы транскрибируете прения или дискуссию, где спикеры могут перебивать друг друга.
Недавно у нас возникла необходимость транскрибировать ряд аудиофайлов в текст с таймкодами и точным разбитием по фразам.
Задача даже на сегодняшний день нетривиальная, особенно если вам нужен качественный результат. Бесплатные сервисы либо ограничены по времени, либо сильно страдают по качеству.
Поэтому самое время обратиться к достижениям ИИ, а именно Whisper мощной модели для автоматического распознавания речи (ASR) с открытым исходным кодом, разработанная OpenAI.
Вы можете использовать ее через API, но платно, либо установить на собственном ПК – бесплатно, но вам понадобится ПК уровнем от среднего и выше, наличие быстрого ускорителя NVIDIA приветствуется, но не является обязательным требованием.
На самом деле Whisper – это не одна, а целый набор моделей, предлагающий разное качество распознавания речи и разные требования к ресурсам.
На практике имеет смысл использовать модели:
▫️medium – хорошая скорость, среднее качество, 3-5 ГБ ОЗУ
▫️large – профессиональное качество при небольшой скорости и самых больших требованиях к ОЗУ – 10-12 ГБ.
▫️ turbo – то же самое, что и large, но только быстрее, за счет упрощения модели, требует 6-8 ГБ.
В нашем случае требовалось транскрибировать запись судебного заседания и medium не всегда нормально справлялся с юридическими терминами, large и turbo делали это гораздо лучше, при этом turbo сильно заметно быстрее.
Но так как в юридических делах наиболее важна точность, то мы предпочли модель large, предпочитая качество скорости. На CPU Ryzen 9 5900X скорость ее работы составила примерно 0,25, т.е. на часовую запись у вас уйдет примерно 4 часа времени.
Попробовать Whisper можно совсем не сложно на своем оборудовании, после чего самостоятельно сделать выводы о его пригодности в конкретной ситуации. Для работы нам понадобится Python и FFmpeg.
Установим их при помощи пакетного менеджера Winget:
winget install -e --id Python.Python.3.12
winget install -e --id Gyan.FFmpeg
Так как мы имеем дело с Python, то, чтобы избежать возможных проблем с зависимостями и библиотеками хорошим тоном является запуск проекта в отдельном виртуальном окружении (ENV), для этого перейдем в папку проекта, скажем
F:\Wishper и откроем там терминал с консолью PowerShell, после чего создадим виртуальное окружение:py -m venv whisper-env
И активируем его:
.\whisper-env\Scripts\Activate.ps1
Впоследствии, когда вы захотите поработать с проектом еще раз, вам потребуется только заново активировать окружение командой, указанной выше.
Установим Whisper:
pip install -U openai-whisper
После чего просто запускаем распознавание речи командой:
whisper "audio.mp3" --language ru --model medium --output_format srt
Путь к файлу укажите в двойных кавычках, в пути используйте прямые слеши
/ или обратные удвоенные \\, например:"C:/Users/Имя/audio.mp3"
"C:\\Users\\Имя\\audio.mp3"
Далее указываем язык, модель и формат вывода, если вам нужны точные таймкоды, то используйте стандартный формат субтитров – SRT.
Для использования ускорения на GPU вам потребуется заменить некоторые библиотеки, в этом же ENV выполните:
pip uninstall torch torchvision torchaudio -y
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
Затем к строке запуска добавьте дополнительный ключ для использования CUDA:
whisper "audio.mp3" --language ru --model medium --output_format srt --device cuda
Если вам нужно дополнительно распознавание спикеров (диаризация), то установите модуль WhisperX:
pip install whisperx
И добавьте ключ
–diarize, например:whisperx "audio.mp3" --language ru --model medium –diarize --output_format srt
Теперь вывод кроме таймкодов будет размечаться метками SPEAKER_00, SPEAKER_01 и т.д Но качество такого распознавания не всегда уверенное, особенно если вы транскрибируете прения или дискуссию, где спикеры могут перебивать друг друга.
23👍20👌6
Насколько критично использовать ECC-память для ZFS. Часть_1
Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS.
Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно:
Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные.
В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти.
Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки.
Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным.
Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п.
Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей.
В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study
Согласно этим данным, вероятность ошибки в течении одного года составляет для:
▫️ 1 DIMM – 8.2%
▫️ 4 DIMM – 28.98%
▫️ 8 DIMM – 49.56%
▫️ 16 DIMM – 74.56%
Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит:
▫️ 1 год – 29%
▫️ 3 года -63%
▫️ 5 лет – 82%
Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока.
Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок.
Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки.
Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию.
При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок.
При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей:
🔸 Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год
🔸 Среди «проблемных» DIMM медианное количество ошибок - 64 в год, среднее - 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок)
🔸 Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок
Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените.
Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах.
В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.
Вопрос использования ECC-памяти для ZFS вызывает в обществе множественные споры , а мнения спорящих кардинально расходятся, кто-то говорит, что ECC там даром не нужна, другие возражают, что отсутствие ECC это гарантированный способ полностью убить ZFS.
Начнем с того, что один из соавторов ZFS Мэтью Аренс высказался достаточно однозначно:
В ZFS нет ничего особенного, что требовало бы или поощряло использование ECC‑памяти (памяти с коррекцией ошибок) в большей степени, чем в случае с любой другой файловой системой.
Т.е. никакого особенного требования для использования именно ECC-памяти в ZFS нет, но есть определенные моменты. ZFS – система с контролем целостности и мы ожидаем, что она будет надежно хранить наши данные.
В большинстве случаев так оно и есть, при чтении ZFS проверяет контрольную сумму данных, чтобы быть уверенной, что она отдает именно то, что было записано. Но здесь появляется дополнительный риск в виде памяти.
Если данные в момент чтения в память или записи из нее на диск окажутся повреждены, то ZFS может записать такой блок считая его нормальным. Сама же память без коррекции ошибок неспособна выполнять такие проверки.
Почему может возникнуть ошибка в памяти? Брак или износ модулей мы во внимание не берем, это достаточно легко выявляется через MemTest и такой модуль заменяется исправным.
Мы же говорим о случайных ошибках, которые возникают в исправных модулях при воздействии солнечной радиации, радиоактивном распаде изотопов, входящих в материал модуля, электромагнитных наводках и т.д. и т.п.
Отягчающими факторами становится разгон, плохой тепловой режим, общий износ ячеек, плохие контакты. И основной единицей возникновения ошибки тут является не общий объем памяти, а количество физических модулей.
В дальнейших расчетах мы опирались на статистический материал от Google: DRAM errors in the wild: a large-scale field study
Согласно этим данным, вероятность ошибки в течении одного года составляет для:
▫️ 1 DIMM – 8.2%
▫️ 4 DIMM – 28.98%
▫️ 8 DIMM – 49.56%
▫️ 16 DIMM – 74.56%
Давайте возьмем типичную платформу для домашней лаборатории или сервера небольшой рабочей группы – 4 DIMM, вероятность ошибки составит:
▫️ 1 год – 29%
▫️ 3 года -63%
▫️ 5 лет – 82%
Если взять средний срок эксплуатации системы до апгрейда в 5 лет, но ошибка имеет достаточно большую, но не абсолютную вероятность произойти в течении этого срока.
Что это значит? А это не обязательно говорит о том, что ваши данные будут обязательно повреждены. Если ошибка произошла при чтении, то приложение может просто упасть, не заметить ее (если это стриминговый поток) или откорректировать собственными средствами коррекции ошибок.
Т.е. вероятность того, что ошибочные данные будут записаны на диск, окажется существенно ниже вероятности возникновения ошибки.
Но уже начиная с 16 DIMM риски становятся более серьезными и вероятность ошибки стремится к единице на отрезке времени от 2 лет и более. Но обычно с таким объемом памяти работают серверные системы и ECC там используется по умолчанию.
При этом чем-то критичным данную ситуацию назвать нельзя, да есть определенный риск повреждения данных, он он крайне низок. Гораздо ниже других источников ошибок.
При этом распределение ошибок далеко не равномерное, статистика Google показывает сильный перекос в сторону отдельных модулей:
🔸 Лишь 8,2% всех DIMM сталкиваются с хотя бы одной исправимой ошибкой за год
🔸 Среди «проблемных» DIMM медианное количество ошибок - 64 в год, среднее - 3 751 (сильный перекос из-за небольшого числа модулей с тысячами ошибок)
🔸 Распределение ошибок подчиняется степенному закону: 20% затронутых DIMM генерируют >94% всех ошибок
Таким образом вам скорее повезет, чем не повезет, а если не повезло, то скорее всего такой модуль вы просто отбракуете и замените.
Как видим ничего критичного для ZFS в применении ECC-памяти нет, все ровно тоже самое, что и в других файловых системах.
В следующей части мы разберем, на основе все той же статистики Google вероятность выхода из строя всей ZFS.
👍17❤8🔥5
Windows Vista – провал или…
Windows Vista все считают одним из самых больших провалов Microsoft и в реальности Vista действительно провалилась на рынке, но говорит ли это о том, что Vista была плохой системой?
Вовсе нет, плохой системой Vista не была, но ее провал был неизбежным в тех обстоятельствах и при тех решениях, которые сопутствовали ее выходу на рынок.
Windows XP был несомненным успехом компании, но вместе с тем становилось понятно, что архитектура NT5 себя исчерпала. Нужны были новые решения и на волне эйфории разработчики замахнулись на нечто принципиально новое – проект Blackcomb.
Однако на этом пути что-то пошло не так, планы никак не хотели становиться реальностью и очень скоро стало ясно, что реальных сроков выполнения проекта назвать никто не может, поэтому решили сначала выпустить некоторую промежуточную ОС, которую назвали Longhorn.
Но ее разработка тоже на задалась, в результате в 2004 году проект был перезапущен с нуля и были взяты реальные и достижимые цели, потому что время уже серьезно поджимало, рынок ждал новую ОС от Microsoft, а ее все не было…
Также для новой ОС были крайне велики пользовательские ожидания, во многом подогретые самой Microsoft, все ждали чего-то нового.
Начало разработки тогда еще Blackcomb пришелся на эпоху гонки гигагерц, когда тактовые частоты процессоров постоянно росли и отрасль была полна оптимизма. На момент перезапуска проекта в 2004 году перспективы дальнейшего роста частоты выглядели уже не столь радужно, но все-таки рынок ожидал продолжения роста.
В результате, к моменту выпуска в 2007 году Vista оказалась в ситуации, когда она могла нормально запускаться и работать только на достаточно мощных процессорах и системах от 2 ГБ памяти, что составляло на тот момент верхний сегмент рынка.
В массах же были те самые «два ядра – два гига», причем ядра там были достаточно скоромные 2-2,2 ГГц, в то время как разработчики предполагали массовое распространение систем с частотами 3-4 ГГц.
Но переигрывать что-то было уже поздно, тем более на компанию сильно давили производители ПК, которым нужно было представить на рынке новые компьютеры с Vista и Microsoft серьезно снизила аппаратные требования к системе.
Вторым по силе источником негатива стала новая видеоподсистема WDDM, которая полностью отвязывала видеокарту от ядра системы и значительно повышала стабильность. Если раньше крах видеодрайвера означал крах всей системы, то теперь драйвер просто перезапускался, экран моргал и систем работала дальше.
Но это привело к серьезной просадке производительности, если раньше ваша видеокарта более-менее тянула современные игры, то теперь вам нужно было идти в магазин за новой.
Масла в огонь добавили и программные проблемы. Драйвера к новой системе были не готовы, софт частично несовместим, частично не оптимизирован, вкупе с занижением системных требований это делало Vista похожей на улитку, попавшую в студень.
Многие нововведения были также неотрегулированны и раздражали, тот же излишне назойливый UAC или брандмауэр.
Со временем многие проблемы решили, оптимизировали производительность, подросли вычислительные мощности, но ничего из этого систему спасти уже не могло, что и показал выпуск первого сервис-пака, после которого Vista, по сути, становилась другой системой.
После чего было принято решения закрыть проект и срочно выпустить новую ОС на базе доработанной Vista, которой стала Windows 7 ставшая не менее успешной нежели Windows XP, но это уже совсем другая история.
Но не будем забывать, что все то, что мы видим в современных ОС, включая Windows 10 и Windows 11 было впервые реализовано в Windows Vista и технически это была крайне прогрессивная для своего времени система.
Но условия в которых она была выведена на рынок не оставили ей ни одного шанса на успех.
Windows Vista все считают одним из самых больших провалов Microsoft и в реальности Vista действительно провалилась на рынке, но говорит ли это о том, что Vista была плохой системой?
Вовсе нет, плохой системой Vista не была, но ее провал был неизбежным в тех обстоятельствах и при тех решениях, которые сопутствовали ее выходу на рынок.
Windows XP был несомненным успехом компании, но вместе с тем становилось понятно, что архитектура NT5 себя исчерпала. Нужны были новые решения и на волне эйфории разработчики замахнулись на нечто принципиально новое – проект Blackcomb.
Однако на этом пути что-то пошло не так, планы никак не хотели становиться реальностью и очень скоро стало ясно, что реальных сроков выполнения проекта назвать никто не может, поэтому решили сначала выпустить некоторую промежуточную ОС, которую назвали Longhorn.
Но ее разработка тоже на задалась, в результате в 2004 году проект был перезапущен с нуля и были взяты реальные и достижимые цели, потому что время уже серьезно поджимало, рынок ждал новую ОС от Microsoft, а ее все не было…
Также для новой ОС были крайне велики пользовательские ожидания, во многом подогретые самой Microsoft, все ждали чего-то нового.
Начало разработки тогда еще Blackcomb пришелся на эпоху гонки гигагерц, когда тактовые частоты процессоров постоянно росли и отрасль была полна оптимизма. На момент перезапуска проекта в 2004 году перспективы дальнейшего роста частоты выглядели уже не столь радужно, но все-таки рынок ожидал продолжения роста.
В результате, к моменту выпуска в 2007 году Vista оказалась в ситуации, когда она могла нормально запускаться и работать только на достаточно мощных процессорах и системах от 2 ГБ памяти, что составляло на тот момент верхний сегмент рынка.
В массах же были те самые «два ядра – два гига», причем ядра там были достаточно скоромные 2-2,2 ГГц, в то время как разработчики предполагали массовое распространение систем с частотами 3-4 ГГц.
Но переигрывать что-то было уже поздно, тем более на компанию сильно давили производители ПК, которым нужно было представить на рынке новые компьютеры с Vista и Microsoft серьезно снизила аппаратные требования к системе.
Вторым по силе источником негатива стала новая видеоподсистема WDDM, которая полностью отвязывала видеокарту от ядра системы и значительно повышала стабильность. Если раньше крах видеодрайвера означал крах всей системы, то теперь драйвер просто перезапускался, экран моргал и систем работала дальше.
Но это привело к серьезной просадке производительности, если раньше ваша видеокарта более-менее тянула современные игры, то теперь вам нужно было идти в магазин за новой.
Масла в огонь добавили и программные проблемы. Драйвера к новой системе были не готовы, софт частично несовместим, частично не оптимизирован, вкупе с занижением системных требований это делало Vista похожей на улитку, попавшую в студень.
Многие нововведения были также неотрегулированны и раздражали, тот же излишне назойливый UAC или брандмауэр.
Со временем многие проблемы решили, оптимизировали производительность, подросли вычислительные мощности, но ничего из этого систему спасти уже не могло, что и показал выпуск первого сервис-пака, после которого Vista, по сути, становилась другой системой.
После чего было принято решения закрыть проект и срочно выпустить новую ОС на базе доработанной Vista, которой стала Windows 7 ставшая не менее успешной нежели Windows XP, но это уже совсем другая история.
Но не будем забывать, что все то, что мы видим в современных ОС, включая Windows 10 и Windows 11 было впервые реализовано в Windows Vista и технически это была крайне прогрессивная для своего времени система.
Но условия в которых она была выведена на рынок не оставили ей ни одного шанса на успех.
👍26❤4🤮3
Автоматически обновляем списки адресов Telegram на Mikrotik
Что это и для чего – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают известные сложности, когда хочется не только хлеба (текста), но и зрелищ (картинок с видосиками)
Список нужных нам адресов известен и публикуется официально: https://core.telegram.org/resources/cidr.txt
Поэтому мы снова призвали на помощь ИИ и быстренько написали еще один скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
P.S. Перед запуском убедитесь, что файл с адресами доступен с вашего устройства
👇👇👇
Что это и для чего – рассказывать не надо (надеюсь) и для чего нам могут потребоваться всегда актуальные списки его адресов – тоже.
Иначе возникают известные сложности, когда хочется не только хлеба (текста), но и зрелищ (картинок с видосиками)
Список нужных нам адресов известен и публикуется официально: https://core.telegram.org/resources/cidr.txt
Поэтому мы снова призвали на помощь ИИ и быстренько написали еще один скрипт, который получает этот список и обновляет адресный лист (либо создает при его отсутствии).
Скрипт в комментариях, добавляем в System – Scripts, проверяем. Если все работает – добавляем в планировщик System – Scheduler и пусть от там тихо, скажем, раз в неделю данный список проверяет и обновляет.
P.S. Перед запуском убедитесь, что файл с адресами доступен с вашего устройства
👇👇👇
3👍48❤4
Самостоятельно формируем списки адресов на Mikrotik
Использовать готовые списки хорошо, но не всегда это возможно. Бывает возникает потребность составить список адресов до какого-либо специфического сервиса полного набора доменных имен, которого вы не знаете.
Это характерно для крупных проектов, которые могут использовать разветвленную сеть поддоменов разного уровня и которые могут постоянно изменяться. Скажем сегодня страница содержит ссылки на
Не ловить же постоянно руками? Конечно нет, на роутерах Mikrotik можно автоматизировать выявление таких адресов и добавление их в списки, а использовать мы для этого будем не совсем очевидный метод – запись типа FWD на DNS-сервере.
Данная запись позволяет отправить запрос к домену или полностью всей доменной зоне на сторонний DNS-сервер, но в нашем случае это некритично, можете перенаправить запрос хоть на самого себя, главное - чтобы ответ заслуживал доверия.
Более важно то, что RouterOS позволяет не только перенаправить запрос, но и поместить этот адрес в отдельный список. А это именно то, что нам нужно.
Для реализации просто добавьте запись типа FWD, например:
Данная запись переправит все запросы для доменной зоны example.com вместе с поддоменами на DNS-сервер 10.0.0.1 и внесет запись в список EXAMPLE.
А чтобы не обновлять списки слишком часто зададим разумное время жизни таких записей – сутки:
После чего открываем браузер, переходим на интересующий нас ресурс и наблюдаем за тем как списки автоматически пополняются, причем самыми разнообразными поддоменами, о которых вы раньше могли и не догадываться.
Использовать готовые списки хорошо, но не всегда это возможно. Бывает возникает потребность составить список адресов до какого-либо специфического сервиса полного набора доменных имен, которого вы не знаете.
Это характерно для крупных проектов, которые могут использовать разветвленную сеть поддоменов разного уровня и которые могут постоянно изменяться. Скажем сегодня страница содержит ссылки на
cdn01.example.com, а завтра уже на cdn03.example.com и т.д.Не ловить же постоянно руками? Конечно нет, на роутерах Mikrotik можно автоматизировать выявление таких адресов и добавление их в списки, а использовать мы для этого будем не совсем очевидный метод – запись типа FWD на DNS-сервере.
Данная запись позволяет отправить запрос к домену или полностью всей доменной зоне на сторонний DNS-сервер, но в нашем случае это некритично, можете перенаправить запрос хоть на самого себя, главное - чтобы ответ заслуживал доверия.
Более важно то, что RouterOS позволяет не только перенаправить запрос, но и поместить этот адрес в отдельный список. А это именно то, что нам нужно.
Для реализации просто добавьте запись типа FWD, например:
/ip dns static add address-list=EXAMPLE forward-to=10.0.0.1 match-subdomain=yes name=example.com type=FWD
Данная запись переправит все запросы для доменной зоны example.com вместе с поддоменами на DNS-сервер 10.0.0.1 и внесет запись в список EXAMPLE.
А чтобы не обновлять списки слишком часто зададим разумное время жизни таких записей – сутки:
/ip dns set address-list-extra-time=1d
После чего открываем браузер, переходим на интересующий нас ресурс и наблюдаем за тем как списки автоматически пополняются, причем самыми разнообразными поддоменами, о которых вы раньше могли и не догадываться.
❤11🔥6👍1
Windows Me – не то время, не то место…
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
Еще одна «провальная» ОС от Microsoft - Windows Me (Millenium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).
Хотя, если честно, так сильно хаять Millenium было не за что, просто она появилась не в то время и не в том месте, а потому оказалась некоторым недоразумением, от новой ОС тогда ожидали совсем иного.
Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тода Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.
Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.
Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.
Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.
Это можно заметить буквально во всем, в загрузочном экране, иконках, наборе цветов и т.д. и т.п. Для пользователей 9х это было достаточно свежо и современно.
Также новая система предложила расширенную поддержку мультимедиа и современного оборудования, зарождающейся сети интернет и многое из того, что сегодня воспринимается как должное.
Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии всторенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.
Еще одно важное новшество – это Восстановление системы, штатный инструмент, который позволял делать снимки состояния системы и откатываться на них. Да, работал он через пень-колоду, но раньше ни в линейке 9x, ни в NT ничего подобного не было.
Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.
Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.
Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.
Также ряд старых приложений мог работать в новой системе нестабильно, вызывая многочисленные сбои и перезагрузки. Что и повлекло за собой имидж системы как «глючной».
Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.
Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.
Но по этому же самому поводу она являлась выбором и владельцев устаревших систем, которые начали испытывать с ней серьезные проблемы.
И оно бы, может быть, все утряслось и уладилось, но через год в сентябре 2001 на рынок вышла Windows XP и завоевала там феерический успех.
После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.
Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.
1👍19❤4👨💻3🤮2💯2
Насколько критично использовать ECC-память для ZFS. Часть_2
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
В прошлой части мы рассмотрели общее влияние ошибок памяти на ZFS и выяснили, что риск возникновения таких ошибок невелик, а риск повреждения пользовательских данных еще ниже.
А как быть с самой ZFS, может ли такая ошибка привести к полному разрушению или критическому повреждению файловой системы?
Давайте снова обратимся к статистическому материалу от Google, который содержит данные о вероятности повреждения при возникновении ошибок памяти метаданных ZFS, что теоретически может привести (но не обязательно приведет) к повреждению структуры ZFS.
▫️ 1 DIMM – 0,0428%
▫️ 4 DIMM – 0,171%
▫️ 8 DIMM – 0,341%
С одной стороны, это немного, например, для типичной системы с четырьмя модулями DIMM вероятность повреждения метаданных составит 0,17% в год или 1 случай из 585.
Много это или мало? Для этого давайте сравним вероятность ошибки в памяти с другими событиями, потенциально могущими привести к потере пула, за основу возьмем систему с 4 DIMM и промежуток в 5 лет:
▫️Ошибка в метаданных из-за не-ECC (4 DIMM) – 0,85%
▫️Отказ одного диска в RAID-Z1 – 5-14%
▫️Одновременный отказ 2 дисков в RAID-Z1 – 2,5%
▫️Ошибка администратора (rm -rf, zfs destroy) 2,5-9,6%
Как видим, вероятность разрушения ZFS по причине ошибки в памяти в несколько раз ниже вероятности выхода из строя сразу двух дисков в массиве и еще ниже возможной человеческой ошибки.
Но говорит ли это, что ECC -память для ZFS не нужна? Нет, раз в год и палка стреляет и если есть возможность использовать ECC, то ее нужно использовать. Если же нет, то стоит понимать, что у вас появляются дополнительные риски, которые следует учитывать.
Также следует понимать, что все сказанное выше относится к любой файловой системе, а не только ZFS.
Что касается ZFS, то воспринимать ее как панацею, обеспечивающую надежное хранение тоже не следует. Да, ZFS защищает ваши данные лучше, чем иные файловые системы, но она также имеет точки отказа и может подвергнуться сбоям.
👍20🤔2❤1
Предсказуемые имена сетевых интерфейсов systemd
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
Начиная с версии 197, systemd/udev автоматически назначает предсказуемые, стабильные имена сетевых интерфейсов для всех сетевых интерфейсов. Это решение было встречено, скажем мягко, неоднозначно. Поэтому в данной заметке мы расскажем для чего это сделано и какие проблемы решает.
Начнем с классической схемы с eth, первоначально она базировалась на опросе ядром сетевых устройств по мере их появления, а так как порядок загрузки драйверов может носить случайный характер, то eth0 при следующей загрузке мог стать eth1 и наоборот.
Долгое время для решения этой проблемы использовалась схема присвоения имен на основе MAC-адресов, но она имела существенные недостатки в виде необходимости root-доступа на запись файловой системы и способность впадать в состояние гонки при подключении нового устройства.
С появлением виртуализации возникли новые сложности, связанные с тем, что MAC-адреса сетевых интерфейсов виртуальных машин не являются фиксированными и могут меняться.
Другой применяемый подход – biosdevname, в этом случае ядро пыталось считать из BIOS топологию сетевого устройства по принципу порт – индекс – слот и на этом основании присваивать сетевые имена.
Недостаток данного подхода - он полностью неприменим для не x86 устройств.
Но в целом biosdevname предлагал здравый поход: имена полностью автоматические, полностью предсказуемые, они остаются фиксированными, даже если оборудование добавляется или удаляется (т. е. не происходит повторного нумерации), и сломанное оборудование можно без проблем заменить.
В systemd реализована схема во многом похожая на biosdevname, но более развитая и предполагающее большее сходство имен сетевых интерфейсов с именами других устройств, например, блочных.
Она состоит из нескольких политик:
1️⃣ Имена, включающие индексные номера прошивки/BIOS для встроенных устройств (например: eno1)
2️⃣ Имена, включающие индексные номера слотов PCI Express, предоставленные прошивкой/BIOS (например: ens1)
3️⃣ Имена, включающие физическое/географическое расположение разъема оборудования (например: enp2s0)
4️⃣ Имена, включающие MAC-адрес интерфейсов (например: enx78e7d1ea46da)
5️⃣ Классическое, непредсказуемое именование ethX, встроенное в ядро (например: eth0)
Выбор имени происходит следующим образом: политика 3 если она применима и доступна, иначе переход к политике 2, от нее к политике 1. Если не одна политика не подходит, то применяется политика 5.
Политика 4 никогда автоматически не применяется, но может быть включена системным администратором.
Политика 5 применяется только в крайнем случае. Это означает, что, если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имена устройств ядра, они также будут иметь приоритет. Кроме того, любые схемы именования, специфичные для дистрибутива, также будут иметь приоритет.
Таким образом система предоставляет постоянные и предсказуемые имена для сетевого оборудования вне зависимости от версии драйверов и ядра, а также марки оборудования.
Такие имена не меняются при добавлении или удалении оборудования и сохраняются при его замене. Также это гарантирует неизменность имен в виртуальных средах. И, кроме того, не требуется root-доступ на запись файловой системы.
К недостаткам данной схемы можно отнести некоторую начальную неопределенность, ранее в системе с одним сетевым адаптером он гарантированно был eth0, теперь его наименование следует уточнить перед настройкой.
👍30😢3❤2🤮2👌2
Настройка языка и региональных стандартов в Ubuntu или Debian
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
В Debian пакета console-setup может не оказаться, в таком случае выполните:
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
Данный вопрос достаточно простой, но очень часто про него забывают, вспоминая только тогда, когда это выходит боком. Поэтому лучше сразу уделить внимание этому вопросу и выполнить такую настройку первым делом после установки системы.
Начнем с правильной установки локали, так как именно от нее могут зависеть настройки по умолчанию устанавливаемого ПО и в некоторых случаях их уже не удастся поменять просто и безболезненно.
Для этого выполните команду:
dpkg-reconfigure locales
Перед вами появится большой список локалей – выбираем из них необходимые, обычно достаточно выбрать ru_RU.UTF-8, в некоторых случаях может понадобиться еще en_US.UTF-8, следующим шагом укажите выбранную консоль для использования по умолчанию.
После чего система сгенерирует указанные вами локали и установит выбранную локалью по умолчанию.
Теперь настроим консоль, это необходимо для нормального отображения символов в оболочке:
dpkg-reconfigure console-setup
В Debian пакета console-setup может не оказаться, в таком случае выполните:
apt install console-setup
И повторите предыдущую команду.
На самом первом экране безальтернативно выбираем UTF-8, затем находим и выбираем набор символов Latin; Slavic Cyrillic; Greek. Остальные настройки можете выбрать на свой вкус (размер символов, шрифт и т.д.)
И в заключение сразу правильно установим часовой пояс:
dpkg-reconfigure tzdata
Ничего сложного там нет, выбираем нужный континент и часовой пояс, применяем настройки.
После всех выполненных действий операционную систему следует перезагрузить.
👍37👌5🔥2❤1
Порядок запуска гостевых систем в Proxmox VE
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
Proxmox, как и любая взрослая система виртуализации предоставляет богатые инструменты для управления работой гостевых систем (виртуальных машин и контейнеров), одним из важных параметров работы узла является порядок запуска гостевых систем.
Пока гостей мало обычно этот вопрос не встает на повестке дня, но как только их количество увеличивается и появляются достаточно тяжелые системы, то вопрос начинает вставать ребром.
Начнем с того, что ваша дисковая подсистема может не выдержать одновременного запуска такого количества гостевых систем и серьезно просядет по производительности, в результате чего вы будете бегать вокруг и ждать, когда же оно наконец загрузится.
Также не будет ничего хорошего, если сервер приложений запустится раньше обсуживающего его сервера БД или сетевого хранилища. В общем таких ситуаций может быть много и ничего хорошего из них не получится.
Поэтому берем управление порядком загрузки в свои руки, а именно разделяем гостевые системы по степени важности и критичности, учитывая зависимости между ними.
Первыми ставим наиболее важные системы, обеспечивающие функционирование все инфраструктуры: роутеры, VPN-сервера, DNS, DHCP и т.д. и т.п.
Далее можем запустить контроллеры домена, за ними СУБД, потом сервера приложений, потом все остальное.
Настроить все это можно прямо в графическом интерфейсе в разделе Options виртуальной машины, прежде всего активируйте опцию Start at boot, которая включает автоматическую загрузку гостевой системы.
Затем откройте настройку Start/Shutdown order, где вы можете указать порядок загрузки/выключения, для этого можете использовать любые целые положительные числа.
При включении узла гипервизор проверяет все гостевые системы, у которых включена автозагрузка и строит очередь согласно указанным значением порядка. Очередь у контейнеров и виртуальных машин общая.
Первыми запускаются гостевые системы с самым низким порядком, последними те, у которых порядок не указан совсем. Гости с одинаковым номером порядка запускаются одновременно.
Но запущенная гостевая система вовсе не означает ее готовность к работе, загрузка нужных служб может занимать время и если это критично для зависящих от них гостевых систем, то мы можем поставить дополнительную задержку, которую указываем в параметре Startup delay в секундах.
Эта опция часто вызывает неверное понимание, многие считают, что она определяет задержку старта гостевой системы, однако это не так, данная задержка влияет только на запуск гостей следующей очереди.
Если задержек установлено несколько, то отработает самая длительная из них. И только после этого начнут загружаться гостевые системы следующей очереди. Без указания порядка очереди эта настройка бессмысленна.
Выключение происходит в обратном порядке, сначала гости без указания порядка, потом от самого большого номера очереди к самому маленькому. Задержки при выключении не используются, как только выключились все гостевые системы одной очереди тут же, выключается другая.
Параметр Shutdown timeout устанавливает тайм-аут на выключение, по умолчанию 60 секунд, если гостевая система не завершила свою работу за указанное время, то в лог пишется ошибка выключения и гостевая система завершается принудительно.
Если у вас есть тяжелые машины, которые долго выключаются, то имеет смысл увеличить данный параметр, чтобы гостевой системе хватало времени корректно завершить процессы, а если это какая-то тестовая лаборатория и вы хотите, чтобы она быстрее выключалась, то таймаут можно уменьшить.
11👍43❤6🥱2
Войти в айти
Был недавно в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын этой весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
Был недавно в гостях у знакомых и сразу, чуть ли не с порога первый вопрос – как сейчас лучше войти в айти. Ну да понятно, у них сын этой весной школу будет заканчивать и вопрос выбора будущей профессии стоит остро.
Посидел, попил чая, с будущим коллегой побеседовал и не увидел у него вообще ни желания, ни интереса, ни каких бы там ни было способностей к этому делу.
Спрашиваю, а зачем в айти то, не самая простая отрасль, как никак, да еще и постоянного самообразования требует.
На что услышал, мол ладно тебе, все равно у айтишников самые высокие зарплаты и работают в тепле и уюте, сидя за компьютером, а еще можно удаленно из дома работать.
В целом они в чем-то правы и даже у начинающего айтишника зарплата если не будет самой высокой по рынку, то все равно будет выше, чем у начинающих в других отраслях.
И если с нашей, отраслевой точки зрения, зарплаты отдельных юных падаванов невелики, то с точки зрения широких народных масс – они достаточно высоки, особенно за то, что эти самые айтишники сидят в тепле и ничего не делают.
Поэтому можно говорить, что в обществе давно сложилось понимание айти как некой синекуры, куда надо только попасть, а потом катайся как сыр в масле. На самом деле все конечно сложнее, но мнение уже сложилось.
Масла в огонь подбавляют и всевозможные курсы, и даже государственные программы по переквалификации самых широких народных масс населения в айтишников.
Государство понять можно, с нынешними темпами цифровизации и импортозамещения ему срочно нужны специалисты нижнего звена, в достаточном для их массового использования количестве.
Плюс айти всячески популяризуется у молодого поколения, о чем мы только что писали выше.
Нынешние высокие заработные платы в IT обусловлены двумя вещами: дефицитом специалистов и достаточно высокой добавочной стоимостью, таким специалистом производимой.
Но и трудятся такие специалисты преимущественно в коммерческой сфере, где никто терпеть лентяев и дураков не будет: или ты работаешь и получаешь нормальные деньги или идешь на улицу.
Войти в такое айти просто так сложно, какие бы дипломы и корочки у тебя не были. В коммерции на диплом смотрят в последнюю очередь. Ты или умеешь и делаешь, либо не умеешь и проходишь мимо и неважно кто-то по специальности: программист или ветеринар.
А вот в госсекторе все по-иному, там можно годами ничего не делать, просто имитируя рабочий процесс и красиво отчитываясь наверх, плюс присутствуют достаточно специфичные взаимоотношения, которые лучше всего характеризуются поговоркой: «я начальник – ты дурак, ты начальник – я дурак».
Нормальные специалисты в госсектор не спешат. Частично из-за невысоких по отраслевым меркам зарплат, а частично из-за специфики рабочих отношений (скажем так). А кто и прибивается – так ненадолго, ну или в случае, если больше никуда не берут.
Поэтому именно государству сегодня выгодно выбросить на рынок большое количество начинающих айтишников. Которые, прекрасно понимая сами, что айтишники они «ненастоящие» не будут страдать излишними амбициями и пойдут туда, где тепло, светло и деньги платят, т.е. преимущественно в госсектор.
Хотя кто-то, возможно, и откроет в себе новые способности, но это будут именно штучные случаи. Аналогичный эффект даст и массовый приток молодежи на айти специальности. Появится обширный рынок молодых специалистов, хотя и невысокой квалификации.
А что это значит? А это значит, что уровень зарплаты в этом сегменте резко пойдет вниз, по-другому никак, если по рынку труда бегают стада молодых (и не очень) айтишников, желающих просто найти работу по специальности.
Повлияет ли это на уровень зарплат в отрасли в целом? Нет. Опытные специалисты как были, так и останутся востребованы. А вот существующий сейчас перекос, когда даже молодой и зеленый айтишник получает выше среднего – выправит.
А вообще история повторяется. В начале нулевых модно было быть юристом. И где сейчас все эти стада молодых юристов? А хороших что тогда, что сейчас приходится поискать и получают они более чем достойно.
👍33😁5❤3👌3🤡2
Заменит ли ИИ системных администраторов
Вот уже не один раз за последнее время читатели задают один и тот же вопрос, а заменит ли ИИ системных администраторов? А если и не заменит, то не сократит ли значительно рынок труда.
Вопрос интересный и я тоже думал об этом, сегодня почти весь день провел в разъездах, встречах, разговорах и уже ближе к вечеру разговорился за кофе со знакомой главной бухгалтером одной подшефной конторы.
А разговор как-то неожиданно зашел про ИИ, я ее прямо спросил – пользуешься? Она ответила утвердительно и сказала, что, в общем и целом, довольна полученным результатом.
Что делает? Да точно также спихнула на него всю рутину: проверки, сверки, поиск расхождений и все такое прочее. Иногда заставляет искать что-то новое в сети, разбирать непонятные и редкие ситуации.
Спрашиваю – не фантазирует? Фантазирует – говорит, мол как без этого, но я же не дура, я же вижу, что его куда-то не туда понесло, сразу могу направить правильным путем. И вообще, чем более четко ставишь задачу, тем лучше результат.
И если раньше, чтобы «прокрыжить» месяц надо было либо убить пару часов, либо загрузить на полдня девочку, то сетка сделает это минут за пять. Причем ничего не упустит и точно все найдет, в отличие от девочки.
Получается, говорю, что ИИ все-таки заменяет бухгалтеров, на что она на момент задумалась, а потом сказала – нет. Потому что, если быть честными, то все эти девочки – они не бухгалтера на самом деле, хотя формально ими числятся.
Все что они могут – это вносить первичку, разносить платежи и делать еще множество монотонных и нудных повседневных задач, не требующих ни квалификации, ни глубокого понимания. Самостоятельно вести учет даже какого-нибудь простого ИП они не смогут.
Ничего не напоминает? В нашей отрасли дела обстоят примерно также, кто такой настоящий системны администратор? Это человек обладающий инженерным мышлением, умеющий проводить причинно-следственные связи и строить гипотезы при недостатке информации.
А также принимать решения в условиях цейтнота и психологического давления. Когда все упало и надо все срочно поднимать или когда что-то пошло не так и надо вернуть все, как было до окончания технологического окна.
Одновременно с этим кому-то надо читать логи, смотреть мониторинг, заполнять отчеты, сидеть на первой линии поддержки и все такое прочее. Можно ли этих сотрудников назвать администраторами? Давайте скажем честно – нет. В лучшем случае помощниками администратора.
И вот их ИИ спокойно заменит, потому что он не ленится, не сачкует, а просто быстро, спокойно и качественно делает всю рутину. У него не болит голова после вчерашнего, с ним не ругается жена и он не решает личные вопросы в рабочее время.
И что самое смешное, товарищей, меняющих картриджи и вытаскивающих замятую бумагу ИИ не заменит, просто потому что не умеет. А вот сотрудников первой линии поддержки, помощников и младших сотрудников – запросто.
Но тут давайте снова будем честны, это не администраторы, это младший технический персонал, самостоятельно инфраструктуру, даже простую, они не потянут. А бизнес он не про благотворительность, он про прибыль и лишние дармоеды ему не нужны.
Поэтому мораль сей басни будет очень проста. Либо вы представляете собой самостоятельную профессиональную единицу, либо ИИ скоро займет ваше место. Если вы действительно профессионал – то ИИ станет вашим помощником и заменит нескольких раздолбаев.
Иначе – вам придется конкурировать с ним на рынке труда и шансы будут далеко не в вашу пользу.
Поэтому, если вы решили серьезно работать в сфере IT, то вам придется действительно стать хорошим специалистом, который может и умеет, либо уступить рабочее место ИИ и пойти туда, что ИИ еще не осилил – работу руками.
Вот уже не один раз за последнее время читатели задают один и тот же вопрос, а заменит ли ИИ системных администраторов? А если и не заменит, то не сократит ли значительно рынок труда.
Вопрос интересный и я тоже думал об этом, сегодня почти весь день провел в разъездах, встречах, разговорах и уже ближе к вечеру разговорился за кофе со знакомой главной бухгалтером одной подшефной конторы.
А разговор как-то неожиданно зашел про ИИ, я ее прямо спросил – пользуешься? Она ответила утвердительно и сказала, что, в общем и целом, довольна полученным результатом.
Что делает? Да точно также спихнула на него всю рутину: проверки, сверки, поиск расхождений и все такое прочее. Иногда заставляет искать что-то новое в сети, разбирать непонятные и редкие ситуации.
Спрашиваю – не фантазирует? Фантазирует – говорит, мол как без этого, но я же не дура, я же вижу, что его куда-то не туда понесло, сразу могу направить правильным путем. И вообще, чем более четко ставишь задачу, тем лучше результат.
И если раньше, чтобы «прокрыжить» месяц надо было либо убить пару часов, либо загрузить на полдня девочку, то сетка сделает это минут за пять. Причем ничего не упустит и точно все найдет, в отличие от девочки.
Получается, говорю, что ИИ все-таки заменяет бухгалтеров, на что она на момент задумалась, а потом сказала – нет. Потому что, если быть честными, то все эти девочки – они не бухгалтера на самом деле, хотя формально ими числятся.
Все что они могут – это вносить первичку, разносить платежи и делать еще множество монотонных и нудных повседневных задач, не требующих ни квалификации, ни глубокого понимания. Самостоятельно вести учет даже какого-нибудь простого ИП они не смогут.
Ничего не напоминает? В нашей отрасли дела обстоят примерно также, кто такой настоящий системны администратор? Это человек обладающий инженерным мышлением, умеющий проводить причинно-следственные связи и строить гипотезы при недостатке информации.
А также принимать решения в условиях цейтнота и психологического давления. Когда все упало и надо все срочно поднимать или когда что-то пошло не так и надо вернуть все, как было до окончания технологического окна.
Одновременно с этим кому-то надо читать логи, смотреть мониторинг, заполнять отчеты, сидеть на первой линии поддержки и все такое прочее. Можно ли этих сотрудников назвать администраторами? Давайте скажем честно – нет. В лучшем случае помощниками администратора.
И вот их ИИ спокойно заменит, потому что он не ленится, не сачкует, а просто быстро, спокойно и качественно делает всю рутину. У него не болит голова после вчерашнего, с ним не ругается жена и он не решает личные вопросы в рабочее время.
И что самое смешное, товарищей, меняющих картриджи и вытаскивающих замятую бумагу ИИ не заменит, просто потому что не умеет. А вот сотрудников первой линии поддержки, помощников и младших сотрудников – запросто.
Но тут давайте снова будем честны, это не администраторы, это младший технический персонал, самостоятельно инфраструктуру, даже простую, они не потянут. А бизнес он не про благотворительность, он про прибыль и лишние дармоеды ему не нужны.
Поэтому мораль сей басни будет очень проста. Либо вы представляете собой самостоятельную профессиональную единицу, либо ИИ скоро займет ваше место. Если вы действительно профессионал – то ИИ станет вашим помощником и заменит нескольких раздолбаев.
Иначе – вам придется конкурировать с ним на рынке труда и шансы будут далеко не в вашу пользу.
Поэтому, если вы решили серьезно работать в сфере IT, то вам придется действительно стать хорошим специалистом, который может и умеет, либо уступить рабочее место ИИ и пойти туда, что ИИ еще не осилил – работу руками.
👍40👎9❤6💯3
Анализируем загрузку вашей Linux системы при помощи systemd-analyze
Многие администраторы задаются вопросом – что задерживает загрузку их Linux системы, какие службы и как влияют на этот процесс. Желательно в цифрах и фактах.
Возможно, вы удивитесь, но все это в вашей системе уже есть, с цифрами, фактами и графиками. Достаточно воспользоваться утилитой systemd-analyze.
Если вы просто запустите ее, то получите общее время загрузки системы разделенные на этапы загрузки ядра и пользовательского окружения. Понятно, что такой информации мало, поэтому будем детализировать.
Прежде всего получим список процессов, влияющих на загрузку и отсортированных по времени запуска:
Также можно построить зависимостей и времени запуска критических сервисов:
Для анализа вам может пригодиться график загрузки, для его построения используйте:
А этой командой можно построить граф зависимостей сервисов в формате DOT, но сам по себе он мало интересен, потому как полный граф системы представляет собой сильно запутанное и нечитаемое дерево, куда интереснее получить граф для отдельно взятой службы или таргета.
Для преобразования DOT-файла в график вам потребуется установить пакет
После чего выполните команду:
И в папке запуска скоро появится интересующий вас график, по которому можно изучить все зависимости юнита. Обратите внимание, что имя сервиса нужно писать полностью, с указанием типа юнита.
Многие администраторы задаются вопросом – что задерживает загрузку их Linux системы, какие службы и как влияют на этот процесс. Желательно в цифрах и фактах.
Возможно, вы удивитесь, но все это в вашей системе уже есть, с цифрами, фактами и графиками. Достаточно воспользоваться утилитой systemd-analyze.
Если вы просто запустите ее, то получите общее время загрузки системы разделенные на этапы загрузки ядра и пользовательского окружения. Понятно, что такой информации мало, поэтому будем детализировать.
Прежде всего получим список процессов, влияющих на загрузку и отсортированных по времени запуска:
systemd-analyze blame
Также можно построить зависимостей и времени запуска критических сервисов:
systemd-analyze critical-chain
Для анализа вам может пригодиться график загрузки, для его построения используйте:
systemd-analyze plot > boot.svg
А этой командой можно построить граф зависимостей сервисов в формате DOT, но сам по себе он мало интересен, потому как полный граф системы представляет собой сильно запутанное и нечитаемое дерево, куда интереснее получить граф для отдельно взятой службы или таргета.
Для преобразования DOT-файла в график вам потребуется установить пакет
graphviz:apt install graphviz
После чего выполните команду:
systemd-analyze dot docker.service | dot -Tsvg > docker.svg
И в папке запуска скоро появится интересующий вас график, по которому можно изучить все зависимости юнита. Обратите внимание, что имя сервиса нужно писать полностью, с указанием типа юнита.
1👍33❤2🔥2🤡2
MultiDrive – бесплатная утилита для работы с дисками
Утилиты для работы с дисками в Windows – отдельная категория программ, которые работают с критически важным оборудованием – дисками и пользовательскими данными.
У многих администраторов уже выработался свой набор программ, но чаще всего это коммерческие решения, что не всегда подходит, особенно если речь идет о лицензионной чистоте или заказчик не хочет приобретать дополнительный софт.
Не так давно мы открыли для себя утилиту MultiDrive от компании Atola Technology. На первый взгляд она ничем не выделяется среди аналогов. Простой и понятный интерфейс, необходимый минимум функций.
Программа умеет клонировать, создавать резервные копии дисков и восстанавливать их, а также делать очистку с гарантированным уничтожением данных. Все достаточно просто и наглядно, запутаться решительно негде.
Это делает ее пригодной как для опытных специалистов, так и для обычных пользователей, которым просто надо клонировать старый диск на новый. Или сделать резервную копию системы.
Данное ПО не является открытым, но распространяется бесплатно для личного и коммерческого применения. Компания разработчик может собирать статистику использования, но эту функцию нужно явно включить и спокойно отключить в настройках.
Кроме самой утилиты вы можете скачать загрузочный диск с ней на базе WinPE, что делает ее полноценным и универсальным инструментом.
Но самое интересное – наличие собственного CLI, которое позволяет использовать утилиту в сценариях автоматизации. CLI полностью свой, но достаточно прост и отлично документирован.
При необходимости вы можете вызвать дополнительную справку по любой команде с подробным перечислением всех ключей, примерами использования и расшифровкой применяемых сокращений.
В общем, перед нами добротно сделанный бесплатный продукт, который можно и нужно использовать в повседневной деятельности.
Утилиты для работы с дисками в Windows – отдельная категория программ, которые работают с критически важным оборудованием – дисками и пользовательскими данными.
У многих администраторов уже выработался свой набор программ, но чаще всего это коммерческие решения, что не всегда подходит, особенно если речь идет о лицензионной чистоте или заказчик не хочет приобретать дополнительный софт.
Не так давно мы открыли для себя утилиту MultiDrive от компании Atola Technology. На первый взгляд она ничем не выделяется среди аналогов. Простой и понятный интерфейс, необходимый минимум функций.
Программа умеет клонировать, создавать резервные копии дисков и восстанавливать их, а также делать очистку с гарантированным уничтожением данных. Все достаточно просто и наглядно, запутаться решительно негде.
Это делает ее пригодной как для опытных специалистов, так и для обычных пользователей, которым просто надо клонировать старый диск на новый. Или сделать резервную копию системы.
Данное ПО не является открытым, но распространяется бесплатно для личного и коммерческого применения. Компания разработчик может собирать статистику использования, но эту функцию нужно явно включить и спокойно отключить в настройках.
Кроме самой утилиты вы можете скачать загрузочный диск с ней на базе WinPE, что делает ее полноценным и универсальным инструментом.
Но самое интересное – наличие собственного CLI, которое позволяет использовать утилиту в сценариях автоматизации. CLI полностью свой, но достаточно прост и отлично документирован.
При необходимости вы можете вызвать дополнительную справку по любой команде с подробным перечислением всех ключей, примерами использования и расшифровкой применяемых сокращений.
В общем, перед нами добротно сделанный бесплатный продукт, который можно и нужно использовать в повседневной деятельности.
11👍31🔥9❤2
Выгрузка и загрузка информационных баз 1С при помощи автономного сервера
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
Для выгрузки конфигурации используйте:
Для загрузки:
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.
Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.
Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.
От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке
bin под именем ibcmd.В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.
Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.
Начнем с самого популярного, выгрузки базы в DT-файл:
./ibcmd infobase dump --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.
Параметр --dbms указывает тип СУБД, можете использовать
PostgreSQL или MSSQLServer. Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.
Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!
Загрузить базу можно обратной командой:
./ibcmd infobase restore --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt
Для выгрузки конфигурации используйте:
./ibcmd infobase config save --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
Для загрузки:
./ibcmd infobase config load --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf
После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:
./ibcmd infobase config apply --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1
В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.
👍27🤯4❤3👀1🤝1