---

Hejsa

Jeg har siddet og rodet lidt med noget streaming af mp3 over et lan (lidt
til sjov brug). Det drejer sig om icecast fra www.icecast.org
Ved compilering af icecast var der mulighed for at kompilere noget
tcp_wrapper ind også. Men da jeg ikke forstod noget af hvad en tcp_wrapper
bruges til ud over noget sikkerhed så har jeg valgt ikke at gøre brug af
det.
Men efter jeg fik disse problemer har jeg ikke programmet startet op mere.

Efter jeg har siddet og leget lidt med det har jeg fået sindsyg lange login
tider både på min ftp (glftpd) og via ssh. Jeg har ikke være henne og prøve
direkte ved boxen; men det vil da undre mig meget hvis det skulle være
anderledes.

Førhen tog det 1 sec så var jeg inde både via ftp og ssh. Nu tager det
omkring 15-30 sekunder (har ikke lige taget tid). Men det er som om den tror
den skal laves et eller andet opslag først som lige skal lave en timeout.

Hvad kan umiddelbart være problemet ? Og hvordan løser jeg det ?

Det drejer sig om en Redhat 7.1 med enkelte opgraderinger i forhold til
standard install.

Mvh

Brian

---

Hej igen

Da jeg har en apache-server kørende også, prøvede jeg lige at komme ind på
nogle af de sider jeg har liggende på den.
Da jeg har password og lign. på dem så er de også sindsyg lang tid om at
skifte når jeg vælger en anden side.

Så umiddelbart må det da være et eller andet authentication-problem :(

Mvh

Brian

> Jeg har siddet og rodet lidt med noget streaming af mp3 over et lan (lidt
> til sjov brug). Det drejer sig om icecast fra www.icecast.org
> Ved compilering af icecast var der mulighed for at kompilere noget
> tcp_wrapper ind også. Men da jeg ikke forstod noget af hvad en tcp_wrapper
> bruges til ud over noget sikkerhed så har jeg valgt ikke at gøre brug af
> det.
> Men efter jeg fik disse problemer har jeg ikke programmet startet op mere.
>
> Efter jeg har siddet og leget lidt med det har jeg fået sindsyg lange
login
> tider både på min ftp (glftpd) og via ssh. Jeg har ikke være henne og
prøve
> direkte ved boxen; men det vil da undre mig meget hvis det skulle være
> anderledes.
>
> Førhen tog det 1 sec så var jeg inde både via ftp og ssh. Nu tager det
> omkring 15-30 sekunder (har ikke lige taget tid). Men det er som om den
tror
> den skal laves et eller andet opslag først som lige skal lave en timeout.
>
> Hvad kan umiddelbart være problemet ? Og hvordan løser jeg det ?
>
> Det drejer sig om en Redhat 7.1 med enkelte opgraderinger i forhold til
> standard install.
>
> Mvh
>
> Brian
>
>

---

Trespasser told the rest of dk.edb.system.unix:

> Hej igen
>
> Da jeg har en apache-server kørende også, prøvede jeg lige at komme
> ind på nogle af de sider jeg har liggende på den.
> Da jeg har password og lign. på dem så er de også sindsyg lang tid om
> at skifte når jeg vælger en anden side.
>
> Så umiddelbart må det da være et eller andet authentication-problem :(

Jeg er på den af mine Debian-spande som jeg (normalt) har kørende i
døgndrift det samme problem. Det begyndte for ca. 15 timer siden. Her
er mine oplevelser:
1) Apache er 10-20 sek. om at levere siden (uanset om der skal
authenticates eller ej).
2) Squid er nu 5-7 sek om at reagere på request overhovedet. Og det
tager ca. 20 sek. at hente en side på www.tiscali.dk (mod normalt
1-2 sek.) og 3-5 sek. uden Squid.
3) SSH connection tager omkring 25-30 sek. mod normalt 1-2 sek.
4) Samba når at time-out inden brugerne (Win2k og WinNT) når at mounte
de delinger der er på den.

Jeg har oplevet det en gang før, hvor den hurtigste løsning
tilsyneladende var at geninstallere skidtet. Jeg har prøvet at
opgradere libpam til nyeste i unstable-arkiverne - uden held.
Jeg kan sige så meget at det skete i går mellem 18:00-19:00, og der er
ingen tegn på noget som helst i syslog'en.
I går aftes slukkede jeg for den, og her i morges (09:00) tændte jeg
for den, hvorefter den opførte sig normalt i ca. 30 min. Nu gør den det
samme igen :/
Jeg har heldigvis et alternativ kørende nu, men det er ikke holdbart i
længden og jeg fatter ikke en skid af det. Jeg troede egentlig det var
tilknyttet Debians-unstable-arkiver, men dine symptomer lyder meget som
mine, så det tror jeg ikke.

Er der andre der kører Apache- eller SSH-servere der har oplevet noget
lignende inden for de sidste 24 timer?

> Brian

[...]

--
H e n r i k B o e g h ^ http://henrik.boegh.net/index.php?side=usenet
*** There's an X_ too much in my email address ***
"En fremmed er en ven, du ikke har mødt endnu."
-- Poul Kirk Andersen (Brugt i Orange reklame)

---

Hej Henrik

Det tidspunkt passer meget godt med det tidspunkt jeg begyndte at få
problemer med min server også.
Min squid har helt samme problem og jeg har de samme ting kørende som du har
dog ikke Samba og jeg har præcis samme problemer.

Jeg prøvede nemlig at fjerne authentication på apache og så er det stadig
langsomt :(

God råd og svar kan virkeligt godt bruges at i hvert tilfælde 2 mennesker :)

Brian

"Henrik Boegh" <henrik@boegh.X_net> wrote in message
news:67613601.KDcbePVmsc@willemoes.nyboder.boegh.net...
> Trespasser told the rest of dk.edb.system.unix:
>
> > Hej igen
> >
> > Da jeg har en apache-server kørende også, prøvede jeg lige at komme
> > ind på nogle af de sider jeg har liggende på den.
> > Da jeg har password og lign. på dem så er de også sindsyg lang tid om
> > at skifte når jeg vælger en anden side.
> >
> > Så umiddelbart må det da være et eller andet authentication-problem :(
>
> Jeg er på den af mine Debian-spande som jeg (normalt) har kørende i
> døgndrift det samme problem. Det begyndte for ca. 15 timer siden. Her
> er mine oplevelser:
> 1) Apache er 10-20 sek. om at levere siden (uanset om der skal
> authenticates eller ej).
> 2) Squid er nu 5-7 sek om at reagere på request overhovedet. Og det
> tager ca. 20 sek. at hente en side på www.tiscali.dk (mod normalt
> 1-2 sek.) og 3-5 sek. uden Squid.
> 3) SSH connection tager omkring 25-30 sek. mod normalt 1-2 sek.
> 4) Samba når at time-out inden brugerne (Win2k og WinNT) når at mounte
> de delinger der er på den.
>
> Jeg har oplevet det en gang før, hvor den hurtigste løsning
> tilsyneladende var at geninstallere skidtet. Jeg har prøvet at
> opgradere libpam til nyeste i unstable-arkiverne - uden held.
> Jeg kan sige så meget at det skete i går mellem 18:00-19:00, og der er
> ingen tegn på noget som helst i syslog'en.
> I går aftes slukkede jeg for den, og her i morges (09:00) tændte jeg
> for den, hvorefter den opførte sig normalt i ca. 30 min. Nu gør den det
> samme igen :/
> Jeg har heldigvis et alternativ kørende nu, men det er ikke holdbart i
> længden og jeg fatter ikke en skid af det. Jeg troede egentlig det var
> tilknyttet Debians-unstable-arkiver, men dine symptomer lyder meget som
> mine, så det tror jeg ikke.
>
> Er der andre der kører Apache- eller SSH-servere der har oplevet noget
> lignende inden for de sidste 24 timer?
>
> > Brian
>
> [...]
>
> --
> H e n r i k B o e g h ^ http://henrik.boegh.net/index.php?side=usenet
> *** There's an X_ too much in my email address ***
> "En fremmed er en ven, du ikke har mødt endnu."
> -- Poul Kirk Andersen (Brugt i Orange reklame)
>

---

Henrik Boegh <henrik@boegh.X_net> wrote:
> 3) SSH connection tager omkring 25-30 sek. mod normalt 1-2 sek.
> 4) Samba når at time-out inden brugerne (Win2k og WinNT) når at mounte
> de delinger der er på den.
[..]
> Er der andre der kører Apache- eller SSH-servere der har oplevet noget
> lignende inden for de sidste 24 timer?

Sjovt nok er min gamle OpenBSD 2.9 maskine her til morgen begyndt at
opfoere sig praecist saadan som 3 og 4 beskriver. Apache virker dog
fint.

Ved naermere undersoegelse viser det sig, at ssh forbindelser haenger ved:

[..]
debug1: RSA authentication accepted by server.
debug1: Requesting pty.
debug1: Requesting authentication agent forwarding.
debug1: Requesting shell.
debug1: Entering interactive session.

Prompten fremkommer efter et stykke tid. Jeg kigger paa det senere i
dag.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst <a@area51.dk> writes:

> Prompten fremkommer efter et stykke tid. Jeg kigger paa det senere i
> dag.

Et globalt DNS problem?

--
Thorbjørn Ravn Andersen
http://bigfoot.com/~thunderbear

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> wrote:
> Alex Holst <a@area51.dk> writes:
>
>> Prompten fremkommer efter et stykke tid. Jeg kigger paa det senere i
>> dag.
>
> Et globalt DNS problem?

Nej, den paagaeldende maskine er bag NAT. Jeg har sovet hele dagen (jeg
er syg som en hund) og nu virker baade ssh og samba igen, uden at jeg
har gjort noget.

Jeg kan dog huske, at i morges virkede smbclient -L fra localhost, og
ikke fra en anden maskine paa samme /24.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst <a@area51.dk> wrote:
> Henrik Boegh <henrik@boegh.X_net> wrote:
>> 3) SSH connection tager omkring 25-30 sek. mod normalt 1-2 sek.
>> 4) Samba når at time-out inden brugerne (Win2k og WinNT) når at mounte
>> de delinger der er på den.
> [..]
>> Er der andre der kører Apache- eller SSH-servere der har oplevet noget
>> lignende inden for de sidste 24 timer?
>
> Sjovt nok er min gamle OpenBSD 2.9 maskine her til morgen begyndt at
> opfoere sig praecist saadan som 3 og 4 beskriver. Apache virker dog
> fint.
>
> Ved naermere undersoegelse viser det sig, at ssh forbindelser haenger ved:
>
> [..]
> debug1: RSA authentication accepted by server.
> debug1: Requesting pty.
> debug1: Requesting authentication agent forwarding.
> debug1: Requesting shell.
> debug1: Entering interactive session.
>
> Prompten fremkommer efter et stykke tid. Jeg kigger paa det senere i
> dag.

En opfoelgning vildt forsinket og lidt klogere. Regel 1: det er *altid*
DNS problemer. Ogsaa selvom det umuligt *kan* vaere DNS problemer. *Isaer*
hvis det umuligt kan vaere DNS problemer.

Mit problem var en kombination af en uopdateret resolv.conf, en uheldig
/etc/hosts og en forkert ~/.ssh/config spredt over nogle maskiner. Ting
der hjaelper:

1. Debug eet symptom ad gangen
2. tcpdump -n port 53 i et vindue med lang scrollback buffer
3. kontroller hvilke navne og IP adresser der kan slaas op. Hvis dine
resolv.conf peger forskellige steder hen, goer det for hver name
server.
4. bliver din resolv.conf nogensinde overskrevet af en dhcp client?

Tilsaet ca. 20 minutters koncentration og nyd dit netvaerk uden DNS
problemer.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/

---

Alex Holst wrote:
>> Henrik Boegh <henrik@boegh.X_net> wrote:
>>> 3) SSH connection tager omkring 25-30 sek. mod normalt 1-2 sek.
>> [..]

> En opfoelgning vildt forsinket og lidt klogere. Regel 1: det er *altid*
> DNS problemer. Ogsaa selvom det umuligt *kan* vaere DNS problemer. *Isaer*
> hvis det umuligt kan vaere DNS problemer.

En kommentar: jeg stødte på problemet i går, da en række maskiner på
privat net skulle kunne tilgå sshd på en maskine på public net. Og sidst
nævnte ikke har adgang til den DNS de førstnævnte er i. Jeg løste det
ved at starte sshd med '-u0', så den ikke bekymrer sig om maskinnavnene, men
kun ip-adresserne.

-- Ole

---

Henrik Boegh told the rest of dk.edb.system.unix:

[...]

> Jeg er på den af mine Debian-spande som jeg (normalt) har kørende i
> døgndrift det samme problem. Det begyndte for ca. 15 timer siden.

Her er så lidt opfølgning på problemet:
Jeg har nu kigget alle mine logfiler efter igen - bl.a. inspirreret af
Alex's indlæg og kan desværre ikke finde noget der overfor mig antyder
nogle problemer.
Da jeg ikke har fuld tillid til Tiscalis nameservere har jeg altid haft
alle de maskiner hvorfra jeg normalt tilgår ssh-servicen. Og jeg har
kigget efter - den er ok.
I den tro at mine ipchains måske kunne være gået i selvsving "slog jeg
dem fra" (flushede alle rules og default policy ACCEPT). Samme
nedslående resultat.
Så jeg valgte Microsoft-løsningen og genstartede dyret. Den har nu
opført sig ordentligt i ca. ½ time....

[...]

> H e n r i k B o e g h ^

