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.
Related
I'm starting to manage my dotfiles in my linux mint(ubuntu system). So, here I am writing a bash script automating the installation of my preferred apps. But I want that script to be system independent. Suppose when I become a mature user in linux system, I might want to switch to arch or something that's why I want to make dynamic scripting file which doesn't throw an error because my script says to download apps using apt or apt-get package manager and my system has pacman or dnf package manager.
How can I find out the system package manager?
If you want to manage systems on multiple distributions I recommend to look at a configuration management tool instead of writing something yourself.
The skills learned will be valuable in other situations as well.
Configuration management tools like ansible, chef or puppet have already solved the problem of determining the package manager of a specific distribution. (And will often hide the details in a more generic module.)
Also keep in mind that even with this information you will have to take into consideration that distributions can and do use different names for the same package.
E.g. Red Hat based distributions have a package called httpd for the apache web server. Debian based distributions will use apache2 packages instead.
Again configuration management tools allow you to define variables for each distribution family.
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.
I know how does Cask works and all the benefits I can get when using it in a brand new system, but what I want to know and I don't seem to find and answer anywhere is... would it be a good idea if I delete my previous installed software and replace them with cask versions? would I see some kind of improvement, or would it be a waste of time?
There's no real advantage to reinstalling existing binaries using homebrew-cask. It's strictly a workflow improvement for when you need to install various softwares. For instance, if you wanted to have a script to install all your regularly used binaries on a new computer, that would be more efficient than manually visiting several sites and downloading, installing, etc.
Traditional software installation on some apps have automatic updates and some require the user to visit the apps website to do an update. Once the update is downloaded the user is required to click next, next, agree etc whilst it is satisfactory to do this for a few apps it can be time consuming.
One of the advantages of HBC is that it does an install without user interaction or sometimes a prompt for admin password. So if you do a reinstall of the OS you can use HBC to reinstall the additional apps.
At present there is no provision for updates using HBC so i have written scripts that take of some issues.
The scripts will create a file that lists the files to be updated including apps that are defined as latest. You can then modify the file to suit your requirements and install updates using my olinst script.
For more information visit my github.
https://github.com/pacav69/homebrew-homebrew-caskroom-offline-installer
I tried to adopt Vagrant in our team. I created a Vagrantfile and make provisioning in some way. Everything works as charm, but ...
It's unclear for me how I can automate some routine tasks like:
running django(I use django, but it's framework agnostic problem) dev server on 0.0.0.0
running grunt watcher
providing a separate console for django-specific commands
It is looks like vagrant not intended to help with this kind of automation and I look for some community adopted way to do that. I goggled and found nothing.
I see a few way to that:
bootstrap.sh script but messy and hard to mantain
something like tmuxinator -- requires tmux on host machine and now it's impossible to put tmuxconfig in project repo
etc
What is the 'canonical' way to resolve this problem?
P.S.: Please, think about designers, manual testers and other guys which like to use tools as is
In general you are best off using a provisioner. To be honest, a bootstrap.sh file is a good place to start unless you want to learn the ins and outs of something like chef / ansible / salt / puppet. If you do you might want to start at salt (SaltStack) because it is written in python which I'm guessing you use given the django angle.
For your specific questions:
Part of the point of vagrant is it lets you develop against real stacks and real web servers so you can avoid the "oh, that don't quite work the same on apache" moment that often comes in projects. So for your first question I would look at how to provision the app behind apache / nginx or whatever you are using for the production web servers.
Because of the shared file systems users can just run grunt locally on the host machine. This also lets grunt do things like hook into OSX notifications.
I'm not familiar with tmuxinator so I'm not sure how to start here. But if it is a service that the server really runs then you should figure out a way to package the install and deploy it to the provisioned VM. As for configuration, is it possible to get a dev config in the repo?
Same as #Wyatt, I recommend use Vagrant with provision tools, such as puppet, saltstack, chef, anisble, etc. These tools are created for the requirements you ask for, and most are open source. Choice is no wrong, you can start learning from any one, they are similar.
With that, you can quickly and easily run several VM servers with all applications installed automatically. With the customised Puppet codes or chef cookbooks, you can update them any time and provision to VM easily, you can re-use them for your PROD environment as well.
Take some times to learn one of these automation tools first, you will get benefit to save a lot of time.
I use Puppet, and recommend the best puppet book PRO PUPPET to you. It has all you need.
Ok, so I'm a bit late jumping onto the Vagrant band-wagon, but figured it's about time I did.
Brief background: I've been a freelance developer for quite some time now developing solutions based on Magento and Drupal, and have finally gathered enough demand to warrant the need to build up a team. Previously, whenever I started development on any new project, I use to clone a preconfigured base VM in Virtualbox, and use that. Of course there were still configurations to do on it until I could start with actual development. Every project's web files therefore all resided inside /var/www/projectname on an Ubuntu VM.
Now I've read up on why I should be Vagrant, especially considering that I now have a team of 4 developers working with me, but I would appreciate any feedback on the following questions I have:
Moderator note: I know this isn't exactly asking a programming question, so please advise if this could be turned into a wiki, as I'm sure that feedback into this will help someone just like me.
I am still reading through the Vagrant docs, so please be kind...noob questions ahead!
I now work on a Mac. Does it matter if I use Parallels, and another developer uses VirtualBox on Windows if we need to share or collaborate on projects?
When I issue the command, vagrant up for an existing project, will it start the VM up as I would in VirtualBox or will it recreate the VM?
Is the command vagrant halt the same issuing sudo poweroff in Ubuntu, for example?
I currently use PhpStorm and its SFTP feature for project files synchronization with the option to exclude certain files on the remote server (VM) from being imported and sync'ed...will I be able to specify the same using Vagrant folder sharing?
Could I easily zip or archive a Vagrant VM, move it to a file server, and then "re-import" when and if needed? (example bug fixes, or new feature enhancements)
What do we use to easily provision VMs for common projects? Should we being using Puppet, Chef, Puphpet or Salt? I've seen that Puphpet provides a nice GUI to create a vagrantfile which I'm sure once generated, we could customize for future projects. At a very basic level, we need to ensure that certain applications are installed onto the server (zip, phpmyadmin, OpenSSL, etc.), certain PHP settings, PHP and PEAR modules, and Apache settings. I already have base VMs set up as I'd like them for both Magento projects as well as Drupal projects.
EDIT: I should also add that I use to enable Host Adapter in VirtualBox (on Windows), configure the VHost inside Ubuntu, and then update my host machine's hosts file with something like 192.168.56.3 drupalsite1.dev. So I'm unsure if Port Forwarding would be better to use? I'm not very clued up on that I must admit.
Like i said - noob questions! However, I would really appreciate any feedback on these questions. My deepest thanks!
Most of what you are asking is subjective so common sense and experience are the best tools.
I recommend all team members use the same provider (parallels isn't officially supported) and virtualbox is readily available. The base boxes, by provider, could have slight variances, you never know.
Vagrant will start the vm similarly but vagrant also does other things like configuration the network, hostname, shared folders, etc. Not quite the same. The big power lies in the capability to be able to teardown the environment and bring it back in a cleanly provisioned state.
Basically, yes.
Yes, your vagrant VMs are just like your own mini cloud. You would interact the servers similar to the way you'd interact with external boxes.
Yes, the simple answer is that it's called packaging and you can share the resultant .box. However, it's good practice to keep the base box and provisioning scripts under CM so you can rebuild and modify as needed.
For provisioners, I think it is dependent upon your experience and your familiarity with the provisioner language and how much you want to invest in learning them. Look through the provisioner support and see what fits your need and budget. Chef has a very steep learning curve, in my experience, but also has a lot of thought built in. Most provisioners have wide libraries of available installation "scripts".
The host adapter can be handled identically in vagrant.
Learn by doing, I recommend going down the table of contents (navbar) of the vagrant docs and trying each step where it makes sense. Then make your decisions.
That is my 2 cents. Hope this helps!