IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 9 March 2021   (all times are UTC)

03:36GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 276 seconds)
03:50lucas_ has joined IRC (lucas_!~lucascast@177-185-133-170.dynamic.isotelco.net.br)
03:51lucas_ is now known as Guest49163
03:59lucascastro has left IRC (lucascastro!~lucascast@177-185-133-170.dynamic.isotelco.net.br, *.net *.split)
03:59sutula has left IRC (sutula!~sutula@184.97.9.9, *.net *.split)
04:01sutula has joined IRC (sutula!~sutula@184.97.9.9)
04:04vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:01RaphGro has joined IRC (RaphGro!~raphgro@fedora/raphgro)
06:41ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:44woernie has joined IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de)
07:55woernie has left IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de, Ping timeout: 264 seconds)
07:56woernie has joined IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de)
07:59sfxworks has joined IRC (sfxworks!46a07ce1@ip70-160-124-225.hr.hr.cox.net)
08:00
<sfxworks>
Hi. Following the guide: I get "I don't know how to mount /srv/ltsp/ubuntu.img"
08:00
<alkisg>
Hi sfxworks, and what is that image?
08:00
<sfxworks>
Could not parse output of: ip -o route get 192.168.67.1
08:00
LTSP command failed: blkid -po export /srv/ltsp/ubuntu.img
08:00
was the error
08:00
<alkisg>
What's the output of `file /srv/ltsp/ubuntu.img`
08:00
<sfxworks>
root@ryzen1:~/vms# file /srv/ltsp/ubuntu.img
08:01
srv/ltsp/ubuntu.img: symbolic link to /root/vms/focal-server-cloudimg-amd64.img
08:01
It is the ubuntu 20.04 image
08:01
Though I did try to add my ssh key to it
08:01
I used virt-sysprep -a focal-server-cloudimg-amd64.img --ssh-inject root:file:/root/.ssh/id_rsa.pub
08:02
<alkisg>
What's the output of `file /root/vms/focal-server-cloudimg-amd64.img`
08:02
I haven't seen that image
08:02
<sfxworks>
`/root/vms/focal-server-cloudimg-amd64.img: QEMU QCOW2 Image (v2), 2361393152 bytes`
08:02woernie has left IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de, Ping timeout: 264 seconds)
08:02
<sfxworks>
It is from https://cloud-images.ubuntu.com/focal/current/
08:02
<alkisg>
sfxworks: ltsp doesn't support qcow2, it only supports raw images
08:02
You'll need to decompress it
08:02
<sfxworks>
Ah okay, thanks!
08:02
<alkisg>
np
08:04woernie has joined IRC (woernie!~werner@www.velometrik.eu)
08:09
<alkisg>
(initially, I started using libguestfs to support qcow2 as well, but then I wanted to be able to mount the VMs from the initramfs as well, to boot clients directly with them, so I stopped using libguestfs)
08:15
<sfxworks>
I... See- hmm .I think I followed the wrong installation guide possibly? https://ltsp.org/docs/installation/ as soon as I ran the ltsp image command my server rebooted into an ubuntu desktop environment of which I do not know the password to...
08:16
<alkisg>
sfxworks: eeeh, ltsp doesn't modify your server
08:16
Are you talking about your client?
08:17
That page is the one and only installation guide, it's fine
08:17
<sfxworks>
No err the server. I ran it on a machine in a datacenter and it just suddenly rebooted into a desktop env.
08:17
<alkisg>
Can you share the history of commands that you ran?
08:17
<sfxworks>
I had to connect to it via it's BMC
08:17
<alkisg>
I.e. type history or sudo history
08:17
(put it to pastebin if so)
08:17
Or you could share your screen with me if you like, it'll certainly be faster...
08:18
<sfxworks>
Here is what I have: https://gist.github.com/sfxworks/7e2d1a014242d67031a145f8e704a0d9
08:19
Ah I do not want to take your time with a screenshare! Sorry about this though I do appreciate the support.
08:19
<alkisg>
No worries. I usually prefer screen sharing as it's 10 times faster than IRC :)
08:19* alkisg does "remote support" as it's main 3 jobs...
08:21
<sfxworks>
Erm, I am sorry I am a bit hesitant in doing that. Though if you are available for a call using discord or similar I could share my screen there. I would just not be ok with yielding control.
08:22
<alkisg>
No worries
08:22
sfxworks: I don't use cloud images (why do you opted on cloud instead of a usual desktop image), but I don't see anything that resembles the installation of a desktop environment there
08:23
<sfxworks>
Yeah that's what I am wondering about...
08:23
<alkisg>
So on your server, what's the output of: ls /usr/share/xsessions
08:23
<sfxworks>
It definitely has taken me by surprise. Especially since this was an environment with containers and nothing is installed on this host.
08:23
<alkisg>
And of : cat /var/log/apt/history.log
08:25
<sfxworks>
https://gist.github.com/sfxworks/a6f0c7cf98fe6513bd907b4c48f66c63
08:25
I see `gnome-control-center-data:amd64`
08:25
from the apt install --install-recommends
08:25
ltsp etc
08:26
<alkisg>
sfxworks: ah, you installed epoptes in a headless environment
08:26
epoptes is a graphical tool, you should have omitted that on headless servers
08:26
<sfxworks>
Ah understood!
08:26
<alkisg>
I'd purge all these packages that were installed by that last command, then I'd reinstall ltsp without epoptes
08:29
<sfxworks>
Do you think I would be just as safe with a purge on just epotes?
08:29
Running a purge on the installer command yields:
08:29
 kubelet : Depends: ethtool but it is not going to be installed
