Eike, There is a built in 'help' function which will display the available commands.
Ed, I left cron jobs alone with the idea that people would ask for them to be removed once they had been moved elsewhere. Please file a bug and I'll get the job cleaned up. -Matt, On Thu, Aug 29, 2019 at 2:52 AM Eike Stepper <step...@esc-net.de> wrote: > Am 27.08.2019 um 16:44 schrieb Matthew Ward: > > Hi Ed, > > > > The restricted shell was originally created with the goal of providing > committers a way to interact with the > > downloads/archive filesystems for releng activities, and version control > systems without providing a general purpose > > shell. So naturally the command set available leans in that > direction(mv,cp,mkdir,git etc). > Finding out what the restricted shell actually allows you to do is quite > annoying, as it just kicks you out on forbidden > commands. Is there an alternative way of discovering/indicating > forbiddenness? > > Cheers > /Eike > > ---- > http://www.esc-net.de > http://thegordian.blogspot.com > http://twitter.com/eikestepper > > > > > > We are certainly willing to discuss adding extra commands either > temporarily or permanently, but I want to make it > > clear that the goal is not to reproduce bash. > > > > -Matt. > > > > > > > > > > On Mon, Aug 26, 2019 at 9:58 AM Ed Merks <ed.me...@gmail.com <mailto: > ed.me...@gmail.com>> wrote: > > > > What will we be able to do in restricted shell? Using vi is a very > basic activity. I suppose there must be some > > good reason why that's restricted? Earlier I was under the > impression that such simple things would continue to > > work, but now I have to wonder. But then it was mentioned that > things we discover needed could become unrestricted... > > > > > > On 26.08.2019 15:35, Matthew Ward wrote: > >> Hi David, > >> > >> Thanks for the questions. > >> > >> Users with the restricted shell will have the same home directories > that they do currently, which will remain the > >> place for authorized keys. You won't be able to edit(vi/emacs/ed) > files directly within the restricted shell, > >> so you will need to upload them via scp/rsync. If you want a more > 'interactive' type of access I'd suggest > >> looking into using libfuse, and specifically the sshfs file system. > >> > >> The restricted shell allows rsync, so there should be zero impact. > If you'd like to test in advance, drop me a > >> line and I'll set you up. > >> > >> -Matt. > >> > >> On Sat, Aug 24, 2019 at 3:23 PM David Williams < > david_willi...@acm.org <mailto:david_willi...@acm.org>> wrote: > >> > >> On 8/23/19 14:24, Matthew Ward wrote: > >>> Hi Everyone, > >>> > >>> I just wanted to follow up with a reminder that on August > 28th we will be moving committers that have an > >>> actual shell on Eclipse.org to our restricted shell. > >>> > >>> I'd like to thank both Donat and Etienne on the Buildship > RelEng team who volunteered to test this change, > >>> and helped me confirm that this change should be minimally > disruptive. > >>> > >>> If you have any questions, please let me know. > >>> > >>> -Matt. > >>> > >> > >> Thanks for the reminder. > >> > >> Will those of use that still want to use 'scp' and similar > still have a 'home directory' (on "build"?) and is > >> that still the place for .ssh/authorized_keys2? Or, does all > that change with "restricted shell"? > >> > >> If a change, can you point me to instructions on how to set > that up? I would assume some form of "ssh-copy-id > >> hostname" but thought best not to assume and ask explicitly. > >> > >> In case you are wondering, the use case, for using scp and > similar is to download a number of builds to my > >> local machine (without going through web interfaces). > >> Now that I think of it, I currently use rsync via ssh, such as > >> > >> rsync -a -e ssh ${committer_id}@build.eclipse.org:$ <mailto: > committer_id...@build.eclipse.org:$>{dlpath} > >> "${output_dir}" > >> > >> Will that still work with a restricted shell? Or, will I need > to convert to "scp"? > >> > >> Thanks, > >> > >> > >> _______________________________________________ > >> cross-project-issues-dev mailing list > >> cross-project-issues-dev@eclipse.org <mailto: > cross-project-issues-dev@eclipse.org> > >> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >> > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > >> > >> > >> _______________________________________________ > >> cross-project-issues-dev mailing list > >> cross-project-issues-dev@eclipse.org <mailto: > cross-project-issues-dev@eclipse.org> > >> To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org <mailto: > cross-project-issues-dev@eclipse.org> > > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org > > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
