Gigabyte brix som server

Det är dags att byta ut min gamla server - bättre att byta innan den kraschar än att behöva göra det i panik.  Och dessutom vågar jag inte byta från Debian oldstable till stable rakt av, rör inte det system som fungerar!

Så det blir en gigabyte brix efter lite övervägande. För att den är liten och strömsnål och tillräckligt kraftfull ändå. Håller på att installera debian wheezy (nuvarande stable) för tillfället - det får bli ett separat inlägg.
UPPDATERING: se längst ner i detta inlägg!

Första intrycket

• bios är riktigt uselt. trots att det är ett efibios känns det som en relik från 90-talet, förutom att man på den tiden fick en pappersmanual värd namnet. att avkryptera förkortningarna i menyerna är inte särskilt skoj.
• enheten är riktigt riktigt liten, sval och tyst.
• att starta om/stänga av med knappen är lite slumpmässigt - man har ingen aning om vad som händer. tur att servern inte ska startas om så ofta...

Uppdatering: Efter trassel med grafiken på Debian stable körde jag Ubuntu ett tag. Sedan försökte jag att uppdatera Debian stable till testing, men det funkade inte. Efter en total ominstallation med första installerversionen av Jessie kan jag däremot säga att det funkar utmärkt!

Bandwidth limit ssh

For all you who are interested in rate limiting ssh, to not consume too much bandwidth, here is a suggestion:

Use trickle! (apt-get install trickle for debian/ubuntu users)

instead of

ssh you@example.com

you use

trickle -u 123 -d 456 ssh you@example.com

where u is the upload limit in kbytes/s and d is the download limit in kbytes/s.

Very handy. I use it to rate limit file synchronization with unison. I have a ssh.sh script with

#!/bin/sh
trickle -u 20 -d 40 ssh "$@"

in it, and sshcmd=/path/to/ssh.sh in my unison profile.

Good luck!

btrfs som rotfilsystem på Debian Wheezy

Nu har turen kommit till att använda btrfs som rotfilsystem på en Debian Wheezy-installation. Efter att installationen blivit klar efter en evighet (läs förra inlägget, om prestandaproblem med fsync) stannade booten på att fsck fallerade. Detta är något missvisande och verkar ha att göra med att "reparation/kontroll-verktyget" för btrfs inte är klart. I väntan på att det är klart returnerar det att allt är ok, om jag förstått saken rätt.
Workaround: ta bort filsystemkontrollen från fstab, dvs ändra sista kolumnen till noll för btrfsvolymerna. Detaljer finns här.

Nu håller jag på att sätta upp subvolymer och snapshots, så att jag får lite ordning och reda. Time machine-funktionalitet på filsystemnivå är en helt annan femma än rsync+hårdlänkar som "alla" använder för backup!

experiment med btrfs

Nu har jag använt btrfs på en partition för backup - funkar perfekt. Det jag framförallt vill åt är checksummekontrollen, dvs att man vet att data är korrekta.

