Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28574

Re: Remote Debugging

Show all headers | View raw

On 27/02/2019 23:28, A.P.Richelieu wrote:
> Den 2019-02-27 kl. 23:00, skrev David Brown:
>> On 27/02/2019 22:12, A.P.Richelieu wrote:
>>> Den 2019-02-27 kl. 21:25, skrev David Brown:
>>>> On 27/02/2019 18:45, A.P.Richelieu wrote:
>>>>
>>>>> If you have a set of stuff on the Pi, dedicated for the test,
>>>>> that should be refreshed, then just create a git repo somewhere 
>>>>> with the test code, and let the Pi do a "git pull --rebase" 
>>>>> periodically.
>>>>
>>>> If the test program(s) are running on the Pi, then you need some way 
>>>> to get them onto the Pi and to keep them updated with any changes. 
>>>> git is one way to share a set of source files.  But there is nothing 
>>>> special about it - the OP should use whatever makes sense to him and 
>>>> whatever suits his current practices.
>>>>
>>>> One thing for sure is that automatic rebases are probably a very bad 
>>>> idea - just like any other automatic updates.  Connect to the Pi 
>>>> with ssh, and do an update when you are ready to test the new 
>>>> software - not before.
>>>>
>>>>
>>>> One thing I didn't mention earlier - when running programs via ssh 
>>>> on a setup like this, run them within "screen" (or "tmux") on the 
>>>> Pi. Then the terminals and programs stay alive even if you 
>>>> disconnect the ssh and connect again later.
>>>>
>>>>
>>>>  > The Pi should only have read access to the repo.
>>>>  >
>>>>
>>>> That is an arbitrary restriction which may not be appropriate.  (It 
>>>> doesn't even make much sense - /users/ have access to a repo, not 
>>>> /computers/.)  If the OP is happy fiddling with the software using 
>>>> nano over ssh, then he should be able to check in changes - there is 
>>>> no reason to force a specific direction to the development process.
>>>
>>> Not really, if you give write access, it will be possible for anyone
>>> that can break into the Pi to get write access to your repo.
>>> Breaking in, consists of removing the SD-Card and mounting it in your 
>>> laptop, after which you can copy the ssh private key.
>>> Not a good idea.
>>
>> First, you don't have to store ssh keys to make git work.  You can put 
>> in the password manually, without storing it.
> 
> Which is totally unneccessary, if you only give read access.

Yes - assuming that you don't mind hackers getting read access to your 
files (if you are realistically worried about hackers), and you don't 
mind the limitations of being read-only.

Personally, I would find read-only access too limiting.

> 
>>
>> Secondly, you can have more than one account - storing a user on the 
>> Pi with ssh keys that has write access to relevant repository, does 
>> not mean using the users main ssh keys.  They can be used solely for 
>> this purpose.
>>
>> Third, the aim is to keep the Pi secure despite being accessible from 
>> the net.  No security is ever perfect, but people hacking in over the 
>> net should be a very low risk problem.
>>
> Not really.

If is a realistic issue, then the OP should drop the whole idea.

> 
>> Fourth, if someone is physically breaking into the guy's office, then 
>> it is extremely unlikely that they will be interested in stealing the 
>> SD-Card from the Pi in order to copy the ssh keys.  And this is 
>> unlikely to reach high on the OP's list of concerns if he has had a 
>> physical break-in.
>>
> 
> 
>> Fifthly, if the git master is set up correctly and you are using 
>> appropriate keys, then all the ssh key thief can do is commit to that 
>> one repository of test code.  That is not going to be a big issue - 
>> and all changes are tracked, logged, and reversible.
>>
> That is unneccessary trouble.

If you don't let in the hackers in the first place, there is no problem 
- and this gives you a plan B if you need it.

> 
>> Sixth, if you think it is not possible to set up git to give safe and 
>> reliable write access like this, then you should not be recommending 
>> git for the job.
> I am recommending read only git, and you say that git is useless, if you
> do not have write access from all over the world.
> I beg to disagree.

