Kim's Adventures into Geekspace

To content | To menu | To search

Tuesday, October 22 2013

Postgres.app, PHP and Mavericks

Update 10 November 2013: after updating Mavericks from GM to build 13A603, everything broke again. After recompiling like specified below nothing was working and there may have been a missing path somewhere in the php.ini-file. While tracking the error down, I stumbled over a new version of PHP with a one-line install on http://www.coolestguidesontheplanet.com. I decided on 5.5 while I was at it.:

easy PHP 5.5-installation

Just running the installation command, a curl, the postgres-connection was working again, even from a non-standard postgres-installation. Thumbs up.

--

I updated a few of my computers to Mac OS X 10.9 Mavericks. Everything went fine, or so I thought until my wife complained about a missing blog. I happen to run this blog on Dotclear using a Postgres.app-database. Dotclear is of course using php and Apache.

Soon it was clear that the good folks at Apple have dropped support for Postgres in their php-configuration, so what to do. But I found this rather helpful page:

http://blog.rupey.org/post/63221360055/adding-postgres-support-to-php-on-os-x-mavericks

It was not perfect though, as a few steps were a bit shorthanded: installing autoconf from brew for instance, but that was fairly easy after a bit of googling, so I won’t repeat those steps here. See here, if you like.

I think that Rupey gets it very right for the rest, that is if you have Postgres installed by hand, i.e. that it is comfortably sitting in /usr/local/pgsql/ or similar. Given that I had used the app-version - much simpler to install and run - I had to point the configuration to the right directory. So when doing this

cd ext/pdo_pgsql

phpize

./configure

I ended up with this error:

checking for pg_config... not found

configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path

To point out the right installation path I just had to do this:

./configure --with-pdo-pgsql=/Applications/Postgres.app/Contents/MacOS/bin

before doing the rest:

make

sudo make install

and finally adding extension=pdo_pgsql.so to /etc/php.ini (and changing the time zone) and doing a sudo httpd -k graceful to make php work with Postgres again. Sorry for the downtime, btw.

Sunday, August 25 2013

Gmail in turmoil

A user had a Macbook Air 1st generation that was extremely slow. Two people had already had a look and had even installed a fan control app, as they thought the Mac was breaking down and needed a physical check of the fans.

The problem was related to Mail, and when checking the Console, nothing showed up, i.e. no log files were showing at all. Running Yasu from Jim Mitchell resolved the first permission related issue that would also have been resolved using Disk Utility.

The second problem was due to a mail that the user tried to send from her Gmail account using Mail on Mac OS X 10.5.8. The mail only consisted of a file, but it was iTunes.app that apparently was 170 MB. Gmail refused to acknowledge it and gave this error (in Danish): Billede 1.png

Basically, because of the size of the mail, Gmail decided not to save the draft as it was way too big, and Mail didn't understand the error message correctly and thought it was because Gmail was offline and hence it tried to save the mail to drafts to be synchronized at the next possibility, probably resulting in another similar error leaving more and more files in the drafts folder each of 170 MB.

The problem was then, that if you tried to delete the draft, it would run into the same problem and move the deleted mail - to drafts, so in total about a 100 mails were generated this way, one each time the process would stop and the mail again was saved wrongly and using far too much of the capacity of the machine, the network and the Macbook Air became slower and slower.

The fix was as follows:

1) Turning off "Keep drafts on the Server" and "Keep Trash on the Server"

2) Patiently manually deleting the offending mail from the file system - files would keep appearing for another 15 minutes or so…

3) Rebuilding the mailboxes (Menu Mailboxes->Rebuild)

4) Turning  "Keep drafts on the Server" and "Keep Trash on the Server" on again.

I don't know if this problem persists in later versions of Mail, I have never seen the behavior before, but it definitely didn't look nice in 10.5.8.

Tuesday, August 13 2013

Gmail-disturbance!

The wife of a friend of mine had a problem. Sending emails from her iPad would change the sender from something like "wife<wife@owndomain.dk>" to something like: "wife<husband@gmail.com>". This was of course frustrating like hell, as responses to her emails were sent to her husband, even though the recipients saw her name in the email applications. She had no problems with sending correctly from her Mac or iPhone. They had already checked the SMTP-address - repeatedly - so it was a mystery.

To fix this, I checked the SMTP-server list, i.e. Outgoing mail servers. There were a number of servers listed, as the iPad had belonged to the husband, but the correct SMTP-server of the "wife@owndomain.dk" was present. Also present was a Gmail-SMTP-entry, with the husbands login credentials.

The culprit was that there was no password for the login credentials for the correct SMTP-server, so we set that, and removed the gmail-entries. This resolved the issue. The last part was not necessary, but just to be sure the problem will not come again.

My analysis is that the original SMTP-server somehow was unavailable and that Mail on the iPad had (wrongly) asked for the correct password instead of recognizing the offline situation. Handling this error, the wife had somehow deleted the password. Doing this is too easy, Apple! Then the failover for Mail was of course to take the next SMTP-server on the list, and here Gmail does something very strange. It leaves the name of the sender "Wife" but changes the email-address to be the one of the account sending it, so wife@owndomain.dk becomes wife<husband@gmail.com>. Not smart either.

The fix worked, btw.

- page 2 of 5 -