---

Jeg er ved at gøre min server lidt mere sikker og "ren". I den forbindelse
har jeg kikker på hvilke system services den kører. Jeg har funden en list
over services som jeg ikke umidbart ved hvad er, og om jeg må lukke.

Er der evt en der vil kommentere lidt på listen, eller ved om der finden en
side der fortæller om de forskellige services. Det er RedHAt 7.3 jeg kører.

Listen:

anacron (Jeg ved hvad cron er, men hvad med denne?)
apmd
atd
autofs (Der er flere med "fs" hvad er det?)
gpm
isdn (Er der hvad jeg tror det er? Jeg kører med en kabel modem)
lpd
netfs
nfslock
rawdevices
rhnsd


--
Mvh
Anders Lund
Anders@zaimGED.dk
Fjern geden fra min signatur!

---

On Sat, 28 Sep 2002 23:04:50 +0200, Anders Lund <Anders@zaimGED.dk> wrote:

Det er der ikke nogen der gider at svare på. freshmeat.net lader dig
passende finde ud af det selv.
>
> autofs (Der er flere med "fs" hvad er det?)
Den skal dog nok findes på google
> netfs
Ditto
> nfslock
Låsning til nfs
> rawdevices
dunno - google
> rhnsd
er SVJV Redhat Name service daemon. Min erfaring med den, er at den ar
fyldt med kedelige og dumme fejl.

--
Jesper

---

On Sat, 28 Sep 2002 21:12:54 +0000, Jesper Louis Andersen wrote:

> Min erfaring med den, er at den ar
> fyldt med kedelige og dumme fejl.

Det lyder ligesom noget jeg engang kom til at installere.. det hed Windows
? :)

--
,''`. Michel Komischke
: :' :
`. `' http://streetwise.dk
`- http://newbie.linux.dk

---

Anders Lund wrote:

> anacron (Jeg ved hvad cron er, men hvad med denne?)

Er en erstatning for cron, når maskinen ikke står tændt hele tiden.
Den behøves ikke på en server.

> apmd

Det er en dims, der normalt bruges på bærbare for at spare strøm.
Den må IKKE køre på en stationær maskine, da det den så får diskene
til at spinde op og ned hele tiden og dermed forkorter deres leve-
tid drastisk.

> atd

Bruges til at udføre kommandoer på et bestemt tidspunkt. Helt
uskadelig.

> autofs (Der er flere med "fs" hvad er det?)

Mounter dine diske fra andre maskiner efter behov. Er smadder-smart
på en arbejdsstation eller på servere i store netværk. Men du har
ikke brug for den på serveren.

> gpm

Mus i tekst-mode. Nuke den, da den har det med at få andre programmer
til at dørke.

> isdn (Er der hvad jeg tror det er? Jeg kører med en kabel modem)

Ja. Ud med den.

> lpd

Printer dæmon. Bruges kun hvis du har en printer på.

> netfs
> nfslock

Bruges begge af NFS - Network File System - som er super. Behold
den og RTFM en del.

> rawdevices

Ikke noget for andet end hajer.

> rhnsd

RedHat Network Service Daemon - brug den eller up2date for at holde
din maskine opdateret med de seneste patches fra RedHat.


Et ekstra tips: Hvis du ikke ved, hvad et program eller et script
er, så kan du kigge efter det i RPM databasen:

$ rpm -qf /etc/init.d/rhnsd
up2date-2.7.86-7.x.3

Skrot alt efter den første bindestreg og skriv så:

$ rpm -qi up2date
Name : up2date Relocations: (not relocateable)
Version : 2.7.86 Vendor: Red Hat, Inc.
Release : 7.x.3 Build Date: Thu 18 Apr 2002
08:26:56 PM CEST
Install date: Fri 24 May 2002 09:56:37 PM CEST Build Host:
porky.devel.redhat.com
Group : System Environment/Base Source RPM:
up2date-2.7.86-7.x.3.src.rpm
Size : 1100859 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://rhn.redhat.com
Summary : Determines which system packages need to be updated via RHN.
Description :
The Red Hat Update Agent that automatically queries the Red Hat
Network servers and determines which packages need to be updated on
your machine.

-Claus

---

On Sat, 28 Sep 2002 23:33:55 +0200, Claus Rasmussen wrote:

>> netfs
>> nfslock
>
> Bruges begge af NFS - Network File System - som er super. Behold den og
> RTFM en del.

NFS er _ikke_ super, det sutter for vildt. Det er hamrende ustabilt og
langsomt.

Martin
--
De anede ikke en hujende fis om det, og der er aldrig nogen der
for alvor har troet på at man behøvede æde jord eller affald for
at holde sig sund og rask.
- Bertel Lund Hansen

---

Martin Ehmsen <thames@get2net.dk> writes:

> On Sat, 28 Sep 2002 23:33:55 +0200, Claus Rasmussen wrote:
>
> >> netfs
> >> nfslock
> >
> > Bruges begge af NFS - Network File System - som er super. Behold den og
> > RTFM en del.
>
> NFS er _ikke_ super, det sutter for vildt. Det er hamrende ustabilt og
> langsomt.

Det var så din mening... Bortset fra at det kan være lidt irriterende at
stort set alt hænger når/hvis nfs serveren crasher og man ikke har soft-
mounted sine devices, så har jeg aldrig oplevet problemer med det, og
efter min mening kører det også ganske hurtigt, i hvert fald hurtigt nok
til at fylde et 100 mbit netværk op.

Desuden er NFS det absolut nemmeste at bruge og gå til, og det er dejlig
let at integrere i ethvert unixmiljø, hvis man da lige kan overkomme
sikkerhedsproblematikkerne.

mvh
--
Joakim Recht
Tlf. 20 85 54 77
Email god@cs.auc.dk / PGP key http://www.braindump.dk/pgp.txt
WWW http://www.braindump.dk / http://www.compuclub.dk

---

Joakim Recht <god@cs.auc.dk> writes:

> efter min mening kører det også ganske hurtigt, i hvert fald hurtigt nok
> til at fylde et 100 mbit netværk op.

Hvilken version af NFS er det?

Jeg ved at nogle versioner af NFS benytter sig af synkrone
skrivninger, hvilket vil sige at kald til write() blokerer indtil de
skrevne data faktisk er skrevet på NFS-serveren. En enkelt
(enkelttrådet) klient og en enkelt server kan med dette design ikke
fylde noget som helst netværk mere end _halvt_ op ved kun at skrive,
og dét kun hvis størrelsen af hver skrivning er mindst B * L, hvor B
er båndbredden og L er forsinkelsen mellem klient og server.

Er der Linux-understøttede NFS-versioner som ikke benytter sig af
synkrone skrivninger?

---

Martin Ehmsen wrote:

> NFS er _ikke_ super, det sutter for vildt. Det er hamrende ustabilt og
> langsomt.

Argumenter ?

Det eneste problem, jeg har med NFS, er sikkerheden, hvis man ikke stoler
på sine brugere. NFS mætter nemt en 100Mb forbindelse (*) uden overdreven
CPU belastning (**) og det er klippesolidt (***).

*) Overfører 10MB pr. sekund (har lige prøvet med at overføre en 100MB fil).
Helt som forventet, når man regner på hvad der skal overføres af data på
en 100Mb forbindelse.

**) CPU belastningen ligger på omkring en 35%. Observeret i samme test som
ovenfor. Til sammenligning tager lokal kopiering af den samme fil 30%.

***) Jeg har aldrig haft et eneste problem med NFS - udover naturligvis den
_feature_ ved NFS, at den får programmerne til at se ud som om de
hænger, hvis serveren er nede. Det er sådan, det skal være: Når severen
kommer op igen, kører ens program videre uantastet.

