IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 18 May 2019 (all times are UTC)
| 01:17 | eu^20386213250 has joined IRC (eu^20386213250!cb56d5fa@203.86.213.250) | |
| 01:18 | <eu^20386213250> I have a question
| |
| 01:19 | eu^20386213250 has left IRC (eu^20386213250!cb56d5fa@203.86.213.250, Remote host closed the connection) | |
| 01:30 | <vagrantc> i, too, have questions.
| |
| 03:17 | <alkisg> Me too! vagrantc: I implemented a "must" function, which means "run a command, and if it doesn't work, display the command, and offer a troubleshooting shell, and don't continue execution until the specified command returns true".
| |
| 03:17 | Example use: must cd dir; must cp a b; must my_function; https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/ltsp.sh#L113
| |
| 03:17 | Question: ...read the mount_dir and mount_file functions there: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/ltsp.sh#L182
| |
| 03:17 | They use the must function a lot. It's really great for debugging! But... is the code READABLE like this?
| |
| 03:19 | Oh mispasted the URLs, the second one is the must() implementatino, and the first one is the mount_dir/mount_file functions.
| |
| 03:36 | <vagrantc> alkisg: i can see how it would be useful when debugging, but a bit of a security problem if someone's presented with a root shell in a live deployment
| |
| 03:37 | <alkisg> Ah true; so we should only enable the shell when a parameter is passed on the cmdline or so?
| |
| 03:38 | Or the opposite, to lock it when someone wants a more secure enviroment? E.g. again from cmdline or lts.conf?
| |
| 03:38 | <vagrantc> failure modes should be secure by default
| |
| 03:40 | <alkisg> vagrantc: although... if one unplugs the ethernet cable, he gets a root shell anyway
| |
| 03:40 | By the panic function of initramfs tools
| |
| 03:40 | <vagrantc> because if your "make me secure" flag fails to work correctly...
| |
| 03:41 | there are lots of ways to compromise security, it doesn't mean to ignore best practices
| |
| 03:41 | <alkisg> We do lose this ability though: oh this rare issue occurred, how can I get debug information now that I didn't have "ltsp.allow_debug=true"...
| |
| 03:42 | <vagrantc> it's true
| |
| 03:43 | <alkisg> vagrantc: how about requiring a password, recorded somewhere on the server?
| |
| 03:44 | E.g. ltsp-mkinitrd creates an md5sum to be used for password checking,
| |
| 03:44 | and stores the plaintext password in an unreadable location on the server
| |
| 03:44 | So at least we can tell the user "if you have root on the server, your password is there"
| |
| 03:44 | <vagrantc> sounds like a built-in backdoor
| |
| 03:44 | <alkisg> How so? Even booting encrypted disks does that
| |
| 03:45 | Do you mean the "ask password" bit, or the "store password" bit?
| |
| 03:49 | <vagrantc> a bit of both
| |
| 03:49 | <alkisg> Hmm btw, the normal is to allow root on non-ltsp clients, by just pressing "e" on grub and typing "init=/bin/bash"
| |
| 03:50 | If users want to lock down that, they need to explicitly disable grub cmdline editing
| |
| 03:50 | So up to the part where the image is public (initrd, squashfs, up to ldm) maybe we can default to debug_shell=true
| |
| 03:51 | And if someone needs to lock it down, he can do so from /proc/cmdline
| |
| 03:51 | (or lts.conf)
| |
| 03:51 | <vagrantc> i don't know how you'll convince me this is a good idea
| |
| 03:52 | <alkisg> I think I found a good example where distros default to what I prefer too :)
| |
| 03:52 | I don't think I can convince you, but I think we can default to that until enough users say the opposite
| |
| 03:53 | I'm sure if you had control over grub defaults, you wouldn't do it the way it's done now...
| |
| 03:53 | <vagrantc> in debian the initramfs no longer defaults to giving access to a shell on failure
| |
| 03:54 | * alkisg tests that... | |
| 03:54 | <vagrantc> obviously, you can pass it any init= you want
| |
| 03:55 | <alkisg> No that's a good argument, if initramfs-tools doesn't show a root shell on panic, you'll convince me
| |
| 03:56 | <vagrantc> not without a password
| |
| 03:56 | <alkisg> I don't think the initramfs supports password handling
| |
| 03:56 | <vagrantc> right
| |
| 03:57 | <alkisg> Meh in my installation the only things that call "panic" are ltsp scripts and cryptroot
| |
| 03:57 | Ah ok and init, when it doesn't find /sbin/init, testing...
| |
| 03:59 | vagrantc: buster-gnome did call panic and drop to the initramfs shell, without any ltsp code involved
| |
| 03:59 | <vagrantc> huh.
| |
| 03:59 | i was pleasantly surprised to see the more secure behavior, but who knows what enabled it
| |
| 04:00 | maybe specifying panic=SECONDS or something
| |
| 04:00 | <alkisg> Was it in initramfs/panic? Or are you talking about later on, when root is mounted?
| |
| 04:00 | *after pivot_root?
| |
| 04:00 | <vagrantc> quite possibly
| |
| 04:01 | <alkisg> At that point I can make "debug_shell" invoke a "login"; and if he has a root password there, he can use it
| |
| 04:02 | Anyway security was a good point I'll think about it more. How about code readability, is it ok in that regard?
| |
| 04:03 | Oh my. login is available in the initramfs, maybe we can use it.
| |
| 04:04 | Oh it's busybox login
| |
| 04:04 | <vagrantc> so what password would it make available?
| |
| 04:04 | <alkisg> It has an /etc/passwd with a single root user, no /etc/shadow,
| |
| 04:05 | <vagrantc> does it auto-generate it and store it somewhere?
| |
| 04:05 | <alkisg> presumably we could use a sha* shadow entry and make it work,
| |
| 04:05 | and maybe we'll even be able to block ctrl+c there :P
| |
| 04:05 | <vagrantc> exec login should work
| |
| 04:06 | unless it just loops infinitely
| |
| 04:06 | <alkisg> True, it should work
| |
| 04:07 | <vagrantc> any stored password available over clear-text network protocols is going to be eminently brute-forceable
| |
| 04:07 | even if it's hashed
| |
| 04:07 | <alkisg> But isn't that how disks are encrypted? With a hash?
| |
| 04:08 | <vagrantc> good encryption uses much more sophisticated methods than a simple one-way hash function
| |
| 04:09 | but a hashed password entry in /etc/passwd sent over the network is not going to be all that good
| |
| 04:11 | <alkisg> I think that people that care so much about security, can create encrypted VMs, and send all that encrypted disk over the nework with ltsp
| |
| 04:11 | So that users will need to type the encryption password to boot
| |
| 04:11 | But I don't think our users will appreciate that to be the default
| |
| 04:12 | <vagrantc> hopefully most users will never need it, in which case it shouldn't be the default :P
| |
| 04:12 | <alkisg> Anyways, I'll see what we can do about security in the last stages; it's not like ltsp5 blocks "panic" or erases shadow/root md5sums now
| |
| 04:13 | <vagrantc> one of the most important aspects about security isn't "does this particular person want security" but "security doesn't work if people have to think about it and opt in"
| |
| 04:13 | <alkisg> I don't want to design a state-of-the art bash-based security-aware application; I wouldn't even be using bash for that :)
| |
| 04:14 | If it's better than what we do now, it's good enough as a starting point; sometimes aiming too high makes no work done
| |
| 04:15 | <vagrantc> ltsp in fedora defaulted to having root shells on all the extra consoles for a while to make life easier on users
| |
| 04:15 | eventually that security issue was fixed
| |
| 04:18 | <alkisg> I think I feel well enough with not allowing a shell without a password, even if that password is just an autogenerated one, stored on the server, sent over the network with a simple hash
| |
| 04:18 | We'll see if it's opt in or opt out
| |
| 04:22 | !hash
| |
| 04:22 | <ltsp> I do not know about 'hash', but I do know about these similar topics: 'LDM_PASSWORD_HASH', 'ROOT_PASSWORD_HASH'
| |
| 04:22 | <alkisg> !ROOT_PASSWORD_HASH
| |
| 04:22 | <ltsp> ROOT_PASSWORD_HASH: To be able to login as root in vt1, with password "qwer1234", put this in lts.conf: INIT_COMMAND_ROOT_HASH="sed 's!^root:[^:]*:!root:\$6\$p2LdWE6j\$PDd1TUzGvvIkj9SE8wbw1gA/MD66tHHlStqi1.qyv860oK47UnKcafSKqGp7cbgZUPlgyPv6giCVyCSCdJt1b0:!' -i /etc/shadow"
| |
| 04:23 | <alkisg> Maybe something like that, that will also work with login in initramfs
| |
| 04:23 | And opt-in
| |
| 04:23 | <vagrantc> setting a password enables the feature or something
| |
| 04:23 | <alkisg> Right
| |
| 04:24 | <vagrantc> as long as the password is not set by default, sure :)
| |
| 04:25 | <alkisg> The problem is basically in the initramfs; later on, debug_shell can be "repeat y/n", without giving a shell, and expecting the user to switch to another terminal/vt/whatever to troubleshoot, then press y to repeat
| |
| 04:26 | Hmmm indeed, the need for login won't be as frequently needed as I thought, since they'll be able to use alternate terminals/vts
| |
| 04:27 | E.g. if screen_02=ldm gets an issue, it can just block with "repeat y/n", and wait for the user to resolve the issue via epoptes
| |
| 04:27 | <vagrantc> there we go
| |
| 04:28 | <alkisg> The most precious part there isn't the login itself, but the fact that it blocks at the exact point of the problem, displaying the exact command that caused it
| |
| 04:30 | <vagrantc> i vaguely recall there being a syslog implementation in busybox, too
| |
| 04:30 | so if you at least had networking, you could do simple syslog messages
| |
| 04:31 | <alkisg> Eh, we can just print to stderr and block with repeat y/n, networking isn't that important
| |
| 04:31 | The sysadmin will need local access, but I don't mind about that
| |
| 04:31 | If he wants to enable netconsole, sure, it's up to him
| |
| 04:32 | <vagrantc> sounds good to me
| |
| 04:32 | <alkisg> As always, thanks for the advice!
| |
| 04:32 | <vagrantc> why "must" ...
| |
| 04:32 | <alkisg> Oh just the first thing that came to mind
| |
| 04:33 | Please propose better ones
| |
| 04:33 | <vagrantc> this
| |
| 04:33 | <alkisg> "req" for require?
| |
| 04:33 | <vagrantc> "must" succeed or...
| |
| 04:34 | it might get tripped up with quoting issues for arbitrary commands ...
| |
| 04:34 | <alkisg> Yes, that was the idea. This command must be executed; don't continue without it
| |
| 04:34 | <vagrantc> shell isn't very good at sanitizing argument inputs...
| |
| 04:34 | but as long as we don
| |
| 04:34 | <alkisg> It doesn't use eval, so I don't expect it to trip. Any specific cases where it would?
| |
| 04:34 | <vagrantc> t use it for every single command, it should be fine
| |
| 04:35 | <alkisg> "$@" should work with any quoting done
| |
| 04:35 | As it contains the value, not the source
| |
| 04:37 | <vagrantc> i suspect we won't be using it for overly complicated cases
| |
| 04:37 | <alkisg> I have "set -e" enabled
| |
| 04:37 | Which means that if any command fails, a "err trap" is executed, and the script stops anyway
| |
| 04:38 | To avoid that, all commands that might fail, need either "|| true", or "must"
| |
| 04:39 | <vagrantc> right
| |
| 04:39 | <alkisg> So, I expect to use "must" in almost all the commands that might fail...
| |
| 04:39 | <vagrantc> i forgot you're upgrading to GPL-3+ :)
| |
| 04:40 | <alkisg> That's the "correct thing to do", isn't it?
| |
| 04:40 | <vagrantc> i think it's good
| |
| 04:42 | * vagrantc doesn't remember if vagrantc wrote boolean_is_true or not, but see's it's doubted if it will continue | |
| 04:52 | <alkisg> Yeah I was going to rewrite it, then I thought "oh wait to see if we need it first"
| |
| 04:59 | <vagrantc> alkisg: i've now glanced at the new code a bit, too :)
| |
| 04:59 | <alkisg> Haha, it's in brainstorming phase, don't glance too much :D
| |
| 05:00 | <vagrantc> i am in theory an informal co-mentor, no? :P
| |
| 05:00 | <alkisg> Indeed you are!
| |
| 05:00 | And the most precious one !
| |
| 05:00 | <vagrantc> aww.
| |
| 05:01 | <alkisg> I've rewritten most of the code 2-3 times already; and e.g. just now I switched it from focusing to nbd, to focusing to nfs; so I don't want to over-optimize before I'm sure about some of the implementation choices...
| |
| 05:02 | <vagrantc> sure
| |
| 05:03 | it overall looks a lot cleaner and less cluttered, fwiw
| |
| 05:04 | <alkisg> Yey
| |
| 05:04 | vagrantc: from buster busybox: modprobe netconsole=6665@192.168.1.28/eth0,6666@192.168.1.19/
| |
| 05:04 | server: nc -l -u 6666
| |
| 05:04 | ....and netconsole works fine :)
| |
| 05:05 | Opt in or opt out?
| |
| 05:05 | Maybe opt-in...
| |
| 05:06 | <vagrantc> nice!
| |
| 05:06 | <alkisg> OK let me cause a kernel panic and see if it's logged
| |
| 05:06 | [ 4063.199417] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
| |
| 05:06 | Yey it's the first time I'm able to copy/paste that!
| |
| 05:06 | * vagrantc uses serial consoles a lot, but netconsole is cool! | |
| 05:07 | <alkisg> vagrantc: how does serial console work? I tried to google it, then switched focus to netconsole
| |
| 05:07 | You have a usb to serial cable? And then what?
| |
| 05:07 | <vagrantc> plug into a serial port
| |
| 05:07 | most devboards have some pins you connect
| |
| 05:07 | <alkisg> Ah, not for PCs
| |
| 05:08 | <vagrantc> yeah
| |
| 05:08 | well, servers sometimes
| |
| 05:08 | <alkisg> OK, and then? It's a devboard serial to another devboard serial connection?
| |
| 05:08 | <vagrantc> and older PCs used to have serial ports
| |
| 05:08 | well, there's traditional 5v serial, and lower voltage serial-ttl ... but
| |
| 05:09 | most of the modern stuff is 3.3v or 1.8v
| |
| 05:09 | <alkisg> I mean, you're not using usb anywhere, just serial-to-serial, right?
| |
| 05:09 | <vagrantc> usually using usb to serial/serial-ttl adapters
| |
| 05:10 | which makes a /dev/ttyUSBN you can connect to
| |
| 05:10 | <alkisg> Gotcha. Yeah even if I get that, our users won't, so netconsole suits us better.
| |
| 05:10 | <vagrantc> e.g. "screen /dev/ttyUSB0 115200" flows pretty naturally for me :)
| |
| 05:11 | console=ttyS0,115200 are typical kernel arguments ... sometimes it's a different device like ttyAMA0 for some models of raspberry pi
| |
| 05:11 | <alkisg> So, design question: should it be: ltsp.netconsole=1 in cmdline and LTSP_NETCONSOLE=1 in lts.conf,
| |
| 05:11 | or should it be: INITRD_CMD_xx="netconsole 6665@$IP:6666@SERVER"?
| |
| 05:11 | the first one is more elegant; the second makes for MUCH smaller ltsp code
| |
| 05:11 | (and it will apply in many other parts too)
| |
| 05:12 | I.e. lts.conf can switch from directives to commands, to be executed at certain phases
| |
| 05:12 | <vagrantc> what about implementing it as ltsp.netconsole=1 and then it sets INITRD_CMD_NETCONSOLE ?
| |
| 05:13 | <alkisg> In this case we need to have the word "netconsole" in our code
| |
| 05:13 | <vagrantc> right
| |
| 05:13 | <alkisg> In the second case I mentioned, we don't
| |
| 05:14 | <vagrantc> honestly ... we've seen so many proliferated options over time that eventually got deprecated by something else ...
| |
| 05:14 | so i guess i'm leaning towards INITRD_CMD_xx="netconsole ..."
| |
| 05:14 | <alkisg> It will make our wiki more valuable then; to document all the things we can run, there
| |
| 05:15 | OK. So, I'll start with only the INIT_CMD, and if we see that it's bad, we can add the ltsp.vars later with no additional effort
| |
| 05:15 | <vagrantc> you could include commented examples like that in the default ltsp.conf or whatever
| |
| 05:16 | ltsp.initrd_cmd_xx="netconsole ..." would work, right?
| |
| 05:16 | <alkisg> If I manage to make a decent /proc/cmdline parser... both dracut and initramfs-tools don't handle spaces
| |
| 05:16 | <vagrantc> at least the old implementation ltsp.ANYTHING would just set ANYTHING
| |
| 05:16 | <alkisg> I think I can make it, at least for simple spaces without much quoting \$ etc
| |
| 05:17 | <vagrantc> ah, yeah, forgot that limitation
| |
| 05:17 | <alkisg> Btw if we take this example to the extremes, instead of X_MODE_0=xxx, we'd have:
| |
| 05:17 | DM_CMD_01="cat >/etc/X11/xorg.conf <<EOF
| |
| 05:17 | xorg contents here
| |
| 05:17 | EOF"
| |
| 05:18 | <vagrantc> hmmm... that starts to look too ugly
| |
| 05:18 | <alkisg> Or it can be DM_CMD_01="xrandr params", or DM_CMD_01="cp /run/ltsp/ltsp-initrd/$mac/xorg.conf /etc/X11/"
| |
| 05:19 | I.e. files can be shipped in the initramfs now, no need for ltsp-update-image
| |
| 05:19 | <vagrantc> handling arbitrary file redirectors inside shell variables is starting to get into territory of "maybe this shouldn't be in shell"
| |
| 05:19 | yeah, i love getting rid of ltsp-update-image for every minor change to the server/chroot
| |
| 05:20 | <alkisg> lts.conf will be a shell script with the addition that [sections] become section_name() functions,
| |
| 05:20 | <vagrantc> ltsp.conf? :)
| |
| 05:20 | <alkisg> so it's up to the sysadmin to keep it clean, like VAR=VALUE, or do whatever he wants there
| |
| 05:21 | Currently I have it at /etc/ltsp/ltsp-client.conf
| |
| 05:21 | While ltsp.conf means the server; unused now
| |
| 05:21 | <vagrantc> nice.
| |
| 05:21 | <alkisg> I'm also not sure how to name the client metapackage...
| |
| 05:21 | 1) ltsp-server and ltsp-client? that will "upgrade" ltsp5 to ltsp19
| |
| 05:21 | <vagrantc> because of existing ltsp-client packages?
| |
| 05:22 | <alkisg> 2) ltsp and ltsp-client-meta? that will allow ltsp5 and ltsp19 to coexist
| |
| 05:22 | <vagrantc> really depends on how quickly this matures
| |
| 05:22 | if we can get an important release where they don't co-exist, i'd prefer just upgrading them
| |
| 05:22 | <alkisg> OK let's postpone this until august then
| |
| 05:23 | They don't really mean the same thing though
| |
| 05:23 | E.g. ltsp-server 5 uses /opt; ltsp19 uses /srv
| |
| 05:23 | One uses chroots, the other VMs
| |
| 05:23 | <vagrantc> ah.
| |
| 05:23 | <alkisg> It's like a different product, with no compatibility at all
| |
| 05:23 | So I'm not sure if it can be considered a "package upgrade"
| |
| 05:23 | <vagrantc> ok, so "ltsp" for the server-side for sure ... what do we need in ltsp-client again?
| |
| 05:24 | <alkisg> Currently just the squashfs module in the chroot
| |
| 05:24 | So a tiny initramfs hook
| |
| 05:24 | And it might temporarily need ldm too
| |
| 05:24 | <vagrantc> ltsp-client-hooks ?
| |
| 05:24 | <alkisg> (unless I reimplement it in python/gtk, and send it from ltsp-initrd)
| |
| 05:25 | (or if I make pam* work)
| |
| 05:25 | (08:23:59 AM) vagrantc: ok, so "ltsp" for the server-side for sure ==> OK I think that answers it
| |
| 05:26 | <vagrantc> wonder if a pam-*sql* would be any easier than ldap for a rudimentary implementation
| |
| 05:26 | <alkisg> I might manage to avoid ltsp-client at all; we'll see
| |
| 05:26 | <vagrantc> well, so far you could regenerate the initramfs using an overlay, no?
| |
| 05:26 | not quite as cool as just booting the image directly, but still no modifications to the image
| |
| 05:27 | and doesn't work for cross-architecture images...
| |
| 05:27 | <alkisg> I don't regenerate the initramfs; I send an additional ltsp.img initramfs
| |
| 05:27 | So it works for cross-arch too
| |
| 05:27 | <vagrantc> i know, but if it's between no ltsp-client and regenerating the initramfs, vs. having to maintain ltsp-specific client code?
| |
| 05:27 | alkisg: does the initramfs do depmod?
| |
| 05:28 | e.g. /lib/modules/VERSION/modules* ... are they minimized, or could we simply copy the modules into ltsp-initramfs.img ?
| |
| 05:28 | <alkisg> Currently, we only need the following binaries: squashfs and ldm
| |
| 05:28 | <vagrantc> in the client?
| |
| 05:28 | <alkisg> Squashfs is only needed when ltsp-update-image runs
| |
| 05:29 | <vagrantc> isn't that server-side?
| |
| 05:29 | <alkisg> (while e.g. it's not needed for buster.vbox)
| |
| 05:29 | So, if ltsp-update-image manages to put squashfs to the initramfs, we're fine
| |
| 05:29 | <vagrantc> oh, if the booted image is squashfs, it needs the tools to mount it?
| |
| 05:30 | i don't recall squashfs being needed in the initrd ... ?
| |
| 05:30 | <alkisg> If the booted image is squashfs, the initramfs needs to have the squashfs module
| |
| 05:30 | It's not there by default
| |
| 05:30 | <vagrantc> but not squashfs-utils
| |
| 05:30 | <alkisg> No, it doesn't need squashfs-utils
| |
| 05:30 | <vagrantc> just try injecting the module
| |
| 05:31 | <alkisg> So, if ltsp-update-image somehow manages to regenerate the initramfs and include the squashfs.ko, we're done
| |
| 05:31 | While, for the ldm binary, it'll be solved if I manage to rewrite it in python/gtk, i.e. interpreted, or if pam* works
| |
| 05:31 | <vagrantc> i mean, you might just be able to copy the squashfs.ko into your ltsp-initramfs.img ?
| |
| 05:31 | <alkisg> So if both of those things work, then we're back to not needed an ltsp-client package
| |
| 05:32 | That would require ltsp-initramfs.img to be arch-specific, not arch:any
| |
| 05:32 | <vagrantc> you mean arch:all
| |
| 05:32 | <alkisg> That one :)
| |
| 05:32 | <vagrantc> but you could generate one for each ltsp image
| |
| 05:32 | in addition to the arch:all one
| |
| 05:33 | <alkisg> Yes, but boot.ipxe starts to get ugly then
| |
| 05:33 | <vagrantc> i see
| |
| 05:33 | well, the goal of nothing in the source image is pretty awesome
| |
| 05:33 | <alkisg> Maybe unmkinitramfs + cp + mkinitramfs will work, without using update-initramfs in the "chroot"
| |
| 05:34 | Thus not requiring a "chroot" command, from x64 to armhf or whatever is in the image
| |
| 05:34 | <vagrantc> just append it to the initrd.img ...
| |
| 05:34 | <alkisg> Oh yup forgot about that
| |
| 05:35 | <vagrantc> find /lib/modules/ -name squashfs.ko | cpio -SOMEARGUMENTS | gzip >> initrd.img
| |
| 05:35 | <alkisg> We also need the "overlay" module, but we can insmod that from the read-only mounted "$rootmnt" at initramfs time
| |
| 05:35 | Yup, sounds doable
| |
| 05:35 | <vagrantc> probably slightly more complicated, but that's the jist
| |
| 05:35 | <alkisg> vagrantc: I only worry that it'll also need zlib* modules as dependencies
| |
| 05:36 | <vagrantc> as long as it doesn't trim the /lib/modules/VERSION/modules* files
| |
| 05:36 | can probably resolve that with tools from the server
| |
| 05:36 | <alkisg> That'd be awesome then
| |
| 05:37 | Or we can just tell them "run this command after installing the VM; echo squashfs > /etc/initramfs-tools/modules-something.conf
| |
| 05:37 | <vagrantc> grep squashfs /lib/modules/4.19.0-5-amd64/modules.dep
| |
| 05:37 | kernel/fs/squashfs/squashfs.ko: kernel/lib/zstd/zstd_decompress.ko kernel/lib/xxhash.ko
| |
| 05:37 | and then do that recursively
| |
| 05:37 | note some distros compress the modules
| |
| 05:37 | ko.gz ko.xz, etc.
| |
| 05:39 | at least on buster, it looks like just those three
| |
| 05:39 | this assumes that the initramfs doesn't "clean" the modules.dep and related files
| |
| 05:41 | bad news ... it cleans modules.dep
| |
| 05:42 | but you can probably call depmod -a from the initramfs, if it doesn't do it itself
| |
| 05:48 | <alkisg> Heh, another crazy idea, booting .isos as ltsp clients (with ldm and all) should be doable now. Testing..
| |
| 05:48 | <vagrantc> right
| |
| 06:05 | kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b) | |
| 06:10 | <alkisg> Whoops two "ltsploop" are needed, one for the .iso and one for the squashfs
| |
| 06:10 | <vagrantc> heh
| |
| 06:26 | <alkisg> Yup, I just booted an ubuntu live cd without using "casper"; it booted much faster!
| |
| 06:27 | <vagrantc> with the double-loop mounts?
| |
| 06:27 | <alkisg> Yes
| |
| 06:27 | <vagrantc> nice
| |
| 06:28 | <alkisg> Later on I'll do it properly, maybe with ltsploop=mount1,mount2, but it's not a priority now
| |
| 06:28 | <vagrantc> most of those will probably have squashfs in the initramfs :)
| |
| 06:28 | <alkisg> Yes, and iso9660 too, as booting the .iso from usb is a valid use case
| |
| 06:28 | So it'll be the quickest way to test ltsp
| |
| 06:28 | "just put your favourite .iso there and netboot the clients" :D
| |
| 06:35 | <vagrantc> very cool
| |
| 06:48 | <alkisg> Haha, nfs is great. I disable networking from network-manager, it freezes, I reenable it, it works fine again
| |
| 06:49 | vagrantc: you don't have security concerns about reimplementing ldm in python/shell, right?
| |
| 06:50 | E.g. they can't clean a typed password from RAM, like C, but I think that's asking too much
| |
| 06:52 | (08:26:06 AM) vagrantc: wonder if a pam-*sql* would be any easier than ldap for a rudimentary implementation ==> I don't think we can get sshfs up and working without using the password in ssh first
| |
| 06:52 | So ldap and pam* will need nfs4, kerberos etc, I think it's too much trouble to be our default
| |
| 06:54 | Well, unless we have code that: creates an ssh key on the client, authenticates against the server and sends the public ssh key at the same time, and then the server writes that to ~/home/.ssh/authenticated_keys on the server
| |
| 06:54 | Then the user can do passwordless ssh from the client to the server, setting up sshfs or whatever he likes
| |
| 06:54 | But I don't like the idea of adding a key to the user's home, even temporarily
| |
| 06:54 | <vagrantc> that's a little ugly...
| |
| 06:55 | i wonder if instead of having libpam-sshauth do everything, if we couldn't just create an ssh tunnel as part of the pam stack
| |
| 06:55 | or ssh master socket
| |
| 06:56 | <alkisg> Isn't that what libpam-sshauth does only?
| |
| 06:56 | It does more things than that?
| |
| 06:56 | <vagrantc> it also auth's against the server
| |
| 06:57 | <alkisg> I don't realize the difference there
| |
| 06:57 | To setup the ssh socket, you need to authenticate against the server, right?
| |
| 06:57 | And one would do that from the pam auth hook?
| |
| 06:57 | <vagrantc> pam modules can just do things on the system, but not themselves return any pam information
| |
| 06:58 | <alkisg> So the difference is just "return NULL" or "return OK"?
| |
| 06:58 | Does it save us any coding?
| |
| 06:58 | <vagrantc> that's the question
| |
| 06:59 | we should just switch to kiosks :)
| |
| 06:59 | <alkisg> Btw, having libpam* doesn't mean that users will be able to use fingerprints etc; they'll still be limited to username/passsword,
| |
| 06:59 | <vagrantc> forget about authentication altogether
| |
| 06:59 | :)
| |
| 07:00 | <alkisg> or just allow users to login with username@gmail.com :P
| |
| 07:00 | And two-way authentication
| |
| 07:00 | <vagrantc> well, it's been good tossing around ideas ... but i'd best rest :)
| |
| 07:01 | * vagrantc waves | |
| 07:01 | <alkisg> Thanks!
| |
| 07:01 | And good night
| |
| 07:01 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 07:39 | <alkisg> Yey, initramfs-tools already supports netconsole
| |
| 07:44 | <Hyperbyte> That is awesome!
| |
| 07:44 | I have no idea what it means, but... awesome.
| |
| 07:46 | * alkisg will type the factoid in 2 mins | |
| 07:49 | <alkisg> !learn netconsole as to debug kernel crashes etc, enable netconsole by running `nc -l -u 6666` on the server, and putting this in pxelinux.cfg/default: netconsole=@${ip}/enp0s3,@${srv}/
| |
| 07:49 | <ltsp> The operation succeeded.
| |
| 07:50 | <alkisg> Hyperbyte: usually, kernel crashes don't appear in (remote) syslog; this way ^ we'll finally be able to see why clients crash
| |
| 08:04 | Actually let's start using the new wiki...
| |
| 08:05 | !forget netconsole
| |
| 08:05 | <ltsp> The operation succeeded.
| |
| 08:05 | <alkisg> !learn netconsole as https://github.com/ltsp/ltsp/wiki/netconsole
| |
| 08:05 | <ltsp> The operation succeeded.
| |
| 08:39 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
| 08:47 | <Hyperbyte> Sounds interesting. :-)
| |
| 09:15 | jeblesh has left IRC (jeblesh!2e78d540@gateway/web/freenode/ip.46.120.213.64, Ping timeout: 256 seconds) | |
| 11:16 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 252 seconds) | |
| 11:32 | <alkisg> !rank
| |
| 11:32 | <ltsp> #1 lts.conf (195), #2 ask (165), #3 SCREEN_02 (123), #4 nbd-client (113), #5 vnc-dide (99), #6 epoptes (95), #7 ltsp-manager (80), #8 ltsp-bug (73), #9 lts.conf (64), #10 local-boot (60), #11 tftp (56), #12 quiet-splash (56), #13 greek-schools-ppa (50), #14 alkisg (49), #15 install (47), #16 greek (46), #17 raspberrypi (45), #18 raspberrypi (45), #19 raspberrypi (45), #20 directx (41)
| |
| 11:55 | <alkisg> !list
| |
| 11:55 | <ltsp> Admin, Channel, ChannelLogger, Config, Factoids, MeetBot, Misc, Owner, RSS, Seen, Status, Time, User, and Utilities
| |
| 11:55 | <alkisg> !alias
| |
| 11:55 | <ltsp> (alias [<channel>] <oldkey> <newkey> [<number>]) -- Adds a new key <newkey> for factoid associated with <oldkey>. <number> is only necessary if there's more than one factoid associated with <oldkey>. The same action can be accomplished by using the 'learn' function with a new key but an existing (verbatim) factoid content.
| |
| 11:58 | <alkisg> !load alias
| |
| 11:58 | <ltsp> Error: You don't have the owner capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
| |
| 11:58 | <alkisg> whoami
| |
| 11:58 | !whoami
| |
| 11:58 | <ltsp> I don't recognize you.
| |
| 12:40 | GodFather_ has joined IRC (GodFather_!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com) | |
| 12:43 | GodFather has joined IRC (GodFather!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com) | |
| 13:18 | GodFather_ has left IRC (GodFather_!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds) | |
| 13:18 | GodFather has left IRC (GodFather!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds) | |
| 13:29 | book` has left IRC (book`!~book`@68.ip-149-56-14.net, Quit: Leaving) | |
| 13:32 | book` has joined IRC (book`!~book`@68.ip-149-56-14.net) | |
| 14:27 | pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds) | |
| 14:37 | pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme) | |
| 15:42 | kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds) | |
| 15:43 | kjackal has joined IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr) | |
| 16:20 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 16:32 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.100.191) | |
| 16:35 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.56.54, Ping timeout: 255 seconds) | |
| 17:32 | kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 245 seconds) | |
| 17:33 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:70ee:5f34:4c95:b67b) | |
| 19:07 | kjackal_v2 has joined IRC (kjackal_v2!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348) | |
| 19:08 | kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds) | |
| 19:56 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |
| 22:14 | kjackal_v2 has left IRC (kjackal_v2!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348, Ping timeout: 258 seconds) | |