Book Image

PowerShell Core for Linux Administrators Cookbook

By : Prashanth Jayaram, Ram Iyer
Book Image

PowerShell Core for Linux Administrators Cookbook

By: Prashanth Jayaram, Ram Iyer

Overview of this book

PowerShell Core, the open source, cross-platform that is based on the open source, cross-platform .NET Core, is not a shell that came out by accident; it was intentionally created to be versatile and easy to learn at the same time. PowerShell Core enables automation on systems ranging from the Raspberry Pi to the cloud. PowerShell Core for Linux Administrators Cookbook uses simple, real-world examples that teach you how to use PowerShell to effectively administer your environment. As you make your way through the book, you will cover interesting recipes on how PowerShell Core can be used to quickly automate complex, repetitive, and time-consuming tasks. In the concluding chapters, you will learn how to develop scripts to automate tasks that involve systems and enterprise management. By the end of this book, you will have learned about the automation capabilities of PowerShell Core, including remote management using OpenSSH, cross-platform enterprise management, working with Docker containers, and managing SQL databases.
Table of Contents (19 chapters)

Comparing Windows PowerShell and PowerShell Core

Windows PowerShell and PowerShell Core are two different implementations. The former is based on a larger framework, the .NET Framework. The latter, on the other hand, is a more modern framework, the .NET Core. PowerShell Core is cross-platform since its parent is. Windows PowerShell, on the other hand, is Windows-only, but has more capabilities than PowerShell at the time of writing this book.

The PowerShell that this book talks about is the cross-platform PowerShell Core. This is referred to as PowerShell. The PowerShell that is Windows-specific is referred to as Windows PowerShell.

Windows PowerShell leverages the internal components and the architectural model of Windows, with its capabilities enhanced by WinRM as well as Windows Management Instrumentation. In fact, most of the differences exist because of the inherent differences between Windows and Unix-like operating systems.

Support for snap-ins

PowerShell will not support the legacy version of modules, also known as snap-ins. Many of the snap-ins of old have been repackaged to be binary modules. Therefore, the unavailability of snap-ins should not be of much concern. Future development of these binary modules should, in theory, work on either PowerShell, provided that the host supports the API calls that are part of the binaries. For example, let's imagine that the Windows Active Directory module was repackaged into a binary PowerShell module. This module would run on Windows PowerShell as well as PowerShell on Windows. However, since Windows Active Directory does not run on Linux, the module would not work with PowerShell on Linux.

Convenience aliases

One important point to note is that commands such as ls and mkdir are aliases in Windows PowerShell, which means that running ls on Windows PowerShell would run Get-ChildItem in the background (this is also true for PowerShell on Windows). In Linux, however, running ls from within PowerShell would run the actual ls command; ls is not an alias in PowerShell on Linuxit is the command itself, whose output would be plain text. You can validate this by running ls | Get-Member on PowerShell on Linux, and comparing it with PowerShell on Windows as well as Windows PowerShell (it is, therefore, good to stick to the best practice of not using aliases in scripts):

PowerShell knows whether it is running on Linux, Windows, or macOS by means of the values of the automatic variables IsLinux, IsWindows, and IsMacOS. On any system, only one of these variables has the value True. When PowerShell sees that IsLinux is True, it would run Linux commands instead of the convenience aliases that were initially created to facilitate Linux administrators. For more information on these automatic variables, read the Configuring built-in variables recipe.

PowerShell Workflows

Windows administrators who are used to PowerShell Workflows in Windows PowerShell need to note that they are absent in PowerShell. PowerShell Workflows were a little advanced (to put it nicely) and were used in specific scenarios where multiple cmdlets were to be run in parallel, or activities had to, say, survive a reboot. Workflows work on the Windows Workflow Foundation, which is not cross-platform. Therefore, PowerShell Workflows will not run on PowerShell. However, the unavailability of PowerShell Workflows is no deal-breaker. Workflows were not used much either.

PowerShell Desired State Configuration

Desired State Configuration (DSC) is a work in progress at the time of writing this book. As of now, there are two code bases of DSC resources: LCM for Linux, which is managed by Microsoft's Unix team, and DSC Resources for Windows PowerShell, which was written by the PowerShell team. It could be some time before the DSC code base becomes cross-platform.