Topic: ssh login and FTP very slow

[Ari]

Dan Brown wrote:
>
> My guess is that it's related to using DHCP.  DHCP, after
> all, does include methods for setting DNS parameters.  Don't
> know how to avoid it, though; probably some sort of change to
> the resolv.conf templates.

Perhaps, but...
shouldn't a reboot of the server correct that problem then? I mean the SME template system should kick in and reset the resolv.conf file to what it was originally supposed to be... but it doesn't.

I dunno. I'm just glad it was finally figured out.

[Dan Brown]

Curiouser and curiouser...  The e-smith templates for resolv.conf just point it to 127.0.0.1.  So, it looks like the dhcp client is somehow re-writing resolv.conf.  No, a reboot of the server won't rebuild the config files from templates.

[Terry Brummell]

Mine was the same way, DNS settings were for the ISP, not the local server.  Changed it to my domain and server IP and all resolves nice and quick again.  What is the fix, and has anyone sent this of the N.S.S.G.?

Dan Brown wrote:
>
> Curiouser and curiouser...  The e-smith templates for
> resolv.conf just point it to 127.0.0.1.  So, it looks like
> the dhcp client is somehow re-writing resolv.conf.  No, a
> reboot of the server won't rebuild the config files from
> templates.

[Dan Brown]

The fix, for the time being, seems to be to be to re-expand the /etc/resolv.conf file after obtaining an address via DHCP.

[Berend]

Hallo All


Here the same thing. Every time you boot resolv.conf is rebuild with the
dhcpc settings and youre ocal setting is lost.

And the only thing that works is to expand-template /etc/resolv.conf

Hopely there will be a fix around soon

[Luke Drumm]

Would it make sense to add the 'template expand action' to the 'DHCP change IP event files'?

[guestHH]

uuuhhh, it's me ....

THANKS ARI and DAN B. for jumping in here!

It's working for me allright now again. And I'm also eager to hear a solution so that the resolv.conf is adapted to the correct settings every time my ISP finds it nessecsary to update by ext. IP. He isn't  gonne call me...

Anyway a BIG thanks to ARI for keeping me updated and jumping in, and as for DAN B. Hey! where would we be without your comments....

Thanks to both of you so far,

guestHH

[Dan Brown]

I've reported this to bugs@e-smith; we'll see what they say.

[Charlie Brady]

Dan Brown wrote:
>
> I've reported this to bugs@e-smith; we'll see what they say.

Ari also reported it not long before you did.

They'll get back to you in the morning, I'm sure.

In the mean time, running this command should fix the problem:

/usr/bin/perl -i.old -pe \
   's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
   /etc/sysconfig/network-scripts/ifup

Charlie

[guestHH]

Hi all,

Opened this thread, closing it....

See: http://forums.contribs.org/index.php?topic=13085.msg49364#msg49364

and await solutions...

Thanks once again to Ari and Dan B.

Regards,
guestHH

[guestHH]

ps.

I also suffered from a VERY LONG login time on my local LAN. With LOGIn i mean boot-up a client pc (WIn-XP with reg addaptons) and very unstable network connectios e.g. mapped volumes, services (Hylafax takes a very long time to authenicate....)

Will let you know what my resulta are AFTER i slept...

Regards,
guestHH

[Ari]

Just one final thought..

It may not necessarily be the SME server.

Apparently, some ISP's are pushing out DNS with their DHCP leases now... like mine (I think).

So if someone can think up some crafty way to override this whenever a new DHCP lease is pushed, that would be really cool.

Email me at ari@novikoff.net if ya have an idea.

Cheers!
Ari

[Charlie Brady]

Ari wrote:

> It may not necessarily be the SME server.
>
> Apparently, some ISP's are pushing out DNS with their DHCP
> leases now... like mine (I think).

That's perfectly normal.

> So if someone can think up some crafty way to override this
> whenever a new DHCP lease is pushed, that would be really cool.

See my earlier message, which contains instructions on patching the ifup script so that dhcpcd is started with the -R option, which tells it not to change /etc/resolv.conf. What I left out of the earlier instructions is that you need to do to restart dhcpcd with the new arguments.

# Bring down the external interface
/sbin/ifdown eth1
# Make sure that dhcpcd has exited
killall dhcpcd # Replace /etc/resolv.conf with the correct one
/sbin/e-smith/expand-template /etc/resolv.conf
# Restart the external interface
/sbin/ifup eth1

Replace eth1 with eth0 if your system is configured with "swapped"  ethernet interfaces.

Regards

Charlie

[Charlie Brady]

guestHH wrote:

> Opened this thread, closing it....

Please remember in future to report any suspected bugs to bugs@e-smith.com. We do not and cannot promise to monitor these bulletin boards.

Regards

Charlie

[Charlie Brady]

Charlie Brady wrote:

> In the mean time, running this command should fix the problem:
>
> /usr/bin/perl -i.old -pe \
>    's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
>    /etc/sysconfig/network-scripts/ifup

Allow me to correct myself (again).  Perform this command sequence:

# drop the external link - note therefore that you can perform the
# fix remotely using this procedure
/sbin/ifdown eth1
# Replace /etc/resolv.conf with the correct contents
/sbin/e-smith/expand-template /etc/resolv.conf
# Patch the ifup script to use the correct arguments to dhcpcd
/usr/bin/perl -i.old -pe \
    's/DHCPCDARGS="-d/DHCPCDARGS="-R -d/' \
    /sbin/ifup
# Now bring the external interface back up
/sbin/ifup eth1

Regards

Charlie