|00:03||syrius has joined IRC (firstname.lastname@example.org)|
|00:20||doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:753d:150f:d6ec:f416)|
can anyone help me with menueditor?
ask: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least a full hour after asking a question, as not everybody constantly monitors the channel.
how do I setup custom application menus for a group of students?
the menueditor app under edubuntu just comes up blank
I've never used the menu editor
I always just edit the .desktop files in /usr/share/applications/
This question isn't really about LTSP either, by the way. You'd better seek out resources from your specific Linux distribution.
|01:11||vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)|
well ltsp is used for class room setups so I was hoping that someone might have some experience
besides no one is talking at #edubuntu
|01:18||F-GTSC has joined IRC (F-GTSCemail@example.com)|
|01:20||FGXR6 has left IRC (FGXR6firstname.lastname@example.org, Ping timeout: 244 seconds)|
well Hyperbyte maybe you can answer. How can I assigned a specific .desktop to certain users?
and which file do I need to edit?
|01:43||roue has left IRC (email@example.com, Ping timeout: 256 seconds)|
|01:43||yanu has left IRC (firstname.lastname@example.org, Ping timeout: 256 seconds)|
|01:43||roue_ has joined IRC (email@example.com)|
|01:43||yanu_ has joined IRC (firstname.lastname@example.org)|
|02:23||vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)|
|03:04||andygraybeal has joined IRC (email@example.com)|
|03:31||cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 272 seconds)|
|03:33||cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)|
|03:38||doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:753d:150f:d6ec:f416, Quit: Leaving)|
|04:03||telex has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|04:04||telex has joined IRC (email@example.com)|
doctari: We edited the /usr/share/glib-2.0/schemas files so that new users would have our default desktop.
|05:02||andygraybeal has left IRC (firstname.lastname@example.org, Quit: Ex-Chat)|
|05:40||gdi2k_ has left IRC (email@example.com, Ping timeout: 245 seconds)|
|05:53||gdi2k_ has joined IRC (firstname.lastname@example.org)|
|06:36||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|07:08||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)|
|07:54||F-GTSC has left IRC (F-GTSCemail@example.com, Ping timeout: 272 seconds)|
|08:01||doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2)|
|08:05||doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Client Quit)|
|08:07||doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2)|
|08:07||F-GTSC has joined IRC (F-GTSCfirstname.lastname@example.org)|
|08:38||vmlintu_ has joined IRC (email@example.com)|
|08:45||vmlintu has left IRC (firstname.lastname@example.org, *.net *.split)|
|08:58||ogra_ has left IRC (email@example.com, Ping timeout: 246 seconds)|
|08:58||ogra_ has joined IRC (firstname.lastname@example.org)|
|09:04||staffencasa_ has joined IRC (email@example.com)|
|09:04||staffencasa has left IRC (firstname.lastname@example.org, Ping timeout: 276 seconds)|
|09:05||stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 276 seconds)|
|09:06||stgraber has joined IRC (email@example.com)|
|09:59||stgraber has left IRC (firstname.lastname@example.org, Changing host)|
|09:59||stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)|
doctari: been weekending hard :)
|10:48||khildin has joined IRC (email@example.com)|
|11:07||vmlintu_ is now known as vmlintu|
|11:10||AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf)|
highvoltage: what are you up-to these days?
|11:27||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 264 seconds)|
|11:28||adrianorg has joined IRC (email@example.com)|
vmlintu: still doing a variety of linux/opensourcy stuff. started my own company again recently (it's so new it doesn't even have a website yet). it's still early days :)
vmlintu: and you?
highvoltage: still working with schools or something else?
highvoltage: i'm doing mostly the same as before.. just more schools and more of everything
vmlintu: working with some small universities that specialises in math and science and also companies that provide linux support to other companies
but not so much schools.
|13:21||klausade has joined IRC (firstname.lastname@example.org)|
|13:38||hugo has joined IRC (hugo!~hugo@gateway/tor-sasl/hugo)|
are you doing any development or is it more consulting/admin?
|14:23||hugo has left IRC (hugo!~hugo@gateway/tor-sasl/hugo, Quit: Leaving)|
vmlintu: development in-house, consulting externally
vmlintu: I'll hopefully have some on-line products that are in a working state in a few months, it's a lot of work to get something off the ground :)
highvoltage: cloud / saas products? Sounds interesting
|14:46||telex has left IRC (email@example.com, Remote host closed the connection)|
|14:48||telex has joined IRC (firstname.lastname@example.org)|
can anyone help with a menu question?
|15:29||khildin has left IRC (email@example.com, Ping timeout: 245 seconds)|
|15:50||vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)|
|15:53||elptuxman has joined IRC (elptuxman!46c448e4@gateway/web/freenode/ip.184.108.40.206)|
|15:56||elptuxman has left IRC (elptuxman!46c448e4@gateway/web/freenode/ip.220.127.116.11)|
|16:17||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
|16:19||adrianorg has joined IRC (email@example.com)|
|16:31||vmlintu has left IRC (firstname.lastname@example.org, Ping timeout: 265 seconds)|
|16:37||vmlintu has joined IRC (email@example.com)|
|16:56||map7 has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|17:05||freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)|
|17:16||ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)|
|17:29||ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)|
|17:34||AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf, Quit: Connection closed for inactivity)|
|17:35||ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)|
|17:48||doctari_ has joined IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2)|
|17:51||doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Ping timeout: 265 seconds)|
|18:05||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
|18:11||andygraybeal has joined IRC (email@example.com)|
doctari_: apt-get install edubuntu-menueditor python-gmenu; menueditor
And file a bug for menueditor to put python-gmenu in its dependencies (or ping mgariepy, I think he's maintaining it...)
My turn to ask something unrelated... is it possible to use kvm (virt-manager, whatever) and have a virtual machine in bridged mode *and* keep using network manager, so that one can see the network speed, IP etc in the nm settings?
we found a workaround for that part alkisg but the problem is that the archive that men-editor create has no conf files in it just a directory structure
alkisg: what network speed you'd want to see?
doctari_: people worked with that previously, e.g. in 10.04, I have never used it myself, but do you mean that you haven't found a good tutorial, or that it is now broken?
vmlintu: in the network-manager applet, for the connection to show its status, for the user to be able to go to its properties and see 100mbps or ip, mask...
I.e. I don't want to use /etc/network/interfaces....
alkisg: ah, I first understood that you want to use network-manager on the kvm guest and see the network status from there
No no I just think that all that bridging doesn't allow network-manager to manage the connection, and it's not able to show its status...
while e.g. vbox uses injection instead of bridging or something like that, and it's completely transparent for the user, no host network setup necessary...
I've seen people writing that network-manager is quite buggy when used with libvirt and bridging, but it's possible to get it working..
Hrm... virt-manager also managed to break dnsmasq, it put a "bind-interfaces" directive which doesn't allow dnsmasq to function properly with its default "enable dns server" setting...
I had to edit that virt-manager file and change it to bind-dynamic
|18:42||* vagrantc waves to alkisg|
alkisg: i use network manager and have virtual machines in bridged mode ... but i usually use the bridges configured by libvirt
alkisg: it should be able to attach to any existing bridge though
i've done that before too
vagrantc: so libvirt sets up bridges that you can use along with network-manager?
E.g. have a normal dynamic ip with network-manager, and have the VM in bridged mode there?
In `ip a`, I have: virbr0 192.168.122.1/24
In virt-manager, "bridged mode" is not enabled, it's gray...
|18:48||doctari_ has left IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2, Quit: Leaving)|
|18:48||doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2)|
|18:49||* alkisg tells himself to RTFM...|
|18:53||andygraybeal has left IRC (firstname.lastname@example.org, Ping timeout: 245 seconds)|
alkisg: i simply use a bridge, not sure what bridged mode is :)
I can't find what to do in the gui in order to use bridged mode
alkisg: you can use macvtap interfaces which i think is similar to what you're talking about virtualbox using
But without using command line or configuration files, just GUIs
alkisg: at least with virt-manager ... when viewing the virtual machine hardware, you can select the NIC, and select macvtap interface from the drop-down...
alkisg: view -> details, select NIC, network source drop-down
Yup thanks I see it now, it wasn't there in the create vm wizard
alkisg: might not be
alkisg: i don't tend to use macvtap because the host network becomes inaccessible, and i frequently have squid-deb-proxy or some other caching proxy running on the host
Ouch, the host net become inaccessible?!
the host networking continues to function, but the client can't reach the host
that isn't the case with virtualbox?
In vbox, the host is e.g. 192.168.1.10 and the vm at 192.168.1.11 and they communicate like normal machines
with ethernet packets, ip packets, whatever
|19:06||andygraybeal has joined IRC (email@example.com)|
|19:06||* vagrantc has been struggling with resolving https://bugs.debian.org/767764 and https://bugs.launchpad.net/ltsp/+bug/1072711 in a cleaner way|
And the user doesn't need to specify the IP anywhere, so it'll work in whatever host subnet...
|19:07||* vagrantc wonders if network-manager can configure a bridge that libvirt could then hook into|
the default in libvirt has a NATted bridge
vagrantc: so LIBGL_ALWAYS_INDIRECT is causing more issues?
macvtap also doesn't tend to work on wireless
alkisg: seems to be
I don't know why we put that there... I think stgraber put it to enable some software gl, but why would we need to specify it, why isn't it autodetected?
alkisg: and the init-ltsp.d hook should've gone in LDM ... :(
alkisg: dunno. i'm tempted to disable all the LIBGL_ALWAYS_INDIRECT code
alkisg: and make a flag to enable it or something
I never got it to do anything useful, I only had to disable it in a few cases myself too
Should we drop it until we find a use case where it actually helps?
I think there's a bug report in launchpad where stgraber says he managed to get unity working slowly with that, but I never did get unity working (not that I tried much...)
i'm inclined to drop it entirely, or make it an explicitly enabled feature
automake is a nightmare
to add one file you have to touch 4 different files or something
or i'm not grasping ldm's autofoo correctly.
If you let me reimplement ldm in shell, we wouldn't need automake :P
ok, figured out the automake bits enough to install that awful "rm .../nouveau" hack
vagrantc: doesn't init-ltsp.d/50-opengl remove nouveau already? http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2447
alkisg: yes, but it belongs in the ldm package.
alkisg: and i'm wondering if it shouldn't just go in the screen script instead.
would be more self-contained, only applies when LDM_DIRECTX is there
alkisg: the launchpad bug with the noveau hack ... does that happen regardless of LIBGL_ALWAYS_INDIRECT=true/false ?
seems like rather than removing the driver, not setting LDM_DIRECTX would be cleaner
er, not setting LIBGL_ALWAYS_INDIRECT
vagrantc: if we remove LIBGL_ALWAYS_INDIRECT, we have no issues
I don't understand what's the issue in the debian bug tracker though (haven't read all of it)
If nouveau is rm'ed, why do they experience the bug?
But I do vote for dropping the whole LIBGL_ALWAYS_INDIRECT code until we have an actual, recent use case where it helps
alkisg: basically, the idea of removing a driver from the filesystem seems like a very ugly hack ... so i'm wondering if we can get rid of both problems by addressing the LIBGL_ALWAYS_INDIRECT issue?
Please do, remove both of those hacks
the less agressive option is to make them conditional
and default to off
We have CLIENT_ENV for that
How much more conditional?
if someone wants it, they can easily add it to CLIENT_ENV ?
sounds good to me.
There's a lot of mesa options to put them all as conditionals... http://www.mesa3d.org/envvars.html
Yes CLIENT_ENV works fine
|19:34||* vagrantc wonders if this is too invasive for jessie|
it's really ugly overall
|19:34||* alkisg pats vagrantc in the shoulder and says "go for it"|
|19:42||* vagrantc is also tempted to drop the 16-bit color by default feature|
due to https://bugs.debian.org/705143 and the likes
vagrantc: that's a cinnamon bug, not a 16-color bug
I think workarounds are good when we actually work around bugs from other packages
16bit means 2 times faster graphics, it's too significant to drop it when it works...
alkisg: but requiring workarounds for several of the most common desktop environments seems like a loosing battle.
It always works when there's no compositing, right?
And, compositing managers no longer care about remote x, right?
cinnamon, gnome3, gnome-flashback ... if i remember correctly
gnome-flashback doesn't have problems with 16 bit
|19:48||* vagrantc will try again|
cinnammon and gnome3 don't work over the network
I've never seen cinnammon-2d, is it still being developed?
I did hear about problems with compiz and some 16bit cards though
(gnome-flashback with compiz enabled)
alkisg: so, just to be clear, the noveau driver removal hack is really just a workaround for when LIBGL_ALWAYS_INDIRECT=true ?
Yes, I didn't know how much stgraber wanted that, and instead of completely removing it I decided to only disable it in the case that I saw it was causing problems
err, instead of removing it, I removed nouveau*
following some advice from #nouveau or something...
So, apparently, cinnamon does have a 2d variant in jessie... https://packages.debian.org/jessie/all/cinnamon-common/filelist
|19:58||* alkisg needs to try that, if it works as advertised it might be a good alternative to gnome-flashback|
|20:01||* alkisg adds the cinnamon ppa for 14.04...|
Having a normal gnome3 desktop stack with a 2d mint-like menu is all we need... hopefully cinnamon-2d is exactly that :)
bb in 2'..
|20:08||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|20:09||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
Errr cinnamon-2d says "software rendering", and it's very slow *and* has severe drawing issues locally on my dual core 2.2 ghz pc...
So nope it's not ltsp's fault :)
|20:21||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)|
|20:21||alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)|
alkisg: i was also thinking more about how to configure ipxe with a bootscript earlier, and just using http (and ideally, https boot)
figuring out some way to store https certificate information on the boot media would allow for a secured network boot, only needing to update the local media on certificate change
and then you could actually verify the rootfs hash
by storing some verification data in the initramfs
|20:56||doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2, Ping timeout: 245 seconds)|
vagrantc: we can skip pxelinux completely with undionly.kpxe
I tried it, it works fine, it even supports detection for pae, 64bit etc
So we won't be needing ifcpu64 either
And it supports uefi too, albeit with a few issues, but a lot better than syslinux
for uefi, grub is the only one that has good support
So if you agree too, we can work on replacing pxelinux with ipxe/undionly...
alkisg: it's sounding good!
We won't be needing tftp at all then, just ltspd=http(s)
would be a big break from prior ltsp versions
(and if we could implement just the proxydhcp part in ltspd, which should be really small, we could skip dnsmasq too...)
for some reason that seems riskier to me
It's not very significant, I don't mind about that, it would just be more pnp :)
(proxydhcp is just 1 packet)
not the whole dhcp server?
No, of course not
If someone wants a real dhcp he'd have to use dnsmasq/isc-dhcp
i know there are basically out-of-the-box python http server implementations, but rewriting a dhcp server would seem like too much :)
I don't even want to implement a tftp server :D
I think someone implemented proxydhcp in java in 20 lines or so
|21:05||* vagrantc wonders how hard it would be to boot old chroots with the new stuff, too|
back before we asked dnsmasq to implement it...
I don't think python has a simpletftpserver
So we'd have to use dnsmasq/tftpd and ltsp-update-kernels etc there
Would tftpless booting happen through grub that loads something locally?
Client loads either pxe + (tft/undionly.kpxe), or ipxe
at that point we have http(s) support
So sorry I forgot the pxe part, we'd still need tftpd there
Just to get the undionly.kpxe
ok.. so it'd be same as pxe + lpxelinux.0 + http
yes, ipxe instead of pxelinux
Gives more scripting support, and uefi support
And https, sanboot, etc
alkisg: i'm thinking we need a systematic way to log some of these new feature ideas... might make it easier to actually move forward than just chatting on irc when ideas come to us :)
|21:11||* alkisg never had problems with which of the ideas to work on, only with finding the time to do that... :)|
We do have some todo page in the wiki, don't we?
if you are planning big changes, laptop support is something that requires a big rewrite
vmlintu: I think you should start upstreaming your code :)
alkisg: I've done a few excercises on that, but basically it rips out 98% of ltsp code and replaces it with something new
vmlintu: I have no problem with that :D
I've been thinking of starting something from scratch so many times that I lost count
As long as it's well designed...
meh. i've lost my wiki.ltsp.org credentials again
vmlintu: what do you mean by laptop support?
vagrantc: most of our new client devices are now laptops. They boot locally using grub + squashfs image copied to a local partition.
It's the same image as thin/fat clients and ltsp servers use
ltsp with a local install?
The image is updated by downloading an rdiff and patching old image to create a new one
basically could boot to ltsp over the network and then install it to the local media?
vagrantc: yes, that's how it works
yeah, that sounds worth upstreaming
vagrantc: I've been using a system like that on my main laptop for the past 1,5 years now..
vmlintu: rdiff with squashfs?
Isn't that ...like downloading the whole file again?
I mean, squashfs == compression, and compression ==> no sensible rdiff..
no.. it's quite manageable actually
alkisg: compression doesn't always break binary diffs
To get a small diff, you'd need an uncompressed file system like ext4, right?
take "gzip --rsyncable" for example
the compressed image is now 9.5gb and weekly diffs are often 300mb
although, depending on the image size, it might just be simpler to rewrite the image...
I think I've seen 1gb diffs too, but for us that's not a problem
vmlintu: so what parts of LTSP are you using?
vmlintu: are you using the "add files to squashfs" capability of squashfs, or are you just using binary diff between the old and the new 9 gb images?
alkisg: they are all new images
vagrantc: I think ltspfs is only part that we haven't modified. There's no ldm and we don't use lts.conf anymore as it's replaced by ldap based configuration.
vagrantc: thin/fat client concepts are still ltsp
vagrantc: ltsp servers are netboot devices themselves
We do plan on ditching ldm so that's not a problem
Are you using ltsp-build-client?
heh. with LDM_DIRECTX=true, LTSP_FATCLIENT=false and LIBGL_ALWAYS_INDIRECT=true, cinnamon2d just hangs for me, but cinnamon issues an error and falls back to software rendering, but works.
Are you using init-ltsp.d and other stuff?
vmlintu: i've long dreamed of network booted network booting servers :)
recursive network boot
There are people that do that with plain ltsp...
vagrantc: we have now bootservers that have basically just tftpd+dhcpd+nfsd+something else
oh, i'm probably being hit by the 16-bit color depth issues...
|21:27||* vagrantc notes that the 16-bit color depth also makes all LDM themes look grainy|
That's a problem with ldm
kerberos is currently the only supported authentication method
|21:32||austrian_ has left IRC (firstname.lastname@example.org, Ping timeout: 246 seconds)|
vmlintu: are you using some gui for user management?
alkisg: if you want to see how it works, I can setup a demo puavo organisation for you.. maybe it'd explain it better..
It feels silly that we both develop such tools...
vmlintu: sounds good, thanks, but not yet, I'm not yet in the phase of implementing new features in ltsp
alkisg: I mean the gui part, if you want to see it
Yes, I understood, but I'll forget what I saw, when after a few months I'll want to work on these things
vmlintu: which DE are you using?
(so, about the puavo demo organization, I'll ask you in a few months when I'll want to start working on such things, thank you...)
alkisg: gnome3 flashback
|21:41||austrian_ has joined IRC (email@example.com)|
We agree there! :)
I think stabilizing gnome-flashback is very significant... more so than ltsp advancements
alkisg: what ltsp means is the next big question, I think
when running an image locally on a laptop there's no terminal server anywhere anymore..
I would go for "liveboot" but debian already had that :)
And, liveboot has more code that I'd like to reuse than ltsp...
|21:53||* alkisg ==> pumpkin|
|21:53||alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)|
vmlintu: essentially just remote homedirs and authentication at that point?
vagrantc: for laptops we are mostly using local homedirs as they are true laptops that can be anywhere
vagrantc: homedir access to server is done separately
After we switched laptops from local installations managed by puppet to using the same image as thin/fat clients, reliability went through the roof
e.g. we updated laptops from quantal -> trusty just by updating the image on the laptops' harddrives. No need to run apt-get or anything
so there really isn't much of anything ltsp on it
and the biggest benefit for laptops and ltsp servers is that we can rollback the whole system to old version if some update fails because of a broken ubuntu update or something similar
vagrantc: if you think ltsp as a terminal server project, then no. If you think ltsp as a way to create running desktop images, then laptops are all about that
But when taking ldm and ltspfs out of the picture, ltsp really isn't much of code, but more of a concept and a mindset, I think
i've mostly thought of LTSP as a network booting infrastructure
but i've definitely thought about using LTSP codebase to do the sorts of things you've apparently implemented :)
but it has tons of code to configure X and audio
And the laptops do need that code as much as fatclients do
|22:09||* vagrantc thought we gutted most of the X configuration code|
X mostly configures itself these days.
maybe tons was a bit too much ;)
there's xrandr code etc
so you're using a screen script to start the display manager?
lightdm is started by upstart
then it doesn't use the LTSP Xrandr code
vmlintu: you've really piqued my curiosity! :)
vagrantc: it's easy to configure lightdm to run scripts to call xrandr when it starts
vagrantc: here's the lightdm.conf we are using: https://github.com/opinsys/puavo-ltsp/blob/master/client/templates/etc/lightdm/lightdm.conf
vmlintu: you hard-code 16-bit color for a local system?
oh, i see, you have a conditional in there
|22:16||* vagrantc didn't know lightdm supported conditionals|
that bodes well for lightdm+libpam-sshauth
the xrandr code is now actually changed to support gnome's screen setting tool
that's a ruby template, not real lightdm.conf
it looks like you've got all the features in there we need, though
the display-setup-script is what runs xrandr and such?
tweaking the sessions-directory would also be useful
but I need to get some sleep.. I can go over the features in more detail if you want
later I mean
|22:25||* vagrantc eyes up https://tracker.debian.org/pkg/fts and https://github.com/gonicus/fts|
vmlintu: night! thanks for all the ideas!
|22:36||telex has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|22:38||telex has joined IRC (email@example.com)|
|23:12||khildin has joined IRC (firstname.lastname@example.org)|
|23:13||khildin has left IRC (email@example.com, Read error: Connection reset by peer)|
|23:19||oh has joined IRC (oh!bc78c335@gateway/web/freenode/ip.18.104.22.168)|
|23:20||oh is now known as Guest49254|
hello, can someone point me somewhere on how to use nodm on ltsp thin client?
why not just use LDM's autologin features?
Guest49254: what's your goal? what kind of setup?
I am trying to make a kiosk with persistant home directory, but currently I am far from it..
simplest thing would be to use LDM fatclient with autologin
unless you want the persistent homedir somewhere other than the server...
no, on server would be just fine. Alright, my first problem would be with autologin then, when I chroot into the environment on server and make a new user with password there, it's not recognized on client
i am always getting errors in auth.log that it's unknown user
you don't typically add users in the chroot
normally, you just add users on the server and they authenticate on the server.
|23:59||ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)|