Recovering the root password on a BeagleBone Black

I recently went to use a BeagleBone Black board on which I'd never booted from the eMMC before (that I could recall) and had been instead booting off of a microSD card. To the best of my knowledge, the root password on this board should never, ever have been changed from the default (blank password), but apparently it was. None of the passwords that I had ever used for any of my BeagleBone Blacks was working, which created a problem: I needed to recover the root password to this BeagleBone Black so that I could use it for my projects again. I was in luck. The BeagleBone Black has the tools that I needed to do it. I'm writing this blog post (like many other posts in the blog) so that I can have a reference to come back to if I ever need it in the future.

To recover the root password of a BeagleBone Black, you'll need the following items:

• A 5V, minimum 1 A dedicated power source (you shouldn't really be powering the board off of the micro USB port)
• An SD card (and reader, of course)
• An FTDI USB-to-serial cable for accessing the debug serial port of the BeagleBone Black.

Once you've acquired all of the required items above, perform the following steps:

1. Flash the SD card with an image that you can obtain from BeagleBone.org/GettingStarted.
2. Insert the SD card into the *unpowered* BeagleBone Black.
3. Apply power.
4. The BeagleBone Black should boot from the SD card (assuming that you've flashed the correct image)
5. Connect the FTDI serial cable to the board and your compter, and open your serial client of choice to connect to the board.
6. Hit enter once or twice, and a command prompt should come up, assuming you've used the correct settings:
1. 115200
2. 8N1
7. Log in using root and a blank password (should be the default on the SD card image that you downloaded from the BeagleBoard.org website.)

You're now logged into the image running on the SD card. However, we can't change the root password now because that will only change it for the root user on the SD card image. We need to change it for the permanent image stored on the BeagleBone Black's embedded eMMC flash. Being logged in as you are, perform the following steps to mount the eMMC image and change the password for that image's root user:

1. Mount the eMMC flash:  mount /dev/mmcblk1p2 /media/card
2. Change the root of the file system to be the partition on the eMMC flash which you just mounted: chroot /media/card
3. Change the password of the root user to something you know: passwd root
4. Exit out of the changed root: exit
5. Shutdown the BeagleBone Black : shutdown -h now
6. Disconnect the power from the board
7. Eject the microSD card.
8. Reconnect the power to the board
9. Watch the board boot up, and log in as root. You should be able to log in with the password that you just set.

Implicit rules with Makefile

In my ongoing quest to make my builds less complex and faster, I've been going through my Makefiles and trying to learn as much as possible to simplify it and leverage Make as much as I can. To that end, I discovered something incredibly useful today that I suppose I would have known had I taken the time to read the man page for Make:

make -p

This command will list all of the implicit rules for make, which you can then use to optimize the living crap out of your Makefile.

Installing NTP on an Ubuntu server

NTP is used to synchronized time between machines. You can read the Ubuntu HOWTO here.

Installing a TFTP server using xinetd on Ubuntu

I recently had need to redo an old server that had been running an ancient Gentoo installation for which there was no longer a software upgrade path, so I chose to install Ubuntu on it. Part of the requirements of the server were that it runs a TFTP server for hosting files for configuring embedded devices. I had previously found an article on how to setup TFTP through inetd, but I could find it, so I'm cobbling this tutorial together from various sources.

1. # apt-get install xinetd tftpd
2. Ensure that the following lines are in the /etc/services file:
1. tftp     69/tcp
2. tftp     69/udp
3. Open the /etc/xinetd.d/tftp file (create it if it doesn't exist) and ensure that it contains the following:

   # default: off
   # description: The tftp server serves files using the Trivial File Transfer \
   #    Protocol.  The tftp protocol is often used to boot diskless \
   #    workstations, download configuration files to network-aware printers, \
   #    and to start the installation process for some operating systems.
   service tftp
   {
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = root
       server          = /usr/sbin/in.tftpd
       server_args     = -s /tftpboot
       disable         = no
   }
   

4. # /etc/init.d/xinetd restart

5. Test the server:# tftp localhost

   tftp> get hello.txt
   Received 23 bytes in 0.1 seconds
   tftp> quit 

You should now be good to go. The (abridged) instructions for this were retrieved from this article.

Digging into Raspberry Pi: Part 2

So, further into my quest to build a control system with the Raspberry Pi, I've been looking around at ways to have simple input from the user for a simple system. The first thing that came to my mind was using an Xbox controller to provide input from the user:

• It's simple for the user to use, and given that many people grew up with game consoles, it'll be intuitive and not require retraining the user.
• The Xbox controller plugs into USB and should therefore provide an easy way to integrate a controller for my system.
• The command to download joystick support for the Raspberry Pi was dead simple: 
• sudo apt-get install joystick

The post located here also shows some options for the joystick on the Raspberry Pi. I'll post more information as I learn how to use the library to access the device.

Digging into Raspberry Pi

I've recently purchased several Raspberry Pi boards so that I could use them with the RasPlex distribution to run Plex clients and connect them to my TVs and stream media from a central box in my house. However, I've now realized that with their ability to output to HDMI by default, I can use them as video controllers for projects at work. On my blog I'm going to document my experiences with the Pi, mostly as a list for me to follow if I ever have to recreate my work.

Today, I started off by doing the following :
1. Running NOOBS
2. Installing Raspbian
3. Used 'sudo apt-get install fluxbox' to install the Fluxbox window manager.
4. 'touch ~/.xsession' and 'vi ~/.xsession' and appended 'fluxbox' to the end of the file to start fluxbox when X starts.

Converting a .cer and .pvk to a .pfx file

The Windows SDK comes with a built-in tool for performing this conversion, the details of which you can find here. The command you'll need looks something like the following :

pvk2pfx /pvk MyCert.pvk /pi inputpassword /pfx MyCert.pfx /po outputpassword /spc MyCert.cer

Journey to robust windows services: killing a service that failed during OnStartup and now won't stop (even though Stop() has been called)

I've found that sometimes I don't exactly get my service configuration right the first time, and this can cause a failure when calling OnStartup. As a result, when I call Stop() during the exception handling in OnStartup(), the service gets stuck in the 'Stopping' state in the services manager. Here's a quick command line to help you out with that :

TaskKill /F /FI "Services eq [service name as diplayed in the service's properties]"

This will get your process knocked off so that you can resume debugging and building.

System.ArgumentException: Unable to find the requested .Net Framework Data Provider when using SQLite with MSTest unit tests in Visual Studio 2012

I recently encountered the exception in the post title while migrating solutions from Visual Studio 2010 to Visual Studio 2012. Going back and forth between versions, the problem only occurred for me in Visual Studio 2012, it otherwise did not appear in 2010. I ran across this post on StackOverflow about another developer in a similar circumstance, but I didn't want to depend on whatever machine I was using having the SQLite Db Provider installed in the GAC, so I chose a different route: I added [DeploymentItem]s for each of SQLite.Interop.dll, System.Data.SQLite.dll and System.Data.SQLite.Linq.dll to the top of each of my test suites that require them.  It's perhaps not an ideal solution, but it does seem to be the most pragmatic one for my circumstances.

Journey to robust web services: Fixing an error 404.3 message in IIS 7.0 / 8.0

I've recently had to go out of town, and only had my personal laptop to take with me. I usually develop in a Windows 7 environment with IIS 7.0 / IIS Express 7.5, but my laptop is Windows 8, so of course I have to go through the process of setting up my development environment all over again. One of the common errors I see when setting up a new environment is error 404.3: Not found. I run into it over and over again and when I fix it, it seems like such a trivial thing and I never remember to write down the fix to reduce my setup time in the future. Today that changes. The problem can be caused by a couple of things:
1) You don't have the application setup in IIS. You need to setup the application in IIS, *and* you need to point it to your web project directory.
2) You don't have all the requisite components installed in IIS. In order to properly install WCF, you must have IIS installed, you must have ASP.NET installed, and you must have WCF registered. Up to Windows 7 / .NET 4.0, this means you must have, at some point, run aspnet_regiis.exe -ir. On Windows 8, this means you must have installed ASP.NET 3.5 / 4.5, and installed HTTP activation for each (as well as corresponding activations for any other protocols such as net.tcp.

Journey to robust Windows Services: Overriding the default web site when deploying your applications from the command line

I recently ran into a problem where I wanted to deploy a new application to the default web site on an old IIS 6 instance via MSDeploy on the command line from my build machine. Unfortunately, it decided to deploy the application in a folder immediately underneath the default web site, rather than as the default website itself. This post on the IIS forums provided the solution.

Journey to robust Windows Services: NHibernate throws with System.InvalidOperationException: Unable to generate a temporary class

Recently I've been trying to deploy a new web application to an old machine running Windows Server 2003 (not by choice). When I would start the application, NHibernate would thrown in its class constructor with a message along the lines of :

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\wz58eig4.0.cs' could not be found
error CS2008: No inputs specified

The problem was caused by the fact that the user under which I was running the application didn't have access to the 'C:\Window\Temp' folder where the temporary folder was being created. The solution was simple: update the security settings of that folder to allow Read and List for the Users group. The idea was given to me by answers to this question on Stack Overflow.

How to fix the ugly ass Ubuntu boot splash OR Damn, Ubuntu, you ugly

TL;WR: http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml

If you've had Ubuntu for a while and you've got an nVidia video card, chances are you've got the ugly ass default boot screen. Fortunately, you can fix this. You just need to follow the instructions above. I hope you're comfortable with the command line.

Changing the password complexity requirements on Windows Server

To change the password complexity requirements on Windows Server (2008 at least) (for whatever reason), do the following :

Start -> Run -> gpedit.msc -> Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

Then in the right-hand policy pane, set 'Password must meet complexity requirements' to 'Disabled' (right-click -> Properties)

Journey to robust windows services: Service could not be installed. Verify that you have sufficient privileges to install system services

This is an annoying and almost entirely useless error. It can be caused by any number of things. However, in my case today, it was caused by the fact that the EventLog Source hadn't been created when I tried to install my Windows Service using the WiX installer that I had developed (which it turned out wasn't quite complete). Fortunately, WiX (at least as of 3.5) has built-in support for creating Windows Event Log sources as part of the installation process. Fortunately, I was able to rely on this article on stackoverflow.com to guide me through the process. The gist of the article:

