Convert RSA SSL to a java keystore, the easy way.
Often times you will get the ---public key--- and --private key--- pairs from a certificate authority and need to convert them from RSA format to java keystores for Java.
Here's how to do it:
* You should put the keys into their appropriate .key (private) and .crt (public) files.
* Convert them into bundled pkcs12 format, use a export password.
openssl pkcs12 -export -in www.crt -inkey www.key -out bundle.p12
* Convert the pkcs12 key to a java keystore (.jks) file.
keytool -importkeystore -deststorepass EXPORT_PASSWORD -destkeystore www.jks -srckeystore www.p12 -srcstoretype PKCS12 -alias 1
You will get www.jks as a result, which is a usable java keystore. The alias of 1 is required to choose the certificate in the source PKCS12 file, keytool isn't clever enough to figure out which certificate you want in a store containing one certificate. (Source: http://cunning.sharp.fm/2008/06/importing_private_keys_into_a.html )
If you need to import an intermediate cert, you can do something like:
keytool -import -trustcacerts -file /path/to/ca/ca.pem -alias CA_ALIAS -keystore $JAVA_HOME/jre/lib/security/cacerts
If you need to import and intermediate cert, you can do something like:
openssl pkcs12 -export -chain -CAfile gd_bundle.crt -in (name of your certificate) -inkey (name of your certificate private key file) -out keystore.tomcat -name tomcat -passout pass:changeit
Then follow the steps above.
HINTS:
To view an x509 cert: openssl x509 -in mycert.crt -text
Check a private key: openssl rsa -in privateKey.key -check
To check a CSR: openssl req -text -noout -verify -in CSR.csr
Check a certificate: openssl x509 -in certificate.crt -text -noout
( More: http://www.sslshopper.com/article-most-common-openssl-commands.html)
To view a keystore: keytool -list -v -keystore keystore.jks
----------------------
Dealing with intermediates and linking those in your keystore:
If you need to install intermediates, you have to concatenate a ton of certs along with your intermediates into one cert file, and then build the keystore that way.
cat SSL123_PrimaryCA.pem /etc/ssl/certs/ca-certificates.crt SSL123_SecondaryCA.pem > allcacerts.crt
Basically cat all your intermediates along with the openSSL certs into one file. If you don't include /etc/ssl/certs/ca-certificates.crt in your catenation then you may get errors like "Error unable to get issuer certificate getting chain" later down.
Then you need to build your PKCS12 version of the cert by running:
openssl pkcs12 -export -chain -CAfile allcacerts.crt -in customercert.cer -inkey customercert.key -out customercert.pkcs -name tomcat -passout pass:changeit
Then convert this thing into a real java keystore:
keytool -importkeystore -deststorepass changeit -destkeystore YOUR-NEW-KEYSTORE.keystore -srckeystore customercert.pkcs -srcstoretype PKCS12 -alias tomcat
Then see if it worked:
keytool -list -v -keystore YOUR-NEW-KEYSTORE.keystore
References to input a chained cert into a keystore:
http://oldbytes.posterous.com/create-a-ssl-keystore-for-a-tomcat-server-usi
Count IP Addresses in Access Log File: BASH One-Liner
Recently our network was overloaded and our systems were being brought down by the amount of traffic.
When I first noticed the server slowing down, I checked the access.log files.
One quick way to see which IP addresses are most active is to sort by them:
cat access.log |cut -d ' ' -f 1 |sort
The cut command there simply throws away all the output except for the first field on each line, which is the IP address. Then we sort them. We can then scroll up through the terminal window and get a quick-and-dirty visual indication of which IP is most prevalent.
But in my case, I had quite a few IPs with several hundred hits, and that’s not enough to cause a problem. I needed to see which ones were in the thousands, but scrolling up through the terminal output it’s not especially easy to see the difference between say 500 lines and 1000 lines.
I needed an actual count of the number of times each IP address appeared the access log. I came up with the following BASH one-liner to do it (split onto multiple lines here only for readability):
FILE=/path/to/access.log;
for ip in `cat $FILE |cut -d ' ' -f 1 |sort |uniq`;
do { COUNT=`grep ^$ip $FILE |wc -l`;
if [[ "$COUNT" -gt "500" ]]; then echo "$COUNT: $ip";
fi }; done
First it creates a for-loop based on the output of the uniq command, so each iteration of the loop is for a different unique IP from the log. It then greps the log for that IP and uses "wc -l" to count the lines in the output. Finally, if the count is greater than 500, it displays the count and the IP, like so:
6975: 124.115.3.33
5648: 124.115.5.169
1514: 66.219.73.236
1451: 74.204.11.20
UPDATE: even easier: the uniq command has a -c argument that does most of this work automatically. It counts the occurrences of each unique line. Then a quick sort -n and a tail shows the big ones.
cat /path/to/access.log |awk '{print $1}' |sort |uniq -c |sort -n |tail
Count lines per second in log file with BASH.
Today I had a business need to see how many java exceptions per second were coming out of my Tomcat servers. I wrote this script to pull the number of lines per second coming from catalina.out:
tail -f /var/log/tomcat5/catalina.out|perl -e 'while (<>) {$l++;if (time > $e) {$e=time;print "$l\n";$l=0}}
Once I had a baseline for that, I filtered by exceptions:
tail -f /var/log/tomcat5/catalina.out|grep -i 'exception'|perl -e 'while (<>) {$l++;if (time > $e) {$e=time;print "$l\n";$l=0}}'
This allowed me to watch in real time how many exceptions our Tomcat heads were printing per second, if greater than 0.
A few readers have also pointed out these one liners which may be of use:
tail -f /var/log/tomcat5/catalina.out | pv -l -i10 -r >/dev/null
tail -n0 -f /var/log/tomcat5/catalina.out>/tmp/tmp.log & sleep 10; kill $! ; wc -l /tmp/tmp.log
Do you really want to be a programmer?
You know (you’ve got to know!) that this is going to turn into an obsession, if you learn to program. You know this right?
First, you’ll completely forget to take the dogs out. It’ll be standing by the screen door, darting its head about, as your eyes devour the code, as your fingers slip sweet and elegant messages to the computer.
Thanks to your neglect, things will start to break. Your mounds of printed sheets of code will cover up your air vents. Your furnace will choke. The trash will pile-up: take-out boxes you hurriedly ordered in, junk mail you couldn’t care to dispose of, mold of last months dinner will grow on that plate next to your computer. Your own uncleanliness will pollute the air. Moss will infest the rafters, the water will clog, animals will let themselves in, trees will come up through the foundation.
But your computer will be well-cared for. And you, my dear beloved reader, will have nourished it with your knowledge. In the eons you will have spent with your machine, you will have become part-CPU. And it will have become part-flesh. Your arms will flow directly into its USB and serial port. Your eyes will accept the video directly from DVI-24 pin. Your lungs will sit just above the processor, cooling it.
And just as the room is ready to force itself shut upon you, just as all the overgrowth swallows you and your machine, you will finish your script. You and the machine together will run this latest Python script, the product of your obsession. And the script will fire up chainsaws to trim the trees, hearths to warm and regulate the house. Builder nanites will rush from your script, reconstructing your quarters, retiling, renovating, chroming, polishing, disinfecting. Mighty androids will force your crumbling house into firm, rigid architecture. Great pillars will rise, statues chiseled. You will have dominion over this palatial estate and over the encompassing mountains and islands of your stronghold.
Do you still want to be a programmer?
If so, pick your language:
Ruby
Python
BASH shell programming
How linux memory allocation works.
$ free -m
total used free shared buffers cached
Mem: 1504 1491 13 0 91 764
-/+ buffers/cache: 635 869
You run this, and my god! You've only got 13 megabytes of RAM. What happened to all of your ram?
Don't worry! It's still available!
You have 869 megabytes of free memory in your buffers, and 13 megabytes of virgin untouched memory allocations.
What's going on?
You see, Linux uses memory for applications (which if available is consdiered free) but it also uses it for other uses (which makes linux consider it "used" although it is available to any application which needs to address more memory!)
Linux typically uses RAM for disk caching, if your applications want more memory, it just takes back a chunk that the disk cache borrowed.
From the Linux System Administrators guide:
Reading from a disk is very slow compared to accessing (real) memory. In addition, it is common to read the same part of a disk several times during relatively short periods of time. For example, one might first read an e-mail message, then read the letter into an editor when replying to it, then make the mail program read it again when copying it to a folder. Or, consider how often the command ls might be run on a system with many users. By reading the information from disk only once and then keeping it in memory until no longer needed, one can speed up all but the first read. This is called disk buffering, and the memory used for the purpose is called the buffer cache.
Since memory is, unfortunately, a finite, nay, scarce resource, the buffer cache usually cannot be big enough (it can't hold all the data one ever wants to use). When the cache fills up, the data that has been unused for the longest time is discarded and the memory thus freed is used for the new data.
There's also some programs in C you can compile and run to prove the concept.
Why can’t bash run scripts suid?
I was approached by an associate today asking about why bash scripts can't be run as suid.
What is suid?
For those that don't know, setuid and setgid (short for set user ID upon execution and set group ID upon execution, respectively) are flags you sat set on a file that allow users to run an executable with the permissions of the executable's owner or group. The setuid bit was invented by Dennis Ritchie for UNIX. His employer, AT&T, applied for a patent in 1972; the patent was granted in 1979 as patent number US 4135240 "Protection of data file contents"
A practical use of setuid would be the /usr/bin/passwd command, as it requires nonprivileged-users to be able to run it, and it also requires access to the sensitive file /etc/shadow containing your password hash (and everyone elses) to update passwords. The permissions for the passwd program are 4755/-rwsr-xr-x which give it this capability. (Notice the 4 in front of the permission causing suid bit to be active.) This tells the system it is okay to run parts of the script as root level access (by invoking setuid( 0 ); in C ), even if invoked by a user.
SUID in bash
So SUID in bash isn't possible because the bash interpreter will forcibly drop suid if it detects the bit for security reasons. Second, bash will detect being run as setuid, and immediately drop the privileges. This is for security, as it would be too easy to compromise a system.
To exemplify the insecurity of a theoretical suid bash script, take this highly secure bash script with user level access.
#!/bin/sh if grep -q “^$(whoami)\$” /etc/privileged-users.txt then echo Youre in the access list! echo $1 >> /etc/hosts else echo “You don’t have permissions to add to /etc/hosts” fi
This allows users defined in /etc/privileged-users.txt to add a line to /etc/hosts.
Let's abuse SUID:
echo "shutdown -h now" > ~/bin/grep; chmod 755 ~/bin/grep PATH=~/bin addhost
~/bin/grep gets executed and the machine is now offline.
You could mitigate this by adding set PATH=/bin:/usr/bin to your script to re-set any malicious $PATH on startup, but then an attacker could do:
gcc -shared -o libdl.so.2 ROOTKIT.c LD_LIBRARY_PATH=. addhost
Then when grep tries to call its standard libc library, it instead links into our library and does something bad.
You could fix this by LD_LIBRARY_PATH=/lib/ but are you safe now?
No. We could rename the script.
ln /usr/bin/addhost ./-i
The symlink still has suid, is called "-i" and when running it bash will really run bash -i for interactive mode.
So in a 9 line script we went over several ways to gain root access when it looked like it was a pretty harmless script. Using sudo instead is highly advisable, and this is the reason why bash does not utilize suid.
When there's a will, there's a way!
To get around all of the safeguards built to protect your box from being rootkitted, create a program like this.
#include
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
setuid( 0 );
system( "/path/to/script.sh" );
return 0;
}
Then get it ready with
gcc runscript.c -o runscript chown root:root runscript chmod 4755 runscript
Now you can run your shell script with root permissions at your own risk. Yay!
Kernel 3.x 50% battery efficiency losses in kernel are tabloid claims.
Phoronix has yet another article proclaiming that the Linux Kernel has a "power regression" bug in it. They report 50% power loss due to this bug
First off, it's not a code regression issue. Redhat patched a bug related to how the kernel sets ASPM. The bug caused computers to crash when the BIOS reported ASPM wasn't supported, but was enabled in hardware (RHEL-681017). They fixed it by instructing ASPM to remain off if the BIOS reported it was unsupported; then leaving it on. This solved peoples stuff from crashing.
Further reading:
http://lwn.net/Articles/449448/
http://lwn.net/Articles/449648/
The problem where claims of 50% power losses come from is that it forcing ASPM to be off on systems that report it as unsupported causes a loss in power savings. A tradeoff to your system crashing on crap hardware.
This is where a tool like Jupiter or tuned comes in, these tools are designed to alter the state of the kernel to optimize the system for performance when plugged in, and battery life when unplugged. In the case of Jupiter, not only do I change multiple kernel parameters, but I also change the power state of (supported) devices to shift them to power savings mode.
For those that do see a small loss in battery life and are willing to risk stability for a few extra minutes unplugged, there is a workaround.
Set 'pcie_aspm=force' on the kernel command line of grub.conf, reboot, and move on with life.
To see if you have a bad BIOS, look at /sys/module/pcie_aspm/parameters/policy. If it says 'default', you probably unfortunately have a computer that is reporting that ASPM is unsupported.
If you have a laptop or netbook, and you want optimal battery life, install Jupiter or tuned.
Monitoring in Cacti without heavyweight SNMP services.
I found a really cool project out there called ServerStats which is a way to do monitoring in Cacti without having to have SNMP set up on all of your servers.
It's basically a tiny tool which runs under inetd on the servers to be monitored, and Cacti is set up to make a socket connection to this service.
Here's the output of the tool meant to be run under xinetd:
$ /usr/local/bin/serverstats loadavg-1:0.07 loadavg-5:0.06 loadavg-15:0.07 net-rx:26740961501 net-tx:46202108165 mem-memfree:39816 mem-buffers:8240 mem-cached:67044
Here's the source for the above program:
#include#include #include int cmp_token(char* b1, char* b2) { return strncasecmp(b1, b2, (int) strlen(b2)) == 0; } char* next_token(char* buffer, int first) { if (buffer) { if (!first) { while (*buffer && !(*buffer == ' ' || *buffer == '\t')) { buffer ++; } } while (*buffer) { if (*buffer != ' ' && *buffer != '\t') { return buffer; } buffer ++; } } return NULL; } char* skip_token(char* buffer, int count) { while (count-- > 0) { buffer = next_token(buffer, 0); } return buffer; } void print_loadavg(FILE* output) { double loadavg[3] = {0, 0, 0}; getloadavg(loadavg, 3); fprintf(output, "loadavg-1:%.2f ", loadavg[0]); fprintf(output, "loadavg-5:%.2f ", loadavg[1]); fprintf(output, "loadavg-15:%.2f ", loadavg[2]); } void print_meminfo(FILE* output) { FILE *fp; char buffer[256], *buffer2; char *memtext[] = {"memfree", "buffers", "cached", "swaptotal", "swapfree"}; unsigned int memvalue[] = {0, 0, 0, 0, 0}; int i; int found = 0; if (fp = fopen("/proc/user_beancounters", "r")) { // Check whether we are in an OpenVZ VPS. We will read the beancounter // instead of meminfo. while (fgets(buffer, 1023, fp)) { int held, barrier; buffer2 = next_token(buffer, 0); if (cmp_token(buffer2, "privvmpages")) { buffer2 = skip_token(buffer2, 1); sscanf(buffer2, "%i", &held); buffer2 = skip_token(buffer2, 2); sscanf(buffer2, "%i", &barrier); memvalue[0] = (barrier - held) * 4; found = 1; } else if (cmp_token(buffer2, "oomguarpages")) { buffer2 = skip_token(buffer2, 1); sscanf(buffer2, "%i", &held); memvalue[3] = held * 4; } else if (cmp_token(buffer2, "physpages")) { buffer2 = skip_token(buffer2, 1); sscanf(buffer2, "%i", &held); memvalue[4] = held * 4; } } fclose(fp); } if (!found && (fp = fopen("/proc/meminfo", "r"))) { while (fgets(buffer, 1023, fp)) { for (i = 0; i < sizeof(memtext) / sizeof(char*); i ++) { if (cmp_token(buffer, memtext[i])) { sscanf(next_token(buffer, 0), "%i", &memvalue[i]); break; } } } fclose(fp); } for (i = 0; i < 3; i ++) { fprintf(output, "mem-%s:%i ", memtext[i], memvalue[i]); } fprintf(output, "mem-swap:%i", memvalue[3] - memvalue[4]); } void print_net_dev(FILE* output) { FILE *fp; char buffer[256], *buffer2; unsigned long long rx, tx; unsigned long long totalrx = 0, totaltx = 0; if (fp = fopen("/proc/net/dev", "r")) { // Read the first two lines of junk fgets(buffer, 1023, fp); fgets(buffer, 1023, fp); while (fgets(buffer, 1023, fp)) { if (!(buffer2 = next_token(buffer, 1))) continue; // We do not wish to count the local network. if (cmp_token(buffer2, "lo:")) continue; if (!(buffer2 = strstr(buffer2, ":"))) continue; buffer2 = next_token(++ buffer2, 1); sscanf(buffer2, "%lli", &rx); if (!(buffer2 = skip_token(buffer2, 8))) continue; sscanf(buffer2, "%lli", &tx); totalrx += rx; totaltx += tx; } fclose(fp); } fprintf(output, "net-rx:%lli ", totalrx); fprintf(output, "net-tx:%lli ", totaltx); } int main(int argc, char **argv) { print_loadavg(stdout); print_net_dev(stdout); print_meminfo(stdout); fflush(stdout); }
Here's the xinetd script:
service serverstats
{
type = UNLISTED
socket_type = stream
wait = no
user = nobody
server = /usr/local/bin/serverstats
port = 9087
disable = yes
}
And finally the cacti template:
ServerStats Host hash_000013d1308663063663abd7798a1a75c2703b|hash_000013bbbc13d34b7446572dc8b7a117076f50|hash_000013fc68939b4d122d6cdd540337d8d3b67a ServerStats - Load Average 1 120 500 on 2 on on on 100 0 1000 0 processes in the run queue hash_080013a4ed56bc67e7908c26ce3a8f3737e85d EACC00 7 1 0 hash_060013e9c43831e54eca8069317a2ce8c6f751 1 Minute Average 1 hash_080013a4ed56bc67e7908c26ce3a8f3737e85d 0 9 4 0 hash_060013304a778405392f878a6db435afffc1e9 Current on 2 hash_0800132eefcf768b1aa530ed75796e62c28d73 EA8F00 4 1 0 hash_060013e9c43831e54eca8069317a2ce8c6f751 5 Minute Average 3 hash_0800132eefcf768b1aa530ed75796e62c28d73 0 9 4 0 hash_060013304a778405392f878a6db435afffc1e9 Current on 4 hash_080013c2573a1c2eb017235e13a1fbe7f1ec78 B1441E 5 1 0 hash_060013e9c43831e54eca8069317a2ce8c6f751 15 Minute Average 5 hash_080013c2573a1c2eb017235e13a1fbe7f1ec78 0 9 4 0 hash_060013304a778405392f878a6db435afffc1e9 Current on 6 Data Source [ss_loadavg_1] task_item_id hash_000013ec813fa43d7bf740a4189583220055b3|hash_000013a9e26867149f7df424d9fc1d6d7961cf Data Source [ss_loadavg_5] task_item_id hash_00001351a20328c26f4e382d9b5d147e775f24|hash_000013dbd451a344d3140d3375f3bba0327502 Data Source [ss_loadavg_15] task_item_id hash_000013033f173b7d995685ea495f45ed9d02dc|hash_000013920df6aa2c8b67b30212531faf62e3c5 ServerStats - Traffic (bits/sec) 1 120 500 on 2 on on on 100 0 1000 bits per second hash_08001347d9b20cde5d6eb247bf3f44bdb620b8 00CF00 7 1 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Inbound 1 hash_08001347d9b20cde5d6eb247bf3f44bdb620b8 0 9 4 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Current: 2 hash_08001347d9b20cde5d6eb247bf3f44bdb620b8 0 9 1 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Average: 3 hash_08001347d9b20cde5d6eb247bf3f44bdb620b8 0 9 3 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Maximum: on 4 hash_0800137a164527aee8a671d461bb3a12f73b43 002A97 4 1 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Outbound 5 hash_0800137a164527aee8a671d461bb3a12f73b43 0 9 4 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Current: 6 hash_0800137a164527aee8a671d461bb3a12f73b43 0 9 1 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Average: 7 hash_0800137a164527aee8a671d461bb3a12f73b43 0 9 3 hash_05001373f95f8b77b5508157d64047342c421e hash_060013e9c43831e54eca8069317a2ce8c6f751 Maximum: 8 Data Source [ss_net_rx] task_item_id hash_0000139b48b48fbb5530c966a0cfa428abe2c4|hash_00001315f29761dbf6e5c83e920c002f7f2827|hash_000013374066c96fd8084b2a3fba82f8a3ad65|hash_000013a0b34ad2a8f0f4758c677ae6d16bf9c3 Data Source [ss_net_tx] task_item_id hash_000013ffb93c383fe4a804995d4ef4db7a5fb7|hash_00001350e680c62bd5ba6e0c45aa979686afef|hash_00001375ebc84dd4acbd07d61c833c5c7d45e1|hash_00001358d6b84d110b67ae271860093fa03cee ServerStats - Memory Usage 1 120 500 on 2 on on on 100 0 1000 kB hash_080013d9c63fa34be7090c9e8c8dfac74be591 8F005C 7 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Memory Free 1 hash_080013d9c63fa34be7090c9e8c8dfac74be591 0 9 4 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Current: 2 hash_080013d9c63fa34be7090c9e8c8dfac74be591 0 9 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Average: 3 hash_080013d9c63fa34be7090c9e8c8dfac74be591 0 9 3 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Maximum: on 4 hash_080013e82c066110b32bbb433acebca21f8615 FF5700 8 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Memory Buffers 5 hash_080013e82c066110b32bbb433acebca21f8615 0 9 4 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Current: 6 hash_080013e82c066110b32bbb433acebca21f8615 0 9 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Average: 7 hash_080013e82c066110b32bbb433acebca21f8615 0 9 3 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Maximum: on 8 hash_080013723eb14e872bcf57126025f73c79d53a FFC73B 8 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Cache Memory 9 hash_080013723eb14e872bcf57126025f73c79d53a 0 9 4 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Current: 10 hash_080013723eb14e872bcf57126025f73c79d53a 0 9 1 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Average: 11 hash_080013723eb14e872bcf57126025f73c79d53a 0 9 3 hash_050013634a23af5e78af0964e8d33b1a4ed26b hash_060013e9c43831e54eca8069317a2ce8c6f751 Maximum: on 12 Data Source [ss_mem_cached] task_item_id hash_000013601841d332144f76f0b779ae11d7d348|hash_00001373e0c52741d75959bf76b9e4ae2f94b6|hash_000013668fb8f0ff525d9ec75dfa129f3c811e|hash_000013bd981c77bbfce0381230a011409275ef Data Source [ss_mem_buffers] task_item_id hash_000013a5011e6bbc896676ea5e67c15f1c2f2a|hash_00001365ac2fe5d1dbf25b74286a55305d0ad8|hash_000013213b4833d2aacc7d7f20895eea7cc2cd|hash_0000133ac789b78a2e763e2217429713ceb47e Data Source [ss_mem_memfree] task_item_id hash_000013196281cb3abf7968c607036795c94952|hash_000013e3b1f4c6c243032234e33fefb1757a9b|hash_000013334ad942a70f6cafb5b27e0a0bf35451|hash_000013a5bd9b7ad79c0e3b333488ec7a444cfa ServerStats Data |host_description| - ServerStats hash_030013cb8c634ddf6b0adc4524f7030178bc19 300 on hash_150013c21df5178e5c955013591239eb0afd46|hash_1500130d9c0af8b8acdc7807943937b3208e29|hash_1500136fc2d038fb42950138b0ce3e9874cc60|hash_150013e36f3adb9f152adfa5dc50fd2b23337e ss_loadavg_5 0 500 1 600 hash_070013ee030c840f31caa0e8910490429f515c ss_net_rx 0 100000000 2 600 hash_0700139b08ab8f35132d6180f32724734f1f2c ss_net_tx 0 100000000 2 600 hash_070013233d6292b435caa07865a3656ef5df90 ss_mem_cached 0 100000000 1 600 hash_0700139c08c83f5466b532ecc2674efe2e3f25 ss_mem_buffers 0 100000000 1 600 hash_070013e0533a9e01ad9b8e677719109f6f13e8 ss_loadavg_1 0 500 1 600 hash_070013f73f3f7a29daa9845c1c7ba67e5b9d37 ss_loadavg_15 0 500 1 600 hash_0700138b1fa23c8772d9cb9771edc97cc6f341 ss_mem_memfree 0 100000000 1 600 hash_0700132a5751d44df3cd33d283615f80f9b1f6 hash_070013113c452c62f008cbf8664e6bfb0b373b ServerStats Query 1 nc -w 5 <host> 9087 Hostname or IP Address hostname in host Load Average 1 Minute on out loadavg-1 Load Average 5 Minutes on out loadavg-5 Load Average 15 Minutes on out loadavg-15 Network Bytes Received on out net-rx Network Bytes Transmitted on out net-tx Memory Free on out mem-memfree Memory Buffers on out mem-buffers Memory Cached on out mem-cached Daily (5 Minute Average) 0.5 1 600 86400 1|3 Weekly (30 Minute Average) 0.5 6 700 604800 1|3 Monthly (2 Hour Average) 0.5 24 775 2678400 1|3 Yearly (1 Day Average) 0.5 288 797 33053184 1|3 Normal %8.2lf %s Load Average %8.2lf Turn Bytes into Bits 1 4 CURRENT_DATA_SOURCE 2 6 8 3 2 3 Multiply by 1024 1 4 CURRENT_DATA_SOURCE 2 6 1024 3 2 3