Ik dacht dat het triviaal was, maar men doet het bijna altijd verkeerd.
Dus hier is iets om in uw oorkes te knopen:

Een RAID volume mag je NIET partitioneren! (Disk partities, zoals met fdisk.)

Natuurlijk kan je dat wel doen, en zo goed als altijd doet men dat ook, maar dat is dus helemaal niet de bedoeling.
Hier is waarom:

We gaan ervan uit dat we een hardware RAID controller gebruiken in RAID-1 (Mirroring) met 2 harde schijven.
Er zijn 2 partities, een O.S. partitie, en een Data partitie.

NUMA, staat voor Non-Uniform Memory Access, en is een serieus security issue.

Vroeger zat er op je moederbord 1 CPU, en alles was goed.
Als je meer rekenkracht nodig had, dan bouwde je een cluster: Meerdere complete systemen gelinked met elkaar.

Tegenwoordig hebben veel systemen, en zeker servers, meerdere CPU's en is memory access een probleem geworden...

Er zijn veel hosting providers die een backupsserver aanbieden die toegankelijk is via FTP.
Er is zelfs betalende software die de data van jouw PC overdraagt naar een FTP server.

Dit is dus weer iets dat ik helemaal niet begrijp.

FTP is een insecure protocol: De login data is zichtbaar voor iedereen, Sessies kunnen gehijacked worden, Bestanden kunnen gecaptured of gewijzigd worden.
(Zeker voor machines in een datacenter.)

Kleine, maar ondoordachte, wijzigingen kunnen soms grote gevolgen hebben.
Ik denk dat iedereen het daar mee eens is.

Ook ik kan hier van meespreken...

Ik gebruik intern een DHCP server om alle computers in huis van hun configuratie te voorzien.
DHCP wordt het meest gebruikt om hosts dynamisch een IP adres toe te kennen, maar er zijn nog veel meer mogelijkheden.

En daarmee bedoel ik niet massaparkeren op de autosnelweg, maar het Linux commando "file".

Het file commando geeft informatie over een bepaald bestand:

# file /etc/hosts
/etc/hosts: ASCII text

# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1,
dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped

Het commando kan ook leuke informatie weergeven over allerlei bestanden, bijvoorbeeld de resolutie van images, videobestanden, etc...

Als je VPNs opzet, site-to-site of VPNs voor clients, dan gebruik je natuurlijk certificaten i.p.v. shared-keys.
Het nadeel is dat dat een dure grap wordt, tenzij je een beetje moeite doet om zelf een PKI infrastructuur op te zetten.
En dat laatste is vrij eenvoudig met "Easy RSA".

Veel mensen denken te weten waarom een Journaling File System dient: Om filecorruptie te vermijden als een volume niet netjes afgesloten wordt. (Bijvoorbeeld bij een crash.)

Helemaal fout!

Een Journaling File System probeert om filesystemcorruptie te vermijden als een volume niet netjes afgesloten wordt.
Dit is een belangrijke nuance.

Op mijn werk gebeuren er soms leuke dingen.
Zo ook deze morgen...

Turkije loopt een uur voor op België.
Er ligt een VPN tussen België en Trukije.
Ik beheer de VPN connectivity en een gedeelte van de netwerkinfrastructuur in Turkije.
Turkish Telecom is de grootste telecom operator, en ook bijna de enige deftige ISP.

2008/01/22 20:00h GMT

SSH is onmisbaar om een Linux systeem vanop afstand te installeren of te beheren.

Meestal is SSH echter zo geconfigureerd dat de server een wachtwoord vraagt. Dit kan natuurlijk veiliger, maar ook handiger omdat je nu voor iedere nieuwe verbinding je wachtwoord opnieuw moet ingeven.
Dat laaste zorgt er dan weer voor dat mensen een makkelijk en snel te typen wachtwoord kiezen...

Natuurlijk bestaat er een oplossing, namelijk publickey authenticatie.

Hier is hoe:

Als je netwerkapparatuur om de een of andere reden "inline" moet plaatsen (IDS, IPS, proxy, traffic shaper,...) is dat soms een risico, want als dit apparaat zou falen, dan wordt de netwerkconnectie onderbroken.
Gelukkig is daar een oplossing voor...

De kogel is door de kerk.

In opvolging van
http://blog.knudde.be/NAS+Server
http://blog.knudde.be/NAS+Server+II

Ik moet toegeven dat mijn originele eisen niet haalbaar waren.
Het was zo'n beetje als het overbekende "goed, snel, goedkoop" dilemma. Je kan er maar 2 hebben...

De originele eisen waren:

Computers worden steeds sneller.
Gelukkig maar, want blijkbaar worden gebruikers en programmeurs steeds dommer en dommer.
Om de een of andere reden proberen ze altijd alles op de meest onefficiënte manier te doen.

<plof!>

Je hebt net een computervoeding horen ontploffen.
Jammer genoeg is ook het moederbord mee ontploft.
Server down.

Na de nodige herstellingswerken, wilde het systeem natuurlijk niet correct booten vanwege inconsistenties in de logische partities. Geen probleem, want daarvoor dient "fsck".

Helaas wilde de "normale" kernel niet booten, want die heeft dingen nodig die op de corrupte partitie staan.

Dus je wil een mailserver opzetten?
Hopelijk niet, hopelijk wil je er minstens 2.

Om mailexchangers op een redundante en loadbalancing manier op te zetten, zijn er 2 mogelijkheden. (Er zijn er meer, maar deze zijn eigelijk varianten op een van deze principes.)

Hetgeen je kiest, hangt af van je voorkeur, en die hangt natuurlijk af van hetgeen jij belangrijk vindt.
DNS is zeer belangrijk bij het opzetten van een redundant email infrastructuur, maar dat wist je al, hoop ik.

Multiple MX records