Nu finns nya 10.10 ute för er som inte redan har installerat det. Läs mer om nyheterna hos OMG! Ubuntu och WebUpd8. Lämna gärna en rad om vad ni tycker om Maverick.

Hämta Ubuntu 10.10

Jag tänkte beskriva ett par saker som är väldigt kritiska för ett virtualiseringssystem. Nämligen stöd för att hantera en park som ett stort arbetskluster. Samt stöd för migrering av maskiner mellan noder i detta kluster. Vidare som kommer jag även att ta upp DRBD (Distributed Replication Block Device) samt backup av virtuella maskiner.

Backup är något som jag inte kräver av ett virtualiseringsystem. Men det är alltid trevligt att ha flera olika nivåer av backup. Jag har alltid utfört backup av maskiner via enkla skript. Dessa filer har sedan blivit kopierade till två olika maskiner. Båda med RAID 6 för extra säkerhets skull. Det är aldrig skoj när en till disk dyker medans man håller på att byta ut en trasig. Det skall mycket till för att en tredje disk skall gå sönder i samma stund.

Kluster är en av de fundamentala delarna i PVE. Så processen för att skapa ett är väldigt enkel. Vad jag tycker är synd är avsaknaden av uppdelning i flera kluster. Som det är i dag så fungerar det på så vis att man har en master och flera slavar. Det finns inget sätt att sektionera upp i flera olika grupper. För mitt företag så är inte detta ett riktigt bekymmer. Men jag kan tänka mig att en stor serverpark hade haft enorma problem då adminsidan hade innehållit en sådär hundra fysiska maskiner. Självfallet kan man lösa detta genom att placera ut flera masters. Kanske rentutav en per rackskåp om man så vill. Dock finns det ett stort problem med detta som jag kommer till strax.

En sådan lösning kräver dock att man är händig och kan organisera sin park. Det behövs nämligen tillverkas ett system (webbsida) via vilken samtliga masters kan listas och nås. Ett sådant system är trivialt att bygga och något som jag själv skrev ihop på en eftermiddag. Men om man endast är utbildad till serveradmin och inte kodare. Eller inte känner för att sätta sig att kodknacka så kan det var ett bekymmer.

Som jag nämnde tidigare så är kluster en fundamental del av PVE. Klustret tillhandahåller stödet som krävs för att man skall kunna administrera ett flertal maskiner från ett admingränssnitt. Det möjliggör översikt av saker så som CPU- och minnesanvändning. IODelay samt procentuell användning av diskutrymme. Ett exempel kan se ut på följande vis.

Den med uppmärksamhet kan lägga märke till att maskinen 'kajsa' är något mer belastad än övriga maskiner. Detta beror på att 'kajsa' ansvarar för ett litet IO experiment jag arbetar på. Nämligen hurvida det är hållbart att köra en PostgreSQL server i en OpenVZ miljö. Resultaten av detta experiment tänkte jag ta upp i ett senare kapitel då jag skall beskriva flaskhalsar.

Vid en sådan situation när man märker att en virtuell maskin rullar segare för att dess värdmaskin är belastad. Så är det väldigt trevligt att kunna flytta över VM:en till en mindre belastad värd. Detta är en trivial process i PVE. Men det finns ändå en sak att tänka på. Om en KVM maskin inte ligger på en iSCSI eller NFS lagring så kommer en 'online' migration inte att lyckas. Detta beror på att värd A inte kan överföra kontroll samt hela avbildningen till värd B medans den fortfarande låter KVM arbeta. I en sådan situation måste man stänga av den virtuella maskinen innan man kan överföra den.

PVE har inte i dagsläget stöd för att automatiskt flytta runt virtuella maskiner vid situationer då värden är belastad. Ett sådant system är dock inte speciellt svårt att implementera om man nu måste ha ett sådant stöd redan i dag. En liten daemon som ligger och snurrar på mastern skulle kunna hålla ett vakande öga på klustret med hjälp utav de applikationen som finns. Om sedan en värd är hårt belastad så skulle den kunna flyttat över maskiner som har markerats som kritiska till en annan värd.

Jag skulle våga gissa att något liknande kommer att finnas i PVE den dagen Proxmox har färdat HA (High Availability) stödet. Under tiden dock så får man göra det bästa av situationen.

