Samstag, 1. Juni 2019

Migration of a Postgresql database in OpenShift

I'm working with an OpenShift 3.11 HA cluster where I deployed a Red Hat Single Sign On Application for authorization using a template of the catalouge. This template create a single Pod for the SSO and another one for a Postgresql 9.5 database to get the data persistent.
After collecting some experience with this application I decided to deploy a new one which should be redundant and each Pod should be schedule on a different node. So I would like to migrate the data from the Postgresql database of the first application.

I found following workaround which works for me. The way to it I describe at the bottom of this article ;-)

Ok, let's start:
Let's say we have the following Pods:
old Postgresql Pod: sso-postgresql
new Postgresql Pod: sso-new-postgresql
name of the database: root
user of the database: user1

First we have to create a custom dump from the Postgresql database which hosts the data:

oc rsh sso-postgresql

sh-4.2$ mkdir tmp
sh-4.2$ cd tmp
sh-4.2$ pg_dump -Fc root > db.dump
sh-4.2$ exit
oc rsync sso-postgresql:/opet/app-root/src/tmp </local/path>

Then we switch to the actual project in OpenShift and sync the Postgresql dump into the new Postgresql Pod. By the way, this Pod has to be created with the same database name and credentials like the ole one

oc project sso-new
oc rsync <local/path> sso-new-postgresql:/var/lib/pgsql/data/

The output of this command will look like this:

sending incremental file list

./

db.dump



sent 306,145 bytes received 131 bytes 204,184.00 bytes/sec

total size is 305,961 speedup is 1.00

rsync: failed to set permissions on "/var/lib/pgsql/data/.": Operation not permitted (1)

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2]

error: exit status 23

The error has no meaning for us, so we can go further

Now you have to pause all Pods with a connection to the new database

oc resume pause dc <Pods>

For the next steps we log in the new Postgresql Pod

oc rsh sso-new-postgresql

sh-4.2$ cd /var/lib/pgsql/data
Check that the db.dump is there

Now we enter the workaround cause a normal restore didn't worked for me:


sh-4.2$ psql --list

List of databases

Name | Owner | Encoding | Collate | Ctype | Access privileges

-----------+----------+----------+------------+------------+-----------------------

postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 |

root | user1 | UTF8 | en_US.utf8 | en_US.utf8 |

template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +

| | | | | postgres=CTc/postgres

template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres +

| | | | | postgres=CTc/postgres

(4 rows)

Delete the database root
sh-4.2$ dropdb -U user1 root

Then create a new one 

sh-4.2$ createdb -O user1 root

Check if this new database is empty:

sh-4.2$ psql root_entw

psql (9.5.14)

Type "help" for help.



root_entw=# \dt

No relations found.

root_entw=# \q

Then make the restore in this new database:

sh-4.2$ pg_restore -d root_entw -U userv1c --clean --if-exists --create db_c.dump

pg_restore: [archiver (db)] Error while PROCESSING TOC:

pg_restore: [archiver (db)] Error from TOC entry 3309; 1262 16385 DATABASE root_entw userv1c

pg_restore: [archiver (db)] could not execute query: ERROR: cannot drop the currently open database

Command was: DROP DATABASE IF EXISTS root_entw;



pg_restore: [archiver (db)] could not execute query: ERROR: permission denied to create database

Command was: CREATE DATABASE root_entw WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.utf8' LC_CTYPE = 'en_US.utf8';







pg_restore: [archiver (db)] Error from TOC entry 3312; 0 0 COMMENT EXTENSION plpgsql

pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql

Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';







pg_restore: WARNING: no privileges could be revoked for "public"

pg_restore: WARNING: no privileges could be revoked for "public"

pg_restore: WARNING: no privileges were granted for "public"

pg_restore: WARNING: no privileges were granted for "public"

WARNING: errors ignored on restore: 3


Ignore the errors ;-)

Check the database for the tables

sh-4.2$ psql root_entw

psql (9.5.14)

Type "help" for help.



root_entw=# \dt

List of relations

Schema | Name | Type | Owner

--------+-------------------------------+-------+---------

