IRC-ing on AIX with EMACS ERC

Emacs ERC (M-x erc) is a IRC client built into newer releases of EMACS.

To build this you need the bos.adt sets and a compiler (gcc or xlc will do just fine).



Remember to set TERM=dtterm for colors :-).

Building Git Version Control System on AIX, HP-UX and Solaris

Git is a fast version control system originally designed for the Linux kernel and written by Linus Torvalds.
Need git on AIX or HP-UX? Here's how:

HP-UX PA-RISC 2.0:

First, you're going to need a compiler (GCC), GNU make (gmake) and GNU coreutils (install). swinstall the dependency repositories first:
coreutils 6.9 coreutils
gcc 4.2.3 gcc
libgcc 4.2.3 libgcc
libiconv 1.12 libiconv
make 3.81 make
perl 5.8.8 perl
zlib 1.2.3 zlib

Untar the package and start building:

$ ./configure --with-iconv=/usr/local/bin

Edit the Makfile:

CC = gcc
AR = ar
RM = rm -f
TAR = tar
FIND = find
INSTALL = /usr/local/coreutils/bin/install

# sudo gmake NEEDS_LIBICONV=1 NO_TCLTK=1 install prefix=/usr/local

$ which git
/usr/local/bin/git
$ uname -sr
HP-UX B.11.11
$ git --version
git version 1.5.4.4


Building GIT on AIX 5.3 POWERPC:

Install dependencies and GCC, gmake, GNU coreutils (install), etc:

gcc-4.0.0-1 libgcc-4.0.0-1 libstdc++-4.0.0-1 libstdc++-devel-4.0.0-1 gcc-c++-4.0.0-1 readline-4.3-2 readline-devel-4.3-2 zlib-1.2.3-3 zlib-devel-1.2.3-3 make-3.80-1 unzip-5.51-1 flex-2.5.4a-6 bison-1.875-3 popt-1.7-2 gettext-0.10.40-6 expect-5.42.1-3 tcl-8.4.7-3 tk-8.4.7-3 coreutils-5.2.1-2

$ ./configure

vi Makefile:

CC = /opt/freeware/bin/gcc
AR = ar
RM = rm -f
TAR = /opt/freeware/bin/tar
FIND = find
INSTALL = /usr/linux/bin/install
RPMBUILD = rpmbuild
TCL_PATH = /opt/freeware/bin/tclsh
TCLTK_PATH = /opt/freeware/bin/wish

# gmake NO_MSGFMT=1 install prefix=/opt/freeware

$ uname -a
AIX aix 3 5 004518FC4C00
$ which git
/opt/freeware/bin/git
$ git --version
git version 1.5.4.4

Solaris 10:

Solaris 10 comes with gcc, gmake and GNU tools in /usr/sfw/bin, but you'll need ginstall from GNU coreutils (you can get it from Solaris Freeware).

$ ./configure

Edit the Makefile - set the path to "ar", "gcc" and GNU "install".

CC = /usr/sfw/bin/gcc
AR = /usr/ccs/bin/ar
RM = rm -f
TAR = tar
FIND = find
INSTALL = /opt/sfw/bin/install

Look for ifeq ($(uname_S),SunOS) and set INSTALL to /opt/sfw/bin/install also.

# gmake NO_TCLTK=1 NO_CURL=1 install prefix=/opt/sfw

% uname -a
SunOS ibmsolaris 5.10 Generic_127112-11 i86pc i386 i86pc

% git --version
git version 1.5.4.4

GNU Screen for the win! - Solaris, AIX, HP-UX

I really love the hardstatus line in .screenrc :P. Just upgraded this machine to 8.3 too, so don't mind the title. (C-a A - OpenVMS-8.3) xD

Credits for the .screenrc hardstatus line go to Han:

log off
hardstatus alwayslastline "%{-b ck} %?%-w%?%{+b}%n%f %t%{-b} %?%+w%? %= %l %D %d/%m/%Y %0c "
hardstatus on
escape ^Tt

Wallpaper is some image off flickr + GIMP + my favorite palindrome:

In girum imus nocte, ecce et consumimur igni.

We enter the circle by night and we are consumed by the fire.
(Drawn like moths to a flame).



By popular demand:



GNU Screen works just fine with that hardstatus line even on HP-UX systems. One thing I did though, was use:

env TERM=xterm-color screen

To start screen after ssh-ing in. After screen starts, you'll probably want:

TERM=vt100; export TERM

Also. You can put them in your profile. Using TERM=screen doesn't always work well.

Of course, you can just use TERM=dtterm, or even use dtterm, as done here via ssh -X to my AIX server :-).



As you can see, the AIX and HP-UX versions need a bit more work (or a fixed sized terminal in case of AIX):

UNIX Deployment Tools - JumpStart, IgniteUX, NIM, KickStart, AutoYaST, FAI

Bare metal recovery and mass deployment tools for UNIX and UNIX-like systems:

On Windows there's RIS, WDS or tools like Ghost, on UNIX platforms we have tools like JumpStart, IgniteUX, NIM, FAI, KickStart, etc. to help with massive deployment of operating systems.

UNIX:

• Sun Solaris - Custom JumpStart and Advanced Installations - The custom JumpStart installation method is a command–line interface that enables you to automatically install or upgrade several systems, based on profiles that you create. The profiles define specific software installation requirements. You can also incorporate shell scripts to include preinstallation and postinstallation tasks. You choose which profile and scripts to use for installation or upgrade. The custom JumpStart installation method installs or upgrades the system, based on the profile and scripts that you select. Also, you can use a sysidcfg file to specify configuration information so that the custom JumpStart installation is completely hands-off.
• Sun Solaris - JumpStart Enterprise Toolkit: provides a framework to simplify and extend the JumpStart functionality provided within the Solaris Operating System.
  
• Sun Solaris Flash Archives (flar) - can be used with JumpStart technology to automate and speed up deployment or disaster recovery.
  
• HP HP-UX Ignite-UX - is an administration toolset that allows: Simultaneous installation of HP-UX on multiple clients, The creation and use of custom installations, The remote recovery of clients, The creation of recovery media.
• IBM AIX mksysb/mkcd/mkdvd: The mksysb command creates a backup of the operating system (that is, the root volume group). You can use this backup to reinstall a system to its original state after it has been corrupted. If you create the backup on tape, the tape is bootable and includes the installation programs needed to install from the backup.
• IBM AIX NIM - Network Installation Management - is an excellent feature of the AIX operating system and is very important for teams or companies that have a need to install or upgrade many RS/6000 machines with the same images at the same time. NIM supports the use of mksysb images. Performing a NIM mksysb installation is faster than performing a NIM rte installation, and with mksysb, you can optionally include other installed software. You can use a mksysb image to install the nodes of a CSM cluster.

Linux:

• RedHat Linux Kickstart provides automation of Linux installation that uses a single kickstart file to install the system on multiple machines.
• SUSE Linux AutoYaST - Automatic Linux Installation and Configuration with YaST2. AutoYaST allows unattended and automated installation. With AutoYaST, administrators can create a consistent baseline configuration for new installations in large or expanding deployments. In addition to AutoYaST, other installation methods include PXE Boot, CD-ROM, NFS, CIFS/SMB, HTTP, FTP, and the Service Location Protocol (SLP), which allows autodetection of install servers. ALICE, SuSEs former auto-installation system was a system built around the auto-installation features that were available with YaST1. In order to be able to use existing ALICE configuration files and resources, a special option is provided in the configuration system will let you convert ALICE configuration files into a control file readable by AutoYaST.
• Debian GNU/Linux FAI - Fully Automatic Installation - is an automated installation tool to install or deploy Debian GNU/Linux and other distributions on a bunch of different hosts or a Cluster. FAI can also be used for configuration management of a running system.
  

BSD:

• Automatic OpenBSD Installation - Jumpstart-style procedure for installing OpenBSD servers
• FreeBSD "JumpStart" Guide - This article details the method used to allow machines to install FreeBSD using the Intel PXE method of booting a machine over a network. Use sysinstall install.cfg for scripting.
• BSD PXEBoot - while not unassisted, BSD systems can easily boot from PXE and install over the network.
  

Tools:

• Cfengine - an adaptive system configuration management engine - is an automated suite of programs for configuring and maintaining Unix-like computers. It has been used on computing arrays of between 1 and 20000 nodes.
  

IBM's AIX 6.1 released, Open BETA ended

The AIX 6.1 open beta has ended, and AIX 6.1 has been released. Those with older processors such as Power 3 will need to upgrade (to POWER6, POWER5, Power 4 or PPC970 processors) if they plan to run AIX 6.1.

Cool new features in 6.1:

• Workload Partitions
  A new, software based, virtualization approach that complements the existing IBM System Logical Partitions by reducing the number of operating system images that have to be managed when consolidating workloads.
• Role Based Access Control
  Provides improved security and manageability by allowing administrators to grant authorization for management of specific AIX resources to users other than root by associating those resources with a role that is then associated with a particular system user.
• AIX Security Expert enhancements
  The AIX Security Expert has been enhanced to provide an option to store security templates directly in a Lightweight Directory Protocol (LDAP) directory—simplifying implementation of a consistent security across an entire enterprise.
• Name Resolver Caching Daemon
  The Name Resolver Caching Daemon is a new facility to cache host lookup information locally which can improve the performance of applications that access this type of information multiple times.
• probevue dynamic tracing
  probevue is a new dynamic tracing tool that can simplify debugging complex system or application code. This tool allows a developer or system administrator to dynamically insert trace breakpoints in existing code without having to recompile the code.
• System Director Console for AIX
  This new facility provides direct access to the System Management Interface Tool (SMIT) in a Web browser. The System Director Console for AIX is included with AIX 6 and does not require any other Web server or other software.

Backup and Recovery Primer - Part I: Backup Strategy

Backup Basics and best practice. Developing a backup strategy.

A proper backup strategy should be part of every disaster recovery plan. Every company should have at least a basic DRP, business continuity plan and employ risk management techniques.

Data backup and recovery falls in the prevention against data loss category, along side surge protection, interruptible power supplies (UPS), fire prevention systems, data security software (IDS, Antivirus Software, etc).

A backup is not a simple thing. You can't just throw your files on some random storage array every now and then and expect things to work out. A proper backup requires planning, a backup strategy, risk assessment and team work.

1) What does a backup strategy help us mitigate against?

• Disk failure. - Face it, disks fail. Often.
• Filesystem corruption or disk corruption, or other events that leave our disk in an inconsistent state. - I've seen this one too many times. You run out of inodes on a filesystem and you also need to run fsck on it, but you cannot. And you cannot mount it either. Or your filesystem decides to break, and corrupts your data. Filesystem corruption is more often in the case of power failures and forced shutdowns.
  
• File deletion and accidents: I've seen things like "# rm -rf $HOME/*" on a UNIX system (where the default root $HOME is /, of course) and various other accidents using pipes or dd. And it's usually easier to restore files from backup than to try to restore them after you've erased them. Also, allowing testing and development on production systems will eventually lead to such accidents taking down your main production database sooner or later...
  
• Stolen or destroyed disks / machines. Laptops are especially vulnerable to this.
• Tampering with the data: Viruses, exploits, hackers may modify and tamper with your data. You may need to perform a roll-back to a previous state of your data.

But, most important, a proper backup strategy will save you and your company money. Data loss and downtime will lead to financial losses due to lost customers, wasted money, image and reputation loss, morale going down among your staff or even legal problems. Not to mention there are things that simply cannot be recreated once lost, like access logs and such.

You must fully understand why you need a backup strategy, what it is you're protecting (don't just think of data, think of your companies reputation, your job security, loss of revenue and such).

2) Who is responsible for the integrity of the data

The data owner. Which, in most cases, is upper management. It's management's responsibility to do a risk assessment, and deploy the proper business continuity and disaster recovery plans. They often decide to delegate permissions and responsibility to such tasks down the chain of command.

3) What do you make backup copies of?

Just your production database? The whole system? Just the critical data tables?
It's your responsibility to asses what data is critical, how long it would take to restore a system in case of a disaster (hope for the best, but expect the worse. Can you cope with a fire? How about and earthquake? How about a disgruntled employee purposely altering or erasing your data?).

4) How often do you backup?

Do you need continuous data protection (CDP)? Can you accept loosing a day's work? How about losing one day of everyone's work? If you have 1000 users, that may as well be 3 years worth of work right there, in a single day. What will that cost you?

5) How do you backup?

Will you be using tapes? Will you purchase a storage array and use it for backup purposes? Will you be using optical media? Are you going to do this across the network? How will the network cope with the load generated by the backup?

What software will you use? How much does it cost? What about the total cost of ownership? Will future versions be supported and be able to access older backups?

Are you storing all the relevant information to restoring your systems? How about permissions or disk volume / partition configuration?

6) Where will you store your backup?

Doing a backup on the same disk, or on the same disk on the machine you're backing up is usually a very bad idea. Or leaving the tape in the tape drive or on top of your machine. Think about it. That tape probably contains vital and confidential information. You don't want it to go up in flames with your production systems, or get stolen along with the confidential business records it contains. You really need to evaluate all possibilities in terms of on-site storage (fire-proof tape safe, tape robots or even a simple storage cabinet) as well as off-site storage.

Also, consider online backup vs. offline backup. Consider something as simple as a rsync-snapshot/rsnapshot/rsync-with snapshots or as complex and powerful as Sun's StorageTek Availability Suite.

7) Monitoring and testing

Don't just dump the fs content to a tape and leave it there. Test and monitor your backup and restore procedures.

Test your backup software. Some companies even go so far as to test a new backup solution for years in parallel to the old solution before committing themselves to using only the new backup method.

Always keep your backup policy up to date. Make sure your plans and strategies reflect real life situations.

8) Restoring data

Backups in themselves have little importance. It's restoring the data that matters. How will you get data off those tapes / cds? How long will it take? Will you have your system up and running to a satisfactory baseline, fast? How about restoring individual files from a certain point in time? Say a user requires an 3 month old email. What will you do then, restore the whole mail database, from 23 tapes by restoring a full backup, the incremental, the differentials, etc? That wouldn't be too much fun, now would it...

It's usually a good idea to take a layered approach to backup. Like in Windows, you have System Restore to revert to a previous state of the operating system, Shadow Copies to restore older versions of files, you have ntbackup to do a system state, registry and filesystem backup, and Windows Complete PC Backup (or tools like Norton Ghost) for bare metal recovery.

Make sure your mail server stores emails for a certain period of time. Have your log servers store logs and rotate / archive them at a specific interval. Here is where products like QFS / SAMfs really shine.

The idea is simple. It's a lot easier to restore and manipulate files from lower backup levels than it is to manipulate bare metal recovery backups or full filesystem backups.

9) Scalability

Data within a company grows at an exponential rate. As data grows, so will your backup needs. You will need to plan ahead, make sure all your backup systems are scalable and can handle growth. If you hit some weird limitation (like with some filesystems for example, that can't grow beyond 1-2 TB and so on), that's pretty much it..

Also, make sure that while your systems are scalable, they don't grow beyond your power to manage them. Keep things simple and easy to understand. Document everything.