Powershell: Discussion: What base cmdlets are expected/needed for OS mgmt?

[SteveL-MSFT]

This came from today's Community Call. Discussion is what cross platform cmdlets do admins need to perform basic mgmt?

• A meta-module published to PSGallery that contains all the individual modules that implement these cmdlets
• Plugin model to allow community to provide support for different distros and their idiosyncrocies
• Some examples as potential candidates: task scheduling, ACL configuration, Get-PendingReboot (perhaps part of a Get-ComputerInfo or Get-OSInfo cmdlet?)

[DarwinJS]

Thinking of stuff that is obviously missing from Linux, but also stuff that should be in Windows or needs serious fixing.

This is cmdlets you would want around for barebones bootstrap automation of Windows or Linux.

• Stop-Computer, Restart-Computer (missing on Linux)
• Scheduler / Cron (Missing on Linux, WAAAY TOOO COMPLEX on Windows)
• Path Management soapbox: *) It's 2018, *) PATH variables are still critical, *) they are easy to screw up on removes, *) easy to overflow on Windows in large environments, *) two source contexts (user, computer) and a final rendered context on windows (process) - it is definitely a task for the uber admin tool PowerShell - but we have nothing endsoapbox. I have template code for Windows for this one.
• reliable editing of INIs and CONFs - INIs have been summarily ignored since Windows 95 came out. But now I am dealing with more and more Linux ports to Windows that either use INIs or CONFs. Since CONFs are harder - might as well handle INIs at the same time. The fact that CONFs are so unstructured is going to be a source of security holes (turning up on audits too) for OpenSSH on Windows.
• cross platform, simple permissions CMDLets - at least supporting linux chmod level of functionalty for both. And Convert-CHMODToPermissions to easy transitions. Set-Permissions -Permissions (Convert-ChmodToPermissions '755') -TargetObject '$env:userprofile.ssh'
• test-rebootpending - use known facilities on each platform. Redhat family command "needs-restarting -r ; echo $?"

The amount of times I have to re-use and bug fix painstakingly maintained personal code libraries for the above is dumbfounding. (which also means I have empathy for how hard some of these problems are)

I would easily call this "fundamental, multi-generational tech debt" - things that should have been there on day one - that aren't there are on year 20 (for both windows and linux)

FYI - I would be fine with two levels of CMDLets for some of this. For example "Set-Permissions" = multiplatform, common, most frequently used file permissions setting. All parameters applicable to both platforms. "Set-AdvancedPermissions" - platform specific functionality. Maybe advanced splits out to "Set-AdvancedWinPermissions" and "Set-AdvancedLinPermissions" - or maybe it is a new breed of CMDLet whose parameters are known and expect to vary widely by platform (NOT parameter sets)? Set-AdvancedPermissions would not need to be in a minimal install and may be best community managed and as script CMDLets. But this could be a useful categorization to get to a set of core common cmdlets - possibly part of powershell and then a relief valve for those wanting the advanced, platform specific features. Or maybe "Set-Platform*" nomenclature such as "Set-PlatformPermissions"

/cc @SteveL-MSFT @joeyaiello @BrucePay

[dragonwolf83]

Or maybe "Set-Platform*" nomenclature such as "Set-PlatformPermissions"

Set-ItemPermissions and make it part of the PowerShell Providers and have FileSystem and Registry Providers implement that cmdlet. ACLs tend to be hierarchal so it seems like a natural fit. Since they don't exist now, you could make them cross-platform without stepping on existing Windows only cmdlets.

[DarwinJS]

@dragonwolf83 - More than what CMDLets are called I was trying to get around multiplaform implementations that try to take in the entirety of a functionality on all platforms.

Doing that would seem to create a lot of discussion around principles and would result in very ugly CMDLets that are an aggregate of all the requirements of all platforms.

I'm saying that we should apply paretos law - that 80% of the value of a cross platform CMDLet might actually come from a natural 20% of functionality that is common across platforms. Then put the extra 80% of differing functionality in platform specific cmdlets that still follow a naming convention that link them to their multi-platform counterparts. Also, if there is no need for platform specific CMDLets because all functionality was general enough - then the platform specific does not need to be built. I wonder if updating the path might fall into this area.

It might get rid of silly design conversations and deliver the pragmatic value of having something in this space. It might also help guide: *) what functionality should be in the most minimal powershell and *) what functionality is maintained as part of the project, versus a community break out - it was pointed out that the community is very valuable in flushing out functionality for all the platform specific nuances of a given bit of functionality, *) allows building of the multiplatform right away without knowing when or whether platform specific would ever be built (agile discovery).

The idea I am espousing could be applied to all multi-platform cmdlets like scheduling tasks, editing the path, editing confs.

[dragonwolf83]

I agree. I was in no way calling for all Linux and Windows functionality to be handled in one cmdlet nor should it always match the platform idioms. We want abstractions that makes sense for the top use cases.

For example, do you really need to know chmod and how it works or do you just need to know that you can get and set read, read/write, modify, and deny permissions. I think adding that to PowerShell Providers makes the most sense. More advanced permissions that get into NTFS and EXT4 differences that can't be mapped could get platform specific cmdlets.

Maybe I spoke too soon though because it is an implementation detail and we really just a need a list of things to create issues on. It was on the mind and wanted to write it down before I forgot.

[DarwinJS]

Ah - so I understand - you are musing whether a core CMDLet should also use "provider" to abstract commonality between elements of the system when a concept (like permissions) applies to more than one area.

Interestingly Linux left almost everything as files in the first place - most especially configuration stores.

More abstract providers (AD, SCCM, IIS) would generally seem to be the realm of non-core CMDLets.

[nyanhp]

To add to this: Service management on Linux as well. I don't know how ALL the distributions handle daemons but the same -Service cmdlets to manage Windows services and Linux daemons would be great. Start/Stop/Get/Restart-Service for Linux daemons would definitely make PowerShell more useful for admins. New-Service will likely be a bit more work.
This will probably spark a debate about systemd and other systems though. Using systemctl/systemd should cover all enterprise distributions if I am not mistaken.

[MathiasMagnus]

@DarwinJS Stop/Restart-Computer +1. A Start-Computer would be nice too exposing WakeOnLAN.

This is my wish-list of enhancing the UX primarily on Linux:

• Expand/Compress-Archive to handle more formats, especially those native to Linux derivates.
• Expand-Archive performance leaves a lot to be desired.
• *-Disk, *-Partition, *-Volume commands be portable via PS Core. Whether they are rewritten or existing WMI code in the Linux kernel is expanded doesn't really matter from the end-user's POV.
• Update-Package is a must. It is the longest standing issue with OneCore.
• APT/YUM/SNAP as package providers for OneCore.
• Test-Connection not dumping native ping output.
• Get-SysLog cmdlets based on @IISResetMe ConvertTo-Object utility.
• NetAdapter and NetworkSwitchManager equivalent functionality that is implementable on Linux. Especially how Ubuntu 18.04 changed the networking config compared to Ubuntu 16.04 so one has to relearn.
• *-RaidArray for wrapping mdadm with PS goodness.
• Setting up firewall reasonably in a cross-plat manner.
• Get/Register/Unregister-UnixUser, Unix group management, assigning users to groups, etc.

But most importantly: DSC Core! I'd be willing to contribute with HPC-specific providers, given that I can author them in PS and not MOF. (Wrapping nvidia-smi, rocm-smi, etc.) But I don't have the capacity to do all of the above to get a base node running configured and automated with PS. Currently I do the same old ad hoc administration but with PS as shell instead of Bash.

[IISResetMe]

Get-SysLog cmdlets based on @IISResetMe ConvertTo-Object utility.

While I appreciate the shout out, I'm inclined to suggest we implement a simple RFC5424-compliant top-down parser rather than building on top of regex for this purpose.

I'd be more than happy to work on a prototype for this

[lygstate]

NetAdapter doesn't work under Win7

[vexx32]

@lygstate I believe the NetAdapter cmdlets are part of Windows 8 and higher, they're tied to features only available in those OSes.