Freitag, 30. Januar 2009Powermize me baby
Nachdem ich nun stolzer Besitzer eines Dell Vostro 1310 bin auf welchem mittlerweile ein Ubuntu 8.10 läuft ist mir aufgefallen, dass die Akkulaufzeit unter Intrepid Ibex merkbar geringer ist als unter dem parallel installierten Windows XP.
Erster Anlaufpunkt waren natürlich Prozessor und Grafikkarte. Der Prozessor lässt sich dank Panelapplet ziemlich einfach den eigenen Stromsparwünschen anpassen.
Mit der eingebauten nVidia GeForce™ 8400M GS ist das leider nicht ganz so einfach. Zwar gibt es in den Optionen des properitären nVidia Treibers eine eigene Seite für den Powermizer. Da kann man aber nur gucken, nicht klotzen.
Eine kurze Suche im Netz hat jedoch verraten, dass man die Einstellungen dennoch anpassen kann - in der Xorg.conf
Dazu im entsprechenden "Device" Abschnitt eine zusätzliche Option für den Powermizer hinzufügen. Bei mir sieht das ganze wie folgt aus:
Section "Device"   Identifier "Configured Video Device"   Driver "nvidia"   Option "NoLogo" "True"   Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2233; PowerMizerDefault=0x3" EndSectionPerfLevelSrc=0xAABB gibt die Strategie an, mit welcher Taktrate gefahren wird. Die ersten beiden Ziffern (AA) stehen für den Batteriebetrieb, die zweiten (BB) für Netzbetrieb. Dabei steht eine 22 für feste Taktrate und eine 33 für eine variable Taktung je nach Anforderung. In meiner Config läuft die Grafikkarte auf Akku also mit festem Takt und mit engestecktem Netzkabel mit adaptiver Taktstrategie. PowerMizerDefault=0xC gibt nun an, mit welchem festen Takt die Grafikkarte fahren soll: 0x1 - Maximale Performance 0x2 - Irgendeine der mittleren möglichen Taktraten wird verwendet 0x3 - Maximales Energiesparen ist angesagtSollte man unter PerfLevelSrc zweimal einen festen Takt vorgegeben haben (0x2222) so muss man auch zwei Abschnitte PowerMizerDefault eintragen. Der erste steht dann für Batteriebetrieb, der zweite für Netzbetrieb. Das ganze sieht dann z.B. so aus: Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x3; PowerMizerDefaultAC=0x1" und sagt aus, dass im Akkubetrieb mit minimalem Energieverbrauch gearbeitet werden soll und unter Netzbetrieb die Grafikkarte dauerhaft mit den maximalen Performanceeinstellungen läuft.
Geschrieben von aple
um
00:17
| Kommentar (1)
| Trackbacks (0)
Zuletzt bearbeitet am 30.01.2009 00:58
Mittwoch, 21. Januar 2009Unprivilegierte Prozesse auf privilegierten Ports
Linux unterscheidet zwischen privilegierten (1-1024) und unprivilegierten Ports (>1024). Die Idee dahinter war mal, dass wenn man zu einem Server auf einem privilegiertem Port connected, dass dort mit ziemlicher Sicherheit ein vertrauenswürdiger, vom Systemadministrator eingerichteter Dienst lauscht. Das ist heute aber nicht mehr zwingend der Fall.
Jedenfalls hat man beim Betrieb von Webservern immer das Problem, einem möglichst unprivilegierten Prozess Zugriff auf Port 80 oder 443 zu geben. Oft wird das so gelöst, dass der Prozess mit root-Rechten gestartet wird und dann nach Öffnen des Ports freiwillig die Rechte wieder abgibt. Das machen aber nicht alle Webserver so.
Eine weitere auch nicht wirklich schöne Lösung ist es, den Webserver auf Port 8080 und 8043 lauschen zu lassen und per Iptables ein Portredirect zu machen. Das klappt solange, bis IPv6 ins Spiel kommt, denn dafür gibt es kein NAT und damit auch kein Portredirect.
Auf der Suche nach einer anderen Lösung bin ich auf accessfs [1] gestoßen. Mit diesem Kernelmodul kann man über ein Verzeichnis is /proc die Gruppe und den Eigentümer für einen spezifischen Port zu setzen.
Accessfs gibt es unter [1] als Kernelpatch für verschiedene, auch recht aktuelle Kernel. Für den von uns verwendeten Kernel 2.6.21 musste der Patch leicht angepasst werden. [2]
# cd /usr/src/linux # cat accessfs-2.6.21-0.20.patch | patch -p1 # make menuconfigDanach findet man unter File Systems ---> Miscellanenous filesystems ---> <*> Accessfs support (Experimental) <*> User permission based IP portsdie passende Einstellung. Durch die Veränderung am Kernel reicht es nicht, einfach nur das Modul zu bauen und zu laden. Danach muss das accessfs noch eingehangen werden: # mount -t accessfs none /proc/accessoder per /etc/fstab: proc /proc proc defaults 0 0 none /proc/access accessfs 0 0Zum Schluss noch ein chown jboss:jboss /proc/access/net/ip/bind/80und der Jboss kann unprivilegiert auf Port 80 laufen. Quellen: [1] http://www.olafdietsche.de/linux/accessfs/ [2] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/sys-kernel/xen-sources/
Geschrieben von pegro
um
10:44
| Kommentare (0)
| Trackback (1)
Zuletzt bearbeitet am 30.01.2009 00:59
Freitag, 16. Januar 2009Gut zu wissen
Wenn man selbst Ebuilds schreibt oder Ebuilds aus dem Bugtracker verwenden will, muss man die für Portage notwendige Manifest-Datei erstellen. Dazu ein Hinweis:
If you've made a local modification to an ebuild, patch, or added anything else to your local overlay and need to make Portage aware of the changes so the package can be properly merged, do not use the "digest" command. Use "manifest" instead. For example: ebuild foo-1.0.17.ebuild manifest Digests have been dead for a long time. Please don't encourage bad practices.Digests werden nach und nach aus dem Tree entfernt und durch das Manifest2-Format ersetzt. Quellen: [1] http://blogs.gentoo.org/nightmorph/2008/12/24/december-public-service-announcement Dienstag, 13. Januar 2009LLDP mit Tcpdump
Das Link Layer Discovery Protocol (LLDP) dient zum Austausch von Informationen bezüglich benachbarten Netzwerkgeräten, wie z.B. Switches oder Router und wird daher eher im Netzwerkcore verwendet, um herauszufinden, welches Gerät an welchem Port hängt.
Es gibt aber auch Implementierungen für Linux: u.a. OpenLLDP [1] und lldpd [2]
Falls man aber grade mal nur das Notebook dabei hat und keinen dieser Dienste installiert hat, reicht ein einfacher tcpdump-Aufruf, um den Switchport, an dem ich hänge herauszufinden. Vorausgesetzt der Switch spricht LLDP.
tcpdump -i eth0 ether proto 0x88ccWer weiß, welche Informationen wo stehen, kann auf Anhieb sagen, welcher Port es ist. Wer das nicht kann, verwendet Wireshark [3]. Quellen: [1] http://openlldp.sourceforge.net/ [2] https://trac.luffy.cx/lldpd [3] http://wiki.wireshark.org/LinkLayerDiscoveryProtocol
Geschrieben von pegro
um
18:15
| Kommentar (1)
| Trackbacks (0)
Zuletzt bearbeitet am 03.01.2009 16:15
Opera und CaCert Zertifikate
Ich habe meine Zertifikate von CaCert ausstellen lassen. Da das Rootzertifikat von CaCert bei nur sehr wenigen Browser dabei bzw. aktiviert ist, muss man meist das Root-Zertifikat erst importieren.
Der Opera in Version 10 (auch schon in der 9er) hat dann aber das Problem, dass er die verwendete Verschlüsselungsmethode für unsicher hält.
(1) This site is using an outdated encryption method which is no longer classified as secure. It cannot sufficiently protect sensitive data. Do you wish to continue?Nach ewiger Suche fand sich die Problemerklärung im Forum [1] auf der Operaseite. Both problems are due to problems caused by CACert.org, the "open source" CA. Their OCSP server is not standards compliant, and refuse to return a valid response when we try to GET it (POST works fine, but Opera now uses GET). They will have to fix their server. The request for their CRL fails because they have specifed a HTTPS URL for that, signed by the same root specifying that CRL, meaning that the CRL is setting up a dependency on itself as we can't fetch the CRL until we have downloaded it, which means it will never happen. As CRLs are digitally signed, and have certain validity periods, using HTTPS for CRL fetching is unnecessary (and sets up a Catch-22 situation). CACert should reissue their root, removing the CRL URL, and also reissue their Class 3 intermediate so that the HTTP CRL URL is located there.Übersetzt ungefähr so: 2 Probleme:
Geschrieben von pegro
um
17:17
| Kommentare (64)
| Trackbacks (0)
Zuletzt bearbeitet am 13.01.2009 17:17
(Seite 1 von 1, insgesamt 5 Einträge)
|
SucheArchivKategorien |