Hmmm...  I only have a couple of free minutes here, but I
skimmed through this.

I think that named_rcng is simply mis-named.  It's used twice
in /etc/rc.d/named.  The second looks bogus; I'm pretty sure
it (and the entire case statement around it) can safely
be deleted.

Regardless of how named_rcng is set, /etc/rc.d/named will
still start named.  (This is why I say it's mis-named;
Christian seems to have misunderstood it to determine whether
or not /etc/rc.d/named would start named.)  The difference
is simply which set of variables get used:

named_rcng = NO
      named_flags  is obeyed
      named_chrootdir, named_chroot_autoupdate, and named_symlink_enable
are not obeyed.

named_rcng = YES
      named_flags is not obeyed; it gets overwritten with auto-generated
flags
      named_chrootdir, named_chroot_autoupdate, and named_symlink_enable
are obeyed.

Forcing it YES certainly has the potential of breaking some
existing installations because it ignores named_flags.
If we're going to do it, do it before 5.2.  However, I would
suggest changing the code so that named_flags gets obeyed if
it is set.  In that case, we could dump named_rcng, set
named_flags="" in /etc/defaults/rc.conf and just possibly
manage to avoid breaking anything.

Like I said, this is all based on a pretty cursory study;
I might be mis-reading something.

In any case, the comments in /etc/defaults/rc.conf should be
augmented to make it clear which variables are obeyed for
each setting of named_rcng.

Tim

Gordon Tetlow wrote:
> Forwarded to the rc mailing list. Tim, do you want to weigh in on this?
>
> IIRC, it has something to do with the way NetBSD does named startup
> (which is in a chroot?) while we do it the old fashioned simpler way.
>
> -gordon
>
> ----- Forwarded message from Christian Weisgerber <naddy@...> -----
>
> Date: Sun, 7 Sep 2003 13:28:42 +0200
> From: Christian Weisgerber <naddy@...>
> To: gordon@...
> Subject: -CURRENT rc_ng: named_rcng
> X-Spam-Status: No, hits=-7.5 required=6.5
>  tests=BAYES_10,USER_AGENT_MUTT
>  autolearn=ham version=2.55
>
> Shouldn't named_rcng default to "YES" now or in fact be completely
> removed, considering that no alternative startup exists any longer?
>

Forwarded to the rc mailing list. Tim, do you want to weigh in on this?

IIRC, it has something to do with the way NetBSD does named startup
(which is in a chroot?) while we do it the old fashioned simpler way.

-gordon

----- Forwarded message from Christian Weisgerber <naddy@...> -----

Date: Sun, 7 Sep 2003 13:28:42 +0200
From: Christian Weisgerber <naddy@...>
To: gordon@...
Subject: -CURRENT rc_ng: named_rcng
X-Spam-Status: No, hits=-7.5 required=6.5
	 tests=BAYES_10,USER_AGENT_MUTT
	 autolearn=ham version=2.55

Shouldn't named_rcng default to "YES" now or in fact be completely
removed, considering that no alternative startup exists any longer?

--
Christian "naddy" Weisgerber                          naddy@...

----- End forwarded message -----

On Sun, 7 Sep 2003, Tim Kientzle wrote:

> Lukas Ertl wrote:
> >  It seems to
> > run fine, the problem is that it doesn't generate the same output as an
> > unmodified version, ...
>
> This is supposed to not be a problem.
> Generally, there will be more than one order
> that meets the specified requirements.  As long
> as the order you're building does follow the
> specified requirements, it should not matter whether
> or not it's exactly the same.

Ok, if I just look at the "PROVIDE"/"REQUIRE" lines it seems to meet the
requirements.  But, for example, one thing might be a problem: the
original has vinum before gbde, and my modification puts gbde before
vinum.

Both provide "disks", but I guess gbde should depend on vinum already
running.

regards,
le

--
Lukas Ertl                             eMail: l.ertl@...
UNIX Systemadministrator               Tel.:  (+43 1) 4277-14073
Vienna University Computer Center      Fax.:  (+43 1) 4277-9140
University of Vienna                   http://mailbox.univie.ac.at/~le/

On Sun, 7 Sep 2003, Tim Kientzle wrote:

> Lukas Ertl wrote:
> >  It seems to
> > run fine, the problem is that it doesn't generate the same output as an
> > unmodified version, ...
>
> This is supposed to not be a problem.
> Generally, there will be more than one order
> that meets the specified requirements.  As long
> as the order you're building does follow the
> specified requirements, it should not matter whether
> or not it's exactly the same.
>
> This is actually a good test to see whether
> all of the requirements are being correctly
> specified.

I did a little bit of analysis of the output from Lukas' version of
rcorder, and it seemed there were some disturbing differences, but
unfortunately I didn't have enough time to really research it, or test
boot it.

I agree that in an ideal world, it wouldn't matter, I'm just concerned
that we have a hidden dependency in "rc.d/*" returning stuff in alpha
order.

I would like to see us add this feature to rcorder, but I think we need
some volunteers to test boot it on a variety of different systems before
we turn it loose on the world. :)  I'm also interested Luke's opinions
on the topic as well.

Doug

--

     This .signature sanitized for your protection

Lukas Ertl wrote:
>  It seems to
> run fine, the problem is that it doesn't generate the same output as an
> unmodified version, ...

This is supposed to not be a problem.
Generally, there will be more than one order
that meets the specified requirements.  As long
as the order you're building does follow the
specified requirements, it should not matter whether
or not it's exactly the same.

This is actually a good test to see whether
all of the requirements are being correctly
specified.

Tim Kientzle

Hi,

I hacked rcorder to accept a directory as a parameter instead of passing
in all rc scripts on the command line with a glob.  You can find this
patch at <http://mailbox.univie.ac.at/~le/rcorder.c.diff>.  It seems to
run fine, the problem is that it doesn't generate the same output as an
unmodified version, and I don't see why since I didn't touch the functions
which do the actual ordering.

The difference between original and modified output can be found at
<http://mailbox.univie.ac.at/~le/output.diff>.  The reason for this seems
to be related to the fact that a glob orders the filenames alphabetically,
while readdir() has no particular ordering - it more or less returns the
directory entries as they were created.

I found that on my system the output is different since I run -current and
did some mergemaster's after upgrading my kernel/world.  If I delete
/etc/rc.d completely and re-create it with mergemaster -i, the original
and the modified versions of rcorder produce matching output.

I didn't dig into the rcorder code to understand this enough, but could it
be that rcorder depends on a certain pre-ordering of input?

Any thoughts and ideas are appreciated,

regards,
le

--
Lukas Ertl                             eMail: l.ertl@...
UNIX Systemadministrator               Tel.:  (+43 1) 4277-14073
Vienna University Computer Center      Fax.:  (+43 1) 4277-9140
University of Vienna                   http://mailbox.univie.ac.at/~le/

Folks,

In case you missed this, please check my thinking here, and let me know
your opinion. I've added the option to savecore to report if there is a
dump, so the rest of the rc work is a SMOP.

Doug


---------- Forwarded message ----------
From: Doug Barton <DougB@...>
To: Poul-Henning Kamp <phk@...>
Cc: freebsd-current@...
Date: Mon, 1 Sep 2003 23:51:17 -0700 (PDT)
Organization: http://www.FreeBSD.org/
Subject: Re: swapon vs savecore dilemma

On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:

> Hmm, that was an unfortunate side effect.

Heh, well, stuff happens. I think your idea of opening swap exclusive is
probably a good one, but it will require some gymnastics to accomodate
it. One thing that'd really help is an option to savecore that tells us
if there is a dump to deal with or not. If I had that, we could do
something like this in /etc/rc.d/savecore

if there is no dump
	 exit
else
	 does fsck -p of the fs to write the dump to succeed?
		 mount it rw
		 write the dump
		 clear the dump
		 exit
	 else
		 does try fsck -y of the fs without swap succeed?
			 mount, write, clear, exit
		 else
			 ???

At the ??? point I'm not sure how best to proceed, since if we swapon to
the same partition with the dump, it's likely to corrupt the dump, yes?
On the other hand, we're doing swapon before savecore now, so I guess
I'm curious about how dangerous this really is.

Probably the right thing to do is to swapon, fsck -y, and if it succeeds
then swapoff, and try writing the dump anyway. I just want to be
sure before we start re-writing rc.d/savecore.

So, the first question is does the pseudocode above look reasonable, and
the second question is what's the likelihood of getting an option to
savecore to detect a dump to play with?

Doug

--

     This .signature sanitized for your protection

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

