SQL Schema Dump erstellen und in neues Schema einspielen unter Oracle

Problem:
Ich habe ein Datenbank auf dem Oracle welche für die Entwicklung geclont werden soll

Lösung:
Über die Kommandozeile wird ein „Oracle Data Pump“ erstellt.
Ich melde mich als Systemuser an, erstelle ein Backup Directory und erstelle darin den Dump

sqlplus SYSTEM/oracle@ORCL
## Ab hier in SQLPLUS
SQL> desc DBA_DIRECTORIES
Name Null? Type
----------------------------------------- -------- ----------------------------
OWNER NOT NULL VARCHAR2(30)
DIRECTORY_NAME NOT NULL VARCHAR2(30)
DIRECTORY_PATH VARCHAR2(4000)

SQL> CREATE DIRECTORY tmp as '/home/oracle/EXPORTS' ;

Directory created.
SQL> exit
Disconnected from Oracle Database 11g
## Ab hier wieder in der Shell

# dieser Dump wird nun in /home/oracle/EXPORTS erstellt
expdp USER/PASS schemas=USER directory=tmp dumpfile=myDB.dmp logfile=myDB.log

Das Backup ist nun vom gewünschten Schema erstellt worden, nun wird der neue User erstellt und der Dump in ein neues Schema eingespielt. Wichtig ist hier das Remappen beim Importieren!!

sqlplus SYSTEM/oracle@ORCL
##Ab hier SQL Plus
SQL> CREATE USER TESTUSER IDENTIFIED BY TESTUSER;
SQL> GRANT CREATE SESSION TO TESTUSER;
SQL> exit
## Ab hier wieder in der Shell
impdp TESTUSER/TESTUSER schemas=USER directory=tmp dumpfile=myDB.dmp remap_schema=USER:TESTUSER

Das müsste es auch schon gewesen sein

Optische Datenrettung unter Windows

Bezugnehmend auf Optische Datenrettung unter Linux hier das Äquivalent aus der Windows-Welt.

Problem:

Ich habe mehrere CDs mit Daten. Leider sind die Datenträger in die Jahre gekommen und lassen sich nicht mehr fehlerfrei auslesen.

Lösung:

  • CLI-basiert

Hier hat sich das c’t-Tool h2cdimage bewährt. Das Tool liest optische Medien sektorweise aus und erstellt daraus ein ISO. Die Bedienung ist etwas knifflig, weil die passenden Parameter „erraten“ werden müssen, um auch das richtige Laufwerk zu treffen. Das Ganze ist aber im entsprechenden Readme.txt so gut erklärt, dass es hier nicht im Detail erläutert werden muss.

  • GUI-basiert

Wer lieber ein GUI-basiertes Tool einsetzt, dem sei Roadkil’s Unstoppable Copier empfohlen. Das Tool kopiert auf Dateisystem-Ebene, lässt sich dabei aber nicht durch Lesefehler beirren wie die Windows-Bordmittel. Bedienung selbsterklärend. Die Standard-Settings können beibehalten werden, zusätzlich empfehlen sich die Optionen „Unbeschädigte Dateien zuerst“ und „Logdatei aktivieren“, so lässt sich später nachvollziehen welche Dateien evtl. ausgelassen wurden. Desweiteren sollten die „Maximalen Wiederholungen“ auf einen sinnvollen Wert (z.B. 10) begrenzt werden. Mittels „Überspringen“-Button kann man zur Laufzeit problematische Dateien überspringen, falls sich der Auslesevorgang zu sehr in die Länge zieht.

Viel Erfolg!

Dropbox Installation und Updates unter Debian

Problem:
Ich möchte Dropbox unter Debian und Nautilus nutzen

Lösung:
Installation des Paketes „nautilus-dropbox“

Zuerst also als root….

apt-get install nautilus-dropbox # Installation incl. Abhängigkeiten
dropbox start -i #Download und Installation des Daemons - aber dann keine Kontodaten eingeben!

und nach dem Download als User dann:

dropbox start #hier trägt man seine Dropbox Daten ein

Von Zeit zu Zeit sollte man den Daemon updaten.
Zuerst beendet man als User Dropbox

