HEADS UP: sendmail 8.12.2 MFC'ed
Kohler, Raymond J
which do I run simply to get the output from periodic mailed correctly?
That's all I use sendmail for and I'd like to keep its use to a minimum.
Thanks.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Gregory Neil Shapiro
raymond.j.kohler> ways to run sendmail, which do I run simply to get the
raymond.j.kohler> output from periodic mailed correctly? That's all I use
raymond.j.kohler> sendmail for and I'd like to keep its use to a minimum.
raymond.j.kohler> Thanks.
Just set sendmail_enable to NO. Until the patch under review is mailed,
you'll get two daemons but that will be fixed shortly.
Eric L. Howard
> One question about this: now that we have 4 different ways to run sendmail,
> which do I run simply to get the output from periodic mailed correctly?
> That's all I use sendmail for and I'd like to keep its use to a minimum.
> Thanks.
>
You don't need to run sendmail as a daemon for this...just add an alias for
root in /etc/aliases for where you want root's mail to end up...run
newaliases and away you go.
~elh
--
Eric L. Howard e l h @ o u t r e a c h n e t w o r k s . c o m
------------------------------------------------------------------------
www.OutreachNetworks.com 313.297.9900
------------------------------------------------------------------------
Advocate of the Theocratic Rule
Gregory Neil Shapiro
>> which do I run simply to get the output from periodic mailed correctly?
>> That's all I use sendmail for and I'd like to keep its use to a minimum.
>> Thanks.
>>
elh> You don't need to run sendmail as a daemon for this...just add an
elh> alias for root in /etc/aliases for where you want root's mail to end
elh> up...run newaliases and away you go.
With 8.12, you do need a daemon to accept the mail from the "command line"
submission. See /etc/mail/README for an explanation.
Karsten W. Rohrbach
> One question about this: now that we have 4 different ways to run sendmail,
> which do I run simply to get the output from periodic mailed correctly?
> That's all I use sendmail for and I'd like to keep its use to a minimum.
> Thanks.
some dumbfire binmail implementation should take it's place. mail
subsystems should be available as package/port.
bsd has always followed a paradigm for source code management,
installation, upgrades and overall implementation issues which is
straightforward, mostly uncomplicated, thus less error-prone than other
*ix systems -- a paradigm not found much in the sysv-infested world of
/etc directories one might nowadays call a "registry". this is a strong
point in bsd systems which makes them much more valuable than other more
complicated systems, IMVHO, because it gains stability, resiliency and
ease of administration.
the question is: why the hell are complex (or rather complicated)
subsystems that often stay unused still in the base distribution? it is
simply not consequent, not following the main paradigm of bsd's design,
to have subsystems like sendmail or bind in the base dist, where
simpler, more starightforward, client only implementations would do the
job in most cases. why not put apache into the base dist? or webmin? or
postgres? this would actually make sense in terms of a "more complete"
base distribution, but it simply does not fit the picture we all have
from bsd: being a simple, straighforward, rock-solid dist, with no "bells
and whistles" (actually there are a lot, but they are well hidden), with
less "chrome" than other widespread *ix dists.
i don't want to spoil the image of all the committers, of all the people
doing hard work, contributing to the project, but the default
installation in some points just doesn't make sense to me, relative to
my perception of bsd. it's mainly a philosophical thing, and i can't
understand why it is done the way it is done today.
we got the year 2002, where everybody is free to choose "some" free os,
"some" mua, "some" you name it, but i (as a user) still stick to freebsd
because i know that it is one of the finest operating systems "out
there", delivering excellent performance, even under heaviest of loads,
being rock-solid and thus, serving as a profound basis for internet
services. and it even gets better from release to release, this is a
great achievement, and i enjoy every minor version-bump.
as it comes to my systems, i put together a small shell script which
actually _removes_ parts of the stuff that is installed by default.
there are the NO_* build options, but why aren't they used in the
official release? a question should be integrated into sysinstall, that
simply asks: "mua: fish or flesh?" (or whatever you may call it).
i simply don't get it. still. since about 4+ years now. and counting...
please, make such complex software a port/package.
regards,
/k
--
> Jesus died for your sins. Make it worth his time.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x
Eric L. Howard
> >> One question about this: now that we have 4 different ways to run sendmail,
> >> which do I run simply to get the output from periodic mailed correctly?
> >> That's all I use sendmail for and I'd like to keep its use to a minimum.
> >> Thanks.
> >>
>
> elh> You don't need to run sendmail as a daemon for this...just add an
> elh> alias for root in /etc/aliases for where you want root's mail to end
> elh> up...run newaliases and away you go.
>
> With 8.12, you do need a daemon to accept the mail from the "command line"
> submission. See /etc/mail/README for an explanation.
Maybe I shoud have inserted a disclaimer...
*I have not run sendmail for production SMTP services for 2 years...pay no
attention to me!*
I don't know...that seems a little wrong to me...and to explore here will
probably lead us all way off-topic. Thanx for the correction.
~elh
--
Eric L. Howard e l h @ o u t r e a c h n e t w o r k s . c o m
------------------------------------------------------------------------
www.OutreachNetworks.com 313.297.9900
------------------------------------------------------------------------
Advocate of the Theocratic Rule
To Unsubscribe: send mail to majo...@FreeBSD.org
Helge Oldach
>the question is: why the hell are complex (or rather complicated)
>subsystems that often stay unused still in the base distribution? it is
>simply not consequent, not following the main paradigm of bsd's design,
>to have subsystems like sendmail or bind in the base dist,
Because they don't ...stay unused. It's just convenient to have a
standard, well- and widely-known piece of software around. You may not
like it but both Sendmail and BIND are the de facto standards. Period.
You have all hooks to throw them away and substitute them with something
different, so please don't bother the world if they don't grok your
personal taste.
Not another sendmail-versus-whatever discussion please... Please!
Helge
P.S. Get rid of vi; cat should be enough for everyone!
Karsten W. Rohrbach
[...]
> standard, well- and widely-known piece of software around. You may not
they are not, but this is not the issue. "it is just convenient to have
emacs in the base system", it's a de facto standard, it's widely known
and i guess it's much more widespread than the use of sendmail. but,
again, this is not the issue here. why not have apache in the base dist?
(to quote one part of the original again).
> You have all hooks to throw them away and substitute them with something
> different, so please don't bother the world if they don't grok your
> personal taste.
this isn't about my "personal taste", this is about "philosophy", just
as i stated in the other pragraph you generously deleted. thank you.
> Not another sendmail-versus-whatever discussion please... Please!
this isn't it neither. re-read the original mail and think about it
again.
> P.S. Get rid of vi; cat should be enough for everyone!
do you really expect me to comment on this?
btw, "guessing" from the domain part of you mail address, you should
actually be interested in straightforwardness and stability of
implementations in the field your company operates in, shouldn't you?
btw2, it's very hard to make a point if the first sentence of an email
ends with "period.", even harder if you fail to make a point in your
whole argumentation.
btw3, if you didn't still did not understand what i meant in the
original mail (i know, i'm not a native english speaker, so are you, so
the chosen language might not be as efficient due to my deficiencies),
please think about it _again_. it is about simplicity of implementation.
straighforwardness. ease of administration. this in context to what i
see as the basic paradigms in bsd's design. and this all in relation to
"how-it-is-done in -RELEASE". i don't want to change somebody's
lifestyle. i don't want to change the release engineer's way of
thinking. i want the people involved to think about the questions i
posed in the original mail and i _know_ that this is a good idea. with
people like you, "guarding" the borders of "their" sandlot, of course,
there's not as much probability to come to a point of _discussion_, because
you appear to _insist_ on the correctness of your view of the world. fwiw,
let me tell you one thing my friend: when the catholic church around
1490 AD taught a picture of a world being flat as a dish, columbus was
apparently the only one idealistic enough to prove them wrong. this was
not the result of saying "we did this since 1300, why should we think
different now?". you get my point.
have a nice day,
/k
--
> Coders do it with a routine.
Yeasah Pell
> >the question is: why the hell are complex (or rather complicated)
> >subsystems that often stay unused still in the base distribution? it is
> >simply not consequent, not following the main paradigm of bsd's design,
> >to have subsystems like sendmail or bind in the base dist,
>
> Because they don't ...stay unused. It's just convenient to have a
> standard, well- and widely-known piece of software around. You may not
> like it but both Sendmail and BIND are the de facto standards. Period.
>
> You have all hooks to throw them away and substitute them with something
> different, so please don't bother the world if they don't grok your
> personal taste.
>
> Not another sendmail-versus-whatever discussion please... Please!
>
> Helge
>
> P.S. Get rid of vi; cat should be enough for everyone!
When did it become a sendmail-versus-whatever discussion? The question is
simply this: why are there large, complex, non-BSD packages in src-contrib
that are not critical to the running of many types of systems, and not
strictly a dependency of the system proper? (Before you jump and say that
some local mail delivery tool should be system-mandatory, note that the
original suggestion was that if there is to be a default mail tool, it
should be some very simple binmail style thing, not a whole full blown
sendmail implementation.)
I don't buy the argument that the software is there so that you can use it
when you finally find a need for it. That could be said about much of the
generally useful software that has found a home in the ports collection. Nor
does the fact that sendmail and bind are de facto standards mean they should
be afforded any different treatment than the many other de facto services
that live in the ports tree. I'd guess that there are a similar number of
BSD machines running apache as there are running sendmail, and probably
substantially more than are running BIND -- but you don't find that piece of
de facto web serving software in src-contrib, do you?
The suggestion that moving sendmail or bind into the ports tree is
tantamount to doing the same to vi is interesting, but I see a major
difference between the two: I can hardly contrive an example where vi
wouldn't be useful to have, whereas I have actually encountered many cases
in my work where a DNS server and an MTA are both unwanted and even needed
to be removed due to constraints unrelated to name resolution or mail
transport. And, as Helge prematurely pointed out, there are perfectly
functional alternatives to both of those packages, too.
It seems analagous to opt-in (ports) versus opt-out (src) for software,
except that the opt-out procedure is more involved (alter make.conf,
buildworld) than the opt-in procedure (install the port), and is more
difficult to manage (especially if you want to manage the software
independent of the rest of the OS.) Given those characteristics, why would
one prefer the "opt-out" method? Actually, when you start to think along
those lines, it starts to take a Microsoft-esque bundled software favoritism
shape, which might be why the "sendmail-versus-whatever" flag was raised
prematurely.
But I'm assuming that there are actual good reasons for this software being
in the main tree, not simply for the advocacy of some particular software,
as that seems pointless. (Also because the idea gives me the creeps.) My
best guess for why they remain there is the momentum generated by their very
presence -- if many or most people use that software, and moving it out
would break their setups, it's not likely to change any time soon, eh?
I've noticed that there are, in fact, sendmail and bind ports -- does
anybody use them? if so, why, and do they interact poorly with their
src-contrib counterparts? If not, why are they there? Is there some
political struggle afoot to cleave these packages from the BSD sources
proper? Are these old, deprecated ports?
In fact, it seems like about 50% of the packages in src-contrib can also be
found in the ports collection. That's pretty confusing, actually.
Apparently, I have the bzip2 package installed for no reason, as it's part
of stable. Pulled in as a logical dependency of tar's -y option, maybe? Are
there plans to eventually deprecate the duplicated ports, or the packages in
src-contrib, or neither? Is there any sort of rough policy on how to decide
where to put a piece of non-BSD software?
Anyway, I just wanted to say that some of Karsten's comments resonated with
my own experiences, and while perhaps a little harshly worded, I think the
questions deserve some thought.
/Yeasah
Helge Oldach
>Helge Oldach(helge....@atosorigin.com)@2002.03.26 23:26:57 +0000:
>[...]
>> standard, well- and widely-known piece of software around. You may not
>> like it but both S******* and B*** are the de facto standards. Period.
Please quote correctly and don't falsify my words here. I am not willing
to discuss with you showing this unacceptable attitude.
Helge
Helge Oldach
>The question is
>simply this: why are there large, complex, non-BSD packages in src-contrib
>that are not critical to the running of many types of systems, and not
>strictly a dependency of the system proper?
Because they always have been. BSD users (those who have been running
BSD systems for *years* and not those who jumped on the wagon lately) do
expect that a decent, full-function MTA and DNS server are on board by
default. And further they expect that those beasts are being configured
as they have always been configured, in other words: No learning curve,
no additional installation of the ports.
This BSD thing is about tradition. "Alternative" software is what the
word says: It's about re-inventing the wheel. This is the Linux spirit.
>The suggestion that moving sendmail or bind into the ports tree is
>tantamount to doing the same to vi is interesting, but I see a major
>difference between the two: I can hardly contrive an example where vi
>wouldn't be useful to have, whereas I have actually encountered many cases
>in my work where a DNS server and an MTA are both unwanted and even needed
>to be removed due to constraints unrelated to name resolution or mail
>transport.
I have the exactly opposite experience. Most of my systems need at least
an outbound-only MTA, and it's much easier to add a single rc.conf
line than to build a port, set aside installing the entire ports tree
first. (Yes, I have a couple of machines without ports tree. Consider,
for instance firewalls or VPN gateways.) Moving it into ports will
complicate matters for almost everybody, while having some decent
full-function package in the base system will make it easy at least for
those who use that.
Count this my strong vote against removal of packages that are
traditionally part of the base system.
Helge
Karsten W. Rohrbach
> Karsten W. Rohrbach:
> >Helge Oldach(helge....@atosorigin.com)@2002.03.26 23:26:57 +0000:
> >[...]
> >> standard, well- and widely-known piece of software around. You may not
> >> like it but both S******* and B*** are the de facto standards. Period.
>
> Please quote correctly and don't falsify my words here. I am not willing
> to discuss with you showing this unacceptable attitude.
as i pointed out in my previous mail, this is _not_ a software[A] vs.
software[B] discussion, and your way of approaching the questions i
posed does not bring you, me, the community or anyone any further.
i blanked out two "buzzwords", and that on purpose. this was not meant
to falsify, and i admit that i should have marked this removal of
non-relevant co-information. i think i made my point clear by now, so
that everybody interested understands what i mean. in case of not
understanding my words, everyone is free to _ask_. bashing on people
without reason does not make any sense and i find your way to approach a
discussion to be not very fruitful or constructive. that said i ask you
if you also think of that as an "unacceptable attitude"?
on the other hand, quoting you as "[...]not willing to discuss[...]",
your behaviour ultimately proves that obviously this is the case, yes.
if you are not able to discuss this on a technical level, or perhaps
you are not in the mood to do so, please, consider not commenting on
the whole thing here. if you want to tell me your personal feelings about
my person, please do so via private mail. you are always welcome to do
that. my native language is german (i guess your's, too) so this might
work out a little more productive than the stuff you posted here.
thank you.
have a nice day,
/k
--
> Hackers do it with fewer instructions.
Karsten W. Rohrbach
removed. please, read on.
Helge Oldach(helge....@atosorigin.com)@2002.03.27 09:36:19 +0000:
> Yeasah Pell:
> >The question is
> >simply this: why are there large, complex, non-BSD packages in src-contrib
> >that are not critical to the running of many types of systems, and not
> >strictly a dependency of the system proper?
>
> Because they always have been. BSD users (those who have been running
> BSD systems for *years* and not those who jumped on the wagon lately) do
> expect that a decent, full-function MTA and DNS server are on board by
> default. And further they expect that those beasts are being configured
> as they have always been configured, in other words: No learning curve,
> no additional installation of the ports.
if you consider doing
cd /usr/ports/whereever && make install clean
as steep learning curve, i guess you disqualify yourself in this very
forum.
> This BSD thing is about tradition. "Alternative" software is what the
> word says: It's about re-inventing the wheel. This is the Linux spirit.
wrong, it is called evolution, a natural way of things evolving which
does not stop just because somebody puts up a sign "this is bsd, we do
it this way since 1970 and it won't change in the future". this has
nothing to do with linux at all. it is also not about re-inventing the
wheel. you seem to mix up the terms "tradition" and "religion" here,
introducing an implicit amount of folklore, hoping that it will support
your nonexistant line of argumentation.
define:
- "this bsd thing"
- "linux spirit"
when it comes to tradition, i cannot remember a single freebsd
distribution which natively supports to be booted from tape. running bsd
on pc hardware does not have anything to do with tradition.
another point is that, if the community would stick to your way of
"tradition", freebsd nowadays would run on laptop computers (why
support pcmcia/cardbus? it's not been there in the 70's, so why should
we bother to implement it today?).
do i need to go on?
> >The suggestion that moving sendmail or bind into the ports tree is
> >tantamount to doing the same to vi is interesting, but I see a major
> >difference between the two: I can hardly contrive an example where vi
> >wouldn't be useful to have, whereas I have actually encountered many cases
> >in my work where a DNS server and an MTA are both unwanted and even needed
> >to be removed due to constraints unrelated to name resolution or mail
> >transport.
>
> I have the exactly opposite experience. Most of my systems need at least
> an outbound-only MTA, and it's much easier to add a single rc.conf
> line than to build a port, set aside installing the entire ports tree
> first. (Yes, I have a couple of machines without ports tree. Consider,
> for instance firewalls or VPN gateways.) Moving it into ports will
> complicate matters for almost everybody, while having some decent
> full-function package in the base system will make it easy at least for
> those who use that.
generally, you make a point here.
to come back to your original thought, do you consider having sendmail
on a firewall a good thing[tm]? sell that to your customers and prove me
that you do this successfully. this, just as a sidenote.
as another sidenote, nobody prevents you from building a package
yourself on a machine having a ports tree installed. these systems are
known as "builder" machines, and most of the folks in the bsd community
having more than just a handful of machines operate one. just to build
their custom packages. you don't have many machines in the field, have
you? this question just out of curiosity.
> Count this my strong vote against removal of packages that are
> traditionally part of the base system.
>
> Helge
/k
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
--
> If you think sex is a pain in the ass, try a different position.
Thomas Hurst
> Count this my strong vote against removal of packages that are
> traditionally part of the base system.
I hate sendmail with a passion. I use exim; hence it's just added
bloat sitting in my rather full /usr.
The existance of more up-to-date ports for a lot of what's in the base
system means many people don't want any trace of them from the base
system; e.g. Perl.
Additionally, many parts of the base system are not required or wanted
on simple systems; if I have a tiny 486 I want to turn into a firewall,
I don't want to spend hours trimming down the base system to fit on it.
I suggest we extend the package system to include the base system; then
I can just do env PKG_DBDIR=/var/db/syspkg pkg_deinstall sendmail-6.6.6,
and sysinstall can more easily NOT install things I don't want, without
impacting users who do want them.
Or maybe everyone who doesn't want to use sendmail should switch to
NetBSD w/ syspkg :)
--
Thomas 'Freaky' Hurst - fre...@aagh.net - http://www.aagh.net/
-
Lackland's Laws:
(1) Never be first.
(2) Never be last.
(3) Never volunteer for anything
Scott Lambert
> * Helge Oldach (helge....@atosorigin.com) wrote:
>
> > Count this my strong vote against removal of packages that are
> > traditionally part of the base system.
>
> I can just do env PKG_DBDIR=/var/db/syspkg pkg_deinstall sendmail-6.6.6,
> and sysinstall can more easily NOT install things I don't want, without
> impacting users who do want them.
Congratulations! You are the 1,000th person to volunteer to do this.
When may we expect the patches?
--
Scott Lambert KC5MLE Unix SysAdmin
lam...@lambertfam.org http://www.lambertfam.org/~lambert/resume.html
3 years Sr. SysAdmin experience with FreeBSD in small & medium size ISPs.
John
seems to have gone nearly off it's topic)..
Pell Yeasah wrote:
>I've noticed that there are, in fact, sendmail and bind ports -- does
>anybody use them? if so, why, and do they interact poorly with their
>src-contrib counterparts? If not, why are they there? Is there some
>political struggle afoot to cleave these packages from the BSD sources
>proper? Are these old, deprecated ports?
I'm a *nix newbie. I ran into this the other day. Had my system completely
up and running. (Internet gateway, NAT box, several other packages config'd
successfully). Decided I wanted to install Bind9.
I cvsup'd, and went in and installed Bind9 from ports.
Config'd it according to the bind9 doc, and when I started named, naturally
it started 8.2.4 (Free 4.4 Rel), rather than the 9.2.1.rc1 that I had
installed. Now I've got Bind installed twice, and have no idea what's the
best way to get it working properly.
I'll have to bait friends over with beer and pizza to get them to help me
fix :(
Is there doc for the ports tree apps ANYWHERE that describes locations that
things are installed to, or what config files are necessary, possibly even
how to admin different apps when installed from the ports tree??
(Especially since it seems that when installed from ports, it doesn't
install them in their default locations.. thus I have named in
/usr/local/sbin, and /usr/sbin...)
I'm a beginner, and my biggest help with my FreeBSD boxes is a linux guy,
who keeps telling me "FreeBSD is F'Kd up. They do things screwey".
My experiences with cvsup and installing from ports were excellent, until I
ran into the Bind prob.
Just my 2c.
John Ricker
Michael Lucas
This will stop the default system bind from starting.
You then should have a script in /usr/local/etc/rc.d to start the
correct bind. It's almost certainly there already, just prevented
from running by the default system bind.
--
Michael Lucas mwl...@FreeBSD.org, mwl...@BlackHelicopters.org
my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
http://www.blackhelicopters.org/~mwlucas/
Jerry A!
: I'm a *nix newbie. I ran into this the other day. Had my system completely
: up and running. (Internet gateway, NAT box, several other packages config'd
: successfully). Decided I wanted to install Bind9.
: I cvsup'd, and went in and installed Bind9 from ports.
: Config'd it according to the bind9 doc, and when I started named, naturally
: it started 8.2.4 (Free 4.4 Rel), rather than the 9.2.1.rc1 that I had
: installed. Now I've got Bind installed twice, and have no idea what's the
: best way to get it working properly.
: I'll have to bait friends over with beer and pizza to get them to help me
: fix :(
You should have named installed twice. All ports by default install
under the /usr/local hierarchy. See hier(7) for how the filesystems are
laid out.
You should also get used to reading through /etc/defaults/rc.conf and
seeing what the default values are for various apps. Then you'll know
what to set in /etc/rc.conf to override the defaults. See rc.conf(5)
for more details.
I shouldn't do this, but the quick answer to your question is to insert
the following in your /etc/rc.conf.
named_enable="YES"
named_program="/usr/local/sbin/named"
: Is there doc for the ports tree apps ANYWHERE that describes locations that
: things are installed to, or what config files are necessary, possibly even
: how to admin different apps when installed from the ports tree??
: (Especially since it seems that when installed from ports, it doesn't
: install them in their default locations.. thus I have named in
: /usr/local/sbin, and /usr/sbin...)
Check out the ports(7) man page. It's chock full o' goodness. There
you'll find a pointer to pkg_info(1) which is the program you'll use to
see the contents of an installed package/port.
Also, check out chapter 4 of the FreeBSD Handbook, "Installing
Applications: Packages and Ports".
: I'm a beginner, and my biggest help with my FreeBSD boxes is a linux guy,
: who keeps telling me "FreeBSD is F'Kd up. They do things screwey".
I can say the same thing about Linux. I can point out examples of
inconsistencies ad infinitum. Having an attitude like that doesn't
help. Point out that no two UNIX-like OS's have the exact same setups
or behave exactly the same. When I was starting out on this stuff a
long time ago, someone described this as "character" and "flavor".
: My experiences with cvsup and installing from ports were excellent, until I
: ran into the Bind prob.
Well, I hope I helped somewhat and that you've got the groundwork for
enjoying this stuff and making it work for you.
--Jerry
Open-Source software isn't a matter of life or death...
...It's much more important than that!
Jerry A!
: Set named_enable="NO" in /etc/rc.conf.
:
: This will stop the default system bind from starting.
:
: You then should have a script in /usr/local/etc/rc.d to start the
: correct bind. It's almost certainly there already, just prevented
: from running by the default system bind.
Actually, the current version of the bind9 port doesn't install any
startup files in /usr/local/etc/rc.d.
I believe that the expected behavior is to set "named_program" in
/etc/rc.conf.
Someone please correct me if I'm wrong, if I'm giving out
mis-information, I'd like to remedy that.
--Jerry
Open-Source software isn't a matter of life or death...
...It's much more important than that!
To Unsubscribe: send mail to majo...@FreeBSD.org
Pascal Hofstee
> Is there doc for the ports tree apps ANYWHERE that describes locations that
> things are installed to, or what config files are necessary, possibly even
> how to admin different apps when installed from the ports tree??
> (Especially since it seems that when installed from ports, it doesn't
> install them in their default locations.. thus I have named in
> /usr/local/sbin, and /usr/sbin...)
> I'm a beginner, and my biggest help with my FreeBSD boxes is a linux guy,
> who keeps telling me "FreeBSD is F'Kd up. They do things screwey".
>
> My experiences with cvsup and installing from ports were excellent, until I
> ran into the Bind prob.
I have no personal experience with installing Bind9 from ports.
The usual tendency for ports though is they either install their things
in /usr/local/* or /usr/X11R6/* in case USE_X_PREFIX is specified in
the ports Makefile.
In your case it's 100% certain that the /usr/local/* files are the Bind9
files ... with a rdnc.conf.sample put in /usr/local/etc/ (Documentation
will be in /usr/local/share/doc/bind9)
On default if you simply specify named_enable="YES" in /etc/rc.conf
rc.network will start up your bind executable on system boot.
If you check /etc/defaults/rc.conf you'll notice there are a few more
named-related rc.conf variables you can set. One of these being
named_program.
I think if you would put the following line into your /etc/rc.conf would
make FreeBSD start up your freshly installed Bind9 instead of the
default bind8 that comes with your base-system.
named_program="/usr/local/sbin/named"
I think you will have to consult the Bind9-port's documentation as to
where the port install of Bind9 will expect it's configuration.
As i said above already .. i have not ever tried this myself. But
according to my understanding of FreeBSD's rc and ports systems, this
should at least answer your question on how to get FreeBSD to start up
the new Bind9 ... and which files on your system will belong to which
version of Bind.
--
Pascal Hofstee <dae...@shadowmere.student.utwente.nl>
Michael Lucas
> Actually, the current version of the bind9 port doesn't install any
> startup files in /usr/local/etc/rc.d.
>
> I believe that the expected behavior is to set "named_program" in
> /etc/rc.conf.
No, I believe you're correct.
<puts on FreeBSD middle-aged geezer hat>
I haven't installed updated versions of BIND since 1997 or so, so my
knowledge is just a wee bit dated. Sorry.
==ml
--
Michael Lucas mwl...@FreeBSD.org, mwl...@BlackHelicopters.org
my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
http://www.blackhelicopters.org/~mwlucas/
To Unsubscribe: send mail to majo...@FreeBSD.org
Raoul Schroeder
>
>Because they don't ...stay unused. It's just convenient to have a
>standard, well- and widely-known piece of software around. You may not
>like it but both Sendmail and BIND are the de facto standards. Period.
>
I don't mind sendmail being the default, what I do mind is that after
every upgrade I need to find the new sendmail binary, delete it, and
point a link towards the qmail sendmail binary.
If all stayed in the same place, then there would be no problem.
Erick Mechler
:: point a link towards the qmail sendmail binary.
:: If all stayed in the same place, then there would be no problem.
Or you could investigate mailwrapper(8) and mailer.conf(5) which would
solve your problems, I do believe.
Cheers - Erick
Pete French
> every upgrade I need to find the new sendmail binary, delete it, and
> point a link towards the qmail sendmail binary.
Err - mailwrapper ? I hate sendmail too, my /etc/mail/mailer.conf looks
like this:
sendmail /usr/local/sbin/exim
send-mail /usr/local/sbin/exim
mailq /usr/local/sbin/exim
newaliases /usr/local/sbin/exim
...and it all "just works" when I upgrade. No hassle.
> If all stayed in the same place, then there would be no problem.
Methinks you are making it hard for yourself for some reason.
-pcf.
Mike Jakubik
I totally agree with you. Many programs that are integrated by default into
FreeBSD change much more often than FreeBSD does, OpenSSH being a good
example. Many people also dislike whats integrated i.e. sendmail (i
personally use postfix, cant stand sendmail). I would love to see a bare
FreeBSD install that stayed that way when updating via cvs. Perhaps an
option in the installation, that would also change the necessary
configurations to keep programs like sendmail out.
-----Original Message-----
From: owner-free...@FreeBSD.ORG
[mailto:owner-free...@FreeBSD.ORG]On Behalf Of Thomas Hurst
Sent: Wednesday, March 27, 2002 5:59 AM
To: sta...@FreeBSD.ORG
Subject: Re: HEADS UP: sendmail 8.12.2 MFC'ed
* Helge Oldach (helge....@atosorigin.com) wrote:
> Count this my strong vote against removal of packages that are
> traditionally part of the base system.
I hate sendmail with a passion. I use exim; hence it's just added
bloat sitting in my rather full /usr.
The existance of more up-to-date ports for a lot of what's in the base
system means many people don't want any trace of them from the base
system; e.g. Perl.
Additionally, many parts of the base system are not required or wanted
on simple systems; if I have a tiny 486 I want to turn into a firewall,
I don't want to spend hours trimming down the base system to fit on it.
I suggest we extend the package system to include the base system; then
I can just do env PKG_DBDIR=/var/db/syspkg pkg_deinstall sendmail-6.6.6,
and sysinstall can more easily NOT install things I don't want, without
impacting users who do want them.
Or maybe everyone who doesn't want to use sendmail should switch to
NetBSD w/ syspkg :)
Brooks Davis
>
> I totally agree with you. Many programs that are integrated by default into
> FreeBSD change much more often than FreeBSD does, OpenSSH being a good
> example. Many people also dislike whats integrated i.e. sendmail (i
> personally use postfix, cant stand sendmail). I would love to see a bare
> FreeBSD install that stayed that way when updating via cvs. Perhaps an
> option in the installation, that would also change the necessary
> configurations to keep programs like sendmail out.
If you'd like to do something other then pointlessly bitch and moan
about the situation, head on over to the libh project which aims to
create a new installer and packaging system that together with the
NetBSD /etc/rc.d system might someday allow this. Join the mailing list
and find something useful to do.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Yeasah Pell
> > I suggest we extend the package system to include the base system; then
> > I can just do env PKG_DBDIR=/var/db/syspkg pkg_deinstall sendmail-6.6.6,
> > and sysinstall can more easily NOT install things I don't want, without
> > impacting users who do want them.
>
> Congratulations! You are the 1,000th person to volunteer to do this.
> When may we expect the patches?
You seem to be indicating that this is popularly held to be the right thing
to do, but that nobody has the time to do it. Is this true?
In any case, you evidently missed Thomas' signature from the above-quoted
message... guess we won't have a volunteer here. ;-)
/Yeasah
>--
>Thomas 'Freaky' Hurst - fre...@aagh.net - http://www.aagh.net/
>-
>Lackland's Laws:
>(1) Never be first.
>(2) Never be last.
>(3) Never volunteer for anything
Paul David Fardy
>>> The question is simply this: why are there large, complex, non-BSD
>>> packages in src-contrib that are not critical to the running of many
>>> types of systems, and not strictly a dependency of the system proper?
Helge Oldach(helge....@atosorigin.com)@2002.03.27 09:36:19 +0000:
>> Because they always have been...
>> ...
>> This BSD thing is about tradition. "Alternative" software is what the
>> word says: It's about re-inventing the wheel. This is the Linux spirit.
I'd use "heritage" rather that tradition. Some recognition of
heritage is due. After all, BIND *is* the *Berkeley* Internet Name
Daemon and Sendmail was an important part of BSD <= 4.4BSD. But,
while heritage may influence Sendmail's continued existence in
contrib, isn't why it's stayed around--not directly anyway.
On Wednesday, March 27, 2002, at 05:29 AM, Karsten W. Rohrbach wrote:
> wrong, it is called evolution, a natural way of things evolving which
> does not stop just because somebody puts up a sign "this is bsd, we do
> it this way since 1970 and it won't change in the future". this has
> nothing to do with linux at all. it is also not about re-inventing the
> wheel. you seem to mix up the terms "tradition" and "religion" here,
> introducing an implicit amount of folklore, hoping that it will support
> your nonexistant line of argumentation.
I think you're going to far ascribing "religion" to Helge's "tradition".
But I agree that "It's always been done that way." isn't a strong
argument.
> when it comes to tradition, i cannot remember a single freebsd
> distribution which natively supports to be booted from tape.
I don't think every version of BSD did either. And I would bet
good money that *noone* has a tape loading FreeBSD dist. :-)
But the point is well taken: there's got to be more to the
argument than that, ... and there is...
> to come back to your original thought, do you consider having sendmail
> on a firewall a good thing[tm]? sell that to your customers and prove me
> that you do this successfully. this, just as a sidenote.
Actually, many people do use Sendmail on their firewalls. I've even done
some consulting on just such a beast. And I'm not convinced that any other
MTA is inherently safer. Sendmail gets the bulk of the abuse and still
critical in keeping Internet mail going.
> as another sidenote, nobody prevents you from building a package
> yourself on a machine having a ports tree installed.
But, then again, noone prevents you from
# rm /usr/sbin/sendmail*
either.
Ultimately, it's not about tradition or heritage and it's not about
evolution, either. The real argument for keeping them runs like this:
Sendmail and BIND work. Sendmail and BIND remain in active development.
And, most importantly, each is actively maintained by FreeBSD committers.
Pulling them out of contrib is not evolution, but revolution. You'll have
to convince freebsd-core that it's better for [who?] to maintain [what?]
than to continue letting Greg Shapiro--who's FreeBSD work may even been
supported by Sendmail, Inc. Greg's work, alone, is enough to keep it in
contrib. Greg ensures that "it ain't broke, so don't fix it."
It seems to me that most people are content, if not happy, with Sendmail.
And I don't think it just those old farts that actually learned enough
to know why "R$-!$+ $@$>Canonify2 $2<@$1.UUCP>" was very useful (and
still be useful somewhere :-).
Helge Oldach(helge....@atosorigin.com)@2002.03.27 09:36:19 +0000:
>> Count this my strong vote against removal of packages that are
>> traditionally part of the base system.
Count this my strong vote for keeping working contributed software just
where it is.
Paul
--
PS Does anyone know where I can find a PCI/UNIBUS adapter? :-)
Yeasah Pell
From: "Paul David Fardy" <pdf...@mac.com>
> Ultimately, it's not about tradition or heritage and it's not about
> evolution, either. The real argument for keeping them runs like this:
> Sendmail and BIND work. Sendmail and BIND remain in active development.
> And, most importantly, each is actively maintained by FreeBSD committers.
>
> Pulling them out of contrib is not evolution, but revolution. You'll have
> to convince freebsd-core that it's better for [who?] to maintain [what?]
> than to continue letting Greg Shapiro--who's FreeBSD work may even been
> supported by Sendmail, Inc. Greg's work, alone, is enough to keep it in
> contrib. Greg ensures that "it ain't broke, so don't fix it."
From this posting and others, I'm starting to get the impression that the
real, underlying reason that sendmail and bind remain in src-contrib is that
the maintainers are developing/maintaining at a rate that would make
generating port patches and doing port versions prohibitively time
consuming. I can definitely appreciate the strength of that argument.
It would be possible (in principle) to have the ports system be able to pull
source from a seperate FreeBSD src tree, instead of a distribution tarball
and patches (maybe even directly from src-contrib). I wonder if there are
other ports that are really pretty highly customized for FreeBSD that would
work better as vendor branch CVS imports (like sendmail is, I presume). Has
this been considered already? This could certainly help the ~50% packages in
src-contrib that are duplicated in the ports tree, which I feel is a
deplorable state of affairs.
I guess that it would be appropriate to list what I feel are the advantages
of moving these packages out of src-contrib:
1) It feels much more logical and consistent. This is roughly analagous in
strength to the "tradition" or "heritage" argument for keeping them in
src-contrib, so I figured I'd include it.
2) Security. The interests of system security dictates that you include as
little as possible in a default system, and allow additional software to be
added on *as needed*.
3) Management. I can pick a version, upgrade, downgrade, switch to a
different but similar software package, and stop using the software
altogether all without having to touch any other part of the system.
4) Insulation. People not using the software will not be affected by changes
to the software, as recently happened with sendmail.
5) Cohesion. Some software lives in both src-contrib and ports (in fact
about half of src-contrib, by my count). Having two sources for the same
software has all sorts of problems. Bugs/security holes need to be fixed in
two places. People get confused as to which software they are running, and
under what circumstances. In extreme cases, both software packages could
come into use in different contexts, and if they were divergent and
incompatible versions... well, you get the point. (Some people have
characterized this as adding "character" to the system, which boggles my
mind.)
The arguments that I've heard so far to keep them in src-contrib:
1) Tradition/heritage. It's part of BSD, and people expect it to be there.
2) They are in active FreeBSD-specific development (which isn't readily
accomodated by the ports system as it stands)
3) We'd lose the contribution of Greg if sendmail was moved out of the core
system. (Could this possibly be true?? I assume that Greg would eventually
become involved in the discourse if it looked like something would actually
happen, and his veto would definitely shut down the possibility of doing any
of this. Some people are just That Important.)
I'm sure I missed points on both sides. Comments?
It also occurs to me that pro-port items 1, 2 and 4 could be at least partly
accomplished with changes to the installer, as follows:
* BIND, sendmail, and anything else in src that might fall on the other side
of the razor are moved into a different distribution set for the installer,
similar to the non-port XFree86. They could be selected by default -- the
main idea is to allow a person to install FreeBSD from media without
packages that aren't _logically_ part of the core system (heritage and
tradition notwithstanding)
* It'd definitely be nice if a skeleton make.conf was set up based on which
distribution sets were selected during the install -- even if BIND and
sendmail are never changed at all. This would mean somebody who installed a
stripped down FreeBSD system wouldn't unexpectedly get all those packages
when they started tracking a branch.
Unfortunately, I don't know much about the installer or the generation of
distribution sets, so I have no idea if that would be difficult or not.
/Yeasah
Calvin NG
Perhaps those who have a different perference then the choices
made by the FreeBSD developers should read up on the
various NO_xxx settings that are can be used in /etc/make.conf
for the purpose to not building the software that you do not want.
(and also prevent overwriting your favourite software that
you choose to install in base)
In addition, you can also choose add a refuse file in /usr/sup/src-all/
to NOT cvsup those sendmail/bind/kerberos/... source code
that you do not intend to build anyway. Do be careful of
dependencies though.
With the above in consideration, removing sendmail/bind/whatever/....
is a one time effort, and it will stays that way.
There are ways for you to customise your system, and ensure that
it stays that way even when you upgrade (via cvsup).
Regards,
/calvin
lines with :> are quotes from Mike Jakubik's email
:>
:> I totally agree with you. Many programs that are integrated by default into
Scott Lambert
> > I don't mind sendmail being the default, what I do mind is that after
> > every upgrade I need to find the new sendmail binary, delete it, and
> > point a link towards the qmail sendmail binary.
>
> Err - mailwrapper ? I hate sendmail too, my /etc/mail/mailer.conf looks
> like this:
>
> sendmail /usr/local/sbin/exim
> send-mail /usr/local/sbin/exim
> mailq /usr/local/sbin/exim
> newaliases /usr/local/sbin/exim
Except that with the rc.conf changes to sendmail_enable you now need to
start your MTA from /usr/local/etc/rc.d/{qmail|postfix|exim|...}.sh or
rc.local and setting sendmail_enable=NO rather than it just working once
you fixup mailer.conf.
I think this patch pretty much does away with the arguments that the
sendmail_* rc.conf variables should be mta_* as it pretty much makes the
knob useless for any other mailer with a sendmail compatible interface.
I'm not complaining about it. I do like I'm supposed to and read
FreeBSD-STABLE. :-) Now I know I have to do some extra work the
next time I upgrade a -STABLE system. If I get bitten it's *my* fault.
--
Scott Lambert KC5MLE Unix SysAdmin
lam...@lambertfam.org http://www.lambertfam.org/~lambert/resume.html
3 years Sr. SysAdmin experience with FreeBSD in small & medium size ISPs.
To Unsubscribe: send mail to majo...@FreeBSD.org
Vladislav V. Zhuk
>
> This will stop the default system bind from starting.
>
> You then should have a script in /usr/local/etc/rc.d to start the
> correct bind. It's almost certainly there already, just prevented
> from running by the default system bind.
You are forget about: dig, host, nslookup, nsupdate and other
utilities from bind package.
--
Vladislav V. Zhuk (06267)3-60-03 ad...@dru.dn.ua 2:465/1...@FidoNet.org
Pete French
> start your MTA from /usr/local/etc/rc.d/{qmail|postfix|exim|...}.sh or
> rc.local and setting sendmail_enable=NO rather than it just working once
> you fixup mailer.conf.
Why ? The way I read the changes was that if I set sendmail_enable to YES and
the rest to NO it will start sendmail in the normal way, and thus
via the magic of mailwarpper start whatever MTA I have instead. No changes
necessary to the way I currently do things at all.
-pcf.