# Set the hostname correctly before we start off, otherwise CWP will pick up the wrong name
# Update existing packages
sudo yum -y update
# Install wget and nano (as I like nano and wget is needed for the CWP install)
sudo yum -y install wget nano
# Reboot the box to sort out any updates requiring reboot
In the past, I’ve configured these on my domains (and wrote about SPF with GSuite – which was at the time, Google Apps). In the last 9 years, the rest of the DNS config has changed a lot, and as I’ve never had issues with mail, I never reviewed my settings. Until today.
For another reason, I checked my config on mx toolbox – and I spotted that some tuning was required.
It seems, that at some point the recommended record has changed from:
v=spf1 include:aspmx.googlemail.com ~all
To a different domain:
v=spf1 include:_spf.google.com ~all
OK; no problem – that one’s easy to fix. Setting up DKIM was easy as well, using the guidance here, and again highlighted that those records were incorrect as well. At some point a CPanel server had managed the DNS config and added it’s own records!
Reminder to self – review my MX settings at least every couple of years!
For me, the bare minimum when it comes to app configuration in Qlik Sense or QlikView is:
– Setting paths and libs for use in data load script
– Setting “boilerplate” variables – e.g. the number/date/currency/etc formats
– Setting HidePrefix, SearchIndex and other app-specific behaviours
– Setting Product or Customer specific settings for consumption in the UI
In a multi-product/customer setup (see this previous post about deployment frameworks for context) where we follow common standards for names and folder structures we can streamline this configuration to reduce the maintenance and deployment burden.
In the absence of a source control system like SVN or GIT, a quick and easy way of capturing changes in a app is to update a version control tab before passing the app back to other developers, or onto testers.
This is a very low-tech solution, but the format below works well in shared environments. The first two tabs of your application should be:
– Version (explain the app and list changes you’ve made)
– Config (set the configuration values like paths, dates, etc used in your application’s data load and UI)
I have an installation of the 3arcade script that’s still in the wild, and decided it was time to update it to work with PHP 5.6 (at least).
These changes fix:
– a row 0 error in play.php linked to deprecated functions
– deprecation of the ereg_replace function through use of intval
– deprecation of the mysql_connect function (and future deprecation of mysql* functions) through use of PDO
– consistency of database connection and query errors with a variable in the config file