dropbox stop

und das Update wird als root durchgeführt

dropbox update

und im Anschluss kann man als User wieder Dropbox starten

dropbox start

Done!

Eigenen SSH Key verwalten unter Linux

DSA/RSA Schlüssel sind eine praktische Sache zur Identifikation zB gegenüber eines GIT, SSH oder SFTP Servers. Die Nutzungsmöglichkeiten sind hier breit gefächert. Ich notiere hier nun mal das kleine 1mal1 der Schlüsselverwaltung, evtl kann es jemand gebrauchen.

Bzgl der Art des Keys kann jeder mal im Netz stöbern, es steht RSA und DSA (zusätzlich zur gewählten bit-Stärke) zur Wahl. Gerne wird mit der Schlüsselberechnung durch Quantencomputer argumentiert. Ich kenne niemanden mit einem QC, falls Ihr jemanden kennt, dann schreibt mir doch bitte.
Per Default wird jedenfalls (unter Wheezy) ein RSA Schlüssel generiert, das war nicht immer so. AFAIK lag das an der Patentierung (die wohl im Jahr 2000 ausgelaufen ist) von RSA.
Ich finde RSA gut – aber entscheidet selbst was Ihr nutzen möchtet!

Das Tool „ssh-keygen“ kommt hier zum Einsatz, es ist zur Erzeugung und zum Management der Schlüssel zu gebrauchen und steckt im Paket „openssh-client“.

Der private Schlüssel kann mit einem Kommentar (-C „Kommentar“) bestückt werden, dieser ist nach Schlüsselerzeugung nicht mehr abänderbar!!
Der öffentliche Schlüssel hingegen kann abgeändert werden, dort steht der Kommentar im Klartext am Ende des Schlüssels. Ohne Kommentarangabe lautet der Kommentar username@machine

Bei jeder der folgenden Aktionen kann ein -f /pfad/zum/schluesselname.key hinzugefügt werden, dann fällt die Abfrage nach dem Schlüsselnamen weg. Wer mehrere Schlüssel pflegen muss, wird darauf angewiesen sein.

Ach, nur dass es gesagt wurde – WICHTIG: Den Privaten Schlüssel NIE aus der Hand geben – sagt ja auch der Name schon.
Der private Schlüssel kann mit einem Passwort versehen werden um unbefugten die Nutzung zu verwehren, aber richtig sicher ist das trotzdem nicht. Ein Passwort kann manchmal störend sein, dieses wird bei jeder Nutzung des Schlüssels abgefragt. Es kommt also immer auf den Einsatzzweck an, ob ein Passwort nötig/sinnvoll ist.

1. Generieren eines Schlüssels (in meinem Fall RSA-Key 2048bit stark) mit Kommentar (Mein Namen) aber ohne Passwort

ssh-keygen -t rsa -b 2048 -C "Max Mustermann" -v

Ausgabe:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
28:af:78:11:a2:35:cc:6e:6f:f6:d1:1c:c0:a2:92:2b Max Mustermann
The key's randomart image is:
+--[ RSA 2048]----+
| |
| . |
| o . o |
| .*... o |
|o+.o... S |
|.oo .o o . |
|E. . .o o |
|. .=. . |
| .+... |
+-----------------+

Nun wurde ein Privater und ein Öffentlicher Schlüssel erstellt, diese können sofort genutzt werden!

2. Ausgabe des öffentlichen Schlüssels
Dieses Feature benötigt man, wenn nur der private Schlüssel vorliegt und der öffentliche auf einem Server bereitgestellt werden muss.

ssh-keygen -y

Ausgabe (gekürzt)

Enter file in which the key is (/root/.ssh/id_rsa):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA......2jl9bP4IkzF5jLJv Max Mustermann

3. Setzen eines Passworts für den privaten Schlüssel (je nach Einsatzzweck)

ssh-keygen -p

Hier wird man aufgefordert, 2 mal ein Passwort einzugeben sofern keines gesetzt war.

Optische Datenrettung unter Linux

Problem:
Ich habe mehrere CDs mit Daten. Leider sind die Datenträger in die Jahre gekommen und lassen sich nicht mehr fehlerfrei auslesen.

Lösung:
Es kommt ddrescue zum Einsatz

apt-get install gddrescue

Zuerst mache ich ein Abbild von der CD mit ddrescue nach /tmp/sr0.iso. Die Erstellung kann je nach Schaden eine Weile dauern. Im schlechtesten Fall kann auch ddrescue nichts mehr ausrichten, dann sollte man sich von den Daten verabschieden.

cd /tmp
time ddrescue /dev/sr0 sr0.iso

Das Ergebnis schaute in meinem Fall dann „irgendwann“ so aus:

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued: 701469 kB, errsize: 5453 kB, current rate: 7680 B/s
ipos: 692124 kB, errors: 1070, average rate: 40049 B/s
opos: 692124 kB, time since last successful read: 0 s
Finished

Nun kann man das ISO File mounten um die Daten runter zu kopieren

mount -t iso9660 -o loop /tmp/sr0.iso /mnt

Viel Erfolg beim CDs sichern!

Das sollte im besten Fall mit jedem Datenträger (DVD, Diskette, CD, HDD) so funktionieren falls unerwartet Probleme auftauchen.

svn relocate im Terminal

Problem:
Man hat ein SVN Repository bei welchem die URL gewechselt wurde

Lösung:
Am besten löst man das mit der Kommandozeile.

Zuerst wechselt man in den ausgecheckten Projektordner und findet die aktuelle URL heraus.

cd /pfad/zum/projekt
svn info

Ich habe beispielsweise den Sourcecode von Magento 1.6 hier liegen, die dortige Ausgabe zeigt

Pfad: .
URL: http://svn.magentocommerce.com/source/branches/1.6
Basis des Projektarchivs: http://svn.magentocommerce.com/source
UUID des Projektarchivs: ee4975a1-dc2a-0410-ac7a-f60e980b784d
Revision: 165969
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: vladimir.pelipenko
Letzte geänderte Rev: 140935
Letztes Änderungsdatum: 2012-01-11 15:01:14 +0100 (Mi, 11. Jan 2012)

Wichtig ist hier die „URL: “ Zeile.
Nun zur Handhabung von svn ein Auszug aus der Hilfe

switch (sw): Update the working copy to a different URL.
usage: 1. switch URL[@PEGREV] [PATH]
2. switch --relocate FROM TO [PATH...]

Daraus resultiert im Magento Beispielfall folgender Befehl

svn switch --relocate http://svn.magentocommerce.com/source/branches/1.6 http://mein.neuer.pfad/source/branches/1.6

Mittels svn info kann das Ergebnis überprüft werden.

GIT Server und Gitolite installieren unter Debian

Problem:
Ich benötige für die Entwicklungsabteilung einen GIT Server und möchte aber nicht für jeden Entwickler einen vollwertigen Account auf der Maschine bereitstellen.

Lösung:
Ich kombiniere GIT mit Gitolite.
Gitolite ist eine Administrationsmöglichkeit über ein GIT-Repository und ist selbst ein Nachfolger von Gitosis.

Zuerst muss ein User (und zugehörige Gruppe) angelegt werden, ich nenne diese „git“, das Repository Verzeichnis lege ich nach /srv/gitolite

mkdir -p /srv/gitolite
addgroup --system git
adduser --system --home /srv/gitolite --shell /bin/bash --gecos "GIT@hostname" --ingroup git --disabled-password git
chown -R git:git /srv/gitolite

Jetzt installiere ich folgende Pakete

apt-get install git-core git git-svn

Nun kann mit der gitolite Installation (als root!!) begonnen werden

cd /usr/local/src
git clone git://github.com/sitaramc/gitolite
# installation für alle user ist nicht zwingend nötig, mach ich aber
gitolite/install -ln /usr/local/bin

Nun sollte man einen SSH Public Key besitzen, dieser ist zwingend nötig! Ohne diesen kann hier nicht weitergemacht werden!!! Ich lade meinen Key erstmal auf den Server nach /tmp/key.pub
Jetzt wird man User „git“ und richtet gitolite ein

su - git
gitolite setup -pk /tmp/key.pub

An dieser Stelle sind wir eigentlich schon fertig, gitolite ist installiert und Einsatzbereit.
Testen kann man das mit einem SSH Clienten

ssh git@server info

Das Ergebnis sollte ungefähr so ausschauen:

hello key, this is git@server running gitolite3 v3.5.1-4-g2f48a3e on git 1.7.0.4

R W gitolite-admin
R W testing

Man muss nun noch das Admin Repo auf der eigenen Maschine/Laptop/Desktop mit nem Clienten klonen um die weitere Konfiguration durchzuführen. Repos anlegen und User hinzufügen. Siehe hier http://gitolite.com/gitolite/clone.html

Fertig ist dein GIT Server!

Wer schon SVN Repos pflegt, kann diese nun migrieren. Den Vorgang hab ich hier beschrieben.

SVN Repos zu GITolite konvertieren unter Debian

Problem:
Ich habe einige SVN Repos, die nun ins GIT rüber sollen.

Lösung:
Verwendung von svn2git zur Migration. Nachfolgend wird svn2git beschrieben.
Alternativ kann auch SubGIT gute Dienste leisten.

Ich installiere also zuerst folgende Pakete auf dem Zielsystem

apt-get install git-core git-svn ruby rubygems

Nach der Installation folgen folgende Befehle zur Installation von svn2git

# sources hinzufügen
gem sources -a http://gems.github.com


gem install nirvdrum-svn2git

Im Anschluss ist svn2git nutzbar.
Man sollte lokal einmal das zu konvertierende SVN Projekt komplett auschecken. Ich hatte bei der Anwendung von svn2git und git clone svn jeweils den gleichen Fehler erhalten. Dieser war verschwunden nachdem ich das Projekt einmal ausgecheckt hatte.

!! Der Apache bzw das zuständige WebDAV Modul hat bei vielen Dateien im Repo ein ernsthaftes Overhead Problem weil für jedes File eine Anfrage gestellt werden muss. Es bietet sich also an, wenn möglich, das SVN Protokoll (svn://) bzw. lokal das File Protokoll (file://) zu nutzen !!

Die genutzten Authoren kann man in den ausgecheckten Projekten mit folgenden Einzeilern rausfinden:

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > /tmp/authors-transform.txt

bzw.

svn log --xml | grep author | sed 's_^.*>(.*)<.*$_1_' | sort --unique > authors-transform-from-book.txt

Die beiden txt Dateien sollte man dann zusammenführen und Dubletten bereinigen.

svn2git erwartet das Author Mapping unter ~/.svn2git/authors, wenn die Datei an anderer Stelle liegt, muss das gesondert angegeben werden.

Nun kann man den Prozess anstoßen

# erstelle arbeitsordner
mkdir -p /tmp/svn2git/
# wechsel nach arbeitsordner
cd /tmp/svn2git

Den nachfolgenden Befehl sollte nur wenn nicht anderes möglich, mit dem http Protokoll genutzt werden!! Siehe obiger Hinweis

# svn2git im verbose mode & tee -a
svn2git -v http://my.svn.host.example.com/project1 | tee -a /tmp/projekt1-svn2git.log

Wie man im Terminal (oder dem erzeugten Log) sehen kann, werden ausser dem Klonen noch einige Arbeiten am Repo durchgeführt.

Im Anschluss sollte man noch .gitignore erstellen falls nötig

# erst zeigen lassen ob nötig
git svn show-ignore -i trunk
# die datei .gitignore erstellen, wenn obiger Befehl etwas ausgibt
git svn create-ignore -i trunk > .gitignore

Will man nun das migrierte Projekt in zB Gitolite überführen, lohnt es sich das Projekt zuvor anzulegen und die im Ordner Projekt1.git befindliche gl-conf zu sichern. Das Projekt kann man dann wieder auf dem Filesystem löschen, wir benötigen nur die gl-conf.

In den Repository Ordner von Gitolite kann nun das Projekt reingeclont werden, im Anschluss muss nur die gl-conf wieder in den Ordner überführt werden.


git clone --bare ./ /pfad/zum/repo/Projekt1.git

Happy Coding!