How can I install the packages from the EPEL software repository?

There are repository rpm packages for RHEL5 and RHEL6. The repository package installs the repo details on your local system for yum or up2date to use. Then you can install packages with your usual method, and the EPEL repository is included.
For EL5:

su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm'  ...  su -c 'yum install foo'  

For EL6:

su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm'  ...  su -c 'yum install foo'  

http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F

Adding new Initscripts with Red Hat's chkconfig (init scripts) At Boot - autostart

Place the script in /etc/rc.d/init.d and run (as root)

chmod +x /etc/rc.d/init.d/oracle  

to make the script executable. If you are concerned about normal users seeing the script, you could try more restrictive file permissions, as long as the script is executable by root as a standalone script.

Notice the two comments lines in the script:

#chkconfig: 2345 80 05  #description: Oracle 8 Server  

These lines are needed by chkconfig to determine how to establish the initial runlevels to add the service as well as set the priority for the start-and-stop script execution order. These lines denote the script will start Oracle 8 server for the runlevels 2, 3, 4 and 5. In addition, the start priority will be set to 80 while the stop priority will be 05.

Now that the script is in place with the appropriate execute permissions and the required chkconfig comments are in place, we can add the initscript to the chkconfig configuration by typing, as root, chkconfig --add oracle.

Using chkconfig's query feature, we can verify our addition:

[root]# chkconfig --list | grep oracle

 

NFS Server setup on LINUX and Mounting NFS on another server

http://tldp.org/HOWTO/NFS-HOWTO/server.html
http://www.cyberciti.biz/tips/ubuntu-linux-nfs-client-configuration-to-mount-nfs-share.html
http://nfs.sourceforge.net/

Troubleshoot at packet level using the following command
#tcpdump -ieth0 -vv -nn -X host 10.9.1.1

1. Add entry to /etc/exports file (ON NFS SERVER01)
   
   
   # <NFSshare dir> <ip address to allow (optional parameters)>
   /archive 10.9.1.0/24(no_wdelay,rw,async)
   /archive/shareHL7 10.9.1.9(rw,sync) 10.9.1.11(rw,sync) 10.9.1.12(rw,sync) 10.9.1.0/24(ro,async) 10.9.1.8(rw,sync)
   
   
   
2. Test if the share is active on the server
   
   Client01:# showmount -e server01
   
   
3. On NFS Client01 (Open /etc/fstab file)
   
   # Server:/<dir>/ <mountpoint> <type> <optional parameters>
   NFSSERVER01:/archive/shareHL7 /archive nfs rw,hard,bg,tcp,nfsvers=3,rsize=32768,wsize=32768 0 0
   
   
   
4. Allow hosts access TCP (/etc/hosts.allow)
   Add following line
   
   portmap: 10.9.1.8 , 10.9.1.9 , 10.9.1.11 , 10.9.1.12
   
   
   
   
5. Re-read exports file
   You should run the command exportfs -ra to force nfsd to re-read the /etc/exports file
   

ISSUES: mount to NFS Server failed: RPC Error: Program/version mismatch (retrying).

Test your nfs version by typing
#man nfs
#yum --version nfs
#rpm -qa | grep -i nfs

List all the readily available versions
#rpcinfo -u localhost nfs

• NFS Versions 2, 3, and 4 are supported on 2.6 and later kernels.
• NFS over UDP and TCP on IPv4 are supported on the latest 2.4 and 2.6 kernels.

Rebuilding RPMDB (RPM Database) - open rpm file handles

Following with the output, there has been a process being initiated by cron.daily since may 9th and not finishing the execution. The files in SOSREPORT help troubleshoot the issue if you are troubleshooting remotely. [root@BUTWIS01 ~]# ps -ef|grep rpm root 1225 6420 0 Jul12 ? 00:00:00 /bin/sh /etc/cron.daily/rpm root 1233 1225 0 Jul12 ? 00:00:00 /usr/lib/rpm/rpmq -q --all --qf %{name}-%{version}-%{release}.%{arch}.rpm\n root 1353 6255 0 Jun05 ? 00:00:00 /bin/sh /etc/cron.daily/rpm root 1359 1353 0 Jun05 ? 00:00:00 /usr/lib/rpm/rpmq -q --all --qf %{name}-%{version}-%{release}.%{arch}.rpm\n root 1997 6451 0 May21 ? 00:00:00 /bin/sh /etc/cron.daily/rpm root 2000 1997 0 May21 ? 00:00:00 /usr/lib/rpm/rpmq -q --all --qf %{name}-%{version}-%{release}.%{arch}.rpm\n

......

......

The problem appears to have begun on certain date (lets say May 9th); that's the earliest log entry, and /var/log/rpmpkgs is a 0-byte file created on May 10. Unfortunately, we do not seem to have logs stretching back nearly that far on the server, so determining what happened may not be possible. Does the server itself have any 'messages' files in /var/log other than messages and messages.1?

One thing we can see is that each of the temporary files created by the cron job still have open file handles: sort 1360 0 1 unknown /var/log/rpmpkgs.bvNeC1355 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable)

sort 2001 0 1 unknown /var/log/rpmpkgs.AqCXY1999 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 2145 0 1 unknown /var/log/rpmpkgs.CMQBk2143 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 2580 0 1 unknown /var/log/rpmpkgs.unPLs2578 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 3485 0 1 unknown /var/log/rpmpkgs.LbxJe3483 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 4017 0 1 unknown /var/log/rpmpkgs.AiNLk4009 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 6523 0 1 unknown /var/log/rpmpkgs.BEVAC6518 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 6584 0 1 unknown /var/log/rpmpkgs.NfVjU6582 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable) sort 7071 0 1 unknown /var/log/rpmpkgs.blYnX7062 lstat: Resource temporarily unavailable) (stat: Resource temporarily unavailable)

ls -hl /var/log

The fact that all the files still exist in /var/log/messges* suggests this isn't an issue with your storage or filesystem. Unfortunately, the logs still don't go back far enough to tell us what might have happened. The next thing I like to do is collect some data about what the stuck processes are doing. To that end, please run: strace -Tttfvo /tmp/strace.out -p15223 Let that run for 15 seconds or so, then press Ctrl+C and send us /tmp/strace.out.

The strace output shows that rpm process is currently stalled in a futex wait: 15223 14:48:53.284527 futex(0x2ae242d4a6cc, FUTEX_WAIT, 1, NULL <unfinished ...> This usually indicates a problem within rpmdb so perform following steps to rebuild rpmdb. 1, capture current status. # cd /var/lib/rpm # /usr/lib/rpm/rpmdb_stat -CA > /tmp/rpmdb.out 2, Kill the rpm processes by running "killall -9 rpm" 3, back rpmdb then rebuild. # mv /var/lib/rpm/__db.* /tmp # rpm --rebuilddb Running "rpm -qa" or "yum checl-update" should confirm if the rpmdb is back in working state. Read /tmp/rpmdb.out along with the result after you have run above for more insights.

How-To: Kill a Process Using the 'pidof' Command

If a process hangs and you want to easily kill it, type in a console:

kill -9 $(pidof process_name)

And replace process_name with a currently running process. For example, to kill rpm you would issue the following:

kill -9 $(pidof rpm)

Or awk, as another example:

kill -9 $(pidof awk)

Or

kill -9 $(pidof awk -1)

pidof is a command that finds the process ID (PID) of a given application. What is inside the ( and ) parenthesis is replaced with a certain PID, and the process which has that PID will be killed.

Disk Drive - C.P.U - performance measurement on Linux server

(For using tools like iostat, sar[cpu], mpstat[c.p.u usageINFO], nfsiostat[nfsShareStat], nfsstat[nfsShareStat], lpstat[cups-printerStats], vmstat[virtualMemStat])

You need sysstat installed
#yum install sysstat




CURRENT SERVER STATS
=================================
[root@sssl-prime ~]# hdparm -T /dev/sda1
/dev/sda1:
Timing cached reads: 9152 MB in 2.00 seconds = 4581.28 MB/sec

[root@ssssl-prime ~]# hdparm -t /dev/sda1
/dev/sda1:
Timing buffered disk reads: 100 MB in 3.03 seconds = 33.04 MB/sec

[root@ssssl-prime ~]# hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 112 MB in 3.04 seconds = 36.85 MB/sec

[root@ssssl-prime ~]# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 116 MB in 3.00 seconds = 38.62 MB/sec

[root@ssssl-prime ~]# hdparm -t /dev/sda3
/dev/sda3:
Timing buffered disk reads: 108 MB in 3.03 seconds = 35.64 MB/sec


[root@bu 5.8 ~]# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 26204 MB in 2.00 seconds = 13126.82 MB/sec
Timing buffered disk reads: 1312 MB in 3.00 seconds = 437.20 MB/sec

[root@bu 6.2 ~]# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 14174 MB in 2.00 seconds = 7095.22 MB/sec
Timing buffered disk reads: 912 MB in 3.00 seconds = 303.88 MB/sec

Juju works like a charm

Colplexity of having everything in cloud... Sys admins have to deal with it.

Genericize the product so it's more sellable. Download JUJU to have
abstraction and encapsulate things into a single nugget that devTips
guy can make configurations provisioned so people can use it Ina
generic way, they are called charms.. They were at 40 charms a year
back.

App flower is an open source company and it's software was not easy to deploy.

Juju gives users deployment options of auto deploying charms.

Juju is a cloud abstraction layer but at a different layer than ????


It's developed in python.

Juju.ubuntu.com
Cloud.ubuntu.com
Launch pad.net/juju

#juju on freenode

Clint Byrum. F.l@canonical.com
They are hire ing


He wrote a doc what u need to setup on a distro(Ubuntu) fedora
approaches them too for a porting

Strong code review process almost scurry


Pretty good for ongoing management. And that's the plan toile it
really good management tool. It's like fabric... Allows u to
orchastrate things now... Whereas with juju u have to encode what
needs to be orchastrates now and u make it available for later.

Juju is not for asking system what it's doing..

Fabric is more of a config mgmt tool ara lower level.

No transaction rollback for implementing the charms.

Charms have meta data what it talks to and how it talks to it.

Sent from my iPhone