Re: Oversight in /etc/defaults/rc.conf

[Ryan Stone]

On Tue, Jul 12, 2016 at 10:50 AM, RW  wrote:

> Unless I'm misunderstanding the situation. rc.d/iovctl isn't actually
> doing anything by default because of iovctl_files="".
>
> There is an analogy with rc.d/sysctl which runs by default, with a
> an empty sysctl.conf file. This also has no explicit enable entry in
> rc.conf.
>

That is how it is intended to work, and rc.d/sysctl was the inspiration for
that script if memory serves.  I'm not entirely opposed to an iovctl_enable
variable but it seems redundant.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Oversight in /etc/defaults/rc.conf

[Rodney W. Grimes]

> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===============
> >> --- etc/defaults/rc.conf   (revision 302482)
> >> +++ etc/defaults/rc.conf   (working copy)
> >> @@ -695,6 +695,7 @@
> >>  rctl_enable="YES" # Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"   # rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
    Missing explination of knob
> >>  iovctl_files=""   # Config files for iovctl(8)
> >>
> >>  ##
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 
> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"

What ever is resolved you also need to add a # comment describing it.

> 
> instead?
> 
>   Cheers,
> 
>   Matthew

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Oversight in /etc/defaults/rc.conf

[RW]

On Tue, 12 Jul 2016 15:10:43 +0100
Matthew Seaman wrote:


> I'm not religious about it being turned off per se.  More that it
> should have a clearly defined on/off state shown in the defaults.
> 
> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?

Unless I'm misunderstanding the situation. rc.d/iovctl isn't actually
doing anything by default because of iovctl_files="".

There is an analogy with rc.d/sysctl which runs by default, with a
an empty sysctl.conf file. This also has no explicit enable entry in
rc.conf. 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Oversight in /etc/defaults/rc.conf

[Glen Barber]

On Tue, Jul 12, 2016 at 03:10:43PM +0100, Matthew Seaman wrote:
> On 07/12/16 13:27, Glen Barber wrote:
> > On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> >> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> >> fine -- however I did notice that the new iovctl rc script is apparently
> >> enabled by default.  That seems like a trivial omission:
> >>
> >> Index: etc/defaults/rc.conf
> >> ===============
> >> --- etc/defaults/rc.conf   (revision 302482)
> >> +++ etc/defaults/rc.conf   (working copy)
> >> @@ -695,6 +695,7 @@
> >>  rctl_enable="YES" # Load rctl(8) rules on boot
> >>  rctl_rules="/etc/rctl.conf"   # rctl(8) ruleset. See rctl.conf(5).
> >>
> >> +iovctl_enable="NO"
> >>  iovctl_files=""   # Config files for iovctl(8)
> >>
> >>  ##
> >>
> > 
> > I'm not sure I understand.  Is there a functional and/or performance
> > impact with it enabled by default?  (Note, I don't disable it in my
> > rc.conf, and there is no /dev/iov/* on my system.)
> 
> I'm not religious about it being turned off per se.  More that it should
> have a clearly defined on/off state shown in the defaults.
> 

Ah, this was my confusion.  Thank you for clarifying.

> I went for 'off' following the general principle that rc.conf items
> should mostly be off by default and require specific action to enable.
> Yes, there are exceptions to this rule, but I see no particular reason
> that iovctl should be one.  What's the advantage to turning it on by
> default on every FreeBSD installation?
> 
> However, even if it's felt it should be enabled everywhere, then
> shouldn't /etc/defaults/rc.conf have:
> 
> iovctl_enable="YES"
> 
> instead?
> 

I'm not pro -vs- con either way.  But I think this should be resolved in
head first, and MFC'd to stable/11, as this isn't something I think
should be in the "checklist" when branching.  I think you are really
pointing out a different "bug" here.

Glen



signature.asc
Description: PGP signature

Re: Oversight in /etc/defaults/rc.conf

[Matthew Seaman]

On 07/12/16 13:27, Glen Barber wrote:
> On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
>> I just upgraded my main machine to 11-STABLE.  Things are mostly working
>> fine -- however I did notice that the new iovctl rc script is apparently
>> enabled by default.  That seems like a trivial omission:
>>
>> Index: etc/defaults/rc.conf
>> ===========
>> --- etc/defaults/rc.conf (revision 302482)
>> +++ etc/defaults/rc.conf (working copy)
>> @@ -695,6 +695,7 @@
>>  rctl_enable="YES"   # Load rctl(8) rules on boot
>>  rctl_rules="/etc/rctl.conf" # rctl(8) ruleset. See rctl.conf(5).
>>
>> +iovctl_enable="NO"
>>  iovctl_files="" # Config files for iovctl(8)
>>
>>  ##
>>
> 
> I'm not sure I understand.  Is there a functional and/or performance
> impact with it enabled by default?  (Note, I don't disable it in my
> rc.conf, and there is no /dev/iov/* on my system.)

I'm not religious about it being turned off per se.  More that it should
have a clearly defined on/off state shown in the defaults.

I went for 'off' following the general principle that rc.conf items
should mostly be off by default and require specific action to enable.
Yes, there are exceptions to this rule, but I see no particular reason
that iovctl should be one.  What's the advantage to turning it on by
default on every FreeBSD installation?

However, even if it's felt it should be enabled everywhere, then
shouldn't /etc/defaults/rc.conf have:

iovctl_enable="YES"

instead?

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: Oversight in /etc/defaults/rc.conf

[Allan Jude]

On 2016-07-12 08:27, Glen Barber wrote:
> On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
>> I just upgraded my main machine to 11-STABLE.  Things are mostly working
>> fine -- however I did notice that the new iovctl rc script is apparently
>> enabled by default.  That seems like a trivial omission:
>>
>> Index: etc/defaults/rc.conf
>> ===========
>> --- etc/defaults/rc.conf (revision 302482)
>> +++ etc/defaults/rc.conf (working copy)
>> @@ -695,6 +695,7 @@
>>  rctl_enable="YES"   # Load rctl(8) rules on boot
>>  rctl_rules="/etc/rctl.conf" # rctl(8) ruleset. See rctl.conf(5).
>>
>> +iovctl_enable="NO"
>>  iovctl_files="" # Config files for iovctl(8)
>>
>>  ##
>>
> 
> I'm not sure I understand.  Is there a functional and/or performance
> impact with it enabled by default?  (Note, I don't disable it in my
> rc.conf, and there is no /dev/iov/* on my system.)
> 
> Glen
> 

If the service should be on by default, then it should have
iovctl_enable="YES" in etc/defaults/rc.conf

One way or the other, a default should be set.

-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Oversight in /etc/defaults/rc.conf

[Glen Barber]

On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
> I just upgraded my main machine to 11-STABLE.  Things are mostly working
> fine -- however I did notice that the new iovctl rc script is apparently
> enabled by default.  That seems like a trivial omission:
> 
> Index: etc/defaults/rc.conf
> =======
> --- etc/defaults/rc.conf  (revision 302482)
> +++ etc/defaults/rc.conf  (working copy)
> @@ -695,6 +695,7 @@
>  rctl_enable="YES"# Load rctl(8) rules on boot
>  rctl_rules="/etc/rctl.conf"  # rctl(8) ruleset. See rctl.conf(5).
> 
> +iovctl_enable="NO"
>  iovctl_files=""  # Config files for iovctl(8)
> 
>  ##
> 

I'm not sure I understand.  Is there a functional and/or performance
impact with it enabled by default?  (Note, I don't disable it in my
rc.conf, and there is no /dev/iov/* on my system.)

Glen



signature.asc
Description: PGP signature

Oversight in /etc/defaults/rc.conf

[Matthew Seaman]

I just upgraded my main machine to 11-STABLE.  Things are mostly working
fine -- however I did notice that the new iovctl rc script is apparently
enabled by default.  That seems like a trivial omission:

Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(revision 302482)
+++ etc/defaults/rc.conf(working copy)
@@ -695,6 +695,7 @@
 rctl_enable="YES"  # Load rctl(8) rules on boot
 rctl_rules="/etc/rctl.conf"# rctl(8) ruleset. See rctl.conf(5).

+iovctl_enable="NO"
 iovctl_files=""# Config files for iovctl(8)

 ##

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Greg Rivers]

On Tue, 12 Nov 2013, Erwin Lansing wrote:

Sorry about the delay, but I did finally update all three dns/bind9* 
ports today.




Thanks a lot for your work on this very important port.

I have dropped the complicated chroot, and related symlinking, logic 
from the default rc script as I don't think that is the right place to 
implement things.




I am somewhat astonished by this decision.  FreeBSD has been running named 
chrooted for as long as I can remember.  One of the really nice things 
about running BIND on FreeBSD has been that it came perfectly configured 
out of the box.  I think a lot of people are going to be surprised by 
this.


Maybe the rc script is the wrong place to set up the chroot, but shouldn't 
the port at least set it up at install time?  Without this, there is going 
to be a lot of duplicated and error prone effort with everyone setting up 
their own chroot environment.


I would recommend users who want the extra security to use jail(8) 
instead of a mere chroot.




Is it the consensus that running named chrooted doesn't really add 
additional security?  If a jail is that much better, shouldn't the port 
set up an appropriately configured jail so that we once again have 
everything working out of the box?


Maybe the Capsicum framework will supersede both chroots and jails for 
added BIND security, but until then, shouldn't the chroot feature be 
retained?


--
Greg Rivers
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Yasuhiro KIMURA]

From: Erwin Lansing er...@freebsd.org
Subject: Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
Date: Tue, 12 Nov 2013 12:13:23 +0100

 Sorry about the delay, but I did finally update all three dns/bind9*
 ports today.  I have dropped the complicated chroot, and related
 symlinking, logic from the default rc script as I don't think that
 is the right place to implement things.  I would recommend users
 who want the extra security to use jail(8) instead of a mere chroot.
 
 This change should not affect the installed base of FreeBSD 9.x and
 earlier systems, but new installations there should note that the
 symlink option is no longer turned on by default, but still supported.
 
 I tested some default cases, but by no means can test every corner case,
 so please let me know how this works out.

Please merge r257694 to stable/10 because remnants of BIND are still left.

Best Regards.

---
Yasuhiro KIMURA
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[George Kontostanos]

On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing er...@freebsd.org wrote:

 On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote:
   E 
   E  Erwin, can you please handle that?
   E
   E Things are much worse that this, the ports are completely written
 under the assumption that there is a Bind in base, which of course would
 already break with WITHOUT_BIND before Bind was completely removed.  It
 will be hard to fix without breaking the installed base of 8 and 9.  Sigh.
   E
   E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.
  
   Suggestion. An option to install the rc script would solve that
 problem.
  
 
  If only it was that simple, it would have been done a long time ago.  As
 Gleb points out, the ports are broken by design.  The rc script needs a
 complete rewrite, and that's only after fixing all configuration files,
 setting up chroot, etc etc and all that while not breaking the installed
 base on 8 and 9.  I spent most of yesterday on this and if I'm lucky, I'm
 halfway through.
 


 Sorry about the delay, but I did finally update all three dns/bind9*
 ports today.  I have dropped the complicated chroot, and related
 symlinking, logic from the default rc script as I don't think that
 is the right place to implement things.  I would recommend users
 who want the extra security to use jail(8) instead of a mere chroot.

 This change should not affect the installed base of FreeBSD 9.x and
 earlier systems, but new installations there should note that the
 symlink option is no longer turned on by default, but still supported.

 I tested some default cases, but by no means can test every corner case,
 so please let me know how this works out.

 Best,
 Erwin


Excellent thanks so much!

If you had named running using the old rc scripts and config in 10 you will
need to:

1) Backup your zones  stop named
2) Delete /var/named/*
3) Create a new symlink in etc to /usr/local/etc/namedb
4) Restore your zones
5) Start named from the new rc script

-- 
George Kontostanos
---
http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[George Kontostanos]

On Wed, Nov 13, 2013 at 7:59 PM, George Kontostanos
gkontos.m...@gmail.comwrote:

 On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing er...@freebsd.org wrote:

 On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote:
   E 
   E  Erwin, can you please handle that?
   E
   E Things are much worse that this, the ports are completely written
 under the assumption that there is a Bind in base, which of course would
 already break with WITHOUT_BIND before Bind was completely removed.  It
 will be hard to fix without breaking the installed base of 8 and 9.  Sigh.
   E
   E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.
  
   Suggestion. An option to install the rc script would solve that
 problem.
  
 
  If only it was that simple, it would have been done a long time ago.
  As Gleb points out, the ports are broken by design.  The rc script needs a
 complete rewrite, and that's only after fixing all configuration files,
 setting up chroot, etc etc and all that while not breaking the installed
 base on 8 and 9.  I spent most of yesterday on this and if I'm lucky, I'm
 halfway through.
 


 Sorry about the delay, but I did finally update all three dns/bind9*
 ports today.  I have dropped the complicated chroot, and related
 symlinking, logic from the default rc script as I don't think that
 is the right place to implement things.  I would recommend users
 who want the extra security to use jail(8) instead of a mere chroot.

 This change should not affect the installed base of FreeBSD 9.x and
 earlier systems, but new installations there should note that the
 symlink option is no longer turned on by default, but still supported.

 I tested some default cases, but by no means can test every corner case,
 so please let me know how this works out.

 Best,
 Erwin


 Excellent thanks so much!

 If you had named running using the old rc scripts and config in 10 you
 will need to:

 1) Backup your zones  stop named
 2) Delete /var/named/*
 3) Create a new symlink in etc to /usr/local/etc/namedb
 4) Restore your zones
 5) Start named from the new rc script


Sorry I forgot also that if if you don't specify the location of named in
the rc.conf:

named_program=/usr/local/sbin/named

You will get an error message:

root@hp:/etc # /usr/local/etc/rc.d/named start
/usr/local/etc/rc.d/named: WARNING: run_rc_command: cannot run
/usr/sbin/named

Those are observations from a test machine that I use which was running
bind with the old rc style.

Thanks

-- 
George Kontostanos
---
http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Erwin Lansing]

On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote:
  E 
  E  Erwin, can you please handle that?
  E
  E Things are much worse that this, the ports are completely written under 
  the assumption that there is a Bind in base, which of course would already 
  break with WITHOUT_BIND before Bind was completely removed.  It will be 
  hard to fix without breaking the installed base of 8 and 9.  Sigh.
  E
  E I'll try to work on it this week, but unfortunately have a full 
  schedule of meetings and travel as well.
  
  Suggestion. An option to install the rc script would solve that problem. 
   
 
 If only it was that simple, it would have been done a long time ago.  As Gleb 
 points out, the ports are broken by design.  The rc script needs a complete 
 rewrite, and that's only after fixing all configuration files, setting up 
 chroot, etc etc and all that while not breaking the installed base on 8 and 
 9.  I spent most of yesterday on this and if I'm lucky, I'm halfway through.  
 


Sorry about the delay, but I did finally update all three dns/bind9*
ports today.  I have dropped the complicated chroot, and related
symlinking, logic from the default rc script as I don't think that
is the right place to implement things.  I would recommend users
who want the extra security to use jail(8) instead of a mere chroot.

This change should not affect the installed base of FreeBSD 9.x and
earlier systems, but new installations there should note that the
symlink option is no longer turned on by default, but still supported.

I tested some default cases, but by no means can test every corner case,
so please let me know how this works out.

Best,
Erwin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[George Kontostanos]

On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff gleb...@freebsd.org wrote:

 On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote:
 E  On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
 E  G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org
 :
 E  G 
 E  G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 E  G   Ö Altough bind removed from FreeBSD 10 distribution,
 /etc/rc.d/named
 E  G  script
 E  G   Ö still exists.
 E  G   Ö and this script depends on /etc/mtree/BIND.chroot.dist
 file but
 E  G  there is
 E  G   Ö no such file in source tree.
 E  G   Ö I think this file was forgotten to be removed.
 E  G   Ö
 E  G   Ö And also, named_* definitions still exists in
 /etc/defaults/rc.conf
 E  G  file.
 E  G  
 E  G   Please review attached file that removes named from /etc.
 E  G 
 E  G  It would be great if the port would learn to install its own
 script etc.
 E  G  in time for that change. (Unless it’s already there, and I’m
 just too blind
 E  G  to see it.)
 E  G
 E  G No you are not blind. Installing bind from ports still relies on
 the
 E  G /etc/rc.d/named script.
 E 
 E  Erwin, can you please handle that?
 E
 E Things are much worse that this, the ports are completely written under
 the assumption that there is a Bind in base, which of course would already
 break with WITHOUT_BIND before Bind was completely removed.  It will be
 hard to fix without breaking the installed base of 8 and 9.  Sigh.
 E
 E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.


Suggestion. An option to install the rc script would solve that problem.



 What should we do with src?

 IMO, we should proceed with removal of remnants of bind in src. In the
 worst case,
 if you can't handle it this week, the situation will be the following:

 1) 8.x, 9.x users are okay
 2) 10+.x users w/o bind are okay
 3) 10+.x users with bind have problems

 If we skip updating src, then situation would be:

 1) 8.x, 9.x users are okay
 2) 10+.x users w/o bind have problems
 3) 10+.x users with bind are okay

 I think, there are less 10.x users with bind, than 10.x without it.


Please warn about this in UPDATING. I am personally use 12 FreeBSD servers
as dedicated DNS servers only.


 --
 Totus tuus, Glebius.




-- 
George Kontostanos
---
http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Gleb Smirnoff]

On Wed, Nov 06, 2013 at 03:22:03PM +0200, George Kontostanos wrote:
G  IMO, we should proceed with removal of remnants of bind in src. In the
G  worst case,
G  if you can't handle it this week, the situation will be the following:
G 
G  1) 8.x, 9.x users are okay
G  2) 10+.x users w/o bind are okay
G  3) 10+.x users with bind have problems
G 
G  If we skip updating src, then situation would be:
G 
G  1) 8.x, 9.x users are okay
G  2) 10+.x users w/o bind have problems
G  3) 10+.x users with bind are okay
G 
G  I think, there are less 10.x users with bind, than 10.x without it.
G 
G Please warn about this in UPDATING. I am personally use 12 FreeBSD servers
G as dedicated DNS servers only.

Erwin is now working on fixing the ports. Ports will be fixed soon.

Actually ports were not correct even for older branches, because relying
on a script from /etc/rc.d for a port is incorrect behavior.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Stefan Bethke]

Am 06.11.2013 um 14:59 schrieb Erwin Lansing:

 Suggestion. An option to install the rc script would solve that problem.  
 
 If only it was that simple, it would have been done a long time ago.  As Gleb 
 points out, the ports are broken by design.  The rc script needs a complete 
 rewrite, and that's only after fixing all configuration files, setting up 
 chroot, etc etc and all that while not breaking the installed base on 8 and 
 9.  I spent most of yesterday on this and if I'm lucky, I'm halfway through.

I'm very grateful for all that work going into making sure that people are not 
left stranded without working DNS after an upgrade.

Thank you Erwin!


Stefan

-- 
Stefan Bethke s...@lassitu.de   Fon +49 151 14070811

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[George Kontostanos]

On Wed, Nov 6, 2013 at 3:59 PM, Erwin Lansing er...@lansing.dk wrote:



 On 06/11/2013, at 14.22, George Kontostanos gkontos.m...@gmail.com
 wrote:

 On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff gleb...@freebsd.org wrote:

 On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote:
 E  On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
 E  G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff 
 gleb...@freebsd.org:
 E  G 
 E  G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 E  G   Ö Altough bind removed from FreeBSD 10 distribution,
 /etc/rc.d/named
 E  G  script
 E  G   Ö still exists.
 E  G   Ö and this script depends on /etc/mtree/BIND.chroot.dist
 file but
 E  G  there is
 E  G   Ö no such file in source tree.
 E  G   Ö I think this file was forgotten to be removed.
 E  G   Ö
 E  G   Ö And also, named_* definitions still exists in
 /etc/defaults/rc.conf
 E  G  file.
 E  G  
 E  G   Please review attached file that removes named from /etc.
 E  G 
 E  G  It would be great if the port would learn to install its own
 script etc.
 E  G  in time for that change. (Unless it’s already there, and I’m
 just too blind
 E  G  to see it.)
 E  G
 E  G No you are not blind. Installing bind from ports still relies on
 the
 E  G /etc/rc.d/named script.
 E 
 E  Erwin, can you please handle that?
 E
 E Things are much worse that this, the ports are completely written
 under the assumption that there is a Bind in base, which of course would
 already break with WITHOUT_BIND before Bind was completely removed.  It
 will be hard to fix without breaking the installed base of 8 and 9.  Sigh.
 E
 E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.


 Suggestion. An option to install the rc script would solve that problem.



 If only it was that simple, it would have been done a long time ago.  As
 Gleb points out, the ports are broken by design.  The rc script needs a
 complete rewrite, and that's only after fixing all configuration files,
 setting up chroot, etc etc and all that while not breaking the installed
 base on 8 and 9.  I spent most of yesterday on this and if I'm lucky, I'm
 halfway through.

 Erwin, sent from a phone at the train station


Thank you all for your effort!

-- 
George Kontostanos
---
http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Gleb Smirnoff]

  [adding maintainer to Cc]

On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org:
G 
G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
G   Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named
G  script
G   Ö still exists.
G   Ö and this script depends on /etc/mtree/BIND.chroot.dist file but
G  there is
G   Ö no such file in source tree.
G   Ö I think this file was forgotten to be removed.
G   Ö
G   Ö And also, named_* definitions still exists in /etc/defaults/rc.conf
G  file.
G  
G   Please review attached file that removes named from /etc.
G 
G  It would be great if the port would learn to install its own script etc.
G  in time for that change. (Unless it’s already there, and I’m just too blind
G  to see it.)
G 
G No you are not blind. Installing bind from ports still relies on the
G /etc/rc.d/named script.

Erwin, can you please handle that?

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Erwin Lansing]

On 04 Nov 2013, at 09:34, Gleb Smirnoff gleb...@freebsd.org wrote:

  [adding maintainer to Cc]
 
 On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
 G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org:
 G 
 G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 G   Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named
 G  script
 G   Ö still exists.
 G   Ö and this script depends on /etc/mtree/BIND.chroot.dist file but
 G  there is
 G   Ö no such file in source tree.
 G   Ö I think this file was forgotten to be removed.
 G   Ö
 G   Ö And also, named_* definitions still exists in /etc/defaults/rc.conf
 G  file.
 G  
 G   Please review attached file that removes named from /etc.
 G 
 G  It would be great if the port would learn to install its own script etc.
 G  in time for that change. (Unless it’s already there, and I’m just too 
 blind
 G  to see it.)
 G 
 G No you are not blind. Installing bind from ports still relies on the
 G /etc/rc.d/named script.
 
 Erwin, can you please handle that?

Things are much worse that this, the ports are completely written under the 
assumption that there is a Bind in base, which of course would already break 
with WITHOUT_BIND before Bind was completely removed.  It will be hard to fix 
without breaking the installed base of 8 and 9.  Sigh.

I'll try to work on it this week, but unfortunately have a full schedule of 
meetings and travel as well.

Erwin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Gleb Smirnoff]

On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote:
E  On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
E  G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org:
E  G 
E  G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
E  G   Ö Altough bind removed from FreeBSD 10 distribution, 
/etc/rc.d/named
E  G  script
E  G   Ö still exists.
E  G   Ö and this script depends on /etc/mtree/BIND.chroot.dist file but
E  G  there is
E  G   Ö no such file in source tree.
E  G   Ö I think this file was forgotten to be removed.
E  G   Ö
E  G   Ö And also, named_* definitions still exists in 
/etc/defaults/rc.conf
E  G  file.
E  G  
E  G   Please review attached file that removes named from /etc.
E  G 
E  G  It would be great if the port would learn to install its own script 
etc.
E  G  in time for that change. (Unless it’s already there, and I’m just too 
blind
E  G  to see it.)
E  G 
E  G No you are not blind. Installing bind from ports still relies on the
E  G /etc/rc.d/named script.
E  
E  Erwin, can you please handle that?
E 
E Things are much worse that this, the ports are completely written under the 
assumption that there is a Bind in base, which of course would already break 
with WITHOUT_BIND before Bind was completely removed.  It will be hard to fix 
without breaking the installed base of 8 and 9.  Sigh.
E 
E I'll try to work on it this week, but unfortunately have a full schedule of 
meetings and travel as well.

What should we do with src? 

IMO, we should proceed with removal of remnants of bind in src. In the worst 
case,
if you can't handle it this week, the situation will be the following:

1) 8.x, 9.x users are okay
2) 10+.x users w/o bind are okay
3) 10+.x users with bind have problems

If we skip updating src, then situation would be:

1) 8.x, 9.x users are okay
2) 10+.x users w/o bind have problems
3) 10+.x users with bind are okay

I think, there are less 10.x users with bind, than 10.x without it.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Özkan KIRIK]

Hi,

Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named script
still exists.
and this script depends on /etc/mtree/BIND.chroot.dist file but there is
no such file in source tree.
I think this file was forgotten to be removed.

And also, named_* definitions still exists in /etc/defaults/rc.conf file.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Gleb Smirnoff]

On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named script
Ö still exists.
Ö and this script depends on /etc/mtree/BIND.chroot.dist file but there is
Ö no such file in source tree.
Ö I think this file was forgotten to be removed.
Ö 
Ö And also, named_* definitions still exists in /etc/defaults/rc.conf file.

Please review attached file that removes named from /etc.

-- 
Totus tuus, Glebius.
Index: etc/defaults/periodic.conf
===
--- etc/defaults/periodic.conf	(revision 257584)
+++ etc/defaults/periodic.conf	(working copy)
@@ -137,10 +137,6 @@ daily_status_mail_rejects_enable=YES			# Check m
 daily_status_mail_rejects_logs=3			# How many logs to check
 daily_status_mail_rejects_shorten=NO			# Shorten output
 
-# 470.status-named
-daily_status_named_enable=YES
-daily_status_named_usedns=YES# DNS lookups are ok
-
 # 480.status-ntpd
 daily_status_ntpd_enable=NO# Check NTP status
 
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf	(revision 257584)
+++ etc/defaults/rc.conf	(working copy)
@@ -256,6 +256,7 @@ hostapd_enable=NO		# Run hostap daemon.
 syslogd_enable=YES		# Run syslog daemon (or NO).
 syslogd_program=/usr/sbin/syslogd # path to syslogd, if you want a different one.
 syslogd_flags=-s		# Flags to syslogd (if enabled).
+altlog_proglist=		# List of chrooted applicatioins in /var
 inetd_enable=NO		# Run the network daemon dispatcher (YES/NO).
 inetd_program=/usr/sbin/inetd	# path to inetd, if you want a different one.
 inetd_flags=-wW -C 60		# Optional flags to inetd
@@ -267,23 +268,6 @@ hastd_program=/sbin/hastd	# path to hastd, if yo
 hastd_flags=			# Optional flags to hastd.
 ctld_enable=NO		# CAM Target Layer / iSCSI target daemon.
 local_unbound_enable=NO	# local caching resolver
-#
-# named.  It may be possible to run named in a sandbox, man security for
-# details.
-#
-named_enable=NO		# Run named, the DNS server (or NO).
-named_program=/usr/sbin/named # Path to named, if you want a different one.
-named_conf=/etc/namedb/named.conf 	# Path to the configuration file
-#named_flags=			# Use this for flags OTHER than -u and -c
-named_uid=bind 		# User to run named as
-named_chrootdir=/var/named	# Chroot directory (or  not to auto-chroot it)
-named_chroot_autoupdate=YES	# Automatically install/update chrooted
-# components of named. See /etc/rc.d/named.
-named_symlink_enable=YES	# Symlink the chrooted pid file
-named_wait=NO 		# Wait for working name service before exiting
-named_wait_host=localhost 	# Hostname to check if named_wait is enabled
-named_auto_forward=NO 	# Set up forwarders from /etc/resolv.conf
-named_auto_forward_only=NO 	# Do forward only instead of forward first
 
 #
 # kerberos. Do not run the admin daemons on slave servers
Index: etc/freebsd-update.conf
===
--- etc/freebsd-update.conf	(revision 257584)
+++ etc/freebsd-update.conf	(working copy)
@@ -35,7 +35,7 @@ UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.pr
 
 # When upgrading to a new FreeBSD release, files which match MergeChanges
 # will have any local changes merged into the version from the new release.
-MergeChanges /etc/ /var/named/etc/ /boot/device.hints
+MergeChanges /etc/ /boot/device.hints
 
 ### Default configuration options:
 
Index: etc/namedb/Makefile
===
--- etc/namedb/Makefile	(revision 257584)
+++ etc/namedb/Makefile	(working copy)
@@ -1,11 +0,0 @@
-# $FreeBSD$
-
-SUBDIR=	master
-
-FILES=	named.conf named.root
-
-NO_OBJ=
-FILESDIR=	/etc/namedb
-FILESMODE=	644
-
-.include bsd.prog.mk
Index: etc/namedb/master/Makefile
===
--- etc/namedb/master/Makefile	(revision 257584)
+++ etc/namedb/master/Makefile	(working copy)
@@ -1,9 +0,0 @@
-# $FreeBSD$
-
-FILES=	empty.db localhost-forward.db localhost-reverse.db
-
-NO_OBJ=
-FILESDIR=	/etc/namedb/master
-FILESMODE=	644
-
-.include bsd.prog.mk
Index: etc/namedb/master/empty.db
===
--- etc/namedb/master/empty.db	(revision 257584)
+++ etc/namedb/master/empty.db	(working copy)
@@ -1,11 +0,0 @@
-
-; $FreeBSD$
-
-$TTL 3h
-@ SOA @ nobody.localhost. 42 1d 12h 1w 3h
-	; Serial, Refresh, Retry, Expire, Neg. cache TTL
-
-@	NS	@
-
-; Silence a BIND warning
-@	A	127.0.0.1
Index: etc/namedb/master/localhost-forward.db
===
--- etc/namedb/master/localhost-forward.db	(revision 257584)
+++ etc/namedb/master/localhost-forward.db	(working copy)
@@ -1,11 +0,0 @@
-
-; $FreeBSD$
-
-$TTL 3h
-localhost. SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
-	; Serial, Refresh, Retry, Expire, Neg. cache TTL
-
-	NS	localhost.
-
-	A	127.0.0.1
-		::1
Index: etc

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[Stefan Bethke]

Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org:

 On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named script
 Ö still exists.
 Ö and this script depends on /etc/mtree/BIND.chroot.dist file but there is
 Ö no such file in source tree.
 Ö I think this file was forgotten to be removed.
 Ö 
 Ö And also, named_* definitions still exists in /etc/defaults/rc.conf file.
 
 Please review attached file that removes named from /etc.

It would be great if the port would learn to install its own script etc. in 
time for that change. (Unless it’s already there, and I’m just too blind to see 
it.)


Stean

-- 
Stefan Bethke s...@lassitu.de   Fon +49 151 14070811




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

[George Kontostanos]

On Mon, Nov 4, 2013 at 12:54 AM, Stefan Bethke s...@lassitu.de wrote:


 Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org:

  On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
  Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named
 script
  Ö still exists.
  Ö and this script depends on /etc/mtree/BIND.chroot.dist file but
 there is
  Ö no such file in source tree.
  Ö I think this file was forgotten to be removed.
  Ö
  Ö And also, named_* definitions still exists in /etc/defaults/rc.conf
 file.
 
  Please review attached file that removes named from /etc.

 It would be great if the port would learn to install its own script etc.
 in time for that change. (Unless it’s already there, and I’m just too blind
 to see it.)


 Stean

 --
 Stefan Bethke s...@lassitu.de   Fon +49 151 14070811




 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


No you are not blind. Installing bind from ports still relies on the
/etc/rc.d/named script.

Best

-- 
George Kontostanos
---
http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh

[Warner Losh]

In message [EMAIL PROTECTED] Maxim Sobolev writes:
: I like this idea, but perhaps it would be nice to have more
: fine-grained control over when /dev/random is blocking and when
: not. Why not to add sysctl to switch between blocking/non-blocking
: behaviour (defaulting to non-blocking), so our startup scripts would
: be able to switch /dev/random to be secure at the point when it's
: safe to do (all f/s mounted) much like it copes with
: kern.securelevel.  Additionaly it would solve the problem that you
: are not able to use almost anything in single-user mode (less, vi,
: ee etc) w/o feeding /dev/random by hand first.

That's why I had the first write clause in my statement.  The act of
seeing it, which writes to /dev/random, would be enough.  No need to
make it more complex than it has to be.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh

[Maxim Sobolev]

Warner Losh wrote:

 In message [EMAIL PROTECTED] Maxim Sobolev writes:
 : I like this idea, but perhaps it would be nice to have more
 : fine-grained control over when /dev/random is blocking and when
 : not. Why not to add sysctl to switch between blocking/non-blocking
 : behaviour (defaulting to non-blocking), so our startup scripts would
 : be able to switch /dev/random to be secure at the point when it's
 : safe to do (all f/s mounted) much like it copes with
 : kern.securelevel.  Additionaly it would solve the problem that you
 : are not able to use almost anything in single-user mode (less, vi,
 : ee etc) w/o feeding /dev/random by hand first.

 That's why I had the first write clause in my statement.  The act of
 seeing it, which writes to /dev/random, would be enough.  No need to
 make it more complex than it has to be.

Seeding it with *something* (ls, vmstat, date etc) is not equial to seeding it
properly, i.e using data with high enough amount of entropy in it. Therefore,
such sysctl may be potentially used to determine that random generator is in
insecure state and should not be used for anything that require high level of
randomness (key generation for example - ssh may check such sysctl and refuse
to generate a key or at least warn a user about possible problems).

Just my UAH0.02 ;).

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Mikel]

Point taken, however; does it not allowe the services to be configured by such things 
as ip, and time period
and offer yet better activity logging? With the approriate firewall setup the added 
layers are worth the
trouble.


Well enough b/w wasted on this for now.

m


Neil Blakey-Milner wrote:

 On Wed 2000-11-08 (09:30), Mikel wrote:
  I've had been considering running xinted for some time now, and thanks to
  Forest's suggestions I've been able to successfully get it up and running
  smoothly. I am personnaly left wondering why not just replact inetd altogether
  with this version? It certainly enhances security a bit.

 How does it enhance security?

 My main concern:

 (nbm@scythe) /usr/src/usr.sbin/inetd find . -type f -name "*.c" | xargs wc -l | 
grep total
 2933 total

 vs:

 (nbm@scythe) /home/nbm/security/xinetd-2.1.8.9pre10 find . -type f -name "*.c" | 
xargs wc -l | grep total
23149 total

 Neil
 --
 Neil Blakey-Milner
 [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Mikel]

I've had been considering running xinted for some time now, and thanks to
Forest's suggestions I've been able to successfully get it up and running
smoothly. I am personnaly left wondering why not just replact inetd altogether
with this version? It certainly enhances security a bit.

Well these are just thoughts from the peanut gallery.

Cheers,
Mikel

Forrest Aldrich wrote:

 At 09:30 AM 11/7/2000 +, Konstantin Chuguev wrote:

 If xinetd has a startup script, why don't you just set inetd_enable="NO"
 and let
 the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no
 /etc/rc.*
 files (except for rc.conf.local, obviously).
 [ .. ]

 Sure that would work, but for the type of service it is, this seems rather
 ambiguous.  I would rather see this service handled in the rc.* scripts,
 where other similar services are handled.

 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Sheldon Hearn]

On Wed, 08 Nov 2000 09:30:02 EST, Mikel wrote:

 I am personnaly left wondering why not just replact inetd altogether
 with this version? It certainly enhances security a bit.
 
 Well these are just thoughts from the peanut gallery.

Too many of those and a mailing list becomes unreadable. :-)

However, as a show of good faith, I'll say that your question has been
asked _many_ times before and it should not be hard for you to find the
answer in the archives.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Neil Blakey-Milner]

On Wed 2000-11-08 (09:30), Mikel wrote:
 I've had been considering running xinted for some time now, and thanks to
 Forest's suggestions I've been able to successfully get it up and running
 smoothly. I am personnaly left wondering why not just replact inetd altogether
 with this version? It certainly enhances security a bit.

How does it enhance security?

My main concern:

(nbm@scythe) /usr/src/usr.sbin/inetd find . -type f -name "*.c" | xargs wc -l | grep 
total
2933 total

vs:

(nbm@scythe) /home/nbm/security/xinetd-2.1.8.9pre10 find . -type f -name "*.c" | 
xargs wc -l | grep total
   23149 total

Neil
-- 
Neil Blakey-Milner
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Giorgos Keramidas]

On Mon, Nov 06, 2000 at 06:18:38PM -0500, Chris Faulhaber wrote:
 
 You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
 The affected ports would need their ${PREFIX}/etc/rc.d files removed
 (otherwise you would start them twice) along with a message letting the
 installer know how to start it properly.

As a first attempt to do this the proper way, I'm thinking of adding
an option like USE_SYSTEM_ETC in the xinetd port, that will inhibit
installing of the rc.d script, and print a note at the end that tells
the installer to change inetd_program in /etc/rc.conf.

Any objections to this?

- giorgos


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Konstantin Chuguev]

Chris Faulhaber wrote:

 On Tue, Nov 07, 2000 at 01:02:03AM +0200, Giorgos Keramidas wrote:
  On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
   It would be useful to have back the program specification variable for
   inetd.  Currently we have:
  
   inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
   inetd_flags="-wW"   # Optional flags to inetd
  
   and the /etc/rc.* files assume the use of the stock inetd.  Where some
   people choose to use alternative inetd-like programs such as xinetd.
  [...]
 
  Nice idea!  And the fix is simple.  The included patch will correct it :-)
 

 You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
 The affected ports would need their ${PREFIX}/etc/rc.d files removed
 (otherwise you would start them twice) along with a message letting the
 installer know how to start it properly.


If xinetd has a startup script, why don't you just set inetd_enable="NO" and let
the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no /etc/rc.*
files (except for rc.conf.local, obviously).

--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Giorgos Keramidas]

On Tue, Nov 07, 2000 at 09:30:48AM +, Konstantin Chuguev wrote:
 
 If xinetd has a startup script, why don't you just set inetd_enable="NO" and let
 the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no /etc/rc.*
 files (except for rc.conf.local, obviously).

The original idea was to allow other programs to be used instead of the
default inetd, by tweaking /etc/rc.conf appropriately.  For instance,
one could say:

inetd_enable="YES"
inetd_program="/usr/local/sbin/xinetd"
inetd_flags="-reuse"

and change his internet-superserver program to something else.

I am not sure if this is something that a lot of people would consider
a desired feature, but I was trying to see if it can be done (see the
request that started this thread).

- giorgos


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Forrest Aldrich]

At 09:30 AM 11/7/2000 +, Konstantin Chuguev wrote:

If xinetd has a startup script, why don't you just set inetd_enable="NO" 
and let
the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no 
/etc/rc.*
files (except for rc.conf.local, obviously).
[ .. ]

Sure that would work, but for the type of service it is, this seems rather 
ambiguous.  I would rather see this service handled in the rc.* scripts, 
where other similar services are handled.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Chris Faulhaber]

On Tue, Nov 07, 2000 at 01:02:03AM +0200, Giorgos Keramidas wrote:
 On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
  It would be useful to have back the program specification variable for 
  inetd.  Currently we have:
  
  inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
  inetd_flags="-wW"   # Optional flags to inetd
  
  and the /etc/rc.* files assume the use of the stock inetd.  Where some 
  people choose to use alternative inetd-like programs such as xinetd.
 [...]
 
 Nice idea!  And the fix is simple.  The included patch will correct it :-)
 

You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
The affected ports would need their ${PREFIX}/etc/rc.d files removed
(otherwise you would start them twice) along with a message letting the
installer know how to start it properly.

 [ do we really need to cross-post this? ]
 

No, -stable removed.

-- 
Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED]

FreeBSD: The Power To Serve   -   http://www.FreeBSD.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Giorgos Keramidas]

On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
 It would be useful to have back the program specification variable for 
 inetd.  Currently we have:
 
 inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
 inetd_flags="-wW"   # Optional flags to inetd
 
 and the /etc/rc.* files assume the use of the stock inetd.  Where some 
 people choose to use alternative inetd-like programs such as xinetd.
[...]

Nice idea!  And the fix is simple.  The included patch will correct it :-)

[ do we really need to cross-post this? ]

- giorgos


diff -r -u etc.orig/defaults/rc.conf etc/defaults/rc.conf
--- etc.orig/defaults/rc.conf   Tue Nov  7 00:59:39 2000
+++ etc/defaults/rc.confTue Nov  7 00:58:40 2000
@@ -89,6 +89,7 @@
 syslogd_enable="YES"   # Run syslog daemon (or NO).
 syslogd_flags="-s" # Flags to syslogd (if enabled).
 inetd_enable="YES" # Run the network daemon dispatcher (or NO).
+inetd_program="inetd"  # path to inetd, if you don't want stock inetd
 inetd_flags="-wW"  # Optional flags to inetd
 #
 # named.  It may be possible to run named in a sandbox, man security for
diff -r -u etc.orig/rc etc/rc
--- etc.orig/rc Tue Nov  7 00:59:29 2000
+++ etc/rc  Tue Nov  7 00:55:27 2000
@@ -395,7 +395,10 @@
 [Nn][Oo])
;;
 *)
-   echo -n ' inetd';   inetd ${inetd_flags}
+   if [ -x ${inetd_program:-/usr/sbin/inetd} ]; then
+   echo -n ' inetd';
+   ${inetd_program:-/usr/sbin/inetd} ${inetd_flags}
+   fi
;;
 esac
 

/etc/defaults/rc.conf

[Forrest Aldrich]

It would be useful to have back the program specification variable for 
inetd.  Currently we have:

inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
inetd_flags="-wW"   # Optional flags to inetd

and the /etc/rc.* files assume the use of the stock inetd.  Where some 
people choose to use alternative inetd-like programs such as xinetd.  We'd 
do better to have in /etc/defaults/rc.conf:

inetd_enable="YES"  # Run the network daemon dispatcher (or NO).
inetd_program=-"/usr/local/sbin/xinetd"   # Location of inetd/service daemon
inetd_flags="-wW"   # Optional flags to inetd

.. or something similar, rather than manually editing the core rc.* scripts.


_F



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: conf/17595: Preventing cp /etc/defaults/rc.conf /etc/rc.conf from looping

[Doug Barton]

I took another look at this problem, and before I go forward with more
testing I wanted to solicit some comments. The problem is that users who
don't read blindly copy /etc/defaults/rc.conf into /etc. Because of the
recursive call at the end of /etc/defaults/rc.conf when you copy the
file into /etc it gets sourced once by /etc/defaults/rc.conf, then keeps
sourcing itself in /etc/rc.conf forever (actually, till the system runs
out of fd's). 

One solution that was experimented with a while back, and referenced
again in PR 17595 was to put a checkpoint variable in
/etc/defaults/rc.conf which would prevent it from being recursively
sourced. There are two problems with this strategy. The first is that
users who define both an /etc/rc.conf and an /etc/rc.conf.local will not
have the second file sourced on rc's first run through the rc.conf's.
More serious is the fact that there are other scripts in /etc/rc* (like
rc.firewall, rc.network, etc.) that source the rc.conf's themselves.
Using this checkpoint variable method those scripts first source
/etc/defaults/rc.conf, then don't go on to source the files in /etc.
This prevents them from reading in user defined overrides to the
defaults. This is disastrous in cases like rc.firewall, where for
example the firewall type would never get defined as "open", so the
machine is cut off from the network on reboot if ipfw is compiled into
the kernel.

The method I've finally arrived at is to replace the simple recursive
source at the end of /etc/defaults/rc.conf with a combination of the
checkpoint variable and the definition of a function which handles the
recursive sort. This function uses a local variable to keep track of
which files it has sourced already. This eliminates the possibility of
infinite recursive source's, while also allowing other files to source
the rc.conf's both within rc, and independently. The only thing that has
to change is that the files which need to source the rc.conf's will need
to add a call to this new function. Here is the function:

if [ -z "${sourcercs_defined}" ]; then
sourcercs_defined=yes
sourcercs ( ) {
local sourced_files
for i in ${rc_conf_files}; do
case "${sourced_files}" in
*:$i:*)
;;
*)
sourced_files="${sourced_files}:$i:"
if [ -f $i ]; then
. $i
fi
;;
esac
done

}
fi

In (for example) rc, this:

if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi

would change to this:

if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
sourcercs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi


I realize that this solution may seem overly complex, but it allows the
greatest amount of flexibility while at the same time unloading a gun
that lots of users have shot themselves in the foot with. It works with
the little test suite of conf files and scripts that I created to
simulate the rc* files. I plan to do more thorough testing tomorrow with
actually patching my rc* files and rebooting. 

Comments welcome,

Doug
-- 
"So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
The master simply replied, "Mu."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: conf/17595: Preventing cp /etc/defaults/rc.conf /etc/rc.conf from looping

[Adrian Chadd]

On Mon, Mar 27, 2000, Doug Barton wrote:

   One solution that was experimented with a while back, and referenced
 again in PR 17595 was to put a checkpoint variable in
 /etc/defaults/rc.conf which would prevent it from being recursively
 sourced. There are two problems with this strategy. The first is that
 users who define both an /etc/rc.conf and an /etc/rc.conf.local will not
 have the second file sourced on rc's first run through the rc.conf's.
 More serious is the fact that there are other scripts in /etc/rc* (like
 rc.firewall, rc.network, etc.) that source the rc.conf's themselves.
 Using this checkpoint variable method those scripts first source
 /etc/defaults/rc.conf, then don't go on to source the files in /etc.
 This prevents them from reading in user defined overrides to the
 defaults. This is disastrous in cases like rc.firewall, where for
 example the firewall type would never get defined as "open", so the
 machine is cut off from the network on reboot if ipfw is compiled into
 the kernel.

Ok, I tried something a little different.

I wrote a script called 'getconfig', whose sole existence is
to read /etc/defaults/rc.conf, /etc/rc.conf, and then any other
scripts that are in rc_conf_files (well, it didn't have to
read /etc/rc.conf, but I forced it anyway ..)

Then each startup script which loaded /etc/defaults/rc.conf and
tried to load /etc/rc.conf was modified to load /etc/getconfig
instead.

Since no code exists in the conf files, if the user copies them
around willy nilly, they don't cause a loop. It also means
that you could possibly put sanity checking code in getconfig
to make sure the user hasn't done anything blatantly stupid
(I can't think of anything, but then, I don't cp /etc/defaults/rc.conf
/etc/rc.conf that frequently either .. )

So, the question is: What have I missed this time ?



Adrian



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: syslogd_flags in /etc/defaults/rc.conf

[Will Andrews]

On Mon, Mar 20, 2000 at 09:45:49AM -0800, Nick Johnson wrote:
 I'm curious to see if anyone is like-minded with me that syslogd_flags in
 /etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
 should be, considering:
 
   1. Most people don't direct syslogs at other machines in my experience.
   2. Someone could conceivably DOS a machine by directing tons of crap at 
  port 121, which is also noted in the BUGS section of the syslogd
  manpage.
   3. Syslogd runs as root, and while it is a mature piece of code, I think
  it preferable to minimize the number of root applications listening
  on sockets.

This seems like a reasonable change. Thanks for pointing this out! :)

-- 
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ 
G+ e- h! r--+++ y?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

syslogd_flags in /etc/defaults/rc.conf

[Nick Johnson]

I'm curious to see if anyone is like-minded with me that syslogd_flags in
/etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
should be, considering:

  1. Most people don't direct syslogs at other machines in my experience.
  2. Someone could conceivably DOS a machine by directing tons of crap at 
 port 121, which is also noted in the BUGS section of the syslogd
 manpage.
  3. Syslogd runs as root, and while it is a mature piece of code, I think
 it preferable to minimize the number of root applications listening
 on sockets.

   Nick

--
"Why do so many people concern themselves so much with the private
 affairs of complete strangers?"
 - Me
My PGP public key:http://www.spatula.net/pubkey.txt
Nick Johnson, version 1.5   http://www.spatula.net/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: syslogd_flags in /etc/defaults/rc.conf

[Joseph Scott]

Nick Johnson wrote:
 
 I'm curious to see if anyone is like-minded with me that syslogd_flags in
 /etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
 should be, considering:
 
   1. Most people don't direct syslogs at other machines in my experience.

While I am one of those people that does redirect syslogs to other
machines, I agree with your change.

   2. Someone could conceivably DOS a machine by directing tons of crap at
  port 121, which is also noted in the BUGS section of the syslogd
  manpage.
   3. Syslogd runs as root, and while it is a mature piece of code, I think
  it preferable to minimize the number of root applications listening
  on sockets.
 
Nick

-- 

Joseph Scott
[EMAIL PROTECTED]
Office Of Water Programs - CSU Sacramento


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: /etc/defaults/rc.conf

[Eivind Eklund]

On Wed, Feb 17, 1999 at 06:15:06PM +1030, Greg Lehey wrote:
 On Tuesday, 16 February 1999 at  9:24:31 -0800, Jordan K. Hubbard wrote:
  If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted.
 
  Wrong.  You need to read just a bit FURTHER into that file before
  jumping to such conclusions. :-)
 
 Been there, done that.  Next thing is to write a book about it.  Can I
 hope that it won't change again this year?

You can _hope_.

Eivind, who has a number of things he would like to see be different
in the rc system (including rc.conf) - see
http://www.freebsd.org/~eivind/newrc.html for a set of requirements
and a couple of thoughts.  Missed requirements are welcome.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

/etc/defaults/rc.conf

[Luoqi Chen]

Initially I though /etc/defaults/rc.conf stored the default settings and then
we could override some of the settings in /etc/rc.conf, but after a close
look at how they are used in /etc/rc*, I am confused:

if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
elif [ -f /etc/rc.conf ]; then
. /etc/rc.conf
fi

If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted.
So what is the purpose of /etc/defaults/rc.conf?

-lq

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: /etc/defaults/rc.conf

[sthaug]

 Initially I though /etc/defaults/rc.conf stored the default settings and then
 we could override some of the settings in /etc/rc.conf, but after a close
 look at how they are used in /etc/rc*, I am confused:
 
   if [ -f /etc/defaults/rc.conf ]; then
   . /etc/defaults/rc.conf
   elif [ -f /etc/rc.conf ]; then
   . /etc/rc.conf
   fi

Check out the tail end of /etc/defaults/rc.conf - you'll find it sources
/etc/rc.conf (or /etc/rc.conf.local).

Steinar Haug, Nethelp consulting, sth...@nethelp.no

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: /etc/defaults/rc.conf

[Richard Seaman, Jr.]

On Tue, Feb 16, 1999 at 09:04:11AM -0500, Luoqi Chen wrote:
 Initially I though /etc/defaults/rc.conf stored the default settings and then
 we could override some of the settings in /etc/rc.conf, but after a close
 look at how they are used in /etc/rc*, I am confused:
 
   if [ -f /etc/defaults/rc.conf ]; then
   . /etc/defaults/rc.conf
   elif [ -f /etc/rc.conf ]; then
   . /etc/rc.conf
   fi
 
 If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted.
 So what is the purpose of /etc/defaults/rc.conf?

Doesn't /etc/defaults/rc.conf pull in /etc/rc.conf ?  It appears to here.

-- 
Richard Seaman, Jr.   email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax:   414-367-5852

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: /etc/defaults/rc.conf

[Jordan K. Hubbard]

 If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted.

Wrong.  You need to read just a bit FURTHER into that file before
jumping to such conclusions. :-)

- Jordan

To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: /etc/defaults/rc.conf

[Greg Lehey]

On Tuesday, 16 February 1999 at  9:24:31 -0800, Jordan K. Hubbard wrote:
 If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted.

 Wrong.  You need to read just a bit FURTHER into that file before
 jumping to such conclusions. :-)

Been there, done that.  Next thing is to write a book about it.  Can I
hope that it won't change again this year?

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message