Debian Etch Attansic L1 atl1 driver

stombi — Sat, 14 Jun 2008 23:57:00 +0200

Le contexte :

Distribution : Debian Etch stable
Kernel : 2.6.18
Carte mère : ASUS P5KPL
Carte réseau intégrée : Attansic L1 Gigabit

Da vendredi 13 effect :

Le driver pour le kernel 2.6.18 n'est pas inclus dans Etch, donc pas de réseau.

Solution :

Récupérer le driver et le copier sur une clé usb ( wget ftp://hogchain.net/pub/linux/attansic/vendor_driver/l1-linux-v1.2.40.2.tar.gz )
Installer Etch sans réseau (choisir aucune carte réseau)
Brancher la clé usb et copier le driver sur la Etch
Compiler le driver sur la Etch

Pré requis :


 # apt-get install fakeroot kernel-package kernel-image-2.6-686 linux-source-2.6.18 linux-headers-’uname -r’ module-init-tools

Récupérer le driver :

 # mount /dev/sda1 /mnt
 # cd /mnt
 # cp l1-linux-v1.2.40.2.tar.gz /usr/src/
 # cd /usr/src/
 # tar vzxf l1-linux-v1.2.40.2.tar.gz
 # cd l1-linux-v1.2.40.2/src/

Compiler et installer le driver :

 # make install
 # insmod /lib/modules/2.6.18-6-686/kernel/drivers/net/atl1/atl1.ko
 # depmod -a
 # modprobe atl1
 # echo atl1 >> /etc/modules

Reste plus qu'a éditer /etc/network/interfaces et /etc/resolv.conf et le tour et joué.

PS : j'ai mis le module compilé pour 2.6.18-6-686 ( atl1.ko ) en pièce jointe à ce billet.

Sources :

Apache2 multiple SSL Virtual Hosts

stombi — Thu, 14 Jul 2005 12:52:00 +0000

Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?

Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the problem is that the SSL session is a separate transaction that takes place before the HTTP session even starts. Therefore all the server receives is an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds that matches the port and IP address.

You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then you can have no more than 1 SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

NameVirtualHost 192.168.1.1:80

Other workaround solutions are:

Use separate IP addresses for different SSL hosts. Use different port numbers for different SSL hosts.

Specifically, you cannot have multiple secure virtual hosts on the same SOCKET (IP address + port). By default, a secure host will use port 443. You can change configure your virtual host to use a different port number with the same IP, thus creating another socket. There are many disadvantages to this approach. The most obvious disadvantage is that if you are not using the default port, your URL must also contain the port number to access the secure site.

Example:

Site using default port - www.something.com - would be accessed as https://www.something.com

A site using port 8888 would be accessed as https://www.something.com:8888

Another disadvantage is that if you introduce more ports, you will be providing more opportunities for port sniffing hackers. Last, if you select a port that is used by something else, you will create conflict problem.

Stombi Home Page - Serveur

Debian Etch Attansic L1 atl1 driver

Apache2 multiple SSL Virtual Hosts