Vilken metod använder ni när ni administrerar era servrar?

Har ni fysisk åtkomst till dom med skärm/tgb/mus direkt kopplat eller använder ni nåt verktyg typ OnCommand? VNC? SSH? Kör ni rentav thinlinc? Isf hur når ni just *den* servern ni vill in och skruva på?

Själv använder jag mest SSH, ofta med X, för att nå consolen på master-servern får jag köra virtuellt skrivbord via HP IOS i webbläsaren, funkar bara "sådär"....

/H

Mastern ligger i VmWare så den kör jag via Virtualcenter i någon form. Agenterna släpar jag mig till serverrummet för att pilla på, 1 gång i månaden eller vad det kan vara fråga om. Ska väl sätta upp ILO framöver och se om det kan funka dugligt.

Nu har vi på Cendio inte några stora skarpa ThinLinc-kluster (vi har
två ThinLInc-servrar á en server vardera - ett internt, och så
demosystemet). Båda administrerar vi via SSH + https (Webmin). I
förekommande fall testar man ju också att logga in med
ThinLinc-session för att kolla att det man ändrat funkar som det ska.

Men, denna brist på stora kluster hindrar mig inte från att ta
tillfället i akt och orera lite om hur jag skulle administrera ett
större ThinLinc-kluster om jag hade ett .

Som vanligt vid systemadministration gäller att en gyllende regeln är
AUTOMATISERA ALLT! Har man gjort något ordentligt en gång så behöver
man inte göra det igen. En annan gyllende regel är ÖVERVAKA ALLT. Har
man haft ett fel och identifierat orsaken, så justerar man sin
övervakning så att man upptäcker att felet är på väg att hända innan
det händer nästa gång.

Till att börja med skulle jag se till att ha två ThinLinc-kluster:

 * Ett litet kluster på två eller tre maskiner att testa med. Det här
   klustret kan man med fördel köra i en virtuell miljö, exempelvis
   VMware, Xen eller KVM.

 * Det andra klustret är det skarpa klustret med många maskiner. Det
   kör man med fördel "på metallen", för att få ut så mycket prestanda
   som möjligt från varje maskin.

Som hjälpmedel i administrationen skulle jag använda tre verktyg:

 * Ett versionshanteringssystem, exempelvis subversion. Det använder
   man för att hålla ordning på de ändringar man gör.

 * Ett konfigurationshanteringssytem för servrar, och här är nog min
   favorit den fria programvaran Puppet. I Puppet definierar man all
   konfiguration, exempelvis vilka paket som ska vara installerade på
   en agent, hur /etc/asound.conf ska se ut, hur /etc/fstab ska se ut,
   etc. etc. Konfigurationsfilerna för Puppet hanterar man i
   subversion, så att man blir tvungen att dokumentera varför man gör
   en ändring, och automatiskt får dokumentation på exakt vilken
   ändring som gjordes, vem som gjorde den, och när den gjordes.

 * Ett övervakningssystem, och här är min favorit gratisprogramvaran
   Nagios. Här kan man lägga upp övervakning över att maskinerna är
   uppe, att deras diskar inte är på väg att bli fulla, att de inte
   har några processer som är i konstiga state, m.m. Med lite klurande
   kan man till och med få Puppet att skriva konfiguration för Nagios,
   så att en ny maskin i klustret automatiskt läggs till även i
   Nagios.

I övrigt så skulle jag se till att sätta upp infrastruktur för att
nätinstallera den Linuxdistribution som kör på mina ThinLinc-servrar.

Givet ovanstående, hur gör man då vanliga dagliga
adminstrationsuppgifter?

Installera ny programvara på klustret:

 * Installera programvaran i testklustret. Modifiera
   konfigurationsfiler och se till att det funkar som det ska. När man
   ändrar en konfigurationsfil så ser man också till att ändra i
   Puppets konfiguration så att ändringen kommer att slå igenom när
   man kör på riktigt. Dvs, om man har gjort någon inställning i
   gconf för en viss applikation så säger man åt puppet att
   kontrollera om den inställningen är korrekt, och annars göra den.

 * Be eventuellt användare att testa, mot testklustret.

 * Checka in ändringarna i Puppet-konfigurationen i subversion.

 * Testkör eventuellt puppet-konfigurationen på en andra maskin för
   att kontrollera att ändringarna faktiskt blivit korrekt definierade
   i Puppet.

 * Checka ut puppet-konfigurationen på det skarpa klustret. Säg åt
   puppet att uppdatera alla maskiner.

 * Klart!

Ändring av någon konfigurationsvariabel går till på samma sätt som
ovan.

Lägga till en agent i klustret:

 * Lägg till maskinen i Puppets konfiguration.

 * I en riktigt ideal värld så är även DHCP-servern (delvis) styrd av
   puppet, så att man när man lagt till maskinen i Puppets
   konfiguration automatiskt får ett entry i DHCP-servern med rätt
   MAC-adress och fast tilldelning av IP för maskinen.

 * Boota maskinen från nätet. Eftersom man har fixat så att
   Linuxdistributionen kan installeras från nätet så installeras nu
   Linuxdistributionen automatiskt. Det är bara en basinstallation med
   relativt få paket som installeras, resten sköts av Puppet.

 * I postinstallscript vid installation har man definierat att
   puppet-klienten ska köras igång och kontakta puppetmaster, vilket
   sker. Här måste man godkänna klientens kryptonyckel för att
   puppetmaster ska godkänna klienten.

 * Maskinen kommer nu att installera all programvara som
   Puppet-konfigurationen säger ska installeras, inklusive korrekt
   konfiguration. Om man har gjort rätt så kommer inte VSM Agent att
   startas förrän maskinen faktiskt är klar att använda.

 * VSM Server-konfigurationen kan man eventuellt hantera manuellt,
   alternativt kan den nya agenten automatiskt läggas till listan över
   agenter i vsmserver.conf.

Fixa till en maskin som varit nere ett tag:

 * När maskinen bootar körs puppet, så eventuella
   konfigurationsändringar och paketuppdateringar som gjorts under
   tiden maskinen var nere appliceras automatiskt.

Uppdatera linuxdistributionen i klustret:

 * Uppgradera eller nyinstallera i testklustret. Fixa allt som blivit
   knasigt och se till att puppet-konfigurationen är rätt.

 * Om man nyinstallerar så nätbootar man alla maskiner i klustret och
   får automatiskt ny konfiguration.

Ungefär så. Kräver naturligtvis en del jobb för att få till perfekt,
men man kan spara en väldig massa tid i längden!

Jag har testat en grej som verkar riktigt "fiffig" om man som vi har bladeservrar där det inte finns någon fysisk grafisk konsol.... (man använder istället webläsaren och Java mot ILOt's ip, segar som tusan... mest irriterande faktiskt)

Man kör igång vsmserver på agenterna och i vsmserver.hconf på resp. agent anger 127.0.0.1 som "terminal server" (vsmagent.hconf har den "riktiga" masterns ip som master) så kan man logga in direkt till den agentserver man vill nå... bara ange agentens ip/namn så kommer man in på den server man vill till.

Jag har kört såhär i någon vecka nu, och har inte upptäckt några problem med det ännu.... men nu snart är det helg och jag ska hem och svetsa en grill!

Tvungen att lägga till ett nytt sätt som jag just provat, MidpSSH.

Fruktansvärt trevligt att kunna SSHa in för att starta om en tjänst etc lite snabbt, direkt från mobilen.