Solution for Docker in WSL and connection problems for Vscode running Remote-Container cmds

Have you already set up an machine running on WSL version 2 with Docker and is about to run and set up your project in an remote container from vscode but can't connect to Docker from Visual Studio Code?

You might encounter errors in Vscode when running Remote-Container: Opening folder in container like these or similar.

error during connect: Get http://localhost:2375/v1.40/version: dial tcp [::1]:2375
ECONNREFUSED 127.0.0.1:2375

Even though you have set up environment variable DOCKER_HOST to "tcp://localhost:2375" and confirmed that the communication works to the Docker server from the terminal/cmd/shell?

Then you might need to change the environment variable of DOCKER_HOST to the actual IP-adress of the WSL machine running the docker server. At least if you want VsCode to be able to run the containers with docker.

You'll find the IP adress of your machine by running i.e. this command from a windows terminal:

wsl.exe -d CHANGE_THIS_TO_YOUR_DIST_NAME /bin/bash -c "ip addr show eth0 | grep 'inet\b' | awk '{print $2}' | cut -d/ -f1"

CHANGE_THIS_TO_YOUR_DIST_NAME could be Ubuntu-16.04 or Ubuntu-18.04 or any other OS you've installed.
Copy the IP-adress and update DOCKER_HOST with the actual IP of the WSL machine. Close down vscode and open again to refresh the env-variables. Vscode should now be able to run the docker commands.

Remember to update the IP-adress in your DOCKER_HOST environment variable when you restart windows and since your virtual machine in WSL doesn't have a static IP, yet. See this issue about WSL dynamic and missing static IP-config

Tip! Guide for setting up WSL2 with Docker server in Windows.

"Join.me" free alternative - Best one alternative

Looking for an Join.me alternative since they have no free plans since june 2019?

9€ or $10 might not be much to pay per month for a fantastic and painless share screen meeting product but if you are hosting meetings very rarely, it might not attract you to buy one month for one simple meeting.

My searching for another solution led me to the Zoom product as an alternative to Join Me. Zoom offers a basic plan which is free and allows you to host unlimited meetings, share screen, webcam, recordings, plan meetings etc. A lot of more functionality than Join.me has to offer, and for Free.

Joining a meeting with Zoom in default settings, forces you to download their application but there is an setting in your account where you can make meetings available in the browser without the need to download and install the Zoom application.

My findings is that Zoom is a powerful solutions for online meetings and the best free alternative to Join.me without any download and install hassle.

Pricing and plans comparison

Join.Me plans

Zoom.Us plans

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.