Как запустить Oracle VirtualBox (VBOX) в фоновом режиме Microsoft Windows?

Из cmd или в ярлыке выполняем:

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" startvm <Имя_VM> --type headless

VMWare Memory. Работа с памятью

CPU
Предположим, что у нас есть бездействующая ВМ с резервом 2 GHz.  В этом случае другие машины могут получить процессорное время, не используемое данной ВМ, несмотря на резерв.
Память
А вот с памятью все иначе.
Если ВМ имеет зарезервированную память, но еще не обращалась ко всему объему резерва, то неиспользованная память может быть отдана другим ВМ. Однако после того, как произошло обращение ко всему объему резерва, ESX сохраняет полный резерв за этой ВМ, даже если ВМ бездействует и не обращается к памяти.
Разъясню чуть более техническим языком – ВМ видит непрерывную vRAM, виртуальную память, часть которой каким-то образом распределена в pRAM, физической памяти сервера. Выделение очередного блока pRAM происходит при первом обращении ВМ к блоку vRAM, поэтому в общем случае объем выделенной pRAM меньше или равен объему vRAM. Т.е. для ВМ с 4 GB памяти фактически может быть выделено 512 MB физической памяти просто потому что к 3.5 GB ВМ ни разу не обращалась. В случае с резервированной памятью все происходит точно так же. Резерв памяти защищает только физическую память, уже выданную ВМ, поэтому даже при резерве в 2 GB фактическое использование может составить лишь 512 MB, а следовательно 1.5 GB физической памяти могут быть выделены другим ВМ. Но как только произойдет обращение к этим 1.5 GB со стороны ВМ с резервом памяти, они будут выделены в pRAM, и далее уже никому другому не будут отданы, даже если не будет ни одного нового обращения.
Зарезервированные 2 GB памяти ни при каких условиях не будут сброшены в своп или выдавлены balloon-драйвером. Однако весь объем памяти ВМ, лежащий выше отметки резерва (т.е. 1 GB для ВМ с 3 GB памяти и резервом в 2 GB), будет рассматриваться сервером ESX на общих основаниях – т.е. и balloon и swap поджидают за углом :)
---
Источник 1

Memory management

В полете из солнечной Москвы в прохладный Баку
у меня появилось вдохновение для написания сего текста.
Лично мне он понравился.

Вот у нас есть сервер ESX(i), для простоты один. У его есть сколько-то оперативной памяти для виртуальных машин (“Доступная память”), и на нем работает сколько-то виртуальных машин. Этим виртуальным машинам выделено сколько-то памяти (“Показанная память” ), и они сколько-то этой памяти потребляют (“Потребляемая память” ). Что можно рассказать про это?

Несколько общих слов

Доступная память – это все гигабайты памяти сервера минус:

1. Память, которую гипервизор тратит на себя. ESXi создает в памяти RAM диск для своей работы. ESX отрезает 300-800 мегабайт для Service Console. Виртуальным коммутаторам, iSCSI инициатору и прочим компонентам так же нужны ресурсы для своей работы.
2. Память, которую гипервизор тратит для создания процесса виртуальной машины. Overhead, говоря в терминах счетчиков нагрузки. Когда мы создаем виртуалку и “показываем” ей гигабайт памяти, гипервизор ей выдает часть или 100% этого гигабайта. И даже в последнем случае еще 100-150 мегабайт тратит на оверхед.
3. Еще HA может резервировать сколько-то памяти под свои нужды. 

Показанная память – это тот объем памяти, который мы указываем в настройках ВМ, на закладке Hardware. Именно этот объем видит гостевая ОС. Это максимум, который гостевая ОС может использовать. Однако, гипервизор может выделить для ВМ из реальной оперативки и меньший объем, чем “показал” ей памяти. То, что гостю выделено лишь, например, 400 мегабайт из показанного гигабайта изнутри не заметить.  По каким причинам гипервизор будет так подло поступать поговорим чуть позже.

Потребляемая память – это сколько реальной оперативной памяти использует виртуальная машина. Или, правильнее сказать, какой объем памяти выделил ей гипервизор. В  терминах мониторинга это Consumed.

Memory Overcomitment

Все мы наслышаны про чудесный (без иронии) “Memory Overcomitment”. Что это? Это ситуация, когда “Показанная память” всех ВМ на сервере больше чем “Доступная память”. То есть мы “показали” нашим виртуальным машинам больше памяти, чем есть на сервере. Кстати говоря, и это важно, “Потребляемая память” в такой ситуации может быть как меньше (хороший случай), так и больше чем память “Доступная” (плохой случай).

Иллюстрация “хорошего” случая:

Memory Overcomitment достигается на ESX(i) за счет нескольких технологий. Перечислим их:

• выделение по запросу;
• transparent memory page sharing:
• balloon driver или его еще можно обозвать vmmemctl;
• memory compression (новинка 4.1);
• vmkernel swap.

Что это? Каково место этих технологий? Насколько они офигенны? Насколько они бесполезны? Давайте поразмышляем.

Вводная к размышлениям

Мы будем рассуждать о потреблении памяти виртуальными машинами, а точнее – гостевыми ОС и приложениями.

Основная идея в чем – “показанная” серверу (тут неважно – физическому или виртуальному) оперативная память никогда не загружена на 100%. Почему? У вас загружена именно так? Значит вы хреново спланировали этот сервер, согласны?

