Fedora 31 / Rawhide in Windows Subsystem For Linux

So you want to do Fedora stuff without the hardware headaches and all the vitualization crap? 

Well it's finally possible in Windows 10 to run Fedora 31 or even Rawhide (currently 32).

Here's what you need:

1. Update Windows 10 Pro to the latest. Reboot ad nauseum as required.

2. Enable the Windows Subsystem for Linux (WSL) if not already turned on. I used this guide. Reboot again.

3. Open the Microsoft Store and search for Fedora Remix for WSL. It was $5 when I bought it today - figured that was a small price to pay to avoid Alpine, Ubuntu and Debian WSL variants. Shoutout to Whitewater Foundry for the sale price. 

4. Launch the new app from Start > Apps > Fedora Remix for WSL

5. This is where things got a bit ... unexpectedly annoying, but I did finally resolve my issue.

6. At the command prompt, run these commands:

sudo su
dnf update -y

Then I tried to install more stuff...

dnf install -y buildah podman

... but that's when things went sideways:

RPM: error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch

7. After much googling, experimenting with db cache recovery, and learning way more low level rpm db commands than I ever wanted, I found a simple solution:

rm -f /var/lib/.rpm.lock

But somewhere along the way I had tried switching to Rawhide (didn't help!), so to go back to Fedora 31, I did this:

# see current release version at 32
cat /etc/*release 

# enable/disable repos by hand - no rawhide, only fedora.
cd /etc/yum.repos.d/; vim *.repo 

# out with the new, in with the old
yum remove generic-release

# re-enable any .repo files that were disabled by the uninstall of Fedora 32
for d in fedora*.rpmsave; do mv $d ${d/.rpmsave}; done

# reinstall removed packages
dnf history info $(dnf history | grep generic-release | grep Removed | \
  sed -e "s#[ ]*\([0-9]\+\) | remove.\+#\1#")

# determine which packages were removed
dnf history info $(dnf history | grep generic-release | grep Removed | \
  sed -e "s#[ ]*\([0-9]\+\) | remove.\+#\1#") | grep Removed | \
  grep @@System | sed -e "s#[ ]*Removed \(.\+\).\(noarch\|fc.\+\).*#\1#"

# reinstall them
yum install --releasever=31 audit fedora-gpg-keys fedora-repos fedora-repos-rawhide \
  generic-release generic-release-common initscripts setup shadow-utils  

# verify back to 31
cat /etc/*release 

9. Back in business, can now install without dnf errors from fc31 packages.

dnf -y install buildah podman
dnf -y install hub
dnf -y install python jq pip
...

10. Aside: to get a list of all the things you've installed in your Fedora machine, you can run:

for i in $(dnf history | grep -v "Altered" | grep install | \
  sed -e "s#[\t ]\+\([0-9]\+\)[\t ]\+|.\+#\1#" | tac); do
    dnf history info $i | grep Command | \
      sed -e "s#.\+ : #dnf -y #";
done

Next up... experimenting with an X server to do Fedora GUI apps inside Windows (without the need for VirtualBox 6.1, which seems to be much tetchier than 6.0 for multi-monitor support).

Configuring CodeReady Workspaces 2.0 w/ Microsoft Active Directory user authentication

To use Microsoft Active Directory logins with CodeReady Workspaces, first deploy
it to your OpenShift cluster. For Workspaces 2.0, OCP 4.2 is recommended (4.1
and 3.11 are also supported).

Once your deployment is started, sign in using the RH SSO:

Select the “User Federation”:

Select “LDAP” for the external source:

Fill out the LDAP mandatory information and save it (DO NOT sync the users yet).

The value of Username LDAP attribute should match the value used below for LDAP Attribute.

Once saved, go the mapper:

In the list of LDAP attributes, remap the following two attributes:

Set LDAP attribute to “sAMAccountName”, to match the value set above for Username LDAP attribute:

Save your changes.

Next, update the email mapper if needed (eg., set LDAP Attribute to “userPrincipalName” to store the user's email address:

Again, save your changes.

Go back to the “setting” tab to sync users:

That's it! Now you can use Active Directory user logins in CodeReady Workspaces 2.

Force Chrome to use hardware acceleration (performance enhancement under virtual box 6)

Moving to Fedora 31 on Virtual Box 6.1

Last week I got a new Thinkpad T490s, and to celebrate I grabbed the latest Windows 10 Pro updates, installed Virtual Box 6.1, and set up a new Fedora 31 VM. 

Everything was pretty smooth right out of the box but for two problems:

1. guest OS in Seamless mode slides UNDER Window's taskbar.

2. Chrome 79.0.3945.117 (Official Build) (64-bit) performance was insanely sluggish and unusable inside the VM.

Still working on a fix for the first one, other than to hide the Windows taskbar when working on a single screen, and to assign my VM's xfce4-panel to run on a different pimary monitor by default than Windows' primary monitor (so they don't overlap). 

But for the second issue, I found this solution - forcing my VM's Chrome to use hardware acceleration, by turning on a setting under chrome://flags:

And like that, voom. Chrome is responsive and useable again!

Deploying Che 7 with custom images (air gap environment)

Number 5: deploying Che 7 behind a firewall (air gap environment) using 

chectl --che-operator-cr-yaml=...

Deploying Che 7 with custom images

Unlike Deploying Che 7 to Minishift 1.34+, this doc will explain how to do an Eclipse Che 7 deployment with a custom resource yaml file to override the images used in the deployment.

This process can be used for many things, but in this example it’ll be in support of an air gap environment, where an organization cannot directly see Quay or Red Hat Container Catalog, and must instead reference internally mirrored artifacts within their organization’s firewall.

Prerequisites

You need the latest Minishift and chectl releases.

Fetch them like this (or similar):

cd ~/bin
curl -sSL https://github.com/che-incubator/chectl/releases/download/20190724230954/chectl-linux -o chectl
chmod +x chectl

cd /tmp
curl -sSL https://github.com/minishift/minishift/releases/download/v1.34.1/minishift-1.34.1-linux-amd64.tgz -o minishift.tgz
tar xvzf minishift.tgz
mv minishift*/minishift ~/bin/
chmod +x ~/bin/minishift

Procedure

1. Start up minishift. (See Start up Minishift for some suggested default settings.)

   minishift start

2. Log in once startup is complete.

   oc login 192.168.MY.IP:8433 -u system -p admin

3. For Eclipse Che 7, pull these images and publish them to your internal registry:
   • eclipse/che-server:nightly
   • eclipse/che-keycloak:nightly
   • quay.io/eclipse/che-devfile-registry:nightly
   • quay.io/eclipse/che-plugin-registry:nightly
   • centos/postgresql-96-centos7:latest
   • registry.access.redhat.com/ubi8-minimal:8.0
4. Create a custom resource file, which overrides the default image values from che-operator defaults.go to use your custom registry’s images.

   NOTE	To watch the events and verify which images are pulled, see this post before performing the next step.

5. Deploy Che to minishift using the custom resource file created above. In this example the namespace che-op is used instead of the default che:

   chectl server:start -a operator -p minishift \
     --che-operator-cr-yaml=che7-custom-resource-airgap.yaml -n che-op

   NOTE	If you use the minishift addon to deploy Che (which uses a deployment configuration instead of an operator), your custom resource file will not be used. The addon is deprecated.

6. You should see this:
   
   
   
7. Once deployed, you should see these in your Minishift console:
8. The custom image reference can be seen in the yaml for the deployment:
   
   

Configuring Minishift for use with Eclipse Che and Red Hat CodeReady Workspaces

Number 4 in my Che series... a quick guide for using Minishift, in order to test drive Che 7 or Red Hat CodeReady Workspaces.

If you're not running Windows as your host OS, your mileage may vary in terms of memory requirements and preferred virtual machine driver, but the suggestions below should work on most OSes... even the one with an incomplete sed implementation.

Get Minishift and oc

Download and unpack the latest minishift v1.34.1 binary from here:

https://github.com/minishift/minishift/releases

You’ll also want the Openshift Origin Client Tools (oc) 4 or 3.11 from:

• https://mirror.openshift.com/pub/openshift-v4/clients/ocp/
• https://mirror.openshift.com/pub/openshift-v3/clients/

Once downloaded and unpacked, put the minishift and oc executables in your ~/bin or some other folder that’s on your PATH.

Configure Minishift

On Windows, I use Git bash shell for most shell commands.

# To prevent rate limiting when starting minishift, use a personal 
# access token.
# You can create new one at https://github.com/settings/tokens
export MINISHIFT_GITHUB_API_TOKEN="f00cafebabel33t"

# Grant enough memory to run CRW 1.2 / Che 6 and workspaces
# 6G min for one workspace, plus 2G for each additional workspace
minishift config set memory 12G

# Grant enough disk for downloading container images
minishift config set disk-size 25G

# if not using default virtualization engine, eg., want Virtual Box, use
minishift config set vm-driver virtualbox

# enable cluster admin user
minishift addons install --defaults
minishift addons enable admin-user

On Windows, you might need to touch a file that your shell can’t find.

touch /c/Users/YOUR_LOGIN_HERE/.minishift/machines/minishift_kubeconfig

Note	If it fails with error Checking if requested OpenShift version 'v3.11.0' is valid …​ v3.11.0 is not a valid OpenShift versionFAIL, try WSL bash.

# start minishift oc cluster
minishift start

Once minishift starts successfully, you’re ready to deploy Che or CRW to the server.

If minishift fails to come up, try killing and starting it again:

minishift stop
minishift start

Or delete it and try again:

minishift stop
minishift delete
minishift start

When successful, you should see something like this (use your actual IP address in place of 192.168.$YOUR_IP):

OpenShift server started.

The server is accessible via web console at:
    https://192.168.$YOUR_IP:8443/console

You can log into the above console URL using the special user = system:admin - full cluster admin privileges required to deploy an operator:

oc login 192.168.$YOUR_IP:8443 -u system:admin

If you prefer to use a different user, you can grant that user cluster admin privileges:

oc adm policy --as=system:admin add-cluster-role-to-user cluster-admin admin # for admin user
oc adm policy --as=system:admin add-cluster-role-to-user cluster-admin developer # for developer user

Deploy something!

If you want to install CodeReady Workspaces 1.2, download the Operator Installer from here:

• https://developers.redhat.com/products/codeready-workspaces/download

Set up your authentication with the new Red Hat Container Catalog's registry, registry.redhat.io:

• https://access.redhat.com/RegistryAuthentication#using-authentication-3

Run the installation as follows:

./deploy.sh -d

Or, if you'd like to install Che 7, see Deploying Che 7 to Minishift.

You can also use the built-in Che add-on in Minishift, but that approach is deprecated. Enable it as follows:

minishift addons enable che; minishift addons apply \
  --addon-env CHE_DOCKER_IMAGE=eclipse/che-server:nightly \
  --addon-env OPENSHIFT_TOKEN=$(oc whoami -t) che

# switch to Che 7.0.0.RC3 plugin registry format (fixed in minishift v1.34.1) 
# see https://github.com/minishift/minishift/commit/4c0a0c0b9cfb92798fef53e5c54e80ca71c5f715
minishift --profile che addons apply --addon-env PLUGIN__REGISTRY__URL=https://che-plugin-registry.openshift.io/v3 che

Third in this series... how to create and deploy your own custom devfile registry, so you can include your own stacks out of the box inside Che 7.

Creating your own devfile registry

Prerequisites

You need a Kubernetes or OpenShift cluster (eg., minikube or minishift), into which you have installed Che. Follow the steps in this document to deploy Che.

Steps below can then be done to deploy a custom devfile registry to your cluster, and use it with Che.

Procedure

1. Check out https://github.com/eclipse/che-devfile-registry/

   git clone https://github.com/eclipse/che-devfile-registry/
   cd che-devfile-registry

2. Make changes in the devfiles/ folder to add new or remove existing devfile folders from the registry.
3. Build the image.

   This example uses a personal quay repository and an arbitrary tag ubi8-2, but you can use another image registry and path as needed.

   docker build . -f Dockerfile --no-cache \
     -t quay.io/nickboldt/che-devfile-registry:ubi8-2

4. Push it to quay (or your image registry of choice)

   docker push quay.io/nickboldt/che-devfile-registry:ubi8-2

   Verify the image and tag you pushed are published, eg., https://quay.io/repository/nickboldt/che-devfile-registry?tab=tags Verify the Repository Visibility is public, eg., https://quay.io/repository/nickboldt/che-devfile-registry?tab=settings

5. Remove any existing che-devfile-registry deployments.

   oc delete dc che-devfile-registry; \
   oc delete svc che-devfile-registry; \
   oc delete route che-devfile-registry; \
   sleep 5s

6. Deploy the new che-devfile-registry.

   oc new-app -f deploy/openshift/che-devfile-registry.yaml \
     -p PULL_POLICY="Always" \
     -p IMAGE="quay.io/nickboldt/che-devfile-registry" \
     -p IMAGE_TAG="ubi8-2"; \
   sleep 5s

    
7. You can browse the registry’s devfiles/index.json file to verify your new devfile is included.
   
8. Update your config map to point to the new registry.

   oc set env dc/che CHE_WORKSPACE_DEVFILE__REGISTRY__URL=http://che-devfile-registry-che.192.168.99.112.nip.io/

   
9. Check your Che deployment to see if the changes are live by creating a new workspace from your devfile registry:

• http://che-che.192.168.99.112.nip.io/dashboard/#/create-workspace

Second in this series... more tips for Che 7 on Minishift.

Discovering containers loaded by Che 7

Prerequisites

You need a Kubernetes or OpenShift cluster (eg., minikube or minishift), into which you have installed Che.

Follow the steps in this document to deploy Che. Steps below can be done in parallel to collect a list of containers involved in deployment.

Procedure

1. Once you have started your cluster, you can watch events and see which images are pulled. Start this in a console window before deploying Che to your cluster.

   oc project che
   oc get po
   oc get events -w | tee /tmp/minishift.log.txt

2. Watch for lines containing the following lines to see what containers are pulled.

   Successfully pulled image "..."
     and
   Container image "..." already present on machine

3. For example, this should extract just a list of pulled containers, including any duplicate re-pulls:

   cat /tmp/minishift.log.txt | \
     egrep "Successfully pulled image|Container image" | \
     sed -e 's#.*\(Successfully pulled image\|Container image\) "\(.\+\)\".*#\2#g'

4. You can also look at the available images in the minishift docker context:

   eval $(minishift docker-env)
   docker images

5. Next, using chectl, deploy Che to your cluster and watch the events get logged.
6. You can also see container events at this URL:
   • https://192.168.YOUR.IP:8443/console/project/che/browse/events