atime: dieser Zeitstempel spiegelt den letzten Zugriff (lesend und schreibend) auf die Datei wieder
mtime: wann wurde das letzte mal in die Datei geschrieben. Wird also gesetzt wenn die Datei erstellt wird und jedes mal neu wenn sich am Inhalt der Datei was aendert
ctime: etwas missverstaendlich ChangeTime (nicht CreateTime!). Dieser Zeitstempel aendert sich wenn der Inhalt der Datei geaendert wird (also genau wie bei mtime), aber auch wenn sich an den Metadaten der Datei (Zugriffsrechte, Besitzer, ..) aendern

Die Daten lassen sich unter Linux z.B. mit dem Kommando ‘stat’ anzeigen:

1
2
3
4
5
6
7
8

$ stat bild.png
  File: „bild.png“
  Size: 71253     	Blocks: 144        IO Block: 4096   reguläre Datei
Device: 803h/2051d	Inode: 138763      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  benutzer)   Gid: ( 1000/  benutzer)
Access: 2011-03-25 14:01:32.859874003 +0100
Modify: 2010-12-02 11:26:18.944805110 +0100
Change: 2010-12-05 11:26:18.944805110 +0100

Die Anwaltskanzlei Ferner Alsdorf hat eine gute Übersicht erstellt, die Urteile zu diesem Thema auflistet:
Streitwert: Unverlangte Zusendung von Email bzw. Newsletter

configure: error: Your t1lib distribution is not installed correctly. Please reinstall it.

unter Debian / Ubuntu einfach das Paket “libt1-dev” installieren:

1

aptitude install libt1-dev

Unter Redhat / CentOS gibt es die RPM Pakete unter http://packages.sw.be/t1lib/, unter CentOs 64 bit folgendes tun:

1
2
3

wget http://packages.sw.be/t1lib/t1lib-5.1.2-1.el5.rf.x86_64.rpm
wget http://packages.sw.be/t1lib/t1lib-devel-5.1.2-1.el5.rf.x86_64.rpm
rpm -Uvh t1lib*

Alle Links und Anleitung unter weiterlesen.

Dafür benötigt werden:

• aktuelles .NET Framework von Microsoft
• Dokan library
• Dokan SSHFS

Als erstes sollte man (wenn noch nicht vorhanden) das .NET Framework von Microsoft laden und installieren.
Anschließend die Dokan library. Das ist die Basis für das Dokan SSHFS und stellt eine Schicht zwischen der Anwendung (in dem Fall Dokan SSHFS) und dem Betriebssystem (Windows) zur Verfügung. Die Installation sollte keine weiteren Probleme darstellen, ein Neustart ist nicht nötig.
Als letztes einfach das Dokan SSHFS installieren. Auch hier sollte es keine Probleme geben.

Die Benutzung sollte weitestgehend selbsterklärend sein – einfach starten und die benötigten Daten eingeben:

• Unter “Host” den Hostnamen des Servers eingeben (z.B.: trafex.de)
• Bei “User” den Benutzernamen angeben, mit dem man sich einloggen möchte
• der Port ist der Port, unter dem der SSH Daemon auf dem Server erreichbar ist
• als nächstes kann man zwischen der Authentifizierung via Passwort wählen, dabei braucht man nur das Benutzerpasswort auf dem Server eingeben, oder ein SSH Keyfile.
• “Server Root” gibt das als Basisverzeichnis, welches eingebunden werden soll. Die darunterliegende Verzeichnisse sind, solang man nich neu Mounted, nicht erreichbar.
• zum Schluss gibt man den Laufwerksbuchstaben an, unter dem die Dateien unter Windows erreichbar sein sollen

Nach dem Connecten braucht es einen kleinen Augenblick. Im Erfolgsfall bekommt man in einer kleinen Box den Status “sshfs start” gemeldet, im Fehlerfall die Meldung “failed to connect” – dann sollte man einfach noch mal die Angaben überprüfen.

Für Ubuntu spricht für mich das es aktueller ist als Debian und sich trotzdem weitestgehend wie ein Debian bedienen lässt. Außerdem ist die Einrichtung von XEN ohne grosse Neukompilierung des Kernels möglich.

Mehr unter weiter lesen …

Als Anleitung fand ich eine veraltete Anleitung im serversupportforum, diese Anleitung basiert auf dieser.

Erster Schritt: Netzwerkdaten sichern

Diese muss man später wieder eintragen und sind zur Konnektivität sehr wichtig.

Die wichtigsten Daten erhält man mit dem mit dem Befehl:

ifconfig

Man erhält in Etwa folgende Ausgabe:

eth0      Link encap:Ethernet  HWaddr 00:13:8F:10:92:8F
          inet addr:85.12.123.123  Bcast:85.12.123.255  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17660218 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18155043 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1490089780 (1.3 GiB)  TX bytes:3045423043 (2.8 GiB)
          Interrupt:16 Base address:0xdc00

