z/OS Distributed File Service zFS Administration
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Enabling the zFS auditid

z/OS Distributed File Service zFS Administration
SC23-6887-00

To enable the unique auditid, start by following scenario 2 with some new aggregates to verify that it does not cause problems for your installation. Then, use scenario 3 to convert the rest of the aggregates. The next time the aggregates are mounted, they have a unique auditfid.

Scenarios:
  1. You want all your aggregates to have the unique auditfid (and therefore, all auditids) use the new method:
    1. Do nothing. The default is convert_auditfid=on in your IOEPRMxx configuration file and new aggregates get unique auditfids by default.
    Result: Any existing aggregates are converted to the unique auditfid the next time they are mounted (attached). Newly formatted aggregates using IOEAGFMT, or zfsadm format get unique auditfids by default. IOEFSUTL format always creates unique auditfids.
  2. You want your new aggregates to have the unique auditfid and your existing aggregates to remain with the standard auditfid:
    1. Specify convert_auditfid=off in your IOEPRMxx configuration file.
    2. Specify (or default to) -newauditfid when you format new aggregates using IOEAGFMT or zfsadm format. Use IOEFSUTL to format new aggregates.
    Result: Old aggregates are not converted to unique auditfids when you mount (attach), but new aggregates have the unique auditfids.
  3. You want all your aggregates to remain with the standard auditfid (and therefore all auditids have the standard format):
    1. Specify convert_auditfid=off in your IOEPRMxx configuration file and specify -nonewauditfid when you use IOEAGFMT or zfsadm format to format new aggregates. Do not use IOEFSUTL format to format new aggregates.
    Result: Any existing aggregates are converted to the unique auditfid the next time they are mounted (attached). When you format new aggregates and specify the –newauditfid option, the aggregates have the unique auditfid.

Guideline: New aggregates formatted with ISHELL, automount allocany, allocuser, or the BPXWH2Z utility will not have unique auditfids after they are formatted. However, they will be converted to unique auditfids by default the first time they are mounted unless you specify convert_auditfid=off in your IOEPRMxx configuration file or specify zfsadm config -convert_auditfid off.

If a zFS aggregate is moved to another DASD location, the auditfid remains the same, unless you change it using the zfsadm setauditfid -force command. This is a trade-off between changing the auditfid, which causes auditids for the same file to be generated differently, versus not changing the auditfid, which causes auditids to remain the same but with the possibility that another zFS aggregate might get allocated with the first extent exactly in the place (and on the same volume) as the moved aggregate was located. This means that two different zFS files/directories might have the same auditid.

Even though the zFS auditid format is described, the internal contents of an auditid might not match exactly as stated. The VOLSER might not match the VOLSER of the volume containing the first extent because of moving the aggregate. The main use should be as an opaque number (that is, you should only use it to compare for equality of the whole auditid against another auditid).

Use the following algorithm to help distinguish between the unique auditfid, the standard zFS auditfid, and HFS auditid (which does not depend on the internal contents of the new zFS auditid):
If the last eight bytes of the auditid are binary zero, the auditid is zFS standard format
   Else, if the first byte of the auditid is X'01', the auditid is an HFS format
   Else, the auditid is the unique zFS format

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014