I en situation då man kör PVE på en större serverpark så skrev jag att man skulle kunna kört med ett flertal masters. Problemet med denna lösningen är att man förlorar stödet att migrera maskiner mellan dessa noder. Det finns så vitt jag vet inte stöd att placera en master som en slav i ett större nätverk. Om detta är ett acceptabelt problem så är bekymret löst. I annat fall så får man helt enkelt köra hela parken via ett gränssnitt.

Nästa sak jag tänkte ta upp är DRBD (Distributed Replication Block Device). Ett stycke underbarn som har blivit en del av Linux kerneln från och med v2.6.33. Att ha DRBD stöd i PVE medför ett par förbättringar.

• LVM kan köras ovanpå DRBD
• Samtliga VM diskar replikeras i realtid på båda PVE noder via nätverket
• Möjlighet att 'live' migrera maskiner utan någon downtime på ett par sekunder utan behov av ett SAN. Detta eftersom datan redan finns på målmaskinen.

Tyvärr så stöds denna trevliga lösning för stunden bara av KVM maskiner. Något som jag hoppars att Proxmox fixar tills den dagen HA stödet är klart.

För att kunna ta nytta av detta så behövs två 'identiska' maskiner som har minst två nätverkskort samt en tillgänglig RAID volym som är lika stor på båda maskiner.

Det finns ingen mening för mig att repetera processen som finns beskriven på http://pve.proxmox.com/wiki/DRBD. Men jag tänker dock nämna skillnaden mot vanliga SAN lösningar.

I en traditionell lösning så hade man använt två maskiner för att hantera SAN:et. Sedan ytterligare två maskiner för att hantera de virtuella maskinerna. Sedan behöver man ett eget nätverk för lösningen. Det vill säga ett dedicerat VLAN, mer switchar osv. Så denna lösningen kan rätt snabbt bli väldigt komplex.

Med DRBD lösningen så klämmer man in det hela på två maskiner. Med endast en patchkabel för överförging av klondatan. Denna lösning är enkel och kostnadseffektiv. Speciellt då ett SAN är dyra saker att ha i drift. DRBD ger mig en nivå av redundans som jag är nöjd med. Räcker det inte med två så får man helt enkelt sätta in fler noder.

Som en avslutning tänkte jag ta upp något av det absolut viktigaste i en servermiljö. Något man ständigt måste påpeka för folk att de skall göra. För när väl olyckan är framme så visare det sig att de självfallet inte har gjort det. Nej jag talar varken om preventivmedel eller hemförsäkringar. Utan om backup av data, speciellt kritisk driftdata.

PVE har ett inbyggt stöd för att utföra backup av VM:s på ett enkelt vis. Man väljer bara vilka maskiner man vill utföra backup på. Samt när det skall utföras och mot vilken lagringsenhet det skall skrivas. Mycket enklare än så kan det inte bli. I alla fall kan man tycka det tills man inser att den nattliga backupen växer och börjar ta allt för lång tid.

Självfallet så tog det ett tag innan jag insåg detta bekymret. Målmaskinen som vi använde som backup var inte snabb nog för att hantera den enorma floden av data som kom varje natt. Dels fanns det flaskhalsar i nätverket men på senare tid vad det mer en fråga om att få in fyra elefanter i en folkvagn. Det enklaste är ju att sätta två fram och två i baksätet. Men den lösningen fungerade inte riktigt för mig.

En av räddningarna för mig var DRBD lösningen som avlastade en del av överföringen. Den andra var att jag införskaffade ett par nyare diskar och gjorde om arrayerna till RAID 10. Detta räckte för att få upp hastigheten på överföringen till en acceptabel nivå.

Jag hade kunnat utökat ytterligare och länkat samman fler nätverkskort för ytterligare överföringskapacitet. Men detta är något jag får ta och titta på om vi sätter upp fler virtuella maskiner.

Personligen var jag väldigt skeptisk till virtualisering från första början. Det är lätt att se hur enkelt man placerar ett flertal driftkritiska maskiner på en gemensam hårdvara. Denna maskin får sedan helt enkelt inte gå sönder. Den måste ha "five nine" uptime för att inte kunder skall ringa och klaga.

Tack och väl så finns det lösningar på dessa problemen. Lösningar som alltid har funnit där. För hårdvara har alltid gått sönder, och kommer fortsätta göra så. Ett system som lider av en driftkritisk "single point of failure". Är helt enkelt ett dåligt designat system.

I ett par veckor framöver tänkte jag försöka beskriva mina erfarenheter kring virtualisering av datorer. Hur jag under en vecka förra året migrerade hela serverparken på det företaget jag jobbar. Från att köra på sex fysiska maskiner till att köra på fyra fysiska och 16 virtuella. Allt tack vare en Debian baserad lösning som kostade företaget noll kronor.

Samtliga maskiner på jobbet kör Debian, både servrar och arbetsstationer. Det finns en oskriven policy som säger att man har två val av system på sin dator, Ubuntu eller Debian. Vill man köra något annat så är man fri att göra så. Men jag finns inte tillgänglig för att lösa eventuella problem som uppstår. Det finns inte heller kapital som går att lägga på mjukvarulicenser. Vi tycker att det är trevligare att lägga de pengarna på löner och nyutveckling. Detta är en miljö som jag är mestadels skyldig för, och den underlättade väldigt mycket för mig när jag ville prova på virtualisering.

Situationen var sådan att jag hade ont om datorer. Mailsystemet, webbservern, OpenVPN maskinen, SVN arkivet med mera, låg på samma maskin. På andra maskiner rullade instanser av kundsystem som av design inte borde husera under samma tak. Detta gjorde att jag under en period när mina kolleger var på semester, utförde öppen hjärtkirurgi på hela vår serverpark.

Sedan en tid tillbaka hade jag lekt med KVM (Kernel based Virtual Machine) och tyckte väldigt mycket om lösningen. Utvecklingen skedde med rask takt och nya versioner verkade strömma till på veckobasis. På min arbetsdator hade jag vmx stöd och kunde därför leka med KVM precis så mycket som jag ville. Så det första jag gjorde var att testa Red Hats lösning för att hantera virtualiseringsparker. Virtual Machine Manager var utan tvekan ett enkelt system att komma igång med. Bortsett från ett par buggar så funkade det förvånansvärt bra. Dock så hade programmet en svaghet som jag inte kunde komma över. Det krävde att man hade virt-manager installerat på den datorn som skulle kontrollera parken.

Detta var något som jag inte gillade. Det tillhör inte ovanligheten att jag behöver kunna administrera vår serverpark utanför kontoret. Visst kan jag tunnla in med hjälp av SSH. Eller brygga mitt hemmanät med jobbet via OpenVPN. Men detta krävde fortfarande att jag hade specifik mjukvaran installerad för att kunna administrera.

En terminal hade egentligen räckt för mig. Men jag behövde tänka på de andra på jobbet. I läget då jag skulle vara ledig, sjuk eller för den delen omkommit i en tragisk zeppelinarolycka. Så behövs en system där man lätt kan förstå vad som behövs göras och hur man gör det.

Tack och väl så hittade jag ett sådant system. Till min stora förvåning så var det allt jag letade efter för stunden. Ett system som bygger på Debian och hade en "bare metal installer". Det vill säga att man installerar det från grunden på en tom burk. Proxmox Virtual Environment, eller PVE som det förkortas, är ett enkelt system som bland annat har stöd för följande saker.

• Kluster
• OpenVZ
• KVM via QEMU
• DRDB
• Automatisk backup
• Webbadministrering
• System mallar

Det finns mycket saker att vara nöjd över med det systemet. Men likt alla andra system så har det vissa brister som blev uppenbara för mig under installationen.

Det fanns tyvärr inget stöd för att placera systemet på ett mjukvaru RAID. Skulle man kräva RAID så behövs en hårdvarulösning. Något som jag är starkt motståndare till av flera olika anledningar. Problemet går säkerligen att lösa då PVE kan installeras på ett existerande Debian system. Dock så ville jag börja om från noll och var inte intresserad av att ge mig i kast med något sådant.

Vid installation så kräver även systemet att man tilldelar maskinen ett statiskt IP. Detta är säkerligen ett krav för att underlätta vid hanteringen av kluster. Men något som betydde att jag var tvungen att gå in i DHCP servern och markera den adressen som upptagen väldigt tidigt.

För övrigt så gick installationen väldigt snabbt. Maskinen som jag hade valt att utföra testet på hade följande hårdvara.

• Intel Core2 Quad CPU Q6600
• 4GB RAM
• 320GB HDD
• 10/100/1000 NIC

Maskinen var inte på något vis ett monster. Det är praktiskt taget en helt vanlig arbetsstation.

Med systemet installerat så var det dags att sätta upp mina första maskiner och se hur det hela fungerade. Tyvärr så utförde jag aldrig några prestandatester för att se förlusten av övergången till virtualisering. Detta var dock inte något allvarligt problem för mig då mitt största bekymmer var mängden maskiner, inte prestanda.

Jag hade aldrig testat OpenVZ tidigare och hade därmed ingen uppfattning över varken fördelar eller nackdelar med den lösningen. KVM hade jag däremot lekt med en hel del så mina första maskiner fick bli av den typen.

Efter att man hade specificerat saker som namn, diskstorlek, mängd RAM samt övrig hårdvara. Så var bara att välja vilken ISO avbild man ville boota från samt att starta maskinen. I min sedvanliga process så hade jag hämtat hem Debians netinstall ISO. En fil som ligger på kring 150MB och är enligt min mening det bästa sättet att installera Debian.

Maskinen startade i bakgrunden och det var bara att klicka på länken "Open VNC console" för att få upp vad den virtuella datorn tror är sin skärm. Detta krävde dock att man hade Java installerat då VNC klienten som startas är en Java applet.

För övrigt var det bara att installera som vanligt.

Det dröjde inte många timmar innan jag hade beslutat att migrera samtliga maskiner till den här lösningen. De av er som jobbar på stora företag tänker säkerligen just nu.

- Men vad *** tänker han med? Detta kräver ju minst sex månaders testning och utvärdering innan ett beslut kan fattas.

Till svar har jag bara tre saker att säga:

• Vill man få något utfört så måste det ske utan att någon ovanför har en aning om att man gör det.
• För det andra så är vi ett litet företag. Samt att jag sitter högst upp på stegen gällande drift och utveckling. Alla problem som kunde uppstå är saker som jag hade fått fixa på min fritid om något skulle gå fel.
• För det tredje, vad tror ni man har backups till .

Sagt och gjort så tog jag tag i processen, fullt medveten om att det här skulle bli ett par sena kvällar

Det första jag tänkte göra var att använda ett p2v (Physical-to-Virtual) verktyg för att konvertera existerande maskiner till virtuella. Den enda lösningen som skulle passa för mig verkade vara Red Hats "virt-p2v Live CD". Den var dock experimentell och jag kände inte för att skada något vitalt. Den andra lösningen hade varit att dd:a hela disken till en fil. Men detta skulle producerat en fil på 320GB av vilken jag nyttjar ca två procent.

Nej, den enda vettiga lösningen var att utföra rena installationer av samtliga maskiner och återskapa dem från den nattliga backupen. Visst skulle jag gå miste om ett par timmars data. Men det är inget som vårt ostabila elnät inte redan hade medfört vida andra tillfällen.

Processen att återskapa samtliga maskiner från backup är inte något som behövs beskrivas här. Däremot så finns det en hel del till att skriva om hur man hanterar kluster i PVE. Hur man hanterar migrering av virtuella maskiner mellan fysiska. Det finns en hel del att säga om vad som är bra och mindre bra gällande hur man sätter upp och kopplar all hårdvara. Men det sparar jag till nästa gång.

Som en avslutning så tänkte jag nämna priset för hårdvaran. Varje maskin gick på ungeför 5000 kronor stycket. Det är 15000 spänn för att emulera en park med 16 maskiner. Inte fy skam för en veckas arbete.

The Weta Digital har en serverhall modell gigantisk, eller "rendering wall" som dom kallar den, för att rendera 3D grafik. Med en disk array på cirka 2 Petabyte (~2097152 Gigabyte) lagring och ett 10Gigabit nätverk som binder ihop totalt 4000 bladservrar á 35.000 kärnor från Hewlett Packard blir det minst sagt en imponerande setup.

I filmen Avatar tog 1 minut video upp cirka 17,28GB data. Plötsligt känns inte 2PB lagring löjligt mycket. För att klara belastningarna som servrarna utsätts för använder man vattenkylning i serverhallen som bilden nedan visar.

Och enligt Weta Digitals systemadministratör Paul Gunn, använder man Ubuntu på så gott som alla datorer hos företaget. Ubuntu körs nämligen på alla servrar och minst 90% av deras skrivbordsdatorer uppskattas använda Ubuntu.

Mer detaljerad information finns att tillgå hos Information Management och IT World.

Källa: Jordan Hall

Impression

Night Impression

Läs mer om dessa teman på Ubuntus Wiki: https://wiki.ubuntu.com/Artwork/Incoming/Maverick/ImpressionGtkThemes

För den senaste versionen av dessa två teman, besök Wiki-sidan.

Tips: OMG! Ubuntu

http://jeffhoogland.blogspot.com/2010/06/why-ubuntu-is-harder-than-windows.html (OBS! Kan innehålla spår av ironi!)

Är det bara jag som plötsligt blev sjukt sugen muffins?

Läs mer om Lucid Lynx här:

• http://www.ubuntu.com/products/whatisubuntu/1004features
• http://www.ubuntu.com/getubuntu/releasenotes/1004

Hämta Ubuntu 10.04 LTS Lucid Lynx

• ubuntu-10.04-alternate-amd64.iso.torrent
• ubuntu-10.04-alternate-i386.iso.torrent
• ubuntu-10.04-desktop-amd64.iso.torrent
• ubuntu-10.04-desktop-i386.iso.torrent
• ubuntu-10.04-server-amd64.iso.torrent
• ubuntu-10.04-server-i386.iso.torrent

Man ansåg dock att detta inte är en optimal lösning för nybörjarna och dom utan internet, därför har man valt att lösa problemet innan man släpper lös Lucid Lynx.

Lucid förväntas komma senare idag eller imorgon. Buggrapporten hittar du här: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/570765

Kom igång med Ubuntu 10.04 är en omfattande handbok till operativsystemet Ubuntu. Handboken släpps under en fri licens och du har möjlighet att ladda ned, läsa, modifiera och dela med dig av den hur mycket du vill.

Det som förvånar mig lite är att utav videon nedanför att dömma så tycks det flyta på rätt bra, med tanke på att Ubuntu inte är anpassat för en liten smartphone med begränsad hårdvara.

Videon avslöjar dock att det inte är Ubuntu i sitt standardutförande. Man använder bland annat OpenBox som fönsterhanterare och en del standardprogram är utbytt.

Läs mer om projektet på forumet hos XDA-Developers.

Källa: Pocketnow.com

https://wiki.ubuntu.com/MReleaseSchedule

Representanter från bland annat Ubuntu, Kubuntu, Edubuntu, Xubuntu, Mythbuntu och SpreadUbuntu kom till London och arbetade med Canonical's designteam för att förfina designer och arbeta tillsammans. Resultatet av arbetet kan ni ta del av nedanför. Den nya stilen av Ubuntu drivs av temat "Light". Man har utvecklat en omfattande samling av visuella riktlinjer och behandlingar som speglar denna stil, och uppdaterar viktiga tillgångar som logotypen. Det nya temat träder i kraft i den kommande versionen 10,04 LTS, och kommer att definiera Ubuntu's utseende och känsla dom kommande åren.

Källa: Jono Bacon

Den nya loggan

Efter sex år var det dags att uppdatera Ubuntu's ansikte. Den nya loggan känns modern och stilren.

Nya GTK teman

Visuellt sett är ljusa färger vackert, luftigt och skapar klarhet och trevnad.

CD koncept

Det är inte CD-omslag för nästa utgåva, men den visar ett koncept för hur det kan se ut. Man anser att valet av den nya paletten av färger kan hjälpa dom att skapa en djärv design som hjälper dom att stå ut från andra operativsystem.

Anteckningar

Liksom de material man tillverkar och säljer/ger bort idag kommer att få ta del av det nya utseendet.

Webbdesign

Webbplatser som stödjer Ubuntu och communityt kommer också att få en uppdatering för att passa med det nya utseendet!

Boot Splash

För att fira den nya looken och paletten har man skapat en minimalistisk startupplevelse. Inte för att man ser den speciellt länge, tack vare det fantastiska jobbet som teknik-teamen gjort.

Läs mer om det nya utseendet på Ubuntu's wiki-sida.

Den nya uppdateringen har inte något spännande att bjuda på, mer än totalt 9 döda buggar.

Läs mer om milstolpen på Launchpad.

