Git, Github, Infrastructure, Stash

How to migrate Gitolite or other Git-Server Repos to Stash automatic.

In one of our projects I had the need to convert many Git repositories from an old Gitolite server to a internal Stash system.

To have no need to make it for the more than 50 repositories by hand, I wrote this small script which I wanna share with you. The nice things the way which I use transfers also all branches, tags etc.

See the projects Github Page:
https://github.com/tommyziegler/gitolite-to-stash-converter

Just clone it, specify your data and have fun.

For problems in your setup create an issue on Github. Tested with Stash version v3.6.0

Standard
DNS, Git, Github, Infrastructure, Webseite

Github Seite als Webhosting benutzen

Das SCM System Git und somit sein kostenloser Service Github.com wird immer beliebter.

Git ([ɡɪt], engl. Blödmann) ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich für die Quellcode-Verwaltung des Linux-Kernels entwickelt wurde. (Siehe Wikipedia: https://de.wikipedia.org/wiki/Git)

Eine komplette Historie der Webseite zu haben, die Möglichkeiten Änderungen schnell zurückzurollen, eine detailierte Dokumentation, sowie optional Aufgaben über externe Tools und/oder Skripte(n) automatisch zu erledigen, es gibt so viele Vorteile das ich glaube das es die Zukunft für Webseiten sein wird. – Ich denke sogar für viele andere Dokumente wie Briefe, Gesetze, Bücher, jegliche Projektdateien usw. ist eine SCM System von Vorteil.

Für ein Projekt was ich gerade aus dem Boden stampfe (in den nächsten Monaten gibts mehr) wollte ich das mal ausprobieren. Also habe ich eine Domain bei einen x-belibigen Domain-Händler (gandi.net) gekauft. – Eine tolle neue .io-Domain 🙂

1.) Github Seite anlegen

Als erstes legen wir bei Github eine Seite an, also wir erzeugen uns quasi Webspace bei Github.

– Lege auf der Github Webseite ein Repo an <meineseite>.github.io

$ git clone https://github.com/<user>/<meineseite>.github.io
$ cd <meineseite>.github.io/
$ echo "Hello World" > index.html
$ git add --all
$ git commit -m "Initial commit"
$ git push -u origin master

Damit haben wir jetzt eine Github Seite angelegt welche unter der Github Subdomain „http://<meineseite>.github.io“ verfügbar ist. – Dies solltest du im Browser überprüfen.

2.) MX Einträge im DNS-Server deines Domain-Händler / Hoster umbiegen
Nun wollen wir unseren Provider sagen das unser Webspace, also unsere Webseite bei Guthub liegt. Dafür müssen wir uns bei dem Provider anmelden und den DNS-Server korrekt einstellen. Dies ist von Provider zu Provider unterschiedlich.

Wir müssen zwei A-Record einstellen um unserer Domain die Github IP Adressen mitzuteilen …

@ 1800 IN A 192.30.252.153
@ 1800 IN A 192.30.252.154

… sowie den CNAME für unsere Github Seiten Sub-Domain.

www 10800 IN CNAME <meineseite>.github.io.

Danach sollte nach einer kurzen Zeit (bei mir 5 – 10 Minuten, kann aber auch bis 24 Stunden sein) die Seite unter der Hauptdomain verfügbar sein.

Um den DNS Cache zu leeren, kann man folgenden Befehl ausführen. (Mac OS X 10.10)

$ sudo discoveryutil udnsflushcaches

3.) Github Seiten Sub-Domain auf den richtigen Domainnamen umlenken
Jetzt sollten wir nur noch zum abrunden unsere Github Seite auch automatisch mit dem richtigen Domainnamen anzeigen. Also wir leiten sozusagen von „http://<meineseite>.github.io“ auf „<meineseite>.io“ um. Dafür legen wir einfach die Datei CNAME mit dem Inhalt der richtigen Domain in das Git-Repository.

$ echo "<meineseite>.io" > CNAME
$ git add --all
$ git commit -m "Initial commit"
$ git push -u origin master

Nun ist man auch auf „<meineseite>.io“ wenn man „http://<meineseite>.github.io“ ansurft.

Ich hoffe das dieser Artikel nützlich ist und wenn es Fragen oder Anmerkungen gibt warte ich auf Feedback.

Nützliche Links:

Github:
* Github Tips zum A-Record beim eigenen DNS Provider
Domain-Provider:
* DNS-Einstellungen bei Domainfactory
* DNS-Einstellungen bei 1&1
* Blogartikel zu Einstellungen bei gandi.net

Standard
Git

SVN-zu-Git Migration

Dieser Artikel beschreibt, wie ein SVN-Repository (bzw. darin enthaltene Ordnerstrukturen) in ein Git-Repository umgewandelt werden können.

Dazu muss zunächst mit dem git-svn-Kommando ein SVN-Zweig „getrackt“ werden. Anschließend wird jede Revision des angegebenen SVN-Zweigs in eine Git-kompatible Struktur überführt. Während des Auscheckens der SVN-Sourcen müssen alle SVN-Autoren-Namen auf Git-Autoren-Namen „gemappt“ werden. Anschließend kann diese konvertierte, mit korrekten Autoren-Namen versehene Struktur als Git-Repository committed werden.

Dieser Artikel beschreibt, wie ein SVN-Repository mittels Git-Kommandozeilenbefehlen in ein Git-Repository umgewandelt werden kann.

Konvertieren eines SVN-Zweigs

Um ein SVN-Repo zu Git zu konvertieren, muss zunächst ein entsprechendes leeres Repository auf dem Git-Server angelegt und dann die SVN-Sourcen in das zugehörige lokale Git-Repository ge“fetch“t werden:

# Erstelle leeren Ordner
mkdir svn-to-git-konvertierung
cd svn-to-git-konvertierung

# Clone Admin-Repository und füge der gitolite.conf-Datei ein neues Repository names "GIT_REPO_NAME" hinzu.
git clone git@gitserver:gitolite-admin
cd gitolite-admin
nano conf/gitolite.conf
git commit -a -m "Repository hinzugefügt"
cd ..

# Erzeuge ein lokales Git-Repository, basierend auf den per URL identifizierten SVN-Sourcen, mit dem Namen GIT_REPO_NAME.
mkdir GIT_REPO_NAME
cd GIT_REPO_NAME
git svn init svn://svnserver/pfad/zur/svn/ordner/struktur

# Wandle während der Konvertierung alle SVN-Authorennamen in Git-Authorennamen um.
git config svn.authorsfile ../gitolite-admin/svn-authors.txt
git svn fetch

# Sende das konvertierte SVN-Git-Repository an den Git-Server.
git remote add origin git@gitserver:GIT_REPO_NAME
git push origin master

Autoren-Mapping

Mit folgendem Befehl kann eine Liste aller SVN-Autoren erstellt werden, welche in einen bestimmten SVN-Zweig committed haben:

svn log svn://svnserver/pfad/zur/svn/ordner/struktur --xml | grep -P "^(.*?)<\/author>/$1 = /'

Eine Datei „svn-authors.txt“ kann wie oben beschrieben die bereits bekannten SVN-Autoren des Zweigs svn://svnserver/pfad/zur/svn/ordner/struktur auf Git-Autoren mappen. Es ist praktisch Sie auf die Grundebene des „gitolite-admin“-Repositories einzuchecken, um Sie für spätere Vorgänge wiederzuverwenden.

Diese wird für das Konvertieren eines alten Standes im SVN-Zweig benötigt und sollte deshalb vor der Konvertierung ausgecheckt werden.

Nützliche Links

  • http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
  • http://treyhunner.com/2011/11/migrating-from-subversion-to-git
  • http://stackoverflow.com/questions/2337281/how-do-i-do-an-initial-push-to-a-remote-repository-with-git
  • Standard
    Git

    Git Server mit Gitolite auf einen Ubuntu Server installieren

    Dies wird eine kleine Anleitung wie man die Gitolite Benutzerverwaltung für Git Repositories in Betrieb nimmt.

    SERVER:

    Als erstes müssen wir Git und Gitolite auf dem Server installieren.

    $ sudo apt-get update
    $ sudo apt-get install git-core gitolite
    $ sudo adduser --system --group --shell /bin/bash --disabled-password git
    

    ADMIN CLIENT:

    Dann müssen wir Public/Private SSH Keys auf einen Client generieren mit den wir das Repo verwalten möchten.

    $ ssh-keygen -t rsa
    $ scp ~/.ssh/id_rsa.pub regular_username@git_server_IP_address:/tmp/git-admin.pub
    
    $ mkdir ~/git-admin-keys
    $ cp ~/.ssh/id_rsa ~/git-admin-keys
    $ cp ~/.ssh/id_rsa.pub ~/git-admin-keys
    

    SERVER:

    Dieser Key wird nun auf den Server installiert.

    $ sudo su - git
    $ gl-setup /tmp/git-admin.pub
    

    ADMIN CLIENT:

    Gitolite wird auch via einem eigenen Repository konfiguriert und eingestellt. Dieses kann man mit folgenden Befehl klonen.

    $ git clone git@git_server_IP_address:gitolite-admin ~/gitolite-admin
    

    Mit folgenden Befehl können wir Nutzer im Gitolite Repo anlegen

    $ cp /path/to/john's/public/key.pub ~/gitolite-admin/keydir/john.pub
    $ git add ~/gitolite-admin/keydir/john.pub
    $ git commit -a -m "New user John added"
    

    Nun könnnen wir die Hauptkonfigurationsdatei erstellen.

    $ nano ~/gitolite-admin/conf/gitolite.conf
    

    Folgende Standard Datei von mir ist sinnvoll und sollte selbsterklärend sein.

    	gitolite.conf:
    
    		################################################################################
    		# Gruppen-Makros:                                                              #
    		# Per Leerzeichen getrennte Usernamen; es dürfen nur solche User eingetragen   #
    		# werden, die mittels ihrer im 'keydir'-Verzeichnis abgelegten public ssh keys #
    		# eingerichtet worden sind.                                                    #
    		#                                                                              #
    		#    z.B.: @group_name = user1 user2 user3                                     #
    		#                                                                              #
    		################################################################################
    
    		@magunait-admins       = user1
    		@magunait-engineers    = user4 user5
    		@magunait-tools        = usertoolchain
    
    
    		###############################################################################
    		# Admin Repository:                                                           #
    		# Mit diesem Repository werden Benutzer und Repositories verwaltet.           #
    		###############################################################################
    
    		# Admin-Repository
    		repo gitolite-admin
    		    RW     = @magunait-admins
    		    R      = @magunait-engineers
    
    		###############################################################################
    		# MagunaIT-Repositories:                                                      #
    		# Diese Repositories werden vom MagunaIT-Team verwaltet.                      #
    		###############################################################################
    
    		# Masterbrain-Repositories
    		repo repo1
    		    RW = @magunait-engineers @magunait-tools
    
    		repo repo2 repo3
    		    RW = @magunait-engineers @magunait-tools
    

    Nun kann man die Änderungen mit folgenden Befehlen auf den Git Server hochladen.

    $ git commit -a -m "Add user credentials"
    
    $ git push
    

    DEVELOPER CLIENT:

    Folgende Befehle um den Client Standard Werte des Benutzer(s) zu übermitteln ist ratsam.

  • Unix (Linux, Mac OS X etc.)
  •   $ git config --global core.editor your_editor_choice
      $ git config --global user.name "your_name_here"
      $ git config --global user.email "your_email@address.com"
    

    Dies ist eine kleine Anleitung wie ich bei einigen Kunden Git einfach und schnell installiert habe.

    Standard
    MySQL

    MySQL Query zum anonymisieren von IPv4 Adressen

    Wenn man schnell mal IPv4 Adressen in der Datenbank anonymisieren will hilft ein dieser Query weiter:

    UPDATE [TableName] SET [ipField] = CONCAT_WS('.', SUBSTRING_INDEX([ipField],'.',1), SUBSTRING_INDEX(SUBSTRING_INDEX([ipField],'.',2),'.',-1), SUBSTRING_INDEX(SUBSTRING_INDEX([ipField],'.',-2),'.',1), "xxx");

    Anonymisiert die IP von ‚192.168.178.123‘ zu ‚192.168.178.xxx‘.

    Standard
    Infrastructure

    Deploying a Java-Tomcat-Webapp on AmazonAWS via ShellScript

    A small shell script which i used to deploy our web apps to our Amazon AWS Infrastructure. This script I used for our test and staging systems. Next step will be a deployment pipeline.


    #bash

    # File to deploy
    FILE=mywebapp.war

    # Amazon AWS Informations (Host, User, SSL-Key)
    EC2HOST=ec2-xxx-xxx-xxx-xxx.eu-west-1.compute.amazonaws.com
    SSHUSER=root
    SSHKEY=/path/to/ssh/key/keyfile.pem

    # Check if file exists
    if [ -f $FILE ];
    then

    # SSH Connection String
    SSHCONNECTION=$SSHUSER@$EC2HOST

    if [ -f $SSHKEY ];
    then
    # stop deployed app
    ssh -i $SSHKEY $SSHCONNECTION "/etc/init.d/tomcat stop && killall java"

    # deploy to amazon aws
    ssh -i $SSHKEY $SSHCONNECTION rm -rf /opt/tomcat/webapps/ROOT /opt/tomcat/webapps/ROOT.war
    scp -i $SSHKEY ./$FILE $SSHCONNECTION:/opt/tomcat/webapps/ROOT.war
    rm -rf ./$FILE

    # start new deployed app
    ssh -i $SSHKEY $SSHCONNECTION "/etc/init.d/tomcat start && tailf /opt/tomcat/logs/catalina.out"

    else
    echo "SSH Key $SSHKEY doesn't found."
    fi

    else
    echo "File $FILE does not exist."
    fi

    Standard
    Security

    Eigene OpenSSL Zertifkate erstellen

    Hier eine kleine Anleitung (Shell-Skript) wie man über die Konsole mit Hilfe von OpenSSL sich selbstsignierte Zertifikate erstellt.

    #!/bin/sh
    
    #SSL Certificate Infos
    COMMONNAME="tommyziegler.com"
    ORGANIZATION="Tommy Ziegler"
    COUNTRY="DE"
    STATE="Niedersachsen"
    LOCATION="Lueneburg"
    DAYSVALID=365
    
    # Generating self-signed certificate
    openssl genrsa -des3 -passout pass:x -out server.pass.key 2048
    openssl rsa -passin pass:x -in server.pass.key -out server.key
    rm server.pass.key
    openssl req -new -key server.key -out server.csr -subj "/C=$COUNTRY/ST=$STATE/L=$LOCATION/O=$ORGANIZATION/CN=$COMMONNAME"
    openssl x509 -req -days $DAYSVALID -in server.csr -signkey server.key -out server.crt
    rm server.csr
    
    Standard
    Security

    Schnelles überprüfen ob ein SSL Zertifikat valide ist

    Nachdem ich jetzt in einem Projekt wo ich SSL-Pinning auf der Client Seite in ein Qt- sowie NodeJS-Client implementiert hatte fortlaufend keine Verbindung zu neuen Server Modulen in meiner Server Zoo Landschaft bekommen konnte, war ich irgendwie recht verwirrt und verzweifelt. Denn auch in den Browsern wurde mir alle Zertifikate mit Grün angezeigt, und es sah alles nach der Client-Seite aus.

    Bis wir per Hand das SSL Zertifikat mit dem OpenSSL-Kommandozeilentool überprüft hatten und feststellten das wir da das gleiche Problem hatten.
    Und die Moral von der Geschicht: „Bei Zertifikats-Foo, nie Browsern vertrauen.“


    > openssl s_client -connect server.hostname.net

    Standard
    Konferenz

    Review der BED-Con Konferenz in Berlin

    In der ersten Aprilwoche (03./04.) war ich auf der Konferenz der “Berlin Expert Days“ 2014. Die Themenbereiche der BED-Con 2014 sollten Java und Java EE, Mobile und Responsive, Spring, JavaScript, funktionale Sprachen, NoSQL, Continuous Delivery, DevOps sowie User Experience sein. Da ich mich in den letzten Jahren durch ein neues Projekt bei meinem Hauptarbeitgeber genau in diesem Bereich befinde, passte die Konferenzrichtung perfekt zu mir. Als ich dann noch von den Preisen, Early-Bird 75 Euro und Standard 90 Euro gelesen hatte, gab es eigentlich gar kein Argument mehr die Konferenz, welche ja nur zwei Stunden Zugfahrt entfernt war, auszulassen. Also buchte ich mir ein Ticket und freute mich darauf.

    Meine Freude war groß, da ich durch den Programmplan wusste, dass ich mir dort tolle Speaker anhören werden würde und ich sogar schon einige aus meinem Projektgeschäft kenne. Des Weiteren waren auch mir bekannte Entwickler einer Partnerfirma da. Somit hatte ich zwei Anlaufpunkte um allein nicht unterzugehen, denn leider konnte ich keine meiner Arbeitskollegen und privaten IT-Freunde motivieren mich zu begleiten. Vielleicht ändert sich dieses ja nächstes Jahr nach dieser Review.

    Der Austragungsort der BED-Con ist auf dem Universitätsgelände der Freien Universität Berlin, Campus Dahlem im Institut für Informatik. Somit ist es im Vergleich zu Konferenzen wie den beiden JAX Konferenzen in Deutschland oder der Devoxx in Belgien eine recht überschaubare und familiäre Konferenz. Umso mehr war ich deshalb von der organisatorischen Leistung, wie z.B. der Verpflegung, dem Equipment und dem Ablauf sehr überrascht, da dies genial gemacht war. Im Vergleich dazu haben sich viel größere und teurere Konferenzen schon ganz schön blamiert.

    Die Vorträge, welche ich gehört habe, waren wie immer bei der Auswahl meiner Konferenzen bunt gemischt. Von Möglichkeiten der Entscheidungsfindung beim UX Design im Team über NoSQL, sowie BigData Themen. Aber auch Java 8 und das Spring 4 Framework bis hin zur Notwendigkeit der Beleuchtung vom Java Applikations-Server, was zu sogenannten Micro-Services führt und einem Talk über das Caching in seiner Anwendung.
    Ich hätte mir eigentlich gerne noch viel mehr angesehen, aber nur einen Talk zu verfolgen war auf Grund des Orts- und Zeitproblems leider nicht möglich und die BED-Con zeichnet die Talks auch leider nicht auf.

    Dennoch habe ich eine Menge Informationen mit nach Hause genommen, welche ich noch durcharbeiten werde. Des Weiteren macht es mir immer total viel Spaß mit so vielen intelligenten und kreativen Köpfen an einem Ort zu sein und unseren Spirit zu spüren.

    Ich sage Daumen hoch für die BED-Con und bis zum nächsten Jahr. 🙂

    Webseite: http://bed-con.org
    Twitter: @bedcon (Hashtag: #bedcon)

    Standard
    Java, Spring

    How to expose the resourceId with Spring-Data-Rest?

    Spring-Data-Rest is a quite new project in the Spring family of pivotal. The intention of this project is to reduce the boilercode of controllers and services when you need only CRUD methods on an entity for your REST resources. – Quote from project page is “Spring-Data-Rest makes it easy to expose JPA based repositories as RESTful endpoints.”

    One requirement I had was to expose the CRUD identifier and database primary key which is annotated with @Id. In my case that was needed because the field was functional required. For that I had to expose it because at the standard configuration the ID field is only visible on the resource path, but not on the JSON body.

    To expose it you need to configure your RepositoryRestMvcConfiguration like that:

    @Configuration
    public class MyCoolConfiguration extends RepositoryRestMvcConfiguration {
    
        @Override
        protected void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) {
            config.exposeIdsFor(FooEntity.class);
        }
    }
    

    The entity class could look like that:

    @Entity
    public class FooEntity {
    
        @Id
        @GeneratedValue(strategy= GenerationType.AUTO)
        Long id;
    
        String name;
    }
    

    With this configuration you will receive your entity id back.

    {
      "_links":{
      "self":{
        "href":"http://localhost:8081/api/fooentity/1"
      }
    },
      "id":1,
      "name":"bar"
    }
    

    Additional Comment from a Spring-Developer: URI stands for unique, resource, *identifier* – The URI *is* the id. What I expose here is a database internals.

    Standard