1. Add the "http://schemas.microsoft.com/wix/UtilExtension" namespace to your .wxs file root XML element
2. Add a util:EventSource Log="Application" Name="MyServiceLogSourceName" EventMessageFile="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" element to each component which requires an Event Log source
3. Problem solved

Journey to robust windows services: debugging your WiX custom actions

I've recently had some trouble getting WiX custom actions to work, and after searching around for a while, I found this article. It gives the reader two options for how to debug WiX custom actions, but I had to use both in combination to get it to work. I'll repeat the steps here, just in case the link goes stale:

1. Follow all the necessary steps to create a WiX setup project, along with a separate Custom Action project (available as a project type in the New Project dialog in Visual Studio 2010+ with WiX 3.7)
2. After you've created your custom action method and gotten the project building, add System.Diagnostics.Debugger.Launch(); at the beginning of your custom action method. This will kick the custom action into the debugger so that you can debug it (assuming you've got the wixpdb in the same directory from which you launched the installer).
3. Go to Control Panel -> System -> Advanced System Settings -> Advanced (tab) -> Environment Settings (button) -> System Variables (group) -> New .... (button) 
4. In the dialog that comes up, create a new variable called 'MMsiBreak' (without the quotes) and give it the value of your custom action method (e.g. MyCustomActionMethod)
5. Now run the debug version of your installer and it should get kicked right into your method and allow you to debug your custom action.