--
H e n r i k B o e g h ^ http://henrik.boegh.net/index.php?side=usenet
*** There's an X_ too much in my email address ***
"Nunc est bibendum -nu skal der drikkes"
-- Horats

---

Henrik Boegh wrote:

> Er der andre der kører Apache- eller SSH-servere der har oplevet noget
> lignende inden for de sidste 24 timer?

Har du forsøgt at fejlsøge med tcpdump, på både ethernet interfacet og
localhost?

---

Christian E. Lysel told the rest of dk.edb.system.unix:

[...]

> Har du forsøgt at fejlsøge med tcpdump, på både ethernet interfacet og
> localhost?

Hvad tænker du helt specifikt på når du skriver 'fejlsøge med tcpdump'?

--
H e n r i k B o e g h ^ http://henrik.boegh.net/index.php?side=usenet
*** There's an X_ too much in my email address ***
"Skadefryd, den nationale danske form for selvglæde."
-- George Brandes

---

Henrik Boegh wrote:

>>Har du forsøgt at fejlsøge med tcpdump, på både ethernet interfacet og
>>localhost?
> Hvad tænker du helt specifikt på når du skriver 'fejlsøge med tcpdump'?


Jo, det lyder som netværksproblemer, og tcpdump kan bruges til at se
hvad der sker på netværket eller ikke sker :)

Fx kan du se om du sender en dns forspørgelse men ikke får svar.

---

Christian E. Lysel told the rest of dk.edb.system.unix:

[...]

> Jo, det lyder som netværksproblemer, og tcpdump kan bruges til at se
> hvad der sker på netværket eller ikke sker :)

Pingtiderne er som de bør være. Der er intet pakketab.
Når jeg er logget ind er der heller ingen problemer. Jeg tillader mig
at tvivle på at det har noget med netværksproblemer at gøre.

> Fx kan du se om du sender en dns forspørgelse men ikke får svar.

Hvorfor skulle den sende DNS-forespørgsler?
Som jeg skrev andetsteds så er alle de hosts jeg normalt connecter fra
i /etc/hosts.

Trods god vilje tror jeg ikke at tcpdump kan give noget som helst
fingerpeg her :(

--
H e n r i k B o e g h ^ http://henrik.boegh.net/index.php?side=usenet
*** There's an X_ too much in my email address ***
"There is only one truth - my truth"
-- unknown

---

Henrik Boegh wrote:

> Pingtiderne er som de bør være. Der er intet pakketab.


Ping er en meget simpel test og udmærket test til at teste connectivity.

tcpdump kan bruges til meget mere end at teste connectivity.

> Når jeg er logget ind er der heller ingen problemer. Jeg tillader mig
> at tvivle på at det har noget med netværksproblemer at gøre.


Den største fejl du kan gøre når du fejlsøger er at udlukke ting du ikke
har testet!

>>Fx kan du se om du sender en dns forspørgelse men ikke får svar.
> Hvorfor skulle den sende DNS-forespørgsler?
> Som jeg skrev andetsteds så er alle de hosts jeg normalt connecter fra
> i /etc/hosts.


Det var blot en eksempel.


> Trods god vilje tror jeg ikke at tcpdump kan give noget som helst
> fingerpeg her :(


Det er måske ikke interessant at se hvor hurtigt 3-way handshake bliver
udført, eller om der er andre fejl?

---

On Wed, 20 Feb 2002 17:01:49 +0100, Henrik Boegh <henrik@boegh.X_net>
wrote:

>Christian E. Lysel told the rest of dk.edb.system.unix:
>
>[...]
>
>> Jo, det lyder som netværksproblemer, og tcpdump kan bruges til at se
>> hvad der sker på netværket eller ikke sker :)

Jeg havde ikke lige problemer med ssh, men med noget http trafik, som
gik gabende langsomt. Jeg har konstateret, at min dns server forsøgte
at råbe 192.0.32.18 og .19 op, men routen stoppede et sted hos Tiscali
eller lige udenfor. Problemet gik i sig selv mellem 16 og 17 i
eftermiddag.

Såe.... der kan måske være noget om snakken med et globalt dns
problem.

mvh
Klaus

---

On Wed, 20 Feb 2002 08:44:29 +0100, Trespasser wrote:

> Hejsa

> Hvad kan umiddelbart være problemet ? Og hvordan løser jeg det ?
>

Du har tjekket at det ikke er den Klassiske fejl med hosts?
Har du lavet et entry til din workstation i /etc/hosts på din server?

--
Med venlig hilsen
Bo Simonsen

"Join the GNU Generation"

---

Hej

Nej det har jeg godt nok ikke. Men jeg har aldrig har det problem før.

Men hvis jeg skulle indsætte noget i /etc/hotsts skal jeg så sætte
netbios-navnet ind og ip'en og hvad evt. mere ?

Mvh

Brian
"Bo Simonsen" <paltas@geekworld.dk> wrote in message
news:pan.2002.02.20.12.49.55.922447.823@geekworld.dk...
> On Wed, 20 Feb 2002 08:44:29 +0100, Trespasser wrote:
>
> > Hejsa
>
> > Hvad kan umiddelbart være problemet ? Og hvordan løser jeg det ?
> >
>
> Du har tjekket at det ikke er den Klassiske fejl med hosts?
> Har du lavet et entry til din workstation i /etc/hosts på din server?
>
> --
> Med venlig hilsen
> Bo Simonsen
>
> "Join the GNU Generation"

---

On Wed, 20 Feb 2002 15:24:04 +0100, Trespasser wrote:

> Hej
>
> Nej det har jeg godt nok ikke. Men jeg har aldrig har det problem før.
>
> Men hvis jeg skulle indsætte noget i /etc/hotsts skal jeg så sætte
> netbios-navnet ind og ip'en og hvad evt. mere ?
>

Det er btw det samme Claus er inde på.

Det er for så vidt lige meget hvilket navn du bruger, men det vil være
velvalgt at bruge netbios navnet, og derefter dens ip, så der står i
/etc/hosts

ip         masknavn

eksempel

192.168.1.1      luder

--
Med venlig hilsen
Bo Simonsen

"Join the GNU Generation"

---

Trespasser wrote:

> Førhen tog det 1 sec så var jeg inde både via ftp og ssh. Nu tager det
> omkring 15-30 sekunder (har ikke lige taget tid). Men det er som om den
> tror den skal laves et eller andet opslag først som lige skal lave en
> timeout.

Den laver et DNS opslag. Det er i hvert fald det, der har været årsagen,
når jeg har haft problemet.

Prøv at pinge dine DNS servere (de står i filen resolv.conf). Du har
forresten ikke været ved at rode med bind ? Lad være med det

-Claus

---

Hej

Jeg sad og kigge div. conf-filer igennem og der så jeg at resolv.conf ikke
indeholdte min egen dns-server. Så det er blevet rettet og så virker det
igen :)

Hvorfor bliver resolv.conf overskrevet ved boot (etablering af
pppoe-forbindelse) og hvad kan jeg evt. gøre for at det er den samme
resolv.conf der hele tiden bliver brugt. Grunden til dette er at squid
bruger resolv.conf til at hente dns-servere fra som den skal bruge.

Mvh

Brian
"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:a50btp$k2f$3@sunsite.dk...
> Trespasser wrote:
>
> > Førhen tog det 1 sec så var jeg inde både via ftp og ssh. Nu tager det
> > omkring 15-30 sekunder (har ikke lige taget tid). Men det er som om den
> > tror den skal laves et eller andet opslag først som lige skal lave en
> > timeout.
>
> Den laver et DNS opslag. Det er i hvert fald det, der har været årsagen,
> når jeg har haft problemet.
>
> Prøv at pinge dine DNS servere (de står i filen resolv.conf). Du har
> forresten ikke været ved at rode med bind ? Lad være med det
>
> -Claus
>
>

---

Trespasser wrote:

> Hvorfor bliver resolv.conf overskrevet ved boot (etablering af
> pppoe-forbindelse) og hvad kan jeg evt. gøre for at det er den samme
> resolv.conf der hele tiden bliver brugt. Grunden til dette er at squid
> bruger resolv.conf til at hente dns-servere fra som den skal bruge.

Bruger du DHCP ? Det er det eneste, jeg umiddelbart kan forestille
mig, der skulle pille ved resolv.conf (pppoe kender jeg ikke).

-Claus

---

Trespasser wrote:

> Hvorfor bliver resolv.conf overskrevet ved boot (etablering af
> pppoe-forbindelse) og hvad kan jeg evt. gøre for at det er den samme


en dhcp klient kan godt finde på at overskrive disse oplysninger, med
det den får oplyst af sin dhcp server.

> resolv.conf der hele tiden bliver brugt. Grunden til dette er at squid
> bruger resolv.conf til at hente dns-servere fra som den skal bruge.

squid behøver ikke resolv.conf,

# TAG: dns_nameservers
# Use this if you want to specify a list of DNS name servers
# (IP addresses) to use instead of those given in your
# /etc/resolv.conf file.
#
# Example: dns_nameservers 10.0.0.1 192.172.0.4
#
#dns_nameservers none