← Back to team overview

c4c-dev team mailing list archive

Re: Large Binary Files

 

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

Follow ups