Johan_G

Bara ett litet klargörande:
Problemet består i att root-servrar och topp-domänservrar börjat skicka ut AAAA (quad A) records som har med IPv6 att göra. BIND försöker då kontakta dom med IPv6, men de flesta saknar idag IPv6 routing vilket gör att frågan till slut får time-out. Denna time-out är på några sekunder.

Lösningen är normalt att starta named-processen med flaggan -4 så att den endast använder IPv4. Tyvärr krävs BIND 9.2.5 eller senare för att kunna skicka med det argumentet. Mac OS X Server kör 9.2.2 eller något likande.

Så man måste tyvärr hämta källkoden för BIND, kompilera och byta ut named samt ändra i startkonfigurationen så att argumentet -4 skickas med. Vi har gjort det på vår server, och det fungerar! Alternativet är att sätta upp DNS:en som en forward DNS, vilket är att låta någon annan ta hand om problemet
Detta är också buggrapporterat till Apple, så vi får hoppas på enklare lösning i framtiden.

Kan nämna att det inte bara är vi som har detta problem. Alla som kör BIND råkar ut för samma sak. Sök lite på olika Linux forum får ni se.

Allt tyder på att detta kommer att lösas inom kort, tro mig

Du kan uppnå effekten av att interna användare inte behöver logga in på något av följande sätt:
- Spara namn och lösenord på användarnas nyckelringar.
- Om du har en Open Directory Master kan du med MCX-settings ange att servervolymer automatiskt skall monteras när användarna loggar in.
- Om din servervolym delas ut av Open Directory Master, och dina användare är Network- eller Mobile Users (eller har Kerberos aktiverat på annat sätt), får du Single Sign On, d.v.s. att användarna varken behöver ange namn eller lösenord när de ansluter till servervolymen.

Det kanske mest korrekta sättet att göra gruppmails-adresser är att använda "postfix style aliases" så som dokumentationen beskriver (sid 42):
http://images.apple.com/server/pdfs/Mail_Service_v10.4.pdf

Om man är lite finurlig kan man scripta upp skapandet av gruppmails-alias. Jag gjorde ett sådant script för en kunds räkning för ett tag sedan. Scriptet läser alla OD-grupper med id-nummer inom ett visst intervall (man kanske inte vill att alla grupper automatiskt skall bli mailgrupper?) och skapar sedan en postfix alias fil. Scriptet kan enkelt schemaläggas att köras regelbundet.

/etc/resolv.conf är en länk som pekar på /var/run/resolv.conf
configd skriver till /var/run/resolv.conf - inte direkt till /etc/resolv.conf
Kanske att något kan ha hänt med länken, eller att något med behörigheterna?

Så här ser det ut på min maskin:
lrwxr-xr-x 1 root wheel 20 Apr 23 19:40 /etc/resolv.conf -> /var/run/resolv.conf
-rw-r--r-- 1 root daemon 20 Sep 14 19:07 /var/run/resolv.conf

Arkivera och installera?

Det skall fungera att bara följa instruktionerna i dokumentationen.
http://images.apple.com/movies/euro/euro/server/documentation/pdfs/2005/Open_Directory_v10.4.pdf

Läs på sidan 83 och framåt...

Ursäkta, men jag har vid ett flertal tillfällen använt ACL:er för att åstadkomma det ni vill göra. Fungerar alldeles utmärkt! Lita emellertid inte alltid på hur behörigheterna visas från klienten. Använd "Effective Permissions inspector" i Workgroup Manager så skall ni att det blir rätt! ... och testa.

Och, visst vore det bra om "Inherit Permissions from parent" för AFP fixades till! Vore lite lättare då...

Ja, du kan addera på diskar till ett befintligt RAID-set så länge du håller dig på samma controller. Du kan alltså bygga ut med upp till ytterligare 3 diskar om du har 4 från början.
Sidan 38 i den här PDF:en
http://images.apple.com/server/pdfs/RAIDAdmin1.2-UserGuide.pdf

http://images.apple.com/server/pdfs/High_Availability_Admin_v10.4.pdf
Ja, vet att det är jobbigt att läsa dokumentation, men faktum är att svaren finns där!

Läs sidorna 115-116 i denna PDF, så hittar du svaret:
http://images.apple.com/server/pdfs/User_Management_Admin_v10.4.pdf

Varför sym-länk? Skapa en mapp på din andra disk, gör den till en automonterad SharePoint så dyker den snällt upp i listan i användarnas Home-flik i WGM. Bara att välja!

PS. Det absolut vanligaste felet när man vill sätta upp en miljö för Network Users är att man glömmer att skapa ett Network Mount Record för SharePointen där hembiblioteken skall ligga.

Jag netbootade några maskiner förra veckan för en enkel demo. Shadowfilerna blev 48MB. Skälet att köra diskless är om du vill plocka bort hårddisken i klientmaskinerna. Annars finns det inga "fördelar".

Skillnaden mellan NetBoot och NetInstall? NetBoot bootar hela datorn från en diskimage på servern. Det behövs ingenting, inte ens en disk på klientmaskinen. NetInstall gör samma sak, men istället för att starta LoginWindow, Finder, Dock mm så startar den installeraren så att du kan installera det som är på din imagefil. Detta kan vara antingen ett komplett system eller enstaka filer/program.

Bästa rådet jag kan ge är att kolla på Mike Bombichs sida:
http://www.bombich.com/software/netrestore.html

Ladda ned NetRestore och läs sedan den medföljande dokumentationen. Speciellt avsnittet Setting up a NetInstall-Restore solution. Där har du förklaringar och nyckeln till att bygga en perfekt lösning! Dock är det kanske lite overkill för dina 10 eMac:ar? (om du inte behöver blåsa maskinerna en gång i veckan?) Köp annars en liten FireWire hårddisk och installera Mac OS X på den. Sedan kan du antingen använda Mac OS X:s skivverktyg eller NetRestore från den. ARD är perfekt för det löpande underhållet!

Om du väljer att köra diskless kommer en temporär s.k shadow fil skapas på servern. Den är dock långt ifrån lika stor som själva image-filen eftersom den bara innehåller de förändringar användarna gör under sin session.
Om du däremot väljer att inte köra diskless kommer den netbootade klientens interna hårddisk att användas istället för serverns.

dig går också använda för att testa DNS. I Tiger är det faktiskt dig som används i Lookup fliken i Nätverksverktyget, så man behöver inte ens använda Terminal. I svaret från dig ser man både vilken DNS server som tagit reda på svaret åt dig, samt hur lång tid frågan verkligen tog.

Ja, om din DNS server inte har svaret i sin cache, eller är uppsatt att forwarda alla DNS förfrågningar till en annan server kontaktar den alltid root servrarna, för att sedan rekursivt lösa din förfrågan.

En liten detalj man kanske bör beakta är att verktyg som dig, host och nslookup kontaktar DNS servern direkt. I Mac OS X är lookupd DNS resolver, vilket innebär att det är den som kontaktar DNS servrarna (efter att först ha tittat i sin egen cache och /etc/hosts.. i normala fall).
Det skiljer alltså lite på hur DNS uppslag går till beroende på om man använder Lookup-fliken i Nätverksverktyget, eller om man knappar in en URL i t.ex. Safari. Jag har dock aldrig varit med om att detta skapat problem på något sätt.

Dock borde du knappa in statiska entries i /etc/hosts på din klient istället för att göra det i DNS:en. Om du nu absolut vill testa? Jag skulle personligen aldrig göra det, eftersom du utan tvekan kommer att få problem den dag någon gör en förändring. Förändringar är vanligare än man tror!

Att sätta upp din DNS som en fowarding (eller caching) DNS är en mycket bra idé, men det bästa du kan göra är faktiskt att se till att besöka din välbesökta sidor så ofta du kan Då säkerställer du att de alltid finns i din cache.

Ett annat rätt användbart tips, som kräver lite Terminal-knappande:
Skicka ett ping till broadcast adressen på nätverket. Om du inte vet vad broadcasten är kan du skriva:
ifconfig en0
(en0 = Inbyggt Ethernet. broadcast adressen står i output:en)

Skriv sedan:
ping -c 1 10.0.1.255
(byt ut 10.0.1.255 mot din broadcast adress)

Det fiffiga med detta är att datorn nu lägger in, inte bara ipadresserna utan även MAC-adresserna i arp-cachen. Denna cache lagrar detta för de senaste datorer du pratat med, och genom att pinga broadcast har du faktiskt pratat med alla på ditt subnät (inte bara datorer dock) Genom att lista arp-cachen får du fram allt du behöver:
arp -a

Enkelt!