c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

Hi Isreal, ALl,

SO in affest, that would be two packages we need to create:

[1] The Admin Package
[2] The User Package

The Admin Package would have:

1. Generate New Key
2. Install To Server
3. Manage Auth Keys
4. Whatever else is wanted for admins .. .. ..
5. Exit

and the user package something like below.

best regards,

Greg



On 05/19/2015 02:29 PM, Israel wrote:
> 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
>>>>
>>>>
> 
>