00:03 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
02:16 | clntkhtru has joined IRC (clntkhtru!57e15846@wc.42120015012.clnt.kht.ru) | |
02:30 | clntkhtru has left IRC (clntkhtru!57e15846@wc.42120015012.clnt.kht.ru) | |
06:47 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-58568f-194.dhcp.inet.fi, Ping timeout: 240 seconds) | |
06:49 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-50dda4-246.dhcp.inet.fi) | |
07:25 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
07:30 | <kvaps> it seems there is some bug in ubuntu's network_configuration script in initramfs-tools
| |
07:30 | https://gist.github.com/kvaps/83cedefb9b1605fda91d75cdb778a716#file-initramfs-no-ip-console-L591-L744
| |
07:32 | `ip: SIOCGIFFLAGS: No such device` look like that the device does not yet exists when dhclient is called
| |
07:33 | oh it exists , but renamed to eno1 previusly
| |
07:34 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
08:18 | <kvaps> yep there is a race between mlx4_en and dhclient
| |
08:43 | `modprobe af_packet; wait_for_udev 10` solved problem
| |
09:11 | woernie has left IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de, Ping timeout: 256 seconds) | |
09:12 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
11:54 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
12:20 | <kvaps> alkisg: it was amazing journey to find and solve this race conditions, after I found how nfsroot developers are doing that *facepalm*
| |
12:21 | the just run configure_networking in a loop
| |
12:26 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: apt-get install hexchat) | |
12:27 | adrianorg has joined IRC (adrianorg!~adrianorg@189.114.158.29) | |
12:31 | adrianor1 has left IRC (adrianor1!~adrianorg@179.177.213.222.dynamic.adsl.gvt.net.br, Ping timeout: 256 seconds) | |
12:31 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
13:07 | <alkisg> kvaps: hehe, been there, done that :D
| |
13:07 | At one time my own implementation of "configure_networking" was much more stable than the one in initramfs-tools...
| |
13:08 | But they play with it so much that it's not worth to try to keep up with all the changes...
| |
13:08 | <kvaps> Yep also initramfs-tools for debian and ubuntu are bit different
| |
13:09 | <alkisg> Ubuntu got netplan so they changed it quite a bit
| |
13:09 | dhclient is better than ipconfig, but it should go upstream in debian, not downstream in ubuntu...
| |
13:12 | <kvaps> I need to set an `HOSTS_x` variable for the ltsp applet from external file, do you think will `PRE_INIT_KUBERNETES_HOSTS=". /etc/ltsp/kubeadm-join.env"` work?
| |
13:14 | <alkisg> Sure, also: echo HOSTS_X=blah > /usr/share/ltsp/client/applet/55-environment.sh
| |
13:15 | I.e. the external script can generate an ltsp script in that path
| |
13:17 | <kvaps> Thanks, I'll try
| |
13:17 | Always wanted to ask, what do you use instead of RCFILE?
| |
13:19 | I usually ship the .service files with the ltsp.conf and installing them like this https://github.com/kvaps/kubefarm/blob/master/deploy/helm/kubefarm/templates/ltsp-configmap.yaml#L86-L90
| |
13:24 | <alkisg> kvaps: POST_SERVICE_x="blah"
| |
13:25 | There's the `ltsp service` applet for that; it works on the server too
| |
13:25 | <kvaps> got it
| |
13:26 | > also: echo HOSTS_X=blah > /usr/share/ltsp/client/applet/55-environment.sh That's pretty cool I can define new applets as a configmaps in kubernetes :D
| |
13:27 | <alkisg> And if you're using multiple servers, [server-mac] parameters => also works to run different things on each server
| |
13:28 | <kvaps> no-no my server is pretty stupid, there is just dnsmasq for tftp in single-port-mode and nginx, nothing else
| |
13:36 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 256 seconds) | |
13:37 | woernie has joined IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de) | |
14:28 | woernie has left IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de, Ping timeout: 240 seconds) | |
14:29 | <kvaps> alkisg: cloud you trigger ltsp-cloud build pls?
| |
14:30 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
14:33 | <alkisg> Done; off for now...
| |
14:35 | <kvaps> thanks!
| |
14:51 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
14:52 | RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro) | |
14:55 | woernie_ has joined IRC (woernie_!~werner@p5b296b80.dip0.t-ipconnect.de) | |
14:55 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 264 seconds) | |
15:08 | <kvaps> alkisg: is ltsp package required on the clients?
| |
15:14 | woernie_ has left IRC (woernie_!~werner@p5b296b80.dip0.t-ipconnect.de, Ping timeout: 256 seconds) | |
15:16 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
15:20 | <alkisg> kvaps: no, but squashfs module needs to be in the initramfs (ltsp puts it there)
| |
15:21 | <kvaps> ack
| |
16:06 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Ping timeout: 240 seconds) | |
16:06 | woernie has joined IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de) | |
16:31 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |
16:49 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
17:14 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
17:16 | <kvaps> alkisg: haven't you think to generate repeatable ssh keys for the clients?
| |
17:19 | RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.) | |
17:26 | <alkisg> kvaps: it needs a step for the server to trust the clients, so reverse epoptes connections are a lot better...
| |
17:26 | If one needs it though, he can surely implement it, and/or wireguard keys too
| |
17:29 | <kvaps> > reverse epoptes connections are a lot better... Do you mean case when clients accessing server not vise-versa?
| |
17:37 | <alkisg> Yes, that's how epoptes works
| |
17:37 | The server public key goes to the ltsp image, so the clients trust the server
| |
17:37 | and there's no need for the server to trust the clients that way, it's like https, not like ssh
| |
17:40 | <kvaps> Kubernetes is working the same way
| |
17:43 | But I would like to have some additional method like SSH to perform debug operations if its needed.
| |
17:44 | <alkisg> Sure, ssh can easily be activated...
| |
17:45 | <highvoltage> ~/win 15
| |
17:45 | <kvaps> Yep I'm using this already, I'm running ssh-keygen each new boot, and now I just thinking about some alternative
| |
17:46 | <alkisg> You can have static ssh keys and symlink them with POST_INIT
| |
17:47 | You can e.g. put them in /etc/ltsp/ so that they go in ltsp.img
| |
17:48 | <kvaps> Yep, that's possible but still less secure than generate always the same pairs using some salt value
| |
17:49 | <alkisg> The salt can be something from dmidecode, the machine serial number, the board uuid etc
| |
17:50 | But telling ssh-keygen to use specific salt is tricky
| |
17:50 | While e.g. wireguard configuration is a lot more easy and secure
| |
17:52 | <kvaps> yeah, cool idea. machine serial number should be enough
| |
17:57 | https://serverfault.com/questions/398633/can-ssh-keygen-be-seeded-to-generate-the-same-key
| |
18:40 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Ping timeout: 245 seconds) | |
18:45 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: $HOME) | |
18:58 | woernie has left IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de, Remote host closed the connection) | |
18:59 | woernie has joined IRC (woernie!~werner@p5b296b80.dip0.t-ipconnect.de) | |
20:02 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
20:02 | <kvaps> https://github.com/cornfeedhobo/ssh-keydgen
| |
20:25 | spectra has left IRC (spectra!~spectra@debian/developer/spectra, Ping timeout: 272 seconds) | |
20:41 | spectra has joined IRC (spectra!~spectra@debian/developer/spectra) | |
21:38 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |