Nyligen dök det upp anklagelser om avsiktligt inplacerade felaktigheter i krypteringsfunktioner i openbsd. Felaktigheterna skulle göra att FBI kan avkryptera information lättare. Väldigt obehagligt, men verkar inte vara så farligt som det lät.
I efterdiskussionerna kom en intressant tävling upp: en tävling där det gäller att avsiktlig programmera fel, på ett sådant sätt att funktionen ser helt korrekt ut men att koden utför något annat än man tror.
Här visas ett program som tar en bildfil och målar svart i en rektangel, t ex för att dölja ett ansikte eller text. Programmet fungerar som avsett, men lyckas ändå gömma bildinformation i den behandlade bilden. Den som blankar ut rektangeln tror att bildinformationen är borta, men den som känner till hemligheten kan delvis återskapa informationen. Koden ser helt oskyldig ut! Se själv här för noggrann diskussion.
Jag har mitt mobilabonnemang hos 3. Är måttligt road - dokumentation om hur man använder telefonsvararen saknas på hemsidan, kundtjänst ger felaktiga instruktioner, fakturorna kommer inte fram, priserna för att ringa utomlands är ett skämt. "man får hoppas att dom lägger ut nåt snart", som kundtjänst sa när jag frågade om var man kunde hitta instruktioner för mobilsvaret.
Hinner tänka en del fula ord, eftersom den varit exkluderad från mitt normala backupsystem baserat på rsync+hårdlänk+ssh+extern plats. Men, första regeln vid dataförlust är dont panic. Jag konstaterar kallt att jag råkat ta bort mappen på något sätt, och att data förmodligen inte är överskrivna eftersom ingen ytterligare aktivitet skett på partitionen. Jag monterar av partitionen, gör en lvm snapshot och kopierar den råa partitionen med dd till en extern disk. Data finns där, möjligtvis osammanhängande och utan metainformation om filnamn och datum men filerna borde gå att återvinna iallafall.
Innan jag hinner inspektera det stället den backupas till dagligen oroar jag mig att jag synkroniserar - och att borttagningen av mappen kan ha synkroniserats även den. För att se om det går att vinna data söker jag på "undelete file ext3" och liknande och hittar en hel del intressanta script. Jag hinner testa några och visst går det att hitta filerna igen! Tidsstämplarna är fel och filnamnen är borta, men själva filinnehållet är bevarat.
Jag prövade bland annat photorec som finns tillgängligt i ubuntu. Några andra intressanta uppslag är ext3grep och ext3undel.
Ungefär samtidigt hinner jag inspektera målet för backupen, och visst, där finns alla filerna. Jag har kört med rsync utan flaggan --delete. Skönt att jag tänkte till när jag satte upp det scriptet.
Några nygamla slutsatser:
backupen ska vara på en annan fysisk plats
på annat fysiskt media (följer av föregående :-)
ske automatiskt (annars blir den aldrig gjord)
vara skyddad mot användarmisstag (demonstreras av det som hänt mig)
Min normala backuprutin uppfyller alla krav ovan. Det är denna mapp som inte omfattas av den normala backupen, som på grund av sin storlek fått en separat rutin. Det blir ändring på det nu. Jag lutar åt ett alternativ med rsync+hårdlänk. Jag funderar även på vilket filsystem som är bäst ur återskapningssynpunkt. Verkar som att ext2 är bättre än ext3, men det tar alldeles för lång tid vid filkontroll för att vara praktiskt.
Höstens troligen sista segling idag, från Tyresö till Värmdö. Väldigt fint väder och en riktigt fin höstdag med varmt och sol. Vi såg tre havsörnar ovanför Baggensfjärden!
Det blåste ordentligt, Stavsnäs hade 11 m/s medelvind och 19 m/s i byarna (inklippt nedan). Skummet blåste av vågtopparna och det var fullt med vita gäss. Vi gjorde ungefär 6 knop när vi med nedtagna segel drev in mot hamnen.
Tyvärr hade vi ett litet motorhaveri, så vi fick låna en motor med kort rigg. Det finns en anledning till att man har extra lång rigg på utombordsmotorer, propellern gick i luften ganska ofta och det var svårt att komma mot vinden.
Segla är fantastiskt. Segla i skärgården är ännu bättre. Segla trimaran är ännu bättre!
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!
Jag använder sedan ett par år krypterad epost. Jättebra och ganska enkelt, men en stor sak är fel: att det är få som använder det. Nu har jag ibland behov av att skicka saker krypterat med användare som ibland inte är särskilt datorkunniga eller inte har tillräckliga rättigheter att bestämma över sin egen dator.
När en sådan användare ska skicka något hemligt till mig kan jag be personen att komprimera filen med 7-zip lösenordsskyddat och välja något lösenord som meddelas mig på något annat sätt. Problemet är att användaren då behöver komma över tröskeln att installera och/eller använda 7zip. Samt något annat jobbigt och potentiellt svårt: att meddela lösenordet. Och inte minst, att komma på ett tillräckligt varierat lösenord som dessutom inte missuppfattas över en raspig mobilanslutning.
En lösning skulle vara att jag sätter upp en säker (https) sida för filuppladdning på min webserver som i sin tur får kryptera och maila mig, med pgp och min publika nyckel. Nackdelen är att https är tungt för servern, samt att servern får jobba hårt för att kryptera ytterligare en gång. Fördelen är att användaren inte behöver veta något annat än adressen till min sida.
En väldigt bra ide är att låta användaren stå för datorkraften själv, genom att låta krypteringen ske hos användaren. Den krypterade filen kan sedan skickas över nätet utan några speciella åtgärder. Som med andra lösningar löser det inte problemet med autentisering (att jag kan vara säker på vem som skickat det) på samma sätt som "riktig" krypterad epost gör.
Såhär skulle det kunna se ut:
jag sätter upp en sida som användaren går in på, https-skyddad för att hindra man in the middle-attack på java-scripten. Typ "https://www.pauldreik.se/laddauppfiler.php" eller något sådant. Här finns javascripen inbäddade som senare sköter krypteringen. Den lilla trafik som måste krypteras är själva htmlkoden för sidan samt scripten, enbart några kb.
jag sätter även upp en normal (http) sida med ett php-script eller vad som helst, t ex "http://www.pauldreik.se/mottagare.php" som accepterar indata i form av uppladdade filer. användaren ser ej denna, så denna kan vara vad som helst.
användaren väljer en fil ifrån en vanlig htmlform, som de flesta användare använt väldigt många andra ställen, t ex när man laddar upp en bilaga till webmail. Filen läses sedan lokalt på användarens dator,krypteras lokalt med javascript och min publika nyckel, och postas sedan till "http://www.pauldreik.se/mottagare.php" i krypterad form över vanlig http.
på webservern skickas den mottagna filen i ett mail till mig. Eftersom bara jag har den privata nyckeln är det bara jag som kan läsa filen. Kringdetaljer som datum och ev namn och så som användaren skrivit in samt avsändande ipadress följer med. Dessa går naturligtvis att mixtra med på samma sätt som vem som helst kan skicka mig en fil och hävda att de heter något annat.Detta problem löses genom signering, som finns stöd för i "riktig" krypterad epost.
På detta sätt behöver användaren inte ha några rättigheter, inte installera något, och kan skicka mig filer utan yttre insyn. Jag behöver inte ha en kraftig server eftersom den inte gör någon kryptering.
Byggstenar kommer från hanewin.net (se länk i texten ovan), pgp och standard html samt javascript.
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.
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!
Ett flygplan förbrukar väldigt mycket bränsle vid start, något mindre vid stigning upp till flyghöjd och förhållandevis lite vid flygning på konstant höjd. Här finns en sida som ger några intressanta siffror: http://fluglaerm.de/hamburg/klima.htm
Jag har tänkt på det här när jag läst flygbolagens redovisning som brukar finnas med i ombordtidningen - där specificeras bränsleåtgången men ej vid vilken flyglängd som avses.
Bränsleförbrukning per person (räknat på 300 personer, verkar vara något lågt) blir
50 mils flygning - 148 g CO2/km (kort resa för flygplanstypen)
200 mils flygning - 102 g CO2/km
5000 mils flygning - 93 g CO2/km
Av detta är 3133 g/person för starten , 213 g/person och km för stigningen och sedan dalar det mot 87g per person och km för flygning på konstant höjd.
Ganska stor variation!
Fotnot: det är bränsleåtgång och ej co2 som anges på nedersta raden i tabellen på länken, trots texten.
Att versionsnumren tickar framåt på linuxkärnan är lätt att se (www.kernel.org). Commitloggen är inte lätt att förstå, och det är svårt att se skogen för alla träden. Det behövs tolkningshjälp.
Jag har tidigare läst den bra sammanställningen på kernel newbies.
Här finns en annan bra förklaring: h-online.com
Snabba datorer är dyra. Att maximera prestanda för en given budget är lättare när man har en sådan här jämförelse framför sig. http://techreport.com/articles.x/18799/15
Bläddra ner till "overall performance per dollar". X6-orna (AMD:s sexkärninga) ligger bra till!
Att koppla in LED-belysning är inte enkelt. Detta beror på att lysdioder har en tröskeleffekt i sin ström-spänningskurva. Under en viss spänning lyser det inte alls, över en viss spänning överbelastas lysdioden till dess att den går sönder. En illustrerande graf finns på engelska wikipedia. Normal drift sker alltså i ett smalt intervall. Därför ska dioder strömstyras.
Vissa lysdiodlister man köper är kopplade med ett motstånd i serie. På det sättet ökar intervallet för vilken spänning lysdioden lyser lagom, så att man kan koppla till en fast spänning (vanligast 12 V) utan att vare sig överbelasta eller inte få något ljus alls.
För att dimma led kan man antingen styra spänningen (väldigt svårt), reglera strömmen eller pulsa strömmen/spänningen (PWM-styrning). Att reglera strömmen faller sig naturligt om man har strömstyrning. Då låter man kretsen som styr strömmen ha justerbar ström, istället för ett fast värde. Detta komplicerar inte kretsen särskilt mycket - det svåra är att reglera strömmen.
Det är jättesvårt att köpa dimbar led. Nomenklaturen är inte enhetlig. Man får höra sådana termer som "mekanisk transformator", som jag inte tycker finns. Själva LED-listen påverkas inte av dimbarhet. Däremot drivdonet. Vissa dimmerenheter är avsedda att kopplas in mellan drivdon och LED, andra avsedda att koppla in på 230V-sidan. Vad jag är ute efter är ett drivdon som är reglerbart i sig.
Till slut fastnade jag för ett drivdon från designlight, köpt från Theofils. Enligt specifikationen är strömmen ställbar från 10-350mA. Det finns i två varianter, en D-LT15WD som klarar upp till 15 W och en D-LT30WD som klarar upp till 30W. Ohms lag ger att den då kan ge en maximal utspänning på 15/0.350=43V respektive 86V. Den för högre effekt var något dyrare, 464 kr på Theofils.
En annan drivenhet jag övervägde är från Lumoluce, via ledbutiken. Denna har flera olika drivlägen (konstant spänning, konstant ström, dimbar, master/slav-funktionalitet. allt detta för 650 kr). Eller den här, också från ledbutiken.
Till detta kommer led-listen. Efter att ha letat runt lite på olika ställen fastnade jag för LED-tejp super 1 varmvit 90 lumen från återförsäljaren Molectric som är en flexibel remsa med 60 lysdioder per meter. Man kan dela den var tredje diod (var 5:e cm) vilket gör den lätt att koppla in. På baksidan sitter självhäftande tejp.
Den nominella effekten är 5W per meter vid 12 V (den är alltså avsedd för konstant spänning).
Man kan då räkna ut att för att få max effekt vid 350 mA ska man seriekoppla bitar om 0.350A/(5W/m/12V)=0.84m. Med delbarheten var 5:e cm blir det då 85 cm. 6 m ledlist totalt går att koppla in på denna regulator. Listen kostar 258kr/m före mängdrabatt.
När jag kopplat in allt visar det sig att ljuset är väldigt bra från LED-listen. Den gör skäl för benämningen varmvit. Regulatorn är däremot inte särskilt bra - lägsta läget är väldigt starkt och ljuset ökar inte jämnt med rattens vridning. Dimbart är det, men inte lika stort område som en normal dimmer med glödlampa ger. Här finns mer att göra!
Sammanlagt så tycker jag att det är jättefint att ha en remsa med lysande punkter. Det ger stora möjligheter att utforma belysningen!
Först ville den inte starta, men när jag tagit ut batteriet gick det bättre.
Tiden har gått fort, både vad gäller hårdvara och operativsystem. Nuvarande macbook har ca 100 ggr högre klockfrekvens. Redan då kunde man välja inställningar för prestanda eller batterilivslängd.
Video på webben/datorer är ett problemområde. Det är för att det finns patentfrågor och många olika format, vissa av dom proprietära. Att hitta minsta gemensamma nämnare för alla besökare resulterar i att man använder mjpeg, vilket är undermåligt. Alla plattformar stöder inte flash. Iphone/ipad till exempel.
Ett steg framåt är html5, som stöder uppmärkning av video.
Jag deltar i folding@home, för lag sweclockers. Mitt mål är att komma in på topp tusen. För det krävs i dagsläget 41096 poäng. Jag har 7676 i dagsläget.
Uppdatering 20100707:
Jag har kommit in på topp tusen och ligger just nu på plats 990. Gränsen för att komma in på listan har ökat till 42799 poäng.
Det har nyligen varit en del högljudda diskussioner om handikappsystem i flerskrovsvärlden. Det är många som sagt att handikappsegling är på låtsas, entyp är det som är det enda som gäller om man vill kappsegla.
Vad finns det för krav på handikappsystem?
Det ska vara rättvisande för olika vindar, banor, vågförhållanden relativt andra båtar i samma handikappsystem.
Det ska baseras på båtens maximala prestanda, dvs hur fort den kan gå med bästa möjliga besättning.
Punkt 1 ovan är svår att definiera. Väntevärdet av båtens hastighet över ett givet urval av yttre förhållanden är egentligen den enda rimliga definitionen.
Punkt 2 är svår när man har få båtar som seglar få seglingar på amatörnivå.
Därtill kommer flera önskemål
Det ska vara lätt att ta fram. Även lyskommittéer seglar hellre än sitter vid datorn eller mäter segel.
Det ska vara internationellt gångbart.
Det ska inte leda till att man tar fram båtar som har lågt handikapp för sin verkliga prestanda. Detta har förstört många båttyper genom åren.
Det ska inte uppmuntra till att bygga om båten för att få så långt handikapp kontra prestanda som möjligt. Detta för att uppmuntra att bygga bra och snabba båtar, snarare än handikappoptimering.
För att uppnå ovanstående försöker man göra på olika sätt.
matematisk formel för hur man räknar ut handikappet baserat på mått, längd, vikt och möjligen andra saker.
handikappet tas fram från kappseglingsresultat
En kombination av ovanstående.
Sedan kan man ha olika approach till hur man ska gå tillväga
Allt är hemligt för alla utom handikappkommittén.
Allt är öppet. Man redovisar öppet för vilka grunder man sätter handikapptalet på, för varje enskild båt.
Principen för hur man gör är öppen, men beslutet för varje enskild båt är hemlig.
Om man talar om hur man gör, riskerar man att få handikappoptimerade båtar, vilket är dåligt.
Om man håller allt hemligt riskerar man att förtroendet för systemet tappas.
Sammantaget skulle jag vilja hävda att det är oförenliga krav för att göra ett bra handikappsystem. Det kan bara bli mer eller mindre dåligt. Det ser man t ex på att när det är hårdvindssegling så går vissa båtar bra jämfört med annars. Detta är en ofrånkomlig effekt av att ha samma handikapptal oberoende av yttre förhållanden. Därtill kommer att vindar ändras medan man seglar, varför förhållanden kan vara olika för olika båtar i samma kappsegling. Detta händer när det mojnar eller friskar i under seglingen.
För flerskrovsseglare använder man SRS (f.d. LYS). Det sätts i en kommitté, med hemligt förfarande. Om det baseras på empiri, formler eller en kombination låter jag vara osagt.
Det är ganska naturligt att kommittén får mycket kritik från seglarna. "När alla är missnöjda samtidigt, har man gjort rätt" var det någon som sa...
Jag skulle vilja att lyskommittén öppnar en aning och blir lite mer transparenta. Redovisa öppet vilka principer man arbetar efter.
Det är inte helt lätt att hitta en passande bil för att kunna dra ett släp på 1500 kg totalvikt med B-körkort.
Här finns en lista någon sammanställt: http://bilmodeller.se/slapvagn/
För att koda video till min mobiltelefon använder jag programmet handbrake. Telefonen är rätt petig med vad den vill spela eller inte.
Inställningarna nedan fungerar för mig:
container mp4
ej web optimized
ej large file size
picture: ej detelicine
ej decomb
ej devblock
ej deinterlace
ej denoise
storlek 320x180
crop 0:0:0:0
optimal for source off
anamorphic off
video:
video codec mpeg-4 (ffmpeg)
framrate same as source
2 pass encoding
turbo first pass
bitrate 200 kbps
audio
acc (faac) bitrate 160 sample rate same as source, stereo
För att ladda ner senaste ubuntu använde jag bittorrent. Det är praktiskt att göra detta på min server, eftersom den är påslagen jämt och nåbar.
Förut har jag kört genom att logga in och sedan med transmission-remote för att kontrollera transmission-daemon. Det finns ett annat sätt att göra - genom att köra genom webgränssnitt.
Här är en guide för att få till transmission så att det fungerar. Det kräver visst pyssel för att få till säkerhetsmässigt och att undvika överbelastning av server och router. Samtidigt ska uppsättningen vara säker.
Som alltid kan man göra på många sätt. Det här är sättet jag valde. Guiden avser linux.
skapa en separat användare för att köra nedladdningen
skapa kataloger som har rätt rättigheter (för att undvika konsekvenser av ev. intrång)
bygg transmission
starta demonen och stäng sedan av den.
redigera konfigurationsfilen
starta demonen (crontab, eller manuellt).
anslut via webgränssnitt
tuta och kör!
Steg 1
Jag väljer att skapa användaren "transmission". Med roträttigheter kör jag adduser transmission. Jag väljer att ta bort lösenordet genom att köra passwd -l transmission. På det sättet riskerar jag inte att någon kan logga in som den nya användaren. För att förenkla att komma åt det jag laddar ner låter jag användaren ha en grupptillhörighet som min vanliga användare också är med i. Det görs med usermod -g gruppnamn -G gruppnamn transmission.
Se till att katalogen ägs/har rättigheter på ett sådant sätt att transmission kan skriva till den.
Steg 3
bygg transmission. Jag checkade ut revision 10363 från transmission. Detta pekar till en fungerande version. Jag körde först head, men det var inte särskilt stabilt. I exemplet nedan används den utpekade versionen.
Som användare transmission (su - transmission som root, eller sudo su - transmission för er ubuntufreaks :-) :
installera först beroenden (och subversion, gcc om du inte redan har det. ) Beroenden kan jag inte på rak arm, men de finns listade på http://trac.transmissionbt.com/wiki/Building
Det är viktigt att allt är disable utom daemon när du kör configure. Se listan längst ner på sidan som länkas till ovan.
mkdir -p ~/code/thirdparty
cd ~/code/thirdparty
svn co -r10363 svn://svn.m0k.org/Transmission/trunk/ transmission
.cd transmission
./autogen.sh
./configure --disable-gtk --disable-allt-utom-daemon --enable-daemon
make
Det tar rätt lång tid både för configure och make ovan. Ha tålamod!
Steg 4
kör demonen med
code/thirdparty/transmission/daemon/transmission-daemon -f
och avsluta med ctrl c efter en stund. Då finns en konfigurationsfil att utgå från.
Steg 5
redigera konfigurationsfilen. Min ser ut såhär. Detta är viktigt för att få det att fungera. Kolla inställningarna noga - annars så aktiveras till exempel inte webgränssnittet!
emacs ~/config/transmission-daemon/settings.json
[
"alt-speed-down": 50,
"alt-speed-enabled": false,
"alt-speed-time-begin": 540,
"alt-speed-time-day": 127,
"alt-speed-time-enabled": false,
"alt-speed-time-end": 1020,
"alt-speed-up": 50,
"bind-address-ipv4": "0.0.0.0",
"bind-address-ipv6": "::",
"blocklist-enabled": false,
"dht-enabled": true,
"download-dir": "/sökväg/till/bra/plats/för/nedladdade/filer/downloaddir",
"encryption": 1,
"incomplete-dir": "/sökväg/till/bra/plats/för/nedladdade/filer/incompletedir",
"incomplete-dir-enabled": true,
"lazy-bitfield-enabled": true,
"message-level": 2,
"open-file-limit": 32,
"peer-limit-global": 40,
"peer-limit-per-torrent": 30,
"peer-port": 6881,
"peer-port-random-high": 65535,
"peer-port-random-low": 49152,
"peer-port-random-on-start": false,
"peer-socket-tos": 0,
"pex-enabled": true,
"port-forwarding-enabled": false,
"preallocation": 1,
"proxy": "",
"proxy-auth-enabled": false,
"proxy-auth-password": "",
"proxy-auth-username": "",
"proxy-enabled": false,
"proxy-port": 80,
"proxy-type": 0,
"ratio-limit": 2.0000,
"ratio-limit-enabled": false,
"rename-partial-files": true,
"rpc-authentication-required": false,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": "{redigardavmigförattdetförmodligenärdumtattvisamittlösenordhär",
"rpc-port": 9091,
"rpc-username": "",
"rpc-whitelist": "127.0.0.1",
"rpc-whitelist-enabled": true,
"speed-limit-down": 500,
"speed-limit-down-enabled": true,
"speed-limit-up": 500,
"speed-limit-up-enabled": true,
"start-added-torrents": true,
"trash-original-torrent-files": false,
"umask": 18,
"upload-slots-per-torrent": 14
}
Jag har begränsat hastigheten och antal anslutningar, eftersom min router inte klarar mer.
Steg 6
Sen körde jag igång klienten. Rpc-whitelist begränsar vem som kan nå webgränssnittet, genom att sätta det till 127.0.0.1 kommer man bara åt det lokalt. Jag gör så att jag vidarebefodrar en port med ssh från dee dator jag sitter vid, dvs ssh -L9091:localhost:9091 server.com och ansluter sedan till localhost:9091 på den lokala datorn.
Jag har följande i min crontab. Nästa ombootning får avslöja om det fungerar....
@reboot sleep 120s && TRANSMISSION_WEB_HOME=$HOME/code/thirdparty/transmission/web/ $HOME/code/thirdparty/transmission/daemon/transmission-daemon -f
för att provköra använder jag det som är efter &&.
Steg 7
Jag sätter upp en port-vidarebefodring med ssh
ssh -L9091:localhost:9091 server.com
och ansluter sedan med en webläsare till http://localhost:9091/
Idag släpptes äntligen Ubuntu 10.04. Otroligt snygg installation. Här en skärmdump från installation via mac os x/virtualbox.
Grafiken tycker jag har fått sig ett lyft, riktigt snyggt i min smak! Allra mest intressanta nyheten är den snabba starten. Nu gick det inte särskilt fort för mig ändå, strax under 40 sekunder från boot till fungerande kommandorad. Helt ok. Det tog fem minuter att starta red hat 2001, när jag började med linux...
Det kändes kul att installera octave och octave sockets, eftersom jag har skrivit en (liten) del av koden! Installera octave3.2 och octave-sockets så kan du prova själv. Det är min förtjänst att minnet inte går åt i samma takt som nätverkstrafiken strömmar in över octavesocketarna.
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 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]
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"
Jag har en ide om hur man kan minska utsläppen vid flygplansstart. Problemet är att man vid start måste ha mycket hög effekt. Om man kan hjälpa till vid start bör man kunna optimera motorerna för verkningsgrad och inte toppeffekt. Det finns säkert massa "ifs och buts" men se det som en ide!
Tilläggseffekt från landansluten el
Hjälpfordon (bogserbåtsliknande)
Draglina
Tilläggsraketer
Metod 1: En högspänningskabel ansluts till flygplanet, ev från en liten vagn som kan åka längs startbanan. Elektriska element i motorn omvandlar el till värme. När planet lyfter lossnar kabeln.
Metod 2a: En liten rälsbunden vagn, eldriven, hakar i planet med en krok och hjälper till att accelerera det. När planet lyfter lossnar kroken automatiskt.
Metod 2b: Ett litet hjälpplan dockar till flygplanet. Hjälpplanet är försedd med en mycket kraftig vätgas/biogasmotor. När hjälpplanet hjälpt till att lyfta flygplanet flyger det autonomt tillbaka till flygplatsen och tankas igen.
Metod 3: En eldriven winsch hjälper upp flygplanet. När flygplanet är tillräckligt högt upp lossas linan. Eventuellt kan winschen lagra energi i ett svänghjul under en längre tid, som sedan mekaniskt används till winschen. På det sättet kapas toppeffektbehovet i winschen.
Metod 4: Raketer fyllda med förnybart bränsle (vätgas/biogas) monteras på planet. Efter att de hjälp till vid starten släpps de ner för återvinning, eller så får de sitta kvar till landning.
En uppskattning av effektbehovet vid start: En jumbojet väger ca 400 ton (max startvikt). Med 250 km/h starthastighet krävs ca 1 GJ i rörelseenergi. Om man har 30 sekunder på sig är det en medeleffekt på ca 30 MW.
Omvänd DNS (reverse DNS) innebär att en ipadress slås upp till ett värdnamn. Jag har funderat över hur man ska gå till väga för att få omvänd dns att fungera korrekt, dvs att uppslagning från domännamn till adress och sedan tillbaka ger samma domännamn. Här finns en bloggpost som behandlar hur det går till. Det handlar alltså om att få ISP:n att lägga in poster som pekar på det man önskar.
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
Jag använder Unison för att synkronisera filer mellan datorer. Det är ett utmärkt verktyg. Fram till nyligen har det inte gått att synkronisera filer mellan olika plattformar på ett enkelt sätt - om man använder svenska tecken. Eller rättare sagt, exotiska tecken som manualen säger, allt utom 7-bits ascii. Sålänge man håller sig till en och samma plattform har det inte varit några problem.
Nu finns en lösning - senaste versionen av unison fungerar utmärkt oberoende av teckenkodning. Jag har fått synkronisering att fungera mellan Mac OS X, Windows och Linux (Debian, Ubuntu) smärtfritt. Jag använder en Debianbaserad linuxserver som "nav" och de övriga maskinerna synkronisera mot den. Tricket för att få det att fungera är att köra en tillräckligt sen version av unison på alla ställen. Klientens version måste fungera med den version som ligger på servern. Viktigt är att man kan ha flera samtidiga versioner på servern. Detta gör att man kan ha en blandning av olika versioner, utan problem.
En liten kommentar: i texten säger jag att "det inte behövs" osv. Eftersom en del operativsystem är konfigurerbara i all oändlighet är det inte nödvändigtvis sant. Däremot är det sant för den konfiguration som gäller för standardinstallationer.
Här kommer receptet som fungerar för mig:
På servern (Debian Lenny linux): --------------------------------- Installera unison med apt-get install unison. Det ger version 2.27.57 för mig: $unison -version unison version 2.27.57
Detta räcker utmärkt för att synkronisera andra maskiner med samma version, OM DU HAR SAMMA TECKENKODNING. Kör du t ex ubuntu eller debian behövs inget mer göras. Det behövs däremot om du ska köra Mac OS X eller windows som klienter mot servern. Och det ska vi, inte sant!
Nu checkar jag ut version 2.39.6 från unisons repositorie (funkar troligtvis med andra versioner, om du vill ha exakt som jag så lägg till -r403 till kommandot nedan för att få revision 403) $mkdir -p $HOME/code/thirdparty $cd $HOME/code/thirdparty $svn co -r403 https://webdav.seas.upenn.edu/svn/unison/trunk unison Du måste ha subversion och ocaml installerat. (På min arkitektur (arm) råkar ocamlopt inte finnas, därför använder jag NATIVE=false. Lämna ut det om du inte behöver det) $cd $HOME/code/thirdparty/unison $make NATIVE=false när kompileringen lyckas kör jag $ $HOME/code/thirdparty/unison/src/unison -version och får svaret unison version 2.39.6 vilket betyder att allt är som det ska.
På Mac OS X (som klient) --------------------------------- På mac gör jag ungefär likadant som på servern. Detta eftersom de färdigbyggda paket för unison (.dmg) inte var tillräckligt aktuella för att det skulle fungera för mig. Nu ser jag att det dykt upp en 2.40 för Mac, kan vara värt att prova först! Annars bygger man såhär. Man behöver förmodligen ha installerat utvecklarverktygen på mac för att det ska fungera. (Du behöver make, ssh, subversion, ocaml och möjligtvis fler saker) $mkdir -p $HOME/code/thirdparty $cd $HOME/code/thirdparty $svn co -r403 https://webdav.seas.upenn.edu/svn/unison/trunk unison $cd $HOME/code/thirdparty/unison $make
Om allt gick bra har du nu ett fungerande unison. Det ligger i $HOME/code/thirdparty/unison/src/uimacnew/build/Default/ Jag drog mitt till dockningslisten och så funkade allt som tänkt.
Sist men nästan viktigast: peka ut sökvägen till unison på servern i konfigurationsfilen. Konfigurationsfilen ligger i ~/Library/Application Support/Unison/*.prf på mac os x. Se till att den innehåller raden servercmd=XXXX/code/thirdparty/unison/src/unison där XXXX matchar $HOME på servern. Kör $echo $HOME på servern om du inte vet vad det är.
På Windows (som klient) -------------------------------- På windows fick jag en av de förbyggda programmen att fungera. Här visar sig verkligen styrkan i att köra en distribution och inte bara ett operativsystem - bibliotek, sökvägar, binärer finns enkelt tillgängliga. På Debian kör jag apt-get install unison-gtk och är sedan klar. I windows är man tvungen att installera inte bara unison utan även ssh (via cygwin är lättast) och gtk. Det tog mig säkert en timme att få att fungera.
Du behöver en tillräckligt sen unisonversion för att få det att fungera mot unison som används på servern.
Instruktioner för hur man gör finns när man letar sig fram till downloads för windows på unisons hemsida. Man behöver unisonbinären, gtk-runtime och cygwin. Jag kopierade bara in unisonbinären rakt in i det uppackade gtk-runtime-biblioteket och det fungerade för mig.
Precis som på mac os x behöver du peka ut sökvägen till unison på servern. Profilen redigeras i unisons grafiska gränssnitt. Lägg till servercmd enligt instruktionerna för mac os x.
Om du följt instruktionerna och bett tillräckligt till datorguden kan du nu synkronisera filer utan problem med teckenkodning!
I ran into a bug with google earth, which refused to show my kml files properly. My curves had been straightened out and data were missing. This is because the decimal point notation is not respected when parsing kml files - my Swedish localization thinks decimal points are a comma (,) and not point (.).
This is a workaround: start google earth with LANG set to something else. $LANG= googleearth
For me, this bug appears on google earth 5.1.3506.3999 (beta) but not 5.0.11377.1968 (beta). Now these two run on different systems, but anyway....
Sorry for not having time to dig the bug archives etc. Post links if you know any relevant links for this bug.
I have not seen anything about decimal points in the kml specification. If you see it somewhere, please post a link.
And while I am at it: Thanks google (and/or Keyhole?), for distributing this fantastic piece of software.
Jag har börjat få fler och fler spamkommentarer på bloggen. Jag har tröttnat på att gå in och ta bort dom, så nu har jag aktiverat att jag måste godkänna kommentarer. Det är så att man undrar vem som har tid att sitta och skriva kommentarer överallt.
Jag lånade ut min elenergimätare till en bekant, med villkor att han delade med sig av resultatet. Han har nu mätt upp sitt 1m³(!) saltvattenakvarium och fler andra grejer.
Jag ställer mig i raden av gratulanter till Google som nu inte längre infinner sig i att medverka till den kinesiska censuren. Googles blogginlägg om saken(engelska) Ett mer utförligt utlägg (på svenska) Förhoppningsvis leder detta på sikt till att censuren kan luckras upp.
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.
(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:
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.
