Showing headlines posted by jwright

This morning, I worked on an Ubuntu Server 14.04 guest who’s disk space has been increased by the VMWare host. LVM was configured on the guest during installation, so that simplified the process of getting the extra space rolled into the original partitioning scheme. Below is a set of instructions that I was able to use on this live server without interruption in service.

I’ve found a few articles about using the Clojure programming language on the BeagleBone Black. However, all of them I’ve seen gloss over the installation steps. I got Clojure 1.6.0 running on my rev B BeagleBone Black (aka BBB from here on) and I’ve outlined the steps to do it in this post. If you haven’t done anything with your BBB yet, plug it in to a free USB port and open START.htm when it mounts as a drive.

Recently, I needed to count open-close machine cycles for a customer. We couldn’t trust the machine readouts, so we needed an external device to count the cycles accurately. This device also needed to be built quickly and easily moved from machine to machine.

Pulling together hardware designers from all over the Internet presents several challenges. Among these is the task of keeping things like project time lines, roadmaps, forums, wikis, and issue tracking organized and cohesive. There may also be the need to collect and organize design files such as CAD, which don’t fit well into the traditional paradigm used by source code management systems like git and CVS. The main reason for this is because CAD files tend to be binary, and are hard to diff or merge in any meaningful way.

When making your custom scripts or software available to someone else, it’s a good idea to make that content as easy to extract and install as possible. You could just create a compressed archive, but then the end user has to manually extract the archive and decide where to place the files. Another option is creating packages (.deb, .rpm, etc) for the user to install, but then you’re more locked into a specific distribution. A solution that I like to use is to create a self-extracting archive file with the makeself.sh script.

Welcome, in this blog post we’re going to set Bodhi Linux up on a touchscreen device. Since the last post covered touchscreen calibration, I thought I would go one step beyond that by choosing and configuring a distribution to make the touchscreen easy to use (on-screen keyboard, finger scrolling, etc). This post won’t be an exhaustive run through of everything that you can do with Bodhi on a touchscreen system, but my hope is to give you a good start. Please feel free to talk about your own customizations and ways of doing things in the comment section. We’ll be focusing on desktop touchscreens and Intel based tablets here, but Bodhi also has an ARM version that’s currently in alpha. The ARM version of Bodhi will officially support Archos Gen 8 tablets initially, and then expand support out from there. I’m using Bodhi because it has a nice Enlightenment Tablet profile that I think makes using a touchscreen system fairly natural and intuitive. You of course could also use another distro like Ubuntu (Unity) or Fedora (Gnome Shell) with your touchscreen but, as I mentioned, I’m partial to Bodhi for this use.

I recently did some work with an ELO Touchsystems 1515L 15? LCD Desktop Touchmonitor. I was pleased with the touchmonitor’s hardware and performance, but in order to make it work properly in Linux I had to find a suitable calibration program. Out of the box on several distributions this touchscreen exhibits Y-axis inversion, where touching the top of the screen moves the cursor to the bottom and vice versa. xinput-calibrator is a freedesktop.org project that worked well for calibration, fixing the Y-axis inversion issue, and as a bonus it works for any standard Xorg touchscreen driver.

In this tip we’re going to explore a couple of ways to find open IP (Internet Protocol) addresses on your network. You might need this information if you were going to temporarily set a static IP address for a host. Even after you’ve found an open IP though, you still need to take care to avoid IP conflicts if your network uses DHCP (Dynamic Host Configuration Protocol). Please also be aware that one of these techniques uses the nmap network scanning program, which may be against policy in some environments. Even if it’s not against corporate policy, the nmap man page states that “there are administrators who become upset and may complain when their system is scanned. Thus, it is often advisable to request permission before doing even a light scan of a network.”

Now, if you’ve ever tried to use sudo to run a command sequence such as a pipeline, where each step required superuser priveleges, you probably got a Permission denied error. This is because sudo only applies to the first command in the sequence and not the others. There are multiple ways to handle this, but there are two that stand out to me. First, you can use sudo to start a shell (such as bash) with root priveleges, and then give that shell the command string. This can be done using the -c option of bash. To illustrate how this works, I’ll start out using sudo to run cat on a file that I created in the /root directory that I normally wouldn’t have access to.

Your shell script has little to no chance of running securely if it trusts the environment that it runs in, and that environment has been compromised. You can help protect your script from unintended behavior by not trusting items like environment variables. Whenever possible, assume that input from the external environment has been designed to cause your script problems. The PATH variable is a common source of security holes in scripts. Two of the most common issues are the inclusion of the current directory (via the . character) in the path, and using a PATH variable that’s been manipulated by a cracker. The reason that you don’t want the current directory included in the path is that a malicious version of a command like ls could have been placed in your current directory.

This post is the second in a series on shell script debugging, error handling, and security. The content of this post will be geared mainly toward BASH users, but there will be information that’s suitable for users of other shells as well. Information such as techniques and methodologies may transfer very well, but BASH specific constructs and commands will not. The users of other shells (CSH, KSH, etc) will have to do some homework to see what transfers and what does not. There are a lot of opinions about how error handling should be done, which range from doing nothing to implementing comprehensive solutions. In this post, as well as my professional work, I try to err on the side of in-depth solutions.

This post is the first in a series on shell script debugging, error handling, and security. Although I’ll be presenting some methodologies and techniques that apply to all shell languages (and most programming languages), this series will focus very heavily on BASH. Users of other shells like CSH will need to do some homework to see what information transfers and what does not. One of the difficulties with debugging a shell script is that BASH typically doesn’t give you very much information to go on. You might get error output showing a line number, but that’s just the line where the shell became aware of the error, not necessarily the line where the error actually occurred. Add in a vague error message such as the one in Listing 1, and it gets difficult to tell what’s going on inside your script.

If you just want enough information to fix your problem quickly, you can read the How-To section of this post and skip the rest. I would highly recommend reading everything though, as a good understanding of the concepts and commands outlined here will serve you well in the future. We also have Video and Audio included with this post that may be a good quick reference for you. Don’t forget that the man and info pages of your Linux/Unix system can be an invaluable resource as well when you’re trying to solve problems.

lsof is used to LiSt Open Files, hence the command’s name. It’s a handy tool normally used to list the open files on a system along with the associated processes or users, and can also be used to gather information on your system’s network connections. When run without options, lsof lists all open files along with all of the active processes that have them open. To get a full and accurate view of what files are open by what processes, make sure that you run the lsof command with root privileges.