Journey to robust windows services: creating custom actions for your WiX installers

I've lately been trying to update my WiX installers to perform custom actions so that I can do some security configuration of my applications after they're installed. I got started with this article on CodeProject, but it was missing some information. Apparently, in addition to creating the separate project for the CustomAction DLL, you need to include as part of that assembly a CustomAction.config file with the following contents:

xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v2.0" />
        <supportedRuntime version="v3.5" />
        <supportedRuntime version="v4.0" />
    </startup>
</configuration>

But what really got the thing working was targeting the CustomAction DLL to .NET framework v3.5, rather than 4.0 because I was getting some bad image format exceptions when trying to run it. Thankfully I found the MSDN article on enabling MSI logging. These two articles on stackoverflow.com also really helped out.

Journey to robust web services: installing a WCF 4.0 application on IIS 6.0

Due to budget and other constraints, I'm unable to get my hands on the latest and greatest software for running a WCF application I've been working on, so I'm forced to use what my company's got: Windows Server 2003 and IIS 6.0. Suffice it to say that working with these old bits of software are less than ideal. However, I'm stuck with it. So, moving forward, here's some of the things I found while working on the application:

1. There's no easy way to set certain items in the registry for the Network Service user. (Sorry, for various reasons, I can't elaborate on that statement.)
2. Due to (1), I've decided to run my application as a custom normal (non-Administrator) user that I've created. However in order to use this user with IIS and its applications, certain steps must be taken.

