Hi,
not sure, wether it is appropiate to ask here, but in lack of a better
alternative, I'll give it a go.
I am trying to boot an alpine container (openrc), works as root. but
when changing to a user id, the bootup fails with getty error messages:
getty: console: TIOCSCTTY: Operation not pe
Hello,
For a simple setup, I've tried to replace radvd with systemds
IPv6SendRA=true.
Now the link supposed to send the RA of course has both a fixed local as
well as fixed global (ULA) address. As it happens to be the default gw
as well.
Since the local address is being configured manuall
Am 05.09.22 um 18:34 schrieb Ede Wolf:
Hello,
For a simple setup, I've tried to replace radvd with systemds
IPv6SendRA=true.
Now the link supposed to send the RA of course has both a fixed local as
well as fixed global (ULA) address. As it happens to be the default gw
as well.
Sinc
thing fundamentally, this looks more and more like a bug.
Either we need a LinkLocalAddressing=ipv6manual option or it should be
checked, wether a valid scope local address is being provided later on.
But of course, I may be wrong
On Mon, 5 Sept 2022, 19:14 Ede Wolf, <mailto:lis...@nebelschwaden.de
Yes, this. There's no benefit to disabling link-local addressing, and
doing so can definitely break other IPv6 features. I've never seen an
explicitly-configured link-local address before, but I'd be really
surprised if it worked as a replacement for the
automatically-generated link-local address
Hello,
I am having two container connected via private network to a bridge with
a mtu of 8k.
However the .nspawn generated interfaces have the default mtu of 1500.
And while I can manually adjust the mtu to 8k using the ip link command,
I am wondering, wethere there is a way to specify the m
later reference them in the .link
file?
Am 01.07.24 um 16:07 schrieb Ede Wolf:
Hello,
I am having two container connected via private network to a bridge with
a mtu of 8k.
However the .nspawn generated interfaces have the default mtu of 1500.
And while I can manually adjust the mtu to 8k
Hello,
I am having two machines that receive their ipv6 address and their
default route via RA, both on the same physikal link, as is the router.
While one works as expected, the other machine behaves in a way, that it
gets it's default route after restarting networkd, but once that has
expi
oes not.
Am 03.07.24 um 09:46 schrieb Ede Wolf:
Hello,
I am having two machines that receive their ipv6 address and their
default route via RA, both on the same physikal link, as is the router.
While one works as expected, the other machine behaves in a way, that it
gets it's default ro
Hello,
I would like to confirm, wether I am reading the nspawn documentation
correctly or wether I am confusing things.
For ipvlan, it reads:
'Create an "ipvlan" interface of the specified Ethernet network
interface and add it to the container.'
I understand this the way, that the equivale
Hello,
I am trying to enable temporary and/or stable addresses for a link and
am most likely running into troubles with the device naming. However, I
do not change any network name myself, neither in udev nor as part or a
link file, it's just the standard system settings (from Arch, in case
t
v/rules.d? Many distributions install such a rules file by
default, and this renames the interfaces to 'standard' names.
On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote:
Hello,
I am trying to enable temporary and/or stable addresses for a link and
am most likely running into troubles with the
Found the reason for this global issue. The not working machine had not
been moved to SLAAC, as I've though it was, but had still been
configured statically.
Bummer.
As a workaround I have set default values:
net.ipv6.conf.default.stable_secret=
net.ipv6.conf.default.addr_gen_mode=2
net.ipv6
Am 22.05.20 um 17:58 schrieb Andrei Borzenkov:
The problem is, that sysctl.conf is being executed before the interfaces
get their eventual names.
That sounds like actual bug. What systemd version do you use?
At least it is, what the journal suggest, as seen below. However,
generally it sou
That sounds like actual bug. What systemd version do you use?
I've just did a test with Deepin, as I've had VM flying around of that
debian based distribution, and here it seems to work, using systemd 241
instead of 245. systemd-sysctl is clearly called after the renaming:
May 22 21:48:
expected.
Am 22.05.20 um 21:50 schrieb Ede Wolf:
That sounds like actual bug. What systemd version do you use?
I've just did a test with Deepin, as I've had VM flying around of that
debian based distribution, and here it seems to work, using systemd 241
instead of 245. systemd
1:01 test1-PC systemd-networkd[263]: enp0s3: Interface name
change detected, enp0s3 has been renamed to lan-01.
May 22 22:41:01 test1-PC systemd-networkd[263]: lan-01: Gained carrier
Am 22.05.20 um 21:50 schrieb Ede Wolf:
That sounds like actual bug. What systemd version do you use?
Given lack of errors after interface rename, settings were most probably
applied correctly.
No. According to the log, the lack of errors after the rename result
simlpy in there are no more settings left that could be applied. Because
they all have been tried before. And failed. sysctl.conf is
to find out?
At least with systemd-245/arch (not sure who is to blame) I cannot use
the final name, and with systemd-241/deepin (debian) I cannot either, if
the final name is a custom one through udev rule or .link file.
Am 23.05.20 um 15:13 schrieb Andrei Borzenkov:
23.05.2020 11:56, Ede
So I have an environmentfile containing two variable definitions:
RUNASUSER=nobody
MEM=4294967296
And my service section reads:
[Service]
EnvironmentFile=/path/myfile
User=$RUNASUSER
LimitMEMLOCK=$MEM
This service failes to startup, as I cannot seem to being able to use a
variable for the Us
I am not sure what made you think this works, but systemd has no
Pure logic of conclusion. Besides this being a sensible thing to be able
to do, why is LimitMEMLOCK not causing the unit to fail, when given a
(non existing) variable? Or, since it is no variable from a systemd
point of view,
Am 25.06.20 um 14:30 schrieb Lennart Poettering:
Nah, unless you write a shell or templating language I doubt variable
expansion is a good thing.
I am aware, that discussion here is futile, but this is contradictious,
because:
[Unit]
Description=test service
[Service]
User=%i
Type=oneshot
Thanks for the heads up, but I've just used nobody as an example here,
because everybody knows, it is a systems user and therefore not to be
confused. Just to make it more clear.
Generally I do like the concept of dynamic users, but there are still
some open questions left and therefore needs
what exactly stands in your way to use
ExtecStart=/usr/local/bin/myscript.sh?
Because my question was about making a template unit file more dynamic,
not the process called by the unit.
Having an environmentfile %i.env, that a) defines the environment for
the actual service to be called
I do this today using a drop-in, because environment variables can be
set there as well. It works very well, exactly as you describe. There
is a template service unit file, and a drop-in directory for each
instance which contains a file that sets the environment variables and
also provides values
Just a wild guess, but I'd start with a combination of one of those:
# -
[Unit]
Description=my service
Before=network.target
Before=systemd-networkd.service
Before=network-online.target
Before=systemd-networkd-wait-online.service
...
[Install]
WantedBy=Basic.target
# -
Probably so
be prefixed with a % :)
Until then I'll stick with dedicated unit files.
Ede
Am 26.06.20 um 15:27 schrieb Lennart Poettering:
On Do, 25.06.20 20:25, Ede Wolf (lis...@nebelschwaden.de) wrote:
Does work, so %i works, $SOMETHING not. Different naming, different way of
invocation, I am aware
Hi,
My journal get spammed with messages from timesyncd, claiming a changed
network connection. However, I have not touched the network
configuration at all and the ntp even happens to be on the same subnet.
No DHCP either.
Here two examples, 200 messages in 20 minutes uptime, or 5800 of th
Am 10.02.21 um 22:38 schrieb Dan Nicholson:
On Wed, Feb 10, 2021 at 11:49 AM Ede Wolf wrote:
My journal get spammed with messages from timesyncd, claiming a changed
network connection. However, I have not touched the network
configuration at all and the ntp even happens to be on the same subne
suitable servers where found.
Makes me wonder, wether timedatectl could have been used as well?
Once the ntp issue had been fixed, the log messages vanished.
Just as a reference for future generations
Am 11.02.21 um 17:22 schrieb Mantas Mikulėnas:
On Thu, Feb 11, 2021 at 6:07 PM Ede Wolf
30 matches
Mail list logo
