Find the answer to your Linux question:
Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Remote scripting


    We're Windows developers looking to get involved with Linux for the first time. We have a specific requirement from a customer.

    Basically we need to connect to a remote Linux server from a Windows application and do the following.

    1. Modify a config file
    2. Restart a service

    Could anyone point me in the right direction to accomplish this. Presumably we could implement some kind of SSH client in our app?

    Any help appreciated, as we really are newbies to this.


  2. #2
    Super Moderator Roxoff's Avatar
    Join Date
    Aug 2005
    Nottingham, England
    For an ssh client, just take a look at Putty (which is a Windwos tool). It's open source.

    How you handle the updates to the config file depend on the kinds of changes you want to make. Take a look at how VIM works for file editing by hand on a text console, or look at using the tools 'grep', 'sed', 'awk' - there are several other tools available too.

    You restart a service either by using the 'service' command or by executing its system V init script directly, normally located in /etc/rc.d somewhere. Normally you'd need administrator (root) privileges before you can restart services.
    Linux user #126863 - see

  3. #3
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    There is a perfect answer for exactly this kind of task.
    Unfortunately, this is deep in "unix land", so it might take some learning time.

    What we use to manage several hundred machines in three datacenters is a system management software called puppet

    The basic idea:
    - you describe, how an environemt or node shall look like in an "manifest"
    - and a "provider" will then realize that config on the machine.

    How does it work
    - There is a puppetmaster, that has all the manifests/modules.
    - The puppet agents (after certificate exchange) report so called "facts" about themselves to the puppetmaster. A fact can be: the linux distribution used, or if its a 32bit or 64bit machine, hostname, etc
    - The puppetmaster will enforce changes on the agents, according to the manifests and the reported facts

    --> this results in a quite complete, tight and sophisticated way of managing machines.

    As a simple manifest:
    package { 'openssh-server': 
      ensure => 'installed', 
    service { 'sshd':
      enable     => 'true',
      hasrestart => 'true',
      ensure     => 'running',
      require    => [ Package['openssh-server'], File['/etc/ssh/sshd_config'], ],
    file { '/etc/ssh/sshd_config':
      ensure   => present,
      owner    => 'root',
      group    => 'root',
      mode     => '0600',
      source   => 'puppet:///<PATH_ON_THE_PUPPETMASTER_MANIFESTDIR>'
      require  => Package['openssh-server'],
      notify   => Service['sshd'],
    It is ensured, that the package is installed.
    It is ensured, that the service runs.
    Whenever the config file is changed, the service will be notified.

    This is just the beginning.
    As you can probably guess from the "file" part,
    the sshd_config is just copied from the master to the agents.

    Still quite clumsy.
    There is a supplemental tool for puppet called augeas, which can parse config files.
    With that, one can change single (or multiple) keys without the need to replace the whole file.

    A code snippet to achieve this can look like this:
    augeas { "sshd_config":
        context => "/files/etc/ssh/sshd_config",
        changes => [
          "set Ciphers ${sshd::ciphers}",
          "set ListenAddress ${sshd::listenaddress}",
    You might have noticed, that the key values are variables.
    At my place, we made use of another nice tool called hiera
    The variables come from a hiera lookup.
    The result of the hiera lookup is dependent on the location of the node.

    So the same manifest can produce multiple, location specific configs.

    Interesting for you?
    Last edited by Irithori; 11-15-2011 at 08:17 PM. Reason: missing requirements
    You must always face the curtain with a bow.

  4. $spacer_open
  5. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Forgot to mention:

    The puppet manifests and the hiera data will be of course in a repository (svn/git) for the usual good stuff:
    - central place
    - rollbacks
    - logs
    - diffs
    - branches
    - access control
    - encryption (via e.g. https and/or svn+ssh)
    - backup

    The puppetmaster itself is a svn/git client.

    About the windows part:
    Any subversion/git client application will do.
    - commit a change to the repo. From here on the automagic kicks in

    - on the next puppet run, the puppetmaster will update itself
    - and enforce the modifications
    You must always face the curtain with a bow.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts