Hello Friends, This is Gaurav Gupta from Gurgaon, India. By profession I am an UNIX Systems Administrator and have proven career track on UNIX Systems Administration. This blog is written from both my research and my experience. The methods I describe herein are those that I have used and that have worked for me. It is highly recommended that you do further research on this subject. If you choose to use this document as a guide, you do so at your own risk.
So, in a followup to the Solaris RBAC configuration post, I wanted to show how quick and easy it is to configure RBAC. As an example, I’m going to be working with the Solaris reboot command, on the basis that many developers want to reboot their environments, but you don’t always want to give them root.
So, the basic steps are:
define a Profile
assign a command to the Profile
define a Role
assign the Profile to the Role
allow a user to use the Role
Easy stuff. First stage, let’s create the profile. Profiles live in /etc/security/prof_attr, and are a way to group together similar commands. If you look in that file, you’ll see a lot of existing profiles, which tie together common groups of Solaris commands.
Adding a new profile is easy - we just add an extra line to the end of that file:
# echo "Reboot:::Profile to reboot Solaris:help=" >> /etc/security/prof_attr
Breaking it down - the first field is the profile name, and the fourth field is the description. The rest of the fields don’t matter at this stage, for what we’re doing.
The new profile is useless without a command, so let’s add the Solaris reboot command. Commands associated with RBAC profiles live in /etc/security/exec_attr (can you see a pattern in the filenames yet?) and - again - this file is pre-populated with command Solaris commands, grouped by profile.
second field is the security policy - in this case, standard superuser
third field is the type - in this case, it’s a command
sixth field is the full path to the command
final field is the effective user ID the command is executed as
So far, it’s all pretty straightforward. Now we have a profile, and we have a command associated with that profile. Now we need to create a role.
RBAC roles are essentially normal user accounts, which have a restricted shell, and associated profile(s). The restricted shell is there to apply all the execution privilege and audit trail RBAC goodness.
Adding a role is nice and easy:
# roleadd -m -d /export/home/reboot reboot
64 blocks
Note the command line options to roleadd are the same as used when adding a normal Solaris user with useradd.
We also need to give the role a password:
# passwd reboot
New Password:
Re-enter new Password:
passwd: password successfully changed for reboot
And now we can see the role has been added to /etc/passwd:
# grep reboot /etc/passwd
reboot:x:1001:1::/export/home/reboot:/bin/pfsh
So it looks almost exactly the same as a normal Solaris user. Now all we need to do is add a profile to the role. We do this with the rolemod command, which - again - is very similar to the normal usermod command:
# rolemod -P Reboot reboot
Details of which profiles are assigned to roles - and which roles are assigned to users - live in /etc/user_attr - so we can look in there to see the changes we’ve made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
Finally we’ll add the role to our user account:
# usermod -R reboot tomk
UX: usermod: tomk is currently logged in, some changes may not take effect until next login.
And just look in /etc/user_attr to make sure the changes have been made:
# grep reboot /etc/user_attr
reboot::::type=role;profiles=Reboot
tomk::::type=normal;roles=reboot
We can use the roles command to see what roles we have available to us:
$ roles
reboot
However, logged in as myself I still can’t reboot the machine:
$ /usr/sbin/reboot
reboot: permission denied
And that’s because the profile is assigned to the role, not to my user account:
$ profiles
All
Basic Solaris User
The clue on how to use roles was in how they are created and stored - they’re just like normal users. So to access a role, we su to it:
$ su reboot
Password:
The moment we su to a role, the whole RBAC audit trail kicks in. Everything, from that initial su onwards, is logged and tracked. Unlike sudo, this logging continues, even if we change shells or become another user (if the role allows us to). It’s this unbreakable audit trail that makes RBAC so powerful.
Now that we’ve assumed a role, we can check out the profiles available to us:
$ profiles
Reboot
So we can now execute the reboot command and bounce the box:
$ /usr/sbin/reboot
Connection to 192.168.13.101 closed by remote host.
Connection to 192.168.13.101 closed.
Have a look at the configuration files and see all of the roles and profiles that come pre-configured with Solaris. Play about with them and get familiar with the terminology. RBAC isn’t difficult or complex - it’s just very different. Get comfortable with it and you’ll soon be able to leverage it’s power to really secure your Solaris machines without denying users any functionality
Booting problems poses serious challenge to the system administrators as system is down and no one can use it . This article tries to cover some of the general booting problems and their possible solutions to enable understand the problem cause and bring the system up very quickly.
Following are some of the booting issues ,error messages their meaning and possible solutions discussed in this article.
1) Booting in single user mode and mounting root disk
2) Making boot device alias
3) Timeout waiting for ARP/RARP packet”? error message
4) The file just loaded does not appear to be executable – error message
5) bootblk: can’t find the boot program – error message
1. Booting in single user mode and mounting root hard disk
Most important step in diagnosing the booting problems is booting the system in single user mode and examining the hard disk for possible errors & work out the corrective measure. Single user mode can be achieved by any of the following methods :-
ok> boot -s ;from root disk
ok> boot net -s ;from network
ok>boot cdrom -s ;from cdrom
Rebooting with command: cdrom -s
Configuring the /devices directory
Configuring the /dev directory
INIT: SINGLE USER MODE
#
# fsck /dev/rdsk/c0t3d0s0
# mount /dev/dsk/c0t3d0s0 /mnt
Perform the required operation on mounted disk , now accessible through /mnt ,& unmount the hard disk after you are done ;
# umount /mnt
# reboot
2.Making boot device alias
In case system can not boot from primary disk and it is needed to make another boot disk to access the data , nvalias command is used .
nvalias command makes the device alias and assigns an alternate name to a physical disk. Physical address of target disk is required which can be had by show-disk command on ok>.
boot block can not find the boot programe – ufsboot in Solaris .Either ufsboot is missing or corrupted . In such cases it can be restored from the cdrom after booting from cdrom & mounting the hard disk
Kernel directory or unix kernel file in this directory is not found .Probably deleted during fsck or deleted by mistake. Copy it from the cdrom or restore from the backup tape.
System can not find the /etc/path_to_install file .It might be missing or corrupted and needs to be rebuild.
To rebuild this file boot the system with -ar option :
ok>boot -ar
Press enter to select default values for the questions asked during booting and select yes to rebuild /etc/path_to_install
The /etc/path_to_inst on your system does not exist or is empty. Do you want to rebuild this file [n]? y
system will continue booting after rebuilding the file.
9. Can’t stat /dev/rdsk/c0t3d0s0
When booted from cdrom and done fsck the root partition comes out to be fine but on booting from root disk this error occurs. The device name for / is missing from /dev/dsk directory and to resolve the issue /dev & /devices directories has to be restored from root backup tapes .
How to Mirror root With Solaris Volume Manager in the Solaris 9 and 10 OS
Prerequisites
First, you need to identify the disks that you want to create mirrors with. You can do this by using the format command to find the disks in question.
Run the format command; below is an example of the output:
AVAILABLE DISK SELECTIONS:
0. c3t2d0
/pci@7b,0/pci1022,7458@11/pci1000,3060@2/sd@2,0
1. c3t3d0
/pci@7b,0/pci1022,7458@11/pci1000,3060@2/sd@3,0
In my example, I'm mirroring the root partitions along with the other partitions from the disk drive.
My drives are c3t2d0 and c3t3d0.
Procedure for Mirroring root
First, partition your primary drive, typically the one that the Solaris OS is currently running on. (In my case, this is drive 0, c3t2d0.) I traditionally do this during the installation of the Solaris OS to prevent data loss.
You will need one partition that is about 10 Mbyte for the meta database.
Once you are satisfied with the partition that you have created, ensure that you label the disk, and then perform the following steps to transfer the same partitioning table.
Transfer the partition table from one drive to another.
Note: Notice the use of s2, which is typically the overlap partition; if you changed this on the disk, please substitute the proper slice in its place.
Now that you have the two disks looking the same, execute the following:
metadb -a -c 3 -f c3t2d0s7 c3t3d0s7
The -c 3 creates three copies of the metastat database in this space, just in case a single copy gets corrupted (which is never good).
We will initialize the disk that makes up the root partition by doing the following. I'm using s0 because this is my root partition; you can substitute where appropriate.
metainit -f d11 1 1 c3t2d0s0
metainit -f d12 1 1 c3t3d0s0
Now we will create the actual mirror:
metainit d10 -m d11
After you have completed the preceding steps, you need to run the following command, which will automatically update /etc/system and /etc/vfstab to let it know that you are using a metadevice as your root disk.
metaroot d10
After you have executed the commands above, you need to reboot the machine before attaching the other half of the mirror to the root device. You can't attach a currently mounted device, or the machine will go crazy. In order to attach the device you will need to do the following:
metattach d10 d12
To check on the status of the mirror, you can do the following:
metastat d10
You will want to update the Openboot with the prior alias for the boot devices. You can do this by doing the following:
If you are mirroring just the two internal drives, you will want to add the following line to /etc/system to allow it to boot from a single drive. This will bypass the SVM Quorum rule
set md:mirrored_root_flag = 1
Please note that if you are running a Sparc platform you can use the installboot command in order to install the boot blocks onto the head of the drive.
For a UFS based File system you will use the below command.
