sendmail mailing list. Our /etc/rc will be fixed instead.
It seems sendmail becomes more and more incompatible, f.e.
Return-Receipt-To not works anymore :-(
quite right. (Thic causes you to get prompted for an 'Old Password' when
changing someone's NIS password even if your password isn't set yet.)
Do it like local_passwd.c does.
Add five sysctl variables that you should probably never tweak.
net.arp.t_prune: 300
net.arp.t_keep: 1200
net.arp.t_down: 20
net.arp.maxtries: 5
net.arp.useloopback: 1
net.arp.proxyall: 0
(It's net.arp because arp isn't limited to inet, though our present
implementation surely is).
taking an argument of type ypresp_key. This is incorrect: it should be
ypresp_nokey. (yp_first() is supposed to return the first key in a
given map; the server doesn't need any client-specified key to handle
such a request.)
#include <sys/user> used to be self contained, but now it needs either
half a dozen VM specific includes beforehand (yuck, so much for
portability), or some horrible hack like this for user-mode only
applications.. The kind of stuff that needs this is the libkvm stuff,
w, ps, etc... I would welcome a better fix for this BTW.. :-)
(note: this is #ifndef KERNEL, so it shouldn't be re-polluting the kernel
space after it's been so painfully cleaned up...)
static executables that depend on this will need to be relinked (ie: do
this before 'ps'), but the dynamic linked stuff should be OK (ie: 'w')
Obtained from: NetBSD (not much point reinventing the wheel.. :-)
This is now in line with NetBSD as well..
Note that once this series of commits is finished, you must recompile
libkvm, then ps and maybe 'w'. If you are running the recently imported
sendmail-8.7, you should recompile that too (src/conf.c at least).
No, not really. There are just a couple of long-standing bogosities here
that I feel compelled to fix. :)
There are two small changes here:
1) yp.x actually contains _three_ protocol definitions: YPPROG (standard
NIS client/server procedures), YPPUSH_XFRRESPPROG (callback handler
for the YPPROC_XFR service, aka ypxfr/yppush) and YPBINDPROG (for ypbind,
ypset & friends). The problem is that when you run yp.x through rpcgen(1),
it generates client and server stubs with hooks for all three services.
This makes it impossible to actually use the rpcgen-erated code in a
program that only deals with _one_ of these services (ypserv, ypbind,
etc...) without manually removing the unneeded stubs (either by hand
editing or by committing unspeakable horrors with sed). This defeats
the whole purpose of using rpcgen and is generally annoying.
What I've done is to insert a few #ifndefs and #endifs to allow a
programmer to selectively blot out those functions that aren't needed
for a particular program. For instance, if you do 'rpcgen -DYPSERV_ONLY',
you'll get only the necessary client/server stubs to implement the
standard yp client and server functions. If you do 'rpcgen -DYPBIND_ONLY',
you get only what you need for ypbind. If you don't #define anything,
you get the whole mess, just like before, so existing programs won't
notice the difference. (Note that the -D flag is not supported by our
existing crufty version of rpcgen, but I intend to update it soon.)
2) The definition for the ypresp_key_val structure is actually incorrect
with respect to reality: the key and val members are specified in the
wrong order. It should be val/key rather than key/val. For whatever
the reason, Sun's actual NIS implementation contradicts the protocol
definition in this case. Again, accounting for this bogosity here is
cleaner and easier than mangling the output from rpcgen.
most devsw referenced functions are now static, as they are
in the same file as their devsw structure. I've also added DEVFS
support for nearly every device in the system, however
many of the devices have 'incorrect' names under DEVFS
because I couldn't quickly work out the correct naming conventions.
(but devfs won't be coming on line for a month or so anyhow so that doesn't
matter)
If you "OWN" a device which would normally have an entry in /dev
then search for the devfs_add_devsw() entries and munge to make them right..
check out similar devices to see what I might have done in them in you
can't see what's going on..
for a laugh compare conf.c conf.h defore and after... :)
I have not doen DEVFS entries for any DISKSLICE devices yet as that will be
a much more complicated job.. (pass 5 :)
pass 4 will be to make the devsw tables of type (cdevsw * )
rather than (cdevsw)
seems to work here..
complaints to the usual places.. :)
actually retrieves all the information no matter how many interfaces
there are. (Probably there are other utilities which need similar
modification.)
Submitted by: Andrew Webster <awebster@dataradio.com>
for the particular card in use. At the moment, I've set it to any of
the bt445S VLB cards (not the bt445C which apparently work) and the
bt5xx series (isa cards). The 742 and PCI cards should not need it. :-)
It may be useful to have something like this:
#ifndef BOUNCE_BUFFERS
if (bounce_buffers_required && more_than_16MB_ram)
panic("this card requires bounce buffers for more than 16MB ram!")
#endif
