zondag 17 oktober 2010

Command to set Solaris PW expiration date...

These values can be set or modified from the command line by root, using the passwd command as follows;

# passwd -n 0 -w 14 -x 60 username
Where -n is the minimum number of days allowed between password changes, -w is the number of days befor the password expires and the user is warned, and -x is the maximum munber of days that the password will be valid for.

These values can ONLY be queried or changed by root.

When a user changes their password, only the encrypted password and current date are stored in /etc/shadow. The "number-of-days" values are not changed.
The expiration date, is calculated, not stored.

To remove the password expiration, symply type:

# passwd -x -1 username

disable login via serial port

/usr/sbin/pmadm -lPMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
zsmon ttymon ttya u root /dev/term/a I - /usr/bin/login - 9600 ldterm,ttcompat ttya login: - tvi925 y #
zsmon ttymon ttyb u root /dev/term/b I - /usr/bin/login - 9600 ldterm,ttcompat ttyb login: - tvi925 y #

  1. /usr/sbin/pmadm -d -p zsmon -s ttya
  2. /usr/sbin/pmadm -d -p zsmon -s ttyb

zaterdag 16 oktober 2010

bsmconv, bsmunconv – enable or disable Solaris Auditing

Synopsis
/etc/security/bsmconv [rootdir].../etc/security/bsmunconv [rootdir]...Description
The bsmconv and bsmunconv scripts are used to enable or disable the BSM features on a Solaris system. The optional argument rootdir is a list of one or more root directories of diskless clients that have already been configured. See smdiskless(1M).

To enable or disable BSM on a diskless client, a server, or a stand-alone system, logon as super-user to the system being converted and use the bsmconv or bsmunconv commands without any options.

To enable or disable BSM on a diskless client from that client's server, logon to the server as super-user and use bsmconv, specifying the root directory of each diskless client you wish to affect. For example, the command:



myhost# bsmconv /export/root/client1 /export/root/client2
enables BSM on the two machines named client1 and client2. While the command:



myhost# bsmconv
enables BSM only on the machine called myhost. It is no longer necessary to enable BSM on both the server and its diskless clients.

After running bsmconv the system can be configured by editing the files in /etc/security. Each diskless client has its own copy of configuration files in its root directory. You might want to edit these files before rebooting each client.

Following the completion of either script, the affected system(s) should be rebooted to allow the auditing subsystem to come up properly initialized.

Audit log rotation

add to crontab:

0 0 * * * /usr/sbin/audit -n
10 0 * * * find /var/audit/ -type f -mtime +7 -exec rm {} \; 2>/dev/null

How to restart a service

/lib/svc/method/sshd restart
or
svcadm restart sshd

vrijdag 15 oktober 2010

Handy bookmarks

SUN BigAdmin System Administrator Resource
http://www.sun.com/bigadmin/home/index.jsp

Generating Random Passwords
http://www.securepasswords.net/site/GenPronounceable.html

identify users of files and devices

HOST-root# fuser /var/opt/bsl/logs/*/*
/var/opt/bsl/logs/akamai/akamai.log: 28287o
/var/opt/bsl/logs/bslweb/bslweb.log: 28287o
/var/opt/bsl/logs/tomcat/catalina.out: 28287o

Process 28287 should be stopped

HOST-root# ps -efa | grep 28287
root 20158 19722 0 09:36:21 pts/1 0:00 grep 28287
tomcat 28287 1 0 Apr 17 ? 2:30 /opt/j2re1.4.2_13/bin/java -Djava.endorsed.dirs=/opt/apache-tomcat-4.1.36/commo

Size of folders

du -skh *

Check which patches are installed

showrev -p | grep <patchnumber>

Creating an SSH key pair with OpenSSH

Using the OpenSSH program suite, a 2048 bit RSA key pair can be created by

$ ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa
The output will be something similar to:

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_repos.
Your public key has been saved in id_rsa_repos.pub.
The key fingerprint is:
5d:0d:2b:c7:44:2c:6c:39:f6:09:9c:55:3e:5f:9b:bf xxx@yyy

The private key
The private key file (called id_rsa_repos in the example above) needs to be kept secret and well-protected by the user who uses it to identify herself. It is handy to store the corresponding public key along with the private key for easy access (e.g. when you have to provide it to a service provider).

Private key files are sensitive

It is recommended (though not strictly required) to protect the private key file with a passphrase. The important point to keep in mind is that whoever manages to get hold of the private key file will be able to access the service protected by the key (e.g. the subversion repository account) with your user privileges, if the private key file is not protected by a passphrase.

Additionally or alternatively the directory containing the private key file can be encrypted. All modern operating systems support transparent directory encryption. How to configure directory encryption depends on your operating system and is beyond the scope of this HOWTO. If unsure, ask your IT support group.


The public key
The public key file is the entity that is exchanged between the user and the service provider (e.g. the subversion administrator in the case where the service provided is access to a subversion repository). If generated via OpenSSH, it usually ends in .pub (see example above) and looks something like:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA2KZp+OEKJu4IYC81ydFG4P/tVYJondVrKIEznxonQ8EEhdlY
lhGLHrqcBB+il8lCWVsuHRakTEmuh3v3TAWkFlOhs1oRCkx+
Gc3sXl86H0hj5meCddVjVV+FeVLRtuCahh6H
6pt4USZtK/g+K3p5w5Pyao1B1ZESr1cdqIX30r2Nnj/fCJ54A9TuvNSwRsqISQ/PPmCT00oAHusBtKqU1f6Q
aD3CrtsejHYBYPiomOQRRcRdk0Jyrf/o5sgLs53zLdgw8dn7xuQ14YBQxY9+StqlSuTzyET9EB6CDHsoRbx/L5pXhId/LCrWYk7qsxRrc0xMmTQ7hDgQsy4qwoXtIw== xxx@yyy
Note that the first and second field must not be changed. Only the third field (xxx@yyy) can be changed deliberately, since it is a comment relevant only to the human reader, but irrelevant to the machine.

Fingerprints can help you identifying keys

If you are ever in doubt whether you have the right public key, call

$ ssh-keygen -l -f id_rsa_repos.pub
on the public key file (id_rsa_repos.pub in this example). The output will look something like:

2048 5d:0d:2b:c7:44:2c:6c:39:f6:09:9c:55:3e:5f:9b:bf id_rsa_repos.pub
The first field will show the length of the key (2048 bit in this case), the second field is the fingerprint of the key. The fingerprints of the two keys is what you should compare if you are unsure whether the two keys are the same.

Fingerprints can help you comparing keys

The same trick works on private RSA key files, too. Thus if you want to know whether a private and a public key match, type

$ ssh-keygen -l -f id_rsa_repos ; ssh-keygen -l -f id_rsa_repos.pub
and compare the output.



Public keys can be derived from private keys

If you have lost the public key file but still have the private key file, the public key can easily be reconstructed from the private key file by

$ ssh-keygen -y -f id_rsa_repos

Check userstatus in oracle db

su - oracle
sqlplus /nolog
connect / as sysdba

Get list of status for users:
select username, account_status from dba_users;
Locking up a user:
alter user system account lock;

get date in filename

`date "+%Y%m%d"`

Extended Attributes: how to handle them

To find files that contain exented attributed: find / -xattr -printTo list the attributes : runat <filename> ls -lTo remove the attribute : runat <filename> rm <attribute>
Script to remove all extended attributes:
  1. !/usr/bin/ksh
  2. removing xattributes
cd
for i in `find / -xattr -print`
do
runat $i rm
SUNWattr_ro SUNWattr_rw
done

grep multiple words

/usr/xpg4/bin/grep -E 'word1|word2:' filename.txt