Folgende Werte sind wichtig: “inet addr”, “Bcast” und “Mask”, diese notieren.
Weiterhin brauchen wir noch die IP-Adresse des Gateways:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
85.12.123.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         85.12.123.1     0.0.0.0         UG    0      0        0 eth0

Hier notieren wir uns die IP hinter der Zeile die mit “0.0.0.0″ beginnt (in dem Fall also 85.12.123.1)

Weiterhin die Inhalte der Dateien /etc/resolv.conf notieren.

Zweiter Schritt: Rettungssystem booten & Festplatte vorbereiten

Jetzt startet ihr das Rettungssystem. Das geht meistens über das Web-Interface eures Anbieters.
Sobald ihr euch da eingeloggt habt leeren wir die Platte des Servers und teilen diese neu ein.

2. Festplatte & Dateisysteme

Ich habe meine Festplatte nach dem “klassischem” Schema partitioniert.
/dev/sda1 als ext2 für das Boot-Device mit dem Boot-Flag,
/dev/sda2 für Swap
/dev/sda3 als ext3 für die Daten
Einteilen des ganzen mit fdisk (Anleitung z.B. hier) und dann die Dateisysteme anlegen und alles mounten:

mke2fs /dev/sda1
mke2fs -j /dev/sda3
swapoff -a
swapon /dev/sda2
mkdir /mnt/debinst
mount /dev/sda3 /mnt/debinst
mkdir /mnt/debinst/boot
mount /dev/sda1 /mnt/debinst/boot

Hinweis: falls der Swap-Bereich vorher noch nicht eingerichtet worden ist, muss man diesen erst mit “mkswap /dev/sda2″ initialiseren. Danke an Andi für diesen Hinweis. (siehe Kommentare)

3. Ubuntu Basisdateien

Nachdem alles gemountet ist geht es an die Installation von Ubuntu mittels debbootstrap. (aktuell ist Intrepid)
Die Basisdateien holt man sich vom Ubuntu-Server. Danach muss man das .deb-Paket umwandeln, damit man es einfach entpacken kann:

mkdir /mnt/debinst/root
cd /mnt/debinst/root
wget http://de.archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~intrepid1_all.deb
ar -xf debootstrap_1.0.10ubuntu1~intrepid1_all.deb
cd /
tar -zxvf /mnt/debinst/root/data.tar.gz
/usr/sbin/debootstrap --arch amd64 intrepid /mnt/debinst/ http://de.archive.ubuntu.com/ubuntu

Wer keine 64Bit-Installation (bei Intel-Prozessoren auch amd64 benutzen) möchte erstzt das amd64 mit i386.
Das ganze dauert jetzt etwas. Das Script holt sich die Ubuntu-Basisdateien vom Ubuntu-Server und packt sie an die richtigen Stellen auf der gemounteten Partition.
Wenn das ganze dann fertig ist müssen wir das proc-Dateisystem und die Devices auf dem neuem System initialisieren. Das geht auch sehr einfach:

mount -t proc proc /mnt/debinst/proc
cd /mnt/debinst/dev/
MAKEDEV -v generic

4. Ubuntu Grundsystem installieren

Jetzt ins neu angelegte System chrooten. D.h. wir gaukeln den Programmen vor das das neue System das Basissystem ist – sprich virtuell wird /mnt/debinst zu /

LANG= chroot /mnt/debinst /bin/bash

Die voreingestellten Quelldateien beschränken sich auf die Basispakete. Für die volle Auswahl müssen wir die Source-Datei ändern:

vim /etc/apt/sources.list

Die Originaldatei sieht bei mir so aus:

deb http://de.archive.ubuntu.com/ubuntu intrepid main

Das ändere ich in:

deb http://de.archive.ubuntu.com/ubuntu intrepid main restricted universe multiverse
deb http://de.archive.ubuntu.com/ubuntu intrepid-security main restricted universe multiverse
deb http://de.archive.ubuntu.com/ubuntu intrepid-updates main restricted universe multiverse

Danach die Paketlisten updaten und schauen ob es evtl. Updates gibt:

apt-get update
apt-get upgrade

5. Grundsystem konfigurieren

Zuerst kümmern wir uns um das automatische Mounten der Dateisystem beim Systemstart. Das wird in der /etc/fstab getan. Hier der Inhalt meiner neuen fstab:

/dev/sda3       /       ext3    defaults,noatime                        0       1
/dev/sda1       /boot   ext2    defaults,noatime,nosuid,nodev           0       2

/dev/sda2       none    swap    sw                                      0       0
proc            /proc   proc    defaults                                0       0

Dann das nächste, das Netzwerk. Die Konfiguration wird an mehreren Stellen festgelegt.

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address <IP-Adresse>
        netmask <Netzmaske>
        broadcast <Broadcast-Adresse>
        gateway <Default-Gateway>

Zur Namensauflösung muss die /etc/resolv.conf angepasst werden. Hier einfach das gleich ‘reinschreiben was im alten System auch schon in der Datei stand.
Den Hostnamen des neuen Systems legt man in der /etc/hostname fest. Diesen da einfach ‘rein schreiben.
Die Hosts-Datei ist obligatorisch, aber sollte für den Normalbetrieb zumindest die Definition für localhost aufweisen:

127.0.0.1       localhost.localdomain   localhost

Jetzt kommen Pakete und Einstellungen zur Sprache:

apt-get install language-pack-en language-pack-de
dpkg-reconfigure locales

Um Deutsch und UTF-8 zur Voreinstellung zu machen muss folgendes in die /etc/environment hinzugrüfgt werden:

LANG="de_DE.UTF-8"
LANGUAGE="de_DE:de:en_GB:en"

Nun kommen wir zur Uhrzeit. Dazu müssen wir die Zeitzone des Servers einstellen:

dpkg-reconfigure tzdata

Und danach können wir gleich die Uhrzeit des Servers mit einem NTP-Server abgeleichen:

ntpdate ptbtime1.ptb.de

Damit wir nachher wieder zum Server verbinden können brauchen wir noch den SSH Server:

apt-get install ssh

Und das Passwort für den root-Benutzer festlegen:

passwd root

6. Kernel installieren

Vor dem Kernel muss der Bootloader installiert werden. Da ich Grub bevorzuge mache ich das manuell vorher, ansosnten würde Lilo installiert werden.

apt-get install grub

Dann der eigentliche Kernel, das geht eigentlich sehr einfach. Zuerst schauen wir uns an welche Kernel-Version wir installieren wollen:

apt-cache search linux-image

Da wir einen Server betreiben wollen bietet sich das Server-Image an. Installiert wird es mit:

apt-get install linux-image-server

Man kann auch eine feste Version benutzen, dann wird der Kernel des Servers allerdings nicht mit geupdated.
Zum Abschluss der Kernel-Installation muss noch Grub eingerichtet werden:

cp /proc/mounts /etc/mtab
grub-install /dev/sda

Das dauert einen Augenblick, nicht erschrecken.

Damit Grub auch weiss, was es später booten soll muss eine menu.lst angelegt werden. Das macht man mit:

update-grub

Die Abfrage, ob eine menu.lst generiert werden soll, mit y bestätigen.

7. Neustart

Der Moment der Wahrheit. Der Neustart des Systems.

Erst mal müssen wir aus dem chroot ‘raus. Dazu einfach

exit

eingeben.
Jetzt kann man den Server neu starten lassen:

reboot

Und hoffen das der Server online geht.
Wenn alles geklappt hat hat man ein minimales Grundsystem, auf dem man aufbauen kann und z.B. Apache, MySQL und und und installieren.

Dem kann man zum Glück etwas auf die Sprünge helfen: einfach ein Kernel-Image einer älteren Ubuntu-Version benutzen.

Die derzeit aktuelle Version gibt es hier: http://packages.ubuntu.com/hardy/linux-image-2.6.24-22-xen
Einfach (z.B. mittels wget) auf den Server laden und dann via dpkg installieren, anschliessend die /boot/grub/menu.lst anpassen. Hier mein Eintrag als Beispiel:

title           XEN Ubuntu 8.10, 2.6.24-22 (Hardy) kernel
uuid            81706b95-438e-4d18-a7ce-0b4899ab76a7
kernel          /xen-3.3.gz
module          /vmlinuz-2.6.24-22-xen root=UUID=d20b2199-7242-4de9-97f7-f97831e58232 ro quiet splash
module          /initrd.img-2.6.24-22-xen
savedefault
boot

Danach neustarten. That’s all.

Weitere Informationen und den Download gibt es auf phpMyAdmin.net

####################################################################
[+] PHP iCalendar <= 2.24 Insecure Cookie Handling Vulnerability
[+] Discovered By Stack
[+] Greetz : All my freind
####################################################################
---
exploit:
javascript:document.cookie = "phpicalendar_login=1; path=/";
javascript:document.cookie = "phpicalendar=1; path=/";

# milw0rm.com [2008-09-22]
Quelle: http://www.milw0rm.com/exploits/6526

Dieses Beispiel zeigt man wieder aufs deutlichste das man einfache Cookies nicht zur Authentifizierung benutzen sollte. Alle Scriptsprachen bieten mindestens eine Art von Session-System, mit dem man eine Nutzerauthentifizerung auf einfache Art und Weise implementieren kann und an allen Stellen wird darauf hingewiesen das Cookies unsicher sind. Um so schlimmer ist es auch noch das solche Scripte öffentlich angeboten werden. Ein Grund mehr nicht jedem Script, welches angeboten wird, zu vertrauen.

Einige der neuen Features der 1.2er Version:

• bessere Domunentation
• verbesserte Effekte
• ‘richtige’ Hash-Objekte
• Swiff Objekt zur Interaktion mit Flash
• die Möglichkeit zu jedem Element Metadaten zu speichern

Bei der Umstellung ist zu beachten, das sich an der API einiges getan hat und man somit evtl. etwas Arbeit in die Umstellung stecken muss – was sich aber meiner Meinung nach mehr als Lohnt.