I've installed the net-snmp package (version 5.8) by downloading the tar.gz file and compiling the files inside on a RHEL server (version 6.9).
I can see that the package is installed when I type snmpd --version but whenever I try to use service snmpd restart it says snmpd: unrecognized service.
I did all the setups and the snmpd.conf file was created (but not at /etc/snmp/ for some reason initially, so I copied the file there) but it seems like snmpd isn't being recognized at all.
I even tried snmpd restart but nothing happens and it seems like the SNMP connection still isn't there either.
Is there a way to fix this issue? Thanks!
Related
I've just installed SnowSQL for Windows as per the instructions at https://docs.snowflake.com/en/user-guide/snowsql-install-config.html#installing-snowsql-on-microsoft-windows-using-the-installer
However, when I attempt to connect to Snowflake, it fails:
C:\>snowsql -a <account> -u <user> --authenticator externalbrowser -o log_level=DEBUG
No module named 'win32timezone'
If the error message is unclear, enable logging using -o log_level=DEBUG and see the log to find out the cause. Contact support for further help.
Goodbye!
C:\>snowsql -v
Version: 1.2.7
Any ideas appreciated
What version of windows are you using? How did you install?
No module named 'win32timezone'
Per the official documentation snowsql is a python application. The error message above is a python error indicating it cannot find the aforementioned package. However, installing that package is not likely a fix as snowsql appears to ship with a version of python. Which makes a lot of sense, dealing with python dependencies is a nightmare.
I started a Windows 2016 host in AWS and installed snowsql 1.2.7 via the MSI. I was able to get to the login screen without any problems.
I would completely remove snowsql, do a search for snowsql and delete any folders you find, then reinstall. If it's still not working I'd provide more information as requested above.
This was acknowledged as a defect by Snowflake, and they will fix it in a newer version. The workaround is to install v 1.2.5, and invoke this version from the command line
snowflake <options> -v 1.2.5
I tried to spoof my local network with arpspoof from dsniff package. Everything is good, I can see sniffed packets from my "victim" in Wireshark.
Now, how do I use webspy? I've tried something like this with running firefox:
#webspy -i wlan0 192.168.1.XXX
webspy: listening on wlan0
openURL(http://178.33.XXX.XXX/)
The "victim's" computer (192.168.1.XXX) tried to connect with 178.33.XXX.XXX but I couldn't see anything in firefox. Is this requiring something more?
According to this post, two things can be the cause for not getting the victim browser's mirror in webspy:
Firefox browser should be opened from the command-line firefox &, after running the webspy listener.
If dniff (the package of "dniff suite of tools" which includes webspy, dniff,arpspoof,dnsspoof, mailsnarf etc.) is installed by manually compiling the source package instead through the package manager (such as apt-get or yum), the arp.c source file in the unpacked dniff directory should be edited.
The following line in the arp.c file should be changed from
strncpy(ar.arp_dev, "eth0", sizeof(ar.arp_dev));
to
strncpy(ar.arp_dev, "wlan0", sizeof(ar.arp_dev));
Save the file and recompile the application.
I've been trying to install MacPorts on a new Mac Pro with a fresh, fully updated Yosemite OS. The installer hangs on 'Running package scripts'. So I tried to build it from source. That works, with the installer stating:
Congratulations, you have successfully installed the MacPorts system.
However, it seems unusable. When I do sudo port install apache2 I get the message:
Error: Port apache2 not found
Simply trying to do a 'self update' (as root):
sh-3.2# port -d selfupdate
DEBUG: MacPorts sources location: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
---> Updating MacPorts base sources using rsync
receiving file list ... done
base.tar
...and then nothing... I've waited for half an hour, but it won't go any further. I can't find any logs either.
Again: there's nothing special about my setup, it's out-of-the-box Yosemite, only updated through the App store and, of course, I've installed Xcode with command line utilities and formally accepted the license, as is required according to the MacPorts site.
I've also tried uninstalling it, using the instructions from the MacPorts site, and reinstalling. But it does not make a difference.
I've read quite a few forum posts, but I can't find any post relating a problem like this. I hope someone can shed some light on this.
The installer hangs running package scripts because the last statement in these package scripts is exactly this "sudo port selfupdate" that you've been running manually afterwards.
Because this step did never run, your MacPorts installation lacks knowledge about the apache2 port (which is exactly why the installer runs selfupdate to give you a full-featured installation).
Unfortunately Apple's infrastructure (rsync.macports.org) seems to have connectivity problems at the moment, which is causing problems for quite a few people. You can try using one of the mirrors as outlined at https://trac.macports.org/wiki/Mirrors.
I am trying to install CKAN on my local computer using Ubuntu 14.04 LTS.
I followed the instructions for installing from source found here and I try to check if solr is running by visiting http://localhost:8983/solr/.
I can see that Jetty is running because when I visit http://localhost:8983 I see that it is up.
I added the jdk as follows:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk-amd64
I am getting a 500 error when i try to open the solr page:
HTTP ERROR 500
Problem accessing /solr/index.jsp. Reason:
JSP support not configured
Powered by Jetty://
Any ideas? Should I redo the whole thing from the start?
Edit/Update
I just couldn't do anything with this installation. The bigger problem was that installation files were meshed up! I tried to install tomcat/solr instead of jetty/solr and things went sour. So I just created a VM and did a fresh install there. For anyone interested I did a tomcat/solr installation following this and a CKAN installation following this (with out of course the solr instructions). Also, for some reason the CKAN installation has commented out the solr URL, so even if it is right, I had to delete the comment.
A fix has been documented by #mstantoncook here [2939] & [1651] How to solr-jetty JSP support
Note the last comment, sudo service jetty restart
It's a Jetty BUG on Ubuntu 14.04!
There is nothing wrong with Ckan itself.
Actually, there is a bug in the libjetty-extra-java package (version 6.1.26 and newer) in Ubuntu 14.04. The bug was introduced after Jetty (in Ubuntu) has changed it's dependences from libtomcat6-java to libtomcat7-java.
You can get more info about this bug in Ubuntu Launchpad: Bug #1508562 "Broken symlinks for JSP support in libjetty-extra-java version 6.1.26-1ubuntu1.1".
The bug is already fixed on Debian, and I'm hope it will be solved in Ubuntu 14.04 soon.
There are workarounds that may work for your case
I proposed some workarounds in this bug report, and since they can be useful for the Ckan users, I'll also replicate them here.
All of them consist on use both jetty and libtomcat7-java, but adding/replacing some classes (code ported from libtomcat6, in put in the jsp-2.1-6.0.2.jar file) to the Jetty classpath.
I don't know if they have some problem. Use them at your own risk!
Workaround 1 - Install the fix package proposed by vshn
I found this workaround here: https://github.com/ckan/ckan/pull/2966
In short:
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
service jetty restart
This will install a JSP jar that works (the file will be named jsp-2.1-6.0.2.jar, but it contains classes ported from libtomcat6).
Workaround 2 - Manually install the JSP jar
Download the same JAR file that the DEB package above would install.
wget https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+attachment/4785985/+files/jsp-2.1-6.0.2.jar
Now, move it to a proper location inside the Jetty config dir. I did it this way:
mkdir /etc/jetty/extra-jars
mv jsp-2.1-6.0.2.jar /etc/jetty/extra-jars
And add a line like this one in the Jetty start.config file:
echo "/etc/jetty/extra-jars/jsp-2.1-6.0.2.jar" >> /etc/jetty/start.config
And:
service jetty restart
Correct solution
The correct solution is to wait for the Ubuntu Team solution. However, while waiting for this fix, you can use any of the previous workarounds (I prefer the last one).
I hope they help you!
Try this steps:
sudo mv jsp-2.1-6.0.2.jar /usr/share/jetty/lib/.
change own:
sudo chown root:root /usr/share/jetty/lib/jsp-2.1-6.0.2.jar
finally restart jetty:
sudo service jetty restart
I followed this steps and now I can see localhost:8983/solr and localhost/solr/admin
In Ubuntu 14.04 this can be fixed with:
cd /tmp
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
sudo dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
sudo service jetty restart
Following http://docs.ckan.org/en/ckan-1.6/solr-setup.html#single-solr-instance
(this one a bit old, but worked perfect for me )
You will have to edit /etc/profile and add this line to the end such as this to the end (adjusting the path for your machine’s jdk install:
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/ (or other version)
then
export JAVA_HOME
sudo service jetty start
I have a Nagios server installation up and running.
I'm starting to deploy check_mk out to all my client machines.
I am using mrpe for custom checks on my client machines.
As one of the checks, I would like to use the check_ssh plugin.
I tried to copy check_ssh from another machine to the client but it looks like it won't allow me to run it this way. Can I get away from actually installing the nagios agent and just stick to check_mk and be able to run Nagios plugins?
The exact error I am getting is:
ld.so.1: check_ssh: fatal: libintl.so.3: open failed: No such file or directory
thanks in advance
Most of the plugins in the standard nagios-plugins pack are compiled C, so if you're copying them to a different distribution or architecture they may not work. I would consider just downloading the nagios-plugins package or grabbing the latest source package for the client machines.
Nagios Plugins Source tarball
http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.16.tar.gz
You can check SSH without nrpe plugin, it can be done from the Nagios server, just use the check_ssh plugin with this command (launched from the server):
./usr/local/nagios/libexec/check_ssh -H <client_ip>
If it's enabled it should print something like:
SSH OK - OpenSSH_6.0p1 Debian-4+deb7u1 (protocol 2.0) |
time=0,018154s;;;0,000000;10,000000
(That's because i'm using Debian Wheezy)
check_ssh comes with Nagios plugins tarball...
I'm currently using
nagios-plugins-2.0.2.tar.gz
Good luck...