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


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

01:17eu^20386213250 has joined IRC (eu^20386213250!cb56d5fa@203.86.213.250)
01:18
<eu^20386213250>
I have a question
01:19eu^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:05kjackal 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:01vagrantc 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:39SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166)
08:47
<Hyperbyte>
Sounds interesting. :-)
09:15jeblesh has left IRC (jeblesh!2e78d540@gateway/web/freenode/ip.46.120.213.64, Ping timeout: 256 seconds)
11:16SYS64738 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:40GodFather_ has joined IRC (GodFather_!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com)
12:43GodFather has joined IRC (GodFather!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com)
13:18GodFather_ has left IRC (GodFather_!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds)
13:18GodFather has left IRC (GodFather!~rcc@71-82-51-159.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds)
13:29book` has left IRC (book`!~book`@68.ip-149-56-14.net, Quit: Leaving)
13:32book` has joined IRC (book`!~book`@68.ip-149-56-14.net)
14:27pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)
14:37pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
15:42kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds)
15:43kjackal has joined IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr)
16:20ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
16:32adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.100.191)
16:35adrianorg has left IRC (adrianorg!~adrianorg@177.156.56.54, Ping timeout: 255 seconds)
17:32kjackal has left IRC (kjackal!~quassel@athedsl-165918.home.otenet.gr, Ping timeout: 245 seconds)
17:33kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:70ee:5f34:4c95:b67b)
19:07kjackal_v2 has joined IRC (kjackal_v2!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348)
19:08kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds)
19:56ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
22:14kjackal_v2 has left IRC (kjackal_v2!~quassel@2a02:587:3106:1000:59a6:2f4c:44b9:f348, Ping timeout: 258 seconds)