Quick check for directory size using du

The utilities du has a few parameter which could affect timing of checking directory size. But the difference is not that large 


Using du -csh on the current directory 

time du -csh .
544G

real    0m20.485s
user    0m0.308s
sys     0m2.146s

Using du -cmshis rather fast

$ time du -cmsh
544G

real    0m17.306s
user    0m0.266s
sys     0m1.951s

Using du -sh is the longest

$ time du -sh .
544G    .

real    0m21.790s
user    0m0.312s
sys     0m2.289s

The Machine that blur and even dissolve the difference between the disk and memory

This article is taken from HP Labs’ “Machine” dissolves the difference between disk and memory

.....“The Machine,” an experimental piece of computing hardware that HP executives hope will be the template upon which the future of networked computing is built. In an interview with Ars, Sontag explained how the core technologies of The Machine—memristor-based memory and low-cost silicon-to-optic interfaces—will change the shape of computing.

The Machine is a hyper-dense collection of computing hardware that could be used in anything from a data center to a mobile device. It has terabytes of storage and a much smaller power draw than today’s computing devices—all because of memristor-based memory and optical interconnects.

Do read the article  HP Labs’ “Machine” dissolves the difference between disk and memory

checkjob showq job is deferred. 'Execution server rejected request MSG=cannot send job to mom, state=PRERUN')

I'm using Torque 4.2.6 and MAUI 3.3.1

When I submitted a job, the job landed with a Deferred command

job is deferred.  Reason:  RMFailure  (cannot start job - RM failure, rc: 15043, 
msg: 'Execution server rejected request MSG=cannot send job to mom, state=PRERUN')

You can do a tail -f /var/log/messages or /var/spool/torque/server_logs

LOG_ERROR::No route to host (113) in send_job_work, send_job failed to host 
comp-node-1, c0a832a7 port 15002

This gave a hint. I checked my iptables and I realised that the iptables was on and I shut accordingly and the issue was cleared.

For more information:

1. Troubleshooting deferred jobs, episode 80

An observation - MAUI MAXPROC initally not working on Torque 2.5

I reinstalled Torque 2.5 and MAUI. After going through the setup as found in Installing Torque 2.5 on CentOS 6. But instead of using the xcat scripts, I used the scripts found in contrib folder to do the installation

I also installed MAUi based on MAUI Installation on Torque and xCAT

After setting up the configuration, and testing with sample qsub

$ echo "sleep 30" |qsub -l nodes=2:ppn8 

. The MAXPROC limits in MAUI does not seems to work.

The solution  I found later on is that I made a mistake of starting service pbs_shed start before service pbs_server start which cause the MAXPROC in MAUI to stop functioning. When I started service pbs_server only, the MAXPROC in Maui works. strange....

Bad UID for job execution MSG=ruserok failed validating user1 from ServerNode while configuring Submission Node in Torque

Supposed you have the error when you are testing your submission node for torque. Firstly do take a look at the blog on Configuring Torque Submission Node

I'm using Torque 2.5.3 and MAUI 3.3.1

$ echo "sleep 30" | qsub -I
qsub: Bad UID for job execution MSG=ruserok failed validating ..... from server server1

The Error could be coming from 2 possible misconfigurations

Step 1: Do check that your Torque Server Configuration has the followings. You can check by doing

# qmgr -c "p s".
.....
.....
set server submit_hosts = submission_node
set server allow_node_submit = True 
.....
.....

If not you can add it in very quickly

# qmgr -c 'set server submit_hosts = submission_node'

# qmgr -c 'set server allow_node_submit = True'

Step 2: Start the PBS services in sequence.
From my observation, we do not need to start the pbs_sched just the pbs_server only

# service pbs_server start

Step 3: Finally make sure in the Primary Submission host, you configure to allow traffic from /etc/hosts.equiv

# vim /etc/hosts.equiv

# dns_name_of_secondary_hosts

Resolution for ERROR: torque.setup: line 45: pbs_server: command not found

# ./torque.setup root
initializing TORQUE (admin: root@headnode.com)
./torque.setup: line 45: pbs_server: command not found
ERROR: pbs_server failed to start, check syslog and server logs for more information

Resolution is very simple for this. Th reason for the error as indicated above is that the torque.setup was not able to find the path for pbs_server. Just do the following

# touch /etc/profile.d/torque.sh
vim /etc/profile.d/torque.sh
export PATH=$PATH:/opt/torque/x86_64/bin:/opt/torque/x86_64/sbin

# source /etc/profile.d/torque.sh 

Try ./torque.setup root again. It should work

Red Hat Enterprise Linux 7 is now available

Do read Red Hat Website Announcing the General Availability of Red Hat Enterprise Linux 7!

Key Red Hat Enterprise Linux 7 features include:

• Lightweight, portable Docker containers run applications at near bare-metal speed providing isolation and leveraging SELinux for increased security.
  
• Improved filesystem enhancements including a default XFS filesystem that supports up to 500TB, improvements to NFS 4 adding extended attributes with SELinux labels, and LVM supporting whole volume snapshots with rollback.
  
• Improved interoprability with Microsoft Active Directory domains, allowing Red Hat Enterprise Linux clients to integrate more easily within heterogeneous datacenters.
  
• Centralized management of processes, services, security, and other resources using systemd allowing enhanced, granular control of your system.
  
• Performance tool utilities such as TUNA, Thermostat, and Performance Co-Pilot to allow you to monitor, measure, and resolve application problems.
  
• New management tools like OpenLMI help to create uniformity and standardized administration across systems by managing storage, network, and high-availability resources.
  
• Refined control over system subscriptions allows you to set support priority, audit systems reliably, and see how you're using your subscriptions at a glance.

For more information, do read

• Red Hat Enterprise Linux 7 is here: new improvements to downloads, product page, and doucmentation

Resolution for ERROR: cannot set TORQUE admins

Run the ./torque.setup root 

# ./torque.setup root
initializing TORQUE (admin: root@headnode.com)

You have selected to start pbs_server in create mode.
If the server database exists it will be overwritten.
do you wish to continue y/(n)?y
root     22809     1  0 11:57 ?        00:00:00 pbs_server -t create
Max open servers: 9
qmgr obj= svr=default: Bad ACL entry in host list MSG=First bad host: headnode.com
ERROR: cannot set TORQUE admins

Step 1: Configure the trqauthd daemon to start automatically at system boot for the PBS Server.
At $TORQUE_HOME

# cd $TORQUE_HOME
# cp contrib/init.d/trqauthd /etc/init.d/
# chkconfig --add trqauthd
# echo /usr/local/lib > /etc/ld.so.conf.d/torque.conf
# ldconfig
# service trqauthd start

Try the ./torque.setup root again. If there  is error like the above.

Step 2: Look at your host file. Make sure hostname of the server is the same as the first name with the corresponding IP Addresses

For example at /etc/hosts

# 192.168.1.1 headnode.com headnode
..... 
.....

At /etc/sysconfig/network

HOSTNAME=headnode.com
.....
.....

Step 3: Try the ./torque.setup root again.It should be successful

 ./torque.setup root
initializing TORQUE (admin: root@headnode.com)

You have selected to start pbs_server in create mode.
If the server database exists it will be overwritten.
do you wish to continue y/(n)?y
root     22843     1  0 12:00 ?        00:00:00 pbs_server -t create
Max open servers: 9
Max open servers: 9

RedHat Alert: OpenSSL CCS Injection Vulnerability (CVE-2014-0224) Alert

Taken from OpenSSL CCS Injection Vulnerability (CVE-2014-0224) Alert which came out yesterday.

Red Hat was recently notified of a vulnerability affecting all versions of OpenSSL shipped with Red Hat products. CVE-2014-0224 could allow for a man-in-the-middle attack against an encrypted connection.
SSL/TLS connections typically allow for encrypted traffic to pass between two parties where only the intended senders and recipients can decrypt data. In the event of a man-in-the-middle attack, an attacker could intercept an encrypted data stream allowing them to decrypt, view and then manipulate said data.
The vulnerability can only be exploited if both server and client are vulnerable to this issue. In the event that one of the two is vulnerable, there is no risk of exploitation.

NOTE: This vulnerability cannot be used to extract server or client side key material. This means that existing signed certificates do not need replacement once software is updated.

How does this impact systems

This issue affects products using OpenSSL in one of two scenarios:

OpenSSL version 1.0.1 and higher

Products Affected:
Red Hat Enterprise Linux 6.5, Red Hat Storage 2.1, Red Hat Enterprise Virtualization
All users running OpenSSL 1.0.1 and higher are impacted. It is recommended that all users of this version update to the latest release in order to remediate this vulnerability.

OpenSSL below 1.0.1

Products Affected:
Red Hat Enterprise Linux 6.4 and earlier, Red Hat Enterprise Linux 5, Red Hat Enterprise Linux 4, Red Hat JBoss Middleware
The vulnerability only affects the OpenSSL clients. Servers running OpenSSL versions below 1.0.1 are not vulnerable to this issue. Clients using OpenSSL versions below 1.0.1 connecting to servers running OpenSSL versions 1.0.1 and higher are vulnerable and should be updated.

Frequently Asked Questions

This FAQ is for the vulnerability CVE-2014-0224 in OpenSSL, also known as "CCS Injection"

Is this issue the same as HeartBleed?

No, this a new issue discovered in OpenSSL that could result in a man-in-the-middle attack. See the explanation above for full details

Is this issue worse than HeartBleed?

HeartBleed allowed anyone on the internet to exploit vulnerable servers. This issue requires an attacker to intercept and alter network traffic in real time in order to exploit the flaw. This reduces the risk that this vulnerability can be exploited but does not make it impossible, updating should be a primary remediation focus regardless of the difficulty in leveraging the exploit.

Do I need to regenerate any certificates?

No, this issue does not result in certificate or private key information leaking.

How can I tell if I'm vulnerable to this issue? Is it possible to test remotely for the presence of this issue?

All versions of OpenSSL are vulnerable to this issue. Review the relevant solution for your product:
Red Hat Enterprise Linux
Red Hat Enterprise Virtualization
Red Hat JBoss Middleware
Red Hat Storage
Red Hat Access Labs has released the CCS Injection Detector to you validate your systems have been patched against this vulnerability.

How can I verify the update is working properly?

You can use the Access Labs CCS Injection Detector to verify the update has been applied successfully.

Is there a way to mitigate this issue without an update?

There is no known mitigation for this issue. The only way to fix it is to install updated OpenSSL packages and restart affected services.

Does this issue affect other TLS libraries?

Red Hat has reviewed the NSS and GnuTLS libraries for this issue. We have determined that these libraries are not affected by this specific issue.

Do I need to update my OpenSSL package, even if I am not running version 1.0.1?

Red Hat suggests everyone updates their OpenSSL packages regardless of the version they are using. See above for further details

Is this issue being exploited in the wild?

At the time the issue was made public, we were not aware of any public exploits for this issue or that it is being exploited in the wild. We believe an exploit could be written for this issue, however exploitation requires the attacker to intercept and alter network traffic in real time.

When did Red Hat find out about this issue?

The OpenSSL team was notified about this issue on May 1, 2014, and contacted Red Hat and other OS distributions on June 2, 2014. This issue was made public on June 5, 2014.

What can an attacker actually do with this issue?

This issue could allow an attacker to conduct a man-in-the-middle attack against a vulnerable OpenSSL client communicating with a vulnerable OpenSSL server. The attacker could then potentially view or modify the secured traffic. The attacker would need a way to access network traffic between the communicating parties and alter it. This OpenSSL issue alone does not provide such level of access to network traffic.

Why do Red Hat's security advisories list multiple CVE IDs?

OpenSSL is fixing several issues with their latest update. Red Hat's updates fix the issues as relevant to our various versions of OpenSSL. This issue has been singled out as the most serious and we are providing additional information.

Converting Kilobytes to Gigabytes and vice versa

If you need to do a quick calculation from Kilobytes to Gigabytes and vice versa. Do take a look at
Kilobytes to Gigabytes Conversion Calculator