Redmine Installation auf FreeBSD und Apache 2.4

Abhängigkeiten

  • postgresql93-server
  • apache24
  • ap24-mod_fastcgi
  • fcgi-devkit

Installation

Datenbank einrichten

PostgreSQL muss eingerichtet sein.

Benutzer erstellen

Datenbank erstellen

Vorbereitungen

VirtualHost

In der Datei /usr/local/etc/apache24/httpd.conf die Zeile

einklammern oder hinzufügen.

Einen VirtualHost in der Datei /usr/local/etc/apache24/extra/httpd-vhosts.conf hinzufügen.

Redmine einrichten

fcgi-Datei kopieren und einrichten

Datenbank einrichten

Die Datei /usr/local/www/redmine/config/database.yml.example nach database.yml kopieren:

Die Datei /usr/local/www/redmine/config/database.yml bearbeiten:

Abhängigkeiten installieren

Die Datei Gemfile.local erstellen mit folgendem Inhalt

und fcgi installieren

Sessions einrichten

Datenbank-Schemas installieren

Test

Öffnet auf localhost den Port 3000. Kann also nur auf der selben Maschine getestet werden.

Anhänge konfigurieren

Die Datei /usr/local/www/redmine/config/configuration.yml bearbeiten und folgendes konfigurieren:

Abschließende Konfiguration

In der Datei /usr/local/redmine/config/configuration.yml alles weitere wie E-Mail, Repo usw. konfigurieren.

Rechte vergeben:

 

compow – Unser Unternehmensportal – Ein technischer Überblick

compow ist heute online gegangen, ein Portal für Unternehmen, bei dem Unternehmer ihre Firma oder ihre Firmen kostenlos vorstellen können.

Aber wie kann man ein solches System technisch aufbauen? Für technikinteressierte möchte ich das einmal kurz beschreiben.

Die Plattform

Beginnen möchte ich mit der Plattform. Die Website und alle Dienste, die sie benötigt, laufen auf FreeBSD 11. Nahezu alles ist in C++ geschrieben und setzt auf wxWidgets und der DSLib auf. Als Datenbank wird PostgreSQL genutzt.

Wir nutzen schon seit Jahren BSDs, allen voran FreeBSD und haben uns dementsprechend natürlich für dieses Betriebssystem entschieden. Darauf installiert ist die DSLib, eine interne Bibliothek, die viele „Probleme“ abstrahiert, wie beispielsweise den Datenbankzugriff oder auch die Websiteentwicklung, Sockets und vieles mehr. Sie nutzt ausgiebig wxWidgets.

Darauf aufbauend läuft ein Serverprogramm, welches die Kommunikation mit der Datenbank gewährleistet und sich um die Authentifizierung kümmert und über SSL mittels JSON mit den angehängten Programmen kommuniziert. Die Serversoftware ist sehr klein, da alle Funktionen über Shared Objects dynamisch hineingeladen werden. Somit ist der Austausch von Funktionen immer sehr einfach und eine Verteilung des Servers mit dedizierten Funktionen über mehrere Hardwareserver sehr leicht.

Die Website ist ein einfacher Client, der mit dem Server kommuniziert, selbst nicht viel Logik beinhaltet und hauptsächlich nur als Frontend eingesetzt wird. Nahezu die gesamte Logik übernimmt die Serversoftware. Auch die Website ist mit C++ entwickelt und nutzt HTML5, CSS3, JQuery und Bootstrap.

Damit wir die Datenbank einfach bearbeiten können, gibt es ein grafisches Administrationprogramm, welches ein handelsübliches wxWidgets-GUI-Programm ist. Dieses verbindet sich, genauso wie die Website, auch mit dem Server und kommuniziert per JSON über SSL.

Um die Stellenangebote zu importieren, haben wir eine kleine C++-Software geschrieben, die mittels CURL die jeweiigen XML-Feeds herunterlädt und dann per DSLib in die Datenbank schreibt. Das Programm wird nachts per Cron aufgerufen. Danach wird die Datenbank reorganisiert.

Dann gibt es noch ganz viele Hilfsprogramme, die für das ein oder andere da sind und Entwicklungszeit einsparen.

Die Entwicklungsumgebung

Wie entwickeln wir eigentlich? Die Frage lässt sich leicht beantworten: Hardcore (:

Die Hauptentwicklung findet auf Client- und Serversystemen unter FreeBSD statt. Als Compiler nutzen wir hauptsächlich Clang++. Git ist unser Versionsverwaltungssystem und als Editor kommt zu 99% VIM zum Einsatz. Als PostgreSQL-DB-Frontend nutzen wir pgadmin3. Bilder werden in Inkscape und Gimp erstellt und bearbeitet. gmake ist unser Buildsystem. Mit DSTesting wird unser Code getestet. Um komfortabel mit CSS arbeiten zu können, nutzen wir less (lessc).

Wenn Ihr Fragen habt, schreibt sie gerne in die Kommentare.

Viele Grüße

Thorsten

wxWidgets 2.8.12 unter Windows (7) 32bit kompilieren – OpenSource GUI-FrameWork und mehr

Wir benötigen zwei Pakete

Wichtig ist, dass beide Pakete direkt nach C:\ installiert werden und keine Leerzeichen im Pfad enthalten sind.

Ist beides installiert, fügt man der PATH-Variablen den Pfad zu den MINGW-Binaries hinzu. In meinem Fall

Dann startet man die PowerShell, wechselt ins wxWidgets-Verzeichnis und dort in „build\msw“. In meinem Fall

Dort gibt man folgende Befehlskette ein:

Hinweis: mit „-j#“ funktionierte bei mir der Kompilierungsvorgang nicht, so dass ich Make anwies, immer nur einen Prozess zu starten. Das dauert natürlich je nach Rechnergeschwindigkeit.

Dann ist wxWidgets installiert und nutzbar.

Android-Entwicklung unter FreeBSD – Man ist nicht auf Linux angewiesen. Naja, doch, ein bisschen.

Android-Anwendungen lassen sich neben Linux, Mac OS X und Windows auch auf FreeBSD entwickeln. Dazu dient diese Schritt-für-Schritt-Anleitung. Ich habe das auch in den bsdforen.de gepostet.

Schritt 1 – Installation der Linux-Emulation:

Schritt 2 – Linux-Java-SDK installieren

Mit Version 7 (1.7) hatte ich Probleme, deshalb installierte ich Version 6 (1.6). Man muss es von Oracle herunterladen, wozu ein Account dort benötigt wird, und dann nach /usr/ports/distfiles kopieren.

Schritt 3 – Android-SDK installieren und entpacken

Die SDK-Tools einzeln reichen, wenn man kein Eclipse nutzt (wie ich). Man muss die Version für Linux herunterladen.

http://developer.android.com/sdk/index.html

Danach das Toolkit entpacken.

Schritt 4 – Systemanpassungen

Die Datei „android“ im SDK unter „tools“ muss angepasst werden.

java_cmd=“java“ ändern in java_cmd=“/usr/local/linux-sun-jdk1.6.0/bin/java“

Ebenso muss die Variable JAVA_HOME angepasst werden mit dem folgenden Pfad:

/usr/local/linux-sun-jdk1.6.0

Schritt 5 – SDKs herunterladen

Auf der Kommandozeile „android“ starten und die SDKs installieren, die man benötigt. Der Download kann einige Zeit in Anspruch nehmen

Schritt 6 – adb installieren

Schritt 7 – Android-Gerät anzeigen

In Android muss natürlich USB-Debugging eingeschaltet sein.

Werden keine Geräte angezeigt, hilft es bei mir, mit „adb kill-server“ das Problem wieder zu beheben. „adb devices“ listet dann die Geräte wieder auf. Das passiert bei mir, wenn das Gerät zwischendurch abstecke.

Android wird nachfragen, ob man den verbundenen Computer erlauben will, dass er auf das Gerät zugreifen darf. Das sollte man natürlich bestätigen.

Schritt 8 – dx fixen

Beim Ausführen von „ant debug“ kann es zu dem folgenden Fehler kommen: Execute failed: java.io.IOException: Cannot run program „xxx/dx“: java.io.IOException: error=2, No such file or directory. Der Shell-Pfad in der Datei ist falsch gesetzt und geht auf /bin/bash anstelle /usr/local/bin/bash. Es genügt, die Datei zu bearbeiten und die Shebang zu ändern (z.B. /usr/bin/env bash). Andernfalls kann man auch /usr/local/bin/bash nach /bin/bash linken, was aber unsauber ist.

Schritt 9 – Erstes Projekt

http://developer.android.com/training/basics/firstapp/creating-project.html

Als Beispiel

Dort das richtige Target aussuchen. In meinem Fall ist das für Android 4.3 das Target mit der ID 27:

id: 27 or „android-18“
Name: Android 4.3
Type: Platform
API level: 18
Revision: 2
Skins: WXGA720, WSVGA, WXGA800, WVGA854, WQVGA432, HVGA, WXGA800-7in, WQVGA400, QVGA, WVGA800 (default)
ABIs : armeabi-v7a, x86

Dann das Verzeichnis erstellen:

und dann das Projekt initiieren:

Danach kann man es direkt kompilieren:

und so auf das Android-Gerät installieren:

bzw. zur Reinstallation

Viel Spaß bei der Android-Entwicklung unter FreeBSD.

FreeBSD und VirtualBox: scp und afp und andere Dinge gehen nicht mehr – Cannot allocate memory

Bei der Nutzung von VirtualBox kann es passieren, dass scp oder auch afp und andere Dienste keinen Speicher reservieren können (Cannot allocate memory). Um das Problem zu beheben, genügt es, eine Systemvariable zu setzen:

net.graph.maxdata=65536

Das muss in die Datei /boot/loader.conf. Danach muss der Rechner neugestartet werden.

FreeBSD-NIS-Server – Mac OS X-NIS-Client – Der Löwe brüllt anders

Standardmäßig werden Kennwörter in FreeBSD via MD5Hash in der master.passwd gespeichert. Leider hat Mac OS X 10.7 Lion damit ein Problem. Die Benutzeranmeldung funktioniert via NIS so leider nicht mehr.

Stellt man den Algorithmus aber auf ein anderes Verfahren, beispielsweise DES, ist das Problem behoben. Und das funktioniert so:

In der Datei /etc/login.conf wird unter default passwd_format von md5 einfach in des geändert. Nach dem Speichern der Datei muss die Datei noch ins von FreeBSD lesbare Datenbankformat umgewandelt werden. Dies geschieht mit cap_mkdb /etc/login.conf. Von den Besuchern, die sich per NIS anmelden, muss das Kennwort erneut "gehashed" werden (passwd <username>).

Nach cd /var/yp && make und Neustart des Macs sollte die Anmeldung wieder wie gewohnt funktionieren.

FreeBSD als Time Machine-Server für Mac OS X – Netatalk ganz einfach

(Diese Anleitung bezieht sich auf FreeBSD 8.2 und 9.0RC1 mit netatalk 2.2.1.1)

Bis Mac OS X Snow Leopard (10.6) habe ich Time Machine immer via iSCSI auf FreeBSD genutzt, welche ich mit dem kostenlosen iSCSI-Initiator von globalSAN genutzt habe. iSCSI auf FreeBSD einzurichten ist sehr einfach und globalSAN lief immer recht gut.

Nachdem globalSAN aber zum aktuellen Zeitpunkt nicht mehr vernünftig auf Lion funktioniert (falsche Festplattengröße wird angezeigt, das Festplattendienstprogramm kann das Device nicht formatieren oder hängt sich sogar auf, via Terminal kann man mit newfs kein Dateisystem erstellen oder Time Machine meldet einfach laufend Fehler) und globalSAN seinen Initiator jetzt kostenpflichtig gemacht hat, musste eine andere Lösung her.

Da fiel die Wahl auf netalk, womit man sein FreeBSD (oder Linux oder Solaris oder usw.) mit dem Apple File Protocol ausstatten kann. Da ich es nur für Time Machine benötige und alle weiteren Freigaben via NFS oder SMB laufen lasse, habe ich mich für die einfachste und zielgerichtetste Konfiguration entschlossen.

Netatalk wird über die Ports installiert (cd /usr/ports/net/netatalk && make install oder portinstall -c net/netatalk) und beim Konfigurieren wird alles außer APPLETALK abgewählt (im Notfall einmal mit make config nachsehen). Nach dem Kompilieren und Installieren befinden sich dann alle Konfigurationsdateien unter /usr/local/etc.

Die Datei netatalk.conf wird bearbeitet. Folgende Zeilen werden aktiviert und mit den folgenden Werten versehen:

AFPD_RUN=yes
ATALKD_RUN=no
PAPD_RUN=no

Nach dem Speichern erstellt man das Verzeichnis /var/AppleDB. Das darf ruhig root gehören. Dann benötigt man ein Verzeichnis, in dem man die Time Machine-Daten speichern kann. In meinem Fall ist das /server/timemachine. Diesen Pfad gibt man in der Datei AppleVolumes.default folgendermaßen an:

/server/timemachine TimeMachine allow:<benutzer> dbpath:/var/AppleDB options:usedot,noadouble,nohex,tm

<benutzer> muss durch den/die Benutzer ersetzt werden, der/die auf die Freigabe zugreifen können. Es muss unbedingt darauf geachtet werden, dass diese auch auf Unixebene Schreib- und Leseberechtigungen auf das Verzeichnis haben. Die Benutzer werden kommasepariert angegeben. Wichtig ist die Option tm am Ende. Ohne sie funktioniert Time Machine nicht.

Um netatalk zu starten, müssen in die Datei /etc/rc.conf noch die folgenden Zeilen ergänzt werden:

netatalk_enable=“YES“
cnid_metad_enable=“YES“
afpd_enable=“YES“

Dann kann netatalk mit

service netatalk start

gestartet werden. Mittels [Apfel]+[k] im Finder kann dann direkt die Verbindung zum Server aufgebaut werden. Bis die Freigabe in Time Machine erscheint, kann es ein paar Sekunden dauern (bei mir um die zehn). Anschließend können die Backups durchgeführt werden.

FreeBSD auf RAID1 (gmirror/geom_mirror) installieren – Installation via mfsbsd

Hier der kurze Ablauf:

  1. mfsbsd herunterladen
  2. ISO brennen
  3. von CD booten
  4. folgende Schritte befolgen:

# gmirror label -vb round-robin gm0 <DEVICE_0>
# gmirror load
# gmirror insert gm0 <DEVICE_1>

# fdisk -BI /dev/mirror/gm0
# bsdlabel -wB /dev/mirror/gm0s1
# bsdlabel -e /dev/mirror/gm0s1

# /dev/mirror/gm0: 8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 40G 16 4.2BSD 0 0
b: 4G * swap 0 0
c: * * unused 0 0
e: * * 4.2BSD 0 0

# newfs -O2 -U /dev/mirror/gm0s1a
# mount /dev/mirror/gm0s1a /mnt

# sysinstall

custom
options
install root: /mnt
distributions
minimal
commit

# rm -Rf /mnt/boot/kernel
# cp -Rp /mnt/boot/GENERIC /mnt/boot/kernel

/mnt/etc/rc.conf

defaultrouter=“<IP des Routers/Gateways>“
hostname=“<hostname.domain>“
ifconfig_<NETZWERK-INTERFACE>=“inet <IP> netmask <NETMASK>“
keymap=“german.iso“
sshd_enable=“YES“

/mnt/etc/fstab

# Device Mountpoint FStype Options Dump Pass
/dev/mirror/gm0s1b none swap sw 0 0
/dev/mirror/gm0s1a / ufs rw 1 1

/mnt/boot/loader.conf

geom_mirror_load=“YES“

# reboot

Das war es schon.

Kurztipp: Einschaltknopf für ACPI-Shutdown auf FreeBSD deaktivieren

Ich bin hier jetzt das zweite Mal mit dem Knie an den Einschalter gekommen. Direkt fährt der Rechner herunter. Mit der Einstellung

hw.acpi.power_button_state=NONE

in der Datei /etc/sysctl.conf kann das vermieden werden. Mittels

# sysctl hw.acpi.power_button_state=NONE

kann man das auch temporär einschalten.