Historien fra idag:

KVM hosten der triller gw.mxbox.dk og web-serveren som køre dette site, døde i nat med en disk fejl, i dennes RAID 1
Jeg havde ikke få lavet mit raid 1 grub konfiguration korrekt, sådan at den kunne boote på den sekundære disk, den primære disk sagde en "lyd" som de fleste it-folk kan genkende, lyden af et sata disk som ikke kan spinne op, Thuu thuu thuu, vil jeg gætte på lyd-sproget kan gengives med.

Ny hardware til en KVMhost blevet fundet i gemmerne, vigtigst var at den cpu mæssigt understøttede KVM.
egrep '(vmx|svm)' --color=always /proc/cpuinfo vil verficier om hardwaren understøtter KVM.
OBS.  en Hyper-V 2012 R2 guest, understøtter ikke de rigtige cpu features som kræves for at køre KVM. "been there, done that"

installation er debian wheezy standard, på hardware.
installation af KVM på debian <-  http://www.howtoforge.com/virtualization-with-kvm-on-a-debian-squeeze-server samt http://www.server-world.info/en/note?os=Debian_7.0&p=kvm 

Tag den virkende harddisk ud af den gamle server, og tilslutte den nye server via USB.

Kør nedestående for at finde hvilket /dev/sd? som usb diske kan findes under.
 fdisk -l

Hos mig viste det at diske lå som /dev/sde

herefter skal mdadam før benyttes, da den gamle disk var med Linux software raid.

mdadm --assemble --run /dev/md9 /dev/sde2

mkdir /mnt/test
mount /dev/md9 /mnt/test

Herefter kunne de gamle *.img filer hentes fra nedenstående mappe.

cp -r /mnt/test/var/lib/libvirt/images/*.img /var/lib/libvirt/images/

Config filerne kunne hentes fra

cp -r /mnt/test/etc/libvirt/qemu/*.xml /etc/libvirt/qemu/

Nu skal KVM guest blot registeret igen, udfra *.xml filerne.

virsh define /etc/libvirt/qemu/guestnavn.xml

og maskinerne startes på ny

 virsh start guestnavn

Mine sites køre alle igen, 2 -3 timers søndags arbejde, hvor det meste skyldes kopiering af images fra USB til den nye server diske.

Jeg har i de sidste år benyttet mig af Fail2ban til at blokkere ipaddresser som forsøger at forcere sig ind på mine gateways, og jeg kan tydelig se at Kina er blevet mere aktivt i løbet af det sidste års tid og er lidt træt af de samme ipaddresser forsætter med at prøve at logge ind med root via ssh, selvom at "permitrootlogin = no" er sat i sshd.

F.eks den sidste uges blokkeret ipaddresser taget ud fra fail2ban.log

zgrep -h "Ban " /var/log/fail2ban.log | awk '{print $5,$1,$7}' | sort 

[ssh] 2013-12-29 138.91.192.42
[ssh] 2013-12-29 58.215.133.52
[ssh] 2013-12-29 61.147.113.77
[ssh] 2013-12-29 61.147.113.83
[ssh] 2013-12-30 123.147.162.173
[ssh] 2013-12-30 193.107.16.206
[ssh] 2013-12-30 222.175.114.134
[ssh] 2013-12-30 32.65.224.46
[ssh] 2013-12-30 50.30.33.6
[ssh] 2013-12-30 58.215.240.94
[ssh] 2013-12-30 61.147.113.77
[ssh] 2013-12-30 61.147.116.8
[ssh] 2013-12-30 61.147.74.149
[ssh] 2013-12-30 61.160.251.140
[ssh] 2013-12-30 92.62.1.5
[ssh] 2013-12-31 201.44.88.212
[ssh] 2013-12-31 46.238.116.34
[ssh] 2014-01-01 122.192.35.146
[ssh] 2014-01-01 124.115.18.14
[ssh] 2014-01-01 124.160.194.27
[ssh] 2014-01-01 183.129.249.106
[ssh] 2014-01-01 58.215.133.52
[ssh] 2014-01-01 61.147.113.77
[ssh] 2014-01-01 61.160.251.140
[ssh] 2014-01-02 124.160.194.27
[ssh] 2014-01-02 213.92.117.212
[ssh] 2014-01-02 222.175.114.134
[ssh] 2014-01-02 61.144.43.235
[ssh] 2014-01-02 61.147.113.83
[ssh] 2014-01-02 61.147.74.149

Min list over banned ipaddresser som opdateres en gang i timen kan ses her: http://gw.mxbox.dk/fail2banIp.html

61.147.0.0/16 er efter hvad jeg kan se ipaddresser fra kina og jeg kan se at det er gengangere på nogle af mine andre gateways rundt omkring.

Her i aften har jeg tilføjet en nu fail2ban jail, som blokkere ipaddressen i væsentlig længere tid, end default, ligeledes holder den sin egen logfile, dvs. en ipaddresse som bliver banned for 2 uger siden slippe ikke uden om, at blive banned, i laaaaaaang tid blot fordi at auth.log er blevet overskrevet.

http://stuffphilwrites.com/2013/03/permanently-ban-repeat-offenders-fail2ban/

 

 

Jeg har haft tid til at lege lidt de sidste par aftner, med et lille Debian router projekt.

Router os installation Debian wheezy standard:

Services SSH + dhcp til de 2 test interfaces + forward af ipv4 enabled.

Hardware:

DG945GCLF2 + Intel PRO/1000 MT Dual Port Server Adapter (pci / pci-x) 82546EB Chip.

Test 1: virker et pci-x netkort i DG945GCLF2 PCI slot

Resultat: JA

Test 2: hvordan performer et pci-x i et PCI slot ?

Iperf har jeg haft til at vise 748 MBit/ via x-kables fra en bærbar til 1 aktiv interface på Intel netkortet.

begyndte jeg at aktivere begge Ethernet porte i Intel kortet på en gang faldt performance til ca. 380 - 500Mbit uanset om jeg kørete igennem routeren, eller jeg testede op imod routeren med iperf.

Jeg fik 100 CPU forbrug, da jeg forsøgte at køre Iperf fra test maskine A til router interface B og test maskine B til router interface A ( routeren var iperf server)

Jeg har en formodning om at det kan være PCI porten som er årsag til at jeg ikke får mere performance ud af de 2 GBIT porte, når begge er aktive på en gang.

Iperf mellem test maskiner.

Iperf mellem test maskiner

Jeg tror at næste test bliver hvor jeg har installeret Mikrotik RouterOs på selv samme hardware og ser om dette "ændre" på speeden.


Et godt værktøj til at håndtere store file kopieringer er screen samt Rsync.

Store kopieringer kan være mange forskellige ting, i mit tilfælde er det en Iscsi lun som der skal laves en backup af til en anden server på et andet site.
File størrelse er 500GB plus...
båndbredte er max 20MBit...

Derfor betyder det meget at ikke skulle lave en ny kopiering af hele filen hver gang der skal laves en backup, men det kan klares ved at lave delta, når først den første kopi er i hus.

Kopi 1 skal laves via rsync --sparse  (-S)

Opdatering af kopi skal laves via Rsync --inplace

Credits til: http://gergap.wordpress.com/2013/08/10/rsync-and-sparse-files/  som løste dette issue for mig med hans poste.

Jeg har på det sidste leget med en Epson WF-7015 A3 / A4 printer, baggrund er at jeg har skulle lave et mobilt A3 print koncept, til nogle personer som var på farten over flere dage, uden at komme tilbage til kontoret, personerne er udstyret med Apple IOS enheder, derfor AirPrint.

Egentlig burde jeg havde bestilt WF-7525 som har native airprint, men der gik ged i min research og jeg fik bestilt en forkert printer, nemlig WF-7015'eren.... og der gik faktisk mere ged i det, for leverandøren fik sendt 2 af disse printer til 2 forskellige addresser :-(

3 tekniske ting jeg har lært her af:
WF-7015 understøtter ikke NATIV AirPrint, ej heller epson's egne iOS printer apps, efter hvad jeg har forsøgt.
Der findes ikke CUPS driver til wf-7015 på debian armhf pladformen (Rasbian) 
Airprint kan leveres af en Cups print server, for ikke så langtid siden skulle man bruge et airprint-generate.py script fra github, men mine tests med Debian Wheezy og Cups viser at dette faktisk ikke længere er nødvendigt :-)

Konceptet havde derudover et par udfordringer, som skulle løses.
IOS enheden skulle kunne være Mobilt internet for at via VPN forbinde sig til firmaets server, hvor dokumenterne ligger, samtidig med at der blev printet.
konceptet skulle kunne leve i en bil og af et bil batteri, hvilket sætter krav til standby strøm forbrug, og hvorlangtid til lever i enhedernes opsætning, når enheden er uden størm.

Løsninger:
WF-7015 manglende nativ airprint -> en Linux enhed som køre en cups printer server.
Mobilt forbindelse til firma serveren -> IOS enheden skal danne Wifi netværket (internet deling) til Linux cups print serveren, der automatisk skal koble sig på når det "mobile" netværk er tilstede.
Bil batteri, 12Vto230v converter samt intet skal ligge i memory, dvs. printeren selv skal holdes "dum".

Koncept Version 1 var at bruge en RasberyPI enhed til at lege Airprint Cups server, men da OpenPrinter kun har kompertible WF-7015 driver med X86 pladformen og ingen til armfs, løb jeg i et problem som jeg ikke selv kunne løse. ( hertil virkede rasberian forholdvis langsom til at "spoole" printerdata, lavede faktisk et forsøg med dette setup.

Kencept Version 2 brug en af de I386 gamle laptop's jeg har liggende, de har indbygget wifi og har nok kræfter til at køre en cups server.

Kort, så pxe installerede jeg debian wheezy på maskinen, headless, dvs. ingen desktop, denne tager blot til at loade.
Netværk setup med at den automatisk logger på et kendt netværk klares via wpa_supplicant.conf
se dette blok indlæg http://www.raspberrypi.org/phpBB3/viewtopic.php?t=11517  som indeholder eksemple der kan tilpasses.

Cups print serveren installeres efter denne guide:
http://www.welzels.de/blog/projekte/raspberry-pi/raspberry-pi-als-airprint-server/
dog kan "airprint-generate.py delen vist springes over, laver man det også, ser man 2 "air print" enheder på set netværk.