Fleisch und Kippen

would you tell other people to start smoking?


would you tell other people to stop smoking?


do you think smoking is unhealthy for you and others?


are you smoking?




do you think this makes it ‚good‘?


that’s why i do not eat meat.

„Gesetz zur Sicherheit der Bürger“

… das ist ja auch schon bewusst möglichst allgemein gehalten. Hier geht es nicht mehr darum bestimmte, schadhafte Verhaltensweisen zu illegalisieren, sondern unter einem generellen Deckmantel alles unter Verdacht stellen zu KÖNNEN. Generelles Verbot für alles. Jederzeit erweiterbar. Perspektiven wie „Freiheit“ vorsätzlich ausgeblendet.


GIT init on All-Inkl – quicknote

you may want to store your `.git` repo within the webroot? JUST DON’T IT *

get putty

get your login credentials (host, user, PW)

login via putty

on All Inkl you’re now in the root directory of your webspace.

create a new folder for your repo

`mkdir manegefreivontierquaelerei.de.git`

create a new folder for your web-root (where the domain is linked to)**

`mkdir manegefreivontierquaelerei.de`


`cd manegefreivontierquaelerei.de.git`

create repo

`git init –bare`

now we want to automatically deploy a copy of this repo in the web dir

`cd hooks`

`nano post-receive`

GIT_WORK_TREE=/www/htdocs/w00fXXXX/manegefreivontierquaelerei.de git checkout -f

CTRL+X, choose Y, Enter; this changes the destination-folder and overwrites everything (EVERYTHING!! do not store anything else in this folder)

hook must be executeable (it’s shell file)

`chmod +x post-receive`

now quit the putty console and install git.

navigate to a folder on your local machine, e.g. in windows explorer and right click -> start git bash

`git clone ssh://ssh-w00fXXXX@w00fXXXX.kasserver.com/www/htdocs/w00fXXXX/manegefreivontierquaelerei.de.git`

`cd manegefreivontierquaelerei.de`

that’s it, ready for git-magic.

* except for if you hoster doesn’t allow other setups, then use `.htaccess` to deny web-access
** do not hesitate to enable HTTPS – at All Inkl the Let’s Encrypt certificates are included FOR FREE!!

GIT development & deployment – architecture planning

After several years of re-engineering an entry level auction house platform with my friend Rüdiger (in my spare time, non-profit), i’m now planning to migrate my out-of-date Notepad++/FTP/production-only-workflow to a more stable and reliable PHPStorm- and GIT-based development/deployment process. Especially the last 12 month gave me a huge boost when talking about integrated development environements (IDE), debugging features and a lot of new tools for M2M (machine-to-machine communication). Sockets, REST-APIs and all this state-of-the-art cool new stuff opened a lot of new doors, not only for my private purposes, but also for my carreer.

So, back to non-business. Thinking about environments first, it’s clear to have at least two of them: live and test. At this point it’s not necessary to have every version that was ever build available all the time, that’s more risk than fun. So taking this further we will have two domains available for our live users and filthy little testing-midgets (; www.example.com and test.example.com, last one protected by a dumb htaccess.

Underlying the webserver providing (at least) access to our production and development filesystem we’ll use three main directories for the source files: /bare to hold our bare GIT repository, /live to deploy our master branche, accessible via www.example.com and /test for breaking everything on test.example.com.

My first thought before this conclusion was to generate a directory for each main version resulting in folders like /test, /v1, /v2, .. /v17, and so on. Besides spamming the servers filesystem and maybe giving more attackpoints for blackhats through vulnerabilities, i was thinking about the uptime which could be decreased to near zero by just re-routing the domain to the specific directory/version – same with restoring older version.

So i came up with this advantages of mapping two branches on two directories:

 pros  cons

+  simple, easy to understand and maintain

+ (nearly) no old code, resulting in …

+ … less vulnerabilities, no loot for crackers

+ .. and everything tidied up 

+ more automation 

– slower deployment due to copying files 






Maybe i’ll rethink this, putting in more scripting (hooks) for renaming live and test directories after a master merge.

Yeah, master merge. So, now lets see what we’re doing on the local machine and how the server will manage the pushes: Classical XAMPP environment, PHPStorm IDE with set up GIT origin remote bare repo. After developing just commit and push to the server. The GIT hook will manage the deployment to the specific directory, based on which branch we push. „dev“ branch to /test, „master“ branch to /live. Just force a checkout so we can be sure nothing broke from a merge.

Let’s think about it again tomorrow and then i’ll test this in real life. 

[insert info graphic here]

[link to next article]