How to determine the OS version using pvymomi? - python-3.x

Using pvymomi, I can determine the OS. How does one determine the OS version?
#!/usr/bin/python3
import sys
import atexit
from pyVmomi import vim
from pyVim.connect import SmartConnectNoSSL, Disconnect
si = SmartConnectNoSSL(host = 'xxx', user = 'xxx', pwd = 'xxx', port = 443)
atexit.register(Disconnect, si)
content = si.RetrieveContent()
vm = si.content.searchIndex.FindByIp(None, sys.argv[1], True)
print(vm.summary.config.guestFullName)
print(vm.summary.config.guestId)
The above code produces the following:
$ ./example.py 10.120.73.45
CentOS 7 (64-bit)
centos7_64Guest
I can see the VM is running CentOS 7, but is it 7.6 or 7.9? I'm not seeing what property or even what data object gives that information.

After doing some research into this question, I have found that the vSphere Web Services API, which the Python package pyvmomi uses does not have an easy way to collect the exact version operating system version with a basic API call.
If you look at the vSphere Web Services API information for
guestFamily, which is in GuestInfo you will not see any API call for precise versioning information.
Additionally, to obtain the exact operating system version information for CentOS you would normally have to query the kernel, which contains this information.
You can obtain the version of CentOS using this command:
cat /etc/centos-release
# output
CentOS Linux release 7.9.2009 (Core)
You can query this information GuestProgramSpec
Here is some pseudocode for doing this.
ps = vim.vm.guest.ProcessManager.ProgramSpec(programPath="/usr/bin/cat", arguments=" /etc/centos-release > /tmp/os_version_info.txt")
res = pm.StartProgramInGuest(vm, creds, ps)
You can also obtain this information using the uname tool, which is commonly used to obtain information about the processor architecture, which as the system hostname and the version of the kernel running on the system.
Here is the command - uname -s -r
-s, (--kernel-name) - Prints the kernel name
-r, (--kernel-release) - Prints the kernel release.
Here is a website that provides some information on mapping the kernel releases information to a specific operating system. Here is another website. Using the latter website I can see that kernel-3.10.0-1160.el7.x86_64 maps to CentOS 7.9.2009 for x86_64.
Here is some pseudocode for doing this.
ps = vim.vm.guest.ProcessManager.ProgramSpec(programPath="/usr/bin/uname", arguments=" -s -r > /tmp/os_kernel_info.txt")
res = pm.StartProgramInGuest(vm, creds, ps)
Based on my research getting this information back to the console is more complex. Here is a Stack Overflow question in how to do this.
UPDATE
I discovered this sample pyvmomi script, which can execute a command and retrieve the content back to the console.
Execute program in a virtual machine

Related

xen hvm : no console

I am trying to run opnsense as xen domU.
My host is debian 11 and xen boots as dom0 with this configuration :
dom0_mem=1G,max:1G dom0_max_vcpus=1
I am trying to boot on opnsense from iso with this file :
builder = "hvm"
name = "router"
memory = 1024
vcpus = 2
serial='pty'
sdl=0
vnc=0
disk = [ 'phy:/dev/sda3,sda,w'
, '/opt/iso/OPNsense-23.1-OpenSSL-dvd-amd64.iso,raw,xvdc,devtype=cdrom,r'
]
boot='cd'
-> xl create -c opnsense.cfg
The domU seems to boot (disk and CPU activity) but the console stays empty.
I tried to access to console with "xl console router" but the command returns :
"xenconcole: Could not lock /var/lock/xenconsole.14: Resource temporary unavailable."
Is there a special configuration for console in hvm mode ?
Thanks for help
Does opnsense actually support a serial console automatically in its installer iso image?
You may want to double check, just to make sure serial console actually works in your environment, with an ordinary Linux distribution install iso image if there is serial output.
The posted domU.cfg looks correct to me, it works in my non-Debian, non-OPNsense environment.

SWUpdate API with Qt

I'm trying to update my application using SWUpdate tool for my embedded board.
I already created my .swu pack, anche with ssh command line, it works fine.
I need to launch the update from my Qt application.
How can I do?
Maybe I can launch QProcess::execute("swupdate -i /run/media/AppUpdate.swu"), but it still not working.
How can I link with Qt the SWUpdate API installed?
Thanks.
You did not state which Qt version you are using. The more recent ones deprecated the QProcess::execute call as you are using it (program name and arguments in one string).
Try this:
QProcess* proc = new QProcess;
proc->setProgram("swupdate");
proc->setArguments(QStringList({"-i", "path/to/your/update.swu"});
proc->start();
if (!proc->waitForStarted())
qCritical() << "failed to start swupdate: " << proc->errorString();
/*optional: block/wait for swupdate to finish*/
proc->waitForFinished(-1);
I recommend to also implement and connect the readyRead signal and save/log swupdate's output in case something goes wrong during the update.

django.db.utils.DatabaseError: Error while trying to retrieve text for error ORA-01804

Q1. What versions are we using?
Ans.
Python 3.6.12
OS : CentOS 7 64-bit
DB : Oracle 18c
Django 2.2
cx_Oracle : 8.1.0
Q2. Describe the problem
Ans. While running server with "python3 manage.py runserver"
application is able to contact Oracle DB and show the Django Administration page and login also works.
But when we access the application using the Apache (HTTPD) based URL over secure SSL port, we do see the Django page and the admin page as well but Login to Admin page with Internal server error.
In the logs, we see
"django.db.utils.DatabaseError: Error while trying to retrieve text for error ORA-01804"
cx_oracle is otherwise able to connect to the database properly, another application is also using the same database behind the same httpd proxy and works fine
Q3. Show the directory listing where your Oracle Client libraries are installed (e.g. the Instant Client directory). Is it 64-bit or 32-bit?
Ans. 64-bit
Q4. Show what the PATH environment variable (on Windows) or LD_LIBRARY_PATH (on Linux) is set to?
LD_LIBRARY_PATH=/srv/vol/db/oracle/product/18.0.0/dbhome_1/lib:/lib:/usr/lib
PATH=$ORACLE_HOME/bin:/srv/vol/db/oracle/product/18.0.0/dbhome_1/lib:$PATH
Q5. Show any Oracle environment variables set (e.g. ORACLE_HOME, ORACLE_BASE).
ORACLE_HOME=/srv/vol/db/oracle/product/18.0.0/dbhome_1
TNS_ADMIN=$ORACLE_HOME/network/admin
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
ORACLE_BASE=/srv/vol/db/oracle
CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$ORACLE_HOME/lib
Any suggestions/help is highly appreciated.
Thank you
I found the problem
So I just removed all the variable declarations from /etc/sysconfig/httpd and checked, the application was still able to access the lib files, so these were now redundant.
Then undid all variable declarations done earlier in .localsh and .localrc files for the os users. To start from scratch, and go step by step to see where it breaks.
So now, cx_Oracle was looking for the lib files in wrong directory
$ORACLE_HOME/client_1/lib
instead of
$ORACLE_HOME/lib
DPI-1047: Cannot locate a 64-bit Oracle Client library: "$ORACLE_HOME/client_1/lib/libclntsh.so: cannot open shared object file: No such file or directory". See https://cx-oracle.readthedocs.io/en/latest/user_guide/installation.html for help
I did not have any subfolder named "client_1" inside dbhome_1
so I just created a symlink client_1 that points to dbhome_1 (still unsure on this, but at least it works :) )
So, now, this error was gone but now again ORA-01804 was coming. 😑
I had read somewhere that this error can be fixed by adding "libociei.so" but I did not have one on my instance, so I generated it using these commands:-
mkdir -p $ORACLE_HOME/rdbms/install/instantclient/light
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk igenliboci
Then I just moved this libociei.so file from
$ORACLE_HOME/instantclient to $ORACLE_HOME/lib
Now there was a new error (so.. progress 😉 ):
ORA-12546 - TNS Permission Denied.
This was easy to solve 😀
I used this command to address this :-
setsebool -P httpd_can_network_connect on
And...... That was all! It worked.

WMIC differences in Linux vs Windows

This wmic query (NODE, USER, PASS all desensitised)...
wmic /NODE:10.00.00.1 /LOCALE:MS_409 /PRIVILEGES:ENABLE /TRACE:OFF /INTERACTIVE:OFF /FAILFAST:OFF /USER:domain\my_user /PASSWORD:myPass! /OUTPUT:STDOUT /APPEND:STDOUT /AGGREGATE:ON class StdRegProv CALL EnumKey ^&H80000002,"Software\Microsoft\SystemCertificates\MY\Certificates"
^&H80000002 is the uint32 conversion of HKEY_LOCAL_MACHINE
... runs flawlessly in a CMD prompt in Windows. I can also run it in the context of a node package from my local windows machine with success, I'm going to assume this is because the wmic call is made specifically to the local machine (windows) where it is handled effortlessly. Returning to me a result containing what I require...
res.sNames [ 'BB731A3DD8F089A6D4E59AF9D706...' ]
I created a docker container running Alpine and node where I host an express application. I followed the instructions below to install WMIC on Linux...
https://askubuntu.com/questions/885407/installing-wmic-on-ubuntu-16-04-lts
This installed successfully.
Now when I run the exact same query from a bash prompt in Ubuntu either via my Node app or a direct command, I'm receiving this result:
Garne#MYCOMPUTERNAME MINGW64 ~
$ wmic.exe /NODE:10.00.00.1 /LOCALE:MS_409 /PRIVILEGES:ENABLE /TRACE:OFF /INTERACTIVE:OFF /FAILFAST:OFF /USER:domain\my_user /PASSWORD:myPass! /OUTPUT:STDOUT /APPEND:STDOUT /AGGREGATE:ON class StdRegProv CALL EnumKey ^&H80000002,"Software\Microsoft\SystemCertificates\MY\Certificates"
[1] 426
bash: H80000002,Software\Microsoft\SystemCertificates\MY\Certificates: No such file or directory
Garne#MYCOMPUTERNAME MINGW64 ~ $ ERROR: Description = Access is
denied.
I can't for the life of me work out whether this is due to a string formatting error in Linux vs Windows or whether Linux is running a different variant of wmic that isn't resolving my query correctly?
For anyone wondering, after hours of testing this with very obscure error messages. Make sure you escape absolutely everything in bash style not in a windows fashion.
Note:
\$ instead of ^&
Wrap USER value in ''
Wrap PASSWORD value in ''
References here:
https://manpages.debian.org/buster/bash/bash.1.en.html#QUOTING
$ wmic /NODE:10.23.0.11 /LOCALE:MS_409 /PRIVILEGES:ENABLE /TRACE:OFF /INTERACTIVE:OFF /FAILFAST:OFF /USER:'domain\my_user' /PASSWORD:'myPass!' /OUTPUT:STDOUT /APPEND:STDOUT /AGGREGATE:ON class StdRegProv CALL EnumKey \&H80000002,"Software\Microsoft\SystemCertificates\MY\Certificates"
Executing (StdRegProv)->EnumKey()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
ReturnValue = 0;
sNames = {"BB731A3DD8F089A6D4E59AF9D70601F9CBB94A9D"};
};

RemoteCertificateNameMismatch when auth using SslStream on linux

I've come across some strange behaviour of dotnet SslStream, when running my dotnet-core app on linux environment.
here is the code:
TcpClient cl = new TcpClient();
cl.Connect("52.209.63.190", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");
Auth result is success, when running on windows.
But same code ends with auth error (RemoteCertificateNameMismatch), when linux.
dotnet --info:
.NET Command Line Tools (2.1.4)
Product Information:
Version: 2.1.4
Commit SHA-1 hash: 5e8add2190
Runtime Environment:
OS Name: fedora
OS Version: 27
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.1.4/
Microsoft .NET Core Shared Framework Host
Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54
Why code behaviour is so different on linux?
How can I handle it and pass ssl auth?
Thank you in advance
So, you can connect to that host with
TcpClient cl = new TcpClient();
cl.Connect("api.bitfinex.com", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");
I don't know how you got the IP address of api.bitfinex.com, but it's under cloudflare, and may be you don't need to connect bitfinex with his real IP address.
But if it is required to connect that special IP address, you can override verification callback before you do any connection
System.Net.ServicePointManager.ServerCertificateValidationCallback =
(sender, certificate, chain, errors) => true;
Looks like the answer is simple: too old dotnet version.
2.0 seems to have some ssl issues, which were fixed since 2.1
When I installed the newest one (2.1.3), my app still didn't work, decause I had to uninstall prev version (2.0.5) manually to be able to use 2.1.3
Now the app ends with the same result on both windows and linux environments.
Many thanks to M. Hovhannisyan. I've started trying different linux versions, and figured out what I did wrong

Resources