Tag: linux

heute nacht ist die dann hinfaellig:

= 3,46 jahre 😉

seit einiger zeit nervt der rkhunter auf einem debian lenny rum, dass ein paar appliktionen veraltet sind. dumm nur, wenn der paketmanager fuer die distribution keine neueren versionen im angebot hat.

Warning: Application 'gpg', version '1.4.9', is out of date, and possibly a security risk.
Warning: Application 'openssl', version '0.9.8g', is out of date, and possibly a security risk.
Warning: Application 'sshd', version '5.1p1', is out of date, and possibly a security risk.

das gemeckere bekommt man weg, in dem man diese zeile in die datei /etc/rkhunter.conf eintraegt:

APP_WHITELIST="gpg:1.4.9 openssl:0.9.8g sshd:5.1p1"

und dann beanstandet er auch noch das:

Warning: Suspicious file types found in /dev:
/dev/shm/network/ifstate: ASCII text

…ist aber ein anderes thema. die ursache ist wahrscheinlich, dass der speicherort von ifstate sich in der vergangenheit des oefteren geaendert hat. um diese meldung weg zu bekommen, muss man in die datei /etc/rkhunter.conf folgende zeile einzufuegen:

ALLOWDEVFILE=/dev/shm/network/ifstate

basierend auf dem testserverchen (debian lenny 64bit) hier ein echt kurzes xen (4.0.1) howto. und los gehts…

die benoetigten pakete installieren:

apt-get install xen-hypervisor xen-linux-system xen-utils xenstore-utils xenwatch xen-tools

die config datei fuer die xentools bearbeiten. (theoretisch kann man den kram auch alles auf der commandline mitgeben)

vi /etc/xen-tools/xen-tools.conf

…das eintragen:

lvm = vg0
dist   = `xt-guess-suite-and-mirror --suite`
gateway    = 192.168.0.1
netmask    = 255.255.255.0
broadcast  = 192.168.0.255
passwd = 1
kernel = /boot/vmlinuz-`uname -r`
initrd = /boot/initrd.img-`uname -r`
mirror = `xt-guess-suite-and-mirror --mirror`
serial_device = hvc0
disk_device = xvda

die xen(d) config anpassen:

vi /etc/xen/xend-config.sxp

und diese werte setzen bzw. aendern:

[...]
(network-script 'network-bridge antispoof=yes')
[...]
(vif-script vif-bridge)
[...]

und nach einem abschliessenden reboot kann der erste virtuelle server installiert werden:

xen-create-image --hostname=vs.sd.vc --size=150Gb --swap=4Gb --ip=192.168.0.100 --memory=1Gb --arch=amd64 --role=udev

dank der xen-tools config wird ein debian lenny installiert. andere kann man z.b. mit dem parameter “–dist=etch” instalieren.

die virtuelle kiste noch “anschalten” und gut is:

xm create /etc/xen/vs.sd.vc.cfg

have fun!

so… nachdem ich jahrelang mit dem vmware server gearbeitet habe, mache ich mich nun mal an xen.
fuer die ersten gehversuche hab ich mir bei manitu einen rootserver gemietet. die entscheidung fiel auf manitu, da es dort (im gegensatz zu z.b. hetzner) standardmaessig vier ipadressen zu einem server gibt. da es ja nur zum “probieren” ist, reicht mir der rootserver M mit einem amd dualcore und 4gb ram vollkommen aus. zudem gibts keine mindestvertragslaufzeit bzw. ist monatlich kuendbar.

der server, der mir zugewiesen wurde, hatte prompt ein problem mit der hardware. von den zwei physikalischen festplatten wurde meistens nur eine erkannt. manchmal auch beide… und das mal so und mal so. der support hat mir kurzerhand einfach einen neuen server gegeben. mal schauen, wie es nun klappt.

um die kiste nach meinen vorstellungen zu partitionieren, hab ich ihn erstmal neu installiert. 4gb swap und 100gb fuer die root partition und beides als raid1. der rest wird ein lvm fuer die xen maschinchen. mit cfdisk auf beiden platten einfach den freien platz als eine partition des typs FD eingerichtet. das sieht dann so aus:

~# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         523     4200966   fd  Linux raid autodetect
/dev/sda2             524       13578   104864287+  fd  Linux raid autodetect
/dev/sda3           13579      121601   867694747+   5  Extended
/dev/sda5           13579      121601   867694716   fd  Linux raid autodetect

manchmal ist ein boot an dieser stelle notwendig. danach kann das raid device eingerichtet werden:

mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda5 /dev/sdb5

da kommt auch gleich wieder eine fehlermeldung:

mdadm: excess host name on HOMEHOST line:  - ignored
mdadm: excess address on MAIL line: root - ignored

die man mit einem freundlichen

vi /etc/mdadm/mdadm.conf

..und aendern der entprechenden werte los werden kann.

und damit die raid devices auch in der mdadm.conf stehen, muss man diesen befehl ausfuehren:

mdadm --detail --scan >> mdadm.conf

nun noch ein paar sachen drauf, die man sowieso immer braucht:

apt-get install ntp ntpdate rsync mc postfix lvm2 dmsetup reiserfsprogs xfsprogs

und die passende zeitzone einstellen:

dpkg-reconfigure tzdata

danach noch das physical volume und die volume group anlegen:

pvcreate /dev/md2
vgcreate vg0 /dev/md2

das reicht erstmal als vorbereitung fuer den xen server. das zeugs mit dem lvm wird gemacht, weil:
“Virtual machines that use disk images are very slow and heavy on disk IO”. normalerweise muesste man naemlich noch die standardeinstellung fuer die maximalen loopback devices in der datei “/etc/modules” erhoehen, damit man die ganzen disk images mounten kann.

morgen gehts weiter mit der installation der virtuellen maschinen. dann mal schauen, wie ich am einfachsten “alte” physikalische maschinen virtualisiere…

debian 2.1 und suse 5.2… die suse hab ich schnell aufgegeben. dabian ist seither meistens die distribution meiner wahl.

die cd’s hab ich heute im keller beim aufraeumen gefunden. irgendwie bringe ich es nicht uebers herz, sie weg zu schmeissen. brauchen werde ich sie aber auch niiiieee mehr.

damals musste man mangels bandbreite den kram noch auf cd’s kaufen. was ein scheiss.

schoen, wenn andere schneller sind…

…bloed, dass es nicht funktioniert hat. aber danke fuer den hinweis… ich lass das dann erstmal 😉

ein nachtrag zu dem posting “nic RTL8168b/8111b mit debian kernel 2.6.32-5-amd64” das wars dann wohl doch nicht. ich hatte in weiser vorraussicht schon ersatz fuer die realtek besorgt… dann doch ne gute intel 😉 und siehe da.. seit drei wochen laeuft die kiste wieder durch.

mein gestriges problem scheint ein bug zu sein. da die kiste neun wochen problemlos gelaufen ist, hatte ich eigentlich auf ein hardwareproblem getippt. gestern ist der fehler mindestens 7 mal aufgetreten und immer war die ganze kiste lahm gelegt. onkel google hat mir viele ergebnisse gebracht, wobei ich dann nur einen loesungsansatz verfolgte. seit 11 stunden laeuft mein servchen nun wieder durchgehend. schauen wir mal, obs die endgueltige loesung war.

als gedaechtnisstuetze….

$ sudo vi /etc/default/grub

das “pcie_aspm=off” einfuegen:

...
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="pcie_aspm=off"
...

und grub aktualisieren:

$ sudo update-grub

…boot toot goot

und nachher noch schnell gechecked, obs auch greift:

dmesg |grep aspm

sieht so aus…

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=480935f7-a232-4848-a049-68b7184b1f9a ro pcie_aspm=off quiet
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=480935f7-a232-4848-a049-68b7184b1f9a ro pcie_aspm=off quiet
[    0.505592] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'

nanunana… mein vmware serverchen, auf dem auch dieses blog laeuft, ist vorhin einfach “ausgestiegen”. scheinbar ein problem mit der netzwerkkarte:

soso.. “NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out”… na dann will ich mal google quaelen und forschen und sicherheitshalber mal schauen, ob ich irgendwo ersatz auftreibe… :-/