KRDC kann kein vnc

Sunday, August 18. 2013

 Ich hatte den Remote Desktop Client krdc mit pacman -S kdenetwork-krdc allein installiert, aber es ging und ging nicht. Den gewohnten Aufruf aus der konsole lehnte er mit Verweis auf nicht unterstützte URL ab und bei manuelle Auswahl bot er nur RDP aber kein VNC an. Google wusste gar keinen Rat. Die Antwort erriet ich aus der Beschreibung im KDE-Userbase Wiki: Krdc is one of a pair of KDE programs (Krfb is the other) 

Krdc funktioniert nur, wenn kdenetwork-krfb auch installiert ist.

arch linux von verschlüsselter SSD

Sunday, August 11. 2013

Das Thema ist an sich gut dokumentiert, hier ein paar Links:

https://wiki.archlinux.org/index.php/Encrypted_LVM

https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

https://wiki.archlinux.de/title/Festplatte_verschl%C3%BCsseln

http://www.marcstraube.de/linux/2012/08/installation-von-archlinux-mit-verschlusseltem-lvm-und-systemd/

 
Medium mit Rauschen initialisieren:
# frandom ist ein wenig schneller /dev/random und dcfldd ist ein erweitertes dd und gibt dem Ungeduldigen eine Fortschrittsanzeige
dcfldd if=/dev/frandom of=/dev/sdb   
 
# für Neugierige und Kontroll-freaks ist
# lde ein DiskEditor, mit dem man sich anschliessend ansehen kann, was nun auf der disk steht
 
lde /dev/sdb   
 
# SSD partitinieren, da wir syslinux einsetzen werden, brauchen wir nur zwei Partitionen für boot und den verschluesselten Rest 
# gdisk ist gpt fdisk, GPT ist bei mehr als 2 TB angesagt
 
gdisk /dev/sdb  
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          100351   48.0 MiB    8300  Linux filesystem
   2          100352       250069646   119.2 GiB   8E00  Linux LVM
 
# jetzt luks auf die grosse Partition, vorher einen langen, gut merkbaren Pass-Satz ausdenken
cryptsetup -y  -h sha512 --align-payload=8192 luksFormat /dev/sdb2
cryptsetup luksOpen --allow-discards /dev/sdb2 clvm 
 
# und jetzt die logischen Partitionen der LVM anlegen
pvcreate  --dataalignment 4M /dev/mapper/clvm
vgcreate ssd /dev/mapper/clvm
lvcreate -L 20G ssd -n rootvol
lvcreate -L 80G ssd -n homevol
lvcreate -l 100%FREE ssd -n varvol
 
# boot formatieren, 
mkfs.ext2 /dev/sdb1 -L boot
 
# die übrigen volumes bekommen ext4
mkfs.ext4  -E discard /dev/mapper/ssd-rootvol -L root
mkfs.ext4  -E discard /dev/mapper/ssd-homevol -L home
mkfs.ext4  -E discard /dev/mapper/ssd-varvol -L var
 
# standardmaessig werden immer 5% für root reserviert, auf home brauchen wir das nicht
tune2fs -m 0 /dev/mapper/ssd-homevol
 
# so jetzt kann man sie schon mounten und mit der Installation beginnen
mkdir /mnt/sdb2
mount /dev/ssd/rootvol /mnt/sdb2
mkdir /mnt/sdb2/home
 
mkdir /mnt/sdb2/var
mkdir /mnt/sdb2/boot
mount /dev/sdb1 /mnt/sdb2/boot
mount /dev/ssd/homevol /mnt/sdb2/home
 
mount /dev/ssd/varvol /mnt/sdb2/var
 
# damit die naechsten Schritte aus einem installierten Arch-System (statt archiso) gehen, 
# müssen die arch-install-scripts installiert sein
 
pacstrap /mnt/sdb2 base base-devel syslinux
 
syslinux-install_update -i -a -m -c /mnt/sdb2
 
# das legt uU in /boot/syslinux/ diverse symlinks an, was natuerlich nicht funktioniert,
# wenn die Bootpartition alleine und das Ziel der Links noch verschluesselt ist.
# Also kontrollieren und ggf statt der symlinks die echten dateien einkopieren.
 
# Die erzeugte /boot/syslinux/syslinux.cfg wird man auch kontrollieren und editieren wollen.
# wenn man statt der device -Pfade UUIDs einsetzen will, sieht ein funktionierender Eintrag etwa so aus:
 
LABEL arch
        MENU LABEL Arch Linux
        LINUX ../vmlinuz-linux
        APPEND root=/dev/mapper/ssd-rootvol cryptdevice=UUID=c30af807-1234-1234-1234-5ae7f6803b4d:ssd:allow-discards rw lang=de locale=de_DE.UTF-8
        INITRD ../initramfs-linux.img
 
# fstab erzeugen
#  (-U nutzt die UUID, anschliessend ist Handarbeit angesagt, wg swap etc.
# nuetzlich kommt blkid mit einer Liste aller partitionen und deren Bezeichnungen)
genfstab -U -p /mnt/sdb2 >> /mnt/sdb2/etc/fstab  
 

Anschliessend kann man in das neue System booten und normal installieren...

Und? Ist die SSD wirklich so rasend schnell, bzw. bringt sie überhaupt auf einem älteren Board mit legacy SATA etwas? Und wird die Performance nicht von der Ver-/Entschlüsselung komplett wieder aufgefressen?

Die Stoppuhr sagt: fast doppelt so schnell. Von der alten Platte ist die Kiste in 32sec. beim LoginScreen des KDM und braucht danach noch einmal 18 sec., bis der Desktop sichtbar wird. Von der neuen Platte sind es 16 sec und danach 14.

 

 Google findet ein Installations-ISO für Windwos 2008 R2 als Trial bei MS, auch eine Sharepoint2010-Installation als Trial. Zum Download muss man sich mit einer MS-ID registrieren, an die da zugehörige email-Adresse gehen dann auch mails mit Produktkeys. Die braucht man.

Neue VM anlegen, üppige HD zuteilen, üppig Ram (4GB, immer noch knapp), mit dem ISO als CD-Image starten. Erstinstallation geht erstaunlich schnell, erstes Update bei bei 81% ewig hängen bis ich merke, dass hinter dem "Initial Steps"-Fenster eine Dialogbox "IE9 installieren" versteckt sitzt. Nein. Restliche Updates, reboot, restliche Updates, reboot.
Statische IP zuteilen, Installations-Ratgeber und Hinweise ergoogeln.
Nach der Anleitung Server roles und Features installieren. Reboot. 
Sharepointserver.exe in die vm kopieren (aus SMB mag sie nicht starten), Prerequisites Installieren, (will gleich erst mal einen Reboot). Den Product Key aus der Download-Mail eingeben (man hat vier zur Auswahl, habe mal den ersten genommen).

Sharepoint-Install will wissen, ob ich standalone oder eine Farm anlegen will. Standalone reicht mir erst einmal.
Nach der Installation startet ein Configuration Wizard, fragt, ob er ggf Dienste restarten darf (ja). Zeit für eine Tasse Kaffee.

Und dann startet tatsächlich Sharepoint server. Grottenlahm, wie zu erwarten war. Mit einem SP auf Port 80 und der Sharepoint Central Administration auf Port 6531.


 

Porteus vom usb

Saturday, December 29. 2012

Schnell ist es ja. Wenn auch nur beim Booten.
In kaum einer Minute vom Einschalten bis in den KDE-Desktop (Trinity ~KDE 3.5), und das auf einer alten acer Travelmate 4060-Büchse ohne HD von einem 0815-usb. Und dabei sind mindestens 5, vllt aber sogar 15 sec. warten auf ein Timeout noch inklusive - das ist aber deutlich was schneller als der vorige Anlauf mit Mint.
Wenn man es erst mal zum Starten gebracht hat, und auch danach gilt: holp'rige Wegstrecke.

Porteus ist Kindeskind von Slackware, graue Eminenz der Distributionen. Meine erste Linux-Installation war ein Slackware, stilecht auf einem 386SX so circa 1997. Linux zu installieren war damals eine ziemlich frustrierende Angelegenheit, um es vorsichtig auszudrücken. 

Porteus sagt von sich, eine Distribution zu sein, die darauf optimiert ist, von Medien wie einem USB-Stick sehr schnell zu booten. Wie bringe ich Porteus bootfähig auf einen Stick? Da ist die Doku ganz klar: 

  • .iso herunterladen, auf cd brennen
  • Rechner von der CD-Rom nach Porteus booten
  • usb-Stick einstecken
  • Porteus Installer machen lassen

Fein, dass mit dem neu booten übertrage ich einer vbox - vm aber davon ab folge ich der Anleitung wortwörtlich. Ergebnis: geht nicht.
Den Reminder angeklickt und Bootloader installieren ausgewählt, das Ding (ziemlich lange) machen lassen, bis es mir Erfolg meldet und dann den Laptop vom stick booten - und er benimmt sich, als sei überhaupt kein boot loader vorhanden. not a bootable disk.

Aus seiner Vorgeschichte misstraue ich dem stick etwas und formatiere ihn (vfat) neu. Wiederhole die vorigen Schritte, hat nichts geholfen.
Kurz gegoogelt und die Sache zu Fuss unternommen. 
Ja, hagelt es eine Ladung roter Fehler, md5 hash fail. Google drauf, finde http://forum.porteus.org/viewtopic.php?f=41&t=1378
K
urzversion: am 10.7.2012 bestätigt der Guru dieser Distri, dass er da in der Datei md5sums.txt irgendwie die falschen Pfade erwischt hat. 
Mein Download war am 28.12, satte 5,5 Monate später, und der bestätigte Bug ist unverändert drin. 

Der empfohlene workaround war ohnehin, die roten Fehler schlicht zu ignorieren unde weiter zu machen. Was ich auch tat, nur um nun beim nächsten Bootversuch Fehler analog dieser Beschreibung zu bekommen:

 

SYSLINUX 4.04 CHS 2011-04-18 Copyright (C) 1994-2011 H. Peter Anvin et al
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
(bei mir war es SYSLINUX 4.05)
 
Der Poster meldet am Ende des Threads, er sei nun darauf gekommen, dass Syslinux auf seinem Rechner fat-32 nicht erkennt, mit fat-16 ging es. Fat-16 war mir nun wirklich zuviel an Erniedrigung aber ich beschloss, seinen Tip doch aufzugreifen und meinen Stick mal wieder neu zu formatieren, zur Abwechslung mit ext3. Anschliessend /boot und /porteus vom .iso auf den Stick kopieren, den Bootloader mit 
/boot/lin_start_here.sh
installieren, Test-Boot und Bingo!, auf einmal kommt die Kiste hoch. Sauschnell, siehe oben.
 
Ländereinstellung (deutsches Tastatur-Layout) sind nicht von einer Sitzung zur nächsten persistent.
Trinity hält sie aber wenigstens während der laufenden Session bei, während unter LXDE das US-Layout schon nach wenigen Mouseclicks wieder zurückkehrt. Porteus-Settings nimmt sich desbezüglich einige Zeit, ändert letztlich aber gar nichts am Ablauf.
 
Nur Google aus dem Network-Package zu installieren geht schief. Es kommt (kurz)= eine MsgBox mit einem Hinweis auf Misserfolg beim Anlegen des Profile und dann segfaults Chrome. Mit dem mc im Dateisystem herumspazierend fallen mir dann diverse zerbrochene Symlinks unter / auf libs unter /usr/lib/seamonkey auf. So sensibilisiert entdecke ich im Network-Package dann die Seamonkey shared libs, die aktiviert und auf einmal geht Google Chrome auch. 
Unter LXDE schafft es Google-Chrome mehrfach nicht, die Settings mit dem Google-Account zu synchronisieren, das ding lädt und lädt und lädt... Zurück auf Trinity/KDE klappt es aber.
 
Also im ersten Eindruck: mehr als nur ein paar ungeschliffene Ecken sind schon dabei...
 

 

 

Die Anforderung, aus einem laufenden System ein Debian neu zu installieren, ergibt sich zum Beispiel, wenn ein System neu aufgesetzt werden soll, abe kein passendes optisches Laufwerk zur Verfügung steht.

Die Lösung heißt debootstrap und das Vorgehen ist etwa hier oder hier gut beschrieben. 

Outline:
apt-get install debootstrap
mkdir /target/proc
mkdir /target/dev
mkdir /target/sys
mount --bind /proc /target/proc
mount --bind /dev /target/dev
mount --bind /sys /target/sys
mount -t devpts devpts /
target/dev/pts

debootstrap --arch i386 squeeze /target http://ftp.de.debian.org/debian

(Tasse Kaffee)

 chroot target

Nach dem letzten Befehl sind wir per chroot im neu aufgesetzten (rudimentären) System,  dem wir nun mit Hilfe von apt-get und einem Editor noch manches ergänzen müssen, ehe es booten kann:

/etc/apt/sources.list editieren
apt-get install console-data console-common tz-data less locales keyboard-configuration
apt-get install  linux-image-686
dpkg-reconfigure tzdata console-data console-common keyboard-configuration
passwd   (root passwd setzen!)
/etc/fstab (Eintrag für /proc nicht vergessen)
/etc/network/interfaces
/etc//udev/rules.d/70-persistent-net.rules  (Einträge löschen, falls nachher andere NIC)

(Page 1 of 2, totaling 9 entries) » next page