Your articulate explanation is much appreciated. Makes sense now. I will file our exchange away for future reference. Thanks again.
On 01/11/2013 07:33 AM, GauteHope wrote: > The reason is that for keys to work with ssh an ssh-agent implementation > (ssh-agent, gnome-keyring, etc) needs to be accessible > by the ssh client. When you run your window manager an agent is set up which > is normally able to automatically determine which key needs to be loaded and > then load it if it does not have a password. This is why it works without you > needing to do anything in your normal environment. > > The agent information is stored in environment variables and references > to a communication pipe some where on the filesystem, usually in /tmp/ > (changing file name each time the agent is started -> when you log in), > where only your user has access. > > When running a cron job you do not have access to your usual environment > and any programs run as a cron job (recurrent) does not know where to > communicate with any existing (ssh)agent - if you are logged in at the > time. So, since your keys do not require any passwords or interactive > input, starting an ssh-agent and exporting the access information > (environment variables using 'eval'), adding the key to this agent (ssh- > add), the programs (utilizing an ssh client) run in this environment > will know how to access the newly started agent (probably running > parallel to any other agent you have running on your login session). > > It is similar to relaying the ssh-agent information when you log in > remotely using the '-A' flag of ssh, this way the remote session (e.g. > command line bash) will have access to the original ssh-agent on your > local machine through a pipe set up through the ssh connection - with > the result that you can use the keys of your original agent in any > further ssh connections made from the remote computer (current session). > > As to why this is not done through gnome-schedule; there are infinite > many ways various program interact with each other - creating wrapper > scripts like this is easier. The only exception where we try to support > interaction is between a program and the currently running graphical > environment - by again exporting the environment variables to the X > session and authority agents. Remember that cron and at was created > without graphical environments and will run even if you are not logged > in or have a graphical environment set up. If the application needs a > graphical environment and there is none - it is likely to crash. > > I hope I was clear enough, and I am happy to help, > - Gaute > > Quoting: >> Greetings, >> >> I appreciate your help with this. I've tried your script and it worked >> flawlessly. May I trouble you further for an explaination as >> to why the script works and simply scheduling the job does not. >> >> Thanks, >> >> Robert Vanderhoof -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1097504 Title: Unable to schedule a recurring Unison job with cron or gnome-schedule To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-schedule/+bug/1097504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
