Month / April 2017

by Aaron

Quick demo of Go’s context.WithTimeout

To better understand Go’s context withTimeout functionality (and as a reference for myself), I’ve created this small self-contained demo. I didn’t find the published documentation’s example to be clear enough. The interesting part, coming from other programming languages and platforms, was that the WithTimeout function only was a signal that something happened. It doesn’t do anything when there’s a time out (like abort a goroutine or anything dramatic like that).

The essential pieces:

  1. Call WithTimeout passing the Background() context and specify the timeout (I’ve specified  3.2 seconds)
  2. Be a good citizen and defer the cancellation (to be sure that it’s called) and defer close the channel
  3. Start the go routine which waits for the Done channel
  4. When the Done is signaled, display the current time in seconds and what caused the signal
  5. The main app is waiting for the goroutine to end, so signal that.
  6. In the main function, the code sleeps and wakes emitting some time stamps to the console
  7. Depending on whether cancel is called, the goroutine signal may be one of two things.
    1. If cancel is not called prior to the second sleep in the code, the ctx.Err() returns 
      <-ctx.Done():  context deadline exceeded
    2. If cancel however is called, the ctx.Err() returns: 
      <-ctx.Done():  context canceled
  8. Then, the goroutine uses the channel to signal completion (wait<-true).

You can experiment with this sample here.

With cancel called (the line cancel() not commented out):

first sleep completed,  02.00
Timeout: 02.00
in <-ctx.Done():  context canceled
after second sleep done,  04.00

And, with // cancel() commented out:

first sleep completed,  02.00
Timeout: 03.20
in <-ctx.Done():  context deadline exceeded
after second sleep done,  04.00

Hopefully this helps someone besides me.

by Aaron

How to sign Powershell scripts with self-signed certificates in Windows 10

I wanted to allow all signed Powershell scripts to run on a PC in our house on Windows 10. To do that, I needed a code-signing certificate.

Unfortunately, the days of easily obtaining a free code signing certificate seem to have ended. Have no fear! You can create a self-signed certificate if you don’t expect to use the certificate anywhere but on the PC where the certificate was created.

First, I enabled Powershell scripts to run. From an administrative Powershell command prompt: 

> Set-ExecutionPolicy AllSigned

Acknowledge the warning and you’re ready to execute only signed scripts.

But, if you create your own script, you’ll need to sign it. To create the necessary code-signing certificate, you’ll again use Powershell. From an administrative Powershell command prompt: 

PS C:\Dev>New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\ -Type CodeSigningCert -Subject "CN=PowershellScripts" -NotAfter (Get-Date).AddYears(10)

You can change the Common Name (CN) to anything you’d like, or adjust the expiration date (using -NotAfter). I’ve got the expiration as 10 years from today.

Once you’ve got the code signing certificate created as shown above, you’ll need to move the certificate to the Trusted Root Certification Authorities. If you don’t, when you sign the powershell script, it still won’t be allowed to run (and the act of signing will produce an UnknownError).

Start the certificate manager (press Windows key, type cert, and select “Manage computer certificates“, or hit Windows+R, then type: “certmgr.msc“).

Drag Certificate Into Trusted Root Certification Authorities

Expand Trusted Root Certification Authorities first, then expand Personal > Certificates and select the PowershellScripts Code Signing certificate and then drag it into the Trusted Certificates list as shown above (or you can right click, cut, and then paste it as well).

Now that you’ve got a trusted code signing cetificate, you can sign your Powershell scripts.

If you’ve only got one code signing certificate (which I presume you do otherwise you wouldn’t have needed a new one), from an administrative Powershell command prompt first switch directories to where the script you want to sign is located, then do these commands: 

> $cert = (Get-ChildItem Cert:\LocalMachine\my -CodeSigningCert)[0]
> Set-AuthenticodeSignature .\reconnect-iscsi-targets.ps1 $cert

You should then see a table with the SignerCertificate, Status, and the Path. If everything went well, the Status should be Valid.

Here’s something interesting you can do with iSCSI targets and PowerShell using a signed PowerShell script.

 

 

by Aaron

Automatic Reconnection of iSCSI Targets in Windows 10 using PowerShell

When my highly recommended Synology Disk Station reboots for a required update (I’ve got it set to automatically reboot), a shared Windows 10 PC in our house cannot always successfully reconnect to the iSCSI targets without manual intervention. Unfortunately, I haven’t always noticed which has led to several features of Windows not functioning the way I want (I have mapped the iSCSI drives/disks via Windows and made them into network shares for the other PCs/laptops in our house — this way I can use Windows bitlocker encryption on the iSCSI drive contents).

To make the connection more automatic, I created a simple one line PowerShell script that periodically attempts to connect to any disconnected iSCSI targets using the Windows Task Scheduler.

I saved this into a script file called reconnect-iscsi-targets.ps1: 

Get-IscsiTarget | where ($_.isConnected -eq $false) | Connect-IscsiTarget

Then, in the Task Scheduler, I created a new task set to run every 10 minutes daily. The script just gets all iSCSI targets, filters only those that aren’t connected, and then passes the results to the connection cmdlet.

For the action, I selected “Start a program” for program/script, I entered: “powershell.exe”, and then added the arguments “-File” and the full path to the file name, like: 

-File c:\Users\aaron\Documents\reconnect-iscsi-targets.ps1

If there are spaces in the path to the PowerShell file, be sure to add quotes around the full path and file name.

You shouldn’t need the start in option set (leave it empty if you’d like).

On the General tab of the task, make sure you’ve set the “Run whether user is logged on or not” option and “Run with highest privileges.”

Next up — how to quickly create a Self-Signed Code-Signing certificate. And, how to actually allow scripts to run!