stephanevg / hostsfilemanagement Goto Github PK

depends on #18

Issue is part of: #6
Generate documentation based on comment based help using PlattyPS.
The documents will then be made available through Github Wiki.

Technical details:

1. Every cmdlet must have a .md file
2. Naming convention: FunctionName.md
3. Files should be located in /Docs/ of this repository.

I got this:

>  Get-HFMHostsfile | Save-HFMHostFile -BackupFolder C:\admin\backup\
Get-ChildItem : Cannot find path 'C:\admin\backup\' because it does not exist.
At C:\Users\taavast3\OneDrive\Repo\Projects\OpenSource\Class.HostsManagement\HostsFileManagement\Classes\public\HostsFile.ps1:131 char:22
+ ... ckupItems = Get-ChildItem -Path $BackupFolder.FullName -Filter "*$($T ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\admin\backup\:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

WARNING: Could not find a part of the path 'C:\admin\backup\20181118-105624_U279610_Hosts.bak'.

Would make sense to force the creation of the full path if it doesn't exists.

Originally, this repository was built to work with Classes only.
once #4 is resolved, we will need to update the help files. this will result in changing the following things:

• Readme.md
• Update / rewrite the About
• Use PlatyPS to generate Help documents of comment based help from different functions
• Create Wiki Page and link mardown files generated with plattyPS

Perhaps we can already start to implement some of these things (like the automation using PlatyPS, and creating the WikiPage).

If stumbled on an invalid IP Address do you want it to stop or continue?
This was one of quirks Tobias talked about... 😁

Here's something to think about:

Class parseIPAddress{
   $IPAddress

   parseIPAddress($ipv4){
      $this.IPAddress = ($ipv4 -as [IPAddress]).IPAddressToString
   }
}

[parseIPAddress]::new('38.25.63.10')
[parseIPAddress]::new('380.25.63.10')

Class parseIPAddressThrow{
   $IPAddress

   parseIPAddressThrow($ipv4){
      $this.IPAddress = ([IPAddress]$ipv4).IPAddressToString
   }
}

[parseIPAddressThrow]::new('38.25.63.10')
[parseIPAddressThrow]::new('380.25.63.10')

there are 4 failing tests (out of 63):

Looking at the result. the hostname would be rhino and the fqdn rhino.acme.com. Did you want to omit the # in the comment?

Isolating discussion from #4

@LxLeChat It make sense to me to be able to remove an entry. I think we should offer the possibility to to the end user to do it in several ways:

1. via [HostsEntry] Just like in your example from #4 It would make sense, to be able to remove an single or an array of Hostsentry objects from a given Hostsfile
2. Via String: It would be good to have have the user to write a string, which could be a FQDN or an IP address. In the background, we could handle this using a regex, and according to the type, we will fetch the corresponding entry, and if present, remove it. Perrhaps, this one should also be an array.

These are the cases I could think of

Remove-HFMHostsFileEntry -Entry  "192.168.1.34"
Remove-HFMHostsFileEntry -Entry  "Server01"

# Your example:
$a = Get-HFMHostsFile
$b = Get-HFMHostsFileContent
Remove-HFHMHostsFileEntry -Entry $b[0..5] #remove 6 first entries # Parameters should be singular.

I think this could be managed simply using a switch -Regex
where we will identify if it is IP, FQDN, netbiosName
Alos check if of Type [Entrytype]

`
#PseudoCode:

if($Entry.GetType().FullName -eq "EntryType"){
#Do work
}Else{

Switch($Entry){
     '^\d' {#Ip}
     '^\w' {fqdn or netbios}
    'default' {Throw 'not supported'}
  }

}

`

Somethig like that

Implement Appvyeor CI

This module is classes based. With experience, I noticed that end users don't really embrace using classes that much, and are more willing to work with functions / cmdlets, thing they are used too since a few years already.

In order to make this module easier for the public embrace, and to abstract the complexity for the end users, and add an encapsulation layer, I would like to add the following cmdlets / functions (See below)

Technical implementation details:

Each cmdlet should have the following:

• Comment based help
• At least 2 examples.
• A unit test.

Please fork, and create an individual branch per function.

Get-HFMHostsFile

• Get-HFMHostsfile -> Get the Hostsfilecontent (Remotley or locally).
• Get-HFMHostsfile Examples
• Get-HFMHostsfile Pester Tests

Get-HFMHostsFileContent

• Get-HFMHostsFileContent -> Reads the HostsFileContent Received from Get-HFMHostsFile
• Get-HFMHostsFileContent Examples
• Get-HFMHostsFileContent Pester Tests

New-HFMHostsFileEntry

• New-HFMHostsFileEntry -> Creates an HostFileEntry object (Of type [HostsEntry])
  • Parameters:
    -Type (Must be of type [HostsEntryType])
• New-HFMHostsFileEntry Examples
• New-HFMHostsFileEntry PesterTests

Set-HFMHostsFileEntry

• Set-HFMHostsFileEntry
• Set-HFMHostsFileEntry Examples
• Set-HFMHostsFileEntry Pester Tests

Save-HFMHostFileEntry

• Save-HFMHostFileEntry
• Save-HFMHostFileEntry Examples
• Save-HFMHostFileEntryPester Tests

New-HFMHostsFileBackup

• New-HFMHostsFileBackup
• New-HFMHostsFileBackup Examples
• New-HFMHostsFileBackup Tests

Remove-HFHMHostsFileEntry

• Remove-HFHMHostsFileEntry
• Remove-HFHMHostsFileEntry Examples
• Remove-HFHMHostsFileEntry Tests