Der Dienst Dudle ist datenschutzrechtlich eine saubere Alternative zu Doodle, das zwar in der Schweiz zu Hause ist, jedoch Google Analytics einsetzt und die Benutzer mit Werbung bewirft. Außerdem ist die Verwendung von Doodle für Beamte in Baden-Württemberg schlicht verboten.
Die Installation ist kein Zuckerschlecken, geht aber insgesamt dann doch eher freundlich als kompliziert über die Bühne. Das ganze Gefrickel lohnt nur dann, wenn man eine HTTPS Verschlüsselung für die eigenen Seiten schon am Laufen hat – wenn nicht, dann verwendet man besser den Dienst der TUD direkt.
Es kann durchaus sein, dass ich im folgenden ein paar Pakete zu viel an Bord hole – das mag dann bitte jeder selbst für sich prüfen. Außerdem kann es sein, dass einige Pakete nicht installiert wurden, weil diese auf meinem Zielsystem schon vorhanden waren. Anyway – so ging’s bei mir:
apt-get install bzr libgettext-rails-ruby1.8 potool make libgettext-rails-ruby ruby-gettext gettext
Bei mir kamen hierbei die Pakete ruby1.9.1-dev ruby-dev schon mit an Bord und auch die Symlinks von ruby auf ruby1.9.1 wurden eingerichtet.
cd /var/www/ # oder wo auch immer dudle später hin soll
Ein simples bzr branch https://dudle.inf.tu-dresden.de/ dudle bewirft den Benutzer mit Fehlermeldungen. So will es dann klappen:
bzr -Ossl.cert_reqs=none branch https://dudle.inf.tu-dresden.de/ dudle
Das Verzeichnis /var/www/dudle wird mittels des Befehls angelegt, gehört aber erst einmal root, was wir nicht wollen.
chown -R www-data.www-data dudle/ cd dudle/ cp -p config_sample.rb config.rb
In die .htacces im Stammverzeichnis von Dudle sollte man bei der Nutzung von Ruby 1.9.1 (also auf einem 14.04 Server) hinzufügen:
SetEnv RUBYLIB /var/www/dudle/
Geschieht dies nicht, dann wirft Dudle Fehlermeldungen in die Apache error.log, die darauf hindeuten, dass Dudle seine Ruby Dateien nicht findet.
Wir holen uns noch die Sprachpakete für Dudle an Bord:
for i in locale/??; do wget -O $i/dudle.mo https://dudle.inf.tu-dresden.de/locale/`basename $i`/dudle.mo ; done
Die folgenden Schritte integrieren Dudle in den Webserver:
a2enmod auth_digest
Dann die Sitekonfiguration des Apachen bearbeiten – das könnte je nach System z.B. in die folgende Datei sein: /etc/apache2/sites-available/default-ssl.conf
Alias /dudle /var/www/dudle
<Directory /var/www/dudle>
Options +ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
Nachdem die Voraussetzung nun geschaffen sind, Dudle zu installieren, kann der Compiler im Verzeichnis /var/www/dudle angeworfen werden:
make
In den hier auftauchenden Fehlermeldungen (eigentlich sollten keine mehr kommen – die obigen Schritte integrieren alles, was ich habe lernen müssen) kann man sehen, was Dudle noch fehlt. Zumindest so ungefähr. Meistens, so musste ich erfahren, hilft nur eine Suchmaschine weiter, weil die Ruby-Fehlermeldungen etwas kryptisch für mich waren.
Ging alles glatt – den Apachen neu starten:
service apache2 restart
Der Rest ist Anhübschungskram – z.B. durch Anpassung der Dateien im Verzeichnis dudle/css. Empfehlenswert ist das folgende Stylesheet:
wget https://dudle.inf.tu-dresden.de/css/TUD2.css wget https://dudle.inf.tu-dresden.de/css/tud/logo.png
Ich hab dann noch das Logo ausgetauscht, die Rechte wieder angepasst und beschlossen, dass nun erst einmal alles gut ist.
Dudle legt neue Abfragen im Stammverzeichnis /dudle/ unter jeweils recht kryptisch anmutenden Namen als Ordner an, die alle Umfragedaten (Benutzer, Passwörter derselben, Zeiten etc.) enthalten. Die Passwörter landen gehashed in .htdigest Dateien.
Meine Schule wäre versorgt – andere können den Dienst bei der TUD (Link siehe oben) oder auch gerne das Dudle auf dem Lehrerforbildungsserver nutzen:
https://lehrerfortbildung-bw.de/dudle/
Bei Problemen nach der Eingabe von Umlauten oder Ligaturen in die Dudle Felder: hier weiterlesen.
Hi,
Danke erstmal für die tolle Doku.
Den befehl mit cert_reqs kennt er aber nicht. Kommt ständig die Meldung „unknown command“.
Weiß du voran das liegen könnte?
Gruß
Ali
Das ist
ssl.cert_reqsBitte kontrolliere mal mit:
# bzr help ssl.cert_reqsDa sollte als Antwort kommen:
Whether to require a certificate from the remote side. (default:required)
Possible values:
* none: Certificates ignored
* required: Certificates required and validated
Hieraus ergab sich mein
bzr -Ossl.cert_reqs=noneweil die Gegenstelle lediglich ein selfsigned Zertifikat einsetzte.
Servus zusammen,
habe das nach Anleitung soweit befolgt und die Dudle Installation an sich funktioniert auch super.
Das einzige Problem ist, dass die CGI-Skripte nur als Code angezeigt werden. Das wird wohl nur ne falsche Apache Konfiguration sein.
Nachdem ich das allerdings genau nach Installationsanleitung alles heruntergeladen habe (Server Ubuntu 14.04 wurde extra für Dudle aufgesetzt, ist also nix anderes vorher drauf gewesen) geht es trotzdem nicht.
Hab in sämtlichen Apache Config-Files alles mir Mögliche ausprobiert; AddHandler cgi-script .cgi .rb – Options +ExecCGI in den verschiedenen Config-Files – usw. Habe das in x-verschiedenen Kombinationen getestet bis ich mich wieder verkonfiguriert habe und das System neu aufgesetzt habe.
Kannst du mir evtl. noch einen Tipp geben was du für Einstellungen zum Thema CGI-Skript hast die ich noch überprüfen kann? Wäre sau cool!
Grüße
Max
Ein Blick in die Logs (/var/log/apache/error.log oder access.log) könnte helfen, weil die Suche nach dortigen Fehlermeldungen einen meist direkt zu Beiträgen führt, bei denen andere Menschen die gleichen Problemen hatten.
Mir fällt spontan das hier zur Überprüfung ein:
sudo a2enmod cgi
sudo service apache2 restart
Oder auch in den Apache Konfigurationsdateien nachsehen. FIndest Du da Zeilen wie
Options +ExecCGI
AddHandler cgi-script .cgi .pl
Options Indexes FollowSymLinks MultiViews ExecCGI
Ach so, ja, noch was: die Rechte auf den Dateien stimmen? Der Apache darf diese auch ausführen?
Servus,
die Error-Logs bringen mich nicht viel weiter.
Selbst mit dem Log-Level was am meisten ausspucken sollte kommt nichts was mir helfen könnte.
CGI ist Enmodded
Die entsprechenden Zeilen sind vorhanden (angefangen wie in der Beschreibung) – auch teilweise mal was anderes probiert in anderen .conf Dateien wie sites-enabled oder der apache2.conf.
Rechte sind an www-data vergeben, ich hab zum testen ob es an den Berechtigungen liegt aber auch einfach einen chmod 777 -R gesetzt. Sollte kein Problem sein.
Muss bei Addhandler evtl. noch ein .rb dahinter? Zwar schon ausprobiert, aber finde dazu nix wirklich gutes im Netz.
Ich bin mir zu 100% sicher, dass es nur an der Config für den Apache liegt. Allerdings probiere ich schon seit Wochen immer wieder an dem Problem herum um weiter zu kommen – schaff es aber einfach nicht. Es wird immer nur der Code ausgegeben.
Viele Grüße, Max
@Max
Bei mir half Folgendes:
nano /etc/apache2/conf-available/dudle.conf
Diesen Text einfügen:
SetEnv RUBYLIB /var/www/html/dudle/
Options +ExecCGI
AddHandler cgi-script .cgi
Und die Konfiguration mit „a2enconf dudle.conf“ aktivieren.
Verzeichnis ggf. anpassen.
Bei mir funktioniert es nicht ganz. Wenn ich die Startseite aufrufe finde ich z. B. in error.log vom Apache folgendes:
[cgi:error] [pid 27600] [client 79.230.47.249:63348] AH01215: /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require‘: iconv will be deprecated in the future, use String#encode instead.
Ich verstehe zwar, dass da ein Funktion nicht mehr genutzt werden soll, aber wie behebe ich das?
Check doch mal ob es die Dateien bei Dir gibt:
/usr/lib/ruby/1.9.1/x86_64-linux/iconv.so
# stammt aus dem Paket libruby1.9.1
/usr/lib/ruby/vendor_ruby/gettext/core_ext/iconv.rb
# stammt aus dem Paket ruby-gettext
Der Aufruf erfolgt aus der /dudle/date_locale.rb. Ich würde deswegen erst einmal auf ein fehlendes gem tippen … das Du evtl. durch die Installation oben genannter Pakete an Bord bekommst?