I am Using Nagios XI. Currently My Nagios showing three states of alerts: CRITICAL, WARNING and OK.
I want to add another custom hard state FATAL for some extreme issues like server or any of my component(Java jar component) is down. Currently we are getting the DOWN message when the Host is Down. If the component is down I am getting "URL Status is CRITICAL" But I want "URL Status is FATAL". Is that possible to add a custom State in Nagios? How can I do that?
You can't. The states are built in (along with a fouth state, UNKNOWN, which is generally used if the plugin fails for reasons that probably belong to the plugin itself, not the object being monitored).
The states are intended to mean "requires action immediately (CRITICAL)" and "will probably require action soon (WARNING)". There's nothing left which would make your FATAL state different from CRITICAL, so i suggest you use that.
If you want to pass additional information to operators, you can always do that in the text the plugin provides.
(As Nagios is open source, you could probably modify the source code to allow another state. But this would be a huge task to implement properly, make your installation incompatible with the rest of the world, no plugins except yours would support it, and you'd have to re-apply and rewrite your patches with every new version of Nagios, so i'd strongly recommend against it).
You can't add states. But if you only want to make your alerts stand out more clearly, you can modify the nagios-Stylesheets in /etc/nagios3/stylesheets/ or add custom javascript in /usr/share/nagios3/htdocs/ssi/<nagiospage>-header.ssi and highlight the respective messages from there.
Related
I can use acceptChanges, jdbcRowSet1.acceptChanges(); , with my jdbcRowSet data source to accept the changes (updates, deletes, etc). How would I rollback or cancel any updates, deletions, etc.???
I tried jdbcRowSet1.rollback(); but got an error.
Error while executing JavaScript action expression
Script interpreter error, line=1, col=13: Unknown member 'rollback' in Java class 'com.ibm.xsp.extlib.jdbc.model.JdbcRowSetAccessor'
JavaScript code
1: jdbcRowSet1.rollback();
Anyone try this yet?
thanks, Howard
The jdbcRowSet data source does not currently support rollback(). We could add support for this in the future perhaps (no guarantees). From my reading, there is a method RowSet.cancelRowUpdates() that we could use in our jdbcRowSet implementation for this, but it only cancels updates to a row, and doesn't cancel deletions/insertions.
A simple potential solution for your issue would be to reload the page via javascript call, context.reloadPage(), and that will discard the current rowSet. Simplistic solution, but it may do the trick for you.
Your questions is really less XPages specific, and more about general SQL management in Java, so if you want a more indepth answer than I provide, you may want to update your tags.
More than likely your connection has autocommit set to true. This forces the data set to commit changes as you make them immediately, so there is nothing to roll back. The rollback() method is from the connection object related to the row set, and will not provide a rollback when autocommit is true, hence the error you get.
You need to look into changing your auto commit to false, then make sure you call commit() or rollback() when you are done with your changes. If you have multiple transactions occurring, you should look into the the connection manager as well. I touch in this briefly in the chapter on the SQL controls in the Extension Library book from IBM Press.
I want to show a specified dialog under simulation category like "Developement Strategy" and do something after its "OK" click. Is there a way to show a native petrel process window?
I can see some class and interfaces in "Slb.Ocean.Petrel.UI" like DialogBuilder , DialogPage, IDialogPageFactory, IDialogPage...but I can't use them, even I don't know if they supply my required objects.
I think you want to create a Workstep (Slb.Ocean.Petrel.Workflow). The Ocean wizard lets offers a quick start. It creates optionally a process wrapper for you, which is the item showing up in the process tree.
Once you got familiar with the concepts, you can evolve the simplistic initial implementation by using the WorkflowEditorUIFactory. Check the namespace documentation in the Ocean documentation for more details.
IProcessDiagram offers different Add methods for your custom Process to enable custom positioning in the tree node sequence.
You can programmatically show a particular process dialog using DialogBuilder.ShowSettings(object) and passing the Process instance. This is typically used by a plug-in to launch its own process dialog, but it's possible to obtain a reference to the instance of a native Process by name using FindProcess(string). This is, of course, a very fragile approach:
Process p = PetrelSystem.ProcessDiagram.FindProcess("Development strategy");
PetrelSystem.DialogBuilder.ShowSettings(p);
It would need a lot of error handling, not just to guard against changes to the process name, but also to handle the case where an exclusive process dialog is already open.
However, this will still only launch the dialog. There is no way to know if/when the user clicks the OK button. Petrel processes are typically stand-alone pieces of functionality, and any kind of chaining is generally supported by creating workflows.
We have a complex scenario which requires a timer job to run after content deployment to a SP 2010 site collection. The timer job automatically deactivates/reactivates a branding feature which is responsible for setting the master page for the site collection, among other things.
We have had several feature upgrades along the way, and neglected to call .Update() on the feature in that specific site collection. So all of the updated CSS, master page, page layouts etc. are out of date on that SC.
The strange part is that when I checked the version number of that feature in this SC, it shows as the latest version. The custom upgrade action clearly didn't run and update the files, because nobody called .Upgrade().
One of my colleagues suggested that the deactivate/reactivate process done by the timer job would update the version number, meaning that I can no longer call Upgrade()!
Is that true? Does a deactivate/reactivate cycle for a feature automatically update the feature version number?
Is there an easy way to fix this mess? Some way to decrement the version number programmatically, then call Upgrade()??
On 1: No. Feature deactivating / activating does not trigger an update. See this article by Chris O' Brian: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade(), typically in conjunction with one of
the QueryFeatures() methods. My tool which I’ll go on to talk about is
a custom application page which helps you with this part – note there
is no STSADM command, PowerShell cmdlet or user interface to do this
out-of-the-box.
Is your timer job cycling the feature activation with Force? Then, yes, it is triggering the feature upgrade/feature update see the following screenshot from SPFeature.Activate (see my yellow marking):
Why the feature version is incremented, I'm not sure. When you have a feature, install a new feature version and activate / deactivate, the feature version stays the same unless you run an Upgrade, see also this related question stating the same: https://sharepoint.stackexchange.com/questions/41476/feature-upgrading-question
I'm guessing your timer job is using force? Otherwise I'm not quite sure what is happening.
On 2: Don't know if it is possible to decrease the version number, but the safest way would be to just create a new version including a grand "clean up" feature receiver which sets everything correct, i.e. checks which steps of the feature upgrade have happened already (e.g. new list created, new content type added) and which haven't. Depending on that just execute the same steps again which have not executed yet. For the latter part you can fortunately use the existing code, so you would only need the "clean up" or checking code.
After some testing I found that simply deactivating and reactivating the feature will increment the version number and completely screw up your upgrade! I even watched the update come through in the content database. As soon as you deactivate/reactivate the updated feature, the new version number pops into the content DB. Of course the upgrade doesn't actually run, it just increments the version number.
This means that if you then call .Upgrade() it won't work because SharePoint thinks it's already been upgraded!!
To fix this I updated the row in the content database to set the feature version back to 0.0.0.0 for that particular web and then I could run .Upgrade() just fine....but that's not exactly a supported solution. If anyone else has a better idea drop a reply.
I have been working on cleaning an old project's resource.h.
In the project I am working on, I have some IDs which are in the form:
IDM_XXXX 32771
but are referred in code in ON_COMMAND and ON_UPDATE_COMMAND_UI statements.
So am I right in thinking that they are following the command architecture and ideally should be named as ID_XXX instead of IDM_XXXX?
I have read through TN022: Standard Commands Implementation and see that Microsoft says:
We recommend you use the standard "IDM_" prefix for menu items which
do not follow the command architecture and need menu-specific code to
enable and disable them.
I am not sure what is meant by menu-specific code here.
How are IDM_XXXX resources normally handled? Also what is the valid range range for IDM_XXXX? I have gone through TN020: ID Naming and Numbering Conventions but am confused.
ID_ and IDM_ are interchangeable because commands are accessible via command bars, menus or maybe ribbons. I never use IDM_, I only use ID_
Reserved by the MFC is 0xE000->0xEFFF and 0x7000->0x7FFF.
TN020 says that menu/command IDs must be in the range of 0x8000 and greater, but I found no reason why to do this. In the tooltip handling and command routing of the dialogs of the 16bit MFC version and AFAIK an old MFC4.x version, there was a specific code that looks for commands being greater than 0x8000.
By accident I had cases were an ID <0x8000 was created, but it worked.
I would resist not following the recommendations in the technical note. Microsoft does have undocumented messages that may interfere with your code if you violate their recommendations. And, debugging such an issue would be difficult. Additionally, following the recommendation allows you the extra benefit of...
following the MFC command architecture not only makes command handlers
more powerful (since they will work with toolbars) but makes the
command handler code reusable
This means MFC will use the same code to handle any menu and toolbar interactions that are linked together.
I have a reason to prefer my plugin to be registered on post-op but I'd need to put something in it (change a field to another value). Do I really have to register it on pre-op or can I shove my update into it despite that the operation has been carried out already?
I'd prefer to avoid firing up an update. The code logic might get a bit crowdy and confusing by that, since there'll be a lot of stuff to do upon a "real" update.
Changes made to the target entity in post-op will not end up in the database unless you run an update manually.
You could consider breaking up your plugin into two. One to change the field in pre-op and one to do whatever it is you're doing in post-op.
Plugins can share data: http://msdn.microsoft.com/en-us/library/gg328579.aspx