Von Gitlab zu Gitea

Probleme

In letzter Zeit, sind die langen Anfangsladezeiten der Website von Gitlab immer häufiger aufgetreten. Sowie wurde die ganze Website immer langsamer und fast nicht mehr bedienbar. Daher habe ich mir das ganze auf meine Vserver etwas genauer angeschaut. Dabei hat sich herausgestellt, das Gitlab immer Ressourcen-hungriger wird. In meinem Fall waren es fast 1,4 GB Ram + 2-3 GB im Swap. Bei gerade 2 GB Hauptspeicher ist das nun doch etwas zu viel. Laut Gitlab wird derweilen auch empfohlenen, dass man 2 CPU Cores und 8 GB RAM benötigt (stand 01.07.2018), siehe hier https://docs.gitlab.com/ee/install/requirements.html.

Durch Zufall bin ich auf Gitea gestoßen, welches ich gleich ausprobieren musste. Und siehe da, die Funktionalität auf der Website ist genau das was ich benötige und noch etwas mehr. Des Weiteren benötigt es aktuell um die 300-500 MB Arbeitsspeicher und die ganze Anwendung besteht aus einer 50 MB großen Datei. Des Weiteren ist die Installation denkbar einfach und es kann der vorhandene MySQL-Server genutzt werden, oder auch SqlLite als Datenbank-Backend.

Installation

So und hier nun die Installation für Gitea (Im groben hab ich mich dabei an die Original-Anleitung von Gitea gehalten mit ein paar kleinen Anpassungen):

Vorbereitung

Hiermit wird die Anwendung in der Version 1.4.3 heruntergeladen und entsprechend umkopiert, so kann ohne weiteres auch die Anwendung aktualisiert werden:

wget -O gitea https://dl.gitea.io/gitea/1.4.3/gitea-1.4.3-linux-amd64
chmod +x gitea
cp gitea /usr/local/bin/gitea

Hiermit wird die Ordnerstrukturen erzeugt:

adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password --home /home/gitea gitea
mkdir -p /var/lib/gitea/{custom,data,indexers,public,log}
chown gitea:gitea /var/lib/gitea/{data,indexers,log}
chmod 750 /var/lib/gitea/{data,indexers,log}
mkdir /etc/gitea
chown root:gitea /etc/gitea
chmod 770 /etc/gitea

Gitea als Dienst

Nun noch den Dienst für Gitea einrichten, dafür nachfolgenden Code in die Datei „/etc/systemd/system/gitea.service“ eintragen:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=gitea HOME=/home/gitea GITEA_WORK_DIR=/var/lib/gitea GITEA_CUSTOM=/var/lib/gitea/custom
# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE
#StandardOutput=syslog # Ist der Default
#StandardError=syslog # Ist der Default
SysLogIdentifier=gitea
[Install]
WantedBy=multi-user.target

Danach den Dienst aktivieren und starten:

systemctl enable gitea
systemctl start gitea

Wenn man die Datei verändert hat, benötigt man erst ein nachladen vom systemd damit alles wieder funktioniert:

systemctl daemon-reload

Nacharbeiten

Nun geht man auf die Website und richtet Gitea ein. Danach sollte man noch die Konfigurationsdateien gegen Veränderung schützen:

chmod 750 /etc/gitea
chmod 644 /etc/gitea/app.ini

Die Konfigurationsdatei kann auch per Hand verändert werden, danach muss Gitea aber einmal neugestartet werden:

systemctl restart gitea

Diagnose

Um sich die Logausgaben, die von Gitea auf SdtOut geschrieben werden, anzuschauen, benutzt man journalctl:

journalctl -u gitea
journalctl -f -u gitea # Live log

Hinter dem Apache verstecken

Da ich als Haupteinstiegsserver einen Apache-Server am laufen habe, benötige ich nun noch eine Proxy-Konfiguration, um die Anfrage weiterzuleiten (Der angegebene Port, ist der Standard-Port von Gitea. Wenn man diesen angepasst hat, muss er hier ebenfalls angepasst werden!):

# unverschlüsselte Verbindung
<VirtualHost w.x.y.z:80>
  ServerName gitea.example.com
  ServerAdmin hostmaster@example.com
  # Umleiten auf HTTPS
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^/(.*) https://gitea.example.com/$1
  </IfModule>
  Redirect / https://gitea.exmaple.com/
</VirtualHost>
# SSL Konfiguration
<VirtualHost w.x.y.z:443>
  ServerName gitea.example.com
  ServerAdmin hostmaster@example.com
  SSLEngine On
  SSLHonorChipherOrder On
  SSLCipherSuite ...
  SSLVerifyDepth 10
  SSLCertificateFile /../...pem
  SSLCertificateKeyFile /../...key
  SSLCertificateKeyFile /../...crt
  SSLCertificateKeyFile /../...csr
  ...
  # Internes weiterleiten an den nginx
  <IfModule mod_proxy.c>
    ProxyVia On
    ProxyRequests Off
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
    ProxyPreserveHost On
    <Proxy *>
      Options FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all
    </Proxy>
    # Notwendig, damit die https-Verbindung auf http weitergeleitet werden kann
    RequestHeader set Host "gitea.example.com"
    RequestHeader add X-Forwarded-Ssl on
    RequestHeader set X-Forwarded-For %{REMOTE_IP}%
    RequestHeader set X-Forwarded-Proto "https"
  </IfModule>
</VirtualHost>

Jetzt benötigt man noch die Proxy-Module und einen neuladen des Apache-Server:

a2enmod proxy
a2enmod proxy_http
service apache2 reload #oder restart wenn man möchte

GitLab konfigurieren

Für die Konfiguration des GitLab mit dem Omnibus-Package ist nur eine Datei notwendig, diese ist die „/etc/gitlab/gitlab.rb“. Ein Beispiel:

# URL die im Browser eingegeben wird. (Es scheint so, das am Ende kein / stehen darf)
external_url "https://gitlab.example.com"
# Einstellungen für nginx
nginx['listen_address'] = '127.0.0.1'
nginx['listen_https'] = false
nginx['listen_port'] = 880
nginx['redirect_http_to_https'] = true
# Ist notwendig, damit die richtige URL bei den Projekten steht. Gerade bei Sub-Sub-Domains, z.B: gitlab.mydomain.example.com.
gitlab_rails["gitlab_host"] = 'gitlab.example.com'
# EMail-Adresse die als Absender eingetragen wird
gitlab_railse["gitlab_email_from"] = 'gitlab@example.com'
# Für neuere Version, wird mehr Arbeitsspeicher benötigt (recommended 4 GB), um diese etwas zu umgehen kann die
#   Unicorn-Arbeitsthread verringer, die typischerweise auf Anzahl Cores + 1 eingestellt sind:
#   Weitere Info: https://docs.gitlab.com/ce/install/requirements.html#unicorn-workers
unicorn['worker_processes'] = 2
unicorn['worker_timeout'] = 60

Nach jeder Änderung in der Konfiguration muss gitlab rekonfiguriert werden, das macht man mit folgenden Befehl:

gitlab-ctl reconfigure

Wenn nginx nicht starten kann, weil ein anderer Webserver schon läuft, dann kann man das wie folgt lösen. Zuerst muss man nginx umkonfigurieren, damit dieser auf einen anderen Port lauscht. In der Datei „/etc/gitlab/gitlab.rb“ die nachfolgenden Einträge hinzufügen:

# Einstellungen für nginx
nginx['listen_address'] = '127.0.0.1'
nginx['listen_https'] = false
nginx['listen_port'] = 880
nginx['redirect_http_to_https'] = true

Da hier ein interne Verbindung benutzt wird, um von dem einen Webserver auf den anderen zu kommen, reicht hier http völlig aus. Das „:880“ definiert den Port an dem nginx lauschen soll. Sollte nach dem Re-konfigurieren von gitlab, nginx noch nicht am angegeben Port lauschen, was mit nachfolgenden Befehl nachgeprüft werden kann:

netstat -pant

Dann sollte man nginx per Hand stoppen und starten:

gitlab-ctl stop nginx
gitlab-ctl start nginx

Nun muss der andere Webserver noch als Proxy eingerichtet werden. Beim Apache (ab Version 2.0) müssen zuerst die Proxy-Module aktiviert werden:

a2enmod proxy
a2enmod proxy_http

In der VHost-Konfiguration zum Gitlab-Server sollte dann ungefähr so ausschauen:

# unverschlüsselte Verbindung
<VirtualHost w.x.y.z:80>
  ServerName gitlab.example.com
  ServerAdmin hostmaster@example.com
  # Umleiten auf HTTPS
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^/(.*) https://gitlab.example.com/$1
  </IfModule>
  Redirect / https://gitlab.exmaple.com/
</VirtualHost>
# SSL Konfiguration
<VirtualHost w.x.y.z:443>
  ServerName gitlab.example.com
  ServerAdmin hostmaster@example.com
  SSLEngine On
  SSLHonorChipherOrder On
  SSLCipherSuite ...
  SSLVerifyDepth 10
  SSLCertificateFile /../...pem
  SSLCertificateKeyFile /../...key
  SSLCertificateKeyFile /../...crt
  SSLCertificateKeyFile /../...csr
  ...
  # Internes weiterleiten an den nginx
  <IfModule mod_proxy.c>
    ProxyVia On
    ProxyRequests Off
    ProxyPass / http://127.0.0.1:880/
    ProxyPassReverse / http://127.0.0.1:880/
    ProxyPreserveHost On
    <Proxy *>
      Options FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all
    </Proxy>
    # Notwendig, damit die https-Verbindung auf http weitergeleitet werden kann
    RequestHeader set Host "gitlab.example.com"
    RequestHeader add X-Forwarded-Ssl on
    RequestHeader set X-Forwarded-For %{REMOTE_IP}%
    RequestHeader set X-Forwarded-Proto "https"
  </IfModule>
</VirtualHost>

Und dann noch den Apache die Konfiguration erneut einlesen lassen, mit nachfolgenden Befehl:

service apache2 reload #oder restart wenn man möchte

Nun sollte man über den Zugriff „https://gitlab.example.com“ auf die GitLab anmelde Webseite kommen. Und bei den Projekten, sollten auch die richtigen URL’s erscheinen.

Weitere Informationen zu Einstellungen von GitLab findet man hier.

Tabelle aus MS SQL Server exportieren und wieder einspielen

Um eine Tabelle komplett aus dem MS SQL Server zu exportieren benutzt man typischer Weise den BCP Befehl. Zum exportieren benutzt man folgenden Befehl:

bcp <db>.<schema>.<table> out <table-file> -S <sql-svr> -T -c

Um diese Tabelle wieder am anderen Server einzubuchen, sollte diese Tabelle am besten leer sein. Das Eintragen funktioniert dann mit folgenden Befehl:

bcp <db>.<schema>.<table> in <table-file> -S <sql-svr> -T -c

Die Bedeutung der Parameter am BCP-Befehl:

  • out (in): der Weg den die Daten gehen, heraus aus der DB in die Datei (von der Datei in die DB)
  • -S <sql-svr>: Darüber wird der MS-SQL-Server angegeben, mit dem gearbeitet wird
  • -T: Gesicherte Verbindung, wenn nicht möglich kann über „-U/-P“ ein Benutzer und das Password angegeben werden
  • -c: definiert die Zeichentypen, wenn dies nicht angegeben wird, muss für jede Spalte die Definition einzeln angegeben werden

Für weitere Hilfe, kann man noch hier bei Microsoft direkt nachschauen für weitere Parameter.

WordPress Syntaxhighlighting mit Leerraum am Anfang

Ich hab seit langer Zeit das Plugin „SyntaxHighlighter Plus“ verwendet, um meine Quellen farblich anzuzeigen. Bei einfachen Quellen war dies noch einfach und ohne Probleme, es wurde einfach mit [ Sprachkennung ] begonnen und mit [ /Sprachkennung ] beendet.

Probleme gab es aber immer dann, wenn es längere Quellen waren, die auch Einrückungen hatten. Entweder man hat diese in der Visuell-Ansicht angegeben, dann sind nach jedem speichern die mühsam erzeugten Einrückungen wieder entfernt gewesen. Hat man das ganze in einen Quote-Block gesetzt, so wurde nichts gelöscht, aber es wurden die Tags nicht erkannt, wodurch die Quellen nicht farblich geschaltet wurden

Oder man musste in die HTML-Ansicht wechseln, und dort die Quellen einfügen. Nach dem Speichern und erneuten editieren, sind aber dort dann bekannte HTML-Zeichen durch ihre Textersetzungen ersetzt worden. Das Problem war dann aber, das das kaufmännische Und bei jedem Speichern ersetzt wurde. Was bedeutet, der erste Wurf musste sitzen.

Endlich fand ich dann folgenden 2 Plugins, welche die alte Funktionalität unterstützten und sehr einfach gehalten wurden:

  • SyntaxHighlighter Evolved
  • SyntaxHighlighter TinyMCE Button

So existieren nun 2 Buttons im TinyMCE-Editor, durch denen Quote-Blöcke eingefügt werden, die zeitgleich eine Sprachkennung besitzen, um die Quellen farblich zu gestalten. Und durch den Quote-Block, gehen auch keine Einrückungen mehr verloren. Was ebenfalls sehr interessant ist, es gibt die Möglichkeit, in den Kommentaren das Syntaxhighlighting zu aktivieren.

Einzige einige Einstellungen musste ich noch im Evolved vornehmen, damit es wieder so aussah wie im alten und das waren folgende:

  • Hightlighter Version auf 2.x gestellt, dadurch funktioniert wieder der Zeilenumbruch, sowie die 4 Buttons werden dargestellt
  • „Load all Brushes“ muss aktiviert werden, damit es überhaupt funktioniert
  • „Wrap long lines“ muss aktiviert werden, damit der Zeilenumbruch funktioniert

[Update]Nachgehend habe ich doch noch ein anderes Plugin gefunden, mit dem Namen „WP SyntaxHighlighter“, welches die oberen 2 in einem vereint und noch etwas zusätzliche Funktionalität hinzufügt. Der einzige Nachteil ist, das die alte []-Tags nicht mehr erkannt werden, wodurch einige älter Blogs nochmal überarbeitet werden mussten.

Als zusätzliche Funktionalität existiert die Möglichkeit in Kommentaren SyntaxHighlighting zu setzten. [/Update]

C# Dienst mit eigener Installationsroutine (per /i)

Nach langer suche und vielen Zusammenstückeln, habe ich nun endlich ein komplettes Paket um einen Dienst die Möglichkeit zu implementieren sich selbst per Kommandozeilenparameter zu installieren.

Ebenso wird zeitgleich eine Konsolenausgabe mit implementiert. Das einzige Problem hier ist, solange der Projekt-Typ nach Standard auf „Windows Anwendung“ steht, funktionieren das Attachen nicht ganz komplikationslos, da die Anwendung in der Konsole direkt zurückkehrt ohne aufs Ende des Prozesses zu warten. Um diese Problem wegzubekommen, muss der Projekt-Typ auf „Konsolen Anwendung“ umgestellt werden.

Dieser Quellcode hat einen großen Vorteil gegenüber anderen die noch vorhanden sind, da hier beim installieren und deinstallieren das gleiche durchgeführt wird, was auch das InstallUtil Programm durchführt. Daher kann das Array welches bei Install und Deinstall übergeben wird, entsprechend der Parameter die am InstallUtil vorhanden sind erweitert werden.

(Vorne weg noch ein kleiner Tip, sollte die using-Direktive zu einer Klasse fehlen und die Klasse wurde richtig geschrieben, dann kann per [Strg]+[.] die Direktive automatisch ermittelt und hinzugefügt werden. Für den Fall das ich welche vergessen habe.)

Zuerst einmal die Konstanten und die Imports, welche innerhalb der „static class Program“ eingefügt werden müssen:

const uint ATTACH_PARENT_PROCESS = 0x0ffffffff;
const int ERROR_ACCESS_DENIED = 5; // Process ist schon attached von einer anderen Konsole
[DllImport("kernel32", SetLastError = true)]
static extern bool AllocConsole();
[DllImport("kernel32", SetLastError = true)]
static extern bool FreeConsole();
[DllImport("kernel32", SetLastError = true)]
static extern bool AttachConsole(uint dwProcessID);

Die Main-Prozedur (der noch der Paramter „string[] args“ hinzugefügt werden muss, wenn nicht vorhanden) muss nun folgender weise erweitert werden:

ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[] { new MyNewService() };
if (System.Environment.UserInteractive)
{
  if(!AttachConsole(ATTACH_PARENT_PROCESS) || Marshal.GetLastWin32Error() == ERROR_ACCESS_DENIED)
    AllocConsole();
  // Uebergabe Parameter
  bool install = false;
  bool uninstall = false;
  bool debug = false;
  string value = "";
  int pos = -1;
  for (int i = 0; i < args.Length; i++)
  {
    var arg = args[i];
    value = "";
    pos = arg.IndexOf('=');
    if (pos > 0)
    {
      value = arg.Substring(pos + 1);
      arg = arg.Substring(0, pos);
    }
    switch(arg.ToLower())
    {
      case "/i": install = true; break;
      case "/u": uninstall = true; break;
      case "/c": debug = true; break;
      case "/account": /*Account-Typ aus der Variable value speichern*/ break;
      case "/user": /*Benutzer aus der Variable value speichern*/ break;
      case "/passwd": /*Passwort aus der Variable value speichern*/ break;
      default:
        Console.WriteLine("Argument nicht verstanden: {0}", arg);
        break;
    }
  }
  try
  {
    if (install)
    {
      var combArgs = new string[] { Assembly.GetExecutingAssembly().Location };
      System.Configuration.Install
        .ManagedInstallerClass.InstallHelper(combArgs);
    }
    else if (uninstall)
    {
      var combArgs = new string[] { "/u", Assembly.GetExecutingAssembly().Location };
      System.Configuration.Install
        .ManagedInstallerClass.InstallHelper(combArgs);
    }
    else if (debug)
    {
      var svc = ServicesToRun[0] as MyNewService;
      svc.OnStartDebug(args);
      Console.WriteLine("[Return] fürs beenden drücken...");
      Console.ReadLine();
      svc.OnStopDebug();
    }
  }
  catch (Exception exc)
  {
    Console.WriteLine(exc.Message);
  }
  // Konsole wieder freigeben
  FreeConsole();
}
else
{
  // Wenn das Programm nicht ueber die Konsole gestartet wurde dann als Dienst starten lassen
  ServiceBase.Run(ServicesToRun);
}

Zusätzlich müssen die 2 Funktionen (OnStartDebug/OnStopDebug) angelegt werden, die einzig die gleichnamigen (ohne Debug am Ende) protected Methoden aufrufen, wenn der Debug-Modus gewünscht ist. Wenn nicht, dann einfach diesen Teil aus den obigen Quellcode entfernen.

Benutze GIT

Hier eine kurze Beschreibung, welche Software wie installiert werden muss um mit Git gut arbeiten zu können. Ebenso werden Befehlsfolgen für die einfache Verwendung noch folgen. Sowie auch allgemeine Informationen um sich das leben zu erleichtern.

Git Server

Installation auf einen Debian Server

Am einfachsten ist es, wenn man die Konfiguration mit einem Benutzer auf dem Computer selbst durchnimmt. Dafür erzeugt man mit folgenden Befehl einen Private/Public-Key, anfallende Abfragen mit Enter bestätigen:

ssh-keygen -b 2048 -t rsa

Den Public-Key dann in den den weiter unten angegeben Verzeichnis kopieren, damit der gitolite-Benutzer dran kommt.

Sollte bei den meisten Distributionen ähnlich funktionieren. (WICHTIG: Der Pfad in den alle Daten von gitolite gelegt werden ist der Home-Pfad des Benutzers, diesen könnte man, nach der Paket-Installation, mit dem Befehl „vipw“ anpassen, aber bitte Vorsicht, damit die Datei nicht zuerstört wird, da sonst keine Anmeldung mehr funktioniert)

#Installieren der Packet
 apt-get install git gitweb gitolite python-setuptools
 # Kopiere den Haupt-Public-Key ins TempVerzeichniss
 # mit folgenden Namen: /tmp/username.pub
 # Wechsle auf den User gitolite
 su gitolite
 # Start gitolite Setup, username.pub wird Hauptadmin
 gl-setup /tmp/username.pub
 # Klone das Repo von deinem Server für weitere Einstellungen
 git clone gitolite@server:gitolite-admin

Konfiguration von gitweb

Im gitweb („/etc/gitweb.conf“) müssen nur 2 Ornder-Pfade angepasst werden, und zwar muss die „$projectroot“ auf das repositories-Verzeichnis zeigen, welches auf erster Ebene im Benutzerverzeichnis vom gitolite liegt. Und die „$projects_list“ muss noch auf die Datei „projects.list“ zeigen, welche im selben Verzeichnis wie das Repository liegt. Kleines Beispiel einer kompletten config, bei der das Homeverzeichnis vom gitolite unter „/srv/gitolite“ liegt:

# path to git projects (<project>.git)
 $projectroot = "/srv/gitolite/repositories/";
 # directory to use for temp files
 $git_temp = "/tmp";
 # target of the home link on top of all pages
 #$home_link = $my_uri || "/";
 # html text to include at home page
 $home_text = "indextext.html";
 # file with project list; by default, simply scan the projectroot dir.
 $projects_list = "/srv/gitolite/projects.list";
 # stylesheet to use
 $stylesheet = "gitweb.css";
 # javascript code for gitweb
 $javascript = "gitweb.js";
 # logo to use
 $logo = "git-logo.png";
 # the 'favicon'
 $favicon = "git-favicon.png";

Konfiguration von gitolite

Comming soon…

Git Client

Die Verschiedenen Windows-Clients

  • git (Grundbasis, wird von den Nachfolgenden benötigt)
    Liefert eine Bash-Shell mit, in der gearbeitet wird. Für eine Shell sehr gute Anzeige der Informationen zum Repo. Zusätzlich existiert noch gitk als graphische Anzeige der Historie.
  • Git Extensions
    Mein aktueller Favorit. Ist eine eigenständige GUI, welche schön die Befehle für git kapselt. Anzeige einer History der zuletzt geöffneten Elemente, erstellen von Favoriten mit Gruppierungen, einfache Anzeige des aktuellen Branches und einfacher wechsel möglich, Gute graphische Aufbereitung des Historie, …
    Leider aktuell nur auf Englisch, aber ja nicht wirklich schlimm.
  • TortoiseGIT
    Arbeiten wie mit TortoiseSVN, fügt sich als Kontextmenu in den Explorer ein. Leider auch nur auf Englisch.

Egal welche Installation, würde ich unter Windows immer empfehlen das Putty bzw Plink benutzt werden sollte, und nicht über openssh. Putty bzw Plink harmoniert einfach viel besser mit Windows und ist schöner und einfacher zu konfigurieren. Zum weiteren ist es einfach um durch einen Proxy zu kommen.

Verschiedene Server-URL

Alle Werte in []-Klammern sind Optional. Werte in {}-Klammern sind Variablen die entsprechend von ihnen versorgt werden müssen

  • ssh://gitolite@{Server}[:{Port}]/{Projekt}
    Beispiel: ssh://gitolite@example.com:85/meinProjekt
    Beispiel: ssh://gitolite@example.com:85/Unterverzeichnis/meinProjekt
  • git://{Server}/{Projekt}
    git://example.com/meinProjekt
  • {sshUser}@{Server}:{Projekt}
    gitolite@example.com:meinProjekt
    gitolite@example.com:Unterverzeichnis/meinProjekt
  • {PuttySessionName}:{Projekt}
    Dazu im Nachfolgenden Kapitel mehr…

Verbindung mit SSH-Protokoll zum Git-Repo hinter einem Proxy

Wichtig: Der Proxy selbst darf den Port nicht blocken. Dies bedeutet, das entweder am Proxy den Port 22 nicht geblockt ist, oder man den SSH-Port auf einen nicht blockierten Port stellt. Häufig funktionieren Port 80 (http) und Port 443 (https).

Der zweite Vorteil diese Weges ist, das alle Einstellungen  im Putty vorgenommen werden und nur noch der Name der gespeicherten Session beim git clone angegeben werden muss.

Als Url wird folgender Befehl verwendet (Zur Einfachheit benutzt man häufig trotzdem den Git-Servernamen als Sessionname, also auch beim git-clone-Befehl):
git clone example.com:meinProjekt meinProjekt

Damit nun noch die ganze Verbindung durch den Proxy führt, muss Putty geöffnet werden. Dort müssen dann folgende Einstellungen unter den passenden Tabs eingestellt werden:

  • Session: Hostname und Port des Git-Servers
  • Connection->Proxy: Proxy-Type (bei mir http), Name und Port des Proxyservers, Benutzername und Passwort für die Proxyanmeldung. Alle anderen Einstellungen so lassen!
  • Connection->Data: Bei „Auto-Login username“ muss gitolite eingetragen werden
  • Connection->SSH->Auth: Bei „Private key file for authentication“ muss der Pfad zu ihrem Private Key Eingetragen werden.

Nun wieder auf die erste Seite zurück und bei „Saved Sessions“ einen eindeutigen Namen eingeben, zur Einfachheit den des Git-Servers, in unseren Beispiel „example.com“.

Es ist sehr wichtig der Session den gleichen Namen wie beim „git clone“ zu geben, weil plink so alle Einstellungen von der Putty Session findet und benutzt. Nämlich wenn Plink versucht den Rechnernamen aufzulösen, schaut es zuerst mit dem Rechnernamen auf die Namen der gespeicherten Sessions, wenn es dort nichts findet dann geht es direkt über die DNS-Auflösung.

Git Befehle

Comming soon…

MinGW64 auch einfacher

Nach längerem bemühen mit dem MinGW64 hab ich jetzt noch eine einfache Möglichkeit gefunden den MinGW64 zu installieren. Unter http://tdm-gcc.tdragon.net/ findet man den Installer. Es gibt verschiedene Versionen, einen für 32-Bit-Version komplett, einen für 64-Bit Version komplett und einen Webinstaller, bei dem man genau angibt was man installiert haben möchte und nur der Teil geladen wird.

Dieser zum einem aktueller als der MinGW64 (Hat aktuelle die Version 4.5.1) und kann auch Programme als 64-Bit-Version erzeugen. Und natürlich ist es viel einfacher als sich die Versionen alles selbst zusammen zu suchen und sie auszupacken. Dagegen gibt es nur einen Nachteil, das der von TDM etwas älter ist, was mir persönlich nicht wirklich stört.

Daher werde ich jetzt wohl komplett auf TDM umsteigen.

Notepad++ und LaTeX

Da ich schon seit längerem mich wieder mit LaTeX beschäftigen wollte und ich gerne mit Notepad++ arbeite, habe ich nach einer Möglichkeit gesucht dies zu verbinden. Und ja es gibt eine. Zuerst benötigen wir die entsprechende Software dazu, zu finden unter folgenden Links:

Notepad++ :  Der Texteditor
miktex :  Die bekannste Windowssoftware für LaTeX
pdflatex Kommandos :  Aufrufparameter der Exe

Nach dem Download entsprechend die Software installieren. Bei miktex hab ich mir „nur“ die Portable-Version geholt. Diese reicht auch und muss nur entpackt werden aber bei den Aufrufen im Notepad++ muss entweder der komplette Pfad angegeben werden oder das bin-Verzeichnis muss selbst in die PATH-Variable eingetragen werden.

Nun starten wir Notepad++. Fügen ein kleines Beispiel ein, speichern es und drücken F5. In dem nun erscheinenden Fenster geben Sie folgende Zeile ein (Daran denken wenn Sie die Portable-Version benutzen das pdflatex.exe und texify.exe mit dem kompletten Pfad angeben müssen):

cmd /c cd /d „$(CURRENT_DIRECTORY)“ && „pdflatex.exe“ -shell-escape „$(FILE_NAME)“ && „texify.exe“ –clean –pdf –run-viewer „$(FILE_NAME)“

Kurze Erklärung zum Aufruf:
cmd /c => Startet eine Shell und führt das nachfolgende Kommando aus und schließt wieder
cd /d „..“ => Wechselt in das Verzeichnis der aktuell gewählten Datei (Damit die pdf-Datei im selben Verzeichnis wie die tex-Datei abliegt
&& => Verknüpft mehrere Befehle
pdflatex … => erstellt die aux-Datei (wird für texify benötigt)
texify … => erstellt die pdf-Datei und öffnet die Datei

Über einen Klick auf Speichern können Sie den Aufruf im Notepad++ speichern und mit einem Namen sowie einem Shortcut versehen. Diese Eintrag finden Sie dann im „Ausführen“-Menü als eigenen Punkt.

Unter Einstellungen->Tastatur->Run commandos(Tablasche im Fenster)  können Sie falsch gespeicherte Kommandos auch ohne Probleme wieder löschen per Rechtsklick.

CodeBlocks MinGW Linker Einstellungen (Programme ohne MinGW Laufzeit-Dlls)

Da ich mir des öfteren auch schon die Frage gestellt habe, wieso ich immer diverse Laufzeit-Dlls bei meinen durch MinGW übersetzten Programmen mitgeben muss und ich es erst heute wieder in einem Kommentar aufkam, hab ich mir die Mühe gemacht und danach gesucht. Natürlich wurde ich auch fündig und es auch gar nicht so schwer, nachdem man Verstanden hat wo man die Parameter einstellen muss.

Die Rätselhaften Parameter sind folgende:

-static-libgcc -static-libstdc++

Das war der erste Teil. Der zweite Teil war dann noch wo gebe ich diese Flags bei CodeBlocks an. Und wer lesen kann ist klar im Vorteil, man muss diese beim Linker und _NICHT_ beim Compiler angeben. Also Rechtsklick aufs Projekt und zu den „Build options…“. In der Tablasche „Linker settings“ findet man den Frame „Other linker options:“ und dort trägt man beide Parameter ein. Sieht dann ungefähr so aus:CodeBlocks Linker EinstellungenWie man hier noch sieht, gibt stehen 2 weitere Parameter drin, um die folgende Warnmeldung die ich seit neuestem sehen zu deaktivieren:

warning: auto-importing has been activated without –enable-auto-import specified on the command line.

Sollte ich noch weitere wichtige Parameter vergessen habe einfach einen Kommentar hinterlassen oder per Mail zukommen dann werden Sie hier mit aufgenommen.

Boost mit MinGW64

Zuerst brauchen wir eine Lauffähige MinGW64 Umgebung. Eine Installationsleitung findet man dazu hier.

Nachdem man MinGW64 besitzt sollte man sich noch die Quellen von boost holen, am einfachsten von Ihrer Website http://www.boost.org/users/download/ laden. Es wird eigentlich nur die boost-Quellen selbst benötigt, da in diesem auch immer die Quellen von bjam dabei sind. Und hier findet man noch eine Installation zu Perl, wovon boost nicht abhängig ist, aber wenn man Sie installieren möchte dann vor dem übersetzten.

Nun müssen die Quellen noch entpackt werden. Und dann stellen wir uns in den entpackten Ordner mit der Eingabeaufforderung.

Mit dem Nachfolgenden Befehl wird die Pfad Variable so gesetzt das ein direkter Aufruf der Komponenten möglich ist, wobei der Pfad entsprechend angepasst werden muss:

SET PATH=C:\Programme\MinGW64\bin;%PATH%

Nun erstellen wir uns bjam mit folgendem Aufruf direkt im boost-src Ordner:

bootstrap.bat  ‚ Damit hat er bei mir immer den MS Compiler benutzt
oder: tools\jam\src\build.bat [COMPILER] (zB msvc, gcc, ….)

Da bei mir der Aufruf von build.bat mit mingw oder gcc nicht funktioniert hat, hab ich denn die Datei „x86_64-w64-mingw32-gcc.exe“ im bin-Verzeichnis in „gcc.exe“ umbenannt und dann build.bat nochmals mit gcc aufgerufen und schon ging es! Dafür musste ich dann die bjam.exe per Hand aus dem „bin.ntx86_64“-Ordner in die Root des boost-Ordners kopieren.

Und nun wird boost erstellt. Dies wird mit folgenden Befehlen durchgeführt, einer für die statischen Libs und einer für dynamischen Libs:

bjam –prefix=<PfadErstellteDateien> –without-mpi –without-python toolset=gcc address-model=64 variant=release link=static threading=multi install
bjam –prefix=<PfadErstellteDateien> –without-mpi –without-python toolset=gcc address-model=64 variant=release link=static threading=multi install

Die „–without..“-Parameter werden nicht unbedingt gebraucht, so sieht man aber keine Meldungen darüber. Nun müssen entweder die Dateien noch ins MinGW Verzeichnis kopiert werden oder in der IDE die Pfade passend gesetzt werden.

Da ich mir die ganzen Kommandos nicht immer einzeln tippen wollte bei jeder neuen Version hab ich mir ein kleines Batch-File geschrieben, welches eine Ebene höher als die Root der Quellen von boost abgelegt ist. In diesem werden am Anfang alle Pfade gesetzt und die Datei nur noch ausgeführt werden. So muss auch bei jeder neuen Version nur die Pfadangabe angepasst werden und die Datei nochmal ausführen damit mit der aktuellen Version gearbeitet werden kann. Hab die Datei aber immer aus der Eingabeaufforderung gestartet, durch Doppeltklick ging irgendwie immer was schief. Hier die Datei: boost_install.cmd (Das .txt muss durch .bat oder .cmd ersetzt werden, Download am einfachsten über Punkt „Verlinkten Inhalt speichern unter…“ im Kontextmenü)