Skip to main content

Message of the Day

The message of the day (motd) file is used by the System Administrators to display information to users when the log in to a system using a command line tool (for instance ssh). On older systems, it was a single text file located in /etc/motd. On Ubuntu, after around v10.10, it was changed to a series of scripts that are executed instead of simply displaying a text file. There are many ways it can be invoked (or cause it to be displayed).

One place is from inside /etc/pam.d/sshd where there is a line for the motd:

`` session optional # [1]11

Commenting this out will disable the motd from being displayed. Another place the information can be stored is in the profile file located in /etc/profile.

It is also in the sshd configuration file (/etc/ssh/sshd_config) so don't forget to update that and then restart the sshd service (/etc/init.d/sshd restart) for any changes to you make to the config file.

Renamed ethernet Devices

I had a problem when I copied a Linux virtual machine from one host to another and made some changes (specifically which networks it could see on the host). Specifically the ethernet devices changed and the udev process couldn't find the old devices, resulting in the network interfaces wouldn't come up.

Logging onto a console will identify that eth0 (as an example), is gone and you have no network interfaces. Examinging the dmesg output with the command dmesg | grep eth will show something similar to the following:

udev: renamed network interface eth0 to eth2
udev: renamed network interface eth1 to eth3

The solution is to edit the file /etc/udev/rules.d/z25_persistent-net.rules and change the configuration information for the relevant NICs in that file so that they are named with the correct interfaces so that /etc/network/interfaces can load the correct network (IP) configuration information. I hope this helps someone else as it was challenging for me to solve this problem. (By the way, this may also occur if you replace a Network Interface Card (NIC) in your system!)

IP Address...or Who Am I?

For computers to talk on a network, they need a unique address. The most common type of address is an Internet Protocol, or IP, address. The address consists of a network portion and a device (computer) portion. I use the term "device" only because it could be something other than a computer, like a printer, tablet or smartphone. It isn’t critical to understanding IP Addresses that there is a separate network portion and a separate device portion, but it does become important when you to want to understand how data moves across your personal network and across the internet.

Currently, the most common format of IP address is Internet Protocol version 4 (IPv4). It consists of four groupings of 8 bits (each grouping is called an octet) separated by periods. While it is four groupings of bits, it is more commonly represented as four numbers between 0 and 255 separated by periods. Since I have a permanent IP Address on the internet, my address is Since you’re reading this on my website, you may know it more commonly as (the name associated with the IP Address, and viewable as in your web browser’s window).

There are two types of IP Addresses: Static IP addresses and Dynamic IP Addresses. Static IP Addresses are permanently assigned to you by your Internet Service Provider (ISP). The only reason you need a static IP Address is if you want to provide a service (like email or manage a web server) on the Internet. This ensures people can always find you since your IP Address will always be the same. Most people, however, have a dynamic IP Address given to them when the turn on their computer, router or dial into their Internet Service Provider. The ISP keeps track of a list of addresses and gives it out to users (devices) when they connect to the internet.

Many users who have a broad-band connection (through a cable modem, DSL, or FIOS/Fiber Optic Service) think they have a static IP address because it’s the same every time they connect. However, it’s just a coincidence and they could get a different IP address at any time.

I’d like to add one last comment about IP Addresses before I explain the significance of the bits. There are two different types of IP Addresses: routable (addresses that are directly accessible on the internet) and non-routable (or what I’m going to call “private”) IP Addresses. (NOTE: This is not the same as a Virtual Private Network or VPN, which is a separate topic). Most homes and businesses have private IP addresses assigned to their employee’s or home computers. Then there is a device called a router that translates the “private” IP Address to a public IP Address and allows users to do things like browse the web and send email, among other activities. These devices are called “routers” because they route, or move traffic, between the two networks (the public and private or between two private networks). These devices may also be described as wireless routers or firewall-routers and are sold by companies like Cisco (Linksys), Netgear, and Buffalo, to name just a few manufacturers.

These private IP Addresses usually start with 10.x.x.x, 172.16.x.x (to 172.31.x.x), or 192.168.x.x (where “x” is some value between 0 and 255). These addresses fall into a range of defined IP addresses for a private (or a non-routable) network. (NOTE: I do NOT use the term secure. The use of a “private” network does not in any way mean your communications are secure from unauthorized users!) This allows communications between your devices (on your private network) and limits the data that “leaks” onto the Internet. In effect, it reduces the amount of “unnecessary” data on the Internet. (NOTE: This does not prevent viruses or other bad software from sending unauthorized data off your computer or network!) If you want more information on network addressing, please see

This document explains how Internet Protocol (IP) Addresses are unique on a particular network and allows computer or devices to talk to on another. It also provides a basic explanation of how private networks reduce the data traffic on the internet and connect local devices together.

Originally written: May 15, 2008, Finished Editing: October 28, 2008

VMWare From the Windows Command Line

The ability to manage a vmware instance from the command line can be critical when the GUI or webpage (since VMWare has a built-in web server so you can manage some of your virtual machines) won't work. In this case the following two commands helped me on Windows XP:

C:\> cd "c:\Program Files\VMware\Vmware Server"
C:\Program Files\VMware\Vmware Server> vmrun.exe -h "https://localhost:8333/sdk" -P 8333 -T server -u TJ -p PASSWORD stop "[standard] Ubuntu8/Ubuntu.vmx"

This allowed me to user my username (TJ) to shutdown the system using my local (domain) password.

Additional information on the command line switches is also available at

Additional information can be found in the documents at or at

MSSQL Versions

There are always a variety of ways to get the version of Microsoft SQL Server (MSSQL). The easiest way to get the version is to use MSSQL Enterprise Manager (or SQL Server Studio) and view the version number next to the server name.

There is another way by examing the value of the @@version variable. Specifically you can execute the following SQL statements:

SELECT @@version

The following code will as well, and in a slightly different format:

SELECT 'SQL Server '
+ CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - '
+ CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' ('

This will return the data in a slightly different format so you can identify the information related to which type of SQL Server is installed.

But many people will wonder why you'd even want to execute the SQL since it would take longer. My thought is that if you wrapped this up in a CMD file (using OSQL to execute it against a list of servers) you can generate a list of the versions of MSSQL that exist in your environment. This makes it easier for audit questions or if you just need to validate what versions you are using.

Drupal Information

Drupal is a piece of software that helps you create and manage content (information) on a website. This falls into a category of software called Content Management Systems (CMS). In reality, it is more of a "framework" to provide specific functionality related to the "pages" you create and manage, to include a consistent look and feel (a theme) as well as additional tools to control and manage the content, or information.

The main website for Drupal is available at On that website they describe Drupal as "Community Oriented Plumbing," which does fit in with the orientation of a CMS. Part of the power of any CMS is the ability to easily allow anyone (or some small group of people) to create, manage and/or publish content on the World Wide Web (there is a pretty dynamic security model in Drupal to enforce managing content).

Probably a little more than you wanted, but here's the info on Drupal. Some of these links are for me to share with others as well, and this email just is my "historical documentation" in case I have to find it again. <grin>

Here are a few sites that use (or used) Drupal: (PSU - Portland, OR site) (Foreign Exchange with Farheed Zakara) (Pro Firefox Advocacy web site) (Fake news web site) (Linux News website) (Linux News website) (Linux News website) (Karlstad University library) (Personal website)

Some links to Drupal related sites include:

Other Drupal Info:

Creating Accounts in Postgres

Many people new to Postgres are confused by the security model. They understand the SQL commands that use GRANT, CONNECT and REVOKE to alter permissions (the SQL DSL, or Data Security Language component of SQL) because that is common across various SQL Database Engines. However, Postgres has another layer of security that you need to successfully navigate first.

== pg_hba.conf ==

Postgres uses a configuration file, called the pg_hba.conf file, that identifies how each user (or users) can connect to each database in the postgres engine. It identifies what system (or systems) the user(s) can connect from what systems and also specifies the authentication method they use for that database. In wriitng (and revising this), it sounds complex, or maybe it's just my style of writing. But the below description should make it clearer.

Basically there are four fields that are checked:

  • Username
  • Database
  • User connection source
  • Authentication mechanism

The sample file below (with explanation) may help understand the different methods and sources:

local     all         postgres         ident
local     music_db    music            md5
local     all         dbadump          trust
#local     all         all              ident sameuser
local     all         all              ident

This means that the user _postgres_ can connect locally (over a Unix Socket) to any database, and you will trust that the Operating System has already identified the user (the ident method).

The user _music_ can connect locally to the database music_db using a password encrypted in postgres (the password is encrypted using md5).

The user _dbadump_ can connect locally to any database and is trusted into that database. This is a potential security issue as ANY user on the local system can claim to be the user _dbadump_ and connect to any database. (You'd have to rely on SQL DSL and GRANT permissions to restrict their access at this point!)

The next line is a comment. So it is ignored by engine, but you can use it to document your configuration file if you so wish.

The last line says that any other system user (Linux or Windows) can connect locally to any database (again, their permissions should be controlled through DSL inside each database).

One thing to note (and is specified in the Postgres documentation) is the permissions should be going from MOST restrictive (the tightest definition) to the LEAST restrictive (the potential for more people to match the "rule"). The reason is that the first rule that matches (whether they successfully log in or not!) determines which rule APPLIES (and no further checking occurs!).

Now that I've shown what happens when you connect locally (over a Socket), we'll talk about REMOTE (from another computer) connections.

# IPv4 local connections:
host      all         all           md5

Any user that connects to any database using localhost ( to will use an encrypted password stored in Postgres.

A word of warning on this one - I've used the network of 127.*.*.* instead of just because some Linux distributions define the localhost (or even the hostname) with something else in the 127.*.*.* network. If you choose to use a CIDR Address of or (anything between and you could exclude some addresses where they would connect with a different rule.

host      music_db    music       md5
host      music_db    music       md5
host      all         timothy        md5
host      all         dbauser       trust
hostssl   all         admin             md5

The user _music_ can connect to the database music_db from either or (and they can authenticate or prove who they are by providing a password that matches their password stored in postgres and encrypted using the md5 algorithm).

The user _timothy_ can connect to ANY database from any computer with an IP Address between and (NOTE: This is only on the local network. If you connect over the Internet, which I will show later, you will have a different EXTERNAL IP Address that the database engine will see.)

The user _dbauser_ can connect to any database from the IP Address of ONLY. But any user that claims to be _dbauser_ on that system will be explicityly trusted into the engine.

The user _admin_ can connect from ANY IP Address in the world and will be able to prove who they are by providing a password that matches up with what is already encrypted and stored inside Postgres. The only difference between this and previous "host" entries is that the connection is encrypted using SSL (Secure Sockets Layer). There is additional overhead associated with using encryption, but especially across the Internet, you really should encrypt the whole session (especially the authentication piece so you don't send a password across the Internet in plain text).

The last line is similar, but it authenticates against a LDAP souce rather than having the password stored in postgres.

== Roles ==

Once the user has a connection to the server/database, a second mechanism is used to identify what objects they can access, basically where they have permissions to view or update data. This is the Data Security Language (DSL) portion of SQL. This is where you allow a user to CONNECT to a database or read data (SELECT permission) or update data (UPDATE or DELETE permissions). These permissions are well explained in the documentation for Postgres or any other SQL Database engine.

How Computers Talk to Each Other

I was asked by a friend to explain how computers talk to one another, as she had no understanding of computer networking...or how computers talk, send data, to each other.

To start, every computer on a computer network has to have a unique address. The address consists of a network portion, and an identifier for the specific device (computer, printer, tablet, smartphone, etc.). While a user isn't concerned with the difference between the "network" portion and the "device" portion, it helps to realize that they are both included in the address. Currently, the most common address format is in the format of where x is a value between 0 and 255. If you look at the range, there are 256 values for each section (each group).

(A few people have asked "why does it stop at 255?" Computers deal only with bits, which have one of two values: 0 and 1. Combinations of 0s and 1s have additional meaning. Computers are binary systems (meaning they only understand two digits). The possible combination of values from 0 to 255 is represented by a group of 8 bits, or combination of 0s and 1s. In this case, the network address is actually 4 bytes or 32 bits.)

Each value is actually 1 byte in the address. Specifically, we refer to this as an IP, or Internet Protocol, Address. You may see it abbreviated as either IP Address, TCP/IP Address, or occasionally even IP Addy (short for address).

Since each computer has a unique address, we know "where" the computer is. We also require a few other pieces of information. We need to find a port on the destination system to talk to. This port is connected to an application that listens for data and/or commands. After the computer(s) start talking with each other, they may agree to move to another port for further communication.

This is some special software, called Domain Name Service or DNS, that relate IP Addresses to computer names, and vice-versa. This helps resolve, or change, computer names to IP Adresses. Since computers ONLY talk to each other by IP Address (See RFC 1518 - and for more information), which solves two fo the five necessary requirements for computers to talk, especially since your computer already "knows" it's own IP Address.

We now understand the importance of IP Addresses, or at least as part of the communication process, computers need to have a protocol. The protocol helps both computers understand how the data is communicated between them. This explains the "language" of the data being communicated. Like someone converting Spanish to English, this explains that the first X number of bits are the source IP Address, the next Y group of bits are the destination address, and the next group of Z bits are the type of data being transmitted, the next group is any error checking and other "management", and the data being sent to the destination system. In short, the protocol is the understanding of what the data stream is supposed to look like. Of course, there is a lot more information that that in each data packet.

The last thing to understand is the port. The operating system creates special memory locations that programs can connect to. The program can connect to one or more of these memory locations and respond to data or commands that come into and out of this special memory. Usually after the initial communication takes place, the server portion will tell the client, "Hey, next time you talk to me, talk on a different port - we'll call it 'Y'." This allow a service (an application) to always listen on a single port for incoming communications (like the Web Server called Apache which listens on Port 80 or Port 443 and moves the communication to a different port).

Sometimes people wonder if they need to know all these ports (off the top of their head). In reality, the answer is no. Most applications send an expected port along with their data. For instance, when you send an email your email software knows to sned it using SMTP (Simple Mail Transport Portocol) on port 25 (as one example, your email client may also use other ports depending on how it is communicating with the eMail Service). In another example, you request a web page using your web browser over the HTTP (Hyper Text Transport Protocol) on port 80 or port 443 if it is an encrypted / secure connection.

There are many common protocols with known ports, and a list of them is probably on your computer system. Under Linux or on a Macintosh, these are usually listed in a file called /etc/services. For Microsoft Windows computers, the file may exist in C:\Windows\System32\Drivers\etc\services on Windows 2000 and Windows XP. For these Operating Systems, they are normal text files that can be viewed, but should not be edited or changed (even if the computer allows you to). If you were to make a change and successfully save the file, you won't have any impact to the system as these are more for reference than for actual operation. But you could confuse other people with any inadvertent changes if they happen to look at the file.


  • Should I include a reference section?

  • Should I include a list to RFC?

  • Do I have a networking 101 Document

Tinymce Issue on Drupal Upgrade

After an upgrade, I was having trouble viewing some pages due to a number of errors. They all revolved around missing tables for tinymce.

I was able to solve this by creating two tables: tinymce_role and tinymce_settings.

The SQL to generate these two tables is:

CREATE TABLE `tinymce_role` (
    `name` varchar(128) NOT NULL default '',
    `rid` tinyint(3) unsigned NOT NULL default '0',
    UNIQUE KEY `name` (`name`,`rid`)

CREATE TABLE `tinymce_settings` (
    `name` varchar(128) NOT NULL default '',
    `settings` text NOT NULL,
    PRIMARY KEY  (`name`)

After running this, I was able to successfully run the update script to correct other missing dependencies.

UPDATE (04 March 2015): I never annotated what version of Drupal this was with. If my memory is correct, this is with something in the 5.x range of versions. Furhter, this was in MySQL, prior to my migration from MySQL to PostgreSQL.

Plugins for Squirrel Mail

Adding a Squirrelmail plugin is relatively simple. This sample installs the "change_sqlpass" plugin (which requires the "compat" (or compatibility) plugin. First copy the necessary plugins to the server you are installing them onto. A command like:

$ scp plugin timbruce@server:~/download/squirrelmail

Depending on how it's installed, you need to assume the correct user to configure the plugin.

$ sudo su -

On Ubuntu, you need to change to the following directory:

# cd /usr/share/squirrelmail/plugins

Then execute the following command:

# tar -xzvf compatibility-2.0.9-1.0.tar.gz
# tar -xzvf change_sqlpass-3.3-1.2.tar.gz

Detemine which version of SquirrelMail you are running (looking at the login page will help). I'm using Ubuntu version 1.4.10a, so I patch using v1.4. Now I can install compatibility using the following command:

# cd /usr/share/squirrelmail/plugins/compatibility/
# patch -p0 < patches/compatibility_patch-1.4.10.diff

After this, configure SquirrelMail.

# cd ../config
# ./

Go to #8 (Plugins) and install change_sqlpass. (NOTE: I also need to update the plugins/change_sqlpass/config.php file with the appropriate parameters to allow it to update the database.)