Утверждение 1 – мы должны стремиться к тому. что виртуальные машины не должны все время потреблять 100% от “показанной” им памяти. Таким образом, прочие соображения я буду основывать на том, что у вас именно так. То, что некоторые задачи занимают чем-то всю свободную память – здесь не учитываем, так как разговор идет в общем.

Утверждение 2 – в разное время суток\дни недели наши приложения потребляют память по разному. Большинство задач хотят ресурсов в рабочие часы в будни, с пиками утром или в середине дня или <подставьте данные своей статистики>. Однако бывают приложения с нетипичными для нашей инфраструктуры профилем потребления памяти.

Утверждение 3 – в вашей инфраструктуре сделан запас по оперативной памяти серверов, то есть “доступной” памяти. Этот запас делается из следующих соображений:

• архитектор боится промахнуться с необходимым объемом. промахнуться в смысле “продать меньше памяти чем потребуется”;
• как запас на случай отказа сервера (или нескольких);
• как запас на случай роста виртуальных машин или нагрузки на существующие виртуальные машины.

Далее.

Рискну предположить, что в наших инфраструктурах можно выделить несколько групп виртуалок, по разному потребляющих память.

Попробую предложить классификацию. Она примерна, потому что тут я ее предлагаю лишь для иллюстрации своих размышлений.

• ВМ приложений – сколько памяти вы выделяете (“показываете” в моих определениях тут) своим серверам приложений? При опросах на курсах я слышу цифры 4-8, редко больше.  Вернее, для малого числа ВМ больше. Большинство таких приложений потребляет ресурсы в рабочие часы, однако бывают и исключения (например, сервера резервного копирования, работающие по ночам);
• Инфраструктурные ВМ – всякие DNS, DC, и т.п. Обычно гигабайт или два. Потребляют ресурсов мало, пики если вообще есть – в рабочие часы;
• Тестовые ВМ – думаю, гигабайт или два в среднем по больнице, и больше по требованию смотря что тестировать будем. Пики в рабочие часы, где-то бывает куча тестовых виртуалок, простаивающих подавляюще большую часть времени (как крайний случай – кто-то создал и забросил, а удалить виртуалку страшно – вдруг кому нужна).

Давайте теперь рассмотрим эти группы виртуальных машин в контексте механизмов работы с памятью.

Выделение по запросу

То, чего нет у других. Ну или я не знаю что есть. (помните, пост про vDiva – “Вы считаете себя нереально крутым спецом по виртуализации, хотя ни разу в жизни не видели Xen, Hyper-V или KVM”).

Как это работает

Виртуальной машине выделили (“показали”) два гигабайта. Виртуальную машину включили. Что происходит дальше?

Этап 1 – включение. Часто мне приходится слышать о том, что при старте гость забивает нулями всю память – уважаемые читатели, кто в теме просветите меня – так ли это на самом деле, мои изыскания привели к противоречивым выводам. Допустим это так – потому что это самый плохой случай – ведь гость на старте делает вид, что ему нужна вся “показанная” ему память. Ок, гипервизор ему всю выдает. Итак, на этапе 1 “потребляемая” память равна “показанной”, в самом плохом случае.

Этап 2 – гость стартовал все службы, службы начали работать, создавать нагрузку. Но не сто процентов памяти потребляется, см. утверждение 1. Например, 1200 мегабайт из выделенных 2000. То есть гость 800 мегабайт пометил у себя в таблице памяти как “свободная”. По хорошему, гипервизору надо бы ее забрать. Он и забирает, для этого используется механизм balloon(!). Т.е. одна из задач балон-драйвера (подробности о нем см. ниже) – это отбирать ранее выданною, но сейчас ненужную гостю память. Итак, балон раздулся, затем сразу сдулся. Что получилось – гостю 1200 мегабайт нужно, поэтому они балоном или не отнялись, или сразу вернулись обратно. Но больше памяти гостю, обычно, не нужно – и он больше не просит. А раз не просит, гипервизор ему больше и не дает.

Насколько часто это применяется к разным группам виртуальных машин

Работает этот механизм всегда, когда виртуальная машина потребляет не 100% “показанной” памяти.  То есть всегда, кроме первых минут после включения и редких пиков, этот механизм работает, и заметно экономит нам память.

Если виртуальная машина не потребляет всю память часто – механизм очень полезен. Для некоторых тестовых – 100% времени. Для производственных серверов – как минимум ночью. А если часть серверов нагружается в другое время суток чем оставшаяся часть – вообще шоколадно. Для инфраструктурных – иногда бОльшую часть времени.

Эффект на производительность

Если и есть негативный, то не должен быть большим.

transparent memory page sharing

Технология с самым сложно звучащим  названием.

Как это работает

Гипервизор считает контрольные суммы, хеши, страниц оперативной памяти. Находит одинаковые (для одной или нескольких виртуальных машин) страницы. И одинаковые страницы из разных “виртуальных таблиц памяти” адресует в одну единственную страницу в памяти реальной. Получается, на пустом месте гипервизор делает “потребляемую” память меньше чем она могла бы быть без данного механизма. Ну про “”на пустом месте” я конечно соврал  – гипервизор тратит ресурсы процессоров сервера на подсчет контрольных сумм. Но с учетом того, что, как правило, ресурсов процессора у нас дофига, этот обмен нам очень выгоден.

Иллюстрация:

Насколько часто это применяется к разным группам виртуальных машин

