 |
Unix - Storage FAQ
This page is about Unix - Storage related FAQ.
Unix & Storage Admins, can post their questions here
ALSO VISIT MY HOMEPAGE MORE INFO http://unixsa06.googlepages.com
Question1: What If you forget/loost Solaris Password
Load the Solaris cdrom (This does not have to be the same Solaris version as the machine.)
Take the machine down to the PROM level -
# init 0 (or halt)
When it comes down to the OK prompt -
OK boot cdrom -s
When it is back up -
# mount /dev/dsk/c0t0d0s0 /a (your root device/partition)
# fsck /dev/dsk/c0t0d0s0 (optional, if you can't mount disk)
# cd /a/etc
# TERM=vt100;export TERM
# vi shadow and remove second field on root line
The root line should like -
root::12345:::::: (it must start root:: the other values are not important)
wq! (or x!)
init 6 (or reboot)
When the machine comes back up -
passwd (set a new root password)
Question 2. How to clean bad image header in a catalog backup (VNB)?
1) 'Bad Image Header' Message
++++++++++++++++++++++++++++++++++++++++++++++
INFO: One of the files that holds info about one of the client's backups was not cleaned up after the backup was terminated abnormally.
This usually happens when the partition gets full, or the backup or master server terminates abnormally.
NetBackup cannot clean up these catalog image files.
They must be done manually. Follow the procedures below.
======================================
Run the DATABASE IMAGE CHECK
======================================
A) Check the image directories on master server with:
/usr/openv/netbackup/bin/bpdbm -consistency > /tmp/DBreport.txt
This report can be run when backups are running.
Monitor for completion ps -ef|grep consistency
B) When complete, search the report file created in step above for Bad images
egrep "directory of|Bad image" /tmp/DBreport.txt > /tmp/bad_images.txt
EXAMPLE :
If the bad_images.txt says something like this:
check directory of client
check directory of client
check directory of client
Bad image header: BA_01_System_W2K_1085982754_INCR
Bad image header: BA_01_System_W2K_1085982755_INCR
Bad image header: BA_01_System_W2K_1085982756_FULL
check directory of client
check directory of client
From this output, Client s008a70 is showing 3 problem images
do the following to remove the 3 bad images:
# cd /usr/openv/netbackup/db/images/s008a70/1085000000
# ls BA_01_System_W2K_1085982754_INCR*
BA_01_System_W2K_1085982754_INCR
# rm BA_01_System_W2K_1085982754_INCR*
# ls BA_01_System_W2K_1085982755_INCR*
BA_01_System_W2K_1085982755_INCR
BA_01_System_W2K_1085982755_INCR.f
# rm BA_01_System_W2K_1085982755_INCR*
# ls BA_01_System_W2K_1085982756_FULL*
BA_01_System_W2K_1085982756_FULL
BA_01_System_W2K_1085982756_FULL.f
# rm BA_01_System_W2K_1085982756_FULL*
Also check the catstore directory that may have some of these image files
# cd /usr/openv/netbackup/db/images/s008a70/1085000000/catstore
# rm BA_01_System_W2K_1085982754_INCR*
# rm BA_01_System_W2K_1085982755_INCR*
# rm BA_01_System_W2K_1085982756_FULL*
C) Then initiate the catalog cleanup manually per these commands in the technote below:
# touch /usr/openv/netbackup/bin/CLEAN_IN_BACKGROUND
# /usr/openv/netbackup/bin/admincmd/bpimage -cleanup -allclients
Technote for CLEAN_IN_BACKGROUND
http://seer.support.veritas.com/docs/236274.htm
You can leave the CLEAN_IN_BACKGROUND in place. It does not need to be removed.
++++++++++++++++++++++++++++++++++++++++++++++
How to decode the 10 digit UNIX timestamps
To decode the unix timestamp used in files and directories
/usr/openv/netbackup/bin/bpdbm -ctime 1031286584
1031286584 = Thu Sep 5 23:29:44 2002
Unix Security Features:
Unix Security Policies
1.0 Identify and Authenticate Users
1.1.1User ID
The /etc/passwd file provides a map of UIDs and login names.User access control in the kernel is based on UIDs. Two different login names with the same UID are seen internally as the same userid even though they may have different passwords.Login names and UIDs in /etc/passwd must be unique in order to be able to individually identify users and to preserve accountability and auditability.
1.1.2PAM Authentication (REDHAT and SOLARIS)
PAM (Pluggable Authentication Modules) should be used on all systems to comply with the
authentication requirements in this document that are not supported by the base operating
system.
REDHAT: Add the setting to enforce a default no access policy in the file /etc/pam.d/other.
auth required /lib/security/pam_deny.so
account required /lib/security/pam_deny.so
1.1.3Root: The root account (UID 0):
The UID 0 provides total privileged authority. UID 0 is normally associated with userid root. Access to privileged authority by sharing passwords to accounts with privileged UIDs/GIDs is permitted. Direct login access to the root account must be restricted to the physical console device.
The following root requirements must be met.
The root account must be the only account with the uid of 0.
The root account must be the only user account that is a member of the root group (if it
exists).
The root account must be defined locally on each system.
The root account must have a password assigned during installation.
The root account must not have a /root/.rhosts or /root/.netrc files, or if they do exist they must be empty, chmod 0, owned by user root and group sys.
Root’s login script must not utilize any file not owned by root or owned by operating system accounts which are group or world writable.
Root cron jobs must only execute files owned by root or owned by system accounts without shell access and the files must not be group or world writable.
Absolute path names should be utilized when executing commands as root. (ex. /bin/su) This is to prevent root from accidentally executing a trojan horse. Minimally, root’s $PATH environment variable must not include the relative current directory (.), relative sub directory (./) or any relative parent directory (..)
All non-console root access must require the administrator to log in using sudo if it is available to their account. If sudo is not available, then root access is achieved by logging into a regular non-privileged userid, and then su to provide an audit trail.
REDHAT: Include only physical devices in the file /etc/securetty and have the pam_securetty PAM module enabled for every applicable authentication service. The /etc/securetty file contains a list of all the TTY interfaces that allow root logins to the system. This file by default only contains the console TTY’s and must not contain any others. An audit trail must be kept of successful and failed su attempts. This can be enforced with the pam_wheel module with the following entry in /etc/pam.d/su:
auth required /lib/security/pam_wheel.so debug group=admingroup
Make sure that all system administration accounts are in the system group “admingroup” they will not be able to /bin/su to root. To add a user to these groups, run the following command.
#usermod -G admingroup userid (userid=the userid)
SOLARIS: In Solaris the root umask must be set to 027 by adding umask=027 to /.profile, or
/.login
Root console restrictions must be set by adding CONSOLE=/dev/console to
/etc/default/login.
1.1.4System Userids:
UID numbers from 1 to 99, and 60000 + for Solaris have been historically associated with system login names, therefore, they must not be used for regular users. For practical purposes UIDs 1 to 99 must be reserved for system or application userids. These userids must not allow login access, this can be accomplished by having an asterisk character( * ) in the password field of /etc/shadow (REDHAT or SOLARIS)
REDHAT: The installation process of Red Hat creates a number of unnecessary system user accounts. The following accounts must be locked or removed from all Linux systems and assigned a shell that does not allow login access.
nfsnobody
games
rpc
postgres
nscd
news
gopher
named
rpcuser
SOLARIS: The installation process of Solaris creates a number of unnecessary system user
accounts. The following accounts must be locked or removed from all Solaris systems and
assigned a shell that does not allow login access.
lp
uucp
nuucp
listen
smtp
The default system accounts below must use the following UID’s in the /etc/passwd file.
root:0
bin:2
adm:4
noaccess:60002
daemon:1
sys:3
nobody:60001
nobody4:65534
The default system accounts are listed below and are by default locked from login via the NP -
No
Password or *LK* - Locked in the /etc/shadow file as shown below. This must not be changed.
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
The root id and all system ids must have ftp access disabled by having an entry in the file /etc/ftpusers or /etc/vsftpd.ftpusers. The exception for this rule would be the user "ftp" for systems that have anonymous ftp enabled. If the file /etc/ftpusers or /etc/vsftpd.ftpusers does not exist, then it must be created. Additionally, any user accounts that do not need ftp access should also be added to this file.
1.1.5System Groupids:
GIDs from 0 to 99 must be reserved for system or application group names. Only system,application, or regular userids with a valid business justification may be members of these groups.
The admingroup system group must be added for privileged access.
1.2User Accounts:
User accounts are defined as accounts set up for and owned by a human being.
User accounts are to be owned by one human being and not shared.
User accounts are set up in the /etc/passwd file.
/etc/default/login must have the entry, PASSREQ=YES (SOLARIS)
A password must be assigned to each user account in /etc/passwd. This encrypted
password must be stored in the /etc/shadow file (REDHAT and SOLARIS) or the
/etc/security/passwd file (AIX).
Username:x:uid:gid:gcos field:home directory:shell
Each UID must be used only once to ensure that all accounts have a unique UID
number assigned.
A home directory must be assigned to each user account in /etc/passwd. This account must be owned by the user to which it is assigned and the group owner must be one of which the user account is a member. Additionally, the users home directory must be located in a general user area such as /home and not at /,/tmp, or other system directory.
Username:x:uid:gid:gcos field:home directory:shell
All login shells that are approved by the system administration team for use by users must be added to /etc/shells unless they are used to disallow login access.
Only shells listed in /etc/shells will be added to the shell field of the /etc/passwd file unless the shell is used to disallow login access.
All accounts in /etc/passwd must utilize a shell listed in /etc/shells unless the shell is used to disallow login access. .
All accounts that are necessary to be present on the system for business use but do not require human access should have /bin/false, /sbin/nologin, /dev/null, or other shell which disallows login access as the shell. These shells should NOT be added to /etc/shells.
Shells listed in /etc/shells must not have setuid or setgid privileges.
All shells must be owned by the users root or bin and must not be world writable.
Username:x:uid:gid:gcos field:home directory:shell
1.2.1Application Accounts vs. Application User Accounts
1.2.1.1Application Accounts
Application accounts are defined as unix accounts used by an application to run on a system.
Application Accounts, where possible, must utilize a nonfunctioning shell such as /bin/false to prevent shell access to the account.
Application accounts must identify the application for which it is running in the gecos field.
Username:x:uid:gid:gecos field:home directory:shell
A home directory must be assigned to each application account in /etc/passwd. Additionally, the home directory must be located in either the application’s working directory or a general user area such as /home and not at /,/tmp, or other system directory.
All default application accounts set up in /etc/passwd including guest and
anonymous must be disabled if not required. If these default accounts are required the password must be changed to follow the STANDARD Password Ageing rules or disabled
•Application accounts must follow the login shell requirements
1.2.1.2Application User accounts
Application user accounts are defined as unix accounts used by users to run, access, or administer an application.
Application user accounts should not be logged into directly. The use of su or sudo is the preferred method of gaining access to application user accounts.
Application user accounts must identify the application for which it is used to administer in the gecos field
Username:x:uid:gid:gecos field:home directory:shell
A home directory must be assigned to each application user account in /etc/passwd.
Additionally, the home directory must be located in either the application’s working
directory or a general user area such as /home and not at /,/tmp, or other system
directory.
Username:x:uid:gid:gcos field:home directory:shell
All default application user accounts set up in /etc/passwd including guest
and anonymous must be disabled if not required. If these default accounts are required the password must be changed to follow the STANDARD Password Ageing Rules or disabled
1.2.2Temporary Accounts:
Temporary accounts may be necessary on occasion for maintenance or support purposes. These accounts must only be used as necessary as determined by management.
Temporary account access must be restricted only to resources required for the purposes of the work being done. This access must be closely monitored and revoked as soon as the account is no longer needed.
Temporary accounts must be set to expire at a predetermined date by management which can be no longer than 7 days from the creation of the account. If access is needed longer than one week, then the user must again invoke the temporary account creation process
Unix FAQ
Syslog Configuration
Sun Managers Thread
Solaris Trips& Tricks
Unix Library
Unix for learners
Send E-Mail to: unixsa06@gmail.com
Copyright © 2006 Vidya Shyamala A. All Rights Reserved