| 30 Jun 2023 |
 hexa | never used those | 17:39:27 |
 @sumner:nevarro.space | this is what I get with ip a
root@matrix:~/ > ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 96:00:02:23:cd:a5 brd ff:ff:ff:ff:ff:ff
inet 5.161.216.225/32 brd 5.161.216.225 scope global dynamic eth0
valid_lft 71733sec preferred_lft 60933sec
inet6 fe80::9400:2ff:fe23:cda5/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
link/ether 86:00:00:44:d6:83 brd ff:ff:ff:ff:ff:ff
altname enp7s0
inet 10.0.1.3/32 brd 10.0.1.3 scope global dynamic eth1
valid_lft 71734sec preferred_lft 60934sec
inet6 fe80::8400:ff:fe44:d683/64 scope link
valid_lft forever preferred_lft forever
| 17:40:43 |
| @sumner:nevarro.space | * this is what I get with ip a
root@matrix:~/ > ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 96:00:02:23:cd:a5 brd ff:ff:ff:ff:ff:ff
inet 5.161.216.225/32 brd 5.161.216.225 scope global dynamic eth0
valid_lft 71733sec preferred_lft 60933sec
inet6 fe80::9400:2ff:fe23:cda5/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
link/ether 86:00:00:44:d6:83 brd ff:ff:ff:ff:ff:ff
altname enp7s0
inet 10.0.1.3/32 brd 10.0.1.3 scope global dynamic eth1
valid_lft 71734sec preferred_lft 60934sec
inet6 fe80::8400:ff:fe44:d683/64 scope link
valid_lft forever preferred_lft forever
this is with dhcp
| 17:40:57 |
| @sumner:nevarro.space | I don't know how to replicate that using just systemd.network | 17:50:45 |
| hexa | ip route? | 17:56:52 |
| @sumner:nevarro.space | root@matrix:~/ > ip route
default via 172.31.1.1 dev eth0 proto dhcp src 5.161.216.225 metric 1002
10.0.0.0/8 via 10.0.0.1 dev eth1 proto dhcp src 10.0.1.3 metric 1003 mtu 1450
10.0.0.1 dev eth1 proto dhcp scope link src 10.0.1.3 metric 1003 mtu 1450
172.31.1.1 dev eth0 proto dhcp scope link src 5.161.216.225 metric 1002
| 17:58:06 |
| hexa | legacy interface names 😲 | 17:59:22 |
| @sumner:nevarro.space | I set usePredictableInterfaceNames = false since I saw that recommended somewhere. | 18:01:14 |
| hexa | that is as silly recommendation 😄 | 18:01:24 |
| hexa | you need a mechanism to ensure the same interface comes up with the same name on every boot | 18:02:03 |
| hexa | the ethN scheme is first come, first served | 18:02:11 |
| hexa | systemd.network.enable = true;
systemd.network.networks."10-wan" = {
matchConfig.Name = "eth0";
networkConfig.DHCP = "ipv4";
};
systemd.network.networks."10-wan" = {
matchConfig.Name = "eth1";
address = [
"10.0.1.3/32"
]:
routes = [
{ routeConfig.Destination = "10.0.0.0/8"; }
];
};
| 18:03:09 |
| hexa | * systemd.network.enable = true;
systemd.network.networks."10-wan" = {
matchConfig.Name = "eth0";
networkConfig.DHCP = "ipv4";
};
systemd.network.networks."10-wan" = {
matchConfig.Name = "eth1";
networkConfig.DHCP = "ipv4";
};
| 18:04:04 |
| hexa | * systemd.network.enable = true;
systemd.network.networks."10-wan" = {
matchConfig.Name = "eth0";
networkConfig.DHCP = "ipv4";
};
systemd.network.networks."10-vpn" = {
matchConfig.Name = "eth1";
networkConfig.DHCP = "ipv4";
};
| 18:04:11 |
| @sumner:nevarro.space | should I also re-enable usePredictableInterfaceNames and update the matchConfig.Name accordingly, then? | 18:06:01 |
| hexa | in that case I would recommend going with matchConfig.MACAddress | 18:06:31 |
| hexa | because what are the new names going to be? | 18:06:55 |
| hexa | probably mentioned somewhere in dmesg | grep renamed | 18:07:19 |
 Zhaofeng Li | (apparently I missed the whole conversation) I pin against MAC addresses as well | 18:16:38 |
| Zhaofeng Li | ... and I go one step further and rename the interfaces to wan/lan/bedroom etc | 18:17:05 |
| @sumner:nevarro.space | thanks for your help, I went ahead and pinned to mac address and it seems to be working. I'll just have to wait and see if I get pinged in the middle of the night again because my server is down due to forgetting how to connect to the internet. I guess networkd is probably more reliable than using dhcpcd? | 19:10:37 |
| 2 Jul 2023 |
|  duponin left the room. | 20:23:43 |
| 4 Jul 2023 |
|  jlesquembre joined the room. | 09:14:55 |
| 10 Jul 2023 |
 @julian:nekover.se | Hi, why is StrictHostKeyChecking=accept-new enabled per default and is there an option to disable it? | 01:28:01 |
| @julian:nekover.se | Also I'm not sure, if it's great to that option enabled per default. While it's certainly fine for most use cases - depending on where your remote hosts are and what your threat model is - I think such an option should be opt in and not opt out.
I certainly wouldn't expect software to auto-accept remote SSH keys for me, so I was also kinda bamboozled finding out colmena did. | 01:44:40 |
| 11 Jul 2023 |
|  @beect:matrix.org joined the room. | 10:52:41 |
| 12 Jul 2023 |
|  @aktaboot:tchncs.de joined the room. | 22:21:10 |
| @aktaboot:tchncs.de | hello,
Is it possible to (re)use lib.nixosSystem definitions with colmena directly ? | 22:22:39 |
| @aktaboot:tchncs.de | Since I already have each host defined as a lib.nixosSystem attrset | 22:23:46 |
| 13 Jul 2023 |
| Zhaofeng Li | In reply to @julian:nekover.se
Hi, why is StrictHostKeyChecking=accept-new enabled per default and is there an option to disable it? (oof, somehow missed the notification)
It's enabled by default since there isn't a good way to manually accept the keys when deploying to multiple hosts in parallel yet. There isn't an option to disable it right now, but perhaps it can be overridden by SSH_CONFIG_FILE (not sure - need to test)
| 02:31:05 |
