in reply to Laziness and the Win32::Daemon

It isn't that hard to install a service remotely. You just copy the files to the Admin$ share and remotely add a small subtree to the registry. When the computer reboots, the service is installed and runs. What to put in the Registry can be determined by installing the service on your machine and copying.

You can even not be so hackish and use the Win32 API for installing services and probably get the service running without the remote computer being rebooted (though I haven't actually done that so I can't promise, it just appears that such would be so).

You can also run remote commands according to Using WMI for create a remote Process on Win32.

BTW, I'm one of those pissy users ;) and would likely disable your daemon when I found it. Having a Perl script run as a daemon isn't a trivial matter. Perl chooses "use more memory" at nearly every design trade-off and having my work interfered with because you think you need an inventory of my machine and silently installed a memory-hogging daemon isn't going to make me happy.

I'd rather you get an inventory by running the script at midnight w/o installing stuff on my computer. You need to figure out what computers are on your network anyway (if you don't know this already then you must be using DHCP so you could look to your DHCP servers for the answer), so track that and when was the last time you got an inventory on that computer. Each midnight, try to get an inventory on computers that are due one. If any computers go two weeks after that without ever being running at midnight, then run the inventory on them at noon.

Or you can go the other route and buy SMS from Microsoft and treat all of your users like trespassers on their desktop. ;)

        - tye (but my friends call me "Tye")
  • Comment on (tye)Re: Laziness and the Win32::Daemon

Replies are listed 'Best First'.
Re: (tye)Re: Laziness and the Win32::Daemon
by Macphisto (Hermit) on Jun 20, 2001 at 21:03 UTC
    1. The users are trespassers! :)
    2. There is a marked difference between the level of my users ( mainly retired military brass ), and a monk like yourself. But either way ... you wouldn't particularly have access rights to the Registry or the Services tools to remove the service. You do however bring up a good point: While this script is small, and takes up little memory since it basically just rips through the registry and some disk stats for the inventory, if it were something else it would be a good bit more memory-hoggish. I would love to hear some ways to limit or diminish the amount of memory used.
    3. Checking the DHCP logs is a good idea. However, the computers not active would not be listed. I could do a union of DHCP statistics, but computers get changed out, etc, etc, and the list doesn't stay constant. I feel this will be my strongest entanglement


    Thanks for you comments, Tye.
    Macphisto the I.T. Ninja

    Everyone has their demons....
[reply]

      If you do decide to run it as a daemon, you should probably have it stop and restart itself after it does any real work. This frees the memory it allocated, which can end up growing without bound in too many cases.

      To get the service to restart itself, I'd have a "-restart" command-line option so the service can do something like: system( qq(start $^X $0 -restart "$serviceName") )

              - tye (but my friends call me "Tye")
[reply]
[d/l]
      While this script is small, and takes up little memory since it basically just rips through the registry and some disk stats for the inventory

      Is there any reason not to run the inventory from a single machine? Harvesting info from win32 registry and disks is usually pretty quick (on my network anyway).

      If all of your machines are in a domain (assuming NT systems here), you can get a list of them and attempt to harvest. Failures can be noted in a log. This takes care of the machines that are online. In the login script, add a line to log the machine name to a remote share. You can schedule the harvester to scan the share for machines that come online and inventory them.

[reply]

In Section Seekers of Perl Wisdom