Category Archives: php

PHP IPAM installation issues and how to fix or avoid them

The issues I had was during the install process were with broken CSS, a jQuery error, a couple missing PHP modules, broken Captcha images and unusable complex passwords.

The broken CSS and jQuery errors were a result of my client’s web server SSLSessionCache configuration was incorrect (missing) and their intermediate certificate was also corrupt. I fixed both of these issues and it fixed the CSS and jQuery errors. If you have these issues, it isn’t likely an PHPIPAM problem, but a problem with your server config.

The second issue was post install:

Warning: file(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in functions/classes/class.Tools.php on line 1694

The very simple fix for this is to make sure the PHP curl module is installed. It’s not listed as a required module on the PHP IPAM installation guide, but it definitely is.

In addition, my Captcha images were broken. I had GD installed, but I didn’t have the PHP GD module installed. Easily fixed by installing the PHP GD module and a quick web server restart.

Finally, if you are like me and use ridiculously complex passwords generated by a cloud-based secret server, such as Encryptr, LastPass, Thycotic, 1Password, etc, it should be noted that while you can use a password up to 128 characters long, per the DB schema, you cannot use special characters, or at least some special characters. I had to use the ‘functions/scripts/reset-admin-password.php’ feature a few times. When using an invalid password you are not provided with any warnings; it simply accepts it, so this issue may not be obvious at first.

All these issues are trivial and easily fixed or circumvented. The PHPIPAM software is amazing and please do not let this post discourage you from installing it.

Update: I found another PHP module that is required post-installation that isn’t mentioned on the PHP IPAM website, which is the ctype module. It addresses this issue:

Fatal error: Call to undefined function ctype_digit() in functions/PEAR/Net/IPv4.php on line 242

PHP’s date.timezone setting and date_default_timezone_set function

In newer versions of PHP, you are required to set the system’s timezone. If you’ve encountered either of the errors below, or something like them, you need to do this.

Warning: 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 the timezone 'UTC' for now, but please set date.timezone to select your timezone.
Warning: strtotime(): 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 the timezone 'UTC' for now, but please set date.timezone to select your timezone.

To do it server-wide, simply edit your php.ini file. If you are not sure where it is, use locate -i php.ini to find it.

Uncomment the following line and set it to your desired timezone:

;date.timezone =

I am on the West Coast of Canada, so I set mine to Vancouver:

date.timezone = America/Vancouver

You will need to restart your web server after making changes to the php.ini file.

If you want to set it on a single file, or override the global settings, you can use the date_default_timezone_set() function:




If you are using FreeBSD, here’s a list of timezones:

Setting your timezone in FreeBSD

Updating OpenSSL for Apache without breaking your base OpenSSL install on FreeBSD 9.2-RELEASE

After two very frustrating days, I have finally been able to perform what used to be a fairly routine thing for me, which is creating a FAMP server using FreeBSD, Apache 2.2.x, MySQL 5.x.x and PHP 5.5.x.

Several issues arose out of my attempts.

My first attempt was installing Apache 2.4.9, MySQL 5.6.17 and PHP 5.5.12 on FreeBSD 10.0-RELEASE-p3 (AMD64). This was my first time installing anything greater than MySQL 5.1.x. ‘./configure’ has been replaced with ‘cmake .’; other than that, all things ordinary. This was also my first time installing Apache 2.4.x and there are several new steps involved. The first is that you now have to manually install Apache’s portable runtime library and associated utilities. Piece of cake. Grabbed those from the APR website and installed without issue. Apache installed. But now the trouble. I was able to ‘./configure’ and ‘make’ PHP without issue, but during the ‘make install’ I ran into an issue.

# make install
Installing PHP SAPI module: apache2handler
/usr/local/httpd/build/ SH_LIBTOOL='/usr/local/apr/build-1/libtool' /usr/local/httpd/modules
/usr/local/apr/build-1/libtool --mode=install cp /usr/local/httpd/modules/
libtool: install: cp .libs/libphp5.lai /usr/local/httpd/modules/
libtool: install: cp .libs/libphp5.a /usr/local/httpd/modules/libphp5.a
libtool: install: chmod 644 /usr/local/httpd/modules/libphp5.a
libtool: install: ranlib /usr/local/httpd/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.5.5/libs'
Warning! dlname not found in /usr/local/httpd/modules/
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/httpd/modules/
chmod: /usr/local/httpd/modules/ No such file or directory
apxs:Error: Command failed with rc=65536

Keep in mind, this was a brand new, entirely fresh FreeBSD 10.0-RELEASE install with ‘freebsd-update’ run bringing it to -p3. Nothing else had been done on this box except the MySQL and Apache installs.

I found it very strange that in that small bunch of code, two separate libtools were referenced. Foolishly, I didn’t check my working server to compare. In any case, ‘/usr/local/apr/build-1/libtool’ and the libtool included with the PHP source were both referenced. For good measure, I even installed libtool using ‘pkg install’. Nothing worked and failed to be created. Not being a software developer, I went to Google looking for the answer but came up short. A few suggestions were to use the .bz2 version instead of the .tgz version, use ports and one person even pointed the finger at the AMD64 build of FreeBSD. I briefly attempted to install a known working version of from another one of my servers but that just created more issues. I moved on.

I reloaded the OS from scratch and tried again. Same result. I’m a sucker for punishment.

I then reinstalled the OS using FreeBSD 9.2-RELEASE. As before, I ran ‘freebsd-update’ first thing and brought it up to -6p. I compiled MySQL using the new steps I had learned earlier. Same with Apache, except I used 2.2.27 this time to simplify things; go with what you know. Then the true test, PHP 5.5.12, which also installed no problem. Added a few times to httpd.conf and started the server. Problem. I telneted to port 80 to see what version or OpenSSL I was using and it came back as 0.9.8y. This version isn’t vulnerable to the heartbleed vulnerability, but it does lack TLSv1.1 and TLSv1.2 support, which I need, if only to give my clients a greater sense of security. So I search Google for “freebsd upgrade openssl” and a few articles come up, including one I had recently visited. I went back, performed the needful using ports and OpenSSL was upgraded. Sort of. The base OpenSSL install has its binaries in /usr/bin, libraries in /usr/lib and config file in /etc. The port install puts the binaries in /usr/local/bin, the libraries in /usr/local/lib and the config file in /usr/local/etc/ssl. So I have two completely autonomous OpenSSL installs at this point. Typing ‘which openssl’ shows /usr/bin/openssl which is version 0.9.8y. ‘/usr/local/bin/openssl version’ shows 1.0.1g. Again, 0.9.8y is not vulnerable to heartbleed, but it is insufficient for my needs. After further reading, a few people suggested to remove the old binary and symlink /usr/local/bin/openssl to /usr/bin/openssl and also symlink the configuration files. This seemed to work, so I rebuilt Apache again thinking that version 1.0.1g would show up. But it didn’t. Knowing that this was a new install and that I would probably blow it away once I found a working formula, I started deleting things, symlinking things, moving things, etc. I reminded myself of my father-in-law who while looking to free up space on his internal HDD, he deleted his windows system files with the rational of “I’ve never used those, I can delete them.” A mess I made. Server trashed. Blank slate.

Again, I started with FreeBSD 9.2-RELEASE. I immediately updated using freebsd-update to -p6. I then downloaded and installed OpenSSL 1.0.1g from the OpenSSL website. I then confirmed that my base and secondary install were as expected:

# /usr/bin/openssl version         
OpenSSL 0.9.8y 5 Feb 2013


# /usr/local/ssl/bin/openssl version
OpenSSL 1.0.1g 7 Apr 2014


When it came to compiling Apache, I had to compile mod_ssl as a static module. In the process, a few of the core modules were also made static, so I had a mishmash of static and dynamic. I had to comment out a few of the LoadModule statements in the httpd.conf, but in the end, everything works as it should.

[root@server01 ~]# telnet localhost 80
Connected to localhost.
Escape character is '^]'.
HTTP/1.1 / GET

HTTP/1.1 501 Method Not Implemented
Date: Wed, 28 May 2014 23:07:36 GMT
Server: Apache/2.2.27 (Unix) DAV/2 PHP/5.5.12 mod_ssl/2.2.27 OpenSSL/1.0.1g
Content-Length: 220
Connection: close
Content-Type: text/html; charset=iso-8859-1

Success! I now have a server running exactly the way I want and I have no compromised any of the base OpenSSL files, or anything that was built against them. While I think this was a fairly good way to accomplish this task, there are probably even better ways to do it. However, my Googling efforts did not lead me to those.

Another other method, which some will say is more elegant, would have been to install from pkg or ports. However, I disagree. Since I compiled my first web server twenty years ago to present day, I have always been an advocate of compiling critical services from source. If all you ever do is type ‘pkg install apache22’ how do you learn to troubleshoot when something goes wrong? How do you know how to fine tune your installation when you need to compile in sockets, or curl, or other libraries and modules? I prefer infinite control.