If you are using the password option for the tentacle protocol then you must also add the password to the TENTACLE_EXT_OPTS in the /etc/init.d/tentacle_serverd file e.g.
TENTACLE_EXT_OPTS=”-x YOURAGENTPASSWORD …
If you do not do this then if you are using the agent password option then no agent data will be logged.
This is not a very secure way of data logging.
Mailfilter POP timestamp in message-ID invalid and potentially also causes mailfilter to stall at 100% CPU.
I have a fetchmail daemon that call mailfilter as a postconnect (defined in the .fetchmailrc file). I got the following error message,
mailfilter: Examining 297 message(s).
mailfilter: Error: POP timestamp in message-ID invalid. mailfilter: Error: Parsing the header of message 292 failed. mailfilter: Error: Scanning of mail account failed. mailfilter: Error: Skipping account xxxxxx@example.com@mail.example.com due to earlier errors.
and I noticed that the mailfilter process was running at 100% CPU though that may be unrelated.
I found that mailfilter 0.8.3 has a new option of -i to ignore POP timestamp. This is probably what I want to make this more stable.
As I’m adding this to a Parallels based server it is unlikely to have this version of mailfilter as this package has very little development activity as it is a stable application so I had to build from source.
My server didn’t have svn so I browsed the Sourceforge svn for mailfilter on my local PC and at the bottom there is a linkfor “Download GNU tarball” I copied that link and then pasted into my console and used wget to get this latest tarball from Sourceforge. It has a odd name so moved that to a tar.gz file name e.g. mv index.html\?view\=tar mailfilter.0.8.3.tar.gz and then ran tar xvfz mailfilter.0.8.3.tar.gz
Perquisite packages for building,
There may be more but that is the ones I needed to add to my server.
Making this you cd to the mailfilter directory and then run
./autogen.sh make sudo make install
If that works then this’ll probably install the mailfilter to /usr/local/bin/mailfilter so now in the .fetchmailrc change the postconnect line to have,
postconnect ''/usr/local/bin/mailfilter -i ''
use double quotes if you pass the new -i option to ignore timestamps. The -i is a new feature in Mailfilter 0.8.3 (not in 0.8.2).
Killall the mailfilter and fetchmail and then re-launch your fetchmail daemon.
Errors
Missing g++
If you see,
checking whether the C++ compiler works... no configure: error: in `/root/sources/mailfilter': configure: error: C++ compiler cannot create executables See `config.log' for more details.
Then check the log file and look for g++ line e.g.
configure:2879: checking for g++ configure:2909: result: no
Do a g++ and if it comes back with -bash: g++: command not found then install the g++ package and then it will work. Re-run the ./autogen.sh and then make
Missing bison
If you get the make fail and you can see /bin/sh: yacc: command not found then you need a YACC of some kind. I installed bison re-run the ./autogen.sh and then make
Missing flex
If you get an error in the make e.g. it crashes out with g++: rcfile.cc: No such file or directory
g++: no input files make[2]: *** [rcfile.o] Error 1
then check back and see if you see error: FlexLexer.h: No such file or directory . If so then check flex is installed. Install and then re-run ./autogen.sh and then make
Missing openssl header files
If you see openssl/ssl.h: No such file or directory and similar openssl/rand.h: No such file or directory then you need to install libssl-dev. Install that package and then re-run ./autogen.sh and then make.
After a month and a few weeks of use it has been stable. The erroneous timestamps are also suspected to stall Outlook 2003. I pick up emails in parallel to my customer to provide emergency support when they are on holiday. As Microsoft support for both XP and Office 2003 is finishing in April 2014 I plan to migrate the customer to a newer OS and Office version.
This may happen to you in that web pages for anonymous users (i.e. not logged on) stay stale even when you use “Delete Cache” in WordPress dashboard and clear the data from your browser. The page contents stay stale and menus (if they were changed) stay on the old layout.
If this happens to you and you are pulling your hair out in testing and unable to get the pages to display on the new content then ssh into your server and check the permissions (ownership) of the /wp-content/cache is actually owned by the web server and has not been changed..
After a Plesk/Parallels upgrade (automatic I think) the user that Apache ran in changed and this meant that files that were previously created by Apache using the old user account were now not able to be deleted by the new Apache account user (www-data). This is probably never going to be seen on shared hosting but could be seen on virtual or dedicated servers.
The WordPress site would have kept dishing out the old file not matter what I did because the old cache files couldn’t be deleted.
The fix is easy (assuming your Apache installation is going to remain stable) and that is to ssh shell into your account and delete using the file owner (or root) the contents of the /wp-content/cache directory (which will have a “meta” and supercache” subdirectories.
You may also be able to use your FTP client to do the same but probably the cache directory won’t actually be visible at all.
Once you have deleted all of that old stuff then go back into the wp-super-cache plugin settings and remove and then re-enable the cache settings.
Non-logged on browsers will now correctly display the site and the supercache/www.example.com/… files correctly build up with the ownership being the Apache web server.
To test this I use Firefox and Opera: Firefox is logged in and Opera is used to display the web site as an anonymous user. Opera has a nice feature in Opera -> Settings -> Delete private data that you can quickly clear the browser cache of everything.
On a new server you may find that you cannot upload images and it fails with an error,
Unable to create directory /var/www/path/to/your/httpdocs/wp-content/uploads/2011/06. Is its parent directory writable by the server?
This is because of permissions in that the apache web server can’t write to the wp-content/uploads folder.
The wp-content/uploads folder is defined by default in WordPress under the Settings -> Media and doesn’t need to change but you have to get the web server to be able to write to this location on the first day of use.
If you are using Filezilla or similar FTP Client you must set the file permissions of /wp-content to 777 then go into your post again and add the image. This should work now and if you look at the wp-content directory you will see a new uploads directory with the file permissions of 777 and owner and group will be the apache web server. Set the /wp-content back to 755.
You don’t need to do anything else. It will keep working from now on.
Obviously the issue of setting 777 on a directory when we’re usually told to not do this raises alarm bells so is this an issue ? On shared hosting it could be an issue. A malicious user on another account could get Apache to upload content to this directory and then hotlink to this content in SPAM emails or bogus web sites but if this is a server or virtual server that you control all the shared accounts then there is no real problem.
A good shared hosting company should have setup the Apache mod_suexec and suPHP module for the virtual host that you are using on the shared account system and you won’t have access to that.