Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ihnp4.ucsd.edu!agate!howland.reston.ans.net!sol.ctr.columbia.edu!startide.ctr.columbia.edu!wpaul
From: wpaul@ctr.columbia.edu (Bill Paul)
Newsgroups: comp.os.386bsd.questions
Subject: Re: changing 2.0 behavior
Date: 2 Dec 1994 06:30:11 GMT
Organization: Columbia University Center for Telecommunications Research
Lines: 92
Message-ID: <3bmetj$6be@sol.ctr.columbia.edu>
References: <D05wFw.v2@murdoch.acc.Virginia.EDU>
NNTP-Posting-Host: startide.ctr.columbia.edu
X-Newsreader: TIN [version 1.2 PL2]
Daring to challenge the will of the almighty Leviam00se, Brian -Paco- Hope
(paco@Virginia.EDU) had the courage to say:
: Here are some quirks I would like answered, if anyone knows how to
: fix them. Unless you really feel the net would benefit from your
: solution, just email me, please.
Well heck, the net could always benefit from my solutions.
: First off, I get messages on the consoles (ttyv{0,1,2}) every time
: ANYONE logs in. I'm used to seeing messages on every terminal when
: root logs in. It seems odd to me that non-priveleged users generate
: these messages, too. They don't, though, appear in xconsole windows
: or xterms. Just on the 3 virtual consoles. I guess all the consoles
: are just like one console as far as these messages go. Anyways,
: how do I stop these?
It would appear that the way to turn off this behavior is to:
a) Get the source code. (You know, every time I say this I feel like I'm
ripping off one of Steve Martin's old stand-up routines: "Yes, you too
can have a million dollars and *never* pay taxes. Here's how: first, get
a million dollars. Second...")
b) Go to: /usr/src/usr.bin/login
c) Edit the Makefile and remove the part that says: -DLOGALL
d) Recompile login.
e) Install the new login in place of the old one, being *VERY* careful
to set the permissions correctly.
The comments in login.c seem to indicate that this behavior is considered
a feature, since it (supposedly) saves you the trouble of going through
the wtmp file for login accounting. Dunno about that one... I don't mind
either way.
: Secondly, I don't want any motd most of the time. I deleted the
: contents of /etc/motd but left a 0-length file there. The next time
: I boot up, it has contents again: FreeBSD 2.0-RELEASE. I suppose
: I could delete the file, but why does it come back if I just 0-out
: the contents?
/etc/rc puts that in there for you every time the system boots. You can
either hack /etc/rc to make it stop doing that, or you can create a file in
your home directory called .hushlogin which will prevent login from
displaying /etc/motd regardless of what's in it. Just do this:
% touch ~/.hushlogin
What /etc/rc does now is really kind of useless: in 1.1.5[.1] it would
also toss in the kernel name and revision number, which was of some
value since you would know what kernel you were running whenever you
logged in. In 2.0 you just get the OS name and release number, which
doesn't do much for you. I changed my rc script to generate the same
kind of string that SunOS does, so that I see the OS name and release,
the kernel id, the revision number and the compilation date (I can do
that you know: it's a free country and everything).
: Lastly, an answer, which I'm going to post to the bugs group.
: I tried to get domain name services running, and I edited my
: resolve.conf file. Funny thing was that it didn't know who my
: name server was. It turns out that the file that inetd (or whichever
: daemon handles this) is looking for is 'resolv.conf' without the
: second 'e' in the name. Renaming the file fixed the problem immediately.
: This seems like a simple oversight in the initial setup. I thought
: I'd mention it to save other people the trouble of figuring that out.
Whoa... er, wait. You mean to say the installation created /etc/resolve.conf
instead of resolv.conf? Hurm... this bug must have been introduced recently:
when I did my installation, which was a day or so after 2.0-RELEASE first
hit the net, the install script created resolv.conf correctly (it botched
almost everything else, but resolv.conf it did right ;). Somebody must
have violated the "it's not broken, don't fix it" rule. Okay Jordan:
what's your excuse this time? :)
BTW, there's no one 'daemon' in charge of reading /etc/resolv.conf.
The gethostbyname(), gethostbyaddr() and related resolver functions in
libc are designed to look there, thus any programs that use these
functions will wind up referencing resolv.conf automagically.
: Paco
-
: |Brian "Paco" Hope (Team OS/2) | (804) 982-2294, fax:(804) 982-2214 |
Team OS/2, hunh? I thought this post seemed a little warped. (*rimshot*)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul System Manager
wpaul@ctr.columbia.edu Center for Telecommunications Research
Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The M00se Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~