Translate

Friday 31 October 2014

Google announces intention to begin deprocating SHA1

Google has announced a provisional plan and timetable to begin reducing support for X.509 certificates that have been signed using SHA1. The industry is now beginning to replace the SHA1 algorithm in favour of SHA2 or perhaps SHA256 because as computers become more powerful, it is becoming more likely that criminals will be able to brute-force exisinting hashes or to produce fake messages that will have the same hash as a legitimate message.

A hash is a string of characters produced when a one-way encryption algorthim processes a message. This process enables a browser or program API to ensure that a message has not been tampered with.
It is meant to be impossible to find two messages that produce the same hash however in reality there are always are, and when this happens it is referred to as a "hash-collision".

An attacker can only find a collision by taking the hash of an existing message then hashing millions of other messages until one produces the same string. The problem for legitimate users is that once rainbow-tables containing multiple hashes start to appear, an attacker then only needs a relatively low powered computer to do a search of the tables.

What does this mean to you?

In simple terms you need to make an inventory of all your existing certificates and then determine when they are due for renewal, and how they were signed. You can then either gradually replace them now with certificates signed with SHA2 or buy new certificates when they expire. Great care and a lot of testing is required because some older browsers will not be able to process the new certificates and the users of your website will start to messages like this:





If you are using certificates on your AIX system you can use SystemScan to help you to find and document them.

Monday 27 October 2014

SUSE Linux Enterprise 12 is now available for IBM Power systems

SUSE has just announced  the release of SLES (Suse Linux Enterprise Server) version 12 for IBM Power and x86_64 servers. It is packed with new enterprise features such as full-system rollback, multi-pathing, and live kernel patching, which should reduce downtime and thus appeal to businesses that run critical workloads.

