3/2/09

5 Simple Commands to Remove DB2 Cleanly

Before you install new version of DB2, if you need to remove the old version, please perform the following steps:

1. Log in as root.
2. List all DB2 instances:
bash# //instance/db2ilist

3. Drop each instance listed in the previous step with the following command:
bash# //instance/db2idrop instance-name

4. Drop the DB2 administration server:
bash# //instance/dasidrop `//instance/dasilist`

5. Uninstall all of the DB2 packages on your system using the db2deinstall command on your DB2 CD-ROM or from the unpackaged directory:
bash# /mnt/cdrom/db2/db2_deinstall -n

Actual example:

staff1@pw70:/opt/IBM/db2/V9.5/instance>./db2idrop db2inst1
DBI1070I Program db2idrop completed successfully.

staff1@pw70:/opt/IBM/db2/V9.5/instance>./db2idrop db2ins91
DBI1070I Program db2idrop completed successfully.

staff1@pw70:/opt/IBM/db2/V9.5/instance>daslist
dasusr

staff1@pw70:/opt/IBM/db2/V9.5/instance>dasdrop dasusr

SQL4410W The DB2 Administration Server is not active.
DBI1070I Program dasdrop completed successfully.

staff1@pw70:/data/software/db2v953a/server>./db2_deinstall -a

Enter full path name for the install directory -
------------------------------------------------
/opt/IBM/db2/V9.5
DBI1016I Program db2_deinstall is performing uninstallation. Please
wait.
The execution completed successfully.

.pw.

2/7/09

How to kill hanging Windows remote desktop connection

When you don't log off Windows Remote Desktop (or terminal service client), the connection becomes
orphaned. You may get the following screen:

Too many sessions prevents future logins. Do the following to clean up connections (on Windows 2003 server).
From a client machines CMD windows:

D:>query session /SERVER:myserver.myco.com
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
rdp-tcp#11 Administrator 1 Active rdpwd
rdp-tcp#4 Administrator 2 Active rdpwd

The above show 2 connections to “myserver”. You can kill the sessions with ID 1, 2, 3, so on.

tsdiscon 1 /SERVER:myserver.myco.com

where 1 rdp-tcp#11 Administrator 1 Active rdpwd “ID” col
Also, can tskill to remotely stop a process.


Scheduling Linux Tasks

automation and scheduling:

The at command enables the simplest form of job scheduling. It runs a command or a series of commands once only at a specified time, and mails any output to the user. The jobs it runs are processed in the background. You use this syntax for the at command. In the syntax, you can specify the time in a number of different ways. For example, you can specify the time as 01:30 or as 1:30 am.

[root@host11 pwstaff]# at -m 01:30


You now want to schedule a series of commands that you’ve saved in a file named “system_maintenance” to run at 12:00 pm. To do this, you use the -f option to Specify the file in an at command.

[root@host11 pwstaff]# at -f system_maintenance 12:00

Suppose that it is the end of June and you want to schedule a job to run four weeks from today, without entering the exact date on which it must run. Which command do you enter before specifying the job that must run to do this?

at now + 4 weeks

Ordinary users use the crontab command to create or edit their crontab files. To use the crontab command, users must be listed in the file /etc/cron.allow. If that file doesn’t exist, the users must not be listed in /etc/cron.deny. If neither file exists, all users can use the crontab command unless some other configuration prevents this.

[root@samwise root]# crontab -l

no crontab for root

[root@samwise root]# crontab -e to create

An entry of 00 in the minute field, 20 in the hour field, and 1-5 in the day of week field specifies that a command must run at 8:00 pm every day, from Monday to Friday.

00 20 * * 1-5 sort/usr/sales


In order, the fields that make up the time pattern in a crontab file entry include minute, hour, day of month, month of year, and day of week. Examples:


0 22 * * 1-5 10:00 pm on weekdays
15 14 1 * * 2:15 pm on the first of every month
30 /2 * * * Half past the hour every two hours
30 19 * * 1 7:30 pm every Monday


The /etc/at.allow and /etc/at.deny files enable you to control which users can run the at command. When a user tries to run an at job, the at command checks to see if the /etc/at.allow file exists. If it does and the user is listed in the file, at schedules the job.


If the user is not listed in /etc/at.allow, they will not be able to schedule the job, irrespective of whether they are listed in the /etc/at.deny file.If the /etc/at.allow file does not exist, at checks the /etc/at.deny file. If the user’s name does not appear in this file, the job will be scheduled. If the /etc/at.allow file doesn’t exist and /etc/at.deny is empty, any user can run at jobs. Alternatively, if /etc/at.allow exists and is empty, or if neither file exists, no user except root can run at jobs.

In some Linux distributions, such as Red Hat 7, any user can run cron jobs if neither the /etc/cron.allow or /etc/cron.deny files exist. In other distributions, only root can run cron jobs if neither file exists.