get vmware esxi cpu info


~ # vmwarevim-cmd hostsvc/hosthardware | grep -A10 cpuPkg | grep description
   cpuPkg = (vim.host.CpuPackage) [
      (vim.host.CpuPackage) {
         dynamicType = , 
         index = 0, 
         vendor = "intel", 
         hz = 2833433579, 
         busHz = 333345127, 
         description = "Intel(R) Xeon(R) CPU           E5440  @ 2.83GHz", 
         threadId = (short) [
            0, 
            1, 

Here I get the info for 8 different machines to see if they all match:

for i in `seq 1 1 8`; do ssh vm30$i "vim-cmd hostsvc/hosthardware | grep -A10 cpuPkg | grep description"; done;

This works on 4.1 and 5.1 versions.

share:

bulk change default assignee in Redmine

If you have hundreds of Redmine projects, and someone has created them from other projects, chances are you will have a default assignee that doesn’t belong on all those projects. Login to the Redmine database and update the projects table accordingly.

mysql> select id,name,default_assignee_id from projects where default_assignee_id=6;
+----+---------------+---------------------+
| id | name          | default_assignee_id |
+----+---------------+---------------------+
| 14 | Project1      |                   6 |
| 55 | SomeProject2  |                   6 |
| 56 | Proj3         |                   6 |
(many rows omitted)
+----+---------------+---------------------+
57 rows in set (0.01 sec)

mysql> update projecst set default_assignee_id=NULL where default_assignee_id=6;
share:

copy partition table from one disk to another

When replacing a failed disk in a RAID 1 array, it’s necessary to get the new disk setup properly with an identical partition table matching the existing disk. In this case sda has failed and has been replaced with a spare. To copy the partition table from sdb to sda do this:

# sfdisk -d /dev/sdb | sfdisk /dev/sda --force

Make absolutely sure you know which disk is which, otherwise you will blow out the good partition table on the running disk, with whatever is on the spare (probably no partition table at all).

share:

From time to time you might encounter a failure message about SSH and host identification. SSH remembers the fingerprint of keys of other hosts it connects to. It stores these keys in a file, so that if the fingerprint changes you will hear about it. This can happen with some DHCP addresses. For example, HostA has a DHCP address of 192.168.1.102. You change HostA’s IP address, to a static address, and the lease for 192.168.1.102 expires. Then you bring up HostB and it gets the DHCP address of 192.168.1.102. When you go to ssh to 192.168.1.102, you get an error. That’s because SSH recognizes that it’s a different host altogether. This helps prevent in MIM attacks, or IP spoofing. In this case we know what’s going on, so it’s safe to remove the old fingerprint for HostA and reconnect to HostB subsequently storing it’s fingerprint.

# ssh 192.168.1.102
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
34:6e:16:28:90:21:bd:6a:80:e4:97:41:85:ef:4a:ad.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for 192.168.1.102 has changed and you have requested strict checking.
Host key verification failed.
#

One way to fix this is to use vi to edit the known_hosts file. Use the :15 command to navigate to line 15 and use dd keystroke to remove this entry, then :wq to save and quit vi.

Another alternative is to use sed to remove line 15:

# sed -i '15d' /root/.ssh/known_hosts
#

Also, the ssh-keygen utility comes with this built in:

# ssh-keygen -f '/root/.ssh/known_hosts' -R 192.168.1.102
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
# 
share:

check SSL certificate from website

You can easily get the SSL certificate from a website from command line. To get the whole thing in text form:

# echo "quit" | openssl s_client -connect $1:443 2>/dev/null | openssl x509 -noout -text
# (long output)

Also, individual attributes can be checked. Get some useful info by using -issuer or -enddate flags

# echo "quit" | openssl s_client -connect godaddy.com:443 2>/dev/null | openssl x509 -noout -issuer | cut -d '/' -f 5 | cut -d "=" -f2
GoDaddy.com, Inc.
#
#
#echo "quit" | openssl s_client -connect godaddy.com:443 2>/dev/null | openssl x509 -noout -enddate | cut -d "=" -f2
Nov 12 19:07:30 2014 GMT
#
share:

use command line to add pool and virtual server to f5 BigIP load balancer

Using the bigpipe cli command (or it’s alias “b“) to add pools and virtual servers, can save you hundreds of clicks. This is a very old version of a bigip.

# uname -r
BIG-IP 4.5.14

This creates a pool named myserverpool and adds a single member to it:

# b pool myserverpool {member 172.16.11.201:80}

To add many servers just use a while loop:

# i=202; while [ "$i" -lt "237" ]; do b pool myserverpool add \{ member 172.16.11.$i:80 \}; i=$(($i+1)); done;

Repeat for https:

# b pool myserverpool_ssl {member 172.16.11.201:443}
# i=202; while [ "$i" -lt "237" ]; do b pool myserverpool_ssl add \{ member 172.16.11.$i:443 \}; i=$(($i+1)); done;

Now add health checks:

# i=201; while [ "$i" -lt "237" ]; do b node 172.16.11.$i:80 monitor use http; i=$(($i+1)); done;
# i=201; while [ "$i" -lt "237" ]; do b node 172.16.11.$i:443 monitor use https; i=$(($i+1)); done;

And finally create the virtual servers, pointing traffic to the corresponding pools:

# b virtual 5.6.7.8:80 use pool myserverpool
# b virtual 5.6.7.8:443 use pool myserverpool_ssl
share: