The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,860 other subscribers

Archive for the ‘*nix’ Category

« Previous Entries
Next Entries »

After the freenode to libera transition: openSUSE:IRC list – openSUSE Wiki

Posted by jpluimers on 2021/06/18

For my link archive: [Wayback] openSUSE:IRC list – openSUSE Wiki

–jeroen

Posted in *nix, Chat, IRC, Linux, openSuSE, Power User, SocialMedia, SuSE Linux | Leave a Comment »

CloudKey ESXi Appliance – Google Search

Posted by jpluimers on 2021/06/07

Via [Archive.is] CloudKey ESXi Appliance – Google Search:

–jeroen

Posted in *nix, Cloud Key, ESXi6, ESXi6.5, ESXi6.7, Internet, Network-and-equipment, Power User, Unifi-Ubiquiti, Virtualization, VMware, VMware ESXi | Leave a Comment »

Downloading files with wget on ESXi · random writes

Posted by jpluimers on 2021/05/31

Reminder to self to check if wget on ESXi now finally supports https downloading: [WayBack] Downloading files with wget on ESXi · random writes.

In the mean time, ESXi 6.7 Update 2 and up seems to support this; so the below workaround might only be needed for ESXi 6.7 update 1 and below.

[WayBack] VMware ESXi: help downloading large ISO – Server Fault

I will likely not do this, as by now all my ESXi boxes should have been recent enough.

I will keep the article because of the BusyBox commands section below.

If so, I might finally try and write a Python wrapper for this, as I know that Python 3 on ESXi supports https, but the ESXi BusyBox does not have a built-in cURL.

Some links and notes I might need by then:

BusyBox commands

Another cool thing in the above blog post is that it shows how to dump the BusyBox built in commands.

I ran it for ESXi 6.7 with a slight trick to get the full path (using back-ticks and escaped back-ticks) and content.

Since ESXi is BusyBox based, the commands that are in /bin are not actually binaries, but each command is a symlink to the BusyBox binary. BusyBox then knows the original name of the command, so it can deduct what part to execute. This makes for a very space efficient storage scheme.

The various bits of the tricks to get the location of the BusyBox binary, so the --list parameter can be passed to it:

  • The which wget gives the full path of wget.
  • The ls -l `which wget` shows the full path of wget and the symlink target (but there is no way for ls to only show the symlink target).
  • The readlink -f `which wget` shows the full path of where /bin/wget points to: the BusyBox binary.

The main trick consists of backtick evalution, and knowing that ls cannot get you just the symlink target, but readlink can:

Now the back-tick escapes, because you cannot nest back-ticks:

  • The `readlink -f \`which wget\`` executes the BusyBox binary without arguments.
  • The `readlink -f \`which wget\`` --list executes the BusyBox binary with the --list parameter.

Note I do not like the cat --help (see [WayBack] How do I check busybox version (from busybox)? – Unix & Linux Stack Exchange) way of getting the BusyBox version, as that gets echoed to stderr.

This is the output:

Read the rest of this entry »

Posted in *nix, *nix-tools, cURL, ESXi6, ESXi6.5, ESXi6.7, Power User, Virtualization, VMware ESXi, wget | Leave a Comment »

“FIPS mode initialized” when you ssh out of an ESXi box

Posted by jpluimers on 2021/05/28

The once per console/shell logon output of FIPS mode initialized to stderr when you ssh out of an ESXi box seems to be something new since ESXi 6.7.

Since I hardly do this, it took a while to reproduce and track back the version where it was introduced and to realise why it is on stderr.

stderr in retrospect is logical: if you need to parse stdout of a job running across an ssh channel, you do not want it to get interfered with “side channel” output, hence stderr.

For a longer explanation see, for instance [WayBack] ssh “FIPS mode initialized” message to stderr – Why? – Unix and Linux | DSLReports Forums:

Keep in mind that “ssh” is used to transport a stream, as with “rsync”. What you put on “stdout” becomes part of the stream. That’s why this sort of informational message needs to go to “stderr”.

Parsing is hard, so bugs like [WayBack] Git fetcher fails on machine with FIPS enabled machines · Issue #3664 · inspec/inspec · GitHub got [WayBack] fixed in [WayBack] pull request like [WayBack] not parsing stderr, but checking for exitstatus.

Stock OpenSSH portable does not contain FIPS support

Finding back when and how FIPS support for OpenSSH was introduced provide a bit harder than I hoped for.

It appears that stock [WayBack] OpenSSH: Portable Release does not support FIPS. But there are patches on top of these files:

Many (most?) Linux distributions include a patched version like [WayBack] ssh.c in openssh located at /openssh-5.9p1 (git://pkgs.fedoraproject.org/openssh).

They integrate the patches like [WayBack] File openssh.spec of Package openssh – openSUSE Build Service.

Patches for instance look like [WayBack] openssh/openssh-5.3p1-fips.patch at master · gooselinux/openssh · GitHub which is more than a decade old (see the 2009 message [WayBack] rpms/openssh/devel openssh-5.3p1-fips.patch, NONE, 1.1 openssh-5.3p1-mls.patch, NONE, 1.1 openssh-5.3p1-nss-keys.patch, NONE, 1.1 openssh-5.3p1-selabel.patch, NONE, 1.1 openssh-5.3p1-skip-initial.patch, NONE, 1.1 .cvsignore, 1.24, 1.25 openssh.spec, 1.170, 1.171 sources, 1.24, 1.25 openssh-3.8.1p1-krb5-config.patch, 1.1, NONE openssh-4.7p1-audit.patch, 1.2, NONE openssh-5.1p1-mls.patch, 1.1, NONE openssh-5.1p1-skip-initial.patch, 1.1, NONE openssh-5.2p1-fips.patch, 1.6, NONE openssh-5.2p1-nss-keys.patch, 1.3, NONE openssh-5.2p1-selabel.patch, 1.2, NONE).

The patches seem to originate at the (now defunct) WayBack Index of /export/openssh of http://openssl.com/export/openssh/ .

In the end I found [WayBack] Mailing List Archive: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules? having these quotes:

vanilla OpenSSH doesn’t support running OpenSSL in FIPS-140 mode. Some
downstream providers patch OpenSSH they deliver with their distributions
with changes to enable FIPS-140 mode.

[WayBack] Secure Shell and FIPS 140-2 – Managing Secure Shell Access in Oracle® Solaris 11.4 explains a bit of background of them.

ESXi 6.7

Binary searching for the version where this was introduced could have been a lot shorter if I had done a “FIPS mode initialized” “ESXi” – Google Search, resulting in for instance:

The final two links made me discover XSIBackup

They see be one of the few (only one?!) free backup solutions for the bare ESXi:

In addition, they have a binary for rsync version 3.1.0: [WayBack] 33HOPS | Rsync for VMWare Backup, so lees need to go to Source: ESXi 5.1 and rsync – damiendebin.net

––jeroen

Posted in *nix, *nix-tools, ESXi6.5, ESXi6.7, Power User, ssh/sshd, Virtualization, VMware, VMware ESXi | Leave a Comment »

Wondering about the flavours of Tumbleweed ISO images

Posted by jpluimers on 2021/05/28

The Tumbleweed ISO images have many flavours, none yet covered in a comprehensive list.

I found [WayBack] Get openSUSE , which only explains part of the puzzle:

  • Installation: x86_64, i586, aarch64, ppc64le (for DVD/NET)
  • Kubic x86_64 aarch64 (for DVD)
  • Live x86_64 i686 (for )

I do get the processor/architectures:

README files:

These all have the same content:

These ISO files are published automatically once a new snapshot finished.
They haven't seen any kind of testing before publishing, so download on your
own risk and cost.

Most of the time they work, but there are times when they are broken.

So visit (and edit if you reported a bug severe enough)
http://en.opensuse.org/Portal:Tumbleweed

But I could not find a single page explaining the difference between all these (and why some of them are not prefixed with Tumbleweed):

flavour media name architectures: x86 architectures: ARM architectures: PowerPC architectures: Z Systems
openSUSE-Kubic DVD x86_64 aarch64
openSUSE-MicroOS DVD x86_64
openSUSE-Tumbleweed DVD i586, x86_64 aarch64 ppc64, ppc64le s390x
openSUSE-Tumbleweed-GNOME Live i686, x86_64
openSUSE-Tumbleweed-KDE Live i686, x86_64
openSUSE-Tumbleweed NET i586, x86_64 aarch64 ppc64, ppc64le s390x
openSUSE-Tumbleweed-Rescue CD i686, x86_64
openSUSE-Tumbleweed-XFCE Live i686, x86_64

I do not get why:

  • some have a media name (especially not DVD: all of them are iso files, right?)
  • the architecture lists is so different for most of them
  • the rescue image is not i586

I know there are also non-ISO images for instance for Raspberry Pi or pure ARM at

  • [WayBack] Index of /ports/armv6hl/tumbleweed/images/:
    • openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.armv6l-Current.raw.xz
    • openSUSE-Tumbleweed-ARM-JeOS.armv6-rootfs.armv6l-Current.tar.xz
  • [WayBack] Index of /ports/armv7hl/tumbleweed/images/
    • Too long a list to fully categorise right now; limited categorisation:
    • Flavours seem to be E20/GNOME/JeOS/KDE/LXQT/X11/XFCE
    • Architectures seem to be a13olinuxino/a20olinuxinolime/a20olinuxinomicro/arndale/beagle/beaglebone/chromebook/cubieboard/cubietruck/cuboxi/efi/loco/midway/nanopineo/olinuxinolime/olinuxinolime2/panda/paz00/raspberry2/sabrelite/sinovoipbpimplus/socfpgade0nanosoc/udooneo/wga//              all armv7zl flavoured

Then there is

I have questions on these too (:

The JeOS question got answered

When originally writing this in 2019, I could not figure out what JeOS was.

Now I know it is supposed to be pronounced as juice and is meant to have “Just enough Operating System” to get a base system working:

For Raspberry Pi 2, this was the image to use mid 2020 via [Wayback] HCL:Raspberry Pi2 – openSUSE Wiki and [Wayback] http://download.opensuse.org/ports/armv7hl/tumbleweed/images/:

The OpenQA shows the global build state, but not specific to Raspberry Pi models: [Wayback] https://openqa.opensuse.org/group_overview/3

–jeroen

Read the rest of this entry »

Posted in *nix, *nix-tools, Linux, openSuSE, Power User, SuSE Linux, Tumbleweed | Leave a Comment »

Need to do some catch up on “Transactional Server” from Open Suse

Posted by jpluimers on 2021/05/28

Transactional Server to me smells like Microsoft data warehouse era, so seeing it in an OpenSuSE Tumbleweed install made me wonder: huh, DBMS?

So I likely need some catch up to do do on this:

Apparently “Transactional Server” is an installation type similar to “Server”, which can upgrade without touching a running system.

So how can the system then run with the updates applied?

The answer seems to be “reboot”.

This is contrary to a lot of update changes in the past (that seems to be towards “update the running system, even allow for live kernel patching” with optional before/after snapshots.

It immediately associates with “immutability”, and likely containers.

Hopefully I’m right, but I still have questions, like:

Until I have more time, these are on my reading list:

--jeroen

Read the rest of this entry »

Posted in *nix, Linux, openSuSE, Power User, SuSE Linux, Tumbleweed | Leave a Comment »

How to Copy files between ESXi hosts using SCP Command

Posted by jpluimers on 2021/05/21

Derived the bits below from [WayBack] How to Copy files between ESXi hosts using SCP Command.

Recursive copy from a remote machine to an existing local directory:

scp -rp root@192.168.71.97://vmfs/volumes/EVO860_500GB/VM1/ /vmfs/volumes/EVO860_250GB/VM2/

After this you need to edit the .vmxf files in the VM2 directory to ensure these are not duplicates.

One thing to remember is that you need the current host to allow the SSH client in the firewall, which is disabled by default:

After enabling:

Be really careful with the -3 option to scp; it allows you to transfer from one remote machine to another remote machine, but when using keyboard-interactive, you have a high change to lock-out your accounts: SSH will try to keyboard-interactive to both hosts at the same time.

If you lock-out root, then you have to go through the local DCUI console (use ALT-F2 to go there), then reset the root account failure count using pam_tally2 --user root --reset.

So this can be bad:

scp -3 -rp root@192.168.71.97://vmfs/volumes/EVO860_500GB/VM1/ root@192.168.71.91://vmfs/volumes/EVO860_250GB/VM2/

This works, but assumes the SSH client is enabled from the first host:

scp -rp root@192.168.71.97://vmfs/volumes/EVO860_500GB/VM1/ root@192.168.71.91://vmfs/volumes/EVO860_250GB/VM2/

See these links:

 

[root@ESXi-X9SRI-F:~] esxcli network firewall get
   Default Action: DROP
   Enabled: true
   Loaded: true
[root@ESXi-X9SRI-F:~] esxcli network firewall ruleset list --ruleset-id sshClient
Name       Enabled
---------  -------
sshClient    false
[root@ESXi-X9SRI-F:~] esxcli network firewall ruleset set --ruleset-id sshClient --enabled true
[root@ESXi-X9SRI-F:~] esxcli network firewall ruleset list --ruleset-id sshClient
Name       Enabled
---------  -------
sshClient     true
[root@ESXi-X9SRI-F:~] esxcli network firewall ruleset set --ruleset-id sshClient --enabled false
[root@ESXi-X9SRI-F:~] esxcli network firewall ruleset list --ruleset-id sshClient
Name       Enabled
---------  -------
sshClient    false

–jeroen

Posted in *nix, *nix-tools, ESXi6, ESXi6.5, ESXi6.7, Power User, ssh/sshd, Virtualization, VMware, VMware ESXi | Leave a Comment »

NFS server on Windows

Posted by jpluimers on 2021/05/14

One way to access files from ESXi is over NFS shares.

Out of the box, Windows Server is the only edition that provides NFS server capability, but desktop editions only have an NFS client.

There are some commercial and open sources implementations though, of which [WayBack] GitHub – winnfsd/winnfsd seems the best maintained open source one.

In case I ever need NFS server support, I need to check out these links:

–jeroen

Posted in *nix, Power User, Virtualization, VMware, VMware ESXi, Windows | Leave a Comment »

ESXi: where are my log files actually stored? Actually, most of them are in `/scratch/log` which points to a hidden `.locker` directory in a datastore.

Posted by jpluimers on 2021/05/05

A summary of the full gist at [Wayback/Archive.is] ESXi-where-are-my-log-files-stored.txt:

# ls -al / /var/ /var/log/ /var/run/ /scratch/ /scratch/log/ | grep "/\|log\|-\>"
/:
...
lrwxrwxrwx    1 root     root            57 Apr  4 18:16 scratch -> /vmfs/volumes/5ce2d440-72311161-75c5-0025907d9d5c/.locker
...
/scratch/:
drwxr-xr-x    1 root     root        106496 Apr 10 08:40 log
/scratch/log/:
-rw-------    1 root     root           411 Apr  4 18:20 Xorg.log
...
-rw-------    1 root     root         78835 Apr  4 10:30 syslog.0.gz
-rw-------    1 root     root         61136 Mar 18 15:05 syslog.1.gz
-rw-------    1 root     root         60589 Feb 24 00:30 syslog.2.gz
-rw-------    1 root     root         60373 Feb  1 08:01 syslog.3.gz
-rw-------    1 root     root         60203 Jan  9 15:50 syslog.4.gz
-rw-------    1 root     root         59889 Dec 17 23:20 syslog.5.gz
-rw-------    1 root     root         60398 Nov 25 06:50 syslog.6.gz
-rw-------    1 root     root         60563 Nov  2 14:25 syslog.7.gz
-rw-------    1 root     root        531794 Apr 10 09:35 syslog.log
...
-rw-------    1 root     root        157255 Apr  4 18:17 vvold.log
/var/:
...
drwxr-xr-x    1 root     root           512 Apr  5 19:19 log
...
/var/log/:
-rw-r--r--    1 root     root           416 Apr  4 18:16 .vmsyslogd.err
...
-rw-r--r--    1 root     root         38069 Apr  4 18:20 configRP.log
-rw-r--r--    1 root     root             0 Apr  4 18:16 cryptoloader.log
...
-rw-r--r--    1 root     root            87 Apr  5 21:57 esxcli.log
...
-rw-------    1 root     root          3350 Apr  4 18:16 init.log
-rw-r--r--    1 root     root           966 Apr  4 18:16 iofilter-init.log
...
-rw-r--r--    1 root     root         21769 Apr  4 18:16 jumpstart-esxcli-stdout.log
-rw-r--r--    1 root     root         18857 Apr  4 18:16 jumpstart-native-stdout.log
-rw-r--r--    1 root     root         10837 Apr  4 18:16 jumpstart-stdout.log
-rw-r--r--    1 root     root             0 Apr  4 18:16 kickstart.log
...
-rw-------    1 root     root         10916 Apr  4 18:16 sysboot.log
...
-rw-------    1 root     root            64 Apr 10 09:13 tallylog
...
/var/run/:
lrwxrwxrwx    1 root     root            12 Apr  4 18:16 log -> /scratch/log
  • Almost all log files (most from /var/log and all from /var/run/log) are actually persistently stored in /scratch/log and survive reboots. Just a few are non-persistent.
  • /var/log/syslog is being archived as .gz files (compressed by gzip).
  • syslog is special: the location can be configured, and even be external: [Wayback] Configuring syslog on ESXi (2003322)

    VMware vSphere ESXi 5.0 and higher hosts run a Syslog service (vmsyslogd) that provides a standard mechanism for logging messages from the VMkernel and other system components. By default in ESXi, these logs are placed on a local scratch volume or a ramdisk. To preserve the logs further, ESXi can be configured to place these logs to an alternate storage location on disk and to send the logs across the network to a Syslog server.

  • A summary of some of the above log files is at [Wayback] ESXi Log File Locations

–jeroen

Posted in *nix, *nix-tools, ash/dash, ash/dash development, BusyBox, Development, ESXi6, ESXi6.5, ESXi6.7, ESXi7, gzip, Power User, Scripting, Software Development, Virtualization, VMware, VMware ESXi | Leave a Comment »

Running ArchiveTeam Warrior version 3.2 on ESXi

Posted by jpluimers on 2021/05/05

A while ago I wrote about Helping the WayBack ArchiveTeam team: running their Warrior virtual appliance on ESXi.

Since it was scheduled before my cancer treatment started and got posted when still recovering from it, I missed that version 3.2 of the [Wayback] ArchiveTeam Warrior appliance appeared in the [Wayback] Releases · ArchiveTeam/Ubuntu-Warrior at [Wayback] Release v3.2 · ArchiveTeam/Ubuntu-Warrior. You can download it form these places:

These two sites have not yet been updated, so they contain the older versions:

The source code now has been moved three times:

Read the rest of this entry »

Posted in *nix, *nix-tools, ArchiveTeamWarrior, Cloud, Containers, diff, Docker, ESXi5, ESXi5.1, ESXi5.5, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Infrastructure, Internet, InternetArchive, Kubernetes (k8n), KVM Kernel-based Virtual Machine, patch, Power User, VirtualBox, Virtualization, VMware, VMware ESXi, VMware Workstation, WayBack machine | Leave a Comment »

« Previous Entries
Next Entries »