IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 11 August 2015 (all times are UTC)
| 00:44 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 244 seconds) | |
| 00:50 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 01:28 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-jpkaenrgawmrvbuw, Quit: Connection closed for inactivity) | |
| 03:33 | sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net) | |
| 03:33 | sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net) | |
| 03:42 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 03:58 | vagrantc 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:36 | sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Ping timeout: 244 seconds) | |
| 04:48 | <vagrantc> well, LDM built successfully
| |
| 04:56 | andygraybeal has left IRC (andygraybeal!~andy@h161.2.16.72.static.ip.windstream.net, Ping timeout: 265 seconds) | |
| 05:10 | andygraybeal has joined IRC (andygraybeal!~andy@50.96.137.165) | |
| 05:16 | sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net) | |
| 05:18 | sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Client Quit) | |
| 05:22 | sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net) | |
| 05:57 | sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Quit: ZNC - http://znc.sourceforge.net) | |
| 06:00 | sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net) | |
| 06:13 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 06:29 | mikkel_ has joined IRC (mikkel_!~mikkel@mail.dlvs.dk) | |
| 06:41 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.) | |
| 06:50 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 06:50 | work_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:12 | uXus 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:15 | uXus 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:21 | vagrantc 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:31 | vagrantc 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:00 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 264 seconds) | |
| 08:00 | khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be) | |
| 08:12 | vagrantc 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:50 | gdi2k has left IRC (gdi2k!~gdi2k@180.191.109.246, Read error: Connection reset by peer) | |
| 09:01 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 09:02 | telex 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:06 | gdi2k 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:42 | Grembler 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:15 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 10:15 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 10:19 | khildin 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:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 10:35 | alkisg is now known as work_alkisg | |
| 11:00 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ljtijvlxgkkhtexg) | |
| 11:09 | khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be) | |
| 11:36 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 11:37 | <vagrantc> work_alkisg: everything fixed yet? :)
| |
| 11:38 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 11:42 | Grembler 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:52 | Grembler 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:07 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Read error: Connection reset by peer) | |
| 12:18 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 12:19 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.156.139, Ping timeout: 264 seconds) | |
| 12:20 | adrianorg 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:34 | mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Ping timeout: 264 seconds) | |
| 12:35 | mikkel_ 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:49 | khildin has left IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be, Quit: I'm gone, bye bye) | |
| 12:49 | khildin has joined IRC (khildin!~khildin@ip-62-235-40-110.dial.scarlet.be) | |
| 12:51 | mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Ping timeout: 244 seconds) | |
| 12:55 | mikkel_ 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:23 | khildin 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:37 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Remote host closed the connection) | |
| 13:38 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 13:46 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:46 | mikkel_ has left IRC (mikkel_!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 14:07 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 14:19 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 14:40 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 14:41 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 15:17 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 240 seconds) | |
| 15:19 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 15:26 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 15:38 | gbaman has joined IRC (gbaman!~gbaman@104.40.144.249) | |
| 15:43 | gbaman has left IRC (gbaman!~gbaman@104.40.144.249, Ping timeout: 250 seconds) | |
| 15:50 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 16:13 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 16:51 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 16:52 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 17:58 | work_alkisg is now known as alkisg | |
| 18:50 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:51 | alkisg 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:45 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 20:48 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 21:06 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 21:21 | danau11 has joined IRC (danau11!~durban@12.197.179.122) | |
| 21:25 | danau11 has left IRC (danau11!~durban@12.197.179.122, Ping timeout: 240 seconds) | |
| 22:22 | sutula has left IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net, Ping timeout: 260 seconds) | |
| 22:23 | sutula has joined IRC (sutula!~sutula@207-118-180-127.dyn.centurytel.net) | |
| 22:48 | gdi2k 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:03 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 23:13 | gdi2k has joined IRC (gdi2k!~gdi2k@119.94.4.10) | |
| 23:29 | gdi2k has left IRC (gdi2k!~gdi2k@119.94.4.10, Ping timeout: 260 seconds) | |
| 23:48 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 23:50 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 23:52 | gdi2k has joined IRC (gdi2k!~gdi2k@119.94.4.10) | |
| 23:57 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Quit: Leaving.) | |