Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
You can execute a command on a remote system by using ssh:
e.g. From your prod:
ssh devhost ls
Would do an ls. Of course this will ask you for a password. You can get around that by setting up an ssh trust. (Adding public key of user on the prodhost to the $HOME/.ssh/authorized_keys file for the user on the devhost.
A couple of cautions:
1) You probably should think long and hard before establishing a trust from root to root. If someone hacks one host they've hacked both.
2) You call them prod and dev. Always for your own sanity make sure you only allow trust FROM prod TO dev and not vice versa. You typically allow many more users to do all sorts of crazy things on a dev host that you don't want to do on a prod host (or even give them access to).
There are many other ways of doing such remote command execution. There are even commercial packages such as Tivoli's Workload Manager that are designed to run jobs across multiple servers and even wait for specific steps to complete on one server before executing another on another server.
my env is this.....
Prod machine internet connected protected by a firewall..
Test machine and Prod machine are connected using a lan....
Test has not a firewall istalled ,and i opened the Prod firewall to use the internal lan network....
Test Machine cames on starting up the sshd and the proftpd daemaons.....
Test has not a console connected....
so using Prod ssh i'm able to execute jobs on the test machine using as output the video attached to the Prod machine that can act as the console of the whole system....
"You can get around that by setting up an ssh trust. (Adding public key of user on the prodhost to the $HOME/.ssh/authorized_keys file for the user on the devhost. "
this will permit to me to skip to eneter the password ...!
"2) You call them prod and dev. Always for your own sanity make sure you only allow trust FROM prod TO dev and not vice versa"
thanks also for this info.!
"There are even commercial packages such as Tivoli's Workload Manager that are designed to run jobs across multiple servers and even wait for specific steps to complete on one server before executing another on another server."
this is very interesting...i have a further question ...
are only availables commencial packages doing such functions.....
or also some opensource packages are doing the same functions ?
Not saying there aren't any free ones but I've never run across any that are full packages such as described for TWS/Maestro. On a quick Google search I found many that claim they work on Linux/OSS but none that say they are "free".
Note that there are "job scheduling" tools for Linux. The most common (which is also available in UNIX) is "cron". This allows you to schedule jobs on a single host. If you created shell scripts that do remote execution (e.g. doing the ssh mentioned above) you can use cron on one machine to kick off jobs on another one. cron is used for scheduling recurring jobs. There is another command called "at" which is used for scheduling jobs once. We have one HP-UX (UNIX) environment where we use the cron on one system to submit an "at" job on another system. Another tool available on Linux is anacron which is similar to cron but allows you to schedule tasks for systems that aren't running all the time (such as laptops).
You can get more details on above commands by reading the man page. Just type "man" and the command name:
(additional detail for how to configure crontab files used by cron)