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

Groups > comp.arch.embedded > #28572

Re: Remote Debugging

Show all headers | View raw

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.

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.

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.

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.

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

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

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

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

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