Do prac biurowych komputer sprawdza się wyśmienicie, a po rozszerzeniu RAMu do 2 GB sporo zyskał, jak się okazało 1 GB to za mało na zestaw KDE + KMail z kilkoma kontami IMAP + Akregator z kilkudziesięcioma źródłami RSS + Iceweasel. W zasadzie mógłbym na nim jeszcze pracować , a nawet pograć w  takie gry jak Enemy Territory, czy (ostatnio) mniej wymagające jak Einstein Puzzle, Xmoto czy OpenTTD. Jednak od paru miesięcy jest chętny na tego laptopa, pora więc było coś poszukać.

U jednego z klientów zobaczyłem X300, którym się zachwyciłem. Bardzo lekki (1.44 kg), przyjemny w obsłudze i przede wszystkim ciągle mający to coś z ThinkPadów. W końcu decyzja zapadła, wspólnik wyraził zgodę i w drugiej połowie marca dokonałem zakupu. Dysk SSD 64 GB może nie poraża pojemnością, ale z drugiej strony w T42  mam 60 GB i nie odczuwałem braku miejsca. Co jeszcze ciekawego - karta graficzna na chipsecie intel 965, a więc przyjdzie czas na zabawę z kernel mode-setting.

Ale to później.

Póki co pozwoliłem sobie na pewien eksperyment. Przez dwa tygodnie będę korzystał w możliwie największym stopniu z preinstalowanego systemu, czyli Visty. Tak więc, nie Thunderbird, a Windows Mail (następca Outlook Express), nie Firefox a Internet Explorer (tak, prawdopodobnie jestem głupi). Jedyne na co sobie pozwolę to Putty. Jeśli więc w ciągu najbliższych tygodni nie pojawi się z mojej strony żaden commit w PLD, oznacząć to będzie tylko jedno: Umarł Vi, niech żyje Visual Studio  

PS: Seems like I’ll switch to Polish on this site.

Openvpn’s ethernet bridging howto comes with simple setup scripts that you can use to bridge internal interface (e.g. eth0) with virtual one (e.g. tap0). Since standard system tools in PLD do not let you create tap interfaces, you have to care about creating one on your own. Hopefully you can use openvpn’s –mktun command line switch or handy little tool called tunctl to create one.

This has one drawback — you can’t easily use it with standard PLD interface config files (/etc/sysconfig/interfaces/ifcfg-foo). Of course you could set up the interface from rc.local, but things are getting more complicated if you are using vserver on the same machine that is supposed to act as a openvpn server.

The problem is – after you start your vserver guest systems, they have their virtual networking set up and bound to ethX (or whatever device you set them up to). If you’d try to set bridge at this time, you’d run into trouble. Not only this could cause problems with services on host system, but what’s worse – your vserver guest systems would loose network connectivity.

You could try to write your own init script and run it somewhere between networking and vserver. Slightly better, but still not perfect. Luckily, there’s a better approach.

Obiously the scenario I described above only matters if one of your vservers uses ethernet card that you plan to be a part of bridge interface. In case of ethernet bridging, this means at least one of your vserver (as it was in my case) vservers provides service to LAN.

Ethernet bridging with OpenVPN on vserver-enabled host – PLD way

In my configuration, I needed to connect two networks over Internet. I need to bridge them becase of various proprietary stuff that cannot be reconfigured. For the sake of this howto, we will name the gw machines in both locations hq and branch, each of them having two NICs, eth0 (external – internet), and eth1 (internal — lan).

hq eth0: <irrelevant>
hq eth1: 10.0.0.1/8

branch office eth0: <irrelevant>
branch office eth1: 10.0.10.1/8

There are also a few other ip addresses assigned on both hq’s interfaces — these are used by vserver guest systems.

Before we begin, make sure you have all necessary tools:
# poldek -Qiv  bridge-utils openvpn easy-rsa umlinux-tools

What we need is to prepare /etc/sysconfig/interfaces/ifcfg-br0 with slightly modified content:

# ifcfg-br0
TAP=$(tunctl -b -t tap0)
DEVICE=br0
IPADDR1=10.0.0.1/8
ONBOOT=yes
BRIDGE_DEVS="eth1 $TAP"
SPANNING_TREE=no
# eof

Alternatively you could use openvpn binary to set up tap device: „openvpn –mktun –dev tap0″ – it’s up to you. Note that if you choose to use openvpn binary, you will need to

What’s next

Once it is done, you can follow the official ethernet bridging howto – just skip the bridge-start / bridge-stop scripts. Here’s a sample configuration for hq machine (openvpn server):

# hq's openvpn config
local 1.2.3.4 # hq public ip address
port 1194
proto tcp
dev tap0
ca /etc/easy-rsa/keys/ca.crt
cert /etc/easy-rsa/keys/hq.crt
key /etc/easy-rsa/keys/hq.key  # This file should be kept secret
dh /etc/easy-rsa/keys/dh1024.pem
server-bridge 10.0.0.1 255.0.0.0 10.0.10.3 10.0.10.100
push "route 10.0.0.0 255.0.0.0"
ifconfig-pool-persist /etc/openvpn/ipp-hq.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-hq-status.log
log /var/log/openvpn-hq-log
verb 5
# eof

