Thursday, August 31, 2017

Dell iDRAC Reboot Guest OS and Restart DRAC commands

Send the following commands via SSH:

ssh <drac hostname or IP> 'racadm getsysinfo'

You can even redirect it to a file on your local system:
ssh <drac hostname or IP> 'racadm getsysinfo' | tee -a /path/to/file.txt

Reboot Guest OS (the OS installed on the hardware)

(from: https://www.devops.zone/tricks/connecting-ssh-drac-reboot-server/)
Connect to the Dell Remote Access Controller (Drac) IP address via SSH. Then execute:
racadm serveraction <action>
whereas you replace <action> with one of the following:
  • powerdown — Powers down the managed system.
  • powerup — Powers up the managed system.
  • powercycle — Issues a power-cycle operation on the managed system. This action is similar to pressing the power button on the system’s front panel to power down and then power up the system.
  • powerstatus — Displays the current power status of the server (“ON”, or “OFF”)
  • hardreset — Performs a reset (reboot) operation on the managed system.
So, to power off and back on your server, you just type racadm serveraction powercycle.
If your Drac crashes for any reason, you may want to reset it: (more info)
racadm racreset soft
If you want to have information about your current server, type:
racadm getsysinfo
(from: https://frednotes.wordpress.com/2012/11/13/reset-dell-idrac-using-ssh/)

How to reboot an DELL idrac when web page refuse access:

Connect to idrac IP using ssh with the password refused by web page
$ ssh root@192.168.0.120
root@192.168.0.120's password:
The magic DELL tool is here : radadm
/admin1-> racadm
===============================================================================
 RACADM version 1.80 (Build 17)
 Copyright (c) 2003-2010 Dell, Inc.
 All Rights Reserved
 ===============================================================================
RACADM usage syntax:
racadm <subcommand> <options>
Examples:
racadm getsysinfo
 racadm getsysinfo -d
 racadm getniccfg
 racadm setniccfg -d
 racadm setniccfg -s 192.168.0.120 255.255.255.0 192.168.0.1
 racadm getconfig -g cfgLanNetworking
Display a list of available subcommands for the RAC:
racadm help
Display more detailed help for a specific subcommand:
racadm help <subcommand>
------------------------------------------------------------------------------
So to reboot :
/admin1-> racadm racreset soft
RAC reset operation initiated successfully. It may take up to a minute
for the RAC to come back online again.
/admin1-> Connection to 192.168.0.120 closed by remote host.
Connection to 192.168.0.120 closed.



Thursday, August 3, 2017

I need to rsync from a root protected directory on one server to a root protected directory on another...


Thanks to: https://crashingdaily.wordpress.com/2007/06/29/rsync-and-sudo-over-ssh/


sudo rsync -av -e "ssh" --rsync-path="sudo rsync" username@srv01.prod.example.com:/tftpboot/ /tftpboot/

So here is the thing...

I SSH(ed) to the remoteA and forwarded my ssh keys (ForwardAgent yes) and ran this command:

Breakdown:
sudo rsync -av -e "ssh" 
^ On the host I'm running this on run it under sudo
--rsync-path="sudo rsync" username@srv01.prod.example.com:/tftpboot/ /tftpboot/
^ On the remote server run rsync server as sudo

Tuesday, May 2, 2017

SSH ProxyCommand to use a "gateway" ssh server for subsequent SSH connections

from: https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/

ProxyCommand to the rescue

If you’re still reading this, chances are that you’re not aware of the awesome toolbox that is SSH (or at least OpenSSH, let’s be honest).
OpenSSH has an option called ProxyCommand. It works by specifying a ProxyCommand to connect to host B. The config would look like this for our simple example:
1 Host hosta
2  User userfoo
3  Hostname 123.123.123.123
4 
5 Host hostb
6  User userbar
7  Hostname 192.168.1.1
8  Port 2222
9  ProxyCommand ssh -q -W %h:%p hosta
This config tells your local SSH client to connect to host A via a direct connection. Now, if you type ssh hostb what it will do is connect to host A first and then forward your SSH client via the ProxyCommand to the host and port specified by the -W parameter, in this case I used 192.168.1.1 to underline that this is an internal host. Your local SSH client will then authenticate to host B as if you were connected to it directly.
Another observation here is that you don’t need to memorize anything about the host, neither it’s IP or obscure hostname, port or username when you can simply alias it with the Host line.