IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 14 May 2019 (all times are UTC)
| 05:05 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
| 05:18 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b) | |
| 05:26 | woernie has joined IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de) | |
| 05:40 | woernie has left IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 05:45 | <alkisg> vagrantc: hmm, for squashfs over nfs, `mount -o ro /root/buster-squashfs.img /mnt` gives me: "mount: mounting /dev/loop0 on /mnt failed: No such file or directory"
| |
| 05:46 | It's like loop devices and nfs don't mix well
| |
| 05:47 | <vagrantc> mount -o loop,ro ...
| |
| 05:47 | * alkisg tries from a real client instead for from an initramfs... | |
| 05:48 | <alkisg> I tried it, the same; the man page also says that loop is ignored/autodetected currently
| |
| 05:48 | <vagrantc> might also need to modprobe squashfs first
| |
| 05:48 | initramfs mount ... sometimes has misleading error messages
| |
| 05:48 | <alkisg> Hmm squashfs doesn't appear in lsmod, even after I try `modprobe squashfs`
| |
| 05:49 | <vagrantc> cat /proc/filesystems
| |
| 05:50 | <alkisg> It worked from the server itself
| |
| 05:50 | squashfs doesn't appear in /proc/filesystems
| |
| 05:51 | Maybe it's only loaded on demand?
| |
| 05:52 | !nbd-client
| |
| 05:52 | <ltsp> nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
| |
| 05:53 | <vagrantc> i seem to recall in initramfs-tools we had to both add a hook to add the module to the initramfs as well as maybe manually loading it in the initramfs
| |
| 05:53 | * alkisg wonders if he's stupid enough to assume that squashfs exists in the initramfs, and didn't include it :D | |
| 05:53 | <vagrantc> it definitely shows up in /proc/filesystems after loading the module here
| |
| 05:53 | <alkisg> I was trying with a clean buster vm, after only installing nbd-client
| |
| 05:53 | <vagrantc> that might make it trickier to do the "append to initramfs" trick.
| |
| 05:54 | <alkisg> So it's possible that the squashfs module isn't even included, let me check...
| |
| 05:54 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Read error: Connection reset by peer) | |
| 05:55 | <vagrantc> not included by default in a run-of-the-mill initramfs
| |
| 05:55 | on buster
| |
| 05:55 | <alkisg> Gotcha; thanks, trying...
| |
| 05:55 | <vagrantc> lsinitramfs /boot/initrd.img-VERSION
| |
| 05:55 | so we'd need at least some sort of hook "client" side to make sure the initramfs contains the right modules...
| |
| 05:55 | <alkisg> (I also had the same "not found" message when trying to mount a .raw image with losetup or mount -o offset, and that was misleading there... maybe yet another missing module though)
| |
| 05:56 | <vagrantc> also possible
| |
| 05:56 | <alkisg> Indeed
| |
| 05:56 | It's silly that even dmesg doesn't say which module isn't there
| |
| 05:56 | do a printf to stderr, people! :D
| |
| 05:56 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b) | |
| 05:56 | <vagrantc> it's an initramfs, not a real OS! :P
| |
| 06:04 | <alkisg> zstd_decompress/squashfs needed
| |
| 06:04 | <vagrantc> zstd is new ...
| |
| 06:05 | very fast decompression
| |
| 06:05 | <alkisg> The initramfs code probably puts it there as a squashfs dependency though
| |
| 06:05 | While now in the clean initramfs, it wasn't there
| |
| 06:05 | Oh well our ltsp-client "metapackage" will need to pull those in too
| |
| 06:06 | I think it still make sense to use a server-side ltsp-initrd.img, as it allows the ltsp code to live there and be easily updated, and it ships lts.conf early in the initramfs, to use per-client mount options etc
| |
| 06:07 | (it worked fine now; thanks for all the help!)
| |
| 06:07 | <vagrantc> right
| |
| 06:07 | <alkisg> let me test speeds
| |
| 06:07 | <vagrantc> and that you can update *just* a little archive for new ltsp code is still very useful
| |
| 06:08 | <alkisg> Yeah `ltsp-initrd` currently needs less than 1 sec
| |
| 06:10 | gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Ping timeout: 245 seconds) | |
| 06:11 | <alkisg> In the "same arch" case, it would be possible to put these in the initramfs even from ltsp-update-image / cleanup phase
| |
| 06:11 | Unfortunately doing this without chrooting would involve copying a lot of code from initramfs-tools for dependency walking, probably not worth it
| |
| 06:12 | <vagrantc> you could add initramfs-tools hooks at that phase and regenerate the initramfs if needed
| |
| 06:12 | <alkisg> Yes, but that would only work in the same arch, where we can chroot
| |
| 06:12 | (or use qemu)
| |
| 06:13 | <vagrantc> recently initramfs-tools started using parallel compression ... *much* faster
| |
| 06:13 | qemu works pretty well for arm*
| |
| 06:17 | * alkisg prepares a "nbd vs squashfs-over-nfs" test with a real gigabit client... | |
| 06:18 | <vagrantc> when i tested ... 4 years ago ... squashfs+NFS was still slower, but not a lot slower
| |
| 06:20 | woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de) | |
| 06:22 | <alkisg> vagrantc: what was your test? A simple hdparm -t says "111 MB/sec vs 109", no real difference
| |
| 06:23 | gdi2k has joined IRC (gdi2k!~gdi2k@213.5.69.139) | |
| 06:23 | <vagrantc> alkisg: probably dd if=/somefile of=/dev/null
| |
| 06:23 | hdparm sounds more interesting.
| |
| 06:23 | <alkisg> Let me try the file system overhead, a tar /usr...
| |
| 06:26 | Heh. `du -sh imgroot` => 5 secs on nfs, 7 on nbd
| |
| 06:26 | <vagrantc> after repeated tests?
| |
| 06:29 | gdi2k has left IRC (gdi2k!~gdi2k@213.5.69.139, Ping timeout: 246 seconds) | |
| 06:29 | <alkisg> Yes, and with dropping caches on the client
| |
| 06:30 | Let me find a good tar > /dev/null command...
| |
| 06:30 | <vagrantc> now yank the ethernet for a while and see which can recover :)
| |
| 06:33 | <alkisg> tar nfs: 7 sec, tar nbd: 8s
| |
| 06:33 | (around 4 gb root file system)
| |
| 06:33 | repeating...
| |
| 06:34 | Heh, server-side caching benefits nfs more; now it's 6.7 vs 8.6
| |
| 06:34 | Heh. I don't see a downside to using nfs there :D
| |
| 06:34 | Yanking the cable...
| |
| 06:34 | <vagrantc> so we could have skipped this whole NBD thing if we had just thought to try that years ago
| |
| 06:34 | <alkisg> (btw, nbd appears to become more and more unreliable in recent versions)
| |
| 06:35 | <vagrantc> i only tried it in desperation when overlay fs stopped working with NFS
| |
| 06:36 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:36 | <alkisg> I'll set up my development environment like this then: exporting /home/virtualbox-vms over nfs, letting initramfs-tools mount all that over nfs, then the ltsp code to losetup/mount the appropriate vm partition as /root
| |
| 06:36 | No more "configure nbd" code :D
| |
| 06:36 | We lose swap; but that was unreliable too
| |
| 06:36 | I can replace it with local swap here when needed; maybe people won't miss it much
| |
| 06:38 | <fiesh> hmm yeah we have no swap either... sometimes I wish we did, OOM situations suck so hard lately under linux
| |
| 06:38 | oftentimes actually crashes your operating system, sometimes SysReq+f helps
| |
| 06:39 | and with only 16GB of ram in the clients and YouCompleteMe being written in Python and thus gobbling resources like they grow on trees, OOM is inevitable :/
| |
| 06:39 | <alkisg> Ah, restarting the *services* on the server should be a much better test than just removing the cable
| |
| 06:39 | fiesh: I'll try to make the user session run with higher oom score; that would at least crash the session and allow you to read the logs, instead of crashing the system,
| |
| 06:40 | and, i'll explore defaulting to zram caching when the client has ram > some threshold
| |
| 06:41 | yanking the cable, dropping caches, doing "ls dir"
| |
| 06:41 | nbd: read error after a few secs
| |
| 06:41 | nfs: just waited; worked after reconnecting
| |
| 06:42 | <fiesh> wow cool with nbd
| |
| 06:42 | zram sounds interesting!
| |
| 06:43 | <alkisg> restarting nbd-server and nfs-server:
| |
| 06:43 | (and dropping caches and running ls)
| |
| 06:44 | nbd: showing a few cached dirs; complaining about ioerrors on others; didn't reconnect
| |
| 06:44 | <fiesh> :/
| |
| 06:44 | <alkisg> nfs: ...everything fine
| |
| 06:44 | <fiesh> yeah nfs is resilient, nbd not so much sometimes
| |
| 06:45 | <alkisg> vagrantc: I haven't tested nfs a lot. In a few cases, I couldn't unmount dirs on the server until I stopped the nfs-kernel-server service, even though the clients were powered off, possibly because the nfs service was keeping state in case the clients wanted to reconnect,
| |
| 06:46 | my question: can nfs be annoying for root file system sharing? any gotchas that I haven't yet seen?
| |
| 06:46 | It seems like we should switch the defaults to this one...
| |
| 06:46 | gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28) | |
| 06:47 | <alkisg> fiesh: what you're reporting are for gentoo, right?
| |
| 06:47 | <fiesh> yes
| |
| 06:47 | <alkisg> OK great, same observations apply here in ubuntu
| |
| 06:47 | <fiesh> :)
| |
| 06:48 | I don't think that LTSP performs worse under OOM than other installations though btw. OOM has just become really awful under Linux I think
| |
| 06:48 | no idea why the defaults are so bad for OOM, you'd think it's a bug if using up all ram can bring down your system...
| |
| 06:48 | <alkisg> fiesh: indeed, but still, distros should be setting oom score, and they don't
| |
| 06:49 | I do want to bring this up with some distro at some point, when I have plenty of free time to fight it :D
| |
| 06:49 | <fiesh> haha
| |
| 06:49 | <alkisg> At least bring xorg/wayland down, not "any process"...
| |
| 06:50 | <vagrantc> it's pretty much "whichever process happened to push it too far" by default, no?
| |
| 06:50 | <alkisg> I think so, but I wonder why the system crashes instead of killing firefox/chrome then
| |
| 06:51 | Something is definitely going wrong there
| |
| 06:51 | vagrantc: I'm thinking that I should file a bug report on nbd github that summarizes all that, and concludes with "so ltsp is going to switch to nfs again, unless nbd can become more resilient"; does it sound too harsh?
| |
| 06:52 | <vagrantc> alkisg: i'm not sure it's really actionable that way ... e.g. filing specific bugs about specific issues is one thing
| |
| 06:52 | <fiesh> no I don't think it's "whichever process happened to push it too far"
| |
| 06:52 | <vagrantc> alkisg: but saying you'll switch to a different backend if things don't shape up
| |
| 06:52 | <fiesh> the linux oom killer generates this score for all processes
| |
| 06:52 | <alkisg> Sure, "unplug the network and it produces errors instead of stalling io" is very specific
| |
| 06:53 | <fiesh> and kills the highest scoring
| |
| 06:53 | which *should* involve memory consumption as well as probably other factors, maybe even user before root, not sure
| |
| 06:53 | but clearly it doesn't really work that well
| |
| 06:53 | <vagrantc> alkisg: i'm just not sure it's worth the "we'll switch if you don't fix this" angle
| |
| 06:53 | <alkisg> Gotcha; I'll just mention the bugs then
| |
| 06:54 | fiesh: indeed; so we'd need to set up specific test cases where it misbehaves, to convince them there's a bug there
| |
| 06:54 | The kernel lists aren't a nice place if one doesn't do his homework first :P
| |
| 06:55 | <fiesh> hah no indeed
| |
| 06:55 | they could learn a thing or two from #ltsp on freenode ;P
| |
| 06:56 | <alkisg> Haha, maybe if we had their bug reports we'd learn from them.. it's a lot quieter here :D
| |
| 06:57 | <fiesh> hehe sounds about right
| |
| 06:58 | * alkisg switches his next goal to "setting up my environment to VMs over NFS instead of over NBD which I currently use" | |
| 07:15 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 07:15 | <fiesh> hmm our NBD system runs fairly smoothly now to be honest -- of course when the server goes down, all the clients are done for, but I can live with that, and I know not to delete files that the nbd daemon still uses for clients
| |
| 07:18 | <alkisg> fiesh: well, if nfs only has benefits and no drawbacks, it wouldn't give you any trouble switching over,
| |
| 07:18 | also, you can delete nbd server files, and they will be actually removed when the last client disconnects,
| |
| 07:18 | it's a linux kernel feature, to "hide" the deleted files that are still in use, and to actually remove them when they're closed
| |
| 07:21 | <fiesh> heh it's been this way in every UNIX ever since, I know ;)
| |
| 07:21 | but somehow nbd can go into funky mode for unknown reasons
| |
| 07:21 | <alkisg> Really? Oh my yet another issue :D
| |
| 07:22 | <fiesh> giving clients huge lag -- I think it probably tries to do some fstat or so the files and fails over and over... but never bothered to investigate
| |
| 07:22 | well nbd does seem to provide better performance!
| |
| 07:22 | <alkisg> Than what, squashfs over nfs?
| |
| 07:22 | My tests now say the opposite
| |
| 07:23 | <fiesh> oh squashfs over nfs! I see!
| |
| 07:23 | not just native nfs
| |
| 07:23 | <alkisg> :)
| |
| 07:23 | Right
| |
| 07:23 | <fiesh> yeah that sounds like a nice solution
| |
| 07:23 | <alkisg> Native nfs is very slow
| |
| 07:23 | <fiesh> yeah
| |
| 07:24 | <alkisg> So all my tests above ^ were for squashfs over nfs, and I didn't see any single benefit for nbd
| |
| 07:24 | <fiesh> and by no benefit you mean no disadvantage to? ;)
| |
| 07:24 | oh for
| |
| 07:24 | not over
| |
| 07:24 | hehe
| |
| 07:24 | yeah that sounds totally reasonable
| |
| 07:24 | <alkisg> Hopefully my english didn't fail me there :D
| |
| 07:25 | And there's no need to configure separate exports in the nfs case
| |
| 07:25 | Whereas in nbd, for every new export, we need to restart the server, losing all clients!
| |
| 07:25 | <fiesh> no you can just serve a directory with the images in it I guess, that's really great
| |
| 07:25 | <alkisg> I'll try to support 3 cases:
| |
| 07:26 | an nfs base dir with: VMs (with partitions), squashfs files (produced by ltsp-update-image), and even plain chroots
| |
| 07:26 | If we can boot all these with simple ltsp parameters, it's great
| |
| 07:31 | Yey, my loop attempts were failing because the busybox mount utility is too stupid to modprobe squashfs and ext4; easy to fix
| |
| 07:41 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 07:46 | <fiesh> these 3 cases would cover basically anything I think
| |
| 08:04 | <alkisg> Damn, silly last block for directly using VMs: the initramfs `mount` doesn't support `offset`, and `losetup` doesn't probe for partitions, and `partprobe` isn't available, and `blockdev --rereadpt` doesn't work with loop devices, and `echo 1 > /sys/block/sdc/device/rescan` isn't there for loop devices...
| |
| 08:04 | Damn one small partprobe away and I can't find how to bypass it! :D
| |
| 08:13 | statler has joined IRC (statler!~Georg@gwrz.lohn24.de) | |
| 08:31 | GodFather_ has left IRC (GodFather_!~rcc@143.59.184.72, Ping timeout: 245 seconds) | |
| 08:31 | GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 246 seconds) | |
| 08:34 | woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 09:00 | <alkisg> Yey, proper workaround found! :)
| |
| 09:00 | Sun is shining again. Oh, only inside the pc; it rains outside.
| |
| 10:19 | Heh
| |
| 10:19 | Squashfs over NFS seems to work so much better than NBD
| |
| 10:20 | Does anyone want a quick how to, to test it in production, and report back?
| |
| 10:20 | (schools are closing for the year here; can't test widely...)
| |
| 10:23 | ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75) | |
| 10:28 | <fiesh> alas we're too busy these days to test this right now, otherwise I'd love to...
| |
| 10:35 | <highvoltage> 0/win 32
| |
| 10:40 | GodFather_ has joined IRC (GodFather_!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 10:40 | GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net) | |
| 10:44 | os_a has joined IRC (os_a!~Thunderbi@195.112.116.22) | |
| 10:47 | os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Client Quit) | |
| 10:53 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 12:16 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:26 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection) | |
| 12:34 | Faith has joined IRC (Faith!~Paty_@143.107.231.49) | |
| 12:34 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:34 | <mwalters> alkisg: I'm interested ;)
| |
| 12:35 | have clients actively connected at the moment, though
| |
| 12:38 | <alkisg> I don't expect any disruption to connected clients; but I left from work and tomorrow I'll visit a school, so I'll have a lot of time for this on Thursday
| |
| 12:45 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 257 seconds) | |
| 12:45 | kjackal has joined IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr) | |
| 12:45 | <mwalters> cool... my users would looove anything that improves fat client performance
| |
| 13:27 | <Hyperbyte> alkisg, I could test it, sure. :-)
| |
| 13:29 | <mwalters> "Just use ldap they said"
| |
| 13:29 | "That's what it's for they said"
| |
| 13:29 | ....aaaand now I'm setting up dns and zone transfering and and and ... :|
| |
| 14:00 | <Hyperbyte> I assume you don't get paid hourly? :-)
| |
| 14:02 | <mwalters> :(
| |
| 14:07 | kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 252 seconds) | |
| 14:08 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b) | |
| 14:31 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Quit: Leaving) | |
| 15:02 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 15:27 | <jeblesh_> oky dide systemctl stop firewalld.service and the pxe boot works dhcp ssh nfs+nfs3 tftp are open to public whot m i missing ? :s
| |
| 15:42 | GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 246 seconds) | |
| 15:42 | GodFather_ has left IRC (GodFather_!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 252 seconds) | |
| 15:44 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 15:54 | <alkisg> vagrantc: debian buster vm, without nbd-client, without a custom initramfs, boots just fine over nfs+loop device (ext4), without squashfs, after fighting with a few quirks
| |
| 15:54 | All my benchmarks show that method to be faster than nbd. go figure. :)
| |
| 15:56 | And if we point tftp to /srv/ltsp, then we can have /srv/ltsp/vm for both old-style-nfs and tftp, like you used to do in the past
| |
| 15:57 | And /srv/ltsp/vm/vm.raw for disk-based images, and finally /srv/ltsp/images/vm.img for squashfs ones. 3 methods supported, all over nfs.
| |
| 16:01 | <vagrantc> sounds nice :)
| |
| 16:01 | by old-style NFS, are you meaning without the loopback device?
| |
| 16:04 | <alkisg> Yes, plain chroot without a squashfs loopback device
| |
| 16:04 | vagrantc: where exactly did you point tftp? To /opt/ltsp?
| |
| 16:04 | Or to /opt/ltsp/image/boot?
| |
| 16:05 | <vagrantc> alkisg: /var/lib/lessdisks ... it predated my ltsp days :)
| |
| 16:05 | <alkisg> vagrantc: so it needed a subpath like $TFTP/image/boot/kernel, right?
| |
| 16:05 | <vagrantc> something like that, yeah
| |
| 16:07 | <alkisg> I'm trying to figure out if putting everything under /srv/ltsp actually helps users in organization, or if it messes with some use cases like both chroots and squashfs images...
| |
| 16:08 | Oh well let's make it easier for 90% of the use cases, and hope the rest 10% can read the wiki for advanced tricks
| |
| 16:11 | <vagrantc> there may be cases where someone would still need something like ltsp-update-kernels to copy the files to a separate tftp dir if it's not possible to move for some reason
| |
| 16:11 | <alkisg> vagrantc: what ships /etc/kernel-img.conf in debian?
| |
| 16:12 | <vagrantc> alkisg: nothing ships it
| |
| 16:12 | alkisg: it's generated, if present at all
| |
| 16:12 | <alkisg> I see some handy /vmlinuz and /initrd.img symlinks, that can be used for tftp in most debian/ubuntu versions, but I think I heard something about moving them to /boot instead, which would break things
| |
| 16:12 | <vagrantc> the manpage for it is in linux-base
| |
| 16:13 | alkisg: the unversioned links are deprecated in debian and might disappear
| |
| 16:13 | though it's been that way for years...
| |
| 16:14 | <alkisg> We wouldn't rely on them; but if someone wanted to maintain old-nfs-style chroots AND have tftp at the same location, it would make things automatic for him
| |
| 16:14 | Normal users would run ltsp-update-kernels, yeah
| |
| 16:14 | I already have code for that that reads the most recent kernel/initrd from inside images for most distros
| |
| 16:14 | (fedora, gentoo, raspbian etc)
| |
| 16:16 | <vagrantc> looks like it may not be deprecated anymore ... huh.
| |
| 16:17 | maybe they tried to deprecate it and there was a revolt or something
| |
| 16:17 | <alkisg> Great, finally a revolution that actually helped helps us :)
| |
| 16:18 | That would mean that we won't have an "ltsp" dir under tftp anymore
| |
| 16:31 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.180.185) | |
| 16:33 | adrianorg has left IRC (adrianorg!~adrianorg@179.187.31.252.dynamic.adsl.gvt.net.br, Ping timeout: 255 seconds) | |
| 16:46 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 258 seconds) | |
| 17:55 | GodFather has joined IRC (GodFather!~rcc@143.59.184.72) | |
| 17:55 | GodFather_ has joined IRC (GodFather_!~rcc@143.59.184.72) | |
| 17:58 | woernie has joined IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de) | |
| 18:04 | <josefig> I'm trying to implement a script to know how much time the ltsp client is idle. When I activate the screensaver i cannot unlock the pc, it says incorrect password. Why would this be ?
| |
| 18:12 | <alkisg> !hash
| |
| 18:12 | <ltsp> I do not know about 'hash', but I do know about these similar topics: 'LDM_PASSWORD_HASH', 'ROOT_PASSWORD_HASH'
| |
| 18:13 | <alkisg> !LDM_PASSWORD_HASH
| |
| 18:13 | <ltsp> LDM_PASSWORD_HASH: LDM_PASSWORD_HASH=True in lts.conf saves the password hash to /etc/shadow on login, so that the users can unlock the screensaver etc. If they happen to change their password though, that only takes effect until logout.
| |
| 18:13 | <alkisg> josefig: use this ^
| |
| 18:13 | <josefig> i see, because of the pam authentication right ?
| |
| 18:14 | <alkisg> Because ltsp does not have pam authentication, yes
| |
| 18:14 | <josefig> I'm starting to understand how it works ltsp
| |
| 18:14 | thanks for the tip
| |
| 19:17 | statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection) | |
| 19:20 | jeblesh_ has left IRC (jeblesh_!2e78d540@gateway/web/freenode/ip.46.120.213.64, Ping timeout: 256 seconds) | |
| 19:40 | woernie has left IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 19:49 | <uumas> alkisg: Oh, unlocking from screensaver isn't supposed to work without that?
| |
| 19:49 | Because it's always worked for me
| |
| 19:50 | <mwalters> it'll work on thinclients, but not fatclients
| |
| 19:50 | <uumas> Well, I have fat clients...
| |
| 19:51 | <vagrantc> you've certainly done some changes to the default setup then
| |
| 19:51 | <uumas> I never even thought of that, but now that I think about it, it definitely shouldn't work
| |
| 19:51 | <mwalters> such as putting that line into lts.conf ;)
| |
| 19:52 | <vagrantc> maybe you've changed pam to allow any password for the screensaver unlock ... that would also work :)
| |
| 19:52 | <mwalters> or maybe you have a populated passwd and shadow file in a chroot?
| |
| 19:53 | <vagrantc> all LDM_PASSWORD_HASH does is populates /etc/shadow with the hashed password you successfully authenticated to the server with
| |
| 19:54 | <uumas> Ah, I got it. I use ldap for authentication and because it's a chrootless setup the ldap auth config is also on the client squashfs image so they authenticate directly to the ldap server.
| |
| 19:54 | <mwalters> a winrar
| |
| 19:55 | <uumas> Hmm?
| |
| 19:55 | <mwalters> an internet colloquialism for "a winner"
| |
| 19:55 | <uumas> k
| |
| 19:56 | <mwalters> now you've peaked my interest, though... doesn't that cause issues w/ computer accounts?
| |
| 19:57 | <uumas> computer accounts?
| |
| 19:57 | <mwalters> maybe not all of ldap depends on them
| |
| 19:57 | jeblesh has joined IRC (jeblesh!2e78d540@gateway/web/freenode/ip.46.120.213.64) | |
| 19:57 | <mwalters> AD/FreeIPA have the concept of computer objects within the directory
| |
| 19:57 | and generally won't auth for a computer that doesn't have one
| |
| 19:58 | with the fat clients being ephemeral, I figured it'd cause issues
| |
| 19:58 | (e.g., denying the auth request from the screensaver outright)
| |
| 19:58 | <uumas> Ah, hosts, yeah. I use plain OpenLDAP without host information (for now)
| |
| 19:58 | <mwalters> oic
| |
| 19:59 | I came from AD, they were "computer accounts"... hosts sounds more accurate ;)
| |
| 19:59 | <uumas> I'll be switching to FreeIPA in the summer though, so I'll have to see how that will work
| |
| 19:59 | <jeblesh> hi all my firewalld on ubuntu desktop 18.0.4 is blocking LTSP, what port's shold it open in order for it to worck with the firewalld up and runing ?
| |
| 20:00 | <mwalters> I just set up freeipa here... have 3 out of 4 ltsp servers hooked up to it so far
| |
| 20:00 | jeblesh: probably ssh and tftp at least
| |
| 20:00 | I guess nbd too... then whatever other services you're using
| |
| 20:00 | <jeblesh> enabled on public zone ... but no go ...
| |
| 20:01 | <mwalters> I'm not sure what that means, you're not just using ufw?
| |
| 20:01 | oh, are you doing the 2 nic setup?
| |
| 20:01 | <uumas> Sounds like fedora/rhel/centos firewalld to me
| |
| 20:02 | <jeblesh> its a desktop instolation it comes with firewall-config gui app thingy :P
| |
| 20:02 | <mwalters> yeah, ubuntu 18.04 would use ufw out of the box
| |
| 20:02 | oh, no idea how to use that ;)
| |
| 20:03 | <uumas> I mean firewalld, which is the default on rhel. I remember having to deal with zones using that
| |
| 20:03 | But could be something else
| |
| 20:03 | <jeblesh> yes .. but i set avry thing on public zone so it shold mean nothing ...
| |
| 20:03 | <mwalters> dunno about recent fedorah or rhel... centos7 seems to use firewall-cmd now
| |
| 20:04 | which seems pretty straightforward
| |
| 20:04 | <jeblesh> firewall-cmd is firewalld front end comand lime ...
| |
| 20:04 | <mwalters> `firewall-cmd --add-port=123/tcp --permanent`
| |
| 20:04 | that'd explain it
| |
| 20:04 | do you need the firewall active even?
| |
| 20:04 | at least for sanity checking you could disable it to make sure
| |
| 20:05 | <jeblesh> humm honestly not realy
| |
| 20:05 | <mwalters> to make sure that's what is causing the issues*
| |
| 20:05 | <jeblesh> i systemctl stop firewalld and the PXE boot works fine ...
| |
| 20:06 | <uumas> jebelesh: If you want to see what's the problem run 'netstat -tulpn' on the ltsp server to see which ports each service uses, then check with 'nmap <ltsp server ip> -p <port>' for all needed services from another pc in the same network
| |
| 20:08 | <mwalters> reasonably certain you'd see messages in syslog too
| |
| 20:08 | or some log
| |
| 20:09 | <jeblesh> is ther a way to get a log of conection denaies from firewalld and do it that way ?
| |
| 20:10 | <uumas> https://unix.stackexchange.com/questions/114734/can-logging-be-enabled-in-firewalld
| |
| 20:10 | This is for fedora but should be similar
| |
| 20:12 | <jeblesh> awsome thenx
| |
| 20:16 | lol "019-05-14 23:14:54 ERROR: Invalid option definition: 'FIREWALLD_ARGS=--debug=10'" that's one way that dosent worck ... S:
| |
| 20:22 | jeblesh has left IRC (jeblesh!2e78d540@gateway/web/freenode/ip.46.120.213.64, Ping timeout: 256 seconds) | |
| 21:04 | <josefig> is it usual that the path /var/log is shared by all ltsp clients ?
| |
| 21:06 | <quinox> I only share /home/ between my fat clients
| |
| 21:06 | <vagrantc> josefig: how do you mean shared?
| |
| 21:07 | josefig: they may share the same initial state of the directory, but over time they diverge, until you reboot where it resets.
| |
| 21:07 | <josefig> share the folder like quinox said, I shared /home among the fat clients, but I want to get some logs like syslog for example
| |
| 21:08 | <vagrantc> definitely do not share /var/log from the server
| |
| 21:08 | <josefig> i think i know what to do
| |
| 21:08 | some logger path setting
| |
| 21:08 | <vagrantc> configure your server to do remote syslogging
| |
| 21:09 | then you'll get logs for all the clients and you can configure the log server to store the logs however you want
| |
| 21:09 | <josefig> yes, that can be an option.
| |
| 21:10 | <vagrantc> there's even an option to turn it on client-side
| |
| 21:11 | it was a one-line configuration option for rsyslog to enable, if i remember correctly
| |
| 21:16 | <josefig> hum on lts.conf ?
| |
| 21:16 | i found it
| |
| 21:17 | thanks vagrantc
| |
| 21:19 | <vagrantc> there's also server-side configuration needed
| |
| 21:20 | <josefig> yes, you mean on syslog-ng right ?
| |
| 21:20 | http://wiki.ltsp.org/wiki/Troubleshooting#Syslog
| |
| 21:53 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |
| 22:16 | <vagrantc> i last used rsyslog, but you're welcome to use whatever syslog you want
| |
| 22:22 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds) | |
| 22:31 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 23:20 | gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Quit: Leaving) | |