Florian Weimer schreibt über ein Pythskript namens debsecan. debsecan steht für Debian Security Analyzer und bewertet den Updatestand eines Debiansystems. Wenn das Skript durchläuft, erfährt man von fehlenden Sicherheitsupdates und bekannten Schwachstellen im System.
Ein Aufruf erfolgt einfach mittels Programmname und Name der Debianversion. Beispielsweise kann man sein Sargerechner mittels debsecan --suite sarge testen. Als Ausgabe erhält man dann alle Pakete, bei denen es Schwachstellen oder Updates gibt. Eine Ausgabe könnte so aussehen:
$ debsecan --suite sarge
CVE-2005-1234 vim (low urgency)
CVE-2005-4321 screen (medium urgency)
Dabei ist es auch wichtig zu beachten, dass das Anliegen scheitert, wenn man apt-pinning macht.
Wer das testen möchte, kann das Skript entweder über das Versionsverwaltungssystem darcs herunterladen oder sich bei Florian herunterladen. Ich finde das sehr sinnvoll und werde es mal bei meinen Rechnern testen.
Mika hat heute in seinem Blog die grml-Version 0.5 angekündigt. Sie kann ab sofort von der Homepage des Projektes heruntergeladen werden. grml Tokolytika basiert auf der Kernelversion 2.6.13.4 und bringt eine Unzahl an nützlicher Software mit. Ich kann jedem Leser nur den Test von grml empfehlen. Bereits die Betaversionen funktionierten hier sehr gut und ich denke im Laufe des Tages werde auch ich einen Blick auf die endgültige Version werfen. Super Job Mika!
Wenn du dich dafür interessierst, welche Distribution die richtige für dich ist, kannst du einen Blick auf den Punkt 0.2 der FAQ der Newsgroup dcoulm werfen oder einen Test machen. Der Linux Distribution Chooser fragt diverse Punkte ab und bietet dann anhand der eingegebenen Punkte die in Frage kommenden Linuxdistros an. Nach dem Test kann ich mich gleich zwischen neun verschiedenen Versionen unterscheiden. Dazu gehörten dann Debian, (K)Ubuntu, Gentoo, Fedora und einige andere.
Nachdem ich nun einige Kombinationen getestet habe, glaube ich, dass man hier durchaus eine erste, gute Idee bekommen kann, welche Distribution die richtige ist.
So langsam kommen die privaten Rechner in Region, wo man mehrere GB an RAM braucht. Doch wenn man einen Linuxrechner mit mehr als 1 GB bestückt, können u.U. Probleme auftreten. Ein solches Problem hatte Andreas Mandalka. Der Rechner war mit 3 GB bestückt und wurde per grub mit der Option mem=3072 gestartet. Beim Anmelden, egal ob Konsole oder X11, erschienen alle Tastatureingaben verzögert. Was kann man tun?
Zunächst könnte es am BIOS liegen. Manche Motherboards möchten gern paarweise bestückt werden. Ob es daran liegt, kannst du dem Handbuch des Motherboards entnehmen.
Eine zweite linuxspezifische Möglichkeit liegt in der aktuellen Konfiguration des Kernels. Hier gibt es die Option NOHIGHMEM:
Linux can use up to 64 Gigabytes of physical memory on x86 systems.
However, the address space of 32-bit x86 processors is only 4
Gigabytes large. That means that, if you have a large amount of
physical memory, not all of it can be “permanently mapped” by the
kernel. The physical memory that’s not permanently mapped is called
“high memory”.
In den Anweisungen wird empfohlen, bei RAM zwischen einem und vier Gigabyte den Wert auf 4GB und ab vier GB auf 64GB zu setzen. Wenn du dies machst und den Kernel anschließend neu kompilierst, sollten die Probleme verschwinden.
Nico Golde und Marc Haber waren zuletzt etwas unzufrieden mit der Performance von security.debian.org. Doch die letzten News aus dem Hause Debian versprechen Besserung.
Nach dem Update von XFree86 konnte die alte Maschine die Last offensichtlich nicht mehr aushalten und verursachte die obigen Probleme. Nun hat man eine Vereinbarung mit der Telegraaf Media Groep getroffen. Diese hosten jetzt das öffentliche Frontend. Hoffen wir, dass das die Lösung darstellt.
Ich finde ja, dass jeder ein paar ausgedruckte Kernelquellen zur Abendlektüre mit ins Bett nehmen sollte. Falls man kein C kann, so finden sich in den Kommentaren immer wieder sehr interessante Sachen. Derartiges hat auch Jörn aufgetrieben:
static void happy_meal_tcvr_write(struct happy_meal *hp,
void __iomem *tregs, int reg,
unsigned short value)
{
int tries = TCVR_WRITE_TRIES;
ASD((“happy_meal_tcvr_write: reg=0x%02x value=%04x\n”, reg, value));
/* Welcome to Sun Microsystems, can I take your order please? */
if (!(hp->happy_flags & HFLAG_FENABLE)) {
happy_meal_bb_write(hp, tregs, reg, value);
return;
}
/* Would you like fries with that? */
hme_write32(hp, tregs + TCVR_FRAME,
(FRAME_WRITE | (hp->paddr << 23) |
((reg & 0xff) << 18) | (value & 0xffff)));
while (!(hme_read32(hp, tregs + TCVR_FRAME) & 0x10000) && --tries)
udelay(20);
/* Anything else? */
if (!tries)
printk(KERN_ERR "happy meal: Aieee, transceiver MIF write bolixed\n");
/* Fifty-two cents is your change, have a nice day. */
}
Die besten Ergebnisse bringt bekanntlich der Zufall. So stiess ich kürzlich per Zufall auf Rubber.
Wer desöfteren LaTeX-Dokumente schreibt, wird immer wieder auf das Problem stossen, wie oft denn das Dokument durch den Interpreter geschickt werden muss. Da muss man eventuell BibTeX aufrufen und makeindex oder xindy. Schnell landet man bei drei oder mehr Durchläufen. Einerseits kann man sich hier mit Makefiles behelfen. Oder aber man nutzt eben Rubber.
Rubber ist ein Satz von Pythonskripten, die automagisch erkennen, wie oft das Dokument durch LaTeX durch muss und es ebensooft macht. Am Ende hat man nur durch den Aufruf rubber $DATEI eine fertige DVI-Datei. Ebenso einfach lassen sich auch PostScript- oder PDF-Dateien erzeugen. Ich fand das Programm nach kurzer Zeit sehr nützlich und kann es nur wärmstens ans Herz legen.