Stu

I also would love to be able to provision AWS Lightsail instances. I found this thread looking for exactly that.

Hi all, I was just curious as to what approach people take to handling their emails when it comes to small hosting companies. In all my online adventures I have always used an external service such as google and used mail forwarding and my own domain etc... But I'm wondering if I should now be looking at something different such as setting up my own mail server, or if that would introduce reliability concerns etc... How do you do yours? Thanks all

@samuel.hautcoeur who did you find? Are you happy with their work? I'd be interested to know, thanks

Hi Paul, yes at the moment it is a manual process. I am doing it exactly as you describe using a pool of internal IP's. Each internal IP corresponds to a port on a predefined list that I have already configured in my firewall. for example intenal IP allocated to the VPS = 10.0.0.10:3389 to access that as a customer they will connect to ExternalIP :2010 then 10.0.0.11:3389 = ExternalIP :2011 etc... I understand the module has no way of knowing how I have configured my port forwarding and the list of services each host could require is infinite so there can't be anything predefined built in that would suite everyone. I'm more asking how I could achieve sending the external IP and port in the provisioning email instead of the internal IP. Something like... if provisioned IP = 10.0.0.10 then send customer ExternalIP :2010 Some kind of table where I could enter IP and port forward would be great, is that doable? I imagine I would need to commission someone to make an addon for that, which is fine if its doable. failing that, is there another way to achieve it? Thanks for all your help everyone, I know this is an unusual way of doing things, but it suits my particular situation.

@Paul is probably well placed to know lol

yes but it can only provision with different IP's for each server. If I want to have a shared IP for all VPS's using different ports per VPS, how can I auto provision that?

Hi, I have a specific target for my VPS's and I want to use a single server IP and a pool of internal IP's. When provisioning the VPS is it possible to provide the customer with the main server IP and a Port? I have the everything working as I need it to be in terms of IP's, Ports, VPS's etc, but I am manually giving the customers the login details at the moment. Is there a way to automate the provisioning in this situation? I am currently using virtualizor, but with SolusVM being taken over recently I am hoping to one day switch back to that. Thanks for your help

To follow up on this, I've set nginx to pass everything to apache and it now works. So this is clearly nginx caching causing the behaviour. Thanks

Hi, I have tried to change both admin and client themes, but the changes are not taking affect. I am running Nginx infront of apache and blesta is in a subdir /portal My first thought is cache, so I deleted the Nginx cache folder, I cleared my browser cache, I purged cloudflares cache, but still no joy. Is there other caching going on somewhere in Blesta that I need to clear? When I select a new theme no colours change, but if I put a custom url to the logo that works. I'm missing something obvious I'm sure. Thanks

Hi All, I'm coming back to my blesta project again after a long time away. We are now on v4.2.2 and my previous method of getting blesta working on Nginx no longer appears to work. I have removed Blesta's .htaccess file from the Blesta root dir, now I'm redirected to this... https://mysite.com/blesta/index.php/install I think the fix for this used to be... Next, update /lib/init.php and make the following change: // define("HTACCESS", file_exists(ROOTWEBDIR . ".htaccess")); define("HTACCESS", true); but this line no longer appears in /lib/init.php so is there a new fix for this or is this no longer needed and I need to do something different or am I way off and have missed something else? Thanks all :)

HI, just coming back to my blesta project after a long time away from it. Is this tutorial still accurate for 4.2.0?

yeah I had similar before. Give the try_files way a go. It should make a noticable difference in speed. Using if statements and rewrites is slower because they are read and processed for each request.

Very useful addon and well coded. I wouldn't be without it.

Reissued the blesta_cms license and everything is fine again. Thanks for your help @cyandark and @Licensecart

oh oops forgot I had installed that, I thought I was still working on a clean blesta install lol. My bad, thanks guys

Blesta is informing me I have an invalid license... my server setup was nginx + php-fpm and everything was working fine. I have just added Varnish Cache and now this issue has appeared. My setup now goes like this... Incoming Https -> nginx -> varnish -> nginx -> php-fpm My original thought was that the origin IP wasnt getting passed through to the end and blesta was just reading the IP as 127.0.0.1. This was the case at first of course, but I have cured that by adding... unset req.http.X-Forwarded-For; set req.http.X-Forwarded-For = client.ip; and set_real_ip_from 127.0.0.1; and proxy_set_header X-Real-IP $remote_addr; all in the relevant places as necessary. I have confirmed the origin IP is correctly forwarded to the end by logging in with my test client and checking the geoIP shows the correct IP (it does) I re-issued my license but that didn't help. So I'm now stuck. Anyone know what else I can do to diagnose this issue? Thanks

Messed with this for a while after posting the question. I have come up with the following which seems to work.... location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; # fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # Deny all attempts to access hidden files # such as .htaccess, .htpasswd, .DS_Store (Mac). location ~ /\. { deny all; } # Disallow access to any file with .pdt extension location ~ (\.pdt) { return 403; } } If anyone wants to add to this please feel free to post.

Hi Guys, can some people show me their nginx configs for blesta? I had it working using the 'try_files $uri' way of doing things, but I reinatlled my server and forgot how I made it work before. I am currently using a method i found on here elsewhere (thanks to that poster), but I would like to get back to the 'try_files $uri' method as it was much cleaner and simpler. Here is what i'm currently using... location / { error_page 404 = @blesta; #IF file doesn't exist log_not_found off; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; # fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # Disallow access to any file with .pdt extension location ~ (\.pdt) { return 403; } if (!-e $request_filename){ rewrite ^(.*)$ /index.php; } #Core rewrite location @blesta { rewrite ^(.*)$/index.php/(.*) /$1 permanent; } } I remember before I was using something a lot simpler, something like... location / { try_files $uri $uri/ then the fastcgi_pass stuff

Well I couldn't figure this out, and the VPS was behaving a little strange in general so I deleted the server and created a totally new droplet. I completed the installation exactly as I had done before and now everything is fine and working great. Its perfectly possible that I missed something the first time round, I really dont think I did, but its possible. Anyway, all working now Thanks for your help guys

Thanks for the tips guys. I did indeed upgrade to a 1GB droplet.

yep you're right, access denied. very strange, I set things up the same as before (well obviously not lol) I'll figure it out and post back here for others when i figure out what I did wrong thanks for the tip

Ive probably done something stupid, but I dont know what. I reinstalled my server and blesta and its displaying as per the pic below

My test server is also a digital ocean but 512mb

looks like I ran out of memory on my low budget test server and mariadb crashed. Restarted it and everything is fine. How much memory do you recommend for a live production blesta install?

I have just managed to configure blesta and solusVM together and blesta has just provisioned its first openVZ VM to my test client. I am using Blesta 4.0 and SolusVM v1.18.06 Blesta provisioned it, SolusVM has created it and my test client received the confirmation email. As soon as I received the email blesta became unusable. I was logged in as a client on one screen and admin on the other screen, I refreshed both and all there is now is a blank white screen on both. I turned on error reporting and it shows... SQLSTATE[HY000] [2002] Connection refused whats happened?