php init_set session gc_maxlifetime doesn't work (solution VPS)

I had problems with changing the max session lifetime as it didn't work by just writing this to my php code:

ini_set('session.gc_maxlifetime', 8*60*60);
ini_set('session.cookie_lifetime', 8*60*60);

My goal was to set the session lifetime to 8 hours (8*60*60 = 28800 seconds). Still the sessions was destroyed after 1 hour or 3600 seconds. 3600 seconds is my default session gc_maxlifetime setting in php.ini ( /etc/php5/apache2/php.ini Ubuntu 14.04 ) and the default is 1440 seconds.
I confirmed that the parameter was actually changed with

ini_get('session.cookie_lifetime');

And yes. It was set to 28800 seconds. So what then if I could change the session.cookie_lifetime but it still doesn't work?

The problem was not anything with my settings. But with the default settings of how the system handles the garbage collection for the sessions that is stored on the server. There is a cron job that runs every X minute and a bash script that wipes out the old session, where the sessions are stored and based on the value set in the php.ini file, not the manual configuration I'm setting in my script.

So as long as I don't specify another save path for the session files, the default handler for the garbage collection will wipe those out.

One solution for this is to save the php sessions in another path:

ini_set('session.save_path', getcwd().'/../phpSessionStorage');

Now everything should work as expected. But one thing to keep in mind is that if you specify another save path for the php sessions then you need to remove all the old ones, some sort of garbage collector. There are different ways to handle this, maybe the easiest way is to use the session.gc_probability ( e.g. ini_set('session.gc_probability', 1) ) but I wrote a short command for my crontab to clear all the old ones that is older than 480 minutes ( 28800 seconds ).

0 * * * * find /var/www/websitefolder/phpSessionStorage -cmin +480 -type f -delete

As you can see, this cron job runs every hour and removes the old session files from the custom session folder.

So after all. My initial problem was never with a php-setting or apache but how Ubuntu-combined-with-php5 handles the garbage collector for the old php sessions.

Some tips when you'are having troubles with not getting the session.gc_maxlifetime to work.

1. Are you allowed to change the session.gc_maxlifetime with ini_set() function? Check your permissions and your php.ini if the function is maybe disabled ( disable_functions ).
2. All session settings must be declared before the session_start() function in your php-code. You can see if the session has been started with session_status() function.
3. Check with ini_get() function if your configuration with ini_set() is really applied.
4. What is wiping out the stored sessions if there are no configuration fault?

Read more about PHPs sessions configuration.

Solution to Knockd won't work / open port in iptables

I had a struggle to get Portknocking with knockd to work on my Ubuntu 14.04 VPS. I've read and followed a lot of instructions, Ubuntus instruction among these. But nothing seemed to help me out here.

I did check my knockd log located to /var/log/knockd.log and the configuration for activating the knockd commands seemed to work. But I always ended up with "command returned non-zero status code (a number)"

So what I figured out that it had to do something with the start_command and stop_command that didn't do the job correctly. Everywhere I could read that you were "supposed to" control the IP tables by having e.g.

start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

If it was say to open up the SSH-default port 22. But that didn't work for me.
The first I did was to check if /sbin/iptables even existed and it didn't. No wonder why nothing happen with my iptables configuration...

So one solution to this was for me to create two shell script to configure the iptables for me.
I created a knock-open.sh containing this.

#!/bin/sh 

iptables -I INPUT 1 -s $1 -p tcp -m tcp --dport 22 -j ACCEPT

Then I created a knock-close.sh:

#!/bin/sh

iptables -D INPUT -s $1 -p tcp -m tcp --dport 22 -j ACCEPT

And my knockd.conf-file (/etc/knockd.conf), I configured it like this:

[options] 

logfile = /var/log/knockd.log 

[SSH] 

sequence      = 1212:udp,3861:tcp,8721:udp 

seq_timeout   = 5 

tcpflags      = syn 

start_command = sh /var/scripts/knock-open.sh %IP% 

cmd_timeout   = 20 

stop_command  = sh /var/scripts/knock-close.sh %IP%

So this did the trick for me. After restarting the daemon (service knockd restart) and knocking the sequence ports, iptables was now configured correctly and working with knockd.

