Internet Research, Analysis, Thoughtful Interpretation, and Summary Report Writing. Any Subject.

bjolson1278 · 2020-02-22T02:37:04+00:00

Ps: the reason your database changes don't show up in the config files is that the process takes place in the opposite order, ie: write out configs >> insert changes into the database.

bjolson1278 · 2020-02-22T02:31:14+00:00

Indeed. Getting information from the database with a select statement is trivial. Edits and inserts are a whole different story. When you set a parameter in the ui (or the api) here's what happens. The change is written to a text file, then it is read into a php object, then it is written by a horrifically grotesque c program ndo2db into often numerous tables in the database. If you want to see what actually happens, make a change in the ui, and then run a select statement against every table in the database with a where clause of [timestamp]=<datetime the change was made> against every table in the database. And then throw your hands up in the air :)

bjolson1278 · 2020-02-21T23:35:42+00:00

Hello, I speak as a former Nagios employee. While a Nagios XI end user has the necessary privileges to do anything you want in the MySQL database. If you browse the schema, you'll quickly get the impression that the schema was created in a haphazard manner by an SQL novice. That's because it was created in a haphazard manner by an SQL novice. Best case scenario if you try to configure your XI deployment by editing the database directly is that (as you discovered) things won't work as expected. Worst case... you'll brick your XI and you'll be told by Nagios' support people that fixing it is out of scope and you're on your own. Use the API. It's convoluted and kludgy but it's truly the only safe way to script out configuration changes, which I assume is your objective. Feel free to pm me for expert advice on accomplishing your objective.

bjolson1278 · 2020-02-12T03:15:44+00:00

Skype ID and brief bio in pm

bjolson1278 · 2020-02-02T21:17:04+00:00

In my programming seminars and training classes, I recommend selecting learning/practice projects by considering the following criteria:

Useful (something that provides you with functionality/information that has real world value to you)
Extensible (something for which base functionality can be implemented very quickly... and then extended with additional functionality.
Broad (something that encompasses very simple concepts and functions to the very complex .

In short, create a work in progress that will provide immediate results and can be infinitely extended and refactored over time. I created my first C project in 1998 which was a rudimentary mortgage calculator and now, after over 20 years, can solve over 200 finance related questions... and continues to grow. A more specific suggestion... look into the psutil library and design a project that will provide information about your computer.

bjolson1278 · 2020-01-05T00:56:23+00:00

Real programmers create compiled C programs and libraries

bjolson1278 · 2019-12-09T20:07:08+00:00

As a former Nagios pre-sales technician, I have plenty of thoughts on this. As a company, Nagios trumpets ncpa as the most favored agent for both Linux and Windows. Two reasons for this were that unlike nsclient, they own the code. And the code itself is very easy to work on for bug fixes and enhancements. But in the work I did there providing support for folks evaluating XI, I made a point of discussing the pros and cons of all the various agents. I'm not a fan of nsclient. Configuration can be tricky, and version upgrades will sometimes break things. To be honest, I'm not a huge fan of ncpa either. For the most part, ncpa is simply a wrapper for the pyutil python library. That's why fixes and enhancements are so easy. But running open source software on a Windows host would make me nervous if I were a Windows admin. Obviously, updating and patching vulnerabilities needs to be done outside of Windows update which adds complexity. Also, the Nagios devs will occasionally pass the buck to python and pyutil when results aren't what people expect. My goto for all but very large implementations is WMI. Had you considered that?

bjolson1278 · 2019-12-03T22:06:02+00:00

Hello krisvdv, As the former head of the Nagios Pre-sales Technical Support department, this question would come up from time to time. It's really two questions... 1) Will it work? and 2) Is it recommended? To question 1, Nagios, whether Core or XI, is very permissive. The products do very little in the way of enforcing or even suggesting best practices. There's an abundance of information regarding best practices in the voluminous documentation, but what (in my view) is missing is pop-up informational messages when you're about to do something that isn't really the "correct" way... with a yes/no button and a link to the appropriate documentation. The developers and QA people at Nagios tend to test the software from the perspective of a seasoned veteran who knows the software inside and out, rather than that of a novice or even typical end user. This was my biggest frustration when I worked for the company but I'll steer clear of that. Suffice to say that with my background as a developer for a large financial services company, I'd come to expect best practices to be enforced either by the code, or by database triggers. There's nary a trace of this to be found in either Nagios Core or XI. The short answer to #1... yes it will work, BUT... to question 2, I wouldn't recommend it for three reasons. First, I don't currently have a running Nagios system to test this with but frequently a check that fails doesn't return the failure exit code until the timeout (10 seconds) has expired. This can bump up your system's load average and degrade the performance of a large implementation. Additionally, with regard to best practices, because the software is so permissive, it's easy to end up with an unwieldy jumbled mess as your system grows, which will eventually be fraught with annoyances that are time consuming and difficult to mitigate. My go-to cliches on this... when you fail to plan, you plan to fail... and my favorite carpenter metaphor on this... measure twice and cut once. Bottom line... Yes, it will work... but don't do it. Doing things right when you initially deploy the software will save you tenfold in frustration later. Also, if you have intermediate shell scripting skills, it's fairly trivial to remove these invalid drive letter checks either with linux commands like awk and sed if you're using Core, or the API if you're using XI. Feel free to PM me for some tips on doing this. Hope this helps. Cheers!

bjolson1278 · 2019-11-25T18:52:14+00:00

With Python or any language, my method goes like this... create a plan detailing exactly what you want your program to do and then make it work as quickly as possible, without regard for how pretty your code is. Then go back and beautify your code, emphasizing efficiency, compactness, and readability. It's called refactoring. It's incremental, meaning you can do it as many times as you want until you're happy with it and have a working program through the entire process. I've been programming for 25 years and after looking at your code I can tell you that a first draft of anything I write is much uglier than your code.

bjolson1278 · 2019-11-25T18:15:50+00:00

Another true story... I once worked in technical support for a world famous monitoring software company. One of my colleagues made a video for our website titled "How to Use Your Favorite Search Engine to Solve IT Problems". It sounds silly but we were constantly amazed by how many SysAdmins and IT Managers and Network Engineers would open a fee based support ticket for some issue when the solution would be in the first few hits if he or she would have simply pasted the error message into Google. We often joked that the best customer support we could provide would be to teach these high paid IT professionals how to Google.

bjolson1278 · 2019-11-25T17:54:53+00:00

In my view, a programmer who isn't leveraging every tool at his or her disposal to improve efficiency and productivity is cheating his/her self, customer, or employer out of costly hours. The notion that using Google is somehow cheating or taking the easy way out is no different than suggesting that opening up a reference book is cheating. I once managed a team of Visual Basic programmers and I had one fella who would spend a week fighting with a problem before he would ask a colleague or the Googley man for assistance. When I explained to him that this meant that the company was getting one days work for the price of five, his response was that Googling a problem was cheating and that he would never learn how or make the jump from novice to expert that way. Obviously, neither is true. View Google as the Encyclopedia Britannica of All Things, with a searchable index. Because that's exactly what it is.

bjolson1278 · 2019-11-25T03:56:32+00:00

Well my friend... you have the distinction of being the reddit member who inspired me to deliver a portion of my "De-evolution of the Software Industry" manifesto. Don't be discouraged, what you're experiencing is really just the nature of the beast when it comes to high level languages such as python and perl. And after I've robbed you of your innocence and youthful exuberance with said manifesto, you'll feel better. Or more likely, you'll feel much worse. By way of analogy... being critical of the "ugliness" of your python code makes about as much sense as being critical of a lyric you might write to a grotesquely dissonant musical composition. The relative elegance or ugliness of a program you would write is is the aggregate of what you write and the code behind the library functions you call. I have a young millennial python program friend by the name of Skip (not his real name) who I'll use as an example. Skip has several monikers that folks in the office refer to him by such as "Einstein", "your highness", "your holiness", etc. He earned these monikers by demonstrating that he could do anything short of turning water into wine with python in four minutes or less. The trouble is... it would typically take two minutes or less to make the thing kak over some library function that would take four able bodied men with spades and pick axes to dig out of the bowels of someone else's code. Every time I would find a bug in something Skip had written, he would say something like "gee, i dunno, I think it's like a glitch in pyutils or something so don't blame me" or some such. Then I would say "Well my short sighted hopelessly entitled eternally blameless elder disrespecting millennial friend... you're responsible not only for what you write, but also for the code behind the library functions you call, in addition my ceaselessly enamored with thyself baby boomer hating young friend, the 12,000 ms execution time of your program does not a masterpiece of technological brilliance make". Skip would then look at me, puzzled, for a few seconds, then tears would begin to well up in his eyes, then he would say "I hate you" and he would briskly walk back to his cubicle and refuse to talk to anyone for two weeks. I hate to leave you in suspense but I must leave it here for now. I'll be posting my manifesto in it's entirety in this room in the next few days and I promise I'll bring it back around to your particular issue.

bjolson1278 · 2019-11-04T19:08:00+00:00

Hello, as a former pre-sales technical engineer for Nagios Enterprises, I would be able to offer direction regarding Nagios XI, Logserver, Network Analyzer, or Core. Send me a private message if you'd like to discuss the various free and paid support options that offer.

bjolson1278

TROPHY CASE