Laziness and the Win32::Daemon

Macphisto has asked for the wisdom of the Perl Monks concerning the following question:

By education I'm a Computer Scientist but my traning/trade I'm a Network/Systems administrator for a small IT Company. Perhaps a better description would be I'm the PFY to my bosses BOFH ( see here for a description of BOFH and PFY ). And being those things, I'm both a Ba**ard and incredibly lazy. One of the things we have to do on a semi-regularly basis, is to create inventories of our computers and of the software installed on them. When I first started working here as an intern, I had to do this by hand, mainly because I was new and wasn't trusted enough to write a perl script to do the work for me while I head to the Crystal City Underground for a pint. Now that I've moved from intern to Admin and earned the trust of my superior BOFH, I can do just about whatever I want and I'm told, "If you break it, we'll fix, just make sure you learn from it!" As it stands the IT department here is only the BOFH and myself and since I'm the PFY I end up doing the inventory. The last time I did it, I whipped up some Win32 perl to do it, but I still had to go to each computer. I was designing it to go out, walk our network, and remotely pull the information I needed from all the computers but I ran into snags. The biggest one being that it wasn't guaranteed that every computer would be on and connected to the network at the given time the script would be running.

I put the idea on the back burner and went about my work. I discovered the Win32::Daemon module while coding a script to watch the user shares, and an idea came to me. Let the script run as Daemon ( or Service in the Win32 world ) and every time the computer boots, it runs the script I'd already written for inventory, and writes the results to file ( named by its Network Node ID ) on a disk share. Anytime I needed the inventory, it'd be right there, on my network, waiting for me. Yet, again, I still run into snags...

Should it be a daemon or should I simply make the script run in the "Start Up" directory of the machines?

If the machine weren't rebooted periodically the script wouldn't get a chance to run and perhaps my inventory would be off or skewed. Perhaps, it would be best for the script to run as a daemon and to excute both at startup, and at midnight since some computers aren't turned off by their users, and some are turned off at the end of the day

Deployment -- i'm still lazy...
- There are ~100 computers to inventory, across three offices which are a pretty good distance apart. As well, if you're an admin, you know that users think they're the most important person in the company and if you disturb them from their work ( or porn perusal or crossword completion ) they get all pissy and go crying to their case leader. So what I would like to do is to install the service remotely, which in itself presents more problems( you were expecting ease? ):

I'd like to know if anyone has any ideas on any of the above entanglements, as well as if you forsee any other problems. If you have any comments or ideas about this, I'd love to hear them. As well if you'd like to send me some pie, I can provide an address...
Macphisto the I.T. Ninja

Everyone has their daemons....

Comment on Laziness and the Win32::Daemon

Replies are listed 'Best First'.
(tye)Re: Laziness and the Win32::Daemon by tye (Sage) on Jun 20, 2001 at 20:46 UTC
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")	[reply]
Re: (tye)Re: Laziness and the Win32::Daemon by Macphisto (Hermit) on Jun 20, 2001 at 21:03 UTC
The users are trespassers! :) 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. 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]
(tye)Re2: Laziness and the Win32::Daemon by tye (Sage) on Jun 20, 2001 at 21:09 UTC
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]
Re: (Macphisto)Re: (tye)Re: Laziness and the Win32::Daemon by joefission (Monk) on Jun 20, 2001 at 21:49 UTC
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]
Re: Laziness and the Win32::Daemon by ellem (Hermit) on Jun 20, 2001 at 20:09 UTC
code aside, I would think this process would work: add a line to your startup.bat files that says run this inventory.pl script found at \\server\where\script\lives Then when the client computer runs the script it has said "Here!" and at that point have inventory.pl get the required info (either through a subroutine or have inventory.pl invoke YAS (yet another script.)) The disadvantages to this are (As Dave Roth has pointed out in WIN32 Perl Scripting :: Sys Admins) that at 8AM when your users login there will be some strain on your server as they all start hitting that script all at once. Pie, like lunch is (sadly) never free The flip side to this would be to have startup.bat INSTALL the inventory script and then your startup.bat file could if/then the next time it was run the inventory process. -- lmoran@wtsgSPAM.com print "\x{263a}"	[reply]
Re: Re: Laziness and the Win32::Daemon by Macphisto (Hermit) on Jun 20, 2001 at 20:17 UTC
Those are good comments, and the only thing that keeps me from throwing it into startup.bat is that some of the computers don't get rebooted periodically. Some users just refuse to turn off their computer when their done at the end of the day ( /me believes Washington DC is headed towards California like rolling black outs ), so that script might not run often enough to represent a current inventory. Macphisto the I.T. Ninja Everyone has their demons....	[reply]
Re: Re: Re: Laziness and the Win32::Daemon by ellem (Hermit) on Jun 20, 2001 at 22:05 UTC
hmm... running a mix of 9X and NT or just 9X? if 9X then set up a machine as you Policy machine and force them off at say 11:45PM until 3:45AM (tell 'em it's for backups), plus if using DHCP shorten the leases. if 9X && NT then set up a 9X and a Server for Policy as the two are not even remotely compatible NT will do a whole bunch of neat stuff if you ask it to. OR are you running Mac Clients as your name suggests? In which case switch your clients to OS 9.02 and they'll crash so much they'll have to sign in all day! -- lmoran@wtsgSPAM.com print "\x{263a}"	[reply]
Re: Re: Re: Re: Laziness and the Win32::Daemon by Macphisto (Hermit) on Jun 20, 2001 at 22:09 UTC


Pathologically Eclectic Rubbish Lister
	PerlMonks