Сложный вопрос. Сложность во все более широко используемом механизме Large Pages. Если у вас Windows 7/2008 + Nehalem, и используются страницы памяти по 2 МБ, теория гласит что эффект от page sharing будет маленьким. Хотя в реальности там довольно сложный алгоритм:

ESX(i) разбивает 2 МБ страницу на 4 КБ, считает их хеши, но не использует механизм page sharing пока памяти хватает. А вот если перестало хватать – перед тем как включать какой-то из механизмов подкачки начинает делать sharing этих маленьких 4 КБ кусков.

Что говорит практика по эффективности и безболезненности такого подхода– у меня пока мнения не сложилось.

А если у вас железо или софт постарее, или эти большие страницы принудительно отключены – эффект обычно офигенный.

Эффект на производительность

Именно производительность негативного эффекта не испытывает. Тем более что ESX(i) знает, что такое архитектура NUMA, и если сервер у нас этой архитектуры, то дедупликация страниц памяти идет внутри каждого одного  NUMA узла независимо, чтобы виртуалке не приходилось за отдельными, дедуплицированными страницами лазать в память другого процессора.

Однако в теории накладные расходы имеют место быть – если какая-то ВМ хочет изменить разделяемую с другими страницу памяти, с помощью технологии Copy-on-write делается копия страницы, которая и отдается приватно данной ВМ. Это медленнее, чем просто дать записать в неразделяемую страницу. Насколько заметен эффект в реальной жизни – сказать очень сложно.

Официально данные вот какие:

За единицу выбраны данные тестов с отключенным page sharing. Как видно, средний столбец – со включенным page shring и параметрами по умолчанию, не хуже, а иногда лучше(!) по производительности.Улучшение связывают с тем, что memory footprint у виртуалки становится меньше, и лучше помещается в кэш (видимо, процессорный?).

Крайние тесты – это число транзакций в секунду, компилирование ядра - время.

UPD. от июня 2011 - отключение Large Pages позволяет сэкономить треть ОЗУ, есть такое мнение - TPS vs. Large Pages in real life.

balloon driver / vmmemctl

Самая радостная для русского уха технология.

Как это работает

Один из компонентов VMware tools – это драйвер устройства vmmemctl. По команде ESX(i) он начинает запрашивать у гостевой ОС память, так же как это делают приложения гостевой ОС. Т.е. этот драйвер раздувает тот самый “баллон” внутри, отнимая память у гостя.

Зачем это надо? Для решения двух задач.

Первая уже описана выше – если гостю были выделены страницы памяти, которые он уже перестал использовать, то гипервизор не может такие свободные страницы отличить и забрать. А раздувшемуся внутри “баллону” гость сам их отдаст в первую очередь, и затем не попросит у гипервизора их обратно. Страницы памяти, занятые “баллоном”, гипервизор отличит, и перестанет их адресовать для виртуальной машины, которой они были адресованы до сего момента. Посмотрите на иллюстрацию ниже – страницы памяти, гостем для себя помеченные как “свободные”, помечены звездочками слева. А справа, в следующем состоянии описываемого механизма, они уже не занимают железную память сервера.

Иллюстрация:

Вторая задача – когда гостю выделено, например, два гигабайта, а один гигабайт из них надо отнять. Характерный пример – когда памяти сервера перестало хватать резко увеличившемуся числу виртуальных машин. А число их резко увеличилось из-за сбоя одного из серверов, и рестарта его ВМ на другом.

Так вот, у ВМ надо отнять память. Гипервизор раздувает баллон, гость начинает свопировать (в свой собственный файл\раздел подкачки. То есть balloon – это способ гипервизору задействовать механизм подкачки гостя). Реальную память, теперь занятую баллоном(с точки зрения гостя), гипервизор отдает другой ВМ. Кстати, в моем примере гипервизор отдаст команду отнять гигабайт. А весь ли гигабайт баллон отнимет? Может быть, и не весь – гость вполне может отказать ему в памяти, если сочтет что другим компонентам память нужнее. Если баллон не справился, то гипервизор доотнимет оставшееся с помощью memory compression и vmkernel swap.

Насколько часто это применяется к разным группам виртуальных машин

Первая задача – отнимание незанятой памяти, стабильно актуальна для виртуальных машин любой группы.

Вторая задача – мне видится мало актуальной. Давайте разберем ее слегка подробнее.

Итак, из чего может взяться ситуация, когда у одной ВМ память надо отнять, чтобы отдать другой? Я вижу несколько вариантов:

1. когда у нас memory overcommitment. и сразу у многих ВМ наступили пики нагрузки, что привело к загрузке сервера на 100%. Это, кстати говоря, причина пользоваться MO аккуратно. Впрочем, совсем отказываться от MO, как призывает нас делать Майкрософт, по моему мнению, тоже не стоит.
2. когда у нас ломается один из серверов кластера HA. Например, у нас 10 серверов, все загружены по памяти(днем, в будни) процентов на 70. Вы знаете, что HA все упавшие ВМ перезапустит на одномиз оставшихся серверов? Т.е. виртуалкам потребуется 140% его памяти.
   
   Вот тут я соврал, как показали дальнейшие исследования. Выбор о том где включить ВМ с упавшего сервера предпринимается для каждой ВМ независимо. Но для иллюстрации описанная ситуация сойдет.Далее ситуация разветвляется. Если у вас есть DRS, то он быстренько разнесет виртуалки по разным серверам, и баллону работать не придется.
   А вот если DRS нет, или он не в автоматическом режиме – вот тут мы приходим к нехватке на всех физической памяти. И гипервизор отнимет память у части машин с помощью баллона.
   У многих из вас нет DRS?
   У тех, у кого таки нет DRS – часто у вас ломаются серверы?
   Наконец, даже наличие баллона что означает – что запустятся все виртуалки, но всем будет хреново от нехватки памяти (правда, какие-то виртуальные машины могут “остаться на коне”, за счет опускания других ВМ в еще большее свопирование – см. такие настройки как reservation и shares).