Tror du ikke, at du hellere skulle trolle et andet sted ?

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> *) Overfører 10MB pr. sekund (har lige prøvet med at overføre en 100MB fil).
> Helt som forventet, når man regner på hvad der skal overføres af data på
> en 100Mb forbindelse.

Kan du ikke prøve at tage tid på programmet herunder på et NFS-system?
Det eneste det gør at at oprette en fil og skrive ca. 100 MB i den.



#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static void
disaster (const char *what)
{
fprintf (stderr, "%s\n", what);
exit (1);
}

enum {
BLOCK_SIZE = 32768
};

int
main ()
{
int i, written;
unsigned char blah[BLOCK_SIZE];
FILE *f;

if (!(f = fopen ("nfs-test", "w")))
   disaster ("fopen() failed");

srand (time(NULL));
for (i = 0; i < BLOCK_SIZE; ++i)
   blah[i] = rand() % 256;

for (written = 0; written <= 100000000; written += BLOCK_SIZE)
{
   if (fwrite (blah, 1, BLOCK_SIZE, f) != BLOCK_SIZE)
    disaster ("fwrite() failed\n");
}

return 0;
}   

---

Soeren Sandmann <sandmann@daimi.au.dk> writes:

> Kan du ikke prøve at tage tid på programmet herunder på et NFS-system?
> Det eneste det gør at at oprette en fil og skrive ca. 100 MB i den.

Jeg vil også gerne kende forsinkelsen mellem klient og server, altså
ping-tiden mellem de to maskiner.

---

Soeren Sandmann wrote:

> Soeren Sandmann <sandmann@daimi.au.dk> writes:
>
>> Kan du ikke prøve at tage tid på programmet herunder på et NFS-system?
>> Det eneste det gør at at oprette en fil og skrive ca. 100 MB i den.
>
> Jeg vil også gerne kende forsinkelsen mellem klient og server, altså
> ping-tiden mellem de to maskiner.

Jeg rettede blokstørrelsen til 8192 bytes (stemmer med min NFS blok-
størrelse):

Lokalt: 1 sek
NFS: 9 sek

Altså samme resultat som min rå filkopiering.

Ping tider:

Fra klient til server: rtt min/avg/max/mdev = 0.138/0.148/0.228/0.023 ms
Fra server til klient: rtt min/avg/max/mdev = 0.130/0.133/0.139/0.010 ms

Kørt på en 10-20 pakker.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Fra klient til server: rtt min/avg/max/mdev =
> 0.138/0.148/0.228/0.023 ms

Ok, med synkrone skrivninger kan man opnå

8192 bytes / 0.148 ms > 50MB/s

hvilket jo er mere end båndbredden mellem de to maskiner, så i dette
tilfælde vil forsinkelsen ikke være en flaskehals. Men hvis
pingtiderne var fx 2 ms, så falder den maksimale overførselsrate til
8192 bytes / 2ms ~= 4 MB/s, hvilket er mindre end båndbredden.

Så eksperimentet siger ikke så meget, fordi de to maskiner åbenbart
står tæt på hinanden.

Men hvis NFS-skrivninger stadig er synkrone, *vil* NFS få sværere og
sværere ved at fylde netværket ud, fordi pingtiderne mellem to
maskiner er begrænset af lysets hastighed, mens der ikke er nogen øvre
grænse på båndbredden - ikke nogen vi er i nærheden af i hvert fald.

---

Soeren Sandmann wrote:

> Ok, med synkrone skrivninger kan man opnå
>
> 8192 bytes / 0.148 ms > 50MB/s
>
> hvilket jo er mere end båndbredden mellem de to maskiner, så i dette
> tilfælde vil forsinkelsen ikke være en flaskehals. Men hvis
> pingtiderne var fx 2 ms, så falder den maksimale overførselsrate til
> 8192 bytes / 2ms ~= 4 MB/s, hvilket er mindre end båndbredden.

Hvad så med bare at sætte blokstørrelsen op ? Bruger vi en blokstørrelse
på 32K, vil dit regnestykke give 16MB/s hvilket igen er mere end bånd-
bredden. Og det på et netværk med temmeligt lange ping-tider.

Jeg har i øvrigt adgang til et andet netværk med omkring 10 maskiner.
Der er ping-hastighederne det samme som på mit eget. Jeg vil tro, at du
skal op i meget store netværk (>100 maskiner), før det bliver et problem.
Og i så fald vil man nok arbejde med at placere NFS serverne i nærheden
af klienterne (ja, jeg kender godt daimis setup, hvis det er det, du
tænker på).

....

> Men hvis NFS-skrivninger stadig er synkrone, *vil* NFS få sværere og
> sværere ved at fylde netværket ud, fordi pingtiderne mellem to
> maskiner er begrænset af lysets hastighed, mens der ikke er nogen øvre
> grænse på båndbredden - ikke nogen vi er i nærheden af i hvert fald.

Jeg har svært ved at se de synkrone skrivninger som et problem. Jeg
vil i hvert fald se det som et /større/ problem, at der var risiko for,
at mine data gik tabt, hvis enten klienten eller serveren gik på røven.

Jeg kiggede lidt på 'man nfs'. Der står ikke noget om synkron vs. asyn-
kron. På den anden side kan man i /usr/src/linux/fs/nfsd/vfs.c læse:

/*
* The stable flag requests synchronous writes.
* N.B. After this call fhp needs an fh_put
*/
int
nfsd_write(struct svc_rqst *rqstp, struct svc_fh *fhp, loff_t offset,
char *buf, unsigned long cnt, int *stablep)

Det ser altså ud til, at implementationen er i stand til at håndtere
asynkrone skrivninger, men at det ikke er båret med i userland. Er du
sikker på, at asynkrone skrivninger er en del af NFS protokollen ? Det
ville undre mig, da det ændrer semantikken af write.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Hvad så med bare at sætte blokstørrelsen op ? Bruger vi en blokstørrelse
> på 32K, vil dit regnestykke give 16MB/s hvilket igen er mere end bånd-
> bredden. Og det på et netværk med temmeligt lange ping-tider.

Ja, så længe blokstørrelsen er af ca. samme størrelse som forsinkelse
* båndbredde, vil mange sekventielle, synkrone skrivninger ikke være
noget stort problem. Problemet opstår hvis der er læsninger ind i
mellem skrivningerne.

Hvis der først sker en skrivning, så en læsning som afhænger af sidste
skrivning, så en skrivning osv., så vil hver eneste læsning være
begrænset af et roundtrip. Hvis skrivningerne derimod var asynkrone,
så ville *summen* af tiden til læsningerne være begrænset af et
roundtrip.

> Det ser altså ud til, at implementationen er i stand til at håndtere
> asynkrone skrivninger, men at det ikke er båret med i userland. Er du
> sikker på, at asynkrone skrivninger er en del af NFS protokollen ? Det
> ville undre mig, da det ændrer semantikken af write.

Jeg ved ikke om asynkrone skrivninger er en del af protokollen.

Det er rigtigt at det ville ændre semantikken af write() på lokale
filer, og det er helt sikkert en del af grunden til at NFS' design er
som det er. Bemærk dog at der er flere typer Unix-filedescriptors som
findes i ikke-blokerende former, hvor write() er asynkron.

---

Soeren Sandmann wrote:

> Hvis der først sker en skrivning, så en læsning som afhænger af sidste
> skrivning, så en skrivning osv., så vil hver eneste læsning være
> begrænset af et roundtrip. Hvis skrivningerne derimod var asynkrone,
> så ville *summen* af tiden til læsningerne være begrænset af et
> roundtrip.

Rigtigt. Jeg kom også til at tænke på, at hvis man skriver en masse små
filer hver mindre end blokstørrelsen, så vil man have problemet igen.
Men alt dette altså kun på netværk med lange ping-tider.

....

> Jeg ved ikke om asynkrone skrivninger er en del af protokollen.
>
> Det er rigtigt at det ville ændre semantikken af write() på lokale
> filer, og det er helt sikkert en del af grunden til at NFS' design er
> som det er. Bemærk dog at der er flere typer Unix-filedescriptors som
> findes i ikke-blokerende former, hvor write() er asynkron.

Med 2.6 kernen kommer der også asynkrone skrivninger generelt. Det er
lavet af hensyn til databaser på lokale filsystemer, men det kan være,
at det (sammen med XFS) betyder, at det også bliver muligt i NFS.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Men alt dette altså kun på netværk med lange ping-tider.

Nej, hver læsning vil være begrænset af roundtrip-tiden uanset hvor
lang den er, og man kan forvente at båndbredden bliver ved med at
vokse eksponentielt et stykke tid endnu, mens man ikke skal forvente
at pingtiden falder noget særligt.

Altså hvis du en dag sætter et gigabit-netværk mellem dine maskiner,
så vil det blive betydeligt sværere for NFS at mætte det med den samme
trafik, fordi ping-tiderne ikke vil falde væsentligt.

Det er naturligvis rigtigt at det at noget er begrænset af noget
andet, kun er et problem hvis dette andet faktisk *er* en flaskehals i
praksis. Min pointe er bare at pingtiderne *vil* blive en flaskehals
sådan som forholdet mellem båndbredde og forsinkelse udvikler sig.

---

Soeren Sandmann wrote:

> Det er naturligvis rigtigt at det at noget er begrænset af noget
> andet, kun er et problem hvis dette andet faktisk *er* en flaskehals i
> praksis. Min pointe er bare at pingtiderne *vil* blive en flaskehals
> sådan som forholdet mellem båndbredde og forsinkelse udvikler sig.

Det er rigtigt. På den anden side: Du har beregnet, at der max. kan
overføres 50MB/s med en blokstørrelse på 8K - uanset båndbredden på
nettet.

Men det er altså stadig fem gange så hurtigt som på mit 100Mb netværk
og skal sammenlignes med overførselshastigheden på maskinen lokalt,
der er på 100MB/s.

Dvs. at et 1Gb netværk vil være halvt så hurtigt som mine diske. Det
er til at leve med. Det bliver i hvert fald aldrig hurtigere end
diskene

-Claus

---

On Sun, 29 Sep 2002 12:46:36 +0200, Claus Rasmussen wrote:

> Martin Ehmsen wrote:
>
>> NFS er _ikke_ super, det sutter for vildt. Det er hamrende ustabilt og
>> langsomt.
>
> Argumenter ?

Hvor skal jeg begynde:
- Fil opretning: Normalt når et program opretter en fil, så vil den få en
   fejl hvis filen allerede findes. Dette implementerer NFS ikke
   ordentligt. Det kan give meget uheldige virkninger hvis et program tror
   den har oprette en unik fil og i virkeligheden ikke har. Tænk fx på en
   NFS mountet mailbox (vink farvel til din post).
- Fil locking: NFS locker ikke filer selv (da nfds kører stateless) og
   bruger en daemon til det (det var også hvad vi så i det opringelige
   indlæg). Men det går meget langsomt.
   Der er også et stor problem hvis serveren crasher, så bliver alle
   clienters lock tabt med clienterne bliver ikke informeret herom.
   Fx kan andre clienter locke en fil som en anden client troede
   vedkommende havde locket.
   Det kan også give meget uheldige virkninger!!
- Tids synkronisering: NFS synkronisere ikke tiden mellem server og
   klient. Dette kan give meget uheldige virkninger for visse programmer
   som bruger filer som er mountet med NFS.
- Sikkerheden: NFS sender alt i klar tekst... Det er heller ikke godt!

osv...


> Tror du ikke, at du hellere skulle trolle et andet sted ?

> /dev/null

Martin
--
De anede ikke en hujende fis om det, og der er aldrig nogen der
for alvor har troet på at man behøvede æde jord eller affald for
at holde sig sund og rask.
- Bertel Lund Hansen

---

Martin Ehmsen wrote:

> On Sun, 29 Sep 2002 12:46:36 +0200, Claus Rasmussen wrote:
>
>> Martin Ehmsen wrote:
>>
>>> NFS er _ikke_ super, det sutter for vildt. Det er hamrende ustabilt og
>>> langsomt.
>>
>> Argumenter ?
>
> Hvor skal jeg begynde:

Du kan f.eks begynde med at forklare, hvad du mener med, at det

"sutter for vildt"
"hamrende ustabilt"
"langsomt"

I stedet for bare at snakke udenom. Og gerne med _dokumentation_ i
stedet for løse påstande.

I mit indlæg _dokumenterede_ jeg, at NFS har en CPU belastning, der
er 5% højere end ved en lokal kopiering, og at det mætter en 100Mb
forbindelse uden problemer. Stabiliteten kan jeg ikke dokumentere,
men jeg har som sagt aldrig haft et eneste problem.

-Claus

---

On Sun, 29 Sep 2002 13:28:46 +0200, Claus Rasmussen wrote:

>>> Argumenter ?
>>
>> Hvor skal jeg begynde:
>
> Du kan f.eks begynde med at forklare, hvad du mener med, at det
>
> "sutter for vildt"

Personlig mening (det burde fremgå klart), og det mener jeg også at jeg
har dokumenteret i mit indlæg. Jeg har også selv været ude for at NFS har
smadret filer for mig.

> "hamrende ustabilt"

Dette er min oplevelse fra at bruge NFS til dagligt på et temmeligt stort
netværk. Det sker, ikke ofte, men tit nok at NFS er skyld i at
hjemmekataloger ikke kan mountes.

> "langsomt"

NFS er oftest hurtigt på små netværk (som du jo også nævner så kører det
dejligt hurtigt for dig), men på større netwærk er det ikke altid så
hurtigt.

> I stedet for bare at snakke udenom. Og gerne med _dokumentation_ i
> stedet for løse påstande.

Øhhh... Hvad mener du med løse påstande. De fire ting som nævnte er alle
dokumenterede problemer med NFS (og de er ikke de eneste).

> I mit indlæg _dokumenterede_ jeg, at NFS har en CPU belastning, der er
> 5% højere end ved en lokal kopiering, og at det mætter en 100Mb
> forbindelse uden problemer. Stabiliteten kan jeg ikke dokumentere, men
> jeg har som sagt aldrig haft et eneste problem.

Det er da fint det virker for dig og sikkert også for en masse andre
mennesker.

Martin
--
"No harm," The Boss burbles on.
"So anyway, I thought maybe we should do something about Branding."
"Branding?" I ask, match poised against the striker behind my back.
"You mean as in burning a mark onto any user that complains?"
- BOFH

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Det eneste problem, jeg har med NFS, er sikkerheden, hvis man ikke stoler

Det er da ogsaa rigeligt.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Det eneste problem, jeg har med NFS, er sikkerheden, hvis man ikke stoler
>
> Det er da ogsaa rigeligt.

Ja, men det er svært at finde et fornuftigt alternativ. Kender du noget ?

-Claus

---

Claus Rasmussen wrote:

> >> Det eneste problem, jeg har med NFS, er sikkerheden, hvis man ikke stoler
> >
> > Det er da ogsaa rigeligt.
>
> Ja, men det er svært at finde et fornuftigt alternativ. Kender du noget ?
>
> -Claus
>

Har ikke proevet, men NFS skulle kunne puttes igennem Zebedee
(www.winton.org.uk/zebedee/).


Vh,

--
Ole Michaelsen, Darmstadt, Germany
http://www.fys.ku.dk/~omic

---

