02:39 | snurl has left IRC (snurl!snurl@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 246 seconds) | |
02:41 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
03:38 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 258 seconds) | |
03:39 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
04:06 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
05:42 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 244 seconds) | |
05:43 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
06:00 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
09:03 | woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de) | |
10:30 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds) | |
10:49 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
11:59 | SYS64738 has joined IRC (SYS64738!~jhonny5@159.213.93.166) | |
12:06 | mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy) | |
12:07 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
12:19 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds) | |
12:21 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
12:24 | SYS64738 has left IRC (SYS64738!~jhonny5@159.213.93.166, Ping timeout: 244 seconds) | |
12:49 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds) | |
12:59 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
13:23 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Ping timeout: 250 seconds) | |
13:26 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
13:29 | fnurl has left IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com, Client Quit) | |
13:51 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
14:06 | woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection) | |
14:42 | fnurl has joined IRC (fnurl!~url@host81-154-10-106.range81-154.btcentralplus.com) | |
15:32 | josefig has joined IRC (josefig!~josefig@unaffiliated/josefig) | |
15:55 | woernie has joined IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de) | |
16:06 | xit_ has joined IRC (xit_!683390e5@gateway/web/freenode/ip.104.51.144.229) | |
16:08 | <xit_> I am working on setting up LTSP on Ubuntu 18.04 but am having trouble with the PXE booting of clients. Anyone want to try to give me some pointers?
| |
16:11 | <josefig> xit_, what kind of problems?
| |
16:15 | <xit_> I followed the instructions at http://wiki.ltsp.org/wiki/Installation/Ubuntu but I don't see instructions on configuring dnsmasq for PXE booting.
| |
16:17 | The clients connect, but then no pxelinux.0 file is found on the server.
| |
16:22 | josefig, thank you for responding, btw.
| |
16:23 | josefig, is the PXE booting setup outside the scope of the LTSP installation?
| |
16:24 | <josefig> no, it's not
| |
16:24 | there is a script that you have to download and it will set it up the DNS.
| |
16:25 | do you have 2 NICs or only 1 ?
| |
16:25 | <xit_> 2 NIC setup
| |
16:29 | Is that the 'sch-scripts' mentioned in the installation page?
| |
16:32 | <alkisg> (07:15:06 PM) xit_: I followed the instructions at http://wiki.ltsp.org/wiki/Installation/Ubuntu but I don't see instructions on configuring dnsmasq for PXE booting.
| |
16:32 | ==> the 4 commands at http://wiki.ltsp.org/wiki/Installation/Ubuntu#b.29_Dual_NIC_.28Classic_DHCP.29
| |
16:33 | <xit_> Yes, I did execute those commands. But they seem to be mostly relating to firewall settings for the interface traffic.
| |
16:34 | to allow clients to have internet access through the server
| |
16:35 | <alkisg> xit_: the first command configures pxe booting
| |
16:35 | The other 3 are for the clients to see the internet
| |
16:35 | (07:17:10 PM) xit_: The clients connect, but then no pxelinux.0 file is found on the server. ==> did you run ltsp-update-image?
| |
16:36 | http://wiki.ltsp.org/wiki/Installation/Ubuntu#a.29_Installing_LTSP_in_.22chrootless.22_.28previously_pnp.29_mode
| |
16:36 | ltsp-update-image --cleanup /
| |
16:37 | <josefig> xit_, you must check if something is blocking the internet, in my case i use ltsp for development teams and i had the issue that systemd-resolved was listening in the same port than dnsmasq
| |
16:37 | s/than/that
| |
16:37 | <alkisg> josefig: if he doesn't have pxelinux.0, he probably didn't build the image at all
| |
16:37 | I don't think it's related to networking, but to the image
| |
16:37 | <josefig> ah, you're right.
| |
16:38 | you have to create the image, also, the correct architecture.
| |
16:38 | <alkisg> xit_: in general it's best to start by doing ALL the steps, not half of them; this should work out of the box. If you need customizations, it's best to do them later on
| |
16:38 | <josefig> it happened to me the first time
| |
16:40 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
16:44 | <xit_> Alright, I will scratch what I have done and do it again.
| |
16:45 | a question though...how does building/updating the image make the 'pxelinux.0' file appear on the server? That doesn't make sense to me.
| |
16:47 | <Sleaker> xit_: hmm, I don't use dnsmasq. mine boots and grabs via tftp-hpa and I have the pxe files in the root of the tftp server
| |
16:47 | <xit_> the dnsmasq config file specifies "dhcp-boot=net:pxe,/ltsp/amd64/pxelinux.0", at the tftp-root of "/var/lib/tftpboot/", but no such file is found there.
| |
16:48 | Yes, using the tftp-hpa was the way I did this years ago, but I saw that LTSP has recommended using dnsmasq instead...see instructions
| |
16:48 | <vagrantc> ltsp-update-image may call ltsp-update-kernels
| |
16:49 | which is what copies the pxelinux* files into place
| |
16:50 | <xit_> Ah, yes...that 'ltsp-update-kernels' was missing from the instructions..but I should have remembered to execute it myself..ugh.
| |
16:51 | <vagrantc> shouldn't need to execute it manually
| |
16:52 | <alkisg> xit_: nothing is missing, many people have followed that successfully. I think you missed the ltsp-update-image part, OR it failed and you didn't see the failure
| |
16:52 | xit_: did you use ltsp-build-client, or ltsp-update-image -c /?
| |
16:52 | <xit_> Ah yes, I see my mistake now, I did neglect to run ltsp-update-image because I had skipped the step to install a desktop into the chroot.
| |
16:53 | <vagrantc> chroots are too much trouble
| |
16:53 | <alkisg> So, chroot mode... ltsp-build-client should have created pxelinux.0 for you then
| |
16:53 | <xit_> I had used the --fat-client-desktop option on the ltsp-build-client instead
| |
16:54 | <vagrantc> ltsp-build-client is basically deprecated
| |
16:54 | <alkisg> So I'm guessing that ltsp-build-client actually failed and you didn't see the error
| |
16:54 | So it never compressed the image, and never called ltsp-update-kernels
| |
16:54 | And, your chroot might be in a somewhat broken state
| |
16:55 | <xit_> when I said, chroot I was referring to the 'ltsp-chroot -m apt install ubuntu-mate-desktop' command I skipped in the instructions.
| |
16:55 | <vagrantc> why not run chrootless?
| |
16:56 | <alkisg> xit_: in that page, there's "a) Installing LTSP in "chrootless" (previously pnp) mode" and "b) Installing LTSP in "chroot" mode "
| |
16:56 | We're proposing (a), and we're thinking that you followed (b)
| |
16:56 | In (b), there's an ltsp-build-client command, which probably failed in your setup
| |
16:56 | That failure is before the ltsp-chroot step
| |
16:57 | <xit_> Oh..well, it's just that when I did this years ago, it was with chroot, I was just following the steps that seemed closest to what I was familiar with, to avoid too many learning tangents.
| |
16:57 | I will follow your advice and try it the chrootless way
| |
16:57 | <alkisg> You can also try single nic, it's easier
| |
16:57 | <vagrantc> most testing and development happens in chrootless mode these days
| |
16:57 | <alkisg> chrootless and single nic is the easiest setup
| |
16:58 | <Sleaker> hmm. might need to try and swap over to that then
| |
16:59 | <xit_> I have to go now, but you guys are all champs, you have helped me a lot, thank you all.
| |
17:42 | <mwalters> How could I check that a script is being executed on a fat client and not the server?
| |
17:43 | I guess a simple hostname check...
| |
17:43 | (I'm half thinking outloud, and half wonder if someone has something in place that definitely works)
| |
18:19 | <alkisg> mwalters: usually, $LTSP_FATCLIENT is set; also, grep init=/sbin/init-ltsp /proc/cmdline
| |
18:19 | <mwalters> Thanks!
| |
18:20 | <alkisg> In the future I think the ltsp test will be just "test -d /run/ltsp"
| |
18:20 | <mwalters> Trying to write a couple scripts for checking password age/updating on all of our LTSP boxes... ldap/freeipa just rubs me the wrong way ;)
| |
18:21 | <alkisg> mwalters: if you could write a small "how to ldap", it would help a lot for the newer ltsp
| |
18:23 | <mwalters> oh, I'm avoiding ldap!
| |
18:27 | mwalters has left IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net, Ping timeout: 264 seconds) | |
18:29 | mwalters has joined IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net) | |
18:29 | <mwalters> whoops, home server lost connection
| |
18:29 | I'm not doing ldap, trying to avoid it
| |
18:31 | Last time I tried ldap w/ linux was like 2009... we had a factory in Israel, and we needed to stand up a RHEL server to put our financial software on because of local laws... connected samba to active directory... it was a mess D:
| |
18:31 | I was the only person in the entire company with any real linux experience, so I got stuck with it :D
| |
18:32 | unfortunately... looks like password -S outputs the date the fat client was booted :D
| |
18:33 | or probably more accurately, the date the user logged into the fat client
| |
18:48 | <alkisg> mwalters: how are you planning to do this/
| |
18:48 | You can allow the users to change password graphically, with remoteapps
| |
18:49 | <mwalters> so, I have age checking working w/ a bash script right now
| |
18:49 | ltsp-remoteapps mate-terminal -- /my/script.sh
| |
18:50 | the script uses passwd -S to check age, if the age is greater than some specified value... call passwd
| |
18:50 | at least that's what I have roughed out right now
| |
18:51 | <alkisg> mate-about-me allows the users to change the password graphically
| |
18:51 | <mwalters> sprinkle in some user friendly echo messages and things, use read -s to get old/new passwd
| |
18:51 | are ideas
| |
18:51 | <alkisg> You can do the check with a remoteapps script that calls that, to avoid showing a terminal to the users
| |
18:51 | <mwalters> I need to "force" them to complete the process
| |
18:51 | <alkisg> Terminals can be scary to new linux users...
| |
18:51 | <mwalters> as part of our agency policies
| |
18:51 | no doubt
| |
18:51 | communication will be key
| |
18:51 | <alkisg> You can pop graphical programs as many times as you like, until they do change the password
| |
18:52 | <mwalters> lol
| |
18:52 | <alkisg> And even show zenity dialogs, if needed
| |
18:52 | <mwalters> yeah, I have a few scripts that use zenity already, I'm just kinda proof of concepting as well
| |
18:52 | we also have 4 different LTSP boxes... ideally I want the password to be synced between all of them
| |
18:52 | <alkisg> Btw, all that because ldm doesn't allow to change aged passwords?
| |
18:52 | <mwalters> basically
| |
18:53 | <alkisg> Eh, it'd be much more convenient to fix that then
| |
18:53 | <mwalters> Probably :)
| |
18:53 | On my end, this is driven by licensing requirements/federal law
| |
18:54 | we need to put forth at least a basic effort
| |
18:54 | due to the nature of what we do
| |
18:54 | (I'm assuming you have various privacy laws in Greece/EU regarding student privacy... similar to that)
| |
18:55 | <alkisg> I mean, if you enforced "passwords are aged after 1 month" normally on the server, and solved the "update password at login" issue, shouldn't it be the best solution?
| |
18:55 | <mwalters> yes, it would
| |
18:55 | However, I know nothing about ldm... and can muddle through some bash scripts ;)
| |
18:56 | <alkisg> ok
| |
18:56 | <mwalters> to be honest, my development experience is in webapps and things like that
| |
18:57 | (and bash scripting to support deployment/automation of that type of stuff)
| |
18:58 | so, what I'm saying is... I can get this running "good enough", nowish... versus putting an unknown quantity of time and effort into getting LDM to do what I want ;)
| |
18:59 | even in the case of LDM honoring password aging and supporting changes... I'd still need to develop the scripts to update the shadow hashes across 4 servers
| |
19:00 | <alkisg> But you wouldn't need that if you used ldap, right?
| |
19:00 | Is ldap really that hard? I was wondering if it could be the "secure default" for the next ltsp...
| |
19:00 | <mwalters> yes, but I'm a department of one... it's upfront cost, vs maintenance
| |
19:00 | another server, another OS, another thing to keep updated
| |
19:00 | <alkisg> Like `ltsp-config ldap` and it would configure everything in a sensible way
| |
19:01 | <mwalters> replace server with vm/container/whatever
| |
19:01 | <vagrantc> we've done a lot to try and avoid ldap ... maybe we should explore what it takes to use it :)
| |
19:01 | <mwalters> lol
| |
19:02 | A lot of it is not wanting YAVM ;)
| |
19:02 | <vagrantc> well, many people have explored it ... but it's been a while
| |
19:02 | <mwalters> or YAC
| |
19:02 | <alkisg> (while the unsecure default could be nfsv3+copying passwd/shadow to the clients; only after reaaaly notifying the sysadmin about the security implications)
| |
19:02 | <vagrantc> and many horror stories...
| |
19:02 | <mwalters> I don't use NSF
| |
19:02 | eer nfs
| |
19:03 | <alkisg> It's just that the ssh/sshfs thing is ltsp specific, it's not widely used
| |
19:04 | while things like "oh password aging doesn't work with lightdm" as solved rather fast
| |
19:04 | <mwalters> sure... I mean... ldap is probably the "right" solution for my problem when it comes right down to it... I'm struggling with scale... standing up a whole new service for 4 other servers just seems silly to me
| |
19:04 | <alkisg> *with lightdm and ldap
| |
19:04 | <mwalters> if I had 10 ltsp servers, I'd probably be doing it
| |
19:04 | but honestly, we'll be down to 3 in the next year I think
| |
19:12 | <alkisg> vagrantc: do you think we could rename the old source package to ltsp5, and keep it around for a few years, while the new source package that would be named ltsp, would only produce one binary package named ltsp, which would conflict with ltsp-client-core, ltsp-server, ltspfs, ldm etc etc?
| |
19:13 | So that people could still use ltsp5 for a few years, until the newer ltsp gets all the bells and whistles needed for production
| |
19:14 | <vagrantc> conceptually possible, devil in the details :)
| |
19:14 | <alkisg> Hehe, always :D
| |
19:15 | <vagrantc> should only need to conflict with ltsp-client-core and ltsp-server
| |
19:15 | though maybe we'd want it to block other things ...
| |
19:15 | having ldm and ltspfs installed should be harmless, hopefully
| |
19:16 | since they don't enable any services by default...
| |
19:16 | <alkisg> Possibly, but why not get rid of them anyway...
| |
19:16 | E.g. in the initial release we might say "it defaults to nfs3 and passwd/shadow copying which very insecure; use nfsv4/kerberos/ldap for proper security"; but that would be hard for our users, until ltsp-config is able to automatically configure all these
| |
19:16 | <vagrantc> ugh.
| |
19:16 | not real fond of this copyring around shadow.
| |
19:17 | nfs3 for homedirs?
| |
19:17 | <alkisg> Indeed; but if we're going for proper pam, it might be the quick workaround until that proper pam thing is implemented
| |
19:18 | Or, we could keep it in experimental for some time, until those things are implemented
| |
19:18 | I was reading a bit about nis; it's not much safer than just copying shadow
| |
19:19 | <vagrantc> yeah, no reason to try nis
| |
19:19 | <alkisg> So of the existing pam modules, I think ldap would work; but of course we wouldn't have sshfs then; so... nfsv4; and to protect that => kerberos
| |
19:20 | So it's getting complicated, and it needs a lot of experience in that field to define good defaults for ltsp-config
| |
19:20 | <vagrantc> right
| |
19:20 | although we should still be able to do sshfs with ldap ?
| |
19:20 | <mwalters> getting freeipa to work correctly and fully is... odd... I have mucked about with openldap in a while, though
| |
19:21 | (work correctly and fully on ubuntu)
| |
19:21 | (haven't mucked about with openldap)
| |
19:21 | <alkisg> vagrantc: we'd need a pam hook to get the ldap password and then do an ssh connection, to be able to have the sshfs home
| |
19:21 | <vagrantc> i seem to recall using samba's ldap implementation a few years back, but i wasn't the primary person working on it
| |
19:21 | <mwalters> generally ldap won't disclose the password, only if the authentication request succeeded
| |
19:22 | <vagrantc> hence libpam-sshauth ... but that's got it's own complications...
| |
19:22 | <mwalters> e.g., client makes a request to the server, the server turns it around and asks the ldap server to verify the request
| |
19:22 | <alkisg> sshfs by itself has a lot of issues (e.g. no ~/.dmrc); libpam-sshauth has a lot more
| |
19:22 | mwalters: one can get the password that the user typed to the DM, from a pam hook, without involving ldap
| |
19:23 | <vagrantc> i didn't even think ~/.dmrc was used anymore, or certainly not consistantly
| |
19:23 | <alkisg> vagrantc: there's also /var/lib/accountservice etc; but we don't have those dirs on the clients either; while ldap supposedly has solutions for such things
| |
19:23 | <mwalters> Yeah, that's where my knowledge thins out... I've done nodejs applications authing against active directory... but I haven't dealt with pam at all beyond enabling the samba module
| |
19:24 | woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection) | |
19:24 | <alkisg> E.g. maybe the last session is saved on ldap itself; dunno
| |
19:24 | <vagrantc> alkisg: out of all of this, i get the impression kerberos is hardest to get right
| |
19:25 | alkisg: needs server-side configuration per client
| |
19:25 | <mwalters> ldap also has the concept of the computer/client too... generally you register the computers themselves
| |
19:25 | <alkisg> Heh, we might need to keep ldm around for a bit then, until all these things are resolved
| |
19:25 | <mwalters> I'm not sure if that extends to kerberos, but I thought it did
| |
19:26 | <vagrantc> LDM is the part i most want to deprecate ... but also has a lot of challenges
| |
19:27 | hence ... where we've been for the last few years
| |
19:27 | i'm just not sure how much longer we'll be able to keep LDM limping along ... a lot of services are getting more and more integrated into the display manager
| |
19:28 | <mwalters> so libpam-ssh or similar would have full pam/local auth on the client, just configured to connect to the ltsp server?
| |
19:29 | s/connect/auth against the ssh server on the ltsp server
| |
19:30 | I wonder if that would be chainable... have a primary and several secondary servers...
| |
19:31 | <vagrantc> should be chainable, sure
| |
19:32 | libpam-sshauth runs locally, and connects to the server via ssh ... if you successfully connect to the configured ssh server, pam treats it as a successful login
| |
19:33 | and sets up an ssh socket that you can do other ssh actions with
| |
19:33 | (e.g. sshfs, remoteapps, etc.)
| |
19:33 | <mwalters> nice
| |
19:33 | <vagrantc> but... it's a complicated world
| |
19:33 | <mwalters> :D
| |
19:34 | <vagrantc> we've definitely had it working as a proof of concept, but in practice there are lots of quirks
| |
19:34 | <mwalters> there always are
| |
19:39 | all these threats of broken thumbs and fingers. I don't really want to touch ldm now
| |
19:39 | :D
| |
20:07 | * alkisg wonders if scotty is still using ltsp anywhere, and if he'd be willing to spend some time on libpam-sshauth, once the rest of the things are ready... | |
20:14 | <mwalters> as long as he stays away from my fingers
| |
20:18 | xit_ has left IRC (xit_!683390e5@gateway/web/freenode/ip.104.51.144.229, Quit: Page closed) | |
20:19 | <vagrantc> alkisg: haven't really gotten much response from scotty in a long while ...
| |
20:22 | <alkisg> I wonder if the *@ltsp.org mails stopped working; jim only answered in his other mail
| |
20:50 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
20:50 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |
20:53 | <josefig> I'm trying to set up the screensaver to do the auto log off once the iddle time reaches 5 minutes but i don't find to how to do it.
| |
20:54 | <vagrantc> you could write up a script with xautolock and such
| |
20:54 | did something like that years ago
| |
20:59 | <josefig> yes, i'm reading about autolock
| |
20:59 | xautolock
| |
21:11 | <alkisg> josefig: i imagine that if you e.g. set mate-screensaver-preferences to "floaters", then you can write your logout script at /usr/lib/mate-screensaver/mate-screensaver/floaters
| |
21:11 | I.e. the screensaver just calls an executable, and you can replace it with your logout script
| |
21:12 | Another way is to monitor `mate-screensaver-command -t` which tells you when screensaver got active, but that requires polling, it's not event driven
| |
21:14 | And /usr/share/applications/screensavers/gnomelogo-floaters.desktop should give you an example on how to create your own screensaver script for logout, without overriding an existing one
| |
21:17 | <quinox> Currently I use login-via-LDAP for many things including LTSP, and I'm looking forward to using LDAP + NFSv4 (no experience with Kerberos yet, but I'm gonna get some)
| |
21:17 | <alkisg> quinox: do you think some standard ldap schema could be selected as the default for ltsp users?
| |
21:18 | Or is it so varied that it should be up to the sysadmin?
| |
21:18 | <quinox> with LDAP you leave it up to the user: you allow them to configure some search query and use that
| |
21:19 | <alkisg> So we wouldn't be able to implement something like `ltsp-config ldap` for newbies?
| |
21:20 | <quinox> that would set up a new LDAP server, or configure for an existing one?
| |
21:20 | <alkisg> It would make the ltsp server an ldap server
| |
21:21 | <quinox> I think we can make that work, if the user doesn't have LDAP yet he won't care how we structure it
| |
21:21 | <alkisg> And then if the user wants to ...add a few users, what does he need to do?
| |
21:21 | What's the easiest way there?
| |
21:21 | <quinox> currently I myself use https://www.ldap-account-manager.org/lamcms/
| |
21:22 | straight from Ubuntu's package manager, but it's poorly maintained
| |
21:22 | nobody seems to test it, so with new releases I sometimes have to hack the code a bit
| |
21:22 | <alkisg> Ouch
| |
21:22 | OK maybe we could modify sch-scripts / ltsp-manager to work with ldap there
| |
21:23 | <quinox> we could add some small command line scripts for it
| |
21:23 | <alkisg> We developed that for schools, to be able to easily create new users and groups, with templates etc
| |
21:23 | Like, "create classes a1, a2, b1, b2, c1, c2, and 20 users in each of them, and shared folders for each class"
| |
21:24 | quinox: it's late here so I need to leave, but hopefully you could point me in the right direction some time in the coming months, when I'll have the first new-ltsp bits ready
| |
21:24 | Good night all :)
| |
21:24 | <quinox> sure thing
| |
21:24 | nn
| |
21:45 | <josefig> thank you, im reading about it
| |
22:04 | I did the lock on one pc, but when I tried to type the password it doesn't allow the user to login again
| |