public | admin_event_entity | table | userv1c

public | associated_policy | table | userv1c

public | authentication_execution | table | userv1c

public | authentication_flow | table | userv1c

public | authenticator_config | table | userv1c

public | authenticator_config_entry | table | userv1c

public | broker_link | table | userv1c

public | client | table | userv1c

public | client_attributes | table | userv1c

public | client_auth_flow_bindings | table | userv1c

public | client_default_roles | table | userv1c

public | client_initial_access | table | userv1c

public | client_node_registrations | table | userv1c

public | client_scope | table | userv1c

public | client_scope_attributes | table | userv1c

public | client_scope_client | table | userv1c

public | client_scope_role_mapping | table | userv1c

public | client_session | table | userv1c

public | client_session_auth_status | table | userv1c

public | client_session_note | table | userv1c


root_entw=# \q



Exit the Pod

sh-4.2$ exit

Resume the related Pods

After the Pods are started, check if the data is available for the Pods 

That's it!!!

-----------------------------------------------------------------------------------------------------------
So... what was the way to here??? (a long and winding road ;-))

First I tried to make a snapshot of the pvc of the postgresql Pod. But unfortunatly the plugin I'm using doesn't support pvc snapshots

Then I tried to make a full and a partial dump of the old Postgresql database and restore the dump in the new one. I tried

pg_dump root | gzip > /opt/app-root/src/tmp /sso-postgresql.gz
pg_dumpall

and in the new Postgresql Pod

psql root < /var/lib/pgsql/data/sso-postgreql

That produce only a lot of errors, but no new data in my database

Then I found a tip that pg_restore works better with a custom dump format. So I created a cutom dum and tried the direct restore in the new Pod (see documentation of Postgresql https://www.postgresql.org/docs/9.5/app-pgrestore.html)
But again... only errors and no expected data

After many experiments (and learned a lot how to act with Postgresql) suddenly it works... I tried to figure out what I've done in my experiments ans recogniszed, that I once deleted the first database. I deleted it to make a pg_restore expecting the restore would also create the database new. But this didn't happened. So I created the database new. But I forgotten bevore deleting the database to notice which tables are inside (shit). And so I tried again the restore, but I only say the errors thinking the restore was not succesful. But after leaving the pod and check the data in the application -surprise- the data was there.

I was using this workaround many times, and every time it was a success.

If someone outside there has a better idea to realize such a migration, please tell me... I'm more an OpenShift specialist than a Postgresql master... 









Montag, 6. Mai 2019

Deja Dup Probleme Ubuntu 16.04 nach 18.04

Nachdem ich mein System mit Ubuntu 18.04 neu aufgesetzt hatte, wollte ich meine Daten aus meinem vorhandenen Backup, welches ich mit DejaDup unter Ubuntu 16.04 erzeugt hatte, wieder einspielen.
Zu meinem Entzetzen musste ich feststellen, dass DejaDup unter 18.04 die Daten nicht mehr erkannte. Bei der Wiederherstellung kam es immer wieder zu Fehlermeldungen und dem Abbruch der Wiederherstellung.

Auf meiner Suche nach der Lösung versuchte ich es mit Hinweisen wie unter
https://wiki.ubuntuusers.de/Deja_Dup/ die mich leider nicht weiter brachten, da sie für mich nicht funktionierten.

Die Lösung war dann, eine VM mit Ubuntu 16.04 zu erzeugen, die einen Austausch Ordner mit dem Gastsystem unterhält.

Innerhalb der VM habe ich mit DejaDup dann einzelne Ordner wieder hergestellt. Hat man genügend Speicher zur Verfügung, kann man auch das ganze Backup wiederherstellen, was für meinen Fall jedoch nicht möglich war.

Um nun einzelne Ordner oder Dateien wieder herstellen zu können, öffnet man den Dateimanager Nautilus unter Ubuntu 16.04, wechselt in den Ordner, in der die Daten ursprünglich lagen und ruft mit der rechten Maustaste das Kontextmenü auf. Dort gibt es einen Menüpunkt "Fehlende Dateien wiederherstellen".

Nachdem dieser ausgewählt wurde, erscheint Fenster von DejaDup, welches auffordert, dass Backup auszuwählen, aus welchem wieder hergestellt werden soll. Danach startet DejaDup den Einlesevorgang, der etwas Zeit in Anspruch nehmen kann.

In der Liste, die nach Beendigung des Einlesevorgangs zu sehen ist, können die Dateien und Ordner ausgewählt werden, die wiederhergestellt werden sollen. Et voilá... Danach stehen die Dateien wieder zur Verfügung und können über den Austausch Ordner auf das Gast-System gezogen werden.

Ach ja: Über eine Besonderheit bin ich noch gestolpert! Möchte man Dateien z.B. aus dem Download Ordner wiederherstellen, wird man beim ersten Versuch feststellen, dass der Eintrag "Fehlende Dateien wiederherstellen" im Kontextmenü nicht zu sehen ist. Die Lösung hierfür liegt darin, dass das DejaDup auf dem System noch nicht konfiguriert wurde und in der Standard-Konfiguration von DejaDup der Download-Ordner in der Liste der zu ignorierenden Ordnern enthalten ist. Löscht man aus dieser Liste den Download-Ordner raus und fügt ihn in die Liste der zu sichernden Ordner ein, so erscheint im Kontextmenü nun auch der Eintrag zum wiederherstellen der Dateien

Donnerstag, 14. März 2019

kubectl für entfernten Minikube einrichten

Herausforderung
Auf meinem lokalen Rechner habe ich einen minikube installiert und gestartet. Aus einer VM heraus, möchte ich auf den minikube mit kubectl zugreifen

Thematik:
Wie informiere ich kubectl darüber, wo sich der minikube befindet?

Lösung:
  • Anlegen einer ~/.kube/config
  • Kopieren aller relevanten Zertifikate
Wird der minikube installiert und gestartet wird auf dem Hostsystem ein Verzeichnis ~/.kube angelegt. In diesem Verzeichnis wird wiederum die Datei "config" abgelegt, die alle notwendigen Daten für den Zugriff auf den minikube enthält.
Innerhalb der ~/.kube/config wird auf Zertifikate verwiesen, die bei der Installation des minikube unter ~./minikube abgelegt wurden.

Meine Lösung war nun folgende:

In der VM, die kubectl enthält:
$ mkdir ~/.kube
$ mkdir ~/.minikube

vom Host des minikube aus
$ scp ~/.kube/* user@remoteVm:/home/user/.kube/
$ scp ~/.minikube/* user@remoteVm:/home/user/.minikube/

In der VM:
$ sed -i 's/user_host/user_vm/g' ~/.kube/config

danach sollte ein
$kubectl cluster-info

ein Ergebnis zeigen

Der Host, wie auch die VM laufen mit Xubuntu 18.04

Update 2019-04-03

Möchte man auch mit Docker arbeiten, sollte der verwendete System-User noch der Gruppe "docker" hinzugefügt werden:
$ usermod -aG docker <user>



Sonntag, 15. Juli 2018

Resize a logical volume with Ansible with checks before

Situation:
My challenge is to check my nodes if the root directory has enough space and if not check if the volume group has also enough space to resize the logical volume.

Here is my Ansible code. I'm sure it's not perfect, but it works :-)

# Check nodes before Upgrade Cluster
---
- hosts: all
  become: True
  tasks:

    - name: Test disk space available
      assert:
        that:
         - item.mount != '/' or {{ item.mount == '/' and \
                   item.size_available > (item.size_total) }}
      with_items: '{{ ansible_mounts }}'
      ignore_errors: yes
      register: disk_free

    - name: Check VG for enough space
      assert:
        that:
          - item.key != '{{ VG }}' or {{ item.key == '{{ VG }}' \
                   and item.value.free_g > 1.00 }}
      with_dict: '{{ ansible_lvm.vgs }}'
      register: vg_free
      ignore_errors: yes
      when: disk_free is failed

    - name: resize lvROOT
      shell: lvresize -L +1G /dev/VG/lv && xfs_growfs /

      when: vg_free is succeeded

Freitag, 13. Juli 2018

Ansible unter Ubuntu 16.04

Installation Ansible:


$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible
$ ansible --version
   ansible 2.6.1
Um mit Ansible arbeiten zu können, die Hosts in die /etc/ansible/hosts eintragen, die angesprochen werden soll
Danach muss der ssh key des Ansible-Hosts auf die Ziel-Hosts kopiert werden
$ ssh-keygen
$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@zielsystem
Ich habe den ssh key meines normalen Users kopiert, und nicht den von root
Erster Test:
$ ansible all -m setup 
Im weiteren Verlauf:
Der Zugriff per Root wird doch benötigt... daher den Public Key doch noch rüber kopieren

Bug beim Auslesen der LVM Größen über setup
https://github.com/ansible/ansible/issues/33617

Mittwoch, 30. Mai 2018

Gasterweiterung unter VirtualBox Ubuntu Server 16.04 ohne Desktop

VirtualBox 5.2
VM: Ubuntu 16.04 ohne Desktop

Herausforderung: Gasterweiterung installieren

$sudo apt-get update
$sudo apt-get upgrade
$sudo apt-get install gcc make

Wenn notwendig restart

$mount /dev/cdrom /media/cdrom 
$/media/cdrom/VBoxLinuxAdditions.run 
reboot 

$sudo usermod --append --groups vboxsf USERNAME

Donnerstag, 3. Mai 2018

Get started with minishift on Ubuntu 16.04

I actually go through the course Fundamentals of Containers, Kubernetes, and Red Hat OpenShift 

For this course I need a minishift environment. 
My first try was to install a RHEL 7.4 on an older laptop (this is the recommendation in the course). Unfortanetly the laptop was to weak ;-)
Second try was to install it in a VM (on Virtualbox). But this doesn't work because you have to run a VirtualBox in a VirtualBox. And actually VirtualBox doesn't support the vmx flag inside a VM, so minishift doesn't work.
Third try was to make the exersices in the OpenShift 3.7 Playground on the platform learn.openshift.com. For the first exercises it works for me. But on the point working with a Dockerfile it ends.
So I search again for a solution to install minishift somewhere. In the documentation of minishift I recogniszed, that it can be installed on every Linux Distro. So I decided to try it on my productive laptop running with Ubuntu 16.04. 


  • download minishift for Linux
  • extract the tar file to a directory of your choice
  • add the directory to the PATH variable
  • and start minishift the first time :         $minishift start


First starting problem was, that the default hypervisor for Linux is KVM. On my system I have VirtualBox installed.

So I started minishift again with: $minishift start --vm-driver=virtualbox

and here we are, minishift is running!!!!

Then I try to build a new docker image with a RHEL7.3 base image. The first run command in the dockerfile is yum update -y. After starting docker build the system told me, that I haven't got a valid subscription. Big problem, if you want to install something inside this image.

But there is a easy solution (I love dockerfiles): I added simply in the dockerfile:

subscription-manager register --username admin-example --password secret --auto-attach

(of course with my personal credentials ;-). You need a RedHat developer account)

start the docker build command again... and it works :-)

To run minishift permanently with VirtualBox as vm-driver there are following steps necessary:
If you have already started minishift:
1. Stop minishift                           $minshift stop
2. Delete minishift configuration: $minishift delete

If you haven't started minishift for the first time and also for the "deleted" minishift then

$minishift config set vm-driver virtualbox (no "=" between vm-driver and virtualbox, that doesn't work)

Another topic is the user for minishift. Before starting minishift the first time create a permanent minishift user in the ~/.bashrc:

export MINISHIFT_USERNAME=myusername

export MINISHIFT_PASSWORD=mypassword

After both configuration for user and hypervisor environment are done, start the minishift cluster the first time with

$minishift start

It takes some time :-)

After my first try to login to the minishift cluster with the oc login command, I always get the error message: "oc: command not found"
After some search I find the solution for my Ubuntu environment:

execute: $eval $(minishift oc-env)

After this command the oc command works fine 

Please also have a look to the minishift documentation