SonicChicken blog

Recently I’ve had one of my student assistants working on setting up a web server. She’s pretty much got it, except that she hasn’t been able to establish a connection from the web server to our database server.

We’re wanting to use ADODB to connect to a mssql server. She figured out how to install the databases/adodb5 port (and how to get ADODB included in the PHP configuration), but that wasn’t enough by itself. I thought there might be a PHP extension required, and a little Unix pipe revealed the missing module:

# grep -i ^php /usr/ports/INDEX-7 | grep -v ^php4 | grep -i adodb

The command above searches the ports index for lines starting with “php” (or “PHP”), ignores those which begin with “php4″ (I’m not interested in version 4 stuff), and searches everything that’s matched so far for “adodb” (or “ADODB”). Results:

php-adodb-ext... (long index line snipped)

A quick check of /var/db/pkg verified that this module hadn’t been installed yet. I installed the module via portmaster(8) and added the new extension per the pkg-message instructions:

# portmaster databases/php-adodb-ext
.
.
.
(installation stuff snipped)
# cat >>/usr/local/etc/php/extensions.ini
extension=adodb.so

Now we’re getting a different error:

PHP Fatal error:  Call to undefined function mssql_get_last_message() in /usr/local/share/adodb/drivers/adodb-mssql.inc.php on line 501

Google indicates the problem is likely that the mssql extension for PHP isn’t installed. I ran the same pipe that I did for ADODB, this time searching for mssql:

# grep -i ^php /usr/ports/INDEX-7 | grep -v ^php4 | grep -i adodb

php5-mssql... (long index line snipped)

So another portmaster(8) installation, this time for php5-mssql. One of php5-mssql’s dependencies is freetds-msdblib, which has some configuration options. The only one I’m setting is MSDBLIB, which enables MS SQLserver (in lieu of the old Sybase DB).

This port (php5-mssql) automatically registers itself as a PHP extension, so you don’t have to add a line to /usr/local/etc/php/extensions.ini yourself.

I’m still getting errors, but they’re starting to look like problems with the database connection string instead of server configuration now. Progress, of a sort. But that’s enough for now–It’s almost 8:00 pm on Friday night before a 3-day weekend, long past time for me to get on with my own life!

We’ve been getting the following types of error messages on our DHCP server (running on FreeBSD):

Jan 12 07:01:52 *someserver* dhcpd: uid lease 192.168.100.200 for client 00:12:34:56:78:9a is duplicate on 192.168.100/24

Google turned up a helpful post which told me what the problem was, but I didn’t care for the suggested fix. Initially I concentrated on the MAC addresses listed in the error log, seeing if they were also defined in our dhcpd.conf file:

grep "is duplicate" /var/log/messages \
    | cut -f 11 -d' ' \
    | sort -u \
    | grep -C --file=- /usr/local/etc/dhcpd.conf

But this doesn’t seem like the correct approach. What we really ought to be doing is comparing our dhcpd.leases file to dhcpd.conf, looking for MAC addresses that are listed in both. Anything that’s listed with a fixed-address in dhcpd.conf probably shouldn’t be the leases file, IMHO. That’s probably a bit too complicated for a bunch of shell commands piped together, since we’d need to parse a multi-line DHCP entry from each file. I think a perl script might do the job.

We are currently building about a dozen FreeBSD servers at work. The build process is pretty well documented, but it’s a bit labor intensive. So I had one of my student assistants look into automating the process somewhat. This post discusses our assumptions and initial conditions, along with our results and recommendations. Hopefully this can help others trying to implement similar plans.

We implemented this on FreeBSD versions 6.2, 6.3, 6.4. We will also be testing this on version 7.1 later this month. We are focusing on the i386 architecture, and we would like to try large (≥3 GiB) memory configurations with the amd architecture as well.

All of our systems have a common set of basic tools:

• portmaster
• portupgrade
• portaudit
• spinner
• screen
• postfix
• nagios
• sudo
• bash
• emacs
• lynx

Ideally we would like to install all of these common tools with one command that doesn’t require further user intervention. We could have created a package for this, but I’m pretty sure we would need to build a separate package for every possible FreeBSD version and architecture — that’s 4 O/S versions x 2 architectures = 8 packages, which doesn’t seem worthwhile for ~12 systems.

Another possible approach would have been creation of a “metaport”, a single pseudo-application listing all of the tools as dependencies. I didn’t pursue this because it doesn’t (by itself) address the user intervention issue.

One more goal of this project was the automation/scripting of some common system configuration tasks such as enabling/starting NTP, setting up network printers, etc. This doesn’t have anything to do with the ports/packages system, so we needed to write a script for this part. Most of this code is pretty obvious and mundane, but I’ve included it in the article for the sake of completeness.

The trickiest part of this whole project was figuring out how to do unattended installation of ports with options, e.g. screen. Normally when you install such a port, you will be presented with an ncurses menu of options for that port. Each of these options should correspond to a WITH_* / WITHOUT_* variable that controls how the port is built, possibly affecting the port’s dependencies, etc. The options menu is displayed when the ‘config’ target is built:

# cd /usr/ports/sysutils/screen
# make config
(ncurses option menu appears, user chooses which options to enable/disable)
# grep ^WITH /var/db/ports/screen/options
WITHOUT_CJK=true
WITH_INFO=true
WITH_MAN=true
WITH_NETHACK=true
WITH_XTERM_256=true
WITHOUT_HOSTINLOCKED=true
WITHOUT_SHOWENC=true

The options are saved in /var/db/ports/portname/options, as shown above. Once you have figured out which options to enable/disable on one system (interactively), you can copy them into a port-specific section of /etc/make.conf as follows:

# echo '# Options for sysutils/screen' >>/etc/make.conf
# echo 'if ${.CURDIR:M*ports/sysutils/screen}' >>/etc/make.conf
# grep ^WITH /var/db/ports/screen/options >>/etc/make.conf
# echo '.endif' >>/etc/make.conf

We’ll now test this by removing the config file and building the port with the BATCH=yes flag set. This should prevent the ncurses config screen from popping up.

# cd /usr/ports/sysutils/screen
# make rmconfig clean
(We're using /bin/sh for our installation script, as well as for testing.)
(If you're using csh, you'll need to use *setenv* instead of *export*.)
# export BATCH=yes
# make install clean
(Lots and lots of output, but no configuration prompting!)

The components of the solution are all in place! Now all we need is to put them together and write the script, but that’ll have to wait until next week.

We got a new Kyocera printer at work a few days ago. The model we’re trying out is an “EP510DN“. We had a heck of a time finding information for this printer on the Kyocera web site. In desperation, we called their sales/support people who informed us that a Kyocera “EPwhatever” is an EcoPro unit, all of which show up on the KyoceraEcoPro domain. (Personally, seems like having completely different domain names for the same company is a good way to dilute your brand.) As soon as I added “EcoPro” to my Google query, I got meaningful results on the first page.

We are setting this up on a FreeBSD print server. We had DHCP and DNS configured and tested, so we created a printcap(5) entry for the printer, and got… errors (from the /var/log/lpd-errs log file):

lpd[32955]: /dev/lp: No such file or directory

After much head-banging, I finally figured out the problem–there was some whitespace at the end of one of the lines in the printcap. Doh!

Some other notes and information about this printer:

• Web-based configuration doesn’t support https:// protocol.
• The configuration username is “admin”. Default password is “”. Get IP configured on the printer, pull up the web interface, and change it–ASAP! (Ideally you would set the password on a private network, before putting it on the Internets. Not that it’ll do you much good–see previous note.) I’ve seen a pretty gnarly security exploit for Kyocera printers, which seems to bypass what little security is available, but I haven’t tested it on our unit yet.
• The printer supports Bonjour protocol, although it doesn’t seem to be a “real” PostScript printer. (My Mac sees it as a “Generic PostScript” device.)
• The EP510DN PPD file is available for *nix operating systems. I’m still looking for a Mac driver for this printer.

I don’t know if we’ll keep this printer or send it back. The print speed is definitely nice, and print quality seems alright. I’m a bit disturbed about all the network services that this printer provides, without securing them in any meaningful way. I’ll try out the cracking suggestion above and see if this model is vulnerable.