Om ni använder Ubuntu 8.04 (Hardy Heron) och inte har installerat dom nya uppdateringarna kan ni göra det via den grafiska uppdateringshanteraren eller via terminalen med dessa kommandon:

sudo aptitude update

sudo aptitude safe-upgrade

Om du har datorn igång börjar du med att starta om den, när starthanteraren GRUB startar trycker du på tangenten <Esc> för att komma in i menyn för GRUB som bilden nedanför visar.

I menyn väljer du det andra alternativet som slutar med texten recovery mode.

Här väljer du root Drop to root shell prompt.

Du är nu inloggad som användaren root och har fulla rättigheter, därmed full tillgång till allt på systemet.

För att ändra lösenordet på din användare utför du kommandot:

passwd <din användare>

Ange ditt nya lösenord två gånger och du är sedan klar.

Man behöver som standard inget lösenord för användaren root i recoveryläget, eftersom att root saknar ett lösenord. Men genom att sätta ett lösenord för root kan ingen obehörig komma åt användarkontot utan lösenordet.

För att ordna det gör vi om samma procedur som innan, fast nu för användaren root:

passwd root

Ange lösenordet två gånger. Du är nu säker från obehöriga användare, men du får nu vara noga med att inte glömma bort lösenordet.

Så här kommer det att se ut när man försöker komma åt användaren root via recoveryläget hädanefter:

Läs mer om den nya alphan hos Ubuntu.com.

Ladda hem

• Ubuntu Desktop and Server
• Ubuntu Server for UEC and EC2
• Ubuntu ARM
• Kubuntu
• Xubuntu
• Edubuntu
• Mythbuntu

UNetbootin finns tillgängligt både för Linux och Windows. Om du har Ubuntu installerar du det via förråden med kommandot:

sudo aptitude install unetbootin

Annars laddar du hem det här för Linux eller om du har Windows.

Läs hela testet hos Phoronics.

För er som inte orkar plöja igenom testet, får ni en kort sammanfattning: Prestandaförlusten med PAE-kärnan är obefintlig medans 64-bit kärnan var märkbart snabbast av dom alla.

Den som installerade skärmsläckaren fick aldrig någon skärmsläckare, utan en trojan i form av ett skript som laddar hem ett par olika skript. Skripten har tydligen uppdaterats och diskutionen om vad skripten har gjort har varietat lite. Några pratade om att offrets dator blev förberedd för en DDoS attack (Denial of Service) och en annan sak som är bekräftat var att ett kommando som skulle ta bort hela root-filsystemet för Ubuntu, dock var kommandot felskrivet så det var rätt harmlöst.

Läs mer om händelsen på Ubuntu Forums.

Det hela verkar vara ett verk av en amatör eftersom han inte ens fick till "rm" kommandot rätt. Skärmsläckaren och användaren blev snabbt borttaget från GNOME-Look, men om du har installerat denna skärmsläckare rekomenderas det att du utför följande kommando:

sudo rm -f /usr/bin/Auto.bash /usr/bin/run.bash /etc/profile.d/gnome.sh index.php run.bash && sudo dpkg -r app5552

[warning]Kör inte kommandot om du inte har intallerat "skärmsläckaren".[/warning]

Att tänka på

GNU/Linux är omtalat för att vara säkert, vilket det är. Men inget operativsystem är säkarare än vad användaren gör det! Mitt råd är att inte installera alla DEB-filer du ramlar över, även om ovan fall är ovanligt så förekommer det. Risken finns ju att du installerar något du inte räknat med.

Så innan du installerar en DEB-fil från en osäker källa tänk en extra gång. För att vara helt säker ska du hålla dig till Ubuntu's officiella förråd och PPA-förråden från Launchpad.

Det finns en intressant tråd som jag rekomenderar att du läser på Ubuntu Forums: Ubuntu Security, den är skriven av en forumadmin och täcker en del intressanta saker gällande säkerheten.

Om man vill slippa denna extra knapptryckning kan man göra en enkel liten ändring med Gconf. Detta värde ändrar man enklast med dessa kommandon:

Invaktivera fördröjning:

gconftool-2 --set /apps/indicator-session/suppress_logout_restart_shutdown --type string "true"

Aktivera fördröjning:

gconftool-2 --set /apps/indicator-session/suppress_logout_restart_shutdown --type string "false"