Coming primarily from a Unix background, I’ve remained disappointed for 10+ years that NetWorker’s init script has barely changed in that time. Or rather, the only things that have really changed in the script are checks for additional software – e.g., Legato License Manager.

It’s frustrating, in a pesky sort of way, that in all this time the engineers at EMC have never bothered to implement a restart function within the script.

For just about every Unix platform in NetWorker, the only arguments that /etc/init.d/networker takes are:

  • stop – stop the NetWorker services
  • start – start the NetWorker services

That’s it. Once, a long time ago, I got frustrated, and hacked on the NetWorker init script to include a restart option, one that worked with the following logic:

  1. Issued a stop command.
  2. Waited 30 seconds.
  3. Checked to see if there were any NetWorker daemons still running.
  4. If there were NetWorker daemons still running, warn the user and abort.
  5. If there were no NetWorker daemons still running, issue a start command.

Over time, I got tired of inserting this hack back into the init scripts after every upgrade or reinstall, and in time even gave up keeping it around. Call it laziness or apathy on my part, but whatever you want to label it, the same applies to first Legato, then EMC engineering for not adding this absolute basic and practically expected functionality after all these years.

Is there an RFE for this? I don’t know, but logically there should be no need for one. As systems have matured, the restart option has effectively become a default/expected setting on most platforms for init scripts. NetWorker has sadly lagged behind and still requires the administrator to manually run the stop and the start, one after the other.

A minor quibble, I know, but nevertheless a quibble.

 

OK, there’s not a lot about NetWorker that drives me nuts. I think I’ve done only one other “Quibbles” topic here so far, but I’ve reached the point on this one where I’d like to vent some exasperation.

There are times – not often, but they occasionally happen – where for some reason or another, a device will lock up and become unresponsive. When this reaches a point where the only way to recover is to either kill the controlling nsrmmd process or restarting NetWorker, things get tough.

The reason for this is that NetWorker does not, anywhere, provide a mapping between each nsrmmd, the device it controls and the process ID for that device.

Honestly, this is one of these basic administrative usability issues for which there is no excuse that it hasn’t been resolved and available for the last 5 years, if not the last 10 years. It comes down to either laziness or apathy – people have been asking for it long enough that with all the changes done to nsrmmd over the years, it should have been added a long time ago.

What do you think?

 

I’ve been working with NetWorker for 12+ years now. I’ve used servers from v4.1, and clients back to the v3.x range. I’m not the most long-term NetWorker user, but I suspect I’m up in the top 10% for long-term users of the product.

Thus, I feel that I’m perfectly justified to point out my ongoing annoyance with the client GUI – particularly on Windows. Just why after all these years can’t the GUI be used to backup to a pool other than the Default pool?

Here it is, in all its aggravating failure:

Where's my pool selection, EMC?

Where's my pool selection, EMC?

I’m not a fan of the client GUI for backup – for the most part I think backup should be server initiated, and if you want to run a backup from the client then running save from the command line is reasonably easy. That being said, not everyone loves the command line like me.

There’s no justification for this ongoing failure to be able to select a backup pool in the GUI. None whatsoever. I don’t care if an EMC engineer who has worked on NetWorker for longer than I’ve been using it suggests a dozen reasons why it can’t be done, it’s … well, not enough.

Why?

Go take a look at the SQL client GUI, or the Exchange client GUI, as an example.

Both of these give the user the option to backup to another pool.

Please will someone actually take the time to update the client GUI so it’s no longer laughable?

 

I know this is a minor quibble – and for the most part, minor quibbles sum up the issues that I have with NetWorker. However, it annoys the hell out of me.

Somewhere, someone in the development team at EMC got the bright idea for NetWorker 7.3 that for “usability” and “consistency” reasons, it would become necessary when depositing media to either:

  • Answer an inane question (i.e., sequence goes: put media in CAP, run nsrjb -d, get asked to answer ‘yes’ to whether you want to import media or not)
  • Remember to add a -Y option to the nsrjb -d command to automatically answer ‘yes’ to the inane question.

Now, I do have a problem with this. In the first case, core behaviour was changed, and I don’t like that. Nor do I see a valid consistency reason – in nsrjb you’ve always been required to answer ‘yes’ or to add a -Y to the command if you’re going to do something destructive, but depositing media shouldn’t be deemed a destructive action.

In the second case, administrators are going to get into the habit of automatically throwing a -Y option onto each nsrjb command they run. I’m the first to admit that where I need to, I do use -Y, but don’t advocate that people get into the habit of using it except for when it is really necessary.

Thus, my preference would be that some release of NetWorker would drop the inane question when a deposit is done, and just let the administrator or person running the deposit get on with the activity of moving tapes.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha