EATON 9130 2kVA (1800W) Full-conversion UPS

As I no longer service UPS, all my stock has aged and its far more cost effective to buy a brand new unit than to refurbish the old "line-interactive" units.

Two of my 1500VA units have now died and were not worth my time repairing so now I'm down to one small one for the Home Theatre and two big ones for the storm pumps.

The problem with these old units is they are NOT tolerant of operating on generator power and as their batteries age, it now costs a minimum of $480 for the small ones and $1200 for the big ones, just to buy replacement batteries!

So I decided to do something I've wanted to do for ages, that is to buy a good full-conversion Uninterruptible Power Supply (UPS) which will:

• operate on the generator during extended outages so I don't need as much battery capacity
• provide true "clean" power for all the computers and home theatre equipment
• cost less to upgrade batteries for, in the future.

So I did lots of web research then went out an bought an EATON 9130 2kVA UPS from Power On Australia
It was promptly delivered and I powered it up.

Now understand that I've handled many UPS models and sizes, but none of that prepared me for the noise that assaulted my ears when I powered this baby up!
It was competing with some of the 10kVA systems I've worked on!

Two little 80mm cheap-as-chips case fans were managing to produce a cool 51DB of noise (at the standard 1m measuring distance)!!

In a quiet office when you're trying to have a hands-free/conference phone conversation .... nah! ... that's just not doable!

After some more Google searching I discovered this was another well-known problem (though why I didn't see it in my pre-purchase research I'm not sure)  ... wasn't expecting noise to be an issue I guess.

Long story short, I obtained permission from the supplier to swap out the fans for two "silent" high-flow equivalents, without voiding my warranty.

I've yet to press it fully into service but at-least its 'ready' now and seems to be more efficient than the  old line-interactive one it will replace  :-)  

The Solar Saga Continues - An Update

Previous post in this series

Next Post in this series

Details of the IES installation

Back in early 2014 after the vendor and I got jack of the all the hassles with multiple SAMIL inverters, they managed to convince SAMIL that the unit design was flawed and we wanted it ripped out.

The vendor then kindly replaced the SAMIL with an ABB (aka Power One) AURORA inverter to which I added an RS485-to-IP interface, loaded their Aurora Comunicator v2.10.1 PC software and we've been reaping the benefits ever since, with excellent logging and a good UI

 So all has gone wonderfully well since then ... till recently ... when all of a sudden the inverter started to fail with what transpires to be a well known error code of E031

It transpires that after a few years in the field, a particular component has failed in many of these units and they are replaced under their 5yr warranty with little issue.

The only difficulty for me was that my original vendor has gone out of business!

See this page

After some Googling I found the above page and contacted MC Electrical here in Brisbane and they handled the warranty submission, acquisition and installation of a manufacturer-refurbished unit all very fuss-free and professionally, for nothing more than their standard call out rate. 
Hopefully this one will last longer!
They are manufactured by one of the biggest power and energy equipment suppliers in the world so you'd hope this was just one of those post-manufacture flaws which did not get picked up under stress-testing at the design stage.

Open Systems, CI/CD, Virtualisation and Containers

Summarising the difference between Docker, Boot2Docker and Vagrant

Short answer: 

Vagrant abstracts the machine where as Docker abstracts the application.

Vagrant is a virtual machine manager, it allows you to script the virtual machine configuration as well as the provisioning

Docker on the other hand uses kernel cgroup and namespacing via lxc. 
It means that you are using the same kernel as the host and the same file system 


The reason you could want to use Vagrant is if you need an operating environment which differs from that of your Virtualisation host.
e.g. You might want BSD, Windows or other non-linux development on your Ubuntu box
 

This Quora article explains it all quite well:

https://www.quora.com/What-is-the-difference-between-Docker-and-Vagrant-When-should-you-use-each-one

Further:

-->

Docker doesn't provision machines, it wraps your application in a lightweight portable runtime which can be dropped anywhere. 

What runtime you choose for your application has nothing to do with how you provision your machines!

 
Conversely, you may use Vagrant to provision machines which have nothing to do with developing your application - for example a ready-to-use Windows box or something
http://stackoverflow.com/questions/16647069/should-i-use-vagrant-or-docker-for-creating-an-isolated-environment

From the author of Docker: http://stackoverflow.com/a/22370529

From the author of Vagrant: http://stackoverflow.com/a/21314566

Running Java inside a Windows container on a Windows server

https://alexandrnikitin.github.io/blog/running-java-inside-windows-container-on-windows-server/

 

Adobe Flash Update Wont Install - I FIXED IT!

I have a number of VirtualBox VM's running Windows on a Windows 7 Host.
Regularly when I come to do an Adobe Flash update for one of the Browsers (more often than not it happens to be FireFox) and the stub download occurs ok and you fire off the exe, avoid all the crapware and it gets part way through the download and install and fails ... nearly every time.

I discovered two things:

1. I was saving the download to a shared drive running off the host machine and mapped into my VM's ... quite a few installers will not work across the virtualised drive mapping!!!!
   ... including Adobe Flash.
   Copy the downloaded installer (e.g. flashplayer21_xa_install.exe) to the system drive of the VM and 95% of the time it will install without a hitch.
2. The other 5%, I wound up closing the browser as well, as soon as I kicked-off the exe

 99.9999% Flash update success rate now !  :-)

Best Practices of Continuous Integration and Testing

A good video summary of what CI is, can be found here

The Practices of Continuous Integration include the following 11 detailed in Martin Fowler's
Practices of Continuous Integration
This page of notes is still being compiled asat: 8 Apr 2016 

Practice 1 – Maintain a Single Source Repository

Using Version Control Systems (VCS') such as ...

Practice 2 – Automate - Version-Control / Build / Deploy / Test

Using CI tools such as

• Anthill: Now distributed by IBM and implemented in Java. It has a proprietary license.
• Bamboo: Atlassian’s CI server isn’t open source, but the Java code is provided to customers for free. It is also free for open source and community projects to use.
• Buildbot: An open source offering - Brian Warner’s Python based CI tool.
• Continuum: An Apache build tool developed in Java.
• Cruise Control: First shipped in 2001, CruiseControl can fairly claim to be the server that started it all. It was originally developed by employees at ThoughtWorks, but is now an independent project. It's open source, and has versions written in Java, C# and Ruby.
• easyCIS: Freeware CI server developed by Václav Zahradník on top of the .NET framework.
• FinalBuilder Server/Continua CI: CI server from VSoft written in C#.
• Go: ThoughtWorks' continuous delivery tool written in Java.
• Gump: The Apache Software Foundation's first CI tool. Written in Python it supports Apache Ant and Maven, amongst others.
• Hudson: Java CI server now managed by the Eclipse Foundation.
• Jenkins: An open source tool written in Java. The project was forked from Hudson after a dispute with Oracle and is now led by CloudBees.
• Mojo: OpenMake’s free Java-based CI server.
• Parabuild: Java-based server from Viewtier Systems.
• Pulse: Java-based CI server from Zutubi.
• QuickBuild: PMEase’s Java-based CI tool.
• Sin: CI tool written in C# by Casper Hornstrup. It supports Subversion and is licensed with GPL.
• TeamCity: Java-based CI server from JetBrains, makers of IntelliJ.
• Team Foundation Server: Microsoft’s CI sever, widely used by .NET developers.
• TravisCI: Hosted continuous integration service for the open source community.
• Zed: Java-based CI Server from Hericus Software.

Controlling tools to:

Build

• Maven - is a "build management tool" (orchestrator) for defining how your .java files get compiled to .class 'es, packaged into .jar (or .war or .ear) files, then (pre/post)processed with tools to manage the CLASSPATH, and all sorts of other tasks required to build a project.
• Ant:
• Ruby:
• Rake:
• Powershell:
• WinAutomation:

The following is an example hypothetical build process you might use with a simple software system

1. Get the source. You may need to download or fetch the source from a source code repository. For this, you might need to know the tag or version of the source code you want to build.
2. Prepare a build area. You will probably want to create a set of directories, perhaps according to some standardized directory layout.
3. Configure the build. In this step, you will determine what optional components can be built based on the current environment. You might want to set build numbers and version numbers to be included in the build.
4. Validate the source code. You may have a standard style guide and you wish to ensure all code conforms to this before you build a release.
5. Compile the source code
6. Build the compiled code into libraries potentially including non-code resources such as properties, images and sound files.
7. Run the system's tests to validate the build.
8. Build the documentation for the software. This may range from something as simple as collecting text files up to processing content through some form of publishing system to produce the documentation in its final form
9. Package up all of the components of the software – code, resources, images, documentation, etc. – into a deployable package. You might need to produce several packages in different formats for different target users
10. Deploy the software to some standard location for use or distribution

Deploy

• Powershell: 
• Octopus: normal
• Ansible: a radically simple IT automation engine
  
  • Used for cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
  • It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow description of automation jobs in a way that approaches plain English.
  • Ansible manages Linux/Unix machines using SSH by default.
  • From version 1.7, Ansible also supports Windows machines. Native PowerShell remoting is used, rather than SSH.
    Ansible will still be run from a Linux control machine, and uses the “winrm” Python module to talk to remote hosts.
• dssd

Test

• Ranorex: 
• BOLD: normal
• BOLD: normal

Jenkins Tutorial videos
Jeff Jantz - Continuous Integration with Jenkins on Amazon EC2 [1 / 5]
Jeff Jantz - Installing and configuring a Jenkins CI Server on an Amazon EC2 [2 / 5]
Jeff Jantz - Configuring Jenkins on Amazon EC2 [3 / 5]
Jeff Jantz - Continuous Integration with Jenkins on Amazon EC2 [4 / 5]
Jeff Jantz - Continuous Integration with Jenkins on Amazon EC2 [5 / 5]
Sriram Gunda - Installing Jenkins as a Windows Service

TeamCity Tutorial videos
TeamCity UserGuide - Introduction [1 / 9]
TeamCity UserGuide - Web Interface Overview [2 / 9]
TeamCity UserGuide - Build Configurations [3 / 9]
TeamCity UserGuide - Build Results [4 / 9]
TeamCity UserGuide - Working with Tests [5 / 9]
TeamCity UserGuide - Code Analysis [6 / 9]
TeamCity UserGuide - Working with Changes [7 / 9]
TeamCity UserGuide - Personal Builds [8 / 9]
TeamCity UserGuide - Notification and User Profiles [9 / 9]
TeamCity UserGuide - Getting started with TeamCity
 

Practice 3 – Make Your Build Self-Testing

Here is just a short excerpt of tools and frameworks:

• UI tests: Selenium, Robot Framework, Protractor, WinAutomation
• Service tests: JBehave, FitNesse, SoapUI, JMeter Performance Tests
• Unit tests: JUnit, TestNG, Mockito (Mock Framework)

Practice 4 – Everyone Commits To the Mainline Every Day

Practice 5 – Every Commit Should Build the Mainline on an Integration Machine

Since branching and merging has become easier with Git, there are various workflows available on how to develop software with Git. The most popular one is called GitFlow.
Here is a list of various Git workflows and comparisons that you can examine, in case you want to learn more on the topic:

• Git Flow, Vincent Driessen
• GitHub Flow
• GitLab Flow
• Atlassian Git workflow comparison

Practice 6 –  Fix Broken Builds Immediately

Practice 7 – Keep the Build Fast

Practice 8 – Test in a Clone of the Production Environment

Practice 9 – Make it Easy for Anyone to Get the Latest Executable

Practice 10 – Everyone can see what’s happening

Practice 11 – Automate Deployment

To deploy your software you should use a single deployment script.
This deployment script will be used for deploying to every environment.
As a result you automatically test the script before doing an actual production deployment.

eMails with - SMTP, POP, IMAP, MAPI, unencrypted or encrypted with SSL or TLS

While refreshing my own understanding of mail authentication, I stumbled across two well written and clearly explained articles on:

SSL vs TLS: https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

Three ways a mail message can be handled:

·         Unsecured - no encryption (no SSL or TLS)

·         Explicit (port based) encryption (SSL)

·         Implicit (by protocol) encryption (TLS)

and

SMTP TLS: https://luxsci.com/blog/smtp-tls-all-about-secure-email-delivery-over-tls.html

The sending computer or server could be configured for:

1. No TLS — never use it.
2. Opportunistic TLS — use it if it is available, if not, send insecurely.
3. Forced TLS — use TLS or do not deliver the email at all

And for the record, while there are other mail protocols, the majority of our world will use one of four:

POP(3) (Receiving email)

• Port 110 - this is the default POP3 non-encrypted port
• Port 995 - this is the port you need to use if you want to connect using POP3 securely

IMAP (Interacting with remote email stores)

• Port 143 - this is the default IMAP non-encrypted port
• Port 993 - this is the port you need to use if you want to connect using IMAP securely

SMTP (Sending email)

• Port 25 - this is the default SMTP non-encrypted port
• Port 465 - this is the port used, if you want to send messages using SMTP securely
• Port 578 - Authenticated SMTP 

Exchange MAPI

MAPI is a way for applications and email clients to communicate with Microsoft Exchange servers,

and is capable of IMAP style syncing of emails, contacts, calendars, and other features, all tied into local email clients or applications.

This function of syncing emails is branded by Microsoft as “Exchange ActiveSync.”

• RPC - this is the default SMTP non-encrypted port

(TCP End Point Mapper port (TCP/135) and the dynamic RPC port range (6005-59530) for outgoing connections)

HTTP/HTTPS

                If using webmail clients but these already have the underlying POP or IMAP running between the mail server and the webmail (http) server

Exchange 2013 default ports

 

Other related links
Exch 2013 ports 
Exch receiver security settings
Outlook settings for POP and IMAP access for Office 365 for business or Microsoft Exchange