You are right, that is what I was trying to do.. And, believe it or not, I did
actually get
it to work (even when it had to renew it's lease/etc)...  I was just being lazy
and didn't
want to make a run to the computer store for a second nic...  In the end, it
would
have been a lot easier to just go get another NIC, I was more just enjoying the
challenge of it all I suppose...

I did finally go get one, of course - which would absolutely be my
recommendation as
well..

Thanks!

- Greg

--- In FreeBSD-rc@yahoogroups.com, Gordon Tetlow <gordont@g...> wrote:
> On Sun, Aug 31, 2003 at 02:48:54PM -0700, Doug Barton wrote:
> > I have to confess, I don't really understand what you're trying to
> > accomplish here. I think your best bet is freebsd-questions@f...
>
> I think he is trying a single-armed network, where he's trying to put
> both his internal network and the outgoing connection on the same
> network interface. FWIW, it's a really bad idea, and considering how
> cheap network adapters are these days, I don't see how anyone can
> justify working with such a beast.
>
> -gordon

On Sun, Aug 31, 2003 at 02:48:54PM -0700, Doug Barton wrote:
> I have to confess, I don't really understand what you're trying to
> accomplish here. I think your best bet is freebsd-questions@....

I think he is trying a single-armed network, where he's trying to put
both his internal network and the outgoing connection on the same
network interface. FWIW, it's a really bad idea, and considering how
cheap network adapters are these days, I don't see how anyone can
justify working with such a beast.

-gordon

Hi,

> I think the work you're doing is great, just wondering if you asked to
> have this reviewed by anyone on the rc team before committing?

I've talked about this with Warner, and before that, with Mike.

Does something not work ?

Martin

I have to confess, I don't really understand what you're trying to
accomplish here. I think your best bet is freebsd-questions@....

Hope this helps,

Doug

--

     This .signature sanitized for your protection

Martin,

I think the work you're doing is great, just wondering if you asked to
have this reviewed by anyone on the rc team before committing?

Thanks,

Doug


On Mon, 11 Aug 2003, Martin Blapp wrote:

> mbr         2003/08/11 13:32:00 PDT
>
>   FreeBSD src repository
>
>   Modified files:
>     etc                  network.subr pccard_ether
>   Log:
>   Improve the handling dhcp handling of pccard_ether.
>
>   There are now many configurations which have a NIC on board, and
>   pccard slots. If a dhclient is running on the internal nic, the
>   Improve the handling dhcp handling of pccard_ether.
>
>   Improve the dhcp handling of pccard_ether.
>
>   There are now many configurations which have a NIC on board and
>   Improve the dhcp handling of pccard_ether.
>
>   There are now many configurations which have a NIC on board and
>   cardbus slots too. If a dhclient was already running on the internal
>   NIC, the user was forced to kill a running dhclient manually.
>
>   If now a pccard is included at startup time, /etc/rc.d/dhclient
>   start does include it into the startup list for dhcp devices.
>   That means you can now do dhcp on the internal and the pccard devices
>   at the same time. If the card is plugged in later, a running dhclient
>   (working for the internal interface only) is killed, and restarted,
>   but the interface name of the new pccard is added to the internal
>   name. After removal, /etc/rc.d/dhclient is started again. This
>   script does nothing if there are no devices in /etc/rc.conf
>
>   This is only a workaround for a well known problem. After we have
>   a dhcp client which handles device adding and removal, it will go
>   away.
>
>   Revision  Changes    Path
>   1.153     +18 -0     src/etc/network.subr
>   1.33      +30 -1     src/etc/pccard_ether
>
>
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/network.subr.diff?&r1=1.152&r2=1.1\
53&f=h
>
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/pccard_ether.diff?&r1=1.32&r2=1.33\
&f=h
>
>

--

     This .signature sanitized for your protection

Hello,

I'm having a bit of trouble with something - I'm not sure if it's possible.  If
so,
can anyone provide some pointers?

Basically I am trying to configure a single ethernet interface to have both a
static ip and a dynamically assinged ip...

The situation is that I have a small network that uses a FreeBSD system as an
internet gateway.   Prior to today all this took place through a dialup 56k
modem (which was fine because I only use one computer at a time, but it was
very convenient).   Today I just got cable service and would like to keep the
same basic network configuration, with the FreeBSD server doing IPnat
between the local 192.168.1.* network and the rest of the world.

Any ideas on this would be very appreciated.

Thanks!

- Greg

> No, I mean this: suppose you have IPFIREWALL compiled statically
> into your kernel (defaulting to "deny ip from any to any") and
> have firewall_enable="NO" in /etc/rc.conf).  The logical thing
> in this case would be to set net.inet.ip.fw.enable=0.  This is
> trivial to implement in /etc/rc.network in RELENG_4, but I'm
> looking for a clean way to implement this in HEAD with rc.d/.

Many years ago I lobbied hard for the inclusion of the
IPFIREWALL_DEFAULT_TO_ACCEPT option to alleviate this very problem.
Since 1. It's hard to parse what a user actually intended to do given
the combination of things that you describe, and 2. There are already
existing mechanisms to unload this particular foot-shooting gun, I'm
inclined to let sleeping dogs lie on this one.

HTH,

Doug

--

     This .signature sanitized for your protection

Mike Makonnen wrote:
> I'm forwarding this to freebsd-rc. I can't think of an easy way
> this could be done. Maybe someone there will have an answer.
>
> ----- Forwarded message from Ruslan Ermilov <ru@...> -----
>
> Date: Sun, 24 Aug 2003 22:27:46 +0300
> To: Mike Makonnen <mtm@...>
> From: Ruslan Ermilov <ru@...>
> Subject: Re: Patches for the Makefile in src/etc
> User-Agent: Mutt/1.5.4i
>
> On Sat, Aug 23, 2003 at 04:42:45PM -0400, Mike Makonnen wrote:
>
>>On Sat, Aug 23, 2003 at 10:43:28PM +0300, Ruslan Ermilov wrote:
>>
>>>BTW, while we're in touch, is there an easy way to modify
>>>rc.d/ipfw to set net.inet.ip.fw=0 if firewall_enable="NO"
>>>was specified, and we have told "/etc/rc.d/ipfw stop".
>>
>>With rc.d, a conscious decision was made that it would be completely
>>integrated with rc.conf. For consistency and reliability sake
>>it was decided that all actions in the scipts would be dependant
>>on knobs in rc.d. So, if the user wants to override what rc.conf
>>says, he has to attach a 'force' prefix to the command. In your
>>case it would be
>> # /etc/rc.d/ipfw forcestop
>>
>
> No, I mean this: suppose you have IPFIREWALL compiled statically
> into your kernel (defaulting to "deny ip from any to any") and
> have firewall_enable="NO" in /etc/rc.conf).  The logical thing
> in this case would be to set net.inet.ip.fw.enable=0.  This is
> trivial to implement in /etc/rc.network in RELENG_4, but I'm
> looking for a clean way to implement this in HEAD with rc.d/.

Ruslan,

I had a big fight with Luke Mewburn and others about this
issue.  The short answer is: NO.  If the knob
is turned off, the rc.d script becomes a no-op.

Tim

I'm forwarding this to freebsd-rc. I can't think of an easy way
this could be done. Maybe someone there will have an answer.

----- Forwarded message from Ruslan Ermilov <ru@...> -----

Date: Sun, 24 Aug 2003 22:27:46 +0300
To: Mike Makonnen <mtm@...>
From: Ruslan Ermilov <ru@...>
Subject: Re: Patches for the Makefile in src/etc
User-Agent: Mutt/1.5.4i

On Sat, Aug 23, 2003 at 04:42:45PM -0400, Mike Makonnen wrote:
> On Sat, Aug 23, 2003 at 10:43:28PM +0300, Ruslan Ermilov wrote:
> >
> > BTW, while we're in touch, is there an easy way to modify
> > rc.d/ipfw to set net.inet.ip.fw=0 if firewall_enable="NO"
> > was specified, and we have told "/etc/rc.d/ipfw stop".
>
> With rc.d, a conscious decision was made that it would be completely
> integrated with rc.conf. For consistency and reliability sake
> it was decided that all actions in the scipts would be dependant
> on knobs in rc.d. So, if the user wants to override what rc.conf
> says, he has to attach a 'force' prefix to the command. In your
> case it would be
>  # /etc/rc.d/ipfw forcestop
>
No, I mean this: suppose you have IPFIREWALL compiled statically
into your kernel (defaulting to "deny ip from any to any") and
have firewall_enable="NO" in /etc/rc.conf).  The logical thing
in this case would be to set net.inet.ip.fw.enable=0.  This is
trivial to implement in /etc/rc.network in RELENG_4, but I'm
looking for a clean way to implement this in HEAD with rc.d/.


Cheers,
--
Ruslan Ermilov  Sysadmin and DBA,
ru@...  Sunbay Software Ltd,
ru@...  FreeBSD committer



----- End forwarded message -----

Cheers.
--
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@... | Fingerprint: 00E8 61BC 0D75 7FFB E4D3  6BF1 B239 D010 3215 D418
mtm@...| FreeBSD - Unleash the Daemon !

On Wed, 13 Aug 2003, Brooks Davis wrote:

> If rc.conf.local had other variables in, I'd basically have to generate
> it from scratch every time I ran the script since that's how new
> variables would be added unless I wanted to write code to parse the
> file so I could add variables that are new and subtract ones that are
> obsolete.

Lars already covered this.

> You could argue that once that happens I'd need the database of values
> anyway so my argument is moot, but I've been trying to avoid that.

Glad to help push you in the right direction. :)

Doug

--

     This .signature sanitized for your protection

On Thu, Aug 14, 2003 at 11:33:08AM +1000, Luke Mewburn wrote:
> On Tue, Aug 12, 2003 at 10:50:59AM -0700, Brooks Davis wrote:
>   | On my network booted cluster, I've found it useful to be able to set the
>   | hostname of the machine using a file similar to /etc/nodename in
>   | Solaris.  The following patch extends the definition of the hostname
>   | variable so that if it is an absolute path refering to an existing file,
>   | the contents of the file become the host name.  Technicaly, FreeBSD
>   | seems to accept host names of that form, but since you can't store then
>   | in DNS, I don't think I care about the slight restriction.
>
> NetBSD has supported /etc/myname for a *long* time (over 10 years).
> rc.conf(5)'s $hostname overrides it.
>
> If you're going to reinvent the wheel, you might as well be more
> consistent with the system that you got the rc.d stuff from (NetBSD)
> than a system which isn't reknowned for consistency in its init.d
> design (Solaris).

Adding:

hostname="/etc/myname"

to /etc/defaults/rc.conf after applying my patch would do exactly that
as well as allowing users to be compatable with Solaris or Linux or
whatever.  Maybe I should add that to my patch and promote it as a
NetBSD compatability feature. :-)

-- 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

On Tue, Aug 12, 2003 at 10:50:59AM -0700, Brooks Davis wrote:
   | On my network booted cluster, I've found it useful to be able to set the
   | hostname of the machine using a file similar to /etc/nodename in
   | Solaris.  The following patch extends the definition of the hostname
   | variable so that if it is an absolute path refering to an existing file,
   | the contents of the file become the host name.  Technicaly, FreeBSD
   | seems to accept host names of that form, but since you can't store then
   | in DNS, I don't think I care about the slight restriction.

NetBSD has supported /etc/myname for a *long* time (over 10 years).
rc.conf(5)'s $hostname overrides it.

If you're going to reinvent the wheel, you might as well be more
consistent with the system that you got the rc.d stuff from (NetBSD)
than a system which isn't reknowned for consistency in its init.d
design (Solaris).

Luke.

On Tue, Aug 05, 2003 at 09:17:17AM +0200, yahoo@... wrote:
   | i just managed to get an sh coredump with an rc.d/ script of mine.
   | either there is a bug in rc.subr or i am doing things wrongly. in
   | any way, i need some help.
   |
   | here is part of the output of /etc/rc.d/test stop :
   |
   | /etc/rc.d/test: DEBUG: run_rc_command: evaluating :().
   | Loading configuration files.
   | Node type = 15
   | pid 5183 (sh), uid 0: exited on signal 11 (core dumped)
   | zsh: segmentation fault (core dumped)  /etc/rc.d/test stop
   |
   | the 'Node type' message comes from sh's eval.c function.  my rc.d/test
   | is attached.
   |
   | the shell dies after the last command from test_stop(), but before the
   | next command from run_rc_command(), as far as i can tell.
   |
   |
   | what i want to do is basically the same that is done by
   | rc.shutdown: going through rc.d/ in reverse order and calling every
   | script with a 'stop' argument. my code is almost the same as in
   | rc.shutdown. if i run test_stop manually (i.e. not through
   | run_rc_command "$1" at the bottom of my script), everything seems to
   | work just fine.

rc.subr is not guaranteed to be recursion friendly.

>>On Tue, 12 Aug 2003, Brooks Davis wrote:
>>>On my network booted cluster, I've found it useful to be able to set the
>>>hostname of the machine using a file similar to /etc/nodename in
>>>Solaris.

Sounds like a fine idea to me.

On the other hand, if you get too much resistance,
you could simply take advantage of the fact that
the entire rcNG system is shell scripts.  In particular,
/etc/rc.conf and /etc/rc.conf.local can use arbitrary
shell constructs, e.g.

In /etc/rc.conf:
   . /etc/nodename

In /etc/nodename:
   hostname="xxx"

This provides the separation you're looking for
without any additional hassle.

Tim

Brooks Davis wrote:
> On Wed, Aug 13, 2003 at 12:15:37PM -0700, Doug Barton wrote:
>
>>On Wed, 13 Aug 2003, Brooks Davis wrote:
>>
>>
>>>This significantly increases the complexity of my /conf generation
>>>scripts.  Currently, most hosts have an easily generated host name based
>>>on their IP address, but some do not.  With a single configuration file
>>>I need to regenerate from scratch every time like rc.conf.local, I need
>>>to change my script to look up ip address and find the host name.  If I
>>>could set the host name in a file, I would just not overwrite it if it
>>>existed so I'd only need to specify the hostname the first time.
>>
>>I have to confess, I don't quite understand the paragraph above. If you
>>can generate a file called foo that has the hostname in it, and then not
>>overwrite that file, why can't you also generate a file called
>>rc.conf.local, that has the hostname in it, and then not overwrite THAT
>>file?
>
>
> If rc.conf.local had other variables in, I'd basically have to generate
> it from scratch every time I ran the script since that's how new
> variables would be added unless I wanted to write code to parse the
> file so I could add variables that are new and subtract ones that are
> obsolete.  You could argue that once that happens I'd need the database
> of values anyway so my argument is moot, but I've been trying to avoid
> that.  I was hoping this trivial change would be non-controversial and I
> could avoid building that database a little longer.

Just as an observation, the last entry in rc.conf wins, so you could
just append new entries to it.

(On the overall issue, I have no preference either way.)

Lars
--
Lars Eggert <larse@...>           USC Information Sciences Institute

On Wed, Aug 13, 2003 at 12:15:37PM -0700, Doug Barton wrote:
> On Wed, 13 Aug 2003, Brooks Davis wrote:
>
> > This significantly increases the complexity of my /conf generation
> > scripts.  Currently, most hosts have an easily generated host name based
> > on their IP address, but some do not.  With a single configuration file
> > I need to regenerate from scratch every time like rc.conf.local, I need
> > to change my script to look up ip address and find the host name.  If I
> > could set the host name in a file, I would just not overwrite it if it
> > existed so I'd only need to specify the hostname the first time.
>
> I have to confess, I don't quite understand the paragraph above. If you
> can generate a file called foo that has the hostname in it, and then not
> overwrite that file, why can't you also generate a file called
> rc.conf.local, that has the hostname in it, and then not overwrite THAT
> file?

If rc.conf.local had other variables in, I'd basically have to generate
it from scratch every time I ran the script since that's how new
variables would be added unless I wanted to write code to parse the
file so I could add variables that are new and subtract ones that are
obsolete.  You could argue that once that happens I'd need the database
of values anyway so my argument is moot, but I've been trying to avoid
that.  I was hoping this trivial change would be non-controversial and I
could avoid building that database a little longer.

-- Brooks

On Wed, 13 Aug 2003, Brooks Davis wrote:

> This significantly increases the complexity of my /conf generation
> scripts.  Currently, most hosts have an easily generated host name based
> on their IP address, but some do not.  With a single configuration file
> I need to regenerate from scratch every time like rc.conf.local, I need
> to change my script to look up ip address and find the host name.  If I
> could set the host name in a file, I would just not overwrite it if it
> existed so I'd only need to specify the hostname the first time.

I have to confess, I don't quite understand the paragraph above. If you
can generate a file called foo that has the hostname in it, and then not
overwrite that file, why can't you also generate a file called
rc.conf.local, that has the hostname in it, and then not overwrite THAT
file?

Doug

--

     This .signature sanitized for your protection

On Wed, Aug 13, 2003 at 10:41:20AM -0700, Doug Barton wrote:
> On Wed, 13 Aug 2003, Brooks Davis wrote:
>
> > Hmm, rc.conf.local might be a solution.  The nice thing about this is
> > that I can have a single rc.conf and when I'm generating /conf/<ip>/etc
> > directories I just have to do "echo $hostname > <ip>/etc/nodename".
> > This fits well with my current model where I create new files but don't
> > over write them so I don't risk screwing up my existing settings like
> > ssh keys or non-standard host names when I decided to add a new
> > configuration parameter.
>
> rc.conf.local is designed for precisely this purpose. :) The following:
>
> echo "hostname=\"${foo}.example.com\"" >> rc.conf.local
>
> Is only slightly more complicated than your example above, and takes
> advantage of existing mechanisms. While I'm totally in favor of
> improving our diskless support, I see no reason to add complications to
> the code when a simple solution already exists.

This significantly increases the complexity of my /conf generation
scripts.  Currently, most hosts have an easily generated host name based
on their IP address, but some do not.  With a single configuration file
I need to regenerate from scratch every time like rc.conf.local, I need
to change my script to look up ip address and find the host name.  If I
could set the host name in a file, I would just not overwrite it if it
existed so I'd only need to specify the hostname the first time.

The script I use is below.  As you can see, the hostname code would
become significantly more complicated as it would require access to an
external database.

I disagree with your assessment that this adds an enough of complexity
to the code to constitute a downside worthy of consideration.

-- Brooks

#!/bin/sh
domainname=example.org
ipaddr=$1
if [ -z "$2" ]; then
         hostname=`echo ${ipaddr} | awk 'BEGIN {FS="\."} {printf("r%02dn%02d",
$3, $4) }'`
else
         hostname=$2
fi
hostname="${hostname}.${domainname}"

echo "ip = ${ipaddr}"
echo "hostname = ${hostname}"

mkdir -p ${ipaddr}/etc/ssh
if [ ! -e ${ipaddr}/etc/nodename ]; then
         echo "${hostname}" > ${ipaddr}/etc/nodename
fi
if [ ! -e ${ipaddr}/etc/ssh/ssh_host_key ]; then
         /usr/bin/ssh-keygen -t rsa1 -N "" -f
${ipaddr}/etc/ssh/ssh_host_key
fi
if [ ! -e ${ipaddr}/etc/ssh/ssh_host_dsa_key ]; then
         /usr/bin/ssh-keygen -t dsa -N "" -f
${ipaddr}/etc/ssh/ssh_host_dsa_key
fi
if [ ! -e ${ipaddr}/etc/ssh/ssh_host_rsa_key ]; then
         /usr/bin/ssh-keygen -t rsa -N "" -f
${ipaddr}/etc/ssh/ssh_host_rsa_key
fi

--
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

On Wed, 13 Aug 2003, Brooks Davis wrote:

> Hmm, rc.conf.local might be a solution.  The nice thing about this is
> that I can have a single rc.conf and when I'm generating /conf/<ip>/etc
> directories I just have to do "echo $hostname > <ip>/etc/nodename".
> This fits well with my current model where I create new files but don't
> over write them so I don't risk screwing up my existing settings like
> ssh keys or non-standard host names when I decided to add a new
> configuration parameter.

rc.conf.local is designed for precisely this purpose. :) The following:

echo "hostname=\"${foo}.example.com\"" >> rc.conf.local

Is only slightly more complicated than your example above, and takes
advantage of existing mechanisms. While I'm totally in favor of
improving our diskless support, I see no reason to add complications to
the code when a simple solution already exists.

We have literally tenss of thousands of machines at Yahoo!, and the
combination of rc.conf for standard configuration and rc.conf.local for
machine-specific stuff like hostname, IP, etc. works quite well for us,
I'm sure it will be suitable for you too. :) Can you give that a try,
and let us know how it works out for you?

Doug

--

     This .signature sanitized for your protection

On Tue, Aug 12, 2003 at 06:49:05PM -0700, Doug Barton wrote:
> On Tue, 12 Aug 2003, Brooks Davis wrote:
>
> > On my network booted cluster, I've found it useful to be able to set the
> > hostname of the machine using a file similar to /etc/nodename in
> > Solaris.
>
> Before I got excited about this patch, I'd like to hear more about why
> that mechanism works better for you than editing the variable in
> /etc/rc.conf.local. Note, I'm not saying that we won't adopt your idea,
> I'd just like to be persuaded a little more first.
>
> The main reason I'm hesitant is that while on the one hand having
> multiple ways to do the same task is _sometimes_ beneficial, it can
> often lead to needless user confusion. The rcNG system is already
> confusing enough, so I'm hesitant to add more complexity without a
> really good reason.

Hmm, rc.conf.local might be a solution.  The nice thing about this is
that I can have a single rc.conf and when I'm generating /conf/<ip>/etc
directories I just have to do "echo $hostname > <ip>/etc/nodename".
This fits well with my current model where I create new files but don't
over write them so I don't risk screwing up my existing settings like
ssh keys or non-standard host names when I decided to add a new
configuration parameter.

On a more general level, I believe this change improves the ease of
diskless configuration which IMO is on of FreeBSD's major strengths.
It's not a big improvements, but I think it is one.  Our diskless
support is one of the biggest reasons I was able to convince the people
buying the cluster that we should run FreeBSD instead of Linux.  The
increase in complexity is very small and only effects a case that
was more or less undefined before. (hostname(1) accepts anything,
but somehow I don't think your machine would be very happy named
/etc/nodename. :-)

Finally, any complexity difference between rcNG and the old rc system is
pretty irrelavent to me in this case because I plan to MFC the change if
it's acceptable in 5.x.

-- Brooks

FYI,

I'm forwarding this, slightly edited, with permission. I want to make
y'all aware of this issue, especially since some of you are responsible
for some of the files listed. I also want to make Luke aware, since some
of this is relevant to the stuff we've sucked in from netbsd.

Please don't leap into action just yet though, since the issues of
exactly how to properly assign the copyright are still being discussed.
Consider this a heads up so that you can start thinking about what
you're comfortable with when the time comes to actually start making
changes (if appropriate).

Doug


---------- Forwarded message ----------
From: Wes Peters <wes@...>
Date: Tue, 12 Aug 2003 00:29:16 -0700
Subject: Cleanup of copyright, etc.

Our copyrights have fallen into disarray.  It would be nice if we could
get these cleaned up in time for the 5.2 release, if at all possible.

./alpha/alpha/critical.c
./alpha/include/critical.h
./i386/i386/critical.c
./i386/include/critical.h
./ia64/ia64/critical.c
./ia64/include/critical.h
./kern/kern_idle.c
./kern/subr_blist.c
./powerpc/include/critical.h
./powerpc/powerpc/critical.c
./sparc64/include/critical.h
./sparc64/sparc64/critical.c
./sys/blist.h
./vm/vm_pageq.c
./vm/vm_zeroidle.c
./amd64/amd64/critical.c
./amd64/include/critical.h

Each of the above refers to "the BSD copyright" in /usr/src/COPYRIGHT.
This is possibly not a legally acceptable copyright notice, and at any
rate the contents of /usr/src/COPYRIGHT are terribly out of date.

In addition I have identified at least the following files:

./etc/devfs.conf
./etc/rc
./etc/netstart
./etc/network.subr
./etc/rc.sendmail
./etc/periodic/security/100.chksetuid
./etc/periodic/security/200.chkmounts
./etc/periodic/security/300.chkuid0
./etc/periodic/security/400.passwdless
./etc/periodic/security/500.ipfwdenied
./etc/periodic/security/510.ipfdenied
./etc/periodic/security/550.ipfwlimit
./etc/periodic/security/600.ip6fwdenied
./etc/periodic/security/650.ip6fwlimit
./etc/periodic/security/700.kernelmsg
./etc/periodic/security/800.loginfail
./etc/periodic/security/900.tcpwrap
./etc/periodic/security/security.functions
./etc/rc.d/atm1
./etc/rc.d/atm2.sh
./etc/rc.d/atm3.sh
./etc/rc.d/hostname
./etc/rc.d/netif
./etc/rc.d/nisdomain
./etc/rc.d/pccard
./etc/rc.d/pcvt
./etc/rc.d/syscons
./include/complex.h
./lib/libc/gen/getosreldate.3
./lib/libc/gen/sysctlnametomib.c
./lib/libc/stdlib/grantpt.3
./lib/libc/stdlib/grantpt.c
./lib/libstand/zalloc.c
./lib/libstand/zalloc_defs.h
./lib/libstand/zalloc_malloc.c
./lib/libstand/zalloc_mem.h
./lib/libstand/zalloc_protos.h
./libexec/pt_chown/pt_chown.c
./libexec/save-entropy/save-entropy.sh
./share/doc/papers/bufbio/bio.ms
./share/doc/papers/devfs/paper.me
./share/man/man4/nmdm.4
./share/man/man8/rc.sendmail.8
./share/misc/scsi_modes
./sys/compat/linux/linux_uid16.c
./sys/sys/copyright.h
./sys/sys/copyright.h
./tools/make_libdeps.sh
./usr.bin/doscmd/cpu.c
./usr.bin/doscmd/tty.h
./usr.bin/doscmd/video.c
./usr.sbin/spkrtest/spkrtest.sh

which purport to be copyright by "The FreeBSD Project", which does not
exist in any legal sense.  Note: this list is not exhaustive, just a
simple sweep grepping for 'the freebsd project'; many more may be lurking
in the source tree.

We are going to attempt to make sense of this mess in time for 5.2
release, so if you created any of these files and would like to amend the
copyright before we unleash the hounds of hell, please do so before
1-Sept-2003.  After that we may begin "fixing" copyrights on files that
were obviously created for or donated to the FreeBSD Project, directing
the copyright to the FreeBSD Foundation.

Please take a few minutes to look over this list and any files you have
created on behalf of the project and help us straighten out this mess.
Thank you.

--

         Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes@...

On Tue, 12 Aug 2003, Brooks Davis wrote:

> On my network booted cluster, I've found it useful to be able to set the
> hostname of the machine using a file similar to /etc/nodename in
> Solaris.

Before I got excited about this patch, I'd like to hear more about why
that mechanism works better for you than editing the variable in
/etc/rc.conf.local. Note, I'm not saying that we won't adopt your idea,
I'd just like to be persuaded a little more first.

The main reason I'm hesitant is that while on the one hand having
multiple ways to do the same task is _sometimes_ beneficial, it can
often lead to needless user confusion. The rcNG system is already
confusing enough, so I'm hesitant to add more complexity without a
really good reason.

Hope this helps,

Doug

--

     This .signature sanitized for your protection

On my network booted cluster, I've found it useful to be able to set the
hostname of the machine using a file similar to /etc/nodename in
Solaris.  The following patch extends the definition of the hostname
variable so that if it is an absolute path refering to an existing file,
the contents of the file become the host name.  Technicaly, FreeBSD
seems to accept host names of that form, but since you can't store then
in DNS, I don't think I care about the slight restriction.

Any comments?

-- Brooks

Index: etc/rc.d/hostname
===================================================================
RCS file: /usr/cvs/src/etc/rc.d/hostname,v
retrieving revision 1.3
diff -u -p -r1.3 hostname
--- etc/rc.d/hostname 30 Jul 2003 18:53:59 -0000 1.3
+++ etc/rc.d/hostname 12 Aug 2003 01:14:11 -0000
@@ -42,6 +42,13 @@ hostname_start()
 	 # Set the host name if it is not already set
 	 #
 	 if [ -z "`hostname -s`" ]; then
+  # If ${hostname} is an absolute path, use the contents
+  # of the indicated file as the host name.
+  #
+  if [ `expr "${hostname}" : '\(.\)'` = "/" -a \
+ 	    -r "${hostname}" ]; then
+ 	 hostname=`cat ${hostname}`
+  fi
 		 hostname ${hostname}
 		 echo "Setting hostname: `hostname`."
 	 fi
Index: share/man/man5/rc.conf.5
===================================================================
RCS file: /usr/cvs/src/share/man/man5/rc.conf.5,v
retrieving revision 1.197
diff -u -p -r1.197 rc.conf.5
--- share/man/man5/rc.conf.5 28 Jul 2003 13:56:00 -0000 1.197
+++ share/man/man5/rc.conf.5 12 Aug 2003 17:41:49 -0000
@@ -240,6 +240,8 @@ containing spaces.
  The fully qualified domain name (FQDN) of this host on the network.
  This should almost certainly be set to something meaningful, even if
  there is no network connection.
+If set to an absolute path, the contents of the refrenced file will be
+used to set the hostname.
  If
  .Xr dhclient 8
  is used to set the hostname via DHCP,

--
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