Et part noter omkring brug af RapidSSL til apacheer det f.eks. bestilles via billigssl.dk som videre sælger disse certificater til 100 kr. incl moms hvilket er billigt og jeg finder dem fine nok til at sikre "private" sider.

Når man går i gang skal man have en sekundær mail adresse tilrådighed for domainet, disse skal være en af de faste system email navne, så som This email address is being protected from spambots. You need JavaScript enabled to view it. / This email address is being protected from spambots. You need JavaScript enabled to view it. / This email address is being protected from spambots. You need JavaScript enabled to view it. / This email address is being protected from spambots. You need JavaScript enabled to view it. / This email address is being protected from spambots. You need JavaScript enabled to view it. og skal bruges til at verificer at du har kontrollen over domainet.

Dan en key

openssl genrsa -des3 -out www.domain.xx.key 2048

Fjern kodeordet fra key'en

openssl rsa -in www.domain.xx.key -out www.domain.xx.key.unsecure

lav csr til bestilling af certificat.

openssl req -new -key www.domain.xx.key -out www.domain.xx.csr

Når bestillings processen er gennemført og man får tilsendt sin crt samt intermitiate crt, skal man f.eks. hvis man henter disse ud via OWA, sætte disse ind i wordpad hvis man er på en Windows boks, før disse igen kopieres til www.domain.xx.crt filen på webserveren ellers begynder man at se fejl som nedestående og apache stopper med at køre:
[error] Unable to configure verify locations for client authentication
[error] SSL Library Error: 151441510 error:0906D066:PEM routines:PEM_read_bio:bad end line

DVS. pas på hvilke file format man får hentet crt ud med, CR / CR LF og htlm kode har naturligevis en indvirkning på certificat filerne.
´

I apache sites filen defineres pathen til disse 3 filer.

SSLCertificateFile /etc/apache2/ssl/www.domain.xx.crt
SSLCertificateKeyFile /etc/apache2/ssl/www.domain.xx.key.unsecure
SSLCACertificateFile /etc/apache2/ssl/www.domain.xx.crt.intermediate

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.