I am trying to design a system to communicate between a manager computer and a single embedded agent using Net-snmp.
One thing that does not seem to be answered clearly is the difference in base software that you need on the manager versus the agent computers.
On most tutorials they seem to install "snmp" on both the agent and the manager and additionally download "snmpd" on the agent.
My current understanding is you need the base "snmp" on the manager, and you need "snmpd" on the agent. But my confusion comes from whether you need to install "snmp" on the agent. It seems like you would bloat the agent with a lot of manager specific software.
I understand this would make sense for if you want to query data locally in the agent, but in the situation you want to reduce the agent software size for an embedded system do you need to install "snmp" on it, and if you do is there any way to remove manager specific files?
Thanks!
Edit: Just a little bit more info to better specify my question or where I am having confusion. On the faq, it has things like including ""--enable-mini-agent" when compiling snmp for the agent, which specifies you need to install "snmp" for the agent. But there was also a separate tutorial that did not include "snmp" on the agent which is why I am confused at whether you would need "snmp" on the agent and if you do not then what benefit it has over not including it. Thanks.
Thank Lex, the bit "it ships as a bundle" was the bit I was missing as this was not mentioned anywhere, so for someone new this "obvious once you know it" piece of information not being mentioned explicitly on the site was important for my overall understanding.
Basically my overall confusion on thinking the net-snmp source package was not a bundle for the agent and manager came from this tutorial I followed: https://www.maketecheasier.com/net-snmp-part-1/, as it was the only tutorial that got net-snmp to work correctly. My confusion was that he was installing the bundled net-snmp package from the source, but was also installing a seperate snmp daemon via "sudo apt-get install snmpd". I was assuming therefore that you needed to install snmpd separate to get the daemon working.
The tutorial did not mention that snmpd is actually already included in the source and you do not need to do the "sudo apt-get install snmpd" command for snmpd to work as you are just doing a redundant download and install.
From what I understand, Ansible is agentless and can connect using OpenSSH. I believe that Ansible requires Python. We currently do not have Python available (Jython is available) on this mainframe, and I'm not sure that a reliable port exists, although I have found some possibilities (e.g. http://www.rocketsoftware.com/zos-open-source/python?ver=2.7.6).
Is Python, or anything else, required on the target server/mainframe to use Ansible to deploy files?
According to
the install docs,
the target machine should only need a functioning sshd and a pretty
old Python version.
You may be somewhat limited on the
modules
you can use with ZOS, but some will work, and you could probably write
more yourself.
I'm using nix as a package manager on OSX. I've installed postgres. Now I'd like to start and stop the postgres server (and other related utilities). I can write a script to do this manually, and edit my config. But, is there a "best practice" way to do this on OSX? E.g. I found postgres configs under ~/.nix-profile/share, are there startup scrips for OSX somewhere?
I've not come across anything related to the nix project for running services in the nixpkgs repo directly on OS X.
If you just have a few services you want to run I believe you'd have to put the scripts together yourself as you suggest.
Alternatively disnix should do what you're after but it might be a bit overkill just for one machine.
Another option would be to deploy a nixos configuration into a (optionally headless) virtualbox instance with nixops.
I'm using this setup myself for a different use case, but it should certainly also support yours.
disnix, nixos and nixops are documented together with nix/nixpkgs on the nixos.org page.
For the life of me I can't find the tool I ran across yesterday. It's not Homebrew (I already use Homebrew) what I found was a tool that I think was built in Ruby that allowed for installing regular .app applications and otherwise scripting most of an OS X config (I assume preferences and other things). I already have a script based on the Thoughtbot Ruby environment that I'm able to run successfully but I'd love the ability to script installing the other 20-30 apps that I use so that it would make reformatting a little easier.
Thanks!
You might be thinking of a configuration management tool like Chef. You can use this to bring up a system from a bare OS to the configured state defined in your recipes.
Personally I've only used it for setting up linux servers, but I think it would work just as well for launching installers and running configuration scripts on a Mac.
This is the tool I was looking for.
https://github.com/benhoskings/babushka
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.