• Loss of opportunities
• Damage to your brand
• Data loss
• Lost sales
• Lost trust

It’s essential to stay on top and ahead of any potential downtime.

Here are three areas where you need to be ahead of the curve:

Know your limits / server resources

Physical resource shortages

A common cause of downtime is from running out of server resources.

Whether it is RAM, CPU, disk space or other, when you run out, you risk data corruption, programs crashing and severe slowdowns to say the least. It is essential to perform regular server monitoring of your resources.

One of the most important; yet overlooked metrics, is disk space. Running out of disk space is one of the most preventable issues facing IT systems in our opinion.

When you run out of disk space, your system can no longer save files, losing data and leading to data corruption.

Often your website might still look like it is up and running and it’s only when a customer interacts with it, perhaps uploading new data or adding an item to a shopping basket, that you find it then fails to work.

We see this happen most frequently, when there is a “run-away log file” that keeps expanding until everything stops on the server!

CMS systems like Magento fall particularly prey to this as they often have unchecked application logs.

Internally, we record all server resource metrics every 10 seconds onto our MINDER stack and alerts will be raised well in advance of disk space running out. You don’t need to be this ‘advanced’ – you could simply have a script check current disk space hourly and email you if it is running out.

Configured resource shortages

Another common resource limit is a misconfigured server.

You could have a huge server with more CPU cores, RAM and storage than you could dream of using, but if your software isn’t configured to use it it won’t matter.

For example, if you were using PHP-FPM, and hadn’t configured it correctly, it would only have five processes running to process PHP. This means that in the case of a traffic spike, the first five requests would be served as normal but anything beyond that 5th request will be queued up until the first five had been served. This will of course needlessly slowing the site down for visitors.

Issues like this are often flagged up in server logs, letting you know when you hit these configured limits, so it is good to keep your eyes on them. These logs can also indicate that your site is getting busier and help you to grow your infrastructure in good time, along with your visitors.

You might be thinking, “why are there these arbitrary limits getting in my way? I don’t need these at all”.

Well, it is good to have these limits so that in the case of an unusual traffic spike, everything will run slowly but importantly it will work! If they are set too high, or not set at all, you might reach the aforementioned “physical limits” issue risking data corruption and crashing.

Did you know, by default NGINX only runs with one single threaded worker!

Providers

As a small business, it is normally impossible to do everything in house – and why would you want to,  when you need to focus on your business?

So it is good to step back every once in a while and document your suppliers.

Even if you only own a simple website, suppliers could include:

• Domain registrar (OpenSRS, Domainbox, …)
• DNS providers (Route 53, DNS Made Easy, …)
• Server hosting (Rapidswitch, Linode, AWS EC2, …)
• Server maintenance (Dogsbody Technology, …)
• Website software updates (WordPress, Magento, …)
• Website plugin updates (Akismit, W3 Total Cache, …)
• Content Delivery Network (Cloudflare, Akamai, …)
• Third parties (Sagepay, Worldpay, …)

All of these providers need to keep their software and/or services up to date. Some will cause more impact on you than others.

Planned maintenance

Looking at server hosting, all servers need maintenance every now and again, perhaps to load in a recent security update or to migrate you away from ageing hardware.

The most important point here is to be aware of it.

All reputable providers will send notifications about upcoming maintenance windows and depending on the update they will let you reschedule the maintenance for a more convenient time – reducing the effect on your business.

It is also good to have someone (like us) on call in case it doesn’t go to plan. Maintenance work might start in the dead of night, but if no one realises it’s still broken at 09:00, heads might roll!

Unplanned maintenance

Not all downtime can is planned. Even the giants, Facebook and Amazon have unplanned outages now and again.

This makes it critical to know where to go if your provider is having issues. Most providers have support systems where you can reach their technical team. Our customers can call us up at a moments notice.

Another good first point of call is a provider’s status page, here you can see any current (as well as past or future) maintenance or issues that are occurring. For example if you use Linode you can see issues on their status page here.

Earlier this year, we developed Status Pile a webapp, which combines provider status information into one place, making it easier for you to see issues at a glance.

Uptime monitoring

This isn’t really a warning sign, but it’s impossible to foresee everything. The above areas are great places to start, but they can’t cover you for the unexpected.

That’s where uptime monitoring comes in. Regardless of the cause, you need to know when your site goes down and you need to know fast.

We recommend monitoring your website at least minutely with a provider like Pingdom or AppBeat.

Proper configuration

Just setting up uptime monitoring is one thing, but it is imperative to configure it properly. You can tell someone to “watch the turkey in the oven” and so they watch the turkey burn!

I’ve seen checks which make sure a site returns a webpage, but if that page says, “error connecting to database” it doesn’t matter!

Good website monitoring checks the page returned includes the correct status code and site content. Perhaps your website connects to your docker application but only for specific actions then you should test specifically as well.

Are you checking your entire website stack?

Who is responsible?

A key part of uptime monitoring – and a number of other items I have mentioned – is that it alerts the right people and that they action those alerts.

If your uptime alerts flag an outage and they are sent to an accounts team it’s unlikely they’ll be able to take action. Equally if an alert comes in late in the evening when no one is around your site might be down until 0900 the next morning.

This is where our maintenance service comes in. We have a support team on call 24/7, ready to jump on any issues.

Phew that was a lot, we handle all of this and more. Contact us and see how we can give you peace of mind.

Feature image by Andrew Klimin licensed CC BY 2.0.

The post Common warning signs before server outages appeared first on Dogsbody Technology.

It was a very successful trip and there are lots of learning points that apply to my own projects at home.

Team diversity

Our team came from numerous backgrounds and, thanks to that, had a huge range of skills and experiences. Some skills were obvious, we had a few teachers on the team who quickly took to working in the secondary school. But a lot of skills I didn’t fully appreciate until we were out there. For example, one team member had a real gift of communication especially with children thanks to being a grandparent.

In addition to the core team, we had support back in Farnborough. The value of this support can be seen in the small things, such as forwarding update emails to friends and family while we were away, but also in major events such as organising lifts to and from the airport after our taxi was cancelled at the last minute.

We also had members of the EI team and community that joined us day to day. I found their insight into the community invaluable as they were able to point out the cultural changes that I wouldn’t have seen myself for example motivating women to work on the build site.

Knowing and trusting in the team strengths was immensely useful as it meant that I didn’t need to worry about everything, for example, I always knew that logistics were in hand, this let me focus on the activities we were doing and engage with the now.

But there can be a danger in trusting in skills. At one point we found out that the building plan was being followed upside down; leading to a rather impromptu building redesign.

Moving bricks at the nursery school

Flexibility

We always knew we would have to be flexible, especially working in the secondary school as there were many unknowns. The biggest one being, how good is their English? When we got there we found other issues, two of the school forms actually shared the same classroom – so with 80+ students it was a squeeze.

Knowing that their English skills might be an issue and during our planning we had built in flexibility so that we could spend more time on the items they struggled on and also teach more if they excelled. The “form two” class did excel, so we were able to focus on using plurals, something that they were particularly struggling with.

Flexibility was also required at the build site where we were all given trowels and floats and taught how to lay bricks. Towards the end of our trip so many locals were joining us on site we were running out of equipment. Flexibility allowed this to be used to our advantage rather than being a hindrance. We were able to help in other ways, collecting water, getting to know the locals and even sitting in the school classrooms helping with marking.

Secondary school students

Forward Planning

Over the months leading up to the trip, we spent a lot of time planning. Deciding who will lead each activity, what songs we will sing, creating school lesson plans and gathering resources. This was also happening in Tanzania where the EI team were planning logistics and getting building materials to the site for us. This was especially important since we were doing two back to back building projects. Both sites would need to be at a point where we could come and help as well as being well resourced.

It is notoriously difficult to plan anything far in advance in Tanzania as they are always focused on the present. We were fortunate to have one team member heading out early and kicking the community into action, setting up bunk beds, showers and paving the way for the rest of us.

These three points all came together in an unexpected manner when we visited the nearby village of Ikuka, some team members and others from St Peters had visited Ikuka two years ago so we were excited to see the village again. When we got there we spent a couple of minutes of seeing the new church building when we received a text saying “get to the village office, the whole village is here.” There we were met with hundreds of people singing, dancing and bearing gifts filled with jubilation.

All in all I had a great trip, filled with many great memories so do ask me about it if you get the chance.

If you want to learn more checkout the Emmanuel International website.

The post Things I learned from my mission trip to Tanzania appeared first on Dogsbody Technology.

Here at Dogsbody Technology we are connected to servers, editing files and improving configs every day. All of this means that a good text editor is a must. That is why we chose Vim.

I assume you know the basics, If you don’t I recommend starting here.

Tip 1: Use Vim as a file browser

Have you ever accidentally opened a directory in vim? if you had, you would be pleasantly surprised that it creates a nice interface to find and start editing the file you meant.

Well you can get to that menu another way:

:Explore

From this menu you can use your arrow keys to select and open up new files for editing.

Of course if you already know the file name, just open it directly:

:open filename

Phew I was worried I might need to leave vim for a second then.

Tip 2: Try out multi-line inserts

*tap**tap**tap**tap**tap**tap**tap* the sound of a colleague commenting out a code block. Slow, noisy. Vim has a much quicker approach using visual blocks:

ctrl + v # Enter visual block mode and using your arrow keys select all of the lines you wish to edit
ctrl + shift + i # Enter insert mode
"Example text entry"
Esc # Stop entering text

A very similar method can be used to append text to lines.

ctrl + v 
end # Move the cursor to the end of the line - This works even if the line endings are different lengths 
ctrl + shift + a # Enter append insert mode
"Example text entry"
Esc

You can also use visual block mode to quickly delete a large area of text. Just select it and press “d”.

Tip 3: Make the most of macros

Macros are incredibly simple and just as powerful. They are a sequence of Vim inputs and commands that you can re-run at the touch of a button.

Here’s how to start recording your custom macro:

q # Start recording
j # or any other character you want to trigger it
# any collection of commands you want
q # Stop recording

Then to run the macro:

# To run the "j" macro
@
j

To quickly re-run the last macro, you can double tap “@” or just hold it.

Simple to learn, but when you combine it with other commands, you can quickly build something amazing.

For example – I had a JSON blob containing a list of different SSH keys multiple times. I needed to delete the second key that matched the word “frank”. Quickly creating a macro that runs a search, go to next line, delete. Manually this job would have taken half an hour, with Macros, just five mins.

Tip 4: All the things she ‘sed’

…running through my head

Vim has an inbuilt stream editor, this enables you to modify lines in a quick and replicable manner. But did you know that it comes with regex support out of the box?

Lets look at this command:

:% s/\(wibble\)/ --> \1 <-- /g
:g/[Ww]ibble/d

The first command finds the word “wibble” and puts two big arrows around it, not very useful but a good example:

• The “%” at the beginning tells it to match all lines. Alternatively you could put in specific line numbers (e.x. 5,13 – match lines five to thirteen)
• “s/$input/$output/g” start a text substitution. Ending g means match multiple times on one line.
• \(wibble\) create a capture group looking for the word “wibble”.  Notice that the braces need escaping, unlike normal regex.
• \1 return the contents of capture group one

The second command uses a slightly different function. It deletes all lines with the word wibble in them, matching both with an without a capital letter W.

If you need to brush up on your regex, we find the regexr site an indispensable resource.

Tip 5: Escaping

If you have ever seen this error “E45: 'readonly' option is set” then you have probably seen this work around…

:w ! sudo tee %

But did you know you can expand this to use any bash commands?

:w ! sort | uniq | tee %

These commands sort the file, then remove any duplicate lines before using tee to write the output back into your vim file.

That concludes my top five Vim tips. Vim is an astonishingly advanced tool that rewards you the further you dig into it.

Did you learn something new? Do you have your own Vim tips to share? Leave us a message in the comments below!

The post 5 Vim tips for advanced users appeared first on Dogsbody Technology.

It is just like an address book, it stores your friends phone numbers for when you want to contact them. Originally network admins had to store every domain they knew about in hosts file but this was quickly replaced when the internet became so big this was impossible. This information is now provided by a service called DNS (domain name service) but nearly every system still supports the hosts file.

It is very useful to know that the hosts file is checked before DNS and therefore can be used to overwrite DNS on your computer. This is immensely useful for testing, development work and moving things around on the internet. We regularly use hosts files to test websites on new servers without interrupting normal site visitors.

How to change your hosts file:

Windows 10 and 8

1. Press the Windows key

2. Type “Notepad” into search

3. Right click on the Notepad app and select “Run as administrator”

4. From Notepad, open the following file: “c:\Windows\System32\Drivers\etc\hosts”

5. Make your changes

6. Save the file

macOS (Mojave)

1. Open up the terminal (this is found in Applications/Utilities)

2. sudo nano /private/etc/hosts

3. Make your changes

4. Save the file (ctrl-x and then y)

You will need to clear the system cache before your changes are loaded in.

5. sudo killall -HUP mDNSResponder

Linux

1. Open a terminal

2. sudo vim /etc/hosts

3. Make your changes

4. Save the file

I am in my hosts file, now what?

Hosts files are written as so:

ip.ad.dr.ess      domain names

For example if you wanted all traffic to dogsbody.com (and www.) to instead go to 203.0.133.54:

203.0.133.54      www.dogsbody.com dogsbody.com

Finally remember to revert your changes when you have finished testing!

Migrating websites? updating DNS? kerfufled? contact us today

Feature image by Michal Jarmoluk licensed for Free.

The post What’s a hosts file? appeared first on Dogsbody Technology.

In the case of an outage logs are indispensable to see what happened. If you’re under attack it will be logged. Everything is logged so it is essential to pay attention.
– From my last blog post why there’s nothing quite like Logcheck.

These are our top five tips when working with large log files.

1. tail

The biggest issue with log files is the size, logs can easily grow into gigabytes. Most text editing tools normally used with other text files (vim, nano, gedit etc) load these files into memory, this is not an option when the file is larger than your systems memory.

The tail command fixes this by only getting the bottom lines of the log file. It fixes the problem of reading the whole file into memory by only loading the final bytes of the file.

Log files nearly always have new log lines appended to the bottom of them meaning they are already in chronological order. tail therefore gets you the most recent logs.

A good technique with this is to use tail to export a section of the log (in this example the last 5000 lines of the log). This means you can comb a smaller extract (perhaps with the further tools below) without needing to look through every single log line, reducing resource usage on the server.

tail -5000 > ~/logfile.log

You may also find the head command useful, it is just like tail but for the top lines in a file.

2. grep is your best friend.

Perhaps you are only interested in a certain lines in your log file, then you need grep.

For example if you are only interested in a specific timestamp, this grep returns all of the logs that match the 05th March 2019 at 11:30 until 11:39.

grep "05/Mar/2019:11:3" logfile.log

When using grep you need to know what is in the log file and how it is formatted, head and tail can help there.

Be careful to not assume things, different logs are often written in different formats logs even when they are created by the one application (for example trying to compare webserver access and error logs).

So far I have only used grep inclusively but you can also use it to exclude lines. For example the bellow command returns all logs from the 05th of March at 11:30 and then removes lines from two IP’s. You can use this to remove your office IP’s from your log analytics.

grep "05/Mar/2019:11:3" logfile.log | grep -v '203.0.113.43\|203.0.113.44'

3. Unique identifiers

grep is at its best when working with unique identifiers as you saw above we focussed in on a specific time stamps. This can be extended to any unique identifier but what do you look for?

A great unique identifier for web server logs is the visitors IP address this can be used to follow their session and see all of the URL’s they visited on the site. Unless they are trying to obfuscate it, their IP address persists everywhere the visitor goes so can be used when collating logs between multiple servers.

grep "203.0.113.43" server1-logfile.log server2-logfile.log

Some software includes its own unique identifiers for example email software like postfix logs a unique ID against each email it processes. You can use this identifier to collate all logs related to a specific email. It could be that the email has been stuck in the system for days which this approach will pick up on.

This command will retrieve all logs with the unique identifier 123ABC123A from all files that start “mail.log” (mail.log.1, mail.log.3.gz)

zgrep '123ABC123A' mail.log*

Taking points 2 and 3 one step further, with a little bit of command line magic. This command returns the IP addresses of the most frequent site visitors at on the 5th of March at 11 AM.

grep "05/Mar/2019:11:" nginx-access.log | awk '{ print $1 }' | sort | uniq -c | sort -n | tail

4. Logrotate

As I have said before logs build up quickly over time and to keep your logs manageable it is good to rotate them. This means that rather than one huge log file you have multiple of smaller files. Logrotate is a system tool which does this, in fact you may likely find that it is already installed.

It stores its config’s in /etc/logrotate.d and most software provides their own config’s to rotate their logs.

If you are still dealing with large log files then it may well be time to edit these config’s.

A quick win might be rotating the file daily rather than weekly.

You can also configure logrotate to rotate files based on size rather than date.

5. AWS Athena

AWS Athena brings your log analytics to the next level. With it you can turn your text log file into a database and search it with SQL queries. This is great for when you are working with huge volumes of log data. To make this easier Athena natively supports the Apache log format and only charge you for the queries you make.

AWS have lots of good documentation on setting up Athena and tying it into Apache logs.

Fighting huge log files? not getting the insights you want? Contact us and see how we can help.

Feature image by Ruth Hartnup licensed CC BY 2.0.

The post 5 things you need to know when working with big logs appeared first on Dogsbody Technology.

Logs are our bread and butter. They store details on everything that happens on any server; each request to each asset on this webpage is logged, every login and email sent. In the case of an outage logs are indispensable to see what happened. If you’re under attack it will be logged. Everything is logged so it is essential to pay attention.

Manually checking all server logs is a slow and arduous task and quickly becomes impossible as you scale up. We actively monitor server logs with Logcheck. Logcheck makes this log monitoring possible across hundreds of servers by reducing the logs needing to be looked at, it does this with the exception tracking approach.

Most log management tools use a blacklist approach, looking for bad words such as “attack”, “bad” and “error”. In doing so they only tell you about the “known bad”, the log lines that have shown errors before. Big problems will come if you’re hosting a brand new app or using new software, there is no way of knowing what is bad and what should be alerted on. You rely completely on the new software to have configured logging that matches your current rules.

Logcheck’s whitelist approach fixes the problem these other tools have, as it passes you all unknown/rogue logs. This makes it perfect for any venture in to the unknown by telling you exceptions to known good rules.

Regex can be used in the whitelist making the rules very customisable and still broad enough to not have to whitelist every single combination of log.  We maintain our whitelist rules on a per-server basis, as logs that are OK on one server could indicate a problem on another.

Logcheck and log administration are services offered in our maintenance packages.

Contact us today to find out more!

Feature image background by gregloby licensed CC BY 2.0.

The post Why there’s nothing quite like Logcheck appeared first on Dogsbody Technology.

Over time technology and security evolves, new bugs are fixed and new threats prevented, so in order to maintain a secure infrastructure it is important to keep all software and systems up to date.

Operating systems are key to security, providing the libraries and technologies behind NGINX, Apache and anything else running your application. Old operating systems don’t support the latest technologies which new releases of software depend on, leading to compatibility issues.

Leaving old Ubuntu 14.04 systems past April 2019 leaves you at risk to:

• Security vulnerabilities of the system in question
• Making your network more vulnerable as a whole
• Software incompatibility
• Compliance issues (PCI)
• Poor performance and reliability

Ubuntu End of life dates:

Ubuntu LTS (long term support) operating systems come with a 5 year End Of Life policy. This means that after 5 years it receives no maintenance updates including security updates.

• Ubuntu 14.04 : April 2019
• Ubuntu 16.04 : April 2021
• Ubuntu 18.04 : April 2023

Faster:

Just picking up your files and moving them from Ubuntu 14.04 to Ubuntu 18.04 will speed up your site due to the new software.

• Apache 2.4.7 -> Apache 2.4.29
• NGINX 1.4.6 -> NGINX 1.14.0
• MySQL 5.5 -> MySQL 5.7
• PHP 5.5 -> PHP 7.2

Are you still using an old operating system?

Want to upgrade?

Not sure if this effects you?

Drop us a line and see what we can do for you!

Feature image by See1,Do1,Teach1 licensed CC BY 2.0.

The post How will the Ubuntu 14.04 EOL affect me? appeared first on Dogsbody Technology.

“I wanna scream and shout and let it all out”.
– will.i.am & Britney Spears

Postfix set up

Install the postfix email software:

sudo apt-get install postfix mailutils

The following screen will pop up. I am setting up a Internet site where email is sent directly using SMTP.

Next enter the server hostname.

If you want to change these settings after the initial install you can with sudo dpkg-reconfigure postfix. There are a number of other prompts for different settings, but I have found the default values are all sensible out of the box.

Now to configure where email notifications are sent to:

sudo vim /etc/aliases

In this file you should already have the “postmaster” alias set to root.  This means that any emails to postmaster are sent on to the root user, making it even more important root emails are seen.

It is good practice to set up a few other common aliases. “admin” and your admin username (In my case this was “ubuntu”).

Finally we need to send root email somewhere.  Your file should end up looking like this…

postmaster: root
admin: root
ubuntu: root
root: replaceme@example.com

Obviously “replaceme@example.com” should be an email address you have access to and check regularly.

These new aliases need to be loaded into the hashed alias database (/etc/aliases.db) with the following command:

sudo newaliases

Finally send an email to the root user (which should be sent onto the email you configured above) testing our setup is working:

echo "Testing my new postfix setup" | mail -s "Test email from `hostname`" root

Sending Problems?

If you have done the above and are still having problems sending email there are two first points of call I would check.

This command shows all queued email that is waiting to be sent out by the server. If an email is stuck it will show up here.

sudo mailq

All postfix actions are logged into /var/log/mail.log. You will want to look specifically at the postfix/smtpd messages as that is the process which is talking out of your server to others.

A useful tip for debugging is to use tail -f to monitor a log file for any updates. Then in another terminal session, try to send another email. You can then watch for the corresponding log entries in the original terminal. This way you can be sure which log entries you need to be focusing on.

tail -f /var/log/mail.log

Another thing to consider is that your server is part of the bigger internet where spam is a serious issue.

Your servers reputation is important in effecting how email is received, there are technologies you can set up to improve reputation.

Some providers have their own anti-spam protection that could be affecting you such as Google Cloud blocking all traffic on port 25, 465 and 587 & AWS throttling port 25.

Now email is working

Make sure your server scripts and crons are set up to send alerts, and not fail silently. With crons there is a variable to manage this for you, just add MAILTO=root at the top of your cron file.

Lastly, don’t fall victim to alert fatigue. It is easy to send all email to root but this will quickly become tiring. You should only get emails if something goes wrong, or if something needs to be actioned. This way, when a new email comes in you know you need to look at it.

Need help setting up email? Struggling with emails failing to send? Want someone else to receive and manage server notifications? Contact us and see how we can help today!

Feature image background by tejvan licensed CC BY 2.0.

The post Root email notifications with postfix appeared first on Dogsbody Technology.

Obviously, the best provider will depend entirely on what you want to use it for. We frequently use cloud storage for backups. It is a perfect use case, you can sync your backups into multiple geographical locations at the touch of a button. Storage space grows with you and it doesn’t require anything extra on our servers. Backups of course are not the only option.

Here is a handful of use cases for cloud storage:

• Backups (especially off-site Backups)
• Online File Sharing
• Content delivery networks (CDNs)
• Team Collaboration
• Infrequently accessed files storage
• Storage with unparalleled availability (uptime) and durability (data corruption)
• Static sites (such as my personal site) which is hosted directly out of an AWS S3 bucket

The Data

Below is an abridged version of the data we keep on various providers. This spreadsheet is correct at time of publishing.