That is not what I said.  I said that if git won't do an appropriate job 
here, which I expect will include write access in a secure manner, then 
it is not the right tool for this job.  That does not make git useless - 
it would make it a poor choice here.  (git /can/ give you write access 
in a secure way here, so it could be a good choice.)

Of course, the question of git or alternative ways to share files is 
totally irrelevant to what the OP has been asking about.

> 
> The proper procedure is to have a test setup in your office where
> the Pi has write access. In this setup, you test and verify that it 
> works. Only after testing there, is the test system released.
> 
> Pi's at remote locations should not have write access.

I believe I may have found the source of your confusion.  The Pi is 
staying put - it is the developer who is moving around.

> All experiments should be done on the local system.
> If need to, a remote system could be made to use a dedicated branch.
> 
> 
>>
>>>
>>> The important part of git is that this is something that the Pi
>>> starts, not something that is pushed into the Pi.
>>>
>>
>> No.  The Pi does not start anything.
> 
> The update is started by running code on the Pi.
> 

That code is run by the user, when /they/ decide to run it.

> 
>>
>> The user, logged into the Pi by ssh, starts the update or pull.  And 
>> that same user can edit files directly on the Pi, and should be able 
>> to commit and push the changes.
> 
> The used should commit and push the stuff in a controlled environment,
> not in a customer system.
> 

You are misunderstanding the setup.

Also, customer systems may be a controlled environment - at least, 
controlled enough for that purpose.

>>
>>> It is certainly a good idea to update the Pi automatically
>>> with the latest test suite.
>>
>> Nonsense.  It is a good idea to know exactly what you are running on 
>> the test system, and update it when it is time to update it, not based 
>> on some periodic pulls.
> 
> Automatic, does not neccessarily mean that there is a periodic pull.
> It might do the pull every time you reset the target.
> 

True.  But my answer is unchanged.

> 
> 
>>> If you find you have a problem, you can easily revert to an older 
>>> commit.
>>
>> Yes, that's easy - if you are in control of your updates and haven't 
>> set an automatic job for it.
>>
> You are in control of the main repo.
> Noone will pull in something, which is not part of that repo.
> 
>>> Obviously you should be able to disable the automatic update,
>>> if for some reason you do not like to use the latest version.
>>>
>>
>> You have it ass-backwards.
>>
> No I don't.
> 

Well, we must leave it to the OP to decide what he wants to do.

I am sure that if we were in the same room, discussing plans for a real 
setup, we'd be much closer to agreement - I think we are making 
different kinds of assumptions about the OP's situation here.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 13:42 -0800
  Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-26 22:37 +0000
    Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-26 15:39 -0800
      Re: Remote Debugging Theo <theom+news@chiark.greenend.org.uk> - 2019-02-27 01:32 +0000
    Re: Remote Debugging Jack <jack4747@gmail.com> - 2019-02-26 22:49 -0800
    Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 09:08 +0100
      Re: Remote Debugging Grant Edwards <invalid@invalid.invalid> - 2019-02-27 14:49 +0000
      Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 18:45 +0100
        Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 21:25 +0100
          Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 22:12 +0100
            Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:00 +0100
              Re: Remote Debugging "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-27 23:28 +0100
                Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-27 23:50 +0100
  Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 15:41 -0800
    Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 01:23 +0100
      Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:41 -0800
      Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 17:49 -0800
        Re: Remote Debugging edward.ming.lee@gmail.com - 2019-02-27 18:00 -0800
          Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-27 18:08 -0800
            Re: Remote Debugging Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-02-28 11:21 +0200
        Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-02-28 09:09 +0100
          Re: Remote Debugging gnuarm.deletethisbit@gmail.com - 2019-02-28 15:27 -0800
            Re: Remote Debugging David Brown <david.brown@hesbynett.no> - 2019-03-01 10:11 +0100
  Re: Remote Debugging Les Cargill <lcargill99@comcast.com> - 2019-02-27 22:07 -0600
  Re: Remote Debugging Paul Rubin <no.email@nospam.invalid> - 2019-02-27 21:35 -0800

csiph-web