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. -- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.mdt.net.au/~john Debian Linux admin & support:technical services