Using a custom user to run an IIS 6.0 application

The following are pre-requisites in order to be able to use a custom user to run an IIS 6.0 application:

• The user must have already been created and should have absolutely the least number of privileges possible.
• Thanks to this question on Stack Overflow, the following must also have the following:
• The "Log on as a service" right (Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service)
• "Access this computer from the network" (similar location as in the step above)
• "Deny logon locally"
• "Log on as a batch job"
•  "Read & Execute", "List Folder Contents" and "Read" access to the file system that underpins the web site/application
• Thanks to this troubleshooting article on MSDN, I also found out that the user must be part of the "IIS_WPG" group.

I now have other problems to worry about with this application, but at least now I know that they're not related to how I'm running the application in IIS.

Journey to robust web services: apparently we shouldn't use 'using'

I recently stumbled across an article stating why we shouldn't use the 'using' keyword with WCF services, and I found it rather interesting. I'd have to re-read it, and re-evaluate it, before I use it but you can read the blog post on the original site.

Journey to robust webservices: kickstarting use of certificates phase II: using certificates for client authentication

There are a number of means of authenticating users, and one of the most secure is via a certificate. This article on CodeProject provides a start. Unfortunately, the article doesn't really mention a few things:

1. Depending on how you ran the tools, you may have inadvertently run the commands it gives you as an administrator. I ran them in a console that I already had open that was running as administrator, so they were installed as administrator, and I also happened to have been running in Visual Studio as an administrator at the time, so everything happily worked. Then when I rebooted my machine this morning and was running as a normal user, nothing worked, and I wasted over an hour trying to figure out why. That was why. Regardless of how you generated and installed the keys, you should go and explicitly grant permissions on the key to the users you want to have access to them. On the Microsoft website, there is a bundle of WCF samples (which you can find here). Included in the samples is a tool called FindPrivateKey. Download the samples, compile the program, and use it to find the key that you just generated. You'll need a command similar to the following : "C:\Samples\WCFWFCardSpace\WCF\Tools\FindPrivateKey\CS\bin\FindPrivateKey.exe My LocalMachine -t "28 ce e3 2c 7e 05 3a 97 a0 b4 92 fd d5 b0 f9 de 0e 4c 2e 4b"" where the value in quotes is the thumbprint of the non-signing (client) key you generated in the instructions from the article. Once it spits out the location of the file, you'll need to go and alter its permissions to allow whatever user your server / client application is running under access to the file.
2. Depending on the binding you're using with WCF on the server side, you may need to have a certificate with full chain trust on the IIS server (or other?) in order to use the binding (*cough* basicHttpBinding and any other transport-only security bindings *cough*). With that in mind, after you've generated the certificates in the article, while you're in the certificate manager MMC snap-in, you'll also need to copy (not move) the IIS developer certificate used in IIS to the "Trusted Root Certification Authorities" store.