A couple of months ago I took and passed the Amazon Web Services Certified Solutions Architect Associate (AWS CSAA for those not in the mood to be verbose) exam.

It’s a Long Way to the Top (If You Wanna Pass the Test)

It took about 10 months to prepare for this exam, although most of that calendar time was taken up by work, with the lion’s share of studying and cramming happening a week-plus before the exam (we were also leaving for UK/Norway a few days after that, so let’s say it was a bit of a hectic week-plus).

With that said and with the benefit of hindsight, here are the things I used or did on the way to the CSAA exam.

Udemyou? Udemy!

I purchased and completed three CSAA courses, and while there were understandably overlap in content among the three, I found Linux Academy’s offering to have the most focused in terms of lab work (although in order to take full advantage of their hands-on labs one should probably sign up with their “all-you-can-eat” course subscription).

The acloud.guru course, when purchased from Udemy, can be transferred to their proper site where its contents get updated fairly regularly to reflect changes and new features in AWS.

The third course was okay, but I think acloud.guru and Linux Academy were much better. With that said, I purchased all three during Udemy’s frequent sales, so not a huge hit to the wallet (between the study material and the exam cost, I’d probably spent around $200 getting this certification).

Don’t Book ’em, Danno

Of the books I’d read and referred to during all this, I’d guardedly recommend this study guide. It covers the exam materials, but some of the details and what one might regard “minutiae” have changed since the publication date (I found that out through practice tests, FAQ’s, and updated acloud.guru lessons).

I guess it doesn’t help that a new version of the CSAA exam came out since the study guide’s publication. It looks like there is a newer book that covers the 2018 exam, but I haven’t had the time or need to look into it.

GTFO: Get the FAQ’s Out

The one constant of AWS is that it is constantly changing. New features are added, existing features are changed (or sometimes deprecated), and their own documentation, especially their FAQ’s, do keep up with these changes pretty well.

Not that this particular tidbit showed up in the exam, but recently we were looking at FedRAMP compliance of AWS services for a project, and in the span of two weekly meetings, the Elasticache managed service got approved (we noticed the status changing in the middle of the second meeting).

There are better examples of how quickly and constantly things change with the AWS service portfolio, but the time-honored adage of “Read The Fine Manual” (the adage in question masterfully sanitized by George Takei in one of the Starfleet Command game tutorials) definitely applies.

Practice, Practice, Practice

As a coworker so rightly advocates, build your muscle memory. Following along with the videos to provision an EC2, VPC, etc. is great for being introduced to those concepts, but doing these exercises without guidance, repeatedly, and preferably for “real world” projects is critical for internalizing AWS knowledge.

I’m fortunate in that I get to work with AWS for work, and in the months leading up to the exam, I had an opportunity to migrate a million-plus user WordPress site to AWS, launch an ECS Fargate-backed analytics dashboard application, and set up a multi-environment AWS infrastructure. As well as launching regular old EC2 instances that host CMS sites.

While it’s awesome to be able to do this sort of “learn by doing,” one can still do quite a bit of exploring and building with the AWS free tier account (although be prepared to pay a few bucks at least – there is a price for knowledge after all).

Taking Tests to Practice Taking Tests To…

To follow through on another adage about cutting bait or fishing, I booked an appointment to take the CSAA exam, and started hitting the Whiz Labs practice tests. While not as compact as flash cards (nor 100% accurately reflect actual exam questions), the practice tests are a great resource to assess what you think you know and to focus on the bits that you now know you don’t know.

The Big Day

While it is possible to take the certification exam at home, I decided to do what most folks do and scheduled an appointment with PSI, who administer proctored exams for all sorts of things, from aspiring cloud architects to realtors and whoever needs a-testin’ to be a-certified.

The local PSI facility is in a rather unremarkable office building a few minutes from our house, and it is remarkably busy with exam-takers who show up by the half-dozen-plus, sign in, pack away everything (e.g., wallet, keys, and especially phones) in a locked zipper bag, and shuffle away to a room full of booths, each with a workstation ready to test your worthiness to be whatever you’re looking to call yourself.

A couple of hours after checking in for my appointment, I shuffled out of the unremarkable office building with a vague recollection of having passed the exam. Once you submit all your answers, you’re presented with the test results, but you don’t get any actual hard copy of said results. I remembered seeing the word “Congratulations!” on that final screen which would at least imply that I passed, but even the email that arrived immediately after the exam simply stated that I “completed” the test.

The actual results arrived via email the following day, and hey, just as I kinda recalled, I passed!

While I may have taken a lot of calendar time studying, doing, watching, and eventually cramming, I do think that if you do need to take that time to really use AWS in order to learn it. A part of the curriculum does involve a “trivial pursuit” type of memorizing the details of specific AWS services and features, but the exam does require you to understand how the alphabet soup of Amazon cloud offerings (EC2, VPC, ECS, ECR, ELB, ALB, S3, RDS, and on and on) work together, especially in “hybrid” deployments where part of the IT infrastructure remains on-site, while other bits get boosted into the cloud.

And For My Next Trick

What is that they say about potato chips and certifications – that you can’t just have one? I’ll be looking into the Certified Developer Associate exam next, and while once upon a time the CSAA and CDA exams were so similar that you could ace one and pass the other, that “feature” has been nerfed/fixed. So, time to start hitting the videos, clouds, and books again!

A DDoS Tool Gone Good

Wrk is described as being “capable of generating significant load” against a target server/load balancer/environment, which can also be read as “throw enough requests at something to bog it down and cause it to crash.” The aforementioned colleague did describe it as “essentially a DDoS tool,” and he’s not kidding.

“Gone Good,” Really

But the point here really is to be able to generate application requests of specified volume and duration (and other parameters, too) and view a report of the responses from these requests that give you a data point of system performance.

In our case, we have a web application being migrated to Amazon Web Services from a multi-VPS setup in Rackspace, and we used wrk to determine a comparative baseline between these two systems to naturally demonstrate superior performance on AWS. Turns out our initial tests favored the Rackspace environment by a couple of orders of magnitude.

Long story less long, it turns out that a number of sub-components in the AWS environment weren’t configured properly, and after addressing these loose bits, the throughput numbers did come up significantly. Using wrk during this “system tuning” process was beyond helpful as we were able to associate performance data with specific changes, even to the point of reverting settings when test results showed that we’d passed a point of diminishing returns!

It’s Like Tabasco…

…you’ll want to try it on everything, although every application and its environment is different enough performance results do not necessarily tell an “apples to apples” comparison of which is “faster” or “better.” And one also needs to keep in mind that it is possible to overload and crash a target with this tool (remember the “essentially a DDoS tool” bit from earlier?), so be wise in its use.

Link for future reference: https://ubuntuforums.org/showthread.php?t=2352821

Using a VPN used to be the sort of badge of honor indicating that you did something important enough for your corporate overlords to grant you access to the company network through the magick Cisco tunnel (yeah, so you’re having to sling pivot tables off the office file server over the weekend, but hey, you dontcha feel special?!). Now, especially with the net neutrality repeal, everyone’s getting a VPN, and it’s not just to stream BBC’s iPlayer from the States.

Choices, Choices

There are a gazillion VPN vendors out there, and even more blog space devoted to the explanation, virtues, necessity, and comparisons of VPNs, and being the curious soul I am, I’d pondered “Hmm, would it be possible to set up your own VPN tunnel using the various cloud server services out there?” And yes, it is, and you’ve got your choice of tutorials to dig that encrypted tunnel under/through your ISP (or simply through that open coffeeshop hotspot).

You could…

• Set up a $5/month Digital Ocean Droplet and install OpenVPN Server on Ubuntu
• Do something similar on a free tier Amazon Web Service EC2 instance
• Use the OpenVPN AWS EC2 tiered appliance

Then there’s a number of different walkthroughs for deploying OpenVPN Server as a Docker Container, and I went with this one:

• Setup Your Own $5 VPN With Docker, OpenVPN and Digital Ocean

The simplicity of a Digital Ocean Droplet, which lets you kinda skate past the accoutrements that come with (and are essential to an) AWS cloud environment, and the easy-breezy-beautiful Docker Container image were the main attractions here.

London Calling… and They Hung Up

And speaking of easy and breezy, the whole thing from start to finish took me about 15 minute to set up, and I had myself a VPN tunnel with a UK IP (as in an IP address in the UK, not those xenophobic knobs UKIP) address! The immediate downer was finding out that the clever folks at the BBC had blacklisted data centre (note the “proper” spelling there) IP addresses, so no iPlayer for me.

No big deal, I deleted the Droplet, created a new one Stateside, and I’d gotten myself a little tunnel through public wi-fi hotspots for my phone, tablet, etc. So far, I’ve been pleased with the latency (or the relative lack thereof) as well as with the ability to set up as many devices/users as I want at that miserly $5 per month. The next step is to set up a spare Netgear router that I’d flashed with DD-WRT to have a perma-connection through our home ISP.

Dee Eye Wye Vee Pee Enn

Admittedly all this is probably more work than paying a few bucks a month for a professionally managed VPN service, but there’s something oddly satisfying about setting something up yourself. Not as thrilling as, let’ say, digging your way under and out of Stalag Luft III, but it’s kinda sorta a way to make your “great escape” through your own bloody ISP (and that’s a whole ‘nother rant for another time).

And speaking of “The Great Escape,” here’s a great song by a great band:

More Popular Than “Blep”?

With the recent developments in the abrogation of digital privacy, “SSL” will most likely be hot on the heels of “VPN” as the most popular Internet acronym of 2017. And here I was thinking a week ago that I wanted to put an SSL cert on my sites to improve SEO visibility and to simply get rid of that “Not Secure” label on the address bar. Once upon a time, those digital certificates typically came from one or two vendors and cost as much as a well decked-out 15″ MacBook Pro Retina. And they were kind of a pain to install.

A short while back, a mentor mentioned letsencrypt.org as a free, open, and automated certificate authority, and as part of my forays into AWS/Google Cloud hosting I decided to give it and its accompanying CertBot tool a try.

I Think We’re Secure Now

Five minutes later, and my Google VM-hosted site is secure! An hour later, I’ve slapped SSL certs on four other sites, this time hosted on AWS and Digital Ocean! A good portion of that hour was spent doing the head+desk thing before realizing I needed to (a) open port 443 on the host and (b) undo the Apache booboo that was making normal HTTP listen on 443. Live and learn and laugh.

I haven’t tried using Let’s Encrypt and CertBot on a GoDaddy VPS or a Media Temple Grid Server, but since it does not appear that you need root permission, that may be something I’d look into at some point.

You do need to have a fully qualified domain name for your host, and you also need to set up a cron job to renew the certificate every 90 days. Minor issues for something this quick, easy, and cheap.

You’re Not My Phishing (Pay)Pal

It’s also worth noting that literally the day after I’d installed these SSL certs, there were a couple of articles in my Android news feed talking about how PayPal phishing sites were using Let’s Encrypt for digital certificates. Leave it to the malfeasants to go ruining things for the rest of us, just like pseudoephedrine. Or something.

UPDATE: A New Domain and an Updated Certificate

Fast forward a week or so, and after having launched another pair of Let’s Encrypted websites, I decided to revisit my OSHA compliance web app and get a separate domain for it. Registering the domain was a cinch, thanks to Google, although it took me a few hours of waiting before realizing I had to create zone records in another section of the DNS management form, and changing the SSL certificate on the site took a bit of trial and error (and updating a forwarding setting on the default Apache configuration among other things).

I’d first heard of Mautic on the first day of my internship with InboundRx (and truth be told that’s the first time I’d heard of marketing automation – I’ve worked with web analytics and email marketing campaigns, but the idea of setting stages and points for your participants and having software facilitate the process flow was something that lay outside my loop until then). The idea was to use this as an alternative to Hubspot which is regarded as the proverbial Cadillac of such services (with features and price tag to go with that), and we were tasked with customizing this open source tool with modified branding and launching an instance of it on the cloud.

No-Go, Daddy

First we tried a local installation with MAMP. Great, I can follow directions and have it running on my MacBook. Next, on a Cloud 9 workspace. Then the first brick wall of publishing this app on Heroku. It took very little digging to discover that Mautic doesn’t support PostgreSQL (and Heroku doesn’t do MySQL), so no go. Next, a GoDaddy Virtual Private Server. No, Daddy, no. Upgrading to the required version of PHP was a mild pain in the rear (and trying to get PHP7 installed on their VPS was an extreme pain in the rear), and then trying to configure outbound email delivery that didn’t deliver everything as spam was as fruitless. Lesson learned: don’t try DIY when doing bulk mail.

Sailing the Open-Source Seas of Cheese

Even trying to work with the platform once it was launched (on wobbly legs) was a trial. Importing 8,000 contacts required some heavy massaging and eventual breakup of the CSV file into more manageable (or less crash-prone) chunks of 1,000. And the default pagination of 100 line items proved to be yet another pain in the rear for site admins who wanted to bulk-assign thousands of contacts into Segments and Campaigns. I’d managed to modify the PHP code to allow up to 500 items in a bulk operation, which resulted in my first (pending, probably not going to go through) pull request to an open source project.

In the meantime, I’d installed an instance of Mautic on a Digital Ocean Droplet for my own nefarious purposes, with greater success (or fewer faceplants) than with GoDaddy. But then I don’t have 8,000 folks in my contacts list. Yet.

You Can’t Spell “Awesome” without “AWS”?

Over the past couple of weeks, I’d started working with Amazon Web Services, and in particular with their EC2 virtual machines. I’d launched InboundRx’s new website on an EC2 instance, and I was curious as to the lower limit of an instance size that could support Mautic. Starting with an Ubuntu/LAMP Amazon Machine Image that I’d set up for future WordPress sites, I spun up (insert a merry twirl of a magic wand here) a t2.nano instance (insert sage shaking of heads going “that ain’t gonna work, son, that there nano’s too small!”) and installed Mautic. So far so great.

As an aside, I had to get myself up to speed on setting up key pairs for SSH access, which also came in handy in my later forays onto Google Cloud Platform, but I digress.

Cloud Rockets in Flight, APM Delight

Right around that time (a whole week-ish ago?!), I’d started mucking around with New Relic’s Application Performance Management tools (this is what happens when one attends a few Meetups in New Relic’s offices and asks the obvious question of what do these folks do), and while my initial install of the APM PHP agent was easy-peasy and uneventful (a Digital Ocean Droplet doing triple-duty with Drupal, WordPress, and Mautic), I figured I’d use the APM to see if I could get any more insights into a low power (t2.nano doesn’t get much lower!) install of Mautic tasked with importing thousands of contacts.

The PHP agent requires root access in order to install, which means (a) no-go on the GoDaddy VPS and (b) no-go on Media Temple’s Grid Server, but awesomesauce on AWS. I felt a bit like those automotive crash test engineers in that I was deliberately putting load on the application server to see whether and how it’d buckle and crumble. I definitely wasn’t disappointed, as there were plenty of hangs and crashes (nothing fatal that required calling Mulligan to re-do everything from scratch!), and having to tweak php.ini while using Mautic’s, MySQL’s, and NewRelic’s logs to cross-reference and triangulate errors was actually a lot of fun.

Probably the biggest lesson learned is that the mere 0.5 GiB of memory will cause MySQL to keel over a few times a day. I’m sure this is going to poleaxe the server’s responsiveness, but setting up a swap file seemed to alleviate that multiple-times-a-day MySQL crash.

That said, on one hand, I think a t2.nano can handle Mautic, but I do wonder about this CPU Credits per Hour thing and whether I’d end up running out of them at some point on such a small EC2 instance. #weshallsee

Deliver This Mail, ‘Cos Amazon SES So!

When we tried hosting Mautic on GoDaddy, we tried using the host VPS as an SMTP relay to send outgoing emails. Spam by any other name is still canned meat, or so the saying goes, and more often than not the outgoing marketing emails landed in the junk bin. Reverse DNS helps to an extent, and I suspect that setting up DKIM and other identity authentication would have helped as well. But since I was using AWS, I figured why not try their Simple Email Service?

Verifying a domain was quite straightforward in making a few DNS zone file tweaks, and verifying email addresses was even simpler. The biggest holdup (and relatively speaking this seems minor in retrospect) was getting Amazon to get our account out of the “sandbox” to allow us to actually send mail (as opposed to the severely limited delivery parameters of the sandbox). While we’ve yet to actually do a full-scale email campaign with the AWS setup, initial experiments are quite promising.

That said, the next instance of Mautic on AWS is going to use a bigger machine with more hamsters at the wheel.

Flip the calendar, and for the last four weeks, I’d been getting elbows-deep with WordPress, and I’m quite appreciative of how quickly I can put together a clean-looking, easy-to-manage website. In one recent “just for giggles” experiment, I tried recreating an existing website with WordPress – a fairly straightforward company website originally built with Drupal – and managed to have something that could serve as its doppelganger in very short time. Spin up a site, pick a theme, customize said theme a bit, populate it with content, and spend way more time dinking with a carousel that looks cheesy and contrived.

I guess this rapid spin up and site building underscore just how much more styling and whiz-bang glitzery one can pile on should one have the (client’s) budget to do so!

The Custom Theme Called Bosch!

So, I’d started that over a week ago, seeking to mimic a handful of mockups for a website design. The design was centered around these “panels” that would contain text or images, and those panels would be arranged three-across on a page, kinda like those triptychs that Hieronymus Bosch was famous for (minus the pre-bad-acid-trip depictions of hell). I’d wanted this theme to be responsive, and thanks to a friend who pointed me towards a boilerplate starter theme, powered by SASS.

Fast forward a fistful of days, and I think I’ve learned quite a bit getting not only the “triptych” layout but also a complementary “diptych” template up and running for this theme. All the content is managed as WordPress pages, with the Advanced Custom Fields providing placeholders for the bits of text and images. As noted in an earlier post, the navbar and grid stylings had to be constructed for use in this theme, but I really like the ability to control media query breakpoints for the latter via SASS. The content rendering on the WP template side was a great learning experience working with the WP loops, bits of branching logic in those loops, and a thin shaving of jQuery to give the “panels” some clicky bits. Such technical jargon, truly!

At Least It’s Not As Reviled As Carousels…

I’d like to incorporate modals next – allowing site managers to specify whether a panel can link to additional content, and have that content (currently envisioned as the main body of a WP post or a page) displayed in a modal. Let’s see how many more commits that’ll involve!

The repo: https://github.com/eeronomicon/wp-theme-bosch

Let’s Start from the Roots

A friend had shared a bunch of nuggets of wisdom on matters of making websites with WordPress, and of those nuggets, I’d started playing with a couple of products from Roots: Bedrock and Sage. The former is a WordPress boilerplate that uses Composer to manage dependencies (as well as enhance security and totally rewire your WP folder structure), and the latter is a blank slate custom theme (they call ’em “starter themes,” kinda like starter homes?) with the latest Bootstrap and gulp-powered workflow for cranking out sawed-off CSS from SASS files.

I just noticed that the current version of Sage is dropping gulp/Bower for Webpack and also has Foundation as a CSS library choice. Dang, that’s what I get for going with 8.5, instead of 9.0.x-beta. But then, I’m going by their advice: “If you want a stable version, use the latest Sage 8 release.” If I were also going by their advice, I might have gone a different path for a custom theme. But I didn’t.

“There’s a place I know where the hipsters go, it’s called Bedrock, twitch, twitch”

Instead of the famous one minute install of WordPress, Bedrock delivers a tad more complex, but supposedly more robust first pass at putting the… ahem, foundations of your WP site in place. It seems to work fine on a Cloud 9 IDE, and I’m sure I’ll hit some potholes if I push this to a live environment somewhere. And speaking of environments, Bedrock uses .env to manage site configs and environments. I guess the odds of a wp-config.php file ending up in a public repo with database passwords and such are lower thanks to this (L2 .gitignore or GTFO?).

And I still had to screw around with .htaccess files on Cloud 9. Okay, not screw around, but copy and paste. Big deal.

Want Some SASS with Your Sage? Gotta Grow Some First!

The Sage theme installs via Composer, and version 8.5 requires Node, gulp, and Bower to crank out completed style and script files. I’ve found these links to be useful:

• https://www.sitepoint.com/modernizing-wordpress-theme-development-with-sage/
• https://www.sitepoint.com/sass-semantically-extend-bootstrap/
• https://discourse.roots.io/t/bootstrap-navbar-since-nav-was-moved-to-soil/3638
• https://www.sitepoint.com/5-useful-sass-mixins-bootstrap/
• http://sass-lang.com/guide
• https://v4-alpha.getbootstrap.com/layout/grid/

Things to note for the future – Sage doesn’t really have the Bootstrap navbar, so you have to roll your own (a wp-bootstrap-navwalker.php file in the /lib directory, linked in functions.php, and some markup in header.php), and the Bootstrap 4 grid tags didn’t work for me out of the gate so I created my own semantically extended tags using SASS (_grid.scss, with _variables.scss and _global.scss).

The HTML that uses the extended tags have divs that have a single class, as opposed to a small handful that would have accounted for screen sizes, etc. The use of maps for grouping variables helps keep code clean, and @mixin/@include is great for consolidating common style parameters. Less of Write Everything Twice (WET) and more of Don’t Repeat Yourself (DRY). On one hand, I wish we’d spent more time with SASS at school, but I think I’ve got a handle on it. Or starting to.

Composer, Composer, Composer!

Some helpful soul has made WordPress plugins and themes available for management via Composer:

• https://roots.io/using-composer-with-wordpress/
• https://wpackagist.org/

Earmarked for use with a future WP project.

Fruits of Our Labours (So Far)

The WP custom theme is largely a sandbox at the moment, but there’s good examples for future reference.

• https://github.com/eeronomicon/wp-theme-inboundrx
• https://ide.c9.io/eeronomicon/wp-inboundrx

Additional SASS notes for future reference:

• https://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
• http://alistapart.com/article/dry-ing-out-your-sass-mixins
• https://www.psd2html.com/blog/customize-bootstrap-grid-with-sass.html

Hey You, Get Onto My Cloud (Nine)

This link lays things out for spinning up a WP workspace on Cloud 9:

https://community.c9.io/t/setting-up-wordpress/1709

If I were to have rolled out the “first draft” version of this new site to a non-development environment, I’d probably have to have done a bit more moderate lifting, but for the sake of being able to scoot ‘n’ shoot, it’s truly hard to beat Cloud 9.

WordPress in a Nutshell: Pick a Theme, Then Copy/Paste?

Instead of launching myself headfirst into making a custom theme via child theme or a blank slate, I decided to quickly peruse the mega-mart of WP themes. Even the “official” themes directory from the WP site is overwhelming, and scrolling through literally hundreds of “one page” designs from a premium themes site had almost made me forsake that forever-scrolling approach to building a site.

At some point, folks may look at those one pagers the same way that we shudder at those eyebleed Geocities sites (or the more humble AOL Home Pages). I think that Bootstrap sites may qualify for future-retro-embarrassment, although I think there’s quite a bit of Bootstrap-shaming already. As an aside, I like Bootstrap.

More Embarrassing Than Bootstrap

So, I pick a theme, and start tweaking away probably for hours, spending a good chunk trying to get a carousel working on the landing page. Yeah, let’s talk about future-retro-embarrassment-today stuff: carousels. I kinda like them, but yeah, they’re a big use of space that you’d really have to do something special with in order to truly justify that much real estate.

On the other hand, I kinda like the constant motion, as it offsets the walls of text that occupy these pages. And pexels.com is great for freebie images for these carousels. Although their “business” image section has more photos of MacBooks than Craigslist.

Copywriting Is Going To Be a Doozy

I’d recently started using Yoast SEO, perhaps because I enjoy being nagged at by a grammar-checker imploring me to use section titles and to use more active voice. The copy on the site that’d remade is going to need a lot of work to get those orange and red dots at the bottom of this edit page to go green. There are many walls of text on this site, but it’s infinitely better to use actual content than to slather on the bacon/hipster ipsum.

Just Because You Can, You Perhaps Should

One simply does not become a WordPress wizard overnight. Just because I can spin up an install, slap on a theme and a bunch of plugins, and copy over some verbiage, it most likely doesn’t mean that I can go sell someone a new company website. Or maybe I should anyway.

1. Cloud 9 development environment
2. Heroku (unsuccessfully – see below)
3. Digital Ocean Droplet
4. GoDaddy Virtual Private Server

With the current version, Mautic dropped support for Postgres, which seems to be the database of choice for Heroku (I set up one of our Epicodus group projects there and had to migrate the database from MySQL to Postgres), and trying to get the app to work with CloudDB and Google SQL weren’t terribly successful. So, no Heroku for you. Or for me.

Skinny Dipping in the Digital Ocean

Thus far, the Digital Ocean Droplet seems to have been the least PITA, although it did take a bit of doing to get folder permissions and Apache configurations set up properly. For future reference:

• https://kgmoney.net/blog/installing-mautic-marketing-automation/
• https://www.linuxbabe.com/ubuntu/install-mautic-onubuntu-16-04-marketing-automation-software
• https://getcomposer.org/doc/faqs/how-to-install-untrusted-packages-safely.md

GoDaddy, Go!

While Googling installation issues for Mautic on GoDdaddy’s Virtual Private Server, I’d noticed that a good portion of responses flat out state to stay the hell away from GoDaddy. Not that it’s necessarily applicable to a “vanilla” install of Mautic, but GoDaddy does not support PHP7 (although they may do so in the coming months – no firm ETA). I did hover over someone’s shoulder while they navigated through some amazing flaming hoops to get PHP7 on a GD VPS (phpbrew to the rescue). I used the EasyApache web GUI on GoDaddy’s WHM (WebHost Manager) to change the PHP version to 5.6 (which Mautic requires) and to enable a couple of required add-ons (mbstring and fileinfo)… and waited 20 minutes for Apache and PHP to be rebuilt.

Apache, Easy?

Run update first before doing any of the EasyApache stuff, as the build process can crap out.

More php.ini settings to tweak:

• always_populate_raw_post_data=-1
• memory_limit = 256M
• max_execution_time=300

Some of these can be done through EasyApache; others you’ll have to php –ini to find the file and nano that booger (good luck sorting through the lines of settings to find ’em: grep -n is your friend). The latter two settings seemed to help when using Composer to build out your vendor directory.

GoDaddy’s VPS requires you to create a cPanel user through the WHM in order to publish a site, and juggling permissions (e.g., passing root privileges between the cPanel user and the “root” user) can be a tad confusing. I’d found configuring Apache through a .conf on Digital Ocean to be a bit more straightforward, but both get the job done.

Bouncy, Bouncy, Big and Bouncy

Outbound emails – your development instance will probably not successfully send emails, as they’ll either end up in the recipient’s spam box or be filtered automatically. I’ve configured third party email accounts (standard IMAP/POP/SMTP mail and Office365) to relay outbound messages for Mautic. It’s also possible to use the VPS itself as the outbound server – GoDaddy allows a set number of relays per day, which may be more than sufficient for small scale implementations – bigger outbound loads may require services like MailChimp or Amazon SES.

One last tweak to make – Mautic doesn’t like group write access on its index.php file. We had to look at the error logs through cPanel to get this detail for the 500 error that was thrown.

Anything else? GD’s VPS is on CentOS, so no apt-get, it’s all yum.