Posts tagged programming

ipHouse Dot Logo

Local PHP configuration

PHP 5.3 added a useful feature, per-directory .ini files. You can enter PHP configuration directives into a text file named “.user.ini”, upload it to your htdocs directory or any other directory of your website, and that configuration will be used for any PHP scripts in that directory or below.

For example, you may not want to display page errors to visitors of your website, but want to see them for anything in the /development/ sub-directory where you’re working on new things. You might create a .user.ini file in that sub-directory containing

error_reporting = E_ALL
display_errors = On
display_startup_errors = On

Or perhaps you have a sub-directory of remote procedure calls which are invoked from a webpage via AJAX and always return JSON data. You could simplify them by creating a .user.ini file in that subdirectory containing

default_mimetype = “application/json”
display_errors = Off

What can’t you do? You can’t use any configuration directives marked PHP_INI_SYSTEM, which cover fundamental and security-related PHP configuration are reserved for the root php.ini file.

ipHouse Dot Logo

Adding Exchange 2010 mailboxes from text file with PowerShell

I wrote before about adding Exchange 2010 mailboxes with PowerShell and AWK. I was having some trouble with the syntax of importing from a .csv or tab-delimited file so I punted and used awk on my workstation and got the work done.

That workflow is not ideal. I’d rather do it all in PowerShell. I got some great help from the fine folks over at /r/powershell and Don Jones’s PowerShell books and videos.

Here is a better way:

  • Use the Import-Csv cmdlet to import the data as an array objects with text properties, for each column.
  • Add and adjust the properties we need and their values.
  • Pass the whole array to New-Mailbox, which will do the right thing, as long as all the parameter names match the object properties.

If I exported the data as .csv, with properly named column headers, this would get even easier, but I will give PowerShell the same data I gave awk for the sake of parity. So let’s say I have no control over the format the data arrives in and it comes space-delimited like this:

Alice Adams aadams aadams@corp.domain.com Password1
Bob Baker bbaker bbaker@corp.domain.com Password2
Charlie Carter ccarter ccarter@corp.domain.com Password3
Dan Davis ddavis ddavis@corp.domain.com Password4
Ed Evans eevans eevans@corp.domain.com Password5
Frank Foster ffoster ffoster@corp.domain.com Password6

Here is how to use PowerShell to add these users using the data from this file.

To use a space for the field delimiter, we’ll use -Delimiter ‘ ‘. This file does not have a header row. Import-Csv imports as key-value pairs, so each column needs a name.  By default, it uses the top row for that, but that would not be the right thing to do here, since the top row is data.  So we can either put a header row on the file, or define alternate column names with a -Header argument.  Here is the command import my users.txt file as an array of objects, $users:

PS> $users = Import-Csv -Delimiter ' ' -path .\users.txt -Header FirstName, LastName, SamAccountName, UserPrincipalName, plaintextpass

This loads the data from the file into an array of objects $users.  Each element of $users has properties as defined in the header with values from the corresponding row.  Here’s the first element in $users:

PS> $users[0]

FirstName         : Alice
LastName          : Adams
SamAccountName    : aadams
UserPrincipalName : aadams@corp.domain.com
plaintextpass     : Password1

Next, we’ll add the “Name” property, which is a string in the form “FirstName LastName”

PS> $users = $users | Select-Object -Property *, @{name='Name';expression={$_.FirstName + ' ' + $_.LastName}}

The property is appended to the end of the list, but that’s fine, since Add-Mailbox accepts these arguments in any order. Here’s how the first object looks now.

PS> $users[0]

FirstName         : Alice
LastName          : Adams
SamAccountName    : aadams
UserPrincipalName : aadams@corp.domain.com
plaintextpass     : Password1
Name              : Alice Adams

Add-Mailbox wants the password as a system.securestring, and won’t accept a plain string at all. Items of type System.SecureString is stored in memory encrypted.  We’re defeating the security benefits of that behavior by handling the passwords as plaintext elsewhere in the script and in the data file. For exactly that reason, ConvertToSecureString will complain if we use it to accept plain text with -AsPlainText, but it will do it anyway if we use -Force.  The whole thing goes like this.

PS> $users = $users | Select-Object -Property *, @{name='Password';expression={(ConvertTo-SecureString -AsPlainText -Force -String "$_.plaintextpass")}}

Now we have the password stored as a SecureString.  Trying to print the password only prints “System.Security.SecureString” and not the actual contents, but it is in there.

PS> $users[0]

FirstName         : Alice
LastName          : Adams
SamAccountName    : aadams
UserPrincipalName : aadams@corp.domain.com
plaintextpass     : Password1
Name              : Alice Adams
Password          : System.Security.SecureString

Now let’s get rid of that plaintext password.  Strictly, this step is not necessary. Since “plaintextpass” does not match any of the arguments that Add-Mailbox accepts, it will be discarded.  But since we need to encrypt the password as a SecureString to pass it anyway, why pass it as plaintext as well.  So we strip the property out like this:

PS> $users = $users | Select-Object -Property * -ExcludeProperty plaintextpass

And finally, our objects look like this:

PS> $users[0]

FirstName         : Alice
LastName          : Adams
SamAccountName    : aadams
UserPrincipalName : aadams@corp.domain.com
Name              : Alice Adams
Password          : System.Security.SecureString

It is not an accident that these are exactly the arguments that Add-Mailbox wants.  This is the fun part.

PS> $users | Add-Mailbox

That’s it. The contents of the properties of each object in $users are passed to the corresponding arguments Add-Mailbox accepts.  Add-Mailbox takes those arguments and creates six new users.

And of course, since this is powershell, all of this can be done in one big pipeline if readability is not your thing.  That would look like this:

PS> Import-Csv -Delimiter ' ' -path .\users.txt -Header FirstName, LastName, SamAccountName, UserPrincipalName, plaintextpass | Select-Object -Property *, @{name='Name';expression={$_.FirstName + ' ' + $_.LastName}}, @{name='Password';expression={(ConvertTo-SecureString -AsPlainText -Force -String "$_.plaintextpass")}} | Select-Object -Property * -ExcludeProperty plaintextpass | Add-Mailbox
ipHouse Dot Logo

Into the vCloud API

We’ve been working on building a proper vmForge account creation and management site, so for the last couple of weeks I’ve worked a lot with the vCloud API. It’s a RESTful system, which means everything’s done by getting XML from and posting XML to a web server. It’s perhaps not the worst API I’ve ever worked with, but its tedious to work through. Even more so because their parser is insanely pedantic, to the point of requiring elements in a specific order. So that’s a point in PHP’s favor, that it maintains key order in associated arrays.

(more…)

This Old Code

Although revisiting and updating existing code isn’t necessarily fun or an obviously lucrative way to spend your limited time, it can certainly pay dividends. I know my personal knowledge, skill, and experience have changed over the years, and code which seemed perfectly good six years ago can be painful to read now. Perhaps you’ve gained new appreciation for readable code in general. Or limiting how deeply you nest your conditional blocks, or avoiding incomprehensible loops six pages long. Regardless, code which is easy to read and understand is easy to maintain, and has fewer bugs.

Sometimes, its not your skill which was necessarily at fault, but your environment. Perhaps the code has simply outgrown the original project scope, and become littered with references and obscure exceptions which were bolted on later. Reconsidering and refactoring the code is a necessary step to regaining control of the chaos. Or the original project simply didn’t afford enough time for development, and you had to leverage existing code which didn’t quite fit. Our own ipMom account interface started life as PostfixAdmin, which was quick and easy to put into production, though you wouldn’t be able to tell anymore.

Finally, programming languages themselves change. New libraries are added, and new functions which can make your code leaner and cleaner overall. With relatively new programming languages, its easy to have code which predates any developed or widely-used best practices for the language. Bringing the code up to spec now will make it easier for you, and easier for others, to maintain it in the future.

Go to Top