October 2025
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

Categories

October 2025
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

How to block ssh users after 3 failed login attempts using pam_tally2.so

ock user login after failed login attempts in Red Hat 6.x and CentOS 6.x

Earlier in RedHat based distro we used to setup pam_tally.so for locking the user login after some failed login attempts.

Now in Red Hat 6.x and CentOS 6.x we will use pam_tally2.so .

# cd /etc/pam.d
# cp -p password-auth-ac password-auth-ac.bak
# vi system-auth

note:password-auth is softlink of original file password-auth-ac . ls -la password-auth

Now add these two lines in password-auth-ac or password-auth

auth required pam_tally2.so deny=3 unlock_time=36000 audit

account required pam_tally2.so

Below is the sample of my system’s password-auth file.

[root@localhost ~]# cat /etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth required pam_tally2.so deny=3 unlock_time=36000 audit
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account required pam_tally2.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
[root@localhost ~]#

By default the failed logs are saved in /var/log/tallylog

To see user’s no. of failed attempts,command is –

pam_tally2 -u username

To reset failed login log(like faillog -u username -r), use below command

pam_tally2 -u username –reset

To know what are the options you can use with pam_tally2.so .Read the file from below given path.

cat /usr/share/doc/pam-1.1.1/txts/README.pam_tally2

April 5th, 2014 | Category: Centos | Leave a comment

WebSphere Application Server V8.5 Concepts, Planning, and Design Guide

WebSphere Application  Server V8.5 Concepts,  Planning, and Design Guide[gview file=”http://rmohan.com/wp-content/uploads/2014/04/WAS-V8.5-Concepts-Planning-and-Design-Guide.pdf”]

April 3rd, 2014 | Category: Websphere | Leave a comment

Change the delay time after a failed login attempt?

On Solaris, this can be changed in the /etc/default/login file. The default
is 4 seconds. In case you want no delay at all, change it to 0.

SLEEPTIME=0

On Linux, this can be configured in the /etc/login.defs file. The default
on Linux is 3 seconds.

FAIL_DELAY    0

But be careful. By changing this setting, a brute force attack might be easier

March 31st, 2014 | Category: Linux | Leave a comment

Sar Linux

 

Sar… Networking

echo "Rcvd Bytes - Time";\
(unset LANG; sar -n DEV) | grep eth0 | awk '{print ($5" - "$1)}' | sort -nr | head -n5;\
echo "Average:    `sar -n DEV |grep eth0| tail -n1 | awk '{print ($5)}'`"

Example:

$ echo "Rcvd Bytes - Time";\
(unset LANG; sar -n DEV) | grep eth0 | awk '{print ($5" - "$1)}' | sort -nr | head -n5;\
echo "Average:    `sar -n DEV |grep eth0| tail -n1 | awk '{print ($5)}'`"
Rcvd Bytes - Time
1.72 - 09:00:01
1.58 - 01:30:01
1.26 - 01:20:01
1.10 - 01:40:01
1.09 - 03:30:01
Average:    0.83 

xample:

 echo "Rcvd Bytes - Time";\
(unset LANG; sar -n DEV) | grep eth0 | awk '{print ($5" - "$1)}' | sort -nr | head -n5;\
echo "Average:    `sar -n DEV |grep eth0| tail -n1 | awk '{print ($5)}'`"
Rcvd Bytes - Time
1.72 - 09:00:01
1.58 - 01:30:01
1.26 - 01:20:01
1.10 - 01:40:01
1.09 - 03:30:01
Average:    0.83

Also just the usual ‘top n tailed’ format to show the last 20 records for ‘received bytes’:

(unset LANG; sar -n DEV) | grep tx |head -n1| awk '{print ("          "$6)}';\
(unset LANG; sar -n DEV) | grep eth0 | tail -20 | awk '{print ($1,$2" - "$6)}';

Example:

  (unset LANG; sar -n DEV) | grep tx |head -n1| awk '{print ("          "$6)}';\
(unset LANG; sar -n DEV) | grep eth0 | tail -20 | awk '{print ($1,$2" - "$6)}';
txkB/s
11:50:01 eth0 - 1.69
12:00:01 eth0 - 0.40
12:10:01 eth0 - 0.01
12:20:01 eth0 - 0.01
12:30:01 eth0 - 0.01
12:40:01 eth0 - 0.01
12:50:01 eth0 - 0.01
13:00:01 eth0 - 0.01
13:10:01 eth0 - 0.01
13:20:01 eth0 - 0.01
13:30:01 eth0 - 0.01
13:40:01 eth0 - 0.01
13:50:01 eth0 - 0.25
14:00:01 eth0 - 0.10
14:10:01 eth0 - 0.02
14:20:01 eth0 - 0.01
14:30:01 eth0 - 0.03
14:40:01 eth0 - 0.86
14:50:01 eth0 - 0.22
Average: eth0 - 1.56

You’ll notice that I use ‘unset LANG’ in a lot of the examples. This removes AM/PM from the output and tailors the results instead in 24hr clock format. It makes the output a lot more predictable when on different machines!

Sar… Memory

o one of the big problems with Sar is that it’s pretty ‘dumb’ with its ‘memory free’ reporting. Although the information from Sar is great, a colleague of mine gave me the basis for a few more one liners that will perform a calculation to ensure that buffers/cache are taken into account as their usage is relinquished under system load.

Again, all of my commands are pretty hacky, and probably not examples of good scripting – but they get the job done!

Show the ‘real’ memory usage, the last column gives the true value:

(unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’

Example:

(unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’

Linux 2.6.xx (influencd.co.uk)     05/31/10
00:00:01    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
00:10:01       109904    295708     72.90     43432     73392    764192     22232      2.83      3592 44.1022
00:20:01       107480    298132     73.50     43556     73404    764192     22232      2.83      3592 44.6663
00:30:01       107328    298284     73.54     43668     73404    764192     22232      2.83      3592 44.6762

Showing the ‘real’ memory usage in a presentable format, top and tailing the results:

(unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6); \
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1″    –  “$4” – “$11)}’| head -1;\
echo “Time     – Real memory used %”; (unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1″ – “$11)}’| tail -10

Example:

(unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6); \
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1”    –  “$4” – “$11)}’| head -1;\
echo “Time     – Real memory used %”; (unset LANG ;sar  -r) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1″ – “$11)}’| tail -10

Linux    –  05/31/10 –
Time     – Real memory used %
19:50:01 – 86.6651
20:00:01 – 87.8406
20:10:01 – 88.1177
20:20:01 – 87.031
20:30:01 – 87.315
20:40:01 – 89.1699
20:50:01 – 89.4323
21:00:01 – 89.0723
21:10:01 – 90.3524
Average: – 45.4244

The below will give an hourly snapshot of the memory usage for every day that there is a sar log for, in reverse date order:

for i in $(ls /var/log/sa/ | grep -v sar);\
do (unset LANG ;sar  -f /var/log/sa/$i -r) | awk ‘$3~/[0-9]/{total=$3+$2;\
usedbc=$3-($5+$6); pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’\
| awk ‘{print ($1” – “$4” – “$11)}’| head -1 | grep -v “memused”; echo “Time     – Real memory used %”;\
(unset LANG ;sar  -r  -f /var/log/sa/$i) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);pc_used=(100*usedbc)/total;\
print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1″ – “$11)}’| grep “00:01” | grep -v “memused”; echo; done

Example:

[root@influencd ~]$  for i in $(ls -t /var/log/sa/ | grep -v sar);\
do (unset LANG ;sar  -f /var/log/sa/$i -r) | awk ‘$3~/[0-9]/{total=$3+$2;\
usedbc=$3-($5+$6); pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’\
| awk ‘{print ($1″ – “$4” – “$11)}’| head -1 | grep -v “memused”; echo “Time     – Real memory used %”;\
(unset LANG ;sar  -r  -f /var/log/sa/$i) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);pc_used=(100*usedbc)/total;\
print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($1″ – “$11)}’| grep “00:01” | grep -v “memused”; echo; done

Linux – 05/24/10 –
Time     – Real memory used %
00:00:01 –
01:00:01 – 89.3317
02:00:01 – 88.9066
03:00:01 – 88.5102
[snip]
Linux – 05/23/10 –
Time     – Real memory used %
00:00:01 –
01:00:01 – 49.6731
02:00:01 – 49.1317
[etc etc]

The below uses the day’s average from the sar information, and presents it for each day that there’s a log:

echo “Real memory used %”;\
for i in $(ls /var/log/sa/ | grep -v sar); do (unset LANG ;sar  -f /var/log/sa/$i -r) | awk ‘$3~/[0-9]/{total=$3+$2; \
usedbc=$3-($5+$6); pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($4)}’\
| head -1 | grep -v “memused” ;\
(unset LANG ;sar  -r  -f /var/log/sa/$i) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print (”           “$11)}’| tail -1;done

Example:

echo “Real memory used %”;\
for i in $(ls /var/log/sa/ | grep -v sar); do (unset LANG ;sar  -f /var/log/sa/$i -r) | awk ‘$3~/[0-9]/{total=$3+$2; \
usedbc=$3-($5+$6); pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print ($4)}’\
| head -1 | grep -v “memused” ;\
(unset LANG ;sar  -r  -f /var/log/sa/$i) | awk ‘$3~/[0-9]/{total=$3+$2; usedbc=$3-($5+$6);\
pc_used=(100*usedbc)/total;print $0,pc_used} $3!~/[0-9]/{print $0}’ | awk ‘{print (”           “$11)}’| tail -1;done

Real memory used %
05/23/10
49.2444
05/24/10
40.8514
05/25/10
43.1346
05/26/10
50.288
05/27/10
60.299
05/28/10
65.9872
05/29/10
70.6873
05/30/10
40.3156
05/31/10
45.7713

In contrast if we compare the ‘dumb’ memory usage to the example above, you can see some pretty major differences in terms of the value:

echo ”     Memory used %”; for i in $(ls /var/log/sa/ | grep -v sar); do echo $i ;\
sar  -r -f /var/log/sa/$i | tail -1 | awk ‘{print ($1″ – “$4)}’; done

Example:

echo ”     Memory used %”; for i in $(ls /var/log/sa/ | grep -v sar); do echo $i ;\
sar  -r -f /var/log/sa/$i | tail -1 | awk ‘{print ($1″ – “$4)}’; done

Memory used %
sa23
Average: – 70.35
sa24
Average: – 78.06
sa25
Average: – 94.58
sa26
Average: – 92.61
sa27
Average: – 89.86
sa28
Average: – 93.69
sa29
Average: – 97.31
sa30
Average: – 65.48
sa31
Average: – 75.65

 Sar… CPU

 

Cpu information:

Display ‘Processor Queue Length’ information from the last 15 intervals in a presentable format:

sar -q | head -3; sar -q | tail -n15

Example:

sar -q | head -3; sar -q | tail -n15
Linux 2.6.xx (influencd.co.uk)     05/31/2010
12:00:01 AM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
04:30:01 PM         0       104      0.02      0.01      0.00
04:40:01 PM         0       105      0.00      0.00      0.00
04:50:01 PM         0        97      0.00      0.00      0.00
05:00:01 PM         0        97      0.00      0.00      0.00
05:10:01 PM         0        97      0.00      0.00      0.00
05:20:01 PM         0        97      0.00      0.00      0.00
05:30:01 PM         0        97      0.00      0.00      0.00
05:40:01 PM         0        97      0.00      0.00      0.00
05:50:01 PM         0        97      0.00      0.00      0.00
06:00:01 PM         0        97      0.00      0.00      0.00
06:10:01 PM         0        98      0.07      0.02      0.00
06:20:01 PM         0       109      0.00      0.00      0.00
06:30:01 PM         0       106      0.13      0.03      0.01
06:40:01 PM         0       110      0.07      0.02      0.00
Average:            0        98      0.00      0.00      0.00

Display general CPU stats from the last 15 intervals in a presentable format:

sar | head -3; sar | tail -n15

Example:

sar | head -3; sar | tail -n15
Linux 2.6.xx (influencd.co.uk)     05/31/2010

12:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:30:01 PM     all      0.00      0.00      0.00      0.01      0.00     99.98
04:40:01 PM     all      0.01      0.00      0.00      0.03      0.00     99.95
04:50:01 PM     all      0.02      0.00      0.01      0.02      0.00     99.95
05:00:01 PM     all      0.00      0.00      0.00      0.00      0.00     99.98
05:10:01 PM     all      0.00      0.00      0.00      0.01      0.00     99.98
05:20:01 PM     all      0.01      0.00      0.00      0.00      0.00     99.98
05:30:01 PM     all      0.00      0.00      0.00      0.01      0.00     99.99
05:40:01 PM     all      0.00      0.00      0.00      0.01      0.00     99.99
05:50:01 PM     all      0.00      0.00      0.00      0.00      0.00     99.99
06:00:01 PM     all      0.00      0.00      0.00      0.01      0.00     99.98
06:10:01 PM     all      0.03      0.00      0.01      0.02      0.00     99.94
06:20:01 PM     all      0.17      0.00      0.02      0.21      0.01     99.59
06:30:01 PM     all      1.09      0.00      0.06      0.34      0.03     98.48
06:40:01 PM     all      0.35      0.00      0.02      0.15      0.01     99.47
Average:        all      0.03      0.00      0.01      0.05      0.00     99.92

Presentable CPU idle percentage, for the last 15 intervals:

unset LANG;date;echo “CPU idle  %”; sar | tail -20| awk ‘{print ($1″ “$2” – “$8)}’

Example:

unset LANG;date;echo “CPU idle  %”; sar | tail -20| awk ‘{print ($1″ “$2” – “$8)}’
Mon May 31 19:09:53 GMT 2010
CPU idle  %
16:00:01 all – 99.49
16:10:01 all – 99.97
16:20:02 all – 99.98
16:30:01 all – 99.98
16:40:01 all – 99.95
16:50:01 all – 99.95
17:00:01 all – 99.98
17:10:01 all – 99.98
17:20:01 all – 99.98
17:30:01 all – 99.99
17:40:01 all – 99.99
17:50:01 all – 99.99
18:00:01 all – 99.98
18:10:01 all – 99.94
18:20:01 all – 99.59
18:30:01 all – 98.48
18:40:01 all – 99.47
18:50:01 all – 99.80
19:00:01 all – 99.86
Average: all – 99.92

CPU Idle average for each day available in the Sar logs:

echo “Average CPU idle  %”; for i in $(ls /var/log/sa/ | grep -v sar); \
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’ ;\
sar -f /var/log/sa/$i | tail -1 | awk ‘{print (”       “$7)}’; done

Example:

echo “Average CPU idle  %”; for i in $(ls /var/log/sa/ | grep -v sar); \
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’ ;\
sar -f /var/log/sa/$i | tail -1 | awk ‘{print (”       “$7)}’; done
Average CPU idle  %
2010-05-23 23:50
0.00
2010-05-24 23:50
0.00
2010-05-25 23:50
0.00
2010-05-26 23:50
0.00
2010-05-27 23:50
0.00
2010-05-28 23:50
0.01
2010-05-29 23:50
0.00
2010-05-30 23:50
0.00
2010-05-31 19:00
0.00

Average processor queue length for every day available in the sar logs:

echo “Average Processor Queue length”; for i in $(ls /var/log/sa/ | grep -v sar);\
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’ ; \
sar -q -f /var/log/sa/$i | tail -1 | awk ‘{print (”       “$6)}’; done

Example:
echo “Average Processor Queue length”; for i in $(ls /var/log/sa/ | grep -v sar);\
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’ ; \
sar -q -f /var/log/sa/$i | tail -1 | awk ‘{print (”       “$6)}’; done
Average Processor Queue length
2010-05-23 23:50
0.00
2010-05-24 23:50
0.00
2010-05-25 23:50
0.00
2010-05-26 23:50
0.00
2010-05-27 23:50
0.00
2010-05-28 23:50
0.00
2010-05-29 23:50
0.00
2010-05-30 23:50
0.00
2010-05-31 20:10
0.00

Show CPU processor queue length use by hourly snapshot, for every day in the last month:

date;echo;echo “Processor Queue Length (15m)”;echo; for i in $(ls /var/log/sa/ | grep -v sar);\
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’;\
sar -q -f /var/log/sa/$i | grep “:00:” | awk ‘{print ($1,$2″ – “$7)}’; echo; done

Example:

[root@influencd ~]# date;echo;echo “Processor Queue Length (15m)”;echo; for i in $(ls /var/log/sa/ | grep -v sar);\
do ll /var/log/sa/$i | awk ‘{print ($6,$7)}’;\
sar -q -f /var/log/sa/$i | grep “:00:” | awk ‘{print ($1,$2″ – “$7)}’; echo; done
Mon May 31 19:02:30 GMT 2010
Processor Queue Length (15m)

2010-05-23 23:5012:00:01 AM – ldavg-15
01:00:01 AM – 0.00
02:00:01 AM – 0.00
03:00:01 AM – 0.00
[Snip]
2010-05-24 23:50
12:00:01 AM – ldavg-15
01:00:01 AM – 0.00
02:00:01 AM – 0.00
03:00:01 AM – 0.00
[etc etc]

Hourly Processor queue length with 15/m averages:

sar -q | grep 00:01| awk ‘{print ($1” “$2” – “$7)}’|head -3;\
sar -q |grep 00:01| awk ‘{print ($1,$2” – “$7)}’| tail -n15

Example:

sar -q | grep 00:01| awk ‘{print ($1” “$2” – “$7)}’|head -3;\
sar -q |grep 00:01| awk ‘{print ($1,$2” – “$7)}’| tail -n15
12:00:01 AM – ldavg-15
01:00:01 AM – 0.00
02:00:01 AM – 0.00
04:00:01 AM – 0.00
05:00:01 AM – 0.00
06:00:01 AM – 0.00
07:00:01 AM – 0.00
08:00:01 AM – 0.00
09:00:01 AM – 0.00
10:00:01 AM – 0.00
11:00:01 AM – 0.00
12:00:01 PM – 0.00
02:00:01 PM – 0.00
03:00:01 PM – 0.00
04:00:01 PM – 0.00
05:00:01 PM – 0.00
06:00:01 PM – 0.00
07:00:01 PM – 0.00

March 30th, 2014 | Category: Linux | Leave a comment

How to enable SAR (System Activity Reporter) on Solaris

Solaris 10 comes with a new feature called SMF (Solaris Management Facility), and to
enable SAR, we need to update the SMF database with this information.

# svcadm enable svc:/system/sar:default

Now lets check if it is really enabled.

# svcs -x system/sar
svc:/system/sar:default (system activity reporting package)
State: online since Sun Nov 16 10:07:42 2008
See: sar(1M)
See: /var/svc/log/system-sar:default.log
Impact: None.

OK. Looks good, but this was only the first part. The second part is, to activate the
two shell scripts that comes with SAR:

/usr/lib/sa/sa1 = a shell script to collect and store data in the binary file /var/adm/sa/sadd, where dd is the current day
/usr/lib/sa/sa2 = a shell script that writes a daily report in the file /var/adm/sa/sardd

To run those scripts regurarly, we need to enable the three lines, in the crontab of the user sys:

# crontab -l sys
#ident "@(#)sys 1.5 92/07/14 SMI" /* SVr4.0 1.2 */
#
# The sys crontab should be used to do performance collection. See cron
# and performance manual pages for details on startup.
#
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

That’s it. Now the System Activity Reporter is running every 20 minutes,
and at 18:05 o’clock a daily report is created.

March 30th, 2014 | Category: Solaris | Leave a comment

Solaris 10 Password Policy Enforcement

I was recently handed a baseline policy that was to implemented for all users on the Solaris 10 systems that I support.  After a small amount of research I was able to find the various pieces that needed to be altered.

Desired Policy

After discussion between the security officer and the other management level staff, the following policy was decided upon:

Normal User Password Requirements

  • at least 8 characters in length
  • no more than 20 characters in length
  • contain at least on letter
  • contain at least one number
  • forced to change at least every 180 days
  • 15 minute lockout after 5 unsuccessful attempts

Most of the restrictions were fairly basic and could be easily accomplished.  The only one that I could find no mechanism for control of in Solaris 10 is the automatic unlock of an account after the specified 15 minute lockout.  While it is possible to determine when an account has been locked by looking at the timestamp in the syslog, there is no automated method for unlocking the account after a certain amount of time has elapsed.  I suppose it would be possible to write a script to check the entries in the shadow file then grep the syslog then do some math on the timestamp, but honestly I am not worried about it.

Implementation

The implementation process involves editing two files that are key to the functionality of user login security.  As always when altering system files it is a good idea to make backups of the originals in case things go wrong.  The files involved are:

  1. /etc/default/login
  2. /etc/default/passwd

Setting the account lockout (aka Three Strikes)

Generally the default on a Solaris 10 system is to set the account lockout to three password retries before an account is locked.  We decided to relax this a little and allow for five retries.

  1. Open /etc/default/login in your favorite editor
  2. Search for the line reading RETRIES=3
  3. Change the line to read RETRIES=5

Configuring the complexity rules

The password complexity ruleset for Solaris 10 is fairly understandable.  The rules are defined in /etc/default/passwd and the values to be tweaked are:

  • MINDIFF
  • MINALPHA
  • MINNONALPHA
  • MINUPPER
  • MINLOWER
  • MAXREPEATS
  • MINSPECIAL
  • MINDIGIT
  • WHITESPACE

The desired policy decided upon was to require at least one number and one letter.  There was some discussion about special characters, but it was decided to not require any special characters for normal user accounts.  Given these requirements the following process is used to implement the complexity ruleset:

  1. Open the file /etc/default/passwd in your favorite editor
  2. Set the password complexity tunables to look as follows
MINDIFF=3
MINALPHA=1
#MINNONALPHA=1
#MINUPPER=1
#MINLOWER=1
MAXREPEATS=0
#MINSPECIAL=0
MINDIGIT=1
WHITESPACE=YES

Setting the password expiration and length rules

Configuring account lockouts and password complexity is a great start, however it is not the complete picture.  While reasonable complexity rules will allow users to set passwords that they can readily remember, and a flexible lockout value will give some room for fumble fingers, if users are not required to change their passwords every so often then the security of the system can suffer as well.

You also should consider password length.  A shorter password, regardless of complexity, is going to be easier to crack from an algorithmic standpoint.  This is simply due to the mathematical requirements.  The problem is that user’s tend to not like long passwords.  As you increase the password length, you increase the likelihood the passwords will use dictionary words (we can account for that as well).

The agreed upon setting for normal users on our systems was 180 days.  Unfortunately Solaris 10 uses a setting measured in weeks and not days.  What this means is that the setting will have to be slightly longer.  The password length was decided to be at least 8 characters and no longer than 20 characters.  Also, Solaris 10 has no setting to enable a maximum password length.

  1. Open /etc/default/passwd in your favorite editor
  2. Set the value for MAXWEEKS to be the value of number of days divided by 7, rounding up
  3. Set the value for PASSLENGTH to be the value of the minimum number of characters

Important Notes and Considerations

Password Length

The default algorithm used for passwords under Solaris 10 is crypt_unix.  This algorithm is not considered sufficiently secure, even by Oracle.  You should investigate using a different algorithm such as MD5 or Blowfish instead.  The default will not allow for passwords that are longer than 8 characters.  You can set the password to be longer, but all characters after the eighth position will be discarded during the authentication check process.

Retroactive Usage

Changes to the password expiration policy is not immediately retroactive.  For the expiration requirements to take effect on existing accounts you will need to initiate a manual password change for the shadow file entry to be updated.

Dictionary Words

When Solaris 10 was introduced one of the changes made to PAM was the ability to use a comma-delimited list of dictionary files to avoid usage of common words during password selection.  This can be configured with the DICTIONLIST variable in the /etc/default/passwd file.

Applying lockout to the root user

While this is not the default, you can apply the lockout rule to the root user account by editing the /etc/user_attr file and changing the lock_after_retries value for this user to yes.  Be warned this is not recommended since a locked account can only be unlocked by the root user.  If your root level account becomes locked then you will need to have an account that allows sudo access or you will end up going to some extreme lengths to re-enable access to the system.

March 30th, 2014 | Category: Solaris | Leave a comment

How to Create or Edit a crontab File

Before You Begin

If you are creating or editing a crontab file that belongs to root or another user you must become root.

You do not need to become root to edit your own crontab file.

  1. Create a new crontab file, or edit an existing file. 
    # crontab -e [username]

    where username specifies the name of the user’s account for which you want to create or edit a crontab file. You can create your own crontab file without superuser privileges, but you must have superuser privileges to creating or edit a crontab file for root or another user.

    Caution Caution – If you accidentally type the crontab command with no option, press the interrupt character for your editor. This character allows you to quit without saving changes. If you instead saved changes and exited the file, the existing crontab file would be overwritten with an empty file.
  2. Add command lines to the crontab file.Follow the syntax described in Syntax of crontab File Entries. The crontab file will be placed in the /var/spool/cron/crontabs directory.
  3. Verify your crontab file changes. 
    # crontab -l [username]

Example 14-1 Creating a crontab File

The following example shows how to create a crontab file for another user.

# crontab -e jones

The following command entry added to a new crontab file automatically removes any log files from the user’s home directory at 1:00 a.m. every Sunday morning. Because the command entry does not redirect output, redirect characters are added to the command line after *.log. Doing so ensures that the command executes properly.

# This command helps clean up user accounts.
1 0 * * 0 rm /home/jones/*.log > /dev/null 2>&1

How to Verify That a crontab File Exists

To verify that a crontab file exists for a user, use the ls -l command in the /var/spool/cron/crontabs directory. For example, the following output shows that crontab files exist for users jones and smith. 

$ ls -l /var/spool/cron/crontabs
March 30th, 2014 | Category: Solaris | Leave a comment

Solaris ssh restart

To check if the service is online or offline:
# svcs -v ssh
online – 12:23:17 115 svc:/network/ssh:default

To stop the service:
#svcadm disable network/ssh

To start the service:
#svcadm enable network/ssh

To restart the service:
# svcadm restart network/ssh

To Restart the SSH Service

Login to the command-line terminal
Run the command:

svcadm restart svc:/network/ssh:default

svcs -Ho state svc:/network/inetd

 

Now lets check if it is really enabled.

# svcs -x system/sar
svc:/system/sar:default (system activity reporting package)
State: online since Sun Nov 16 10:07:42 2008
See: sar(1M)
See: /var/svc/log/system-sar:default.log
Impact: None.

etting Information About Services Running on a System

Let’s first take a look at the svcs command to generate a list of service instances that are being run on the system. Without any additional options, svcs provides a quick one-line status of each enabled service instance, as shown in Listing 1.

# svcs
STATE          STIME    FMRI
legacy_run     Jun_14   lrc:/etc/rcS_d/S99openconnect-clean
legacy_run     Jun_14   lrc:/etc/rc2_d/S47pppd
legacy_run     Jun_14   lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run     Jun_14   lrc:/etc/rc2_d/S89PRESERVE
disabled       Jun_14   svc:/platform/i86pc/acpihpd:default
disabled       Jun_14   svc:/network/ipsec/policy:default
disabled       Jun_14   svc:/network/nis/domain:default
online         Jun_14   svc:/system/early-manifest-import:default
online         Jun_14   svc:/system/svc/restarter:default
online         Jun_14   svc:/network/tcp/congestion-control:vegas
online         Jun_14   svc:/network/tcp/congestion-control:highspeed
online         Jun_14   svc:/network/sctp/congestion-control:highspeed
online         Jun_14   svc:/network/sctp/congestion-control:vegas
online         Jun_14   svc:/network/tcp/congestion-control:newreno
online         Jun_14   svc:/network/sctp/congestion-control:cubic
online         Jun_14   svc:/network/tcp/congestion-control:cubic
…
online         Jun_14   svc:/system/zones:default
online         Jun_14   svc:/system/power:default
online         Jun_14   svc:/system/hal:default
online         Jun_14   svc:/application/texinfo-update:default
online         Jun_14   svc:/application/pkg/update:default

Listing 1. Example svcs Output

# svcs -a
STATE          STIME    FMRI
legacy_run     Jun_14   lrc:/etc/rcS_d/S99openconnect-clean
legacy_run     Jun_14   lrc:/etc/rc2_d/S47pppd
legacy_run     Jun_14   lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run     Jun_14   lrc:/etc/rc2_d/S89PRESERVE
disabled       Jun_14   svc:/system/device/mpxio-upgrade:default
disabled       Jun_14   svc:/network/install:default
disabled       Jun_14   svc:/network/ipfilter:default
disabled       Jun_14   svc:/network/ipsec/ike:default
disabled       Jun_14   svc:/network/ipsec/manual-key:default
disabled       Jun_14   svc:/system/name-service-cache:default
disabled       Jun_14   svc:/network/ldap/client:default
disabled       Jun_14   svc:/network/nis/client:default
disabled       Jun_14   svc:/network/ibd-post-upgrade:default
disabled       Jun_14   svc:/network/inetd-upgrade:default
disabled       Jun_14   svc:/network/nfs/status:default
disabled       Jun_14   svc:/network/nfs/nlockmgr:default
…
online         Jun_14   svc:/system/zones:default
online         Jun_14   svc:/system/power:default
online         Jun_14   svc:/system/hal:default
online         Jun_14   svc:/application/texinfo-update:default
online         Jun_14   svc:/application/pkg/update:default

this case, it amounts to 111 disabled services on this system.

# svcs | wc -l
147
# svcs -a | wc -l
258

Now that we’ve seen a listing of all service instances, let’s explore one of the service instances and get some more information about it. In this example, let’s choose the svc:/system/zones:default service instance. We can use the -l option and the service name to get more information, as shown in Listing 3.

# svcs -l svc:/system/zones:default
fmri         svc:/system/zones:default
name         Zones autoboot and graceful shutdown
enabled      true
state        online
next_state   none
state_time   June 14, 2012 08:30:31 PM NZST
logfile      /var/svc/log/system-zones:default.log
restarter    svc:/system/svc/restarter:default
manifest     /etc/svc/profile/generic.xml
manifest     /lib/svc/manifest/system/zones.xml
manifest     /lib/svc/manifest/system/zonestat.xml
dependency   require_all/none svc:/milestone/multi-user-server (online)
dependency   optional_all/none svc:/system/pools:default (disabled)
dependency   optional_all/none svc:/system/pools/dynamic:default (disabled)
dependency   optional_all/none svc:/system/zones-monitoring (online)

Listing 3. Getting Information About a Service Instance

svcs -d svc:/system/zones:default
gman@rampage:~$ svcs -d zones
STATE          STIME    FMRI
disabled       Jun_14   svc:/system/pools:default
disabled       Jun_14   svc:/system/pools/dynamic:default
online         Jun_14   svc:/system/zones-monitoring:default
online         Jun_14   svc:/milestone/multi-user-server:default

Let’s now have a look at another related service instance, svc:/system/zones-monitoring:default, and see what services depend on this service using the -D option to svcs:

# svcs -D svc:/system/zones-monitoring:default
STATE          STIME    FMRI
online           Jun_14   svc:/system/zone:default

The result, svc:/system/zones:default, is relatively unsurprising since we had already determined that relationship in the previous example. One of the key features of SMF is that administrators manage services rather than the individual processes themselves. But what if we wanted to know what processes were being started by a given service instance? We can look at this easily by using the -p option to svcs, which ps helps to confirm:

# svcs -p zones-monitoring
STATE          STIME    FMRI
online         Jun_14   svc:/system/zones-monitoring:default
Jun_14        216 zonestatd

# ps 216
PID TT       S  TIME COMMAND
216 ?        S  0:01 /usr/lib/zones/zonestatd

Up until now, we have always used the full FMRI on the command line to specify the service that we are interested in. SMF also supports abbreviated FMRIs. All of the following examples of getting information about the svc:/system/system-log:default service instance are equivalent because they each uniquely identify the service:

# svcs -l svc:/system/system-log:default
# svcs -l system/system-log:default
# svcs -l system-log:default
# svcs -l system-log

Starting and Stopping Services

Now that we’ve looked at what services are running on the system and retrieved some basic information about those services, let’s now look at how we can administer the state of those services with the svcadm command. For the next few examples, we’ll take a look at the svc:/application/management/net-snmp:default service instance, which is responsible for managing the /usr/sbin/snmpd SNMP agent that is used to collect information about a system through a set of Management Information Bases (MIBs). We can check the initial state of this service and the types of dependencies it has using the svcs command, as shown in Listing 4.

# svcs net-snmp
STATE          STIME    FMRI
disabled       Jun_14   svc:/application/management/net-snmp:default
# svcs -d net-snmp
STATE          STIME    FMRI
disabled       Jun_14   svc:/network/rpc/rstat:default
online         Jun_14   svc:/system/cryptosvc:default
online         Jun_14   svc:/milestone/network:default
online         Jun_14   svc:/system/filesystem/local:default
online         Jun_14   svc:/milestone/name-services:default
online         Jun_14   svc:/system/system-log:default
online         Jun_14   svc:/milestone/multi-user:default
# svcs -l net-snmp
fmri         svc:/application/management/net-snmp:default
name         net-snmp SNMP daemon
enabled      false
state        disabled
next_state   none
state_time   June 19, 2012 01:50:37 PM NZST
logfile      /var/svc/log/application-management-net-snmp:default.log
restarter    svc:/system/svc/restarter:default
contract_id
manifest     /etc/svc/profile/generic.xml
manifest     /lib/svc/manifest/application/management/net-snmp.xml
dependency   require_all/none svc:/milestone/multi-user (online)
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   optional_all/none svc:/milestone/name-services (online)
dependency   optional_all/none svc:/system/system-log (online)
dependency   optional_all/none svc:/network/rpc/rstat (disabled)
dependency   require_all/restart svc:/system/cryptosvc (online)
dependency   require_all/restart svc:/milestone/network (online)
dependency   require_all/refresh file://localhost/etc/net-snmp/snmp/snmpd.conf (online)

Listing 4. Checking the Initial State and Dependencies of a Service

The net-snmp service instance is initially disabled, but all its required dependencies are online (only one optional dependency, svc:/network/rpc/rstat, is disabled). Let’s go ahead and enable this using the svcadm enable command:

# svcadm enable net-snmp
# svcs -p net-snmp
STATE          STIME    FMRI
online          9:33:40 svc:/application/management/net-snmp:default
9:33:40     6062 snmpd

As we can see above, the /usr/sbin/snmpd daemon agent has now been started, and we can verify that the SNMP agent is working using the snmpwalk command, as shown in Listing 5.

# snmpwalk -v 1 -c public localhost
SNMPv2-MIB::sysDescr.0 = STRING: SunOS rampage 5.11 11.1 i86pc
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.3
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (186832) 0:31:08.32
SNMPv2-MIB::sysContact.0 = STRING: “System administrator”
SNMPv2-MIB::sysName.0 = STRING: rampage
SNMPv2-MIB::sysLocation.0 = STRING: “System administrators office”
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (31) 0:00:00.31
SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.
…
NOTIFICATION-LOG-MIB::nlmConfigGlobalEntryLimit.0 = Gauge32: 1000
NOTIFICATION-LOG-MIB::nlmConfigGlobalAgeOut.0 = Gauge32: 1440 minutes
NOTIFICATION-LOG-MIB::nlmStatsGlobalNotificationsLogged.0 = Counter32: 0 notifications
NOTIFICATION-LOG-MIB::nlmStatsGlobalNotificationsBumped.0 = Counter32: 0 notifications

Listing 5. Verifying That the SNMP Agent is Working

Before we go any further, let’s also take a quick look at SMF’s ability to restart any processes in the event of a hardware or software failure. As we saw above, the /usr/sbin/snmpd agent daemon is running with a process ID of 6062. Let’s kill that process and see what happens:

# kill -9 6062
# svcs -p net-snmp
STATE          STIME    FMRI
online          9:38:12 svc:/application/management/net-snmp:default
9:38:12     6065 snmpd

We can see that the /usr/sbin/snmpd process has restarted with a new process ID of 6065 and the service is still online! Permanently disabling the service is also simple by using the svcadm disable command, as follows:

# svcadm disable net-snmp
# svcs net-snmp
STATE          STIME    FMRI
disabled        9:44:40 svc:/application/management/net-snmp:default
# snmpwalk -v 1 -c public localhost
Timeout: No response from localhost

If we had chosen to, we could also have disabled the service temporarily until the next reboot using the -t option. Each service in SMF is always in one of a few different states, as shown in Table 2.
Table 2. SMF Service States
State     Description
uninitialized     This is the initial state of all services until its restarter (usually svc.startd) moves services to another state.
offline     The instance is enabled but not yet running or unable to run.
online     The instance is enabled and running.
maintenance     The instance is enabled but unable to run for some reason, and administrative action will be required.
disabled     The instance is disabled.
legacy-run     The service is not directly managed by SMF, but it was started at some point.

If, for any reason, we wanted to restart a service, we could use the svcadm restart command.
SMF Milestones

SMF milestones are services that aggregate multiple service dependencies and describe a specific state of system readiness on which other services can depend. Administrators can see the list of milestones that are defined by using the svcs command, as shown in Listing 6.

# svcs milestone*
STATE          STIME    FMRI
online         Jun_30   svc:/milestone/unconfig:default
online         Jun_30   svc:/milestone/config:default
online         Jun_30   svc:/milestone/devices:default
online         Jun_30   svc:/milestone/network:default
online         Jun_30   svc:/milestone/single-user:default
online         Jun_30   svc:/milestone/name-services:default
online         Jun_30   svc:/milestone/self-assembly-complete:default
online         Jun_30   svc:/milestone/multi-user:default
online         Jun_30   svc:/milestone/multi-user-server:default

Listing 6. Listing Milestones

Some of the above milestones correspond to the traditional system run levels S (svc:/milestone/single-user), 2 (svc:/milestone/multi-user), and 3 (svc:/milestone/multi-user-server). Others correspond to internal implementation of the system configuration framework, sysconfig. While changing milestones is possible with svcadm, it is recommended that administrators continue to use the init command.
Making Some Basic Configuration Changes to Services

From time to time, it might be necessary to modify some of the configuration behind a service instance. One of the significant changes in Oracle Solaris 11 is that some of the system configuration traditionally located in /etc was moved into the SMF configuration repository. One of the primary drivers for this change was to more seamlessly manage a system upgrade and preservation of configuration while being able to easily merge in any vendor-provided configuration for configuration options that haven’t been locally modified. The SMF configuration repository, managed by the svc.configd daemon, has been modified to store its configuration in a series of layers, as a series of administrative customizations and configuration provided through site profiles, system profiles, and manifests. We will cover this in more detail in another article.

At the heart of the configuration repository are property groups and properties. Property groups are exactly what they say they are—a set of properties that have been organized into a logical grouping. Within each property group, an arbitrary number of properties can exist storing a variety of different configuration types—simple strings, integers, Booleans, and network addresses, to name a few. Properties and property groups can be specific to a given service instance or global across all instances of a particular service. A property might have different values set on a parent service and a service instance, and the value from the service instance will take precedence.

Before we go into detail about how to modify changes in the SMF repository, let’s quickly look at the command svcprop and how we can use it to list property groups and properties of a given service or service instance. Listing 7 shows it being used with the svc:/network/dns/client:default instance.

# svcprop dns/client:default
general/complete astring
general/enabled boolean true
general/action_authorization astring solaris.smf.manage.name-service.dns.client
general/entity_stability astring Unstable
general/single_instance boolean true
general/value_authorization astring solaris.smf.manage.name-service.dns.client
config/value_authorization astring solaris.smf.value.name-service.dns.client
config/nameserver net_address 192.168.0.1
sysconfig/group astring naming_services
milestoneconfig_network_dns_client/entities fmri svc:/milestone/config
milestoneconfig_network_dns_client/external boolean true
milestoneconfig_network_dns_client/grouping astring optional_all
milestoneconfig_network_dns_client/restart_on astring none
milestoneconfig_network_dns_client/type astring service
location_dns-client/entities fmri svc:/network/location:default
…
restarter/state_timestamp time 1339662573.051463000
restarter_actions/auxiliary_tty boolean false
restarter_actions/auxiliary_fmri astring svc:/network/location:default
general_ovr/enabled boolean true

Listing 7. Listing Property Groups and Properties

In Listing 7, we are using svcprop without any other options, and we get a composed view by default—one that includes properties from both the parent service and the service instance. If we just wanted to look at the instance properties, we can use the -C option, as shown in Listing 8.

# svcprop -C dns/client:default
general/complete astring
general/enabled boolean true
restarter/logfile astring /var/svc/log/network-dns-client:default.log
restarter/start_pid count 572
restarter/start_method_timestamp time 1339662573.041262000
restarter/start_method_waitstatus integer 0
restarter/transient_contract count
restarter/auxiliary_state astring dependencies_satisfied
restarter/next_state astring none
restarter/state astring online
restarter/state_timestamp time 1339662573.051463000
restarter_actions/auxiliary_tty boolean false
restarter_actions/auxiliary_fmri astring svc:/network/location:default
general_ovr/enabled boolean true

Listing 8. Listing Only Instance Properties

If we wanted to focus on a particular property, we can use the -p option to specify the property group and property. In this case, we’re going to find the config/nameserver property on the service rather than on the service instance. This property is used as a replacement to the legacy /etc/resolv.conf file in previous versions of Oracle Solaris, though the value is mirrored to that file for compatibility with applications that might be parsing it.

# svcprop -p config/nameserver dns/client
192.168.0.1

Now that we’ve seen how to query properties, let’s take a look at another command, svccfg, that we can use to set properties. svccfg provides a number of different ways to set properties: directly on the command line, through an interactive text-based interface, or through a text editor. Let’s keep with our svc:/network/dns/client example and see how easy it is to set the name server configuration.

# svccfg -s dns/client setprop config/nameserver = 10.0.0.1
# svccfg -s dns/client listprop config/nameserver
config/nameserver net_address 10.0.0.1

Changes made to an existing service in the respository typically do not take effect until the service instance has been refreshed.

# svcprop -p config/nameserver dns/client
192.168.0.1
# svcadm refresh dns/client:default
# svcprop -p config/nameserver dns/client
10.0.0.1

Equally, we could have used the interactive interface to make these changes. Let’s change the value of config/nameserver back to what it was originally, 192.168.0.1, as shown in Listing 9.

# svccfg
svc:> select dns/client
svc:/network/dns/client> listprop config/nameserver
config/nameserver net_address 10.0.0.1
svc:/network/dns/client> describe config/nameserver
config/nameserver net_address 10.0.0.1
The value used to construct the “nameserver” directive in resolv.conf(4)
svc:/network/dns/client> setprop config/nameserver = 192.168.0.1
svc:/network/dns/client> listprop config/nameserver
config/nameserver net_address 192.168.0.1
svc:/network/dns/client> select default
svc:/network/dns/client:default> refresh
svc:/network/dns/client:default> exit

Listing 9. Using the Interactive Interface

svccfg supports a number of other useful commands, such as listpg to list property groups on a given service, editprop to open up a text editor to more easily allow configuration of multiple properties at the same time, and extract to allow administrators to easily capture service customizations as an XML file that can be applied on other systems. We will cover more of these in another article.
Monitoring the State of Services

One of the new features added to SMF in Oracle Solaris 11 is the ability to monitor the state of services and get notified if they change, either through e-mail or SNMP traps. Notifications can be quickly set to check if any SMF services go into maintenance mode or if a particular service goes online, for example. As a quick example, let’s set an e-mail notification to be sent anytime an SMF service goes into maintenance mode, as shown in Listing 10.

# svccfg setnotify -g maintenance mailto:admin@mycompany.com
# svccfg listnotify -g
Event: to-maintenance (source: svc:/system/svc/global:default)
Notification Type: smtp
Active: true
to: admin@mycompany.com

Event: from-maintenance (source: svc:/system/svc/global:default)
Notification Type: smtp
Active: true
to: admin@mycompany.com

Listing 10. Example of Setting a Notification

By default, SMF will use an existing simple e-mail template to fill in the values of any SMF service that has gone into or out of the maintenance state; however, this can be modified easily by setting a parameter, msg_template, in the mailto: address, as follows:

# svccfg setnotify -g maintenance “‘mailto:admin@mycompany.com?msg_template=/usr/local/share/new-smf-email-template'”

We can also monitor individual services. In this case, let’s monitor the svc:/network/http:apache22 Apache Web server default instance for any changes away from its current online state:

# svcs http:apache22
STATE          STIME    FMRI
online         Jun_14   svc:/network/http:apache22
# svccfg -s http:apache22 setnotify from-online mailto:admin@mycompany.com
# svccfg -s http:apache22 listnotify
Event: from-online (source: svc:/network/http:apache22)
Notification Type: smtp
Active: true
to: admin@mycompany.com

Troubleshooting

Now that we have covered some of the basics of administration with SMF, let’s quickly take a look at some of the things we can do to troubleshoot what might be wrong with a service. To quickly get an idea of what services are not running due to errors, we can use the -xv options to svcs, as shown in Listing 11.

# svcs -xv
svc:/system/identity:node (system identity (nodename))
State: disabled since June 22, 2012 08:11:14 PM NZST
Reason: Disabled by an administrator.
See: http://sun.com/msg/SMF-8000-05
See: man -M /usr/share/man -s 4 nodename
See: /var/svc/log/system-identity:node.log
Impact: 5 dependent services are not running:
svc:/network/rpc/bind:default
svc:/network/rpc/gss:default
svc:/system/filesystem/autofs:default
svc:/network/rpc/smserver:default
svc:/network/nfs/mapid:default

Listing 11. Determining Which Services Have Errros

In this case, we have a simple problem: svc:/system/identity:node has been disabled causing five dependent services to not run. Enabling it fixes the problem.

Another reason for failure might be a missing configuration file, as in this example with svc:/application/management/net-snmp:default:

# svcs -xv
svc:/application/management/net-snmp:default (net-snmp SNMP daemon)
State: offline since June 22, 2012 08:17:28 PM NZST
Reason: Dependency file://localhost/etc/net-snmp/snmp/snmpd.conf is absent.
See: http://sun.com/msg/SMF-8000-E2
See: man -M /usr/share/man/ -s 8 snmpd
See: /var/svc/log/application-management-net-snmp:default.log
Impact: This service is not running.

Once we have fixed the problem (by ensuring that the snmpd.conf file exists), we need to restart the service.

Another failure might be due to an incorrect configuration file or missing executables, as it the case here with svc:/network/http:apache22:

# svcs -xv
svc:/network/http:apache22 (Apache 2.2 HTTP server)
State: maintenance since June 22, 2012 08:23:35 PM NZST
Reason: Method failed.
See: http://sun.com/msg/SMF-8000-8Q
See: man -M /usr/apache2/2.2/man -s 8 httpd
See: http://httpd.apache.org
See: /var/svc/log/network-http:apache22.log
Impact: This service is not running.

In this case, it’s not clear from a quick summary of the error what the fault is; however, it’s clear that the service is now in maintenance state requiring explicit administrative intervention. The next logical step is to look at the service log located at /var/svc/log/network-http:apache22.log, as shown in Listing 12, which soon reveals the problem.

# tail /var/svc/log/network-http\:apache22.log
[ Jun 22 20:22:34 Method “stop” exited with status 0. ]
[ Jun 22 20:22:34 Executing start method (“/lib/svc/method/http-apache22 start”). ]
Apache version is 2.2
[ Jun 22 20:22:35 Method “start” exited with status 0. ]
[ Jun 22 20:23:35 Stopping because service restarting. ]
[ Jun 22 20:23:35 Executing stop method (“/lib/svc/method/http-apache22 stop”). ]
Apache version is 2.2
/usr/apache2/2.2/bin/apachectl[86]: /usr/apache2/2.2/bin/httpd: not found
[No such file or directory]
Server failed to start. Check the error log (defaults to
/var/apache2/2.2/logs/error_log) for more information, if any.
[ Jun 22 20:23:35 Method “stop” exited with status 95. ]

Listing 12. Checking the Service Log

We can easily see that our system is missing the /usr/apache2/2.2/bin/httpd executable file. This can be fixed easily by restoring the missing file using the IPS package manager with a pkg fix apache-22 command. Once we have identified and fixed the problem, we need to clear the state of the SMF service:

# svcadm clear http:apache22
# svcs http:apache22
STATE          STIME    FMRI
online         20:34:04 svc:/network/http:apache22

March 30th, 2014 | Category: Solaris | Leave a comment

Shrink root partition using LVM

While I installed my OS long back, I had partitioned more space in the root file system, because of which I was unable to use other file systems due to lack of disk space.
So, incase if few are facing the same issues, here is the tutorial to decrease your space in root partition.
Once your volume group(VG) gets free space, you can extend any where in your logical volumes(LV) which resides in the same volume group(VG)
Change Plan:
1. find the current disk usage in the file system.
2. Since your root partition(mounted) needs to be re-sized,  need access to unmounted root volume get into the rescue environment.
3. Change to logical volume manager in rescue environment.
4. Shrink the root file system
5. Reduce root volume.
6. Reboot system and bring it online.
7. Check the root disk after re-sizing.
Technical Implementation:
 
1. Current disk usage:
tux# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      6.7G  2.0G  4.5G  31% /
/dev/sda1              99M   12M   83M  13% /boot
tmpfs                 379M     0  379M   0% /dev/shm
2. Reboot the system and boot system in rescue environment.
3. In rescue shell, change to LV Manager prompt.
#lvm vgchange -a y
The -a y argument sets the availability to “y” or yes. As there are no specified LVM volume groups, this command will make all LVM volumes found available to the rescue kernel.
Once the kernel is aware of all LVM volumes they will be automatically mapped as devices. These are usually located under /dev/VolGroup.
#ls /dev/VolGroup00/
LogVol00  LogVol01
#e2fsck -f /dev/VolGroup00/LogVol00
4. After the check, resize2fs can be used to shrink the file system on the LVM volume. Here I reduce the root volume to 1GB
#resize2fs -f /dev/VolGroup00/LogVol00 1G
The e2fsck check command could be run again to make sure the, now significantly smaller, root file system is OK.
5. Reduce the root volume.
#lvm lvreduce -L 1G /dev/VolGroup00/LogVol00
The lvreduce command reduces the size of LVM volumes. The -L option allows the new size to be explicitly given. If the option to this argument does not begin with a minus sign, it is taken as the size to reduce the volume.
6. Remove CD/DVD and reboot the system to bring it online.
#reboot
7. Check root partition after reboot.
tux# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      5.9G  2.0G  3.7G  35% /
/dev/sda1              99M   12M   83M  13% /boot
tmpfs                 379M     0  379M   0% /dev/shm
Root partition was shrinked successfully.
March 29th, 2014 | Category: Centos | Leave a comment

Logical Volume Snapshots

Environment: CentOS release 6.3 (32-bit).
Descriptions:
By LV snapshot you will be able to freeze your logical volumes. In other words, you can easily backup and rollback to a original logical volume state. This is almost similar to VMware where you can the snap shot of the VM and revert in-case if anything goes wrong.
Concept of snapshot are just like the symbolic links, where you don’t create a file, instead you only reference to it. Here, two essential parts are
1. Metadata.
2. Data blocks.
When a snapshot is created Logical Volume Manager simply creates a copy of all Metadata pointers to a separate logical volume, snapshot volume only starts grow once you start altering data of the original logical volume.
Implementation:
Since my server was not created using LVM, I have created two partitions and changed them to LVM.
Change plan:
1. Create two partitions on /dev/sda drive.
2. Create physical volumes on the two drives.
3. Create volume group.
4. Create a single logical volume using ext3 file system.
5. Take snapshot and remove data
6. Rollback logical volume snapshot
Technical Implementation:
 
1. Created two physical partitions:
tux#fdisk -l | tail -2
/dev/sda5            2305        2366      497983+  8e  Linux LVM
/dev/sda6            2367        2428      497983+  8e  Linux LVM
tux#
2. Created Physical Volumes:
tux#pvcreate /dev/sda[5-6]
  Physical volume “/dev/sda5” successfully created
  Physical volume “/dev/sda6” successfully created
tux#
3. Created volume groups:
tux#vgcreate vol_grp /dev/sda5 /dev/sda6
  /dev/hdc: open failed: No medium found
  Volume group “vol_grp” successfully created
tux#
4. Created single logical volume of 100Mb with ext3 file system.
tux#lvcreate -L 100M -n lv1 vol_grp
  Logical volume “lv1” created
tux#
tux#mkfs.ext3 /dev/vol_grp/lv1
mke2fs 1.39 (29-May-2006)
.
.
tux#
Finally, we have come to the point where we can take a snapshot of our logical volume, for this we will also need some sample data on our Logical Volume, so once we revert from the snapshot we can confirm entire process by comparing original data with data recovered from the snapshot.
Create a mount directory for the logical volume and mount it.
tux#mkdir /mnt/lv1
tux#mount /dev/vol_grp/lv1 /mnt/lv1
tux#
tux:/mnt/lv1#cp -r /sbin/ .
tux:/mnt/lv1#cp -r /bin/ .
tux:/mnt/lv1#du -s .
39312   .
tux:/mnt/lv1#
5. Creating the LV snapshot.
tux:/mnt/lv1]#lvcreate -s -L 30M -n lv1_snapshot /dev/vol_grp/lv1
  Rounding up size to full physical extent 32.00 MB
  Logical volume “lv1_snapshot” created
tux:/mnt/lv1]#
Execute lvs to confirm that new volume snapshot has been created.
tux:/mnt/lv1]#lvs
  LV           VG      Attr   LSize   Origin Snap%  Move Log Copy%
  lv1          vol_grp owi-ao 100.00M
  lv1_snapshot vol_grp swi-a-  32.00M lv1      0.07
tux:/mnt/lv1]#
Since the snapshot was already created, now you can alter the data on the volume group.
tux:/mnt/lv1]#rm -rf ./bin/
tux:/mnt/lv1]#rm -rf ./sbin/
tux:/mnt/lv1]#du -s .
13      .
tux:/mnt/lv1]#
6. Rollback logical volume snapshot.
tux:/mnt/lv1]# lvconvert –merge /dev/vol_grp/lv1_snapshot
  Can’t merge over open origin volume
  Merging of snapshot lv1_snapshot will start next activation.
tux:/mnt/lv1]#
tux#umount /mnt/lv1
Deactivate and activate you volume:
tux# lvchange -a n /dev/vol_grp/lv1
tux# lvchange -a y /dev/vol_grp/lv1
As a last step mount again your logical volume “lv1” and confirm that data all has been recovered:
tux# mount /dev/vol_grp/lv1 /mnt/lv1
tux:/mnt/lv1]# ls
bin  lost+found  sbin
tux:/mnt/lv1]#
tux# du -s /mnt/lv1/
39312   .

 

March 29th, 2014 | Category: Centos | Leave a comment
« Newer Entries  
  Older Entries »