How to convert a rootvg from jfs to jfs2

1. Create an /image.data file
# mkszfile


2. Edit the /image.data file to create JFS2 filesystems


I edited each of the fsdata stanzas converting


fs_data:
FS_NAME= /opt
FS_SIZE= 131072
FS_MIN_SIZE= 12320
FS_LV= /dev/hd10opt
FS_FS= 512
FS_NBPI= 4096
FS_COMPRESS= no
FS_BF= false
FS_AGSIZE= 8


to


fs_data:
FS_NAME= /opt
FS_SIZE= 131072
FS_MIN_SIZE= 12320
FS_LV= /dev/hd10opt
FS_JFS2_BS= 4096
FS_JFS2_SPARSE= yes
FS_JFS2_INLINELOG= no
FS_JFS2_SIZEINLINELOG= 0


I edited each jfs lv, changing "TYPE = jfs" to "TYPE = jfs2".
I also edited the jfslog to be TYPE = jfs2log.


3. Edit /etc/filesystems and for each jfs filesystem in rootvg, change
"jfs" to "jfs2" in the vfs line. Check that each filesystem has
options = rw.


Here's an excerpt from my edited /etc/filesystems file.


/:
dev = /dev/hd4
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = root
free = true
account = true
options = rw


/home:
dev = /dev/hd1
vfs = jfs2
log = /dev/hd8
mount = true
check = true
free = false
account = true
options = rw


/usr:
dev = /dev/hd2
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
free = false
account = true
options = rw


4. Take the mksysb, but without the -i flag (since that will create a
new /image.data file, overwriting your amended one).


5. Restore the mksysb as normal.

Steps required to replace a failing PV from a non-root VG

--> Backup all filesystems found on the failing PV.
--> lspv -l (lspv -l hdisk2) To determine which filesystem(s) are found on the PV in question.

--> Find out how the LVs are laid-out on the PV so you will know how to re-create them when the time comes.
lslv -m (lslv -m oracle) You will use the output of the lslv command to serve as a template for creating a map file for this LV later on.

--> Unmount all filesystems on that PV. umount to unmount each filesystem from the PV in question.

--> Remove all LVs found on that PV. rmlv (rmlv /oracle)

--> Remove the questionable PV from the system. reducevg

--> Remove the PV entry from the ODM database. rmdev -l -d (rmdev -l hdisk2 -d)

--> Shutdown the system: Shutdown -F

--> Remove the bad PV and install the new PV

--> Add the new PV to the VG in question. extendvg (eg., extendvg datavg hdisk2)

--> Re-create the LVs removed from the OLD PV to the NEW PV.
mklv -y -m (mklv -y oracle -m oracle.map oraclevg 200 hdisk2)
The map file is assembled from the output generated from the lslv -m command in step 2 above. Do this for each LV that existed on the removed PV.

--> Re-size the filesystems on the new PV. mkfs /dev/ (mkfs /dev/oracle) Do this for each file system that existed on the removed PV.

--> Perform a filesystem check before mounting it. fsck -f /dev/ (fsck -f /dev/oracle)

--> Mount all filesystems on that PV. mount (mount /oracle)

--> Now restore the data you backed up

Regaining root's password

1) Boot from a cd-rom or a bootable Tape.

2) Press F5 or 5.

3) Select option 3 from installation and maintanance menu: Start maintanance menu for system recovery.

4) Follow the option to activate the root vg and obtain the shell.

5) Once a shell is available then run the passwd command to reset the password for root.

6) sync

7) Reboot the system.

REMOVING UNWANTED FILES

Removing Obsolete Files

Occasionally, you need to remove unwanted and unneeded files from your system. AIX provides you with the skulker command, which allows you to automatically track and remove obsolete files. This facilityworks on candidate files located in the /tmp directory, executable a.out files, core files, and ed.hup files.

To run the skulker command, type
# skulker -p

You can automate the skulker command by setting up the cron facility to perform this task regularly.






Removing Unowned Files

When a user ID is removed, that user’s files then have no owner assigned to them. To identify files that have no owner, you can use the find command as follows:
# find / -nouser -ls

After identifying files that have no owners, determine whether the files are needed. If they are needed, assign them to a different user. Otherwise, you can remove those files from the system.





Managing Unauthorized Remote Host Access

Some programs use the .rhosts file to gain access to a system. In some cases, access can be granted to unauthenticated users. To avoid this situation, remove the .rhosts file from your system.
For HACMP clusters, .rhosts files are required. Instead of removing them from these configurations, set the permissions to 600 and assign ownership of the files to root.system.

To find .rhosts files, run the following command:
# find / -name .rhosts -ls






Monitoring Executable Files

To monitor the activity of critical executable files, you need a good understanding of how these files are being used. The executable files that you need to monitor are those that are owned by root and have either their SUID or SGID bits set.
After carefully monitoring these files during normal system activity, you can generate a report that includes a list of files that are normally executed. You can then contrast that report with subsequent reports that show new files with these attributes that were set without your knowledge. To create the baseline report, run the following commands:
# find / -perm -4000 -user 0 -ls
# find / -perm -2000 -user 0 -ls

Changing the CDE login screen

This security issue also affects the Common Desktop Environment (CDE) users. The CDE login screen also displays, by default, the host name and the operating system version. To prevent this information frombeing displayed, edit the /usr/dt/config/$LANG/Xresources file, where $LANG refers to the local language installed on your machine.

In the Example assuming that $LANG is set to C, copy this file into /etc/dt/config/C/Xresources. Next, open the /usr/dt/config/C/Xresources file and edit it to remove welcome messages that include the host name and operating system version.

Securing unattended Terminals

Always lock your terminal when it is not being attended to prevent unauthorized access. Leaving system terminals unsecure poses a potential security hazard. To lock your terminal, use the lock command.

Changing the login screen welcome message

To prevent displaying certain information on login screens, edit the herald parameter in the
/etc/security/login.cfg file. The default herald contains the welcome message that displays with your login prompt. To change this parameter, you can either use the chsec command or edit the file directly.
The following example uses the chsec command to change the default herald parameter:
# chsec -f /etc/security/login.cfg -a default -herald "Unauthorized use of this system is Prohibited.\n\nlogin: "

To edit the file directly, open the /etc/security/login.cfg file and update the herald parameter as follows:
default:
herald ="Unauthorized use of this system is prohibited\n\nlogin:"
sak_enable = false
logintimes =
logindisable = 0
logininterval = 0
loginreenable = 0
logindelay = 0