RRWH

Simple! - APRS - Basically Packet Radio, RPi is used to decode then upload data to Internet. And at such low power usage it is perfect for remote/splar-powered installtion.

Yeah, Got a few RPi's 1 gets use as a media Server - XBMC connected to the NAS Does a great job. Still playing with one to use as a remote (solar powered) internet gateway for Ham Radio. Until the Pi it was simply not feasible to do this due to the power requirements to have something running all the time. Now at about 4W power it is very feasible. Have not used the GPIO pins for any control, but have thought about it - that is what Ardruino's are for - much lower power and quite simple code.

A 512M/1G Vswap openvz VPS running Nginx (centminmod) works very well. it runs in about 270Meg as we also installed an Imap server as well to handle email. It is a very weak CPU powering the node so not much needed here. OK, we don't really stress it either and we are planning on mirroring this setup and creating a HA cluster with another VPS of the same Specs.

Oops - just noticed that this was done before I updated - so version here was 3.0.1 - I will generate a new invoice to test with now We have updated to 3.0.2 and confirm if it is still present. Mike -> portal all works exactly as expected the only place that incorrect URL's have appeared is in the email. Edit : just tested again and all working fine... This might have been a 3.0.1 problem that was addressed (that will teach me to test more in the future)

In an email sent out when creating an invoice (from default email template for "Template Invoice Delivery (Unpaid) The URL is showing up as http://address.com/full/directory/path/to/the/file/index.php/client/ in the same e-mail, the {invoice.payment_url} is in the same way - it includes the http://address.com/full/directory/path/to/the/file/index.php/rest/of/url V3.0.2 Running on Nginx/php-fpm I have copies of the e-mail messages if it will assist and can provide further details if required.

This is the answer -> Create the order form. note the URL. Then edit the Portal page and select html (it is easier) Find the link to the Order section and add the full details of what your link actually is.

Just updated, no problems/ Suggestion: when you release a patch/update, would it be possible to put a quick note as to which components will need to be updated as well? EG, this time, I had to go to Plugins and update the Order System Plugin and also to the Modules and update the Universal Module. Maybe a quick summary so that we don't need to go looking at modules and plugins? I have identified a couple of bugs as well that I need to confirm as well - > will let you know once I have reviewed and re-tested.

Time for our own show-off! Been busy with our new site just a few things left to go (but when is a website ever finished....), Finally got our integration about 95% there - just need to sort out a few small things that will come in time. site - http://rrwh.com Blesta - https://support.rrwh.com/ Login as a client - demo@example.com / demodemo The bit you cannot see is that we put the "logged in as staff" on the same line as the "client Login / logged in navigation " A huge thanks to Mike for his tutorial - it was invaluable in getting this far.

After reading the excellent Site integration tutorial - I quickly came to realize that we can modify almost all aspects of the Site. WARNING WARNING WARNING - ALWAYS MAKE A BACKUP BEFORE MODIFYING ANY FILES There are a LOT of *pdt files within a blesta install, and the one you want to modify is usually pretty easy to find. From the doc root of your Blesta install, simply do the following # find . -name "*pdt" This will give you a list of ALL the PDT files used for the presentation of the site. Now, say you have a little specific mod you want to do (and yes) I did. The Mod I wanted to make was really quite simple - it is on the Support page. (Portal -> Support) We are setting up several Support departments - we only have a single Support department listed where you can raise a request without being logged in, all other departments you need to be logged in. As it is not obvious, we wanted to add a little bit of extra text to the page. First, look at the URL of the Page you are going to: https://yoursite/client/plugin/support_manager/client_tickets/departments/ next list ALL the pdt files so we can identify what we want to modify, we went looking thru the list for a file that was a close match to the page path. ./plugins/support_manager/views/default/client_tickets_departments.pdt looked to be a likely candidate for what we were trying to achieve. First thing, we make a backup of the original file, just in case we mess it up and can easily revert to the original # cp client_tickets_departments.pdt client_tickets_departments.pdt_orig Then with your favorite editor, modify the file. We wanted to add a very simple message to the page <div style="margin: 0 0 0 4em"><p><br />Existing Clients, Please login to see all Support departments</p></div> Well, we took a moment, looked over the code and found what appeared to be the place where we wanted to add the text to the page. <div class="heading first"> <h5><?php $this->_("ClientTickets.departments.heading_details");?></h5> </div> <div style="margin: 0 0 0 4em"><p><br />Existing Clients, Please login to see all Support departments</p></div> <div id="departments" class="pad"> Now, when you go to Portal -> Support you will see what we added (see the attached Image) - In this case, it was pretty east to see where within the pdt file we needed to make the addition. Pretty Simple! The Final Step - remember, if you do an update or install a newer version that your mods may be removed. You should also be keeping a document somewhere of what files you modify and exactly what you changed, so in the event that an upgrade replaces the file you modified, you can easily put your changes back in place - and of course, making a copy of the files you modified as well is probably a good idea as well. Looking forward to seeing some of the other customization's that everyone does.

Well, over the last day or so, I attempted to update some details and also add some packages. No matter what I did, It would just sit and wait, then finally push me to the public portal page after about 15 seconds without modifying the plan. Yes, it frustrated the heck out of me and finally, I realized that in the meantime, I had enabled the PHPIDS module. A quick look at the logs - and voila - I could see I was triggering it based on a large amount of post data - it was including the description and the email. Disabled PHPIDS, and I could actually modify and update the packages.

Been sorting out a few Nginx Issues as well - especially around forcing everything to use https If you need a hand generating your CSR and a self-signed cert for testing I think I have a guide somewhere as well. My stack where blesta is installed is a centminmod install, and then I just added a vhost where I installed Blesta in the root. My complete sanitized vhost config file is included for reference. server { server_name namegoeshere.com; access_log /path/to/access.log combined buffer=32k; error_log /path/to/error.log; root /path/to/docroot; listen 80; listen 443 default ssl; ssl on; ssl_certificate /path to/certificate.crt; ssl_certificate_key /path/to/ssl.key; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM; ssl_prefer_server_ciphers on; # Force All pages to use SSL if ($ssl_protocol = "") { rewrite ^ https://$server_name$request_uri? permanent; } location ~ (\.pdt) { return 403; } location / { error_page 404 = @blesta; log_not_found off; if ($request_uri ~ "^(.*)/install.php$"){ rewrite install.php /%1/install/ redirect; } } location @blesta { rewrite ^(.*)$ /index.php last; } include /path/to/php.conf; } Specific Issue that I had using the centminmod stack was I had to remove the included config file for staticfiles - it sets cache headers for several static files and was causing issues with the navigation in the admin panel (css). For fine-tuning, I will probably make a copy of this file and remove just the css stuff to keep it all as fast as possible.

better and will stop someone else having problems...

.... and a quick heads-up for anyone else that copies/pastes it - Just be careful to edit the URL's to the control panel - Be sure to include the correct tag! when I was testing, I didn't and you get the dreadful oops when you try and provision a service when there are wrong tags in the message! And thanks for the contribution - made a great start!.

Got it..... Found that php.ini had been configured to disable exec ! Might be worth adding to the install checks and noting that exec is required for the backups.

Mysqldump binary is in place. # which mysqldump /usr/bin/mysqldump I have configured SFTP access and verified it is working via the SFTP config page (test connection). Additionally, I grabbed the exact command being run from the /app/models/backup.php file and time ran it from the cmdline. time mysqldump --host="localhost" --user="xxx" --password="xxx" "xxx" >/tmp/sql_dump001 real 0m1.627s user 0m0.280s sys 0m0.093s # ll /tmp/sql* -rw-r--r-- 1 root root 4133568 Aug 29 09:55 /tmp/sql_dump001 A quick look at the contents of the dump file and it looks to be fine. Additionally, I took a look in the tmp dir and I can see an empty archive file in there that co-incides with each time I tried to manually run it.

Just looking at the backups and have a couple of Q's What is backed up by the built-in backup? Is it just the database or is it more? - such as the pdt files that are customized. Reason I am asking is that when I try and do an on demand backup, it times out and does not complete, guess that I will just have to wait until the backup runs and hope it completes. What sort of time does the on-demand backup take? When I try, it times out without completing - I guess I will need to extend the php execution time in order to complete the backup, but how long do I need to set it to?

correct - the ACL is all fine, but getting everything in the one place and automated saves a lot of effort when creating reseller accounts -and since the majority of our accounts are reseller accounts we want to simplify this as much as possible!. Maybe I need to add this as a module feature request for the CPanel Module!

Finally getting around to finalizing my Blesta config and I have hit a bit of a snag. When setting up a Reseller account there is nowhere to specify the Reseller resources - IE Total Disk and BW that they are allocated. If I missed this - please let me know where to set it up! This is not something that is configured within an ACL, that is applied to a reseller, but when I browse the CPanel API doco it looks like it is in another area and should be something that is configured. I would expect that this is additional options that I would see when you select Reseller - just like the ACL List, I would expect to be able to add any/all of the values available under the SetResellerLimits as per the API doco. http://docs.cpanel.net/twiki/bin/view/SoftwareDevelopmentKit/SetResellerLimits we don't want to have to log into the Server and manually set this up..... Help! as this is the last blocker for us to cut over to Using Blesta.

Checked the database and could see the value of theme_settings changing when I modify via the admin panel - so that is all working. It looks like it is.... and I was not aware of it. I did a brand new fresh install of an Nginx stack in a brand new VPS to do my install - I use Centminmond to do the stack install and just checked the configs - and found that it does the following (among other things) For the moment, I have removed the include from my vhost config to the staticfiles.conf location ~* \.(css)$ { #add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate"; access_log off; expires 30d; break; }

Well, I tried selecting several different themes - and regardless of which one I select, nothing changed, I get the "theme updated" message, refresh athe page and it remained the same colour.

tried on 3 computes and just did the 3.0.1 upgrade and still the same. Later on, I'll do a backup and replace the admin css with the copy from the last beta and see how it looks - as the css has changed since the beta and release in the app/views/admin/default folder from beta7, # ll *css total 140 drwxr-xr-x 2 root root 4096 Aug 2 14:25 admin_login -rw-r--r-- 1 root root 3293 Jul 21 2011 colorpicker.css -rw-r--r-- 1 root root 7965 Apr 18 14:35 css3.css -rw-r--r-- 1 root root 5515 Jul 18 2012 dashboard_calendar.css -rw-r--r-- 1 root root 2919 Nov 19 2012 datepicker.css -rw-r--r-- 1 root root 91 May 13 09:08 ie.css -rw-r--r-- 1 root root 859 Sep 24 2012 jquery.jrating.css -rw-r--r-- 1 root root 12302 Jul 2 2012 jquery.qtip.css -rw-r--r-- 1 root root 10055 Jun 18 2012 jquery.qtip.min.css -rw-r--r-- 1 root root 60884 Aug 2 13:53 layout.css -rw-r--r-- 1 root root 629 Sep 30 2011 reset.css -rw-r--r-- 1 root root 9297 May 13 09:53 theme.css the same folder from 3.0.1 ]# ll *css total 140 drwxr-xr-x 2 nginx nginx 4096 Aug 21 22:23 admin_login -rw-r--r-- 1 nginx nginx 3293 Aug 21 22:23 colorpicker.css -rw-r--r-- 1 nginx nginx 7965 Aug 21 22:23 css3.css -rw-r--r-- 1 nginx nginx 5515 Aug 21 22:23 dashboard_calendar.css -rw-r--r-- 1 nginx nginx 2919 Aug 21 22:23 datepicker.css -rw-r--r-- 1 nginx nginx 91 Aug 21 22:23 ie.css -rw-r--r-- 1 nginx nginx 859 Aug 21 22:23 jquery.jrating.css -rw-r--r-- 1 nginx nginx 12302 Aug 21 22:23 jquery.qtip.css -rw-r--r-- 1 nginx nginx 10055 Aug 21 22:23 jquery.qtip.min.css -rw-r--r-- 1 nginx nginx 61006 Aug 21 22:23 layout.css -rw-r--r-- 1 nginx nginx 629 Aug 21 22:23 reset.css -rw-r--r-- 1 nginx nginx 9297 Aug 21 22:23 theme.css Only file that has changed is layout.css - I'll copy it from my Dev (beta) version and test again later.

Went smooth! At what point are we going to be able to do the updates from within Blesta itself. At the moment, it is a bit of a pain as you have to be logged in, download the patch/package, upload it to the server, unzip, then run install. Can't wait until I can do this all from within Blesta itself and thus save a lot of time.

I decided to do a fresh install of V3 onto a brand new VPS running Nginx, rather than go with an upgrade of the Beta version. Since doing so, when logged into the admin panel I see all sorts of strange behaviour when I mouse-over the main nav items - it over-writes the next line down- the sub nav menu. Tried this with 3 different browsers (Ie9, Firefox and chrome) and get exactly the same result. - and just did it on another Computer as well. Anyone seen this behaviour? Screenshot, I simply did a mouse-over on billing, but the home (Dashboard/Calendar) says visible but is over-laid with the menu items for billing. I have not looked into the CSS to see if it has changed since the beta, but this is a bit annoying!

Makes me glad I never went with that particular software....

thanks! have had a little play and will certainly use this before going live (after release)