DivByZero.com

Much ado about scripting, Linux & Eclipse: card subject to change

2020-02-07

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).

2020-01-16

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.

2020-01-14

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!

2019-07-25

Deploying Che 7 with custom images (air gap environment)

2019-07-19

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:
You’ll also want the Openshift Origin Client Tools (oc) 4 or 3.11 from:

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:

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

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

2019-07-04

Creating your own devfile registry

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. 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.,
    Verify the Repository Visibility is public, eg.,
  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:

    2019-06-29

    Discovering containers loaded by Che 7

    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 chectldeploy 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