Vadims Podans's former blog

По независящим от меня (а может и зависящим) причинам я сегодня объявляю о закрытии свего блога на spaces.live.com. Безусловно, блоггинг-движок здесь один из самых продвинутых, которые я видел, но, тем не менее, обладает некоторыми недостатками, которые мне кажутся важными. Это:

• очень слабые возможности управления комментариями в постах;
• отсутствие возможности присоединения поста к нескольким категориям;
• качество работы в последнее время оставляет желать лучшего.

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

Но я не прекращаю свою деятельность в качестве блоггера. Прежде чем закрыться мне нужно было найти альтернативу spaces и результатом поисков стал мой новый блог на отдельном хостинге. Я очень надеюсь, что мои постоянные читатели не сильно обременятся переключением на новый RSS feed.

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

Ну и самое главное - мой новый блог:

>> www.sysadmins.lv <<

Сегодня закончил читать книгу "Введение в Windows PowerShell", которую купил на ozon.ru. По сути данная книга - ужатый вариант симбиоза PowerShell In Action и Windows PowerShell Cookbook, который не содержит пространных рассуждений (коих в PowerShell In Action немало) и опущено достаточно много серьёзного (который применяется лишь в специфичных задачах) материала. Оно, собственно говоря, и верно, т.к. из названия видно, что это введение и в ней рассказываются только те вещи, которые необходимы для тех, кто только начинает изучение PowerShell. Но вместе с этим книга, как мне кажется, потеряла некоторую живость, т.е. текст выглядит достаточно сухо и идея лёгкости и простоты языка так же теряется. Я читал книгу как типичный хэндбук и руководство к пользованию. К технической части материала никаких претензий нету совершенно, т.к. тех.материал подобран автором удачно. Но это не учебник по высшей математике, а вводная книга по технологии, которая должна не только рассказать об этой технологии, но и заинтересовать ею читателя (книга "PowerShell In Action" образцово решила как техническую, так и общелитературную и агитационную составляющую). Если бы я не был до этого знаком с PowerShell и не читал других книг, то я вряд ли заинтересовался "очередной глючной поделкой от мелкософта" (цэ) луноходы этой технологией. Как мне кажется, причина тому:

Андрей Владимирович Попов

http://popov.math.mrsu.ru/ - сайт со страничкой автора книги.

Редко встречаются доценты и кандидаты наук, которые могут излагать свои мысли просто и с азартом (во всяком случае мне такие в РТУ не попадались). Но, тем не менее, видно, что автор старался писать наиболее понятным языком. Хотя, несколько слов (а точнее их значения в русском языке) мне так и остались непонятны. В принципе, все недостатки книги легко компенсируются технической составляющей. На редкость в книге разбираются не абстрактные примеры, а вполне реальные и живые примеры, которыми просто напичкана книга Windows PowerShell Cookbook. Вобщем, автору удалось выбрать самое лучшее из имеющихся англоязычных книг, хоть и общая концепция немного была утеряна и главы стали несколько оторваны друг от друга. Но в общем и целом впечатление от книги осталось очень и очень хорошее, т.к. данная книга позволяет сразу вникать в суть PowerShell, его работы и возможностей, позволяя за очень быстрое время начать писать собственные скрипты на новом (во всяком случае, ему ещё и 2 года не стукнуло) скриптовом языке.

• Я рекомендовую данную книгу для тех, кто только собирается начать изучение (или только начал изучать и хочет пойти дальше, кроме как умение запускать отдельные командлеты) PowerShell и достаточно быстро научиться писать собственные скрипты.
• Далее, если читатель захочет расширить свои познания в PowerShell я рекомендую прочесть PowerShell In Action. Данная книга позволит не только ближе ознакомиться с языком, но и проникнуться его философией.
• После можно будет серьёзно браться за PowerShell Cookbook (которую при первом приближении стоит рассматривать, как коллекцию скриптов), в которой уже описывается сам подход к решению задач в скриптах и с ней учиться разбирать готовые и писать собственные скрипты уже высокой сложности и эффективности.

