---

Hejsa.
Jeg har lavet et script der opdaterer en navneserver hver gang der kommer
ændringer i en database. I værste fald (i praksis nok aldrig) kan dette ske
omkring 500 gange i døgnet, så seirenummeret skal gerne afspejle dette. Pt.
er formatet YYYYMMDDxx, hvor xx er serienummeret, og dette havde jeg tænkt
mig at udvide med endnu et ciffer til YYYYMMDDxxx, men så nægter named at
starte.
Jeg har ikke fundet noget dokumentation for at serienummeret ikke må være
mere end 10 karakterer langt, men hvad pokker kan der ellers være galt?

Takker
Keller

---

"Carsten Keller" <CK@ADM.iha.dk> writes:

> Jeg har ikke fundet noget dokumentation for at serienummeret ikke må være
> mere end 10 karakterer langt, men hvad pokker kan der ellers være galt?

Jeg har ikke undersøgt det, men hvis serienummeret er 32bit langt er
der kun 10 cifre.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
> Jeg har ikke undersøgt det, men hvis serienummeret er 32bit langt er

Hvilket jeg mener det er.

> der kun 10 cifre.

Eller sagt på en anden måde, i år 4294 får vi problemer, da følgende er
det største tal:

4294967296
YYYYMMDDxx


Hvis du ikke er gået igang med at bruge serienummerne, kan du evt. bruge
formatet YYYMMDDxxx, dvs at du får problemer i slutningen af år 2999.

---

Christian E. Lysel wrote:
> 4294967296

Ups, der skal stå 4294967295 :)

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3D0F030C.9010104@example.net...

> Hvis du ikke er gået igang med at bruge serienummerne, kan du evt. bruge
> formatet YYYMMDDxxx, dvs at du får problemer i slutningen af år 2999.

Jeg har af gode grunde ikke sat versionen med det lange serienummer i drift

Men hvis jeg umiddelbart går over til YYYMMDDxxx får jeg jo de første 200 år
et lavere serial end jeg har nu
Løsningen bliver nok at jeg forudsætter at der ikke sker mere end 100
opdateringer pr. døgn.
Takker
Keller

---

Carsten Keller wrote:
> Men hvis jeg umiddelbart går over til YYYMMDDxxx får jeg jo de første 200 år
> et lavere serial end jeg har nu
> Løsningen bliver nok at jeg forudsætter at der ikke sker mere end 100
> opdateringer pr. døgn.

Du kan som en anden blot droppe YYYYMMDD notationen og blot lægge én til
ved hver opdatering.

---

"Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
news:3D0F1978.70506@example.net...
> Du kan som en anden blot droppe YYYYMMDD notationen og blot lægge én til
> ved hver opdatering.

Jeg har overvejet det, men det er nu rart at kunne se hvornår der sidst er
sket en opdatering. Jeg har ikke noget godt argument, andet end at det vil
være synd at ødelægge sådan et pænt tal
Keller

---

"Carsten Keller" <CK@ADM.iha.dk> writes:

> "Christian E. Lysel" <chlyshoswmdatapunktumcom@example.net> wrote in message
> news:3D0F1978.70506@example.net...
> > Du kan som en anden blot droppe YYYYMMDD notationen og blot lægge én til
> > ved hver opdatering.
>
> Jeg har overvejet det, men det er nu rart at kunne se hvornår der sidst er
> sket en opdatering. Jeg har ikke noget godt argument, andet end at det vil
> være synd at ødelægge sådan et pænt tal

Du kunne også lave serial udfra "seconds since `00:00:00 1970-01-01
UTC'" - tilsvarende bruges i tinydns fra djbdns pakken.

15:17 csa@c 0 % date +%s
1024492629

(Du skal bruge GNU date)

Og hvis du så vil se, hvornår opdateringen blev foretager er det noget i
stil med:

15:18 csa@c 0 % date -d '00:00:00 1970-01-01 UTC 1024492629 sec' +%c
Wed Jun 19 15:17:09 2002


/Claus A

---

"Claus Albøge" <csa@csa-net.dk> wrote in message
news:20020619.152230806482500@csa-net.dk...
> Du kunne også lave serial udfra "seconds since `00:00:00 1970-01-01
> UTC'" - tilsvarende bruges i tinydns fra djbdns pakken.
>
> 15:17 csa@c 0 % date +%s
> 1024492629

Men så går der omkring 31 år før serienummeret overhaler mit nuværende
serial

Det jeg var ude efter var såmen bare, at jeg uden større sværdslag kunne
komme til at rette mere end 100 gange om dagen, uden at ødelægge de "pæne"
tal.
Næste gang jeg kører en navneserver op, vil jeg nok vælge at bruge
almindelige serials, men indtil videre får den lov til at køre videre med
maks 100 opdateringer i døgnet.
Takker for de mange forslag.
Keller

---

"Carsten Keller" <CK@ADM.iha.dk> writes:

> "Claus Albøge" <csa@csa-net.dk> wrote in message
> news:20020619.152230806482500@csa-net.dk...
> > Du kunne også lave serial udfra "seconds since `00:00:00 1970-01-01
> > UTC'" - tilsvarende bruges i tinydns fra djbdns pakken.
> >
> > 15:17 csa@c 0 % date +%s
> > 1024492629
>
> Men så går der omkring 31 år før serienummeret overhaler mit nuværende
> serial

Kig RFC 2182, Sektion 7

http://www.rfc-editor.org/rfc/rfc2182.txt

der er proceduren for at "nedsætte" serienummeret beskrevet.
(Godt man ikke bruger BIND :)


/Claus A

---

"Carsten Keller" <CK@ADM.iha.dk> writes:

> Hejsa.
> Jeg har lavet et script der opdaterer en navneserver hver gang der kommer
> ændringer i en database. I værste fald (i praksis nok aldrig) kan dette ske
> omkring 500 gange i døgnet, så seirenummeret skal gerne afspejle dette. Pt.
> er formatet YYYYMMDDxx, hvor xx er serienummeret, og dette havde jeg tænkt

Det med at du overskrider 32-bit lyder sandsynligt.

Det vigtige er at serienummeret stiger hver gang du opdaterer. Du kan
derfor lave det om til en almindelig taeller, med det behov du har.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

Carsten Keller wrote:
> Hejsa.
> Jeg har lavet et script der opdaterer en navneserver hver gang der kommer
> ændringer i en database. I værste fald (i praksis nok aldrig) kan dette ske

Har du evt. kikket på djbdns, http://cr.yp.to/djbdns.html i stedet for
at bruge bind. I djbdns bygger den selv seriel nøglen.

Værktøj til interface med en sqldata kan findes på
http://cr.yp.to/djbdns/other.html

---

Christian E. Lysel wrote:
> Carsten Keller wrote:
> > Hejsa.
> > Jeg har lavet et script der opdaterer en navneserver hver gang der kommer
> > ændringer i en database. I værste fald (i praksis nok aldrig) kan dette ske
>
> Har du evt. kikket på djbdns, http://cr.yp.to/djbdns.html i stedet for
> at bruge bind. I djbdns bygger den selv seriel nøglen.

Eller brug dynamisk opdatering af din Bind8 eller Bind9, der bygger den
ogsaa selv serienummeret.

Vh,

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

---

Ole Michaelsen wrote:
>> Har du evt. kikket på djbdns, http://cr.yp.to/djbdns.html i stedet for
>> at bruge bind. I djbdns bygger den selv seriel nøglen.
> Eller brug dynamisk opdatering af din Bind8 eller Bind9, der bygger den
> ogsaa selv serienummeret.

Kik endvidere på http://cr.yp.to/djbdns/blurb/unbind.html

og

http://cr.yp.to/djbdns/blurb/security.html

og

http://cr.yp.to/djbdns/guarantee.html

---

Christian E. Lysel wrote:

> > Eller brug dynamisk opdatering af din Bind8 eller Bind9, der bygger den
> > ogsaa selv serienummeret.
>
> Kik endvidere på http://cr.yp.to/djbdns/blurb/unbind.html
> http://cr.yp.to/djbdns/blurb/security.html
> http://cr.yp.to/djbdns/guarantee.html

Lad os nu ikke starte en flame-war. Den slags klares glimrende andre
steder. En af mine favoritter er

"http://groups.google.com/groups?hl=en&safe=off&th=a997d4756bc8f7f8&rnum=6"

Vh,

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