IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 7 August 2015 (all times are UTC)
| 00:55 | teacher has joined IRC (teacher!a2f670de@gateway/web/freenode/ip.162.246.112.222) | |
| 00:55 | <teacher> hey is there anyone here who can help me with epoptes?
| |
| 00:55 | i am running edubuntu and can't get the standalone clients to find the epoptes server
| |
| 00:55 | <maldridge> teacher: what have you tried so far?
| |
| 00:56 | <teacher> basically when i go get certificates i get a timeout error
| |
| 00:56 | basically it can't find the server
| |
| 00:56 | i think i need config epoptes to find the server but not sure how
| |
| 00:57 | i went into config file and entered ip address
| |
| 00:57 | so it reads 192.168.1.xxx=server now
| |
| 00:58 | <maldridge> that needs to go the other way
| |
| 00:58 | you put that in the file located at /etc/default/epoptes-client right?
| |
| 00:58 | <teacher> yes
| |
| 00:59 | and i deleted the # in front of that line
| |
| 00:59 | and it is the other way in the file
| |
| 00:59 | <maldridge> can you ping that address from your client?
| |
| 01:00 | <teacher> so in terminal i would do like ping <ipaddress>?
| |
| 01:00 | <maldridge> yeah
| |
| 01:00 | you should get something like "64 bytes back"...
| |
| 01:00 | <teacher> PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data. 64 bytes from 192.168.1.196: icmp_seq=1 ttl=64 time=0.511 ms 64 bytes from 192.168.1.196: icmp_seq=2 ttl=64 time=0.186 ms 64 bytes from 192.168.1.196: icmp_seq=3 ttl=64 time=0.205 ms 64 bytes from 192.168.1.196: icmp_seq=4 ttl=64 time=0.193 ms 64 bytes from 192.168.1.196: icmp_seq=5 ttl=64 time=0.209 ms 64 bytes from 192.168.1.196: icmp_seq=6 ttl=64 time=0.207 ms 64 bytes from
| |
| 01:01 | yep
| |
| 01:01 | pinged ok
| |
| 01:01 | teacher@LINUX4:~$ sudo epoptes-client -c 140553966347936:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:787: epoptes-client ERROR: Failed to fetch certificate from 192.168.1.196:789 teacher@LINUX4:~$
| |
| 01:01 | that is my error
| |
| 01:02 | <maldridge> hm, and the firewall on the server is configured to allow traffic from the client to connect?
| |
| 01:02 | <teacher> unsure how to check that on ubuntu?
| |
| 01:02 | i know i downloaded a gui firewall manager but i don't remember the name
| |
| 01:03 | <maldridge> hm, if you didn't configure a firewall, you probably don't
| |
| 01:03 | <teacher> i am starting to think it is server side though-- none of the clients will connect
| |
| 01:03 | <maldridge> in a terminal, you can run "sudo iptables -nvL"
| |
| 01:03 | that will tell you what the firewall state is, you are specificall concerned with "CHAIN INPUT"
| |
| 01:04 | <teacher> on client or server?
| |
| 01:04 | <maldridge> server
| |
| 01:06 | <teacher> unknown input "-nvL"
| |
| 01:07 | <maldridge> you entered that command as typed, without the quotes?
| |
| 01:09 | <teacher> they all say policy accept
| |
| 01:10 | i ended up doing iptables -L
| |
| 01:10 | is that what i was looking for?
| |
| 01:11 | <maldridge> if they all say accept, it shouldn't be a firewall issue then
| |
| 01:12 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 01:12 | <maldridge> I'm not really sure what the issue would be then, my appologies I don't run epoptes on my network
| |
| 01:13 | teacher2 has joined IRC (teacher2!a2f670de@gateway/web/freenode/ip.162.246.112.222) | |
| 01:13 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Client Quit) | |
| 01:13 | <teacher2> teacher@LINUX7T:~$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination +
| |
| 01:13 | that is from the server
| |
| 01:13 | Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas) | |
| 01:14 | <maldridge> hm, not a firewall issue then
| |
| 01:16 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 01:20 | teacher has left IRC (teacher!a2f670de@gateway/web/freenode/ip.162.246.112.222, Quit: Page closed) | |
| 01:28 | teacher has joined IRC (teacher!a2f670de@gateway/web/freenode/ip.162.246.112.222) | |
| 01:28 | <teacher> thanks for your help
| |
| 01:28 | sudo ufw allow out 443/tcp
| |
| 01:36 | <maldridge> I suspect that was meant for another terminal
| |
| 01:57 | <teacher2> i needed to edit the etc\host file-- now i am running
| |
| 01:58 | thanks for being there at least-- you are a diplomat i am proud to have for the linux community
| |
| 01:58 | <maldridge> why are you editing the /etc/hosts ?
| |
| 01:58 | always glad to help, some things are non-obvious
| |
| 01:58 | <teacher2> i had to redirect it to the ip addy as the server there also
| |
| 01:58 | <maldridge> ah, so your epoptes server isn't in DNC
| |
| 01:58 | DNS
| |
| 01:58 | <teacher2> i don't believe so
| |
| 01:59 | and i dont have a static ip address on the server...so every few days/ weeks we will have to reconfigure
| |
| 01:59 | <maldridge> ok, that makes sense, but is should have worked by IP
| |
| 01:59 | oh
| |
| 01:59 | <teacher2> which sucks...maybe i can change the router to have the server as static
| |
| 01:59 | <maldridge> if you control the DHCP server its pretty easy to set a static address
| |
| 01:59 | alternatively you could install avahi on the server and clients and allow them to find each other on a *.local domain
| |
| 01:59 | <teacher2> i don't and out tech person is pretty non-tech...honestly.
| |
| 01:59 | so we will see?
| |
| 01:59 | maybe she will let
| |
| 02:00 | thats a good idea-- avahi
| |
| 02:00 | will look into that
| |
| 02:00 | teacher has left IRC (teacher!a2f670de@gateway/web/freenode/ip.162.246.112.222, Ping timeout: 246 seconds) | |
| 02:01 | teacher2 has left IRC (teacher2!a2f670de@gateway/web/freenode/ip.162.246.112.222, Quit: Page closed) | |
| 03:44 | anthonym has joined IRC (anthonym!~anthonym@pdpc/supporter/professional/anthonym) | |
| 03:45 | <anthonym> Hey guys. I'm thinking of implementing LTSP in our organisation, to share terminal access to our ubuntu application server for multiple thinstations. I've got an implementation here for testing and so far it isn't too bad. My question though is this. I have multiple locations that are all linked together via vpn. How does LTSP hold up over WAN/vpn? And what would be recommended to ensure
| |
| 03:45 | this works optimally?
| |
| 03:51 | <maldridge> ltsp boots over the network, I'm not sure you can do that with a VPN, what is your end goal?
| |
| 03:53 | <anthonym> I need my external business locations to be able to logon to the terminal server in this office
| |
| 03:53 | <maldridge> do they have site to site VPN?
| |
| 03:53 | <anthonym> just like a windows terminal server..
| |
| 03:53 | the remote offices I guess will be treated as 'remote users'
| |
| 03:54 | <maldridge> if I'm not mistaken, windows terminal server needs the remote machines to already have an OS on them
| |
| 03:54 | ltsp was designed ot bootstrap up from bare metal into a workable system
| |
| 03:56 | <anthonym> Yeah I understand that. so I guess ltsp will only be useful for the computers here in the office.
| |
| 03:56 | and for the remote offices I'd need to use something like NX server?
| |
| 03:57 | This part here:
| |
| 03:57 | The client then loads Linux from the NFS mounted root filesystem (or NBD filesystem image) and starts the X Window system. At this XDMCP login manager on the LTSP server. In case of the newer MueKow (LTSP v5.x) setup, the client first builds an SSH tunnel to the LTSP server's X environment, through which it will start the LDM (LTSP Display Manager) login manager locally. From this point forward,
| |
| 03:57 | all programs are started on the LTSP server, but displayed and operated from the client.
| |
| 03:58 | thats from here: https://en.wikipedia.org/wiki/Linux_Terminal_Server_Project
| |
| 03:58 | so is it possible to have the remote networks boot into an LTSP environment and tunnel into the terminal server here?
| |
| 03:59 | <maldridge> one moment please
| |
| 03:59 | dealing with a sev1
| |
| 04:04 | if you were running a network topology far more complex than can be discussed here, you could do that
| |
| 04:15 | <anthonym> thanks :)
| |
| 04:17 | <maldridge> np
| |
| 04:49 | eemeli has joined IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12) | |
| 04:52 | ricotz has joined IRC (ricotz!~rico@p5B2A993B.dip0.t-ipconnect.de) | |
| 04:52 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 05:13 | eemeli has left IRC (eemeli!3e94cd0c@gateway/web/freenode/ip.62.148.205.12, Quit: Page closed) | |
| 05:13 | Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 05:15 | Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas) | |
| 05:16 | Phantomas has left IRC (Phantomas!~phantomas@ubuntu/member/phantomas, Read error: Connection reset by peer) | |
| 06:10 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 07:06 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 07:08 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 07:11 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 07:28 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds) | |
| 07:49 | work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr) | |
| 08:06 | <work_alkisg> anthonym: what is your VPN bandwidth?
| |
| 09:06 | ltsp has joined IRC (ltsp!~supybot@ltsp.org) | |
| 09:10 | ltsp has joined IRC (ltsp!bot@ltsp.org) | |
| 10:10 | NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es) | |
| 10:45 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split) | |
| 10:45 | elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split) | |
| 10:45 | _longines has left IRC (_longines!~longines@static.95.25.4.46.clients.your-server.de, *.net *.split) | |
| 10:45 | spectra_ has left IRC (spectra_!~spectra@63.142.251.150, *.net *.split) | |
| 10:49 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 10:51 | elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi) | |
| 10:51 | _longines has joined IRC (_longines!~longines@static.95.25.4.46.clients.your-server.de) | |
| 10:51 | spectra_ has joined IRC (spectra_!~spectra@63.142.251.150) | |
| 10:53 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 11:04 | alkisg is now known as work_alkisg | |
| 11:05 | NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 246 seconds) | |
| 11:19 | danau11 has joined IRC (danau11!~durban@12.197.179.122) | |
| 11:20 | danau11 has left IRC (danau11!~durban@12.197.179.122) | |
| 11:28 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 12:18 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.102.209, Ping timeout: 246 seconds) | |
| 12:20 | adrianorg has joined IRC (adrianorg!~adrianorg@189.58.224.95.dynamic.adsl.gvt.net.br) | |
| 12:48 | <zamba> Hyperbyte: nope, not nfs
| |
| 12:50 | Hyperbyte: all clients are dropped into initramfs now
| |
| 12:57 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 13:33 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 13:36 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 13:44 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 13:47 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:56 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 255 seconds) | |
| 13:57 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 14:56 | anthonym has left IRC (anthonym!~anthonym@pdpc/supporter/professional/anthonym, Remote host closed the connection) | |
| 14:57 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 14:58 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 14:59 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:59 | anthonym has joined IRC (anthonym!~anthonym@59-100-200-214.syd.static-ipl.aapt.com.au) | |
| 15:00 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 15:04 | anthonym has left IRC (anthonym!~anthonym@59-100-200-214.syd.static-ipl.aapt.com.au, Remote host closed the connection) | |
| 15:04 | anthonym has joined IRC (anthonym!~anthonym@59-100-200-214.syd.static-ipl.aapt.com.au) | |
| 15:24 | <Hyperbyte> zamba, any progress?
| |
| 15:39 | Phantomas has joined IRC (Phantomas!~phantomas@ubuntu/member/phantomas) | |
| 15:54 | work_alkisg is now known as alkisg | |
| 16:00 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:03 | <zamba> Hyperbyte: not really, no
| |
| 16:03 | <Hyperbyte> I'm home nwo.
| |
| 16:03 | Need help still?
| |
| 16:07 | <alkisg> vagrantc: I hope you didn't get a chance to pull r2648, I pushed --overwrite to 's/_/ /' in a comment :)
| |
| 16:08 | vagrantc: also, please test it with aufs when you have a chance, I removed your code in order to use the same code path as in overlayfs
| |
| 16:08 | <vagrantc> oh, that'd be nice if it works
| |
| 16:08 | <alkisg> It will suffer from the same "submounts are RO" issue, but at least the code will be common
| |
| 16:08 | <vagrantc> alkisg: i'm not in any position to do much testing at the moment
| |
| 16:08 | alkisg: boo! :P
| |
| 16:08 | <alkisg> np, just keep it in mind for the future :D
| |
| 16:08 | Haha
| |
| 16:09 | <vagrantc> actually, we need /boot to be writeable for the tftp menu generaiton, no?
| |
| 16:09 | <alkisg> Hrm. I tested with some /home and /mnt submounts, I didn't actually test with /boot.
| |
| 16:09 | <vagrantc> alkisg: the pre-conference wifi is laggy and only available for like 30 minutes a day :(
| |
| 16:10 | <alkisg> vagrantc: I don't think we're doing anything to /boot in the cleanup phase
| |
| 16:10 | <vagrantc> alkisg: so overlayfs doesn't allow you to mount directories within the filesystem, is that the problem/
| |
| 16:10 | ?
| |
| 16:10 | <alkisg> We want write access when ltsp-update-kernels runs, right?
| |
| 16:10 | <vagrantc> yes
| |
| 16:10 | <alkisg> I.e. in kernel-postinst, not in `ltsp-update-image -c /`...
| |
| 16:10 | So we should be OK if the /boot submount is RO in ltsp-update-image...
| |
| 16:11 | There are multiple problems with overlayfs, but yes that's the major one
| |
| 16:11 | <vagrantc> if update-kernels hasn't been run, the server may not have the menus in /boot
| |
| 16:11 | <alkisg> ltsp-update-image won't solve that though in the cleanup phase
| |
| 16:12 | <vagrantc> it used to
| |
| 16:12 | <alkisg> update-kernels is ran outside of the COW image
| |
| 16:12 | <vagrantc> that doesn't match my experience
| |
| 16:12 | <alkisg> It ran update-kernels inside the COW view, and the boot/pxelinux.cfg subdir was removed after the COW view was discarded
| |
| 16:12 | ?
| |
| 16:13 | Note, I'm talking about the cow view that cleanup sets up, not outside of it
| |
| 16:14 | <vagrantc> so, how does it write such that the image generated has the files, but the server's /boot remains untouched, without doing it in the cow phase?
| |
| 16:15 | <alkisg> I don't see any calls to update-kernels
| |
| 16:15 | And in my experience, it didn't call update-kernels
| |
| 16:15 | I don't know why you remember that it did
| |
| 16:15 | https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 16:15 | <vagrantc> merely by observation of a recent install
| |
| 16:15 | <alkisg> /usr/share/ltsp/update-kernels
| |
| 16:15 | I even have the command listed as a manual one
| |
| 16:16 | For the sysadmin to execute it
| |
| 16:16 | <vagrantc> well, i definitely never ran it in my recent build out, and it behaves as described
| |
| 16:16 | <alkisg> Let me check the debian ltsp-pnp wiki...
| |
| 16:17 | dpkg-reconfigure linux-image-3.2.0-4-486 This reports update-initramfs: Generating /boot/initrd.img-3.2.0-4-486 adding the changes above and triggers the call to /usr/share/ltsp/update-kernels.
| |
| 16:17 | If one runs dpkg-reconfigure, then that is what calls update-kernels...
| |
| 16:18 | Ah, found it, cleanup.d/50-update-kernels
| |
| 16:19 | <vagrantc> i never ran that
| |
| 16:19 | yeah, it ran as part of cleanup.d
| |
| 16:19 | <alkisg> It's automatically ran by ltsp-update-mage -c
| |
| 16:20 | So yup this will fail on certain conditions
| |
| 16:20 | I.e. if the user has a separate /boot, and he's never ran update-kernels...
| |
| 16:21 | Please put update-kernels in ltsp-client-core.postinst :)
| |
| 16:24 | <vagrantc> meh.
| |
| 16:24 | alkisg: i guess i'd rather keep aufs working
| |
| 16:25 | and come up with a better fix for overlayfs
| |
| 16:25 | <alkisg> OK, sorry for reverting the aufs part
| |
| 16:25 | I'd be glad to see a better fix for overlayfs, but I don't think that ltsp-update-image --cleanup should be the one calling update-kernels inside the COW
| |
| 16:25 | <vagrantc> it's fine, that's why we have revision control! :)
| |
| 16:26 | <alkisg> I only put it there as a hack until you fixed it in packaging...
| |
| 16:29 | We keep pxelinux.cfg automatically updated in each kernel upgrade, I think it's sane that we initialize it to the existing kernel when ltsp-client-core is installed
| |
| 16:29 | It's not like we have a tool for the sysadmin to run... we modify the system automatically anyway
| |
| 16:30 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 264 seconds) | |
| 16:30 | <alkisg> End of 30' internet time :D
| |
| 16:33 | vagrantc has joined IRC (vagrantc!~vagrant@2.173.94.72) | |
| 16:33 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:35 | <alkisg> (07:30:39 μμ) alkisg: End of 30' internet time :D
| |
| 16:35 | (07:29:26 μμ) alkisg: We keep pxelinux.cfg automatically updated in each kernel upgrade, I think it's sane that we initialize it to the existing kernel when ltsp-client-core is installed
| |
| 16:41 | Another example... if I run debootstrap and install ltsp-client (not using ltsp-build-client), I won't get pxelinux.cfg either. I think I should get it, from ltsp-client postinst
| |
| 16:41 | <vagrantc> alkisg: i think it makes more sense to run at image creation time ... it's more guaranteed to be correct.
| |
| 16:41 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 16:41 | <alkisg> (no cleanup involved there)
| |
| 16:42 | vagrantc: then should we remove the update-kernels kernel hook as well?
| |
| 16:42 | <vagrantc> it's too hot to really think this out, though
| |
| 16:42 | :)
| |
| 16:42 | <alkisg> :)
| |
| 16:43 | I install a VM in vbox, then install ltsp-client. I'd like my .vdi image to be directly exportable...
| |
| 16:43 | No image generation there at all
| |
| 16:44 | <vagrantc> we'll need to use dpkg triggers with the kernel hook or something
| |
| 16:45 | in fact, we might want to drop the kernel hook and just use dpkg triggers
| |
| 16:45 | they've been available at least since wheezy, and would allow us to run various hooks at more appropriate times
| |
| 16:48 | just haven't wrapped my head around exactly how to test it yet
| |
| 16:48 | <alkisg> I don't understand... the update-initramfs trigger would just call our kernel postinst, won't it?
| |
| 16:49 | I.e. we'd still need the kernel postinst hook...
| |
| 16:50 | <vagrantc> well, i'm not sure kernel postinst is the right place anymore ... because update-initramfs may get triggered and regenerate the initramfs, but that wouldn't re-run our code (though it arguably should)
| |
| 16:51 | <alkisg> dpkg-reconfigure update-initramfs calls the trigger which calls our hook, doesn't it?
| |
| 16:51 | triggers are not for usual execution, like a plain `update-initramfs` call, they exist for package installation/configuration etc, right>
| |
| 16:51 | ?
| |
| 16:52 | *dpkg-reconfigure linux-image, sorry
| |
| 16:52 | hrm
| |
| 16:53 | <vagrantc> basically, we may need to add our hooks to multiple places
| |
| 16:54 | <alkisg> Triggers are the to prevent multiple executions etc, right?
| |
| 16:54 | Do we expect multiple runs of ltsp-client-core.postinst?
| |
| 16:55 | * alkisg reads up on dpkg triggers... | |
| 16:55 | <alkisg> https://lists.ubuntu.com/archives/ubuntu-devel/2007-January/023212.html
| |
| 16:55 | <vagrantc> we'll still need ways to run it manually
| |
| 16:56 | but i think if we hook into a few more triggers that'd be good.
| |
| 17:00 | vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc) | |
| 17:01 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Disconnected by services) | |
| 17:01 | <alkisg> To restore a package in state `triggered' to `installed', dpkg will run the postinst script: postinst triggered " ..."
| |
| 17:01 | vagrantc_ is now known as vagrantc | |
| 17:02 | <alkisg> So the idea is to drop the kernel hook and put the code in postinst, if "triggered" is passed...
| |
| 17:02 | <vagrantc> that document is also quite old ... not sure what the state of the art is
| |
| 17:03 | <alkisg> But we won't get the kernel version being installed that way
| |
| 17:03 | <vagrantc> there are two ends to triggers to .. the listeners and the providers (not sure on the terms)
| |
| 17:04 | <alkisg> man deb-triggers => interest / activate
| |
| 17:06 | >> A package with pending triggers is not considered properly installed until efforts to notify it of the trigger event have been successful. The new state of having pending triggers is a dpkg package status of `triggered', which lies somewhere between `config-failed' and `installed'.
| |
| 17:07 | That does sound appropriate :)
| |
| 17:07 | <vagrantc> now i remember why i have waited so long to investigate triggers properly...
| |
| 17:13 | <alkisg> It seems straightforward; we need ltsp-client-core.postinst with "activate update-initramfs\ninterest update-initramfs", and to handle "triggered" in ltsp-client-core.postinst
| |
| 17:13 | *we need ltsp-client-core.triggers with ...
| |
| 17:33 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 250 seconds) | |
| 17:36 | alkisg is now known as work_alkisg | |
| 17:45 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:10 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 19:47 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 19:48 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 19:49 | <championofcyrodi> did that LDM HASH password fix ever make it in to ubuntu 14.04 repo?
| |
| 19:49 | * championofcyrodi is looking | |
| 19:50 | <championofcyrodi> 5.5.1-1ubuntu2
| |
| 19:50 | last time i looked at it, the builds were failing.
| |
| 20:05 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 264 seconds) | |
| 20:06 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 20:17 | <championofcyrodi> hmmm yea... the ltsp-docs from ubuntu are still out of sync with the ltsp main...
| |
| 21:14 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 21:38 | anthonym has left IRC (anthonym!~anthonym@59-100-200-214.syd.static-ipl.aapt.com.au, Remote host closed the connection) | |
| 21:39 | anthonym has joined IRC (anthonym!~anthonym@59-100-200-214.syd.static-ipl.aapt.com.au) | |
| 22:05 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 22:06 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 22:49 | gdi2k has left IRC (gdi2k!~gdi2k@180.191.109.246, *.net *.split) | |
| 22:49 | work_alkisg has left IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr, *.net *.split) | |
| 22:49 | mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, *.net *.split) | |
| 22:52 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
| 22:58 | gdi2k has joined IRC (gdi2k!~gdi2k@180.191.109.246) | |
| 23:00 | work_alkisg has joined IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr) | |
| 23:21 | work_alkisg1 has joined IRC (work_alkisg1!~alkisg@srv1-dide.ioa.sch.gr) | |
| 23:22 | work_alkisg has left IRC (work_alkisg!~alkisg@srv1-dide.ioa.sch.gr, *.net *.split) | |
| 23:44 | Ark74 has joined IRC (Ark74!~Ark74@189.220.255.72.cable.dyn.cableonline.com.mx) | |