You will also need to reconfigure vserver to bind to bridge interface (e.g. br0) — just edit /etc/vservers/$vserver/interface/$num/dev file.

Few months ago (before I saw this, honestly!) dad and I agreed that having a family file server was a good idea. What conviced us what the mess we were having with family photos – some of them were on my father’s computer, some on mine. We also wanted to get rid of duplicate data (apps, few isos, etc.) between our computers.  What was surprising to me, my mom was also enthusiastic about the idea. Before we stared, we decided that our server has to:

• be quiet (preferably fanless),
• be economic / ecologic (small power consumption),
• have a lot of space (in RAID-1 setup, if possible),
• cost no more than 1000 PLN (ca 300 €),

After doing some research, I decided to buy one of VIA’s EPIA motherboards – which are small (mini-itx), fanless (!), and consume relatively low power (ca. 15 W) comparing to their full-size competitors. From my rough calculations whole system would consume no more that 30-40W of energy, beside the already mentioned motherboard (with integrated CPU, NIC and VGA), there would be a 1TB SATA disk. With 40W of power conspution, estimated cost of running it 24/7 was:

24 (hours) * 30 (days) * 0.04 kW (power consumption) * 0.3 PLN (estimated price of 1kWh of energy) ~= 10 PLN

As low as 10 PLN (about 3 €) a month. Boy I wish I could pay that „much” on a gas station …

It took about three weeks before I bought all the required parts:

• EPIA SP-8000EG FANLESS motherboard,
• a D-153 chasis (designed for VIA’s EPIA motherboards),
• 1TB Samsung HD103UJ SATA HDD,
• 1GB DDR RAM,

Total cost: 1003 PLN (incl. VAT), which is about 300 €. Once assembled it looks like this:

Maybe it’s not beautiful, but it doesn’t have to be.
Now to the more technical part, it is powered by PLD Th:

[root@epiath ~]# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 800.047
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse up rng rng_en ace ace_en
bogomips : 1602.68
clflush size : 32[root@epiath ~]#

And it was so quiet…  image a system where the most nosiest component is its hdd (about 27dB). Unfortunately, it failed as a fanless system, the hdd warmed up to more than 45°C. We decided to insert small, 8x8cm fan inside the chasis. It helped a lot – the hdd temperature dropped almost isntantly to less than 35°C, and as I am writing thist post, hddtemp reports 28°C. At the price of lower temperature, we got a bit louder system and a slightly higher power consumption.

Epiath (I probably suck at naming my systems) is a new project – it went „live” about three weeks ago, and is still not finished, there are few thins I still plan to do:

• remote access (OpenVPN), so that my brother could share his photos as well,
• track new files (with find), and announce them with mail sent on a daily basis,
• develop a search engine – search throuch file names at a minimum, perhaps we could make use of beagle to scan through contents as well (any experience with that anyone?),
• NFS access – or is it more convenient to use SMB, even for a Linux user?

So far, I am quite happy we decided to build our home server – even though it did cost a bit (you don’t spend 300 € everyday, do you?).

They are, but nevertheless for some reasons – like saving few watts of energy, or just for pure fun – one may want to create a diskless workstation.

One of our customers (who deserves a separate entry) runs a medium sized grocery shop. Recently we had to replace one of the computers that for that last few years served as terminal at the cash desk. We decided to put a diskless workstation there – after all, if server goes down, we are in big trouble anyway, and a workstation that can’t boot would be the least of our problems.

Not being an experienced PXE user, I decided to write a small tutorial for those who would like to play a bit with diskless systems. I will provide you with a short howto that shows how to successfully boot PLD on a diskless computer.

In this part we will learn to boot PLD RescueCD. This has been previously described by jajcus and used by areq as a semi-official RescueCD-PXE howto (polish). I assume you have two computers – a server and a diskless client, and you know MAC address of the latter.

First we need ot install few packages:

# poldek -Qiv dhcp rlinetd tftpd-hpa syslinux

where dhcp is a DHCP server (in case you don’t have one yet), tftpd-hpa being a TFTP server and syslinux provides us with pxelinux.0 file (more on this later). If you already have an inet daemon, you may skip rlinetd. If not, you may install it, or some other inetd implementation, like xinetd.

Than we need to obtain PLD RescueCD, I downloaded 2.95 which was the most recent version as of this writing. Once you have it, either burn it and mount the cd, or just mount the iso and copy files we need :

# mkdir /mnt/iso
# mount -o loop RCDx86 _295.iso /mnt/iso
# cp /mnt/iso/rescue.cpi /var/lib/tftp
# cp /mnt/iso/boot/isolinux/vmlinuz /var/lib/tftp/rescue.vmlinuz
# chmod 644 /var/lib/tftp/rescue.{cpi,vmlinuz}
# umount /mnt/iso

Where vmlinuz is a kernel image, and rescue.cpi – an initrd – in case of RescueCD it’s more than that, but that’s ok.

From the syslinux package, we need pxelinux.0, which we also place in /var/lib/tftp:

# cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftp

I believe pxelinux.0 can be best described as the network bootloader. It reads configuration from a specified TFTP server and behaves as told to. Both LILO and GRUB (or SILO in case of SPARC) need a config file to run properly. That’s no different in our case.

By default, PXELINUX looks up for several config files under the ${tftpdir}/pxelinux.cfg dir (where $tftpdir is /var/lib/tftp by default), starting from file named after the NIC GUID (shown on startup), going through file named as MAC address, through IP based configs till the file named ‘default’ and stops once it finds one. This lets you to be as flexible as you want to be – you may want to provide separate files for each workstation you have, or have one file for them all. In this tutotrial, we will try to keep things simple, and will refer to the default file.

# mkdir /var/lib/tftp/pxelinux.cfg
# touch/var/lib/tftp/pxelinux.cfg/default

Syntax of pxelinux config file is pretty simple and easy to understand, let me provide you with a complete setup:

# cat /var/lib/tftp/pxelinux.cfg/default
default rescuecd
label rescuecd
kernel rescue.vmlinuz
append initrd=rescue.cpi root=/dev/ram0
#

If I were to write it for GRUB, it would more or less like this:

# cat grub.test
default 0
title rescuecd
kernel /vmlinuz root=/dev/ram0
initrd  /rescue.cpi
#

Great! Our TFTP server is now set up. What’s left is to tell DHCP how to use all these goodies. I assume you have DHCP configured (or know how to do it), if not, please refer to e.g. official PLD documentation (polish).  What you need to add is a group section that may look like this:

# grep -A 20 group /etc/dhcpd.conf

group {

next-server 192.168.1.2;
filename „pxelinux.0″;
host comp {

hardware ethernet 00:12:34:56:78:90;
fixed-address 192.168.1.3;

}

}

#

This should be pretty much self-explanatory, but to make things clear, next-server tells a client IP address of the server that stores a file we should load and boot. As one may assume filename tells dhcpd which file to load through TFTP. host {} declares a static entry for a given machine – you may want to have a fixed IP address for it – so that you can remotly log in.

Once you are done, you should restart the services:

# service dhcp restart
# service rc-inetd restart

After that you should be able to sucessfully boot form the diskless workstation. In the next part we will learn how to boot PLD ac on a diskless workstation.

Have fun.

Packages for th-i686 are available, just add the following lines to your poldek configuration:

[source]

type = pndir

name = th-xen

path = http://carme.pld-linux.org/~adamg/kxen/

You may also want to build these packages in your own environment –  in that case have a look at kernel-xen.spec and xen.spec files.

[pl] Osoby korzystające z technologii Xen™ może zaciekawić informacja o pojawieniu się zestawu pakietów RPM (kernel + userspace) Xen™ 3.2.0-rc4-pre (z gałęzi xen-unstable repozytorium Mercurial). Na chwilę obecną udało mi się ponieść system dom0, uruchomić xend, natomiast z uruchomieniem systemu domU są pewne problemy (komunikt dotyczący hotpluga) – pomoc mile widziana.

Przygotowałem zestaw pakietów dla architektury th-i686, odpowiedni wpis dla poldka:

[source]

type = pndir

name = th-xen

path = http://carme.pld-linux.org/~adamg/kxen/

Możliwe jest także samodzielne zbudowanie pakietów – w takim przypadku warto zainteresować się plikami kernel-xen.spec oraz xen.spec.

Xen proved to be quite stable for me, I am quite satisfied it finally went to the ac – I won’t have to remember about rebuildoing packages (I also use drbd-0.7 and drbd-8.x) after each kernel update.

[pl] O ile hawk lub glen nie zmienią zdania, pakiety RPM z kernel-xen0 oraz kernel-xenU wkrótce powinny pojawić się jako część aktualizacji dla PLD AC (ac-updates). Pakiety te znajdują się obecnie w ac-ready, i jeśli się nie mylę, jedyne co zostało do zro bienia to przygotowanie paczek okołokernelowych dla xenU (te dla xen0 wydają się być gotowe). Ohh, i jeszcze pozostało zbudowanie userspace.

Xen™ okazał się dla mnie całkiem stabilnym rozwiązaniem, jestem zadowolony że w końcu trafił do Ac – nie będę musiał pamiętać o budowie pakietów (korzystam także z drbd-0.7 oraz drbd-8.x) po każdej aktualizacji kernela.

Big thanks to  baggins for  an account on students. The monster  machine he has there helped me a lot in preparing both Xen and OpenOffice.org packages.

[pl] Właśnie wrzuciłem paczki z kernel-xen0/xenU  w wersji 2.6.16.53-2. Wydanie to poprawia CVE-2007-4573 – dziurę umożliwiającą lokalnym użytkownikom zdobycie uprawnień administratora. Paczki RPM dla ac-i686 i ac-amd64 są dostepne tam gdzie zawsze - http://students.mimuw.edu.pl/~adamg/xen/ .

Podziękowania dla baginsa za konto na  students.  Potężna maszyna, jaką tam ma była bardzo pomocna podczas przygotowynia paczek Xen oraz OpenOffice.org.