Sometimes I find that some Ubuntu installations don’t have the dig command available:

[chris@work ~]$ dig +short example.com
-bash: dig: command not found
[chris@work ~]$ 

The solution is to install the dnsutils package. For example:

[chris@work ~]$ sudo apt-get install dnsutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  rblcheck
The following NEW packages will be installed:
  dnsutils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/147 kB of archives.
After this operation, 378 kB of additional disk space will be used.
Selecting previously unselected package dnsutils.
(Reading database ... 182371 files and directories currently installed.)
Unpacking dnsutils (from .../dnsutils_1%3a9.9.3.dfsg.P2-4ubuntu1.1_amd64.deb) ...
Processing triggers for man-db ...
Setting up dnsutils (1:9.9.3.dfsg.P2-4ubuntu1.1) ...
[chris@work ~]$ dig +short example.com
93.184.216.119
[chris@work ~]$ 

I recently had to find out which APT package provided a specific command on one of my Ubuntu systems. After a bit of digging, I discovered that the dpkg command’s magical -S switch gives us a simple way to do this.

Per the dpkg-query man page, the -S switch (also valid as --search) does the following:

-S, --search filename-search-pattern...
    Search for packages that own files corresponding to the given pattern.  Standard shell wildchars can be used in the pattern.  This command will  not  list  extra  files  created  by  maintainer scripts, nor will it list alternatives.

In other words, it takes a file pattern (optionally including a path or portions of a path), searches the known packages to see if any have owned files that match the requested search, and lists any packages that contain a match.

For example:

