All posts by Jon

First steps for Ubuntu on Beaglebone!

Logo_UbuntuYou probably ended up here by following my brief tutorial on flashing the BeagleBone Black with Ubuntu 14.04 Linux.  If not, well, that’s ok too.

So now that you have a palm-sized computer running the latest Ubuntu release for ARM, what do you do?  Well, lots of things – this post is going to focus purely on the OS-level “things to do” rather than address things you might try with the BBB hardware itself.

The first thing you’re going to want to do is add a new user because you’re probably going to put this thing on a network with internet access and having the default “ubuntu” user enabled is not ideal.   So, simply type the bold text below and you’ll be adding a user named “jon”.

 * Documentation:  https://help.ubuntu.com/
Last login: Fri Jul 25 00:37:28 2014 from hpsjkensy01.asus
ubuntu@BeagleAPP1:~$ sudo adduser jon
[sudo] password for ubuntu:
Adding user `jon’ …
Adding new group `jon’ (1001) …
Adding new user `jon’ (1001) with group `jon’ …
Creating home directory `/home/jon’ …
Copying files from `/etc/skel’ …
Enter new UNIX password:  ************
Retype new UNIX password:  *************
passwd: password updated successfully
Changing the user information for jon
Enter the new value, or press ENTER for the default
Full Name []: Jon
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y

 

Note that I masked the password input with *’s.  Great!  You’ve successfully added a new user!  Now what?  Now we add the user to the sudo group else it will only function as a standard user and not be able to modify system files or install packages.  There are many ways to do this but I like this simple one-liner:

ubuntu@BeagleAPP1:~$ sudo usermod -aG sudo jon

Done.  Now “jon” can perform sudo calls.  Notice that we did -aG in the command above.  That is important so that the user has the sudo group appended to them, else they’ll only be sudo… which is ok usually, but it’s poor form.

So we’ve got a new user with a password and they can perform sudo calls.  What next?  Simple – now we remove the default “ubuntu” user to remove any potential vulnerability.  Some people will prefer to lock the user out rather than delete them – that’s fine but I won’t be detailing that.  Here is how you remove a user and their home directory:

jon@BeagleAPP1:~$ sudo userdel -r ubuntu

That was easy.  Did you notice that the above line said “jon@Beagle…”?  Yep, we logged into “jon” in order to delete “ubuntu”.  So now we update the sources and OS:

jon@BeagleAPP1:~$ sudo apt-get update
0% [Connecting to ports.ubuntu.com] [Connecting to repos.rcn-ee.net]

Uh-oh – we’ve called apt-get update but we sit at 0% connecting and nothing happens.  Not to worry!  This is expected (so long as you have a network cable plugged in, etc.).  What’s going on here is that we just setup the device, it’s going out to “ports.ubuntu.com” but it has no idea how to get there because we have no DNS servers defined.  But shouldn’t it work out of the box?  Yes, it should.  Let’s see what’s going on…

First we check out /etc/resolv.conf to see that DNS is setup as it should be:

jon@BeagleAPP1:~$ sudo cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
domain localdomain
search localdomain
nameserver 192.168.1.1

Hrm.  That looks fine – it shows our router, or expected router, as a DNS provider.  Well, let’s see what’s going on then with our IP information:

jon@BeagleAPP1:~$ ifconfig eth0| grep ‘inet addr:’
inet addr:192.168.50.41  Bcast:192.168.50.255  Mask:255.255.255.0

Ahhh… see the problem?  Our eth0 interface is configured or assigned 192.168.50.41 but our DNS entry in resolv.conf is set for 192.168.1.1!  I will assume that most people trying this have a little networking background but naturally 192.168.50.x will not route to 192.168.1.1 (well, it can with VLAN config but… this is a home network let’s not go there…).  So what do we do?  Simple – we set the nameserver in resolve.conf to either 192.168.50.1 (our router on 192.168.50.x) or we set it up to an external DNS server like 8.8.8.8 (Google.com).  It’s your call!

Now, let’s try that update thing again:

jon@BeagleAPP1:~$ sudo apt-get update
Get:1 http://repos.rcn-ee.net trusty InRelease [1,782 B]
Ign http://ports.ubuntu.com trusty InRelease
Ign http://ports.ubuntu.com trusty-updates InRelease
Hit http://ports.ubuntu.com trusty Release.gpg
Get:2 http://repos.rcn-ee.net trusty/main armhf Packages [11.6 kB]

Awwwwyeaaaaah.  Receiving data from these internet repositories – great!

