Re: PermitUserEnvironment option forOpenSSH sshd; was Re(2): automating x permission on a file.

2011-12-20 Thread Bob Proulx
peasth...@shaw.ca wrote: > The PermitUserEnvironment option for the OpenSSH sshd might > make scp usable after all. At present the sshd won't allow > an existing file to be over-written, even when write permission > is present. What? Uhm... No. That isn't the way it works. You can overwrite f

PermitUserEnvironment option forOpenSSH sshd; was Re(2): automating x permission on a file.

2011-12-20 Thread peasthope
* From: Bob Proulx * Date: Tue, 13 Dec 2011 14:45:19 -0700 > This would be much better for rsync over ssh. Start using rsync using > the -a option to preserve everything including permissions. The PermitUserEnvironment option for the OpenSSH sshd might make scp usable after all. At

Re: automating execution of script; was Re (3): automating x permission on a file.

2011-12-19 Thread Bob Proulx
peasth...@shaw.ca wrote: > Suppose ~/.bashrc ends with these 5 lines. > > exec while 1 do > if (inotifywait -e modify ~/control.sh) = 0 > then { chmod u+x ~/control.sh; ~/control.sh; } > controlresult > fi > done You have that in a loop forever, right? How will you log in? How would you pre

automating execution of script; was Re (3): automating x permission on a file.

2011-12-18 Thread peasthope
* From: Bob Proulx * Date: Wed, 14 Dec 2011 13:43:07 -0700 > A process listens through inotify on the receiving end > for the control file. ... When control files appear > the incoming handling process reads the file and > acts upon the instructions included in the file. Thanks. I

Re: Re (3): automating x permission on a file & some [OT] chatter.

2011-12-14 Thread Bob Proulx
peasth...@shaw.ca wrote: > Bob Proulx wrote: > > I think hacking the ftp backend will always be problematic. > > Understood. Really I meant that the ETHO operating system would > have to be replaced with Linux or Plan 9 or Inferno. Possible but not > appealing. I think you can do it without.

Re (3): automating x permission on a file & some [OT] chatter.

2011-12-14 Thread peasthope
From: Bob Proulx Date: Wed, 14 Dec 2011 13:43:07 -0700 > > To obtain rsync, the client system would have to be changed. > > I think hacking the ftp backend will always be problematic. Understood. Really I meant that the ETHO operating system would have to be replaced with Linux or Plan 9

Re: Re (2): automating x permission on a file & some [OT] chatter.

2011-12-14 Thread Bob Proulx
peasth...@shaw.ca wrote: > Bob Proulx wrote: > > Is there a constraint that you must use ftp? ... > > ETHNO has FTP and SSH.Send but not rsync. SSH.Send requires > painfully more time than FTP does. To obtain rsync, the client > system would have to be changed. I think hacking the ftp backend

Re (2): automating x permission on a file & some [OT] chatter.

2011-12-13 Thread peasthope
From: Bob Proulx Date: Tue, 13 Dec 2011 14:45:19 -0700 > Is there a constraint that you must use ftp? ... ETHNO has FTP and SSH.Send but not rsync. SSH.Send requires painfully more time than FTP does. To obtain rsync, the client system would have to be changed. > It sends passwords in th

Re: automating x permission on a file.

2011-12-13 Thread Bob Proulx
peasth...@shaw.ca wrote: > CONTEXT > Squeeze system with vsftpd with default umask, 077. > A script file, blah.sh for example, is put to the > system. The file arrives with permissions 600. Is there a constraint that you must use ftp? Because it is terrible for this context of PUTting a

automating x permission on a file.

2011-12-13 Thread peasthope
CONTEXT Squeeze system with vsftpd with default umask, 077. A script file, blah.sh for example, is put to the system. The file arrives with permissions 600. PROBLEM Each time blah.sh is put on the system, "chmod 700 blah.sh" can make it executeable. The ftp client does not provi