Debain on Power-7

You can now run Debian Linux on an IBM Power-7 system:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Debian%206%20on%20Power7%20LPAR

DB2 Express C (Community version)

This is a FREE, and FREELY DISTRIBUTABLE version of DB2:

http://www-01.ibm.com/software/data/db2/express-c/

Here is a nice gentle introductory video:
https://www.youtube.com/watch?v=yWUcYBYkbhk&list=PLA3171CB2CD7A21FA

This is also a nice resource:
http://bigdatauniversity.com/

Heartbleed OpenSSL fixes

IBM has produced security bulletins which contains a link to the latest OpenSSL updates:
http://www14.software.ibm.com/webapp/set2/subscriptions/onvdq?mode=18&ID=3499&myns=pwraix61&mync=E

http://www14.software.ibm.com/webapp/set2/subscriptions/onvdq?mode=18&ID=3494&myns=pwraix71&mync=E

http://www.ibm.com/support/docview.wss?uid=isg3T1020688&myns=swgother&mynp=OCSSNR5K&mync=E

Remeber that you should think very seriously about obtaining a replacement certificate once you have patched your system to ensure that your system is completely protected as it may already have been compromised, and your current certificate stolen.

DB2 Licencing

DB2 is installed from scripts and the licencing status can be hard to find. You need to locate the db2licm executable and then run it as follows:

# /opt/IBM/db2/V9.7/adm/db2licm -l
Product name:                     "DB2 Workgroup Server Edition"
License type:                     "Trial"
Expiry date:                      "07/13/2014"
Product identifier:               "db2wse"
Version information:              "9.7"
Max number of Value Units:        "480"
Max amount of memory (GB):        "64"

Product name:                     "DB2 Connect Server"
License type:                     "Trial"
Expiry date:                      "07/13/2014"
Product identifier:               "db2consv"
Version information:              "9.7"

or for the DB2 LDAP installation:

# /usr/opt/db2_08_01/adm64/db2licm -l
Product Name                            = "DB2 Enterprise Server Edition"
Product Identifier                      = "DB2ESE"
Version Information                     = "8.2"
Expiry Date                             = "Permanent"
Registered Connect User Policy          = "Disabled"
Number Of Entitled Connect Users        = "5"
Enforcement Policy                      = "Soft Stop"
Number of processors                    = "2"
Number of licensed processors           = "101"
Database partitioning feature           = "Not entitled"
Annotation                              = ""
Other information                       = ""

Product Name                            = "DB2 High Availability Disaster Recovery Option"
Product Identifier                      = "DB2HADR"
Version Information                     = "8.2"
Expiry Date                             = "Permanent"
Annotation                              = ""
Other information                       = ""

Product Name                            = "DB2 Advanced Security Option"
Product Identifier                      = "DB2ASO"
Version Information                     = "8.2"
Expiry Date                             = "Permanent"
Annotation                              = ""
Other information                       = ""

Improving name resolution performance

AIX 6.1 introduced the netcd daemon which caches protocol (e.g. DNS) resolutions. It is started by the SRC (System Resource Controller) from "/etc/rc.tcpip", however it is normally commented out/disabled and won't run unless you create a configuration file. The default file is "/etc/netcd.conf"

A really basic example is:

# cat /etc/netcd.conf
cache  all  protocols   600  1440
This caches all protocol resolutions with a hash table of 600 lines for 24 hours.

Once the file has been created you can activate the daemon after each reboot by editing the "/etc/rc.tcpip" as follows:

# Start up netcd daemon
start /usr/sbin/netcd "$src_running"

To manually start the daemon enter:
# startsrc -s netcd

To query it's status:
# lssrc -l -s netcd
Subsystem         Group            PID          Status
 netcd            netcd            12255406     active
Debug                     Inactive
Configuration File        /etc/netcd.conf
Configured Cache         local protocols
Configured Cache         dns protocols
Configured Cache         nisplus protocols
Configured Cache         nis protocols
Configured Cache         ulm protocols

The “/etc/netcd.conf” file has four different types of configurations:

_ Caching settings

_ Security settings

_ Log level settings

_ Daemon settings

The /etc/netcd.conf file has four different types of configurations:

1. Caching settings: You can specify what resolver should be cached:

    # cache <type_of_cache> <type_of_map> <hash_size> <cache_ttl>

    (default setting: cache all all 128 60)

    (example for a DNS cache: cache dns hosts 128 0)

type_of_cache                  Declares the type of cache. Possible values are all, local, dns, nis, nisplus, and yp.

type_of_map                    Declares the map to be used to do the lookup. Check netcd.conf man page or look at the sample file for a complete list.

hash_size                           Specifies the number of lines used for the cache. (An hash table is used to store the cache)

cache_ttl                            Declares the time to life for a cache entry. The unit is minutes. The TTL is not used for local resource caches.

If you specify a value other than 0 for DNS caches, it will overwrite the TTL of the DNS server response.

2. Security settings:

You can specify under which user and group a netcddaemon should be run. The default user is root and the default group is system.

3. Log level settings:

The netcddaemon creates a log file in /var/tmp/netcd.log. You can specify a different log file location, a log file size limit in KB, and the number of log file rotations. The default setting is no size limit and therefore no rotations are taken.

    Use this syntax to change the settings:

    log_file <file>

    log_rotate <number>

    log_size <number>

 

4. Daemon settings

net_scan_frequency      Specifies how often netcddaemon looks for expired cache entries in network caches. The unit is min., default is 1.

local_scan_frequency    Specifies how often the netcddaemon checks for changes to the local resources. The unit is minutes, default is 1.

socket_queue_size       Indicates the message queue size. The unit is the number of outstanding requests, default value is 256.

Dump cache content

With the netcdctrl command you can dump the cache contents to a file. The dump can be either in binary or ascii format. To dump the DNS cache in ASCII format use the following command:

# netcdctrl -t dns -e hosts -a /tmp/netcd.cache.out

Displaying caching stats with netcdctrl

# netcdctrl -t dns -e hosts -s /tmp/netcd.stats

# more /tmp/netcd.stats

CACHE dns, hosts, name

Hash index : 0, Max number of entries : 0, Current number of entries : 0

Heartbleed - Are your sites vulnerable?

There is a lot of conflicting information about the possible causes and effects of this exploit, and the best way to deal with it. Unfortunatletly there is no simple answer because a site may claim it is not effected because they upgraded last week, etc, but how about if you had an account since last year, before they patched, and you have not recently changed your password, or if they are effected, and yet to patch, what then? You could change all your passwords for everythng right now and then find you have to do the same thing again when you are sure that the dust has settled. You could also be foolish enough to use the same password for several sites and because you re-use your password on a safe site, somebody could still compromise this account because they know your password from another site that has already been compromised?

As if the situation was not complicated enough you also need to be sure that any effected site has also renewed their certificates after patching, otherwise they are still vulnerable!

One simple thing you can do right away is to see if the sites you use the most are on the list of effected sites: https://lastpass.com/heartbleed/

Capacity on demand

Have you ever wondered how you can find out which features were activated when your system was ordered?
All you need to know is your system serial number and this can easily be obtained by running:

 # prtconf | egrep "System Model:|Machine Serial Number:"
System Model: IBM,9111-520
Machine Serial Number: 659B6FC

Now open the IBM web page: http://www-912.ibm.com/pod/pod and enter your system type and serial number e.g.

System Type: 520
Serial Number: 65 - 9C8BF



















You can also learn more about the features ordered from:
https://www-304.ibm.com/support/docview.wss?uid=isg3T1010860


Note
The machine ID number contains 12 characters in the following digit format:
       xxyyyyyymmss. The xx positions indicate the system and is always 00. The yyyyyy
       positions contain the unique ID number for the entire system. The mm position
       represents the model ID. The ss position is the submodel number and is always 00.
       The model ID describes the ID of the CPU Planar, not the model of the System as a
       whole.

       Most machines share a common model ID of 4C.

Updating Wget

When you update AIX to a later level you may notice that many RPMs such as wget no longer work and may simply produce core dumps.

If this is the case you need to download the following RPMs (or later versions):

libidn-1.28-1.aix5.1.ppc.rpm
openssl-1.0.1g-1.aix5.1.ppc.rpm
openssl-devel-1.0.1g-1.aix5.1.ppc.rpm
openssl-doc-1.0.1g-1.aix5.1.ppc.rpm
wget-1.15-1.aix5.1.ppc.rpm

and then install/update your RPM as follows:

# rpm -Uvh ./*rpm
libidn                      ##################################################
openssl                     ##################################################
openssl-devel               ##################################################
openssl-doc                 ##################################################
wget                        ##################################################

Wget should now be working again:

# wget -h
GNU Wget 1.15, a non-interactive network retriever.
Usage: wget [OPTION]... [URL]...

Mandatory arguments to long options are mandatory for short options too.

Startup:
  -V,  --version           display the version of Wget and exit.
  -h,  --help              print this help.
  -b,  --background        go to background after startup.
  -e,  --execute=COMMAND   execute a `.wgetrc'-style command.

Log...
..

HeartBleed (CVE-2014-0160)

There seems to be a lot of mis-information at the moment and many pundits are suggesting that everyone should change their passwords NOW! Even stranger, they have even designed their own logo for the bug??

I would urge caution and say it is more sensible to wait and to see who is vulnerable, and when they applied the patch(es). Then, and only then would I suggest changing your passwords.

The fact is that if you have kept your AIX system up to date you are unlikely to have an old version of OpenSSL, and so not vulnerable to this particular exploit, however curiously there are reports that the latest versions are affected?

What we do know so far is that the following versions are NOT vulnerable:

OpenSSL 0.9.8
OpenSSL 1.0.0
OpenSSL 1.0.1g

Versions of OpenSSL 1.0.1 to 1.0.1f (inclusive) are vulnerable

A few days ago IBM issued a security advisory that can be accessed here:


http://aix.software.ibm.com/aix/efixes/security/openssl_advisory7.doc
https://aix.software.ibm.com/aix/efixes/security/openssl_advisory7.doc
ftp://aix.software.ibm.com/aix/efixes/security/openssl_advisory7.doc

Comparing Patches

It is vital to regularly update your system in order to ensure you have the latest and most stable version of AIX and its utilities, and to protect yourself against attack. Failure to keep your systems up to date can also mean that if you have to call support a lot time could be wasted installing patches before you can implement a satisfactory solution.

Fortunately IBM has some tools that can make the job of maintaining patch leves, and install updates, much easier. When you visit Fix Central and select your patches there is a compare report link next to each patch set e.g.

If you download this text file to your AIX system you can then use the compare_report command to see which fixes you need and how the level of your system compares to that of the patch-set. e.g.

# compare_report -s -r ./6100-08-00-1241.compare -h -v

This example will  generate a list of the patch-sets that are of a higher or lower level than those in the fix-pack. For more details see the compare_report man page.

Once you have downloaded your patch-sets to your system you can either install them from smit or  by using my preferred method:

Change to the directory where you dowloaded the patches and run:

# inutoc .
# install_all_updates -Yd .
install_all_updates: Initializing system parameters.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Checking for updated install utilities on media.
...
install_all_updates: Result = SUCCESS

(Where -Y accepts all licence agreements and -d identifies the directory where the patches are stored)

The installation command produces a handy report in"/var/adm/ras/install_all_updates.log" that can be used to analyse the results of the pactch operation.

Mounting NFS shares from a Linux server

Almost every Unix/Linux server, except IBM, has "portcheck" enabled, which means that an NFS client must use reserved ports when connecting to the server.  Fortunately this setting can be changed on the fly, and can also be made permanent. If you attempt to mount an NFS filesystem from a Linux server without portcheck, you will receive the following error:

# mount centos:/home/export /mnt
mount: 1831-008 giving up on:
centos:/home/export
vmount: Operation not permitted.

Once portcheck is activated, you can mount the filesystem:

# nfso -o nfs_use_reserved_ports=1
Setting nfs_use_reserved_ports to 1
# mount centos:/home/export /mnt
# df -g /mnt
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
centos:/home/export    401.31    239.08   41%   115639     1% /mnt

Managing portcheck

To activate portcheck:
# nfso -o nfs_use_reserved_ports=1

To deactivate portcheck:
# nfso -o nfs_use_reserved_ports=0

To make the change permanent:
# nfso -p -o nfs_use_reserved_ports=1

If this setting does not survive a reboot, you can  manually edit the "/etc/tunables/nextboot" file as follows:

nfso:
        nfs_use_reserved_ports = 1

# tuncheck -f /etc/tunables/nextboot

If interested in learning more about a tunable you can always use the "-h" option:

# nfso -h portcheck
Purpose:
Checks whether an NFS request originated from a privileged port.
Values:
        Default: 0
        Range: 0 - 1
        Type: Dynamic
        Unit: On/Off
Tuning:
Value of 0 disables the port-checking that is done by the NFS server. A value of 1 directs the NFS server to do port checking on the incoming NFS requests. This is a configuration decision with minimal performance consequences.

If nfs_use_reserved_ports=0 AIX server uses nonreserved IP port numbers above 1024 when the NFS client communicates with the NFS server.

If nfs_use_reserved_ports=1 AIX server uses nonreserved IP port numbers below 1024
when the NFS client communicates with the NFS server.