Ole Michaelsen wrote:

> Har ikke proevet, men NFS skulle kunne puttes igennem Zebedee
> (www.winton.org.uk/zebedee/).

Tak for linken, men jeg burde nok have skrevet, at kryptering af data
er udelukket pga. performance (her bruger man en switch i stedet). Det
var NFSs authentication mekanisme, jeg gerne ville have en erstatning
for.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> > Det er da ogsaa rigeligt.
>
> Ja, men det er svært at finde et fornuftigt alternativ. Kender du noget ?

Nej, men jeg har heller ikke arbejdet seriøst med NFS-konfiguration i
lang tid.

I dag ville jeg, hvis klienten understøtter det fornuftigt, bruge
Samba - det har jeg fx tænkt mig at gøre med min OS X maskine som jeg
skal have sikkerhedskopieret.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Thorbjoern Ravn Andersen wrote:

> I dag ville jeg, hvis klienten understøtter det fornuftigt, bruge
> Samba

HVAD ?! Et Windows filsystem ? Kætteri !!

(men sandt at sige, så /har/ samba en authentication mekanisme - i mod-
sætning til NFS)

-Claus

---

Thorbjoern Ravn Andersen wrote:

> Claus Rasmussen <clr@cc-consult.dk> writes:
>
>> Ja, men det er svært at finde et fornuftigt alternativ. Kender du noget ?
>
> Nej, men jeg har heller ikke arbejdet seriøst med NFS-konfiguration i
> lang tid.

Hmm. Så kan man ikke sove og giver sig af ren kedsomhed til at læse release
notes fra den nye RedHat-8.0. 909 (!) linier nede finder man følgende:

o The Red Hat Linux 8.0 kernel contains a preview release of a new
client called kafs for the AFS distributed filesystem. This client
is not yet fully featured and provides only read-only mode. The
client is for testing purposes only and is not supported.

Google giver nogle links:

http://homer.csm.port.ac.uk/mab/Computing-FrameWork/afs.html
http://www.openafs.org/
http://www.faqs.org/faqs/afs-faq/

Det er godt nok ikke liige produktionsklart på linux, men umiddelbart ser
det ud som om, det kan blive det, der afløser NFS på sigt.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> skrev i en meddelelse
news:an5784$mr6$1@sunsite.dk...
<Snip god gennemgang af min liste>


--
Mvh
Anders Lund
Anders@zaimGED.dk
Fjern geden fra min signatur!

---

Anders Lund wrote:
> anacron (Jeg ved hvad cron er, men hvad med denne?)

Cronjobs kører kun, når maskinen er tændt. Det er ikke så godt til
f.eks. laptops. For de ting, der skal køre selvom maskinen er slukket
husker Anacron på hvad der skulle have været sket og kører det når den
bliver tændt.

> apmd

Advanced Power Management (APM) daemon. Kan f.eks. sætte din maskine i
dvale ved for lidt aktivitet. Også mest til laptops. Et nyere system er
ACPI.

> atd

køre ting til en bestemt tid. I modsætning til cron, der kører periodisk.

> autofs (Der er flere med "fs" hvad er det?)

Automounteren :
http://www.linux-consulting.com/Amd_AutoFS/autofs-3.html#ss3.1

> gpm

Musse-support i virtuelle-konsoller. D.v.s., når du ikke kører X

> isdn (Er der hvad jeg tror det er? Jeg kører med en kabel modem)

Godt spørgsmål.

> lpd

print-spool daemon. Har du installeret printer?

> netfs
> nfslock

NFS. Bruger du NFS? (Network file system. /etc/exports o.s.v.)

> rawdevices

Så vidt jeg ved er det noget med at man kan bruge det til at disable
cachen på et scsi-device.

> rhnsd

Vidste ikke hvad det var før jeg slog det op. Red Hat har åbenbart en
lille daemon ala Microsofts, der periodisk kontakter RedHat og spørger
efter updates.

Peter