CA Autosys Command Line
1. autoflags
2. autoping
3. autorep
4. autosyslog
5. chase
6. chk_auto_up
7. clean_file
8. jil
9. cron2jil
10. job_depends
11. monbro
12. sendevent
13. autosys_secure
14. autobcp
Change DBMAINT time
Check if DBMAINT processed
1. autoflags
Usage: autoflags -aiodvxrhn
a -- ALL information
i -- tape id #
o -- operating system
d -- database
v -- AutoSys version #
x -- AutoSys full version #
r -- AutoSys release #
h -- hostid
n – hostname
Command description
To show autosys information such as version, hostname, database
Example
$ autoflags –a
G1 SOLAR SYB 4.5 0 83f842c5 kcscws90
2. autoping
Usage: autoping <-m machineALL> [-A] [-D]
where: machine is the machine to ping, or 'ALL' for ALL machines
-D = check the Database connections on that machine
-A = Send an ALARM if there are problems.
Command description
To verify that server and client machine are properly configured and are communicating successfully
Example
$ autoping –m kcsinp41 –D
AutoPinging Machine [kcsinp41] AND checking the Remote Agent's DB Access.
AutoPing WAS SUCCESSFUL!
3. autorep
Usage: [-J JobName] <-d -s -q -o [OverRide #] -w>
[-r run_num] [-L Print Level] [-x]
[-G GlobalName] [-M MachineName] [-D DataServer:DataBase]
Command description
- To list a variety of information about jobs
Example
- show job information
$ autorep –J backup-ca-autosys1-daily
Job Name Last Start Last End ST Run Pri/Xit
____________________________ ____________________ ____________________ __ _______ ___
backup-ca-autosys1-daily 07/10/2008 23:00:09 07/10/2008 23:03:51 SU 1735024/1
- show job detail
$ autorep –J backup-ca-autosys1-daily –q
/* ----------------- backup-ca-autosys1-daily ----------------- */
insert_job: backup-ca-autosys1-daily job_type: c
box_name: BACKUP-CA-DAILY
command: /opt/CA/cabackup/scripts/45expconf2.sh
machine: kcsinp41
owner: autosys@kcsinp41
permission: gx,wx
description: "This job for export configure at AUTOSYS DEVELOPE (kcsinp41)"
std_out_file: /cbs/autosys/log/$AUTO_JOB_NAME.out
std_err_file: /cbs/autosys/log/$AUTO_JOB_NAME.err
alarm_if_fail: 1
profile: /etc/profile
- show job information run 1 day ago ( maximum to 7 days ago)
$ autorep –J backup-ca-autosys1-daily –r -1
- show all jobs
$ autorep –J ALL
4. autosyslog
Usage: autolog [-e -j Job_Name ] [-p]
-e [ monitor (tail -f) the event processor output file. ]
-j job_name [ Inspect the latest remote agent output file for job_name ]
-p Include the output from the environment if available (RemoteProFile)
หรือ [autosys@kcsinp41]$cd $AUTOUSER
[autosys@kcsinp41]$pwd
/opt/CA/UAJM/autouser/out
Tail –f event_demon.D45
Command description
- Being used to view either the event processor log file or the remote agent log file for the specified job
Example
$ autosyslog -e
Monitoring primary event processor output file:
/opt/CA/UAJM/autouser/out/event_demon.D45
*** To break out type control-c (^c) ***
[10:16:12.0932] [1] [ktbux283 connected for by-pass-report]
[10:16:12.1428] [1] EVENT: CHANGE_STATUS STATUS: STARTING JOB: by-pass-report
[10:16:15.2616] [1] EVENT: CHANGE_STATUS STATUS: RUNNING JOB: by-pass-report
[10:16:26.5451] [1] EVENT: CHANGE_STATUS STATUS: SUCCESS JOB: by-pass-report
[10:16:26.7411] [1] [ktbux283 connected for restore_report_283]
[10:16:27.8023] [1] EVENT: CHANGE_STATUS STATUS: STARTING JOB: restore_report_283
[10:16:29.8942] [1] EVENT: CHANGE_STATUS STATUS: RUNNING JOB: restore_report_283
[10:16:30.9691] [1] EVENT: CHANGE_STATUS STATUS: SUCCESS JOB: restore_report_283
[10:16:31.1797] [1] [ktbux283 connected for by-pass-report]
[10:16:32.2364] [1] EVENT: CHANGE_STATUS STATUS: STARTING JOB: by-pass-report
[10:16:34.3130] [1] EVENT: CHANGE_STATUS STATUS: RUNNING JOB: by-pass-report
5. chase
Usage: [ -A ] [ -E ]
Option
-A Indicates that if chase detects any consistencies ( such as, jobs that should be running, but are not) it sends alarms to RDBMSs
-E Indicates that if ad job and the job’s Remote Agent are not running on the client machine, but the database indicates they should be, chase puts the job in FAILURE status triggering the job to be restarted If the job definition includes the n_retrys attribute
Command description
- To check what job is running at this time
Example
$ chase
Running the Chase Process.
______________________________________________________________________________
______________________________________________________________________________
Checking on Jobs in the STARTING state...
There are NO Jobs that have been in the STARTING state
more than 120 Seconds.
______________________________________________________________________________
Checking on Jobs in the RUNNING state...
______________________________________________________________________________
[ktbux204a connected for ]
______________________________________________________________________________
Examining Job: tmp_ftp_pmt_tlrpmt_cbsgo On Machine: ktbux204a
OK! Both the auto_remote daemon and the job are still running.
______________________________________________________________________________
[ktbux204b connected for ]
______________________________________________________________________________
Examining Job: gl-fms-balance-extract On Machine: ktbux204b
OK! Both the auto_remote daemon and the job are still running.
______________________________________________________________________________
[ktbux283 connected for ]
______________________________________________________________________________
Examining Job: by-pass-report On Machine: ktbux283
OK! Both the auto_remote daemon and the job are still running.
______________________________________________________________________________
Chase is done!
6. chk_auto_up
Command description
- To check status of event processor and event server
Example
$ chk_auto_up
______________________________________________________________________________
Attempting (1) to Connect with Database: AUTOSYSDBD:autosys
*** Have Connected successfully with Database: AUTOSYSDBD:autosys. ***
______________________________________________________________________________
Connected with Event Server: AUTOSYSDBD:autosys
______________________________________________________________________________
______________________________________________________________________________
Checking Machine: kcsinp41
Primary Event Processor is RUNNING on machine: kcsinp41
7. clean_file
Usage: clean_file –d days
-d days
Specify that log files older than the number of days will be removed
Command description
- deletes old Remote Agent log files
Example
- removed log files older than 7 days
$ clean_files –d 7
8. jil
Usage: jil [-q] [-S autoserv_instance] [-V none job batch ]
Command description
- jil is scripting language used to create job definitions
Example
- To used jil command to create job detailed in job_detail.txt
$ more job_detail.txt
/* ----------------- backup-ca-autosys1-daily ----------------- */
insert_job: backup-ca-autosys1-daily job_type: c
box_name: BACKUP-CA-DAILY
command: /opt/CA/cabackup/scripts/45expconf2.sh
machine: kcsinp41
owner: autosys@kcsinp41
permission: gx,wx
description: "This job for export configure at AUTOSYS DEVELOPE (kcsinp41)"
std_out_file: /cbs/autosys/log/$AUTO_JOB_NAME.out
std_err_file: /cbs/autosys/log/$AUTO_JOB_NAME.err
alarm_if_fail: 1
profile: /etc/profile
$ jil < job_detail.txt
$ autorep –J job_detail.txt –q
/* ----------------- backup-ca-autosys1-daily ----------------- */
insert_job: backup-ca-autosys1-daily job_type: c
box_name: BACKUP-CA-DAILY
command: /opt/CA/cabackup/scripts/45expconf2.sh
machine: kcsinp41
owner: autosys@kcsinp41
permission: gx,wx
description: "This job for export configure at AUTOSYS DEVELOPE (kcsinp41)"
std_out_file: /cbs/autosys/log/$AUTO_JOB_NAME.out
std_err_file: /cbs/autosys/log/$AUTO_JOB_NAME.err
alarm_if_fail: 1
profile: /etc/profile
9. cron2jil
usage: cron2jil -f cronFile \
[ -d outputDirectory ] [ -i includeFile ] [ -m machine ] [ -p prefix]
Option
-f crontab_file Specifies the name of crontab formatted file
-d output_directory Specifies the directory to which the *.jil and *.cal should be written. The default is the current working directory
-i include_file Specifies the name of a file containing JIL statements
Command description
- To convert crontab file to a corresponding JIL script (*.jill file)
10. job_depends
Usage: job_depends < -c -d -t > <-J JobName>
[-F From Date/Time (MM/DD/YYYY HH:MM)]
[-T To Date/Time]
[-L Print Level] [-D DataServer:DataBase]
Option
-c Current Condition Status
-d Dependencies Only
-t Time Dependencies
Command description
- show dependencies and conditions of a job
Example
$ job_depends -c -J report-go-convert
Start Dependent
Job Name Status Date Cond? Cond? Jobs?
-------- ------- ---------------- ----- ---------
report-go-convert SUCCESS No Yes Yes
Condition: s(report-go-split)
Atomic Condition Current Status T/F
---------------- -------------- ---
SUCCESS(report-go-split) SUCCESS T
Dependent Job Name Condition
------------------ ---------
report-go-arrangment SUCCESS(re...)
______________________________________________________________________________
11. monbro
Usage: monbro -N name [-P polling frequency] [-D DataServer:DataBase] [-q]
Option
-N name Specifies the name of monitor or report (browser) to be run, you can type ALL for all
-P poll_frequency Applies to monitors only and indicates the time interval (seconds), the default is 10 seconds.
Command Description
- Run monitor or report that has already been defined, using JIL or the monitor/browser editor
Example
$ monbro –N ALL
12. sendevent
Usage: sendevent -E EVENT [-S AUTOSERV] [-A Alarm] [-J JobName]
[-s Status] [-P Event Priority] [-M Max Send Trys ]
[-q Job Que Priority] [-G Global=Value] [-C Comment]
[-U (Un-SENDEVENT)] [-T Time of Event] [-K Signal(s)]
Option
-E event Specifies the event to be sent
STARTJOB à start job
KILLJOB à kill job
DELETEJOB à delete job
FORCE_STARTJOB à force starting job
JOB_ON_ICE à on ice job
JOB_OFF_ICE à off ice job
JOB_ON_HOLD à on hold job
JOB_OFF_HOLD à off hold job
STOP_DEMON à stop event processor
-J job name Specifies job name
Command Description
- To send events for variety of purposes, including starting or stopping jobs
Example
- force starting job named “test_job”
$ sendvent –E FORCE_STARTJOB test_job
- stop event processor
$ sendevent –E STOP_DEMON
13. autosys_secure
AutoSys Security Utility
autosys_secure [-h] [-q] {-a -c -d}
{-u -editu -execu} user@domain_or_host
[-o old password] [-p password] [-host domain_or_host]
-h help
-p new password
-q Run Quietly (No Prints)
-a Add a New User
-c Change an Existing User
-d Delete an Existing User
-u AutoSys user@domain_or_host Required for ALL options
-o old password , Required for -c with -u
-p current password , Required for -d with -u
-p new password , Required for -a and -c with –u
Command description
- Maintain the edit and exec superuser ownership, remote authentication methods and database password
Example
$ autosys_secure
Please select an action to perform:
[1] Administer EDIT/EXEC superusers.
[2] Change AutoSys database password.
[3] Change AutoSys remote authentication method.
[4] Create AutoSys User@Host or Domain password.
[5] Change AutoSys User@Host or Domain password.
[6] Delete AutoSys User@Host or Domain password.
[7] Exit autosys_secure.
[A] Get Encrypted Password for Adapters.
14. autobcp
usage: autobcp source_server target_server dump_file autosys_password [source_db_name target_db_name batch_size bcp_format]
Command description
- To synchronize database by firstly deleting target database and then copy database from source database to target database
Example
$ cd /opt/CA/UAJM/autosys/install
$ ./autobcp AUTOSYSDBP AUTOSYSDBS dump autosys
Sybase database command
1. xql
Usage: xql [ -U ][ -P ][ -S ][ -D ][ -c ][ -f ][ -d ][ -i ][ -I ][ -l ][ -w ][ -T ][ -x ]
************************************************************************************
* [-U user ] Sybase User *
* [-P password ] Sybase Password *
* [-S server ] Sybase Server *
* [-D database ] Database name *
* [-c sqltext ] SQL text to process *
* [-f filename ] file with SQL in it *
* [-d delimiter] output file field delimiter ( default: "" ) *
* [-i ] ISQL compatible output *
* [-I ] ISQL compatible output, with no header *
* [-l ] Long format - columns and values, one to a line. *
* [-w nnn ] Width of output line for -i option *
* [-T nnn ] Interactive xql timeout time in minutes.(-T0 for no exit) *
* [-x ] Version Information
Command description
- access to database
Example
$ xql -Uautosys -Pautosys -D autosys -S AUTOSYSDBS
xql>>[AUTOSYSDBD][autosys] 1>
Change DBMAINT time
$cd /opt/CA/UAJM/autouser
1. $Backup /opt/CA/UAJM/autouser/config.P45 ทั้งเครื่อง kcsinp01 และ kcsinp02
2. แก้ไขเป็นเวลาที่ต้องการ DBMaintTime=hh:mm
3. Recycle EP
Check if DBMAINT processed
$cd /opt/CA/UAJM/autouser/out
$cat DBMaint.out
2008/11/28
Solaris 10 Account Lockout
Solaris 10 Account Lockout ("Three Strikes!")
by: Glenn M. Brunette, Jr., 10/11/2004
http://www.securitydocs.com/library/2637
The next item of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS is account lockout. Account lockout is the ability of a system or service to administratively lock an account after that account has suffered "n" consecutive failed authentication attempts. Very often "n" is three hence the "three strikes" reference.
Recall from yesterday's entry on non-login and locked accounts that there is in fact a difference. Locked accounts are not able to access any system services whether interactively or through the use of delayed execution mechanisms such as cron(1M). So, when an account is locked out using this capability, only a system administrator is able to re-enable the account, using the passwd(1) command with the "-u" option.
Account lockout can be enabled in one of two ways. The first way will enable account lockout globally for all users. The second method will all more granular control of which users will or will not be subject to account lockout policy. Note that the account lockout capability will only apply to accounts local to the system. We will look at both in a little more detail below.
Before we look at how to enable or disable the account lockout policy, let's first take a look at how you configure the number of consecutive, failed authentication attempts that will serve as your line in the sand. Any number of consecutive, failed attempts beyond the number selected will result in the account being locked. This number is based on the RETRIES parameter in the /etc/default/login file. By default, this parameter is set to 5. You can certainly customize this parameter based on your local needs andpolicy. By default, the Solaris Security Toolkit will set the RETRIES parameter to 3.
Now that we know how to define how many consecutive, unsuccessful authentication attempts we will allow, let's take a look at how you can enable the account lockout policy globally. This policy can be altered using the LOCK_AFTER_RETRIES variable in the /etc/security/policy.conf file. Just as it sounds, if you set this parameter to YES, then the account lockout policy is enabled for all users on the system (unless there is a user override which we will talk about in a minute). By default, this parameter is set to NO which means that account lockout is not enabled. So, let's try a simple example. First, I created a test account called gmb. Next, I set the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf to YES. To see, how this feature works, I attempted to authenticate to a system (and failed) using three different services:(1) TELNET, (2) FTP and (3) RLOGIN. I failed the login attempt for each of these services (in turn) twice with the exception of RLOGIN since after the fifth failed attempt the account was locked. I ran this test from the system's console so that the log
messages could be injected into the output stream to give you a better idea of what was happening. Hereis the actual log of the test that was run:
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login:
Connection to localhost closed by foreign host.
# ftp localhost
Connected to localhost.
220 sampleHost FTP server ready.
Name (localhost:root): gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> user gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> quit 221 Goodbye.
# rlogin -l gmb localhost Password:
Sep 23 23:23:47 sampleHost login: Excessive (5)
login failures for gmb: locking account. Login
incorrect
login:
As you can see, after the fifth attempt, the gmb account was locked. This can also be verified by looking at the shadow(4) file entry for that account:
# grep "^gmb:" /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5
You can see that the account has been locked and that a record of the number of failures is available in the last column. From the shadow(4) manual page, the last field (called "flag") stores the failed login count in the low order four bits while reserving the remainder for future use. This means that you can also look at individual shadow(4) entries and see how many consecutive failed authentication attempts have been made per user. For example, you could do the following to see how many users have had failed authentication attempts since their last successful login:
# awk -F: '$NF >= 1 { print; }' /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5
foo:02YZb5ZaMrcrk:12685::::::2
bar:XF0Ggjq1c6tYQ:12685::::::1
baz:.VxOG4ytNE8es:12685::::::3
If a user who has had failed authentication attempts is finally able to successfully login to the system, that user will be presented with a message like:
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: baz
Password:
Warning: 3 failed login attempts since last
successful login.
Last login: Thu Sep 23 23:36:44 from localhost
This warning message is available for interactive login services (not FTP) and is very helpful in
providing warning to users who may not have been responsible for the failed authentication attempts. It is important that you educate your users to not simply ignore these messages as they could be a symptom of an ongoing attack on their account. Also, note that once a user has successfully authenticated to a system, the failed login count is reset:
# grep "^baz" /etc/shadow
baz:.VxOG4ytNE8es:12685::::::
Note that the use of alternate authentication mechanisms such as rhosts or Secure Shell public key authentication will not reset the failed login count even on successful login. Should an account be locked however (either administratively or through the account lockout facility), the account would no longer be accessible even when using these alternate authentication methods. For example:
# grep gmb /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::
# rsh -l gmb localhost /bin/finger
account expired
or for Secure Shell...
# ssh -l gmb -i /export/home/gmb/.ssh/id_dsa
localhost
Enter passphrase for key
'/export/home/gmb/.ssh/id_dsa':
Sep 24 00:34:59 sampleHost sshd[1504]: Failed
publickey for gmb from 127.0.0.1 port 32801 ssh2
Password:
The second way in which account lockout can be configured is per-user in the /etc/user_attr file. Each user listed in the /etc/user_attr file can have an attribute defined called lock_after_retries. For a description of the format of this file, see the user_attr(4) manual page. By default, this value is set to no. To configure account lockout for a specific user, simply add the lock_after_retries attribute with a value of yes. For example, let's assume you have an entry for user gmb:
gmb::::type=normal;profiles=FOO Security
Management;roles=secadm
To enable account lockout, you simple change the above line to:
gmb::::type=normal;profiles=FOO Security
Management;roles=secadm;lock_after_retries=yes
Let's take another view on this. Let's assume that the account lockout policy has been enabled globally using the method described above. You can then configure some users to be immune to this policy using this user-specific override. For example, if the LOCK_AFTER_RETRIES parameter was set to YES in /etc/security/policy.conf, but you did not want the policy to apply to the gmb account, then you only need to make sure that the /etc/user_attr file contains an entry for the gmb account that sets the lock_after_retries attribute to no as in:
gmb::::lock_after_retries=no
Here is an example of how this works. I will attempt to access the gmb account with an invalid password five times using TELNET. In contrast to the above example, the account should not be locked and no account locked message should be generated. First, let's confirm we have our system configured correctly for this test:
# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::::::
# grep "^gmb:" /etc/user_attr
gmb::::lock_after_retries=no
# grep "^LOCK_AFTER_RETRIES="
/etc/security/policy.conf
LOCK_AFTER_RETRIES=YES
Now, let's see if the account actually gets locked after 5 failed authentication attempts.
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
Sep 23 23:51:46 sampleHost login: REPEATED LOGIN
FAILURES ON /dev/pts/1 FROM localhost, gmb
Connection to localhost closed by foreign host.
# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::
Just as expected, the gmb account is immune from the account lockout policy that applies to other users on the system. This is in fact what is implemented by default for the root account. That is, even if account lockout is enabled globally (which is not the default), the root account is still immune from being locked out. This is done to prevent a malicious user from locking the root account out of the system. If you would like this policy to apply to the root account, then simply change the value of the lock_after_retries parameter to yes in the /etc/user_attr file.
This concludes another installment. As always, I hope you find this information useful in understanding how some of the new Solaris 10 security enhancements work and how they can be applied to solve realworld problems in your environment.
by: Glenn M. Brunette, Jr., 10/11/2004
http://www.securitydocs.com/library/2637
The next item of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS is account lockout. Account lockout is the ability of a system or service to administratively lock an account after that account has suffered "n" consecutive failed authentication attempts. Very often "n" is three hence the "three strikes" reference.
Recall from yesterday's entry on non-login and locked accounts that there is in fact a difference. Locked accounts are not able to access any system services whether interactively or through the use of delayed execution mechanisms such as cron(1M). So, when an account is locked out using this capability, only a system administrator is able to re-enable the account, using the passwd(1) command with the "-u" option.
Account lockout can be enabled in one of two ways. The first way will enable account lockout globally for all users. The second method will all more granular control of which users will or will not be subject to account lockout policy. Note that the account lockout capability will only apply to accounts local to the system. We will look at both in a little more detail below.
Before we look at how to enable or disable the account lockout policy, let's first take a look at how you configure the number of consecutive, failed authentication attempts that will serve as your line in the sand. Any number of consecutive, failed attempts beyond the number selected will result in the account being locked. This number is based on the RETRIES parameter in the /etc/default/login file. By default, this parameter is set to 5. You can certainly customize this parameter based on your local needs andpolicy. By default, the Solaris Security Toolkit will set the RETRIES parameter to 3.
Now that we know how to define how many consecutive, unsuccessful authentication attempts we will allow, let's take a look at how you can enable the account lockout policy globally. This policy can be altered using the LOCK_AFTER_RETRIES variable in the /etc/security/policy.conf file. Just as it sounds, if you set this parameter to YES, then the account lockout policy is enabled for all users on the system (unless there is a user override which we will talk about in a minute). By default, this parameter is set to NO which means that account lockout is not enabled. So, let's try a simple example. First, I created a test account called gmb. Next, I set the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf to YES. To see, how this feature works, I attempted to authenticate to a system (and failed) using three different services:(1) TELNET, (2) FTP and (3) RLOGIN. I failed the login attempt for each of these services (in turn) twice with the exception of RLOGIN since after the fifth failed attempt the account was locked. I ran this test from the system's console so that the log
messages could be injected into the output stream to give you a better idea of what was happening. Hereis the actual log of the test that was run:
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login:
Connection to localhost closed by foreign host.
# ftp localhost
Connected to localhost.
220 sampleHost FTP server ready.
Name (localhost:root): gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> user gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> quit 221 Goodbye.
# rlogin -l gmb localhost Password:
Sep 23 23:23:47 sampleHost login: Excessive (5)
login failures for gmb: locking account. Login
incorrect
login:
As you can see, after the fifth attempt, the gmb account was locked. This can also be verified by looking at the shadow(4) file entry for that account:
# grep "^gmb:" /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5
You can see that the account has been locked and that a record of the number of failures is available in the last column. From the shadow(4) manual page, the last field (called "flag") stores the failed login count in the low order four bits while reserving the remainder for future use. This means that you can also look at individual shadow(4) entries and see how many consecutive failed authentication attempts have been made per user. For example, you could do the following to see how many users have had failed authentication attempts since their last successful login:
# awk -F: '$NF >= 1 { print; }' /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5
foo:02YZb5ZaMrcrk:12685::::::2
bar:XF0Ggjq1c6tYQ:12685::::::1
baz:.VxOG4ytNE8es:12685::::::3
If a user who has had failed authentication attempts is finally able to successfully login to the system, that user will be presented with a message like:
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: baz
Password:
Warning: 3 failed login attempts since last
successful login.
Last login: Thu Sep 23 23:36:44 from localhost
This warning message is available for interactive login services (not FTP) and is very helpful in
providing warning to users who may not have been responsible for the failed authentication attempts. It is important that you educate your users to not simply ignore these messages as they could be a symptom of an ongoing attack on their account. Also, note that once a user has successfully authenticated to a system, the failed login count is reset:
# grep "^baz" /etc/shadow
baz:.VxOG4ytNE8es:12685::::::
Note that the use of alternate authentication mechanisms such as rhosts or Secure Shell public key authentication will not reset the failed login count even on successful login. Should an account be locked however (either administratively or through the account lockout facility), the account would no longer be accessible even when using these alternate authentication methods. For example:
# grep gmb /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::
# rsh -l gmb localhost /bin/finger
account expired
or for Secure Shell...
# ssh -l gmb -i /export/home/gmb/.ssh/id_dsa
localhost
Enter passphrase for key
'/export/home/gmb/.ssh/id_dsa':
Sep 24 00:34:59 sampleHost sshd[1504]: Failed
publickey for gmb from 127.0.0.1 port 32801 ssh2
Password:
The second way in which account lockout can be configured is per-user in the /etc/user_attr file. Each user listed in the /etc/user_attr file can have an attribute defined called lock_after_retries. For a description of the format of this file, see the user_attr(4) manual page. By default, this value is set to no. To configure account lockout for a specific user, simply add the lock_after_retries attribute with a value of yes. For example, let's assume you have an entry for user gmb:
gmb::::type=normal;profiles=FOO Security
Management;roles=secadm
To enable account lockout, you simple change the above line to:
gmb::::type=normal;profiles=FOO Security
Management;roles=secadm;lock_after_retries=yes
Let's take another view on this. Let's assume that the account lockout policy has been enabled globally using the method described above. You can then configure some users to be immune to this policy using this user-specific override. For example, if the LOCK_AFTER_RETRIES parameter was set to YES in /etc/security/policy.conf, but you did not want the policy to apply to the gmb account, then you only need to make sure that the /etc/user_attr file contains an entry for the gmb account that sets the lock_after_retries attribute to no as in:
gmb::::lock_after_retries=no
Here is an example of how this works. I will attempt to access the gmb account with an invalid password five times using TELNET. In contrast to the above example, the account should not be locked and no account locked message should be generated. First, let's confirm we have our system configured correctly for this test:
# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::::::
# grep "^gmb:" /etc/user_attr
gmb::::lock_after_retries=no
# grep "^LOCK_AFTER_RETRIES="
/etc/security/policy.conf
LOCK_AFTER_RETRIES=YES
Now, let's see if the account actually gets locked after 5 failed authentication attempts.
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
Sep 23 23:51:46 sampleHost login: REPEATED LOGIN
FAILURES ON /dev/pts/1 FROM localhost, gmb
Connection to localhost closed by foreign host.
# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::
Just as expected, the gmb account is immune from the account lockout policy that applies to other users on the system. This is in fact what is implemented by default for the root account. That is, even if account lockout is enabled globally (which is not the default), the root account is still immune from being locked out. This is done to prevent a malicious user from locking the root account out of the system. If you would like this policy to apply to the root account, then simply change the value of the lock_after_retries parameter to yes in the /etc/user_attr file.
This concludes another installment. As always, I hope you find this information useful in understanding how some of the new Solaris 10 security enhancements work and how they can be applied to solve realworld problems in your environment.
Net Backup
Starting and Stopping Netbackup
Stopping Netbackup
/usr/openv/netbackup/bin/K77netbackup --> graceful shutdown
/usr/openv/netbackup/bin/bpps -a --> check for any remaining processes
/usr/openv/netbackup/bin/goodies/bp.kill_all ---> kills all remaining netbackup processes, not necessarily graceful
/usr/openv/netbackup/bin/bpps -a --> check for any remaining processes
kill -9for any remaining. NOTE: unkillable processes may require a reboot
Starting Netbackup
/usr/openv/netbackup/bin/S77netbackup --> after bp.kill_all, to restart
Common Tasks
Starting the Administration GUI
java from the windows client
x-windows from the server - /usr/openv/netbackup/bin/xnb &
Checking Backup Status
Activity Monitor or
/usr/openv/netbackup/bin/admincmd/bpdbjobs -report
Cleaning a tape manually
Identify the drive name to be cleaned
tpclean -L
Manually clean the drive:
tpclean -C
Determining what tapes were used for a backup
GUI
Backup and Restore --> Find the file system --> Preview Media Button
CLI
Find the correct backup images
bpimagelist -U -client-d -e
Find the media used for those images
bpimagelist -U -client-d -e -media
Listing the files in a backup
Find the tape(s) used (above procedure using bpimagelist)
cd /usr/openv/netbackup/db/jobs/done
Run the following script and redirect it's output to a text file:
for file in `grep MOUNTING *grepawk '{print $1}'sed 's/:MOUNTING//'`
do
echo $file
grep PATH_WRITTEN $fileawk '{print $3}'
echo " "
echo "==========================================End of
Image======================================"
echo " "
done
This process works for NBU V3.4:
cd /usr/openv/netbackup/db/images/
ls -ltr --> this will identify the directory with the proper date
verify directory with "bpdbm -ctime
cd
ls -ltr --> lists all of the backups for this client on this date
cat__.f awk '{print $10}' --> this prints out the files in the backup
For NBU > V3.4
bpflist --help --> undocumented netbackup command to list files from a binary .f file
Inventory the Robot
Inventory Robot --> /opt/openv/volmgr/bin/vmcheckxxx -rt robot_type -rn robot_number -list
(where robot_type is tld, acs, . . .)
Inventory Robot and Update Configuration --> /opt/openv/volmgr/bin/vmupdate -rt robot_type -rn robot_number -list (where robot_type is tld, acs, . . .)
Listing Properties of the Volume Pools
vmpool -listall
Scratch Tapes
Count scratch tapes: /usr/openv/volmgr/bin/vmquery -pn Scratch grep -c "robot slot"
Moving tapes to the scratch pool
If Needed - Expire the tape
bpexpdate -ev-d 0 -force -host
Move the tape
vmchange -p 2 -m
Checking Drive Usage
/usr/openv/volmgr/bin/vmoprcmd
Taking a drive down or up
/usr/openv/volmgr/vmoprcmd -down
/usr/openv/volmgr/vmoprcmd -up
Performing a Restore
From the GUI
user backup & restore --> configuration --> client
user backup & restore --> configuration --> client to restore
directory to search
directory depth
date range
file --> browse backups for restore
Adding New Tapes to the Library
Using the GUI
Media Management --> Actions --> New --> Single Volume . . -->
Media Type (ie DLT)
Robot Type (ie TLD)
Media ID (from Inventory)
Slot Number (from Inventory)
Robot Number (ie 0)
Volume Group
Volume Pool (ie Scratch)
Using the CLI
vmadd -m-mt -verbose -rt -b -rn -rc1 -p -mm
vmpool -listall --> lists all pools, both name and number
For example: vmadd -m 000151 -mt dlt -verbose -rt tld -b 000151 -rn 0 -rc1 8 -p 2 -mm
0
Re-using Tapes from other systems or older Netbackups
Expire the media
bpexpdate -ev MEDIA_ID -d 0 -force -host HOST
Deassign the media
vmquery -deassignbyid MEDIA_ID 4 0
Move to the scratch pool
vmchange -m MEDIA_ID -p POOL#
Relabel the media
bplabel -ev CIM572 -d dlt -p Scratch
Changing the attributes of media
Changing the barcode
vmchange -barcode CYM100D -m CYM100
Changing the Volume Pool
vmchange -m MEDIA_ID -p POOL#
To expire media
bpexpdate -ev-d 0 -force -host
To unfreeze media
List the frozen media
/usr/openv/netbackup/bin/goodies/available_media grep -i FROZEN
Unfreeze the media
bpmedia -unfreeze -ev-h
To relabel a tape
bplabel -ev-d -p
bplabel -ev 000687 -d dlt -p TriVrgt_OFFSITE
To remove media from the Netbackup database
Verify that there are no images on the tape
bpimmedia -mediaid 000687 -L
Expire the tape
bpexpdate -ev 000687 -d 0 -host scorpius -force
Get the status and pool number of the tape
vmquery -m 000687
Deassign the tape
vmquery -deassignbyid
vmquery -deassignbyid 000687 4 0x0
Delete the tape
vmdelete -m 000687
Installing the Netbackup Client
/update_clients -ForceInstall -ClientList /tmp/clients.lst
requires that TMPDIR and TEMPDIR be set correctly
Excludng files from backup on a client
Create /usr/openv/netbackup/exclude_list
Put the file specifications of the files/directories to be excluded
/mnt/directory/*
Displaying Information about a Tape
vmquery -m--> Displays attributes about a particular tape
bpmedialist -U -mcontents -ev 000687 --> Displays media contents
bpmedialist -U -mlist --> List of all media
bpmedialist -U -mlist -ev CYM966 --> Listing of a particular media id
bpimmedia -mediaid 000687 -L --> Listing of images on a tape
Robtest Commands
Starting robtest
robtest
1 --> to select TLD 0
Getting help
?
Looking at contents of the tape drives
s d
Looking at the contents of the library
s s
Moving a tape from a drive to a library slot
s d --> to identify drive number that has tape (Contains Cartridge = yes,
Barcode=XXXXXX)
s s --> to identify an empty slot in the tape library (Netbackup will need to be reinventoried)
m d# s# --> from from drive # to slot #
s d --> verify the tape drive is empty
s s --> verify the library slot has the tape
Configuration Files
/usr/openv/netbackup/bp.conf
configuration file, sets backup server and backup clients
force statement must be correct
client to browse from
client to restore to
/usr/openv/volmgr/vmconf
Logfiles
To utilize logfiles, create the corresponding directory in /usr/openv/netbackup/logs
Server Logfile directories:
admin - adminstrative commands
bpbrm - backup and restore manager
bpcd - client daemon
bpdbjobs - database manager program process
bpdm - disk manager process
bpjava-msvc - Java application server authentication service
bpjava-usvc - process that services Java requests
bprd - request daemon process
bpsched - scheduler process that runs on master servers
bptm - tape/optical media management process
user-ops - required directory for use by Java programs
xbpadm - X based administration utility
xbpmon - X based job monitor process
Client Logfile directories:
bp - client user interface process
bparchive - archive program
bpbackup - backup program
bpbkar - program that generates golden images
bpcd - client daemon
bpjava-msvc - Java application server authentication service
bpjava-usvc - process that services Java requests
bplist - program that lists backed up and archived files
bpmount - program that determines local mountpoints and wildcard expansion for multiple
streams
bphdb - Oracle database backup program start process
db_log - database specific extension log
tar - tar process log during restores
user_ops
Media Manager logging automatically goes to the system log using syslogd logging facility
.Logging will only occur if these directories are created. These directories will generate a lot of data and should be deleted when no longer necessary.
To increase the amount of logging information set VERBOSE=2 in /usr/open/netbackup/bp.conf
(default is VERBOSE=1)
Processes
ltid
acsd
vmd
Useful Commands
bpcllist - list classes
bpclinfo-L --> displays info about a class
vmpool - volume pools
vmpool -listall
vmpool -listscratch
bplabel -ev-d hcart
bpbackup db --> backs up the catalog
bpclclients--> lists the clients for a particular policy (class)
Troubleshooting
bperror -statuscode <-- displays information about the netbackup error. No Backups are running:
Check system log file for error messages
Stop and restart all the netbackup processes
Look for a downed drive
/usr/openv/volmgr/bin/vmoprcmd
/usr/openv/volmgr/bin/vmoprcmd -up 0 --> this will bring up drive 0 if it's control shows
as down
Look for pending requests
/usr/openv/volmgr/bin/vmoprcmd or gui --> device management
If there is a pending request either re-assign it to a drive, or deny the request
Downed drive does not come back up or does not stay up
Check for a hardware problem by looking for messages on the tape library
Make sure there is not a tape stuck in the drive
Use robtest (described above) to look at the drives
If there is a tape stuck in the drive, try to remove it using robtest
If robtest fails, then you must manually remove it.
Verify the Client is communicating properly:
bpclncmd -ip--> from both client and server
bpclntcmd -hn--> from both client and server
bpclntcmd -pn --> from client only
Device Actions
Device Management --> info about tape drives
dlt
hcart (ultrium)
Media Actions
Media id must agree with # of the tape
Create a media id
actions -->new-->single volume-->dlt cart (not dlt2)
put it into the "netbackup" volume pool
Netbackup Client
To check things out do this:
It could be a couple things. Mostly DNS, bp.conf, or something stupid. On the client run this command
/usr/openv/netbackup/bin/bpclntcmd -pn
/usr/openv/netbackup/bin/bpclntcmd -server "server name"
/usr/openv/netbackup/bin/bpclntcmd ip "ip_address"
One of these usually fails and your able to fix it right off
1074 ./bpclntcmd -hn corpbu1
1075 ./bpclntcmd -ip 10.194.1.129
1076 ping 10.194.1.129
1077 ./bpclntcmd -hn corpldv1
1078 ./bpclntcmd -hn corpbu1.corporate.vox.net
1079 ping corpldv1
1080 ./bpclntcmd -ip 10.194.1.120
Must be able to resolve correctly from the master server and the client or it will not work!!!
Veritas NetBackup Performance Tuning Tips
Is your Veritas (Symantec, now) NetBackup Server agonizingly slow in taking backups? I found this undocumented feature on Veritas’ website, and quadrupled my backup speeds. Without going into too much details, I’ll give a brief on what was happening. From a local hard drive on a Linux box, backup onto a tape library was running at 16 MB/sec.
That’s slower than a snail with arthritis. Turns out, NetBackup uses certain default values for shared memory buffer sizes (details on Veritas’ website). The values happen to be 8 x 32KB of shared mem buffers.
To increase the size of the buffers and the number of buffers, you have to create the following two files:
/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS
/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
Simply fill in the values that you need for each. A good number for SIZE_DATA_BUFFERS would be 131072 (128KB), or, if your tape drive supports it, 262144. You can also choose to have 16 such buffers by typing in this number in the NUMBER_DATA_BUFFERS file. Note that you may have to increase the shared mem limits on your system before doing this.
This is applicable to a whole lot of previous versions of NetBackup starting from 3.4, and it works with the latest 6.0 version as well.
Stopping Netbackup
/usr/openv/netbackup/bin/K77netbackup --> graceful shutdown
/usr/openv/netbackup/bin/bpps -a --> check for any remaining processes
/usr/openv/netbackup/bin/goodies/bp.kill_all ---> kills all remaining netbackup processes, not necessarily graceful
/usr/openv/netbackup/bin/bpps -a --> check for any remaining processes
kill -9
Starting Netbackup
/usr/openv/netbackup/bin/S77netbackup --> after bp.kill_all, to restart
Common Tasks
Starting the Administration GUI
java from the windows client
x-windows from the server - /usr/openv/netbackup/bin/xnb &
Checking Backup Status
Activity Monitor or
/usr/openv/netbackup/bin/admincmd/bpdbjobs -report
Cleaning a tape manually
Identify the drive name to be cleaned
tpclean -L
Manually clean the drive:
tpclean -C
Determining what tapes were used for a backup
GUI
Backup and Restore --> Find the file system --> Preview Media Button
CLI
Find the correct backup images
bpimagelist -U -client
Find the media used for those images
bpimagelist -U -client
Listing the files in a backup
Find the tape(s) used (above procedure using bpimagelist)
cd /usr/openv/netbackup/db/jobs/done
Run the following script and redirect it's output to a text file:
for file in `grep MOUNTING *grep
do
echo $file
grep PATH_WRITTEN $fileawk '{print $3}'
echo " "
echo "==========================================End of
Image======================================"
echo " "
done
This process works for NBU V3.4:
cd /usr/openv/netbackup/db/images/
ls -ltr --> this will identify the directory with the proper date
verify directory with "bpdbm -ctime
cd
ls -ltr --> lists all of the backups for this client on this date
cat
For NBU > V3.4
bpflist --help --> undocumented netbackup command to list files from a binary .f file
Inventory the Robot
Inventory Robot --> /opt/openv/volmgr/bin/vmcheckxxx -rt robot_type -rn robot_number -list
(where robot_type is tld, acs, . . .)
Inventory Robot and Update Configuration --> /opt/openv/volmgr/bin/vmupdate -rt robot_type -rn robot_number -list (where robot_type is tld, acs, . . .)
Listing Properties of the Volume Pools
vmpool -listall
Scratch Tapes
Count scratch tapes: /usr/openv/volmgr/bin/vmquery -pn Scratch grep -c "robot slot"
Moving tapes to the scratch pool
If Needed - Expire the tape
bpexpdate -ev
Move the tape
vmchange -p 2 -m
Checking Drive Usage
/usr/openv/volmgr/bin/vmoprcmd
Taking a drive down or up
/usr/openv/volmgr/vmoprcmd -down
/usr/openv/volmgr/vmoprcmd -up
Performing a Restore
From the GUI
user backup & restore --> configuration --> client
user backup & restore --> configuration --> client to restore
directory to search
directory depth
date range
file --> browse backups for restore
Adding New Tapes to the Library
Using the GUI
Media Management --> Actions --> New --> Single Volume . . -->
Media Type (ie DLT)
Robot Type (ie TLD)
Media ID (from Inventory)
Slot Number (from Inventory)
Robot Number (ie 0)
Volume Group
Volume Pool (ie Scratch)
Using the CLI
vmadd -m
vmpool -listall --> lists all pools, both name and number
For example: vmadd -m 000151 -mt dlt -verbose -rt tld -b 000151 -rn 0 -rc1 8 -p 2 -mm
0
Re-using Tapes from other systems or older Netbackups
Expire the media
bpexpdate -ev MEDIA_ID -d 0 -force -host HOST
Deassign the media
vmquery -deassignbyid MEDIA_ID 4 0
Move to the scratch pool
vmchange -m MEDIA_ID -p POOL#
Relabel the media
bplabel -ev CIM572 -d dlt -p Scratch
Changing the attributes of media
Changing the barcode
vmchange -barcode CYM100D -m CYM100
Changing the Volume Pool
vmchange -m MEDIA_ID -p POOL#
To expire media
bpexpdate -ev
To unfreeze media
List the frozen media
/usr/openv/netbackup/bin/goodies/available_media grep -i FROZEN
Unfreeze the media
bpmedia -unfreeze -ev
To relabel a tape
bplabel -ev
bplabel -ev 000687 -d dlt -p TriVrgt_OFFSITE
To remove media from the Netbackup database
Verify that there are no images on the tape
bpimmedia -mediaid 000687 -L
Expire the tape
bpexpdate -ev 000687 -d 0 -host scorpius -force
Get the status and pool number of the tape
vmquery -m 000687
Deassign the tape
vmquery -deassignbyid
vmquery -deassignbyid 000687 4 0x0
Delete the tape
vmdelete -m 000687
Installing the Netbackup Client
/update_clients -ForceInstall -ClientList /tmp/clients.lst
requires that TMPDIR and TEMPDIR be set correctly
Excludng files from backup on a client
Create /usr/openv/netbackup/exclude_list
Put the file specifications of the files/directories to be excluded
/mnt/directory/*
Displaying Information about a Tape
vmquery -m
bpmedialist -U -mcontents -ev 000687 --> Displays media contents
bpmedialist -U -mlist --> List of all media
bpmedialist -U -mlist -ev CYM966 --> Listing of a particular media id
bpimmedia -mediaid 000687 -L --> Listing of images on a tape
Robtest Commands
Starting robtest
robtest
1 --> to select TLD 0
Getting help
?
Looking at contents of the tape drives
s d
Looking at the contents of the library
s s
Moving a tape from a drive to a library slot
s d --> to identify drive number that has tape (Contains Cartridge = yes,
Barcode=XXXXXX)
s s --> to identify an empty slot in the tape library (Netbackup will need to be reinventoried)
m d# s# --> from from drive # to slot #
s d --> verify the tape drive is empty
s s --> verify the library slot has the tape
Configuration Files
/usr/openv/netbackup/bp.conf
configuration file, sets backup server and backup clients
force statement must be correct
client to browse from
client to restore to
/usr/openv/volmgr/vmconf
Logfiles
To utilize logfiles, create the corresponding directory in /usr/openv/netbackup/logs
Server Logfile directories:
admin - adminstrative commands
bpbrm - backup and restore manager
bpcd - client daemon
bpdbjobs - database manager program process
bpdm - disk manager process
bpjava-msvc - Java application server authentication service
bpjava-usvc - process that services Java requests
bprd - request daemon process
bpsched - scheduler process that runs on master servers
bptm - tape/optical media management process
user-ops - required directory for use by Java programs
xbpadm - X based administration utility
xbpmon - X based job monitor process
Client Logfile directories:
bp - client user interface process
bparchive - archive program
bpbackup - backup program
bpbkar - program that generates golden images
bpcd - client daemon
bpjava-msvc - Java application server authentication service
bpjava-usvc - process that services Java requests
bplist - program that lists backed up and archived files
bpmount - program that determines local mountpoints and wildcard expansion for multiple
streams
bphdb - Oracle database backup program start process
db_log - database specific extension log
tar - tar process log during restores
user_ops
Media Manager logging automatically goes to the system log using syslogd logging facility
.Logging will only occur if these directories are created. These directories will generate a lot of data and should be deleted when no longer necessary.
To increase the amount of logging information set VERBOSE=2 in /usr/open/netbackup/bp.conf
(default is VERBOSE=1)
Processes
ltid
acsd
vmd
Useful Commands
bpcllist - list classes
bpclinfo
vmpool - volume pools
vmpool -listall
vmpool -listscratch
bplabel -ev
bpbackup db --> backs up the catalog
bpclclients
Troubleshooting
bperror -statuscode <-- displays information about the netbackup error. No Backups are running:
Check system log file for error messages
Stop and restart all the netbackup processes
Look for a downed drive
/usr/openv/volmgr/bin/vmoprcmd
/usr/openv/volmgr/bin/vmoprcmd -up 0 --> this will bring up drive 0 if it's control shows
as down
Look for pending requests
/usr/openv/volmgr/bin/vmoprcmd or gui --> device management
If there is a pending request either re-assign it to a drive, or deny the request
Downed drive does not come back up or does not stay up
Check for a hardware problem by looking for messages on the tape library
Make sure there is not a tape stuck in the drive
Use robtest (described above) to look at the drives
If there is a tape stuck in the drive, try to remove it using robtest
If robtest fails, then you must manually remove it.
Verify the Client is communicating properly:
bpclncmd -ip
bpclntcmd -hn
bpclntcmd -pn --> from client only
Device Actions
Device Management --> info about tape drives
dlt
hcart (ultrium)
Media Actions
Media id must agree with # of the tape
Create a media id
actions -->new-->single volume-->dlt cart (not dlt2)
put it into the "netbackup" volume pool
Netbackup Client
To check things out do this:
It could be a couple things. Mostly DNS, bp.conf, or something stupid. On the client run this command
/usr/openv/netbackup/bin/bpclntcmd -pn
/usr/openv/netbackup/bin/bpclntcmd -server "server name"
/usr/openv/netbackup/bin/bpclntcmd ip "ip_address"
One of these usually fails and your able to fix it right off
1074 ./bpclntcmd -hn corpbu1
1075 ./bpclntcmd -ip 10.194.1.129
1076 ping 10.194.1.129
1077 ./bpclntcmd -hn corpldv1
1078 ./bpclntcmd -hn corpbu1.corporate.vox.net
1079 ping corpldv1
1080 ./bpclntcmd -ip 10.194.1.120
Must be able to resolve correctly from the master server and the client or it will not work!!!
Veritas NetBackup Performance Tuning Tips
Is your Veritas (Symantec, now) NetBackup Server agonizingly slow in taking backups? I found this undocumented feature on Veritas’ website, and quadrupled my backup speeds. Without going into too much details, I’ll give a brief on what was happening. From a local hard drive on a Linux box, backup onto a tape library was running at 16 MB/sec.
That’s slower than a snail with arthritis. Turns out, NetBackup uses certain default values for shared memory buffer sizes (details on Veritas’ website). The values happen to be 8 x 32KB of shared mem buffers.
To increase the size of the buffers and the number of buffers, you have to create the following two files:
/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS
/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
Simply fill in the values that you need for each. A good number for SIZE_DATA_BUFFERS would be 131072 (128KB), or, if your tape drive supports it, 262144. You can also choose to have 16 such buffers by typing in this number in the NUMBER_DATA_BUFFERS file. Note that you may have to increase the shared mem limits on your system before doing this.
This is applicable to a whole lot of previous versions of NetBackup starting from 3.4, and it works with the latest 6.0 version as well.
Clear Zombie Process
This script for clear or kill zombie process for solaris 9 and solaris 10.
------------------------------------------------------------------------------------------
#!/bin/ksh
trap '' 1 2 15
while :
do
for x in `ps -el awk '$2 ~ /Z/ {print $4}'`
do
preap $x
done
sleep 86400 # every 24 Hrs.
done
trap 1 2 15
This script for clear or kill zombie process for solaris 9 and solaris 10.
------------------------------------------------------------------------------------------
#!/bin/ksh
trap '' 1 2 15
while :
do
for x in `ps -el awk '$2 ~ /Z/ {print $4}'`
do
preap $x
done
sleep 86400 # every 24 Hrs.
done
trap 1 2 15
Subscribe to:
Posts (Atom)
