Virtual Academy by PurpleSynapz™ is now open for enrollment. Register now to avail 90% Discount. Use Coupon Code PSZ90 https://purplesynapz.virtualuniversity.io/explore
SUPPORT FOR HARD DRIVES BEYOND 2TB IN SECUREPLATFORM
Author: Gaurav Kumar
About Issue :
The 'fdisk' utility does not work correctly with hard drives beyond 2TB in size due to the fact that it works with Legacy MBR only : if the disk exceeds 2 TB - the maximum partition size representable using the 32-bit LBAs of the legacy MBR (assuming a 512 byte block size) - the size of this partition is marked as 2 TB, ignoring the rest of disk.
To be able to work with hard drives beyond 2TB size, a GUID Partition Table (GPT) standard for the layout of the partition table on a physical hard disk needs to be used.
Linux community provides a wide range of tools for partitioning MBR disks. Of the common tools, only those based on libparted library can handle GPT. Contact Check Point Support to obtain GNU Parted tool that was compiled for SecurePlatform.
A hard drive beyond 2TB size will have to be added as additional disk to the working machine. Using GNU Parted tool that was compiled for SecurePlatform, this additional disk will be partitioned, and added as a new partition under existing SecurePlatform OS.
Booting from hard disk than 2 TB is possible only when:
a) EFI mode is enabled in BIOS.
b) OS kernel supports EFI mode.
Currently, EFI is not supported by any Check Point OS (such support might be added in the future -
customers should contact local Check Point office to get the precise answer).
Meaning, Check Point OS can not be installed on a hard disk larger than 2 TB - such disk
can only be added to the machine as an additional disk. Then, if needed, a symbolic link can be
created (with 'ln -s' command) inside Check Point OS, so that relevant files are stored on
that additional hard disk.
This Process assumes at least advanced knowledge of Linux OS, partitioning of hard disks, and mounting of file systems.
a). Copy tool inside /var/tmp
rpm -ivh –force ilsiebel01_8168_5160_0_parted-1.6.3-29.i386.rpm
rpm -qa | grep parted
3. List the partition tables on the physical hard disks:
The new partition will be on a new hard disk.The new disk device will most likely be called /dev/sdb, and a message will say 'Disk /dev/sdb doesn't contain a valid partition table'
4. Verify Unallocated sectors :
Enter ” v “ while ask for command as shown below:
5. Check the name of new drive device (sdb, sdc, etc):
6. Start the tool:
Note: parted is using the drive device, on which the binary file resides : Using /dev/sda
7. Select the new drive device (it is forbidden to use this tool to partition the drive device, on which SecurePlatform is currently installed):
(parted) select /dev/sdb
Error may appear : Unable to open /dev/sdb - unrecognised disk label.
Note: this error is normal, since label was not created yet - ignore it.
8. Create a GPT label for new drive device (the labels are predefined - you have to create GPT label)
(parted) mklabel gpt
Note: The label is case-insensitive.
Verify that the label was created and get the disk geometry (example is given for HDD size 20 GB):
9. Create primary partition - do not specify the file-system type, but specify the start and end of the partition in MegaBytes (example is given for HDD size 20 GB):
10. Quit the tool:
11. Verify Created partition:
12. Create the file-system type EXT3 on the new partition:
mkfs -t ext3 /dev/sdb1
Note: on SecurePlatform 2.6, the default limitation of EXT3 file-system is 16TB and can be modified by specifying block-size argument for 'mkfs' command.
13. Mount the new partition with 'mount' command:
mount -t ext3 drive_device mounting_directory
14. Verify that partition was mounted with either 'mount' command or 'df' command (example is given for HDD size 20 GB):
15. Do not forget to update the /etc/fstab file, if necessary to mount the new partition automatically on each boot.
a). Backup /etc/fstab file: cp /etc/fstab /etc/fstab-org
b). Update /etc/fstab file as shown : vi /etc/fstab
16. Check current log directory for CLM as shown:
17. Stop all Check Point services on CLM:
18. Create a new directory:
mkdir -v -p /absolute_path/to/new/log_dir
19. Move the current directory $FWDIR/log:
mv $FWDIR/log $FWDIR/log_ORIGINAL
20. Configure the CLM to use the new directory:
create a symbolic link between the current directory $FWDIR/log/ and the new directory:
ln -s /absolute_path/to/new/log_dir $FWDIR/log
Explanation: By default, the FireWall Logs received from the managed Security Gateways should be stored in $FWDIR/log/. The underlying operating system will physically save the FireWall Log files based on the above symbolic link.
21. Start all Check Point services on CLM:
22. Check that the FireWall Log files are stored in the new directory:
[Expert@HostName]# ls -l /absolute_path/to/new/log_dir
For additional help or business inquiry, you can always reach out to us at email@example.com