Skip to content

Thermische Isolierung und ihre Folgen

Früh morgens an einem Feiertag um 6 Uhr von der gegenüberliegenden Alarmanlage geweckt ergab sich für mich die Chance auf Feldstudien zur Thermischen Isolierung. Die Daten dieser Studie möchte ich hier vorstellen und in den folgenden Wochen ggf. präzisieren...

Versuchsaufbau:

Das Versuchsobjekt besteht aus einem Wohnblock in 2,5 Etagen Bauweise mit jeweils 5 Mietparteien pro Eingang. Die Versuchsperson bewohnt eine Wohnung im ersten Stock im inneren des Gebäudes, hat also keine große Aussenwand wie die Mietparteien am Ende des Wohnblocks.

Folgende Modifikationen wurden an dem verwendeten Mehrfamilienhaus vorgenommen:

1.) Anbringen eines Aussengerüstes an der Ostseite des Gebäudes zur Erhöhung des Lärmpegels durch Vogelgezwitscher.
2.) Entfernung der Fenstersimse zwecks besserem Zugang der Aussentemperaturen zu den Fensterelementen.
3.) Entfernung der Dachverschalung zur Verbesserung des Luftdurchzugs des über der Wohnung der Versuchsperson befindlichen Dachbodens.
4.) Entfernung der Balkone und Vernagelung der Balkontüren zur Vermeidung von Aufwärmzonen für die Versuchsperson in der Nachmittagssonne
5.) Einbau neuer Heizungsventile zur Reduzierung der Heizungsdurchflusskapazität und damit der Heizleistung in der Wohnung der Versuchsperson.

Historische Daten:

Durch jahrelange Untätigkeit der eigentümlich zuständigen Stellen befindet sich das Testobjekt in schlechtem wärmeisolatorischen Zustand. Risse in den Wänden und eine nicht mehr zeitgemäße (quasie nicht vorhandene) Wärmeisolierung erfordern ein Durchheizen der Wohnung vom Herbst bis Frühling im Heizungsbetriebsmod "Volle-Pulle". Für die täglich notwendigen kurzen Komplettlüftungen der Wohneinheit ist die Verfügbarkeit einer Winterkleidung in 4-5 Monaten im Jahr notwendig.

Versuchsablauf:

Im Verlauf des Versuchs wird das Testobjekt von Osten beginnend über die Nordfront hin zur westlichen Hausseite im Verlauf eines Jahres wärmeisoliert. Das Dach wird innenseitig isoliert und der Dachboden mit einer wärmedämmenden Bodenschicht versehen. Durch diese Massnahmen soll die illegale Wärmeabsorbtion in den orbitalen Bereich eingedämmt werden. Zusätzlich wird im Keller eine Isolationsschicht an der Decke angebracht, um die Kaltedurchdringung der unteren Wohneinheiten in den kalten Monaten zu reduzieren. In der kürzlich aktualisierten Versuchsplanung werden die bisherigen Lichtflutungsanlagen in den Wänden durch neuere Modelle ersetzt.

Bisherige Beobachtungen in der ersten Versuchsphase:

Mit der Isolation der Hauswände wurde begonnen. Die Ostseite (für die nicht wissenschaftlich begabten: Das ist da wo der gelbe Ball morgens immer als erstes auftaucht) ist zuerst mit Wärmedämmplatten versehen worden. Diese Arbeiten sind noch nicht gänzlich abgeschlossen, bedecken aber bereits den Großteil der Aussenmauern der von der Versuchsperson bewohnten Wohneinheit.
Isolierungsarbeiten an der Ostseite


Die Westseite der Wohneinheit ist bis auf den fehlenden Balkon und die entfernten Fenstersimse noch im Originalzustand.

Westseite


Früh morgendlich zum Sonnenaufgang herrscht in der Wohneinheit eine recht niedrige gefühlte Temperatur. Dies wurde vor Versuchsbeginn durch entsprechendes Heizen mit der vorhandenen Heizanlage und durch schnelles bekleiden der Versuchsperson kompensiert. In Extremen fällen wurde durch die Zuführung von Wärmespeichernden Flüssigkeiten (genannt Käffchen) eine weitere Erwärmung der Versuchsperson herbeigeführt. Im Laufe der frühen Morgenstunden erwärmte sich die Wohneinheit durch die Strahleneinwirkungen der Sonne auf die Aussenmauer. Die bereits angebrachte Wärmeisolationsschicht auf der Ostseite verrichtet aber bereits ihre Arbeit und verhindert erfolgreich die Erwärmung der Wohneinheit durch die Sonneneinstrahlung; wohingegen die Abendliche Abkühlung durch die bisher nicht durchgeführte Isolierung der Westseite und des Dachbodens noch sehr effizient erfolgt. Hinzu kommt der additive Effekt der bereits durchgeführten Heizungsleistungsreduzierung durch den Tausch der Heizungsventile, der eine Kompensation durch schlichtes Heizen ebenfalls nicht mehr im gewohnten Masse ermöglicht.

Fazit zum Abschluss der ersten Versuchsphase:

Mir ist scheisskalt. Ich geh jetzt ins Freie zum Aufwärmen...

So (!) funktioniert EDV!


Ein Softwareentwickler und seine Frau:

Sie: "Schatz, wir haben kein Brot mehr, könntest du bitte zum Supermarkt gehen und eins holen? Und wenn sie Eier haben, bring 6 Stück mit."

Er: "Klar Schatz, mach ich!"

Nach kurzer Zeit kommt er wieder zurück und hat 6 Brote dabei.

Sie: "Warum nur hast du 6 Brote gekauft?!?"
Er: "Sie hatten Eier."

1.) Warum konkrete Anforderungen wichtig sind
2.) Warum wir immer so Probleme haben unsere Frauen zu verstehen.

Eins ist sicher. ER hat alles richtig gemacht!!

Bind10 early testing

Am 02.06. diesen Jahres ist ein weiteres Developer-Release von Bind10 erschienen. Nachdem ich als DNS-Admin die Announcements vor einem Jahr gelesen hatte, begann schon die Vorfreude auf die neue Version.

Anständige Skalierbarkeit, Datenbankbackends, modularer Aufbau, dynamsiche Konfiguration zur Laufzeit, definierte APIs zur Konfiguration. Alles Features, die einen leitgeplagten Admin von größeren Bind9-Systemen das Herz höher schlagen lassen.

Das Developer-Release veranlasste mich nun dazu das ganze mal zu testen. Im Wiki ist zu lesen, das die Entwickler auch auf Debian entwickeln. Also sollte das auf meinem Debian ja kein Problem sein. Aber bei den Requirements geht es schon los. Als erstes Backend wurde sqlite implementiert. Dies ist im stable-Debian auch bereits in ausreichender Version vorhanden. Die boost-Libs sind ebenfalls aktuell genug. Auch die Compilerauswahl von 3.4.3 bis 4.4.1 ist mit stable abbildbar. Aber was hat die Entwickler geritten, als sie Abhängigkeiten zu Python 3.1 eingebaut haben??? Im Stable ist python 2.5 enthalten.

Aber was soll's. Fix eine neue Virtualbox-Instanz aufgesetzt, Debian-testing draufgepackt und los gehts. Dort ist Python 3.1 bereits enthalten. (obwohl 2.6 imho Distributionsdefault werden soll...) Der svn-Checkout ist auch problemlos (wer es wirklich testen will, sollte beim Verzeichnis trunk bleiben. Meine 2GB /home-Partition haben für einen kompletten checkout nicht ausgereicht). Mit dem Installieren von "base-essentials" und "pkg-config" (was in den Requirements nicht angegeben ist aber trotzdem benötigt wird) war auch schon das Basissystem für die Tests geschaffen.

Apropos Testsystem. Ich bin Teilpurist. Deswegen hat mein virtuelles Testsystem 64MB RAM und 2 Festplatten mit je 2GB Plattenplatz. Da ich ja kein Unmensch bin und meiner Software auch mal was gönne, hab ich noch 148MB von der einen Platte als swap zugewiesen. Wenn das nicht ausreicht, schieb ich Bind10 wieder in die Schublade, bis die Entwickler ihr Semester in Entwicklung resourcenschonender Software besucht haben.

Nach dem svn-Checkout liegen im trunk-Verzeichnis die Sourcecodes. Für den Üblichen Dreisatz aus ./configure && make && make install fehlt nur eines. Das ./configure-Script. Ein Aufruf von "autoreconf --install" erledigt das Problem und erzeugt das Script. Da ich meine Software gerne unter Kontrolle habe, will ich diese nicht im /usr/local oder gar direkt unter /usr liegen haben. Deswegen wird dem configure-Script ein extra Verzeichnis mittels "--prefix=/opt/bind10-trunk" mitgegeben. Damit alles durchlief hab ich noch hier und da mit ein paar dev-Packaten nachhelfen müssen. Diese habe ich aber leider nicht gelistet. Aber ein bischen Spaß sollst Du beim Testen ja auch haben...

Da ich nicht nur Teilpurist sondern auch Hobby-Paranoiker bin, habe ich die Software natürlich als normaler User gebaut. Damit das make-install klappt, muss dafür das Verzeichnis unter /opt angelegt werden. Das erledigt ein "sudo /usr/bin/install -u frank -g frank -m 755 -d /opt/bind10-trunk" für mich. Und wie zur Bestätigung steht auch gleich im Bind10-Guide, das die Entwicklungsversionen so konfiguriert sind, das sie nicht per Default auf Port udp/53 lauschen sondern auf udp/5300. Also noch ein Pluspunkt. Das Ding läuft bis zur entgültigen Version bei mir zum Testen also als unpreviligierter User. ;-)

Nun noch mit "/opt/bind10-trunk/sbin/bind10 --verbose" starten und los gehts. Der Parameter --verbose bewirkt dabei, das der Prozess sich nicht als Daemon in den Hintergrund verfrachtet sondern schön alles auf der Konsole ausgibt, was er so macht.

Als DNS-Admin haue ich an dieser Stelle natürlich gleich den passenden dig-Befehl in die Konsole, um meinen neuen DNS-Server zu testen. Aber da teilt mir die bash mit einem freundlichen "dig: command not found" auch gleich mit, dass ich vergessen habe noch etwas zu erwähnen. Auf dem System sind nämlich (um Wechselwirkungen mit vorgängerversionen auszuschliessen) keinerlei DNS-Tools installiert. Also parallele Session zum nächsten virtuellen testsystem aufbauen und dort mit dig die ersten Anfragen starten...

... aber die Ernüchterung kommt sofort. In der aktuellen Fassung kennt der Bind10 noch nichtmal die Root-Zone. Der ist wirklich blanko. Da diese frühe Version aber noch nicht für DNS-Cache konzipiert ist, spielt das erstmal eigentlich keine Rolle. Also gleich ein bischen schnüffeln und schon findet man im Internet nichtnur den Root-Zonefile sondern auch ältere Versionen von .edu, .in-addr.arpa und .ipv6.arpa. Also ausreichend Basismaterial zum testen. Mit dem Befehl "/opt/bind10-trunk/b10-loadzone ./root.zone" wird also flink die root-Zone importiert. Die anderen Beispielzonen folgen kurz darauf. Jetzt führen die Testabfragen vom anderen System auch zu den gewünschten Erfolgen. Also: Bind10 is up and running !!!

Fazit des Ganzen:
Die aktuelle Entwicklungsversion hat noch keine Ahnung, was Notifyer sind. Laut Doku soll man bereits Zonentransfers manuell anstoßen können. Aber das wollte noch nicht so. Nach bisherigen Forschungen liegt das wohl daran, das zwar alle Basisrequirements vorhanden sind, aber scheinbar für die boostlib doch Module notwendig sind, die in der Form nicht im Debian-testing enthalten sind. DNS-SEC wird auch noch nicht unterstützt. Das Konfigurationstool "bindctl" arbeitet interaktiv und kommt schon mit einer Onlinehilfe um die Ecke. Die Konfiguration wird nicht mehr in Textfiles erledigt, sondern in einer Datenbank. Das Datenbankschema des sqlite-Datenbank ist bisher recht schmal. Dort sind noch keine Speichermöglichkeiten für Slave-Zonen zu erkennen. Andere Backends als sqlite sind bisher nicht vorhanden, sollen aber folgen. Der eigentlich erst für den 2YearMilestone angekündigte Webinterface zur Konfiguration ist bereits soweit, das es auf 127.0.0.1 einen Serverport öffnen, ist aber noch nicht funktionsfähig. Und was mich aufatmen lässt ist die Tatsache, das ich Bind10 mit den geringen Resourcen sowohl kompelieren als auch starten konnte. Bleibt mir eigentlich nurnoch den Entwicklern ein "Danke (Jungs|Mädels). Weiter so" zuzurufen.

Und um hier auch gleich mal einen weiteren Meilenstein meiner OpenSourceAktivitäten in den Google-Cache-Zement zu meisseln...
... wenn man mal die Announcements der Entwickler ausser auch lässt, ist dies das erste Posting eines Bind10-Users auf der Mailingliste. Und ratet mal, wer der Autor ist :-D :-D :-D

Ich brauch mehr Käffchen...

... ohne überleb ich sowas nicht...

From: Heel van, Jolanda
Sent: Tuesday, June 15, 2010 8:36 AM
Subject: Email Account Quota Limit Exceeded!!!

Ihre Webmail Quote The Set Quota / Grenze, die überschritten wird 20GB.You laufen derzeit auf 23GB Aufgrund Versteckte Dateien und Ordner auf Ihre Mailbox. Bitte klicken Sie den untenstehenden Link, um Ihre Mailbox zu validieren und Ihre Quota erhöhen.



Click Here:



Failure To auf diesen Link klicken und bestätigen Sie Ihre Quota kann den Verlust wichtiger Informationen in Ihre Mailbox / oder Ursache Limited Zugang zu ihr.
Dank
HELP DESK


Vorklärungspauschale...

Wat is eine "Vorklärungspauschale"???
Stellen wir uns mal ganz dumm und sagen das ist einfach eine Pauschale...

Naja. Nachdem die erste Verwunderung vorbei ist, stellte sich heraus, das damit das Telefonat gemeint war mit dem vor dem Einsatz eines Technikers geklärt wurde, was überhaupt gemacht werden soll.

Also zu meiner Zeit nannte man sowas noch Service...
cronjob