System Administrators

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

Common confusion between DNS and web configurations

There is always confusion about what DNS does and what it doesn’t do. In particular, I see constant reference to DNS functions mixed up with web server functions, and vice-versa. Hopefully this post clarifies things a bit to separate what DNS does and what web servers handle.
(more…)

ipHouse Dot Logo

Test everything!

A while a go, I wrote down some personal rules to what I should do as an admin. First and foremost, and underlined about six times was this: Test Everything. It seems so simple, but you have to consider, if it’s not tested, and verified, it’s not working. Simple. Oh, it may be working, but it may not be. “May” is not good enough. So when I roll out a new server, I test and test and test. When I make a change, I test it. If I do reboot a server, I watch logs to make sure that the services are working. If the logs don’t show that everything is working, I manually test things.

(more…)

Juniper JunOS Learning Opportunities

If you wanted to learn how to use Juniper networking gear, and especially get some exposure to JunOS, their network OS based on FreeBSD that you need to configure almost all the Juniper devices with, there are many free or reasonable learning options available.

(more…)

Go to Top