Список актуальных и полезных книг по PowerShell прикреплены на главной странице блога в разделе "Книжная полка".

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

К типографии у меня 2 претензии:

1. как можно печатать книги на туалетной бумаге? Серовато-полупрозрачную бумагу, которая чуть толще газетной бумаги я иначе назвать не могу. Если для художественных произведений это ещё куда не шло (хотя, тоже не самый удачный выбор), то для тех.документации это недопустимо. Художественную литературу прочитал и положил на полку. Здесь же читать книгу и возвращаться к ней придётся не один раз. Плюс, в процессе изучения книга будет (во всяком случае предполагается такое) активно использоваться и, соответсвенно, изнашиваться будет не меньше. После 10 прочтений книга явно придёт в не совсем потребный вид. А ведь уже 2008 год на дворе, если что.
2. Шрифт. В последнее время читаю литературу только на английском языке (издательства MS Press и др.). Скажем, взять ту же Windows Vista Resource Kit или Windows Server 2008 Pki and Certificate Security. Открываешь книгу и она уже приятна для зрительного восприятия, её удобно читать. Здесь же шрифт подобран "совок классический" на бумаге "бумага совковая, классическая". Я, конечно же, понимаю, что администраторы должны уметь читать мануалы на любой бумаге с любым шрифтом и кроме материала книг ничего лишнего воспринимать не должны. Но, я думаю, на западе же не зря тратятся солидные средства только на оформление и дизайн печати, чтобы читателю было приятно открыть книгу, прочитать и получить от этого как эстетическое, так и интеллектуальное удовольствие. Здесь же книгу открыл, прочитал и появляется желание с ней сходить в туалет.

Вобщем, как говорит Артемий Лебедев: так верстают только мудаки. (цэ)

Citāts

PowerShell by default

The next versions of Windows will have PowerShell installed by default (except server core where its an option) -  http://blogs.msdn.com/powershell/archive/2008/10/28/powershell-will-be-installed-by-default-on-windows-server-08-r2-ws08r2-and-windows-7-w7.aspx

This is going to make remote admin a dream. When you add the new features in PowerShell v2 and the additional Windows functionality based on PowerShell - http://blogs.msdn.com/powershell/archive/2008/10/29/ny-times-delcares-powershell-to-be-30-of-the-value-of-windows-7.aspx

it really is going to be a case of you have to learn PowerShell to do your job.  I'm currently working through the study guide for one of the Exchange 2007 exams and I'm amazed by how much of it is PowerShell based. Takes me back to the SQL Server 6.5 admin exam that was all based on Stored Procedures (yes I know I'm showing my age :-) ).

Command lines rule.

 

Share this post :

 

Technorati Tags: PowerShell

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

• простота языка, функционал и семантика (которая на порядки лучше, чем в CMD/VBS/JS) ускоряет разработку скриптов и сценариев на PowerShell;
• следовательно, снижаются трудовые и финансовые затраты на администрирование сетей;
• наконец-то луноходы могут заткнуться с фразами, что в Windows нету консоли! (это по сути был единственный аргумент луноходов, против которого пользователям Windows сказать было по сути нечего).

Wow - the NY Times is Johnny-on-the-spot with their analysis of the 10 best features of Windows 7 for IT Pros HERE.  It turns out that PowerShell is responsible for 3 of them!

Сегодня на форуме TechNet задали вопрос о том, как преобразовать числовое значение типа прав доступа к объекту в его текстовое значение (см. тут). В предыдущих постах, посвящённых управленю ACL из PowerShell я использовал этот приём, но не акцентировал на этом внимание. Поэтому я подумал, что пора поставить на этом вопросе жирную точку.

Итак, как я не раз писал ранее, для управления списком доступа к объектам (ACL) используются различные классы .NET, например:

• File System - FileSystemRights;
• Registry - RegistryRights.

Если у нас есть числовое значение права доступа (как у автора топика на форуме), то преобразовать его в текстовый вид очень просто:

[System.Security.AccessControl.FileSystemRights]1179817

где 1179817 - числовое значение, которое описывает тип доступа. В данном случае это число соответствует праву ReadAndExecute и Synchronize. Если ввести другое число, например 721343:

[vPodans] [System.Security.AccessControl.FileSystemRights]721343
Modify, TakeOwnership

то мы получим текстовое значение прав, а именно - Modify и TakeOwnership. Бывают случаи, когда не допускается указания прав в текстовом виде и требуется указание только в числовом виде. Обратное преобразование выполняется при помощи свойства Value__ :

[vPodans] [System.Security.AccessControl.FileSystemRights]721343 | gm


   TypeName: System.Security.AccessControl.FileSystemRights

Name        MemberType Definition
----        ---------- ----------
CompareTo   Method     System.Int32 CompareTo(Object target)
Equals      Method     System.Boolean Equals(Object obj)
GetHashCode Method     System.Int32 GetHashCode()
GetType     Method     System.Type GetType()
GetTypeCode Method     System.TypeCode GetTypeCode()
ToString    Method     System.String ToString(), System.String ToString(String format, IFormatProvi..
value__     Property   System.Int32 value__ {get;set;}

Это единственное свойство, которое хранится в данном объекте. Посмотрим, как это работает на практике:

[vPodans] ([System.Security.AccessControl.FileSystemRights]"FullControl").value__
2032127

Вот так мы получили числовое значение права FullControl. По этой аналогии можно преобразовать типы доступа и к другим объектам, как реестр:

[vPodans] ([System.Security.AccessControl.RegistryRights]"FullControl").value__
983103
[vPodans] [System.Security.AccessControl.RegistryRights]2
SetValue
[vPodans]

Enjoy!

Ричард Сиддэвей (Richard Siddaway) в своём блоге ведёт на мой взгляд интересный цикл постов Windows 2000 Scripting Guide (W2KSG) с применением PowerShell и WMI. В них рассказываются достаточно интересные и полезные возможности классов WMI для сбора различных сведений как программной части системы, так и аппаратной. Так же недавно на форуме TechNet была поднята (да, на форумах всегда найдутся археологи, которые выкопают темы полу- и годичной давности, а то и ещё старше :) ) тема про скрипт, который бы собрал данные об аппаратной составляющей компьютеров. Подобные темы периодически всплывают на различных форумах. Я подумал, что неплохо было бы решить данный вопрос с помощью PowerShell.

Итак, отправной точкой для меня послужила ссылка на Computer System Hardware Classes, где я посмотрел какие классы можно применить. Изучив весь список я отобрал лишь самые необходимые для решения задачи классы, а именно:

• Win32_OperatingSystem
• Win32_Processor
• Win32_MemoryDevice
• Win32_BaseBoard
• Win32_VideoController
• Win32_DiskDrive
• Win32_LogicalDisk
• Win32_CDROMDrive
• Win32_NetworkAdapter

Достаточно сходить по ссылкам и можно посмотреть множество свойств каждого класса, которые детально описывают себя. Но при прочтении очень важно следить за поддерживаемыми свойствами в ОС, которые были выпущены до Windows Vista/2008. Я старался эти моменты учитывать, чтобы получить оптимальную совместимость как с предыдущими ОС, так и с текущими.

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

$OS = gwmi  Win32_OperatingSystem | Select Caption, OSArchitecture,
OtherTypeDescription, ServicePackMajorVersion, CSName, TotalVisibleMemorySize
$CPU = gwmi  Win32_Processor | Select Architecture, DeviceID, Name
$RAM = gwmi  Win32_MemoryDevice | Select DeviceID,
StartingAddress, EndingAddress
...

После определения всех классов WMI и переменных я начал писать секцию вывода. Например, вывод имени компьютера и ОС, под которой он управляется:

"Computer Name: `n`t" + $OS.CSName + "`n"
"Operating System: `n`t" + $OS.Caption + " " + $OS.OtherTypeDescription + $OS.OSArchitecture + "`n"

Здесь можно не обращать на знаки регулярных выражений, т.к. они несут только одну функцию, а именно - удобное для воспроиятия форматирование вывода. Т.е. первой строкой пойдёт название поля Computer Name, после чего будет переход на новую строку (`n). Чтобы все строчки не сливались я значения полей отделил табулятором (`t). И в конце так же добавил знак возврата каретки (`n), чтобы отделить между собой поля. Вывод в данном случае будет таким:

Computer Name:
        THOR


Operating System:
        MicrosoftR Windows VistaT Business  32-bit


Service Pack:
        Service Pack 1 installed


[vPodans]

Т.е. поля идут с левого края и между собой отделены двумя пустыми строками. А значения полей отделены табулятором относительно того же левого края. Мне кажется, что такой выход весьма читабелен и данные не сливаются в кучу. Когда у поля только одно значение - всё просто. Но когда значений возможно несколько, то задача форматирования выхода таких данных стала для меня небольшой проблемой. Почему небольшой - потому что ответ посмотрел в блоге у Ричарда, а именно в посте W2KSG: Free Disk Space. Суть заключается в очень простом: берётся переменная с массивом данных и по конвейеру при помощи команды Format-Table подготавливается табличный выход и с указанием основного элемента, по которому будет этот выход формироваться. Чтобы лучше понять этот процесс я покажу его на примере вывода сведений о процессоре. Сейчас многопроцессорные системы не редкость и скрипт должен поддерживать показ сведений о более чем одном процессоре:

[user name] $CPU = gwmi  Win32_Processor | Select Architecture, DeviceID, Name
[user name] "Processors:"
Processors:
[user name] $CPU | ft DeviceID, @{Label = "Architecture"; Expression = {switch ($_.Architecture) {
>> "0" {"x86"}; "1" {"MIPS"}; "2" {"Alpha"}; "3" {"PowerPC"}; "6" {"Intel Itanium"}; "9" {"x64"}}}},
>> @{Label = "Model"; Expression = {$_.name}} -AutoSize
>>

DeviceID Architecture Model
-------- ------------ -----
CPU0     x86          Intel(R) Pentium(R) 4 CPU 2.60GHz
CPU1     x86          Intel(R) Pentium(R) 4 CPU 2.60GHz


[user name]

К сожалению, ноутбук у меня однопроцессорный, поэтому эту часть скрипта я запустил на стационаре (в котором, кстати, тоже только 1 физический процессор. Но технология Hyper-Threading эмулирует именно настоящую мультипроцессорность, а не логические ядра, как это сделано в многоядерных процессорах). Итак, давайте разберём строку:

$CPU | ft DeviceID, @{Label = "Architecture"; Expression = {switch ($_.Architecture) {
"0" {"x86"}; "1" {"MIPS"}; "2" {"Alpha"}; "3" {"PowerPC"}; "6" {"Intel Itanium"}; "9" {"x64"}}}},
@{Label = "Model"; Expression = {$_.name}} -AutoSize

Переменная $CPU содержит сведения о всех установленных процессорах в системе. Я эту переменную передал по конвейеру сразу на команду форматирования - ft (сокращённый алиас от Format-Table) и указал по какому свойству форматировать (DeviceID, который перечисляет ID номера всех процессоров начиная с 0). А дальше я использовал несколько хэш-таблиц для отображения дополнительных свойств каждого объекта. Параметр Label задаёт название новой графе, а Expression указывается значение параметра (как Architecture и Model). Если посмотреть справку по классу Win32_Processor, то можно увидеть, что свойство Architecture содержит лишь числовое значение (от 0 до 9) и в справке приведена расшифровка этих значений. Числовые значения в данном случае, согласитесь, не самый читабельный вариант. Поэтому в Expression я вместил конструкцию Switch, которая автоматически будет числовым значениям сопоставлять понятные текстовые значения. И если свойство Architecture вернёт числовое значение 0, то Switch в нашем случае сопоставит ему более понятное значение x86. И в последней строке я добавил ещё одну хэш-таблицу, которая добавляет ещё одну графу - Model, которая будет содержать свойство Name класса Win32_Processor - название процессора.

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

$RAM = gwmi  Win32_MemoryDevice | Select DeviceID, StartingAddress, EndingAddress

DeviceID будет содержать номер каждого установленного модуля памяти начиная с нулевого ряда (разбор понятий Ряд и Банк памяти выходит за рамки данного поста) или первого слота. StartingAddress и EndingAddress показывают адресное пространство, за которое отвечает каждый модуль начиная от первого байта. И простым вычитанием начального адреса из конечного мы получим ёмкость каждого модуля:

$RAM | ft DeviceID, @{Label = "Module Size(MB)"; Expression = {(($_.endingaddress - $_.startingaddress) / 1KB).ToString("F00")}} -AutoSize

Так же, как и с процессорами я содержимое переменной $RAM перенаправил по конвейеру на форматирование по столбцу DeviceID. И через запятую добавил ещё одну хэш-таблицу, которая будет показывать объём каждого модуля. Если просто произвести операцию вычитания, то мы получим объём памяти в килобайтах. Чтобы показать объём в мегабайтах я просто разделил полученную разность на килобайты - 1KB (Очень удобная штука :) ). Здесь важно было не ошибиться, т.к. по логике может показаться, что нужно делать на 1MB, чтобы получить размер в мегабайтах. Но, как я уже сказал выше, у нас разность будет уже в килобайтах. Поэтому, чтобы получить в мегабайты, то нам нужно разделить только на 1KB. И посмотрим, что мы будем иметь на выходе:

[vPodans] $RAM = gwmi  Win32_MemoryDevice | Select DeviceID, StartingAddress, EndingAddress
[vPodans] $RAM | ft DeviceID, @{Label = "Module Size(MB)"; Expression = {(($_.endingaddress - 
$_.startingaddress) / 1KB).ToString("F00")}} -AutoSize

DeviceID        Module Size(MB)
--------        ---------------
Memory Device 0 1024
Memory Device 1 1024

[vPodans]

Вот так мы получили номера модулей памяти и объём каждого из них. После деления у нас не получится целое число, поэтому я сконвертировал это число в строку (ToString) и указал количество знаков после запятой - 0 знаков (F00). В данном случае дробное число просто округляется до ближайшего целого числа. Количество знаков после запятой можно изменить, например указав F01, которое округлит число до ближайшего целого числа с точностью до 1 знака после запятой. Это всё не я придумал, а честно взял из поста W2KSG: Free Disk Space :)

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

1. Оформил скрипт в функцию Get-HwInfo и с возможностью передачи в неё имён компьютеров
2. Каждый WMI класс позволяет собирать сведения не только с локальных комьютеров, но и с удалённых. Имя далённого компьютера указывается через параметр -ComputerName при вызове команды Get-WMIObject, например: $CPU = gwmi  Win32_Processor -ComputerName $computers | Select Architecture, DeviceID, Name

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

########################################################
# Get-HwInfo.ps1
# Version 1.0
#
# Getting basic information about systems hardware
#
# Vadims Podans (c) 2008
# http://vpodans.spaces.live.com/
########################################################

function Get-HwInfo ($computers = ".") {
$OS = gwmi  Win32_OperatingSystem -ComputerName $computers | Select Caption, OSArchitecture,
OtherTypeDescription, ServicePackMajorVersion, CSName, TotalVisibleMemorySize
$CPU = gwmi  Win32_Processor -ComputerName $computers | Select Architecture, DeviceID, Name
$RAM = gwmi  Win32_MemoryDevice -ComputerName $computers | Select DeviceID,
StartingAddress, EndingAddress
$MB = gwmi  Win32_BaseBoard -ComputerName $computers | Select Manufacturer, Product, Version
$VGA = gwmi  Win32_VideoController -ComputerName $computers | Select Name, AdapterRam
$HDD = gwmi  Win32_DiskDrive -ComputerName $computers | select Model, Size
$Volumes = gwmi  Win32_LogicalDisk -Filter "MediaType = 12" -ComputerName $computers | Select DeviceID,
Size, FreeSpace
$CD = gwmi Win32_CDROMDrive | Select Id, Name, MediaType
$NIC = gwmi Win32_NetworkAdapter -ComputerName $computers | ?{$_.NetConnectionID -ne $null}
"Computer Name: `n`t" + $OS.CSName + "`n"
"Operating System: `n`t" + $OS.Caption + " " + $OS.OtherTypeDescription + $OS.OSArchitecture + "`n"
"Service Pack: `n`t" + "Service Pack " + $OS.ServicePackMajorVersion + " installed`n"
"Processors:"
$CPU | ft DeviceID, @{Label = "Architecture"; Expression = {switch ($_.Architecture) {
"0" {"x86"}; "1" {"MIPS"}; "2" {"Alpha"}; "3" {"PowerPC"}; "6" {"Intel Itanium"}; "9" {"x64"}}}},
@{Label = "Model"; Expression = {$_.name}} -AutoSize
"Physical Memory: "
$RAM | ft DeviceID, @{Label = "Module Size(MB)"; Expression = {
(($_.endingaddress - $_.startingaddress) / 1KB).tostring("F00")}} -AutoSize
"Total Memory: `n`t" + ($OS.TotalVisibleMemorySize / 1KB).tostring("F00") + " MB`n"
"MotherBoard: "
"`tVendor: " + $MB.Manufacturer
"`tModel:  " + $MB.Product
"`tVersion: " + $MB.Version + "`n"
"Videocontroller:"
"`tModel: " + $VGA.Name
"`tVideo RAM: " + ($VGA.AdapterRam/1MB).tostring("F00") + " MB`n"
"HarddDisks:"
$HDD | ft Model, @{Label="Disk Size(GB)"; Expression = {($_.Size/1GB).tostring("F01")}} -AutoSize
"Disk Partitions:"
$Volumes | ft DeviceID, @{Label="TotalSize(GB)"; Expression={($_.Size/1GB).ToString("F01")}},
@{Label="FreeSize(GB)"; Expression={($_.FreeSpace/1GB).tostring("F01")}} -AutoSize
$CD | ft Id, @{Label = "Media Type"; Expression = {$_.MediaType}},
@{Label = "Model"; Expression = {$_.Name}} -AutoSize
"Netwok Adapters:"
$NIC | ft NetConnectionID, @{Label="Media Status"; Expression = {switch ($_.NetConnectionStatus) {
"0" {"Disconnected"}
"1" {"Connecting"}
"2" {"Connected"}
"3" {"Disconnecting"}
"4" {"Hardware not present"}
"5" {"Hardware disabled"}
"6" {"Hardware malfunction"}
"7" {"Media disconnected"}
"8" {"Authenticating"}
"9" {"Authentication succeeded"}
"10" {"Authentication failed"}
"11" {"Invalid address"}
"12" {"Credentials required"}
}}},
@{Label="NIC"; Expression={$_.name}}
}

Здесь видно, что в конце я снова применил конструкцию Switch, которая расшифровывает числовое значение статуса сетевого адаптера в его текстовое значение.

Согласен, что скрипт выглядит не очень опрятно, но в PowerGUI он выглядит вполне сносно. На основе данного скрипта каждый может его с лёгкостью расширить и изменить под свои нужды, я лишь старался показать образец решения задачи, а так же показал некоторые интересные приёмы в PowerShell. Кстати говоря, данный скрипт можно отправить в HTML формат командой ConvertTo-Html. Это будет удобно, когда потребуется собрать подобные сведения с нескольких компьютеров. Тогда HTML формат будет весьма полезен для последующего анализа. На сегодня всё, а теперь спать.