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


Channel log from 11 August 2015   (all times are UTC)

00:44cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 244 seconds)
00:50cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
01:28AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jpkaenrgawmrvbuw, Quit: Connection closed for inactivity)
03:33sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net)
03:33sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net)
03:42Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
03:58vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:04
<vagrantc>
work_alkisg, Phantomas: ok. caught up on sleep, time to get LTSP hashed out
04:05
<Phantomas>
Good morning vagrantc
04:05
How's jetlag going?
04:05
<vagrantc>
just about adjusted now. :)
04:06
it's also cooler in the mornings, so probably easier to get work done now than later :)
04:09
<Phantomas>
Good. Hope work_alkisg will show up early too. I'm with no sleep from yesterday so I'll probably have to leave earlier than usual.
04:10
<vagrantc>
oh my!
04:10
<Phantomas>
nah, nothing special. Just permanent jet lag :D :P
04:11
<vagrantc>
ouch
04:12
well, i'm working on updating the ltsp/ldm packaging to work with trunk
04:12
Phantomas: you've been experimenting with linux mint?
04:12
<Phantomas>
Ubuntu Mate 15.10 that is
04:13
it has some bugs, but it's still alpha
04:13
<vagrantc>
well, it'd be good if we can get the next upstream release to work out some of those bugs
04:14
do you know how mint's release process goes as far as getting bug fixes in?
04:14
<Phantomas>
btw work_alkisg sent an ldm build too yesterday a bit after you left
04:14
<vagrantc>
yeah, i forgot to merge those updates
04:15
<Phantomas>
Nah, I don't know much about mint
04:17
<vagrantc>
pushed the ldm packaging updates too
04:19
<Phantomas>
It's been a while since we released a new version of epoptes, so I'm focusing on this right now. I want to test it on 15.10 in order to make sure it works with the "latest" changes (systemd etc)
04:20
And after that I'm probably rewriting most of it. I have already started actually
04:21
I don't know if we're going for LTSP major changes too, but maybe I could help a bit there too.
04:23
<vagrantc>
yeah, i'd really like to get some major changes for LTSP started up again. epecially if it stirs up more developer interest
04:23
it seems like LTSPd would be a good starting point
04:24
and re-writing the init-ltsp.d stuff into alkisg's flexible-boot idea or whatever we want to call it
04:24* vagrantc would also really like to give a look-over with overlayfs
04:24
<vagrantc>
seems like that needs some fixing.
04:26* gehidore huggles overlayfs
04:28
<Phantomas>
I've not studied ltsp's code, so I'm not really in a position to judge or propose changes, but alkisg has told me some of the plans you have discussed. I've also wrote some python for the ltspd thing.
04:30
<vagrantc>
cool
04:36sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Ping timeout: 244 seconds)
04:48
<vagrantc>
well, LDM built successfully
04:56andygraybeal has left IRC (andygraybeal!~andy@h161.2.16.72.static.ip.windstream.net, Ping timeout: 265 seconds)
05:10andygraybeal has joined IRC (andygraybeal!~andy@50.96.137.165)
05:16sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net)
05:18sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Client Quit)
05:22sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net)
05:57sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net)
06:00sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net)
06:13ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
06:29mikkel_ has joined IRC (mikkel_!~mikkel@mail.dlvs.dk)
06:41Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.)
06:50Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas)
06:50work_alkisg is now known as alkisg
06:50* alkisg waves
06:51* muppis yawns
06:51* vagrantc cheers
06:51
<vagrantc>
alkisg: got a stretch VM set up to start testing ltsp
06:52
alkisg: and built ldm, ltsp and ltspfs (with a very minor change)
06:52
so they all still build.
06:52
i suppose i should go ahead and upload libpam-sshauth while i'm at it
06:52
<alkisg>
Cool. Gimme 10' to help Phantomas with some ltsp installation issues in 15.10 first and I"ll check the irclogs then
07:02
Meh, arcfour isn't supported in 15.10... :-/
07:02
!arcfour
07:02
<ltsp>
arcfour: http://en.wikipedia.org/wiki/RC4 is an SSH cipher which is more than 2 times faster than the default aes128-ctr. To enable it, set LDM_SSHOPTIONS="-o Ciphers=arcfour128".
07:02* alkisg needs to benchmark chacha20 which is supposedly suited for low-cpu mobile phones
07:06* vagrantc hopes in vain that overlayfs "just works" with NFS with a more recent kernel than last tested
07:08
<vagrantc>
no such like with 4.1
07:08
i also wanted to work on the loopback mounting patches for initramfs-tools...
07:09
https://bugs.debian.org/468114
07:09
need to also make adjustments for loopback over NFS
07:10
<alkisg>
vagrantc: I sent you a link a week ago about that
07:10
There were patches that made it work with nfs,
07:10
and a user reported that the patches didn't work for him and sent yet another patch
07:11
So it should be working soonish...
07:12
<vagrantc>
alkisg: oh, i should be sure to let the debian kernel maintainers aware of those
07:12uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
07:12
<vagrantc>
alkisg: i guess i missed that link...
07:12
<alkisg>
http://blog.gmane.org/gmane.linux.file-systems.union
07:12
(12:33:47 μμ) alkisg: overlayfs update for 4.2 ==> supposedly supports NFS as lower dir
07:12
...not the last message, which is mine, the previous one
07:13
<vagrantc>
loopback over NFS still gives a lot of the speed improvements and improved "stability" of NFS
07:13
<alkisg>
[GIT PULL] overlayfs update for 4.2
07:13
This relaxes the requirements on the lower layer filesystem: now ones that implement .d_revalidate, such as NFS, can be used.
07:14
vagrantc, we could also default to aoe :D
07:14
<vagrantc>
true enough
07:14
alkisg: ltsp-config aoe ?
07:14
<alkisg>
Yup
07:15* alkisg is ok with nbd though, no major issues
07:15
<vagrantc>
i recall it being fairly simple to set up, if a little obscure
07:15
i've found NBD to be really unstable with very brief networking outage
07:15
<alkisg>
The problem there was with serving a different swap per client
07:15
I couldn't reproduce what you're saying
07:15uXus has joined IRC (uXus!~uXus@217.77.222.72)
07:16
<alkisg>
Try again some time, I even tried to leave the cable unplugged for more than 10 minutes
07:16
<vagrantc>
and also restarting nbd-server crashing all the clients
07:16
<alkisg>
It was still working after I replugged it
07:16
<vagrantc>
ok
07:16
worth retrying, i guess.
07:16
also, wouter has some NBD updates that may be really nice for us
07:17* vagrantc forgets the details
07:17* alkisg really wants local caching for whatever block device we use
07:17
<alkisg>
With SSD disks etc, local network will never be on par again
07:18
I think it would be easy enough to create a block device of our own, one that merges caching and nbd or aoe
07:19
Or, use dmcache or xnbd-proxy
07:19
Anyway, for now, let's start with ironing out the bugs that Phantomas is finding...
07:19
Phantomas: will you file a bug about ltsp-config lts.conf not creating the tftp directory, thus doing nothing?
07:20
<Phantomas>
sure
07:21vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
07:29
<alkisg>
Phantomas: fix for the ltsp-config bug: http://paste.debian.net/291219/
07:30
...ping me when you've filed the bug report
07:31vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
07:32
<vagrantc>
apparently reports of network stability have been exadgerrated
07:34
alkisg: it looks like some patches made their way to mainline
07:34
alkisg: regarding overlayfs/NFS compatibility
07:35
alkisg: hope to get them backported to debian's kernel ... update the bug report
07:35
<alkisg>
Yup that'd be nice
07:35
<vagrantc>
https://bugs.debian.org/786925
07:36
alkisg: so were you saying that there was some progress regarding submounts upstream?
07:36
<alkisg>
vagrantc, which debian versions does this affect? jessie?
07:37
<vagrantc>
alkisg: jessie still uses aufs, so it's just stretch/testing and sid/unstable for now
07:37
<alkisg>
Won't stretch get the 4.2 kernel?
07:37
<vagrantc>
probably, but it makes it hard to test while it doesn't
07:38
<alkisg>
Sure
07:38
About the submounts, I couldn't find anything better than mounting them read-only
07:38
<vagrantc>
alkisg: maybe i'll take a stab at it
07:39
alkisg: i really don't like the read-only option
07:39
<alkisg>
That'd be nice, but I think the proper solution there is to get ltsp-client-core to generate pxelinux.cfg
07:39
I think that overlayfs will be more stable in the future
07:39
At that point, we can take a look again on how to handle it better
07:39
Now it had so many issues that I'm glad that I found something that works in all of its versions
07:39
And I had to use a tmpfs to make it, it wouldn't work with plain /tmp
07:40
*it would only work in the patched ubuntu version with plain /tmp
07:40
Otherwise it re-uses overlayfs submounts but not other submounts, it's a bit crazy on what it does, it's too unstable currently
07:41
<vagrantc>
mounts in /tmp often have restricted permissions... so it might be best to use something outside of /tmp anyways
07:42
<alkisg>
My /tmp is the same as my /, which is ext4
07:42
It's not a special file system
07:42
<vagrantc>
it is not uncommon for it to be special and restricted, is what i'm getting at
07:43
<alkisg>
Whenever I was speaking about /tmp, I was speaking about `mkdir /tmp/testoverlayfs`, which is the same as plain `mkdir /testoverlayfs`
07:43
So the overlayfs issues I had where with plain ext4...
07:43
<vagrantc>
$ sudo ltsp-update-image --cleanup --config-nbd /
07:43
Skipping yaboot configuration. install yaboot package if you need it.
07:43
cp: cannot create regular file ‘/boot/pxelinux.0’: Read-only file system
07:43
ln: failed to create symbolic link ‘/boot/vmlinuz’: Read-only file system
07:43
ln: failed to create symbolic link ‘/boot/initrd.img’: Read-only file system
07:43
:(
07:44
<alkisg>
I think we should delete /usr/share/ltsp/cleanup.d/50-update-kernels and move it to ltsp-client-core.postinst
07:45
Either as a trigger or not
07:45
<vagrantc>
but the server doesn't need those files there at all
07:46
<alkisg>
Why not?
07:46
vagrantc: when one installs ltsp-client, he's asking for those files
07:46
He could then serve them via the server VM .vdi file
07:46
they're not related to ltsp-pnp
07:46
Nor to ltsp-update-image
07:46
<vagrantc>
hmmm.
07:47
i guess it's just like we prefer to use init-ltsp.d to modify files at boot rather than directly ... i.e. when we had more tweaks to the chroots in ltsp-build-client...
07:48
it's not exactly the same, but there is something elegant to only generating the files where they are needed
07:48
<alkisg>
Use case... I use qemu to create an arm VM. I install ltsp-client in it. I don't use ltsp-server at all. When will I have those files generated?
07:49
ltsp-update-image -c can only run in the same arch
07:49
<vagrantc>
noting will generate them automatically ... although depending on how you install/update kernels, it might generate them
07:49
<alkisg>
The files are needed in different arches too
07:49
Chrooting to the COW image to run things is a priviledge that we cannot rely on
07:49
It's good that we can implement ltsp-pnp that way, but the pxelinux files are not specific to ltsp-pnp
07:50
Let me tell it another way...
07:50
ltsp-client does generate those files, on kernel postinst
07:50
It's its responsibility to generate them
07:51
The problem is with debian packaging, "how can I generate those files for the current kernel on postinst without breaking debian policy"
07:51
<vagrantc>
there's nothing policy breaking there
07:51
it's more a timing issue than a policy one
07:51
<alkisg>
Then why wouldn't ltsp-client generate them for the existing kernel?
07:52
Scenario... (1) i install ltsp-client and I don't have these files. (2) I update the kernel and I have these files.
07:52
Is this normal?!
07:52
I would expect consistency there
07:52
<vagrantc>
sure, that's status quo.
07:52
<alkisg>
If `ltsp-update-image -c /` runs after (1), it has a problem. If it runs after (2), it doesn't have a problem.
07:52
And the (2) step is just a normal update, nothing related to ltsp
07:53
That sound very inconsistent to me
07:53
*sounds
07:53
<vagrantc>
i guess i was impressed how it worked with "ltsp-update-image --cleanup /" and wanted to make it more like that, but you're making the case that it should just always be there.
07:53
<alkisg>
Yup
07:53
I do believe that those files belong to ltsp-client since it always generates them on kernel postinst, and that it's a problem that it doesn't initialize for the current kernel on ltsp-client postinst
07:54
I only created /usr/share/ltsp/cleanup.d/50-update-kernels because at that time I couldn't convince you to see it my way :)
07:55
<vagrantc>
i think it used to be more invasive than it is
07:55
<alkisg>
I wouldn't mind if ltsp-client put those files to /var/lib/ltsp instead of /boot, but that's a completely different story
07:56
It's easier to serve them via tftp in /boot, ok
08:00vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 264 seconds)
08:00khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be)
08:12vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
08:15
<vagrantc>
alkisg: so when doing "ltsp-update-image --cleanup /" what do we expect to be modifyable?
08:15
<alkisg>
vagrantc: well, cleanup removes users, so /etc should be modifyable,
08:16
And it might even remove some packages, which then means that /usr and /etc and /var should be modifyable
08:16
<Phantomas>
vagrantc, alkisg: Would you please commit that: https://bugs.launchpad.net/ltsp/+bug/1483573 ? :)
08:18
<alkisg>
Phantomas: sure, doing so...
08:18
<vagrantc>
alkisg: so it's not uncommon for /usr and /var to be mounted separately ...
08:19
<alkisg>
vagrantc: currently, we're not removing any packages
08:19
So currently we only need /etc to be writeable
08:19
In the future, overlayfs might work better and allow us to have the COW on top
08:20
If you can find some other way, I'd be very glad to see it, but I couldn't
08:20
(other than using aufs...)
08:20
<vagrantc>
ok, trying to tackle it now
08:20
ah, you're also wanting a way that works with ubuntu's "overlayfs"? as well as mainline's "overlay" fs?
08:21
<alkisg>
I don't mind, as long as it works with Ubuntu's overlayfs even without submounts at all
08:21
Just mainline overlay is fine
08:26
Phantomas, vagrantc, pushed http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2650
08:26
Let me send an ldm daily build...
08:27
<Phantomas>
great
08:27
<alkisg>
" Import will run as soon as possible. "
08:50gdi2k has left IRC (gdi2k!~gdi2k@180.191.109.246, Read error: Connection reset by peer)
09:01telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
09:02telex has joined IRC (telex!teletype@freeshell.de)
09:05
<vagrantc>
alkisg: i think i have it working the way aufs used to
09:06
it leaves crufty "work" dirs around ... can at least make them hidden dirs.
09:06gdi2k has joined IRC (gdi2k!~gdi2k@119.94.4.10)
09:08
<vagrantc>
it could use some refactoring... but the basic jist is there.
09:21
<vervelak>
alkisg: can you please remind me the bot macros?
09:22
also it will be helpful if you add them in the topic
09:23
<vagrantc>
!help
09:23
<ltsp>
(help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
09:23
<vagrantc>
!topics
09:23
<ltsp>
topics: To get a list of topics, type ltspbot: factoids search --values
09:23
<vagrantc>
ltsp: factoids search --values
09:23
<alkisg>
vervelak: it's supybot, you can google for its commands
09:24
vagrantc: pastebin?
09:24
(the preliminary code...)
09:24
<vervelak>
!factoids
09:24
<ltsp>
factoids: to add factoids to the LTSP bot, type: !learn factoid as text
09:24
<vagrantc>
alkisg: reverted your changes entirely, so this is off the previous
09:24
!factoids search --values
09:24
<ltsp>
More than 100 keys matched that query; please narrow your query.
09:24
<vagrantc>
!factoids search --values no really show them all
09:24
<ltsp>
No keys matched that query.
09:24
<vagrantc>
!factoids search --values *
09:24
<ltsp>
More than 100 keys matched that query; please narrow your query.
09:25
<vagrantc>
meh.
09:25
<vervelak>
!factoids search --values socat
09:25
<ltsp>
'kvm-socat', 'socat', 'socat-screen', and 'socat-server'
09:25
<vervelak>
!factoids search --values socat-screen
09:25
<ltsp>
socat-screen: to share a local thin client shell with a remote person, see https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/socat-screen
09:26
<vervelak>
!factoids search --values socat
09:26
<ltsp>
'kvm-socat', 'socat', 'socat-screen', and 'socat-server'
09:26
<vervelak>
!factoids search --values kvm-socat
09:26
<ltsp>
No keys matched that query.
09:26
<vervelak>
!factoids search --values socat-server
09:26
<ltsp>
No keys matched that query.
09:26
<vervelak>
!factoids search --values screen
09:26
<ltsp>
'Hyperbyte', 'SCREEN_02', 'composition', 'disable_lock_screen', 'flash', 'freerdp', 'kvm-socat', 'kvm-vnc', 'lock-screen', 'mate-bug', 'quiet-splash', 'shell-screen', 'socat', 'socat-screen', 'splash', 'st5742', 'vga', 'vnc-alkisg', 'vnc-dide', 'vnc-plinet', 'win8-rdp', and 'x11vnc'
09:27
<vervelak>
!help
09:27
<ltsp>
(help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
09:27
<vagrantc>
alkisg: http://paste.debian.net/291256/
09:27
<alkisg>
vervelak: you can PM the bot in order to not spam the channel
09:28
vagrantc: the new code uses /proc/modules because in /proc/filesystems both overlay and overlayfs are present
09:28
So in order to see if workdir is needed or not, one needs to check /proc/modules
09:29
(in the ubuntu patched version, the module is named overlayfs, in the kernel's version it's named overlay)
09:31
vagrantc: so you create the workdirs etc in the real file systems?
09:31
What if they're read-only?
09:31
Or if they don't have enough free space?
09:31
Hmm
09:31
<vagrantc>
alkisg: no, they're created in the cow filesystem
09:34
<vervelak>
I can't find the macro for the remote support :S
09:34
<vagrantc>
alkisg: ah, so you might accidentally hit "overlayfs" when you need to behave as "overlay"?
09:36
alkisg: does /proc/modules show if the filesystem is compiled in rather than as a module?
09:36
that's why i used /proc/filesystems
09:36
<alkisg>
vervelak: which remote support, vnc or socat?
09:37
vagrantc: I don't know about compiled-in modules
09:37
<vervelak>
the socat one
09:38
<alkisg>
!socat
09:38
<ltsp>
socat: One way to share a console with a remote person is: [local pc] forward port 5500; apt-get install socat; socat tcp-listen:5500,keepalive=1 stdio,raw,echo=0 [remote pc] apt-get install socat screen; socat SYSTEM:"sleep 1; exec screen -xRR ra",pty,stderr tcp:REMOTE-IP:5500 & screen -l -S ra
09:38
<vagrantc>
alkisg: i guess we could check for the module in the order we want instead
09:38
<alkisg>
vagrantc: /proc/filesystems contains overlay and overlayfs in both cases, e.g. in 12.04 and in 15.10
09:39* vagrantc squints
09:39
<vagrantc>
alkisg: and it needs different options depending on which is actually available?
09:39
<alkisg>
Yes
09:39* vagrantc grunts
09:39
<alkisg>
overlay needs workdir, overlayfs doesn't
09:39
vagrantc: very nice solution :)
09:40
I tested it in wily and it seems to work fine
09:40
Thanks for that, although I still think that we should create pxelinux.cfg on postinst :)
09:40
<vagrantc>
could probably refactor it re-use more common code with the aufs and overlay support
09:40
but i'll push it for now, and then lets figure out a better way to distinguish filesystems
09:41
<alkisg>
Yes, I think it can support all 3 cases
09:42Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
09:42
<alkisg>
vagrantc: do you want me to merge the code so that it's common to all 3 cases, overlay, overlayfs and aufs?
09:44
<vagrantc>
alkisg: so ben hutchings suggests we look for the modules in /sys/modules, which should be present weather it's compiled in or not
09:45
<alkisg>
Cool
09:45
<vagrantc>
alkisg: and then we can control the order of discovery rather than relying on the order in a loop through /proc/filesystems or /proc/modules
09:45* vagrantc looks at it for real
09:45
<vagrantc>
alkisg: right now lets just push what i have
09:46
<alkisg>
vagrantc: I didn't test if the code works in wily, I only tested the concept
09:46
It's possible that it breaks ltsp-update-image -c / in wily...
09:46
<vagrantc>
this is why debcamp is great, that probably saved us hours of fumbling around :)
09:47
<alkisg>
Also the tmpfs is still needed, as by using ext4 the overlay shows up as a submount
09:47
<vagrantc>
alkisg: well, it works in jessie :)
09:47
<alkisg>
So the comment about tmpfs is still valid
09:47
<vagrantc>
no sure what you mean about submount ... i've got /tmp on a tmpfs and it works fine...
09:47
er, /tmp on ext4
09:47
<alkisg>
ltsp-update-image -c / creates a tmpfs
09:47
<vagrantc>
yes
09:48
<alkisg>
I don't remember why I did that
09:48
<vagrantc>
for the overlayfs
09:48
<alkisg>
A week ago I tried not using a tmpfs, but /tmp directly
09:48
There's no real reason to use a tmpfs there
09:48
<vagrantc>
it makes cleanup trivial
09:48
<alkisg>
And I saw that overlayfs has a bug
09:48
<vagrantc>
hrm...
09:48
<alkisg>
Yes but it restricts changes to the available RAM instead of the available free disk space
09:48
<vagrantc>
overlayfs, or overlay fs ? :)
09:49
but the changes are tiny
09:49
we're talking about a handful of directories and maybe some whiteout files
09:49
<alkisg>
Fortunately yes
09:49
It still needs the comment about it though
09:49* alkisg checks /sys/module...
09:49
<vagrantc>
i guess we could conceivably install additional packages
09:51
alkisg: if /sys/module/overlay is only present on newer style, that might be perfect.
09:51
<alkisg>
vagrantc: /sys/module/overlay is only present if one modprobes it
09:51
<vagrantc>
sure, which we do, no?
09:51
<alkisg>
Yes, but first we try to see if it's already loaded
09:52
So that if one modprobes aufs in wily, ltsp-update-image will use it
09:52
<vagrantc>
you have aufs?
09:52
<alkisg>
aufs is available in 15.10 if one wants to modprobe it , yes
09:53
<vagrantc>
the same issue is present with /proc/filesystems, /proc/modules or /sys/module/*
09:53
you need to modprobe it for it to show up
09:53
unless it's compiled in, of course
09:53
<alkisg>
vagrantc: sure I didn't mention it as a problem
09:53
Just as a notice
09:54
<vagrantc>
if multiple are available, i'd like to prefer "overlay", "overlayfs", "aufs" ... maybe allowing an option to force one.
09:54
<alkisg>
vagrantc: so, we can properly support aufs, overlay and overlayfs, we don't have any pending issues here, right?
09:55
<vagrantc>
as far as i can see.
09:55
well, other than the NFS issue
09:55
but for ltsp-update-image, it appears to work fine
09:55
<alkisg>
Sure, but I mean that we don't need to commit something now and something later on
09:55* vagrantc would prefer incremental commits
09:56
<alkisg>
Based on the old or on the new code? (before your in-development patch)
09:57
<vagrantc>
i think the read-only bind mounts were undesireable and i don't think it upload worthy
09:57
so i would like to push the patch i've made
09:57
<alkisg>
OK, I'll merge the other fixes after your upload
09:57
<vagrantc>
but it doesn't yet detect the right version
09:57
doesn't yet detect the overlay vs. overlayfs mount options
09:57
<alkisg>
I.e. comments, modprobe -q, removing chroot name etc
09:58
Unifying the bind-mounts code etc
09:58
<vagrantc>
yeah, that'd be good to do next, i think.
09:58
<alkisg>
It's just double work
09:58
But np I undid some of your work so it's payback time :)
09:58
<vagrantc>
heh
09:58
and pushed
09:59
<alkisg>
Tell me when you're done with it so that I can re-merge
09:59
<vagrantc>
go for it
09:59
and now there are git artifacts in the bzr commit history :)
09:59
<alkisg>
I'll use my own version if you don't mind... :)
10:00
I.e. keep the new code and merge the bind mounts part
10:00
<vagrantc>
hm?
10:00
oh, too late
10:00
what?
10:00* vagrantc is confused
10:01
<alkisg>
It's easier for me to support all 3 modules based on my code that based on your code, that's all, it's nothing important
10:01
<vagrantc>
i pushed two changes, one which reverted the previous cmmit, and another which rewrites the bind-mounts with overlay to be like aufs
10:01
<alkisg>
The end result does the same
10:01
s/that/than
10:02
<vagrantc>
the overlay stuff is tricky to get right with the workdirs
10:02
but as long as it works i'm not attached either way.
10:04
<alkisg>
So anyway what I meant is that I'll try to do the merge starting the code from r2650 instead of from r2652
10:04* alkisg goes for it...
10:06
<vagrantc>
this will be a bit of messy history :)
10:06
<alkisg>
There were other changes in r2650 that should have been kept... and it's difficult to re-do them in another way
10:06
<vagrantc>
fair enough
10:07
<alkisg>
Anyway details
10:15vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
10:15vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
10:19khildin has left IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be, Ping timeout: 250 seconds)
10:30* vagrantc heads to lunch
10:30* vagrantc waves
10:30vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
10:35alkisg is now known as work_alkisg
11:00AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ljtijvlxgkkhtexg)
11:09khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be)
11:36vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
11:37
<vagrantc>
work_alkisg: everything fixed yet? :)
11:38Faith has joined IRC (Faith!~paty@unaffiliated/faith)
11:42Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Read error: Connection reset by peer)
11:45
<vagrantc>
apparently, debian's essentially in freeze... so experimental only.
11:45* vagrantc sighs
11:52Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
11:58
<vagrantc>
well, i can build an image, but didn't say anything about it booting... hrm.
12:07Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Read error: Connection reset by peer)
12:18Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
12:19adrianorg has left IRC (adrianorg!~adrianorg@186.213.156.139, Ping timeout: 264 seconds)
12:20adrianorg has joined IRC (adrianorg!~adrianorg@179.180.170.26)
12:23
<Phantomas>
vagrantc: Just reported this one: https://bugs.launchpad.net/ltsp/+bug/1483682
12:23
Informed alkisg too, he thinks it's probably incompatibility with systemd and he'll take a look
12:25
<vagrantc>
something's probably killing the nbd-client
12:25
and not respecting all the places we've told it not to
12:26
<Phantomas>
Seems like it
12:27
<vagrantc>
seems to be hanging on swap creation for me.
12:29
<work_alkisg>
vagrantc: I'll be back (available) in a couple of hours, but I think I'll work on the smaller ltsp issues first, then on the non-free repository that I was working on yesterday, and I'll end up merging the overlayfs stuff after those
12:29
So I'll probably not do all of those today... :)
12:34mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Ping timeout: 264 seconds)
12:35mikkel_ has joined IRC (mikkel_!~mikkel@mail.dlvs.dk)
12:39
<vagrantc>
work_alkisg: fair enough
12:43* highvoltage catches up with what vagrantc is up to
12:49khildin has left IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be, Quit: I'm gone, bye bye)
12:49khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be)
12:51mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Ping timeout: 244 seconds)
12:55mikkel_ has joined IRC (mikkel_!~mikkel@mail.dlvs.dk)
13:05
<vagrantc>
highvoltage: heya!
13:06
highvoltage: mostly just trying to get ltsp/ldm/ltspfs updated with all the committed but unreleased patches
13:13
<highvoltage>
ah cool.
13:15
<vagrantc>
Phantomas: i'm able to poweroff/reboot fine with debian's stretch release using systemd ... i wonder what's different.
13:15
Phantomas: oh, unmounting /rofs and /cow seem likely culprits
13:15
<Phantomas>
oh... strange
13:16
<vagrantc>
it might be using a different feature set of systemd
13:16
(also debian jessie, the current stable release, works fine with systemd)
13:17
Phantomas: could you try with a different init system?
13:17
<Phantomas>
I thought so too about the unmounting, that's why I typed this part of the log
13:17
yea, i'll give it a try, just not today, probably tomorrow
13:18
<vagrantc>
sure
13:20
<Phantomas>
I was looking for a caching block device for nbd, in order to make things faster in ltsp, you've probably talked about that with alkisg
13:20
<vagrantc>
a little
13:20
i also talked about that sort of stuff with the debian NBD maintainer
13:21
<Phantomas>
seems like a guy named Juan Antonio Martinez has tried bcache over NBD, with some success
13:21
also that name seems familiar, I guess I've seen him in this channel sometime?
13:22
<vagrantc>
bcache seems interesting
13:22
<Phantomas>
http://sourceforge.net/p/nbd/mailman/message/32028740/
13:23
yea alkisg told me the requirements and mentioned bcache and dm-cache and I looked them up a bit
13:23khildin has left IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be, Remote host closed the connection)
13:23
<Phantomas>
they both seem to be mainly focused on speeding up write operations on HDDs by using SSDs as cache
13:24
<vagrantc>
the newest lab i'm looking at switching to LTSP has pretty large hard disks in all the clients already... would be nice to put them to use
13:26
<Phantomas>
In terms of speeding up LTSP networking etc I don't think a really large hard disk would be required. Would it?
13:28
I mean, the image shouldn't really exceed like 10-20GB or so. On the other hand, I'm totall not an LTSP expert :)
13:29
<vagrantc>
even for a fairly large fatclient, i haven't seem images get bigger than a couple gigs of compressed squashfs
13:30
uncompressed maybe 5g
13:30
though caching what's actually used only needs a tiny amount
13:30
what would be really cool is if it still worked if the server was down...
13:31
<Phantomas>
indeed
13:32
I was pretty excited to get involved and write a read-only cache block device for NBD, but I think bcache should do the trick pretty well.
13:33
We could test it, and if it misses features we'd like such as working when the server is down, I may get excited again :P
13:34
<vagrantc>
:)
13:35
<Phantomas>
It's a bit ironic that it needs some workarounds to be used as a read-only caching device which is fairly simple, when they have implemented so many write modes. But as I said, they probably aimed at SSD -> HDD caching.
13:37ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Remote host closed the connection)
13:38ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
13:46ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
13:46mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:07Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
14:19vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi)
14:40uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
14:41uXus has joined IRC (uXus!~uXus@217.77.222.72)
15:17vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds)
15:19uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek)
15:26uXus has joined IRC (uXus!~uXus@217.77.222.72)
15:38gbaman has joined IRC (gbaman!~gbaman@104.40.144.249)
15:43gbaman has left IRC (gbaman!~gbaman@104.40.144.249, Ping timeout: 250 seconds)
15:50Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net)
16:13Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave)
16:51telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
16:52telex has joined IRC (telex!teletype@freeshell.de)
17:58work_alkisg is now known as alkisg
18:50vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:51alkisg is now known as work_alkisg
18:53
<Phantomas>
vagrantc: Hey! Have you been playing with ansible?
18:54
<vagrantc>
Phantomas: yes, it's pretty cool.
18:54
<Phantomas>
Seems that it could be a possible base for epoptes. What do you think?
18:55
<vagrantc>
just the distributed ssh component?
18:55
i've mostly used it for system configuration
18:56
<Phantomas>
I read that you can use modules which can be a python script for example
18:56
so, maybe we could make epoptes-client an ansible module
18:56
and yea, use its ssh connections etc instead of a custom protocol that we are currently using
18:58
I'm not sure if it is flexible enough so that you can have the logic we need in epoptes-client in an ansible module, but seems like it could be possible
18:59
<vagrantc>
i'm not sure ansible would add much to what you already have
18:59
<Phantomas>
I mean, all a module does is provide configuration, or it can do whatever it wants
19:01
Yea, we've been in an epic debate with work_alkisg in the last 3 years about whether we should use a daemon for epoptes or just gui <-> clients with forward connections (gui connects to client)
19:01
he linked ansible to me, with an excess feeling of victory :P
19:01
<vagrantc>
heh
19:01
standardized protocols is good... just not sure it's the right match
19:06
<Phantomas>
ok, maybe I'll have a look and see if I should declare defeat, or keep going with my daemon stuff
20:45Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo)
20:48vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
21:06ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
21:21danau11 has joined IRC (danau11!~durban@12.197.179.122)
21:25danau11 has left IRC (danau11!~durban@12.197.179.122, Ping timeout: 240 seconds)
22:22sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Ping timeout: 260 seconds)
22:23sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net)
22:48gdi2k has left IRC (gdi2k!~gdi2k@119.94.4.10, Ping timeout: 250 seconds)
22:51
<maldridge>
I don't think ansible is really what you'd want for this, getting a module to run remotely is easy enough, but getting it to run remotely, and locally requires special vodoo. If you could have it just run remotely, there are lighter solutions that might be cheaper
23:03ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
23:13gdi2k has joined IRC (gdi2k!~gdi2k@119.94.4.10)
23:29gdi2k has left IRC (gdi2k!~gdi2k@119.94.4.10, Ping timeout: 260 seconds)
23:48telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
23:50telex has joined IRC (telex!teletype@freeshell.de)
23:52gdi2k has joined IRC (gdi2k!~gdi2k@119.94.4.10)
23:57Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.)