You can subscribe to this list. I would LOVE to see this feature in OpenNMS. Whie it's great to know that my smtp, imap and pop3 servers are up, that really tells me next to nothing about how (or if) mail is flowing through the system. We've looked at some systems to do this in the past, but for one reason or another they've not quite done it. 'Tarus Balog' writes: there are some Nodes entry whose nodesysoid are not null but their interface or interfaces' issnmpprimary are not 'P' in IpInterface mostly are 'N',sometime are 'S' why? For an Interface to be considered an SNMP Primary interface, it must satisfy 1) its IP Address in the ipAddrTable must map to a valid ifIndex 2) it must exist in a package in collectd-configuration if not, it is set to 'N'. If more than one interface can be the SNMP primary interface, the one with the lowest IP address is chosen.

Free

In 1.1, if the interface is a software loopback interface (with a valid IP address other than 127.) it will be chosen. Is this behaviour already implemented in 1.1, or is it planned? And also, is there any way to force OpenNMS to choose a given interface? Case at hand here is routers with ethernet and serial interface, and no management, and I'd like to have a specific interface as primary interface (since I might have several customers with 192.168.x.x on the ether-side, this is not something I'd like to have end up as primary, sa might be the case if their serial line has an IP that is numerically higher). HTH-T -A - Alexander Hoogerhuis alexh@.

CCNP - CCDP - MCNE - CCSE +47 908 21 485 'You have zero privacy anyway. Get over it.' -Scott McNealy. Hello Adam, Please accept my appreciation for making such a good presentation which not only gives the product overview but also in detail about the configuration. This is really usefull for the opennms community. Best Regards, R.S.Sundar Systems Support Manager Future Software Limited 480-481,Anna Salai,Nandanam,Chennai - 600 035.INDIA Tel: 550 Extn: 377, Fax: 157 Email: sundarrs@., Web:.Original Message- From: discuss-admin@.

mailto:discuss-admin@.On Behalf Of adam@. Sent: Thursday, November 21, 2002 9:34 PM To: discuss@. Subject: opennms-discuss OpenNMS Presentation The first version of my OpenNMS presentation is available at the URL listed below if someone would like to take a look and offer comments.

Forwarded message from adam@. Date: Thu, 21 Nov 2002 10:46:16 -0500 From: adam@. Reply-To: members@. Subject: KLUG Members OpenNMS Presentation To: members@.

The OpenNMS presentation from this Tuesday (19Nov2002) has been posted as a PDF file on the FTP server and linked to from the Past Presentations page. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to:. This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message.

FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. Hello all, I have been wanting to write, for a few years, an SMTP throughput poller. I want it to not only connect to an SMTP server, but send a message, and receive that message over SMTP (or POP3, IMAP4, etc.), and measure throughput time. I would like for it to possibly even look at Received: headers and attempt to calculate hop-by-hop delays. In my experience over the last 7 years of dealing with enterprise mail systems, administrators who are not experts in SMTP and OS performance have a difficult time finding the root of email performance issues. This is made worse because there are many systems in series and/or parallel (usually both) that handle hundreds of thousands of messages a day.

Thourough and constant mail throughput monitoring of all parts of the system, in addition to system statistics gathering helps considerably in making capacity planning easier, as well as debugging (although having the ability to perform reliable, proactive capacity planning will minimize the latter). I would like my customers to be able to use OpenNMS for collecting and presenting this data.

Here is a little more thought-out idea of what I want to do: What do you think? Would you like to have this in OpenNMS?

Tyrell:

Do you know if anyone has already started or completed something like this (I have looked, and I do not). Thank you, - deej - Daniel (DJ) Gregor. Attachments: I think that OpenNMS should be added to RRD World, that is, the list of software products which use RRDTool which are listed on the RRDTool home page. Here is that page: I have asked Tobi (Tobias Oetiker) if he could add OpenNMS to the above-listed page.

He said sure and asked that I whip up a web page based on an existing tool listed at RRD World and send it his way. I have done so, but I wanted to run it by you folks first. You will find it attached, however the images might not work correctly. Please let me know if you have any comments. Have a great one, - deej - Daniel (DJ) Gregor. At 1:27 PM -0500 11/25/02, Zidovec, Eric wrote: How's about this for a silly idea. Make the patch as I originally suggested and then do the same thing under OS 10.2 that linux does for sh.

Create a symbolic link for bash over to zsh. If that's a plausible solution. It's least desirable to change what shell the OS thinks it's running. Mark - - Mark F. Murphy, Director Software Development Tyrell Software Corp.

At 11:08 AM -0700 11/25/02, Ian Wallace wrote: I don't know. What do people think? Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. I think the less dependencies on things outside java, the better. Relying on certain shells which may not be in the target OS is just another place for the software or the install process to break. In our port to MacOS X, we are looking at other areas where such dependencies exist and trying to reduce those dependencies.

Mark - - Mark F. Murphy, Director Software Development Tyrell Software Corp.

Ben - That would work for the build, but what about for the opennms.sh stuff? I'm thinking that the start/stop scripts could be converted to using something along the lines of generic /bin/sh functionality. I agree that after even looking at the build.sh script. Well it's a bit obtuse in places. Cheers ian On Mon, 2002-11-25 at 11:37, Benjamin Reed wrote: On Mon, 2002-11-25 at 13:08, Ian Wallace wrote: I was afraid of that. Hmmmm, the issue on Solaris (if I get this correct) is that there is a /bin/sh however since the scripts are written to only run with bash (or I guess zsh) they bomb miserably on Solaris (on linux /bin/sh is a link to /bin/bash. Which makes everything work just peachy).

I don't know. What do people think? Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. The other option is to somehow wrap the scripts so that they run under /bin/sh and detect and call the correct interpretor.

So you would call /bin/bash on linux, /bin/bash on solaris and /bin/zsh on Mac OS 10.1 but could call /bin/bash on OS 10.2. I would say that a better long-term goal is to do more work to make the build all work within ant, either with a custom task or two to fill out details, or with maybe xslt transforms or something like that.

The current build system is basically a bunch of hacks around things ant 1.3 couldn't do. It's likely either cleaner nowadays, or easier to write some java ant tasks to do the bits we need rather than rewriting the shell stuff. The shell stuff is. Scary, to say the least.

=) It has it's own internal consistency, but it's really obtuse to someone coming in new, or wanting to change anything. It makes more sense to make our build more 'normal'. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: - Ian Wallace - iwallace@. 303.218.2040 (w) 720.308.5696 (m) 303.218.2100 (f) eForce Managed Services, Denver CO Enterprise IT Solutions. On Mon, 2002-11-25 at 13:08, Ian Wallace wrote: I was afraid of that.

Hmmmm, the issue on Solaris (if I get this correct) is that there is a /bin/sh however since the scripts are written to only run with bash (or I guess zsh) they bomb miserably on Solaris (on linux /bin/sh is a link to /bin/bash. Which makes everything work just peachy).

I don't know. What do people think? Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. The other option is to somehow wrap the scripts so that they run under /bin/sh and detect and call the correct interpretor. So you would call /bin/bash on linux, /bin/bash on solaris and /bin/zsh on Mac OS 10.1 but could call /bin/bash on OS 10.2. I would say that a better long-term goal is to do more work to make the build all work within ant, either with a custom task or two to fill out details, or with maybe xslt transforms or something like that.

The current build system is basically a bunch of hacks around things ant 1.3 couldn't do. It's likely either cleaner nowadays, or easier to write some java ant tasks to do the bits we need rather than rewriting the shell stuff. The shell stuff is.

Scary, to say the least. =) It has it's own internal consistency, but it's really obtuse to someone coming in new, or wanting to change anything. It makes more sense to make our build more 'normal'. If I had to put my $.02 in, I would vote for the wrapper. A simple = script that calls uname and determines the OS could then call an OS = specific script. Chris -Original Message- From: Ian Wallace mailto:iwallace@. Sent: Monday, November 25, 2002 1:08 PM To: Discuss OpenNMS Cc: discuss@.

Subject: Re: opennms-discuss OpenNMS 1.1.0 Running on Solaris 8/? Patch suggestions. Comments requested please I was afraid of that.

Hmmmm, the issue on Solaris (if I get this correct) is that there is a /bin/sh however since the scripts are written to only run with bash (or I guess zsh) they bomb miserably on Solaris (on linux /bin/sh is a link to /bin/bash. Which makes everything work just peachy).

I don't know. What do people think? Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. The other option is to somehow wrap the scripts so that they run under /bin/sh and detect and call the correct interpretor.

So you would call /bin/bash on linux, /bin/bash on solaris and /bin/zsh on Mac OS 10.1 but could call /bin/bash on OS 10.2. Cheers ian On Sat, 2002-11-23 at 23:24, Johnie Wardlaw wrote: There is an issue with Mac OS 10.1 since /bin/bash does not exist in=20 Apple's installation for that version. On Mac OS 10.1 /bin/sh is a copy of=20 /bin/zsh which works fine with the OpenNMS scripts. If you make this change=20 it will no longer build or run on Mac OS 10.1. Mac OS 10.2 does have /bin/bash in the distribution but I don't want to=20 force everyone to run that version. I would really like to avoid installing=20 bash if I can. What is the issue with using /bin/sh on the Solaris platform?

Maybe a=20 better solution is to make the scripts Bourne shell compliant so they work=20 correctly on other Unix platforms like AIX and HP-UX as well. Johnie At 08:37 PM -0500, you wrote: On Saturday, November 23, 2002, at 06:16 PM, Ian Wallace wrote: Personally I see no issue what so ever with changing /bin/sh to /bin/bash since the scripts need it anyway. If no dissents I'll do this on Monday. Send along the diff for 2 and 3 (or just the line to modify) and we'll add them in and check them into CVS. The more platforms that we run on. The more folks will use the tool (my two cents).

Hdrcaposx re-write for mac. Nov 29, 2018 - Moving to a new Mac? Learn how to move your files to your new Mac. Do this before you erase the hard drive or follow any other steps. Jul 22, 2008 - Greg Ward's HDRcapOSX has been largely re-written to accommodate the changes in Mac OS X and the Canon SDK since the original version. Jun 29, 2016 - Mac OS X software for HDR capture using Canon cameras. The re-write was carried out by Denis Fan and supported by EPSRC grant.

By all means. I thought we caught them all last time when we merged the=20 solaris patches. If not, that's a bug. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: -=20 Ian Wallace - iwallace@.

303.218.2040 (w) 720.308.5696 (m) 303.218.2100 (f) eForce Managed Services, Denver CO=20 Enterprise IT Solutions. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to. Well, How's about this for a silly idea. Make the patch as I originally suggested and then do the same thing under OS 10.2 that linux does for sh. Create a symbolic link for bash over to zsh. If that's a plausible solution. Just another 2 cents worth from me, Eric On Mon, 2002-11-25 at 13:08, Ian Wallace wrote: I was afraid of that.

Hmmmm, the issue on Solaris (if I get this correct) is that there is a /bin/sh however since the scripts are written to only run with bash (or I guess zsh) they bomb miserably on Solaris (on linux /bin/sh is a link to /bin/bash. Which makes everything work just peachy).

I don't know. What do people think?

Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. The other option is to somehow wrap the scripts so that they run under /bin/sh and detect and call the correct interpretor. So you would call /bin/bash on linux, /bin/bash on solaris and /bin/zsh on Mac OS 10.1 but could call /bin/bash on OS 10.2. cheers ian On Sat, 2002-11-23 at 23:24, Johnie Wardlaw wrote: There is an issue with Mac OS 10.1 since /bin/bash does not exist in Apple's installation for that version. On Mac OS 10.1 /bin/sh is a copy of /bin/zsh which works fine with the OpenNMS scripts. If you make this change it will no longer build or run on Mac OS 10.1. Mac OS 10.2 does have /bin/bash in the distribution but I don't want to force everyone to run that version.

I would really like to avoid installing bash if I can. What is the issue with using /bin/sh on the Solaris platform?

Maybe a better solution is to make the scripts Bourne shell compliant so they work correctly on other Unix platforms like AIX and HP-UX as well. - Johnie At 08:37 PM -0500, you wrote: On Saturday, November 23, 2002, at 06:16 PM, Ian Wallace wrote: Personally I see no issue what so ever with changing /bin/sh to /bin/bash since the scripts need it anyway. If no dissents I'll do this on Monday.

Send along the diff for 2 and 3 (or just the line to modify) and we'll add them in and check them into CVS. The more platforms that we run on. The more folks will use the tool (my two cents).

For

By all means. I thought we caught them all last time when we merged the solaris patches. If not, that's a bug. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: - Ian Wallace - iwallace@. 303.218.2040 (w) 720.308.5696 (m) 303.218.2100 (f) eForce Managed Services, Denver CO Enterprise IT Solutions. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to:. I was afraid of that.

Hmmmm, the issue on Solaris (if I get this correct) is that there is a /bin/sh however since the scripts are written to only run with bash (or I guess zsh) they bomb miserably on Solaris (on linux /bin/sh is a link to /bin/bash. Which makes everything work just peachy). I don't know. What do people think? Should we go with the lowest common denominator approach (basically rewrite for /bin/sh which could be a pain I haven't looked at the scripts yet.) or force people to install bash as it's what's need to run anyway. The other option is to somehow wrap the scripts so that they run under /bin/sh and detect and call the correct interpretor.

So you would call /bin/bash on linux, /bin/bash on solaris and /bin/zsh on Mac OS 10.1 but could call /bin/bash on OS 10.2. Cheers ian On Sat, 2002-11-23 at 23:24, Johnie Wardlaw wrote: There is an issue with Mac OS 10.1 since /bin/bash does not exist in Apple's installation for that version. On Mac OS 10.1 /bin/sh is a copy of /bin/zsh which works fine with the OpenNMS scripts. If you make this change it will no longer build or run on Mac OS 10.1. Mac OS 10.2 does have /bin/bash in the distribution but I don't want to force everyone to run that version. I would really like to avoid installing bash if I can. What is the issue with using /bin/sh on the Solaris platform?

Tyrell: Opennms For Mac Windows 10

Maybe a better solution is to make the scripts Bourne shell compliant so they work correctly on other Unix platforms like AIX and HP-UX as well. Johnie At 08:37 PM -0500, you wrote: On Saturday, November 23, 2002, at 06:16 PM, Ian Wallace wrote: Personally I see no issue what so ever with changing /bin/sh to /bin/bash since the scripts need it anyway. If no dissents I'll do this on Monday. Send along the diff for 2 and 3 (or just the line to modify) and we'll add them in and check them into CVS. The more platforms that we run on. The more folks will use the tool (my two cents).

By all means. I thought we caught them all last time when we merged the solaris patches.

If not, that's a bug. discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: discuss mailing list (discuss@.) To subscribe, unsubscribe, or change your list options, go to: - Ian Wallace - iwallace@. 303.218.2040 (w) 720.308.5696 (m) 303.218.2100 (f) eForce Managed Services, Denver CO Enterprise IT Solutions. Can you give me a quick overview of how you went about reverting to 1.40? When you say you left RRD, do you mean you just leave the RRD directory, or is there more to it? Just trying to figure out if I need to uninstall OpenNMS first, etc.

'Rickards, Keith' wrote: Well, that's what I ended up doing with so many dependencies. I left RRD however. Seems to work fine. Keith -Original Message- From: James Kilton mailto:kilton9@. Sent: Friday, November 22, 2002 11:45 AM To: discuss@.; discuss@. Subject: Re: opennms-discuss OpenNMS 1.02 occasionally hanging on RedHat 7.3.

Saw that, but couldn't find the file referenced in the document, so I figured my issue was different. Perhaps I'll try the fixes listed in the document before trying to revert back to 1.4.0, since the former sounds easier. Does OpenNMS need reinstalled after downgrading Java? - 'Jalon Q. Zimmerman' wrote: See the online FAQ at the opennms.org website unter 'Troubleshooting' and 'OpenNMS hangs after about 1 hr.' :) Jalon At 01:32 PM, you wrote: Hello.

I'm evaluating OpenNMS on a RedHat 7.3 system for SNMP monitoring. Every couple of days on averageI'll notice that the polling has stopped. Trying to check the status of the processes or stopping OpenNMS alltogether just results in the command hanging.

See all features. Virtual analogue with classic architecture plus extras. 2 oscillators, noise, ring modulator. 2 LFOs with 8 waveforms, host-syncable. Audio source mixer with authentic overdrive and filter feedback.

Twin filter related to Diva (early model). Unison with up to 8 voices. Analogue-type ADSR envelopes, loopable or LFO-triggered. Small modulation matrix with depth modulation from a second source. Chorus effect with 3 modes. MIDI learn / unlearn for hardware control. Resizable UI from 70% to 200%.

Skinnable UI. Over 580 factory presets. History Tyrell is the name of a project by the German online magazine Amazona.de. A reader survey and follow-on forum posts provided a pool of ideas for a low-cost hardware analogue synth, which Mic ‘Moogulator’ Irmer collected and used to develop quite a powerful concept. Based on a design similar to Roland’s classic Juno 60, a few modules and novel features could be added without making the product too expensive.

However, it soon became obvious that developing the hardware would have taken years, so Urs offered to turn the core design into a freeware softsynth. That was late 2010. Only a few weeks later, TyrellN6 was out for beta testing. After some serious bug-fixing and fine tuning, the final release version became available in April 2011. Version 3 In April 2013 we released TyrellN6 version 3, which now supports VST3. The new user interface was designed by Ryo Ishido. Download TyrellN6 from here: and scroll down until you see the Mac OS X, Windows and Linux links.