Date:Mon, 16 Jul 2018 21:14:39 +0200
From:Steffen Nurpmeso
Message-ID: <20180716191439.sk1eg%stef...@sdaoden.eu>
| stated that reverse solidus at line endings is not necessary to
| continue open and-or lists after && ||, after keywords etc.
They're not needed,
Roy Marples wrote in <932e6a45-c917-666c-bd70-b52fb0d92...@marples.name>:
|On 15/07/2018 11:18, Roy Marples wrote:
|> On 15/07/2018 03:37, Robert Elz wrote:
..
|>> Lastly, for this, I wonder[...]
...
|> The actual change required is a bit more invasive than that line change
|> though, but
On 16/07/2018 14:00, John D. Baker wrote:
"env force_hostname=YES" has it's own pitfall of flip-flopping in the same
way, but that's your adminsitrative decision based on your network setup.
Can "env var=value" be part of the block guarded by an "interface ifN"
statement? On a multi-homed
On Mon, 16 Jul 2018, John D. Baker wrote:
> Can "env var=value" be part of the block guarded by an "interface ifN"
> statement? On a multi-homed machine, there should be only one host name
> and one can choose the interface from which it receives (and acts on) the
> information.
>
> If not,
On Mon, 16 Jul 2018, Roy Marples wrote:
> > Well, what do you know! The YeeLoong successfully used 'dhcpcd' upon
> > netbooting. And with "env force_hostname=YES", it gets an FQDN instead
> > of its short name (only).
> >
> > And a SPARCstation 5 netbooting -8 has just done the same. Looks
On Mon, Jul 16, 2018 at 08:49:31AM +0100, Roy Marples wrote:
> After thinking about it some more, I think the best solution for the FQDN is
> to either fix the DHCP server to send the domain in the hostname field OR
> stop the kernel assigning a hostname OR leave things as they are.
This is
On 16/07/2018 04:17, John D. Baker wrote:
On Sun, 15 Jul 2018, John D. Baker wrote:
On Mon, 16 Jul 2018, Roy Marples wrote:
Sadly, all my machines are x86 based. I have an ERLITE mips router where I
also run dhcpcd, and it doesn't stamp on routes there either, so I'm pretty
sure this isn't
On Mon, 16 Jul 2018, Roy Marples wrote:
> Sadly, all my machines are x86 based. I have an ERLITE mips router where I
> also run dhcpcd, and it doesn't stamp on routes there either, so I'm pretty
> sure this isn't an arch issue ... but I could be wrong.
The only route that was an issue was the
On 15/07/2018 23:54, John D. Baker wrote:
On Sun, 15 Jul 2018, Roy Marples wrote:
But have we considered an alternative? The in kernel DHCP client as
I see it is just to handle network booting yes? Once userland is
netmounted, dhcpcd can then take over? If so, does the kernel DHCP
This seems
On Sun, 15 Jul 2018, Roy Marples wrote:
> But have we considered an alternative? The in kernel DHCP client as
> I see it is just to handle network booting yes? Once userland is
> netmounted, dhcpcd can then take over? If so, does the kernel DHCP
This seems to be a condition unique to x86
On 15/07/2018 12:16, Robert Elz wrote:
| The only other concern I have with this is that if we have two
| interfaces and dhcpcd receives the same short hostname on both but only
| a domain on one of them, then the hostname will flip-flop between short
| and long hostnames.
I'm not
On Sun 15 Jul 2018 at 18:16:15 +0700, Robert Elz wrote:
> The test "language" was very badly defined (ie: not at all really.)
>
> To avoid problems with that, there are very specific rules about
> where to look for operators depending upon just how many args
> exist - with those rules, it is
Date:Sun, 15 Jul 2018 11:18:22 +0100
From:Roy Marples
Message-ID:
| If we're going to test that, then we need to check the converse for
| ${hsort} && [ "$hostname" = "${hostname%%.*}" ]
First irrelevant comment, the %%.* instead of #*. is an irrelevant
On 15/07/2018 11:18, Roy Marples wrote:
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that
need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or
On 15/07/2018 03:37, Robert Elz wrote:
As with most client/server systems, there are two separate things that need
to be made to work - the server has to send the data that you want it to
send (which might mean altering what the client requests, or server config,
or ...) and then the client
On Sun, 15 Jul 2018, Robert Elz wrote:
> Date:Sat, 14 Jul 2018 11:14:19 -0500 (CDT)
> From:"John D. Baker"
>
> | I also needed to set "use-host-decl-names true;" in "dhcpcd.conf".
>
> In dhcpd.conf I assume.
Yes. I added that to "/etc/dhcpd.conf", i.e., the DHCP
Date:Sat, 14 Jul 2018 11:14:19 -0500 (CDT)
From:"John D. Baker"
Message-ID:
| On Sat, 14 Jul 2018, Robert Elz wrote:
|
| > env force_hostname=YES
|
| Yes, that's the ticket.
Good.
| I also needed to set "use-host-decl-names true;" in "dhcpcd.conf".
On Sat, 14 Jul 2018, Robert Elz wrote:
> env force_hostname=YES
Yes, that's the ticket.
I also needed to set "use-host-decl-names true;" in "dhcpcd.conf". Some
netbooted hosts would get their hostname without this, but most would
not, ending up with "localhost". The same hosts always
Date:Sat, 14 Jul 2018 13:12:29 +0200
From:Martin Husemann
Message-ID: <20180714111229.gf3...@mail.duskware.de>
| In userland, dhcpcd hooks should set the full name by default, if I read
| /libexec/dhcpcd-hooks/30-hostname correctly, not sure what goes wrong here
On Sat, 14 Jul 2018, Martin Husemann wrote:
> On Sat, Jul 14, 2018 at 06:40:49AM -0400, Greg Troxel wrote:
> > My guess, without reading specs, is that the right thing to do is to
> > change the in-kernel dhcp client to construct fqdn and use it.
>
> The in-kernel dhcp client is minimalistic and
On Sat, Jul 14, 2018 at 06:40:49AM -0400, Greg Troxel wrote:
> My guess, without reading specs, is that the right thing to do is to
> change the in-kernel dhcp client to construct fqdn and use it.
The in-kernel dhcp client is minimalistic and only extracts enough
data to mount /, and it should
"John D. Baker" writes:
> So far, I can only get an FQDN for netbooted machines if I make the
> "host" entries:
>
> host foo.example.com {
> ...
> }
>
> group bar {
> option host-name "bar.example.com";
> ...
> }
>
> which is a lot of duplication for all the potential
I have historically used dhcpd.conf "host" entries like:
option domain-name "example.com";
option domain-name-servers M.N.O.P, W.X.Y.Z;
host foo {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address A.B.C.D;
option next-server P.Q.R.S;
option root-path "/path/to/foo";
}
23 matches
Mail list logo
