Re: startup/connection trubble [was Modules & name resolution]
On Wed, Apr 26, 2000 at 10:50:09PM -0500, w trillich wrote
> hey john -- thanks for the informative reply!
>
> John Pearson wrote:
> >
> > > my syslog was complaining of something quite similar, so maybe
> > > you already helped my problem a bit. from syslog...
> > > Apr 25 21:29:48 server modprobe: Note: /etc/modules.conf is more
> > > recent than /lib/modules/2.0.36/modules.dep
> > > Apr 25 21:29:48 server insmod: Note: /etc/modules.conf is more recent
> > > than /lib/modules/2.0.36/modules.dep
> > >
> > > but i probably need more help yet...
> > >
> >
> > Others have reported similar problems after upgrading to recent
> > modutils, and have been told to run
> > # depmod -a
> > to update modules.dep. Maybe that will help.
> >
> > Did your apt-get dist-upgrade complete OK? Do you see any
> > alarming messages if you run apt-get check? It could be you're
> > only halfway through the upgrade.
>
> # apt-get check
> Reading Package Lists... Done
> Building Dependency Tree... Done
> #
>
> looks clean (but as i recall it took several iterations!)...
>
>
>
> > > from /var/log/messages:
> [snip]
> > > Apr 25 22:03:05 server kernel: Cannot find map file.
> [snip]
> > > Apr 25 22:03:05 server /sbin/rpc.statd[1901]: unable to register
> > > (SM_PROG, SM_VERS, udp).
> > > Apr 25 22:03:05 server ypbind[1915]: Unable to register (YPBINDPROG,
> > > YPBINDVERS, udp).
> [snip]
> > > Apr 25 22:07:12 server modprobe: modprobe: Can't locate module net-pf-18
> > > Apr 25 22:07:14 server last message repeated 3 times
> [snip]
> > > unable to register? invalid argument? missing module?
> > > i'm guessing "net-pf-18" is significant... how do i get that?
> >
> > The "net-pf-18" message is the kernel trying to load the module
> > for network protocol family 18, which linux/include/net/socket.h
> > lists as "Ash", with which I'm not familiar. If it represents a
> > protocol family that you don't intend to support, or you just
> > want to get rid of the messages, add
> > alias net-pf-18 off
> > to /etc/modutils/aliases and then run update-modules. I'd guess
> > it's something to do with AppleTalk, and I'd avoid getting
> > alarmed; the AppleTalk suite includes several protocols, only a
> > few of which you are likely to need to talk to Macs on your
> > local net.
>
> so that's probably what's interfering with the startup of netatalk.
> (i get errors disrupting the appletalk startup phase on the console,
> but it seems to work nonetheless. i'm telnetting from upstairs now,
> or i'd cut & paste the actual error from on-screen...)
>
> whatever modules ARE working right now seem to be what i need,
> so i've added the disabling etc/modutils/aliases line, as you suggested.
>
> but--where'd it go off to? if i do need it in the future, how
> can i restore it?
>
It may not have gone anywhere. I can't recall the context, in
which I saw this myself (may have been netatalk then, too) but
some software seems to attempt to use each defined protocol
family (maybe, just as a way of finding which ones are
supported) - this would produce messages like this for protocols
that your kernel doesn't support, but it may not be a problem
unless it's a protocol family you need support for.
>
>
> > "Unable to register" sounds like a problem with the portmapper
> > (rpc.portmap), which manages ypbind, rpc.statd and other rpc
> > services ; is it running? Don't worry too much about this if
> > other things need fixing (unless you rely on yp to get things
> > working) - come back to it later, if it's still a problem once
> > things have stabilised.
>
> # ps ax | grep map
> 9564 ttyp0 S 0:00 grep map
> 2206 ? S 0:00 /sbin/portmap
>
> so it's running. what's it do? (aside from "convert RPC program
> numbers into DARPA protocol port numbers", which is geekspeak
> for "frob your clavis via frammistat 6.0")
>
> (and rpc is remote-process-call/control, right? aka
> one of the universe's biggest security holes? do i need it?)
>
The portmapper itself isn't too bad, but people may be able to
use it to determine what rpc services you're running. Briefly,
it provides a way that you can run arbitrary services that don't
have well-known port numbers: the server registers itself with
the portmapper, which allocates a port number to the service;
clients ask the portmapper for a service, and it directs them to
the appropriate port.
> what's ypbind, by the way? (don't grok NIS either, can you tell?)
> how do i find which of these daemons are merely security holes,
> and which i need for my purposes? the manpages seem to presume
> knowledge of the functions these gizmos provide, of which i have
> none... :)
>
ypbind is the client-side of NIS; if you're using NIS then this
is the daemon that talks to your yp server, and gets yp stuff
(most notably, user information). If you aren't using YP, then
# apt-get remove nis
It's included in some of the installation profiles, but I'm not
clear on why.
The portmapper also manages NFS and NFS locking services and a
few other things, so you may want to keep it even if you ditch
NIS.
John P.
--
huiac@camtech.net.au
john@huiac.apana.org.au
http://www.mdt.net.au/~john Debian Linux admin & support:technical services
Reply to: