c4c-dev team mailing list archive

[Israel <israel@xxxxxxxxxx>]

Hi Greg and all,
this sounds exactly right!
I think this fully addresses the copyright issue, and makes it easy for
the end user

On 05/19/2015 03:23 PM, KI7MT wrote:
> Hello Eric, All,
>
> Just off the top of my head, we could put a package together with a menu
> something along the lines of:
>
> 1. Install Media (Music, Videos)
> 2. Update Media (Music, Videos)
> 3. Request New Access Code
> 4. Install New Access Code
> 5. Exit
>
> Something to that affect. The rest of the would happen behind the scenes.
>
> best regards,
>
> Greg.
>
>
> On 05/19/2015 01:36 PM, Eric Bradshaw wrote:
>> Guys,
>>
>> This sounds wonderful, I guess I just want to make sure it's very uncomplicated for the end users. I apologize for my own ignorance, but I believe I would know much less than most about how exactly this all would work and while you all can hopefully walk me through step-by-step I wouldn't be want to put the recipient of our software and/or a C4C computer through what I'd be willing to do. I guess what I'm trying to say is I'd like to above all else make it very easy for the end-user. Like there is a well-defined, maybe even pretty text box in which to type in one code (we deliver with the computer) and from then on they only need their password.
>>
>> Eric
>> --
>> Thank You,
>> God Bless You,
>> Computers4Christians
>> http://Computers4Christians.org/
>>
>> KI7MT <ki7mt@xxxxxxxxx> 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:
>>>>>>>
>>>> ...
>>>>
>>> -- 
>>> 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
>>>
>>>


-- 
Regards

-Israel
ToriOS Team