Many people use SMIT when updating AIX and/or NIM but do not realise that they can also do this from the command-line using two IBM-supplied sctripts. Patches downloaded from Fix Central should all be in one directory e.g. "6100-08-02-1316".
Change to the directory containing the patches and ensure that it is writeable, so inutoc can create/update the index, all that the files are readable by root.
# cd 6100-08-02-1316
# inutoc .
Run the patch-install script:
# install_all_updates -d . -Y
+-----------------------------------------------------------------------------+
Summaries:
+-----------------------------------------------------------------------------+
Pre-installation Failure/Warning Summary
----------------------------------------
Name Level Pre-installation Failure/Warning
-------------------------------------------------------------------------------
sysmgt.websm.rte 6.1.7.1 Requisite failure
sysmgt.pconsole.rte 6.1.7.2 Requisite failure
perfagent.tools 6.1.7.2 Requisite failure
devices.vdevice.IBM.v-scs...
...
The results will not only be displayed on the screen but stored in "/var/adm/ras/install_all_updates.log".
You now reboot your system to ensure everything is working OK and once satisfied you can commit all the newly applied fixes in order to remove the old copies and save a lot of space in "/usr".
# installp -c ALL
# oslevel -s
6100-08-02-1316
If you are using NIM you will also want to update your LPP_SOURCE so that any new clients will be built to the same OS level. Fortunately this can also be done from the command-line:
Note: NIM can only be patched this way to TL (tech-levels) and not SP (Service Packs).
# cd <patch-directory>
# nim_update_all -d . -s 610spot_res -l 610lpp_res -v -u
+ typeset +f
+ typeset -ft DEBUG
+ typeset -ft _check_level
+ typeset -ft bname
+ typeset -ft check_access
+ typeset -ft check_cpush_ok
+ typeset -ft check_level
+ typeset -ft check_push_ok
+ typeset -ft ck_attrs
+ typeset -ft ck_gencopy_flags
+ typeset -ft ck_inst_root_dirs
+ typeset -ft ck_installp_flags
+ typeset -ft ck_rel_level
+ typeset -ft ck_spot_options
+ typeset -ft cleanup
+ typeset -ft cmd_what
+ typeset -ft convert_arch_value
+ typeset -ft create_sysb
+ typeset -ft err_from_cmd
+ typeset -ft err_signal
+ typeset -ft error
...
..
395266 of 422959 files (93%)....................
0512-003 mksysb may not have been able to archive some files.
The messages displayed on the Standard Error contained additional
information.
+ [[ 0 -ne 0 ]]
+ return 0
+ [ 0 -ne 0 ]
+ /usr/bin/tee -a /var/adm/ras/nim.update
+ /usr/bin/dspmsg -s 2 cmdnim.cat 338 \nNIM update_all is complete - enjoy!
NIM update_all is complete - enjoy!
Your SPOT and LPP_SOURCE should now be at the same level.
# lsnim -l 610spot_res
610spot_res:
class = resources
type = spot
plat_defined = chrp
arch = power
Rstate = ready for use
prev_state = verification is being performed
location = /export/eznim/spot/610spot_res/usr
version = 6
release = 1
mod = 8
oslevel_r = 6100-08
alloc_count = 0
server = master
Rstate_result = success
mk_netboot = yes
mk_netboot = yes
mk_netboot = yes
Translate
Thursday, 7 August 2014
Wednesday, 6 August 2014
Putting installp into debug mode
If you are having problems installing a product or patch try enabling "debugger mode":
# export INST_DEBUG=yes
# installp ...
# export INST_DEBUG=yes
# installp ...
Tuesday, 5 August 2014
Installing RPMs
Installing RPMs in AIX can be a real pain and a lot of time can be spent looking for the dependant packages etc. This is a quick tip which enables you to see a package's contents and dependencies without having to try to install it:
To see some background information:
# rpm -qpi ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
Name : sudo Relocations: (not relocateable)
Version : 1.8.9p5 Vendor: (none)
Release : 1 Build Date: Thu Feb 6 14:46:56 CET 2014
Install date: (not installed) Build Host: aix51.perzl.org
Group : Applications/System Source RPM: sudo-1.8.9p5-1.src.rpm
Size : 1571387 License: BSD
URL : http://www.courtesan.com/sudo/
Summary : Allows restricted root access for specified users
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis. It is not a replacement for the shell. Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.
Adding the "--changelog" argument also lets you see all the author's publising information:
# rpm -qpi --changelog ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
...
.
* Thu Feb 06 2014 Michael Perzl <michael@perzl.org> - 1.8.9p5-1
- updated to version 1.8.9p5
* Tue Jan 21 2014 Michael Perzl <michael@perzl.org> - 1.8.9p4-1
- updated to version 1.8.9p4
..
To see the dependencies:
# rpm -qpR ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
gettext >= 0.10.40
openldap >= 2.4.23
openssl >= 1.0.1f-1
zlib
/bin/sh
libc.a(shr.o)
libcrypto.a(libcrypto.so.1.0.1)
libintl.a(libintl.so.1)
liblber.a(liblber-2.4.so.2)
libldap.a(libldap-2.4.so.2)
libs.a(shr.o)
libz.a(libz.so.1)
You can also see the files in the package and importantly where it is going to be installed:
# rpm -qpl ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
/etc/sudoers
/opt/freeware/bin/sudo
/opt/freeware/bin/sudoedit
/opt/freeware/bin/sudoreplay
/opt/freeware/doc/sudo-1.8.9p5
/opt/freeware/doc/sudo-1.8.9p5/HISTORY
/opt/freeware/doc/sudo-1.8.9p5/LICENSE
/opt/freeware/doc/sudo-1.8.9p5/README
/opt/freeware/doc/sudo-1.8.9p5/TROUBLESHOOTING
/opt/freeware/doc/sudo-1.8.9p5/UPGRADE
/opt/freeware/libexec/sudo/group_file.so
/opt/freeware/libexec/sudo/sudo_noexec.so
To see some background information:
# rpm -qpi ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
Name : sudo Relocations: (not relocateable)
Version : 1.8.9p5 Vendor: (none)
Release : 1 Build Date: Thu Feb 6 14:46:56 CET 2014
Install date: (not installed) Build Host: aix51.perzl.org
Group : Applications/System Source RPM: sudo-1.8.9p5-1.src.rpm
Size : 1571387 License: BSD
URL : http://www.courtesan.com/sudo/
Summary : Allows restricted root access for specified users
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis. It is not a replacement for the shell. Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.
Adding the "--changelog" argument also lets you see all the author's publising information:
# rpm -qpi --changelog ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
...
.
* Thu Feb 06 2014 Michael Perzl <michael@perzl.org> - 1.8.9p5-1
- updated to version 1.8.9p5
* Tue Jan 21 2014 Michael Perzl <michael@perzl.org> - 1.8.9p4-1
- updated to version 1.8.9p4
..
To see the dependencies:
# rpm -qpR ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
gettext >= 0.10.40
openldap >= 2.4.23
openssl >= 1.0.1f-1
zlib
/bin/sh
libc.a(shr.o)
libcrypto.a(libcrypto.so.1.0.1)
libintl.a(libintl.so.1)
liblber.a(liblber-2.4.so.2)
libldap.a(libldap-2.4.so.2)
libs.a(shr.o)
libz.a(libz.so.1)
You can also see the files in the package and importantly where it is going to be installed:
# rpm -qpl ./sudo-1.8.9p5-1.aix5.1.ppc.rpm
/etc/sudoers
/opt/freeware/bin/sudo
/opt/freeware/bin/sudoedit
/opt/freeware/bin/sudoreplay
/opt/freeware/doc/sudo-1.8.9p5
/opt/freeware/doc/sudo-1.8.9p5/HISTORY
/opt/freeware/doc/sudo-1.8.9p5/LICENSE
/opt/freeware/doc/sudo-1.8.9p5/README
/opt/freeware/doc/sudo-1.8.9p5/TROUBLESHOOTING
/opt/freeware/doc/sudo-1.8.9p5/UPGRADE
/opt/freeware/libexec/sudo/group_file.so
/opt/freeware/libexec/sudo/sudo_noexec.so
IBM releases latest version of Cloud Manager
IBM is moving ever closer to Linux an Openstack with their latest software release:
http://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_com_sys-cloud-manager-with-openstack
The 90 day (IBM Partner) trial has a pretty hefty including copies of RHEL6, DB2, and MySQL, however if you have the time and a spare system I think it will be worth it.
I personally think that this is a very significant announcement as it gives a clear illustration of IBM's general future business strategy.
http://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_com_sys-cloud-manager-with-openstack
The 90 day (IBM Partner) trial has a pretty hefty including copies of RHEL6, DB2, and MySQL, however if you have the time and a spare system I think it will be worth it.
I personally think that this is a very significant announcement as it gives a clear illustration of IBM's general future business strategy.
Thursday, 31 July 2014
An alternative to dsh
This is an interesting way to run an SSH command on multiple systems:
http://www.unixmen.com/clusterssh-manage-multiple-ssh-sessions-on-linux/
http://www.unixmen.com/clusterssh-manage-multiple-ssh-sessions-on-linux/
Monday, 28 July 2014
An interesting LDAP feature
Many people use LDAP to store vital information such as usernames and passwords, and sudo rules, and this information should always protected as much as possible. The ideal soltion is to configure Secure LDAP and have all your traffic encrypted using a certificate. The problem is that you have to start somewhere and it is always easier to start with the most basic configuration, and add functionality as you go.
The easiest and supported method for configuring an AX server as an AIX client is to use the mksecldap command. This method not only configures the "/etc/ldap/ldap.cfg" configuration file, it tests the actual connection and adds an entry to the "/etc/inittab" which ensures that LDAP starts during boot.
ldapclntd:23456789:wait:/usr/sbin/start-secldapclntd > /dev/console 2>&1
Assuming everything is working you should be able to test your connection:
# ls-secldapclntd
ldapservers=ldap-server.mydomain.local
current ldapserver=ldap-server.mydomain.local
ldapport=389
active connections=1
ldapversion=3
usercachesize=1000
usercacheused=3
groupcachesize=100
groupcacheused=3
usercachetimeout=300
groupcachetimeout=300
heartbeat interval=300
numberofthread=10
connectionsperserver=10
authtype=UNIX_AUTH
searchmode=ALL
defaultentrylocation=LDAP
ldaptimeout=60
serverschematype=SFUR2
userbasedn=OU=AIX,DC=mydomain,DC=local
groupbasedn=OU=AIX,DC=mydomain,DC=local
userobjectclass=user,person,organizationalperson
groupobjectclass=group
and retrieve some data e.g.
# lsldap
dn: OU=AIX,DC=mydomain,DC=local
dn: CN=Builtin,DC=mydomain,DC=local
dn: CN=Computers,DC=mydomain,DC=local
d...
..
As you used a username (binddn) and password (bindpwd) to make the connection these credentials are stored in the "ldap.cfg" e.g.
binddn:CN=myhost,OU=AIX,DC=domain,DC=local
bindpwd:{DESv2}65 C1ADCD69A$F 973F44541DAC97E66A78DEF1B5FA97EFF
According to IBM this password has been salted and the file cannot be copied to another system, however this is not the case as you can actually create a single file and copy it to all your hosts, and just add the entry to "/etc/inittab" and this gives you a really quick way to build a test environment, however what happens if you want to change the password, or make every host bind using a different name?
The convential wisdom is to create an account that matches the hostname of each server. This works nicely but if you want to do this you also need to run mksecldap on each host, or do you?
If you are sticking to one user for all and just want to change the password you can simply run mksecldap on one host, disctribute the "ldap.cfg" and restart the daemons, however you create a new password by running:
# /usr/sbin/secldapclntd -e <new-password>
and then append this to the "bindpwd:" entry and recycle the daemon. The interesting part is that this new password is SALTED and so cannot be copied to another system, which means if you want to script this, it has to run on each target machine.
Note: If you are testing/are unsure about a password you can simply enter the plain-text, restart the daemon, and this will also work, but should obviously be repaced ASAP.
The other thing to consider is that if your LDAP server(s) is not available during boot, your AIX server will hang. It is therefore worth considering replacing "wait" with "once".
The easiest and supported method for configuring an AX server as an AIX client is to use the mksecldap command. This method not only configures the "/etc/ldap/ldap.cfg" configuration file, it tests the actual connection and adds an entry to the "/etc/inittab" which ensures that LDAP starts during boot.
ldapclntd:23456789:wait:/usr/sbin/start-secldapclntd > /dev/console 2>&1
Assuming everything is working you should be able to test your connection:
# ls-secldapclntd
ldapservers=ldap-server.mydomain.local
current ldapserver=ldap-server.mydomain.local
ldapport=389
active connections=1
ldapversion=3
usercachesize=1000
usercacheused=3
groupcachesize=100
groupcacheused=3
usercachetimeout=300
groupcachetimeout=300
heartbeat interval=300
numberofthread=10
connectionsperserver=10
authtype=UNIX_AUTH
searchmode=ALL
defaultentrylocation=LDAP
ldaptimeout=60
serverschematype=SFUR2
userbasedn=OU=AIX,DC=mydomain,DC=local
groupbasedn=OU=AIX,DC=mydomain,DC=local
userobjectclass=user,person,organizationalperson
groupobjectclass=group
and retrieve some data e.g.
# lsldap
dn: OU=AIX,DC=mydomain,DC=local
dn: CN=Builtin,DC=mydomain,DC=local
dn: CN=Computers,DC=mydomain,DC=local
d...
..
As you used a username (binddn) and password (bindpwd) to make the connection these credentials are stored in the "ldap.cfg" e.g.
binddn:CN=myhost,OU=AIX,DC=domain,DC=local
bindpwd:{DESv2}65 C1ADCD69A$F 973F44541DAC97E66A78DEF1B5FA97EFF
According to IBM this password has been salted and the file cannot be copied to another system, however this is not the case as you can actually create a single file and copy it to all your hosts, and just add the entry to "/etc/inittab" and this gives you a really quick way to build a test environment, however what happens if you want to change the password, or make every host bind using a different name?
The convential wisdom is to create an account that matches the hostname of each server. This works nicely but if you want to do this you also need to run mksecldap on each host, or do you?
If you are sticking to one user for all and just want to change the password you can simply run mksecldap on one host, disctribute the "ldap.cfg" and restart the daemons, however you create a new password by running:
# /usr/sbin/secldapclntd -e <new-password>
and then append this to the "bindpwd:" entry and recycle the daemon. The interesting part is that this new password is SALTED and so cannot be copied to another system, which means if you want to script this, it has to run on each target machine.
Note: If you are testing/are unsure about a password you can simply enter the plain-text, restart the daemon, and this will also work, but should obviously be repaced ASAP.
The other thing to consider is that if your LDAP server(s) is not available during boot, your AIX server will hang. It is therefore worth considering replacing "wait" with "once".
Thursday, 3 July 2014
Using Putty to login
We are being told everyday not to use simple passwords or to use the same password on multiple sites, which is good advice, however what is the best alternative?
If you use Putty to connect to your AIX or Linux systems you can create an OpenSSH key-pair using the PuttyGen application and then copy the key to your AIX host, which then enables you to login with requiring a password, however the disadvantages to this approach are:
One possible solution is to restrict root or your normal account(s) to SSH key-only authentication, and then set-up a restricted rescue-account that has as little functionality and privilege as possible except that it enables you to su/sudo.
Many hackers routinely scan port 22 for SSH services and then try to guess the root password so one possibility is to setup a dedicated service on port 443 as most firewalls allow HTTPS/SSL traffic, and hackers would not normally notice SSH on this port.
If you use Putty to connect to your AIX or Linux systems you can create an OpenSSH key-pair using the PuttyGen application and then copy the key to your AIX host, which then enables you to login with requiring a password, however the disadvantages to this approach are:
- There is no way to prevent a user from having a key without any pass-phrase, or to control the quality, content, or age, etc. Therefore if somebody has access to their PC they can login without a password, and/or steal the key.
- If you are at home, or in another remote location where you don't have access to your private-key file, and you have turned-off password authentication, you are stuck. This also applies if you lose the key file.
One possible solution is to restrict root or your normal account(s) to SSH key-only authentication, and then set-up a restricted rescue-account that has as little functionality and privilege as possible except that it enables you to su/sudo.
Many hackers routinely scan port 22 for SSH services and then try to guess the root password so one possibility is to setup a dedicated service on port 443 as most firewalls allow HTTPS/SSL traffic, and hackers would not normally notice SSH on this port.
Subscribe to:
Posts (Atom)