Anyone out there still running CyberGuard V2.x firewalls?
>
> Unfortunately my employer is, and I'm expected to keep them alive for
> another 6 months or so until the legacy application they are part of
> can be killed off.
>
> One of them failed after a power outage on the weekend - disk would
> not spin up. This is common enough, and usually not a problem - I just
> drop in another disk, boot from tape, and restore the latest backup tape. >
> Problem is, none of my miniroot tapes will boot - all 4 of them have
> gone bad. It's not the drive, I got the same result on 2 different
> machines, both of which read recent backup tapes just fine.
>
> I should be able to create a new miniroot tape on one of the running
> systems, but there's no documentation on how to do so. The backup
> tapes are created by a script "backupCYBERGUARD", which uses fdump. I
> found a release note which says the corresponding restore script
> "restoreCYBERGUARD" lives in /usr/src/cmd, but that directory is empty
> on my systems - so even if I manage to create and boot from a new
> miniroot tape, I don't have a copy of the restore script - it seems my
> only copies were on the bad tapes :-(
>
> I called CyberGuard's tech support, they were very nice but quite sure
> they had no V2.x archives, or any remaining staff with CX/UX knowledge. >
> If anyone still has a functioning CyberGuard V2.x miniroot tape, or a
> listing of restoreCYBERGUARD, or even perhaps enough CX/UX knowledge
> to explain how to restore backup tapes manually, I'd be most greatful
> if you would reply.
>
> TIA
I eventually figured this one out. There were clues in the backup script which suggested it might be possible to write a bootable backup tape, and the necessary miniroot binaries existed on one of the running systems. I was able to modify the backup script to create bootable backups, which of course included the restore script.
I took it a step further and also figured out how to add a second hard disk, write backups to it, and boot from it if the primary disk failed - not easy since CX/UX is a multi-level secure (MLS) system so you don't get to simply connect a drive and have the operating system acknowledge it - you have to rebuild the kernel and include proper labels for the new hardware. Similarly, you have to build a new kernel which has the second disk labeled as the boot disk and install it on the second disk as part of the backup to disk process.
I was able to keep these systems running reliably until they were finally retired a couple of months ago. Backup to disk was used twice due to primary disk failures. I kept two of the boxes, currently taking up space in my basement, because they run the only true MLS operating system I know of.
The security benefits of running an MLS OS are obvious. Why don't we have any available to us today?
Triffid