I hope this solution helps someone out there who's struggling with knockd and iptables.

Fix for rsyslog uses almost 100% CPU on OpenVZ system

If you ever get the problem with rsyslog for some reason use nearly 100% of the CPU all the time there may be some compatibility problem (probably a bug out of your control) with your system and rsyslog. Especially systems running on OpenVZ.

I had this problem with my VPS running Ubuntu 14.04.01 and on OpenVZ

A quick fix to prevent this for me was is to change the rsyslog.cnf-file by terminal:

sed -i -e 's/^\$ModLoad imklog/#\$ModLoad imklog/g' /etc/rsyslog.conf

You should restart the rsyslog-service to make the changes apply by:

service rsyslog stop
service rsyslog start

I hope this solve the problem for you.

Config logrotate for apache log-files in "www"-directory or in other non-standard

If you have configured Apache to split error and access logs for each virtual server or configured website. Then logrotate wont rotate those log-files in their custom locations with standard configs. Logrotate comes normally installed with your distribution and is configured to rotate the apache log files that is located in /var/logs/apache2.

But if you have several websites running on your VPS or server, it's linkley you have a seperate log file for each website that you have configured and the logging wont be in the standard location.

As an example. I've several websites running under a structure of "/var/www/$NAMEOFTHEWEBSITE". Now each website has separate logging, in a structure like this  "/var/www/$NAMEOFTHEWEBSITE/logs". In each logs-directory I've a access.log, error.log and a php-error.log. If I want to rotate these with logrotate I need to configure logrotate for that.

This is done by creating another config file for my custom directories.

vim /etc/logrotate.d/www

Then with this configuration:
/var/www/*/logs/*.log { 
weekly
missingok
rotate 26
compress
delaycompress
dateext
notifempty
create 640 root adm
sharedscripts
postrotate
if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ];

then /etc/init.d/apache2 reload > /dev/null fi 
endscript
}

My configuration does this:

• For each and any .log-file in /var/www/*/logs/
• Do weekly rotation. (weekly)
• If  log-file is missing, ignore without error message (missingok)
• Rotate for 26 weeks (rotate 26)
• Compress all log-files (compress)
• Delay compression with one time (delaycompress)
• Name the rotated files with a date-based name so it's easier for me to know where to look (dateext)
• Do not rotate if log-file is empty (notifempty)
• Owner and permission settings for rotated file (create 640 root adm)
• Normally, prescript and postscript scripts are run for each log which is rotated, meaning that a single script may be run multiple times for log file entries which match multiple files (such as the /var/log/news/* example). If sharedscript is specified, the scripts are only run once, no matter how many logs match the wildcarded pattern. However, if none of the logs in the pattern require rotating, the scripts will not be run at all. This option overrides the nosharedscripts option and implies create option. (sharedscripts)
• The lines between postrotate and endscript (both of which must appear on lines by themselves) are executed after the log file is rotated. These directives may only appear inside of a log file definition. (postrotate & endscript)

That's it. I hope it helps you out configuring your vps or server with the very useful logrotate.

Apt-get problems and Temporary failure resolving 'us.archive.ubuntu.com'

Experience problems when trying to install or running update with apt-get in Linux, Ubuntu or other distributions?

When running ie. apt-get update you may get error message like:

Temporary failure resolving 'us.archive.ubuntu.com'
Temporary failure resolving 'archive.ubuntu.com'

Err http://archive.ubuntu.com lucid Release.gpg Temporary failure resolving 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/lucid/main/i18n/Translation-en_US.lzma Temporary failure resolving 'archive.ubuntu.com'

The problem is that apt-get can't reach the destination files for some reasons.

One possible answer to this problem is that this is an temporary problem because the servers are not available for the moment.
You may also want to check your source.list @ /etc/apt/sources.list

One possible solution for this problem is to check your iptables configuration so you aren't blocking outgoing connection that are needed to be reached.

I solved the "Temporary failure resolving", apt-get failure on my VPS by adding "-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT" into my iptables configuration.

So making sure that this below are added to your iptables configuration can help and solve the Temporary failure resolving issue.

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT