Monday, June 3, 2024

VMWare ESXi (VSphere) - How to Downgrade VM Hardware (example 7U3 to 6.7)

Upgrading the hardware on a VM is easy just rigth click on the mouse and chose "Upgrade VM Compatibility".

The inverse, which downgrading VM Hardware, there is no official way of doing it.


To downgrade from ESXI 7U3 to 6.7 I did it like this (should work for other versions):


  • Enable SSH on ESXI7
  • WinSCP to ESXI7
  • Clone the .vmx to save it before changing it
  • Change original .vmx to ESXI 6.7 (hardware version 14):

            virtualHW.version = "14"


            You can find other harware versions at:

            https://knowledge.broadcom.com/external/article?legacyId=1003746

                VMware products and their virtual hardware version


  • Unregister the VM
  • Register VM using the modified .vmx





Sunday, June 2, 2024

Ansible - Setup on Linux ( +cisco devices )

 

Ansible Installation

On the ubuntu shell run:

sudo apt update
sudo apt upgrade -y

 

# PYTHON

sudo apt-get install python3

sudo apt install python3-pip

 

# ANSIBLE

sudo apt install -y software-properties-common

sudo apt install -y ansible

 

# ANSIBLE COMMON MODULES / LIBRARIES (OPTIONAL)

ansible-galaxy collection install cisco.ios

sudo apt-get install python3-dnspython

sudo pip install ansible-pylibssh

sudo pip install pexpect

sudo pip install paramiko

sudo apt-get install sshpass


SSH Host Key Checking

If you want to avoid issues on connecting via SSH because the the keys are not added, go to:  

sudo nano /etc/ansible/ansible.cfg

and uncoment the "host_key_checking" line:

[defaults]
host_key_checking = False

Verification

WSL

Win+r ubuntu

 

PYTHON

python3

 

ANSIBLE

ansible-playbook --version


Wednesday, May 18, 2022

Ansible - Setup on Windows WSL ( +cisco devices )

Enable Windows Features for WSL (Windows Subsistem for Linux - aka Linux on Windows)

Run on powershell

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

 

Download and Install WSL2 Patch

https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi

Set Default Version to Version 2

Run on powershell

wsl --set-default-version 2

Ubuntu WSL Download - Without Using Windows Store - Online Method

Open windows CMD and run:

wsl --list --online
The following is a list of valid distributions that can be installed.
Install using 'wsl --install -d <Distro>'.

NAME FRIENDLY NAME
Ubuntu Ubuntu
Debian Debian GNU/Linux
kali-linux Kali Linux Rolling
openSUSE-42 openSUSE Leap 42
SLES-12 SUSE Linux Enterprise Server v12
Ubuntu-16.04 Ubuntu 16.04 LTS
Ubuntu-18.04 Ubuntu 18.04 LTS
Ubuntu-20.04 Ubuntu 20.04 LTS


wsl --install --distribution Ubuntu

Ubuntu WSL Download - Without Using Windows Store - Offline Method

Open windows powershell and run:

Invoke-WebRequest -Uri https://aka.ms/wslubuntu2004 -OutFile Ubuntu.appx

Add-AppxPackage .\Ubuntu.appx


First Run and Installation

Win+r Ubuntu

Set WSL DNS to Google DNS (default is a Windows generated, which doesn't always work)

Change the DNS to Google's DNS

sudo nano /etc/resolv.conf


# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 8.8.8.8

Avoid windows from changing the DNS server again:

sudo nano /etc/wsl.conf 


[network]
generateResolvConf = false

Ansible Installation

On the ubuntu shell run:

sudo apt update
sudo apt upgrade -y

 

# PYTHON

sudo apt-get install python3

sudo apt install python3-pip

 

# ANSIBLE

sudo apt install -y software-properties-common

sudo apt install -y ansible

 

# ANSIBLE COMMON MODULES / LIBRARIES (OPTIONAL)

ansible-galaxy collection install cisco.ios

sudo apt-get install python3-dnspython

sudo pip install ansible-pylibssh

sudo pip install pexpect

sudo pip install paramiko

sudo apt-get install sshpass


SSH Host Key Checking

If you want to avoid issues on connecting via SSH because the the keys are not added, go to:  

sudo nano /etc/ansible/ansible.cfg

and uncoment the "host_key_checking" line:

[defaults]
host_key_checking = False

Extra - Convert Install Machines to WSL2

If you already had WSL installed and some distros and want to convert then, first check your distros and versions:

wsl --list -v
NAME STATE VERSION
Ubuntu Running 1

then change it to version two and windows will start the conversion:

wsl --set-version Ubuntu 2

Verification

WSL

Win+r ubuntu

 

PYTHON

python3

 

ANSIBLE

ansible-playbook --version


Monday, October 8, 2018

Nvidia Shield - NAS Server (SMBv1)


Configuring The Nvidia Shield (v8.0.0)

Go to Settings > Storage & reset > Transfer files over network, to turn this feature on.

clip_image002

You'll be presented with a

  • User name - the Nvidia Shield generates it but you can change it
  • Password - the Nvidia Shield generates the password not you

that you can use on a networked PC to access SHIELD folders.

clip_image004

Make sure your PC is on the same network as your SHIELD.


Activate SMB1 Client on Windows 10

This is a legacy protocol and it´s client is disabled by default, to enable it:

  1. Open Control Panel.
  2. Click on Programs.
  3. Click on Turn Windows features on or off link.

clip_image006

  1. Expand the SMB 1.0/CIFS File Sharing Support option.
  2. Check the SMB 1.0/CIFS Client option.

clip_image007

  1. Click the OK button.
  2. Click the Restart now button.

After completing these steps, you'll once again be able to see and connect to network devices running the old protocol on your local network from your Windows 10 computer.


Accessing The Nvidia Shield Shared Folder

On windows start menu run the following command:

image

You can also permanently map your SHIELD as a network drive by right-clicking on "Network" in File Explorer and selecting "Map Network Drive". Select an unused Drive letter.

clip_image011


Based On:

https://nvidia.custhelp.com/app/answers/detail/a_id/4172/~/how-do-i-share-shield-tv-folders-with-a-pc

Sunday, December 10, 2017

Raspberry Pi/Linux - Installing Webmin

Today I’m going to show you how to install webmin on you Raspberry Pi or other linux machines. I tested this on a Raspberry Pi.


On The Cli

On the CLI of the machine you want to install Webmin, just do.

sudo apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl apt-show-versions python

wget https://downloads.sourceforge.net/project/webadmin/webmin/1.870/webmin_1.870_all.deb

sudo dpkg -i webmin_1.870_all.deb

now Webmin should be installed and running.


On a Browser

Let’s access Webmin, just swap the 192.168.10.20 IP with the IP where you installed webmin, and access it on the browser like this:

https://192.168.10.20:10000

and login to webmin:

image

the user and pasword are you machines’s local linux users and passwords.

Now you start managing you linux from a Gui :)

image

My main goal personally was to have a Gui to manage DNS (Bind), which becomes quite easy with webmin.:

image

Tuesday, November 7, 2017

Linux SSH - Automation with Send & Expect Scripts

By Ken Hess

Expect is a natural and intuitive automation scripting language that operates in much the same way humans do when interacting with a system. You type in commands and expect a certain response to your command. When you receive the expected response, you enter another command and so on. Expect works in the same way, except you have to provide the script with commands and expected responses to those commands. Basically, you have to script out the entire two-way “conversation.”


You can think of an Expect script as a dialog script written for two actors: a sender and a receiver. One of the more popular activities to automate is an SSH session between two hosts, in which one host is the sender (local host) and the other is the receiver (remote host). Being able to emulate every keystroke and create a true interactive session between two systems via a script is an exciting proposition.


Expect Setup

Most Linux distributions include Expect as part of the available and installable software packages. In other words, you won’t have to download and install from source code. Use your system’s package manager to download and install Expect and any required dependencies or associated packages. For example:


$ sudo yum install expect
or
$ sudo apt-get install expect


Once you have Expect installed, you can begin writing scripts.


Creating an Interactive SSH Session

As stated previously, you must provide both sides of the conversation in your script because you’re setting up an interactive system. Look at a few essential items before diving right into a script.


To make an Expect script executable as a standalone program, you must do two things: Make the script executable, and supply the path to the script for expect . The path on my system is: /usr/bin/expect ; therefore, enter that path on the first line of your script with a preceding “shebang” (#! ):

#!/usr/bin/expect -f

The -f switch tells Expect that it is reading commands from a file.


The spawn command spawns or launches an external command for you. In this case, ssh to a remote host (aspen ):

spawn ssh aspen

Change the host aspen to your remote host. When you SSH to a remote system, you’re prompted for a password. This password prompt is what you “expect” from the remote system; therefore, you enter that expected response:

expect "password: "

From the local side, you have to enter your password at the password prompt. To send anything to the remote system, it must be included in double quotes and must include a hard return (\r ). Change PASSWORD to your password:

send "PASSWORD\r"

Again, you have to enter the expected response from the remote system, which in this case is a user prompt ($ ).

expect "$ "

Now that you’re logged in to the remote system, you can begin your interactive session on that remote host. The following send command issues the ps -ef |grep apache command:

send "ps -ef |grep apache\r"

Output will appear as STDOUT. After the command has executed, you’re returned to a prompt, so tell the Expect script that bit of information:

expect "$ "

Finally, send the exit command to the remote system to log out. Don’t forget that hard return (\r ):

send "exit\r"

The script in its entirety looks as follows:

#!/usr/bin/expect -f
spawn ssh aspen
expect "password: "
send "PASSWORD\r"
expect "$ "
send "ps -ef |grep apache\r"
expect "$ "
send "exit\r"

Change permissions on the script so that it is executable; for example,

$ chmod 755 script.sh

and try it for yourself.


Expect Caveats

If your script hangs and doesn’t continue, try the command manually yourself and look for the response. If the remote system drops you to a prompt as its final act, then place that in your script (e.g., expect "$ " ). Be sure you have entered the hard return (\r ) inside the closing quotation mark in your send line. You might also find that your system needs two backslashes on the send line for a hard return (\r ).


Sometimes Expect scripts execute too fast, and you won’t see your expected response. If that happens, place a sleep command and a number of seconds for the command preceeding it to wait for a response, or your data might be ignored.
For example, if you connect to a remote system and there’s a delay in creating that connection, your script will continue to execute and fail because it sends commands before the remote system has time to respond.


You have to think about network delays, shell responses and system timing when scripting in Expect. Like any scripting language, Expect has its quirks, but you’ll find that it’s an easy way to automate those repetitious keystrokes and procedures. The time you spend debugging your scripts is well worth the effort.


Autoexpect

Of course, some lazy system administrators take lazy to a higher level and even cheat at writing Expect scripts by invoking a shell “watcher” or recorder script named Autoexpect. Once invoked, Autoexpect watches your every keystroke and records it to a file named, script.exp by default. You’ll almost certainly have to edit and prune this script to achieve your desired results; however, it can save hours of script debugging to have an almost complete script from which to work.


If you simply run a freshly created Autoexpect script, it will likely fail because, if you issued a command that answers your request by displaying information to the screen, the script picks up that answer, too, and copies it into the script file.
For example, if during your Autoexpect session, you type, ls , the result of that command appears in your script.exp file as well. After you’ve created a few Expect scripts by hand, you’ll appreciate the cleanup editing you have to do in an Autoexpect-created script.
To install Autoexpect, issue a command like:

$ sudo apt-get install expect-dev

You’ll likely require many more dependencies for this feature, so prepare yourself for a slight delay while everything installs.


Creating an Interactive SSH Session with Autoexpect

After installing Autoexpect and all of its required packages, you’re ready to create Expect scripts automatically by stepping through the procedures you want to automate. Using the above example, SSH to a remote system and run a

ps -ef |grep apache

command and then log out.
Invoking Autoexpect is easy:

$ Autoexpect

Autoexpect started, file is script.exp
$

Although it looks as if nothing has happened or is happening, every keystroke you type will be recorded into script.exp . Every STDOUT response you receive will also be copied into that same file. Your entire session is recorded – but not just recorded, it is also formatted in Expect script style. To stop recording keystrokes to your script, press Ctrl+D on your keyboard to stop Autoexpect and copy the buffer to your file.


The complete transcription of this simple procedure is very long and includes a lot of commentary from the author, Don Libes:

#!/usr/bin/expect -f
#
# This Expect script was generated by Autoexpect on Thu Oct 11 15:53:18 2012
# Expect and Autoexpect were both written by Don Libes, NIST.
#
# Note that Autoexpect does not guarantee a working script.  It
# necessarily has to guess about certain things.  Two reasons a script
# might fail are:
#
# 1) timing - A surprising number of programs (rn, ksh, zsh, telnet,
# etc.) and devices discard or ignore keystrokes that arrive "too
# quickly" after prompts.  If you find your new script hanging up at
# one spot, try adding a short sleep just before the previous send.
# Setting "force_conservative" to 1 (see below) makes Expect do this
# automatically - pausing briefly before sending each character.  This
# pacifies every program I know of.  The -c flag makes the script do
# this in the first place.  The -C flag allows you to define a
# character to toggle this mode off and on.

set force_conservative 0  ;# set to 1 to force conservative mode even if
                           ;# script wasn’t run conservatively originally
if {$force_conservative} {
         set send_slow {1 .1}
         proc send {ignore arg} {
                 sleep .1
                 exp_send -s -- $arg
         }
}

#
# 2) differing output - Some programs produce different output each time
# they run.  The "date" command is an obvious example.  Another is
# ftp, if it produces throughput statistics at the end of a file
# transfer.  If this causes a problem, delete these patterns or replace
# them with wildcards.  An alternative is to use the -p flag (for
# "prompt") which makes Expect only look for the last line of output
# (i.e., the prompt).  The -P flag allows you to define a character to
# toggle this mode off and on.
#
# Read the man page for more info.
#
# -Don

set timeout -1
spawn $env(SHELL)
match_max 100000
expect -exact "]0;khess@trapper: ~khess@trapper:~\$ "
send -- "ssh aspen\r"
expect -exact "ssh aspen\r
khess@aspen’s password: "
send -- "PASSWORD\r"
expect -exact "\r
Linux aspen 2.6.32-43-server #97-Ubuntu SMP Wed Sep 5 16:56:41 UTC 2012 x86_64 GNU/Linux\r
Ubuntu 10.04.4 LTS\r
\r
Welcome to the Ubuntu Server!\r
  * Documentation: 
http://www.ubuntu.com/server/doc\r
\r
   System information as of Thu Oct 11 15:55:28 CDT 2012\r
\r
   System load:  1.09               Temperature:         40 C\r
   Usage of /:   1.0% of 454.22GB   Processes:           168\r
   Memory usage: 22%                Users logged in:     1\r
   Swap usage:   0%                 IP address for eth0: 192.168.1.250\r
\r
   Graph this data and manage this system at
https://landscape.canonical.com/\r
\r
7 packages can be updated.\r
7 updates are security updates.\r
\r
New release ‘precise’ available.\r
Run ‘do-release-upgrade’ to upgrade to it.\r
\r
*** System restart required ***\r
Last login: Thu Oct 11 15:53:41 2012 from trapper\r\r
]0;khess@aspen: ~khess@aspen:~\$ "
send -- "ps -ef|grep apache\r"
expect -exact "ps -ef|grep apache\r
www-data   555 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   556 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   557 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   558 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   559 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
khess    21504 21433  0 15:55 pts/1    00:00:00 grep apache\r
root     23171     1  0 Sep27 ?        00:00:28 /usr/sbin/apache2 -k start\r
]0;khess@aspen: ~khess@aspen:~\$ "
send -- "exit\r"
expect -exact "exit\r
logout\r
Connection to aspen closed.\r\r
]0;khess@trapper: ~khess@trapper:~\$ "
send -- "^D"
expect eof
khess@trapper:~$
You can see that you have a lot of cleanup to do before you distill this transcript down to its essential parts. Autoexpect also changes permissions on the script.exp file so that it is executable.
The parts you needed for this script to execute correctly are shown below in my cleaned up version.
#!/usr/bin/expect -f

set force_conservative 0  ;# set to 1 to force conservative mode even if
                           ;# script wasn’t run conservatively originally
if {$force_conservative} {
         set send_slow {1 .1}
         proc send {ignore arg} {
                 sleep .1
                 exp_send -s -- $arg
         }
}

set timeout -1
spawn $env(SHELL)
match_max 100000
expect -exact "$ "
send -- "ssh aspen\r"
expect -exact "password: "
send -- "PASSWORD\r"
expect -exact "$ "
send -- "ps -ef|grep apache\r"
expect -exact "$ "
send -- "exit\r"
expect -exact "$ "


You can see that the complex prompts, such as

expect -exact "exit\r
logout\r
Connection to aspen closed.\r\r
]0;khess@trapper: ~khess@trapper:~\$ "

have been shortened significantly to:

expect -exact "$ "

The prompt still works because Expect looks for the last few characters in an expect line and not the entire string. You could shorten the line that expects the password prompt from:

expect -exact "password: "
to
expect -exact ": "

A word of caution against shortening your expect lines too much – it makes the script more difficult, not easier, to read and interpret in the future when you try to figure out what’s going on.

You might not realize that ": " is a password prompt. Unless you’re great at including comments in your scripts, you might spend hours debugging this shortened version.


Summary

To be perfectly honest, I only use Autoexpect when building an Expect draft script. To sit down and attempt writing Expect line-by-line just isn’t appealing after being seduced and ruined by the ease of removing unwanted lines from an Autoexpect-created script. Autoexpect makes using Expect fun and more intuitive by letting you perform a procedure one time instead of many. After discovering and using Autoexpect, my Expect scripting creation time and debug time has been cut by at least two-thirds. I suspect you’ll have much the same return on your time as well.


Taken From: http://www.admin-magazine.com/Articles/Automating-with-Expect-Scripts

Monday, September 11, 2017

Raspberry - Remote Desktop via The Cloud (Real VNC)


Login via SSH

On your PC access the SD card with Raspbian installed:

image

create a file named ssh with no content:

image

this will signal the Raspberry Pi to start the SSH server.

Put the SD card on the raspberry and start it.


Start VNC Server

Now on the cli via SSH:

sudo raspi-config


### ADJUST RESOLUTION ###

7 Advanced Options

A5 Resolution

DTM Mode 16 1024x768 60 Hz 4:3


### ENABLE REAL VNC SERVER ###

Interfacing Options

P3 VNC –Yes  (ENTER TO ENABLE)
    
  Now it will install a bunch of packages


Install the Real VNC Client on a PC

Get the Real VNC Server here:

https://www.realvnc.com/en/connect/download/viewer/

image


Access the Raspberry Pi via VNC

Get the Raspberry PI IP from you router or by connecting a HDMI screen to it:

image

authenticate using a local user and password (the default is: pi / raspberry)

image


image


Creating a Cloud Account

image

image

if it does not open a browser, click on this link:

https://www.realvnc.com/en/raspberrypi/#sign-up

now create an account, and login into to the above window.

image

hit next and you are done.

You can have up to 5 devices with this free account.


Logging in to the Cloud

Now logging in the window above with the created account:

image

and it will show all your devices. Now you can just click on a device and with no port forwarding it will access it via the Real VNC Cloud:

image