02:32 | <sbalneav> alkisg: ping
| |
05:05 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds) | |
05:36 | ricotz has joined IRC (ricotz!~ricotz@p5B2A97D8.dip0.t-ipconnect.de) | |
05:36 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
06:06 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds) | |
06:07 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
06:56 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c) | |
07:01 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
07:15 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 264 seconds) | |
07:25 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c) | |
14:54 | <alkisg> sbalneav: eh, that was 5:32 in the morning, not too likely for me to pong :)
| |
14:55 | adrianorg has left IRC (adrianorg!~adrianorg@189.58.225.235.dynamic.adsl.gvt.net.br, Ping timeout: 244 seconds) | |
14:55 | <sbalneav> alkisg: Quick questionfor you
| |
14:55 | for libpam-external
| |
14:56 | right now, the "command" is a single character
| |
14:56 | <alkisg> Sure, shoot! Although I'd imagine I'd be asking the questions to you... :D
| |
14:56 | <sbalneav> So > for a username prompt
| |
14:56 | : for a password prompt.
| |
14:56 | etc
| |
14:56 | So if you want a password prompt, you'll do:
| |
14:56 | :Password:
| |
14:57 | Or
| |
14:57 | adrianorg has joined IRC (adrianorg!~adrianorg@189.58.226.223.dynamic.adsl.gvt.net.br) | |
14:57 | <sbalneav> >Username:
| |
14:57 | Now, would it be more intuitive, in your opinion, if I changed those from single characters, into simple commands:
| |
14:57 | pwprompt Password:
| |
14:57 | userprompt Username:
| |
14:58 | etc.
| |
14:58 | <alkisg> I'm missing some background so I can't yet imagine exactly how this works
| |
14:58 | <sbalneav> OK
| |
14:58 | So pam-external calls an external script.
| |
14:58 | <alkisg> Where is libpam-external's branch?
| |
14:59 | <sbalneav> launchpad.net/~ltsp-upstream/+git/libpam-external
| |
14:59 | So, pam-external's just a shim: it calls an external program that actually drives the pam authentication process
| |
14:59 | <alkisg> The plan is for that to "replace" libpam-sshauth, right?
| |
15:00 | along with the external script
| |
15:00 | <sbalneav> Right.
| |
15:00 | libpam-external is like a "pam toolkit"
| |
15:00 | You tell it to do things like prompt the user, get a password, etc.
| |
15:00 | <alkisg> I'm also missing a few bits on how pam works. This will only work for auth, to authenticate users and maybe passwd, to let them change their password, but it won't support listing users etc?
| |
15:01 | <sbalneav> Right, that's what the companion "libnss-external" is for
| |
15:01 | <alkisg> Nice
| |
15:01 | So e.g. lightdm wants to authenticate a user
| |
15:01 | It shows a prompt, gets a username, calls the pam stack
| |
15:01 | <sbalneav> right
| |
15:02 | <alkisg> You have a hook there and you get what, just the username at that point, or the combination username/password?
| |
15:02 | <sbalneav> Well, the way pam works is this.
| |
15:02 | You call pam
| |
15:02 | Pam says "ask for a username"
| |
15:02 | lightdm asks for a username
| |
15:02 | passes result back to pam
| |
15:02 | pam asks for password
| |
15:02 | lightdm prompts for password
| |
15:03 | returns result to pam
| |
15:03 | pam does the authentication
| |
15:03 | off you go.
| |
15:03 | what *pam-external* does, is hand off those bits to an external script.
| |
15:04 | the *script* says (on stdout) "prompt for a username"
| |
15:04 | pam-external translates this into a pam call
| |
15:04 | and so on, up to lightdm
| |
15:04 | <alkisg> static int usernameprompt_cb (pam_handle_t *pamh, char **output, char *input); ==> is that a standarized name by pam, or did you name it that way yourself?
| |
15:04 | <sbalneav> That's my callbac
| |
15:05 | *it* calls pam_get_user
| |
15:05 | See, I read stdin
| |
15:05 | get an "instruction"
| |
15:05 | Call the appropriate pam call
| |
15:05 | get the result
| |
15:05 | put it on stdout
| |
15:06 | So the script just talks on stdin and stdout
| |
15:06 | and it *drives* the pam authentication process
| |
15:06 | So right now, the "instructions" are single characters
| |
15:07 | What I'm wondering is: would it be clearer to actually make the instructions strings
| |
15:07 | i.e. instead of ':' for "get a password", it's "pwprompt" or whatever
| |
15:07 | <alkisg> I'm trying to see if you're mapping from some standarized pam command names to stdio, then yeah it would indeed make sense to use those #defines in stdio as well
| |
15:08 | <sbalneav> I suppose I could use something close to the pam names
| |
15:08 | pam_get_user
| |
15:08 | pam_get_user Username:
| |
15:08 | <alkisg> (06:02:37 μμ) sbalneav: Pam says "ask for a username" ==> is that a special function? or a const string parameter?
| |
15:09 | <sbalneav> That's a special function.
| |
15:09 | It either pulls the pam username from the stack if it's already defined, or prompts the user for it.
| |
15:09 | That's how pam modules "stack"
| |
15:10 | I.e. once the first modules prompted for a username, the resto of the modules in the stack don't need to anymore.
| |
15:10 | <alkisg> So lightdm would prompt for a username, not the script. The script would just get a ... notification?
| |
15:11 | <sbalneav> No, the script prompts for the username
| |
15:11 | have a look at:
| |
15:11 | launchpad.net/~ltsp-upstream/+git/pamexternal-sshauth for an example script
| |
15:12 | but now that I think about it, you're right, I should probably make the instructions close to the pam library names as I can.
| |
15:12 | easy to change
| |
15:13 | <alkisg> if prompt[1]: print '>' + prompt[0] else: print ':' + prompt[0]
| |
15:13 | This is hard to read, yeah
| |
15:14 | <sbalneav> right.
| |
15:14 | ok, human readable names it is :D
| |
15:14 | I'm easily convinced :D
| |
15:14 | <alkisg> But I still haven't understood the whole thing...
| |
15:15 | Can we start the events from lightdm again?
| |
15:15 | I haven't understood at all when the ssh call comes in (paramiko, I assume)
| |
15:16 | <sbalneav> Right, paramiko's the python ssh library
| |
15:16 | ok
| |
15:16 | lightdm starts
| |
15:16 | calls pam_start
| |
15:16 | pam_start loads pam_external
| |
15:17 | pam_external spawns sshauth script
| |
15:17 | <alkisg> (thanks, this is exactly how I wanted to hear it in order to get a better understanding of pam...)
| |
15:17 | <sbalneav> script prompts "Username?"
| |
15:17 | pam_external calls pam_get_user
| |
15:17 | pam_get_user asks lightdm to prompt for username
| |
15:17 | lightdm prompts
| |
15:17 | user enters
| |
15:18 | lightdm hands username to pam
| |
15:18 | pam hands username to pam_external
| |
15:18 | pam_external prints username on stdout
| |
15:18 | script reads it. Now script has username
| |
15:18 | Fenuks has joined IRC (Fenuks!~Fenuks@95.191.242.41) | |
15:18 | <sbalneav> script prompts: "Password?"
| |
15:19 | pam_external reads it on stdin
| |
15:19 | translates to pam call
| |
15:19 | pam tells lightm to prompt for password
| |
15:19 | lightdm prompts "Password?"
| |
15:19 | user enters
| |
15:19 | passes back to pam
| |
15:19 | pam -> pam_external
| |
15:19 | prints on stdout
| |
15:19 | script reads it
| |
15:20 | now script has username, password
| |
15:20 | does auth
| |
15:20 | auth works
| |
15:20 | script prints PAM_SUCCESS
| |
15:20 | passes back to pam_external
| |
15:20 | <alkisg> Ah, you're translating a big part of the pam stack to stdio conversation... wouldn't it be easier to e.g. use some python pam bindings directly? I imagine python does have pam bindings...
| |
15:20 | <sbalneav> It does
| |
15:20 | but now you're limited to writing in python.
| |
15:21 | pam external allows you to write in ANYTHING
| |
15:21 | C
| |
15:21 | Python
| |
15:21 | Perl
| |
15:21 | Shell script
| |
15:21 | whatever
| |
15:21 | since you conduct the conversation via text on stdin/stdout
| |
15:22 | <alkisg> True, but we mostly care about implementing the ssh part, right? Do you think we'll be using it to implement other methods of authentication as well?
| |
15:22 | <sbalneav> Right, *we* only care about the ssh part. But if I'm gonna write a tool... I want to write a general purpose one :D
| |
15:23 | <alkisg> If python (or even your initial .c code) can handle the ssh authentication, do you think it makes sense to have a bigger layer/library there?
| |
15:23 | For example, ldm was rewritten to support plugins
| |
15:23 | That reduced the code readability though
| |
15:23 | <sbalneav> Well, pam_external's actually pretty small. It's less than 1000 lines of code.
| |
15:24 | And it's a general purpose shim, so all the authentication work is done in the script.
| |
15:24 | <alkisg> E.g. suppose we want to implement the ssh auth/passwd/nss part. How long would that be (a) with python bindings, and (b) with libpam_external?
| |
15:24 | <sbalneav> Roughly equal
| |
15:24 | BUT
| |
15:25 | <alkisg> So we just have an additional 1000 lines to learn, and a new "protocol"...
| |
15:25 | <sbalneav> The advantage is, you can TEST your pam-external scripts just at the command line, they don't have to run under pam
| |
15:25 | since they just talk via stdin/out
| |
15:25 | so, you want to test: it says "Username:?" you just *type* the username
| |
15:26 | with pam python bindings you'd *have* to test them via running lightdm in a test window, or something.
| |
15:26 | <alkisg> ...or a fake stdio-dm, yeah
| |
15:27 | Some hundreds lines would be needed to implement that as well
| |
15:27 | <sbalneav> You can simply take that python script and just run it as is.
| |
15:28 | ssh_authenticate.py host=blah
| |
15:28 | It'll say ")Username:"
| |
15:28 | You say "alkisg"
| |
15:28 | It'll say ":Password:"
| |
15:28 | you say "i'm too sexy for my clothes" or whatever :D
| |
15:28 | Then it'll do the auth
| |
15:28 | <alkisg> I can't really give good advice on that, the pam callbacks haven't yet settled down in my brain... :)
| |
15:29 | I need to read more about it and maybe even code a little to grasp the whole concept
| |
15:29 | * quinox tests PAM stuff from the command line with http://pamtester.sourceforge.net/ | |
15:29 | <sbalneav> So do I, quinox
| |
15:29 | But with this scheme, you don't even need that :D
| |
15:30 | <alkisg> sbalneav: me and vagrantc and Phantomas will probably make it to debconf16, so do have some things ready till then, for us to play with... and hopefully integrate them to ltsp
| |
15:31 | <sbalneav> That's my goal
| |
15:31 | I'm workin' like a madman :D
| |
15:31 | * alkisg needs to help his daughter with her studies, bb for now guys! | |
15:31 | <sbalneav> Cheers
| |
15:35 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Ping timeout: 260 seconds) | |
15:35 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Quit: No Ping reply in 180 seconds.) | |
15:37 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c) | |
15:40 | Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack) | |
16:05 | ltsp_fan has joined IRC (ltsp_fan!29320220@gateway/web/freenode/ip.41.50.2.32) | |
16:07 | <ltsp_fan> Hi everybody, thanks for your all your help: I am helping out at a school that has 20 RPI loaded with berryterminal connecting to an edubuntu server
| |
16:07 | everything worked in 2014
| |
16:07 | then this year I did a fresh install of edubuntu 12.04.05 and now sound is choppy
| |
16:08 | vlc says pulseaudio is to blame
| |
16:08 | any suggestions?
| |
16:09 | then my second question is: I came across UbuntuLTSP/RaspberryPi (I think by alkisg), but that requires RPI2 or higher which we don't have
| |
16:10 | <sbalneav> ltsp_fan: https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Choppy.2Fdistorted_sound
| |
16:11 | <ltsp_fan> "https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi" mentions Berryterminal and Pinet as alternatives, is Pinet better?
| |
16:12 | <sbalneav> Define "better"
| |
16:12 | <alkisg> (07:08:00 μμ) ltsp_fan: then this year I did a fresh install of edubuntu 12.04.05 and now sound is choppy => how did you install it, with berryterminal?
| |
16:12 | <ltsp_fan> edubuntu 12.04.05 is on the server, the I left the rpi's as they were
| |
16:13 | apparently berryterminal has no updates since 2013
| |
16:13 | <alkisg> Yeah
| |
16:13 | !raspberrypi
| |
16:13 | <ltsp> raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
| |
16:13 | <alkisg> So, rpi1 requires special compilation for arm6
| |
16:13 | And most distros don't bother with that
| |
16:14 | That's what raspbian did, it provided a repository for armv6
| |
16:14 | So for rpi1, you need something raspbian based
| |
16:14 | <ltsp_fan> berryterminal worked
| |
16:14 | <alkisg> Yup, arm6 too, but unmaintained
| |
16:14 | While raspbian is maintained
| |
16:15 | Normal debian and ubuntu support arm7, i.e. rpi2 and rpi3
| |
16:15 | So the best route is to build a raspbian chroot, i.e. (#2) or (#3)
| |
16:15 | The server works fine with either ubuntu or debian, you choice
| |
16:15 | <ltsp_fan> my first question, I suppose is, how come everything worked before and now it doesn't, what about 12.04.05 is different from 12.04.x that made things stop working
| |
16:16 | <alkisg> I don't think you'll find anyone willing to help with kernel/sound issues on a deprecated (berryterminal ) software, when there is other software (raspbian) that is maintained
| |
16:16 | <ltsp_fan> @sbalneav, i did play around with pulseaudio settings
| |
16:17 | sure, that's fair, I was just curious. So on to my second question
| |
16:17 | <sbalneav> ltsp_fan: What did you do?
| |
16:17 | <alkisg> With raspbian you'll even get the new KMS driver, which in time will even get 3D acceleration etc. Maintained...
| |
16:19 | (one reason why it could have failed, is that the old installation was 12.04.1, i.e. kernel 3.2, while 12.04.5 comes with kernel 3.13)
| |
16:19 | <ltsp_fan> @sbalneav I lowered the sampling rate and it did help, but not perfectly, it was just strange how things worked well before and then stopped working, I realise that 12.04.5 must be very different from versions before.
| |
16:19 | ahh exactly
| |
16:20 | so a newer kernel can make some things worse ? it seems.
| |
16:20 | <sbalneav> Of course :D
| |
16:20 | <alkisg> Sure, it can break graphics, cpu, file system, all of it
| |
16:20 | <sbalneav> Kernels keep getting bigger
| |
16:20 | <alkisg> It's called "regressions" :)
| |
16:20 | <sbalneav> So do all the user programs :D
| |
16:20 | If your cpu stays the same..... performance will suffer :D
| |
16:20 | <ltsp_fan> man that's sad, I thought the point of an LTS release is to avoid this
| |
16:21 | <alkisg> 3.2 wouldn't boot with new hardware
| |
16:21 | <sbalneav> You moved from one LTS release to another
| |
16:21 | <alkisg> That's the point of LTS releases, to provide new kernels for new hardware
| |
16:21 | <sbalneav> It's still an upgrade.
| |
16:21 | <alkisg> You can just install the 3.2 kernel on 12.04.5, it's easy
| |
16:21 | <ltsp_fan> ahhh, I didn't know that
| |
16:21 | <alkisg> *if* that's the issue...
| |
16:21 | The best route is to install 16.04 on the server, and a raspbian chroot
| |
16:22 | That's a maintained combination :)
| |
16:22 | <ltsp_fan> ok thank you, you have both satisfied my curiosity, so onto the better solution
| |
16:22 | ok so raspbian chroot
| |
16:22 | is that what pinet does?
| |
16:23 | <alkisg> pinet is about raspbian chroot on ubuntu server, yes
| |
16:23 | <ltsp_fan> great!
| |
16:24 | <alkisg> It basically uses ltsp, but has a script for autoconfiguration
| |
16:25 | <ltsp_fan> ok, we're honing in on a solution
| |
16:25 | <alkisg> I don't know more about it, I stopped caring when I read its users say "ltsp is dead, long live pinet" in some forums, which is totally inaccurate since pinet is just a couple of scripts on top of ltsp. :)
| |
16:26 | <ltsp_fan> those are very ungrateful users, I'm sure it is not from the pinet author.
| |
16:27 | <alkisg> I'm sure too, we spend months helping him implement it :)
| |
16:28 | <ltsp_fan> my final decision I suppose is should I try raise funds to get newer pi's and use UbuntuLTSP/RaspberryPi or will pinet produce the same acceptable (though mediocre) experience I had before in 2014?
| |
16:28 | with the current 20 rpi's
| |
16:29 | <alkisg> What are your server specs?
| |
16:29 | Exact cpu model and ram?
| |
16:30 | rpi3's can almost work as ltsp fat clients, which makes a big difference from thin clients as they run things locally with their own cpu/ram
| |
16:30 | But in general, core i3's are the best clients :D
| |
16:30 | <ltsp_fan> i7 3.6 Ghz 16Gb Ram
| |
16:30 | a good server
| |
16:31 | <alkisg> OK that server with 2-3 bonded gigabit NICs and a good switch should give a good experience for *thin* clients that rpi's are
| |
16:31 | !flash
| |
16:31 | <ltsp> flash: Yes, flash sucks. An HD full screen 30 fps video needs 2.5 Gbps bandwidth (1920×1080×4×30)! Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like http://linterna-magica.nongnu.org
| |
16:31 | <alkisg> You'll never be able to properly watch full screen youtube etc
| |
16:31 | Thin clients have limitations
| |
16:31 | <ltsp_fan> sure our main use case was reduced quality ka-lite videos
| |
16:31 | <alkisg> So yeah go for the 16.04 server / raspbian chroot for now, and when you upgrade, try to get diskless *fat* clients
| |
16:32 | Even window scrolling may require a lot of bandwidth, it's still pixels
| |
16:32 | That's what fat clients avoid
| |
16:33 | <ltsp_fan> ok thank's that's solid advice
| |
16:33 | <alkisg> You're welcome :)
| |
16:34 | <ltsp_fan> btw can't the rpi1's function as fat clients considering they have a dedicated video decoding chip and ephiphany web browser supports it?
| |
16:35 | <alkisg> I usually check CPU scores in cpubenchmark.net to decide which clients are good and which are not
| |
16:35 | robb_nl has joined IRC (robb_nl!~robb_nl@62.235.103.52) | |
16:35 | <alkisg> I advice people to get new clients with at least 2000 score
| |
16:35 | 1000 score is acceptable fat client
| |
16:35 | rpi1 would score about 100
| |
16:36 | Your i7 server would score around 5000, depending on the model
| |
16:36 | So it's faster than all of your pis together
| |
16:36 | <ltsp_fan> wow!
| |
16:37 | oh but again doesn't the video decoding change this calculation?
| |
16:37 | <alkisg> For starters, you won't be able to scroll a window since it doesn't involve decoding :)
| |
16:38 | There are a couple of applications that support decoding video, e.g. omxplayer and patched vlc
| |
16:38 | But in general I doubt any browser can ask the vc4 of rpi to decode e.g. youtube flash or html5 content
| |
16:39 | <ltsp_fan> apparently epiphany does
| |
16:39 | <alkisg> Unfortunately the APIs that linux has there, are way behind than those of e.g. android
| |
16:39 | I couldn't see any fullscreen videos with epiphany
| |
16:39 | Did you manage to see any fullscreen videos with it?
| |
16:40 | <ltsp_fan> well, I haven't tried. we're mainly interested in videos on the ka-lite interface
| |
16:40 | do you know if pinet supports fat client?
| |
16:40 | <alkisg> I don't know the ka-lite interface. Is it html5-based? flash-based?
| |
16:40 | <ltsp_fan> html5
| |
16:41 | video-js player I think
| |
16:41 | <alkisg> pinet is just a wrapper around ltsp and raspbian, both of them support fat clients
| |
16:41 | <ltsp_fan> oh yes, of course :)
| |
16:42 | but pinet itself as a wrapper, does it have an option for fat clients?
| |
16:43 | wait why am I asking that here, sorry
| |
16:43 | you've helped enough already
| |
16:43 | I have a solution to my hair-pulling problem
| |
16:43 | <alkisg> I don't know if it has an option or if it just says "here, I ran ltsp-chroot for you, now you type: apt install ubuntu-mate-desktop" :)
| |
16:43 | <ltsp_fan> let me implement it before I worry about fat clients!
| |
16:44 | haha!
| |
16:45 | ok thanks guys, you're life-savers
| |
16:45 | all the best!
| |
16:45 | <alkisg> bb
| |
16:46 | ltsp_fan has left IRC (ltsp_fan!29320220@gateway/web/freenode/ip.41.50.2.32, Quit: Page closed) | |
17:01 | robb_nl has left IRC (robb_nl!~robb_nl@62.235.103.52, Ping timeout: 246 seconds) | |
17:07 | robb_nl has joined IRC (robb_nl!~robb_nl@62.235.103.52) | |
17:24 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 260 seconds) | |
17:27 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c) | |
17:29 | Fenuks has left IRC (Fenuks!~Fenuks@95.191.242.41, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
17:38 | robb_nl has left IRC (robb_nl!~robb_nl@62.235.103.52, Quit: I'm gone, bye bye) | |
19:28 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 264 seconds) | |
20:18 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c) | |
21:43 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:d05c:ad72:368e:269c, Ping timeout: 260 seconds) | |
21:45 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
22:14 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
22:32 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 260 seconds) | |
22:44 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
23:10 | <sbalneav> vagrantc: https://code.launchpad.net/~ltsp-upstream/+git/pamexternal-sshauth
| |
23:16 | <vagrantc> sbalneav: that's now at least 3 or so of your newish projects i need to package up! :)
| |
23:17 | sbalneav: you think pamexternal-sshauth might be able to included with the libpam-external as an example implementation?
| |
23:17 | <sbalneav> yeah, probably could
| |
23:17 | <vagrantc> sbalneav: or will they need to grow independently?
| |
23:18 | <sbalneav> It's not done yet, still got more work to do before it's a point-for-point replacement for libpam-sshauth
| |
23:18 | <vagrantc> sbalneav: so, those two basically replace libpam-sshauth?
| |
23:18 | ah.
| |
23:18 | <sbalneav> Yes, ultimately.
| |
23:18 | Prolly need another weeks worth of work.
| |
23:18 | <vagrantc> i should probably try and get this stuff moving into debian experimental, at least
| |
23:19 | <sbalneav> Gimme another week to get things stabalized.
| |
23:19 | I'm still in the "rapidly changing everything" phase.
| |
23:19 | Today, I moved from single character commands in pam_external to actual human readable commands.
| |
23:19 | <vagrantc> sbalneav: i'll gladly give a week or two, as i clearly haven't been keeping pace with you :)
| |
23:19 | <maldridge> ah, the break and fix phase where fun things happen
| |