PowerShell has been the default configuration tool for Windows since it’s release in 2006, but since being open-sourced in 2016, administrators can use it for Linux and macOS as well. However, there are some significant differences in how to manage a Windows operating system over a Linux operating system.
For example, while Windows is an API-driven operating system, relying on specific endpoints that are built into the operating system to make changes to the system, Linux is a file-driven operating system. That means that changes to users, services, disk mounts, and networking are done by managing file contents of specific configuration files.
Bash has traditionally been the tool that Linux administrators use to manage those files, but now Linux administrators have another tool they can use to manage those files: PowerShell. There are too many configuration files to cover in one article, but these techniques to manipulate file contents, so they can be used across any configuration files on the operating system. Here are a few of the more critical files:
This file is where information is kept about users that are logging into the system. These entries are comma-delimited, but a sample entry looks something like this:
This might not make a lot of sense at first, but here is a little look at how this line is formatted:
<User Name>:<Password>:<User ID>:<Group ID>:<Comment>:<User Home Directory>:<Default Shell>
Since this file uses a colon delimiter, you can use PowerShell to parse the items in it like you would with any string. This is a pretty common format for Linux configuration files. You’ll see other files covered in this post that have this format.
This format means that you can use the
-Tail switches to get the first and last entries on the list respectively, as shown in the screenshot below.
The Linux commands you would use to interact with this file are
userdel and unfortunately at the time of writing, PowerShell version 7 doesn’t have an equivalent cmdlet or the ability to run commands as sudo. That means that until those capabilities are added into PowerShell version 7, you have to either run the Linux commands by themselves or run the PowerShell
Add-Content cmdlet with sudo privileges as shown in the screenshot below. It’s not ideal, but it works.
This file has the groups on the system and which users are members of those groups. Similarly to the /etc/passwd file, /etc/group is colon-delimited, but the syntax is a little different. A typical entry in this file looks like
sys:x:3:user1 but when you break it down by item, here is how that line looks in a little more of a human-readable way:
<Group Name>:<Password>:<Group ID>:<Group Members>
Since you still don’t have the ability to run PowerShell as sudo or native cmdlets to work with Linux groups, you will still have to find another way to run this command. Fortunately, the PowerShell console also allows for running Linux commands natively, which means that if you are already familiar with the Linux commands, you can run them alongside your PowerShell commands In the screenshot below, the
usermod command adds the
user1 user to the
In Linux, the bash profile is used to do anything from set environment variables, customize the appearance of the Linux shell, or start background processes. PowerShell has a similar concept with the PowerShell profile, which has a reserved variable
$profile to reference it. Both of these files are a list of commands that run when either the bash or PowerShell shells are started, and they only pertain to that shell.
These profiles are unique for each user and located under each user’s home directory. For example, for a user named user1, the bash profile would be under /home/user1/.bash_profile while the PowerShell profile would be under /home/user1/.config/powershell/Microsoft.PowerShell_profile.ps1. Since these are text files, commands can be added to the end with either the
>> operator or the
This can get really confusing when working with them because, in bash, the reserved variable to change the profile is PS1, which is also the default extension for PowerShell scripts. What’s more confusing is that in bash, the items in the prompt itself are referred to by
/u is user,
/h is hostname,
/w is the working directory, and so on. This is how that might look in a bash profile:
# Bash Profile # Set an environment variable export NEW_PATH=/this/is/a/path # Change foreground color of the prompt to Blue PS1="\[\033[34m\]\u@\h\w\$" # Write a message echo "Bash profiles are so useful!"
Because PowerShell is meant to be more human-readable than bash, the syntax to do the same things is a little more familiar:
# PowerShell Profile # Set an environment variable $env:NEW_PATH=/this/is/a/path # Change foreground color of the prompt to Blue $shell.ForegroundColor = “Blue” # Write a message Write-Host "PowerShell profiles are so useful!"
The best practice for these files is to either rely on one or the other, but both are important pieces of their respective shells, and make for powerful tools when used properly.
This might not seem like a lot of options for Linux administration from a purely PowerShell perspective, but there is a silver lining: Modules. Modules are a core part of PowerShell, they add in capabilities that would be much harder or impossible without them.
The biggest strength of PowerShell is that PowerShell is very extensible. The PowerShell Gallery has a module for almost every need, including Linux administration. For example, the LinuxPowershellTools module adds three new cmdlets to your system:
Remove-User. This module returns the user profile mentioned earlier, but now as a PowerShell object.
PowerShell 7 still doesn’t have all the Linux administration capabilities that you may want from it yet, but it is also still in preview and Microsoft and the community is invested in making sure they are on the way. In the meantime, there are community modules and workarounds to make sure that no matter how you need to manage your Linux system, you still have the ability to do that from PowerShell.