The server was a:
CPU Intel Xeon X3430
RAM 4GB
HD 4x500GB

During the installation, on each of the 4 disks, I created:
- a small /boot partition (~300Mb)
- 10 Gb RAID1 for /
- 1 Gb RAID10 for swap
- remaining space as RAID10, with a big LVM volume on top of it.

Please note: at the end of the installation, you should manually install grub on every disk, because if the first disk get destroyed, you cannot boot your system.

mkdir /boot2 /boot3 /boot4
mount /dev/sdb1 /boot2
mount /dev/sdc1 /boot3
mount /dev/sdd1 /boot4
rsync -av /boot/ /boot2/
rsync -av /boot/ /boot3/
rsync -av /boot/ /boot4/
umount /boot2/ /boot3/ /boot4/
dd if=/dev/sda of=/dev/sdb count=1 bs=512
dd if=/dev/sda of=/dev/sdc count=1 bs=512
dd if=/dev/sda of=/dev/sdd count=1 bs=512

At this point, installing kvm plus virt-manager is straightway:

aptitude install kvm libvirt-bin virt-manager

Remember that Lenny is getting pretty old, so for getting more from your server, you should use the backports.org packages.

Now add your user to the libvirt and kvm system groups (/etc/groups):

[..]
kvm:x:112:bob
libvirt:x:115:bob
[..]

At this point, you should connect to virt-manager GUI. As far as I understood, virt-manager support connections from remote hosts, but the TLS configuration is not so well documented, so you can simply do X11 forwarding or install a VNC server, or NX server, on the host to get the local virt-manager.

What I usually do on my lan from my laptop is:

ssh -X -l myuser myserver.local
virt-manager

And the virt-manager window will popup.

LVM Configuration
Edit->Host Details->Storage
Add your LVM Volume Group defined during the first setup: from this window, you can create virtual disks for your machines.
Using LVM instead of simple disk images give great benefits: less overhead, and the ability to expands images (and filesystems on it) without even rebooting the VM.

Network Configuration
You can use both bridged networks and private networks. Bridged networks are used when a VM should have the same subnet address of the other hosts on the local networks.

Bridged networks requires additional configuration on the host to work:

cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#auto eth0
#allow-hotplug eth0
#iface eth0 inet static
#        address 192.168.0.4
#         netmask 255.255.255.0
#         gateway 192.168.0.1

auto br0
allow-hotplug br0
iface br0 inet static
         address 192.168.0.4
         netmask 255.255.255.0
         gateway 192.168.0.1
         bridge_ports eth0
         bridge_stp off
         bridge_maxwait 15

Private networks should be use to isolate the virtual machine from the physical networks. You can create a DMZ using strict iptables rules for allowing clients to reach VM inside a private network. You can take a look on the iptables scripts I am using on the host, that use both bridged and private networks.

cat firewall.sh
#! /bin/bash
# By Giovanni Toraldo

LAN='br0'
VLAN='virbr0'
SUBNET='192.168.0.0/24'
VSUBNET='192.168.122.0/24'

## FLUSH
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

## Default Policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Basic Routing/Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -i lo -j ACCEPT

## Local Inbound Services
iptables -A INPUT -p tcp --dport 22 -j ACCEPT # ssh
iptables -A INPUT -p tcp --dport 25 -j ACCEPT # mail
iptables -A INPUT -p udp --dport 123 -j ACCEPT # ntp
iptables -A INPUT -p tcp --dport 80 -s $SUBNET -j ACCEPT # nginx

# VLAN - I accept and route all traffic
iptables -A INPUT -i $VLAN -j ACCEPT
iptables -A INPUT -i $LAN -j ACCEPT
iptables -A FORWARD -i $VLAN -j ACCEPT
iptables -A FORWARD -i $LAN -o $VLAN -j ACCEPT
# Masquerading packets from private networks only!!
iptables -t nat -A POSTROUTING -s $VSUBNET -o $LAN -j MASQUERADE

Purtroppo dispositivi del genere (ma anche router/modem/acess-point), nonostante siano dei bei pezzi d’hardware, nonostante siano basati su software GNU/Linux, nonostante sulla carta abbiano tantissime feature (SMB, NFS, FTP, UPNP, DAAP, Torrent), spesso si scopre che il software è una mezza ciofeca.

Perchè? Non lo so, non conosco nessuno che lavora in questo campo, ma mi piacerebbe approfondire. Il male più grosso, da quel che riesco a capire, è che i produttori usano sଠsoftware libero, ma sembra che siano totalmente incapaci a gestirlo: ogni nuovo dispositivo che sfornano, spesso significa un nuovo linux embedded ricostruito da zero (from scratch).

