Iristyle

Write-Host "Waiting for containers to exit." -NoNewLine
while ($(docker ps -q)) 
{
    Write-Host "." -NoNewLine
    Start-Sleep 1
}
Write-Host

Write-Host "Stopping Azure Agent"
Stop-Service vstsagent*

Iristyle

# must be run as an admin
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\' -Name DisableAntiSpyware -Value 1
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\' -Name DisableRoutinelyTakingAction -Value 1
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\' -Name ServiceKeepAlive -Value 0

New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender' -Name 'Exclusions' -ErrorAction Ignore
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions' -Name 'Exclusions_Paths' -Value 1
New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions' -Name Paths -ErrorAction Ignore
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions\Paths' -Name 'Complete Drive' -Value 'C:\'

Iristyle

• In DashWare, create a new profile and name it GoPro Hero7 Black
• From the GoPro add, there will already be a number of files in C:\Program Files\GoPro\GoPro Desktop App\telemetrydata\DataProfiles, including the file Hero7BlackGPMF.xml
• Copy the file from the above directory, overwriting the file at C:\Users\Parity\Documents\DashWare\DataProfiles that is created when the new profile is created inside Dashware

NOTE: There is also a folder at C:\Program Files\DashWare\DataTool\DataProfiles which is irrelevant

More info at:

Iristyle

• Tranmission OpenVPN has a funny setup - requires a TUN.sh to be setup to enable the VPN tunnel
• If ports become unmappable in the silly Docker UI on Synology, refer to this note about /user/local/etc/services.d files - https://forum.synology.com/enu/viewtopic.php?t=86531#p326803

Iristyle

function Get-DockerConfigFilePath
{
  $path = "${ENV:ALLUSERSPROFILE}\docker\config\daemon.json"

  # retrieve the path to daemon.json from docker service config, if present
  sc.exe qc docker |
    ? { $_ -match 'BINARY_PATH_NAME\s*:\s*(.*)' } |
    ? { $_ -match '--config-file\s*(.*daemon\.json)' }

  # found BINARY_PATH_NAME which contains --config-file *AND* file exists

Iristyle

Path  : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\PuppetLabs\code
Owner : NT AUTHORITY\SYSTEM
Group : NT AUTHORITY\SYSTEM
Sddl  : O:SYG:SYD:P(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)

Path  : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\PuppetLabs\facter
Owner : NT AUTHORITY\SYSTEM
Group : NT AUTHORITY\SYSTEM

Iristyle

So we have 2 mechanisms that we use to check whether or not we're on Windows.

• Puppet::Util::Platform.windows? - defined in platform.rb - Has no dependencies on any other code, and should never be stubbed / mocked in a test. You'll see this described a bit more at https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/platform.rb#L4-L11 (Original commit from Patrick is at https://github.com/puppetlabs/puppet/commit/ea740f652fb5252569d4adaefd486aa9daf44b63#diff-043b51d1cd12f524007e614baff1119a)
• Puppet.features.microsoft_windows? - defined in feature/base.rb. Generally requires that Puppet itself be initialized, including its feature management code. Set in Puppet by trying to load win32 gems, and stubbed in tests where behavior is normally gated on the check.

In this particular instance, I think we'd prefer to use Puppet::Util::Platform.windows? as I wouldn't expect any cross-platform stubbing to occur in tests.

Iristyle

Get-ScheduledTask | % {
 $props = [ordered]@{
   TaskName = $psitem.TaskName
   # note ErrorAction Ignore needed to prevent conversion problems
   Compatibility = $psitem | Select -ExpandProperty Settings | Select -ExpandProperty Compatibility -ErrorAction Ignore
 }
 New-Object -TypeName PSObject -Property $props
}

Iristyle

While documenting Bundler behavior to make the chart at https://gist.github.com/Iristyle/8a2214a6dd5aa709ba2a1abd32b4eacd, an interesting scenario was uncovered.

The following diff is a result of running the same code a day apart in AppVeyor. All dependencies downloaded / installed are exactly the same, except:

• The "YESTERDAY 2.4 x64" run is against commit https://github.com/puppetlabs/puppetlabs-scheduled_task/commits/0a203bea3249698c0995515f7016ab42615cc049
  • The complete run output is available at https://ci.appveyor.com/project/puppetlabs/puppetlabs-scheduled-task/build/1.1.x.143/job/pfae70sfa1kdv8cg
  • Note that it includes "Fetching json 1.8.6 / Installing json 1.8.6 with native extensions"
  • Also note that as a result, bundle exec ruby -e 'require \"json\"; puts \"bundled json version: #{JSON::VERSION}\"' emits bundled json version: 1.8.6
  • And gem list includes json (default: 2.0.4, 1.8.6)

Iristyle

	Gemfile	gem fetched / native ext built	--path specified	Gemfile.lock	system json	bundled json	gem list	bundle exec gem list	bundle show json
Ruby 2.1 / json 1.8.1	gem 'json', '>= 0'	fetched 1.8.6 built 1.8.6		json (1.8.6)	1.8.6	1.8.6	(1.8.6, default: 1.8.1)	(1.8.6)	C:/Ruby21-x64/lib/ruby/gems/2.1.0/gems/json-1.8.6
Ruby 2.4 / json 2.0.4	gem 'json', '>= 0'	fetched 1.8.6 built 1.8.6		json (1.8.6)	2.0.4	1.8.6	(default: 2.0.4, 1.8.6)	(1.8.6)	C:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/json-1.8.6
Ruby 2.1 /<b