An Example

As we said above, we regularly use cloud storage for for server backups. In this example I am backing up 20 GB’s of data every day. It is stored for 3 months. Each month a backup is downloaded to verify its integrity. This equates to:

• 1860GB’s of stored data
• 620GB’s uploaded
• 20GB’s downloaded
• 3100 Put requests
• 100 Get requests

And the winners are (yearly price)…

1. £113.73 – Backblaze B2
2. £321.57 – Azure
3. £335.29 – Digital Ocean Spaces
4. £386.29 – Google Cloud Storage
5. £410.96 – IBM Cloud
6. £419.33 – AWS S3
7. £1,581.60 – Rackspace

At the time of writing, Backblaze provide the cheapest storage per GB by miles but with two large caveats. They only have two data centres and because of that cannot match the redundancy of bigger companies like AWS.  They also do not have a UK data centre which can cause a potential compliance issue as data has to be stored in the US.

Azure is our current recommendation for new cloud storage setups. They are the second cheapest per GB stored, have a UK based data centre and also provide great control over data redundancy. Digital Ocean are the next cheapest but because of the minimum $5 spend they may not be for everyone.

Gotcha’s

Of course what is right for you will also depend on your current server set up. If you are using AWS for data processing and analytics it makes sense to use them, data transfer within AWS being free.

Most cloud providers price in US dollars which we have converted to UK sterling.  This means that exchange rates can affect storage prices greatly.  Azure were the only provider to provide UK sterling prices directly.

Be sure to check the durability (chance that files will become corrupted) of your data as well as it’s availability (chance that you cannot access a file).

The options are limitless. Interested in what cloud storage can do for you? Drop us a line today!

Feature image background by gothopotam licensed CC BY 2.0.

The post Cloud Storage Pricing Comparison appeared first on Dogsbody Technology.

I’m Rob, I look after maintenance packages here at Dogsbody Technology. I want to explain the advantages between the two main patching approaches.

What to Patch

Before we get into the differences of how to patch it’s worth discussing what to patch.

Generally speaking we want to patch everything.  A patch has been produced for a reason to either fix a bug or security issue.

Sometimes patches add new features to a package and this can be when issues occur.  Adding new features can cause things to break (usually due to broken configuration files).

Identifying when a patch release is for a bug, a security fix or adding a feature can be hard. In some cases the patch can be all three things.  Some operating systems try and separate or tag security patches separately however our experience shows that these are rarely accurate.

One of the reasons we like manual patching so much is that it allows us to treat each patch/customer/server combination independently and only install what is required, when it is required.

Auto Patching Advantages

The server checks and updates itself regularly (hourly/daily/weekly).

• Patches can easily be installed out of hours overnight.
• Patches are installed during the weekend and bank holidays.
• Perfect for dev environments where downtime is OK.
• Perfect for use in Constant Integration (CI) workflows where new patches can be tested before being put into production.

Our automatic patching strategy is to typically install all patches available for the system as it is the only sure way to know you have all the security patches required.

Manual Patching Advantages

A notification (e-mail or internal ticket) is sent to the server admin who logs onto the server and installs the latest updates.

• Patches can be held during busy/quiet periods.
• The admin can ensure that services are always restarted to use the patch.
• The admin can search for dependant applications that maybe using a library that has been patched (e.g. glibc patches)
• The admin is already logged onto the server ready to act in case something does break.
• Kernel reboots (e.g. Meltdown or Stack Clash) can be scheduled in and mitigated.
• Configuration changes can be reviewed and new options implemented when they are released. Catching issues before something tries to load a broken configuration file.
• Perfect for production environments where you need control. Manual patching works around your business.

Because we manually track the packages used by a customer we can quickly identify when a patch is a security update for that specific server.  We typically patch security updates on the day it is released also install non-security updates at the same time to ensure the system has the latest and greatest.

Are you unsure of your current patch strategy? Unsure what the best solution is for you? Contact us today!

Feature image background by Courtnei Moon licensed CC BY 2.0.

The post Manual patching vs auto patching appeared first on Dogsbody Technology.