Il risultato? Passano l’80% del loro tempo a risolvere problemi che il resto del mondo ha affrontato una volta sola: ti ritrovi a combattere con l’interfaccia web che scombina la configurazione di samba e non funziona più, niente da fare per agganciare NFS su mac, ventole che girano a palla nonostante temperature sotto quella ambientale e infine, ciliegina sulla torna, non c’è versi di avere un cacchio di accesso shell per capire cosa diamine stia succedendo.

E questo è quello in cui sono incappato in un solo fine settimana di utilizzo approfondito.

Che fare? Opensource non è solo ‘software aggratis’, opensource è comunità , competenze e testardaggine. Questo dns323 wiki è un ottimo punto di partenza. Per i primi passi da muovere, consiglio questa paginetta Installare Telnet/Fun_Plug.

Quello che avrete (e che ho io in questo momento) è accesso ssh e un chroot con una serie di pacchetti di base pronti all’uso e altri già  installati.
Il prossimo passo per me è agganciare direttamente una bel chroot Debian ARM =D

La scelta è ricaduta su un MacBook Pro da 15 pollici con processore 2.66GHz (che ho preso da Essedi scontato di 200 euro).

00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1) 00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1) 00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b3) 00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1) 00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1) 00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1) 00:03.4 RAM memory: nVidia Corporation Device 0a98 (rev b1) 00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1) 00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1) 00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1) 00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1) 00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1) 00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1) 00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1) 00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1) 00:0b.0 IDE interface: nVidia Corporation MCP79 SATA Controller (rev b1) 00:0c.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1) 00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1) 00:16.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1) 00:17.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1) 02:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1) 04:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01) 05:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Express1394b Controller (PHY/Link) (rev 07)

Praticamente tutto fatto da nvidia =P

Con una Lenny amd64 il grosso funziona, manca solo il wireless che non è supportato dal modulo bcm43xx opensource ma tocca usare il driver AP WL STA proprietario (aptitude install broadcom-sta-source && module-assistant a-i broadcom-sta && modprobe wl), e l’audio, nonostante venga rilevata correttamente la scheda audio e i controlli paiono esserci tutti, non son riuscito a far funzionare nè gli speaker interni nè il jack delle cuffie [bug report]

Per il controllo delle ventole (fornito dal modulo applesmc di Linux) ho trovato uno script carino:
setfan.sh
(l’autore originale non me ne vorrà , ma non ricordo proprio da dove l’ho pescato)

Non dimenticate di installare pommed per la gestione dei tasti funzione (luminosità  e retroilluminazione dei tasti).

Once installed, any file you drop into your Dropbox folder will synchronize and be available on any other computer you’ve installed Dropbox on, as well as from the web. Also, any changes you make to files in your Dropbox will sync to your other computers, instantly.

NB: this is not FREE software. Dropbox give you a free client (GPL2), but you should use their server for hosting your files. They also give a free 2 Gb account (others plan here).

Unfortunately, only .deb for ubuntu were available. I made you a package for Debian Lenny.

And, of course, the .deb package is hosted on Dropbox =P
http://files.getdropbox.com/u/630394/nautilus-dropbox_0.6.1_i386.deb

Additional link: how to setup a command line client for dropbox

The prerequisites are:
- the file named system_image.gz that is on the Recovery CD.
- a live linux system (knoppix? SysRescueCD? I’ve used my debian on nfs.)
- basic knowledge of a partition tool editor (like cfdisk).

system_image.gz is the compressed image of the root system. Copy it on a usb pen, samba share, public_html, where you want!
Start the eee-box with the live system of your choice, and unpack the compressed root on the internal drive of EEE-Box with:

zcat system_image.gz > /dev/sdb
(nb: my debian recognized the harddisk as sdb, on other live system can be sda, check the dmesg for being sure)

Now we need to add a second ext3 partition that will be used as /home directory with cfdisk: remember to create it as Primary Partition, so it will be called sdb2.
After, create a swap partition in a Extended Partition, so it will be named sdb5.

Format the newly crated partition with:
mkfs.ext3 /dev/sdb2 mkswap /dev/sdb5

Reboot, and you are ready to use a brand new Asus Xandros.

We will use a great tool for manage our git repositories: gitosis.

aptitude install gitosis sudo -H -u gitosis gitosis-init < SSH_KEY.pub
where ssh_key.pub is a file that contains a public rsa key generated with ssh-keygen (as default is saved on ~/.ssh/id_rsa.pub).
The key is used to authenticate the repositories admin, so can even be on another host with ssh access.

Now on your local machine (even different where gitosis was installed, but you need the private rsa key on it):
git clone gitosis@YOUR_SERVER_IP:gitosis-admin.git
This repository contains configuration data for gitosis, you will modify it, commit and push, and gitosis automatically reload itself.