Glad över hur lätt det var att komma igång med btrfs satte jag igång en nyinstallation av debian, med btrfs lagt ovanpå en krypterad partition. Vilken pina! Det visar sig att btrfs i sin nuvarande version är riktigt kass när det gäller fsync(), vilket installationsprogrammet för Debian gör väldigt, väldigt ofta. (Läs mer här, debian bugg #635993). Det verkar tack och lov finnas workarounds när man väl installerat systemet, men just nu har jag tröttnat på att höra hårddisken knattra sedan två timmar för något som brukar gå på under en halvtimme.

Rate limit a pipe

Something I often do while developing is replaying recorded network traffic.
Something along

$nc host port

to send data in the traffic.bin to host, via tcp. This will however dump the data as fast as possible, which makes it difficult to keep up with the data pace at the other end (which I try to study/debug).
A solution is to use pipe viewer which can do many things, one of them to rate limit data.
Running

$pv -L 100

gives 100 bytes per second rate. pipe viewer is installed by

$apt-get install pv

on Debian. I was just about to write a tool like this, but searched for an existing solution instead!

Mailserver i egen regi

Något jag länge funderat på är nu klart - jag kör min egen mailserver. Jag har haft två epostleverantörer - en för inkommande och en för utgående.
Den inkommande spamfiltrerade så hårt att fullt legitima mail inte kom igenom. En oförstående support gjorde inte saken bättre.
Den utgående mailleverantören hade även annan verksamhet på sina servrar som skickade spam, till den grad att servern klassades som skräpserver och blev blockerad av andra mailservrar.
Därtill var imapservern väldigt seg, och kontostorleken var för liten.
Det som fick mig att till slut få tummen ur var dock att avtalet skulle löpa ut.

Varför valde jag att köra eposten själv och inte ta en extern leverantör?

• jag vill inte råka ut för för hård spamfiltrering som tar bort legitima mail
• jag vill inte riskera att klassifiseras som en dålig server pga. andra användare
• jag vill ha så stora mailboxar jag själv känner för
• jag vill inte att min mail passerar sveriges gränser i onödan
• jag vill kunna backupa mailen i mitt normala backupsystem
• det är skoj att kunna!

Jag försökte hitta en leverantör som kunde erbjuda ett par imap-konton med rimlig storlek (>=500 MB) och inget annat. Det var svårt! Det närmaste jag kom skulle kosta över 100 kr i månaden. För den pengen kan jag lägga ner ganska mycket tid själv för att räkna hem det på lång tid. Och epost är långsiktig.

Nu kör jag postfix (för smtp) och dovecot (för imap) bakom NAT och dynamisk DNS och det fungerar mycket väl. Detta på en mycket klen server.
Det var inte helt lätt att förstå konfigurationen av postfix - det är mycket som kan konfigureras i en mailserver. Att få igång postfix med ett enstaka konto är inte särskilt svårt, däremot flera domäner, virtuella mailboxar, autentisering utan pam, kryptering, förhindra open relay, spf-verifiering och greylisting tog lite tid. Dovecot gick fortare att konfigurera - det mesta är klart från start. Den medföljande konfigurationsfilen på över 1000 rader förklarar det mesta.

Jag följde dokumentationen på postfix hemsida, samt diverse howtos. Här finns ett exempel på en howto som ger en god översikt.

I huvudsak går det ut på följande. Om man gör det i ordning så är det inte skarpt förrän sista punkten, när DNS-en ändras (MX-recorden). Här är arbetsgången i huvudsak. För mig tog det ca 30 timmar att få det att fungera, men då visste jag i princip ingenting om smtp, postfix eller dovecot.

• konfigurera DNS så att din server kan nås via namn
• sätt upp filstruktur för virtuella mailboxar
• skapa lösenordsdatabas för eposten
• konfigurera dovecot så att den når dina mailboxar och autentiserar mot lösenordsdatabasen
• konfigurera dovecot till att använda kryptering (TLS/SSL)
• konfigurera postfix så att den kan skicka mail ut
• konfigurera postfix så att den inte är en open relay
• konfigurera postfix till att autentisera genom dovecot
• konfigurera postfix till att levera mail till dina mailboxar
• konfigurera postfix med alla dina maildomäner, vidarebefodringar och alias
• konfigurera postfix till att använda kryptering (TLS)
• vidarebefodra portar smtp 25 och 587 i din router
• vidarebefodra port 993 i din router för dovecot
• peka om MX-recorden för din domän (det är nu extern epost faktiskt dirigeras in till servern, till dess kan du härja runt fritt för att prova att det fungerar!)
• lägg till greylisting och spf till postfix
• ordna backup av mailboxarna

Det som återstår att göra är att fixa självsignerade certifikat så att jag slipper bekräfta varningarna i mitt epostprogram. Samt möjligtvis spam-filtrering...
Och kanske webmail, men det är en annan historia.

Nu så här en vecka efter att allt gått i drift måste jag säga att det fungerar riktigt bra. Responstiden är makalöst kort - precis som det ska vara.

Jag använder Debian, en helt fantastisk linuxdistribution. Tack, alla debianutvecklare och ni som skrivit alla program jag använder!

Konvertera mts-filer i linux

Jag har spelat in filmer i HD-format med en canon legria hf200 videokamera (full HD). Det genererar mts-filer som innehåller video på avchd-format. (för mig 1920x1080i, 2*25 Hz)

Jag följde guiden på http://wesleybailey.com/articles/ffmpeg-tutorial-convert-avchd-mts-m2ts
och lyckades koda om video inspelad i högsta kvalitet till ett format jag kan spela utan problem.

Jag använder debian lenny och la till debian multimedia i repositorien, innan jag följde guiden.

relevanta rader i /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian/ lenny main contrib non-free
deb http://ftp.sunet.se/pub/os/Linux/distributions/debian-multimedia/ lenny main


För information: jag visar här information från ffmpeg om videoklippen när jag spelat in i de olika kvalitetslägena på kameran, högsta till lägsta. Detta är skapat med ffmpeg -i [filnamn]

bitrate: 24055 kb/s
Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 25.00 tb(r)
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, 256 kb/s


bitrate: 17021 kb/s
Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 25.00 tb(r)
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, 256 kb/s

bitrate: 12483 kb/s
Stream #0.0[0x1011]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 25.00 tb(r)
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, 256 kb/s


bitrate: 7122 kb/s
Stream #0.0[0x1011]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 25.00 tb(r)
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, 256 kb/s

bitrate: 6258 kb/s
Stream #0.0[0x1011]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 25.00 tb(r)
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, 256 kb/s





För att konvertera till ett format som är lättare att spela upp utan att det hackar, använder jag följande kommando:
bitrate=4000
size="1280x720"
ffmpeg -i "$infile" -vcodec libxvid -b ${bitrate}k -acodec copy -deinterlace -s $size "$outfile"

Storleksändring av krypterad disk (luks)

Den här artikeln avser diskkryptering på Linux, med luks och ext3.

En guide för hur man konfigurar kryptering finns här.

Om du är otålig, hoppa till de sex nedersta raderna och byt ut mina namn mot dina.

Jag använder diskkryptering för att skydda mina data. Mina diskar hanteras av LVM, vilket jag varmt kan rekommendera. Nu har diskutrymmet tagit slut inom den krypterade partitionen, och jag behöver därför storleksändra den. Det är en av fördelarna med LVM, så länge det finns fysiskt diskutrymme kvar någonstans går det att öka valfri partition utan att det kräver några stora ändringar eller tar lång tid.

Jag kör kommandona nedan medan jag är inloggad och filsystemen är monterade. Det går utmärkt. Otroligt, egentligen, att det går!

Bakgrundsinformation:
Nedan heter min volymgrypp (lvm volume group) minvg, min logiska volym (lvm logical volume) minlv. Namnet för den krypterade volymen är minkv.
I /etc/crypttab står det:
#
minkv /dev/minvg/minlv none luks,noearly

I /etc/fstab finns raden:
/dev/mapper/minkv /home/mittnamn ext3 defaults 0 4

Såhär gör du:

Storleksändra först lvm-partitionen (här ökning med 5 GB):
$lvextend -L +5G /dev/minvg/minlv

Öka sedan den krypterade volymens storlek:
$cryptsetup resize minkv

Öka sedan filsystemets storlek:
$resize2fs /dev/mapper/minkv

Smokeping on debian lenny

Smokeping is a tool to monitor network connectivity and visualize it in a very easily readable way.
I had some trouble to get it started - not the smokeping part, but getting the apache configuration going. This is a writeup on what I did to get it going. It is used on Debian Lenny, but should work for ubuntu as well. To lighten up the text, I show one of the graphs I got from it. I can see there was a network disruption for approximtely 20 minutes.

I wrote this by following the material on

• howtoforge.com tutorial
  
• smokeping documentation
  
• debian documentation /usr/share/doc/smokeping/README.Debian
• apache cgi documentation
  

Install smokeping:

apt-get install smokeping

(optional)
Configure the interval in /etc/smokeping/config.d/Database as the default values are, in my opinion, a bit to sparse to detect network loss.

step = 30
pings = 3

Delete the statistics database to avoid the error during restart in the next step:

rm /var/lib/smokeping/Local/LocalMachine.rrd

restart smokeping:

/etc/init.d/smokeping restart

add targets in /etc/smokeping/config.d/Targets:

+ dreik
menu=dreik
title=dreik
++ sniiigel
menu=sniiigel
title=sniiigel
host=sniiigel.dreik.se

++ rufus
menu=rufus
title=rufus
host=rufus.paulsundvall.net

restart smokeping to make it start monitoring the newly added entries above (this lets you have some statistics to view, collected while getting the rest to work):

/etc/init.d/smokeping restart

Smokeping should now be running. To be able to see some results you have to run a web server with cgi capabilities. I believe one can generate the content statically instead and serve it as static pages, but I use apache/cgi here.

(Install apache if you have not done already. apt-get install apache2)

One has to edit an existing or create a new apache configuration file. I serve the stats through password protected pages on ssl, this is an excerpt from that file which is /etc/apache2/sites-available/ssl. If you do not care about encryptiong and/or protecting the page, you can set it up using a much shorter configuration file. Just leave out the bits about authentication.
I do not know much about apache configuration and the configuration could probably be improved while obtaining the same or higher security level.

Alias /smokeping/ /var/www/smokeping/

Options -FollowSymLinks
Options -Indexes
AllowOverride None
AuthUserFile /x/y/z/passwords
AuthGroupFile /x/y/z/groups
AuthName "bla da bla smokeping"
AuthType Basic
AuthBasicProvider file
Require group webreaders

Alias /smokepingcgi/ /usr/lib/cgi-bin/

Options +ExecCGI
AddHandler cgi-script cgi
SetHandler cgi-script
Options -FollowSymLinks
Options -Indexes
AllowOverride None
AuthUserFile /x/y/z/passwords
AuthGroupFile /x/y/z/groups
AuthName "bla da bla smokeping"
AuthType Basic
AuthBasicProvider file
Require group webreaders

Then reload the apache configuration with

/etc/init.d/apache2 reload

And voila, I get nice graphs when pointing the browser to the www.myserver.net/smokepingcgi/smokeping.cgi

To get the name right, edit /etc/smokeping/config.d/General to contain your name instead of the default.

Running apt-get through ssh SOCKS proxy using tsocks

I had to update two debian servers behind a firewall which allowed outgoing ssh connections but only allowed http (and ftp) access via a proxy with a username/password I did not have access to.

The problem was solved with tsocks and requires an ssh server working normally.
Let the ssh server be ssh.server.com and the host behind the firewall be called "host".
Regular syntax with

hostname$command

meaning I run command on host hostname is used. The guide is for debian but works similarily for other distributions.

Install tsock on the host, if not done already.
This might be a chicken-and-egg problem because in order to install it you may need to download it which is not possible because you are behind that proxy. I did it by downloading the correct package (right distribution, right architecture) on a computer with working internet connection (I call this "other" below). The package page is here, which has links to the deb packages. Then I transferred it with scp to host with sftp:

other$ scp tsocketXXX.deb ssh.server.com:

On host, I then got the package from the ssh server:

host$ scp ssh.server.com:tsocketXXX.deb .

and then installed it (as root, of course)

host$ dpkg -i tsocketXXX.deb

The dependencies for tsocket are most likely already met on a standard install.

I then created settings for the socket by creating ~/.tsocks.conf on host for the user which needs to go through the proxy. Because apt-get runs as root, I did this as the root user. The content of ~/.tsocks.conf is

server = 127.0.0.1
server_port = 8080

(Note: this did not work for me on debian etch, I had to edit /etc/tsocks.conf instead)

I then set up the SOCKS proxy with ssh, as a regular user on host

host$ ssh -D8080 ssh.server.com

I then (in a another parallel session) run apt-get:

host$ tsocks apt-get update && tsocks apt-get upgrade

which then runs just fine (as usual, apt is really a great tool!).

What happens is that the traffic goes through port 8080 on host, then tunnels encrypted through ssh to the ssh server. From there, it opens the connection just as if I had requested the url from inside the server.
Once apt-get finishes, you can quit the ssh session (the one with -D8080)

Security concerns: Someone else (local user) will be able to use your SOCKS proxy while you have it open. That might be a problem if you do not trust the local users on the server.

Generate static version of mediawiki site

Here are some random notes on how to generate a static dump of a mediawiki site

1. Download the DumpHTML.php extension:
   cd /var/tmp/
   svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/DumpHTML
   
2. Copy the extension to the mediawiki installation (mine is in /var/lib/mediawiki, I use the packaged version for Debian Lenny).
   Become root.
   cp -r /var/tmp/DumpHTML /var/lib/mediawiki/extensions/
3. Decide where to put the content (I use /var/www/staticdump here) and call the script:
   php /var/lib/mediawiki/extensions/DumpHTML/dumpHTML.php -d /var/tmp/staticdump --image-snapshot --force-copy --no-overwrite

Then my other web server (not apache, which serves mediawiki) can show the pages in /var/tmp/staticdump which is a lot faster than generating them with php.
The drawback is that some pages are not generated, such as the page listing all pages on the wiki.

The manual page for the extension is here: http://www.mediawiki.org/wiki/Manual:DumpHTML.php

Access control lists i linux

Att använda ett vanligt linuxsystem själv är inga problem. När det kommer in fler användare blir det svårare - att dela filer etc gör att rättigheter måste sättas korrekt. Om man har en enkel struktur är det lätt att göra så att alla har samma primärgrupp, vilket gör att de filer man skapar blir läs/skrivbara av andra (grovt förenklat, det beror naturligtvis på en väldig massa saker). För mer komplicerade strukturer behövs tyngre vapen: access control lists.

Här finns en läsvärd text: http://www.suse.de/~agruen/acl/linux-acls/online/
Såhär samverkar det med samba: http://www.samba.org/ .......

En snabbstart:

1. se till att filsystemet är monterat med acl påslaget: mount -oremount,acl,rw,noatime /dev/sdaX /mntpnt (för att göra permanent, lägg till acl i options i /etc/fstab)
2. Se till att du har acl installerat. På debian är det apt-get install acl som ordnar det.
   
3. pröva: mkdir /mntpnt/slask
4. getfacl /mntpnt/slask ger :
   getfacl /mntpnt/slask
   # file: slask
   # owner: pauls
   # group: pauls
   user::rwx
   group::r-x
   other::r-x
   
   
5. pröva att sätta acl:setfacl -d -m g:musiclovers:rw musik/
   
6. getfacl musik
   # file: musik
   # owner: pauls
   # group: musiclovers
   user::rwx
   group::rwx
   other::---
   default:user::rwx
   default:group::rwx
   default:group:musiclovers:rw-
   default:mask::rwx
   default:other::---
   

Ganska lätt, och väldigt kraftfullt. Tyvärr är det inte helt lätt att bevara dessa rättigheter för backup. Det verkar som att rsync har möjlighet att bevara rättigheterna (via flagga -A), tyvärr måste man då ha motsvarande grupper uppsatta på det system som backas upp mot. Tips mottages gärna!

sftp med minsta möjliga rättigheter

FTP är krångligt att sätta upp bakom en brandvägg. Dessutom verkar många ha väldigt svårt för att använda ftp-program. Därtill är ftp okrypterat.
Ett bra alternativ är sftp (notera skillnaden mot ftps).

Att sätta upp en sftp-server är lika lätt som att installera en sshserver, i debian (och ubuntu?) är det bara att installera packetet openssh-server så är det klart.
Däremot krävs det en del extra för att kunna ha användare som har tillgång till sftp men inte ett normalt shellkonto.

Jag följde guiden här, men det är ganska lätt bara man kommer ihåg följande steg:

1. skapa gruppen sftponly: $addgroup sftponly
   
2. konfigurera sshd (filen /etc/ssh/sshd_conf) så att en avdelning med "match group sftponly..." finns med innehåll
   

   Match group sftponly
          ChrootDirectory /home/%u
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp
   Glöm inte heller att ändra
   Subsystem sftp /usr/lib/openssh/sftp-server
   till
   Subsystem sftp internal-sftp
   

3. ladda om konfigurationen med $/etc/init.d/ssh reload
4. skapa en användare du vill ska kunna enbart använda sftp: $adduser unlucky
5. tilldela gruppgemenskap: $addgroup unlucky sftponly
   
6. sätt hemkatalog till / : $usermod -d / unlucky
   
7. se till att hemkatalogen ägs av root (för att ssh-servern ska kunna göra chroot): $chown root:root /home/unlucky
8. se till att användaren inte kan logga in normalt: $chsh -s /bin/false unlucky

Prova sedan att logga in med den nya användaren. Det ska inte gå vare sig direkt, via ssh, via su - unlucky utan enbart via sftp.
För windows finns winscp och filezilla som går att ansluta sig med.

Jag monterar kataloger inuti /home/unlucky med --bind readonly så att den nya användaren kan läsa men inte skriva. Mer om det någon annan dag!

Compile realtime kernel in Debian lenny (preemption patch)

This is how to compile a realtime kernel (preemptive kernel) in Debian Lenny. It should pretty much be cut and paste. I run a 64 bit Intel Q6600 system on a standard pc, and had a bit of hazzle before I got latencies down to a reasonable level.
I will use the directory /var/tmp/KERNEL to build in but that is not important.

• become root

• mkdir /var/tmp/KERNEL

• cd /var/tmp/KERNEL

• wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.26.6.tar.bz2

• wget
  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.6-rt11.bz2

• tar xvjf linux-2.6.26.6.tar.bz2

• cd linux-2.6.26.6

• bzcat ../patch-2.6.26.6-rt11.bz2 |patch -p1

• make clean && make mrproper

• make menuconfig (select complete preemption, choose 1000 Hz timer frequency. High resolution timers and symmetric multiprocessing SMP were already enabled)
  

• make-kpkg clean

• fakeroot make-kpkg --initrd --append-to-version=-rt-200811111930 kernel_image kernel_headers

• dpkg -i ../linux-headers-2.6.26.6-rt11-rt-200811111930_2.6.26.6-rt11-rt-200811111930-10.00.Custom_amd64.deb ../linux-image-2.6.26.6-rt11-rt-200811111930_2.6.26.6-rt11-rt-200811111930-10.00.Custom_amd64.deb

To make sure everything works as intended, run cyclictest (see previous post here) and make sure the latencies are low. I get approximately 300 us max latency which is a bit high compared to other results I have seen, but low enough for me. Make sure you stress the computer when running the test. Without the preemption patch, I get 3000 us in latency when I open a web browser. I also had to turn off things in the bios to get down to 300 us.
I tried the ubuntu realtime kernel 2.6.24 which installs fine on debian lenny, but the latency would just not come down. This indicates the BIOS setting was the crook. I use noapic nolapic as boot settings, which seem to be needed.

Update 2008-11-12:
The frequency scaling is the crook! Running a preemptive kernel as compiled above works fine until the cpu frequency jumps. It has nothing to do with noapic or nolapic, it is sufficient to prevent the frequency to change. You can do this with either disabling frequency scaling in BIOS, or lock the frequency with

for i in `seq 0 3`; do cpufreq-set -c$i -g performance; done

to get constant full speed or

for i in `seq 0 3`; do cpufreq-set -c$i -g powersave; done

to get lowest speed. Both work fine and gets the latency down to 250 us (performance ) to 20 us (powersave) when I tested, as compared to 3000 us with ondemand frequncy scaling governor. I guess I should test with heavier load and longer time to be sure, but I am confident that the frequency scaling is the one to blame. To bad, because frequency scaling is a wonderful thing.
I tried to keep only one core constant speed and locking the processes to that core with taskset

echo `seq 6050 6056` |xargs -n1 taskset -p 0x1

where 6050 is the process id reported by cyclictest.

Sniiigeln är död. Leve sniiigeln!

Min gamla server gav upp och det var bara att skaffa en ny. Den har fungerat huvudsakligen som backupserver och versionshanteringsserver för mitt företag. När man väl provat att ha en miniserver är det svårt att gå tillbaka till att köra backup till dvd/extern hårddisk.

Dags att skaffa en ny server! Jag vill att den ska uppfylla följande krav:

• strömsnål (detta utesluter mer eller mindre alla skrivbordsdatorer)
  
• går att köra debian linux på
  
• RAMminne >=64 MB för att kunna köra unison på större strukturer
• USB-ingång för att kunna ansluta externt USB-minne vid behov

Jag funderade över bland annat fit-pc, nslu-2, hemmabyggt VIA mini-itx och bubba two men det blev till slut en qnap TS109-II.

Jag har nu inhandlat ovan nämnda qnap och installerat debian på den. Hittills verkar den vara snabbare i responsen än nslu2, men jag når tyvärr bara 3 MB/s i överföringshastighet över rsync/ssh/arcfour. Gigabitnätverkskortet verkar därmed ganska meningslöst på denna server.

Uppdatering 20090730:
Jag sprang över denna fit-pc-liknande dator baserad på nvida ion: Asrock Ion 330. Mycket intressant! Verkar dra ca 20-30W, lite mycket för en server men helt ok för att byta ut en skrivbordsdator. Verkar vara svår att få tag på just för tillfället. Ska för kunds räkning köpa in server, det får bli en laptop HP Compaq 615 istället eftersom det är bråttom.

Koda dvdfilm till format lämpligt för webben

En kompis fick en dvdfilm med en intervju med honom skickad till sig, och bad mig om att göra om filmen till något format som man kan ha på en websida.
Eftersom bara en del av filmen var relevant behövde jag redigera, detta gjorde jag med kino. Extrahera filmen försökte jag göra med ffmpeg (något i stil med ffmpeg -i /var/tmp/VTS_01_1.VOB -ss 00:11:14 -t 350 -threads 4 -vcodec mpeg4 -b 4000k -acodec copy /tmp/output_mpeg4_b4000_ab128.avi) och sedan med mencoder (något i stil med
mencoder dvd:// -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=694 -oac mp3lame -lameopts br=128 -o dvdvideo.avi) men detta funkade lite halvdant för mig.

Till slut hittade jag en ganska enkelt framkomlig väg:

1. importera dvd:n med vobcopy (kopierar dvd-filmen till filer):
   $vobcopy
2. importera filen i kino
3. klipp bort ändar etc i kino
4. exportera inifrån kino
   

Skicka epost från kommandoraden

En mycket användbar funktion i *nix-system är möjligheten att skicka epost via kommandoraden. T ex såhär:

echo "hej hopp" | mailx -s"ämnesrad" slask@paulsundvall.net

Detta kräver förstås att datorn är konfigurerad korrekt. Jag har ett externt smtp-konto och använder det för att skicka post i mitt system. För att ställa in allting följde jag instruktionerna på http://wiki.debian.org/GmailAndExim4
Instruktionen gäller för att använda gmail som leverantör, men det fungerade med min epostleverantör utan problem.

Planeten jorden

Det här roliga programmet som heter xplanet kan bland annat rendera en bild av jorden. Väldigt fint!
I debian installerar man det med (som vanligt, lätt som en plätt!)
apt-get install xplanet xplanet-images
Användbart på många sätt, man kan visa andra planeter och stjärnor bland annat.
Bilden är gjord med kommandot
xplanet --num_times 1 --geometry 400x400 --latitude 59 --output jorden.png
En mer högupplöst bild går att åstadkomma genom att ändra 400x400 till något högre.

lvm är bra

En del av er har erfarenhet av att partitionera hårddiskar och känner till problemet med att man inte i förväg vet hur stora partitionerna bör vara för att inte slösa med utrymme i onödan men ändå vara tillräckligt stora för framtida behov.
En fantastisk lösning på detta problem är lvm (se wikipedia).
Defaultinstallationen för / var för liten. Att utöka den var så enkelt som att (medan systemet är igång!)
lvextend -L +2G /dev/quadricepsjr/root
ext2online /dev/quadricepsjr/root
så hade jag helt plötsligt 2 GB extra ledigt.

Uppdatering: jag hittade en guide på precis lagom nivå skriven av Steve Kemp. Här hittar du den: http://www.debian-administration.org/articles/410
Steve skriver väldigt bra tycker jag, han har bland annat skrivit det mycket praktiska jukeboxliknande programmet gnump3d som jag kör på min nslu2.

Nu har jag använt lvm till att slå ihop "överblivna" partitioner till en som är tillräckligt stor för att rymma det jag ska ha den till. Detta utan att behöva skapa nya partitioner och röra till det för min installation; det är skönt att ha åtminstone en dator som jag inte experimenterar med utan får lov att vara stabil.

Skapa ett tomt odt-dokument från kommandoraden

Jag vill kunna skapa en file från kommandoraden och sedan redigera den senare.
T ex
touch fil.txt
kate fil.txt

Motsvarande sak med odt-fil (open document, kan öppnas med t ex open office) vill jag ska kunna ske så här ungefär:
touch fil.odt
ooffice fil.odt

men det går inte eftersom fil.odt är tom och jag får varningar och felmeddelanden.
Lite arbete med google ger mig följande:
(tack http://www.livejournal.com/doc/server/lj.install.perl_setup.modules.html)

Installera OpenOffice::OODoc
som root, starta CPAN-skalet:
# perl -MCPAN -e shell
uppgradera cpan:
cpan> install Bundle::CPAN
kör sen:
cpan> reload cpan


sen är det dags för det jag egentligen ville:
cpan> install OpenOffice::OODoc
nu är jag klar och kan från en annan terminal som vanlig användare köra
oobuild tomt_dokument.ods --opendocument
som jag sedan kan öppna med openoffice:
ooffice tomt_dokument.ods

Jag använder debian testing men detta bör fungera på även andra distributioner.