<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">
   <channel>
      <title>Kris Lowet - Linux</title>
      <description>Vrijgegeven handleidingen en artikels m.b.t. Linux en Open-Source.</description>
      <link>http://www.krislowet.be</link>
      <copyright>(c) Kris Lowet</copyright>
      
      <language>nl-be</language>
      <category>Linux - Open-Source</category>
      
         <atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/KrisLowet-Linux" /><feedburner:info uri="krislowet-linux" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><creativeCommons:license>http://creativecommons.org/licenses/by-sa/2.0/</creativeCommons:license><item>
            <title>Back-up van een desktop computer / laptop naar een externe harde schijf</title>
            <description>Net zoals systeembeheerders hebben thuisgebruikers ook een laksheid aan back-uppen. Toegegeven, het is voor velen ruim gezien ook een saaie bedoening, echter ook een noodzakelijk iets. Iedere thuisgebruiker heeft op zijn of haar computer wel een groot aantal bestanden staan die men liever niet kwijt geraakt. Dat kan gaan van documenten van het werk of op school, tot herinnering foto's van de geboorte van een eerste spruit. Het kunnen bestanden zijn met een grote emotionele waarde, maar ook met een grote financiële waarde.
Het is dan ook absoluut noodzakelijk om doordacht te back-uppen. Dit document beschrijft een back-up script wat ik geschreven heb om eenvoudige werkcomputers of laptops naar een externe harde schijf te back-uppen.

Ik ben uitgegaan van een computer met daarop het OS Ubuntu 9.04.

Dit script is te downloaden op http://www.krislowet.be/scripts/backupPull.sh&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/Qzyb1kar6W0" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/Qzyb1kar6W0/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 20:21:19 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=25</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=25</feedburner:origLink></item>
         
         <item>
            <title>Remote server back-up m.b.v. Rsync over SSH en groeperen op nacht / dag / week / maand</title>
            <description>Back-up. Een kort woord, een woord met veel betekenis, maar eveneens een doe-woord wat in vele gevallen niet actief wordt uitgevoerd. Een woord dat nog al te vaak gezien wordt als een noodzakelijk kwaad, in plaats van een noodzakelijk iets. Door laksheid van zowel systeembeheerders als thuisgebruikers verdwijnen nog al te vaak belangrijke bestanden van de harde schijven.

Met de juiste programma's en een kleine moeite om de configuratie ervan te overlopen kan back-uppen echter heel eenvoudig zijn. Hierbij denk ik aan volwaardige programma's zoals BackupPC en Bacula. Voor kleinere netwerken kan men ook werken met eenvoudigere toepassingen zoals Rsnapshot, gebaseerd op Rsync.

Het grote verschil in het maken van back-ups is de wijze waarop back-ups van de client naar de back-up server worden overgebracht. De twee mogelijkheden hierbij zijn de volgende: de client duwt zijn te back-uppen bestanden richting de back-up server, of de back-up server trekt de gewenste bestanden uit de client. Beide mogelijkheden hebben hun voor- en nadelen.

Persoonlijk kies ik voor de tweede mogelijkheid: de back-up server trekt de bestanden uit de client naar zich toe. Deze keuze heb ik gemaakt omwille van het feit dat de publieke sleutel van de server gedeeld moet worden met de client en zodoende de back-up server de client kan benaderen, maar niet omgekeerd.

Een ander groot voordeel bij deze manier van werken is dat de back-up server zelf bepaald wanneer hij de back-ups van de verschillende clients zal binnenhalen en er zodoende geen overbelasting kan komen wanneer 10 clients tegelijkertijd hun bestanden willen overbrengen.
Men kan Rsync geen complete back-up oplossing noemen, maar het is een prachtig stukje software dat zijn diensten in het verleden al meermaals bewezen heeft. Op basis van Rsync heb ik in Bash een eigen back-up script geschreven om eenvoudig een back-up te maken van Linux (Ubuntu) clients (servers) binnen een netwerk.

Dit script is te downloaden op http://www.krislowet.be/scripts/backupPull.sh&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/puE2faEh3oE" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/puE2faEh3oE/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 20:20:02 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=24</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=24</feedburner:origLink></item>
         
         <item>
            <title>De veiligheid van draadloze WEP en WPA(2) netwerken</title>
            <description>Sinds enkele jaren blaast men hoog van de toren dat een WEP beveiliging van draadloze netwerken achterhaald is en men overal gebruik zou moeten maken van WPA(2).

Wanneer ik de configuratie van een doorsnee huis-tuin-en-keuken router nader bekijk zie ik dat, zelfs de hedendaagse nieuwe toestellen, nog steeds de WEP beveiliging optie aan boord hebben. Is WEP dan werkelijk zo zwak als men beweerd?

Enige tijd geleden had mijn buurman problemen met zijn draadloze netwerk. De configuratie nader bekeken zag ik dat men gebruik had gemaakt van WEP beveiliging. Deze configuratie was opgezet door installateurs van een niet nader te noemen grote internet service provider op de Belgische markt.

Ik ben geen beveiligingsexpert maar ik wilde de uitspraken over de zwakheid van WEP die overal rondgestrooid wordt toch eens aan de praktijk toetsen. Nadien ben ik ook gaan kijken naar de sterktes en zwaktes van WPA(2). Alle tests in dit document heb ik uitgevoerd op mijn persoonlijk (draadloze) netwerk.&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/v42tvIphZc0" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/v42tvIphZc0/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 18:42:38 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=23</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=23</feedburner:origLink></item>
         
         <item>
            <title>Squid HTTP cache proxy</title>
            <description>Snelheid. Daar draait het allemaal om wanneer er gebruikt gemaakt wordt van een cache proxy. Alle pakketjes moeten vlug bij de gebruiker zijn. Ook komen we uit een tijd waarin we te maken hadden met harde datalimieten die de ISP's hun klanten oplegde - en die tijd is trouwens nog niet volledig voorbij!

Laat ons eerlijk zijn, het is ook onnodig om x aantal keer diezelfde foto van het internet te gaan downloaden. Stel: 20 collega's krijgen op kantoor dezelfde mail aan met daarin een link naar een online fotoalbum met 50 foto's van de barbecue van vorige maand. Als iedere foto 1MB bedraagt en alle collega's alle 50 foto's bekijken, dan zou er op het einde van de rit maar liefst 1000MB aan data gedownload zijn. Dit is eenvoudigweg absurd.

Wanneer het kantoor daarentegen gebruik maakt van een cache proxy, dan worden die 50 foto's slechts 1 keer gedownload. Dit wilt zeggen: in plaats van 1000MB wordt er dan 50MB gedownload. De collega's die diezelfde foto's willen bekijken krijgen deze geserveerd van de cache proxy die lokaal staat opgesteld, zonder dat zij hier iets van merken, dit proces gebeurt transparant.

Een groot verschil voor wie de factuur van de ISP moet betalen, de foto's worden vlugger getoond aan de gebruikers, de internetverbinding geraakt niet overbelast met enkel en alleen foto's en er treed geen netwerkvervuiling op.

Het nut van een cache proxy lijkt me nu wel duidelijk. Op volgende pagina's ga ik bespreken hoe je zo een cache proxy kan opzetten.

Het voorbeeld wat ik zal gebruiken, wordt ook ingezet op Ubuntu release party's.&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/SibyQTE8BFw" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/SibyQTE8BFw/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 18:41:43 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=22</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=22</feedburner:origLink></item>
         
         <item>
            <title>Software en Fake RAID 0 / RAID 1 Benchmarks</title>
            <description>Het verschil tussen RAID 0 en RAID 1 veronderstel ik dat gekend is.
Als je voor veiligheid kiest, ga je resoluut voor RAID 1. RAID 0 kan data echter vlugger wegschrijven en terug uitlezen. Maar wat is nu het effectieve prestatie verschil?

Ik heb een vers geïnstalleerd 64bit Ubuntu 8.10 systeem aan enkele benchmark tools onderworpen om het bestandssysteem (EXT3) te testen. De resultaten volgen hieronder. Er draaide geen andere programma's tijdens de tests.

Ik heb het verschil gemeten tussen zowel Software RAID 0 en Software RAID 1 als Fake RAID 0 en Fake RAID 1. Ook heb ik het verschil in tijd gemeten voor een herstelling van een Software- als een Fake RAID 1 array. Als laatste heb ik de tests uitgevoerd op hetzelfde systeem maar met slechts één harde schijf.

Als Fake RAID controller heb ik gebruik gemaakt van de Dell SAS 6IR op een PCI-Express poort. Deze kaart heeft een snelheid van 3GB/s per poort.&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/APCbkGoNhVE" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/APCbkGoNhVE/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 18:41:12 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=21</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=21</feedburner:origLink></item>
         
         <item>
            <title>Linux Terminal Server Project</title>
            <description>Linux Terminal Server Project (LTSP) is een toepassing dat op servers geïnstalleerd wordt om thin clients van een besturingssysteem te voorzien. Door middel van een netwerkkaart kunnen thin clients verbinding maken met de server, op voorwaarde dat de netwerkkaart PXE ondersteunt.

LTSP kan ingezet worden in bijvoorbeeld scholen of KMO's. Een groot voordeel voor de systeembeheerder is dat hij zich slechts over één systeem (de server) moet buigen i.p.v. bijvoorbeeld 20 PC's te onderhouden. Een ander voordeel is de kostenbesparing op energie; omdat thin clients geen bewegende onderdelen (ventilatoren, harde schijven, CD-Rom stations) aan boord hebben en bijgevolg zeer weinig stroom verbruiken.

Een thin client is dus een minimale PC zonder harde schijf. Het besturingssysteem wordt via het netwerk vanaf de centrale server geladen. De programma's die op de server geïnstalleerd zijn, zijn ook rechtstreeks toegankelijk voor de gebruikers achter de thin clients. De bestanden van de gebruikers worden eveneens op de server opgeslagen.

In dit artikel zal ik bespreken hoe een LTSP-server gebruiksklaar gemaakt wordt.&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/ADqrXPbhAyA" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/ADqrXPbhAyA/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 18:40:18 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=20</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=20</feedburner:origLink></item>
         
         <item>
            <title>EXT en EXT 4 benchmarks</title>
            <description>Sinds enkele jaren is men aan het bouwen aan EXT4, de opvolger van het veelgebruikte EXT3. In oktober 2008 is EXT4dev uit de ontwikkelingsfase gekomen en heeft het de naam EXT4 gekregen.

In dit artikel geef ik de verschillen weer tussen EXT3 en EXT4 op Ubuntu 9.04. Ook  heb ik ubuntu 9.04 op EXT4 geïnstalleerd op een RAID0 indeling.&lt;img src="http://feeds.feedburner.com/~r/KrisLowet-Linux/~4/GV0-g4eZXRU" height="1" width="1"/&gt;</description>
            <link>http://feedproxy.google.com/~r/KrisLowet-Linux/~3/GV0-g4eZXRU/downloadbestand.php</link>
            <pubDate>Tue, 14 Dec 2010 18:37:58 +0100</pubDate>
            <guid isPermaLink="false">http://www.krislowet.be/downloadbestand.php?id=19</guid>
         <feedburner:origLink>http://www.krislowet.be/downloadbestand.php?id=19</feedburner:origLink></item>
         
   </channel>
</rss>