Modify gitosis.conf:
[gitosis] [group gitosis-admin] writable = gitosis-admin members = scorp@antani [group developers] writable = sandbox members = scorp@antani

The group gitosis-admin is the one that can manage the gitosis configuration (we are doing it now).
The group developers i've added it's the one with all developers will use to access our repositories. You can even create many different groups for many different repositories.
Sandbox is the name of a testing git repository i am going to create (not exists yet, i've only specified that the user scorp@antani can push commits into).

To render effetive changes, do:
git commit -a -m "Allow scorp write access to sandbox" git push

Now let's try the new toy, we should initialize the sandbox repository:
mkdir sandbox cd sandbox git init git remote add origin gitosis@YOUR_SERVER_IP:sandbox.git touch helloworld.txt git add helloworld.txt git commit -m 'first test commit' git push origin master:refs/heads/master

Happy now? Good Coding.

Common errors

~/sandbox$ git push origin master:refs/heads/master No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as 'master'. fatal: The remote end hung up unexpectedly error: failed to push some refs to 'gitosis@192.168.1.1:sandbox.git'

You should remember to commit changes before to push it ;)

References: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

The first thing to do, is to configure the variable mynetworks to allow only certain netblocks to use postfix to send email all over the world:
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 X.X.X.X/XX
Look out: the ips should be in CIDR notation, so you probably need to apt-get install ipcalc.

Using ipcalc is straight-forward. For example, think our servers are located on the netblock from 188.57.33.80 to 188.57.33.87:
$ ipcalc 188.57.33.80 - 188.57.33.87 deaggregate 188.57.33.80 - 188.57.33.87 188.57.33.80/29
Here it is.

Next level is to configure smtp login, if you don’t have a subnet for your clients.
aptitude install sasl2-bin libsasl2-modules libsasl2-2
Now enable daemon and configure it for being accessed by postfix, editing /etc/default/saslauthd:
START=yes OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Now tell to postfix to use saslauth in /etc/postfix/sasl/smtpd.conf:
pwcheck_method: saslauthd mech_list: PLAIN LOGIN

And enable it in /etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

In case of:

postfix/smtpd[638]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied

Hint: add postfix to sasl group:
$ adduser postfix sasl

No real new features in this release. But some of the fixed bugs were nasty:

* Possible crashes in the IDE property sheet and while saving forms.
* Crash in the debugger when selecting the “Collection” identifier.
* Automatic completion now works correctly on lines having non-ASCII characters.
* Dir() and RDir() now work correctly on relative paths.
* Enumerating something inside a _next() enumerator method now is safe.
* SUPER now works inside overriden static methods.
* Fix string and blob quoting in the PostgreSQL component.
* Sockets will not take 100% CPU anymore.
* Startup forms hidden at design time are not shown automatically anymore.
* The XSLT component works again.
* A lot of fixes in the GTK+ component too.
* …

Read the ChangeLog to see all of thems.

Gambas 2.10 i386 deb

Istruction for the installation:
aptitude remove ~ngambas dpkg -i gambas2_2.10.0-1_i386.deb

For gaining performances, I compiled the kernel with the Core 2/Newer Xeon as Processor Family, removed every generic optimization, compiled statically some driver and change the IO scheduler to no-op (fifo is the best on flash based memory, because they haven’t any seek time).

I am attaching here the config, the kernel image, the headers required to compile other modules and the madwifi module that I use for the wireless card.

linux-image 2.6.28-eeegt-1
linux-headers 2.6.28-eeegt-1
madwifi-modules 2.6.28-eeegt-1
.config 2.6.28 900a

With the recent kernel, there is no need to use the madwifi driver, the ath5k module works great. I also reintroduced the right atl1e for the ethernet device and the atl2 module necessary for the other eeepc model.

linux-image 2.6.28-eeegt-3
linux-headers 2.6.28-eeegt-3
.config 2.6.28 eeepc 900a/901

• Dependant packages
• Recommended packages
• Suggested packages

The first are packages strictly needed for an application to work correctly (eg: for amsn, the tls library needed to login). The recommended packages are not needed, but they usually add features to the main application (eg: for gimp, the gimp-gnomevfs used to drag and drop files from nautilus). Finally, the suggested packages that’s not add feature to the main package but that are in somehow manner related to the main package.

As default, apt-get/aptitude always install recommends packages, and this is a great thing for who is using a desktop, or don’t want to spend time selecting the right packages but want that everything works as best it can.

Unfortunately, this is not a right choice when we are configuring a server system or an embedded system.

So, the first thing to do, when you gain the shell on a fresh installation, is to instruct apt to install only needed dependencies.

Insert in /etc/apt/apt.conf these two lines:

APT::Install-Recommends "false"; APT::Install-Suggests "false";