med tidsrum rammer man ind i hardware som enten er for nyt til at der er opensource drivers eller at leverandøren ikke stille dette tilrådighede, det er naturligvis træls hvis man ønsker at "pxe" hardware og mangler netværks kortet eller disk controller.

Løsning er at følge denne guide på Debian Wiki :-)  meget meget simplet.

https://wiki.debian.org/DebianInstaller/NetbootFirmware

jeg selv skulle have tilføjeret Binary firmware for Broadcom NetXtremeII  som hentes her:  https://packages.debian.org/squeeze/firmware-bnx2

Microsoft best Practices
http://technet.microsoft.com/en-us/library/dn720239.aspx

Heruder at skifte disk scheduleren til noop.

hvilket gøre ved at editere i grub

vi /etc/default/grub
GRUB_CMDLINE_LINUX="elevator=noop"
update-grub2
reboot

se den aktive scheduler gøres ved at kalde
cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

en heden som står med [] er default disk scheduler

efter reboot

cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

 

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/