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 4,226 other subscribers

Archive for May, 2021

« Previous Entries

Fritz!Box repeater and other devices: “Radar detection enabled. At the moment no wireless LAN connection (5 GHz) is possible; please wait.”

Posted by jpluimers on 2021/05/31

If any of your Fritz!Box devices under “Wireless” -> “Radio Channel” -> “5-GHz band”  the indicates “Radar detection enabled. At the moment no wireless LAN connection (5 GHz) is possible; please wait.” – Google Search:

  1. Click on the “Refresh Auto Channel” button
  2. Wait until it has chosen a new 5Ghz channel
  3. Verify you can connect over 5Ghz
  4. If you still cannot connect, retry steps 1…3 once.

I had this only happen on 1750E repeaters so far, but others seem to have had it on other Fritz!Box devices as well.

In the Netherlands, potentially affected channels seem to be 52 through 140.

Related:

–jeroen

Posted in Fritz!, Fritz!Box, Fritz!WLAN, Internet, Power User | Leave a Comment »

E46 fuse box and cigarette lighter connection when front has VDO navigation installed

Posted by jpluimers on 2021/05/31

Some links (mostly in German) about E46 fuse box, and cigarette lighter connections (in my case: there was a VDO Dayton navigation in the normal place of the cigarette lighter in the front):

–jeroen

Read the rest of this entry »

Posted in cars, E46 330xd touring BMW, LifeHacker, Power User | 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 »

« Previous Entries
 
%d bloggers like this: