net-snmp, get/set sent to shell with object name not OID (linux) - net-snmp

Someone, who used to work here, configured a linux box to send snmpset/get requests using MIB object names instead of OIDs. snmpget is called in a shell with some familiar switches and then, bam, just the object name. How is he doing this? Is there a way to configure snmp in linux so that you can do this? I am hearing from coworkers that perhaps there is a way to configure netsnmp on your machine to do the conversion from object names to OIDs.

So we figured this out. In Linux, snmp can be installed on the command line with sudo apt-get install snmp. The syntax is the same as net-snmp. With a basic installation, you have to pas OIDs (which are period separated strings of integers) into snmpget/set to get a response. However, you can see here everything you need to set up your machine to take in the object names. You need to add your mib files to a directory and then point snmp.conf to your mibs.

Related

How do I input a password from a makefile or system( ) call?

I'm working on a C project that makes connections to remote servers. Commonly, this involves using some small terminal macros I've added to my makefile to scp an executable to that remote server. While convenient, the only part of this I've not been able to readily streamline is the part where I need to enter the password.
Additionally, in my code, I'm already using system() calls to accomplish some minor terminal commands (like sort). I'd ALSO like to be able to enter a password if necessary here. For instance, if I wanted to build a string in my code to scp a local file to my remote server, it'd be really nice to have my code pull (and use) a password from somewhere so it can actually access that server.
Does anyone a little more experienced with Make know a way to build passwords into a makefile and/or a system() call in C? Bonus points if I can do it without any third-party software/libraries. I'm trying to keep this as self-contained as possible.
Edit: In reading responses, it's looking like the best strategy is to establish a preexisting ssh key relationship with the server to avoid the login process via something more secure. More work up front for less work in the future, by the sound of it, with additional security.
Thanks for the suggestions, all.
The solution is to not use a password. SSH, and thus SCP, has, among many many others, public key authentication, which is described all over the internet. Use that.
Generally, the problem you're trying to solve is called secret management, and the takeaway is that your authentication tokens (passwords, public keys, API keys…) should not be owned by your application software, but by something instructing the authenticating layer. In other words, the way forward really is that you enable SSH to connect on its own without you entering a password by choosing something that happens to not be an interactive authentication method. So, using a password here is less elegant than just using the generally favorable method of using a public key to authenticate with your server.
Passing passwords as command line option is generally a bad idea – that leaks these passwords into things like process listings, potentially log entries and so on. Don't do it.
Running ssh-keygen to create the keys. Then, adding/appending the local system's (e.g) .ssh/id_rsa.pub file to the remote's .ssh/authorized_keys file is the best way to go.
But, I had remote systems to access without passwords but the file was not installed on the remote (needing ssh-keygen to be run on the remote). Or, the remote .ssh/authorized_keys files did not have the public key from my local system in it.
I wanted a one-time automated/unattended script to add it. A chicken-and-the-egg problem.
I found sshpass
It will work like ssh and provide the password (similar to what expect does).
I installed it once on the local system.
Using this, the script would:
run ssh-keygen on the remote [if necessary]
Append the local .ssh/id_rsa.pub public key file to the remote's .ssh/authorized_keys
Copy back the remote's .ssh/id_rsa.pub file to the local system's .ssh/authorized_keys file [if desired]
Then, ssh etc. worked without any passwords.
UPDATE:
ssh_copy_id is your fried, too.
I had forgotten about that. But, when I was doing this, I had more complex requirements.
The aforementioned script would merge/combine all the public keys and update all the authorized_keys files on all the systems. This would be repeated anytime any new system was added to the mix.
you never need to run ssh-keygen on a remote host, especially not to generate an authorized_keys file. –
Marcus Müller
I think that was inferred but not implied as a requirement [particularly in context]. I hope the answer wasn't -1 for that.
Note that (1) ssh-keygen is needed for (3) copy back the public key.
Ironically, one of the tutorial pages for ssh-copy-id says run ssh-keygen first ...
It's been my exerience when setting up certain types of systems/clusters (e.g. a development host/PC and several remote/target/test ones), if one wants to do local-to-remote actions, invariably one wants to do:
remote-to-local actions -- (e.g.) I'm ssh'ed into a remote system and want to do rcp back to the development system.
The remote system needs to do a git clone/pull from [and, sometimes, git push to] the local git server.
remote-to-remote -- copying/streaming data between target systems.
This requires that each system have a private/public key pair and all systems have an authorized_keys file that has the public keys of all the other systems.
When I've not set up the systems that way it usually comes back to haunt me [usually late at night when I'm tired]. So, I just [axiomatically] set it up that way at the outset.
One of the reasons that I developed the script in the first place. Also, since we didn't want to have to maintain a fork of a given system/distro installer for production systems, we would:
Use the stock/standard distro installer CD/USB
Use the script to add the extra/custom config, S/W, drivers, etc.

How do I configure ABRT to store core files for my unpackaged programs in the current working directory?

I'm using Fedora 25 which uses abrt to manage my core dumps. Following the documentation I've set "ProcessUnpacked" to "yes", and I can see my corefiles when a program I'm maintaining coredumps. Unfortunately those cores are stored in /var/spool/abrt, which is unsatisfactory to me for a variety of reasons.
I would like to configure abrt to store core files (or the entire coredump info directory) in the current working directory, when it detects that it is processing an unpackaged program. Can someone tell me how to do this? If there's anything special I need to know to keep selinux happy, I'd appreciate that info as well.
I'd actually recommend instead configuring your system to use coredumpctl. See https://fedoraproject.org/wiki/Changes/coredumpctl for the plan to make this the default in Fedora 26. Making this the default on your system now is easy:
sudo systemctl disable --now abrt-ccpp.service
sudo systemctl enable --now abrt-journal-core.service
You may find the coredumpctl management tool to be convenient. If you don't want this at all, disable both of the services above and replace the file /usr/lib/sysctl.d/50-coredump.conf with a symlink to /dev/null. (And/or otherwise set /proc/sys/kernel/core_pattern to a filename, like the default core.)

How to get harddrive serial number in C or asm without wmi

how to get harddrive serial number(not the volume # wich change at each reinstall of windows) in C or asm, without wmi (cause wmi required admin right). Any clue would be helpfull cause right now i found nothing on web in C without wmi, in dayss of searching... Thank you.
EDIT : For windows system
Please try my open source tool, DiskId32, which also has the source code at http://www.winsim.com/diskid32/diskid32.html . I only have an Win32 version at this time. Maybe some day I will add a Win64 version.
Hard drive serial number and other information about the harddrive like firmware version, etc. can only be obtained using SMART as far as I know and that requires special ioctls to the the block device node (/dev/sda or /dev/sdb) which is usually not available to a regular user.
I know there is a tool called smartctl which does exactly this:
sudo smartctl -i /dev/sda
Similar tools exist (hdparm, lshw, etc.) as well.
As far as trying to figure it out this info without being a privileged user, it might be possible only if it is exposed via /proc or /sys which I highly doubt is being done in the current SATA block device drivers.

SNMPd: Cannot open /proc/bus/pci

I cross-compiled NET-SNMP 5.7.1 from sources to a PowerPC using ELDK-3.1.
When I try to load the snmpd daemon in my embedded board, I see the message:
# snmpd -f -Lo
pcilib: Cannot open /proc/bus/pci
pcilib: Cannot find any working access method.
Of course my PPC board has no PCI, and I wonder why is netsnmp looking for it.
In more than one place I see this same message (sourceforge, mail-archive, google-groups), but ir has no answer at all. Another variant, with a little but unhelpful responses at (archlinuxarm).
Can anybody please help me?
I'm assuming you're on a Linux target.
Net-SNMP's changelog lists "[PATCH 3057093]: allow linux to use libpci for creating useful ifDescr strings".
The configure script will search for an available libpci, and, having found one, will define
HAVE_PCI_LOOKUP_NAME and HAVE_PCI_PCI_H. To disable this code: after configuring, you can change those defines in include/net-snmp/net-snmp-config.h, then rebuild. The affected code is in agent/mibgroup/if-mib/data_access/interface_linux.c.
There's also a patch in this bug report: http://sourceforge.net/p/net-snmp/bugs/2449/
I resolved the issue using the stock snmpd that comes with the Raspbian.
In /etc/snmp/snmpd.conf file I isolated the issue to the following line
agentAddress udp:161,udp6:[::1]:161
Instead of listening on all interfaces, if I specify the the ip address of the eth0 interface i.e.:
agentAddress udp:10.0.1.5:161,udp6:[::1]:161
Then snmpd starts fine.
My speculation is that the stock snmpd tries to enumerate all possible interfaces including the pci ones.

Getting proxy information on Linux programmatically

I am currently using libproxy to get the proxy information (if any) on RedHat and Debian Linux. It doesn't work all that well, but it's the only way I know I can use to get the proxy information from my code.
I need to stop using the lib since in most cases it doesn't recognize the proxy.
Is there any way to acquire the proxy information? What i mean is, is there a file (or group of files) i can read, or an env variable or an API or system call that i can use to get the information?
Gnome based code is OK, KDE might help as well but i am looking for something more generic.
The code is C.
Now, before anyone asks, I don't want to use libproxy anymore. Period. I don't want to start investigating why it doesn't work. I don't really want to know whether there is a new version of that lib. I know it might work, I just don't want to use it. i can't use it (just because). So please don't point me that way.
Code is appreciated.
thanks.
In linux, the "global proxy setting" is typically just environment variables that are usually set in /etc/profile. You can examine those variables to see what proxy is set.
The variables are:
http_proxy - the proxy for HTTP connections
ftp_proxy - the proxy for FTP connections
Using the Network Proxy Preferences tool under Gnome saves information in the GConf database. The path to the keys are /system/http_proxy and /system/proxy. You can read about the detail in those trees at this page.
You can access the GConf database using the library API. Note that GConf is based on GObject. To examine the contents of this tree using the command line, try the following:
gconftool-2 -R /system/http_proxy
This will provide a "name = value" listing of the tree, which may be usable in your application. Note that this requires a system() call, so it's not recommended for a deployed application, but it might help you get started.
GNOME has its own place to store the Proxy settings, and I am sure KDE or any other DE has its own place too. May be you can look for any mention of where Proxy settings should be store in the Linux Standard Base. That could hint you a standard of doing it irrespective of Distro or DE.
DE -> Desktop Environment
char* proxy = getenv("all_proxy");
This statement puts the value of the environment variable called all_proxy, which is used by the system as a global proxy, in your C variable.
To print it in bash, try env | grep 'all_proxy' | cut -d= -f 2.

Resources