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

Groups > comp.arch.embedded > #28573

Re: Remote Debugging

Show all headers | View raw

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.

> 
> 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.

> 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.

> 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.

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.
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.


> 
> 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.

> 
>> 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.



>> 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.

AP

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