How to change timezone from command line in Ubuntu
sudo dpkg-reconfigure tzdata
sudo dpkg-reconfigure tzdata
If not specified the PHP5 session files will be located in a directory like /var/lib/php5 and the builtin garbage collection will delete them, normally after 24 hours.
But often systems like CMS:es will put session files somewhere else and if the system doesn’t have it’s own garbage collection those session files will be kept forever. The reason can be to let a website visitor click “keep me logged in” or to remember a visitors preferences on the website. This normally doesn’t impose a problem as these session files are very small and the number of them counts in hundreds or possibly a couple of thousand files.
However, I encountered a site that created a very large number of session files and kept them forever. At some point the session files count was in the range of millions of files causing the system to run out of inodes. A solution could be to investigate how the system was handling session files but the internal workings of the site was outside of my responsibility. Another solution was to increase inodes but this will be a temporary solution.
The solution chosen was to create a garbage collection routine for the site in question, that deleted session files older than x days. The oldest session files was over 4 years old. The decision was to delete all session files older than a month (30 days), causing visitors who logged in, or had their preferences set, for more than a month ago had to re-login or set their preferences again on their next visit to the site. This was accomplished by the following command (which is run by cron every night):
find /var/www/somedomain.com/web/var/session/ -type f -mtime +30 -exec rm {} \;
On Ubuntu 14.04 LTS:
apt-get install php5-imap
php5enmod imap
service apache2 reload
If you put a script to be run by cron in cron.hourly, cron.daily, cron.weekly or cron.monthly but they won’t run, make sure that they:
You can also execute the command to verify that your script will be run:
run-parts –test /etc/cron.daily
I used FormMail.pl from Matt’s Script Archive on one of my web sites and called this script from several other web sites. This way I only need to maintain one copy of the script regarding updates.
The script began complaining about “Bad referrer” when called from my other sites, even though I could positively verify that the other site’s domain name was present in the referrers of FormMail.pl.
Not finding the problem in the script itself I began to think over what I had recently changed on the site hosting the FormMail.pl and one thing was that I recently added a http redirect any incoming calls that didn’t go to the site url using https and I also redirected www.sitename to just sitename. For example, a call to http://www.sitename was redirected to https://sitename using Apache’s http rewrite module.
On my other sites using the FormMail.pl script from the main site, I was calling the FormMail.pl using a url beginning with http://www, i.e. the call was redirected by http redirect rules. When changing the url to call the FormMail.pl script to https://sitename (i.e. using SSL and no www), the call would not be touched by http redirect rules and voila – everything was working again.
Upgrading a system running Ispconfig3 on Ubuntu 12.04 (LTS) to 14.04 is quite straight forward. However there are some issues to consider before doing so. It might affect some of the sites that are being hosted.
Upgrade procedure:
apt-get install sasl2-bin
/etc/init.d/saslauthd start
service amavis restart
service postfix restart
#smtpd_sasl_path = private/auth
#smtpd_sasl_type = dovecot
service postfix restart
When setting up a website in Ispconfig3 I wanted to run a cron job (shell script) for the site (setup under Sites -> Cron jobs) but the job did not execute. When examining the /var/log/auth.log I found lines like these:
Mar 22 10:31:01 servername jk_chrootsh[28726]: abort, homedir ‘/var/www/clients/client6/web284’ for user web284 (5015) does not contain the jail separator <jail>/./<home>
Mar 22 10:31:01 servername jk_chrootsh[28725]: abort, homedir ‘/var/www/clients/client1/web283’ for user web283 (5014) does not contain the jail separator <jail>/./<home>
Some week ago FileZilla released a new version – 3.10.0.1. After installing this version some clients had problems connecting with their web hosting servers using FTP. One of the changes in FileZilla was that it now defaults to TLS encrypted connections if the server supports it, which many web hosting providers do.
However, if the FTP server is not properly configured together with it’s firewall the client will connect but fail to retrieve the directory listing (timeout).
A workaround on the client side is to connect with plain old FTP using no encryption. To do this in the later versions of FileZilla you must create a connection in the site manager and select plain FTP (unsecure) in the encryption field. (This option is not availible in the quick connect.)
A better solution is to solve the problem on the server side. To do this the FTP server must be configured to use a specific range of ports for passive mode and allowing traffic to them through the server firewall. The example below shows how to do this with pure-ftpd and iptables. In the example we setup pure-ftpd to use ports 50000-55000 for passive transfers and then we allow the same range in iptables.
echo “50000 55000” > /etc/pure-ftpd/conf/PassivePortRange
/etc/init.d/pure-ftpd restart
Then add the following to your iptables rules and reload them:
iptables -I INPUT -p tcp -m tcp –dport 50000:55000 -j ACCEPT
A client was going to stop using Microsoft Outlook and Exchange server and move their email to an ordinary web hosting company using IMAP. The client was downscaling and had no use of the benefits of Microsoft Exchange like shared contacts and calendars. They where just using it for email which could be obtained much cheaper by using the IMAP account at their web hosting provider.
So I was faced with the task of converting their old email contained in PST files. They had already shut down their Exchange server and I could not use the Outlook program. I just had the PST files that where exported before the server shutdown and needed them imported into the IMAP account without using Outlook as it was not availible for me.
This is how I solved it.
Tools used: