instant jruby & derby environment für eine RoR Anwendung

Als angestammter Java-Entwickler geht es mir oftmals schwer von der Hand, einer Ruby on Rails (RoR) Anwendung mit relativ wenig Aufwand eine brauchbare Laufzeitumgebung zu bieten.
Normalerweise sollte das OS (MacOS 10.5.6) alles Brauchbare bieten. So ist oftmals eine Rails-Version installiert und auch das (standardmäßig genutzte) SQlite 3 ist vorhanden.
Dennoch sind es oftmals Plugins (spezielle Rails Version / spezielle gems), welche einen zusätzlichen Aufwand benötigen.
Nicht zu vergessen, dass RoR nicht auf allen Systemen vorinstalliert ist und dementsprechend ein interessierter Entwicklung von einem Out-of-the-Box Erlebnis weit entfernt ist.
Sehen wir den Tatsachen ins Auge… die Wahrscheinlichkeit eine installierte JVM vorzufinden ist (noch?) deutlich höher, als eine Lauffähige Ruby-Installation.
Was liegt also näher, als die benötigte Umgebung auf Java fußen zu lassen.
Hierzu werden verwendet:

  • jRuby in Version 1.1.5 (http://jruby.codehaus.org)
  • Derby-DB in Version 10.4.2.0 (http://db.apache.org/derby)
  • weiterhin wird eine installierte JVM (>1.5) vorrausgesetzt

 

Alles weitere wird mit Hilfe von shell-Scripten bewerkstelligt. Wobei momentan nur Unix-Scripte benutzt werden. Eine Portierung auf Windows sollte aber nur eine Sache von Minuten sein.
Es liegt eine RoR-Anwendung in einem Entwicklungs-Status vor. Diese wurde bisher in einem Netbeans-Enviroment mit einer SQlite-DB betrieben.
Das Verzeichnis ist folgendermaßen aufgebaut:

ROOT
|
|- microblog (dies ist unsere RoR-Anwendung)
|
|- derby (derby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib
|
|- jruby (jruby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib

Das Hauptproblem besteht darin, dass alle benötigten gems in das entsprechende Unterverzeichnis installiert werden müssen.
Weiterhin muss die Derby-DB mit dem entsprechenden Rake-Task auf mit der aktuellen Schema-Datei instanziiert werden.
Zuletzt sollen die vorhandenen User-Daten in die Derby-DB eingefügt werden.

  1. Anpassen der database.yml
    Wir nutzen weiterhin eine jdbc-Connection. Allerdings ändert sich der Treiber auf den der Derby-DB:
    database.yml

    development:
    adapter: jdbc
    driver: org.apache.derby.jdbc.ClientDriver
    url: jdbc:derby://localhost/microblog_development;create=true
    encoding: utf8
    pool: 5
    username: microblog
    password: microblog
    host: localhost
  2. Export der alten DB-Daten:
    Wir benutzen hierzu das Tool sqlitebrowser (http://sqlitebrowser.sourceforge.net) und erzeugen uns so einen SQL-Dump der alten SQLite-DB. Wir benutzen hierbei nur die SQL-Inserts für den User-Import. Diese speichern wir in die Datei:
    microblog/db/microblog.sql
  3. Für den Import erstellen wir einen Rake-Task:
    microblog/lib/tasks/sql-import.rake

    namespace :microblog do
    desc 'Import old SQL Data'
    task :sqlimport => :environment do
    dbConn = ActiveRecord::Base.establish_connection :development
    sql = File.open("db/microblog.sql").read
    sql.split(';').each do |sql_statement|
    dbConn.connection.execute(sql_statement)
    end
    puts "imported user data '#{Time.now}' "
    end
    end
  4. Erstellen des Setup-Scriptes:
    Folgende Schritte sind notwendig:

    1. Setzen aller benötiger Verzeichnisse
    2. installieren aller benötigter gems
    3. Starten des Derby-DB-Servers
    4. Rake db:migrate
    5. import der alten Daten
    6. Beenden des Derby-DB-Servers

    Das Script sieht wie folgt aus:
    jruby-setup.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es ist zu erwähnen, dass es notwendig ist, jeweils auf die entsprechende jRuby-Installation zu verweisen.
    Weiterhin benötigt jRuby den entsprechenden derbyClientDriver, welcher in die (von jRuby später verwendete) JAVA_OPTS-Variabel eingetragen wird.
    Ebenfalls musst der Classpath soweit angepasst werden, dass sowohl jRuby, als auch Derby über die notwendigen Bibliotheken verfügen.
    Als letztes ist noch erwähnenswert, dass die beiden Rake-Tasks jeweils aus dem App-Verzeichnis ausgeführt werden.

  5. Das Start-Script.
    Letzendlich sind auch zum eigentlichen Betrieb des Servers Anpassungen notwendig, da auch hier die jRuby-Instanz mit den verwendeten gems benutzt werden sollen.
    Das Script sieht wie folgt aus:
    run.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    export BASE_DIR=$BASE_DIR
    export JRUBY=$JRUBY
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    echo "starting microblog"
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/microblog/script/server
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es entspricht also einer abgespeckten Variante des Setup-Scriptes. Hierbei wird auch immer ein db:migrate aufgerufen, für den Fall, dass sich die DB-Struktur in der Zwischenzeit geändert haben sollte.

  6. Auslieferung ;-).
    Derby und jRuby belegen knapp 80 MB sodass es notwendig ist, die Dateigröße für den Transport zu verringern.
    Zuallererst sollten die benötigten gems am besten immer online bezogen werden, sodass man hier ein paar MB sparen kann.
    Weiterhin benutzen wir Jar um die vorhandenen Dateien auf ein 13 MB-Archiv zu packen.
    Die veränderten Scripte sehen wie folgt aus:
    Zuerst das Script, welches die vorhandenen Dateien packt:
    pack.sh

    #!/bin/sh
    find . -name '*.DS_Store' -type f -delete
    jar -cvf statusQ-runtime.jar derby/ jruby/ run.sh pack.sh microblog/db/microblog.sql microblog/lib/tasks/sql-import.rake
    rm -R jruby
    rm -R derby
    rm run.sh
    rm microblog/db/microblog.sql
    rm microblog/lib/tasks/sql-import.rake
    rm pack.sh

    Und nun das geänderte jruby-setup.sh Script, welches vor dem eigentlichen Setup noch für das Entpacken aller Dateien verantwortlich ist:
    jruby-setup.sh

    #!/bin/sh
    jar -xvf statusQ-runtime.jar
    rm -R META-INF
    chmod +x run.sh
    chmod +x setup.sh
    chmod +x pack.sh
    chmod +x jruby/bin/jruby
    chmod +x derby/bin/startNetworkServer
    chmod +x derby/bin/stopNetworkServer
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

Als nächstes sollte die Scripte auf Windows portiert werden.
Weiterhin wäre es interessant, die Derby/jRuby Binaries jeweils direkt online zu beziehen.

what to do, if you locked yourself out from Mac OS?

a wood with a chain and a padlock

Yesterday I found myself in a strange situation:

Every Shell Command I tried to use ended up with a “command not found“. This happened with sudo, nano … you name it.

After a short time, I figured out that the folder /usr/bin (where all these programs are stored) had only executable rights for the owner (so admin:wheel).

As a normal user I was not able to use them.

So how to change this if you cannot sudo ?

As always in MacOS, the best way to fix this, is to boot into Singe User Mode (restart and press the Apple/Command Key + “S”).
After you got into the Terminal view you have to scan the filesystem for errors:

/sbin/fsck -fy 

And then remount it as writable:

/sbin/mount -wu /

Now, you can alter the user rights for /usr/bin with:

chmod 755 /usr/bin

After a reboot you are again able to execute the commands.
If you still have problems you should control your PATH-settings.

echo $PATH 

It should contain /usr/bin near the beginning.

Nachlese: 25C3

Guten Tag Welt,
Hello World,

I wish you all the best for the future and a great year 2009!


Heute mal wieder was auf Deutsch.
Today again in german!


 

Zum Ende des Jahres 2008 habe ich mit einem Kollegen den Chaos Communication Congress in Berlin besucht.
Wir waren zum ersten (und definitiv nicht zum letzten) Mal dort.
Anfangs ein paar grundlegende Tipps um dort zu überleben:

Essentiell wichtig ist es, für die eigene Infrastruktur zu sorgen:

1. Mehrfachstecker (mindestens 6-fach, besser noch mehr).
2. Netzwerk-Switch – je mehr Anschlüsse man über hat, desto eher kann man sich wo anschließen.
3. Eine externe Festplatte (am besten 2,5″ mit USB-Stromversorgung, da der Strom zeitweise ausfiel und so die Festplatte vom Laptop Strom erhalten kann)
4. Laptop oder Netbook (das scheint wirklich der Trend zu sein in diesem Jahr)
5. Gute und bequeme Kopfhörer (es werden alle Vorträge im Netz übertragen, sodass man diese auch gut am Laptop verfolgen kann)

Das waren so die Dinge, die mir aufgefallen sind.
Letzendlich waren es _VIELE_ Menschen in dem kleineren BCC.

Bei den meisten Vorträgen musste man schon sehr früh innerhalb des Vortragsraumes sein.
Die Vorträge waren durchgehend sehr informativ und auch durchgehend auf hohem Niveau.
Ich habe wirklich sehr viele Anregungen mitgenommen.
Interessant war es, zeitgleich die Reaktionen der deutschen News-Portale mit zu verfolgen…

Also…. dieses Jahr fahre ich wieder hin!…. Aber deutlich besser vorbereitet :D.

Abschließend noch ein Video von dem “DDoS-Angriff” auf Dunkin’ Donuts:

sophisticated Backups mit Rsync

Backups sind wichtig.
Jeder der einmal vor einer kaputten, ratternden Festplatte gesessen hat, weiß wie frustrierend das Wissen ist, alle seine Daten ins informationstechnische Nirwana entschwinden zu sehen.
Ist ein Backup der persönlichen Daten noch mit relativ geringem Aufwand möglich (so es denn regelmäßig veranstaltet wird), so wird ein Backup eines Server-Systems in vielen Dingen anspruchsvoller.
Dies fängt damit an, dass reinen Datenmengen oftmals das Vielfache eines Ein-Benutzer-Systems betragen. Okay in heutige Zeit, wo ein jeder zig GBs an Musik und Videos auf dem Rechner hat, muss man das natürlich relativieren.
In diesem Beitrag möchte ich ein Bash-Script vorstellen, welches folgende Dinge leistet:

  1. Sichern von N-Hosts über RSYNC
  2. Sichern von N-Verzeichnissen auf jedem Host
  3. Inkrementelles Sichern (es werden nur Unterschiede gesichert/übertragen)
  4. Zusammenführen von täglichen (inkrementellen) Backups zu wöchentlichen Vollbackups.
  5. die aktuellen Backups sind jeweils unter einem Hardlink “latest” erreichbar.

Nachfolgend erfolgt eine Beschreibung über den Ablauf des Scriptes.
Es wird Momentan durch eine Sicherung von 3 Serversystemen und ca. 20 GB an reinen Nutzdaten getestet.

  1. Stelle sicher, dass alle notwendigen Verzeichnisse vorhanden sind:
    • Verzeichnis “log” für log-Dateien der Sicherungen
    • Verzeichnis “backup” für die eigentlichen Sicherungen
    • Je Backupquelle ein Verzeichnis
    • Innerhalb jedes Quellverzeichnisses ein Verzeichnis für tägliche und eines für wöchentliche Sicherungen
  2. Stelle sicher, dass alle Config-Dateien vorhanden sind:
    • sources.txt mit den Namen der zu sichernden Hosts/Verzeichnisse
    • exclude.txt mit den Dateien, welche nicht gesichert werden sollten (z.B. Thumbs.db)
    • innerhalb jedes Quellverzeichnisses eine Datei namens src-root.txt (mit dem ROOT der Sicherung)
      und src-folders.txt (mit den einzelnen Verzeichnissen)

Der Aufbau des Root-Verzeichnisses sieht nun wie folgt aus.

ROOT
|
|-log
|-sources.txt
|-exclude.txt
|-backup
|-host1.de
|-host2.de
|-src-root.txt
|-src-folders.txt
|-daily
|-weekly

Ein Beispiel für eine sources.txt sieht wie folgt aus:

host1.de
host2.de

Ein Beispiel für eine exclude.txt sieht wie folgt aus:

Thumbs.db
.DS_Store

Eine src-root.txt könnte so aussehen:

user@host1.de:

Eine src-folders.txt könnte so aussehen:

/home
/etc
/var/log
/var/www

Ablauf der Sicherung:

  • Generiere Log-Datei.
  • Iteriere über alle Quellen aus sources.txt
  • Überprüfe ob alle Quellen Verzeichnisse zum Sichern enthalten.
  • Überprüfe ob lokal Verzeichnisse für die Sicherung existieren – wenn nicht lege sie an.
  • Erstelle tägliches Backup – existiert ein vorheriges Backup, so sichere nur die Änderungen.

Dies passiert mit folgendem Befehl:

rsync -zrva –exclude-from=exclude.txt –link-dest=<hardlink-zu-altem-backup>  <sourcefolder>/ <backupfolder>/daily/<tag>/<zu-sicherndes-Verzeichnis>
Hierbei werden alle Benutzerrechte mitgesichert.
Setzte Hardlink vom letztem täglichen Backup auf aktuelles tägliches Backup.
Überprüfe ob Sonntag ist ( date +%w = 0)
Wenn ja, synchronisiere letztes tägliches Backup mit wöchentlichem (neuen) Backup.
Setzte Hardlink vom letztem wöchentlichen Backup auf aktuelles wöchentliches Backup.
Lösche alle täglichen Backups.
Setzte Hardlink vom letztem täglichen Backup auf aktuelles wöchentliches Backup.
So werden maximal 7 tägliche inkrementelle Backups erstellt und pro Jahr 52 wöchentliche Full-Backups.

#!/bin/sh

# Philipp's backup-scripte version 2

ROOT=/tank/backup/server
BACKDIR=$ROOT/backup
D=`eval date +%Y-%m-%d`
W=`eval date +%Y-%W`
w=`eval date +%w`
LATEST=latest
EXCLUDE=$ROOT/exclude.txt
SOURCES=$ROOT/sources.txt

LOG=$ROOT/log/$D.log

# Array of all needed folders
folders=( $ROOT/log $ROOT/sources )
files=( $EXCLUDE $SOURCES $LOG)

for folder in ${folders[@]}; do
    if [ ! -d $folder  ] ; then mkdir -p $folder; fi
done

for file in ${files[@]}; do
    if [ ! -f $file  ] ; then touch $file; fi
done

log () {
    if [  -z "$1" ] ; then echo "" > $LOG ; fi
    echo $1
    echo $1 >> $LOG    
}

# Ab hier gehts dann richtig los :-)

log

log "STARTING BACKUP..."
log "date: $D"

#stopping start time
#TIME0= expr `date +%s`;

# backup following sources
for SOURCE in `cat $SOURCES`; do
    log ""
    log "=================================================================="
    log "====== backup: $SOURCE "
    if [ ! -d $BACKDIR/$SOURCE/daily/$D  ] ; then mkdir -p $BACKDIR/$SOURCE/daily/$D; fi    
    if [ ! -f $BACKDIR/$SOURCE/src-root.txt  ] ; then touch $BACKDIR/$SOURCE/src-root.txt; fi    
    if [ ! -f $BACKDIR/$SOURCE/src-folders.txt  ] ; then touch $BACKDIR/$SOURCE/src-folders.txt; fi      
    #Logindaten lesen
    LOGINDATA=`cat $BACKDIR/$SOURCE/src-root.txt`
    if [ ! "$LOGINDATA" = "" ]; then
        log "====== benutze $LOGINDATA" 
        log "=================================================================="
        log ""
        for FOLDER in `cat $BACKDIR/$SOURCE/src-folders.txt`; do
            log "backup up... $FOLDER"
            mkdir -p $BACKDIR/$SOURCE/daily/$D/$FOLDER
            ### wenn schon latest-day vorhanden, dann sichere nur ânderungen
            if [ ! -d $BACKDIR/$SOURCE/daily/$LATEST  ] ; then 
                rsync -zrva $OLD --exclude-from=$EXCLUDE --link-dest=$BACKDIR/$SOURCE/daily/$LATEST/$FOLDER  $LOGINDATA/$FOLDER/ $BACKDIR/$SOURCE/daily/$D/$FOLDER | tee -a $LOG
            else
                rsync -zrva $OLD --exclude-from=$EXCLUDE $LOGINDATA/$FOLDER/ $BACKDIR/$SOURCE/daily/$D/$FOLDER | tee -a $LOG
            fi   
        done
        ### setze latest-day von altem Stand auf aktuelles Backup
        if [ -d $BACKDIR/$SOURCE/daily/$D ] ; then
            if [ -d $BACKDIR/$SOURCE/daily/$LATEST ] ; then rm $BACKDIR/$SOURCE/daily/$LATEST; fi
            ln -s $BACKDIR/$SOURCE/daily/$D $BACKDIR/$SOURCE/daily/$LATEST    
        fi

        ## wenn ende der Woche, dann erstelle Snapshot der Woche
        if [ "$w" = "0" ]; then
            log "create week-backup for $W"
            for FOLDER in `cat $BACKDIR/$SOURCE/src-folders.txt`; do
                mkdir -p $BACKDIR/$SOURCE/weekly/$W/$FOLDER
                rsync -zrva $OLD --exclude-from=$EXCLUDE $BACKDIR/$SOURCE/daily/$D/$FOLDER/ $BACKDIR/$SOURCE/weekly/$W/$FOLDER | tee -a $LOG
            done
            ### setze latest-week von altem Stand auf aktuelles Backup
            if [ -d $BACKDIR/$SOURCE/weekly/$LATEST ] ; then rm $BACKDIR/$SOURCE/weekly/$LATEST; fi
            ln -s $BACKDIR/$SOURCE/weekly/$W $BACKDIR/$SOURCE/weekly/$LATEST | tee -a $LOG 
            log "updating weekly latest"

            ### lââsche alte Backups
            log "delete all daily folders"
            rm -R $BACKDIR/$SOURCE/daily/*

            ### setze latest-day von altem Stand auf aktuelles Backup
            if [ -d $BACKDIR/$SOURCE/daily/$LATEST ] ; then rm $BACKDIR/$SOURCE/daily/$LATEST; fi
            ln -s $BACKDIR/$SOURCE/weekly/$W $BACKDIR/$SOURCE/daily/$LATEST | tee -a $LOG
            log "updating daily latest"
        fi
    fi
done

#stopping end time
#TIME1= expr `date +%s`;
#ERG = expr `$TIME1 - $TIME0`;

log "=================================================================="
log "DONE"
#log "using $ERG seconds"
log "=================================================================="

Safari, Spotlight Craches after Timemachine Restore

So i almost gave up with solving some strange Software Crashes
For Example:

Spotlight wasn’t active. There was even no Spotlight icon.
Safari Crashes when i type the second word into a google search field.

After a while i browsed through my folder-tree and so i detected, that the tmp folder.
I remember that i set /tmp to be excluded during TM-Backups so save so Disk Space.
So after i restored this folder with

   cd /
   sudo ln -s /private/tmp /tmp
   sudo chmod 1777 /tmp

everything works fine again. IMHO it is a bug in the TM-System-Restore Workflow.

Blogged with the Flock Browser

Subversion in a nexenta zone

grass growing in cubic stone pot

To sort Things out, I will use another feature of Nexenta (OpenSolaris): Zones.
So I am sure, that my Subversion Server is in its own enviroment and has its own IP.

There are two great howtos:

1. Creating a New Zone in Nexenta
2. Installing SVN 1.4 in a Nexenta Zone

I am almost done with backing up all my stuff.
I really hope to improve the network performance with a hardware upgrade :-).

Blogged with the Flock Browser

patch File for compiling storeGPU on Macos with CUDA 2.0

I am currently working with a middleware-App Demonstration using Nvidia’s CUDA.
After some time i make the example to work on MacOS 10.5.

You will need:

CUDA SDK and Toolkit for MacOS (you need to add the kext driver manually when installing the Toolkit)

the StoreCPU Sources

 

If you try to compile the source you will get some errors like this:

 

    ./storeGPU.h:41:19: error: cutil.h: No such file or directory
        (you need to include your inc path)

    

    ld: library not found for -lcutil
        (you need to include your lib path)

 

    storeGPU.cu:491:19: error: macro “CUT_DEVICE_INIT” requires 2 arguments, but only 1 given

        (with version 2.0 of CUDA there is another CUT_DEVICE_INIT-Method)

    

    Undefined symbols:

    “sg_init()”, referenced from:

    run_md5_overlap_test()     in main.o

    run_sha1_overlap_test()     in main.o

        (here you need to add parameter to match with the new CUT_DEVICE_INIT-Call)

 

All Settings are done with the following Patch.

If your CUDE-SDK is installed in /Developer/CUDA  (normal setup path)

You may use the following patches to make the storeGPU-Demo to run:

storegpu-diff

Nexenta iSCSI Target Setup

root@sunny:~# zfs create tank/home
root@sunny:~# zfs create tank/home/philipp
root@sunny:~# zfs create -V 250M tank/home/philipp/TM
root@sunny:~# zfs set shareiscsi=on tank/home/philipp/TM
root@sunny:~# iscsitadm modify target -p 1 tank/home/philipp/TM
root@sunny:~# zfs list
NAME                             USED  AVAIL  REFER  MOUNTPOINT
syspool                          689M  16.6G    23K  none
syspool/rootfs-nmu-000           688M  16.6G   641M  legacy
syspool/rootfs-nmu-000@initial  47.3M      –   631M  –
tank                             250M  1.34T    21K  /tank
tank/home                        250M  1.34T  27.5K  /tank/home
tank/home/philipp                250M  1.34T    27K  /tank/home/philipp
tank/home/philipp/TM             250M  1.34T    24K  –
tank/media                        18K  1.34T    18K  /tank/media
root@sunny:~# iscsitadm list target -v
Target: tank/home/philipp/TM
    iSCSI Name: iqn.1986-03.com.sun:02:f683c44e-e774-c018-9f6f-89ef914db75b
    Alias: tank/home/philipp/TM
    Connections: 0
    ACL list:
    TPGT list:
        TPGT: 1
    LUN information:
        LUN: 0
            GUID: 0
            VID: SUN
            PID: SOLARIS
            Type: disk
            Size:  250M
            Backing store: /dev/zvol/rdsk/tank/home/philipp/TM
            Status: online

(via Solaris iSCSI Target with ESX 3.02 Server)

Blogged with the Flock Browser

Sunny Setup Part 1

Neues Wochenende, neues Glück :-).

Ich habe mittlerweile auch die anderen Betriebssysteme durch:

FreeBSD:
Obwohl dies einer meiner Favoriten war, werde ich nicht FreeBSD einsetzen. Die ZFS-Unterstützung ist teilweise noch erschreckend.
Ohne angepassten Kernel gibt es wohl noch des öfteren Kernelpanics. Weiterhin scheint bei dem FreeBSD-Projekt selber nach einer Umstellung des Packet-Servers auf ZFS
ein paar Probleme aufgetaucht zu sein.
pro:

  • Sehr schmale Installation möglich.
  • Unterstützung der eingebauten Encryption-Hardware (siehe VIA-Eden-Plattform)
  • Unterstützung von encrypted devices

contra:

  • Warnmeldung bei Netzwerkzugriffen (Packet lost/Packet Timeout)
  • ZFS ohne “Kernel-Hacking” nicht ausreichend stabil.

Zu Milax ist nicht viel zu sagen. Es ist scheint für einen kleineren Desktop eine gute Wahl zu sein (graphisch macht es schon etwas her und nutzt nur wenig Ressourcen).
Für einen Server ist es aber wohl wenig geeignet. Es gibt zwar eine spezielle Server-Version, allerdings ist auch hier die Unterstützung der VIA-NICs nicht gegeben.

Nachtrag:
OpenSolaris. Da OpenSolaris schon erfolgreich in NAS-Systemen eingesetzt wird [1,2,3], habe ich mir die Developer-Preview von Project Indiana besorg und testweise installiert.
Leider scheint es out of the Box nur möglich zu sein, eine Komplettinstallation mit Gnome usw. durchzuführen. Das ist schade, verspricht der Weg, den Sun mit Project Indiana eingeschlagen hat, doch durchaus vielversprechend zu sein. Aber anscheinend scheint auch hier die Hardwareunterstützungen auf reine Intel/AMD-Systeme beschränkt zu sein.

Nun sitze ich als wieder vor einem Nexenta-System.
Ich bin gerade dabei, ein iSCSI-Target aufzusetzen um dann mal einen aussagekräftigen Wert für die Datenübertragung erhalten zu können.

Blogged with the Flock Browser