Отсюда вывод – наличие баллона это несомненный плюс для решения задачи один, но не панацея для решения задачи два.

Эффект на производительность

Для задачи один незаметный – отнимается только ненужная память.

Для задачи два разный – см. далее.

memory compression

Новинка, этот механизм появился только в 4.1.

Как это работает

Гипервизор использует часть памяти под создание эдакого кэша. Теперь, когда встает задача два из описания баллона – впихнуть ВМ в меньший чем им хочется объем памяти, часть их памяти будет сжиматься и помещаться в ранее зарезервированную область.

Идея в том, что сжать и записать данные в память , или прочитать и разжать – быстрее чем без сжатия читать или писать с диска, из файла подкачки.

Иллюстрация:

Состояние “а” – надо выгрузить две страницы памяти из реальной оперативки.

Состояние “b” – решение вопроса “по старинке”, свопированием.

Состояние “с” – модерновое решение вопроса. Страницы сжаты и помещены в ранее зарезервированную область памяти сервера.

Обратите внимание, что память под этот кэш не резервируется на сервере заранее – это часть памяти самой ВМ. Т.е. когда для ВМ перестает хватать памяти, гипервизор отнимает у нее еще немного, и в этом немного размещает сжатые страницы ее памяти.

Насколько часто это применяется к разным группам виртуальных машин

Редко – как я выше писал, при адекватном планировании и наличии DRS почти никогда.

Эффект на производительность

См. далее.

vmkernel swap

Последняя надежда.

Как это работает

При включении виртуальной машины гипервизор создает файл .vswp – файл подкачки vmkernel для этой ВМ.

Теперь, когда гипервизору надо забрать часть памяти у виртуальной машины, он может просто из части страниц скопировать содержимое в данный файл, и перенаправлять обращения ВМ к памяти в файл. Гость ничего про это знать не будет.

Будет ли гипервизор пользовать vmkernel swap, а не balloon или memory compression? См. ниже.

Насколько часто это применяется к разным группам виртуальных машин

См. описание второй задачи для баллона – отнять и поделить. Я думаю, что такая задача встает редко.

Плюс vmkernel swap в том, что он работает всегда. Гипервизору нет дела ни до чего – ни до наличия vmware tools и vmmemctl в госте, ни до чего другого – задействовать vmkernel swap можно всегда.

Минус – тормоза будут значительными.

Эффект на производительность

См. далее.

Нехватка памяти на всех – какой механизм будет использован?

У ESX(i) есть счетчик – процент свободной памяти.

Его пороговые значения это 6% (high, типа все ок), 4% (soft, типа маловато осталось), 2% (hard, пипец как мало осталось, атас!), и 1%(low, все, приехали).

• Free RAM>=6%. Пока свободной памяти остается не меньше 6 процентов (состояние high) задействуется только page sharing.
• Free RAM<6%. Свободной памяти меньше чем хотелось бы. Начинаем использовать balloon.
• Free RAM<4%. Свободной памяти мало. Используем еще и compression и vmk swap.
• Free RAM<1%. Полный пипец. В доке вот что написано: “..в дополнение к balloon, swap и compression, гипервизор делает еще and additionally blocks the execution of all virtual machines that consume more memory than their target memory allocations”. Я пока не понял что это значит.

Balloon и vmkernel swap и memory compression делают одну и ту же работу. Но ballon делает ее более оптимально – позволяет гостю самому выбрать что класть в своп. Данные тестов:

Крайняя правая позиция – когда из 512 мегабайт памяти у гостя оставалось только 128. Красная линия – скорость компиляции когда до 384 мегабайта памяти отнимается только balloon, зеленая – только vmkernel swap.

Специфика компиляции в том, что самому процессу память особо не нужна – основной объем занят под кэш данных. Так вот, в случае balloon гость понимал, что в своп лучше положить сначала данные, чем ядро ОС. А в случае vmkernel swap такой выбор сделать нельзя, и в своп идет “что-то”.

А вот данные при похожих условиях для базы данных Oracle, нагруженной соответствующей утилитой:

Обратите внимание – пока balloon отнимал меньше чем 1792 мегабайта из 3840, производительность практически не падала. Это опять же специфика приложения, но приложения характерного.

А вот для каких-то приложений разницы не будет:

И в начальном диапазоне vmkernel swap даже меньше негатива оказывает на производительность ВМ. Впрочем, процент приложений вот так использующих память весьма мал. Здесь использовалась бенчмарка SPECjbb.

А вот для Exchange разница кардинальна:

Если отнять 9 из 12 гигабайт памяти баллоном, то это даст удвоение latency, в то время как отнятие двух гигабайт из двенадцати при помощи vmkernel swap – утридцетитворение.

Таким образом, если свопирование неизбежно, balloon это меньшее зло.

Однако, еще разок замечу – по моему мнению, вам редко придется оказаться в ситуации, когда balloon будет работать из за нехватки памяти. И даже если такая ситуация случится, balloon даст снижение производительности, просто почти всегда меньшее снижение, чем использование vmkernel swap.

А теперь сравним это еще и с compression:

Вкратце – compression не панацея, но если уж памяти жестко не хватает, то с compression лучше чем без него (только с vmkernel swap, если быть точным). Нагрузка на процессоры увеличивается на 1-2%, что неощутимо.

Все.

P.S.

За кадром остались limit, reservation и shares. Первым пользоваться для памяти не надо, вторым – лишь для самых требовательных к памяти ВМ, третьим – в двух словах не скажешь.

Первоисточник картинок и данных тестирования - Understanding Memory Resource Management in VMware ESX 4.1.

Я тут сделал несколько утверждений – буду рад комментариям.

Источник 2

Справка по командам Vim

Открытие файла

vi опции имя_файла

• +номер — переместить курсор к указной строке после запуска.
• +/шаблон — выполнить поиск по шаблону и переместить курсор к первому вхождению
• +команда — выполнить команду после запуска программы
• -b — двоичный режим, для редактирования исполняемых файлов
• -d — режим поиска различий в файлах, нужно указать несколько файлов для открытия
• -g — графический режим
• -n — не использовать автосохранение для восстановления файла при сбое
• -R — режим только для чтения
• -w — сохранить все действия в файл
• -x — шифровать файл при записи
• -C — режим совместимости с Vi

Открытие нескольких файлов

vi имя_файла1 имя_файла2 имя_файла3

Переключение на 3 открытый файл

:buffer 3

Просмотр всех открытых файлов

:buffers

Поиск и замена всех вхождений "idiot" в документе на "manager"

:%s/\<idiot\>/manager/gc

Эта команда состоит из:

: - переход в командный режим

% - вполнять для всех строк документа

s - краткая форма записи команды :substitute (Замена)

/ - флаг полей икомое и замена

\< - начало слова

\> - конец слова

g - заменить все вхождения, а не только первое в каждой строке

с - спрашивать перед каждой заменой

Перемещение фрагмента текста с помощью маркера

Последовательность действий:

1)Ставим курсор в начало фрагмента текста

2)Создаем маркер "а", нажав в командном режиме ma (m - сокращение marker)

3)Перемещаем курсор в конец фрагмента

4)Нажимаем d'a удаляя таким образом маркированный текст

5)Перемещаем курсор в позицию вставки фрагмена

6)Нажимаем p

Для отображения всех символов включаем режим списка

:set list

Установка длинны строки

:set wrapmargin=70

Удаление ^M в конце строк из файлов с кодировкой MS-DOS

:1,$s/{Ctrl+V}{Ctrl+M}//{Enter}

• : - командный режим
• 1 - с первой строки
• $ - до последней строки
• s - краткая форма записи команды :substitute (Замена)
• / - символы определяющие начало и конец поля текста
• {Ctrl+V}{Ctrl+M} - {Ctrl + V} указывает Vim обрабатывать {Ctrl + M} символ как обычный символ, даже если он является особым
• {Enter} - будет рассматриваться как {Enter} без {Ctrl + V}.

CentOS cli config

Network

Show status network interfaces:

    nmcli d


Terminal user interface configuration network interfaces:

    nmtui


Resart network service:

    service network restart

Захват образа Windows 7

Устанавливаем чистую систему. Она будет эталонной и с нее мы захватим образ
Перезагружаемся в режим аудита:

C:\Windows\System32\sysprep\sysprep /audit /reboot

Устанавливаем обновления и необходимое программное обеспечение.
Очищаем систему от временных файлов.

Останавливаем эталонную систему командой:

C:\Windows\system32\sysprep\sysprep /oobe /generalize /shutdown

После этого эталонную систему запускать до захвата образа нельзя.

Переходим к инструментальной системе с установленным WAIK.

Откроем Пуск - Все программы - Microsoft Windows AIK - Командная строка средств развертывания и выполним команду для 32-битных систем:

copype.cmd x86 e:\win_pe

или для 64-битных:

copype.cmd amd64 e:\win_pe

где e:\win_pe желаемое расположение папки с образом. Предварительно папку создавать не надо, так как в этом случае вы получите ошибку, что папка уже существует.

Теперь перейдем в папку назначения и скопируем файл winpe.wim в папку ISO\sources и переименуем его в boot.wim.
Затем скопируем в папку ISO из папки C:\Program Files\Windows AIK\Tools\amd64 или C:\Program Files\Windows AIK\Tools\x86, в зависимости от разрядности, файл imagex.exe.

Затем в Командной строке средств развертывания дадим следующую команду:

oscdimg -n -be:\win_pe\etfsboot.com e:\win_pe\ISO e:\win_pe\winpe.iso

Результатом работы команды будет образ winpe.iso с которого следует загрузить эталонную систему.
Если вы не выполняли дополнительной разметки диска эталонной системы, то раздел для захвата будет иметь букву D:, а загрузочный диск E:, на всякий случай проверяем командой dir.
Теперь приступим к захвату образа, так как образ создается пофайлово, то его можно сохранять на тот же самый раздел. Введем следующую команду:

E:\imagex /capture d: d:\install.wim "Win7_ULT_x64" /compress maximum  /boot /verify

В качестве параметров указываем захватить диск D: и сохранить его в образ D:\install.wim, в кавычках указываем собственное название образа,
также ставим максимальное сжатие, возможность загрузки и проверку созданного образа. После чего можем сходить выпить кофе, данная операция занимает в среднем около получаса.
Перезагружаем эталонную систему в обычный режим и копируем созданный образ на ПК с установленным WAIK.
Перейдем в e:\win_pe и очистим папку ISO, затем скопируем туда содержимое оригинального диска Windows 7, который мы использовали для установки эталонной системы.
После чего заменим файл install.wim в папке sources на захваченный нами образ. Теперь можно приступать к сборке собственного ISO-образа, для этого выполните команду:

oscdimg -u2 -m -o -lWIN7ULTx64 -be:\win_pe\etfsboot.com e:\win_pe\iso e:\win_pe\Win7_ULT_x64.iso

разберем ключи команды подробнее:

    u2 -создает образ, который имеет только файловую систему UDF.
    m - снимает ограничения на размер образа.
    o - заменяет дублирующиеся файлы одним экземпляром, позволяет сократить размер образа.
    l - метка тома, вводится без пробелов, необязательный параметр.
    b - расположение загрузочного файла, также без пробелов.

Образ собирается довольно быстро, единственный момент - с большой долей вероятности его размер превысит 4,7 ГБ и записать его на обычную DVD болванку не удастся.
В этом случае можно использовать двухслойные болванки DVD9, но они реже встречаются в продаже и могут поддерживаться не всеми моделями дисководов.
В этом случае можно разбить дистрибутив на две части, каждый из которых будет помещаться на DVD-диск стандартной емкости.
Также следует помнить об ограничении 32-х разрядных систем, которые не умеют работать с wim-образами размером более 4 ГБ.

Разделить образ можно следующей командой:

imagex /split e:\win_pe\install.wim e:\win_pe\install.swm 3000

В результате будет создано два или более swm-файла максимальным размером в 3000 МБ. Затем удалим из папки ISO\sources install.wim и поместим туда install.swm, после чего соберем образ первого диска:

oscdimg -u2 -m -lWIN7ULTx64DVD1 -be:\win_pe\etfsboot.com e:\win_pe\iso e:\win_pe\Win7_ULT_x64_DVD1.iso

После этого удалим install.swm и скопируем на его место install2.swm. Второй диск нет смысла делать загрузочным, поэтому соберем его более простой командой:

oscdimg -u2 -m -lWIN7ULTx64DVD2  e:\win_pe\iso e:\win_pe\Win7_ULT_x64_DVD2.iso

Установка с разделенного образа производится обычным путем, начиная с первого диска, в процессе работы инсталлятор сам попросит сменить диск

pvs
vgs
lvs

fdisk /dev/sda
n – для создания нового раздела на диске;
p – для присвоения primary новому разделу.

Укажите номер, который будет носить этот раздел. First sector и Last sector указываем по умолчанию. После этого мы получим уведомление, что был создан раздел типа Linux размером 16 GB.

Теперь необходимо сменить тип раздела с Linux на Linux LVM:
t – для смены типа созданного раздела.

Указываем номер нашего раздела:
8e – это hex-код для типа LVM.

В результате этой операции мы получим сообщение, что раздел был изменен с типа Linux на Linux LVM.

p – для вывода всех томов на нашем диске

После чего – w, для записи изменений на диск и выхода из программы fdisk.

Выйдя из программы, мы получаем сообщение, что для применения изменений необходимо перезагрузиться (предпочтительно), либо выполнить команду partprobe.

После того, как мы успешно создали раздел, необходимо создать новый physical volume на основе этого раздела:
pvcreate /dev/sda4

Следующим шагом будет расширение нашей volume group посредством добавления в неё созданного physical volume.
vgextend lvm-master /dev/vda2

Теперь проверим сколько доступного свободного места в нашей VG на данный момент:
vgs

С помощью команды lvdisplay мы можем посмотреть список всех logical volume, которые на данный момент доступны:
lvdisplay

Нам доступен один, он носит название lvm-rootfs. На этом logical volume находится наш коренной раздел ( / ).

Теперь мы расширим наш LV lvm-rootfs на доступные нам 5 GB (с 15GB до 20GB). Команда vgdisplay покажет свободные PE (Physical Extend):
vgdisplay

Именно на это количество PE мы и расширим наш LV lvm-rootfs:
lvextend -l +1280 /dev/lvm-master/lvm-rootfs

После расширения LV необходимо расширить файловую систему на весь доступный объем:
resize2fs /dev/lvm-master/lvm-rootfs

Теперь посмотрим на новый размер нашего LV:
lvdisplay

--------------------------------------------------------------------

Make Apache2

cd /tmp/web

wget http://apache.ip-connect.vn.ua//httpd/httpd-2.4.33.tar.gz

tar –xzf httpd-2.4.33.tar.gz

cd httpd-2.4.33

./configure --enable-so
make
make install

/usr/local/apache2/bin/apachectl start

-------------------------------------------------------------------

Apache Web Server и доменная авторизация

Исходные данные: установлен Apache Web Server 2.4

Настройка виртуальных хостов:

В Ubuntu виртуальные хосты настроены на работу по умолчанию.
Настройки сайтов хранит /etc/apache2/sites-available/.
Будет загружен любой файл, который вы добавите в /etc/apache2/sites-enabled/, создав символическую ссылку на соответствующий сайт в /etc/apache2/sites-available/.

Включить сайт можно также командой:
a2ensite test.com.conf
service apache2 reload

Выключить, соответственно:
a2dissite test.com.conf
service apache2 reload



Файлы конфигурации виртуального хоста

Копируем настройки по-умолчанию в новый виртуальный хост:
cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/myproject.conf

Вносим дополнения и получаем примерно следующее на выходе:

<VirtualHost *:80>
    ServerName myproject.com
    ServerAlias www.myproject.com
    DocumentRoot /www/projects/myproject.com
    <Directory /www/projects/myproject.com>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Require all granted
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/myproject-error.log
    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn
    CustomLog ${APACHE_LOG_DIR}/myproject-access.log combined
</VirtualHost>

ServerName and ServerAlias:  домен, соответствующий этому виртуальному хосту и его алиас

DocumentRoot: веб-корень домена

Options -Indexes: останавливает людей от того, чтобы перейти в каталог и посмотреть файлы перечисленные там. Вместо этого они видят ошибку Forbidden. Это может запретить пользователям просматривать все ваши файлы в вашем/images каталоге, например.

AllowOverride: установить в «все», чтобы разрешить .htaccess файлы на вашем виртуальном хосте (и подкаталогах)

ErrorLog, CustomLog: создать файлы журналов специально для домена, они не смешиваются с трафиком/ошибками с других сайтов, работающих на сервере.

Winbind для проверки подлинности использует Kerberos. Для корректной работы Kerberos необходимо синхронизировать часы с доменом. Для это установим NTP. Настроим NTP. Синхронизируем время. Настроим автоматический запуск. И запустим NTP. Время синхронизированно. Установим необходимые пакеты:


yum -y install mod_auth_ntlm_winbind httpd-devel  autoconfig krb5-workstation samba samba-common samba-winbind

Следующим шагом необходимо сконфигурировать установленные пакеты и ввести сервер в домен. Для это в консоли пишем:

ADSERVER=FQDN контролера домена (например dc.company.local)
DOMAIN=домен  (company.local)
WORKGROUP= company
authconfig --enableshadow --enablemd5 --passalgo=md5 --krb5kdc=$ADSERVER --krb5realm=$DOMAIN --smbservers=$ADSERVER --smbworkgroup=$WORKGROUP --enablewinbind --enablewinbindauth --smbsecurity=ads --smbrealm=$DOMAIN --smbidmapuid="16777216-33554431" --smbidmapgid="16777216-33554431" --winbindseparator="+"  --winbindtemplateshell="/bin/false" --enablewinbindusedefaultdomain --disablewinbindoffline --winbindjoin=Administrator --disablewins --disablecache --enablelocauthorize –updateall

После этого мы должны получить сообщение о том, что наш сервер теперь является доменной машиной. Добавим правило для SE Linux:

setsebool -P allow_httpd_mod_auth_ntlm_winbind on

Запусим winbind
service winbind start

Настроим автоматический запуск:
chkconfig winbind on

Проверим правильность работы winbind:
wbinfo –u получим список пользователей
wbinfo –g получим список групп

Проверить правильность работы Kerberos можно получив тикет:
kinit administrator (любое имя доменного пользователя),по запросу вводим пароль.

Полученный тикет можно посмотреть командой:
klist


Для работы mod_auth_ntlm_winbind необходимо в файле /etc/httpd/conf/httpd.conf изменить параметр KeepAlive=off на KeepAlive=on.

В директории /etc/httpd/conf.d создаем файл ntlm_winbind.conf со следующим содержанием:
LoadModule auth_ntlm_winbind_module /usr/lib64/httpd/modules/mod_auth_ntlm_winbind.so
<Location ~ "(otrs/customer.pl)">
  AuthName "NTLM Authentication"
  AuthType NTLM
  Require valid-user
  NTLMAuth on
  NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
  NTLMBasicAuthoritative on
</Location>

Тем самым мы просим передать данные авторизации только при доступе к customer.pl
Последние что нужно сделать, это изменить Config.pm закоментировать часть отвечающую за авторизацию LDAP и добавить NTLM авторизацию.
# Авторизация LDAP
#$Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::LDAP';
#$Self->{'Customer::AuthModule::LDAP::Host'} = 'dc.company.local';
#$Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=COMPANY, dc=local';
#$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
#$Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = 'read_ad_user';
#$Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'pass_for_read_ad_user';

#Авторизация NTLM
$Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';


Проверим коректно ли зарегистрировался сервер OTRS на DNS сервере выполнив команду nslookup otrs-server
Настройка завершена!
Открывать в браузере otrs-server-name/otrs/customer.pl и видим результат.
Если же не видим результат, значит при настройке была допущена ошибка, внимательно смотрим настройки в файлах /etc/krb5.conf /etc/samba/smb.conf


NTLM устарело (модуль для апача, на сколько я знаю, больше не поддерживается и не разрабатывается). Используйте для прозрачной аутентификации Kerberos (поддерживается всеми браузерами).
Конфигурация Apache выглядит ничем не сложнее:

LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so

AllowOverride None
Options +ExecCGI -Includes
DirectoryIndex customer.pl
AuthName «OTRS Kerberos Authentication»
AuthType Kerberos
Krb5Keytab /etc/apache2/otrs-server.keytab
KrbAuthRealms DOMAIN1.COM DOMAIN2.COM
KrbMethodNegotiate On
KrbSaveCredentials Off
KrbMethodK5Passwd On
KrbVerifyKdc OFF
Require valid-user
KrbServiceName Any
Order allow,deny
Allow from all


https://www.linux.org.ru/forum/admin/13556405

MikroTik.Отправка списка адресов

Модификация скрипта из предыдущего поста для отправки на почту адресов, назначенных на интерфейсах:

:local months ("jan","feb","mar","apr","may","jun","jul","aug","sep","oct","nov","dec");
:local ts [/system clock get time];
:set ts ([:pick $ts 0 2].[:pick $ts 3 5].[:pick $ts 6 8]);
:local ds [/system clock get date];
:local month [ :pick $ds 0 3 ];
:local mm ([ :find $months $month -1 ] + 1);
:if ($mm < 10) do={ :set mm ("0" . $mm); };
:set ds ([:pick $ds 7 11] . $mm . [:pick $ds 4 6]);
:local fname3 ("Mikrotik-".[/system identity get name]."-".$ds."-".$ts.".ip");
/ip address print terse detail file=$fname3
/tool e-mail send to="admin@mail.com" subject=([/system identity get name]) from=mikrotik@mail.com file=$fname3 server=mail.mail.com;
:delay 3s;
:log info "send ip finished";
:delay 30s;
:foreach i in=[/file find] do={ :if ([:typeof [:find [/file get $i name] "Mikrotik-"]]!="nil") do={/file remove $i}; }
:log info message="Configuration backup finished.";

MikroTik. Скрипт бекапа на почтовый ящик

Для настройки бекапов на почту необходимы 2 ящика. Ящик, на который будут отправляться сообщения и, соответственно, ящик, от имени которого MikroTik будет отправлять сообщения.

Кому: admin@mail.com
От кого: mikrotik@mail.com

Предварительно необходимо настроить почту mikrotik@mail.com на MikroTik

В интерфейсе WinBox в меню Tools > EMail:

Скрипт отправки бекапа создаем в System > Scripts и называем BackupEmail:

:local months ("jan","feb","mar","apr","may","jun","jul","aug","sep","oct","nov","dec");
:local ts [/system clock get time];
:set ts ([:pick $ts 0 2].[:pick $ts 3 5].[:pick $ts 6 8]);
:local ds [/system clock get date];
:local month [ :pick $ds 0 3 ];
:local mm ([ :find $months $month -1 ] + 1);
:if ($mm < 10) do={ :set mm ("0" . $mm); };
:set ds ([:pick $ds 7 11] . $mm . [:pick $ds 4 6]);
:local fname1 ("Mikrotik-".[/system identity get name]."-".$ds."-".$ts.".backup");
:local fname2 ("Mikrotik-".[/system identity get name]."-".$ds."-".$ts.".rsc");
/system backup save dont-encrypt=yes name=$fname1
/export compact file=$fname2
/tool e-mail send to="admin@mail.com" subject=([/system identity get name]) from=mikrotik@mail.com file=$fname1 server=mail.mail.com;
:delay 3s;
/tool e-mail send to="admin@mail.com" subject=([/system identity get name]) from=mikrotik@mail.com file=$fname2 server=mail.mail.com;
:log info "backup finished";
:delay 30s;
:foreach i in=[/file find] do={ :if ([:typeof [:find [/file get $i name] "Mikrotik-"]]!="nil") do={/file remove $i}; }
:log info message="Configuration backup finished.";


И выполняем его по расписанию с помощью System > Scheduller:

Postfix. Запрет отправки

 Для запрета отправки и получения вложений с определенными расширениями делаем следующее

Редактируем файл главных настроек postmap /etc/postfix/main.cf

mime_header_checks = pcre:/etc/postfix/mime_check

Редактируем /etc/postfix/mime_check, добавив фильтр запрета вложений zip и pdf

/name=[^>]*\.(pdf|zip)/ REJECT


Запрещаем письма с китайской кодировкой
/^Subject: =?big5?/     REJECT Chinese encoding not accepted by this server


Запрещаем письма с китайских доменов
/^From:.*\@.*\.cn/      REJECT Sorry, Chinese mail not allowed here

Postfix. Контроль отправки на алиас all@

 Для того, чтобы ограничить права на отправку почты на алиас all@ определенным списком ящиков, делаем следующее

Создаем в /etc/postfix/main.cf новый класс (можно в начале файла)

smtpd_restriction_classes = checksent
checksent =
   check_sender_access hash:$config_directory/allow2all,
   reject

и в начале раздела smtpd_recipient_restrictions = первой строкой добавляем

check_recipient_access hash:$config_directory/aliases_all,

Создаем файлы allow2all и aliases_all в /etc/postfix/

touch /etc/postfix/allow2all
touch /etc/postfix/aliases_all

и редактируем их

Структура файла allow2all

#cat allow2all
nameusermail@domain.com      OK

Структура файла aliases_all

#cat alias_all
all@domain.com   checksent

Заставляем Postfix увидеть настройки

postmap /etc/postfix/main.cf
postmap /etc/postfix/allow2all
postmap /etc/postfix/aliases_all

Перезапускаем Postfix

service postfix reboot

Postfix. Перенаправление почтовых сообщений

 Для перенаправления почтовых сообщений средствами PostFix следует выполнить следующие действия:

• Проверить включен ли файл со списком перенаправлений в настройках PostFix

vi /etc/postfix/main.cf

• Отредактировать список, добавив в него требуемые записи <С какого ящика> <На какой ящик>

vi /etc/postfix/recipient_bcc_maps

• Применить изменения

postmap /etc/postfix/recipient_bcc_maps
postfix reload