This release is designed for POWER-8 and uses the Little-Endian memory model (AIX and older Linux's are Big-Endian), is SMT8 (Simultaneous multi-threading) aware, and works with  PowerKVM.

Most Linux kernels use Little-Endian so this release increases IBM compatibility between Power and traditional x86 systems. The difference between LE and BE is simply the other that the memory bytes are stored, one starts at the left and works right, the other right to left e.g. if you had a number 123, one stores it in reverse 321.

Thursday 23 October 2014

Creating a system-wide core dump durectory


The syscorepath command was introduced in AIX 6.1 and enables a system administrator to set up a single system-wide directory in which to dump core files from any processes. This can ease administrative tasks in managing file-system space and provides a single, known directory in which to find core files. By default, the core file is created in the working directory of the process being core-dumped.

e.g. to store all your core files in "/core":



# syscorepath -p /core



Other useful switches are:

-c        Unsets the current directory specified as the repository for core files. Subsequent core files will be created in the working directory of the process.

-g         Displays current directory specified as the repository for core files.

Monday 20 October 2014

IBM to cease manufacturing processors

IBM continues to restructure itself from a manufacturer to a services business and the lates casualty is the the Power chip range:

http://www.computerweekly.com/news/2240232957/IBM-to-ditch-costly-chip-making-unit

Sunday 12 October 2014

Thinking of migrating to Linux? Here are some points to consider


This article describes how you can use a tool such as SystemScan AIX AIX to migrate from AIX to Linux


Preparation 

The first and possibly most important step in any migration project is to understand what you have now and to fix as many issues as possible. Things that cannot be fixed must be at least documented so alternative arrangements can be made.

1. Produce an accurate and detailed inventory of the existing systems.

SystemScan can scan an AIX system in minutes and provide an in-depth analysis highlighting issues such as missing packages, or differences between OS levels.

2. Make an inventory of the applications, workloads, and licences.

Creating an accurate inventory of your users, filesystems, applications, etc. can help you to understand what you need to migrate and perhaps buy new, or transfer existing licences and applications. It is also important to remember that an IBM Power chip is more powerfull than any Intel equivelant and thus can support far larger workloads, therefore you may require more licences in the Linux environment.

3. Compare users and groups on all systems and try to align (standardise) them where possible. E.g. Make user Oracle uid=200 on all systems.

a.      Consider using an external single-sign-on such as LDAP to migrate users
b.      Identify and where possible standardise any sudo rules

Reducing the amount of non-system users, and standardising UIDs etc. greatly reduces the amount of work required during a migration and reduces the risk of orphaned files. If possible try to map application IDs so that they are the same on Linux as AIX and use shared LDAP/AD users so that they can login to both the source and target with the same credentials, and their files are also available.

4. Create an inventory of any (host) keys and certificates.


a.      Consider replacing or renewing certificates possibly with more modern/secure versions. This is always a good idea as they may have been compromised and as computers become more powerful so ever longer key lengths are required to protect them.


b.      Create some kind of automated calendar or alert system to renew certificates before expiry.

SystemScan helps you to identify keys and certificates so the you can plan to transfer or replace them.

5.    Identify any workloads or partitions that cannot be migrated and/or are now longer required.


a.      Create a separate plan for decommissioning or long-term maintenance in or to maintain these worloads.

There are always going to be applications that are no longer supported, or are so old that there is no modern version, or perhaps they cannot even run on Linux. In this case you need to look for a replacement or plan to keep them running on IBM equipment by either leasing some dedicated kit or looking for a partner that can host it for you.

6.      Ensure the same software versions are available on Linux, e.g. Oracle 11i. If an upgrade is required research any data conversions etc.

a.      If the source and destination application are the same consider connecting both systems (Linux initially read-only) and test to ensure that the data can be used without any translation or conversion.

b.      If conversion is required you must plan for the identical amount of storage to be (temporarily) available to Linux in order to test migration etc.


7.      Check (equivalent) device-drivers are available on Linux and ensure that fibre-cards etc, can connect to the SAN or network at the same or improved speed.

8.      Patch the AIX environment as much as possible and do all possible hardening and tuning in order to ensure that the source systems are in the best possible state.

9.      Attempt to measure user perception(s) and experience in order to create a baseline otherwise users may attribute existing problems to the migration.

a.      Identify any known issues or bugs because if something is broken in source it will be broken in target.

10.  Use your current partition inventory to estimate the number of processors and memory sizings required for the target Linux systems.

11.  Create some test cases such as reading 10GB of data, or having 100 users simultaneously logged-in in order to create a PVU ratio e.g. one Power7 PROC=4 Intel PROCS, or one HP Blade can handle the equivalent workload as an LPAR with 0.4 VPROCS.

12.  Consult the application vendors such as Oracle to see if Intel has special requirements e.g. an AIX system with a 3GB SGA needs be increased to 4GB on Intel.

13.  Check if any special permissions are in place on AIX e.g. RBAC and ensure that there is a conversion plan.

14.  Ensure that any existing monitoring systems can handle both AIX and Linux, or that there is a migration plan.

15.  Check any existing backup data can still be recovered after the migration.

16.  Ensure there is a backup plan in place to replace the existing arrangements.

17.  AIX uses NIM and mksysb for provisioning and bare-metal recovery. Linux uses Kickstart in place of NIM, however there is no direct replacement for mksysb. Suggest using Storix as it works on both platforms.

a.      Create a Linux satellite server in order to centrally control the release and installation of patches.

18.  Ensure that Linux support and licencing is fit for purpose and is budgeted for going forward.

19.  Research all file-transfer (MFT) connections and where possible centralise them using a solution such as GoAnywhere as this will enable you to test both the source and target environments whilst maintain a central single point of control.

20.  If you intend to migrate middleware such as WMQ to an open-source solution you must also check that there is a way to compare both solutions and/or to run them in parallel using some kind of message gateway.

21.  Do you intend to do a big-bang, or a gradual conversion. In either case do you have adequate fallback and DR plans?

22.  How long do change requests etc take and what is the size of any change window? If you now this you can ensure that no change takes more than 40% of this Window in order to allow for management meetings and fallback decisions.

23.  Plan dry-runs and dress rehearsals.

24.  Decide whether the new solution will be locally or cloud-based and ensure that there are DR plans in place.

25 .Finally you should ensure that your LInux supplier can provide adequate support and there are suitable support arrangments in place.

Thursday 2 October 2014

Shellshock update

This site contains a lot of advice and some nice test tools to guage if you are vulnerable: https://shellshocker.net/#systemtest

There is an update avalable for AIX7.1 (bash-4.2-3.aix6.1.ppc.rpm) from: ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoo lbox/RPMS/ppc/bash/

Early indications are that this fixes the bug.