►
From YouTube: Windows HostProcess Containers For Configuration And Beyond - James Sturtevant & Mark Rossetti
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Windows HostProcess Containers For Configuration And Beyond - James Sturtevant & Mark Rossetti, Microsoft
The days of needing custom scripts and hard-won knowledge to set up and configure Windows Server hosts are over. The new Windows HostProcess Container feature in Kubernetes has begun to close a major feature gap between Windows and Linux containers. We now have a way to carry out key tasks such as running kube-proxy and CNIs (Container Network Interface) as containers in the cluster. Beyond the basics, HostProcess containers also open the door to more effective logging, monitoring and debugging of the Windows environment. In this session, we will cover the basics of using HostProcess containers and see how they differ from other Windows containers. After gaining an understanding of these differences, we will explore three examples covering the common use cases for HostProcess containers: CNIs, debugging, and on-demand monitoring. The attendees will see concrete examples of HostProcess Containers, novel approaches to debugging, and gain inspiration for new ways of interacting with Windows enabled clusters.
A
A
Folks,
but
you
know
how
painful
that
is,
and
so
for
everybody
else,
SSH
sshing
into
the
node
usually
requires
doing
a
proxy
jump
or
already
like
setting
up
a
VM
inside
the
network.
So
you
can
RDP.
Then
you
need
to
know
that
the
password
to
that
VM
and
it's
difficult
challenging,
and
so
what
I'm
going
to
show
you
here
today
is
we're.
A
First
thing:
we're
going
to
do
is:
take
a
quick
look
at
the
the
nodes,
so
you're
going
to
see
a
Linux
node
and
a
Windows
node,
and
then
we're
going
to
install
the
plugin.
So
we're
going
to
use
crew
to
do
that.
Crew,
install
Windows,
debug
crew.
If
you
have
not
familiar
with
crew,
it
installs
a
plug-in.
So
you
can
start
to
use
that
tool
directly
with
cubectl
next
I'm
going
to
run
Cube
CTL,
Windows
debug,
and
it's
so
fast
that
I
can
barely
say
it.
A
A
But
now
I
can
edit
the
config
files
kind
of
poke
around
do
some
searching
with
inside
the
error
logs
or
anything
else
there,
and
so
this
is
all
hosted
inside
this
HPC
folder
here
and
inside
there
you're
going
to
see
we
have
Vim,
but
we
also
have
some
networking
scripts
that
we
ship
out
of
the
box
so
that
you
can
collect
traces
and
packets
and
all
sorts
of
other
things
there
and
the
best
part
about
that
is.
It
all
goes
away
when
the
when
the
container
gets
killed.
A
So
that's
a
quick
demo.
Hopefully
that
gets
you
excited
I'm
James,
Sturdivant
I'm,
a
software
engineer
at
Microsoft
I've
been
working
with
Windows
containers
for
four
or
five
years
now:
I'm
a
tech
lead
for
Sig
windows
and
maintainer
at
cluster
API
for
azure.
Mostly
doing
windows
work
there
and
I
know
how
to
make
fire
six
different
ways
using
only
sticks
and
stones
and
that's
related
to
my
Twitter
handle
Aspen
Wilder.
So
you
can
ask
me
about
that
later.
Mark.
D
Yeah
hi
I'm,
Mark,
Rossetti
I
am
also
a
software
engineer
at
Microsoft.
I
am
the
co-chair
of
Sig
windows
and
I
kind
of
pop
in
all
around
different
parts
of
core
kubernetes.
To
make
sure
things.
Work
with
Windows
I
am
not
generally
on
Twitter,
okay.
So
here's
a
little
bit
about
what
we're
going
to
talk
about
today.
First,
we're
going
to
do
an
overview
of
what
host
process
containers
are.
That
was
the
new
kind
of
feature
that
powered
everything
in
that
demo.
D
Then
we're
going
to
go
deep
into
one
or
two
deployments
to
show
you
guys
kind
of
how
it
works
and
then
we're
going
to
probably
fill
out
most
of
the
rest
of
the
time
with
some
demos
and
then
have
some
additional
resources
and
some
questions
and
answers.
So,
first
off
what
are
host
process
containers
host
process
containers
are
conceptually
equivalent
to
privileged
containers
on
Linux
for
anybody
who's
familiar
with
that
really
just
as
a
way
where
you
can
package
distribute
and
deploy
your
workloads
as
containers
to
Windows
nodes.
D
These
containers
run
as
a
process
directly
on
the
host.
Hence
the
name
host
process
containers
which
gives
you
you
know
almost
full
access
to
the
host's
file
system.
You
know
Network
stack,
process,
space
event,
viewers,
all
of
that
I
say
almost
because
we'll
demo,
some
security
considerations
for
all
of
these
in
the
future.
The
other
great
thing
about
this
is
we
really
designed
this
feature
to
be.
You
know
kubernetes,
first,
so
the
deployed
as
containers,
but
they
run
just
as
a
normal
pod.
D
So
you
get
the
benefits
of
all
the
different
constructs
that
you're
used
to
like
volume
mounts.
You
know,
resource
limits,
everything
that's
managed
there
are
listed
there.
So
what
are
some
of
the
motivations
for
this
really
I?
Think
as
James
hit
earlier
managing
and
provisioning
waiter
knows
was
extremely
difficult.
D
Also,
there
really
wasn't
a
good
standardized
way
to
deploy
many
of
the
essential
components
that
needed
to
run
on
the
Node,
your
cni
Solutions
Cube
proxy.
Before
all
of
that,
really
it
was
just
up
to
the
whoever
was
setting
up
the
node
to
set
that
up.
It
often
involves
a
lot
of
custom
Powershell
to
parse
environment
relied
on
third-party.
You
know
service
managers
often
and
SSM-
was
the
big
one.
There
really
was
a
poor
upgrade
story.
You
needed
to
orchestrate
logging
into
the
node
and.
E
D
Your
own
updates
each
time
and
it
also
yeah
just
another
downside-
was
requiring
access
to
the
node
and
then
your
workloads
once
they
were
running
with
this,
they
were
very
difficult
to
monitor.
You
really
didn't
have
any
visibility
into
if
they
were
running
or
not
the
error.
State
again,
you
required
access
to
the
nodes
to
even
get
that
information,
and
you
had
no
easy
way
to
get
your
logs
now
with
host
process
containers
you
can
deploy
all
of
these
workloads,
just
as
demon
sets.
So
it's
a
you
know,
familiar
upgrade
story.
D
Familiar
deployment
story
runs
as
a
container
which
everybody
here
is
here
is
used
to.
You
have
rolling
updates.
All
of
that
and
actually
no
access
to
the
node
is
required
as
already
demoed
and
then
once
your
workloads
are
deployed,
you
monitor
them.
Just
like
anything
else.
You
could
do
just
check
to
see
if
your
pods
are
running
they'll
get
restarted.
If
they're,
not
you
can
use
logs
to
monitor
them.
All
of
that.
D
Here's
a
little
bit
of
information
about
the
history
of
this
feature.
This
feature
went
beta
in
kubernetes
123,
that's
when
it's
generally
on
by
default,
so
it
called
that
out
here
and
it
is
going
stable
in
this
next
release
of
kubernetes.
One
thing
to
note,
though,
is
this:
functionality
is
only
supported
if
you're
running
container
d,
as
your
container
runtime
I
believe
most
Windows
users
have
migrated
to
that
now
so
big
issue.
A
So
now
that
you
know
kind
of
what
host
process
containers
are,
we
wanted
to
show
you
how
you'd
actually
use
them,
and
so
we're
going
to
take
a
look
at
a
big
spec
here
and
don't
worry
I'm
going
to
zoom
in
here,
and
the
first
thing
we're
going
to
take
a
look
at
is
the
Pod
spec
and
using
the
security
context.
So
this
is
the
standard,
Windows
security
context
that
we're
hooking
into
here.
A
We
also
specify
host
Network
equals
true,
we
need
to
work
for
the
cni.
Specifically,
we
need
to
work
within
the
host
Network
compartment
to
be
able
to
program
all
the
the
rules
for
the
networking
in
there,
and
so
we
have
access
to
that
there
as
well
and
Mark's
working
on
a
cap
to
enable
that
for
regular
containers
as
well.
So
if
you're
interested
in
that,
you
can
talk
to
him
afterwards.
A
The
next
part
I
want
to
dive.
In
on
is
the
init
containers,
so
Mark
said
we,
we
built
this
with
kubernetes
the
kubernetes
ideas
in
in
mind,
and
so
we
can
use
init
containers
with
these
host
process
containers,
and
this
enables
us
to
be
able
to
install
things
like
cni
binaries.
This
is
a
very
familiar
pattern
from
the
Linux
side,
and
so
I
no
longer
need
to
go
download
these
things
and
prep
them
on
my
windows.
Node
initially
I
can
apply
them
at
the
the
time
I'm
applying
my
cni.
A
A
Next
up
we
have
multiple
containers
here.
Calico
needs
a
little
bit
of
prep
before
Felix
runs
to
be
able
to
talk
to
the
kubernetes
API,
and
so
we're
able
to
run
more
than
one
container
inside
this
pod
with
that
host
process,
and
then
they
communicate
to
each
other
via
the
file
system.
In
this
case,
but
there's
other
ways
they
could
do
that
and
the
most
exciting
part
here
is
that
they
have
full
access
to
the
API
server
using
the
security.
A
So
the
next
part
that
I
wanted
to
call
out
here
is
Q
proxy,
so
we're
also
enabled
this
for
Q
proxy
and
we're
using
it
basically
in
the
same
way,
you'll
see
the
host
process
security
context
at
the
top
there,
but
we
also
are
using
the
downward
API
to
pass
in
information,
because
this
is
built
into
kubernetes.
We
no
longer
have
to
use
our
Powershell
scripts
and
do
some
kind
of
fancy
thing
to
go
figure
out
exactly
what
the
Pod
IP
address.
A
And
on
top
of
that,
we
can
use
taints
and
tolerations
with
these.
So
we
can
say
we
only.
This
is
a
critical
component,
because
it's
the
cube
proxy.
We
need
this
running
at
all
times
and
then
upgrading
becomes
super
simple,
we're
using
kubernetes
upgrade
strategies
here,
instead
of
having
to
build
our
own
through
some
sort
of
Powershell
scripts
or
something
along
those
lines,
and
so
for
those
that
may
have
noticed
at
the
top.
D
Yeah
so
you'll
notice
in
the
previous
demos,
we
were
running
as
a
local
system
account,
that's
generally
not
desirable
and
a
lot
in
a
lot
of
cases.
So
we
do
have
some
mechanisms
so
that
people
can
configure
what
access
these
containers
have
on
each
one
of
the
nodes.
There's
a
demo
here
that
I'll
kind
of
narrate
as
it's
going
through.
So
this
deployment
has
a
Powershell
script.
D
Yes,
yes,
essentially,
so
he
asked
if
that
would
be
equivalent
of
a
like
a
running
run
as
as
a
service
account.
And
yes,
yes,
it
is
so
here
you'll,
see
here,
there's
a
Powershell
script
that
gets
plopped
in
as
a
config
map
that
runs
on
the
nodes.
The
first
thing
we
do
is
we
use
a
net
local
user
to
create
a
local
user
account,
and
then
we
create
some
folders
and
get
different
access
to
those
here.
You'll
see.
Well,
we
just
missed,
there's
an
init
container
that
all
it
does.
D
D
D
And
we
have
access
to
that
chair,
so
I'll
talk
about.
What's
going
on
here,
usually
so
now
I
mean
we
realize
that
this
is
a
pretty
powerful
feature
and
we
want
to
limit
access
to
the
node,
but
we're
trying
to
figure
out
a
way
to
do
that
that
didn't
require.
Having
people
manage.
You
know:
user
accounts
on
the
nodes,
either
using
weak,
passwords
or
potentially
no
passwords
or
other
things.
D
So
what
happens
here
is
if
you
pass
in
the
local
group
name
as
that
run
as
user
name,
when
these
containers
are
started,
we'll
actually
create
a
new
user,
a
local
user.
Add
it
to
that
group,
so
We'll
Inherit,
all
the
security
permissions
from
that
group,
and
then
your
container
will
run
as
that
user
and
then
that
user
will
get
cleaned
up
at
the
end.
D
This
is
beneficial
because
yeah
it
makes
it
a
lot
easier
to
manage
these
user
accounts.
You
don't
need
these
passwords
and
there's
a
lot
of
benefits
to
this
another
nice
thing
with
this.
Is
it
really
completely
falls
into
the
Windows
security
model?
So
you
assign
access
or
deny
access
to
all
of
the
different
Windows
resources?
D
D
One
other
thing
that
I
wanted
to
call
out
here
is:
you
may
have
noticed
that
these
containers
start
pretty
fast
for
Windows
containers,
as
we
were
developing
this
feature
we
noticed
like,
since
it
is
a
process
just
running
directly
on
the
host.
You
really
don't
need
all
of
the
stuff
that
comes
in
with
these
windows
container
based
images,
so
we
tried
to
make
it
so
that
you
didn't
need
this,
and
so
we
created
a
new
base
image
here.
D
D
That's
used
to
build
the
image
and
instructions
on
how
to
how
to
use
this
too,
and
if
anybody
is
not
familiar
with
using
buildkit
to
build
images,
it's
pretty
easy.
So
here's
a
quick,
Demo
First
we'll
have
a
Hello
World
file
that
just
says
hello,
world
and
a
Docker
file
and
then
so
with
buildx.
You
need
to
make
a
buildx
builder
and
specify
the
target
operating
system
or
the
platform
to
use.
But
then
you
can
just
use
Docker
build
X,
build
commands
to
build
that.
D
A
All
right
so
now
that
we
have
an
understanding
of
what
host
process
containers
are
and
how
to
configure
them
and
operate
with
them.
We
wanted
to
show
off
a
few
tools
that
the
community
has
already
built
with
host
process
containers.
The
first
one
we're
going
to
show
is
a
tool
that
I
developed,
that
I
solved
the
problem
that
I
needed
inside
Sig
windows
and
so
I
I'm,
one
of
the
ones
that
maintain
all
the
Sig
Windows
tests,
and
we
have
occasional
flakes
that
happen.
A
Every
40th
or
50th
run,
and
we
needed
Windows
traces,
ETL
traces
to
be
able
to
collect
and
debug
these
things,
because
we
identified
that
the
bug
was
in
the
OS
running
a
trace.
These
end-to-end
tests
take
about
an
hour
to
or
so
to,
run
and
running
a
trace
for
that
long
would
result
in
a
many
gigabyte
size
file,
a
massive
and
so
I
needed
a
way
to
be
able
to
trigger
when
that,
when
a
specific
test
was
running
and
then
kick
off
the
traces
and
then
get
them
uploaded
somewhere.
A
So
what
I'm
going
to
show
you
here
is
the
tool
that
I
built
to
do
this.
I've
called
the
trigger
logger,
which
not
very
creative
here,
and
so
first
thing
we'll
do
is
we're
gonna
install
the
trigger
Locker?
So
it's
just
a
yaml
file.
It
is
a
host
process
container,
that's
running
in
the
background,
and
it
it
has
a
config
map
and
that
config
map
allows
you
to
to
configure
this.
This
tool
and
the
thing
that
we're
going
to
look
at
is
it
has
a
trigger
that
runs
on
namespace
creation.
A
I
know
what
that
namespace
is
that's
going
to
be
created
in
the
test
and
so
every
time
that
test
kicks
off
I'm,
going
to
run
that
next
up
once
that
trigger
triggers
I'm
going
to
run
wpr
or
Windows
performance
recorder.
The
windows
performance
recorder
is
a
thing
that
creates
that
ETL
file
and
then
finally,
at
the
end,
once
once
I
destroy
the
namespace
I'm
going
to
upload
that
to
Azure
storage
or
any
kind
of
blob
storage.
A
That's
available
to
me
so
I've
got
this
tool
running
you'll,
see
that
it
is
using
the
in
cluster
config
that
I
mentioned
before.
So
it's
communicating
to
the
API
server
and
it's
using
the
the
service
account
that
I've
wired
that
has
access
to
list
namespaces,
it's
listening
to
all
the
namespaces
inside
the
cluster
and
then
the
next
step
for
me
is
going
to
we're
going
to
listen
to
the
logs
of
the
trigger
logger
and
create
that
namespace.
A
A
C
A
A
A
I
can
query
the
hns
logs,
which
is
where
the
networking
configuration
that's
set
up,
and
so
here
I've
run
that
networking
configuration
and
I
can
see
all
the
networks
that
are
created
on
the
law
on
a
node
I
can
see
all
the
load
balancers
that
have
been
created
and
I
can
see
all
the
mappings
between
those.
So
if
something
got
misconfigured
somewhere,
it's
very
easy
to
inspect
that,
and
this
is
super
powerful
in
a
large
cluster.
A
A
If
you
know
what
you're
looking
here,
this
is
just
telling
you
the
packets,
going
through
the
the
various
components
of
the
networking
stack.
This
can
be
converted
to
a
Wireshark,
and
so
you
can
load
this
into
Wireshark
and
then
analyze
it
from
there
and
we're
using
packetmon
behind
the
scenes,
which
is
another
tool
that
ships
with
Windows
server
and
the
latest
releases,
and
so
I
can
filter
down
to
individual
packets.
A
I
can
fill
it
down
into
individual
components
within
the
networking
stack
and
and
just
see
those
components,
and
the
last
thing
I'm
going
to
show
here
is
sometimes
you
don't
know
what's
going
on,
and
you
know
that
maybe
the
packets
are
dropping
but
you're
not
sure
how
bad
it
is,
and
so
I
can
just
quickly
query
against
the
a
node,
and
it
will
give
me
the
counters
that
are
being
seen
on
that
node
and
so
then
from
there
I
can
narrow
it
down
to
something
else.
That's
happening.
A
Yeah,
so
the
networking
team
actually
used
this
to
identify
some
various
bugs
within
some
some
customers
that
we
had
experienced,
and
this
enabled
them
to
identify
an
individual
pod
running
in
a
100,
node
cluster
and
say
this
is
the
component
that
is
is
causing
problems
so
super
powerful
tools.
These
are
all
open
source
and
the
next
part
we're
going
to
step
into
is
just
some
additional
resources.
A
So
since
we
have
released
host
process,
containers
for
for
kubernetes
and
123.
we've
had
a
huge
adoption
of
this
across
the
ecosystem,
as
you
can
see
from
all
these
projects
so
that
when
Windows
container
inspect
is
in
there
cube
proxies
in
their
Calico
and
I.
Think
one
of
the
other
really
good
ones,
is
Windows
exporter
for
Prometheus.
So
there's
a
ton
out
there,
there's
even
more
that
we
didn't
get
to
list
here
and
the
thing
I
want
to
call
out
if
you
are
new
to
the
kubernetes
ecosystem
and
you
want
to
contribute.
A
This
is
a
great
way
to
contribute
to
Windows.
There's
a
lot
of
examples
out
there
that
you
can
leverage
and
there's
a
lot
of
projects
that
either
don't
know.
This
is
available
or
don't
have
the
windows
expertise
to
be
able
to
do
this,
and
so
you
can
go
out
there
and
make
a
pretty
significant
contribution
that
enables
the
ecosystem.
D
Oh
yeah,
so
this
this
feature
and
all
of
the
like
the
things
that
we've
demoed
here
were
really
developed
in
conjunction
with
Sig
windows.
So
we
wanted
to
take
a
minute
to
highlight
some
other
upcoming
talks
related
to
Sig
Windows.
There's
a
Windows
operational
Readiness
talk
tomorrow.
There's
a
Sig,
Windows
maintainer
track
talk
tomorrow
and
then
there's
a
interesting
Lessons,
Learned
From
scheduling,
20
million
Windows
containers
in
a
month
talk
on
Friday.
D
So
if
you're
interested
please
come
support
us
and
before
we
get
to
the
Q,
a
I
just
wanted
to
put
up
some
resource
slides
here.
Don't
worry
about
taking
this
down
just
download
the
slides
off
sketch,
but
there's
a
lot
more
information
about
the
cap.
The
discussions
that
went
into
eventually
bring
this
feature
to
froshin
documentation
on
how
to
use
it.
Lots
of
examples.
D
All
of
that.
If
anybody
is
interested
in
participating
or
getting
more
information
here,
we
encourage
you
to
just
go
through
the
normal
Sig
Windows
communication
channels,
the
biggest
one
being
the
Sig
Windows
slack
Channel.
But
there's
also.
We
have
a
community
guide
on
how
to
reach
us
and
we
have
a
community
meeting
every
Tuesday
at
12,
30
PST,
so
hope
to
see
more
people
there.
Next,
we'll
open
it
up
to
q
a
and
at
the
same
time,
I'll
just
leave
this
up.
If
anybody
wants
to
leave
some
feedback.
F
F
One
of
the
differences
between
a
privileged
container
in
Linux
and
host
process
container
is
that
the
container
is
running
as
a
process
in
the
host
right.
So
I
also
know
that
there
is
no
file
system
isolation
so
for
cluster
administrators
that
want
to
enable
this
feature.
What
security
recommendations
do
you
have
so
that
workloads
cannot
access,
can
have
the
same
access
on
the
file
system.
B
D
Particularly
around
the
file
system,
so
since
so
so
much
of
this
is
controlled
just
through
the
normal
kubernetes
constructs.
Really,
the
the
built-in
security
admission
policies
will
help
cover
you
a
lot.
I
know
if
you're
in
the
restricted
policy,
you
won't
be
able
to
schedule
those
process,
containers
and
all
of
that,
so
we
really
recommend
all
the
best
practices
about
really
not
allowing
host
of
postpath
volume
amounts
and
that
sort
of
the
thing
and
I
think
that
should
help
get
you
kind
of
started.
A
C
D
So
I
thought
I
heard
his.
Is
there
a
future
for
more
isolated
access
to
the
host?
Currently,
no
we're
hoping
that
we
just
haven't
had
it
planned.
But
if
there's
some
interesting
use
cases
we'd
like
to
hear
it
most
of
the
use
cases
that
we've
highlighted
required
either
pretty
broad
access
to
the
host
or
were
allowing
us
to
yeah.
E
D
G
D
So
there
is
some
virtualization
happening
there.
Yes,
so
your
your
container
image
will
get
mounted
to
a
well-known
location,
see
colon
HPC
and
then
it
will
be
there.
Okay,
all
of
the
C
drive
will
get
mapped
in
to
that
as
well,
and
then
your
volume
mounts
will
show
up
just
like
they
do
in
normal's
window
server
containers.
So
if
you
mount
in,
like
VAR
log
it'll
show
up
in
C
column,
fire
log
right.
G
But
if,
if
in
your
example,
where
you're
using
the
init
container
to
install
something,
if
I
delete
that
pod,
it's
still
installed
right,
you
installed
it
physically
on
the
Node
and
all
I
did
was
delete.
Whatever
the
deployment
of
the
the
container
image
was
from
the
disk
and
close
the
pro
stop
the
process.
I
guess.
A
So,
just
specifically
like
in
the
cni
case
there
we
copied
the
cni
binaries
into
the
cni
location
yeah,
but,
like
the
Vim
like
we
had
Vim
that
doesn't
live
on
the
host
that
was
in
the
container
and
when
the
container
went
away,
it
was
it's
going
to
be
removed
as
well.
Okay,
so
it
depends
on
where
you
put
the
binaries
on
the
the
system
right.
C
F
D
So
there's
there's
a
cap
and
actually
the
PRS
to
do
this-
have
a
lot
of
discussion
around
that
too.
So
I'll
probably
defer
to
that.
But
the
short
answer
is
no.
We
actually
so
if,
if
for
whatever
reason
that
SQL
and
HPC
folder
exists
on
the
Node,
we
clear
it
so
that
you
won't
get
that
the
contention
the
same
contention
that
you
can
get
with
shadowing,
but
other
than
that.
It's
there's
not
really
much
concern
there.
E
Hi
fabulous
talk,
question
for
you,
I
know
that
there
are
a
lot
of
really
exciting
caps
in
Flight
around
windows
stuff
as
well.
If
somebody
wants
to
jump
in
and
start
participating
in,
some
of
the
actual,
like
the
cups
and
other
things
like
this,
that
you're
in
the
process
of
working
on
yeah.
This
one
is
going
GA,
that's
great,
but
what
other
ones
are
kind
of
a
an
exciting
place?
People
might
get
involved.
D
Oh,
that's
what
our
maintainer
talk
is
covering
tomorrow
too,
so,
if
you're
interested
in
that
tube
item,
as
James
mentioned,
host
networks
like
access
to
the
host
Network
compartment
for
regular
Windows
Server
containers
is
one
and
really
following
a
whole
bunch
of
the
node.
The
Sig
node
kepts,
to
bring
parity
to
Windows.
Is
that
too
yep.