Update Tru64 4.0F -> 5.0A

[Ricardo Lima Caio]

Please,

I am trying to update a Tru64 version 4.0F OS to 5.0A.
After the load stage, when the server boots with the new OS version already, and shows the login screen, it does not accept the password for the root user and all the other users.
After some tries, it shows the following message:

'The security databases are corrupted. However, you can login ...'

What can i fix the security databases ?

Thanks in advance,
Ricardo

[Ann Majeske]

Ricardo,

Were you running Enhanced Security on V4.0F? Why are you updating to V5.0A? V5.0A is no longer supported.

Ann

[Ricardo Lima Caio]

In response to your questions, Ann

> Were you running Enhanced Security on V4.0F? Yes, I am running Enhanced Security.

> Why are you updating to V5.0A? V5.0A is no longer supported.
I am updating to version 5.0A, because is a mandatory path to V5.1A, that is the version asked by Oracle 9i R2.
I will need to update again to 5.1A, as soon as the first update finishes.

Ann

[Ann Majeske]

Hi Ricardo,

The format of the Enhanced Security databases changed between V4.0F and V5.0A. The installupdate should have converted the databases automatically. I'll see if I can find out what the installupdate should have done to do the conversion.

Try to log in to the console as root. If you can't, you'll have to bring the system up in single user mode to fix the security databases. When you do, try running authck -a to see if it gives us any interesting information about the state of the databases and let me know what it says.

For future reference, I've been told that there are "problems" with installupdate to V5.0A and that the migration path V4.0F -> V4.0G -> V5.1 -> V5.1a (or b) is a better choice even though it is more steps.

Ann

[Johan Brusche]

Patch and correction script in attachement/


The on-disk format of the Enhanced Security databases changed between
Digital Unix V4.0F and Tru64 Unix V5.0. An installupdate from Digital
Unix V4.0F to Tru64 Unix V5.0a on a system with Enhanced Security
enabled will not correctly convert the Enhanced Security databases to
the new file format and subsequent login attempts will fail. The
following messages are displayed in the

/var/adm/smlogs/it.log file:

it.log: db_load: /tcb/files/auth.db2: Bad file number
it.log: db_load: /var/tcb/files/auth.db2: Bad file number

A workaround to this problem is to first update from 4.0F to V5.0, then
to V5.0A.

Alternatively, the files contained in this patch kit may be applied
before and after the upgrade from Tru64 Unix V4.0F to Tru64 Unix V5.0a
with Enhanced Security enabled to correct the database file format
problem.
The patch procedure described here should be carefully followed in
order to ensure successful implementation.

FILES TO BE DISTRIBUTED

/usr/shlib/libsecurity.so
upd_C2_50a.sh

INSTALLATION INSTRUCTIONS

Assume the patched files are temporarily placed in the directory
/patches. Before performing the installupdate to V5.0A, as root:

# cd /usr/shlib
# cp /patches/libsecurity.so libsecurity.so.new
# chown bin:bin libsecurity.so.new
# chmod 644 libsecurity.so.new

# cd /
# cp /patches/upd_C2_50a.sh upd_C2_50a.sh
# chown root:system upd_C2_50a.sh
# chmod 755 upd_C2_50a.sh

After performing the installupdate to V5.0A, shut the system
down then boot to single user mode. Once in single user mode,
at the prompt:

# cd /usr/shlib
# cp libsecurity.so libsecurity.so.orig
# mv libsecurity.so.new libsecurity.so

# cd /
# ./upd_C2_50a.sh

After performing the above tasks, reboot the system to multi-user
mode.

[Ann Majeske]

Hi Ricardo,

I looked at the script that is run to update the security databases. The script is OSFC2SEC.scp. That script did not change from V5.0 through V5.1B. So, I think the two most likely scenarios that we have here are: 1) The script did not run; 2) There was an error running the script.

So, the first thing to do is to check to see if there are any errors related to the security databases (ttys.db and auth.db) and/or any messages at all pertaining to OSFC2SEC.scp in the installupdate log: /usr/adm/smlogs/update.log.

If there are errors, the fix to your corruption depends on what the errors are.

If OSFC2SEC.scp just didn't run, it looks like you can just do the following:
Save existing db files:
# cp -p /etc/auth/system/ttys.db /etc/auth/system/ttys.db.save
# cp -p /tcb/files/auth.db /tcb/files/auth.db.save
#cp -p /var/tcb/files/auth.db /var/tcb/files/auth.db.save
Convert the files to the new format, do the following for each file:
# /usr/tcb/bin/db_dump185 -p /etc/auth/system/ttys.db | /usr/tcb/bin/db_load /etc/auth/system/ttys.db2
# /sbin/mv /etc/auth/system/ttys.db2 /etc/auth/system/ttys.db
Change the ownership and permissions to be the same as the original db file.

Ann

[Ann Majeske]

Never mind, Johan's answer is correct!

Ann

[Michael Schulte zur Sur]

Hi Robert,

there is another thing to consider, when you take the update path via 5.0A. There is a cdrom patch, which you should apply before going to 5.1A, otherwise the dates from the cdrom might be misread and the kernel build will fail after the update.

Michael

[Ralf Puchner · Accepted solution]

next step is to boot into single user mode

>>> boot -fl s

deactivate C2

# mount -a
# secconfig
(change from enhanced to base)

now you will be ask for a new password. Enter it, delete C2 database directory and switch back to C2. Another approach is to use authck to check databases after switching back to enhanced without deleting C2 database directory.

[Spider Boardman]

Ralf's advice will hurt anyone running V5.x worse than the original reported situation, for which the correct fix has already been posted. [He said to delete required inventory without which you can't return to Enhanced Security in V5.x.]

[Ralf Puchner]

Spider,

sorry but this procedure have worked on many system which have reported similar problems.
It is easy, requires no skills and worked several times. It will not fix the C2 database problem itself that is right, but it is a starter to recreate the C2 environment after restoring an old database file (if v5.x system runs before) or to start from scratch after removing the C2 files (e.g. replacing the current files within /etc/auth/system with the "." template files).