[chris@home ~]$ dpkg -S /usr/bin/GET
libwww-perl: /usr/bin/GET
[chris@home ~]$ which ls
/bin/ls
[chris@home ~]$ dpkg --search /bin/ls
coreutils: /bin/ls
[chris@home ~]$ dpkg --search /etc/cron.d
sysstat, php5-common, cron, anacron, rsnapshot: /etc/cron.d
[chris@home ~]$ dpkg --search /etc/cron.d/*
anacron: /etc/cron.d/anacron
php5-common: /etc/cron.d/php5
rsnapshot: /etc/cron.d/rsnapshot
sysstat: /etc/cron.d/sysstat
[chris@home ~]$ dpkg --search /etc/cron.daily
google-chrome-beta, man-db, update-notifier-common, apt, popularity-contest, anacron, logrotate, aptitude, cracklib-runtime, dpkg, passwd, google-musicmanager-beta, sysstat, apache2, apache2.2-common, apport, google-talkplugin, cron, samba, bsdmainutils, ntp, mlocate: /etc/cron.daily
[chris@home ~]$ which which
/usr/bin/which
[chris@home ~]$ dpkg -S /usr/bin/which
debianutils: /usr/bin/which
[chris@home ~]$ which dpkg
/usr/bin/dpkg
[chris@home ~]$ dpkg -S /usr/bin/dpkg
dpkg: /usr/bin/dpkg
[chris@home ~]$ 

I added in the which command to show how you can retrieve the full path to specific commands.

Notice how supplying /etc/cron.d returned a listing of all matches for that specific string while searching for /etc/cron.d/* provides a separate match for each entry in the /etc/crond.d directory.

I really need to dig deeper into the dpkg command as it has a wealth of handy features that are just waiting to be used.

I booted up my Ubuntu 13.10 system running Unity today to find that the clock was missing in the app panel.

Fortunately this was easy to fix without having to reboot the system. I simply ran the following:

[chris@work ~]$ killall unity-panel-service
[chris@work ~]$ 

The clock instantly appeared.

If this doesn’t fix your problem, make sure that you have the indicator-datetime package installed. You can try installing it by running the following:

[gaarai@tenshi ~]$ sudo apt-get install indicator-datetime
The following NEW packages will be installed:
  gnome-control-center-datetime{a} indicator-datetime
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/55.7 kB of archives. After unpacking 318 kB will be used.
Do you want to continue? [Y/n/?] y
Selecting previously unselected package indicator-datetime.
(Reading database ... 552412 files and directories currently installed.)
Unpacking indicator-datetime (from .../indicator-datetime_13.10.0+13.10.20131023.2-0ubuntu1_amd64.deb) ...
Selecting previously unselected package gnome-control-center-datetime.
Unpacking gnome-control-center-datetime (from .../gnome-control-center-datetime_13.10.0+13.10.20131023.2-0ubuntu1_amd64.deb) ...
Processing triggers for libglib2.0-0:amd64 ...
Processing triggers for libglib2.0-0:i386 ...
Processing triggers for bamfdaemon ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for desktop-file-utils ...
Processing triggers for mime-support ...
Processing triggers for gnome-menus ...
Setting up indicator-datetime (13.10.0+13.10.20131023.2-0ubuntu1) ...
Setting up gnome-control-center-datetime (13.10.0+13.10.20131023.2-0ubuntu1) ...
Processing triggers for libc-bin ...

[gaarai@tenshi ~]$ 

I’m finding that more and more software developers are being quite inconsiderate and are making code that requires PHP 5.3. Since many server-based and long-term support distros are still on PHP 5.2, this can make things difficult quickly.

I’ll share how I upgraded one of my servers, but I do need to let you know about some specifics about my setup as your setup may be different and require different steps to upgrade.

When I started, my system ran CentOS 5.5 and PHP 5.2.16. Now it is running CentOS 5.6 and PHP 5.3.3.

You won’t be able to follow these steps without root access, so that is definitely a requirement. I’m also running Apache. You may be using a different web server, but if you don’t know what I’m talking about, you are running Apache. I assume that if you run a different server, you will know what to change in my steps.

Read More→

I just updated one of my CentOS systems to PHP 5.3 (a chore best reserved for another blog post), and started to see the following warning popping up:

PHP Notice: in file index.php on line 15: date(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘America/Chicago’ for ‘CDT/-5.0/DST’ instead

Annoying to say the least. The fix is much easier than the message makes it seem.

PHP 5.3 now requires that you either have a timezone set in your php.ini file or that you pass the desired timezone via the date_default_timezone_set() function before calling the date() function.

I opened my server’s /etc/php.ini file and searched for timezone. My ini file had a section like the following:

[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
; date.timezone =

I uncommented the date.timezone line and added the timezone I wanted.

[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'America/Chicago'

There are two very important things to do in order for this to work properly for you:

1. Use a timezone that is appropriate for your needs. Use PHP’s List of Supported Timezones to find the timezone that works for you.
2. Since your server is likely to cache the PHP configuration, you will want to restart your web server process in order for the change to be recognized. The command to execute varies by system, but for most systems, the following will work:

   [user@server /etc]$ sudo service httpd restart
   [sudo] password for user:
   Stopping httpd:                          [  OK  ]
   Starting httpd:                          [  OK  ]
   [user@server /etc]$ 

   Of course, if you are already root, you won’t need to use sudo:

   [root@server /etc]# service httpd restart
   Stopping httpd:                          [  OK  ]
   Starting httpd:                          [  OK  ]
   [root@server /etc]# 

I recently wrote a script to dump data into CSV files. The CSV files work well for using in other scripts, but they are a bit difficult to read in order to verify that the data looks good. Sure, I could transfer the files to my local system and open them up in OpenOffice Spreadsheet or a similar program, but I want to do quick checks of the generated data and constantly copying the data and opening it up again in a program would just slow me down. Fortunately, there is a better way.

Using a combination of the cat, column, and less commands that are available from most *nix shells, the CSV data can be rendered into a nice table and quickly navigated. Here is an example:

[chris@host data]$ cat file.csv | sed -e 's/,,/, ,/g' | column -s, -t | less -#5 -N -S
      1 number_of_tests  execution_time min  execution_time max  execution_time avg  execution_time std_dev  peak_memory_usage min  peak_memory_usage max  peak_memory_usage avg  peak_memory_usage std_dev  real_memory_usage min
      2 449              0.2421700954        0.2522599697        0.24422667392717    0.0013405194115834      22062656               22067696               22062951.732739        552.24028841091            22282240
      3 416              0.2449610233        0.2619900703        0.24721734340337    0.0015257664849685      21295528               21300888               21295541.019231        262.48728836508            21495808
      4 446              0.2286360264        0.2422661781        0.23043336515404    0.001174508347353       20895976               20900800               20895987.03139         228.20177111936            20971520
      5 428              0.1955471039        0.2902140617        0.1981168762521     0.0046106433816399      18045464               18048784               18045487.271028        276.98063531264            18087936
      6 436              0.2208828926        0.2558329105        0.22297720351353    0.0021463518368546      18717960               18723192               18718020.238532        557.06025400191            18874368

The output is easy to navigate with the cursor keys and is perfect for quickly verifying the generated data.

To use for your files, simply replace file.csv in the above example with your file’s name. The -#5 determines how many columns to scroll when using the left and right arrow keys. You can increase or decrease this as needed to make navigating easier.

For those interested, I’ve tested this on Debian-based (Ubuntu, Mint, etc) and Redhat-based (CentOS) systems, and it works on all of them.

Since I’m tying together various command line tools that have no concept of the CSV format, there are some contents that this does not handle well. For example, all commas will be treated as separating out columns, even if the comma is escaped by quotes or a backslash.

I updated the command to fix a problem with handling empty entries, such as “…,data,,data,…”. The sed command takes care of changing those empty values to a space.

Yet another tale from trying to run a Perl script with the setuid bit turned on. See my earlier post on fixing “Can’t do setuid (cannot exec sperl)” for details about why running perl scripts with setuid bits is a special case.

I tried to run my script and I got the following message:

[user@server ~]$ run-script
Insecure $ENV{PATH} while running setuid at ~/run-script line 4.

The basic idea that this message is trying to get across is that an environment variable that is being used may contain data that could open up an attack vector. The way to fix this is by setting the variable to a set of defaults that don’t come from the user and thus are less susceptible to being manipulated by someone in order to break the security of the system.

In this case, my script executed a program on the shell. Since shell interpretation comes into play, the $PATH variable is looked at to decide where the program could be located. This is an attack vector as someone could just change that variable to cause their own code to be called, thus escalating their code’s privileges without your knowledge.

In order to avoid this, I set the $PATH variable to a restricted set for use in the script by adding the following in the script before my shell call:

$ENV{"PATH"} = "/usr/bin";

This may need to be modified to meet your specific needs. In addition to making this change, I went ahead and changed the call to the shell program to be an absolute reference to the program in order to further mitigate any potential issue, such as aliases.

I recently needed to run a perl script with setuid bit set. This allows the script to run as the user the script’s file is owned by. In this case, I needed the script to run as root.

Since doing this can be very dangerous, Perl does something very nice by default: If you have the setuid bit set on the script, it forces the script to run in Taint Mode which helps to ensure proper sanitation of the environment and inputs. By doing this, Perl can help lock down possible attack vectors that can compromise the security of your script. This isn’t perfect however, so I do recommend that you read up on Perl’s security measures.

So now down to the main point of this post. I tried to run the script with the setuid bit set, and I got the following error message:

[user@server ~]$ run-script
Can't do setuid (cannot exec sperl)

Well that certainly puts a damper on things. Fortunately, the solution is easy. There is simply an additional package that needs to be installed to provide the wrapper program that puts this Perl security in place.

For Debian (Ubuntu, Mint, etc as well), run the following:

[user@server ~]$ sudo apt-get install perl-suid

For CentOS, run the following:

[user@server ~]$ sudo yum install perl-suidperl