08:29
and similar
08:29
<alkisg>
Try sudo apt purge --auto-remove epoptes epoptes-client, and see
08:29
If it removes gnome, ok, if not, no
08:30
Autoremove doesn't remove packages that were recommended by OTHER packages than epoptes
08:30
So it'll leave packages that weren't there yesterday
08:33
<sfxworks>
Gotcha.. Understood. Giving that a shot. Thank you so much!
08:33
<alkisg>
np
08:33
The best would be to get the list of the packages, and remove just them
08:33
A simple sed command should produce the list...
08:41
<sfxworks>
Perfect! Situation resolved.
08:41
<alkisg>
Great
08:59adrianorg has left IRC (adrianorg!~adrianorg@177.156.230.68, Ping timeout: 276 seconds)
08:59adrianorg has joined IRC (adrianorg!~adrianorg@189.58.183.22.dynamic.adsl.gvt.net.br)
09:10
<sfxworks>
Should I be concerned about: Mar 09 09:07:42 ryzen1 dnsmasq-tftp[6954]: file /srv/tftp/ltsp/ltsp.img not found?
09:10
<alkisg>
sfxworks: yes, it means you didn't run `ltsp initrd`
09:10
The clients won't boot without it
09:10
<sfxworks>
Ah
09:11woernie has left IRC (woernie!~werner@www.velometrik.eu, Ping timeout: 256 seconds)
09:11woernie has joined IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de)
09:13
<sfxworks>
Thanks! Sorry I thought that was optional. I'm guessing ltsp nfs is required too?
09:13
<alkisg>
sfxworks: yes all the steps in the installation page are mandatory
09:15
<sfxworks>
Understood, thanks!
09:19
No errors so far, but when I ran nfs, intrig and image I got `Could not parse output of: ip -o route get 192.168.67.1` even though I have that IP on the machine via netplan on eno2. Is this something to be concerned about?
09:20
It appears as `local 192.168.67.1 dev lo table local src 192.168.67.1 uid 0 \ cache <local>`
09:20
It also appears on ip a `    inet 192.168.67.1/24 brd 192.168.67.255 scope global eno2`
09:21
<alkisg>
sfxworks: it shouldn't cause any issues, but can you upload the whole output of `ip -o route get 192.168.67.1` to pastebin?
09:21
<sfxworks>
Just can't seem to ping the machine fetching the files yet: `PING 192.168.67.247 (192.168.67.247) 56(84) bytes of data.` `From 192.168.67.1 icmp_seq=1 Destination Host Unreachable`
09:22
The whole output is just `local 192.168.67.1 dev lo table local src 192.168.67.1 uid 0 \ cache <local>`
09:22
<alkisg>
OK, I'll note it down and troubleshoot that later
09:22
It shouldn't cause any issues
09:23
<sfxworks>
Understood.
09:23
The files were served... `sent /srv/tftp/ltsp/ubuntu/initrd.img to 192.168.67.247`. Hmm I wonder why it isn't up yet...
09:23
<alkisg>
Next message there would be the nfs successful mount notification
09:24
Run `journalctl -f` on the server, and watch the client screen too
09:29
<sfxworks>
Hmm I am not seeing this. Though I made sure I ran `ltsp nfs` and I have the nfs-kernel-server package `nfs-kernel-server is already the newest version (1:1.3.4-2.5ubuntu6).`
09:29
<alkisg>
What messages do you see on the client screen?
09:30
<sfxworks>
Unfortunately these clients do not have a bmc. I can try running this on a home lab.
09:30
<alkisg>
What is a bmc?
09:31
A screen?
09:31
Can't you test with a VM client with a normal screen?
09:31
<sfxworks>
baseboard management controller
09:31
Err yeah thats a good idea
09:32
I'd just have to remake some bridges...
09:48ghaoil has joined IRC (ghaoil!~ghaoil@31.7.247.13)
09:53
<sfxworks>
Can't replicate using the VM. Interesting... I wonder if one of my machines is having issues in general.
09:53
Nice though, glad to see it in action!
09:54
<alkisg>
Great
09:59
<sfxworks>
This appears on the clients from the log...  `error 8 User aborted the transfer received from 192.168.67.247`
09:59
I found this as a result: https://dnsmasq-discuss.thekelleys.org.narkive.com/dM1IXeKH/dnsmasq-tftp-failed-sending-file
09:59
<alkisg>
sfxworks: and the client fails to boot, or continues normally?
10:00
<sfxworks>
For the two baremetal machines (not the VM) the logs show that dnsmasq-tftp is sending more files for a bit. Though it isn't reachable.
10:01
I can ping the vm and ssh (though I need to adjust my keys) but can't do anything with the bare metal machines.
10:02
<alkisg>
Eeeh, so did you see a login screen on the VM? Were you able to login with a user there?
10:02
<sfxworks>
yeah I have a login screen on the VM
10:03
Though it didn't save the ssh public key I injected
10:03
Assuming it is working otherwise though.
10:03
<alkisg>
!ssh
10:03
<ltspbot>
I do not know about 'ssh', but I do know about these similar topics: 'sshd'
10:03
<alkisg>
!sshd
10:03
<ltspbot>
sshd: Exposing sshd host keys over NFS is unsafe, so it's disabled by default and !epoptes is recommended instead. If you insist on running sshd in LTSP clients, read https://github.com/ltsp/ltsp/discussions/310#discussioncomment-101549
10:04
<alkisg>
About the bare metal client, we'd need to read its screen
10:43
<ghaoil>
Is ltsp still affected by the sshfs / gnome-keyring bug described here: https://bugzilla.gnome.org/show_bug.cgi?id=730587
10:43
<alkisg>
ghaoil: yes and no; i.e. it is, but a work around disables gnome-keyring if it detects sshfs
10:44
So the end result is that ltsp users that use sshfs, just can't use gnome-keyring, but without the "65000 temp files" side effect
10:45
<ghaoil>
I tried mounting the '~/.local/share/keyrings' separately and it works around the issue while still allowing you to use gnome keyring.
10:45
So it's recursively mounted.
10:45
<alkisg>
ghaoil: where is it mounted from, e.g. sshfs, or nfs, or tmpfs?
10:46
<ghaoil>
It's mounted from sshfs too. It works aound the issue for whatever reason.
10:46
<alkisg>
How are you doing a second sshfs mount without requiring the user to enter his password again?
10:46
passwordless sshfs?
10:46
<ghaoil>
https://pastebin.com/zxrZtdsF
10:47
<alkisg>
pam_mount?
10:47
<ghaoil>
I'm using pam_mount.
10:47
<alkisg>
LTSP is disabling symlink forwarding for safety and in order for chrome to work,
10:48
one could enable them and have sshfs working (like you do), but at that ^ cost
10:48
<ghaoil>
With the configuration in that paste, chrome works.
10:48
<alkisg>
And .ICEauthority too?
10:49
ghaoil: ah ok you disable hardlinks, you don't enable symlink forwarding
10:49
<ghaoil>
I could test it if that would be helpful. You'd have to tell me how though.
10:49
<alkisg>
I don't know what that breaks
10:50
That means that the ln (without -s) command would fail, along with any program that uses it
10:50
I'd prefer to spend a couple of hours and fix this in gnome-keyring, rather than try to find which other programs would break if applying "disable_hardlinks"...
10:52
<ghaoil>
ln without -s works.
10:52
<alkisg>
Although, if you're only applying that inside that dir, it shouldn't affect other programs...
10:52
Inside that dir?
10:52
Or outside it?
10:52
<ghaoil>
Inside and out
10:53
<alkisg>
man sshfs => -o disable_hardlink => link(2) will return with errno set to ENOSYS. Hard links don't currently work perfectly on sshfs, and this confuses some programs. If that happens try disabling hard links with this option.
10:54
I read that as "the link call will fail"; not sure which program will misbehave with that
10:54
<ghaoil>
alkisg, fwiw I remembered this bug and we have been using this workaround for more than two years.
10:55
<alkisg>
You could probably just put SSH_OPTIONS="-o disable_hardlink" in ltsp.conf instead of that
10:55
<ghaoil>
This exact configuration. I'd love to see a bug fix in gnome-keyring but given that the bug is open since 05-2014, I won't hold my breath.
10:55
<alkisg>
Yeah someone affected should spend some time to send a patch
10:56
I didn't want to do that myself too, as we don't even use sshfs here, we're using nfs
10:56
<ghaoil>
I'm not using LTSP, I used to, we could not imagine not having gnome-keyring as we're using evolution extensively.
10:57
<alkisg>
Eh, it's just an ltsp.conf option to make it work
10:57
SSH_OPTIONS="-o disable_hardlink"
10:57
And if it doesn't break anything else for you, np then
10:57
<ghaoil>
I, just wanted to bring it to your attention.
10:57
<alkisg>
Thank you for that, much appreciated
10:57
<ghaoil>
So are you saying that I could do a single mount?
10:58
<alkisg>
Maybe disabling hardlinks is a better default than disabling gnome-keyring
10:58
Yes
10:58
Well... not sure if any programs would break with that
10:58
You'd need to test; just put disable_hardlink in the main sshfs mount
11:01
<ghaoil>
Okay, I will do some tests with that I need to make sure that that wouldn't break anything else before I deploy that.
11:01
<alkisg>
:thumbs:
12:05bcg__ has left IRC (bcg__!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, Quit: bcg__)
12:05bcg has joined IRC (bcg!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi)
12:13Douglas_br has joined IRC (Douglas_br!bd4cbe5a@189.76.190.90)
12:15
<Douglas_br>
Hello! How are you? I am reading ltsp.conf doc. so very interting about client multiseat. Does It works with hdmi and VGA devices?
12:16
and DVI. Nowday there are mobos with 3 options
12:36
please question: when configure an user with autologin, at the server side, I add an user in GUI mode an put password base64 or not, only inside ltsp.conf goes password base64?
12:52
for example: Gui mode: user01 password: user01. So, On the ltsp.conf change for base64?
13:30ghaoil has left IRC (ghaoil!~ghaoil@31.7.247.13, Read error: Connection reset by peer)
13:30ghaoil has joined IRC (ghaoil!~ghaoil@31.7.247.13)
13:54Douglas_br has left IRC (Douglas_br!bd4cbe5a@189.76.190.90, Ping timeout: 240 seconds)
14:02Douglas_br has joined IRC (Douglas_br!bd4cbe5a@189.76.190.90)
14:04
<Douglas_br>
hello
14:04
please question: when configure an user with autologin, at the server side, I add an user in GUI mode an put password base64 or not, only inside ltsp.conf goes password base64?
14:04
for example: Gui mode: user01 password: user01. So, On the ltsp.conf change for base64?
14:13
<sebd>
Douglas_br: I have never used the autologin feature yet, sorry. But please wait some more time, someone will know and answer you.
14:13
Usualy questions get answered quite fast here.
14:17
<alkisg>
Douglas_br: regarding multiseat, ltsp currently supports what systemd supports, which is clients with MORE than one graphics cards
14:18
Xorg does supports multiuser with graphics cards that have multiple outputs, but systemd doesn't support that, so to do that in ltsp, it's possible, but it's not automated
14:19
Autologin only needs a password if you use sshfs. If you use nfs, there's no need to specify a password,
14:19
the password is set for the user normally on the server, and in ltsp.conf it goes in base64 form
14:51sfxworks has left IRC (sfxworks!46a07ce1@ip70-160-124-225.hr.hr.cox.net, Ping timeout: 240 seconds)
14:52
<alkisg>
ghaoil: you're using iscsi to netboot the clients? Did you put a custom script in initramfs-tools for that?
14:53
<ghaoil>
There is a parameter set in the iscsi configuration on the client
14:53
That is all that's needed
14:54
I have ipxe make the initial connection
14:54
<alkisg>
ghaoil: can you share the output of `cat /proc/cmdline` of an ltsp client?
14:59
<ghaoil>
alkisg: https://pastebin.com/Z5K8KBMi
14:59
We don't use LTSP
14:59
<alkisg>
ghaoil: sure, but... where's the netboot information there? :D
14:59
ipxe can connect to iscsi, sure, but what about the initramfs, how can it find it?
15:00
Are you sure that's from a netbooted (sorry not ltsp) client, and not from the server itself?
15:01
<ghaoil>
You create the file '/etc/iscsi/iscsi.initramfs'
15:01
And set its contents to 'ISCSI_AUTO=true'
15:01
<alkisg>
Something like this? https://github.com/intel/intelRSD/issues/26#issuecomment-311656769
15:02
If so, ok then, netbooting is handled by open-iscsi...
15:02
And I guess you send the information via dhcp
15:03
<ghaoil>
Yes, we're using open-iscsi as described in that post.
15:04
<alkisg>
ghaoil: how does the "cow" part work? Each client gets each own pool/snapshot of zfs/lvm/something?
15:05
<ghaoil>
In zfs we create a anspshot after we changed something. Than the clone is made of the last snapshot.
15:05
An existing snapshot gets deleted unless we choose not to. So it allows for 'persistent' images.
15:05
<alkisg>
But how can multiple clients work with a single snapshot? Or does each client get its own snapshot or image?
15:06
<ghaoil>
In LVM the LV gets cloned right away.
15:06
Each client gets it's own snapshot using the mac address as identifier which we retrieve through IPXE
15:07
<alkisg>
Is this secure? If a client fakes another mac, it can inject data to the other's disk?
15:09
<ghaoil>
Yes, theocratically knowing the mac of another computer, you could connect to it's image I can image using CHAP authentication to prevent this. Haven't implemented this.
15:09
Also, iSCSI is not secure.
15:09
<alkisg>
Is there any benefit to "not using cow", other than saving a few MB RAM on the netbooted client?
15:10
Why not just use an overlay?
15:10
<ghaoil>
We ran into issues where printing was a big problem because of the lack of storage space.
15:11
<alkisg>
Also, theoretically, a misbehaving client may fill up your server's disk by writing junk in its own / ?
15:12
<ghaoil>
No, it's limited to a maximum space which we set to 32GB clients will typically use less than that.
15:12
<alkisg>
Very nice
15:12
<ghaoil>
Also, we include a swap partition in our image.
15:12
<alkisg>
Does it also support a /swapfile? Or it hangs over iscsi?
15:12
Got it
15:13
<ghaoil>
And we compress the image using ZSTD on the filesystem level which has improved performance dramatically.
15:13
<alkisg>
Although, the image isn't compressed in squashfs, right? So disk access should be around 5 times lower...
15:13
Aaaah
15:14
Hehe you answer right before I ask the question :D
15:14
OK then only the metadata is uncompressed, it should be around 2 times slower than squashfs...
15:15
(based on benchmarks I've done with squashfs over nfs, vs btrfs image with compression over nfs)
15:16
ghaoil: how stable is iscsi? E.g. nfs allows even server rebooting without client hanging; while nbd was so unstable, that a small disconnection would make clients hang
15:16
<ghaoil>
Yes, squashfs is faster but we've found this to be more theoretical that practical as we couldn't tell the difference in day to day use. And we're happy not to have to build images.
15:18
We've tried NBD too, although slightly faster, again purely theoretical, iSCSI is a lot more stable and supports reconnect.
15:18
The client does freeze eventually but continues when the server is available again.
15:18
<alkisg>
Awesome
15:20
So essentially you gain a lot, and only lose the ability to netboot a chroot or an .iso
15:20
(the new ltsp supports netbooting .isos directly, with no ltsp image involved)
15:21
<ghaoil>
You can export ISO's with Lio
15:21
But I've never done anything with it.
15:23
<alkisg>
I definitely want to add iscsi booting support to ltsp, and I also played with zfs snapshots a bit and I was amazed by their possibilities
15:23
The ltsp web server will also be similar to what you have for ipxe, except it'll manage more stuff, like ltsp.img and settings
15:24
Another thing I want to add support for, is local mirroring / caching, as with the new disk technology, local disks are waaaaay faster than networks
15:25
<ghaoil>
It's very nice to be able to 'do stuff' as the client connects to your server at boot time.
15:25
<alkisg>
NVMe drives = 20 gbps each, times 10 clients => 200 gbps, can't have network that fast
15:26
<ghaoil>
I've found that on a server that has enough memory, you can not win on performance using fast drives if you have enough memory and use ZFS.
15:26
<alkisg>
Yeah unfortunately I had to rewrite ltsp from scratch, and I didn't have the time to add a web service in time
15:26
I've tested ltsp on up to 80 gbps network with zfs
15:27
It's excellent, but it won't reach the speed of local nvme drives
15:27
<ghaoil>
As long as the image fits in the memory of the server, you don't need fast drives.
15:27
<alkisg>
The problem isn't while reading or caching the image on the server
15:27
It's while sending it to the clients
15:27
If the server has a 10 gbps NIC, it can't send more than that
15:28
If it has 1 gbps nic... then 10 clients launching libreoffice will need 15 seconds each
15:28
<ghaoil>
True, I'ce never reached nvme speeds on the clients
15:28
<alkisg>
This is fine, but raising to 100 clients causes a bottleneck
15:29
While with bmcache or other technologies, local caching could dramatically improve this
15:29
For local caching to work though, the same read only base should be synced between clients
15:29
And a writable overlay can be created over it using local storage, to have enough memory for swap, printing etc
15:31
10 years in the future, I imagine I'll have usb 4.0 sticks that will costs 5€ and be able to transfer at 10+ gbps each; while my local network will still be less than that for ALL clients... I'll definitely want to utilize local storage then
15:32
(a usb 3 ssd can do that currently with 20 €)
15:33
<ghaoil>
It's possible to have local nvme and sync an image locally.
15:34
Especially with ZFS where you can just send the delta, this should be fast.
15:37
<alkisg>
Indeed that's a very good option, we're also using it for remote /home backups
15:38
<ghaoil>
Do you have anything online regarding the ltsp web interface
15:38
<alkisg>
Only a blueprint, https://github.com/ltsp/ltsp/issues/147
15:39
Is your code uploaded publicly somewhere? Or is it internal for now?
15:39
<ghaoil>
Are you writing it in python?
15:39
<alkisg>
I haven't started yet. I'm between python, php and node
15:40
The "real" code will definitely be shell and python; just the web service may be python/php/node
15:40
<ghaoil>
I wrote our we iinterface in node and have it connect to a python daemon using sockets.
15:41
It's very, but it does the trick.
15:41
It was my first python project.
15:41
<alkisg>
I also want to implement long polling there, so that the server will be able to push notifications to the clients at any time
15:42
I described what I could in that url above; but I'll start implementing it next year, not now...
15:43
<ghaoil>
I had a socket connection between the client and the server once. I didn't have a real need for it so I dropped it.
15:43
More recently I have been thinking about avahi
15:44
But that's more for client discovery, not sending commands or messages.
15:44
<alkisg>
Yeah, and it also doesn't work over WAN
15:45
<ghaoil>
true
15:45
<alkisg>
Some schools here already have 250Mbps connections; I want to be able to tell them "netboot this school client from my remote support office, and I'll install the XXX OS for you"
15:46
<ghaoil>
Well, I sure that our use case is a lot more narrow than the things you've come across.
15:47
I wouldn't mind to make some of the code available, so you can have a look.
15:48
<alkisg>
ghaoil: thank you for that. I'd love to! But it'll have to wait until next year, as I'm finishing my ...very...late... phd this year :)
15:49
<ghaoil>
Very encouraging, much grace with that.
16:01ghaoil has left IRC (ghaoil!~ghaoil@31.7.247.13, Ping timeout: 276 seconds)
16:28Douglas_br has left IRC (Douglas_br!bd4cbe5a@189.76.190.90, Quit: Connection closed)
17:52ghaoil has joined IRC (ghaoil!~ghaoil@hs-user-138.wia.cz)
18:45GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
18:48ghaoil has left IRC (ghaoil!~ghaoil@hs-user-138.wia.cz, Ping timeout: 256 seconds)
18:56GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Quit: Ex-Chat)
18:56GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
19:13ghaoil has joined IRC (ghaoil!~ghaoil@hs-user-138.wia.cz)
20:09woernie has left IRC (woernie!~werner@pd9e8b5cc.dip0.t-ipconnect.de, Remote host closed the connection)
20:40ghaoil has left IRC (ghaoil!~ghaoil@hs-user-138.wia.cz, Ping timeout: 246 seconds)
21:23RaphGro has left IRC (RaphGro!~raphgro@fedora/raphgro, Quit: Please remember your own message. It'll be read as soon as possible.)
22:04bcg has left IRC (bcg!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, Ping timeout: 272 seconds)
22:06ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:27bcg has joined IRC (bcg!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi)