Fryboyter

Pacman XferCommand

Ich setze unter pacman (Paketverwaltung von Arch Linux) seit einiger Zeit nicht den internen Downloadmechanismus, sondern snarf ein. Das gibt bis zur Version 4.0.3 von pacman auch gut. Seit dem gab es diverse 404-Fehler beim Aktualisieren der Pakete. Snarf findet also irgendetwas nicht und bricht deshalb ab. Gerade habe ich in einem lichten Moment die Lösung gefunden. Mittels pacman -Syu –debug bin ich dem Problem auf die Spur gekommen. Snarf hat die Signatur-Dateien der Datenbanken (z. B. core.db.sig) nicht gefunden. Kein Wunder, bisher sind ja nur die Pakete an sich signiert und die Datenbanken kommen erst später an die Reihe. Um trotzdem eines der XferCommand-Einträge in der /etc/pacman.conf zu nutzen muss man in selbiger bei den eingetragenen Paketquellen beim SigLevel noch DatabaseNever hinzufügen, sodass es wie folgt aussieht.

[core]
SigLevel = PackageRequired DatabaseNever
Include = /etc/pacman.d/mirrorlist

Und schon funktionieren die XferCommand-Einträge wieder.

Planetenseite von ubuntuusers.de

Eigentlich widerstrebt es mir ja, auch nur ansatzweise Werbung für etwas zu machen, das mit Ubuntu zu tun hat. Aber in dem Fall werde ich wohl damit leben müssen. Trauma vorprogrammiert. ;-)

Unter http://planet.ubuntuusers.de werden Beiträge aus dem Bereich Linux und Open Source aus diversen Blogs zusammengetragen. Teilweise sind dort recht gute Artikel zu finden.

Arch Linux schneller starten

Eigentlich ist es mir egal, wie schnell die bei mir installierten Betriebssysteme starten. Zumindest, wenn es nicht mehrere Minuten dauert. Aber gestern ist bei mir mal wieder der Spieltrieb ausgebrochen. Darum habe ich mir mal den Bootvorgang von Arch Linux vorgenommen. Als Erstes habe ich mir mal angesehen wie schnell das System derzeit startet. Da ich systemd einsetze habe ich das mit dem Befehl systemd-analyze gemacht. Hier wird angezeigt, welche Services usw. wie lange gebraucht haben. Sortiert wird das ganze von lange bis kurz. Insgesamt hat das System gut 30 Sekunden gebraucht (da ich die alten Werte nicht gespeichert habe, bitte folgende zwei Beispiele nur als Beispiele ansehen).

systemd-analyze Startup finished in 11278ms (kernel) + 19325ms (userspace) = 30603ms

Im Grunde also ein Wert, bei dem zumindest ich nicht meckern kann. Dank meines Spieltriebs wollte ich aber trotzdem mal sehen, was möglich ist. Als Nächstes haben ich mir mittels systemd-analyze blame anzeigen lassen, was wie lange zum Starten gebraucht hat.

systemd-analyze blame
2802ms systemd-readahead-collect.service
2756ms systemd-readahead-collect.service systemd-readahead-replay.service
2727ms systemd-logind.service
2669ms media-WindowsD.mount
2668ms media-WindowsC.mount
2664ms console-kit-daemon.service
2620ms network.service
2600ms dbus.service
1465ms systemd-remount-fs.service
1273ms systemd-udev-trigger.service
1094ms dev-mqueue.mount
1090ms sys-kernel-debug.mount
890ms systemd-user-sessions.service
850ms systemd-sysctl.service
827ms dev-hugepages.mount
609ms systemd-vconsole-setup.service
460ms console-kit-log-system-start.service
451ms systemd-modules-load.service
308ms systemd-tmpfiles-setup.service
306ms media-WindowsD.mount
239ms systemd-udev.service
156ms openvpn@NL4.service
123ms home.mount
43ms tmp.mount
39ms upower.service
16ms udisks2.service
5ms boot.mount
1ms rtkit-daemon.service
1ms sys-fs-fuse-connections.mount

Da ich e4rat verwende habe ich mittels systemctl disable systemd-readahead-collect.service systemd-readahead-replay.service die beiden vergleichbaren systemd-Services deaktiviert, da diese recht lange gebraucht haben. Viel mehr konnte ich nicht deaktivieren, da ich leider alle andere was langsam gestartet wurde, brauche. In der mittels systemd-analyze blame erzeugten List ist mir allerdings noch aufgefallen, dass es relativ lange dauert, bis zwei NTFS-Partitionen gemountet werden. Da ich diese nicht sofort nach dem Start und auch nicht regelmäßige brauche, habe ich mir mal die /etc/fstab vorgenommen. Systemd bietet hier die Möglichkeit, bestimmte Partitionen erst zu mounten, wenn man auf die Mountpoints zugreift. Das sollte wieder etwas bringen. Also habe ich einen Blick in die fstab geworfen. Eine der betreffenden Einträge sah z. B. so aus.

UUID=DE084E95084E6C99 /media/WindowsC ntfs-3g default 0 0

Hier muss nun das default gegen noauto,comment=systemd.automount ausgetauscht werden, sodass wir folgenden Eintrag erhalten.

UUID=DE084E95084E6C99 /media/WindowsC ntfs-3g noauto,comment=systemd.automount 0 0

So wird in diesem Fall die Partition die über /media/WindowC angesprochen wird, erst dann gemountet, wenn man auf den Mountpoint zugreift. Und schon hat das System wieder etwas schneller gebootet. Wirklich schneller wurde der Spaß aber erst, als ich auch noch den Eintrag für /home angepasst habe. Das hat richtig etwas bewirkt. Als Letztes habe ich dann noch die unnötigen Terminals, wie hierbeschrieben deaktiviert. Und was hat mir das ganze jetzt gebracht? Etwas Spass an der Freude und ein System, das nun in ca. 18 Sekunden anstelle von 30 bootet. Ich vermute allerdings, dass man den Bootvorgang noch weiter optimieren könnte. Aber dafür müsste man, wenn man den diversen Anleitungen vertraut, zu sehr ins System eingreifen. Das lasse ich mal lieber.

Sourcecode von HijackThis freigegeben

Das Unternehmen TrendMicro hat den Sourcecode bekannte Tool HijackThis veröffentlicht. Mit Hijackthis ist es möglich unter bestimmten Voraussetzungen einen Schädlingsbefall des Rechners zu erkennen und im besten Fall zu beseitigen.

Das Tool wurde mit Visual Basic erstellt und steht unter http://sourceforge.net/projects/hjt zum Download bereit. Dort findet man auch den erwähnten Sourcecode.

Laut diesem ist der Code unter der GPL 2 veröffentlicht worden. TrendMicro äußert sich dazu in der Pressemitteilung nicht.

Knecht Rootrecht

Eines muss man den Entwicklern von Grml lassen. Die Codenamen ihrer Distributionsversionen sind immer wieder klasse. So erblickte kurz vor Weihnachten Knecht Rootrecht das Licht der Welt und kann sich nun zu seinen Geschwistern Dioptrienotto, Schluchtenscheisser, Eierspass usw. gesellen.

Grml ist eine Linux-Distribution, welche auf Debian Testing basiert, die für Systemrettungen und -verwaltungen eingesetzt wird. Eine Installation ist möglich, allerdings liegt der Schwerpunkt auf der Live-Distribution, da man auf Rechner, die Probleme machen, nicht mal eben ein Betriebssystem installieren kann. Neuerungen sind z. B. EFI Boot von CDs und USB-Sticks (nur bei der 64Bit-Version) und die Verwendung von Fluxbox.

Beim Booten werden anonyme Statistiken erstellt und an die Entwickler gesendet. Dies kann mit der Bootoption “nostats” verhindert werden.

Genauere Informationen zu Knecht Rootrecht findet man unter http://grml.org/changelogs/README-grml-2011.12.