Linux Dienst mit privilegiertem Port ohne Administrator-Rechte

Diens­te soll­ten nicht mit admi­nis­tra­ti­ven Rech­ten gestar­tet wer­den. Es sei denn der Dienst sieht dies vor und erstellt die Unter­pro­zes­se mit nor­ma­len Pri­vi­le­gi­en.
Nicht jede Appli­ka­ti­on berück­sich­tigt das, was zur Fol­ge hat, dass man­che Pro­zes­se kei­ne Diens­te im unte­ren Port­be­reich zur Ver­fü­gung stel­len können.

Hier schafft man ein­fach mit authbind Abhil­fe. So kann zum Bei­spiel eine klei­ne Web­ser­ve­r­ap­pli­ka­ti­on mit Benut­zer­rech­ten auf Port 80 lau­fen.
Möch­te man dem Benut­zer "mini­ser­ver" das Recht geben dies durch­zu­füh­ren, legt man mit touch /etc/authbind/byport/80 eine lee­re Datei an und über­gibt mit chown miniserver:miniserver /etc/authbind/byport/80 deren Besitz. Zuletzt wer­den mit chmod 500 /etc/authbind/byport/80 noch die Rech­te limi­tiert.
Nun kann die Appli­ka­ti­on mit authbind als Wrap­per gestar­tet wer­den und darf auf Port 80 lauschen.

WIM von ISO für USB-Stick splitten

Inzwi­schen sind die Win­dows Instal­la­ti­ons­images so groß gewor­den, dass sie nicht mehr auf FAT32-Daten­trä­ger kopiert wer­den kön­nen. Mit fol­gen­dem Befehl kön­nen die­se gesplit­tet werden:

dism /Split-Image /ImageFile:"<Pfad>\install.wim" /SWMFile:"<Pfad>\install.swm" /FileSize:1024

Anschlie­ßend kann die install.wim gelöscht und der ISO-Inhalt pro­blem­los auf den USB-Stick kopiert werden.

Problem mit Desktop-Symbolen unter Windows 10 Creators Update beheben

Das Crea­tors Update (Ver­si­on 1703 = Build 15063) für Win­dows 10 bringt auf eini­gen Sys­te­men mit bestimm­ten Moni­tor-Auf­lö­sun­gen die Desk­top-Sym­bo­le durch­ein­an­der. Anschlie­ßend las­sen sich die­se auch nicht mehr kor­rekt anord­nen. Dies fällt beson­ders dann auf, wenn meh­re­re Icons gleich­zei­tig mar­kiert und ver­scho­ben werden.

Hier­für gibt es eine ein­fa­che Lösung:
Durch einem Rechts­klick auf eine freie Stel­le des Desk­tops erscheint das Kon­text­me­nü. Hier ist unter "Ansicht" die bereits akti­ve Grö­ße der Desk­top-Icons (z.B. "Mit­tel­gro­ße Sym­bo­le") erneut aus­zu­wäh­len. Dadurch wer­den die Sym­bo­le neu am Git­ter aus­ge­rich­tet und die Posi­tio­nen korrigiert.

Anschlie­ßend funk­tio­niert die Posi­tio­nie­rung wie­der wie gewohnt und auch zuvor uner­reich­ba­re Berei­che an den Rän­dern kön­nen wie­der ord­nungs­ge­mäß genutzt werden.

WSUS auf Windows Server 2012 R2

Instal­liert man die Win­dows Ser­ver Update Ser­vices (WSUS) nach­träg­lich auf einem voll gepatchen Win­dows Ser­ver 2012 R2, erhal­ten Win­dows 7 oder Ser­ver 2008 (R2) kei­nen Zugriff auf den WSUS. Grund dafür ist, dass der Sel­f­Up­da­ter unvoll­stän­dig instal­liert wird und die betrof­fe­nen Cli­ents den pas­sen­den Upda­ter nicht nach­la­den können.
Bei­spiels­wei­se exis­tiert in die­sem Fall der Ord­ner C:\Programme\Update Services\SelfUpdate\WSUS\x64\win7sp1 nicht.

Die Lösung ist, das Update KB2938066 vom WSUS-Ser­ver zu ent­fer­nen und die­sen neu zu star­ten. Anschlie­ßend kann das Update regu­lär wie­der instal­liert wer­den, was einen wei­te­ren Neu­start und die nun kor­rek­te Funk­ti­on mit sich bringt.

Windows 7 Setup mit USB3- & Controllertreibern

Wenn man noch Win­dows 7 auf aktu­el­ler Hard­ware instal­lie­ren möch­te, nutzt man in der Regel einen USB-Strick als Instal­la­ti­ons­me­di­um. Hat das ver­wen­de­te Main­board oder der Lap­top jedoch aus­schließ­lich USB3-Anschlüs­se, muss der USB3-Trei­ber in das Set­up ein­ge­bun­den wer­den. Neben der indi­vi­du­el­len, manu­el­len Metho­de, emp­fiehlt sich gene­rell das erstel­len eines Instal­la­ti­ons­images, das die­sen ent­hält. Neben­bei kann auch gleich der Intel RST-Trei­ber ein­ge­bun­den werden.

Die Trei­ber erhält man z.B. direkt von Intel:
USB3-Trei­ber
Con­trol­ler-Trei­ber

Hier­zu müs­sen fol­gen­de Ord­ner erstellt werden:

C:\WIM
C:\WIM\MOUNT
C:\WIM\drivers

In den Ord­ner C:\WIM wird vom Instal­la­ti­ons­me­di­um die boot.wim und install.wim kopiert und in den Ord­ner C:\WIM\drivers anschlie­ßend die Trei­ber (x86 oder x64) extra­hiert. Anschlie­ßend kann die Imple­men­tie­rung erfol­gen. Die­se wird auf­grund der Mount-/Un­mount-Vor­gän­ge mit Admi­nis­tra­tor­rech­ten ausgeführt.

Für ein 32 Bit Installationsmedium:

dism.exe /Mount-WIM /WimFile:"C:\WIM\install.wim" /index:1 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit
dism.exe /Mount-WIM /WimFile:"C:\WIM\install.wim" /index:2 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit
dism.exe /Mount-WIM /WimFile:"C:\WIM\install.wim" /index:3 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit
dism.exe /Mount-WIM /WimFile:"C:\WIM\install.wim" /index:4 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit
dism.exe /Mount-WIM /WimFile:"C:\WIM\boot.wim" /index:1 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit
dism.exe /Mount-WIM /WimFile:"C:\WIM\boot.wim" /index:2 /MountDir:"C:\WIM\MOUNT"
dism.exe /image:"C:\WIM\MOUNT" /Add-Driver /driver:"C:\WIM\drivers" /ForceUnsigned /recurse
dism.exe /Unmount-wim /mountdir:"C:\WIM\MOUNT" /commit

Anschlie­ßend wer­den die bei­den modi­fi­zier­ten Datei­en nur noch zurück auf den USB-Stick kopiert.

Debian Minimal-Installation auf Raspberry Pi

Um den Raspber­ry Pi als klei­nen Ser­ver zu benut­zen, sind die vor­ge­fer­tig­ten Images von Raspbi­an über­di­men­sio­niert und im Hin­blick auf Boot­zeit und Grund­aus­las­tung unge­eig­net. Seit meh­re­ren Jah­ren nut­ze ich des­halb das Pro­jekt "Raspbi­an (mini­mal) unat­ten­ded net­in­stal­ler", wel­cher ab dem Modell 1B ein­ge­setzt wer­den kann.

Um die aktu­el­len Ker­nel zu nut­zen und auch das Modell 3 zu unter­stüt­zen habe ich das Pro­jekt ent­spre­chend ange­passt. Von der Releases-Sei­te mei­nes Forks kann eine ZIP-Datei her­un­ter­ge­la­den wer­den, des­sen Inhalt ledig­lich auf die SD-Kar­te kopiert wer­den muss.

Anschlie­ßend ein­fach die (µ)SD-Karte und ein mit DHCP und Inter­net­ver­bin­dung ver­sor­gen­des Netz­werk­ka­bel anste­cken, Strom­ver­sor­gung anschlie­ßen und nach ca. 15 Minu­ten Instal­la­ti­ons­zeit boo­tet auto­ma­tisch ein mini­ma­les, sau­be­res Debi­an auf dem Pi.

Anpas­sun­gen des Instal­la­ti­ons­vor­gangs mit­tels einer installer-config.txt kön­nen ana­log zum Ursprungs­pro­jekt gemacht werden.

Man soll­te dar­an den­ken, nach der Instal­la­ti­on mit­tels dpkg-reconfigure locales die Spra­che, dpkg-reconfigure console-data das Tas­ta­tur­lay­out und dpkg-reconfigure tzdata die Zeit­zo­ne festzulegen.

OpenWRT für ASUS RT-N16

Was Leis­tung, Sta­bi­li­tät und Zuver­läs­sig­keit betrifft, ver­rich­tet der ASUS RT-N16 auch nach mehr als fünf Jah­ren vie­ler­orts gute Diens­te. Ledig­lich einer der Kon­den­sa­to­ren im Bereich der Buch­se für die Span­nungs­ver­sor­gung (vio­let­tes Gehäu­se, 680µF) soll­te prä­ven­tiv gegen einen mit höhe­rer Span­nungs­fes­tig­keit getauscht werden.

Doch gera­de für ein Embedded-Gerät, das mit 32MB Flash­spei­cher und 128MB RAM ver­hält­nis­mä­ßig üppig aus­ge­stat­tet ist, lohnt es sich, des­sen Leis­tungs­re­ser­ven mit Open­WRT und den dort zur Ver­fü­gung ste­hen­den Pake­ten auch zu nutzen.

Um sich ein pas­sen­des Image zu bau­en, nutzt man am Bes­ten den Image­Buil­der, mit wel­chem der pro­prie­tä­re und dadurch die höchs­te Leis­tung bereit­stel­len­de SoC/­Wi­Fi-Trei­ber vor­ab inte­griert wer­den kann. Für den ASUS RT-N16 ist die­ser im Ord­ner brcm47xx/generic des jeweils aktu­el­len Open­WRTs zu finden.

Ein Image mit Web­in­ter­face baut der Befehl:

make image PROFILE=Broadcom-wl PACKAGES="luci"

Das fer­ti­ge Image mit dem Namen "openwrt-<version>-brcm47xx-generic-squashfs" fin­det sich anschlie­ßend im Unter­ver­zeich­nis ./bin.

 

Kernelupdate und Grub2 auf XEN-VMs

Ein XEN basier­ter vSer­ver hat den gro­ßen Vor­teil, dass eige­ne Ker­nel und Modu­le genutzt wer­den können.
Stellt der Pro­vi­der VMs jedoch nur mit Grub 1 zur Ver­fü­gung ver­hin­dert die Aus­gangs­kon­fi­gu­ra­ti­on aber unter Umstän­den das Boo­ten neue­rer Ker­nels, da "update-grub" die "menu.lst" nicht auto­ma­ti­siert anpas­sen kann.

Im Zuge der Kor­rek­tu­ren darf auch auf Grub 2 migriert wer­den. Hier­bei wer­den die Grub-Ein­trä­ge kom­plett neu gene­riert und sicher­ge­stellt, dass auch Hosts, wel­che Grub 2 nicht selbst­stän­dig laden, ent­spre­chend wei­ter­ge­lei­tet wer­den. Even­tu­el­le Feh­ler­mel­dun­gen, wel­che beim Auf­ruf von "update-grub" auf­tre­ten kön­nen igno­riert wer­den, sofern die jeweils letz­te Aus­ga­be den Erfolg des Befehls anzeigt.

Die fol­gen­den Befeh­le bezie­hen sich auf Debi­an v8.x:

apt-get -y install grub-legacy
cp -pR /boot/grub/ /boot/grub_old
rm -rf /boot/grub/*
rm -rf /boot/xen/*
update-grub
apt-get -y purge pv-grub-menu grub-common grub-legacy grub-pc grub2 grub2-common
apt-get -y install grub-xen
grub-install --target=x86_64-xen
sed -i 's/timeout\t\t5/timeout\t\t0/' /boot/grub/menu.lst
sed -i 's/# groot=(hostdisk\/\/dev\/xvda1)/# groot=(hd0,0)/' /boot/grub/menu.lst
nano /boot/grub/menu.lst

Alle Ker­nel in der Lis­te ent­fer­nen und erset­zen durch:

title Chainload Grub 2
root (hd0,0)
kernel /boot/xen/pvboot-x86_64.elf

Abschlie­ßend Grub 2 fer­tig kon­fi­gu­rie­ren lassen:

sed -i 's/GRUB_TIMEOUT=5/GRUB_TIMEOUT=0/' /etc/default/grub
update-grub

Nun kann die VM neu gestar­tet werden.

Optio­nal:
Wenn gewünscht, kann auch "fstab" ange­passt wer­den, sodass gemäß den Richt­li­ni­en von Debi­an v8 UUIDs als Iden­ti­fier genutzt wer­den. "xvda2" wird im fol­gen­den Bei­spiel als Swap gemountet:

sed -i 's/^\/dev\/xvd/#\/dev\/xvd/' /etc/fstab
sed -i 's/^proc/#proc/' /etc/fstab
echo "# /dev/xvda1" >> /etc/fstab
echo -e "$(blkid /dev/xvda1 -s UUID | awk '{print $2}' | sed 's/\"//g')\t/\t\t$(df -T /dev/xvda1 | grep "^/dev" | awk '{print $2}')\terrors=remount-ro\t0\t1" >> /etc/fstab
echo "# /dev/xvda2" >> /etc/fstab
echo -e "$(blkid /dev/xvda2 -s UUID | awk '{print $2}' | sed 's/\"//g')\tnone\t\tswap\tsw\t\t\t0\t0" >> /etc/fstab

FritzBox VoIP-Anmeldedaten auslesen

Vie­le Anbie­ter geben die Anmel­de­da­ten für die VoIP-Anmel­dung (noch) nicht her­aus. Wur­den die Daten per TR-069 vom Anbie­ter auto­ma­ti­siert in eine Fritz­Box ein­ge­tra­gen, gibt es jedoch eine brauch­ba­re Lösung. Hier­für wird das in der Fritz­Box ent­hal­te­ne Tool "all­cfgconv" ver­wen­det, das jedoch von AVM in der Funk­tio­na­li­tät beschnit­ten wurde.
Das Erset­zen der "all­cfgconv", um den not­wen­di­gen decrypt-Para­me­ter wie­der­her­zu­stel­len wur­de inzwi­schen durch etli­che Ände­run­gen an den Abhän­gig­kei­ten der auf­ge­ru­fe­nen Diens­te deut­lich erschwert. Deren Wie­der­her­stel­lung ist sehr zeitaufwändig.
Die schnells­te und unpro­ble­ma­tischs­te Mög­lich­keit ist der Export der Daten und der Import auf eine mit Firm­ware­stand vor v6.20 down­ge­gra­de­te Fritz­Box. Am Ein­fachs­ten geht dies durch Aus­wahl der Firm­ware und Kom­pi­lie­rung eines ent­spre­chen­den Freetz-Images. Auf die­se Wei­se kann auch bequem der Tel­net-Dae­mon gestar­tet und dort die Daten aus­ge­le­sen werden.

Zum Auf­spie­len des Freetz-Images soll­te unter allen Umstän­den die Web­ober­flä­che genutzt wer­den, da das "push_firmware"-Tool von Freetz bei man­chen Boxen nicht mehr wie vor­ge­se­hen funk­tio­niert und die Box anschlie­ßend nicht mehr boo­tet. Die­ses Pro­blem lässt sich durch ein pas­sen­des Reco­ver-Tool vom AVM-FTP behe­ben. Doch auch hier gibt es einen Stol­per­stein: Zwar las­sen die Ober­flä­chen der vom Pro­vi­der gelie­fer­ten Fritz­Bo­xen oft kein Bran­ding mehr erken­nen, jedoch ist in der Regel eine "Urla­der-Envi­ron­ment-Varia­ble" gesetzt, durch wel­che das Reco­ver-Tool die Funk­ti­on ver­wei­gert. Im ADAM2-Boot­loa­der kann die­se jedoch gelöscht wer­den. Ein­schrän­kun­gen (auch die TR-069-Kom­pa­ti­bi­li­tät bleibt erhal­ten) konn­te ich kei­ne feststellen.

Vor­ge­hens­wei­se zur Her­stel­lung der Recover-Tool-Kompatibilität:
Benut­zer­na­me & Pass­wort für den ADAM2-Boot­loa­der: "adam2"

quote GETENV provider   # diesen Wert notieren
quote UNSETENV provider
quote REBOOT

Anschlie­ßend funk­tio­niert das Reco­ver-Tool wie gewünscht.

GitHub Release Notifications

Nach­dem ich immer mehr Pro­jek­te bei Git­Hub ver­fol­ge und ein­set­ze, war der Ein­satz einer auto­ma­ti­schen Benach­rich­ti­gung bei neu­en Ver­sio­nen überfällig.

Lösun­gen, wie "Sib­bell" sind lei­der noch nicht aus­ge­reift oder funk­tio­nie­ren über­haupt nicht. Inzwi­schen set­ze ich "rss2email" ein.

Setzt man hin­ter die URL des Release-Tabs das Suf­fix ".atom", erhält man dadurch die URL, wel­che von "rss2email" ein­ge­le­sen wird und deren Ein­trä­ge — sofern noch nicht ver­sandt — per eMail an den gewünsch­ten Emp­fän­ger geschickt werden.
Die Kon­fi­gu­ra­ti­ons­da­tei ist nach der Initia­li­sie­rung unter "~/.config/rss2email.cfg" zu finden.