JaxSite

Thanks for the feedback. I'll check on /dev/urandom and watch the logs over the next few days. Now that I'm past this issue, everything else seems to be working. It was a smooth migration overall. Next on my list is to upgrade to the latest version. ?

Ok I've fixed my issue so I thought I would share in case anyone else runs into a similar issue. PHP's open_basedir was blocking those directories from being seen. I read that on several other blog posts but when I checked my php.ini file, that value wasn't even set. I'm running HestiaCP with Nginx + PHP-FPM. Apparently, there's an additional pool file created per domain located at /etc/php/7.x/fpm/pool.d/yourdomain.com.conf that was setting it. I simply updated it to include the directories and now they are writable as should be.

I've moved the directories up 2 levels. They have same user/group and permissions. I've even added some test code to write a file to the 3 directories. The tmp directory works and the other 2 fail. I am clueless as to why PHP is treating these other 2 folders differently. The user/group "jaxsite" on this server has id of 1003 where on the other server the id was 1004. Is there some code or settings in Blesta that tracks perms by id and perhaps they aren't matching on the server I migrated to?

app/controllers/admin_system_general.php I've been debugging this issue on the server (yikes!). I don't really have a local setup for Blesta dev (yet). Just some basic echo statements to analyze the settings. Looks like the foreach() loop that checks if the directories are writable are returning false for the 2 directories mentioned above. Those paths are coming from the database settings. I've checked and the syntax / path is correct - those directories exist. So the is_writable() never gets called, since is_dir() returns false. Any ideas why is_dir() is returning false on directories that are actually there? Thanks in advance.

Reluctant to post this but I've been trying to move past this for a while now. This is my 4th time to install Blesta. All other times have gone fairly smooth. This one was a migration to another server. I followed the guide and everything looks good. Site renders for both client and admin. Hostname didn't change and kept same db name / pw. Everything looks good except these directories won't show writable no matter what I do. Any thoughts or suggestions would be appreciated.

Another cool update. So this whole thing started when I tried to install Blesta locally on my MacBook Pro running AMPPS. I shifted to installing it on my production server via another subdomain. Thanks to your help Paul, I was able to get it running. So I went back to my laptop and turned on error reporting and debugging. It turns out I was getting a "Session already started..." error. AMPPS default setting in php.ini was session.auto_start = 1. I set that to 0 and everything works locally now too!

I just reset my password and removed the special character and everything works now! Woot woot! Thanks for all your help. -Jonathan

Yes I use a dollar sign like this: //////////////////////////////////////////////////////////////////////////////// // Database //////////////////////////////////////////////////////////////////////////////// // Database connection information Configure::set( 'Blesta.database_info', [ 'driver' => 'mysql', 'host' => 'localhost', //'port' => "8889", 'database' => 'some_database', 'user' => 'some_user', 'pass' => 'SomePassword1234\$', 'persistent' => false, 'charset_query' => "SET NAMES 'utf8'", 'sqlmode_query' => "SET sql_mode='TRADITIONAL'", 'options' => [] ] ); -Jonathan

Paul, I ran the installation via command line and it showed everything completed. It told me to go to /admin/login/ in browser and then I get the same blank screen. So I turned on errors and this is what I got: The installation connected to the database just fine because it creates all the tables. -Jonathan

Paul, Thanks for the response and suggestions. I've tried re-uploading several times. Based on your suggestion, I also re-uploaded blesta-new.php and deleted blesta.php. Re-ran install and still same result. PHP - 5.6 MySQL - 5.6.38 -Jonathan

I am attempting to install the latest version of Blesta 4.1.2 for development and testing. I first tried to install locally on my Mac but was unsuccessful. I knew there were differences in my local AMPPS setup vs my production server, so I opted to try and install on the production server in another subdomain/folder. This production server runs my main instance of Blesta. I just recently upgraded it from 3.x to 4.1.2 without problems. During installation, it tells me I meet the minimum and recommended requirements, etc. I fill out my database info and click INSTALL. The progress bar gets about 80% complete then routes me to ../admin/login/setup and the page is blank. I've checked Chrome Dev tools and nothing is returned. It does return a 200 OK. I've dropped the database tables, removed the code, and tried again with the same result. Upon checking my error log, it showed the following: Based on the post here I modified my MySQL my.cnf file with the following and restarted mysqld but still get the same error. wait_timeout=2400 connect_timeout=360 Any ideas or help would be much appreciated. Regards, Jonathan | JaxSite

Paul, We would like to get a dev license to test our existing customizations before upgrading to 4.x. Further, we have a module we would like to start developing as well. Please let us know how we can acquire a dev license to work locally. Thank you. Regards, Jonathan Griffin | JaxSite

Thanks Jawanet! It works great!!! I hadn't looked at code options yet, having just scanned the admin settings area. This was an easy fix. I settled on 125% for a size that works for me. #create_ticket textarea { font-size: 125%; }

Is there a config setting to control the font size used for the text entry on a support ticket? I'm on a MacBook Pro with 1440x900 resolution and using Chrome. I've attached a screenshot.

I'm having fun learning more about Blesta! Looks like system tasks are set with CompanyID=0. That's why I wasn't seeing the backups task run. I've set it back to CompanyID=0. Now the Amazon S3 backup task is running like a champ!

I noticed when I tried to update the Amazon S3 settings from 1 hour to 1 day, I received a cron task run id error.

I've setup Amazon S3 backup configuration. I've tested the connection and it works. I've forced an offsite backup and it succeeds (confirmed in S3). But when I initially went to Settings -> Company -> Automation ... I didn't see Amazon S3 as an option. I noticed in the database in table cron_task_runs the entry for Amazon S3 (in my case id #14) had CompanyID=0. I manually set this to 1 and now I see the Amazon S3 section in the Automation page. But still when the cron job fires, the backups_amazons3 task does not run. I've also confirmed in Global settings that my tmp and upload folders are readable / writeable by the web user Blesta is running as. I've also confirmed that the cron is setup for that same user via crontab -u [username] -e. Any suggestions would be much appreciated! Thanks!!

Has anyone already started work on an OVH provisioning module? I searched the forums but didn't find any posts so far. I'm considering starting on one or would be willing to help collaborate with someone who already has started. Thanks everybody!

Thanks for the tip! I've set up the Creation Error email notification now.

Based on my previous post, I set out this evening to fix the current security issue with the following goals in mind: Remove the Manage button by the service listing in all states except Active. Remove the Switch icons on service row expansion in all states except Active. If someone enters the direct URL to the cPanel Extended dashboard it disables all functionality and displays a message that the account is not properly setup (similar to default cPanel module). Add a notification message somewhere in the Admin so an administrator is aware the next time they login. Email an administrator of the failed provision (this might already be an existing Blesta feature). After getting familiar with Blesta and cPanel Extended codebases, I have fixed the issue and accomplished my first three goals. I'll continue to become more familiar with the codebase so I can complete goals 4 and 5 too. To accomplish goal #1, I wrapped the template code with a status active check. This removed the Manage button in the Options column of the service row. Here is the code: /app/views/client/[template]/client_services.pdt <td> <?php if ($this->Html->ifSet($status) == "active") { ?> <div class="btn-group"> <a href="<?php echo $this->Html->safe($this->base_uri . "services/manage/" . $this->Html->ifSet($services[$i]->id) . "/");?>" class="btn btn-xs btn-default"> <i class="fa fa-cog fa-fw"></i> <?php $this->_("ClientServices.index.option_manage");?> </a> </div> <?php } ?> </td> To accomplish goal #2, I wrapped the containing table row with a status active check. This disables the row expansion feature in all service states except active. Here is the code: /app/views/client/[template]/client_services.pdt <?php // List all services for ($i=0; $i<$num_services; $i++) { if ($this->Html->ifSet($status) == "active") { ?> <tr class="expand service_info"> <?php } else { ?> <tr> <?php } ?> <td><?php $this->Html->_($services[$i]->package->name);?></td> <td><?php $this->Html->_($services[$i]->name);?></td> To accomplish goal #3, I wrapped the sidebar tab building code with a status active check. This removes all of the cPanel Extended tabs and features from the /services/manage/ view. By removing the Manage button in goal #1 above, the average user will never be able to reach this URL. But for the tech savvy, it wouldn't be hard to figure out. And my goal with this fix is to prevent those tech savvy types from causing harm? So just in case this URL is called, unless the service is active, no manage features are available. Here's the code: /app/controllers/client_services.php public function manage() { $this->uses(array("Coupons", "ModuleManager")); // Ensure we have a service if (!($service = $this->Services->get((int)$this->get[0])) || $service->client_id != $this->client->id) $this->redirect($this->base_uri); $package = $this->Packages->get($service->package->id); $module = $this->ModuleManager->initModule($service->package->module_id); $module->base_uri = $this->base_uri; $method = isset($this->get[1]) ? $this->get[1] : null; // Set sidebar tabs if ($service->status == "active") { $this->buildTabs($service, $package, $module, $method); } I've also attached some screenshots showing the updated UIs where a cPanel Extended service is in PENDING state and management is basically disabled. Overall, I've had a fun night getting familiar with some of the code. Most importantly, I'm happy I was able to fix this security issue for my needs. I welcome any suggestions and advice from the Blesta Developers as well as cyandark. If there's a better way to fix this issue, please share so I can learn in the process. Thanks again for providing this community and everyone here who are so helpful. Cheers!

Somehow I missed the entry in the module logs where cPanel Extended tried to call "createacct" and received an error back from cPanel. I attached a screenshot showing the log entry. So it looks like cPanel prevents a duplicate account with the same domain name from being created. That's good. And it appears like cPanel Extended responds to that error by setting the service in PENDING status. Now I'm thinking I would like for it to do the following: Remove the Manage button by the service listing in all states except Active. Remove the Switch icons on service row expansion in all states except Active. If someone enters the direct URL to the cPanel Extended dashboard it disables all functionality and displays a message that the account is not properly setup (similar to default cPanel module). Add a notification message somewhere in the Admin so an administrator is aware the next time they login. Email an administrator of the failed provision (this might already be an existing Blesta feature).

Correct. The default module created a Blesta account and added the service as PENDING. But you could not access the cPanel integrated features offered from the default module. Not sure if because it is PENDING or flagged from a failed attempt to provision the account. Either way, it prevents someone from spoofing a domain at purchase and gaining access later. I'm going through the cPanel Extended code this evening. I'm hoping I can simply remove the Manage options in all cases unless the service is Active. Plus, add prevention measures during the order process area. That would even be a little more than the default module does.

Awesome! Thanks for the quick reply! If I get the patch working, I'll issue a pull request for you to review and consider in your future version release.

DISCLAIMER: I've been following this community and Blesta for over a year. Recently I purchased a Blesta license and have been doing extensive testing with sample clients, packages, coupons, server groups, etc. I started off provisioning with the default cPanel module. I then decided to give cPanel Extended a shot. During this testing process, I've came across a security issue that concerns me. If this issue has already been brought up and discussed, please forgive me and simply ignore this post. I've searched quite a bit through the forums but have yet to find anyone else with a similar post. I'm fairly new to this forum and still learning my way around. So far I think Blesta has a pretty awesome community of folks! INITIAL TESTING: I started out testing cPanel Extended with some sample clients and sample packages. Immediately, I was impressed with the nice feature set provided. During my initial testing, everything worked smoothly. I was able to manage aspects of the account through Blesta, and jump right over to cPanel or Webmail or File Manager with a single click via Switch. SIMPLE IDEA: I have existing hosting clients that I want to map to accounts in Blesta. So I was curious if I could do that and simply bypass provisioning. I setup a new client account for one of my existing clients. I unchecked the option Provision using the cPanel Extended module. The service was added and set active. I clicked on the Manage button on the service. I was able to see all the cPanel Extended options and everything seemed to work ok. Next I logged in as my client. Again, I clicked the Manage button on the service. I was able to access all the cPanel Extended features. I was able to access cPanel and Webmail thanks to SSO. Everything looked good. This is great! I can map all my existing clients in Blesta with cPanel Extended. Life is good!!! ANOTHER IDEA GONE WRONG: Then my mind started thinking about security. What if someone signed up for an account and entered a domain name that already existed on the server and mapped to another client? Would the new client signing up get an error during the order process? What if I added a service to a client through the Admin and entered a domain name that was already mapped to another Blesta account? First, I decided to test within the Admin area. I was able to set up multiple clients with the same service and mapped to the same domain. But I'm explicitly choosing to uncheck the provision option. So by not provisioning, Blesta doesn't know if that domain already exists or not. And since cPanel Extended is using SSO, I was able to access all features including cPanel and Webmail on the same domain from all the client accounts. This test case is highly unlikely because we would not be setting up multiple accounts mapped to the same domain and bypassing provisioning. It just doesn't make sense. Next, I decided to sign up as a new client. During the order process, I entered a domain that was already setup on the server and mapped to an existing Blesta account. The order went through successfully. I didn't receive any error message. Next I accessed my new client area. I noticed the service was marked PENDING. (At this point I logged in to Admin and checked the Module Logs. cPanel Extended created logs for generating a cPanel user token. But I didn't see a log showing the account creation failed. SPOILER: Later I did similar testing with the default cPanel module and it generated an error log stating the account already existed on the server. Further, cPanel module kept the service PENDING, and when I tried to access Info or Stats it said Account does not exists. Kudos for the security measures implemented in the default cPanel module!) With my new account, I viewed my PENDING service. I clicked on the Manage button. I gained access to ALL cPanel Extended features. I could see detailed information about that existing domain account. I could see what email and ftp accounts were set up. I could access cPanel, Webmail, File Manager, and phpMyAdmin. I could change the cPanel password! Hopefully for those of you reading this, you can see the MAJOR SECURITY RISK posed here. Anyone from anywhere could come to my site, sign up for a hosting account, enter the domain of one of my existing clients, gain access to their account, and do some SERIOUS DAMAGE. GOING FORWARD: Ideally, I would want an error message to be returned during the order process stating the domain chosen is not valid or already in use. But at a minimum, until the service becomes active, all cPanel Extended features should be inaccessible. Perhaps simply disabling or removing the Manage button and disabling the ability to click on the service row for the expanded switch options. I'm cloning the GitHub repo and will starting looking at options for closing this security hole. If anyone else in the community can make the fix faster due to more familiarity with the Blesta code base, please do! SUMMARY: I do want to extend my thanks and appreciation to cyandark for the module. The features are just what I'm looking for to integrate cPanel with Blesta. But at current, I or someone faster needs to resolve this security risk before I will feel comfortable using it in production.

Turns out I was missing an opening brace after require. It works great now. Thanks everyone! { "version": "0.1.0", "name": "JaxSite", "description": "Custom template for JaxSite integration.", "authors": [ { "name": "JaxSite", "url": "http://www.jaxsite.com" } ], "require": { "blesta": ">=3.2.0" } }