Anleitungen/Tutorials

Benutzung der Datenaquisitions-Tools

Beispiel für Aufruf datataker:

 bin/datataker /dev/ttyS5

Obige Zeile verbindet sich mit dem ADC und gibt die Daten mit Timestamp auf stdout aus.

Um den Zusammenhang zwischen gemessenen Intensitäten und Koordinaten auszugeben ist

 macros/acquire

aufzurufen. Dieses Script gibt in dieser Reihenfolge folgende Werte auf stdout aus: timestamp ADC-Wert Azimut Höhe Stunde Deklination Controllertemperatur

 macros/acquire_ref

erweitert die Ausgabe von macros/acquire um eine weitere Spalte

per default wird hier 19 mal der feed gemessen und danach 1 mal den Referenzkanal Es gibt hier noch 3 wichtige (Stellungs)Parameter

• 1. Averaging Anzahl default:100
• 2. Verhältnis Signalwerte Referenzwerte default :20 heisst 19 Signal 1 Referenz
• 3. Gesamtzahl der auszugebenden Werte default :-1 (endlos)

Steuerung von Messungen

Steuerung über bash-Skripte

Das ist die flexibelste Art, Messungen auszuführen. Für die verschiedenen Aufgaben stehen im repo-tree im Unterverzeichnis macros/ (zusätzlich zu den reinen DAQ-Skripten, s.o.) folgende Steuerskripte zur Verfügung:

rt_scan_hor ... Messung in äquidistantem Grid in Horizontalkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

rt_scan_equ ... Messung in äquidistantem Grid in Äquatorialkoordinaten (mind. 5 Parameter benötigt, s. Usage-Hilfe bei Aufruf ohne Parameter)

Steuerung über Task Scheduler "RATSCHE"

Das sollte ab Januar 2011 die verbindliche (einzige) Möglichkeit von Messungen sein, da hier Kollisionen ausgeschlossen sind.

Server-Prozess

Auf dem Radioiden muß eine Instanz von ratsche im Servermodus laufen, der Daemon-Prozess wird beim Start des Radioid per init.d mitgestartet.

Der Serverprozess schreibt mehr oder weniger detaillierte Ausgaben (je nach beim Start angegebenen Verbosity-Level) in das System-Logfile. Diese können von allen Benutzern mit folgendem Befehl begutachtet werden:

tail -f -n 1000 /var/log/messages | grep ratsche

Der Output sieht dann beispielsweise so aus:

Jan 23 11:39:09 Radioid ratsche[18528]: starting RT task scheduler server
Jan 23 11:39:09 Radioid ratsche[18528]: using message queue 0x0000000a
Jan 23 11:39:09 Radioid ratsche[18528]: using executable path /home/hgz/svnlocal/hgz/macros/
Jan 23 11:39:09 Radioid ratsche[18528]: found 1 zombie message(s) in queue...deleting
Jan 23 11:50:00 Radioid ratsche[18528]: starting EquScan task with id=0 (pid 20342)

Benutzung von RATSCHE

Zum Zugriff auf den Taskmanager gibt es das systemweit bekannte tool ratsche (Option -h für Kommandozeilen-Hilfe und Auflistung aller verfügbarer Optionen). Hier nur eine kurze Beschreibung der wichtigsten Optionen:

 ratsche -l

listet alle definierten Tasks auf. Die Bedeutung der einzelnen Werte ist aus dem ebenfalls ausgegebenen Header ersichtlich.

 ratsche -a <tasklist>

fügt die in der datei <tasklist> definierten Tasks hinzu. Eine Beispieldatei ist zu finden im SVN-Repo in macros/dummy_task. Am besten man legt sich eine lokale Kopie dieser Datei an, so dass es bei Veränderung dieser nicht zu SVN-Konflikten kommt, z.B. mit

 cp dummy_task tasklist

Die Datei tasklist ist dann beliebig editierbar. für alle möglichen Task-Typen ist mind. ein Beispiel angegeben. Wenn der Task von ratsche übernommen werden soll, muß natürlich die entsprechende Zeile auskommentiert sein, i.e. das führende "#" zu entfernen. Das genaue Spaltenformat ist in der Beispieldatei erläutert.

Hinweis: Momentan werden die Werte von Priority und Alt-Period noch nicht berücksichtigt. Wird in Zukunft noch implementiert (ist auf meiner ToDo-Liste irgendwo mittendrin ;)

---

Benutzung des Subversion (SVN) Repositories

seit Anfang März 2010 lagert das Software-Repository auf Roberts Server. Eine Übersicht über die Struktur des Repositorys ist erreichbar über file:///.../svnlocal/hgzlib/html/index.html in einem Browser, aber nur wenn man vorher die doxygen-Dokumentation mittels doxygen in diesem Verzeichnis erstellt hat. Der Code kann auch durch ein Trac-Webinterface angeschaut werden:

https://acr-radebeul.zapto.org/trac/browser/trunk

(login und pw sind identisch mit dem Wiki-account)

Zum Auschecken der Repos in eine lokale Arbeitskopie kann entweder obige url benutzt werden, oder aber folgende Quelle, die auch Änderungen im Repository zuläßt (der https-Kanal ist read only, bzw. sollte es sein):

  svn co svn+ssh://svn@acr-radebeul.zapto.org/var/svn/hgz/trunk ~/svnlocal

Passwort ist bei Hgz oder Penner zu erfragen. Zusätzlich kann man sich noch durch Schlüsselaustausch und einem ssh-Agenten das lästige Eintippen des Passworts sparen (siehe unten).

Existiert bereits eine lokale Arbeitskopie (vom vorhergehenden Repository) ist es möglich, diesem die neue Adresse durch folgenden Befehl (im Hauptpfad der lok. Kopie, z.b. svnlocal/) mitzuteilen:

  svn switch --relocate svn+ssh://svnuser@141.30.85.175/home/hgz/svnrep/trunk svn+ssh://svn@rm-radeberg.dyndns.org/var/svn/hgz/trunk

der commit-befähigte user heißt also jetzt svn (pw wie schon erwähnt erfragen). Das soll sich mittelfristig ändern, nämlich dann wenn das Repo endgültig auf dem Perseiden beheimatet wird. Dann wird jeder, der etwas in das Repo einchecken möchte einen Account haben, so dass der Urheber eines Commits auch automatisch im Log erkennbar ist. Andererseits wird nicht jeder auf Perseid registrierte User Schreibzugriff auf das SVN-Repo besitzen. Eine Registrierung (in Form einer mündlichen Absichtserklärung) ist vorzugsweise bei penner und Rücksprache mit Hgz vorzunehmen.

Zugriff auf das svn-Repository durch ssh-Schlüssel

einen passwortlosen Zugriff auf das svn-Repository kann man durch Austausch eines vertraulichen Schlüssels erreichen. Dieser kann von Hgz bezogen werden. Zum Aktivieren des Schlüssels (nehmen wir an, er heißt svnkey) sollte man ihn zuerst an einem geeigneten Ort, wie z.B. $(HOME)/.ssh deponieren. Danach kann er dem ssh-Agenten bekannt gemacht werden mit:

 ssh-add ~/.ssh/svnkey

Zum Kontrollieren, ob der Schlüssel geladen wurde, oder um sich die Liste bereits geladener Schlüssel anzusehen ist folgender Befehl nützlich:

 ssh-add -l

Das bisher beschriebene Verfahren muß jedesmal wiederholt werden, wenn eine neue Konsole gestartet wird. Um den Schlüssel permanent in einer interaktiven Shell (das ist diejenige, die an dem Rechner gestartet wird, an dem man auch sitzt) bekannt zu machen, genügt es, obige Zeile in seine .bashrc (d.h. im eigenen Home-Verzeichnis) anzufügen, also

 ...
 ssh-add ~/.ssh/svnkey

dann sollte an einem Rechner, auf dem eine grafische Benutzeroberfläche läuft, keine Passwortabfrage mehr beim Zugriff auf das svn-Repo erscheinen.

Anders verhält sich das bei entferntem Zugriff auf einen Rechner, z.b. über ssh-login. Dort wird standardmäßig eine Login-Shell gestartet (vgl. interaktive Shell, s.o.), die üblicherweise keine Instanz eines ssh-Agenten initiiert.

Hier gibt es zwei Möglichkeiten:

1.Möglichkeit (empfohlen): man installiert das paket keychain (sofern in den Distributionsquellen vorhanden) und überläßt diesem Programm dann das Starten des ssh-Agenten und Laden des Schlüssels. Dazu muß, analog zu obiger Vorgehensweise, in .profile oder in .bashrc in seinem Home-Verzeichnis (im Prinzip ist es egal, aber besser in .profile) nur der Aufruf von keychain mit dem Schlüssel als Argument erfolgen:

keychain --nogui ~/.ssh/svndd_key
. ~/.keychain/`uname -n`-sh

2.Möglichkeit: man fügt folgende Zeilen an seine .profile an:

# start up ssh-agent
SSH_ENV="$HOME/.ssh/environment"
function start_agent {
    echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null
    /usr/bin/ssh-add ~/.ssh/svnkey;
}
# Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
    . "${SSH_ENV}" > /dev/null
    #ps ${SSH_AGENT_PID} doesn't work under cywgin
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
        start_agent;
    }
else
    start_agent;
fi

Zu beachten ist hier, dass der Schlüssel, welcher geladen werden soll, hier mit angegeben ist (9. Zeile). Der Name muß entsprechend dem tatsächlichen Namen des Schlüssels angepaßt werden. In jeder zukünftig geöffneten Shell wird nun automatisch der Schlüssel geladen, so dass eine Passwortabfrage bei Zugriff auf svn umgangen (im positiven und auch sicheren Sinn) wird. Um die Änderungen auch in der aktiven Shell anzuwenden, kann man außerdem noch den Inhalt der veränderten .profile erneut ausführen lassen mit:

 source ~/.profile

Remote-Mounten der Datenpartition durch sshfs

Zum Mounten von Ordnern fremder Rechner auf dem lokalen Computer über ssh ist das tool sshfs ganz hilfreich. Es setzt auf dem FUSE-Dateisystem-Konzept auf, der Benutzer muß daher Mitglied der Gruppe "fuse" auf dem lokalen Rechner sein.

Als erstes sollte man sicherstellen, dass sshfs installiert ist, und es ggf. über den Paketmanager installieren, z.b.

sudo zypper install sshfs

Danach noch (z.b. über YaST->Benutzer und Gruppen) den eigenen Benutzer zur Gruppe fuse hinzufügen.

nun kann man ein Verzeichnis anlegen, in das das Filesystem des entfernten Rechners hingemountet wird:

mkdir sshfs/radioid

das mounten geschieht über:

sshfs radioid:/daten ~/sshfs/radioid/

dann sollte der Ordner /daten des radioiden in dem Verzeichnis sshfs/radioid gemountet sein. Der Hostname (in diesem fall radioid:/) muß natürlich dem System bekannt sein. Am besten man benutzt den Alias wie auch beim ssh-Login. Dann muß man auch kein PW eingeben.

Noch ein Tip: Ich habe das Mounten von nicht-lokalen Verzeichnissen komfortabel in gkrellm integriert. Dazu muß man einfach bei Configuration->File System ein neues primäres FS hinzufügen (s. Screenshot).

• 
  Konfiguration sshfs-mount in gkrellm
• 
  Einbindung des Radioiden über sshfs-mount in gkrellm