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


Channel log from 14 May 2019   (all times are UTC)

05:05pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
05:18kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)
05:26woernie has joined IRC (woernie!~werner@p5B296A22.dip0.t-ipconnect.de)
05:40woernie 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:54kjackal 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:56kjackal 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:10gdi2k 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:20woernie 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:23gdi2k 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:29gdi2k 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:36ricotz 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:46gdi2k 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:15vagrantc 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:41SYS64738 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:13statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
08:31GodFather_ has left IRC (GodFather_!~rcc@143.59.184.72, Ping timeout: 245 seconds)
08:31GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 246 seconds)
08:34woernie 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:23ZAJDAN 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:40GodFather_ has joined IRC (GodFather_!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
10:40GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
10:44os_a has joined IRC (os_a!~Thunderbi@195.112.116.22)
10:47os_a has left IRC (os_a!~Thunderbi@195.112.116.22, Client Quit)
10:53pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
12:16Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:26Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Remote host closed the connection)
12:34Faith has joined IRC (Faith!~Paty_@143.107.231.49)
12:34Faith 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:45kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 257 seconds)
12:45kjackal 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:07kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 252 seconds)
14:08kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)
14:31SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Quit: Leaving)
15:02SYS64738 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:42GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 246 seconds)
15:42GodFather_ has left IRC (GodFather_!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 252 seconds)
15:44vagrantc 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:31adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.180.185)
16:33adrianorg has left IRC (adrianorg!~adrianorg@179.187.31.252.dynamic.adsl.gvt.net.br, Ping timeout: 255 seconds)
16:46SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
17:55GodFather has joined IRC (GodFather!~rcc@143.59.184.72)
17:55GodFather_ has joined IRC (GodFather_!~rcc@143.59.184.72)
17:58woernie 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:17statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
19:20jeblesh_ has left IRC (jeblesh_!2e78d540@gateway/web/freenode/ip.46.120.213.64, Ping timeout: 256 seconds)
19:40woernie 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:57jeblesh 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:22jeblesh 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:53ricotz 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:22kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds)
22:31Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
23:20gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, Quit: Leaving)