Using pysnmp , can I create a simple v2c get command responder for sysDesc , without engine-id ?
I am working on an application where I need to create a responder thread during system initialization.
For as long as you are using SNMPv3 framework, everything there revolves around the concept of SNMP engine. So you have to use it.
But if you resort to older SNMP design (which is SNMP v1/v2c) - there is no SNMP engine there at all.
Here you will find the example script which implements SNMP Command Responder over SNMP v1/v2c architecture. The script has a some extra functionality (like MIB object and IPv6 support) which you can just drop.
Related
I'd like to get an indication about the context in which my process is running from. I'd like to distinguish between the following cases :
It runs as a persistent scheduled task (launchDaemon/launchAgent)
It was called on-demand and created by launchd using open command-line or double-click.
It was called directly from command-line terminal (i.e. > /bin/myProg from terminal )
Perhaps is there any indication about the process context using Objective-c/swift framework or any other way ? I wish to avoid inventing the wheel here :-)
thanks
There is definetely no simple public API or framework for doing this, and doing this is hard.
Some parts of this info possibly could be retreived by your process itslef with some side-ways which will work on some system versions:
There is a launchctl C-based API, which you can try to use to enumerate all
launch daemon/agent tasks and search for your app path/pid. You may
require a root rights for your process for doing this.
Using open command-line sometimes could be traced with environment
variables it sets for your process.
Running directly from command-line could leave responsible_pid filled correctly (which is private API from libquarantine, unless you are observing it with Endpoint Security starting from 11.smth version)
All this things, except launchctl API, are not public, not reliable, could be broken at any time by Apple, and may be not sufficient for your needs.
But it is worth to take them a try, because there is nothing better :)
You could potentially distinguish all cases you want using system events monitoring from some other (root-permitted) process you control, possibly adopting Endpoint Security Framework (requires an entitlement from Apple, can't be distributed via AppStore), calling a lot of private APIs and a doing bunch of reversing tricks.
The open resource I could suggest on this topic is here
The question says it all. When I say interface, I mean what the user interacts with completely. I've got an extensive C background and know enough to make a rudimentary OS but I'd rather not reinvent the OS. Using a linux build (or something else if better) such as Arch I'd like to know the most appropriate and extensive way to be the lowest layer over the OS.
The closest example I can think of to what I'd like is how Android Phones have perfectly usable interfaces with user permissions handled by the OS but it's a modified linux kernel. Is modifying the kernel the best way to go about it, and if so any pointers to setting up any sort of visual system such as OpenGL.
On most systems, one accesses the operating system by triggering an exception of some kind. Usually a processor has some kind of "trigger an exception that calls a system service" instruction. Each system service is identified by a number and that number is passed as either an operating to the exception or as a register value (depending upon the processor).
The normal practice is to have a wrapper function for each system service designed to be called from some high level language. The wrapper unpacks the parameters (usually on the stack) and sets up the hardware registers using those parameters. Then it triggers the exception to invoke the system service. This causes to processor to enter a protected mode and execute the system service. When the system service completes, the wrapper extracts the return values from hardware registers, then packs the result in to the return parameters for the caller.
I have written a Loadable Kernel Module (LKM) which wraps the audio-driver under /dev/snd/pcmC0D0p .
Therefore I moved pcmC0D0p to pcmC0D0p_bak, renamed my driver to pcmC0D0p and passthru every command like MMAP, IOCTL etc. (but doing other things before forwarding the MMAPed-data).
This is bad, I know (but it's my first step in linux-programing) but it worked.
Today, I read in an article about Userspace device drivers.
Now I'm wondering: should this really be possible? Write a "driver" with userspace-code, implemented methods like MMAP & IOCTL and put it in place of a normal kernel-device (/dev/snd/pcmC0D0p)?
It isn't, isn't it?
IF it's possible, has anyone a simple example, a reference? Anything is really welcome!
It is possible to write userspace device drivers, but not quite in the way you're thinking.
An example is the uio_pci_generic module, this can be programmed (via /proc) with the ID of a PCI device and will make the device's memory available to you via mmap. You can receive interrupts by blocking on a read call.
Note how this does not allow you to pretend to be a driver, only to perform driver-like actions (communicating directly with a hardware device, receiving interrupts, etc). No userspace program can ever service a call to ioctl, or expose itself as a character device, without the help of some kernel module.
I have a perl app which processes text files from the local filesystem (think about it as an overly-complicated grep).
I want to design a webapp which allows remote users to invoke the perl app by setting the required parameters.
Once it's running it would be desirable some sort of communication between the perl app and the webapp about the status of the process (running, % done, finished).
Which would be a recommended way of communication between the two processes? I was thinking in a database table, but I'm not really sure it's a good idea.
any suggestions are appreciated.
Stackers, go ahead and edit this answer to add code examples or links to them.
DrNoone, two approaches come to mind.
callback
Your greppy app needs to offer a callback function that returns the status and which is periodically called by the Web app.
event
This makes sense if you are already using a Web server/app framework which exposes an event loop usable from external applications (rather unlikely in Perl land). The greppy app fires events on status changes and the Web app attaches/listens to them and acts accordingly.
For IPC as you envision it, a plain database is not so suitable. Look into message queues instead. For great interop, pick AMPQ compliant implementation.
If you run the process using open($handle, "cmd |") you can read the results in real time and print them straight to STDOUT while your response is open. That's probably the simplest approach.
(I am not talking about Hibernate or NHibernate ORM )
Windows OS (and some linux version) have 'Hibernate' option to save the state and shutdown the Machine. And Later when we restart we can resume from previous stored state.
Is there any way to Hibernate an application alone ? I mean i want to close the application by saving its state and later when i start the application, it should resume from the previous stored state.
Is there any third party tools available, Or Can i add the feature to my application by using third party libraries ?
Edit: I have a .Net WinForm application with tabbed interface and more than 50 input controls . I need a solution to shutdown the application , and restart later with same values on textboxes. I can write a routine to store and restore all textbox values. But i am looking for some generic method, which can work for any application.
You could bundle your application with its OS as an "appliance" and use something like VMWare to hibernate the whole virtual machine.
Or you could use Smalltalk.
(Both approaches are not something you can easily plug into an existing application, but hey, what you are asking for does seem to call for "platform-level support").
Microsoft MED-V Application virtualization might be able to do such thing, would be nice to have more app virtualization features in the OS itself in the future
Objects containing memory that you own are not too difficult. The problem comes with resources owned by the OS (windows, threads, semaphores etc). You could write something that saved/restored the state of these OS-owned resource but you still need to destroy/recreate them.
What are your goals for doing this?
There isn't a framework for this. The simplist way to achieve this, as you suggested, is to store your data in serializable objects and serialize them out into a file and then serialize them back in later.
That's not difficult, and gets you most of the way. It's also fairly generic-- you only need to write a few lines to serialize any amount of serializeable data in and out.
For more complex things, state like where the cursor was previously etc, should be pushed into a serializable object when the user attempts to close the app and manually pushed back when they load the app.
... but chances are your users aren't going to care about stuff like that, they probably just care that there data is back to how it was.