Thread Previous • Date Previous • Date Next • Thread Next |
Addendum - I didn't want to give the impression that I don't want what was just described to work. On the contrary - it sounds great. I just want it to be and "seem" easy to the end-user. We give away computers (and God willing others will give away computers) to lots of folks without *any* real computer experience whatsoever and I don't want them to feel it's too complicated for them to start. Eric -- Thank You, God Bless You, Computers4Christians http://Computers4Christians.org/ Israel <israel@xxxxxxxxxx> wrote: >Hi, >I think this is brilliant! >This thoroughly covers every thing possible, adds more security, adds >strict compliance with the ambiguous 'for c4c use only' and makes me >feel generally a lot better about the whole deal. >Please do this! > >On 05/19/2015 02:04 AM, KI7MT wrote: >> Hello All, >> >> I've been thinking about this authentication thing a little bit. >> >> There appears to be two use case situations: >> >> [1] PC's that are pre-built and pre-imaged with C4C >> [2] ISO Installation by the user >> >> >> Situation [1] >> >> From a server content delivery standpoint, an easy way to administer >> this would be through the use of SSH Key pairs (private & public). Each >> system built and delivered to the receiver ( the person getting the >> computer ), would get a unique key pair generated off a MB serial >> number, chipset serial number or something that would be unique on every >> machine. Those key pairs will determine if they that system has access >> to the media or not. This is how we all access servers through SSH for >> web-hosting, VPS server administration, even our launchpad code work. >> >> Those keys would be installed on the system before delivery, and added >> to the server's authorized Key list. *That can be your control point*. >> If they re-install the system, loose their key or whatever, they would >> be required to request a new set, and thus agreeing to the EULA again >> before they are sent to them. >> >> This of course would restrict access to the server via SSH to Key access >> only, which is a good thing anyway. Debian has this implemented for all >> their access for us Maintainers. >> >> >> Situation [2] >> >> This is much the same as a user loosing their key pair and having to >> request a new set. The end user, if they want to use the Download >> facility (for media ) would have to request a Key pair. When they do, >> they must agree to the EULA. To get the initially, they would have to >> request them via email, web-interface or whatever. >> >> >> Conclusions >> >> While it's not perfect, it does provide a high level of containment, and >> it's used throughout the Internet as a stand means of access. All this >> can easily be shell scripted. >> >> You could take this one step further, and add passwords to the Keys as >> well, which I would advise. Those PW's should never be given back out. >> If they forget it, to bad, so sad, request a new key pair. >> >> There is only one issue with this, Zsync does not work over SSH, Rsync >> does, SCP does, Curl does. >> >> Zsync is more efficient, no question about that, but rsync is a *very >> good* file transfer protocol. It's used to backup servers all over the >> web, every day. That, coupled with 7Z compression, should work quite >> well. Not to mention, binary data (music files, video's etc) do not >> compress, so we're pretty much stuck with whatever the file sizes are >> anyway. >> >> Rsync commands are simple: rsync -avr pointA/ pointB/ >> >> Over SSH one simply adds the User and IP Addy to the string. Point A and >> B can be any combination of IP addresses, Network Addresses, or Local >> Disk paths. >> >> The only thing you'd have to do really, is add the key pairs to the >> servers auth list when issuing new pairs. Would be a good idea to keep a >> log of the data and what not, but that's pretty easy. >> >> >> Thoughts ?? >> >> >> best regards, >> >> Greg >> >> >> On 05/18/2015 03:34 PM, Israel wrote: >>> Hi again, >>> zenity is a gtk application, and AFAIK there is no real Qt equivalent.. >>> but I have only used KDE a handful of times, and the same goes for LXQt. >>> >>> So, if we want to make an installer we would need to do a few different >>> things. >>> a) make Qt and GTK installers >>> b) use a different toolkit (I am very familiar with FLTK using c++) >>> c) look into Qt dialog programs (do they exist, how good are they?) >>> >>> A bash script is going to be the quickest and easiest way for me to >>> sketch out a program we can test, and use. >>> >>> @Greg do you know any programming languages? >>> >>> I don't have much experience using curl/rsync so my vote is for zsync, >>> as it is used for ISO downloads >>> >>> I think as a further precaution we need to look into some sort of >>> passkey type thing for use with the binary files, in order to further >>> protect things, or some other way of verifying that the zsynced files >>> are going solely to a c4c machine (or someone installing c4c-music or >>> whatever) >>> I don't have any real suggestions for this right now... but just the >>> thought that we should do this >>> >>> >>> On 05/18/2015 12:12 PM, KI7MT wrote: >>>> HI Eric, >>>> >>>> You don't need the QT Opensource Installer .. that's for QT application >>>> development, which we are not doing at this point; it was just an >>>> example of lengthy downloads and accepting the EULA. >>>> >>>> Everything we need QT wise will be provided by the base Installation >>>> ISO. We don't need to be concerned about those packages. >>>> >>>> best regards, >>>> >>>> Greg. >>>> >>>> >>>> >>>> On 05/18/2015 11:07 AM, Eric Bradshaw wrote: >>>>> Guys, >>>>> >>>>> Again, no expertise - but, my thought is we may want to use the QT Open >>>>> Source installer simply because Lubuntu is transitioning to LXQt >>>>> (supposedly) by 15.10 - so maybe we'd be prepared? Apologies if one >>>>> would have nothing to do with the other. >>>>> >>>>> Eric >>>>> >>>>> On 05/18/2015 09:14 AM, KI7MT wrote: >>>>>> Hi Israel, All, >>>>>> >>>>>> Yes, zsync, rsync or even curl could do that job easily. A simple shell >>>>>> script could do what is needed here. >>>>>> >>>>>> If you have ever used MSYS/MinGW, this is exactly how their installer >>>>>> works for pulling packages to install form the SF server. The same for >>>>>> the QT Open Source installer, and it pull a is HUGE amount of data at >>>>>> install. >>>>>> >>>>>> >>>>>> best regards, >>>>>> >>>>>> Greg. >>>>>> >>>>>> On 05/18/2015 07:43 AM, Israel wrote: >>>>>> >>> ... >>> > > >-- >Regards > >-Israel >ToriOS Team > > >-- >Mailing list: https://launchpad.net/~c4c-dev >Post to : c4c-dev@xxxxxxxxxxxxxxxxxxx >Unsubscribe : https://launchpad.net/~c4c-dev >More help : https://help.launchpad.net/ListHelp
Thread Previous • Date Previous • Date Next • Thread Next |