Глава 6. Администрирование Windows и Linux

В PowerShell Core установите модуль WindowsCompatibility, как это показано в нашем следующем примере:

# Сейчас он поставляется пустым
Get-Module -ListAvailable -SkipEditionCheck -Name ServerManager

# Тем не менее, преданные люди, такие как Брюс Пайетт, Стив Ли и Марк Краус сделали это возможным
Install-Module -Name WindowsCompatibility -Scope CurrentUser -Force -AllowClobber
 	   

Чтобы всё заработало, вам необходимо импортировать такой желаемый модуль. В нашем случае, ServerManager, как это показано в следующем примере:

# При помощи данного модуля для несовместимых модулей применяется неявное удалённое взаимодействие
# Одним из них является ServerManager
Import-WinModule -Name ServerManager
 	   

Обнаружьте все экспортированные cmdlet обычными методами, как это показывается в следующем примере:

# Теперь также работают и cmdlet обнаружения
Get-Command -Module ServerManager
 	   

Все cmdlet теперь работают и ведут себя просто отлично, что показано в примере далее:

# Внезапно всё заработало просто отлично
Get-WindowsFeature
Get-WindowsFeature -Name powershell-v2
 	   

Избавление от дыры в безопасности теперь простое снова, как мы это можем видеть в своём очередном примере:

# естественно при неявном удалённом взаимодействии конвейерная обработка повержена и утрачена
# В данном случае, однако, она работает прекрасно
Get-WindowsFeature -Name powershell-v2 | Remove-WindowsFeature
 	   

Это касается и инструментов управления установкой или включения прочих свойств, как видно из приводимого примера:

# само собой разумеется, что добавление свойств тоже делается просто
Get-WindowsFeature -Name RSAT-AD-Tools | Install-WindowsFeature
 	   

Прежде всего, нам требуется ознакомиться с самой системой и опросить все установленные группы пакетов, что показано в следующем коде:

# Давайте для начала определимся на месте
yum groups list
 	   

Фильтрация вывода команд в Linux через PowerShell очень простая, даже для пришедших из Windows администраторов, что мы можем обнаружить по следующему примеру:

# Так как команды ОС всегда возвращают текст,мы можем применять PowerShell для 
# получения именно тех сведений, которые нам требуются
yum groups list | Select-String 'Web Server'
(yum groups list) -match 'Web Server'
 	   

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

# Подавляем имеющийся поток ошибок
(yum groups list 2>$null) -match 'Web Server'
 	   

Теперь, когда у нас есть то что нам требуется, мы можем и дальше применять команды yum и реагировать на их состояние при помощи встроенных переменных, как это делается в ещё одном примере:

$groupname = ((yum groups list 2>$null) -match 'Web Server').Trim()
yum groups install $groupname -y

# Не применяя Start-Process, всё что мы получаем, так это значение кода самого последнего выхода
if ($LASTEXITCODE -ne 0)
{
    Write-Warning "Installing $groupname failed"
}
 	   

Применение Start-Process, хотя и не так натурально выглядит, по сравнению с обычным запуском команды, предлагает больше контроля и понимания, что видно из такого примера:

# Попробуйте это снова в процессе - будьте внимательнее при использовании отметки двойными кавычками
$process = Start-Process -FilePath yum -ArgumentList groups,install, "`"$groupname`"", '-y' -Wait -PassThru

if ($process.ExitCode -ne 0)
{
    Write-Warning "Installation with the following command line failed: $($process.StartInfo.FileName) $($process.StartInfo.Arguments)"
}
 	   

Для перечисления всех установленных пакетов мы можем вновь положиться на PowerShell для надлежащей обработки возвращаемой текстовой информации, как это демонстрирует следующий пример:

# Теперь наши инструменты отображают вывод как следует
# Получение правильного текста очень простое благодаря потрясающим возможностям PowerShell
(yum groups list 2>$null | Out-String) -match "Installed Environment Groups:\s+(?<PackageName>[\w\s]+)`n"
$Matches.PackageName
 	   

Мы имеем дело с неким модулем PowerShell Windows, который, к счастью, может целиком использоваться в PowerShell Core. В самых последних версиях Windows этот модуль в вопросах помечен как совместимый с PowerShell Core, избавляя нас от Шага 1. Начните с включения модулей Windows, как это показано в коде ниже:

Add-WindowsPSModulePath
 	   

Теперь мы можем обнаруживать все требуемые модули и применять их так:

Import-Module Microsoft.PowerShell.LocalAccounts -SkipEditionCheck
 	   

С помощью cmdlet New-LocalUser вы можете просто создать некую локальную учётную запись следующим образом:

New-LocalUser -AccountExpires (Get-Date -Year 2020 -Month 1) -Description 'A test user' -Name JHP -Password (Read-Host -AsSecureString)
 	   

Добавление этого пользователя в некую локальную группу также не составляет проблем, что демонстрирует такой пример:

Add-LocalGroupMember -Group Administrators -Member JHP
 	   

Помимо локальных учётных записей вы также можете добавлять доменные учётные записи (включая Azure AD), а также учётные записи Microsoft для локальных групп, что отображает следующий пример:

Add-LocalGroupMember -Group users -Member "MicrosoftAccount\username@Outlook.com"
 	   

Для удаления некого пользователя нам снова достаточно вызвать cmdlet, как это показывает ещё один пример:

Get-LocalUser -Name *JHP* | Remove-LocalUser
 	   

Прежде всего давайте убедимся есть ли уже доступные команды:

# Поиск подходящих команд - все они внешние
Get-Command -Name *user*
 	   

В системах Linux обычно для создания на лету локальных учётных записей применяются useradd и adduser, как это показывает такой пример:

# При помощи useradd мы можем передавать некий пароль - но его следует хэшировать
man useradd
 	   

Эти команды, тем не менее, ожидают какого- то хэшированного неким образом пароля. А потому давайте начнём с получения безопасным образом полномочий, как это показано в нашем примере:

$credential = Get-Credential -UserName notImportant
 	   

Хотя наш текущий пользователь всё ещё может осуществлять доступ с паролем в открытом виде, как того требуют команды Linux, наши полномочия всё ещё защищены, что демонстрирует такой пример:

$credential.GetNetworkCredential().Password
 	   

Поскольку сам формат для пароля в Linux достаточно особый, мы применяем в помощь себе прочие средства автоматизации, такие как Perl или Python, что показывает следующий пример:

$hashedPassword = python -c ('import crypt; print(crypt.crypt(\"{0}\", crypt.mksalt(crypt.METHOD_SHA512)))' -f $credential.GetNetworkCredential().Password)
 	   

Теперь будет легко создать некую учётную запись пользователя с надлежащим паролем таким манером:

useradd -G wheel -p $hashedPassword john
 	   

Не имея в качестве альтернативы способа выработки хэшированных паролей для Linux, вы могли бы создать соответствующего пользователя и установить его пароль позднее как в этом примере:

# Это могло бы быть неуклюжей альтернативой
useradd jim
$credential.GetNetworkCredential().Password | passwd --stdin jim
 	   

Необходимый реестр делается доступным через поставщика Registry таким образом:

Get-PSProvider -PSProvider Registry
Get-PSDrive -PSProvider Registry
 	   

Итак, для просмотра полученного реестра вы можете применять cmdlet Item, Location и Content, что показано в примере ниже:

Get-ChildItem -Path HKCU:\Software
Get-Location -path HKCU:\Software
Get-ItemProperty -Path HKCU:\Software\Classes -name EditFlags
 	   

Изменение некого значения очень просто выполнять локально, как мы это можем наблюдать в таком примере:

# Изменение имеющегося локального реестра достаточно простое
# например, отключаем UI Server manager при входе в систему
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ServerManager" -name "DoNotOpenServerManagerAtLogon" -Value 1
 	   

Вспомните полученный вывод Шага 1 - поставщик Registry не способен монтировать ульи удалённого реестра. Итак, как же нам получать доступ к реестру удалённых машин с локального хоста? Давайте рассмотрим следующий код:

# Применение встроенных cmdlets не допускает работу с удалённым реестром
(Get-PSProvider -PSProvider Registry).Capabilities
# Тем не менее, при помощи .NET, нет ничего невозможного
$remoteHive = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', 'DSCCASQL01')
 	   

Получив открытым необходимый улей, мы можем открыть подчинённый ключ с доступом на запись таким образом:

# Применим булево значение для открытия некого ключа с доступом на запись:
$key = $remotehive.OpenSubKey('SoFTWarE\microsoft\servermanager', $true)
 	   

Теперь мы способны считывать данные так:

# Сейчас мы также можем пользоваться и необходимым удалённым ключом
$key.GetValue('DoNotopenServerManagerAtLogon')
 	   

Мы также способны изменять данные следующим образом:

# А имея доступ на запись, мы также можем и выполнять запись в него
$key.SetValue('DoNotopenServerManagerAtLogon', 0)
 	   

Следующий пример отображает наиболее распространённую точку входа, /etc:

# Всё начинается здесь
Get-ChildItem -Path /etc -File
 	   

Для изменения таких настроек системы как максимальное число оболочек на группу пользователей мы можем пожелать изменить /etc/security/limits.conf, как это показано в нашем примере:

# Для управления установленными пределами pam, загляните в limits.conf
Get-Content -Path /etc/security/limits.conf

# Попробуйте отфильтровать наиболее важные части
Get-Content -Path /etc/security/limits.conf | Where-Object {-not $_.StartsWith('#')}
 	   

Все записи в относящемуся к PAM limits.conf и все файлы конфигурации в limits.d, все они следуют одному и тому же синтаксису, для которого PowerShell очень хорошо проводит синтаксический разбор, что показано в нашем следующем примере:

# Для этих элементов проявляется некий шаблон... Значения, разделяемые пробелами
man limits.conf

# И естественно, просмотр страниц man page выявляет <domain> <type> <item> <value>
$limits = Get-Content -Path /etc/security/limits.conf | Where-Object {-not $_.StartsWith('#')} |
    ForEach-Object {
    $null = $_ -match "(?<Domain>[\w@]+)\s+(?<Type>hard|soft|-)\s+(?<Item>\w+)\s+(?<Value>\d+)"

    # Удаляем всё соответствие целиком - на самом деле оно нам не требуется
    $Matches.Remove(0)

    # Соответствия являются неким словарём. Который, кстати, может использовать PSCustomObject
    [pscustomobject]$Matches
}

# Обычные переменные, которые можно изменить и сохранить снова
$limits[0].Type = 'Soft'
$limits[0].Item = 'nproc'
$limits[0].Value = 10
 	   

При наличии Add-Content запись обратных значения очень проста, что показано ниже:

# Добавляем некий новый предел подобный приводимому, т.е. ограничить конкретного пользователя MyUser 20 процессами
Add-Content -Value 'MyUser hard nproc 20' -Path /etc/security/limits.conf
 	   

PowerShell обладает рядом существенных возможностей RegEx, поэтому мы можем просто заменять содержимое в файлах, что демонстрирует такой пример:

# PowerShell также исключительно подходит для быстрого изменения значения в конфигурации
# администраторы Linux по- прежнему могут применять неудобочитаемые регулярные выражения - благодаря подробному 
# языку PowerShell, новички получают возможность хотя бы лучше понимать преследуемую цель
$newPort = 4729
(Get-Content -Path /etc/ssh/sshd_config) -replace "^Port\s+\d+" | Set-Content -Path /etc/ssh/sshd_config -Whatif
 	   

Для некой новой службы нам вначале требуется некий исполняемый файл, который взаимодействует с имеющимся контроллером служб (service controller) - того приложения, с которым вы взаимодействуете при исполнении освящённого веками sc.exe, как в следующем примере:

# Посторим шаблон макета службы
dotnet build .\project1
 	   

Данный образец макета службы принимает запросы от диспетчера управления службами, например Start-Service и Stop-Service, что показано в примере ниже:

# Данная простейшая служба лишь реагирует на запросы и не делает более ничего
.\project1\bin\debug\project1.exe
 	   

С помощью cmdlet New-Service вы имеете возможность зарегистрировать свою службу следующим образом:

# Применяя наш макет службы мы даже реагируем на прочие cmdlets служб
# Требуется разрешение пути, ибо New-Service не осуществляет разрешение относительного пути
New-Service -Name Dummy1 -BinaryPathName (Resolve-Path -Path .\project1\bin\debug\project1.exe).Path
Start-Service Dummy1
Stop-Service Dummy1
 	   

Конечно же, New-Service, также как и Set-Service допускает различные полномочия, что можно наблюдать в нашем следующем примере:

$credential = [pscredential]::new('LocalUserJohn', ('Somepass1!' | ConvertTo-SecureString -AsPlainText -Force))
New-LocalUser -Name $credential.UserName -Password $credential.Password
Set-Service -Name Dummy1 -Credential $credential -StartupType AutomaticDelayedStart
 	   

Некий cmdlet, которого очень не хватает в PowerShell Windows, даже после всех лет его эксплуатации, это Remove-Service. К счастью, в PowerShell Core он имеется, что показывается в нашем примере ниже:

# Один из cmdlet который упущен всё ещё в Windows PowerShell даже в наши дни
Remove-Service -Name dummy1 -Verbose
 	   

Запустите поиск доступных cmdlet - на момент написания их не было. Этот отображает следующий пример:

# Пока нет cmdlets служб
Get-Command -Noun Service
 	   

В CentOS, Fedora и Red Hat, помимо прочего, в качестве системы init применяется systemd, что демонстрирует такой пример:

New-VM -Name VM01 -Generation 2
 	   

Хотя он может применяться и для логических элементов, отличных от служб, мы сосредоточимся на части, относящейся к службам, что показано в примере ниже:

# Systemd является некой системой init, которая, естественно применяется не только для служб (daemons - демонов)
systemctl status sshd
service sshd status # deprecated with systemd
 	   

Прежде всего мы можем применять PowerShell для создания приятных функций, относящихся к systemd, которые будут назваться Get-Service. Для этого обратите внимание на получаемый шаблон в выводе systemctl для такого примера:

# Мы всё ещё можем применять PowerShell
systemctl list-units --type service --no-pager
 	   

Мы можем применять его для улучшения получаемого вывода создавая новые объекты, которые могут форматироваться. Начнём прежде всего с некой пустой функции и параметров по умолчанию, что показано в приводимом коде:

function Get-Service
{
    [CmdletBinding()]
    param
    (
        [string[]]
        $Name,

        [string]
        $ComputerName
    )
}
 	   

Естественно, Get-Service способен запускаться удалённо. Или ещё лучше: systemctl имеет возможность через SSH удалённо опрашивать хосты. Вот команда, которая применяет такие изменения:

$results = if ($ComputerName)
{
    systemctl list-units --type service --no-pager -H $ComputerName
}
else
{
    systemctl list-units --all --type service --no-pager
}
 	   

Теперь мы можем применить некое простое регулярное выражение для создания нового объекта, что показано в нашем следующем примере:

$services = foreach ($result in $results)
    {
        #UNIT LOAD ACTIVE SUB DESCRIPTION
        if ($result -match '(?<Name>\w+)\.service\s+(?<LoadedState>\w+)\s+(?<UnitStatus>\w+)\s+(?<Status>\w+)\s+(?<Description>\w[\w\s]*)')
        {
            $tmp = $Matches.Clone()
            $tmp.Remove(0)
            [pscustomobject]$tmp
        }
    }
 	   

После всего этого нам требуется выполнить фильтрацию, если наш пользователь решит применять параметр Name, таким образом:

if ($Name)
{
    Write-Verbose -Message "Applying like-filter for $Name"
    return $services | Where-Object -Property Name -like $Name
}

$services
 	   

Теперь мы можем применять все виды полезных cmdlet, что показывает наш следующий пример:

# Например, с целью форматирования
Get-Service | Format-Table -Property Status, Name, Description
Get-Service | Where-Object -Property Status -eq 'Running'

# Или сортировки
Get-Service | Sort-Object -Property Name

# Или группирования
Get-Service | Group-Object -Property Status
 	   

Новая служба также может быть очень быстро создана, что демонстрирует такой пример:

# Создание какого- то нового демона требует тех же самым базовых компонентов, что и для службы Windows:
# Нечто для исполнения.
# Давайте возьмём сценарий Polaris из "Learn PowerShell Core"!
Get-Content ./LinuxDaemon/polaris.ps1

# В PowerShell мы также можем создать соответствующее определение службы
# Для этого исключительно подходит строка "с этого места" (here-string).
@"
[Unit]
Description=File storage web service

[Service]
ExecStart=$((Get-Process -Id $pid).Path) $((Resolve-Path -Path ./startpolaris.ps1).Path)

[Install]
WantedBy=multi-user.target
"@ | Set-Content /etc/systemd/system/polaris.service -Force

systemctl daemon-reload
systemctl start polaris
 	   

Вместо создания файлов мы также можем следующим образом создать некий новый cmdlet с названием New-Service:

function New-Service
{
    param
    (
        [Parameter(Mandatory)]
        [string]
        $BinaryPathName,

        [Parameter(Mandatory)]
        [string]
        $Name,

        [string]
        $Description,

        [string]
        $User = 'root',

        # один из systemctl list-units --type target --no-pager
        [string]
        $Target = 'multi-user'
    )
}
 	   

New-Service просто добавляет соответствующие значения параметра в сам файл определения службы, что показывает наш пример:

@"
[Unit]
Description=$Description

[Service]
ExecStart=$BinaryPathName
User=$User

[Install]
WantedBy=$Target.target
"@ | Set-Content "/etc/systemd/system/$Name.service" -Force

# Выполняем daemon-reload для указания на файл новой службы
systemctl daemon-reload

Get-Service -Name $Name
 	   

После регистрации вашей новой службы вы можете создать ешё один новый cmdlet или применить: systemctl start polaris

Отыщите cmdlet ScheduledTask следующим образом:

Get-ScheduledTask
 	   

Прежде всего мы бы хотели перечислить все зарегистрированные в системе задачи:

Get-ScheduledTask -TaskName *Cache*
Get-ScheduledTask -TaskPath \Microsoft\Windows\Wininet\
 	   

Удалённое исполнение может быть достигнуто с помощью удалённого CIM, что показывает такой пример:

Get-ScheduledTask -TaskName *Cache* -CimSession (New-CimSession -ComputerName host1)
 	   

Чтобы зарегистрировать какую- то новую задачу, следует воспользоваться некими компонентами. Прежде всего, самим действием для исполнения, как в следующем примере:

$action = New-ScheduledTaskAction -Execute pwsh -Argument '-Command " & {"It is now $(Get-Date) in task land"}'
 	   

Далее полезен также некий переключатель, например:

$trigger = New-ScheduledTaskTrigger -At (Get-Date).AddMinutes(5) -Once
 	   

Наконец, и это совершенно не обязательно, это настройки самой задачи, как показано здесь:

$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -RunOnlyIfNetworkAvailable
 	   

При помощи cmdlet New-ScheduledTask создаётся некий объект задачи. Этот объект всё ещё не функционален, что показывает такой пример:

task = New-ScheduledTask -Action $action -Description "Says hello" -Trigger $trigger -Settings $settings
 	   

Регистрация этого объекта задачи применяет необходимый трюк, показанный в коде ниже:

$registeredTask = $task | Register-ScheduledTask -TaskName MyTask -TaskPath \MyTasks\
 	   

Теперь мы можем взаимодействовать со своей задачей как нужно. Это показывает такой пример:

# Для взаимодействия с нашей можно применять соответствующий cmdlet
$registeredTask | Start-ScheduledTask
$registeredTask | Stop-ScheduledTask

# Наконец, отменяем регистрацию задачи
$registeredTask | Unregister-ScheduledTask
 	   

Запустите как показано здесь обнаружение всех имеющихся cmdlet:

# И снова - собственные cmdlet отсутствуют
Get-Command *ScheduledTask*
 	   

Нам вновь требуется поработать над пропущенным кодом. Однако на этот случай команда PowerShell кое- что имеет в загашнике, что демонстрирует наш пример:

# Download the CronTab module from GitHub
$null = New-Item -ItemType Directory -Path /usr/local/share/powershell/Modules/CronTab -ErrorAction SilentlyContinue
Invoke-WebRequest -Uri https://raw.githubusercontent.com/PowerShell/PowerShell/master/demos/crontab/CronTab/CronTab.psm1 -OutFile /usr/local/share/powershell/Modules/CronTab/CronTab.psm1
 	   

Только что выгруженный модуль может быть импортирован автоматически, как только мы сохраним его в своём PSModulePath. Однако, отличной мыслью будет для начала проверить содержимое самого модуля, что показывает наш следующий пример:

cat /usr/local/share/powershell/Modules/CronTab/CronTab.psm1
 	   

Теперь, когда у нас имеется модуль, выявление cmdlet работает так:

# Выявляем имеющееся содержимое
Get-Command -Module CronTab
 	   

попробуйте вначале опросить имеющийся CronTab, как это сделано в нашем примере:

# Давайте посмотрим есть ли какие- то задания
Get-CronTab

# Get-Crontab отображает имеющееся содержимое, Get-CronJob слегка дружелюбнее:
Get-CronJob
 	   

Чтобы добавить некую новую запись (зарегистрировать новую задачу) мы можем воспользоваться New-CronJob, как это показывает наш следующий пример:

# Создать новое задание очень просто
New-CronJob -Minute 5 -Hour * -DayOfMonth * -Command "$((Get-Process -Id $pid).Path) -Command '& {Add-Content -Value awesome -Path ~/taskfile}'"
 	   

Поиск имеющихся заданий слегка более изощрённое, так как нет имён или путей, как это имеется при планировании в Windows. Это демонстрирует такой код:

# Поскольку у заданий cron нет имён как у запланированных задач, их поиск может быть достаточно хитроумным 
Get-CronJob | Where-Object -Property Command -like '*awesome*'
Get-CronJob | Where-Object -Property Minute -eq 5
 	   

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

# This is especially important when trying to remove a job
Get-CronJob | Where-Object -Property Command -like '*awesome*' | Remove-CronJob -WhatIf
Get-CronJob | Where-Object -Property Command -like '*awesome*' | Remove-CronJob -Confirm:$false
 	   

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

Get-StoragePool
 	   

Как и обычный первичный бульон, наш первичный пул просто содержит необходимые элементы для всех новых пулов хранения. На диски, которые могут быть добавлены в некий пул, указывает некое свойство CanPool, как это показано в следующем примере:

Get-StoragePool -IsPrimordial $true | Get-PhysicalDisk | Where-Object -Property CanPool
 	   

Попробуйте добавить самую первую половину из имеющихся дисков в один пул, как в нашем примере:

$disks = Get-StoragePool -IsPrimordial $true | Get-PhysicalDisk | Where-Object -Property CanPool | Select -First 5

# Теперь мы можем создать некий новый виртуальный диск и в конечном счёте какой- то новый том
Get-StorageSubSystem
New-StoragePool -PhysicalDisks $disks -FriendlyName 'Splish splash' -StorageSubSystemFriendlyName 'Windows Storage*'
 	   

Теперь мы можем создать некий новый виртуальный диск и в конечном счёте какой- то новый том, как в следующем примере:

Get-StoragePool -FriendlyName 'Splish Splash' | 
    New-VirtualDisk -FriendlyName Accounting -UseMaximumSize

$volume = Get-VirtualDisk –FriendlyName Accounting | Get-Disk | Initialize-Disk –Passthru | New-Partition –AssignDriveLetter –UseMaximumSize | Format-Volume
$largefile = [System.IO.File]::Create("$($Volume.DriveLetter):\largefile")
$largefile.SetLength($volume.SizeRemaining - 1kB)
$largefile.Close()
 	   

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

Get-StoragePool -FriendlyName 'Splish Splash' | 
    Add-PhysicalDisk -PhysicalDisks (Get-StoragePool -IsPrimordial $true | Get-PhysicalDisk | Where-Object -Property CanPool)
 	   

Теперь, когда этот пул вырос, наши виртуальный диск и том также могут быть увеличены, что можно увидеть из нашего следующего примера:

Get-VirtualDisk -FriendlyName Accounting | Resize-VirtualDisk -Size 16GB
$volume | Get-Partition | Resize-Partition -Size 15GB
 	   

Все начинается с изучения имеющихся в наличии томов. Так как такие cmdlet как Get-PhysicalDisk ограничены лишь Windows, нам придётся вновь применить CLI на основе текста, как в следующем примере:

lsblk -io KNAME,TYPE,SIZE,MODEL
 	   

Как и cmdlet Get-Disk, lsblk перечисляет все блочные устройства, которые могут применяться для нашего программно определяемого RAID. Создание некого устройства RAID является более сложным нежели создание какого- то пула хранения. Тем не менее, давайте слегка очистим наши данные при помощи PowerShell. Прежде всего, мы можем создать очень простое множество элементов как в приводимом ниже примере:

class BlockDevice
{
    [string] $Name
    [string] $Type
    [int64] $Size
}
 	   

Теперь нам нужно создать для некого повторяемого кода функцию,отображаемую в примере:

function Get-Disk
{
    lsblk -ibo KNAME,TYPE,SIZE,MODEL | Select-Object -Skip 1 | ForEach-Object {
        if ($_ -match '(?<Name>\w+)\s+(?<Type>\w+)\s+(?<Size>[\w\d.]+)\s')
        {
            $tmp = $Matches.Clone()
            $tmp.Remove(0)
            [BlockDevice]$tmp
        }
    }
}
 	   

Теперь мы можем отфильтровать свои диски как в приводимом далее примере - мы также можем воспользоваться соответствующей командой Get-ChildItem, в предположении что нам известно как именуются наши дисковые устройства:

Get-Disk | Where-object -Property Type -ne 'part'
 	   

Команда mdadm в Linux способна создавать некое RAID устройство - но мы желаем для своих достижений воспользоваться PowerShell. На ум приходит новая функция. Начните с перечисления и некого нового класса:

enum RaidLevel
{
    RAID0 = 0
    RAID1 = 1
    RAID4 = 4
    RAID5 = 5
    RAID6 = 6
    RAID10 = 10
}

class RaidDevice
{
    [string] $DeviceName
    [string[]] $MemberDevice
    [RaidLevel] $Level
}
 	   

Теперь мы можем воспользоваться своими новыми типами данных в новой функции с названием Get-SoftwareRaid, прежде чем начнём создавать некое новое, как это показывает наш пример:

function Get-SoftwareRaid
{
 [CmdletBinding()]
 param
 (
 $DeviceName
 )

    $devices = foreach ($line in (Get-Content -Path /proc/mdstat))
    {
        if ($line -match '(?[\w\d]+)\s+:\s+active\s+raid(?[\d])\s+')
        {
            $tmp = $Matches.Clone()
            $tmp.Remove(0)
            $device = [RaidDevice]$tmp

            $deviceString = $line -replace ".*raid\d{1,2}\s+"
            $device.MemberDevice += $deviceString -split "\s" -replace "\[\d+\]"
            $device
        }
    }

    if ($DeviceName)
    {
        $devices = $devices | Where-Object -Property DeviceName -eq $DeviceName
    }

    $devices
}
 	   

Теперь, когда мы можем получить имеющуюся конфигурацию RAID, почему бы нам не создать некий cmdlet, который применяет mdadm неким упорядоченным манером? Вот пример этого:

function New-SoftwareRaid
{
    ...

    process
    {
        if (($MemberDevice | Test-Path) -contains $false)
        {
            Write-Error -Message "One or more member devices not found."
            return
        }

        $devices += $MemberDevice.FullName
        $deviceCount += $MemberDevice.Count
    } 
    
    end
    { 
        ...
        Start-Process -FilePath (Get-Command mdadm).Path -ArgumentList $arguments -Wait -NoNewWindow
    }
}
 	   

Великолепно. Опробуйте свой новый cmdlet в соответствующем конвейере, как показано в следующем коде:

Get-ChildItem -Path /dev/sd[cd] | New-SoftwareRaid -DeviceName md0 -Level Raid0 -Verbose
 	   

Теперь для очистки создайте свою новую функцию Remove-SoftwareRaid, сочетая необходимые команды ОС с PowerShell, что плказывает такой пример:

function Remove-SoftwareRaid
{
    ...

    begin
    {
        $memberDisks = @()
    }

    process
    {
        ...
        $raid = Get-SoftwareRaid -DeviceName $DeviceName.BaseName
        umount $DeviceName.FullName
        mdadm --stop $DeviceName.FullName
        mdadm --zero-superblock /dev/$memberDisk
    }
}
 	   

Попробуйте следующим образом свой новый cmdlet:

Get-Item -Path /dev/md0 | Remove-SoftwareRaid -WhatIf
Get-Item -Path /dev/md0 | Remove-SoftwareRaid -Confirm:$false
 	   

Как и для большинства рецептов, для начала ознакомимся с вашим окружением, например, так:

# Давайте сначала озакомимся с cmdlet first - приготовьтесь к удару!
Get-WinEvent -ListLog * -ErrorAction SilentlyContinue | Format-Wide -Property LogName -Column 4
 	   

Каналы ETW (Event Tracing for Windows) это гигантские объёмы информации. Давайте взглянем на такую команду:

Get-WinEvent -ListProvider *Security* | Format-Wide -Property Name -Column 4
 	   

Однако нас интересует журнал Security; в особенности отказы в регистрации, что показывает такой пример:

Get-WinEvent -LogName Security -MaxEvents 1
 	   

Мы можем выработать нужные нам события отказов в регистрации подобно такому примеру:

# Чтобы это сработало, не забудьте воспользоваться неверным паролем ;)
runas /user:$($env:COMPUTERNAME)\$($env:USERNAME) pwsh
 	   

Для получения такого события имеются два способа. А именно: эффективный и недейственный Начнём с показанного ниже недейственного, чтобы более просто разобраться с улучшениями:

# Мы можем получать данное событие не самым лучшим способом. Выполняя подобные приглашения Get-WinEvent для объединения 
# по ВСЕМУ журналу безопасности - а вы знаете насколько он велик.
Get-WinEvent -LogName Security | Where-Object -Property ID -eq 4625
 	   

Лучший вариант состоит в применении одного из имеющихся параметров фильтрации - помните: фильтруйте как можно раньше - как это показано в следующем примере:

# Вот екий лучший способ
Get-Command Get-WinEvent -Syntax

# Давайте начнём с FilterHashtable по причине его простоты - огненно быстро
$failedLogin = Get-WinEvent -FilterHashtable @{LogName = 'Security'; ID = 4625} -MaxEvents 1
 	   

Выбрав такие события мы можем изучить их слегка подробнее, например:

# Теперь мы можем изучить их - куча сведений
$failedLogin | Get-Member -MemberType Properties

# В особенности важный фрагмент сведений - имеющиеся свойства. Но увы, они не имеют названий
# но мы рассмотрим их
$failedLogin.Properties
 	   

Поскольку мы не желаем работать с неструктурированной информацией, такой как массив строк, мы можем взглянуть на имеющуюся структуру XML самого события. Некий образец демонстрирует следующий код:

# Как мы знаем, в естественном виде всякое событие представлено некой структурой XML
$failedLogin.ToXml()

# Мы можем воспользоваться XML
$xmlEvent = [xml]$failedLogin.ToXml()

# Ну, тогда пошли :)
$xmlEvent.Event.EventData.Data

# Что более важно, мы теперь способны отфильтровать в точности то что нам необходимо
($xmlEvent.Event.EventData.Data | Where Name -eq TargetUserName).InnerText
 	   

Великолепным свойством Get-WinEvent является то, что мы можем фильтровать свои события даже больше - например, по интересующему нас значению TargetUserName - как это показывает наш следующий пример:

# Введём фильтр XPATH.
$filter = '*[System[EventID=4625]] and *[EventData[Data[@Name = "TargetUserName"] = "japete"]]'
Get-WinEvent -FilterXPath $filter -LogName Security
 	   

А если XPATH это нечто что вы не можете легко запомнить, попробуйте снова FilterHashtable. Существует единственный ключ с названием '*', возможно мы можем им воспользоваться, как показано в примере ниже:

Get-Help Get-WinEvent -Parameter FilterHashtable
Get-WinEvent -FilterHashtable @{LogName = 'Security'; ID = 4625; TargetUserName = 'japete'}
 	   

Имейте ввиду, что удалённая работа с соответствующим параметром ComputerName крайне неэффективна. Может применяться за раз лишь одна машина. Вместо этого применяйте удалённый PowerShell, как показано в нашем примере:

# Естественно, всё что мы здесь делаем, мы можем выполнять удалённо в десятках машин.
$filterTable = @{LogName = 'Security'; ID = 4625; TargetUserName = 'japete'}

Invoke-Command -ComputerName (Get-Content .\thousandsOfMachines.txt) -ScriptBlock {
    Get-WinEvent -FilterHashtable $using:filterTable
}
 	   

Прежде всего нам требуется ознакомиться с азами. Давйте рассмотрим такую команду:

# В отличии от Windows Linux не работает с журнаами событий
Get-ChildItem /var/log

# Что ещё хуже, его файлы журнала по умолчанию совершенно в ином формате
Get-ChildItem -Path /var/log -File | foreach {$_ | Get-Content | Select -First 1 -Skip 5 }