After we run sudo apt-get update we’ll do sudo apt-get upgrade.  The difference between the two is that the first command updates your BBB’s list of repositories (where updates/packages are stored) and the second command actually checks those repositories to see if the version of packages you have on your BBB are deprecated based on newer versions out in the universe!  Depending on when you install Ubuntu 14.04 as of this writing you may have only a couple packages to update or you may have dozens.

Once you’re all up to date there are only a few (what I consider) required steps left, hurray!  Let’s set the timezone on this little fella’ and get wrapping up.

The timezone in Ubuntu 14.04 works by creating a link in /etc called localtime that points to (the pointing is called a symlink) an entry in /usr/share/zoneinfo/… so first we need to remove whatever is currently linked there:

jon@BeagleAPP1:~$ sudo rm /etc/localtime

Now that we’ve got no links for timezones, let’s add on back in:

jon@BeagleAPP1:~$ sudo ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

Almost done!  But, it’s getting late and we’re all a bit tired so let’s check the date and time and get this over with:

jon@BeagleAPP1:~$ date
Sun Jul  6 20:17:16 EDT 2014

Oh, dear.  July 6th?  That’s not right.  Hrmph.  It does say EDT so that’s good (because I set it above to …/America/New_York)… but the time is wrong still.  That’s because we need to tell BBB to go out on the internet and sync up:

jon@BeagleAPP1:~$ sudo ntpdate -b -s -u pool.ntp.org

The command ntpdate tells the machine to go out to pool.ntp.org and check the time and if it’s wrong, synchronize.  There are many NTP sources out in the universe, but I chose to use pool.ntp.org because it’s easy to remember and I like it.  So now we’re up-to-date, right?  Let’s see:

jon@BeagleAPP1:~$ date
Thu Jul 27 23:39:29 EDT 2014

Yes!  It’s today!  It’s now!  This is so amazing!

So now we’re done!  Let’s… wait a second.  It just dawned on me…  does BeagleBone have an internal RTC (real-time clock)?  I don’t see a CMOS battery anywhere on the board and it’s not like its easy to miss with a board so small.  Oh, jeez, it doesn’t have an RTC.  So the clock will stop when the unit is powered off and will have the wrong time when turned back on.  I guess we should get familiar with setting that ntpdate command each time, though that is pretty inconvenient.  It’d be great if we could just tell the BBB to check the time every now and then, you know?  Oh well.  Maybe later when we become programmers and can be bothered….

… Not!  It’s simple to do and it also shows you a very basic method of scheduling tasks in Linux.  Crontab time!

A cron job is a scheduled task just like in Windows “task scheduler” – though the syntax is… um… a little less… nice.  So, to keep it simple for you, this is how you add a cron job for this ntpdate process:

jon@BeagleAPP1:~$ sudo crontab -e
[sudo] password for jon:
no crontab for root – using an empty one
/usr/bin/select-editor: 1: /usr/bin/select-editor: gettext: not found ‘select-editor’.
/usr/bin/select-editor: 1: /usr/bin/select-editor: gettext: not found
1. /bin/nano        <—-
2. /usr/bin/vim.tiny
/usr/bin/select-editor: 32: /usr/bin/select-editor: gettext: not found
1-2 [1]: 1
crontab: installing new crontab
(then add:)
00 */12 * * * ntpdate -b -s -u pool.ntp.org

Sweet – but what’s with all the 0′s and slashes and *’s?!  Yeah it’s a little cryptic.  That’s the schedule.  Here’s how it works:

*     *     *   *    *        command  executed
-     -     -   -    -
|     |     |   |    |
|     |     |   |    +----- day of week (0 = Sun)
|     |     |   +------- month (1 - 12)
|     |     +--------- day of month (1 - 31)
|     +----------- hour (0 - 23)
+------------- min (0 - 59)

So, it makes a little sense, I guess.  If you want to repeat something every so often, you’ll use a / and a number.  For instance, we have */12 in the hours field – that means it will try and synchronize the time (by running the command at the end) every 12 hours.

That’s it!  You’re set!  You’ve setup a new user with password, removed the default ubuntu user along with its files/directory, updated the system after confirming the DNS, and updated the time while also creating your first cron job to check for the date/time every 12 hours.  What more could you want?!

Good luck I hope this was helpful – the steps outlined above are what I consider the bare-minimum for a new BBB Ubuntu deployment especially if putting it on the internet.  If you are just going to control GPIO’s or run some scripts not all of this will be useful, but people sometimes forget that their device is online when on wifi or eth0 so it’s good to eliminate potential security issues up front.  Next we’ll cover tracking disk space so that if you run a database or log sensors to the unit you never find yourself out of some place to store your info!

Enjoy!  Make sure to try more stuff and if you come across something cool definitely share it here!